Hi Rob,
Koen just pushed another ehci defconfig change to the angstrom's source tree..
I've just uploaded a build based on that here:
http://www.rcn-ee.com/deb/kernel/CC-beagle-v2.6.29-58cf2f1-oer32
I haven't tested it yet to see if it solves the problem i was seeing..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
This might be interesting for other things as well.
I noticed that my kingston 4gb sdhc card does not work with the latest
kernels but used to work on .27 or so.
Also I noticed some usb issues with EHCI (1.1 webcam on hub not
working; hauppage pvr working directly on ehci works, but if connected
to the hub it does not work any more; apparently the reset after
loading the firmware does not get thru. This happens with several
brands hub, but of course it it could be they have the same chip
inside). Odd thing is that the very same device on the very same hub
works like a charm under opensuse 11.1 (and also worked on 2.6.11 or
so on NLSU2 which is much slower).
Of course I have no idea if that is the ehci hw or the ehci driver
that is causing the issue (and no idea how to further diagnose this).
Frans
On Jun 4, 5:18 pm, Gerald Coley <ger...@beagleboard.org> wrote:
> Request an RMA immediately!
>
> Gerald
Well, before I do that, I'd like to characterized, as best I can, what
is going on.
I have some more data:
My board, held in the chamber at 0C, configured as I had it in my
office, did fail eventually, but it was MUCH more reliable than it was
at ambient. It took many hundreds of runs of my test (dd if=/dev/zero
of=/media/disk/zeros bs=1024 count=100000) before it failed with the
disabled message.
When we brought the chamber up to 25C it died on the second run of the
test.
We are currently running the same test with a different Beagleboard,
but otherwise the same configuration and at 25C.
For reference, my configuration is:
Beagleboard on a 5V, 2A supply purchased from DigiKey.
RS-232 on the board connected to an external serial terminal.
8G Class 6 SDHC with Ubuntu on it.
USB host port driving a 4 port, self-powered hub with the USB memory
stick, keyboard, mouse, and a second 4 port hub on it.
Second 4 port self powered hub driving a Wii USB to Ethernet device
(no network connected).
HDMI port connected to a flat-panel interface to a 12" flat panel.
I'm going to let the second board run in the chamber at 24C for
another hour, then I will put my board back on the bench and run my
tests with everything but the serial port, SDHC, and USB memory on it.
After I do that, I will post my results.
Gerald - are you just RMA it, or are you actually wanting to examine
my board?
I have also problems with the keyboard and I get corrupted data with
my USB 1.1 pwc webcam (connected through a hub of course).
I was under the impression this was a SW issue.
Frans
beagleboard login: usb 2-1.1: reset high speed USB device using musb_hdrc and ad
dress 3
------------[ cut here ]------------
WARNING: at drivers/usb/musb/musb_host.c:128 musb_h_tx_flush_fifo+0x94/0xd4()
Could not flush host TX3 fifo: csr: 0003
Modules linked in: ipv6 rt73
[<c039e304>] (dump_stack+0x0/0x14) from [<c00647b0>] (warn_slowpath+0x5c/0x78)
[<c0064754>] (warn_slowpath+0x0/0x78) from [<c0270c4c>] (musb_h_tx_flush_fifo+0x
94/0xd4)
r3:00000003 r2:c0484cfb
r6:ffffffff r5:00000003 r4:00000003
[<c0270bb8>] (musb_h_tx_flush_fifo+0x0/0xd4) from [<c0271998>] (musb_cleanup_urb
+0xd4/0x120)
[<c02718c4>] (musb_cleanup_urb+0x0/0x120) from [<c0271ff8>] (musb_urb_dequeue+0x
140/0x174)
[<c0271eb8>] (musb_urb_dequeue+0x0/0x174) from [<c0252898>] (unlink1+0xb8/0xc4)
[<c02527e0>] (unlink1+0x0/0xc4) from [<c0253088>] (usb_hcd_unlink_urb+0x58/0x74)
r8:cf89dfa0 r7:ffffff98 r6:cf9a2560 r5:a0000093 r4:00000000
[<c0253030>] (usb_hcd_unlink_urb+0x0/0x74) from [<c0253b6c>] (usb_unlink_urb+0x4
0/0x44)
r7:cf89df94 r6:00000500 r5:cf99a000 r4:cf99a35c
[<c0253b2c>] (usb_unlink_urb+0x0/0x44) from [<c0268b70>] (usb_stor_stop_transpor
t+0x3c/0x68)
[<c0268b34>] (usb_stor_stop_transport+0x0/0x68) from [<c0268060>] (command_abort
+0x7c/0x90)
r4:cf99a35c
[<c0267fe4>] (command_abort+0x0/0x90) from [<c02208bc>] (scsi_send_eh_cmnd+0x128
/0x21c)
r4:40000013
[<c0220794>] (scsi_send_eh_cmnd+0x0/0x21c) from [<c02209dc>] (scsi_eh_tur+0x2c/0
x88)
[<c02209b0>] (scsi_eh_tur+0x0/0x88) from [<c0221360>] (scsi_error_handler+0x184/
0x364)
r5:cfab48ac r4:cfab48a0
[<c02211dc>] (scsi_error_handler+0x0/0x364) from [<c0078190>] (kthread+0x5c/0x94
)
[<c0078134>] (kthread+0x0/0x94) from [<c00679ac>] (do_exit+0x0/0x6a8)
r6:00000000 r5:00000000 r4:00000000
---[ end trace fc1b8fac7574014e ]---
usb 2-1.1: reset high speed USB device using musb_hdrc and address 3
root@beagleboard:~# usb 2-1.1: reset high speed USB device using musb_hdrc and a
ddress 3
------------[ cut here ]------------
WARNING: at drivers/usb/musb/musb_host.c:128 musb_h_tx_flush_fifo+0x94/0xd4()
Could not flush host TX3 fifo: csr: 0003
Modules linked in: ipv6 rt73
[<c039e304>] (dump_stack+0x0/0x14) from [<c00647b0>] (warn_slowpath+0x5c/0x78)
[<c0064754>] (warn_slowpath+0x0/0x78) from [<c0270c4c>] (musb_h_tx_flush_fifo+0x
94/0xd4)
r3:00000003 r2:c0484cfb
r6:ffffffff r5:00000003 r4:00000003
[<c0270bb8>] (musb_h_tx_flush_fifo+0x0/0xd4) from [<c0271998>] (musb_cleanup_urb
+0xd4/0x120)
[<c02718c4>] (musb_cleanup_urb+0x0/0x120) from [<c0271ff8>] (musb_urb_dequeue+0x
140/0x174)
[<c0271eb8>] (musb_urb_dequeue+0x0/0x174) from [<c0252898>] (unlink1+0xb8/0xc4)
[<c02527e0>] (unlink1+0x0/0xc4) from [<c0253088>] (usb_hcd_unlink_urb+0x58/0x74)
r8:cf949fa0 r7:ffffff98 r6:cf89c560 r5:a0000093 r4:00000000
[<c0253030>] (usb_hcd_unlink_urb+0x0/0x74) from [<c0253b6c>] (usb_unlink_urb+0x4
0/0x44)
r7:cf949f94 r6:00000500 r5:cf99c000 r4:cf99c35c
[<c0253b2c>] (usb_unlink_urb+0x0/0x44) from [<c0268b70>] (usb_stor_stop_transpor
t+0x3c/0x68)
[<c0268b34>] (usb_stor_stop_transport+0x0/0x68) from [<c0268060>] (command_abort
+0x7c/0x90)
r4:cf99c35c
[<c0267fe4>] (command_abort+0x0/0x90) from [<c02208bc>] (scsi_send_eh_cmnd+0x128
/0x21c)
r4:40000013
[<c0220794>] (scsi_send_eh_cmnd+0x0/0x21c) from [<c02209dc>] (scsi_eh_tur+0x2c/0
x88)
[<c02209b0>] (scsi_eh_tur+0x0/0x88) from [<c0221360>] (scsi_error_handler+0x184/
0x364)
r5:cfab48ac r4:cfab48a0
[<c02211dc>] (scsi_error_handler+0x0/0x364) from [<c0078190>] (kthread+0x5c/0x94
)
[<c0078134>] (kthread+0x0/0x94) from [<c00679ac>] (do_exit+0x0/0x6a8)
r6:00000000 r5:00000000 r4:00000000
---[ end trace ace7fd02eed9425e ]---
usb 2-1.1: reset high speed USB device using musb_hdrc and address 3
usb 2-1.1: reset high speed USB device using musb_hdrc and address 3
usb 2-1.1: reset high speed USB device using musb_hdrc and address 3
Does anybody know what's happening here?
Wkr,
Joep
Can you share this stress test?
I'm seeing issues with mine and would like to verify myself if I have
the problem or not.
Frans
KP
Is VDD2 software controlled? If I ask such question does it
automatically mean I am not qualified to play around with this? The best
would be prebuild kernel with tunable VDD2 voltage via some knob in
/sys. Or maybe it can be changed via some uboot command before booting
kernel?
I think I do have this issue and I would be willing to play with it. It
is rev C2 board and no matter what power supply I attach or what usb hub
I attach the hub is disconnected when I attach usb keyboard and the EHCI
port doesn't work (re-plugging hub, trying other usb 2.0 device) until I
boot the board again. I tried 2 hubs, 3 power supplies (5V/1A and two
5V/2.5A), 2 keyboards.
Also usb harddisk connected directly to EHCI port mostly works but fails
later when reading more data (using dd, testing longer movie in mplayer).
All this happens when using images from
http://code.google.com/p/beagleboard/wiki/BeagleboardRevCValidation
> We hope to have an official solution in a couple of weeks at
> the latest after more data is collected from our testing.
Great. I hope this can be fixed only in software. I noticed this issue
only recently and it is more than 90 days from buying the board so
according to http://beagleboard.org/support I cannot do RMA (and anyway
I am in Europe and bought it via friend in US so the digi-key invoice
has different name and address).
Frantisek
Any experimental kernels/bootloaders to try? I'm running my
beagleboard from a USB disk and it usually runs without problems for
quite long times, but eventually I get something like:
hub 2-2:1.0: cannot reset port 2 (err = -71)
hub 2-2:1.0: cannot reset port 2 (err = -71)
hub 2-2:1.0: cannot reset port 2 (err = -71)
hub 2-2:1.0: cannot reset port 2 (err = -71)
hub 2-2:1.0: cannot reset port 2 (err = -71)
hub 2-2:1.0: Cannot enable port 2. Maybe the USB cable is bad?
etc.
I'd be happy to test any patches or do some debugging if someone
guides me into what kind of information would be useful :-)
http://www.webos-internals.org/wiki/Patch_webOS_CPU_Frequency_or_Voltage_Scaling#Enable_SmartReflex
the file is there but after running
echo -n 1 > /sys/power/sr_vdd2_autocomp
there is still zero in the file and in kernel log I see
OPP3 doesn't support SmartReflex
SR2: VDD autocomp not activated
Maybe different kernel would do.
Would it make sense to ask for help in the linux-omap mailing list?
I guess Gerald has a reply from TI or a new errata list or something else
which says that "enabling Smart Reflex on VDD2" can workaround EHCI problem.
Now somebody knowledgeable about kernel internals, OMAP3, Smart Reflex
and power management code in general could probably provide some hints
or even a patch to enable this bugfix in the kernel. Maybe the fix is even
sitting in somebody's branch already and we just don't know. Or maybe a
solution for EHCI problem has been explained in the list, but just was
lost in the pile of other messages in linux-omap (it has quite a heavy
traffic).
It may make sense to look at the 'pm' branch:
http://elinux.org/OMAP_Power_Management
But this wiki page has comment:
"Enables SmartReflex autocompensation on VDD2 (Note: This feature can only be
tested on a ES3.1 silicon):
# echo 1 > /sys/power/sr_vdd2_autocomp"
And AFAIK beagleboard revision C has ES3.0 silicon. So no luck here. Or can
something still be done?
The whole beagleboard EHCI story starts here:
http://groups.google.com/group/beagleboard/browse_thread/thread/5b8385f0bb1f63da/d46625fe49783a8a
--
Best regards,
Siarhei Siamashka
>
> On Saturday 15 August 2009, Frantisek Dufka wrote:
>> Gerald Coley wrote:
>>> You need to enable Smart Reflex on VDD2 in the Kernel. I can't
>>> seem to
>>> get anyone around here to help me formalize exactly how to do this
>>> in
>>> the Kernel. So if you can figure it out, I would go ahead and do
>>> it. If
>>> you could please then post it to the community, that would be great.
>>>
>>> Gerald
>>
>> http://www.webos-internals.org/wiki/Patch_webOS_CPU_Frequency_or_Voltage_Sc
>> aling#Enable_SmartReflex
>>
>> the file is there but after running
>> echo -n 1 > /sys/power/sr_vdd2_autocomp
>> there is still zero in the file and in kernel log I see
>> OPP3 doesn't support SmartReflex
>> SR2: VDD autocomp not activated
>>
>> Maybe different kernel would do.
>
> Would it make sense to ask for help in the linux-omap mailing list?
You mean like this: http://thread.gmane.org/gmane.linux.ports.arm.omap/22131
:)
regards,
Koen
OK, thanks. It's good that somebody is actively looking for a solution.
This EHCI issue suddenly started to be a problem for me too just a few days
ago when I tried to hook an external USB HDD to beagle. I did not pay much
attention to these discussion threads earlier so don't have a full picture
yet. And I'm not sure if I have enough spare time to catch up with this stuff,
probably I will just put this HDD on a shelf and wait a few weeks/months :)
Grégoire
On Sat, 15 Aug 2009, Siarhei Siamashka wrote:
> But this wiki page has comment:
> "Enables SmartReflex autocompensation on VDD2 (Note: This feature can only be
> tested on a ES3.1 silicon):
> # echo 1 > /sys/power/sr_vdd2_autocomp"
>
> And AFAIK beagleboard revision C has ES3.0 silicon. So no luck here. Or can
> something still be done?
It should be possible to enable SmartReflex on <ES3.1, but the SR register
values need to be programmed at runtime. (ES3.1 has the SR register
values blown in to eFUSE OTPROM)
As far as I know, only TI has this information, so it's up to them to
release it. Although one of the device vendor kernel patches/tarballs
might have something useful here - I haven't looked recently.
- Paul
> On Saturday 15 August 2009, Frantisek Dufka wrote:
> > Gerald Coley wrote:
> > > You need to enable Smart Reflex on VDD2 in the Kernel. I can't seem to
> > > get anyone around here to help me formalize exactly how to do this in
> > > the Kernel. So if you can figure it out, I would go ahead and do it. If
> > > you could please then post it to the community, that would be great.
> > >
> > > Gerald
> >
> > http://www.webos-internals.org/wiki/Patch_webOS_CPU_Frequency_or_Voltage_Sc
> >aling#Enable_SmartReflex
Seems hacking moves along fast, some basic info and mis-info on Pre. Pre kernel which is shipped needs a few patches and it is capable of running sr+dvfs at the same time.
> > the file is there but after running
> > echo -n 1 > /sys/power/sr_vdd2_autocomp
> > there is still zero in the file and in kernel log I see
> > OPP3 doesn't support SmartReflex
> > SR2: VDD autocomp not activated
In older code you need both compile time and run time to get it to take. Just turning it on won't be so safe until some bug fixes make their way out.
> It may make sense to look at the 'pm' branch:
> http://elinux.org/OMAP_Power_Management
pm branch needs a few changes to make it viable for sr.
> But this wiki page has comment:
> "Enables SmartReflex autocompensation on VDD2 (Note: This feature can only be
> tested on a ES3.1 silicon):
> # echo 1 > /sys/power/sr_vdd2_autocomp"
>
> And AFAIK beagleboard revision C has ES3.0 silicon. So no luck here. Or can
> something still be done?
You will only find characterized parameters for 3.1 and 3.1.1. These are production parts.
I had heard a few bits of talk about running at lower voltage helping ehci out. That seems backwards even if tests show it working. I wonder if it is some artifact of a timing change which happens at lower voltage and because of some new internal chip activity.
Regards,
Richard W.
>
> On Saturday 15 August 2009, Koen Kooi wrote:
>> Op 15 aug 2009, om 22:04 heeft Siarhei Siamashka het volgende
>>
>> geschreven:
>>> On Saturday 15 August 2009, Frantisek Dufka wrote:
>>>> Gerald Coley wrote:
>>>>> You need to enable Smart Reflex on VDD2 in the Kernel. I can't
>>>>> seem to
>>>>> get anyone around here to help me formalize exactly how to do this
>>>>> in
>>>>> the Kernel. So if you can figure it out, I would go ahead and do
>>>>> it. If
>>>>> you could please then post it to the community, that would be
>>>>> great.
>>>>>
>>>>> Gerald
>>>>
>>>> http://www.webos-internals.org/wiki/Patch_webOS_CPU_Frequency_or_Voltage
>>>> _Sc aling#Enable_SmartReflex
>>>>
>>>> the file is there but after running
>>>> echo -n 1 > /sys/power/sr_vdd2_autocomp
>>>> there is still zero in the file and in kernel log I see
>>>> OPP3 doesn't support SmartReflex
>>>> SR2: VDD autocomp not activated
>>>>
>>>> Maybe different kernel would do.
Try the kernel (and modules) from http://dominion.thruhere.net/koen/OE/vbb/
, that is built from Kevins pm-2.6.29 branch with DSS2, isp, iommu,
resizer, vfp, alsa, led, syscalls and zippy daugtherboard patches
applied. It's basically angstrom kernel + pm - extra musb patches. As
a bonus you will be able to use cpufreq to enable 600MHz :)
regards,
Koen
>>> geschreven:
>>>> On Saturday 15 August 2009, Frantisek Dufka wrote:
>>>>> the file is there but after running
>>>>> echo -n 1 > /sys/power/sr_vdd2_autocomp
>>>>> there is still zero in the file and in kernel log I see
>>>>> OPP3 doesn't support SmartReflex
>>>>> SR2: VDD autocomp not activated
>>>>>
>>>>> Maybe different kernel would do.
>
> Try the kernel (and modules) from
> http://dominion.thruhere.net/koen/OE/vbb/ , that is built from Kevins
> pm-2.6.29 branch with DSS2, isp, iommu, resizer, vfp, alsa, led,
> syscalls and zippy daugtherboard patches applied. It's basically
> angstrom kernel + pm - extra musb patches. As a bonus you will be able
> to use cpufreq to enable 600MHz :)
Thanks Koen,
echo -n 1 > /sys/power/sr_vdd2_autocomp now keeps the value stored and
it maybe even does something. I've successfully read two external usb
disks (60GB, 320GB) via dd with no error. Both were conected to usb hub.
Will try without hub too.
This kernel has two issues though. There are some periodic power
management related stacktraces in kernel log (something with PRCM and
cpu idle) and also when switched to 600MHz (which is default) my Nokia
branded mmcmobile 1GB card gives me i/o errors consistently on specific
block when read via dd. At 500MHz it is OK. Two other SD cards and one
2GB Kingston mmcmobile are fine both at 600 and 500 Mhz.
Also when I enabled sleep while idle it hangs after a while. I still see
the screen output but cursor stops blinking and typing on usb keyboard
does nothing.
All those tests were done only with display and usb keyboard so no
kernel output was saved, next time I'll try serial console and save the log.
Frantisek
Are there thermal issues?
KP