Peter Hurley wrote:
> On Fri, 2013-03-29 at 11:44 +0100, Stefan Richter wrote:
>>> On Mar 26 Peter Hurley wrote:
The FW643e-2 is natively PCIe (not behind a bridge) and supports phys
DMA past 4GB (the datasheet says all 48 bits but I can only test it out
to 10GB).
I
Peter Hurley wrote:
On Fri, 2013-03-29 at 11:44 +0100, Stefan Richter wrote:
On Mar 26 Peter Hurley wrote:
The FW643e-2 is natively PCIe (not behind a bridge) and supports phys
DMA past 4GB (the datasheet says all 48 bits but I can only test it out
to 10GB).
I thought the FW643e was as
Peter Hurley wrote:
> On Tue, 2013-03-26 at 17:12 +0100, Clemens Ladisch wrote:
>> Peter Hurley wrote:
>>> Write the PhyUpperBound register with the end-of-memory value. If
>>> end-of-memory is beyond the OHCI limit of 0x,
>>> clamp to that
Peter Hurley wrote:
> Quadlet reads to memory above 4GB is painfully slow when serviced
> by the AR DMA context. In addition, the CPU(s) may be locked-up,
> preventing any transfer at all.
Using physical DMA prevents the use of that address space for software
address handlers, so you have adjust
Peter Hurley wrote:
Quadlet reads to memory above 4GB is painfully slow when serviced
by the AR DMA context. In addition, the CPU(s) may be locked-up,
preventing any transfer at all.
Using physical DMA prevents the use of that address space for software
address handlers, so you have adjust the
Peter Hurley wrote:
On Tue, 2013-03-26 at 17:12 +0100, Clemens Ladisch wrote:
Peter Hurley wrote:
Write the PhyUpperBound register with the end-of-memory value. If
end-of-memory is beyond the OHCI limit of 0x,
clamp to that value.
You will have to lower this limit
Eduardo Cruz wrote:
> Please, anyone knows how to solve this problem?
>
> 2013/3/20 Eduardo Cruz :
>> I'm trying to remap some kernel static memory to user space using
>> remap_pfn_range.
Well, don't do that.
What is the actual problem you're trying to solve?
Regards,
Clemens
--
To unsubscribe
Eduardo Cruz wrote:
Please, anyone knows how to solve this problem?
2013/3/20 Eduardo Cruz eduardohmdac...@gmail.com:
I'm trying to remap some kernel static memory to user space using
remap_pfn_range.
Well, don't do that.
What is the actual problem you're trying to solve?
Regards,
Clemens
Prarit Bhargava wrote:
> On 03/19/2013 03:43 AM, Clemens Ladisch wrote:
>> Prarit Bhargava wrote:
>>> + int "Enable HPET MMAP access by default"
>>> + default 0
>>
>> This breaks backwards compatibility.
>
> Does backwards compatibility
parameter, hpet_mmap_enable, that is required in order
> to actually have the HPET MMAP exposed.
>
> [v2]: Clemens suggested modifying the Kconfig help text and making the
> default setting configurable.
>
> Signed-off-by: Prarit Bhargava
> Cc: Clemens Ladisch
> +++ b/Documenta
in order
to actually have the HPET MMAP exposed.
[v2]: Clemens suggested modifying the Kconfig help text and making the
default setting configurable.
Signed-off-by: Prarit Bhargava pra...@redhat.com
Cc: Clemens Ladisch clem...@ladisch.de
+++ b/Documentation/kernel-parameters.txt
Prarit Bhargava wrote:
On 03/19/2013 03:43 AM, Clemens Ladisch wrote:
Prarit Bhargava wrote:
+ int Enable HPET MMAP access by default
+ default 0
This breaks backwards compatibility.
Does backwards compatibility matter for something like? I have no problem
setting it to 1 but I'm
Prarit Bhargava wrote:
> The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET
> registers to userspace. The Kconfig help points out that in some cases this
> can be a security risk as some systems may erroneously configure the map such
> that additional data is exposed to
Prarit Bhargava wrote:
The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET
registers to userspace. The Kconfig help points out that in some cases this
can be a security risk as some systems may erroneously configure the map such
that additional data is exposed to userspace.
ce where it might have ended up.
Reported-by: Dave Helstroom
Signed-off-by: Clemens Ladisch
---
sound/usb/card.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index df2f6d0..34dc3e8 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
David Helstroom wrote:
> Interface 1 does not exist
Then it doesn't need a quirk, does it?
> and Interface 0 should be ignored.
Why?
If the driver doesn't like something in interface 0, that bug should be
fixed.
What is the output of "lsusb -v" for this device?
Regards,
Clemens
--
To
David Helstroom wrote:
Interface 1 does not exist
Then it doesn't need a quirk, does it?
and Interface 0 should be ignored.
Why?
If the driver doesn't like something in interface 0, that bug should be
fixed.
What is the output of lsusb -v for this device?
Regards,
Clemens
--
To
-by: Dave Helstroom helstr...@google.com
Signed-off-by: Clemens Ladisch clem...@ladisch.de
---
sound/usb/card.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index df2f6d0..34dc3e8 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
Vicentiu Ciorbaru wrote:
> On Sun, Mar 10, 2013 at 6:32 PM, Clemens Ladisch wrote:
>> Vicentiu Ciorbaru wrote:
>>> Removed redundant cast of kmalloc return pointer.
>>
>>> - (icode->gpr_map = (u_int32_t __user *)
>>> - kcalloc
Vicentiu Ciorbaru wrote:
> Removed redundant cast of kmalloc return pointer.
> - (icode->gpr_map = (u_int32_t __user *)
> - kcalloc(512 + 256 + 256 + 2 * 1024, sizeof(u_int32_t),
> - GFP_KERNEL)) == NULL ||
> + (icode->gpr_map = kcalloc(512 + 256 + 256 +
Vicentiu Ciorbaru wrote:
Removed redundant cast of kmalloc return pointer.
- (icode-gpr_map = (u_int32_t __user *)
- kcalloc(512 + 256 + 256 + 2 * 1024, sizeof(u_int32_t),
- GFP_KERNEL)) == NULL ||
+ (icode-gpr_map = kcalloc(512 + 256 + 256 + 2 *
Vicentiu Ciorbaru wrote:
On Sun, Mar 10, 2013 at 6:32 PM, Clemens Ladisch clem...@ladisch.de wrote:
Vicentiu Ciorbaru wrote:
Removed redundant cast of kmalloc return pointer.
- (icode-gpr_map = (u_int32_t __user *)
- kcalloc(512 + 256 + 256 + 2 * 1024, sizeof(u_int32_t
Jeffrey Walton wrote:
> http://www.tux.org/lkml/ is a tough read, and Item 4, "I think I found
> a bug, how do I report it?" does not tell me how to report this.
>From that page:
| A bug is when something (in the kernel, presumably) doesn't behave the
| way it should
So just tell us what it is
Jeffrey Walton wrote:
http://www.tux.org/lkml/ is a tough read, and Item 4, I think I found
a bug, how do I report it? does not tell me how to report this.
From that page:
| A bug is when something (in the kernel, presumably) doesn't behave the
| way it should
So just tell us what it is that
kernel kernel wrote:
> Requesting guidance on how to implement the missing mic input support
> for this Asus Xonar card. I've downloaded the relevant datasheets but
> am unsure how to proceed.
Rip out the card, and look (or eletrically trace) how the CMI8788's
GPIOs and the CS4245's
kernel kernel wrote:
Requesting guidance on how to implement the missing mic input support
for this Asus Xonar card. I've downloaded the relevant datasheets but
am unsure how to proceed.
Rip out the card, and look (or eletrically trace) how the CMI8788's
GPIOs and the CS4245's inputs/outputs
James Courtier-Dutton wrote:
> I have been given a linux kernel sources tar file.
> It contains a modified version of the linux kernel.
> It is just source files, without any "git" history.
> What I would like to do is compare this with the mainline linux kernel
> git tree, and find the tag from
James Courtier-Dutton wrote:
I have been given a linux kernel sources tar file.
It contains a modified version of the linux kernel.
It is just source files, without any git history.
What I would like to do is compare this with the mainline linux kernel
git tree, and find the tag from the
(CC'd sqlite-users ML)
Theodore Ts'o wrote:
> On Tue, Oct 09, 2012 at 02:53:26PM -0500, Jooyoung Hwang wrote:
>> I'd like you to refer to the following link as well which is about
>> mobile workload pattern.
>> http://www.cs.cmu.edu/~fuyaoz/courses/15712/report.pdf
>> It's reported that in Android
(CC'd sqlite-users ML)
Theodore Ts'o wrote:
On Tue, Oct 09, 2012 at 02:53:26PM -0500, Jooyoung Hwang wrote:
I'd like you to refer to the following link as well which is about
mobile workload pattern.
http://www.cs.cmu.edu/~fuyaoz/courses/15712/report.pdf
It's reported that in Android there
Stefan Richter wrote:
> On Sep 10 Shuah Khan wrote:
http://linuxdriverproject.org/mediawiki/index.php/DMA_Mapping_Error_Analysis
>>>
File Name # of calls Status
drivers/firewire/core-iso.c 1Unmap Broken
drivers/firewire/ohci.c 1
Shuah Khan wrote:
> I analyzed all calls to dma_map_single() and dma_map_page() in the
> kernel, to see if callers check for mapping errors, before using the
> returned address.
>
> The goal of this analysis is to find drivers that currently do not
> check dma mapping errors, and fix them.
>
> I
Shuah Khan wrote:
I analyzed all calls to dma_map_single() and dma_map_page() in the
kernel, to see if callers check for mapping errors, before using the
returned address.
The goal of this analysis is to find drivers that currently do not
check dma mapping errors, and fix them.
I
Stefan Richter wrote:
On Sep 10 Shuah Khan wrote:
http://linuxdriverproject.org/mediawiki/index.php/DMA_Mapping_Error_Analysis
File Name # of calls Status
drivers/firewire/core-iso.c 1Unmap Broken
drivers/firewire/ohci.c 1Unmap Broken
In
Wei Yongjun wrote:
> Using list_move_tail() instead of list_del() + list_add_tail().
>
> Signed-off-by: Wei Yongjun
Acked-by: Clemens Ladisch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Wei Yongjun wrote:
Using list_move_tail() instead of list_del() + list_add_tail().
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Acked-by: Clemens Ladisch clem...@ladisch.de
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
Stefan Richter wrote:
> On Aug 12 Clemens Ladisch wrote:
>> Send the GUIDs of newly registered controllers and devices
>> to the /dev/random driver to help seed its pools.
>
> This looks good to me, almost. Isn't the call in fw_card_add redundant?
> The local node's fw_dev
Stefan Richter wrote:
On Aug 12 Clemens Ladisch wrote:
Send the GUIDs of newly registered controllers and devices
to the /dev/random driver to help seed its pools.
This looks good to me, almost. Isn't the call in fw_card_add redundant?
The local node's fw_device instance initializer feeds
Karl Beldan wrote:
> On 7/31/12, Clemens Ladisch wrote:
>> Karl Beldan wrote:
>>> To tx a chunk of data from the SoC => network device, we :
>>> - prepare a buffer with a leading header embedding a pattern,
>>> - trigger the xfer and wait for an ir
Karl Beldan wrote:
> To tx a chunk of data from the SoC => network device, we :
> - prepare a buffer with a leading header embedding a pattern,
> - trigger the xfer and wait for an irq
> // The device updates the pattern and then triggers an irq
> - upon irq we check the pattern for the xfer
Karl Beldan wrote:
To tx a chunk of data from the SoC = network device, we :
- prepare a buffer with a leading header embedding a pattern,
- trigger the xfer and wait for an irq
// The device updates the pattern and then triggers an irq
- upon irq we check the pattern for the xfer completion
Karl Beldan wrote:
On 7/31/12, Clemens Ladisch clem...@ladisch.de wrote:
Karl Beldan wrote:
To tx a chunk of data from the SoC = network device, we :
- prepare a buffer with a leading header embedding a pattern,
- trigger the xfer and wait for an irq
// The device updates the pattern
Chris Brennan wrote:
> These are the updated pastbin links to my BT8x8 issue. Hopefully these
> are helpful, if you need more information, let me know.
You didn't answer Robert's question.
And you are using the fglrx driver; you'll have to ask ATI whether if
supports video overlays and how to
Joshua Roys wrote:
> sound/core/init.c: In function ‘snd_card_disconnect’:
> sound/core/init.c:307: warning: the address of ‘snd_shutdown_f_ops’ will
> always evaluate as ‘true’
>
> Signed-off-by: Joshua Roys <[EMAIL PROTECTED]>
> ---
> sound/core/init.c |1 -
> 1 files changed, 0
Joshua Roys wrote:
sound/core/init.c: In function ‘snd_card_disconnect’:
sound/core/init.c:307: warning: the address of ‘snd_shutdown_f_ops’ will
always evaluate as ‘true’
Signed-off-by: Joshua Roys [EMAIL PROTECTED]
---
sound/core/init.c |1 -
1 files changed, 0 insertions(+), 1
Chris Brennan wrote:
These are the updated pastbin links to my BT8x8 issue. Hopefully these
are helpful, if you need more information, let me know.
You didn't answer Robert's question.
And you are using the fglrx driver; you'll have to ask ATI whether if
supports video overlays and how to
r
shared interrupt handler.
Signed-off-by: Clemens Ladisch <[EMAIL PROTECTED]>
--- linux.orig/sound/pci/bt87x.cTue Feb 19 15:03:57 2008 +0100
+++ linux/sound/pci/bt87x.c Wed Feb 20 08:55:18 2008 +0100
@@ -681,15 +681,12 @@ static struct snd_kcontrol_new snd_bt87x
static i
Eyal Lebedinsky wrote:
> My /etc/modprobe.conf now contains:
> alias snd-card-0 snd-hda-intel
> options snd-card-0 index=0
> options snd-hda-intel index=0
> and and I should add
> options snd-usb-audio index=1
> right?
Yes.
> Any idea why has this changed between the two
Eyal Lebedinsky wrote:
> A recent update to 2.6.23.14-64.fc7 lost sound. The boot log now has
> hda-intel: Error creating card!
> HDA Intel: probe of :00:1b.0 failed with error -12
The two lines before:
| usbcore: registered new interface driver snd-usb-audio
| cannot find the
Eyal Lebedinsky wrote:
A recent update to 2.6.23.14-64.fc7 lost sound. The boot log now has
hda-intel: Error creating card!
HDA Intel: probe of :00:1b.0 failed with error -12
The two lines before:
| usbcore: registered new interface driver snd-usb-audio
| cannot find the slot
Eyal Lebedinsky wrote:
My /etc/modprobe.conf now contains:
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
and and I should add
options snd-usb-audio index=1
right?
Yes.
Any idea why has this changed between the two minor
Greg KH wrote:
> On Mon, Jan 28, 2008 at 09:13:16AM +0100, Clemens Ladisch wrote:
>> Greg KH wrote:
>> > Over two years ago, the Linux USB developers stated that they believed
>> > there was no way to create a USB kernel driver that was not under the
>> >
Greg KH wrote:
> Over two years ago, the Linux USB developers stated that they believed
> there was no way to create a USB kernel driver that was not under the
> GPL. This patch moves the USB apis to enforce that decision.
>
> There are no known closed source USB drivers in the wild, so this
Greg KH wrote:
On Mon, Jan 28, 2008 at 09:13:16AM +0100, Clemens Ladisch wrote:
Greg KH wrote:
Over two years ago, the Linux USB developers stated that they believed
there was no way to create a USB kernel driver that was not under the
GPL. This patch moves the USB apis to enforce
Andrew Paprocki wrote:
> I started debugging a problem I was having with my sky2 network driver
> under 2.6.23.13. The investigation led me to find that the HPET timer
> wasn't working at all, causing the sky2 driver to not work properly.
> Simple example:
>
>
Andrew Paprocki wrote:
I started debugging a problem I was having with my sky2 network driver
under 2.6.23.13. The investigation led me to find that the HPET timer
wasn't working at all, causing the sky2 driver to not work properly.
Simple example:
; which was set in hpet_set_alarm_time().
>
> This patch is against 2.6.24-rc5-mm1.
>
>
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
Acked-by: Clemens Ladisch <[EMAIL PROTECTED]>
> ---
> arch/x86/kernel/hpet.c |2 +-
> 1 file changed, 1 insertion(
in hpet_set_alarm_time().
This patch is against 2.6.24-rc5-mm1.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
Acked-by: Clemens Ladisch [EMAIL PROTECTED]
---
arch/x86/kernel/hpet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86
Denys Vlasenko wrote:
Hi Tapio,
You are the author of these files. Are you still maintaining them?
His newer email address that I found with Google is dead, too.
These two object files hold the biggest data objects in the whole
Linux kernel
Basically, these are big arrays of the
Denys Vlasenko wrote:
Hi Tapio,
You are the author of these files. Are you still maintaining them?
His newer email address that I found with Google is dead, too.
These two object files hold the biggest data objects in the whole
Linux kernel
Basically, these are big arrays of the
Luck, Tony wrote:
[...] Given that the hang went away when you applied the earlier patch, I
conclude that the drivers/char/hpet.c code is the one that got selected when
you had two "hpet" entries ... and that there is something wrong with that
code that doesn't work right on x86_64.
Luck, Tony wrote:
[...] Given that the hang went away when you applied the earlier patch, I
conclude that the drivers/char/hpet.c code is the one that got selected when
you had two hpet entries ... and that there is something wrong with that
code that doesn't work right on x86_64.
Apparently,
David Griffith wrote:
On Mon, 20 Aug 2007, Clemens Ladisch wrote:
David Griffith wrote:
> $ aplaymidi -p 20:0 casablan.mid
>
> Nothing is written to the Fastlane. No lights. Nothing.
Please run "amidi -d -p virtual" and then play to the virtual port
created by amidi, to s
David Griffith wrote:
On Mon, 20 Aug 2007, Clemens Ladisch wrote:
David Griffith wrote:
$ aplaymidi -p 20:0 casablan.mid
Nothing is written to the Fastlane. No lights. Nothing.
Please run amidi -d -p virtual and then play to the virtual port
created by amidi, to see if MIDI playback works
David Griffith wrote:
> On Fri, 17 Aug 2007, Clemens Ladisch wrote:
> > David Griffith wrote:
> > > On Thu, 16 Aug 2007, Clemens Ladisch wrote:
> > > > Please try "amidi -d -p virtual" and playing a .mid file to this port
> > > > with
&g
David Griffith wrote:
On Fri, 17 Aug 2007, Clemens Ladisch wrote:
David Griffith wrote:
On Thu, 16 Aug 2007, Clemens Ladisch wrote:
Please try amidi -d -p virtual and playing a .mid file to this port
with
aplaymidi.
$ aplaymidi -p virtual castle2.mid
Invalid port
David Griffith wrote:
> On Thu, 16 Aug 2007, Clemens Ladisch wrote:
> > Please try "amidi -d -p virtual" and playing a .mid file to this port with
> > aplaymidi.
>
> $ aplaymidi -p "virtual" castle2.mid
> Invalid port virtual - No such file or di
David Griffith wrote:
On Thu, 16 Aug 2007, Clemens Ladisch wrote:
Please try amidi -d -p virtual and playing a .mid file to this port with
aplaymidi.
$ aplaymidi -p virtual castle2.mid
Invalid port virtual - No such file or directory
Sorry, the name of the correspondig sequencer port
David Griffith wrote:
Checking further, I've never been able to
get midi to work with kernels 2.6.18 and later.
Please try "amidi -d -p virtual" and playing a .mid file to this port with
aplaymidi.
Regards,
Clemens
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
David Griffith wrote:
Does anyone here have or can borrow a MOTU Fastlane USB MIDI interface?
I'm having a nasty time trying to nail down what's going wrong. It seems
that for kernels 2.6.17 and earlier, MIDI works fine through this
interface. After that, it doesn't.
What do you mean with
David Griffith wrote:
Does anyone here have or can borrow a MOTU Fastlane USB MIDI interface?
I'm having a nasty time trying to nail down what's going wrong. It seems
that for kernels 2.6.17 and earlier, MIDI works fine through this
interface. After that, it doesn't.
What do you mean with
David Griffith wrote:
Checking further, I've never been able to
get midi to work with kernels 2.6.18 and later.
Please try amidi -d -p virtual and playing a .mid file to this port with
aplaymidi.
Regards,
Clemens
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Ingo Molnar wrote:
so how about the following, different approach: anyone who has a tasklet
in any performance-sensitive codepath, please yell now.
ALSA uses quite a few tasklets in the framework and in several
drivers. Since we
care very much about low latency, many places use
Ingo Molnar wrote:
so how about the following, different approach: anyone who has a tasklet
in any performance-sensitive codepath, please yell now.
ALSA uses quite a few tasklets in the framework and in several
drivers. Since we
care very much about low latency, many places use
Biederman <[EMAIL PROTECTED]>
Acked-by: Clemens Ladisch <[EMAIL PROTECTED]>
> ---
> drivers/char/hpet.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 20dc3be..81be1db 100644
> --- a
-by: Clemens Ladisch [EMAIL PROTECTED]
---
drivers/char/hpet.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 20dc3be..81be1db 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -703,7 +703,7 @@ int
301 - 376 of 376 matches
Mail list logo
