[Gllug] Bashing my head on Kernel Build FC1 2.4.26-1

[Ken Smith]

That's how it feels anyway! I'm not really a Kernel builder BUT I have a
system with an ASUS P4P800 MB that has a 'normal' IDE controller with 2
channels and a VIA 6410 one, that's supposed to support RAID, with another 2
channels. There's also a SATA controller that I'm not currently using, nor
am I bothering with RAID on the 6410. I've since discovered that Linux is a
very low (read that as 'tending to zero') priority to VIA and their driver
support is only a binary driver and some bit of C code that you can compile
to make a module. That works, but the performance is 9 x slower than the VIA
windows driver accessing the same data on the same disk. Copying the same 1G
file takes 42 secs on windows and 6 mins 15 secs on Linux with the VIA
driver. The performance hit is a problem because I want to do multi-track
music work on the system. So I have been testing a Kernel patch I found that
is supposed to make the normal IDE driver in the Kernel able to work the VIA
IDE device. I have been in touch with some folks who have successfully got
it working - so the patch works but not on this system - now I'm stumped.

Here is the problem. Having applied the patch, I can see the changes in the
three source files it is supposed to alter. The kernel seems to build fine
and it boots fine. But no access to the VIA IDE controller. Obviously the
basic IDE driver is working or it would never boot up.

LSPCI shows the device but dmesg does not show the kernel finding it at
bootup. It shows Ide0 and ide1 but not 2 or 3. 

dmesg (full thing attached) has this line just after the IDE initialization
that might be a clue

SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2

whereas booting an otherwise unhacked kernel has this line

md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.

Not surprisingly, hdparm denies all knowledge of the device. Is there
something that I can do to prod about in the kernel to see why it can't see
the device? Various flavours of Windoze on that system can drive it just
fine. (but the software I want to use is open source!) So the hardware/BIOS
is OK. 

I have commented out the line in rc.local that loads the VIA proprietary
module. But the only thing I can think of is that because I have previously
installed/used the VIA proprietary driver that the VIA install process has
somehow knackered that systems ability to find the device. Is there
somewhere in the init process where I can look for that? Or would I be
better to wipe that partition and start again? But that's a Windoze approach
and I'd rather find the problem and fix it without resorting trashing the
whole system and re-installing. Is there some way to turn on more detailed
logging of the init process or to check in the built kernel that the patched
code made it all the way to the binary file. dmesg shows the right kernel
build date and there are no obvious errors in the build process. Many moons
ago (1980's) I did hardware/driver development for some real time systems -
this feels like that. I want to put a trap in the code somewhere and prod
about in the tables/stack to see if the right things are happening - trace
the code step by step. But I haven't time to undertake that level of kernel
development/debugging these days.

Ideas on kernel driver loading/debugging most welcome

Ken



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmesg.txt
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20041101/66641ed6/attachment.txt>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug