From owner-acpi-jp@jp.FreeBSD.org Wed Oct  2 01:48:38 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g91GmcN33127;
	Wed, 2 Oct 2002 01:48:38 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g91Gmb333121
	for <acpi-jp@jp.FreeBSD.org>; Wed, 2 Oct 2002 01:48:37 +0900 (JST)
	(envelope-from jhb@FreeBSD.org)
Received: (qmail 7693 invoked from network); 1 Oct 2002 16:48:34 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63])
          (envelope-sender <jhb@FreeBSD.org>)
          by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
          for <obrien@freebsd.org>; 1 Oct 2002 16:48:34 -0000
Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1])
	by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g91GmLBv010687;
	Tue, 1 Oct 2002 12:48:23 -0400 (EDT)
	(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20021001124824.jhb@FreeBSD.org>
X-Mailer: XFMail 1.5.2 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20021001.203749.98096231.iwasaki@jp.FreeBSD.org>
From: John Baldwin <jhb@freebsd.org>
To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>
Cc: acpi-jp@jp.FreeBSD.org, obrien@freebsd.org
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Tue, 01 Oct 2002 12:48:24 -0400
X-Sequence: acpi-jp 1859
Subject: [acpi-jp 1859] RE: (FWD) no floppy drive with acpi.ko loaded
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: jhb@FreeBSD.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+020902


On 01-Oct-2002 Mitsuru IWASAKI wrote:
>> Scope(\_SB_) {
> [snip]
>>     Device(PCI0) {
> [snip]
>>         Device(FDC0) {
>>             Name(_HID, 0x0007d041)
>>             Method(_STA) {
> 
> This means that the fdc is connected to pci directly (path is
> _SB_.PCI0.FDC0), but I think our fdc(4) doesn't have PCI attachment as
> you know.
> If fdc is connected to isa actually, normally there should be a
> PCI-ISA bridge definition between PCI0 and FDC0.
> pciconf -lv output will be helpful.

Eek, that _is_ weird.  Still, it should attach off of 'acpi' due to
the somewhat bogus way that we flatten all ACPI devices and hang them
off acpi0.

> And this is the diff of dmesg output between w/o acpi.ko case and w/ acpi.ko.
> Host-PCI bridge number is different.
> John, does this cause any problems?

No.  The physical bus number is what matters.  The recent legacy driver
actually fixes this and the host->pci bridge should be pcib0 after that.

> @@ -73,8 +74,24 @@
>  embedded    0   18    D   0x05  3 4 5 6 7 10 11 12 14 15
>  npx0: <math processor> on motherboard
>  npx0: INT 16 interface
> -pcib0: <Host to PCI bridge> at pcibus 0 on motherboard
> -pci0: <PCI bus> on pcib0
> +acpi0: <AMIINT VIA_K7  > on motherboard
> +acpi0: power button is handled as a fixed feature programming model.
> +ACPI timer looks GOOD min = 2, max = 3, width = 2
> [snip]
> +ACPI timer looks GOOD min = 2, max = 3, width = 2
> +Timecounter "ACPI-fast"  frequency 3579545 Hz
> +acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> +acpi_cpu0: <CPU> on acpi0
> +acpi_button0: <Power Button> on acpi0
> +pcib1: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> +pci0: <ACPI PCI bus> on pcib1
>  pci0: physical bus=0
>         map[10]: type 3, range 32, base e0000000, size 26, enabled
>  found->        vendor=0x1106, dev=0x3099, revid=0x00
> 
> Off-topic:
>>         Method(_INI) {
>>             \_SB_.PCI0.IODT()
>>             If(MCTH(\_OS_, "Microsoft Windows NT")) {
>>                 Store(0x0, OSFL)
>>             }
>>             Else {
>>                 If(MCTH(\_OS_, "Microsoft Windows")) {
>>                     Store(0x1, OSFL)
>>                 }
>>                 Else {
>>                     If(MCTH(\_OS_, "Microsoft WindowsME: Millennium Edition")) {
>>                         Store(0x2, OSFL)
>>                     }
>>                     Else {
>>                         Store(0x3, OSFL)
>>                     }
> 
> What do you think about this?
> This means that only MS Windows family OS is officially supported by
> BIOS vendor.  You should not surprise if there are any problems on
> unsupported OS.  If you have some problems and want to run unsupported
> OS like FreeBSD, you have to add support code by yourself and
> overrive DSDT at your own risk.  Or report the problem to BIOS vendor
> and get fixed version of BIOS.

At some point we might want to allow a way to override _OS_ perhaps
using a blacklist to know which BIOS's we should override _OS_ and
claim to be some Windows version.

> Thanks

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
