Re: Problem with SMC Etherpower II + kernel newer 2.4.2
On Mon, 2 Jul 2001, Juergen Wolf wrote: > currently I experience some strange problems with every kernels newer > than 2.4.2 and my SMC Etherpower II network card. While running such a > kernel, the network hangs and I get lots of errors like these listed > below: under the dumb question department: a) bad cable? b) not negotiating speed and duplex with the switch correctly? c) bad card? d) IRQ sharing causing a conflict? I'm less predisposed to blame the card in general or the driver, as I have probably about a dozen SMC epic100 cards here, in single processor x86, dual x86, and dual alphas that have been flawless from about 2.2.14 to 2.4.4. - 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: Problem with SMC Etherpower II + kernel newer 2.4.2
On Mon, 2 Jul 2001, Juergen Wolf wrote: currently I experience some strange problems with every kernels newer than 2.4.2 and my SMC Etherpower II network card. While running such a kernel, the network hangs and I get lots of errors like these listed below: under the dumb question department: a) bad cable? b) not negotiating speed and duplex with the switch correctly? c) bad card? d) IRQ sharing causing a conflict? I'm less predisposed to blame the card in general or the driver, as I have probably about a dozen SMC epic100 cards here, in single processor x86, dual x86, and dual alphas that have been flawless from about 2.2.14 to 2.4.4. - 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: EEPro100 problems in SMP on 2.4.5 ?
On Sat, 30 Jun 2001, Dylan Griffiths wrote: > I'd love to do some of this, but since the box is now being shipped to a > colo facility in New York, I don't really have a choice in the matter. > > Hopefully someone here doing SMP + EEPro100 can see if they can reproduce > the issue (2.4.5 kernel). I've had issues with the Intel cards, as well. What revision of the card is it? Have you tried the drivers available from Intel, to see if they do a better job? In my case, they didn't. I've also had reports, for a linux-2.2.x kernel, that sometimes its guesswork as to whether stock kernel eepro100, the intel e100 driver, or Don Becker's eepro100 will work on the beasts. HTH. - 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: EEPro100 problems in SMP on 2.4.5 ?
On Sat, 30 Jun 2001, Dylan Griffiths wrote: I'd love to do some of this, but since the box is now being shipped to a colo facility in New York, I don't really have a choice in the matter. Hopefully someone here doing SMP + EEPro100 can see if they can reproduce the issue (2.4.5 kernel). I've had issues with the Intel cards, as well. What revision of the card is it? Have you tried the drivers available from Intel, to see if they do a better job? In my case, they didn't. I've also had reports, for a linux-2.2.x kernel, that sometimes its guesswork as to whether stock kernel eepro100, the intel e100 driver, or Don Becker's eepro100 will work on the beasts. HTH. - 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/
problems with aic7xxx driver 6.1.11 (fwd)
-- Forwarded message -- Date: Mon, 25 Jun 2001 11:31:32 -0400 (EDT) From: John Jasen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Dima Meschaninov <[EMAIL PROTECTED]> Subject: problems with aic7xxx driver 6.1.11 #1) It seems that the new aic7xxx drivers do not detect raid controllers, et al on the bus, as we have an nStor NexStor 8le that is completely invisible to your driver. #2) There seem to be a few problems with the new driver, where it can easily get confused into a reset loop. (see below for a rough description) -- Forwarded message -- Date: Mon, 25 Jun 2001 11:20:08 -0400 From: Dmitry Meshchaninov <[EMAIL PROTECTED]> To: John Jasen <[EMAIL PROTECTED]> Subject: Description of SCSI situation on zathras Looks like we have had power down at night. Afterwards, the scsi tray was in a strange state - the system BIOS didn't find anything on the bus, and naturally the linux driver didn't either. After we power cycled scsi tray and rebooted the system, the system BIOS detected all the scsi devices but the linux driver still was blind. It said something about timeouts during lun probing and marked all the devicess offline, and we tried it via reboot/powercycle of the system at least 2-3 times. After we setup the old driver everything went fine. - 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/
a couple of NICs that don't NIC
In these cases, both network interface cards fall over under moderate to heavy traffic. 1) 01:05.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) kernels: 2.2.19 and 2.4.4 drivers used: kernel eepro100 (2.2.19 and 2.4.4) and intel e100 (2.4.4) symptoms: the system would spontaneously reboot under heavy NFS traffic, with no console or /var/log/messages reports. This could be reliably reproduced by mounting an exported directory, and looping "find /mounted/directory -depth -print | xargs cat >/dev/null" 2) SMC EZNET 10/100 nic, using a realtek chipset kernels: 2.4.4 drivers used: kernel 8139too symptoms: the system would hang under heavy network traffic, and need to be powercycled backed to life. ping -f could cause it, as could the test above. Nothing of interest to report via console or syslog. I've currently replaced these cards with the Netgear FA310 series, using the tulip driver (01:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)) and have had no problems, so being able to help in testing would probably be more difficult. - 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/
a couple of NICs that don't NIC
In these cases, both network interface cards fall over under moderate to heavy traffic. 1) 01:05.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) kernels: 2.2.19 and 2.4.4 drivers used: kernel eepro100 (2.2.19 and 2.4.4) and intel e100 (2.4.4) symptoms: the system would spontaneously reboot under heavy NFS traffic, with no console or /var/log/messages reports. This could be reliably reproduced by mounting an exported directory, and looping find /mounted/directory -depth -print | xargs cat /dev/null 2) SMC EZNET 10/100 nic, using a realtek chipset kernels: 2.4.4 drivers used: kernel 8139too symptoms: the system would hang under heavy network traffic, and need to be powercycled backed to life. ping -f could cause it, as could the test above. Nothing of interest to report via console or syslog. I've currently replaced these cards with the Netgear FA310 series, using the tulip driver (01:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)) and have had no problems, so being able to help in testing would probably be more difficult. - 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/
problems with aic7xxx driver 6.1.11 (fwd)
-- Forwarded message -- Date: Mon, 25 Jun 2001 11:31:32 -0400 (EDT) From: John Jasen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Dima Meschaninov [EMAIL PROTECTED] Subject: problems with aic7xxx driver 6.1.11 #1) It seems that the new aic7xxx drivers do not detect raid controllers, et al on the bus, as we have an nStor NexStor 8le that is completely invisible to your driver. #2) There seem to be a few problems with the new driver, where it can easily get confused into a reset loop. (see below for a rough description) -- Forwarded message -- Date: Mon, 25 Jun 2001 11:20:08 -0400 From: Dmitry Meshchaninov [EMAIL PROTECTED] To: John Jasen [EMAIL PROTECTED] Subject: Description of SCSI situation on zathras Looks like we have had power down at night. Afterwards, the scsi tray was in a strange state - the system BIOS didn't find anything on the bus, and naturally the linux driver didn't either. After we power cycled scsi tray and rebooted the system, the system BIOS detected all the scsi devices but the linux driver still was blind. It said something about timeouts during lun probing and marked all the devicess offline, and we tried it via reboot/powercycle of the system at least 2-3 times. After we setup the old driver everything went fine. - 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: is rhl on kernel 2.4?
On Fri, 20 Apr 2001, Xiong Zhao wrote: > fredhat-list red hat linux 7.1 on kernel 2.4?which release?2.4.2 or 2.4.3? > i'v downloaded and compiled a 2.4.3 kernel.i found the version > of header file package is 2.4.0 using rpm -qa|grep kernel.is this > right?where can get linux on 2.4 kernel? > thanks in advance. 2.4.2-ac3, with about a 120 patches to it. If you're really interested, I'll email you the spec file. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: is rhl on kernel 2.4?
On Fri, 20 Apr 2001, Xiong Zhao wrote: fredhat-list red hat linux 7.1 on kernel 2.4?which release?2.4.2 or 2.4.3? i'v downloaded and compiled a 2.4.3 kernel.i found the version of header file package is 2.4.0 using rpm -qa|grep kernel.is this right?where can get linux on 2.4 kernel? thanks in advance. 2.4.2-ac3, with about a 120 patches to it. If you're really interested, I'll email you the spec file. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Your response is requested
On Tue, 17 Apr 2001, Disconnect wrote: > (Sending to LKML just so nobody else flips out) > > OK it wasn't just us. Lemme reassure the admins I just forwarded it to ;) > > It seems to list the hostname of whoever receives it (neat trick). sendmail, by default, appends its domainname to incoming email that doesn't have one. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Your response is requested
On Tue, 17 Apr 2001, Disconnect wrote: (Sending to LKML just so nobody else flips out) OK it wasn't just us. Lemme reassure the admins I just forwarded it to ;) It seems to list the hostname of whoever receives it (neat trick). sendmail, by default, appends its domainname to incoming email that doesn't have one. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Still cannot compile, 2.4.3-ac6
On Sun, 15 Apr 2001, Marko Kreen wrote: > Sorry. Who said it should not be tested? How else it could get > 'default compiler'? If the gcc-3.0 would start giving errors > on some old code then it could be gcc bug. But this rwsem code > is couple of days old. It is good to let it through stricter > error checking, I guess. This rwsem is very in-flux code. eg. > 2.4.4-pre2 did not compile. ac[56] with um-arch do not compile. For what its worth, I got the same error on 2.4.3-ac5, using gcc 2.91.66. I did seem messages fly by in on the list about a few in -ac5, but haven't gone back to dig them out. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Still cannot compile, 2.4.3-ac6
On Sun, 15 Apr 2001, Marko Kreen wrote: Sorry. Who said it should not be tested? How else it could get 'default compiler'? If the gcc-3.0 would start giving errors on some old code then it could be gcc bug. But this rwsem code is couple of days old. It is good to let it through stricter error checking, I guess. This rwsem is very in-flux code. eg. 2.4.4-pre2 did not compile. ac[56] with um-arch do not compile. For what its worth, I got the same error on 2.4.3-ac5, using gcc 2.91.66. I did seem messages fly by in on the list about a few in -ac5, but haven't gone back to dig them out. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: memory usage - continued - iCache/Dentry cacheing bug???
On Wed, 11 Apr 2001, Marcin Kowalski wrote: > I then do a swapoff /dev/sda3 (250mb used), this completely locks the machine > for 50 seconds and pushes the load to 31 when I can log back in. Then > micraculously I am using only 170mb of physical ram. I turn swap back on and > all is well > Can anyone please explain this odd behaviour.. ??? > Below is a free after this whole debacle..::: another cute way of clearing memory is to do a: dd if=/dev/hda of=/dev/null bs= count=1 this will push some stuff into swap; but ... - 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: 2.4.3 compile error No 4
On Wed, 11 Apr 2001, info wrote: > > this may be a stupid question, but are you doing a 'make clean' after > > changing config parameters? > > Maybe it's is a stupid order, but I do this: > 1. untar kernel into /usr/src (there was no /linux subdirectory) > 2. copy my own config file (named config-k6) from old 2.4.0 source > tree (compiled and working - now I am on 2.4.0) > 3. make xconfig, load configuration from this file and then manually > check all parameters > 4 store configuration into new config-k6-1 file > 5. press button "Save and exit" why not copy it over to .config, 'make oldconfig', then pop into your favourite configuration editor and make changes, making sure to save them on exit? then do a 'make clean; make dep; make' - 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: 2.4.3 compile error No 4
On Wed, 11 Apr 2001, info wrote: > OS: Mandrake 6.0RE > AMD K6-200 144 M > gcc 2.95.2-ipl3mdk > > # CONFIG_IPX_INTERN is not set > # CONFIG_SYSCTL is not set > CONFIG_HPFS_FS=y > > Compiler error message No 4: this may be a stupid question, but are you doing a 'make clean' after changing config parameters? - 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: 2.4.3 compile error No 4
On Wed, 11 Apr 2001, info wrote: OS: Mandrake 6.0RE AMD K6-200 144 M gcc 2.95.2-ipl3mdk # CONFIG_IPX_INTERN is not set # CONFIG_SYSCTL is not set CONFIG_HPFS_FS=y Compiler error message No 4: this may be a stupid question, but are you doing a 'make clean' after changing config parameters? - 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: 2.4.3 compile error No 4
On Wed, 11 Apr 2001, info wrote: this may be a stupid question, but are you doing a 'make clean' after changing config parameters? Maybe it's is a stupid order, but I do this: 1. untar kernel into /usr/src (there was no /linux subdirectory) 2. copy my own config file (named config-k6) from old 2.4.0 source tree (compiled and working - now I am on 2.4.0) 3. make xconfig, load configuration from this file and then manually check all parameters 4 store configuration into new config-k6-1 file 5. press button "Save and exit" why not copy it over to .config, 'make oldconfig', then pop into your favourite configuration editor and make changes, making sure to save them on exit? then do a 'make clean; make dep; make' - 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: memory usage - continued - iCache/Dentry cacheing bug???
On Wed, 11 Apr 2001, Marcin Kowalski wrote: I then do a swapoff /dev/sda3 (250mb used), this completely locks the machine for 50 seconds and pushes the load to 31 when I can log back in. Then micraculously I am using only 170mb of physical ram. I turn swap back on and all is well Can anyone please explain this odd behaviour.. ??? Below is a free after this whole debacle..::: another cute way of clearing memory is to do a: dd if=/dev/hda of=/dev/null bs=total memory count=1 this will push some stuff into swap; but ... - 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: kernel bug in 2.4.2-ac28, patched with 6.1.8 aic drivers
On Thu, 5 Apr 2001, John Jasen wrote: > got this on booting up 2.4.2-ac28: > Apr 5 09:36:37 grim kernel: kernel BUG at slab.c:1244! > Apr 5 09:36:37 grim kernel: invalid operand: errr ... belay that one. a) I said I didn't get it in 2.4.3-ac3, which was only about 30% correct. (I've gotten it 7 out of 9 times, since then). and b) it occured on a 2.4.2-ac28 tree without the aic7xxx driver update (which shouldn'tve mattered anyway, in theory) and c) It happened right after webmin (don't ask!) started, and just for giggles, I shut off webmin, rebooted, and -- no more problem. *shrug* -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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/
kernel bug in 2.4.2-ac28, patched with 6.1.8 aic drivers
got this on booting up 2.4.2-ac28: Apr 5 09:36:37 grim kernel: kernel BUG at slab.c:1244! Apr 5 09:36:37 grim kernel: invalid operand: Apr 5 09:36:37 grim kernel: CPU:0 Apr 5 09:36:37 grim kernel: EIP:0010:[kmalloc+303/472] Apr 5 09:36:37 grim kernel: EFLAGS: 00010086 Apr 5 09:36:37 grim kernel: eax: 001b ebx: c1447768 ecx: c02900a0 edx: 16ea Apr 5 09:36:37 grim kernel: esi: cea5a000 edi: cea5a9aa ebp: 00012800 esp: cf27de30 Apr 5 09:36:37 grim kernel: ds: 0018 es: 0018 ss: 0018 Apr 5 09:36:37 grim kernel: Process mingetty (pid: 672, stackpage=cf27d000) Apr 5 09:36:37 grim kernel: Stack: c023a56b 04dc c02ffae0 0403 0403 cea5a000 1000 Apr 5 09:36:37 grim kernel:0015 0246 c01b1dfe 0c3c 0007 c02ffae0 0403 c01b2a6a Apr 5 09:36:37 grim kernel: cf011a30 cff0de74 0001 cf27dee8 c0291080 cf27c000 Apr 5 09:36:37 grim kernel: Call Trace: [alloc_tty_struct+14/40] [init_dev+138/1088] [tty_open+475/944] [cached_l ookup+16/84] [get_chrfops+106/232] [permission+43/48] [chrdev_open+64/76] Apr 5 09:36:37 grim kernel:[dentry_open+198/336] [filp_open+82/92] [sys_open+56/180] [system_call+51/56] Apr 5 09:36:37 grim kernel: Apr 5 09:36:37 grim kernel: Code: 0f 0b 83 c4 08 8b 6b 10 f7 c5 00 04 00 00 74 53 b8 a5 c2 0f Console was half dead -- got the login prompt, but a whole lot of nothing afterwards, but I was able to SysRQ-sync and reboot into another kernel. This problem does not appear in 2.4.3-ac3, FWIW. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: kernel bug in 2.4.2-ac28, patched with 6.1.8 aic drivers
On Thu, 5 Apr 2001, John Jasen wrote: got this on booting up 2.4.2-ac28: Apr 5 09:36:37 grim kernel: kernel BUG at slab.c:1244! Apr 5 09:36:37 grim kernel: invalid operand: errr ... belay that one. a) I said I didn't get it in 2.4.3-ac3, which was only about 30% correct. (I've gotten it 7 out of 9 times, since then). and b) it occured on a 2.4.2-ac28 tree without the aic7xxx driver update (which shouldn'tve mattered anyway, in theory) and c) It happened right after webmin (don't ask!) started, and just for giggles, I shut off webmin, rebooted, and -- no more problem. *shrug* -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: 2.4.3 freeze under heavy writing + open rxvt
On Tue, 3 Apr 2001, Simon Kirby wrote: > Three times now I've had 2.4.3 freeze on my dual CPU box while doing a > "dd if=/dev/zero of=/dev/hdc bs=1024k" (a drive to be RMA'd :)). I got > bored and opened an rxvt, and as the machine was swapping in (I assume), > everything froze. The mouse still moved for about 5 seconds before the > freeze, and the window was visible as it was attempting to start tcsh. > > I'm guessing that what's happening is something is waiting on a lock and > blocking interrupts (?) for five seconds while it is swapping in, and the > NMI lockup detector is kicking in and really breaking it. I've noticed the same thing. I was doing a rather sadistic test, checking a memory chip. one window: make -j in 2.4.2 src; and in another, dd if=/dev/hda of=/dev/null bs=4096k. The third window was running top, and froze. A fourth window wouldn't get past login: -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Bugreport: Kernel 2.4.x crash
On Tue, 3 Apr 2001, [iso-8859-1] Jörn Engel wrote: I don't necessarily believe its the hpt366, as you do. See below: (note: I've also had it running on a stock 2.4.2 kernel for a while) > 00:08.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366 > (rev 01) > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 248 (2000ns min, 2000ns max), cache line size 08 > Interrupt: pin A routed to IRQ 11 > Region 0: I/O ports at 6100 > Region 1: I/O ports at 6200 > Region 4: I/O ports at 6300 > > 00:08.1 Unknown mass storage controller: Triones Technologies, Inc. HPT366 > (rev 01) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 248 (2000ns min, 2000ns max), cache line size 08 > Interrupt: pin A routed to IRQ 11 > Region 0: I/O ports at 6400 > Region 1: I/O ports at 6500 > Region 4: I/O ports at 6600 00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366 (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bugreport: Kernel 2.4.x crash
On Tue, 3 Apr 2001, [iso-8859-1] Jörn Engel wrote: I don't necessarily believe its the hpt366, as you do. See below: (note: I've also had it running on a stock 2.4.2 kernel for a while) 00:08.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366 (rev 01) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 248 (2000ns min, 2000ns max), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at 6100 Region 1: I/O ports at 6200 Region 4: I/O ports at 6300 00:08.1 Unknown mass storage controller: Triones Technologies, Inc. HPT366 (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 248 (2000ns min, 2000ns max), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at 6400 Region 1: I/O ports at 6500 Region 4: I/O ports at 6600 00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366 (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 8 min, 8 max, 120 set, cache line size 08 Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at ac00 [size=8] Region 1: I/O ports at b000 [size=4] Region 4: I/O ports at b400 [size=256] Expansion ROM at ea00 [disabled] [size=128K] 00:13.1 Unknown mass storage controller: Triones Technologies, Inc. HPT366 (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 8 min, 8 max, 120 set, cache line size 08 Interrupt: pin B routed to IRQ 10 Region 0: I/O ports at b800 [size=8] Region 1: I/O ports at bc00 [size=4] Region 4: I/O ports at c000 [size=256] [root@geisha /root]# uptime 10:25am up 8 days, 21:17, 9 users, load average: 0.00, 0.00, 0.00 [root@geisha /root]# uname -a Linux geisha 2.4.2-ac20 #6 SMP Sat Mar 24 23:40:02 EST 2001 i686 unknown -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: 2.4.3 freeze under heavy writing + open rxvt
On Tue, 3 Apr 2001, Simon Kirby wrote: Three times now I've had 2.4.3 freeze on my dual CPU box while doing a "dd if=/dev/zero of=/dev/hdc bs=1024k" (a drive to be RMA'd :)). I got bored and opened an rxvt, and as the machine was swapping in (I assume), everything froze. The mouse still moved for about 5 seconds before the freeze, and the window was visible as it was attempting to start tcsh. I'm guessing that what's happening is something is waiting on a lock and blocking interrupts (?) for five seconds while it is swapping in, and the NMI lockup detector is kicking in and really breaking it. I've noticed the same thing. I was doing a rather sadistic test, checking a memory chip. one window: make -j in 2.4.2 src; and in another, dd if=/dev/hda of=/dev/null bs=4096k. The third window was running top, and froze. A fourth window wouldn't get past login: -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: New directions for kernel development
On Sun, 1 Apr 2001, Linus Torvalds wrote: > Hi all, > > Recently, I've been thinking a lot about where Linux development should > head now that 2.4 is out. Specifically, I've been thinking about how we > ought to make some cultural changes as well as technical changes. Now I'm > not *entirely* sure what directions we should head in as we move towards > 3.0, but I'd like to point out a few areas that need to be addressed as well > as propose some possible solutions. Nothing is set in stone yet, but these > are definitely issues we need to work on. I see you've made no mention of the $17,000,000,000.00 check that you've gotten from MicroSoft, in order to 'further develop' the Linux kernel? -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: New directions for kernel development
On Sun, 1 Apr 2001, Linus Torvalds wrote: Hi all, Recently, I've been thinking a lot about where Linux development should head now that 2.4 is out. Specifically, I've been thinking about how we ought to make some cultural changes as well as technical changes. Now I'm not *entirely* sure what directions we should head in as we move towards 3.0, but I'd like to point out a few areas that need to be addressed as well as propose some possible solutions. Nothing is set in stone yet, but these are definitely issues we need to work on. I see you've made no mention of the $17,000,000,000.00 check that you've gotten from MicroSoft, in order to 'further develop' the Linux kernel? check the date, dudes -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Bug in the file attributes ?
On Thu, 29 Mar 2001, Xavier Ordoquy wrote: > OK, thanks for the answer. > I've spoken to a few people before and they hadn't heard about it. > Since once upon the time on a solaris system I've had a root file that I > couldn't remove even if I hold the rights of the directory. > This is why I figured out this was a bug. > Anyway, thanks for that. I think, I could very easily be mistaken, tho', that being able to do this is part of posix compliance. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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 connectivity trashed.
On Thu, 29 Mar 2001, Richard B. Johnson wrote: >snipped< First mistake: your security administrator relied on the firewall for protection. It is an _aid_ to security; not the 'be all and end all'. IOW, the hosts weren't hardened to resist penetration in case the firewall didn't cover it. Second mistake: your security administrator didn't make known the changes taking place, so that clueful users could have taken some preventative steps on their UNIX boxes. Third mistake: your security administrator either didn't know about; didn't care about; or didn't act on security problems for linux and solaris -- which have been posted, discussed, and addressed on many general or OS-specific security lists. Fourth mistake: your security administrator, rather than address the problems, is sticking his head in the sand and mumbling 'Windows' -- which, as an OS, is a christmas tree where every bauble says 'please hack me!'. In short, your security administrator needs to be dragged out, shot, and left hanging by the front door as a warning to his replacement. Or, at least fired. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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 connectivity trashed.
On Thu, 29 Mar 2001, Richard B. Johnson wrote: snipped First mistake: your security administrator relied on the firewall for protection. It is an _aid_ to security; not the 'be all and end all'. IOW, the hosts weren't hardened to resist penetration in case the firewall didn't cover it. Second mistake: your security administrator didn't make known the changes taking place, so that clueful users could have taken some preventative steps on their UNIX boxes. Third mistake: your security administrator either didn't know about; didn't care about; or didn't act on security problems for linux and solaris -- which have been posted, discussed, and addressed on many general or OS-specific security lists. Fourth mistake: your security administrator, rather than address the problems, is sticking his head in the sand and mumbling 'Windows' -- which, as an OS, is a christmas tree where every bauble says 'please hack me!'. In short, your security administrator needs to be dragged out, shot, and left hanging by the front door as a warning to his replacement. Or, at least fired. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Bug in the file attributes ?
On Thu, 29 Mar 2001, Xavier Ordoquy wrote: OK, thanks for the answer. I've spoken to a few people before and they hadn't heard about it. Since once upon the time on a solaris system I've had a root file that I couldn't remove even if I hold the rights of the directory. This is why I figured out this was a bug. Anyway, thanks for that. I think, I could very easily be mistaken, tho', that being able to do this is part of posix compliance. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Can't find modules after moving to 2.4.2
On Wed, 28 Mar 2001, Marcus Ramos wrote: > I've moved from kernel 2.2.16 to 2.4.2 (RH7) and its boots OK, except > for the fact that none of the modules in "/etc/modules.conf" are loaded > anymore (although modules were enabled in kernel config). In upgrade modutils. current is 2.4.5 -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Can't find modules after moving to 2.4.2
On Wed, 28 Mar 2001, Marcus Ramos wrote: I've moved from kernel 2.2.16 to 2.4.2 (RH7) and its boots OK, except for the fact that none of the modules in "/etc/modules.conf" are loaded anymore (although modules were enabled in kernel config). In upgrade modutils. current is 2.4.5 -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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/
offtopic Re: Linux Worm (fwd)
On Mon, 26 Mar 2001, Bob_Tracy wrote: > So let's quit covering for 'em. Let's have the name(s) behind that > idiotic policy letter, because I would not knowingly allow any company > I work for to hire such people. In this case, the person(s) making the policy seem to be short on clue, and long on agenda. However, I can understand and agree with, from a security perspective, a company deciding to ditch OSes that they have little to no idea about how to handle. I've been in the position to suggest that very action to companies, as their $VENDOR-OS box sits in the corner and decays quietly, because everyone either ignores it while its working, or kicks it into 'submission' when something goes wrong ... Yeah, the _solution_ is to have IT people with lots of clue, but, well ... *cough* ... -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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/
offtopic Re: Linux Worm (fwd)
On Mon, 26 Mar 2001, Bob_Tracy wrote: So let's quit covering for 'em. Let's have the name(s) behind that idiotic policy letter, because I would not knowingly allow any company I work for to hire such people. In this case, the person(s) making the policy seem to be short on clue, and long on agenda. However, I can understand and agree with, from a security perspective, a company deciding to ditch OSes that they have little to no idea about how to handle. I've been in the position to suggest that very action to companies, as their $VENDOR-OS box sits in the corner and decays quietly, because everyone either ignores it while its working, or kicks it into 'submission' when something goes wrong ... Yeah, the _solution_ is to have IT people with lots of clue, but, well ... *cough* ... -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Mounting ISO via Loop Devices
On 20 Mar 2001, Eugene Crosser wrote: > I can confirm that mount over loopback hangs on 2.4.2 (from kernel.org), > regardless of the filesystem type. It seems to have gone away in the 2.4.2-acX series. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Mounting ISO via Loop Devices
On 20 Mar 2001, Eugene Crosser wrote: I can confirm that mount over loopback hangs on 2.4.2 (from kernel.org), regardless of the filesystem type. It seems to have gone away in the 2.4.2-acX series. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: [OT] how to catch HW fault
On Sat, 17 Mar 2001, Aaron Lunansky wrote: > It could very well be your ram (I don't suspect the cpu). If you can, try a > different stick of ram. I've found a good exercise for exercising memory faults is to recompile the kernel with a -j16 flag; and in a second virtual console, do something like dd if=/dev/hda of=/dev/null bs=2048k Either the kernel compile will fail with a sig11, or the dd will fail and lock the system, in my experience. I've used this method, crudely, to chase down memory problems in systems using 256-512MB ram. YMMV. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: [OT] how to catch HW fault
On Sat, 17 Mar 2001, Aaron Lunansky wrote: It could very well be your ram (I don't suspect the cpu). If you can, try a different stick of ram. I've found a good exercise for exercising memory faults is to recompile the kernel with a -j16 flag; and in a second virtual console, do something like dd if=/dev/hda of=/dev/null bs=2048k Either the kernel compile will fail with a sig11, or the dd will fail and lock the system, in my experience. I've used this method, crudely, to chase down memory problems in systems using 256-512MB ram. YMMV. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: devfs vs. devpts
On 16 Mar 2001, Ian Soboroff wrote: > i don't have devpts mounted under 2.4.2 (debian checks whether you > have devfs before mounting devpts), so i tried building my kernel with > Unix 98 pty support but without the devpts filesystem. i get the > following error at the very end of 'make bzImage': snipped from .config: # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # File systems # CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y CONFIG_DEVFS_DEBUG=y ... # CONFIG_DEVPTS_FS is not set from my /etc/devfsd.conf, I have: REGISTERpts/.* MKOLDCOMPAT UNREGISTER pts/.* RMOLDCOMPAT and for permissions: REGISTERpts/.* IGNORE uname -a: Linux grim 2.4.2-ac18 #3 SMP Mon Mar 12 12:05:18 EST 2001 i686 unknown -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: devfs vs. devpts
On 16 Mar 2001, Ian Soboroff wrote: i don't have devpts mounted under 2.4.2 (debian checks whether you have devfs before mounting devpts), so i tried building my kernel with Unix 98 pty support but without the devpts filesystem. i get the following error at the very end of 'make bzImage': snipped from .config: # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # File systems # CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y CONFIG_DEVFS_DEBUG=y ... # CONFIG_DEVPTS_FS is not set from my /etc/devfsd.conf, I have: REGISTERpts/.* MKOLDCOMPAT UNREGISTER pts/.* RMOLDCOMPAT and for permissions: REGISTERpts/.* IGNORE uname -a: Linux grim 2.4.2-ac18 #3 SMP Mon Mar 12 12:05:18 EST 2001 i686 unknown -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Kernel 2.4.2
On Thu, 15 Mar 2001, Ted Gervais wrote: > Anyways - to get things to work, I have put added this statement to the > top of my /etc/rc.d/rc.inet1 file: > > insmod /usr/src/linux/drivers/net/8139too.o. install a later version of modutils, as the /lib/modules directory tree has changed between 2.2.x and 2.4.x - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Richard B. Johnson wrote: > This used to even be the way disks were located by the kernel > drivers. Now, these are found in some "random" order. > > If whatever is causing the "random" order was fixed, put back like > it used to be, etc., we wouldn't have these problems. Another alternative to path2inst or a database, I suppose, would be to use bus/pci slot information (like in /proc/pci?) to order multiple devices, so at least there's some consistency. You might have a serious headache, however, when adding a device, under that scheme. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Richard B. Johnson wrote: This used to even be the way disks were located by the kernel drivers. Now, these are found in some "random" order. If whatever is causing the "random" order was fixed, put back like it used to be, etc., we wouldn't have these problems. Another alternative to path2inst or a database, I suppose, would be to use bus/pci slot information (like in /proc/pci?) to order multiple devices, so at least there's some consistency. You might have a serious headache, however, when adding a device, under that scheme. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Kernel 2.4.2
On Thu, 15 Mar 2001, Ted Gervais wrote: Anyways - to get things to work, I have put added this statement to the top of my /etc/rc.d/rc.inet1 file: insmod /usr/src/linux/drivers/net/8139too.o. install a later version of modutils, as the /lib/modules directory tree has changed between 2.2.x and 2.4.x - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Christoph Hellwig wrote: > In article <[EMAIL PROTECTED]> you >wrote: > > > The problem: > > > drivers change their detection schemes; and changes in the kernel can > > change the order in which devices are assigned names. > > > > For example, the DAC960(?) drivers changed their order of > > detecting controllers, and I did _not_ have fun, given that the machine in > > question had about 40 disks to deal with, spread across two controllers. > > Put LABEL= in you fstab in place of the device name. It solves the example, but not necessarily the problem. We're still left with partitions that don't do labels, attached tape devices, scsi controllers, NICs, and so forth. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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/
magic device renumbering was -- Re: Linux 2.4.2ac20
The problem: drivers change their detection schemes; and changes in the kernel can change the order in which devices are assigned names. For example, the DAC960(?) drivers changed their order of detecting controllers, and I did _not_ have fun, given that the machine in question had about 40 disks to deal with, spread across two controllers. This can create a lot of problems for people upgrading large, production quality systems -- as, in the worst case, the system won't complete the boot cycle; or in middle cases, the user/sysadmin is stuck rewriting X amount of files and trying again; or in small cases, you find out that your SMC and Intel ethernet cards are reversed, and have to go fix things ... Possible solutions(?): Solaris uses an /etc/path_to_inst file, to keep track of device ordering, et al. Maybe we should consider something similar, where a physical device to logical device map is kept and used to keep things consistent on kernel/driver changes; device addition/removal, and so forth ... I am, of course, open to better solutions. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Christoph Hellwig wrote: In article [EMAIL PROTECTED] you wrote: The problem: drivers change their detection schemes; and changes in the kernel can change the order in which devices are assigned names. For example, the DAC960(?) drivers changed their order of detecting controllers, and I did _not_ have fun, given that the machine in question had about 40 disks to deal with, spread across two controllers. Put LABEL=label set with e2label in you fstab in place of the device name. It solves the example, but not necessarily the problem. We're still left with partitions that don't do labels, attached tape devices, scsi controllers, NICs, and so forth. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: [Slightly OT] x86 PROM project
On Sun, 4 Mar 2001, Erik Mouw wrote: > Have a look at OpenBIOS: > > http://www.freiburg.linux.de/OpenBIOS/ > > The project wants to create an IEEE 1275-1994 compliant firmware, like > used by SUN (for example). I'd like to see something like SRM; but with better support. (SRM is the 'BIOS' for alphas, BTW). - 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: [Slightly OT] x86 PROM project
On Sun, 4 Mar 2001, Erik Mouw wrote: Have a look at OpenBIOS: http://www.freiburg.linux.de/OpenBIOS/ The project wants to create an IEEE 1275-1994 compliant firmware, like used by SUN (for example). I'd like to see something like SRM; but with better support. (SRM is the 'BIOS' for alphas, BTW). - 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: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
On Thu, 15 Feb 2001, Michal Jaegermann wrote: > Like I wrote - I did not get to locks on fsck but then stuff was weird > and if I would press sufficiently long maybe I would. I still had some > use for my file systems so I did not try hard enough. Maybe we need > black hens on the top of the magic quoted above? You bring the black hens, I've got the goats, red silk ribbon, and candles ... > > I don't care about X on this system, all that much, honestly. > > "Technicolor" thingy seems to be side effect of your particular > graphics card, no? I gotta think that something Very Bad (tm) is happening at kernel level, like something getting overrun in the IDE subsystem, and overwriting into other areas of memory. *shrug* -- John - 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: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
On Thu, 15 Feb 2001, Michal Jaegermann wrote:
> > Well, the situation is improving, I suppose ...
> >
> > Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
> > the system to go technicolor and lock up.
>
> On UP1100 which I have here somehow this looks a bit different _after_
> I put on it the latest SRM and used this "magic incantation" from
> Hyung Min SEO ('d -l 801feac d' at SRM prompt to modify firmware).
> I copied from disk to disk directory tries with some 150 MB of data
> in these and no ill effects.
I retried the mysticism and incantations (d -l 801feac d) at the srm
prompt, and the machine locked on fsck, under kernel 2.4.1-ac13.
I don't care about X on this system, all that much, honestly.
-- John
-
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: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
Well, the situation is improving, I suppose ... Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause the system to go technicolor and lock up. Now, under 2.4.1-ac13, at about 11000 blocks, it goes technicolor, but doesn't lock up until somewhere between 13000 and 2. *wry shrug* - 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: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
Well, the situation is improving, I suppose ... Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause the system to go technicolor and lock up. Now, under 2.4.1-ac13, at about 11000 blocks, it goes technicolor, but doesn't lock up until somewhere between 13000 and 2. *wry shrug* - 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: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
On Thu, 15 Feb 2001, Michal Jaegermann wrote:
Well, the situation is improving, I suppose ...
Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
the system to go technicolor and lock up.
On UP1100 which I have here somehow this looks a bit different _after_
I put on it the latest SRM and used this "magic incantation" from
Hyung Min SEO ('d -l 801feac d' at SRM prompt to modify firmware).
I copied from disk to disk directory tries with some 150 MB of data
in these and no ill effects.
I retried the mysticism and incantations (d -l 801feac d) at the srm
prompt, and the machine locked on fsck, under kernel 2.4.1-ac13.
I don't care about X on this system, all that much, honestly.
-- John
-
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: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
On Thu, 15 Feb 2001, Michal Jaegermann wrote: Like I wrote - I did not get to locks on fsck but then stuff was weird and if I would press sufficiently long maybe I would. I still had some use for my file systems so I did not try hard enough. Maybe we need black hens on the top of the magic quoted above? You bring the black hens, I've got the goats, red silk ribbon, and candles ... I don't care about X on this system, all that much, honestly. "Technicolor" thingy seems to be side effect of your particular graphics card, no? I gotta think that something Very Bad (tm) is happening at kernel level, like something getting overrun in the IDE subsystem, and overwriting into other areas of memory. *shrug* -- John - 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: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
On Thu, 1 Feb 2001, Andre Hedrick wrote: > Sorry, but the ALI code was written based upon ix86 :-( > Where were you guys during 2.3.X development? We had lots of problems with the few 2.3.x kernels we downloaded; and R effort was needed elsewhere. Would it help if a UP1100 was somehow made available for testing/development? -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
On Thu, 1 Feb 2001, Andre Hedrick wrote: Sorry, but the ALI code was written based upon ix86 :-( Where were you guys during 2.3.X development? We had lots of problems with the few 2.3.x kernels we downloaded; and RD effort was needed elsewhere. Would it help if a UP1100 was somehow made available for testing/development? -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
The system in question is an API UP1100 based system, running 4 Maxtor 40gb IDE drives off the ALI M15x3 chipset. This applies to kernel 2.4.0 and 2.4.1. The drives are identified as follows from hdparm: Model=Maxtor 54098H8, FwRev=DAC10SC0, SerialNo=K80F1ZFC Is also has an Adaptec 29160 SCSI card, running a solid state disk and an AIT tape library. Upon placing any heavy I/O load on any of the disks (dd if=/dev/*d* of=/dev/null) the screen flashes a few times, and then the system locks hard -- no sysrq, no control-alt-del, no pings, no nothing. It will also hang and lock hard on fscking corrupted filesystems under 2.4.0 and 2.4.1. Interestingly enough, I tried 'dd if=/dev/zero of=/tmp/dd.img bs=4096 count=1' and it also locked hard, after printing messages to the effect of: EXT2-fs error: (device info) allocating block in system zone -- block (block numbers). stock RH 2.2.16-3 works peachy. I've tried various options with compiling in and out the ALI chipset, PCI DMA, drive DMA, and IRQ sharing, but without all four of those enabled, the system freezes at identifying the IDE device partitions, like so: hda: lost interrupt lost interrupt lost interrupt I've heard one other report of similar problems on the linux-kernel mailing list, and at least one other on the axp-list. On Thu, 1 Feb 2001, Michal Jaegermann wrote: > Date: Thu, 1 Feb 2001 09:23:42 -0700 > From: Michal Jaegermann <[EMAIL PROTECTED]> > To: John Jasen <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: 2.4.1 not fully sane on Alpha - file systems > > On Thu, Feb 01, 2001 at 10:46:12AM -0500, John Jasen wrote: > > On Wed, 31 Jan 2001, Michal Jaegermann wrote: > > > > > I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine > > > happens to have two SCSI disks on sym53c875 controller and two IDE > > > drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE". > > > > ALI M1535D pci-ide bridge, isn't it? That's what the specs on > > API's webpage seem to indicate. > > 'lspci' claims that this is: > > "07.0 Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV]" > > > > > Try this for fun: dd if=/dev/hda of=/dev/null bs=4096, and see if it > > cronks out. > > Probably. > > > In my case, any serious I/O on the IDE drives quickly results in pretty > > technicolor on the VGA screen, and then a hard lockup. > > No, no technicolor or other sounds effects. The whole thing just > locks up with a power switch as the only option. > > > Furthermore, after power-reset, 2.4.x, x=0 or 1, cannot successfully fsck > > the drives. It hangs after about the 2nd-3rd partition, again in a hard > > lockup. > > My box is much healtier than that. Regardless if I booted into a file > system on a SCSI drive or on an IDE drive (I happen to have those > options although I prefer IDE - I have there something which I can loose > without any real pain :-) I can still fsck drives healthy after the > crash but I did NOT risk fsck under 2.4.1. Things looks way too screwy > for this. > > > > > My WAG is that there are problems in the ALI driver. > > Possibly, but I crashed the whole thing without mounting anything from > IDE drives at all. There are still there but unused. I simply managed > to get something in logs for the case described. Note that errors > I quoted are from a device 08:05, i.e. SCSI driver (/dev/sda5 to be > more precise). When my compiler went bonkers and started to read > clearly some random stuff instead of sources then the whole action was > happening on a SCSI drive. > > Michal > - > 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/ > -- -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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 - can't read root fs (devfs maybe?)
On Thu, 1 Feb 2001, Peter Samuelson wrote: > [Michael J. Dikkema] > > > I went from 2.4.0 to 2.4.1 and was surprised that either the root > > > filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm > > > thinking there might have been a change with regards to the devfs > > > tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? > > > > > > I can't even get a shell with init=/bin/bash.. > > [John Jasen] > > Sounds like a lack of devfsd, which handles backwards compatibility > > for /dev entries. > > devfsd does not start up until after the root filesystem is mounted, so > that's not it. E upon careful reading of the devfs/devfsd documentation, you'll find that it says to put /sbin/devfsd /dev in amongst the first lines in rc.sysinit. In looking through rc.sysinit, / is not mounted rw until much later. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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 - can't read root fs (devfs maybe?)
On Wed, 31 Jan 2001, Michael J. Dikkema wrote: > I went from 2.4.0 to 2.4.1 and was surprised that either the root > filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm > thinking there might have been a change with regards to the devfs > tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? > > I can't even get a shell with init=/bin/bash.. Sounds like a lack of devfsd, which handles backwards compatibility for /dev entries. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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 not fully sane on Alpha - file systems
On Wed, 31 Jan 2001, Michal Jaegermann wrote: > I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine > happens to have two SCSI disks on sym53c875 controller and two IDE > drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE". ALI M1535D pci-ide bridge, isn't it? That's what the specs on API's webpage seem to indicate. > It boots and in the first moment makes even a pretty good impression > of beeing healthy. But an attempt to compile something causes the > whole setup to start behaving weird, with a compiler obviously unable > to find both itself and the right sources, and the whole thing ends in > a silent lockup. Try this for fun: dd if=/dev/hda of=/dev/null bs=4096, and see if it cronks out. In my case, any serious I/O on the IDE drives quickly results in pretty technicolor on the VGA screen, and then a hard lockup. Furthermore, after power-reset, 2.4.x, x=0 or 1, cannot successfully fsck the drives. It hangs after about the 2nd-3rd partition, again in a hard lockup. I have to boot into 2.2.x to fsck the drives, make changes, and reboot to hang the system. My WAG is that there are problems in the ALI driver. > On the second boot I tried to copy kernel sources from a SCSI to an > IDE drive. This time I got something in my logs and the same stuff > was printed on my screen before everything lockded up really tight > again (no sysrq). Here it is: > > kernel: attempt to access beyond end of device > kernel: 08:05: rw=0, want=198500353, limit=5779456 > kernel: attempt to access beyond end of device > kernel: 08:05: rw=0, want=4294934529, limit=5779456 > kernel: attempt to access beyond end of device > kernel: 08:05: rw=0, want=198500353, limit=5779456 > kernel: EXT2-fs error (device sd(8,5)): ext2_readdir: bad entry in > directory #250255: directory entry across blocks - offset=0, > inode=198505472, rec_len=32768, name_len=255 > > (and the machine dies at this point). AIC7xxx controller, just recently started spewing errors very similar to this -- amongst a host of others, as I was trying to get the UP1100 to use a generic IDE interface rather than the ALI 15x3. - 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: Modules and DevFS
On Thu, 1 Feb 2001, William Knop wrote: > >One thing that I've noticed with devfs is that all the old-style names are > >symlinks. > > Hmm... I have no symlinks until the module loads. Therefore X sees no > /dev/input/mouse, doesn't ask the kernel for it, the kernel doesn't load the > module, and DevFS doesn't add the /dev entry. There's got to be an easy way > around this. Perhaps it has already been implimented, but I haven't been > able to get anything to work well (manual loading for me). change your XF86Config file to point to /dev/psaux - 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: Modules and DevFS
On Thu, 1 Feb 2001, William Knop wrote: One thing that I've noticed with devfs is that all the old-style names are symlinks. Hmm... I have no symlinks until the module loads. Therefore X sees no /dev/input/mouse, doesn't ask the kernel for it, the kernel doesn't load the module, and DevFS doesn't add the /dev entry. There's got to be an easy way around this. Perhaps it has already been implimented, but I haven't been able to get anything to work well (manual loading for me). change your XF86Config file to point to /dev/psaux - 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 not fully sane on Alpha - file systems
On Wed, 31 Jan 2001, Michal Jaegermann wrote: I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine happens to have two SCSI disks on sym53c875 controller and two IDE drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE". ALI M1535D pci-ide bridge, isn't it? That's what the specs on API's webpage seem to indicate. It boots and in the first moment makes even a pretty good impression of beeing healthy. But an attempt to compile something causes the whole setup to start behaving weird, with a compiler obviously unable to find both itself and the right sources, and the whole thing ends in a silent lockup. Try this for fun: dd if=/dev/hda of=/dev/null bs=4096, and see if it cronks out. In my case, any serious I/O on the IDE drives quickly results in pretty technicolor on the VGA screen, and then a hard lockup. Furthermore, after power-reset, 2.4.x, x=0 or 1, cannot successfully fsck the drives. It hangs after about the 2nd-3rd partition, again in a hard lockup. I have to boot into 2.2.x to fsck the drives, make changes, and reboot to hang the system. My WAG is that there are problems in the ALI driver. On the second boot I tried to copy kernel sources from a SCSI to an IDE drive. This time I got something in my logs and the same stuff was printed on my screen before everything lockded up really tight again (no sysrq). Here it is: kernel: attempt to access beyond end of device kernel: 08:05: rw=0, want=198500353, limit=5779456 kernel: attempt to access beyond end of device kernel: 08:05: rw=0, want=4294934529, limit=5779456 kernel: attempt to access beyond end of device kernel: 08:05: rw=0, want=198500353, limit=5779456 kernel: EXT2-fs error (device sd(8,5)): ext2_readdir: bad entry in directory #250255: directory entry across blocks - offset=0, inode=198505472, rec_len=32768, name_len=255 (and the machine dies at this point). AIC7xxx controller, just recently started spewing errors very similar to this -- amongst a host of others, as I was trying to get the UP1100 to use a generic IDE interface rather than the ALI 15x3. - 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 - can't read root fs (devfs maybe?)
On Wed, 31 Jan 2001, Michael J. Dikkema wrote: I went from 2.4.0 to 2.4.1 and was surprised that either the root filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm thinking there might have been a change with regards to the devfs tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? I can't even get a shell with init=/bin/bash.. Sounds like a lack of devfsd, which handles backwards compatibility for /dev entries. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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 - can't read root fs (devfs maybe?)
On Thu, 1 Feb 2001, Peter Samuelson wrote: [Michael J. Dikkema] I went from 2.4.0 to 2.4.1 and was surprised that either the root filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm thinking there might have been a change with regards to the devfs tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? I can't even get a shell with init=/bin/bash.. [John Jasen] Sounds like a lack of devfsd, which handles backwards compatibility for /dev entries. devfsd does not start up until after the root filesystem is mounted, so that's not it. E upon careful reading of the devfs/devfsd documentation, you'll find that it says to put /sbin/devfsd /dev in amongst the first lines in rc.sysinit. In looking through rc.sysinit, / is not mounted rw until much later. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
The system in question is an API UP1100 based system, running 4 Maxtor 40gb IDE drives off the ALI M15x3 chipset. This applies to kernel 2.4.0 and 2.4.1. The drives are identified as follows from hdparm: Model=Maxtor 54098H8, FwRev=DAC10SC0, SerialNo=K80F1ZFC Is also has an Adaptec 29160 SCSI card, running a solid state disk and an AIT tape library. Upon placing any heavy I/O load on any of the disks (dd if=/dev/*d* of=/dev/null) the screen flashes a few times, and then the system locks hard -- no sysrq, no control-alt-del, no pings, no nothing. It will also hang and lock hard on fscking corrupted filesystems under 2.4.0 and 2.4.1. Interestingly enough, I tried 'dd if=/dev/zero of=/tmp/dd.img bs=4096 count=1' and it also locked hard, after printing messages to the effect of: EXT2-fs error: (device info) allocating block in system zone -- block (block numbers). stock RH 2.2.16-3 works peachy. I've tried various options with compiling in and out the ALI chipset, PCI DMA, drive DMA, and IRQ sharing, but without all four of those enabled, the system freezes at identifying the IDE device partitions, like so: hda: lost interrupt lost interrupt lost interrupt I've heard one other report of similar problems on the linux-kernel mailing list, and at least one other on the axp-list. On Thu, 1 Feb 2001, Michal Jaegermann wrote: Date: Thu, 1 Feb 2001 09:23:42 -0700 From: Michal Jaegermann [EMAIL PROTECTED] To: John Jasen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: 2.4.1 not fully sane on Alpha - file systems On Thu, Feb 01, 2001 at 10:46:12AM -0500, John Jasen wrote: On Wed, 31 Jan 2001, Michal Jaegermann wrote: I just tried to boot 2.4.1 kernel on Alpha UP1100. This machine happens to have two SCSI disks on sym53c875 controller and two IDE drives hooked to a builtin "Acer Laboratories Inc. [ALi] M5229 IDE". ALI M1535D pci-ide bridge, isn't it? That's what the specs on API's webpage seem to indicate. 'lspci' claims that this is: "07.0 Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV]" Try this for fun: dd if=/dev/hda of=/dev/null bs=4096, and see if it cronks out. Probably. In my case, any serious I/O on the IDE drives quickly results in pretty technicolor on the VGA screen, and then a hard lockup. No, no technicolor or other sounds effects. The whole thing just locks up with a power switch as the only option. Furthermore, after power-reset, 2.4.x, x=0 or 1, cannot successfully fsck the drives. It hangs after about the 2nd-3rd partition, again in a hard lockup. My box is much healtier than that. Regardless if I booted into a file system on a SCSI drive or on an IDE drive (I happen to have those options although I prefer IDE - I have there something which I can loose without any real pain :-) I can still fsck drives healthy after the crash but I did NOT risk fsck under 2.4.1. Things looks way too screwy for this. My WAG is that there are problems in the ALI driver. Possibly, but I crashed the whole thing without mounting anything from IDE drives at all. There are still there but unused. I simply managed to get something in logs for the case described. Note that errors I quoted are from a device 08:05, i.e. SCSI driver (/dev/sda5 to be more precise). When my compiler went bonkers and started to read clearly some random stuff instead of sources then the whole action was happening on a SCSI drive. Michal - 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/ -- -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Bummer...
On Wed, 31 Jan 2001, Greg from Systems wrote:
> I've been playing with the 2.4.0 kernel scince you gave me the patch for
> the alphas...
>
> What I have found is that it tends to randomly hang...
> No Panic, no OOPs, no nothing...
> The machine is a PC164, Which falls under the EB164 class.
> It exhibits this behaviour on both the "generic" and "eb164" cpu types
> {compile option} It doesn't even boot compiled as pc164..
> I'm also seeing this problem on my A/S 4100, "Rawhide"..
I've been having IDE problems under alpha (API UP1100 motherboard) with
the ALI M1535D pci-isa bridge/ide controller and the AIC7xxx drivers.
Under 2.4.0, any heavy disk access "dd if=/dev/hda of=/dev/null" will
immediately lock the system, and under 2.4.1, it won't finish booting ...
--
-- John E. Jasen ([EMAIL PROTECTED])
-- In theory, theory and practise are the same. In practise, they aren't.
-
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: bttv problems in 2.4.0/2.4.1 PAL_BG
On Wed, 31 Jan 2001, archan wrote: > I am using "Pixel View TV tuner card" based on "bttv". It works perfect > in Windows with default TV application, and also responding well in > Linux 2.2.17 and 2.4.0-test10 kernel. The device is getting detected > perfectly by 2.4 kernel but I could not be able to check whether the > card in 2.4 kernel is responding on PAL-BG signal (here, my frequency > table is PAL-BG, country India) as none of the Linux apps (xawtv, > cabletv) are responding positively. I think I ended up trying the bttv 0.8 drivers, and maybe video4linux2, nowe that I think about it. I'll have to doublecheck and get back to you on that. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: bttv problems in 2.4.0/2.4.1 PAL_BG
On Wed, 31 Jan 2001, archan wrote: I am using "Pixel View TV tuner card" based on "bttv". It works perfect in Windows with default TV application, and also responding well in Linux 2.2.17 and 2.4.0-test10 kernel. The device is getting detected perfectly by 2.4 kernel but I could not be able to check whether the card in 2.4 kernel is responding on PAL-BG signal (here, my frequency table is PAL-BG, country India) as none of the Linux apps (xawtv, cabletv) are responding positively. I think I ended up trying the bttv 0.8 drivers, and maybe video4linux2, nowe that I think about it. I'll have to doublecheck and get back to you on that. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Bummer...
On Wed, 31 Jan 2001, Greg from Systems wrote:
I've been playing with the 2.4.0 kernel scince you gave me the patch for
the alphas...
What I have found is that it tends to randomly hang...
No Panic, no OOPs, no nothing...
The machine is a PC164, Which falls under the EB164 class.
It exhibits this behaviour on both the "generic" and "eb164" cpu types
{compile option} It doesn't even boot compiled as pc164..
I'm also seeing this problem on my A/S 4100, "Rawhide"..
I've been having IDE problems under alpha (API UP1100 motherboard) with
the ALI M1535D pci-isa bridge/ide controller and the AIC7xxx drivers.
Under 2.4.0, any heavy disk access "dd if=/dev/hda of=/dev/null" will
immediately lock the system, and under 2.4.1, it won't finish booting ...
--
-- John E. Jasen ([EMAIL PROTECTED])
-- In theory, theory and practise are the same. In practise, they aren't.
-
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: bttv problems in 2.4.0/2.4.1
On Tue, 30 Jan 2001, Matthew Gabeler-Lee wrote: > These errors all occur in the same way (as near as I can tell) in > kernels 2.4.0 and 2.4.1, using bttv drivers 0.7.50 (incl. w/ kernel), > 0.7.53, and 0.7.55. > > I am currently using 2.4.0-test10 with bttv 0.7.47, which works fine. > > I have sent all this info to Gerd Knorr but, as far as I know, he hasn't > been able to track down the bug yet. I thought that by posting here, > more eyes might at least make more reports of similar situations that > might help track down the problem. Try flipping the card into a different slot. A lot of the cards exceptionally do not like IRQ/DMA sharing, and a lot of the motherboards share them between different slots. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: bttv problems in 2.4.0/2.4.1
On Tue, 30 Jan 2001, Matthew Gabeler-Lee wrote: These errors all occur in the same way (as near as I can tell) in kernels 2.4.0 and 2.4.1, using bttv drivers 0.7.50 (incl. w/ kernel), 0.7.53, and 0.7.55. I am currently using 2.4.0-test10 with bttv 0.7.47, which works fine. I have sent all this info to Gerd Knorr but, as far as I know, he hasn't been able to track down the bug yet. I thought that by posting here, more eyes might at least make more reports of similar situations that might help track down the problem. Try flipping the card into a different slot. A lot of the cards exceptionally do not like IRQ/DMA sharing, and a lot of the motherboards share them between different slots. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Moving from kernel 2.2 to 2.4
On Sun, 28 Jan 2001, Alec Smith wrote: > I understand a large portion of the kernel 2.4 networking code was updated > and/or completely replaced. Under 2.2 I have ipchains configured to do > basic masquerading for my local LAN. Is there a straightforward guide which > describes how to do masquerading and firewalling with 2.4 after moving up > from 2.2? http://netfilter.kernelnotes.org/unreliable-guides/ In general, you _have to_ upgrade modutils to at least a 2.3.x revision. If you use devfs, you almost have to install devfsd, and you really need to upgrade util-linux (there's a bug in older versions of /bin/login that barf on the new tty scheme). I usually do it by compiling and installing a 2.4 kernel; compiling, installing devfsd (and adding an entry very early in rc.sysinit for it); installing modutils; and installing util-linux -- then rebooting to test the new kernel. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Support for 802.11 cards?
On Sun, 28 Jan 2001, Mike Pontillo wrote: > I was wondering what 802.11 PCI cards anyone knows of that run > under Linux-2.4. (or 2.2 for that matter) I _think_ a good many of the 802.11 wireless ISA and PCI cards are just bus to PCMCIA adapters, so it would be a question of whether or not the PCMCIA card is supported and if the bridge is supported. - 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: Support for 802.11 cards?
On Sun, 28 Jan 2001, Mike Pontillo wrote: I was wondering what 802.11 PCI cards anyone knows of that run under Linux-2.4. (or 2.2 for that matter) I _think_ a good many of the 802.11 wireless ISA and PCI cards are just bus to PCMCIA adapters, so it would be a question of whether or not the PCMCIA card is supported and if the bridge is supported. - 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: Moving from kernel 2.2 to 2.4
On Sun, 28 Jan 2001, Alec Smith wrote: I understand a large portion of the kernel 2.4 networking code was updated and/or completely replaced. Under 2.2 I have ipchains configured to do basic masquerading for my local LAN. Is there a straightforward guide which describes how to do masquerading and firewalling with 2.4 after moving up from 2.2? http://netfilter.kernelnotes.org/unreliable-guides/ In general, you _have to_ upgrade modutils to at least a 2.3.x revision. If you use devfs, you almost have to install devfsd, and you really need to upgrade util-linux (there's a bug in older versions of /bin/login that barf on the new tty scheme). I usually do it by compiling and installing a 2.4 kernel; compiling, installing devfsd (and adding an entry very early in rc.sysinit for it); installing modutils; and installing util-linux -- then rebooting to test the new kernel. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: No SCSI Ultra 160 with Adaptec Controller
On Tue, 23 Jan 2001, Matthew Jacob wrote: > Actually, aren't a number of newer drives getting upwards of 30MB/s? It depends tests I've done here, with scsi/160 and FC on seagate drives, the read/write speeds start at ~35MB/s, and peter off to ~22MB/s. I admit my methodology was crude, but I was more curious than scientificly precise. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: No SCSI Ultra 160 with Adaptec Controller
On Tue, 23 Jan 2001, Matthew Jacob wrote: Actually, aren't a number of newer drives getting upwards of 30MB/s? It depends tests I've done here, with scsi/160 and FC on seagate drives, the read/write speeds start at ~35MB/s, and peter off to ~22MB/s. I admit my methodology was crude, but I was more curious than scientificly precise. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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-pre8/10 klogd taking 100% of CPU time -- bug?
On Tue, 23 Jan 2001, Tigran Aivazian wrote: > Asset Tag: Ñ^L. > Asset Tag: Ò^L. That's interesting ... My Inspiron 3700 prints asset tags just fine in 2.4.0-release. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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-pre8/10 klogd taking 100% of CPU time -- bug?
On Tue, 23 Jan 2001, Tigran Aivazian wrote: Asset Tag: Ñ^L. Asset Tag: Ò^L. That's interesting ... My Inspiron 3700 prints asset tags just fine in 2.4.0-release. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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/
PROBLEM: raid assembly on 2.4.0-2.4.1-pre9 fails
[1.] One line summary of the problem: cannot assemble md devices under 2.4.x, x=0,1-pre7,1-pre9 [2.] Full description of the problem/report: System: API UP2000 motherboard, running generic 2.4.0 to 2.4.1-pre9 kernel. kernel .config file can be found: http://userpages.umbc.edu/~jjasen1/config.241-p7.txt error messages: can be found: http://userpages.umbc.edu/~jjasen1/boot-2.4.0-errs.txt and boot-2.4.1-p7-errs.txt [3.] Keywords: kernel, filesystem, raid, alpha [4.] Kernel version: 2.4.0, 2.4.1-pre7, 2.4.1-pre9 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) No Oops [6.] A small shell script or example program which triggers the problem (if possible) none [7.] Environment [7.1.] Software (add the output of the ver_linux script here) -- Versions installed: (if some fields are empty or looks -- unusual then possibly you have very old versions) version of kernel is incorrect to report problem. System cannot mount drives under 2.4.0 Linux sneaky 2.2.17-RAID-IDE-NFS #5 Tue Nov 7 18:18:22 EST 2000 alpha unknown Kernel modules 2.3.19 Gnu C egcs-2.91.66 Gnu Make 3.78.1 Binutils 2.9.5.0.22 Linux C Library2.1.3 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.6 Mount 2.10m Net-tools 1.54 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded lockd sunrpc de4x5 st [7.2] CPU Info: [root@sneaky /root]# more /proc/cpuinfo cpu : Alpha cpu model : EV67 cpu variation : 7 cpu revision: 0 cpu serial number : system type : Nautilus system variation: 0 system revision : 0 system serial number: cycle frequency [Hz]: 598802395 timer frequency [Hz]: 1024.00 page size [bytes] : 8192 phys. address bits : 44 max. addr. space # : 255 BogoMIPS: 1191.18 kernel unaligned acc: 0 (pc=0,va=0) user unaligned acc : 0 (pc=0,va=0) platform string : SEC UP1100 598 MHz cpus detected : 1 [7.5] [root@sneaky /root]# more /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid5] read_ahead 1024 sectors md0 : active raid5 hdd1[2] hdc1[1] hdb1[0] hda1[3] 1060096 blocks level 5, 32k c hunk, algorithm 2 [3/3] [UUU] md1 : active raid5 hdd3[2] hdc3[1] hdb3[0] hda3[3] 4208896 blocks level 5, 32k c hunk, algorithm 2 [3/3] [UUU] md2 : active raid5 hdd5[2] hdc5[1] hdb5[0] hda5[3] 4208768 blocks level 5, 32k c hunk, algorithm 2 [3/3] [UUU] md3 : active raid5 hdd6[2] hdc6[1] hdb6[0] hda6[3] 4208768 blocks level 5, 32k c hunk, algorithm 2 [3/3] [UUU] md4 : active raid5 hdd7[2] hdc7[1] hdb7[0] hda7[3] 1060096 blocks level 5, 32k c hunk, algorithm 2 [3/3] [UUU] unused devices: cat /etc/raidtab: [root@sneaky /root]# more /etc/raidtab raiddev /dev/md0 raid-level 5 nr-raid-disks 3 nr-spare-disks 1 persistent-superblock 1 parity-algorithmleft-symmetric chunk-size 32 device /dev/hdb1 raid-disk 0 device /dev/hdc1 raid-disk 1 device /dev/hdd1 raid-disk 2 device /dev/hda1 spare-disk 0 raiddev /dev/md1 raid-level 5 nr-raid-disks 3 nr-spare-disks 1 persistent-superblock 1 parity-algorithmleft-symmetric chunk-size 32 device /dev/hdb3 raid-disk 0 device /dev/hdc3 raid-disk 1 device /dev/hdd3 raid-disk 2 device /dev/hda3 spare-disk 0 ... and so forth. [8.] I seem to recall seeing an error just like this in the archives, under -test5 or somesuch, but of course, can't find it now. -- John Jasen - 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/
PROBLEM: raid assembly on 2.4.0-2.4.1-pre9 fails
[1.] One line summary of the problem: cannot assemble md devices under 2.4.x, x=0,1-pre7,1-pre9 [2.] Full description of the problem/report: System: API UP2000 motherboard, running generic 2.4.0 to 2.4.1-pre9 kernel. kernel .config file can be found: http://userpages.umbc.edu/~jjasen1/config.241-p7.txt error messages: summarised can be found: http://userpages.umbc.edu/~jjasen1/boot-2.4.0-errs.txt and boot-2.4.1-p7-errs.txt [3.] Keywords: kernel, filesystem, raid, alpha [4.] Kernel version: 2.4.0, 2.4.1-pre7, 2.4.1-pre9 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) No Oops [6.] A small shell script or example program which triggers the problem (if possible) none [7.] Environment [7.1.] Software (add the output of the ver_linux script here) -- Versions installed: (if some fields are empty or looks -- unusual then possibly you have very old versions) version of kernel is incorrect to report problem. System cannot mount drives under 2.4.0 Linux sneaky 2.2.17-RAID-IDE-NFS #5 Tue Nov 7 18:18:22 EST 2000 alpha unknown Kernel modules 2.3.19 Gnu C egcs-2.91.66 Gnu Make 3.78.1 Binutils 2.9.5.0.22 Linux C Library2.1.3 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.6 Mount 2.10m Net-tools 1.54 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded lockd sunrpc de4x5 st [7.2] CPU Info: [root@sneaky /root]# more /proc/cpuinfo cpu : Alpha cpu model : EV67 cpu variation : 7 cpu revision: 0 cpu serial number : system type : Nautilus system variation: 0 system revision : 0 system serial number: cycle frequency [Hz]: 598802395 timer frequency [Hz]: 1024.00 page size [bytes] : 8192 phys. address bits : 44 max. addr. space # : 255 BogoMIPS: 1191.18 kernel unaligned acc: 0 (pc=0,va=0) user unaligned acc : 0 (pc=0,va=0) platform string : SEC UP1100 598 MHz cpus detected : 1 [7.5] [root@sneaky /root]# more /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid5] read_ahead 1024 sectors md0 : active raid5 hdd1[2] hdc1[1] hdb1[0] hda1[3] 1060096 blocks level 5, 32k c hunk, algorithm 2 [3/3] [UUU] md1 : active raid5 hdd3[2] hdc3[1] hdb3[0] hda3[3] 4208896 blocks level 5, 32k c hunk, algorithm 2 [3/3] [UUU] md2 : active raid5 hdd5[2] hdc5[1] hdb5[0] hda5[3] 4208768 blocks level 5, 32k c hunk, algorithm 2 [3/3] [UUU] md3 : active raid5 hdd6[2] hdc6[1] hdb6[0] hda6[3] 4208768 blocks level 5, 32k c hunk, algorithm 2 [3/3] [UUU] md4 : active raid5 hdd7[2] hdc7[1] hdb7[0] hda7[3] 1060096 blocks level 5, 32k c hunk, algorithm 2 [3/3] [UUU] unused devices: none cat /etc/raidtab: [root@sneaky /root]# more /etc/raidtab raiddev /dev/md0 raid-level 5 nr-raid-disks 3 nr-spare-disks 1 persistent-superblock 1 parity-algorithmleft-symmetric chunk-size 32 device /dev/hdb1 raid-disk 0 device /dev/hdc1 raid-disk 1 device /dev/hdd1 raid-disk 2 device /dev/hda1 spare-disk 0 raiddev /dev/md1 raid-level 5 nr-raid-disks 3 nr-spare-disks 1 persistent-superblock 1 parity-algorithmleft-symmetric chunk-size 32 device /dev/hdb3 raid-disk 0 device /dev/hdc3 raid-disk 1 device /dev/hdd3 raid-disk 2 device /dev/hda3 spare-disk 0 ... and so forth. [8.] I seem to recall seeing an error just like this in the archives, under -test5 or somesuch, but of course, can't find it now. -- John Jasen - 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 and ipmasq modules
On Sat, 20 Jan 2001, Aaron Lehmann wrote: > It was great to see that 2.4.0 reintroduced ipfwadm support! I had no > need for ipchains and ended up using the wrapper around it that > emulated ipfwadm. However, 2.[02].x used to have "special IP > masquerading modules" such as ip_masq_ftp.o, ip_masq_quake.o, etc. I > can't find these in 2.4.0. Where have they gone? Without important > modules such as ip_masq_ftp.o I cannot use non-passive ftp from behind > the masquerading firewall. I think its ip_conntrack_ftp, but I'll check my fw setup to verify if you still can't find it. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Serious file system corruption with RAID5+SMP and kernelsabove2.4.0
I can't even get RAID5 to assemble thew md devices under 2.4.0 and 2.4.1-pre7. On Sat, 20 Jan 2001, Holger Kiehl wrote: > Date: Sat, 20 Jan 2001 19:42:04 +0100 (CET) > From: Holger Kiehl <[EMAIL PROTECTED]> > To: Otto Meier <[EMAIL PROTECTED]> > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Subject: Re: Serious file system corruption with RAID5+SMP and kernels > above2.4.0 > > On Sat, 20 Jan 2001, Otto Meier wrote: > > > Two days ago I tried new kernels on my SMP SW RAID5 System > > and expirienced serous file system corruption with kernels 2.4.1-pre8,9 as >2.4.0-ac8,9,10. > > The same error has been reported by other people on this list. With 2.4.0 release > > everything runs fine. So I backsteped to it and had no error since. > > > I just tried 2.4.0 and still get filesystem corruption. My system is > also SMP and SW Raid5. So far I have tried 2.4.0, 2.4.1-pre3,8 and > 2.4.0-ac10 and all corrupt my filesystem. 2.2.18 is ok. > > With the help of Manfred Spraul I can now reproduce this problem > within 10 minutes. > > Holger > > - > 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/ > -- -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Serious file system corruption with RAID5+SMP and kernelsabove2.4.0
I can't even get RAID5 to assemble thew md devices under 2.4.0 and 2.4.1-pre7. On Sat, 20 Jan 2001, Holger Kiehl wrote: Date: Sat, 20 Jan 2001 19:42:04 +0100 (CET) From: Holger Kiehl [EMAIL PROTECTED] To: Otto Meier [EMAIL PROTECTED] Cc: "[EMAIL PROTECTED]" [EMAIL PROTECTED], "[EMAIL PROTECTED]" [EMAIL PROTECTED] Subject: Re: Serious file system corruption with RAID5+SMP and kernels above2.4.0 On Sat, 20 Jan 2001, Otto Meier wrote: Two days ago I tried new kernels on my SMP SW RAID5 System and expirienced serous file system corruption with kernels 2.4.1-pre8,9 as 2.4.0-ac8,9,10. The same error has been reported by other people on this list. With 2.4.0 release everything runs fine. So I backsteped to it and had no error since. I just tried 2.4.0 and still get filesystem corruption. My system is also SMP and SW Raid5. So far I have tried 2.4.0, 2.4.1-pre3,8 and 2.4.0-ac10 and all corrupt my filesystem. 2.2.18 is ok. With the help of Manfred Spraul I can now reproduce this problem within 10 minutes. Holger - 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/ -- -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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 and ipmasq modules
On Sat, 20 Jan 2001, Aaron Lehmann wrote: It was great to see that 2.4.0 reintroduced ipfwadm support! I had no need for ipchains and ended up using the wrapper around it that emulated ipfwadm. However, 2.[02].x used to have "special IP masquerading modules" such as ip_masq_ftp.o, ip_masq_quake.o, etc. I can't find these in 2.4.0. Where have they gone? Without important modules such as ip_masq_ftp.o I cannot use non-passive ftp from behind the masquerading firewall. I think its ip_conntrack_ftp, but I'll check my fw setup to verify if you still can't find it. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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/
md problems (2.4.0/2.4.1-pre7 on alpha)
It looks like my first message was too large ... so a bit of trimming of the error messages, and ... Please find attached my .config file for 2.4.1-pre7, and the error logs from trying to mount raid partitions under 2.4.0 and 2.4.1-pre7. Trying to upgrade a system, running 2.2.17, to 2.4.x, and its getting stuck on the raid5 partitions. I've tried with/without devfs support, as well as booting with the md=0,/dev/hdxx,/dev/hdxx,/dev/hdxx, as suggested in Documentation/md.txt -- all to no avail. Any suggestions? -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. # # Automatically generated make config: don't edit # CONFIG_ALPHA=y # CONFIG_UID16 is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # General setup # CONFIG_ALPHA_GENERIC=y # CONFIG_ALPHA_ALCOR is not set # CONFIG_ALPHA_XL is not set # CONFIG_ALPHA_BOOK1 is not set # CONFIG_ALPHA_AVANTI is not set # CONFIG_ALPHA_CABRIOLET is not set # CONFIG_ALPHA_DP264 is not set # CONFIG_ALPHA_EB164 is not set # CONFIG_ALPHA_EB64P is not set # CONFIG_ALPHA_EB66 is not set # CONFIG_ALPHA_EB66P is not set # CONFIG_ALPHA_EIGER is not set # CONFIG_ALPHA_JENSEN is not set # CONFIG_ALPHA_LX164 is not set # CONFIG_ALPHA_MIATA is not set # CONFIG_ALPHA_MIKASA is not set # CONFIG_ALPHA_NAUTILUS is not set # CONFIG_ALPHA_NONAME is not set # CONFIG_ALPHA_NORITAKE is not set # CONFIG_ALPHA_PC164 is not set # CONFIG_ALPHA_P2K is not set # CONFIG_ALPHA_RAWHIDE is not set # CONFIG_ALPHA_RUFFIAN is not set # CONFIG_ALPHA_RX164 is not set # CONFIG_ALPHA_SX164 is not set # CONFIG_ALPHA_SABLE is not set # CONFIG_ALPHA_TAKARA is not set # CONFIG_ALPHA_TITAN is not set # CONFIG_ALPHA_WILDFIRE is not set CONFIG_ISA=y CONFIG_EISA=y # CONFIG_SBUS is not set # CONFIG_MCA is not set CONFIG_PCI=y CONFIG_ALPHA_BROKEN_IRQ_MASK=y CONFIG_SMP=y CONFIG_ALPHA_LARGE_VMALLOC=y CONFIG_PCI_NAMES=y CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_NET=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_BINFMT_EM86 is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y CONFIG_MD_BOOT=y CONFIG_AUTODETECT_RAID=y # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set CONFIG_INET_ECN=y # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_COMMERIAL is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_ISAPNP is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_IDEPCI_SHARE_IRQ is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set #
md problems (2.4.0/2.4.1-pre7 on alpha)
It looks like my first message was too large ... so a bit of trimming of the error messages, and ... Please find attached my .config file for 2.4.1-pre7, and the error logs from trying to mount raid partitions under 2.4.0 and 2.4.1-pre7. Trying to upgrade a system, running 2.2.17, to 2.4.x, and its getting stuck on the raid5 partitions. I've tried with/without devfs support, as well as booting with the md=0,/dev/hdxx,/dev/hdxx,/dev/hdxx, as suggested in Documentation/md.txt -- all to no avail. Any suggestions? -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. # # Automatically generated make config: don't edit # CONFIG_ALPHA=y # CONFIG_UID16 is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # General setup # CONFIG_ALPHA_GENERIC=y # CONFIG_ALPHA_ALCOR is not set # CONFIG_ALPHA_XL is not set # CONFIG_ALPHA_BOOK1 is not set # CONFIG_ALPHA_AVANTI is not set # CONFIG_ALPHA_CABRIOLET is not set # CONFIG_ALPHA_DP264 is not set # CONFIG_ALPHA_EB164 is not set # CONFIG_ALPHA_EB64P is not set # CONFIG_ALPHA_EB66 is not set # CONFIG_ALPHA_EB66P is not set # CONFIG_ALPHA_EIGER is not set # CONFIG_ALPHA_JENSEN is not set # CONFIG_ALPHA_LX164 is not set # CONFIG_ALPHA_MIATA is not set # CONFIG_ALPHA_MIKASA is not set # CONFIG_ALPHA_NAUTILUS is not set # CONFIG_ALPHA_NONAME is not set # CONFIG_ALPHA_NORITAKE is not set # CONFIG_ALPHA_PC164 is not set # CONFIG_ALPHA_P2K is not set # CONFIG_ALPHA_RAWHIDE is not set # CONFIG_ALPHA_RUFFIAN is not set # CONFIG_ALPHA_RX164 is not set # CONFIG_ALPHA_SX164 is not set # CONFIG_ALPHA_SABLE is not set # CONFIG_ALPHA_TAKARA is not set # CONFIG_ALPHA_TITAN is not set # CONFIG_ALPHA_WILDFIRE is not set CONFIG_ISA=y CONFIG_EISA=y # CONFIG_SBUS is not set # CONFIG_MCA is not set CONFIG_PCI=y CONFIG_ALPHA_BROKEN_IRQ_MASK=y CONFIG_SMP=y CONFIG_ALPHA_LARGE_VMALLOC=y CONFIG_PCI_NAMES=y CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_NET=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_BINFMT_EM86 is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y CONFIG_MD_BOOT=y CONFIG_AUTODETECT_RAID=y # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set CONFIG_INET_ECN=y # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_COMMERIAL is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_ISAPNP is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_IDEPCI_SHARE_IRQ is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set #
Re: Defective Red Hat Distribution poorly represents Linux
On Mon, 20 Nov 2000, Charles Turner, Ph.D. wrote: > (4) For those who think the hardware is broken; The hardware worked > for six months using Windows/2000. It has a NT core. On this note, I recall a time that I 'appropriated' a workstation for linux. It was pulled out of the student labs, where it had worked for 3 months running NT 4.0, but the RH install kept on crashing out. I could even reinstall NT 4.0. *shrug* Eventually traced it down to memory, and had our hardware hacks replace it. Sometimes hardware problems can be subtle. -- -- John E. Jasen ([EMAIL PROTECTED]) -- Some elections you just can't buy. For others, there's GORE 2000 - 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: Defective Red Hat Distribution poorly represents Linux
On Mon, 20 Nov 2000, Charles Turner, Ph.D. wrote: (4) For those who think the hardware is broken; The hardware worked for six months using Windows/2000. It has a NT core. On this note, I recall a time that I 'appropriated' a workstation for linux. It was pulled out of the student labs, where it had worked for 3 months running NT 4.0, but the RH install kept on crashing out. I could even reinstall NT 4.0. *shrug* Eventually traced it down to memory, and had our hardware hacks replace it. Sometimes hardware problems can be subtle. -- -- John E. Jasen ([EMAIL PROTECTED]) -- Some elections you just can't buy. For others, there's GORE 2000 - 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/
compiling md/lvm on 2.4.0-test9-test11-pre2 for alpha
I've tried this on -test9, test10, and test11-pre2, all with similar results. I've checked the kernel mailing list archives, and didn't see anything pertinent. I'm getting the following errors: (in this case, attempting to make them as a module) make -C md modules make[2]: Entering directory `/usr/src/linux-2.4.0-test11-pre2/drivers/md' gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11-pre2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6 -Wa,-mev6 -DMODULE -DEXPORT_SYMTAB -c xor.c xor.c: In function `xor_block_alpha': xor.c:1791: inconsistent operand constraints in an `asm' xor.c: In function `xor_block_alpha_prefetch': xor.c:2213: inconsistent operand constraints in an `asm' make[2]: *** [xor.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.0-test11-pre2/drivers/md' make[1]: *** [_modsubdir_md] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.0-test11-pre2/drivers' make: *** [_mod_drivers] Error 2 This is running Redhat 6.2, with updates, compiling 2.4.0-test11-pre2, with gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Any suggestions? -- -- John E. Jasen ([EMAIL PROTECTED]) -- You can have it: right; cheap; now. Pick any two. - 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/
compiling md/lvm on 2.4.0-test9-test11-pre2 for alpha
I've tried this on -test9, test10, and test11-pre2, all with similar results. I've checked the kernel mailing list archives, and didn't see anything pertinent. I'm getting the following errors: (in this case, attempting to make them as a module) snip make -C md modules make[2]: Entering directory `/usr/src/linux-2.4.0-test11-pre2/drivers/md' gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11-pre2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6 -Wa,-mev6 -DMODULE -DEXPORT_SYMTAB -c xor.c xor.c: In function `xor_block_alpha': xor.c:1791: inconsistent operand constraints in an `asm' xor.c: In function `xor_block_alpha_prefetch': xor.c:2213: inconsistent operand constraints in an `asm' make[2]: *** [xor.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.0-test11-pre2/drivers/md' make[1]: *** [_modsubdir_md] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.0-test11-pre2/drivers' make: *** [_mod_drivers] Error 2 /snip This is running Redhat 6.2, with updates, compiling 2.4.0-test11-pre2, with gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Any suggestions? -- -- John E. Jasen ([EMAIL PROTECTED]) -- You can have it: right; cheap; now. Pick any two. - 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/
