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
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
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
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 oops
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.
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
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
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:
> " " == 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,
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.9.1-1
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.9.1-1
" " == 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
" " == 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, but not
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:
[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
[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
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
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
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
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
23 matches
Mail list logo
