2.6.13 kernel OOPS
Hi, Is this a known problem? Thanks, Martin cat /proc/sys/net/ipv4/conf/lo/rp_filter <1>Unable to handle kernel paging request at virtual address 419a91d8 printing eip: c0116644 *pde = Oops: [#6] Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010246 (2.6.13) EIP is at do_proc_dointvec_conv+0x14/0x40 eax: c1b40f28 ebx: ecx: 419a91d8 edx: c1b40f24 esi: 1000 edi: 0001 ebp: 0804d008 esp: c1b40eec ds: 007b es: 007b ss: 0068 Process cat (pid: 503, threadinfo=c1b4 task=c22245d0) Stack: c0116731 419a91d8 0001 c1b40fbc c22245d0 c1b656a4 00030002 c1b40f0b c2242b84 c1b656a4 c1e12420 0804d008 c12910e0 c01169a5 0804d008 c1b40f64 c1b40fa4 Call Trace: [] do_proc_dointvec+0xc1/0x320 [] proc_dointvec+0x15/0x20 [] do_proc_dointvec_conv+0x0/0x40 [] do_rw_proc+0x6e/0x80 [] proc_readsys+0x0/0x20 [] proc_readsys+0x10/0x20 [] vfs_read+0x7e/0x140 [] sys_read+0x3c/0x70 [] syscall_call+0x7/0xb Code: 00 00 83 c4 0c 89 c8 5b 5e 5f 5d c3 8d 74 26 00 8d bc 27 00 00 00 00 83 7c 24 04 00 74 0d 8b 00 85 c0 75 18 8b 02 89 01 31 c0 c3 <8b> 09 85 c9 78 16 c7 00 00 00 00 00 31 c0 89 0a c3 8b 02 f7 d8 bash-2.05$ /bld/linux-2.6.13/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux shadow 2.6.12 #1 SMP Sat Jun 18 09:36:33 CDT 2005 i686 unknown unknown GNU/Linux Gnu C 4.0.0 Gnu make 3.80 binutils 2.15 util-linux 2.12q mount 2.12q module-init-tools 3.0-pre2 e2fsprogs 1.35 reiserfsprogs reiserfsck: reiser4progs fsck.reiser4: pcmcia-cs 3.2.8 nfs-utils 0.1.5 Linux C Library2.3.4 Dynamic linker (ldd) 2.3.4 Linux C++ Library 6.0.4 Procps 3.2.5 Net-tools 1.60 Kbd1.12 Sh-utils 5.2.1 udev 048 Modules Loaded bash-2.05$ - 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: Does kernel require IDE enabled in BIOS to access HD, FS errors?
Jim, Thanks for the info, comments interleaved below Thanks Martin Jim Roland wrote: > > Activating an IDE drive in an older BIOS (newer ones have a SCSI option in > the "A/C/CDROM" options) will always force an IDE drive boot with older > BIOSes. Older BIOSes are written to stop looking for a boot device once it > has found one, and it's own IDE is where it says "Ok, I have boot > capability", otherwise no IDE drive, means it passes boot control to other > system BIOSes (like your SCSI or NIC cards). This is by default with older > systems. This behavior is acceptable, as I can as you suggest move the kernel to the IDE and tell it the root device is /dev/md0. Actually that is what I did to a floppy to get access to the system while the BIOS was set to detect the IDE drives. Since I only boot whenever Linus puts out a new kernel that isn't so much of a concern. > > I expect someone will rebut my comments about the kernel (which is fine, I'm > not a Kernel hacker--PROPERLY USED TERM HERE (not the media's term) ), > but it is my understanding that the kernel uses your system BIOS for actual > reads/writes at the hardware level, this way it does not have to account for > EVERY possible BIOS out there. (Other OSes use BIOS system calls for this > purpose as well) When you turn BIOS to the OS does what it can, but > the BIOS in your system *SHOULD* refuse to process the call, instead it's > doing the read/writes, but not the same way as if IDE was turned on. But, that's kind of the point I'm driving at if the OS can't correctly access the IDE interface it shouldn't do it at all. My guess is that the CMD64X driver is broken since the system can write data to the HD but with random corruption. Ditto for reading data. Likewise, why would I see an increase in write performance when "dd if=/dev/zero of=/dev/null" is running simultaneously on another console. > Are you getting IDE corruption with the BIOS set to for your IDE > drive? None whatsoever. - 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: Does kernel require IDE enabled in BIOS to access HD, FS errors?
Jim, Thanks for the info, comments interleaved below Thanks Martin Jim Roland wrote: Activating an IDE drive in an older BIOS (newer ones have a SCSI option in the A/C/CDROM options) will always force an IDE drive boot with older BIOSes. Older BIOSes are written to stop looking for a boot device once it has found one, and it's own IDE is where it says Ok, I have boot capability, otherwise no IDE drive, means it passes boot control to other system BIOSes (like your SCSI or NIC cards). This is by default with older systems. This behavior is acceptable, as I can as you suggest move the kernel to the IDE and tell it the root device is /dev/md0. Actually that is what I did to a floppy to get access to the system while the BIOS was set to auto detect the IDE drives. Since I only boot whenever Linus puts out a new kernel that isn't so much of a concern. I expect someone will rebut my comments about the kernel (which is fine, I'm not a Kernel hacker--PROPERLY USED TERM HERE (not the media's term) grin), but it is my understanding that the kernel uses your system BIOS for actual reads/writes at the hardware level, this way it does not have to account for EVERY possible BIOS out there. (Other OSes use BIOS system calls for this purpose as well) When you turn BIOS to NONE the OS does what it can, but the BIOS in your system *SHOULD* refuse to process the call, instead it's doing the read/writes, but not the same way as if IDE was turned on. But, that's kind of the point I'm driving at if the OS can't correctly access the IDE interface it shouldn't do it at all. My guess is that the CMD64X driver is broken since the system can write data to the HD but with random corruption. Ditto for reading data. Likewise, why would I see an increase in write performance when dd if=/dev/zero of=/dev/null is running simultaneously on another console. Are you getting IDE corruption with the BIOS set to AUTO for your IDE drive? None whatsoever. - 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/
Does kernel require IDE enabled in BIOS to access HD, FS errors?
Hi,
I have a SMP P166 system that has been running for years with an AIC7xxx SCSI card as
opposed to the native IDE interface. The BIOS has the IDE 0,1,2,3 set to .
Running out of disk space I installed one of the original IDE drives. The kernel
booted and ID'd the drive correctly. Kernel version 2.4.5/6 behave the same.
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
CMD646: IDE controller on PCI bus 00 dev 10
CMD646: chipset revision 1
CMD646: not 100% native mode: will probe irqs later
CMD646: chipset revision 0x01, MultiWord DMA Limited, IRQ workaround enabled
CMD646: simplex device: DMA disabled
ide0: CMD646 Bus-Master DMA disabled (BIOS)
CMD646: simplex device: DMA disabled
ide1: CMD646 Bus-Master DMA disabled (BIOS)
hdb: CD-ROM CDU76E, ATAPI CD/DVD-ROM drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: WDC AC2850F, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hdc: 1667232 sectors (854 MB) w/64KiB Cache, CHS=1654/16/63
hdb: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdb: packet command error: error=0x44
hdb: ATAPI 4X CD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
hdc: [PTBL] [827/32/63] hdc1
However I can't boot from the SCSI drives if the IDE HD is enabled due to deficiencies
in the BIOS... boot "A: then C:" or "C: then A:" are the only choices, if neither are
present the system boots from the SCSI card, otherwise it fails to boot.
PROBLEM: cannot reliably R/W to the HD unless the BIOS is set to recognize.
I consistently see MD5SUM errors and FS corruption and other strange FS symptoms
when the BIOS is set to for the drive and _never_ see any errors with the
setting set to . There are no messages emitted by the kernel that there
were any system errors encountered leading one to believe that all is well, when
it isn't.
What is interesting, is that the I/O writes increase from once every 14 seconds to
once every 2-3 seconds and the FS corruption diminishes but don't disappear
if a background "dd if=/dev/zero of=/dev/null" is running.
Is this expected kernel behavior?
VMSTAT follow... when copying files from SCSI drives to IDE drive.
More info available if needed...
Thanks,
Martin
The waiting processes are kupdated and bdflush. (I have Alt-SysRq- trace of them)
VMSTAT 1 for the case w/ BIOS set to looks like (w/o dd running):
procs memoryswap io system cpu
r b w swpd free buff cache si sobibo incs us sy id
0 0 0 0 83180 1056 39800 0 0 261 3 8343 5 8 87
0 0 0 0 83176 1056 39800 0 0 0 0 11920 3 2 95
0 0 0 0 83176 1056 39800 0 0 0 0 11620 2 2 96
0 1 0 0 83012 1096 39812 0 0 329 0 196 183 3 8 89
0 1 0 0 81268 1128 41444 0 0 1021 0 309 275 3 17 80
0 1 0 0 74464 1200 47716 0 0 313127 292 264 6 25 69
2 0 0 0 67772 1276 53632 0 0 2962 0 397 245 12 25 63
2 0 0 0 64016 1324 56900 0 0 1602 0 414 155 48 27 26
1 1 0 0 53924 1372 66608 0 0 4960 0 200 165 14 40 46
1 0 0 0 42260 1448 77556 0 0 5493 0 232 210 3 35 62
0 1 0 0 30276 1480 88748 0 0 5616 0 201 124 4 34 62
2 0 0 0 22580 1496 96044 0 0 3671 2868 30796 2 33 65
0 1 0 0 12392 1528 105492 0 0 4771 4852 276 164 5 37 58
1 0 0 0 3056 1560 114232 0 0 4641 4861 328 200 2 43 54
1 1 0 0 3056 1588 114192 0 0 5011 4744 281 139 5 39 57
1 0 1 0 3056 1612 114168 0 0 5269 1728 256 115 4 35 60
0 1 1 0 3056 1680 114084 0 0 4827 0 271 193 2 33 64
1 0 1 0 3056 1708 114056 0 0 5268 0 236 106 3 38 59
2 0 1 0 3056 1748 113864 0 0 3817 3968 315 132 7 44 49
2 0 1 0 3056 1760 113604 0 0 2955 0 34863 41 50 9
1 0 1 0 3056 1788 113940 0 0 4258 0 24797 41 46 13
1 0 1 0 3056 1844 113880 0 0 4246 0 281 168 4 36 60
0 1 1 0 3064 1856 113868 0 0 2955 0 20969 3 19 78
0 1 2 0 3064 1856 113868 0 0 0 0 14927 2 3 95
0 1 2 0 3064 1856 113868 0 0 0 0 14719 2 3 95
0 1 2 0 3064 1856 113868 0 0 0 0 15218 2 3 95
0 1 2 0 3064 1856 113868 0 0 0 0 14716 2 4 94
0 1 2 0 3064 1856 113868 0 0 0 0 14716 1 4 94
0 1 1 0 3060 1856 113868 0 0 0 3613 15628 1 5 94
0 1 1
Does kernel require IDE enabled in BIOS to access HD, FS errors?
Hi,
I have a SMP P166 system that has been running for years with an AIC7xxx SCSI card as
opposed to the native IDE interface. The BIOS has the IDE 0,1,2,3 set to NONE.
Running out of disk space I installed one of the original IDE drives. The kernel
booted and ID'd the drive correctly. Kernel version 2.4.5/6 behave the same.
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
CMD646: IDE controller on PCI bus 00 dev 10
CMD646: chipset revision 1
CMD646: not 100% native mode: will probe irqs later
CMD646: chipset revision 0x01, MultiWord DMA Limited, IRQ workaround enabled
CMD646: simplex device: DMA disabled
ide0: CMD646 Bus-Master DMA disabled (BIOS)
CMD646: simplex device: DMA disabled
ide1: CMD646 Bus-Master DMA disabled (BIOS)
hdb: CD-ROM CDU76E, ATAPI CD/DVD-ROM drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: WDC AC2850F, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hdc: 1667232 sectors (854 MB) w/64KiB Cache, CHS=1654/16/63
hdb: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdb: packet command error: error=0x44
hdb: ATAPI 4X CD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
hdc: [PTBL] [827/32/63] hdc1
However I can't boot from the SCSI drives if the IDE HD is enabled due to deficiencies
in the BIOS... boot A: then C: or C: then A: are the only choices, if neither are
present the system boots from the SCSI card, otherwise it fails to boot.
PROBLEM: cannot reliably R/W to the HD unless the BIOS is set to auto recognize.
I consistently see MD5SUM errors and FS corruption and other strange FS symptoms
when the BIOS is set to NONE for the drive and _never_ see any errors with the
setting set to AUTO. There are no messages emitted by the kernel that there
were any system errors encountered leading one to believe that all is well, when
it isn't.
What is interesting, is that the I/O writes increase from once every 14 seconds to
once every 2-3 seconds and the FS corruption diminishes but don't disappear
if a background dd if=/dev/zero of=/dev/null is running.
Is this expected kernel behavior?
VMSTAT follow... when copying files from SCSI drives to IDE drive.
More info available if needed...
Thanks,
Martin
The waiting processes are kupdated and bdflush. (I have Alt-SysRq- trace of them)
VMSTAT 1 for the case w/ BIOS set to NONE looks like (w/o dd running):
procs memoryswap io system cpu
r b w swpd free buff cache si sobibo incs us sy id
0 0 0 0 83180 1056 39800 0 0 261 3 8343 5 8 87
0 0 0 0 83176 1056 39800 0 0 0 0 11920 3 2 95
0 0 0 0 83176 1056 39800 0 0 0 0 11620 2 2 96
0 1 0 0 83012 1096 39812 0 0 329 0 196 183 3 8 89
0 1 0 0 81268 1128 41444 0 0 1021 0 309 275 3 17 80
0 1 0 0 74464 1200 47716 0 0 313127 292 264 6 25 69
2 0 0 0 67772 1276 53632 0 0 2962 0 397 245 12 25 63
2 0 0 0 64016 1324 56900 0 0 1602 0 414 155 48 27 26
1 1 0 0 53924 1372 66608 0 0 4960 0 200 165 14 40 46
1 0 0 0 42260 1448 77556 0 0 5493 0 232 210 3 35 62
0 1 0 0 30276 1480 88748 0 0 5616 0 201 124 4 34 62
2 0 0 0 22580 1496 96044 0 0 3671 2868 30796 2 33 65
0 1 0 0 12392 1528 105492 0 0 4771 4852 276 164 5 37 58
1 0 0 0 3056 1560 114232 0 0 4641 4861 328 200 2 43 54
1 1 0 0 3056 1588 114192 0 0 5011 4744 281 139 5 39 57
1 0 1 0 3056 1612 114168 0 0 5269 1728 256 115 4 35 60
0 1 1 0 3056 1680 114084 0 0 4827 0 271 193 2 33 64
1 0 1 0 3056 1708 114056 0 0 5268 0 236 106 3 38 59
2 0 1 0 3056 1748 113864 0 0 3817 3968 315 132 7 44 49
2 0 1 0 3056 1760 113604 0 0 2955 0 34863 41 50 9
1 0 1 0 3056 1788 113940 0 0 4258 0 24797 41 46 13
1 0 1 0 3056 1844 113880 0 0 4246 0 281 168 4 36 60
0 1 1 0 3064 1856 113868 0 0 2955 0 20969 3 19 78
0 1 2 0 3064 1856 113868 0 0 0 0 14927 2 3 95
0 1 2 0 3064 1856 113868 0 0 0 0 14719 2 3 95
0 1 2 0 3064 1856 113868 0 0 0 0 15218 2 3 95
0 1 2 0 3064 1856 113868 0 0 0 0 14716 2 4 94
0 1 2 0 3064 1856 113868 0 0 0 0 14716 1 4 94
0 1 1 0 3060 1856 113868 0 0 0 3613 15628 1 5
Re: Delay in authentication.
Chris,
I reported the same thing on 11/19/00, whether this is a feature or bug for
2.4.X was not determined. Was this behavior intentionally changed and why?
Looks like 2.2.X gives ECONNREFUSED, but 2.4.X doesn't and times out.
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg13983.html text below.
Martin
I had occasion to "telinit 1" today and found that it took a long time
to login after root passwd was entered. this doesn't happen with 2.2.X
kernels.
Is this to be expected with the 2.4 series kernels? or a bug?
Martin
strace for 2.4.0-test11-pre7
---snip---
gettimeofday({974665658, 952483}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
getpid()= 305
bind(3, {sin_family=AF_INET, sin_port=htons(905),
sin_addr=inet_addr("0.0.0.0")}}, 16)
= 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "\31\23\233@\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN}], 1, 5000) = 0
ioctl(3, SIOCGIFCONF, 0xbfffb33c) = 0
ioctl(3, SIOCGIFFLAGS, 0xbfffb344) = 0
sendto(3, "\31\23\233@\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
---snip---
strace for 2.2.17
---snip---
gettimeofday({974664928, 735539}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
getpid()= 368
bind(3, {sin_family=AF_INET, sin_port=htons(968),
sin_addr=inet_addr("0.0.0.0")}}, 16)
= 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "_c\353\331\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN, revents=POLLERR}], 1, 5000) = 1
recvfrom(3, 0x8056380, 400, 0, 0xbfffd66c, 0xbfffd618) = -1 ECONNREFUSED
(Connection
refused)
close(3)= 0
---snip---
-
Chris Meadors wrote:
>
> On Mon, 8 Jan 2001, David S. Miller wrote:
>
> > This definitely seems like the classic "/etc/nsswitch.conf is told to
> > look for YP servers and you are not using YP", so have a look and fix
> > nsswitch.conf if this is in fact the problem.
>
> What I have never gotten, is why on my machines (no specific distro, just
> everything built from source and installed by me) login takes a long time,
> unless I have portmap running.
>
> My /etc/nsswitch.conf would seem to be right:
>
> passwd: files
> group: files
> shadow: files
>
> hosts: files dns
> networks: files dns
>
> protocols: files
> services: files
> ethers: files
> rpc:files
>
> netgroup: files
>
> What else could effect that?
>
> -Chris
> --
-
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: Delay in authentication.
Chris,
I reported the same thing on 11/19/00, whether this is a feature or bug for
2.4.X was not determined. Was this behavior intentionally changed and why?
Looks like 2.2.X gives ECONNREFUSED, but 2.4.X doesn't and times out.
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg13983.html text below.
Martin
I had occasion to "telinit 1" today and found that it took a long time
to login after root passwd was entered. this doesn't happen with 2.2.X
kernels.
Is this to be expected with the 2.4 series kernels? or a bug?
Martin
strace for 2.4.0-test11-pre7
---snip---
gettimeofday({974665658, 952483}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
getpid()= 305
bind(3, {sin_family=AF_INET, sin_port=htons(905),
sin_addr=inet_addr("0.0.0.0")}}, 16)
= 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "\31\23\233@\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN}], 1, 5000) = 0
ioctl(3, SIOCGIFCONF, 0xbfffb33c) = 0
ioctl(3, SIOCGIFFLAGS, 0xbfffb344) = 0
sendto(3, "\31\23\233@\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
---snip---
strace for 2.2.17
---snip---
gettimeofday({974664928, 735539}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
getpid()= 368
bind(3, {sin_family=AF_INET, sin_port=htons(968),
sin_addr=inet_addr("0.0.0.0")}}, 16)
= 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "_c\353\331\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN, revents=POLLERR}], 1, 5000) = 1
recvfrom(3, 0x8056380, 400, 0, 0xbfffd66c, 0xbfffd618) = -1 ECONNREFUSED
(Connection
refused)
close(3)= 0
---snip---
-
Chris Meadors wrote:
On Mon, 8 Jan 2001, David S. Miller wrote:
This definitely seems like the classic "/etc/nsswitch.conf is told to
look for YP servers and you are not using YP", so have a look and fix
nsswitch.conf if this is in fact the problem.
What I have never gotten, is why on my machines (no specific distro, just
everything built from source and installed by me) login takes a long time,
unless I have portmap running.
My /etc/nsswitch.conf would seem to be right:
passwd: files
group: files
shadow: files
hosts: files dns
networks: files dns
protocols: files
services: files
ethers: files
rpc:files
netgroup: files
What else could effect that?
-Chris
--
-
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/
Again, kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! 2.4.0-prerelease
Hi Neil, I thought I'd seen this same bug on 2.4.0-test12 after I applied your patch but didn't follow up until now. sorry. Anyway, with 2.4.0-prerelease and an updated loop.c.patch, below the ksymoops output (your patch updated to 2.4.0-prerelease), I got the following BUG reports. So it appears as if the "obviously correct patch ;-)" doesn't fix this particular problem, but doesn't seem to break anything obvious. Later, Martin 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) activating NMI Watchdog ... done. cpu: 0, clocks: 680100, slice: 226700 cpu: 1, clocks: 680100, slice: 226700 kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 0039 ebx: c9183e80 ecx: edx: 0002 esi: cb17dcc0 edi: cb1d3d40 ebp: c962e000 esp: c962fd04 ds: 0018 es: 0018 ss: 0018 Process find (pid: 29692, stackpage=c962f000) Stack: c022fea5 c0230040 00a7 cabe30c0 c89c9860 c12c8294 c015bf1d cabe30c0 c89c9860 c12c8294 1000 c89c9860 c12c8294 cabe30c0 fff4 c015c721 cabe30c0 c89c9860 c12c8294 cabe30c0 c12c8294 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 89 7e 1c eb 26 90 8d 74 26 00 6a 00 8b 54 24 >>EIP; c015cf61<= Trace; c022fea5 Trace; c0230040 Trace; c015bf1d Trace; c015c721 Trace; c0125bf7 Trace; c018b15c Trace; c018b064 Trace; c018b48b Trace; c0181b6f <__make_request+5bb/638> Trace; c0181d03 Trace; c0181d6b Trace; c0181ef7 Trace; c0152bea Trace; c0151295 Trace; c0112e28 Trace; c0123ff4 Trace; c014133c Trace; c014170c Trace; c0141867 Trace; c014170c Trace; c0123548 Trace; c0108fd3 Code; c015cf61 <_EIP>: Code; c015cf61<= 0: 0f 0b ud2a <= Code; c015cf63 2: 83 c4 0c add$0xc,%esp Code; c015cf66 5: 89 7e 1c mov%edi,0x1c(%esi) Code; c015cf69 8: eb 26 jmp30 <_EIP+0x30> c015cf91 Code; c015cf6b a: 90nop Code; c015cf6c b: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c015cf70 f: 6a 00 push $0x0 Code; c015cf72 11: 8b 54 24 00 mov0x0(%esp,1),%edx kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! invalid operand: CPU:1 EIP:0010:[] EFLAGS: 00010286 eax: 0039 ebx: c9183e80 ecx: edx: 0100 esi: c87c3ce0 edi: cb1d3d40 ebp: c5f38000 esp: c5f39d2c ds: 0018 es: 0018 ss: 0018 Process find (pid: 29930, stackpage=c5f39000) Stack: c022fea5 c0230040 00a7 cabe3360 c8ad1040 c115d0d4 c015bf1d cabe3360 c8ad1040 c115d0d4 1000 c8ad1040 c115d0d4 cabe3360 fff4 c015c721 cabe3360 c8ad1040 c115d0d4 cabe3360 c115d0d4 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 89 7e 1c eb 26 90 8d 74 26 00 6a 00 8b 54 24 >>EIP; c015cf61<= Trace; c022fea5 Trace; c0230040 Trace; c015bf1d Trace; c015c721 Trace; c0125bf7 Trace; c018b15c Trace; c018b064 Trace; c018b48b Trace; c0181b6f <__make_request+5bb/638> Trace; c0181d03 Trace; c0181d6b Trace; c0181ef7 Trace; c0151347 Trace; c0112e28 Trace; c0123ff4 Trace; c014133c Trace; c014170c Trace; c0141867 Trace; c014170c Trace; c0123548 Trace; c0108fd3 Code; c015cf61 <_EIP>: Code; c015cf61<= 0: 0f 0b ud2a <= Code; c015cf63 2: 83 c4 0c add$0xc,%esp Code; c015cf66 5: 89 7e 1c mov%edi,0x1c(%esi) Code; c015cf69 8: eb 26 jmp30 <_EIP+0x30> c015cf91 Code; c015cf6b a: 90nop Code; c015cf6c b: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c015cf70 f: 6a 00 push $0x0 Code; c015cf72 11: 8b 54 24 00 mov0x0(%esp,1),%edx updated patch for 2.4.0-prerelease __ --- loop.c.orig Fri Dec 29 16:07:21 2000 +++ loop.c Tue Jan 2 17:11:38 2001 @@ -441,37 +441,18 @@ if (!aops->prepare_write || !aops->commit_write) lo->lo_flags |= LO_FLAGS_READ_ONLY; - error = get_write_access(inode); - if (error) - goto out_putf; /* Backed by a regular file - we need to hold onto a file - structure for this file. Friggin' NFS can't live without - it on write and for reading we use do_generic_file_read(), - so...
Again, kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! 2.4.0-prerelease
Hi Neil, I thought I'd seen this same bug on 2.4.0-test12 after I applied your patch but didn't follow up until now. sorry. Anyway, with 2.4.0-prerelease and an updated loop.c.patch, below the ksymoops output (your patch updated to 2.4.0-prerelease), I got the following BUG reports. So it appears as if the "obviously correct patch ;-)" doesn't fix this particular problem, but doesn't seem to break anything obvious. Later, Martin 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) activating NMI Watchdog ... done. cpu: 0, clocks: 680100, slice: 226700 cpu: 1, clocks: 680100, slice: 226700 kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! invalid operand: CPU:0 EIP:0010:[c015cf61] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 0039 ebx: c9183e80 ecx: edx: 0002 esi: cb17dcc0 edi: cb1d3d40 ebp: c962e000 esp: c962fd04 ds: 0018 es: 0018 ss: 0018 Process find (pid: 29692, stackpage=c962f000) Stack: c022fea5 c0230040 00a7 cabe30c0 c89c9860 c12c8294 c015bf1d cabe30c0 c89c9860 c12c8294 1000 c89c9860 c12c8294 cabe30c0 fff4 c015c721 cabe30c0 c89c9860 c12c8294 cabe30c0 c12c8294 Call Trace: [c022fea5] [c0230040] [c015bf1d] [c015c721] [c0125bf7] [c018b15c] [c018b064] [c018b48b] [c0181b6f] [c0181d03] [c0181d6b] [c0181ef7] [c0152bea] [c0151295] [c0112e28] [c0123ff4] [c014133c] [c014170c] [c0141867] [c014170c] [c0123548] [c0108fd3] Code: 0f 0b 83 c4 0c 89 7e 1c eb 26 90 8d 74 26 00 6a 00 8b 54 24 EIP; c015cf61 nfs_create_request+195/1e4 = Trace; c022fea5 devfsd_buf_size+1b85/10a8c Trace; c0230040 devfsd_buf_size+1d20/10a8c Trace; c015bf1d nfs_readpage_async+13d/1c0 Trace; c015c721 nfs_readpage+c5/12c Trace; c0125bf7 do_generic_file_read+347/53c Trace; c018b15c lo_receive+58/68 Trace; c018b064 lo_read_actor+0/a0 Trace; c018b48b do_lo_request+31f/414 Trace; c0181b6f __make_request+5bb/638 Trace; c0181d03 generic_make_request+117/124 Trace; c0181d6b submit_bh+5b/7c Trace; c0181ef7 ll_rw_block+127/188 Trace; c0152bea ext2_bread+ce/110 Trace; c0151295 ext2_readdir+91/37c Trace; c0112e28 do_page_fault+0/3e8 Trace; c0123ff4 do_munmap+58/250 Trace; c014133c vfs_readdir+8c/e8 Trace; c014170c filldir64+0/10c Trace; c0141867 sys_getdents64+4f/b8 Trace; c014170c filldir64+0/10c Trace; c0123548 sys_brk+b4/d8 Trace; c0108fd3 system_call+33/38 Code; c015cf61 nfs_create_request+195/1e4 _EIP: Code; c015cf61 nfs_create_request+195/1e4 = 0: 0f 0b ud2a = Code; c015cf63 nfs_create_request+197/1e4 2: 83 c4 0c add$0xc,%esp Code; c015cf66 nfs_create_request+19a/1e4 5: 89 7e 1c mov%edi,0x1c(%esi) Code; c015cf69 nfs_create_request+19d/1e4 8: eb 26 jmp30 _EIP+0x30 c015cf91 nfs_create_request+1c5/1e4 Code; c015cf6b nfs_create_request+19f/1e4 a: 90nop Code; c015cf6c nfs_create_request+1a0/1e4 b: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c015cf70 nfs_create_request+1a4/1e4 f: 6a 00 push $0x0 Code; c015cf72 nfs_create_request+1a6/1e4 11: 8b 54 24 00 mov0x0(%esp,1),%edx kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! invalid operand: CPU:1 EIP:0010:[c015cf61] EFLAGS: 00010286 eax: 0039 ebx: c9183e80 ecx: edx: 0100 esi: c87c3ce0 edi: cb1d3d40 ebp: c5f38000 esp: c5f39d2c ds: 0018 es: 0018 ss: 0018 Process find (pid: 29930, stackpage=c5f39000) Stack: c022fea5 c0230040 00a7 cabe3360 c8ad1040 c115d0d4 c015bf1d cabe3360 c8ad1040 c115d0d4 1000 c8ad1040 c115d0d4 cabe3360 fff4 c015c721 cabe3360 c8ad1040 c115d0d4 cabe3360 c115d0d4 Call Trace: [c022fea5] [c0230040] [c015bf1d] [c015c721] [c0125bf7] [c018b15c] [c018b064] [c018b48b] [c0181b6f] [c0181d03] [c0181d6b] [c0181ef7] [c0151347] [c0112e28] [c0123ff4] [c014133c] [c014170c] [c0141867] [c014170c] [c0123548] [c0108fd3] Code: 0f 0b 83 c4 0c 89 7e 1c eb 26 90 8d 74 26 00 6a 00 8b 54 24 EIP; c015cf61 nfs_create_request+195/1e4 = Trace; c022fea5 devfsd_buf_size+1b85/10a8c Trace; c0230040 devfsd_buf_size+1d20/10a8c Trace; c015bf1d nfs_readpage_async+13d/1c0 Trace; c015c721 nfs_readpage+c5/12c Trace; c0125bf7 do_generic_file_read+347/53c Trace; c018b15c lo_receive+58/68 Trace; c018b064 lo_read_actor+0/a0 Trace; c018b48b do_lo_request+31f/414 Trace; c0181b6f __make_request+5bb/638 Trace; c0181d03 generic_make_request+117/124 Trace; c0181d6b submit_bh+5b/7c Trace; c0181ef7 ll_rw_block+127/188 Trace; c0151347 ext2_readdir+143/37c Trace; c0112e28 do_page_fault+0/3e8 Trace; c0123ff4 do_munmap+58/250 Trace; c014133c
Re: kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! -reproducible
Alexander Viro wrote: > > On Mon, 18 Dec 2000, Neil Brown wrote: > > > On Monday December 18, [EMAIL PROTECTED] wrote: > > > > " " == M H VanLeeuwen <[EMAIL PROTECTED]> writes: > > > > > > > Trond, Neil I don't know if this is a loopback bug or an NFS > > > > bug but since nfs_fs.h was implicated so I thought one of you > > > > may be interested. > > > > > > > Could you let me know if you know this problem has already been > > > > fixed or if you need more info. > > > > > > Hi, > > > > > > As far as I'm concerned, it's a loopback bug. > > > > I read it the same way. > > Actually, I cannot see the point of copying the "struct file"! Why > > not just take a reference to it? The comment tries to justify it, but > > I don't buy it. > > Wish I remembered who had complained when I proposed to kill that copying... > It was introduced back in 2.1.110 and back then comment looked so: > > + /* Backed by a regular file - we need to hold onto > + a file structure for this file. We'll use it to > + write to blocks that are not already present in > + a sparse file. We create a new file structure > + based on the one passed to us via 'arg'. This is > + to avoid changing the file structure that the > + caller is using */ > + > > I would be happy to get rid of that crap - it was the only reason why I > had to add the sodding file_moveto() and world would be better without it. > If we can kill it off - let's do it and let's take fs/file_table:file_moveto() > along. > > IOW, I also think that copying the struct file is wrong. IIRC, complaints were > bogus - losetup requires enough priviliges to make worrying about security > implications somewhat pointless. Ok, I've was able to cause 2 BUG's yesterday in a couple of hours, ( it was easier to lock the machine solid than to get the BUG;-)), since loading test12 w/patch I haven't seen a single BUG in the last 24 hours. Any chance we can get this change to Linus for test13? Any specific tests you want me to run? Martin - 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: kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! -reproducible
Alexander Viro wrote: On Mon, 18 Dec 2000, Neil Brown wrote: On Monday December 18, [EMAIL PROTECTED] wrote: " " == M H VanLeeuwen [EMAIL PROTECTED] writes: Trond, Neil I don't know if this is a loopback bug or an NFS bug but since nfs_fs.h was implicated so I thought one of you may be interested. Could you let me know if you know this problem has already been fixed or if you need more info. Hi, As far as I'm concerned, it's a loopback bug. I read it the same way. Actually, I cannot see the point of copying the "struct file"! Why not just take a reference to it? The comment tries to justify it, but I don't buy it. Wish I remembered who had complained when I proposed to kill that copying... It was introduced back in 2.1.110 and back then comment looked so: + /* Backed by a regular file - we need to hold onto + a file structure for this file. We'll use it to + write to blocks that are not already present in + a sparse file. We create a new file structure + based on the one passed to us via 'arg'. This is + to avoid changing the file structure that the + caller is using */ + I would be happy to get rid of that crap - it was the only reason why I had to add the sodding file_moveto() and world would be better without it. If we can kill it off - let's do it and let's take fs/file_table:file_moveto() along. IOW, I also think that copying the struct file is wrong. IIRC, complaints were bogus - losetup requires enough priviliges to make worrying about security implications somewhat pointless. Ok, I've was able to cause 2 BUG's yesterday in a couple of hours, ( it was easier to lock the machine solid than to get the BUG;-)), since loading test12 w/patch I haven't seen a single BUG in the last 24 hours. Any chance we can get this change to Linus for test13? Any specific tests you want me to run? Martin - 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/
kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! - reproducible
Trond, Neil I don't know if this is a loopback bug or an NFS bug but since nfs_fs.h was implicated so I thought one of you may be interested. Could you let me know if you know this problem has already been fixed or if you need more info. Martin [1.] One line summary of the problem: kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! [2.] Full description of the problem/report: BUG while trying to read from NFS file mounted locally via loopback. NFS client(heli, UP) & server(shadow, SMP) are 2.4.0-test12 NFSv3. shadow mounted a file system image via loopback to a local mount point. shadow:/mnt#mount heli:/tmp on /mnt type nfs (rw,addr=192.168.0.2) shadow:/mnt/uml# file root_fs_slackware_7.1_small root_fs_slackware_7.1_small: x86 boot sector, extended partition table shadow:/mnt/uml# mount -o loop root_fs_slackware_7.1_small /mnt1 shadow:/mnt/uml# mount heli:/tmp on /mnt type nfs (rw,addr=192.168.0.2) /mnt/uml/root_fs_slackware_7.1_small on /mnt1 type ext2 (rw,loop=/dev/loop/0) shadow:/mnt/uml# cd /mnt1 shadow:/mnt1# lf /usr/local/bin/lf: line 1: 585 Segmentation fault ls $LS_OPTIONS $1 [3.] Keywords (i.e., modules, networking, kernel): nfs, loopback [4.] Kernel version (from /proc/version): Linux version 2.4.0-test12 (mhvl@shadow) (gcc version 2.95.2 19991024 (release)) #1 SMP Tue Dec 12 20:46:11 CST 2000 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) ksymoops 2.3.5 on i686 2.4.0-test12. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test12/ (default) -m /boot/System.map-2.4.0-test12 (specified) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? activating NMI Watchdog ... done. cpu: 0, clocks: 680220, slice: 226740 cpu: 1, clocks: 680220, slice: 226740 kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 0039 ebx: c8639ae0 ecx: edx: 0002 esi: cba46840 edi: c78592c0 ebp: c05f6000 esp: c05f7d08 ds: 0018 es: 0018 ss: 0018 Process ls (pid: 585, stackpage=c05f7000) Stack: c0231b65 c0231d40 00a7 c081fda0 c0a473c0 c1018fd4 c015b30d c081fda0 c0a473c0 c1018fd4 1000 c0a473c0 c1018fd4 c081fda0 fff4 c015bb11 c081fda0 c0a473c0 c1018fd4 c13a9b7c c1018fd4 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c 89 7e 1c eb 26 90 8d 74 26 00 6a 00 8b 54 24 >>EIP; c015c351<= Trace; c0231b65 Trace; c0231d40 Trace; c015b30d Trace; c015bb11 Trace; c0125d33 Trace; c01839bc Trace; c01838c4 Trace; c0183ceb Trace; c01829cf <__make_request+5bb/638> Trace; c0182b4d Trace; c0182bb0 Trace; c0182d37 Trace; c015207d Trace; c0150725 Trace; c0112e58 Trace; c0124891 Trace; c014086c Trace; c0140c3c Trace; c0140d97 Trace; c0140c3c Trace; c0123578 Trace; c010b073 Code; c015c351 <_EIP>: Code; c015c351<= 0: 0f 0b ud2a <= Code; c015c353 2: 83 c4 0c add$0xc,%esp Code; c015c356 5: 89 7e 1c mov%edi,0x1c(%esi) Code; c015c359 8: eb 26 jmp30 <_EIP+0x30> c015c381 Code; c015c35b a: 90nop Code; c015c35c b: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c015c360 f: 6a 00 push $0x0 Code; c015c362 11: 8b 54 24 00 mov0x0(%esp,1),%edx 1 warning issued. Results may not be reliable. [6.] A small shell script or example program which triggers the problem (if possible) see description of problem [7.] Environment [7.1.] Software (add the output of the ver_linux script here) -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux shadow 2.4.0-test12 #1 SMP Tue Dec 12 20:46:11 CST 2000 i686 unknown Kernel modules 2.3.21 Gnu C 2.95.2 Gnu Make 3.79.1 Binutils 2.10.1 Linux C Library> libc.2.2 Dynamic linker ldd (GNU libc) 2.2 Procps 2.0.2 Mount 2.10q Net-tools 1.57 Kbd1.00 Sh-utils 2.0 Modules Loaded [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : Celeron (Mendocino) stepping: 5 cpu MHz : 476.085 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr
kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! - reproducible
Trond, Neil I don't know if this is a loopback bug or an NFS bug but since nfs_fs.h was implicated so I thought one of you may be interested. Could you let me know if you know this problem has already been fixed or if you need more info. Martin [1.] One line summary of the problem: kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! [2.] Full description of the problem/report: BUG while trying to read from NFS file mounted locally via loopback. NFS client(heli, UP) server(shadow, SMP) are 2.4.0-test12 NFSv3. shadow mounted a file system image via loopback to a local mount point. shadow:/mnt#mount heli:/tmp on /mnt type nfs (rw,addr=192.168.0.2) shadow:/mnt/uml# file root_fs_slackware_7.1_small root_fs_slackware_7.1_small: x86 boot sector, extended partition table shadow:/mnt/uml# mount -o loop root_fs_slackware_7.1_small /mnt1 shadow:/mnt/uml# mount heli:/tmp on /mnt type nfs (rw,addr=192.168.0.2) /mnt/uml/root_fs_slackware_7.1_small on /mnt1 type ext2 (rw,loop=/dev/loop/0) shadow:/mnt/uml# cd /mnt1 shadow:/mnt1# lf /usr/local/bin/lf: line 1: 585 Segmentation fault ls $LS_OPTIONS $1 [3.] Keywords (i.e., modules, networking, kernel): nfs, loopback [4.] Kernel version (from /proc/version): Linux version 2.4.0-test12 (mhvl@shadow) (gcc version 2.95.2 19991024 (release)) #1 SMP Tue Dec 12 20:46:11 CST 2000 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) ksymoops 2.3.5 on i686 2.4.0-test12. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test12/ (default) -m /boot/System.map-2.4.0-test12 (specified) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? activating NMI Watchdog ... done. cpu: 0, clocks: 680220, slice: 226740 cpu: 1, clocks: 680220, slice: 226740 kernel BUG at /usr/src/linux/include/linux/nfs_fs.h:167! invalid operand: CPU:0 EIP:0010:[c015c351] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 0039 ebx: c8639ae0 ecx: edx: 0002 esi: cba46840 edi: c78592c0 ebp: c05f6000 esp: c05f7d08 ds: 0018 es: 0018 ss: 0018 Process ls (pid: 585, stackpage=c05f7000) Stack: c0231b65 c0231d40 00a7 c081fda0 c0a473c0 c1018fd4 c015b30d c081fda0 c0a473c0 c1018fd4 1000 c0a473c0 c1018fd4 c081fda0 fff4 c015bb11 c081fda0 c0a473c0 c1018fd4 c13a9b7c c1018fd4 Call Trace: [c0231b65] [c0231d40] [c015b30d] [c015bb11] [c0125d33] [c01839bc] [c01838c4] [c0183ceb] [c01829cf] [c0182b4d] [c0182bb0] [c0182d37] [c015207d] [c0150725] [c0112e58] [c0124891] [c014086c] [c0140c3c] [c0140d97] [c0140c3c] [c0123578] [c010b073] Code: 0f 0b 83 c4 0c 89 7e 1c eb 26 90 8d 74 26 00 6a 00 8b 54 24 EIP; c015c351 nfs_create_request+195/1e4 = Trace; c0231b65 devfsd_buf_size+1c85/1196c Trace; c0231d40 devfsd_buf_size+1e60/1196c Trace; c015b30d nfs_readpage_async+13d/1c0 Trace; c015bb11 nfs_readpage+c5/12c Trace; c0125d33 do_generic_file_read+32f/57c Trace; c01839bc lo_receive+58/68 Trace; c01838c4 lo_read_actor+0/a0 Trace; c0183ceb do_lo_request+31f/414 Trace; c01829cf __make_request+5bb/638 Trace; c0182b4d generic_make_request+101/110 Trace; c0182bb0 submit_bh+54/5c Trace; c0182d37 ll_rw_block+137/1a4 Trace; c015207d ext2_bread+d1/114 Trace; c0150725 ext2_readdir+91/37c Trace; c0112e58 do_page_fault+0/3e8 Trace; c0124891 merge_segments+15d/18c Trace; c014086c vfs_readdir+8c/e8 Trace; c0140c3c filldir64+0/10c Trace; c0140d97 sys_getdents64+4f/b8 Trace; c0140c3c filldir64+0/10c Trace; c0123578 sys_brk+b4/d8 Trace; c010b073 system_call+33/38 Code; c015c351 nfs_create_request+195/1e4 _EIP: Code; c015c351 nfs_create_request+195/1e4 = 0: 0f 0b ud2a = Code; c015c353 nfs_create_request+197/1e4 2: 83 c4 0c add$0xc,%esp Code; c015c356 nfs_create_request+19a/1e4 5: 89 7e 1c mov%edi,0x1c(%esi) Code; c015c359 nfs_create_request+19d/1e4 8: eb 26 jmp30 _EIP+0x30 c015c381 nfs_create_request+1c5/1e4 Code; c015c35b nfs_create_request+19f/1e4 a: 90nop Code; c015c35c nfs_create_request+1a0/1e4 b: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c015c360 nfs_create_request+1a4/1e4 f: 6a 00 push $0x0 Code; c015c362 nfs_create_request+1a6/1e4 11: 8b 54 24 00 mov0x0(%esp,1),%edx 1 warning issued. Results may not be reliable. [6.] A small shell script or example program which triggers the problem (if possible) see description of problem [7.] Environment [7.1.] Software (add the output of the ver_linux script here) -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux shadow
Cache problems on test12-pre?
Hi, I've notices weird compile time failures etc on test12-pre7, especially running more than 2 simultaneous processes... but most noticeable is the time it takes to run ldconfig, after the first time test11 takes less than 1 second, test12-pre7 takes ~40 seconds. both were run immediately after reboot on a completely idle system this system is almost exclusively NFS mounted file systems. Is this a known problem? Martin here is test11 vs test12-pre7 shadow:~# time ldconfig shadow:~# time ldconfig real0m35.881sreal0m43.979s user0m0.120s user0m0.090s sys 0m0.890s sys 0m0.980s shadow:~# time ldconfig shadow:~# time ldconfig real0m0.870s real0m38.702s user0m0.040s user0m0.120s sys 0m0.230s sys 0m0.980s shadow:~# time ldconfig shadow:~# time ldconfig real0m0.345s real0m40.181s user0m0.040s user0m0.130s sys 0m0.070s sys 0m0.900s shadow:~# time ldconfig shadow:~# time ldconfig real0m0.098s - real0m39.108s user0m0.050s user0m0.110s sys 0m0.050s sys 0m1.180s - 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/
another buffer.c:827 BUG, RAID1 reconstruction.
Hi, I got this BUG report after test12-pre7 soft locked on my NFS server, all nfsd's in D state and I had to reboot and system was rebuilding the ide RAID1 arrays. NFS client test12-pre7 was rebooted as well, root logged in, and ran ldconfig NFS server BUG'd out Hand copied OOPS hope too much isn't wrong. Martin heli:~$ ksymoops -K -L -O -m /boot/System.map-2.4.0-test12 < buffer.bug ksymoops 2.3.5 on i586 2.2.17-RAID. Options used -V (default) -K (specified) -L (specified) -O (specified) -m /boot/System.map-2.4.0-test12 (specified) Kernel BUG at buffer.c 827 invalid operand: CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: 001c ebx: c10837d0 ecx: edx: esi: c1be2e40 edi: 0002 epb: c1be2e88 esp: c0275ea8 ds: 0018 es: 0018 ss: 0018 Stack: c02151a5 c021545a 033b 0001e2ba 0046 c13c7be0 cabe2e40 c011c226c c1b32e40 0001 c13c7be0 c13c7bf8 0001 0001 c01c2392 c13c7be0 0001 c13c7b88 c11d3780 0002 c0174c39 c13c7bf8 0001 c11d3780 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] code: 0f 06 83 c4 0c 8d 73 28 8d 43 2c 39 43 2c 74 15 b9 01 00 00 >>EIP; c012ca53<= Trace; c0215195 Trace; c021545a Trace; c01c226e Trace; c01c2399 Trace; c0174c39 Trace; c019db3b Trace; c01a60b4 Trace; c019f367 Trace; c01a6050 Trace; c010a04f Trace; c010a1ae Trace; c01071f0 Trace; e000 Trace; c0108f20 Trace; c0107180 Trace; e000 Trace; c0107213 Trace; c0107277 Trace; c0105000 Trace; c0100191 Code; c012ca53 <_EIP>: Code; c012ca53<= 0: 0f 06 clts <= Code; c012ca55 2: 83 c4 0c add$0xc,%esp Code; c012ca58 5: 8d 73 28 lea0x28(%ebx),%esi Code; c012ca5b 8: 8d 43 2c lea0x2c(%ebx),%eax Code; c012ca5e b: 39 43 2c cmp%eax,0x2c(%ebx) Code; c012ca61 e: 74 15 je 25 <_EIP+0x25> c012ca78 Code; c012ca63 10: b9 01 00 00 00mov$0x1,%ecx Aiee, killing interrupt handler heli:~$ - 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/
another buffer.c:827 BUG, RAID1 reconstruction.
Hi, I got this BUG report after test12-pre7 soft locked on my NFS server, all nfsd's in D state and I had to reboot and system was rebuilding the ide RAID1 arrays. NFS client test12-pre7 was rebooted as well, root logged in, and ran ldconfig NFS server BUG'd out Hand copied OOPS hope too much isn't wrong. Martin heli:~$ ksymoops -K -L -O -m /boot/System.map-2.4.0-test12 buffer.bug ksymoops 2.3.5 on i586 2.2.17-RAID. Options used -V (default) -K (specified) -L (specified) -O (specified) -m /boot/System.map-2.4.0-test12 (specified) Kernel BUG at buffer.c 827 invalid operand: CPU: 0 EIP: 0010:[c012ca53] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: 001c ebx: c10837d0 ecx: edx: esi: c1be2e40 edi: 0002 epb: c1be2e88 esp: c0275ea8 ds: 0018 es: 0018 ss: 0018 Stack: c02151a5 c021545a 033b 0001e2ba 0046 c13c7be0 cabe2e40 c011c226c c1b32e40 0001 c13c7be0 c13c7bf8 0001 0001 c01c2392 c13c7be0 0001 c13c7b88 c11d3780 0002 c0174c39 c13c7bf8 0001 c11d3780 Call Trace: [c0215195] [c021545a] [c01c226e] [c01c2399] [c0174c39] [c019db3b] [c01a60b4] [c019f367] [c01a6050] [c010a04f] [c010a1ae] [c01071f0] [e000] [c0108f20] [c0107180] [e000] [c0107213] [c0107277] [c0105000] [c0100191] code: 0f 06 83 c4 0c 8d 73 28 8d 43 2c 39 43 2c 74 15 b9 01 00 00 EIP; c012ca53 end_buffer_io_async+c7/f4 = Trace; c0215195 tvecs+318d/19d24 Trace; c021545a tvecs+3452/19d24 Trace; c01c226e raid1_end_bh_io+7e/110 Trace; c01c2399 raid1_end_request+99/a0 Trace; c0174c39 end_that_request_first+65/c4 Trace; c019db3b ide_end_request+27/74 Trace; c01a60b4 ide_dma_intr+64/9c Trace; c019f367 ide_intr+fb/150 Trace; c01a6050 ide_dma_intr+0/9c Trace; c010a04f handle_IRQ_event+2f/58 Trace; c010a1ae do_IRQ+6e/b0 Trace; c01071f0 default_idle+0/28 Trace; e000 END_OF_CODE+3fd2af28/ Trace; c0108f20 ret_from_intr+0/20 Trace; c0107180 init+a4/104 Trace; e000 END_OF_CODE+3fd2af28/ Trace; c0107213 default_idle+23/28 Trace; c0107277 cpu_idle+3f/54 Trace; c0105000 empty_bad_page+0/1000 Trace; c0100191 L6+0/2 Code; c012ca53 end_buffer_io_async+c7/f4 _EIP: Code; c012ca53 end_buffer_io_async+c7/f4 = 0: 0f 06 clts = Code; c012ca55 end_buffer_io_async+c9/f4 2: 83 c4 0c add$0xc,%esp Code; c012ca58 end_buffer_io_async+cc/f4 5: 8d 73 28 lea0x28(%ebx),%esi Code; c012ca5b end_buffer_io_async+cf/f4 8: 8d 43 2c lea0x2c(%ebx),%eax Code; c012ca5e end_buffer_io_async+d2/f4 b: 39 43 2c cmp%eax,0x2c(%ebx) Code; c012ca61 end_buffer_io_async+d5/f4 e: 74 15 je 25 _EIP+0x25 c012ca78 end_buffer_io_async+ec/f4 Code; c012ca63 end_buffer_io_async+d7/f4 10: b9 01 00 00 00mov$0x1,%ecx Aiee, killing interrupt handler heli:~$ - 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/
Cache problems on test12-pre?
Hi, I've notices weird compile time failures etc on test12-pre7, especially running more than 2 simultaneous processes... but most noticeable is the time it takes to run ldconfig, after the first time test11 takes less than 1 second, test12-pre7 takes ~40 seconds. both were run immediately after reboot on a completely idle system this system is almost exclusively NFS mounted file systems. Is this a known problem? Martin here is test11 vs test12-pre7 shadow:~# time ldconfig shadow:~# time ldconfig real0m35.881sreal0m43.979s user0m0.120s user0m0.090s sys 0m0.890s sys 0m0.980s shadow:~# time ldconfig shadow:~# time ldconfig real0m0.870s real0m38.702s user0m0.040s user0m0.120s sys 0m0.230s sys 0m0.980s shadow:~# time ldconfig shadow:~# time ldconfig real0m0.345s real0m40.181s user0m0.040s user0m0.130s sys 0m0.070s sys 0m0.900s shadow:~# time ldconfig shadow:~# time ldconfig real0m0.098s - real0m39.108s user0m0.050s user0m0.110s sys 0m0.050s sys 0m1.180s - 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: run level 1, login takes too long, 2.4.X vs. 2.2.X
Hi David, Yup, I know rpc.portmap isn't running, the point is that it wasn't running on either 2.2.17 or 2.4.X. Isn't run level 1 supposed to only be the bare minimum of running processes, a few kernel processes, init and getty. No network services... What's changed in the kernel to elicit this behavior? Is there a better "faster" way to get root access at run level 1 w/o login & passwd on 2.4.X? No it's not an everyday occurance, but I was impatiently thinking the sytem had locked up and rebooted a couple of times, so it got me wondering why 2.2.X and 2.4.X differ in this basic behavior. Martin David Ford wrote: > > rpc.portmap isn't running, your login configuration/nss requires yp or something >provided ans an RPC. > > -d > > "M.H.VanLeeuwen" wrote: > > > I had occasion to "telinit 1" today and found that it took a long time > > to login after root passwd was entered. this doesn't happen with 2.2.X > > kernels. > > > > Is this to be expected with the 2.4 series kernels? or a bug? > > > > Martin - 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/
run level 1, login takes too long, 2.4.X vs. 2.2.X
I had occasion to "telinit 1" today and found that it took a long time
to login after root passwd was entered. this doesn't happen with 2.2.X
kernels.
Is this to be expected with the 2.4 series kernels? or a bug?
Martin
strace for 2.4.0-test11-pre7
---snip---
gettimeofday({974665658, 952483}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
getpid()= 305
bind(3, {sin_family=AF_INET, sin_port=htons(905), sin_addr=inet_addr("0.0.0.0")}}, 16)
= 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "\31\23\233@\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN}], 1, 5000) = 0
ioctl(3, SIOCGIFCONF, 0xbfffb33c) = 0
ioctl(3, SIOCGIFFLAGS, 0xbfffb344) = 0
sendto(3, "\31\23\233@\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
---snip---
strace for 2.2.17
---snip---
gettimeofday({974664928, 735539}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
getpid()= 368
bind(3, {sin_family=AF_INET, sin_port=htons(968), sin_addr=inet_addr("0.0.0.0")}}, 16)
= 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "_c\353\331\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN, revents=POLLERR}], 1, 5000) = 1
recvfrom(3, 0x8056380, 400, 0, 0xbfffd66c, 0xbfffd618) = -1 ECONNREFUSED (Connection
refused)
close(3)= 0
---snip---
-
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/
run level 1, login takes too long, 2.4.X vs. 2.2.X
I had occasion to "telinit 1" today and found that it took a long time
to login after root passwd was entered. this doesn't happen with 2.2.X
kernels.
Is this to be expected with the 2.4 series kernels? or a bug?
Martin
strace for 2.4.0-test11-pre7
---snip---
gettimeofday({974665658, 952483}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
getpid()= 305
bind(3, {sin_family=AF_INET, sin_port=htons(905), sin_addr=inet_addr("0.0.0.0")}}, 16)
= 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "\31\23\233@\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN}], 1, 5000) = 0
ioctl(3, SIOCGIFCONF, 0xbfffb33c) = 0
ioctl(3, SIOCGIFFLAGS, 0xbfffb344) = 0
sendto(3, "\31\23\233@\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
---snip---
strace for 2.2.17
---snip---
gettimeofday({974664928, 735539}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
getpid()= 368
bind(3, {sin_family=AF_INET, sin_port=htons(968), sin_addr=inet_addr("0.0.0.0")}}, 16)
= 0
ioctl(3, FIONBIO, [1]) = 0
sendto(3, "_c\353\331\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN, revents=POLLERR}], 1, 5000) = 1
recvfrom(3, 0x8056380, 400, 0, 0xbfffd66c, 0xbfffd618) = -1 ECONNREFUSED (Connection
refused)
close(3)= 0
---snip---
-
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: run level 1, login takes too long, 2.4.X vs. 2.2.X
Hi David, Yup, I know rpc.portmap isn't running, the point is that it wasn't running on either 2.2.17 or 2.4.X. Isn't run level 1 supposed to only be the bare minimum of running processes, a few kernel processes, init and getty. No network services... What's changed in the kernel to elicit this behavior? Is there a better "faster" way to get root access at run level 1 w/o login passwd on 2.4.X? No it's not an everyday occurance, but I was impatiently thinking the sytem had locked up and rebooted a couple of times, so it got me wondering why 2.2.X and 2.4.X differ in this basic behavior. Martin David Ford wrote: rpc.portmap isn't running, your login configuration/nss requires yp or something provided ans an RPC. -d "M.H.VanLeeuwen" wrote: I had occasion to "telinit 1" today and found that it took a long time to login after root passwd was entered. this doesn't happen with 2.2.X kernels. Is this to be expected with the 2.4 series kernels? or a bug? Martin - 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-test10
"CRADOCK, Christopher" wrote: > > I have a similar hardware list and I don't observe any of these problems on > 2.4.0-test10x. Is it possibly a hardware conflict somewhere? > > What I do see occasionally is if X was ever heavy on the memory usage (say > I've run GIMP for a couple of hours) then the text console's font set gets > trashed until the next reboot. Console driver failing to reset something? > > Chris Cradock > Hi Chris Never had the trashed fonts before. How about a better comparison of systems? All I mentioned were r128, ne2k, PIIX4 and SMP, barely enough to claim similar hardware thus these aren't real problems cause you don't see them. I can send you gory details if your interested. My reason for claiming these are problems, maybe not show stoppers, are: This system is rock solid on 2.2.X. problem 1, shouldn't fail on 2.4 if it works just fine on 2.2. Probably a locking issue but I'm not sure. Any idea where to put some BKL's to see if the problem will go away? problem 2, happens randomly, so is it a hardware problem or a software issue? being that the system works fine SMP and UP then my guess is a software interaction when UP-APIC is enabled, a race condition?? problem 3, new feature in 2.4, one would expect, hey, I've got this hdwr in my system, let me enable this option... wait a minute the system doesn't boot... problem 4, ISAPNP in the kernel is new for 2.4, i was pointing out that it can be improved to make it better able to select IRQ's that work so that the user can just upgrade to 2.4 without having to tweak the BIOS and/or the code. I sent a patch to Linus but he rejected it, yes I realize it was a weak attempt but it fixed my ISAPNP problems, and no one has proposed a better solution. Shouldn't the first release of 2.4.0 show that it's new capabilities are ready for prime time? Thanks, Martin > 1. kernel compiled w/o FB support. When attempting to switch > back to X from VC1-6 system locks hard for SMP. Nada thing > fixes this except hard reset... no Alt-SysRq-B, nothing > DRI not enabled. Video card has r128 chipset. > > 2. System is a NFS root machine, after a period of heavy ntwk > activity, eg. "make clean" in /usr/src/linux ETH0 no longer > works or sometimes just ntwk activity during system boot is > enough to cause the ETH activity to cease. > The only recourse is to Alt-SysRq-B the system. > NIC = NE2K ISA > > 3. Enabling PIIX4, kernel locks hard when printing the partition >tables for hdc. hdc has no partitions. >I think this problem is on Ted's problem list??? > > 4. ISAPNP assigns an invalid/unusable IRQ to NE2K NIC card. >Previously reported to Linus & Ingo, they asked for an MPTABLE >dump, haven't heard back since providing said data. - 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-test10
David Ford wrote: > > "M.H.VanLeeuwen" wrote: > > > 3. Enabling PIIX4, kernel locks hard when printing the partition > >tables for hdc. hdc has no partitions. > >I think this problem is on Ted's problem list??? > > Disable PIIXn tuning and recompile your kernel. How does it fare now? > Yep, disabling (opposite of "enabling") does allow the kernel to boot just fine. PIIXn tuning must be tickling something on the system so that the first time we read from the disk, partition check block 0, the system freezes hard. I do know that w/o PIIXn tuning the result of the first block read is all zero's hence the "/dev/ide/host0/bus0/target1/lun0: unknown partition table" message. Any idea how to go about debugging this kind of lockup? Guess i'll scrounge up a couple of disks and see if it's controller or disk related. Weren't you also experiencing this type of problem on a laptop? Martin lspci -v 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 32 I/O ports at f000 [size=16] 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at d000 [size=32] 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) Flags: medium devsel - 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-test10
David Ford wrote: "M.H.VanLeeuwen" wrote: 3. Enabling PIIX4, kernel locks hard when printing the partition tables for hdc. hdc has no partitions. I think this problem is on Ted's problem list??? Disable PIIXn tuning and recompile your kernel. How does it fare now? Yep, disabling (opposite of "enabling") does allow the kernel to boot just fine. PIIXn tuning must be tickling something on the system so that the first time we read from the disk, partition check block 0, the system freezes hard. I do know that w/o PIIXn tuning the result of the first block read is all zero's hence the "/dev/ide/host0/bus0/target1/lun0: unknown partition table" message. Any idea how to go about debugging this kind of lockup? Guess i'll scrounge up a couple of disks and see if it's controller or disk related. Weren't you also experiencing this type of problem on a laptop? Martin lspci -v 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 32 I/O ports at f000 [size=16] 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at d000 [size=32] 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) Flags: medium devsel - 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-test10
"CRADOCK, Christopher" wrote: I have a similar hardware list and I don't observe any of these problems on 2.4.0-test10x. Is it possibly a hardware conflict somewhere? What I do see occasionally is if X was ever heavy on the memory usage (say I've run GIMP for a couple of hours) then the text console's font set gets trashed until the next reboot. Console driver failing to reset something? Chris Cradock Hi Chris Never had the trashed fonts before. How about a better comparison of systems? All I mentioned were r128, ne2k, PIIX4 and SMP, barely enough to claim similar hardware thus these aren't real problems cause you don't see them. I can send you gory details if your interested. My reason for claiming these are problems, maybe not show stoppers, are: This system is rock solid on 2.2.X. problem 1, shouldn't fail on 2.4 if it works just fine on 2.2. Probably a locking issue but I'm not sure. Any idea where to put some BKL's to see if the problem will go away? problem 2, happens randomly, so is it a hardware problem or a software issue? being that the system works fine SMP and UP then my guess is a software interaction when UP-APIC is enabled, a race condition?? problem 3, new feature in 2.4, one would expect, hey, I've got this hdwr in my system, let me enable this option... wait a minute the system doesn't boot... problem 4, ISAPNP in the kernel is new for 2.4, i was pointing out that it can be improved to make it better able to select IRQ's that work so that the user can just upgrade to 2.4 without having to tweak the BIOS and/or the code. I sent a patch to Linus but he rejected it, yes I realize it was a weak attempt but it fixed my ISAPNP problems, and no one has proposed a better solution. Shouldn't the first release of 2.4.0 show that it's new capabilities are ready for prime time? Thanks, Martin 1. kernel compiled w/o FB support. When attempting to switch back to X from VC1-6 system locks hard for SMP. Nada thing fixes this except hard reset... no Alt-SysRq-B, nothing DRI not enabled. Video card has r128 chipset. 2. System is a NFS root machine, after a period of heavy ntwk activity, eg. "make clean" in /usr/src/linux ETH0 no longer works or sometimes just ntwk activity during system boot is enough to cause the ETH activity to cease. The only recourse is to Alt-SysRq-B the system. NIC = NE2K ISA 3. Enabling PIIX4, kernel locks hard when printing the partition tables for hdc. hdc has no partitions. I think this problem is on Ted's problem list??? 4. ISAPNP assigns an invalid/unusable IRQ to NE2K NIC card. Previously reported to Linus Ingo, they asked for an MPTABLE dump, haven't heard back since providing said data. - 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-test10
FYI, My list of 2.4.0-testX problems Further details, .config, etc...available if needed Martin 2.4.0-test10 and earlier problem list: Problem | UP UP-APIC SMP | 1 | OK OK HARDLOCK 2 | OK FAILS OK 3 | HARDLOCKHARDLOCKHARDLOCK 4 | BROKEN BROKEN BROKEN Problem description: 1. kernel compiled w/o FB support. When attempting to switch back to X from VC1-6 system locks hard for SMP. Nada thing fixes this except hard reset... no Alt-SysRq-B, nothing DRI not enabled. Video card has r128 chipset. 2. System is a NFS root machine, after a period of heavy ntwk activity, eg. "make clean" in /usr/src/linux ETH0 no longer works or sometimes just ntwk activity during system boot is enough to cause the ETH activity to cease. The only recourse is to Alt-SysRq-B the system. NIC = NE2K ISA 3. Enabling PIIX4, kernel locks hard when printing the partition tables for hdc. hdc has no partitions. I think this problem is on Ted's problem list??? 4. ISAPNP assigns an invalid/unusable IRQ to NE2K NIC card. Previously reported to Linux & Ingo, they asked for an MPTABLE dump, haven't heard back since providing said data. - 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-test10
FYI, My list of 2.4.0-testX problems Further details, .config, etc...available if needed Martin 2.4.0-test10 and earlier problem list: Problem | UP UP-APIC SMP | 1 | OK OK HARDLOCK 2 | OK FAILS OK 3 | HARDLOCKHARDLOCKHARDLOCK 4 | BROKEN BROKEN BROKEN Problem description: 1. kernel compiled w/o FB support. When attempting to switch back to X from VC1-6 system locks hard for SMP. Nada thing fixes this except hard reset... no Alt-SysRq-B, nothing DRI not enabled. Video card has r128 chipset. 2. System is a NFS root machine, after a period of heavy ntwk activity, eg. "make clean" in /usr/src/linux ETH0 no longer works or sometimes just ntwk activity during system boot is enough to cause the ETH activity to cease. The only recourse is to Alt-SysRq-B the system. NIC = NE2K ISA 3. Enabling PIIX4, kernel locks hard when printing the partition tables for hdc. hdc has no partitions. I think this problem is on Ted's problem list??? 4. ISAPNP assigns an invalid/unusable IRQ to NE2K NIC card. Previously reported to Linux Ingo, they asked for an MPTABLE dump, haven't heard back since providing said data. - 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/
tun/tap devices on 2.4.0-testX
need help getting tapX devices operational on 2.4 for 2.4 using the new tun.o module I cannot create a tap0 interface. on 2.2 it is the ethertap.o module. changing modules.conf allows the module to load but the interface does not come up: ifconfig tap0 192.168.0.10 up SIOCSIFADDR: No such device tap0: unknown interface: No such device tap0: unknown interface: No such device has anyone successfully gotten this to work, if so how? using devfs, which has created /dev/netlink/tapX devices... symlinking /dev/netlink/tap0 /dev/tap0 doesn't help. #define TUN_DEBUG 1, in tun.c doesn't help, fails to compile. TIA Martin - 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] ISAPNP using an invalid IO_APIC IRQ
Alan Cox wrote: > > IRQ 5 may well have gone to an onboard device. > > There are two things to note here: > > 1. By default if you boot with non PnP OS the BIOS will assign IRQ's > to PnP devices and we would be best to try and keep the existing value when > possible (so the PCI/ISA routing is correct) Yes, when I tell the BIOS that the OS is not PnP aware it assigns IRQ 9 to NIC, yet Linux tries to assign it to IRQ 5. Martin - 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] ISAPNP using an invalid IO_APIC IRQ
Alan Cox wrote: IRQ 5 may well have gone to an onboard device. There are two things to note here: 1. By default if you boot with non PnP OS the BIOS will assign IRQ's to PnP devices and we would be best to try and keep the existing value when possible (so the PCI/ISA routing is correct) Yes, when I tell the BIOS that the OS is not PnP aware it assigns IRQ 9 to NIC, yet Linux tries to assign it to IRQ 5. Martin - 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] ISAPNP using an invalid IO_APIC IRQ
Linus Torvalds wrote:
>
> On Thu, 21 Sep 2000, M.H.VanLeeuwen wrote:
> >
> > Is this patch acceptable?
>
> Please explain.
>
> The test seems to be that "if there are IO_APICs, a PnP irq _has_ to be an
> IO_APIC irq".
>
> > + if (!IO_APIC_IRQ(irq) && io_apic_irqs)
> > + return 1;
>
> Which makes no sense to me. Why would a legacy irq not be acceptable?
firstly, I have no understanding of IO_APIC vs. legacy IRQ handling in i386
hardware so what I say may be completely wrong. I'll explain my circumstance
and we'll go from there.
Legacy would be just fine, but ISAPNP is attempting to assign an IRQ that is
unavailable on my system. In otherwords, the BIOS has assigned it to some
other function and thus the IRQ doesn't appear to Linux as even existing.
In my case IRQ5 was assigned to "DISPLAY CONTROLLER" and IRQ5 isn't available
to the system, excerpts from dmesg:
...
Bus #2 is ISA
I/O APIC #2 Version 17 at 0xFEC0.
Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 *** NO ISA IRQ 5 ***
Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06
...
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
Synchronizing Arb IDs.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-17, 2-20, 2-21, 2-22, 2-23 not connected.
^ no IRQ 5 ?
...
IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
04 003 03 000 0 01149
05 000 00 100 0 00000 *** IRQ 5 ??? ***
06 003 03 000 0 01151
Yet ISAPNP decided to assign that IRQ5 to my NIC. ne.c fails to operate
when there are plenty of other IRQs still available.
The difference is in this logic between _no_ IO-APIC and _yes_ IO_APIC
in isapnp.c
isapnp_for_each_dev(dev) {
if (dev->active) {
if (dev->irq_resource[0].start == irq ||
dev->irq_resource[1].start == irq)
return 1;
}
}
since w/o IO_APIC no PIC->APIC IRQ transform is done and this returns 1
and IRQ 5 is not used. With IO_APIC no match occurs and the system attempt
to use IRQ 5, thus a hung system.
Hence, my attempt to rule out APIC IRQs that were unavailable to the system,
also assuming the legacy IRQs would also not be available. This may not be
globally true, but seems to be on my system. Abit BP6, nu Bios.
This entire problem would not have bothered me too badly, had the system
come up and run, but w/o explicitly telling the BIOS to reserve an ISA
IRQ ISAPNP eventually decides to try IRQ 12. IRQ sharing with PS/2 mouse
and ne.c fail miserably. On 2.2.X I had been using IRQ9 for ne.c card.
With 2.4 IRQ 9 is listed after IRQ 12 in xtab[16] (isapnp.c) so the system
fails to boot.
> Especially as they seem to be acceptable if there are _no_ IO-APIC irq's.
Only if they work. ;)
More info on request or tell me to go away, _grin_ again.
Martin
-
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] ISAPNP using an invalid IO_APIC IRQ
Linus,
Is this patch acceptable?
info & patch below.
Martin
>>Jaroslav
>>
>>Basically, this patch discards any unusable IO_APIC IRQs from the list of IRQs
>>that ISA PNP is trying to allocate from - but only if IO_APIC IRQs are available.
>>
>>Comments?
>>Martin
Jaroslav Kysela wrote:
>
>It works only for i386.
>
>I suggest to add:
>
>#ifndef IO_APIC_IRQ
I used CONFIG_X86_IO_APIC instead
>#define IO_APIC_IRQ(x)
>#define io_apic_irqs 0
>#endif
>
>Also, isapnp_proc.c shouldn't be changed. I prefer to see all possible
>IRQs, although they can't be used. Feel free to post this patch to Linus
>and lkml.
I left in the patch for isapnp_proc.c just in case...
>
>Jaroslav
updated patch
--- /home/mhvl/linux.orig/drivers/pnp/isapnp.c Tue Jul 25 20:25:14 2000
+++ /home/mhvl/linux/drivers/pnp/isapnp.c Wed Sep 20 20:59:56 2000
@@ -33,10 +33,10 @@
#include
#include
#include
-#include
#include
#include
#include
+#include
LIST_HEAD(isapnp_cards);
LIST_HEAD(isapnp_devices);
@@ -48,6 +48,11 @@
#define ISAPNP_DEBUG
#endif
+#ifndef CONFIG_X86_IO_APIC
+#define IO_APIC_IRQ(x) 0
+#define io_apic_irqs 0
+#endif
+
struct resource *pidxr_res = NULL;
struct resource *pnpwrp_res = NULL;
struct resource *isapnp_rdp_res = NULL;
@@ -1598,6 +1603,8 @@
if (irq < 0 || irq > 15)
return 1;
+ if (!IO_APIC_IRQ(irq) && io_apic_irqs)
+ return 1;
for (i = 0; i < 16; i++) {
if (isapnp_reserve_irq[i] == irq)
return 1;
--- /home/mhvl/linux.orig/drivers/pnp/isapnp_proc.c Wed Jul 12 23:58:43 2000
+++ /home/mhvl/linux/drivers/pnp/isapnp_proc.c Tue Sep 19 17:52:25 2000
@@ -30,6 +30,12 @@
#include
#include
#include
+#include
+
+#ifndef CONFIG_X86_IO_APIC
+#define IO_APIC_IRQ(x) 0
+#define io_apic_irqs 0
+#endif
struct isapnp_info_buffer {
char *buffer; /* pointer to begin of buffer */
@@ -448,7 +454,7 @@
isapnp_printf(buffer, "%sIRQ ", space);
for (i = 0; i < 16; i++)
- if (irq->map & (1<map & (1<From previous e-mails
"M.H.VanLeeuwen" wrote:
>
> Jaroslav Kysela wrote:
> >
> > On Tue, 29 Aug 2000, M.H.VanLeeuwen wrote:
> >
> > > With default BIOS settings, IRQ 5 is unavailable for ISA yet
> > > it is being assigned by the ne.c driver and NFS root system
> > > doesn't finish booting.
> > >
> > > Is this a driver problem or a ISAPNP problem?
> >
> > It is general IRQ manager problem. ISA PnP code cannot determine which
> > interrupts cannot be used. I think that we need some next layer between
> > IO APIC control code and Plug & Play routines to exchange this information
> > to prevent allocation of a free but unuseable IRQ for ISA PnP devices.
> >
> > Jaroslav
-
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] ISAPNP using an invalid IO_APIC IRQ
Linus,
Is this patch acceptable?
info patch below.
Martin
Jaroslav
Basically, this patch discards any unusable IO_APIC IRQs from the list of IRQs
that ISA PNP is trying to allocate from - but only if IO_APIC IRQs are available.
Comments?
Martin
Jaroslav Kysela wrote:
It works only for i386.
I suggest to add:
#ifndef IO_APIC_IRQ
I used CONFIG_X86_IO_APIC instead
#define IO_APIC_IRQ(x)
#define io_apic_irqs 0
#endif
Also, isapnp_proc.c shouldn't be changed. I prefer to see all possible
IRQs, although they can't be used. Feel free to post this patch to Linus
and lkml.
I left in the patch for isapnp_proc.c just in case...
Jaroslav
updated patch
--- /home/mhvl/linux.orig/drivers/pnp/isapnp.c Tue Jul 25 20:25:14 2000
+++ /home/mhvl/linux/drivers/pnp/isapnp.c Wed Sep 20 20:59:56 2000
@@ -33,10 +33,10 @@
#include linux/delay.h
#include asm/io.h
#include asm/dma.h
-#include asm/irq.h
#include linux/pci.h
#include linux/init.h
#include linux/isapnp.h
+#include linux/irq.h
LIST_HEAD(isapnp_cards);
LIST_HEAD(isapnp_devices);
@@ -48,6 +48,11 @@
#define ISAPNP_DEBUG
#endif
+#ifndef CONFIG_X86_IO_APIC
+#define IO_APIC_IRQ(x) 0
+#define io_apic_irqs 0
+#endif
+
struct resource *pidxr_res = NULL;
struct resource *pnpwrp_res = NULL;
struct resource *isapnp_rdp_res = NULL;
@@ -1598,6 +1603,8 @@
if (irq 0 || irq 15)
return 1;
+ if (!IO_APIC_IRQ(irq) io_apic_irqs)
+ return 1;
for (i = 0; i 16; i++) {
if (isapnp_reserve_irq[i] == irq)
return 1;
--- /home/mhvl/linux.orig/drivers/pnp/isapnp_proc.c Wed Jul 12 23:58:43 2000
+++ /home/mhvl/linux/drivers/pnp/isapnp_proc.c Tue Sep 19 17:52:25 2000
@@ -30,6 +30,12 @@
#include asm/uaccess.h
#include linux/smp_lock.h
#include linux/isapnp.h
+#include linux/irq.h
+
+#ifndef CONFIG_X86_IO_APIC
+#define IO_APIC_IRQ(x) 0
+#define io_apic_irqs 0
+#endif
struct isapnp_info_buffer {
char *buffer; /* pointer to begin of buffer */
@@ -448,7 +454,7 @@
isapnp_printf(buffer, "%sIRQ ", space);
for (i = 0; i 16; i++)
- if (irq-map (1i)) {
+ if (irq-map (1i) (IO_APIC_IRQ(i) || !io_apic_irqs)) {
if (!first) {
isapnp_printf(buffer, ",");
} else {
--
From previous e-mails
"M.H.VanLeeuwen" wrote:
Jaroslav Kysela wrote:
On Tue, 29 Aug 2000, M.H.VanLeeuwen wrote:
With default BIOS settings, IRQ 5 is unavailable for ISA yet
it is being assigned by the ne.c driver and NFS root system
doesn't finish booting.
Is this a driver problem or a ISAPNP problem?
It is general IRQ manager problem. ISA PnP code cannot determine which
interrupts cannot be used. I think that we need some next layer between
IO APIC control code and Plug Play routines to exchange this information
to prevent allocation of a free but unuseable IRQ for ISA PnP devices.
Jaroslav
-
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] ISAPNP using an invalid IO_APIC IRQ
Linus Torvalds wrote:
On Thu, 21 Sep 2000, M.H.VanLeeuwen wrote:
Is this patch acceptable?
Please explain.
The test seems to be that "if there are IO_APICs, a PnP irq _has_ to be an
IO_APIC irq".
+ if (!IO_APIC_IRQ(irq) io_apic_irqs)
+ return 1;
Which makes no sense to me. Why would a legacy irq not be acceptable?
firstly, I have no understanding of IO_APIC vs. legacy IRQ handling in i386
hardware so what I say may be completely wrong. I'll explain my circumstance
and we'll go from there.
Legacy would be just fine, but ISAPNP is attempting to assign an IRQ that is
unavailable on my system. In otherwords, the BIOS has assigned it to some
other function and thus the IRQ doesn't appear to Linux as even existing.
In my case IRQ5 was assigned to "DISPLAY CONTROLLER" and IRQ5 isn't available
to the system, excerpts from dmesg:
...
Bus #2 is ISA
I/O APIC #2 Version 17 at 0xFEC0.
Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 *** NO ISA IRQ 5 ***
Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06
...
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
Synchronizing Arb IDs.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-17, 2-20, 2-21, 2-22, 2-23 not connected.
^ no IRQ 5 ?
...
IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
04 003 03 000 0 01149
05 000 00 100 0 00000 *** IRQ 5 ??? ***
06 003 03 000 0 01151
Yet ISAPNP decided to assign that IRQ5 to my NIC. ne.c fails to operate
when there are plenty of other IRQs still available.
The difference is in this logic between _no_ IO-APIC and _yes_ IO_APIC
in isapnp.c
isapnp_for_each_dev(dev) {
if (dev-active) {
if (dev-irq_resource[0].start == irq ||
dev-irq_resource[1].start == irq)
return 1;
}
}
since w/o IO_APIC no PIC-APIC IRQ transform is done and this returns 1
and IRQ 5 is not used. With IO_APIC no match occurs and the system attempt
to use IRQ 5, thus a hung system.
Hence, my attempt to rule out APIC IRQs that were unavailable to the system,
also assuming the legacy IRQs would also not be available. This may not be
globally true, but seems to be on my system. Abit BP6, nu Bios.
This entire problem would not have bothered me too badly, had the system
come up and run, but w/o explicitly telling the BIOS to reserve an ISA
IRQ ISAPNP eventually decides to try IRQ 12. IRQ sharing with PS/2 mouse
and ne.c fail miserably. On 2.2.X I had been using IRQ9 for ne.c card.
With 2.4 IRQ 9 is listed after IRQ 12 in xtab[16] (isapnp.c) so the system
fails to boot.
Especially as they seem to be acceptable if there are _no_ IO-APIC irq's.
Only if they work. ;)
More info on request or tell me to go away, _grin_ again.
Martin
-
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: ISAPNP using an invalid IRQ, 2.4.0-test7
Jaroslav Kysela wrote:
>
> On Tue, 29 Aug 2000, M.H.VanLeeuwen wrote:
>
> > With default BIOS settings, IRQ 5 is unavailable for ISA yet
> > it is being assigned by the ne.c driver and NFS root system
> > doesn't finish booting.
> >
> > Is this a driver problem or a ISAPNP problem?
>
> It is general IRQ manager problem. ISA PnP code cannot determine which
> interrupts cannot be used. I think that we need some next layer between
> IO APIC control code and Plug & Play routines to exchange this information
> to prevent allocation of a free but unuseable IRQ for ISA PnP devices.
>
> Jaroslav
>
Jaroslav,
This patch is a first approximation to the above problem, can U look it over?
Basically, it discards any unusable IO_APIC IRQs from the list of IRQs that
ISA PNP is trying to allocate from - but only if IO_APIC IRQs are available.
This works for none APIC systems as well since io_apic_irqs s/b zero if
APIC's don't exist.
Comments?
Martin
--- /home/mhvl/linux.orig/drivers/pnp/isapnp.c Tue Jul 25 20:25:14 2000
+++ isapnp.cMon Sep 18 21:28:39 2000
@@ -33,10 +33,10 @@
#include
#include
#include
-#include
#include
#include
#include
+#include
LIST_HEAD(isapnp_cards);
LIST_HEAD(isapnp_devices);
@@ -1598,6 +1598,8 @@
if (irq < 0 || irq > 15)
return 1;
+ if (!IO_APIC_IRQ(irq) && io_apic_irqs)
+ return 1;
for (i = 0; i < 16; i++) {
if (isapnp_reserve_irq[i] == irq)
return 1;
--- /home/mhvl/linux.orig/drivers/pnp/isapnp_proc.c Wed Jul 12 23:58:43 2000
+++ isapnp_proc.c Wed Sep 13 22:39:47 2000
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
struct isapnp_info_buffer {
char *buffer; /* pointer to begin of buffer */
@@ -448,7 +449,7 @@
isapnp_printf(buffer, "%sIRQ ", space);
for (i = 0; i < 16; i++)
- if (irq->map & (1<map & (1<http://www.tux.org/lkml/
Re: Update Linux 2.4 Status/TODO list
David Ford wrote: > > Andre Hedrick wrote: > > > > 4. Boot Time Failures > > > > > > * Use PCI DMA 'lost interrupt' problem with some hw [which ?] (NEC > > >Versa LX with PIIX tuning) > > > > If this is a rare version of the BX/LX that has a no fix errata, then it > > will be messy to issue resets to get out of the loop. > > > > > * PIIXn tuning can hang laptop (2.4.0-test8-pre6, David Ford) > > > > Need more details of how APM/ACPI is dorking with DMA settins by the OEM. > > These two are both reported by me, are the same issue. The exact same kernel, > one with PIIXn tuning enabled, will hang the hardware on boot requiring a > physical power loss to restart. > > No tuning options applied, only the capability enabled in the kernel, makes it > crash. > > If necessary I can again provide the boot log and a verbose lspci and whatever > else is desired. I'll even let you log in and look at it. > I have the very same problem with my system w/ PIIXn enabled on 2.4.0-test8, BP6 MB. If you need another system/person/datapoint to help narrow down the variables I can supply whatever info you may need or try various patches. Martin - 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: ISAPNP using an invalid IRQ, 2.4.0-test7
Jaroslav Kysela wrote: > > On Tue, 29 Aug 2000, M.H.VanLeeuwen wrote: > > > With default BIOS settings, IRQ 5 is unavailable for ISA yet > > it is being assigned by the ne.c driver and NFS root system > > doesn't finish booting. > > > > Is this a driver problem or a ISAPNP problem? > > It is general IRQ manager problem. ISA PnP code cannot determine which > interrupts cannot be used. I think that we need some next layer between > IO APIC control code and Plug & Play routines to exchange this information > to prevent allocation of a free but unuseable IRQ for ISA PnP devices. > > Jaroslav Kind of what I figured, too bad Linux 2.4 PNP is akin to Plug'N Pray (trademark MS ;)). It seems as though 2.4 is taking a step backwards since the same system/bios setup worked just fine on 2.2 with userland PNP utilities. Making PNP work for more cases would sure be nice. Do you know of anyone actively working to make the above kernel adjustments? Can it be done relatively easily? Martin - 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: ISAPNP using an invalid IRQ, 2.4.0-test7
Jaroslav Kysela wrote: On Tue, 29 Aug 2000, M.H.VanLeeuwen wrote: With default BIOS settings, IRQ 5 is unavailable for ISA yet it is being assigned by the ne.c driver and NFS root system doesn't finish booting. Is this a driver problem or a ISAPNP problem? It is general IRQ manager problem. ISA PnP code cannot determine which interrupts cannot be used. I think that we need some next layer between IO APIC control code and Plug Play routines to exchange this information to prevent allocation of a free but unuseable IRQ for ISA PnP devices. Jaroslav Kind of what I figured, too bad Linux 2.4 PNP is akin to Plug'N Pray (trademark MS ;)). It seems as though 2.4 is taking a step backwards since the same system/bios setup worked just fine on 2.2 with userland PNP utilities. Making PNP work for more cases would sure be nice. Do you know of anyone actively working to make the above kernel adjustments? Can it be done relatively easily? Martin - 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/
