Re: Ext2 & Performances
Aaron Sethman <[EMAIL PROTECTED]> writes: > You might want to take a look at using reiserfs on the 130GB partition, as > its is journalled and doesn't need to be fsck'ed. No. All journaling filesystems need to be fsck'ed. A correctly operating one simply doesn't need to be fsck'ed because of unexpected loss of operating system.Which brings greatly reduce the probability. If an error is detected in the filesystem fsck is still what you have to do to correct it. Eric - 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: Better testing of hardware (was: Defective Read Hat)
"Stephen Gutknecht (linux-kernel)" <[EMAIL PROTECTED]> writes: > A Linux Kernel compile test does a really good job of testing the hard disk, > RAM, and CPU... as it executes all types of instructions and the final > output depends on all prior steps completing correctly. On a really fast > system (> 900Mhz) might make sense to run it twice, once to "warm up" the > CPU and other components. Most "benchmarks" just test speed, not the actual > stability or data integrity (they write results to a device but don't check > for data corruption, or they test only one device at a time, not all at > once). Also note that a Linux Kernel compile stresses memory because of the very pointer loaded data structures of gcc. This means that memory corruption is most likely to flip a bit in a pointer, and cause a bad pointer. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
[first off, thanks for kicking this stuff into gear Adam. I'm way too lazy to do this stuff of my own volition :)] > >was to serialize access to the mixer, there are surely better ways to do > >it. Why are interrupts disabled? the maestro has crappy register indirection that you must use to do nearly anything. when the locking was added we just went nutty with one big lock :) yes, this could be cleaned up with a mixer specific lock as the mixer regs aren't atomic, but don't require the same indirection as the rest of the maestro stuff. the locking fix is still valid if they're all under one big lock. > As far as I can tell, I agree with you, but I do not think > that is related to the move to the new PCI interface. *nod* > I also agree that the ioctl patch is kind of a bandaid over > the problems that you described, and, while Zach Brown can speak The biggest problem is that the current code is gross gross gross. I've been avoiding dealing with it too much in the hopes that moving to oss_audio will make things much more friendly across the board. > problem permanent, and (2) it is an incremental improvement over > the status quo. *nod* I'd like 2.2/2.4 to at least be solid for people so I can disappear (again) to do the oss_audio work. Really, I'd hope it wouldn't take all that long. > That said, I am willing to help try to clean up the > locking code in maestro if Zach thinks it is worth doing right > now, since I have a notebook computer with a maestro chip in If you get me a patch thats obviously correct, I'd happily agree to it going in. I'm not sure its immeditately needed, but won't stop you from playing with things :). Jeff has the start of a patch that moves maestro.c to be a consumer of ac97_codec. It was really close, except for some locking oopsies. If you're dorking around with the locking, you might be able to fix that up at the same time. The new ac97 interface cleans up the code a lot. you can look at how the maestro3 does it, its almost identical to how maestro.c + ac97 would look. [hah, except that maestro3 hasn't had any locking applied to it at all.] > >This driver needs __devxxx, I've heard mention of some hotpluggable > >audio that is based on the maestro chipset (which chip I don't remember) scary. :) this all reminds me, the maestro3 driver is working well enough for most people that I should get it going on 2.4 and submit it.. -- zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
> Unrelated to your change: the maestro reboot notifier shouldn't need to > unregister all that stuff. Who cares if the sound devices are freed, > since we are rebooting. free_irq+maestro_power seems sufficient. or > maybe stop_dma+free_irq+poweroff. its only the power stuff that matters. some biosen don't power down properly if the chip isn't powered down. That could actually be because of weird changes we make to the chip and then mask by powering it down, but shutting it down made the machines halt again :) -- zach - 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: modutils 2.3.20 not backward compatible
Keith Owens wrote: > > On Tue, 21 Nov 2000 20:17:47 -0700, > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: > >Was there a reason we removed the -i and -m options from newer modutils > >and broke backwards caompatibility? I'm re-writing our module build > >scripts for the installer, and I discovered after upgrading to 2.3.20, > >that all the build scripts (about 10MB worth) are now busted and I have > >been spending most of this evening rewriting them so they work again. > > -i and -m have never been in the base code. -i in depmod is a Redhat > add on, only in their distribution. I have no idea what -m does, apart > from -m in insmod which is supported. Blame the distributors. Thanks for clarifying. -i ignores certain dependency failures, and is very dangerous. -m lets you use a map file. If what you say is correct, then it was an erstwhile exercise rewriting these scripts, since they will now take generic parameters. Jeff > > - > 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/
Locking User memory pages from a driver....
Hi all, How do i lock user mode memmory pages from kernel mode driver.. so that i can access it whenever i need to from the driver I am using linux kernel 2.2.14.. can this be done in this kernel version... or is it supported in some other newer versions.. like 2.4.. TIA azad - 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/
Thanks for letting know the list is okay. My ISP quota looks okay, so I am trying resubscribing. Sorry for the noise.
- 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/
Uh, is kernel.org sending out e-mail to the mailing lists? I am not getting linux-kernel messages for two days.
Please reply to me directly, since I am not getting messages from the list. Perhaps something is wedged with my ISP. Miles - 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: ECN causing problems
On Tue, Nov 21, 2000 at 10:26:24PM -0500, Joseph Gooch wrote: > My RaptorNT 6.5 firewall rejects all connections from my linux box when ECN > is enabled. The error is attached. Perhaps this feature should be disabled > by default? Or is there already an option of the sort that i'm missing? I > only got the idea to disable it after a search of linux-kernel. I suggest you file a bugreport against RaptorNT, which evidently is malfunctioning by detecting legit TCP-flags as something illegal. > Plz cc me, I"m not on the list. > > Later! > Joe Gooch > > TCP packet dropped (10.204.186.7->x.x.x.x: Protocol=TCP[SYN 0xc0] Port > 1255->2401): Bad TCP flags combination (received on interface 192.168.1.1) > (probable QueSO probe as flags=0xc2) /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: modutils 2.3.20 not backward compatible
On Tue, 21 Nov 2000 20:17:47 -0700, "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: >Was there a reason we removed the -i and -m options from newer modutils >and broke backwards caompatibility? I'm re-writing our module build >scripts for the installer, and I discovered after upgrading to 2.3.20, >that all the build scripts (about 10MB worth) are now busted and I have >been spending most of this evening rewriting them so they work again. -i and -m have never been in the base code. -i in depmod is a Redhat add on, only in their distribution. I have no idea what -m does, apart from -m in insmod which is supported. Blame the distributors. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
On Tue, Nov 21, 2000 at 06:17:48PM -0500, David Riley wrote: > Richard Torkar wrote: > > > > Well David, there is such a "manual". > > > > http://ftp.sunet.se/LDP/FAQ/faqs/GCC-SIG11-FAQ > > Yes. And if you ask the average new Linux user if they've read it, I > doubt you'll get a "yes". My question boils down to this, and this I > suppose is a personal/informational request for comments, so don't > clutter the list with responses directed at me: What (in your opinion) > is the most commonly read Linux user-land document? Well, a copy of that document *is* the first hit for a google search on 'linux signal 11 faq' http://www.google.com/search?q=linux+signal+11+faq In other words, someone who does the slightest bit of research will find the answer. Jeff - 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/
ECN causing problems
My RaptorNT 6.5 firewall rejects all connections from my linux box when ECN is enabled. The error is attached. Perhaps this feature should be disabled by default? Or is there already an option of the sort that i'm missing? I only got the idea to disable it after a search of linux-kernel. Plz cc me, I"m not on the list. Later! Joe Gooch TCP packet dropped (10.204.186.7->x.x.x.x: Protocol=TCP[SYN 0xc0] Port 1255->2401): Bad TCP flags combination (received on interface 192.168.1.1) (probable QueSO probe as flags=0xc2) - 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/
modutils 2.3.20 not backward compatible
Keith, Was there a reason we removed the -i and -m options from newer modutils and broke backwards caompatibility? I'm re-writing our module build scripts for the installer, and I discovered after upgrading to 2.3.20, that all the build scripts (about 10MB worth) are now busted and I have been spending most of this evening rewriting them so they work again. Thanks Jeff - 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: 53c400 driver
JE's UHCI driver (drivers/usb/uhci.[hc]) uses nested_lock() and nested_unlock() for this. Maybe it could help. ~Randy ___ |randy.dunlap_at_intel.com503-677-5408| |NOTE: Any views presented here are mine alone| |& may not represent the views of my employer.| --- > -Original Message- > From: Alan Cox [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 21, 2000 3:48 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: 53c400 driver > > > > 53c400a non-PNP still lock this system hard. It starts > barking about a > > busy SCSI bus, and then I can fsck again. > > > > To Alan : How hard is it to get thing beast (53c400 and > family) to be SMP > > safe ?? Or is it better to start over again ? > > The problem is that the code takes spinlocks recursively. The original > code (see 2.0's 5380 generic C code) uses cli/sti. It was converted to > use spin_lock() but not allowing for the recursive locking > cases. I tried > to untangle the code paths but they are so ugly and some of > the code is > sufficiently messy and unmaintained (for about 6 years) that I gave up > trying to decode it. > > Alan > > - > 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: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
I forgot to mention that I have tested the updated maestro.c patch that I just submitted by loading the module on a notebook computer, playing some sound, and unloading it. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
Jeff Garzik critiqued my patch for linux-2.4.0-test11/drivers/sound/maestro.c:
>[...] if the intention
>was to serialize access to the mixer, there are surely better ways to do
>it. Why are interrupts disabled?
As far as I can tell, I agree with you, but I do not think
that is related to the move to the new PCI interface.
I also agree that the ioctl patch is kind of a bandaid over
the problems that you described, and, while Zach Brown can speak
for himself, let me take a bit of responsibility for nagging Zach
to make a release anyhow, on the grounds that (1) Zach is already
planning a rewrite to a new interface that I understand that you
and a number of other kernel people are working on, so we are
reasonably assured that this bandaid will not make the underlying
problem permanent, and (2) it is an incremental improvement over
the status quo.
That said, I am willing to help try to clean up the
locking code in maestro if Zach thinks it is worth doing right
now, since I have a notebook computer with a maestro chip in
it, and I normally run an SMP-capable kernel on it (so as run
the same kernel everywhere).
>In any case it will probably change
>when maestro goes ac97_codec (tested patches in gkernel CVS)... which it
>needs to do ;-)
Yes, that is why I think a bandaid in this case will not
become a crutch (if you'll pardon the mixed metaphor).
>This driver needs __devxxx, I've heard mention of some hotpluggable
>audio that is based on the maestro chipset (which chip I don't remember)
I thought I had fixed that, but, upon closer inspection I
see a routine that needed __dev, and found a couple others that
could have it too. I have attached an updated patch below.
>The formatting of pci_device_id data is awful. Named initializers
>-reduce- the readability of the code here, are highly redundant, and its
>usage is totally inconsistent with -all- other PCI drivers in the
>kernel.
We have been discussing this in direct email. Perhaps we
need to bring it to this wider forum.
I agree that named initializers can be redundant when
all of the matches have the same format, which is usually the
case for PCI drivers. However, I think the following advantages
of named initializers outweigh that disadvantage:
1. Most importantly, named initializers make it much easier
to extend the pci_device_id structure, such as adding
a "priority" field to prefer some matches (say, a vendor
specific match for a USB controller) over others, or to
add a "match" field to control ID matching when a value
was 0x, so that we could shrink {,sub}{vendor,device}
from longs to shorts if the number of PCI ID's that
we need to care about grows enormously. I am not advocating
these specific changes, but just using these examples to
show that there is enough of a probability that we may
want to make such a change in the future that we should
not adopt a convention that will require changing the
127 files in linux-2.4.0-test11/drivers/ that use
pci_find* and do not yet have a MODULE_DEVICE_TABLE.
2. I subjectively find named initializers in this case
more readable and less error prone. Without them, I almost
always have to bring up a copy of include/linux/pci.h to
see which fields exactly are being matched and which are being
wildcarded.
3. The seventeen net drivers and four sound drivers that I have
generated MODULE_DEVICE_TABLE's for use named initializers.
The way that my maestro.c patch's use of named initializers
is "totally inconsistent with -all- other PCI drivers" is
that, per your previous email, you are converting my changes
to the less maintainable form.
4. The use of named initializers in other driver structures,
where essentially the same arguments apply, seems to be
the trend in Linus's kernels. So, in the larger picture,
you are the one advocating inconsistency.
I am still open to being rationally convinced that not using
named initializers is better.
I am also willing to produce what I regard as the less maintainable
version if I believe that that will really make the difference as to
whether MODULE_DEVICE_TABLE support (and, in some cases, new style PCI
support) for these drivers gets into the stock kernels or not. I
recognize that people are better off with pci_device_id's done your
way than with no pci_device_id's. If Linus Torvalds or Alan Cox would
tell me that that is how they want it, then that would convince me
that that is the political situation. I am also guaging this from
whether whether the drivers/net changes that I sent to you for
shepherding into Linus's kernel actually get incorporated
Re: linux-2.2.18-pre19 asm/delay.h problem?
[Alan Cox] > You got it. The module is doing an overlarge delay Perhaps people would stop asking this question if the symbol were renamed from __bad_udelay() to, say, __use_mdelay_instead_please(). Sort of like the DNS zone (somewhere at UCLA was it?) where they had something like 'quit 86400 IN CNAME use.exit.to.get.out.of.nslookup.' Peter - 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: Why not PCMCIA built-in and yenta/i82365 as modules
On Tue, Nov 21, 2000 at 10:44:30PM -0300, Horst von Brand wrote: > > If you have a laptop with an assortment of cards, you might want to have > the generic builtin and the cards themselves as modules. No, that's ok, and that's supported with the current config scripts. The original question was about having the generic code built in, but the socket driver (yenta) as a module. The socket driver needs to be loaded regardless of what cards you're using. So I think having one in the kernel and the other as a module is of limited utility. -- Dave - 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: Why not PCMCIA built-in and yenta/i82365 as modules
David Hinds <[EMAIL PROTECTED]> said: [...] > Is there a technical reason for this? Not that I know of; but then I > also cannot think of a good reason for wanting, say, the generic code > built in but the controller support as modules. I do see reasonable > arguments for all-builtin or all-modules. If you have a laptop with an assortment of cards, you might want to have the generic builtin and the cards themselves as modules. Pretty weak, I know. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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/
reiserfs lockup 2.4.0-t11 SMP.
SMP Dual celeron, 128MB ram, 3.6GB part newly created, untar'ing 1GB newsspool, gave kreiserfsd priority -19, got not very easily reproducible lockup. Sysreq showd kreiserfsd running in state L-TLB or something. elmer. - 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.0test8 and 2.4.0test11
A few days ago, and again half an hour ago, X stopped working. Both times this happened in a period of heavy and continuous IDE disk access (copying a 12 GB tree from one disk to another, and doing a diff between two 5 GB trees on different disks). No mouse movement, no reaction to Ctrl-Alt-Backspace. After killing the cp/diff process, X used 100% CPU, and chvt would hang. After killing X and starting a new one all was well. (Of course the vt will be garbled again when I leave X.) The kernels involved were 2.4.0test11preX and 2.4.0test8. (2.4.0test11 dies here when masquerading, but 2.4.0test10 and earlier are OK.) Andries - 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: Why not PCMCIA built-in and yenta/i82365 as modules
On Tue, Nov 21, 2000 at 08:10:38PM -0500, Albert D. Cahalan wrote: > > Hmmm, I'm not the only one who doesn't like modules depending > on other modules. I suppose this is part paranoia about extra > complexity leading to problems, and part desire to avoid the > module overhead for common code that will most likely get used. Since the core PCMCIA code and the socket driver are equally essential to do anything useful with PCMCIA, the only reasonable argument I could see for it would be if you are using one kernel on several systems, all of which use PCMCIA, but which need different socket drivers. So you would save... oh... perhaps 2K by having the PCMCIA shared code in the kernel. In any case, I don't think it would require much more than modifying the Config.in for the PCMCIA drivers to support this. My own paranoia would be that you would be adding a bunch of rarely used permutations of config options, that would rarely be tested. -- Dave - 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: 3c59x: Using bad IRQ 0
On Tue, 21 Nov 2000, Jeff Garzik wrote: > > A caveat to this whole scheme is that usb-uhci -already- calls > pci_enable_device before checking dev->irq, and yet cannot get around > the "assign IRQ to USB: no" setting in BIOS. I hope that is an > exception rather than the rule. Do we have a recent report of this with full PCI debug output? It might just be another unlisted intel irq router.. Linus - 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.0test11-ac1
Alan Cox wrote:
>
>> I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed
out:
>>
>> /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall
-Wstrict-prototypes
>> -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
>> sched.o sched.c
>> irq.c:182: conflicting types for `global_irq_lock'
>> /usr/src/linux/include/asm/hardirq.h:45: previous declaration of
>> `global_irq_lock'
>
>I'll check this. I take it you tried an SMP build ?
Yes, this above build attempt was for an SMP kernel. When I got home,
I tried to build an UP kernel with test11-ac1, and as I'm sure you know
already, it worked perfectly. I then tried to build another SMP kernel, with
the same results as above.
I submitted a tiny patchlet earlier for this. It seems to fix the symptoms.
I compiled and ran a kernel with this patch on the SMP box at work.
I replicated the associated comment for people searching on this pattern.
I'm at home now, please cc any questions or comments to [EMAIL PROTECTED]
Steven
Here is the patchlet again:
diff -u linux/include/asm/hardirq.h.orig linux/include/asm/hardirq.h
--- linux/include/asm/hardirq.h.origTue Nov 21 13:38:07 2000
+++ linux/include/asm/hardirq.h Tue Nov 21 13:40:13 2000
@@ -42,7 +42,7 @@
#include
extern unsigned char global_irq_holder;
-extern unsigned volatile int global_irq_lock;
+extern unsigned volatile long global_irq_lock; /* long for set_bit --RR */
static inline int irqs_running (void)
{
-
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: [uPATCH] fix IDE/ServerWorks OSB4 config option (test11)
Oh well mistakes in Config are okay and not fatal. Thanks for the find Bart. Cheers, On Tue, 21 Nov 2000, Bartlomiej Zolnierkiewicz wrote: > > Hi > > In drivers/Config.in CONFIG_BLK_DEV_OSB4 depends on itself... > > -- > Bartlomiej Zolnierkiewicz > <[EMAIL PROTECTED]> > > --- linux-240t11/drivers/ide/Config.inWed Nov 15 22:02:11 2000 > +++ linux/drivers/ide/Config.in Tue Nov 21 14:52:07 2000 > @@ -68,7 +68,7 @@ > dep_bool 'OPTi 82C621 chipset enhanced support (EXPERIMENTAL)' >CONFIG_BLK_DEV_OPTI621 $CONFIG_EXPERIMENTAL > dep_bool 'PROMISE PDC20246/PDC20262/PDC20267 support' >CONFIG_BLK_DEV_PDC202XX $CONFIG_BLK_DEV_IDEDMA_PCI > dep_bool ' Special UDMA Feature' CONFIG_PDC202XX_BURST >$CONFIG_BLK_DEV_PDC202XX > - dep_bool 'ServerWorks OSB4 chipset support' CONFIG_BLK_DEV_OSB4 >$CONFIG_BLK_DEV_OSB4 > + dep_bool 'ServerWorks OSB4 chipset support' CONFIG_BLK_DEV_OSB4 >$CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 > dep_bool 'SiS5513 chipset support' CONFIG_BLK_DEV_SIS5513 >$CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 > dep_bool 'SLC90E66 chipset support' CONFIG_BLK_DEV_SLC90E66 >$CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 > dep_bool 'Tekram TRM290 chipset support (EXPERIMENTAL)' >CONFIG_BLK_DEV_TRM290 $CONFIG_BLK_DEV_IDEDMA_PCI > > Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: beware of dead string constants
[I wrote]
> > > void foo (void)
> > > {
> > > if (0)
> > > printk(KERN_INFO "bar");
> > > }
> > >
[J . A . Magallon]
> Is it related to opt level ? -O3 does auto-inlining and -O2 does not
> (discovered that here, auto inlining in kernel trashes the cache...)
See for yourself. 'gcc -S' is most helpful. The above generates a
string constant "bar\0" for all optimization levels.
Jakub Jelinek claims to have fixed this particular bug in the last week
or so, although I have not downloaded and compiled recent CVS to verify
this. (Didn't someone at some point have a cgi frontend to
CVS-snapshot 'gcc -S'? I can't find it now.)
There is a similar case of scoped 'static' variables, like 'bar' here:
extern void baz (int *);
void foo (void)
{
if (0) {
static int bar[1024]; /* useless 4096-byte hole in bss */
baz(bar);
}
}
and according to Jeff Law, this case is *not* fixed yet.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0, test10, test11: HPT366 problem
On Tue, 21 Nov 2000, David Woodhouse wrote: > On Tue, 21 Nov 2000, Andre Hedrick wrote: > > > No, if it doesn not hang and we get iCRC errors it will down grade > > automatically, but it is a transfer rate issue than it must be hard coded > > to force an upper threshold limit. > > Do we downgrade gracefully, or do we just drop directly to non-DMA mode? With Grace, and now you blessed, go in peace my son. grep crc ./drivers/ide/* Cheers, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test11: "_isofs_bmap: block < 0"
On Tue, Nov 21, 2000 at 08:14:51AM +0300, Eugene Crosser wrote: > zero entries on the mounted CD, and each "ls" attempt causes this > kernel message: > > _isofs_bmap: block < 0 Same here, except that once showed _isofs_bmap: block >= EOF (1633681408, 4096) -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." hkp://keys.pgp.com - 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: Why not PCMCIA built-in and yenta/i82365 as modules
>> The subject says it all. Is there any particular (technical) reason >> why I must have both the generic pcmcia code and the controller >> support built-in, or build all of them as modules? > > Is there a technical reason for this? Not that I know of; but then I > also cannot think of a good reason for wanting, say, the generic code > built in but the controller support as modules. I do see reasonable > arguments for all-builtin or all-modules. Hmmm, I'm not the only one who doesn't like modules depending on other modules. I suppose this is part paranoia about extra complexity leading to problems, and part desire to avoid the module overhead for common code that will most likely get used. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[2.2.17] oops in /proc/scsi/scsi
I was playing around with Kurt Garloff's rescan-scsi-bus.sh, more precisely, I moved an entire bus from my Tekram DC-390U (with sym53c8xx driver) to my Tekram DC-390 (with tmscsim driver). Then, I ran that script which effectively sends a lot of stuff to /proc/scsi/scsi (scsi add-single-device). I ran that script several times since it did not collect all devices, and at one time, I got two oopsen that I decoded. The script is available at: http://www.garloff.de/kurt/linux/ The Kernel is a patched 2.2.17, but I think it has no SCSI-related patches apart from an updated (2.0e3) tmscsim driver. Here's the full patch list: * ide.2.2.17.all.2904 * i²c 2.5.4 * lm_sensors 2.5.4 * dc390 2.0e3 * serial 5.05 * NFSv3: linux-2.2.17-nfsv3-0.23.1.dif dhiggen-over-0.23.1 restore_rsize * ReiserFS v3.5.27 These are the oopses: ksymoops 2.3.5 on i586 2.2.17ma3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.17ma3/ (default) -m /boot/System.map-2.2.17ma3 (specified) Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found in System.map. Ignoring ksyms_base entry Unable to handle kernel NULL pointer dereference at virtual address 0052 current->tss.cr3 = 05463000, %%cr3 = 05463000 *pde = Oops: 0002 CPU:0 EIP:0010:[sr_finish+112/388] EFLAGS: 00010206 eax: ebx: 0054 ecx: 0005 edx: c7f9cc00 esi: c267bd50 edi: c7f9cc40 ebp: 0001 esp: c267bd3c ds: 0018 es: 0018 ss: 0018 Process rescan-scsi-bus (pid: 18301, process nr: 122, stackpage=c267b000) Stack: c7e3c000 c02a9980 c267bd4c 00307273 c01fedaf c33a0820 0008 c010a058 c01fedf3 c7e3c000 0001 c5902140 c02caee0 c5902148 c0132793 c5902140 c267bda4 c267bda4 c0001a00 0002 c5780280 Call Trace: [scan_scsis+491/1076] [common_interrupt+24/32] [scan_scsis+559/1076] [get_new_inode+147/312] [vsprintf+720/764] [wake_up_process+64/76] [__wake_up+59/68] Code: 80 48 52 20 a1 ac 99 2a c0 80 4c 18 16 08 a1 ac 99 2a c0 80 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 80 48 52 20 orb$0x20,0x52(%eax) Code; 0004 Before first symbol 4: a1 ac 99 2a c0mov0xc02a99ac,%eax Code; 0009 Before first symbol 9: 80 4c 18 16 08orb$0x8,0x16(%eax,%ebx,1) Code; 000e Before first symbol e: a1 ac 99 2a c0mov0xc02a99ac,%eax Code; 0013 Before first symbol 13: 80 00 00 addb $0x0,(%eax) Unable to handle kernel NULL pointer dereference at virtual address 0032 current->tss.cr3 = 02394000, %%cr3 = 02394000 *pde = Oops: CPU:0 EIP:0010:[proc_print_scsidevice+35/504] EFLAGS: 00010246 eax: ebx: c2577d40 ecx: c154f328 edx: c2577d40 esi: 0329 edi: c7e3c000 ebp: c154f000 esp: c0551e78 ds: 0018 es: 0018 ss: 0018 Process cat (pid: 18466, process nr: 140, stackpage=c0551000) Stack: 0002 c2577d40 0329 c7e3c000 c154f000 c154f000 c0271d8a c33a086a c33a0852 c4ae0ac0 0212 c1f564c0 c0200e21 c2577d40 c154f000 c0551ef0 0329 c11462a0 0100 0c00 c1f56380 Call Trace: [scsi_device_types+3946/5792] [scsi_proc_info+121/1876] [do_anonymous_page+45/128] [do_no_page+54/212] [dispatch_scsi_info+64/188] [proc_readscsi+150/268] [proc_readscsi+45/268] Code: 66 8b 40 32 25 ff ff 00 00 50 68 20 5c 27 c0 8b 5c 24 50 03 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 66 8b 40 32 mov0x32(%eax),%ax Code; 0004 Before first symbol 4: 25 ff ff 00 00and$0x,%eax Code; 0009 Before first symbol 9: 50push %eax Code; 000a Before first symbol a: 68 20 5c 27 c0push $0xc0275c20 Code; 000f Before first symbol f: 8b 5c 24 50 mov0x50(%esp,1),%ebx Code; 0013 Before first symbol 13: 03 00 add(%eax),%eax 1 warning issued. Results may not be reliable. -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] isofs/rock.c
William K. Josephson <[EMAIL PROTECTED]>
wrote on Sun, 8 Oct 2000:
> While writing some user-space code recently, I ran across two bugs
> in the Rock Ridge support code. First, a bogus return value and
> second links on the cd of the form foo->/bar are returned
> as foo->//bar. This should fix it.
I think he was mistaken on both counts.
The present 2.4.0test11 only contains the first of his patches.
The 1-line patch below undoes that (and reintroduces some ugliness).
--- rock.c~ Tue Nov 21 21:44:14 2000
+++ rock.c Wed Nov 22 00:55:33 2000
@@ -215,7 +215,7 @@
printk("RR: RE (%x)\n", inode->i_ino);
#endif
if (buffer) kfree(buffer);
- return 0;
+ return -1;
default:
break;
}
[pasted from another window].
Concerning the case above: a RE entry denotes a relocated
directory, something we do not want to see here, so we
should return a "nothing" value.
The ugly code we used to have made get_rock_ridge_filename()
as called in dir.c return -1, and the code
map = 1;
if (we_have_rockridge) {
len = get_rock_ridge_filename(de, tmpname, inode);
if (len != 0) {
p = tmpname;
map = 0;
}
}
if (map) {
...
}
if (len > 0) {
...
}
filp->f_pos += de_len;
continue;
}
would make sure that nothing was done with this filename
and f_pos incremented, entirely as desired.
What 2.4.0test11 does is return 0, but now map is still 1,
and the code invents a real filename there, and then
comes with annoying console messages
Attempt to read inode for relocated directory
So, the old situation was ugly but correct, the new situation wrong.
(I describe this in so much detail because I can readily imagine
that you would like to polish things a bit more.
This get_rock_ridge_filename is also called in namei.c, and
the -1 return value leads to obscure nonsense,
that happens to work today.)
Andries
-
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.0test11-ac1
Followup to: <[EMAIL PROTECTED]> By author:Alan Cox <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > > Nononono... the 82489DX is an *external* APIC, which should be usable > > on any Socket 5/7 CPU... > > I know of no socket 7 board with an 82489DX, and no board on the planet which > has 82489DX and works SMP with a non intel processor. I accept its a heuristic > but so is the current behaviour, and the current heuristic isnt working for > as many cases. > Fair enough. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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/
double page fault in 2.4
Hi all, Running a 2.4.0-text 10 + XFS + CONFIG_HIGHMEM4GB kernel on a 2p ia32 SMP box with 1Gb of memory, our XFS QA locks up the kernel fairly repeatably. It takes quite a while to happen and doesn't appear to be related to XFS. It also only happens when CONFIG_HIGHMEM4GB is enabled, which suggests it's a highmem interraction. The problem appears to be a nested page fault while pulling in a page from an exectuable on an ext2 partition. I've attached a kdb backtrace. Does this ring any bells for anyone? [0]kdb> btp 5868 EBP EIP Function(args) 0xf6945858 0xc0117638 schedule+0x42c (0xf6944000, 0xf6944000, 0xc01130bc) kernel .text 0xc010 0xc011720c 0xc0117910 0xf6945880 0xc0107a84 __down+0x6c kernel .text 0xc010 0xc0107a18 0xc0107adc 0xf6945894 0xc0107c27 __down_failed+0xb (0xf6944000, 0x0, 0xc01130bc, 0xc01b2997, 0xf6d3213c) kernel .text 0xc010 0xc0107c1c 0xc0107c30 0xc01ff6f9 stext_lock+0x4d1 kernel .text.lock 0xc01ff228 0xc01ff228 0xc02050e0 0xf6945938 0xc0113128 do_page_fault+0x6c (0xf6945948, 0x0, 0xf69459e0, 0x0, 0xf69459dc) kernel .text 0xc010 0xc01130bc 0xc01134f0 0xc0109178 error_code+0x34 kernel .text 0xc010 0xc0109144 0xc0109180 Interrupt registers: eax = 0x ebx = 0xf69459e0 ecx = 0x edx = 0xf69459dc esi = 0xf6c17de0 edi = 0xf69459dc esp = 0xf694597c eip = 0xc0159719 ebp = 0xf6945a10 xss = 0x0018 xcs = 0x0010 eflags = 0x00010246 xds = 0xf6940018 xes = 0x0018 origeax = 0x = 0xf6945948 0xc0159719 ext2_get_block+0x13d (0xf6d050e0, 0xc, 0xf6bac600, 0x0) kernel .text 0xc010 0xc01595dc 0xc0159b04 0xf6945a90 0xc0136c12 block_read_full_page+0x11a (0xc20f4648, 0xc01595dc) kernel .text 0xc010 0xc0136af8 0xc0136dc0 0xf6945aa0 0xc0159cf9 ext2_readpage+0x11 (0xf7429120, 0xc20f4648) [0]more> kernel .text 0xc010 0xc0159ce8 0xc0159d00 0xf6945ac4 0xc01262b8 read_cluster_nonblocking+0x110 (0xf7429120, 0x2, 0x18) kernel .text 0xc010 0xc01261a8 0xc01262fc 0xf6945b10 0xc0127956 filemap_nopage+0x26e (0xf7332120, 0x804b000, 0x1) kernel .text 0xc010 0xc01276e8 0xc0127bb4 0xf6945b30 0xc01240ed do_no_page+0x51 (0xf6d32120, 0xf7332120, 0x804b6cc, 0x1, 0xeb0cc12c) kernel .text 0xc010 0xc012409c 0xc012414c 0xf6945b60 0xc0124254 handle_mm_fault+0x108 (0xf6d32120, 0xf7332120, 0x804b6cc, 0x1, 0xf6944000) kernel .text 0xc010 0xc012414c 0xc01242ec 0xf6945c14 0xc011322b do_page_fault+0x16f (0xf6945c24, 0x2, 0x934, 0x24d, 0x24d) kernel .text 0xc010 0xc01130bc 0xc01134f0 0xc0109178 error_code+0x34 kernel .text 0xc010 0xc0109144 0xc0109180 Interrupt registers: eax = 0x ebx = 0x0934 ecx = 0x024d edx = 0x024d esi = 0x edi = 0x0804b6cc esp = 0xf6945c58 eip = 0xc01f8667 ebp = 0xf6945c68 xss = 0x0018 xcs = 0x0010 eflags = 0x00010246 xds = 0x0018 xes = 0x0018 origeax = 0x = 0xf6945c24 0xc01f8667 clear_user+0x37 (0x804b6cc, 0x934) kernel .text 0xc010 0xc01f8630 0xc01f867c 0xf6945c78 0xc014f20e padzero+0x1e (0x804b6cc, 0x804b6cc, 0x804b910, 0xc02c14b8, 0xc014f8f4) kernel .text 0xc010 0xc014f1f0 0xc014f214 0xf6945e10 0xc0150364 load_elf_binary+0xa70 (0xf6945e68, 0xf6945fc4, 0xf6945e68) [0]more> kernel .text 0xc010 0xc014f8f4 0xc01504c8 0xf6945e48 0xc013e2b8 search_binary_handler+0x68 (0xf6945e68, 0xf6945fc4) kernel .text 0xc010 0xc013e250 0xc013e400 0xf6945f9c 0xc013e548 do_execve+0x148 (0xf676f000, 0x80a9d38, 0x80a3c40, 0xf6945fc4) kernel .text 0xc010 0xc013e400 0xc013e59c 0xf6945fbc 0xc010795f sys_execve+0x2f (0x80a9ce0, 0x80a9d38, 0x80a3c40, 0x80a9d38, 0x80a9ce0) kernel .text 0xc010 0xc0107930 0xc010798c 0xc0109047 system_call+0x33 kernel .text 0xc010 0xc0109014 0xc010904c - Daniel Moore [EMAIL PROTECTED] R Software Engineer Phone: +61-3-98348209 SGI Performance Tools Group Fax: +61-3-98132378 - - 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: e2fs performance as function of block size
Alan Cox wrote: > > > It's as though the disk drivers are optimized for this case (1024). I > > The disk drivers are not, and they normally see merged runs of blocks so they > will see big chunks rather than 1K then 1K then 1K etc. > > > behavior, but there is clearly some optimization relative to this size > > inherent in the design of Linux -- and it may be a pure accident. This > > person may be mixing and matching block sizes in the buffer cache, which > > would satisfy your explanation. > > I see higher performance with 4K block sizes. I should see higher latency too ^ Since buffer heads are chained, this would make sense. > but have never been able to measure it. Maybe it depends on the file system. > It certainly depends on the nature of requests Could be. NWFS likes 4K block sizes -- this is it's default. On linux, I've been emulating other block sizes beneath it. I see best performance at 1024 byte blocks, worst at 512. The overhead of buffer chaining is clearly the culprit. On the TCPIP oops on 2.2.18-22, I have not been able to reproduce it reliably. It appears to be in the ppp code, however, and not the TCPIP code. The problem only shows up after several pppd connections have accessed the box then terminated the connections (which is why I think it's pp related). I would rate this as a level IV bug due to the difficulty in creating it, and the fact that you have to deliberately misconfigure a TCPIP network to make it show up. Jeff Jeff - 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: e2fs performance as function of block size
On Tue, Nov 21, 2000 at 05:06:20PM -0700, Jeff V. Merkey wrote: > > > Alan Cox wrote: > > > > > Sirs, > > > performing extensive tests on linux platform performance, optimized as > > > database server, I got IMHO confusing results: > > > in particular e2fs initialized to use 1024 block/fragment size showed > > > significant I/O gains over 4096 block/fragment size, while I expected t= > > > he > > > opposite. I would appreciate some hints to understand this. > > > > It may be that your database is writing out 1K sized blocks on random > > boundaries. If so then the behaviour you describe would be quite reasonable. > > Alan, > > Perhaps, but I have reported this before and seen something similiar. > It's as though the disk drivers are optimized for this case (1024). I > get better performance running NWFS at 1024 block size vs. all the other > sizes, even with EXT2 configured to use 4096, etc. At first glance, > when I was changing block sizes, I did note that by default, EXT2 set to > 1024 would mix buffer sizes in the buffer cache, which skewed caching > behavior, but there is clearly some optimization relative to this size > inherent in the design of Linux -- and it may be a pure accident. This > person may be mixing and matching block sizes in the buffer cache, which > would satisfy your explanation. > You may want to try using raw I/O to fully characterize the behavior of you device. I found that when I use raw I/O I could get very good performance characteristics for devices. If you use dd with a raw device you can vary the block size to see what kind of performance you get out of different sizes. This will completely bypass any affects of buffer cache to get you the performance of the disk in question. An example of this would be to run this sequence of commands noting the time it takes to run it (all transfers 100MB): time dd if=/dev/zero of=/dev/raw1 bs=512 count=204800 time dd if=/dev/zero of=/dev/raw1 bs=1k count=102400 time dd if=/dev/zero of=/dev/raw1 bs=4k count=25600 ... The standard Stephen Tweedie raw I/O will do up to 64KB chunks, beyond that you'll probably have to write one specific to your device (SGI has one for SCSI which I've gotten up to 1MB reads/writes). Using dd doesn't necessarily show you your performance as most access patterns will not be completely sequential in nature, but you can figure out what your "sweet spot" is for your block size. BAPper - 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: Better testing of hardware (was: Defective Read Hat)
"Stephen Gutknecht (linux-kernel)" wrote: > Part of the issue is that there exists no "easy to use" standardized test > software. Full 32-bit concurrent use of many devices can reveal problems > that users do not often see in normal applications. > > One major hardware review site found stability problems with the Intel > Pentium 3 1130Mhz processor that ultimately lead to Intel delaying the > release -- it passed all tests but not a compile of the Linux Kernel! This > was on more than 3 different processors. > http://www.tomshardware.com/cpu/00q3/0008281/pentiumiii-04.html > > A Linux Kernel compile test does a really good job of testing the hard disk, > RAM, and CPU... as it executes all types of instructions and the final > output depends on all prior steps completing correctly. On a really fast > system (> 900Mhz) might make sense to run it twice, once to "warm up" the > CPU and other components. Most "benchmarks" just test speed, not the actual > stability or data integrity (they write results to a device but don't check > for data corruption, or they test only one device at a time, not all at > once). > > What a Linux kernel compile DOESN'T test is the network interfaces and video > cards. > > Compiling over NFS with compilation lines producing some kind of openGL animation ? -- %-% % FORT David, % % 7 avenue de la morvandière 0240726275 % % 44470 Thouare, France[EMAIL PROTECTED] % % ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] % %--LINUX-HTTPD-PIOGENE% % -datamining <-/| .~. % % -networking/flashed PHP3 coming soon | /V\L I N U X% % -opensource| // \\ >Fear the Penguin< % % -GNOME/enlightenment/GIMP | /( )\ % % feel enlighted| ^^-^^% % http://ibonneace.dnsalias.org/ when connected % %-% - 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.0test11-ac1
> > Intel stuff appears to always be happy poking in APIC space. I don't know > > if this is related to the chip internals on the non APIC capable chips. > > Nononono... the 82489DX is an *external* APIC, which should be usable > on any Socket 5/7 CPU... I know of no socket 7 board with an 82489DX, and no board on the planet which has 82489DX and works SMP with a non intel processor. I accept its a heuristic but so is the current behaviour, and the current heuristic isnt working for as many cases. Alan - 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: e2fs performance as function of block size
> It's as though the disk drivers are optimized for this case (1024). I The disk drivers are not, and they normally see merged runs of blocks so they will see big chunks rather than 1K then 1K then 1K etc. > behavior, but there is clearly some optimization relative to this size > inherent in the design of Linux -- and it may be a pure accident. This > person may be mixing and matching block sizes in the buffer cache, which > would satisfy your explanation. I see higher performance with 4K block sizes. I should see higher latency too but have never been able to measure it. Maybe it depends on the file system. It certainly depends on the nature of requests - 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/
LINUX_REBOOT_MAGIC2C
I guess we can soon expect patch from Linus adding LINUX_REBOOT_MAGIC2C to Linux kernel. -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - 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: e2fs performance as function of block size
Alan Cox wrote: > > > Sirs, > > performing extensive tests on linux platform performance, optimized as > > database server, I got IMHO confusing results: > > in particular e2fs initialized to use 1024 block/fragment size showed > > significant I/O gains over 4096 block/fragment size, while I expected t= > > he > > opposite. I would appreciate some hints to understand this. > > It may be that your database is writing out 1K sized blocks on random > boundaries. If so then the behaviour you describe would be quite reasonable. Alan, Perhaps, but I have reported this before and seen something similiar. It's as though the disk drivers are optimized for this case (1024). I get better performance running NWFS at 1024 block size vs. all the other sizes, even with EXT2 configured to use 4096, etc. At first glance, when I was changing block sizes, I did note that by default, EXT2 set to 1024 would mix buffer sizes in the buffer cache, which skewed caching behavior, but there is clearly some optimization relative to this size inherent in the design of Linux -- and it may be a pure accident. This person may be mixing and matching block sizes in the buffer cache, which would satisfy your explanation. Jeff > > - > 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: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
"J . A . Magallon" wrote: > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote: > > -static int dataPort = 0; /* port for register data */ > > +static int dataPort; /* port for register data */ > > That is not too much confidence on the ANSI-ness of the compiler ??? There is nothing wrong with that change. Standard kernel style cleanup, which saves a few bytes in the output kernel image. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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.0test11-ac1
Followup to: <[EMAIL PROTECTED]> By author:Alan Cox <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > > making any assumptions about APIC availability on a processor. > > > > OK, but how does it handle the 82489DX? There are valid configurations > > using this kind of APIC, including Pentium P54C ones... > > These processors don't report the APIC on the cpuid ? If so then I guess > the fix is something like this > > if( cpuid says there is no local apic && vendor != intel) > > Intel stuff appears to always be happy poking in APIC space. I don't know > if this is related to the chip internals on the non APIC capable chips. > Nononono... the 82489DX is an *external* APIC, which should be usable on any Socket 5/7 CPU... -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: Why not PCMCIA built-in and yenta/i82365 as modules
On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote: > The subject says it all. Is there any particular (technical) reason why I > must have both the generic pcmcia code and the controller support > built-in, or build all of them as modules? Is there a technical reason for this? Not that I know of; but then I also cannot think of a good reason for wanting, say, the generic code built in but the controller support as modules. I do see reasonable arguments for all-builtin or all-modules. -- Dave - 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/
Oops in 2.2.18-22 with non-existent TCPIP route
Alan, I have an Oops with 2.2.18-22 that only shows up on a Linux server that's configured as a pppd dial in server with dynamic address assignment (no DHCP). Host IP addresses are configured in an options.ttyS0(192.168.0.1) and options.ttyS1(192.168.0.2) files in /etc/ppp. We caused the Oops by accident when we misconfigured our Cisco CPA 2501 router with a static route for network 207.225.212.40 (mask 255.255.255.248) that pointed to this server (the server had no routes to this network but used to). We were moving some servers around to segregate the law firm onto a private network. I was not running ksymoops but have it setup now and we are attempting to recreate the conditions that produced the oops. The Oops reported is crashed in process slocate (clearly misleading -- looks like an Oops from an interrupt). We will attempt to get the Oops again. Jeff - 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.2.18-pre19 asm/delay.h problem?
> module that is pulling the definition of udelay() from asm/delay.h, it's > referencing __bad_udelay(). However, I can't seem to find the __bad_udelay() > function actually defined anyplace. (Although it could be somewhere in the > kernel source that my grep missed.) Its intentionally missing > Would this be a bug in the module that I'm compiling? Or a real forgotten and You got it. The module is doing an overlarge delay - 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/
linux-2.2.18-pre19 asm/delay.h problem?
Hello, Possibly an issue with an external module that I'm using, but when I compile a module that is pulling the definition of udelay() from asm/delay.h, it's referencing __bad_udelay(). However, I can't seem to find the __bad_udelay() function actually defined anyplace. (Although it could be somewhere in the kernel source that my grep missed.) Would this be a bug in the module that I'm compiling? Or a real forgotten and unused symbol in the delay.h file? I doubt it would be the latter, but I can't figure out what I should link this module against to make things work. Thanks so much, Joe Pranevich Product Support Analyst Lycos.com - 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: NVdriver-problem with 2.4.0-test11
Umm what worked for me was to do the following : change the following line in os-interface.c (Part of NVIDIA_kernel package): symbol_value = get_module_symbol(NV_MODULE_NAME, symbol_name); to : symbol_value = inter_module_get_request(NV_MODULE_NAME, symbol_name); and then remove the following lines which appear after the above lines : #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 4, 0) put_module_symbol(symbol_value); #endif Now there may be something else that needs changing, but after doing the above, the driver loaded up fine as did XFree86. Mof. > From: Vitali Lieder [mailto:[EMAIL PROTECTED]] > > Hallo! > > With new 2.4.0-test11 kernel i have the problem with NVdriver-0.95: > > depmod: *** unresolved symbols in > /lib/modules/2.4.0-test11/video/NVdriver > > /lib/modules/2.4.0-test11/video/Nvdriver:unresolved symbol in > put_module_symbol > /lib/modules/2.4.0-test11/video/NVdriver:unresolved symbol in > get_module_symbol > > Please, could you explain me, how i can find in patch the > #define's lines > with this symbols, that was cleaned from kernel, so that i > can place that > lines by myself in future. - 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: 53c400 driver
> 53c400a non-PNP still lock this system hard. It starts barking about a > busy SCSI bus, and then I can fsck again. > > To Alan : How hard is it to get thing beast (53c400 and family) to be SMP > safe ?? Or is it better to start over again ? The problem is that the code takes spinlocks recursively. The original code (see 2.0's 5380 generic C code) uses cli/sti. It was converted to use spin_lock() but not allowing for the recursive locking cases. I tried to untangle the code paths but they are so ugly and some of the code is sufficiently messy and unmaintained (for about 6 years) that I gave up trying to decode it. Alan - 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: tmscsim driver on test11-pre7 stops working when starting X
On Mon, Nov 20, 2000 at 03:03:03AM +0100, Malte Cornils wrote: > my Dawicontrol 2974 SCSI-adapter fails with kernel 2.4.0-test10 > with pre-11 and reiserfs for kernel test-10 patched in: > > -- > Nov 20 01:30:23 wh36-b407 kernel: scsi : aborting command due to timeout : pid 0, >scsi0, channel 0, id 0, lun 0 Read (10) 00 00 08 c0 6c 00 00 f8 00 > Nov 20 01:30:23 wh36-b407 kernel: DC390: Abort command (pid 0, DCB c12c11c0, SRB >) > Nov 20 01:30:23 wh36-b407 kernel: DC390: Status of last IRQ (DMA/SC/Int/IRQ): >0890cc20 > Nov 20 01:30:23 wh36-b407 kernel: DC390: Register dump: SCSI block: > Nov 20 01:30:23 wh36-b407 kernel: DC390: XferCnt Cmd Stat IntS IRQS FFIS Ctl1 Ctl2 >Ctl3 Ctl4 > Nov 20 01:30:23 wh36-b407 kernel: DC390: 00 44 10 cc 00 80 17 48 > 18 04 > Nov 20 01:30:23 wh36-b407 kernel: DC390: Register dump: DMA engine: > Nov 20 01:30:23 wh36-b407 kernel: DC390: Cmd STrCntSBusAWrkBCWrkAC >Stat SBusCtrl > Nov 20 01:30:23 wh36-b407 kernel: DC390: 80 1000 051a4000 051a5000 >00 0308 > Nov 20 01:30:23 wh36-b407 kernel: DC390: Register dump: PCI Status: 0200 > Nov 20 01:30:23 wh36-b407 kernel: DC390: In case of driver trouble read >linux/drivers/scsi/README.tmscsim > Nov 20 01:30:23 wh36-b407 kernel: DC390: Aborted pid 0 with status 0 pid 0: So, already the device scan fails? I'll have to look up the register dump to analyze it. Would you test the patch I sent you on top of 2.0e5, please? > This happened on the second bootup with the new kernel, when kdm > was starting Xfree 4.0.1 from Debian woody. > Nov 20 01:29:34 wh36-b407 kernel: Bad boy: tmscsim (at 0xc02bf732) called us without >a dev_id! Fixed in 2.0eX, BTW. > I noted there's a new version of the driver on the maintainer's (Kurt > Garloff) homepage, but last time I tested it and reported an oops with > 2.4.test-something he didn't reply at all (that's not an offense, it's > understandable with the amount of work he's doing for KDE2 etc). I tend to answer mails, where I know a solution very quickly, but tend to not send messages like "Thanks I got your mail, I'll look into it!" Actually, when I got some time to do some work, I look for yet unanswered mails. > So should I > a) try with his patch again; my oops report for that is attached below > b) wait you can make of this bugreport > c) provide any further info/testing? Test the patch on 2.0e5 I sent you, please. > BTW, 2.2.17 with the stock tmscsim works fine everytime; with that kernel > (and no other changes) the system is excessively stable :) That's at least something! > CU, Yours Malte #8-) > > PS: Please cc me, I'm usually watching the lists I report bugs to, but LKML > is a bit... excessive; I'll monitor the list from time to time, but can't > guarantee timely responses... Nor can I. Actually, messages concerning drivers I maintain are sorted by procmailrc to a different folder :-) > The next boot, while in the fsck-Phase for the SCSI drive (SysRq > didn't work *that* well obviously :)) I got the oops. There were > some lines scrolling by which I unfortunately couldn't write down > fast enough, but I did copy the oops: > > Oops: Should be fixed in 2.0e5 and later. > Also, the oops occured when I was sharing interrupts (but this is > PCI, so there should be no problems, right?). That's correct only if level triggered IRQs are used. > I just fear that Linus might avoid large patches for the now > imminent 2.4... :-? The 2.0d driver does not work correctly with 2.4, and I'm trying to make sure 2.0f will be perfect. I don't see why Linus should refuse to accept a patch. Regards, -- Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
"Adam J. Richter" wrote:
>
> Here is a patch which ports drivers/sound/maestro.c to the new PCI
> interface, which Zach Brown asked me to post here for comments.
> This patch includes Zach's changes eliminating the ioctl lockups which
> he posted separately, just to make it easier to generate the final
> product from pristine 2.4.0-test11. I could actually divide this
> patch into three phases if need be:
> (a) The ioctl lockup fix which Zach has already submitted for
> (presumably) the next "-pre" release.
> (b) The pci_device_id table declaration and MODULE_DEVICE_TABLE.
> (c) Moving to the new PCI interface. If I were to conform to
> Jeff Garzick's requests on __initdata and __devinitdata, this would
> include changes that would change an __initdata delcaration in
> (b) to __devinitdata.
hmmm. I'm not so sure that the locking is correct... if the intention
was to serialize access to the mixer, there are surely better ways to do
it. Why are interrupts disabled? In any case it will probably change
when maestro goes ac97_codec (tested patches in gkernel CVS)... which it
needs to do ;-)
This driver needs __devxxx, I've heard mention of some hotpluggable
audio that is based on the maestro chipset (which chip I don't remember)
The formatting of pci_device_id data is awful. Named initializers
-reduce- the readability of the code here, are highly redundant, and its
usage is totally inconsistent with -all- other PCI drivers in the
kernel.
To make Zab's life a little easier, use pci_{get,set}_drvdata to make it
easier to port the code back to 2.2.x. Since pci_dev::driver_data
doesn't exist on 2.2.x, you have to ugly up the code with ifdefs, or use
a compatibility macro (like, say, pci_xxx_drvdata.. :))
Unrelated to your change: the maestro reboot notifier shouldn't need to
unregister all that stuff. Who cares if the sound devices are freed,
since we are rebooting. free_irq+maestro_power seems sufficient. or
maybe stop_dma+free_irq+poweroff.
Unrelated to your change: Feel free to submit patches to update
Documentation/pci.txt if you feel it is missing information.
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
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: e2fs performance as function of block size
> Sirs, > performing extensive tests on linux platform performance, optimized as > database server, I got IMHO confusing results: > in particular e2fs initialized to use 1024 block/fragment size showed > significant I/O gains over 4096 block/fragment size, while I expected t= > he > opposite. I would appreciate some hints to understand this. It may be that your database is writing out 1K sized blocks on random boundaries. If so then the behaviour you describe would be quite reasonable. - 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.0test11-ac1
> > MP table regardless of the capabilities of the CPU installed. Its apparently > > legal to do so. There is an apic capability flag that should be tested before > It's not legal -- the MPS is very explicit the MP-table must reflect a > real configuration. Intel tell me otherwise. The real world also disagrees which makes the discussion a little pointless. We have to handle the real situation where this occurs > > making any assumptions about APIC availability on a processor. > > OK, but how does it handle the 82489DX? There are valid configurations > using this kind of APIC, including Pentium P54C ones... These processors don't report the APIC on the cpuid ? If so then I guess the fix is something like this if( cpuid says there is no local apic && vendor != intel) Intel stuff appears to always be happy poking in APIC space. I don't know if this is related to the chip internals on the non APIC capable chips. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
On Wed, 22 Nov 2000 00:26:23 Tigran Aivazian wrote: > On Wed, 22 Nov 2000, J . A . Magallon wrote: > > In the case of kernel, we have to do many things manually, can't rely on > some compiler (sometimes :). So, the code I pointed you at > arch/i386/kernel/head.S (look for "Clear BSS") is in fact what clears the > BSS; without it you will end up with uninitialized garbage in what you > think "ANSI C compiler arranged" for you. > Thanks, that makes everything clear...I'm very suspicious on compilers. Last thing I saw was VisualC++ skipping constructors...but that is off-topic, we talked about 'compilers'... -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer Linux 2.2.18-pre22-vm #7 SMP Sun Nov 19 03:29:20 CET 2000 i686 unknown - 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.0test11-ac1
> I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed out: > > /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes > -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o > sched.o sched.c > irq.c:182: conflicting types for `global_irq_lock' > /usr/src/linux/include/asm/hardirq.h:45: previous declaration of > `global_irq_lock' I'll check this. I take it you tried an SMP build ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
On Wed, 22 Nov 2000, J . A . Magallon wrote: > > On Wed, 22 Nov 2000 00:04:53 Tigran Aivazian wrote: > > On Tue, 21 Nov 2000, J . A . Magallon wrote: > > > > Quite the contrary. The patch seems correct and useful to me. What do you > > think is wrong with it? (Linus accepted megabytes worth of the above in > > the past...) > > > > Sorry, i should look at the rest of the code. Seeing only that, is seems like > that variables have to hold an initial value of zero, and the patch relies > on the ANSI behaviour of the compiler that auto-initializes them to 0. > I have seen many compilers break ANSI rules in optimized mode. Typical > runs-fine-in-debug-mode-but-breaks-on-production-release. > One other point for info would be gcc specs. In the case of kernel, we have to do many things manually, can't rely on some compiler (sometimes :). So, the code I pointed you at arch/i386/kernel/head.S (look for "Clear BSS") is in fact what clears the BSS; without it you will end up with uninitialized garbage in what you think "ANSI C compiler arranged" for you. Regards, Tigran - 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.0test11-ac1
> > o Cleanup console_verbose() dunplication > include/linux/kernel.h: if we are adding new inlines to kernel headers, > they should be 'static inline'.. Agreed > > o Epic100 update > > dhinds seemed to question the epic100 fix which is enclosed in > CONFIG_CARDBUS... also I have a big endian fix for epic100 in my local > tree. I dont think its CONFIG_CARDBUS, we need to test the chip version. But as it stands without that newer cards dont work. Its a WiP > The change to hp-plus is totally unnecessary and backwards... > [un]load_8390_module is null, has been for a while. A bombing run was > made recently through most drivers to -remove- the now-null calls to > *_8390_module. Thats just cruft, already done > > o Tulip crash fix on weird eeproms > Hopefully an update with this and more will be out this week. Ok - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test11] show_mem() to dump free pages
On Tue, 21 Nov 2000, Tigran Aivazian wrote:
> Hi Linus,
>
> In arch/i386/mm/init.c:show_mem() we calculate the number of free pages
> but don't printk it out. Therefore, we must either a) remove the variable
> and the calculation or b) make use of it. I think b) is obviously better.
>
> The patch below was tested under 2.4.0-test11.
apparently, IA64, SuperH and S390 architectures are just as broken as i386
wrt not showing 'free'in show_mem() so here is more complete patch which
covers all architectures:
--- linux/arch/ia64/mm/init.c Tue Oct 10 01:54:56 2000
+++ work/arch/ia64/mm/init.cTue Nov 21 23:18:31 2000
@@ -264,6 +264,7 @@
shared += page_count(mem_map + i) - 1;
}
printk("%d pages of RAM\n", total);
+ printk("%d free pages\n", free);
printk("%d reserved pages\n", reserved);
printk("%d pages shared\n", shared);
printk("%d pages swap cached\n", cached);
--- linux/arch/s390/mm/init.c Mon Oct 16 20:58:51 2000
+++ work/arch/s390/mm/init.cTue Nov 21 23:19:51 2000
@@ -211,6 +211,7 @@
shared += atomic_read(_map[i].count) - 1;
}
printk("%d pages of RAM\n",total);
+printk("%d free pages\n",free);
printk("%d reserved pages\n",reserved);
printk("%d pages shared\n",shared);
printk("%d pages swap cached\n",cached);
--- linux/arch/sh/mm/init.c Mon Oct 16 20:58:51 2000
+++ work/arch/sh/mm/init.c Tue Nov 21 23:20:28 2000
@@ -169,6 +169,7 @@
shared += page_count(mem_map+i) - 1;
}
printk("%d pages of RAM\n",total);
+ printk("%d free pages\n",free);
printk("%d reserved pages\n",reserved);
printk("%d pages shared\n",shared);
printk("%d pages swap cached\n",cached);
--- arch/i386/mm/init.c.0 Tue Nov 21 22:00:52 2000
+++ arch/i386/mm/init.c Tue Nov 21 22:00:36 2000
@@ -221,6 +221,7 @@
}
printk("%d pages of RAM\n", total);
printk("%d pages of HIGHMEM\n",highmem);
+ printk("%d free pages\n",free);
printk("%d reserved pages\n",reserved);
printk("%d pages shared\n",shared);
printk("%d pages swap cached\n",cached);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
On Wed, 22 Nov 2000 00:04:53 Tigran Aivazian wrote: > On Tue, 21 Nov 2000, J . A . Magallon wrote: > > Quite the contrary. The patch seems correct and useful to me. What do you > think is wrong with it? (Linus accepted megabytes worth of the above in > the past...) > Sorry, i should look at the rest of the code. Seeing only that, is seems like that variables have to hold an initial value of zero, and the patch relies on the ANSI behaviour of the compiler that auto-initializes them to 0. I have seen many compilers break ANSI rules in optimized mode. Typical runs-fine-in-debug-mode-but-breaks-on-production-release. One other point for info would be gcc specs. -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer Linux 2.2.18-pre22-vm #7 SMP Sun Nov 19 03:29:20 CET 2000 i686 unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
Richard Torkar wrote: > > Well David, there is such a "manual". > > http://ftp.sunet.se/LDP/FAQ/faqs/GCC-SIG11-FAQ Yes. And if you ask the average new Linux user if they've read it, I doubt you'll get a "yes". My question boils down to this, and this I suppose is a personal/informational request for comments, so don't clutter the list with responses directed at me: What (in your opinion) is the most commonly read Linux user-land document? - 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: USB: Wacom Graphire mouse wheel does not work anymore
On 21 Nov, [EMAIL PROTECTED] wrote: > Hm, there is no stable xinput driver available for XFree 4.0 and > xinput does not support the wheel, too :-( Actually XInput supports that sort of information but probably the XInput driver doesn't. Unfortunately I don't have a Graphire, just a Intuos right now and no airbrush available to test that. -- Servus, Daniel - 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/
Strange thing (/dev/random)
I noticed something odd with the entropy pool in 2.4.0-test11. If a normal user does a 'sysctl -A', the entropy pool empties. I'm not sure why, but it sounds like this isn't a good thing from a security standpoint. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
On Tue, 21 Nov 2000, J . A . Magallon wrote: > > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote: > > > > Quick removal of unnecessary initialization to 0. > > > > > > -static int basePort = 0; /* base port address */ > > -static int regPort = 0;/* port for register number */ > > -static int dataPort = 0; /* port for register data */ > > +static int basePort; /* base port address */ > > +static int regPort;/* port for register number */ > > +static int dataPort; /* port for register data */ > > That is not too much confidence on the ANSI-ness of the compiler ??? > Quite the contrary. The patch seems correct and useful to me. What do you think is wrong with it? (Linus accepted megabytes worth of the above in the past...) (see arch/i386/kernel/head.S and look for surprised. This is becoming FAQ, Richard, how about putting it into your FAQ mentioned at the bottom of this message?) Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
Here is a patch which ports drivers/sound/maestro.c to the new PCI
interface, which Zach Brown asked me to post here for comments.
This patch includes Zach's changes eliminating the ioctl lockups which
he posted separately, just to make it easier to generate the final
product from pristine 2.4.0-test11. I could actually divide this
patch into three phases if need be:
(a) The ioctl lockup fix which Zach has already submitted for
(presumably) the next "-pre" release.
(b) The pci_device_id table declaration and MODULE_DEVICE_TABLE.
(c) Moving to the new PCI interface. If I were to conform to
Jeff Garzick's requests on __initdata and __devinitdata, this would
include changes that would change an __initdata delcaration in
(b) to __devinitdata.
At this point, my preference would be to see (a) in test12-pre1, and
(b) or (b)+(c) in test12-pre2; however, I do not feel strongly about it.
Anyhow, I am sure any feedback would be appreciated.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.0-test11/drivers/sound/maestro.c Sat Nov 11 18:33:13 2000
+++ linux/drivers/sound/maestro.c Wed Nov 15 22:25:42 2000
@@ -243,7 +243,6 @@
#include
#include
-static int maestro_pm_callback(struct pm_dev *dev, pm_request_t rqst, void *d);
#include "maestro.h"
@@ -355,6 +354,51 @@
TYPE_MAESTRO2E
};
+static struct pci_device_id maestro_pci_ids[] __devinitdata = {
+ {
+ vendor: PCI_VENDOR_ESS,
+ device: PCI_DEVICE_ID_ESS_ESS1968,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ driver_data: TYPE_MAESTRO2
+ },
+ {
+ vendor: PCI_VENDOR_ESS,
+ device: PCI_DEVICE_ID_ESS_ESS1978,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ driver_data: TYPE_MAESTRO2E
+ },
+ {
+ vendor: PCI_VENDOR_ESS_OLD,
+ device: PCI_DEVICE_ID_ESS_ESS0100,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ driver_data: TYPE_MAESTRO
+ },
+ { } /* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(pci, maestro_pci_ids);
+
+static int __devinit maestro_probe(struct pci_dev *pcidev,
+ const struct pci_device_id *id);
+static void __devexit maestro_remove(struct pci_dev *pdev);
+static void maestro_suspend(struct pci_dev *pcidev);
+static void maestro_resume(struct pci_dev *pcidev);
+
+static struct pci_driver maestro_driver = {
+ name: "maestro",
+ id_table: maestro_pci_ids,
+ probe: maestro_probe,
+ remove: maestro_remove,
+#ifdef CONFIG_PM
+ suspend:maestro_suspend,
+ resume: maestro_resume,
+#endif /* PM */
+};
+
+
static const char *card_names[]={
[TYPE_MAESTRO] = "ESS Maestro",
[TYPE_MAESTRO2] = "ESS Maestro 2",
@@ -1958,6 +2002,7 @@
static int mixer_ioctl(struct ess_card *card, unsigned int cmd, unsigned long arg)
{
int i, val=0;
+ unsigned long flags;
VALIDATE_CARD(card);
if (cmd == SOUND_MIXER_INFO) {
@@ -1990,9 +2035,9 @@
if(!card->mix.recmask_io) {
val = 0;
} else {
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
val = card->mix.recmask_io(card,1,0);
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, flags);
}
break;
@@ -2019,9 +2064,9 @@
return -EINVAL;
/* do we ever want to touch the hardware? */
-/* spin_lock(>lock);
+/* spin_lock_irqsave(>lock, flags);
val = card->mix.read_mixer(card,i);
- spin_unlock(>lock);*/
+ spin_unlock_irqrestore(>lock, flags);*/
val = card->mix.mixer_state[i];
/* M_printk("returned 0x%x for mixer %d\n",val,i);*/
@@ -2046,9 +2091,9 @@
if(!val) return 0;
if(! (val &= card->mix.record_sources)) return -EINVAL;
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
card->mix.recmask_io(card,0,val);
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, flags);
return 0;
default:
@@ -2057,9 +2102,9 @@
if ( ! supported_mixer(card,i))
return -EINVAL;
Re: 2.2.X patch query (with initial PATCH against 2.2.17)
Hi Horst. >>> Also, part of my plan was to check that the disk is >>> already in this non-standard format, and refuse to >>> dump if not. This would ensure that doing so didn't >>> overwrite somebody's master boot disk by accident, as >>> such disks will not normally be in this non-standard >>> format. >> Just write a magic number somewhere to the disk and >> mark these blocks bad in the fat. Then just check if >> the blocks are marked as bad and contain the magic >> number. No need for a special disk format per se... There's much better reasons for using a special format than that. Horst has hit the main one - code simplicity. > Why any filesystem at all? Just dump the whole on the > diskette in the drive. If root doesn't know what they > are doing fiddling with SysRq, they deserve it in any > case. No FAT, MS-DOS, VFAT or whatever. Just a plain > formated diskette. That argument's a non-starter in my book - the difference between writing a raw floppy and one with an MS-DOS type filesystem on it comes down to prepending a fixed header to the data, nothing more. The MS-DOS type of filesystem is one of the simplest one can get, but the standard version thereof used with floppies is just a PITA to work with. What I've done is to remain compatible with it, but tweak the parameters to produce a much simpler version thereof. > Remember, this has to be absolutely as simple and > robust as possible, and have minimal impact on the > rest of the kernel... That's precicely why I'm using the modified filesystem I referred to in a previous post. Can I suggest that, before you complain any more about it, you actually try it out? I wrote and released the formatter that produces the said filesystem many months ago now, and can easily send you a copy to play with. It's also its own source code, as the said formatter is written entirely as a BASH shell script, and the fact that it's done that way should speak for itself as to the simplicity of the format used. Basically, from a programming point of view, it comes down to writing a raw disk, but prepending a fixed header (size 4k on a 1440k floppy) to the log being written, and gaining a LOT of advantages with virtually no disadvantages. For reference, here's a few of the features of the said format: 1. Disks in this format can be read from and written to by MS-DOS 2.11, 3.10, 5.00 and 6.22 and by Windows 95, 98 and NT (all tested). 2. Disks formatted in this format do NOT use any extra tracks or sectors per track over those formatted in the standard format. 3. From a programmer's viewpoint, the resulting format is MUCH simpler to handle than the standard one. 4. The data area available on the disk is maximised for any particular physical layout. The first two features mean that the resulting disks can be used on ANY standard floppy drive. The third means that the so-called bloat just will not exist. The fourth is the one that people seem to have concentrated on, but is irrelevant for this application. That particular feature is only really relevant for backup disks. > ...(no "must now pull in RW-floppy-format + fat + > msdos modules to do SysRq-D", no " must be built > into the kernel for SysRq-D to work" (at most "floppy > in kernel", more can be hard to swallow in limited > environments where this will be most needed as the > only/principal way of looking at logs)). None of that is required to use this format - it is designed to (a) be fully compatible with the requirements of MS-DOS 2.00 and later (including WIndows 9x and NT, and (b) be as simple as possible for the programmer to code. Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote: > > Quick removal of unnecessary initialization to 0. > > > -static int basePort = 0; /* base port address */ > -static int regPort = 0; /* port for register number */ > -static int dataPort = 0; /* port for register data */ > +static int basePort; /* base port address */ > +static int regPort; /* port for register number */ > +static int dataPort; /* port for register data */ That is not too much confidence on the ANSI-ness of the compiler ??? -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer Linux 2.2.18-pre22-vm #7 SMP Sun Nov 19 03:29:20 CET 2000 i686 unknown - 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: RAID Benchmarking
On Tuesday November 21, [EMAIL PROTECTED] wrote: > Hi, > I want to know , how to Benchmark the performance of > RAID.Is there any tool for benchmarking? > It all depends on what you want to measure. If you want to measure "how well will this work for me", then you need a tool that generates a load that has similar characteristics to the load that you are likely to impose on the system. If that is large single threaded sequential reads or sequential writes, then bonnie is a pretty good tool. However, this isn't a very typical load for me. I have been using bonnie and dbench which can be found at ftp://samba.org/pub/tridge/dbench/ I have heard that iozone is pretty good too, though I haven't tried it yet: http://www.iozone.org/ If you are looking at software raid5 in 2.4, you might like to look at http://www.cse.unsw.edu.au/~neilb/wiki/?LinuxRaidTest which has a number of neat graphs and links to some patches that make raid5 in 2.4 much faster. You might also like to look at Gary Murakami's page at http://www.research.att.com/~gjm/linux/ide-i75raid.html particularly if you are thinking IDE raid. Hope this helps. NeilBrown - 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: ux164 (ruffian) fixes
On Tue, Nov 21, 2000 at 10:47:20AM -0800, Richard Henderson wrote: > On Tue, Nov 21, 2000 at 06:46:09PM +0300, Ivan Kokshaysky wrote: > >Interesting, other pyxis machines do not seem to be so sensitive, > >so I guess some design problems with ux164 motherboard - all this > >looks pretty much like timing issues. > > Wow. Thanks for following through on this. I can now confirm that I can boot using SCSI disks (the fact that this was possible for a while into IDE was a life-saver here :-) a Ruffian (pyxis) Alpha using 2.4.0-test11 kernel and two patches posted by Ivan (bridges-2.4.0t11.gz and extra ruffian fixes). Here are fragments from 'dmesg': Booting on Ruffian using machine vector Ruffian from MILO Command line: bootdevice=sda2 bootfile=/vml240o11.gz root=/dev/sda2 SCSI subsystem driver Revision: 1.00 sym53c8xx: at PCI bus 1, device 13, function 0 sym53c8xx: 53c875 detected sym53c875-0: rev 0x3 on pci bus 1 device 13 function 0 irq 20 sym53c875-0: ID 7, Fast-20, Parity Checking sym53c875-0: on-chip RAM at 0xa101000 sym53c875-0: restart (scsi reset). sym53c875-0: Downloading SCSI SCRIPTS. scsi0 : sym53c8xx - version 1.6b Vendor: IBM Model: DDRS-39130D Rev: DC1B Type: Direct-Access ANSI SCSI revision: 02 Vendor: TOSHIBA Model: CD-ROM XM-6201TA Rev: 1037 Type: CD-ROM ANSI SCSI revision: 02 Vendor: IBM Model: DDRS-34560D Rev: DC1B Type: Direct-Access ANSI SCSI revision: 02 sym53c875-0-<2,0>: tagged command queue depth set to 8 sym53c875-0-<10,0>: tagged command queue depth set to 8 Detected scsi disk sda at scsi0, channel 0, id 2, lun 0 Detected scsi disk sdb at scsi0, channel 0, id 10, lun 0 VFS: Mounted root (ext2 filesystem) readonly. Those who posted "me too" could you please test that this is not only a fluke on my particular machine? Thanks a bunch, Ivan. Also thanks are extended to Gerard Roudier who provided a crucial hint in the moment when we appeared to be completly stuck. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: e2fs performance as function of block size
Hi I think I have a possible explanation for your observations: 1) 1024B Block size: > User time (seconds): 69.32 > System time (seconds): 25.15 > Percent of CPU this job got: 54% > Elapsed (wall clock) time (h:mm:ss or m:ss): 2:54.14 > Major (requiring I/O) page faults: 43861 2) 4096B Block size: > User time (seconds): 68.43 > System time (seconds): 24.79 > Percent of CPU this job got: 39% > Elapsed (wall clock) time (h:mm:ss or m:ss): 3:54.87 > Major (requiring I/O) page faults: 41944 Your application seems to have a lot of small accesses (<4k). Each time you try to read/write a single byte, the whole disk block has to be in the buffercache. Now when you only have to read 1k from the disk to do this, you're faster than when you have to read 4k. You have to chose if you need good sequential I/O performance for large I/O transfers where you need a large block size and good random small I/O performance where you want to have a small block size. Have fun Reto CMA wrote: > > Sirs, > performing extensive tests on linux platform performance, optimized as > database server, I got IMHO confusing results: > in particular e2fs initialized to use 1024 block/fragment size showed > significant I/O gains over 4096 block/fragment size, while I expected the > opposite. I would appreciate some hints to understand this. > The test performed was a c-isam index rebuild for a large table (more than > 30 tuples, over 80 megs for data and 90 megs for indexes). > Disk configurations were just cloned (no fragmentation). > Optimal (for the specific purpose) hdparm and bdflush tuning were applied > and tests run in single user mode. > This behaviour was consistent through a broad range of kernel releases (up > to 2.2.17) and h/w configurations. > Please find attached info and test results for a reference platform. > BTW, similar tests running interbase 4.0 DB load showed > 4x performance > over a fully tuned Win NT 4 config (same platform) ;-) > Regards > > Dr. Eng. Mauro Tassinari > Rome, Italy > [EMAIL PROTECTED] > > dmesg > > Linux version 2.2.6 (root@zap) (gcc version 2.7.2.3) #20 Tue Apr 27 15:23:25 > CDT 1999 > Detected 736483166 Hz processor. > Console: colour VGA+ 80x25 > Calibrating delay loop... 734.00 BogoMIPS > Memory: 127708k/130944k available (1204k kernel code, 408k reserved, 1568k > data, 56k init) > VFS: Diskquotas version dquot_6.4.0 initialized > CPU: Intel 00/08 stepping 03 > Checking 386/387 coupling... OK, FPU using exception 16 error reporting. > Checking 'hlt' instruction... OK. > Checking for popad bug... OK. > POSIX conformance testing by UNIFIX > mtrr: v1.26 (19981001) Richard Gooch ([EMAIL PROTECTED]) > PCI: PCI BIOS revision 2.10 entry at 0xf08f0 > PCI: Using configuration type 1 > PCI: Probing PCI hardware > Linux NET4.0 for Linux 2.2 > Based upon Swansea University Computer Society NET3.039 > NET4: Unix domain sockets 1.0 for Linux NET4.0. > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > Initializing RT netlink socket > Starting kswapd v 1.5 > Detected PS/2 Mouse Port. > Serial driver version 4.27 with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ enabled > ttyS00 at 0x03f8 (irq = 4) is a 16550A > ttyS01 at 0x02f8 (irq = 3) is a 16550A > Real Time Clock Driver v1.09 > RAM disk driver initialized: 16 RAM disks of 4096K size > loop: registered device at major 7 > VP_IDE: IDE controller on PCI bus 00 dev 21 > VP_IDE: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:pio, hdd:DMA > hda: QUANTUM FIREBALLlct15 20, ATA DISK drive > hdd: ATAPI-CD ROM-DRIVE-50MAX, ATAPI CDROM drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: QUANTUM FIREBALLlct15 20, 19470MB w/418kB Cache, CHS=2482/255/63 > hdd: ATAPI 40X CD-ROM drive, 128kB Cache > Uniform CDROM driver Revision: 2.54 > Floppy drive(s): fd0 is 1.44M > FDC 0 is a post-1991 82077 > md driver 0.36.6 MAX_MD_DEV=4, MAX_REAL=8 > linear personality registered > raid0 personality registered > scsi : 0 hosts. > scsi : detected total. > Partition check: > hda: hda1 hda2 hda3 > VFS: Mounted root (ext2 filesystem) readonly. > Freeing unused kernel memory: 56k freed > Adding Swap: 136516k swap-space (priority -1) > parport0: PC-style at 0x378 [SPP,PS2,EPP] > lp0: using parport0 (polling). > CSLIP: code copyright 1989 Regents of the University of California > SLIP: version 0.8.4-NET3.019-NEWTTY-MODULAR (dynamic channels, max=256). > SLIP linefill/keepalive option. > PPP: version 2.3.3 (demand dialling) > PPP line discipline registered. > es1371: version v0.11 time 23:59:18 Apr 28 1999 > es1371: found adapter at io 0xa800 irq 5 > es1371: features: joystick 0x0 > es1371: codec vendor f?v revision 9 > es1371: codec features 18bit DAC 18bit ADC > es1371: stereo enhancement: unknown > rtl8139.c:v1.07 5/6/99
Why not PCMCIA built-in and yenta/i82365 as modules
The subject says it all. Is there any particular (technical) reason why I must have both the generic pcmcia code and the controller support built-in, or build all of them as modules? /Tobias - 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/
page 0 mapped memory in ELF binaries
Ok, I'm sure this isn't any sort of show stopper for the 2.4.0 series (or any other series for that matter, and they probably all have it), but when mapping memory to page 0 in the program header of an ELF, linux completely ignores the ph_memsz field.. I've attached a program to demonstrate.. nasm is needed for compilation... (nasm is available at http://www.cryogen.com/Nasm/) Just so you know, what I want to do is have x bytes at 0x0, when only y bytes are in the file, and y will almost always be less than x.. And yes, this is a little odd, but I really want to do it ;) -- Zinx Verituse(See headers for gpg/pgp key info) BITS 32 ;; Compile with: nasm -f bin zeromap.asm -o zeromap ;; ;; Set this to size you want mapped, and that much will get mapped. This is ;; the ph_filesz field, the ph_memsz is already at 4096*2, but Linux seems to ;; completely ignore that when it's mapping to 0x0 %define ZERO_MAPPED_FILE_SIZE 0 ;; You'll want to set this if you set the above, else you'll get bus errors, ;; due to the file not actually being as big as you told the kernel it was. ;; Note that I don't want a bigger file, just a bigger amount of memory. %define PADDING 0 ;; Define this if you want it to just loop over and over, so you can, ;; say, type "cat /proc/`pidof zeromap`/maps" and get a picture of ;; what all is happening ;) %define INFINITE_LOOP 0 ;; ;; Elf Header ORG 0x8048000 elf_header: .e_ident: db 0x7f, "ELF" .e_ident_class: db 1 ;ELFCLASS32 .e_ident_encoding: db 1 ;ELFDATA2LSB .e_ident_version: db 1 ;EV_CURRENT .e_ident_padding: db 0, 0, 0, 0, 0, 0, 0, 0, 0 .e_type:dw 2 ;ET_EXEC .e_machine: dw 3 ;EM_386 .e_version: dd 1 ;EV_CURRENT .e_entry: dd main .e_phoff: dd PROGRAM_HEADER .e_shoff: dd 0 .e_flags: dd 0 .e_ehsize: dw elf_header_size .e_phentsize: dw 32 .e_phnum: dw 3 .e_shentsize: dw 0 .e_shnum: dw 0 .e_shstrndx:dw 0 elf_header_size equ $ - elf_header ;; Program Header PROGRAM_HEADER equ $-$$ program_header_1: .p_type:dd 1 ;PT_LOAD .p_offset: dd main - $$ .p_vaddr: dd main .p_paddr: dd 0 .p_filesz: dd main_size .p_memsz: dd main_size .p_flags: dd 1+2+4 ;PF_X + PF_R + PF_W .p_align: dd 4 ; Linux 2.4.0-test10 (at least) doesn't like this one at all. program_header_2: .p_type:dd 1 ;PT_LOAD .p_offset: dd nomem - $$ .p_vaddr: dd 0 .p_paddr: dd 0 .p_filesz: dd ZERO_MAPPED_FILE_SIZE .p_memsz: dd 4096*2 ;PAGE_SIZE*2 .p_flags: dd 2+4 ;PF_W + PF_R .p_align: dd 4 ; Yet, this one is fine... it's the exact same stuff, just mapped somewhere ; other than 0x0 program_header_3: .p_type:dd 1 ;PT_LOAD .p_offset: dd nomem - $$ .p_vaddr: dd nomem .p_paddr: dd 0 .p_filesz: dd 0 .p_memsz: dd 4096*2 ;PAGE_SIZE*2 .p_flags: dd 2+4 ;PF_W + PF_R .p_align: dd 4 main: %if INFINITE_LOOP jmp $ %endif mov ebp, nomem call try_access mov ebp, 0x0 call try_access mov eax, 1 ; __NR_exit xor ebx, ebx int 0x80; exit(0); try_access: call write_ebp_msg xor eax, eax .loop: mov ecx, dword [ebp+eax*4] inc eax cmp eax, 0x2000 jg .loop ret write_ebp_msg: mov eax, ebp mov ebx, 16 mov ecx, 8 .loop: xor edx, edx div ebx mov dl, [hex+edx] mov [msg_try_mapped.addr+ecx-1], dl loop .loop mov eax, 4 ; __NR_write mov ebx, 2 mov ecx, msg_try_mapped mov edx, msg_try_mapped.len int 0x80; write(2, msg_try_mapped, strlen(msg_try_mapped)); ret ; NOT REACHED msg_try_mapped: db "Accessing 4096*2 bytes of mapped(?) memory at 0x"
Re: ext2 compression: How about using the Netware principle?
Roy Sigurd Karlsbakk wrote: > > Hi > > With some years of practice with Novell NetWare, I've been wandering why > the (unused?) file system compression mechanism in ext2 is based on > doing realtime compression. To make compression efficient, it can't be > made this simple. Let's look at the type of volume (file system) > compression introduced with Novell NetWare 4.0 around '94: > > - A file is saved to disk > - If the file isn't touched (read or written to) within days > (default 14), the file is compressed. > - If the file isn't compressed more than percent (default 20), the > file is flagged "can't compress". > - All file compression is done on low traffic times (default between > 00:00 and 06:00 hours) > - The first time a file is read or written to within the days > interval mentioned above, the file is addressed using realtime > compression. The second time, the file is decompressed and commited to > disk (uncompressed). > > Results: > A minimum of CPU time is wasted compressing/decompressing files. > The average server I've been out working with have an effective > compression of somewhere between 30 and 100 per cent. > > PS: This functionality was even scheduled for Win2k, but was somewhere > lost... I don't know where... > > Questions: > I'm really not a kernel hacker, but really... > - The daily (or nightly) compression job can run as a cron job. This can > be a normal user process running as root. Am I right? > - The decompress-and-perhaps-commit-decompressed-to-disk process should > be done by a kernel process within (or beside) the file system. > - The M$ folks will get even more problems braging about a less useful > product. > > Please CC: to me, as I'm not on the list > > Regards > > Roy Sigurd Karlsbakk > Well, filesystem compresion is in NT since 4.0, in fact you can compress a file, a directory, or the whole partition, but only under NTFS. I believe that it's [un]compressed on the fly, but I'm not sure about this fact. The [un]compression mechanism could be a kernel thread calling a userspace program (gzip, bzip2, definable) doing the actual decompresion. Don't know, just thoughts. -- Jorge Nerin <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Riley wrote: > Jeff Epler wrote: > > > > On Tue, Nov 21, 2000 at 04:08:26PM -0500, David Riley wrote: > > > Windoze is not the only OS to handle bad hardware better than Linux. On > > > my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept > > > causing random bus-type errors in Linux. Same as when I accidentally > > > (long story) overclocked the bus on the CPU. I think that more > > > tolerance for faulty hardware (more than just poorly programmed BIOS or > > > chipsets with known bugs) is something that might be worth looking into. > > > > And how do you propose to do that? > > > > For instance, in some other operating systems having the top bit flip > > in a pointer will cause silent use of incorrect data. On Linux, this > > will cause a signal 11. Which do you prefer, bad results or an error > > message? > > > > Can you suggest a specific way in which Linux can react correctly to > > e.g. flipped bits in RAM or cache which cannot be detected at the hardware > > level? Or maybe tell me how Linux can react correctly when an overclocked > > CPU starts producing incorrect results for right shifts once every few > > thousand instructions? > > Hmm... Good point. That would be hard to do. On that note, there > should be some prominent note on things like user manuals (though Linux > users shouldn't need *manuals* :-) that notes that common crashes like > signal 11 or "cc: internal failure" messages are generally caused by > hardware problems. Well David, there is such a "manual". http://ftp.sunet.se/LDP/FAQ/faqs/GCC-SIG11-FAQ /Richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6Gve8USLExYo23RsRAtrQAJ4glySTwLB+e02mlYX0L42pf3+8BACdEssx L2fhmp7uY+xa3wpWYt6cb+M= =aP6d -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
Jeff Epler wrote: > > On Tue, Nov 21, 2000 at 04:08:26PM -0500, David Riley wrote: > > Windoze is not the only OS to handle bad hardware better than Linux. On > > my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept > > causing random bus-type errors in Linux. Same as when I accidentally > > (long story) overclocked the bus on the CPU. I think that more > > tolerance for faulty hardware (more than just poorly programmed BIOS or > > chipsets with known bugs) is something that might be worth looking into. > > And how do you propose to do that? > > For instance, in some other operating systems having the top bit flip > in a pointer will cause silent use of incorrect data. On Linux, this > will cause a signal 11. Which do you prefer, bad results or an error > message? > > Can you suggest a specific way in which Linux can react correctly to > e.g. flipped bits in RAM or cache which cannot be detected at the hardware > level? Or maybe tell me how Linux can react correctly when an overclocked > CPU starts producing incorrect results for right shifts once every few > thousand instructions? Hmm... Good point. That would be hard to do. On that note, there should be some prominent note on things like user manuals (though Linux users shouldn't need *manuals* :-) that notes that common crashes like signal 11 or "cc: internal failure" messages are generally caused by hardware problems. That sort of thing would keep spurious complaints and error messages from inappropriate boards like this and on newbie boards where they belong (I'm not saying it was a bad complaint, but generally questions like "Why does RH 6.2, known to be stable on thousands of machines, not install of this machine where NT worked before?" belong on newbie boards and not as a flame of RedHat on the kernel board). Unfortunately, most people who get these error messages don't read the manuals. Besides, where would you put it in a manual? I know that error codes are a great mystery among us on the MacOS (even those of us that have been using it for 16 years only know that Error 11 is usually hardware and [1|2|3] are software) since they aren't really clearly and understandably documented in prominent user-land documentation. By the way, I have no idea how to implement a suggestion like I had. That's why I posted here. If I had a clue how to do that any better than a useless, inefficient kludge, I would have done it myself and submitted a patch. As much as I like the "do it yourself" model of development here, I think a lot of people might appreciate it if more experienced coders wouldn't jump down the throats of people who suggest a feature they can't do themselves yet. I speak for myself, but I don't think I'll find a dearth of support for that opinion. Thanks, David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] Fix AMD PCNet32 printk's
Hi!
Someone overzealously added too many KERN_INFOs to pcnet32, so that they
appear not only at the beginning of each line, but also many times in
between words. This is wrong.
This patch removes the extraneous KERN_* from pcnet32. It leaves all
those that should be there in place. It does not change anything else.
It's against 2.4.0-test11.
--
Vojtech Pavlik
SuSE Labs
diff -urN linux-2.4.0-test11/drivers/net/pcnet32.c linux/drivers/net/pcnet32.c
--- linux-2.4.0-test11/drivers/net/pcnet32.cTue Nov 21 23:04:24 2000
+++ linux/drivers/net/pcnet32.c Tue Nov 21 20:56:57 2000
@@ -483,7 +483,7 @@
printk(KERN_INFO "pcnet32_probe_pci: found device %#08x.%#08x\n", ent->vendor,
ent->device);
ioaddr = pci_resource_start (pdev, 0);
-printk(KERN_INFO " ioaddr=%#08lx resource_flags=%#08lx\n", ioaddr,
pci_resource_flags (pdev, 0));
+printk(KERN_INFO "ioaddr=%#08lx resource_flags=%#08lx\n", ioaddr,
+pci_resource_flags (pdev, 0));
if (!ioaddr) {
printk (KERN_ERR "no PCI IO resources, aborting\n");
return -ENODEV;
@@ -627,29 +627,29 @@
/* There is a 16 byte station address PROM at the base address.
The first six bytes are the station address. */
for (i = 0; i < 6; i++)
- printk( KERN_INFO " %2.2x", dev->dev_addr[i] = inb(ioaddr + i));
+ printk(" %2.2x", dev->dev_addr[i] = inb(ioaddr + i));
if (((chip_version + 1) & 0xfffe) == 0x2624) { /* Version 0x2623 or 0x2624 */
i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */
- printk(KERN_INFO"\ntx_start_pt(0x%04x):",i);
+ printk("\n" KERN_INFO "tx_start_pt(0x%04x):",i);
switch(i>>10) {
- case 0: printk(KERN_INFO " 20 bytes,"); break;
- case 1: printk(KERN_INFO " 64 bytes,"); break;
- case 2: printk(KERN_INFO " 128 bytes,"); break;
- case 3: printk(KERN_INFO "~220 bytes,"); break;
+ case 0: printk(" 20 bytes,"); break;
+ case 1: printk(" 64 bytes,"); break;
+ case 2: printk(" 128 bytes,"); break;
+ case 3: printk("~220 bytes,"); break;
}
i = a->read_bcr(ioaddr, 18); /* Check Burst/Bus control */
- printk(KERN_INFO" BCR18(%x):",i&0x);
- if (i & (1<<5)) printk(KERN_INFO "BurstWrEn ");
- if (i & (1<<6)) printk(KERN_INFO "BurstRdEn ");
- if (i & (1<<7)) printk(KERN_INFO "DWordIO ");
- if (i & (1<<11)) printk(KERN_INFO"NoUFlow ");
+ printk(" BCR18(%x):",i&0x);
+ if (i & (1<<5)) printk("BurstWrEn ");
+ if (i & (1<<6)) printk("BurstRdEn ");
+ if (i & (1<<7)) printk("DWordIO ");
+ if (i & (1<<11)) printk("NoUFlow ");
i = a->read_bcr(ioaddr, 25);
- printk(KERN_INFO "\nSRAMSIZE=0x%04x,",i<<8);
+ printk("\n" KERN_INFO "SRAMSIZE=0x%04x,",i<<8);
i = a->read_bcr(ioaddr, 26);
- printk(KERN_INFO " SRAM_BND=0x%04x,",i<<8);
+ printk(" SRAM_BND=0x%04x,",i<<8);
i = a->read_bcr(ioaddr, 27);
- if (i & (1<<14)) printk(KERN_INFO "LowLatRx,");
+ if (i & (1<<14)) printk("LowLatRx");
}
dev->base_addr = ioaddr;
@@ -662,7 +662,7 @@
memset(lp, 0, sizeof(*lp));
lp->dma_addr = lp_dma_addr;
lp->pci_dev = pdev;
-printk(KERN_INFO "pcnet32: pcnet32_private lp=%p lp_dma_addr=%#08x\n", lp,
lp_dma_addr);
+printk("\n" KERN_INFO "pcnet32: pcnet32_private lp=%p lp_dma_addr=%#08x", lp,
+lp_dma_addr);
spin_lock_init(>lock);
@@ -713,7 +713,7 @@
}
if (dev->irq >= 2)
- printk(KERN_INFO " assigned IRQ %d.\n", dev->irq);
+ printk(" assigned IRQ %d.\n", dev->irq);
else {
unsigned long irq_mask = probe_irq_on();
@@ -728,9 +728,9 @@
dev->irq = probe_irq_off (irq_mask);
if (dev->irq)
- printk(KERN_INFO ", probed IRQ %d.\n", dev->irq);
+ printk(", probed IRQ %d.\n", dev->irq);
else {
- printk(KERN_ERR ", failed to detect IRQ line.\n");
+ printk(", failed to detect IRQ line.\n");
return -ENODEV;
}
}
@@ -978,14 +978,14 @@
lp->dirty_tx, lp->cur_tx, lp->tx_full ? " (full)" : "",
lp->cur_rx);
for (i = 0 ; i < RX_RING_SIZE; i++)
- printk(KERN_DEBUG "%s %08x %04x %08x %04x", i & 1 ? "" : "\n ",
+ printk("%s %08x %04x %08x %04x", i & 1 ? "" : "\n ",
lp->rx_ring[i].base, -lp->rx_ring[i].buf_length,
lp->rx_ring[i].msg_length, (unsigned)lp->rx_ring[i].status);
for (i = 0 ; i < TX_RING_SIZE; i++)
- printk(KERN_DEBUG "%s %08x %04x %08x %04x", i & 1 ? "" : "\n ",
+ printk("%s %08x %04x %08x %04x", i & 1 ? "" : "\n ",
lp->tx_ring[i].base, -lp->tx_ring[i].length,
lp->tx_ring[i].misc, (unsigned)lp->tx_ring[i].status);
- printk(KERN_DEBUG "\n");
+ printk("\n");
}
Re: Defective Red Hat Distribution poorly represents Linux
> > This is true. What I suppose would be the solution is that if faulty > > hardware is found, a reduction in performance should be made. > > Finding out if you've got bad RAM might take a few hours running mem86. Not > exactly what I have in mind to do each boot... Even if memtest doesn't find anything you can't be sure the box is fine. I've seen boxed which passed memtest just fine, but compiling kernels in a endless loop with "make -j" still bombed after some time with gcc sig11. Gerd -- Wirtschaftsinformatiker == Leute, die zwar die aktuellen Aktienkurse jedes Softwareherstellers kennen, aber keines der Produkte auch nur ansatzweise bedienen können.-- Benedict Mangelsdorff - 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/
53c400 driver
Hi, Support for some 53c400 cards is still bad (the non-PnP), so I'll start fixing this. I'll be my fist kernel job, so please spare me :)) Issues : 53c400a non-PNP still lock this system hard. It starts barking about a busy SCSI bus, and then I can fsck again. To Alan : How hard is it to get thing beast (53c400 and family) to be SMP safe ?? Or is it better to start over again ? Regards, Igmar - 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: 3c59x: Using bad IRQ 0
On Tue, 21 Nov 2000, Jeff Garzik wrote: > Tobias Ringstrom wrote: > > When saying yes to "Plug-and-play OS" in the BIOS, my 3Com 905C adapter > > stops working, since the driver tries to use IRQ 0, since the BIOS does > > not assign an IRQ to it. The driver seems to read the IRQ from the card > > before it calls pci_enable_device (and pci_set_master). > > > eth0: 3Com PCI 3c905C Tornado at 0xa400, PCI: Enabling device 00:0a.0 (0014 -> >0017) > > PCI: Assigned IRQ 9 for device 00:0a.0 > > 00:01:02:b4:18:e4, IRQ 0 > > Tobias, can you confirm that calling pci_enable_device before reading > dev->irq fixes the 3c59x.c problem for you? Nope. The interrupts do not seem to get through. Packets are transmitted, but that's it. I've copied the interesting parts from dmesg: PCI: PCI BIOS revision 2.10 entry at 0xf10f0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: Found IRQ 10 for device 00:0b.0 PCI: The same IRQ used for device 00:11.0 [...] 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ See Documentation/networking/vortex.txt PCI: Enabling device 00:0a.0 (0014 -> 0017) PCI: Assigned IRQ 9 for device 00:0a.0 eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:01:02:b4:18:e4, IRQ 9 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. [...] eth0: using NWAY autonegotiation NETDEV WATCHDOG: eth0: transmit timed out eth0: transmit timed out, tx_status 00 status e601. eth0: Interrupt posted but not delivered -- IRQ blocked by another device? Flags; bus-master 1, full 0; dirty 16(0) current 16(0). Transmit list vs. cff10200. 0: @cff10200 length 802a status 0001002a 1: @cff10210 length 802a status 0001002a 2: @cff10220 length 802a status 0001002a 3: @cff10230 length 802a status 0001002a 4: @cff10240 length 802a status 0001002a 5: @cff10250 length 802a status 0001002a 6: @cff10260 length 802a status 0001002a 7: @cff10270 length 802a status 0001002a 8: @cff10280 length 802a status 0001002a 9: @cff10290 length 802a status 0001002a 10: @cff102a0 length 802a status 0001002a 11: @cff102b0 length 802a status 0001002a 12: @cff102c0 length 802a status 0001002a 13: @cff102d0 length 802a status 0001002a 14: @cff102e0 length 802a status 8001002a 15: @cff102f0 length 802a status 8001002a eth0: Resetting the Tx ring pointer. I'm attaching lspci -vvv for the pnp and non-pnp cases. A diff between them reveals only two differences. Th first is the IRQ of the 3Com (7 or 9), and the other one is that the game port of the SBLive card is disabled (which should be irreleant). /Tobias 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 08) Subsystem: Creative Labs CT4832 SBLive! Value Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K]
Re: Defective Red Hat Distribution poorly represents Linux
On Tue, 21 Nov 2000, Horst von Brand wrote: > David Riley <[EMAIL PROTECTED]> said: > > This is true. What I suppose would be the solution is that if faulty > > hardware is found, a reduction in performance should be made. > Finding out if you've got bad RAM might take a few hours running mem86. Not > exactly what I have in mind to do each boot... ecc ram and ecc-capable northbridge isn't exactly expensive... -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test11] show_mem() to dump free pages
Hi Linus,
In arch/i386/mm/init.c:show_mem() we calculate the number of free pages
but don't printk it out. Therefore, we must either a) remove the variable
and the calculation or b) make use of it. I think b) is obviously better.
The patch below was tested under 2.4.0-test11.
Regards,
Tigran
--- arch/i386/mm/init.c.0 Tue Nov 21 22:00:52 2000
+++ arch/i386/mm/init.c Tue Nov 21 22:00:36 2000
@@ -221,6 +221,7 @@
}
printk("%d pages of RAM\n", total);
printk("%d pages of HIGHMEM\n",highmem);
+ printk("%d free pages\n",free);
printk("%d reserved pages\n",reserved);
printk("%d pages shared\n",shared);
printk("%d pages swap cached\n",cached);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
David Riley <[EMAIL PROTECTED]> said: [...] > This is true. What I suppose would be the solution is that if faulty > hardware is found, a reduction in performance should be made. Finding out if you've got bad RAM might take a few hours running mem86. Not exactly what I have in mind to do each boot... -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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: [uPATCH] fix IDE/ServerWorks OSB4 config option (test11)
Bartlomiej Zolnierkiewicz wrote: > --- linux-240t11/drivers/ide/Config.in Wed Nov 15 22:02:11 2000 > +++ linux/drivers/ide/Config.in Tue Nov 21 14:52:07 2000 > @@ -68,7 +68,7 @@ > dep_bool 'OPTi 82C621 chipset enhanced support (EXPERIMENTAL)' >CONFIG_BLK_DEV_OPTI621 $CONFIG_EXPERIMENTAL > dep_bool 'PROMISE PDC20246/PDC20262/PDC20267 support' >CONFIG_BLK_DEV_PDC202XX $CONFIG_BLK_DEV_IDEDMA_PCI > dep_bool ' Special UDMA Feature' CONFIG_PDC202XX_BURST >$CONFIG_BLK_DEV_PDC202XX > - dep_bool 'ServerWorks OSB4 chipset support' CONFIG_BLK_DEV_OSB4 >$CONFIG_BLK_DEV_OSB4 > + dep_bool 'ServerWorks OSB4 chipset support' CONFIG_BLK_DEV_OSB4 >$CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 > dep_bool 'SiS5513 chipset support' CONFIG_BLK_DEV_SIS5513 >$CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 > dep_bool 'SLC90E66 chipset support' CONFIG_BLK_DEV_SLC90E66 >$CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 Just wondering, why do these depend on CONFIG_X86? I just glanced at osb4.c and it looks pretty well-written and portable to me... Nothing X86 specific about it. Ditto some of the others depending on CONFIG_X86. IMHO even if the southbridge is currently only known to be used on x86's, that doesn't mean that the hardware, or the driver, will always be limited to the X86 platform. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
David Riley <[EMAIL PROTECTED]> said: > Horst von Brand wrote: > > So what? My former machine ran fine with Win95/WinNT. Linux wouldn't even > > end booting the kernel. Reason: P/100 was running at 120Mhz. Fixed that, no > > trouble for years. Not the only case of WinXX running (apparently?) fine > > on broken/misconfigured hardware I've seen, mind you. > This is something I've noticed as well... > > Windoze is not the only OS to handle bad hardware better than Linux. On > my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept > causing random bus-type errors in Linux. Same as when I accidentally > (long story) overclocked the bus on the CPU. I think that more > tolerance for faulty hardware (more than just poorly programmed BIOS or > chipsets with known bugs) is something that might be worth looking into. NO! The method they use is not to drive the hardware too hard (i.e., you don't get what you paid for, performance-wise), or just paper over the bug (it _will_ crash soon enough anyway, so why bother?). -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] some cleanup in vgacon.c
Hi James
this is a newer cleaning patch for vgacon.c against test11.
It includes the one I sent a couple of days ago.Could you check this too
and if OK send it to Linus?Unless of course it violates the code-freeze
policy :-)
Thanks,
Jani.
It does the following
1)Removes explicit static initialisation
2)Removes a duplicated code line in vgacon_scroll
3)Removes the static variable vga_hardscroll_user_enable which I guess was
superfluous since it was only indirectly used by vga_hardscroll_enabled.
The no-scroll option still works for me :-)
4)Removed 3 #includes: fs.h ,sched.h and malloc.h seem never to be used,
and besides fs.h is very large :-).I think string.h isn't needed either
but maybe on non x86 ?
It compiles and works without them and I hope no other architecture uses
these headers in vgacon.It would be awkward
--- /usr/src/patches/original/vgacon/vgacon.c Tue Nov 21 22:52:04 2000
+++ vgacon.cTue Nov 21 23:34:33 2000
@@ -35,15 +35,12 @@
#include
#include
-#include
-#include
#include
#include
#include
#include
#include
#include
-#include
#include
#include
#include
@@ -104,17 +101,17 @@
static u16 vga_video_port_val; /* Video register value port */
static unsigned intvga_video_num_columns; /* Number of text columns */
static unsigned intvga_video_num_lines;/* Number of text lines */
-static intvga_can_do_color = 0;/* Do we support colors? */
+static intvga_can_do_color;/* Do we support colors? */
static unsigned intvga_default_font_height;/* Height of default screen
font */
static unsigned char vga_video_type; /* Card type */
-static unsigned char vga_hardscroll_enabled;
+
#ifdef CONFIG_IA64_SOFTSDV_HACKS
/*
* SoftSDV doesn't have hardware assist VGA scrolling
*/
-static unsigned char vga_hardscroll_user_enable = 0;
+static unsigned char vga_hardscroll_enabled;
#else
-static unsigned char vga_hardscroll_user_enable = 1;
+static unsigned char vga_hardscroll_enabled = 1;
#endif
static unsigned char vga_font_is_default = 1;
static intvga_vesa_blanked;
@@ -122,7 +119,7 @@
static intvga_is_gfx;
static intvga_512_chars;
static intvga_video_font_height;
-static unsigned intvga_rolled_over = 0;
+static unsigned intvga_rolled_over;
static int __init no_scroll(char *str)
@@ -132,7 +129,7 @@
* Braille reader made by F.H. Papenmeier (Germany).
* Use the "no-scroll" bootflag.
*/
- vga_hardscroll_user_enable = vga_hardscroll_enabled = 0;
+ vga_hardscroll_enabled = 0;
return 1;
}
@@ -316,7 +313,6 @@
if (vga_video_type == VIDEO_TYPE_EGAC
|| vga_video_type == VIDEO_TYPE_VGAC
|| vga_video_type == VIDEO_TYPE_EGAM) {
- vga_hardscroll_enabled = vga_hardscroll_user_enable;
vga_default_font_height = ORIG_VIDEO_POINTS;
vga_video_font_height = ORIG_VIDEO_POINTS;
/* This may be suboptimal but is a safe bet - go with it */
@@ -965,7 +961,7 @@
static void vgacon_save_screen(struct vc_data *c)
{
- static int vga_bootup_console = 0;
+ static int vga_bootup_console;
if (!vga_bootup_console) {
/* This is a gross hack, but here is the only place we can
@@ -1015,7 +1011,6 @@
vga_rolled_over = 0;
} else
c->vc_origin -= delta;
- c->vc_scr_end = c->vc_origin + c->vc_screenbuf_size;
scr_memsetw((u16 *)(c->vc_origin), c->vc_video_erase_char, delta);
}
c->vc_scr_end = c->vc_origin + c->vc_screenbuf_size;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
On Tue, Nov 21, 2000 at 04:08:26PM -0500, David Riley wrote: > Windoze is not the only OS to handle bad hardware better than Linux. On > my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept > causing random bus-type errors in Linux. Same as when I accidentally > (long story) overclocked the bus on the CPU. I think that more > tolerance for faulty hardware (more than just poorly programmed BIOS or > chipsets with known bugs) is something that might be worth looking into. And how do you propose to do that? For instance, in some other operating systems having the top bit flip in a pointer will cause silent use of incorrect data. On Linux, this will cause a signal 11. Which do you prefer, bad results or an error message? Can you suggest a specific way in which Linux can react correctly to e.g. flipped bits in RAM or cache which cannot be detected at the hardware level? Or maybe tell me how Linux can react correctly when an overclocked CPU starts producing incorrect results for right shifts once every few thousand instructions? There exists hardware specifically intended to be able to diagnose and contain its own failures, but the number of such features on a common home PC is probably a big fat zero. > I'm sure it would solve problems like this (which I clearly identify as > a hardware problem, because the same thing happened with the bad DIMM, > the overclocked bus, and two different overclocked processors (AMD 5x86 > and AMD K6-2 500) and went away when I remedied the offending problem). And that's what you have to do --- fix the problem. In a few situations, you might be able to isolate and exclude the section of RAM which is bad (in fact, there are patches for this and tools to diagnose the problem), but what do you want Linux to do about a processor which cannot reliably execute instructions? > Additionally, overclockers (I myself am a reformed one) might appreciate > more tolerance for such things. I've got a better idea: Overclockers can go to hell, and their bug reports to the trash, until they "reform" like you and I have. Jeff - 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: Better testing of hardware (was: Defective Read Hat)
On Tue, 21 Nov 2000, Stephen Gutknecht (linux-kernel) wrote: > What a Linux kernel compile DOESN'T test is the network interfaces and video > cards. Kernel compile over NFS while playing unreal tournament in X ;) -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
On Tue, 21 Nov 2000, David Riley wrote: > Horst von Brand wrote: > > Windoze is not the only OS to handle bad hardware better than Linux. On > my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept > causing random bus-type errors in Linux. Same as when I accidentally I believe Linux uses memory from the top down rather than from the bottom up like MS which may explain some of the reports that "it werks great in windoze" where the faulty bit is high in the map. Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
On Tue, 21 Nov 2000, David Riley wrote: > Horst von Brand wrote: > > > > So what? My former machine ran fine with Win95/WinNT. Linux wouldn't even > > end booting the kernel. Reason: P/100 was running at 120Mhz. Fixed that, no > > trouble for years. Not the only case of WinXX running (apparently?) fine > > on broken/misconfigured hardware I've seen, mind you. > > This is something I've noticed as well... > > Windoze is not the only OS to handle bad hardware better than Linux. On > my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept > causing random bus-type errors in Linux. Same as when I accidentally > (long story) overclocked the bus on the CPU. I think that more > tolerance for faulty hardware (more than just poorly programmed BIOS or > chipsets with known bugs) is something that might be worth looking into. > I'm sure it would solve problems like this (which I clearly identify as > a hardware problem, because the same thing happened with the bad DIMM, > the overclocked bus, and two different overclocked processors (AMD 5x86 > and AMD K6-2 500) and went away when I remedied the offending problem). > Additionally, overclockers (I myself am a reformed one) might appreciate > more tolerance for such things. Hmmm... The more an O/S wait stupidly for something when it could do useful work, the less it is likely to trigger hardware problems. Windoze is probably still far better that Linux at handling billions dollars. I never noticed it was good at anything else. :-) > My two cents/pence/centavos/local tiny currency denomination, > David Gérard. - 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/
Better testing of hardware (was: Defective Read Hat)
Part of the issue is that there exists no "easy to use" standardized test software. Full 32-bit concurrent use of many devices can reveal problems that users do not often see in normal applications. One major hardware review site found stability problems with the Intel Pentium 3 1130Mhz processor that ultimately lead to Intel delaying the release -- it passed all tests but not a compile of the Linux Kernel! This was on more than 3 different processors. http://www.tomshardware.com/cpu/00q3/0008281/pentiumiii-04.html A Linux Kernel compile test does a really good job of testing the hard disk, RAM, and CPU... as it executes all types of instructions and the final output depends on all prior steps completing correctly. On a really fast system (> 900Mhz) might make sense to run it twice, once to "warm up" the CPU and other components. Most "benchmarks" just test speed, not the actual stability or data integrity (they write results to a device but don't check for data corruption, or they test only one device at a time, not all at once). What a Linux kernel compile DOESN'T test is the network interfaces and video cards. Yes, there are "stand alone" test programs -- but something that uses the actual OS interfaces and drivers (like a kernel compile) is the best way! I think the Linux Community could really jump over Microsoft who suffers from the same problem. Many OS-reported problems stem from hardware that is marginal (especially CPU, RAM, and PCI/AGP bus)... works at most level, but thrown in some heavy tasks... and odd software faults show up. A very simple but well designed test program run for 15 minutes would detect such problems. It is just foolish that Microsoft hasn't delivered this... as it has to cost them 100x more to deal with it as a support problem! You will find that most Overlockers run their favorite game in a loop for 10 or 20 minutes as the best test they have found. This often does Video+Ram+CPU+Sound board (PCI) at full tilt. What is needed is a _standardized test_ that really goes after everything (including network). What "system test" programs exist for Linux today? Any active projects? Just image a good "consumer distro" that has this as part of the setup! I come from an OS/2, WinNT, Win2K background... believe me, the problem has been here in the "PC platform" all along... and every OS vendor (and even application vendor) pays for this oversight. Linux really could take the lead! Before every kernel problem report, require "supertest" to be run for 10 minutes. Stephen Gutknecht -Original Message- From: David Lang [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 21, 2000 2:05 PM To: David Riley Cc: [EMAIL PROTECTED] Subject: Re: Defective Red Hat Distribution poorly represents Linux David, usually when it turns out that Linux finds hardware problems the underlying cause is that linux makes more effective use of the component, and as such something that was marginal under windows fails under linux as the correct timing is used. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
the problem is that unless you tecompile the kernel to add timing delays, you cannot change the timing like this (if you put the tests in all your fast paths to add delays you have just destroyed your performance in the case where the hardware is good) also you don't know the hardware is really working properly under windows, how do you know if the blue screen was caused by a windows bug or a hardware error. David Lang On Tue, 21 Nov 2000, David Riley wrote: > Date: Tue, 21 Nov 2000 16:34:08 -0500 > From: David Riley <[EMAIL PROTECTED]> > To: David Lang <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Defective Red Hat Distribution poorly represents Linux > > David Lang wrote: > > > > David, usually when it turns out that Linux finds hardware problems the > > underlying cause is that linux makes more effective use of the component, > > and as such something that was marginal under windows fails under linux as > > the correct timing is used. > > This is true. What I suppose would be the solution is that if faulty > hardware is found, a reduction in performance should be made. This is > already the case for things like broken PCI BIOS where one can either > set the initialization to work a different way or try to make the > machine autodetect it. I certainly approve of more effective use of any > given component, but sometimes I think it's better to offer the user a > choice in the case of faulty hardware. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0, test10, test11: HPT366 problem
In message <[EMAIL PROTECTED]>, "Mohammad A. Haque" writes: > I read somewhere that hpt366 bios 1.26 will fix the problem with this > particular drive. I'll try and dig up the reference. From the 1.26beta bios redame-file (at http://www.highpoint-tech.com) 1.26.0 08Aug00 . Fix compatibility problem with IBM DTLA ATA-100 har disk /Håkan --- e-mail: [EMAIL PROTECTED] | or [EMAIL PROTECTED] | --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
David Lang wrote: > > David, usually when it turns out that Linux finds hardware problems the > underlying cause is that linux makes more effective use of the component, > and as such something that was marginal under windows fails under linux as > the correct timing is used. This is true. What I suppose would be the solution is that if faulty hardware is found, a reduction in performance should be made. This is already the case for things like broken PCI BIOS where one can either set the initialization to work a different way or try to make the machine autodetect it. I certainly approve of more effective use of any given component, but sometimes I think it's better to offer the user a choice in the case of faulty hardware. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] removal of "static foo = 0" from drivers/ide (test11)
Hi
Quick removal of unnecessary initialization to 0.
--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>
diff -uNr linux-240t11/drivers/ide/ali14xx.c linux/drivers/ide/ali14xx.c
--- linux-240t11/drivers/ide/ali14xx.c Tue Jun 13 20:32:00 2000
+++ linux/drivers/ide/ali14xx.c Tue Nov 21 14:35:59 2000
@@ -81,9 +81,9 @@
{0x2d, 0x32, 0x2e, 0x33}, /* drive 3 */
};
-static int basePort = 0; /* base port address */
-static int regPort = 0;/* port for register number */
-static int dataPort = 0; /* port for register data */
+static int basePort; /* base port address */
+static int regPort;/* port for register number */
+static int dataPort; /* port for register data */
static byte regOn; /* output to base port to access registers */
static byte regOff;/* output to base port to close registers */
diff -uNr linux-240t11/drivers/ide/alim15x3.c linux/drivers/ide/alim15x3.c
--- linux-240t11/drivers/ide/alim15x3.c Wed Nov 15 22:02:55 2000
+++ linux/drivers/ide/alim15x3.cTue Nov 21 14:35:59 2000
@@ -233,8 +233,8 @@
}
#endif /* defined(DISPLAY_ALI_TIMINGS) && defined(CONFIG_PROC_FS) */
-static byte m5229_revision = 0;
-static byte chip_is_1543c_e= 0;
+static byte m5229_revision;
+static byte chip_is_1543c_e;
byte ali_proc = 0;
static struct pci_dev *isa_dev;
diff -uNr linux-240t11/drivers/ide/buddha.c linux/drivers/ide/buddha.c
--- linux-240t11/drivers/ide/buddha.c Wed Nov 15 22:02:11 2000
+++ linux/drivers/ide/buddha.c Tue Nov 21 14:35:59 2000
@@ -87,7 +87,7 @@
* Board information
*/
-static u_long buddha_board = 0;
+static u_long buddha_board;
static int buddha_num_hwifs = -1;
diff -uNr linux-240t11/drivers/ide/hpt366.c linux/drivers/ide/hpt366.c
--- linux-240t11/drivers/ide/hpt366.c Wed Nov 15 22:02:55 2000
+++ linux/drivers/ide/hpt366.c Tue Nov 21 14:36:27 2000
@@ -214,8 +214,8 @@
byte hpt366_proc = 0;
extern char *ide_xfer_verbose (byte xfer_rate);
-byte hpt363_shared_irq = 0;
-byte hpt363_shared_pin = 0;
+byte hpt363_shared_irq;
+byte hpt363_shared_pin;
static unsigned int pci_rev_check_hpt3xx (struct pci_dev *dev)
{
diff -uNr linux-240t11/drivers/ide/ide-pci.c linux/drivers/ide/ide-pci.c
--- linux-240t11/drivers/ide/ide-pci.c Wed Nov 15 22:02:55 2000
+++ linux/drivers/ide/ide-pci.c Tue Nov 21 14:35:59 2000
@@ -185,8 +185,8 @@
#define INIT_HPT366_init_hpt366
#define DMA_HPT366 _dmacapable_hpt366
#else
-static byte hpt363_shared_irq = 0;
-static byte hpt363_shared_pin = 0;
+static byte hpt363_shared_irq;
+static byte hpt363_shared_pin;
#define PCI_HPT366 NULL
#define ATA66_HPT366 NULL
#define INIT_HPT366NULL
diff -uNr linux-240t11/drivers/ide/osb4.c linux/drivers/ide/osb4.c
--- linux-240t11/drivers/ide/osb4.c Wed Nov 15 22:02:12 2000
+++ linux/drivers/ide/osb4.cTue Nov 21 14:35:59 2000
@@ -60,7 +60,7 @@
#include
#include
-static byte osb4_revision = 0;
+static byte osb4_revision;
static struct pci_dev *bmide_dev;
static int osb4_get_info(char *, char **, off_t, int, int);
-
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/
[uPATCH] fix IDE/ServerWorks OSB4 config option (test11)
Hi In drivers/Config.in CONFIG_BLK_DEV_OSB4 depends on itself... -- Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- linux-240t11/drivers/ide/Config.in Wed Nov 15 22:02:11 2000 +++ linux/drivers/ide/Config.in Tue Nov 21 14:52:07 2000 @@ -68,7 +68,7 @@ dep_bool 'OPTi 82C621 chipset enhanced support (EXPERIMENTAL)' CONFIG_BLK_DEV_OPTI621 $CONFIG_EXPERIMENTAL dep_bool 'PROMISE PDC20246/PDC20262/PDC20267 support' CONFIG_BLK_DEV_PDC202XX $CONFIG_BLK_DEV_IDEDMA_PCI dep_bool ' Special UDMA Feature' CONFIG_PDC202XX_BURST $CONFIG_BLK_DEV_PDC202XX - dep_bool 'ServerWorks OSB4 chipset support' CONFIG_BLK_DEV_OSB4 $CONFIG_BLK_DEV_OSB4 + dep_bool 'ServerWorks OSB4 chipset support' CONFIG_BLK_DEV_OSB4 +$CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 dep_bool 'SiS5513 chipset support' CONFIG_BLK_DEV_SIS5513 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 dep_bool 'SLC90E66 chipset support' CONFIG_BLK_DEV_SLC90E66 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 dep_bool 'Tekram TRM290 chipset support (EXPERIMENTAL)' CONFIG_BLK_DEV_TRM290 $CONFIG_BLK_DEV_IDEDMA_PCI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix help info about OSB4 and VIA82CXXX IDE chipsets (test11)
Hi - OSB4 isn't marked (EXPERIMENTAL) in drivers/ide/Config.in so it shouldn't be marked so in Configure.help. - PDC202XX driver also supports PDC20265. - new VIA82CXXX driver removed kernel command line option (FIFO setting) and CONFIG_VIA82CXX_TUNING -- Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- linux-240t11/drivers/ide/Configure.help Sun Nov 19 00:22:49 2000 +++ linux/drivers/ide/Configure.helpTue Nov 21 15:45:16 2000 @@ -868,9 +868,9 @@ This is a driver for the OPTi 82C621 EIDE controller. Please read the comments at the top of drivers/ide/opti621.c. -ServerWorks OSB4 chipset support (EXPERIMENTAL) +ServerWorks OSB4 chipset support CONFIG_BLK_DEV_OSB4 - This driver adds PIO/DMA support for the Serverworks OSB4 chipset + This driver adds PIO/(U)DMA support for the ServerWorks OSB4 chipset. Intel PIIXn chipsets support CONFIG_BLK_DEV_PIIX @@ -898,7 +898,7 @@ If unsure, say N. -PROMISE PDC20246/PDC20262/PDC20267 support +PROMISE PDC20246/PDC20262/PDC20265/PDC20267 support CONFIG_BLK_DEV_PDC202XX Promise Ultra33 or PDC20246 Promise Ultra66 or PDC20262 @@ -972,23 +972,15 @@ VIA82CXXX chipset support CONFIG_BLK_DEV_VIA82CXXX This allows you to to configure your chipset for a better use while - running (U)DMA: it will allow you to enable efficiently the second - channel dma usage, as it may not be set by BIOS. It allows you to - pass a kernel command line at boot time in order to set fifo - config. If no command line is provided, it will try to set fifo + running PIO/(U)DMA, it will allow you to enable efficiently the second + channel dma usage, as it may not be set by BIOS. It will try to set fifo configuration at its best. It will allow you to get information from - /proc/ide/via provided you enabled "proc" support. + /proc/ide/via provided you enabled "/proc file system" support. Please read the comments at the top of drivers/ide/via82cxxx.c If you say Y here, then say Y to "Use DMA by default when available" as well. - - If unsure, say N. - -VIA82CXXX Tuning support (WIP) -CONFIG_VIA82CXXX_TUNING - Please read the comments at the top of drivers/ide/via82cxxx.c If unsure, say N. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
David, usually when it turns out that Linux finds hardware problems the underlying cause is that linux makes more effective use of the component, and as such something that was marginal under windows fails under linux as the correct timing is used. David Lang On Tue, 21 Nov 2000, David Riley wrote: > Date: Tue, 21 Nov 2000 16:08:26 -0500 > From: David Riley <[EMAIL PROTECTED]> > To: unlisted-recipients: ; > Cc: [EMAIL PROTECTED] > Subject: Re: Defective Red Hat Distribution poorly represents Linux > > Horst von Brand wrote: > > > > So what? My former machine ran fine with Win95/WinNT. Linux wouldn't even > > end booting the kernel. Reason: P/100 was running at 120Mhz. Fixed that, no > > trouble for years. Not the only case of WinXX running (apparently?) fine > > on broken/misconfigured hardware I've seen, mind you. > > This is something I've noticed as well... > > Windoze is not the only OS to handle bad hardware better than Linux. On > my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept > causing random bus-type errors in Linux. Same as when I accidentally > (long story) overclocked the bus on the CPU. I think that more > tolerance for faulty hardware (more than just poorly programmed BIOS or > chipsets with known bugs) is something that might be worth looking into. > I'm sure it would solve problems like this (which I clearly identify as > a hardware problem, because the same thing happened with the bad DIMM, > the overclocked bus, and two different overclocked processors (AMD 5x86 > and AMD K6-2 500) and went away when I remedied the offending problem). > Additionally, overclockers (I myself am a reformed one) might appreciate > more tolerance for such things. > > My two cents/pence/centavos/local tiny currency denomination, > David > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.0-test11-ac1 compile error fix
Here is a patch to fix a compile error which I previously reported on
the 2.4.0test11-ac1 thread.
I tried to compile 2.4.0-test11-ac1, and here is where the compile bombed
out:
/usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686-c -o
sched.o sched.c
irq.c:182: conflicting types for `global_irq_lock'
/usr/src/linux/include/asm/hardirq.h:45: previous declaration of
`global_irq_lock'
make[1]: *** [irq.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.0-test11-ac1/arch/i386/kernel'
make: *** [_dir_arch/i386/kernel] Error 2
Evidently, global_irq_lock was changed to a long in several places in
the 2.4.0-test11-ac1 patch, but was left as an int in
linux/include/asm/hardirq.h.
I'm running 2.4.0-test11-ac1 with this patch now.
diff -u linux/include/asm/hardirq.h.orig linux/include/asm/hardirq.h
--- linux/include/asm/hardirq.h.origTue Nov 21 13:38:07 2000
+++ linux/include/asm/hardirq.h Tue Nov 21 13:40:13 2000
@@ -42,7 +42,7 @@
#include
extern unsigned char global_irq_holder;
-extern unsigned volatile int global_irq_lock;
+extern unsigned volatile long global_irq_lock; /* long for set_bit -RR */
static inline int irqs_running (void)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
Horst von Brand wrote: > > So what? My former machine ran fine with Win95/WinNT. Linux wouldn't even > end booting the kernel. Reason: P/100 was running at 120Mhz. Fixed that, no > trouble for years. Not the only case of WinXX running (apparently?) fine > on broken/misconfigured hardware I've seen, mind you. This is something I've noticed as well... Windoze is not the only OS to handle bad hardware better than Linux. On my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept causing random bus-type errors in Linux. Same as when I accidentally (long story) overclocked the bus on the CPU. I think that more tolerance for faulty hardware (more than just poorly programmed BIOS or chipsets with known bugs) is something that might be worth looking into. I'm sure it would solve problems like this (which I clearly identify as a hardware problem, because the same thing happened with the bad DIMM, the overclocked bus, and two different overclocked processors (AMD 5x86 and AMD K6-2 500) and went away when I remedied the offending problem). Additionally, overclockers (I myself am a reformed one) might appreciate more tolerance for such things. My two cents/pence/centavos/local tiny currency denomination, David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0, test10, test11: HPT366 problem
I read somewhere that hpt366 bios 1.26 will fix the problem with this particular drive. I'll try and dig up the reference. David Woodhouse wrote: > > WorksForMe(tm) > > Grrr. I specifically went and read the HPT366 blacklist before buying my > shiny new hard drive. > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0, test10, test11: HPT366 problem
On Tue, 21 Nov 2000, Andre Hedrick wrote:
>
> Does that fix it?
WorksForMe(tm)
Grrr. I specifically went and read the HPT366 blacklist before buying my
shiny new hard drive.
> On Tue, 21 Nov 2000, David Woodhouse wrote:
> > Index: drivers/ide/hpt366.c
> > ===
> > RCS file: /inst/cvs/linux/drivers/ide/Attic/hpt366.c,v
> > retrieving revision 1.1.2.10
> > diff -u -r1.1.2.10 hpt366.c
> > --- drivers/ide/hpt366.c2000/11/10 14:56:31 1.1.2.10
> > +++ drivers/ide/hpt366.c2000/11/21 13:27:32
> > @@ -55,6 +55,8 @@
> > };
> >
> > const char *bad_ata66_4[] = {
> > + "IBM-DTLA-307045",
> > + "IBM-DTLA-307030",
> > "WDC AC310200R",
> > NULL
> > };
--
dwmw2
-
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: beware of dead string constants
On Tue, 21 Nov 2000 13:13:27 Jakub Jelinek wrote:
> On Tue, Nov 21, 2000 at 06:02:35AM -0600, Peter Samuelson wrote:
> >
> > While trying to clean up some code recently (CONFIG_MCA, hi Jeff), I
> > discovered that gcc 2.95.2 (i386) does not remove dead string
> > constants:
> >
> > void foo (void)
> > {
> > if (0)
> > printk(KERN_INFO "bar");
> > }
> >
Is it related to opt level ? -O3 does auto-inlining and -O2 does not
(discovered that here, auto inlining in kernel trashes the cache...)
--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[EMAIL PROTECTED] #> more beer
Linux 2.2.18-pre22-vm #7 SMP Sun Nov 19 03:29:20 CET 2000 i686 unknown
-
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/
