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: 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: 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 s
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: [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: [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
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 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
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
#include
#include
+#include
#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: 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
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/
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: 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/
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/
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: 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/
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: 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: 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
"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/
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: 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/
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/
Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"
Andi Kleen wrote: > > Did you have CONFIG_X86_FXSR or CONFIG_X86_RUNTIME_FXSR enabled when it > worked? > > If not it probably means that the XServer is testing OSFXSR and the branch > that handles it doesn't work. --- linux-2.4.0/.config Thu Jan 11 11:22:11 2001 +++ linux-2.4.1/.config Thu Jan 11 11:24:56 2001 @@ -27,7 +27,7 @@ # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set -# CONFIG_M686FXSR is not set +# CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y The only difference between the two .config files is shown above. 2.4.0 works, 2.4.1 doesn't. And it's not just the X server acting funny. -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: > > Mind trying it with the "HAVE_FXSR" and "HAVE_XMM" macros in > > linux/include/asm-i386/processor.h > > fixed? They _should_ be just > > #define HAVE_FXSR (cpu_has_fxsr) > #define HAVE_XMM(cpu_has_xmm) That doesn't help either. -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"
Hi, Ingo Oeser wrote: > > The only thing that looks responsible for this is the FXSR stuff, > that changed. > > Like to try again backing this out? Just to make sure it wasn't a gcc thing, I've recompiled the original setup with egcs-1.1.2 (previously had used 2.95.2) and that did not fix a thing. Next backed out the entire XMM and FXSR related stuff and now everything is fine again. The CPU in question is an AMD Thunderbird (see cpuinfo below). A friend with a similar setup but a Pentium-3 CPU doesn't seem to see the problem (couldn't verify myself). /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 807.211 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 1608.90 Who wrote that new FXSR stuff? Maybe they have an idea of what's going on. 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/
2.4.1-pre1 breaks XFree 4.0.2 and "w"
Hi all, As I just found out, Linux 2.4.1-pre1 breaks several things on my system that worked perfectly in 2.4.0-final and the entire 2.4.0-ac tree. XFree 4.2.0 now fails to detect monitor timings and therefore removes all modelines and bails out. The relevant diff of the X logfile follows. Note the "nan" bits. < (II) NV(0): Gamma: 1.80 --- > (II) NV(0): Gamma: nan 385,386c385,386 < (II) NV(0): redX: 0.625 redY: 0.340 greenX: 0.285 greenY: 0.600 < (II) NV(0): blueX: 0.150 blueY: 0.065 whiteX: 0.283 whiteY: 0.298 --- > (II) NV(0): redX: 0.625 redY: nan greenX: 0.285 greenY: 0.600 > (II) NV(0): blueX: 0.150 blueY: nan whiteX: 0.283 whiteY: 0.298 424c424 < (II) NV(0): Clock range: 12.00 to 350.00 MHz --- > (II) NV(0): Clock range:nan tonan MHz Moreover, with 2.4.1-pre1 the "w" command behaves in mysterious ways: Normal output is something like: USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root tty1 - 2:23pm 4:41 0.03s 0.03s -bash With 2.4.1-pre1 things look like: USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root tty1 - 2:21pm ? 0.2147483648s 0.01s w I'm not sure I need it so precise :-) Since the 2.4.1-pre1 patch is rather small, it shouldn't be too hard to hunt down the part that causes these oddities. 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: Oops in prune_dcache (2.4.0-prerelease)
Hi, Alexander Viro wrote: > > In principle, it might be that d_find_alias() is broken. I don't see where > it could happen, but then I'm half-asleep right now... While we are at it, > do you have > * autofs Yes. > * knfsd > * ncpfs No, neither of these two. -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: Oops in prune_dcache (2.4.0-prerelease)
Dan Aloni wrote: > > After a bit of few code reviewing, it looks like the only code that > assigns stuff to ->d_op in a nonstandard way is in fs/vfat/namei.c. > > Udo, are you using vfat? Yes. -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: Oops in prune_dcache (2.4.0-prerelease)
Hi, Linus Torvalds wrote: > > The strange thing is that 0x0100 value, which almost certainly should > just be NULL. A one-bit error. > > Now, I assume this machine has been historically stable, with no history > of memory corruption problems.. It's entirely possible (and likely) that > the one-bit error is due to some wild kernel pointer. Which makes this > _really_ hard to debug. Yes the machine is otherwise rock stable, not overclocked and memory timings are rather conservative. Before the oops the machine had been compiling some major application for like 5 hours and maybe the excessive stress kicked a bit somewhere - who knows. > I'll try to think about it some more, but I'd love to have more reports to > go on to try to find a pattern.. That's one I can't reproduce. I've just run memtest86 over the entire ram and it doesn't show any oddities - which doesn't really rule out an occassional bit-flip due to neutrino storms though ;-) If someone else has seen something similar lately, it's time to speak up. -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 in prune_dcache (2.4.0-prerelease)
Hi Linus et. all While under massive disk and cpu load, 2.4.0-prerelease produced the following oops (decode see below) Keith, I've read the FAQ about having been bitten by Makefile bugs with certain symbols and such, yet I still get these symbol warnings even after a mrproper rebuild. Any clues? -Udo. ksymoops 2.3.5 on i686 2.4.0-prerelease. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-prerelease/ (default) -m /boot/System.map-2.4.0-prerelease (specified) Warning (compare_maps): ksyms_base symbol acpi_clear_event_R__ver_acpi_clear_event not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_cm_memcpy_R__ver_acpi_cm_memcpy not found in System.map. Ignoring ksyms_base entry [ ** many other warnings snipped to reduce spam ** ] Unable to handle kernel paging request at virtual address 0114 c01419cc *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 0100 ebx: c20847e0 ecx: c2081d10 edx: c2081d10 esi: c20847c0 edi: c2081d00 ebp: 2c79 esp: c147bfa4 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 3, stackpage=c147b000) Stack: 00010f00 0003 0004 c0141cc1 6ea6 c012a0d3 0006 0004 00010f00 c023e1f1 c147a239 0008e000 c012a19a 0004 cffe5fbc c0105000 ff9c c01074d3 c02d6d64 c02a5fdc Call Trace: [] [] [] [] [] [] Code: 8b 40 14 85 c0 74 09 57 56 ff d0 83 c4 08 eb 0c 57 e8 be 1b >>EIP; c01419cc<= Trace; c0141cc1 Trace; c012a0d3 Trace; c023e1f1 Trace; c012a19a Trace; c0105000 Trace; c01074d3 Code; c01419cc <_EIP>: Code; c01419cc<= 0: 8b 40 14 movl 0x14(%eax),%eax <= Code; c01419cf 3: 85 c0 testl %eax,%eax Code; c01419d1 5: 74 09 je 10 <_EIP+0x10> c01419dc Code; c01419d3 7: 57pushl %edi Code; c01419d4 8: 56pushl %esi Code; c01419d5 9: ff d0 call *%eax Code; c01419d7 b: 83 c4 08 addl $0x8,%esp Code; c01419da e: eb 0c jmp1c <_EIP+0x1c> c01419e8 Code; c01419dc 10: 57pushl %edi Code; c01419dd 11: e8 be 1b 00 00call 1bd4 <_EIP+0x1bd4> c01435a0 45 warnings issued. Results may not be reliable. - 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 when mounting cdrom
Hi all, When mounting a 700 MB CD-RW in my Plextor CD-ROM, my machine reliably oopses. Below is the first oops decoded. Can someone explain to me what all those ksymoops warnings are about? -Udo. ksymoops 2.3.5 on i686 2.4.0-test13-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test13-pre4/ (default) -m /usr/src/linux/System.map (specified) Warning (compare_maps): ksyms_base symbol acpi_clear_event_R__ver_acpi_clear_event not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_cm_memcpy_R__ver_acpi_cm_memcpy not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_cm_memset_R__ver_acpi_cm_memset not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_cm_strncmp_R__ver_acpi_cm_strncmp not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_dbg_layer_R__ver_acpi_dbg_layer not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_dbg_level_R__ver_acpi_dbg_level not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_disable_event_R__ver_acpi_disable_event not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_enable_event_R__ver_acpi_enable_event not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_evaluate_object_R__ver_acpi_evaluate_object not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_current_resources_R__ver_acpi_get_current_resources not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_handle_R__ver_acpi_get_handle not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_name_R__ver_acpi_get_name not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_next_object_R__ver_acpi_get_next_object not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_object_info_R__ver_acpi_get_object_info not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_parent_R__ver_acpi_get_parent not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_possible_resources_R__ver_acpi_get_possible_resources not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_processor_cx_info_R__ver_acpi_get_processor_cx_info not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_processor_throttling_info_R__ver_acpi_get_processor_throttling_info not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_processor_throttling_state_R__ver_acpi_get_processor_throttling_state not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_type_R__ver_acpi_get_type not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_install_address_space_handler_R__ver_acpi_install_address_space_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_install_gpe_handler_R__ver_acpi_install_gpe_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_install_notify_handler_R__ver_acpi_install_notify_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_breakpoint_R__ver_acpi_os_breakpoint not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_callocate_R__ver_acpi_os_callocate not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_free_R__ver_acpi_os_free not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_in8_R__ver_acpi_os_in8 not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_out8_R__ver_acpi_os_out8 not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_printf_R__ver_acpi_os_printf not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_queue_for_execution_R__ver_acpi_os_queue_for_execution not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_sleep_R__ver_acpi_os_sleep not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_sleep_usec_R__ver_acpi_os_sleep_usec not found in System.map. Ignoring ksyms_base entr
New discoveries in the EEPro100 init saga
Hi all, After enabling the option "EEPRO100_PM" and upgrading to test13-pre4 my problems with the eepro100 driver mysteriously ceased to exist. I no longer see any "Card reports no RX buffers" or "Card reports no resources" messages. Since I don't think -pre4 changed anything from -pre3 that would affect the eepro100 driver, my bet is that enabling the experimental power management feature somehow works around the issue. Can others who've had similar problems check if that works for them as well? If it does, it should be somewhat simple to work out what the problem actually is, because the PM code is just a couple dozen lines. Merry X-mas! -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/
[PATCH] Make drivers/media compile as modules
Hi Linus, The Makefile changes broke compiling drivers/media, such as bttv, as kernel modules. Below is the patch against test13-pre3 to fix it. Please apply. -Udo. --- /sources/linux/drivers/media/Makefile Thu Dec 21 08:17:17 2000 +++ /usr/src/linux/drivers/media/Makefile Thu Dec 21 08:15:55 2000 @@ -10,8 +10,10 @@ # subdir-y := video radio +subdir-m := video radio O_TARGET := media.o obj-y:= $(join $(subdir-y),$(subdir-y:%=/%.o)) +obj-m:= $(join $(subdir-m),$(subdir-m:%=/%.o)) include $(TOPDIR)/Rules.make - 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 driver update for 2.4
Ion Badulescu wrote: > This is an i82559 C-step. What kind of switch is it attached to? It's a 3Com FDDI/Ethernet Linkswitch 2200 Rev 2.8 > Also, if you feel like experimenting, edit speedo_interrupt() and change > outw(status & 0xfc00, ioaddr + SCBStatus); > to > outw(status & 0xff00, ioaddr + SCBStatus); [rest snipped] Ok, I'll try that this afternoon and post the results, since it's 4:30am now and I have yet to try the sleep thing. -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 driver update for 2.4
Hi, Anton Altaparmakov wrote: > Just to say that the patch (including added 4) fixed the "card reports no > resources" messages for me. - Looking at my logs the messages appeared once > every 10-40 minutes. - Now the box is up for more than 5 hours with the > patch and test12-pre7 and not a single no resources message logged so far. > (Note, I upgraded the kernel at the same time as adding the patch so it is > actually possible that test12-pre7 vanilla is fixed as well.) The problem here only ever happens at initialisation/first packets. Once the network interface has been initialised properly it never produces those messages anymore. Usually it helps to shut the NIC down with ifconfig and bringing it back up afterwards to properly initialise it. If you are bored, try to reboot a couple dozen times and see if you still see it. I have test12-pre7 also. > My card is an Ether Express Pro 100, lcpci says: Intel Corporation 82557 > [Ethernet Pro 100] (rev 04) and lspci -n gives: class 0200: 10b7:9004 Mine's a rev 08. 00:0d.0 Class 0200: 8086:1229 (rev 08) -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 driver update for 2.4
Ion Badulescu wrote: > > Ok. Can you send me the entire dump? Also, it would be helpful if you > could try to determine when exactly it happens (upon insmod, upon ifconfig > up, or upon receiving some packets later). I have the eepro driver compiled into a monolithic kernel. After rebooting a couple dozen times trying to find a pattern I can't see one, except for one fact worth noticing. As long as the network cable is pulled, everything's groovy. Kernel boots nicely without triggering it, ifconfig doesn't trigger it, route doesn't trigger it, but putting the cable in, immediately triggers it upon packet traffic. * put cable in * eth0: card reports no RX buffers. eth0: card reports no resources. eth0: card reports no RX buffers. eth0: card reports no resources. :> ifconfig eth0 down eth0: 0 multicast blocks dropped. Is it worth analyzing packet traffic and comparing with the timestamps in syslog to see what kind of packet triggers it, or whether any packet triggers it? > Stupid question: are you sure this is not due to the DNS server being > unreachable?... Maybe due to the issues with the NIC. All interesting hosts are now in /etc/hosts, so we'll see. Other stuff that might be of interest: PCI Info: Bus 0, device 13, function 0: Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 8). IRQ 9. Master Capable. Latency=32. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xd480 [0xd4800fff]. I/O at 0x9800 [0x983f]. Non-prefetchable 32 bit memory at 0xd400 [0xd40f]. Card shares IRQ 9 with 2 other devices: irq 9: 620 acpi, bttv, eth0 Need any other info? -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 driver update for 2.4
Ion Badulescu wrote: > The fact that apparently only the people using 82559 chips are seeing this > seems to confirm my analysis above. > > If you could try the attached patch (and maybe pass it onto the other > people who are experiencing this problem), that would be great. > + /* disable advertising the flow-control capability */ > + sp->advertising &= ~0x0400; > + mdio_write(ioaddr, sp->phy[0] & 0x1f, sp->advertising); ^^^ missing a 4 here? I've tried the patch putting a 4 in the place noted above. It doesn't help with the issue at all. Also interesting is the fact that my kernel hangs upon bootup around starting syslogd/klogd or around setting up the NIC (haven't quite figured out), if I pull the network plug and continues when I plug it back in. -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: [PATCH] Re: fs corruption with invalidate_buffers()
Jan Niehusmann wrote:
>
> The following patch actually prevents the corruption I described.
>
> I'd like to hear from the people having problems with hdparm, if it helps
> them, too.
Yes, it prevents the issue.
> Please note that the patch circumvents the problem more than it fixes it.
> The true fix would invalidate the mappings, but I don't know how to do it.
I don't know either. What does Alexander Viro say to all of this?
-Udo.
Same debug patch adapted to test12-pre7 follows:
--- linux/fs/buffer.c Thu Dec 7 22:55:54 2000
+++ /usr/src/linux/fs/buffer.c Thu Dec 7 22:49:02 2000
@@ -627,7 +627,7 @@
then an invalidate_buffers call that doesn't trash dirty buffers. */
void __invalidate_buffers(kdev_t dev, int destroy_dirty_buffers)
{
- int i, nlist, slept;
+ int i, nlist, slept, db_message = 0;
struct buffer_head * bh, * bh_next;
retry:
@@ -653,9 +653,13 @@
write_lock(&hash_table_lock);
if (!atomic_read(&bh->b_count) &&
(destroy_dirty_buffers || !buffer_dirty(bh))) {
- remove_inode_queue(bh);
- __remove_from_queues(bh);
- put_last_free(bh);
+ if (bh->b_page && bh->b_page->mapping)
+ db_message = 1;
+ else {
+ remove_inode_queue(bh);
+ __remove_from_queues(bh);
+ put_last_free(bh);
+ }
}
/* else complain loudly? */
@@ -668,6 +672,8 @@
spin_unlock(&lru_list_lock);
if (slept)
goto retry;
+ if (db_message)
+ printk("invalidate_buffers with mapped page!\n");
}
void set_blocksize(kdev_t dev, int size)
-
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: Trashing ext2 with hdparm
Hi, Andre Hedrick wrote: > > No way that this could cause corruption it is a read-only test. As others pointed out, it's probably something related to shared memory, but it's definitely hdparm that triggers it. I haven't got the hdparm sources here to look at what exactly it's doing, but there is corruption going on, not on disk, but definitely in memory. -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/
Trashing ext2 with hdparm
Hi, Following the discussion in another thread where someone reported fs corruption when enabling DMA with hdparm, I've played around with hdparm and found that even the rather harmless hdparm operations are capable of trashing an ext2 filesystem quite nicely. hdparm version is 3.9 hdparm -tT /dev/hdb1 does the trick here. After that, several files are corrupted, such as /etc/mtab. Reboot+fsck fixes the problem, however e2fsck never finds any errors in the fs on disk. I'm quite sure that earlier kernel versions didn't exhibit this kind of behaviour, although I'm not quite sure at which point things started to break. I have test12-pre6 here atm, but I have test-11 still lying around and will test that in a bit. The drive in question is an IBM-DTLA307030 running in UDMA Mode 5 on a PDC20265, chipset revision 2. I haven't seen any other corruption other than that which hdparm reliably triggers. Might as well be a bug in hdparm, so someone else might also want to check... -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: system hang and corrupt ext2 filesystem with test12-pre5
Skip Collins wrote: > > I have a 900MHz Athlon/Asus A7V mobo system with an onboard ata100 > promise controller. I have only had problems when my ata100/udma5 > harddrive is connected to the promise controller. Using the ATA66 ide > bus eliminates the problem. I typically see the corruption when copying > large (~1GB) files such as vmware virtual disks. It also happens > frequently inside vmware when doing heavy disk access things like > installing software or defragging a win2000 virtual disk. I also have an A7V and both of my IBM IDE drives are connected to the Promise controller, running in UDMA-5 mode. There hasn't been any corruption on either of the drives that had to do with UDMA-5 mode. And the ext2 bugs that 2.4 kernels had, have been fixed in the latest versions. What drive are you using? AFAIR, Andre Hedrick once said certain Maxtor drives aren't quite safe with DMA. -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 driver update for 2.4
Ion Badulescu wrote: > > Do you know if only one specific chip revision exhibits this problem? It > would really help track down the problem. If I remember correctly, 82557 > doesn't have flow control at all, and 82558/9 have different > implementations -- one is proprietary (82558) and one is standard (82559). 82559 has this problem for sure. -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 driver update for 2.4
Andrey Savochkin wrote: > > > eth0: card reports no RX buffers. > > eth0: card reports no resources. > It's a known issue. > I've been promised that this issue would be looked up in Intel's errata by > people who had the access to it, but I haven't got the results yet. I just figured out something interesting. Apparently there's a small timing problem with setting up the NIC: If I put in a sleep 1 between setting up the interface and setting up the gateway route, everything works pretty well. So things now look like this: /sbin/ifconfig lo 127.0.0.1 /sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo /sbin/ifconfig eth0 a.b.c.d broadcast x.y.225.255netmask 255.255.255.0 /sbin/ifconfig eth0:0 a.b.c.d broadcast 172.16.255.255 netmask 255.255.0.0 sleep 1 # This does the trick /sbin/route add default gw a.b.c.d netmask 0.0.0.0 metric 1 > The card itself doesn't report its revision in details. > It can be checked by `lspci'. > Rev 8 is 82559, if I remember, and rev 9 is 82559ER. http://support.intel.com/support/network/adapter/pro100/21397.htm has a list of Board-Assembly IDs and the corresponding chip revisions. 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 driver update for 2.4
Andrey Savochkin wrote: > I've updated eepro100 driver for 2.4 kernel branch. > So far, the most annoying initialization problem (expressing itself in "card > reports no resources" messages) hasn't been fixed. Hi Andrey, I've been using an older EEPro100/B card until now and it's been working without any problems ever since the transmitter bugs were fixed. The boot output looked like this: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.35 $ 2000/11/17 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:A0:C9:41:F4:DE, IRQ 9. Board assembly 667280-003, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x49caa8d6). Receiver lock-up workaround activated. Intel webpage says: 667280-xxx is a model EEPro100/B but I dunno which chipset. Today I've installed a new model with Wake-on-LAN support and got caught by above mentioned eth0: card reports no RX buffers. eth0: card reports no resources. messages as well. Strangely those messages only ever happen during bootup and *every* time. Shutting eth0 down and bringing it back up fixes the problem. What puzzles me a bit is that the newer card (721383-xxx) is an 82559 chip, according to the Intel site, but the boot output doesn't say so: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.35 $ 2000/11/17 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:02:B3:1F:BA:5D, IRQ 9. Receiver lock-up bug exists -- enabling work-around. Board assembly 721383-016, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x04f4518b). If you have any patches or tests that would help to find and fix this init bug, I'd offer to test them out, since I can reliably reproduce the problem. 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: Freeze on FPU exception with Athlon
Markus Schoder wrote: > My test program caused the exception (and the freeze) > unintendedly in the return statement since the > division was optimized away as Brian pointed out. It's quite strange that I cannot seem to trigger the problem here on my machine. > I know of another guy with the exact same CPU (Athlon > Thunderbird 900MHz) and mainboard (ABIT KT7-RAID) who > has the same problem. > > I use gcc 2.95.2 to compile the kernel. Makes me wonder whether it could be an issue with your board (I have an Asus A7V) or with gcc 2.95-2 (I use egcs-1.1.2). > Note that cpuinfo shows model 4 whereas e.g. Brian had > model 2 if that means anything. Mine is a model 4 also, so if it's related to that, I should probably see the problem here as well. /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 807.000213 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes features: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 1608.91 -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: Freeze on FPU exception with Athlon
Linus Torvalds wrote: > > Compiler specific ? > > There's almost certainly more than that. I'd love to have a report on my > asm-only version, but even so I suspect it also requires the 3dnow stuff, > because I'm not able to trigger anything like this on any machines I have > access to (none of them are AMD, though) > Hmm... Linus, I've tried your latest asm-version with my Thunderbird, egcs-1.1.2 and 3dnow support compiled in. Several runs show no problems - the program runs and terminates gracefully. -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: Freeze on FPU exception with Athlon
Linus Torvalds wrote: > > I sure as hell hope this isn't an Athlon issue. Can other people try > the test-program and see if we have a pattern (ie "it happens only on > Athlons", or "Linus is on drugs and it happens for everybody else"). I've tried both variants (fesetenv and inline-asm) with glibc-2.1.3, 2.4.0-test11pre7 and an AMD Thunderbird. Neither does freeze, but both yield: Floating point exception (core dumped) -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: NVdriver with new 2.4.test10 not function
Vitali Lieder wrote: > > Hallo. > > Ich have test new NVdriver 0.95 with new kernel 2.4.0test10, but > have the output: > ***unresolved symbols in /lib/modules/2.4.0-test10/video/NVdriver Just add the following lines somewhere on top of nv.c and recompile the nvidia module. #define mem_map_inc_count(p) atomic_inc(&(p->count)) #define mem_map_dec_count(p) atomic_dec(&(p->count)) They were removed from wrapper.h in test10. -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/
[BUG] Another ext2 OOPS
Hi, I just got another oops with test10pre6. Decoded output follows. Hopefully this helps to hunt a bug down. -Udo Unable to handle kernel NULL pointer dereference at virtual address 0010 c0130512 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: ebx: c13871cc ecx: c38788c0 edx: c13871f8 esi: c13871cc edi: 0001 ebp: cd9fad5c esp: c9bc1ec8 ds: 0018 es: 0018 ss: 0018 Process bash (pid: 275, stackpage=c9bc1000) Stack: c13871cc 0001 cd9fad5c 0019 c02a cdae7480 cadc9680 c9bc 0019 ca742000 c02d7180 0246 c01225d1 c13871cc 0001 cd9fad5c 080e2902 c13871f4 01234567 c9bc c13871f8 Call Trace: [] [] [] [] [] [] [] [] Code: 8b 48 10 89 4c 24 40 c7 44 24 34 00 00 00 00 8b 5b 18 f6 c3 >>EIP; c0130512<= Trace; c01225d1 <___wait_on_page+d1/e0> Trace; c01505ff Trace; c014fee0 Trace; c0122f2e Trace; c0123213 Trace; c0123150 Trace; c012ddfe Trace; c010a9d7 Code; c0130512 <_EIP>: Code; c0130512<= 0: 8b 48 10 movl 0x10(%eax),%ecx <= Code; c0130515 3: 89 4c 24 40 movl %ecx,0x40(%esp,1) Code; c0130519 7: c7 44 24 34 00 00 00 movl $0x0,0x34(%esp,1) Code; c0130520 e: 00 Code; c0130521 f: 8b 5b 18 movl 0x18(%ebx),%ebx Code; c0130524 12: f6 c3 00 testb $0x0,%bl - 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: [BUG]: Ext2 Corruption in test10pre3 (incl. Oops)
Alexander Viro wrote: > > > See another posting. More or less the same analysis. I don't see > where it came from and it smells funny - looks like a loss of ->b_count > _or_ an active page returned by alloc_page() (to grow_buffers()). I > wouldn't exclude the latter, BTW, but then I'm still not too familiar with > Rik's changes to VM, so it's just a nodding to the area I don't grok right > now. > > > Udo, any idea what you are doing differently than anybody else to see > > this thing? Any special usage patterns that seem to bring on the trouble? > > BTW, sorry for a stupid question, but... was it the first oops? If it was > an aftermath of something else... X wasn't executing any commands anymore, so I switched over to a text console and dmesg only showed this one oops after the bootup stuff. Your guess that there might be memory corruption somewhere is probably not too far off, because I occasionally have a broken ld-cache, in which case several programs suddenly stop working. Running "ldconfig" immediately fixes that problem. Whether it's VM-related or broken ram I cannot say, although I'd bet that it's the former. -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/
[BUG]: Ext2 Corruption in test10pre3 (incl. Oops)
Hi Linus & Alexander
It seems that we were all wrong in assuming that ext2 was fixed
wrt. filesystem corruption. test10pre3 once again has the potential
to eat files (not sure about earlier versions).
I finally managed to capture an oops (by hand), so bear with me that
I didn't typo anywhere.
Find attached the decoded oops:
Kernel bug at ll_rw_blk.c: 713!
ksymoops 2.3.4 on i686 2.4.0-test10. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test10/ (default)
-m /boot/System.map-2.4.0-test10 (specified)
invalid operand:
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 001f ebx: 00cc0008 ecx: c4433500 edx: 0007
esi: c2c650c0 edi: c02fd160 ebp: esp: cd28dd90
ds: 0018 es: 0018 ss: 0018
Process netscape (pid: 6456, stackpage=cd28d000)
Stack: c0250fc5 c0251262 02c9 c2c650c0 0008 000c 00cc0008
d00a cee143c0 c02fd170 c0300ac0 c02fd178 c02fd170
0008 00cc0008 c0183f24 00fe c0184b84
c02fd160 c2c650c0
Call Trace: [] [] [] []
[] [] [] []
[] [] [] []
[] [] [] []
Code: 0f 0b 83 c4 0c 90 0f b7 4e 14 66 89 4c 24 16 0f b6 46 15 8b
>>EIP; c0184546 <__make_request+a6/630> <=
Trace; c0250fc5
Trace; c0251262
Trace; c0183f24
Trace; c0184b84
Trace; c0184d53
Trace; c012fa31
Trace; c014efde
Trace; c014f240
Trace; c014f6af
Trace; c021e87e
Trace; c01523af
Trace; c0138db7
Trace; c0138f59
Trace; c012d6bb
Trace; c012d9d8
Trace; c010a9d7
Code; c0184546 <__make_request+a6/630>
<_EIP>:
Code; c0184546 <__make_request+a6/630> <=
0: 0f 0b ud2a <=
Code; c0184548 <__make_request+a8/630>
2: 83 c4 0c addl $0xc,%esp
Code; c018454b <__make_request+ab/630>
5: 90nop
Code; c018454c <__make_request+ac/630>
6: 0f b7 4e 14 movzwl 0x14(%esi),%ecx
Code; c0184550 <__make_request+b0/630>
a: 66 89 4c 24 16movw %cx,0x16(%esp,1)
Code; c0184555 <__make_request+b5/630>
f: 0f b6 46 15 movzbl 0x15(%esi),%eax
Code; c0184559 <__make_request+b9/630>
13: 8b 00 movl (%eax),%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/
Re: Updated 2.4 TODO List
[EMAIL PROTECTED] wrote: > > 8. Fix Exists But Isnt Merged > * 2.4.0-test8 has a BUG at ll_rw_blk:711. (Johnny Accot, Steffen >Luitz) (Al Viro has a patch) Said patch has already been merged in the test9-pre and -final series and the bug can be considered 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: [patch] enabling APIC and NMI watchdog on UP systems
Ingo Molnar wrote: > > the attached patch (against test9-pre7) is a cleaned up version Keir > Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which > programs P6 performance counter 0 as an NMI. (i simplified the code alot - > there is no problem at all with getting NMIs from two sources, and it's > not necessary to make it configurable.) > > i'd like to hear about how this patch works for people - it works here on > SMP systems and on P6 systems. The watchdog is enabled unconditionally - > this should significantly help debugging lockups on UP systems as well! Hi Ingo et al, I've been giving the patch a try, however it hangs my machine during boot. Here's the important bits from console: Local APIC disabled by BIOS -- reenabling found and enabled local APIC! It then locks up in Calibrating delay loop... Machine is an uniprocessor AMD Thunderbird on an Asus A7V mobo. If you need additional info let me know. Cheers, 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: test9-pre7
Linus Torvalds wrote:
>
> VM balacing fixes, sound should work again, and a lot of small details.
>
> Linus
> - pre7:
> - official Compaq CISS driver.
There's a little annoying bug with printing partitions upon bootup.
Specifically my dmesg now looks like:
Partition check:
hda: hda1 hda1
hdb: hdb1 hdb1 hdb2 hdb2 hdb3 hdb3 < hdb5 hdb5 hdb6 hdb6 hdb7 hdb7 hdb8 hdb8 hd
b9 hdb9 hdb10 hdb10 >
The following attached patch should fix this.
I'd be happy if someone could verify that it's correct
(seeing that it's past 3am here).
Cheers,
Udo
--- linux/fs/partitions/check.c Tue Sep 26 03:32:45 2000
+++ patched/fs/partitions/check.c Tue Sep 26 03:31:47 2000
@@ -187,14 +187,11 @@
#ifdef CONFIG_DEVFS_FS
printk(" p%d", (minor & ((1 << hd->minor_shift) - 1)));
#else
- if (hd->major >= COMPAQ_SMART2_MAJOR+0 && hd->major <= COMPAQ_SMART2_MAJOR+7)
+ if ((hd->major >= COMPAQ_SMART2_MAJOR+0 && hd->major <= COMPAQ_SMART2_MAJOR+7)
+||
+ (hd->major >= COMPAQ_CISS_MAJOR+0 && hd->major <= COMPAQ_CISS_MAJOR+7))
printk(" p%d", (minor & ((1 << hd->minor_shift) - 1)));
else
printk(" %s", disk_name(hd, minor, buf));
- if (hd->major >= COMPAQ_CISS_MAJOR+0 && hd->major <= COMPAQ_CISS_MAJOR+7)
-printk(" p%d", (minor & ((1 << hd->minor_shift) - 1)));
-else
-printk(" %s", disk_name(hd, minor, buf));
#endif
}
Re: PROBLEM: umount report "busy" on r/o remount of root filesystem
Jes Sorensen wrote: > > Pavel> Umount (and mount on next line too) report "/: device is busy" > Pavel> and the root filesystem stay not correctly unmounted. > > 2.2.13 and gcc-2.95.2 are not compatible, try with the correct > compiler first. Whatever the problem is, it's probably not a compiler issue. He says it's fine with 2.2.x and breaks with 2.4.x. I've seen the same on my system which is 2.4.0-test9 with egcs-1.1.2. I cannot reliably reproduce it though, it only happens occasionally, so I'm clueless as to what causes it. *** To Theodore Y. Ts'o This should probably be added to the 2.4.x bug-list. Since Pavel seems to be able to constantly reproduce it, it should be possible to track the problem down with his help. Cheers, 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.0-test8: BUG at ll_rw_blk.c:711
Steffen Luitz wrote: > > 2.4.0-test8's kupdate just crashed with a BUG at ll_rw_blk.c:711 when I > was trying to save a file from StarOffice. The system is a Dual PII-300 > (with SMP ...) Al Viro posted a patch to fix this problem earlier today on this list. 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: [final fix] Re: Another ext2fs issue with 2.4.0-test8-final
Alexander Viro wrote: > > Urgh. Look for BUG in syslog (right before the oops). AFAICS it should be > line 711, i.e. > if (!buffer_mapped(bh)) > BUG(); Yes, I saw that. I've applied the patch you posted and it appears to work well. The same procedures that formerly broke it now run without any problems. Cheers, 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-test8-pre6
Linus Torvalds wrote: > Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that > we fixed it now several times, and I was always wrong. Time for some > reverse phychology: > > I'm sure this one doesn't fix the truncate bug either. So far things look really promising here. No ext2 breakage yet. Maybe this time you're wrong again and truncate is indeed fixed. I'll beat it some more in the next couple of days and see if I can get it to break somehow. Cheers, 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/
Still ext2-corruption in test8-pre5 (incl. OOPS)
Hello, I'm still experiencing ext2 corruption even with the newest patch test8-pre5. I'm not using bugtraq, mutt or pine and I'm fairly sure it's not caused by a badly written application or strange input. Right now Linux oopsed and badly broke the whole FS. Hopefully this will help tracking the little bugger down really soon. Regards Udo. Calltrace follows: Unable to handle kernel NULL pointer dereference at virtual address 0018 c0130400 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010287 eax: ebx: ecx: 1000 edx: esi: 1000 edi: ebp: 0001 esp: c6a0de10 ds: 0018 es: 0018 ss: 0018 Process netscape (pid: 512, stackpage=c6a0d000) Stack: cba56b00 1000 cb8bf000 1000 c0130a4d cba56b00 c12e2f80 0d98 1000 0012 000c c12e2f80 0011 1000 cba56b00 0d98 c014d275 cba56b9c 00011d98 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: f6 43 18 10 74 2b 0f ba 6b 18 00 0f ab 6b 18 19 c0 85 c0 75 >>EIP; c0130400 <__block_commit_write+50/c0> <= Trace; c0130a4d Trace; c014d275 Trace; c0123ee7 Trace; c0122181 Trace; c0122272 Trace; c01d0c51 Trace; c0140be6 Trace; c0140cbb Trace; c012c87c Trace; c0136e90 Trace; c012cb13 Trace; c010a98b Code; c0130400 <__block_commit_write+50/c0> <_EIP>: Code; c0130400 <__block_commit_write+50/c0> <= 0: f6 43 18 10 testb $0x10,0x18(%ebx) <= Code; c0130404 <__block_commit_write+54/c0> 4: 74 2b je 31 <_EIP+0x31> c0130431 <__block_commit_write+81/c0> Code; c0130406 <__block_commit_write+56/c0> 6: 0f ba 6b 18 00btsl $0x0,0x18(%ebx) Code; c013040b <__block_commit_write+5b/c0> b: 0f ab 6b 18 btsl %ebp,0x18(%ebx) Code; c013040f <__block_commit_write+5f/c0> f: 19 c0 sbbl %eax,%eax Code; c0130411 <__block_commit_write+61/c0> 11: 85 c0 testl %eax,%eax Code; c0130413 <__block_commit_write+63/c0> 13: 75 00 jne15 <_EIP+0x15> c0130415 <__block_commit_write+65/c0> - 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: file corruption with test8-pre2?
Tim Waugh wrote: > > The end of my inbox has turned to zeroes (everything from a few k off > the beginning to the end), while running test8-pre2. :-( > > (I've restored it from backup, but I thought someone ought to know.) Similar things happen on test7 as well - content of files being garbled and shared libraries being broken. 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 in 2.4.0-test8pre2
Hi folks, I got the following oops right upon rebooting as killall5 attempted to kill off processes. OS is 2.4.0-test8pre2/vanilla. The decoded oops follows: Regards, Udo ksymoops 2.3.4 on i686 2.4.0-test8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test8/ (default) -m /boot/System.map-2.4.0-test8 (specified) Unable to handle kernel NULL pointer dereference at virtual address Oops: 0002 CPU:0 EIP:0010: [] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: ebx: 000f ecx: cfbf93dc edx: cfbf9004 esi: c9925f40 edi: 080498f4 ebp: c14e0544 esp: c9925ec4 ds: 0018 es: 0018 ss: 0018 Process killall5 (pid: 787, stackpage=c9925000) Stack: c9925f40 000f 080498f4 000f c011400d 000f c9925f40 c14e0544 c9925f40 000f 080498f4 bd88 c011434d 000f c9925f40 cffe 0001 0313 c0114400 000f c9925f40 0001 0001 0313 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: 89 08 89 4d 04 85 f6 74 07 83 fe 01 74 2e eb 50 89 59 04 c7 >>EIP; c0113ed8<= Trace; c011400d Trace; c011434d Trace; c0114400 Trace; c0114bed Trace; c0144dcd Trace; c013bc30 Trace; c012ed20 <__fput+60/90> Trace; c012ed61 <_fput+11/40> Trace; c012eda2 Trace; c012df0e Trace; c012df63 Trace; c010aa2f Code; c0113ed8 <_EIP>: Code; c0113ed8<= 0: 89 08 movl %ecx,(%eax) <= Code; c0113eda 2: 89 4d 04 movl %ecx,0x4(%ebp) Code; c0113edd 5: 85 f6 testl %esi,%esi Code; c0113edf 7: 74 07 je 10 <_EIP+0x10> c0113ee8 9: 83 fe 01 cmpl $0x1,%esi Code; c0113ee4 c: 74 2e je 3c <_EIP+0x3c> c0113f14 e: eb 50 jmp60 <_EIP+0x60> c0113f38 10: 89 59 04 movl %ebx,0x4(%ecx) Code; c0113eeb 13: c7 00 00 00 00 00 movl $0x0,(%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/
