For your kind attention,
First, I must solicit your confidence in
this transaction, this is by virtue of it's nature as
being utterly confidential and top secret .We are top
officials from the Federal Ministry of Works and
Housing,(FMWH),Federal Ministry of Finance
and the Presidency, making up
On Wed, 7 Jan 2004, Alan Stern wrote:
> I looked at that. It's not dmesg; it's syslog output -- and all the
> debugging information is missing. Probably your syslog configuration is
I had the kernel messages going to a different file... That file is now
available at the URL I previously sent
On Wed, 7 Jan 2004 [EMAIL PROTECTED] wrote:
> On Tue, 6 Jan 2004, Greg KH wrote:
>
> > Can you enable CONFIG_USB_STORAGE_DEBUG and send the debug log to the
> > linux-usb-devel mailing list for when this happens? The people there
> > should be able to help you out.
> >
>
> Ok, I enabled that a
NEW!
More than 84.000 entries on our page:
All about:
Pokemon, YU-GI-OH, DragonballZ, BeyBlade, Ranma 1/2, and and and
Games, Video's, Pic's, Cards, MP3s, Screen-saver, and and and
and many many more!
And NO DIALERS!
have fun
Alan Stern wrote:
On Mon, 5 Jan 2004, David Brownell wrote:
A hub doesn't have any state that it needs to preserve across a reset, or
at least none that can't be reconstructed after the reset. Since the
reset will automatically disconnect all downstream devices, we not only
don't want to save th
Seems to me there should really be two usb_disconnect() calls,
both of which feed disconect events to khubd. One of the calls
would come internally, from hub status transfer processing.
It's currently using the same API as the other entry point...
The other entry point would be for the HCD layer,
As soon as you mark the device as USB_STATE_NOTATTACHED, there
will be no more retries ... completions happen at whatever rate
protocol timeouts kick in, but from then on there's no way to
start new I/O. Like a car running out of gas, with no hills.
Ah, but devices aren't marked as USB_STATE_NO
Oliver Neukum wrote:
This would permit an attractive concurrency in handling unplug events.
Concurrency is not attractive, unless performance is an issue.
It is just a source of problems.
Well, the real world is concurrent, so the problems are there
regardless of whether the software is geared
On Tue, 6 Jan 2004, Greg KH wrote:
> Can you enable CONFIG_USB_STORAGE_DEBUG and send the debug log to the
> linux-usb-devel mailing list for when this happens? The people there
> should be able to help you out.
>
Ok, I enabled that and the SCSI option. Here's what I get:
Jan 7 09:04:10 axp
On Wed, 7 Jan 2004, Stavros Markou wrote:
> Hi,
>
> Thanks for your quick and accurate answer. It worked !!!
> Are you gonna include this change to the upcoming 2.6.1 kernel ?
I am going to include it, along with other changes to
__usb_reset_device(), but I don't know if it will be ready in time
Hi,
Thanks for your quick and accurate answer. It worked !!!
Are you gonna include this change to the upcoming 2.6.1 kernel ?
Stavros Markou.
Alan Stern wrote:
On Wed, 7 Jan 2004, Stavros Markou wrote:
Hi,
I wonder how can I find out the port number my device was plugged in
during probing
On Wed, 7 Jan 2004, Oliver Neukum wrote:
> > The hooks themselves are trivial; it's what the device drivers will do
> > with them that's hard! The driver has to know what to do about incoming
> > requests while the device is unavailable, it has to be prepared to find
> > that the device ends u
On Wed, 7 Jan 2004, Stavros Markou wrote:
> Hi,
>
> I wonder how can I find out the port number my device was plugged in
> during probing function of driver. I use a ported form kernel
> __usb_reset function and I see that there is a check for all
> parent->maxchild which in my case fails to f
Am Dienstag, 6. Januar 2004 16:59 schrieben Sie:
> Oliver, I like your messages. You always make me stop and think again. :-)
>
> When starting this thread, I had in mind some fairly small changes that
> would easily go into the 2.6 kernel series. But the kind of thing you and
> David are sugg
Hi,
I wonder how can I find out the port number my device was plugged in
during probing function of driver. I use a ported form kernel
__usb_reset function and I see that there is a check for all
parent->maxchild which in my case fails to find a match between my usb
device and parent->children
15 matches
Mail list logo
