* Crash
@ 2002-07-07 23:34 Jarda Gress
0 siblings, 0 replies; 4+ messages in thread
From: Jarda Gress @ 2002-07-07 23:34 UTC (permalink / raw)
To: linux-kernel, jgress
[-- Attachment #1: Type: text/plain, Size: 201 bytes --]
The kernel oops.
I think its in driver for sda. I have 2 IDE drives. One cdrom and one zip.
No scsi controlers or devices.
Attached is the log.
Thanks for delivering this to the right persdon.
Jarda
[-- Attachment #2: messages --]
[-- Type: text/plain, Size: 4845 bytes --]
Jul 7 01:49:37 localhost syslogd 1.4.1: restart.
Jul 7 01:50:04 localhost net_monitor.real[1671]: launched command: /usr/sbin/logdrake --file=/var/log/messages &
Jul 7 01:50:08 localhost net_monitor.real[1671]: launched command: /usr/sbin/logdrake --file=/var/log/messages &
Jul 7 01:50:09 localhost logdrake[1876]: ### Program is starting ###
Jul 7 01:50:13 localhost net_monitor.real[1671]: launched command: /usr/sbin/logdrake --file=/var/log/messages &
Jul 7 01:50:19 localhost logdrake[1878]: ### Program is starting ###
Jul 7 01:50:21 localhost dhcpcd[1710]: timed out waiting for a valid DHCP server response
Jul 7 01:50:26 localhost logdrake[1880]: ### Program is starting ###
Jul 7 01:51:11 localhost kernel: CSLIP: code copyright 1989 Regents of the University of California
Jul 7 01:51:11 localhost kernel: PPP generic driver version 2.4.1
Jul 7 01:51:11 localhost pppd[1892]: pppd 2.4.1 started by jarda, uid 501
Jul 7 01:51:11 localhost pppd[1892]: Using interface ppp0
Jul 7 01:51:11 localhost pppd[1892]: Connect: ppp0 <--> /dev/tts/1
Jul 7 01:51:35 localhost pppd[1892]: Hangup (SIGHUP)
Jul 7 01:51:35 localhost pppd[1892]: Modem hangup
Jul 7 01:51:35 localhost pppd[1892]: Connection terminated.
Jul 7 01:51:35 localhost pppd[1892]: Exit.
Jul 7 01:52:18 localhost pppd[1900]: pppd 2.4.1 started by jarda, uid 501
Jul 7 01:52:18 localhost pppd[1900]: Using interface ppp0
Jul 7 01:52:18 localhost pppd[1900]: Connect: ppp0 <--> /dev/tts/1
Jul 7 01:52:22 localhost kernel: PPP BSD Compression module registered
Jul 7 01:52:23 localhost kernel: PPP Deflate Compression module registered
Jul 7 01:52:23 localhost pppd[1900]: local IP address 210.50.68.22
Jul 7 01:52:23 localhost pppd[1900]: remote IP address 192.168.34.1
Jul 7 01:52:23 localhost pppd[1900]: primary DNS address 203.134.64.66
Jul 7 01:52:23 localhost pppd[1900]: secondary DNS address 203.134.65.66
Jul 7 01:53:44 localhost kernel: Device not ready. Make sure there is a disc in the drive.
Jul 7 01:53:44 localhost kernel: sda : READ CAPACITY failed.
Jul 7 01:53:44 localhost kernel: sda : status = 0, message = 00, host = 0, driver = 28
Jul 7 01:53:44 localhost kernel: Current sd00:00: sense key Not Ready
Jul 7 01:53:44 localhost kernel: Additional sense indicates Medium not present
Jul 7 01:53:44 localhost kernel: sda : block size assumed to be 512 bytes, disk size 1GB.
Jul 7 01:53:44 localhost kernel: /dev/scsi/host0/bus0/target0/lun0: I/O error: dev 08:00, sector 0
Jul 7 01:53:44 localhost kernel: I/O error: dev 08:00, sector 0
Jul 7 01:53:44 localhost kernel: Unable to handle kernel paging request at virtual address 204f2f8d
Jul 7 01:53:44 localhost kernel: printing eip:
Jul 7 01:53:44 localhost kernel: c0160783
Jul 7 01:53:44 localhost kernel: *pde = 00000000
Jul 7 01:53:44 localhost kernel: Oops: 0000
Jul 7 01:53:44 localhost kernel: CPU: 0
Jul 7 01:53:44 localhost kernel: EIP: 0010:[scan_dir_for_removable+19/64] Tainted: P
Jul 7 01:53:44 localhost kernel: EIP: 0010:[<c0160783>] Tainted: P
Jul 7 01:53:44 localhost kernel: EFLAGS: 00010202
Jul 7 01:53:44 localhost kernel: eax: c4b4dd20 ebx: 204f2f49 ecx: 00000000 edx: c4b4dd20
Jul 7 01:53:44 localhost kernel: esi: c54cb500 edi: c58efb60 ebp: c18525c0 esp: c4f03f28
Jul 7 01:53:44 localhost kernel: ds: 0018 es: 0018 ss: 0018
Jul 7 01:53:44 localhost kernel: Process msec_find (pid: 1873, stackpage=c4f03000)
Jul 7 01:53:44 localhost kernel: Stack: c54cb500 c0160c16 c58efb60 c0265a40 00000000 c54cb500 c54cb580 c54cb56c
Jul 7 01:53:44 localhost kernel: c18525c0 c0141690 c18525c0 c4f03fa0 c0141b90 c18525c0 fffffff7 0000000d
Jul 7 01:53:44 localhost kernel: bfffeae8 c0141d3f c18525c0 c0141b90 c4f03fa0 c5816c40 c01338f7 c5816c40
Jul 7 01:53:44 localhost kernel: Call Trace: [devfs_readdir+86/448] [vfs_readdir+96/144] [filldir64+0/352] [sys_getdents64+79/185] [filldir64+0/352]
Jul 7 01:53:44 localhost kernel: Call Trace: [<c0160c16>] [<c0141690>] [<c0141b90>] [<c0141d3f>] [<c0141b90>]
Jul 7 01:53:44 localhost kernel: [sys_fchdir+199/224] [system_call+51/64]
Jul 7 01:53:44 localhost kernel: [<c01338f7>] [<c0106f23>]
Jul 7 01:53:44 localhost kernel:
Jul 7 01:53:44 localhost kernel: Code: 66 8b 43 44 25 00 f0 00 00 66 3d 00 60 75 0d f6 43 10 04 74
Jul 7 01:53:56 localhost anacron[1285]: Job `cron.daily' terminated (mailing output)
Jul 7 02:01:00 localhost CROND[2006]: (root) CMD (nice -n 19 run-parts /etc/cron.hourly)
Jul 7 02:06:07 localhost init: Switching to runlevel: 0
Jul 7 02:06:10 localhost autologin(pam_unix)[1388]: session closed for user jarda
Jul 7 02:07:45 localhost init: Switching to runlevel: 6
Jul 7 02:14:22 localhost syslogd 1.4.1: restart.
Jul 7 02:14:22 localhost kernel: klogd 1.4.1, log source = /proc/kmsg started.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Crash
@ 2001-05-07 14:37 C.Praveen
2001-05-07 15:01 ` Crash Alan Cox
0 siblings, 1 reply; 4+ messages in thread
From: C.Praveen @ 2001-05-07 14:37 UTC (permalink / raw)
To: linux-kernel
Hello,
Is it possible to screw up the hardware entirely from software? I made
some changes to the 2.4.2 kernel to support save/restore of the event
counters. It crashed and does not come up at all, what i would like to
know is if there is any way to screw the board from software in such a way
that power off and power on does not bring it up ?.
Its a dual pentium-3 machine. The power supply is gone also, the power
supply from the crashed machine does not bring up another normal computer,
also power supply from normal computer does not bring up crashed computer.
so there must be something really wrong with the motherboard. Id like to
know if it was because of me ..., is it possible to do things to the
motherboard from software (I did change things in the kernel, timer ISR
also), that wont boot the machine at all when power turned off and then on
?. from aboce is it very likely that the power supply went out and took
the board with it ??
and by "doesnt come up" i meant, totally blank, no output at all
absolutely
*Any* help/comments please!
Praveen C
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Crash
2001-05-07 14:37 Crash C.Praveen
@ 2001-05-07 15:01 ` Alan Cox
2001-05-13 18:11 ` Crash Anuradha Ratnaweera
0 siblings, 1 reply; 4+ messages in thread
From: Alan Cox @ 2001-05-07 15:01 UTC (permalink / raw)
To: C.Praveen; +Cc: linux-kernel
> Is it possible to screw up the hardware entirely from software? I made
In an abstract theoretical sense yes. Accidentally almost impossible.
> know is if there is any way to screw the board from software in such a way
> that power off and power on does not bring it up ?.
The only people are ever likely to do is to corrupt the CMOS, which is easily
cleared.
> Its a dual pentium-3 machine. The power supply is gone also, the power
> supply from the crashed machine does not bring up another normal computer,
> also power supply from normal computer does not bring up crashed computer.
Sounds like a rather more physical layer problem - like a power spike and
PSU failure.
BTW: Always put a voltmeter on a power supply before you swap it like that
to test it. You need to check the voltages under load look sane otherwise you
may end up using a failed PSU to blow up other motherboards which is a
rather expensive debugging error ;)
Alan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Crash
2001-05-07 15:01 ` Crash Alan Cox
@ 2001-05-13 18:11 ` Anuradha Ratnaweera
0 siblings, 0 replies; 4+ messages in thread
From: Anuradha Ratnaweera @ 2001-05-13 18:11 UTC (permalink / raw)
To: Alan Cox; +Cc: C.Praveen, linux-kernel
On Mon, 7 May 2001, Alan Cox wrote:
> > Is it possible to screw up the hardware entirely from software? I made
>
> In an abstract theoretical sense yes. Accidentally almost impossible.
There _were_ some viruses (in M$ world) that added "expensive" operations
to every disk access, such as reading from the extreme ends of the disk,
so that the head of the hard disk might eventually fail.
Also, I have heard a hum coming out of a slightly old monitor (optiplex)
when set to run X with high resolutions (well above horizontal/vertical
frequency limits). This monior eventually failed when operating in the
_safe_ regime. However, I suspect that this was a problem with the monitor
rather than software.
Regards,
Anuradha
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-07-07 23:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-07-07 23:34 Crash Jarda Gress
-- strict thread matches above, loose matches on Subject: below --
2001-05-07 14:37 Crash C.Praveen
2001-05-07 15:01 ` Crash Alan Cox
2001-05-13 18:11 ` Crash Anuradha Ratnaweera
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox