Re: Linux 2.6.13-rc4 (snd-cs46xx)
On Tue, 2005-08-02 at 12:13 -0400, Bill Davidsen wrote: > You are hardly the first person to implement the "it doesn't work right, > but it sure is FAST!" algorithm. > I would actually call it the "It works _most_ of the time, and it sure is FAST!" algorithm. It's a step up from what you mentioned :-) -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
Steven Rostedt wrote: On Fri, 2005-07-29 at 10:29 -0700, Linus Torvalds wrote: On Fri, 29 Jul 2005, Cal Peake wrote: Thanks Andrew! Indeed your suspicions are correct. Adding in all the debugging moved the problem around, it now shows itself when probing parport. Upon further investigation reverting the commit below seems to have nixed the problem. Thanks. Just out of interest, does this patch fix it instead? Oops, never thought that size would be zero coming in. I originally had it as a while() instead of a do while but thought that I could speed it up if the first word succeeded. Sorry for that. I blame it on it being late when I wrote it and trying several different ways. :-P You are hardly the first person to implement the "it doesn't work right, but it sure is FAST!" algorithm. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
Steven Rostedt wrote: On Fri, 2005-07-29 at 10:29 -0700, Linus Torvalds wrote: On Fri, 29 Jul 2005, Cal Peake wrote: Thanks Andrew! Indeed your suspicions are correct. Adding in all the debugging moved the problem around, it now shows itself when probing parport. Upon further investigation reverting the commit below seems to have nixed the problem. Thanks. Just out of interest, does this patch fix it instead? Oops, never thought that size would be zero coming in. I originally had it as a while() instead of a do while but thought that I could speed it up if the first word succeeded. Sorry for that. I blame it on it being late when I wrote it and trying several different ways. :-P You are hardly the first person to implement the it doesn't work right, but it sure is FAST! algorithm. -- -bill davidsen ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
On Tue, 2005-08-02 at 12:13 -0400, Bill Davidsen wrote: You are hardly the first person to implement the it doesn't work right, but it sure is FAST! algorithm. I would actually call it the It works _most_ of the time, and it sure is FAST! algorithm. It's a step up from what you mentioned :-) -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
On Fri, 2005-07-29 at 10:29 -0700, Linus Torvalds wrote: > > On Fri, 29 Jul 2005, Cal Peake wrote: > > > > Thanks Andrew! Indeed your suspicions are correct. Adding in all the > > debugging moved the problem around, it now shows itself when probing > > parport. Upon further investigation reverting the commit below seems to > > have nixed the problem. > > Thanks. Just out of interest, does this patch fix it instead? Oops, never thought that size would be zero coming in. I originally had it as a while() instead of a do while but thought that I could speed it up if the first word succeeded. Sorry for that. I blame it on it being late when I wrote it and trying several different ways. :-P -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
On Fri, 29 Jul 2005, Linus Torvalds wrote:
> Thanks. Just out of interest, does this patch fix it instead?
Indeed it does, thanks Linus!
-cp
>
> diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
> --- a/include/asm-i386/bitops.h
> +++ b/include/asm-i386/bitops.h
> @@ -335,14 +335,13 @@ static inline unsigned long __ffs(unsign
> static inline int find_first_bit(const unsigned long *addr, unsigned size)
> {
> int x = 0;
> - do {
> - if (*addr)
> - return __ffs(*addr) + x;
> - addr++;
> - if (x >= size)
> - break;
> +
> + while (x < size) {
> + unsigned long val = *addr++;
> + if (val)
> + return __ffs(val) + x;
> x += (sizeof(*addr)<<3);
> - } while (1);
> + }
> return x;
> }
>
>
--
"Democracy can learn some things from Communism; for example,
when a Communist politician is through, he is through."
-- Unknown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
On Fri, 29 Jul 2005, Cal Peake wrote:
>
> Thanks Andrew! Indeed your suspicions are correct. Adding in all the
> debugging moved the problem around, it now shows itself when probing
> parport. Upon further investigation reverting the commit below seems to
> have nixed the problem.
Thanks. Just out of interest, does this patch fix it instead?
Linus
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -335,14 +335,13 @@ static inline unsigned long __ffs(unsign
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
int x = 0;
- do {
- if (*addr)
- return __ffs(*addr) + x;
- addr++;
- if (x >= size)
- break;
+
+ while (x < size) {
+ unsigned long val = *addr++;
+ if (val)
+ return __ffs(val) + x;
x += (sizeof(*addr)<<3);
- } while (1);
+ }
return x;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
On Thu, 28 Jul 2005, Andrew Morton wrote:
> The procfs inode IDR tree is scrogged. I'd be suspecting a random memory
> scribble. I'd suggest that you enable CONFIG_DEBUG_SLAB,
> CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_everything_else and retest.
>
> If that doesn't show anything, try eliminating stuff from your kernel
> config.
>
> If it _is_ a scribble then there's a good chance that changing the config
> will simply make it disappear, or will make it manifest in different ways.
Thanks Andrew! Indeed your suspicions are correct. Adding in all the
debugging moved the problem around, it now shows itself when probing
parport. Upon further investigation reverting the commit below seems to
have nixed the problem.
thx,
-cp
[PATCH] speed up on find_first_bit for i386 (let compiler do the work)
Avoid using "rep scas", just let the compiler select a sequence of
regular instructions.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
commit: cd85c8b4457a52d3545fdb9532082b2c1ebd5f21
--- ./include/asm-i386/bitops.h
+++ ./include/asm-i386/bitops.h
@@ -311,6 +311,20 @@ static inline int find_first_zero_bit(co
int find_next_zero_bit(const unsigned long *addr, int size, int offset);
/**
+ * __ffs - find first bit in word.
+ * @word: The word to search
+ *
+ * Undefined if no bit exists, so code should check against 0 first.
+ */
+static inline unsigned long __ffs(unsigned long word)
+{
+ __asm__("bsfl %1,%0"
+ :"=r" (word)
+ :"rm" (word));
+ return word;
+}
+
+/**
* find_first_bit - find the first set bit in a memory region
* @addr: The address to start the search at
* @size: The maximum size to search
@@ -320,22 +334,16 @@ int find_next_zero_bit(const unsigned lo
*/
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
- int d0, d1;
- int res;
-
- /* This looks at memory. Mark it volatile to tell gcc not to move it
around */
- __asm__ __volatile__(
- "xorl %%eax,%%eax\n\t"
- "repe; scasl\n\t"
- "jz 1f\n\t"
- "leal -4(%%edi),%%edi\n\t"
- "bsfl (%%edi),%%eax\n"
- "1:\tsubl %%ebx,%%edi\n\t"
- "shll $3,%%edi\n\t"
- "addl %%edi,%%eax"
- :"=a" (res), "=" (d0), "=" (d1)
- :"1" ((size + 31) >> 5), "2" (addr), "b" (addr) : "memory");
- return res;
+ int x = 0;
+ do {
+ if (*addr)
+ return __ffs(*addr) + x;
+ addr++;
+ if (x >= size)
+ break;
+ x += (sizeof(*addr)<<3);
+ } while (1);
+ return x;
}
/**
@@ -360,20 +368,6 @@ static inline unsigned long ffz(unsigned
return word;
}
-/**
- * __ffs - find first bit in word.
- * @word: The word to search
- *
- * Undefined if no bit exists, so code should check against 0 first.
- */
-static inline unsigned long __ffs(unsigned long word)
-{
- __asm__("bsfl %1,%0"
- :"=r" (word)
- :"rm" (word));
- return word;
-}
-
/*
* fls: find last bit set.
*/
--
"Democracy can learn some things from Communism; for example,
when a Communist politician is through, he is through."
-- Unknown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
On Thu, 28 Jul 2005, Andrew Morton wrote:
The procfs inode IDR tree is scrogged. I'd be suspecting a random memory
scribble. I'd suggest that you enable CONFIG_DEBUG_SLAB,
CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_everything_else and retest.
If that doesn't show anything, try eliminating stuff from your kernel
config.
If it _is_ a scribble then there's a good chance that changing the config
will simply make it disappear, or will make it manifest in different ways.
Thanks Andrew! Indeed your suspicions are correct. Adding in all the
debugging moved the problem around, it now shows itself when probing
parport. Upon further investigation reverting the commit below seems to
have nixed the problem.
thx,
-cp
[PATCH] speed up on find_first_bit for i386 (let compiler do the work)
Avoid using rep scas, just let the compiler select a sequence of
regular instructions.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
commit: cd85c8b4457a52d3545fdb9532082b2c1ebd5f21
--- ./include/asm-i386/bitops.h
+++ ./include/asm-i386/bitops.h
@@ -311,6 +311,20 @@ static inline int find_first_zero_bit(co
int find_next_zero_bit(const unsigned long *addr, int size, int offset);
/**
+ * __ffs - find first bit in word.
+ * @word: The word to search
+ *
+ * Undefined if no bit exists, so code should check against 0 first.
+ */
+static inline unsigned long __ffs(unsigned long word)
+{
+ __asm__(bsfl %1,%0
+ :=r (word)
+ :rm (word));
+ return word;
+}
+
+/**
* find_first_bit - find the first set bit in a memory region
* @addr: The address to start the search at
* @size: The maximum size to search
@@ -320,22 +334,16 @@ int find_next_zero_bit(const unsigned lo
*/
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
- int d0, d1;
- int res;
-
- /* This looks at memory. Mark it volatile to tell gcc not to move it
around */
- __asm__ __volatile__(
- xorl %%eax,%%eax\n\t
- repe; scasl\n\t
- jz 1f\n\t
- leal -4(%%edi),%%edi\n\t
- bsfl (%%edi),%%eax\n
- 1:\tsubl %%ebx,%%edi\n\t
- shll $3,%%edi\n\t
- addl %%edi,%%eax
- :=a (res), =c (d0), =D (d1)
- :1 ((size + 31) 5), 2 (addr), b (addr) : memory);
- return res;
+ int x = 0;
+ do {
+ if (*addr)
+ return __ffs(*addr) + x;
+ addr++;
+ if (x = size)
+ break;
+ x += (sizeof(*addr)3);
+ } while (1);
+ return x;
}
/**
@@ -360,20 +368,6 @@ static inline unsigned long ffz(unsigned
return word;
}
-/**
- * __ffs - find first bit in word.
- * @word: The word to search
- *
- * Undefined if no bit exists, so code should check against 0 first.
- */
-static inline unsigned long __ffs(unsigned long word)
-{
- __asm__(bsfl %1,%0
- :=r (word)
- :rm (word));
- return word;
-}
-
/*
* fls: find last bit set.
*/
--
Democracy can learn some things from Communism; for example,
when a Communist politician is through, he is through.
-- Unknown
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
On Fri, 29 Jul 2005, Cal Peake wrote:
Thanks Andrew! Indeed your suspicions are correct. Adding in all the
debugging moved the problem around, it now shows itself when probing
parport. Upon further investigation reverting the commit below seems to
have nixed the problem.
Thanks. Just out of interest, does this patch fix it instead?
Linus
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -335,14 +335,13 @@ static inline unsigned long __ffs(unsign
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
int x = 0;
- do {
- if (*addr)
- return __ffs(*addr) + x;
- addr++;
- if (x = size)
- break;
+
+ while (x size) {
+ unsigned long val = *addr++;
+ if (val)
+ return __ffs(val) + x;
x += (sizeof(*addr)3);
- } while (1);
+ }
return x;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
On Fri, 29 Jul 2005, Linus Torvalds wrote:
Thanks. Just out of interest, does this patch fix it instead?
Indeed it does, thanks Linus!
-cp
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -335,14 +335,13 @@ static inline unsigned long __ffs(unsign
static inline int find_first_bit(const unsigned long *addr, unsigned size)
{
int x = 0;
- do {
- if (*addr)
- return __ffs(*addr) + x;
- addr++;
- if (x = size)
- break;
+
+ while (x size) {
+ unsigned long val = *addr++;
+ if (val)
+ return __ffs(val) + x;
x += (sizeof(*addr)3);
- } while (1);
+ }
return x;
}
--
Democracy can learn some things from Communism; for example,
when a Communist politician is through, he is through.
-- Unknown
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
On Fri, 2005-07-29 at 10:29 -0700, Linus Torvalds wrote: On Fri, 29 Jul 2005, Cal Peake wrote: Thanks Andrew! Indeed your suspicions are correct. Adding in all the debugging moved the problem around, it now shows itself when probing parport. Upon further investigation reverting the commit below seems to have nixed the problem. Thanks. Just out of interest, does this patch fix it instead? Oops, never thought that size would be zero coming in. I originally had it as a while() instead of a do while but thought that I could speed it up if the first word succeeded. Sorry for that. I blame it on it being late when I wrote it and trying several different ways. :-P -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
Cal Peake <[EMAIL PROTECTED]> wrote: > > Hi, > > Getting this nastiness when probing snd-cs46xx: > > Unable to handle kernel paging request at virtual address 000a75a8 > ... > EIP is at sub_alloc+0x42/0x170 > ... > [] idr_get_new_above_int+0x78/0x120 > [] idr_get_new+0x1f/0x50 > [] get_inode_number+0x39/0x60 > [] proc_register+0x17/0xb0 > [] create_proc_entry+0x85/0xd0 > [] snd_create_proc_entry+0x20/0x30 [snd] > [] snd_info_register+0x44/0xb0 [snd] > [] snd_pcm_lib_preallocate_pages1+0x92/0xd0 [snd_pcm] > [] snd_pcm_lib_preallocate_pages_for_all+0x44/0x70 [snd_pcm] > [] snd_cs46xx_pcm_rear+0xe0/0x100 [snd_cs46xx] > [] snd_card_cs46xx_probe+0xf9/0x250 [snd_cs46xx] > [] pci_match_device+0x1d/0xb0 > [] __pci_device_probe+0x58/0x70 > [] pci_device_probe+0x2f/0x50 > [] driver_probe_device+0x38/0xb0 > [] __driver_attach+0x0/0x50 > [] __driver_attach+0x4c/0x50 > [] bus_for_each_dev+0x69/0x80 > [] driver_attach+0x26/0x30 > [] __driver_attach+0x0/0x50 > [] bus_add_driver+0x83/0xe0 > [] pci_register_driver+0x6d/0x90 > [] alsa_card_cs46xx_init+0xf/0x13 [snd_cs46xx] > [] sys_init_module+0x141/0x1d0 > [] syscall_call+0x7/0xb > > > 2.6.13-rc3-git9 is OK. I'll try poking around at the ALSA changes, see if > I can figure out which one is the culprit. The procfs inode IDR tree is scrogged. I'd be suspecting a random memory scribble. I'd suggest that you enable CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_everything_else and retest. If that doesn't show anything, try eliminating stuff from your kernel config. If it _is_ a scribble then there's a good chance that changing the config will simply make it disappear, or will make it manifest in different ways. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
Hi, Getting this nastiness when probing snd-cs46xx: Unable to handle kernel paging request at virtual address 000a75a8 printing eip: c01afe52 *pde = Oops: [#1] Modules linked in: snd_cs46xx gameport snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc ipt_state ipt_REJECT ipt_LOG ip_conntrack iptable_filter ip_tables nfs lockd sunrpc cifs smbfs hfsplus udf isofs zlib_inflate ntfs msdos vfat fat nls_utf8 nls_iso8859_1 nls_cp437 nls_base e100 mii usb_storage sd_mod scsi_mod usbhid ohci_hcd ehci_hcd usbcore parport_pc parport psmouse pcspkr ide_cd cdrom floppy loop radeon drm nvidia_agp agpgart thermal processor fan button ac CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010246 (2.6.13-rc4) EIP is at sub_alloc+0x42/0x170 eax: 0440 ebx: 0022 ecx: edx: f7c3cd5c esi: 0440 edi: 000a75a8 ebp: esp: f7c3cd44 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 762, threadinfo=f7c3c000 task=f7df4550) Stack: f7c3cd5c 0020 0440 0440 c1cdf26c c1ceaf54 c1cdf260 00d0 f7736018 c1cdf26c 0002 f7733f60 c1ceaf54 c0335a74 c01afff8 c0335a74 f7c3cda0 Call Trace: [] idr_get_new_above_int+0x78/0x120 [] idr_get_new+0x1f/0x50 [] get_inode_number+0x39/0x60 [] proc_register+0x17/0xb0 [] create_proc_entry+0x85/0xd0 [] snd_create_proc_entry+0x20/0x30 [snd] [] snd_info_register+0x44/0xb0 [snd] [] snd_pcm_lib_preallocate_pages1+0x92/0xd0 [snd_pcm] [] snd_pcm_lib_preallocate_pages_for_all+0x44/0x70 [snd_pcm] [] snd_cs46xx_pcm_rear+0xe0/0x100 [snd_cs46xx] [] snd_card_cs46xx_probe+0xf9/0x250 [snd_cs46xx] [] pci_match_device+0x1d/0xb0 [] __pci_device_probe+0x58/0x70 [] pci_device_probe+0x2f/0x50 [] driver_probe_device+0x38/0xb0 [] __driver_attach+0x0/0x50 [] __driver_attach+0x4c/0x50 [] bus_for_each_dev+0x69/0x80 [] driver_attach+0x26/0x30 [] __driver_attach+0x0/0x50 [] bus_add_driver+0x83/0xe0 [] pci_register_driver+0x6d/0x90 [] alsa_card_cs46xx_init+0xf/0x13 [snd_cs46xx] [] sys_init_module+0x141/0x1d0 [] syscall_call+0x7/0xb Code: 08 8b 3a c7 44 8c 1c 00 00 00 00 49 89 4c 24 14 8d 2c 89 8d b6 00 00 00 00 8b 44 24 10 89 e9 8d 54 24 18 d3 f8 89 44 24 0c 89 c6 <8b> 07 83 e6 1f c7 44 24 04 20 00 00 00 89 14 24 89 74 24 08 f7 2.6.13-rc3-git9 is OK. I'll try poking around at the ALSA changes, see if I can figure out which one is the culprit. thx, -cp -- "Democracy can learn some things from Communism; for example, when a Communist politician is through, he is through." -- Unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
Hi, Getting this nastiness when probing snd-cs46xx: Unable to handle kernel paging request at virtual address 000a75a8 printing eip: c01afe52 *pde = Oops: [#1] Modules linked in: snd_cs46xx gameport snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc ipt_state ipt_REJECT ipt_LOG ip_conntrack iptable_filter ip_tables nfs lockd sunrpc cifs smbfs hfsplus udf isofs zlib_inflate ntfs msdos vfat fat nls_utf8 nls_iso8859_1 nls_cp437 nls_base e100 mii usb_storage sd_mod scsi_mod usbhid ohci_hcd ehci_hcd usbcore parport_pc parport psmouse pcspkr ide_cd cdrom floppy loop radeon drm nvidia_agp agpgart thermal processor fan button ac CPU:0 EIP:0060:[c01afe52]Not tainted VLI EFLAGS: 00010246 (2.6.13-rc4) EIP is at sub_alloc+0x42/0x170 eax: 0440 ebx: 0022 ecx: edx: f7c3cd5c esi: 0440 edi: 000a75a8 ebp: esp: f7c3cd44 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 762, threadinfo=f7c3c000 task=f7df4550) Stack: f7c3cd5c 0020 0440 0440 c1cdf26c c1ceaf54 c1cdf260 00d0 f7736018 c1cdf26c 0002 f7733f60 c1ceaf54 c0335a74 c01afff8 c0335a74 f7c3cda0 Call Trace: [c01afff8] idr_get_new_above_int+0x78/0x120 [c01b010f] idr_get_new+0x1f/0x50 [c017d409] get_inode_number+0x39/0x60 [c017d6c7] proc_register+0x17/0xb0 [c017db05] create_proc_entry+0x85/0xd0 [f8b18f80] snd_create_proc_entry+0x20/0x30 [snd] [f8b194f4] snd_info_register+0x44/0xb0 [snd] [f8bbc0d2] snd_pcm_lib_preallocate_pages1+0x92/0xd0 [snd_pcm] [f8bbc184] snd_pcm_lib_preallocate_pages_for_all+0x44/0x70 [snd_pcm] [f8be5030] snd_cs46xx_pcm_rear+0xe0/0x100 [snd_cs46xx] [f8be30f9] snd_card_cs46xx_probe+0xf9/0x250 [snd_cs46xx] [c01b9cbd] pci_match_device+0x1d/0xb0 [c01b9da8] __pci_device_probe+0x58/0x70 [c01b9def] pci_device_probe+0x2f/0x50 [c01fb168] driver_probe_device+0x38/0xb0 [c01fb270] __driver_attach+0x0/0x50 [c01fb2bc] __driver_attach+0x4c/0x50 [c01fa799] bus_for_each_dev+0x69/0x80 [c01fb2e6] driver_attach+0x26/0x30 [c01fb270] __driver_attach+0x0/0x50 [c01fac73] bus_add_driver+0x83/0xe0 [c01ba08d] pci_register_driver+0x6d/0x90 [f897e00f] alsa_card_cs46xx_init+0xf/0x13 [snd_cs46xx] [c012efb1] sys_init_module+0x141/0x1d0 [c0102c95] syscall_call+0x7/0xb Code: 08 8b 3a c7 44 8c 1c 00 00 00 00 49 89 4c 24 14 8d 2c 89 8d b6 00 00 00 00 8b 44 24 10 89 e9 8d 54 24 18 d3 f8 89 44 24 0c 89 c6 8b 07 83 e6 1f c7 44 24 04 20 00 00 00 89 14 24 89 74 24 08 f7 2.6.13-rc3-git9 is OK. I'll try poking around at the ALSA changes, see if I can figure out which one is the culprit. thx, -cp -- Democracy can learn some things from Communism; for example, when a Communist politician is through, he is through. -- Unknown - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
Cal Peake [EMAIL PROTECTED] wrote: Hi, Getting this nastiness when probing snd-cs46xx: Unable to handle kernel paging request at virtual address 000a75a8 ... EIP is at sub_alloc+0x42/0x170 ... [c01afff8] idr_get_new_above_int+0x78/0x120 [c01b010f] idr_get_new+0x1f/0x50 [c017d409] get_inode_number+0x39/0x60 [c017d6c7] proc_register+0x17/0xb0 [c017db05] create_proc_entry+0x85/0xd0 [f8b18f80] snd_create_proc_entry+0x20/0x30 [snd] [f8b194f4] snd_info_register+0x44/0xb0 [snd] [f8bbc0d2] snd_pcm_lib_preallocate_pages1+0x92/0xd0 [snd_pcm] [f8bbc184] snd_pcm_lib_preallocate_pages_for_all+0x44/0x70 [snd_pcm] [f8be5030] snd_cs46xx_pcm_rear+0xe0/0x100 [snd_cs46xx] [f8be30f9] snd_card_cs46xx_probe+0xf9/0x250 [snd_cs46xx] [c01b9cbd] pci_match_device+0x1d/0xb0 [c01b9da8] __pci_device_probe+0x58/0x70 [c01b9def] pci_device_probe+0x2f/0x50 [c01fb168] driver_probe_device+0x38/0xb0 [c01fb270] __driver_attach+0x0/0x50 [c01fb2bc] __driver_attach+0x4c/0x50 [c01fa799] bus_for_each_dev+0x69/0x80 [c01fb2e6] driver_attach+0x26/0x30 [c01fb270] __driver_attach+0x0/0x50 [c01fac73] bus_add_driver+0x83/0xe0 [c01ba08d] pci_register_driver+0x6d/0x90 [f897e00f] alsa_card_cs46xx_init+0xf/0x13 [snd_cs46xx] [c012efb1] sys_init_module+0x141/0x1d0 [c0102c95] syscall_call+0x7/0xb 2.6.13-rc3-git9 is OK. I'll try poking around at the ALSA changes, see if I can figure out which one is the culprit. The procfs inode IDR tree is scrogged. I'd be suspecting a random memory scribble. I'd suggest that you enable CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_everything_else and retest. If that doesn't show anything, try eliminating stuff from your kernel config. If it _is_ a scribble then there's a good chance that changing the config will simply make it disappear, or will make it manifest in different ways. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
