Re: [PATCH 1/1] usb: phy-generic: add the implementation of .set_suspend
hi,
On Fri, Dec 27, 2013 at 10:11:28AM +0800, Peter Chen wrote:
> > > > > Add clock enable/disable at .set_suspend if the PHY has
> > > > > suspend requirement, it can be benefit of power saving for
> > > > > phy and the whole system (parent clock may also be disabled).
> > > > >
> > > > > Signed-off-by: Peter Chen
> > > > > ---
> > > > > drivers/usb/phy/phy-generic.c | 10 ++
> > > > > 1 files changed, 10 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/drivers/usb/phy/phy-generic.c
> > > > > b/drivers/usb/phy/phy-generic.c
> > > > > index aa6d37b..4b20a97 100644
> > > > > --- a/drivers/usb/phy/phy-generic.c
> > > > > +++ b/drivers/usb/phy/phy-generic.c
> > > > > @@ -65,6 +65,16 @@ EXPORT_SYMBOL(usb_nop_xceiv_unregister);
> > > > >
> > > > > static int nop_set_suspend(struct usb_phy *x, int suspend)
> > > > > {
> > > > > + struct usb_phy_gen_xceiv *nop = dev_get_drvdata(x->dev);
> > > > > +
> > > > > + if (IS_ERR(nop->clk))
> > > > > + return 0;
> > > > > +
> > > > > + if (suspend)
> > > > > + clk_disable_unprepare(nop->clk);
> > > > > + else
> > > > > + clk_prepare_enable(nop->clk);
> > > >
> > > > heh, this is why I don't like clk_enable_prepare().
> > > > usb_phy_set_suspend() can be called from atomic context.
> > > >
> > >
> > > Oh, then, how can we disable/enable phy's clock at runtime/system-side
> > > pm? Create another APIs like usb_phy_set_clk()?
> >
> > clk_prepare() on probe, clk_unprepare() on remove,
> > clk_enable()/disable() on set_suspend()
> >
>
> It will keep phy's clock prepare_count is always 1, assume one
> use case, the pll clk is the parent of phy clk, it will
> cause the pll clk can't be unprepared during the runtime, it
> may cause the pll can't be powered off during the runtime.
if you power off PHY's PLL, how will you ever notice a remote wakeup
event ? How will you ever wakeup at all ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/1] usb: phy-generic: add the implementation of .set_suspend
On Fri, Dec 27, 2013 at 02:39:43AM -0600, Felipe Balbi wrote:
> hi,
>
> On Fri, Dec 27, 2013 at 10:11:28AM +0800, Peter Chen wrote:
> > > > > > Add clock enable/disable at .set_suspend if the PHY has
> > > > > > suspend requirement, it can be benefit of power saving for
> > > > > > phy and the whole system (parent clock may also be disabled).
> > > > > >
> > > > > > Signed-off-by: Peter Chen
> > > > > > ---
> > > > > > drivers/usb/phy/phy-generic.c | 10 ++
> > > > > > 1 files changed, 10 insertions(+), 0 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/usb/phy/phy-generic.c
> > > > > > b/drivers/usb/phy/phy-generic.c
> > > > > > index aa6d37b..4b20a97 100644
> > > > > > --- a/drivers/usb/phy/phy-generic.c
> > > > > > +++ b/drivers/usb/phy/phy-generic.c
> > > > > > @@ -65,6 +65,16 @@ EXPORT_SYMBOL(usb_nop_xceiv_unregister);
> > > > > >
> > > > > > static int nop_set_suspend(struct usb_phy *x, int suspend)
> > > > > > {
> > > > > > + struct usb_phy_gen_xceiv *nop = dev_get_drvdata(x->dev);
> > > > > > +
> > > > > > + if (IS_ERR(nop->clk))
> > > > > > + return 0;
> > > > > > +
> > > > > > + if (suspend)
> > > > > > + clk_disable_unprepare(nop->clk);
> > > > > > + else
> > > > > > + clk_prepare_enable(nop->clk);
> > > > >
> > > > > heh, this is why I don't like clk_enable_prepare().
> > > > > usb_phy_set_suspend() can be called from atomic context.
> > > > >
> > > >
> > > > Oh, then, how can we disable/enable phy's clock at runtime/system-side
> > > > pm? Create another APIs like usb_phy_set_clk()?
> > >
> > > clk_prepare() on probe, clk_unprepare() on remove,
> > > clk_enable()/disable() on set_suspend()
> > >
> >
> > It will keep phy's clock prepare_count is always 1, assume one
> > use case, the pll clk is the parent of phy clk, it will
> > cause the pll clk can't be unprepared during the runtime, it
> > may cause the pll can't be powered off during the runtime.
>
> if you power off PHY's PLL, how will you ever notice a remote wakeup
> event ? How will you ever wakeup at all ?
Wakeup logic is covered by 32K OSC. Once the USB wakeup occurs,
the PLL can be powered on automatically.
In fact, in order to satisfy 1ms remote wakeup timing, some SoCs
can send resume signal only with 32K OSC (At system suspend mode,
the 24M OSC is off).
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUGREPORT] Linux USB 3.0
I just got another USB 3.0 bugreport, the entire system crashed. That particular customer already filed a bugreport in November 2013 that his system is in a bad state when using some USB 2.0 media devices which even have opensource drivers built into the kernel. USB 3.0 support with Linux seems to be a disaster with Linux 3.6.12. The affected board is an Intel DH87RL board. On Wed, Dec 25, 2013 at 8:18 AM, Markus Rechberger wrote: > A customer using a device with USBDEVFS is reporting following > backtrace (it seems to be a rather generic issue related to linux usb > 3.0 in general): > According to him this problem is reproducible as soon as he starts the > data transfer, is there anything known about that? > > He is using 3.12.0-031200-generic > > > Dec 24 14:22:39 homenas kernel: [ 1469.818460] xhci_hcd :0f:00.0: > ERROR Transfer event TRB DMA ptr not part of current TD > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: > ERROR Transfer event TRB DMA ptr not part of current TD > > Dec 24 14:30:39 homenas kernel: last message repeated 16 times > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: > WARN Successful completion on short TX > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: > WARN Successful completion on short TX > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: > URB transfer length is wrong, xHC issue? req. len = 46080, act. len = > 1382400 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] BUG: unable to handle > kernel NULL pointer dereference at 0004 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] IP: [] finish_td+0x13f/0x250 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] PGD 0 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] Oops: [#1] SMP > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] Modules linked in: > videodev pci_stub vboxpci(OF) vboxnetadp(OF) vboxnetflt(OF) > vboxdrv(OF) dm_crypt snd_hda_codec_ca0132 snd_hda_intel snd_hda_codec > snd_hwdep snd_pcm snd_seq_midi dm_multipath psmouse scsi_dh > snd_rawmidi serio_raw sb_edac snd_seq_midi_event edac_core snd_seq > snd_timer snd_seq_device lpc_ich snd bnep rfcomm soundcore > snd_page_alloc bluetooth mei_me mei mac_hid ppdev nfsd w83627ehf > hwmon_vid nfs_acl auth_rpcgss coretemp nfs fscache lockd lp parport > sunrpc raid10 raid456 async_pq async_xor async_memcpy > async_raid6_recov async_tx raid0 multipath linear btrfs raid6_pq xor > libcrc32c osst st raid1 tg3 mptsas firewire_ohci ptp mxm_wmi > firewire_core ahci mptscsih pps_core crc_itu_t libahci mpt2sas mptbase > wmi scsi_transport_sas raid_class [last unloaded: vmnet] > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] CPU: 0 PID: 0 Comm: > swapper/0 Tainted: GF O 3.12.0-031200-generic > #201311031935 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] Hardware name: To Be > Filled By O.E.M. To Be Filled By O.E.M./X79 Extreme9, BIOS P3.30 > 01/28/2013 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] task: 81c144a0 > ti: 81c0 task.ti: 81c0 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] RIP: 0010:[] [] > finish_td+0x13f/0x250 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] RSP: > 0018:88102fc03ca8 EFLAGS: 00010046 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] RAX: 880f865d2b10 > RBX: 880f865d2b00 RCX: 0006 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] RDX: 880f865d2b10 > RSI: 0007 RDI: 0046 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] RBP: 88102fc03d08 > R08: 000a R09: > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] R10: 06fd > R11: 06fc R12: 880fd2de > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] R13: 880fd32b1780 > R14: R15: 880fd5c5f000 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] FS: > () GS:88102fc0() > knlGS: > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] CS: 0010 DS: ES: > CR0: 80050033 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] CR2: 0004 > CR3: 01c0d000 CR4: 000407f0 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] Stack: > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] 88102fc03ce8 > 880fd0bc8000 88102fc03d00 880fd268d1a0 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] 88102fc03df4 > 00010002 880fd32b1780 880f865d2b00 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] 880fd268d1a0 > 880fd5c5f000 880fd2de 880fd2c497b0 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] Call Trace: > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] [] > process_bulk_intr_td+0x116/0x2d0 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] [] handle_tx_event+0x656/0xb50 > > Dec 24 14:30:39 homenas kernel: [ 1469.822450] [] ?
Re: [PATCH 1/1] usb: phy-generic: add the implementation of .set_suspend
Hi,
On Fri, Dec 27, 2013 at 04:11:21PM +0800, Peter Chen wrote:
> > > > > > > Add clock enable/disable at .set_suspend if the PHY has
> > > > > > > suspend requirement, it can be benefit of power saving for
> > > > > > > phy and the whole system (parent clock may also be disabled).
> > > > > > >
> > > > > > > Signed-off-by: Peter Chen
> > > > > > > ---
> > > > > > > drivers/usb/phy/phy-generic.c | 10 ++
> > > > > > > 1 files changed, 10 insertions(+), 0 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/usb/phy/phy-generic.c
> > > > > > > b/drivers/usb/phy/phy-generic.c
> > > > > > > index aa6d37b..4b20a97 100644
> > > > > > > --- a/drivers/usb/phy/phy-generic.c
> > > > > > > +++ b/drivers/usb/phy/phy-generic.c
> > > > > > > @@ -65,6 +65,16 @@ EXPORT_SYMBOL(usb_nop_xceiv_unregister);
> > > > > > >
> > > > > > > static int nop_set_suspend(struct usb_phy *x, int suspend)
> > > > > > > {
> > > > > > > + struct usb_phy_gen_xceiv *nop = dev_get_drvdata(x->dev);
> > > > > > > +
> > > > > > > + if (IS_ERR(nop->clk))
> > > > > > > + return 0;
> > > > > > > +
> > > > > > > + if (suspend)
> > > > > > > + clk_disable_unprepare(nop->clk);
> > > > > > > + else
> > > > > > > + clk_prepare_enable(nop->clk);
> > > > > >
> > > > > > heh, this is why I don't like clk_enable_prepare().
> > > > > > usb_phy_set_suspend() can be called from atomic context.
> > > > > >
> > > > >
> > > > > Oh, then, how can we disable/enable phy's clock at runtime/system-side
> > > > > pm? Create another APIs like usb_phy_set_clk()?
> > > >
> > > > clk_prepare() on probe, clk_unprepare() on remove,
> > > > clk_enable()/disable() on set_suspend()
> > > >
> > >
> > > It will keep phy's clock prepare_count is always 1, assume one
> > > use case, the pll clk is the parent of phy clk, it will
> > > cause the pll clk can't be unprepared during the runtime, it
> > > may cause the pll can't be powered off during the runtime.
> >
> > if you power off PHY's PLL, how will you ever notice a remote wakeup
> > event ? How will you ever wakeup at all ?
>
> Wakeup logic is covered by 32K OSC. Once the USB wakeup occurs,
> the PLL can be powered on automatically.
>
> In fact, in order to satisfy 1ms remote wakeup timing, some SoCs
> can send resume signal only with 32K OSC (At system suspend mode,
> the 24M OSC is off).
all right, so I see we need to extend .set_suspend() a bit.
.set_suspend() can be called from bus suspend IRQ and maybe the problem
comes from that mixed sematics of placing PHY in low power mode due to
system suspend or runtime pm, and decreasing power consumption because
USB bus has gone into bus suspend.
Looks like we need to fix that up before I can take this patch. If you
want, I can work on that for v3.15 but if you're willing to put the
work, go for it ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH net-next 4/6] r8152: add rtl_ops
From: Hayes Wang
Date: Fri, 27 Dec 2013 10:34:08 +0800
>
> +static int rtl_ops_init(struct r8152 *tp, const struct usb_device_id *id)
...
>
> + if (rtl_ops_init(tp, id)) {
> + netif_err(tp, probe, netdev, "Unknown Device");
> + return -ENODEV;
You're completely ignoring the error code returned from rtl_ops_init()
(which, as an aside, uses -EFAULT which doesn't seem all that
appropriate).
You might as well have rtl_ops_init() return a boolean.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 01/15] usb: phy: msm: Move mach dependent code to platform data
Hi, On Tue, Nov 12, 2013 at 04:51:36PM +0200, Ivan T. Ivanov wrote: > From: "Ivan T. Ivanov" > > This patch fix compilation error when driver is compiled > in multi-platform builds. > > drivers/built-in.o: In function `msm_otg_link_clk_reset': > ./drivers/usb/phy/phy-msm-usb.c:314: undefined reference to `clk_reset' > ./drivers/usb/phy/phy-msm-usb.c:318: undefined reference to `clk_reset' > > Use platform data supplied reset handlers and adjust error > messages reported when reset sequence fail. > > This is an intermediate step before adding support for reset > framework and newer targets. > > Signed-off-by: Ivan T. Ivanov > Acked-by: David Brown > Cc: Daniel Walker > Cc: Felipe Balbi > Cc: Greg Kroah-Hartman this really looks like you should be using reset framework (drivers/reset/), then your phy driver would simply reset_assert() and reset_deassert(). -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 01/15] usb: phy: msm: Move mach dependent code to platform data
On 12/27/13 10:10, Felipe Balbi wrote: > Hi, > > On Tue, Nov 12, 2013 at 04:51:36PM +0200, Ivan T. Ivanov wrote: >> From: "Ivan T. Ivanov" >> >> This patch fix compilation error when driver is compiled >> in multi-platform builds. >> >> drivers/built-in.o: In function `msm_otg_link_clk_reset': >> ./drivers/usb/phy/phy-msm-usb.c:314: undefined reference to `clk_reset' >> ./drivers/usb/phy/phy-msm-usb.c:318: undefined reference to `clk_reset' >> >> Use platform data supplied reset handlers and adjust error >> messages reported when reset sequence fail. >> >> This is an intermediate step before adding support for reset >> framework and newer targets. >> >> Signed-off-by: Ivan T. Ivanov >> Acked-by: David Brown >> Cc: Daniel Walker >> Cc: Felipe Balbi >> Cc: Greg Kroah-Hartman > this really looks like you should be using reset framework > (drivers/reset/), then your phy driver would simply reset_assert() and > reset_deassert(). > Unfortunately the reset framework is a DT only framework and there are still non-DT platforms within mach-msm. Arnd suggested we push the non-DT reset code down into the mach directory in the meantime. We're in the process of adding the reset framework to DT enabled MSM platforms, hopefully those get merged in 3.14. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 01/15] usb: phy: msm: Move mach dependent code to platform data
On Fri, Dec 27, 2013 at 10:23:10AM -0800, Stephen Boyd wrote: > On 12/27/13 10:10, Felipe Balbi wrote: > > Hi, > > > > On Tue, Nov 12, 2013 at 04:51:36PM +0200, Ivan T. Ivanov wrote: > >> From: "Ivan T. Ivanov" > >> > >> This patch fix compilation error when driver is compiled > >> in multi-platform builds. > >> > >> drivers/built-in.o: In function `msm_otg_link_clk_reset': > >> ./drivers/usb/phy/phy-msm-usb.c:314: undefined reference to `clk_reset' > >> ./drivers/usb/phy/phy-msm-usb.c:318: undefined reference to `clk_reset' > >> > >> Use platform data supplied reset handlers and adjust error > >> messages reported when reset sequence fail. > >> > >> This is an intermediate step before adding support for reset > >> framework and newer targets. > >> > >> Signed-off-by: Ivan T. Ivanov > >> Acked-by: David Brown > >> Cc: Daniel Walker > >> Cc: Felipe Balbi > >> Cc: Greg Kroah-Hartman > > this really looks like you should be using reset framework > > (drivers/reset/), then your phy driver would simply reset_assert() and > > reset_deassert(). > > > > Unfortunately the reset framework is a DT only framework and there are > still non-DT platforms within mach-msm. Arnd suggested we push the > non-DT reset code down into the mach directory in the meantime. We're in > the process of adding the reset framework to DT enabled MSM platforms, > hopefully those get merged in 3.14. And this is why the ARM port is in such a messy situation. It's always better to "push things into the mach- directory" than improving existing frameworks to cope with wild ARM SoCs. fell free to push this through your tree. It _does_ make the PHY driver slightly better and probably buildable on other arches with COMPILE_TEST. Still, I *really* want to see this switching over to reset framework on v3.16. cheers ps: for this patch only you can have my Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH net-next 3/6] r8152: change some definitions
Hayes Wang :
[...]
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index b8bc3eb..a8ea848 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
[...]
> @@ -274,6 +274,9 @@ enum rtl_register_content {
> #define RTL8152_MAX_TX 10
> #define RTL8152_MAX_RX 10
> #define INTBUFSIZE 2
> +#define CRC_SIZE 4
ETH_FCS_LEN ?
[...]
> @@ -1215,7 +1220,7 @@ static void rx_bottom(struct r8152 *tp)
>
> stats = rtl8152_get_stats(netdev);
>
> - pkt_len -= 4; /* CRC */
> + pkt_len -= CRC_SIZE; /* CRC */
> rx_data += sizeof(struct rx_desc);
Nit: you may remove the trailing "/* CRC */" in the same patch.
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 6/6] r8152: support RTL8153
Hayes Wang :
[...]
> diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
> index 4b1c0f3..3e09887 100644
> --- a/drivers/net/usb/cdc_ether.c
> +++ b/drivers/net/usb/cdc_ether.c
> @@ -486,6 +486,7 @@ static const struct driver_info wwan_info = {
> #define ZTE_VENDOR_ID0x19D2
> #define DELL_VENDOR_ID 0x413C
> #define REALTEK_VENDOR_ID0x0bda
> +#define VENDOR_ID_SAMSUNG0x04e8
SAMSUNG_VENDOR_ID would be more consistent for this file.
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUGREPORT] Linux USB 3.0
Seems like DH87RL was working with 3.2.0-55-generic-pae unfortunately we don't have such a board for testing and customer patience is limited to bisect the kernel. Does anyone have a clue what modification could have killed USB 3.0 support within those releases? It does not seem to be SG support. On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger wrote: > I just got another USB 3.0 bugreport, the entire system crashed. That > particular customer already filed a bugreport in November 2013 that > his system is in a bad state when using some USB 2.0 media devices > which even have opensource drivers built into the kernel. > > USB 3.0 support with Linux seems to be a disaster with Linux 3.6.12. > The affected board is an Intel DH87RL board. > > On Wed, Dec 25, 2013 at 8:18 AM, Markus Rechberger > wrote: >> A customer using a device with USBDEVFS is reporting following >> backtrace (it seems to be a rather generic issue related to linux usb >> 3.0 in general): >> According to him this problem is reproducible as soon as he starts the >> data transfer, is there anything known about that? >> >> He is using 3.12.0-031200-generic >> >> >> Dec 24 14:22:39 homenas kernel: [ 1469.818460] xhci_hcd :0f:00.0: >> ERROR Transfer event TRB DMA ptr not part of current TD >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >> ERROR Transfer event TRB DMA ptr not part of current TD >> >> Dec 24 14:30:39 homenas kernel: last message repeated 16 times >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >> WARN Successful completion on short TX >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >> WARN Successful completion on short TX >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >> URB transfer length is wrong, xHC issue? req. len = 46080, act. len = >> 1382400 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] BUG: unable to handle >> kernel NULL pointer dereference at 0004 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] IP: [] finish_td+0x13f/0x250 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] PGD 0 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] Oops: [#1] SMP >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] Modules linked in: >> videodev pci_stub vboxpci(OF) vboxnetadp(OF) vboxnetflt(OF) >> vboxdrv(OF) dm_crypt snd_hda_codec_ca0132 snd_hda_intel snd_hda_codec >> snd_hwdep snd_pcm snd_seq_midi dm_multipath psmouse scsi_dh >> snd_rawmidi serio_raw sb_edac snd_seq_midi_event edac_core snd_seq >> snd_timer snd_seq_device lpc_ich snd bnep rfcomm soundcore >> snd_page_alloc bluetooth mei_me mei mac_hid ppdev nfsd w83627ehf >> hwmon_vid nfs_acl auth_rpcgss coretemp nfs fscache lockd lp parport >> sunrpc raid10 raid456 async_pq async_xor async_memcpy >> async_raid6_recov async_tx raid0 multipath linear btrfs raid6_pq xor >> libcrc32c osst st raid1 tg3 mptsas firewire_ohci ptp mxm_wmi >> firewire_core ahci mptscsih pps_core crc_itu_t libahci mpt2sas mptbase >> wmi scsi_transport_sas raid_class [last unloaded: vmnet] >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] CPU: 0 PID: 0 Comm: >> swapper/0 Tainted: GF O 3.12.0-031200-generic >> #201311031935 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] Hardware name: To Be >> Filled By O.E.M. To Be Filled By O.E.M./X79 Extreme9, BIOS P3.30 >> 01/28/2013 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] task: 81c144a0 >> ti: 81c0 task.ti: 81c0 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] RIP: 0010:[] [] >> finish_td+0x13f/0x250 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] RSP: >> 0018:88102fc03ca8 EFLAGS: 00010046 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] RAX: 880f865d2b10 >> RBX: 880f865d2b00 RCX: 0006 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] RDX: 880f865d2b10 >> RSI: 0007 RDI: 0046 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] RBP: 88102fc03d08 >> R08: 000a R09: >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] R10: 06fd >> R11: 06fc R12: 880fd2de >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] R13: 880fd32b1780 >> R14: R15: 880fd5c5f000 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] FS: >> () GS:88102fc0() >> knlGS: >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] CS: 0010 DS: ES: >> CR0: 80050033 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] CR2: 0004 >> CR3: 01c0d000 CR4: 000407f0 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] Stack: >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] 88102fc03ce8 >> 880fd0bc8000 88102fc03d00 880fd268d1a0 >> >> Dec 24 14:30:39 homenas kernel: [ 1469.822450] 88102fc03df4 >> 00010002 880fd32b1780 880
[PATCH 1/1] USB: Nokia 502 is an unusual device
The USB storage operation of Nokia Asha 502 Dual SIM smartphone running Asha Platform 1.1.1 is unreliable in respect of data consistency (i.e. transfered files are corrupted). A similar issue is described here: http://discussions.nokia.com/t5/Asha-and-other-Nokia-Series-30/Nokia-301-USB-transfers-and-corrupted-files/td-p/1974170 The workaround is (MAX_SECTORS_64): rmmod usb_storage && modprobe usb_storage quirks=0421:06aa:m The patch adds the tested device to the unusual list permanently. Signed-off-by: Mikhail Zolotaryov --- drivers/usb/storage/unusual_devs.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index de32cfa..ad06255 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -234,6 +234,13 @@ UNUSUAL_DEV( 0x0421, 0x0495, 0x0370, 0x0370, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_MAX_SECTORS_64 ), +/* Patch submitted by Mikhail Zolotaryov */ +UNUSUAL_DEV( 0x0421, 0x06aa, 0x1110, 0x1110, + "Nokia", + "502", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_MAX_SECTORS_64 ), + #ifdef NO_SDDR09 UNUSUAL_DEV( 0x0436, 0x0005, 0x0100, 0x0100, "Microtech", -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUGREPORT] Linux USB 3.0
just received following log snippset: Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.177695] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.217966] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.277473] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.317753] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.377242] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.417514] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.477000] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.517279] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.576761] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.617074] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.676581] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.716852] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.776340] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:50 solist kernel: [ 36.816589] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr Dec 27 23:23:51 solist kernel: [ 36.876117] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr the previous bug report of that user: https://bugzilla.kernel.org/show_bug.cgi?id=65021 xhci: complete USB freeze On Fri, Dec 27, 2013 at 8:59 PM, Markus Rechberger wrote: > Seems like DH87RL was working with 3.2.0-55-generic-pae unfortunately > we don't have such a board for testing and customer patience is > limited to bisect the kernel. > > Does anyone have a clue what modification could have killed USB 3.0 > support within those releases? > It does not seem to be SG support. > > On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger > wrote: >> I just got another USB 3.0 bugreport, the entire system crashed. That >> particular customer already filed a bugreport in November 2013 that >> his system is in a bad state when using some USB 2.0 media devices >> which even have opensource drivers built into the kernel. >> >> USB 3.0 support with Linux seems to be a disaster with Linux 3.6.12. >> The affected board is an Intel DH87RL board. >> >> On Wed, Dec 25, 2013 at 8:18 AM, Markus Rechberger >> wrote: >>> A customer using a device with USBDEVFS is reporting following >>> backtrace (it seems to be a rather generic issue related to linux usb >>> 3.0 in general): >>> According to him this problem is reproducible as soon as he starts the >>> data transfer, is there anything known about that? >>> >>> He is using 3.12.0-031200-generic >>> >>> >>> Dec 24 14:22:39 homenas kernel: [ 1469.818460] xhci_hcd :0f:00.0: >>> ERROR Transfer event TRB DMA ptr not part of current TD >>> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >>> ERROR Transfer event TRB DMA ptr not part of current TD >>> >>> Dec 24 14:30:39 homenas kernel: last message repeated 16 times >>> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >>> WARN Successful completion on short TX >>> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >>> WARN Successful completion on short TX >>> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: >>> URB transfer length is wrong, xHC issue? req. len = 46080, act. len = >>> 1382400 >>> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] BUG: unable to handle >>> kernel NULL pointer dereference at 0004 >>> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] IP: [] finish_td+0x13f/0x250 >>> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] PGD 0 >>> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] Oops: [#1] SMP >>> >>> Dec 24 14:30:39 homenas kernel: [ 1469.822450] Modules linked in: >>> videodev pci_stub vboxpci(OF) vboxnetadp(OF) vboxnetflt(OF) >>> vboxdrv(OF) dm_crypt snd_hda_codec_ca0132 snd_hda_intel snd_hda_codec >>> snd_hwdep snd_pcm snd_seq_midi dm_multipath psmouse scsi_dh >>> snd_rawmidi serio_raw sb_edac snd_seq_midi_event edac_core snd_seq >>> snd_timer snd_seq_device lpc_ich snd bnep rfcomm soundcore >>> snd_page_alloc bluetooth mei_me mei mac_hid ppdev nfsd w83627ehf >>> hwmon_vid nfs_acl auth_rpcgss coretemp nfs fscache lockd lp parport >>> sunrpc raid10 raid456 async_pq async_xor async_memcpy >>> async_raid6_recov async_tx raid0 multipath linear btrfs raid6_pq xor >>> libcrc32c osst st raid1 tg3 mptsas firewire_ohci ptp mxm_wmi >>> firewire_core ahci mptscsih pps_core crc_itu_t libahci mpt2sas mptbase >>> wmi scsi_transport_sas raid_class [last
