Re: Cardbus woes

2001-01-04 Thread Warner Losh
[[ This is drifting over into -arch, so I'm ccing there and asking people to redirect there. ]] [[ The context is what to do about certain kinds of locking with pccard code raising the bigger issue of what to do with interrupts and sleepers in a hostile environemnt ]] In message [EMAIL

Re: Cardbus woes

2001-01-03 Thread Justin T. Gibbs
I was mostly trying to push the locks down so that they weren't held during attach and remove. I was using them to protect mostly the kthread state flag in the softc, as well as other variables in the softc. Comments? It seems to me that having a single thread per-softc gives you this

Re: Cardbus woes

2001-01-03 Thread Justin T. Gibbs
It seems to me that having a single thread per-softc gives you this protection without requiring any locks. Other than having to aquire Giant at thread starup (as most code below us is not thread safe yet), I don't see any other locking requirements. I take that back. In pccbb_detach, you need

Re: Cardbus woes

2000-12-27 Thread Jonathan Chen
On Thu, Dec 14, 2000 at 12:47:51PM -0800, John Baldwin wrote: In other news, while wandering through the cardbus code, I discovered that pccbb softc's have an internal mutex much to my surprise, and that they weren't quite being used properly AFAICT. In the pccb0 kthread, they were

Re: Cardbus woes

2000-12-27 Thread John Baldwin
On 27-Dec-00 Jonathan Chen wrote: On Thu, Dec 14, 2000 at 12:47:51PM -0800, John Baldwin wrote: In other news, while wandering through the cardbus code, I discovered that pccbb softc's have an internal mutex much to my surprise, and that they weren't quite being used properly AFAICT. In

Re: Cardbus woes

2000-12-14 Thread Warner Losh
: http://www.FreeBSD.org/~jhb/patches/pccbb.patch. I took a look a this patch, and saw nothing obviously wrong with it. Mike Smith has some uncommitted patches that might amke the resource issue better, but not completely if I'm reading them right (they are extensive, so I might not be).

Re: Cardbus woes

2000-12-14 Thread Mike Smith
With the recent slaughter^Wrework of the PCI code, my hack to allocate resources for unattached PCI devices in pci_probe_nomatch() no longer works. The updated patch can be found at http://www.FreeBSD.org/~jhb/patches/cardbus.hack.patch. I have a set of working patches at

Re: Cardbus woes

2000-12-14 Thread John Baldwin
On 14-Dec-00 Mike Smith wrote: With the recent slaughter^Wrework of the PCI code, my hack to allocate resources for unattached PCI devices in pci_probe_nomatch() no longer works. The updated patch can be found at http://www.FreeBSD.org/~jhb/patches/cardbus.hack.patch. I have a set of

Re: Cardbus woes

2000-12-14 Thread John Baldwin
On 15-Dec-00 John Baldwin wrote: On 14-Dec-00 Mike Smith wrote: With the recent slaughter^Wrework of the PCI code, my hack to allocate resources for unattached PCI devices in pci_probe_nomatch() no longer works. The updated patch can be found at

Re: Cardbus woes

2000-12-14 Thread Warner Losh
In message [EMAIL PROTECTED] John Baldwin writes: : Also, the cardbus controller seems to not be getting interrupts, as it doesn't : notice when a card is inserted and removed anymore. pccard seems to work, : except that the beeping is gone (this may be due to pcm0 being hosed though). beeping

Re: Cardbus woes

2000-12-14 Thread John Baldwin
On 15-Dec-00 Warner Losh wrote: In message [EMAIL PROTECTED] John Baldwin writes: : Also, the cardbus controller seems to not be getting interrupts, as it : doesn't : notice when a card is inserted and removed anymore. pccard seems to work, : except that the beeping is gone (this may be due to

Re: Cardbus woes

2000-12-14 Thread Mike Smith
I have a set of working patches at http://ziplok.dyndns.org/msmith/pci.diff which handle resource reservation, making your hack unnecessary. They're not ready for commit yet, but they're known to work (assuming you get this message 8). Cool, my hack is all b0rked