headers
Yu, Fenghua | 1 Oct 2009 01:30
Picon
Favicon

RE: commit db8be50c4307dac2b37305fc59c8dc0f978d09ea causes MCA on hp rx8640


>On Wed, 2009-09-30 at 13:20 -0700, Yu, Fenghua wrote:
>> 
>> Seems pci_resource_start is not set up yet when quirk_usb_handoff_ohci
>> is called.
>
>Is it possible to fix that, so that it _is_ set up when we start calling
>the PCI_FIXUP_HEADER quirks?
>
>Or do we need to introduce yet another type of PCI quirk.... or have USB
>do something all of its own.
>
>I also hear of people wanting to kill USB off even _earlier_, to work
>around yet more BIOS brokenness.

What's base value in base = pci_ioremap_bar(pdev, 0)? Pci_resource_start should be setup in
pci_read_bases(). Could you please dump res->start in pci_read_bases()? This res->start should
happen before quirk_usb_handoff_ohci(). But somehow res->start is not setup when
quirk_usb_handoff_ohci() is called.

Thanks.

-Fenghua
--
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 | 1 comment |
headers
Andrew Patterson | 1 Oct 2009 02:01
Picon
Favicon

RE: commit db8be50c4307dac2b37305fc59c8dc0f978d09ea causes MCA on hp rx8640

On Wed, 2009-09-30 at 16:30 -0700, Yu, Fenghua wrote:
> >On Wed, 2009-09-30 at 13:20 -0700, Yu, Fenghua wrote:
> >> 
> >> Seems pci_resource_start is not set up yet when quirk_usb_handoff_ohci
> >> is called.
> >
> >Is it possible to fix that, so that it _is_ set up when we start calling
> >the PCI_FIXUP_HEADER quirks?
> >
> >Or do we need to introduce yet another type of PCI quirk.... or have USB
> >do something all of its own.
> >
> >I also hear of people wanting to kill USB off even _earlier_, to work
> >around yet more BIOS brokenness.
> 
> What's base value in base = pci_ioremap_bar(pdev, 0)?
> Pci_resource_start should be setup in pci_read_bases(). Could you
> please dump res->start in pci_read_bases()? This res->start should
> happen before quirk_usb_handoff_ohci(). But somehow res->start is not
> setup when quirk_usb_handoff_ohci() is called.

I think the problem is that the fixup routines are not being called
before the quirk.  Here is an instrumented output without the db8be50c
commit:

ACPI: PCI Root Bridge [L008] (0000:8c)
pci_bus 0000:8c: pcibios_fixup_bus:500: 
pci 0000:8c:01.0: pcibios_fixup_device_resources:481: 
pci 0000:8c:01.0: pcibios_fixup_resources:466: 
pci 0000:8d:02.0: PME# supported from D0 D1 D2 D3hot
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markus Barchfeld | 1 Oct 2009 10:53
Picon
Picon

USB to RS485 converter unreliable with old kernel

Hello,

I use a  USB to RS485 converter (ICP Con i-7561, a PL2303 device,
details below) to access one RS-485 device via Modbus RTU. I have
written a test application using libmodbus which
 - connects to /dev/ttyUSB0 (modbus_connect)
 - sets termios
 - reads an input register from the RS-485 device and
 - disconnects from /dev/ttyUSB0 (modbus_close).

The app runs fine with Ubuntu 9.04, kernel 2.6.28 on my PC. However, I
want to run the application on a MIPS device (Fritz!Box) which uses
kernel 2.6.13. And there I get a problem if I try to run the
application repeatedly. The first run is fine, but any subseqent run
fails. Data can be send to the RS485 device but then there is no
response. After I reconnect the device physically another run succeeds
- and every subsequent run fails again. Running the pl2303 in debug
mode I do not see any error messages, the output of the first and
second run are mostly equal. Except for the missing
read_bulk_callbacks in the second run. See below.

Actually I do not know if the converter does not send any data anymore
or if the kernel discards the data. On the MIPS device I also ran
usbmon, but there was no output. Now I am trying to get output from
usbmon on my PC with Ubuntu/2.6.15. What other debugging tools could
be helpful in this context?

If the converted does not send data anymore it might have been
mis-configured, maybe by setting termios connect/disconnect from
/dev/ttyUSB0. Otherwise there could be an issue with the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Oliver Neukum | 1 Oct 2009 14:54

[patch]fix trivial accounting bug in visor driver

Signed-off-by: Oliver Neukum <oliver@...>

commit 37a863f6f83f21389eb7f01b201272c0239bd98b
Author: Oliver Neukum <oliver@...>
Date:   Thu Oct 1 14:52:17 2009 +0200

    usb:usbserial:visor: fix accounting in error case

    data not pushed to the tty layer due to an error mustn't be counted

diff --git a/drivers/usb/serial/visor.c b/drivers/usb/serial/visor.c
index 1aa5d20..8e2d6dd 100644
--- a/drivers/usb/serial/visor.c
+++ b/drivers/usb/serial/visor.c
 <at>  <at>  -513,7 +513,8  <at>  <at>  static void visor_read_bulk_callback(struct urb *urb)
 			tty_kref_put(tty);
 		}
 		spin_lock(&priv->lock);
-		priv->bytes_in += available_room;
+		if (tty)
+			priv->bytes_in += available_room;

 	} else {
 		spin_lock(&priv->lock);

--
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 | 0 comments |
headers
Oliver Neukum | 1 Oct 2009 15:01

[patch]small fix in error case of suspend in generic usbserial code

Signed-off-by: Oliver Neukum <oliver@...>

commit d9c1828b9c5c4b35da7e9c2982b7c0f98da9cf1c
Author: Oliver Neukum <oliver@...>
Date:   Thu Oct 1 14:58:25 2009 +0200

    usb:usbserial: fix flags in error case of suspension

    suspended flag must be reset in error case

diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index aa6b2ae..2761948 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
 <at>  <at>  -1164,8 +1164,10  <at>  <at>  int usb_serial_suspend(struct usb_interface *intf, pm_message_t message)

 	if (serial->type->suspend) {
 		r = serial->type->suspend(serial, message);
-		if (r < 0)
+		if (r < 0) {
+			serial->suspending = 0;
 			goto err_out;
+		}
 	}

 	for (i = 0; i < serial->num_ports; ++i) {

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oliver Neukum | 1 Oct 2009 15:08

Re: "Safely remove hardware" for USB

Am Mittwoch, 30. September 2009 00:07:25 schrieb Alan Stern:
> > I have no problem with exporting this feature at all. It is necessary for
> > what you want to do and what you want to do is useful.
> > My problem is with the API to user space. I suggest that you add this
> > to the storage driver not generic USB code and all is well.
>
> Do you mean _both_ storage drivers (usb-storage and ub)?  What about
> future storage drivers (UASP)?  You can see why I preferred to add it
> in the core...

That's a factor. usbfs would still be better.

> > You could even make an API that makes the storage driver unregister
> > the SCSI host but retain its binding to the device until it tells usbcore
> > to disable the port. That closes the race with probe().
>
> There is no need to worry about races with probe, as far as usb-storage
> is concerned.  Probe and unbind are already sufficiently mutually
> exclusive.  I don't know about ub.

You race between "safe unplug" and another probe.

Races in between unmounting and unbinding the driver can be fixed
in user space. But  after unbinding and before "safe unplug" the device
can be probed again. That you cannot avoid in user space because
it can be triggered by attaching another device which triggers a driver
being loaded which cannot be avoided.

Putting the API into usbfs fixes this, as usbfs has a concept of claiming
a device.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oliver Neukum | 1 Oct 2009 15:56

Re: [PATCH] USB: serial: Fix read regression in 2.6.31

Am Dienstag, 29. September 2009 19:06:03 schrieb Alan Stern:
> On Tue, 29 Sep 2009, Oliver Neukum wrote:
> > Am Montag, 28. September 2009 20:28:22 schrieb Alan Stern:
> > > It's hard to tell.  Using flush_scheduled_work() safely is really
> > > difficult; avoiding it entirely is much easier.
> >
> > Do you propose including a work queue usbserial itself doesn't use
> > into the generic structure for the benefit of subdrivers?
>
> At this point I'm not recommending any particular solutions.  Mainly
> I'm recommending that we carefully think things through before acting
> impulsively.  :-)

Very well.
I've now looked at tty code and my head spins.

> > > I would prefer to see a scheme that was well considered and planned out
> > > in advance, something that would work properly for all the USB serial
> > > drivers, even if it meant updating a bunch of them.
> > >
> > > The issue appears to boil down to this:
> > >
> > > 	When shutting down the hardware, _all_ the URBs have to be
> > > 	unlinked and no new ones may be submitted.  This means the
> > > 	lower-level serial driver must not communicate with the
> > > 	device, even though the serial core might call subroutines
> > > 	which wish to do so.
> >
> > But that would be a deficiency in the usbserial layer by letting those
> > through, wouldn't it?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alan Cox | 1 Oct 2009 16:34
Picon

Re: [PATCH] USB: serial: Fix read regression in 2.6.31

> > 	What about calls arriving while the shutdown is in progress?
> > 	Some drivers might be able to handle them and other drivers
> > 	might not.
> 
> Do they need to handle them?

Up to a point yes. Simply because the tty layer close helpers call back
into the driver in order to

- flush any pending data
- handle any line discipline shutdown
- fix up the carrier state

> > 	What about calls that were already in progress before the
> > 	shutdown started?  To synchronize with them would require
> > 	taking the mutex on each call or maybe using some form of
> > 	RCU.  Can we afford to do this?  Or should we declare that

You can't. The lock on the tty port lookup and reference in the receive
path is marginal enough with high speed 3G modems, which is why I had
moving the queues to the tty_port in the todo list.

Plus the calls are all blocking anyway and some of them have a lifetime
over the hardware activity lifetime (see hangup behaviour for an example)

> > 	the TTY core is responsible for these things?
> 
> I am very much in favor of dropping that to the tty layer.

The tty core was slowly learning these things but you can't just break
(Continue reading)

Permalink | Reply | 4 comments |
headers
Oliver Neukum | 1 Oct 2009 16:42

Re: [PATCH] USB: serial: Fix read regression in 2.6.31

Am Donnerstag, 1. Oktober 2009 16:34:36 schrieb Alan Cox:
> > > 	What about calls arriving while the shutdown is in progress?
> > > 	Some drivers might be able to handle them and other drivers
> > > 	might not.
> >
> > Do they need to handle them?
>
> Up to a point yes. Simply because the tty layer close helpers call back
> into the driver in order to
>
> - flush any pending data
> - handle any line discipline shutdown
> - fix up the carrier state

OK, I see. Can we get away at least with ignoring throttle/unthrottle
if a shutdown has already begun?

[..]
> Anyway tty has no maintainer so if you want to move it to tty, you get to
> maintain the tty layer and fix all the other drivers to work with your
> interface changes.

So we are on our own.

	Regards
		Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg KH | 1 Oct 2009 16:35
Picon

Re: [PATCH] USB: serial: Fix read regression in 2.6.31

On Thu, Oct 01, 2009 at 03:34:36PM +0100, Alan Cox wrote:
> Anyway tty has no maintainer so if you want to move it to tty, you get to
> maintain the tty layer and fix all the other drivers to work with your
> interface changes.

Hm, the MAINTAINERS file seems to point to someone as the tty maintainer
right now...

I'm not able to do a ton of work on it at the moment due to .31.y
messes, but I am collecting tty patches and will have time in a few
weeks to do more development to hopefully resolve a number of these
issues.

thanks,

greg k-h
--
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 |

Gmane