Re: [PATCH] compiler warning fix in aci.c
From: Anuradha Ratnaweera <[EMAIL PROTECTED]> > On Wed, 30 May 2001, Robert Siemer wrote: > > > > Following patch fixes a compiler warning in aci.c. > > > ... how about putting it inside an "#ifdef DEBUG"? > > > > This is exactly what I did some month ago with my little working > > tree. > > So will you be adding the "#ifdef" again? My next kernel patch for the aci will do so, or I'll remove some debugging code. - In any case I'll pay more attention to compiler warnings. As I'm currently short of time it will take some weeks... (The next patch will also include more RDS/RBDS code for the miroSOUND PCM20 radio) Bye, Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compiler warning fix in aci.c
From: Anuradha Ratnaweera <[EMAIL PROTECTED]> > On Wed, 30 May 2001, Anuradha Ratnaweera wrote: > > > Following patch fixes a compiler warning in aci.c. > > I can guess the usefullness of the functiion print_bits that would be > removed if my patch is applied. If this is so, how about putting it > inside an "#ifdef DEBUG"? This is exactly what I did some month ago with my little working tree. Anyway: are you using some aci-supported hardware? Which one? Bye, Robert PS: I'm not subscribed to linux-kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compiler warning fix in aci.c
From: Anuradha Ratnaweera [EMAIL PROTECTED] On Wed, 30 May 2001, Anuradha Ratnaweera wrote: Following patch fixes a compiler warning in aci.c. I can guess the usefullness of the functiion print_bits that would be removed if my patch is applied. If this is so, how about putting it inside an #ifdef DEBUG? This is exactly what I did some month ago with my little working tree. Anyway: are you using some aci-supported hardware? Which one? Bye, Robert PS: I'm not subscribed to linux-kernel. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compiler warning fix in aci.c
From: Anuradha Ratnaweera [EMAIL PROTECTED] On Wed, 30 May 2001, Robert Siemer wrote: Following patch fixes a compiler warning in aci.c. ... how about putting it inside an #ifdef DEBUG? This is exactly what I did some month ago with my little working tree. So will you be adding the #ifdef again? My next kernel patch for the aci will do so, or I'll remove some debugging code. - In any case I'll pay more attention to compiler warnings. As I'm currently short of time it will take some weeks... (The next patch will also include more RDS/RBDS code for the miroSOUND PCM20 radio) Bye, Robert - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] (2.4.2) aci.c, radio-miropcm20.c for miroSOUND cards
Hello! The patch is for miroSOUND sound cards. The corresponding driver files are aci.c and radio-miropcm20.c The latest is for 2.4.2 and can be found on: http://www.uni-karlsruhe.de/~Robert.Siemer/Private/ http://www.uni-karlsruhe.de/~Robert.Siemer/Private/aci-2.4.2.patch (61kB) Changes: aci.c -general clean-up and rewrite of aci.c for 2.4.x -added SMP safe locking -ioctl pointer bugfix -added (OSS-limited) equalizer support -better distinction of PCM1/PCM12/PCM20 for good mixer-labeling/mic-preamp/output-amplification handling -threw mad16 dependence away: no mixer-number hack anymore -'solo' mode doesn't need some private ioctl() anymore radio-miropcm20.c -removed unclear volume handling (maybe I add it later again) -added stereo/corrected mute handling -tune-ioctl() pays attention to different aci-versions -introduced TUNER_LOW for 50kHz steps -integrated lowlevel RDS routines, currently only for finegrained signal strength value other changes -documentation updates/corrections Bye, Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] (2.4.2) aci.c, radio-miropcm20.c for miroSOUND cards
Hello! The patch is for miroSOUND sound cards. The corresponding driver files are aci.c and radio-miropcm20.c The latest is for 2.4.2 and can be found on: http://www.uni-karlsruhe.de/~Robert.Siemer/Private/ http://www.uni-karlsruhe.de/~Robert.Siemer/Private/aci-2.4.2.patch (61kB) Changes: aci.c -general clean-up and rewrite of aci.c for 2.4.x -added SMP safe locking -ioctl pointer bugfix -added (OSS-limited) equalizer support -better distinction of PCM1/PCM12/PCM20 for good mixer-labeling/mic-preamp/output-amplification handling -threw mad16 dependence away: no mixer-number hack anymore -'solo' mode doesn't need some private ioctl() anymore radio-miropcm20.c -removed unclear volume handling (maybe I add it later again) -added stereo/corrected mute handling -tune-ioctl() pays attention to different aci-versions -introduced TUNER_LOW for 50kHz steps -integrated lowlevel RDS routines, currently only for finegrained signal strength value other changes -documentation updates/corrections Bye, Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix dependencies for radio-miropcm20
Hi Jocelyn! You wrote: > I made a very little patch to avoid > people complaining that the kernel doesn't compile > properly when trying to use radio miropcm20 driver. > (I've seen some of this in french newsgroups...) > -dep_tristate ' Miro PCM20 Radio' CONFIG_RADIO_MIROPCM20 > $CONFIG_VIDEO_DEV > +dep_tristate ' Miro PCM20 Radio' CONFIG_RADIO_MIROPCM20 > $CONFIG_VIDEO_DEV $CONFIG_SOUND_ACI_MIXER This was already discussed some days ago. Arjan said, that the miropcm20 question comes before the aci question, so this is useless. - Arjan, this is not true for 'make menuconfig' and 'make xconfig', isn't it? Anyway, this solution looks somewhat cleaner to me... But you can choose on your own: (: As the new maintainer I'm offering the patches on http://www.uni-karlsruhe.de/~Robert.Siemer/Private/ Jocelyn, as my patches also include bugfixes and enhancements (especially for the miroSOUND pcm20 radio), can you recommend these to the complaining people. - I want more testers and reports for my patches... Thanks, Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fix dependencies for radio-miropcm20
Hi Jocelyn! You wrote: I made a very little patch to avoid people complaining that the kernel doesn't compile properly when trying to use radio miropcm20 driver. (I've seen some of this in french newsgroups...) -dep_tristate ' Miro PCM20 Radio' CONFIG_RADIO_MIROPCM20 $CONFIG_VIDEO_DEV +dep_tristate ' Miro PCM20 Radio' CONFIG_RADIO_MIROPCM20 $CONFIG_VIDEO_DEV $CONFIG_SOUND_ACI_MIXER This was already discussed some days ago. Arjan said, that the miropcm20 question comes before the aci question, so this is useless. - Arjan, this is not true for 'make menuconfig' and 'make xconfig', isn't it? Anyway, this solution looks somewhat cleaner to me... But you can choose on your own: (: As the new maintainer I'm offering the patches on http://www.uni-karlsruhe.de/~Robert.Siemer/Private/ Jocelyn, as my patches also include bugfixes and enhancements (especially for the miroSOUND pcm20 radio), can you recommend these to the complaining people. - I want more testers and reports for my patches... Thanks, Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.1 -- Unresolved symbols in radio-miropcm20.o
> >Miles Lane <[EMAIL PROTECTED]> wrote: > >>depmod: *** Unresolved symbols in > >>/lib/modules/2.4.1/kernel/drivers/media/radio/radio-miropcm20.o > >>depmod: aci_write_cmd > >>depmod: aci_indexed_cmd > >>depmod: aci_write_cmd_d I made up an new patch for 2.4.1. You can find it on http://www.uni-karlsruhe.de/~Robert.Siemer/Private/ It works when: a) aci: modulemiropcm20: module b) aci: build in miropcm20: module c) aci: build in miropcm20: build in Violation to this table is still unchecked... Arjan, I want to include your #ifdef solution, but was unable to find it in 2.2.18... - And further: why did it remove somebody in 2.3.x? Also (at least) in the case of c) videodev_init() is called twice. - It does not hurt, but maybe someone can give me a hint why this happens... Ciao, Robert PS: Miles email address ([EMAIL PROTECTED]) is invalid, isn't it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.1 -- Unresolved symbols in radio-miropcm20.o
Miles Lane [EMAIL PROTECTED] wrote: depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/drivers/media/radio/radio-miropcm20.o depmod: aci_write_cmd depmod: aci_indexed_cmd depmod: aci_write_cmd_d I made up an new patch for 2.4.1. You can find it on http://www.uni-karlsruhe.de/~Robert.Siemer/Private/ It works when: a) aci: modulemiropcm20: module b) aci: build in miropcm20: module c) aci: build in miropcm20: build in Violation to this table is still unchecked... Arjan, I want to include your #ifdef solution, but was unable to find it in 2.2.18... - And further: why did it remove somebody in 2.3.x? Also (at least) in the case of c) videodev_init() is called twice. - It does not hurt, but maybe someone can give me a hint why this happens... Ciao, Robert PS: Miles email address ([EMAIL PROTECTED]) is invalid, isn't it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.1 -- Unresolved symbols in radio-miropcm20.o
From: "Ruurd A. Reitsma" <[EMAIL PROTECTED]> > >Miles Lane <[EMAIL PROTECTED]> wrote: > >>depmod: *** Unresolved symbols in > >>/lib/modules/2.4.1/kernel/drivers/media/radio/radio-miropcm20.o > >>depmod: aci_write_cmd > >>depmod: aci_indexed_cmd > >>depmod: aci_write_cmd_d > appearently Robert Siemer's patch didn't make it to the actual > kernel. He did change the config.in and made some changes to aci.c > to support his version of the firmware. He'll probably be happy to > maintain the driver since I threw out the pcm20 card. Many thanks, Ruurd, for mailing me, too! - I'm not reading linux-kernel completely and looked only for 'aci' is subjects... First, I've put up a new patch, so don't use this old one. Please read my post to linux-kernel: http://boudicca.tux.org/hypermail/linux-kernel/latest/0133.html Second, the described problem is solved: the functions don't exists anymore... (: Third, my patch still has the same problem. <-: As noted, try my patch only when aci and radio-pcm20 is selected as module. I will work on this issue. And I have a request to everyone owning a miroSOUND (or Cardinal Technologies) card: Please try my patch and send me the version line. Mine looks like: at 0x344 The patch has some enhancements over the original; read more in my first post: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0009.2/0260.html The plans for the future are a well done support of the RDS functions for the "PCM20 radio" and maybe an ALSA driver. This would help me to support the equalizer in the "PCM20 radio" better. Thanks, Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.1 -- Unresolved symbols in radio-miropcm20.o
From: "Ruurd A. Reitsma" [EMAIL PROTECTED] Miles Lane [EMAIL PROTECTED] wrote: depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/drivers/media/radio/radio-miropcm20.o depmod: aci_write_cmd depmod: aci_indexed_cmd depmod: aci_write_cmd_d appearently Robert Siemer's patch didn't make it to the actual kernel. He did change the config.in and made some changes to aci.c to support his version of the firmware. He'll probably be happy to maintain the driver since I threw out the pcm20 card. Many thanks, Ruurd, for mailing me, too! - I'm not reading linux-kernel completely and looked only for 'aci' is subjects... First, I've put up a new patch, so don't use this old one. Please read my post to linux-kernel: http://boudicca.tux.org/hypermail/linux-kernel/latest/0133.html Second, the described problem is solved: the functions don't exists anymore... (: Third, my patch still has the same problem. -: As noted, try my patch only when aci and radio-pcm20 is selected as module. I will work on this issue. And I have a request to everyone owning a miroSOUND (or Cardinal Technologies) card: Please try my patch and send me the version line. Mine looks like: ACI 0x07, id 6d/43 "m/C", (PCM20 radio) at 0x344 The patch has some enhancements over the original; read more in my first post: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0009.2/0260.html The plans for the future are a well done support of the RDS functions for the "PCM20 radio" and maybe an ALSA driver. This would help me to support the equalizer in the "PCM20 radio" better. Thanks, Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI IRQ routing problem in 2.4.0 (updated patch)
From: Martin Diehl <[EMAIL PROTECTED]> > On Mon, 29 Jan 2001, Linus Torvalds wrote: > Below is the updated patch. It should handle both (0x01/0x41 > like) mappings. I can (and did) only test the 0x01 case. > USBIRQ routing (0x62) supported, IDE/ACPI/DAQ untouched. I don't really understand your note above, but your patch alone does not fix my problem. - Linus diff over pci-irq.c does. The kernel still does not think what the bios states; it's like the vanilla 2.4.0 in this regard. (--> on my box: kernel panic after "modprobe usb-ohci && modprobe hid") Bye, Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI IRQ routing problem in 2.4.0
From: Linus Torvalds <[EMAIL PROTECTED]> > On Mon, 29 Jan 2001, Robert Siemer wrote: > > > > Further I always see '09' in the Configuration Space at Interrupt_Line > > (0x3c) for the 00:01.2 USB Controller. But 2.4.0 says: > > Interrupt: pin A routed to IRQ 12 > > while 2.4.0-test9 states: > > Interrupt: pin A routed to IRQ 9 > > Ahhah! > > I bet it's the code that goes through all PCI devices, and tries to find > devices that have the same "pirq" (aka "link") value in the tables. > > How about this patch? I bet that you'll get a message about pirq table > conflicts. Does USB end up working afterwards? The patch is good! (: Currently I'm using 2.4.0 with both the patch and the alternate pirq-sis-functions. Here some lines from the kernel after loading usb-ohci: usb.c: registered new driver hub IRQ for 00:01.2:0 -> PIRQ 01, mask 1eb8, excl -> newirq=9 -> got IRQ 12 PCI: Found IRQ 12 for device 00:01.2 PCI: The same IRQ used for device 00:01.1 IRQ routing conflict in pirq table for device 00:01.2 PCI: The same IRQ used for device 00:0c.0 usb-ohci.c: USB OHCI at membase 0xc8901000, IRQ 9 I send two diffs: the first of "dmesg" from a nonworking 2.4.0 to my current (working) kernel, the second of "lspci -vvvxxx" from a working 2.4.0-test9 to the working 2.4.0 I use now. Many thanks, Linus! Robert --- dmesg.2.4.0.alternate_sis_func Mon Jan 29 06:25:53 2001 +++ dmesg.2.4.0.alternate+traversepatch Mon Jan 29 17:16:57 2001 @@ -1,4 +1,4 @@ -Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #5 Mon Jan 29 06:19:16 CET 2001 +Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 +19990314/Linux (egcs-1.1.2 release)) #7 Mon Jan 29 15:44:39 CET 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) @@ -231,9 +231,10 @@ bttv: using 2 buffers with 2080k (4160k total) for capture BT848 and your chipset may not work together. bttv: Bt8xx card found (0). -IRQ for 00:09.0:0 -> PIRQ 04, mask 1eb8, excl -> newirq=11 -> got IRQ 11 -PCI: Found IRQ 11 for device 00:09.0 -PCI: The same IRQ used for device 00:09.1 +IRQ for 00:09.0:0 -> PIRQ 04, mask 1eb8, excl -> newirq=11 -> got IRQ 10 +PCI: Found IRQ 10 for device 00:09.0 +IRQ routing conflict in pirq table for device 00:09.0 +IRQ routing conflict in pirq table for device 00:09.1 bttv0: Bt878 (rev 2) at 00:09.0, irq: 11, latency: 32, memory: 0xe780 bttv0: subsystem: 0070:13eb => Hauppauge WinTV => card=10 bttv0: model: BT878(Hauppauge new (bt878)) [autodetected] @@ -279,9 +280,9 @@ ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 PCI: Enabling device 00:01.1 ( -> 0001) -IRQ for 00:01.1:0 -> PIRQ 01, mask 1eb8, excl -> newirq=12 -> got IRQ 12 -PCI: Found IRQ 12 for device 00:01.1 -PCI: The same IRQ used for device 00:01.2 +IRQ for 00:01.1:0 -> PIRQ 01, mask 1eb8, excl -> newirq=12 -> assigning IRQ 12 +... OK +PCI: Assigned IRQ 12 for device 00:01.1 +IRQ routing conflict in pirq table for device 00:01.2 PCI: The same IRQ used for device 00:0c.0 SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later --- lspci-vvvxxx.2.4.0-test9Mon Jan 29 07:43:27 2001 +++ lspci-vvvxxx.2.4.0.alternate+traversepatch Mon Jan 29 17:19:18 2001 @@ -27,8 +27,8 @@ 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -40: fa 0c 0e 0a 0b 64 00 00 ff ff 10 0f 11 20 04 01 -50: 11 28 02 01 60 0b 64 0b 9c 2e 12 00 a6 0b 00 00 +40: 0c 0c 0e 0a 0b 64 00 00 ff ff 10 0f 11 20 04 01 +50: 11 28 02 01 62 0b 64 0b 9c 2e 12 00 36 06 00 00 60: ff 80 49 00 88 00 00 02 00 80 80 00 20 19 00 00 70: 1a 00 00 c1 00 c1 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 @@ -40,7 +40,7 @@ e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -00:01.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8f [Master SecP SecO PriP PriO]) +00:01.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if +8a [Master SecP PriP]) Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Region 3: I/O ports at Region 4: I/O ports at d000 [size=16] -00: 39 10 13 55 01 00 00 00 d0 8f 01 01 00 20 80 00 +00: 39 10 13 55 01 00 00 00 d0 8a 01 01 00 20 80 00 10: 01 e4 00 00 01 e0 00 00 01 d8 00 00 01 d4 00 00 20: 01 d0 00 00 00 00 00
Re: PCI IRQ routing problem in 2.4.0
From: Linus Torvalds [EMAIL PROTECTED] On Mon, 29 Jan 2001, Robert Siemer wrote: Further I always see '09' in the Configuration Space at Interrupt_Line (0x3c) for the 00:01.2 USB Controller. But 2.4.0 says: Interrupt: pin A routed to IRQ 12 while 2.4.0-test9 states: Interrupt: pin A routed to IRQ 9 Ahhah! I bet it's the code that goes through all PCI devices, and tries to find devices that have the same "pirq" (aka "link") value in the tables. How about this patch? I bet that you'll get a message about pirq table conflicts. Does USB end up working afterwards? The patch is good! (: Currently I'm using 2.4.0 with both the patch and the alternate pirq-sis-functions. Here some lines from the kernel after loading usb-ohci: usb.c: registered new driver hub IRQ for 00:01.2:0 - PIRQ 01, mask 1eb8, excl - newirq=9 - got IRQ 12 PCI: Found IRQ 12 for device 00:01.2 PCI: The same IRQ used for device 00:01.1 IRQ routing conflict in pirq table for device 00:01.2 PCI: The same IRQ used for device 00:0c.0 usb-ohci.c: USB OHCI at membase 0xc8901000, IRQ 9 I send two diffs: the first of "dmesg" from a nonworking 2.4.0 to my current (working) kernel, the second of "lspci -vvvxxx" from a working 2.4.0-test9 to the working 2.4.0 I use now. Many thanks, Linus! Robert --- dmesg.2.4.0.alternate_sis_func Mon Jan 29 06:25:53 2001 +++ dmesg.2.4.0.alternate+traversepatch Mon Jan 29 17:16:57 2001 @@ -1,4 +1,4 @@ -Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #5 Mon Jan 29 06:19:16 CET 2001 +Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 +19990314/Linux (egcs-1.1.2 release)) #7 Mon Jan 29 15:44:39 CET 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) @@ -231,9 +231,10 @@ bttv: using 2 buffers with 2080k (4160k total) for capture BT848 and your chipset may not work together. bttv: Bt8xx card found (0). -IRQ for 00:09.0:0 - PIRQ 04, mask 1eb8, excl - newirq=11 - got IRQ 11 -PCI: Found IRQ 11 for device 00:09.0 -PCI: The same IRQ used for device 00:09.1 +IRQ for 00:09.0:0 - PIRQ 04, mask 1eb8, excl - newirq=11 - got IRQ 10 +PCI: Found IRQ 10 for device 00:09.0 +IRQ routing conflict in pirq table for device 00:09.0 +IRQ routing conflict in pirq table for device 00:09.1 bttv0: Bt878 (rev 2) at 00:09.0, irq: 11, latency: 32, memory: 0xe780 bttv0: subsystem: 0070:13eb = Hauppauge WinTV = card=10 bttv0: model: BT878(Hauppauge new (bt878)) [autodetected] @@ -279,9 +280,9 @@ ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 PCI: Enabling device 00:01.1 ( - 0001) -IRQ for 00:01.1:0 - PIRQ 01, mask 1eb8, excl - newirq=12 - got IRQ 12 -PCI: Found IRQ 12 for device 00:01.1 -PCI: The same IRQ used for device 00:01.2 +IRQ for 00:01.1:0 - PIRQ 01, mask 1eb8, excl - newirq=12 - assigning IRQ 12 +... OK +PCI: Assigned IRQ 12 for device 00:01.1 +IRQ routing conflict in pirq table for device 00:01.2 PCI: The same IRQ used for device 00:0c.0 SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later --- lspci-vvvxxx.2.4.0-test9Mon Jan 29 07:43:27 2001 +++ lspci-vvvxxx.2.4.0.alternate+traversepatch Mon Jan 29 17:19:18 2001 @@ -27,8 +27,8 @@ 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -40: fa 0c 0e 0a 0b 64 00 00 ff ff 10 0f 11 20 04 01 -50: 11 28 02 01 60 0b 64 0b 9c 2e 12 00 a6 0b 00 00 +40: 0c 0c 0e 0a 0b 64 00 00 ff ff 10 0f 11 20 04 01 +50: 11 28 02 01 62 0b 64 0b 9c 2e 12 00 36 06 00 00 60: ff 80 49 00 88 00 00 02 00 80 80 00 20 19 00 00 70: 1a 00 00 c1 00 c1 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 @@ -40,7 +40,7 @@ e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -00:01.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8f [Master SecP SecO PriP PriO]) +00:01.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if +8a [Master SecP PriP]) Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 12 @@ -49,7 +49,7 @@ Region 2: I/O ports at ignored Region 3: I/O ports at ignored Region 4: I/O ports at d000 [size=16] -00: 39 10 13 55 01 00 00 00 d0 8f 01 01 00 20 80 00 +00: 39 10 13 55 01 00 00 00 d0 8a 01 01 00 20 80 00 10: 01 e4 00 00 01 e0 00 00 01 d8 00 00 01 d4 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 0
Re: PCI IRQ routing problem in 2.4.0 (updated patch)
From: Martin Diehl [EMAIL PROTECTED] On Mon, 29 Jan 2001, Linus Torvalds wrote: Below is the updated patch. It should handle both (0x01/0x41 like) mappings. I can (and did) only test the 0x01 case. USBIRQ routing (0x62) supported, IDE/ACPI/DAQ untouched. I don't really understand your note above, but your patch alone does not fix my problem. - Linus diff over pci-irq.c does. The kernel still does not think what the bios states; it's like the vanilla 2.4.0 in this regard. (-- on my box: kernel panic after "modprobe usb-ohci modprobe hid") Bye, Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI IRQ routing problem in 2.4.0
From: Linus Torvalds <[EMAIL PROTECTED]> > On Mon, 29 Jan 2001, Robert Siemer wrote: > > > > > > and see if that changes the behaviour. > > > > It doesn't. A diff from the kernel output is following. Maybe it > > helps... > > Actually, this looks like it _did_ fix something - now the kernel no > longer thinks there is a IRQ routing conflict, so it does seem to be > happier. > > Also, while you're unhappy that it assigns irq 12 instead of 9, the pirq > table actually says that it's ok, and again the code seems to say that > this was actually what the system was set up for. I'm not just unhappy to be unable to control the IRQs with the bios anymore, sym53c8xx doesn't want to share IRQs with the usb subsystem in this case... (kernel panic (killing interrupt handler(?)) and reboot (rebooting in 60 seconds)) 2.4.0-test9 behaviour was different. It really used what the 'bios box' stated during bootup. - A way to set the IRQ distribution via kernel-params is okay for me, too. > Can you re-iterate what the failure mode is, again? Preferable with > this kernel that definitely looks like it at least agrees with what > the BIOS tells it. I'm native German - what is 'failure mode'? 2.4.0-test9 agrees with the bios. [Currently I gave my VGA card (the S3) an IRQ - without one in the bios 2.4.0-test9 was happy, but 2.4.0 gave it IRQ 8 on its own.] > Oh, and please do a "lspci -vvvxxx" as root and send me that as > well. Okay. For 2.4.0-test9 it's following immediately. After that a diff of "lspci -vvx" from 2.4.0-test9 to 2.4.0 is included. Full "lspci -vvx" are in my original post: http://boudicca.tux.org/hypermail/linux-kernel/latest/0130.html To mention it: I have also an ASUS SP97 like Aaron Tiensivu. But the XV version with (unused) onboard VGA. Further I always see '09' in the Configuration Space at Interrupt_Line (0x3c) for the 00:01.2 USB Controller. But 2.4.0 says: Interrupt: pin A routed to IRQ 12 while 2.4.0-test9 states: Interrupt: pin A routed to IRQ 9 Please tell me if it helps te see a "lspci -vvvxxx" from 2.4.0 and whether I should give some 2.4.0-test?? a try... I must go to bed now - otherwise my mother kills me when she reads linux-kernel tomorrow... (-: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at d000 [size=16] 00: 39 10 13 55 01 00 00 00 d0 8f 01 01 00 20 80 00 10: 01 e4 00 00 01 e0 00 00 01 d8 00 00 01 d4 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 00 00 40: 00 00 00 00 00 00 00 00 00 07 e0 00 00 02 00 02 50: 00 01 07 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 10) (prog-if 10 [OHCI]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] 00: 33 53 f0 88 83 00 00 02 00 00 00 03 00 00 00 00 10: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0e 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0c.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03) Subsystem: Tekram Technology Co.,Ltd. DC390F Ultra Wide SCSI Controller Control: I/O+ Mem+ BusMaste
Re: PCI IRQ routing problem in 2.4.0
From: Linus Torvalds <[EMAIL PROTECTED]>
> On Mon, 29 Jan 2001, Robert Siemer wrote:
> (...) that's really interesting..
>
> > Device 00:01.0 (slot 0): ISA bridge
> > INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
>
> Your "link" values are in the range 1-4. Which makes perfect sense, but
> that's absolutely _not_ what the Linux SiS routing code expects (the code
> seems to expect them to be ASCII 'A' - 'D').
>
> It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
> arch/i386/kernel/pci-irq.c are broken for your setup.
>
> Can you replace them with the following:
>
> static int pirq_sis_get(struct pci_dev *router, struct pci_dev *dev, int pirq)
> {
> if (pirq <= 4) {
> u8 x;
> pci_read_config_byte(router, 0x40+pirq, );
> return (x & 0x80) ? 0 : (x & 0xf);
> }
> printk("Unknown SiS pirq value %d\n", pirq);
> return 0;
> }
>
> and
>
> static int pirq_sis_set(struct pci_dev *router, struct pci_dev *dev, int pirq,
>int irq)
> {
> if (pirq <= 4) {
> pci_write_config_byte(router, 0x40 + pirq, irq);
> return 1;
> }
> printk("Unknown SiS pirq value %d\n", pirq);
> return 0;
> }
>
> and see if that changes the behaviour.
It doesn't. A diff from the kernel output is following. Maybe it
helps...
Thanks,
Robert
--- dmesg.2.4.0.debug Sun Jan 28 21:09:46 2001
+++ dmesg.2.4.0 Mon Jan 29 06:25:53 2001
@@ -1,4 +1,4 @@
-Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #4 Sun Jan 28 19:03:05 CET 2001
+Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66
+19990314/Linux (egcs-1.1.2 release)) #5 Mon Jan 29 06:19:16 CET 2001
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
@@ -231,8 +231,9 @@
bttv: using 2 buffers with 2080k (4160k total) for capture
BT848 and your chipset may not work together.
bttv: Bt8xx card found (0).
-IRQ for 00:09.0:0 -> PIRQ 04, mask 1eb8, excl -> newirq=11 -> got IRQ 7
-IRQ routing conflict in pirq table! Try 'pci=autoirq'
+IRQ for 00:09.0:0 -> PIRQ 04, mask 1eb8, excl -> newirq=11 -> got IRQ 11
+PCI: Found IRQ 11 for device 00:09.0
+PCI: The same IRQ used for device 00:09.1
bttv0: Bt878 (rev 2) at 00:09.0, irq: 11, latency: 32, memory: 0xe780
bttv0: subsystem: 0070:13eb => Hauppauge WinTV => card=10
bttv0: model: BT878(Hauppauge new (bt878)) [autodetected]
@@ -278,8 +279,8 @@
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 09
PCI: Enabling device 00:01.1 ( -> 0001)
-IRQ for 00:01.1:0 -> PIRQ 01, mask 1eb8, excl -> newirq=12 -> assigning IRQ 12
... OK
-PCI: Assigned IRQ 12 for device 00:01.1
+IRQ for 00:01.1:0 -> PIRQ 01, mask 1eb8, excl -> newirq=12 -> got IRQ 12
+PCI: Found IRQ 12 for device 00:01.1
PCI: The same IRQ used for device 00:01.2
PCI: The same IRQ used for device 00:0c.0
SIS5513: chipset revision 208
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI IRQ routing problem in 2.4.0
From: Linus Torvalds <[EMAIL PROTECTED]> > Another one.. > Robert, can you get the dump_pirq script from the pcmcia_cs package > and send the output to us? ...it seems to reflect my settings in the bios: Interrupt routing table found at address 0xf0a50: Version 1.0, size 0x0080 Interrupt router is device 00:01.0 PCI exclusive interrupt mask: 0x [] Compatible router: vendor 0x1039 device 0x0008 Device 00:0c.0 (slot 1): SCSI storage controller INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:0b.0 (slot 2): VGA compatible controller INTA: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:0a.0 (slot 3): Ethernet controller INTA: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:09.0 (slot 4): Multimedia video controller INTA: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:01.0 (slot 0): ISA bridge INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:13.0 (slot 0): VGA compatible controller INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Interrupt router at 00:01.0: SiS 85C503 PCI-to-ISA bridge INTA (link 0x41): irq 12 INTB (link 0x42): irq 14 INTC (link 0x43): irq 10 INTD (link 0x44): irq 11 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] aci.c and related files reworked for 2.4.0
Hi Thomas an linux-sound (: ! I made up a new patch for the aci.c and related files. It's for miroSOUND sound cards. It applies cleanly against 2.4.0, but problems can occur when not compiled as modules. - I will work on this issue, but my box has problems booting completely into 2.4.0 (PCI IRQ routing...). So it will take some time. The patch is technically the same as in my initially post on linux-kernel for test8: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0009.2/0260.html Thomas, please try it and tell me if it fits your needs. Further I would be pleased to hear from more people using this sound hardware... (: Bye, Robert diff -urN -X dontdiff linux-vanilla/CREDITS linux/CREDITS --- linux-vanilla/CREDITS Sun Dec 31 18:27:57 2000 +++ linux/CREDITS Sat Jan 27 16:25:01 2001 @@ -2427,6 +2427,14 @@ S: San Jose, California S: USA +N: Robert Siemer +E: [EMAIL PROTECTED] +P: 2048/C99A4289 2F DC 17 2E 56 62 01 C8 3D F2 AC 09 F2 E5 DD EE +D: miroSOUND PCM20 radio RDS driver, ACI rewrite +S: Klosterweg 28 / i309 +S: 76131 Karlsruhe +S: Germany + N: Jaspreet Singh E: [EMAIL PROTECTED] W: www.sangoma.com diff -urN -X dontdiff linux-vanilla/Documentation/Configure.help linux/Documentation/Configure.help --- linux-vanilla/Documentation/Configure.help Thu Jan 4 22:00:55 2001 +++ linux/Documentation/Configure.help Sat Jan 27 16:25:02 2001 @@ -14336,7 +14336,7 @@ If unsure, say Y. -ACI mixer (miroPCM12/PCM20) +ACI mixer (miroSOUND PCM1-pro/PCM12/PCM20) CONFIG_SOUND_ACI_MIXER ACI (Audio Command Interface) is a protocol used to communicate with the microcontroller on some sound cards produced by miro, e.g. the @@ -14345,8 +14345,8 @@ This Voxware ACI driver currently only supports the ACI functions on the miroSOUND PCM12 and PCM20 cards. On the PCM20, ACI also controls - the radio tuner. This is supported in the video4linux - radio-miropcm20 driver. + the radio tuner. This is supported in the video4linux miropcm20 + driver. SB32/AWE support CONFIG_SOUND_AWE32_SYNTH @@ -16087,11 +16087,11 @@ say M here and read Documentation/modules.txt. The module will be called i2c-parport.o. -Miro PCM20 Radio +miroSOUND PCM20 radio CONFIG_RADIO_MIROPCM20 Choose Y here if you have this FM radio card. You also need to say Y - to "ACI mixer (miroPCM12/PCM20)" (in "additional low level sound - drivers") for this to work. + to "ACI mixer (miroSOUND PCM1-pro/PCM12/PCM20)" (in "Sound") for + this to work. In order to control your radio card, you will need to use programs that are compatible with the Video for Linux API. Information on @@ -16101,7 +16101,7 @@ If you want to compile this driver as a module ( = code which can be inserted in and removed from the running kernel whenever you want), say M here and read Documentation/modules.txt. The module will be - called radio-miropcm20.o + called miropcm20.o GemTek Radio Card CONFIG_RADIO_GEMTEK diff -urN -X dontdiff linux-vanilla/Documentation/sound/PCM1-pro linux/Documentation/sound/PCM1-pro --- linux-vanilla/Documentation/sound/PCM1-pro Tue Apr 13 01:18:27 1999 +++ linux/Documentation/sound/PCM1-pro Thu Jan 1 01:00:00 1970 @@ -1,17 +0,0 @@ -In Documentation/sound/README.OSS was a remark saying noone was sure the -mixer on the PCM1-pro worked with the ACI driver. Well, it does. -I've been using the drivers for the MAD16 and the driver for the mixer -since kernel 2.0.32 with a MiroSound PCM1-pro and it works great. - -I've got it working with the following configuration: - -MAD16 audio I/O base = 530 -MAD16 audio IRQ = 7 -MAD16 Audio DMA = 1 -MAD16 MIDI I/O = 330 -MAD16 MIDI IRQ = 9 - -And I've enabled the ACI mixer (miro PCM12) . - - -Bas van der Linden. diff -urN -X dontdiff linux-vanilla/Documentation/sound/README.OSS linux/Documentation/sound/README.OSS --- linux-vanilla/Documentation/sound/README.OSSFri Jul 28 21:50:52 2000 +++ linux/Documentation/sound/README.OSSSat Jan 27 16:23:15 2001 @@ -17,6 +17,7 @@ document can be still interesting and very helpful. [ File edited 17.01.1999 - Riccardo Facchetti ] +[ Edited miroSOUND section 17.09.2000 - Robert Siemer ] OSS/Free version 3.8 release notes -- @@ -1325,26 +1326,38 @@ miroSOUND - -The miroSOUND PCM12 has been used successfully. This card is based on -the MAD16, OPL4, and CS4231A chips and everything said in the section -about MAD16 cards applies here, too. The only major difference between -the PCM12 and other MAD16 cards is that instead of the mixer in the -CS4231 codec a separate mixer controlled by an on-board 80C32 -microcontroller is used. Control of the mixer takes place via the ACI -(miro's audio control interface) protocol that is implemented in a -separate lowlevel driver. Make sure you compile this ACI driver -together with the normal MAD16 support when you use a miroSOUND PCM12 -card. T
PCI IRQ routing problem in 2.4.0
Hi Martin! While moving from 2.4.0-test9 to 2.4.0 I got the following problem: Linux thinks my usb controller is on IRQ 12 instead of IRQ 9. The 'BIOS box' (on boot) still states that usb is on IRQ 9. Under test9 pci-irq-behaviour was okay for me, but with 2.4.0 I cant load the usb-modules (the kernel panics and reboots). I attached the kernel output (with #define DEBUG) and 'lspci -vvx'. I hope you can help me; otherwise I need a good pointer to pci configuration specs... Thanks, Robert 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at d000 [size=16] 00: 39 10 13 55 01 00 00 00 d0 8a 01 01 00 20 80 00 10: 01 e4 00 00 01 e0 00 00 01 d8 00 00 01 d4 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 00 00 00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 10) (prog-if 10 [OHCI]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] 00: 33 53 f0 88 83 00 00 02 00 00 00 03 00 00 00 00 10: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0e 01 00 00 00:0c.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03) Subsystem: Tekram Technology Co.,Ltd. DC390F Ultra Wide SCSI Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] 00: 00 10 0f 00 57 00 00 02 03 00 00 01 08 20 00 00 10: 01 b4 00 00 00 00 80 e1 00 00 00 e1 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 e1 1d 04 39 30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 11 40 00:13.0 VGA compatible controller: Silicon Integrated Systems [SiS] 5597/5598 VGA (rev 65) (prog-if 00 [VGA]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at d000 [size=16] 00: 39 10 13 55 01 00 00 00 d0 8f 01 01 00 20 80 00 10: 01 e4 00 00 01 e0 00 00 01 d8 00 00 01 d4 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 00 00 00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 10) (prog-if 10 [OHCI]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] 00: 33 53 f0 88 83 00 00 02 00 00 00 03 00 00 00 00 10: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0e 01 00 00 00:0c.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03) Subsystem: Tekram Technology Co.,Ltd. DC390F Ultra Wide SCSI Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] 00: 00 10 0f 00 57 00 00 02 03 00 00 01 08 20 00 00 10: 01 b4 00 00 00 00 80 e1 00 00 00 e1 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 e1 1d 04 39 30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 11 40 00:13.0 VGA compatible controller: Silicon Integrated Systems [SiS] 5597/5598 VGA (rev 65) (prog-if 00 [VGA]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #4 Sun Jan 28 19:03:05 CET 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved)
PCI IRQ routing problem in 2.4.0
Hi Martin! While moving from 2.4.0-test9 to 2.4.0 I got the following problem: Linux thinks my usb controller is on IRQ 12 instead of IRQ 9. The 'BIOS box' (on boot) still states that usb is on IRQ 9. Under test9 pci-irq-behaviour was okay for me, but with 2.4.0 I cant load the usb-modules (the kernel panics and reboots). I attached the kernel output (with #define DEBUG) and 'lspci -vvx'. I hope you can help me; otherwise I need a good pointer to pci configuration specs... Thanks, Robert 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- Latency: 32 set 00: 39 10 97 55 07 00 00 22 02 00 00 06 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 set 00: 39 10 08 00 07 00 00 02 01 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:01.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8a [Master SecP PriP]) Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 12 Region 0: I/O ports at ignored Region 1: I/O ports at ignored Region 2: I/O ports at ignored Region 3: I/O ports at ignored Region 4: I/O ports at d000 [size=16] 00: 39 10 13 55 01 00 00 00 d0 8a 01 01 00 20 80 00 10: 01 e4 00 00 01 e0 00 00 01 d8 00 00 01 d4 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 00 00 00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 10) (prog-if 10 [OHCI]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 set, cache line size 08 Interrupt: pin A routed to IRQ 12 Region 0: Memory at e500 (32-bit, non-prefetchable) [size=4K] 00: 39 10 01 70 17 00 80 02 10 10 03 0c 08 20 80 00 10: 00 00 00 e5 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 09 01 00 00 00:09.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02) Subsystem: Hauppage computer works Inc.: Unknown device 13eb Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 16 min, 40 max, 32 set Interrupt: pin A routed to IRQ 11 Region 0: Memory at e780 (32-bit, prefetchable) [size=4K] 00: 9e 10 6e 03 06 00 80 02 02 00 00 04 00 20 80 00 10: 08 00 80 e7 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 70 00 eb 13 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 10 28 00:09.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02) Subsystem: Hauppage computer works Inc.: Unknown device 13eb Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 4 min, 255 max, 32 set Interrupt: pin A routed to IRQ 11 Region 0: Memory at e700 (32-bit, prefetchable) [size=4K] 00: 9e 10 78 08 06 00 80 02 02 00 80 04 00 20 80 00 10: 08 00 00 e7 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 70 00 eb 13 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 04 ff 00:0a.0 Ethernet controller: Winbond Electronics Corp W89C940 (rev 0b) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at b800 [size=32] 00: 50 10 40 09 03 00 80 02 0b 00 00 02 00 00 00 00 10: 01 b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00 00:0b.0 VGA compatible controller: S3 Inc. 86c968 [Vision
[PATCH] aci.c and related files reworked for 2.4.0
Hi Thomas an linux-sound (: ! I made up a new patch for the aci.c and related files. It's for miroSOUND sound cards. It applies cleanly against 2.4.0, but problems can occur when not compiled as modules. - I will work on this issue, but my box has problems booting completely into 2.4.0 (PCI IRQ routing...). So it will take some time. The patch is technically the same as in my initially post on linux-kernel for test8: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0009.2/0260.html Thomas, please try it and tell me if it fits your needs. Further I would be pleased to hear from more people using this sound hardware... (: Bye, Robert diff -urN -X dontdiff linux-vanilla/CREDITS linux/CREDITS --- linux-vanilla/CREDITS Sun Dec 31 18:27:57 2000 +++ linux/CREDITS Sat Jan 27 16:25:01 2001 @@ -2427,6 +2427,14 @@ S: San Jose, California S: USA +N: Robert Siemer +E: [EMAIL PROTECTED] +P: 2048/C99A4289 2F DC 17 2E 56 62 01 C8 3D F2 AC 09 F2 E5 DD EE +D: miroSOUND PCM20 radio RDS driver, ACI rewrite +S: Klosterweg 28 / i309 +S: 76131 Karlsruhe +S: Germany + N: Jaspreet Singh E: [EMAIL PROTECTED] W: www.sangoma.com diff -urN -X dontdiff linux-vanilla/Documentation/Configure.help linux/Documentation/Configure.help --- linux-vanilla/Documentation/Configure.help Thu Jan 4 22:00:55 2001 +++ linux/Documentation/Configure.help Sat Jan 27 16:25:02 2001 @@ -14336,7 +14336,7 @@ If unsure, say Y. -ACI mixer (miroPCM12/PCM20) +ACI mixer (miroSOUND PCM1-pro/PCM12/PCM20) CONFIG_SOUND_ACI_MIXER ACI (Audio Command Interface) is a protocol used to communicate with the microcontroller on some sound cards produced by miro, e.g. the @@ -14345,8 +14345,8 @@ This Voxware ACI driver currently only supports the ACI functions on the miroSOUND PCM12 and PCM20 cards. On the PCM20, ACI also controls - the radio tuner. This is supported in the video4linux - radio-miropcm20 driver. + the radio tuner. This is supported in the video4linux miropcm20 + driver. SB32/AWE support CONFIG_SOUND_AWE32_SYNTH @@ -16087,11 +16087,11 @@ say M here and read Documentation/modules.txt. The module will be called i2c-parport.o. -Miro PCM20 Radio +miroSOUND PCM20 radio CONFIG_RADIO_MIROPCM20 Choose Y here if you have this FM radio card. You also need to say Y - to "ACI mixer (miroPCM12/PCM20)" (in "additional low level sound - drivers") for this to work. + to "ACI mixer (miroSOUND PCM1-pro/PCM12/PCM20)" (in "Sound") for + this to work. In order to control your radio card, you will need to use programs that are compatible with the Video for Linux API. Information on @@ -16101,7 +16101,7 @@ If you want to compile this driver as a module ( = code which can be inserted in and removed from the running kernel whenever you want), say M here and read Documentation/modules.txt. The module will be - called radio-miropcm20.o + called miropcm20.o GemTek Radio Card CONFIG_RADIO_GEMTEK diff -urN -X dontdiff linux-vanilla/Documentation/sound/PCM1-pro linux/Documentation/sound/PCM1-pro --- linux-vanilla/Documentation/sound/PCM1-pro Tue Apr 13 01:18:27 1999 +++ linux/Documentation/sound/PCM1-pro Thu Jan 1 01:00:00 1970 @@ -1,17 +0,0 @@ -In Documentation/sound/README.OSS was a remark saying noone was sure the -mixer on the PCM1-pro worked with the ACI driver. Well, it does. -I've been using the drivers for the MAD16 and the driver for the mixer -since kernel 2.0.32 with a MiroSound PCM1-pro and it works great. - -I've got it working with the following configuration: - -MAD16 audio I/O base = 530 -MAD16 audio IRQ = 7 -MAD16 Audio DMA = 1 -MAD16 MIDI I/O = 330 -MAD16 MIDI IRQ = 9 - -And I've enabled the ACI mixer (miro PCM12) . - - -Bas van der Linden. diff -urN -X dontdiff linux-vanilla/Documentation/sound/README.OSS linux/Documentation/sound/README.OSS --- linux-vanilla/Documentation/sound/README.OSSFri Jul 28 21:50:52 2000 +++ linux/Documentation/sound/README.OSSSat Jan 27 16:23:15 2001 @@ -17,6 +17,7 @@ document can be still interesting and very helpful. [ File edited 17.01.1999 - Riccardo Facchetti ] +[ Edited miroSOUND section 17.09.2000 - Robert Siemer ] OSS/Free version 3.8 release notes -- @@ -1325,26 +1326,38 @@ miroSOUND - -The miroSOUND PCM12 has been used successfully. This card is based on -the MAD16, OPL4, and CS4231A chips and everything said in the section -about MAD16 cards applies here, too. The only major difference between -the PCM12 and other MAD16 cards is that instead of the mixer in the -CS4231 codec a separate mixer controlled by an on-board 80C32 -microcontroller is used. Control of the mixer takes place via the ACI -(miro's audio control interface) protocol that is implemented in a -separate lowlevel driver. Make sure you compile this ACI driver -together with the normal MAD16 support when you use a miroSOUND PCM12 -card. T
Re: PCI IRQ routing problem in 2.4.0
From: Linus Torvalds [EMAIL PROTECTED] Another one.. Robert, can you get the dump_pirq script from the pcmcia_cs package and send the output to us? ...it seems to reflect my settings in the bios: Interrupt routing table found at address 0xf0a50: Version 1.0, size 0x0080 Interrupt router is device 00:01.0 PCI exclusive interrupt mask: 0x [] Compatible router: vendor 0x1039 device 0x0008 Device 00:0c.0 (slot 1): SCSI storage controller INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:0b.0 (slot 2): VGA compatible controller INTA: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:0a.0 (slot 3): Ethernet controller INTA: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:09.0 (slot 4): Multimedia video controller INTA: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:01.0 (slot 0): ISA bridge INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:13.0 (slot 0): VGA compatible controller INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Interrupt router at 00:01.0: SiS 85C503 PCI-to-ISA bridge INTA (link 0x41): irq 12 INTB (link 0x42): irq 14 INTC (link 0x43): irq 10 INTD (link 0x44): irq 11 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI IRQ routing problem in 2.4.0
From: Linus Torvalds [EMAIL PROTECTED]
On Mon, 29 Jan 2001, Robert Siemer wrote:
(...) that's really interesting..
Device 00:01.0 (slot 0): ISA bridge
INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
Your "link" values are in the range 1-4. Which makes perfect sense, but
that's absolutely _not_ what the Linux SiS routing code expects (the code
seems to expect them to be ASCII 'A' - 'D').
It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
arch/i386/kernel/pci-irq.c are broken for your setup.
Can you replace them with the following:
static int pirq_sis_get(struct pci_dev *router, struct pci_dev *dev, int pirq)
{
if (pirq = 4) {
u8 x;
pci_read_config_byte(router, 0x40+pirq, x);
return (x 0x80) ? 0 : (x 0xf);
}
printk("Unknown SiS pirq value %d\n", pirq);
return 0;
}
and
static int pirq_sis_set(struct pci_dev *router, struct pci_dev *dev, int pirq,
int irq)
{
if (pirq = 4) {
pci_write_config_byte(router, 0x40 + pirq, irq);
return 1;
}
printk("Unknown SiS pirq value %d\n", pirq);
return 0;
}
and see if that changes the behaviour.
It doesn't. A diff from the kernel output is following. Maybe it
helps...
Thanks,
Robert
--- dmesg.2.4.0.debug Sun Jan 28 21:09:46 2001
+++ dmesg.2.4.0 Mon Jan 29 06:25:53 2001
@@ -1,4 +1,4 @@
-Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #4 Sun Jan 28 19:03:05 CET 2001
+Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66
+19990314/Linux (egcs-1.1.2 release)) #5 Mon Jan 29 06:19:16 CET 2001
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
@@ -231,8 +231,9 @@
bttv: using 2 buffers with 2080k (4160k total) for capture
BT848 and your chipset may not work together.
bttv: Bt8xx card found (0).
-IRQ for 00:09.0:0 - PIRQ 04, mask 1eb8, excl - newirq=11 - got IRQ 7
-IRQ routing conflict in pirq table! Try 'pci=autoirq'
+IRQ for 00:09.0:0 - PIRQ 04, mask 1eb8, excl - newirq=11 - got IRQ 11
+PCI: Found IRQ 11 for device 00:09.0
+PCI: The same IRQ used for device 00:09.1
bttv0: Bt878 (rev 2) at 00:09.0, irq: 11, latency: 32, memory: 0xe780
bttv0: subsystem: 0070:13eb = Hauppauge WinTV = card=10
bttv0: model: BT878(Hauppauge new (bt878)) [autodetected]
@@ -278,8 +279,8 @@
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 09
PCI: Enabling device 00:01.1 ( - 0001)
-IRQ for 00:01.1:0 - PIRQ 01, mask 1eb8, excl - newirq=12 - assigning IRQ 12
... OK
-PCI: Assigned IRQ 12 for device 00:01.1
+IRQ for 00:01.1:0 - PIRQ 01, mask 1eb8, excl - newirq=12 - got IRQ 12
+PCI: Found IRQ 12 for device 00:01.1
PCI: The same IRQ used for device 00:01.2
PCI: The same IRQ used for device 00:0c.0
SIS5513: chipset revision 208
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI IRQ routing problem in 2.4.0
From: Linus Torvalds [EMAIL PROTECTED] On Mon, 29 Jan 2001, Robert Siemer wrote: and see if that changes the behaviour. It doesn't. A diff from the kernel output is following. Maybe it helps... Actually, this looks like it _did_ fix something - now the kernel no longer thinks there is a IRQ routing conflict, so it does seem to be happier. Also, while you're unhappy that it assigns irq 12 instead of 9, the pirq table actually says that it's ok, and again the code seems to say that this was actually what the system was set up for. I'm not just unhappy to be unable to control the IRQs with the bios anymore, sym53c8xx doesn't want to share IRQs with the usb subsystem in this case... (kernel panic (killing interrupt handler(?)) and reboot (rebooting in 60 seconds)) 2.4.0-test9 behaviour was different. It really used what the 'bios box' stated during bootup. - A way to set the IRQ distribution via kernel-params is okay for me, too. Can you re-iterate what the failure mode is, again? Preferable with this kernel that definitely looks like it at least agrees with what the BIOS tells it. I'm native German - what is 'failure mode'? 2.4.0-test9 agrees with the bios. [Currently I gave my VGA card (the S3) an IRQ - without one in the bios 2.4.0-test9 was happy, but 2.4.0 gave it IRQ 8 on its own.] Oh, and please do a "lspci -vvvxxx" as root and send me that as well. Okay. For 2.4.0-test9 it's following immediately. After that a diff of "lspci -vvx" from 2.4.0-test9 to 2.4.0 is included. Full "lspci -vvx" are in my original post: http://boudicca.tux.org/hypermail/linux-kernel/latest/0130.html To mention it: I have also an ASUS SP97 like Aaron Tiensivu. But the XV version with (unused) onboard VGA. Further I always see '09' in the Configuration Space at Interrupt_Line (0x3c) for the 00:01.2 USB Controller. But 2.4.0 says: Interrupt: pin A routed to IRQ 12 while 2.4.0-test9 states: Interrupt: pin A routed to IRQ 9 Please tell me if it helps te see a "lspci -vvvxxx" from 2.4.0 and whether I should give some 2.4.0-test?? a try... I must go to bed now - otherwise my mother kills me when she reads linux-kernel tomorrow... (-: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- Latency: 32 set 00: 39 10 97 55 07 00 00 22 02 00 00 06 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: c0 ea c0 1e fc 04 43 01 60 00 00 00 00 00 00 00 60: e6 00 00 f9 00 ff 00 ff 00 ff 00 ff 80 02 00 00 70: cc 88 00 00 88 88 88 00 00 00 00 00 00 00 00 00 80: 7c c8 ce f7 40 00 10 40 00 00 00 00 00 00 00 00 90: 02 00 03 44 00 00 00 00 00 00 00 07 00 00 ff ff a0: ff ff 00 80 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 set 00: 39 10 08 00 07 00 00 02 01 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: fa 0c 0e 0a 0b 64 00 00 ff ff 10 0f 11 20 04 01 50: 11 28 02 01 60 0b 64 0b 9c 2e 12 00 a6 0b 00 00 60: ff 80 49 00 88 00 00 02 00 80 80 00 20 19 00 00 70: 1a 00 00 c1 00 c1 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 ec 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:01.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8f [Master SecP SecO PriP PriO]) Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 12 Region 0: I/O ports at ignored Region 1: I/O ports at ignored Region 2: I/O ports at ignored Regio
[V4L] [PATCH] soundcard.c, miroSOUND mixer and radio driver (aci)
Hi!
I'm the new maintainer for aci.c and the dependent files including
radio-miropcm20.c. (Thanks to Markus Kuhn and Ruurd Reitsma.)
The patch is for 2.4.0-test8 and makes the aci lowlevel driver working
again!
During testing with test8 I found a bug in soundcard.c. The second
file is a patch for this issue.
Changes:
aci.c
-general clean-up and rewrite of aci.c for 2.4.x
-added SMP safe locking
-ioctl pointer bugfix
-added (OSS-limited) equalizer support
-better distinction of PCM1/PCM12/PCM20 for good
mixer-labeling/mic-preamp/output-amplification handling
-threw mad16 dependence away: no mixer-number hack anymore
-'solo' mode doesn't need some private ioctl() anymore
radio-miropcm20.c
-removed unclear volume handling (maybe I add it later again)
-added stereo/corrected mute handling
-tune-ioctl() pays attention to different aci-versions
-change to TUNER_LOW for 50kHz steps
-integrated lowlevel RDS routines, currently only for
finegrained signal strength value
other changes
-documentation updates/corrections
Just to say something about stable/development kernels:
The current aci-driver is old (from 2.0.x), broken, has some bugs and
can crash the kernel.
The patch makes it working, fixes known bugs, makes important updates
to fit into 2.4.x and touches nothing in the mm code... [-:
Ciao,
Robert
PS: Additional RDS code is in heavy development. (:
aci-pcm20-2.4.0-test8.patch.gz
--- linux-2.4.0-test8.orig/drivers/sound/soundcard.cFri Aug 11 17:26:44 2000
+++ linux/drivers/sound/soundcard.c Sun Sep 17 21:11:22 2000
@@ -267,6 +267,7 @@
DEB(printk("sound_release(dev=%d)\n", dev));
switch (dev & 0x0f) {
case SND_DEV_CTL:
+ dev >>= 4;
if (mixer_devs[dev]->owner)
__MOD_DEC_USE_COUNT (mixer_devs[dev]->owner);
break;
[V4L] [PATCH] soundcard.c, miroSOUND mixer and radio driver (aci)
Hi!
I'm the new maintainer for aci.c and the dependent files including
radio-miropcm20.c. (Thanks to Markus Kuhn and Ruurd Reitsma.)
The patch is for 2.4.0-test8 and makes the aci lowlevel driver working
again!
During testing with test8 I found a bug in soundcard.c. The second
file is a patch for this issue.
Changes:
aci.c
-general clean-up and rewrite of aci.c for 2.4.x
-added SMP safe locking
-ioctl pointer bugfix
-added (OSS-limited) equalizer support
-better distinction of PCM1/PCM12/PCM20 for good
mixer-labeling/mic-preamp/output-amplification handling
-threw mad16 dependence away: no mixer-number hack anymore
-'solo' mode doesn't need some private ioctl() anymore
radio-miropcm20.c
-removed unclear volume handling (maybe I add it later again)
-added stereo/corrected mute handling
-tune-ioctl() pays attention to different aci-versions
-change to TUNER_LOW for 50kHz steps
-integrated lowlevel RDS routines, currently only for
finegrained signal strength value
other changes
-documentation updates/corrections
Just to say something about stable/development kernels:
The current aci-driver is old (from 2.0.x), broken, has some bugs and
can crash the kernel.
The patch makes it working, fixes known bugs, makes important updates
to fit into 2.4.x and touches nothing in the mm code... [-:
Ciao,
Robert
PS: Additional RDS code is in heavy development. (:
aci-pcm20-2.4.0-test8.patch.gz
--- linux-2.4.0-test8.orig/drivers/sound/soundcard.cFri Aug 11 17:26:44 2000
+++ linux/drivers/sound/soundcard.c Sun Sep 17 21:11:22 2000
@@ -267,6 +267,7 @@
DEB(printk("sound_release(dev=%d)\n", dev));
switch (dev 0x0f) {
case SND_DEV_CTL:
+ dev = 4;
if (mixer_devs[dev]-owner)
__MOD_DEC_USE_COUNT (mixer_devs[dev]-owner);
break;
