i386/60817: FBSD-5.1/5.2-RC1 "fdc0: cmd 3 failed at out byte 1 of 3"

Dierk Sacher usenet at blaxxtarz.de
Sat Jan 24 15:41:02 PST 2004


The following reply was made to PR i386/60817; it has been noted by GNATS.

From: Dierk Sacher <usenet at blaxxtarz.de>
To: supraexpress at globaleyes.net
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: i386/60817: FBSD-5.1/5.2-RC1 "fdc0: cmd 3 failed at out byte 1 of 3"
Date: Sun, 25 Jan 2004 00:37:16 +0100

 Zitiere supraexpress at globaleyes.net vom Sat, Jan 24, 2004 at 09:24:01AM -0600:
 > 3) added the following line in /boot/device.hints to attempt to disable
 >    runtime ACPI, which apparently did not work, or at least - had no
 >    apparent affect with regards to FDC0:
 > 
 > 	hint.acpi.0.disable="1"
 
 Argl. Mea culpa. A Typo. It has to be
 
 	hint.acpi.0.disabled="1"
 
 Meanwhile I digged deeper into the issue and it turns out, that the isa
 code fails to allocate the resource in fdc_alloc_resources
 
 /usr/src/sys/isa/fd.c: line 702:
   fdc->res_ioport = bus_alloc_resource([...]
 
 The resulting error is not bogus, as I thought in the first.
 
 I think, the resource is either allocated to acpi_sysresource in error
 or is not allocated to anything at all in acpi_sysresource_attach
 
 /usr/src/sys/dev/acpica: line 583ff 
 
 The cause seems to be a wrong or missing resource claim in the bios of
 those MSI boards.
 
 My next step will be to find out, which one of the lines (devinfo -u):
     ...
     0x3f0-0x3f1 (acpi_sysresource0)
     0x3f2-0x3f5 ----
     ...
 
 is the wrong one.
 
 Either 0x3f0-9x3f1 shouldn't be claimed by acpi_sysresource0 _or_
 the strange "----" indicates $I_DONT_KNOW_THE_HECK_WHAT_IT_INDICATES.
 
 Maybe it should also be claimed by acpi_sysresource0 (and this may be the
 missing part in the BIOS DSTD or wherever the acpi knows about whats a
 sysresource). If we make it to the statement thats missing or wrong,
 we may be able to force things via a hard coded hack for our broken
 boards until we are able to beg MSI to release a bios update or fix the
 DSDT ourselves.
 
 On the other hand 0x3f7 is claimed by root0 and to my understanding of
 acpi this might be the right assignment. So maybe the whole range of
 0x3f0-0x3f5 (0x3f6 is the stupid ata controller that makes this breakage
 necessary in the first place) should be claimed by root0 too. But I'm
 just guessing.
 
 "Ich glotz da rein wie die Sau ins Uhrwerk"[1], as we say in german. So
 we are in heavy need of some bsd acpi insider to help us out with at
 least some hints, where to dig further.
 
 	Gruss
 	  Dierk
 
 [1] sort of "I really have no idea, what I'm doing here."
 
 -- 
 |----+----|----+----|----+----|----+----|----+----|----+----|----+----|--<
  GPG Fingerprint: D14C 12BB 37A6 6745 7F4F  F420 9E59 D79E A492 2A96
  GPG KeyID      : A4922A96  
 +------------------------------------------------------------------------+


More information about the freebsd-i386 mailing list