public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: linux-kernel@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Subject: 2.2.16: How to freeze the kernel
Date: Fri, 24 Nov 2000 09:10:58 +0100	[thread overview]
Message-ID: <3A1E309C.26058.40EA98@localhost> (raw)

Hello,

this is for your interest, amusement, and for "what not to do":

I managed to freeze the kernel (2.2.16 from SuSE Linux 7.0) in a way 
that I could not even switch virtual consoles. Completely silent 
eberything...

It all started when Windows/95 ruined another CD-R while trying to 
write an image to the media. So I decided to try it with Linux, using 
the same CD writer.

I plugged the device to the so far unused SCSI channel and used the 
"add-sigle-device" method to avoid reboot, and I succeeded:

kgate kernel: scsi singledevice 0 0 4 0
kgate kernel:   Vendor: WAITEC    Model: WT624             Rev: 7.0F
kgate kernel:   Type:   CD-ROM                             ANSI SCSI 
revision: 0
kgate kernel: Detected scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0
kgate kernel: (scsi0:0:4:0) Synchronous at 10.0 Mbyte/sec, offset 15.
kgate kernel: sr1: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda 
tray

Then I used "cdrecord-1.8.1" to simulate writing at "speed=8". It 
worked so far, but there was a warning about possible problems with 
"simulated fixation", and actually several minutes nothing happened 
while the simulated fixation was expected to take place.

At some point I hit ^C, returning to the prompt. As the device did not 
seem to be ready, I thought "remove the device and reconnect", so I did 
"remove-single-device" (possibly while a command was still "busy"). The 
remove suceeded, but a second later everything had stopped!

Should a device with busy commands be able to be removed? I guess no...

The last message in the syslog was:

kgate kernel: scsi : aborting command due to timeout : pid 8358,
 scsi0, channel 0, id 4, lun 0 UNKNOWN(0x5b) 00 02 00 00 00 00 00 00 00

At that point I pressed "RESET", and interestingly the builtin BIOS of 
the Adaptec 2740 (EISA) hung while trying to detect the device.

Only after powering down both, the CD writer and the machine (a HP 
Netserver LD Pro), the BIOS detected the device again. So I guess 
something badly hung...

The driver being used was
Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.31/3.2.4

After that, everything worked fine.

Regards,
Ulrich

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

             reply	other threads:[~2000-11-24  8:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-24  8:10 Ulrich Windl [this message]
2000-11-24  8:52 ` 2.2.16: How to freeze the kernel Steffen Grunewald
2000-11-24 15:14 ` Douglas Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A1E309C.26058.40EA98@localhost \
    --to=ulrich.windl@rz.uni-regensburg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox