From: Daniel Eisenbud <eisenbud@cs.swarthmore.edu>
To: Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de>
Cc: Amit Chaudhary <amitc@brocade.com>, linuxppc-dev@lists.linuxppc.org
Subject: Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode
Date: Fri, 26 Jan 2001 16:04:41 -0500 [thread overview]
Message-ID: <20010126160441.B16573@allspice.cs.swarthmore.edu> (raw)
In-Reply-To: <Pine.LNX.4.30.0101262143110.5676-100000@opal.biophys.uni-duesseldorf.de>; from schmitz@mail.biophys.uni-duesseldorf.de on Fri, Jan 26, 2001 at 09:50:49PM +0100
On Fri, Jan 26, 2001 at 09:50:49PM +0100, Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de> wrote:
> > > Though i cannot help you with your exact problem, some pointers.
> > > 1. The log should be typicall in /var/log/messages as long as you
> > > have syslogd and klogd running.
> >
> > Unfortunately, since /var lives on the same bus, this doesn't help. But
> > I'll try setting up a minimal linux installation on the other SCSI bus
> > and burning a CD, and will hopefully then find something out.
>
> Even with /var living on a different bus, locking the MESH bus solid
> probably means you have all of the SCSI midlevel and perhaps the whole VFS
> locked up.
Hmm, I wouldn't expect the VFS to be involved because this is using the
SCSI generic driver and presumably not going through the VFS at all.
Ah, I see, you mean if the SCSI subsystem locks, then the next time VFS
was waiting for the SCSI bus it might just stay locked forever. Still,
if it turned out that the other SCSI bus was OK but the VFS had locked
up, I could avoid that by just mounting disks on the external bus. But
I'll try to figure out other avenuse before going to the trouble of
doing another install on the external disk.
> I'm not sure about the precise granularity of locking (2.2 or
> 2.4 kernel? I forgot what you said about kernel versions) but I doubt
> there is a per-hostadapter lock even in 2.4.
This happens with both 2.2 and 2.4.
> So what I'm saying is: rather try logging to serial console or network in
> order to see if there's any output produced (it might help to stop syslogd
> and klogd altogether and only use serial console) before you go to the
> effort to set up a copy of the system on another bus.
The thing that makes me a little bit pessimistic about this is that I
don't get any log messages even when I'm logged in on the console.
Maybe I need to change my syslogd setup to log everything to the console
(which virtual console will it get logged to, or can I specify that?)
and not to any files so syslogd won't freeze when SCSI goes? Is there
any reason to believe that I'd be able to get useful output over the
network or serial port when I can't on my screen? (Note that the whole
system doesn't lock up immediately, especially with swap turned off, but
any attempts to access filesystems make things die quickly.)
-Daniel
--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-01-26 21:04 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-26 19:48 mesh SCSI bus locks hard on 7500 when burning a CD-R in dao m ode Amit Chaudhary
2001-01-26 20:12 ` Daniel Eisenbud
2001-01-26 20:50 ` Michael Schmitz
2001-01-26 21:04 ` Daniel Eisenbud [this message]
2001-01-26 21:32 ` mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode Michael Schmitz
2001-01-27 21:31 ` Daniel Eisenbud
2001-01-28 0:59 ` Daniel Eisenbud
2001-01-28 1:25 ` Daniel Eisenbud
2001-01-28 2:34 ` Daniel Eisenbud
2001-01-28 5:09 ` Daniel Eisenbud
2001-01-28 5:11 ` Daniel Eisenbud
2001-01-28 7:16 ` Daniel Eisenbud
2001-01-28 7:17 ` Daniel Eisenbud
2001-01-28 20:24 ` scsi debug info before and after mesh locks up Daniel Eisenbud
2001-01-29 14:29 ` mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode Michael Schmitz
2001-01-29 23:20 ` Daniel Eisenbud
2001-01-30 21:28 ` Michael Schmitz
2001-01-30 21:35 ` Daniel Eisenbud
2001-01-30 21:46 ` Michael Schmitz
2001-01-30 21:57 ` Daniel Eisenbud
2001-01-31 16:40 ` Chris Boot
2001-02-01 16:50 ` Daniel Eisenbud
2001-02-02 7:38 ` SOLVED: " Daniel Eisenbud
2001-02-02 12:58 ` Michael Schmitz
2001-02-02 15:14 ` Daniel Eisenbud
2001-02-05 12:41 ` Benjamin Herrenschmidt
2001-02-03 4:19 ` Paul Mackerras
2001-02-03 16:14 ` Daniel Eisenbud
2001-02-03 16:27 ` Daniel Eisenbud
2001-02-03 18:48 ` PATCH: " Daniel Eisenbud
2001-02-04 21:37 ` SOLVED: " Michael Schmitz
2001-02-05 8:28 ` Geert Uytterhoeven
2001-01-31 7:10 ` Geert Uytterhoeven
2001-01-29 14:28 ` Michael Schmitz
-- strict thread matches above, loose matches on Subject: below --
2001-01-27 2:23 Iain Sandoe
2001-01-27 21:38 ` Daniel Eisenbud
2001-01-28 1:05 Iain Sandoe
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=20010126160441.B16573@allspice.cs.swarthmore.edu \
--to=eisenbud@cs.swarthmore.edu \
--cc=amitc@brocade.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=schmitz@opal.biophys.uni-duesseldorf.de \
/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;
as well as URLs for NNTP newsgroup(s).