I've seen a number of people having problems with the USB host port
(EHCI) on
the Rev C beagleboards. I seem to be having the same problem and
after a few
days of random lockups, I found I can easily reproduce it by reading
data
from a USB disk with dd. After a few seconds of I/O I get the
following:
beagleboard login: root
root@beagleboard:~# dd if=/dev/sda bs=1M > /dev/null
hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
usb 1-2: USB disconnect, address 2
sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
end_request: I/O error, dev sda, sector 647152
__ratelimit: 3 callbacks suppressed
Buffer I/O error on device sda, logical block 80894
Buffer I/O error on device sda, logical block 80895
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sda, sector 647168
Buffer I/O error on device sda, logical block 80896
Buffer I/O error on device sda, logical block 80897
Buffer I/O error on device sda, logical block 80898
Buffer I/O error on device sda, logical block 80899
Buffer I/O error on device sda, logical block 80900
Buffer I/O error on device sda, logical block 80901
Buffer I/O error on device sda, logical block 80902
Buffer I/O error on device sda, logical block 80903
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sda, sector 647408
dd: /dev/sda: Input/output error
root@beagleboard:~#
And the usb devices are dead from then on - unplugging and re-plugging
aren't
noticed, lsusb locks up or just reports the two (EHCI & MUSB) root
hubs.
This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash
drive.
The same happens with every kernel I've tried - the angstrom demos,
the Rev C
validation images, the ones from http://www.rcn-ee.com/deb/kernel/ and
ones
I've built myself from the OpenEmbedded patches. (2.6.28 and 2.6.29).
I've also updated u-boot from 2009.01-dirty (as supplied) to 2009.03.
I've tried with a couple of power supplies, USB power and also with
several
hubs (and no hub).
On Sun, May 10, 2009 at 2:58 PM, tenfoot <tenf...@gmail.com> wrote:
> Hi,
> I've seen a number of people having problems with the USB host port > (EHCI) on > the Rev C beagleboards. I seem to be having the same problem and > after a few > days of random lockups, I found I can easily reproduce it by reading > data > from a USB disk with dd. After a few seconds of I/O I get the > following:
> And the usb devices are dead from then on - unplugging and re-plugging > aren't > noticed, lsusb locks up or just reports the two (EHCI & MUSB) root > hubs. > This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash > drive.
> The same happens with every kernel I've tried - the angstrom demos, > the Rev C > validation images, the ones from http://www.rcn-ee.com/deb/kernel/ and > ones > I've built myself from the OpenEmbedded patches. (2.6.28 and 2.6.29).
> I've also updated u-boot from 2009.01-dirty (as supplied) to 2009.03.
> I've tried with a couple of power supplies, USB power and also with > several > hubs (and no hub).
> Is there anything else I can try to fix this?
> Thanks
> Rob
Hi Rob,
Koen just pushed another ehci defconfig change to the angstrom's source tree..
root@beagleboard:~# usb 1-2.1: USB disconnect, address 3
hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
usb 1-2: USB disconnect, address 2
usb 1-2.3: USB disconnect, address 4
eth0: unregister 'asix' usb-ehci-omap.0-2.3, ASIX AX88772 USB 2.0
Ethernet
usb 1-2.4: USB disconnect, address 5
I tried couple kernels with the same result.
On May 10, 3:58 pm, tenfoot <tenf...@gmail.com> wrote:
> I've seen a number of people having problems with the USB host port
> (EHCI) on
> the Rev C beagleboards. I seem to be having the same problem and
> after a few
> days of random lockups, I found I can easily reproduce it by reading
> data
> from a USB disk with dd. After a few seconds of I/O I get the
> following:
> And the usb devices are dead from then on - unplugging and re-plugging
> aren't
> noticed, lsusb locks up or just reports the two (EHCI & MUSB) root
> hubs.
> This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash
> drive.
> The same happens with every kernel I've tried - the angstrom demos,
> the Rev C
> validation images, the ones fromhttp://www.rcn-ee.com/deb/kernel/and > ones
> I've built myself from the OpenEmbedded patches. (2.6.28 and 2.6.29).
> I've also updated u-boot from 2009.01-dirty (as supplied) to 2009.03.
> I've tried with a couple of power supplies, USB power and also with
> several
> hubs (and no hub).
I'm getting similar issues with USB, almost only when creating heavy traffic
like file transfers. The (powered) USB-HUB turns off all LEDs (indicating
connected devices), and I've to reset the board to get it back running.
Connected to the USB hub is a WIFI adapter and an USB memory stick.
I've a, not fully related, follow-up question; How to build a newer kernel
revision with BitBake/OpenEmbedded? When I build the kernel some version
with some patches are build, where to define that the latest is build?
> I've seen a number of people having problems with the USB host port
> (EHCI) on
> the Rev C beagleboards. I seem to be having the same problem and
> after a few
> days of random lockups, I found I can easily reproduce it by reading
> data
> from a USB disk with dd. After a few seconds of I/O I get the
> following:
> And the usb devices are dead from then on - unplugging and re-plugging
> aren't
> noticed, lsusb locks up or just reports the two (EHCI & MUSB) root
> hubs.
> This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash
> drive.
> The same happens with every kernel I've tried - the angstrom demos,
> the Rev C
> validation images, the ones from http://www.rcn-ee.com/deb/kernel/ and
> ones
> I've built myself from the OpenEmbedded patches. (2.6.28 and 2.6.29).
> I've also updated u-boot from 2009.01-dirty (as supplied) to 2009.03.
> I've tried with a couple of power supplies, USB power and also with
> several
> hubs (and no hub).
There has been quite a thread about the disconnect problem of the USB.
I've had similar problems and I decided to return the board.
Thankfully I just (well half an hour ago) received a new board and it
works! Somehow I have the feeling that the tolerances on the board are
slightly off and some people have problems with their USB.
I am not sure whether the reported problems are solved by replacing
the board or that some kind of software trick could work as well. I am
very happy at this moment as I can show my company tomorrow what the
potential future of computing could be.
I would recommend to read the thread started by me (something with USB
and disconnect), because some people have given tips and tricks that
could help...
Kind regards, Eelco
On 19 mei, 16:22, Joep Schroen <joepschr...@gmail.com> wrote:
> I'm getting similar issues with USB, almost only when creating heavy traffic
> like file transfers. The (powered) USB-HUB turns off all LEDs (indicating
> connected devices), and I've to reset the board to get it back running.
> Connected to the USB hub is a WIFI adapter and an USB memory stick.
> I've a, not fully related, follow-up question; How to build a newer kernel
> revision with BitBake/OpenEmbedded? When I build the kernel some version
> with some patches are build, where to define that the latest is build?
> > I've seen a number of people having problems with the USB host port
> > (EHCI) on
> > the Rev C beagleboards. I seem to be having the same problem and
> > after a few
> > days of random lockups, I found I can easily reproduce it by reading
> > data
> > from a USB disk with dd. After a few seconds of I/O I get the
> > following:
> > And the usb devices are dead from then on - unplugging and re-plugging
> > aren't
> > noticed, lsusb locks up or just reports the two (EHCI & MUSB) root
> > hubs.
> > This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash
> > drive.
> > The same happens with every kernel I've tried - the angstrom demos,
> > the Rev C
> > validation images, the ones fromhttp://www.rcn-ee.com/deb/kernel/and > > ones
> > I've built myself from the OpenEmbedded patches. (2.6.28 and 2.6.29).
> > I've also updated u-boot from 2009.01-dirty (as supplied) to 2009.03.
> > I've tried with a couple of power supplies, USB power and also with
> > several
> > hubs (and no hub).
> > Is there anything else I can try to fix this?
> > Thanks
> > Rob- Tekst uit oorspronkelijk bericht niet weergeven -
For what it is worth, I tested the board that Eelco returned. After a week
of trying to make it fail, I could not. So, I had them send a new one, which
is the one he is referring to.
On Tue, May 19, 2009 at 9:58 AM, eelcor <eelco.r...@gmail.com> wrote:
> Hi,
> There has been quite a thread about the disconnect problem of the USB.
> I've had similar problems and I decided to return the board.
> Thankfully I just (well half an hour ago) received a new board and it
> works! Somehow I have the feeling that the tolerances on the board are
> slightly off and some people have problems with their USB.
> I am not sure whether the reported problems are solved by replacing
> the board or that some kind of software trick could work as well. I am
> very happy at this moment as I can show my company tomorrow what the
> potential future of computing could be.
> I would recommend to read the thread started by me (something with USB
> and disconnect), because some people have given tips and tricks that
> could help...
> > I'm getting similar issues with USB, almost only when creating heavy
> traffic
> > like file transfers. The (powered) USB-HUB turns off all LEDs (indicating
> > connected devices), and I've to reset the board to get it back running.
> > Connected to the USB hub is a WIFI adapter and an USB memory stick.
> > I've a, not fully related, follow-up question; How to build a newer
> kernel
> > revision with BitBake/OpenEmbedded? When I build the kernel some version
> > with some patches are build, where to define that the latest is build?
> > > I've seen a number of people having problems with the USB host port
> > > (EHCI) on
> > > the Rev C beagleboards. I seem to be having the same problem and
> > > after a few
> > > days of random lockups, I found I can easily reproduce it by reading
> > > data
> > > from a USB disk with dd. After a few seconds of I/O I get the
> > > following:
> > > And the usb devices are dead from then on - unplugging and re-plugging
> > > aren't
> > > noticed, lsusb locks up or just reports the two (EHCI & MUSB) root
> > > hubs.
> > > This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash
> > > drive.
> > > The same happens with every kernel I've tried - the angstrom demos,
> > > the Rev C
> > > validation images, the ones fromhttp://www.rcn-ee.com/deb/kernel/and > > > ones
> > > I've built myself from the OpenEmbedded patches. (2.6.28 and 2.6.29).
> > > I've also updated u-boot from 2009.01-dirty (as supplied) to 2009.03.
> > > I've tried with a couple of power supplies, USB power and also with
> > > several
> > > hubs (and no hub).
> > > Is there anything else I can try to fix this?
> > > Thanks
> > > Rob- Tekst uit oorspronkelijk bericht niet weergeven -
> > - Tekst uit oorspronkelijk bericht weergeven -
> For what it is worth, I tested the board that Eelco returned. After a week
> of trying to make it fail, I could not. So, I had them send a new one, which
> is the one he is referring to.
> Gerald
> On Tue, May 19, 2009 at 9:58 AM, eelcor <eelco.r...@gmail.com> wrote:
> > Hi,
> > There has been quite a thread about the disconnect problem of the USB.
> > I've had similar problems and I decided to return the board.
> > Thankfully I just (well half an hour ago) received a new board and it
> > works! Somehow I have the feeling that the tolerances on the board are
> > slightly off and some people have problems with their USB.
> > I am not sure whether the reported problems are solved by replacing
> > the board or that some kind of software trick could work as well. I am
> > very happy at this moment as I can show my company tomorrow what the
> > potential future of computing could be.
> > I would recommend to read the thread started by me (something with USB
> > and disconnect), because some people have given tips and tricks that
> > could help...
> > > I'm getting similar issues with USB, almost only when creating heavy
> > traffic
> > > like file transfers. The (powered) USB-HUB turns off all LEDs (indicating
> > > connected devices), and I've to reset the board to get it back running.
> > > Connected to the USB hub is a WIFI adapter and an USB memory stick.
> > > I've a, not fully related, follow-up question; How to build a newer
> > kernel
> > > revision with BitBake/OpenEmbedded? When I build the kernel some version
> > > with some patches are build, where to define that the latest is build?
> > > > I've seen a number of people having problems with the USB host port
> > > > (EHCI) on
> > > > the Rev C beagleboards. I seem to be having the same problem and
> > > > after a few
> > > > days of random lockups, I found I can easily reproduce it by reading
> > > > data
> > > > from a USB disk with dd. After a few seconds of I/O I get the
> > > > following:
> > > > And the usb devices are dead from then on - unplugging and re-plugging
> > > > aren't
> > > > noticed, lsusb locks up or just reports the two (EHCI & MUSB) root
> > > > hubs.
> > > > This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash
> > > > drive.
> > > > The same happens with every kernel I've tried - the angstrom demos,
> > > > the Rev C
> > > > validation images, the ones fromhttp://www.rcn-ee.com/deb/kernel/and > > > > ones
> > > > I've built myself from the OpenEmbedded patches. (2.6.28 and 2.6.29).
> > > > I've also updated u-boot from 2009.01-dirty (as supplied) to 2009.03.
> > > > I've tried with a couple of power supplies, USB power and also with
> > > > several
> > > > hubs (and no hub).
> > > > Is there anything else I can try to fix this?
> > > > Thanks
> > > > Rob- Tekst uit oorspronkelijk bericht niet weergeven -
> > > - Tekst uit oorspronkelijk bericht weergeven -
DigiKey does not handle the repairs. RMAs are through beagleboard.org.
We have no board to replace anyones boards at the moment. Fell free to send
them back and in another 3-4 weeks we will have replacements to send you.
As I already siad, the board that was returned did not fail. I tested it
myself So, it is unclear that simply getting a new board will fix anyones
problems. It could be related to a noisy power supply where some board are
more tolerant than others of this noise.
On Tue, May 19, 2009 at 11:02 AM, alexey <azapa...@gmail.com> wrote:
> Does that mean i should return board to Digikey and request new one ?
> On May 19, 11:27 am, Gerald Coley <ger...@beagleboard.org> wrote:
> > For what it is worth, I tested the board that Eelco returned. After a
> week
> > of trying to make it fail, I could not. So, I had them send a new one,
> which
> > is the one he is referring to.
> > Gerald
> > On Tue, May 19, 2009 at 9:58 AM, eelcor <eelco.r...@gmail.com> wrote:
> > > Hi,
> > > There has been quite a thread about the disconnect problem of the USB.
> > > I've had similar problems and I decided to return the board.
> > > Thankfully I just (well half an hour ago) received a new board and it
> > > works! Somehow I have the feeling that the tolerances on the board are
> > > slightly off and some people have problems with their USB.
> > > I am not sure whether the reported problems are solved by replacing
> > > the board or that some kind of software trick could work as well. I am
> > > very happy at this moment as I can show my company tomorrow what the
> > > potential future of computing could be.
> > > I would recommend to read the thread started by me (something with USB
> > > and disconnect), because some people have given tips and tricks that
> > > could help...
> > > > I'm getting similar issues with USB, almost only when creating heavy
> > > traffic
> > > > like file transfers. The (powered) USB-HUB turns off all LEDs
> (indicating
> > > > connected devices), and I've to reset the board to get it back
> running.
> > > > Connected to the USB hub is a WIFI adapter and an USB memory stick.
> > > > I've a, not fully related, follow-up question; How to build a newer
> > > kernel
> > > > revision with BitBake/OpenEmbedded? When I build the kernel some
> version
> > > > with some patches are build, where to define that the latest is
> build?
> > > > > I've seen a number of people having problems with the USB host port
> > > > > (EHCI) on
> > > > > the Rev C beagleboards. I seem to be having the same problem and
> > > > > after a few
> > > > > days of random lockups, I found I can easily reproduce it by
> reading
> > > > > data
> > > > > from a USB disk with dd. After a few seconds of I/O I get the
> > > > > following:
> > > > > And the usb devices are dead from then on - unplugging and
> re-plugging
> > > > > aren't
> > > > > noticed, lsusb locks up or just reports the two (EHCI & MUSB) root
> > > > > hubs.
> > > > > This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash
> > > > > drive.
> > > > > The same happens with every kernel I've tried - the angstrom demos,
> > > > > the Rev C
> > > > > validation images, the ones fromhttp://
> www.rcn-ee.com/deb/kernel/and > > > > > ones
> > > > > I've built myself from the OpenEmbedded patches. (2.6.28 and
> 2.6.29).
> > > > > I've also updated u-boot from 2009.01-dirty (as supplied) to
> 2009.03.
> > > > > I've tried with a couple of power supplies, USB power and also with
> > > > > several
> > > > > hubs (and no hub).
> > > > > Is there anything else I can try to fix this?
> > > > > Thanks
> > > > > Rob- Tekst uit oorspronkelijk bericht niet weergeven -
> > > > - Tekst uit oorspronkelijk bericht weergeven -
> DigiKey does not handle the repairs. RMAs are through beagleboard.org.
> We have no board to replace anyones boards at the moment. Fell free to send
> them back and in another 3-4 weeks we will have replacements to send you.
> As I already siad, the board that was returned did not fail. I tested it
> myself So, it is unclear that simply getting a new board will fix anyones
> problems. It could be related to a noisy power supply where some board are
> more tolerant than others of this noise.
> Gerald
> On Tue, May 19, 2009 at 11:02 AM, alexey <azapa...@gmail.com> wrote:
> > Does that mean i should return board to Digikey and request new one ?
> > On May 19, 11:27 am, Gerald Coley <ger...@beagleboard.org> wrote:
> > > For what it is worth, I tested the board that Eelco returned. After a
> > week
> > > of trying to make it fail, I could not. So, I had them send a new one,
> > which
> > > is the one he is referring to.
> > > Gerald
> > > On Tue, May 19, 2009 at 9:58 AM, eelcor <eelco.r...@gmail.com> wrote:
> > > > Hi,
> > > > There has been quite a thread about the disconnect problem of the USB.
> > > > I've had similar problems and I decided to return the board.
> > > > Thankfully I just (well half an hour ago) received a new board and it
> > > > works! Somehow I have the feeling that the tolerances on the board are
> > > > slightly off and some people have problems with their USB.
> > > > I am not sure whether the reported problems are solved by replacing
> > > > the board or that some kind of software trick could work as well. I am
> > > > very happy at this moment as I can show my company tomorrow what the
> > > > potential future of computing could be.
> > > > I would recommend to read the thread started by me (something with USB
> > > > and disconnect), because some people have given tips and tricks that
> > > > could help...
> > > > > I'm getting similar issues with USB, almost only when creating heavy
> > > > traffic
> > > > > like file transfers. The (powered) USB-HUB turns off all LEDs
> > (indicating
> > > > > connected devices), and I've to reset the board to get it back
> > running.
> > > > > Connected to the USB hub is a WIFI adapter and an USB memory stick.
> > > > > I've a, not fully related, follow-up question; How to build a newer
> > > > kernel
> > > > > revision with BitBake/OpenEmbedded? When I build the kernel some
> > version
> > > > > with some patches are build, where to define that the latest is
> > build?
> > > > > > I've seen a number of people having problems with the USB host port
> > > > > > (EHCI) on
> > > > > > the Rev C beagleboards. I seem to be having the same problem and
> > > > > > after a few
> > > > > > days of random lockups, I found I can easily reproduce it by
> > reading
> > > > > > data
> > > > > > from a USB disk with dd. After a few seconds of I/O I get the
> > > > > > following:
> > > > > > And the usb devices are dead from then on - unplugging and
> > re-plugging
> > > > > > aren't
> > > > > > noticed, lsusb locks up or just reports the two (EHCI & MUSB) root
> > > > > > hubs.
> > > > > > This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash
> > > > > > drive.
> > > > > > The same happens with every kernel I've tried - the angstrom demos,
> > > > > > the Rev C
> > > > > > validation images, the ones fromhttp://
> >www.rcn-ee.com/deb/kernel/and > > > > > > ones
> > > > > > I've built myself from the OpenEmbedded patches. (2.6.28 and
> > 2.6.29).
> > > > > > I've also updated u-boot from 2009.01-dirty (as supplied) to
> > 2009.03.
> > > > > > I've tried with a couple of power supplies, USB power and also with
> > > > > > several
> > > > > > hubs (and no hub).
> > > > > > Is there anything else I can try to fix this?
> > > > > > Thanks
> > > > > > Rob- Tekst uit oorspronkelijk bericht niet weergeven -
> > > > > - Tekst uit oorspronkelijk bericht weergeven -
Thank you for returning a new board, as somehow all problems have been
solved. I have no idea what the main difference is, but now I am able
to copy a 350MB file from USB stick to MMC (Í've tried several things
and it didn't work at all with my old board) and when running the
chameleon man demo the USB keeps on working. And the board now is
perfectly stable with one of my crappiest psu's. Quite strange...
Do you think tolerances could be the explanation? As people who have
read my thread might know, I've gone to quite some lengths to assure
that it was a HW faillure. Maybe there is some sensitive point in the
current design?
Regards, Eelco
On 19 mei, 17:27, Gerald Coley <ger...@beagleboard.org> wrote:
> For what it is worth, I tested the board that Eelco returned. After a week
> of trying to make it fail, I could not. So, I had them send a new one, which
> is the one he is referring to.
> Gerald
> On Tue, May 19, 2009 at 9:58 AM, eelcor <eelco.r...@gmail.com> wrote:
> > Hi,
> > There has been quite a thread about the disconnect problem of the USB.
> > I've had similar problems and I decided to return the board.
> > Thankfully I just (well half an hour ago) received a new board and it
> > works! Somehow I have the feeling that the tolerances on the board are
> > slightly off and some people have problems with their USB.
> > I am not sure whether the reported problems are solved by replacing
> > the board or that some kind of software trick could work as well. I am
> > very happy at this moment as I can show my company tomorrow what the
> > potential future of computing could be.
> > I would recommend to read the thread started by me (something with USB
> > and disconnect), because some people have given tips and tricks that
> > could help...
> > > I'm getting similar issues with USB, almost only when creating heavy
> > traffic
> > > like file transfers. The (powered) USB-HUB turns off all LEDs (indicating
> > > connected devices), and I've to reset the board to get it back running.
> > > Connected to the USB hub is a WIFI adapter and an USB memory stick.
> > > I've a, not fully related, follow-up question; How to build a newer
> > kernel
> > > revision with BitBake/OpenEmbedded? When I build the kernel some version
> > > with some patches are build, where to define that the latest is build?
> > > > I've seen a number of people having problems with the USB host port
> > > > (EHCI) on
> > > > the Rev C beagleboards. I seem to be having the same problem and
> > > > after a few
> > > > days of random lockups, I found I can easily reproduce it by reading
> > > > data
> > > > from a USB disk with dd. After a few seconds of I/O I get the
> > > > following:
> > > > And the usb devices are dead from then on - unplugging and re-plugging
> > > > aren't
> > > > noticed, lsusb locks up or just reports the two (EHCI & MUSB) root
> > > > hubs.
> > > > This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash
> > > > drive.
> > > > The same happens with every kernel I've tried - the angstrom demos,
> > > > the Rev C
> > > > validation images, the ones fromhttp://www.rcn-ee.com/deb/kernel/and > > > > ones
> > > > I've built myself from the OpenEmbedded patches. (2.6.28 and 2.6.29).
> > > > I've also updated u-boot from 2009.01-dirty (as supplied) to 2009.03.
> > > > I've tried with a couple of power supplies, USB power and also with
> > > > several
> > > > hubs (and no hub).
> > > > Is there anything else I can try to fix this?
> > > > Thanks
> > > > Rob- Tekst uit oorspronkelijk bericht niet weergeven -
> > > - Tekst uit oorspronkelijk bericht weergeven -- Tekst uit oorspronkelijk bericht niet weergeven -
I agree that it could have something to do with tolerances and slight
board variations. I couldn't solve the problems myself with 5
different kernel versions,3 different MMC cards, 3 different PSU's, 3
different keyboard/mouse combo's, 3 different USB keys and a single
USB to ethernet interface. At a certain point I really didn't have any
options, so I was happy with the suggestion of Gerald to return the
board and thankfully it has solved my problems. Currently I am really
happy as I am able to show my company that the cutting edge of mobile
processors is able to replace simple desktop machines.
Regards, Eelco
On 19 mei, 19:04, alexey <azapa...@gmail.com> wrote:
> I'll try it with the best power supply i got. I power radio receivers
> from it.
> On May 19, 12:06 pm, Gerald Coley <ger...@beagleboard.org> wrote:
> > DigiKey does not handle the repairs. RMAs are through beagleboard.org.
> > We have no board to replace anyones boards at the moment. Fell free to send
> > them back and in another 3-4 weeks we will have replacements to send you.
> > As I already siad, the board that was returned did not fail. I tested it
> > myself So, it is unclear that simply getting a new board will fix anyones
> > problems. It could be related to a noisy power supply where some board are
> > more tolerant than others of this noise.
> > Gerald
> > On Tue, May 19, 2009 at 11:02 AM, alexey <azapa...@gmail.com> wrote:
> > > Does that mean i should return board to Digikey and request new one ?
> > > On May 19, 11:27 am, Gerald Coley <ger...@beagleboard.org> wrote:
> > > > For what it is worth, I tested the board that Eelco returned. After a
> > > week
> > > > of trying to make it fail, I could not. So, I had them send a new one,
> > > which
> > > > is the one he is referring to.
> > > > Gerald
> > > > On Tue, May 19, 2009 at 9:58 AM, eelcor <eelco.r...@gmail.com> wrote:
> > > > > Hi,
> > > > > There has been quite a thread about the disconnect problem of the USB.
> > > > > I've had similar problems and I decided to return the board.
> > > > > Thankfully I just (well half an hour ago) received a new board and it
> > > > > works! Somehow I have the feeling that the tolerances on the board are
> > > > > slightly off and some people have problems with their USB.
> > > > > I am not sure whether the reported problems are solved by replacing
> > > > > the board or that some kind of software trick could work as well. I am
> > > > > very happy at this moment as I can show my company tomorrow what the
> > > > > potential future of computing could be.
> > > > > I would recommend to read the thread started by me (something with USB
> > > > > and disconnect), because some people have given tips and tricks that
> > > > > could help...
> > > > > > I'm getting similar issues with USB, almost only when creating heavy
> > > > > traffic
> > > > > > like file transfers. The (powered) USB-HUB turns off all LEDs
> > > (indicating
> > > > > > connected devices), and I've to reset the board to get it back
> > > running.
> > > > > > Connected to the USB hub is a WIFI adapter and an USB memory stick.
> > > > > > I've a, not fully related, follow-up question; How to build a newer
> > > > > kernel
> > > > > > revision with BitBake/OpenEmbedded? When I build the kernel some
> > > version
> > > > > > with some patches are build, where to define that the latest is
> > > build?
> > > > > > > I've seen a number of people having problems with the USB host port
> > > > > > > (EHCI) on
> > > > > > > the Rev C beagleboards. I seem to be having the same problem and
> > > > > > > after a few
> > > > > > > days of random lockups, I found I can easily reproduce it by
> > > reading
> > > > > > > data
> > > > > > > from a USB disk with dd. After a few seconds of I/O I get the
> > > > > > > following:
> > > > > > > And the usb devices are dead from then on - unplugging and
> > > re-plugging
> > > > > > > aren't
> > > > > > > noticed, lsusb locks up or just reports the two (EHCI & MUSB) root
> > > > > > > hubs.
> > > > > > > This happens with 2 USB disks: a 250Gb hard disk and a 4Gb flash
> > > > > > > drive.
> > > > > > > The same happens with every kernel I've tried - the angstrom demos,
> > > > > > > the Rev C
> > > > > > > validation images, the ones fromhttp://
> > >www.rcn-ee.com/deb/kernel/and > > > > > > > ones
> > > > > > > I've built myself from the OpenEmbedded patches. (2.6.28 and
> > > 2.6.29).
> > > > > > > I've also updated u-boot from 2009.01-dirty (as supplied) to
> > > 2009.03.
> > > > > > > I've tried with a couple of power supplies, USB power and also with
> > > > > > > several
> > > > > > > hubs (and no hub).
> > > > > > > Is there anything else I can try to fix this?
> > > > > > > Thanks
> > > > > > > Rob- Tekst uit oorspronkelijk bericht niet weergeven -
> > > > > > - Tekst uit oorspronkelijk bericht weergeven -- Tekst uit oorspronkelijk bericht niet weergeven -
I think we may have a random noise issue that may be locking up something.
Unfortuantely, until I can get something to fail, I can't do an analysis on
what is going on. I certainly can't afford to transfer large files multiples
of time in production, or we will be shipping 50 boards a week. We are
chasing a similar issue on another board inside TI at the moment. It is a
lot worse than Beagle. I am hoping that we can get some inforamtion from
there. They are looking at a noisy 1.8V rail to see if that may be the
issue. I hope to get some feedback soon on their progress.
On Tue, May 19, 2009 at 12:16 PM, eelcor <eelco.r...@gmail.com> wrote:
> I agree that it could have something to do with tolerances and slight
> board variations. I couldn't solve the problems myself with 5
> different kernel versions,3 different MMC cards, 3 different PSU's, 3
> different keyboard/mouse combo's, 3 different USB keys and a single
> USB to ethernet interface. At a certain point I really didn't have any
> options, so I was happy with the suggestion of Gerald to return the
> board and thankfully it has solved my problems. Currently I am really
> happy as I am able to show my company that the cutting edge of mobile
> processors is able to replace simple desktop machines.
> Regards, Eelco
> On 19 mei, 19:04, alexey <azapa...@gmail.com> wrote:
> > I'll try it with the best power supply i got. I power radio receivers
> > from it.
> > On May 19, 12:06 pm, Gerald Coley <ger...@beagleboard.org> wrote:
> > > DigiKey does not handle the repairs. RMAs are through beagleboard.org.
> > > We have no board to replace anyones boards at the moment. Fell free to
> send
> > > them back and in another 3-4 weeks we will have replacements to send
> you.
> > > As I already siad, the board that was returned did not fail. I tested
> it
> > > myself So, it is unclear that simply getting a new board will fix
> anyones
> > > problems. It could be related to a noisy power supply where some board
> are
> > > more tolerant than others of this noise.
> > > Gerald
> > > On Tue, May 19, 2009 at 11:02 AM, alexey <azapa...@gmail.com> wrote:
> > > > Does that mean i should return board to Digikey and request new one ?
> > > > On May 19, 11:27 am, Gerald Coley <ger...@beagleboard.org> wrote:
> > > > > For what it is worth, I tested the board that Eelco returned. After
> a
> > > > week
> > > > > of trying to make it fail, I could not. So, I had them send a new
> one,
> > > > which
> > > > > is the one he is referring to.
> > > > > Gerald
> > > > > On Tue, May 19, 2009 at 9:58 AM, eelcor <eelco.r...@gmail.com>
> wrote:
> > > > > > Hi,
> > > > > > There has been quite a thread about the disconnect problem of the
> USB.
> > > > > > I've had similar problems and I decided to return the board.
> > > > > > Thankfully I just (well half an hour ago) received a new board
> and it
> > > > > > works! Somehow I have the feeling that the tolerances on the
> board are
> > > > > > slightly off and some people have problems with their USB.
> > > > > > I am not sure whether the reported problems are solved by
> replacing
> > > > > > the board or that some kind of software trick could work as well.
> I am
> > > > > > very happy at this moment as I can show my company tomorrow what
> the
> > > > > > potential future of computing could be.
> > > > > > I would recommend to read the thread started by me (something
> with USB
> > > > > > and disconnect), because some people have given tips and tricks
> that
> > > > > > could help...
> > > > > > > I'm getting similar issues with USB, almost only when creating
> heavy
> > > > > > traffic
> > > > > > > like file transfers. The (powered) USB-HUB turns off all LEDs
> > > > (indicating
> > > > > > > connected devices), and I've to reset the board to get it back
> > > > running.
> > > > > > > Connected to the USB hub is a WIFI adapter and an USB memory
> stick.
> > > > > > > I've a, not fully related, follow-up question; How to build a
> newer
> > > > > > kernel
> > > > > > > revision with BitBake/OpenEmbedded? When I build the kernel
> some
> > > > version
> > > > > > > with some patches are build, where to define that the latest is
> > > > build?
> > > > > > > > I've seen a number of people having problems with the USB
> host port
> > > > > > > > (EHCI) on
> > > > > > > > the Rev C beagleboards. I seem to be having the same problem
> and
> > > > > > > > after a few
> > > > > > > > days of random lockups, I found I can easily reproduce it by
> > > > reading
> > > > > > > > data
> > > > > > > > from a USB disk with dd. After a few seconds of I/O I get
> the
> > > > > > > > following:
> > > > > > > > And the usb devices are dead from then on - unplugging and
> > > > re-plugging
> > > > > > > > aren't
> > > > > > > > noticed, lsusb locks up or just reports the two (EHCI & MUSB)
> root
> > > > > > > > hubs.
> > > > > > > > This happens with 2 USB disks: a 250Gb hard disk and a 4Gb
> flash
> > > > > > > > drive.
> > > > > > > > The same happens with every kernel I've tried - the angstrom
> demos,
> > > > > > > > the Rev C
> > > > > > > > validation images, the ones fromhttp://
> > > >www.rcn-ee.com/deb/kernel/and > > > > > > > > ones
> > > > > > > > I've built myself from the OpenEmbedded patches. (2.6.28 and
> > > > 2.6.29).
> > > > > > > > I've also updated u-boot from 2009.01-dirty (as supplied) to
> > > > 2009.03.
> > > > > > > > I've tried with a couple of power supplies, USB power and
> also with
> > > > > > > > several
> > > > > > > > hubs (and no hub).
> > > > > > > > Is there anything else I can try to fix this?
> > > > > > > > Thanks
> > > > > > > > Rob- Tekst uit oorspronkelijk bericht niet weergeven -
> > > > > > > - Tekst uit oorspronkelijk bericht weergeven -- Tekst uit
> oorspronkelijk bericht niet weergeven -
> > - Tekst uit oorspronkelijk bericht weergeven -
I'm glad the new hardware was able to fix the problem. Boy, I hate
problems that are hard to reproduce. One possibility in this case is
a timing problem somewhere in the logic where a signal ALMOST has
sufficient set-up time for a clock. Most of the time it works, but a
voltage dip or temperature increase causes the signal to be missed, or
worse, become metastable. (I never metastable I liked.) Sometimes
this can be fixed in software -- perhaps there is a signal that could
be sampled on the opposite edge of the clock, providing a stable
signal at all times. Sometime software can perform extra reads on a
metastable register: the first to see if it has changed at all, and a
second read to see which value it really changed to.
One reason the new board could work while the old one failed is that a
component on the new board is just enough faster or slower so that the
timing issue does not occur -- or is so rare that nobody observes it.
For example, a different voltage regulator or passives can generate a
voltage that is a percent higher or lower... just enough to expose or
hide the timing issue.
I think I mentioned in the other stream a problem I had with a board
that would fail after a couple hours, and only at high temperature.
That was nasty to find. Turned out to have an easy software solution,
so happy ending!
These issues are tough to track down. Funny thing is that there are only two
components in the circuit, OMAP and the SMSC PHY. This is a similar issue we
had on Port1 of the OMAP3530. When we moved to port2 it appeared to be
resolved. So, it may be an issue inside the OMAP or the PHY.
One thing we noticed on Port1 was that if we slowed down the processor, the
issue went away, even though the interface was still 60MHZ. Could someone
with a questionable board slow the processor speed down and see if that
affects the results?
On Tue, May 19, 2009 at 1:35 PM, John Beetem <johnbee...@yahoo.com> wrote:
> eelcor,
> I'm glad the new hardware was able to fix the problem. Boy, I hate
> problems that are hard to reproduce. One possibility in this case is
> a timing problem somewhere in the logic where a signal ALMOST has
> sufficient set-up time for a clock. Most of the time it works, but a
> voltage dip or temperature increase causes the signal to be missed, or
> worse, become metastable. (I never metastable I liked.) Sometimes
> this can be fixed in software -- perhaps there is a signal that could
> be sampled on the opposite edge of the clock, providing a stable
> signal at all times. Sometime software can perform extra reads on a
> metastable register: the first to see if it has changed at all, and a
> second read to see which value it really changed to.
> One reason the new board could work while the old one failed is that a
> component on the new board is just enough faster or slower so that the
> timing issue does not occur -- or is so rare that nobody observes it.
> For example, a different voltage regulator or passives can generate a
> voltage that is a percent higher or lower... just enough to expose or
> hide the timing issue.
> I think I mentioned in the other stream a problem I had with a board
> that would fail after a couple hours, and only at high temperature.
> That was nasty to find. Turned out to have an easy software solution,
> so happy ending!
> These issues are tough to track down. Funny thing is that there are only two
> components in the circuit, OMAP and the SMSC PHY. This is a similar issue we
> had on Port1 of the OMAP3530. When we moved to port2 it appeared to be
> resolved. So, it may be an issue inside the OMAP or the PHY.
> One thing we noticed on Port1 was that if we slowed down the processor, the
> issue went away, even though the interface was still 60MHZ. Could someone
> with a questionable board slow the processor speed down and see if that
> affects the results?
> Gerald
> On Tue, May 19, 2009 at 1:35 PM, John Beetem <johnbee...@yahoo.com> wrote:
> > eelcor,
> > I'm glad the new hardware was able to fix the problem. Boy, I hate
> > problems that are hard to reproduce. One possibility in this case is
> > a timing problem somewhere in the logic where a signal ALMOST has
> > sufficient set-up time for a clock. Most of the time it works, but a
> > voltage dip or temperature increase causes the signal to be missed, or
> > worse, become metastable. (I never metastable I liked.) Sometimes
> > this can be fixed in software -- perhaps there is a signal that could
> > be sampled on the opposite edge of the clock, providing a stable
> > signal at all times. Sometime software can perform extra reads on a
> > metastable register: the first to see if it has changed at all, and a
> > second read to see which value it really changed to.
> > One reason the new board could work while the old one failed is that a
> > component on the new board is just enough faster or slower so that the
> > timing issue does not occur -- or is so rare that nobody observes it.
> > For example, a different voltage regulator or passives can generate a
> > voltage that is a percent higher or lower... just enough to expose or
> > hide the timing issue.
> > I think I mentioned in the other stream a problem I had with a board
> > that would fail after a couple hours, and only at high temperature.
> > That was nasty to find. Turned out to have an easy software solution,
> > so happy ending!
We've just got a beagleboard at work (also rev C2) so I tried the same
test (dumping the contents of a USB disk) on both my board (which I
was using in my original email) and work's board. Mine always fails
after a minute or so, but the work's one doesn't show any error and I
was able to read the disk several times over (a total of about 40Gb of
data) without a problem. Everything was the same apart from the board
(i.e. same power supply, SD card, kernel, u-boot, NAND contents - both
in factory state) - so it definitely looks like a hardware issue.
How would I go about changing the clock speed to see if that fixes
anything?
Regards
Rob
On May 19, 7:46 pm, Gerald Coley <ger...@beagleboard.org> wrote:
> These issues are tough to track down. Funny thing is that there are only two
> components in the circuit, OMAP and the SMSC PHY. This is a similar issue we
> had on Port1 of the OMAP3530. When we moved to port2 it appeared to be
> resolved. So, it may be an issue inside the OMAP or the PHY.
> One thing we noticed on Port1 was that if we slowed down the processor, the
> issue went away, even though the interface was still 60MHZ. Could someone
> with a questionable board slow the processor speed down and see if that
> affects the results?
> Gerald
> On Tue, May 19, 2009 at 1:35 PM, John Beetem <johnbee...@yahoo.com> wrote:
> > eelcor,
> > I'm glad the new hardware was able to fix the problem. Boy, I hate
> > problems that are hard to reproduce. One possibility in this case is
> > a timing problem somewhere in the logic where a signal ALMOST has
> > sufficient set-up time for a clock. Most of the time it works, but a
> > voltage dip or temperature increase causes the signal to be missed, or
> > worse, become metastable. (I never metastable I liked.) Sometimes
> > this can be fixed in software -- perhaps there is a signal that could
> > be sampled on the opposite edge of the clock, providing a stable
> > signal at all times. Sometime software can perform extra reads on a
> > metastable register: the first to see if it has changed at all, and a
> > second read to see which value it really changed to.
> > One reason the new board could work while the old one failed is that a
> > component on the new board is just enough faster or slower so that the
> > timing issue does not occur -- or is so rare that nobody observes it.
> > For example, a different voltage regulator or passives can generate a
> > voltage that is a percent higher or lower... just enough to expose or
> > hide the timing issue.
> > I think I mentioned in the other stream a problem I had with a board
> > that would fail after a couple hours, and only at high temperature.
> > That was nasty to find. Turned out to have an easy software solution,
> > so happy ending!
> These issues are tough to track down. Funny thing is that there are only two > components in the circuit, OMAP and the SMSC PHY. This is a similar issue we > had on Port1 of the OMAP3530. When we moved to port2 it appeared to be > resolved. So, it may be an issue inside the OMAP or the PHY.
> One thing we noticed on Port1 was that if we slowed down the processor, the > issue went away, even though the interface was still 60MHZ. Could someone > with a questionable board slow the processor speed down and see if that > affects the results?
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).
I have a RevC board that very repeatably fails with a "hub 1-0:1.0:
port 2 disabled by hub (EMI?), re-enabling... " message. The board is
powered by a 5V 2A switching power supply. It is connected to a USB
2.0 hub which is itself powered by a 2A power supply.
I have tried an experiment where I put the board into a cold chamber,
took it to 0C, and ran the same test - to the same result. I don't see
any significant variance in the time to failure. This would tend to
exclude any marginal timing issues that are exacerbated by low
temperature.
I could get a heat-gun and run the other side of the test if anybody
thinks that would be useful.
I assume you've tried different peripherals (USB device and USB hub) to rule out it being the USB device itself and/or the hub...? What about the other ports on the hub...? Do they drop out too...?
> Date: Thu, 4 Jun 2009 08:12:24 -0700
> Subject: [beagleboard] Re: USB EHCI problems
> From: david.hag...@aeroflex.com
> To: beagleboard@googlegroups.com
> I have a RevC board that very repeatably fails with a "hub 1-0:1.0:
> port 2 disabled by hub (EMI?), re-enabling... " message. The board is
> powered by a 5V 2A switching power supply. It is connected to a USB
> 2.0 hub which is itself powered by a 2A power supply.
> I have tried an experiment where I put the board into a cold chamber,
> took it to 0C, and ran the same test - to the same result. I don't see
> any significant variance in the time to failure. This would tend to
> exclude any marginal timing issues that are exacerbated by low
> temperature.
> I could get a heat-gun and run the other side of the test if anybody
> thinks that would be useful.
On Jun 4, 4:17 pm, Michael Evans <horse_d...@hotmail.com> wrote:
> I assume you've tried different peripherals (USB device and USB hub) to rule out it being the USB device itself and/or the hub...? What about the other ports on the hub...? Do they drop out too...?
The USB port on the Beagleboard dies as do all the ports on the hub -
after that, unplugging and plugging back in the hub does nothing: only
a reboot will restore the port.
I've already tried a couple of hubs, and I could get the failures on
both heavy access to a USB memory stick and to a USB to Ethernet
adapter.
Right now we are performing experiments with my Beagleboard in one of
our environmental chambers: we are currently running it at 0C to
reproduce my tests, but in moving the board to the chamber we
unavoidably had to change the configuration, so we are sequencing
through:
Different hubs.
Different power supplies.
Different devices on the bus in addition to the memory stick (mouse,
Ethernet device), etc.
Presence/absence of a device on the HDMI port.
Right now, things aren't failing - which is puzzling because I had a
100% reproducibility before. However, that might be a GOOD thing if I
can work out what variable caused the change.
If I can't get it to start failing, I'll try to get to exactly the
configuration I had in my office, then start simplifying. Failing
that, I'll take the chamber back to 20C, and then up to 40C.
Hopefully we can characterize this enough to at least make it
reproducible.
> On Jun 4, 4:17 pm, Michael Evans <horse_d...@hotmail.com> wrote:
> > I assume you've tried different peripherals (USB device and USB hub) to
> rule out it being the USB device itself and/or the hub...? What about the
> other ports on the hub...? Do they drop out too...?
> The USB port on the Beagleboard dies as do all the ports on the hub -
> after that, unplugging and plugging back in the hub does nothing: only
> a reboot will restore the port.
> I've already tried a couple of hubs, and I could get the failures on
> both heavy access to a USB memory stick and to a USB to Ethernet
> adapter.
> Right now we are performing experiments with my Beagleboard in one of
> our environmental chambers: we are currently running it at 0C to
> reproduce my tests, but in moving the board to the chamber we
> unavoidably had to change the configuration, so we are sequencing
> through:
> Different hubs.
> Different power supplies.
> Different devices on the bus in addition to the memory stick (mouse,
> Ethernet device), etc.
> Presence/absence of a device on the HDMI port.
> Right now, things aren't failing - which is puzzling because I had a
> 100% reproducibility before. However, that might be a GOOD thing if I
> can work out what variable caused the change.
> If I can't get it to start failing, I'll try to get to exactly the
> configuration I had in my office, then start simplifying. Failing
> that, I'll take the chamber back to 20C, and then up to 40C.
> Hopefully we can characterize this enough to at least make it
> reproducible.
The board will be replaced and your board will be evaluated along with the
other two boards we have. On the other two boards, we could not get them to
fail, but in both those cases, the replacement boards worked fine. So, this
is not something that is in all boards,
Gerald
On Fri, Jun 5, 2009 at 10:08 AM, David Hagood <david.hag...@aeroflex.com>wrote:
> 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?
On Jun 4, 5:18 pm, Gerald Coley <ger...@beagleboard.org> wrote:
> Request an RMA immediately!
> Gerald
(NOTE: I pulled my previous message, as I had a couple of errors in it
that I wanted to correct...)
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.
On Jun 5, 10:12 am, Gerald Coley <ger...@beagleboard.org> wrote:
> The board will be replaced and your board will be evaluated along with the
> other two boards we have. On the other two boards, we could not get them to
> fail, but in both those cases, the replacement boards worked fine. So, this
> is not something that is in all boards,
> Gerald
Yes, that checks with the boards we have - mine dies, a couple of
others don't. I'd like to try to get as much information as possible
to allow others to have a better shot at reproducing the problems.
Is there anything I should check on the two boards I have (e.g. lot
numbers on the boards and/or parts) that would be of use in
troubleshooting this?
