Re: innd mmap bug in 2.4.0-test12 (UNIMPORTANT)
On Thu, 28 Dec 2000, Alan Cox wrote: > The ramfs maintainer has patches (in -ac) which deal with the size limiting > of RAMfs. I'm using it on a PDA and its really really nice to be able to > pop up a GUI app and drag the bar to '60% for apps' like other PDA systems ;) May I ask which PDA do you have running Linux and worth a few bucks? Pau - To unsubscribe from this list: send 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.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 03:47:12AM +0100, Andrea Arcangeli wrote: > PS. I'm very suprised thttpd isn't threaded, it should really be threaded at > least on the x86 family to run fast. This is one of the main thttpd design points: run in a select() loop. Since it is intended for mainly static workloads, it performs quite well... -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send 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: Oops when mounting cdrom
On Fri, 29 Dec 2000 01:55:51 +0100, "Udo A. Steinberg" <[EMAIL PROTECTED]> wrote: >Can someone explain to me what all those ksymoops warnings are >about? >Warning (compare_maps): ksyms_base symbol acpi_clear_event_R__ver_acpi_clear_event >not found in System.map. Ignoring ksyms_base entry Read the lkml FAQ, question 8.8. cliche_generate(man, fish, teach). - To unsubscribe from this list: send 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.2.19pre3 on sparc64: Hangs on boot, "no cont in shutdown!"??
"make check_asm" should fix it. Later, David S. Miller [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: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again
In article <[EMAIL PROTECTED]>, Mike Elmore <[EMAIL PROTECTED]> wrote: > >I really need to get rid of this 8139 card. Since >yall are the oracle, which nice 100mbs card is fine >hardware and is coupled with a well debugged driver? There are always problems with some hardware, but my personal recommendation for a card would definitely be the Intel Ethernet Pro 100 series (82557). Unlike the tulip cards (which are pretty good too), there aren't a million different versions of it. There's a few, but it's not a big mess. It performs well, and is stable. It's pretty well documented (apart from the magic extensions), and it's common. That said, some people have trouble even with that card. Nobody knows why, but at least the driver is actively maintained etc, so I still am not nervous about recommending it. I bet that others will have other recommendations, but so far I have at least personally had good luck with the eepro100. 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: test13-pre5
Simply executing
*p++ = htonl(fl->fl_pid);
before
start = loff_t_to_s64(fl->fl_start);
also works.
Later,
Albert
Linus Torvalds wrote:
>
> On Fri, 29 Dec 2000, Stefan Traby wrote:
> > On Thu, Dec 28, 2000 at 03:37:51PM -0800, Linus Torvalds wrote:
> >
> > > Too bad. Maybe somebody should tell gcc maintainers about programmers that
> > > know more than the compiler again.
> >
> > I know that {p,}gcc-2.95.2{,.1} are not officially supported.
>
> Hmm, I use gcc-2.95.2 myself on some machines, and while I'm not 100%
> comfortable with it, it does count as "supported" even if it has known
> problems with "long long". pgcc isn't.
>
> > Did you know that it's impossible to compile nfsv4 because of
> > register allocation problems with long long since (long long) month ?
>
> lockd v4 (for NFS v3), I assume.
>
> No, I wasn't aware of this particular bug.
>
> > The following does not hurt, it's just a fix for a broken
> > compiler:
>
> Ugh, that's ugly.
>
> Can you test if it is sufficient to just simplify the math a bit, instead
> of uglyfing that function more? The nlm4_encode_lock() function already
> tests for NLM4_OFFSET_MAX explicitly for both start and end, so it should
> be ok to just re-code the function to not do the extra "loff_t_to_s64()"
> stuff, and simplify it enough that the compile rwill be happy to compile
> the simpler function. Something along the lines of
>
> if (.. NLM4_OFFSET_MAX tests ..)
> ..
>
> *p++ = htonl(fl->fl_pid);
>
> start = fl->fl_start;
> len = fl->fl_end - start;
> if (fl->fl_end == OFFSET_MAX)
> len = 0;
>
> p = xdr_encode_hyper(p, start);
> p = xdr_encode_hyper(p, len);
>
> return p;
>
> Where it tries to minimize the liveness of the 64-bit values, and tries to
> avoid extra complications.
>
> 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/
--
Albert Cranford Deerfield Beach FL USA
[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: linux 2.4.0-test12 compile error
My fault. The ia64 patch was the problem. - Original Message - From: Matthew D. Pitts To: [EMAIL PROTECTED] Sent: Thursday, December 28, 2000 4:39 PM Subject: linux 2.4.0-test12 compile error Forgive me if this question has already been answered. I am unable to compile 2.4.0-test12 on my system. Linux-Mandrake 7.1 gcc-2.95.3 (might be a gcc snapshot) binutils-2.10.0.33 (freshly compiled today) modutils-2.3.23 (compiled yesterday) the following is the message I get gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -g -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586 -c -o init/main.o init/main.c In file included from /usr/src/linux/include/linux/pagemap.h:16, from /usr/src/linux/include/linux/locks.h:8, from /usr/src/linux/include/linux/raid/md.h:36, from init/main.c:24: /usr/src/linux/include/linux/highmem.h:48: macro `clear_user_page' used with too many (3) args /usr/src/linux/include/linux/highmem.h:90: macro `copy_user_page' used with too many (4) args make: *** [init/main.o] Error 1 the kernel I am trying to compile is linux-2.4.0-test12 with linux-2.4.0-test12-ia64-001214 and linux-2.4.0-test12-reiserfs-3.6.23 patches applied. Is there something else I need? Matthew D. Pitts [EMAIL PROTECTED]
Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again
All, You are some damn smart people. Whatever evil was happening is fixed in test13-pre5. I pounded it with 3 successive full backups of my multigig nfs mounted home directory to my Onstream drive while downloading a kernel and doing multiple >100M file copies over nfs at the same time while playing an mp3 off a nfs mounted partition. It was moving slow cause the card is 10mbs, but all jobs finished and the machine is now sitting idle as happy as can be. Any idea what portion of pre4 got fixed in pre5 to fix this problem? I'd just like to know so I can look around if it comes back. Sorta related: I really need to get rid of this 8139 card. Since yall are the oracle, which nice 100mbs card is fine hardware and is coupled with a well debugged driver? I don't want to have any more network card problems. I'm tired of this crappy 8139. -mwe On Thu, Dec 28, 2000 at 01:59:03PM -0800, David S. Miller wrote: > > Try pre5 > > Later, > David S. Miller > [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/ -- Mike Elmore [EMAIL PROTECTED] "Never confuse activity with accomplishment." -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/
aic7xxx 2.4.0 test12 hang
hi! kernel: 2.4.0.test12 hardware: Adaptec AIC-7892 Ultra 160/m SCSI host adapter (19160) problem: kernel hangs when using my cdrom with cdparanoia to read cdda data. (i have nothing else on the bus for now.) i'd like 2 provide more info, but after 2 *long* fsck ... (maybe tomorrow :-( i've read about similar hangs on an alpha on this list (same kind of controller) any solution there ... Regards, Armin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Why was this APM patch not fully applied?
On Tue Apr 04 2000 - 23:19:12 EDT, Stephen Rothwell posted a patch to linux-kernel. See http://boudicca.tux.org/hypermail/linux-kernel/2000week15/0481.html To quote: This patch (against 2.3.99pre4-4) does the following: Allow user mode programs to reject standby and suspend operations. [...] This first item is important to me. Unfortunately, the patch no longer applies to current kernels (test13-pre4). Was there any reason for it not to be included, or was it just ignored accidently? (The patch is still available at http://linuxcare.com.au/apm/ if anyone cares.) -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send 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.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 03:29:53AM +0100, Andrea Arcangeli wrote: > On Fri, Dec 29, 2000 at 02:32:32AM +0100, Jure Pecar wrote: > > Hi all, > > > > I'm expiriencing a problem with thttpd web server > > (www.acme.com/software/thttpd) on recent linux 2.2 kernels with Andrea's I downloaded the sources right now to see what 'out of memory' means. I assume you were using version 2.20b. > out of memory looks an userspace message, so it looks like malloc request was My guess was right, it's not possible to know where it came from though: andrea@athlon:~/devel/thttpd-2.20b > grep 'out of' *.c fdwatch.c:** or 0 if the timeout expired, or -1 on errors. A timeout of INFTIM means libhttpd.c: syslog( LOG_CRIT, "out of memory" ); libhttpd.c: syslog( LOG_CRIT, "out of memory" ); libhttpd.c: syslog( LOG_CRIT, "out of memory" ); libhttpd.c: syslog( LOG_CRIT, "out of memory" ); libhttpd.c: syslog( LOG_CRIT, "out of memory" ); libhttpd.c: syslog( LOG_CRIT, "out of memory" ); libhttpd.c: syslog( LOG_ERR, "out of memory" ); libhttpd.c: ** since it's impossible to get out of the tree. However, we still libhttpd.c: syslog( LOG_ERR, "out of memory" ); libhttpd.c: syslog( LOG_ERR, "out of memory" ); thttpd.c: syslog( LOG_CRIT, "out of memory" ); thttpd.c: syslog( LOG_CRIT, "out of memory" ); thttpd.c: (void) fprintf( stderr, "%s: out of memory\n", argv0 ); thttpd.c: syslog( LOG_CRIT, "out of memory" ); thttpd.c: (void) fprintf( stderr, "out of memory\n" ); thttpd.c: syslog( LOG_CRIT, "out of memory" ); thttpd.c: (void) fprintf( stderr, "out of memory\n" ); thttpd.c: syslog( LOG_CRIT, "out of memory" ); andrea@athlon:~/devel/thttpd-2.20b > But luckily it always happens after some kind of memory allocation, so it's going to be the overcommit check of mmap that is complaining as I guessed (assuming glibc isn't buggy in your system). I was thinking I have a minor fix (in aa patchkit) that can help if the problem happens while you are quite near to use all the memory (swap included) and you have very low level of buffercache and pagecache. But I don't think you were near the out of memory condition, right? (can you monitor via `vmstat 1 >log` to be sure?) It addresses more a correctness issue than a real life problem. And if it was a real life problem then you can workaround it with `echo 1 >/proc/sys/vm/overcommit_memory' without need to apply the real fix and recompile the kernel (but again: I don't think this is the problem, setting overcommit_memory to 1 would probably only temporarly hide the problem, you would probably get the task killed by the kernel some time later anyways) BTW, after checking the sources we at least know it wasn't due memory fragmentation (fork complains with a different message). Andrea PS. I'm very suprised thttpd isn't threaded, it should really be threaded at least on the x86 family to run fast. - To unsubscribe from this list: send 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.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 02:32:32AM +0100, Jure Pecar wrote: > Hi all, > > I'm expiriencing a problem with thttpd web server > (www.acme.com/software/thttpd) on recent linux 2.2 kernels with Andrea's > VM-global patches. Without the patch server runs normally with its usual Before the -7 revision the VM-global was sharing a memory corruption bug with vanilla 2.2.x. VM-global was incidentally hiding such bug extremely well though (but with heavy load and using LVM snapshotting I triggered it even under VM-global-6, so then I spotted such last leftover too and the strict fix for such MM corruption bug got merged into 2.2.18pre2x too, and at the same time I released VM-global-7) I need to know exactly which kernel sources you were using (and also the compiler of course ;) > dose of complaints on the linux platform (it's being developed on BSD > afaik), but with the patch it runs ok for about three days (depends on > traffic i guess), then enters into some state where it reports 'out of > memory' for every larger file (>1Mb) it starts serving and dies. When it out of memory looks an userspace message, so it looks like malloc request was too large (it could happen because of an userspace corruption in the 'size' parameter for example). > comes back up it dies again whitin 10 seconds. As this is not happening > on a stock kernel and the restart of the server itself has no efect, i > conclude it has to be something there in the VM-global that thttpd > doesnt really like. As the VM-global seems to be the only cure for the > VM_do_try_to_free_pages problem, which is an issue for me too, i'd > really like to hear some official words on this before 2.2.19 comes out > with VM-global ... and while i'm at it, can we expect ide patch in > 2.2.19 too? Even if you are using VM-global-7 with only this information it's non obvious that VM-global-7 (the one included 19pre3) is the source of your problem. So if you were using the -7 revision please check the logs and the console for Oopses and try to strace the daemon to see how it dies. It's also not clear what it means that restarting the server itself has no effect, as far I can tell it could even be an userspace issue (some rc script that doesn't cope with an unclean exit of the server?). And besides the webserver, how does the rest of the system behaves when the problem appears? There are too many possibilities, we need to restrict our search. You were using -6 revision as first thing you can try to reproduce with 2.2.19pre3 after checking the compiler. If you send me your .config I can send you a binary image to test. Thanks for the feedback, Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
NIC + PCI busmaster problems? (2.2, 2.4) - Was: Re: 8139too driver broken? (2.4-test12)
: On Sat, 23 Dec 2000 18:50:53 +0100, Stefan Hoffmeister wrote: >: On Fri, 22 Dec 2000 18:34:46 + (GMT), Alan Cox wrote: > >>2.2.18 might help and also as an '8139too' driver rewrite which may work > >Advancing further to a 2.4-test12 kernel (with the latest available >8139too driver - 0.9.12) improves the situation even further, but doesn't >solve it. Cool, I am talking to myself again. Is it possible that problems in busmastering support cause these problems (2.2 + 2.4)? There has been a bit of "swap the nic" fun, some work with Manfred on the Realtek, and it seems as if the Realtek 8139 drivers are not to blame, because a 3com 509C-TX exhibits even worse problems in the same system, while both the Realtek 8139 and the 3com 509C-TX perform fine (8 MB/s) when dropped into a different system. Due to that, I believe that the Realtek itself is not to blame, but the system it is stuck in :-) HP Omnibook 800, P133, 48 MB, in the docking station 00:00.0 Host bridge: VLSI Technology Inc 82C535 (rev 03) 00:01.0 PCI bridge: VLSI Technology Inc 82C534 (rev 03) 00:02.0 Class ff00: VLSI Technology Inc 82C532 (rev 02) Complete lspci -vv at end of message. In total, I have tried three different NICs (Realtek 8029(AS), Realtek 8129B, 3com 905C-TX). Of these, only the Realtek 8029(AS) performs as expected: * Realtek 8029(AS), ne2k-pci: 1100+-1 KB/s send; 1000+-30 KB/s receive (netperf) "ping -s 65000" works but * Realtek 8139B, 8139too: 3500+-10 KB/s send; 1300 +-400(!) KB/s receive (netperf) "ping -s 4433" (>3 packets) - 100% packet loss at the Realtek * 3com 905C-TX, 3c59x: 3500+-10 KB/s send; 400 (!) +-300(!) KB/s receive (netperf) "ping -s 2593" (>2 packets) - 100% packet loss at the 3com 905C-TX * 3com 905C-TX, 3c90x: 3500+-10 KB/s send; 400 (!) +-300(!) KB/s receive (netperf) "ping -s 3300" (>2.5 packets) - 100% packet loss at the 3com 905C-TX I find it interesting that only the card that *doesn't* do busmastering (Realtek 8029(AS), according to lspci -vv) performs in an acceptable manner. Could busmastering problems be responsible for this? TIA! Stefan ** 00:00.0 Host bridge: VLSI Technology Inc 82C535 (rev 03) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B- 00:02.0 Class ff00: VLSI Technology Inc 82C532 (rev 02) 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- (32-bit, non-prefetchable) Bus: primary=00, secondary=20, subordinate=22, sec-latency=32 I/O window 0: -0003 I/O window 1: -0003 BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite- 16-bit legacy interface ports at 0001 00:04.1 CardBus bridge: Texas Instruments PCI1130 (rev 04) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- (32-bit, non-prefetchable) Bus: primary=00, secondary=23, subordinate=25, sec-latency=32 I/O window 0: -0003 I/O window 1: -0003 BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite- 16-bit legacy interface ports at 0001 00:06.0 IRDA controller: VLSI Technology Inc 82C147 (rev 02) 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- http://www.tux.org/lkml/
Re: Repeatable Oops in 2.4t13p4ac2
> I am fairly confident something in ac2 is fishy. I can repeatable get > ac2 to fail with PCMCIA and also reiserfs under load, I absolutely > cannot get these failures without ac2. The PCMCIA thing is unlikely to be related (there are no changes on any PCMCIA that actually worked on 13pre4). Reiserfs might be the trigger because the quota code changed, but if it did touch it I'd expect it to have failed to compile > This is totally repeatable so if you want further diagnostics please > let me know I'm going to go and do a detailed audit of the mm bits I have differing from Linus. For one I'd be much happier to differ in drivers with Linus and avoid differing in mm/vm internals stuff. 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: Oops when mounting cdrom
On Fri, Dec 29 2000, Udo A. Steinberg wrote: > Hi all, > > When mounting a 700 MB CD-RW in my Plextor CD-ROM, my machine > reliably oopses. Below is the first oops decoded. > > >>EIP; c01be6df<= Fixed in pre5 -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send 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.19pre and thttpd (VM-global problem?)
Hi all, I'm expiriencing a problem with thttpd web server (www.acme.com/software/thttpd) on recent linux 2.2 kernels with Andrea's VM-global patches. Without the patch server runs normally with its usual dose of complaints on the linux platform (it's being developed on BSD afaik), but with the patch it runs ok for about three days (depends on traffic i guess), then enters into some state where it reports 'out of memory' for every larger file (>1Mb) it starts serving and dies. When it comes back up it dies again whitin 10 seconds. As this is not happening on a stock kernel and the restart of the server itself has no efect, i conclude it has to be something there in the VM-global that thttpd doesnt really like. As the VM-global seems to be the only cure for the VM_do_try_to_free_pages problem, which is an issue for me too, i'd really like to hear some official words on this before 2.2.19 comes out with VM-global ... and while i'm at it, can we expect ide patch in 2.2.19 too? -- Pegasus - To unsubscribe from this list: send 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: CCFOUND and more
On 2000.12.28 Keith Owens wrote: > > Yes. Some arch files change CROSS_COMPILE after CC has been set and > expect the change to flow into the definition of CC. This "feature" > only works because '=' stores the value as text and reevaluates the > text each time, automatically picking up any changes to CROSS_COMPILE. > Using CC := might break m68k and mips. The makefile redesign for 2.5 > will fix this problem once and for all. > OK, understrood. Anyway, I know there is not too much impact of this issue, but you could always convert-to-fast-version the more critical vars with something like: CC = . CPP = $(CC) -E .. include arch/$(ARCH)/Makefile # Eval them once forever CC:=$(CC) CPP:=$(CPP) -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.2.19-pre3-aa3 #3 SMP Wed Dec 27 10:25:32 CET 2000 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre5
On Fri, 29 Dec 2000, Stefan Traby wrote:
> On Thu, Dec 28, 2000 at 03:37:51PM -0800, Linus Torvalds wrote:
>
> > Too bad. Maybe somebody should tell gcc maintainers about programmers that
> > know more than the compiler again.
>
> I know that {p,}gcc-2.95.2{,.1} are not officially supported.
Hmm, I use gcc-2.95.2 myself on some machines, and while I'm not 100%
comfortable with it, it does count as "supported" even if it has known
problems with "long long". pgcc isn't.
> Did you know that it's impossible to compile nfsv4 because of
> register allocation problems with long long since (long long) month ?
lockd v4 (for NFS v3), I assume.
No, I wasn't aware of this particular bug.
> The following does not hurt, it's just a fix for a broken
> compiler:
Ugh, that's ugly.
Can you test if it is sufficient to just simplify the math a bit, instead
of uglyfing that function more? The nlm4_encode_lock() function already
tests for NLM4_OFFSET_MAX explicitly for both start and end, so it should
be ok to just re-code the function to not do the extra "loff_t_to_s64()"
stuff, and simplify it enough that the compile rwill be happy to compile
the simpler function. Something along the lines of
if (.. NLM4_OFFSET_MAX tests ..)
..
*p++ = htonl(fl->fl_pid);
start = fl->fl_start;
len = fl->fl_end - start;
if (fl->fl_end == OFFSET_MAX)
len = 0;
p = xdr_encode_hyper(p, start);
p = xdr_encode_hyper(p, len);
return p;
Where it tries to minimize the liveness of the 64-bit values, and tries to
avoid extra complications.
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: test13-pre5
On Thu, 28 Dec 2000, Marcelo Tosatti wrote:
>
> We also want to move the page to the per-address-space clean list in
> ClearPageDirty I suppose.
I would actually advice against this.
- it's ok to have too many pages on the dirty list (think o fthe dirty
list as a "these pages _can_ be dirty")
- whenever we do a ClearPageDirty() we're likely to remove the page from
the lists altogether, so it's not worth it doing extra work.
The exception, of course, is the actual "filemap_fdatasync()" function,
but that one would probably look something like
spin_lock(&page_cache_lock);
while (!list_empty(&mapping->dirty_pages)) {
struct page *page = list_entry(mapping->dirty_pages.next, struct page,
list);
list_del(&page->list);
list_add(&page->list, &mapping->clean_pages);
if (!PageDirty(page))
continue;
page_get(page);
spin_unlock(&page_cache_lock);
lock_page(page);
if (PageDirty(page)) {
ClearPageDirty(page);
page->mapping->writepage(page);
}
UnlockPage(page);
page_cache_put(page);
spin_lock(&page_cache_lock);
}
spin_unlock(&page_cache_lock);
and again note how we can move it to the clean list early and we don't
have to keep the PageDirty bit 100% in sync with which list is it on. If
somebody marks it dirty later on (and the dirty bit is still set), that
somebody won't move it back to the dirty list (because it noticved that
the dirty bit is already set), but that's ok: as long as we do the
"ClearPageDirty(page);" call before startign the actual writeout(), we're
fine.
So the "mapping->dirty_pages" list is maybe not so much a _dirty_ list, as
a "scheduled for writeout" list. Marking the page clean doesn't remove it
from that list - it can happily stay on the list and then when the
writeout is started we'd just skip it.
Ok?
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/
Oops when mounting cdrom
Hi all, When mounting a 700 MB CD-RW in my Plextor CD-ROM, my machine reliably oopses. Below is the first oops decoded. Can someone explain to me what all those ksymoops warnings are about? -Udo. ksymoops 2.3.5 on i686 2.4.0-test13-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test13-pre4/ (default) -m /usr/src/linux/System.map (specified) Warning (compare_maps): ksyms_base symbol acpi_clear_event_R__ver_acpi_clear_event not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_cm_memcpy_R__ver_acpi_cm_memcpy not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_cm_memset_R__ver_acpi_cm_memset not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_cm_strncmp_R__ver_acpi_cm_strncmp not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_dbg_layer_R__ver_acpi_dbg_layer not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_dbg_level_R__ver_acpi_dbg_level not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_disable_event_R__ver_acpi_disable_event not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_enable_event_R__ver_acpi_enable_event not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_evaluate_object_R__ver_acpi_evaluate_object not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_current_resources_R__ver_acpi_get_current_resources not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_handle_R__ver_acpi_get_handle not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_name_R__ver_acpi_get_name not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_next_object_R__ver_acpi_get_next_object not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_object_info_R__ver_acpi_get_object_info not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_parent_R__ver_acpi_get_parent not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_possible_resources_R__ver_acpi_get_possible_resources not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_processor_cx_info_R__ver_acpi_get_processor_cx_info not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_processor_throttling_info_R__ver_acpi_get_processor_throttling_info not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_processor_throttling_state_R__ver_acpi_get_processor_throttling_state not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_get_type_R__ver_acpi_get_type not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_install_address_space_handler_R__ver_acpi_install_address_space_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_install_gpe_handler_R__ver_acpi_install_gpe_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_install_notify_handler_R__ver_acpi_install_notify_handler not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_breakpoint_R__ver_acpi_os_breakpoint not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_callocate_R__ver_acpi_os_callocate not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_free_R__ver_acpi_os_free not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_in8_R__ver_acpi_os_in8 not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_out8_R__ver_acpi_os_out8 not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_printf_R__ver_acpi_os_printf not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_queue_for_execution_R__ver_acpi_os_queue_for_execution not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_sleep_R__ver_acpi_os_sleep not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol acpi_os_sleep_usec_R__ver_acpi_os_sleep_usec not found in System.map. Ignoring ksyms_base entr
Re: test13-pre5
On Thu, Dec 28, 2000 at 03:37:51PM -0800, Linus Torvalds wrote:
> Too bad. Maybe somebody should tell gcc maintainers about programmers that
> know more than the compiler again.
I know that {p,}gcc-2.95.2{,.1} are not officially supported.
Did you know that it's impossible to compile nfsv4 because of
register allocation problems with long long since (long long) month ?
The following does not hurt, it's just a fix for a broken
compiler:
--- linux/fs/lockd/xdr4.c.orig Fri Dec 29 01:35:32 2000
+++ linux/fs/lockd/xdr4.c Fri Dec 29 01:36:36 2000
@@ -156,7 +156,7 @@
nlm4_encode_lock(u32 *p, struct nlm_lock *lock)
{
struct file_lock*fl = &lock->fl;
- __s64 start, len;
+ volatile __s64 start, len;
if (!(p = xdr_encode_string(p, lock->caller))
|| !(p = nlm4_encode_fh(p, &lock->fh))
Here is an example without this patch (pgcc-2.95.2.1 this time which
is bug-compatible to gcc-2.95.2.1).
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -c -o xdr4.o xdr4.c
xdr4.c: In function `nlm4_encode_lock':
xdr4.c:181: internal error--insn does not satisfy its constraints:
(insn/i 313 585 315 (set (reg:SI 1 %edx)
(subreg:SI (lshiftrt:DI (reg:DI 0 %eax)
(const_int 32 [0x20])) 0)) 323 {lshrdi3_const_int_subreg} (nil)
(nil))
gcc: Internal compiler error: program cpp got fatal signal 13
make[2]: *** [xdr4.o] Error 1
make[2]: Leaving directory `/.localvol000/usr/src/linux-2.4.0-test13pre5/fs/lockd'
make[1]: *** [_modsubdir_lockd] Error 2
make[1]: Leaving directory `/.localvol000/usr/src/linux-2.4.0-test13pre5/fs'
make: *** [_mod_fs] Error 2
The question is: Is it worth to apply ?
--
ciao -
Stefan
"export PS1="rms# " "
Stefan TrabyLinux/ia32 fax: +43-3133-6107-9
Mitterlasznitzstr. 13 Linux/alphaphone: +43-3133-6107-2
8302 Nestelbach Linux/sparc http://www.hello-penguin.com
Austriamailto:[EMAIL PROTECTED]
Europe mailto:[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: New driver
> > On Thu, 28 Dec 2000 22:19:37 +0100 (CET), > [EMAIL PROTECTED] wrote: > >I wanted to share what I've done but since I'm very new to kernel hacking > >I don't know what to do with my patch. Could you give me some hints? > > linux/Documentation/SubmittingPatches > Ok. Since it's a new category, there's no maintainers for it. I'll post the patch here. And since it's quite a bit patch (about 120Kb) you can download the plain text patch at this URL: http://www.ifrance.com/nobis/em8300-patch. This patch is against the linux-2.4.0-test13-pre5 source tree. Description: this is the integration of the em8300 driver available at http://dxr3.sourceforge.net The primary driver is only an external source driver. So I decided to try to build it directly into the kernel source tree (there was incompatibilities with the new Makefile system) and to add a devfs support for the devices. As it is a new category, I've added a submenu to the configuration system: MPEG cards into the Multimedia section. Please note I didn't wrote this driver but simply integrated an existing driver. -- Nicolas Noble - To unsubscribe from this list: send 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: NETDEV WATCHDOG: eth0: transmit timed out
On Thu, Dec 28, 2000 at 12:26:06PM +0100, Manfred wrote: > David wrote: > > > > Same old story, bugger still does it. Have to set the link down/up to > > get it running again. > > > > 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev > > 20) > > > > I missed your earlier mails, could you resend the details? > I'm interested in the output from > > tulip-diag -m -a -f > > before and after a link failure. > > > I'm aware that the tulip drivers doesn't handle cable disconnects and > reconnects with MII pnic cards. I have a patch for that problem, but it > affects _all_ MII tulip cards, and thus it won't be included soon. If > tulip-diag says "10mbps-serial", then you have run into that bug. I have the same transmit timeout problem, but with a D-Link via rhine board. I'm running -test10, and it seems to happen under high (interrupt?) load with both heavy disk and network activity. Interestingly, it appears to happen more often when the other end of the network activity is a 10BaseT link. I'm using a Netgear dual-speed hub. Do you think these might be related? - To unsubscribe from this list: send 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 web cam
On Thu, Dec 28, 2000 at 05:32:15PM -0500, Wakko Warner wrote: > I would have tried linux-usb, but I didn't know where it was, sorry. try http://www.linux-usb.org/ greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - To unsubscribe from this list: send 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.2.18 dies on my 486..
On Thu, 28 Dec 2000, Alan Cox wrote:
>> I just upgraded my 486 firewall's kernel to pure 2.2.18 from
>> 2.2.17, with no other changes, and now it dies with all sorts
>> of hard disk failures.
>>
>> I get:
>>
>> hdb: lost interrupt
>> And stuff about DRQ lost...
>
>What hardware config, what hdparm tuning options ?
AMD 486-DX2/66 12Mb RAM, ALi 14xx chipset. Using 2.2.18 stock
and also 2.2.18+IDE.
hdparm settings:
pts/3 root@gw:~# hdparm -iv /dev/hd[abc]
/dev/hda:
multcount= 16 (on)
I/O support = 1 (32-bit)
unmaskirq= 0 (off)
using_dma= 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 929/16/48, sectors = 713472, start = 0
Model=DSAA-3360, FwRev=25505120, SerialNo=PABP2020102
Config={ SoftSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=929/16/48, TrkSize=59400, SectSize=550, ECCbytes=16
BuffType=3(DualPortCache), BuffSize=96kB, MaxMultSect=16, MultSect=16
DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
CurCHS=929/16/48, CurSects=-486539254, LBA=yes, LBAsects=713472
tDMA={min:240,rec:240}, DMA modes: sword0 sword1 sword2 mword0 mword1
IORDY=yes, tPIO={min:240,w/IORDY:240}, PIO modes:
/dev/hdb:
multcount= 8 (on)
I/O support = 1 (32-bit)
unmaskirq= 0 (off)
using_dma= 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 827/32/63, sectors = 1667232, start = 0
Model=Maxtor 7850 AR, FwRev=UA7X6059, SerialNo=P60133LS
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>5Mbs FmtGapReq }
RawCHS=1654/16/63, TrkSize=0, SectSize=0, ECCbytes=11
BuffType=3(DualPortCache), BuffSize=64kB, MaxMultSect=8, MultSect=8
DblWordIO=yes, OldPIO=2, DMA=yes, OldDMA=1
CurCHS=1654/16/63, CurSects=1889533977, LBA=yes, LBAsects=1667232
tDMA={min:150,rec:150}, DMA modes: sword0 sword1 *sword2 *mword0
IORDY=on/off, tPIO={min:240,w/IORDY:180}, PIO modes: mode3
/dev/hdc:
multcount= 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 524/255/63, sectors = 8418816, start = 0
Model=QUANTUM FIREBALL SE4.3A, FwRev=API.0A00, SerialNo=334734916263
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=14848/9/63, TrkSize=32256, SectSize=512, ECCbytes=4
BuffType=3(DualPortCache), BuffSize=80kB, MaxMultSect=16, MultSect=off
DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
CurCHS=14848/9/63, CurSects=1979711616, LBA=yes, LBAsects=8418816
tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1 *mword2
IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4
UDMA modes: mode0 mode1 mode2
No messages in syslog, but it died numerous times with "hdb
interrupt lost" and DRQ failed or something like that. It seems
to work fine if I access any one drive, but if I copy from hdb ->
hdc the machine dies within seconds.
.config attached
I am thinking possible hardware failure, but I havent spent time
yet trying to narrow it down.
No special lilo options or any tweaking going on on this machine
other than hdparm..
--
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2000, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
--
Are you an open source developer? Need web space? Your own project mailing
lists? Bug tracking software? CVS Repository? Build environments?
Head over to http://sourceforge.net for all of that, and more, for free!
#
# Automatically generated by make menuconfig: don't edit
#
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Processor type and features
#
# CONFIG_M386 is not set
CONFIG_M486=y
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M686 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
#
# General setup
#
CONFIG_NET=y
# CONFIG_PCI is not set
# CONFIG_MCA is not set
# CONFIG_VISWS is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
# CONFIG_BINFMT_JAVA is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_OTHER is not set
# CONFIG_APM is not set
# CONFIG_TOSHIBA is not set
#
# Plug and Play support
#
# CONFIG_PNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_D
[PATCH] e820 memory detection fix for ThinkPad
Hi Linus, Alan, lkml-readers, I first sent this two weeks ago, but other than a suggestion from a linux-kernel reader, I got no response. This small patch didn't appear in a 2.4.0-test kernel either, so I'm just submitting it again. This is a tiny patch to make the int15/e820 memory mapping work on IBM ThinkPads. Until now, I have had to give lilo a mem= option with one meg of RAM less than I actually have; otherwise ACPI events would overwrite data. The only alternative was to use one of the patches available on http://www.pell.portland.or.us/~orc/Memory/, but these are quite big. I tracked down the problem, at least for the ThinkPad 600X (2645-4EU), to arch/i386/boot/setup.S: apparently the bios doesn't retain the value of register %edx, so after the first entry is read the ascii word `SMAP' is lost and further entries won't be recognized. The solution is simple, just move the assignment 6 lines down so it's inside the loop that is done for every entry. This patch is for 2.4.0-test7..12, but it should work for pre13 kernels and even 2.2 kernels with the memory map backport: --- linux/arch/i386/boot/setup.S.origMon Oct 30 17:44:29 2000 +++ linux/arch/i386/boot/setup.S Thu Dec 21 19:37:12 2000 @@ -289,10 +289,11 @@ # a whole bunch of different types, and allows memory holes and # everything. We scan through this memory map and build a list # of the first 32 memory areas, which we return at [E820MAP]. -# +# This is documented at http://www.teleport.com/~acpi/acpihtml/topic245.htm + +#define SMAP 0x534d4150 meme820: -movl $0x534d4150, %edx# ascii `SMAP' xorl %ebx, %ebx # continuation counter movw $E820MAP, %di# point into the whitelist # so we can have the bios @@ -300,13 +301,15 @@ jmpe820: movl $0xe820, %eax# e820, upper word zeroed +movl $SMAP, %edx # do this every time, some + # bioses are forgetful movl $20, %ecx # size of the e820rec pushw %ds # data record. popw %es int $0x15# make the call jc bail820 # fall to e801 if it fails -cmpl $0x534d4150, %eax# check the return is `SMAP' +cmpl $SMAP, %eax # check the return is `SMAP' jne bail820 # fall to e801 if it fails # cmpl $1, 16(%di) # is this usable memory? My ThinkPad now shows this during boot: Linux version 2.4.0-test12 (mjoosen@hexane) (gcc version 2.95.2 19991024 (release)) #2 Sun Dec 10 23:51:04 EST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0bed @ 0010 (usable) BIOS-e820: f000 @ 0bfd (ACPI data) BIOS-e820: 1000 @ 0bfdf000 (ACPI NVS) BIOS-e820: 0002 @ 0bfe (reserved) BIOS-e820: 0002 @ fffe (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009f800 for 4096 bytes. ... and that's without a mem= option to lilo, of course. May I suggest you try this patch in the next 2.[24]-pre kernel? Thanks, and a happy New Year! (And be careful with fireworks, you need those fingers.) BTW: I work for IBM, but I'm not in the PC department (or even ThinkPad development). Unfortunately I won't be able to answer all your IBM-related questions... BTW2: I'm not on the linux-kernel mailing list, so please reply to [EMAIL PROTECTED] Regards, -- Marc Joosen Communication Link Design IBM T.J. Watson Research Center Yorktown Heights, NY - To unsubscribe from this list: send 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: test13-pre5
On Thu, 28 Dec 2000, Linus Torvalds wrote:
> - make "SetPageDirty()" do something like
>
> if (!test_and_set(PG_dirty, &page->flags)) {
> spin_lock(&page_cache_lock);
> list_del(page->list);
> list_add(page->list, page->mapping->dirty_pages);
> spin_unlock(&page_cache_lock);
> }
>
>This will require making sure that every place that does a
>SetPageDirty() will be ok with this (ie double-check that they all have
>a mapping: right now the free_pte() code in mm/memory.c doesn't care,
>because it knew that it coul dmark even anonymous pages dirty and
>they'd just get ignored.
> - make a filemap_fdatasync() that walks the dirty pages and does a
>writepage() on them all and moves them to the clean list.
We also want to move the page to the per-address-space clean list in
ClearPageDirty I suppose.
-
To unsubscribe from this list: send 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] Re: innd mmap bug in 2.4.0-test12
Linus Torvalds wrote: > Ok, pre-5 should have all the same places you found already fixed, but > please do give it some heavy-duty testing to make sure there isn't > anything hidden.. I've beaten on it fairly heavily with the BUG in there as you suggested, with no problems. This kernel even seems a little faster: Test machine: 64 meg, 500 Mhz K6, IDE, Ext2, Blocksize=4K Test: dbench 48 pre49.5 MB/sec 11 min 6 secs pre5 10.8 MB/sec 9 min 48 secs I think it would be an awfully good idea to let the BUG out for mass consumption: + if (PageDirty(page)) BUG(); remove_page_from_inode_queue(page); remove_page_from_hash_queue(page); page->mapping = NULL; -- 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/
[PATCH] swap write clustering for 2.4 (again :))
Linus,
The following patch changes swap_writepage() to try to do write clustering
of phisically contiguous pages which are dirty and in the swapcache.
Do you want to include it in 2.4 ?
diff -Nur --exclude-from=exclude linux.orig/include/linux/mm.h linux/include/linux/mm.h
--- linux.orig/include/linux/mm.h Thu Dec 21 04:34:19 2000
+++ linux/include/linux/mm.hThu Dec 21 03:56:30 2000
@@ -451,6 +451,8 @@
extern int filemap_swapout(struct page *, struct file *);
extern int filemap_sync(struct vm_area_struct *, unsigned long,size_t,
unsigned int);
extern struct page *filemap_nopage(struct vm_area_struct *, unsigned long, int);
+extern inline struct page * ___find_page_nolock(struct address_space *, unsigned
+long, struct page *);
+
/*
* GFP bitmasks..
diff -Nur --exclude-from=exclude linux.orig/include/linux/swap.h
linux/include/linux/swap.h
--- linux.orig/include/linux/swap.h Thu Dec 21 04:34:19 2000
+++ linux/include/linux/swap.h Thu Dec 21 04:16:42 2000
@@ -166,6 +166,8 @@
extern unsigned long swap_cache_find_total;
extern unsigned long swap_cache_find_success;
#endif
+
+extern struct swap_info_struct swap_info[MAX_SWAPFILES];
/*
* Work out if there are any other processes sharing this page, ignoring
diff -Nur --exclude-from=exclude linux.orig/mm/filemap.c linux/mm/filemap.c
--- linux.orig/mm/filemap.c Thu Dec 21 04:34:20 2000
+++ linux/mm/filemap.c Thu Dec 21 03:53:41 2000
@@ -242,7 +242,7 @@
spin_unlock(&pagecache_lock);
}
-static inline struct page * __find_page_nolock(struct address_space *mapping,
unsigned long offset, struct page *page)
+inline struct page * ___find_page_nolock(struct address_space *mapping, unsigned long
+offset, struct page *page)
{
goto inside;
@@ -250,12 +250,22 @@
page = page->next_hash;
inside:
if (!page)
- goto not_found;
+ return NULL;
if (page->mapping != mapping)
continue;
if (page->index == offset)
break;
}
+ return page;
+}
+
+static inline struct page * __find_page_nolock(struct address_space *mapping,
+unsigned long offset, struct page *page)
+{
+ page = ___find_page_nolock(mapping, offset, page);
+
+ if(!page)
+ return NULL;
+
/*
* Touching the page may move it to the active list.
* If we end up with too few inactive pages, we wake
@@ -264,7 +274,7 @@
age_page_up(page);
if (inactive_shortage() > inactive_target / 2 && free_shortage())
wakeup_kswapd(0);
-not_found:
+
return page;
}
diff -Nur --exclude-from=exclude linux.orig/mm/swap_state.c linux/mm/swap_state.c
--- linux.orig/mm/swap_state.c Mon Dec 4 19:22:02 2000
+++ linux/mm/swap_state.c Thu Dec 21 04:23:47 2000
@@ -5,6 +5,8 @@
* Swap reorganised 29.12.95, Stephen Tweedie
*
* Rewritten to use page cache, (C) 1998 Stephen Tweedie
+ *
+ * 21/12/2000 Added swap write clustering. Marcelo Tosatti
*/
#include
@@ -17,9 +19,95 @@
#include
+static inline struct page * swap_page_dirty(unsigned long, unsigned long, struct
+swap_info_struct *);
+
+#define SWAP_WRITE_CLUSTER (1 << page_cluster)
+
static int swap_writepage(struct page *page)
{
- rw_swap_page(WRITE, page, 0);
+ unsigned long page_offset, curr, offset, i, type;
+ struct swap_info_struct *swap;
+ swp_entry_t entry;
+ struct page *cpages[SWAP_WRITE_CLUSTER*2];
+ int count, first;
+
+ entry.val = page->index;
+
+ type = SWP_TYPE(entry);
+
+ swap = &swap_info[type];
+
+ /* If swap area is not a real device, do not try to write cluster. */
+ if(!swap->swap_device) {
+ rw_swap_page(WRITE, page, 0);
+ return 0;
+ }
+
+ page_offset = offset = SWP_OFFSET(entry);
+ cpages[SWAP_WRITE_CLUSTER] = page;
+ count = 1;
+ first = SWAP_WRITE_CLUSTER;
+ curr = 1;
+
+ spin_lock(&pagecache_lock);
+ swap_device_lock(swap);
+
+ /*
+* Search for clusterable dirty swap pages.
+*/
+
+ while (count < SWAP_WRITE_CLUSTER) {
+ struct page *p = NULL;
+
+ if(offset <= 0)
+ break;
+
+ offset = page_offset - curr;
+ p = swap_page_dirty(offset, type, swap);
+
+ if(!p)
+ break;
+
+ cpages[--first] = p;
+
+ ClearPageDirty(p);
+ curr++;
+ count++;
+ }
+
+ curr = 1;
+
+ while (count < SWAP_WRITE_CLUSTER) {
+ struct page *p = NULL;
+ offset = page_offset + curr;
+
+ if(offset >= swap->max)
+ break;
+
+ p = swap_page_dirty(offset, type, swap);
+ if(!p)
+ b
Re: test13-pre5
On Thu, Dec 28, 2000 at 03:37:51PM -0800, Linus Torvalds wrote: > > > On Fri, 29 Dec 2000, Andi Kleen wrote: > > > > Hopefully all the "goto out" micro optimizations can be taken out then too, > > "goto out" often generates much more readable code, so the optimization is > secondary. I was more thinking of cases like the scheduler's gotos, which has gotten rather spagetti recently. Admittedly classic goto out is often more readable than many nested if()s with error handling. > > > I recently found out that gcc 2.97's block moving pass has the tendency > > to move the outlined blocks inline again ;) > > Too bad. Maybe somebody should tell gcc maintainers about programmers that > know more than the compiler again. In x86-64 which relies on 2.97 I'm using __builtin_expect, defined to likely() and unlikely(), which seems to generate good code. -Andi - To unsubscribe from this list: send 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: test13-pre5
On Thu, Dec 28, 2000 at 03:14:56PM -0800, David S. Miller wrote: >Date: Fri, 29 Dec 2000 00:17:21 +0100 >From: Andi Kleen <[EMAIL PROTECTED]> > >On Thu, Dec 28, 2000 at 02:54:52PM -0800, David S. Miller wrote: >> To make things like "page - mem_map" et al. use shifts instead of >> expensive multiplies... > >I thought that is what ->index is for ? > > It is for the page cache identity Andi... you know, page_hash(mapping, index)... Oops, I confused it with the 2.0 page->map_nr, which did exactly that. I should have known better. Thanks for correcting this brainfart. > And the add/sub/shift expansion of a multiply/divide by constant even > in its' most optimal form is often not trivial, it is something on the > order of 7 instructions with waitq debugging enabled last time I > checked. Wonder if it looks better with wq debugging turned off or a compressed ->zone. -Andi - To unsubscribe from this list: send 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: test13-pre5
On Fri, 29 Dec 2000, Andi Kleen wrote: > > Hopefully all the "goto out" micro optimizations can be taken out then too, "goto out" often generates much more readable code, so the optimization is secondary. > I recently found out that gcc 2.97's block moving pass has the tendency > to move the outlined blocks inline again ;) Too bad. Maybe somebody should tell gcc maintainers about programmers that know more than the compiler again. 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: test13-pre5
On Fri, 29 Dec 2000, Andi Kleen wrote: > On Thu, Dec 28, 2000 at 02:54:52PM -0800, David S. Miller wrote: > >Date: Thu, 28 Dec 2000 23:58:36 +0100 > >From: Andi Kleen <[EMAIL PROTECTED]> > > > >Why exactly a power of two ? To get rid of ->index ? > > > > To make things like "page - mem_map" et al. use shifts instead of > > expensive multiplies... > > I thought that is what ->index is for ? No. "index" only gives the virtual index. "page - mem_map" is how you get the _physical_ index in the zone in question, which is common for physical tranlations (ie "pte_page()", "page_to_virt()" or "page_to_phys()") > Also gcc seems to be already quite clever at dividing through small > integers, e.g. using mul and shift and sub, so it may not be even worth to reach > for a real power-of-two. Look at the code - it's a big multiply to do a divide by 68 or similar. Quite expensive. Doing "page->address - TASK_SIZE" on x86 for the non-highmem case would probably be faster. 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: test13-pre5
Date: Fri, 29 Dec 2000 00:17:21 +0100 From: Andi Kleen <[EMAIL PROTECTED]> On Thu, Dec 28, 2000 at 02:54:52PM -0800, David S. Miller wrote: > To make things like "page - mem_map" et al. use shifts instead of > expensive multiplies... I thought that is what ->index is for ? It is for the page cache identity Andi... you know, page_hash(mapping, index)... And the add/sub/shift expansion of a multiply/divide by constant even in its' most optimal form is often not trivial, it is something on the order of 7 instructions with waitq debugging enabled last time I checked. Later, David S. Miller [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: USB web cam
On 2000.12.28 Wakko Warner wrote: > I really hate to ask on the list, but if I was to buy a usb web cam, what > would be a good choice? > > I would have tried linux-usb, but I didn't know where it was, sorry. > Try a fresh new kernel, at least 2.2.18 or any 19-preX. They include usb right 'out of the box'. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.2.19-pre3-aa3 #3 SMP Wed Dec 27 10:25:32 CET 2000 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre5
On Fri, 29 Dec 2000, Andi Kleen wrote: > On Thu, Dec 28, 2000 at 02:54:52PM -0800, David S. Miller wrote: > >Date: Thu, 28 Dec 2000 23:58:36 +0100 > >From: Andi Kleen <[EMAIL PROTECTED]> > > > >Why exactly a power of two ? To get rid of ->index ? > > > > To make things like "page - mem_map" et al. use shifts instead of > > expensive multiplies... > > I thought that is what ->index is for ? Nope, ->index is there to identify which offset the page has in ->mapping, read mm/filemap.c::__find_page_nolock() for more info. > Also gcc seems to be already quite clever at dividing through > small integers, e.g. using mul and shift and sub, so it may not > be even worth to reach for a real power-of-two. > > I suspect doing the arithmetics is at least faster than eating the > cache misses because of ->index. I'm pretty confident that arithmetic is faster than cache misses ... but an unlucky size of the page struct will cause extra cache misses due to misalignment. regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send 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: test13-pre5
On Thu, Dec 28, 2000 at 03:15:01PM -0800, Linus Torvalds wrote: > > (first number for 32bit, second for 64bit) > > > > - Do not compile virtual in when the kernel does not support highmem > > (saves 4/8 bytes) > > Even on UP, "virtual" often helps. The conversion from "struct page" to > the linear address is quite common, and if "struct page" isn't a > power-of-two it gets slow. Are you sure? Last time I checked gcc did a very good job at optimizing small divisions with small integers, without using div. It just has to be a good integer with not too many set bits. > is 100% accurate, we _do_ care that the fields close-by don't get strange > effects from updating "age". We used to have exactly this problem on alpha > back in the 2.1.x timeframe. When it is shared with a constant field (like zone index) it shouldn't matter, no ? At worst you can see outdated data, and when the outdated data is constant all is fine. > > - flags can be __u32 on 64bit hosts, sharing 64bit with something that > > is tolerant to async updates (e.g. the zone table index or the index) > > - index could be probably u32 instead of unsigned long, saving 4 bytes > > on i386 > > It already _is_ 32-bit on x86. Oops. It was a typo. I meant to write "saving 4 bytes on 64bit" > Anyway, I don't want to increase "struct page" in size, but I also don't > think it's worth micro-optimizing some of these things if the code gets > harder to maintain (like the partial-word stuff would be). Ok pity :-/ Hopefully all the "goto out" micro optimizations can be taken out then too, I recently found out that gcc 2.97's block moving pass has the tendency to move the outlined blocks inline again ;) -Andi - To unsubscribe from this list: send 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: test13-pre5
On Thu, Dec 28, 2000 at 02:54:52PM -0800, David S. Miller wrote: >Date: Thu, 28 Dec 2000 23:58:36 +0100 >From: Andi Kleen <[EMAIL PROTECTED]> > >Why exactly a power of two ? To get rid of ->index ? > > To make things like "page - mem_map" et al. use shifts instead of > expensive multiplies... I thought that is what ->index is for ? Also gcc seems to be already quite clever at dividing through small integers, e.g. using mul and shift and sub, so it may not be even worth to reach for a real power-of-two. I suspect doing the arithmetics is at least faster than eating the cache misses because of ->index. -Andikkk - To unsubscribe from this list: send 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: test13-pre5
On Thu, 28 Dec 2000, Andi Kleen wrote: > > BTW.. > > The current 2.4 struct page could be already shortened a lot, saving a lot > of cache. Not that much, but some. > (first number for 32bit, second for 64bit) > > - Do not compile virtual in when the kernel does not support highmem > (saves 4/8 bytes) Even on UP, "virtual" often helps. The conversion from "struct page" to the linear address is quite common, and if "struct page" isn't a power-of-two it gets slow. > - Instead of having a zone pointer mask use a 8 or 16 byte index into a > zone table. On a modern CPU it is much cheaper to do the and/shifts than > to do even a single cache miss during page aging. On a lot of systems > that zone index could be hardcoded to 0 anyways, giving better code. > - Instead of using 4/8 bytes for the age use only 16bit (FreeBSD which > has the same swapping algorithm even only uses 8bit) This would be good, but can be hard. FreeBSD doesn't try to be portable any more, but Linux does, and there are architectures where 8- and 16-bit accesses aren't atomic but have to be done with read-modify-write cycles. And even for fields like "age", where we don't care whether the age itself is 100% accurate, we _do_ care that the fields close-by don't get strange effects from updating "age". We used to have exactly this problem on alpha back in the 2.1.x timeframe. This is why a lot of fields are 32-bit, even though we wouldn't need more than 8 or 16 bits of them. > - Remove the waitqueue debugging (obvious @) Not obvious enough. There are magic things that could be done, like hiding the wait-queue lock bit in the waitqueue lists themselves etc. That could be done with some per-architecture magic etc. > - flags can be __u32 on 64bit hosts, sharing 64bit with something that > is tolerant to async updates (e.g. the zone table index or the index) > - index could be probably u32 instead of unsigned long, saving 4 bytes > on i386 It already _is_ 32-bit on x86. Only the LSF patches made it 64-bit. That never made it into the standard kernel. Sure, we could make it "u32" and thus force it to be 32-bit even on 64-bit architectures, but some day somebody will want to have more than 46 bits of file mappings, and which 46 bits is _huge_ on a 32-bit machine, on a 64-bit one in 5 years it will not be entirely unreasonable. Anyway, I don't want to increase "struct page" in size, but I also don't think it's worth micro-optimizing some of these things if the code gets harder to maintain (like the partial-word stuff would be). The biggest win by far would come from increasing the page-size, something we can do even in software. Having a "kernel page size" of 8kB even on x86 would basically cut the overhead in half. As that would also improve some other things (like having better throughput due to bigger contiguous chunks), that's something I'd like to see some day. (And user space wouldn't ever have to know - we could map in "half pages" aka "hardware pages" without mappign the whole page). 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: 2.2.19 hard hang from userspace while accessing /dev/mdXX devices
On Thu, Dec 28, 2000 at 11:09:34PM +, Alan Cox wrote:
> > If you open a non-existant md device (i.e. /dev/md11) from userspace
> > with an open() call, then send an ioctl() command, it results in the
> > following message then hard hangs the entire system if you attempt
> > to open any /dev/mdXX device with a minor number greater than 10.
> > Used to work on 2.2.17.
>
> What does 2.2.18 show and which raid patches are you using if any on them
2.2.18 pre 27 (2.2.18) exhibits identical behavior. I am not using any
RAID patches. SPEC file used to build the kernel RPM is attached. I am
using the IPVS patch, and an iBCS2 patch (which does not touch the kernel,
just iBCS). The SPEC file lists all the patches being applied to this
kernel.
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/
Summary: The Linux 2.2.18 Kernel
Name: kernel
%define sublevel 18
%define kversion 2.2.%{sublevel}
%define pcmciaver 3.1.22-23
%define ibcsver 2.1-981105
%define ksymoopsver 0.7c
# disable build root strip policy
%define __spec_install_post /usr/lib/rpm/brp-compress || :
Version: %{kversion}
Release: 27
%define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}
Copyright: GPL
Group: System Environment/Kernel
ExclusiveArch: i386 i586 i686 alpha sparc sparc64
ExclusiveOS: Linux
Obsoletes: kernel-modules, kernel-sparc
Source0: ftp://ftp.kernel.org/pub/linux/kernel/v2.2/linux-%{kversion}.tar.gz
Source1: ftp://sourceforge.org/pcmcia/pcmcia-cs-%{pcmciaver}.tar.gz
Source2: ftp://tsx-11.mit.edu/pub/linux/BETA/ibcs2/ibcs-%{ibcsver}.tar.gz
Source3: ftp://ftp.ocs.com.au/pub/ksymoops/ksymoops-%{ksymoopsver}.tar.gz
Source10: pcmcia-cs-2.8.8-network.script
Source11: module-info
Source12: installkernel
Source14: kernel-2.2-BuildASM.sh
Source20: kernel-%{kversion}-i386.config
Source21: kernel-%{kversion}-i386-smp.config
Source22: kernel-%{kversion}-i386-BOOT.config
Source23: kernel-%{kversion}-alpha.config
Source24: kernel-%{kversion}-alpha-smp.config
Source25: kernel-%{kversion}-sparc.config
Source26: kernel-%{kversion}-sparc-smp.config
Source27: kernel-%{kversion}-sparc64.config
Source28: kernel-%{kversion}-sparc64-smp.config
Source29: kernel-%{kversion}-i686.config
Source30: kernel-%{kversion}-i686-smp.config
Source31: kernel-%{kversion}-alpha-BOOT.config
Source32: kernel-%{kversion}-sparc-BOOT.config
Source33: kernel-%{kversion}-sparc64-BOOT.config
Source34: kernel-%{kversion}-i586.config
Source35: kernel-%{kversion}-i586-smp.config
Patch98: ipvs-1.0.0-2.2.17.patch
Patch99: pre-patch-%{PACKAGE_VERSION}-%{PACKAGE_RELEASE}
Patch100: ibcs-2.1-rh.patch
Patch101: ibcs-2.1-locking.patch
BuildRoot: /var/tmp/kernel-%{KVERREL}-root
Provides: module-info
Autoreqprov: no
Requires: initscripts >= 3.64
Vendor: Timpanogas Research Group, Inc.
Packager: [EMAIL PROTECTED]
%package source
Requires: kernel-headers = %{kversion}
Summary: The source code for the Linux kernel.
Group: Development/System
%package headers
Summary: Header files for the Linux kernel.
Group: Development/System
%package doc
Summary: Various documentation bits found in the kernel source.
Group: Documentation
%package pcmcia-cs
Summary: The daemon and device drivers for using PCMCIA adapters.
Group: System Environment/Kernel
Obsoletes: pcmcia-cs
%package utils
Summary: Kernel related utilities.
Group: System Environment/Kernel
%package ibcs
Obsoletes: iBCS
Summary: Files which allow iBCS2 programs to run.
Group: System Environment/Kernel
%description
The kernel package contains the Linux kernel (vmlinuz), the core of your
Linux operating system. The kernel handles the basic functions
of the operating system: memory allocation, process allocation, device
input and output, etc.
%description source
The kernel-source package contains the source code files for the Linux
kernel. These source files are needed to build most C programs, since
they depend on the constants defined in the source code. The source
files can also be used to build a custom kernel that is better tuned
to your particular hardware, if you are so inclined (and you know what
you're doing).
%description headers
Kernel-headers includes the C header files for the Linux kernel. The
header files define structures and constants that are needed for
building most standard programs and are also needed for rebuilding the
kernel.
%description doc
This package contains documentation files form the kernel
source. Various bits of information about the Linux kernel and the
device drivers shipped with it are documented in these files.
You'll want to install this package if you need a reference to the
options that can be passed to Linux kernel modules at load time.
%description pcmcia-cs
Many laptop machines (and some non-laptops) support PCMCIA cards for
expansion. Also known as "credit card adapters," PCMCIA cards are
small cards for everything from SCSI support to
Re: test13-pre5
Date: Thu, 28 Dec 2000 23:58:36 +0100 From: Andi Kleen <[EMAIL PROTECTED]> Why exactly a power of two ? To get rid of ->index ? To make things like "page - mem_map" et al. use shifts instead of expensive multiplies... Later, David S. Miller [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.2.19 hard hang from userspace while accessing /dev/mdXX devices
> If you open a non-existant md device (i.e. /dev/md11) from userspace > with an open() call, then send an ioctl() command, it results in the > following message then hard hangs the entire system if you attempt > to open any /dev/mdXX device with a minor number greater than 10. > Used to work on 2.2.17. What does 2.2.18 show and which raid patches are you using if any on them - To unsubscribe from this list: send 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.19 hard hang from userspace while accessing /dev/mdXX devices
Hard hand in 2.2.19
If you open a non-existant md device (i.e. /dev/md11) from userspace
with an open() call, then send an ioctl() command, it results in the
following message then hard hangs the entire system if you attempt
to open any /dev/mdXX device with a minor number greater than 10.
Used to work on 2.2.17.
message is:
md map 11
bap map 11 ll_rw_block
offending code that causes the hard hang is:
register int fd, ccode;
struct hd_geometry geometry;
fd = open("/dev/md11", O_RDWR);
if (fd < 0)
return 1;
#ifdef HDIO_REQ
ccode = ioctl(fd, HDIO_REQ, &geometry);
#else
ccode = ioctl(fd, HDIO_GETGEO, &geometry);
#endif
if ((ccode == -EINVAL) || (ccode == -ENODEV))
{
close(fd);
return 1;
}
close(fd)
return 0;
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: test13-pre5
On Thu, 28 Dec 2000, Andi Kleen wrote: > On Thu, Dec 28, 2000 at 02:33:07PM -0800, David S. Miller wrote: > >Date:Thu, 28 Dec 2000 23:17:22 +0100 > >From: Andi Kleen <[EMAIL PROTECTED]> > > > >Would you consider patches for any of these points? > > > > To me it seems just as important to make sure struct page is > > a power of 2 in size, with the waitq debugging turned off this > > is true for both 32-bit and 64-bit hosts last time I checked. > > Why exactly a power of two ? To get rid of ->index ? Most likely to minimise the number of cache misses needed to access a complete page_struct. Then again, I guess 48 bytes would _also_ guarantee that we never need more than 2 cache misses to access every part of the page_struct. And the memory wasted in the page_struct may well be a bigger factor than the cache misses on lots of systems... (time for another CONFIG option? ;)) regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send 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: test13-preX: DRM (tdfx.o) unresolved symbols fixed?
Am Donnerstag, 28. Dezember 2000 17:40 schrieb Tony Hoyle: > Dieter Nützel wrote: > > Am Mittwoch, 27. Dezember 2000 11:07 schrieb Nils Philippsen: > > > Hi all, > > > > > > On Wed, 27 Dec 2000, Dieter [iso-8859-1] Nützel wrote: > > > > I got this since test13-pre1 (pre4, now): > > > > > > > > SunWave1>depmod -e > > > > depmod: *** Unresolved symbols in > > > > /lib/modules/2.4.0-test13-pre4/kernel/drivers/char/drm/tdfx.o > > > > > > [snipped] > > > > > > > Something missing in the 'new' drm/Makefile? > > This is a temporary fix: > > --- drmP.old Thu Dec 28 16:27:34 2000 > +++ drmP.hSat Dec 23 13:57:08 2000 > @@ -40,6 +40,7 @@ > #include > #endif /* __alpha__ */ > #include > +#include > #include > #include > #include If I compile agpgart and tdfx directly into the kernel, it works for me, too. Thanks! Dieter - To unsubscribe from this list: send 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: test13-pre5
On Thu, Dec 28, 2000 at 02:33:07PM -0800, David S. Miller wrote: >Date: Thu, 28 Dec 2000 23:17:22 +0100 >From: Andi Kleen <[EMAIL PROTECTED]> > >Would you consider patches for any of these points? > > To me it seems just as important to make sure struct page is > a power of 2 in size, with the waitq debugging turned off this > is true for both 32-bit and 64-bit hosts last time I checked. Why exactly a power of two ? To get rid of ->index ? -Andi - To unsubscribe from this list: send 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 web cam
Em Thu, Dec 28, 2000 at 05:32:15PM -0500, Wakko Warner escreveu: > I really hate to ask on the list, but if I was to buy a usb web cam, what > would be a good choice? > > I would have tried linux-usb, but I didn't know where it was, sorry. one based on the ov511 chipset, like the Creative Web Cam 3, look here: http://alpha.dyndns.org/ov511 ooops, it seems to be unreachable here, so look at Documentation/usb/ov511.txt - Arnaldo - To unsubscribe from this list: send 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 web cam
On Thu, 28 Dec 2000, Wakko Warner wrote: > I really hate to ask on the list, but if I was to buy a usb web > cam, what would be a good choice? The ov511-based cameras seem to work really nicely. (this is a cheap chip, used in lots of different cameras) And while we're on the topic of webcams: http://distro.conectiva.com.br/webcam/ ;) regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send 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-test12: PCMCIA IRQ assignments?
On Tue, Dec 26, 2000 at 07:24:39AM -0500, [EMAIL PROTECTED] wrote: > > Hello, > > I have a Sager NP9820 laptop with an ALI chipset and a TI PCI1251BGFN > PCMCIA chipset. For some reason, when I use the yenta module under 2.4.0, > it gets an incorrect IRQ assignment. It uses IRQ11, which is also used by > my ATI Rage Pro card... therefore, when you install this module, the > machine locks up. > > If I use the pcmcia card services under 2.2.16, then the PCMCIA bridge > gets a correct assignment of IRQ 10. I've poked around a bit and haven't > found a way to force the 2.4.0 module to use a specific IRQ... is there a > way to do this without hardcoding it? Do you have a sound driver loaded? I can use my CardBus Ethernet card only without a sound driver, then the CardBus bridge and Ethernet card show up on IRQ10. Mysteriously however loading the i810_audio driver (for a 440MX chip) moves the bridge to IRQ11 (the same as the 440MX). No lockup, but the bridge and Ethernet card don't work then. I'd be interested what happens in your case. More specifically, as the PCI code enables the 440MX sound device it logs that it uses the same IRQ as the cb bridge, meaning the IRQ changed already. This is 2.4.0-test12. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send 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: test13-pre5
Date:Thu, 28 Dec 2000 23:17:22 +0100 From: Andi Kleen <[EMAIL PROTECTED]> Would you consider patches for any of these points? To me it seems just as important to make sure struct page is a power of 2 in size, with the waitq debugging turned off this is true for both 32-bit and 64-bit hosts last time I checked. Later, David S. Miller [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/
[PATCH] VM fixes + RSS limits 2.4.0-test13-pre5
Hi Linus,
I know this is probably not the birthday present you've been
hoping for, but here is a patch agains 2.4.0-test13-pre5 which
does the following - trivial - things:
1. trivially implement RSS ulimit support, with
p->rlim[RLIMIT_RSS].rlim_max treated as a hard limit
and .rlim_cur treated as a soft limit
2. fix the return value from try_to_swap_out() to return
success whenever we make the RSS of a process smaller
3. clean up refill_inactive() ... try_to_swap_out() returns
the expected result now, so things should be balanced again
4. only call deactivate_page() from generic_file_write() if we
write "beyond the end of" the page, so partially written
pages stay active and will remain in memory longer (8% more
performance for dbench, as tested by Daniel Phillips)
5. (minor) s/unsigned int gfp_mask/int gfp_mask/ in vmscan.c
... we had both types used, which is rather inconsistent
Please consider including this patch in the next 2.4 pre-patch,
IMHO all of these things are fairly trivial and it seems to run
very nicely on my test box ;)
regards,
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
--- linux-2.4.0-test13-pre5/mm/filemap.c.orig Thu Dec 28 19:11:39 2000
+++ linux-2.4.0-test13-pre5/mm/filemap.cThu Dec 28 19:28:06 2000
@@ -1912,7 +1912,7 @@
/* Make sure this doesn't exceed the process's max rss. */
error = -EIO;
- rlim_rss = current->rlim ? current->rlim[RLIMIT_RSS].rlim_cur :
+ rlim_rss = current->rlim ? (current->rlim[RLIMIT_RSS].rlim_cur >> PAGE_SHIFT)
+:
LONG_MAX; /* default: see resource.h */
if ((vma->vm_mm->rss + (end - start)) > rlim_rss)
return error;
@@ -2438,7 +2438,7 @@
}
while (count) {
- unsigned long bytes, index, offset;
+ unsigned long bytes, index, offset, partial = 0;
char *kaddr;
/*
@@ -2448,8 +2448,10 @@
offset = (pos & (PAGE_CACHE_SIZE -1)); /* Within page */
index = pos >> PAGE_CACHE_SHIFT;
bytes = PAGE_CACHE_SIZE - offset;
- if (bytes > count)
+ if (bytes > count) {
bytes = count;
+ partial = 1;
+ }
/*
* Bring in the user page that we will copy from _first_.
@@ -2491,9 +2493,17 @@
buf += status;
}
unlock:
- /* Mark it unlocked again and drop the page.. */
+ /*
+* Mark it unlocked again and release the page.
+* In order to prevent large (fast) file writes
+* from causing too much memory pressure we move
+* completely written pages to the inactive list.
+* We do, however, try to keep the pages that may
+* still be written to (ie. partially written pages).
+*/
UnlockPage(page);
- deactivate_page(page);
+ if (!partial)
+ deactivate_page(page);
page_cache_release(page);
if (status < 0)
--- linux-2.4.0-test13-pre5/mm/memory.c.origThu Dec 28 19:11:39 2000
+++ linux-2.4.0-test13-pre5/mm/memory.c Thu Dec 28 19:12:04 2000
@@ -1198,6 +1198,12 @@
pgd = pgd_offset(mm, address);
pmd = pmd_alloc(pgd, address);
+ if (mm->rss >= (current->rlim[RLIMIT_RSS].rlim_max >> PAGE_SHIFT)) {
+ lock_kernel();
+ enforce_rss_limit(mm, GFP_HIGHUSER);
+ unlock_kernel();
+ }
+
if (pmd) {
pte_t * pte = pte_alloc(pmd, address);
if (pte)
--- linux-2.4.0-test13-pre5/mm/vmscan.c.origThu Dec 28 19:11:40 2000
+++ linux-2.4.0-test13-pre5/mm/vmscan.c Thu Dec 28 20:30:10 2000
@@ -49,7 +49,8 @@
if ((!VALID_PAGE(page)) || PageReserved(page))
goto out_failed;
- if (mm->swap_cnt)
+ /* RSS trimming doesn't change the process' chances wrt. normal swap */
+ if (mm->swap_cnt && !(gfp_mask & __GFP_RSS_LIMIT))
mm->swap_cnt--;
onlist = PageActive(page);
@@ -58,7 +59,13 @@
age_page_up(page);
goto out_failed;
}
- if (!onlist)
+ /*
+* SUBTLE: if the page is on the active list and we're not doing
+* RSS ulimit trimming, then we let refill_inactive_scan() take
+* care of the down aging. Always aging down here would severely
+* disadvantage shared mappings (of eg libc.so).
+*/
+ if (!onlist || (gfp_mask & __GFP_RSS_LIMIT))
/* The page is still mapped, so it can't be freeable... */
age_page_down_ageonly(page);
@@ -85,8 +92,8 @@
* we c
USB web cam
I really hate to ask on the list, but if I was to buy a usb web cam, what would be a good choice? I would have tried linux-usb, but I didn't know where it was, sorry. -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send 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: test13-pre5
On Thu, Dec 28, 2000 at 12:59:22PM -0800, Linus Torvalds wrote: > - we absolutely do _not_ want to make "struct page" bigger. We can't >afford to just throw away another 8 bytes per page on adding a new list >structure, I feel. Even if this would be the simplest solution. BTW.. The current 2.4 struct page could be already shortened a lot, saving a lot of cache. (first number for 32bit, second for 64bit) - Do not compile virtual in when the kernel does not support highmem (saves 4/8 bytes) - Instead of having a zone pointer mask use a 8 or 16 byte index into a zone table. On a modern CPU it is much cheaper to do the and/shifts than to do even a single cache miss during page aging. On a lot of systems that zone index could be hardcoded to 0 anyways, giving better code. - Instead of using 4/8 bytes for the age use only 16bit (FreeBSD which has the same swapping algorithm even only uses 8bit) - Remove the waitqueue debugging (obvious @) - flags can be __u32 on 64bit hosts, sharing 64bit with something that is tolerant to async updates (e.g. the zone table index or the index) - index could be probably u32 instead of unsigned long, saving 4 bytes on i386 Would you consider patches for any of these points? -Andi - To unsubscribe from this list: send 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] shmmin behaviour back to 2.2 behaviour
> You can get the Linux special behaviour to be able to attach to a > removed segment by its shmid by passing the file descriptor for the > posix shm from the attached process to the attaching process. > > Did I miss something? Not that I've ever used 8) - To unsubscribe from this list: send 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: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again
Try pre5 Later, David S. Miller [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: [Patch] shmmin behaviour back to 2.2 behaviour
Alan Cox <[EMAIL PROTECTED]> writes: > There are fundmental things shm* can do that mmap cannot. Does posix > shm handle those (leaving segments alive but unattached being the > obvious one) Yes: shmget == shm_open (+ ftruncate(fd, size)) shmat== mmap (0, size, , , fd, 0) shmdt== munmap (addr, size); shmctl(IPC_RMID) == shm_unlink () shmctl(IPC_STAT) == fstat(); shmctl(IPC_LOCK) == mlock() /*nearly*/ shmctl(IPC_SET) == fchown(), fchmod() You can get the Linux special behaviour to be able to attach to a removed segment by its shmid by passing the file descriptor for the posix shm from the attached process to the attaching process. Did I miss something? Christoph - To unsubscribe from this list: send 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] shmem_unuse race fix
Linus Torvalds <[EMAIL PROTECTED]> writes: > On 28 Dec 2000, Christoph Rohland wrote: > > > > First we need the following patch since otherwise we use a swap entry > > without having the count increased: > > No, that shouldn't be needed. > > Look at the code-path: the kernel has the page locked, so nothing will > de-allocate the swap entry - so it's perfectly ok to increase it > later. I am not sure that page locking is done very strictly in the swap cache. I had to fiddle around that sometimes in shmem.c. The patch actually is getting me the 'right error': Undead swap entries in swapoff instead of bad swap entries in nopage. The latter means there is a swapentry noted in the page table which was legally removed. And that's definitely wrong. > I dislike the "magic" __get_swap_page(2) thing - we might make > get_swap_page() itself _always_ return a swap entry with count two > (one fot eh swap cache, one for the user), or we should keep it the > way it was (where we explicitly increment it for the user). Yes, I agree. I was too lazy to check the other uses of get_swap_page for this patchlet. But at least shmem.c uses the same and I think it's logical. We always need a swap cache and a user reference. > Ok. How about making try_to_unuse() just get the VM semaphore instead of > the page table lock? > > Then try_to_unuse() would follow all the right rules, and the above > problem wouldn't exist.. If this is right we should do this. There is no need to care about contention in swapoff. It's definitely not the common path. But we have to be careful about deadlocks Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again
All, Had another nfsd oops today. I was listening to a mp3 that is located on a nfs partition mounted off the machine that oops'd with no other network activity. Ksymoops output is attached as well as the regular console text. What the heck, I say what the heck is goin on here? -- Mike Elmore [EMAIL PROTECTED] "Never confuse activity with accomplishment." -unknown ksymoops 2.3.5 on i686 2.4.0-test13-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test13-pre4/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. kre8tive.org login: Unable to handle kernel paging request at virtual address dbdbdc17 c01e78b6 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: dbdbdbdb ebx: c1324140 ecx: c3de4f20 edx: 05c8 esi: c3de4f20 edi: ebp: esp: c22d3c68 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 637, stackpage=c22d3000) Stack: c2a02da0 c3de4f20 bbfa 05c8 c2a02da0 012e3b11 c01e7cd9 c2a02da0 c3de4f20 c02e3b4c c22d2000 c23c8680 c3de4f20 c2481010 0101a8c0 c22d2000 dbdbdbdb c482a15f c3de4f20 c482c41c c22d3d84 0003 c22d3d94 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 3c 8b 4c 24 20 89 41 3c 8b 74 24 24 c7 46 18 00 00 00 >>EIP; c01e78b6<= Trace; c01e7cd9 Trace; dbdbdbdb Trace; c482a15f <[ip_conntrack]ip_ct_gather_frags+3b/c8> Trace; c482c41c <[ip_conntrack]ip_conntrack_local_out_ops+0/18> Trace; c4828fc9 <[ip_conntrack]ip_conntrack_in+39/32c> Trace; c482c41c <[ip_conntrack]ip_conntrack_local_out_ops+0/18> Trace; c012b9f9 Trace; c482755a <[ip_conntrack]ip_conntrack_local+5a/60> Trace; c01ea33c Trace; c01e1c1c Trace; c01ea33c Trace; c01e1ed1 Trace; c01ea33c Trace; c482c41c <[ip_conntrack]ip_conntrack_local_out_ops+0/18> Trace; c01e9938 Trace; c01ea33c Trace; c01e9a6e Trace; c01ffe38 Trace; c02002cc Trace; c01ffe38 Trace; c0205bc8 Trace; c0205c06 Trace; c01d764d Trace; c0205bc8 Trace; c0217074 Trace; c0217581 Trace; c02184d6 Trace; c0216c14 Trace; c0175b2a Trace; c01074bb Code; c01e78b6 <_EIP>: Code; c01e78b6<= 0: 8b 40 3c mov0x3c(%eax),%eax <= Code; c01e78b9 3: 8b 4c 24 20 mov0x20(%esp,1),%ecx Code; c01e78bd 7: 89 41 3c mov%eax,0x3c(%ecx) Code; c01e78c0 a: 8b 74 24 24 mov0x24(%esp,1),%esi Code; c01e78c4 e: c7 46 18 00 00 00 00 movl $0x0,0x18(%esi) Kernel panic: Aiee, killing interrupt handler! 1 warning issued. Results may not be reliable. Red Hat Linux release 7.0 (Guinness) Kernel 2.4.0-test13-pre4 on an i686 kre8tive.org login: Unable to handle kernel paging request at virtual address dbdbdc17 printing eip: c01e78b6 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: dbdbdbdb ebx: c1324140 ecx: c3de4f20 edx: 05c8 esi: c3de4f20 edi: ebp: esp: c22d3c68 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 637, stackpage=c22d3000) Stack: c2a02da0 c3de4f20 bbfa 05c8 c2a02da0 012e3b11 c01e7cd9 c2a02da0 c3de4f20 c02e3b4c c22d2000 c23c8680 c3de4f20 c2481010 0101a8c0 c22d2000 dbdbdbdb c482a15f c3de4f20 c482c41c c22d3d84 0003 c22d3d94 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 3c 8b 4c 24 20 89 41 3c 8b 74 24 24 c7 46 18 00 00 00 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing
Re: Abysmal RAID 0 performance on 2.4.0-test10 for IDE?
[EMAIL PROTECTED] (Tim Wright) writes: > On Wed, Dec 27, 2000 at 04:23:43PM +, Paul Jakma wrote: > > On Tue, 26 Dec 2000, Ian Stirling wrote: > > > > > The PCI bus can move around 130MB/sec, > > > > in bursts yes, but sustained data bandwidth of PCI is a lot lower, > > maybe 30 to 50MB/s. And you won't get sustained RAID performance > > > sustained PCI performance. > > > > No. A well-designed card and driver doing cache-line sized transfers can > achieve ~100MB/s. On the IBM (Sequent) NUMA machines, we achieved in excess > of 3GB/s sustained read I/O (database full table scan) on a 16-quad (32 PCI > bus) system. That works out at around 100MB/s per bus. Sadly, I am sure that your "well-designed" system must be costly as hell... :( -- Mathieu CHOUQUET-STRINGER E-Mail : [EMAIL PROTECTED] Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis - To unsubscribe from this list: send 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: New driver
On Thu, 28 Dec 2000 22:19:37 +0100 (CET), [EMAIL PROTECTED] wrote: >I wanted to share what I've done but since I'm very new to kernel hacking >I don't know what to do with my patch. Could you give me some hints? linux/Documentation/SubmittingPatches - To unsubscribe from this list: send 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] 8139too fix
Jeff Garzik, is offline for the next three weeks.. He claims that his wrists hurt from the keyboard ;-)... 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: sharing text segments of all programs
On Thu, 28 Dec 2000, Ari Heitner wrote: > this has to be a dumb idea Not really, you're just 8 (9?) years too late... > The question is, why shouldn't it be possible to share the text > segments of *all* running programs? Linux uses shared mmap() for "loading" executables (well, they're just mapped and demand-loaded as page faults come in), which happens to give exactly the behaviour that's on your wish list ;) regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Abysmal RAID 0 performance on 2.4.0-test10 for IDE?
On Wed, Dec 27, 2000 at 04:23:43PM +, Paul Jakma wrote: > On Tue, 26 Dec 2000, Ian Stirling wrote: > > > The PCI bus can move around 130MB/sec, > > in bursts yes, but sustained data bandwidth of PCI is a lot lower, > maybe 30 to 50MB/s. And you won't get sustained RAID performance > > sustained PCI performance. > No. A well-designed card and driver doing cache-line sized transfers can achieve ~100MB/s. On the IBM (Sequent) NUMA machines, we achieved in excess of 3GB/s sustained read I/O (database full table scan) on a 16-quad (32 PCI bus) system. That works out at around 100MB/s per bus. Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send 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] 8139too fix
Hi,
with the fix below, newer versions of modutils won't
complain about the (missing) symbol debug...
Could you please apply this for the next pre-patch?
thanks,
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
--- ./drivers/net/8139too.c.wrong Thu Dec 28 19:39:18 2000
+++ ./drivers/net/8139too.c Thu Dec 28 19:39:26 2000
@@ -536,7 +536,6 @@
MODULE_DESCRIPTION ("RealTek RTL-8139 Fast Ethernet driver");
MODULE_PARM (multicast_filter_limit, "i");
MODULE_PARM (max_interrupt_work, "i");
-MODULE_PARM (debug, "i");
MODULE_PARM (media, "1-" __MODULE_STRING(8) "i");
static int read_eeprom (void *ioaddr, int location, int addr_len);
-
To unsubscribe from this list: send 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: test13-pre5
Linus Torvalds wrote: > - global dirty list for global syn(). We don't have one, and I don't >think we want one. We could add a few lists, and split up the active >list into "active" and "active_dirty", for example, but I don't like >the implications that would probably have for the LRU ordering. This has been the subject of a lot of flam^H^H^H^H discussion on #kernelnewbies about this and it's still an open question. The only way to see if a separate active_dirty hurts or helps is to try it. Later. :-) I don't see how a separate active_dirty list can hurt LRU ordering. We could still take the pages off the two lists in the same order we did with one list if we wanted to, or at least, statistically the same in turns of number, age, time since entering the list, etc. That better not cause radically different or undesireable behaviour or something is really broken. By breaking active into two lists we'd get a very interesting tuning parameter to play with: the relative rate at which pages are moved from active to inactive. Beyond that, the active_dirty list could be pressed into service quite easily as a page-oriented version of kflushd, and would obviously be useful as a global sync list. -- 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/
Re: innd mmap bug in 2.4.0-test12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > does anyone other than me think that the pm code is *way* too agressive about > spinning down the hard drive? my 256mb laptop (2.2.16) will only spin down the > disk for about 30 seconds before it decides it's got something else it feels > like writing out, and spins back up. Spinnup has got to be more wasteful than > just leaving the drive spinning... Yup, I find this - especially if I hang around in X for a while. - -- " "" " " " " " " " " """ " " " " "" " " "" """ """ "" " " " " "" " """ """ " "" "" """ " " """ " " "" """" "" " "" "" " " """ " " " " "" " " """ " " " "" " " " "" -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Made with pgp4pine iD8DBQE6S7JJRcGgB3aidfkRAhpkAJ9UYVhD+sRqADqUMm2i+UgbuYS8kACgzG4E WhqPEhm6XHixqHpUOFQ4els= =yQKY -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/
linux 2.4.0-test12 compile error
Forgive me if this question has already been answered. I am unable to compile 2.4.0-test12 on my system. Linux-Mandrake 7.1 gcc-2.95.3 (might be a gcc snapshot) binutils-2.10.0.33 (freshly compiled today) modutils-2.3.23 (compiled yesterday) the following is the message I get gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -g -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586 -c -o init/main.o init/main.c In file included from /usr/src/linux/include/linux/pagemap.h:16, from /usr/src/linux/include/linux/locks.h:8, from /usr/src/linux/include/linux/raid/md.h:36, from init/main.c:24: /usr/src/linux/include/linux/highmem.h:48: macro `clear_user_page' used with too many (3) args /usr/src/linux/include/linux/highmem.h:90: macro `copy_user_page' used with too many (4) args make: *** [init/main.o] Error 1 the kernel I am trying to compile is linux-2.4.0-test12 with linux-2.4.0-test12-ia64-001214 and linux-2.4.0-test12-reiserfs-3.6.23 patches applied. Is there something else I need? Matthew D. Pitts [EMAIL PROTECTED]
sharing text segments of all programs
this has to be a dumb idea -- either it's way harder to implement than i think, or it's just plain impossible. but i'm curious why it won't work. So, if you fork, all the pages in both the child and the parent are marked COW. Since the text segment is read only, it'll never be written to; all forked children of a given process image share their code. This makes for very efficient operation in many cases. A program could concievably even communicate with a running copy of itself, and fork off a new copy of the running version rather than keeping multiple copies in memory (resulting in significant savings). And of course shared libraries are shared. The question is, why shouldn't it be possible to share the text segments of *all* running programs? You'd just have to keep track of which running processes have unmodified executables (actually, in solaris, modifying an executable of a running program is a good way to crash the program, since it only loads the parts of the executable as it needs them. from experience, if you're writing a shell in solaris, you can't compile your shell from within your shell :). If you start up another copy of an already-running program, you share its text pages. I know segmented memory models in some past OSs have permitted this sort of thing (OS/2 comes to mind). But this isn't really a segmentation model. It's just a "oh, all that stuff is already in memory, I'll just increase the refcount on *that* copy rather than loading a whole new copy". But i've got to be wrong. I just don't know why. Cheers, Ari Heitner - To unsubscribe from this list: send 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: test13-pre5 (via82cxxx_audio.c)
In article <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> writes:
LT>
LT> The mm cleanups also include removing "swapout()" as a VM operation, as
swapout was not removed from drivers/sound/via82cxxx_audio.c; the
following does so (compiles and produces sound, someone who
understands this please check).
--- drivers/sound/via82cxxx_audio.c.origThu Dec 28 21:02:03 2000
+++ drivers/sound/via82cxxx_audio.c Thu Dec 28 21:12:58 2000
@@ -1727,20 +1727,8 @@
}
-#ifndef VM_RESERVE
-static int via_mm_swapout (struct page *page, struct file *filp)
-{
- return 0;
-}
-#endif /* VM_RESERVE */
-
-
struct vm_operations_struct via_mm_ops = {
nopage: via_mm_nopage,
-
-#ifndef VM_RESERVE
- swapout:via_mm_swapout,
-#endif
};
-
To unsubscribe from this list: send 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: [wildly off-topic] Re: test13-pre5
On Thu, 28 Dec 2000, Rik van Riel wrote: > On Thu, 28 Dec 2000, Marcelo Tosatti wrote: > > On Thu, 28 Dec 2000, Linus Torvalds wrote: > > > > > If somebody (you? hint, hint) wants to do this, > > > > Ok, I'll do it because I love Tove. > > Marcelo, you should buy some glasses ;) > > Tove != Tux > > It's ok and probably safe to love Tux, the nice cuddly > penguin everybody loves. > > However, loving the (6-time ??) Finnish female karate > champion, who happens to be married to Linus is probably > quite a bit less safe ... Marcelo runs like hell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[wildly off-topic] Re: test13-pre5
On Thu, 28 Dec 2000, Marcelo Tosatti wrote: > On Thu, 28 Dec 2000, Linus Torvalds wrote: > > > If somebody (you? hint, hint) wants to do this, > > Ok, I'll do it because I love Tove. Marcelo, you should buy some glasses ;) Tove != Tux It's ok and probably safe to love Tux, the nice cuddly penguin everybody loves. However, loving the (6-time ??) Finnish female karate champion, who happens to be married to Linus is probably quite a bit less safe ... cheers, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
New driver
Hello! I've just joined this mailing-list so forgive-me if I do some mistakes. I've done a little add-on to the linux kernel source in order to build directly the driver for the em8300 chip. This chip is the main chip of the DXR3 and Hollywood Plus mpeg decompression cards. Since now, the source of this driver was an external source tree and it builded four modules that drives the cards. But since the major update of the 2.4.0's Makefiles, it wasn't able to compile up. As I really wanted to use both of them, I tried my best to make it working and it cames into a patch against the linux-2.4.0-test13-pre4 kernel. It adds a new section into the configuration tree in order to support the mpeg decompression cards. And so it builds correctly this driver. I wanted to share what I've done but since I'm very new to kernel hacking I don't know what to do with my patch. Could you give me some hints? Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre5
On Thu, 28 Dec 2000, Linus Torvalds wrote: > If somebody (you? hint, hint) wants to do this, Ok, I'll do it because I love Tove. > I'd be very happy - I can do it myself, but because it's my birthday > I'm supposed to drag myself off the computer soon and be social, or > Tove will be grumpy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] in 2.4.0test12 and earlier
I've posted these problems several times before, but I've never received any response, and I'd really like this problems worked out. I'd be happy to try anything that I can to assist in the bug tracking process. Basically, the kernel locks up on my Alpha PC164 when network load is high. It does it with several different NICs. Any ideas? Also, If I try to compile the kernel for PC164 instead of generic, then the computer gets irq probe errors for the hard drive, and the computer doesn't boot. Any ideas? I would really appreciate help in solving these problems. --Ray Strode - To unsubscribe from this list: send 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: test13-pre5
On Thu, 28 Dec 2000, Marcelo Tosatti wrote:
>
> On Thu, 28 Dec 2000, Linus Torvalds wrote:
>
> > This still doesn't tell "sync()" about dirty pages (ie the "innd loses the
> > active file after a reboot" bug), but now the places that mark pages dirty
> > are under control. Next step..
>
> Do you really want to split the per-address-space pages list in dirty and
> clean lists for 2.4 ?
>
> Or do you think walking the current per-address-space page list searching
> for dirty pages and syncing them is ok?
There are a few issues:
- fdatasync/fsync is often quite critical for databases. It's _possibly_
ok to just walk all the pages for an inode, but I'm fairly certain that
this is an area where if we don't have a separate dirty queue we _will_
need to add one later.
- global dirty list for global syn(). We don't have one, and I don't
think we want one. We could add a few lists, and split up the active
list into "active" and "active_dirty", for example, but I don't like
the implications that would probably have for the LRU ordering.
- we absolutely do _not_ want to make "struct page" bigger. We can't
afford to just throw away another 8 bytes per page on adding a new list
structure, I feel. Even if this would be the simplest solution.
So right now I think the right idea is to
- split up "address_space->pages" into "->clean_pages" and
"->dirty_pages". This is fairly easily done, it requires small changes
like making "truncate_inode_pages()" instead be
"truncate_list_pages()", and making "truncate_inode_pages()" call that
for both the dirty and the clean lists. That's about 10 lines of diff
(I already tried this), and that's about the biggest example of
something like that. Most other areas don't much care about the inode
page lists.
- make "SetPageDirty()" do something like
if (!test_and_set(PG_dirty, &page->flags)) {
spin_lock(&page_cache_lock);
list_del(page->list);
list_add(page->list, page->mapping->dirty_pages);
spin_unlock(&page_cache_lock);
}
This will require making sure that every place that does a
SetPageDirty() will be ok with this (ie double-check that they all have
a mapping: right now the free_pte() code in mm/memory.c doesn't care,
because it knew that it coul dmark even anonymous pages dirty and
they'd just get ignored.
- make a filemap_fdatasync() that walks the dirty pages and does a
writepage() on them all and moves them to the clean list.
- make fsync() and fdatasync() call the above function before they even
call the low-level per-FS code.
- make sync_inodes() use that same filemap_fdatasync() function so that
the sync() case is handled.
All done. It looks something like 5-10 places, most of which are about 10
lines of diff each, if even that.
The only real worry would be that the locking isn't rigth, but getting the
pagemap lock should be the safe thing, and from a lock contention
standpoint it should be ok (if we move a lot of pages back and forth, lock
contention is going to be the least of our worries, because it implies
that we'd be doing a LOT of IO to actually write the pages out).
If somebody (you? hint, hint) wants to do this, I'd be very happy - I can
do it myself, but because it's my birthday I'm supposed to drag myself off
the computer soon and be social, or Tove will be grumpy.
And you don't want Tove grumpy.
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: [PATCH] Re: innd mmap bug in 2.4.0-test12
On Thu, 28 Dec 2000, Daniel Phillips wrote: > > OK, I see you just posted -pre5 while I was making the patch, but here > it is anyway, as a cross-check. Ok, pre-5 should have all the same places you found already fixed, but please do give it some heavy-duty testing to make sure there isn't anything hidden.. 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: [PATCH] Re: innd mmap bug in 2.4.0-test12
Linus Torvalds wrote:
> We don't want to lose dirty bits by mistake. The only cases where it's ok
> to clear the dirty bit is when we truncate a page completely (so it won't
> be needed and obviously really shouldn't be written out) and when we've
> lost the last user of a swap cache entry.
>
> Any other cases might be bugs, where we remove a page from a mapping
> without noticing that it is dirty (we had this bug in reclaim_pages(), for
> example).
I tried to go the lazy way the first time. This time I put the BUG in
there and then went chasing all the places that do
(__)remove_inode_page. There are tentacles all over the place but I
*think* I found them all. That turned up one more place needing
changing, and this is one you already spotted a couple of days ago, in
reclaim_page. I subjected this patch to some dbenching without
triggering the BUG.
The try_to_unuse function calls delete_from_swap_cache and this is
pretty unfamiliar stuff for me, but it looks like the page is just
freshly read and couldn't be dirty. There's one more case in
arch/68K/atari/stram.c (unswap_by_read), similar to try_to_unuse.
OK, I see you just posted -pre5 while I was making the patch, but here
it is anyway, as a cross-check.
--- 2.4.0-test13-pre4.clean/mm/filemap.cFri Dec 29 03:14:58 2000
+++ 2.4.0-test13-pre4/mm/filemap.c Fri Dec 29 04:29:09 2000
@@ -96,6 +96,7 @@
remove_page_from_inode_queue(page);
remove_page_from_hash_queue(page);
page->mapping = NULL;
+ if (PageDirty(page)) BUG();
}
void remove_inode_page(struct page *page)
@@ -132,7 +133,7 @@
curr = curr->next;
/* We cannot invalidate a locked page */
- if (TryLockPage(page))
+ if (PageDirty(page) || TryLockPage(page))
continue;
/* Neither can we invalidate something in use.. */
--- 2.4.0-test13-pre4.clean/mm/vmscan.c Fri Dec 29 03:14:58 2000
+++ 2.4.0-test13-pre4/mm/vmscan.c Fri Dec 29 04:30:48 2000
@@ -484,7 +484,7 @@
}
/* The page is dirty, or locked, move to inactive_dirty list. */
- if (page->buffers || TryLockPage(page)) {
+ if (page->buffers || PageDirty(page) || TryLockPage(page)) {
del_page_from_inactive_clean_list(page);
add_page_to_inactive_dirty_list(page);
continue;
-
To unsubscribe from this list: send 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: test13-pre5
On Thu, 28 Dec 2000, Linus Torvalds wrote: > This still doesn't tell "sync()" about dirty pages (ie the "innd loses the > active file after a reboot" bug), but now the places that mark pages dirty > are under control. Next step.. Do you really want to split the per-address-space pages list in dirty and clean lists for 2.4 ? Or do you think walking the current per-address-space page list searching for dirty pages and syncing them is 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/
[PATCH] remove __mark_buffer_dirty and related changes
On Thu, 28 Dec 2000, Linus Torvalds wrote:
> I would actually prefer not having the balance_dirty() in
> mark_buffer_dirty() at all, and then just potentially adding an explicit
> balance_dirty to strategic places. There would probably not be that many
> of those strategic places.
>
> As it stands, this is a bit too subtle for my taste, having people who
> sleep without really realizing it, and not necessarily really wanting to
> (not for correctness issues, but for latency issues - that superblock lock
> can be quite nasty)
Linus, here is a patch which:
- removes __mark_buffer_dirty()
- makes mark_buffer_dirty() return the old dirty bit on the buffer
- changes mark_buffer_dirty_inode() to return the value returned by
mark_buffer_dirty
- changes all calls to mark_buffer_dirty_inode() (on ext2) to
balance_dirty() in case the return value of mark_buffer_dirty_inode() is
1.
Juan Quintela is going to send a patch which calls balance_dirty() after
unlocking the superblock lock on various places on ext2 as soon as he
finds time to.
Comments?
diff -Nur linux.orig/fs/block_dev.c linux/fs/block_dev.c
--- linux.orig/fs/block_dev.c Thu Dec 28 17:42:14 2000
+++ linux/fs/block_dev.cThu Dec 28 17:55:03 2000
@@ -129,7 +129,8 @@
p += chars;
buf += chars;
mark_buffer_uptodate(bh, 1);
- mark_buffer_dirty(bh);
+ if (mark_buffer_dirty(bh))
+ balance_dirty(dev);
if (filp->f_flags & O_SYNC)
bufferlist[buffercount++] = bh;
else
@@ -144,7 +145,6 @@
}
buffercount=0;
}
- balance_dirty(dev);
if (write_error)
break;
}
diff -Nur linux.orig/fs/buffer.c linux/fs/buffer.c
--- linux.orig/fs/buffer.c Thu Dec 28 17:42:14 2000
+++ linux/fs/buffer.c Thu Dec 28 17:49:17 2000
@@ -1078,16 +1078,13 @@
/* atomic version, the user must call balance_dirty() by hand
as soon as it become possible to block */
-void __mark_buffer_dirty(struct buffer_head *bh)
+int mark_buffer_dirty(struct buffer_head *bh)
{
- if (!atomic_set_buffer_dirty(bh))
+ if (!atomic_set_buffer_dirty(bh)) {
__mark_dirty(bh);
-}
-
-void mark_buffer_dirty(struct buffer_head *bh)
-{
- __mark_buffer_dirty(bh);
- balance_dirty(bh->b_dev);
+ return 1;
+ }
+ return 0;
}
/*
@@ -1851,7 +1848,7 @@
struct inode *inode = (struct inode *)mapping->host;
struct page *page;
struct buffer_head *bh;
- int err;
+ int err, need_balance = 0;
blocksize = inode->i_sb->s_blocksize;
length = offset & (blocksize - 1);
@@ -1908,12 +1905,14 @@
flush_dcache_page(page);
kunmap(page);
- mark_buffer_dirty(bh);
+ need_balance = mark_buffer_dirty(bh);
err = 0;
unlock:
UnlockPage(page);
page_cache_release(page);
+ if (need_balance)
+ balance_dirty(bh->b_dev);
out:
return err;
}
diff -Nur linux.orig/fs/ext2/inode.c linux/fs/ext2/inode.c
--- linux.orig/fs/ext2/inode.c Thu Dec 28 17:42:14 2000
+++ linux/fs/ext2/inode.c Thu Dec 28 17:52:49 2000
@@ -404,7 +404,8 @@
branch[n].p = (u32*) bh->b_data + offsets[n];
*branch[n].p = branch[n].key;
mark_buffer_uptodate(bh, 1);
- mark_buffer_dirty_inode(bh, inode);
+ if (mark_buffer_dirty_inode(bh, inode))
+ balance_dirty(bh->b_dev);
if (IS_SYNC(inode) || inode->u.ext2_i.i_osync) {
ll_rw_block (WRITE, 1, &bh);
wait_on_buffer (bh);
@@ -469,7 +470,8 @@
/* had we spliced it onto indirect block? */
if (where->bh) {
- mark_buffer_dirty_inode(where->bh, inode);
+ if (mark_buffer_dirty_inode(where->bh, inode))
+ balance_dirty(where->bh->b_dev);
if (IS_SYNC(inode) || inode->u.ext2_i.i_osync) {
ll_rw_block (WRITE, 1, &where->bh);
wait_on_buffer(where->bh);
@@ -591,7 +593,8 @@
wait_on_buffer(bh);
memset(bh->b_data, 0, inode->i_sb->s_blocksize);
mark_buffer_uptodate(bh, 1);
- mark_buffer_dirty_inode(bh, inode);
+ if (mark_buffer_dirty_inode(bh, inode))
+ balance_dirty(bh->b_dev);
}
return bh;
}
@@ -907,7 +910,8 @@
if (partial == chain)
mark_inode_dirty(inode);
else
- mark_buffer_dirty_inode(partial->bh, inode);
+ if (mark_buffer_dirty_inode(partial->bh, inode))
+
Re: New discoveries in the EEPro100 init saga
On Sat, Dec 23, 2000, Udo A. Steinberg <[EMAIL PROTECTED]> wrote: ; ; Hi all, ; ; After enabling the option "EEPRO100_PM" and upgrading to test13-pre4 ; my problems with the eepro100 driver mysteriously ceased to exist. ; I no longer see any "Card reports no RX buffers" or "Card reports no ; resources" messages. ; ; Since I don't think -pre4 changed anything from -pre3 that would ; affect the eepro100 driver, my bet is that enabling the experimental ; power management feature somehow works around the issue. ; ; Can others who've had similar problems check if that works for them ; as well? If it does, it should be somewhat simple to work out what ; the problem actually is, because the PM code is just a couple dozen ; lines. Udo, the driver has an issue that is affected by fiddling with different parameters, it's a timing issue of somesort, changing a bit of code seems to fix it on one system but it breaks it on others, I am comparing the driver line by line to the specs to see where the misbehavioure could be comming from. -- I knew I was alone, I was scared, it was getting dark and it was a hardware problem. -Dragan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test13-pre5
The main notables are the network fixes (uninitialized skb->dev could and did cause oopses in ip_defrag) and the mm fixes (dirty pages without mappings etc, causing problems in page_launder). The mm cleanups also include removing "swapout()" as a VM operation, as nobody can sanely do anything more than just marking the page dirty anyway (the real work is done by writepage() these days), and doing that explicitly simplifies VM scanning considerably. This still doesn't tell "sync()" about dirty pages (ie the "innd loses the active file after a reboot" bug), but now the places that mark pages dirty are under control. Next step.. Linus - - pre5: - NIIBE Yutaka: SuperH update - Geert Uytterhoeven: m68k update - David Miller: TCP RTO calc fix, UDP multicast fix etc - Duncan Laurie: ServerWorks PIRQ routing definition. - mm PageDirty cleanups, added sanity checks, and don't lose the bit. - pre4: - Christoph Rohland: shmfs cleanup - Nicolas Pitre: don't forget loop.c flags - Geert Uytterhoeven: new-style m68k Makefiles - Neil Brown: knfsd cleanups, raid5 re-org - Andrea Arkangeli: update to LVM-0.9 - LC Chang: sis900 driver doc update - David Miller: netfilter oops fix - Andrew Grover: acpi update - pre3: - Christian Jullien: smc9194: proper dev_kfree_skb_irq - Cort Dougan: new-style PowerPC Makefiles - Andrew Morton, Petr Vandrovec: fix run_task_queue - Christoph Rohland: shmfs for shared memory handling - pre2: - Kai Germaschewski: ISDN update (including Makefiles) - Jens Axboe: cdrom updates - Petr Vandrovec; Matrox G450 support - Bill Nottingham: fix FAT32 filesystems on 64-bit platforms - David Miller: sparc (and other) Makefile fixup - Andrea Arkangeli: alpha SMP TLB context fix (and cleanups) - Niels Kristian Bech Jensen: checkconfig, USB warnings - Andrew Grover: large ACPI update - pre1: - me: drop support for old-style Makefiles entirely. Big. - me: check b_end_io at the IO submission path - me: fix "ptep_mkdirty()" (so that swapoff() works correctly) - fix fault case in copy_from_user() with a constant size, where ((size & 3) == 3) - To unsubscribe from this list: send 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] ulimit RSS enforcement for 2.4.0-test13-pre4
Hi Linus, Alan, Stephen,
the patch below implements trivial RSS ulimit enforcement
for the 2.4 kernel.
The hard limit (rlim_max) is enforced as a true hard limit,
both at page fault time and again from kswapd. The soft
limit is "enforced" by simply scanning and swapping the
process more agressively from kswapd ...
This behaviour is "comperable" to disk quotas and allows
the sysadmin to set the limits such that the user can have
the memory if it's available but that the processes will
be swapped out first if the memory is needed.
Due to the fact that swapout IO is moved from try_to_swap_out
to page_launder, the enforcement of even the hard limit doesn't
give *ANY* disk IO at all ... the "extra" pages will just sit
in the inactive_dirty list doing nothing; this makes RSS ulimit
enforcement possible without the performance problems we would
have had some time ago.
Since this patch is both trivial and has a very often requested
feature, would you consider adding this to the next pre-patch ?
regards,
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
--- linux-2.4.0-test13-pre4/mm/filemap.c.orig Wed Dec 27 16:48:23 2000
+++ linux-2.4.0-test13-pre4/mm/filemap.cThu Dec 28 17:12:42 2000
@@ -1900,7 +1900,7 @@
/* Make sure this doesn't exceed the process's max rss. */
error = -EIO;
- rlim_rss = current->rlim ? current->rlim[RLIMIT_RSS].rlim_cur :
+ rlim_rss = current->rlim ? (current->rlim[RLIMIT_RSS].rlim_cur >> PAGE_SHIFT)
+:
LONG_MAX; /* default: see resource.h */
if ((vma->vm_mm->rss + (end - start)) > rlim_rss)
return error;
--- linux-2.4.0-test13-pre4/mm/memory.c.origWed Dec 27 16:48:23 2000
+++ linux-2.4.0-test13-pre4/mm/memory.c Thu Dec 28 17:12:19 2000
@@ -1198,6 +1198,12 @@
pgd = pgd_offset(mm, address);
pmd = pmd_alloc(pgd, address);
+ if (mm->rss >= (current->rlim[RLIMIT_RSS].rlim_max >> PAGE_SHIFT)) {
+ lock_kernel();
+ enforce_rss_limit(mm, GFP_HIGHUSER);
+ unlock_kernel();
+ }
+
if (pmd) {
pte_t * pte = pte_alloc(pmd, address);
if (pte)
--- linux-2.4.0-test13-pre4/mm/vmscan.c.origWed Dec 27 16:48:24 2000
+++ linux-2.4.0-test13-pre4/mm/vmscan.c Thu Dec 28 18:01:24 2000
@@ -50,7 +50,8 @@
if ((!VALID_PAGE(page)) || PageReserved(page))
goto out_failed;
- if (mm->swap_cnt)
+ /* RSS trimming doesn't change the process' chances wrt. normal swap */
+ if (mm->swap_cnt && ! (gfp_mask & __GFP_RSS_LIMIT))
mm->swap_cnt--;
onlist = PageActive(page);
@@ -59,7 +60,13 @@
age_page_up(page);
goto out_failed;
}
- if (!onlist)
+ /*
+* SUBTLE: if the page is on the active list and we're not doing
+* RSS ulimit trimming, then we let refill_inactive_scan() take
+* care of the down aging. Always aging down here would severely
+* disadvantage shared mappings (of eg libc.so).
+*/
+ if (!onlist || (gfp_mask & __GFP_RSS_LIMIT))
/* The page is still mapped, so it can't be freeable... */
age_page_down_ageonly(page);
@@ -135,10 +142,13 @@
/*
* Don't do any of the expensive stuff if
* we're not really interested in this zone.
+* Note that RSS limit enforcement should succeed
+* regardless.
*/
if (page->zone->free_pages + page->zone->inactive_clean_pages
+ page->zone->inactive_dirty_pages
- > page->zone->pages_high + inactive_target)
+ > page->zone->pages_high + inactive_target &&
+ !(gfp_mask & __GFP_RSS_LIMIT))
goto out_unlock_restore;
/*
@@ -348,6 +358,58 @@
}
/*
+ * This function is used to enforce RSS ulimits for a process. When a
+ * process gets an RSS larger than p->rlim[RLIMIT_RSS].rlim_max, this
+ * function will get called.
+ *
+ * The function is pretty similar to swap_out_mm, except for the fact
+ * that it scans the whole process regardless of return value and it
+ * keeps the swapout statistics intact to not disturb normal swapout.
+ *
+ * XXX: the caller must hold the kernel lock; this function cannot loop
+ * because mlock()ed memory could be bigger than the RSS limit.
+ */
+void enforce_rss_limit(struct mm_struct * mm, int gfp_mask)
+{
+ unsigned long address, old_swap_address;
+ struct vm_area_struct* vma;
+
+ /*
+* Go through process' page directory.
+*/
+ old_swap_address = mm->swap_address;
+ address = mm->swap_address = 0;
+
+ /* Don't decrement mm->swap_cnt in try_to_swap_out */
+ gfp_mask |= __GFP_RSS_LIMIT;
+
Re: [RFC] changes to buffer.c (was Test12 ll_rw_block error)
On Thu, 28 Dec 2000, Chris Mason wrote:
>
> Linus and Rik are cc'd in to find out if this is a good idea in
> general.
Probably.
There are some arguments for starting the writeout early, but there are
tons of arguments against it too (the main one being "avoid doing IO if
you can do so"), so your patch is probably fine. In the end, the
performance characteristics are what matters. Does the patch make for
smoother behaviour and better performance?
Anyway, the "can_get_io_locks" check is subsumed by the "launder_loop"
check: we will never set "launder_loop" to non-zero if we can't get the
io_locks, so you might as well just make the test be
/* First loop through? Don't start IO, just move it to the back of the list */
if (!launder_loop) {
and be done with it.
I'd like to hear what that does for dbench.
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: [RFC] changes to buffer.c (was Test12 ll_rw_block error)
On Thursday, December 28, 2000 16:49:14 +0100 Daniel Phillips <[EMAIL PROTECTED]>
wrote:
[ dbench 48 test on the anon space mapping patch ]
>
> This benchmark doesn't seem to suffer a lot from noise, so the 7%
> slowdown with your patch likely real.
>
Ok, page_launder is supposed to run through the inactive dirty
list twice, and on the second run, it wants to start i/o. But,
if the page is dirty, writepage is called on the first run. With
my patch, this flushes lots more data than it used to.
I have writepage doing all the i/o, and try_to_free_buffers
only waits on it. This diff makes it so writepage is only called
on the second loop through the inactive dirty list, could you
please give it a try (slightly faster in my tests).
Linus and Rik are cc'd in to find out if this is a good idea in
general.
-chris
--- linux-test13-pre4/mm/vmscan.c Sat Dec 23 13:14:26 2000
+++ linux/mm/vmscan.c Thu Dec 28 15:02:08 2000
@@ -609,7 +609,7 @@
goto page_active;
/* Can't start IO? Move it to the back of the list */
- if (!can_get_io_locks) {
+ if (!launder_loop || !can_get_io_locks) {
list_del(page_lru);
list_add(page_lru, &inactive_dirty_list);
UnlockPage(page);
-
To unsubscribe from this list: send 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] Re: innd mmap bug in 2.4.0-test12
Linus Torvalds wrote: > No, I'd much rather have > > if (PageDirty(page)) BUG(); > > there, and then have the free_swap_cache code clear the dirty bit. > > We don't want to lose dirty bits by mistake. The only cases where it's ok > to clear the dirty bit is when we truncate a page completely (so it won't > be needed and obviously really shouldn't be written out) and when we've > lost the last user of a swap cache entry. > > Any other cases might be bugs, where we remove a page from a mapping > without noticing that it is dirty (we had this bug in reclaim_pages(), for > example). And in this case it's clear we lose data with nfs and smbfs that way. Maybe this is more like it: --- 2.4.0-test13.clean/mm/filemap.c Fri Dec 29 03:14:58 2000 +++ 2.4.0-test13/mm/filemap.c Fri Dec 29 04:13:27 2000 @@ -132,7 +132,7 @@ curr = curr->next; /* We cannot invalidate a locked page */ - if (TryLockPage(page)) + if (PageDirty(page) || TryLockPage(page)) continue; /* Neither can we invalidate something in use.. */ - To unsubscribe from this list: send 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: innd mmap bug in 2.4.0-test12
> > I use ramfs for /tmp on my laptop -- it's very handy because it > > extends the amount of the the disk had spent spun down and therefore > > battery life; but writing large files into /tmp can blow away the > > system or at the very least eat away at otherwise usable ram. Not > > terribly desirable. > > Jeff Garzik had the code to do this, and the new shared memory code should > be able to be massaged to handle this all without actually bloating the > kernel (ie "ramfs" would still stay very very tiny, just taking advantage > of the common code that the VM layer already has to support for other > things). The ramfs maintainer has patches (in -ac) which deal with the size limiting of RAMfs. I'm using it on a PDA and its really really nice to be able to pop up a GUI app and drag the bar to '60% for apps' like other PDA systems ;) They do touch the core vm/vfs code for one callback, which would be nice to lose but not obvious it can be - To unsubscribe from this list: send 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] Re: innd mmap bug in 2.4.0-test12
On Thu, 28 Dec 2000, Daniel Phillips wrote: > [in vmscan.c] > > Between line 573 and 594 the page can have 1 user and be unlocked, so it > > can be removed by invalidate_inode_pages, and the mapping will be > > cleared here: > > http://innominate.org/~graichen/projects/lxr/source/mm/filemap.c?v=v2.3#L98 > > This seems like the obvious thing to do: > > --- 2.4.0-test13.clean/mm/filemap.c Fri Dec 29 03:14:58 2000 > +++ 2.4.0-test13/mm/filemap.c Fri Dec 29 03:16:21 2000 > @@ -96,6 +96,7 @@ > remove_page_from_inode_queue(page); > remove_page_from_hash_queue(page); > page->mapping = NULL; > + ClearPageDirty(page); > } > > void remove_inode_page(struct page *page) No, I'd much rather have if (PageDirty(page)) BUG(); there, and then have the free_swap_cache code clear the dirty bit. We don't want to lose dirty bits by mistake. The only cases where it's ok to clear the dirty bit is when we truncate a page completely (so it won't be needed and obviously really shouldn't be written out) and when we've lost the last user of a swap cache entry. Any other cases might be bugs, where we remove a page from a mapping without noticing that it is dirty (we had this bug in reclaim_pages(), for example). 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: innd mmap bug in 2.4.0-test12
On Thu, 28 Dec 2000, Chris Wedgwood wrote: > > this remind me; perhaps you or Al could answer this. > > How hard would it be to have ramfs backed by swap? The goal being > try to achieve something like a FreeBSDs mfs. > > I use ramfs for /tmp on my laptop -- it's very handy because it > extends the amount of the the disk had spent spun down and therefore > battery life; but writing large files into /tmp can blow away the > system or at the very least eat away at otherwise usable ram. Not > terribly desirable. Jeff Garzik had the code to do this, and the new shared memory code should be able to be massaged to handle this all without actually bloating the kernel (ie "ramfs" would still stay very very tiny, just taking advantage of the common code that the VM layer already has to support for other things). 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: [prepatch] 2.4 waitqueues
On Wed, 27 Dec 2000, Andrew Morton wrote: > > - Introduces a kernel-wide macro `SMP_KERNEL'. This is designed to > be used as a `compiled ifdef' in place of `#ifdef CONFIG_SMP'. There > are a few examples in __wake_up_common(). Please don't do this, it screws up the config option autodetection in "make checkconfig", and also while gcc is reasonably good at deleting dead code, gcc has absolutely no clue at all about deleting dead variables, and will leave the stack slots around giving bigger stack usage and worse cache behaviour. (The gcc stack slot problem is a generic gcc problem - your approach just tends to make it worse). If you want to do this locally somewhere, that's ok, but keep it local. > - SLEEP_ON_VAR, SLEEP_ON_HEAD and SLEEP_ON_TAIL have been changed. I > see no valid reason why these functions were, effectively, doing > this: > > spin_lock_irqsave(lock, flags); > spin_unlock(lock); > schedule(); > spin_lock(lock); > spin_unlock_irqrestore(lock, flags); > > What's the point in saving the interrupt status in `flags'? If the > caller _wants_ interrupt status preserved then the caller is buggy, > because schedule() enables interrupts. 2.2 does the same thing. > > So this has been changed to: > > spin_lock_irq(lock); > spin_unlock(lock); > schedule(); > spin_lock(lock); > spin_unlock_irq(lock); > > Or did I miss something? I'm a bit nervous about changing the old compatibility cruft, but the above is probably ok. Anyway, I'd like you to get rid of the global SMP_KERNEL thing (turning it into a local one if you want to for this case), _and_ I'd like to see this patch with the wait-queue spinlock _outside_ the __common_wakeup() path. Why? Those semaphores will eventually want to re-use the wait-queue spinlock as a per-semaphore spinlock, and they would need to call __common_wakeup() with the spinlock held to do so. So let's get the infrastructure in place. 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: Activating APIC on single processor
Francis Pieraut wrote: >I try to activate APIC interrruption on a single processor(PIII) with >kernel2.4.0-test11. > >I activate APIC interruption with the configuration of linux kernel >2.4.0test-11. In the linux kernel configuration under processor type and >features I activate "APIC and IO-APIC support on uniprocessor", and I >desactivate "Symmetric multi-processing support". The only way I found to >check APIC activation is looking into /proc/interrupts, no "IO-APIC" can >be found there. So I read IO-APIC.txt and I suppose there sould be >conflicts with IRQ of my PCI cards. So I remove all my PCI cards and still >have no APIC interrupt. >Is there another way to check APIC activation? >Am-I doing to right things to activate IO-APIC? CONFIG_X86_UP_IOAPIC only works if you actually have an IO-APIC (the "and" in the description is strict), but most UP boards don't have one. You should apply the UP-APIC patch, available at: http://www.csd.uu.se/~mikpe/linux/upapic/ /Mikael - To unsubscribe from this list: send 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] Re: innd mmap bug in 2.4.0-test12
[in vmscan.c] > Between line 573 and 594 the page can have 1 user and be unlocked, so it > can be removed by invalidate_inode_pages, and the mapping will be > cleared here: > http://innominate.org/~graichen/projects/lxr/source/mm/filemap.c?v=v2.3#L98 This seems like the obvious thing to do: --- 2.4.0-test13.clean/mm/filemap.c Fri Dec 29 03:14:58 2000 +++ 2.4.0-test13/mm/filemap.c Fri Dec 29 03:16:21 2000 @@ -96,6 +96,7 @@ remove_page_from_inode_queue(page); remove_page_from_hash_queue(page); page->mapping = NULL; + ClearPageDirty(page); } void remove_inode_page(struct page *page) - To unsubscribe from this list: send 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] not sleep while holding a locked page in block_truncate_page
On Thu, 28 Dec 2000, Marcelo Tosatti wrote: > > If we call mark_buffer_dirty() on an already dirty buffer, we may sleep > waiting for bdflush even if we haven't caused _any_ real disk IO (because > the buffer was already dirty anyway). > > I think it makes more sense if we only call balance_dirty if we actually > caused real disk IO. > > Would you accept a patch to change that situation by making > __mark_buffer_dirty return the old dirty bit value and make > mark_buffer_dirty only sleep on bdflush if we dirtied a clean buffer? I would actually prefer not having the balance_dirty() in mark_buffer_dirty() at all, and then just potentially adding an explicit balance_dirty to strategic places. There would probably not be that many of those strategic places. As it stands, this is a bit too subtle for my taste, having people who sleep without really realizing it, and not necessarily really wanting to (not for correctness issues, but for latency issues - that superblock lock can be quite nasty) 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: Repeatable Oops in 2.4t13p4ac2
On Thu, 28 Dec 2000 [EMAIL PROTECTED] wrote: > > > > > > > > > > Do you remember if the reports you've got always oopsed the same > > > > > address (004) ? > > > > > > Hi - Here's another Oops from the same machine. It looks to be in a totally > different place in the code which probably means it's a memory problem? Not necessarily, but it may be a memory problem. > I'll try installing on another box to confirm. You can run the memtest86 tool (you can find it at http://reality.sgi.com/cbrady_denver/memtest86/), which is a more reliable way to find out if its really a memory bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Activating APIC on single processor
Hi I have try to activate APIC in my BIOS, but I didn't have this option. Have you ever try it? Tanks Francis Pieraut Francis Pieraut On Thu, 28 Dec 2000, John Levon wrote: > On 28 Dec 2000, David Huggins-Daines wrote: > > > <[EMAIL PROTECTED]> writes: > > > > > I activate APIC interruption with the configuration of linux kernel > > > 2.4.0test-11. In the linux kernel configuration under processor type and > > > features I activate "APIC and IO-APIC support on uniprocessor", and I > > > desactivate "Symmetric multi-processing support". The only way I found to > > > check APIC activation is looking into /proc/interrupts, no "IO-APIC" can > > > be found there. So I read IO-APIC.txt and I suppose there sould be > > > conflicts with IRQ of my PCI cards. So I remove all my PCI cards and still > > > have no APIC interrupt. > > > Is there another way to check APIC activation? > > > Am-I doing to right things to activate IO-APIC? > > > > You might not actually have an IO-APIC or even a local APIC. This is > > the case with the Mobile PIII for instance (I puzzled over this myself > > for a long time). > > > > To find out for sure, run: > > > > grep 'flags.*apic' /proc/cpuinfo > > This isn't for sure. I bet you *do* have a local APIC. > > This flag is missing on a Pentium II here - I think the BIOS disables > it. However, it can be enabled in the normal way just fine. > > The presence of an IO-APIC is a different matter. > > thanks > john > > -- > "The majority of the stupid is invincible and guaranteed for all time. The > terror of their tyranny, however, is alleviated by their lack of consistency." > - Albert Einstein > - To unsubscribe from this list: send 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: innd mmap bug in 2.4.0-test12
On Thursday, December 28, 2000 15:51:24 -0200 Rik van Riel
<[EMAIL PROTECTED]> wrote:
> On Thu, 28 Dec 2000, Chris Mason wrote:
>
>> I think a dirty page without a writepage func seems a bit
>> broken. How about we give ramfs a writepage func that just
>> returns 1. That way nobody does any special if
>> (ramfs_page(page)) kinds of tests...
>
> This will lead to the ramfs pages staying on the inactive_dirty
> list forever, deadlocking the system.
>
This wouldn't be the first time this week I've read this part of
page_launder wrong, but I don't see a difference between a NULL writepage
func, and a writepage func that returns 1. I read the code like this:
if(PageDirty(page)) {
...
if (!writepage)
goto page_active ;
...
result = writepage(page)
if (result != 1)
continue ;
SetPageDirty(page);
goto page_active ;
}
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] not sleep while holding a locked page in block_truncate_page
On Thu, 28 Dec 2000, Linus Torvalds wrote:
>
>
> On Thu, 28 Dec 2000, Marcelo Tosatti wrote:
> >
> > Hi Linus,
> >
> > block_truncate_page() function unecessarily calls mark_buffer_dirty(),
> > which may wait on bdflush, while holding a locked page.
>
> Good catch. It should be ok to sleep for bdflush while holding the page,
> but at the same time it's certainly preferable _not_ to do that.
>
> bdflush should not need any locks that we hold, so it shouldn't have
> deadlocked. How did you find this? Just reading the source, or have you
> seen any real problems?
Just reading the code.
> If the latter, maybe there's something that tries to get a FS lock
> when it shouldn't?
No, its not a deadlock. Its just a potential performance
problem.
Actually, ext2 is full of calls to mark_buffer_dirty() while holding the
superblock lock. Juan Quintela (which is being CC'ed) has a patch to
minimize the contention of the superblock lock by calling balance_dirty()
only after the sb lock gets unlocked all over ext2. Would you accept that
patch for 2.4?
Moreover, it seems mark_buffer_dirty does not makes a lot of sense wrt
balance_dirty:
---
/* atomic version, the user must call balance_dirty() by hand
as soon as it become possible to block */
void __mark_buffer_dirty(struct buffer_head *bh)
{
if (!atomic_set_buffer_dirty(bh))
__mark_dirty(bh);
}
void mark_buffer_dirty(struct buffer_head *bh)
{
__mark_buffer_dirty(bh);
balance_dirty(bh->b_dev);
}
---
If we call mark_buffer_dirty() on an already dirty buffer, we may sleep
waiting for bdflush even if we haven't caused _any_ real disk IO (because
the buffer was already dirty anyway).
I think it makes more sense if we only call balance_dirty if we actually
caused real disk IO.
Would you accept a patch to change that situation by making
__mark_buffer_dirty return the old dirty bit value and make
mark_buffer_dirty only sleep on bdflush if we dirtied a clean buffer?
-
To unsubscribe from this list: send 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: Repeatable Oops in 2.4t13p4ac2
> > > >
> > > > Do you remember if the reports you've got always oopsed the same
> > > > address (004) ?
> > >
Hi - Here's another Oops from the same machine. It looks to be in a totally
different place in the code which probably means it's a memory problem? I'll
try installing on another box to confirm.
Thank you for your help!
Chris
Unable to handle kernel NULL pointer dereference at virtual address 0120
c0145914
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010207
eax: ebx: 0100 ecx: 001e edx: 0c0c
esi: 0100 edi: ebp: 0025dbb1 esp: c333fe5c
ds: 0018 es: 0018 ss: 0018
Process nfsd (pid: 194, stackpage=c333f000)
Stack: 00041182 dff86060 0025dbb1 c18ee000 c0145d3e c18ee000 0025dbb1 dff86060
00041182 c337a200 c3345ec0 c93da800 c0167b01 c18ee000
0025dbb1 0003 c337a200 c0167f41 c18ee000 0025dbb1
Call Trace: [] [] [] [] []
[] [] [] [] []
Code: 39 6e 20 75 ef 8b 44 24 14 39 86 90 00 00 00 75 e3 85 ff 74
>>EIP; c0145914<=
Trace; c0145d3e
Trace; c0167b01
Trace; c0167f41
Trace; c01eaef6
Trace; c01684b0
Trace; c0168a3a
Trace; c01666c3
Trace; c01f8715
Trace; c01664ed
Trace; c0107480
Code; c0145914
<_EIP>:
Code; c0145914<=
0: 39 6e 20 cmp%ebp,0x20(%esi) <=
Code; c0145917
3: 75 ef jnefff4 <_EIP+0xfff4> c0145908
Code; c0145919
5: 8b 44 24 14 mov0x14(%esp,1),%eax
Code; c014591d
9: 39 86 90 00 00 00 cmp%eax,0x90(%esi)
Code; c0145923
f: 75 e3 jnefff4 <_EIP+0xfff4> c0145908
Code; c0145925
11: 85 ff test %edi,%edi
Code; c0145927
13: 74 00 je 15 <_EIP+0x15> c0145929
-
Everyone should have http://www.freedom2surf.net/
-
To unsubscribe from this list: send 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] shmem_unuse race fix
On 28 Dec 2000, Christoph Rohland wrote: > > First we need the following patch since otherwise we use a swap entry > without having the count increased: No, that shouldn't be needed. Look at the code-path: the kernel has the page locked, so nothing will de-allocate the swap entry - so it's perfectly ok to increase it later. I dislike the "magic" __get_swap_page(2) thing - we might make get_swap_page() itself _always_ return a swap entry with count two (one fot eh swap cache, one for the user), or we should keep it the way it was (where we explicitly increment it for the user). > Second there look at this in handle_pte_fault: > > /* >* If it truly wasn't present, we know that kswapd >* and the PTE updates will not touch it later. So >* drop the lock. >*/ > spin_unlock(&mm->page_table_lock); > if (pte_none(entry)) > return do_no_page(mm, vma, address, write_access, pte); > return do_swap_page(mm, vma, address, pte, pte_to_swp_entry(entry), >write_access); > > The comment is wrong. try_to_unuse will touch it. This stumbles over a > bad swap entry after try_to_unuse complaining about an undead swap > entry. > > If I retry in try_to_unuse it goes into an infinite loop since it > deadlocks with this. Ok. How about making try_to_unuse() just get the VM semaphore instead of the page table lock? Then try_to_unuse() would follow all the right rules, and the above problem wouldn't exist.. 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: innd mmap bug in 2.4.0-test12
On Thu, 28 Dec 2000, Linus Torvalds wrote: > On Thu, 28 Dec 2000, Rik van Riel wrote: > > > > I've made a small debugging patch that simply checks > > for this illegal state in add_page_to_active_list and > > add_page_to_inactive_dirty_list. > > I bet it won't catch the real bad guy, which almost certainly is > the "remove_from_swap_cache()" thing (it should do a > ClearPageDirty() before it removes it from the swapper_inode > mapping). Ohhh indeed. This is a very likely candidate which is trivial to fix. regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send 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] not sleep while holding a locked page in block_truncate_page
On Thu, 28 Dec 2000, Marcelo Tosatti wrote: > > Hi Linus, > > block_truncate_page() function unecessarily calls mark_buffer_dirty(), > which may wait on bdflush, while holding a locked page. Good catch. It should be ok to sleep for bdflush while holding the page, but at the same time it's certainly preferable _not_ to do that. bdflush should not need any locks that we hold, so it shouldn't have deadlocked. How did you find this? Just reading the source, or have you seen any real problems? If the latter, maybe there's something that tries to get a FS lock when it shouldn't? 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/
