PCI Bus EEH Error Recovery

EEH 개요

저자는 Linas Vepstas이며 문서 날짜는 2005년 1월 12일입니다. IBM POWER 기반 pSeries와 iSeries의 PCI bus controller는 다양한 PCI bus error를 감지하고 보고하는 Enhanced Error Handling (`EEH`) 기능을 제공합니다.

EEH hardware는 OS를 reboot하지 않고 PCI bus error를 clear하고 개별 PCI card를 다시 시작할 수 있게 합니다. 전통적 PCI에서는 chip이 CPU에 직접 연결되어 error가 CPU machine-check/check-stop을 일으켜 CPU 전체를 멈추거나, error를 무시해 user/kernel data corruption, adapter hang, system crash/lockup을 초래했습니다.

EEH의 목적은 OS를 PCI error에서 보호하고 개별 device를 recover해 system 신뢰성과 견고성을 높이는 것입니다. PCI-E specification 기반의 다른 vendor system도 미래에 비슷한 기능을 제공할 수 있습니다.

EEH error 원인

EEH는 원래 열, 습기, 먼지, 진동, 불량 electrical connection으로 PCI card가 고장 나는 hardware failure를 막기 위해 설계되었습니다. 실제 error의 대부분은 card가 slot에 제대로 꽂히지 않았거나 device-driver bug, firmware bug, PCI-card hardware bug 때문에 발생합니다.

가장 흔한 software bug는 device가 자기 card에 DMA access로 reserve되지 않은 system-memory location으로 DMA를 시도하는 것입니다. EEH는 bad DMA가 만들었을 silent memory corruption을 막으며, 이 방식으로 여러 driver bug가 발견되고 수정되었습니다.

다른 원인은 data/address line parity error와 PCI-X split-completion error입니다. 실제 hardware failure의 대다수는 PCI card를 물리적으로 빼서 다시 제대로 꽂으면 해결됩니다.

PHB isolation과 일반 recovery

PCI Host Bridge (`PHB`)가 PCI error를 감지하면 영향받은 card를 isolate합니다. Isolation은 system에서 card로, card에서 system으로 가는 모든 write를 막고 8/16/32-bit read가 각각 `0xff`, `0xffff`, `0xffffffff`를 반환하게 합니다. 이는 slot에서 device를 물리적으로 뺐을 때와 같은 값입니다.

PCI memory, I/O space, config space access가 모두 isolation 대상이지만 interrupt는 계속 전달됩니다.

Detection과 recovery는 ppc64 firmware의 Run-Time Abstraction Services (`RTAS`)를 통해 수행합니다. Linux가 여러 chipset의 서로 다른 interface와 quirk를 직접 다루지 않도록 firmware가 pSeries/iSeries 전체에 uniform하고 forward-compatible한 abstraction을 제공합니다.

OS나 driver가 slot isolation을 의심하면 firmware call로 확인합니다. 실제 isolation이면 driver는 pending work를 끝낼 수 없다는 전제에서 consistent state로 전환하고 card recovery를 시작합니다.

일반 recovery는 PCI #RST line을 2초 동안 assert해 device를 reset하고 BAR, latency timer, cache-line size, interrupt line 등의 config space를 재설정한 다음 driver를 다시 initialize합니다. Hot-plug slot에서는 최악의 경우 card power를 cycle할 수 있습니다. 상위 layer는 reset 동안 Ethernet/disk/USB I/O가 잠시 멈추는 것 외에는 card reboot를 몰라야 이상적입니다.

3~4회 reset 뒤에도 recover하지 못하면 card가 완전히 죽었다고 보고 sysadmin에게 알립니다. RTAS와 `syslogd`의 `/var/log/messages`에도 reset error를 기록합니다. 고장 adapter는 표준 PCI hotplug tool로 제거하고 교체해야 합니다.

현재 PPC64 Linux EEH 구현

현재 구현은 개별 driver 변경 없이 동작하는 generic EEH recovery mechanism입니다. PCI hotplug infrastructure를 활용하고 userspace/udev까지 event를 전달합니다.

EEH는 boot 아주 초기에 PHB별로, 그리고 PCI slot hotplug 때 enable해야 합니다. Boot path는 `arch/powerpc/platforms/pseries/eeh.c`의 `eeh_init()`이, hotplug path는 `drivers/pci/hotplug/pSeries_pci.c`가 eeh.c를 호출해 수행합니다. Device PCI scan보다 먼저 enable해야 합니다.

Power5 hardware는 EEH가 없으면 동작하지 않고 older Power4만 disable 상태로 실행할 수 있으므로 사실상 EEH를 끌 수 없습니다. 모든 PCI device는 EEH code에 등록되어야 하며, error detection을 위해 device의 I/O address range를 알아야 합니다. 임의 address에 대응하는 device는 `pci_get_device_by_addr()`로 찾습니다.

`arch/powerpc/include/asm/io.h`의 기본 `readb()`, `inb()`, `insb()` 등은 I/O read가 all-`0xff`인지 검사합니다. 그러면 `eeh_dn_check_failure()`가 firmware에 실제 EEH error인지 묻고, 아니라면 정상 처리합니다. False alarm 총계는 변경 가능성이 있는 `/proc/ppc64/eeh`에서 볼 수 있으며 대부분 PCI scan이 많은 `0xff` read를 만드는 boot 중 발생합니다.

Frozen slot을 감지하면 `arch/powerpc/platforms/pseries/eeh.c`가 `/var/log/messages`에 stack trace를 기록합니다. Error 자체가 보통 조금 앞서 발생하므로 이 trace는 driver author가 detection 지점을 찾는 데 유용합니다.

그 다음 notifier chain/work queue로 failure event를 배포합니다. Driver나 다른 kernel component는 `eeh_register_notifier(struct notifier_block *)`로 등록하고 PCI device pointer, device node, state 정보를 받습니다.

Hotplug handler recovery sequence

`drivers/pci/hotplug/pSeries_pci.c`의 `handle_eeh_events()`가 EEH `notifier_block` event를 처리합니다. 먼저 device BAR를 저장하고 `rpaphp_unconfig_pci_adapter()`를 호출해 card driver를 stop합니다.

Driver stop은 userspace로 uevent를 보내 Ethernet card의 `ifdown eth0` 같은 script를 trigger합니다. Handler는 script가 끝날 시간을 주려고 5초 sleep한 뒤 PCI card를 reset하고 BAR와 하위 bridge를 재구성합니다.

마지막으로 `rpaphp_enable_pci_slot()`이 driver를 재시작하고 `ifup eth0` 같은 추가 userspace event를 trigger합니다.

Device shutdown call chain

PCI slot unconfigure의 첫 단계에서 pcnet32 driver close function까지 이어지는 원문 call sequence는 다음과 같습니다.

rpa_php_unconfig_pci_adapter (struct slot *)  // in rpaphp_pci.c
{
  calls
  pci_remove_bus_device (struct pci_dev *) // in /drivers/pci/remove.c
  {
    calls
    pci_destroy_dev (struct pci_dev *)
    {
      calls
      device_unregister (&dev->dev) // in /drivers/base/core.c
      {
        calls
        device_del (struct device *)
        {
          calls
          bus_remove_device() // in /drivers/base/bus.c
          {
            calls
            device_release_driver()
            {
              calls
              struct device_driver->remove() which is just
              pci_device_remove()  // in /drivers/pci/pci_driver.c
              {
                calls
                struct pci_driver->remove() which is just
                pcnet32_remove_one() // in /drivers/net/pcnet32.c
                {
                  calls
                  unregister_netdev() // in /net/core/dev.c
                  {
                    calls
                    dev_close()  // in /net/core/dev.c
                    {
                       calls dev->stop();
                       which is just pcnet32_close() // in pcnet32.c
                       {
                         which does what you wanted
                         to stop the device
                       }
                    }
                 }
               which
               frees pcnet32 device driver memory
            }
 }}}}}}

핵심 경로는 `rpa_php_unconfig_pci_adapter()` → `pci_remove_bus_device()` → `pci_destroy_dev()` → `device_unregister()` → `device_del()` → `bus_remove_device()` → `device_release_driver()` → `pci_device_remove()` → `pcnet32_remove_one()` → `unregister_netdev()` → `dev_close()` → `pcnet32_close()`입니다.

`pcnet32_close()`가 device를 실제로 stop하고, 상위 remove path는 pcnet32 driver memory를 free합니다. 원문 247~253행은 `drivers/pci/pci_driver.c`에서 시작하는 같은 tail sequence를 다시 요약합니다.

Userspace uevent call chain

PCI device unconfigure가 userspace script에 event를 보내는 대응 call trace는 다음과 같습니다.

rpa_php_unconfig_pci_adapter() {             // in rpaphp_pci.c
  calls
  pci_remove_bus_device (struct pci_dev *) { // in /drivers/pci/remove.c
    calls
    pci_destroy_dev (struct pci_dev *) {
      calls
      device_unregister (&dev->dev) {        // in /drivers/base/core.c
        calls
        device_del(struct device * dev) {    // in /drivers/base/core.c
          calls
          kobject_del() {                    //in /libs/kobject.c
            calls
            kobject_uevent() {               // in /libs/kobject.c
              calls
              kset_uevent() {                // in /lib/kobject.c
                calls
                kset->uevent_ops->uevent()   // which is really just
                a call to
                dev_uevent() {               // in /drivers/base/core.c
                  calls
                  dev->bus->uevent() which is really just a call to
                  pci_uevent () {            // in drivers/pci/hotplug.c
                    which prints device name, etc....
                 }
               }
               then kobject_uevent() sends a netlink uevent to userspace
               --> userspace uevent
               (during early boot, nobody listens to netlink events and
               kobject_uevent() executes uevent_helper[], which runs the
               event process /sbin/hotplug)
           }
         }
         kobject_del() then calls sysfs_remove_dir(), which would
         trigger any user-space daemon that was watching /sysfs,
         and notice the delete event.

핵심 경로는 `device_del()` → `kobject_del()` → `kobject_uevent()` → `kset_uevent()` → `dev_uevent()` → PCI bus의 `pci_uevent()`입니다. `pci_uevent()`가 device name 등을 기록하고 `kobject_uevent()`가 netlink uevent를 userspace로 보냅니다.

Early boot에서 netlink listener가 없으면 `kobject_uevent()`가 `uevent_helper[]`를 실행해 `/sbin/hotplug` event process를 시작합니다. 이후 `kobject_del()`은 `sysfs_remove_dir()`을 호출하므로 sysfs를 감시하던 daemon도 delete event를 알아챌 수 있습니다.

현재 설계의 장단점

현재 generic design의 가장 큰 장점은 개별 device driver를 바꾸지 않아도 넓은 범위를 보호한다는 점입니다. 가장 큰 단점은 영향을 받을 필요가 없던 network daemon과 filesystem까지 방해할 수 있다는 점입니다.

• Network card reset은 연속 `ifdown`/`ifup` userspace 동작을 만들어 card reboot를 몰라도 될 network daemon을 흔들 수 있습니다.
• SCSI device reset은 mounted filesystem에 더 심각한 문제를 만듭니다. I/O가 이미 멈춘 뒤에는 pending buffer를 flush하며 unmount할 수 없으므로 reset을 block layer 이하에서 처리해 filesystem을 건드리지 않는 것이 이상적입니다.
• Ext3fs는 성공할 때까지 read/write를 retry해 이 상황을 견디는 것으로 보이지만 가볍게만 test되었습니다.
• SCSI-generic subsystem은 command failure 때 SCSI device, bus, HBA reset을 연쇄 시도하며 이를 block layer에서 숨깁니다. 이 chain에 EEH reset을 추가하는 것이 자연스럽습니다.
• Root device에서 SCSI error가 나면 sysadmin이 `/bin`, `/sbin`, `/etc`, `/var` 등을 ramdisk/tmpfs에 배치해 두지 않은 한 system을 복구할 수 없습니다.

결론

결론적으로 EEH software recovery에는 개선할 지점이 남아 있지만 forward progress가 이루어지고 있습니다.