Re: fwochi.c and bus_space_barrier()

Sean Bruno wrote:
> On Thu, 2009-04-16 at 22:20 +0200, Andreas Tobler wrote:
>> Sean Bruno wrote:
>>>>> You may want to retry several times.  Like you pointed out in earlier
>>>>> posts, this issue seems to be a race condition.
>>>> Heh, now I remember, I did not speak about a race condition, but about a 
>>>> timing issue.
>>>>
>>>> If I leave the printfs away, it panics here.
>>>>
>>>> for (lps = 0, lps_counter = 0; !lps && lps_counter < 3; lps_counter++) {
>>>>                  lps = (OREAD(sc, OHCI_HCCCTL) & OHCI_HCC_LPS);
>>>>                  if (!lps) {
>>>>                          pause("fwlps", (50 * hz + 999) / 1000);
>>>>                          device_printf(dev, "lps not set, 
>>>> attempt(%d)\n", lps_cou
>>>> nter);
>>>>                  } /* else
>>>>                          device_printf(dev, "lps(%0x) set\n", lps);*/
>>>>          }
>>>>
>>>> In my case the lps is not NULL, so we print something in the first run 
>>>> of the loop, this print statement is enough 'time' for the card to come 
>>>> up. If we leave the printf away, it is not enough time to come up for 
>>>> the card. Panic.
>>>>
>>>> This was the same thing I reported, adding a printf statement at the 
>>>> beginning of fwphy_rddata cures my panic.
>>>>
>>>> So I'd suggest to leave the lps test away and add always a pause(9), or 
>>>> does this cause headache on other archs?
>>>>
>>>> Thanks,
>>>> Andreas
>>>>
>>>
>>> Ok, I think I've finally caught up to Marius (at least in this
>>> situation).  
>>>
>>> The *ACTUAL* issue is that fwochi_probe_phy() code isn't properly
>>> handling the transition state from LPS==0 to LPS==1.  In this period of
>>> time, the internal SCLK on the firewire board may have not started yet.
>>> There can be a period of time between the value of LPS==1 and the SCLK
>>> actually starting.  
>>>
>>> fwphy_rddata() appears to be *trying* to deal with this, but is
>>> obviously failing.  
>>>
>>> So "lps" has been set, but the PHY is not up yet.  In order to access
>>> PHY resources, we have to wait for SCLK to start(OHCI spec v1.1 table
>>> 6.1).
>>>
>>> I believe your error is defined in the OHCI spec, Appendix A.6, PCI Bus
>>> Errors.  The bus error is supposed to happen!  :)  The driver just isn't
>>> handling the error case properly.
>>>
>>> The proper fix is to handle the ERROR according to spec.  I will work on
>>> a proper solution this weekend.  In the meantime, here is a patch to get
>>> you by based on the pause() mechanism.
>>>
> 
> 
> Here is a different, more generic patch that seems to work for me on my
> machines.
> 
> Essentially, make fwphy_rddata() responsible for catching the error and
> implementing the pause().  This *should* have the same effect, unless I
> don't understand what I'm doing.
> 
> I have eliminated the LPS check for now(see ifdef's) in
> fwohci_probe_phy().
> 
> If this works, I will cleanup the ifdef's before I commit.

Unfortunately it doesn't. For me it looks the same as the original trace.

Sorry for the bad news.
Andreas

u60# kldload firewire
fwohci0: <Texas Instruments TSB12LV23> mem 
0x4008000-0x40087ff,0x400c000-0x400ff
ff irq 2008 at device 4.0 on pci0
fwohci0: latency timer 24 -> 32.
fwohci0: cache size 16 -> 16.
fwohci0: [ITHREAD]
fwohci0: OHCI version 1.0 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:10:74:60:00:00:ee:a9
fwohci0: resetting OHCI...done (loop=0)
panic: pcib: PCI bus B error AFAR 0x1ff840080ec AFSR 0x4000f00000000000
cpuid = 0
KDB: stack backtrace:
panic() at 0xc03316e8 = panic+0x1c8
psycho_pci_bus() at 0xc060aac8 = psycho_pci_bus+0x88
intr_event_handle() at 0xc0309b3c = intr_event_handle+0x5c
intr_execute_handlers() at 0xc061aab4 = intr_execute_handlers+0x14
intr_fast() at 0xc00812f0 = intr_fast+0x50
-- interrupt level=0xd pil=0 %o7=0xc0f9cccc --
fwphy_rddata() at 0xc0f9cd0c = fwphy_rddata+0x12c
fwohci_reset() at 0xc0fa113c = fwohci_reset+0x1fc
fwohci_init() at 0xc0fa22b4 = fwohci_init+0x9d4
fwohci_pci_attach() at 0xc0fa2d58 = fwohci_pci_attach+0x278
device_attach() at 0xc03600e4 = device_attach+0x4a4
device_probe_and_attach() at 0xc0361648 = device_probe_and_attach+0x28
pci_driver_added() at 0xc021c7f4 = pci_driver_added+0x154
devclass_driver_added() at 0xc035df34 = devclass_driver_added+0x74
devclass_add_driver() at 0xc035eb3c = devclass_add_driver+0x7c
driver_module_handler() at 0xc035fb78 = driver_module_handler+0x58
module_register_init() at 0xc031e934 = module_register_init+0x154
linker_load_module() at 0xc0315478 = linker_load_module+0xb38
kern_kldload() at 0xc0315a28 = kern_kldload+0xc8
kldload() at 0xc0315c20 = kldload+0x60
syscall() at 0xc062c1e8 = syscall+0x2e8
-- syscall (304, FreeBSD ELF64, kldload) %o7=0x1008e0 --
userland() at 0x4045dd68
user trace: trap %o7=0x1008e0
pc 0x4045dd68, sp 0x7fdffffe1e1
pc 0x1006f0, sp 0x7fdffffe2a1
pc 0x40206954, sp 0x7fdffffe361
done
KDB: enter: panic
[thread pid 1128 tid 100081 ]
Stopped at      0xc0367b40 = kdb_enter+0x80:    ta              %xcc, 1
db>


_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "[email protected]"