> Only that, apparently, "setserial" would not change a wrong IRQ > definition set for the kernel
Yes it will. That's what it does. > that one is done with installing a > distro for instance - when there's the "networking" section to fill > in(*) Bullshit, sir. The kernel defaults to the commonly used values at boot, and setserial is used to configure them as needed within the system boot scripts. In Slackware, for instance, that's in /etc/rc.d/rc.serial. > My question was where exactly this IRQ definition resides, and if > there was any means to change it _after_ "the system" has been > installed.(**) Distribution specific. It's in an init script somewhere, most probably. It will *not* be in the kernel *anywhere*, and recompiling that will not help. Try grepping your startup scripts for setserial to see if you can find it; 'grep setserial /etc/rc.d/*' perhaps, but I rarely use Mandrake and frankly your attitude dissuades me from bothering to boot a Mandrake VM to find out where it keeps its scripts. > In the specific case, with an IRQ 7 used for serial com4, there's > still another complication: There is a second parallel (printer) port in > that machine (not used/connected to something; and jumper-set to another > IRQ), though default value for this is usually set to IRQ 7, and thus > probably even assumed by [the kernel?]. > No idea if this could confuse "setserial" or whatever. Probably. All setserial is is a wrapper around the serial device configuration ioctl function, which'll return an error if some other driver has claimed the specified IRQ. You should see this shown as "File or device busy" or somesuch, I believe. Try 'cat /proc/interrupts', which'll list all the IRQs the kernel is watching and the device which is handling them. If you see something on IRQ7, that might be why setserial is failing, but you should have seen an error message in that case. Then run 'setserial /dev/ttyS3' to see what the ttyS3 driver is configured for. 'setserial /dev/ttyS3 irq 7' ought then change the IRQ, and 'setserial /dev/ttyS3' again to confirm it. If you could post the output of those four commands, we might be able to see why it's not working. If you continue to rant on about how we're being unreasonable, then I'm sure you can work out what to do on your own. Regards, Ben A L Jemmett. (http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/) To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with unsubscribe SURVPC in the body of the message. Also, trim this footer from any quoted replies. More info can be found at; http://www.softcon.com/archives/SURVPC.html
