On Saturday 03 April 2004 21:13, Gene Heskett wrote:
>Greetings;
>
>You'll find a sysrq -t capture attached. xsane is hung in the
> opening device scan, leaving that little window, and its totally
> unkillable by any means but a reboot, which brings up the you're
> running as root warning as it re
On Fri, 2 Apr 2004, Grzegorz Kulewski wrote:
> On Wed, 31 Mar 2004, Marc-Christian Petersen wrote:
>
> > On Sunday 28 March 2004 00:51, Alan Stern wrote:
> >
> > Hi Grzegorz,
> >
> > > > When running modem_run on 2.6.4-WOLK2.3 it locks in D state on one of USB
> > > > ioctls. It works at least
Hi
I've just tried 2.6.5 to check if the oops on removal of Bluetooth
dongle is still here. Unfortunately it is:
PREEMPT
CPU: 0
EIP: 0060:[] Not tainted
EFLAGS: 00010002 (2.6.5)
EIP is at urb_unlink+0x30/0xa0 [usbcore]
eax: ce7dabdc ebx: ecx: edx: cb768000
esi: 0246 edi: ce7
> A single program has the /dev/usb/tts/0 (yes, I am using devfs for this
> system just now 8-) device open and is blocked waiting in poll() with the
> relevant events member set to POLLIN.
>
> Whenever the phone is turned off or the USB cable is pulled from main
> computer port, the opps occurs
The original message was received at Sun, 4 Apr 2004 10:19:25 -0400
from e4.esmtp.ibm.com [9.14.6.104]
- The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
(reason: 550 5.1.1 <[EMAIL PROTECTED]>... User 'kipisz' is not a registered
gateway user)
- Tran
On Sat, 2004-04-03 at 20:40, Alan Stern wrote:
> Without having looked recently in any detail at the specific code in sd.c
> or sr.c, I want to comment in general terms on the nature of the
> open/disconnect race.
>
> It's a generic problem that affects every driver whose devices can be
> opened t
Bernd Porr wrote:
Dave,
we are just developing a follow up of the USB DUX board. That one will
(try to) take full advantage of the new ISO code in 2.6. I would like to
transfer every microframe and every microframe should carry 3 packets of
512 bytes. This is approx 6Mbytes/sec. Thus, I would l
On 4 Apr 2004, James Bottomley wrote:
> OK, your "problem" definition is that "there's a race", which I agree
> with, I just don't agree that it's a problem.
>
> Disconnections are fundamentally asynchronous events (a device may be
> disconnected by the user at any stage regardless of what any ke
On Sun, 2004-04-04 at 12:46, Alan Stern wrote:
> Ah, you have left out the third, bad alternative: open succeeds, user gets
> an fd that points to a deallocated device. More details below...
No, that would be a bug. I'm looking for evidence that such a bug exists
in sd.
> Let's consider a simpl
James Bottomley wrote:
Let me illustrate: the user may disconnect the device then open it. If
they open it before even the USB subsystem gets notified of the
disconnection then all the elaborate synchronisation in the world isn't
going to be able to prevent that (the device was gone when they open
On Sun, 2004-04-04 at 14:16, David Brownell wrote:
> You're assuming that synchronization is there to establish a single
> global notion of state. Clearly that's impossible; also undesirable.
Thank you.
> The synchronization is actually there to let the "device gone" state
> spread cleanly throu
We've talked about this before on the mailing lists... we've never come
up with a good solution.
It seems to me that the problem screams for a semaphore. The question is
just which semaphore.
That, and coming up with reasonable semantics to impose on every driver.
Let's see what usage fits well wit
On 4 Apr 2004, James Bottomley wrote:
> On Sun, 2004-04-04 at 12:46, Alan Stern wrote:
> > Ah, you have left out the third, bad alternative: open succeeds, user gets
> > an fd that points to a deallocated device. More details below...
>
> No, that would be a bug.
Of course it would! That's ex
James Bottomley wrote:
So you dispute this assertion in the email you quoted above:
Since we cannot solve that
race, there's no reason to try to solve the "some parts of the kernel
know but others don't" part of the race.
On what basis? This, I think, is the core of the differences between
On t
There is no oops if the device is not opened (or at least there isn't one
"every time like clockwork" 8-).
Using the usbserial.c from linux-2.4.25 in my 2.4.22 tree (yes, arbitrary
experiment, but safe enough given the diff, and my overall problem goes back
to an embedded box that I can't just rev
On Fri, Apr 02, 2004 at 06:36:55PM -0500, James Bottomley wrote:
> = drivers/scsi/sr.c 1.103 vs edited =
> --- 1.103/drivers/scsi/sr.c Fri Apr 2 11:30:44 2004
> +++ edited/drivers/scsi/sr.c Fri Apr 2 17:29:06 2004
> @@ -424,8 +424,19 @@
>
> static int sr_block_release(struct inode
This is "reasonably well tested" on the x86 platform.
This patch fixes a problem where the usbserial code would not notify
connected programs that the serial port was going away.
--- linux-2.4.25-orig/drivers/usb/serial/usbserial.c 2003-11-28
10:26:20.0 -0800
+++ linux-2.4.25/drivers/us
On Sun, 4 Apr 2004 21:46:52 -0700
"Robert White" <[EMAIL PROTECTED]> wrote:
> This is "reasonably well tested" on the x86 platform.
>
> This patch fixes a problem where the usbserial code would not notify
> connected programs that the serial port was going away.
> @@ -1404,9 +1408,11 @@ static v
A Virus was detected in the mail sent by you.
The message has been rejected.
--- Scan information follows ---
Result: Virus Detected
Virus Name: [EMAIL PROTECTED]
File Attachment: data.zip
Attachment Status: deleted
--- Original message information follows ---
From: [EMAIL PROTECTED]
To: [EMAI
Pasting the whole program is impractical, so here is the psudocode
Open /dev/usb/ttyUSB0
Build Poll structure with events = POLLIN for this descriptor
Call poll(&structure,1,-1)
(Without the patch) If you pull the usb cable out of the computer, the program above
will never return from the poll.
20 matches
Mail list logo
