Re: Weird behaviour
On Sat, Feb 25, 2012 at 09:42:36AM -0500, Kevin Gordon wrote: I think we can close the book on this. Today, all of the USB ports on one just stopped working altogether for anything, not even a little mouse when plugging in gives any result. The second one is now reliably showing in dmesg that it is running full-speed not high speed. So, it's h/w. [...] I agree. My guess is that ESD damage had led to a gradual decline in performance, and eventual failure. This is consistent with how ESD damage may present. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Weird behaviour
On Sat, Feb 18, 2012 at 04:33:12PM -0500, Kevin Gordon wrote: On Tue, Feb 14, 2012 at 5:18 PM, James Cameron qu...@laptop.org wrote: For your interest, next time you need it, there's an OpenFirmware test feature for checking the fs-update transfer rates from USB. ok null-fsdisk fs-update u:\fs.zd [...] I upgraded the firmware to Q3C01, which eliminated the write-block-start and finish not unique messages. However invoking the command null-fsdisk fs-update u:\os883.zd4 (which is the build we use on these machines and is teh file on the USB drive) gives the following warnings on the good (reference) XO 1.5: Image size is larger than output device Thanks. Fixed in next release. The null device had a zero size, and so anything except a zero size input file triggered this abort. The fix [1] sets the null device to 32GB size. In the meanwhile, should you still wish to test the performance of fs-update without eMMC or microSD writes: ok dev /null : size 0 8 ; dend size isn't unique ok null-fsdisk fs-update u:\os883.zd4 file said highest block 29849 but wrote only as high as block 0 file did not write a zero block, but wrote only as low as block 29489 These messages are a consequence of the abort, and therefore can be ignored. In the absence of this abort, the messages may be important. The test using null-fsdisk only neuters the write to eMMC or microSD, and the .zd file is still read and decompressed. On an XO-1.75 using null-fsdisk, the fs-update reduced from 5:05 to 4:36, which shows that most of the time cost is the decompression. The same file read in without decompression [2] cost 1:26. References: 1. http://tracker.coreboot.org/trac/openfirmware/changeset/2870 2. http://wiki.laptop.org/go/Forth_Lesson_23#read_a_large_file -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Weird behaviour
On Tue, Feb 21, 2012 at 12:39:43PM +1100, James Cameron wrote: On an XO-1.75 using null-fsdisk, the fs-update reduced from 5:05 to 4:36, which shows that most of the time cost is the decompression. The same file read in without decompression [2] cost 1:26. That result was using a different method to what fs-update uses, so I redid the test with the same method [1]. The result was 27 seconds. References: 1. http://wiki.laptop.org/go/Forth_Lesson_23#read_a_.zd_file -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Weird behaviour
On Tue, Feb 14, 2012 at 5:18 PM, James Cameron qu...@laptop.org wrote: I agree, it seems likely to be a hardware problem with USB. You said file copy from USB to the filesystem was just as slow. Is that using OpenFirmware or Linux? I'm expecting you used Linux. Linux We made some USB changes in OpenFirmware, but these ought not to have had this effect, and should have no effect at all on Linux. Yet, I am interested to know what version of OpenFirmware is on the units. -- For your interest, next time you need it, there's an OpenFirmware test feature for checking the fs-update transfer rates from USB. ok null-fsdisk fs-update u:\fs.zd I did the following to try to establish a reference point on a perfectly good XO 1.5 with functioning USB I upgraded the firmware to Q3C01, which eliminated the write-block-start and finish not unique messages. However invoking the command null-fsdisk fs-update u:\os883.zd4 (which is the build we use on these machines and is teh file on the USB drive) gives the following warnings on the good (reference) XO 1.5: Image size is larger than output device file said highest block 29849 but wrote only as high as block 0 file did not write a zero block, but wrote only as low as block 29489 00:00:00 What it does is read the data from USB and then discard it. That way you can exclude the time otherwise spent writing to the internal microSD or eMMC. The feature was recently fixed (10th Feb 2012) so use firmware after that date. I didn't go back to find when it broke. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Weird behaviour
Sounds like a signal integrity issue is forcing the USB to run at 10 Mbps on those two laptops. Have you tried another USB stick ? Or different ports on the malfunctioning laptops ? There is little on the motherboard which can affect these ports --- they run from the connector to the Via companion chip (VX855). Perhaps this is due to ESD damage of the VX855 itself... Regards, wad On Feb 14, 2012, at 8:47 AM, Kevin Gordon wrote: No, this email is not about my generally weird behaviour, it's about a couple of my new XO 1.5's :-) I have 2 x XO 1.5's that seem to have a very slow USB transfer rate; like, I mean glacial. I use the same USB build sticks to build many XO 1.5's, but on these particular two it takes close to an hour to do a refresh, or sometimes just stops in the middle of the refresh block colour animation - regardless of the stick used. I have many times verified that the same sticks refresh in normal time, on about 8 other 1.5s. All the XO's are currently at the default 883 build with q3b11 when doing this refresh test. I then suspected maybe main memory, but then a refresh from the SD card slots on these same two suspect machines is lightning fast, (in fact way faster than I've ever seen using USB), and the machine seems to be successfully built. However, I've also then done just a USB copy from another stick down to the file system, and it too is really, really slow, if and when when it finishes. The standard short-cut key at boot-time diagnostics show no errors. Any hints? Thanks KG ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Weird behaviour
On Tue, Feb 14, 2012 at 11:43 AM, John Watlington w...@laptop.org wrote: Sounds like a signal integrity issue is forcing the USB to run at 10 Mbps on those two laptops. Have you tried another USB stick ? Or different ports on the malfunctioning laptops ? All three ports act on each machine act consistently. All 10 USB sticks act consistently. There is little on the motherboard which can affect these ports --- they run from the connector to the Via companion chip (VX855). Perhaps this is due to ESD damage of the VX855 itself... I have spare machines, would you be interested in my sending these back to you for investigation? I can mail them down, my cost. KG Regards, wad On Feb 14, 2012, at 8:47 AM, Kevin Gordon wrote: No, this email is not about my generally weird behaviour, it's about a couple of my new XO 1.5's :-) I have 2 x XO 1.5's that seem to have a very slow USB transfer rate; like, I mean glacial. I use the same USB build sticks to build many XO 1.5's, but on these particular two it takes close to an hour to do a refresh, or sometimes just stops in the middle of the refresh block colour animation - regardless of the stick used. I have many times verified that the same sticks refresh in normal time, on about 8 other 1.5s. All the XO's are currently at the default 883 build with q3b11 when doing this refresh test. I then suspected maybe main memory, but then a refresh from the SD card slots on these same two suspect machines is lightning fast, (in fact way faster than I've ever seen using USB), and the machine seems to be successfully built. However, I've also then done just a USB copy from another stick down to the file system, and it too is really, really slow, if and when when it finishes. The standard short-cut key at boot-time diagnostics show no errors. Any hints? Thanks KG ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Weird behaviour
I agree, it seems likely to be a hardware problem with USB. You said file copy from USB to the filesystem was just as slow. Is that using OpenFirmware or Linux? I'm expecting you used Linux. We made some USB changes in OpenFirmware, but these ought not to have had this effect, and should have no effect at all on Linux. Yet, I am interested to know what version of OpenFirmware is on the units. -- For your interest, next time you need it, there's an OpenFirmware test feature for checking the fs-update transfer rates from USB. ok null-fsdisk fs-update u:\fs.zd What it does is read the data from USB and then discard it. That way you can exclude the time otherwise spent writing to the internal microSD or eMMC. The feature was recently fixed (10th Feb 2012) so use firmware after that date. I didn't go back to find when it broke. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
