lkml.org 
[lkml]   [2013]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRE: [PATCH 2/2] PCI: fix system hang issue of Marvell SATA host controller
    Hi, Bjorn

    >> >> > Fix system hang issue: if first accessed resource file of BAR0 ~
    >> >> > BAR4, system will hang after executing lspci command
    >> >>
    >> >> This needs more explanation. We've already read the BARs by the
    >> >> time header quirks are run, so apparently it's not just the mere
    >> >> act of accessing a BAR that causes a hang.
    >> >>
    >> >> We need to know exactly what's going on here. For example, do
    >> >> BARs
    >> >> 0-4 exist? Does the device decode accesses to the regions
    >> >> described by the BARs? The PCI core has to know what resources
    >> >> the device uses, so if the device decodes accesses, we can't just
    >> >> throw away the start/end information.
    >> > The BARs 0-4 is exist and the PCI device is enable IO space, but
    >> > user access
    >> the regions file by udevadm command with info parameter, the system will hang.
    >> > Like this: udevadmin info --attribut-walk
    >> --path=/sys/device/pci-device/000:*.
    >> > Because the device is just AHCI host controller, don't need the
    >> > BAR0 ~ 4 region
    >> file.
    >> > Is my explanation ok for the patch?
    >>
    >> No, I still don't know what causes the hang; I only know that udevadm
    >> can trigger it. I don't want to just paper over the problem until we
    >> know what the root cause is.
    >>
    >> Does "lspci -H1 -vv" also cause a hang? What about "setpci -s<dev>
    >> BASE_ADDRESS_0"? "setpci -H1 -s<dev> BASE_ADDRESS_0"?
    > The commands are ok because the commands can't find the device after accessing IO port.
    > The root cause is that accessing of IO port will make the chip go bad. So, the point of the patch is don't export capability of the IO accessing.

    >Ah, so the problem is not with accessing the BAR in config space. The problem is with accessing the I/O port space mapped by the BAR. Is that right?

    Yes...

    >Does "udevadm info --attribute-walk" really access the device address space mapped by the BARs?

    The older version maybe will access the space, I just got the info from HP. And I simplify the issue by executing following command:
    Cat /sys/devices/pci-device/**/resourceX

    I want to set the resources of BAR0 ~ 4 to 0 to avoid the IO accessing by user.

    Any question? Thanks!




    \
     
     \ /
      Last update: 2013-03-09 16:21    [W:9.027 / U:0.268 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site