TEST IGNORE
- 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/
TEST IGNORE
- 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: Asus CUV4X-D mobo
d such. I couldn't record the geometry for these drives as they're not marked with it. I had to basically deduce what the setup is. As I said, this is the first time I've seen a drive NOT be marked. David -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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/
Asus CUV4X-D mobo
Well, once again, VIA chipsets cause havok. The Asus CUV4X-D VIA694XDP/VT82C686B chipset. The southbridge (686b) could NOT see it's way clear to understand what my hard drives' geometry was. Kept getting LI every single reboot. Put the drives back on the Promise PDC20267 ATA100 controller and things worked just fine. The APIC errors are gone and things have settled down with the drives working fine @ UDMA5. (hdparm -A1 -c1 -d1 -X69 /dev/hd#). Average disk speed is 32MB/s with no data corruption. Has anyone else experienced problems with this specific motherboard and the VIA chipset? I'm interested in folks using the 2.4.1-ac1# kernel or pristine 2.4.1 + 3.20 via82cxxx patch. I'm also wondering if the 1/09/2001 BIOS this board has is known to have translation problems with Western Digital drives (specifically the WDC300BB00-UA1-A 30GB 7200 RPM EIDE drives) or if it's just this board. BIOS reports CHS as being 1024x16x63+LBA. hdparm -I /dev/hda reports CHS of 16383x16x63+LBA. fdisk reports CHS as 58168x16x63+LBA using neither what the drive reports or what fdisk sees as the CHS count in BIOS stopped the reproducable (and irritating) LI error. Switch to the Promise PDC20267 ATA100 offboard card, run lilo again and bam, instant LILO. Hope fully this is thorough enough. I've attached the lspci -vv output to this email as well. (I'm really starting to dislike this VT82C686 chipset. grrr) --- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Subsystem: Asustek Computer, Inc.: Unknown device 8038 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40) Subsystem: Asustek Computer, Inc.: Unknown device 8038 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=256K] 00:0b.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 4d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] Capabilities: [58] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:0d.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [60] Power Management version 1 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Asus CUV4X-D mobo
Well, once again, VIA chipsets cause havok. The Asus CUV4X-D VIA694XDP/VT82C686B chipset. The southbridge (686b) could NOT see it's way clear to understand what my hard drives' geometry was. Kept getting LI every single reboot. Put the drives back on the Promise PDC20267 ATA100 controller and things worked just fine. The APIC errors are gone and things have settled down with the drives working fine @ UDMA5. (hdparm -A1 -c1 -d1 -X69 /dev/hd#). Average disk speed is 32MB/s with no data corruption. Has anyone else experienced problems with this specific motherboard and the VIA chipset? I'm interested in folks using the 2.4.1-ac1# kernel or pristine 2.4.1 + 3.20 via82cxxx patch. I'm also wondering if the 1/09/2001 BIOS this board has is known to have translation problems with Western Digital drives (specifically the WDC300BB00-UA1-A 30GB 7200 RPM EIDE drives) or if it's just this board. BIOS reports CHS as being 1024x16x63+LBA. hdparm -I /dev/hda reports CHS of 16383x16x63+LBA. fdisk reports CHS as 58168x16x63+LBA using neither what the drive reports or what fdisk sees as the CHS count in BIOS stopped the reproducable (and irritating) LI error. Switch to the Promise PDC20267 ATA100 offboard card, run lilo again and bam, instant LILO. Hope fully this is thorough enough. I've attached the lspci -vv output to this email as well. (I'm really starting to dislike this VT82C686 chipset. grrr) --- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Subsystem: Asustek Computer, Inc.: Unknown device 8038 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR+ Latency: 0 Region 0: Memory at fc00 (32-bit, prefetchable) [size=32M] Capabilities: [a0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate=none Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: f600-f9df Prefetchable memory behind bridge: f9f0-fbff BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40) Subsystem: Asustek Computer, Inc.: Unknown device 8038 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) (prog-if 8a [Master SecP PriP]) Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Region 4: I/O ports at b800 [size=16] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32, cache line size 08 Interrupt: pin D routed to IRQ 18 Region 4: I/O ports at b400 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.3 USB
Re: Asus CUV4X-D mobo
couldn't record the geometry for these drives as they're not marked with it. I had to basically deduce what the setup is. As I said, this is the first time I've seen a drive NOT be marked. David -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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 stifles innovation...
ROTFL, man this guy is funny. On Fri, 16 Feb 2001, Dennis wrote: > At 02:48 PM 02/16/2001, Jesse Pollard wrote: > >On Fri, 16 Feb 2001, Andrew Scott wrote: > > >On 15 Feb 2001, at 9:49, fsnchzjr wrote: > > > > > >> Watch Microsoft's Jim Allchin go Linux-bashing!!! > > >> Nice little article on how we're all going to die of herpes from our > > >> repeated exposition to Linux... > > >> > > http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta > > >> g=ltnc > > > > > >That's about as self-serving a statement as I've ever seen. If this > > >'Jim Alchin' actually believes what he's saying, he's got to be one > > >of the worlds biggest fools, and if he doesn't believe what he's > > >saying, well there aren't too many words that would accurately > > >describe what he is. > > > > > >It's pretty funny in some ways, e.g. "We can build a better product > > >than Linux...", which begs the question, "Well, why don't you?". > > >Perhaps it costs too much? > > objective, arent we? > > There is much truth to the concept, although Microsoft should not be ones > to comment on it as such. > > For example, if there were six different companies that marketed ethernet > drivers for the eepro100, you'd have a choice of which one to buy..perhaps > with different "features" that were of value to you. Instead, you have > crappy GPL code that locks up under load, and its not worth spending > corporate dollars to fix it because you have to give away your work for > free under GPL. And since there is a "free" driver that most people can > use, its not worth building a better mousetrap either because the market is > too small. So, the handful of users with problems get to "fit it > themselves", most of whom cant of course. > > Theres also the propensity for mediocre stuff to get into the kernel > because some half-baked programmer was willing to contribute some code. The > 50% of the kernel that remains "experimental" ad infinitum is evidence of that. > > The biggest thing that the linux community does to stifle innovation is to > bash commercial vendors trying to make a profit by whining endlessly about > "sourceless" distributions and recommending "open-source" solutions even > when they are wholly inferior. You're only hurting yourselves in the long > run. In that respect MS is correct, because those with the dollars to > innovate will stay away. > > DB > > - > 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/ > -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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 stifles innovation...
Would someone tell me where you get all this lovely information on patents held by M$? I can't find anything. On Fri, 16 Feb 2001, James Sutherland wrote: > On Fri, 16 Feb 2001, Rik van Riel wrote: > > > On Thu, 15 Feb 2001, Alan Olsen wrote: > > > > > I expect the next thing that will happen is that they will get > > > patents on key portions of their protocols and then start > > > enforcing them. > > > > If Microsoft would start pissing off IBM and other major > > companies which have big business interests in Linux by > > invoking their patents, I can just imagine IBM coming down > > on Microsoft with their own patents ... > > > > "Hey you! Stop flipping those bits! Hold it right there! > > ... Don't you flip any more bits, read this patent first..." > > > > (and I'm sure they must have patents on _setting_ bits as > > well ;)) > > Apparently they DO have a patent on the tab key - you thought Amazon's > "one click shopping" patent was bad?! > > > James. > > - > 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/ > -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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 stifles innovation...
Would someone tell me where you get all this lovely information on patents held by M$? I can't find anything. On Fri, 16 Feb 2001, James Sutherland wrote: On Fri, 16 Feb 2001, Rik van Riel wrote: On Thu, 15 Feb 2001, Alan Olsen wrote: I expect the next thing that will happen is that they will get patents on key portions of their protocols and then start enforcing them. If Microsoft would start pissing off IBM and other major companies which have big business interests in Linux by invoking their patents, I can just imagine IBM coming down on Microsoft with their own patents ... "Hey you! Stop flipping those bits! Hold it right there! ... Don't you flip any more bits, read this patent first..." (and I'm sure they must have patents on _setting_ bits as well ;)) Apparently they DO have a patent on the tab key - you thought Amazon's "one click shopping" patent was bad?! James. - 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/ -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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 stifles innovation...
ROTFL, man this guy is funny. On Fri, 16 Feb 2001, Dennis wrote: At 02:48 PM 02/16/2001, Jesse Pollard wrote: On Fri, 16 Feb 2001, Andrew Scott wrote: On 15 Feb 2001, at 9:49, fsnchzjr wrote: Watch Microsoft's Jim Allchin go Linux-bashing!!! Nice little article on how we're all going to die of herpes from our repeated exposition to Linux... http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta g=ltnc That's about as self-serving a statement as I've ever seen. If this 'Jim Alchin' actually believes what he's saying, he's got to be one of the worlds biggest fools, and if he doesn't believe what he's saying, well there aren't too many words that would accurately describe what he is. It's pretty funny in some ways, e.g. "We can build a better product than Linux...", which begs the question, "Well, why don't you?". Perhaps it costs too much? objective, arent we? There is much truth to the concept, although Microsoft should not be ones to comment on it as such. For example, if there were six different companies that marketed ethernet drivers for the eepro100, you'd have a choice of which one to buy..perhaps with different "features" that were of value to you. Instead, you have crappy GPL code that locks up under load, and its not worth spending corporate dollars to fix it because you have to give away your work for free under GPL. And since there is a "free" driver that most people can use, its not worth building a better mousetrap either because the market is too small. So, the handful of users with problems get to "fit it themselves", most of whom cant of course. Theres also the propensity for mediocre stuff to get into the kernel because some half-baked programmer was willing to contribute some code. The 50% of the kernel that remains "experimental" ad infinitum is evidence of that. The biggest thing that the linux community does to stifle innovation is to bash commercial vendors trying to make a profit by whining endlessly about "sourceless" distributions and recommending "open-source" solutions even when they are wholly inferior. You're only hurting yourselves in the long run. In that respect MS is correct, because those with the dollars to innovate will stay away. DB - 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/ -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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: [OTP] SMP board recommendations?
Thank you all for your response.
Andre (ASL), thanks for the assist. Laurie and Janine took care of me.
Asus CUV4X-D mobo with 1GB of buffered ECC RAM. I'm in the process of
transfering all the hardware to the new board. I'll let you know if this
new board solves the APIC errors and the random lockups under heavy I/O
problems.
I do have one more problem that I just can NOT track down.
2.4.1-ac10 kernel on the old Abit VP6 mobo. I'm getting curious errors
from the 2.4.1, 2.4.1-ac10, and 2.4.2-pre[#] kernels.
I've been using
dd if=/dev/zero of=/tmp/testdd.img bs=1024k count=1500
for testing of I/O on the various boards I have here. Now, the funny part
is that I get "file size limit exceeded" at around 1.0GB. I was getting
this under the 2.4.2-pre# kernels so i switched to straight 2.4.1 and got
the same problem. I switched to the 2.4.1-ac# line and the problem
disappeared. Guess what? It's baaacckk!
So, I did a strace of the dd command and got the following from it
execve("/bin/dd", ["dd", "if=/dev/zero", "of=/tmp/testing.img", "bs=1024k",
"count=1500"], [/* 22 vars */]) = 0
brk(0) = 0x804e7b8
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=7852, ...}) = 0
old_mmap(NULL, 7852, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0755, st_size=1183326, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\215"..., 4096) = 4096
old_mmap(NULL, 947548, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40017000
mprotect(0x400f7000, 30044, PROT_NONE) = 0
old_mmap(0x400f7000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xdf000) =
0x400f7000
old_mmap(0x400fb000, 13660, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x400fb000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x400ff000
mprotect(0x40017000, 917504, PROT_READ|PROT_WRITE) = 0
mprotect(0x40017000, 917504, PROT_READ|PROT_EXEC) = 0
munmap(0x40015000, 7852)= 0
personality(PER_LINUX) = 0
getpid()= 195
brk(0) = 0x804e7b8
brk(0x804e7f0) = 0x804e7f0
brk(0x804f000) = 0x804f000
open("/dev/zero", O_RDONLY|O_LARGEFILE) = 3
open("/tmp/testing.img", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x804ada8, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {0x804ada8, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {0x804ada8, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, {0x804ae70, [], 0x400}, NULL, 8) = 0
old_mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4010
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) =
1048576
* BIG ASS SNIP **
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = -1
EFBIG (File too large)
--- SIGXFSZ (File size limit exceeded) ---
+++ killed by SIGXFSZ +++
Now, notice the beginning file creation call. It starts out with
O_LARGEFILE but ends with EFBIG. Since I'm not totally familiar with the
kernel code I could be wrong on my next statement and if I am, please tell
me, but it looks like it changes the file creation call from LARGEFILE to
EFBIG (or is this just the error call itself?)
Now, the kernel is supposed to be able to handle creating a 4TB file(?),
so 1.0GB should be nothing to it. NOTHING changed betwen it working and
not working. No hardware changes, no software additions, no recompiles of
existing applications/daemons.. nothing.
So, my question is now one of "What gives?" Any clues on how I can check
to see what's going wrong? Is my gut feeling that it's changing the file
type wrong? (IIUC, there are different open() calls for different size
files? No, I have nothing to base this one, just something I flashed on
and thought might explain the problem.)
I'm learning here guys, so please be gentle. You folks are the only ones I
have with the experience to tell me when I'm just fscked in the head and
when I'm bang on.
--
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation - Sunnyvale, CA
-
To unsubscribe from this
[OTP] SMP board recommendations?
Anyone have a recommendation for a motherboard for a homebased SMP box? I've tried the Abit VP6 and the MSI 6321 (694D Pro). Both give me the APIC errors with system lockups on heavy I/O using the 2.4.1-ac1# and the 2.4.2-pre# kernels. (The ac-## line doesn't die ANYWHERE near as often as the other board.) I'm looking into the i810 server board with the onboard SCSI controllers. I plan on installing either the Promise PDC20267 ATA100 controller or a Promise FastTrak RAID card (if they come in ATA100) since the only SCSI I have is the Yamaha 8424S SCSI CDR-W. Since this IS off topic of sorts, please reply to me privately. Thanks -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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/
[OTP] RE: Linux stifles innovation...
On Thu, 15 Feb 2001, Alan Olsen wrote: > I expect the next thing that will happen is that they will get patents on > key portions of their protocols and then start enforcing them. > They can only patent their own creations. I'd like to see them try to get patents for their "extensions" to TCP or some other bastardization they've made to the various standard protocols. They'd be isolating themselves out of the market in a heartbeat. Who would be willing to pay for their breaking of standards? Their existing user base perhaps but not many more than that, save the few companies that decided it was in their best interests to pay the fee. More than likely they'll kill their own market they go that route. > With the various IP laws that have been passed in the last few years in > the US (and through WIPO) they will have a large brick to try and hit us > with. (IMHO these laws pretty much allow large entities to buy their > markets and are the biggest threat to innovation out there.) > OK, WIPO? Never heard of it. Got a URL? > Actually I am sending copies of his rant out to all of my friends who > still use Microsoft products. > hehe, already done that. Got some GOOD feedback off of that. So far 5 of the 10 I've emailed have responded in rage. Don't know too many humans that take kindly to being politely called an idiot in public, which is basically what M$ has been saying. "You're an idiot if you use Linux because Linux stifles inovation. Thus you are a pawn of the Linux movement which makes you part of the threat to intellectual property (Read this as you are a part of the threat to my bottom line. > If that is the attitude they have towards their customers and the > development community then it is time to get away while you still can. > Microsoft relies rather heavily on the belief that their business model has locked their client base in. What they don't understand is that, the "movement" of Opensource as they so call it, will start to cost them even MORE money than we do now. Why? because as more people get pissed off at the mindframe of M$ and realize that there are comparable OpenSource products out there, they'll be leaving M$. Admittedly this will start out as a small trickle, taking place over the next say 2 years. Microsoft needs to wake up to the understanding that the only way they will survive if the "Linux movement" (their words not mine) gets ticked off enough to truly start a concerted effort to make open source based replacements for Microsoft products, is to play nice with Linux and OpenSource products in general, they're dead in the water. > Of course, the reason I moved over all my development to Linux in the > first place what that I did not have to worry about being screwed over by > a "corporate strategy" or have the license terms changed on the next > release or have to pay for something over and over again in the vain > attempt to get something to work. > I started with Linux in 94 because I thought it was a replacement for Windows. Even back then, when Linux was still a dog of a kernel, it seemed to exude power and inovation. (My personal belief so no one flame me for that line.) > With Linux I can read the source. There are no hidden interfaces. No > mystical archane knowledge that you have to pay the company to learn get > the job done. It is all there and it all works. (Or if it does not, then > the tools exist to make it work.) > Microsoft relies HEAVILY on the changes they've made in their product lines to hide details from the consumer, some of whom NEED to know those changes. This is just a case of a company that's chosen a business model that can't compete with it's exact opposite. They know it, we know it, and their advantage right now is that the general public DOESN'T know it. I do feel kind of sorry for Microsoft. Their attornies and marketing force must have tons of ulcers trying to figure out how to beat (not just co-exist with) a product that has no clearly defined (read suable) human owner, and that changes on an hourly basis like the sea changes the layout of the sand on a beach. Severely tough to fight something like that. > I wonder what kind of law they will try to push to outlaw Open Source? > > If this is his idea of "The American Way" then he needs to take a basic > civics course. He obviously slept through the last one. > He wasn't sleeping. He was down the hall in Corporate Raiding 101. David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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 stifles innovation...
Seriously though folks, look at who's doing this! They've already tried once to sue 'Linux', were told they couldn't because Linux is a non-entity (or at least one that they can not effectively sue due to the classification Linux holds), and now they can't use their second favorite tactic for stifling NON-M$ product lines. How? They can't BUY the linux code base OR any GPL's software to the point that they can bury it by buying and freezing the code from public use. We sort HAD to expect something like THIS to come. Though what DOES concern me is how effective this current ploy may be if they get ANY sort of backing from the government. (I doubt they will, but What If?) Let's hope EFF and FSF stay on their toes for this one. M$ doesn't have to win to really wipe our nose in stuff. They got the cash whereas we don't. ALTHOUGH, spending money to fight an idea or concept has never proven successful. And since the RESULTS of that idea or concept (in this case source code) are not suable AFAIK. So we got the upper hand there. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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 stifles innovation...
Seriously though folks, look at who's doing this! They've already tried once to sue 'Linux', were told they couldn't because Linux is a non-entity (or at least one that they can not effectively sue due to the classification Linux holds), and now they can't use their second favorite tactic for stifling NON-M$ product lines. How? They can't BUY the linux code base OR any GPL's software to the point that they can bury it by buying and freezing the code from public use. We sort HAD to expect something like THIS to come. Though what DOES concern me is how effective this current ploy may be if they get ANY sort of backing from the government. (I doubt they will, but What If?) Let's hope EFF and FSF stay on their toes for this one. M$ doesn't have to win to really wipe our nose in stuff. They got the cash whereas we don't. ALTHOUGH, spending money to fight an idea or concept has never proven successful. And since the RESULTS of that idea or concept (in this case source code) are not suable AFAIK. So we got the upper hand there. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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/
[OTP] RE: Linux stifles innovation...
On Thu, 15 Feb 2001, Alan Olsen wrote: I expect the next thing that will happen is that they will get patents on key portions of their protocols and then start enforcing them. They can only patent their own creations. I'd like to see them try to get patents for their "extensions" to TCP or some other bastardization they've made to the various standard protocols. They'd be isolating themselves out of the market in a heartbeat. Who would be willing to pay for their breaking of standards? Their existing user base perhaps but not many more than that, save the few companies that decided it was in their best interests to pay the fee. More than likely they'll kill their own market they go that route. With the various IP laws that have been passed in the last few years in the US (and through WIPO) they will have a large brick to try and hit us with. (IMHO these laws pretty much allow large entities to buy their markets and are the biggest threat to innovation out there.) OK, WIPO? Never heard of it. Got a URL? Actually I am sending copies of his rant out to all of my friends who still use Microsoft products. hehe, already done that. Got some GOOD feedback off of that. So far 5 of the 10 I've emailed have responded in rage. Don't know too many humans that take kindly to being politely called an idiot in public, which is basically what M$ has been saying. "You're an idiot if you use Linux because Linux stifles inovation. Thus you are a pawn of the Linux movement which makes you part of the threat to intellectual property (Read this as you are a part of the threat to my bottom line. If that is the attitude they have towards their customers and the development community then it is time to get away while you still can. Microsoft relies rather heavily on the belief that their business model has locked their client base in. What they don't understand is that, the "movement" of Opensource as they so call it, will start to cost them even MORE money than we do now. Why? because as more people get pissed off at the mindframe of M$ and realize that there are comparable OpenSource products out there, they'll be leaving M$. Admittedly this will start out as a small trickle, taking place over the next say 2 years. Microsoft needs to wake up to the understanding that the only way they will survive if the "Linux movement" (their words not mine) gets ticked off enough to truly start a concerted effort to make open source based replacements for Microsoft products, is to play nice with Linux and OpenSource products in general, they're dead in the water. Of course, the reason I moved over all my development to Linux in the first place what that I did not have to worry about being screwed over by a "corporate strategy" or have the license terms changed on the next release or have to pay for something over and over again in the vain attempt to get something to work. I started with Linux in 94 because I thought it was a replacement for Windows. Even back then, when Linux was still a dog of a kernel, it seemed to exude power and inovation. (My personal belief so no one flame me for that line.) With Linux I can read the source. There are no hidden interfaces. No mystical archane knowledge that you have to pay the company to learn get the job done. It is all there and it all works. (Or if it does not, then the tools exist to make it work.) Microsoft relies HEAVILY on the changes they've made in their product lines to hide details from the consumer, some of whom NEED to know those changes. This is just a case of a company that's chosen a business model that can't compete with it's exact opposite. They know it, we know it, and their advantage right now is that the general public DOESN'T know it. I do feel kind of sorry for Microsoft. Their attornies and marketing force must have tons of ulcers trying to figure out how to beat (not just co-exist with) a product that has no clearly defined (read suable) human owner, and that changes on an hourly basis like the sea changes the layout of the sand on a beach. Severely tough to fight something like that. I wonder what kind of law they will try to push to outlaw Open Source? If this is his idea of "The American Way" then he needs to take a basic civics course. He obviously slept through the last one. He wasn't sleeping. He was down the hall in Corporate Raiding 101. David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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/
[OTP] SMP board recommendations?
Anyone have a recommendation for a motherboard for a homebased SMP box? I've tried the Abit VP6 and the MSI 6321 (694D Pro). Both give me the APIC errors with system lockups on heavy I/O using the 2.4.1-ac1# and the 2.4.2-pre# kernels. (The ac-## line doesn't die ANYWHERE near as often as the other board.) I'm looking into the i810 server board with the onboard SCSI controllers. I plan on installing either the Promise PDC20267 ATA100 controller or a Promise FastTrak RAID card (if they come in ATA100) since the only SCSI I have is the Yamaha 8424S SCSI CDR-W. Since this IS off topic of sorts, please reply to me privately. Thanks -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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: [OTP] SMP board recommendations?
Thank you all for your response.
Andre (ASL), thanks for the assist. Laurie and Janine took care of me.
Asus CUV4X-D mobo with 1GB of buffered ECC RAM. I'm in the process of
transfering all the hardware to the new board. I'll let you know if this
new board solves the APIC errors and the random lockups under heavy I/O
problems.
I do have one more problem that I just can NOT track down.
2.4.1-ac10 kernel on the old Abit VP6 mobo. I'm getting curious errors
from the 2.4.1, 2.4.1-ac10, and 2.4.2-pre[#] kernels.
I've been using
dd if=/dev/zero of=/tmp/testdd.img bs=1024k count=1500
for testing of I/O on the various boards I have here. Now, the funny part
is that I get "file size limit exceeded" at around 1.0GB. I was getting
this under the 2.4.2-pre# kernels so i switched to straight 2.4.1 and got
the same problem. I switched to the 2.4.1-ac# line and the problem
disappeared. Guess what? It's baaacckk!
So, I did a strace of the dd command and got the following from it
execve("/bin/dd", ["dd", "if=/dev/zero", "of=/tmp/testing.img", "bs=1024k",
"count=1500"], [/* 22 vars */]) = 0
brk(0) = 0x804e7b8
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=7852, ...}) = 0
old_mmap(NULL, 7852, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0755, st_size=1183326, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\215"..., 4096) = 4096
old_mmap(NULL, 947548, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40017000
mprotect(0x400f7000, 30044, PROT_NONE) = 0
old_mmap(0x400f7000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xdf000) =
0x400f7000
old_mmap(0x400fb000, 13660, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x400fb000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x400ff000
mprotect(0x40017000, 917504, PROT_READ|PROT_WRITE) = 0
mprotect(0x40017000, 917504, PROT_READ|PROT_EXEC) = 0
munmap(0x40015000, 7852)= 0
personality(PER_LINUX) = 0
getpid()= 195
brk(0) = 0x804e7b8
brk(0x804e7f0) = 0x804e7f0
brk(0x804f000) = 0x804f000
open("/dev/zero", O_RDONLY|O_LARGEFILE) = 3
open("/tmp/testing.img", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x804ada8, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {0x804ada8, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {0x804ada8, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, {0x804ae70, [], 0x400}, NULL, 8) = 0
old_mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4010
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) =
1048576
* BIG ASS SNIP **
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = -1
EFBIG (File too large)
--- SIGXFSZ (File size limit exceeded) ---
+++ killed by SIGXFSZ +++
Now, notice the beginning file creation call. It starts out with
O_LARGEFILE but ends with EFBIG. Since I'm not totally familiar with the
kernel code I could be wrong on my next statement and if I am, please tell
me, but it looks like it changes the file creation call from LARGEFILE to
EFBIG (or is this just the error call itself?)
Now, the kernel is supposed to be able to handle creating a 4TB file(?),
so 1.0GB should be nothing to it. NOTHING changed betwen it working and
not working. No hardware changes, no software additions, no recompiles of
existing applications/daemons.. nothing.
So, my question is now one of "What gives?" Any clues on how I can check
to see what's going wrong? Is my gut feeling that it's changing the file
type wrong? (IIUC, there are different open() calls for different size
files? No, I have nothing to base this one, just something I flashed on
and thought might explain the problem.)
I'm learning here guys, so please be gentle. You folks are the only ones I
have with the experience to tell me when I'm just fscked in the head and
when I'm bang on.
--
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation - Sunnyvale, CA
-
To unsubscribe from this
Re: doing RAID 0 with HPT370
On Thu, 15 Feb 2001, Bradley Kite wrote: > I found this message while searching for a solution to getting > linux to see a raid array on my HPT370: > > http://www.mailgate.org/linux/linux.dev.raid/msg00163.html > > Its got someone from highpoint saying that raid support will > be offered "in the near future", and that message was dated October 2000. > > I emailed highpoint to ask if they had got any where, but they dont seem to > reply. > I've emailed them myself as this is the 2nd board I have with the HPT370 controller on it. HighPoint has not returned any of the 4 messages I've sent to them in the last 3 months. I don't know what their plans are but I do know I get the feeling they don't care to support Linux in any way shape or form. Feels like a pawn off job. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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/
MP-Table mappings
In my dmesg I'm getting duplicate table reservations. found SMP MP-table at 000f5770 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f1000 reserved twice. hm, page 000f2000 reserved twice. On node 0 totalpages: 262128 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 32752 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Is this an issue? David - 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: doing RAID 0 with HPT370
On Thu, 15 Feb 2001, Bradley Kite wrote: I found this message while searching for a solution to getting linux to see a raid array on my HPT370: http://www.mailgate.org/linux/linux.dev.raid/msg00163.html Its got someone from highpoint saying that raid support will be offered "in the near future", and that message was dated October 2000. I emailed highpoint to ask if they had got any where, but they dont seem to reply. I've emailed them myself as this is the 2nd board I have with the HPT370 controller on it. HighPoint has not returned any of the 4 messages I've sent to them in the last 3 months. I don't know what their plans are but I do know I get the feeling they don't care to support Linux in any way shape or form. Feels like a pawn off job. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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/
APIC problems
I asked for some information and seems at least 1 person took the "tone" of my email to mean I had an attitude while asking. On the premise that perhaps I did ask with an attitude, even if I don't see it, I'd like to ask for some information. Here is a synopsis of what I'm running up against and what I've done to try to fix it. I have the Abit VP6 mainboard loaded with 1GB of RAm and dual PIII-733s. On heavy I/O I get "APIC error on CPU# ##(##)" (replace #'s with CPUID# and APIC error code) In this case I'm getting 08(02) 04(08) 04(02) 02(04) 02(08) as the returned codes. Now the person that responded told me that it meant I had crap hardware. The Abit VP6 is an extremely popular board in the linux crowd from what I've been able to glean through IRC channels and other conversations. If the board was truly that bad, I have a hard time believing it would be as popular as it is. (OK, so this comment is subjective. :) ) Tracing back through the kernel code I found the list of error codes in apic.c. I'm specifically looking at function... asmlinkage smp_error_interrupt(void) >From what I understand of C, the error code returned is generated by a call to apic_read(APIC_ESR) which stores the value in 'v', sets the ESR register to 0 via the call to apic_write(APIC_ESR, 0);, regets the value via apic_read(APIC_ESR); yet again and stores that value in 'v1', acknowledges the IRQ service call, the APIC controller made, and finally increments the irq error count. It appears that it's using the modulus value as the actual error code. OK, so now that I know what the error code is but I still don't see how it can return a value of 08 which is not listed as an error code. I can see that the error codes are actually the values of ESR both before and after the apic_write() call. I see that the codes are the modulus'd value before and after the apic_write call. What I'm not understanding is how to translate that into a valid ID for determining what the exact error is. In this instance 08 doesn't appear to be a valid return. Or am I missing something here?? Here are the APIC errors APIC error on CPU0: 00(08) APIC error on CPU1: 00(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU0: 08(08) APIC error on CPU1: 08(02) APIC error on CPU1: 02(02) APIC error on CPU1: 02(08) APIC error on CPU0: 08(02) APIC error on CPU1: 08(01) APIC error on CPU0: 02(02) APIC error on CPU1: 01(02) APIC error on CPU0: 02(02) APIC error on CPU1: 02(04) APIC error on CPU1: 04(04) APIC error on CPU1: 04(02) APIC error on CPU1: 02(08) APIC error on CPU1: 08(02) APIC error on CPU1: 02(02) When I review my dmesg I see the following error as well. mapped IOAPIC to d000 (fec0) CALLIN, before setup_local_APIC(). ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-9, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not connected. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. ...: physical APIC id: 02 ... : IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail calibrating APIC timer ... PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I10,P0) -> 17 PCI->APIC IRQ transform: (B0,I12,P0) -> 19 PCI->APIC IRQ transform: (B0,I13,P0) -> 18 PCI->APIC IRQ transform: (B0,I14,P0) -> 18 PCI->APIC IRQ transform: (B1,I0,P0) -> 16 After about 50% completion of creating a 1.0GB file, the system will lock up with no errors or warnings. I can flip VTs, but if I try to log in it will not respond, nor will any commands like a simple ls -al $HOME/ The controller my drives sit on is the HPT370 ATA100/RAID controller Info is below HPT370: IDE controller on PCI bus 00 dev 70 HPT370: chipset revision 3 HPT370: not 100% native mode: will probe irqs later HPT370: ATA-66/100 forced bit set (WARNING)!! ide2: BM-DMA at 0xc800-0xc807, BIOS settings: hde:DMA, hdf:DMA HPT370: ATA-66/100 forced bit set (WARNING)!! ide3: BM-DMA at 0xc808-0xc80f, BIOS settings: hdg:DMA, hdh:pio hde: WDC WD300BB-00AUA1, ATA DISK drive hdf: WDC WD300BB-00AUA1, ATA DISK drive hdg: WDC WD300BB-00AUA1, ATA DISK drive ide2 at 0xb800-0xb807,0xbc02 on irq 18 ide3 at 0xc000-0xc007,0xc402 on irq 18 hde: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=58168/16/63, UDMA(100) hdf: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=58168/16/63, UDMA(100) hdg: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=58168/16/63, UDMA(100) I am not using the RAID ability, simply the ATA100. hdparm -t -T shows that my buffered disk reads sit at around 32MB/s. I get excellent speed on files smaller than 512MB. No lock ups, no problems. Go over the 512MB or thereabouts (sometimes it locks around
APIC problems
I asked for some information and seems at least 1 person took the "tone" of my email to mean I had an attitude while asking. On the premise that perhaps I did ask with an attitude, even if I don't see it, I'd like to ask for some information. Here is a synopsis of what I'm running up against and what I've done to try to fix it. I have the Abit VP6 mainboard loaded with 1GB of RAm and dual PIII-733s. On heavy I/O I get "APIC error on CPU# ##(##)" (replace #'s with CPUID# and APIC error code) In this case I'm getting 08(02) 04(08) 04(02) 02(04) 02(08) as the returned codes. Now the person that responded told me that it meant I had crap hardware. The Abit VP6 is an extremely popular board in the linux crowd from what I've been able to glean through IRC channels and other conversations. If the board was truly that bad, I have a hard time believing it would be as popular as it is. (OK, so this comment is subjective. :) ) Tracing back through the kernel code I found the list of error codes in apic.c. I'm specifically looking at function... asmlinkage smp_error_interrupt(void) From what I understand of C, the error code returned is generated by a call to apic_read(APIC_ESR) which stores the value in 'v', sets the ESR register to 0 via the call to apic_write(APIC_ESR, 0);, regets the value via apic_read(APIC_ESR); yet again and stores that value in 'v1', acknowledges the IRQ service call, the APIC controller made, and finally increments the irq error count. It appears that it's using the modulus value as the actual error code. OK, so now that I know what the error code is but I still don't see how it can return a value of 08 which is not listed as an error code. I can see that the error codes are actually the values of ESR both before and after the apic_write() call. I see that the codes are the modulus'd value before and after the apic_write call. What I'm not understanding is how to translate that into a valid ID for determining what the exact error is. In this instance 08 doesn't appear to be a valid return. Or am I missing something here?? Here are the APIC errors APIC error on CPU0: 00(08) APIC error on CPU1: 00(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU0: 08(08) APIC error on CPU1: 08(02) APIC error on CPU1: 02(02) APIC error on CPU1: 02(08) APIC error on CPU0: 08(02) APIC error on CPU1: 08(01) APIC error on CPU0: 02(02) APIC error on CPU1: 01(02) APIC error on CPU0: 02(02) APIC error on CPU1: 02(04) APIC error on CPU1: 04(04) APIC error on CPU1: 04(02) APIC error on CPU1: 02(08) APIC error on CPU1: 08(02) APIC error on CPU1: 02(02) When I review my dmesg I see the following error as well. mapped IOAPIC to d000 (fec0) CALLIN, before setup_local_APIC(). ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-9, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not connected. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. ...: physical APIC id: 02 ... : IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail calibrating APIC timer ... PCI-APIC IRQ transform: (B0,I7,P3) - 19 PCI-APIC IRQ transform: (B0,I7,P3) - 19 PCI-APIC IRQ transform: (B0,I10,P0) - 17 PCI-APIC IRQ transform: (B0,I12,P0) - 19 PCI-APIC IRQ transform: (B0,I13,P0) - 18 PCI-APIC IRQ transform: (B0,I14,P0) - 18 PCI-APIC IRQ transform: (B1,I0,P0) - 16 After about 50% completion of creating a 1.0GB file, the system will lock up with no errors or warnings. I can flip VTs, but if I try to log in it will not respond, nor will any commands like a simple ls -al $HOME/ The controller my drives sit on is the HPT370 ATA100/RAID controller Info is below HPT370: IDE controller on PCI bus 00 dev 70 HPT370: chipset revision 3 HPT370: not 100% native mode: will probe irqs later HPT370: ATA-66/100 forced bit set (WARNING)!! ide2: BM-DMA at 0xc800-0xc807, BIOS settings: hde:DMA, hdf:DMA HPT370: ATA-66/100 forced bit set (WARNING)!! ide3: BM-DMA at 0xc808-0xc80f, BIOS settings: hdg:DMA, hdh:pio hde: WDC WD300BB-00AUA1, ATA DISK drive hdf: WDC WD300BB-00AUA1, ATA DISK drive hdg: WDC WD300BB-00AUA1, ATA DISK drive ide2 at 0xb800-0xb807,0xbc02 on irq 18 ide3 at 0xc000-0xc007,0xc402 on irq 18 hde: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=58168/16/63, UDMA(100) hdf: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=58168/16/63, UDMA(100) hdg: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=58168/16/63, UDMA(100) I am not using the RAID ability, simply the ATA100. hdparm -t -T shows that my buffered disk reads sit at around 32MB/s. I get excellent speed on files smaller than 512MB. No lock ups, no problems. Go over the 512MB or thereabouts (sometimes it locks around 612-640MB), and
Re: 2.4.2-pre3
BTW, the kernel version is 2.4.2-pre3 (2.4.1 with patch-pre3 applied) NO other patches have been applied. I used hdparm v3.9 to set the params with. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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.2-pre3
APIC error on CPU0: 02(04) APIC error on CPU1: 08(08) APIC error on CPU0: 04(04) APIC error on CPU1: 08(08) APIC error on CPU0: 04(04) APIC error on CPU0: 04(04) APIC error on CPU1: 08(08) APIC error on CPU0: 04(04) APIC error on CPU1: 08(08) APIC error on CPU0: 04(04) scsi0 : AdvanSys SCSI 3.2M: PCI Ultra-Wide: BIOS C8000/7FFF, IO AC00/3F, IRQ 17 Vendor: YAMAHAModel: CRW8424S Rev: 1.0j Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0 sr0: scsi3-mmc drive: 24x/16x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.12 **POST NOTE** The scsi0 and APIC errors were not part of bootup. They came after the system was already up and running. Any info on the file size problem and the APIC errors would be appreciated. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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.2-pre3
: 08(08) APIC error on CPU0: 04(04) APIC error on CPU1: 08(08) APIC error on CPU0: 04(04) APIC error on CPU0: 04(04) APIC error on CPU1: 08(08) APIC error on CPU0: 04(04) APIC error on CPU1: 08(08) APIC error on CPU0: 04(04) scsi0 : AdvanSys SCSI 3.2M: PCI Ultra-Wide: BIOS C8000/7FFF, IO AC00/3F, IRQ 17 Vendor: YAMAHAModel: CRW8424S Rev: 1.0j Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0 sr0: scsi3-mmc drive: 24x/16x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.12 **POST NOTE** The scsi0 and APIC errors were not part of bootup. They came after the system was already up and running. Any info on the file size problem and the APIC errors would be appreciated. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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.2-pre3
BTW, the kernel version is 2.4.2-pre3 (2.4.1 with patch-pre3 applied) NO other patches have been applied. I used hdparm v3.9 to set the params with. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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: APIC errors with 2.4.2-pre1
OK, talked with someone who knows a little more about this than i do. According to him, one reason I may be getting these errors is due to the fact that the HPT370 controller is using IRQ18 which falls in the APIC extended IRQ range (16 - 31). If this is a problem is there a work-around? I don't know how to change the IRQ the HPT370 is using since it's an onboard card. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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/
APIC Errors with 2.4.2-pre1
First off, here's something from my dmesg. mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) CALLIN, before setup_local_APIC(). ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-9, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not connected. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. ...: physical APIC id: 02 ... : IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail calibrating APIC timer ... PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I10,P0) -> 17 PCI->APIC IRQ transform: (B0,I12,P0) -> 19 PCI->APIC IRQ transform: (B0,I13,P0) -> 18 PCI->APIC IRQ transform: (B0,I14,P0) -> 18 PCI->APIC IRQ transform: (B1,I0,P0) -> 16 Then whenever I do heavy CPU or RAM testing using something like cputest and ubench, I get the following errors in my log.. APIC error on CPU0: 00(08) APIC error on CPU1: 00(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU0: 08(08) APIC error on CPU1: 08(08) APIC error on CPU1: 08(08) APIC error on CPU0: 08(08) APIC error on CPU1: 08(02) APIC error on CPU1: 02(02) APIC error on CPU1: 02(08) APIC error on CPU0: 08(02) APIC error on CPU1: 08(01) APIC error on CPU0: 02(02) APIC error on CPU1: 01(02) APIC error on CPU0: 02(02) APIC error on CPU1: 02(04) APIC error on CPU1: 04(04) APIC error on CPU1: 04(02) APIC error on CPU1: 02(08) APIC error on CPU1: 08(02) APIC error on CPU1: 02(02) and on and on and on and on... I found the error codes in /usr/src/linux/arch/i386/kernel/apic.c. I could use a little help though on interpreting the error code(s) returned. Also, from the source code I see that apic_read(APIC_ESR) is called. In /usr/src/linux/include/asm/apicdef.h, I see that APIC_ESR is 0x280 which I take is the offset into the APIC_DEFAULT_PHYS_BASE. Since this is a controller, I'd like to know what the ##(##) represent. I take it that these numbers are the error code the controller reported just before and just after the apic_write(). To me it looks like this was done this way just to save state because the next thing called was the ack_APIC_irq(). Can someone also please explain what the ESR is? (Please forgive my ignorance of this stuff.) -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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: APIC errors with 2.4.2-pre1
OK, talked with someone who knows a little more about this than i do. According to him, one reason I may be getting these errors is due to the fact that the HPT370 controller is using IRQ18 which falls in the APIC extended IRQ range (16 - 31). If this is a problem is there a work-around? I don't know how to change the IRQ the HPT370 is using since it's an onboard card. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - 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: VT82C686A corruption with 2.4.x
Yeah, I'm seriously beginning to think it's a board specific issue. If I drop the RAM count down to 768MB I get far less drops in app deaths now. I'm living in Sunnyvale CA which is part of the Rolling Blackouts designated spots in CA. Ever since the power companies have been instituting this I've seen equipment that otherwise ran great all of a sudden start flaking. I've got this particular machine connected to a UPS so I figured the voltage regulation would be right on the money. Now, I'm not so sure since a number of people have brought this up. I'm going to drop her down to 768MB and then try a 128MB DIMM in there. I want to see if it can handle that. Since the 128s have less draw than the 256s do, maybe this will work. Right now I've got the full 1GB in there. What I'm seeing now is application deaths, occational X11 lockups, but SUPRIZE! SUPRIZE! no more drive corruptions since I removed the DMA flag from the drives, disabled DMA use in the BIOS and replaced the ATA66 cable with an ATA33. For everyone out there that's assisted in tracking this down and assisted in getting a working fix going.. .THANK YOU! For now, I'm going to have to play keep in step with the kernel, patches, and the VIA driver. Voj, can you directly add me to whatever ANNOUNCE list you use for announcing the latest release of the driver? Once again thanks folks. It's still not totally stable here, but it's a DAMN sight farther than it was before. While not TOTALLY convinced that it's a local hardware issue, I do thank folks for their 2 cents. :-) On Wed, 31 Jan 2001, David Riley wrote: > Mark Hahn wrote: > > > > >>From what I gather this chipset on 2.4.x is only stable if you cripple just >about everything that makes > > > it worth having (udma, 2nd ide channel etc etc) ?does it even work when >all that's done now or is > > > it fully functional? > > > > it seems to be fully functional for some or most people, > > with two, apparently, reporting major problems. > > > > my via (kt133) is flawless in 2.4.1 (a drive on each channel, > > udma enabled and in use) and has for all the 2.3's since I got it. > > Not to make a "mee too" post but... > > It's worked flawlessly for me. Always. Since it seems to work fine for > just about everyone else, I'd venture to say that it's a board specific > issue, quite likely with the BIOS. Some other problems seem to have to > do with the memory; I remember the KX133 had some definite problems with > memory timing, especially with large amounts (3 DIMMS were a problem on > some motherboards that were loosely laid out). > > My 2 cents, > David > - > 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/ > - 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: VT82C686A corruption with 2.4.x
Yeah, I'm seriously beginning to think it's a board specific issue. If I drop the RAM count down to 768MB I get far less drops in app deaths now. I'm living in Sunnyvale CA which is part of the Rolling Blackouts designated spots in CA. Ever since the power companies have been instituting this I've seen equipment that otherwise ran great all of a sudden start flaking. I've got this particular machine connected to a UPS so I figured the voltage regulation would be right on the money. Now, I'm not so sure since a number of people have brought this up. I'm going to drop her down to 768MB and then try a 128MB DIMM in there. I want to see if it can handle that. Since the 128s have less draw than the 256s do, maybe this will work. Right now I've got the full 1GB in there. What I'm seeing now is application deaths, occational X11 lockups, but SUPRIZE! SUPRIZE! no more drive corruptions since I removed the DMA flag from the drives, disabled DMA use in the BIOS and replaced the ATA66 cable with an ATA33. For everyone out there that's assisted in tracking this down and assisted in getting a working fix going.. .THANK YOU! For now, I'm going to have to play keep in step with the kernel, patches, and the VIA driver. Voj, can you directly add me to whatever ANNOUNCE list you use for announcing the latest release of the driver? Once again thanks folks. It's still not totally stable here, but it's a DAMN sight farther than it was before. While not TOTALLY convinced that it's a local hardware issue, I do thank folks for their 2 cents. :-) On Wed, 31 Jan 2001, David Riley wrote: Mark Hahn wrote: From what I gather this chipset on 2.4.x is only stable if you cripple just about everything that makes it worth having (udma, 2nd ide channel etc etc) ?does it even work when all that's done now or is it fully functional? it seems to be fully functional for some or most people, with two, apparently, reporting major problems. my via (kt133) is flawless in 2.4.1 (a drive on each channel, udma enabled and in use) and has for all the 2.3's since I got it. Not to make a "mee too" post but... It's worked flawlessly for me. Always. Since it seems to work fine for just about everyone else, I'd venture to say that it's a board specific issue, quite likely with the BIOS. Some other problems seem to have to do with the memory; I remember the KX133 had some definite problems with memory timing, especially with large amounts (3 DIMMS were a problem on some motherboards that were loosely laid out). My 2 cents, David - 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/ - 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: VT82C686A corruption with 2.4.x
rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
hdparm -i /dev/hdc outputs
/dev/hdc:
Model=WDC WD153AA, FwRev=05.05B05, SerialNo=WD-WMA0R1258522
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=30064608
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
cat /proc/ide/via outputs
--VIA BusMastering IDE Configuration
Driver Version: 3.20
South Bridge: VIA vt82c686a
Revision: ISA 0x22 IDE 0x10
BM-DMA base:0xb000
PCI clock: 33MHz
Master Read Cycle IRDY:1ws
Master Write Cycle IRDY:1ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: no no
Post Write Buffer: no no
Enabled: yes yes
Simplex only: no no
Cable Type: 40w 40w
---drive0drive1drive2drive3-
Transfer Mode: UDMA PIO UDMA PIO
Address Setup: 30ns 120ns 30ns 120ns
Cmd Active: 90ns 90ns 90ns 90ns
Cmd Recovery:30ns 30ns 30ns 30ns
Data Active: 90ns 330ns 90ns 330ns
Data Recovery: 30ns 270ns 30ns 270ns
Cycle Time: 60ns 600ns 60ns 600ns
Transfer Rate: 33.0MB/s 3.3MB/s 33.0MB/s 3.3MB/s
Other than this I don't know what else to give you.
David D.W. Downey
-
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: VT82C686A corruption with 2.4.x
Model=WDC WD153AA, FwRev=05.05B05, SerialNo=WD-WMA0R1258522
Config={ HardSect NotMFM HdSw15uSec SpinMotCtl Fixed DTR5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=30064608
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
cat /proc/ide/via outputs
--VIA BusMastering IDE Configuration
Driver Version: 3.20
South Bridge: VIA vt82c686a
Revision: ISA 0x22 IDE 0x10
BM-DMA base:0xb000
PCI clock: 33MHz
Master Read Cycle IRDY:1ws
Master Write Cycle IRDY:1ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: no no
Post Write Buffer: no no
Enabled: yes yes
Simplex only: no no
Cable Type: 40w 40w
---drive0drive1drive2drive3-
Transfer Mode: UDMA PIO UDMA PIO
Address Setup: 30ns 120ns 30ns 120ns
Cmd Active: 90ns 90ns 90ns 90ns
Cmd Recovery:30ns 30ns 30ns 30ns
Data Active: 90ns 330ns 90ns 330ns
Data Recovery: 30ns 270ns 30ns 270ns
Cycle Time: 60ns 600ns 60ns 600ns
Transfer Rate: 33.0MB/s 3.3MB/s 33.0MB/s 3.3MB/s
Other than this I don't know what else to give you.
David D.W. Downey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
On Tue, 30 Jan 2001, Byron Stanoszek wrote: > (unless you're overclocking). Setting it to 66 will cause the VIA driver to > believe your PCI bus is running at 66MHz and will program the IDE controller to > run at half the speed to maintain 33MHz. In reality, your controller now runs > at 16. I removed the ide and ata setting. System is running stably as in no kernel crashes, but I am getting daemon and shell crashes. With this current kernel I've had 1 kernel crash in about 3 hours as compared to 1 every 10 or 15 minutes. Crash, reboot, 10 minutes or so crash, reboot. ect ect. I'm wanting to test something else out. I'm wondering if there isn't some hardware issue with the RAM. This particular board will do 1GB of PC133, or 2.5GB of PC100. I'm wondering if there isn't something wrong with how it reads the speed and the appropriate limitation. It's running stably if I only run 768MB of PC133 RAM. But if I run a solid 1GB of PC133 I get segfaults and sig11 crashes constantly. All the RAM has been professionally tested and certified. Any clues would be appreciated. David - 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/
VIA VT82C686X
Woohoo! Just found out that ATA66 on the VIA aint too great. I set the kernel boot options idebus=66 ide0=ata66 enabling ATA66 according to dmesg. The HDD is a WDC UDMA100 30.5GB drive. I retried the dd if=/dev/hda7 of=/tmp/testing2.img bs=1024k count=2000 on one VT, ran renice -20 on the dd process then ran procinfo on another and top on a 3rd. I logged into a fourth and ran sync;sync;sync;sync;sync. After @30 seconds the machine became totally unresponsive, locking up all but the current VT. I let it sit there and waited until the dd finished in case the renice was what killed the control. When dd finished I tried running any type of command but the tty was completely frozen. All other VTs were non responsive as well. This is gonna be fun when I test the Promise controller. hehe David D.W. Downey - 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: VT82C686A corruption with 2.4.x
OK, just completed the upgrade to 2.4.1-pre12 + via82c.diff. SYSTEM SPECS CHANGES === Shut off ACPI Shut off 2nd IDE controller in BIOS Shut off APM Disabled UDMA support in BIOS Removed 256MB RAM (768M total RAM) * Everything is running stabler now. Here's what I've got set up right now. VIA SUPPORT 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at a000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 I/O ports at b000 I/O ports at b400 I/O ports at b800 I/O ports at bc00 Memory at db00 (32-bit, non-prefetchable) Capabilities: [58] Power Management version 1 00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Flags: bus master, medium devsel, latency 32, IRQ 15 I/O ports at c000 Memory at db02 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at c400 Memory at db021000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Flags: 66Mhz, fast devsel Memory at d400 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) I/O ports at 9000 Capabilities: [54] AGP version 1.0 Capabilities: [60] Power Management version 1 PROMISE SUPPORT === PDC20265: IDE controller on PCI bus 00 dev 60 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. DMESG - VIA == PCI: Using IRQ router VIA [1106/0686] at 00:07.0 System Vendor: VIA Technologies, Inc.. VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB DD TESTING == [root@timberwolf /root]# dd if=/dev/hda7 of=/tmp/testing.img bs=1024k count=20002000+0 records in 2000+0 records out [root@timberwolf /root]# ls -al /tmp/testing.img -rw-r--r--1 root root 2097152000 Jan 29 17:54 /tmp/testing.img [root@timberwolf /root]# ls -alh /tmp/testing.img -rw-r--r--1 root root 2.0G Jan 29 17:54 /tmp/testing.img [root@timberwolf /root]# I'm also attaching a ksyms dump. David D.W. Downey Address SymbolDefined by f286a060 advansys_proc_info[advansys] f286a060 __insmod_advansys_S.text_L60896 [advansys] f286caf0 advansys_reset[advansys] f286c770 advansys_abort[advansys] f286c660 advansys_command [advansys] f286a58c advansys_detect [advansys] f286d084 advansys_biosparam[advansys] f287b0e0 __insmod_advansys_S.data_L15488 [advansys] f287ef00 __insmod_advansys_S.bss_L128 [advansys] f2878e60 __insmod_advansys_S.rodata_L8808 [advansys] f286c350 advansys_release [advansys] f286c698 advansys_queuecommand [advansys] f286a000 __insmod_advansys_O/lib/modules/2.4.1-pre12/kernel/drivers/scsi/advansys.o_M3A761A3A_V132097 [advansys] f286c444 advansys_info [advansys] f286d10c advansys_setup
Re: VT82C686A corruption with 2.4.x
OK, here is the output of lspci -v on the SMP box I'm having trouble with as requested... 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at a000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 I/O ports at b000 I/O ports at b400 I/O ports at b800 I/O ports at bc00 Memory at db00 (32-bit, non-prefetchable) Capabilities: [58] Power Management version 1 00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Flags: bus master, medium devsel, latency 32, IRQ 15 I/O ports at c000 Memory at db02 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at c400 Memory at db021000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Flags: 66Mhz, fast devsel Memory at d400 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) I/O ports at 9000 Capabilities: [54] AGP version 1.0 Capabilities: [60] Power Management version 1 - 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: VT82C686A corruption with 2.4.x
Actually what rumors are you hearing? Right now I can tell you from personal experience that the VIA VT82C686A chipset is causing kernel deaths, corrupted data on my drives, and UDMA issues (meaning that when I enable the UDMA support the kernel CONSISTENTLY crashes.) This is all pre patch-2.4.1-pre11. I've not tested the new patch as of yet as I was in a car accident and have not felt well enough to mess with things. I will however be testing the new patch in about a half hour. The test bed will be the SMP box I've been talking about on the list, Red Hat 7.0 (only one that will install on the machine without dying instantly during installation) and using the KGCC rather than the GCC that comes with RH7. Supposedly there are a couple of other patches available to add as well, but I'm not sure where they are exactly. I just downloaded the patch that Voj gave (v3.20) for the VIA chipsets. Nicholas, give me a bit and I'll let you know what's going on with my tests here. I can consistently get the current kernel to die simply by running dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k TRy this on your box with the patch-2.4.1-pre11 added to the kernel source and let me know what you get. Maybe we can work on this together. David D.W. Downey On Tue, 30 Jan 2001, Tobias Ringstrom wrote: > So you have not seen any corruption, but are willing to do testing. Very > kind, but you could have choosen a better subject, I think. There are a > lot more rumours that facts regarding the VIA drivers right now. > > /Tobias > > > On Tue, 30 Jan 2001, Nicholas Knight wrote: > > > I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon > > CPU in it. > > So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my > > P3 using a propriatory micron motherboard that uses an intel BX2 chipset. > > However, I recently trashed my linux installation (doing things totaly > > unrelated to the kernel) and now would be more than happy to assist in > > trying to figure out what the heck is causing the filesystem corruption on > > VIA chipsets, but so far I've only found bits and peices of information on > > it, and have been unable to locate a compiliation of information avalible on > > the problem, so I'd know just where to start. > > If anyone could point me to a good place to start looking, besides the > > thousands of messages containing just bits and peices of information, I > > could get to work on some testing. > > - > 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/ > - 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: VT82C686A corruption with 2.4.x
Actually what rumors are you hearing? Right now I can tell you from personal experience that the VIA VT82C686A chipset is causing kernel deaths, corrupted data on my drives, and UDMA issues (meaning that when I enable the UDMA support the kernel CONSISTENTLY crashes.) This is all pre patch-2.4.1-pre11. I've not tested the new patch as of yet as I was in a car accident and have not felt well enough to mess with things. I will however be testing the new patch in about a half hour. The test bed will be the SMP box I've been talking about on the list, Red Hat 7.0 (only one that will install on the machine without dying instantly during installation) and using the KGCC rather than the GCC that comes with RH7. Supposedly there are a couple of other patches available to add as well, but I'm not sure where they are exactly. I just downloaded the patch that Voj gave (v3.20) for the VIA chipsets. Nicholas, give me a bit and I'll let you know what's going on with my tests here. I can consistently get the current kernel to die simply by running dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k TRy this on your box with the patch-2.4.1-pre11 added to the kernel source and let me know what you get. Maybe we can work on this together. David D.W. Downey On Tue, 30 Jan 2001, Tobias Ringstrom wrote: So you have not seen any corruption, but are willing to do testing. Very kind, but you could have choosen a better subject, I think. There are a lot more rumours that facts regarding the VIA drivers right now. /Tobias On Tue, 30 Jan 2001, Nicholas Knight wrote: I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon CPU in it. So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my P3 using a propriatory micron motherboard that uses an intel BX2 chipset. However, I recently trashed my linux installation (doing things totaly unrelated to the kernel) and now would be more than happy to assist in trying to figure out what the heck is causing the filesystem corruption on VIA chipsets, but so far I've only found bits and peices of information on it, and have been unable to locate a compiliation of information avalible on the problem, so I'd know just where to start. If anyone could point me to a good place to start looking, besides the thousands of messages containing just bits and peices of information, I could get to work on some testing. - 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/ - 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: VT82C686A corruption with 2.4.x
OK, here is the output of lspci -v on the SMP box I'm having trouble with as requested... 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at a000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 I/O ports at b000 I/O ports at b400 I/O ports at b800 I/O ports at bc00 Memory at db00 (32-bit, non-prefetchable) Capabilities: [58] Power Management version 1 00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Flags: bus master, medium devsel, latency 32, IRQ 15 I/O ports at c000 Memory at db02 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at c400 Memory at db021000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Flags: 66Mhz, fast devsel Memory at d400 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) I/O ports at 9000 Capabilities: [54] AGP version 1.0 Capabilities: [60] Power Management version 1 - 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: VT82C686A corruption with 2.4.x
OK, just completed the upgrade to 2.4.1-pre12 + via82c.diff. SYSTEM SPECS CHANGES === Shut off ACPI Shut off 2nd IDE controller in BIOS Shut off APM Disabled UDMA support in BIOS Removed 256MB RAM (768M total RAM) * Everything is running stabler now. Here's what I've got set up right now. VIA SUPPORT 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at a000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 I/O ports at b000 I/O ports at b400 I/O ports at b800 I/O ports at bc00 Memory at db00 (32-bit, non-prefetchable) Capabilities: [58] Power Management version 1 00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Flags: bus master, medium devsel, latency 32, IRQ 15 I/O ports at c000 Memory at db02 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at c400 Memory at db021000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Flags: 66Mhz, fast devsel Memory at d400 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) I/O ports at 9000 Capabilities: [54] AGP version 1.0 Capabilities: [60] Power Management version 1 PROMISE SUPPORT === PDC20265: IDE controller on PCI bus 00 dev 60 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. DMESG - VIA == PCI: Using IRQ router VIA [1106/0686] at 00:07.0 System Vendor: VIA Technologies, Inc.. VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB DD TESTING == [root@timberwolf /root]# dd if=/dev/hda7 of=/tmp/testing.img bs=1024k count=20002000+0 records in 2000+0 records out [root@timberwolf /root]# ls -al /tmp/testing.img -rw-r--r--1 root root 2097152000 Jan 29 17:54 /tmp/testing.img [root@timberwolf /root]# ls -alh /tmp/testing.img -rw-r--r--1 root root 2.0G Jan 29 17:54 /tmp/testing.img [root@timberwolf /root]# I'm also attaching a ksyms dump. David D.W. Downey Address SymbolDefined by f286a060 advansys_proc_info[advansys] f286a060 __insmod_advansys_S.text_L60896 [advansys] f286caf0 advansys_reset[advansys] f286c770 advansys_abort[advansys] f286c660 advansys_command [advansys] f286a58c advansys_detect [advansys] f286d084 advansys_biosparam[advansys] f287b0e0 __insmod_advansys_S.data_L15488 [advansys] f287ef00 __insmod_advansys_S.bss_L128 [advansys] f2878e60 __insmod_advansys_S.rodata_L8808 [advansys] f286c350 advansys_release [advansys] f286c698 advansys_queuecommand [advansys] f286a000 __insmod_advansys_O/lib/modules/2.4.1-pre12/kernel/drivers/scsi/advansys.o_M3A761A3A_V132097 [advansys] f286c444 advansys_info [advansys] f286d10c advansys_setup
VIA VT82C686X
Woohoo! Just found out that ATA66 on the VIA aint too great. I set the kernel boot options idebus=66 ide0=ata66 enabling ATA66 according to dmesg. The HDD is a WDC UDMA100 30.5GB drive. I retried the dd if=/dev/hda7 of=/tmp/testing2.img bs=1024k count=2000 on one VT, ran renice -20 on the dd process then ran procinfo on another and top on a 3rd. I logged into a fourth and ran sync;sync;sync;sync;sync. After @30 seconds the machine became totally unresponsive, locking up all but the current VT. I let it sit there and waited until the dd finished in case the renice was what killed the control. When dd finished I tried running any type of command but the tty was completely frozen. All other VTs were non responsive as well. This is gonna be fun when I test the Promise controller. hehe David D.W. Downey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT82C686X
On Tue, 30 Jan 2001, Byron Stanoszek wrote: (unless you're overclocking). Setting it to 66 will cause the VIA driver to believe your PCI bus is running at 66MHz and will program the IDE controller to run at half the speed to maintain 33MHz. In reality, your controller now runs at 16. I removed the ide and ata setting. System is running stably as in no kernel crashes, but I am getting daemon and shell crashes. With this current kernel I've had 1 kernel crash in about 3 hours as compared to 1 every 10 or 15 minutes. Crash, reboot, 10 minutes or so crash, reboot. ect ect. I'm wanting to test something else out. I'm wondering if there isn't some hardware issue with the RAM. This particular board will do 1GB of PC133, or 2.5GB of PC100. I'm wondering if there isn't something wrong with how it reads the speed and the appropriate limitation. It's running stably if I only run 768MB of PC133 RAM. But if I run a solid 1GB of PC133 I get segfaults and sig11 crashes constantly. All the RAM has been professionally tested and certified. Any clues would be appreciated. David - 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: [ANNOUNCE] Kernel Janitor's TODO list
On Mon, 29 Jan 2001, John Levon wrote: > huh ? > > http://www.kernelnewbies.org/books.php3 > > /usr/src/linux-2.4/Documentation/DocBook > > /usr/src/linux/* > > try the last one on Windows. Please get your facts at least remotely near > the truth before you rant on linux-kernel again > > john > > Umm, john.. He IS right. I've been following the linux kernel list for QUITE some time, though actively asking questions on it for the last 2 months. I've read through the docs in /usr/src/linux/Documentation/* and i hear one more person tell me to "read the source" I'll go nuts. SOURCE CODE ONLY MAKES SENSE TO THOSE THAT EITHER WROTE IT OR WORK WITH IT EVERYDAY! And don't tell me "Well, then you shouldn't be touching the kernel if you're not a developer" because that's crap too. Simply put, with all bitterness and finger pointing aside, WHERE do we find information on various kernel functions, their general usage (as in the WHY, not only the HOW) and reasonings on why not to use some vs. others. Remember, most of you guys have been coding for years, or working on the kernel for years. Some of us don't have that level of expertise, are trying to get it, and feel like we're being told that information is a private domain we aren't allowed in to. Me personally, I'd be happy with a list of all the finctions in the linux kernel, a brief description of their usage and a singl elink on where to find more info about that particular function. Just my 2 cents worth. David D.W. Downey - 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: [ANNOUNCE] Kernel Janitor's TODO list
On Mon, 29 Jan 2001, John Levon wrote: huh ? http://www.kernelnewbies.org/books.php3 /usr/src/linux-2.4/Documentation/DocBook /usr/src/linux/* try the last one on Windows. Please get your facts at least remotely near the truth before you rant on linux-kernel again john Umm, john.. He IS right. I've been following the linux kernel list for QUITE some time, though actively asking questions on it for the last 2 months. I've read through the docs in /usr/src/linux/Documentation/* and i hear one more person tell me to "read the source" I'll go nuts. SOURCE CODE ONLY MAKES SENSE TO THOSE THAT EITHER WROTE IT OR WORK WITH IT EVERYDAY! And don't tell me "Well, then you shouldn't be touching the kernel if you're not a developer" because that's crap too. Simply put, with all bitterness and finger pointing aside, WHERE do we find information on various kernel functions, their general usage (as in the WHY, not only the HOW) and reasonings on why not to use some vs. others. Remember, most of you guys have been coding for years, or working on the kernel for years. Some of us don't have that level of expertise, are trying to get it, and feel like we're being told that information is a private domain we aren't allowed in to. Me personally, I'd be happy with a list of all the finctions in the linux kernel, a brief description of their usage and a singl elink on where to find more info about that particular function. Just my 2 cents worth. David D.W. Downey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
Nevermind. I found it. It's actually residing in /pub/linux/kernel/testing/ and NOT in /pub/linux/kernel/v2.4/ or it's subdirs. David D.W. Downey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
> Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz > I'm on ftp.kernel.org right this second in /pub/linux/kernel/v2.4/ There is only a test-kernels/ subdir there, not a test/ test-kernels/ does not contain the patch. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
Hi Linus, Sorry to bother you. I'm trying to find where you uploaded linux-2.4.1-pre11. I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/ directories. Is it somewhere different? Also, Alan, I grabbed your patch-2.4.0-ac11.gz file from your directory on ftp.kernel.org. Does this contain the updated VIA IDE support that Linus was talking about in the 2.4.1-pre11? I'm thinking either kernel.org hasn't posted the 2.4.1-pre11 or I totally misunderstand the directory layout on kernel.org. A URL to the right patch or, preferably, full source for 2.4.1-pre11 would be great. Thanks, David D.W. Downey On Sun, 28 Jan 2001, Linus Torvalds wrote: > > I just uploaded it to kernel.org, and I expect that I'll do the final > 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the > pre-kernel works for you.. > > The main noticeable things in pre11 are fixing some bugs that crept in > after 2.4.0 - the block device queuing improvements could lose wakeups > under extreme load by multiple clients, and the vmscanning "get rid of > special return codes for shared memory" thing had missed a bit. > > This should also fix the VIA IDE driver issues (if you want safe, do NOT > enable auto-dma), and the reported problems with hpt366 controllers and > IBM drives. Hopefully these were the last major IDE issues for a while. > > Also, can people who have had unhappy relationships with their eepro100 > please try to cuddle and make up again? The eepro100 changes should fix > the problem of having posted writes that basically made some of the timing > not work out. > > Linus > > - > pre11: > - Trond Myklebust: NFS/RPC client SMP fixes > - rth: alpha pyxis and cabriolet fixes > - remove broken sys_wait4() declarations > - disable radeon debugging code > - VIA IDE driver should not enable autodma unless asked for > - Andrey Savochkin: eepro100 update. Should fix the resource timing problems. > - Jeff Garzik: via82cxxx_audio update > - YMF7xx PCI audio update: get rid of old broken driver, make new >driver handle legacy control too. > - fix missed wakeup on block device request list > - hpt366 controller doesn't play nice with some IBM harddisks > - remove inode pages from the page cache only after having removed them >from the page tables. > - shared memory out-of-swap writepage() fixup (no more magic return) > > pre10: > - got a few too-new R128 #defines in the Radeon merge. Fix. > - tulip driver update from Jeff Garzik > - more cpq and DAC elevator fixes from Jens. Looks good. > - Petr Vandrovec: nicer ncpfs behaviour > - Andy Grover: APCI update > - Cort Dougan: PPC update > - David Miller: sparc updates > - David Miller: networking updates > - Neil Brown: RAID5 fixes > > pre9: > - cpq array driver elevator fixes > - merge radeon driver from X CVS tree > - ispnp cleanups > - emu10k unlock on error fixes > - hpfs doesn't allow truncate to larger > > pre8: > - Don't drop a megabyte off the old-style memory size detection > - remember to UnlockPage() in ramfs_writepage() > - 3c59x driver update from Andrew Morton > - egcs-1.1.2 miscompiles depca: workaround by Andrew Morton > - dmfe.c module init fix: Andrew Morton > - dynamic XMM support. Andrea Arkangeli. > - ReiserFS merge > - USB hotplug updates/fixes > - boots on real i386 machines > - blk-14 from Jens Axboe > - fix DRM R128/AGP dependency > - fix n_tty "canon" mode SMP race > - ISDN fixes > - ppp UP deadlock attack fix > - FAT fat_cache SMP race fix > - VM balancing tuning > - Locked SHM segment deadlock fix > - fork() page table copy race fix > > - > 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/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
Hi Linus, Sorry to bother you. I'm trying to find where you uploaded linux-2.4.1-pre11. I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/ directories. Is it somewhere different? Also, Alan, I grabbed your patch-2.4.0-ac11.gz file from your directory on ftp.kernel.org. Does this contain the updated VIA IDE support that Linus was talking about in the 2.4.1-pre11? I'm thinking either kernel.org hasn't posted the 2.4.1-pre11 or I totally misunderstand the directory layout on kernel.org. A URL to the right patch or, preferably, full source for 2.4.1-pre11 would be great. Thanks, David D.W. Downey On Sun, 28 Jan 2001, Linus Torvalds wrote: I just uploaded it to kernel.org, and I expect that I'll do the final 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the pre-kernel works for you.. The main noticeable things in pre11 are fixing some bugs that crept in after 2.4.0 - the block device queuing improvements could lose wakeups under extreme load by multiple clients, and the vmscanning "get rid of special return codes for shared memory" thing had missed a bit. This should also fix the VIA IDE driver issues (if you want safe, do NOT enable auto-dma), and the reported problems with hpt366 controllers and IBM drives. Hopefully these were the last major IDE issues for a while. Also, can people who have had unhappy relationships with their eepro100 please try to cuddle and make up again? The eepro100 changes should fix the problem of having posted writes that basically made some of the timing not work out. Linus - pre11: - Trond Myklebust: NFS/RPC client SMP fixes - rth: alpha pyxis and cabriolet fixes - remove broken sys_wait4() declarations - disable radeon debugging code - VIA IDE driver should not enable autodma unless asked for - Andrey Savochkin: eepro100 update. Should fix the resource timing problems. - Jeff Garzik: via82cxxx_audio update - YMF7xx PCI audio update: get rid of old broken driver, make new driver handle legacy control too. - fix missed wakeup on block device request list - hpt366 controller doesn't play nice with some IBM harddisks - remove inode pages from the page cache only after having removed them from the page tables. - shared memory out-of-swap writepage() fixup (no more magic return) pre10: - got a few too-new R128 #defines in the Radeon merge. Fix. - tulip driver update from Jeff Garzik - more cpq and DAC elevator fixes from Jens. Looks good. - Petr Vandrovec: nicer ncpfs behaviour - Andy Grover: APCI update - Cort Dougan: PPC update - David Miller: sparc updates - David Miller: networking updates - Neil Brown: RAID5 fixes pre9: - cpq array driver elevator fixes - merge radeon driver from X CVS tree - ispnp cleanups - emu10k unlock on error fixes - hpfs doesn't allow truncate to larger pre8: - Don't drop a megabyte off the old-style memory size detection - remember to UnlockPage() in ramfs_writepage() - 3c59x driver update from Andrew Morton - egcs-1.1.2 miscompiles depca: workaround by Andrew Morton - dmfe.c module init fix: Andrew Morton - dynamic XMM support. Andrea Arkangeli. - ReiserFS merge - USB hotplug updates/fixes - boots on real i386 machines - blk-14 from Jens Axboe - fix DRM R128/AGP dependency - fix n_tty "canon" mode SMP race - ISDN fixes - ppp UP deadlock attack fix - FAT fat_cache SMP race fix - VM balancing tuning - Locked SHM segment deadlock fix - fork() page table copy race fix - 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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz I'm on ftp.kernel.org right this second in /pub/linux/kernel/v2.4/ There is only a test-kernels/ subdir there, not a test/ test-kernels/ does not contain the patch. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
Nevermind. I found it. It's actually residing in /pub/linux/kernel/testing/ and NOT in /pub/linux/kernel/v2.4/ or it's subdirs. David D.W. Downey - 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: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
LOL, I'm in Sunnyvale, CA right now. I work for Ensim.Com. OK, here is all the technical info on my box. Sorry it took so long to respond. Had a department meeting to attend. MSI 694D Pro running Dual FC-PGA PIII-733 CPUs with 1GB of Corsair RAM. HDD is a Western Digital WDC300BB-00AU1 ATA100 drive (running it on the VIA controlled ATA33/66 controller since the kernel doesn't support the ATA100 very well.) Chipsets are the VIA VT82C686A and the Promise PDC20265 NIC is a NetGear FA-310TX Advansys UW SCSI Card Yamaha CRW8424S CDRW Voodoo3 2000 AGP 16MB AGP video card. APM/ACPI turned OFF in BIOS, NOT using the ATA100 controller Symptoms: Consistantly recurring kernel deaths resulting in hard lock of box. On Thu, 25 Jan 2001, Andre Hedrick wrote: > > Where the flip are you form this power starved portion of the world? > Also the subject is AMD and VIA chipsets not AMD CPU's running on VIA > chipsets. > > What chipset or host is causing you the problem? > > VIA pr Promise? > > On Thu, 25 Jan 2001, David D.W. Downey wrote: > > > > > > > OK, I see you guys releasing patches for the AMD + VIA problem, but this > > problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s > > and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When > > are we going to see something for the MSI boards? > > > > My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset > > and the Promise PDC20265 ATA100 onbard controller. > > > > I need some sort of help with this. I'm getting kernel deaths left and > > right and no hope in sight here. > > > > I though it might possibly be a mix of SCSI + IDE causing troubles so I > > borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys > > SCSI card (not sure of the make offhand. I can find the box when I get > > home as I'm at work right now.) > > > > I would code up a fix if I knew what the hell I was doing when it came to > > coding which I do NOT. > > > > Vojtech, can you please work with me on this issue? Or if you are too > > busy, can you put me in contact with someone who can help? I've got a > > $3000 machine sitting here that I can not do a damn thing with until I > > stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation > > not at the kernel or anyone involved with the VIA stuff. Please don't take > > it that way.) > > > > David Downey > > > > > > - > > 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/ > > > > Andre Hedrick > Linux ATA Development > - 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: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
OK, I see you guys releasing patches for the AMD + VIA problem, but this problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When are we going to see something for the MSI boards? My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset and the Promise PDC20265 ATA100 onbard controller. I need some sort of help with this. I'm getting kernel deaths left and right and no hope in sight here. I though it might possibly be a mix of SCSI + IDE causing troubles so I borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys SCSI card (not sure of the make offhand. I can find the box when I get home as I'm at work right now.) I would code up a fix if I knew what the hell I was doing when it came to coding which I do NOT. Vojtech, can you please work with me on this issue? Or if you are too busy, can you put me in contact with someone who can help? I've got a $3000 machine sitting here that I can not do a damn thing with until I stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation not at the kernel or anyone involved with the VIA stuff. Please don't take it that way.) David Downey - 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: [preview] Latest AMD VIA IDE drivers with UDMA100 support
OK, I see you guys releasing patches for the AMD + VIA problem, but this problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When are we going to see something for the MSI boards? My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset and the Promise PDC20265 ATA100 onbard controller. I need some sort of help with this. I'm getting kernel deaths left and right and no hope in sight here. I though it might possibly be a mix of SCSI + IDE causing troubles so I borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys SCSI card (not sure of the make offhand. I can find the box when I get home as I'm at work right now.) I would code up a fix if I knew what the hell I was doing when it came to coding which I do NOT. Vojtech, can you please work with me on this issue? Or if you are too busy, can you put me in contact with someone who can help? I've got a $3000 machine sitting here that I can not do a damn thing with until I stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation not at the kernel or anyone involved with the VIA stuff. Please don't take it that way.) David Downey - 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: [preview] Latest AMD VIA IDE drivers with UDMA100 support
LOL, I'm in Sunnyvale, CA right now. I work for Ensim.Com. OK, here is all the technical info on my box. Sorry it took so long to respond. Had a department meeting to attend. MSI 694D Pro running Dual FC-PGA PIII-733 CPUs with 1GB of Corsair RAM. HDD is a Western Digital WDC300BB-00AU1 ATA100 drive (running it on the VIA controlled ATA33/66 controller since the kernel doesn't support the ATA100 very well.) Chipsets are the VIA VT82C686A and the Promise PDC20265 NIC is a NetGear FA-310TX Advansys UW SCSI Card Yamaha CRW8424S CDRW Voodoo3 2000 AGP 16MB AGP video card. APM/ACPI turned OFF in BIOS, NOT using the ATA100 controller Symptoms: Consistantly recurring kernel deaths resulting in hard lock of box. On Thu, 25 Jan 2001, Andre Hedrick wrote: Where the flip are you form this power starved portion of the world? Also the subject is AMD and VIA chipsets not AMD CPU's running on VIA chipsets. What chipset or host is causing you the problem? VIA pr Promise? On Thu, 25 Jan 2001, David D.W. Downey wrote: OK, I see you guys releasing patches for the AMD + VIA problem, but this problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When are we going to see something for the MSI boards? My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset and the Promise PDC20265 ATA100 onbard controller. I need some sort of help with this. I'm getting kernel deaths left and right and no hope in sight here. I though it might possibly be a mix of SCSI + IDE causing troubles so I borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys SCSI card (not sure of the make offhand. I can find the box when I get home as I'm at work right now.) I would code up a fix if I knew what the hell I was doing when it came to coding which I do NOT. Vojtech, can you please work with me on this issue? Or if you are too busy, can you put me in contact with someone who can help? I've got a $3000 machine sitting here that I can not do a damn thing with until I stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation not at the kernel or anyone involved with the VIA stuff. Please don't take it that way.) David Downey - 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/ Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA chipset discussion
I get something similar. *I* get it when I mix drives on the various
controllers, aka ATA33/66 and ATA100 drives. I also get this error from
the CDROM when using the ATA100 controller for my ATA100 30GB drive and
the ATA33/66 controller for the CDROM. (Cyber 48X generic IDE CDROM).
On Sat, 20 Jan 2001, Andy Galasso wrote:
> I'm not sure how relevant it is, but FWIW here's what I've got:
>
> MSI 694D Pro Motherboard 2xPIII-800 100MHz FSB
> Linux-2.4.0-prerelease SMP
> Promise FastTrak100 controller card
> 4 IBM DTLA-307030 drives attached to Promise card
> boot params: ide2=0xac00 ide3=0xb400
>
> Here's an excerpt of what I get when trying to boot:
>
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 16
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
> ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:DMA, hdd:pio
> PDC20267: IDE controller on PCI bus 00 dev 70
> PDC20267: chipset revision 2
> PDC20267: not 100% native mode: will probe irqs later
> PDC20267: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode.
> PDC20267: neither IDE port enabled (BIOS)
> hde: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
> hde: IBM-DTLA-307030, ATA DISK drive
> hdf: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
> hdf: IBM-DTLA-307030, ATA DISK drive
> hdg: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
> hdg: IBM-DTLA-307030, ATA DISK drive
> hdh: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
> hdh: IBM-DTLA-307030, ATA DISK drive
> ide1 at 0x170-0x177,0x376 on irq 15
> ide2 at 0xac00-0xac07,0xae06 on irq 16
> ide3 at 0xb400-0xb407,0xb606 on irq 16 (shared with ide2)
> hde: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
> hdf: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
> hdg: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
> hdh: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
> Partition check:
> hde:hde: irq timeout: status=0x50 { DriveReady SeekComplete }
> hde: irq timeout: status=0x50 { DriveReady SeekComplete }
> hde: irq timeout: status=0x50 { DriveReady SeekComplete }
> hde: irq timeout: status=0x50 { DriveReady SeekComplete }
> ide2: reset: master: error (0x00?)
> hde: irq timeout: status=0x50 { DriveReady SeekComplete }
> hde: irq timeout: status=0x50 { DriveReady SeekComplete }
> hde: irq timeout: status=0x50 { DriveReady SeekComplete }
> hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> ide2(?): unexpected interrupt, status=0x58, count=1
> ide2: reset: master: error (0x00?)
> hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> end_request: I/O error, dev 21:00 (hde), sector 0
> hde: drive not ready for command
> unable to read partition table
> hdf:hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
> hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
> hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
> hdf: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> ide2(?): unexpected interrupt, status=0x58, count=2
> ide2: reset: master: error (0x00?)
> hdf: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> hdf: drive not ready for command
> hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
> hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
> hdf: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> ide2(?): unexpected interrupt, status=0x58, count=3
> ide2: reset: master: error (0x00?)
> hdf: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> end_request: I/O error, dev 21:40 (hdf), sector 0
> hdf: drive not ready for command
> unable to read partition table
> ...
> (similar for hdg ... hdh ...)
> ...
>
> -Andy Galasso
>
>
> On Wed, Jan 17, 2001 at 02:02:17PM -0800, David D.W. Downey wrote:
> >
> > Could those that were involved in the VIA chipset discussion email me
> > privately at [EMAIL PROTECTED]?
> >
> > I'm truly interested in solving this issue. I personally think it's more
> > than just the chipset causing the problems.
> >
> >
> > I'm looking for members of the list that are using the kernel support for
> > the following
> >
> >
> > VIA chipset
> > Promise controller (PDC2026# with specifics on the PDC20265 (ATA100))
> > SMP support
> > IDE + SCSI mix in the system.
> >
> >
> > I'm trying to track a number of POSSIBLE bugs (can't say they are for
> > sure) and any input from folks with this mix of drivers would be
> > expone
Re: boot.img & initrd.img
www.linuxdoc.org has a HOWTO on bottdisks called Bootdisk-HOWTO. I believe it's in the older faq section. On Sat, 20 Jan 2001, Linux Admin wrote: > Hi guys ... > > new to the list. need help ? > > can anyone please guide to me to an how-to or documentation on how to make a > custom boot.img & initrd.img ? > > thanks in advance.. > > parag mehta > > - > 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/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA chipset discussion
On Fri, 19 Jan 2001, John O'Donnell wrote: I also have APM disabled. (I don't think APM support is useful on a server so I default disable it.) > > Forgive me. I know _nothing_ about Power Management resources. > What kind of resouces would PM use to interfere with the mouse. > FYI I have power management turned off in my BIOS and in the kernel > I have CONFIG_APM and ONLY CONFIG_APM_REAL_MODE_POWER_OFF. > How does that compare with the rest of you? > Johnny O > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA chipset discussion
On Fri, 19 Jan 2001, John O'Donnell wrote: I also have APM disabled. (I don't think APM support is useful on a server so I default disable it.) Forgive me. I know _nothing_ about Power Management resources. What kind of resouces would PM use to interfere with the mouse. FYI I have power management turned off in my BIOS and in the kernel I have CONFIG_APM and ONLY CONFIG_APM_REAL_MODE_POWER_OFF. How does that compare with the rest of you? Johnny O - 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: boot.img initrd.img
www.linuxdoc.org has a HOWTO on bottdisks called Bootdisk-HOWTO. I believe it's in the older faq section. On Sat, 20 Jan 2001, Linux Admin wrote: Hi guys ... new to the list. need help ? can anyone please guide to me to an how-to or documentation on how to make a custom boot.img initrd.img ? thanks in advance.. parag mehta - 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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA chipset discussion
I get something similar. *I* get it when I mix drives on the various
controllers, aka ATA33/66 and ATA100 drives. I also get this error from
the CDROM when using the ATA100 controller for my ATA100 30GB drive and
the ATA33/66 controller for the CDROM. (Cyber 48X generic IDE CDROM).
On Sat, 20 Jan 2001, Andy Galasso wrote:
I'm not sure how relevant it is, but FWIW here's what I've got:
MSI 694D Pro Motherboard 2xPIII-800 100MHz FSB
Linux-2.4.0-prerelease SMP
Promise FastTrak100 controller card
4 IBM DTLA-307030 drives attached to Promise card
boot params: ide2=0xac00 ide3=0xb400
Here's an excerpt of what I get when trying to boot:
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:DMA, hdd:pio
PDC20267: IDE controller on PCI bus 00 dev 70
PDC20267: chipset revision 2
PDC20267: not 100% native mode: will probe irqs later
PDC20267: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode.
PDC20267: neither IDE port enabled (BIOS)
hde: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
hde: IBM-DTLA-307030, ATA DISK drive
hdf: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
hdf: IBM-DTLA-307030, ATA DISK drive
hdg: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
hdg: IBM-DTLA-307030, ATA DISK drive
hdh: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
hdh: IBM-DTLA-307030, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xac00-0xac07,0xae06 on irq 16
ide3 at 0xb400-0xb407,0xb606 on irq 16 (shared with ide2)
hde: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
hdf: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
hdg: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
hdh: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
Partition check:
hde:hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
ide2: reset: master: error (0x00?)
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
ide2(?): unexpected interrupt, status=0x58, count=1
ide2: reset: master: error (0x00?)
hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
end_request: I/O error, dev 21:00 (hde), sector 0
hde: drive not ready for command
unable to read partition table
hdf:hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
hdf: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
ide2(?): unexpected interrupt, status=0x58, count=2
ide2: reset: master: error (0x00?)
hdf: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdf: drive not ready for command
hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
hdf: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
ide2(?): unexpected interrupt, status=0x58, count=3
ide2: reset: master: error (0x00?)
hdf: status error: status=0x58 { DriveReady SeekComplete DataRequest }
end_request: I/O error, dev 21:40 (hdf), sector 0
hdf: drive not ready for command
unable to read partition table
...
(similar for hdg ... hdh ...)
...
-Andy Galasso
On Wed, Jan 17, 2001 at 02:02:17PM -0800, David D.W. Downey wrote:
Could those that were involved in the VIA chipset discussion email me
privately at [EMAIL PROTECTED]?
I'm truly interested in solving this issue. I personally think it's more
than just the chipset causing the problems.
I'm looking for members of the list that are using the kernel support for
the following
VIA chipset
Promise controller (PDC2026# with specifics on the PDC20265 (ATA100))
SMP support
IDE + SCSI mix in the system.
I'm trying to track a number of POSSIBLE bugs (can't say they are for
sure) and any input from folks with this mix of drivers would be
exponentially useful, even if for nothing more than discounting some of my
thoughts.
Also, can anyone summurize the already known and specific problems with
combinations of the above requirements? I would truly appreciate that.
David D.W. Downey
-
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/
-
To unsubscribe from this
VIA chipset discussion
Could those that were involved in the VIA chipset discussion email me privately at [EMAIL PROTECTED]? I'm truly interested in solving this issue. I personally think it's more than just the chipset causing the problems. I'm looking for members of the list that are using the kernel support for the following VIA chipset Promise controller (PDC2026# with specifics on the PDC20265 (ATA100)) SMP support IDE + SCSI mix in the system. I'm trying to track a number of POSSIBLE bugs (can't say they are for sure) and any input from folks with this mix of drivers would be exponentially useful, even if for nothing more than discounting some of my thoughts. Also, can anyone summurize the already known and specific problems with combinations of the above requirements? I would truly appreciate that. David D.W. Downey - 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/
VIA chipset discussion
Could those that were involved in the VIA chipset discussion email me privately at [EMAIL PROTECTED]? I'm truly interested in solving this issue. I personally think it's more than just the chipset causing the problems. I'm looking for members of the list that are using the kernel support for the following VIA chipset Promise controller (PDC2026# with specifics on the PDC20265 (ATA100)) SMP support IDE + SCSI mix in the system. I'm trying to track a number of POSSIBLE bugs (can't say they are for sure) and any input from folks with this mix of drivers would be exponentially useful, even if for nothing more than discounting some of my thoughts. Also, can anyone summurize the already known and specific problems with combinations of the above requirements? I would truly appreciate that. David D.W. Downey - 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: Article: Using test suites to test the new kernel
God sent you right? :) Been looking for something along this nature. David On Mon, 15 Jan 2001, Michael D. Crawford wrote: > I've written a brief article on the topic of using test suites to test new linux > kernels. > > It is my hope that anyone who wants to play with the new kernels will try out > some of these suites, not just people doing a formal QA process, so that more > coverage of configurations can be achieved. > > Using Test Suites to Validate the Linux Kernel > http://linuxquality.sunsite.dk/articles/testsuites/ > > I cover the use of suites that test the correct functioning of applications (for > example, language compliance tests for Python and Kaffe's Java implementation) > as well as test suites aimed directly at testing Linux itself. > > Links to five different packages with test suites are given. I'd appreciate > hearing of any more that you know about. > > I also appreciate your comments on how I can improve the article. This is a > first draft. > > Regards, > > Mike Crawford > - 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: ide.2.4.1-p3.01112001.patch
I feel it important to note that the distrib in use for all of this is of
my own design. The specs are at www.kixolinux.com.
Why do I feel this is important? Possibly something I've done in the
distrib could be affecting this as well. I remember reading some weeks ago
about the 2.4.0-test## series + SCSI + SMP were having some problems.
The drives are as follows
ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:DMA
hda: WDC WD153AA, ATA DISK drive
hda: 30064608 sectors (15393 MB) w/2048KiB Cache, CHS=1871/255/63, UDMA(66)
ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:DMA
hdb: WDC WD300BB-00AUA1, ATA DISK drive
hdb: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=3649/255/63, UDMA(66)
ide1: BM-DMA at 0xb008-0xb00f, BIOS settings: hdc:DMA, hdd:pio
hdc: SAMSUNG CD-ROM SC-148F, ATAPI CDROM drive
hdc: ATAPI 48X CD-ROM drive, 128kB Cache, DMA
The errors are as follows
hdc: timeout waiting for DMA
hdc: irq timeout: status=0xd0 { Busy }
hdc: DMA disabled
hdc: ATAPI reset complete
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54
end_request: I/O error, dev 16:00 (hdc), sector 929520
hdc: irq timeout: status=0xd0 { Busy }
hdc: ATAPI reset complete
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54
end_request: I/O error, dev 16:00 (hdc), sector 929522
I get the same thing for hda and hdb though not as frequently as with
hdc. (Controller doesn't like switchign between DMA and PIO modes
possibly? ::shrug::)
David D.W. Downey
-
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: ide.2.4.1-p3.01112001.patch
> > /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
> > DriveReady SeekComplete Error } hda: dma_intr: error=0x84 {
> > DriveStatusError BadCRC } hda: dma_intr: status=0x51 { DriveReady
> > SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError
> > BadCRC } hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> ...
> > 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev
> > 02)
> > 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
> > 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super]
> > (rev 22)
> > 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo]
> > (rev 10)
> > 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> > 00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> > 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
> > ACPI] (rev 30)
Good! I'm not the only ome getting this error! Mine is also a VT82C686
though mine is a VT82C686A (352 BGA). This is on an MSI Model 694D Pro
motherboard running dual PIII-733 FC-PGA 133MHz Coppermines. RAM is 4
256MB PC133 unbuffered 7ns non mixed-cell DIMMs. I bring up the RAM and
CPU info because this board is also giving me random SIG11 errors even
though all equipment passes lab testing.
I was beginning to think the board was flaky until i saw this
posting. Almost exactly matche smy errors. Also, since I'm using the
Promise PDC20265 (rev 2) ATA33/66 + 100 controller on the mobo, I wasn't sure
if my errors were stemming from that. The 2.4.0 kernel driver picks up
the controller fine and it's only under heavy I/O (aka dd if=/dev/hdc
of=/root/testdd.img bs=1024M count=2k ) that it REALLY goes nuts and
drops loses it's lunch all over the floor. Accessing a standard 48X CDROM
in the same manner doesn't kill the kernel but I get quite a few
DriveReady errors like you got. I'm wondering if this is just a flaky
chipset or if this is a Promise controller issue. This is one reason i'm
extremely interested in what controller you have on your board, and if you
are using it.
I also had to remove the USB support totally since it would stream errors
at me about usb devices not accepting new addresses.
Funny thing is, I don't have any USB devices attached to the machine!
Thought address assignments were only when you attached devices.
Anyone else out there with troubles with either of these 3 items?
David D.W. Downey
-
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: ide.2.4.1-p3.01112001.patch
/dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
DriveReady SeekComplete Error } hda: dma_intr: error=0x84 {
DriveStatusError BadCRC } hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error } hda: dma_intr: error=0x84 { DriveStatusError
BadCRC } hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
...
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev
02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super]
(rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo]
(rev 10)
00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
ACPI] (rev 30)
Good! I'm not the only ome getting this error! Mine is also a VT82C686
though mine is a VT82C686A (352 BGA). This is on an MSI Model 694D Pro
motherboard running dual PIII-733 FC-PGA 133MHz Coppermines. RAM is 4
256MB PC133 unbuffered 7ns non mixed-cell DIMMs. I bring up the RAM and
CPU info because this board is also giving me random SIG11 errors even
though all equipment passes lab testing.
I was beginning to think the board was flaky until i saw this
posting. Almost exactly matche smy errors. Also, since I'm using the
Promise PDC20265 (rev 2) ATA33/66 + 100 controller on the mobo, I wasn't sure
if my errors were stemming from that. The 2.4.0 kernel driver picks up
the controller fine and it's only under heavy I/O (aka dd if=/dev/hdc
of=/root/testdd.img bs=1024M count=2k ) that it REALLY goes nuts and
drops loses it's lunch all over the floor. Accessing a standard 48X CDROM
in the same manner doesn't kill the kernel but I get quite a few
DriveReady errors like you got. I'm wondering if this is just a flaky
chipset or if this is a Promise controller issue. This is one reason i'm
extremely interested in what controller you have on your board, and if you
are using it.
I also had to remove the USB support totally since it would stream errors
at me about usb devices not accepting new addresses.
Funny thing is, I don't have any USB devices attached to the machine!
Thought address assignments were only when you attached devices.
Anyone else out there with troubles with either of these 3 items?
David D.W. Downey
-
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: ide.2.4.1-p3.01112001.patch
I feel it important to note that the distrib in use for all of this is of
my own design. The specs are at www.kixolinux.com.
Why do I feel this is important? Possibly something I've done in the
distrib could be affecting this as well. I remember reading some weeks ago
about the 2.4.0-test## series + SCSI + SMP were having some problems.
The drives are as follows
ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:DMA
hda: WDC WD153AA, ATA DISK drive
hda: 30064608 sectors (15393 MB) w/2048KiB Cache, CHS=1871/255/63, UDMA(66)
ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:DMA
hdb: WDC WD300BB-00AUA1, ATA DISK drive
hdb: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=3649/255/63, UDMA(66)
ide1: BM-DMA at 0xb008-0xb00f, BIOS settings: hdc:DMA, hdd:pio
hdc: SAMSUNG CD-ROM SC-148F, ATAPI CDROM drive
hdc: ATAPI 48X CD-ROM drive, 128kB Cache, DMA
The errors are as follows
hdc: timeout waiting for DMA
hdc: irq timeout: status=0xd0 { Busy }
hdc: DMA disabled
hdc: ATAPI reset complete
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54
end_request: I/O error, dev 16:00 (hdc), sector 929520
hdc: irq timeout: status=0xd0 { Busy }
hdc: ATAPI reset complete
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54
end_request: I/O error, dev 16:00 (hdc), sector 929522
I get the same thing for hda and hdb though not as frequently as with
hdc. (Controller doesn't like switchign between DMA and PIO modes
possibly? ::shrug::)
David D.W. Downey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 + reiserfs + smp
Thanks Chris. Appreciate the fast getback. On Fri, 15 Dec 2000, Chris Mason wrote: > > > On Fri, 15 Dec 2000, David D.W. Downey wrote: > > > > I've been reading the thread regarding data corruption with 2.4.0-test12, > > reiserfs, and smp. > > > > Unfrotunately I've not seen any resolution announced about this. Is this > > still an issue or has this been fixed? > > > reiserfs and test12 won't play nice at all right now due to the > ll_rw_block changes. I'm testing a patch now, it should be done sometime > today. > > -chris > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > -- David D.W. Downey RHCE - 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.0 + reiserfs + smp
I've been reading the thread regarding data corruption with 2.4.0-test12, reiserfs, and smp. Unfrotunately I've not seen any resolution announced about this. Is this still an issue or has this been fixed? Right now I've stayed with 2.4.0-test10 + reiserfs and Uni mode while waiting for a resolution to this. Anyone know the current status of this problem? -- David D.W. Downey RHCE - 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.0 + reiserfs + smp
I've been reading the thread regarding data corruption with 2.4.0-test12, reiserfs, and smp. Unfrotunately I've not seen any resolution announced about this. Is this still an issue or has this been fixed? Right now I've stayed with 2.4.0-test10 + reiserfs and Uni mode while waiting for a resolution to this. Anyone know the current status of this problem? -- David D.W. Downey RHCE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 + reiserfs + smp
Thanks Chris. Appreciate the fast getback. On Fri, 15 Dec 2000, Chris Mason wrote: On Fri, 15 Dec 2000, David D.W. Downey wrote: I've been reading the thread regarding data corruption with 2.4.0-test12, reiserfs, and smp. Unfrotunately I've not seen any resolution announced about this. Is this still an issue or has this been fixed? reiserfs and test12 won't play nice at all right now due to the ll_rw_block changes. I'm testing a patch now, it should be done sometime today. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- David D.W. Downey RHCE - 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 shared memory??
Yeah I just read that. Thanks for the info. Knew nothing about it being kicked out there. I usually only read looking for package locations of needed software to run the kernels. Now it looks like I should be reading more. Thanks for the blow to the head to get me thinking right again. :) BTW, I have that mounted now like the docs say but I still do not get any shared info. I've gotten a couple of other emails about it, one of which states that it ate up too much CPU time. What I'm wondering is, is it possible to get that info some other way? I realize walking the process tree is a pain in the ass and expensive CPU and time wise. Also, I'm not sure if that information would include each process's private memory space. The reason I'm asking is that taking the overall memory used, subtracting the cached and buffered memory may not always leave the right amount of shared memory. (If I show 26MB used total, 21MB which is cached and 1MB that's buffered is it a FACT that the remaining 4MB unaccounted for is actually and completely shared memory?) Any other information on this would be appreciated. TO THE KERNEL DEVELOPERS = BTW, I love the devfs stuff. REALLY makes s big difference. I'm developing my own flavor of linux and it's quickly being modified to use ONLY devfs entries. > > On Sun, 10 Dec 2000 12:11:14 David D.W. Downey wrote: > > > > OK, got a tiny little bug here. > > > > When running top, procinfo, or free I get 0 for Shared memory. Obviously > > this is incorrect. What has changed from the 2.2.x and the 2.4.x that > > would cause these apps to misreport this information. > > > > Have you mounted /dev/shm (shared memory) filesystem ? > Take a look at kernel documentation under linux/Documentation/Changes. > > -- > Juan Antonio Magallon Lacarta #> cd /pub > mailto:[EMAIL PROTECTED] #> more beer > > Linux werewolf 2.2.18-pre25-vm #4 SMP Fri Dec 8 01:59:48 CET 2000 i686 > > - > 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/ > - 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 shared memory??
Yeah I just read that. Thanks for the info. Knew nothing about it being kicked out there. I usually only read looking for package locations of needed software to run the kernels. Now it looks like I should be reading more. Thanks for the blow to the head to get me thinking right again. :) BTW, I have that mounted now like the docs say but I still do not get any shared info. I've gotten a couple of other emails about it, one of which states that it ate up too much CPU time. What I'm wondering is, is it possible to get that info some other way? I realize walking the process tree is a pain in the ass and expensive CPU and time wise. Also, I'm not sure if that information would include each process's private memory space. The reason I'm asking is that taking the overall memory used, subtracting the cached and buffered memory may not always leave the right amount of shared memory. (If I show 26MB used total, 21MB which is cached and 1MB that's buffered is it a FACT that the remaining 4MB unaccounted for is actually and completely shared memory?) Any other information on this would be appreciated. TO THE KERNEL DEVELOPERS = BTW, I love the devfs stuff. REALLY makes s big difference. I'm developing my own flavor of linux and it's quickly being modified to use ONLY devfs entries. On Sun, 10 Dec 2000 12:11:14 David D.W. Downey wrote: OK, got a tiny little bug here. When running top, procinfo, or free I get 0 for Shared memory. Obviously this is incorrect. What has changed from the 2.2.x and the 2.4.x that would cause these apps to misreport this information. Have you mounted /dev/shm (shared memory) filesystem ? Take a look at kernel documentation under linux/Documentation/Changes. -- Juan Antonio Magallon Lacarta # cd /pub mailto:[EMAIL PROTECTED] # more beer Linux werewolf 2.2.18-pre25-vm #4 SMP Fri Dec 8 01:59:48 CET 2000 i686 - 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/ - 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/
No shared memory??
OK, got a tiny little bug here. When running top, procinfo, or free I get 0 for Shared memory. Obviously this is incorrect. What has changed from the 2.2.x and the 2.4.x that would cause these apps to misreport this information. This IS information gained through the /proc filesystem which is kernel based is it not? This would seem to make it a kernel issue since the change in format is brought about by how the kernel reports this information if i understand this correctly. (If I am wrong, please let me know. I hate laboring under false assumptions) How do I fix this problem in any event? David PGPKeys Downey - 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/
No shared memory??
OK, got a tiny little bug here. When running top, procinfo, or free I get 0 for Shared memory. Obviously this is incorrect. What has changed from the 2.2.x and the 2.4.x that would cause these apps to misreport this information. This IS information gained through the /proc filesystem which is kernel based is it not? This would seem to make it a kernel issue since the change in format is brought about by how the kernel reports this information if i understand this correctly. (If I am wrong, please let me know. I hate laboring under false assumptions) How do I fix this problem in any event? David PGPKeys Downey - 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/
Network delays with NE2K-PCI
KERNEL VER: 2.4.0-test11 ADD. PATCHES: reiserfs patch NETWORK CARD: NE2K-PCI Kingston KNE-111TX (P/N: 4460170-001.A00) 10/100BASE-TX MOBO: MSI BX-Master with 20001013 BIOS update PROBLEM: Network hangs on all initial outbound traffic. I need to do a ping in order to get any type of connection. Network response starts out in the high thousand ms then "connects" and drops to a normal 23 ms average. If I do NOT do this initial ping or several nslookups or some sort of outbound traffic I can not connect to the net nor does the box respond to inbound packets. But once I do that first set of pings everything works fine.. until the next reboot and I end up having to do that first set of pings again. This problem does not happen under any of the 2.2.x series of kernels with reiserfs patch and same NIC module and network config. All versions of network daemons like named, postfix, sendmail sshd ect ect are the same. (I purposely built the setups under 2.2 and 2.4 the same just to make sure it wasn't a daemon issue.) I've searched through the list archvies under SUBJECT and found nothing related to this. POSSIBILITY: Driver issue with the 2.4.0-test11 and the ne2k-pci module when used with this particular network card? It acts almost like the card is "sleeping". I thought it might possibly be the WAKE ON LAN option in the BIOS but I turned off all APM options in BIOS, disabled the apmd daemon and compiled the kernel without APM support. I thought it might be the fact that it's a 32 bit bus mastering PCI adapter but I've tried enabling and disabling bus mastering in the BIOS to what extent it allows. At this point I'm totally clueless where to look. All my other machines running various versions of 2.4.0 (test6 through test11) all use the NetGear FA-310TX and i don't get this problem. Only with this brand of card. (Tried 3 different physical cards of the same model.) Any ideas? David D.W. Downey - 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/
Network delays with NE2K-PCI
KERNEL VER: 2.4.0-test11 ADD. PATCHES: reiserfs patch NETWORK CARD: NE2K-PCI Kingston KNE-111TX (P/N: 4460170-001.A00) 10/100BASE-TX MOBO: MSI BX-Master with 20001013 BIOS update PROBLEM: Network hangs on all initial outbound traffic. I need to do a ping in order to get any type of connection. Network response starts out in the high thousand ms then "connects" and drops to a normal 23 ms average. If I do NOT do this initial ping or several nslookups or some sort of outbound traffic I can not connect to the net nor does the box respond to inbound packets. But once I do that first set of pings everything works fine.. until the next reboot and I end up having to do that first set of pings again. This problem does not happen under any of the 2.2.x series of kernels with reiserfs patch and same NIC module and network config. All versions of network daemons like named, postfix, sendmail sshd ect ect are the same. (I purposely built the setups under 2.2 and 2.4 the same just to make sure it wasn't a daemon issue.) I've searched through the list archvies under SUBJECT and found nothing related to this. POSSIBILITY: Driver issue with the 2.4.0-test11 and the ne2k-pci module when used with this particular network card? It acts almost like the card is "sleeping". I thought it might possibly be the WAKE ON LAN option in the BIOS but I turned off all APM options in BIOS, disabled the apmd daemon and compiled the kernel without APM support. I thought it might be the fact that it's a 32 bit bus mastering PCI adapter but I've tried enabling and disabling bus mastering in the BIOS to what extent it allows. At this point I'm totally clueless where to look. All my other machines running various versions of 2.4.0 (test6 through test11) all use the NetGear FA-310TX and i don't get this problem. Only with this brand of card. (Tried 3 different physical cards of the same model.) Any ideas? David D.W. Downey - 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.0-test11 + reiserfs + iptables
Hi guys, Not sure if this is the right list for this, but I'll spew this forward too you. Redirects to right place is definitiely welcome. Since I added the reiserfs kernel patch , I figured I'd mention it. Problem: When building the kernel things buld fine with no errors other than the standard warnings generated by -Wall. Running the make dep bzImage modules modules_install command completes. Nothing big there, but when i reboot to the new kernel and the system runs depmod -a `uname -r` I keep getting unresolved symbols for the ipt_REDIRECT module in the kernel's iptables support. I'm using the latest Red Hat **6.2** gcc and glibc, not the 7.0's. >From what I understand in asking around, there is a symbol in the module itself that's not being exported to depmod. (?) 1) Is there a way to find out exactly WHAT symbol is not being kicked out? 2) If so is there a way to force that symbol to be exported for depmod's use? The reason I ask this here is since it's a kernel level module, I associate that as a kernel issue. Thanks gentleman David - 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/
TEST IGNORE
- 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.0-test11 + reiserfs + iptables
Hi guys, Not sure if this is the right list for this, but I'll spew this forward too you. Redirects to right place is definitiely welcome. Since I added the reiserfs kernel patch , I figured I'd mention it. Problem: When building the kernel things buld fine with no errors other than the standard warnings generated by -Wall. Running the make dep bzImage modules modules_install command completes. Nothing big there, but when i reboot to the new kernel and the system runs depmod -a `uname -r` I keep getting unresolved symbols for the ipt_REDIRECT module in the kernel's iptables support. I'm using the latest Red Hat **6.2** gcc and glibc, not the 7.0's. From what I understand in asking around, there is a symbol in the module itself that's not being exported to depmod. (?) 1) Is there a way to find out exactly WHAT symbol is not being kicked out? 2) If so is there a way to force that symbol to be exported for depmod's use? The reason I ask this here is since it's a kernel level module, I associate that as a kernel issue. Thanks gentleman David - 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/
