headers
Brad Jackson | 1 Oct 2008 03:05

Re: USB resume from suspend to disk in 2.6.27


Alan Stern wrote:
> Does this mean that the last line to appear on the screen was the 
> "failed to restore interface 0" line?  If not, what was the last line?
>   
The "failed to restore interface 0 altsetting 0" message is the only 
line that ever shows up on the console when resuming from disk hangs 
with an unpatched kernel.  There could be unseen messages printed before 
the console is cleared.
> Here are a couple of questions:
>
> First, can you tell (by watching the screen during the preliminary 
> boot when you resume from hibernation) whether the UHCI driver starts 
> running before the saved image is read back from the disk?  If 
> necessary we could add a patch to put in a delay so you'd be able to 
> see it on the screen with no trouble.
>   
I get what looks like normal kernel boot messages scrolling by too fast 
too read before the resume progress percentage counts up.  I haven't 
noticed any messages after the image is fully read, but it could be too 
quick to be seen.

> Second, what happens when you do this:
>
> 	echo suspend >/sys/bus/usb/devices/5-2/power/level
> 	echo on >/sys/bus/usb/devices/5-2/power/level
>
> That is, what shows up in the debugging log?
>   
Output from unpatched kernel when pasting each echo command separately:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ajay Kumar Gupta | 1 Oct 2008 09:38
Picon
Favicon

[PATCH] MUSB: Fix for kernel panic with multiple bulk transfer

Fixes kernel panic when multiple copy is performed among more than two mass
storage media and transfer is aborted.musb_advance_schedule(),
musb_urb_dequeue(),musb_cleanup_urb() and musb_h_disable() functions have
been modified to correct urb handling associated with bulk and control
endpoints which are multiplexed on one hardware endpoint.

musb_advance_schedule() has been removed from musb_cleanup_urb() and added
to musb_urb_dequeue(). musb_h_disable() has been modified to take care of
multiple qh on same hw_ep scenario.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta <at> ti.com>
CC: Romit Dasgupta <romit <at> ti.com> 
---
Suggestions welcome to move while loop doing kfree(qh) from 
musb_advance_schedule() and musb_h_disable() to musb_giveback().

 drivers/usb/musb/musb_host.c |  105 ++++++++++++++++++++++++++++++-----------
 1 files changed, 77 insertions(+), 28 deletions(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 8b4be01..c2474de 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
 <at>  <at>  -427,8 +427,17  <at>  <at>  musb_advance_schedule(struct musb *musb, struct urb *urb,
 		qh = musb_giveback(qh, urb, 0);
 	else
 		qh = musb_giveback(qh, urb, urb->status);
+	while (qh && qh->is_ready && list_empty(&qh->hep->urb_list)) {
+		struct list_head *head;
+		head = qh->ring.prev;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juergen Beisert | 1 Oct 2008 09:51
Picon
Favicon
Gravatar

What can be wrong with the EHCI driver

Hello list,

we run a VT6212 based PCI card in MPC5200B CPU based card (= PowerPC = Big 
Endian).

$ lspci -tv
-[0000:00]-+-18.0  VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
           +-18.1  VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
           +-18.2  VIA Technologies, Inc. USB 2.0

Attached is a USB-to-SATA device (USB-2.0). The UHCI driver isn't loaded yet.

When we start the EHCI driver we _always_ get:

$ modprobe ehci_hcd

ehci_hcd 0000:00:18.2: EHCI Host Controller
ehci_hcd 0000:00:18.2: new USB bus registered, assigned bus number 2
ehci_hcd 0000:00:18.2: irq 66, io mem 0xa0040000
ehci_hcd 0000:00:18.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 4 ports detected
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: EHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.26.5-rt9-ptx-trunk ehci_hcd
usb usb2: SerialNumber: 0000:00:18.2
usb 2-1: new high speed USB device using ehci_hcd and address 2
usb 2-1: device descriptor read/64, error -110
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jon K Hellan | 1 Oct 2008 09:32
Picon
Favicon

Option / AnyData new modem, same ID

A user emailed me asking for help with his AnyData modem. It turned out that 
the problem wasn't driver related, and that the right driver was loaded. It was 
a new model name for an existing product ID.

Turns out that AnyData ADU-310C uses the same product ID as ADU-E100A/D/C/H. Do 
we add a comment about this to the kernel? Like shown below:

Jon K Hellan, Trondheim, Norway

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 73f8277..712551b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
 <at>  <at>  -318,7 +318,7  <at>  <at>  static struct usb_device_id option_ids[] = {
         { USB_DEVICE(DELL_VENDOR_ID, 0x8136) }, /* Dell Wireless HSDPA 5520 == 
Novatel Expedite EU860D */
         { USB_DEVICE(DELL_VENDOR_ID, 0x8137) }, /* Dell Wireless HSDPA 5520 */
         { USB_DEVICE(DELL_VENDOR_ID, 0x8138) }, /* Dell Wireless 5520 Voda I 
Mobile Broadband (3G HSDPA) Minicard */
-       { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_E100A) },
+       { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_E100A) }, /* 
ADU-E100, ADU-310 */
         { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) },
         { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_620UW) },
         { USB_DEVICE(AXESSTEL_VENDOR_ID, AXESSTEL_PRODUCT_MV110H) },
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 3 comments |
headers
h.sattler | 1 Oct 2008 11:14

Antwort: Re: Antwort: Re: Antwort: Re: Antwort: RE: ehci-ixp4xx in linux-2.6.26.5

Alan Stern <stern@...> schrieb am 30.09.2008 18:01:02:

> On Tue, 30 Sep 2008 h.sattler@... wrote:
> 
> > No. Intel added two additional fields (N_TT[24..27] and N_PTT[20..23]) 
for 
> > the embedded TT that is described like that:
> > 9.15.1 Embedded Transaction Translator Function
> > The OTG controller supports directly connected full and low speed 
devices 
> > without
> > requiring a companion controller by including the capabilities of a 
USB 
> > 2.0 high speed
> > hub transaction translator. Although there is no separate Transaction 
> > Translator block in
> > the system, the transaction translator function normally associated 
with a 
> > high speed
> > hub has been implemented within the DMA and Protocol engine blocks. 
The 
> > embedded
> > transaction translator function is an extension to EHCI interface, but 

> > makes use of the
> > standard data structures and operational models that exist in the EHCI 

> > specification to
> > support full and low speed devices.
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruno.SELVA | 1 Oct 2008 13:54

What is the best hardware in order to work on Linux UWB and WLP ?

Hello guys,

I'm very new on this mailing list and would like to have some advise on the
hardware to choose for WLP UWB and where to buy it? In term of compatibility
with Linux UWB and performances.
Thanks by advance 

Bruno Selva

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Denis Joseph Barrow | 1 Oct 2008 14:16
Favicon

A few design questions wrt the hso driver.

Hi,
I'm currently beginning to test the modem functionality of the hso driver.

Simple question first.
There is this comment near the top of hso.c
Interface 2:	Standard modem interface - circuit switched interface, should
		not be used.

Who put this comment in & why? is it obselete?
The modem port at least works on minicom till the point
of setting up the ppp connection.

I'm not a modem guru
Also has anyone ideas on how to test the hso_serial_tiocmset
TIOCM_RTS TIOCM_DTR stuff.

My project lead Filip wants me to implement code to report
on DCD/RxCarrier DTR/TxCarrier to the kernel any ideas
where I might find an example of such stuff implemented
in the kernel & a means to test it.

Now a more involved question.
The suspend resume code in hso.c hso_get_activity &
hso_put_activity code to me looks very racy but the code seems to be working relatively reliably
because the schedule resume stuff happens at a slow pace. 
Despite the codes simplicity I do not have a good feel for whether it
is stable or not & don't feel like an authority on how to make the code better.

The more obvious possible issues I see with it the code are,
I could be wrong if I am please say so.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Bird (Sphere Systems | 1 Oct 2008 14:27
Picon
Favicon

Re: A few design questions wrt the hso driver.

Hi Denis,
	The 'should not be used' comment was in the original driver from Option. I 
think the point they were trying to make is that it's only to be used to make 
circuit switched connections, and if you want packet switched connections you 
should be using the network interface. As far as I know it actually functions 
OK in both scenarios.

Best regards,

Andrew

On Wednesday 01 October 2008 13:16, Denis Joseph Barrow wrote:
> Hi,
> I'm currently beginning to test the modem functionality of the hso driver.
>
> Simple question first.
> There is this comment near the top of hso.c
> Interface 2:	Standard modem interface - circuit switched interface, should
> 		not be used.
>
> Who put this comment in & why? is it obselete?
> The modem port at least works on minicom till the point
> of setting up the ppp connection.
>
> I'm not a modem guru
> Also has anyone ideas on how to test the hso_serial_tiocmset
> TIOCM_RTS TIOCM_DTR stuff.
>
> My project lead Filip wants me to implement code to report
> on DCD/RxCarrier DTR/TxCarrier to the kernel any ideas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paulius Zaleckas | 1 Oct 2008 14:57
Picon

Re: A few design questions wrt the hso driver.


Denis Joseph Barrow wrote:
> Hi,
> I'm currently beginning to test the modem functionality of the hso driver.
> 
> Simple question first.
> There is this comment near the top of hso.c
> Interface 2:	Standard modem interface - circuit switched interface, should
> 		not be used.

AFAIK this interface is disabled in most 'hso' devices firmware.
Although it was enabled in some devices what made them work with 'option'
driver. Thats how some IDs got there :)

> 
> Who put this comment in & why? is it obselete?
> The modem port at least works on minicom till the point
> of setting up the ppp connection.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Alan Stern | 1 Oct 2008 16:05
Picon
Favicon

Re: Antwort: Re: Antwort: Re: Antwort: Re: Antwort: RE: ehci-ixp4xx in linux-2.6.26.5

On Wed, 1 Oct 2008 h.sattler@... wrote:

> > > I'll guess I will dig through it a bit but then is comes to 
> > > usb_control_msg(), I find it hard to follow the code.
> > 
> > You shouldn't have to worry about anything outside of the ehci-hcd 
> > driver.
> 
> Well, core/hub.c lead me to the point where it failed.
> It's a very complex thing.

The failure occurred earlier, inside ehci-hcd.  By following the code 
backward, you got stuck at a point considerably after the real cause of 
the error.

> I think, I'll just give up on it for now and live with a dead USB port on 
> that board :-/.
> If you have any ideas, though, I'm going to try them out :)

All I can say is that the usbmon log appears to indicate that your 
USB-1.1 hub replied to the initial Get-Descriptor request with a STALL.  
Maybe the request was improperly formatted, maybe the hub wasn't 
working, and maybe the hub replied correctly but the IXP465 failed to 
interpret the reply.

If you can hook up a bus analyzer, it would tell you what really 
happened.

Alan Stern
(Continue reading)

Permalink | Reply | 0 comments |

Gmane