Re: How to get a device_t
On Wed, 6 Aug 2003 13:00:13 +0200
Bernd Walter <[EMAIL PROTECTED]> wrote:
>
> Back to the original question:
> How do I get the device_t from nexus?
> Is there a get_nexus() function somewhere?
You can do it this way:
devclass_t nexusdc = devclass_find("nexus");
device_t nexus = devclass_get_device(nexusdc, 0);
It is in fact in the code path as "parent" in nexus_pcib_identify,
but not in the special PCI bridge identification function. If you
call BUS_ADD_CHILD at that time, you don't need to probe or attach
your device; it will be automatically probed and attached later and
you can whatever logic you want in your probe and attach routines.
Eric
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: possible deadlocks?
On 11-Aug-2003 Ted Unangst wrote: > one more. This falls into the very improbable category. Ordinarily, I > don't think this is possible because FreeBSD doesn't support hotplug PCI, > so sk attachment can't be raced. > > However, assuming I had some hot plug sk card, it seems like running > ifconfig sk0 at just the wrong point during sk1 attach will deadlock. If > it absolutely can not happen (for a reason other than sk is attached > before init runs) please explain. > > sk.c: > sk_attach_xmac() > SK_LOCK(sc); /* grabs */ > ether_ifattach() > ifattach() > IFNET_WLOCK() /* waits for 2 */ > > in6_ifattach.c: > in6_nigroup_attach() > IFNET_RLOCK() /* grabs */ > in6_addmulti() > if_addmulti() > sk_ioctl() > SK_IF_LOCK(); /* waits for 1 */ You can't ifconfig sk0 until after it attaches. sk0 and sk1 don't share locks, so you don't have to worry about the interaction there. Also, SK_LOCK != SK_IF_LOCK, or is that a typo? If it is a typo, then the lock order should still be fixed in some fashion. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB versus SMP and Epson printers.
On 6 Aug, Frank Mayhar wrote: > On Monday I received my brand-new Epson C82, a replacement for a 900N with > a dead print head. I had already configured CUPS so I imagined that I would > just hook it up with USB and everything would be happy. > > Well, that's not how it turned out. > > I tried two different machines, both with Tyan dual-CPU motherboards. One > is a Thunder 2500 (S1867) with dual PIII 866, my gateway/fax/server > box and the one I preferred. The other is my main desktop box, a Tiger > MPX (2466N-4M) with dual Athlon MP 1900+. Both displayed essentially > the same problem, although the Tiger MPX seemed to come a little bit > closer to working than the Thunder 2500. > > Basically, although usbdevs would show the device, when I tried to do, > say, an 'escputil -s -r /dev/ulpt0' (to show the ink levels), the process > would seem to send something to the printer (I say "seem to" because I > saw no evidence of it on the printer side), then sit in the USB code > forever, timing out and looping. Unless someone snuck it in while I wasn't looking, our ulpt implementation doesn't support reading data from the printer, so it's not possible to check the ink levels. I've had to boot Linux in order to do this. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: possible deadlocks?
On 12-Aug-2003 Peter Jeremy wrote: > On Mon, Aug 11, 2003 at 03:50:26PM -0700, Ted Unangst wrote: >>On Mon, 11 Aug 2003, John Baldwin wrote: >>> Also, SK_LOCK != SK_IF_LOCK, or is that a typo? If it is a typo, >>> then the lock order should still be fixed in some fashion. >> >>They are the same. SK_IF_LOCK is called on the sk_if_softc, but just >>locks the shared sk_softc mutex. Does that make sense? >> >>#define SK_LOCK(_sc)mtx_lock(&(_sc)->sk_mtx) >>#define SK_IF_LOCK(_sc) mtx_lock(&(_sc)->sk_softc->sk_mtx) > > This strikes me as a particularly poor selection of macros. They > look like they are different locks and I'm sure John won't be the > only person who gets caught believing they really are different. > > Getting locking right is difficult enough without having the same lock > called different things in different places. This is an area where > C++ would be cleaner - you have two (inline) functions with the same > name and the compiler picks the appropriate one based on the argument > type. Failing that, I think the code would be cleaner without the > macros or with SK_IF_LOCK() references replaced by SK_LOCK(). Definitely agreed. That is gross. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
