Re: kernel BUG at ll_rw_blk.c:711

2000-09-30 Thread Martin Costabel

Christoph Simon wrote:
[]
> kernel BUG at ll_rw_blk.c:711!
[]
> prepare such an event to make it reproducible. In both cases, please
> CC to me, as I'm not on this list.

If you look at the lkml archives at
http://boudicca.tux.org/hypermail/linux-kernel/, for example, you see
this same thread every couple of days since -test8 came out 3 weeks ago
(2000week37). Fixes have been posted, and -test9pre1 contains a fix.
IMHO, the latest reasonably stable 2.4.0 kernel is 2.4.0-test9pre1 and
not 2.4.0-test8. 

I find it pretty weird that such a manifestly buggy kernel version has
remained the "official" 2.4 kernel for more than 3 weeks now.

--
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



kernel BUG at ll_rw_blk.c:711

2000-09-30 Thread Christoph Simon


This is the first time in a long time I'm experiencing problems with
the Linux kernel. A wonderful job. The backside is that it's also a
very long time ago since the last time I read (parts of) the kernel.

One of my users complained of netscape hanging frequently while
reading news. I tried to find out what was happening and found
netscape in the ``uninterruptible sleep' state. When checking dmesg I
found this message:

-----------
kernel BUG at ll_rw_blk.c:711!
invalid operand: 
CPU:0
EIP:0010:[]
EFLAGS: 00210282
eax: 001f   ebx: c15853c0   ecx: c1377180   edx: 
esi: c15853c0   edi: c02b9760   ebp: 0001   esp: c39a3ea8
ds: 0018   es: 0018   ss: 0018
Process communicator-sm (pid: 1415, stackpage=c39a3000)
Stack: c0207405 c02076a2 02c7 c15853c0 0001 000c  c135fd54 
   c02b9778 c02b9770  0008   c0167f22 00fe 
   c0168b81 c02b9760 0001 c15853c0 c15853c0  0001 c39a3f38 
Call Trace: [] [] [] [] [] 
[] []
   [] [] [] [] [] 
[]
Code: 0f 0b 83 c4 0c 90 0f b6 46 15 0f b7 4e 14 8b 14 85 e0 dc 2a
---

Well, if the kernel says it's a bug, it'll be a bug, right? But I
really don't know what to do with this. I checked out that line and
got the message that this is something for 2.5. The kernel is
2.4.0pre8 using APIC on a mono CPU, compiled with gcc 2.95.2,
debian/woody box (Athlon CPU, Biostar motherboard, VIA chipset).

I wonder if there is anything I can do in this situation beside
switching off APIC and waiting for 2.5.0. The bad thing is, that after
this has happened, sync, shutdown (and some other programs?) also fall
asleep, forcing me to powercycle the computer. I can't really tell how
to reproduce the problem, but as it is popping up quite frequently, a
more knowledable writer on this list might be able to tell me how to
prepare such an event to make it reproducible. In both cases, please
CC to me, as I'm not on this list.

TIA
Christoph


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



kernel BUG at ll_rw_blk.c:711!

2000-09-25 Thread Alvaro Lopes

Just got this one:

Sep 25 18:02:01 thecrypt kernel: kernel BUG at ll_rw_blk.c:711!
Sep 25 18:02:01 thecrypt kernel: invalid operand: 
Sep 25 18:02:01 thecrypt kernel: CPU:0
Sep 25 18:02:01 thecrypt kernel: EIP:0010:[__make_request+161/1444]
Sep 25 18:02:01 thecrypt kernel: EFLAGS: 00210282
Sep 25 18:02:01 thecrypt kernel: eax: 001f   ebx: c0f1cb00   ecx:
c39224a0   edx: 0006
Sep 25 18:02:01 thecrypt kernel: esi: c0f1cb00   edi: c02d0c20   ebp:
0001   esp: c4323ea8
Sep 25 18:02:01 thecrypt kernel: ds: 0018   es: 0018   ss: 0018
Sep 25 18:02:01 thecrypt kernel: Process communicator-sm (pid: 2815,
stackpage=c4323000)
Sep 25 18:02:01 thecrypt kernel: Stack: c021f1a5 c021f442 02c7
c0f1cb00 0001 000c  001e8480 
Sep 25 18:02:01 thecrypt kernel:c02d0c38 c02d0c30 
0002   c01563c2 00fe 
Sep 25 18:02:01 thecrypt kernel:c0156f81 c02d0c20 0001
c0f1cb00 c0f1cb00  0001 c4323f38 
Sep 25 18:02:01 thecrypt kernel: Call Trace: [tvecs+49309/72568]
[tvecs+49978/72568] [blk_get_queue+50/64] [generic_make_request+257/272]
[ll_rw_block+337/448] [writeout_one_page+57/80]
[do_buffer_fdatasync+72/124] 
Sep 25 18:02:01 thecrypt kernel:[generic_buffer_fdatasync+29/56]
[writeout_one_page+0/80] [ext2_sync_file+47/164] [sys_write+139/160]
[sys_fsync+73/104] [system_call+51/56] 
Sep 25 18:02:01 thecrypt kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7
4e 14 8b 14 85 a0 52 2c c0 

Kernel is 2.4.0-test8
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Oops: kernel BUG at ll_rw_blk.c:711! despite patch.

2000-09-22 Thread Bennett Feitell

Here is the ksymoops decode.  This Oops occurs fairly often even after
applying the patch (appended here following the oops), before the patch the
file system was generally extremely slow.  The patch was posted by David S.
Miller as a fix for a known bug and may be found at:

http://x58.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=669208918&threaded=1&CONTEXT=969683703.1203175464&hitnum=11

The patch seems to take care of Netscape falling into a Zombie state with
the system unable to shutdown, CTRL-ALT-SYSRQ-S and then CTRL-ALT-SYSRQ-U
fails to save the file system from an fsck on forcible reboot when in this
state.

The system is a K6-2+/FIC va503+/128MB Which was completely stable under
2.4.0-test7.

I hope this helps someone, if more info is needed please ask.  I have pre
patch oopses of this nature floating in my logs.

Regards,

Bennett Feitell

--START Of Oops--

[root@bfeitell log]# ksymoops -m /boot/System.map-2.4.0-test8 latest.oops
ksymoops 0.7c on i586 2.4.0-test8.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test8/ (default)
 -m /boot/System.map-2.4.0-test8 (specified)

Sep 23 00:07:14 bfeitell kernel: invalid operand: 
Sep 23 00:07:14 bfeitell kernel: CPU:0
Sep 23 00:07:14 bfeitell kernel: EIP:0010:[__make_request+178/1556]
Sep 23 00:07:14 bfeitell kernel: EFLAGS: 00010296
Sep 23 00:07:14 bfeitell kernel: eax: 001f   ebx: c291a5c0   ecx:
c6332820   edx: 0002
Sep 23 00:07:14 bfeitell kernel: esi: c291a5c0   edi:    ebp:
c02e5a00   esp: c4e13e94
Sep 23 00:07:14 bfeitell kernel: ds: 0018   es: 0018   ss: 0018
Sep 23 00:07:14 bfeitell kernel: Process netscape (pid: 694,
stackpage=c4e13000)
Sep 23 00:07:14 bfeitell kernel: Stack: c0240685 c0240922 02c7 c291a5c0
0002 000c 000
0 00c0
Sep 23 00:07:14 bfeitell kernel:0002 c02e5a10 001e8480 c02e5a18
c02e5a10  000
2 
Sep 23 00:07:14 bfeitell kernel: c0187824 00fe c018841d
c02e5a00 0001 c291a5c
datasync+73/120]
Sep 23 00:07:14 bfeitell kernel: Code: 0f 0b 83 c4 0c 90 66 8b 5e 14 0f b6
46 15 8b 14 85 80 a0 2d
Using defaults from ksymoops -t elf32-i386 -a i386
 
Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   0f 0b ud2a
Code;  0002 Before first symbol
   2:   83 c4 0c  add$0xc,%esp
Code;  0005 Before first symbol
   5:   90nop
Code;  0006 Before first symbol
   6:   66 8b 5e 14   mov0x14(%esi),%bx
Code;  000a Before first symbol
   a:   0f b6 46 15   movzbl 0x15(%esi),%eax
Code;  000e Before first symbol
   e:   8b 14 85 80 a0 2d 00  mov0x2da080(,%eax,4),%edx

--END of Oops--

--Start of Patch--

--- vanilla/linux/fs/buffer.c   Wed Sep  6 08:29:45 2000
+++ linux/fs/buffer.c   Sun Sep 10 17:25:26 2000
@@ -1758,13 +1758,13 @@
pos += blocksize;
}
 
+   err = 0;
+   if (!buffer_mapped(bh)) {
+   get_block(inode, iblock, bh, 0);
+   if (!buffer_mapped(bh))
+   goto unlock;
+   }
if (!buffer_uptodate(bh)) {
-   err = 0;
-   if (!buffer_mapped(bh)) {
-   get_block(inode, iblock, bh, 0);
-   if (!buffer_mapped(bh))
-   goto unlock;
-   }
err = -EIO;
bh->b_end_io = end_buffer_io_sync;
ll_rw_block(READ, 1, &bh);

--End of Patch--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



kernel BUG at ll_rw_blk.c:711!

2000-09-18 Thread Mike Civil

[NB. following may not be relevant as seen on box with known upper 32MB
of 128MB DIMM faulty and not in use via mem=96MB]

Oops obtained when exiting Staroffice 5.2. Relevant procs left in
unkillable state :-

  F S UIDPID  PPID   CLS PRI ADDR SZ WCHAN  STIME TTY  TIME CMD
144 Z root 4 1 -  30 - 0 do_exi 19:38 ?00:00:00 [kupdate 
]
000 D mike  3925 1 -  30 - 25091 wait_o 21:28 tty3 00:00:58 
/usr/local/office52/program/soffice.bin
444 Z mike  3943  3925 -  30 - 0 do_exi 21:28 tty3 00:00:00 
[soffice.bin ]

gcc version 2.95.2 19991024 (release)

ksymoops 2.3.4 on i686 2.4.0-test8.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test8/ (default)
 -m /boot/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Sep 18 21:42:39 duncodin kernel: invalid operand: 
Sep 18 21:42:39 duncodin kernel: CPU:0
Sep 18 21:42:39 duncodin kernel: EIP:0010:[__make_request+159/1452]
Sep 18 21:42:39 duncodin kernel: EFLAGS: 00010286
Sep 18 21:42:39 duncodin kernel: eax: 001f   ebx: c05f6540   ecx:    edx: 

Sep 18 21:42:39 duncodin kernel: esi: c05f6540   edi: c11cfd78   ebp: 0001   esp: 
c11c9f34
Sep 18 21:42:39 duncodin kernel: ds: 0018   es: 0018   ss: 0018
Sep 18 21:42:39 duncodin kernel: Process kupdate (pid: 4, stackpage=c11c9000)
Sep 18 21:42:39 duncodin kernel: Stack: c01d9265 c01d9502 02c7 c05f6540 0001 
0020  001e8480
Sep 18 21:42:39 duncodin kernel:c11cfd90 c11cfd88  0002  
 c01517e7 00fe
Sep 18 21:42:39 duncodin kernel:c01523cc c11cfd78 0001 c05f6540 c05f6540 
 0001 c11c9fd0
Sep 18 21:42:40 duncodin kernel: Call Trace: [tvecs+42909/49816] [tvecs+43578/49816] 
[blk_get_queue+55/72] [generic_make_request+272/284] [ll_rw_block+347/460] 
[flush_dirty_buffers+130/180] [tvecs+13678/49816]
Sep 18 21:42:40 duncodin kernel: Code: 0f 0b 83 c4 0c 66 8b 4e 14 31 c0 8a 46 15 8b 14 
85 c0 8c 26
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   0f 0b ud2a   
Code;  0002 Before first symbol
   2:   83 c4 0c  add$0xc,%esp
Code;  0005 Before first symbol
   5:   66 8b 4e 14   mov0x14(%esi),%cx
Code;  0009 Before first symbol
   9:   31 c0 xor%eax,%eax
Code;  000b Before first symbol
   b:   8a 46 15  mov0x15(%esi),%al
Code;  000e Before first symbol
   e:   8b 14 85 c0 8c 26 00  mov0x268cc0(,%eax,4),%edx


1 warning issued.  Results may not be reliable.
-- 
Mike CivilHome  : [EMAIL PROTECTED]
Broadmayne, Dorset, UKWork  : [EMAIL PROTECTED]
+44 (0)1305 853644
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: kernel BUG at ll_rw_blk.c:711!

2000-09-13 Thread Rik van Riel

On Wed, 13 Sep 2000, David S. Miller wrote:

> Known bug, Linus just hasn't made a pre-patch in a long
> time with the fix.  Here is the fix:

I'd like to confirm that this patch is /needed/ to keep
my system running with 2.4.0-test8...

> --- vanilla/linux/fs/buffer.c Wed Sep  6 08:29:45 2000
> +++ linux/fs/buffer.c Sun Sep 10 17:25:26 2000
> @@ -1758,13 +1758,13 @@
>   pos += blocksize;
>   }
>  
> + err = 0;
> + if (!buffer_mapped(bh)) {
> + get_block(inode, iblock, bh, 0);
> + if (!buffer_mapped(bh))
> + goto unlock;
> + }
>   if (!buffer_uptodate(bh)) {
> - err = 0;
> - if (!buffer_mapped(bh)) {
> - get_block(inode, iblock, bh, 0);
> - if (!buffer_mapped(bh))
> - goto unlock;
> - }
>   err = -EIO;
>   bh->b_end_io = end_buffer_io_sync;
>   ll_rw_block(READ, 1, &bh);

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: kernel BUG at ll_rw_blk.c:711!

2000-09-13 Thread Eloy Paris

Thanks Dave.

I normally would have seen the patch floating around in linux-kernel,
but I check the archives on kernelnotes.org and the archives have not
been working since last Sep. 8.

Cheers!

Eloy.-

On Wed, 13 Sep 2000, David S. Miller wrote:

> 
> Known bug, Linus just hasn't made a pre-patch in a long
> time with the fix.  Here is the fix:
> 
> --- vanilla/linux/fs/buffer.c Wed Sep  6 08:29:45 2000
> +++ linux/fs/buffer.c Sun Sep 10 17:25:26 2000
> @@ -1758,13 +1758,13 @@
>   pos += blocksize;
>   }
>  
> + err = 0;
> + if (!buffer_mapped(bh)) {
> + get_block(inode, iblock, bh, 0);
> + if (!buffer_mapped(bh))
> + goto unlock;
> + }
>   if (!buffer_uptodate(bh)) {
> - err = 0;
> - if (!buffer_mapped(bh)) {
> - get_block(inode, iblock, bh, 0);
> - if (!buffer_mapped(bh))
> - goto unlock;
> - }
>   err = -EIO;
>   bh->b_end_io = end_buffer_io_sync;
>   ll_rw_block(READ, 1, &bh);
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: kernel BUG at ll_rw_blk.c:711!

2000-09-13 Thread Petko Manolov

"Eloy A. Paris" wrote:
> 
> Hi!
> 
> I got an Oops with 2.4.0test8. The message written to syslog said:
> 
> Sep 13 02:51:49 antenas kernel: kernel BUG at ll_rw_blk.c:711!
> 
> This machine has 128MBytes of memory and at the time of the Opps I was
> running Netscape and a big find was running in the background as well


I got the same error at the same circumstances (test8, debian and
netscape-4.75).

I can send the oops if needed.


best,
Petkan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: kernel BUG at ll_rw_blk.c:711!

2000-09-13 Thread David S. Miller


Known bug, Linus just hasn't made a pre-patch in a long
time with the fix.  Here is the fix:

--- vanilla/linux/fs/buffer.c   Wed Sep  6 08:29:45 2000
+++ linux/fs/buffer.c   Sun Sep 10 17:25:26 2000
@@ -1758,13 +1758,13 @@
pos += blocksize;
}
 
+   err = 0;
+   if (!buffer_mapped(bh)) {
+   get_block(inode, iblock, bh, 0);
+   if (!buffer_mapped(bh))
+   goto unlock;
+   }
if (!buffer_uptodate(bh)) {
-   err = 0;
-   if (!buffer_mapped(bh)) {
-   get_block(inode, iblock, bh, 0);
-   if (!buffer_mapped(bh))
-   goto unlock;
-   }
err = -EIO;
bh->b_end_io = end_buffer_io_sync;
ll_rw_block(READ, 1, &bh);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



kernel BUG at ll_rw_blk.c:711!

2000-09-13 Thread Eloy A. Paris

Hi!

I got an Oops with 2.4.0test8. The message written to syslog said:

Sep 13 02:51:49 antenas kernel: kernel BUG at ll_rw_blk.c:711!

This machine has 128MBytes of memory and at the time of the Opps I was
running Netscape and a big find was running in the background as well
(Debian's daily maintenance script). The machine was pretty
irresponsive (as everytime this daily maintenance script runs).

I have been running -test8 (and all the different -testxx releases)
with no problems at all. This is the first time I get an Oops. After
the Opps I was able to continue to use the machine but after a little
bit I had to cycle power because all processes that had to access the
disk where hanging in the D state.

I don't think I can reproduce this...

Decoded oops is attached.

Cheers,

Eloy.-

P.S. I am not subscribed to linux-kernel.

ksymoops 2.3.4 on i686 2.4.0-test8.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test8/ (default)
 -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 001f   ebx: c7db9f20   ecx: c7580b40   edx: 0008
esi: c7db9f20   edi: c02303c0   ebp: 0001   esp: c4639ea8
ds: 0018   es: 0018   ss: 0018
Process communicator-sm (pid: 445, stackpage=c4639000)
Stack: c01bc6c5 c01bc962 02c7 c7db9f20 0001 000c  001e8480 
   c02303d8 c02303d0  0002   c014f422 00fe 
   c014ffe1 c02303c0 0001 c7db9f20 c7db9f20  0001 c4639f38 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 c0 4b 22 c0 

>>EIP; c014f9dd <__make_request+a1/5a4>   <=
Trace; c01bc6c5 
Trace; c01bc962 
Trace; c014f422 
Trace; c014ffe1 
Trace; c0150141 
Trace; c0120ef5 
Trace; c0120f94 
Trace; c0120fe5 
Trace; c0120ebc 
Trace; c0144c1b 
Trace; c012a4fb 
Trace; c012b351 
Trace; c010a2df 
Code;  c014f9dd <__make_request+a1/5a4>
 <_EIP>:
Code;  c014f9dd <__make_request+a1/5a4>   <=
   0:   0f 0b ud2a  <=
Code;  c014f9df <__make_request+a3/5a4>
   2:   83 c4 0c  add$0xc,%esp
Code;  c014f9e2 <__make_request+a6/5a4>
   5:   0f b6 46 15   movzbl 0x15(%esi),%eax
Code;  c014f9e6 <__make_request+aa/5a4>
   9:   0f b7 4e 14   movzwl 0x14(%esi),%ecx
Code;  c014f9ea <__make_request+ae/5a4>
   d:   8b 14 85 c0 4b 22 c0  mov0xc0224bc0(,%eax,4),%edx


1 warning issued.  Results may not be reliable.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



PROBLEM: kernel BUG at ll_rw_blk.c:711

2000-09-09 Thread Johnny Accot


Hi all!

I'm not subscribed to the list, but got a crash this morning with the
brand new 2.4.0-pre8.  Hope it helps.

BTW, thanks for your great work.

J. Accot


--
[1.] One line summary of the problem:kernel BUG at ll_rw_blk.c:711

[2.] Full description of the problem/report:

First, I typed 'sync' (remotely), which dumped core.  I typed it a second
time to see whether it could be reproduced, but the machine already crashed.
The kernel log was:

Sep  9 14:54:25 julee kernel: kernel BUG at ll_rw_blk.c:711!
Sep  9 14:54:25 julee kernel: invalid operand: 
Sep  9 14:54:25 julee kernel: CPU:0
Sep  9 14:54:25 julee kernel: EIP:0010:[__make_request+159/1452]
Sep  9 14:54:25 julee kernel: EFLAGS: 00010286
Sep  9 14:54:25 julee kernel: eax: 001f   ebx: c3fe8780   ecx:    edx: 

Sep  9 14:54:25 julee kernel: esi: c3fe8780   edi: c0275d20   ebp: 0001   esp: 
c5f37f34
Sep  9 14:54:25 julee kernel: ds: 0018   es: 0018   ss: 0018
Sep  9 14:54:25 julee kernel: Process kupdate (pid: 4, stackpage=c5f37000)
Sep  9 14:54:25 julee kernel: Stack: c01ef2e5 c01ef582 02c7 c3fe8780 0001 
000c  0001
Sep  9 14:54:25 julee kernel:c0275d38 c0275d30  0002  
 c016ba87 00fe
Sep  9 14:54:25 julee kernel:c016c66c c0275d20 0001 c3fe8780 c3fe8780 
 0001 c5f37fd0
Sep  9 14:54:25 julee kernel: Call Trace: [devfsd_buf_size+44101/50752] 
[devfsd_buf_size+44770/50752] [blk_get_queue+55/72] [generic_make_request+272/284] 
[ll_rw_block+347/460] [flush_dirty_buffers+130/180] [tvecs+13678/39896]
Sep  9 14:54:25 julee kernel:[sync_old_buffers+25/104] [kupdate+213/224] 
[kernel_thread+40/56]
Sep  9 14:54:25 julee kernel: Code: 0f 0b 83 c4 0c 31 c0 66 8b 4e 14 8a 46 15 8b 14 85 
20 a5 26
Sep  9 15:06:16 julee kernel: kernel BUG at ll_rw_blk.c:711!
Sep  9 15:06:16 julee kernel: invalid operand: 
Sep  9 15:06:16 julee kernel: CPU:0
Sep  9 15:06:16 julee kernel: EIP:0010:[__make_request+159/1452]
Sep  9 15:06:16 julee kernel: EFLAGS: 00010286
Sep  9 15:06:16 julee kernel: eax: 001f   ebx: c40a83c0   ecx: c55ce140   edx: 
0002
Sep  9 15:06:16 julee kernel: esi: c40a83c0   edi: c0275d20   ebp: 0001   esp: 
c3555f04
Sep  9 15:06:16 julee kernel: ds: 0018   es: 0018   ss: 0018
Sep  9 15:06:16 julee kernel: Process sync (pid: 705, stackpage=c3555000)
Sep  9 15:06:16 julee kernel: Stack: c01ef2e5 c01ef582 02c7 c40a83c0 0001 
000c  001e8480
Sep  9 15:06:16 julee kernel:c0275d38 c0275d30  0002  
 c016ba87 00fe
Sep  9 15:06:16 julee kernel:c016c66c c0275d20 0001 c40a83c0 c40a83c0 
 0001 c3555fa4
Sep  9 15:06:16 julee kernel: Call Trace: [devfsd_buf_size+44101/50752] 
[devfsd_buf_size+44770/50752] [blk_get_queue+55/72] [generic_make_request+272/284] 
[ll_rw_block+347/460] [sync_buffers+232/456] [fsync_dev+16/48]
Sep  9 15:06:16 julee kernel:[sys_sync+7/16] [system_call+51/64]
Sep  9 15:06:16 julee kernel: Code: 0f 0b 83 c4 0c 31 c0 66 8b 4e 14 8a 46 15 8b 14 85 
20 a5 26

[3.] Keywords (i.e., modules, networking, kernel): kernel, devfs?

[4.] Kernel version (from /proc/version):

Linux version 2.4.0-test8 (root@julee) (gcc version 2.95.3 19991030 (prerelease)) #110 
sam sep 9 13:26:49 CEST 2000

Just downloaded the new 2.4.0-test8 kernel.  No patch applied.  Oh, one patch.
The new acpi code from http://developer.intel.com/technology/iapc/acpi ...  Yet
the ACPI interpreter was not enabled; the 'Enter S1 state' was enabled.

[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)

No OOPS.

[6.] A small shell script or example program which triggers the
 problem (if possible)

None.

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)

Running RedHat RawHide 2424, with few minor changes, which should
not interact with kernel compilation.

Linux julee 2.4.0-test8 #110 sam sep 9 13:26:49 CEST 2000 i586 unknown
Kernel modules 2.3.11
Gnu C  2.95.3
Binutils   2.9.5.0.34
Linux C Library..
ldd: missing file arguments
Try `ldd --help' for more information.
ls: /usr/lib/libg++.so: Aucun fichier ou répertoire de ce type
Procps 2.0.6
Mount  2.10k
Net-tools  (1999-04-20)
Kbd[option...]
Sh-utils   2.0
Sh-utils   Parker.
Sh-utils   
Sh-utils   Inc.
Sh-utils   NO
Sh-utils   PURPOSE.

glibc-2.1.3-16 is installed.  ver_linux didn't seem to detect it.

[7.2.] Processor information (from /proc/cpuinfo):

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 5
model   : 8
model name  : Mobile Pentium MMX
stepping: 1
cpu MHz : 232.106809
fdiv_bug: no
hlt_bug