Missing IDE driver

[KingOfDos]

We (a little community within the Netherlands) have a few (~10) old computers. Something 'they' call a laptop, but it will crush your lap (seriously!) after a couple of minutes. It's mend as "almost" all-weather-conditions-pc.

The problem with linux atm is, that they removed our IDE driver from the kernel. And there are many users with exact this hardware setup. I've already tried a few old linux distro's, but nothing usefull. Most (if not all of them) "netboots" won't work, because the age, and incomplete mirrors).

This is the hardware info from the BIOS (and HDT gives the same information):
IDE interface [0101]: ALi Coporation MS4803 [10b9:5215]

The kernel versions that support the needed hardware lay between 2.3.27 and 2.6.14-rc2, as far I can tell. Based on this:

http://www.linuxhq.com/kernel/v2.3/27/drivers/pci/pci.ids
+5215 MS4803

http://www.linuxhq.com/kernel/v2.6/14-rc2/drivers/pci/pci.ids
-5215 MS4803

I'm hoping that you (the TCL team) can create a patch for us, so we could use any future TCL without the need for everyone to compile there own stuff.
ATM the only way for me to use this machine, is to PXE-boot the ISO file (using gPXE). Because non of the up2date distro's will support this IDE card. That's quite useless seen a portable setup (where you don't want to PXE boot everything).

The main reason for me to use TCL is the old hardware. It's an Pentium 1, 200MHz. 64mb ram. TCL works really fast at this setup! But I don't have the knowledge to compile my own kernel (modules) to solve this problem. So i'm really hoping that the community will help me (and thereby others!).

[^thehatsrule^]

If it was actually removed from upstream kernel, there would probably be a good reason for it.  However, the removal of that file from that location doesn't mean much.

Is there anything relevant in `dmesg`?  Does the device have a raid controller?

[curaga]

Shouldn't it run with the generic ide driver, even if there's no proper one?

[KingOfDos]

If it was actually removed from upstream kernel, there would probably be a good reason for it.  However, the removal of that file from that location doesn't mean much.

Sure, if they removed it from the kernel, there will be a good reason for it. But for me as linux user (on kernel level) it's sometimes quite annoying to see that they've changed things again. Ok, I should stop with speculating, hehe.

Is there anything relevant in `dmesg`?  Does the device have a raid controller?

dmesg located here: http://kingofdos.com/zooi/dmesg-for-old-embedded-device.log
[added with edit]
And I'd see this line: Uniform Multi-Platform E-IDE driver
That's odd tbh. I'd even see some /dev/hda (and hda[1-9]{1}) and /dev/hdb (and hdb[1-9]{1}), but those are from the ramdrive (fdisk and cfdisk can't access it, so I guess it's not the IDE drive but ram).
[/added with edit]

The devices is build with embedded hardware, so there's nothing I'd can change (except the pcmcia card, floppy, hdd and battery pack). There is also 1 16bit ISA slot containing a 4 port serial card (as far dmesg can tell, custom connector+stuff).
And there is a SCSI card, that's only available through the backside of the laptop. There is NO option within the bios (or hardware jumper as far I can tell) to disable the SCSI card.

We checked a couple of BIOSes, to see if there are any differences. But all the devices have the same (or at least for the most important) settings within the BIOS/CMOS (except booting order, and other non-hardware specific changes).

Shouldn't it run with the generic ide driver, even if there's no proper one?

That's what I was thinking. It's just an IDE driver, and even GRUB/etc are working with the controller. So why the real kernel isn't doing the same (at any distro!!)?

Is it for example possible to change the /lib/modules/2.6.*/modules.pcilist (or whatever the filename is exactly, tabcompletion ftw), so I could add the PCI ID to a generic driver? Yes it's possible, but the question is more like: Is it usefull to try this? Because I've got to unpack the ISO, change it and repack it.

But again, I'd don't know the linux kernel very good. I'm a webdeveloper who can install and maintain many services and create my own applications. But trying to find a solution for this (kernel) issue is new for me.

[curaga]

As mentioned in the dmesg, try this boot option:

ide_generic.probe_mask=0x3f

The generic driver has no pci ids set, it should take over if there's no native driver. If it's an ISA chip, it might not be able to without the param above.

[KingOfDos]

It worked, thanks for that. Only, from that point the mouse seems broken.

I'm still seeing the mouse within /proc/bus/input/devices, witch differs time to time (depending on the information I'd entered in xsetup). After changing the mouse configuration within xsetup. I'd restarted the x-thingy by killing / reopening it. But no luck. Still no working mouse.
I'd see nothing special when I'd compare the dmesg. http://kingofdos.com/zooi/dmesg-no-mouse.log
And after unplugging the keyboard+mouse (1 cable+connector) there is no update within udev.

Also. After I'd try to setup with an 500MB partition, something went wrong at the setup. But that's another story, and I'd guess that I'd made a user error somewhere. I'd now get "mount: mounting /dev/hda1 on /mnt/hda1 failed: Invalid argument", so can't (yet) test xsetup with an full-reboot.

At this point I've created an script to create the PXE env, including customization of the TCL ISO. It's working really good if you'd ask me (damn fast, hehe).

[edit]wth, i've never quoted myself. sorry[/edit]

[tinypoodle]

Code: [Select]

sudo cat /dev/mouse
sudo cat /dev/mouse0
Any output if you move the mouse or click?

(Ctrl+C to exit)

[KingOfDos]

There is no /dev/mouse or /dev/mouse0. I've got an /dev/input/mouse0, /dev/input/mice and /dev/input/event0, but when i'd cat them as root I'm not getting any data. There is a /dev/psaux, but it's the same result as the others (no output via cat). Via /dev/input/event1 I'm getting some data when I'd press key's on the keyboard.

I've got an "mouse lock" button, when I'd turn that function of, the mouse sents up/down/left/right keypresses (because that keys are not on the keyboard in another form, only within the mouse).

All I'd know about the mouse, is that it's an trackball, with 3 buttons. On the same bus as the keyboard. I guess it's using the same chip within the keyboard enclosure, seen the "mouse lock" button + effects.

I'm currently testing with a few other probe_mask's. With 0x2 the computer resets itself at a random point. And while testing the memory (POST) it gives an "Memory error". But the mouse worked at that point, no disk. I'm going to test 0x1 atm (will edit this post in a few sec)

[tinypoodle]

if the cat can't catch the mouse, bothering with X about mouse is futile.

When you get the POST "Memory error" poweroff for a few secs.

Running memtest86 on an old box couldn't harm in any case.

[KingOfDos]

if the cat can't catch the mouse, bothering with X about mouse is futile.

Indeed, that's why I'd started to search on another lever, after the suggestion of catting the inputs.

When you get the POST "Memory error" poweroff for a few secs.

Indeed, but it should not happen. It's because TCL crashes.

Running memtest86....

At the first "Memory error" this was indeed the thing I did. It completed 15 times without any error, so I'm sure it's within TCL somewhere (at least "with this very specific strange hardware situation").

Based on the fact that the mouse stopped working, after using the probe_mask. I'd started to search how that worked, and what it did. Now I'm using ide_generic.probe_mask=0x1, to only toggle the first IDE port (master+slave), instead of just everything without the knowledge if it's there.

And then: Whooo! Now I've got an working IDE drive and an working mouse! I'd hope that TCL stays stable (now I've solved the hardware issues, or at least I'd think). Nope. Not "stable". Still rebooting at random moments just after a fresh boot from ISO. Most of the time when I'd move the mouse (over an icon within the menu-thingy, but can also happen at other early moving, random over the desktop). But that's something for tomorrow, It's already 05:00 (AM) local time.

Thanks all, for the help (so far, hehe). The suggestions gave me enough search keywords to solve this problem.

old box

Sure, but only used for 740.4 HR, that's 30 days (for an 10 year old device, that's quite nice I'd think).

[curaga]

Ah, the nice times of prodding ISA ports...

Anyway, it's a bad interaction with the kernel, your bios, and your mouse now. I suggest opening a bug at the kernel bugzilla.