Re: 2.4.x SMP blamed for Xfree 4.0 crashes
On Feb 13 2001, Alan Cox wrote: > Yeah I've seen this claim repeatedly. XFree 4.0.2 crashes for me in similar > ways on 3dfx and matrox cards and it happens with 2.2 kernels as well. I thought that I was going crazy or that it was just my inability to configure things correctly, but it is kind of comforting to see that I'm not the only one seeing problems with XFree86 4.0.2 + matrox + kernel 2.2.18 (UP system -- an AMD Duron with chipset KT133). When X 4.0.2 entered the Debian testing distribution, I immediately upgraded (I had used X 4.0.1 before with very good results, but that system had an HD crash and I reinstalled Debian potato, that comes with X 3.3.6). I got all these strange Segfaults and crashes with a vanilla 2.2.18 kernel. I went back to X 3.3.6 and everything is running perfectly fine since then, but I'd like to use the new features of X 4. []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - 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: [patch] VIA 4.2x driver for 2.2 kernels
On Feb 21 2001, Vojtech Pavlik wrote: > On Tue, Feb 20, 2001 at 11:15:02PM -0800, Shane Wegner wrote: > > Ok, can I still use -u1 -k1 -c1 on the drives or is it even > > necessary anymore. > > If you enable automatic DMA in the kernel config, it isn't necessary > at all. The VIA driver sets up everything. Ok. Please disregard my last message (this one contains exactly what I was looking for). > 4) But VIA is still set to PIO mode Why does this happen? And what about the other options to hdparm (-u1 -k1 -c1)? Are they potentially dangerous also? []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - 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: [patch] VIA 4.2x driver for 2.2 kernels
On Feb 21 2001, Vojtech Pavlik wrote: > Don't do that. Use the kernel option to enable DMA instead. You mean using hdparm can cause problems? Could you provide more details on the problems that could arise? I'm completely ignorant on the subject... []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - 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: [patch] VIA 4.2x driver for 2.2 kernels (fwd)
This message was apparently intended to be sent to the list. []s, Roger... - Forwarded message from Pozsar Balazs <[EMAIL PROTECTED]> - From: Pozsar Balazs <[EMAIL PROTECTED]> To: Rogerio Brito <[EMAIL PROTECTED]> Subject: Re: [patch] VIA 4.2x driver for 2.2 kernels Date: Thu, 22 Feb 2001 01:04:27 +0100 (MET) Message-ID: The kernel doesn't seem to set 32bit io transfers by default. Is it dangerous or unrecommended to set it with hdparm? On Wed, 21 Feb 2001, Rogerio Brito wrote: > On Feb 21 2001, Vojtech Pavlik wrote: > > On Tue, Feb 20, 2001 at 11:15:02PM -0800, Shane Wegner wrote: > > > Ok, can I still use -u1 -k1 -c1 on the drives or is it even > > > necessary anymore. > > > > If you enable automatic DMA in the kernel config, it isn't necessary > > at all. The VIA driver sets up everything. > > Ok. Please disregard my last message (this one contains > exactly what I was looking for). > > > 4) But VIA is still set to PIO mode > > Why does this happen? > > And what about the other options to hdparm (-u1 -k1 -c1)? Are > they potentially dangerous also? > > > []s, Roger... > > ----- End forwarded message - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - 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/
[Newbie] Re: Problem creating filesystem
On Feb 26 2001, Jeremy Jackson wrote: > Carlos Fernandez Sanz wrote: > > The IDE controller is > > Bus 0, device 17, function 0: > > Unknown mass storage controller: Promise Technology Unknown device (rev > > 2). > > Vendor id=105a. Device id=d30. > > Medium devsel. IRQ 10. Master Capable. Latency=32. > > Unrelated to disk "problem", you might want to set your PCI latency timer in > BIOS to 64 or more. Ok, I understand that this is probably off-topic and way too basic, but what exactly would this do, in layman terms? Would the latency being set to 32 result in any potential data corruption? BTW, to set this quantity, one should use setpci, right? Thanks for any help, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac11
On Mar 03 2001, Alan Cox wrote: > 2.4.2-ac11 > o Resync with Linux 2.4.3pre1 What exactly does these resyncs mean? Do they mean that the entire Linus's tree is merged in the -ac patches (unless explicitly noted)? And when things eventually get accepted by Linus, do they disappear from the -ac changelogs? []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - 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 discussion
On Jan 17 2001, David D.W. Downey wrote: > > Could those that were involved in the VIA chipset discussion email me > privately at [EMAIL PROTECTED]? Just to add a datapoint to the discussion, I'm using a VIA chipset here (in fact, it's an Asus A7V board with a Duron), a 2.2.18 kernel with André's patches and I'm only using IDE (UDMA/66 and UDMA/33 here) and I'm *not* seeing any problems. Perhaps this may be a problem with some revisions of the chipset (or, perhaps, I'm not stressing my system enough for the bugs to show their heads). I'm attaching the output of lspci of my machine to this message. I also used a 2.4.0 kernel with all support for everything here enabled, but the HD where I had that kernel died. :-( So, I'm back using a 2.2.0 kernel. > I'm truly interested in solving this issue. I personally think it's > more than just the chipset causing the problems. This may be a possibility, since I'm using this very same chipset and I'm not seeing any problems... > VIA chipset > Promise controller (PDC2026# with specifics on the PDC20265 (ATA100)) I'm using these (but I don't have anything in my Promise controller yet, since I couldn't find UDMA/100 drives when I bought my machine). > SMP support > IDE + SCSI mix in the system. But I'm not using SMP nor SCSI here. Hope this helps, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) 00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev 10) 00:0a.0 Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 01) 00:0d.0 Multimedia audio controller: Ensoniq: Unknown device 5880 (rev 02) 00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04)
Re: VIA chipset discussion
On Jan 18 2001, Matthew Fredrickson wrote: > BTW, are you having any trouble with your ps/2 mouse port in X? Like I said in the previous e-mail, I'm using right now an Asus A7V mobo with Linus' stock kernel 2.2.18 with André's patches. I'm using basically a Debian potato here with XFree86 3.3.6 and a Microsoft Intellimouse (with IMPS/2 protocol) and everything seems to be working fine. Before my brand new 40GB Samsung HD died, I was using a more modified potato, including XFree86 4.0.1e (or 4.0.1f, I don't remember). Everything was also working fine with this older setup. > On my new ASUS board, ps/2 mouse devices (just in X, gpm works fine) > act a little crazy (random mouse movement, random clicking, etc., > except I'm not the one doing all the random movement). I'm not sure > what it is, though I do know it's not as bad once I upgraded from > 2.2.18pre21 to 2.4.0. I usually only follow Alan's pre series when things are broken with the final releases, so I don't know about 2.2.18preX. I'm sorry that I can't help. > I think I'm going to try using the mouse as a usb device and see if > I still have trouble. Unfortunately, I have never ever seen a USB device, so I have no experience here to help you. > Anyway, just wondering if you're seeing the same problem. No, but have you tried changing the mouse? I've had problems with a Matrox G400 AGP 16MB monohead that I purchased when I got my system. It did crash when X was running in Linux and FreeBSD (and many versions of X, for that matter), but under Windows it worked flawlessly. When I used Matrox's drivers with XFree86 4.x, it worked perfectly. I changed my Matrox and now I'm using a new one under X 3.3.6 under potato (a stable platform that I use) and everything is fine). So, perhaps you could try changing your mouse? []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac12 (vt82c686 info)
On Mar 07 2001, Vojtech Pavlik wrote: > Also, the vt82c686 will work just fine with Linux, but will be limited > to UDMA33, because UDMA66 on this chip does reliably fail. How do I know which one I have? Using the revision of the chip? lspci only shows that I have a vt82c686 (revision 22 -- perhaps this is the clue), but I have been using UDMA66 drives here with *no* corruption so far (or I haven't stressed my system enough to notice it). Here are the lines from my lspci which I think are relevant here: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Any hints are more than welcome. []s, Roger... P.S.: This is an ASUS A7V mobo. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - 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: [UPDATE] Zerocopy patches, against 2.4.1-pre10
On Jan 24 2001, Mathieu Chouquet-Stringer wrote: > Moreover, few ethernet cards are able to compute the ip checksum so > linux doesn't need anymore to do that. I'm very ignorant when it comes to Ethernet, but I'd like to know which cards have this feature, as I'm planning on buying a new one for my small home LAN (if they aren't expensive enough). And, of course, cards whose Linux drivers are able to use this feature... Any comments are more than welcome. Thanks in advance, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send 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
On Jan 29 2001, 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 > 2) Detects a maximum of 64mb of ram, unless worked around by the "mem=" > switch > 3) The clock drifts slowly (more so under heavy load than light load), > leaking time. I know that I am late here, but I'm also using a via KT133 chipset with a Duron 600MHz and I'm using a kernel 2.2.18 here with the IDE patches and I'm not seeing anything of the above problems. Everything just works fine. What are you using? I'm using an Asus A7V, with BIOS 1003 (I didn't upgrade it, since I'm terribly scarred of it going wrong and not being to boot again). This is with kernel 2.2.18 (no signs of filesystem corruption also, and I have UDMA/66 enabled, but my system is not exactly stressed). > I think #2 is because e820h memory detection While I don't have problems with the Duron above, I do have a 486 here with 8MB of memory that I intend to use as a router for my local LAN, but 2.4.0 only recognizes 7MB, while 2.2.18 recognizes all 8MB. Under 2.4.0 (I haven't tried 2.4.1 yet), I used a mem=8M option and it worked fine, but I don't know if this is indeed safe or not (I'd guess that it would be, since the 2.2 kernels use all memory, but you never know). []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send 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
On Feb 02 2001, Dunlap, Randy wrote: > > From: Rogerio Brito [mailto:[EMAIL PROTECTED]] > > > > While I don't have problems with the Duron above, I do have a > > 486 here with 8MB of memory that I intend to use as a router > > for my local LAN, but 2.4.0 only recognizes 7MB, while 2.2.18 > > recognizes all 8MB. > > Fixed in 2.4.1 and its pre-patches. Thank you very much, Randy. I'll compile 2.4.1 or anything newer than this and I'll report back my results. Thank you very much again, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Slowing down CDROM drives (was: Re: ATAPI CDRW which doesn't work)
On Feb 05 2001, Jens Axboe wrote:
> On Sat, Feb 03 2001, [EMAIL PROTECTED] wrote:
> > Feb 3 22:08:25 Line kernel: hdb: irq timeout: status=0xd0 { Busy }
> > Feb 3 22:08:25 Line kernel: hdb: DMA disabled
> > Feb 3 22:08:55 Line kernel: hdb: ATAPI reset timed-out, status=0x90
> > Feb 3 22:08:55 Line kernel: hda: DMA disabled
>
> Try disabling DMA on the drive before accessing it.
Well, this has nothing to do with the above, but is there any
utility or /proc entry that lets me say to my CD drive that it
should not work at full speed?
Basically, some drives make way too much noise when they're
operating at full speed. When I'd like to listen to some MP3s
from a burned CD-R, what I'm currently doing is copying the
files that I want to /tmp and listening from there, but this
is obviously a dirty solution. :-(
Thanks in advance for any hints, Roger...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To unsubscribe from this list: send 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: Slowing down CDROM drives (was: Re: ATAPI CDRW which doesn't work)
On Feb 05 2001, Jens Axboe wrote: > ioctl(cd_fd, CDROM_SELECT_SPEED, speed); I'd like to thank everybody that replied either on the list and privately. I didn't know that I could just use the /proc entries to change the IDE driver speed with a simple: echo current_speed:4 > /proc/ide/hdc/settings (Thanks Mark for this). I'd also like to thank Andries about the tip on the mount option. I didn't find anything in the util-linux (mount) manpage before I asked (I'm using Debian potato's util-linux 2.10q-1). The option that I chose was to cook a little proggie to call the ioctl to set the speed. This is the most flexible solution (as it doesn't involve messing with fstab or being root to pass the mount option to mount). Thanks, Jens! Thank you all very, very much for the amazing (and fast) help! []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
What is the difference between buffers and cached? (was: Re: 2.4.x Shared memory question)
On Feb 04 2001, LA Walsh wrote: > Another oddity -- I notice things taking alot more memory > in 2.4. This coincides with 'top' consistently showing I have 0 shared > memory. AFAIK, the 2.4.0 series does share memory, but it's just the counters that are not updated, for they are costly. > total:used:free: shared: buffers: cached: > Mem: 525897728 465264640 606330880 82145280 287862784 > Swap: 2709094400 270909440 This is the perfect time to ask one thing that I don't know, but that I've tried to find without success: what is the difference between "buffers" and "cached"? I'd make the wild guess that "buffers" would mean any types of buffers that the kernel maintains, while "cached" would have something to do with cached disk blocks... Are these guesses correct or completely, way off? Thanks for any hints, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA silent disk corruption - likely fix
On Feb 05 2001, Udo A. Steinberg wrote:
> Peter Horton wrote:
> > I've found the cause of silent disk corruption on my A7V motherboard,
> > and it might affect all boards with the same North bridge (KT133 etc).
>
> Do you have a small test program to illustrate that bug? I have an A7V
> with PCI Master Read Caching enabled and haven't seen any corruption so
> far (which doesn't necessarily mean much). Or if you don't have a test
> program, how did you identify it's caching too much?
> Also, are you using a Thunderbird or a Duron?
Just an extra data point here.
I have an A7V here also and I haven't seen anything wrong with
my setup (but I'm using 2.2.18 + the IDE patches). Perhaps,
I'm not hitting the bad cases or I'm not stressing the system
enough. I'm using a Quantum lct15 drive here with UDMA/66
here. I have a Duron 600MHz and I remember that when I was
setting the machine (after I bought it), I left everything in
the default settings (so, the PCI Master Read Caching is
disabled).
> I'm using the 1003 Bios, which has proven to be the most stable so far.
> Which one do you use?
I also use 1003, but I have not tried anything else (for fear
of something going wrong when I'm upgrading -- like a power
outage). :-)
[]s, Roger...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To unsubscribe from this list: send 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: Slowing down CDROM drives (was: Re: ATAPI CDRW which doesn't work)
On Feb 10 2001, Pavel Machek wrote: > Hi! > > > ioctl(cd_fd, CDROM_SELECT_SPEED, speed); > > Does this actually work? I helped my friend with partly broken cdrom > (worked only at low speeds) and it did not have much effect. It did > not make my cdrom quiet, either, AFAI can remember. Well, I wrote a little program that just makes this call that Jens told me about and it worked perfectly with my hardware -- using my CD-ROM drive at speed 1, 2 or 4, it works quietly and I can listen to MP3s at volumes that I couldn't earlier. OTOH, it seems that a paradox is happening: this very same drive has some problems (not always reproducible) reading some CD-RW discs when it operates at very slow speeds. In this case, the best that I can do is to let the drive accelerate as much as it wants and then it works ok. BTW, Jens, what is the way to set the drive back to its maximum speed, without limits? Where could I read more about the subject (that is, this and other ioctl's) without annoying you? I'm a moderately competent C programmer (only moderately), but I know *nothing* about the kernel. []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send 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: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Feb 11 2001, Andi Kleen wrote: > The reiserfs nfs problem in standard 2.4 is very simple -- it'll > barf as soon as you run out of file handle/inode cache. Any workload > that accesses enough files in parallel can trigger it. I'm just trying to evaluate if I should use reiserfs here or not: is this phenomenon that you describe above happening independently of whether I choose the knfsd or userspace nfsd? From your message, I got the impression that it would happen with knfsd only, but I'm just checking before I make a wrong decision. Thanks from a humble (and ignorant) network admin, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
