Well, I tested md5sum and still got the wrong sums. But, testing on two other computers, the md5sum is correct. Hmmm.
A couple of items of good news:
1. video=640x480 works (doesn't in 184.108.40.206 kernel)
2. OpenOffice works (doesn't in 220.127.116.11 kernel).
Tonight I will compile the 18.104.22.168 kernel.
Comments:Posted on 21 Oct 2010, 8:15 by BarryK
I compiled that kernel, and success, md5sum works.
However, the 22.214.171.124-kernel md5sum bug only occurs on certain hardware, a PC with SiS chips (I tested on two others, with Intel chips and they were ok). lspci reports:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX Host (rev 11)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (rev 25)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 91)
01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600 GT] (rev a2)
I am testing booting off a USB Flash stick.
But there is bad news. The 126.96.36.199 kernel has only one patch, it reverts an earlier patch that is reported to break some USB interfaces.
But in my case the reversion has broken things.
So, it is a no-win situation, and I will have to contact the kernel developers pronto.
Posted on 22 Oct 2010, 8:20 by BarryK
I am conducting an experiment. I have been in contact with one of the kernel developers and he is puzzled that I have trouble with 188.8.131.52 as it only reverts one very small patch. He has requested that I get in contact with some other developers, but I have been looking at it...
Here is the changelog for 184.108.40.206:
Revert "USB delay init quirk for logitech Harmony 700-series devices"
This reverts commit 631b2d37894bb2a891d8897e1861362a23dde4d9.
It was found to cause a number of USB devices to not work properly
because we call usb_disable_autosuspend too soon. This is not an issue
with any other kernel version.
Here is the patch in question:
...well, I am far from an expert here, but it seems to me that moving the call to function usb_detect_quirks() to a different place in the code is what has broken other USB interfaces.
That patch was applied back in the 220.127.116.11 kernel, and it also seems to me that just reverting a patch like that could break things. Other patches applied since 18.104.22.168 are maybe depending on usb_detect_quirks() being in the new location. This could be a very subtle problem.
..Am I too naive? It just seems to me, from the point of view of someone unfamiliar with managing a project with thousands of patches being submitted, that just taking out an old one is asking for trouble.
Anyway, I thought that I would take a punt. I don't know, I haven't studied the code in depth, maybe this will break something... I have restored the original call to usb_detect_quirks(), in the 22.214.171.124 code, so it is now called in two places.
I'm compiling it now, let's see what happens.
Posted on 22 Oct 2010, 14:43 by BarryK
Special 126.96.36.199 seems ok
My "special" hacked 188.8.131.52 seems ok. Reckon I will go for this one for the next Wary.
Posted on 23 Oct 2010, 8:01 by BarryK
184.108.40.206 special patch
As I say, I am blundering in here, knowing nothing about this code, just a superficial assessment, but this is my "special" patch:
The official 220.127.116.11 patch breaks some hardware. It only reverts
a patch that was in 18.104.22.168, but I have my own replacement for the
22.214.171.124 patch: do this manually, to file
# diff -u hub.cORIG hub.c
--- hub.cORIG 2010-10-20 20:18:19.000000000 +0800
+++ hub.c 2010-10-22 07:46:03.000000000 +0800
@@ -1791,6 +1791,7 @@
+ usb_detect_quirks(udev); /*BK*/
err = usb_enumerate_device(udev); /* Read descriptors */
if (err < 0)