Subject: Re: esp(4) SCSI (Re: MI SONIC Ethernet driver for mac68k)
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
List: port-mac68k
Date: 06/05/2007 00:37:34
At 2:27 Uhr +0900 5.6.2007, Izumi Tsutsui wrote:
>> >On my LC630, "dd if=/dev/rsd0a of=/dev/null bs=64k" doesn't work
>> >while "bs=63k" works:
>>
>> No problems here:

[...]

>Hmm, then LC630 (Q630) might have some quirk around esp DMA
>and should we handle it in mac68k/obio/esp.c?

Sounds like it... maybe the issue hasn't shown up so far because most
people stick with IDE disks for that Mac?

>> I noted, though, that the Seagate Cheetah is only recognized as
>> asynchronous scsi device.
>
>If you don't have any "flags" at esp(4) lines in your config,
>you could add "PQUIRK_CAP_SYNC" quirk flag to scsi_quirk_patterns[]
>in sys/dev/scsipi/scsiconf.c.

Interesting. I had the Cheetah in a PowerMac G3/400 before on an Adaptec
U2W, and it would fall back to async there, as soon as another disk was on
the bus with it. In addition, the other disk (a 9 GB IBM U2W that the Mac
shipped with) would then fall back to narrow (8 Bit) SCSI. So there's
definitely something fishy there.

OTOH, the Cheetah ran on a Sun sbus fas adapter for years without problems.
And a

Index: scsiconf.c
===================================================================
RCS file: /cvsroot/src/sys/dev/scsipi/scsiconf.c,v
retrieving revision 1.241.2.1
diff -u -p -u -r1.241.2.1 scsiconf.c
--- scsiconf.c  19 Feb 2007 20:03:17 -0000      1.241.2.1
+++ scsiconf.c  4 Jun 2007 22:28:40 -0000
@@ -644,6 +644,8 @@ static const struct scsi_quirk_inquiry_p
         "FUJITSU ", "M2624S-512      ", ""},     PQUIRK_CAP_SYNC},
        {{T_DIRECT, T_FIXED,
         "SEAGATE ", "SX336704LC"   , ""}, PQUIRK_CAP_SYNC |
PQUIRK_CAP_WIDE16},
+       {{T_DIRECT, T_FIXED,
+        "SEAGATE ", "ST336706LW"   , ""}, PQUIRK_CAP_SYNC},

        {{T_DIRECT, T_REMOV,
         "IOMEGA", "ZIP 100",            "J.03"}, PQUIRK_NOLUNS},

doesn't make a difference for the Quadra, with or without a
PQUIRK_CAP_WIDE16. The disk has a 16-to-8 bit adapter, maybe that leads the
kernel to assume async operation?

	hauke

--
"It's never straight up and down"     (DEVO)