* sd8686 linux system hang: not always @ 2009-08-19 18:56 Benoît Vaillant 2009-08-19 19:39 ` Dan Williams 0 siblings, 1 reply; 5+ messages in thread From: Benoît Vaillant @ 2009-08-19 18:56 UTC (permalink / raw) To: netdev Hi list, It seems my previous message for libertas-dev didn't make its ways through, so resending it... Appologies if it did in any way and for multiple receptions if any :/ Here are a few notes, to try to isolate the issue(s?) regarding this problem. /* Just a bit of context information: I'm using an MID (quite close to an Aigo, although bios differs, probably some hardware too, yet I've not checked much on that). I'm trying to use my Marvell card to get wifi access on a debian installation. The other OS installed (midinux) successfully gets a connection using the 8686_v9 mobilin driver, so I'd not go for any hardware issue. This driver failing to compile 'out of the box' on fresh kernels, I thought getting the libertas module working would be a better way to get through. */ I had the same kernel hang issue as reported earlier on this list[1] and can also confirm the reload issue[2] still seems to be here, although I'm not really bothered by that for the moment and didn't take any time at assessing it. I did a few attempts at getting associated with an AP, initially unsuccessfully getting a hang, my latest attempts leading to a better result (no association, yet no hang! :) ). I've tried both 8.73.7.p3 and 9.70.3.p24 versions of the firmware (and the one provided by midinux, which I highly suspect to be a mere 8.73.7.p3). In my latest attempts, I focused only on the 8.73.7.p3 since it gave good results using iwlist scannig: I could list the available APs fine. Now, with the attempts I did, using a kernel 2.6.31-rc5, I used to hang. Using some manually inserted printk()s, it lead me from the libertas driver to mmc, esp. in drivers/mmc/core.c the mmc_wait_for_req(...) function. It was done without mmc debugging messages, with libertas debugging symbols activated but not printed out. From there on, I switched to the wireless git[3] in order to be able to provide more convinient patches if needed. I immediately patched it against the attached proposal from last thread[4], adapting it due to compile issues (see below). I also gave a quick try at Philip's proposal[5], which didn't seem to work, unfortunately. about the patch: I didn't adapt it as proposed latter on in the thread by setting 0 values, but by reinserting the "old" cmd_ds_802_11_get_log log structure. Wrong thing? The good news using this kernel was that I wasn't always stuck in a hang: listing the APs works, connecting to an AP using WPA & french bands failed, yet without hanging (here, I had MMC & libertas debugging messages). The bad news is I can reproduce the hang using these sources quite easily if I do, say: an association request, followed by an iwconfig to check if the association was done *before* all the attempts were done. The attempts I did using iwconfig once the previous one timed-out were successfull. This leads me to think there are in fact two issues: - an association issue (at least in France). Maybe not much of a problem? I might even be the one doing the wrong thing, not the kernel :) - an issue when accessing the card (race condition?), which could be more subtle to handle. Using the fresh 2.6.31-rc6 kernel.org release, with MMC & libertas debugging messages on, I still can do an association request without getting neither a hang, nor an association. So maybe one of the race issues that are patched in it do solve part of this problem. Yet, running several AP association requests does hang. I'd be glad to do more testing and provide usefull information. Any idea(s) on which track(s) I should now follow and how I can help you solve this issue? Thanks, -- Benoît [1] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002487.html [2] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002510.html [3] git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git [4] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002496.html [5] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002494.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sd8686 linux system hang: not always 2009-08-19 18:56 sd8686 linux system hang: not always Benoît Vaillant @ 2009-08-19 19:39 ` Dan Williams 2009-08-20 20:40 ` Benoît Vaillant 0 siblings, 1 reply; 5+ messages in thread From: Dan Williams @ 2009-08-19 19:39 UTC (permalink / raw) To: Benoît Vaillant; +Cc: netdev On Wed, 2009-08-19 at 20:56 +0200, Benoît Vaillant wrote: > Hi list, > > It seems my previous message for libertas-dev didn't make its ways > through, so resending it... Appologies if it did in any way and for > multiple receptions if any :/ > > Here are a few notes, to try to isolate the issue(s?) regarding this > problem. > > /* > Just a bit of context information: > I'm using an MID (quite close to an Aigo, although bios differs, > probably some hardware too, yet I've not checked much on that). I'm > trying to use my Marvell card to get wifi access on a debian > installation. The other OS installed (midinux) successfully gets a > connection using the 8686_v9 mobilin driver, so I'd not go for any > hardware issue. This driver failing to compile 'out of the box' on > fresh kernels, I thought getting the libertas module working would be > a better way to get through. > */ > > I had the same kernel hang issue as reported earlier on this list[1] > and can also confirm the reload issue[2] still seems to be here, > although I'm not really bothered by that for the moment and didn't > take any time at assessing it. > > I did a few attempts at getting associated with an AP, initially > unsuccessfully getting a hang, my latest attempts leading to a better > result (no association, yet no hang! :) ). > > I've tried both 8.73.7.p3 and 9.70.3.p24 versions of the firmware (and > the one provided by midinux, which I highly suspect to be a mere > 8.73.7.p3). In my latest attempts, I focused only on the 8.73.7.p3 > since it gave good results using iwlist scannig: I could list the > available APs fine. > > Now, with the attempts I did, using a kernel 2.6.31-rc5, I used to > hang. Using some manually inserted printk()s, it lead me from the > libertas driver to mmc, esp. in drivers/mmc/core.c the > mmc_wait_for_req(...) function. It was done without mmc debugging > messages, with libertas debugging symbols activated but not printed > out. Just for context, what SDIO controller are you using on this platform? Dan > From there on, I switched to the wireless git[3] in order to be able > to provide more convinient patches if needed. I immediately patched it > against the attached proposal from last thread[4], adapting it due to > compile issues (see below). I also gave a quick try at Philip's > proposal[5], which didn't seem to work, unfortunately. > > about the patch: I didn't adapt it as proposed latter on in the thread > by setting 0 values, but by reinserting the "old" > cmd_ds_802_11_get_log log structure. Wrong thing? > > The good news using this kernel was that I wasn't always stuck in a > hang: listing the APs works, connecting to an AP using WPA & french > bands failed, yet without hanging (here, I had MMC & libertas > debugging messages). > > The bad news is I can reproduce the hang using these sources quite > easily if I do, say: an association request, followed by an iwconfig > to check if the association was done *before* all the attempts were > done. The attempts I did using iwconfig once the previous one > timed-out were successfull. > > This leads me to think there are in fact two issues: > - an association issue (at least in France). Maybe not much of a > problem? I might even be the one doing the wrong thing, not the > kernel :) > - an issue when accessing the card (race condition?), which could be > more subtle to handle. > > Using the fresh 2.6.31-rc6 kernel.org release, with MMC & libertas > debugging messages on, I still can do an association request without > getting neither a hang, nor an association. So maybe one of the race > issues that are patched in it do solve part of this problem. Yet, > running several AP association requests does hang. > > I'd be glad to do more testing and provide usefull information. Any > idea(s) on which track(s) I should now follow and how I can help you > solve this issue? > > Thanks, > > -- > Benoît > > [1] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002487.html > [2] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002510.html > [3] git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git > [4] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002496.html > [5] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002494.html > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sd8686 linux system hang: not always 2009-08-19 19:39 ` Dan Williams @ 2009-08-20 20:40 ` Benoît Vaillant 2009-08-21 13:04 ` Dan Williams 0 siblings, 1 reply; 5+ messages in thread From: Benoît Vaillant @ 2009-08-20 20:40 UTC (permalink / raw) To: Dan Williams; +Cc: netdev [-- Attachment #1.1: Type: text/plain, Size: 1215 bytes --] On Wed, Aug 19, 2009 at 02:39:57PM -0500, Dan Williams wrote: > On Wed, 2009-08-19 at 20:56 +0200, Benoît Vaillant wrote: > > /* > > Just a bit of context information: > > I'm using an MID (quite close to an Aigo, although bios differs, > > probably some hardware too, yet I've not checked much on that). I'm > > trying to use my Marvell card to get wifi access on a debian > > installation. The other OS installed (midinux) successfully gets a > > connection using the 8686_v9 mobilin driver, so I'd not go for any > > hardware issue. This driver failing to compile 'out of the box' on > > fresh kernels, I thought getting the libertas module working would be > > a better way to get through. > > */ > > <snip> > > Just for context, what SDIO controller are you using on this platform? Sure, i can provide that! lspci claims i's an: 00:e1.0 SD Host controler: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #1 (rev 06) 00:e1.1 SD Host controler: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #2 (rev 06) Complete `lspci -vvv` is attached. Could this lead to anything already known which i have might missed? Thanks, -- Benoît [-- Attachment #1.2: lspci-vvv.txt --] [-- Type: text/plain, Size: 7933 bytes --] 00:00.0 Host bridge: Intel Corporation Device 8101 (rev 06) Subsystem: COMPAL Electronics Inc Device 002e 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 00:02.0 VGA compatible controller: Intel Corporation Device 8109 (rev 06) (prog-if 00 [VGA controller]) Subsystem: COMPAL Electronics Inc Device 002e 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 Interrupt: pin A routed to IRQ 7 Region 0: Memory at c8080000 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at 1800 [size=8] Region 2: Memory at d0000000 (32-bit, non-prefetchable) [size=128M] Region 3: Memory at c8000000 (32-bit, non-prefetchable) [size=128K] Expansion ROM at <unassigned> [disabled] Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [b0] Vendor Specific Information <?> Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: 00000000 Data: 0000 00:1a.0 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB Client Controller (rev 06) (prog-if 80 [Unspecified]) Subsystem: COMPAL Electronics Inc Device 002e 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 Interrupt: pin A routed to IRQ 255 Region 0: Memory at c8020000 (32-bit, non-prefetchable) [disabled] [size=4K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- 00:1b.0 Audio device: Intel Corporation System Controller Hub (SCH Poulsbo) HD Audio Controller (rev 06) Subsystem: COMPAL Electronics Inc Device 002e 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: 64 bytes Interrupt: pin A routed to IRQ 255 Region 0: Memory at c8024000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM L0s Enabled; Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [100] Virtual Channel <?> Capabilities: [130] Root Complex Link <?> 00:1d.0 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB UHCI #1 (rev 06) (prog-if 00 [UHCI]) Subsystem: COMPAL Electronics Inc Device 002e 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 Interrupt: pin A routed to IRQ 23 Region 4: I/O ports at 1820 [size=32] Kernel driver in use: uhci_hcd 00:1d.1 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB UHCI #2 (rev 06) (prog-if 00 [UHCI]) Subsystem: COMPAL Electronics Inc Device 002e 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 Interrupt: pin B routed to IRQ 19 Region 4: I/O ports at 1840 [size=32] Kernel driver in use: uhci_hcd 00:1d.2 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB UHCI #3 (rev 06) (prog-if 00 [UHCI]) Subsystem: COMPAL Electronics Inc Device 002e 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 Interrupt: pin C routed to IRQ 18 Region 4: I/O ports at 1860 [size=32] Kernel driver in use: uhci_hcd 00:1d.7 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB EHCI #1 (rev 06) (prog-if 20 [EHCI]) Subsystem: COMPAL Electronics Inc Device 002e 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 Interrupt: pin D routed to IRQ 21 Region 0: Memory at c8021000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port: BAR=1 offset=00a0 Kernel driver in use: ehci_hcd 00:1e.0 SD Host controller: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #1 (rev 06) (prog-if 01) Subsystem: COMPAL Electronics Inc Device 002e 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 Interrupt: pin A routed to IRQ 22 Region 0: Memory at c8021400 (32-bit, non-prefetchable) [size=256] Kernel driver in use: sdhci-pci 00:1e.1 SD Host controller: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #2 (rev 06) (prog-if 01) Subsystem: COMPAL Electronics Inc Device 002e 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 Interrupt: pin B routed to IRQ 20 Region 0: Memory at c8021800 (32-bit, non-prefetchable) [size=256] Kernel driver in use: sdhci-pci 00:1f.0 ISA bridge: Intel Corporation System Controller Hub (SCH Poulsbo) LPC Bridge (rev 06) Subsystem: COMPAL Electronics Inc Device 002e 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- Kernel driver in use: isch_smbus 00:1f.1 IDE interface: Intel Corporation System Controller Hub (SCH Poulsbo) IDE Controller (rev 06) (prog-if 80 [Master]) Subsystem: COMPAL Electronics Inc Device 002e 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 Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8] Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1] Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8] Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1] Region 4: I/O ports at 1810 [size=16] Kernel driver in use: pata_sch [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sd8686 linux system hang: not always 2009-08-20 20:40 ` Benoît Vaillant @ 2009-08-21 13:04 ` Dan Williams 2009-08-21 22:55 ` Benoît Vaillant 0 siblings, 1 reply; 5+ messages in thread From: Dan Williams @ 2009-08-21 13:04 UTC (permalink / raw) To: Benoît Vaillant; +Cc: netdev On Thu, 2009-08-20 at 22:40 +0200, Benoît Vaillant wrote: > On Wed, Aug 19, 2009 at 02:39:57PM -0500, Dan Williams wrote: > > On Wed, 2009-08-19 at 20:56 +0200, Benoît Vaillant wrote: > > > /* > > > Just a bit of context information: > > > I'm using an MID (quite close to an Aigo, although bios differs, > > > probably some hardware too, yet I've not checked much on that). I'm > > > trying to use my Marvell card to get wifi access on a debian > > > installation. The other OS installed (midinux) successfully gets a > > > connection using the 8686_v9 mobilin driver, so I'd not go for any > > > hardware issue. This driver failing to compile 'out of the box' on > > > fresh kernels, I thought getting the libertas module working would be > > > a better way to get through. > > > */ > > > <snip> > > > > Just for context, what SDIO controller are you using on this platform? > > Sure, i can provide that! > > lspci claims i's an: > 00:e1.0 SD Host controler: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #1 (rev 06) > 00:e1.1 SD Host controler: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #2 (rev 06) > > Complete `lspci -vvv` is attached. > > Could this lead to anything already known which i have might missed? Well, besides the fact that the Poulsbo SDHC driver hasn't actually passed review for the kernel yet... That doesn't mean the Poulsbo driver isn't a fine driver, but if Pierre hasn't acked it, I don't really trust it. The largest # of problems people have had with Libertas SDIO have been with the host controller with things like transfer widths, clocking, interrupt vs. polled mode, chunk size, etc. When the SDHC driver and hardware they are using actually starts working well, then libertas actually starts working well. So I don't mean to brush you off, but we know the chip works pretty well with the Ricoh line (which I'm typing this on right now with an sd8686) and a few other embedded-type controllers. So I'd start diving down into the SDHC driver code for Poulsbo and try to figure out what's going on there and in the MMC layer. Dan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sd8686 linux system hang: not always 2009-08-21 13:04 ` Dan Williams @ 2009-08-21 22:55 ` Benoît Vaillant 0 siblings, 0 replies; 5+ messages in thread From: Benoît Vaillant @ 2009-08-21 22:55 UTC (permalink / raw) To: Dan Williams; +Cc: Benoît Vaillant, netdev [-- Attachment #1: Type: text/plain, Size: 1705 bytes --] Hi, On Fri, Aug 21, 2009 at 08:04:16AM -0500, Dan Williams wrote: > Well, besides the fact that the Poulsbo SDHC driver hasn't actually > passed review for the kernel yet... And other parts of Poulsbo drivers were removed from -at least- debian, for the xorg part of it. I had that in mind. > That doesn't mean the Poulsbo driver isn't a fine driver, but if > Pierre hasn't acked it, I don't really trust it. The largest # of > problems people have had with Libertas SDIO have been with the host > controller with things like transfer widths, clocking, interrupt > vs. polled mode, chunk size, etc. When the SDHC driver and hardware > they are using actually starts working well, then libertas actually > starts working well. Ok. I'll check on parameters when I get spare time. I did consider such things could be part (all? :) ) of the issue. Pointers welcomed, if any other than browsing the web! > So I don't mean to brush you off, but we know the chip works pretty well > with the Ricoh line (which I'm typing this on right now with an sd8686) > and a few other embedded-type controllers. So I'd start diving down > into the SDHC driver code for Poulsbo and try to figure out what's going > on there and in the MMC layer. Hehe, no worry, I know the chip works fine under midinux. Yet compiling such working drivers would either lead me to revert to an older kernel version (and not provide testing with newer ones, thus) or adapt the marvell driver to newer kernel, task which I'm rather not sure to be able to carry by some quite good amount of time :) You didn't brush me off, I wasn't expecting a straight working solution :) TFYA, -- Benoît [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-08-21 22:55 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-08-19 18:56 sd8686 linux system hang: not always Benoît Vaillant 2009-08-19 19:39 ` Dan Williams 2009-08-20 20:40 ` Benoît Vaillant 2009-08-21 13:04 ` Dan Williams 2009-08-21 22:55 ` Benoît Vaillant
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).