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
Cal Peake wrote:
On Fri, 29 Jul 2005, Mickey Stein wrote:
This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
and gave it a test run. It had a bit of a problem and ground to a halt after
spewing these into the log.
If I can find the time tomorrow morning, I'll leave parport_pc commented out
of modprobe.conf and see if something else pops loose. I don't use the
parallel port, but I try to keep a fairly robust config for noticing bugs.
Hi Mick,
Can you please try the patch below from Linus (or -git2 tomorrow) and
confirm that it fixes it for you?
thx,
-cp
--- 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;
}
Linus Torvalds wrote:
On Fri, 29 Jul 2005, Mickey Stein wrote:
I've been quite low on time lately, so perhaps I missed something
obvious in the notes. When I did the "$make xconfig" , there were no
warnings about changes or new config params.
Does this fix it for you? (Already in the current git tree)
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;
}
I'm running on *-rc4 at the moment, so thanks very much for the patch.
I think there were ~3 of my modules producing similar output, but after
I followed someone's advice about enabling most of the CONFIG_DEBUG_*
switches, I experienced quite a bit more trouble getting anything to log
(or do anything but freeze). Now, all the modules are loading fine.
If I get time I'll probably be asking which of the 9 or 10 CONFIG_DEB*
switches are compatible with one another, but actually it may have just
been the same bug that would hang me up when they were on. I'll test
with the full CONFIG_DEBUG .config later on.
Appreciate it,
Mick
-
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
Cal Peake wrote:
On Fri, 29 Jul 2005, Mickey Stein wrote:
This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
and gave it a test run. It had a bit of a problem and ground to a halt after
spewing these into the log.
If I can find the time tomorrow morning, I'll leave parport_pc commented out
of modprobe.conf and see if something else pops loose. I don't use the
parallel port, but I try to keep a fairly robust config for noticing bugs.
Hi Mick,
Can you please try the patch below from Linus (or -git2 tomorrow) and
confirm that it fixes it for you?
thx,
-cp
--- 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;
}
Hi Cal,
I'll give that a go in about 30 minutes and report back, hopefully on
*rc4-* ;) . I'm not sure I'll be around in the morning so will apply
this to today's and see.
Thanks,
Mickey
-
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
Jesper Juhl <[EMAIL PROTECTED]> wrote: > > For the bennefit of those of us who were not at LKS, could someone > elaborate a bit on "the new release process" ? http://lwn.net/Articles/144281/ - 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
On Fri, 29 Jul 2005, Mickey Stein wrote:
> This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
> and gave it a test run. It had a bit of a problem and ground to a halt after
> spewing these into the log.
>
> If I can find the time tomorrow morning, I'll leave parport_pc commented out
> of modprobe.conf and see if something else pops loose. I don't use the
> parallel port, but I try to keep a fairly robust config for noticing bugs.
Hi Mick,
Can you please try the patch below from Linus (or -git2 tomorrow) and
confirm that it fixes it for you?
thx,
-cp
--- 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)
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
On 7/29/05, Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > > On 7/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > > Hey everybody, > > > > > > as many of you are aware, we were talking (not enough) about the > release > > > process at LKS this year. > > > > > > This ain't it. > > > > > > This is just the regular old release "process", with some LKS > backlog put > > > in for good measure. > > > > > > But the good news is, that I'll try the new release process after 2.6.13 > > > is out, which is hopefully not too far away. Which means that we should > > > try to let people know about the fact that if they want to merge stuff, > > > they should do so in the first two weeks after the 2.6.13 release, > and no > > > later (also, no earlier either, by now). > > > > > > > For the bennefit of those of us who were not at LKS, could someone > > elaborate a bit on "the new release process" ? > > > It's summarized here: > http://lwn.net/Articles/144281/ > Thank you for that link. It'll be interresting to see how that works out. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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
> On 7/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > Hey everybody, > > > > as many of you are aware, we were talking (not enough) about the release > > process at LKS this year. > > > > This ain't it. > > > > This is just the regular old release "process", with some LKS backlog put > > in for good measure. > > > > But the good news is, that I'll try the new release process after 2.6.13 > > is out, which is hopefully not too far away. Which means that we should > > try to let people know about the fact that if they want to merge stuff, > > they should do so in the first two weeks after the 2.6.13 release, and no > > later (also, no earlier either, by now). > > > > For the bennefit of those of us who were not at LKS, could someone > elaborate a bit on "the new release process" ? It's summarized here: http://lwn.net/Articles/144281/ --- ~Randy - 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
On 7/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > Hey everybody, > > as many of you are aware, we were talking (not enough) about the release > process at LKS this year. > > This ain't it. > > This is just the regular old release "process", with some LKS backlog put > in for good measure. > > But the good news is, that I'll try the new release process after 2.6.13 > is out, which is hopefully not too far away. Which means that we should > try to let people know about the fact that if they want to merge stuff, > they should do so in the first two weeks after the 2.6.13 release, and no > later (also, no earlier either, by now). > For the bennefit of those of us who were not at LKS, could someone elaborate a bit on "the new release process" ? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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
Hey everybody, as many of you are aware, we were talking (not enough) about the release process at LKS this year. This ain't it. This is just the regular old release "process", with some LKS backlog put in for good measure. But the good news is, that I'll try the new release process after 2.6.13 is out, which is hopefully not too far away. Which means that we should try to let people know about the fact that if they want to merge stuff, they should do so in the first two weeks after the 2.6.13 release, and no later (also, no earlier either, by now). So if you have a favourite kernel developer, please wake him up with a friendly kick to the head and explain this concept to him in small easy-to-understand words, and tell him that we're in the freeze process for 2.6.13 now, and that he should be gathering up the patches, and make sure they get to me _after_ 2.6.13 is out, but at that point do it in a timely manner. Ok? In the meantime, here's the 2.6.13-rc4 update, with a diffstat so horribly ugly that I won't even show it (the kernel list would eat it as too big anyway), and I'll have to go fix my code that generates it. Oh, and in case you wonder, it's ugly because a cris architecture update with long filenames that really causes git-apply to output som rather nasty-looking diffstats ;) ALSA, IB, NTFS, SCSI (qla2xxx) and the cris architecture update. Linus This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config and gave it a test run. It had a bit of a problem and ground to a halt after spewing these into the log. I'd say ; right after it did a "modprobe parport_pc". Actually I duplicated this today on rc4-git1 after yesterday's same experience with -rc4. With the .config file below, I did a grub boot (init 1). The dmesg from this was not so different, if at all, from my last working kernel. After this, I only did one test, which was a "$modprobe parport_pc" which produced the usual hundreds of trace msgs. I could modprobe some other modules without problem, i2c, snd_*, etc. The dmesg > 'file' is attached below. Config is attached below that. The only update from trying this yesterday was that with *git1, I did the modprobe in a more controlled fashion, and the system didn't hang on the modprobe. If I let it continue by doing an init 3, it does eventually freeze and I don't get more information of use in dmesg or the /var/log/m* file. I've been quite low on time lately, so perhaps I missed something obvious in the notes. When I did the "$make xconfig" , there were no warnings about changes or new config params. The two mentioned files are on as attachments. Some other details: mainboard: nf7 (abit nforce2 chipset) last kernel before *rc4 that was running well with the identical config: 2.6.13-rc3-git7 Using mem=4g and associated parms to get my full 1g. Version rawhide: Up to date as of yesterday (27-Jul) If I can find the time tomorrow morning, I'll leave parport_pc commented out of modprobe.conf and see if something else pops loose. I don't use the parallel port, but I try to keep a fairly robust config for noticing bugs. Mick --attached files-- :02:00.0 PCI: Discovered primary peer bus ff [IRQ] PCI: Using IRQ router default [10de/01e0] at :00:00.0 PCI: Bridge: :00:08.0 IO window: disabled. MEM window: eb00-ebff PREFETCH window: disabled. PCI: Bridge: :00:1e.0 IO window: disabled. MEM window: e800-eaff PREFETCH window: d000-dfff PCI: Setting latency timer of device :00:08.0 to 64 apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac) highmem bounce pool size: 64 pages VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API vga16fb: initializing vga16fb: mapped to 0xc00a fb0: VGA16 VGA frame buffer device isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Real Time Clock Driver v1.12 Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected NVIDIA nForce2 chipset agpgart: AGP aperture is 128M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 PNP: PS/2 controller doesn't have AUX irq; using default 0xc PNP: PS/2 Controller [PNP0303] at 0x60,0x64 irq 112 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NFORCE2: IDE controller at PCI slot :00:09.0 NFORCE2: chipset revision 162 NFORCE2: not 100% native mode: will probe irqs later NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround. NFORCE2: :00:09.0 (rev a2) UDMA133 controller ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Re: Linux 2.6.13-rc4
Hey everybody, as many of you are aware, we were talking (not enough) about the release process at LKS this year. This ain't it. This is just the regular old release process, with some LKS backlog put in for good measure. But the good news is, that I'll try the new release process after 2.6.13 is out, which is hopefully not too far away. Which means that we should try to let people know about the fact that if they want to merge stuff, they should do so in the first two weeks after the 2.6.13 release, and no later (also, no earlier either, by now). So if you have a favourite kernel developer, please wake him up with a friendly kick to the head and explain this concept to him in small easy-to-understand words, and tell him that we're in the freeze process for 2.6.13 now, and that he should be gathering up the patches, and make sure they get to me _after_ 2.6.13 is out, but at that point do it in a timely manner. Ok? In the meantime, here's the 2.6.13-rc4 update, with a diffstat so horribly ugly that I won't even show it (the kernel list would eat it as too big anyway), and I'll have to go fix my code that generates it. Oh, and in case you wonder, it's ugly because a cris architecture update with long filenames that really causes git-apply to output som rather nasty-looking diffstats ;) ALSA, IB, NTFS, SCSI (qla2xxx) and the cris architecture update. Linus This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config and gave it a test run. It had a bit of a problem and ground to a halt after spewing these into the log. I'd say ; right after it did a modprobe parport_pc. Actually I duplicated this today on rc4-git1 after yesterday's same experience with -rc4. With the .config file below, I did a grub boot (init 1). The dmesg from this was not so different, if at all, from my last working kernel. After this, I only did one test, which was a $modprobe parport_pc which produced the usual hundreds of trace msgs. I could modprobe some other modules without problem, i2c, snd_*, etc. The dmesg 'file' is attached below. Config is attached below that. The only update from trying this yesterday was that with *git1, I did the modprobe in a more controlled fashion, and the system didn't hang on the modprobe. If I let it continue by doing an init 3, it does eventually freeze and I don't get more information of use in dmesg or the /var/log/m* file. I've been quite low on time lately, so perhaps I missed something obvious in the notes. When I did the $make xconfig , there were no warnings about changes or new config params. The two mentioned files are on as attachments. Some other details: mainboard: nf7 (abit nforce2 chipset) last kernel before *rc4 that was running well with the identical config: 2.6.13-rc3-git7 Using mem=4g and associated parms to get my full 1g. Version rawhide: Up to date as of yesterday (27-Jul) If I can find the time tomorrow morning, I'll leave parport_pc commented out of modprobe.conf and see if something else pops loose. I don't use the parallel port, but I try to keep a fairly robust config for noticing bugs. Mick --attached files-- :02:00.0 PCI: Discovered primary peer bus ff [IRQ] PCI: Using IRQ router default [10de/01e0] at :00:00.0 PCI: Bridge: :00:08.0 IO window: disabled. MEM window: eb00-ebff PREFETCH window: disabled. PCI: Bridge: :00:1e.0 IO window: disabled. MEM window: e800-eaff PREFETCH window: d000-dfff PCI: Setting latency timer of device :00:08.0 to 64 apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac) highmem bounce pool size: 64 pages VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API vga16fb: initializing vga16fb: mapped to 0xc00a fb0: VGA16 VGA frame buffer device isapnp: Scanning for PnP cards... isapnp: No Plug Play device found Real Time Clock Driver v1.12 Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected NVIDIA nForce2 chipset agpgart: AGP aperture is 128M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 PNP: PS/2 controller doesn't have AUX irq; using default 0xc PNP: PS/2 Controller [PNP0303] at 0x60,0x64 irq 112 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NFORCE2: IDE controller at PCI slot :00:09.0 NFORCE2: chipset revision 162 NFORCE2: not 100% native mode: will probe irqs later NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround. NFORCE2: :00:09.0 (rev a2) UDMA133 controller ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA ide1:
Re: Linux 2.6.13-rc4
On 7/29/05, Linus Torvalds [EMAIL PROTECTED] wrote: Hey everybody, as many of you are aware, we were talking (not enough) about the release process at LKS this year. This ain't it. This is just the regular old release process, with some LKS backlog put in for good measure. But the good news is, that I'll try the new release process after 2.6.13 is out, which is hopefully not too far away. Which means that we should try to let people know about the fact that if they want to merge stuff, they should do so in the first two weeks after the 2.6.13 release, and no later (also, no earlier either, by now). For the bennefit of those of us who were not at LKS, could someone elaborate a bit on the new release process ? -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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
On 7/29/05, Linus Torvalds [EMAIL PROTECTED] wrote: Hey everybody, as many of you are aware, we were talking (not enough) about the release process at LKS this year. This ain't it. This is just the regular old release process, with some LKS backlog put in for good measure. But the good news is, that I'll try the new release process after 2.6.13 is out, which is hopefully not too far away. Which means that we should try to let people know about the fact that if they want to merge stuff, they should do so in the first two weeks after the 2.6.13 release, and no later (also, no earlier either, by now). For the bennefit of those of us who were not at LKS, could someone elaborate a bit on the new release process ? It's summarized here: http://lwn.net/Articles/144281/ --- ~Randy - 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
On 7/29/05, Randy Dunlap [EMAIL PROTECTED] wrote: On 7/29/05, Linus Torvalds [EMAIL PROTECTED] wrote: Hey everybody, as many of you are aware, we were talking (not enough) about the release process at LKS this year. This ain't it. This is just the regular old release process, with some LKS backlog put in for good measure. But the good news is, that I'll try the new release process after 2.6.13 is out, which is hopefully not too far away. Which means that we should try to let people know about the fact that if they want to merge stuff, they should do so in the first two weeks after the 2.6.13 release, and no later (also, no earlier either, by now). For the bennefit of those of us who were not at LKS, could someone elaborate a bit on the new release process ? It's summarized here: http://lwn.net/Articles/144281/ Thank you for that link. It'll be interresting to see how that works out. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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
On Fri, 29 Jul 2005, Mickey Stein wrote:
This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
and gave it a test run. It had a bit of a problem and ground to a halt after
spewing these into the log.
If I can find the time tomorrow morning, I'll leave parport_pc commented out
of modprobe.conf and see if something else pops loose. I don't use the
parallel port, but I try to keep a fairly robust config for noticing bugs.
Hi Mick,
Can you please try the patch below from Linus (or -git2 tomorrow) and
confirm that it fixes it for you?
thx,
-cp
--- 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
Jesper Juhl [EMAIL PROTECTED] wrote: For the bennefit of those of us who were not at LKS, could someone elaborate a bit on the new release process ? http://lwn.net/Articles/144281/ - 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
Cal Peake wrote:
On Fri, 29 Jul 2005, Mickey Stein wrote:
This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
and gave it a test run. It had a bit of a problem and ground to a halt after
spewing these into the log.
If I can find the time tomorrow morning, I'll leave parport_pc commented out
of modprobe.conf and see if something else pops loose. I don't use the
parallel port, but I try to keep a fairly robust config for noticing bugs.
Hi Mick,
Can you please try the patch below from Linus (or -git2 tomorrow) and
confirm that it fixes it for you?
thx,
-cp
--- 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;
}
Hi Cal,
I'll give that a go in about 30 minutes and report back, hopefully on
*rc4-* ;) . I'm not sure I'll be around in the morning so will apply
this to today's and see.
Thanks,
Mickey
-
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
Cal Peake wrote:
On Fri, 29 Jul 2005, Mickey Stein wrote:
This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
and gave it a test run. It had a bit of a problem and ground to a halt after
spewing these into the log.
If I can find the time tomorrow morning, I'll leave parport_pc commented out
of modprobe.conf and see if something else pops loose. I don't use the
parallel port, but I try to keep a fairly robust config for noticing bugs.
Hi Mick,
Can you please try the patch below from Linus (or -git2 tomorrow) and
confirm that it fixes it for you?
thx,
-cp
--- 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;
}
Linus Torvalds wrote:
On Fri, 29 Jul 2005, Mickey Stein wrote:
I've been quite low on time lately, so perhaps I missed something
obvious in the notes. When I did the $make xconfig , there were no
warnings about changes or new config params.
Does this fix it for you? (Already in the current git tree)
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;
}
I'm running on *-rc4 at the moment, so thanks very much for the patch.
I think there were ~3 of my modules producing similar output, but after
I followed someone's advice about enabling most of the CONFIG_DEBUG_*
switches, I experienced quite a bit more trouble getting anything to log
(or do anything but freeze). Now, all the modules are loading fine.
If I get time I'll probably be asking which of the 9 or 10 CONFIG_DEB*
switches are compatible with one another, but actually it may have just
been the same bug that would hang me up when they were on. I'll test
with the full CONFIG_DEBUG .config later on.
Appreciate it,
Mick
-
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/
Linux 2.6.13-rc4
2: Make the UARTs on MPC824x individual platform devices
ppc32: Add proper prototype for cpm2_reset()
I2C-MPC: Restore code removed
Kurt Wall:
Add text for dealing with "dot releases" to README
Kyle Moffett:
[NET]: Fix setsockopt locking bug
Linda Xie:
[SCSI] IBM VSCSI Client: sending client info to server
Linus Torvalds:
Linux 2.6.13-rc4
Revert broken "statement with no effect" warning fix
Merge master.kernel.org:/.../perex/alsa
Merge master.kernel.org:/.../davem/sparc-2.6
Fix up qla2xxx configuration bogosity
Merge head 'for-linus' of master.kernel.org:/.../shaggy/jfs-2.6
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/.../aegl/linux-2.6
Merge master.kernel.org:/home/rmk/linux-2.6-arm-smp
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/home/rmk/linux-2.6-arm
Merge master.kernel.org:/home/rmk/linux-2.6-arm-smp
Fix compiler warning in qla_iocb.c
Merge master.kernel.org:/.../jejb/scsi-for-linus-2.6
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/.../davem/sparc-2.6
Merge master.kernel.org:/home/rmk/linux-2.6-serial
Merge master.kernel.org:/home/rmk/linux-2.6-arm
Remove "noreplacement" kernel command line option.
x86: use alternative instructions for fnsave/fxsave too
Merge master.kernel.org:/.../davem/net-2.6
x86: make restore_fpu() use alternative assembler instructions
Fix up incorrect "unlikely()" on %gs reload in x86 __switch_to
Merge master.kernel.org:/home/rmk/linux-2.6-serial
Merge master.kernel.org:/home/rmk/linux-2.6-arm
Merge master.kernel.org:/.../aia21/ntfs-2.6
Merge master.kernel.org:/.../tglx/mtd-2.6
Merge master.kernel.org:/.../aegl/linux-2.6
Merge master.kernel.org:/.../aegl/linux-2.6
Merge master.kernel.org:/.../tglx/mtd-2.6
Merge head 'for-linus' of master.kernel.org:/.../shaggy/jfs-2.6
Merge /home/torvalds/linux-2.6-arm
Loic Le Loarer:
[EQL]: Proper num_slaves decrement
Lucas Correia Villa Real:
ARM: 2825/1: S3C2410: turns %d into %ld on DMA printk
Luming Yu:
/home/lenb/linux-2.6 branch 'acpi-2.6.12'
ACPI: delete unnecessary EC console messages
Marcel Selhorst:
tpm: Support for Infineon TPM
Marcelo Feitoza Parisi:
[ATM]: [idt77252] use time_after() macro
[NET PCMCIA]: drivers/net/pcmcia/smc91c92_cs.c : Use of time_after macro
[WAN]: drivers/net/wan/: use of time_after macro
Marcelo Tosatti:
ppc32: 8xx remove BROKEN Kconfig entry
cpm_uart: use DPRAM for early console
ppc32: 8xx: update DataTLBMiss exception comment
Mark Haverkamp:
[SCSI] aacraid: Fix sgmap error
[SCSI] aacraid: New products patch
Martin Schwidefsky:
s390: find_next_{zero}_bit fixes
s390: spin lock retry
s390: fadvise hint values.
Matt:
[ALSA] hda: add sigmatel hp detect support
[ALSA] hda: enable unsolicited responses
[ALSA] hda-codec - SigmaTel HDA resume support
[ALSA] hda-codec - SigmaTel HDA multichannel support
Matt Mackall:
[NET]: Move in_aton from net/ipv4/utils.c to net/core/utils.c
Matt Porter:
ppc32: fix dma_map_page() to use page_to_bus()
Matthias Urlichs:
Option Card driver update, Maintainer entry
Mauro Carvalho Chehab:
v4l: bug fixes for tuner, cx88 and tea5767
Michael Burian:
ARM: 2794/1: Add "Image" and "mach-types.h" to dontdiff list
Michael Chan:
[TG3]: add 5780 fiber support
[TG3]: disallow jumbo TSO on 5780
[TG3]: consolidate all DMA water mark settings
[TG3]: add variable buffer size for standard ring
[TG3]: add 5780 basic jumbo frame support
[TG3]: add 5780 basic support
Michael Gernoth:
ARM: 2830/1: Fix Jornada 720 PCMCIA-support
Michael Hunold:
v4l: fix tuning with MXB driver
Michael Krufky:
dvb: rename lgdt3302 frontend module to lgdt330x
v4l: hybrid dvb: rename CFLAGS from CONFIG_DVB_ back to original HAVE_
v4l: hybrid dvb: move #defines to Makefile
v4l: hybrid dvb: fix warnings with -Wundef
dvb/v4l: cx88 cleanup
lgdt3302: warning fix
dvb/4vl: RF input selection fir
dvb/v4l: lgdt3302: isolate tuner
v4l: fix regression modprobe bttv freezes the computer
dvb: LGDT3302 QAM lock bug fix
Michael S. Tsirkin:
[IB/mthca]: Use io_remap_pfn_range for PCI space
Michal Januszewski:
fbdev: update info->cmap when setting cmap from user-/kernelspace.
fbcon: don't repaint the cursor when it is disabled.
Michal Ostrowski:
rocket.c: Fix ldisc ref count handling
Mikael Starvik:
CRIS IDE driver
CRIS update: new subarchitecture v32
CRIS update: updates for 2.6.12
CRIS update: synchronous serial port driver
CRIS update: SMP
CRIS update: profiler
CRIS update: pci
CRIS update: mm
CRIS update: misc patches
CRIS update: IRQ
CRIS update: I/O and DMA allocator
CRIS update: drivers
CRIS update: debug
CRIS update: console
CRIS update: configuration and build
CRIS update: arch split
Mike Miller:
cciss per disk queue
Miles Bader:
v850: Define L1_CACHE_SHIFT and L1_CACH
Linux 2.6.13-rc4
prototype for cpm2_reset()
I2C-MPC: Restore code removed
Kurt Wall:
Add text for dealing with dot releases to README
Kyle Moffett:
[NET]: Fix setsockopt locking bug
Linda Xie:
[SCSI] IBM VSCSI Client: sending client info to server
Linus Torvalds:
Linux 2.6.13-rc4
Revert broken statement with no effect warning fix
Merge master.kernel.org:/.../perex/alsa
Merge master.kernel.org:/.../davem/sparc-2.6
Fix up qla2xxx configuration bogosity
Merge head 'for-linus' of master.kernel.org:/.../shaggy/jfs-2.6
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/.../aegl/linux-2.6
Merge master.kernel.org:/home/rmk/linux-2.6-arm-smp
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/home/rmk/linux-2.6-arm
Merge master.kernel.org:/home/rmk/linux-2.6-arm-smp
Fix compiler warning in qla_iocb.c
Merge master.kernel.org:/.../jejb/scsi-for-linus-2.6
Merge master.kernel.org:/.../davem/net-2.6
Merge master.kernel.org:/.../davem/sparc-2.6
Merge master.kernel.org:/home/rmk/linux-2.6-serial
Merge master.kernel.org:/home/rmk/linux-2.6-arm
Remove noreplacement kernel command line option.
x86: use alternative instructions for fnsave/fxsave too
Merge master.kernel.org:/.../davem/net-2.6
x86: make restore_fpu() use alternative assembler instructions
Fix up incorrect unlikely() on %gs reload in x86 __switch_to
Merge master.kernel.org:/home/rmk/linux-2.6-serial
Merge master.kernel.org:/home/rmk/linux-2.6-arm
Merge master.kernel.org:/.../aia21/ntfs-2.6
Merge master.kernel.org:/.../tglx/mtd-2.6
Merge master.kernel.org:/.../aegl/linux-2.6
Merge master.kernel.org:/.../aegl/linux-2.6
Merge master.kernel.org:/.../tglx/mtd-2.6
Merge head 'for-linus' of master.kernel.org:/.../shaggy/jfs-2.6
Merge /home/torvalds/linux-2.6-arm
Loic Le Loarer:
[EQL]: Proper num_slaves decrement
Lucas Correia Villa Real:
ARM: 2825/1: S3C2410: turns %d into %ld on DMA printk
Luming Yu:
/home/lenb/linux-2.6 branch 'acpi-2.6.12'
ACPI: delete unnecessary EC console messages
Marcel Selhorst:
tpm: Support for Infineon TPM
Marcelo Feitoza Parisi:
[ATM]: [idt77252] use time_after() macro
[NET PCMCIA]: drivers/net/pcmcia/smc91c92_cs.c : Use of time_after macro
[WAN]: drivers/net/wan/: use of time_after macro
Marcelo Tosatti:
ppc32: 8xx remove BROKEN Kconfig entry
cpm_uart: use DPRAM for early console
ppc32: 8xx: update DataTLBMiss exception comment
Mark Haverkamp:
[SCSI] aacraid: Fix sgmap error
[SCSI] aacraid: New products patch
Martin Schwidefsky:
s390: find_next_{zero}_bit fixes
s390: spin lock retry
s390: fadvise hint values.
Matt:
[ALSA] hda: add sigmatel hp detect support
[ALSA] hda: enable unsolicited responses
[ALSA] hda-codec - SigmaTel HDA resume support
[ALSA] hda-codec - SigmaTel HDA multichannel support
Matt Mackall:
[NET]: Move in_aton from net/ipv4/utils.c to net/core/utils.c
Matt Porter:
ppc32: fix dma_map_page() to use page_to_bus()
Matthias Urlichs:
Option Card driver update, Maintainer entry
Mauro Carvalho Chehab:
v4l: bug fixes for tuner, cx88 and tea5767
Michael Burian:
ARM: 2794/1: Add Image and mach-types.h to dontdiff list
Michael Chan:
[TG3]: add 5780 fiber support
[TG3]: disallow jumbo TSO on 5780
[TG3]: consolidate all DMA water mark settings
[TG3]: add variable buffer size for standard ring
[TG3]: add 5780 basic jumbo frame support
[TG3]: add 5780 basic support
Michael Gernoth:
ARM: 2830/1: Fix Jornada 720 PCMCIA-support
Michael Hunold:
v4l: fix tuning with MXB driver
Michael Krufky:
dvb: rename lgdt3302 frontend module to lgdt330x
v4l: hybrid dvb: rename CFLAGS from CONFIG_DVB_ back to original HAVE_
v4l: hybrid dvb: move #defines to Makefile
v4l: hybrid dvb: fix warnings with -Wundef
dvb/v4l: cx88 cleanup
lgdt3302: warning fix
dvb/4vl: RF input selection fir
dvb/v4l: lgdt3302: isolate tuner
v4l: fix regression modprobe bttv freezes the computer
dvb: LGDT3302 QAM lock bug fix
Michael S. Tsirkin:
[IB/mthca]: Use io_remap_pfn_range for PCI space
Michal Januszewski:
fbdev: update info-cmap when setting cmap from user-/kernelspace.
fbcon: don't repaint the cursor when it is disabled.
Michal Ostrowski:
rocket.c: Fix ldisc ref count handling
Mikael Starvik:
CRIS IDE driver
CRIS update: new subarchitecture v32
CRIS update: updates for 2.6.12
CRIS update: synchronous serial port driver
CRIS update: SMP
CRIS update: profiler
CRIS update: pci
CRIS update: mm
CRIS update: misc patches
CRIS update: IRQ
CRIS update: I/O and DMA allocator
CRIS update: drivers
CRIS update: debug
CRIS update: console
CRIS update: configuration and build
CRIS update: arch split
Mike Miller:
cciss per disk queue
Miles Bader:
v850: Define L1_CACHE_SHIFT and L1_CACHE_SHIFT_MAX
v850: Update PCI support
v850: Add pte_file
v850: Update ioremap return type and add ioread/iowrite functions
v850: Add defconfigs
v850: const
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/
