Re: traditional syscalls with DRIVER_MODULE ????
Hi, On Wednesday 25 May 2011 21:02:29 Jim Bryant wrote: > do start_read/stop_read and start_write/stop_write map directly to the > userland read(2) and write(2) calls? No, but they are called from these calls. The idea is that you use the FIFO mechanism already present there when moving data, and poll() will be automatically handled. Probably that is not suitable for your purpose? > i had looked at this previously, and am a bit confused on if the above > is correct. > > even if they are the direct interface to read(2)/write(2), the issue of > a poll method for select(2) still exists... > > grepping all DRIVER_MODULE usages comes up with only two poll methods: > > powerpc/powermac/pmu.c:DEVMETHOD(adb_hb_controller_poll, > pmu_poll), > powerpc/powermac/cuda.c: DEVMETHOD(adb_hb_controller_poll, > cuda_poll), > > and those are unhelpful. > > please excuse me if these are newbie questions, but, i'm still in the > learning process. It is OK to ask questions :-) > > i can do this if there is a way to prevent DRIVER_MODULE from creating > the devfs nodes, and instead do this in a hybrid way using DRIVER_MODULE > and make_dev(9), which has the exact traditional functionality i want in > this. any ideas? Why can't you create the node when you receive a device_attach event? > two of the three device nodes this driver will create > will require read(2)/select(2) interfaces visible to userland, and the > third driver will require write(2) visible to userland. > the question is: is there a way to use DRIVER_MODULE, which seems > necessary for usbdi, yet create the devfs nodes using make_dev/cdevsw? > i would prefer to not have DRIVER_MODULE create the device nodes. DRIVER_MODULE() only will create devices if you have a load function which does so. It is only called once! --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: traditional syscalls with DRIVER_MODULE ????
do start_read/stop_read and start_write/stop_write map directly to the userland read(2) and write(2) calls? i had looked at this previously, and am a bit confused on if the above is correct. even if they are the direct interface to read(2)/write(2), the issue of a poll method for select(2) still exists... grepping all DRIVER_MODULE usages comes up with only two poll methods: powerpc/powermac/pmu.c:DEVMETHOD(adb_hb_controller_poll, pmu_poll), powerpc/powermac/cuda.c: DEVMETHOD(adb_hb_controller_poll, cuda_poll), and those are unhelpful. usb_fifo_methods doesn't seem to have a poll, how would i go about this? select(2) is a more familiar interface for application programmers to use for this purpose, instead of using an ioctl for the same functionality in a way that is not compatible with select(2). please excuse me if these are newbie questions, but, i'm still in the learning process. i can do this if there is a way to prevent DRIVER_MODULE from creating the devfs nodes, and instead do this in a hybrid way using DRIVER_MODULE and make_dev(9), which has the exact traditional functionality i want in this. any ideas? two of the three device nodes this driver will create will require read(2)/select(2) interfaces visible to userland, and the third driver will require write(2) visible to userland. the question is: is there a way to use DRIVER_MODULE, which seems necessary for usbdi, yet create the devfs nodes using make_dev/cdevsw? i would prefer to not have DRIVER_MODULE create the device nodes. am i missing something? i again apologize for the newbie questions... jim Hans Petter Selasky wrote: On Tuesday 24 May 2011 23:19:27 Jim Bryant wrote: if i add such an interface to the current DRIVER_MODULE version, how would i go about NOT having DRIVER_MODULE create the devfs entries? i would prefer to have the devfs entries handled by make_dev, so to have access to the desired syscalls. Look at /sys/dev/usb/serial/ulpt.c For a simple example. More abstract: "cd /usr/ports/multimedia/cuse4bsd" and "man libusb20" --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: System hang in USB umass module while processing panic
On Wednesday 25 May 2011 19:37:01 Shah, Vishal wrote:
> Hi Hans Petter,
>
> Thanks for looking into this.
> The command is not hanging on a USB device. The issue is, command never
> reaches the USB device. As I understand it, after receiving the command
> from the upper layers, umass layer will just enqueue the xfer at the
> USBD layer. And then usb_proc process is supposed to take the xfer from
> the queue and give it to the EHCI layer. When the system panics and gets
> into the uni-processor environment, the current process issues a
> SYNCHRONIZE_CACHE command keeps polling the umass layer for the
> completion of that xfer, and won't leave the single running CPU. For
> this reason, the usb_proc is never scheduled after that and the xfer
> never reaches the USB device.
>
> Thanks,
> Vishal
Hi,
In UNI processor mode the following function will be called, which will poll
the transfers (at the side of the USB processes):
static void
umass_cam_poll(struct cam_sim *sim)
{
struct umass_softc *sc = (struct umass_softc *)sim->softc;
if (sc == UMASS_GONE)
return;
DPRINTF(sc, UDMASS_SCSI, "CAM poll\n");
usbd_transfer_poll(sc->sc_xfer, UMASS_T_MAX);
}
If the umass_cam_poll() is not called, then any pending SCSI commands will not
complete.
However, if the panic triggers inside the USB stack, this might not work like
expected.
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
RE: System hang in USB umass module while processing panic
Hi Hans Petter, Thanks for looking into this. The command is not hanging on a USB device. The issue is, command never reaches the USB device. As I understand it, after receiving the command from the upper layers, umass layer will just enqueue the xfer at the USBD layer. And then usb_proc process is supposed to take the xfer from the queue and give it to the EHCI layer. When the system panics and gets into the uni-processor environment, the current process issues a SYNCHRONIZE_CACHE command keeps polling the umass layer for the completion of that xfer, and won't leave the single running CPU. For this reason, the usb_proc is never scheduled after that and the xfer never reaches the USB device. Thanks, Vishal -Original Message- From: Hans Petter Selasky [mailto:hsela...@freebsd.org] Sent: Wednesday, May 25, 2011 8:11 AM To: Andriy Gapon Cc: Shah, Vishal; freebsd-usb@FreeBSD.org; Ranaweera, Samantha; Faylor, Christopher Subject: Re: System hang in USB umass module while processing panic On Wednesday 25 May 2011 17:01:24 Andriy Gapon wrote: > on 19/05/2011 22:27 Shah, Vishal said the following: > > In FreeBSD 8 USB driver, commands are asynchronously sent from umass > > layer onto the wire, in other words, multiple threads are involved > > before the command is sent from the umass layer all the way to the wire. > > Since the usb_proc is not scheduled current process keeps waiting for > > the command to complete, hence the hang. Is this a known issue? If yes, > > is there a fix available? Are there any plans of adding a synchronous > > path to send the command to the device? Any information regarding this > > issue is much appreciated. > > From your description this sounds like a problem in USB driver. > I am not an expert in USB code, looks like some polling prodding would have > to be added there (if it's not there yet). Hans Petter may be a better > contact for this issue. > I am not sure if I can help you more. Hi, The umass driver is being polled during panic. If some command is hanging on a USB device then USB cannot do anything about it. Only the CAM layer can abort the SCSI command, because the USB layer doesn't know if it is the dump device or not? Sometimes the command timeouts are rather longs so waiting until the command times out might work to get a core dump. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: System hang in USB umass module while processing panic
On Wednesday 25 May 2011 17:01:24 Andriy Gapon wrote: > on 19/05/2011 22:27 Shah, Vishal said the following: > > In FreeBSD 8 USB driver, commands are asynchronously sent from umass > > layer onto the wire, in other words, multiple threads are involved > > before the command is sent from the umass layer all the way to the wire. > > Since the usb_proc is not scheduled current process keeps waiting for > > the command to complete, hence the hang. Is this a known issue? If yes, > > is there a fix available? Are there any plans of adding a synchronous > > path to send the command to the device? Any information regarding this > > issue is much appreciated. > > From your description this sounds like a problem in USB driver. > I am not an expert in USB code, looks like some polling prodding would have > to be added there (if it's not there yet). Hans Petter may be a better > contact for this issue. > I am not sure if I can help you more. Hi, The umass driver is being polled during panic. If some command is hanging on a USB device then USB cannot do anything about it. Only the CAM layer can abort the SCSI command, because the USB layer doesn't know if it is the dump device or not? Sometimes the command timeouts are rather longs so waiting until the command times out might work to get a core dump. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: System hang in USB umass module while processing panic
on 19/05/2011 22:27 Shah, Vishal said the following: > In FreeBSD 8 USB driver, commands are asynchronously sent from umass layer > onto > the wire, in other words, multiple threads are involved before the command is > sent from the umass layer all the way to the wire. Since the usb_proc is not > scheduled current process keeps waiting for the command to complete, hence the > hang. Is this a known issue? If yes, is there a fix available? Are there any > plans of adding a synchronous path to send the command to the device? Any > information regarding this issue is much appreciated. >From your description this sounds like a problem in USB driver. I am not an expert in USB code, looks like some polling prodding would have to be added there (if it's not there yet). Hans Petter may be a better contact for this issue. I am not sure if I can help you more. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB driver locking
On 5/25/11 12:54 AM, Daniel O'Connor wrote: On 25/05/2011, at 9:51, Hans Petter Selasky wrote: current. There is also a new utility called usbdump, which can be used to figure out what is going on. I am running 9-current (in production for my sins..) usbdump is useful but consumes too much CPU at my data rate :( You probably need an USB analyzer to figure out the real problem. Have you tried to start usbdump only once the problem happens? I'll try and cook something up to run it when the problem happens. hans and Daniel, I suggest you put some KTR points into the driver and trace some crucial information using that. it is capable of keeping up with very fast stuff with small disturbance. Just the basic info.. you get 5 x 64 bit arguments. (or is it 6?) which is enough space for quite a bit of stuff to be logged. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB driver locking
On 25/05/2011, at 9:51, Hans Petter Selasky wrote: >>> current. There is also a new utility called usbdump, which can be used to >>> figure out what is going on. >> >> I am running 9-current (in production for my sins..) >> >> usbdump is useful but consumes too much CPU at my data rate :( > > You probably need an USB analyzer to figure out the real problem. Have you > tried to start usbdump only once the problem happens? I'll try and cook something up to run it when the problem happens. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB driver locking
On Wednesday 25 May 2011 09:47:50 Daniel O'Connor wrote: > On 25/05/2011, at 9:33, Hans Petter Selasky wrote: > > On Tuesday 24 May 2011 23:48:30 Daniel O'Connor wrote: > >> I find that my application has rare problems where it does not get a > >> reply from the micro to a control bus packet, or perhaps the micro > >> doesn't receive it (I need to add a sequence number or similar to my > >> protocol to try and detect it I think). > > > > There was a data toggle issue fixed with the EHCI recently, which > > triggers depending on hardware timing. Are you running the latest > > 8-stable or 9- > > This one? > http://svnweb.freebsd.org/base?view=revision&revision=219845 Yes. > I have that as I am running 219926 > > > current. There is also a new utility called usbdump, which can be used to > > figure out what is going on. > > I am running 9-current (in production for my sins..) > > usbdump is useful but consumes too much CPU at my data rate :( You probably need an USB analyzer to figure out the real problem. Have you tried to start usbdump only once the problem happens? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB driver locking
On 25/05/2011, at 9:33, Hans Petter Selasky wrote: > On Tuesday 24 May 2011 23:48:30 Daniel O'Connor wrote: >> I find that my application has rare problems where it does not get a reply >> from the micro to a control bus packet, or perhaps the micro doesn't >> receive it (I need to add a sequence number or similar to my protocol to >> try and detect it I think). > > There was a data toggle issue fixed with the EHCI recently, which triggers > depending on hardware timing. Are you running the latest 8-stable or 9- This one? http://svnweb.freebsd.org/base?view=revision&revision=219845 I have that as I am running 219926 > current. There is also a new utility called usbdump, which can be used to > figure out what is going on. I am running 9-current (in production for my sins..) usbdump is useful but consumes too much CPU at my data rate :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB driver locking
On Tuesday 24 May 2011 23:48:30 Daniel O'Connor wrote: > I find that my application has rare problems where it does not get a reply > from the micro to a control bus packet, or perhaps the micro doesn't > receive it (I need to add a sequence number or similar to my protocol to > try and detect it I think). There was a data toggle issue fixed with the EHCI recently, which triggers depending on hardware timing. Are you running the latest 8-stable or 9- current. There is also a new utility called usbdump, which can be used to figure out what is going on. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
