> Would people try out pre-2.1.37-7 and see what it breaks? The largest
> change since the last pre-patch is simply that I split up the old bit
> operations in two: one for atomically doing a test-and-change operation,
> and one for just doing the change operation.
I did, and was bitten. I booted the kernel, then went to xwindows and
fired lynx. The machine froze solid, and I had to reboot. I rebooted, and
started lynx from text mode. I got the following oops:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
current->tss.cr3 = 01472000, lr3 = 01472000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c0175f57>]
EFLAGS: 00010283
eax: 00000000 ebx: c0f748a8 ecx: 33743978 edx: c1fb9ca8
esi: c0f7486c edi: c1fb9ce0 ebp: c1fb9df0 esp: c1471f24
ds: 0018 es: 0018 ss: 0018
Process lynx (pid: 144, process nr: 30, stackpage=c1471000)
Stack: c1fb9ce0 c1fb9d58 00000000 00000000 00000286 c1fb9f8c c0172c66 c1fb9ce0
c1fb9ce0 c0499dec 00000000 bfffdb28 c017e54c c1fb9ce0 00000000 c0499dec
c0499d60 c01624d3 c0499dec 00000000 c0499d60 c016292c c0499dec c0de45c0
Call Trace: [<c0172c66>] [<c017e54c>] [<c01624d3>] [<c016292c>] [<c0121acf>] [<c0121b4a>] [<c0121bc6>]
[<c010948a>]
Code: 08 00 00 83 c4 0c 5b 5e 5f 5d 83 c4 08 c3 8d 76 00 83 ec 2c
Error in symbol table input.
Cannot find map file.
As you can see, the symbol table info was not found by the kernel
(Still could not find why...) I compiled ksymoops and it segfaults
(long time since I used it last time). So here are the info from my
system map, extracted by hand:
00000000c0121a98 T sys_creat
00000000c0121ab0 T __fput
00000000c0121afc T close_fp
00000000c0121b80 T sys_close
00000000c0121bd0 T sys_vhangup
...
00000000c0162410 T sock_alloc
00000000c01624b4 T sock_release
00000000c01624f4 T sock_sendmsg
...
00000000c01628c8 t sock_poll
00000000c01628f4 t sock_close
00000000c0162930 t sock_fasync
...
00000000c0172ae4 T tcp_shutdown
00000000c0172b50 T tcp_close
00000000c0172d58 t wait_for_connect
...
00000000c0175b44 T tcp_do_retransmit
00000000c0175d44 T tcp_send_fin
00000000c0175f68 T tcp_send_synack
...
00000000c017e4bc t inet_dup
00000000c017e4dc T inet_release
00000000c017e554 t inet_bind
...
After this oops, I got back to the prompt. But when I started shutdown
(to go back to pre-patch-5 - I did not test pre-patch-6) I got another
oops and the machine froze. I hoped to find this other oops in the log
files but there was no trace of it (I may redo all steps and write
down the oops stuff if needed).
--Another topic: I read a couple of messages about having problems with numlock & the like. This is what happens to me:
1) the NumLock led is ON at boot (it was off with 2.1.36, IIRC). 2) if I then boot as root on term 1, and I press the NumLock key once, the NumLock led does NOT go off 3) if I press it a second time, it goes off, and then all goes on more or less OK. 4) If I press numlock while the booting process is going on, or to a term that is not logged in, or otherwise I do not follow steps 2 and 3 above, I find myself in a condition when the machine remains locked for a few seconds. If I connect from another (networked) machine with ssh and run top, I can see that the situation unlocks when top does a refresh of its output. If I type keys, it seems that the unlocking process is delayed. If I wait patiently, when the top output on the other PC changes I can type again on that multiple console, or switch to another. But if I do other things with numlock or capslock keys, I am blocked again for another period.
Am I the only one??
Ciao Carlo
-- * ...Ma appena fuori tutto e' gomma, * K * Carlo E. Prelz - fluido@marktest.pt tutto e' cicca impiastricciata... * (Marco Zappa-Niente cicca nella scuola)