OK, some new information. Apparently, the ethernet traffic is getting
corrupted by heavy disk access to the second disk on my primary ALI
5229 controller. I suspect this is related to the oops, as the kernel
log messages reporting the errors tend to come roughly at the same
time as the oopses.
Hello again! We're in luck! The oops happened again, and this time,
the full oops dump appeared on the screen, which I have copied below:
=
Unable to handle kernel paging request at virtual address 6e617274
current->tss
Greetings! Here are the contiguous lines from kern.log:
Mar 21 01:14:47 intech9 kernel: eth0: bogus packet: status=0x80 nxpg=0x57 size=1270
Mar 21 01:14:49 intech9 kernel: Unable to handle kernel NULL pointer dereference at
virtual address
Mar 21 01:14:49 intech9 kernel: current->tss.c
> " " == Camm Maguire <[EMAIL PROTECTED]> writes:
> I'd be happy to generate one if I could. I've got the system
> map. The defaults reported by ksymoops are all correct. Don't
> know why it didn't give me more info. Normally, the info is
> reported by klogd anyway, bu
Greetings, and thanks for your reply!
Trond Myklebust <[EMAIL PROTECTED]> writes:
> > " " == Camm Maguire <[EMAIL PROTECTED]> writes:
>
> > 2.2.18 oops leaves umount hung in disk sleep
>
> This is normal behaviour for an Oops ;-)
>
> > Unable to handle kernel NULL pointer d
> " " == Camm Maguire <[EMAIL PROTECTED]> writes:
> 2.2.18 oops leaves umount hung in disk sleep
This is normal behaviour for an Oops ;-)
> Unable to handle kernel NULL pointer dereference at
> virtual address
current-> tss.cr3 = 02872000, %%cr3 = 02872
Please reply directly as I'm in ECN exile from this mailing list!
[1.] One line summary of the problem:
2.2.18 oops leaves umount hung in disk sleep
[2.] Full description of the problem/report:
Greetings! We have a backup server running 2.2.18,
nfs-kernel-server 0.1.
7 matches
Mail list logo
