Earlier, I reported that 2.5.22 and 2.5.23 do not boot.
With Marcin's IDE-93 this is corrected, and the system boots.
Earlier, I reported an oops at shutdown. I just looked at
what causes the oops and find that the call
hcd->driver->stop()
is executed while hcd->driver->stop is NULL.
So,
> Earlier, I reported an oops at shutdown. I just looked at
> what causes the oops and find that the call
> hcd->driver->stop()
> is executed while hcd->driver->stop is NULL.
>
> ...
> USB people may worry whether hcd->driver->stop should
> have been non-NULL.
Not supposed to be possible.
> Why does the keyspan driver get a new device number? Surely it would
> be better to keep the old one which is a) numbered properly and b)
> doesn't waste a device number (yes we did try connecting > 64 keyspans
> to one PC ;-)
I suspect Greg will have more to say on this topic, but I'll point
Ok, I'm completely stumped on a problem and thought I'd see if anyone
has seen this or might have an idea why it's happening.
I (unfortunately) have to use an older kernel (2.4.2-2, i.e. Redhat
7.1) and on both UHCI drivers (uhci.o and usb-uhci.o) I'm seeing what
looks like the HCD is "losing" d
From: David Brownell <[EMAIL PROTECTED]>
> Earlier, I reported an oops at shutdown. I just looked at
> what causes the oops and find that the call
> hcd->driver->stop()
> is executed while hcd->driver->stop is NULL.
>
> ...
> USB people may worry whether hcd->
On Thu, Jun 20, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
> Ok, I'm completely stumped on a problem and thought I'd see if anyone
> has seen this or might have an idea why it's happening.
>
> I (unfortunately) have to use an older kernel (2.4.2-2, i.e. Redhat
> 7.1) and on both UHCI drivers
On Thu, 20 Jun 2002, Ian Molton wrote:
| Has /ANYONE/ managed to get /ANY/ OHCI based USB card to work?
I've used the Lucent (now Agere) quadra-bus PCI-USB card.
It has 4 USB controllers and 4 connectors. I.e., each connector
get full max theoretical 12 Mbps bandwidth.
| my Athlon machine has
On Thu, Jun 20, 2002 at 03:40:06PM +0200, Ondrej Palkovsky wrote:
>
> I have checked the hid-core.c in drivers/usb (2.4.18) and I have found
> only control_out transfers. Can somebody point me to a particular file
> that does INT OUT transfers? (I have 'grep'ed all files in drivers/usb
> and didn
On Thu, 20 Jun 2002, Johannes Erdfelt wrote:
>Well, 2.4.2 is known buggy. Why do you have to use that? Can you just
>use the driver from a more recent kernel?
Testing, support, and a binary module...so I'm stuck at 2.4.2-2. I
can't backport a newer uhci.o or usb-uhci.o since DMA, pci_pool, etc
On Thu, Jun 20, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
>
> On Thu, 20 Jun 2002, Johannes Erdfelt wrote:
>
> >Well, 2.4.2 is known buggy. Why do you have to use that? Can you just
> >use the driver from a more recent kernel?
>
> Testing, support, and a binary module...so I'm stuck at 2.4
On Thu, Jun 20, 2002 at 01:41:25PM +0100, Nick Craig-Wood wrote:
> We are currently building a pile of machines with 6 or more Keyspan
> USA-49W's attached (4 port serial cards). The actual USB connectivity
> works fine and I've sent GiB of data down the serial ports with no
> errors - very satis
On 20 Jun 02 at 20:49, [EMAIL PROTECTED] wrote:
>
> Now that you tell me that these things are set at initialization
> and never changed, the initialization must be wrong. And indeed,
> it says "__devexit_p(uhci_stop)" and this yields NULL.
Now when kernel tries to shutdown devices on poweroff,
On Thu, Jun 20, 2002 at 12:27:32PM -0700, Greg KH wrote:
> On Thu, Jun 20, 2002 at 01:41:25PM +0100, Nick Craig-Wood wrote:
> > So now the devices are numbered in a completely illogical fashion. It
> > *seems* to be consistent the numbering scheme from boot to boot but if
> > you move one thing a
On Thu, 20 Jun 2002, Johannes Erdfelt wrote:
>Ok, I think you can probably backport the necessary fixes to get it to
>work.
>
>The PCI DMA stuff is pretty easy to seperate out logically from the
>other changes.
>
>I'll have to take a look at the diff.
That'd be great! If you can point out whic
On Thu, Jun 20, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
>
> On Thu, 20 Jun 2002, Johannes Erdfelt wrote:
>
> >Ok, I think you can probably backport the necessary fixes to get it to
> >work.
> >
> >The PCI DMA stuff is pretty easy to seperate out logically from the
> >other changes.
> >
>
On Thu, Jun 20, 2002 at 04:22:37PM -0400, Dan Streetman wrote:
> That'd be great! If you can point out which changes you suspect I'll
> try them out. I'm still suspicious though, since it's happening in
> both uhci and usb-uhci...I didn't think they shared queueing code...?
Maybe it's something
On Thu, Jun 20, 2002 at 08:57:02PM +0100, Nick Craig-Wood wrote:
> On Thu, Jun 20, 2002 at 12:27:32PM -0700, Greg KH wrote:
> > On Thu, Jun 20, 2002 at 01:41:25PM +0100, Nick Craig-Wood wrote:
> > > So now the devices are numbered in a completely illogical fashion. It
> > > *seems* to be consiste
On Thu, Jun 20, 2002 at 09:40:27PM +0200, Petr Vandrovec wrote:
> On 20 Jun 02 at 20:49, [EMAIL PROTECTED] wrote:
> >
> > Now that you tell me that these things are set at initialization
> > and never changed, the initialization must be wrong. And indeed,
> > it says "__devexit_p(uhci_stop)" and
On Thu, Jun 20, 2002 at 08:49:36PM +0200, [EMAIL PROTECTED] wrote:
> Now that you tell me that these things are set at initialization
> and never changed, the initialization must be wrong. And indeed,
> it says "__devexit_p(uhci_stop)" and this yields NULL.
>
> So, my previous stopoops patch can
Reminder:
Alcatel modem attached to hub; when I attach another
device to the hub, syslog fills up with message like
usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 490 ret -110
usb_control/bulk_msg: timeout
usb-uhci.c: interrupt, status 2, frame# 1349
Summary:
Seems like a bug in u
Hi
I'm running kernel 2.4.19pre10 on an embedded x86ish (AMD ELAN) board using
a CMD USB-673B controller. I am able to connect and transfter data with
the modem, but it resets (disconnect/reconnect) the device sporadically (it
seems to be related to how heavily I'm thrashing the modem).
In s
On Fri, Jun 21, 2002 at 12:56:00AM +0200, Duncan Sands wrote:
> Reminder:
> Alcatel modem attached to hub; when I attach another
> device to the hub, syslog fills up with message like
> usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 490 ret -110
> usb_control/bulk_msg: timeout
> us
On Fri, 21 Jun 2002 08:56, Duncan Sands wrote:
> (The program was hacked out of the user mode driver for the
> Alcatel modem that was running when I connected the webcams
> that triggered the original bug report).
>
> Looks like a usbdevfs bug, right?
This is purely with a userspace driver, right?
On Fri, 21 Jun 2002 11:22, Simon Gittins wrote:
> Hi
>
> I'm running kernel 2.4.19pre10 on an embedded x86ish (AMD ELAN) board using
> a CMD USB-673B controller. I am able to connect and transfter data with
> the modem, but it resets (disconnect/reconnect) the device sporadically (it
> seems to
> > I'm running kernel 2.4.19pre10 on an embedded x86ish (AMD
> ELAN) board using
> > a CMD USB-673B controller. I am able to connect and
> transfter data with
> > the modem, but it resets (disconnect/reconnect) the device
> sporadically (it
> > seems to be related to how heavily I'm thrash
25 matches
Mail list logo
