PCIデバイスのBARの値がNetBSD/i386とUbuntuとで異なる

dynabook SS SX/15AでNetBSD/i386を使うとサウンドデバイスが認識されない問題を調べています。OSに含まれているPCI管理ツールを使って、そもそもどのように認識されているのかを探ってみました。

まずNetBSDのpcictlを使ってみます。すると以下の情報が得られました。

000:27:0: Intel 82801GB/GR High Definition Audio Controller (mixed mode multimedia, revision 0x02)

オプションを指定して更に詳細な情報を取得してみます。気になる箇所だけを以下に抜粋します。

Base address register at 0x10
  type: 64-bit nonprefetchable memory
  base: 0x0000000000000000, not sized 

また比較するために、Ubuntuのlspciでも情報を取得してみると、次のようになりました。

00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 02)
 Subsystem: Toshiba America Info Systems NM10/ICH7 Family High Definition Audio Controller
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 27
 Region 0: Memory at d2080000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: <access denied>
 Kernel driver in use: snd_hda_intel
 Kernel modules: snd_hda_intel

両者を比べてみると、BARに入っている領域の情報が、64bitである事は一致していますが、開始アドレスが異なっています。NetBSDでは0なのに対して、Ubuntuではd2080000になっています。

デバッグ情報を見るためにextent_alloc_region()にextent_print(9)を入れてみたところ、次のような出力が得られました。この関数の引数には、開始アドレス0で、サイズ0x4000が与えられています。そしてコンフリクトが発生するためエラーが返っています。要求されたのは0x0 ～0x3fffですから、既存の0x0 - 0x9dfffと衝突してしまうのでしょう。

extent `iomem' (0x0 - 0xffffffff), flags = 0x3
     0x0 - 0x9dfff
     0x100000 - 0xcf75ffff
     0xcf760000 - 0xcf760fff
     0xe0000000 - 0xe001ffff
     0xe0020000 - 0xe0407fff
     0xf00d8000 - 0xf00d8fff
     0xf00e0000 - 0xf00e0fff
     0xf00e2000 - 0xf00e2fff
     0xfed00000 - 0xfed003ff
     0xffd40000 - 0xffd7ffff
     0xffd80000 - 0xffdfffff

しかしBARで入っている情報では、64bitフラグが建っているようですし、Ubuntuのように0xd2080000が指定されれば衝突が発生することもなくなると思います。なぜNetBSDでは開始アドレスが0x0なのでしょうか。

そもそも同じハードウェアなのに、どうしてPCI情報を読み取った結果が異なるのでしょうか？