Kevanf1 wrote:

On 29/04/06, Hylton Conacher (ZR1HPC) wrote:

...

I would like to move the Ensonique on-board sound device to another IRQ but do not know how. What is the 'correct' IRQ for sound devices? I think it was 15 but I would prefer to leave te ide items alone.

Would moving eth0 to a different PCI slot help?

I thought sound cards normally defaulted to IRQ5 You might be able to change the IRQ settings through the BIOS. I seem to recall that on some BIOS's the IRQs are locked down but can be altered.

As Kevan said, probably in the BIOS. There may also be a jumper or dip switch setting on the sound card that will alter the factory shipped default IRQ. James W.

On Saturday 29 April 2006 8:21 am, Hylton Conacher (ZR1HPC) wrote:

I have a 9.2 system here where the network card(Realtek 8139) and the on-board sound have the same IRQ.

I know this because it is mentioned when I boot the machine on the listing of the HDDs cofigured in the BIOS. In addition RTFM indicated that the procinfo command shows the IRQs, relevant details pasted below:

irq 0: 1495304 timer irq 9: 690 uhci_hcd, uhci_hcd irq 1: 1881 i8042 irq 10: 14983 eth0, Ensoniq AudioP irq 2: 0 cascade [4] irq 11: 0 acpi irq 3: 102 irq 12: 37136 i8042 irq 4: 8 irq 14: 13890 ide0 irq 6: 14 irq 15: 18097 ide1

I would like to move the Ensonique on-board sound device to another IRQ but do not know how. What is the 'correct' IRQ for sound devices? I think it was 15 but I would prefer to leave te ide items alone.

Would moving eth0 to a different PCI slot help?

Don't bother. Unless you can actually prove a problem with IRQ sharing, it doesn't matter. That is why you see the longer PCI hardware ID in which include PCI bus #, slot#, position on the bus, etc. The actual IRQ is just another reference point or differentiator along the way. Pre-1999/2000, the older systems at that time needed correct IRQ settings and usually would not share IRQs. That is really old-school these days. You may run into this on pre-400-500 MHz systems but it is less of an issue, especially in Linux, because the PCI routines are much better about uniquely identifying each piece of hardware. There is no single, correct and 'Industry Standard' IRQ for sound devices. That is dependent on the mainboard hardware, BIOS and how it is presented to the operating system. Once ID'd, Linux gives it a unique ID to reference it in the future. Moving eth0 to another PCI slot may change its IRQ but the system and OS may keep it at 5 anyway. Again, don't bother. Unless there is a known conflict you can actually 'prove' is happening because sound and eth0 are sharing an IRQ it doesn't matter. It used to matter about 10 years ago... Stan

On Sunday 30 April 2006 14:16, Sunny wrote:

Ok, lets say I have "proven" problem. Actually the problem is with the mobo and the chipset (it is SiS, and there are some problems), but I guess if I can move the sound on another irq, it'll work ... so, what's the way to change the assigned irq by the driver/kernel?

Hi Sunny, Would you care to share the mainboard model and chipset numbers (and revision, if appropriate?) I apologize in advance if you've posted this already, but I sometimes seem to have a very 'twitchy' delete key finger! ;-) regards, Carl

On 4/30/06, Carl Hartung wrote:

On Sunday 30 April 2006 14:16, Sunny wrote:

...

Ok, lets say I have "proven" problem. Actually the problem is with the mobo and the chipset (it is SiS, and there are some problems), but I guess if I can move the sound on another irq, it'll work ... so, what's the way to change the assigned irq by the driver/kernel?

Hi Sunny,

Would you care to share the mainboard model and chipset numbers (and revision, if appropriate?) I apologize in advance if you've posted this already, but I sometimes seem to have a very 'twitchy' delete key finger! ;-)

regards,

Carl

Hi Carl, the machine is Compaq Presario SR1710NR, Sempron 3400+, Asus mobo with SiS chipset ASUS A8AE-LE. Here is a link to mobo specs on hp site: http://h10025.www1.hp.com/ewfrf/wc/document?lc=en&cc=us&dlc=en&product=1817035&docname=c00496280 So, the problem is that the APIC kernel support for this mb is kind of shaky. Most of the devices (incl. sound, network, etc.) share the same IRQ. Even if I disable the onboard sound and put another one (tried with PCI and USB), it hooks up them to tre same IRQ. And I can not use the mike - it breaks after 2-3 sec of working, I tried skype, and other recording programs. I tried both 64 and 32 bit SuSE 10, Knoppix 32 bit. It is always the same. I know from the kernel lists that there is a problem with the APIC support for some SiS mobo's, so I hope that if I can set the IRQ for the sound to something else, it may work. Cheers Sunny -- Svetoslav Milenov (Sunny) Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit operating system originally coded for a 4-bit microprocessor by a 2-bit company that can't stand 1 bit of competition.

On 5/1/06, S Glasoe wrote:

Changing an IRQ like that has to be supported in the BIOS. On your system that could be either the embedded soundcard's IRQ or the NIC's PCI slot IRQ. If there isn't support in the BIOS for changing a specific piece of hardware's IRQ then your choice is to have the BIOS changed. So either you or someone else or Compaq or SiS must 'fix' the BIOS or work the driver/kernel idea.

Asus does not offer updates for "custom" boards they make for OEMs. Compaq does not have newer bios either :(

Have you tried acpi=off? Is there a setting for 'PnP OS' in your BIOS (should be set to 'Not a PnP OS' for Linux)? Do you have options for different APIC settings in the BIOS such as 1.0 versus 1.1. or whatever and have you tried them?

PnP is off in BIOS. ACPI=off does not allow boot at all, it freezes. noapic and nolapic settings does some weird things to the overall performance. It makes the ping timeout for the onboard NIC from the machine to the router, or any other machine on my network to become 500+ ms, while if I do not use noapic or nolapic, it is 0.5 ms. I assume that it completely messes up the IRQs if I disable APIC. And ... it does not help the sound problem at all. I guess this is a kernel/driver problem, so maybe I should post on some kernel list. Anyway, it does not answer the OP question - is there a way to make the kernel to assign a specific IP to a device.

The problem may not be IRQ related. It could be that ACPI support is flakey for your mainboard and not providing enough information for drivers to differentiate all the hardware into unique PCI IDs. The correct PCI bus#, PCI slot#, position on PCI bus, IRQ, I/O pot, etc may not be correct. That could eventually be fixed by driver/kernel updates. SUSE used to have information about dumping APCI data and sending it to them to try to get these types of things fixed... can't find it now that bugzilla is available! I'll keep looking...

Please do. I tried as well, but still can not find it.

Stan

-- -- Svetoslav Milenov (Sunny) Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit operating system originally coded for a 4-bit microprocessor by a 2-bit company that can't stand 1 bit of competition.

S Glasoe wrote:

On Saturday 29 April 2006 8:21 am, Hylton Conacher (ZR1HPC) wrote:

...

I have a 9.2 system here where the network card(Realtek 8139) and the on-board sound have the same IRQ.

I know this because it is mentioned when I boot the machine on the listing of the HDDs cofigured in the BIOS. In addition RTFM indicated that the procinfo command shows the IRQs, relevant details pasted below:

irq 0: 1495304 timer irq 9: 690 uhci_hcd, uhci_hcd irq 1: 1881 i8042 irq 10: 14983 eth0, Ensoniq AudioP irq 2: 0 cascade [4] irq 11: 0 acpi irq 3: 102 irq 12: 37136 i8042 irq 4: 8 irq 14: 13890 ide0 irq 6: 14 irq 15: 18097 ide1

I would like to move the Ensonique on-board sound device to another IRQ but do not know how. What is the 'correct' IRQ for sound devices? I think it was 15 but I would prefer to leave te ide items alone.

Would moving eth0 to a different PCI slot help?

Don't bother. Unless you can actually prove a problem with IRQ sharing, it doesn't matter. That is why you see the longer PCI hardware ID in which include PCI bus #, slot#, position on the bus, etc. The actual IRQ is just another reference point or differentiator along the way.

Pre-1999/2000, the older systems at that time needed correct IRQ settings and usually would not share IRQs. That is really old-school these days. You may run into this on pre-400-500 MHz systems but it is less of an issue, especially in Linux, because the PCI routines are much better about uniquely identifying each piece of hardware.

There is no single, correct and 'Industry Standard' IRQ for sound devices. That is dependent on the mainboard hardware, BIOS and how it is presented to the operating system. Once ID'd, Linux gives it a unique ID to reference it in the future.

Moving eth0 to another PCI slot may change its IRQ but the system and OS may keep it at 5 anyway. Again, don't bother. Unless there is a known conflict you can actually 'prove' is happening because sound and eth0 are sharing an IRQ it doesn't matter. It used to matter about 10 years ago... Tnx, Now I feel old as the knowledge I have is about 10-15yrs old.

I'll have a look at the BIOS but otherwise I hope it is not going to be problems.

On Monday 01 May 2006 10:39 am, Sunny wrote:

...

SUSE used to have information about dumping APCI data and sending it to them to try to get these types of things fixed... can't find it now that bugzilla is available! I'll keep looking...

Please do. I tried as well, but still can not find it.

...

Stan

Sunny

Gotta love that support between manufacturers on those low-cost OEM mainboards. Don't know how deep you want to get into this and I have no idea if the following will help at all but . . . Found it! From Phillip Thomas of SUSE dated May 1, 2003... "In order to be able to expand the blacklist (as well as the whitelist) for the kernel, we need to know on which systems the problems occur. Therefore, please send an e-mail message to acpi@suse.de. Tell us which kernel parameter(s) worked on your system. (Please include the output of the diagnosis tools acpidmp and dmidecode in your message. These tools are available at ftp.suse.com/pub/people/ak/diag.)" And from the README at that ftp site: "acpidmp and dmidecode are useful for diagnosing ACPI boot problems. Newer versions of these tools can be found in the pmtools rpm in recent SUSE distributions. pmtools also includes additional tools like an AML disassembler and compiler." The acpidmp and dmidecode programs are what I was thinking of to attach to a bugzilla report. Phillip also had an http://www.suse.de/en/private/products/suse_linux/i386/acpi.html page once upon a time when you could reach the SUSE employee's corporate web pages that had some more info. Stan

On Monday 01 May 2006 6:32 am, Darryl Gregorash wrote:

...

I have a 9.2 system here where the network card(Realtek 8139) and the on-board sound have the same IRQ. If either of the devices is a busmaster, then it should not matter if

On 29/04/06 07:21, Hylton Conacher (ZR1HPC) wrote: they share the irq. One of my network cards is a busmaster, and my sound card, both network cards, and USB are all on the same irq with no problems.

...

Would moving eth0 to a different PCI slot help? If it is a busmaster, the preferred place is in slot 0.

I have a laptop (a Dell Inspiron 1000) with apparent IRQ conflicts, but I obviously can't move cards around -- and on this particular machine, the brain-damaged BIOS has no facilities for tinkering with IRQs. The symptom is peculiar: KDE hangs on bootup if my network wireless card is inserted and runs fine if it isn't. But if I insert the card once KDE has started, both KDE and networking are happy. Paul

On 01/05/06 10:35, Hylton Conacher (ZR1HPC) wrote:

...

Moving eth0 to another PCI slot may change its IRQ but the system and OS may keep it at 5 anyway. Again, don't bother. Unless there is a known conflict you can actually 'prove' is happening because sound and eth0 are sharing an IRQ it doesn't matter. It used to matter about 10 years ago... Tnx, Now I feel old as the knowledge I have is about 10-15yrs old. If you have any meaningful knowledge about 10-15 year olds, please share with the rest of us -- I am sure all parents will be grateful :-D

But I don't think these are IRQ conflicts, most likely they are simple i/o errors.

On 01/05/06 13:19, S Glasoe wrote:

On Monday 01 May 2006 11:35 am, Hylton Conacher (ZR1HPC) wrote:

...

S Glasoe wrote:

...

Moving eth0 to another PCI slot may change its IRQ but the system and OS may keep it at 5 anyway. Again, don't bother. Unless there is a known conflict you can actually 'prove' is happening because sound and eth0 are sharing an IRQ it doesn't matter. It used to matter about 10 years ago...

Tnx, Now I feel old as the knowledge I have is about 10-15yrs old.

I'll have a look at the BIOS but otherwise I hope it is not going to be problems.

Know exactly how that feels. How old is this hardware? You mention that it matters in Windows which IRQ is set so which version of Windows was that and was it running on this same hardware? You may have hardware and BIOS that require setting IRQs but that, in general, is going to be more than 6-8 years old. Back in the day when ISA/EISA was transitioning to PCI, IRQ settings mattered because most add-in cards had hardware jumpers for IRQ. PCI allowed those hardware settings to be put into firmware on the cards and the system/BIOS and discovered by operating systems so physical intervention and its risk of static electricity death could be avoided, conflicts over sharing of limited IRQs could be resolved via software, less labor intensive, more automation via operating system, etc.

Actually, the problem of IRQ conflict is a serious hardware design issue (he says, thinking fondly back to the days of undergrad electonics, when popping transistors could be heard throughout the undergrad lab), rather than a problem with the actual bus design. In the early days, and through most of the life of the ISA bus, peripheral cards used a reverse-biased TTL (transistor-to-transistor logic) to assert/deassert the IRQ line. To deassert an IRQ line, a card had to open the circuit (ie ground it). If another card on the same IRQ line then tried to assert the line (ie close the circuit), the first one would find its transistors overloaded, and they could burn out. The cheap ones (like the ones they gave us to playwith in undergrad physics labs) invariably did. With open-collector logic, which is mostly used now, these considerations do not arise. The open (grounded) collector on the transistor is a natural IRQ deassert, and the current levels involved when some other card tries to assert the line are not sufficient to cause an overload, because the transistor never has to be reverse-biased to perform its tasks. For non-engineers, think of reverse-biasing as sort of like trying to push on a door that says "Pull" -- you probably aren't going anywhere, but if you do, the door's going to break first.

Darryl Gregorash wrote:

On 29/04/06 07:21, Hylton Conacher (ZR1HPC) wrote:

...

I have a 9.2 system here where the network card(Realtek 8139) and the on-board sound have the same IRQ.

If either of the devices is a busmaster, then it should not matter if they share the irq. One of my network cards is a busmaster, and my sound card, both network cards, and USB are all on the same irq with no problems.

...

Would moving eth0 to a different PCI slot help?

If it is a busmaster, the preferred place is in slot 0. And I would easily be able to pick up that the device is a busconductor ie how do I determine this?

On Tuesday 02 May 2006 6:45 am, Darryl Gregorash wrote:

On 01/05/06 16:45, Paul W. Abrahams wrote:

...

I have a laptop (a Dell Inspiron 1000) with apparent IRQ conflicts, but I obviously can't move cards around -- and on this particular machine, the brain-damaged BIOS has no facilities for tinkering with IRQs. The symptom is peculiar: KDE hangs on bootup if my network wireless card is inserted and runs fine if it isn't. But if I insert the card once KDE has started, both KDE and networking are happy.

Paul

Am I correct in assuming, from what you say here, that the system will boot successfully to runlevel 3? If so, then I do not think this is a serious hardware conflict, if indeed it is a conflict at all. Rather, something somewhere in KDE is the problem. What that might be, I cannot say, but the SuSEplugger, if running, might be something to look at.

Yes, the system boots to runlevel 3 fine. I agree that the problem is probably KDE-related. As to suseplugger, I can't locate any docs on it, though I found the executable easily enough. I've seen it referred to many times -- but what does it do? Paul

-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

On Tuesday 02 May 2006 16:42, Paul W. Abrahams wrote:

Yes, the system boots to runlevel 3 fine. I agree that the problem is probably KDE-related. As to suseplugger, I can't locate any docs on it, though I found the executable easily enough. I've seen it referred to many times -- but what does it do?

Hi Paul, If the problem is booting with the network adapter in place causes KDE to "hang", here are some suggestions: First, give the system several minutes to time out, recover and attempt initializing again. Let it sit in the "hung" state for several minutes to see if it eventually sorts itself out. For clues about what may be causing the problem, look through /var/log/boot.msg and boot.omsg (the "o" for "old" meaning the previous boot.msg) Experiment with different boot parameters per my previous post in this thread to Sunny. Here's the link again: /usr/src/linux-{version}/Documentation/kernel-parameters.txt If you Google "suseplugger" you will get many, many hits. In short, it is meant to detect when new hardware is plugged into the system and, if configured accordingly, make that hardware available for use. I'm not sure suseplugger is related to your problem, though. regards, Carl

On Friday 05 May 2006 1:29 pm, Hylton Conacher (ZR1HPC) wrote:

Hardware is 3-4years old and motherboard has a single ISA slot, rest are PCI. Realtek NIC is in a PCI slot. Sound os on motherboard.

Nothing in the ISA slot? I would _guess_ that the BIOS would reserve an IRQ for the ISA slot once it knows what IRQ the ISA card wants/has/requires. That may be the only IRQ action this BIOS does.

2001/11/03 date of purchase.

New enough. Having the ISA slot is something. Once the system knows which IRQ the ISA slot/card has then I'd guess that all PCI slots and devices would share the remaining IRQs.

Had a look in the BIOS and didn't see specific settings for the sound IRQ and te networking IRQ. I did say that the BIOS must monitor the IRQ's, whatever that means as even after reboot the NIC and Sound still had the same IRQ.

Standard PCI, BIOS, IRQ interaction.

In conclusion it would seem I have bad hardware but then the IRQ's being the same doesn't if I am not using the ISA slot, and Linux 9.2 right?

I'd say it wasn't bad hardware. You just haven't figured out the unique challenge presented by this combination of hardware, BIOS and PCI cards. Newer Linux versions will help. I keep coming back to one of my first questions though. Think there has been 3 different threads based on IRQ settings. Can't keep them straight anymore. Does it matter if your devices share an IRQ? Or are you just fixated on trying to get each PCI or onboard device _not_ to share an IRQ? I know you may be getting an error message stating something about unknown parameters (IRQ being one of them) when loading a driver but my experience tells me that is just an old generic error message that can't be more specific. Its giving you a hint as to what to troubleshoot. Stan

On Sunday 07 May 2006 7:03 am, Hylton Conacher (ZR1HPC) wrote:

...

I keep coming back to one of my first questions though. Think there has been 3 different threads based on IRQ settings. Can't keep them straight anymore. Does it matter if your devices share an IRQ? Or are you just fixated on trying to get each PCI or onboard device _not_ to share an IRQ? I know you may be getting an error message stating something about unknown parameters (IRQ being one of them) when loading a driver but my experience tells me that is just an old generic error message that can't be more specific. Its giving you a hint as to what to troubleshoot.

Oooh, time for the deeep stuff :) I am more fixated on getting each device to have a single IRQ as I seem to remember from my past that having the same IRQ, on a Windows system anyway, would render either one or both of the devices inoperable ie they cannot both have the same request number to query the cpu.

Remember that there were never enough hardware based IRQs to go around to uniquely identify all the hardware people wanted to put into a PC. One manufacturer I worked at cascaded 3 Interrupt Controllers to get enough unique hardware IRQs to support their SCSI controllers and CPU boards. Most PCs used 1 or 2 Interrupt Controllers in the day when these were individual ICs and needed the mainboard real estate for connections. This was true in the deep, dark past of the early PCI days circa mid-90's to late-90's. Once PCI became the dominant slot standard for mainboards, PCI matured (got most of the nasty bugs out), PCI card manufacturers gained more experience and got their bugs worked out, and the OS vendors got things worked out then dedicated slots per IRQ weren't as necessary. Once all these players got it straight that PCI bus, slot, IRQ, I/O port, memory addresses, etc could all be used to uniquely identify devices things have gotten much better. What you are seeing now reminds you of those IRQ conflict days. I wager that what is really happening is that there is a driver issue where your particular mainboard and BIOS aren't helping with the unique identification of all the devices. The driver(s) and/or Linux kernel may not know about your hardware's idiosyncracies and therefore can't allow perfect operation.

Whilst I realise it probably doesn't matter on Linux and that a newer version would help and that it seems that both the network card and sound are basically operating, although not fantastically, there must be something in this IRQ thing as cpu's have not changed their operating habits since Linux arrived, I don't think?

Using Konppix or Ubuntu/Kubuntu to troubleshoot may show that all your hardware can work. Try the Live CD versions to see what happens. In regards to hardware not much may have changed. Its the software though that is changing more these days in regards to drivers, kernel drivers, BIOS and firmware updates, etc. If the developers know of an issue they can typically code for it.

I know its thinking outside of the box but it is interesting.

Whatever solves it! Stan