RE: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao m ode

RE: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao m ode

[Amit Chaudhary]

Hi Daniel,

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.
2. For information on sysrq, check Documentation/sysrq.txt in the linux kernel sources. You will have to rebuilt your kernel to enable SysRq.

Amit


-----Original Message-----
From: Daniel Eisenbud [mailto:eisenbud@cs.swarthmore.edu]
Sent: Thursday, January 25, 2001 1:50 PM
To: linuxppc-dev@lists.linuxppc.org
Subject: Fwd: mesh SCSI bus locks hard on 7500 when burning a CD-R in
dao mode



I asked this in linuxppc-user bothj yesterday and months ago, and have
not received any replies, which made me wonder if this list would be a
better place to ask.  I haven't done any significant kernel hacking, but
know C well and am more than happy to try to debug and see if I can fix
this, but I'm not sure where to start.  I guess the first thing to do
should be to boot from a disk on the other SCSI bus and see what errors
I get from mesh, since right now everything just freezes hard without
any visible diagnostics.  Or is there a way, even with a totally frozen
SCSI bus (containing the swap partition among other things, though I can
of course swapoff before testing this) to tell anything useful about the
state of the machine once SCSI is frozen.  I have vaguely heard of, but
don't know the details of this "magic sysrq" thing.  Would that be
useful?

Please excuse my cluelessness -- any advice that people have is much
appreciated!

The text of my original message with the details of the problem is
below.

Thanks,
Daniel Eisenbud

----- Forwarded message from Daniel Eisenbud <eisenbud@cs.swarthmore.edu> -----

Date: Wed, 24 Jan 2001 22:28:54 -0500
From: Daniel Eisenbud <eisenbud@cs.swarthmore.edu>
To: linuxppc-user@lists.linuxppc.org
Subject: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode


I have a Powermac 7500 (with a G3 accelerator.)  I have replaced the
internal CD-ROM with a Yamaha CD-RW drive.  This sits on the mesh SCSI
bus.  I have the mesh driver configured to run at 5 megabytes/second
(since I get massive SCSI problems all over the place if I set it to
10.)  Under a variety of kernels, from 2.2.15 or so to 2.4.0 from Paul
Mackeras's tree, my SCSI setup is generally stable and I can burn CD-R
disks just fine in track-at-once mode.  However, if I try to burn a disk
in disk-at-once mode, either with cdrdao or cdrecord, the SCSI bus
appears to silently lock up hard, bringing down my whole machine.
Nothing is logged at all, as far as I can tell.  Has anyone had this
problem before?  Does anyone know of a solution?  If not, how would I go
about debugging this further?

Thanks in advance,
Daniel Eisenbud

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu




----- End forwarded message -----

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao m ode

[Daniel Eisenbud]

On Fri, Jan 26, 2001 at 11:48:40AM -0800, Amit Chaudhary <amitc@brocade.com> 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.

> 2. For information on sysrq, check Documentation/sysrq.txt in the
> linux kernel sources. You will have to rebuilt your kernel to enable
> SysRq.

Great, I'll look into this.

Thanks for the advice!

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao m ode

[Michael Schmitz]

> > 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. 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.

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.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

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/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Michael Schmitz]

> > > 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,

Right. And are you sure the sg driver isn't going through VFS (sharing
buffers with the rest of the system)?

> 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

As long as the sg driver doesn't touch VFS buffers at all, not even for
copying data from user space, I think you should be safe.

> This happens with both 2.2 and 2.4.

So more lock granularity in 2.4 didn't help :-(


> > 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.

I think that's a different story: these messages would be posted to the
console by syslogd which might already hang. Depends on your syslog.conf.

Serial console is different in that it doesn't just write log messages to
the kernel log buffer and wait for klogd/syslogd to pick them up, but
instead write the messages out to the serial port without delay.

> 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?)

# same to a separate screen
*.info;mail.none;authpriv.none;local0.none		/dev/tty7

is what keeps a not-too-cluttered log (copy of /var/log/messages) on tty7
of our server. kern.notice to some tty would probably be enough for you.

> and not to any files so syslogd won't freeze when SCSI goes?  Is there

So put just that one line redirecting log output to /dev/tty7 into
syslog.conf temporarily and kill -1 syslogd before starting the test.

> 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.)

The system not locking up immediately makes me hope serial console will
still work and show messages if there are any generated. At least
interrupts aren't blocked yet. syslog to a log host might also still work.
But output to console should also still work ...

Have you tried to increase the kernel log level (dmesg -n 7 should be the
max level you can set from user space) to make sure every kernel message
goes to the current console directly? If that doesn't work, but you can
still use the keyboard, it's time to hack a new sysrq option that dumps
the current MESH status and so on. Or toggles logging in the MESH driver.
You might be able to use xmon as well - I've never tried hard enough to
understand xmon.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Fri, Jan 26, 2001 at 10:32:35PM +0100, Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de> wrote:
> > 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,
>
> Right. And are you sure the sg driver isn't going through VFS (sharing
> buffers with the rest of the system)?

Um, no idea.  I'd believe you if you said that it was.  :-)

> > 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.
>
> I think that's a different story: these messages would be posted to the
> console by syslogd which might already hang. Depends on your syslog.conf.
>
> Serial console is different in that it doesn't just write log messages to
> the kernel log buffer and wait for klogd/syslogd to pick them up, but
> instead write the messages out to the serial port without delay.

How do I set it up to log to a serial console?  (I may not be able to do
this for a few days until I borrow a friend's laptop, though.)

> > 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?)
>
> # same to a separate screen
> *.info;mail.none;authpriv.none;local0.none		/dev/tty7
>
> is what keeps a not-too-cluttered log (copy of /var/log/messages) on tty7
> of our server. kern.notice to some tty would probably be enough for you.
>
> > and not to any files so syslogd won't freeze when SCSI goes?  Is there
>
> So put just that one line redirecting log output to /dev/tty7 into
> syslog.conf temporarily and kill -1 syslogd before starting the test.

I'll try this variation in a few minutes.

> Have you tried to increase the kernel log level (dmesg -n 7 should be the
> max level you can set from user space) to make sure every kernel message
> goes to the current console directly?

I did "dmesg -n 8" since I forgot the number and didn't have your email
right in front of me, and it accepted that.  Does dmesg just tell the
kernel what to send to syslogd, or does it tell it what to send to the
current console directly?  If the former, how does this work on a
per-console basis?  If the latter, why would a serial console have a
better chance of working?

> If that doesn't work, but you can still use the keyboard, it's time to
> hack a new sysrq option that dumps the current MESH status and so on.
> Or toggles logging in the MESH driver.  You might be able to use xmon
> as well - I've never tried hard enough to understand xmon.

Hmm, I'll try to look into this.  If anyone has any pointers to
information about xmon, please let me know.  Do I need to use it over a
serial line?

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Sat, Jan 27, 2001 at 04:31:15PM -0500, Daniel Eisenbud <eisenbud@cs.swarthmore.edu> wrote:
> On Fri, Jan 26, 2001 at 10:32:35PM +0100, Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de> wrote:
> > # same to a separate screen
> > *.info;mail.none;authpriv.none;local0.none		/dev/tty7
> >
> > is what keeps a not-too-cluttered log (copy of /var/log/messages) on tty7
> > of our server. kern.notice to some tty would probably be enough for you.
> >
> > > and not to any files so syslogd won't freeze when SCSI goes?  Is there
> >
> > So put just that one line redirecting log output to /dev/tty7 into
> > syslog.conf temporarily and kill -1 syslogd before starting the test.
>
> I'll try this variation in a few minutes.

This worked, but I didn't get any useful log output until I started
getting error 600 from the SCSI midlevel and errors from ext2fs.  I'm
going to try again, making sure that I have dmesg set as high as
possible, and see if I can get anything else.  Otherwise, is it time to
start scattering printk()'s around the mesh driver?

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Sat, Jan 27, 2001 at 07:59:24PM -0500, Daniel Eisenbud <eisenbud@cs.swarthmore.edu> wrote:
>
> On Sat, Jan 27, 2001 at 04:31:15PM -0500, Daniel Eisenbud <eisenbud@cs.swarthmore.edu> wrote:
> > On Fri, Jan 26, 2001 at 10:32:35PM +0100, Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de> wrote:
> > > # same to a separate screen
> > > *.info;mail.none;authpriv.none;local0.none		/dev/tty7
> > >
> > > is what keeps a not-too-cluttered log (copy of /var/log/messages) on tty7
> > > of our server. kern.notice to some tty would probably be enough for you.
> > >
> > > > and not to any files so syslogd won't freeze when SCSI goes?  Is there
> > >
> > > So put just that one line redirecting log output to /dev/tty7 into
> > > syslog.conf temporarily and kill -1 syslogd before starting the test.
> >
> > I'll try this variation in a few minutes.
>
> This worked, but I didn't get any useful log output until I started
> getting error 600 from the SCSI midlevel and errors from ext2fs.  I'm
> going to try again, making sure that I have dmesg set as high as
> possible, and see if I can get anything else.  Otherwise, is it time to
> start scattering printk()'s around the mesh driver?

In fact, it looks like the mesh driver has significant debugging code.
My last attempt of this evening will be to turn that on and see if it
does anything.  If not, I'll look at this again tomorrow or the day
after.

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Sat, Jan 27, 2001 at 08:25:00PM -0500, Daniel Eisenbud <eisenbud@cs.swarthmore.edu> wrote:
> In fact, it looks like the mesh driver has significant debugging code.
> My last attempt of this evening will be to turn that on and see if it
> does anything.  If not, I'll look at this again tomorrow or the day
> after.

Well, the mesh driver debugging code did not trigger.  However, I have
some new information: cdrdao eventually exits with
"cdrdao: Device not configured.  Cannot set SG_SET_TIMEOUT"
I also get a message that the SCSI subsystem gave a return code of
6000000 (looking at the source, this is actually in hex) while trying to
access my internal disk.

There also appear to be reports of this happening on the single
(non-mesh) SCSI bus of a powermac 7200.  I just replied to one of them
on the mailing list.  In that case, it's not clear that this only dies
when trying to burn in disk-at-once mode.  There's another report of
trouble on the mailing list from someone who was trying to burn in
disk-at-once mode but didn't specify on what hardware.  I'm about to
respnd to that one to see if I can get a little bit closer to tracking
this down.  The non-mesh report makes me wonder if the problem is in
some other layer.  Maybe the sg driver has a subtle endianness issue on
PowerPC?  Has anyone ever successfully burned a disk in disk-at-once
mode with a SCSI CD-R or CD-RW on a powerppc machine?  On a powermac?

Maybe the next thing to do (why didn't I think of this sooner?) is to
strace cdrdao and cdrecord and see what system call they're really
hanging in, and what difference there is between what they do in dao
mode and what they do in tao mode.  More later!

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Sat, Jan 27, 2001 at 09:34:01PM -0500, Daniel Eisenbud <eisenbud@cs.swarthmore.edu> wrote:
> Maybe the next thing to do (why didn't I think of this sooner?) is to
> strace cdrdao and cdrecord and see what system call they're really
> hanging in, and what difference there is between what they do in dao
> mode and what they do in tao mode.  More later!

Attached is strace output from cdrdao.  I honsetly can't make much of
it, but maybe someone else will be able to?  I'm not sure if it hung in
the last read or the last write.  I think it was the last read, because
strace printed part of that line and then its output file (which I put
on a ramdisk, and tarred to a floppy from there, so I wouldn't have to
copy it by hand once my SCSI bus was useless) didn't change for a while,
and then the read line finished printing.  There's probably a way to
make strace print timestamps, and I'll do that tomorrow (as well as
doing this with cdrecord in both disk-at-once and track-at-once modes to
be able to compare them.

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

Oops, I forgot to actually attach the file.  If anyone wants to see this
and has trouble with reading MIME attachments, just email me and I'll
send you a plaintext copy -- I figured I compress and attach it to spare
the whole list a 20K email.

-Daniel

On Sun, Jan 28, 2001 at 12:09:29AM -0500, Daniel Eisenbud <eisenbud@cs.swarthmore.edu> wrote:
> Attached is strace output from cdrdao.  I honsetly can't make much of
> it, but maybe someone else will be able to?  I'm not sure if it hung in
> the last read or the last write.  I think it was the last read, because
> strace printed part of that line and then its output file (which I put
> on a ramdisk, and tarred to a floppy from there, so I wouldn't have to
> copy it by hand once my SCSI bus was useless) didn't change for a while,
> and then the read line finished printing.  There's probably a way to
> make strace print timestamps, and I'll do that tomorrow (as well as
> doing this with cdrecord in both disk-at-once and track-at-once modes to
> be able to compare them.

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

[-- Attachment #2: cdrdao.log.0.gz --]
[-- Type: application/x-gunzip, Size: 3016 bytes --]

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

More output.  It looks like SCSI dies when cdrecord sends the cue sheet,
which it only does in DAO mode, the SCSI driver dies, as exemplified in
this portion of its output in verbose mode:

Executing 'send_cue_sheet' command on Bus 0 Target 3, Lun 0 timeout 200s
CDB:  5D 00 00 00 00 00 00 00 20 00
DMA addr: 0x100404F0 size: 32 - using copy buffer
pack_len: 36, reply_len: 36 pack_id: 70 result: 0 sense[0]: 00
cmd finished after 200.500s timeout 200s

As you can see, it times out.  Attached is a bzip2'ed tar file of the
strace output (with timings, this time) and output of burning the same
very short track (which happens to be the TOC of an audio CD, not that
it seems to matter) in TAO mode and DAO mode.

Now to get to the bottom of what about the "send_cue_sheet" command is
losing.  But I need to get some sleep first.  If anyone has any ideas
about what I might do to actually see the packet and actually watch what
happens as it goes through the SCSI subsystem, that would be great.  I
can see xmon looming in my future.  :-)

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

Aargh, forgot to attach the file again!  Here it is.

-Daniel

On Sun, Jan 28, 2001 at 02:16:58AM -0500, Daniel Eisenbud <eisenbud@cs.swarthmore.edu> wrote:
> More output.  It looks like SCSI dies when cdrecord sends the cue sheet,
> which it only does in DAO mode, the SCSI driver dies, as exemplified in
> this portion of its output in verbose mode:
[...]

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

[-- Attachment #2: cdrecord-tests.tar.bz2 --]
[-- Type: application/octet-stream, Size: 13644 bytes --]

scsi debug info before and after mesh locks up

[Daniel Eisenbud]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

And here's more info: the result of "echo scsi dump 1 > /proc/scsi/scsi"
before and a few times after it freezes.  Can anyone help me make sense
of this?  I guess I need to dig into the source to see what the SCSI
command numbers correspond to.

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

[-- Attachment #2: scsidump-before --]
[-- Type: text/plain, Size: 1021 bytes --]

Dump of scsi host parameters:
 0 0 0 : 0 00000000
 0 0 0 : 0 00000000


Dump of scsi command parameters:
h:c:t:l (dev sect nsect cnumsec sg) (ret all flg) (to/cmd to ito) cmd snse result
(  0)  0:0: 0: 0 ( 08:00   10    0    2 ffffffff 1) (0 5 0x 0) (3000    0    0) 0x28 0x00 0x00000000
(  1)  0:0: 0: 0 ( 00:00    0    0    0 ffffffff 0) (0 0 0x 0) (   0    0    0) 0x00 0x00 0x00000000
(  2)  0:0: 1: 0 ( 08:16 983056    0    2 ffffffff 1) (0 5 0x 0) (3000    0    0) 0x2a 0x00 0x00000000
(  3)  0:0: 1: 0 ( 08:16 999438    0    2 ffffffff 1) (0 5 0x 0) (3000    0    0) 0x2a 0x00 0x00000000
(  4)  0:0: 3: 0 ( 00:00    0    0    0 ffffffff 0) (0 1 0x 0) (4050    0    0) 0x1e 0x00 0x00000000
(  5)  0:0: 3: 0 ( 00:00    0    0    0 ffffffff 0) (0 0 0x 0) (   0    0    0) 0x00 0x00 0x00000000
h:c:t:l (dev sect nsect cnumsec sg) (ret all flg) (to/cmd to ito) cmd snse result
Dump of pending block device requests
Dump of pending block device requests
Dump of pending block device requests
wait_for_request = c0172244

[-- Attachment #3: scsidump-after --]
[-- Type: text/plain, Size: 1014 bytes --]

Dump of scsi host parameters:
 0 2 2 : 0 00000000
 0 0 0 : 0 00000000


Dump of scsi command parameters:
h:c:t:l (dev sect nsect cnumsec sg) (ret all flg) (to/cmd to ito) cmd snse result
(  0)  0:0: 0: 0 ( 08:00   10    0    2 ffffffff 1) (0 5 0x 0) (3000    0    0) 0x28 0x00 0x00000000
(  1)  0:0: 0: 0 ( 00:00    0    0    0 ffffffff 0) (0 0 0x 0) (   0    0    0) 0x00 0x00 0x00000000
(  2)  0:0: 1: 0 ( 08:16 606220    2    2    1 1) (0 5 0x 0) (3000    0    0) 0x2a 0x00 0x00000000
(  3)  0:0: 1: 0 ( 08:16 622628    0    2 ffffffff 1) (0 5 0x 0) (3000    0    0) 0x2a 0x00 0x00000000
(  4)  0:0: 3: 0 ( 15:02    0    0    0    1 0) (0 1 0x 0) (20050    0    0) 0x5d 0x00 0x00000000
(  5)  0:0: 3: 0 ( 00:00    0    0    0 ffffffff 0) (0 0 0x 0) (   0    0    0) 0x00 0x00 0x00000000
h:c:t:l (dev sect nsect cnumsec sg) (ret all flg) (to/cmd to ito) cmd snse result
Dump of pending block device requests
Dump of pending block device requests
Dump of pending block device requests
wait_for_request = c0172244

[-- Attachment #4: scsidump-way-after --]
[-- Type: text/plain, Size: 1023 bytes --]

Dump of scsi host parameters:
 0 0 0 : 0 00000000
 0 0 0 : 0 00000000


Dump of scsi command parameters:
h:c:t:l (dev sect nsect cnumsec sg) (ret all flg) (to/cmd to ito) cmd snse result
(  0)  0:0: 0: 0 ( 08:00   10    0    2 ffffffff 1) (0 5 0x 0) (3000    0    0) 0x28 0x00 0x00000000
(  1)  0:0: 0: 0 ( 00:00    0    0    0 ffffffff 0) (0 0 0x 0) (   0    0    0) 0x00 0x00 0x00000000
(  2)  0:0: 1: 0 ( 08:16 606224    0    2 ffffffff 0) (0 5 0x 0) (3000    0    0) 0x2a 0x00 0x06000000
(  3)  0:0: 1: 0 ( 08:16 999438    0    2 ffffffff 0) (0 5 0x 0) (3000    0    0) 0x2a 0x00 0x00000000
(  4)  0:0: 3: 0 ( 00:00    0    0    0 ffffffff 0) (0 1 0x 0) (20050    0    0) 0x5d 0x00 0x06000000
(  5)  0:0: 3: 0 ( 00:00    0    0    0 ffffffff 0) (0 1 0x 0) (2050    0    0) 0x00 0x00 0x06000000
h:c:t:l (dev sect nsect cnumsec sg) (ret all flg) (to/cmd to ito) cmd snse result
Dump of pending block device requests
Dump of pending block device requests
Dump of pending block device requests
wait_for_request = c0172244

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Michael Schmitz]

> > > So put just that one line redirecting log output to /dev/tty7 into
> > > syslog.conf temporarily and kill -1 syslogd before starting the test.
> >
> > I'll try this variation in a few minutes.
>
> This worked, but I didn't get any useful log output until I started
> getting error 600 from the SCSI midlevel and errors from ext2fs.  I'm
> going to try again, making sure that I have dmesg set as high as

Please report the precise message text.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Mon, Jan 29, 2001 at 03:29:16PM +0100, Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de> wrote:
> > > > So put just that one line redirecting log output to /dev/tty7 into
> > > > syslog.conf temporarily and kill -1 syslogd before starting the test.
> > >
> > > I'll try this variation in a few minutes.
> >
> > This worked, but I didn't get any useful log output until I started
> > getting error 600 from the SCSI midlevel and errors from ext2fs.  I'm
> > going to try again, making sure that I have dmesg set as high as
>
> Please report the precise message text.

Here is what appears to be the relevant part of the log.  I have more of
it, which I can send to anyone if they need more context.  Note that in
the full log, there are _no_ _more_ messages from the mesh driver ever
after the last one you see in this segment.  It just crawls into a
corner and dies.

Note that this is from turning mesh debugging on for all hosts in
mesh.c, and turning on SCSI debugging by compiling in the option and
then doing "echo scsi log all > /proc/scsi/scsi".

-Daniel

Jan 29 10:42:50 cumulonimbus kernel: sg_unlink_reserve: req->use_sg=0
Jan 29 10:42:50 cumulonimbus kernel: sg_write: dev=2, count=78
Jan 29 10:42:50 cumulonimbus kernel: Open returning 1
Jan 29 10:42:50 cumulonimbus kernel: sg_write:   scsi opcode=0x5d, cmd_size=10
Jan 29 10:42:50 cumulonimbus kernel: sg_start_req: max_buff_size=32
Jan 29 10:42:50 cumulonimbus kernel: sg_link_reserve: size=32
Jan 29 10:42:50 cumulonimbus kernel: sg_write_xfer: num_write_xfer=32, use_sg=0
Jan 29 10:42:50 cumulonimbus kernel: Activating command for device 3 (1)
Jan 29 10:42:50 cumulonimbus kernel: scsi_do_cmd (host = 0, channel = 0 target = 3, buffer =c3490000, bufflen = 32, done = c00e149c, timeout = 20050, retries = 1)
Jan 29 10:42:50 cumulonimbus kernel: command : 5d  00  00  00  00  00  00  00  20  00
Jan 29 10:42:50 cumulonimbus kernel: internal_cmnd (host = 0, channel = 0, target = 3, command = c033c245, buffer = c3490000,
Jan 29 10:42:50 cumulonimbus kernel: bufflen = 32, done = c00e149c)
Jan 29 10:42:50 cumulonimbus kernel: queuecommand : routine at c00e39f4
Jan 29 10:42:50 cumulonimbus kernel: mesh_start: c033c200 ser=1518 tgt=3 cmd= 5d 0 0 0 0 0 0 0 20 0 use_sg=0 buffer=c3490000 bufflen=32
Jan 29 10:42:50 cumulonimbus kernel: leaving internal_cmnd()
Jan 29 10:42:50 cumulonimbus kernel: Leaving scsi_do_cmd()
Jan 29 10:42:50 cumulonimbus kernel: mesh: sending 1 msg bytes: c0
Jan 29 10:42:50 cumulonimbus kernel: sg_read: dev=2, count=36
Jan 29 10:42:50 cumulonimbus kernel: Open returning 1
Jan 29 10:46:10 cumulonimbus kernel: Command timed out active=1 busy=1 failed=1
Jan 29 10:46:11 cumulonimbus kernel: Error handler waking up
Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Checking to see if we need to request sense
Jan 29 10:46:11 cumulonimbus kernel: Command to ID 3 timedout
Jan 29 10:46:11 cumulonimbus kernel: Total of 0+1 commands on 1 devices require eh work
Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Checking to see if we want to try abort
Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Checking to see if we want to try BDR
Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Try hard bus reset
Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Try hard host reset
Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Take device offline
Jan 29 10:46:11 cumulonimbus kernel: Finishing command for device 3 6000000
Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Returning
Jan 29 10:46:11 cumulonimbus kernel: Clearing timer for command c033c200
Jan 29 10:46:11 cumulonimbus kernel: scsi_error.c: Waking up host to restart
Jan 29 10:46:11 cumulonimbus kernel: Calling request function to restart things...
Jan 29 10:46:11 cumulonimbus last message repeated 2 times
Jan 29 10:46:11 cumulonimbus kernel: scsi_error.c: device offline - report as SUCCESS
Jan 29 10:46:11 cumulonimbus kernel: Command finished 1 0 0x6000000
Jan 29 10:46:11 cumulonimbus kernel: Notifying upper driver of completion for device 3 6000000
Jan 29 10:46:11 cumulonimbus kernel: sg__done: dev=2, scsi_stat=0, res=0x6000000
Jan 29 10:46:11 cumulonimbus kernel: Deactivating command for device 3 (active=0, failed=0)
Jan 29 10:46:11 cumulonimbus kernel: Error handler sleeping
Jan 29 10:46:11 cumulonimbus kernel: sg_finish_rem_req: res_used=1
Jan 29 10:46:11 cumulonimbus kernel: sg_unlink_reserve: req->use_sg=0

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Michael Schmitz]

> >
> > Please report the precise message text.
>
> Here is what appears to be the relevant part of the log.  I have more of
> it, which I can send to anyone if they need more context.  Note that in
> the full log, there are _no_ _more_ messages from the mesh driver ever
> after the last one you see in this segment.  It just crawls into a
> corner and dies.
> Jan 29 10:42:50 cumulonimbus kernel: mesh: sending 1 msg bytes: c0
> Jan 29 10:42:50 cumulonimbus kernel: sg_read: dev=2, count=36
> Jan 29 10:42:50 cumulonimbus kernel: Open returning 1
> Jan 29 10:46:10 cumulonimbus kernel: Command timed out active=1 busy=1 failed=1
> Jan 29 10:46:11 cumulonimbus kernel: Error handler waking up
> Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Checking to see if we need to request sense
> Jan 29 10:46:11 cumulonimbus kernel: Command to ID 3 timedout

The command in question seems to time out (now does this message come from
the sg or midlevel timeout?).

> Jan 29 10:46:11 cumulonimbus kernel: Total of 0+1 commands on 1 devices require eh work
> Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Checking to see if we want to try abort
> Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Checking to see if we want to try BDR
> Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Try hard bus reset
> Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Try hard host reset
> Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Take device offline
> Jan 29 10:46:11 cumulonimbus kernel: Finishing command for device 3 6000000
> Jan 29 10:46:11 cumulonimbus kernel: scsi_unjam_host: Returning

The error handling code can't cope with the situation. Either because
abort support isn't implemented, or because something in the low level
driver went FUBAR.

> Jan 29 10:46:11 cumulonimbus kernel: Clearing timer for command c033c200
> Jan 29 10:46:11 cumulonimbus kernel: scsi_error.c: Waking up host to restart
> Jan 29 10:46:11 cumulonimbus kernel: Calling request function to restart things...
> Jan 29 10:46:11 cumulonimbus last message repeated 2 times

That 'restart things' doesn't seem to do anything either.

The big question: why does this particular command time out in the first
place? Does the target expect more data to be sent? Does the target just
crash and fails to release the bus? It seems to work on other host
adapters, doesn't it?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Tue, Jan 30, 2001 at 10:28:25PM +0100, Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de> wrote:
> The big question: why does this particular command time out in the first
> place? Does the target expect more data to be sent? Does the target just
> crash and fails to release the bus? It seems to work on other host
> adapters, doesn't it?

There's a report of excatly the same failure mode on mac53c94 with a
different brand (Sony, as opposed to Yamaha on my MESH) of DVD drive.
So the only points in common seem to be that the DVD drives are running
on mac hardware and that the drivers are written by Paul Mackerras.  :-)
I don't at all mean to impugn Paul's coding ability, which is obviously
excellent, but the fact that he wrote both the drivers may mean that
they share lots of code and possibly share the same bug.

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Michael Schmitz]

> > The big question: why does this particular command time out in the first
> > place? Does the target expect more data to be sent? Does the target just
> > crash and fails to release the bus? It seems to work on other host
> > adapters, doesn't it?
>
> There's a report of excatly the same failure mode on mac53c94 with a
> different brand (Sony, as opposed to Yamaha on my MESH) of DVD drive.

Please send a detailed description on how to reproduce this bug by PM.
I'll try to look into that on my Lombard, and in case I can get the
required binaries for m68k I'd also test on an old Quadra with 53c9x
SCSI.

Does the bug happen only with DVD writers, or regular CD writers?

> So the only points in common seem to be that the DVD drives are running
> on mac hardware and that the drivers are written by Paul Mackerras.  :-)
> I don't at all mean to impugn Paul's coding ability, which is obviously
> excellent, but the fact that he wrote both the drivers may mean that
> they share lots of code and possibly share the same bug.

If so, the bug should have propagated to the m68k 53c9x driver. Wouldn't
be the 53c9x first weirdness - I never got it to accept a DAT drive (old
DDS-1, possibly Apple) without blowing up.

It might be something PPC specific as well and have nothing to do with
Paul's drivers.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Tue, Jan 30, 2001 at 10:46:06PM +0100, Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de> wrote:
> > > The big question: why does this particular command time out in the first
> > > place? Does the target expect more data to be sent? Does the target just
> > > crash and fails to release the bus? It seems to work on other host
> > > adapters, doesn't it?
> >
> > There's a report of excatly the same failure mode on mac53c94 with a
> > different brand (Sony, as opposed to Yamaha on my MESH) of DVD drive.
>
> Please send a detailed description on how to reproduce this bug by PM.
> I'll try to look into that on my Lombard, and in case I can get the
> required binaries for m68k I'd also test on an old Quadra with 53c9x
> SCSI.

Basically, any time I have used cdrdao to write a disc, or cdrecord with
the -dao flag, the SCSI bus has locked up, under kernels from 2.2.15pre3
or so to a recent 2.4 from the bk tree.  I'm tempted to see whether I
can write a short program using the sg stuff to just send the
"send_cue_sheet" command to the CD-RW and see if it locks up, but I
haven't had a chance to look into it yet.

> Does the bug happen only with DVD writers, or regular CD writers?

Aargh, sorry, when I said "DVD" above it was a complete thinko.  I have
a Yamaha CD-RW drive (the model number is something wit 8424 in it, I
can get exact details when I get home.)  The report with the mac53c94
driver was a Sony CD-R or CD-RW drive -- I've exchanged email with the
guy who reported it and can ask for the details if you'd like.  I have
no idea if it would fail with a DVD writer, but all the cases I've seen
have been CD writers.  (This is why it's not a good idea to wait until
late afternoon to have coffee, and why if I do so, I should refrain from
writing email until after I have found some.)  :-)

> > So the only points in common seem to be that the DVD drives are running
> > on mac hardware and that the drivers are written by Paul Mackerras.  :-)
> > I don't at all mean to impugn Paul's coding ability, which is obviously
> > excellent, but the fact that he wrote both the drivers may mean that
> > they share lots of code and possibly share the same bug.
>
> If so, the bug should have propagated to the m68k 53c9x driver. Wouldn't
> be the 53c9x first weirdness - I never got it to accept a DAT drive (old
> DDS-1, possibly Apple) without blowing up.

It would be great if you could check this out.

> It might be something PPC specific as well and have nothing to do with
> Paul's drivers.

This is why I asked in a previous email whether anyone had ever burned
a disk in DAO mode successfully on a pmac or in fact on any powerpc
machine, but I've received no responses.  Hmm, maybe I should try to
conduct a quick survey of this on linuxppc-user and/or debian-powerpc.

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Chris Boot]

>> It might be something PPC specific as well and have nothing to do with
>> Paul's drivers.
>
> This is why I asked in a previous email whether anyone had ever burned
> a disk in DAO mode successfully on a pmac or in fact on any powerpc
> machine, but I've received no responses.  Hmm, maybe I should try to
> conduct a quick survey of this on linuxppc-user and/or debian-powerpc.

Well, I can't write a dao disk on my Panasonic CW-7502.  cdrecord complains
that it can't send the cue sheet, but the SCSI bus doesn't die in any way, I
can still mount and use disks on it afterwards (I only have the built-in
CD-ROM and my CD-R on it).  I can provide exactly what cdrecord says and any
other info if you wish.

This is on a Performa 5400/180 with an early pull of the 2.4.0 kernel from
bk.  Everything seems to be working fine, except for this (which isn't too
important for me).

Good luck,

--
    .-.        Chris Boot
    /v\     bootc@worldnet.fr
   // \\
  /(   )\   L   I   N   U   X
   ^^-^^   >Phear the Penguin<


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Wed, Jan 31, 2001 at 05:40:24PM +0100, Chris Boot <bootc@worldnet.fr> wrote:
>
> >> It might be something PPC specific as well and have nothing to do with
> >> Paul's drivers.
> >
> > This is why I asked in a previous email whether anyone had ever burned
> > a disk in DAO mode successfully on a pmac or in fact on any powerpc
> > machine, but I've received no responses.  Hmm, maybe I should try to
> > conduct a quick survey of this on linuxppc-user and/or debian-powerpc.
>
> Well, I can't write a dao disk on my Panasonic CW-7502.  cdrecord complains
> that it can't send the cue sheet, but the SCSI bus doesn't die in any way, I
> can still mount and use disks on it afterwards (I only have the built-in
> CD-ROM and my CD-R on it).  I can provide exactly what cdrecord says and any
> other info if you wish.

That would be great -- any additional info that we can get helps.  Is
there a 200 second wait before it fails, or does it fail immediately?

> This is on a Performa 5400/180 with an early pull of the 2.4.0 kernel from
> bk.  Everything seems to be working fine, except for this (which isn't too
> important for me).

What SCSI driver do you use?  (If you don't know offhand, you should be
able to tell from the kernel boot messages.)

If you're willing to do a little bit more work, could you compile a
kernel with all the SCSI debugging support (there are two config
options) enabled, and before you try to burn a disk in DAO mode, type
(as root) "echo scsi log all > /proc/scsi/scsi"?  (The logging will be
turned off again when you next reboot.)  And then send us the resultant
syslog?

My working hypothesis is that there is something powerpc specific that
derails the send_cue_sheet command, but the lockup is because of the
mesh driver not handling the error well.  If this is correct, these
would both be good problems to fix.

Thanks,
Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

SOLVED: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

A patch will have to wait until tomorrow morning, but I have just burned
my first CD in DAO mode!  :-)  The problem was a table in mesh.c and
about four or five other drivers specifying which SCSI commands write
data to the drive (as opposed to reading from it.)  send_cue_sheet
(0x5d) was not in the table, nor mentioned in include/scsi/scsi.h.
Adding the appropriate #define to scsi.h and the appropriate table entry
to mesh.c fixed things nicely!

There are still some issues outstanding:
1)	The same table is duplicated in five or six drivers.  I think it
would make lots of sense to have a macro for the case statment in just
one place.  Should it go in scsi.h?  Or its own new file?

2)	It's a little bit worrisome that the whole mesh bus locks up
because of this.  What if some other unknown SCSI command tries to write
data?  The whole problem will repeat itself.  How do most of the SCSI
drivers avoid needing this information, or from what alternate source do
they get it?  Is there something about OldWorld mac hardware that
particularly makes mesh.c and mac53c94.c need this table?

3)	It continues to be worrisome that the mesh driver doesn't handle
aborts right or retry lost arbitration (nor does mac53c94.)  Is there
anywhere that the way to do these things is documented?  I'm willing to
try my hand at fixing them.

A quick patch will follow in the morning, and based on people's opinions
about issue 1 above, I'll make a more definitive patch to send to Linus
and Alan Cox and whoever one sends these things to.

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SOLVED: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Michael Schmitz]

> A patch will have to wait until tomorrow morning, but I have just burned
> my first CD in DAO mode!  :-)  The problem was a table in mesh.c and
> about four or five other drivers specifying which SCSI commands write
> data to the drive (as opposed to reading from it.)  send_cue_sheet
> (0x5d) was not in the table, nor mentioned in include/scsi/scsi.h.
> Adding the appropriate #define to scsi.h and the appropriate table entry
> to mesh.c fixed things nicely!

Good work :-)

>
> There are still some issues outstanding:
> 1)	The same table is duplicated in five or six drivers.  I think it
> would make lots of sense to have a macro for the case statment in just
> one place.  Should it go in scsi.h?  Or its own new file?

scsi.h is used by all drivers, and describes mostly midlevel stuff. Your
command table is only needed by some lowlevel drivers so it should go into
some separate header included only by those drivers.

Only MHO, ask a Linux SCSI guru.

Better yet, find another way to determine which commands send data from
the command bytes directly (what do all those drivers that don't use the
table use instead?)

> 3)	It continues to be worrisome that the mesh driver doesn't handle
> aborts right or retry lost arbitration (nor does mac53c94.)  Is there
> anywhere that the way to do these things is documented?  I'm willing to
> try my hand at fixing them.

The SCSI specs are probably the authoritative guide here. Plus the MESH
and 53C94 data sheets.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SOLVED: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Fri, Feb 02, 2001 at 01:58:44PM +0100, Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de> wrote:
> > There are still some issues outstanding:
> > 1)	The same table is duplicated in five or six drivers.  I think it
> > would make lots of sense to have a macro for the case statment in just
> > one place.  Should it go in scsi.h?  Or its own new file?
>
> scsi.h is used by all drivers, and describes mostly midlevel stuff. Your
> command table is only needed by some lowlevel drivers so it should go into
> some separate header included only by those drivers.

Sounds reasonable.

> Only MHO, ask a Linux SCSI guru.

I just subscribed to linux-scsi, so I will.

> Better yet, find another way to determine which commands send data from
> the command bytes directly (what do all those drivers that don't use the
> table use instead?)

I'll ask this too.

> > 3)	It continues to be worrisome that the mesh driver doesn't handle
> > aborts right or retry lost arbitration (nor does mac53c94.)  Is there
> > anywhere that the way to do these things is documented?  I'm willing to
> > try my hand at fixing them.
>
> The SCSI specs are probably the authoritative guide here. Plus the MESH
> and 53C94 data sheets.

These would be useful things to have, but it sounds from the comments at
the top of mesh.c and mac53c94 that the interface for this with the rest
of the kernel changed somewhere in the 2.1 series.  So I'm hoping that
the drivers already support the hardware properly, and I mostly want to
know if anyone knows where it's documented how to interact with the
kernel.  I'll ask this on linux-scsi too.  Meanwhile, a patch is coming
up.

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SOLVED: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Benjamin Herrenschmidt]

>The SCSI specs are probably the authoritative guide here. Plus the MESH
>and 53C94 data sheets.

I would add to this list Apple's Darwin MESH driver source that describe
with comments various MESH HW bugs and usual SCSI devices bugs that
confuse MESH, along with workarounds.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SOLVED: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Paul Mackerras]

Daniel Eisenbud writes:

> A patch will have to wait until tomorrow morning, but I have just burned
> my first CD in DAO mode!  :-)  The problem was a table in mesh.c and
> about four or five other drivers specifying which SCSI commands write
> data to the drive (as opposed to reading from it.)  send_cue_sheet
> (0x5d) was not in the table, nor mentioned in include/scsi/scsi.h.
> Adding the appropriate #define to scsi.h and the appropriate table entry
> to mesh.c fixed things nicely!

Great!  It's a long time ago now that I wrote the mesh driver, but
IIRC the mesh works best if the driver can predict what SCSI phases
are going to be needed in what order.  Recall that with SCSI, the
target (i.e. the disk or CD-writer or whatever) controls what kinds of
things (commands, data, messages, status etc.) get transferred on the
SCSI bus and in what direction, and the host is just supposed to obey.
With the mesh the driver sets it up for what would normally happen
next at each stage and if the target actually wants something
different, you get a phase mismatch error.  The driver then needs to
look at what the target wants and set up the mesh to do that.

As I said, it's been a while, and what I don't remember is whether the
mesh gives you a phase mismatch interrupt if you tell it to receive
data (do an IN operation) when the target also expects to receive data
(i.e. do an OUT operation).  I have a vague idea that it might do so
in PIO mode but not in DMA mode or something.  It's quite believable
that the whole thing would lock up in this situation.

> There are still some issues outstanding:
> 1)	The same table is duplicated in five or six drivers.  I think it
> would make lots of sense to have a macro for the case statment in just
> one place.  Should it go in scsi.h?  Or its own new file?

Well, it could be declared in scsi.h but the actual table of values
should go in a .c file.

> 2)	It's a little bit worrisome that the whole mesh bus locks up
> because of this.  What if some other unknown SCSI command tries to write
> data?  The whole problem will repeat itself.  How do most of the SCSI
> drivers avoid needing this information, or from what alternate source do
> they get it?  Is there something about OldWorld mac hardware that
> particularly makes mesh.c and mac53c94.c need this table?

See above.  I spent many long evenings back maybe 4 years ago
hammering on the mesh in my 7500, trying to get the driver to handle
all the possible situations that can arise.  I recall also that there
are bugs in the mesh that I had to work around.  The mesh is
documented in Apple's "Macintosh Technology in CHRP" document
reasonably well, but as a specification rather than as a user's manual
which might warn you about potential problems.

The 53c94 is another story; I never found any decent documentation for
it, I just had to work from the open firmware methods for it plus some
other drivers which seemed to be for similar chips.  I got the
mac53c94 driver to the stage where it seemed to work mostly but I
never had the time and the motivation to stress-test it and to
implement things like disconnect/reconnect.

> 3)	It continues to be worrisome that the mesh driver doesn't handle
> aborts right or retry lost arbitration (nor does mac53c94.)  Is there
> anywhere that the way to do these things is documented?  I'm willing to
> try my hand at fixing them.

I was never sure exactly how the higher levels of the scsi code
expected the host adaptor drivers (like mesh.c) to do aborts.  At the
time I tried to read the code but I found it to be quite opaque; it
was very complicated and not very well structured.  I haven't looked
at it lately, although I know Alan Cox was trying to tidy it up a bit
at one stage.

I thought the mesh driver did retry lost arbitration though.

If you want to try to fix the problems and implement the aborts and
resets properly, that would be great.  You would at least need a copy
of the SCSI-2 standard (or at least a late draft) plus the "Macintosh
Technology in CHRP" document.

Ideally the driver should cope with the target wanting to do an OUT
when we expect to do an IN, which would make it less critical that the
data_goes_out() function is correct.  The critical thing to find out
is whether the mesh gives you a phase mismatch exception in the case
where the target is expecting to do an OUT phase (i.e. receive data)
but we tell the mesh to do an IN phase with DMA.

> A quick patch will follow in the morning, and based on people's opinions
> about issue 1 above, I'll make a more definitive patch to send to Linus
> and Alan Cox and whoever one sends these things to.

I would very much like to see the proposed patches before they are
sent to Linus & Alan.

Paul.

--
Paul Mackerras, Open Source Research Fellow, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SOLVED: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Sat, Feb 03, 2001 at 03:19:18PM +1100, Paul Mackerras <paulus@linuxcare.com.au> wrote:
> Daniel Eisenbud writes:
[...]
> As I said, it's been a while, and what I don't remember is whether the
> mesh gives you a phase mismatch interrupt if you tell it to receive
> data (do an IN operation) when the target also expects to receive data
> (i.e. do an OUT operation).  I have a vague idea that it might do so
> in PIO mode but not in DMA mode or something.  It's quite believable
> that the whole thing would lock up in this situation.

Ah.

> > There are still some issues outstanding:
> > 1)	The same table is duplicated in five or six drivers.  I think it
> > would make lots of sense to have a macro for the case statment in just
> > one place.  Should it go in scsi.h?  Or its own new file?
>
> Well, it could be declared in scsi.h but the actual table of values
> should go in a .c file.

My current patch has a static function in the new file scsi_dataout.h,
which is included by all the drivers in question.   But I agree that it
would be cleaner to declare the function in scsi.h, change
scsi_dataout.h to scsi_dataout.c, make the function no longer static,
and tell make about the dependencies.  I'll do that.

> > 3)	It continues to be worrisome that the mesh driver doesn't handle
> > aborts right or retry lost arbitration (nor does mac53c94.)  Is there
> > anywhere that the way to do these things is documented?  I'm willing to
> > try my hand at fixing them.
>
> I was never sure exactly how the higher levels of the scsi code
> expected the host adaptor drivers (like mesh.c) to do aborts.  At the
> time I tried to read the code but I found it to be quite opaque; it
> was very complicated and not very well structured.  I haven't looked
> at it lately, although I know Alan Cox was trying to tidy it up a bit
> at one stage.

I'll take a look...

> I thought the mesh driver did retry lost arbitration though.

The comment at the top of the file says that it doesn't, but that's as
far as I've investigated so far.  It may be that you just didn't get
around to changing the comment?

> If you want to try to fix the problems and implement the aborts and
> resets properly, that would be great.  You would at least need a copy
> of the SCSI-2 standard (or at least a late draft) plus the "Macintosh
> Technology in CHRP" document.

Are these available on the net, or would I have to order paper copies
from somewhere?

> > A quick patch will follow in the morning, and based on people's opinions
> > about issue 1 above, I'll make a more definitive patch to send to Linus
> > and Alan Cox and whoever one sends these things to.
>
> I would very much like to see the proposed patches before they are
> sent to Linus & Alan.

I'll be glad to show them to you first.

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SOLVED: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

On Sat, Feb 03, 2001 at 11:14:27AM -0500, Daniel Eisenbud <eisenbud@cs.swarthmore.edu> wrote:
> On Sat, Feb 03, 2001 at 03:19:18PM +1100, Paul Mackerras <paulus@linuxcare.com.au> wrote:
[...]
> > Well, it could be declared in scsi.h but the actual table of values
> > should go in a .c file.
>
> My current patch has a static function in the new file scsi_dataout.h,
> which is included by all the drivers in question.   But I agree that it
> would be cleaner to declare the function in scsi.h, change
> scsi_dataout.h to scsi_dataout.c, make the function no longer static,
> and tell make about the dependencies.  I'll do that.

The advantage of my current approach is that there are two SCSI drivers
(for acorn and i2o) that use copies of this table but that live outside
of drivers/scsi.  They already include scsi.h, and it's easy to make
them include scsi_dataout.h.  For the files inside drivers/scsi, it's
easy to see how to make them depend on scsi_dataout.o, but it's not
obvious to me how it should work for files that live elsewhere.  Am I
missing something obvious?

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

PATCH: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Daniel Eisenbud]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

On Sat, Feb 03, 2001 at 11:27:05AM -0500, Daniel Eisenbud <eisenbud@cs.swarthmore.edu> wrote:
> On Sat, Feb 03, 2001 at 11:14:27AM -0500, Daniel Eisenbud <eisenbud@cs.swarthmore.edu> wrote:
> > On Sat, Feb 03, 2001 at 03:19:18PM +1100, Paul Mackerras <paulus@linuxcare.com.au> wrote:
> [...]
> > > Well, it could be declared in scsi.h but the actual table of values
> > > should go in a .c file.
> >
> > My current patch has a static function in the new file scsi_dataout.h,
> > which is included by all the drivers in question.   But I agree that it
> > would be cleaner to declare the function in scsi.h, change
> > scsi_dataout.h to scsi_dataout.c, make the function no longer static,
> > and tell make about the dependencies.  I'll do that.
>
> The advantage of my current approach is that there are two SCSI drivers
> (for acorn and i2o) that use copies of this table but that live outside
> of drivers/scsi.  They already include scsi.h, and it's easy to make
> them include scsi_dataout.h.  For the files inside drivers/scsi, it's
> easy to see how to make them depend on scsi_dataout.o, but it's not
> obvious to me how it should work for files that live elsewhere.  Am I
> missing something obvious?

Here's the patch aginst the 2.4 bitkeeper tree.  The only hunk that
should fail against 2.2, though, is the include/scsi/scsi.h one, which
is trivial to fix.  Please let me know if it would be better either to
put the function I've addeed in a .c file instead, or to just change all
the different drivers' tables directly.

Meanwhile, I'll start trying to get a clue about the SCSI layer's abort
handling.

-Daniel

--
Daniel E. Eisenbud
eisenbud@cs.swarthmore.edu

[-- Attachment #2: scsi-patch-2_4 --]
[-- Type: text/plain, Size: 19771 bytes --]

diff -durpN linuxppc_2_4/drivers/acorn/scsi/acornscsi.c linuxppc_2_4-scsifix/drivers/acorn/scsi/acornscsi.c
--- linuxppc_2_4/drivers/acorn/scsi/acornscsi.c	Fri Jan 12 16:57:57 2001
+++ linuxppc_2_4-scsifix/drivers/acorn/scsi/acornscsi.c	Sat Feb  3 12:02:04 2001
@@ -152,6 +152,7 @@
 #include <asm/ecard.h>

 #include "../../scsi/scsi.h"
+#include "../../scsi/scsi_dataout.h"
 #include "../../scsi/hosts.h"
 #include "../../scsi/constants.h"
 #include "acornscsi.h"
@@ -600,34 +601,6 @@ cmdtype_t acornscsi_cmdtype(int command)
 }

 /*
- * Prototype: int acornscsi_datadirection(int command)
- * Purpose  : differentiate between commands that have a DATA IN phase
- *	      and a DATA OUT phase
- * Params   : command - command to interpret
- * Returns  : DATADIR_OUT - data out phase expected
- *	      DATADIR_IN  - data in phase expected
- */
-static
-datadir_t acornscsi_datadirection(int command)
-{
-    switch (command) {
-    case CHANGE_DEFINITION:	case COMPARE:		case COPY:
-    case COPY_VERIFY:		case LOG_SELECT:	case MODE_SELECT:
-    case MODE_SELECT_10:	case SEND_DIAGNOSTIC:	case WRITE_BUFFER:
-    case FORMAT_UNIT:		case REASSIGN_BLOCKS:	case RESERVE:
-    case SEARCH_EQUAL:		case SEARCH_HIGH:	case SEARCH_LOW:
-    case WRITE_6:		case WRITE_10:		case WRITE_VERIFY:
-    case UPDATE_BLOCK:		case WRITE_LONG:	case WRITE_SAME:
-    case SEARCH_HIGH_12:	case SEARCH_EQUAL_12:	case SEARCH_LOW_12:
-    case WRITE_12:		case WRITE_VERIFY_12:	case SET_WINDOW:
-    case MEDIUM_SCAN:		case SEND_VOLUME_TAG:	case 0xea:
-	return DATADIR_OUT;
-    default:
-	return DATADIR_IN;
-    }
-}
-
-/*
  * Purpose  : provide values for synchronous transfers with 33C93.
  * Copyright: Copyright (c) 1996 John Shifflett, GeoLog Consulting
  *	Modified by Russell King for 8MHz WD33C93A
@@ -2552,7 +2525,7 @@ int acornscsi_queuecmd(Scsi_Cmnd *SCpnt,
     SCpnt->host_scribble = NULL;
     SCpnt->result = 0;
     SCpnt->tag = 0;
-    SCpnt->SCp.phase = (int)acornscsi_datadirection(SCpnt->cmnd[0]);
+    SCpnt->SCp.phase = Scsi_data_goes_out(SCpnt);
     SCpnt->SCp.sent_command = 0;
     SCpnt->SCp.scsi_xferred = 0;
     SCpnt->SCp.Status = 0;
diff -durpN linuxppc_2_4/drivers/acorn/scsi/acornscsi.h linuxppc_2_4-scsifix/drivers/acorn/scsi/acornscsi.h
--- linuxppc_2_4/drivers/acorn/scsi/acornscsi.h	Fri Jan 12 16:57:57 2001
+++ linuxppc_2_4-scsifix/drivers/acorn/scsi/acornscsi.h	Fri Feb  2 18:36:48 2001
@@ -288,14 +288,6 @@ typedef enum {					/* command type				*/
     CMD_MISC,					/* Others				*/
 } cmdtype_t;

-/*
- * Data phase direction
- */
-typedef enum {					/* Data direction			*/
-    DATADIR_IN,					/* Data in phase expected		*/
-    DATADIR_OUT					/* Data out phase expected		*/
-} datadir_t;
-
 #include "queue.h"
 #include "msgqueue.h"

diff -durpN linuxppc_2_4/drivers/i2o/i2o_scsi.c linuxppc_2_4-scsifix/drivers/i2o/i2o_scsi.c
--- linuxppc_2_4/drivers/i2o/i2o_scsi.c	Fri Jan 12 16:58:05 2001
+++ linuxppc_2_4-scsifix/drivers/i2o/i2o_scsi.c	Fri Feb  2 18:36:48 2001
@@ -49,6 +49,7 @@
 #include <linux/version.h>
 #include <linux/i2o.h>
 #include "../scsi/scsi.h"
+#include "../scsi/scsi_dataout.h"
 #include "../scsi/hosts.h"
 #include "../scsi/sd.h"
 #include "i2o_scsi.h"
@@ -494,35 +495,6 @@ const char *i2o_scsi_info(struct Scsi_Ho
 	return(&hostdata->controller->name[0]);
 }

-
-/*
- * From the wd93 driver:
- * Returns true if there will be a DATA_OUT phase with this command,
- * false otherwise.
- * (Thanks to Joerg Dorchain for the research and suggestion.)
- *
- */
-static int is_dir_out(Scsi_Cmnd *cmd)
-{
-	switch (cmd->cmnd[0])
-	{
-     		case WRITE_6:           case WRITE_10:          case WRITE_12:
-      		case WRITE_LONG:        case WRITE_SAME:        case WRITE_BUFFER:
-      		case WRITE_VERIFY:      case WRITE_VERIFY_12:
-      		case COMPARE:           case COPY:              case COPY_VERIFY:
-      		case SEARCH_EQUAL:      case SEARCH_HIGH:       case SEARCH_LOW:
-      		case SEARCH_EQUAL_12:   case SEARCH_HIGH_12:    case SEARCH_LOW_12:
-      		case FORMAT_UNIT:       case REASSIGN_BLOCKS:   case RESERVE:
-      		case MODE_SELECT:       case MODE_SELECT_10:    case LOG_SELECT:
-      		case SEND_DIAGNOSTIC:   case CHANGE_DEFINITION: case UPDATE_BLOCK:
-      		case SET_WINDOW:        case MEDIUM_SCAN:       case SEND_VOLUME_TAG:
-      		case 0xea:
-        		return 1;
-		default:
-        		return 0;
-	}
-}
-
 int i2o_scsi_queuecommand(Scsi_Cmnd * SCpnt, void (*done) (Scsi_Cmnd *))
 {
 	int i;
@@ -604,7 +576,7 @@ int i2o_scsi_queuecommand(Scsi_Cmnd * SC
 	scsidir = 0x00000000;			// DATA NO XFER
 	if(len)
 	{
-		if(is_dir_out(SCpnt))
+		if(Scsi_data_goes_out(SCpnt))
 		{
 			direction=0x04000000;	// SGL OUT  (osm-->iop)
 			scsidir  =0x80000000;	// DATA OUT (iop-->dev)
diff -durpN linuxppc_2_4/drivers/scsi/eata_dma.c linuxppc_2_4-scsifix/drivers/scsi/eata_dma.c
--- linuxppc_2_4/drivers/scsi/eata_dma.c	Fri Jan 12 16:58:28 2001
+++ linuxppc_2_4-scsifix/drivers/scsi/eata_dma.c	Fri Feb  2 18:36:48 2001
@@ -84,6 +84,7 @@
 #endif
 #include <linux/blk.h>
 #include "scsi.h"
+#include "scsi_dataout.h"
 #include "sd.h"
 #include "hosts.h"
 #include "eata_dma.h"
@@ -522,24 +523,10 @@ int eata_queue(Scsi_Cmnd * cmd, void (*

     cmd->scsi_done = (void *)done;

-    switch (cmd->cmnd[0]) {
-    case CHANGE_DEFINITION: case COMPARE:	  case COPY:
-    case COPY_VERIFY:	    case LOG_SELECT:	  case MODE_SELECT:
-    case MODE_SELECT_10:    case SEND_DIAGNOSTIC: case WRITE_BUFFER:
-    case FORMAT_UNIT:	    case REASSIGN_BLOCKS: case RESERVE:
-    case SEARCH_EQUAL:	    case SEARCH_HIGH:	  case SEARCH_LOW:
-    case WRITE_6:	    case WRITE_10:	  case WRITE_VERIFY:
-    case UPDATE_BLOCK:	    case WRITE_LONG:	  case WRITE_SAME:
-    case SEARCH_HIGH_12:    case SEARCH_EQUAL_12: case SEARCH_LOW_12:
-    case WRITE_12:	    case WRITE_VERIFY_12: case SET_WINDOW:
-    case MEDIUM_SCAN:	    case SEND_VOLUME_TAG:
-    case 0xea:	    /* alternate number for WRITE LONG */
+    if (Scsi_data_goes_out(cmd))
 	ccb->DataOut = TRUE;	/* Output mode */
-	break;
-    case TEST_UNIT_READY:
-    default:
+    else
 	ccb->DataIn = TRUE;	/* Input mode  */
-    }

     /* FIXME: This will will have to be changed once the midlevel driver
      *        allows different HBA IDs on every channel.
diff -durpN linuxppc_2_4/drivers/scsi/eata_pio.c linuxppc_2_4-scsifix/drivers/scsi/eata_pio.c
--- linuxppc_2_4/drivers/scsi/eata_pio.c	Fri Jan 12 16:58:28 2001
+++ linuxppc_2_4-scsifix/drivers/scsi/eata_pio.c	Fri Feb  2 18:36:48 2001
@@ -50,7 +50,7 @@
 #include <asm/io.h>
 #include "eata_pio.h"
 #include "eata_dma_proc.h"
-#include "scsi.h"
+#include "scsi_dataout.h"
 #include "sd.h"

 #include <linux/stat.h>
@@ -325,24 +325,10 @@ int eata_pio_queue(Scsi_Cmnd * cmd, void

     cmd->scsi_done = (void *)done;

-    switch (cmd->cmnd[0]) {
-    case CHANGE_DEFINITION: case COMPARE:         case COPY:
-    case COPY_VERIFY:       case LOG_SELECT:      case MODE_SELECT:
-    case MODE_SELECT_10:    case SEND_DIAGNOSTIC: case WRITE_BUFFER:
-    case FORMAT_UNIT:       case REASSIGN_BLOCKS: case RESERVE:
-    case SEARCH_EQUAL:      case SEARCH_HIGH:     case SEARCH_LOW:
-    case WRITE_6:           case WRITE_10:        case WRITE_VERIFY:
-    case UPDATE_BLOCK:      case WRITE_LONG:      case WRITE_SAME:
-    case SEARCH_HIGH_12:    case SEARCH_EQUAL_12: case SEARCH_LOW_12:
-    case WRITE_12:          case WRITE_VERIFY_12: case SET_WINDOW:
-    case MEDIUM_SCAN:       case SEND_VOLUME_TAG:
-    case 0xea:      /* alternate number for WRITE LONG */
+    if (Scsi_data_goes_out(cmd))
 	cp->DataOut = TRUE; /* Output mode */
-	break;
-    case TEST_UNIT_READY:
-    default:
+    else
 	cp->DataIn = TRUE;  /* Input mode  */
-    }

     cp->Interpret = (cmd->target == hd->hostid);
     cp->cp_datalen = htonl((ulong)cmd->request_bufflen);
diff -durpN linuxppc_2_4/drivers/scsi/in2000.c linuxppc_2_4-scsifix/drivers/scsi/in2000.c
--- linuxppc_2_4/drivers/scsi/in2000.c	Thu Jan 25 02:58:36 2001
+++ linuxppc_2_4-scsifix/drivers/scsi/in2000.c	Fri Feb  2 18:36:48 2001
@@ -119,6 +119,7 @@
 #include <linux/stat.h>

 #include "scsi.h"
+#include "scsi_dataout.h"
 #include "sd.h"
 #include "hosts.h"

@@ -251,34 +252,6 @@ unsigned long value;
    return value;
 }

-
-/* The 33c93 needs to be told which direction a command transfers its
- * data; we use this function to figure it out. Returns true if there
- * will be a DATA_OUT phase with this command, false otherwise.
- * (Thanks to Joerg Dorchain for the research and suggestion.)
- */
-static int is_dir_out(Scsi_Cmnd *cmd)
-{
-   switch (cmd->cmnd[0]) {
-      case WRITE_6:           case WRITE_10:          case WRITE_12:
-      case WRITE_LONG:        case WRITE_SAME:        case WRITE_BUFFER:
-      case WRITE_VERIFY:      case WRITE_VERIFY_12:
-      case COMPARE:           case COPY:              case COPY_VERIFY:
-      case SEARCH_EQUAL:      case SEARCH_HIGH:       case SEARCH_LOW:
-      case SEARCH_EQUAL_12:   case SEARCH_HIGH_12:    case SEARCH_LOW_12:
-      case FORMAT_UNIT:       case REASSIGN_BLOCKS:   case RESERVE:
-      case MODE_SELECT:       case MODE_SELECT_10:    case LOG_SELECT:
-      case SEND_DIAGNOSTIC:   case CHANGE_DEFINITION: case UPDATE_BLOCK:
-      case SET_WINDOW:        case MEDIUM_SCAN:       case SEND_VOLUME_TAG:
-      case 0xea:
-         return 1;
-      default:
-         return 0;
-      }
-}
-
-
-
 static struct sx_period sx_table[] = {
    {  1, 0x20},
    {252, 0x20},
@@ -492,7 +465,7 @@ DB(DB_EXECUTE,printk(")EX-1 "))
  * Start the selection process
  */

-   if (is_dir_out(cmd))
+   if (Scsi_data_goes_out(cmd))
       write_3393(hostdata,WD_DESTINATION_ID, cmd->target);
    else
       write_3393(hostdata,WD_DESTINATION_ID, cmd->target | DSTID_DPD);
@@ -642,7 +615,7 @@ no:
          write_3393(hostdata,WD_CONTROL, CTRL_IDI | CTRL_EDI | CTRL_BUS);
          write1_io(0, IO_FIFO_WRITE);  /* clear fifo counter, write mode */

-         if (is_dir_out(cmd)) {
+         if (Scsi_data_goes_out(cmd)) {
             hostdata->fifo = FI_FIFO_WRITING;
             if ((i = cmd->SCp.this_residual) > (IN2000_FIFO_SIZE - 16) )
                i = IN2000_FIFO_SIZE - 16;
@@ -1584,7 +1557,7 @@ DB(DB_INTR,printk("RESEL"))
     * But we DO need to fix the DPD bit so it's correct for this command.
     */

-         if (is_dir_out(cmd))
+         if (Scsi_data_goes_out(cmd))
             write_3393(hostdata,WD_DESTINATION_ID,cmd->target);
          else
             write_3393(hostdata,WD_DESTINATION_ID,cmd->target | DSTID_DPD);
diff -durpN linuxppc_2_4/drivers/scsi/mac53c94.c linuxppc_2_4-scsifix/drivers/scsi/mac53c94.c
--- linuxppc_2_4/drivers/scsi/mac53c94.c	Thu Jan 25 02:58:36 2001
+++ linuxppc_2_4-scsifix/drivers/scsi/mac53c94.c	Fri Feb  2 18:36:48 2001
@@ -23,6 +23,7 @@
 #include <asm/system.h>

 #include "scsi.h"
+#include "scsi_dataout.h"
 #include "hosts.h"
 #include "mac53c94.h"

@@ -58,7 +59,6 @@ static void mac53c94_interrupt(int, void
 static void do_mac53c94_interrupt(int, void *, struct pt_regs *);
 static void cmd_done(struct fsc_state *, int result);
 static void set_dma_cmds(struct fsc_state *, Scsi_Cmnd *);
-static int data_goes_out(Scsi_Cmnd *);

 int
 mac53c94_detect(Scsi_Host_Template *tp)
@@ -154,7 +154,7 @@ mac53c94_queue(Scsi_Cmnd *cmd, void (*do
 	struct fsc_state *state;

 #if 0
-	if (data_goes_out(cmd)) {
+	if (Scsi_data_goes_out(cmd)) {
 		int i;
 		printk(KERN_DEBUG "mac53c94_queue %p: command is", cmd);
 		for (i = 0; i < cmd->cmd_len; ++i)
@@ -480,7 +480,7 @@ set_dma_cmds(struct fsc_state *state, Sc
 	struct scatterlist *scl;
 	struct dbdma_cmd *dcmds;

-	dma_cmd = data_goes_out(cmd)? OUTPUT_MORE: INPUT_MORE;
+	dma_cmd = Scsi_data_goes_out(cmd)? OUTPUT_MORE: INPUT_MORE;
 	dcmds = state->dma_cmds;
 	if (cmd->use_sg > 0) {
 		total = 0;
@@ -509,51 +509,6 @@ set_dma_cmds(struct fsc_state *state, Sc
 	st_le16(&dcmds[-1].command, dma_cmd);
 	st_le16(&dcmds->command, DBDMA_STOP);
 	cmd->SCp.this_residual = total;
-}
-
-/*
- * Work out whether data will be going out from the host adaptor or into it.
- * (If this information is available from somewhere else in the scsi
- * code, somebody please let me know :-)
- */
-static int
-data_goes_out(Scsi_Cmnd *cmd)
-{
-	switch (cmd->cmnd[0]) {
-	case CHANGE_DEFINITION:
-	case COMPARE:
-	case COPY:
-	case COPY_VERIFY:
-	case FORMAT_UNIT:
-	case LOG_SELECT:
-	case MEDIUM_SCAN:
-	case MODE_SELECT:
-	case MODE_SELECT_10:
-	case REASSIGN_BLOCKS:
-	case RESERVE:
-	case SEARCH_EQUAL:
-	case SEARCH_EQUAL_12:
-	case SEARCH_HIGH:
-	case SEARCH_HIGH_12:
-	case SEARCH_LOW:
-	case SEARCH_LOW_12:
-	case SEND_DIAGNOSTIC:
-	case SEND_VOLUME_TAG:
-	case SET_WINDOW:
-	case UPDATE_BLOCK:
-	case WRITE_BUFFER:
- 	case WRITE_6:
-	case WRITE_10:
-	case WRITE_12:
-	case WRITE_LONG:
-	case WRITE_LONG_2:      /* alternate code for WRITE_LONG */
-	case WRITE_SAME:
-	case WRITE_VERIFY:
-	case WRITE_VERIFY_12:
-		return 1;
-	default:
-		return 0;
-	}
 }

 static Scsi_Host_Template driver_template = SCSI_MAC53C94;
diff -durpN linuxppc_2_4/drivers/scsi/mesh.c linuxppc_2_4-scsifix/drivers/scsi/mesh.c
--- linuxppc_2_4/drivers/scsi/mesh.c	Fri Jan 12 16:58:29 2001
+++ linuxppc_2_4-scsifix/drivers/scsi/mesh.c	Fri Feb  2 18:36:48 2001
@@ -31,6 +31,7 @@
 #include <asm/feature.h>

 #include "scsi.h"
+#include "scsi_dataout.h"
 #include "hosts.h"
 #include "mesh.h"

@@ -208,7 +209,6 @@ static void mesh_done(struct mesh_state
 static void mesh_completed(struct mesh_state *, Scsi_Cmnd *);
 static void set_dma_cmds(struct mesh_state *, Scsi_Cmnd *);
 static void halt_dma(struct mesh_state *);
-static int data_goes_out(Scsi_Cmnd *);
 static void do_abort(struct mesh_state *ms);

 static struct notifier_block mesh_notifier = {
@@ -565,7 +565,7 @@ mesh_start_cmd(struct mesh_state *ms, Sc
 	int t;

 	ms->current_req = cmd;
-	ms->tgts[cmd->target].data_goes_out = data_goes_out(cmd);
+	ms->tgts[cmd->target].data_goes_out = Scsi_data_goes_out(cmd);
 	ms->tgts[cmd->target].current_req = cmd;

 #if 1
@@ -1794,51 +1794,6 @@ halt_dma(struct mesh_state *ms)
 		       ms->tgts[ms->conn_tgt].data_goes_out);
 	}
 	ms->dma_started = 0;
-}
-
-/*
- * Work out whether we expect data to go out from the host adaptor or into it.
- * (If this information is available from somewhere else in the scsi
- * code, somebody please let me know :-)
- */
-static int
-data_goes_out(Scsi_Cmnd *cmd)
-{
-	switch (cmd->cmnd[0]) {
-	case CHANGE_DEFINITION:
-	case COMPARE:
-	case COPY:
-	case COPY_VERIFY:
-	case FORMAT_UNIT:
-	case LOG_SELECT:
-	case MEDIUM_SCAN:
-	case MODE_SELECT:
-	case MODE_SELECT_10:
-	case REASSIGN_BLOCKS:
-	case RESERVE:
-	case SEARCH_EQUAL:
-	case SEARCH_EQUAL_12:
-	case SEARCH_HIGH:
-	case SEARCH_HIGH_12:
-	case SEARCH_LOW:
-	case SEARCH_LOW_12:
-	case SEND_DIAGNOSTIC:
-	case SEND_VOLUME_TAG:
-	case SET_WINDOW:
-	case UPDATE_BLOCK:
-	case WRITE_BUFFER:
- 	case WRITE_6:
-	case WRITE_10:
-	case WRITE_12:
-	case WRITE_LONG:
-	case WRITE_LONG_2:      /* alternate code for WRITE_LONG */
-	case WRITE_SAME:
-	case WRITE_VERIFY:
-	case WRITE_VERIFY_12:
-		return 1;
-	default:
-		return 0;
-	}
 }

 #ifdef MESH_DBG
diff -durpN linuxppc_2_4/drivers/scsi/scsi_dataout.h linuxppc_2_4-scsifix/drivers/scsi/scsi_dataout.h
--- linuxppc_2_4/drivers/scsi/scsi_dataout.h	Wed Dec 31 19:00:00 1969
+++ linuxppc_2_4-scsifix/drivers/scsi/scsi_dataout.h	Fri Feb  2 18:36:48 2001
@@ -0,0 +1,49 @@
+/*
+ * This was copied from mesh.c to keep us from needing six copies of it in
+ * different drivers.  SEND_CUE_SHEET was added to make burning CD-Rs in DAO
+ * mode work with these drivers.
+ *
+ * Work out whether data will be going out from the host adaptor or into it.
+ * (If this information is available from somewhere else in the scsi
+ * code, somebody please let me know :-)
+ */
+static int
+Scsi_data_goes_out(Scsi_Cmnd *cmd)
+{
+	switch (cmd->cmnd[0]) {
+	case CHANGE_DEFINITION:
+	case COMPARE:
+	case COPY:
+	case COPY_VERIFY:
+	case FORMAT_UNIT:
+	case LOG_SELECT:
+	case MEDIUM_SCAN:
+	case MODE_SELECT:
+	case MODE_SELECT_10:
+	case REASSIGN_BLOCKS:
+	case RESERVE:
+	case SEARCH_EQUAL:
+	case SEARCH_EQUAL_12:
+	case SEARCH_HIGH:
+	case SEARCH_HIGH_12:
+	case SEARCH_LOW:
+	case SEARCH_LOW_12:
+	case SEND_CUE_SHEET:
+	case SEND_DIAGNOSTIC:
+	case SEND_VOLUME_TAG:
+	case SET_WINDOW:
+	case UPDATE_BLOCK:
+	case WRITE_BUFFER:
+ 	case WRITE_6:
+	case WRITE_10:
+	case WRITE_12:
+	case WRITE_LONG:
+	case WRITE_LONG_2:      /* alternate code for WRITE_LONG */
+	case WRITE_SAME:
+	case WRITE_VERIFY:
+	case WRITE_VERIFY_12:
+		return 1;
+	default:
+		return 0;
+	}
+}
diff -durpN linuxppc_2_4/drivers/scsi/wd33c93.c linuxppc_2_4-scsifix/drivers/scsi/wd33c93.c
--- linuxppc_2_4/drivers/scsi/wd33c93.c	Fri Jan 12 16:58:34 2001
+++ linuxppc_2_4-scsifix/drivers/scsi/wd33c93.c	Fri Feb  2 18:36:48 2001
@@ -86,6 +86,7 @@
 #include <linux/blk.h>

 #include "scsi.h"
+#include "scsi_dataout.h"
 #include "hosts.h"


@@ -244,34 +245,6 @@ unsigned long value;
    return value;
 }

-
-/* The 33c93 needs to be told which direction a command transfers its
- * data; we use this function to figure it out. Returns true if there
- * will be a DATA_OUT phase with this command, false otherwise.
- * (Thanks to Joerg Dorchain for the research and suggestion.)
- */
-static int is_dir_out(Scsi_Cmnd *cmd)
-{
-   switch (cmd->cmnd[0]) {
-      case WRITE_6:           case WRITE_10:          case WRITE_12:
-      case WRITE_LONG:        case WRITE_SAME:        case WRITE_BUFFER:
-      case WRITE_VERIFY:      case WRITE_VERIFY_12:
-      case COMPARE:           case COPY:              case COPY_VERIFY:
-      case SEARCH_EQUAL:      case SEARCH_HIGH:       case SEARCH_LOW:
-      case SEARCH_EQUAL_12:   case SEARCH_HIGH_12:    case SEARCH_LOW_12:
-      case FORMAT_UNIT:       case REASSIGN_BLOCKS:   case RESERVE:
-      case MODE_SELECT:       case MODE_SELECT_10:    case LOG_SELECT:
-      case SEND_DIAGNOSTIC:   case CHANGE_DEFINITION: case UPDATE_BLOCK:
-      case SET_WINDOW:        case MEDIUM_SCAN:       case SEND_VOLUME_TAG:
-      case 0xea:
-         return 1;
-      default:
-         return 0;
-      }
-}
-
-
-
 static struct sx_period sx_table[] = {
    {  1, 0x20},
    {252, 0x20},
@@ -478,7 +451,7 @@ DB(DB_EXECUTE,printk(")EX-1 "))
     * Start the selection process
     */

-   if (is_dir_out(cmd))
+   if (Scsi_data_goes_out(cmd))
       write_wd33c93(regp, WD_DESTINATION_ID, cmd->target);
    else
       write_wd33c93(regp, WD_DESTINATION_ID, cmd->target | DSTID_DPD);
@@ -611,7 +584,7 @@ no:

       if ((cmd->SCp.phase == 0) && (hostdata->no_dma == 0)) {
          if (hostdata->dma_setup(cmd,
-                     (is_dir_out(cmd))?DATA_OUT_DIR:DATA_IN_DIR))
+                     (Scsi_data_goes_out(cmd))?DATA_OUT_DIR:DATA_IN_DIR))
             write_wd33c93_count(regp,0); /* guarantee a DATA_PHASE interrupt */
          else {
             write_wd33c93_count(regp, cmd->SCp.this_residual);
@@ -1385,7 +1358,7 @@ DB(DB_INTR,printk("RESEL%s", sr == CSR_R
     * But we DO need to fix the DPD bit so it's correct for this command.
     */

-         if (is_dir_out(cmd))
+         if (Scsi_data_goes_out(cmd))
             write_wd33c93(regp, WD_DESTINATION_ID, cmd->target);
          else
             write_wd33c93(regp, WD_DESTINATION_ID, cmd->target | DSTID_DPD);
diff -durpN linuxppc_2_4/include/scsi/scsi.h linuxppc_2_4-scsifix/include/scsi/scsi.h
--- linuxppc_2_4/include/scsi/scsi.h	Fri Jan 12 16:59:00 2001
+++ linuxppc_2_4-scsifix/include/scsi/scsi.h	Fri Feb  2 18:39:50 2001
@@ -76,6 +76,7 @@
 #define RESERVE_10            0x56
 #define RELEASE_10            0x57
 #define MODE_SENSE_10         0x5a
+#define SEND_CUE_SHEET	      0x5d
 #define PERSISTENT_RESERVE_IN 0x5e
 #define PERSISTENT_RESERVE_OUT 0x5f
 #define MOVE_MEDIUM           0xa5

Re: SOLVED: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Michael Schmitz]

> As I said, it's been a while, and what I don't remember is whether the
> mesh gives you a phase mismatch interrupt if you tell it to receive
> data (do an IN operation) when the target also expects to receive data
> (i.e. do an OUT operation).  I have a vague idea that it might do so
> in PIO mode but not in DMA mode or something.  It's quite believable
> that the whole thing would lock up in this situation.

You probably check for this explicitly in PIO mode. Phase mismatch usually
happens if the target goes from data to message phase due to errors (I
haven't seen the MESH specs so I'm speculating here).

> The 53c94 is another story; I never found any decent documentation for
> it, I just had to work from the open firmware methods for it plus some
> other drivers which seemed to be for similar chips.  I got the
> mac53c94 driver to the stage where it seemed to work mostly but I
> never had the time and the motivation to stress-test it and to
> implement things like disconnect/reconnect.

Disconnect and reselect are implemented in the ESP driver which was used
as template for the 68k Mac 53C9x driver at one time. Maybe take a
page or two from these drivers to implement disconnect. That driver uses a
trick that might help avoiding the data direction lockup with MESH as
well: the chip is programmed for the whole arbitration/selection/command
phases but will interrupt right before data phase, at which point you
could check the data direction before setting up the DMA (assuming the
target asserts the data direction after seeing the command byte). One
additional interrupt taken. No additional overhead if you skip this step
for some well known commands like WRITE_* and READ_* :-)

> > 3)	It continues to be worrisome that the mesh driver doesn't handle
> > aborts right or retry lost arbitration (nor does mac53c94.)  Is there
> > anywhere that the way to do these things is documented?  I'm willing to
> > try my hand at fixing them.
>
> I was never sure exactly how the higher levels of the scsi code
> expected the host adaptor drivers (like mesh.c) to do aborts.  At the

The main pitfall used to be that active and disonnected commands needed
to be removed  from the host adapter queue on a bus or host reset, and
their completion routine had to be called to terminate the command with
error (thereby stopping the midlevel timeout).
Plain command aborts are tricky because you need to act differently for
commands that are in the process of being sent to the device,
disconnected, or actively transfering data (removing commands from the
host queue that haven't been issued yet is rather trivial). The easiest
course of action (read: cop-out) for a command that's being issued or
transfering data is to reset the bus.

The new SCSI error handling code was/is supposed to simplify all of this,
I just never got around to figuring out how it works. If someone could
point me to a SCSI errorhandling HOWTO that'd be much appreciated.

	Michael

P.S:: Daniel, I can send a copy of the SCSI-2 spec if you need it.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SOLVED: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Geert Uytterhoeven]

On Sun, 4 Feb 2001, Michael Schmitz wrote:
> P.S:: Daniel, I can send a copy of the SCSI-2 spec if you need it.

And I can send a copy of the CHRP MacTech spec.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Geert Uytterhoeven]

On Tue, 30 Jan 2001, Michael Schmitz wrote:
> > So the only points in common seem to be that the DVD drives are running
> > on mac hardware and that the drivers are written by Paul Mackerras.  :-)
> > I don't at all mean to impugn Paul's coding ability, which is obviously
> > excellent, but the fact that he wrote both the drivers may mean that
> > they share lots of code and possibly share the same bug.
>
> If so, the bug should have propagated to the m68k 53c9x driver. Wouldn't
> be the 53c9x first weirdness - I never got it to accept a DAT drive (old
> DDS-1, possibly Apple) without blowing up.

FYI, my DDS-1 worked with my MESH. Not perfectly, sometimes it gave a warning
(lost arbitration, IIRC), which aborted the current reading/writing.

Moving the DD-1 to the Sym53c875 solved the problem.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mesh SCSI bus locks hard on 7500 when burning a CD-R in dao mode

[Michael Schmitz]

> How do I set it up to log to a serial console?  (I may not be able to do
> this for a few days until I borrow a friend's laptop, though.)

console=/dev/ttyS0 in the kernel options.

> I did "dmesg -n 8" since I forgot the number and didn't have your email
> right in front of me, and it accepted that.  Does dmesg just tell the

Maybe 8 is OK as well.

> kernel what to send to syslogd, or does it tell it what to send to the
> current console directly?  If the former, how does this work on a

The debug level controls what sort of printk messages are sent to the
console device(s) directly. syslogd always gets a copy of everything
anyway.

> per-console basis?  If the latter, why would a serial console have a
> better chance of working?

Just in case the screen update is blocked by some interrupt disable stuff.
Serial console works without interrupts (at least it used to).

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/