From root@techpc04.okladot.state.ok.us  Tue Mar 23 14:49:04 2004
Return-Path: <root@techpc04.okladot.state.ok.us>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id B762116A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 23 Mar 2004 14:49:04 -0800 (PST)
Received: from odot.okladot.state.ok.us (odot.okladot.state.ok.us [192.149.244.9])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 3188D43D31
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 23 Mar 2004 14:49:04 -0800 (PST)
	(envelope-from root@techpc04.okladot.state.ok.us)
Received: from notes9c.okladot.state.ok.us (notes9a.okladot.state.ok.us [10.36.36.31])
	by odot.okladot.state.ok.us (AIX4.3/8.9.3/8.9.2) with ESMTP id QAA45874;
	Tue, 23 Mar 2004 16:49:03 -0600
Received: from techpc04.okladot.state.ok.us ([199.27.9.37])
          by notes9c.okladot.state.ok.us (Lotus Domino Release 5.0.12)
          with ESMTP id 2004032316494672:18037 ;
          Tue, 23 Mar 2004 16:49:46 -0600 
Received: by techpc04.okladot.state.ok.us (Postfix, from userid 0)
	id 9C8E95C11; Tue, 23 Mar 2004 16:49:04 -0600 (CST)
Message-Id: <20040323224904.9C8E95C11@techpc04.okladot.state.ok.us>
Date: Tue, 23 Mar 2004 16:49:04 -0600 (CST)
From: "Paul Seniura" <pdseniura@techie.com>
Sender: "Paul Seniura" <pdseniura@techie.com>
Reply-To: "Paul Seniura" <pdseniura@techie.com>
To: FreeBSD-gnats-submit@freebsd.org
Subject: ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00  <- repeats for exactly 30 seconds during boot when no slave is wired
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         64637
>Category:       kern
>Synopsis:       ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00  <- repeats for exactly 30 seconds during boot when no slave is wired
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    sos
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 23 14:50:12 PST 2004
>Closed-Date:    Mon Oct 04 11:35:58 GMT 2004
>Last-Modified:  Tue Oct  5 14:00:26 GMT 2004
>Originator:     "Paul Seniura" <pdseniura@techie.com>
>Release:        FreeBSD 5.2-CURRENT i386
>Organization:
State of Okla. D.O.T.
>Environment:
System: FreeBSD techpc04.okladot.state.ok.us 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Tue Mar 23 03:34:06 CST 2004 root@techpc04.okladot.state.ok.us:/usr/obj/src/sys/IBM300SY_4BSD_O2 i386

>Description:

We have a newish drive made by LG/HDST with latest firmware.  As shown in dmesg:
acd0: <HL-DT-ST RW/DVD GCC-4120B/2.02> CDRW drive at ata1 as master

While the kernel is probing for ATA/IDE devices, we see the following line repeatedly for exactly 30 seconds:
ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00

After the ttys come up, it seems the drive actually has no problems and is quite usable, albeit with the same known problems seen by others with different models when using apps such as 'burncd'.

Waiting an extra 30 seconds for a development machine to reboot is really trying my patience.  It is showing the kernel still needs some work.  (I must follow -Current via CTM due to political firewall issues here.)

This drive is installed in an IBM 300PL PC with latest BIOS firmware.  There are only two ATA/IDE devices: a primary/master HD and this secondary/master Combo drive.  There are no 'slaves' wired, in fact IBM's ribbon cables do not have an extra connector to do this.  Yes I've quintuple-checked the jumpers(!).

I bought this drive brand-new only a year ago.  It is exactly the same model+firmware Apple was using for its 'Combo' iMacs.  I used it for a while in my G4 Sawtooth running Jaguar and Panther.  A friend used it with Win2K for a while.  Now we have installed it into an IBM 300PL PC and want to use it for FreeBSD-current projects.

The original drive in the 300PL was an earlier LG model CDROM-only with latest firmware.  I still have access to it: it does not produce this problem (when wired in place of the new LG-Combo).

I tested a Pioneer DVR-107 the same way: it does not produce this problem (however, this drive will not be used on the 300PL).

I have tried setting sysctl values to change the timeouts for ATA devices -- the kernel msgs do not change and we still see exactly 30 seconds worth of repeated lines.

I have tried changing ATA DMA<->PIO modes -- it does not change the kernel msgs.

I have tried different schedulers: ULE and 4BSD produce the same msgs.

I have tried enabling ACPI: the same msgs.  (We cannot use ACPI for other reasons; see maillist archives, search for my name, to find out why).

I have messed with BIOS settings -- IBM's SurePath[tm] BIOS does not have many features here, and nothing will change the msgs.

I have asked for help in the -current maillist every so often since February 2004 and have received no replies.  So I open this PR.

>How-To-Repeat:

Install the LG 'Combo' CD/DVD drive.  Boot up.  See the msgs.

>Fix:

I need help & direction, please -- what to test, what to change, etc.  I'm fresh out of ideas.  I'm very much afraid when FreeBSD 5.3 "goes GM" it will still have this bug and many users will be asking "Why am I seeing this problem?".

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->sos 
Responsible-Changed-By: cperciva 
Responsible-Changed-When: Tue Mar 30 10:35:59 PST 2004 
Responsible-Changed-Why:  
Assign to the ATA guru. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=64637 

From: "Paul Seniura" <pdseniura@techie.com>
To: <FreeBSD-gnats-submit@freebsd.org>, <freebsd-current@freebsd.org>
Cc:  
Subject: Re: kern/64637: ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00  <- repeats for exactly 30 seconds during boot when no slave is wired
Date: Tue, 27 Apr 2004 14:16:03 -0500 (CDT)

 With the recent patches to ata-lowlevel.c (v1.33 at this writing), verbose boot is showing this in the dmesg:
 [...]
 atapci0: <Intel PIIX4 UDMA33 controller> port 0xfff0-0xffff,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 2.1 on pci0
 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfff0
 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0
 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6
 ata0: reset tp1 mask=03 ostat0=50 ostat1=00
 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00
 ata0-slave:  stat=0x00 err=0x01 lsb=0x00 msb=0x00
 ata0: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1<ATA_MASTER>
 ata0: at 0x1f0 irq 14 on atapci0
 ata0: [MPSAFE]
 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170
 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376
 ata1: reset tp1 mask=03 ostat0=50 ostat1=00
 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb  <-- Magic Numbers for ATAPI device
 ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00 \ <----------/////////////////
 [...^v^v^v^ repeats 30 seconds' worth ^v^v^v^...] < <---------<<<  looping  <<<
 ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00 / <----------\\\\\\\\\\\\\\\\\
 ata1: reset tp2 mask=01 stat0=00 stat1=81 devices=0x4<ATAPI_MASTER>
 ata1: at 0x170 irq 15 on atapci0
 ata1: [MPSAFE]
 [...]
 
 
 The 'atacontrol list' shows:
 ATA channel 0:
     Master:  ad0 <IBM-DTTA-371010/T77IA73A> ATA/ATAPI revision 4
     Slave:       no device present
 ATA channel 1:
     Master: acd0 <HL-DT-ST RW/DVD GCC-4120B/2.02> ATA/ATAPI revision 0
     Slave:       no device present
 
 
 The 'atacontrol mode 0' shows:
 Master = UDMA33
 Slave  = BIOSPIO
 
 
 The 'atacontrol mode 1' shows:
 Master = WDMA2
 Slave  = BIOSPIO
 
 
 With this new info, we can see that we are getting the ATAPI_MAGIC_* numbers from the secondary channel (still connected only to the LG Combo as Master, no Slaves at all anywhere).
 The code turns on 'ch->devices |= ATA_ATAPI_MASTER;' at this point and continues.
 We see different stat1 values afterwards, when checking for slave on secondary.
 It seems stat1 is not checked against ATA_S_ERROR at this point.
 How can we do this properly so it'd work for everyone?
 
 Also should I figure out why tp2 on primary channel ends up with mask=03, with no slaves at all anywhere?
 Or is this a common assumption being made?
 
 ? ? ? ?
 
 
   --  thx, Paul Seniura.
 
 

From: "Paul Seniura" <pdseniura@techie.com>
To: <FreeBSD-gnats-submit@freebsd.org>, <freebsd-current@freebsd.org>
Cc: <sos@freebsd.org>
Subject: Re: kern/64637: [PATCH] ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00  <- repeats for exactly 30 seconds during boot when no slave is wired
Date: Wed, 28 Apr 2004 11:29:47 -0500 (CDT)

 Hi,
 
 I saw Soren's private msg (heh, I can't figure out how to spell his name correctly ;) .
 I know anything this low-level is a thorny thing to be modifying.
 
 But this is one of those irritating things that bother one so much that it compels one to try fixing it oneself.
 
 I'm no expert, but 30 years of building electronics and interfacing some of them to computers & writing drivers for them, I kinda have a knack.  ;)
 
 The dmesg may be showing the 'answer' to this, up a bit further, in the tp1 lines:
  [...]
  ata0: reset tp1 mask=03 ostat0=50 ostat1=00
  [...]
  ata1: reset tp1 mask=03 ostat0=50 ostat1=00
  [...]
 
 I _think_ we are _already_ getting a definitive response that there are no slaves connected.
 
 Let me hear from y'all if this is correct or not:
 
 The ostat1 in particular comes from the query for the ATA_SLAVE device on that channel (shown by 'ata#:') and getting the ATA_STATUS from that query (see patch below).
 
 A zero value means nothing is busy, nothing is ready, nothing has an error, etc. etc. etc. (status flags defined following line #82 in ata-all.h v1.78).
 
 We're seeing zeroes because nothing is there to respond.
 
 Ergo, no slave device there.
 
 What I do _not_ know is why we aren't getting ATA_NO_SLAVE lit up, but that part of ata-lowlevel.c (under line #556) is being executed anyway (this _is_ an older IBM 300PL model with its latest BIOS; its ACPI and APM modes make no difference here).
 
 I also don't know if a zero value should prompt the code to check other flags -- if so, where & what & how??
 
 So I am testing this patch for the time being:
 
 ===== cut here =====
 --- ata-lowlevel.c_orig	Wed Apr 28 00:43:17 2004
 +++ ata-lowlevel.c	Wed Apr 28 10:33:44 2004
 @@ -546,7 +546,7 @@ ata_generic_reset(struct ata_channel *ch
      ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_IBM | ATA_MASTER);
      DELAY(10);
      ostat0 = ATA_IDX_INB(ch, ATA_STATUS);
 -    if ((ostat0 & 0xf8) != 0xf8 && ostat0 != 0xa5) {
 +    if ((ostat0 & 0xf8) != 0xf8 && ostat0 != 0xa5 && ostat0 != 0) {
  	stat0 = ATA_S_BUSY;
  	mask |= 0x01;
      }
 @@ -557,7 +557,7 @@ ata_generic_reset(struct ata_channel *ch
  
      /* in some setups we dont want to test for a slave */
      if (!(ch->flags & ATA_NO_SLAVE)) {
 -	if ((ostat1 & 0xf8) != 0xf8 && ostat1 != 0xa5) {
 +	if ((ostat1 & 0xf8) != 0xf8 && ostat1 != 0xa5 && ostat1 != 0) {
  	    stat1 = ATA_S_BUSY;
  	    mask |= 0x02;
  	}
 ===== cut here =====
 
 
 It's fixed the problem as best that I can figure out.  ;)
 
 This IBM model does not have a ribbon connector for an extra drive (altho empty physical slot exist, but IBM wants to $ell you a new part for 'upgrading', see), so I'm not able to test this further.  Does anyone out there have the 'nads to try this patch?  ;)
 
 
   --  thx, Paul Seniura.
 

From: "Paul Seniura" <pdseniura@techie.com>
To: <FreeBSD-gnats-submit@freebsd.org>
Cc:  
Subject: Re: kern/64637: ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00  <- repeats for exactly 30 seconds during boot when no slave is wired
Date: Fri, 4 Jun 2004 17:48:48 -0500 (CDT)

 After a recent commit for ata-lowlevel.c:
 
 > sos         2004/06/01 04:34:47 PDT
 > 
 >   FreeBSD src repository
 > 
 >   Modified files:
 >     sys/dev/ata          ata-lowlevel.c 
 >   Log:
 >   Dont retry on devices that left the system.
 >   Ignore "fake" devices that has 0x7f status.
 >   
 >   Revision  Changes    Path
 >   1.37      +3 -2      src/sys/dev/ata/ata-lowlevel.c
 
 We are still seeing the repeated console msg for 30 seconds.
 Same scenario, same hardware & setups, etc.
 
 And I still have the same notion that I wrote earlier,
 in that when these values = 0,
  err=0  ostat0=0  ostat1=0  etc.
 they really do indicate "no slave exists".
 
 I've updated my patch for this PR to match the above commit:
 
 ===cut-here===
 --- ata-lowlevel.c_orig	Tue Jun  1 08:44:55 2004
 +++ ata-lowlevel.c	Fri Jun  4 16:15:20 2004
 @@ -532,7 +532,7 @@ ata_generic_reset(struct ata_channel *ch
      ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_IBM | ATA_MASTER);
      DELAY(10);
      ostat0 = ATA_IDX_INB(ch, ATA_STATUS);
 -    if ((ostat0 & 0xf8) != 0xf8 && ostat0 != 0xa5 && ostat0 != 0x7f) {
 +    if ((ostat0 & 0xf8) != 0xf8 && ostat0 != 0xa5 && ostat0 != 0x7f && ostat0 != 0) {
  	stat0 = ATA_S_BUSY;
  	mask |= 0x01;
      }
 @@ -543,7 +543,7 @@ ata_generic_reset(struct ata_channel *ch
  
      /* in some setups we dont want to test for a slave */
      if (!(ch->flags & ATA_NO_SLAVE)) {
 -	if ((ostat1 & 0xf8) != 0xf8 && ostat1 != 0xa5 && ostat1 != 0x7f) {
 +	if ((ostat1 & 0xf8) != 0xf8 && ostat1 != 0xa5 && ostat1 != 0x7f && ostat1 != 0) {
  	    stat1 = ATA_S_BUSY;
  	    mask |= 0x02;
  	}
 ===cut-here===
 
 Applying this patch once again shuts-up those looping messages.  ;)
 
 I wish we could get people to test this patch then commit it.
 
   --  thx, Paul Seniura.
 

From: "Paul Seniura" <pdseniura@techie.com>
To: <FreeBSD-gnats-submit@freebsd.org>
Cc: <sos@freebsd.org>
Subject: Re: kern/64637:  ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00  <- repeats for exactly 30 seconds during boot when no slave is wired
Date: Fri, 18 Jun 2004 11:35:57 -0500 (CDT)

 <sigh>
 Keeping up with the changes...
 
 > sos         2004-06-11 07:39:15 UTC
 > 
 >   FreeBSD src repository
 > 
 >   Modified files:
 >     sys/dev/ata          ata-lowlevel.c
 >   Log:
 >   Back out the last change as that broke some SATA devices.
 >   Now we are cleaing up remove a few lines of unused code.
 > 
 >   Revision  Changes    Path
 >   1.38      +4 -9      src/sys/dev/ata/ata-lowlevel.c
 
 
 I still must apply my patch to put a muzzle on those
 messages that won't quit for 30 seconds every time
 the machine needs rebooting.
 
 
 ====cut-here====
 --- ata-lowlevel.c_orig	Fri Jun 11 16:45:17 2004
 +++ ata-lowlevel.c	Mon Jun 14 08:49:10 2004
 @@ -532,7 +532,7 @@
      ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_IBM | ATA_MASTER);
      DELAY(10);
      ostat0 = ATA_IDX_INB(ch, ATA_STATUS);
 -    if ((ostat0 & 0xf8) != 0xf8 && ostat0 != 0xa5) {
 +    if ((ostat0 & 0xf8) != 0xf8 && ostat0 != 0xa5 && ostat0 != 0) {
  	stat0 = ATA_S_BUSY;
  	mask |= 0x01;
      }
 @@ -543,7 +543,7 @@
  
      /* in some setups we dont want to test for a slave */
      if (!(ch->flags & ATA_NO_SLAVE)) {
 -	if ((ostat1 & 0xf8) != 0xf8 && ostat1 != 0xa5) {
 +	if ((ostat1 & 0xf8) != 0xf8 && ostat1 != 0xa5 && ostat1 != 0) {
  	    stat1 = ATA_S_BUSY;
  	    mask |= 0x02;
  	}
 ====cut-here====
 
 
 I'm running -Current as of last night's
 CTM bucket (17 June 2004 CDT).  This
 bug still occurs.  The theory mentioned
 earlier in this PR still applies AFAIKT.
 
 Why is no one looking at this PR? 
 Do y'all want this bug in 5.3-Release? 
 
 
   --  thx, Paul Seniura
            System Specialist
            State of Okla. D.O.T.
 
State-Changed-From-To: open->analyzed 
State-Changed-By: sos 
State-Changed-When: Mon Aug 16 11:27:23 GMT 2004 
State-Changed-Why:  


http://www.freebsd.org/cgi/query-pr.cgi?pr=64637 
State-Changed-From-To: analyzed->feedback 
State-Changed-By: sos 
State-Changed-When: Mon Aug 16 11:33:05 GMT 2004 
State-Changed-Why:  
OK, gnats ate my log first time around :( 

Simple answer, you cannot rely on regs containing zero's, that'll 
break lots of other drives, so no can do. 

Now, what you are seeing is just the ATA driver waiting the 31secs that 
the ATA spec calls for, that is a feature not a bug :) 

ATA tries hard to avoid that wait, but its simply not possible to . 
them all correctly, some subset is bound to use the specified wait. 

Thats said, you could maybe avoid the wait be setting the drive in 
question to be slave instead of master. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=64637 

From: "Paul Seniura" <pdseniura@techie.com>
To: <FreeBSD-gnats-submit@freebsd.org>
Cc: <sos@freebsd.org>
Subject: Re: kern/64637: ata1-slave: stat=0x01 err=0x00 lsb=0x00 msb=0x00 <- repeats for exactly 30 seconds during boot when no slave is wired
Date: Mon, 16 Aug 2004 11:28:39 -0500 (CDT)

 I cannot move the LG-Combo drive to a 'slave' connection. 
 In the PR I've carefully documented this as IBM has it
 set up: 
 
 IBM has wired it to the secondary ATA channel as a
 'master' and it is the only connection possible there. 
 
 Physically the Combo drive cannot be moved nor can its
 ribbon cable reach over to the primary channel so it can
 be 'slave' to the IBM-provided HDD.
 
 There is nothing else that can be attached to that
 secondary channel as a 'master', ergo the Combo drive
 must be jumpered as 'master' there.
 
 I know how to hack hardware as well as software.  ;) 
 There just is no way to have a master/slave pair
 connected to any of the same channels.  I would have
 done that and logged such workarounds in this PR if
 it were possible.  Honest.
 
 Doesn't the ATA spec require a 'master' somewhere if
 I simply jumpered the Combo drive to 'slave' while it
 is wired all by itself to a channel?
 
 Another thing I have discussed in the PR: 
 The ostat regs are Zero I suspect because there are no
 Slaves present on either channel.  What else _could_
 that mean?  The code does not test for Zero.  I wonder
 if the possibility of having masters on each channel
 but no slaves has not been thought-of?  ;)  Other than
 ostat==Zero, then what _would_ be the proper test for
 the condition of "no slaves present on any channel"?
 
 Thank you for taking time for this and discussing it more. 
 I wish we had better hardware, but we always get the
 hand-me-downs.  Your tax dollars hard at work here.  ;)
 
 P.S. I see the commits on the ata-* modules done today. 
 When they show up in the CTM deltas, I will build
 kernel & world without my Zero Test and try them out.
 
   --  thx, Paul Seniura.
 

From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk>
To: Paul Seniura <pdseniura@techie.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, sos@FreeBSD.ORG
Subject: Re: kern/64637: ata1-slave: stat=0x01 err=0x00 lsb=0x00 msb=0x00
 <- repeats for exactly 30 seconds during boot when no slave is wired
Date: Mon, 16 Aug 2004 19:20:14 +0200

 Paul Seniura wrote:
 > I cannot move the LG-Combo drive to a 'slave' connection.=20
 > In the PR I've carefully documented this as IBM has it
 > set up:=20
 >=20
 > IBM has wired it to the secondary ATA channel as a
 > 'master' and it is the only connection possible there.=20
 >=20
 > Physically the Combo drive cannot be moved nor can its
 > ribbon cable reach over to the primary channel so it can
 > be 'slave' to the IBM-provided HDD.
 >=20
 > There is nothing else that can be attached to that
 > secondary channel as a 'master', ergo the Combo drive
 > must be jumpered as 'master' there.
 >=20
 > I know how to hack hardware as well as software.  ;)=20
 > There just is no way to have a master/slave pair
 > connected to any of the same channels.  I would have
 > done that and logged such workarounds in this PR if
 > it were possible.  Honest.
  >
 > Doesn't the ATA spec require a 'master' somewhere if
 > I simply jumpered the Combo drive to 'slave' while it
 > is wired all by itself to a channel?
 
 That was what I tried to make you try actually, and yes it does work.
 
 > Another thing I have discussed in the PR:=20
 > The ostat regs are Zero I suspect because there are no
 > Slaves present on either channel.  What else _could_
 > that mean?  The code does not test for Zero.  I wonder
 > if the possibility of having masters on each channel
 > but no slaves has not been thought-of?  ;)  Other than
 > ostat=3D=3DZero, then what _would_ be the proper test for
 > the condition of "no slaves present on any channel"?
 
 The problem is that your master device shows up as zero'd register on=20
 the slave addresses. Normally a nonexistent drive would show up as 0xff=20
 or 0x7f, zero signals that there is something there. I'd call the device =
 
 buggy if it responds to other than the selected device ID.
 
 > Thank you for taking time for this and discussing it more.=20
 > I wish we had better hardware, but we always get the
 > hand-me-downs.  Your tax dollars hard at work here.  ;)
 
 Not my tax dolllars, they would be Danish Kroner :)
 
 > P.S. I see the commits on the ata-* modules done today.=20
 > When they show up in the CTM deltas, I will build
 > kernel & world without my Zero Test and try them out.
 
 Roger!
 
 -S=F8ren
 

From: "Paul Seniura" <pdseniura@techie.com>
To: <freebsd-gnats-submit@FreeBSD.org>
Cc: <sos@DeepCore.dk>
Subject: Re: kern/64637: ata1-slave: stat=0x01 err=0x00 lsb=0x00 msb=0x00 <- repeats for exactly 30 seconds during boot when no slave is wired
Date: Mon, 30 Aug 2004 17:26:12 -0500 (CDT)

 I jumpered the LG-Combo drive as 'slave'. 
 Remember it is by itself on the secondary IDE channel,
 but per your earlier e-mail said it should be ok. 
 I powered everything back on. 
 Of course the BIOS detected a "162 config change"
 and I went thru its menues to see where it now thinks
 the LG drive is located,
 and COULD NOT FIND IT AT ALL. 
 There is no drive on the secondary channel as far as
 IBM's SurePath[tm] BIOS is concerned. 
 Nothing.  Nada.  Zip.
 
 Hoping FreeBSD might detect it on its own, I
 booted it up with this slave-by-itself. 
 No such luck, FreeBSD didn't find it. 
 The BIOS _must_ see it first. 
 We didn't get the 30-seconds worth of repeats as mentioned
 in this PR but we also are not able to use the LG-Combo
 drive at all while it is set solely as slave like that.
 
 I mentioned earlier that IBM's cabling won't let us wire
 the LG on primary/slave behind the HD.
 So I jumpered LG back to master on secondary,
 and now we're back to the problems in this PR.
 
 I'm using CTM deltas up thru early this morning,
 with 'ident ata-lowlevel.c' showing as:
 ata-lowlevel.c:
      $FreeBSD: src/sys/dev/ata/ata-lowlevel.c,v 1.46 2004/08/27 22:14:45 sos Exp $
 
 I mentioned much earlier in the PR about dmesg showing
 lsb/msb status 0x14/0xeb with err=0x01
 and that is the clue to making it work right. 
 Somehow we are suppose to treat the drive in a different
 manner right then & there.  But we are not, so the driver
 gets confused and sees
 zeroes for lsb/msb and 0x01 for stat
 on the non-existent ata1-slave after that. 
 I'm _sure_ this is the clue.  But I can't afford to buy
 books to study it myself (would love to do that, just
 can't pay for anything now, and TPTB won't buy them either). 
 Frustrating. 
 So I put my Zero-Test patch back onto this module until we
 (you & me & whoever else) can figure it out properly.  ;)
 
 Thank you for taking time to read this. 
 I'll be able to try anything if needed.
 
   --  thx, Paul Seniura.
 
 
State-Changed-From-To: feedback->closed 
State-Changed-By: sos 
State-Changed-When: Mon Oct 4 11:31:16 GMT 2004 
State-Changed-Why:  
First of you cannot use the 
lsb/msb status 0x14/0xeb with err=0x01 
to decide anything other that a device is there and an error occured. 

I've change quite a few things in ATA's probe since then so yo might give  
it a spin. Anyhow that 31S timeout is what the specs call for on HW that 
cant be decided quickly/reliably, so at least we are true to spec that way :) 


http://www.freebsd.org/cgi/query-pr.cgi?pr=64637 

From: "P.D. Seniura" <pdseniura@techie.com>
To: freebsd-gnats-submit@FreeBSD.org,
	"So/ren Schmidt" <sos@FreeBSD.org>
Cc:  
Subject: Re: kern/64637: ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00
    <- repeats for exactly 30 seconds during boot when no slave is wired
    
Date: Mon, 04 Oct 2004 10:23:59 -0500

 DO NOT CLOSE!
 WHY DO YOU CLOSE WHEN I HAVE NOT EVEN SEEN _YOUR_
 REPLY YET LET ALONE TRY YOUR SUGGESTIONS? 
 YES I MEAN TO SHOUT ABOUT THIS! 
 THIS IS NOT A GOOD WAY TO WIN PEOPLE TO USE FreeBSD!!
 
 I do not understand your reply -- you have not said
 anything concerning the "Magic numbers".  Please
 explain why they show up and why the code #defines
 them in that way if we are not to deal with it in a
 different manner?
 
 This "Combo" drive is the only hardware that seems
 to bring this issue up.  I say again it is the very
 same model Apple used for earlier iMacs on OSX and
 the firmware is the latest we can get from LG. 
 Other than this irritating boot-up delay there does
 not seem to be any other problem with it.
 
 If we cannot discuss this on a PR then what _is_ the
 proper venue to discuss this?  If a PR _is_ the
 right way to discuss this then why do you close it
 before I have even seen it?  (Yes I checked my
 account here late late late last night Sunday and
 your msg was not here.)  You do not close a problem
 until THE CUSTOMER/USER is agreeable to it!  I am
 in tech-support here, tho, not only/just an
 end-user, so any bugs end up in my lap, and then I
 am the one to talk to other techs / engineers when
 _I_ am stumped.
 
 I did build a new kernel mid-week last week without
 my "zero test" and it STILL FAILS.  I will try again
 another build tonight (Monday Oct. 4 2004) after the
 next CTM shows up.  I need to be very careful on this
 next build because of the library-bumps, so I am
 hoping we can test it by tomorrow.
 
 So -- PLEASE KEEP THIS PR OPEN.
 .     AFAIAC THIS BUG STILL EXISTS.
 .     And please explain "Magic Numbers" in the code?
 
 Thank you.
 
 
 ----- Original Message -----
 From: So/ren Schmidt <sos@FreeBSD.org>
 Date: Mon, 4 Oct 2004 11:35:57 GMT
 To: pdseniura@techie.com, sos@FreeBSD.org, sos@FreeBSD.org
 Subject: Re: kern/64637: ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00  <- repeats for exactly 30 seconds during boot when no slave is wired
 
 Synopsis: ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00  <- repeats for exactly 30 seconds during boot when no slave is wired
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: sos
 State-Changed-When: Mon Oct 4 11:31:16 GMT 2004
 State-Changed-Why: 
 First of you cannot use the
 lsb/msb status 0x14/0xeb with err=0x01
 to decide anything other that a device is there and an error occured.
 
 I've change quite a few things in ATA's probe since then so yo might give 
 it a spin. Anyhow that 31S timeout is what the specs call for on HW that
 cant be decided quickly/reliably, so at least we are true to spec that way :)
 
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=64637
 
 -- 
 ___________________________________________________________
 Sign-up for Ads Free at Mail.com
 http://promo.mail.com/adsfreejump.htm
 
 

From: "P.D. Seniura" <pdseniura@techie.com>
To: sos@deepcore.dk
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/64637: ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00
    <- repeats for exactly 30 seconds during boot when no slave is wired
    
Date: Tue, 05 Oct 2004 08:58:19 -0500

 Hi,
 
 Okay. 
 Last night's full world+kernel build does not help
 this matter.  Last/latest CTM came out yesterday-
 evening CST (GMT -0500).
 
 FreeBSD techpc04.okladot.state.ok.us 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Mon Oct  4 23:58:36 CDT 2004    root@techpc04.okladot.state.ok.us:/usr/obj/src/sys/IBM300SY_4BSD_Os  i386
 
 ----- Original Message -----
 From: sos@deepcore.dk
 Date: Mon, 4 Oct 2004 20:02:15 +0200 (CEST)
 To: "P.D. Seniura" <pdseniura@techie.com>
 Subject: Re: kern/64637: ata1-slave:  stat=0x01 err=0x00 lsb=0x00 msb=0x00  <- repeats for exactly 30 seconds during boot when no slave is wired
 
 > It seems P.D. Seniura wrote:
 > >  DO NOT CLOSE!
 > >  WHY DO YOU CLOSE WHEN I HAVE NOT EVEN SEEN _YOUR_
 > >  REPLY YET LET ALONE TRY YOUR SUGGESTIONS? 
 > >  YES I MEAN TO SHOUT ABOUT THIS! 
 > >  THIS IS NOT A GOOD WAY TO WIN PEOPLE TO USE FreeBSD!!
 > 
 > This is not a good way to get further help, sorry...
 
 This is not a good response to my PR.  The person
 who opened it must be allowed to continue with it
 if he thinks it needs to be that way. 
 That is my point. 
 Sorry you cannot see it that way, but being here for
 27+ years dealing with "commercial vendors" who
 treat our problems that way will always make my
 temper flare up.  You have not won my trust simply
 because this problem has been open since February 2004
 and we've not talked much about it: I can show the
 problem still exists even today but you want to close
 the PR to mask/hide this bug for 5.3-Release. 
 Yes I know I say it harshly like that, I have had
 many such occurrences in my 27+ years experience. 
 You close a PR without fixing it or allowing further
 work on it.
 
 > >  I do not understand your reply -- you have not said
 > >  anything concerning the "Magic numbers".  Please
 > >  explain why they show up and why the code #defines
 > >  them in that way if we are not to deal with it in a
 > >  different manner?
 > 
 > If that is not good enough for you as an explanation, go to www.t13.org 
 > and get the ATA/ATAPI specifications, that will explain to great length 
 > what the magic numbers etc are for and how to use them in the spec'ed way.
 
 No it is not a good-enough reply because it still does
 not explain why _your_ code is acting the way it does. 
 YOUR code -- not t13.org's.
 
 I still want to know, for example, why stat=0x01 is
 repeatedly showing for 30 seconds, on the
 ata1-slave line, when there is no-such device wired
 on that channel.  I do not think T13 will tell me
 why _your_ code is doing that.
 And after having seen the "magic numbers".
 
 However, I will try to study their docs, and thank
 you for the pointer.  I hope you will answer further
 questions on this matter without the aid of a PR,
 and in a more timely manner, please.
 
 I cannot obtain any other machinery here at work, as
 you may remember what I mentioned earlier about TPTB
 at this state govmt being tight-wads.  I must use what
 I've been handed.  I bring in and buy some of my own
 parts & equipment to keep this project moving.  AAMOF
 this "Combo" drive is mine, and as stated in the PR we
 have not had any problem with it used in other
 systems.  That is why I feel so sure we have a bug
 in your code.
 
 I cannot file a problem with IBM because we already
 have their latest BIOS and there are no further
 problems with the motherboard/etc. and the age of
 this model being very reliable.  But it is a model
 that cannot use 80-pin ATA cables -- I tried that,
 too, in hopes of having a master+slave on one channel
 in order to skirt-around your bug.
 
 With everything done that can possibly be done --
 remember my 27+ years experience -- I am pleading
 with you to continue helping me with this bug, please.
 
 For the time being, I must use my "Zero Test" patch
 just to keep from going crazy having to watch all
 those ata1-slave lines filling up dmesg.
 
 And for the time being, my manager is probably
 thinking FreeBSD is not very reliable w/r/t Linux
 and the length of time it takes to fix such a bug
 as this one.  I hate to say this so strongly, but
 this is giving FreeBSD a very bad name when it
 comes to "support".  I need help, and the PR was
 the main way to keep track of what we (you & I)
 have done to try fixing it.  So closing the PR was
 not a good thing to do.  And that is my point here. 
 So if you want to remedy this particular situation,
 you will re-open the PR so we can continue logging
 our attempts at fixing it, please.
 That is my point.
 Having a consistent bug and closing the PR when it
 is not yet fixed.
 That is my point.
 
 > -So/ren 
 
   --  thx, Paul Seniura.
 
 
 -- 
 ___________________________________________________________
 Sign-up for Ads Free at Mail.com
 http://promo.mail.com/adsfreejump.htm
 
 
>Unformatted:
