63
> ln -s /dev/input/mice /dev/mouse
> The mouse moved randomly on the screen and a little movement moves the cusror very
> far.
> What could i set to obtain a correct behavoir ?
For X, you need the mouse protocol "imps/2" in XF86config.
--
Georg Ac
eduled URBs (i.e. with the new URB, there would be more than
1024 frames "running")
- Not enough URBs running (eg. only 2). At the completion of the first URB,
it's absolutely too late to submit the second one...
--
Georg Acher, [EMAIL PROTECT
us and read data back to A oder the
socket. If it was a IN-interrupt or a IN-isochronous transfer, the data
block mutates to a stream. Closing the connection means "unlink urb". Even a
user space tool can do this (is ISO supported by usbfs?). It's just a matter
of t
.5.25, I've chosen the
> "alternate" UHCI driver, uhci-hcd.o. I'll delete the other HCD drivers
> in the drivers/usb/host directory that are now no longer in the build,
> and send that to Linus in a few days.
>
> I'd like to publicly thank Georg Acher, Deti
I have it, and I will use it as long as my Win98 partition survives ;-)
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
---
This sf.
that
anyone had a performance penalty with these limits...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
---
This sf.net e
ot touching the mouse usually (not always)
> prevents any problems from happening. As soon as you start moving it
> again it happens again. Then sometimes, after the light goes out, it
> never comes on again.
Ouch... Have you tried a self-powered hub (ie. a hub with it's
em. Usually 99% of all
problems in USB show the same symptoms: Device doesn't work...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
-
lp). I've seen similar
messages now and then, but usually the device died.
One more question (can't remember if it's mentioned in the first mail): Is
the keyboard directly connected to the PC or are there any USB-hubs (also
onboard) inbetween?
--
Georg Acher, [EMAIL PROTEC
ared queueing code...?
Maybe it's something with the data toggles. Sometimes I have the feeling
that the core and freshly plugged in devices have a different opinion how
the flag should be. OUT transfers are not affected, but UHCI seems to ignore
the data if the toggle is set wrong.
--
ied it with an OHCI board? Was there a version, where the device
worked?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
useful value. Does this happen only with usb-uhci or also with uhci?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
_
b-uhci doesn't affect the normal codepaths, so without the
#define it is safe. I can't say for certain that there are no evil side effects when
enabled, but it looks not bad...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh
produce the
ENXIO just with hid.o loaded.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
Sponsored by:
o defibrillate the defibrillater ;-)
Via or Intel? And, yes, the defibrillator is still in the animal experiment
phase and not yet ideal.
BTW: You have received a big disconnect, at least that is true :-)
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
f the oops also happens for you with that version, can you give
us more information about the loaded drivers and the connected USB-devices?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
since their
invention (surely a lack in completeness), but that should be well known. So
please don't kill the messenger ;-)
When usb-uhci survives the evaluation, I will add the control queuing, but
for now I don't want to introduce a new complex
explanation.
A quick inspection showed no obvious problems in your code...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
initial charge current will also be shorter. As ceramic caps have also a
lower impedance for high frequency, this is good for EMI, too...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh
the scanner again responds only after a complete
> >unload of the uhci driver.
>
> That would appear to be a bug somewhere in usb-uhci ... what about
> the updated/smaller "-hcd" versions?
Well, a dead HCD smells like VIA ;-) But I don't understand why a correctly
signalled
an internal USB hub?
And: What happens when you are inserting the laptop in the docking station
again? Do the messages stop?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not agai
On Mon, May 27, 2002 at 03:45:51PM +0200, Eduard Hasenleithner wrote:
> Georg Acher wrote:
>
> Replying a bit late, but better than never.
>
> On Fri, May 10, 2002 at 11:43:51PM +0200, Eduard Hasenleithner wrote:
>
> > > May 10 22:57:52 editower kernel: usb.c: U
URB every 2-4
frames (1ms) should be doable without any queueing.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
.
The interval-value for isochronous transfers is also now supported.
Additionally the patch removes a few typos, obsolete comments+code and
a few non-portable variable declarations.
The patch is against 2.5.17+the urb->next-removal-patch, please apply.
--
Georg Acher, [EMAIL PROTEC
egister contains a value that looks like a part of an ASCII string
("PE=i", does it have a meaning for you?). But it should contain a valid bus
pointer. I can't imagine how the port reset should cause this and why only
on Via and why now and not already in 2.4.1... Very strange...
ng support for that in *uhci*. If I don't have HID loaded, the
binding works.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
o something like this. The important output of the for-loop
is the variable nint, it's a log2(n).
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
__
ry it on 2.4*, I can send you the patch.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
Don't miss the 2002 Sprint PCS Applic
checked it. The ENXIO (and the "input.c: hotplug returns -2"-message)
occurs with the old usb-uhci and also with uhci-hcd. I just had the bad luck
of verbosely documenting the problem.
I'll never do any verbose sanity checks again, I only get troubles with
them ;-)
--
ates
for an USB controller are enough, let the driver writers do the rest...".
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
__
ssage, not the
detection. Thus the HID driver has more than one control URB outstanding...
I will look into that...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
__
e job, this works very well on my machine (I'm typing using it.)
And what happens with usb-uhci-hcd? Or is this the long awaited decision?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh
n't force CONFIG_USB_DEBUG on if it's already
> set, but it's just a simple tweak to get rid of that warning.
That's a leftover from my debugging sessions...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not a
tions (fewer interrupts, better diagnostics)
- Support for module "tune"-parameters for breadth/depth search, debug etc.
- interval support for ISO
- More SMP-tests
- maybe changes for reference counting when it is clear what survives :-)
The gzip'ed patch is against 2.5.15 and
ot;190N01417V102". The chip has 44 pins and was
> covered by a Quality Control sticker. Removing that
> showed the text "Carry U02SE 0101E" on the chip.
With 44pins it can be a AN2135, a low cost version of the popular EZ-USB. If
the 12MHz-quarz connects to pins 8&am
ice? Or
> does that also happen elsewhere (i.e. on disconnect)?
I don't fell well with removing the unlink_urbs(). It may be superfluous in
most cases, but I like double security...
--
Georg Acher, [EMAIL PROT
On Fri, May 10, 2002 at 11:43:51PM +0200, Eduard Hasenleithner wrote:
> On a sidenote: It works when using the "usb.patch" from
> Georg Acher <[EMAIL PROTECTED]>. I still get a first unsuccessful
> id assignment but it works the second time:
> May 10 22:57:52 edi
t touch the timing for working devices, it
should be pretty safe...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
diff -u linux/drivers/usb/usb.c linux.afs/drivers/usb/usb.c
--- linux/drivers/
rupt [usb-uhci] 0xdc
> [] handle_IRQ_event [kernel] 0x3a
> [] do_IRQ [kernel] 0x68
> [] call_do_IRQ [kernel] 0x5
Hm, what is hotplug usually doing at that time?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !&q
ested 4096bytes, but I don't know why...
So at least I have something to look for...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
t to try next?
If there's a BIOS that's worth mentioning, have you tried to play a bit with
the PCI settings (posted write, buffering, latency, etc)?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !&quo
> Any idea what could causing this or similar experiences?
Hm, maybe some endianess problems (but AFAIK, usb-uhci has been tested on
PPC), but that wouldn't explain why exactly this area gets corrupted. Do
USB-hubs/keyboard/mice work in your system?
--
Georg Acher, [EMAIL PROTECTED
transfer_buffer_length contains the length for the extra data (may be 0).
So your code sends the setupdata twice, but why that should give -ENOMEM is
not very clear...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not
th the right urb->status.
There should be absolutely no case in which submit_urb returns with !=0 and a
completions to that URB comes later on.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"
never ending call trace in the end.
I have never seen such problems in any other application using dabusb and
usb-uhci or usb-ohci.
These symptoms smell like memory corruption, but a memory test showed no
problems...
Any ideas?
--
Georg Acher, [EMAIL PROTECTED]
ht
e kernel into
account. GET* writes data into userspace, so _IOW, SET* vice versa.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL
es.
I love that... And they don't dare to tell that the maintainer of usb-uhci?
> I have a Brother HL-1450 Postscript printer and an HP Scanjet 6300C
> attached, FWIW.
Can you find out which one is responsible for the hang? During the hang,
does the system respond to CapsLoc
.c ... ??
The same function (process_iso), of course you have to issue URBs for the
continous reception of isochronous transfers.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
_
Does this help any?
Well, it says, that the just finished isn't restarted early enough, so a gap
occurs. You should think about either larger transfer buffers (i.e. transfer
more frames with one URB) or more than two URBs.
--
Georg Acher, [EMAIL PROTECTED]
http://www
psets produce errors (corrupted packets) every few hours.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL PROTECTED]
;2.4.10.
And, yes - OHCI is much smarter in transferring data. Queuing URBs is really
a pain for UHCI...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
__
ehind it. Due to the dumbness of the UHCI-chip
this event may need correction of the data toggles all the queued
descriptors for this pipe. Guessing from the log info above, this seems to
be not the root cause for the problem...
--
Georg Acher, [EMA
difference (my diff was against 2.4.17...)
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL PROTECTED]
To unsubscribe, use the l
delay in start_hc()
It should apply cleanly to 2.4.17 and also (maybe with a offset) to 2.5.2.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
diff -u linux/drivers/usb/usb-uhci.c
hci about an interrupt error. Is this just a result of the time
> difference between the physical unplug and the unlink of the interrupt
> urb?
Yes, the unlink is called after the hub driver has recognized the hub state
change. That can take a while...
--
Georg Acher
And usb.h is not the only one using that style...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL PROTECTED]
To unsubscribe, use
o more sophisticated locking,
usage counting etc. in the future.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL PROTECTED]
To unsubs
und in our CVS at http://usb.cs.tum.edu/
> Question 3. SniffUSB starts the logfile with the output below, am I correct
> in assuming that this is the same as...
>
> usb_set_configuration (usbdev, usbdev->config[0].bConfigurationValue)
> and
> usb_set_interface (s->
On Mon, Dec 03, 2001 at 11:37:12PM +0100, Martin Diehl wrote:
> Gotcha!
Fine ;-)
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
_
way does it fail?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://
rovides a
more-or-less standard stream, the so called RDI (radio data interface). It
is also still not pure data, but it is at least documented.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
sends data, the TD gets filled and completed. If no data arrives
(either an active NAK or a timeout), the transfer is retried.
So everything is started with the submit_urb, the interrupts only signal the
completion or the failing of the transfer.
--
Georg Acher, [EMAIL PROTECTED]
ave problems: Only use kmalloc'ed memory, static or
stack memory may fail.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL PR
edx: 0082
> esi: c01d6000 edi: c01d6000 ebp: c01d7d64 esp: c01d7d1c
> >>EIP; c011051d<=
> Trace; c88314f1 <[usb-uhci]uhci_submit_urb+21d/34c>
eax/ecx look suspiciously like a referenced NULL-pointer, maybe urb->dev?
--
Georg Acher,
uired, but (AFAICT) is not being applied in either
> driver.
Yes, it is definitely. Otherwise the HC would be immediately dead when using
reclamation. The workaround (QH and TD) is in usb-uhci in init_skel (qh at
chain_end).
--
Georg Acher, [EMAIL PROTECTED]
http:/
IMHO the endpoint state of the device-structure should
reflect this), but it doesn't survive in the end...
I will fix it..
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
On Sat, Oct 13, 2001 at 12:55:41AM +0200, Martin Diehl wrote:
<...>
> - IIRC there was an issue with VIA handling of BABBLE. Probably usb-uhci
> has some fix to work around this.
No, the issue still exists (at least for isochronous, never tried it with
bulk/control).
--
probe() routine.
Do you have a detailed ksymoops-output or the failed reference?
Since reset is a common action and, I think it's more likely a
"garbage-in/crash" scenario...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
&q
On Mon, Oct 01, 2001 at 02:03:59PM -0700, Greg KH wrote:
> On Mon, Oct 01, 2001 at 10:48:59PM +0200, Georg Acher wrote:
> >
> > For usb-uhci/uhci all of the changes (as far I can see) touch the
> > uhci-common.h, which appeared and vanished again in 2.4.10-pre*. So I wou
ain, it should go in ASAP...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
--- linux/drivers/usb/usb-uhci.c.orgThu Sep 27 12:12:39 2001
+++ linux/drivers/usb/usb-uhci.c
ction kernel should only occur in the first kernels of a -pre-series,
not in the last one.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
__
r the planet.
Fix attached. Please apply it.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
--- linux/drivers/usb/usb-uhci.c.orgThu Sep 27 12:12:39 2001
+++ linux/drivers/usb/usb
a rather nasty hang, but one
> user managed to get me a good trace, which I?m printing below:
<...>
Hm, I'm using isochronous transfers in 2.4.10 and have not found such
problems... neither I'm aware of important patches to the isochronous
code...
Thanks for the hint, I'
one aware of this device ?
I have two early engineering samples (ROK101007/2), they need the attached
patch to usb.c to be recognised. But I can't tell about the Bluetooth
funcionality itself...
BTW: Are there any objections to include the patch into the kernel?
--
Georg
od question...
PS: If this bug is lurking around for over 6 months when IRDA is used, why
I'm heearing it now for the first time?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
_
ming-behavior'-devices?
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL PROTECTED]
To unsubscribe, use the last form f
troduce
Why? An ISO URB is in progress or done when its completion is called.
Interrupts are the only exception.
> the "URB on loan to driver" state. (I wonder how the UHCIs deal
> with that?)
usb-uhci: If it's an interrupt, try to kill it regardless of the stat
as to care about complicated protocols. Since Deti also wrote the
Programming Guide, he referred to that driver.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
On Thu, Jun 14, 2001 at 11:48:02PM +0200, Wolfgang Mües wrote:
> So if I see "300" as a value for timeout as an argument of
> usb_control_msg() [as in dabusb.c and dsbr100.c],
> this will mean different times on different platforms... ummpf!
Ooops, I will change that...
read it all. The Anchor chips for example have an optional
double buffering mode for bulk endpoints, allowing back-to-back transfers
with zero delay.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no,
option "bandwidth checking", there's no check
if that can appear, and the transfers will fail.
Remember, USB is a shared medium, and even two USB-ports on a mainboard
usually are connected to one USB controller with 12Mit/s total for all
ports. Only newer VIA chipsets have two UHCI con
uence for Windows:
20ms USB-Reset
Get device descriptor (64bytes)
15ms USB-Reset
Set address
Get device descriptor
...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
_
that...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.source
er to
> recieve the response? Or does it get placed in a structure that
> I should declared when I sent the control message? Tracing this through
> puts me at a dead end: the wake_up point simply seems to return the funtion.
I hope that helps a bit
--
Georg Acher, [EMAI
On Fri, Jun 08, 2001 at 05:52:20AM -0700, David Brownell wrote:
> Oopses normally dump me into KDB, and that's not happening.
> So I don't think there's an oops involved.
What CPU/chipset do you have? Have you tried some BIOS/PCI options (latency,
posted write etc...).
--
. Usually they are taken for setting up the device
in the beginning or only "user"-driven IO. If you want it in interrupts, you
have to implement the functionality on your own. IMHO mixing synchronous and
asynchronous behavior is possible, when the usage can be clearly divided,
otherwise I tend
in the beginning, the whole frame is "lost" for that
device, if no FSBR is used. With FSBR, the device is tried again and again,
until it new accepts data.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh n
d traffic is
> the way to get any "fairness" required.
It is no problem to switch back to depth first, but then it is suboptimal
again for a device that NAKs very often...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !
we switched to depth mode, which
needs the reclamation loop to get high bandwidth for one transfer.
> About delay-TD idea: would it be possible to make low-speed transmit
> to nonexisting device? That should delay it just well :-).
Ouch ;-)
--
Georg Acher, [EMAIL PROTECTED]
and unlink, there's IMHO no deadlock possibility.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL PROTECTED]
To unsubscribe, use t
uhci also on IA64 (yep, there's one (literally) creeping around
here), and it worked very well. But I don't know whether it had David's fix
in it...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of pet
rained locking,
> e.g. everything is under urb lock, but sometimes picks list
> lock (N.B.: opposite lock order). Since his driver is the
> future, I do not think it makes any sense to retrofit his
> scheme into usb-uhci.
Your opinion. Have you checked that there are no races with unlin
rect heuristic for that? Decreasing the
reclamation duration leads to problems with some devices (as a posting
recently showed...). No reclamation provides miserable USB bandwidth and
depth first sequence has no fair scheduling.
--
Georg Acher, [EMAIL PROTECTED]
ht
bulk transfers are affected, low speed control has no loopback. The
loop is switched on, when at least one URB is in progress, that has
USB_NO_FSBR not set. It is switched off after ~50ms (if no new URBs are
submitted).
--
Georg Acher, [EMAIL PROTECTED]
http://www.in
On Sun, Jun 03, 2001 at 09:00:24AM -0700, David Brownell wrote:
> > From: "Georg Acher" <[EMAIL PROTECTED]>
> > On Sat, Jun 02, 2001 at 01:22:00PM +0200, Pavel Machek wrote:
> > >
> > > With Acher's uhci, even ifconfig up of usb-to-usb networkin
r; see -ac series].
> does 50% slowdown. When fsbr is being used, systems slows down by 350%
Hm, the 50% make me curious... have to look what's happening...
> (running more than 4 times slower than normally. Ouch).
Blame Intel. Either low latency or low PCI usage, you can choos
And
always a halted hostcontroller? This looks like a problem in the submitted
URB (wrong memory or such). I don't think that it is HCD-related...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !
and isochronous
transfers....
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
___
[EMAIL PROTECTED]
To unsubscribe, use th
ss streaming easier. Opnions may differ... That it also applies to
bulk is an accident by generalisation (why doing it only for ISO
transfers...).
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
__
r process, to don't touch it
anymore if it was a single (not-resubmitted) urb.
unlink_urb:
LOCK_IRQSAVE(urb_list_lock)
LOCK(urb->lock)
...
UNLOCK(urb->lock)
UNLOCK_IRQRESTORE(urb_list_lock)
--
Georg Acher, [EMAIL PROTECTED]
1 - 100 of 128 matches
Mail list logo
