Re: memory remapping, 4gb memory on 945gt
On Fri, 04 Jan 2008 17:22:57 +0100 Andi Kleen (AK) wrote: AK> [EMAIL PROTECTED] writes: AK> AK> > I recently put 4 GB of memory in my Acer Travelmate 8210 series AK> > notebook. The BIOS only detects 3 GB. AK> AK> Actually it will detect 4GB, but put the PCI hole over the last GB. AK> One way to get more usable memory is to configure the BIOS to use a AK> smaller PCI hole (e.g. use smaller frame buffer/aperture etc.) AK> AK> > I googled around a little. It appears to be a chipset limitation of AK> > the 945gt, which uses the fourth gig for devices. AK> > AK> > Now I can understand this explanation for 32-bit mode, but I'm running AK> > in 64-bit mode. There should be a way to use the fourth gig under AK> > Linux. Is there? AK> AK> The chipset limitation applies to 64bit mode as well as to 32bit mode AK> (which actually does not have a 4GB limitation with PAE) Using a 64-bit or PAE kernel won't give access to more than 4GB of RAM because that only increases the linear address space of the CPU to 48 or 36 bits respectively. The limitation with 945GT is that the chipset only supports 32-bit physical addresses. As Andi already pointed out, parts of that 4GB physical address space are used by devices and their apertures, so you can only try to shrink those devices ranges, if configurable, but you won't be able to use the full 4GB RAM. Cheers, - Udo signature.asc Description: PGP signature
Re: memory remapping, 4gb memory on 945gt
On Fri, 04 Jan 2008 17:22:57 +0100 Andi Kleen (AK) wrote: AK [EMAIL PROTECTED] writes: AK AK I recently put 4 GB of memory in my Acer Travelmate 8210 series AK notebook. The BIOS only detects 3 GB. AK AK Actually it will detect 4GB, but put the PCI hole over the last GB. AK One way to get more usable memory is to configure the BIOS to use a AK smaller PCI hole (e.g. use smaller frame buffer/aperture etc.) AK AK I googled around a little. It appears to be a chipset limitation of AK the 945gt, which uses the fourth gig for devices. AK AK Now I can understand this explanation for 32-bit mode, but I'm running AK in 64-bit mode. There should be a way to use the fourth gig under AK Linux. Is there? AK AK The chipset limitation applies to 64bit mode as well as to 32bit mode AK (which actually does not have a 4GB limitation with PAE) Using a 64-bit or PAE kernel won't give access to more than 4GB of RAM because that only increases the linear address space of the CPU to 48 or 36 bits respectively. The limitation with 945GT is that the chipset only supports 32-bit physical addresses. As Andi already pointed out, parts of that 4GB physical address space are used by devices and their apertures, so you can only try to shrink those devices ranges, if configurable, but you won't be able to use the full 4GB RAM. Cheers, - Udo signature.asc Description: PGP signature
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Mon, 1 Oct 2007 02:07:33 +0200 Frans Pop (FP) wrote: FP> On Monday 01 October 2007, you wrote: FP> > I was suggesting to download 2.6.23-rc8 and applying the -hrt patchset FP> > at FP> > http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ FP> > on top of it. FP> FP> Ah, OK. I'm afraid that was not at all clear from your previous FP> message :-/ Yeah, sorry about that. FP> During 'make oldconfig' I got a config question about "CPU idle FP> support", which does not seem to be in rc8-mm2; is that correct? I FP> answered N. Shouldn't matter either way. Answering 'Y' gives you a more sophisticated C-state governor that improves battery life. FP> The system does boot with rc8 + hrt1. Good. That seems to confirm my suspicion that the real problem is caused by something in -mm which is not in -hrt. However, I have no idea what exactly could be going wrong. FP> Andrew: any suggestions on how to trace the "real" culprit for the hang? FP> FP> FP> Udo: I did see one issue during boot with this rc8 + hrt1 kernel. FP> System is Debian unstable. FP> Setting the system clock.. FP> select() to /dev/rtc to wait for clock tick timed out Thomas and Andrew are the best people to ask about what exactly has been merged from -hrt into -mm. Maybe they can chime in here. Cheers, - Udo signature.asc Description: PGP signature
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Sun, 30 Sep 2007 23:50:29 +0200 Frans Pop (FP) wrote: FP> I'm not sure what you mean. I fetched the branch I think you referred to FP> [1], but when I did a merge of that on top of v2.6.23-rc8-mm2 I FP> got "Already up-to-date", so AFAICT that branch is fully merged into mm FP> and I'm already running with you latest code... FP> Please correct me if I'm doing anything wrong. I was suggesting to download 2.6.23-rc8 and applying the -hrt patchset at http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ on top of it. That excludes all the extra stuff in -mm and should give us a good hint whether HPET is really at fault. Cheers, - Udo signature.asc Description: PGP signature
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Sat, 29 Sep 2007 13:02:34 -0700 Andrew Morton (AM) wrote: AM> On Sat, 29 Sep 2007 21:40:22 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: AM> AM> > On Saturday 29 September 2007, you wrote: AM> > > On Sat, 29 Sep 2007 02:32:44 +0200 Frans Pop <[EMAIL PROTECTED]> AM> > > wrote: AM> > > > On Friday 28 September 2007, Frans Pop wrote: AM> > > > > My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot AM> > > > > after: Marking TSC unstable due to: possible TSC halt in C2. AM> > > > > Time: acpi_pm clocksource has been installed. AM> > > > AM> > > > A few new boot attempts show the problem is more likely at: AM> > > > Probing IDE interface ide0... AM> > AM> > Looks like it is both: hpet killing IDE? AM> > AM> > > Two iterations should get you into the culprit zone. AM> > AM> > Thanks for the pointers. Luckily I ended up in a quite narrow zone AM> > between two of the points you indicated (10 iterations). AM> > AM> > And the winner is: AM> > AM> > 3fe6c0016fd863b233097a8219a0d8577c2fd503 is first bad commit AM> > commit 3fe6c0016fd863b233097a8219a0d8577c2fd503 AM> > Author: Udo A. Steinberg <...> AM> > hpet-force-enable-on-ich34 AM> > AM> > Guess the comments about thin ice and testing were justified :-) AM> > AM> > lspci and a 2.6.23-rc6 dmesg for this system can be found in: AM> > http://lkml.org/lkml/2007/9/19/300 AM> AM> Great, thanks for doing that. AM> AM> I guess I'll drop the patch for now in that case. I somehow doubt that the HPET patch itself is the culprit. In fact, the reason it shows up on git-bisect is probably because without it HPET functionality is not enabled on the platform. So the problem could really be anywhere in the HPET-driven timer infrastructure. Frans, could you try out the -hrt patchset from Thomas Gleixner and see if that works? Also, what ICH does your platform have? ICH3 or ICH4? Cheers, - Udo signature.asc Description: PGP signature
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Sat, 29 Sep 2007 13:02:34 -0700 Andrew Morton (AM) wrote: AM On Sat, 29 Sep 2007 21:40:22 +0200 Frans Pop [EMAIL PROTECTED] wrote: AM AM On Saturday 29 September 2007, you wrote: AM On Sat, 29 Sep 2007 02:32:44 +0200 Frans Pop [EMAIL PROTECTED] AM wrote: AMOn Friday 28 September 2007, Frans Pop wrote: AM My Toshiba Satellite A40 (i386, P4 Mobile) hangs during boot AM after: Marking TSC unstable due to: possible TSC halt in C2. AM Time: acpi_pm clocksource has been installed. AM AMA few new boot attempts show the problem is more likely at: AMProbing IDE interface ide0... AM AM Looks like it is both: hpet killing IDE? AM AM Two iterations should get you into the culprit zone. AM AM Thanks for the pointers. Luckily I ended up in a quite narrow zone AM between two of the points you indicated (10 iterations). AM AM And the winner is: AM AM 3fe6c0016fd863b233097a8219a0d8577c2fd503 is first bad commit AM commit 3fe6c0016fd863b233097a8219a0d8577c2fd503 AM Author: Udo A. Steinberg ... AM hpet-force-enable-on-ich34 AM AM Guess the comments about thin ice and testing were justified :-) AM AM lspci and a 2.6.23-rc6 dmesg for this system can be found in: AM http://lkml.org/lkml/2007/9/19/300 AM AM Great, thanks for doing that. AM AM I guess I'll drop the patch for now in that case. I somehow doubt that the HPET patch itself is the culprit. In fact, the reason it shows up on git-bisect is probably because without it HPET functionality is not enabled on the platform. So the problem could really be anywhere in the HPET-driven timer infrastructure. Frans, could you try out the -hrt patchset from Thomas Gleixner and see if that works? Also, what ICH does your platform have? ICH3 or ICH4? Cheers, - Udo signature.asc Description: PGP signature
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Sun, 30 Sep 2007 23:50:29 +0200 Frans Pop (FP) wrote: FP I'm not sure what you mean. I fetched the branch I think you referred to FP [1], but when I did a merge of that on top of v2.6.23-rc8-mm2 I FP got Already up-to-date, so AFAICT that branch is fully merged into mm FP and I'm already running with you latest code... FP Please correct me if I'm doing anything wrong. I was suggesting to download 2.6.23-rc8 and applying the -hrt patchset at http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ on top of it. That excludes all the extra stuff in -mm and should give us a good hint whether HPET is really at fault. Cheers, - Udo signature.asc Description: PGP signature
Re: [2.6.23-rc8-mm2] System hangs (loops?) during boot
On Mon, 1 Oct 2007 02:07:33 +0200 Frans Pop (FP) wrote: FP On Monday 01 October 2007, you wrote: FP I was suggesting to download 2.6.23-rc8 and applying the -hrt patchset FP at FP http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.23-rc8/ FP on top of it. FP FP Ah, OK. I'm afraid that was not at all clear from your previous FP message :-/ Yeah, sorry about that. FP During 'make oldconfig' I got a config question about CPU idle FP support, which does not seem to be in rc8-mm2; is that correct? I FP answered N. Shouldn't matter either way. Answering 'Y' gives you a more sophisticated C-state governor that improves battery life. FP The system does boot with rc8 + hrt1. Good. That seems to confirm my suspicion that the real problem is caused by something in -mm which is not in -hrt. However, I have no idea what exactly could be going wrong. FP Andrew: any suggestions on how to trace the real culprit for the hang? FP FP FP Udo: I did see one issue during boot with this rc8 + hrt1 kernel. FP System is Debian unstable. FP Setting the system clock.. FP select() to /dev/rtc to wait for clock tick timed out Thomas and Andrew are the best people to ask about what exactly has been merged from -hrt into -mm. Maybe they can chime in here. Cheers, - Udo signature.asc Description: PGP signature
Re: HPET force-enable investigations on Via VT8235
On Mon, 6 Aug 2007 23:57:52 +0200 Udo A. Steinberg (UAS) wrote: UAS> My guess is that newer revisions of VT8235 have HPET whereas older UAS> revisions do not. I'll get an lspci dump from our box tomorrow. Here is the lspci dump from our K7VT4A+ board, where HPET works. 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] 00:11.0 0601: 1106:3177 00: 06 11 77 31 87 00 10 02 00 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 49 18 77 31 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 40: 44 00 78 00 00 00 00 00 0c 01 00 00 44 00 08 08 50: 81 1d 09 00 00 00 00 00 43 00 ff 01 00 00 04 08 60: 00 00 00 00 10 00 02 04 00 00 00 00 00 00 00 00 70: 49 18 77 31 00 00 00 00 00 00 00 00 10 00 00 00 80: 20 84 59 00 9a 10 00 00 01 08 00 00 04 18 00 00 90: 00 77 d8 00 b4 c5 08 00 10 92 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: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 01 04 01 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 04 08 c0 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 16 00 00 00 00 00 01 00 00 00 Cheers, - Udo signature.asc Description: PGP signature
Re: HPET force-enable investigations on Via VT8235
On Mon, 6 Aug 2007 23:57:52 +0200 Udo A. Steinberg (UAS) wrote: UAS My guess is that newer revisions of VT8235 have HPET whereas older UAS revisions do not. I'll get an lspci dump from our box tomorrow. Here is the lspci dump from our K7VT4A+ board, where HPET works. 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] 00:11.0 0601: 1106:3177 00: 06 11 77 31 87 00 10 02 00 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 49 18 77 31 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 40: 44 00 78 00 00 00 00 00 0c 01 00 00 44 00 08 08 50: 81 1d 09 00 00 00 00 00 43 00 ff 01 00 00 04 08 60: 00 00 00 00 10 00 02 04 00 00 00 00 00 00 00 00 70: 49 18 77 31 00 00 00 00 00 00 00 00 10 00 00 00 80: 20 84 59 00 9a 10 00 00 01 08 00 00 04 18 00 00 90: 00 77 d8 00 b4 c5 08 00 10 92 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: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 01 04 01 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 04 08 c0 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 16 00 00 00 00 00 01 00 00 00 Cheers, - Udo signature.asc Description: PGP signature
Re: HPET force-enable investigations on Via VT8235
On Mon, 06 Aug 2007 23:39:30 +0200 Rafał Bilski (RB) wrote: RB> VT8235 does *NOT* have a HPET(*). Only part which has HPET is VT8237. It RB> is device 00:17.0 too, but only 1106:3227 has HPET enable and memory RB> base registers. VT8235 one and only feature which doesn't have driver RB> yet seems to be hardware watchdog. RB> (*) Datasheet revision 2.03 March 16, 2005 We have an Asrock K7VT4A+ board with VT8235 southbridge in our lab and it does have an HPET. Just because the datasheet does not document HPET does not mean it is not implemented. My guess is that newer revisions of VT8235 have HPET whereas older revisions do not. I'll get an lspci dump from our box tomorrow. Cheers, - Udo signature.asc Description: PGP signature
Re: HPET force-enable investigations on Via VT8235
On Mon, 06 Aug 2007 23:39:30 +0200 Rafał Bilski (RB) wrote: RB VT8235 does *NOT* have a HPET(*). Only part which has HPET is VT8237. It RB is device 00:17.0 too, but only 1106:3227 has HPET enable and memory RB base registers. VT8235 one and only feature which doesn't have driver RB yet seems to be hardware watchdog. RB (*) Datasheet revision 2.03 March 16, 2005 We have an Asrock K7VT4A+ board with VT8235 southbridge in our lab and it does have an HPET. Just because the datasheet does not document HPET does not mean it is not implemented. My guess is that newer revisions of VT8235 have HPET whereas older revisions do not. I'll get an lspci dump from our box tomorrow. Cheers, - Udo signature.asc Description: PGP signature
Re: libata limiting to UDMA/33 instead of UDMA/100
On Sun, 10 Jun 2007 17:12:59 +0100 Alan Cox (AC) wrote: AC> Doh logic was backwards when moved from the old to new driver as the old AC> driver was so messy. AC> AC> Try this and if you can confirm it works and results match the cable you AC> have. AC> AC> --- drivers/ata/pata_pdc202xx_old.c~2007-06-10 16:50:55.655743368 AC> +0100 +++ drivers/ata/pata_pdc202xx_old.c 2007-06-10 AC> 16:50:55.655743368 +0100 @@ -31,8 +31,8 @@ AC> AC> pci_read_config_word(pdev, 0x50, ); AC> if (cis & (1 << (10 + ap->port_no))) AC> - return ATA_CBL_PATA80; AC> - return ATA_CBL_PATA40; AC> + return ATA_CBL_PATA40; AC> + return ATA_CBL_PATA80; AC> } AC> AC> /** Alan, The patch fixes my cable detection problem. Now everything is back to UDMA/100 again. I noticed that ata1/ata2 claim to be using irq0, although they do in fact use irq10. This seems to be a purely cosmetical problem. ACPI: PCI Interrupt :00:11.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 scsi0 : pata_pdc202xx_old scsi1 : pata_pdc202xx_old ata1: PATA max UDMA/100 cmd 0x00019400 ctl 0x00019002 bmdma 0x00018000 irq 0 ata2: PATA max UDMA/100 cmd 0x00018800 ctl 0x00018402 bmdma 0x00018008 irq 0 ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480 ata1.00: ATA-5: IBM-DTLA-307030, TX4OA5AA, max UDMA/100 ata1.00: 60036480 sectors, multi 16: LBA ata1.01: ata_hpa_resize 1: sectors = 241254720, hpa_sectors = 241254720 ata1.01: ATA-6: IC35L120AVV207-0, V24OA63A, max UDMA/100 ata1.01: 241254720 sectors, multi 16: LBA48 ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480 ata1.00: configured for UDMA/100 ata1.01: ata_hpa_resize 1: sectors = 241254720, hpa_sectors = 241254720 ata1.01: configured for UDMA/100 Cheers, - Udo signature.asc Description: PGP signature
Re: libata limiting to UDMA/33 instead of UDMA/100
On Sun, 10 Jun 2007 17:12:59 +0100 Alan Cox (AC) wrote: AC Doh logic was backwards when moved from the old to new driver as the old AC driver was so messy. AC AC Try this and if you can confirm it works and results match the cable you AC have. AC AC --- drivers/ata/pata_pdc202xx_old.c~2007-06-10 16:50:55.655743368 AC +0100 +++ drivers/ata/pata_pdc202xx_old.c 2007-06-10 AC 16:50:55.655743368 +0100 @@ -31,8 +31,8 @@ AC AC pci_read_config_word(pdev, 0x50, cis); AC if (cis (1 (10 + ap-port_no))) AC - return ATA_CBL_PATA80; AC - return ATA_CBL_PATA40; AC + return ATA_CBL_PATA40; AC + return ATA_CBL_PATA80; AC } AC AC /** Alan, The patch fixes my cable detection problem. Now everything is back to UDMA/100 again. I noticed that ata1/ata2 claim to be using irq0, although they do in fact use irq10. This seems to be a purely cosmetical problem. ACPI: PCI Interrupt :00:11.0[A] - Link [LNKB] - GSI 10 (level, low) - IRQ 10 scsi0 : pata_pdc202xx_old scsi1 : pata_pdc202xx_old ata1: PATA max UDMA/100 cmd 0x00019400 ctl 0x00019002 bmdma 0x00018000 irq 0 ata2: PATA max UDMA/100 cmd 0x00018800 ctl 0x00018402 bmdma 0x00018008 irq 0 ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480 ata1.00: ATA-5: IBM-DTLA-307030, TX4OA5AA, max UDMA/100 ata1.00: 60036480 sectors, multi 16: LBA ata1.01: ata_hpa_resize 1: sectors = 241254720, hpa_sectors = 241254720 ata1.01: ATA-6: IC35L120AVV207-0, V24OA63A, max UDMA/100 ata1.01: 241254720 sectors, multi 16: LBA48 ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480 ata1.00: configured for UDMA/100 ata1.01: ata_hpa_resize 1: sectors = 241254720, hpa_sectors = 241254720 ata1.01: configured for UDMA/100 Cheers, - Udo signature.asc Description: PGP signature
libata limiting to UDMA/33 instead of UDMA/100
Hi, After switching an older machine over from the PDC20265 PATA driver to the libata driver pata_pdc202xx_old my HDDs are now limited to UDMA/33. With the old driver they were happily running with UDMA/100. I'm including the relevant kernel output for both cases below. Cheers, - Udo Linux version 2.6.19 ([EMAIL PROTECTED]) (gcc version 4.1.2) #2 PREEMPT Tue Apr 24 00:43:48 CEST 2007 [...] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PDC20265: IDE controller at PCI slot :00:11.0 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 ACPI: PCI Interrupt :00:11.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 PDC20265: chipset revision 2 PDC20265: ROM enabled at 0x4010 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide0: BM-DMA at 0x8000-0x8007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x8008-0x800f, BIOS settings: hdc:pio, hdd:pio hda: IBM-DTLA-307030, ATA DISK drive hdb: IC35L120AVV207-0, ATA DISK drive ide0 at 0x9400-0x9407,0x9002 on irq 10 VP_IDE: IDE controller at PCI slot :00:04.1 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci:00:04.1 ide2: BM-DMA at 0xd800-0xd807, BIOS settings: hde:pio, hdf:DMA ide3: BM-DMA at 0xd808-0xd80f, BIOS settings: hdg:pio, hdh:pio hde: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive hdf: PLEXTOR CD-R PX-W1210A, ATAPI CD/DVD-ROM drive ide2 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: max request size: 128KiB hda: 60036480 sectors (30738 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100) hda: cache flushes not supported hda: hda1 hdb: max request size: 128KiB hdb: 241254720 sectors (123522 MB) w/1821KiB Cache, CHS=16383/255/63, UDMA(100) hdb: cache flushes supported hdb: hdb1 hdb2 hdb3 < hdb5 hdb6 hdb7 hdb8 hdb9 hdb10 hdb11 > hdf: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA Uniform CD-ROM driver Revision: 3.20 ide-floppy driver 0.99.newide hde: No disk in drive hde: 98304kB, 96/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm Linux version 2.6.22-rc4 ([EMAIL PROTECTED]) (gcc version 4.1.2) #1 PREEMPT Sat Jun 9 04:02:34 CEST 2007 [...] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 ACPI: PCI Interrupt :00:11.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 scsi0 : pata_pdc202xx_old scsi1 : pata_pdc202xx_old ata1: PATA max UDMA/100 cmd 0x00019400 ctl 0x00019002 bmdma 0x00018000 irq 0 ata2: PATA max UDMA/100 cmd 0x00018800 ctl 0x00018402 bmdma 0x00018008 irq 0 ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480 ata1.00: ATA-5: IBM-DTLA-307030, TX4OA5AA, max UDMA/100 ata1.00: 60036480 sectors, multi 16: LBA ata1.01: ata_hpa_resize 1: sectors = 241254720, hpa_sectors = 241254720 ata1.01: ATA-6: IC35L120AVV207-0, V24OA63A, max UDMA/100 ata1.01: 241254720 sectors, multi 16: LBA48 ata1.00: limited to UDMA/33 due to 40-wire cable ata1.01: limited to UDMA/33 due to 40-wire cable ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480 ata1.00: configured for UDMA/33 ata1.01: ata_hpa_resize 1: sectors = 241254720, hpa_sectors = 241254720 ata1.01: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA IBM-DTLA-307030 TX4O PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 60036480 512-byte hardware sectors (30739 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 60036480 512-byte hardware sectors (30739 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 0:0:1:0: Direct-Access ATA IC35L120AVV207-0 V24O PQ: 0 ANSI: 5 sd 0:0:1:0: [sdb] 241254720 512-byte hardware sectors (123522 MB) sd 0:0:1:0: [sdb] Write Protect is off sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:1:0: [sdb] 241254720 512-byte hardware sectors (123522 MB) sd 0:0:1:0: [sdb] Write Protect is off sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sdb3 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 > sd 0:0:1:0: [sdb] Attached SCSI disk sd 0:0:1:0: Attached scsi generic sg1 type 0 scsi2 : pata_via scsi3 : pata_via ata3: PATA max UDMA/66 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001d800 irq 14 ata4: PATA max UDMA/66 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001d808 irq 15 ata3.00: ATAPI, max PIO2, CDB intr ata3.01: ATAPI, max MWDMA2 ata3.00: configured for PIO2 ata3.01: configured for MWDMA2 scsi 2:0:0:0: Direct-Access IOMEGA ZIP 100 14.A PQ: 0 ANSI: 5 sd 2:0:0:0: [sdc] Attached SCSI removable disk sd 2:0:0:0: Attached scsi generic sg2 type 0 scsi 2:0:1:0: CD-ROMPLEXTOR CD-R PX-W1210A 1.10 PQ: 0 ANSI: 5
libata limiting to UDMA/33 instead of UDMA/100
Hi, After switching an older machine over from the PDC20265 PATA driver to the libata driver pata_pdc202xx_old my HDDs are now limited to UDMA/33. With the old driver they were happily running with UDMA/100. I'm including the relevant kernel output for both cases below. Cheers, - Udo Linux version 2.6.19 ([EMAIL PROTECTED]) (gcc version 4.1.2) #2 PREEMPT Tue Apr 24 00:43:48 CEST 2007 [...] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PDC20265: IDE controller at PCI slot :00:11.0 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 ACPI: PCI Interrupt :00:11.0[A] - Link [LNKB] - GSI 10 (level, low) - IRQ 10 PDC20265: chipset revision 2 PDC20265: ROM enabled at 0x4010 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide0: BM-DMA at 0x8000-0x8007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x8008-0x800f, BIOS settings: hdc:pio, hdd:pio hda: IBM-DTLA-307030, ATA DISK drive hdb: IC35L120AVV207-0, ATA DISK drive ide0 at 0x9400-0x9407,0x9002 on irq 10 VP_IDE: IDE controller at PCI slot :00:04.1 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci:00:04.1 ide2: BM-DMA at 0xd800-0xd807, BIOS settings: hde:pio, hdf:DMA ide3: BM-DMA at 0xd808-0xd80f, BIOS settings: hdg:pio, hdh:pio hde: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive hdf: PLEXTOR CD-R PX-W1210A, ATAPI CD/DVD-ROM drive ide2 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: max request size: 128KiB hda: 60036480 sectors (30738 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100) hda: cache flushes not supported hda: hda1 hdb: max request size: 128KiB hdb: 241254720 sectors (123522 MB) w/1821KiB Cache, CHS=16383/255/63, UDMA(100) hdb: cache flushes supported hdb: hdb1 hdb2 hdb3 hdb5 hdb6 hdb7 hdb8 hdb9 hdb10 hdb11 hdf: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA Uniform CD-ROM driver Revision: 3.20 ide-floppy driver 0.99.newide hde: No disk in drive hde: 98304kB, 96/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm Linux version 2.6.22-rc4 ([EMAIL PROTECTED]) (gcc version 4.1.2) #1 PREEMPT Sat Jun 9 04:02:34 CEST 2007 [...] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 ACPI: PCI Interrupt :00:11.0[A] - Link [LNKB] - GSI 10 (level, low) - IRQ 10 scsi0 : pata_pdc202xx_old scsi1 : pata_pdc202xx_old ata1: PATA max UDMA/100 cmd 0x00019400 ctl 0x00019002 bmdma 0x00018000 irq 0 ata2: PATA max UDMA/100 cmd 0x00018800 ctl 0x00018402 bmdma 0x00018008 irq 0 ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480 ata1.00: ATA-5: IBM-DTLA-307030, TX4OA5AA, max UDMA/100 ata1.00: 60036480 sectors, multi 16: LBA ata1.01: ata_hpa_resize 1: sectors = 241254720, hpa_sectors = 241254720 ata1.01: ATA-6: IC35L120AVV207-0, V24OA63A, max UDMA/100 ata1.01: 241254720 sectors, multi 16: LBA48 ata1.00: limited to UDMA/33 due to 40-wire cable ata1.01: limited to UDMA/33 due to 40-wire cable ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480 ata1.00: configured for UDMA/33 ata1.01: ata_hpa_resize 1: sectors = 241254720, hpa_sectors = 241254720 ata1.01: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA IBM-DTLA-307030 TX4O PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 60036480 512-byte hardware sectors (30739 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 60036480 512-byte hardware sectors (30739 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 0:0:1:0: Direct-Access ATA IC35L120AVV207-0 V24O PQ: 0 ANSI: 5 sd 0:0:1:0: [sdb] 241254720 512-byte hardware sectors (123522 MB) sd 0:0:1:0: [sdb] Write Protect is off sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:1:0: [sdb] 241254720 512-byte hardware sectors (123522 MB) sd 0:0:1:0: [sdb] Write Protect is off sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sdb3 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sd 0:0:1:0: [sdb] Attached SCSI disk sd 0:0:1:0: Attached scsi generic sg1 type 0 scsi2 : pata_via scsi3 : pata_via ata3: PATA max UDMA/66 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001d800 irq 14 ata4: PATA max UDMA/66 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001d808 irq 15 ata3.00: ATAPI, max PIO2, CDB intr ata3.01: ATAPI, max MWDMA2 ata3.00: configured for PIO2 ata3.01: configured for MWDMA2 scsi 2:0:0:0: Direct-Access IOMEGA ZIP 100 14.A PQ: 0 ANSI: 5 sd 2:0:0:0: [sdc] Attached SCSI removable disk sd 2:0:0:0: Attached scsi generic sg2 type 0 scsi 2:0:1:0: CD-ROMPLEXTOR CD-R PX-W1210A 1.10 PQ: 0 ANSI: 5 sr0:
Re: [PATCH 0/2] i386: Fix two more NMI watchdog bugs
On Fri, 8 Jun 2007 13:57:27 -0700 Andrew Morton (AM) wrote: AM> On Fri, 8 Jun 2007 22:49:11 +0200 AM> "Udo A. Steinberg" <[EMAIL PROTECTED]> wrote: AM> AM> > On Fri, 8 Jun 2007 22:43:25 +0200 Ingo Molnar (IM) wrote: AM> > AM> > IM> AM> > IM> * Bj?rn Steinbrink <[EMAIL PROTECTED]> wrote: AM> > IM> AM> > IM> > Anyway, both are bugs and should be fixed. Maybe we're even lucky AM> > IM> > and it fixes your hang. *fingers crossed* AM> > IM> AM> > IM> just to make it clear: the NMI watchdog was working perfectly fine on AM> > IM> that box (in v2.6.21 and in dozens of kernel releases before that, AM> > IM> for multiple years) before Andi's cleanup patch. So lets find that AM> > IM> bug first or revert the cleanups. AM> > IM> AM> > IM> Ingo AM> > AM> > None of the patches posted by Bj__rn fix the kernel BUG at AM> > arch/i386/kernel/cpu/perfctr-watchdog.c:126! that occurs when doing AM> > echo 0 > /proc/sys/kernel/nmi_watchdog AM> > AM> > Call Trace: AM> > [] single_msr_unreserve+0xd/0x1a AM> > [] disable_lapic_nmi_watchdog+0x27/0x35 AM> > [] proc_nmi_enabled+0xa0/0xbd AM> > [] proc_sys_write+0x6f/0x8c AM> > [] proc_sys_write+0x0/0x8c AM> > [] vfs_write+0x8a/0x10c AM> > [] sys_write+0x41/0x67 AM> > [] syscall_call+0x7/0xb AM> > AM> > Andi, did you have a patch for that? AM> > AM> AM> This? AM> AM> AM> From: Bjorn Steinbrink <[EMAIL PROTECTED]> AM> AM> Fix oops triggered during: echo 0 > /proc/sys/kernel/nmi_watchdog AM> AM> The culprit seems to be 09198e68501a7e34737cd9264d266f42429abcdc: This alone does not help, but in combination with the other two patches the problem no longer occurs. Thanks, - Udo signature.asc Description: PGP signature
Re: [PATCH 0/2] i386: Fix two more NMI watchdog bugs
On Fri, 8 Jun 2007 22:43:25 +0200 Ingo Molnar (IM) wrote: IM> IM> * Bj?rn Steinbrink <[EMAIL PROTECTED]> wrote: IM> IM> > Anyway, both are bugs and should be fixed. Maybe we're even lucky and IM> > it fixes your hang. *fingers crossed* IM> IM> just to make it clear: the NMI watchdog was working perfectly fine on IM> that box (in v2.6.21 and in dozens of kernel releases before that, for IM> multiple years) before Andi's cleanup patch. So lets find that bug first IM> or revert the cleanups. IM> IM> Ingo None of the patches posted by Björn fix the kernel BUG at arch/i386/kernel/cpu/perfctr-watchdog.c:126! that occurs when doing echo 0 > /proc/sys/kernel/nmi_watchdog Call Trace: [] single_msr_unreserve+0xd/0x1a [] disable_lapic_nmi_watchdog+0x27/0x35 [] proc_nmi_enabled+0xa0/0xbd [] proc_sys_write+0x6f/0x8c [] proc_sys_write+0x0/0x8c [] vfs_write+0x8a/0x10c [] sys_write+0x41/0x67 [] syscall_call+0x7/0xb Andi, did you have a patch for that? Cheers, - Udo signature.asc Description: PGP signature
Re: [PATCH 0/2] i386: Fix two more NMI watchdog bugs
On Fri, 8 Jun 2007 22:43:25 +0200 Ingo Molnar (IM) wrote: IM IM * Bj?rn Steinbrink [EMAIL PROTECTED] wrote: IM IM Anyway, both are bugs and should be fixed. Maybe we're even lucky and IM it fixes your hang. *fingers crossed* IM IM just to make it clear: the NMI watchdog was working perfectly fine on IM that box (in v2.6.21 and in dozens of kernel releases before that, for IM multiple years) before Andi's cleanup patch. So lets find that bug first IM or revert the cleanups. IM IM Ingo None of the patches posted by Björn fix the kernel BUG at arch/i386/kernel/cpu/perfctr-watchdog.c:126! that occurs when doing echo 0 /proc/sys/kernel/nmi_watchdog Call Trace: [c010c429] single_msr_unreserve+0xd/0x1a [c010c668] disable_lapic_nmi_watchdog+0x27/0x35 [c0110ac6] proc_nmi_enabled+0xa0/0xbd [c018550c] proc_sys_write+0x6f/0x8c [c018549d] proc_sys_write+0x0/0x8c [c0156e5b] vfs_write+0x8a/0x10c [c0157317] sys_write+0x41/0x67 [c0103c30] syscall_call+0x7/0xb Andi, did you have a patch for that? Cheers, - Udo signature.asc Description: PGP signature
Re: [PATCH 0/2] i386: Fix two more NMI watchdog bugs
On Fri, 8 Jun 2007 13:57:27 -0700 Andrew Morton (AM) wrote: AM On Fri, 8 Jun 2007 22:49:11 +0200 AM Udo A. Steinberg [EMAIL PROTECTED] wrote: AM AM On Fri, 8 Jun 2007 22:43:25 +0200 Ingo Molnar (IM) wrote: AM AM IM AM IM * Bj?rn Steinbrink [EMAIL PROTECTED] wrote: AM IM AM IM Anyway, both are bugs and should be fixed. Maybe we're even lucky AM IM and it fixes your hang. *fingers crossed* AM IM AM IM just to make it clear: the NMI watchdog was working perfectly fine on AM IM that box (in v2.6.21 and in dozens of kernel releases before that, AM IM for multiple years) before Andi's cleanup patch. So lets find that AM IM bug first or revert the cleanups. AM IM AM IM Ingo AM AM None of the patches posted by Bj__rn fix the kernel BUG at AM arch/i386/kernel/cpu/perfctr-watchdog.c:126! that occurs when doing AM echo 0 /proc/sys/kernel/nmi_watchdog AM AM Call Trace: AM [c010c429] single_msr_unreserve+0xd/0x1a AM [c010c668] disable_lapic_nmi_watchdog+0x27/0x35 AM [c0110ac6] proc_nmi_enabled+0xa0/0xbd AM [c018550c] proc_sys_write+0x6f/0x8c AM [c018549d] proc_sys_write+0x0/0x8c AM [c0156e5b] vfs_write+0x8a/0x10c AM [c0157317] sys_write+0x41/0x67 AM [c0103c30] syscall_call+0x7/0xb AM AM Andi, did you have a patch for that? AM AM AM This? AM AM AM From: Bjorn Steinbrink [EMAIL PROTECTED] AM AM Fix oops triggered during: echo 0 /proc/sys/kernel/nmi_watchdog AM AM The culprit seems to be 09198e68501a7e34737cd9264d266f42429abcdc: This alone does not help, but in combination with the other two patches the problem no longer occurs. Thanks, - Udo signature.asc Description: PGP signature
Re: [1/4] 2.6.22-rc3: known regressions
On Tue, 29 May 2007 14:52:53 +0200 Michal Piotrowski (MP) wrote: MP> Here is a list of some known regressions in 2.6.22-rc3. MP> MP> Feel free to add new regressions/remove fixed etc. MP> http://kernelnewbies.org/known_regressions Here's another 2.6.22-rc3 regression. It was ok on 2.6.21. I believe it triggered during: echo 0 > /proc/sys/kernel/nmi_watchdog [ cut here ] kernel BUG at arch/i386/kernel/cpu/perfctr-watchdog.c:126! invalid opcode: [#1] PREEMPT Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.22-rc3 #2) EIP is at release_evntsel_nmi+0x16/0x22 eax: 00c1 ebx: 080f7408 ecx: c04296e0 edx: ff3b esi: 0001 edi: f69d4240 ebp: 0002 esp: f6962f30 ds: 007b es: 007b fs: gs: 0033 ss: 0068 Process rc.M (pid: 1281, ti=f6962000 task=f706c030 task.ti=f6962000) Stack: c010cb60 c010cda3 c0110abe 080f7408 f6962f64 f6962fa0 c042ab68 c01853a8 080f7408 f6962f64 f6962fa0 080f7408 0002 c042a774 f69d4240 080f7408 c0185339 0002 c0156d33 f6962fa0 f7fcccb4 f69d4240 fff7 Call Trace: [] single_msr_unreserve+0xd/0x1a [] disable_lapic_nmi_watchdog+0x2b/0x39 [] proc_nmi_enabled+0xa0/0xbd [] proc_sys_write+0x6f/0x8c [] proc_sys_write+0x0/0x8c [] vfs_write+0x8a/0x10c [] sys_write+0x41/0x67 [] syscall_call+0x7/0xb === Code: 00 c7 04 24 f6 5d 3c c0 e8 7d e0 00 00 83 ca ff 89 d0 5a 59 c3 8b 0d 28 6e 48 c0 31 d2 85 c9 74 0e 89 c2 2b 51 18 83 fa 42 76 04 <0f> 0b eb fe 0f b3 15 38 6e 48 c0 c3 8b 0d 28 6e 48 c0 31 d2 85 EIP: [] release_evntsel_nmi+0x16/0x22 SS:ESP 0068:f6962f30 Cheers, - Udo signature.asc Description: PGP signature
Re: [1/4] 2.6.22-rc3: known regressions
On Tue, 29 May 2007 14:52:53 +0200 Michal Piotrowski (MP) wrote: MP Here is a list of some known regressions in 2.6.22-rc3. MP MP Feel free to add new regressions/remove fixed etc. MP http://kernelnewbies.org/known_regressions Here's another 2.6.22-rc3 regression. It was ok on 2.6.21. I believe it triggered during: echo 0 /proc/sys/kernel/nmi_watchdog [ cut here ] kernel BUG at arch/i386/kernel/cpu/perfctr-watchdog.c:126! invalid opcode: [#1] PREEMPT Modules linked in: CPU:0 EIP:0060:[c010cae5]Not tainted VLI EFLAGS: 00010286 (2.6.22-rc3 #2) EIP is at release_evntsel_nmi+0x16/0x22 eax: 00c1 ebx: 080f7408 ecx: c04296e0 edx: ff3b esi: 0001 edi: f69d4240 ebp: 0002 esp: f6962f30 ds: 007b es: 007b fs: gs: 0033 ss: 0068 Process rc.M (pid: 1281, ti=f6962000 task=f706c030 task.ti=f6962000) Stack: c010cb60 c010cda3 c0110abe 080f7408 f6962f64 f6962fa0 c042ab68 c01853a8 080f7408 f6962f64 f6962fa0 080f7408 0002 c042a774 f69d4240 080f7408 c0185339 0002 c0156d33 f6962fa0 f7fcccb4 f69d4240 fff7 Call Trace: [c010cb60] single_msr_unreserve+0xd/0x1a [c010cda3] disable_lapic_nmi_watchdog+0x2b/0x39 [c0110abe] proc_nmi_enabled+0xa0/0xbd [c01853a8] proc_sys_write+0x6f/0x8c [c0185339] proc_sys_write+0x0/0x8c [c0156d33] vfs_write+0x8a/0x10c [c01571ef] sys_write+0x41/0x67 [c0103c30] syscall_call+0x7/0xb === Code: 00 c7 04 24 f6 5d 3c c0 e8 7d e0 00 00 83 ca ff 89 d0 5a 59 c3 8b 0d 28 6e 48 c0 31 d2 85 c9 74 0e 89 c2 2b 51 18 83 fa 42 76 04 0f 0b eb fe 0f b3 15 38 6e 48 c0 c3 8b 0d 28 6e 48 c0 31 d2 85 EIP: [c010cae5] release_evntsel_nmi+0x16/0x22 SS:ESP 0068:f6962f30 Cheers, - Udo signature.asc Description: PGP signature
Re: [PATCH 4/8] Force detect and enable HPET on ICH
On Mon, 21 May 2007 08:46:03 -0700 Jesse Barnes (JB) wrote: JB> I see it documented in the ICH5 datasheet, but that bit is marked reserved JB> in the ICH3 and ICH4 datasheets... Which docs are you looking at? It's documented for ICH5 only. My experiments on IBM T30 (ICH3) and T41p (ICH4) laptops show that HPET exists on these chipsets as well and can be enabled the same way as described in the ICH5 datasheet. Cheers, - Udo -- Dipl.-Inf. Udo Steinberg Technische Universität Dresden http://os.inf.tu-dresden.de/~us15 Institute for System ArchitectureTel: +49 351 463 38401 D-01062 Dresden Fax: +49 351 463 38284 signature.asc Description: PGP signature
Re: [PATCH 4/8] Force detect and enable HPET on ICH
On Mon, 21 May 2007 08:46:03 -0700 Jesse Barnes (JB) wrote: JB I see it documented in the ICH5 datasheet, but that bit is marked reserved JB in the ICH3 and ICH4 datasheets... Which docs are you looking at? It's documented for ICH5 only. My experiments on IBM T30 (ICH3) and T41p (ICH4) laptops show that HPET exists on these chipsets as well and can be enabled the same way as described in the ICH5 datasheet. Cheers, - Udo -- Dipl.-Inf. Udo Steinberg Technische Universität Dresden http://os.inf.tu-dresden.de/~us15 Institute for System ArchitectureTel: +49 351 463 38401 D-01062 Dresden Fax: +49 351 463 38284 signature.asc Description: PGP signature
Re: [PATCH 4/8] Force detect and enable HPET on ICH
On Mon, 7 May 2007 13:31:28 -0700 Venki Pallipadi (VP) wrote: VP> Force detect and/or enable HPET on ICH chipsets. This patch just handles the VP> detection part and following patches use this information. VP> VP> Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> Venki, Is there any reason your patch only enables HPET on ICH6 and beyond? HPET can be enabled on earlier ICH by setting bit 17 in GEN_CNTL on PCI dev 31, func 0, offset d0. This seems to work for ICH3/4/5. Are there any errata affecting these ICHs? Cheers, - Udo -- Dipl.-Inf. Udo Steinberg Technische Universität Dresden http://os.inf.tu-dresden.de/~us15 Institute for System ArchitectureTel: +49 351 463 38401 D-01062 Dresden Fax: +49 351 463 38284 signature.asc Description: PGP signature
Re: [PATCH 4/8] Force detect and enable HPET on ICH
On Mon, 7 May 2007 13:31:28 -0700 Venki Pallipadi (VP) wrote: VP Force detect and/or enable HPET on ICH chipsets. This patch just handles the VP detection part and following patches use this information. VP VP Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Venki, Is there any reason your patch only enables HPET on ICH6 and beyond? HPET can be enabled on earlier ICH by setting bit 17 in GEN_CNTL on PCI dev 31, func 0, offset d0. This seems to work for ICH3/4/5. Are there any errata affecting these ICHs? Cheers, - Udo -- Dipl.-Inf. Udo Steinberg Technische Universität Dresden http://os.inf.tu-dresden.de/~us15 Institute for System ArchitectureTel: +49 351 463 38401 D-01062 Dresden Fax: +49 351 463 38284 signature.asc Description: PGP signature
ACPI interpreter errors
Hello, With 2.6.21 I am getting the following errors from the ACPI interpreter on an Intel S5000PSL board: Allocate Port Service[:02:02.0:pcie20] Allocate Port Service[:02:02.0:pcie21] Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:02.0:pcie01 failed with error 2 aer_init: AER service init fails - No ACPI _OSC support aer: probe of :00:03.0:pcie01 failed with error 1 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:04.0:pcie01 failed with error 2 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:05.0:pcie01 failed with error 2 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:06.0:pcie01 failed with error 2 aer_init: AER service init fails - No ACPI _OSC support aer: probe of :00:07.0:pcie01 failed with error 1 The complete dmesg output is attached. If you need more information, please let me know. Cheers, - Udo dmesg.txt Description: Binary data signature.asc Description: PGP signature
ACPI interpreter errors
Hello, With 2.6.21 I am getting the following errors from the ACPI interpreter on an Intel S5000PSL board: Allocate Port Service[:02:02.0:pcie20] Allocate Port Service[:02:02.0:pcie21] Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:02.0:pcie01 failed with error 2 aer_init: AER service init fails - No ACPI _OSC support aer: probe of :00:03.0:pcie01 failed with error 1 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:04.0:pcie01 failed with error 2 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:05.0:pcie01 failed with error 2 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:06.0:pcie01 failed with error 2 aer_init: AER service init fails - No ACPI _OSC support aer: probe of :00:07.0:pcie01 failed with error 1 The complete dmesg output is attached. If you need more information, please let me know. Cheers, - Udo dmesg.txt Description: Binary data signature.asc Description: PGP signature
Re: Linux 2.6.19
On Fri, 01 Dec 2006 08:15:12 +1100 Herbert Xu (HX) wrote: HX> Udo A. Steinberg <[EMAIL PROTECTED]> wrote: HX> > HX> > Ok, so 2.6.18 used to get along fine with cryptoloop and 2.6.19 refuses to HX> > cooperate. An strace of "losetup -e aes /dev/loop0 /dev/hda7" without all HX> > the terminal interaction shows: HX> HX> Did you enable CONFIG_CRYPTO_CBC? I didn't and that turned out to be the culprit. With CONFIG_CRYPTO_CBC enabled everything works fine. Thanks, Herbert! Shouldn't cryptoloop automatically select CONFIG_CRYPTO_CBC if it depends on it? Cheers, - Udo signature.asc Description: PGP signature
Re: Linux 2.6.19
On Fri, 01 Dec 2006 08:15:12 +1100 Herbert Xu (HX) wrote: HX Udo A. Steinberg [EMAIL PROTECTED] wrote: HX HX Ok, so 2.6.18 used to get along fine with cryptoloop and 2.6.19 refuses to HX cooperate. An strace of losetup -e aes /dev/loop0 /dev/hda7 without all HX the terminal interaction shows: HX HX Did you enable CONFIG_CRYPTO_CBC? I didn't and that turned out to be the culprit. With CONFIG_CRYPTO_CBC enabled everything works fine. Thanks, Herbert! Shouldn't cryptoloop automatically select CONFIG_CRYPTO_CBC if it depends on it? Cheers, - Udo signature.asc Description: PGP signature
Re: Linux 2.6.19
On Wed, 29 Nov 2006 14:21:21 -0800 (PST) Linus Torvalds (LT) wrote:
LT> So go get it. It's one of those rare "perfect" kernels. So if it doesn't
LT> happen to compile with your config (or it does compile, but then does
LT> unspeakable acts of perversion with your pet dachshund), you can rest easy
LT> knowing that it's all your own d*mn fault, and you should just fix your
LT> evil ways.
Ok, so 2.6.18 used to get along fine with cryptoloop and 2.6.19 refuses to
cooperate. An strace of "losetup -e aes /dev/loop0 /dev/hda7" without all the
terminal interaction shows:
open("/dev/hda7", O_RDWR|O_LARGEFILE) = 3
open("/dev/loop0", O_RDWR|O_LARGEFILE) = 4
mlockall(MCL_CURRENT|MCL_FUTURE)= 0
...
munmap(0xb7fc8000, 4096)= 0
ioctl(4, 0x4c00, 0x3) = 0
close(3)= 0
ioctl(4, 0x4c04, 0xbfc21670)= -1 ENOENT (No such file or directory)
ioctl(4, 0x4c02, 0xbfc215e0)= -1 ENOENT (No such file or directory)
dup(2) = 3
fcntl64(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat64(3, {st_mode=S_IFCHR|0720, st_rdev=makedev(4, 1), ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fc8000
_llseek(3, 0, 0xbfc21040, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, "ioctl: LOOP_SET_STATUS: No such "..., 50ioctl: LOOP_SET_STATUS: No
such file or directory) = 50
close(3)= 0
munmap(0xb7fc8000, 4096)= 0
ioctl(4, 0x4c01, 0) = 0
close(4)= 0
exit_group(1) = ?
Linux 2.6.18 does not fail at
ioctl(4, 0x4c04, ...)
I know that dm-crypt is now the preferred method of doing such things, but as
long as cryptoloop exists in the kernel I'd expect it to work.
Cheers,
- Udo
signature.asc
Description: PGP signature
Re: Linux 2.6.19
On Wed, 29 Nov 2006 14:21:21 -0800 (PST) Linus Torvalds (LT) wrote:
LT So go get it. It's one of those rare perfect kernels. So if it doesn't
LT happen to compile with your config (or it does compile, but then does
LT unspeakable acts of perversion with your pet dachshund), you can rest easy
LT knowing that it's all your own d*mn fault, and you should just fix your
LT evil ways.
Ok, so 2.6.18 used to get along fine with cryptoloop and 2.6.19 refuses to
cooperate. An strace of losetup -e aes /dev/loop0 /dev/hda7 without all the
terminal interaction shows:
open(/dev/hda7, O_RDWR|O_LARGEFILE) = 3
open(/dev/loop0, O_RDWR|O_LARGEFILE) = 4
mlockall(MCL_CURRENT|MCL_FUTURE)= 0
...
munmap(0xb7fc8000, 4096)= 0
ioctl(4, 0x4c00, 0x3) = 0
close(3)= 0
ioctl(4, 0x4c04, 0xbfc21670)= -1 ENOENT (No such file or directory)
ioctl(4, 0x4c02, 0xbfc215e0)= -1 ENOENT (No such file or directory)
dup(2) = 3
fcntl64(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat64(3, {st_mode=S_IFCHR|0720, st_rdev=makedev(4, 1), ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fc8000
_llseek(3, 0, 0xbfc21040, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, ioctl: LOOP_SET_STATUS: No such ..., 50ioctl: LOOP_SET_STATUS: No
such file or directory) = 50
close(3)= 0
munmap(0xb7fc8000, 4096)= 0
ioctl(4, 0x4c01, 0) = 0
close(4)= 0
exit_group(1) = ?
Linux 2.6.18 does not fail at
ioctl(4, 0x4c04, ...)
I know that dm-crypt is now the preferred method of doing such things, but as
long as cryptoloop exists in the kernel I'd expect it to work.
Cheers,
- Udo
signature.asc
Description: PGP signature
[PATCH]: Correctly locate RSDP in EBDA
ACPI spec. states that the location of the RSDP structure is found by searching * The first 1 KB of the Extended BIOS Data Area (EBDA). * The BIOS read-only memory space between 0Eh and 0Fh The EBDA scan looks wrong. The patch below against 2.6.12 should correct this. -Udo. --- Calculate correct EBDA address for ACPI RSDP scan. The word at BIOS Data Area 40:0E is the segment address of the EBDA. Signed-off-by: Udo A. Steinberg <[EMAIL PROTECTED]> --- linux-2.6.12/arch/i386/kernel/acpi/boot.c.old 2005-07-20 17:28:32.0 +0200 +++ linux-2.6.12/arch/i386/kernel/acpi/boot.c 2005-07-20 17:31:15.0 +0200 @@ -648,7 +648,7 @@ * Scan memory looking for the RSDP signature. First search EBDA (low * memory) paragraphs and then search upper memory (E-F). */ - rsdp_phys = acpi_scan_rsdp (0, 0x400); + rsdp_phys = acpi_scan_rsdp (*(u16*) 0x40E << 4, 0x400); if (!rsdp_phys) rsdp_phys = acpi_scan_rsdp (0xE, 0x2); pgpGuYcEEEdZD.pgp Description: PGP signature
[PATCH]: Correctly locate RSDP in EBDA
ACPI spec. states that the location of the RSDP structure is found by searching * The first 1 KB of the Extended BIOS Data Area (EBDA). * The BIOS read-only memory space between 0Eh and 0Fh The EBDA scan looks wrong. The patch below against 2.6.12 should correct this. -Udo. --- Calculate correct EBDA address for ACPI RSDP scan. The word at BIOS Data Area 40:0E is the segment address of the EBDA. Signed-off-by: Udo A. Steinberg [EMAIL PROTECTED] --- linux-2.6.12/arch/i386/kernel/acpi/boot.c.old 2005-07-20 17:28:32.0 +0200 +++ linux-2.6.12/arch/i386/kernel/acpi/boot.c 2005-07-20 17:31:15.0 +0200 @@ -648,7 +648,7 @@ * Scan memory looking for the RSDP signature. First search EBDA (low * memory) paragraphs and then search upper memory (E-F). */ - rsdp_phys = acpi_scan_rsdp (0, 0x400); + rsdp_phys = acpi_scan_rsdp (*(u16*) 0x40E 4, 0x400); if (!rsdp_phys) rsdp_phys = acpi_scan_rsdp (0xE, 0x2); pgpGuYcEEEdZD.pgp Description: PGP signature
Re: Linux 2.6.11-rc2
On Sat, 22 Jan 2005 15:04:29 +0100 Martin Josefsson (MJ) wrote:
MJ> On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote:
MJ> >
MJ> > Connection tracking does not compile...
MJ> The problem is when compiling without NAT...
MJ> The patch below should fix it, I can compile both with and without NAT
MJ> now.
Thanks, this fixes my problem, too.
Linus, please apply the following patch from Martin.
-Udo.
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 12:17:39.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 13:55:25.0 +0100
@@ -122,33 +122,6 @@ do {
\
#define IP_NF_ASSERT(x)
#endif
-struct ip_conntrack_expect
-{
- /* Internal linked list (global expectation list) */
- struct list_head list;
-
- /* We expect this tuple, with the following mask */
- struct ip_conntrack_tuple tuple, mask;
-
- /* Function to call after setup and insertion */
- void (*expectfn)(struct ip_conntrack *new,
-struct ip_conntrack_expect *this);
-
- /* The conntrack of the master connection */
- struct ip_conntrack *master;
-
- /* Timer function; deletes the expectation. */
- struct timer_list timeout;
-
-#ifdef CONFIG_IP_NF_NAT_NEEDED
- /* This is the original per-proto part, used to map the
-* expected connection the way the recipient expects. */
- union ip_conntrack_manip_proto saved_proto;
- /* Direction relative to the master connection. */
- enum ip_conntrack_dir dir;
-#endif
-};
-
struct ip_conntrack_counter
{
u_int64_t packets;
@@ -206,6 +179,33 @@ struct ip_conntrack
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];
};
+struct ip_conntrack_expect
+{
+ /* Internal linked list (global expectation list) */
+ struct list_head list;
+
+ /* We expect this tuple, with the following mask */
+ struct ip_conntrack_tuple tuple, mask;
+
+ /* Function to call after setup and insertion */
+ void (*expectfn)(struct ip_conntrack *new,
+struct ip_conntrack_expect *this);
+
+ /* The conntrack of the master connection */
+ struct ip_conntrack *master;
+
+ /* Timer function; deletes the expectation. */
+ struct timer_list timeout;
+
+#ifdef CONFIG_IP_NF_NAT_NEEDED
+ /* This is the original per-proto part, used to map the
+* expected connection the way the recipient expects. */
+ union ip_conntrack_manip_proto saved_proto;
+ /* Direction relative to the master connection. */
+ enum ip_conntrack_dir dir;
+#endif
+};
+
static inline struct ip_conntrack *
tuplehash_to_ctrack(const struct ip_conntrack_tuple_hash *hash)
{
@@ -301,6 +301,7 @@ struct ip_conntrack_stat
#define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
+#ifdef CONFIG_IP_NF_NAT_NEEDED
static inline int ip_nat_initialized(struct ip_conntrack *conntrack,
enum ip_nat_manip_type manip)
{
@@ -308,5 +309,7 @@ static inline int ip_nat_initialized(str
return test_bit(IPS_SRC_NAT_DONE_BIT, >status);
return test_bit(IPS_DST_NAT_DONE_BIT, >status);
}
+#endif /* CONFIG_IP_NF_NAT_NEEDED */
+
#endif /* __KERNEL__ */
#endif /* _IP_CONNTRACK_H */
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c
linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c
--- linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c2005-01-22
12:17:40.0 +0100
+++ linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c 2005-01-22
13:55:49.0 +0100
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#define CLUSTERIP_VERSION "0.6"
pgpjUUY1JDlce.pgp
Description: PGP signature
Re: Linux 2.6.11-rc2
On Sat, 22 Jan 2005 15:04:29 +0100 Martin Josefsson (MJ) wrote:
MJ On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote:
MJ
MJ Connection tracking does not compile...
MJ The problem is when compiling without NAT...
MJ The patch below should fix it, I can compile both with and without NAT
MJ now.
Thanks, this fixes my problem, too.
Linus, please apply the following patch from Martin.
-Udo.
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 12:17:39.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 13:55:25.0 +0100
@@ -122,33 +122,6 @@ do {
\
#define IP_NF_ASSERT(x)
#endif
-struct ip_conntrack_expect
-{
- /* Internal linked list (global expectation list) */
- struct list_head list;
-
- /* We expect this tuple, with the following mask */
- struct ip_conntrack_tuple tuple, mask;
-
- /* Function to call after setup and insertion */
- void (*expectfn)(struct ip_conntrack *new,
-struct ip_conntrack_expect *this);
-
- /* The conntrack of the master connection */
- struct ip_conntrack *master;
-
- /* Timer function; deletes the expectation. */
- struct timer_list timeout;
-
-#ifdef CONFIG_IP_NF_NAT_NEEDED
- /* This is the original per-proto part, used to map the
-* expected connection the way the recipient expects. */
- union ip_conntrack_manip_proto saved_proto;
- /* Direction relative to the master connection. */
- enum ip_conntrack_dir dir;
-#endif
-};
-
struct ip_conntrack_counter
{
u_int64_t packets;
@@ -206,6 +179,33 @@ struct ip_conntrack
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];
};
+struct ip_conntrack_expect
+{
+ /* Internal linked list (global expectation list) */
+ struct list_head list;
+
+ /* We expect this tuple, with the following mask */
+ struct ip_conntrack_tuple tuple, mask;
+
+ /* Function to call after setup and insertion */
+ void (*expectfn)(struct ip_conntrack *new,
+struct ip_conntrack_expect *this);
+
+ /* The conntrack of the master connection */
+ struct ip_conntrack *master;
+
+ /* Timer function; deletes the expectation. */
+ struct timer_list timeout;
+
+#ifdef CONFIG_IP_NF_NAT_NEEDED
+ /* This is the original per-proto part, used to map the
+* expected connection the way the recipient expects. */
+ union ip_conntrack_manip_proto saved_proto;
+ /* Direction relative to the master connection. */
+ enum ip_conntrack_dir dir;
+#endif
+};
+
static inline struct ip_conntrack *
tuplehash_to_ctrack(const struct ip_conntrack_tuple_hash *hash)
{
@@ -301,6 +301,7 @@ struct ip_conntrack_stat
#define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
+#ifdef CONFIG_IP_NF_NAT_NEEDED
static inline int ip_nat_initialized(struct ip_conntrack *conntrack,
enum ip_nat_manip_type manip)
{
@@ -308,5 +309,7 @@ static inline int ip_nat_initialized(str
return test_bit(IPS_SRC_NAT_DONE_BIT, conntrack-status);
return test_bit(IPS_DST_NAT_DONE_BIT, conntrack-status);
}
+#endif /* CONFIG_IP_NF_NAT_NEEDED */
+
#endif /* __KERNEL__ */
#endif /* _IP_CONNTRACK_H */
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c
linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c
--- linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c2005-01-22
12:17:40.0 +0100
+++ linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c 2005-01-22
13:55:49.0 +0100
@@ -29,6 +29,7 @@
#include linux/netfilter_ipv4/ip_tables.h
#include linux/netfilter_ipv4/ipt_CLUSTERIP.h
#include linux/netfilter_ipv4/ip_conntrack.h
+#include linux/netfilter_ipv4/lockhelp.h
#define CLUSTERIP_VERSION 0.6
pgpjUUY1JDlce.pgp
Description: PGP signature
Re: Linux 2.6.11-rc2
On Fri, 21 Jan 2005 18:13:55 -0800 (PST) Linus Torvalds (LT) wrote: LT> Ok, trying to calm things down again for a 2.6.11 release. Connection tracking does not compile... CC net/ipv4/netfilter/ip_conntrack_standalone.o In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34: include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: "struct ip_conntrack" declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/netfilter_ipv4/ip_conntrack.h:305: warning: "enum ip_nat_manip_type" declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has incomplete type include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized': include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC' undeclared (first use in this function) include/linux/netfilter_ipv4/ip_conntrack.h:307: error: (Each undeclared identifier is reported only once include/linux/netfilter_ipv4/ip_conntrack.h:307: error: for each function it appears in.) -Udo. pgpvBTo55ykQ4.pgp Description: PGP signature
Re: Linux 2.6.11-rc2
On Fri, 21 Jan 2005 18:13:55 -0800 (PST) Linus Torvalds (LT) wrote: LT Ok, trying to calm things down again for a 2.6.11 release. Connection tracking does not compile... CC net/ipv4/netfilter/ip_conntrack_standalone.o In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34: include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: struct ip_conntrack declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/netfilter_ipv4/ip_conntrack.h:305: warning: enum ip_nat_manip_type declared inside parameter list include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has incomplete type include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized': include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC' undeclared (first use in this function) include/linux/netfilter_ipv4/ip_conntrack.h:307: error: (Each undeclared identifier is reported only once include/linux/netfilter_ipv4/ip_conntrack.h:307: error: for each function it appears in.) -Udo. pgpvBTo55ykQ4.pgp Description: PGP signature
Re: Tvmixer Oops
Gerd Knorr wrote: > > On Mon, Jun 25, 2001 at 12:56:03PM +0200, Udo A. Steinberg wrote: > > > > Hello, > > > > Attached is the trace of an oops which seems to be caused by the > > tvmixer code. Tvmixer is compiled monolithically into the kernel, > > the rest of bttv is compiled as modules. > > Any hints on how to reproduce that one? I just got another one, however I still cannot reliably reproduce it. Regards, Udo. ksymoops 2.4.1 on i686 2.4.5-ac18. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac18/ (default) -m /boot/System.map-2.4.5-ac18 (specified) Unable to handle kernel NULL pointer dereference at virtual address 002c c01b8faa *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: ebx: ccb16980 ecx: 0010 edx: esi: c02f7fc0 edi: ebp: 0010 esp: cf351ef4 ds: 0018 es: 0018 ss: 0018 Process rat-4.2.19-medi (pid: 5876, stackpage=cf351000) Stack: c028b580 c01cfa68 c5c0dc40 c85162c0 c85162c0 c5c0dc40 c14a82c0 c028ab60 c85162c0 c5c0dc40 c14a82c0 c5c0dc40 ffeb 0002 c013900a c5c0dc40 c012febe c5c0dc40 c85162c0 c85162c0 c5c0dc40 Call Trace: [] [] [] [] [] [] [] Code: 83 78 2c 00 74 09 50 8b 40 2c ff d0 83 c4 04 31 c0 5b 5e c3 >>EIP; c01b8faa<= Trace; c01cfa68 Trace; c013900a Trace; c012febe Trace; c012ef5d Trace; c012ee92 Trace; c012f186 Trace; c0106bfb Code; c01b8faa <_EIP>: Code; c01b8faa<= 0: 83 78 2c 00 cmpl $0x0,0x2c(%eax) <= Code; c01b8fae 4: 74 09 je f <_EIP+0xf> c01b8fb9 Code; c01b8fb0 6: 50push %eax Code; c01b8fb1 7: 8b 40 2c mov0x2c(%eax),%eax Code; c01b8fb4 a: ff d0 call *%eax Code; c01b8fb6 c: 83 c4 04 add$0x4,%esp Code; c01b8fb9 f: 31 c0 xor%eax,%eax Code; c01b8fbb 11: 5bpop%ebx Code; c01b8fbc 12: 5epop%esi Code; c01b8fbd 13: c3ret - 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: Linux 2.4.5-ac20
Alan Cox wrote:
>
> This is the initial merge with 2.4.6pre - treat this one with care, it may
> not be the most reliable 2.4.5ac release ever made
make[3]: Entering directory `/usr/src/linux-2.4.5-ac/drivers/pnp'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.5-ac/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe
-mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -DEXPORT_SYMTAB -c
pnp_bios.c
pnp_bios.c:252: warning: static declaration for `pnp_bios_dock_station_info' follows
non-static
pnp_bios.c:432: warning: no semicolon at end of struct or union
pnp_bios.c:432: parse error before `u16'
pnp_bios.c: In function `pnp_dock_thread':
pnp_bios.c:442: warning: function declaration isn't a prototype
pnp_bios.c:442: warning: extern declaration of `daemonize' doesn't match global one
pnp_bios.c:445: parse error before `struct'
pnp_bios.c:445: warning: unused variable `err'
pnp_bios.c: At top level:
pnp_bios.c:435: storage size of `dock' isn't known
pnp_bios.c:435: warning: `dock' defined but not used
pnp_bios.c:440: warning: `pnp_dock_thread' defined but not used
{standard input}: Assembler messages:
{standard input}:63: Warning: indirect lcall without `*'
{standard input}:143: Warning: indirect lcall without `*'
{standard input}:201: Warning: indirect lcall without `*'
{standard input}:240: Warning: indirect lcall without `*'
-
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: Tvmixer Oops
Gerd Knorr wrote: On Mon, Jun 25, 2001 at 12:56:03PM +0200, Udo A. Steinberg wrote: Hello, Attached is the trace of an oops which seems to be caused by the tvmixer code. Tvmixer is compiled monolithically into the kernel, the rest of bttv is compiled as modules. Any hints on how to reproduce that one? I just got another one, however I still cannot reliably reproduce it. Regards, Udo. ksymoops 2.4.1 on i686 2.4.5-ac18. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac18/ (default) -m /boot/System.map-2.4.5-ac18 (specified) Unable to handle kernel NULL pointer dereference at virtual address 002c c01b8faa *pde = Oops: CPU:0 EIP:0010:[c01b8faa] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: ebx: ccb16980 ecx: 0010 edx: esi: c02f7fc0 edi: ebp: 0010 esp: cf351ef4 ds: 0018 es: 0018 ss: 0018 Process rat-4.2.19-medi (pid: 5876, stackpage=cf351000) Stack: c028b580 c01cfa68 c5c0dc40 c85162c0 c85162c0 c5c0dc40 c14a82c0 c028ab60 c85162c0 c5c0dc40 c14a82c0 c5c0dc40 ffeb 0002 c013900a c5c0dc40 c012febe c5c0dc40 c85162c0 c85162c0 c5c0dc40 Call Trace: [c01cfa68] [c013900a] [c012febe] [c012ef5d] [c012ee92] [c012f186] [c0106bfb] Code: 83 78 2c 00 74 09 50 8b 40 2c ff d0 83 c4 04 31 c0 5b 5e c3 EIP; c01b8faa tvmixer_open+5a/70 = Trace; c01cfa68 soundcore_open+108/190 Trace; c013900a permission+2a/30 Trace; c012febe chrdev_open+3e/50 Trace; c012ef5d dentry_open+bd/140 Trace; c012ee92 filp_open+52/60 Trace; c012f186 sys_open+36/a0 Trace; c0106bfb system_call+33/38 Code; c01b8faa tvmixer_open+5a/70 _EIP: Code; c01b8faa tvmixer_open+5a/70 = 0: 83 78 2c 00 cmpl $0x0,0x2c(%eax) = Code; c01b8fae tvmixer_open+5e/70 4: 74 09 je f _EIP+0xf c01b8fb9 tvmixer_open+69/70 Code; c01b8fb0 tvmixer_open+60/70 6: 50push %eax Code; c01b8fb1 tvmixer_open+61/70 7: 8b 40 2c mov0x2c(%eax),%eax Code; c01b8fb4 tvmixer_open+64/70 a: ff d0 call *%eax Code; c01b8fb6 tvmixer_open+66/70 c: 83 c4 04 add$0x4,%esp Code; c01b8fb9 tvmixer_open+69/70 f: 31 c0 xor%eax,%eax Code; c01b8fbb tvmixer_open+6b/70 11: 5bpop%ebx Code; c01b8fbc tvmixer_open+6c/70 12: 5epop%esi Code; c01b8fbd tvmixer_open+6d/70 13: c3ret - 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: Linux 2.4.5-ac20
Alan Cox wrote:
This is the initial merge with 2.4.6pre - treat this one with care, it may
not be the most reliable 2.4.5ac release ever made
make[3]: Entering directory `/usr/src/linux-2.4.5-ac/drivers/pnp'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.5-ac/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe
-mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -DEXPORT_SYMTAB -c
pnp_bios.c
pnp_bios.c:252: warning: static declaration for `pnp_bios_dock_station_info' follows
non-static
pnp_bios.c:432: warning: no semicolon at end of struct or union
pnp_bios.c:432: parse error before `u16'
pnp_bios.c: In function `pnp_dock_thread':
pnp_bios.c:442: warning: function declaration isn't a prototype
pnp_bios.c:442: warning: extern declaration of `daemonize' doesn't match global one
pnp_bios.c:445: parse error before `struct'
pnp_bios.c:445: warning: unused variable `err'
pnp_bios.c: At top level:
pnp_bios.c:435: storage size of `dock' isn't known
pnp_bios.c:435: warning: `dock' defined but not used
pnp_bios.c:440: warning: `pnp_dock_thread' defined but not used
{standard input}: Assembler messages:
{standard input}:63: Warning: indirect lcall without `*'
{standard input}:143: Warning: indirect lcall without `*'
{standard input}:201: Warning: indirect lcall without `*'
{standard input}:240: Warning: indirect lcall without `*'
-
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: Tvmixer Oops
Hi, Gerd Knorr wrote: > > On Mon, Jun 25, 2001 at 12:56:03PM +0200, Udo A. Steinberg wrote: > > Attached is the trace of an oops which seems to be caused by the > > tvmixer code. Tvmixer is compiled monolithically into the kernel, > > the rest of bttv is compiled as modules. > > Any hints on how to reproduce that one? I cannot reproduce it again - it happened just once so far. The time it happened, I zapped X/KDE while xawtv ran via Ctrl-Alt-Backspace. - 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: Tvmixer Oops
Hi, Gerd Knorr wrote: On Mon, Jun 25, 2001 at 12:56:03PM +0200, Udo A. Steinberg wrote: Attached is the trace of an oops which seems to be caused by the tvmixer code. Tvmixer is compiled monolithically into the kernel, the rest of bttv is compiled as modules. Any hints on how to reproduce that one? I cannot reproduce it again - it happened just once so far. The time it happened, I zapped X/KDE while xawtv ran via Ctrl-Alt-Backspace. - 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/
Tvmixer Oops
Hello,
Attached is the trace of an oops which seems to be caused by the
tvmixer code. Tvmixer is compiled monolithically into the kernel,
the rest of bttv is compiled as modules.
Kernel is 2.4.5-ac17, compiled with gcc-3.0.
Regards,
Udo.
ksymoops 2.4.1 on i686 2.4.5-ac17. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.5-ac17/ (default)
-m /boot/System.map-2.4.5-ac17 (specified)
Unable to handle kernel NULL pointer dereference at virtual address 0030
c01bd8d0
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: ebx: c86d1e40 ecx: c86d1e40 edx: c01bd8c0
esi: c14e92c0 edi: cf2e31c0 ebp: cbd0bc40 esp: c9665edc
ds: 0018 es: 0018 ss: 0018
Process kdeinit (pid: 11670, stackpage=c9665000)
Stack: c01311b9 cf2e31c0 c86d1e40 c01209c0 40afea15 0282 c86d1e40
0001 000a c01301de c86d1e40 c4749580 c86d1e40
0001 c4749580 c011759e c86d1e40 c4749580 cc8ffc40 c9664000
Call Trace: [] [] [] [] []
[] [] [] []
Code: 8b 50 30 85 d2 74 04 50 ff d2 58 31 c0 c3 89 f6 b8 ed ff ff
>>EIP; c01bd8d0<=
Trace; c01311b9
Trace; c01209c0
Trace; c01301de
Trace; c011759e
Trace; c0117b7a
Trace; c01306d3
Trace; c0112bad
Trace; c0117cde
Trace; c0106cfb
Code; c01bd8d0
<_EIP>:
Code; c01bd8d0<=
0: 8b 50 30 mov0x30(%eax),%edx <=
Code; c01bd8d3
3: 85 d2 test %edx,%edx
Code; c01bd8d5
5: 74 04 je b <_EIP+0xb> c01bd8db
Code; c01bd8d7
7: 50push %eax
Code; c01bd8d8
8: ff d2 call *%edx
Code; c01bd8da
a: 58pop%eax
Code; c01bd8db
b: 31 c0 xor%eax,%eax
Code; c01bd8dd
d: c3ret
Code; c01bd8de
e: 89 f6 mov%esi,%esi
Code; c01bd8e0
10: b8 ed ff ff 00mov$0xed,%eax
-
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/
Tvmixer Oops
Hello,
Attached is the trace of an oops which seems to be caused by the
tvmixer code. Tvmixer is compiled monolithically into the kernel,
the rest of bttv is compiled as modules.
Kernel is 2.4.5-ac17, compiled with gcc-3.0.
Regards,
Udo.
ksymoops 2.4.1 on i686 2.4.5-ac17. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.5-ac17/ (default)
-m /boot/System.map-2.4.5-ac17 (specified)
Unable to handle kernel NULL pointer dereference at virtual address 0030
c01bd8d0
*pde =
Oops:
CPU:0
EIP:0010:[c01bd8d0]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: ebx: c86d1e40 ecx: c86d1e40 edx: c01bd8c0
esi: c14e92c0 edi: cf2e31c0 ebp: cbd0bc40 esp: c9665edc
ds: 0018 es: 0018 ss: 0018
Process kdeinit (pid: 11670, stackpage=c9665000)
Stack: c01311b9 cf2e31c0 c86d1e40 c01209c0 40afea15 0282 c86d1e40
0001 000a c01301de c86d1e40 c4749580 c86d1e40
0001 c4749580 c011759e c86d1e40 c4749580 cc8ffc40 c9664000
Call Trace: [c01311b9] [c01209c0] [c01301de] [c011759e] [c0117b7a]
[c01306d3] [c0112bad] [c0117cde] [c0106cfb]
Code: 8b 50 30 85 d2 74 04 50 ff d2 58 31 c0 c3 89 f6 b8 ed ff ff
EIP; c01bd8d0 tvmixer_release+10/30 =
Trace; c01311b9 fput+39/c0
Trace; c01209c0 clear_page_tables+60/90
Trace; c01301de filp_close+3e/60
Trace; c011759e put_files_struct+4e/c0
Trace; c0117b7a do_exit+8a/1c0
Trace; c01306d3 sys_write+83/d0
Trace; c0112bad schedule+1fd/3c0
Trace; c0117cde sys_exit+e/10
Trace; c0106cfb system_call+33/38
Code; c01bd8d0 tvmixer_release+10/30
_EIP:
Code; c01bd8d0 tvmixer_release+10/30 =
0: 8b 50 30 mov0x30(%eax),%edx =
Code; c01bd8d3 tvmixer_release+13/30
3: 85 d2 test %edx,%edx
Code; c01bd8d5 tvmixer_release+15/30
5: 74 04 je b _EIP+0xb c01bd8db tvmixer_release+1b/30
Code; c01bd8d7 tvmixer_release+17/30
7: 50push %eax
Code; c01bd8d8 tvmixer_release+18/30
8: ff d2 call *%edx
Code; c01bd8da tvmixer_release+1a/30
a: 58pop%eax
Code; c01bd8db tvmixer_release+1b/30
b: 31 c0 xor%eax,%eax
Code; c01bd8dd tvmixer_release+1d/30
d: c3ret
Code; c01bd8de tvmixer_release+1e/30
e: 89 f6 mov%esi,%esi
Code; c01bd8e0 tvmixer_release+20/30
10: b8 ed ff ff 00mov$0xed,%eax
-
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: VIA's Southbridge bug: Latest (pseudo-)patch
Gerhard Mack wrote: > > > Its what I would describe as lack of enforcement by trading standards bodies, > > and I suspect what the US would call 'insufficient class action lawsuits' > > What we need is a web page for listing crap hardware so less people buy > it. Not just crap hardware, but also vendors who refuse to release proper material required for writing drivers. NVidia springs to my mind. -Udo. - 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: VIA's Southbridge bug: Latest (pseudo-)patch
Gerhard Mack wrote: Its what I would describe as lack of enforcement by trading standards bodies, and I suspect what the US would call 'insufficient class action lawsuits' What we need is a web page for listing crap hardware so less people buy it. Not just crap hardware, but also vendors who refuse to release proper material required for writing drivers. NVidia springs to my mind. -Udo. - 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: Linux 2.4.4-ac10
Hi,
Alan Cox wrote:
>
> 2.4.4-ac10
With 2.4.4-ac10 and binutils 2.11 I get the following warnings:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686 -malign-functions=4 -c -o pci-pc.o pci-pc.c
pci-pc.c:964: warning: `pci_fixup_via691' defined but not used
pci-pc.c:977: warning: `pci_fixup_via691_2' defined but not used
{standard input}: Assembler messages:
{standard input}:747: Warning: indirect lcall without `*'
{standard input}:832: Warning: indirect lcall without `*'
{standard input}:919: Warning: indirect lcall without `*'
{standard input}:958: Warning: indirect lcall without `*'
{standard input}:990: Warning: indirect lcall without `*'
{standard input}:1022: Warning: indirect lcall without `*'
{standard input}:1053: Warning: indirect lcall without `*'
{standard input}:1082: Warning: indirect lcall without `*'
{standard input}:: Warning: indirect lcall without `*'
{standard input}:1392: Warning: indirect lcall without `*'
{standard input}:1497: Warning: indirect lcall without `*'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686 -malign-functions=4 -c -o apm.o apm.c
{standard input}: Assembler messages:
{standard input}:180: Warning: indirect lcall without `*'
{standard input}:274: Warning: indirect lcall without `*'
Does anyone know what's up with that? Kernel problem or binutils issue?
Regards,
Udo.
-
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: Linux 2.4.4-ac10
Hi,
Alan Cox wrote:
2.4.4-ac10
With 2.4.4-ac10 and binutils 2.11 I get the following warnings:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686 -malign-functions=4 -c -o pci-pc.o pci-pc.c
pci-pc.c:964: warning: `pci_fixup_via691' defined but not used
pci-pc.c:977: warning: `pci_fixup_via691_2' defined but not used
{standard input}: Assembler messages:
{standard input}:747: Warning: indirect lcall without `*'
{standard input}:832: Warning: indirect lcall without `*'
{standard input}:919: Warning: indirect lcall without `*'
{standard input}:958: Warning: indirect lcall without `*'
{standard input}:990: Warning: indirect lcall without `*'
{standard input}:1022: Warning: indirect lcall without `*'
{standard input}:1053: Warning: indirect lcall without `*'
{standard input}:1082: Warning: indirect lcall without `*'
{standard input}:: Warning: indirect lcall without `*'
{standard input}:1392: Warning: indirect lcall without `*'
{standard input}:1497: Warning: indirect lcall without `*'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686 -malign-functions=4 -c -o apm.o apm.c
{standard input}: Assembler messages:
{standard input}:180: Warning: indirect lcall without `*'
{standard input}:274: Warning: indirect lcall without `*'
Does anyone know what's up with that? Kernel problem or binutils issue?
Regards,
Udo.
-
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: USB Problem with reenabling hub
Pete Zaitcev wrote: > > > switching it back on, a problem occurs with reenabling the ports on > > that USB hub. The kernel output follows. > > > Comments anyone? > > Next time, post your /proc/version. I thought this was unnecessary in this case, because my mail headers nicely reveal which version it is, but here it is anyways ;): /proc/version Linux version 2.4.4-ac6 (root@Corona) (gcc version 2.95.3 20010315 (release)) #1 > There were similar things recently (missing urb->dev > reinitialization in usb_hub_reset). If more info is required or someone has a patch to try, please let me know. Regards, Udo. - 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/
USB Problem with reenabling hub
Hi all, I have an USB hub built into my monitor (Eizo T761) which disconnects and powers down the hub when the monitor gets switched off. After switching it back on, a problem occurs with reenabling the ports on that USB hub. The kernel output follows. Comments anyone? Regards, Udo. [Detect USB Ports on mainboard] usb.c: registered new driver usbdevfs usb.c: registered new driver hub PCI: Found IRQ 9 for device 00:04.2 PCI: The same IRQ used for device 00:04.3 PCI: The same IRQ used for device 00:09.0 PCI: The same IRQ used for device 00:09.1 PCI: The same IRQ used for device 00:0d.0 uhci.c: USB UHCI at I/O 0xd400, IRQ 9 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 9 for device 00:04.3 PCI: The same IRQ used for device 00:04.2 PCI: The same IRQ used for device 00:09.0 PCI: The same IRQ used for device 00:09.1 PCI: The same IRQ used for device 00:0d.0 uhci.c: USB UHCI at I/O 0xd000, IRQ 9 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected [Detect USB HUB in monitor] hub.c: USB new device connect on bus1/1, assigned device number 2 hub.c: USB hub found hub.c: 5 ports detected hub.c: USB new device connect on bus1/1/1, assigned device number 3 usb.c: USB device 3 (vend/prod 0x56d/0x2) is not claimed by any active driver. hub.c: USB new device connect on bus2/2, assigned device number 2 hub.c: USB hub found hub.c: 4 ports detected [switch monitor off] usb.c: USB disconnect on device 2 usb.c: USB disconnect on device 3 [switch monitor back on] hub.c: USB new device connect on bus1/1, assigned device number 4 usb.c: USB device not accepting new address=4 (error=-110) hub.c: USB new device connect on bus1/1, assigned device number 5 usb.c: USB device not accepting new address=5 (error=-110) - 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/
USB Problem with reenabling hub
Hi all, I have an USB hub built into my monitor (Eizo T761) which disconnects and powers down the hub when the monitor gets switched off. After switching it back on, a problem occurs with reenabling the ports on that USB hub. The kernel output follows. Comments anyone? Regards, Udo. [Detect USB Ports on mainboard] usb.c: registered new driver usbdevfs usb.c: registered new driver hub PCI: Found IRQ 9 for device 00:04.2 PCI: The same IRQ used for device 00:04.3 PCI: The same IRQ used for device 00:09.0 PCI: The same IRQ used for device 00:09.1 PCI: The same IRQ used for device 00:0d.0 uhci.c: USB UHCI at I/O 0xd400, IRQ 9 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 9 for device 00:04.3 PCI: The same IRQ used for device 00:04.2 PCI: The same IRQ used for device 00:09.0 PCI: The same IRQ used for device 00:09.1 PCI: The same IRQ used for device 00:0d.0 uhci.c: USB UHCI at I/O 0xd000, IRQ 9 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected [Detect USB HUB in monitor] hub.c: USB new device connect on bus1/1, assigned device number 2 hub.c: USB hub found hub.c: 5 ports detected hub.c: USB new device connect on bus1/1/1, assigned device number 3 usb.c: USB device 3 (vend/prod 0x56d/0x2) is not claimed by any active driver. hub.c: USB new device connect on bus2/2, assigned device number 2 hub.c: USB hub found hub.c: 4 ports detected [switch monitor off] usb.c: USB disconnect on device 2 usb.c: USB disconnect on device 3 [switch monitor back on] hub.c: USB new device connect on bus1/1, assigned device number 4 usb.c: USB device not accepting new address=4 (error=-110) hub.c: USB new device connect on bus1/1, assigned device number 5 usb.c: USB device not accepting new address=5 (error=-110) - 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: USB Problem with reenabling hub
Pete Zaitcev wrote: switching it back on, a problem occurs with reenabling the ports on that USB hub. The kernel output follows. Comments anyone? Next time, post your /proc/version. I thought this was unnecessary in this case, because my mail headers nicely reveal which version it is, but here it is anyways ;): /proc/version Linux version 2.4.4-ac6 (root@Corona) (gcc version 2.95.3 20010315 (release)) #1 There were similar things recently (missing urb-dev reinitialization in usb_hub_reset). If more info is required or someone has a patch to try, please let me know. Regards, Udo. - 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: ac10 ide-cd oopses on boot
Alan Cox wrote: > > > Just built 2.4.3-ac10 and got an oops when booting. It tries to detect > > the CD and gives the oops. I'm getting a similar oops with -ac10. I initially thought this might be a result of switching to gcc-2.95.3, because -ac9 runs fine when built with gcc-2.95.2, but if others have seen this too, it's probably the cdrom code indeed. > Can you back out the ide-cd changes Jens did and see if that fixes it ? I'll try that tomorrow, too. Regards, Udo. -- ksymoops 2.3.7 on i686 2.4.3-ac9. Options used -v /usr/src/linux/vmlinux (specified) -K (specified) -l /proc/modules (default) -o /lib/modules/2.4.3-ac10 (specified) -m /boot/System.map-2.4.3-ac10 (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod Unable to handle kernel NULL pointer dereference at virtual address Oops: CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 eax: 000d ebx: ecx: edx: esi: edi: c1469ae8 ebp: 0021 ebp: cffe5ee0 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=cffe5000) Stack: c0276018 c0275fb4 c01b9dbf c1469a00 c02e31f4 c1469b18 c02e3100 0001 0286 0001 0001 c0113623 c02b5fe1 0246 c0113574 c0244e02 c0244e9d c1469a00 c02e3100 c01b91cb c02448ec c02e3100 c1469037 c0244fc0 Call Trace: [] [] [] [] [] [] [] [] [] Code: 8b 04 8a 83 f8 ff 75 0c 83 c6 20 eb e7 8d b4 26 00 00 00 00 >>EIP; c01b9bac<= Trace; c01b9dbf Trace; c0113623 Trace; c0113574 Trace; c01b91cb Trace; c01b8d0c Trace; c01b976a Trace; c01b9af1 Trace; c0105007 Trace; c0105488 Code; c01b9bac <_EIP>: Code; c01b9bac<= 0: 8b 04 8a movl (%edx,%ecx,4),%eax <= Code; c01b9baf 3: 83 f8 ff cmpl $0x,%eax Code; c01b9bb2 6: 75 0c jne14 <_EIP+0x14> c01b9bc0 Code; c01b9bb4 8: 83 c6 20 addl $0x20,%esi Code; c01b9bb7 b: eb e7 jmpfff4 <_EIP+0xfff4> c01b9ba0 Code; c01b9bb9 d: 8d b4 26 00 00 00 00 leal 0x0(%esi,1),%esi <0>Kernel panic: Attempted to kill init! - 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: ac10 ide-cd oopses on boot
Alan Cox wrote: Just built 2.4.3-ac10 and got an oops when booting. It tries to detect the CD and gives the oops. I'm getting a similar oops with -ac10. I initially thought this might be a result of switching to gcc-2.95.3, because -ac9 runs fine when built with gcc-2.95.2, but if others have seen this too, it's probably the cdrom code indeed. Can you back out the ide-cd changes Jens did and see if that fixes it ? I'll try that tomorrow, too. Regards, Udo. -- ksymoops 2.3.7 on i686 2.4.3-ac9. Options used -v /usr/src/linux/vmlinux (specified) -K (specified) -l /proc/modules (default) -o /lib/modules/2.4.3-ac10 (specified) -m /boot/System.map-2.4.3-ac10 (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod Unable to handle kernel NULL pointer dereference at virtual address Oops: CPU: 0 EIP: 0010:[c01b9bac] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 eax: 000d ebx: ecx: edx: esi: edi: c1469ae8 ebp: 0021 ebp: cffe5ee0 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=cffe5000) Stack: c0276018 c0275fb4 c01b9dbf c1469a00 c02e31f4 c1469b18 c02e3100 0001 0286 0001 0001 c0113623 c02b5fe1 0246 c0113574 c0244e02 c0244e9d c1469a00 c02e3100 c01b91cb c02448ec c02e3100 c1469037 c0244fc0 Call Trace: [c01b9dbf] [c0113623] [c0113574] [c01b91cb] [c01b8d0c] [c01b976a] [c01b9af1] [c0105007] [c0105488] Code: 8b 04 8a 83 f8 ff 75 0c 83 c6 20 eb e7 8d b4 26 00 00 00 00 EIP; c01b9bac cdrom_get_entry+1c/50 = Trace; c01b9dbf register_cdrom+1bf/250 Trace; c0113623 release_console_sem+73/80 Trace; c0113574 printk+124/130 Trace; c01b91cb ide_cdrom_probe_capabilities+3eb/400 Trace; c01b8d0c ide_cdrom_register+13c/150 Trace; c01b976a ide_cdrom_setup+49a/4e0 Trace; c01b9af1 ide_cdrom_init+e1/180 Trace; c0105007 init+7/110 Trace; c0105488 kernel_thread+28/40 Code; c01b9bac cdrom_get_entry+1c/50 _EIP: Code; c01b9bac cdrom_get_entry+1c/50 = 0: 8b 04 8a movl (%edx,%ecx,4),%eax = Code; c01b9baf cdrom_get_entry+1f/50 3: 83 f8 ff cmpl $0x,%eax Code; c01b9bb2 cdrom_get_entry+22/50 6: 75 0c jne14 _EIP+0x14 c01b9bc0 cdrom_get_entry+30/50 Code; c01b9bb4 cdrom_get_entry+24/50 8: 83 c6 20 addl $0x20,%esi Code; c01b9bb7 cdrom_get_entry+27/50 b: eb e7 jmpfff4 _EIP+0xfff4 c01b9ba0 cdrom_get_entry+10/50 Code; c01b9bb9 cdrom_get_entry+29/50 d: 8d b4 26 00 00 00 00 leal 0x0(%esi,1),%esi 0Kernel panic: Attempted to kill init! - 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/
Parport fifo stuck when printer out of paper
Hi, When my parport printer runs out of paper and there are still pending print jobs, the kernel will constantly log the following: DMA write timed out parport0: FIFO is stuck parport0: BUSY timeout (1) in compat_write_block_pio To me it's pretty pointless to fill dmesg and the logfiles with this rather harmless but still annoying info. Can this possibly be handled in a nicer way, so that the kernel keeps quiet about such minor printer issues? Regards, Udo. - 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: Linux 2.4.2-ac24
Alan Cox wrote: > > 2.4.2-ac24 > 2.4.2-ac23 > o Back out problem via bridge change (me) That fixed the bttv problems I had. I've noticed that there are four VIA vt8363 PCI fixups by now. Are these experimental to see if some people's problems go away or have VIA confirmed that there is a problem? Regards, -Udo. - 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: Linux 2.4.2-ac24
Alan Cox wrote: 2.4.2-ac24 2.4.2-ac23 o Back out problem via bridge change (me) That fixed the bttv problems I had. I've noticed that there are four VIA vt8363 PCI fixups by now. Are these experimental to see if some people's problems go away or have VIA confirmed that there is a problem? Regards, -Udo. - 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: Weird bttv errors and video hangs with 2.4.2-ac21
Alan Cox wrote: > > > With -ac21 I'm getting occasional long delays in video output with xawtv > > or the picture totally freezes until I click with the mouse in the xawtv > > window. dmesg shows: > > You have a VIA chipset ? Yes. Via KT133. lspci output under -ac20: 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: Asustek Computer, Inc.: Unknown device 8033 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- > bttv0: resetting chip > > bttv0: PLL: 28636363 => 35468950 ... ok > > bttv0: irq: OCERR risc_count=0fb54810 > > > > All of this did not happen with -ac20 under the exact same circumstances, > > so -ac21 does something which the bttv driver (0.7.57) doesn't quite like. > > The only candidate I can think of is the pci quirk stuff added for the VIA > chipsets That is probably the problem then. If you have a patch, want me to try something or need more info, just let me know. Regards, Udo. - 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/
Weird bttv errors and video hangs with 2.4.2-ac21
Hi, With -ac21 I'm getting occasional long delays in video output with xawtv or the picture totally freezes until I click with the mouse in the xawtv window. dmesg shows: bttv0: PLL: 28636363 => 35468950 ... ok bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: SCERR risc_count=0fb54810 bttv0: irq: SCERR risc_count=0fb54810 bttv0: aiee: error loops bttv0: resetting chip bttv0: PLL: 28636363 => 35468950 ... ok bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54820 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: SCERR risc_count=0fb54810 bttv0: aiee: error loops bttv0: irq: SCERR risc_count=0c898014 bttv0: aiee: error loops bttv0: resetting chip bttv0: PLL: 28636363 => 35468950 ... ok bttv0: irq: OCERR risc_count=0fb54810 All of this did not happen with -ac20 under the exact same circumstances, so -ac21 does something which the bttv driver (0.7.57) doesn't quite like. Regards, Udo. - 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/
Weird bttv errors and video hangs with 2.4.2-ac21
Hi, With -ac21 I'm getting occasional long delays in video output with xawtv or the picture totally freezes until I click with the mouse in the xawtv window. dmesg shows: bttv0: PLL: 28636363 = 35468950 ... ok bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: SCERR risc_count=0fb54810 bttv0: irq: SCERR risc_count=0fb54810 bttv0: aiee: error loops bttv0: resetting chip bttv0: PLL: 28636363 = 35468950 ... ok bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54820 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: OCERR risc_count=0fb54810 bttv0: irq: SCERR risc_count=0fb54810 bttv0: aiee: error loops bttv0: irq: SCERR risc_count=0c898014 bttv0: aiee: error loops bttv0: resetting chip bttv0: PLL: 28636363 = 35468950 ... ok bttv0: irq: OCERR risc_count=0fb54810 All of this did not happen with -ac20 under the exact same circumstances, so -ac21 does something which the bttv driver (0.7.57) doesn't quite like. Regards, Udo. - 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: Weird bttv errors and video hangs with 2.4.2-ac21
Alan Cox wrote: With -ac21 I'm getting occasional long delays in video output with xawtv or the picture totally freezes until I click with the mouse in the xawtv window. dmesg shows: You have a VIA chipset ? Yes. Via KT133. lspci output under -ac20: 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 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 Region 0: Memory at e000 (32-bit, prefetchable) [size=128M] Capabilities: [a0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate=none Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal decode]) 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 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: e000-dfff Memory behind bridge: d500-d65f Prefetchable memory behind bridge: d7f0-dfff BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: Asustek Computer, Inc.: Unknown device 8033 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 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (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=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 Region 4: I/O ports at d800 [size=16] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 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, cache line size 08 Interrupt: pin D routed to IRQ 9 Region 4: I/O ports at d400 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 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, cache line size 08 Interrupt: pin D routed to IRQ 9 Region 4: I/O ports at d000 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Subsystem: Asustek Computer, Inc.: Unknown device 8033 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 ? routed to IRQ 9 Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- bttv0: resetting chip bttv0: PLL: 28636363 = 35468950 ... ok bttv0: irq: OCERR risc_count=0fb54810 All of this did not happen with -ac20 under the exact same circumstances, so -ac21 does something which the bttv driver
Spurious interrupts
Hi all, After modifying some bios settings and assigning the parallel port IRQ5 instead of the IRQ7 it formerly had, I'm now getting kernel messages like this: spurious 8259A interrupt: IRQ7 IRQ7 is not in use by any device, but interrupts occur. Can someone tell me what's up with that? -Udo. -- /proc/interrupts: CPU0 0: 34556 XT-PIC timer 1:934 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 1340 XT-PIC serial 5: 1 XT-PIC parport0 8: 1 XT-PIC rtc 9:308 XT-PIC eth0, bttv 10: 65134 XT-PIC ide0 11: 0 XT-PIC EMU10K1 12: 3126 XT-PIC PS/2 Mouse 14: 5 XT-PIC ide2 NMI: 0 LOC: 34523 ERR: 9 procinfo: Linux 2.4.1-ac15 (root@Corona) (gcc 2.95.2 19991024 ) #1 Fri Feb 16 08:36:50 CET 2001 1CPU Memory: TotalUsedFree Shared Buffers Cached Mem:22 2521803372 0 100704 84888 Swap: 5241521436 522716 Bootup: Fri Feb 16 13:14:08 2001Load average: 1.11 0.90 0.42 2/71 246 user : 0:00:16.57 4.4% page in : 432579 nice : 0:03:28.11 55.0% page out: 3564 system: 0:00:18.43 4.9% swap in : 816 idle : 0:02:15.58 35.8% swap out: 1381 uptime: 0:06:18.68 context : 187481 irq 0: 37869 timer irq 8: 1 rtc irq 1: 1141 keyboard irq 9: 335 eth0, bttv irq 2: 0 cascade [4] irq 10: 65145 ide0 irq 3: 1550 serialirq 11: 0 EMU10K1 irq 5: 1 parport0 [3] irq 12: 4248 PS/2 Mouse irq 6: 2 irq 14: 5 ide2 irq 7:10 - 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/
Spurious interrupts
Hi all, After modifying some bios settings and assigning the parallel port IRQ5 instead of the IRQ7 it formerly had, I'm now getting kernel messages like this: spurious 8259A interrupt: IRQ7 IRQ7 is not in use by any device, but interrupts occur. Can someone tell me what's up with that? -Udo. -- /proc/interrupts: CPU0 0: 34556 XT-PIC timer 1:934 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 1340 XT-PIC serial 5: 1 XT-PIC parport0 8: 1 XT-PIC rtc 9:308 XT-PIC eth0, bttv 10: 65134 XT-PIC ide0 11: 0 XT-PIC EMU10K1 12: 3126 XT-PIC PS/2 Mouse 14: 5 XT-PIC ide2 NMI: 0 LOC: 34523 ERR: 9 procinfo: Linux 2.4.1-ac15 (root@Corona) (gcc 2.95.2 19991024 ) #1 Fri Feb 16 08:36:50 CET 2001 1CPU Memory: TotalUsedFree Shared Buffers Cached Mem:22 2521803372 0 100704 84888 Swap: 5241521436 522716 Bootup: Fri Feb 16 13:14:08 2001Load average: 1.11 0.90 0.42 2/71 246 user : 0:00:16.57 4.4% page in : 432579 nice : 0:03:28.11 55.0% page out: 3564 system: 0:00:18.43 4.9% swap in : 816 idle : 0:02:15.58 35.8% swap out: 1381 uptime: 0:06:18.68 context : 187481 irq 0: 37869 timer irq 8: 1 rtc irq 1: 1141 keyboard irq 9: 335 eth0, bttv irq 2: 0 cascade [4] irq 10: 65145 ide0 irq 3: 1550 serialirq 11: 0 EMU10K1 irq 5: 1 parport0 [3] irq 12: 4248 PS/2 Mouse irq 6: 2 irq 14: 5 ide2 irq 7:10 - 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: Linux 2.4.1ac9
Hi, Alan Cox wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ > > 2.4.1-ac9 > o Merge with Linus 2.4.2pre2 I've noticed that -ac9 comes with the "Disable PCI-Master-Read-Caching on VIA" patch that Peter Horton posted a while back. I don't know whether it was applied in Linus' or your tree first, but is it actually verified to fix anything? AFAIR Peter Horton later posted that it didn't fix a thing for him and Petr Vandrovec tracked down his corruption issue to a Promise driver problem. I see no corruption with Master-Read-Caching enabled here and unless someone can verify that it really is the culprit, the patch is probably completely redundant. -Udo. - 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: Linux 2.4.1ac9
Hi, Alan Cox wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.1-ac9 o Merge with Linus 2.4.2pre2 I've noticed that -ac9 comes with the "Disable PCI-Master-Read-Caching on VIA" patch that Peter Horton posted a while back. I don't know whether it was applied in Linus' or your tree first, but is it actually verified to fix anything? AFAIR Peter Horton later posted that it didn't fix a thing for him and Petr Vandrovec tracked down his corruption issue to a Promise driver problem. I see no corruption with Master-Read-Caching enabled here and unless someone can verify that it really is the culprit, the patch is probably completely redundant. -Udo. - 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: PS/2 Mouse/Keyboard conflict and lockup
Alan Cox wrote: > > > I'm not sure whether this is related to the ominous ps/2 mouse bug > > you have been chasing, but this problem is 100% reproducible and > > very annoying. > > It isnt but it might be related to which 2.2.19pre you are running (if any) No, at that time I was running 2.4.1-ac5. > Does downgrading the bios fix it. If so then I suspect you need to talk to > the BIOS vendor. You might find that turning off USB legacy keyboard/mouse > emulation helps too Downgrading the Bios does fix it, but that just shadows the ACPI bugs that cause the problem. With 1003 + ACPI, mouse and keyboard both work, but I've seen spurious scancode problems and keyboard weirdness that I reported to lkml a week or two ago. 1005D + ACPI completely mess up PS/2 mouse and keyboard and lock them up after a while. The solution is not to use ACPI until that is fixed. It appears that without ACPI everything is working perfectly. -Udo. - 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: PS/2 Mouse/Keyboard conflict and lockup
"Udo A. Steinberg" wrote: > > I'm not sure whether this is related to the ominous ps/2 mouse bug > you have been chasing, but this problem is 100% reproducible and > very annoying. > > After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no longer > receives any mouse events and the mouse doesn't work in text > consoles. Once I kill gpm and restart gpm -t ps2 the keyboard > locks up. Alright, I found the culprit - ACPI. Once I had compiled the kernel without it, all the problems mysteriously vanished. I knew there was a reason it was marked 'Experimental' :) Sorry for the noise. -Udo. - 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/
PS/2 Mouse/Keyboard conflict and lockup
Hi Alan et. all I'm not sure whether this is related to the ominous ps/2 mouse bug you have been chasing, but this problem is 100% reproducible and very annoying. After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no longer receives any mouse events and the mouse doesn't work in text consoles. Once I kill gpm and restart gpm -t ps2 the keyboard locks up. Logging in remotely and looking at dmesg revealed the following: keyboard: Timeout - AT keyboard not present? keyboard: unrecognized scancode (70) - ignored If I don't kill and restart gpm, but start X, the mouse works perfectly, but only in X. Any ideas? -Udo. - 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: VIA silent disk corruption - fixed for me
Petr Vandrovec wrote: > After upgrading BIOS (it did not help) I decided to switch my secondary > harddisk to master. And voila - hde running UDMA5, hdg running UDMA2 > (hdf/hdh does not exist), whole night stresstests, no corruption. Excellent! > So at least for me it means that Promise Linux driver does not support > slave-only configuration. I did not checked whether master-slave pair > works, but master alone for sure works for me. I have a master-slave configuration. Both are IBM DTLA-307030 in UDMA-5 mode, the master using vfat32, the slave using ext2. Works like a charm. -Udo. - 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: PS/2 Mouse/Keyboard conflict and lockup
"Udo A. Steinberg" wrote: I'm not sure whether this is related to the ominous ps/2 mouse bug you have been chasing, but this problem is 100% reproducible and very annoying. After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no longer receives any mouse events and the mouse doesn't work in text consoles. Once I kill gpm and restart gpm -t ps2 the keyboard locks up. Alright, I found the culprit - ACPI. Once I had compiled the kernel without it, all the problems mysteriously vanished. I knew there was a reason it was marked 'Experimental' :) Sorry for the noise. -Udo. - 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: VIA silent disk corruption - patch
Dale Farnsworth wrote: > > However, if I enable the BIOS parameter "I/O Recovery Time", I can still > enable read caching without seeing any data corruption. > The lastest BIOS revision (1005C) enables "I/O Recovery Time" by default > where the previous revision I had (1004D) did not. Interesting stuff. Asus, Germany released 1005D today. It's available from ftp://ftp.asuscom.de/pub/ASUSCOM/BIOS/Socket_A/VIA_Chipset/Apollo_KT133/A7V/1005D.zip No comments about what they changed and/or fixed. -Udo. - 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: VIA silent disk corruption - bad news
Petr Vandrovec wrote: > > On 5 Feb 01 at 23:08, Udo A. Steinberg wrote: > > > 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) > > Subsystem: Asustek Computer, Inc.: Unknown device 8033 > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- > > Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium > >TAbort- SERR- ^^ > I tried all different settings in BIOS, and I even programmed values > from your lspci to my VIA (except for SDRAM timmings) - and although > it is a bit better, it is not still perfect. > So for today I'm back on [UMS]DMA disabled. I'll try downgrading BIOS > today, but it looks to me like that something is severely broken here. Are your drives connected to the VIA or the Promise controller? Mine are both connected to the PDC20265 and running in UDMA-100 mode. There have been several threads on lkml about corruption on disks connected to Via chipset IDE controllers, although I didn't follow them in great detail. Maybe your problem is not related to the host bridge, but to the IDE controller? -Udo. - 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: VIA silent disk corruption - bad news
Petr Vandrovec wrote: On 5 Feb 01 at 23:08, Udo A. Steinberg wrote: 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 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+ ^^ I tried all different settings in BIOS, and I even programmed values from your lspci to my VIA (except for SDRAM timmings) - and although it is a bit better, it is not still perfect. So for today I'm back on [UMS]DMA disabled. I'll try downgrading BIOS today, but it looks to me like that something is severely broken here. Are your drives connected to the VIA or the Promise controller? Mine are both connected to the PDC20265 and running in UDMA-100 mode. There have been several threads on lkml about corruption on disks connected to Via chipset IDE controllers, although I didn't follow them in great detail. Maybe your problem is not related to the host bridge, but to the IDE controller? -Udo. - 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: VIA silent disk corruption - patch
Dale Farnsworth wrote: However, if I enable the BIOS parameter "I/O Recovery Time", I can still enable read caching without seeing any data corruption. The lastest BIOS revision (1005C) enables "I/O Recovery Time" by default where the previous revision I had (1004D) did not. Interesting stuff. Asus, Germany released 1005D today. It's available from ftp://ftp.asuscom.de/pub/ASUSCOM/BIOS/Socket_A/VIA_Chipset/Apollo_KT133/A7V/1005D.zip No comments about what they changed and/or fixed. -Udo. - 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: VIA silent disk corruption - bad news
"Udo A. Steinberg" wrote: > > FWIW, here's the output of my lspci for A7V with working 1003 BIOS > and still no corruption (after 2 hours stresstest). Bugger, forgot the end bit. Here's it again: 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 05 03 06 00 10 a2 02 00 00 06 00 00 00 00 10: 08 00 00 e0 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 43 10 33 80 30: 00 00 00 00 a0 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: 17 a4 eb b4 06 81 10 10 88 00 04 08 0c 10 10 10 60: 0f ff 0f b0 e6 e6 e5 00 40 78 86 0f 08 7f 00 00 70: de c0 cc 0c 0e a1 d2 00 01 b4 11 02 00 00 00 01 80: 0f 40 00 00 80 00 00 00 03 00 4c 01 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 6a 02 14 00 b0: 5a ec 80 a5 32 33 28 00 00 00 00 00 00 00 00 00 c0: 01 00 02 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 0e 22 00 00 00 00 00 91 06 -Udo. - 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: VIA silent disk corruption - bad news
Peter Horton wrote: > > The patch doesn't work for me. Maybe I need to disable some more of > those North bridge features :-( > > Oh bum. Back to testing with "normal" ... FWIW, here's the output of my lspci for A7V with working 1003 BIOS and still no corruption (after 2 hours stresstest). 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 05 03 06 00 10 a2 02 00 00 06 00 00 00 00 10: 08 00 00 e0 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 43 10 33 80 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 I'll leave the comparing work to you. If you need more info, just holler. -Udo. - 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: VIA silent disk corruption - likely fix
Peter Horton wrote: > > I've found the cause of silent disk corruption on my A7V motherboard, > and it might affect all boards with the same North bridge (KT133 etc). > > For some reason the IDE controller(s) was sometimes picking up stale > data during bus master DMA to the drive. Assuming that there was no bug > in the CPU it had to be the North bridge that was caching the stuff when > it shouldn't have been. I assume the problem would also apply to other > bus masters (SCSI, NIC etc). Do you have a small test program to illustrate that bug? I have an A7V with PCI Master Read Caching enabled and haven't seen any corruption so far (which doesn't necessarily mean much). Or if you don't have a test program, how did you identify it's caching too much? Also, are you using a Thunderbird or a Duron? I'm using the 1003 Bios, which has proven to be the most stable so far. Which one do you use? -Udo. P.S. I seem to recall that later Bios Versions (>=1004) disable Master Read Caching by default, so maybe Asus has also noticed something wrong with 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: VIA silent disk corruption - likely fix
Peter Horton wrote: I've found the cause of silent disk corruption on my A7V motherboard, and it might affect all boards with the same North bridge (KT133 etc). For some reason the IDE controller(s) was sometimes picking up stale data during bus master DMA to the drive. Assuming that there was no bug in the CPU it had to be the North bridge that was caching the stuff when it shouldn't have been. I assume the problem would also apply to other bus masters (SCSI, NIC etc). Do you have a small test program to illustrate that bug? I have an A7V with PCI Master Read Caching enabled and haven't seen any corruption so far (which doesn't necessarily mean much). Or if you don't have a test program, how did you identify it's caching too much? Also, are you using a Thunderbird or a Duron? I'm using the 1003 Bios, which has proven to be the most stable so far. Which one do you use? -Udo. P.S. I seem to recall that later Bios Versions (=1004) disable Master Read Caching by default, so maybe Asus has also noticed something wrong with 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: VIA silent disk corruption - bad news
Peter Horton wrote: The patch doesn't work for me. Maybe I need to disable some more of those North bridge features :-( Oh bum. Back to testing with "normal" ... FWIW, here's the output of my lspci for A7V with working 1003 BIOS and still no corruption (after 2 hours stresstest). 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 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 Region 0: Memory at e000 (32-bit, prefetchable) [size=128M] Capabilities: [a0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate=none Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 05 03 06 00 10 a2 02 00 00 06 00 00 00 00 10: 08 00 00 e0 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 43 10 33 80 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 I'll leave the comparing work to you. If you need more info, just holler. -Udo. - 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: VIA silent disk corruption - bad news
"Udo A. Steinberg" wrote: FWIW, here's the output of my lspci for A7V with working 1003 BIOS and still no corruption (after 2 hours stresstest). Bugger, forgot the end bit. Here's it again: 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 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 Region 0: Memory at e000 (32-bit, prefetchable) [size=128M] Capabilities: [a0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate=none Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 05 03 06 00 10 a2 02 00 00 06 00 00 00 00 10: 08 00 00 e0 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 43 10 33 80 30: 00 00 00 00 a0 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: 17 a4 eb b4 06 81 10 10 88 00 04 08 0c 10 10 10 60: 0f ff 0f b0 e6 e6 e5 00 40 78 86 0f 08 7f 00 00 70: de c0 cc 0c 0e a1 d2 00 01 b4 11 02 00 00 00 01 80: 0f 40 00 00 80 00 00 00 03 00 4c 01 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 6a 02 14 00 b0: 5a ec 80 a5 32 33 28 00 00 00 00 00 00 00 00 00 c0: 01 00 02 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 0e 22 00 00 00 00 00 91 06 -Udo. - 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/
Keyboard Scancode Problems
Hi all, With all the latest kernels (at least since 2.4.0-test12) I have had occasional problems with a PS/2 keyboard when switching back and forth between X and text consoles. In most cases the problem occurs when switching from X to a text console, which renders the keyboard totally unusable. Pressing any key results in ^W ^E and other garbage. Sometimes pressing Ctrl fixes the problem, other times not even SysRq works. The kernel logs the following stuff: keyboard: unrecognized scancode (70) - ignored keyboard: unrecognized scancode (66) - ignored keyboard: unknown scancode e0 71 keyboard: unknown scancode e0 70 and so forth. I cannot reliably reproduce it though. Can someone enlighten me whether this is a keyboard problem, X problem or something wrong with the kernel's console stuff? -Udo. - 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/
Keyboard Scancode Problems
Hi all, With all the latest kernels (at least since 2.4.0-test12) I have had occasional problems with a PS/2 keyboard when switching back and forth between X and text consoles. In most cases the problem occurs when switching from X to a text console, which renders the keyboard totally unusable. Pressing any key results in ^W ^E and other garbage. Sometimes pressing Ctrl fixes the problem, other times not even SysRq works. The kernel logs the following stuff: keyboard: unrecognized scancode (70) - ignored keyboard: unrecognized scancode (66) - ignored keyboard: unknown scancode e0 71 keyboard: unknown scancode e0 70 and so forth. I cannot reliably reproduce it though. Can someone enlighten me whether this is a keyboard problem, X problem or something wrong with the kernel's console stuff? -Udo. - 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: Request: increase in PCI bus limit
Christopher Neufeld wrote: > The only patch > which has to be applied to make Linux run stably on these systems is to > increase that limit. Would it be possible to bump it up to 128, or even > 256, in later 2.4.* kernel releases? That would allow this customer to > work with an unpatched kernel, at the cost of an additional 3.5 kB of > variables in the kernel. I guess the cleanest solution would be to allow variable setting of the maximum number of PCI busses in the config file, similar to the CONFIG_UNIX98_PTY_COUNT setting, so that "exotic" users with 32+ PCI busses can boost the standard value according to their needs, without having to increase kernel size for the normal users. Regards, Udo. - 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: Request: increase in PCI bus limit
Christopher Neufeld wrote: The only patch which has to be applied to make Linux run stably on these systems is to increase that limit. Would it be possible to bump it up to 128, or even 256, in later 2.4.* kernel releases? That would allow this customer to work with an unpatched kernel, at the cost of an additional 3.5 kB of variables in the kernel. I guess the cleanest solution would be to allow variable setting of the maximum number of PCI busses in the config file, similar to the CONFIG_UNIX98_PTY_COUNT setting, so that "exotic" users with 32+ PCI busses can boost the standard value according to their needs, without having to increase kernel size for the normal users. Regards, Udo. - 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: eepro100 - Linux vs. FreeBSD
Sergey Kubushin wrote: > > The older chips (e.g. 82557) work fine. The problem arises when you have the > newer 82559's. They do work, however, if the power management for eepro100 > is enabled in kernel config. It definitely means that those chips are > underinitialized (or overinitialized :)) when it's not. Andrey posted a patch last week, which obviously fixes the 82559 problems. It's in Linus' latest 2.4.1-pre release too. I have an 82559 and with the patch there've been no issues here yet - so things are looking good so far. I suggest that instead of having 3 drivers (eepro100, e100, freebsd), people should just work together, look at the goodies of each driver and merge them into one perfect driver. Regards, -Udo. - 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: eepro100 - Linux vs. FreeBSD
Sergey Kubushin wrote: The older chips (e.g. 82557) work fine. The problem arises when you have the newer 82559's. They do work, however, if the power management for eepro100 is enabled in kernel config. It definitely means that those chips are underinitialized (or overinitialized :)) when it's not. Andrey posted a patch last week, which obviously fixes the 82559 problems. It's in Linus' latest 2.4.1-pre release too. I have an 82559 and with the patch there've been no issues here yet - so things are looking good so far. I suggest that instead of having 3 drivers (eepro100, e100, freebsd), people should just work together, look at the goodies of each driver and merge them into one perfect driver. Regards, -Udo. - 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/
[OOPS] with 2.2.18
Hello,
Below is a decoded oops from a standard 2.2.18 kernel.
If you need any additional info, please let me know.
Regards,
Udo.
ksymoops 2.3.5 on i686 2.2.18. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.18/ (default)
-m /boot/System.map-2.2.18 (specified)
Unable to handle kernel NULL pointer dereference at virtual address 0001
current->tss.cr3 = 051f3000, %cr3 = 051f3000
*pde =
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 0001 ebx: c5ffe5c0 ecx: edx: cb1bec60
esi: c01fde25 edi: c01fde28 ebp: esp: c3037f4c
ds: 0018 es: 0018 ss: 0018
Process sslwrap (pid: 10350, process nr: 44, stackpage=c3037000)
Stack: ca85dd1c bc68 c5ffe620 c0131028 c01fde28 cb1beae0 0003
c01796d8 ca85dd1c 080ae3d6 c0179eb3 ca85dd1c
ca85ddbc c017ab34 0002 0001 c3036000 0002
Call Trace: [] [] [] [] []
[] []
Code: 89 00 44 8b 47 08 89 43 48 00 43 50 00 00 00 00 c7 00 5c 00
>>EIP; c0130fc0<=
Trace; c0131028
Trace; c01fde28
Trace; c01796d8
Trace; c0179eb3
Trace; c017ab34
Trace; c01094bd
Trace; c01093ac
Code; c0130fc0
<_EIP>:
Code; c0130fc0<=
0: 89 00 movl %eax,(%eax) <=
Code; c0130fc2
2: 44incl %esp
Code; c0130fc3
3: 8b 47 08 movl 0x8(%edi),%eax
Code; c0130fc6
6: 89 43 48 movl %eax,0x48(%ebx)
Code; c0130fc9
9: 00 43 50 addb %al,0x50(%ebx)
Code; c0130fcc
c: 00 00 addb %al,(%eax)
Code; c0130fce
e: 00 00 addb %al,(%eax)
Code; c0130fd0
10: c7 00 5c 00 00 00 movl $0x5c,(%eax)
-
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/
[OOPS] with 2.2.18
Hello,
Below is a decoded oops from a standard 2.2.18 kernel.
If you need any additional info, please let me know.
Regards,
Udo.
ksymoops 2.3.5 on i686 2.2.18. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.18/ (default)
-m /boot/System.map-2.2.18 (specified)
Unable to handle kernel NULL pointer dereference at virtual address 0001
current-tss.cr3 = 051f3000, %cr3 = 051f3000
*pde =
Oops: 0002
CPU:0
EIP:0010:[c0130fc0]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 0001 ebx: c5ffe5c0 ecx: edx: cb1bec60
esi: c01fde25 edi: c01fde28 ebp: esp: c3037f4c
ds: 0018 es: 0018 ss: 0018
Process sslwrap (pid: 10350, process nr: 44, stackpage=c3037000)
Stack: ca85dd1c bc68 c5ffe620 c0131028 c01fde28 cb1beae0 0003
c01796d8 ca85dd1c 080ae3d6 c0179eb3 ca85dd1c
ca85ddbc c017ab34 0002 0001 c3036000 0002
Call Trace: [c0131028] [c01fde28] [c01796d8] [c0179eb3] [c017ab34]
[c01094bd] [c01093ac]
Code: 89 00 44 8b 47 08 89 43 48 00 43 50 00 00 00 00 c7 00 5c 00
EIP; c0130fc0 d_alloc+12c/150 =
Trace; c0131028 d_alloc_root+18/3c
Trace; c01fde28 cprt+168/b316
Trace; c01796d8 get_fd+54/d0
Trace; c0179eb3 sys_socket+33/78
Trace; c017ab34 sys_socketcall+64/1e0
Trace; c01094bd error_code+2d/34
Trace; c01093ac system_call+34/38
Code; c0130fc0 d_alloc+12c/150
_EIP:
Code; c0130fc0 d_alloc+12c/150 =
0: 89 00 movl %eax,(%eax) =
Code; c0130fc2 d_alloc+12e/150
2: 44incl %esp
Code; c0130fc3 d_alloc+12f/150
3: 8b 47 08 movl 0x8(%edi),%eax
Code; c0130fc6 d_alloc+132/150
6: 89 43 48 movl %eax,0x48(%ebx)
Code; c0130fc9 d_alloc+135/150
9: 00 43 50 addb %al,0x50(%ebx)
Code; c0130fcc d_alloc+138/150
c: 00 00 addb %al,(%eax)
Code; c0130fce d_alloc+13a/150
e: 00 00 addb %al,(%eax)
Code; c0130fd0 d_alloc+13c/150
10: c7 00 5c 00 00 00 movl $0x5c,(%eax)
-
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/
Process hung in "D" state with 2.2.18
Hello, I've got a sendmail 8.1.11 process hanging in D state with 2.2.18. ps -eo fname,tty,pid,stat,pcpu,nwchan,wchan reveals the following: PID STAT %CPU WCHAN WIDE-WCHAN-COLUMN COMMAND 16176 D 0.0 1f4c28 down_failed sendmail: startup with ... Is this likely a bug in the kernel or in sendmail? Also let me know what additional info I could provide to help track down the bug. Regards, Udo. - 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/
Process hung in D state with 2.2.18
Hello, I've got a sendmail 8.1.11 process hanging in D state with 2.2.18. ps -eo fname,tty,pid,stat,pcpu,nwchan,wchan reveals the following: PID STAT %CPU WCHAN WIDE-WCHAN-COLUMN COMMAND 16176 D 0.0 1f4c28 down_failed sendmail: startup with ... Is this likely a bug in the kernel or in sendmail? Also let me know what additional info I could provide to help track down the bug. Regards, Udo. - 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-pre1 breaks XFree 4.0.2 and "w"
Linus Torvalds wrote: > > Could people with Athlons please verify that pre3 works for them? It works very well wrt. fxsr. -Udo. - 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: Strange umount problem in latest 2.4.0 kernels
[EMAIL PROTECTED] wrote: > > These days umount is done by directory, not by device, > since a device may be mounted multiple times, so > I expect the silly message is gone. > (Is your umount recent?) > > [But this is only about the "none". I don't know what is > wrong in your situation.] My umount is 2.10r. Alan says he knows what is wrong, so we're all curiously expecting -ac7 ;) -Udo. - 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: Strange umount problem in latest 2.4.0 kernels
"Udo A. Steinberg" wrote: > > The very strange stuff is umount at reboot: > > umount: none busy - remounted read-only > umount: /: device is busy > Remounting root-filesystem read-only > mount: / is busy > Rebooting. I just noticed another strange effect: ps uxa misses a couple dozen processes. Effectively I'm seeing only the kernel processes, all gettys, rpc.portmap, bash and ps. All other processes, all daemons etc. are invisible. If I kill portmap another process becomes visible. I've checked a couple of other machines, different setups etc. all with -ac6 and all show this behavior - also the umount stuff. -Udo. - 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: Strange umount problem in latest 2.4.0 kernels
Alexander Viro wrote: > > umount: none busy - remounted read-only > > > The "none" bit puzzles me the most. /etc/fstab and /etc/mtab > > look perfectly ok. > > > > Has anyone got an idea? Everything worked well with 2.4.0 and > > Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes > > up now. > > Try to revert to -ac4 fs/super.c and see if it helps That makes no difference. Still acting weird. Must be something else. -Udo. - 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: Strange umount problem in latest 2.4.0 kernels
> /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED Ok, culprit identified: /var/spool/lpd/lpd.lock On another partition I had the same problem with httpd's error_log. Since both of those seem to be log- and lock-files, maybe there's something wrong with file locking? Anyway, disabled both lpd and httpd from the startup scripts and now the bug is triggered *every* time. I cannot reboot a single time without partitions being busy. When neither lpd nor httpd run, fsck finds nothing wrong. The very strange stuff is umount at reboot: umount: none busy - remounted read-only umount: /: device is busy Remounting root-filesystem read-only mount: / is busy Rebooting. *fsck* The "none" bit puzzles me the most. /etc/fstab and /etc/mtab look perfectly ok. Has anyone got an idea? Everything worked well with 2.4.0 and Alan's tree up to -ac4, didn't try ac5, and ac6 is what messes up now. -Udo. - 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/
Strange umount problem in latest 2.4.0 kernels
As previously reported by someone, there are occasional problems when shutting down with unmounting partitions, that are reported as busy for strange reasons. Keith Owens said it was supposedly a Redhat shutdown script issue and I since I'm not using Redhat, it's most likely not that. Upon fscking after reboot, I always have errors on a single inode and it's always the same one: /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED Can someone tell me an easy and reliable way of figuring out which file (program) uses said inode? I think that's probably the key to figuring out why the partition is busy on umount. -Udo. - 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/
[OOPS] APIC on Athlon [was Re: Linux 2.4.0-ac6]
"Udo A. Steinberg" wrote: > > Alan Cox wrote: > > > > 2.4.0-ac6 > > o Fix athlon crash on boot with local apic/nmi(Ingo Molnar) > > Still crashes here with -ac6 on my Athlon. I'll have to write down the > oops by hand later on or set up a serial console, but once that's done > I'll post the trace - unless someone already knows what's still wrong > with it. Ok, here goes: Right before it oopses, I can still read the following info on the console which might be of help to someone: Getting VERSION: 40010 Getting VERSION: 40010 Getting ID: 0 Getting ID: f00 Getting LVT0: 700 Getting LVT1: 400 enabling Ext INT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: general protection fault: ksymoops 2.3.7 on i686 2.4.0. Options used -V (default) -K (specified) -L (specified) -o /lib/modules/2.4.0-ac6 (specified) -m /boot/System.map-2.4.0-ac6 (specified) No modules in ksyms, skipping objects CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: ecx: 0186 edx: esi: 0004 edi: c0105000 ebp: 0008e000 esp: c02a1fc0 ds: 0018es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02a1000) Stack: c02a787b ffec 00099800 c02a7ae3 c02a27f5 c02a2900 c022f620 ffec ffec ffec ffec ffec c02d8ce0 c0100192 Call Trace: [] Code: 0f 30 41 0f 30 b9 c1 00 00 00 0f 30 b9 c2 00 00 00 0f 30 b8 >>EIP; c011174a<= Trace; c0100192 Code; c011174a <_EIP>: Code; c011174a<= 0: 0f 30 wrmsr <= Code; c011174c 2: 41incl %ecx Code; c011174d 3: 0f 30 wrmsr Code; c011174f 5: b9 c1 00 00 00movl $0xc1,%ecx Code; c0111754 a: 0f 30 wrmsr Code; c0111756 c: b9 c2 00 00 00movl $0xc2,%ecx Code; c011175b 11: 0f 30 wrmsr Code; c011175d 13: b8 00 00 00 00movl $0x0,%eax Kernel panic: Attempted to kill the idle task! -Udo. - 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: Linux 2.4.0-ac6
Alan Cox wrote: > > 2.4.0-ac6 > o Fix athlon crash on boot with local apic/nmi(Ingo Molnar) Still crashes here with -ac6 on my Athlon. I'll have to write down the oops by hand later on or set up a serial console, but once that's done I'll post the trace - unless someone already knows what's still wrong with it. -Udo. - 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/
