Re: ATA MODE_SENSE_BIG timeout
- Original Message - From: "Luoqi Chen" <[EMAIL PROTECTED]> To: "David Xu" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, March 05, 2003 8:44 AM Subject: RE: ATA MODE_SENSE_BIG timeout > > For those want to fix ATA code, I have another problem > > with CURRENT. I have a Tyan Tiger 230T which is based > > on VIA Apollo 133T, south bridge is VIA 686B. > > On second IDE, I have a Mitsubishi 52X cdrom as master, > > and a Sony 16X CD R/W as slave, when startup, kernel > > is always stuck at "MODE_SENSE_BIG timeout". > > I fortunately catched the dmesg text since ATA code past the > > probing stage. In most case, it will be stuck there forever. > > BTW, both Linux (2.2.14, Redhat) and MS Windows can probe > > these devices in few seconds without any problem. > > > I had more than a few machines behaved this way. I believe > the problem is with the probe and attach sequence of our > ata driver. After an ATA reset, according to spec, an ATAPI > device is supposed to present the ATAPI signature and deassert > the ready bit, until it receives its first packet command. > However when the ata driver issues the first mode sense command, > it polls first for the ready bit which never becomes set and > the operation times out. The most obviously solution is > sending the first command without checking for the ready bit. > > My solution is a little different, but works equally well, > instead I issue an ATAPI reset (what now called a device reset?), > because I don't want to write another or alter the current > ata_command function and we need an atapi_reset function anyway. > According spec, atapi devices SHOULD ONLY be reset via the > atapi reset command (our ata driver doesn't follow this rule). > > The patch is for -stable. I hope it's not too difficult to port > to -current. > I have applied the patch manually to CURRENT, it helps nothing. :( Then I booted kernel without the patch, waited for a very long time to let ata code retry, finally it found the Sony 16X CD RW, but I can not mount it. It is always timeout. David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: ATA MODE_SENSE_BIG timeout
> For those want to fix ATA code, I have another problem
> with CURRENT. I have a Tyan Tiger 230T which is based
> on VIA Apollo 133T, south bridge is VIA 686B.
> On second IDE, I have a Mitsubishi 52X cdrom as master,
> and a Sony 16X CD R/W as slave, when startup, kernel
> is always stuck at "MODE_SENSE_BIG timeout".
> I fortunately catched the dmesg text since ATA code past the
> probing stage. In most case, it will be stuck there forever.
> BTW, both Linux (2.2.14, Redhat) and MS Windows can probe
> these devices in few seconds without any problem.
>
I had more than a few machines behaved this way. I believe
the problem is with the probe and attach sequence of our
ata driver. After an ATA reset, according to spec, an ATAPI
device is supposed to present the ATAPI signature and deassert
the ready bit, until it receives its first packet command.
However when the ata driver issues the first mode sense command,
it polls first for the ready bit which never becomes set and
the operation times out. The most obviously solution is
sending the first command without checking for the ready bit.
My solution is a little different, but works equally well,
instead I issue an ATAPI reset (what now called a device reset?),
because I don't want to write another or alter the current
ata_command function and we need an atapi_reset function anyway.
According spec, atapi devices SHOULD ONLY be reset via the
atapi reset command (our ata driver doesn't follow this rule).
The patch is for -stable. I hope it's not too difficult to port
to -current.
-lq
Index: atapi-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-all.c,v
retrieving revision 1.46.2.18
diff -u -r1.46.2.18 atapi-all.c
--- atapi-all.c 31 Oct 2002 23:10:33 - 1.46.2.18
+++ atapi-all.c 19 Dec 2002 19:59:20 -
@@ -48,6 +48,7 @@
#include
/* prototypes */
+static void atapi_reset(struct ata_device *);
static void atapi_read(struct atapi_request *, int);
static void atapi_write(struct atapi_request *, int);
static void atapi_finish(struct atapi_request *);
@@ -77,6 +78,7 @@
ata_umode(atadev->param), atadev->param->support_dma);
ATA_SLEEPLOCK_CH(atadev->channel, ATA_CONTROL);
+atapi_reset(atadev);
if (atapi_dma && !(atadev->param->drq_type == ATAPI_DRQT_INTR)) {
ata_dmainit(atadev->channel, atadev->unit,
(ata_pmode(atadev->param) < 0) ?
@@ -483,6 +485,8 @@
void
atapi_reinit(struct ata_device *atadev)
{
+atapi_reset(atadev);
+
/* reinit device parameters */
if (atadev->mode >= ATA_DMA)
ata_dmainit(atadev->channel, atadev->unit,
@@ -536,6 +540,43 @@
}
static void
+atapi_reset(struct ata_device *atadev)
+{
+struct ata_channel *ch = atadev->channel;
+u_int8_t stat, lsb, msb;
+int timeout;
+
+ATA_OUTB(ch->r_io, ATA_DRIVE, ATA_D_IBM | atadev->unit);
+DELAY(10);
+ATA_OUTB(ch->r_altio, ATA_ALTSTAT, ATA_A_4BIT | ATA_A_IDS);
+DELAY(10);
+ATA_OUTB(ch->r_io, ATA_DRIVE, ATA_D_IBM | atadev->unit);
+DELAY(10);
+ATA_OUTB(ch->r_io, ATA_CMD, ATA_C_ATAPI_RESET);
+
+for (timeout = 1; timeout; timeout--) {
+ DELAY(100);
+ ATA_OUTB(ch->r_io, ATA_DRIVE, ATA_D_IBM | atadev->unit);
+ DELAY(10);
+ lsb = ATA_INB(ch->r_io, ATA_CYL_LSB);
+ msb = ATA_INB(ch->r_io, ATA_CYL_MSB);
+ stat = ATA_INB(ch->r_io, ATA_STATUS);
+ if ((stat & ATA_S_BUSY) == 0)
+ break;
+}
+
+if (bootverbose)
+ ata_prtdev(atadev, "stat %x, lsb %x, msb %x\n", stat, lsb, msb);
+
+if (timeout == 0)
+ ata_prtdev(atadev, "soft reset failed\n");
+
+ATA_OUTB(ch->r_io, ATA_DRIVE, ATA_D_IBM | atadev->unit);
+DELAY(10);
+ATA_OUTB(ch->r_altio, ATA_ALTSTAT, ATA_A_4BIT);
+}
+
+static void
atapi_read(struct atapi_request *request, int length)
{
int8_t **buffer = (int8_t **)&request->data;
@@ -617,10 +658,13 @@
{
struct ata_device *atadev = request->device;
+ATA_FORCELOCK_CH(atadev->channel, ATA_CONTROL);
atadev->channel->running = NULL;
ata_prtdev(atadev, "%s command timeout - resetting\n",
atapi_cmd2str(request->ccb[0]));
+atapi_reset(atadev);
+
if (request->flags & ATPR_F_DMA_USED) {
ata_dmadone(atadev->channel);
if (request->retries == ATAPI_MAX_RETRIES) {
@@ -631,17 +675,20 @@
request->retries = 0;
}
}
+ATA_UNLOCK_CH(atadev->channel);
/* if retries still permit, reinject this request */
if (request->retries++ < ATAPI_MAX_RETRIES) {
+ int s = splbio();
TAILQ_INSERT_HEAD(&atadev->channel->atapi_queue, request, chain);
+ ata_start(atadev->channel);
+ splx(s);
}
else {
/* retries all used up, return error */
request->error = EIO;
wakeup((caddr_t)request);
}
-ata_reinit(atadev->channel);
}
static char *
To Unsubscribe: send mail to [EMAIL PROT
Re: ATA MODE_SENSE_BIG timeout
On 04-Mar-2003 Soeren Schmidt wrote: > It seems David Xu wrote: >> > (snip snap) >> > > acd1: read data overrun 34/0 >> > > acd1: MODE_SENSE_BIG command timeout - resetting >> > > ata1: resetting devices .. >> > > done >> > > acd1: CD-RW at ata1-slave PIO4 >> > >> > Hmm, can you use the acd1 device normally or does it fail (how) ? >> > >> > -Søren >> > >> It is very rare that the CD-RW will be found now, kernel is always >> stuck there, so I must pull the device off or disable Second IDE in BIOS, >> I can not use it. > > OK, from the above it looked like it was found after the retries.. > I'll try to reproduce the problem here, but so far no luck at that.. I've seen this same problem trying to install 4.7 on a box with a 52x drive. I don't have that drive around anymore and I'm not sure if it was the same make/model. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA MODE_SENSE_BIG timeout
It seems David Xu wrote: > > (snip snap) > > > acd1: read data overrun 34/0 > > > acd1: MODE_SENSE_BIG command timeout - resetting > > > ata1: resetting devices .. > > > done > > > acd1: CD-RW at ata1-slave PIO4 > > > > Hmm, can you use the acd1 device normally or does it fail (how) ? > > > > -Søren > > > It is very rare that the CD-RW will be found now, kernel is always > stuck there, so I must pull the device off or disable Second IDE in BIOS, > I can not use it. OK, from the above it looked like it was found after the retries.. I'll try to reproduce the problem here, but so far no luck at that.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA MODE_SENSE_BIG timeout
- Original Message - From: "Soeren Schmidt" <[EMAIL PROTECTED]> To: "David Xu" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, March 04, 2003 3:56 PM Subject: Re: ATA MODE_SENSE_BIG timeout > It seems David Xu wrote: > > (snip snap) > > acd1: read data overrun 34/0 > > acd1: MODE_SENSE_BIG command timeout - resetting > > ata1: resetting devices .. > > done > > acd1: CD-RW at ata1-slave PIO4 > > Hmm, can you use the acd1 device normally or does it fail (how) ? > > -Søren > It is very rare that the CD-RW will be found now, kernel is always stuck there, so I must pull the device off or disable Second IDE in BIOS, I can not use it. David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA MODE_SENSE_BIG timeout
It seems David Xu wrote: (snip snap) > acd1: read data overrun 34/0 > acd1: MODE_SENSE_BIG command timeout - resetting > ata1: resetting devices .. > done > acd1: CD-RW at ata1-slave PIO4 Hmm, can you use the acd1 device normally or does it fail (how) ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATA MODE_SENSE_BIG timeout
For those want to fix ATA code, I have another problem with CURRENT. I have a Tyan Tiger 230T which is based on VIA Apollo 133T, south bridge is VIA 686B. On second IDE, I have a Mitsubishi 52X cdrom as master, and a Sony 16X CD R/W as slave, when startup, kernel is always stuck at "MODE_SENSE_BIG timeout". I fortunately catched the dmesg text since ATA code past the probing stage. In most case, it will be stuck there forever. BTW, both Linux (2.2.14, Redhat) and MS Windows can probe these devices in few seconds without any problem. Here is the dmesg: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #4: Fri Feb 28 23:55:50 CST 2003 [EMAIL PROTECTED]:/home/davidxu/src/sys/i386/compile/xu2 Preloaded elf kernel "/boot/kernel/kernel" at 0xc04cc000. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc04cc0a8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cc154. Timecounter "i8254" frequency 1193182 Hz CPU: Intel Pentium III (999.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x387fbff real memory = 268369920 (255 MB) avail memory = 255410176 (243 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 Pentium Pro MTRR support enabled VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc047fca2 (122) VESA: NVidia npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdd20 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: on pcib0 IOAPIC #0 intpin 5 -> irq 2 IOAPIC #0 intpin 10 -> irq 5 IOAPIC #0 intpin 11 -> irq 10 agp0: mem 0xf000-0xf3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xd400-0xd41f irq 2 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 uhci1: port 0xd800-0xd81f irq 2 at device 7.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 pci0: at device 7.4 (no driver attached) pci0: at device 9.0 (no driver attached) ed0: port 0xe400-0xe41f irq 10 at device 11.0 on pci0 ed0: address 52:54:ab:52:53:8f, type NE2000 (16 bit) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xc-0xcb7ff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ad0: 57241MB [116301/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-master PIO4 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting de
