ide-scsi detecting CDR as "CD-ROM" in 2.2.19
I'm using the ide patch "ide.2.2.19.05042001" for 2.2.19. In 2.4.5 this cdr wsa detected as a cdr. here it's detected as: Vendor: CREATIVE Model: CD-RW RW8438ERev: FC03 Type: CD-ROM ANSI SCSI revision: 02 Cdrecord says this. cdrecord: Invalid argument. Cannot get mmap for 4198400 Bytes on /dev/zero. TOC Type: 1 = CD-ROM How do i make it be detected as a cdrw or at least cdr? - 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/
anyway to stop dma timeouts in 2.2.19?
I never got dma timeouts running 2.2.19 before installing my promise ata66 card and CDRW. Now i get them whenever disk usage is up and what ends up happening is none of my drives running in dma mode. Is this some effect of enabling the UDMA features of the promise card ? If i compiled the kernel without these UDMA features on the promise card, would it fix the problem? I have 5 drives now, 3 are UDMA4 drives and 1 (secondary slave) is a cdrom using DMA. I can move this to the secondary channel of the promise card if that will help. Is there any way to predict if you're going to have trouble with DMA's? - 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/
anyway to stop dma timeouts in 2.2.19?
I never got dma timeouts running 2.2.19 before installing my promise ata66 card and CDRW. Now i get them whenever disk usage is up and what ends up happening is none of my drives running in dma mode. Is this some effect of enabling the UDMA features of the promise card ? If i compiled the kernel without these UDMA features on the promise card, would it fix the problem? I have 5 drives now, 3 are UDMA4 drives and 1 (secondary slave) is a cdrom using DMA. I can move this to the secondary channel of the promise card if that will help. Is there any way to predict if you're going to have trouble with DMA's? - 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/
ide-scsi detecting CDR as CD-ROM in 2.2.19
I'm using the ide patch ide.2.2.19.05042001 for 2.2.19. In 2.4.5 this cdr wsa detected as a cdr. here it's detected as: Vendor: CREATIVE Model: CD-RW RW8438ERev: FC03 Type: CD-ROM ANSI SCSI revision: 02 Cdrecord says this. cdrecord: Invalid argument. Cannot get mmap for 4198400 Bytes on /dev/zero. TOC Type: 1 = CD-ROM How do i make it be detected as a cdrw or at least cdr? - 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/
cd writer problems with 2.4.5ac17
I'm thinking that this is a kernel scsi emu problem rather than a CDR problem
due to the past scsi emulation mails i've seen about previous kernels. I've
been forced to move to 2.4.x because i want to use my promise ata66 ide
controller and the 2.2 promise drivers dont work for it. My CDR is detected
as Vendor: CREATIVE Model: CD-RW RW8438ERev: FC03 by the ide-scsi
module. Now the problem is, cdrecord is very tempermental with it and it
shouldn't be. Often there are input output errors reading blank media before
writing, these lead to drive lockups that can only be recovered by power
cycling (rebooting).The cdrecord i'm using is version 1.11a04 and i'm
going to try an earlier release to see if it's a cdrecord issue in a bit but
i wanted to get responses from anyone else who may be having these problems
early if it isn't.
Errors: In dmesg this shows up.
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0
Write (10) 00 00 00 00 00 00 00 1f 00
hde: irq timeout: status=0xd0 { Busy }
hde: ATAPI reset complete
I cant get the cdrecord actual error until i reboot, but then when i do it's
random when the error does occur, just that it does after a few uses of the
burner.
on a side note. the kernel really likes to hang up when writing to a cd.
This never used to happen a few kernel releases ago.it slows everything
else down but when the cdr does write a cd, it does so without losing any
fifo buffer.
Any more info needed i'd like to give to figure this out, the thing is,
everytime this happens i have to reboot to use the CDR again. It wont even
detect unless it's power cycled and just unplugging the power cord and
putting it back in doesn't really help because it causes one of my other
drives to flip out. (did that last night.)
-
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/
cd writer problems with 2.4.5ac17
I'm thinking that this is a kernel scsi emu problem rather than a CDR problem
due to the past scsi emulation mails i've seen about previous kernels. I've
been forced to move to 2.4.x because i want to use my promise ata66 ide
controller and the 2.2 promise drivers dont work for it. My CDR is detected
as Vendor: CREATIVE Model: CD-RW RW8438ERev: FC03 by the ide-scsi
module. Now the problem is, cdrecord is very tempermental with it and it
shouldn't be. Often there are input output errors reading blank media before
writing, these lead to drive lockups that can only be recovered by power
cycling (rebooting).The cdrecord i'm using is version 1.11a04 and i'm
going to try an earlier release to see if it's a cdrecord issue in a bit but
i wanted to get responses from anyone else who may be having these problems
early if it isn't.
Errors: In dmesg this shows up.
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0
Write (10) 00 00 00 00 00 00 00 1f 00
hde: irq timeout: status=0xd0 { Busy }
hde: ATAPI reset complete
I cant get the cdrecord actual error until i reboot, but then when i do it's
random when the error does occur, just that it does after a few uses of the
burner.
on a side note. the kernel really likes to hang up when writing to a cd.
This never used to happen a few kernel releases ago.it slows everything
else down but when the cdr does write a cd, it does so without losing any
fifo buffer.
Any more info needed i'd like to give to figure this out, the thing is,
everytime this happens i have to reboot to use the CDR again. It wont even
detect unless it's power cycled and just unplugging the power cord and
putting it back in doesn't really help because it causes one of my other
drives to flip out. (did that last night.)
-
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: lowlatency 2.2.19
this is just a general question about low latency patches on 2.2, I remember hearing about low latency patches for 2.4 not playing well with X 4.x, is this true for 2.2 low latency patches as well? - 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: lowlatency 2.2.19
this is just a general question about low latency patches on 2.2, I remember hearing about low latency patches for 2.4 not playing well with X 4.x, is this true for 2.2 low latency patches as well? - 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/
incorrect CPU usage readings in 2.2.19prex?
Is there something generally wrong with how linux determines total cpu usage (via procmeter3 and top) when dealing with applications that are threaded? I routinely get 0% cpu usage when playing mpegs and mp3s and some avi's even (Divx when using no software enhancement) ... Somehow i doubt that the decoders are so streamlined that they produce <1% cpu usage on the computer. Does anyone know what's going on with this? ps shows nearly 0% cpu usage in the threads as well. i've seen it in these programs freeamp mplayer I've seen it in earlier 2.2.19 kernels but i'm using pre14 right now. - 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/
Everything working fine here.
As a departure from just about every other post talking about something wrong. I just want to say 2.2.19pre14 is working perfectly. I can't say anything about latency because i haven't found much in the area of timing patches for 2.2.19 yet, it is very responsive and fast and handles quite well under load. I haven't had one single kernel oops or crash and no zombie processes. I have not had X lock up the kernel or needed to use sysreq. I have not seen any corruption and the memory management seems to be working well since loading netscape and the gimp is almost instant. X works with dri and my hdd's can work in DMA mode without worrying about irq reset loops or dma timeouts with the cdrom. I even compiled the kernel and all the modules and user level apps for those drivers with athlon gcc 0.0.2 and everything still runs perfect with a little kick in responsiveness. I must say i'm happy with this kernel and for the first time in using all those devel kernels and release 2.4.x's i can use the latest programs like X 4.x fully and not have to worry about when they'll fix that nasty bug that causes the kernel to crash or to let me use some other part of my system without having it corrupt data .Good job alan. just to let you know what i'm using that works really well gcc version pgcc-2.95.3 19991024 (AthlonGCC-0.0.2) XFree86 Version 4.0.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6510) libc 2.2.2 Advanced Linux Sound Architecture Driver Version 0.5.10b bttv 0.7.57 all running on an Abit KA7 Via KT133a motherboard with VIA686a ide controller. with ATA66 hdd's. Voodoo3 agp SB live value 3c509 isa 10baseT and Hauppauge wintv with stereo and fm tuner (with remote which works in linux) Bt878 chipset Thanks again guys anyone who may be looking for a 100% (minus the annoying power management part) working new athlon system ... here it is. And this is not to say that 2.4.x doesn't work good either but in my experience cvs versions of X plus 2.4.x equaled a 100% certainty of a lockup when using GL or xv in hardware accel ... and that just hasn't happened with 2.2.19. - 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/
Everything working fine here.
As a departure from just about every other post talking about something wrong. I just want to say 2.2.19pre14 is working perfectly. I can't say anything about latency because i haven't found much in the area of timing patches for 2.2.19 yet, it is very responsive and fast and handles quite well under load. I haven't had one single kernel oops or crash and no zombie processes. I have not had X lock up the kernel or needed to use sysreq. I have not seen any corruption and the memory management seems to be working well since loading netscape and the gimp is almost instant. X works with dri and my hdd's can work in DMA mode without worrying about irq reset loops or dma timeouts with the cdrom. I even compiled the kernel and all the modules and user level apps for those drivers with athlon gcc 0.0.2 and everything still runs perfect with a little kick in responsiveness. I must say i'm happy with this kernel and for the first time in using all those devel kernels and release 2.4.x's i can use the latest programs like X 4.x fully and not have to worry about when they'll fix that nasty bug that causes the kernel to crash or to let me use some other part of my system without having it corrupt data .Good job alan. just to let you know what i'm using that works really well gcc version pgcc-2.95.3 19991024 (AthlonGCC-0.0.2) XFree86 Version 4.0.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6510) libc 2.2.2 Advanced Linux Sound Architecture Driver Version 0.5.10b bttv 0.7.57 all running on an Abit KA7 Via KT133a motherboard with VIA686a ide controller. with ATA66 hdd's. Voodoo3 agp SB live value 3c509 isa 10baseT and Hauppauge wintv with stereo and fm tuner (with remote which works in linux) Bt878 chipset Thanks again guys anyone who may be looking for a 100% (minus the annoying power management part) working new athlon system ... here it is. And this is not to say that 2.4.x doesn't work good either but in my experience cvs versions of X plus 2.4.x equaled a 100% certainty of a lockup when using GL or xv in hardware accel ... and that just hasn't happened with 2.2.19. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA chipset problems with 2.2?
"Michael B. Allen" wrote: > Hello, > > What's the nature of the VIA chipset problems? I want to get a new system > this weekend but I read on kernel traffic that VIA has problems? I > wan't to use Hendrick's ide patches on 2.2.18. What board should I > get? Help, I've searched through usenet and asked on #linux without > anything conclusive. There are no problems with 2.2.x. What motherboard you get depends on how much you want to spend and on what type of athlon cpu you want to get. K7-2 (classic), get the KA7 by abit. Duron and T-bird should get KT7 or something like that .I'd use alan cox's latest patch. They work great. Awesome performance. As good as linux gets. > > Thanks, > Mike > > >From KT: > > David Riley [*] reported tremendous slowdowns in 2.4.1-pre11 and -pre12 > on his Athlon 900 with a KT133 chipset. Mark Hahn [*] replied, "this is > known: Linus decreed that, since two people reported disk corruption > on VIA, any machine with a VIA southbridge must boot in stupid 1992 > mode (PIO). (yes, it might be possible to boot with ide=autodma or > something, but who would guess?)" He added to Linus Torvalds [*], > "I hope you don't consider this a releasable state! VIA now owns 40% > of the chipset market..." Linus replied: > > So find somebody who can figure out why the corruption happens, and > I'll be really happy with a patch that fixes it. In the meantime, > "releaseable" very much means that we did _everything_ possible to > make sure that people don't screw their disks over. > > You have to realize that stability takes precedence over EVERYTHING. > > -- > signature pending > - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA chipset problems with 2.2?
"Michael B. Allen" wrote: Hello, What's the nature of the VIA chipset problems? I want to get a new system this weekend but I read on kernel traffic that VIA has problems? I wan't to use Hendrick's ide patches on 2.2.18. What board should I get? Help, I've searched through usenet and asked on #linux without anything conclusive. There are no problems with 2.2.x. What motherboard you get depends on how much you want to spend and on what type of athlon cpu you want to get. K7-2 (classic), get the KA7 by abit. Duron and T-bird should get KT7 or something like that .I'd use alan cox's latest patch. They work great. Awesome performance. As good as linux gets. Thanks, Mike From KT: David Riley [*] reported tremendous slowdowns in 2.4.1-pre11 and -pre12 on his Athlon 900 with a KT133 chipset. Mark Hahn [*] replied, "this is known: Linus decreed that, since two people reported disk corruption on VIA, any machine with a VIA southbridge must boot in stupid 1992 mode (PIO). (yes, it might be possible to boot with ide=autodma or something, but who would guess?)" He added to Linus Torvalds [*], "I hope you don't consider this a releasable state! VIA now owns 40% of the chipset market..." Linus replied: So find somebody who can figure out why the corruption happens, and I'll be really happy with a patch that fixes it. In the meantime, "releaseable" very much means that we did _everything_ possible to make sure that people don't screw their disks over. You have to realize that stability takes precedence over EVERYTHING. -- signature pending - - 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/
/proc/meminfo displays incorrect memory sizes
I personally have no way of knowing if it's giving incorrect numbers for cache and buffers and used and such .. but as for total memory, something is wrong. lm sensors tells me i have 288MB of ram, the bootup messages say i have 288MB of memory with 4MB being used by the kernel and my bios says i have 288MB. /proc/meminfo, however, says i have @167MB. Is this correct? and why ? i'm using 2.2.19-pre7 I have agpgart and mtrr compiled in < from dmesg > Memory: 290412k/294848k available (864k kernel code, 412k reserved, 3112k data, 48k init) Dentry hash table entries: 65536 (order 7, 512k) Buffer cache hash table entries: 524288 (order 9, 2048k) Page cache hash table entries: 131072 (order 7, 512k) Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 232M agpgart: Detected Via Apollo KX133 chipset agpgart: AGP aperture is 64M @ 0xd000 bttv: driver version 0.7.54 loaded bttv: using 8 buffers with 2080k (16640k total) for capture that adds to 31.148MB (used) @288MB full@284MB useable < from sensors > Adapter: SMBus vt82c596 adapter at 5000 Algorithm: Non-I2C SMBus adapter Memory type:SDRAM DIMM SPD SDRAM Size (MB):128 eeprom-i2c-2-51 Adapter: SMBus vt82c596 adapter at 5000 Algorithm: Non-I2C SMBus adapter Memory type:SDRAM DIMM SPD SDRAM Size (MB):64 eeprom-i2c-2-52 Adapter: SMBus vt82c596 adapter at 5000 Algorithm: Non-I2C SMBus adapter Memory type:SDRAM DIMM SPD SDRAM Size (MB):64 eeprom-i2c-2-53 Adapter: SMBus vt82c596 adapter at 5000 Algorithm: Non-I2C SMBus adapter Memory type:SDRAM DIMM SPD SDRAM Size (MB): 32 that adds to 288 total:used:free: shared: buffers: cached: Mem: 280281088 276422656 3858432 86532096 69550080 108240896 Swap: 1398210560 139821056 MemTotal:273712 kB MemFree: 3768 kB MemShared:84504 kB Buffers: 67920 kB Cached: 105704 kB SwapTotal: 136544 kB SwapFree:136544 kB that is about 267MB total anyone? - 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/
/proc/meminfo displays incorrect memory sizes
I personally have no way of knowing if it's giving incorrect numbers for cache and buffers and used and such .. but as for total memory, something is wrong. lm sensors tells me i have 288MB of ram, the bootup messages say i have 288MB of memory with 4MB being used by the kernel and my bios says i have 288MB. /proc/meminfo, however, says i have @167MB. Is this correct? and why ? i'm using 2.2.19-pre7 I have agpgart and mtrr compiled in from dmesg Memory: 290412k/294848k available (864k kernel code, 412k reserved, 3112k data, 48k init) Dentry hash table entries: 65536 (order 7, 512k) Buffer cache hash table entries: 524288 (order 9, 2048k) Page cache hash table entries: 131072 (order 7, 512k) Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 232M agpgart: Detected Via Apollo KX133 chipset agpgart: AGP aperture is 64M @ 0xd000 bttv: driver version 0.7.54 loaded bttv: using 8 buffers with 2080k (16640k total) for capture that adds to 31.148MB (used) @288MB full@284MB useable from sensors Adapter: SMBus vt82c596 adapter at 5000 Algorithm: Non-I2C SMBus adapter Memory type:SDRAM DIMM SPD SDRAM Size (MB):128 eeprom-i2c-2-51 Adapter: SMBus vt82c596 adapter at 5000 Algorithm: Non-I2C SMBus adapter Memory type:SDRAM DIMM SPD SDRAM Size (MB):64 eeprom-i2c-2-52 Adapter: SMBus vt82c596 adapter at 5000 Algorithm: Non-I2C SMBus adapter Memory type:SDRAM DIMM SPD SDRAM Size (MB):64 eeprom-i2c-2-53 Adapter: SMBus vt82c596 adapter at 5000 Algorithm: Non-I2C SMBus adapter Memory type:SDRAM DIMM SPD SDRAM Size (MB): 32 that adds to 288 /proc/meminfo total:used:free: shared: buffers: cached: Mem: 280281088 276422656 3858432 86532096 69550080 108240896 Swap: 1398210560 139821056 MemTotal:273712 kB MemFree: 3768 kB MemShared:84504 kB Buffers: 67920 kB Cached: 105704 kB SwapTotal: 136544 kB SwapFree:136544 kB that is about 267MB total anyone? - 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
Vojtech Pavlik wrote: > On Thu, Feb 01, 2001 at 01:20:00PM -0500, Byron Stanoszek wrote: > > > > On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote: > > > > > > > Yeah, by bios does the same thing too on the Abit KT7(a). > > > > > > Ok, I'll remember this. This is most likely the cause of the problems > > > many people had with the KT7 in the past. > > > > What cause are you referring to? As far as I know, there are two options to > > increasing the FSB clock.. one increases both FSB+PCICLK, the other just > > increases FSB. If you increase the FSB only, it should keep PCICLK at a solid > > 33. (But I could be wrong, I've never tested that. I can tomorrow though.) > > I mean that people can alter the PCI clock on these boards and that 33 > doesn't to be always exactly 33 due to rounding errors if used with a > FSB other than 66 or 100 or 133. > > Could it be that the PCI bus is not asynchronous, but only > pseudo-synchronous, allowing for divisors of 5, 4.5, 4, 3.5, 3, 2.5, 2? > > > > The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in > > > PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that > > > there is an external 100MHz clock fed to the chip, so that the UDMA timing is > > > in T = 10ns increments independent of the PCICLK. I'm not 100% sure about > > > the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs > > > to be carried out to verify this. > > > > I don't have a KT7A personally, I only have a KT7. Can anyone else with a KT7A > > verify this? By verify, I take it you mean to use idebus=33 and overclock > > PCICLK? :) At least that would determine if UDMA100 is based on PCI or an > > external 100MHz source. > > Actually he should use the correct idebus= so that the Active/Recover > timings are correct. If KT7A doesn't work with UDMA at high PCI clocks > *even when* idebus= is correct would mean that the UDMA timing is in > 1/(PCICLK*3) units instead of units of 10ns. > > Anyone help us? > > -- > Vojtech Pavlik > SuSE Labs I for one dont use the KT7 motherboardsbut i know from experience that increasing the FSB only effects ram speed ( at least negatively anyway) i have 100Mhz ram and 133Mhz ram so once i'm at 114Mhz the 100Mhz ram cant handle too much more .. so 114Mhz is what i stay at. My PCI clock is not changed at all and so far (for the last couple days) the hdd's on my idebus have not had any problems what so ever. Sorry but i've only got UDMA66 drives and idebus is whatever the 2.2.x kernel defaults to.I'm guessing any sort of corruption caused by 2.4.x had something to do with that dirty page writes mail that was sent to the list a while ago and was probably fixed but never made it to the changelog. I'll stick to 2.2 until 2.5 though just in case.What would be interesting is figuring out why the kernel can't recover somehow from infinite ide irq reset loops which are usually brought on by dma timeouts. That would at least somewhat usefull for when they actually happen (I saw them numerous times in 2.4.x but not since going back to 2.2.x). - 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
Vojtech Pavlik wrote: > On Wed, Jan 31, 2001 at 08:52:58PM -0500, safemode wrote: > > > My KA7 can go over 160Mhz FSB > > Yes i know about memory speed limitions ..that's why you are able to choose > > HW clock - PCI so at those high speeds it's actually say 120Mhz - 33 > > keeping you below or near 100 and not well over the spec of the ram.Anyway i > > dont go that high110 is safe an doesn't cause any heat increase and gives me > > 100Mhz more. nbench shows my performance about equal to t-bird 1ghz. at least in > > memory and integer. The KA7 lets you increase the FSB without increasing the > > PCI bus speed, so i dont have to worry about changing ide bus timings, PCI is > > still at 33 - 34 not enough to hurt any cards. > > Ugh. What chips your KA7 has? As far as I know the KX133 chip (vt8731) > can't do asynchronous PCI, allowing for 2x, 3x and 4x FSB/PCI divisors > only. So I don't a way to have your FSB at 114 and your PCI at 34 with > this chip. Actually it can and it's a simple bios option. I'd show you but it's in the manual and it's hard to scan stuff without a scanner. You can have asynchronous FSB up to 28Mhzso i can have 128Mhz FSB with 33Mhz PCI after that i have to use the synchronous increase which changes PCI as i change the FSB value but the other value gets added onto that asynchronously. It's really a standard feature of this board. I'm not making it up and the proof is me not changing idebus at all and still working after a day at full load and semi-constant usage and MANY compiles. also the bios screen doesn't lie. > > > OK ok.. just forget i ever mentioned it .. It has nothing to do with anything > > i've been talking about problem wise because i _JUST_ did it now ... It is the > > cause of nothing because they all happened before i did anything to the speed. > > This is a 2.4.x kernel problem. It has nothing to do with overclocking because at > > the time i didn't. When i used 2.2.x it did not have any problems and i did not > > overclock.As of now i have no problems with ide resets or dma timeouts (which > > is what i said before), regardless of if i'm overclocking it now or not. It's > > working great (better than great) without changing anyhing in 2.2.19-pre7. > > heh. so everyone can stop flipping out over overclocking because i made sure > > hardware settings were default failsafe even before deciding it was definitely a > > kernel problem and i never had the settings over spec before the problem surfaced. > > Ok. So do you still have a working 2.2 setup and a non-working 2.4 > setup? Would you be able to send me the usual (lspci -vvxxx, dmesg, > hdparm -t /dev/hd*, hdparm -i /dev/hd*, cat /proc/ide/via) data for both > so that I can compare them? > > If I find any differences, I'll know what the bug is. > > -- > Vojtech Pavlik > SuSE Labs I cant get anything from 2.4 because I kind of dont want to re-format and re-install debian again and lose my email and logs and config scripts. It's seriously that bad. fsck would say it fixed everything .. I would reboot and immediately it would come up with certain files having IO errors and then inode errors. Strangely though, this didn't occur the very first time i booted with the kernel... it took about 3 days until it happened, but after that it would happen all the time and even after reboots. I even disabled DMA support for both and it still happened . So i really doubt it has to do with the via specific driver for DMA support in the kernel (ie. there is no /proc/ide/via).i'll look into finding some way of running 2.4 so that it cant destroy my filesystems. - 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
Vojtech Pavlik wrote: On Thu, Feb 01, 2001 at 01:20:00PM -0500, Byron Stanoszek wrote: On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote: Yeah, by bios does the same thing too on the Abit KT7(a). Ok, I'll remember this. This is most likely the cause of the problems many people had with the KT7 in the past. What cause are you referring to? As far as I know, there are two options to increasing the FSB clock.. one increases both FSB+PCICLK, the other just increases FSB. If you increase the FSB only, it should keep PCICLK at a solid 33. (But I could be wrong, I've never tested that. I can tomorrow though.) I mean that people can alter the PCI clock on these boards and that 33 doesn't to be always exactly 33 due to rounding errors if used with a FSB other than 66 or 100 or 133. Could it be that the PCI bus is not asynchronous, but only pseudo-synchronous, allowing for divisors of 5, 4.5, 4, 3.5, 3, 2.5, 2? The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that there is an external 100MHz clock fed to the chip, so that the UDMA timing is in T = 10ns increments independent of the PCICLK. I'm not 100% sure about the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs to be carried out to verify this. I don't have a KT7A personally, I only have a KT7. Can anyone else with a KT7A verify this? By verify, I take it you mean to use idebus=33 and overclock PCICLK? :) At least that would determine if UDMA100 is based on PCI or an external 100MHz source. Actually he should use the correct idebus= so that the Active/Recover timings are correct. If KT7A doesn't work with UDMA at high PCI clocks *even when* idebus= is correct would mean that the UDMA timing is in 1/(PCICLK*3) units instead of units of 10ns. Anyone help us? -- Vojtech Pavlik SuSE Labs I for one dont use the KT7 motherboardsbut i know from experience that increasing the FSB only effects ram speed ( at least negatively anyway) i have 100Mhz ram and 133Mhz ram so once i'm at 114Mhz the 100Mhz ram cant handle too much more .. so 114Mhz is what i stay at. My PCI clock is not changed at all and so far (for the last couple days) the hdd's on my idebus have not had any problems what so ever. Sorry but i've only got UDMA66 drives and idebus is whatever the 2.2.x kernel defaults to.I'm guessing any sort of corruption caused by 2.4.x had something to do with that dirty page writes mail that was sent to the list a while ago and was probably fixed but never made it to the changelog. I'll stick to 2.2 until 2.5 though just in case.What would be interesting is figuring out why the kernel can't recover somehow from infinite ide irq reset loops which are usually brought on by dma timeouts. That would at least somewhat usefull for when they actually happen (I saw them numerous times in 2.4.x but not since going back to 2.2.x). - 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
Byron Stanoszek wrote: > On Wed, 31 Jan 2001, safemode wrote: > > > yea i know. . same mode i also had a big problem with DMA timeouts on > > 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 > > hasn't shown a single irq or DMA error yet since going back to it. > > currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. > > hopefully that should have fixed any problems. I get 24MB/s each according > > to hdparm -t on my hdd's and both are on the same channel. This is much > > better than i ever got with 2.4 even when only one drive was on a channel. > > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. > > my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so > > i'm happy with 2.2. The only thing that would make me want to upgrade would > > be latency patches. I'm convinced 2.4 has performance issues so i guess i'll > > be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having > > this Via corruption problem? i doubt it's a bios problem because wouldn't > > 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont > > show any fixes for it. > > If your FSB is running at 114 MHz, you should try the kernel parameter > idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error > on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't > correctly program the PCI card, so you don't see weird behavior running 2.2 > with a faster PCI clock. > > (Note: 1.14 * 33 = 37.6 PCI Clk) > > It also matters what motherboard you're using, and if it can support speeds up > past 100. If you're serious about overclocking, buy one of the new KT133A > boards that support speeds up to 133 (or an average overclocked 145 limit). > > For instance, my Epox KX133 board is unstable at anything above 110 FSB, but > I've seen the Abit KT7 go as high as 116. You should also have some good > memory that is rated for 150MHz, otherwise you're just asking for trouble. My KA7 can go over 160Mhz FSB Yes i know about memory speed limitions ..that's why you are able to choose HW clock - PCI so at those high speeds it's actually say 120Mhz - 33 keeping you below or near 100 and not well over the spec of the ram.Anyway i dont go that high110 is safe an doesn't cause any heat increase and gives me 100Mhz more. nbench shows my performance about equal to t-bird 1ghz. at least in memory and integer. The KA7 lets you increase the FSB without increasing the PCI bus speed, so i dont have to worry about changing ide bus timings, PCI is still at 33 - 34 not enough to hurt any cards. > > As always, if you have problems with the kernel and want to submit a bug > report, please put all the settings back to normal and test thoroughly before > continuing. It's funny how many bug reports I've heard from people who've > overclocked their FSB and expected the IDE DMA to be set appropriately under > 2.4... maybe this should be mentioned somewhere in ide.txt, even though > overclocking is frowned upon. As i mentioned in older emails, i did this _today_ i mentioned this "bug" over two weeks ago. I turned off DMA in the bios and kernel and the "bug" was still present. you can read the old emails and see for yourself. > > Regards, > Byron > > -- > Byron Stanoszek Ph: (330) 644-3059 > Systems Programmer Fax: (330) 644-8110 > Commercial Timesharing Inc. Email: [EMAIL PROTECTED] OK ok.. just forget i ever mentioned it .. It has nothing to do with anything i've been talking about problem wise because i _JUST_ did it now ... It is the cause of nothing because they all happened before i did anything to the speed. This is a 2.4.x kernel problem. It has nothing to do with overclocking because at the time i didn't. When i used 2.2.x it did not have any problems and i did not overclock.As of now i have no problems with ide resets or dma timeouts (which is what i said before), regardless of if i'm overclocking it now or not. It's working great (better than great) without changing anyhing in 2.2.19-pre7. heh. so everyone can stop flipping out over overclocking because i made sure hardware settings were default failsafe even before deciding it was definitely a kernel problem and i never had the settings over spec before the problem surfaced. - 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
Tobias Ringstrom wrote: > On Wed, 31 Jan 2001, safemode wrote: > > > I'm wondering... Perhaps it's a problem motherboard specific. I'm > > using the KA7 and saw pretty bad problems (extreme fs corruption) > > and bad latency. Perhaps the K7V and the KT7's dont have this problem. > > I dont see any of the problems with dma enabled on 2.2.x > > But are you using the same DMA mode in 2.2 as in 2.4? You can check that > using hdparm -i, I believe. > > /Tobias yea i know. . same mode i also had a big problem with DMA timeouts on 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 hasn't shown a single irq or DMA error yet since going back to it. currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. hopefully that should have fixed any problems. I get 24MB/s each according to hdparm -t on my hdd's and both are on the same channel. This is much better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so i'm happy with 2.2. The only thing that would make me want to upgrade would be latency patches. I'm convinced 2.4 has performance issues so i guess i'll be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having this Via corruption problem? i doubt it's a bios problem because wouldn't 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont show any fixes for it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Alan Cox wrote: > > better than i ever got with 2.4 even when only one drive was on a channel. > > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. > > Hint: people who overclock machines get suprising odd results and bad stuff > happens. Please dont waste developers time unless you can reproduce it at > the intended speed for the components Like i said .. i just did that within the last 5 min it has nothing to do with any problems i've been talking about - 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
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. I'm wondering... Perhaps it's a problem motherboard specific. I'm using the KA7 and saw pretty bad problems (extreme fs corruption) and bad latency. Perhaps the K7V and the KT7's dont have this problem. I dont see any of the problems with dma enabled on 2.2.x Output of 2.2.19-pre7 lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [KX133 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: c000-cfff 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 South] (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. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d000 Capabilities: [c0] Power Management version 2 - 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
David Raufeisen wrote:
> On Wednesday, 31 January 2001, at 08:36:42 (+0100),
> Vojtech Pavlik wrote:
>
> > Hi!
> >
> > 1) You don't seem to have any drives on the VIA controller. If this is
> > true, I don't think this can be a VIA IDE driver problem.
> >
>
> Hi, Are you referring to Mark or me?
>
> I have drives on my VIA (only..) IDE controller:
>
> 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
> VP_IDE: ATA-66/100 forced bit set (WARNING)!!
> ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
> VP_IDE: ATA-66/100 forced bit set (WARNING)!!
> ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
> hda: Maxtor 51536H2, ATA DISK drive
> hdb: Maxtor 94098U8, ATA DISK drive
> hdc: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
> hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66)
> hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.12
> Partition check:
> hda: hda1 hda2
> hdb: hdb1
>
> > 2) In your original message you suggest bs=1024M, which isn't a very
> > good idea, even on a 768 MB system. Here with bs=1024k it seems to run
> > fine.
> >
> > 3) You sent next to none VIA related debugging info. lspci -v itself
> > isn't much valuable because I don't get the register contents. Also
> > hdparm -i of the drives attached to the VIA chip would be useful. Plus
> > also the contents of /proc/ide/via.
>
> I didn't supply anything either, even though my configuration works great it
> might prove useful to someone comparing:
>
> bash-2.04# hdparm -i /dev/hda
>
> /dev/hda:
>
> Model=Maxtor 51536H2, FwRev=JAC61HU0, SerialNo=F203VTHC
> Config={ Fixed }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
> BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30015216
> 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 udma5
> bash-2.04# hdparm -i /dev/hdb
>
> /dev/hdb:
>
> Model=Maxtor 94098U8, FwRev=FA500S60, SerialNo=G8066RQC
> Config={ Fixed }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
> BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
> CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=80041248
> 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
> bash-2.04#
>
> bash-2.04# cat /proc/ide/via
> --VIA BusMastering IDE Configuration
> Driver Version: 2.1e
> South Bridge: VIA vt82c686a rev 0x22
> Command register: 0x7
> Latency timer: 32
> PCI clock: 33MHz
> Master Read Cycle IRDY:0ws
> Master Write Cycle IRDY:0ws
> FIFO Output Data 1/2 Clock Advance: off
> BM IDE Status Register Read Retry: on
> Max DRDY Pulse Width: No limit
> ---Primary IDE---Secondary IDE--
> Read DMA FIFO flush: on on
> End Sect. FIFO flush: on on
> Prefetch Buffer: on on
> Post Write Buffer: on on
> FIFO size: 8 8
> Threshold Prim.: 1/2 1/2
> Bytes Per Sector: 512 512
> Both channels togth: yes yes
> ---drive0drive1drive2drive3-
> BMDMA enabled:yes yes yesno
> Transfer Mode: UDMA UDMA UDMA DMA/PIO
> Address Setup: 30ns 30ns 30ns 120ns
> Active Pulse:90ns 90ns 90ns 330ns
> Recovery Time: 30ns 30ns 30ns 270ns
> Cycle Time: 30ns 30ns 60ns 600ns
> Transfer Rate: 66.0MB/s 66.0MB/s 33.0MB/s 3.3MB/s
>
> bash-2.04# lspci -v (trimmed)
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
> Flags: bus master, medium devsel, latency 8
> Memory at e000 (32-bit, prefetchable) [size=64M]
> Capabilities: [a0] AGP version 2.0
> Capabilities: [c0] Power Management version 2
>
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 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
Re: VT82C686A corruption with 2.4.x
David Raufeisen wrote:
On Wednesday, 31 January 2001, at 08:36:42 (+0100),
Vojtech Pavlik wrote:
Hi!
1) You don't seem to have any drives on the VIA controller. If this is
true, I don't think this can be a VIA IDE driver problem.
Hi, Are you referring to Mark or me?
I have drives on my VIA (only..) IDE controller:
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
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 51536H2, ATA DISK drive
hdb: Maxtor 94098U8, ATA DISK drive
hdc: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66)
hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: hda1 hda2
hdb: hdb1
2) In your original message you suggest bs=1024M, which isn't a very
good idea, even on a 768 MB system. Here with bs=1024k it seems to run
fine.
3) You sent next to none VIA related debugging info. lspci -v itself
isn't much valuable because I don't get the register contents. Also
hdparm -i of the drives attached to the VIA chip would be useful. Plus
also the contents of /proc/ide/via.
I didn't supply anything either, even though my configuration works great it
might prove useful to someone comparing:
bash-2.04# hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 51536H2, FwRev=JAC61HU0, SerialNo=F203VTHC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30015216
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 udma5
bash-2.04# hdparm -i /dev/hdb
/dev/hdb:
Model=Maxtor 94098U8, FwRev=FA500S60, SerialNo=G8066RQC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=80041248
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
bash-2.04#
bash-2.04# cat /proc/ide/via
--VIA BusMastering IDE Configuration
Driver Version: 2.1e
South Bridge: VIA vt82c686a rev 0x22
Command register: 0x7
Latency timer: 32
PCI clock: 33MHz
Master Read Cycle IRDY:0ws
Master Write Cycle IRDY:0ws
FIFO Output Data 1/2 Clock Advance: off
BM IDE Status Register Read Retry: on
Max DRDY Pulse Width: No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush: on on
End Sect. FIFO flush: on on
Prefetch Buffer: on on
Post Write Buffer: on on
FIFO size: 8 8
Threshold Prim.: 1/2 1/2
Bytes Per Sector: 512 512
Both channels togth: yes yes
---drive0drive1drive2drive3-
BMDMA enabled:yes yes yesno
Transfer Mode: UDMA UDMA UDMA DMA/PIO
Address Setup: 30ns 30ns 30ns 120ns
Active Pulse:90ns 90ns 90ns 330ns
Recovery Time: 30ns 30ns 30ns 270ns
Cycle Time: 30ns 30ns 60ns 600ns
Transfer Rate: 66.0MB/s 66.0MB/s 33.0MB/s 3.3MB/s
bash-2.04# lspci -v (trimmed)
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
Flags: bus master, medium devsel, latency 8
Memory at e000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 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: dde0-dfef
Prefetchable memory behind bridge: cdc0-ddcf
Capabilities: [80] Power
Re: VT82C686A corruption with 2.4.x
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. I'm wondering... Perhaps it's a problem motherboard specific. I'm using the KA7 and saw pretty bad problems (extreme fs corruption) and bad latency. Perhaps the K7V and the KT7's dont have this problem. I dont see any of the problems with dma enabled on 2.2.x Output of 2.2.19-pre7 lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [KX133 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: c000-cfff 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 South] (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. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d000 Capabilities: [c0] Power Management version 2 - 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
Alan Cox wrote: better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. Hint: people who overclock machines get suprising odd results and bad stuff happens. Please dont waste developers time unless you can reproduce it at the intended speed for the components Like i said .. i just did that within the last 5 min it has nothing to do with any problems i've been talking about - 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
Tobias Ringstrom wrote: On Wed, 31 Jan 2001, safemode wrote: I'm wondering... Perhaps it's a problem motherboard specific. I'm using the KA7 and saw pretty bad problems (extreme fs corruption) and bad latency. Perhaps the K7V and the KT7's dont have this problem. I dont see any of the problems with dma enabled on 2.2.x But are you using the same DMA mode in 2.2 as in 2.4? You can check that using hdparm -i, I believe. /Tobias yea i know. . same mode i also had a big problem with DMA timeouts on 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 hasn't shown a single irq or DMA error yet since going back to it. currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. hopefully that should have fixed any problems. I get 24MB/s each according to hdparm -t on my hdd's and both are on the same channel. This is much better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so i'm happy with 2.2. The only thing that would make me want to upgrade would be latency patches. I'm convinced 2.4 has performance issues so i guess i'll be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having this Via corruption problem? i doubt it's a bios problem because wouldn't 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont show any fixes for it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Byron Stanoszek wrote: On Wed, 31 Jan 2001, safemode wrote: yea i know. . same mode i also had a big problem with DMA timeouts on 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 hasn't shown a single irq or DMA error yet since going back to it. currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. hopefully that should have fixed any problems. I get 24MB/s each according to hdparm -t on my hdd's and both are on the same channel. This is much better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so i'm happy with 2.2. The only thing that would make me want to upgrade would be latency patches. I'm convinced 2.4 has performance issues so i guess i'll be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having this Via corruption problem? i doubt it's a bios problem because wouldn't 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont show any fixes for it. If your FSB is running at 114 MHz, you should try the kernel parameter idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't correctly program the PCI card, so you don't see weird behavior running 2.2 with a faster PCI clock. (Note: 1.14 * 33 = 37.6 PCI Clk) It also matters what motherboard you're using, and if it can support speeds up past 100. If you're serious about overclocking, buy one of the new KT133A boards that support speeds up to 133 (or an average overclocked 145 limit). For instance, my Epox KX133 board is unstable at anything above 110 FSB, but I've seen the Abit KT7 go as high as 116. You should also have some good memory that is rated for 150MHz, otherwise you're just asking for trouble. My KA7 can go over 160Mhz FSB Yes i know about memory speed limitions ..that's why you are able to choose HW clock - PCI so at those high speeds it's actually say 120Mhz - 33 keeping you below or near 100 and not well over the spec of the ram.Anyway i dont go that high110 is safe an doesn't cause any heat increase and gives me 100Mhz more. nbench shows my performance about equal to t-bird 1ghz. at least in memory and integer. The KA7 lets you increase the FSB without increasing the PCI bus speed, so i dont have to worry about changing ide bus timings, PCI is still at 33 - 34 not enough to hurt any cards. As always, if you have problems with the kernel and want to submit a bug report, please put all the settings back to normal and test thoroughly before continuing. It's funny how many bug reports I've heard from people who've overclocked their FSB and expected the IDE DMA to be set appropriately under 2.4... maybe this should be mentioned somewhere in ide.txt, even though overclocking is frowned upon. As i mentioned in older emails, i did this _today_ i mentioned this "bug" over two weeks ago. I turned off DMA in the bios and kernel and the "bug" was still present. you can read the old emails and see for yourself. Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] OK ok.. just forget i ever mentioned it .. It has nothing to do with anything i've been talking about problem wise because i _JUST_ did it now ... It is the cause of nothing because they all happened before i did anything to the speed. This is a 2.4.x kernel problem. It has nothing to do with overclocking because at the time i didn't. When i used 2.2.x it did not have any problems and i did not overclock.As of now i have no problems with ide resets or dma timeouts (which is what i said before), regardless of if i'm overclocking it now or not. It's working great (better than great) without changing anyhing in 2.2.19-pre7. heh. so everyone can stop flipping out over overclocking because i made sure hardware settings were default failsafe even before deciding it was definitely a kernel problem and i never had the settings over spec before the problem surfaced. - 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: More on the VIA KT133 chipset misbehaving in Linux
Adrian Cox wrote: > Dylan Griffiths wrote: > > The VIA KT133 chipset exhibits the following bugs under Linux 2.2.17 and > > 2.4.0: > > 1) PS/2 mouse cursor randomly jumps to upper right hand corner of screen and > > locks for a bit > > This happens to me about once a month on a BX chipset PII machine here, > and on a KT133 chipset machine I have. I have to hit ctrl-alt-backspace > to regain control of the console. I always assumed it was a bug in X, > but it never caused me enough trouble to actually make me pursue it. > > - Adrian > turn off gpm.. fixes the mouse problem immediately. as in killall -9 gpm before starting X. - 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: More on the VIA KT133 chipset misbehaving in Linux
Adrian Cox wrote: Dylan Griffiths wrote: The VIA KT133 chipset exhibits the following bugs under Linux 2.2.17 and 2.4.0: 1) PS/2 mouse cursor randomly jumps to upper right hand corner of screen and locks for a bit This happens to me about once a month on a BX chipset PII machine here, and on a KT133 chipset machine I have. I have to hit ctrl-alt-backspace to regain control of the console. I always assumed it was a bug in X, but it never caused me enough trouble to actually make me pursue it. - Adrian turn off gpm.. fixes the mouse problem immediately. as in killall -9 gpm before starting X. - 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 Cpu usuage (display oddities more than anything)
Linda Walsh wrote: > Some oddities w/kapmd(2.4.0)... If I sit in X and do nothing other than run top or > "vmstat 5", I get down to as low as 60% idle and 40% in system -- with kapmd getting > 'charged' for the 40%. > > Then I go and run 'freeamp' and the CPU usage goes to 100% idle, presumably because > kapmd never gets called because it's never in the idle loop for longer than 333ms. > > It's just weird and unnatural. > > Also forgive my ignorance but is it really possible playing VBR MP3's takes 0 >measurable > CPU? I've run the program for hours and a ps of 'freeamp' show either no measured >cpu > time or maybe 1 second...the kernel runs at at 100% idle for most of the time. > I thought mp3 decompression was a cpu intensive operationweird... > > I guess I'm thinking -- maybe time in kapmd should be counted as 'idle'? > freeamp is just that good. I've seen 0% cpu usage with it on 2.4 and 2.2. if you notice closely, it does use a percentage of cpu but it's so small that over the course of time that the cpu usage of each process is averaged, it is closer to 0 than 1. It is hands down the best mp3 player i've seen out. - 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 Cpu usuage (display oddities more than anything)
Linda Walsh wrote: Some oddities w/kapmd(2.4.0)... If I sit in X and do nothing other than run top or "vmstat 5", I get down to as low as 60% idle and 40% in system -- with kapmd getting 'charged' for the 40%. Then I go and run 'freeamp' and the CPU usage goes to 100% idle, presumably because kapmd never gets called because it's never in the idle loop for longer than 333ms. It's just weird and unnatural. Also forgive my ignorance but is it really possible playing VBR MP3's takes 0 measurable CPU? I've run the program for hours and a ps of 'freeamp' show either no measured cpu time or maybe 1 second...the kernel runs at at 100% idle for most of the time. I thought mp3 decompression was a cpu intensive operationweird... I guess I'm thinking -- maybe time in kapmd should be counted as 'idle'? freeamp is just that good. I've seen 0% cpu usage with it on 2.4 and 2.2. if you notice closely, it does use a percentage of cpu but it's so small that over the course of time that the cpu usage of each process is averaged, it is closer to 0 than 1. It is hands down the best mp3 player i've seen out. - 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 apollo KX133 ide bug in 2.4.x
Peter Horton wrote: > On Thu, Jan 20, 2000 at 08:38:12AM +, Peter Horton wrote: > > > > I think I'm suffering the same thing on my new Asus A7V. Yesterday I got a > > single "error in bitmap, remounting read only" type error, and today I got > > some files in /tmp that returned I/O error when stat()ed. I do have DMA > > enabled, but only UDMA33. I've done several kernel compiles with no > > problems at all so looks like something is on the edge. Think I might go > > back to 2.2.x for a bit and see what happens, or maybe just remove the VIA > > driver :-((. > > > > I apologise for following up my own E-mail, but there is something I'm > missing here (maybe a whole lot of something). Anyone know how come we're > seeing silent corruption ... I thought this UDMA stuff was all checksummed > ? If there error is outside the data I assume the driver would notice ? > > P. The thing is, even with UDMA disabled in the kernel, I still see the corruption with 2.4.x (release) and above. Anything written while using the kernel is corrupted. Much of the stuff will read fine (files) ... but I believe directories get the IO error immediately and some files do also. Everything is seen as corrupted when you fsck a partition where this kernel has been run and created files on. This is a silent corruption without any errors reported and I've only tested it on ext2. You cannot create FS's with these kernels (at least on the VIA chipsets) since they too are corrupted (note, only tested ext2 fs). I did disable UDMA everywhere and still saw it happen, this problem is not present in older 2.4.0-test kernels so it's something in the late pre-release stage and into the release stage. - 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 apollo KX133 ide bug in 2.4.x
Peter Horton wrote: On Thu, Jan 20, 2000 at 08:38:12AM +, Peter Horton wrote: I think I'm suffering the same thing on my new Asus A7V. Yesterday I got a single "error in bitmap, remounting read only" type error, and today I got some files in /tmp that returned I/O error when stat()ed. I do have DMA enabled, but only UDMA33. I've done several kernel compiles with no problems at all so looks like something is on the edge. Think I might go back to 2.2.x for a bit and see what happens, or maybe just remove the VIA driver :-((. I apologise for following up my own E-mail, but there is something I'm missing here (maybe a whole lot of something). Anyone know how come we're seeing silent corruption ... I thought this UDMA stuff was all checksummed ? If there error is outside the data I assume the driver would notice ? P. The thing is, even with UDMA disabled in the kernel, I still see the corruption with 2.4.x (release) and above. Anything written while using the kernel is corrupted. Much of the stuff will read fine (files) ... but I believe directories get the IO error immediately and some files do also. Everything is seen as corrupted when you fsck a partition where this kernel has been run and created files on. This is a silent corruption without any errors reported and I've only tested it on ext2. You cannot create FS's with these kernels (at least on the VIA chipsets) since they too are corrupted (note, only tested ext2 fs). I did disable UDMA everywhere and still saw it happen, this problem is not present in older 2.4.0-test kernels so it's something in the late pre-release stage and into the release stage. - 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 apollo KX133 ide bug in 2.4.x
I'm sorry I can't be more descriptive than that, but there aren't any errors ever displayed. What happened was after about a day of uptime, I began seeing IO errors when trying to access files. I realized that the IO errors occurred on any file I had created. I rebooted since the computer became impossible to use and fsck removed everything that I had created since upgrading to the release kernel. This is all on ext2fs. I tried making bootdisks but they all showed up as being bad. I tried copying files to another ext2fs but upon fsck, they too were all removed due to corruption. These ext2fs' were not created by the release kernel. I had to go back to 2.4.0-test11 before the kernel would write to the fs correctly. For the record, I disabled DMA in the kernel and i'm compiling for athlon using gcc 2.95.3. I saw the same thing happen though when I booted for a kernel compiled for Pentium 2.Since reverting back to 2.4.0-test11, however, no FS corruption has been observed. Anyone have any idea what this is about? i'm compiling with the same options between kernels but 2.4.x (release and newer) do not seem to be able to write to the ext2fs correctly. Could this be because it was formatted by a 2.2.x kernel? Anyone using this chipset I would caution to have backups ready when using it with 2.4.x, as I lost hundreds of files to it. Also, no errors were reported anywhere, IO errors when trying to stat dirs just started appearing after a couple days uptime ...then they would occur whenever you wrote to the FS. Even after a reboot.If you need any extra iinfo about kernel options and computer config, just ask. - 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 apollo KX133 ide bug in 2.4.x
I'm sorry I can't be more descriptive than that, but there aren't any errors ever displayed. What happened was after about a day of uptime, I began seeing IO errors when trying to access files. I realized that the IO errors occurred on any file I had created. I rebooted since the computer became impossible to use and fsck removed everything that I had created since upgrading to the release kernel. This is all on ext2fs. I tried making bootdisks but they all showed up as being bad. I tried copying files to another ext2fs but upon fsck, they too were all removed due to corruption. These ext2fs' were not created by the release kernel. I had to go back to 2.4.0-test11 before the kernel would write to the fs correctly. For the record, I disabled DMA in the kernel and i'm compiling for athlon using gcc 2.95.3. I saw the same thing happen though when I booted for a kernel compiled for Pentium 2.Since reverting back to 2.4.0-test11, however, no FS corruption has been observed. Anyone have any idea what this is about? i'm compiling with the same options between kernels but 2.4.x (release and newer) do not seem to be able to write to the ext2fs correctly. Could this be because it was formatted by a 2.2.x kernel? Anyone using this chipset I would caution to have backups ready when using it with 2.4.x, as I lost hundreds of files to it. Also, no errors were reported anywhere, IO errors when trying to stat dirs just started appearing after a couple days uptime ...then they would occur whenever you wrote to the FS. Even after a reboot.If you need any extra iinfo about kernel options and computer config, just ask. - 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: ip_conntrack locks up hard on 2.4.0 after about 10 hours
Setiathome 3.03 and 3.x most likely causes the ip_conntrack errors which quickly brings the system to a screetching network halt. I suggest nobody run setiathome on their firewall/gateway/router if they're using iptables with 2.4.x. Not sure how it causes this error nor would it matter to me since i wouldn't be able to recode the client anyway. I'm sure there are setiathome developers (at least one) paying attention to this list. The client is broken. safemode wrote: It seems that for one reason or another, ip_conntrack totally locks (not removeable) after about 10 hours of continued use. All i found were these messages in my dmesg output Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5d9e, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5b2f, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x56bb, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x217db, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x2363e, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x21b64, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x1fa85, caller=c01a6bf1 This makes it impossible to make any sort of network socket connection and all prior connections died. As i said you cannot remove the module to reset ip_conntrack and i'm not sure what could have caused this as it did work up until i woke up this morning, with a total running time of about 10 hours or so. I'd consider this bug rather important, if anyone thinks this is not an ip_conntrack bug and rather something that has changed that i havn't read about, help would be nice. :) i have been using iptables since it came out though and ip_conntrack has only been bad once before, on test5 when it wouldn't kill old dead socket connections and eventually starved itself of free sockets.
ip_conntrack locks up hard on 2.4.0 after about 10 hours
It seems that for one reason or another, ip_conntrack totally locks (not removeable) after about 10 hours of continued use. All i found were these messages in my dmesg output Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5d9e, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5b2f, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x56bb, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x217db, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x2363e, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x21b64, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x1fa85, caller=c01a6bf1 This makes it impossible to make any sort of network socket connection and all prior connections died. As i said you cannot remove the module to reset ip_conntrack and i'm not sure what could have caused this as it did work up until i woke up this morning, with a total running time of about 10 hours or so. I'd consider this bug rather important, if anyone thinks this is not an ip_conntrack bug and rather something that has changed that i havn't read about, help would be nice. :)i have been using iptables since it came out though and ip_conntrack has only been bad once before, on test5 when it wouldn't kill old dead socket connections and eventually starved itself of free sockets. - 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/
ip_conntrack locks up hard on 2.4.0 after about 10 hours
It seems that for one reason or another, ip_conntrack totally locks (not removeable) after about 10 hours of continued use. All i found were these messages in my dmesg output Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5d9e, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5b2f, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x56bb, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x217db, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x2363e, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x21b64, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x1fa85, caller=c01a6bf1 This makes it impossible to make any sort of network socket connection and all prior connections died. As i said you cannot remove the module to reset ip_conntrack and i'm not sure what could have caused this as it did work up until i woke up this morning, with a total running time of about 10 hours or so. I'd consider this bug rather important, if anyone thinks this is not an ip_conntrack bug and rather something that has changed that i havn't read about, help would be nice. :)i have been using iptables since it came out though and ip_conntrack has only been bad once before, on test5 when it wouldn't kill old dead socket connections and eventually starved itself of free sockets. - 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: ip_conntrack locks up hard on 2.4.0 after about 10 hours
Setiathome 3.03 and 3.x most likely causes the ip_conntrack errors which quickly brings the system to a screetching network halt. I suggest nobody run setiathome on their firewall/gateway/router if they're using iptables with 2.4.x. Not sure how it causes this error nor would it matter to me since i wouldn't be able to recode the client anyway. I'm sure there are setiathome developers (at least one) paying attention to this list. The client is broken. safemode wrote: It seems that for one reason or another, ip_conntrack totally locks (not removeable) after about 10 hours of continued use. All i found were these messages in my dmesg output Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5d9e, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5b2f, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x56bb, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x217db, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x2363e, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x21b64, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x1fa85, caller=c01a6bf1 This makes it impossible to make any sort of network socket connection and all prior connections died. As i said you cannot remove the module to reset ip_conntrack and i'm not sure what could have caused this as it did work up until i woke up this morning, with a total running time of about 10 hours or so. I'd consider this bug rather important, if anyone thinks this is not an ip_conntrack bug and rather something that has changed that i havn't read about, help would be nice. :) i have been using iptables since it came out though and ip_conntrack has only been bad once before, on test5 when it wouldn't kill old dead socket connections and eventually starved itself of free sockets.
Re: ACPI in Via Apollo (vt82C686) broken badly in 2.4.x ?
"Grover, Andrew" wrote: > > From: safemode [mailto:[EMAIL PROTECTED]] > > > Well, it seems the only way to look at sensor readings with > > lmsensors is > > to activate acpi in linux for my motherboard. > > Can you please send me the output from dmesg, as well as /proc/interrupts? I > don't think anyone's tried lmsensors and acpi. It may be that they will need > some work to coexist.. > > > According to > > the docs, my > > motherboard is supposed to be supported and is detected when linux > > boots, the problem comes when i try to move the mouse (in console and > > X). It totally flips out, i get irregular mouse movement across the > > screen and button clicks when i just barely touched it. It > > is directly > > related to enabling acpi so i was wondering if anyone else > > has had this > > problem and if there was/is a fix for it or if it's a bug right now. > > If there is specific debugging info that i can get to help, tell me > > where... dmesg just shows successful messages. > > Never seen that before.. does /proc/interrupts indicate mouse driver and > acpi are sharing one? > > Regards -- Andy (ACPI maintainer) The problem wasn't actually with lmsensors together with ACPI yet... Just enabling ACPI with this board causes the mouse to go insane. i will however recompile the stock 2.4.0 kernel that recently came out to test it again. I'll give you output from dmesg and /proc/interrupts before lmsensors is loaded and after (after a new recompile of the drivers too). I can tell you know though, the acpi bus? is running on int 5 according to the bios. ... Should have the output ready within the hour. - 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: ACPI in Via Apollo (vt82C686) broken badly in 2.4.x ?
"Grover, Andrew" wrote: From: safemode [mailto:[EMAIL PROTECTED]] Well, it seems the only way to look at sensor readings with lmsensors is to activate acpi in linux for my motherboard. Can you please send me the output from dmesg, as well as /proc/interrupts? I don't think anyone's tried lmsensors and acpi. It may be that they will need some work to coexist.. According to the docs, my motherboard is supposed to be supported and is detected when linux boots, the problem comes when i try to move the mouse (in console and X). It totally flips out, i get irregular mouse movement across the screen and button clicks when i just barely touched it. It is directly related to enabling acpi so i was wondering if anyone else has had this problem and if there was/is a fix for it or if it's a bug right now. If there is specific debugging info that i can get to help, tell me where... dmesg just shows successful messages. Never seen that before.. does /proc/interrupts indicate mouse driver and acpi are sharing one? Regards -- Andy (ACPI maintainer) The problem wasn't actually with lmsensors together with ACPI yet... Just enabling ACPI with this board causes the mouse to go insane. i will however recompile the stock 2.4.0 kernel that recently came out to test it again. I'll give you output from dmesg and /proc/interrupts before lmsensors is loaded and after (after a new recompile of the drivers too). I can tell you know though, the acpi bus? is running on int 5 according to the bios. ... Should have the output ready within the hour. - 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/
ACPI in Via Apollo (vt82C686) broken badly in 2.4.x ?
Well, it seems the only way to look at sensor readings with lmsensors is to activate acpi in linux for my motherboard. According to the docs, my motherboard is supposed to be supported and is detected when linux boots, the problem comes when i try to move the mouse (in console and X). It totally flips out, i get irregular mouse movement across the screen and button clicks when i just barely touched it. It is directly related to enabling acpi so i was wondering if anyone else has had this problem and if there was/is a fix for it or if it's a bug right now. If there is specific debugging info that i can get to help, tell me where... dmesg just shows successful messages. - 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/
ACPI in Via Apollo (vt82C686) broken badly in 2.4.x ?
Well, it seems the only way to look at sensor readings with lmsensors is to activate acpi in linux for my motherboard. According to the docs, my motherboard is supposed to be supported and is detected when linux boots, the problem comes when i try to move the mouse (in console and X). It totally flips out, i get irregular mouse movement across the screen and button clicks when i just barely touched it. It is directly related to enabling acpi so i was wondering if anyone else has had this problem and if there was/is a fix for it or if it's a bug right now. If there is specific debugging info that i can get to help, tell me where... dmesg just shows successful messages. - 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: Abysmal RAID 0 performance on 2.4.0-test10 for IDE?
Ruth Ivimey-Cook wrote: > > On IDE, you don't. IDE never supports hot-swap, RAID or no. If you want > that, use SCSI. That's not necessarily true. There is work in linux to support Tri-stating the ide devices with the help of a custom card that will allow one to cut power to a specific ide device. Tri-stating allows Hot Swapping of ide devices now. I even had a picture of the device the person is using to hot swap. I'm sorry that I have forgotten this kernel hackers name as i have lost the original email Along with said picture. I'm pretty sure the person who gave it to me was 2.4.x's IDE guy but I cant be sure right now. - 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: Abysmal RAID 0 performance on 2.4.0-test10 for IDE?
Ruth Ivimey-Cook wrote: On IDE, you don't. IDE never supports hot-swap, RAID or no. If you want that, use SCSI. That's not necessarily true. There is work in linux to support Tri-stating the ide devices with the help of a custom card that will allow one to cut power to a specific ide device. Tri-stating allows Hot Swapping of ide devices now. I even had a picture of the device the person is using to hot swap. I'm sorry that I have forgotten this kernel hackers name as i have lost the original email Along with said picture. I'm pretty sure the person who gave it to me was 2.4.x's IDE guy but I cant be sure right now. - 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: lockups from heavy IDE/CD-ROM usage
Zdenek Kabelac wrote: > Problem: When i am using my harddrive and cdrom, my computer will freeze. > It freezes in two different ways.. sometimes just the harddrive access > will freeze (can still do things in X as long as they dont require the > harddrive), and then everything freezes within a few seconds. or else > everything just locks instntly. the problem is reproducable, all i need to > do is be using the harddrive extensively for a couple separate functions > (like compiling the kernel, and copying a large file) and ripping cd audio > (cd paranoia) and i can lock the system in as little as seconds, or a few > minutes sometimes. This will happen more reliably, and much quicker and This is really very similar to my problem with BP6 I'm reporting for a long long time. But everyone says its faulty board. For BP6 somehow helps to set UDMA to mode 2. (I'm not getting these locks when I'm just using ATA33 controler) (hdparm -X66 /dev/hdX) Also could you look at what is being written to console ? (run those intesive programs and stay on console - BP6 lock with this message displayed: hdf: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout: func only 14 In this point it looks like timers are dead... :( And the situation is the same with SMP & NoSMP kernel with apic & noapic. I get this on the 440LX with the same DMA timeout message. Everyone says it's the board's fault as well. Funny. Anyways this happens accross just about any Dev kernel but more so in the -test12 and up versions. . Test10 works fine without locking. Blaming the hardware reminds me of the help given by some other company I can't seem to remember the name to.
Re: lockups from heavy IDE/CD-ROM usage
Zdenek Kabelac wrote: > Problem: When i am using my harddrive and cdrom, my computer will freeze. > It freezes in two different ways.. sometimes just the harddrive access > will freeze (can still do things in X as long as they dont require the > harddrive), and then everything freezes within a few seconds. or else > everything just locks instntly. the problem is reproducable, all i need to > do is be using the harddrive extensively for a couple separate functions > (like compiling the kernel, and copying a large file) and ripping cd audio > (cd paranoia) and i can lock the system in as little as seconds, or a few > minutes sometimes. This will happen more reliably, and much quicker and This is really very similar to my problem with BP6 I'm reporting for a long long time. But everyone says its faulty board. For BP6 somehow helps to set UDMA to mode 2. (I'm not getting these locks when I'm just using ATA33 controler) (hdparm -X66 /dev/hdX) Also could you look at what is being written to console ? (run those intesive programs and stay on console - BP6 lock with this message displayed: hdf: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout: func only 14 In this point it looks like timers are dead... :( And the situation is the same with SMP NoSMP kernel with apic noapic. I get this on the 440LX with the same DMAtimeout message. Everyone says it's the board's fault as well. Funny. Anyways this happens accross just about any Dev kernel but more so in the -test12 and up versions. . Test10 works fine without locking. Blaming the hardware reminds me of the help given by some other company I can't seem to remember the name to.
IDE bugs for intel 440LX chipset in Test12?
All I can say right now is that enabling DMA on a 440LX chipset with 2.4.0-test12 or any other kernel I can remember has caused DMA timeout and ide-reset problems. Disabling dma on the harddrives doesn't help that much either, I still get ide resets. What I'm looking for right now is some information on how to log what the kernel recieves from the harddrive and possibly what it sends so I can give rik some better information on what's going on in this chipset. Thanks. - 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/
IDE bugs for intel 440LX chipset in Test12?
All I can say right now is that enabling DMA on a 440LX chipset with 2.4.0-test12 or any other kernel I can remember has caused DMA timeout and ide-reset problems. Disabling dma on the harddrives doesn't help that much either, I still get ide resets. What I'm looking for right now is some information on how to log what the kernel recieves from the harddrive and possibly what it sends so I can give rik some better information on what's going on in this chipset. Thanks. - 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: 'holey files' not holey enough.
On Wed, 29 Nov 2000 17:36:12 Marc Mutz wrote: > kernel 2.2.17, '/' being a 1k blocksize ext2fs: > > root@adam:/ > dd if=/dev/zero of=holed.file bs=1000 seek=5000 count=1000 > 1000+0 records in > 1000+0 records out > root@adam:/ > ls -l holed.file > -rw-r--r-- 1 root root 600 Nov 29 23:33 holed.file > root@adam:/ > du -sh holed.file > 5.7Mholed.file > > Now that seems funny. why is 5.7MB funny with 600 bytes ? or are you talking about something else? Don't forget that BYTES and thus MEGABYTES are found by powers of 2. They do not function like the decimal "bits". quick way to do the conversion is divide bytes by 1024 to get Kilobytes and then again by 1024 to get Megabytes. This is how it should be displayed. Or am i missing the point of your comment? > Marc > > -- > Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/ > University of Bielefeld, Dep. of Mathematics / Dep. of Physics > > PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) > > - > 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: 'holey files' not holey enough.
On Wed, 29 Nov 2000 17:36:12 Marc Mutz wrote: kernel 2.2.17, '/' being a 1k blocksize ext2fs: root@adam:/ dd if=/dev/zero of=holed.file bs=1000 seek=5000 count=1000 1000+0 records in 1000+0 records out root@adam:/ ls -l holed.file -rw-r--r-- 1 root root 600 Nov 29 23:33 holed.file root@adam:/ du -sh holed.file 5.7Mholed.file Now that seems funny. why is 5.7MB funny with 600 bytes ? or are you talking about something else? Don't forget that BYTES and thus MEGABYTES are found by powers of 2. They do not function like the decimal "bits". quick way to do the conversion is divide bytes by 1024 to get Kilobytes and then again by 1024 to get Megabytes. This is how it should be displayed. Or am i missing the point of your comment? Marc -- Marc Mutz [EMAIL PROTECTED] http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - 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: (iptables) ip_conntrack bug?
On Wed, 15 Nov 2000 16:19:23 Guus Sliepen wrote: > On Wed, Nov 15, 2000 at 03:46:03PM -0500, safemode wrote: > > > I was DDoS'd today while away and came home to find the firewall unable > to > > do anything network related (although my connection to irc was still > > working oddly). a quick dmesg showed the problem. > > ip_conntrack: maximum limit of 2048 entries exceeded > [...] > > I have also seen this happen on a box which ran test9. Apparently because > of > it's long uptime, because the logs should no signs of an attack. > > I guess conntrack forgets to flush some entries? Or maybe there is no way > it can > recover from a full conntrack table? Is it maybe necessary to make the > maximum > size a configurable option? Or a userspace conntrack daemon like the > arpd? I think something is wrong if the ip_conntrack module does not flush it's table after the connections and all that stop. I understand why it does this during the attack...but it doesn't make sense why these tables are kept long after. A userspace tool is not something i think is needed, this piece of code should be in the module, it is either not correctly coded or missing entirely. > I also see a lot of messages like this (on all 2.4 test kernels): > > NAT: 0 dropping untracked packet c00643f0 1 131.211.122.89 -> 224.0.0.2 > NAT: 0 dropping untracked packet c05468e0 1 131.211.122.89 -> 224.0.0.2 > NAT: 0 dropping untracked packet c0064760 1 131.211.122.31 -> 224.0.0.2 > > Turning of multicast on the respective network interface does not stop > these > messages, but anyway they seem rather annoying to me :) Everyone has seen that :) ... that's not exactly what i was talking about the main error message i was worried about was the "ip_conntrack: maximum limit of 2048 entries exceeded" when there was absolutely not traffic coming in and the attack was long since over. I think this is a fairly major bug with the module since it made the firewall inoperable until i reloaded the module.. this DDoS could be repeated on any linux box that is not babysat 24/7 it seems. My firewall drops everything so all the attacker needs to do is get a bunch of sources to send packets (specific? not sure) rapidly enough to fill the ip_conntrack table and your site becomes offline. any other ideas? - 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/
(iptables) ip_conntrack bug?
I was DDoS'd today while away and came home to find the firewall unable to do anything network related (although my connection to irc was still working oddly). a quick dmesg showed the problem. ip_conntrack: maximum limit of 2048 entries exceeded NET: 1 messages suppressed. ip_conntrack: maximum limit of 2048 entries exceeded NET: 3 messages suppressed. ip_conntrack: maximum limit of 2048 entries exceeded NAT: 0 dropping untracked packet c1e69980 6 192.168.1.2 -> 206.251.7.30 ip_conntrack: maximum limit of 2048 entries exceeded NAT: 0 dropping untracked packet c1e69b60 6 192.168.1.2 -> 206.251.7.30 ip_conntrack: maximum limit of 2048 entries exceeded That is a very small snippet of dmesg. It seems that ip_conntrack did not flush or reset after the attack, even though everything was fine when i got home. Keep in mind, this was a somewhat massive attack on my network here but is only connected via a DSL line, it seems the attackers sent hundreds or thousands of very small packets resulting in 21000 connection attempts in a short amount of time. Is this a bug with ip_conntrack? this is kernel version 2.4.0-test5, it's been up for 74 days. I had to reload ip_conntrack to flush it and everything worked fine after that.Thanks for any info. ps. If this is a previously discovered bug, is it fixed in the latest kernels? - 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/
(iptables) ip_conntrack bug?
I was DDoS'd today while away and came home to find the firewall unable to do anything network related (although my connection to irc was still working oddly). a quick dmesg showed the problem. ip_conntrack: maximum limit of 2048 entries exceeded NET: 1 messages suppressed. ip_conntrack: maximum limit of 2048 entries exceeded NET: 3 messages suppressed. ip_conntrack: maximum limit of 2048 entries exceeded NAT: 0 dropping untracked packet c1e69980 6 192.168.1.2 - 206.251.7.30 ip_conntrack: maximum limit of 2048 entries exceeded NAT: 0 dropping untracked packet c1e69b60 6 192.168.1.2 - 206.251.7.30 ip_conntrack: maximum limit of 2048 entries exceeded That is a very small snippet of dmesg. It seems that ip_conntrack did not flush or reset after the attack, even though everything was fine when i got home. Keep in mind, this was a somewhat massive attack on my network here but is only connected via a DSL line, it seems the attackers sent hundreds or thousands of very small packets resulting in 21000 connection attempts in a short amount of time. Is this a bug with ip_conntrack? this is kernel version 2.4.0-test5, it's been up for 74 days. I had to reload ip_conntrack to flush it and everything worked fine after that.Thanks for any info. ps. If this is a previously discovered bug, is it fixed in the latest kernels? - 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: (iptables) ip_conntrack bug?
On Wed, 15 Nov 2000 16:19:23 Guus Sliepen wrote: On Wed, Nov 15, 2000 at 03:46:03PM -0500, safemode wrote: I was DDoS'd today while away and came home to find the firewall unable to do anything network related (although my connection to irc was still working oddly). a quick dmesg showed the problem. ip_conntrack: maximum limit of 2048 entries exceeded [...] I have also seen this happen on a box which ran test9. Apparently because of it's long uptime, because the logs should no signs of an attack. I guess conntrack forgets to flush some entries? Or maybe there is no way it can recover from a full conntrack table? Is it maybe necessary to make the maximum size a configurable option? Or a userspace conntrack daemon like the arpd? I think something is wrong if the ip_conntrack module does not flush it's table after the connections and all that stop. I understand why it does this during the attack...but it doesn't make sense why these tables are kept long after. A userspace tool is not something i think is needed, this piece of code should be in the module, it is either not correctly coded or missing entirely. I also see a lot of messages like this (on all 2.4 test kernels): NAT: 0 dropping untracked packet c00643f0 1 131.211.122.89 - 224.0.0.2 NAT: 0 dropping untracked packet c05468e0 1 131.211.122.89 - 224.0.0.2 NAT: 0 dropping untracked packet c0064760 1 131.211.122.31 - 224.0.0.2 Turning of multicast on the respective network interface does not stop these messages, but anyway they seem rather annoying to me :) Everyone has seen that :) ... that's not exactly what i was talking about the main error message i was worried about was the "ip_conntrack: maximum limit of 2048 entries exceeded" when there was absolutely not traffic coming in and the attack was long since over. I think this is a fairly major bug with the module since it made the firewall inoperable until i reloaded the module.. this DDoS could be repeated on any linux box that is not babysat 24/7 it seems. My firewall drops everything so all the attacker needs to do is get a bunch of sources to send packets (specific? not sure) rapidly enough to fill the ip_conntrack table and your site becomes offline. any other ideas? - 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 disk slow? There's help...
On Fri, 20 Oct 2000 15:34:04 Dmitry Pogosyan wrote: > safemode wrote: > > > That's what i was thinking, but 30MB/s seems to be quite an > exaggeration. > > On my > > Intel Corporation 82371AB PIIX4 IDE (rev 01), ide chipset my master > (10.2GB > > maxtor 7200rpm UDMA66) drive i get ~15-16MB/s and on my slave (same > > interface, 20.1GB maxtor 7200rpm UDMA66), i get ~13MB/s. This goes > against > > logic as the bigger the drive the faster the transferrate should be, > and > > it's about half of your estimate of Michael's 40GB. Is this due to the > > slow disk access of 2.4.0-test10-preX ? Or am i experiencing a bug > here? > > Both drives are operating at UDMA33 mode > > Isn't it this a reason ? You are not using UDMA66 Actually, the difference between UDMA33 and UDMA66 mode occurs mostly in the cache, I should be getting in the upwards of 20MB/s with UDMA33, the first drive is gettings speeds i would expect, but the second is drastically slower even though logic of ide drives dictate it should be going faster since it is bigger. At least this is the general pattern you see with ide drives. > > > (according to hdparm) and both > > drives are set to using 32bit, dma, 16 sector read ahead and 16 sector > > multi-access mode. I've posted results i've gotten from bonnie and > > bonnie++ before, in all cases, the performance seems to be lacking for > the > > kind of hardware i have. > > I have 17-18 MB/sec on my Quantum Fireball 6.4GB (5400 rpm) > drive attached to UDMA33 and 14-15 MB/sec on another, also 5400 rpm > (guess Samsung) drive. Both in -c1 -d1 -m16 mode. > > Ah, sorry, this is with ancient 2.2.5 kernel > > > > - 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 disk slow? There's help...
That's what i was thinking, but 30MB/s seems to be quite an exaggeration. On my Intel Corporation 82371AB PIIX4 IDE (rev 01), ide chipset my master (10.2GB maxtor 7200rpm UDMA66) drive i get ~15-16MB/s and on my slave (same interface, 20.1GB maxtor 7200rpm UDMA66), i get ~13MB/s. This goes against logic as the bigger the drive the faster the transferrate should be, and it's about half of your estimate of Michael's 40GB. Is this due to the slow disk access of 2.4.0-test10-preX ? Or am i experiencing a bug here? Both drives are operating at UDMA33 mode (according to hdparm) and both drives are set to using 32bit, dma, 16 sector read ahead and 16 sector multi-access mode. I've posted results i've gotten from bonnie and bonnie++ before, in all cases, the performance seems to be lacking for the kind of hardware i have. On Fri, 20 Oct 2000 14:58:41 Andre Hedrick wrote: > > Michael, > > Whatever card you are using, in you are getting that low I need to know > more info. That drive should cook at 30MB/sec. - 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 disk slow? There's help...
That's what i was thinking, but 30MB/s seems to be quite an exaggeration. On my Intel Corporation 82371AB PIIX4 IDE (rev 01), ide chipset my master (10.2GB maxtor 7200rpm UDMA66) drive i get ~15-16MB/s and on my slave (same interface, 20.1GB maxtor 7200rpm UDMA66), i get ~13MB/s. This goes against logic as the bigger the drive the faster the transferrate should be, and it's about half of your estimate of Michael's 40GB. Is this due to the slow disk access of 2.4.0-test10-preX ? Or am i experiencing a bug here? Both drives are operating at UDMA33 mode (according to hdparm) and both drives are set to using 32bit, dma, 16 sector read ahead and 16 sector multi-access mode. I've posted results i've gotten from bonnie and bonnie++ before, in all cases, the performance seems to be lacking for the kind of hardware i have. On Fri, 20 Oct 2000 14:58:41 Andre Hedrick wrote: Michael, Whatever card you are using, in you are getting that low I need to know more info. That drive should cook at 30MB/sec. - 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 disk slow? There's help...
On Fri, 20 Oct 2000 15:34:04 Dmitry Pogosyan wrote: safemode wrote: That's what i was thinking, but 30MB/s seems to be quite an exaggeration. On my Intel Corporation 82371AB PIIX4 IDE (rev 01), ide chipset my master (10.2GB maxtor 7200rpm UDMA66) drive i get ~15-16MB/s and on my slave (same interface, 20.1GB maxtor 7200rpm UDMA66), i get ~13MB/s. This goes against logic as the bigger the drive the faster the transferrate should be, and it's about half of your estimate of Michael's 40GB. Is this due to the slow disk access of 2.4.0-test10-preX ? Or am i experiencing a bug here? Both drives are operating at UDMA33 mode Isn't it this a reason ? You are not using UDMA66 Actually, the difference between UDMA33 and UDMA66 mode occurs mostly in the cache, I should be getting in the upwards of 20MB/s with UDMA33, the first drive is gettings speeds i would expect, but the second is drastically slower even though logic of ide drives dictate it should be going faster since it is bigger. At least this is the general pattern you see with ide drives. (according to hdparm) and both drives are set to using 32bit, dma, 16 sector read ahead and 16 sector multi-access mode. I've posted results i've gotten from bonnie and bonnie++ before, in all cases, the performance seems to be lacking for the kind of hardware i have. I have 17-18 MB/sec on my Quantum Fireball 6.4GB (5400 rpm) drive attached to UDMA33 and 14-15 MB/sec on another, also 5400 rpm (guess Samsung) drive. Both in -c1 -d1 -m16 mode. Ah, sorry, this is with ancient 2.2.5 kernel - 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-scsi works now "used to be On ide-scsi recorder failure
I think my confusion came from the fact that i didn't need to reference a specific device before the kernel upgrade. As for telling it to use /dev/sg1 or sg0 ... I cant really tell anymore, i'm no longer using that kernel. It probably was an incorrect usage of cdrecord, so i'm sorry for the posts here, or it could have been something stupid like not compiling in scsi generic support (which i'd like to doubt but can't tell now), oh well, everything works now ...i'm going to test out this atapi-direct write support if i figure out how to convince cdrecord to use it. On Sun, 15 Oct 2000 04:51:30 Dax Kelson wrote: > > The error you were getting is the error I get on my system when I > incorrectly try to access the SCSI cdrom device instead of of the SCSI > generic. > > See: > > [root@thud linux]# cdrecord dev=/dev/sr1 -inq > Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jrg Schilling > scsidev: '/dev/sr1' > devname: '/dev/sr1' > scsibus: -2 target: -2 lun: -2 > cdrecord: No such file or directory. Cannot open SCSI driver. > cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are > root. > [root@thud linux]# > > However, when I correctly reference the SCSI generic device, it works: > > [root@thud linux]# cdrecord dev=/dev/sg1 -inq > Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jrg Schilling > scsidev: '/dev/sg1' > devname: '/dev/sg1' > scsibus: -2 target: -2 lun: -2 > Linux sg driver version: 3.1.17 > Using libscg version 'schily-0.1' > Device type: Removable CD-ROM > Version: 2 > Response Format: 2 > Capabilities : SYNC > Vendor_info: 'YAMAHA ' > Identifikation : 'CRW4416S' > Revision : '1.0j' > Device seems to be: Generic mmc CD-RW. > [root@thud linux]# > > In short, I don't think there was a problem, simply incorrect usage of > cdrecord. > > Dax > > > - 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/
ide-scsi works now "used to be On ide-scsi recorder failure
Everything seems to be working great now... i'm using a patch Andre Hedrick gave me and everything works like normal again. Thanks again for everyone's help. Back to burning cds. - 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: On ide-scsi recorder failure
Unfortunally i compile in all the scsi stuff and make ide-cd modular, so i dont know what was compiled in anymore since that kernel tree is gone. I did however recieve a patch to test10-pre3 which seems to be working, will test the actual record part in a bit (and this kernel i know for a fact has scsi generic compiled in)... thanks for the help guys On Sun, 15 Oct 2000 03:46:52 Matthew Dharm wrote: > Hrm.. last time I checked, cdrecord wanted to use the scsi generic (sg) > interface. Is that loaded (or available as a module)? > > Matt > > -- > Matthew Dharm Home: > [EMAIL PROTECTED] > Maintainer, Linux USB Mass Storage Driver > > Da. Am thinkink of carbonated borscht for lonk nights of coding. > -- Pitr > User Friendly, 7/24/1998 > - 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: On ide-scsi recorder failure
this is cdrecord -v -debug -scanbus note that i symlinked pg0 to scd0 since the device didn't exist anyway and cdrecord insists that is the /dev equivilant to 0,0,0. well dev: (NULL POINTER) speed: -1 fs: -1 Cdrecord 1.10a04 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scg__open() -1,-1,-1 PP Bus: -2 Bus: 0 cookie: Bus: 1 cookie: Bus: 2 cookie: Bus: 3 cookie: Bus: 4 cookie: Bus: 5 cookie: Bus: 6 cookie: Bus: 7 cookie: Bus: 8 cookie: Bus: 9 cookie: Bus: 10 cookie: Bus: 11 cookie: Bus: 12 cookie: Bus: 13 cookie: Bus: 14 cookie: Bus: 15 cookie: cdrecord: No such file or directory. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. - 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: On ide-scsi recorder failure
I just did and it told me it wanted /dev/pg0 which did not exist. The problem is /dev/scd0 is the device and cdrecord refuses to believe it's a CDR, it continues to say that it's read-only On Sun, 15 Oct 2000 02:09:39 Matthew Dharm wrote: > Have you tried using the dev=0,0,0 instead of the dev=/dev/ form? > I'm > told by the cdrecord maintainer that it's more reliable that way, and > that > the /dev/ format should not be used. > > What does cdrecord -scanbus show? > > Matt > > On Sun, Oct 15, 2000 at 01:57:24AM -0400, safemode wrote: > > Alright, first off let me say that this cdrecord was working fine with > > 2.4.0-test8. The recorder is on /dev/scd0 and also on /dev/sr0. > maybe > > this has something to do with it? i'm not sure, but cdrecord keeps > saying > > the stats for it are -2,-2,-2when it should be 0,0,0. Does anyone > > know what the hell is going on here? i'm totally lost. I've tried > different > > versions of cdrecord and all the stable versions i had did the same > thing, > > i thought an experimental one would have a better shot at an > experimental > > kernel. > > > > dmesg | grep scsi > > scsi0 : SCSI host adapter emulation for IDE ATAPI devices > > Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 > > sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray > > > > cat /proc/scsi/scsi > > Attached devices: > > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > > Vendor: IDE-CD Model: R/RW 4x4x24 Rev: C12a > > Type: CD-ROM ANSI SCSI revision: 02 > > > > cdrecord -v -debug -inq dev=/dev/sr0 > > dev: /dev/sr0 speed: -1 fs: -1 > > Cdrecord 1.10a04 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg > Schilling > > TOC Type: 1 = CD-ROM > > scsidev: '/dev/sr0' > > devname: '/dev/sr0' > > scsibus: -2 target: -2 lun: -2 > > scg__open(/dev/sr0) -2,-2,-2 > > cdrecord: Read-only file system. Cannot open '/dev/sr0'. Cannot open > SCSI > > driver. > > > > cdrecord -v -debug -inq dev=/dev/scd0 > > dev: /dev/scd0 speed: -1 fs: -1 > > Cdrecord 1.10a04 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg > Schilling > > TOC Type: 1 = CD-ROM > > scsidev: '/dev/scd0' > > devname: '/dev/scd0' > > scsibus: -2 target: -2 lun: -2 > > scg__open(/dev/scd0) -2,-2,-2 > > cdrecord: Read-only file system. Cannot open '/dev/scd0'. Cannot open > SCSI > > driver. > > > > > > > > The fact that it says it's a cd-rom and not a CDR bothers me. Well, > i'm up > > for suggestions. > > > > > -- > Matthew Dharm Home: > [EMAIL PROTECTED] > Maintainer, Linux USB Mass Storage Driver > > Why am I talking to a toilet brush? > -- CEO > User Friendly, 4/30/1998 > - 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. On ide-scsi recorder failure
Oops on one thing, /dev/sr0 is merely a symlink to /dev/scd0, sorry it's pretty late. these are the attributes of /dev/scd0 brw-rw1 root cdrom 11, 0 Sep 10 01:02 /dev/scd0 - 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. On ide-scsi recorder failure
Oops on one thing, /dev/sr0 is merely a symlink to /dev/scd0, sorry it's pretty late. these are the attributes of /dev/scd0 brw-rw1 root cdrom 11, 0 Sep 10 01:02 /dev/scd0 - 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: On ide-scsi recorder failure
I just did and it told me it wanted /dev/pg0 which did not exist. The problem is /dev/scd0 is the device and cdrecord refuses to believe it's a CDR, it continues to say that it's read-only On Sun, 15 Oct 2000 02:09:39 Matthew Dharm wrote: Have you tried using the dev=0,0,0 instead of the dev=/dev/ form? I'm told by the cdrecord maintainer that it's more reliable that way, and that the /dev/ format should not be used. What does cdrecord -scanbus show? Matt On Sun, Oct 15, 2000 at 01:57:24AM -0400, safemode wrote: Alright, first off let me say that this cdrecord was working fine with 2.4.0-test8. The recorder is on /dev/scd0 and also on /dev/sr0. maybe this has something to do with it? i'm not sure, but cdrecord keeps saying the stats for it are -2,-2,-2when it should be 0,0,0. Does anyone know what the hell is going on here? i'm totally lost. I've tried different versions of cdrecord and all the stable versions i had did the same thing, i thought an experimental one would have a better shot at an experimental kernel. dmesg | grep scsi scsi0 : SCSI host adapter emulation for IDE ATAPI devices Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: IDE-CD Model: R/RW 4x4x24 Rev: C12a Type: CD-ROM ANSI SCSI revision: 02 cdrecord -v -debug -inq dev=/dev/sr0 dev: /dev/sr0 speed: -1 fs: -1 Cdrecord 1.10a04 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '/dev/sr0' devname: '/dev/sr0' scsibus: -2 target: -2 lun: -2 scg__open(/dev/sr0) -2,-2,-2 cdrecord: Read-only file system. Cannot open '/dev/sr0'. Cannot open SCSI driver. cdrecord -v -debug -inq dev=/dev/scd0 dev: /dev/scd0 speed: -1 fs: -1 Cdrecord 1.10a04 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '/dev/scd0' devname: '/dev/scd0' scsibus: -2 target: -2 lun: -2 scg__open(/dev/scd0) -2,-2,-2 cdrecord: Read-only file system. Cannot open '/dev/scd0'. Cannot open SCSI driver. The fact that it says it's a cd-rom and not a CDR bothers me. Well, i'm up for suggestions. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Why am I talking to a toilet brush? -- CEO User Friendly, 4/30/1998 - 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-scsi works now used to be On ide-scsi recorder failure
I think my confusion came from the fact that i didn't need to reference a specific device before the kernel upgrade. As for telling it to use /dev/sg1 or sg0 ... I cant really tell anymore, i'm no longer using that kernel. It probably was an incorrect usage of cdrecord, so i'm sorry for the posts here, or it could have been something stupid like not compiling in scsi generic support (which i'd like to doubt but can't tell now), oh well, everything works now ...i'm going to test out this atapi-direct write support if i figure out how to convince cdrecord to use it. On Sun, 15 Oct 2000 04:51:30 Dax Kelson wrote: The error you were getting is the error I get on my system when I incorrectly try to access the SCSI cdrom device instead of of the SCSI generic. See: [root@thud linux]# cdrecord dev=/dev/sr1 -inq Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jrg Schilling scsidev: '/dev/sr1' devname: '/dev/sr1' scsibus: -2 target: -2 lun: -2 cdrecord: No such file or directory. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. [root@thud linux]# However, when I correctly reference the SCSI generic device, it works: [root@thud linux]# cdrecord dev=/dev/sg1 -inq Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jrg Schilling scsidev: '/dev/sg1' devname: '/dev/sg1' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.1.17 Using libscg version 'schily-0.1' Device type: Removable CD-ROM Version: 2 Response Format: 2 Capabilities : SYNC Vendor_info: 'YAMAHA ' Identifikation : 'CRW4416S' Revision : '1.0j' Device seems to be: Generic mmc CD-RW. [root@thud linux]# In short, I don't think there was a problem, simply incorrect usage of cdrecord. Dax - 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: On ide-scsi recorder failure
Alright, first off let me say that this cdrecord was working fine with 2.4.0-test8. The recorder is on /dev/scd0 and also on /dev/sr0. maybe this has something to do with it? i'm not sure, but cdrecord keeps saying the stats for it are -2,-2,-2when it should be 0,0,0. Does anyone know what the hell is going on here? i'm totally lost. I've tried different versions of cdrecord and all the stable versions i had did the same thing, i thought an experimental one would have a better shot at an experimental kernel. dmesg | grep scsi scsi0 : SCSI host adapter emulation for IDE ATAPI devices Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: IDE-CD Model: R/RW 4x4x24 Rev: C12a Type: CD-ROM ANSI SCSI revision: 02 cdrecord -v -debug -inq dev=/dev/sr0 dev: /dev/sr0 speed: -1 fs: -1 Cdrecord 1.10a04 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '/dev/sr0' devname: '/dev/sr0' scsibus: -2 target: -2 lun: -2 scg__open(/dev/sr0) -2,-2,-2 cdrecord: Read-only file system. Cannot open '/dev/sr0'. Cannot open SCSI driver. cdrecord -v -debug -inq dev=/dev/scd0 dev: /dev/scd0 speed: -1 fs: -1 Cdrecord 1.10a04 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '/dev/scd0' devname: '/dev/scd0' scsibus: -2 target: -2 lun: -2 scg__open(/dev/scd0) -2,-2,-2 cdrecord: Read-only file system. Cannot open '/dev/scd0'. Cannot open SCSI driver. The fact that it says it's a cd-rom and not a CDR bothers me. Well, i'm up for suggestions. - 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: Weird device out-of-space error
ok. first this is what df -i gives me FilesystemInodes IUsed IFree IUse% Mounted on /dev/hda41822720 135002 16877188% / so it's not the inode problem. this is what tune2fs -l /dev/hda4 | grep ^Reserved gives me tune2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Reserved block count: 364266 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) I'm not sure what to make of the tune2fs output but from what df -i and df -m shows me, i'm not out of space or inodes. And as for someone else getting this error with open-office, i suspect that somehow, this is on the cvs server side and has nothing to do with my system, unless it's a cvs version incompatibility. - 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/
Weird device out-of-space error
cvs server: cannot rewrite CVS/Entries.Backup: No space left on device These are the sort of errors i'm getting from cvs but this is what df -m tells me on the partition i'm downloading on /dev/hda4 6865 4899 1610 76% / I'm not sure how to test this on a diff program from cvs since it might have to do something with how cvs goes about creating the files. Is anyone aware of a cvs bug? cvs version is Concurrent Versions System (CVS) 1.10.8 (client/server) (packaged in debian woody) By the way, this is Linux version 2.4.0-test9-vm-OOM (rik's vm-oom patch from oct. 6). This has been up for 6 days 14 hours. I dont seem to be getting any out of space errors by any other programs but considering the uptime of this kernel version, i'm not so sure if it's entirely a cvs problem since i've cvs'd bigger stuff than star-office and never got this error. - 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/
Am I the only one with scsi-ide CDR problems?
I'm just wondering if I'm the only person who has had problems with 2.4.0-test9 recording on ide-scsi cdr's? Nobody has posted anything about it and the test10-prex changefiles don't mention it. cdrecord reports very weird results when scanning the scsi bus whereas dmesg shows what one would expect of the ide-scsi detection. anyone? - 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/
Am I the only one with scsi-ide CDR problems?
I'm just wondering if I'm the only person who has had problems with 2.4.0-test9 recording on ide-scsi cdr's? Nobody has posted anything about it and the test10-prex changefiles don't mention it. cdrecord reports very weird results when scanning the scsi bus whereas dmesg shows what one would expect of the ide-scsi detection. anyone? - 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/
has anyone fixed 2.4.0-test9+ ide-scsi cd recording?
The only reason I'm asking this is because nobody has mentioned it and it seems to have gotten put on the back-burner .. i have heard a lot about 2.2.x ide-scsi fixes but nothing about 2.4.0 ... what's the status of this? - 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/
has anyone fixed 2.4.0-test9+ ide-scsi cd recording?
The only reason I'm asking this is because nobody has mentioned it and it seems to have gotten put on the back-burner .. i have heard a lot about 2.2.x ide-scsi fixes but nothing about 2.4.0 ... what's the status of this? - 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: On ide-scsi recording failure
On Sun, 08 Oct 2000 16:37:03 safemode wrote: > I know this passed by the list before but i missed it. How do you get > ide > - scsi cdrecording to work again? or is this a cdrecord incompatibility > issue now? This worked a couple sub-versions ago in test8. anyone > know? > Forgot to mention, this is linux 2.4.0-test9 with rik's latest vm patch. I compiled scsi emu support and scsi cdrom support into the kernel and made ide-cdrom support as module and it's not loaded. I get this in dmesg: SCSI subsystem driver Revision: 1.00 scsi0 : SCSI host adapter emulation for IDE ATAPI devices Vendor: IDE-CDModel: R/RW 4x4x24 Rev: C12a Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.11 When i set cdrecord to sr0, i get read-only device. and device not recognized errors. Here is the output to cdrecord dev=/dev/sr0 -inq Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling scsidev: '/dev/sr0' devname: '/dev/sr0' scsibus: -2 target: -2 lun: -2 cdrecord: Read-only file system. Cannot open '/dev/sr0'. Cannot open SCSI driver As far as I know, you cant have id's below 0, what's wrong here? is this a cdrecord problem due to a change in kernel scsi or is this a kernel scsi bug? - 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/
On ide-scsi recording failure
I know this passed by the list before but i missed it. How do you get ide - scsi cdrecording to work again? or is this a cdrecord incompatibility issue now? This worked a couple sub-versions ago in test8. anyone know? - 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/
On ide-scsi recording failure
I know this passed by the list before but i missed it. How do you get ide - scsi cdrecording to work again? or is this a cdrecord incompatibility issue now? This worked a couple sub-versions ago in test8. anyone know? - 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: [Xpert] Re: Current CVS version of X does indeed break wrt SHM
Keith Packard wrote: > > Odd, Isn't 777 insecure for shared memory segments? > > Yes; Enlightenment does have it's own little set of features... > > [EMAIL PROTECTED]XFree86 Core Team SuSE, Inc. > I recieved a bunch and bunch of these messages when i run out of shm segments. The latest vm patch that was posted in the list seems to do a better job at making the leak slower. But that could also be due to the fact that i know what will make it leak totally immediately and what will just crash the box within 5 min due to shm weirdness The messages are probably not important to this list so i'm not gonna bother posting them. The SHM problem seems to be for the MOST part X's problem. But, i think the part where the kernel crashes because of the SHM leaking and/or OOM is still a kernel problem that needs addressing before 2.4 gets put out. - 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: [Xpert] Re: Current CVS version of X does indeed break wrt SHM
Keith Packard wrote: Odd, Isn't 777 insecure for shared memory segments? Yes; Enlightenment does have it's own little set of features... [EMAIL PROTECTED]XFree86 Core Team SuSE, Inc. I recieved a bunch and bunch of these messages when i run out of shm segments. The latest vm patch that was posted in the list seems to do a better job at making the leak slower. But that could also be due to the fact that i know what will make it leak totally immediately and what will just crash the box within 5 min due to shm weirdness The messages are probably not important to this list so i'm not gonna bother posting them. The SHM problem seems to be for the MOST part X's problem. But, i think the part where the kernel crashes because of the SHM leaking and/or OOM is still a kernel problem that needs addressing before 2.4 gets put out. - 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: Problem with 2.4.0-test9-pre6 seems to be SHM
safemode wrote: > Mark Hahn wrote: > >> this has nothing to do with the linux kernel. >> X itself does not use shm for anything. apps may use >> an X extension (XSHM) which uses shm segments to exchange >> image data without copying through a socket, but that's >> an extension, not inherent to X. >> >> > Ok, compiling using a cvs of X i got a couple hours ago, I'm just >> >> > wondering what the average segment number is for SHM on an X >> session >> > that has been up for a while i'll get back with any sort of >> info >> > on if the SHM problem has been solved with this latest CVS or if >> it >> > continues to look like a kernel SHM problem. So far though, >> > 2.4.0-test8-vm3 is handling the problem Quite well as opposed to >> test9, >> > which died in 2 hours upon booting ...and it didn't have the added >> >> > stress of compiling X. >> > >> > - >> > > > I think it has a lot to do with the kernel, and with X. Since i > havn't upgraded anything but X (and thus the extensions) ... now it's > obvious that X is at fault for providing us with a wonderful shared > memory leak. But, the kernel too, has something to do with it since > test9 seems to be fairly unstable with it, causing all sorts of weird > happenings before totally freezing up like test8-vm3 does. This > problems only manifests in VERY recent X cvs copies so most people > will not see this problem. The problem i'm wondering about is if the > Kernel is handling shared memory correctly or if this is entirely X's > fault. > Somehow i cant help but think this is somehow linked to an OOM problem that has yet to be fixed with the 2.4.0-testX series. It seems suspiciously like the kernel is killing init when X decides it would be peachy to gobble up all the ram. i dont know of any way to prove this though. - 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: Problem with 2.4.0-test9-pre6 seems to be SHM
Mark Hahn wrote: this has nothing to do with the linux kernel. X itself does not use shm for anything. apps may use an X extension (XSHM) which uses shm segments to exchange image data without copying through a socket, but that's an extension, not inherent to X. > Ok, compiling using a cvs of X i got a couple hours ago, I'm just > wondering what the average segment number is for SHM on an X session > that has been up for a while i'll get back with any sort of info > on if the SHM problem has been solved with this latest CVS or if it > continues to look like a kernel SHM problem. So far though, > 2.4.0-test8-vm3 is handling the problem Quite well as opposed to test9, > which died in 2 hours upon booting ...and it didn't have the added > stress of compiling X. > > - I think it has a lot to do with the kernel, and with X. Since i havn't upgraded anything but X (and thus the extensions) ... now it's obvious that X is at fault for providing us with a wonderful shared memory leak. But, the kernel too, has something to do with it since test9 seems to be fairly unstable with it, causing all sorts of weird happenings before totally freezing up like test8-vm3 does. This problems only manifests in VERY recent X cvs copies so most people will not see this problem. The problem i'm wondering about is if the Kernel is handling shared memory correctly or if this is entirely X's fault.
Re: Problem with 2.4.0-test9-pre6 seems to be SHM
Alan Cox wrote: > I have about 16 after 2 days. Thats a fairly typical desktop (gnome panel, > gfm and everything else is a terminal window) Whoa now?! 16 shm segments?if that's true something is terribly wrong with either X or the kernel's handling of shm that's scary. this is currently what i'm seeing after only 30 min of X -- Shared Memory Status segments allocated 2008 pages allocated 13842 pages resident 12281 pages swapped 1120 Swap performance: 5517 attempts 1120 successes -- Semaphore Status used arrays = 0 allocated semaphores = 0 -- Messages: Status allocated queues = 0 used headers = 0 used space = 0 bytes It increases every time i execute the command ipcs -u i am not even running the amount of apps i normally do. This seems to be a leak, but i'm not sure if it's from X or the kernel. I'm leaning towards X at this point. But the real problem i have with is the kernel is crashing when the requests for shm segments goes over the max for a while. (could not mail back directly to alan *shrugs* ) <[EMAIL PROTECTED]>: 194.168.151.1 does not like recipient. 550 rejected: administrative prohibition Giving up on 194.168.151.1. go figure - 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: Problem with 2.4.0-test9-pre6 seems to be SHM
safemode wrote: > Ok, compiling using a cvs of X i got a couple hours ago, I'm just > wondering what the average segment number is for SHM on an X session > that has been up for a while i'll get back with any sort of info > on if the SHM problem has been solved with this latest CVS or if it > continues to look like a kernel SHM problem. So far though, > 2.4.0-test8-vm3 is handling the problem Quite well as opposed to test9, > which died in 2 hours upon booting ...and it didn't have the added > stress of compiling X. > It only took me 45 min to have X crash 2.4.0-test8-vm3, It occurred when i opened and closed xawtv a few times while the system was under stress from other apps (~1 load ) ... the shm segments kept increasing and i noticed something strange. -- Semaphore Status used arrays = 1 allocated semaphores = 14 It's always been 0 with the previous tests and with this test9-pre6 kernel. Not sure what the significance of it is. SHM segments are increasing (they only go away when X closes) .. swap seems to be stable for nowhere is the ipcs -u output -- Shared Memory Status segments allocated 1379 pages allocated 8770 pages resident 8329 pages swapped 0 Swap performance: 2956 attempts 0 successes -- Semaphore Status used arrays = 0 allocated semaphores = 0 -- Messages: Status allocated queues = 0 used headers = 0 used space = 0 bytes I'm not sure how that swap performance is supposed to be, i need someone to compare to that has this stuff working and does not have the SHM problem ... i expect to crash within an hour. - 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: Problem with 2.4.0-test9-pre6 seems to be SHM
Ok, compiling using a cvs of X i got a couple hours ago, I'm just wondering what the average segment number is for SHM on an X session that has been up for a while i'll get back with any sort of info on if the SHM problem has been solved with this latest CVS or if it continues to look like a kernel SHM problem. So far though, 2.4.0-test8-vm3 is handling the problem Quite well as opposed to test9, which died in 2 hours upon booting ...and it didn't have the added stress of compiling X. - 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: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > safemode wrote: > > > i'll get back about the latest xfree86 in about 2 hours .. but if anyone has any >other ideas > > or info i can give ...it's not problem. test8 seems stable enough to keep itself >up until > > i'm ready to reboot. > > I should hope, I have a 20 day uptime so far. > > -d > > -- > "There is a natural aristocracy among men. The grounds of this are > virtue and talents", Thomas Jefferson [1742-1826], 3rd US President hrmm.. It seems not even the mighty test8-pre6 can handle the cvs of X.. i'm using 90MB of swap at the moment... and almost 4000 segments in shm.. it's like they never go away unless i kill X ...still trying to find the latest cvs.. it appears the module xc is not the latest .. confusing ..anyways .. soon i will be compiling a new X and we shall see how it works. - 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: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > safemode wrote: > > > One more little complaint.. why doesn't vger replace the FROM to > > [EMAIL PROTECTED] like any other sane mailing list ... i > > keep going to Reply and not sending to the list. At least add a > > reply-to tag like the proftpd mailing list has if you want to keep the > > FROM tag as the original sender. > > reply->all works wonderful. > > It's not proper to replace the header and advised against as a common practice. >Adding a reply-to is also advised against but is somewhat 50/50 in practical use. >Clients are suggested to use their reply-to-all > feature instead. Normally you get both the sender and the list. > > -d > > -- > "There is a natural aristocracy among men. The grounds of this are > virtue and talents", Thomas Jefferson [1742-1826], 3rd US President Reply ALL also results in 2 mails being sent instead of one but of course this is usually not a problem since one is going direct and the other is going through vger, but still... it's kind of wasteful to resources and i dont see any harm in Reply-to being sent in the header. Proftpd's mailing list seems to work fine with it. Is your position against it just due to client incompatibility? - 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: problem with 2.4.0-test9-pre6 seems to be SHM
2.4.0-test8-vm3 seems quite stable with this CVS of X After running xawtv and gqmpeg ...which would quickly die due to shm being maxed .. it still works and shows ~ 839 segments ..not really moving from it And after 20 min with all the apps i had open before, still not in swap. Which on test9, i would be ~50MB into swap. . and shortly around an hour 90MB Something is wrong with test9 or the interaction with test9 and X - 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: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > safemode wrote: > > > It seems to me that test8-vm3 handles this fine. in test9 upon loading X i was > > already using swap and down to 10MB ... here i have netscape loaded and some other > > stuff along with gaim and i've got 36MB free still. I'm not so sure you can chalk > > this up totally to X test9 is a VERY VERY poor kernel compared to test8-vm3 > > I fully agree. There is much too high of a problem factor with the test9 series for >me > to use them on my workstations and I don't have time to debug them due to priorities. > > I recommend you do a fresh checkout (not update) of X (current version is 4.01d), >and use > test8 and we'll go from that point. Verify that test8 is clean, apply Rik's VM >patch, > test again, then step to test9. > > There are three issues: > > 1) 100% use of SHM segments appears to cause instability > 2) SHM segments count keeps increasing using X 4.01c possibly due to corrupted cvs >tree, > fresh checkout fixed it for one person > 3) test-9...don't even go there ;) > > -d > > -- > "There is a natural aristocracy among men. The grounds of this are > virtue and talents", Thomas Jefferson [1742-1826], 3rd US President Indeed It will take approximately 2 hours for me to have the new X installed and reboot to use it and get any results. However, test8-vm3 would be AWESOME if it didn't have that deadlock that makes it crash after a while. it seems to be devoid of any of the annoying problems test9 has. One thing that seems to be overlooked too and i'm not sure if it's related or not is my DMA's timeout on test9 this does not occur on test8-vm3. Well, i'll get back about the latest xfree86 in about 2 hours .. but if anyone has any other ideas or info i can give ...it's not problem. test8 seems stable enough to keep itself up until i'm ready to reboot. - 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: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > XFree86 Version 4.0.1b / X Window System > (protocol Version 11, revision 0, vendor release 6400) > Release Date: 11 August 2000 > > =) > > Are you by chance using cvs X from after september 10th? If so, hop on the > [EMAIL PROTECTED] mailing list and post your comments there. There is another > gentlemen with a similar problem. I'm changing pace here, I believe the kernel is > fine and it is an X issue as it occurs on 2.2 as well. Visit the tail of: > http://www.xfree86.org/pipermail/xpert/2000-September/thread.html. > > -d > > safemode wrote: > > > When in doubt. . Blame it on the biggest piece of crap around .. X.One can > > say using a cvs of X is the cause of this by somehow i doubt it would matter. X > > needs a sane make system and i'll bet 10:1 that it's the root of this shm usage. > > But it should not be crashing the OS ...which does occur since i just went down a > > couple minutes ago. Right now it's increasing 1 segment a second it seems. it's > > at 1200 now and i give it about 30 more minutes before i crash again. I'm gonna > > run this on the test8-vm3 patched kernel i had before that was VERY good except > > for that deadlock problem that caused me to crash after 7 days. If the shm usage > > is insane on that then i'll believe it is X's fault. be back with the results > > in a few minutes. > > -- > "There is a natural aristocracy among men. The grounds of this are > virtue and talents", Thomas Jefferson [1742-1826], 3rd US President XFree86 Version 4.0.1c / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 28 August 2000 i cvs'd and compiled this last night Sept 22 ipcs -u -- Shared Memory Status segments allocated 439 pages allocated 2990 pages resident 2645 pages swapped 0 Swap performance: 0 attempts 0 successes -- Semaphore Status used arrays = 0 allocated semaphores = 0 -- Messages: Status allocated queues = 0 used headers = 0 used space = 0 bytes cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 130011136 93089792 369213440 1347584 39284736 Swap: 2052710400 205271040 MemTotal: 126964 kB MemFree: 36056 kB MemShared: 0 kB Buffers: 1316 kB Cached: 38364 kB Active: 18760 kB Inact_dirty: 20920 kB Inact_clean: 0 kB Inact_target: 260 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 126964 kB LowFree: 36056 kB SwapTotal: 200460 kB SwapFree: 200460 kB df shm8388608 11996 8376612 1% /var/shm It seems to me that test8-vm3 handles this fine. in test9 upon loading X i was already using swap and down to 10MB ... here i have netscape loaded and some other stuff along with gaim and i've got 36MB free still. I'm not so sure you can chalk this up totally to X test9 is a VERY VERY poor kernel compared to test8-vm3 - 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: problem with 2.4.0-test9-pre6 seems to be SHM
One more little complaint.. why doesn't vger replace the FROM to [EMAIL PROTECTED] like any other sane mailing list ... i keep going to Reply and not sending to the list. At least add a reply-to tag like the proftpd mailing list has if you want to keep the FROM tag as the original sender. David Ford wrote: > I think it's time to get Christoph on the line and see what he has to say. The > 4096 number is a limit to the system, you can have a max of 4096 shared memory > segments systemwide. Do you know offhand which programs are using(abusing) > shm? > > -d > > safemode wrote: > > > David Ford wrote: > > > > > No, those two are often empty. Does the total of the first group's bytes > > > column match the used column of df? > > > > > > -d > > > > The sum of the Bytes used in the 4096 entries ipcs shows is WAY off from the > > bytes used in df if that's what you wanted to know.df shows 109K in > > use... and that's easily beaten by the first entry in ipcs > > > > -- Shared Memory Segments > > key shmid owner perms bytes nattchstatus > > 0x 32769 root 600 5038082 dest > > 0x0002 131074root 600 1966082 > > 0x0003 163843root 600 6553602 > > 0x 3997700 root 777 5240 1 dest > > 0x 4030469 root 777 5060 1 dest > > 0x 4063238 root 777 4700 1 dest > > > > this is the first 6 entries ... i'm not sure what you're getting at with > > this though.. > > -- > "There is a natural aristocracy among men. The grounds of this are > virtue and talents", Thomas Jefferson [1742-1826], 3rd US President When in doubt. . Blame it on the biggest piece of crap around .. X.One can say using a cvs of X is the cause of this by somehow i doubt it would matter. X needs a sane make system and i'll bet 10:1 that it's the root of this shm usage. But it should not be crashing the OS ...which does occur since i just went down a couple minutes ago. Right now it's increasing 1 segment a second it seems. it's at 1200 now and i give it about 30 more minutes before i crash again. I'm gonna run this on the test8-vm3 patched kernel i had before that was VERY good except for that deadlock problem that caused me to crash after 7 days. If the shm usage is insane on that then i'll believe it is X's fault. be back with the results in a few minutes.
Re: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > No, those two are often empty. Does the total of the first group's bytes > column match the used column of df? > > -d The sum of the Bytes used in the 4096 entries ipcs shows is WAY off from the bytes used in df if that's what you wanted to know.df shows 109K in use... and that's easily beaten by the first entry in ipcs -- Shared Memory Segments key shmid owner perms bytes nattchstatus 0x 32769 root 600 5038082 dest 0x0002 131074root 600 1966082 0x0003 163843root 600 6553602 0x 3997700 root 777 5240 1 dest 0x 4030469 root 777 5060 1 dest 0x 4063238 root 777 4700 1 dest this is the first 6 entries ... i'm not sure what you're getting at with this though.. - 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: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > safemode wrote: > > > xawtv will still work but gqmpeg cannot run. shget returns no memory > > available on any app trying to access it. Well, hope that tells > > someone something because i'm stumped .. something in shm seems > > broken.. or the vm is. > > what does 'ipcs' show? a huge list or a lot of large segments? how about > 'df' if you have shmfs mounted. the 'used' part should match the tally of > ipcs. > > -d > Oops, forgot to read the -h on ipcs .. . here is a better idea of what is goin on -- Shared Memory Status segments allocated 4097 pages allocated 27362 pages resident 8744 pages swapped 18179 Swap performance: 25422 attempts 18180 successes -- Semaphore Status used arrays = 0 allocated semaphores = 0 -- Messages: Status allocated queues = 0 used headers = 0 used space = 0 bytes hope that says something
Re: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: > safemode wrote: > > > xawtv will still work but gqmpeg cannot run. shget returns no memory > > available on any app trying to access it. Well, hope that tells > > someone something because i'm stumped .. something in shm seems > > broken.. or the vm is. > > what does 'ipcs' show? a huge list or a lot of large segments? how about > 'df' if you have shmfs mounted. the 'used' part should match the tally of > ipcs. > > -d my first post shows what df says ..but here it is again ipcs shows A VERY HUGE LIST... ending with this -- Semaphore Arrays key semid owner perms nsems status -- Message Queues key msqid owner perms used-bytes messages yes, they are empty... is this a problem too? df shows Filesystem 1k-blocks Used Available Use% Mounted on shm8388608109448 8279160 2% /var/shm
Problem with 2.4.0-test9-pre6 seems to be SHM
In running xawtv i stumbled upon a very interesting message shmget: No space left on device yet df -m shows shm 8192 108 8084 2% /var/shm I'm not sure what's going on here, /var/shm shows a BUNCH of files in it.. and none of my partitions are even close to being full according to df -m also. any hints would be helpful - 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/
weird mem crap in test9-pre6
I'd like to start out by saying Rik's latest patch to test8 was working GREAT except that deadlock problem which after 7 days of uptime in X finally occurred. So, I thought, updating to the latest normal kernel should have that and it fixed. Obviously I was wrong. The kernel is displaying either A. the wrong mem usage in ps and /proc/meminfo or B. is totally fucked up in the VM or C. someone decided FULL utilization of all available memory was necessary in linux. Like the pre-rik vm fixes, my kernel is now obviously using a whole lot of swap for no apparant reason except the kernel likes to hurt the hdd. Also i'm getting DMA timeouts again causing infinite ide reset loops (which btw are very cool.. you should try it sometimes *hint* someone make a limit where the system just reboots after so many of these damn things ...i see no reason why it should loop to infinite), anyways, if anyone wants some mem info about this tell me ..i'll paste the contents of /proc/meminfo here ..but i'm not sure what else you'll need to figure out why it's being weird. I'm using linux-2.4.0-test9-pre6 on a pii 300 440lx without DRI and framebuffer but with scsi emu cdrom support. i'm using DMA on one hdd at the moment in hopes it wont timeout ..but i used to be able to use it on both hdd's. This was compiled by gcc-2.95.2 /proc/mtrr: reg00: base=0x ( 0MB), size= 128MB: write-back, count=1 reg01: base=0xec00 (3776MB), size= 32MB: write-combining, count=1 /proc/meminfo: total:used:free: shared: buffers: cached: Mem: 130060288 127926272 21340160 749568 33042432 Swap: 205271040 80523264 124747776 MemTotal: 127012 kB MemFree: 2084 kB MemShared: 0 kB Buffers: 732 kB Cached: 32268 kB Active: 15520 kB Inact_dirty: 7912 kB Inact_clean: 9568 kB Inact_target: 300 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 127012 kB LowFree: 2084 kB SwapTotal: 200460 kB SwapFree: 121824 kB - 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/
weird mem crap in test9-pre6
I'd like to start out by saying Rik's latest patch to test8 was working GREAT except that deadlock problem which after 7 days of uptime in X finally occurred. So, I thought, updating to the latest normal kernel should have that and it fixed. Obviously I was wrong. The kernel is displaying either A. the wrong mem usage in ps and /proc/meminfo or B. is totally fucked up in the VM or C. someone decided FULL utilization of all available memory was necessary in linux. Like the pre-rik vm fixes, my kernel is now obviously using a whole lot of swap for no apparant reason except the kernel likes to hurt the hdd. Also i'm getting DMA timeouts again causing infinite ide reset loops (which btw are very cool.. you should try it sometimes *hint* someone make a limit where the system just reboots after so many of these damn things ...i see no reason why it should loop to infinite), anyways, if anyone wants some mem info about this tell me ..i'll paste the contents of /proc/meminfo here ..but i'm not sure what else you'll need to figure out why it's being weird. I'm using linux-2.4.0-test9-pre6 on a pii 300 440lx without DRI and framebuffer but with scsi emu cdrom support. i'm using DMA on one hdd at the moment in hopes it wont timeout ..but i used to be able to use it on both hdd's. This was compiled by gcc-2.95.2 /proc/mtrr: reg00: base=0x ( 0MB), size= 128MB: write-back, count=1 reg01: base=0xec00 (3776MB), size= 32MB: write-combining, count=1 /proc/meminfo: total:used:free: shared: buffers: cached: Mem: 130060288 127926272 21340160 749568 33042432 Swap: 205271040 80523264 124747776 MemTotal: 127012 kB MemFree: 2084 kB MemShared: 0 kB Buffers: 732 kB Cached: 32268 kB Active: 15520 kB Inact_dirty: 7912 kB Inact_clean: 9568 kB Inact_target: 300 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 127012 kB LowFree: 2084 kB SwapTotal: 200460 kB SwapFree: 121824 kB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problem with 2.4.0-test9-pre6 seems to be SHM
In running xawtv i stumbled upon a very interesting message shmget: No space left on device yet df -m shows shm 8192 108 8084 2% /var/shm I'm not sure what's going on here, /var/shm shows a BUNCH of files in it.. and none of my partitions are even close to being full according to df -m also. any hints would be helpful - 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: problem with 2.4.0-test9-pre6 seems to be SHM
David Ford wrote: safemode wrote: xawtv will still work but gqmpeg cannot run. shget returns no memory available on any app trying to access it. Well, hope that tells someone something because i'm stumped .. something in shm seems broken.. or the vm is. what does 'ipcs' show? a huge list or a lot of large segments? how about 'df' if you have shmfs mounted. the 'used' part should match the tally of ipcs. -d my first post shows what df says ..but here it is again ipcs shows A VERY HUGE LIST... ending with this -- Semaphore Arrays key semid owner perms nsems status -- Message Queues key msqid owner perms used-bytes messages yes, they are empty... is this a problem too? df shows Filesystem 1k-blocks Used Available Use% Mounted on shm8388608109448 8279160 2% /var/shm
