Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On Tuesday, August 07, 2012 10:11:01 AM Mike Tancsa wrote: On 8/3/2012 5:26 PM, John Baldwin wrote: If there's a tool for poking at the drives/controller, I would use that, plus camcontrol. Of course you want a data intensive workload (iometer/iozone/xdd with async and sync mode, random reads and sequential reads, etc), and maybe resort to manual testing like pulling drives (power, data) if you don't mind creating failures. If you have some failed/failing drives kicking around, that would be a good test as well (see that all/some of the failure paths are properly stimulated). 3dm2 testing would be good for the ioctl handling, but the most critical tests are basic I/O. Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able to see the 8006 controller I added. Ugh, ok. A few questions: 1) Does the driver see any attached drives/volumes? 2) If it does, does basic I/O to the drives work? 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, fails in that routine when tw_cli makes a request? Thanks. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
On Tue, Aug 07, 2012 at 05:03:13PM +0200, Hans Petter Selasky wrote: On Sunday 05 August 2012 10:33:13 Hans Petter Selasky wrote: On Friday 03 August 2012 10:32:47 Ed Schouten wrote: 2012/8/1 Hans Petter Selasky hsela...@c2i.net: I think the problem is like this, that in order to re-use the unit numbers for USB serial tty devices, the USB stack needs to wait until a TTY is actually freed, right? Else you will have a panic on creating devfs entries having the same name. Indeed. So the USB code could simply pick a different unit number. Hi Ed, USB could use a different Unit number. Some questions: When can the previous unit number be re-used? Is there a callback for this? When can the USB serial code assume that it will not be called again and that all callbacks are drained? Hi, Can you try the attached patch and report back? I applied the patch and reloaded ucom and uplcom. So far there were no power glitches so UPS did not dropped off the bus yet. I have a question regarding the changed fragment of code. Why don't you use unr(9) KPI to manage unit numbers ? pgphlLU9BWRxN.pgp Description: PGP signature
ECMP/FreeBSD its a dream?
Hi... everybody knows the stability of freebsd... but... and the protocol ECMP? its a dream? to use 2 routes with diferent gateways? to load balance? ECMP its a dream? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ECMP/FreeBSD its a dream?
Hi ... You can do that with pf from recent several years :) On Wed, 8 Aug 2012 09:39:43 -0300 Alisson alissongoncal...@bsd.com.br wrote: Hi... everybody knows the stability of freebsd... but... and the protocol ECMP? its a dream? to use 2 routes with diferent gateways? to load balance? ECMP its a dream? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Best Regards, Michael Pounov ELWIX - embedded lightweight unix - WWW: http://www.elwix.org/ EMail: mi...@elwix.org Skype: mpunov XMPP: mi...@aitnet.org Phone: +359 888 737358; +359 899 737358 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ECMP/FreeBSD its a dream?
On 08/08/2012 13:39, Alisson wrote: Hi... everybody knows the stability of freebsd... but... and the protocol ECMP? its a dream? I havent tried but google says http://lists.freebsd.org/pipermail/cvs-src/2008-April/089956.html Its in since 2008 Vince to use 2 routes with diferent gateways? to load balance? ECMP its a dream? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
On Wednesday 08 August 2012 13:31:33 Konstantin Belousov wrote: On Tue, Aug 07, 2012 at 05:03:13PM +0200, Hans Petter Selasky wrote: On Sunday 05 August 2012 10:33:13 Hans Petter Selasky wrote: On Friday 03 August 2012 10:32:47 Ed Schouten wrote: 2012/8/1 Hans Petter Selasky hsela...@c2i.net: I think the problem is like this, that in order to re-use the unit numbers for USB serial tty devices, the USB stack needs to wait until a TTY is actually freed, right? Else you will have a panic on creating devfs entries having the same name. Indeed. So the USB code could simply pick a different unit number. Hi Ed, USB could use a different Unit number. Some questions: When can the previous unit number be re-used? Is there a callback for this? When can the USB serial code assume that it will not be called again and that all callbacks are drained? Hi, Can you try the attached patch and report back? I applied the patch and reloaded ucom and uplcom. So far there were no power glitches so UPS did not dropped off the bus yet. I have a question regarding the changed fragment of code. Why don't you use unr(9) KPI to manage unit numbers ? Probably I could, but right now the unr interface doesn't support pending unit free which I need for other reasons, see below. Ed: I would really like to see a custom argument for the tsw_free(), because it only needs to know the unit number, and the xsc for UCOM is freed when this is called and cannot be referred. Is it possible to have a separate void * for the tsw_free() function? Is this something which you can implement? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
2012/8/8 Hans Petter Selasky hsela...@c2i.net: I have a question regarding the changed fragment of code. Why don't you use unr(9) KPI to manage unit numbers ? Probably I could, but right now the unr interface doesn't support pending unit free which I need for other reasons, see below. What does `pending unit free' mean? I also would prefer it if you used unr(9) -- not just here, but across the entire USB stack. Ed: I would really like to see a custom argument for the tsw_free(), because it only needs to know the unit number, and the xsc for UCOM is freed when this is called and cannot be referred. Is it possible to have a separate void * for the tsw_free() function? Is this something which you can implement? We could extend the TTY code to allow the softc to be changed, e.g. tty_set_softc(). This function could be called right before calling tty_rel_gone(). Still, I would prefer it if these kind of things would not be part of the API. Is there really no way the deallocation of the softc can be delayed until tsw_free() is called? Thanks, -- Ed Schouten e...@80386.nl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
On Wednesday 08 August 2012 19:24:18 Ed Schouten wrote: Ed: I would really like to see a custom argument for the tsw_free(), because it only needs to know the unit number, and the xsc for UCOM is freed when this is called and cannot be referred. Is it possible to have a separate void * for the tsw_free() function? Is this something which you can implement? We could extend the TTY code to allow the softc to be changed, e.g. tty_set_softc(). This function could be called right before calling tty_rel_gone(). Still, I would prefer it if these kind of things would Are you sure that the new softc won't be used in any callbacks when tty_rel_gone() is called, except for tsw_free() ? not be part of the API. Is there really no way the deallocation of the softc can be delayed until tsw_free() is called? Yes, but that is inconvenient. We use the automatically allocated softc given to the driver by newbus. When detach() returns, the softc is freed. Then we need to block in detach, and that is causing the problem! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
On Wednesday 08 August 2012 19:24:18 Ed Schouten wrote: 2012/8/8 Hans Petter Selasky hsela...@c2i.net: I have a question regarding the changed fragment of code. Why don't you use unr(9) KPI to manage unit numbers ? Probably I could, but right now the unr interface doesn't support pending unit free which I need for other reasons, see below. What does `pending unit free' mean? I also would prefer it if you used unr(9) -- not just here, but across the entire USB stack. It is like a drain state, where a unit is collected for free, and then committed to free state when the tsw_free() is called. In the [unlocked] time in between the unit cannot be re-used. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
On 8/8/2012 7:27 AM, John Baldwin wrote: Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able to see the 8006 controller I added. Ugh, ok. A few questions: 1) Does the driver see any attached drives/volumes? Yes 2) If it does, does basic I/O to the drives work? yes 3) Can you add some debugging printfs to twe_ioctl() to see what, if anything, fails in that routine when tw_cli makes a request? Yes, for sure. Let me know what you would like me to add. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
Hi Hans, 2012/8/8 Hans Petter Selasky hsela...@c2i.net: Are you sure that the new softc won't be used in any callbacks when tty_rel_gone() is called, except for tsw_free() ? Yes. Otherwise you would have already seen a kernel panic. See /sys/sys/ttydevsw.h; it has assertions on the locking. It is like a drain state, where a unit is collected for free, and then committed to free state when the tsw_free() is called. In the [unlocked] time in between the unit cannot be re-used. How is this different from calling alloc/free directly? Why would it need to go through this `drain' state? -- Ed Schouten e...@80386.nl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
On Wed, Aug 08, 2012 at 07:42:24PM +0200, Hans Petter Selasky wrote: On Wednesday 08 August 2012 19:24:18 Ed Schouten wrote: 2012/8/8 Hans Petter Selasky hsela...@c2i.net: I have a question regarding the changed fragment of code. Why don't you use unr(9) KPI to manage unit numbers ? Probably I could, but right now the unr interface doesn't support pending unit free which I need for other reasons, see below. What does `pending unit free' mean? I also would prefer it if you used unr(9) -- not just here, but across the entire USB stack. It is like a drain state, where a unit is collected for free, and then committed to free state when the tsw_free() is called. In the [unlocked] time in between the unit cannot be re-used. Still, why do you need such intermediate state ? You cannot reuse the unit number while it is in the 'pending free' still, AFAIU. pgpDMHeuGMbPy.pgp Description: PGP signature
Re: ttydev_cdevsw has no d_purge
On Wednesday 08 August 2012 23:51:55 Konstantin Belousov wrote: On Wed, Aug 08, 2012 at 07:42:24PM +0200, Hans Petter Selasky wrote: On Wednesday 08 August 2012 19:24:18 Ed Schouten wrote: 2012/8/8 Hans Petter Selasky hsela...@c2i.net: I have a question regarding the changed fragment of code. Why don't you use unr(9) KPI to manage unit numbers ? Probably I could, but right now the unr interface doesn't support pending unit free which I need for other reasons, see below. What does `pending unit free' mean? I also would prefer it if you used unr(9) -- not just here, but across the entire USB stack. It is like a drain state, where a unit is collected for free, and then committed to free state when the tsw_free() is called. In the [unlocked] time in between the unit cannot be re-used. Still, why do you need such intermediate state ? You cannot reuse the unit number while it is in the 'pending free' still, AFAIU. Because of the order in which structures are freed. See other e-mail. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
On Wednesday 08 August 2012 22:46:28 Ed Schouten wrote: Hi Hans, 2012/8/8 Hans Petter Selasky hsela...@c2i.net: Are you sure that the new softc won't be used in any callbacks when tty_rel_gone() is called, except for tsw_free() ? Yes. Otherwise you would have already seen a kernel panic. See /sys/sys/ttydevsw.h; it has assertions on the locking. It is like a drain state, where a unit is collected for free, and then committed to free state when the tsw_free() is called. In the [unlocked] time in between the unit cannot be re-used. How is this different from calling alloc/free directly? Why would it need to go through this `drain' state? Because multiple TTYS can share the same ucom unit, and then stuff gets more complicated. I would then need refcounting and such to figure out when to actually free everything. This is simply not needed. I'll make a patch soonish to extend tty.h with a #define tty_set_softc() if you don't mind. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
