send-prしてみました

dynabook SS SX/15Aで動かしているNetBSD/i386でhdaudio(4)が認識できない問題を調べてきましたが、手詰まりになってきたのでsend-prしました。kern/51920として受け付けられたので、何か進展があるでしょう。もしかすると何もアクションを起こしてもらえないかもしれませんが、音が鳴らなくて寂しいというだけのことです。ノートPCのWindows VistaをNetBSD/i386に置き換えることに対して大きな影響を与える事にはならないでしょう。

iomem領域を強制的にすり替えてみたものの失敗

dynabook SS SX/15AにNetBSDを入れてみたところhdaudio(4)がアタッチに失敗します。同じマシンでUbuntuを動かしてみるとアタッチできています。PCIの情報をみても、NetBSDとUbuntuとではiomemのベースアドレスに違いがあり、そういものなのか、何かがおかしいのか、判断できずにいます。

NetBSDではiomem領域がコンフリクトしているようなので、カーネルに手を入れて強制的にUbuntuの場合と同じ領域になるように（言葉は悪いですが）誤魔化してみました。

その結果、多少処理が進みましたが、謎のエラーが増え、結局アタッチできません。

hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at msi0 vec 0
hdaudio0: High Definition Audio version 255.255
hdaudio0: OSS 15 ISS 15 BSS 31 SDO 6 64-bit
hdaudio0: timeout stopping RIRB
hdaudio0: couldn't reset because RIRB is busy
hdaudio0: device driver failed to attach

小手先の対応では駄目なようです。

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情報を読み取った結果が異なるのでしょうか？