On Wed, 30 May 2001 12:17:55 +0100 (BST),
Stephen Cornell <[EMAIL PROTECTED]> wrote:
>ksymoops doesn't seem to have done its job correctly
ksymoops did the best it could when fed with data that has been stamped
on by klogd. Always run klogd as "klogd -x" so it keeps its sticky
fingers off the o
Sorry, after reading the documentation I couldn't figure out who to send this
to. ksymoops doesn't seem to have done its job correctly, but I include the
output anyway. The problem seems to have occured during updatedb (creates the
slocate file database), which runs daily as a cron job (and has
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 ;-
>>>>> " " == 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
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.
[1.] One line summary of the problem:
Oops in schedule
[2.] Full description of the problem/report:
I am unsure of the actual cause. My machine is running Postfix and INN
and both were killed when the oops occurred. These are the only two tasks
that appear to have died.
[3.] Keywords (i.e.,
Dist: Red Hat 7.0
Kernel: Using 2.2.18 + IDE patches.
My lilo.conf:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
#timeout=50
message=/boot/message
default=linux
vga=ext
image=/boot/bzImage-2.2.18-1NSRI
label=linux
read-only
root=/dev/hda3
append="hd
Hello!
I have problems with kernels >=2.2.15
Always have similar oops about 1-2 times per week.
2.2.13 works good for me, but now I need big ide drive support.
I don't tried 2.2.14 yet, but looks like bug is in 2.2.14 and greater.
I have dual processors server with 5 eepro100 interfaces (2 cards
12 matches
Mail list logo