Re: [Omapandroid-discussion] smsc95xx: download ok, upload hangs

[Zach Pfeffer]

On 29 June 2012 10:55, Émeric Vigier <emeric...@savoirfairelinux.com> wrote:
> Hi,
>
> I am not 100% sure but it seems my smsc95xx is unable to wake up the CPU while it is in WFI.
> I have verified that my OMAP4430 constantly enters WFI. Note that sleep states are disabled.
> USB mouse and keyboard events wake it up properly. eth0 RX seems to wake it up, but eth0 TX does not...
> What could be possibly wrong in my config then? usbnet.c only creates softirq to submit URB. No HW irq.
>
> How can I make smsc95xx trigger an interrupt (ehci_hcd:usb1) while transferring data?
> Do you know?

I don't know. Including linaro-android and pandaboard.

> Emeric
>
> ----- Mail original -----
>> De: "Émeric Vigier" <emeric...@savoirfairelinux.com>
>> À: "Zach Pfeffer" <zach.p...@linaro.org>
>> Cc: "Vikram Pandita" <vikram....@ti.com>, omapandroid...@gforge.ti.com
>> Envoyé: Jeudi 28 Juin 2012 16:04:31
>> Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload hangs
>>
>> I tried 4AI.1.4-P1 kernel this morning. The panda_defconfig did not
>> compiled out of the box:
>> arch/arm/mach-omap2/temp_sensor_device.c:38: undefined reference to
>> `omap_temp_sensor_idle'
>> I disabled CONFIG_OMAP_TEMP_SENSOR and CONFIG_OMAP4_DIE_TEMP_SENSOR.
>> It seems that there are not supported on omap4430 anyway...
>> But kernel panics short after init, with my Android images. And I am
>> not really into investigating this panic.
>>
>> Compiling my current kernel with gcc-4.6 (provided by google android)
>> did not change the behavior.
>>
>> I made more tests though. My test setup is now as follows:
>> On the pandaboard I run:
>> # nc -l -p 1032 < /dev/zero &
>> On my host computer (connected to the same network), I run:
>> # nc 192.168.50.107 1032 > /dev/null
>> I can see with nethogs that TX is stalled as I got "nc [...] 0KB/sec"
>>
>> I tried to change mtu, from 1500 to 512, no real improvement.
>>
>> here is a list of my usb devices:
>>
>> # cat /d/usb/devices
>>
>> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
>> B: Alloc= 0/800 us ( 0%), #Int= 3, #Iso= 0
>> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>> P: Vendor=1d6b ProdID=0002 Rev= 3.00
>> S: Manufacturer=Linux 3.0.8-g2562c68-dirty ehci_hcd
>> S: Product=OMAP-EHCI Host Controller
>> S: SerialNumber=ehci-omap.0
>> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
>> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
>> E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
>>
>> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 5
>> D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
>> P: Vendor=0424 ProdID=9514 Rev= 1.00
>> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 2mA
>> I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub
>> E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
>> I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub
>> E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
>>
>> T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
>> D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
>> P: Vendor=0424 ProdID=ec00 Rev= 1.00
>> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 2mA
>> I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff
>> Driver=smsc95xx
>> E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>> E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
>> E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
>>
>> T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=1.5 MxCh= 0
>> D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
>> P: Vendor=04b3 ProdID=3025 Rev= 1.02
>> S: Manufacturer=CHICONY
>> S: Product=USB NetVista Full Width Keyboard
>> C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
>> I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
>> E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
>>
>> T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=03 Dev#= 6 Spd=12 MxCh= 0
>> D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
>> P: Vendor=066b ProdID=400b Rev= 1.01
>> S: Manufacturer=LINKSYS Inc
>> S: Product=LINKSYS USB Adapter
>> S: SerialNumber=9b1fa5
>> C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=156mA
>> I:* If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=pegasus
>> E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
>> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
>> E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=1ms
>>
>> We can see the smsc9514 chipset which is causing me so much pain.
>> Also I compiled the pegasus driver to support an external Linksys
>> device. This device ethernet behaves just fine as eth1. I noticed
>> that MxPS (MaxPacketSizes) and Cls (Class) are different on the two
>> ethernet devices. But I don't think this is the cause of my problem.
>>
>> When I stress the cpu:
>> # stress -c 1
>> TX is resumed and speed increases to ~20KBps.
>> This is strange, because I remember having tested with "stress -c 2"
>> before, without seeing any improvement. My setup is probably
>> different now...
>>
>> Something must be wrong with the wakeonlan capability of the chipset.
>> I checked register 0x20, smsc95xx.h defines:
>>
>> #define PM_CTRL (0x20)
>> #define PM_CTL_DEV_RDY_ (0x00000080)
>> #define PM_CTL_SUS_MODE_ (0x00000060)
>> #define PM_CTL_SUS_MODE_0 (0x00000000)
>> #define PM_CTL_SUS_MODE_1 (0x00000020)
>> #define PM_CTL_SUS_MODE_2 (0x00000060)
>> #define PM_CTL_PHY_RST_ (0x00000010)
>> #define PM_CTL_WOL_EN_ (0x00000008)
>> #define PM_CTL_ED_EN_ (0x00000004)
>> #define PM_CTL_WUPS_ (0x00000003)
>> #define PM_CTL_WUPS_NO_ (0x00000000)
>> #define PM_CTL_WUPS_ED_ (0x00000001)
>> #define PM_CTL_WUPS_WOL_ (0x00000002)
>> #define PM_CTL_WUPS_MULTI_ (0x00000003)
>>
>> # while(true); do ethtool -d eth0 | grep 020: ; sleep 1; done
>> 020: 81 00 00 00 00 00 11 01 1f 00 00 1f a0 30 f8 00
>> 020: 81 00 00 00 00 00 11 01 1f 00 00 1f a0 30 f8 00
>> 020: 81 00 00 00 02 00 11 01 1f 00 00 1f a0 30 f8 00
>> 020: 81 00 00 00 00 00 11 01 1f 00 00 1f a0 30 f8 00
>> 020: 81 00 00 00 00 00 11 01 1f 00 00 1f a0 30 f8 00
>>
>> The only register changing is 0x24 which is LED_GPIO_CFG, which
>> confirms that my register is correct.
>> If I decode correctly, register 0x20 has PM_CTL_WUPS_ED_ and
>> PM_CTL_WOL_EN_ set.
>> Still lacking register description though...
>>
>> ethtool returns nothing regarding wakeonlan for eth0:
>>
>> # ethtool eth0
>> Settings for eth0:
>> Supported ports: [ TP MII ]
>> Supported link modes: 10baseT/Half 10baseT/Full
>> 100baseT/Half 100baseT/Full
>> Supports auto-negotiation: Yes
>> Advertised link modes: 10baseT/Half 10baseT/Full
>> 100baseT/Half 100baseT/Full
>> Advertised auto-negotiation: Yes
>> Speed: 100Mb/s
>> Duplex: Full
>> Port: MII
>> PHYAD: 1
>> Transceiver: internal
>> Auto-negotiation: on
>> Current message level: 0x00000007 (7)
>> Link detected: yes
>>
>> Same ethtool result returned with linaro-11.09, whose ethernet works
>> like a charm.
>>
>> I checked again this linaro-11.09. ifconfig eth0 returns an MTU of
>> 1488 Bytes, where my faulty android build makes eth0 return 1500
>> Bytes. I believe this 1500 comes from the fact that I apply "9bbf566
>> [PATCH] net: usb: smsc95xx: fix mtu" to my current kernel.
>> Changing linaro build's mtu to 1500 does not impact its good
>> performance.
>> Decreasing the mtu to 512 on my current (and faulty) build does not
>> improve the bad performance :-(.
>>
>> I am starting to go mad.
>>
>> Regards,
>> Emeric
>>
>> ----- Mail original -----
>> > De: "Émeric Vigier" <emeric...@savoirfairelinux.com>
>> > À: "Zach Pfeffer" <zach.p...@linaro.org>
>> > Cc: "Vikram Pandita" <vikram....@ti.com>,
>> > omapandroid...@gforge.ti.com
>> > Envoyé: Mercredi 27 Juin 2012 10:06:10
>> > Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload
>> > hangs
>> >
>> > Hi Zach,
>> >
>> > Following Ti's advice
>> > (http://e2e.ti.com/support/omap/f/849/p/196732/704452.aspx#704452),
>> > I will try
>> > http://omapedia.org/wiki/4AI.1.4-P1_OMAP4_Icecream_Sandwich_Release_Notes
>> > today.
>> >
>> > Also I just found out that my current 3.0.8 kernel is compiled with
>> > gcc-4.4.3. I am currently trying with gcc-4.6 but I don't feel
>> > confident about that.
>> > I will try the one you mentioned right after.
>> >
>> > Thanks,
>> > Emeric
>> >
>> > ----- Mail original -----
>> > > De: "Zach Pfeffer" <zach.p...@linaro.org>
>> > > À: "Émeric Vigier" <emeric...@savoirfairelinux.com>
>> > > Cc: "Vikram Pandita" <vikram....@ti.com>,
>> > > omapandroid...@gforge.ti.com
>> > > Envoyé: Jeudi 21 Juin 2012 17:34:15
>> > > Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload
>> > > hangs
>> > >
>> > > You may want to checkout our omapzoom focused tree:
>> > >
>> > > https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc47-omapzoom-stable-blob/
>> > >
>> > > On 21 June 2012 15:20, Émeric Vigier
>> > > <emeric...@savoirfairelinux.com> wrote:
>> > > > Hi Vikram,
>> > > >
>> > > > I made this diff and came up with few patches in smsc95xx.c and
>> > > > usbnet.c (listed below). I applied them to my kernel, but issue
>> > > > occurred again.
>> > > >
>> > > > Because linaro-12.05 uses a 3.4 kernel, and mine is only 3.0.8,
>> > > > I
>> > > > narrowed down the oldest linaro having ethernet working fine.
>> > > > It came up to be linaro-11.09 for panda, which uses 3.1 kernel.
>> > > > diff between my kernel and theirs is null for smsc95xx.c and
>> > > > usbnet.c.
>> > > >
>> > > > Then something must be wrong with my config. I will make the
>> > > > diff
>> > > > of my config and theirs. I have to figure out what's the config
>> > > > file linaro uses for 11.09.
>> > > > My config file is for Android-4.0.4, quite long (and probably
>> > > > faulty):
>> > > > http://pastebin.com/2VXemSae
>> > > >
>> > > > Emeric
>> > > >
>> > > > ----- Mail original -----
>> > > >> De: "Vikram Pandita" <vikram....@ti.com>
>> > > >> À: "Émeric Vigier" <emeric...@savoirfairelinux.com>
>> > > >> Cc: omapandroid...@gforge.ti.com
>> > > >> Envoyé: Jeudi 21 Juin 2012 14:03:07
>> > > >> Objet: Re: [Omapandroid-discussion] smsc95xx: download ok,
>> > > >> upload
>> > > >> hangs
>> > > >>
>> > > >> > test linaro-12.05 ICS release and see ethernet behavior -
>> > > >> > PASSED
>> > > >>
>> > > >> What version kernel does this use if its working?
>> > > >> Would be worth a try to take a diff of the smsc driver files
>> > > >> between
>> > > >> AOSP and this.
>> > > >> At least says its not a hw issue.
>> > > >>
>> > > >>
>> > > >> On Thu, Jun 21, 2012 at 8:30 AM, Émeric Vigier
>> > > >> <emeric...@savoirfairelinux.com> wrote:
>> > > >> >
>> > > >> > Hi,
>> > > >> >
>> > > >> > I am experiencing ethernet issue with a pandaboard A3
>> > > >> > (OMAP4430
>> > > >> > rev
>> > > >> > 2.2) featuring smsc LAN9514-JZX usbnet chipset.
>> > > >> > My panda runs android-4.0.4 with linux kernel 3.0.8
>> > > >> > (android-omap-panda-3.0 branch on
>> > > >> > https://android.googlesource.com/kernel/omap.git).
>> > > >> >
>> > > >> > Receiving ethernet frames work fine, but transmitting them
>> > > >> > does
>> > > >> > not. The driver/chip seems stuck.
>> > > >> > Moving the USB mouse (or USB keyboard key pressed) unlocks
>> > > >> > this
>> > > >> > behavior and transmission gets resumed for a second or two.
>> > > >> > Then
>> > > >> > ethernet transmission gets stuck again.
>> > > >> >
>> > > >> > Recently, I cherry-picked dozen of usbnet and smsc95xx
>> > > >> > patches,
>> > > >> > and
>> > > >> > managed to get a watchdog barking (see test 21 below).
>> > > >> >
>> > > >> > Unfortunately I have no JTAG probe, so I am limited to
>> > > >> > driver
>> > > >> > tweaks and tryouts...
>> > > >> > Here are the tests I have performed so far, along with a
>> > > >> > todo
>> > > >> > list:
>> > > >> >
>> > > >> > FAILED means that the issue came up.
>> > > >> > PASSED means that the issue has not come up.
>> > > >> > DONE, NOT DONE, ONGOING are more related to a todo list than
>> > > >> > a
>> > > >> > test
>> > > >> > report.
>> > > >> >
>> > > >> > 1. check with constant cpu load (stress -c 2) - FAILED
>> > > >> > 2. check if problem occurs on older releases (non ICS) - NOT
>> > > >> > DONE
>> > > >> > 3. try CONFIG_PL310_ERRATA_769419 patch in cpuidle - FAILED
>> > > >> > 4. check without USB hub connected - FAILED
>> > > >> > 5. check with usbcore.autosuspend=600 added to cmdline -
>> > > >> > FAILED
>> > > >> > 6. patch ehci-omap.c to verify clock frequency - NOT DONE
>> > > >> > 7. check with CPU1 offlined - FAILED
>> > > >> > 8. check ethtool on android - FAILED
>> > > >> > Cannot get register dump: Operation not supported on
>> > > >> > transport
>> > > >> > endpoint
>> > > >> > 9. check without USB_EHCI_TT_NEWSCHED - FAILED
>> > > >> >
>> > > >> > 10. try to unbind, rebind smsc95xx - FAILED
>> > > >> > 11. disable turbo_mode and reset the chip - FAILED
>> > > >> > 12. test with "CONFIG_NO_HZ is not set" - FAILED
>> > > >> > 13. test with another external USB ethernet dongle - NOT
>> > > >> > DONE
>> > > >> > 14. test linaro-12.05 ICS release and see ethernet behavior
>> > > >> > -
>> > > >> > PASSED
>> > > >> > Ethernet runs fine on release:
>> > > >> > . 12.05 tracking - PASSED
>> > > >> > . 11.10 tracking - PASSED
>> > > >> > . 11.09 release - PASSED
>> > > >> > 15. try with "netcfg eth0 dhcp" - FAILED
>> > > >> > 16. check datasheet - ONGOING
>> > > >> > registers description is missing on 9514.pdf, only eeprom is
>> > > >> > described
>> > > >> > 17. adapt driver to ethtool - DONE
>> > > >> > 18. dump registers and check against linaro 11.09 - ONGOING
>> > > >> > 19. ethtool returns heaps of "0", the pattern I added to the
>> > > >> > array
>> > > >> > is all replaced by "0"...
>> > > >> > Actually the eeprom is blank. I found it out since each time
>> > > >> > I
>> > > >> > unbind/bind the device to smsc95xx driver, I get a random
>> > > >> > MAC
>> > > >> > address...
>> > > >> >
>> > > >> > 20. test with 11.09 linaro kernel - NOT DONE
>> > > >> > zygote not starting
>> > > >> > 21. uploading 24MB file on the web (http://dl.free.fr) -
>> > > >> > FAILED
>> > > >> > This occurred only with these patches added to my kernel:
>> > > >> > From 8a78335 [PATCH] usbnet: consider device busy at each
>> > > >> > recieved
>> > > >> > packet
>> > > >> > From 5d5440a [PATCH] usbnet: don't clear urb->dev in
>> > > >> > tx_complete
>> > > >> > From 4231d47 [PATCH] net/usbnet: avoid recursive locking in
>> > > >> > usbnet_stop()
>> > > >> > From 1aa9bc5 [PATCH] usbnet: use netif_tx_wake_queue
>> > > >> > instead
>> > > >> > of
>> > > >> > netif_start_queue
>> > > >> > From 7bdd402 [PATCH] net/usbnet: reserve headroom on rx
>> > > >> > skbs
>> > > >> > From 0956a8c [PATCH] usbnet: increase URB reference count
>> > > >> > before
>> > > >> > usb_unlink_urb
>> > > >> > From 9bbf566 [PATCH] net: usb: smsc95xx: fix mtu
>> > > >> > From 720f3d7 [PATCH] usbnet: fix leak of transfer buffer of
>> > > >> > dev->interrupt
>> > > >> > From a472384 [PATCH] usbnet: fix failure handling in
>> > > >> > usbnet_probe
>> > > >> > From 5b6e9bc [PATCH] usbnet: fix skb traversing races
>> > > >> > during
>> > > >> > unlink(v2)
>> > > >> > From 07d69d4 [PATCH] smsc95xx: mark link down on startup
>> > > >> > and
>> > > >> > let
>> > > >> > PHY interrupt
>> > > >> > a timeout occurred:
>> > > >> > http://pastebin.com/KpaTJY3N
>> > > >> >
>> > > >> > My current kernel is based on:
>> > > >> > commit 52f476403350050beb0dff135a55c06c9e7a82a9
>> > > >> > Author: Jean-Baptiste Queru <j...@google.com>
>> > > >> > Subject: Revert "gpu: pvr: Revert to 1.8@550175"
>> > > >> >
>> > > >> > I managed to get a register and PHY dump when upload is
>> > > >> > stuck,
>> > > >> > thanks to ethtool:
>> > > >> >
>> > > >> > 000: 01 00 00 ec 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 010: 04 00 00 00 00 14 00 00 00 00 00 00 00 20 00 00
>> > > >> > 020: 81 00 00 00 00 00 11 01 1f 00 00 1f a0 30 f8 00
>> > > >> > 030: 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00
>> > > >> > 040: 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 060: 00 00 00 00 00 00 00 00 00 80 00 00 00 20 00 00
>> > > >> > 070: 00 00 00 00 83 0f 83 0f 00 00 00 00 0f 06 0f 06
>> > > >> > 080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 0a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 0b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 100: 0c 20 10 00 f7 6f 00 00 a2 7d 13 dd 00 00 00 40
>> > > >> > 110: 20 00 00 80 40 09 00 00 e1 c1 00 00 00 00 00 00
>> > > >> > 120: 00 81 00 00 ff ff 00 00 00 00 00 00 00 00 00 00
>> > > >> > 130: 00 31 00 00 2d 78 00 00 07 00 00 00 c3 c0 00 00
>> > > >> > 140: e1 0d 00 00 e1 c1 00 00 0b 00 00 00 ff ff 00 00
>> > > >> > 150: ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00
>> > > >> > 160: ff ff 00 00 ff ff 00 00 ff ff 00 00 00 00 00 00
>> > > >> > 170: 40 00 00 00 02 00 00 00 e1 00 00 00 ff ff 00 00
>> > > >> > 180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > > >> > 190: ff ff 00 00 ff ff 00 00 00 00 00 00 0a 00 00 00
>> > > >> > 1a0: 00 00 00 00 c8 00 00 00 50 00 00 00 58 10 00 00
>> > > >> >
>> > > >> > But the 9514.pdf datasheet I have misses register
>> > > >> > description.
>> > > >> > Then decoding all this is quite troublesome.
>> > > >> >
>> > > >> > I saw that Ubuntu release got trouble with this chipset and
>> > > >> > acpi.
>> > > >> > But there is no acpi on Android AFAIK.
>> > > >> > Did anyone else experience this issue?
>> > > >> > Does anyone have an idea where it can come from?
>> > > >> >
>> > > >> >
>> > > >> > Thanks a lot for your kind support,
>> > > >> > Emeric
>> > > >> > _______________________________________________
>> > > >> > Omapandroid-discussion mailing list
>> > > >> > Omapandroid...@gforge.ti.com
>> > > >> > https://gforge.ti.com/mailman/listinfo/omapandroid-discussion
>> > > >>
>> > > >
>> > > > _______________________________________________
>> > > > Omapandroid-discussion mailing list
>> > > > Omapandroid...@gforge.ti.com
>> > > > https://gforge.ti.com/mailman/listinfo/omapandroid-discussion
>> > >
>> > >
>> > >
>> > > --
>> > > Zach Pfeffer
>> > > Android Platform Team Lead, Linaro Platform Teams
>> > > Linaro.org | Open source software for ARM SoCs
>> > > Follow Linaro: http://www.facebook.com/pages/Linaro
>> > > http://twitter.com/#!/linaroorg -
>> > > http://www.linaro.org/linaro-blog
>> > >



--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

[Pandita, Vikram]

On Mon, Jul 2, 2012 at 2:11 PM, Zach Pfeffer <zach.p...@linaro.org> wrote:
>
> On 29 June 2012 10:55, Émeric Vigier <emeric...@savoirfairelinux.com>
> wrote:
> > Hi,
> >
> > I am not 100% sure but it seems my smsc95xx is unable to wake up the CPU
> > while it is in WFI.
> > I have verified that my OMAP4430 constantly enters WFI. Note that sleep
> > states are disabled.
> > USB mouse and keyboard events wake it up properly. eth0 RX seems to wake
> > it up, but eth0 TX does not...
> > What could be possibly wrong in my config then? usbnet.c only creates
> > softirq to submit URB. No HW irq.
> >
> > How can I make smsc95xx trigger an interrupt (ehci_hcd:usb1) while
> > transferring data?
> > Do you know?

The pad for gpio will have to be made wakeup capable. Each ball on
omap has a mux that has one bit to make it wakeup capable...
typically disabling cpuidle if fixes the issue, then you are sure its
this issue.

[Michael Malyshev]

it worth a try to monitor signals on PM pins of
ETH chip using oscilloscope

On Thu, Jul 5, 2012 at 1:31 AM, Michael Malyshev <mike.m...@gmail.com> wrote:

the datasheet for the chip is here

http://www.smsc.com/media/Downloads_Public/Data_Sheets/9514.pdf

reading this paper I noticed that power management is shared between  USB and ETH. I think that when you move your mouse ETH is waken up because USB is waken up. the datasheet says

"Many customers use a single poly fuse to power all their devices. For the ganged situation, all power
control pins must be tied together"

I think you need to check the schematics for your board and analyze how PM is implemented. I had problems with TI's implementation of ETH support on other boards. It always was a low priority for some reason. Maybe because Linux kernel is being updated too often and ETH is not that required.

as a conclusion I would look into PM implementation differences in working and non-working kernels including PLL and power domain configurations

On Wed, Jul 4, 2012 at 11:45 PM, Émeric Vigier <emeric...@savoirfairelinux.com> wrote:

----- Mail original -----
> De: "Jassi Brar" <jaswind...@linaro.org>
> À: "Émeric Vigier" <emeric...@savoirfairelinux.com>
> Cc: "Vikram Pandita" <vikram....@ti.com>, "linaro-android" <linaro-...@lists.linaro.org>,
> panda...@googlegroups.com, omapandroid...@gforge.ti.com
> Envoyé: Mercredi 4 Juillet 2012 11:22:29

> Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload hangs
>

> On 4 July 2012 18:51, Émeric Vigier

> <emeric...@savoirfairelinux.com> wrote:
> >
> > Disabling CONFIG_CPU_IDLE does not improve anything, TX remains
> > stuck.
> > Interrupt 109 ehci_usb:usb1 occurs, I logged usb_hcd_irq
> > successfully, but only on when RX i on-going. When it occurs, my
> > TX gets resumed for some time.
> > When I move my mouse, dozen of 109 interrupts occurs, then TX gets
> > resumed for a longer period. And eventually got stuck again.
> >
> > I made a usbmon trace yesterday. I am not a USB expert, but if
> > someone in the room finds something (not) obvious (to me), that
> > would make my day (week actually...).
> > http://pastebin.com/v9GXn5Z7
> >

> Perhaps someone could relieve me of my naivety, but I think unlike
> mouse/keyboard input and ethernet RX, the TX isn't triggered by any
> interrupt, so WFI not moving on is only natural ?

You may be right, I only see interrupts in usbmon traces when I moved my USB mouse.
The fact that mouse activity resumes TX activity would then not be related to interrupts, but something else.
Argh... I hate making assumptions, because I know it is the worst way to debug a problem.


I booted linaro kernel built with panda_defconfig, and my current android images. Android zygote did not start, but I could test eth0 from command line anyway.
Not surprisingly, TX worked fine, achieving ~10MBps (compared to 20KBps when TX gets stuck).

The panda_defconfig from linaro and mine has only CONFIG_DYNAMIC_DEBUG difference. Then my bug must come from the sources:
$ git diff kernel_linaro/drivers/usb kernel/drivers/usb > linaro-11.09_android-omap-panda-3.0_kernel-drivers-usb.diff
http://pastebin.com/Cdas1SMc

There is a huge part concerning PM_RUNTIME in drivers/usb/host/ehci-omap.c that looks suspect...
I will try without related patches.

$ git diff kernel_linaro/drivers/net/usb kernel/drivers/net/usb
only contains diffs on cdc_ncm.c, asix.c. Not interesting...

$ git diff kernel_linaro/drivers/net kernel/drivers/net
has huge differences... But I prefer to ignore them for now.

git diff kernel_linaro/arch/arm/mach-omap2 kernel/arch/arm/mach-omap2
has huge differences as well... The omap44xx_usbhs_ehci_hwmod is not present in linaro kernel for instance.


Regards,

[Michael Malyshev]

[Émeric Vigier]

Hi Vikram, Zach,

Disabling CONFIG_CPU_IDLE does not improve anything, TX remains stuck.
Interrupt 109 ehci_usb:usb1 occurs, I logged usb_hcd_irq successfully, but only on when RX i on-going. When it occurs, my TX gets resumed for some time.
When I move my mouse, dozen of 109 interrupts occurs, then TX gets resumed for a longer period. And eventually got stuck again.

I made a usbmon trace yesterday. I am not a USB expert, but if someone in the room finds something (not) obvious (to me), that would make my day (week actually...).
http://pastebin.com/v9GXn5Z7

Thanks,
Emeric

----- Mail original -----

> De: "Vikram Pandita" <vikram....@ti.com>
> À: "Zach Pfeffer" <zach.p...@linaro.org>
> Cc: "Émeric Vigier" <emeric...@savoirfairelinux.com>, "linaro-android" <linaro-...@lists.linaro.org>,
> panda...@googlegroups.com, omapandroid...@gforge.ti.com
> Envoyé: Lundi 2 Juillet 2012 17:36:33

[Jassi Brar]

On 4 July 2012 18:51, Émeric Vigier <emeric...@savoirfairelinux.com> wrote:
>

> Disabling CONFIG_CPU_IDLE does not improve anything, TX remains stuck.
> Interrupt 109 ehci_usb:usb1 occurs, I logged usb_hcd_irq successfully, but only on when RX i on-going. When it occurs, my TX gets resumed for some time.
> When I move my mouse, dozen of 109 interrupts occurs, then TX gets resumed for a longer period. And eventually got stuck again.
>
> I made a usbmon trace yesterday. I am not a USB expert, but if someone in the room finds something (not) obvious (to me), that would make my day (week actually...).
> http://pastebin.com/v9GXn5Z7
>

[Émeric Vigier]

Hi Michael,

Ok, I will get back to the schematics and try some probing again.
9514.pdf is the datasheet I have on my side as well. But it lacks register descriptions... Steve Glendinning told me the only public register description lies in smsc95xx.h. I suppose I should consider this great enough...

I narrowed down the patches touching drivers/usb/host/ehci-omap.c which are in my (faulty) kernel, but not on the (working) linaro one.
I reverted them all one by one with following status:

Revert "mfd: Add omap-usbhs runtime PM support"
This reverts commit 1233c937d09450956989953841837445aff09336.
=> FAILED

Revert "arm: omap: usb: global Suspend and resume support of ehci and ohci"
This reverts commit 8e9aaf5c4051a8051a87d5fde67141ae062a2f04.
=> FAILED

Revert "usb: ehci-omap: fix clock enabling in shutdown path"
This reverts commit 33a2170896e4f52b504b1fb06e885b4505c69f05.
=> FAILED

Revert "OMAP4: USBHS: Enable remote wakeup using I/O pads"
This reverts commit e50bc2a90c69d09a5fee40f1afaebf19bd559352.
Conflicts:
arch/arm/mach-omap2/pm44xx.c
=> FAILED, although I fixed/hacked the conflict

Revert "usb: ehci-omap: control transceiver clock"
This reverts commit 43deff8560f2395cb833a21d1e0cf518182f086f.
=> FAILED

Previously, with Manuel from Ti, I checked that VDD33IO was fine:
http://e2e.ti.com/support/omap/f/849/p/196732/705274.aspx#705274
I pushed a drawing of my scope capture.

I will if my patch revert have changed anything to this power signal.

Thanks,
Emeric

----- Mail original -----
> De: "Michael Malyshev" <mike.m...@gmail.com>
> À: "Émeric Vigier" <emeric...@savoirfairelinux.com>
> Cc: "Jassi Brar" <jaswind...@linaro.org>, "linaro-android" <linaro-...@lists.linaro.org>,
> panda...@googlegroups.com, omapandroid...@gforge.ti.com
> Envoyé: Mercredi 4 Juillet 2012 17:33:55

> Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload hangs
>

> > panda...@googlegroups.com , omapandroid...@gforge.ti.com

[Émeric Vigier]

----- Mail original -----
> De: "Jassi Brar" <jaswind...@linaro.org>
> À: "Émeric Vigier" <emeric...@savoirfairelinux.com>
> Cc: "Vikram Pandita" <vikram....@ti.com>, "linaro-android" <linaro-...@lists.linaro.org>,

> panda...@googlegroups.com, omapandroid...@gforge.ti.com

> Envoyé: Mercredi 4 Juillet 2012 11:22:29
> Objet: Re: [Omapandroid-discussion] smsc95xx: download ok, upload hangs
>

[Émeric Vigier]

With patch reverted, VDD33IO signals look the same as I depicted on Ti forums.
I checked VDD33A, and it is 3.3V flat. It never goes low.
According to my pandaboard-a-schematic.pdf, both signals should have the same shape as VDD33IO and VDD33A are (supposed to be) connected to VDD_HUB_FLT.
But I see different signals, hmmm...
I don't know what that means. Any idea?

Emeric

----- Mail original -----

> De: "Émeric Vigier" <emeric...@savoirfairelinux.com>
> À: "Michael Malyshev" <mike.m...@gmail.com>

> Cc: "Jassi Brar" <jaswind...@linaro.org>, "linaro-android" <linaro-...@lists.linaro.org>,
> panda...@googlegroups.com, omapandroid...@gforge.ti.com

> Envoyé: Mercredi 4 Juillet 2012 18:48:38

[Émeric Vigier]

Today, I wanted to check ehci PHY was in a correct state. The register dump of smsc9514 shows that the chip is always in READY state.
But I can't state concerning omap ehci PHY: there are a lot of PM_RUNTIME, clk and regulator things I have to decrypt...

omap4_ehci_init() gets auxclk3_ck and sets it to 19.2MHz. Here is what I see:

# cd /sys/kernel/debug/clock/virt_38400000_ck/sys_clkin_ck/auxclk3_src_ck
# for file in `find . -type f`; do echo "$file `cat $file`"; done
./auxclk3_ck/auxclkreq3_ck/flags 0x30a21c00
./auxclk3_ck/auxclkreq3_ck/rate 19200000
./auxclk3_ck/auxclkreq3_ck/usecount 0
./auxclk3_ck/flags 0x30a31c00
./auxclk3_ck/rate 19200000
./auxclk3_ck/usecount 1
./flags 0x30a31c00
./rate 38400000
./usecount 1

"auxclkreq3_ck/usecount" never gets positive, whatever I do (mouse event,RX , TX, ...).
Linaro working release shows the same usecount and flags. So that must be fine.

# cat /sys/kernel/debug/prcm-on
PD_L3_INIT curr=ON prev=OFF logic=ON
CD_L3_INIT mode=SW_WKUP activity=0x2007300
USBPHY mode=AUTO idlest=ON optclk=0x100
FSUSB mode=ENABLED stbyst=STBY idlest=ON
HSUSBHOST mode=ENABLED stbyst=ON idlest=ON
HSUSBOTG mode=AUTO stbyst=ON idlest=ON
USBTLL mode=AUTO idlest=ON
DPLL_USB status=locked

I cannot get this on linaro as prcm-on file does not exist :-(

# cd /sys/kernel/debug/regulator/VUSB
# for file in `busybox find . -type f`; do echo "$file `cat $file`"; done
./twl6030_usb-vusb/max_uV 0
./twl6030_usb-vusb/min_uV 0
./twl6030_usb-vusb/uA_load 0
./open_count 1
./use_count 1

I checked also pm_debug/time and count on both linaro-12.05 and my faulty build:
http://pastebin.com/6AJtEXut
http://pastebin.com/L0JzVtJy

Unfortunately, /sys/kernel/debug/pm_debug is not present on linaro-11.09...

Emeric

----- Mail original -----
> De: "Émeric Vigier" <emeric...@savoirfairelinux.com>
> À: "Michael Malyshev" <mike.m...@gmail.com>
> Cc: "Jassi Brar" <jaswind...@linaro.org>, "linaro-android" <linaro-...@lists.linaro.org>,
> panda...@googlegroups.com, omapandroid...@gforge.ti.com

> Envoyé: Mercredi 4 Juillet 2012 19:16:00

[Pandita, Vikram]

+ anand and moiz if they can pitch in.
I am stuck with some customer defects that I not letting me follow well this thread.

On Jul 12, 2012 1:38 PM, "Émeric Vigier" <emeric...@savoirfairelinux.com> wrote:

Hi all,

Some follow-up on my long lasting issue...
Ming Lei, from Canonical, made me test usb host storage: https://bugs.launchpad.net/linux-linaro/+bug/709245.
It is broken as well, barely 100KBps (with usbmon...). Then my problem does not come from usbnet or smsc95xx.c driver, but probably something with omap ehci and/or omap PM.

I still cannot believe that I am alone using ethernet and usb host on a pandaboard running google official ICS.

--

[Émeric Vigier]

Hi all,

Some follow-up on my long lasting issue...
Ming Lei, from Canonical, made me test usb host storage: https://bugs.launchpad.net/linux-linaro/+bug/709245.
It is broken as well, barely 100KBps (with usbmon...). Then my problem does not come from usbnet or smsc95xx.c driver, but probably something with omap ehci and/or omap PM.

I still cannot believe that I am alone using ethernet and usb host on a pandaboard running google official ICS.

--
Emeric

[Sagar Shinde]

Hi all,

We have got same problem. We use a test automation setup of around 25 Pandaboards.
During testing we send/receive huge amount of data over ethernet to PB. But with onboard Ethernet we get really bad network throughput.
I tried all steps by Emeric (patching the drivers/usb from Linaro kernel, disabling CPU idle flags)  but it dint help.

As mentioned in this thread earlier, moving the mouse etc does improve throughput for that period of time. I also tried by running a script in a loop in background, which does some work after every 100 msec, this also surprisingly improves throughput and we do get data transfer rate of 300-700 Kb/s, (still very less).

Also when we connected external usb to ethernet adapter with ASIX chips the throughput is really good, but we consider this as workaround.
I am testing throughput with iperf.

Has there been any investigations or findings on this issue?
Thanks for any suggestions.

BR
Sagar

[Sagar Shinde]

Hi,

I was using this AOSP ICS build for Panda created by Linaro
http://releases.linaro.org/12.07/android/images/panda-master-gcc44-aosp-stable-blob/

This AOSP ICS build doesnot seem to have the usb networking issue (same as in the thread below) that I have been trying to fix for few weeks now.

So probably kernel in this AOSP ICS image created by Linaro has some fix for it.
I checked the pinned-manifest.xml for which kernel it uses
<project name="kernel/omap" revision="52f476403350050beb0dff135a55c06c9e7a82a9">

So as I understand its above revision checked out from git://android.git.linaro.org/kernel/omap.
I tried to download these sources, but I did not find any difference in the kernel sources I downloaded from AOSP git. (Both also have seem to have same revision!)

I tried to build this kernel and use in AOSP ICS and again I face same usb-ethernet networking issue.

So I am really curious to find the kernel sources used to build the kernel in the AOSP ICS images created by Linaro.

Please could you help with some pointers?
Thanks for your kind support.

BR
Sagar