Am Dienstag, 21. Januar 2003 02:19 schrieb David Brownell:
> Oliver Neukum wrote:
> > When will we go to code freeze?
>
> No such thing as "code freeze", not like commercial UNIX
> where it means a year before customers could see fixes.
> (If they're willing to pay through the nose for patches.)
M
Holger Schurig wrote:
Hi !
:)
I saw that in hcd.c there is the following code:
// NOTE: 2.5 does this if !URB_NO_DMA_MAP transfer flag
if (usb_pipecontrol (urb->pipe))
urb->setup_dma = pci_map_single ( ...
... etc. Right; but the SL811 driver doesn't use t
> If you want to update that driver, I'd encourage you to do so
> on 2.5.latest since when you do, you can also use "usbtest"
> (and "testusb") to put the driver through its paces in a way
> that just was never possible on 2.4 based systems. Given that,
> a backport will be pretty straightforward.
> Do you suggest I update hc_sl811.c from usb-2.5 to usb-2.5? Would't this
> require that I backport lot's of other stuff, e.g. all in drivers/usb/core?
I meant:
Do you suggest I update hc_sl811.c that is in usb-2.4 to the one that is in
usb-2.5? Would't this require that I backport lot's of o
Oliver Neukum wrote:
>
>
I simply don't trust the SCSI layer. I've had to much trouble with it
already.
Hopefully we have some better building blocks and
clearer code in 2.5 to look at this problem in the SCSI
subsystem again.
The first thing a LLDD should do when it _knows_ the device
is gone
[EMAIL PROTECTED] said:
> Providing you refcount objects and defer freeing of resources its not
> normally too terrible
We already have a struct device, which is a ref counted object precisely for
this purpose, embedded inside Scsi_Device.
One of the issues doing this is fast reattachment: the
Am Dienstag, 21. Januar 2003 12:57 schrieb Douglas Gilbert:
> Oliver Neukum wrote:
> >
> >
> > I simply don't trust the SCSI layer. I've had to much trouble with it
> > already.
>
> Hopefully we have some better building blocks and
> clearer code in 2.5 to look at this problem in the SCSI
> subsy
Holger Schurig wrote:
If you want to update that driver, I'd encourage you to do so
on 2.5.latest since when you do, you can also use "usbtest"
(and "testusb") to put the driver through its paces in a way
that just was never possible on 2.4 based systems. Given that,
a backport will be pretty str
Oliver et al.:
In response to one of your previous messages, I tried reducing the scope
of the changes required for properly tracking urb states and synchronous
unlinking. It turns out that in addition to the extra spinlock, I needed
2 bits: one to indicate when the urb is in use (owned by the co
Oliver Neukum wrote:
Disconnect is not really a callback. There's a distinct lack of a back movement here.
khubd -> usbcore -> disconnect() in driver -> [layer on top]
The proposed API in SCSI looks like:
-> LLD -> midlayer -> top layer -> midlayer -> LLD with destroy_slave()
and that's not OK.
Oliver Neukum wrote:
>
So a disconnection would look like this:
1.
scsi_set_offline_host(...);
2.
synchronize_kernel();
3.
error_queied_commands(...);
4.
scsi_remove_host();
Not quite. You want to do 3 before 2, to get 2 going as soon
as possible. Futhermore, 3 is partly in LLDD. 1 w
Am Dienstag, 21. Januar 2003 19:16 schrieb Luben Tuikov:
> Oliver Neukum wrote:
> > Disconnect is not really a callback. There's a distinct lack of a back
> > movement here. khubd -> usbcore -> disconnect() in driver -> [layer on
> > top]
> >
> > The proposed API in SCSI looks like:
> > -> LLD ->
Oliver Neukum wrote:
Am Dienstag, 21. Januar 2003 19:16 schrieb Luben Tuikov:
When the Low Level Device Driver (LLDD), being the transport portal,
notices that the device is going away or has gone away from the
``fabric'' (wlg), it will fire a device-gone event with the kernel.
*Not* necessaril
On Mon, 20 Jan 2003, David Brownell wrote:
> Oliver Neukum wrote:
>
> > So here's the list of things related to the core I remember so we can look
> > at the issues and see which need attention before 2.6.0
> >
> > - reseting during probe will deadlock
> > - reseting through usbfs will not repro
Am Dienstag, 21. Januar 2003 20:47 schrieb Alan Stern:
> Oliver et al.:
>
> In response to one of your previous messages, I tried reducing the scope
> of the changes required for properly tracking urb states and synchronous
> unlinking. It turns out that in addition to the extra spinlock, I needed
On Tue, 21 Jan 2003, Oliver Neukum wrote:
> > But the only alternative
> > is to add a whole extra field (like internal_state).
>
> I believe that you should do that.
I agree.
> It would be great if we could eleminate the need for handling unlinking
> during completion at all. Is there a reason
Hello, Oliver and Alan,
On Tuesday 21 January 2003 21:41, Oliver Neukum wrote:
> It would be great if we could eleminate the need for handling unlinking
> during completion at all. Is there a reason you cannot make them mutually
> exclusive? IMHO it should be possible to do that if you make it a
> > It would be great if we could eleminate the need for handling unlinking
> > during completion at all. Is there a reason you cannot make them mutually
> > exclusive? IMHO it should be possible to do that if you make it a
> > requirement to call giveback with handler_lock held.
>
> Sure, that co
Am Dienstag, 21. Januar 2003 23:10 schrieb Wolfgang Mües:
> Hello, Oliver and Alan,
>
> On Tuesday 21 January 2003 21:41, Oliver Neukum wrote:
> > It would be great if we could eleminate the need for handling unlinking
> > during completion at all. Is there a reason you cannot make them mutually
>
Oliver Neukum wrote:
If automatic resubmission is gone in 2.5.x, why should I code an
usb_unlink_urb() from the completion handler? Do I miss something?
We are talking about unlinking while a completion handler is running,
but not from within the completion handler.
Which does happen to be th
Am Dienstag, 21. Januar 2003 23:47 schrieb David Brownell:
> Oliver Neukum wrote:
> >>If automatic resubmission is gone in 2.5.x, why should I code an
> >>usb_unlink_urb() from the completion handler? Do I miss something?
> >
> > We are talking about unlinking while a completion handler is running,
When copying large amounts of data to a drive:
Logs show:
usb-storage: Command WRITE_10 (10 bytes)
usb-storage: 2a 00 00 05 eb f0 00 00 40 00 2d 80
usb-storage: Bulk command S 0x43425355 T 0x174a Trg 0 LUN 0 L 32768 F 0
CL 10
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_tran
Here's another question to add to your discussion.
When a device is unplugged, the system's representation of that device
can't be removed immediately; there may be open fd's, mounts, pointers,
and so on. Until the time comes when all these handles are released, all
interaction with the device ha
Hi,
this is the first version of the updated and improved patch.
It fails for me in an utterly bizarre way. It breaks some shared
libraries. Could somebody replicate that, or is it time to run
memtest86?
Regards
Oliver
You can import this changeset into BK by piping this
Am Dienstag, 21. Januar 2003 21:19 schrieb Alan Stern:
> On Mon, 20 Jan 2003, David Brownell wrote:
> > Oliver Neukum wrote:
> > > So here's the list of things related to the core I remember so we can
> > > look at the issues and see which need attention before 2.6.0
> > >
> > > - reseting during p
Attached file:
Hi
I'm once again writing a usb driver.
For a simple FIFO device this time. (FTDI)
Yes I know there is already a driver but thats a serial driver and not
fast enough. (Me need fullspeed)
Ok so I've got the stuff setup. usb probe and release and fops.
here is the data structures:
/// file ope
27 matches
Mail list logo
