test13-pre6 compile error..network.o
Hello, I received the following error while compiling test13-pre6 . net/network.o: In function `lecd_attach':net/network.o(.text+0x5ce78): undefined reference to `prepare_trdev'net/network.o(.text+0x5ce88): undefined reference to `prepare_etherdev'net/network.o(.text+0x5cee3): undefined reference to `publish_netdev'make: *** [vmlinux] Error 1 Regards, -Frank
Re: memmove broken on alpha - was Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)
On Sat, Dec 30, 2000 at 05:18:25AM +0200, Matti Aarnio wrote: > As the patch by mr. Kokshaysky is quite different doing more work > (and not only label name changes), I would prefer Richard Henderson > to act as an umpire to tell if your patch is sufficient, or if that > big thing by Kokshaysky is needed. Ivan's code is needed. You can't fall back to memcpy when there is overlap. The ev6 version _will_ corrupt data if you do. r~ - To unsubscribe from this list: send 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 info -- HPT370 RAID support now possible? (was New possibilitiesfor HPT370 RAID support?)
I have email Soren a few days ago and asked him about how he did the decoding of the RAID Signatures on the media and he has not replied. Soren and I talk on a semi-quarterly basis to brag and boast/gloat. For the record I have the information on the array content, and the raid engin design, but can not derive a sane use for Linux. FreeBSD use a CAM layer so they can do some things that Linux can not but they have a perfoamance price that Linux does not have. You take CAM->SCSI->ATA and back and you see how nasty that crap is in the performance market. If you want to tear into FreeBSD and extract the information for me go for it. I have a MESS known as CPRM to stop and I am in the middle of drafting a counter proposal to prevent the CPU/PC/Computer world from being royally screwed by Hollywood. http://www0.mercurycenter.com/svtech/news/top/docs/copy122900.htm Cheers, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development On Sat, 30 Dec 2000, Raymond Carney wrote: > I've read everything that I can find regarding support of the Highpoint > controllers RAID functionality under Linux, and I understand what the issues > have been. The one promising bit of information that I dug up in this process is > that the 'pseudo' RAID functionality of the Highpoint and Promise IDE RAID > controllers is now supported in FreeBSD (4.2-RELEASE and 5.0-CURRENT). My > question is, can the new BSD code be leveraged to add support for these > controllers to the Linux kernel, and could we reasonably expect to see such > support in the near future? > > (I think that most all of the relevant/important bits are in ata-raid.c and/or > ata-raid.h. In > any event, the IDE/ATA guy over on the FreeBSD side is Soren Schmidt > ([EMAIL PROTECTED]), and he > wrote all of the stuff for this. It is my understanding that he got all of the > info on how Highpoint lays out the geometry of the array directly from > Highpoint, and that they were "very forthcoming" with whatever information that > the FreeBSD team asked for. > > There are also indications of support in OpenBSD and NetBSD's pciide driver, > based on work done by Chris Cappuccio ([EMAIL PROTECTED]) and Manuel Bouyer > ([EMAIL PROTECTED])) > > > Please CC: me directly on any replies, and Thanks very much in advance. > -- > __ > /*** ***\ > Raymond Carney <> Discovery consists of seeing what everybody > [EMAIL PROTECTED] <> has seen and thinking what nobody has thought. > 860.774.1939 <> - Albert Von Szent-Gyorgyi > > \***__***/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
New info -- HPT370 RAID support now possible? (was New possibilities for HPT370 RAID support?)
I've read everything that I can find regarding support of the Highpoint
controllers RAID functionality under Linux, and I understand what the issues
have been. The one promising bit of information that I dug up in this process is
that the 'pseudo' RAID functionality of the Highpoint and Promise IDE RAID
controllers is now supported in FreeBSD (4.2-RELEASE and 5.0-CURRENT). My
question is, can the new BSD code be leveraged to add support for these
controllers to the Linux kernel, and could we reasonably expect to see such
support in the near future?
(I think that most all of the relevant/important bits are in ata-raid.c and/or
ata-raid.h. In
any event, the IDE/ATA guy over on the FreeBSD side is Soren Schmidt
([EMAIL PROTECTED]), and he
wrote all of the stuff for this. It is my understanding that he got all of the
info on how Highpoint lays out the geometry of the array directly from
Highpoint, and that they were "very forthcoming" with whatever information that
the FreeBSD team asked for.
There are also indications of support in OpenBSD and NetBSD's pciide driver,
based on work done by Chris Cappuccio ([EMAIL PROTECTED]) and Manuel Bouyer
([EMAIL PROTECTED]))
Please CC: me directly on any replies, and Thanks very much in advance.
--
__
/*** ***\
Raymond Carney <> Discovery consists of seeing what everybody
[EMAIL PROTECTED] <> has seen and thinking what nobody has thought.
860.774.1939 <> - Albert Von Szent-Gyorgyi
\***__***/
-
To unsubscribe from this list: send 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-pre6 (Fork Bug with Athlons? Temporary Fix)
On Fri, Dec 29, 2000 at 07:36:21PM -0800, Linus Torvalds wrote: > Maybe your libc is different on the different machines? Normal programs > shouldn't use segments at all, so I really do not see how this patch could > matter in the least, even if it was completely and utterly buggy (which is > not obvious at first glance). > > I wonder why you seem to have an LDT at all.. glibc 2.2 linuxthreads sets up an LDT to use %gs as thread local data base pointer. -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/
bttv in 2.2.18 worse than 2.2.17
With 2.2.18, I've noticed a few problems with my Hauppauge Win/TV 401 (bt878) card not present in 2.2.17 (using XawTV 2.46 in overlay mode for both): 1) Switching channels causes a brief flicker where the picture shrinks to 1/4 the size in the upper left corner, then changes to the next channel. 2) JPEG captures cause a purple and green fuzzy screen to briefly flash in place of the television image. 3) The first time I run XawTV after loading the module, I get no picture until I change Television -> Composite -> Television. Subsequent runs are fine. Video card is an S3 Virge DX. 00:14.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02) Subsystem: Hauppage computer works Inc.: Unknown device 13eb 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- 4 in the 2.2.18 patch doesn't do anything by itself. -George Greer - To unsubscribe from this list: send 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-pre6 (Fork Bug with Athlons? Temporary Fix)
Ok, I don't think this is an athlon bug, and I think I've figured out what the problem is. For now, you rtemporary fix is probably fine, I'll clean stuff up a bit and make a nicer patch available tomorrow. 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: test13-pre5/drivers/sound/via82cxxx_audio.c did notcompile
On Fri, 29 Dec 2000, Adam J. Richter wrote: > > linux-2.4.0-test13-pre5 eliminated vm_operations_struct->swapout, > but this change was not reflected in drivers/sound/via82cxxx_audio.c, > causing that file to fail to compile. I have attached what I believe > is the correct fix below. Actually, the right fix is to change all VM_RESERVE to VM_RESERVED (ie add a "D" at the end), at which point it should compile and work fine.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, 29 Dec 2000, Andrea Arcangeli wrote: > On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote: > > Your cgi will keep the other CPU occupied, or run two of them. thttpd has > > superb scaling properties compared to say apache. > > I think with 8 CPUs and 8 NICs (usual benchmark setup) you want more than 1 cpu > serving static data and it should be more efficient if it's threaded and > sleeping in accept() instead of running eight of them (starting from sharing > tlb entries and avoiding flushes probably without the need of CPU binding). hey, nobody sane runs an 8 CPU box with 8 NICs for a production webserver. 8 single CPU boxes, or 4 dual boxes behind a load balancer. now that's more common, more scalable, more robust. :) oh yeah they all run perl, java, or php too :) i've seen sites with more than 100 dynamic front-ends and a pair of 350Mhz x86 boxes in the corner handling all the static needs (running apache even!). a pair only 'cause of redundancy reasons, not because of load reasons. 100Mbits/s of *transit* internet bandwidth costs US$75000 per month in typical datacenters btw. obviously there's cheaper bandwidth if you push out to the edges of the net, into the central offices. this isn't to say that nobody will ever want phat bandwidth on a single webserver... but i'd say linux and most everyone else is at least 3 years ahead of the long-haul networks in terms of ability to pump data. the true value of zero-copy TCP will be more apparent in the upcoming age of 1 Mbit/s video thanks to MPEG4. i'd expect to see the cable/dsl conglomerates start doing this in their central offices soon. the RAM and CPU hungry dynamic content languages tend to dictate the sheer quantity of machines required to handle even small web volumes -- folks quickly exceed the reasonably priced SMP systems available. the cost per CPU, and per Mb RAM are the limiting factors (these go up quickly when you put all CPUs and RAM on the bus). that plus the desire for reliability / lack of a single failure point mean that web development tools have grown up expecting to be on a distributed network of nodes rather than on a large SMP system. the 8 CPU monsters run stuff like NFS/filesystems and oracle. some day someone will build a horizontally scalable database which works, with a reasonable licensing policy and then we'll see even more value in commodity hardware/networking. this is an area i'm currently quite interested in, pointers to research / interesting projects appreciated. i know about globalfilesystem.org, veritas clustered fs, oracle parallel server, and IBM DB2 EEE already -- none are quite to the point where i'd use them to scale something across 100 nodes yet though. -dean - To unsubscribe from this list: send 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-pre6
On Fri, 29 Dec 2000, Linus Torvalds wrote: > Marco d'Itri and everybody else who has seen innd problems (or other > shared map problems): can you verify that test13-pre6 works for you? The ->mapping problem seems to be gone in test13-pre5, I'm running this kernel for over 30 hours now with no glitch, gonna check if it's the same for test13-pre6. -- Dan Aloni [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: test13-pre5/drivers/sound/via82cxxx_audio.c did not compile
linux-2.4.0-test13-pre5 eliminated vm_operations_struct->swapout,
but this change was not reflected in drivers/sound/via82cxxx_audio.c,
causing that file to fail to compile. I have attached what I believe
is the correct fix below.
via82cxxx_audio.c has Jeff Garzik's name on it, but I understand
that he is taking a break for a few weeks to recover from typing strain.
(Hope you recover soon, Jeff.) Consequently, I am not sure whom I should
ask to "bless" this change. So, I'll just send this to linux-kernel
and Linus and will leave it to linux-kernel readers to sound the alarm
if I botched the patch.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.0-test13-pre5/drivers/sound/via82cxxx_audio.c Mon Oct 30 12:24:22
2000
+++ linux/drivers/sound/via82cxxx_audio.c Fri Dec 29 16:53:22 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
};
Re: test13-pre6 (Fork Bug with Athlons? Temporary Fix)
On Fri, 29 Dec 2000, Byron Stanoszek wrote: > > I narrowed the problem down to a subset of patches from the MM set in > test13-pre2. Reversing the attached 'context.patch' fixes the problem (only for > i386), but I'm not yet sure why. test13-pre2 and up work without any problems > on an Intel cpu (Pentium 180 & P3 800 tested). Cool. Maybe your libc is different on the different machines? Normal programs shouldn't use segments at all, so I really do not see how this patch could matter in the least, even if it was completely and utterly buggy (which is not obvious at first glance). I wonder why you seem to have an LDT at all.. > Anyways, I can't seem to find out what really changes with the patch except for > the obvious 'void *segment' changing into a typedef-struct. Would you mind trying to hunt this down a bit more? In particular, it would be good to see if the behaviour is the same if you do the typedef change but leave the other logic alone. That would also cut down on the purely syntactic changes of the patch. I'll take a look at the code here. Thanks, 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/
(REPOST-sorry) PCI VIA IDE Strangeness w/2.4.0-test12/test13-pre5
REPOST: People have asked me to repost this message because their e-mail clients don't wrap lines. I'd like to know which ones don't, but this isn't the list for that kind of question, unless it is, which then means I'm posting to the wrong list to start with and then I wouldn't have to repost. Anyways... ---(CC answer please)--- I'm having a strange problem with my IDE controller. I believe (and that's what Windows and the m/b manufaturer -- PC Chips -- say) that I have a VIA PCI BusMaster IDE controller, and I've had some strange history with it. I've asked many people before on various help services, and I was able to fix my problem with the 2.2 series, but now my fix does not work. THE PROBLEM: Ever since the 2.2 kernel series (I remeber this working properly in 2.0.36, without the conflicts), I would get hdc: lost interrupt during boot up, and my system would take bloody ages to boot up and load a CD. I tracked it down to a strange IRQ conflict in which Linux would try to assign both the primary and secondary IDE channels IRQ 14, causing IRQ conflicts galore. I was able to fix this by giving the kernel ide1=0x170,0x376,15 at boot time. This has worked for 2.2.12-.17 and Alan's 2.2.18pre21 (I haven't compiled the official 2.2.18 yet, but I'm sure it will work). I wanted to try the new 2.4.0-test series, and the first I tried was -test11, and from what I recall (other things weren't working properly then), this fix still worked, but now, with -test12, I am now getting the following error repeated for a very long time (then I reboot) with the same parameters: ide_dmaproc: chipset supported ide_dma_lostirq func only: 13 hdb: lost interrupt Also, I get "spurious 8259A interrupt: IRQ 7" if I leave it for a while. I tried -test13-pre5 on somebody on #KernelNewbies' suggestion, and I get the same error. Scrolling up, I see that the kernel messages show that ide0 is on IRQ 14 and ide1 is on 15. I noticed that hda is using DMA, and hdb is using UDMA33, but I don't believe that that is the problem. THE QUESTION: - How do I fix this, or is it a (un)known problem in the newer development versions? If you have the answer, could you please CC me as well for I don't subscribe to this mailing list (sorry!). Thanks a bunch. -- | Evan A. Thompson | He's more fun than trying to skinny | | [EMAIL PROTECTED] | dip in the beach in winter...| | http://evaner.penguinpowered.com |...in Winnipeg. | | ICQ: 2233067 / AIM + MSN: Evaner517 | (GnuPG key avaiable upon request.) | - To unsubscribe from this list: send 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-pre6
On Sat, 30 Dec 2000, Daniel Phillips wrote: > Linus Torvalds wrote: > > > > Ok, there's a test13-pre6 out there now, which does a partial sync with > > Alan, in addition to hopefully fixing the innd shared mapping writeback > > problem for good. Thanks to Marcelo Tosatti and others.. > > After the page_cache_release at line 574 of vmscan.c the page is > unlocked and only owned by the page cache - anything could happen. How > do you know the set_page_dirty at line 581 is still hitting a valid > page? Good question. It should be safe because of the magic return value from "writepage()". If "writepage()" returns 1, then that implies that the page is locked down somehow. But you're right, this is ugly, if not outright buggy (maybe the locked down state could change after the writepage, who knows?). Moving the test is probably a good idea. 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: memmove broken on alpha - was Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)
On Sat, Dec 30, 2000 at 01:02:44PM +1100, Neil Brown wrote: > [ extra detail included because I have added linux-alpha and lins to > the cc list] > > It appears that memmove is broken on the alpha architecture. Indeed it is, and your observation/patch isn't the first one: Date: Thu, 21 Dec 2000 18:40:46 +0300 From: Ivan Kokshaysky <[EMAIL PROTECTED]> To: Alexander Zarochentcev <[EMAIL PROTECTED]> Cc: Richard Henderson <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: memmove() in 2.4.0-test12, alpha platform As the patch by mr. Kokshaysky is quite different doing more work (and not only label name changes), I would prefer Richard Henderson to act as an umpire to tell if your patch is sufficient, or if that big thing by Kokshaysky is needed. Full email (and patch) by Kokshaysky is at: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0012.2/0712.html > memmove is used by net/sunrpc/xdr.c:xdr_decode_string > to move a string 4 bytes down in memory. > memmove(X-4, X, 8) should change > > X: 00 00 00 08 67 69 6c 62 65 72 74 64 > to > X: 67 69 6c 62 65 72 74 64 65 72 74 64 > > Instead it changes it to > > X: 65 72 74 64 65 72 74 64 65 72 74 64 > > This is my first time in alpha assembler, but it looks fairly readable > and the comments help > > Working from > arch/alpha/lib/memmove.S > which I think translates to the following patch: > > --- arch/alpha/lib/memmove.S 2000/12/30 01:59:28 1.1 > +++ arch/alpha/lib/memmove.S 2000/12/30 01:59:49 > @@ -17,7 +17,7 @@ > memmove: > addq $16,$18,$4 > addq $17,$18,$5 > - cmpule $4,$17,$1/* dest + n <= src */ > + cmpule $16,$17,$1 /* dest <= src */ > cmpule $5,$16,$2/* dest >= src + n */ > > bis $1,$2,$1 > > NeilBrown /Matti Aarnio - To unsubscribe from this list: send 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-pre6 (Fork Bug with Athlons? Temporary Fix)
On Fri, 29 Dec 2000, Linus Torvalds wrote:
>
> Ok, there's a test13-pre6 out there now, which does a partial sync with
> Alan, in addition to hopefully fixing the innd shared mapping writeback
> problem for good. Thanks to Marcelo Tosatti and others..
I've been noticing a problem with the memory context switching conflicting with
fork() on my Athlon. The problem began in the test13-pre2 patch, and because
nobody else has seen this problem (or otherwise reported it) since then, I
felt I should look into it a little further.
I narrowed the problem down to a subset of patches from the MM set in
test13-pre2. Reversing the attached 'context.patch' fixes the problem (only for
i386), but I'm not yet sure why. test13-pre2 and up work without any problems
on an Intel cpu (Pentium 180 & P3 800 tested).
Anyways, I can't seem to find out what really changes with the patch except for
the obvious 'void *segment' changing into a typedef-struct. The only thing I
can think of is that the compiler decodes it differently, but I think I can
safely rule that out. I tried both 2.91.66 and 2.95.2, using both different
types of parameters for P5 & K7 (-march=i586 & -march=i686 -malign-functions=4)
and it still gives the problem on the Athlon. Maybe there's something I've
overlooked in that attached patch. Request for an extra pair of eyes please. :)
Here are the casual symptoms. The parent seems to die as soon as a forked child
exits, which seems to me that a new LDT isn't being initialized correctly:
root:~> ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 1.1 0.4 1228 532 ?S21:42 0:05 init [3]
root 2 0.0 0.0 00 ?SW 21:42 0:00 [keventd]
root 3 0.0 0.0 00 ?SW 21:42 0:00 [kswapd]
root 4 0.0 0.0 00 ?SW 21:42 0:00 [kreclaimd]
root 5 0.0 0.0 00 ?SW 21:42 0:00 [bdflush]
root 6 0.0 0.0 00 ?SW 21:42 0:00 [kupdate]
root 289 0.0 0.4 1284 604 ?S21:42 0:00 syslogd -m 0
root 299 0.0 0.8 1912 1104 ?S21:42 0:00 klogd
root 351 0.0 1.2 9292 1576 ?S21:42 0:00 named
root 361 0.0 0.0 00 ?Z21:42 0:00 [named ]
root 363 0.0 1.2 9292 1576 ?S21:42 0:00 named
root 364 0.0 1.2 9292 1576 ?S21:42 0:00 named
root 365 0.0 0.7 2064 936 ?S21:42 0:00 /usr/sbin/sshd
..etc
(Note PID 361)
root:~> strace nslookup sunsite.unc.edu
:
:
rt_sigaction(SIGINT, {0x4003ce78, ~[], 0x400}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x4003ce78, ~[], 0x400}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [HUP INT TERM], NULL, 8) = 0
getpid()= 2615
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
close(3)= 0
socket(PF_INET6, SOCK_STREAM, 0)= -1 ENOSYS (Function not implemented)
socket(PF_INET6, SOCK_STREAM, 0)= -1 ENOSYS (Function not implemented)
socket(PF_INET6, SOCK_STREAM, 0)= -1 EAFNOSUPPORT (Address family not
supported by protocol)--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
---Example parent/child process:
root:~> tar -xzvvf ../pkgs/zgv-5.2.tar.gz
:
:
-rw--- rus/users 1356 2000-06-01 11:46:57 zgv-5.2/INSTALL
-rw--- rus/users 17976 1994-08-23 16:09:05 zgv-5.2/COPYING
-rw--- rus/users 1077 1998-08-26 09:24:31 zgv-5.2/README.fonts
-rw--- rus/users 120 2000-04-22 22:46:49 zgv-5.2/AUTHORS
-rw--- rus/users 3714 2000-01-23 16:29:40 zgv-5.2/SECURITY
Segmentation fault (core dumped)
root:~> strace tar -xzvvf ../pkgs/zgv-5.2.tar.gz
:
:
open("zgv-5.2/COPYING", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4
write(4, "\t\tGNU GENERAL PUBLIC LICENSE"..., 9728) = 9728
read(3, "ccept this License. Therefore, "..., 10240) = 10240
write(4, "ccept this License. Therefore, "..., 8248) = 8248
close(4)= 0
utime("zgv-5.2/COPYING", [2000/12/29-20:21:16, 1994/08/23-16:09:05]) = 0
chown32("zgv-5.2/COPYING", 500, 100)= 0
write(1, "-rw--- rus/users 1077 1"..., 72-rw--- rus/users 1077
1998-08-26 09:24:31 zgv-5.2/README.fonts
) = 72
open("zgv-5.2/README.fonts", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4
write(4, "The copyright for *.bdf (taken f"..., 1024) = 1024
read(3, "\"as\nis\" without express or impli"..., 10240) = 8192
--- SIGCHLD (Child exited) ---
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
Ideas, anyone?
-Byron
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [EMAIL PROTECTED]
diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/ldt.c
Re: test13-pre6
Linus Torvalds wrote: > > Ok, there's a test13-pre6 out there now, which does a partial sync with > Alan, in addition to hopefully fixing the innd shared mapping writeback > problem for good. Thanks to Marcelo Tosatti and others.. After the page_cache_release at line 574 of vmscan.c the page is unlocked and only owned by the page cache - anything could happen. How do you know the set_page_dirty at line 581 is still hitting a valid page? -- 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: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5
Am Freitag, 29. Dezember 2000 14:38 schrieben Sie: > On Fri, 29 Dec 2000, Dieter Nützel wrote: > > your patch didn't apply clean. > > Have you another version? > > It should apply just fine. What error messages did > patch give ? > Applied #2 against my running 2.4.0-test13-pre5 + ReiserFS 3.6.23 tree and a clean test13-pre5 (test12 + test13-pre5). Same for both of them: SunWave1>patch -p0 -E -N http://www.tux.org/lkml/
memmove broken on alpha - was Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)
[ extra detail included because I have added linux-alpha and lins to the cc list] It appears that memmove is broken on the alpha architecture. memmove is used by net/sunrpc/xdr.c:xdr_decode_string to move a string 4 bytes down in memory. memmove(X-4, X, 8) should change X: 00 00 00 08 67 69 6c 62 65 72 74 64 to X: 67 69 6c 62 65 72 74 64 65 72 74 64 Instead it changes it to X: 65 72 74 64 65 72 74 64 65 72 74 64 This is my first time in alpha assembler, but it looks fairly readable and the comments help Working from arch/alpha/lib/memmove.S As the two regions overlap, it doesn't fall back on memcpy, As the two regions are not co-aligned so it jumps to $misaligned. Now the code in $misaligned, like all the code in memmove.S seems to move a block of memory starting at the top, and moving downwards. But in this example, we need to start at the bottom and move upwards. Currently the code falls back on memcpy : if (dest+n <= src || dest >= src + n) However if should also fall back on memcpy: if (dest <= src) So the test should be: if (dest <= src || dest >= src + n) which I think translates to the following patch: --- arch/alpha/lib/memmove.S2000/12/30 01:59:28 1.1 +++ arch/alpha/lib/memmove.S2000/12/30 01:59:49 @@ -17,7 +17,7 @@ memmove: addq $16,$18,$4 addq $17,$18,$5 - cmpule $4,$17,$1/* dest + n <= src */ + cmpule $16,$17,$1 /* dest <= src */ cmpule $5,$16,$2/* dest >= src + n */ bis $1,$2,$1 NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i810 audio fixes for 2.4.0-test13-pre5
> This patch addresses three problems in the i810-audio driver for > 2.4.0-test13-pre5. I will be happy to split it if someone doesn't like > part of it. (I see pre6 just popped out, there are no changes to this > driver in pre6.) > 1) "DMA overrun on send" - this contains a patch from Tjeerd Mulder that >prevents almost all of this. I still get an occasional one during >heavy video activity, the driver was unusable before. (This is a smaller >patch than the previous flamed patch, it does no format conversion.) Yeah I have Tjeerd's patches and no quibbles with them > 3) Add a module parameter to supress powercycling the DACs on rate change - >This causes a big pop on the outputs at least for the CS4299 codec in >the emachines etower 700, probably others. I honestly can't find a >reason to power cycle the DACs. There's nothing in the AC97 spec >that suggests it should be done. The code is common to OSS and ALSA. >I left the old behavior as the default. Maybe later the default should >change if it turns out that everyone wants to force the parameter to >zero. What I would love someone to do (hint ;)) is to move the set_dac_speed set_adc_speed powerup_amp powerdown_amp type stuff into the ac97_codec - actually have a codec_ops in the AC97 for each type. - To unsubscribe from this list: send 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-pre6
On Fri, 29 Dec 2000, Alexander Viro wrote: > > Two examples: devices and bitmaps-in-pagecache trick. But both belong to > 2.5, so... Also, they can easily be done with a private inode, if required. So even in 2.5.x this may not be a major problem. > BTW, nice timing ;-) -pre6 appeared 5 minutes after I've started testing > sane-s_lock patch (SMP-safe lock_super() and friends, refcount on superblocks, > death of mount_sem, beginning of SMP-safe super.c). Oh, well... > > Oblock_super(): what the hell is wait_on_super() doing in fsync_file()? > It gives absolutely no warranties - ->write_super() can easily block, so > it looks very odd. A lot of the superblock locking has been odd. It should probably be a lock_super() + unlock_super(). At least that's what sync_supers() does. > BTW, while we are dropping the junk from vm_operations_struct, could we lose > ->protect() and ->wppage()? Sure. I think sync() and unmap() fall under that heading too - it used to do a msync(), but that was before we handled dirty pages directly, so... 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: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)
On Sat, 30 Dec 2000, Neil Brown wrote: > On Friday December 29, [EMAIL PROTECTED] wrote: > > On Sat, 30 Dec 2000, Neil Brown wrote: > > > > > > So where did the gilbertd directory go ? > > It suffered the curse of the 8-character file name Ah well spotted! It also happens to 12 byte names. > Could you > gdb vmlinux > disassemble xdr_decode_string > disassemble memmove A job for tomorrow. > and see if the code looks right? > > You might like to try: > > 1/ move gilbertd to gilbertdd and see if you can then access it over > nfs. Yep - it starts working. > 2/ create a file called "ertdertd" and see if you get that when you > try to access gilbertd Hehe yes; accessing gilbertd gives you the contents or ertdertd. The server architecture is Alpha. (Client Sparc and x86). Dave -- Have a happy GNU millennium! -- / Dr. David Alan Gilbert | Running GNU/Linux on | Happy \ \ gro.gilbert @ treblig.org | Alpha, x86, ARM and SPARC | In Hex / \ ___|___ http://www.treblig.org |/ - To unsubscribe from this list: send 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: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)
On Friday December 29, [EMAIL PROTECTED] wrote: > On Sat, 30 Dec 2000, Neil Brown wrote: > > > > So where did the gilbertd directory go ? It suffered the curse of the 8-character file name > > > > Can you get a tcpdump (-s 1024) of the network traffic while this is > > happening? > > Yep; to avoid posting to the list I've put it at: > http://www.treblig.org/nfs_bug_netlog > > its 14K and is the output of: > > /usr/sbin/tcpdump -vv -x -s 1024 host sol and tardis > /tmp/netlog 2>&1 > Well.. The trace contains a number of lookup requests. For example, there is a lookup of "samba" which contains the encoded file name: 0005 7361 6d62 6100 s a m b a The " 0005" is the file name length. The corresponding part of the lookup request for gilbertd looks like: 6572 7464 6572 7464 0072 7464 e r t d e r t dr t d Note there is no leading length count. This is not actually surprising when you look at net/sunrpc/xdr.c:xdr_decode_string If the length of the string is a multiple of 4, there is no spare following byte to be a nul terminator for the string, so the whole string is copied back 4 bytes using memmove. This change takes place in the actual packet in the network buffer which is why tcpdump sees it's effect. But you would expect to see: 6769 6c62 6572 7464 0072 7464 g i l b e r t dr t d but you don't. Why? My only guess is that memmove is doing the wrong thing, and moving from the end of the string instead of from the start. What architecture are you doing this on? Your signature lists 4!:-) Could you gdb vmlinux disassemble xdr_decode_string disassemble memmove and see if the code looks right? You might like to try: 1/ move gilbertd to gilbertdd and see if you can then access it over nfs. 2/ create a file called "ertdertd" and see if you get that when you try to access gilbertd > Thanks, > > Dave > > -- > Have a happy GNU millennium! -- > / Dr. David Alan Gilbert | Running GNU/Linux on | Happy \ > \ gro.gilbert @ treblig.org | Alpha, x86, ARM and SPARC | In Hex / > \ ___|___ http://www.treblig.org |/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
VIA IDE controller strangeness (2.4.0-test12/test13-pre5)
---(CC answer please)--- I'm having a strange problem with my IDE controller. I believe (and that's what Windows and the m/b manufaturer -- PC Chips -- say) that I have a VIA PCI BusMaster IDE controller, and I've had some strange history with it. I've asked many people before on various help services, and I was able to fix my problem with the 2.2 series, but now my fix does not work. THE PROBLEM: Ever since the 2.2 kernel series (I remeber this working properly in 2.0.36, without the conflicts), I would get hdc: lost interrupt during boot up, and my system would take bloody ages to boot up and load a CD. I tracked it down to a strange IRQ conflict in which Linux would try to assign both the primary and secondary IDE channels IRQ 14, causing IRQ conflicts galore. I was able to fix this by giving the kernel ide1=0x170,0x376,15 at boot time. This has worked for 2.2.12-.17 and Alan's 2.2.18pre21 (I haven't compiled the official 2.2.18 yet, but I'm sure it will work). I wanted to try the new 2.4.0-test series, and the first I tried was -test11, and from what I recall (other things weren't working properly then), this fix still worked, but now, with -test12, I am now getting the following error repeated for a very long time (then I reboot) with the same parameters: ide_dmaproc: chipset supported ide_dma_lostirq func only: 13 hdb: lost interrupt Also, I get "spurious 8259A interrupt: IRQ 7" if I leave it for a while. I tried -test13-pre5 on somebody on #KernelNewbies' suggestion, and I get the same error. Scrolling up, I see that the kernel messages show that ide0 is on IRQ 14 and ide1 is on 15. I noticed that hda is using DMA, and hdb is using UDMA33, but I don't believe that that is the problem. THE QUESTION: - How do I fix this, or is it a (un)known problem in the newer development versions? If you have the answer, could you please CC me as well for I don't subscribe to this mailing list (sorry!). Thanks a bunch. -- | Evan A. Thompson | He's more fun than trying to skinny | | [EMAIL PROTECTED] | dip in the beach in winter...| | http://evaner.penguinpowered.com |...in Winnipeg. | | ICQ: 2233067 / AIM + MSN: Evaner517 | (GnuPG key avaiable upon request.) | - To unsubscribe from this list: send 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-pre6
On Fri, 29 Dec 2000, Linus Torvalds wrote: > Al: this changes "mapping->host" to be truly defined as a pointer to the > inode that owns the mapping. That's how every user actually _used_ the > host pointer, so this cleans those up to not need any casts. The main > reason, however, is that we needed to have some FS-level anchor for dirty > pages in order to get the correct sync() semantics. If you think it's > worth it to have a notion of an anonymous host we need to add something > else. Two examples: devices and bitmaps-in-pagecache trick. But both belong to 2.5, so... BTW, nice timing ;-) -pre6 appeared 5 minutes after I've started testing sane-s_lock patch (SMP-safe lock_super() and friends, refcount on superblocks, death of mount_sem, beginning of SMP-safe super.c). Oh, well... Oblock_super(): what the hell is wait_on_super() doing in fsync_file()? It gives absolutely no warranties - ->write_super() can easily block, so it looks very odd. BTW, while we are dropping the junk from vm_operations_struct, could we lose ->protect() and ->wppage()? Both are never used and never defined. I can send a diff, indeed, but ed include/linux/mm.h
[PATCH] i810 audio fixes for 2.4.0-test13-pre5
This patch addresses three problems in the i810-audio driver for
2.4.0-test13-pre5. I will be happy to split it if someone doesn't like
part of it. (I see pre6 just popped out, there are no changes to this
driver in pre6.)
1) "DMA overrun on send" - this contains a patch from Tjeerd Mulder that
prevents almost all of this. I still get an occasional one during
heavy video activity, the driver was unusable before. (This is a smaller
patch than the previous flamed patch, it does no format conversion.)
2) Enable codec rate adaption - the current rate setting functions attempt
to get the codecs to rate adapt, but neglect to turn on the bit in the
"Extended Audio Status and Control Register" that allows the codec to
actually adapt. (Audio Codec '97, Rev 2.2, Intel, section 5.8.2)
This allows audio of other than 48kHz if the codec supports it.
3) Add a module parameter to supress powercycling the DACs on rate change -
This causes a big pop on the outputs at least for the CS4299 codec in
the emachines etower 700, probably others. I honestly can't find a
reason to power cycle the DACs. There's nothing in the AC97 spec
that suggests it should be done. The code is common to OSS and ALSA.
I left the old behavior as the default. Maybe later the default should
change if it turns out that everyone wants to force the parameter to
zero.
After this is applied I will followup with another patch that
adds /proc/driver/i810-audio/... support like the via82cxxx driver.
I don't know is user's need it, but it sure helps debugging and
figuring out what sort of hardware is really in the computer.
--- clean-linux/drivers/sound/i810_audio.c Wed Nov 8 19:09:50 2000
+++ linux/drivers/sound/i810_audio.cFri Dec 29 18:10:19 2000
@@ -102,6 +102,7 @@
static int ftsodell=0;
static unsigned int clocking=48000;
+static int cycle_power=1;
#define ADC_RUNNING1
@@ -382,7 +383,7 @@
static unsigned int i810_set_dac_rate(struct i810_state * state, unsigned int rate)
{
struct dmabuf *dmabuf = >dmabuf;
- u32 dacp;
+ u32 dacp=0;
struct ac97_codec *codec=state->card->ac97_codec[0];
if(!(state->card->ac97_features&0x0001))
@@ -410,14 +411,23 @@
if(rate != i810_ac97_get(codec, AC97_PCM_FRONT_DAC_RATE))
{
+ u16 extended_status = i810_ac97_get(codec, AC97_EXTENDED_STATUS);
+
+ /* enable variable rate audio */
+ if ( !(extended_status&1)) {
+ i810_ac97_set(codec, AC97_EXTENDED_STATUS, extended_status |
+1);
+ }
+
/* Power down the DAC */
- dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
- i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0200);
+ if ( cycle_power) {
+ dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
+ i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0200);
+ }
/* Load the rate and read the effective rate */
i810_ac97_set(codec, AC97_PCM_FRONT_DAC_RATE, rate);
rate=i810_ac97_get(codec, AC97_PCM_FRONT_DAC_RATE);
/* Power it back up */
- i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
+ if ( cycle_power) i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
}
rate=(rate * 48000) / clocking;
dmabuf->rate = rate;
@@ -432,7 +442,7 @@
static unsigned int i810_set_adc_rate(struct i810_state * state, unsigned int rate)
{
struct dmabuf *dmabuf = >dmabuf;
- u32 dacp;
+ u32 dacp=0;
struct ac97_codec *codec=state->card->ac97_codec[0];
if(!(state->card->ac97_features&0x0001))
@@ -460,14 +470,22 @@
if(rate != i810_ac97_get(codec, AC97_PCM_LR_DAC_RATE))
{
+ u16 extended_status = i810_ac97_get(codec, AC97_EXTENDED_STATUS);
+ /* enable variable rate audio */
+ if ( !(extended_status&1)) {
+ i810_ac97_set(codec, AC97_EXTENDED_STATUS, extended_status |
+1);
+ }
+
/* Power down the ADC */
- dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
- i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0100);
+ if ( cycle_power) {
+ dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
+ i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0100);
+ }
/* Load the rate and read the effective rate */
i810_ac97_set(codec, AC97_PCM_LR_DAC_RATE, rate);
rate=i810_ac97_get(codec, AC97_PCM_LR_DAC_RATE);
/* Power it back up */
- i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
+ if ( cycle_power) i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
}
rate = (rate * 48000) / clocking;
test13-pre6
Ok, there's a test13-pre6 out there now, which does a partial sync with Alan, in addition to hopefully fixing the innd shared mapping writeback problem for good. Thanks to Marcelo Tosatti and others.. I've pounded on the shared dirty page writeback logic quite a bit, and verified (by doing timings with "strace -ttT") that it should do the right thing with sync/fsync/fdatasync/msync(MS_ASYNC)/msync(MS_SYNC). The reason I'm fairly confident that the problem is gone for good is that the dirty page handling is now quite integral to the whole address space code, and it fell out rather nicely from some mapping host cleanups. Al: this changes "mapping->host" to be truly defined as a pointer to the inode that owns the mapping. That's how every user actually _used_ the host pointer, so this cleans those up to not need any casts. The main reason, however, is that we needed to have some FS-level anchor for dirty pages in order to get the correct sync() semantics. If you think it's worth it to have a notion of an anonymous host we need to add something else. Stephen: mind trying your fsync/etc tests on this one, to verify that the inode dirty stuff is all done right? Marco d'Itri and everybody else who has seen innd problems (or other shared map problems): can you verify that test13-pre6 works for you? Linus - pre6: - Marc Joosen: BIOS int15/e820 memory query: don't assume %edx unchanged by the BIOS. Fixes at least some IBM ThinkPads. - Alan Cox: synchronize - Marcelo Tosatti & me: properly sync dirty pages - Andreas Dilger: proper ext2 compat flag checking - 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/
Re: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)
On Sat, 30 Dec 2000, Neil Brown wrote: > > So where did the gilbertd directory go ? > > Is there any chance that /home/gilbertd is a mount point? Nope; from the server: [root@tardis gcc]# mount /dev/hdc6 on / type ext2 (rw) none on /proc type proc (rw) /dev/hdc3 on /discs/c3 type ext2 (ro) /dev/hdc4 on /discs/c4 type ext2 (rw) /dev/hdc7 on /discs/c7 type ext2 (rw) /dev/hdc8 on /discs/c8 type ext2 (rw) (/home is actually /discs/c4/home). /etc/exports is: /discs/c4 sol(rw,no_root_squash,insecure) gort klaatu oaktree(rw,no_root_squash,insecure) /discs/c3 sol(rw,no_root_squash,insecure) gort klaatu oaktree(rw,no_root_squash,insecure) /mnt/dvd sol(rw,no_root_squash,insecure) Server is tardis, client is sol. > Can you get a tcpdump (-s 1024) of the network traffic while this is > happening? Yep; to avoid posting to the list I've put it at: http://www.treblig.org/nfs_bug_netlog its 14K and is the output of: /usr/sbin/tcpdump -vv -x -s 1024 host sol and tardis > /tmp/netlog 2>&1 Thanks, Dave -- Have a happy GNU millennium! -- / Dr. David Alan Gilbert | Running GNU/Linux on | Happy \ \ gro.gilbert @ treblig.org | Alpha, x86, ARM and SPARC | In Hex / \ ___|___ http://www.treblig.org |/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
File I/O benchmarks for various kernel
I've been using dbench a lot lately for reality checks on various kernel mods, and out of interest I decided to run benchmarks with it on a few different kernel versions. I noticed a major difference between 2.2 and 2.4 kernels - 2.4 is running the benchmarks about 3 times faster than 2.2, and it seems to be getting faster with each step towards 2.4.0. On the other hand, 2.2 seems to be getting slower. Here are a few points on the curve. Test machine: 64 meg, 500 Mhz K6, IDE, Ext2, Blocksize=4K Test: dbench 48 Kernel Throughput Elapsed Time -- -- 2.2.16 3.1 MB/sec 33 min 53 secs 2.2.18 2.8 MB/sec 38 min 10 secs 2.2.19-pre32.7 MB/sec 39 min 44 secs 2.4.0-test12 7.3 MB/sec 14 min 32 secs 2.4.0-test13-pre4 9.5 MB/sec 11 min 06 secs 2.4.0-test13-pre5 10.8 MB/sec 9 min 48 secs Dbench was written by Andrew Tridgell to measure disk performance under simulated samba network traffic load. The '48' means it's simulating the file access patterns of 48 network clients, all doing heavy io at the same time. For anyone interested in checking these results on their own hardware, dbench is available at: ftp://samba.org/pub/tridge/dbench/dbench-1.1.tar.gz -- 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: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 08:06:57PM +0100, Andrea Arcangeli wrote:
> On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote:
> > Your cgi will keep the other CPU occupied, or run two of them. thttpd has
> > superb scaling properties compared to say apache.
>
> I think with 8 CPUs and 8 NICs (usual benchmark setup) you want more than 1 cpu
> serving static data and it should be more efficient if it's threaded and
> sleeping in accept() instead of running eight of them (starting from sharing
> tlb entries and avoiding flushes probably without the need of CPU binding).
Ok - my point was (and maybe I'm just misunderstanding something):
Multiple threads do send() etc. -> this gets serialized by the kernel
anyway, as TCP checksums are done in the kernel as well as the NIC
driving etc. If the TCP layer cannot parallelize checksum calculation.
One thread does many send()'s -> this also gets serialized by the
kernel.
Or: one thread vs. many threads reading from the disk -> makes no difference
since there is *one* buffer layer, one driver, one disk etc. etc.
My question is: Does it change anything in the way the TCP stack
can crank out packets, if I change the number of threads in user-space
making the system calls ?
Does the fine-grained locking allow multiple user-space threads to
actually have TCP checksums etc. done on multiple CPUs concurrently,
and is it true that this will not happen if I have one user-space
thread doing non-blocking send() calls ?
Thanks,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
To unsubscribe from this list: send 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 + char-major-145??
On Fri, 29 Dec 2000 14:07:57 -0700,
Frank Jacobberger <[EMAIL PROTECTED]> wrote:
>modprobe: Can't locate module char-major-145
>
>From /usr/src/linux/Documentation/devices.txt
>
>10 charNon-serial mice, misc features
>145 = /dev/hfmodem Soundcard shortwave modem control {2.6}
That is major 10, minor 145. Search /145 *char/ to find char-major-145.
-
To unsubscribe from this list: send 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: How to write patches
Jeff's descriprion is very informative, but his emphasis is somewhat different from what I find difficult with patches. First, for the life of me I was unable to remeber which argument goes first (DaveM was mad every time). Second, I kept forgetting to keep the base tree a diff against that instead of the latest tree. So, here is the patch release cycle in my view, with all small details. 1. I pick a "base" tree which I will hack on. Suppose that we start with 2.2.17-pre22. So, I download linux-2.2.16.tar.bz2 from Linus place and patch-pre22.bz2 from Alan's place. THESE MUST BE SAVED after I unpack them. 2. I unpack. Note that I have base release in the directory name. bzip -d < linux-2.2.16.tar.bz2| tar xf - mv linux linux-2.2.17-pre22 bzip -d < patch-pre22.bz2| patch -d linux-2.2.17-pre22 -p1 3. One way or another, I make two trees, one of which is "base" and another is "work". mkdir linux-2.2.17-pre22-p3 (cd linux-2.2.17-pre22 && tar cf - .)| (cd linux-2.2.17-pre22-p3 && tar xf -) 4. Hack cd linux-2.2.17-pre22-p3 make oldconfig (make dep && make bzImage) > build.out 2>&1 ... etc. The step #4 will take some time, and kernel will get developed while we sit on it. Normally it takes me anywhere from 3 weeks to 3 months to come up with something useable. 5. Time to diff and submit, but Oops, Linus published 2.2.17! Now you will see how it all REALLY works. 5a. Unpack bzip -d < linux-2.2.17.tar.bz2| tar xf - mv linux linux-2.2.17 6. Diff your base tree and your changed tree. Do not settle for .orig files! Diff whole thing! 6a. Get dontdiff from Tigran, it's helpful wget http://www.moses.uklinux.net/patches/dontdiff 6b. Diff, but notice the argument order!! diff -urN --exclude-from=dontdiff \ linux-2.2.17-pre22 linux-2.2.17-pre22-p3 > linux-2.2.17-pre22-p3.diff 6c. In most cases you need to remove junk from your diff, even with dontdiff. 7. Apply your diff to the new tree (remember, never touch the base tree): mkdir linux-2.2.17-p3 (cd linux-2.2.17 && tar cf - .)| (cd linux-2.2.17-p3 && tar xf -) patch -d linux-2.2.17-p3 -p1 < linux-2.2.17-pre22-p3.diff If I am lucky, my patch applies cleanly or with a small fuzz factor. But otherwise there may be a conflict that I shall resolve by hand: find linux-2.2.17-p3 -name '*.rej' # perhaps cat something.rej >> something && vi something This part is actually important. If I sent linux-2.2.17-pre22-p3.diff to Alan, he would try to apply it against then-current 2.2.17 (if not 2.2.18-pre2), get the same conflict, and dump the patch into the void. Always resolve yourself, do not ride the maintainer. 8. Now I can send the patch to Alan and wait. 9. Once my patch is tentatively applied, say, in 2.2.18-pre2, I re-download it, and do the whole thing again to make sure that it was applied right. Alan has a habit of editing patches on the fly, so I must keep tabs on it. 10. By this time 2.2.17-pre22 base are obsolete so we may delete them (but evacuate good .config first or you'd start from defconfig again): cp linux-2.2.17-pre22-p3/.config linux-2.2.18-pre3/ rm -rf linux-2.2.17-pre22 linux-2.2.17-pre22-p3 # Sometimes I keep linux-2.2.17-pre22-p3.diff a little longer # after the base moved on, for the sake of slower paced collegues. And the ball just keeps rolling. -- Pete - To unsubscribe from this list: send 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 and poor reponse to RT-scheduled processes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message <[EMAIL PROTECTED]>, Greg Maxwell wrote: - -> You are running IDE aren't you? - -> - -> Enable DMA and/or unmask interupts. D'oh! Thanks to Greg for the clue-by-four! I *am* running IDE and I had both DMA (due to misreading of kernel boot message) and interrupt unmasking (since I had forgotten that one) off I had assumed that DMA was on from the mention of it in kernel messages (which on closer reading do indicate CMOS/BIOS configured default modes, not what the kernel is using), and the lack of an explicit message on the order of "I know it's there, but I'm not going to use it all the same" 8-) Now my box behaves much more reasonably... I'll just have to beat harder on it and see what happens. Thank for the help, - --rafal - Rafal Boni [EMAIL PROTECTED] PGP key C7D3024C, print EA49 160D F5E4 C46A 9E91 524E 11E0 7133 C7D3 024C Need to get a hold of me? http:[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE6TQgOEeBxM8fTAkwRArCFAKDVrzaWxGtRFR0pbyNwvIF20bOSiwCfdhg9 wK1ZAhaCfK5qcrQezDECiK4= =9x6E -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre5
On Fri, 29 Dec 2000, David S. Miller wrote: > > For my development testing, I'm running a _heavily_ hacked >kernel. One of these hacks is to pull the wait_queue_head out of >struct page; the waitq-heads are in a separate allocated area of >memory, with a waitq-head pointer embedded in the page structure >(allocated/initialised in free_area_init_core()). This gives a >page structure of 60bytes, giving me one free double-word to play >with (which I'm using as a pointer to a release function). > > Not something like those damn Solaris turnstiles, no please If you want to have a release function, please just use "page->mapping", which gives you much more, including memory pressure indicators etc. Now _that_ can be useful for doing things like slab caches. 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: module programing
On Sat, 30 Dec 2000, Sourav Sen wrote: > Any good updated for module programing? Rubini seems to be too outdated :( http://www.kernelnewbies.org has (what should be) an up to date list of links to both online books/documents & dead tree style books. regards, Davej. -- | Dave Jones.http://www.suse.de/~davej | 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/
Re: [linux-fbdev] new linux_logo16
On Sun, 24 Dec 2000, Geert Uytterhoeven wrote:
> Since the 16-color logo was broken a while ago, we need a new one for 2.4.0.
> The main limitation is that we no longer can choose the palette, but have to
> use the standard VGA 16-color palette.
And here's a patch for it.
Changes:
- Replace the logo.
- Remove linux_logo16_{red,green,blue}.
- We need to load the logo palette for the 256-color logo only.
- Since the 16-color logo uses the VGA console palette, we no longer need to
use pixel values 16-31 for screens that have >= 32 but < 256 colors.
- Remove a superfluous #include . The logo code was moved
from drivers/char/console.c to drivers/video/fbcon.c eons ago.
I tested the patch with vga16fb on an ia32 box. Comments?
--- linux-2.4.0-test13-pre5/include/linux/linux_logo.h Wed Sep 30 23:16:33 1998
+++ logo16-2.4.0-test13-pre5/include/linux/linux_logo.h Fri Dec 29 22:20:02 2000
@@ -1024,422 +1024,407 @@
#ifdef INCLUDE_LINUX_LOGO16
-unsigned char linux_logo16_red[] __initdata = {
-0x00, 0x90, 0xb0, 0x9c, 0xf7, 0x35, 0x83, 0xa5,
-0x65, 0x8f, 0x98, 0xc9, 0xdb, 0xe1, 0xe7, 0xf8
-};
-
-unsigned char linux_logo16_green[] __initdata = {
-0x00, 0x90, 0xb0, 0x9c, 0xf7, 0x2e, 0x83, 0xa5,
-0x65, 0x6e, 0x98, 0x89, 0xbf, 0xac, 0xda, 0xf8
-};
-
-unsigned char linux_logo16_blue[] __initdata = {
-0x00, 0x90, 0xaf, 0x9c, 0xf7, 0x2b, 0x82, 0xa5,
-0x65, 0x41, 0x97, 0x1e, 0x60, 0x29, 0xa5, 0xf8
-};
-
unsigned char linux_logo16[] __initdata = {
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xa1, 0x11, 0x11,
-0x61, 0x16, 0x66, 0x66, 0x11, 0x11, 0x11, 0x11,
-0x11, 0x11, 0x1a, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0xa8, 0x00, 0x00,
-0x00, 0x00, 0x00, 0x87, 0x77, 0x77, 0x77, 0x77,
-0x77, 0x77, 0x73, 0x33, 0x33, 0x3a, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xa3, 0x33, 0x33, 0x00, 0x00, 0x00,
-0x00, 0x00, 0x00, 0x00, 0x77, 0x77, 0x77, 0x77,
-0x77, 0x27, 0x77, 0x77, 0x77, 0x33, 0x3a, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xa3, 0x33, 0x33, 0x30, 0x00, 0x00, 0x00,
-0x00, 0x00, 0x55, 0x50, 0x08, 0x33, 0x77, 0x77,
-0x77, 0x72, 0x72, 0x27, 0x77, 0x77, 0x33, 0x33,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xa3, 0x33, 0x33, 0x77, 0x00, 0x00, 0x00, 0x00,
-0x00, 0x00, 0x58, 0x85, 0x00, 0x11, 0x11, 0xaa,
-0xa3, 0x37, 0x77, 0x72, 0x22, 0x22, 0x77, 0x73,
-0x33, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xa3,
-0x33, 0x37, 0x77, 0x33, 0x00, 0x00, 0x00, 0x00,
-0x00, 0x00, 0x56, 0x85, 0x00, 0x06, 0x66, 0x11,
-0x11, 0x1a, 0xa3, 0x37, 0x77, 0x72, 0x22, 0x77,
-0x73, 0x33, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x33,
-0x33, 0x33, 0x33, 0x30, 0x00, 0x00, 0x00, 0x00,
-0x00, 0x00, 0x55, 0x00, 0x00, 0x06, 0x66, 0x66,
-0x66, 0x66, 0x11, 0x1a, 0xa3, 0x77, 0x72, 0x22,
-0x77, 0x73, 0x3a, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0x33,
-0x33, 0x33, 0x33, 0xa0, 0x00, 0x00, 0x00, 0x00,
-0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x11, 0x11,
-0x66, 0x66, 0x66, 0x66, 0x11, 0xa3, 0x77, 0x22,
-0x22, 0x77, 0x33, 0x33, 0xaa, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0x33, 0x33,
-0x33, 0x3a, 0xa1, 0x10, 0x00, 0x00, 0x00, 0x00,
-0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x77, 0x33,
-0xaa, 0x11, 0x16, 0x66, 0x66, 0x61, 0x1a, 0x37,
-0x22, 0x22, 0x77, 0x33, 0x3a, 0xaa, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0xa3, 0x33, 0x33, 0x33,
-0x3a, 0xa1, 0x11, 0x10, 0x00, 0x00, 0x00, 0x00,
-0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x02, 0x22,
-0x22, 0x77, 0x3a, 0x11, 0x66, 0x66, 0x66, 0x1a,
-0x37, 0x22, 0x22, 0x77, 0x33, 0x3a, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0x33, 0x33, 0x3a,
-0xa1, 0x11, 0x11, 0x10, 0x00, 0x00, 0x50, 0x00,
-0x00, 0x05, 0x80, 0x50, 0x00, 0x00, 0x07, 0x72,
-0x22, 0x22, 0x22, 0x73, 0xa1, 0x66, 0x66, 0x61,
-0x1a, 0x77, 0x22, 0x27, 0x73, 0x33, 0xaa, 0xaa,
-0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0x33, 0x3a, 0xaa,
-0x11, 0x11, 0x1a, 0xa0, 0x08, 0x71, 0x05, 0x00,
-0x00, 0x12, 0x22, 0x50, 0x00, 0x00, 0x07, 0x77,
-0x77, 0x72, 0x22, 0x22, 0x27, 0x31, 0x16, 0x66,
-0x61, 0x13, 0x77, 0x22, 0x77, 0x33, 0x3a, 0xaa,
-0xaa, 0xaa, 0xaa, 0xa3, 0x33, 0x33, 0xaa, 0xa1,
-0x11, 0x1a, 0x33, 0x70, 0x07, 0x2e, 0x70, 0x00,
-0x01, 0x44, 0x42, 0x60, 0x00, 0x00, 0x02, 0x22,
-0x22, 0x22, 0x22, 0x22, 0x22, 0x27, 0x31, 0x66,
-0x66, 0x61, 0xa3, 0x72, 0x22, 0x77, 0x33, 0xaa,
-0xaa, 0xaa, 0xa3, 0x33, 0x33, 0xaa, 0xaa,
Re: 2.4.0-test12-reiserfs oops in
Try test13-pre5, it has this fixed. 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: test13-pre5
Date: Fri, 29 Dec 2000 15:46:22 + (GMT) From: Mark Hemment <[EMAIL PROTECTED]> For my development testing, I'm running a _heavily_ hacked kernel. One of these hacks is to pull the wait_queue_head out of struct page; the waitq-heads are in a separate allocated area of memory, with a waitq-head pointer embedded in the page structure (allocated/initialised in free_area_init_core()). This gives a page structure of 60bytes, giving me one free double-word to play with (which I'm using as a pointer to a release function). Not something like those damn Solaris turnstiles, no please 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: test13-pre5 + char-major-145??
In article <[EMAIL PROTECTED]> you wrote: > What may be calling this? Any advice where to go ferreting? Somebody may try to open the device file. Greetings Bernd - To unsubscribe from this list: send 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: UDP ports 800-n used by NFS client in 2.2.17
On Friday December 29, [EMAIL PROTECTED] wrote: > Does anyone know what causes netstat to show UDP port 800 > as active on a Linux NFS client with 2.2.17 kernel when an NFS filesystem > is mounted? > > Using Debian Linux 2.2 with Kernel 2.2.17 with one NFS filesystem mounted, > I see > the following: > > rsh@lithium [3]$ netstat -n -a -u > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address > udp0 0 0.0.0.0:8000.0.0.0:* > > If I unmount the NFS Filesystem, the UDP port disappears. That will be the local port that is used to talk to the NFS server. > > It appears that each NFS mounted filesystem uses a separate UDP > port, and that they count down from port 800. I.e. the first > mount uses UDP port 800, the second UDP port 799. > > "lsof -i" doesn't show this port belonging to any process, and the "-p" > option to netstat > doesn't show any process info either. I assume that this means that it's a > kernel thing > rather than a process level thing. > > A network sniff while mounting and umounting the NFS filesystem > doesn't show any traffic on UDP port 800 - I just see portmapper, mountd > and nfs > traffic. While mounting and unmounting you might not (I'm not sure) but while accessing the filesystem you definately should. You say that you see "nfs" traffic. Each packet has a source port and a destintation port. For an NFS request, the destination port will be 2049 on the server, the source port will be 800 (or 799 ...) on the client. > > Does anyone know what this is or where I can look in the source for more info? > I've searched /usr/src/linux/fs/nfs/*.c for 800 and 320 (800 in hex) > without success. Check out net/sunrpc/xprt.c:xprt_bindresvport NeilBrown > > Roy Hills > -- > Roy HillsTel: +44 1634 721855 > NTA Monitor Ltd FAX: +44 1634 721844 > 14 Ashford House, Beaufort Court, > Medway City Estate, Email: [EMAIL PROTECTED] > Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send 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: Bugs in knfsd -- Problem re-exporting an NFS share
On Friday December 29, [EMAIL PROTECTED] wrote: > Hi -- could you please CC me if you reply to this mail. > > My problem is that I get an error when setting up the following > configuration: > > A: /exports/A - Redhat 7.0 > B1/B2: mount /exports/A on /export/A from A - Redhat 6.2 > C: mount /exports/A on /mnt/A from B1 or B2 - Redhat 6.2 > > I use knfsd/nfs-utils on each machine. > > bash# ls /mnt/A > /mnt/A/A.txt: No such file or directory > This is not a supported configuration. You cannot export NFS mounted filesystems with NFS. The protocol does not cope, and it implementation doesn't even try. NFS is for export local filesystems only. > > I searched for a while on deja.com, and there seemed to be some indications > that knfsd was bugged and that using the user-mode code would work. > However, no one replied specifically to my message, so I'm still not sure. > > BTW, what I tried to do was to set up a HA configuration of machines B1/B2 > using A as a "shared disk". > This is just to try out the HA software without buying more > hardware. Try "nbd" the network block device. That should be able to give a more realistic imitation of a share disk. NeilBrown > > Thanks in advance for any help! > > Best regards, > Frank Olsen > > PS Happy new year! > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, 29 Dec 2000, Daniel R. Kegel wrote: > Andrea Arcangeli wrote: > > Petru Paler wrote: > > > 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... > > > > It can't scale in SMP. > > thttpd is i/o bound, not CPU bound, so there's no need for SMP scaling. > It's an effective little server as long as the active document > tree fits in RAM. > > If it ain't broke, don't tell people how to fix it :-) > > (If for some reason SMP scaling was desirable, the thttpd > way to do it would be to introduce one thread for each > CPU, and have each thread run the same select() loop.) One could possibly cheat and use fork() instead of using threads. Do your listen() before forking..then both get the listener socket.. Threads aren't always the answer, in this case it wouldn't probably gain you anything over just doing a fork() on SMP. Especially if you got not good reason to be sharing data that closely, which I don't think thttpd would. Aaron - To unsubscribe from this list: send 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 and poor reponse to RT-scheduled processes?
On Fri, Dec 29, 2000 at 03:45:23PM -0500, Rafal Boni wrote: [snip] > The box in question is running the linux-ha.org heartbeat package, > which is a RT-scheduled, mlock()'ed process, and as such should > get as good service as the box is able to mange. Often, under > high disk (and/or MM) loads, the box becomes unreponsive for a > period of time from ~ 1 sec to a high of ~ 2.8sec. [snip] You are running IDE aren't you? Enable DMA and/or unmask interupts. man hdparm Good luck. - To unsubscribe from this list: send 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] filemap_fdatasync & related changes
In article <[EMAIL PROTECTED]>, Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > >Ok, here it is. > >I hope I got all locking and all special cases right. > >Comments ? Looks good. There's a few things this misses, the worst of which were all my bugs in the original description. Things like "don't unlock the page after calling writepage, becasue writepage will do it on its own". Details like that. The worst problem actually ends up being the fact that the global sync() doesn't work, after all, because if it's associated with syncing the inodes it will only sync the dirty page list for inodes that are dirty. Now, this probably doesn't show up in testing, because mostly if you have dirty pages the inode too _will_ be dirty, but that only makes the bug more insidious. So I'll work on this a bit to polish up these problems, but on the whole this is all fine. 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/
test13-pre5 + char-major-145??
Please help me explain why I'm getting the following
modprobe reply on boot up after kernel test13-pre5
loads:
modprobe: Can't locate module char-major-145
>From /usr/src/linux/Documentation/devices.txt
10 charNon-serial mice, misc features
145 = /dev/hfmodem Soundcard shortwave modem control {2.6}
My modules.conf:
---
alias eth0 rtl8139
alias eth1 rtl8139
alias parport_lowlevel parport_pc
alias sound-slot-0 emu10k1
alias usb-controller usb-uhci
---
What may be calling this? Any advice where to go ferreting?
Thanks,
Frank
-
To unsubscribe from this list: send 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: NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)
On Friday December 29, [EMAIL PROTECTED] wrote: > Hi, > On the server: > > bash$ ls -l > total 21 > drwxrwxrwx 11 root root 2048 Jul 23 02:32 arm > lrwxrwxrwx 1 root root 14 Aug 22 1999 dg -> > /home/gilbertd > drwxr-xr-x 6 root root 1024 Mar 21 1999 ftp > drwx-- 5 g3oagg3oag1024 Oct 3 1999 g3oag > drwxr-xr-x 164 gilbertd gilbertd12288 Dec 29 19:42 gilbertd > > on the client: > > [root@sol home]# ls -l > ls: gilbertd: No such file or directory > total 9 > drwxrwxrwx 11 root root 2048 Jul 23 02:32 arm > lrwxrwxrwx1 root root 14 Aug 22 1999 dg -> /home/gilbertd > drwxr-xr-x6 root root 1024 Mar 21 1999 ftp > drwx--5 1000 1000 1024 Oct 3 1999 g3oag > - > > So where did the gilbertd directory go ? Is there any chance that /home/gilbertd is a mount point? Can you show us your /etc/exports, just incase there is something significant there? Can you get a tcpdump (-s 1024) of the network traffic while this is happening? NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ext2's inode i_version gone, what now? (stable branch)
I try to use the Steganographic filesystem stegfs on top of a 2.2.18 kernel, while the stegfs patch was against 2.2.14. The patch applied allmost clean, but that was easy to fix. However a real problem (for me) is that the author (whom I can not reach by email) build stegfs on top of the ext2 filesystem. There he uses ext2's inode structure and at some places reads/writes from ext2 inode's i_version. However, this is not there in ext2_fs_i.h. But I am working with source for 2.2.18 and a lot could have happend since 2.2.14. I would not have expected the inode struct to change, though. Why was it taken away? How is compatibility maintained? What could I use instead to fix the problem? Anyone who is interested in this: http://ban.joh.cam.ac.uk/~adm36/StegFS/download.html the error happens at make[3]: Entering directory `/usr/src/linux/fs/stegfs' cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o inode.o inode.c inode.c: In function `stegfs_read_inode': inode.c:1376: structure has no member named `i_version' inode.c: In function `stegfs_update_inode': inode.c:1785: structure has no member named `i_version' please cc me, I am not on this list. - To unsubscribe from this list: send 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.19pre3 and poor reponse to RT-scheduled processes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii [...Please CC me on any replies, as I'm not on the list(s)...] Folks: I was experiencing problems with 2.2.16 where the box would go out to lunch for a few seconds flushing buffer or paging at inopportune times (is there ever an opportune time for the box to become non- reponsive for 5 seconds? 8-). 2.2.19pre3 makes the behaviour much better, but I still see ~ 2sec pauses at times. I'm sending this to the MM list as well, since I believe the poor behaviour in 2.2.16 was an MM issue... I don't know where the slowdowns are happening this time around. The box in question is running the linux-ha.org heartbeat package, which is a RT-scheduled, mlock()'ed process, and as such should get as good service as the box is able to mange. Often, under high disk (and/or MM) loads, the box becomes unreponsive for a period of time from ~ 1 sec to a high of ~ 2.8sec. The test is simply running a 'dd if=/dev/zero of=/u1/big-empty-file bs=1k count=512000 && date'. Generally, the box will sieze up around the same time as the the 'dd' finishes (maybe trying to exec date?). I'd appreciate any hints at how to reduce the non-reponsiveness window down as much as possible. I haven't yet looked to see if there is a version of the low-latency patches for 2.2.18 or 19pre, but I'd appreciate other ideas on tracking this down as well. Thanks! - --rafal - Rafal Boni [EMAIL PROTECTED] PGP key C7D3024C, print EA49 160D F5E4 C46A 9E91 524E 11E0 7133 C7D3 024C Need to get a hold of me? http:[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE6TPfjEeBxM8fTAkwRAiPaAKDSp1udFSypqq838fwAjQnlFW0m2wCgtycm xF7xuBroSl3YXCTqUXGDAy0= =JHLL -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19pre3 on sparc64: Hangs on boot, "no cont in shutdown!"??
On Thu, Dec 28, 2000 at 09:59:55PM -0800, David S. Miller wrote: > > "make check_asm" should fix it. It doesn't work out of the box starting from pre3 because there are a few fields in the task struct implemented this way: struct list_head local_pages; int allocation_order, nr_local_pages; that is perfectly valid C code but I wasn't aware of the check_asm.sh sed script assumptions and so I incidentally broke sparc's `make check_asm', sorry. To make my 2.2.x tree to work on sparc64 I temporarly broken the above line in two for the time of `make check_asm'. I guess we can go with this patch for 2.2.x instead of doing the right fix ;) --- 2.2.19pre3aa4/include/linux/sched.h.~1~ Fri Dec 29 20:55:57 2000 +++ 2.2.19pre3aa4/include/linux/sched.h Fri Dec 29 21:14:32 2000 @@ -329,7 +329,8 @@ struct files_struct *files; /* memory management info */ struct mm_struct *mm; - struct list_head local_pages; int allocation_order, nr_local_pages; + struct list_head local_pages; + int allocation_order, nr_local_pages; int fs_locks; /* signal handlers */ 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/
module programing
Any good updated for module programing? Rubini seems to be too outdated :( ~sourav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
udf again ?
I recall I have asked this before but now in order to get udf working under 2.2.19pre*, I mailed the developers/maintainers about a fix. Dave wrote : >I forwarded your email to the development list: >[EMAIL PROTECTED] > >Hopefully there's a fix. I dunno, I'm still on 2.2.16. >As far as including udf support in the kernel, I >requested that back in the 2.2.14 days, and supposedly > it was going to be ... > >-Dave but why not in the kernel ? I recall that people wanted it in userspace. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] #2 VM fixes + RSS limits 2.4.0-test13-pre5 #2
Hi Linus, Alan,
Here is a second version of my patch ... it turned out that
fixing of the return value of try_to_swap_out() means that
swap_out_mm() doesn't unlock the mm->page_table_lock ...
The reason I didn't run into this bug yesterday was that the
RSS trimming took care of all the swapout I needed. ;)
The (small) fixes wrt. yesterday's patch are added below.
> 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
1a. don't call enforce_rss_limit() while we're holding the
tasklist_lock ...
1b. enforce_rss_limit() now loops a few times if the first
scanning of the RSS didn't bring us under the soft limit
this turned out to be needed in order to bring a task
down to its RSS limit if the working set is bigger and
there is no VM pressure ... whether it is good or not to
trim to smaller than the working set I don't know, though ;))
> 2. fix the return value from try_to_swap_out() to return
>success whenever we make the RSS of a process smaller
2a. fix swap_out_mm() to unlock the mm->page_table_lock
on success as well
> 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 ;)
The request for inclusion still stands ... I'll be stress-testing
my test machine all weekend while I'm away on the beach.
Other testers are requested ... how does this perform on your
machine and/or are you able to hang it? (I guess the patch
is simple enough to not have any influence on stability)
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 Fri Dec 29 17:10:53 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(current, GFP_HIGHUSER);
+ unlock_kernel();
+ }
+
if (pmd) {
pte_t * pte = pte_alloc(pmd, address);
if (pte)
---
NFS oddity (2.4.0test13pre4ac2 server, 2.0.36/2.2.14 clients)
Hi, On the server: bash$ ls -l total 21 drwxrwxrwx 11 root root 2048 Jul 23 02:32 arm lrwxrwxrwx 1 root root 14 Aug 22 1999 dg -> /home/gilbertd drwxr-xr-x 6 root root 1024 Mar 21 1999 ftp drwx-- 5 g3oagg3oag1024 Oct 3 1999 g3oag drwxr-xr-x 164 gilbertd gilbertd12288 Dec 29 19:42 gilbertd drwxr-xr-x 5 root root 1024 Sep 21 1999 httpd drwxr-xr-x 2 root root 1024 Mar 8 2017 lost+found drwx-- 2 rmk rmk 1024 Apr 11 1999 rmk drwx-- 5 rt rt 1024 Sep 10 14:49 rt drwxr-xr-x 2 root nobody 1024 Apr 16 1999 samba on the client: [root@sol home]# ls -l ls: gilbertd: No such file or directory total 9 drwxrwxrwx 11 root root 2048 Jul 23 02:32 arm lrwxrwxrwx1 root root 14 Aug 22 1999 dg -> /home/gilbertd drwxr-xr-x6 root root 1024 Mar 21 1999 ftp drwx--5 1000 1000 1024 Oct 3 1999 g3oag drwxr-xr-x5 root root 1024 Sep 21 1999 httpd drwxr-xr-x2 root root 1024 Mar 8 2017 lost+found drwx--2 9032 9032 1024 Apr 11 1999 rmk drwx--5 9033 9033 1024 Sep 10 14:49 rt drwxr-xr-x2 root nobody 1024 Apr 16 1999 samba - So where did the gilbertd directory go ? The Server is Linux/Alpha 2.4.0-test13pre4ac2 The clients are Linux/x86 2.0.36 and Linux/SPARC 2.2.14 What gives ? Dave -- Have a happy GNU millennium! -- / Dr. David Alan Gilbert | Running GNU/Linux on | Happy \ \ gro.gilbert @ treblig.org | Alpha, x86, ARM and SPARC | In Hex / \ ___|___ http://www.treblig.org |/ - To unsubscribe from this list: send 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 11:29:12AM -0800, Matt Liotta wrote: > as such doesn't scale well with Linux 2.2 on a dual CPU machine. Our > benchmarks show that we can handle more load on a single CPU machine then a > dual CPU one with Linux 2.2. However, it is encouraging to see that the If for whatever reason you can't use 2.4.x on it right now, in 2.2.19pre3aa4 there's an hack to do tcp_sendmsg checksum and all the copy_user (copies between pagecache and userspace) with the big kernel lock released (so that it can scale better in SMP). That's ugly but people on this list asked for this feature and since it was very fast to implement it I added it. But don't expect anything like 2.4.x SMP scalability! 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/
Re: [PATCH] 8139too fix
On Thu, 28 Dec 2000, Andre Hedrick wrote: [I was going to send brief comment offline, but maybe this will give someone pause for thought...] > Jeff Garzik, is offline for the next three weeks.. > > He claims that his wrists hurt from the keyboard ;-)... And if his wrists hurt, he's definitely doing the right thing by laying off. I _know_: 8 months in a neck brace due to cervical spine damage (don't hunch forward while reading cool/clever code). 1.5 years physical therapy for that damage (permanent, _do not_ hunch forward while reading cool/clever code). 7 months paralysis of left arm (don't put weight on your elbow on hard surface while reading cool/clever code) 5 months paralysis of lower left leg (don't cross your legs while leaning on left elbow while...). The nerve damage can be helped a bit with massive doses of vitamine B if you're lucky, but they don't fully recover in my experience. Bones don't recover at all.. ever. Remember the thousand times your mom said sit up straight?.. I sure do ;-) -Mike - To unsubscribe from this list: send 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?)
I wouldn't use cheap single CPU/NIC machines in the real world. Certainly a cluster of smaller machines does better then one big machine, but that doesn't mean you should use too small of a machine. Remember that as the number of cluster nodes goes up the cluster becomes a management problem. I would use a cluster of dual CPU/NIC machines instead. This gives you the benefits of SMP machines along with the benefits of clusters. It should also allow your cluster to handle more load with less nodes then single CPU/NIC machines. With that being said Linux is proving me wrong in the real world. Our application server is dependant on pthreads (really just cloned process) and as such doesn't scale well with Linux 2.2 on a dual CPU machine. Our benchmarks show that we can handle more load on a single CPU machine then a dual CPU one with Linux 2.2. However, it is encouraging to see that the situation is reversed when using Linux 2.4. -Matt > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 29, 2000 11:14 AM > To: Andrea Arcangeli > Cc: Alan Cox; Petru Paler; Jure Pecar; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: linux 2.2.19pre and thttpd (VM-global problem?) > > > On Fri, Dec 29, 2000 at 08:06:57PM +0100, Andrea Arcangeli wrote: > > On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote: > > > Your cgi will keep the other CPU occupied, or run two of > them. thttpd has > > > superb scaling properties compared to say apache. > > > > I think with 8 CPUs and 8 NICs (usual benchmark setup) you > want more than 1 cpu > > That's a good benchmark setup when the benchmark requires a > single machine. > > In the real world it often makes a lot of sense though to use > a cluster > of cheap single CPU machines behind a load balancer (gives > you better fault > tolerance and is likely cheaper) > > For these thttpd is a nice web server. > > -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/ > - To unsubscribe from this list: send 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 08:06:57PM +0100, Andrea Arcangeli wrote: > On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote: > > Your cgi will keep the other CPU occupied, or run two of them. thttpd has > > superb scaling properties compared to say apache. > > I think with 8 CPUs and 8 NICs (usual benchmark setup) you want more than 1 cpu That's a good benchmark setup when the benchmark requires a single machine. In the real world it often makes a lot of sense though to use a cluster of cheap single CPU machines behind a load balancer (gives you better fault tolerance and is likely cheaper) For these thttpd is a nice web server. -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: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 06:56:09PM +, Alan Cox wrote: > Depends on memory bandwidth, [..] BTW, it could as well use TCP_CORK + sendfile that will become truly zero copy eventually. 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/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 06:50:18PM +, Alan Cox wrote: > Your cgi will keep the other CPU occupied, or run two of them. thttpd has > superb scaling properties compared to say apache. I think with 8 CPUs and 8 NICs (usual benchmark setup) you want more than 1 cpu serving static data and it should be more efficient if it's threaded and sleeping in accept() instead of running eight of them (starting from sharing tlb entries and avoiding flushes probably without the need of CPU binding). 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/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
> They do boost performance on SMP (because you can have N (N=3Dnr. of CP= > Us) > threads serving data). Depends on memory bandwidth, caches, locking overhead and a million other issues. > > on keeping it single-threaded - unless someone can tell me that's a = > bad > > idea) > > Keep it single threaded if you run on UP only... Theory - SMP needs threading Practice is generally a little different - To unsubscribe from this list: send 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: SCSI Problems since upgrade from 2.2.16
"George R. Kasica" wrote: > > Hello: > > I'm running an HP DAT 4mm Autochanger here and since going to 2.2.17 > and 2.2.18 I'm seeing failures when it attempts to unload the tape and > load a new one while backing up using BRU PE...utilizing the mt or mtx > commands as follows: > > mt -f $DEV rewoffl 2>&1 >/dev/null > > OR > > /usr/local/bin/mtx -f /dev/sg1 eject 2>&1 >/dev/null > > If I use the MTX command set to "manually" change the tapes all is > wellany thoughts on the cause or a fix...I don't think the > hardware is broken due to the fact it runs fine "manually" by doing > the mtx -f /dev/sg1 next commnand to load the next tape > > Pertinent info below: > > Information about installed SCSI devices > > Attached devices: > Host: scsi0 Channel: 00 Id: 01 Lun: 00 > Vendor: SEAGATE Model: ST32550N Rev: 0021 > Type: Direct-AccessANSI SCSI revision: 02 > Host: scsi0 Channel: 00 Id: 03 Lun: 00 > Vendor: HP Model: C1553A Rev: NS01 > Type: Sequential-AccessANSI SCSI revision: 02 > Host: scsi0 Channel: 00 Id: 03 Lun: 01 > Vendor: HP Model: C1553A Rev: NS01 > Type: Medium Changer ANSI SCSI revision: 02 While I am not familiar with mtx and the process you are having problems with, 'man 1 mtx' contains the following: The first argument, given following -f, is the SCSI generic device corresponding to your media changer. On the basis of the /proc/scsi/scsi output you have shown, the mtx commands should read "mtx -f /dev/sg2 ..." (not /dev/sg1) as you have noted at the top. Given those 2 sg devices are closely coupled (just differing by the lun) mtx probably can sort this out. Doug Gilbert - To unsubscribe from this list: send 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 09:38:40AM +0200, Petru Paler wrote: > > 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... > > It can't scale in SMP. Your cgi will keep the other CPU occupied, or run two of them. thttpd has superb scaling properties compared to say apache. - To unsubscribe from this list: send 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: How to write patches
Sourav Sen <[EMAIL PROTECTED]> writes: > Hi, > > This question may seem naive, but can anyone tell me if there is any > structured way of writing patches? > > I mean suppose I want to implement some > kernel mechanism, and I define my data structures etc. and made most of > the code as loadable module to start with, but still I am having to > change some parts of the kernel code at the development time, and I > want to make that change using patches, so that I do not have to browse > thru the files to change the code as I debug. > > Is there any structured way of doing this? have a look at: http://www.uwsg.iu.edu/hypermail/linux/kernel/0011.2/0151.html - To unsubscribe from this list: send 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] filemap_fdatasync & related changes
On Thu, 28 Dec 2000, Linus Torvalds wrote:
> 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.
Ok, here it is.
I hope I got all locking and all special cases right.
Comments ?
diff -Nur --exclude-from=/home/marcelo/exclude linux.orig/fs/buffer.c linux/fs/buffer.c
--- linux.orig/fs/buffer.c Fri Dec 29 15:30:52 2000
+++ linux/fs/buffer.c Fri Dec 29 16:21:17 2000
@@ -320,6 +320,46 @@
return 0;
}
+/**
+ * filemap_fdatasync - walk the list of dirty pages of the given address space
+ * and writepage() all of them.
+ *
+ * @mapping: address space structure to write
+ *
+ */
+void filemap_fdatasync(struct address_space * mapping)
+{
+ int (*writepage)(struct page *) = mapping->a_ops->writepage;
+
+ spin_lock(_lock);
+
+while (!list_empty(>dirty_pages)) {
+ struct page *page = list_entry(mapping->dirty_pages.next,
+ struct page, list);
+
+ list_del(>list);
+ list_add(>list, >clean_pages);
+
+ if (!PageDirty(page))
+ continue;
+
+ page_cache_get(page);
+ spin_unlock(_lock);
+
+ lock_page(page);
+
+ if (PageDirty(page)) {
+ ClearPageDirty(page);
+ writepage(page);
+ }
+
+ UnlockPage(page);
+ page_cache_release(page);
+ spin_lock(_lock);
+ }
+ spin_unlock(_lock);
+}
+
/*
* filp may be NULL if called via the msync of a vma.
*/
@@ -367,6 +407,8 @@
if (!file->f_op || !file->f_op->fsync)
goto out_putf;
+ filemap_fdatasync(inode->i_mapping);
+
/* We need to protect against concurrent writers.. */
down(>i_sem);
err = file->f_op->fsync(file, dentry, 0);
@@ -396,6 +438,8 @@
err = -EINVAL;
if (!file->f_op || !file->f_op->fsync)
goto out_putf;
+
+ filemap_fdatasync(inode->i_mapping);
down(>i_sem);
err = file->f_op->fsync(file, dentry, 1);
diff -Nur --exclude-from=/home/marcelo/exclude linux.orig/fs/inode.c linux/fs/inode.c
--- linux.orig/fs/inode.c Fri Dec 1 05:50:27 2000
+++ linux/fs/inode.cFri Dec 29 16:14:09 2000
@@ -100,7 +100,8 @@
memset(inode, 0, sizeof(*inode));
init_waitqueue_head(>i_wait);
INIT_LIST_HEAD(>i_hash);
- INIT_LIST_HEAD(>i_data.pages);
+ INIT_LIST_HEAD(>i_data.clean_pages);
+ INIT_LIST_HEAD(>i_data.dirty_pages);
INIT_LIST_HEAD(>i_dentry);
INIT_LIST_HEAD(>i_dirty_buffers);
sema_init(>i_sem, 1);
@@ -206,6 +207,8 @@
inode->i_state |= I_LOCK;
inode->i_state &= ~I_DIRTY;
spin_unlock(_lock);
+
+ filemap_fdatasync(inode->i_mapping);
write_inode(inode, sync);
diff -Nur --exclude-from=/home/marcelo/exclude linux.orig/mm/filemap.c
linux/mm/filemap.c
--- linux.orig/mm/filemap.c Fri Dec 29 15:30:55 2000
+++ linux/mm/filemap.c Fri Dec 29 16:18:01 2000
@@ -71,7 +71,7 @@
static inline void add_page_to_inode_queue(struct address_space *mapping, struct page
* page)
{
- struct list_head *head = >pages;
+ struct list_head *head = >clean_pages;
mapping->nrpages++;
list_add(>list, head);
@@ -144,7 +144,7 @@
struct list_head *head, *curr;
struct page * page;
- head = >i_mapping->pages;
+ head = >i_mapping->clean_pages;
spin_lock(_lock);
spin_lock(_lru_lock);
@@ -204,26 +204,12 @@
page_cache_release(page);
}
-/**
- * truncate_inode_pages - truncate *all* the pages from an offset
- * @mapping: mapping to truncate
- * @lstart: offset from with to truncate
- *
- * Truncate the page cache at a set offset, removing the pages
- * that are beyond that offset (and zeroing out partial pages).
- * If any page is locked we wait for it to become unlocked.
- */
-void truncate_inode_pages(struct address_space * mapping, loff_t lstart)
+void truncate_list_pages(struct list_head *head, unsigned long start, unsigned
+partial)
{
- struct list_head *head, *curr;
+ struct list_head *curr;
struct page * page;
-
Preemption exit code
As you know we at MontaVista are working on a preemptable kernel that
takes advantage of the spin_lock() macros. One of the "tricks" we use
is to bump a preemption counter on a spin_lock() and to decrement it on
spin_unlock(). The question, here posed, has to do with the test that
needs to be done on the decrement. If the result is zero AND
need_resched is set we want to set the preemption count to one (to avoid
an interrupt race to schedule()) and call schedule(). This test and set
needs to be atomic (again to avoid the interrupt race to schedule()). I
have been thinking of putting the preemption count and the need_resched
flag in shorts with a long union to combine them into one word. Leaving
the endian problem aside, this would then allow me to use the cmpxchg
instruction to test and set the required bit. Thus the spin_unlock()
would generate something like:
preempt_count--;
if( __cmpxchg(>resched_preempt,
RESCHED_ONLY,
RESCHED_PREEMPT,
4) == RESCHED_ONLY) {
do_call_schedule();
Where __cmpxchg() is from .../include/asm/system.h and
do_call_schedule() would decrement the preemption count on return
(actually it would return to the decrement above). (Note that I am
using C here but the actual code would most likely be in asm.)
And then I found the following on the l-k list today:
>Subject: Re: test13-pre5
>Date: Thu, 28 Dec 2000 15:15:01 -0800 (PST)
>From:Linus Torvalds <[EMAIL PROTECTED]>
>
snip
>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.
snip
So, what is recommended here?
Other considerations:
We would like to not have to find and modify all accesses to
need_resched. Currently it is set to one in several places and tested
for non-zero in quite a few more places. Combining the two flags in one
word would change established usage, but would solve the problem.
The above exit code is fast and tight, being a dec a cmpxchg and a
conditional jump (inline) (in asm we can use the Z-flag that the cmpxchg
sets to eliminate the compare in used above). Note that the atomic
requirement is with respect to an interrupt, not another cpu, so the
lock modifier is not needed. If another cpu sets need_resched, it will
also set and interrupt for us so we can safely ignore it here.
George
-
To unsubscribe from this list: send 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 and 8139too
I'm getting intermittent time out on my Realtek 8139B - 8139too on eth0 Guess the problems back. Fun..., Have to reboot my Cisco 675 Oh well... Frank - To unsubscribe from this list: send 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 Fri, 29 Dec 2000, Marcelo Tosatti wrote:
> Now the ext2 changes will for sure make a difference since right now the
> superblock lock is suffering from contention.
superblock lock is suffering from more than just contention. Consider the
following:
sys_ustat() does get_super(), which leaves the sb unlocked.
We are going to call ->statfs().
In the meanwhile, fs is umounted. Woops...
In other words, get_super() callers are oopsen waiting to happen. That's
what is fundamentally wrong with lock_super()/wait_super()/unlock_super() -
we have no reference counter on superblocks and we blindly grab references
to them assuming that they will stay.
The main source of get_super() calls is in device drivers. I propose to add
void invalidate_dev(kdev_t dev, int sync_flag)
{
struct super_block *sb = get_super(dev);
switch (sync_flag) {
case 1: sync_dev(dev);break;
case 2: fsync_dev(dev);break;
}
if (sb)
invalidate_inodes(sb);
invalidate_buffers(dev);
}
to fs/buffer.c, export it and let drivers call that instead of doing the
thing by hands. Then we have a chance to deal with the problem inside the
kernel proper. Right now almost every block device has that sequence in
BLKRRPART handling and fixing each of them separately is going to hurt like
hell.
Linus, I realize that it's changing the block devices near to release, but
AFAICS we have to change them anyway. I'm asking for permission to take
get_super() out.
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
How to write patches
Hi, This question may seem naive, but can anyone tell me if there is any structured way of writing patches? I mean suppose I want to implement some kernel mechanism, and I define my data structures etc. and made most of the code as loadable module to start with, but still I am having to change some parts of the kernel code at the development time, and I want to make that change using patches, so that I do not have to browse thru the files to change the code as I debug. Is there any structured way of doing this? Happy New Year Sourav - To unsubscribe from this list: send 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 07:13:28PM +0100, Jakob Østergaard wrote: > > > It can't scale in SMP. > > > > No one said it does, but it works nicely on UP. > > What ? Maybe you got me wrong (my english isnt that good): I said that it does not scale on SMP, but it works just fine on UP. > The TCP stack is threaded, so things like checksum calculation will > take advantage of multiple processors - right ? Wrong. "Threaded" TCP/IP stack -> fine grained locking, not "multiple threads". > Thes rest of the work is roughly copying data that isn't already > cached from the disk into memory. Well, you have one disk so threads > will buy you zero there. > > Unless you do blocking I/O on the files or on the sockets, I fail to > see how threads could possibly boost the performance on a web server > that serves *static*only* pages. They do boost performance on SMP (because you can have N (N=nr. of CPUs) threads serving data). > (The reason I'm curious is because I'm about a month away from implementing > something that would run high-bandwidth TCP transfers and I'm planning > on keeping it single-threaded - unless someone can tell me that's a bad > idea) Keep it single threaded if you run on UP only... -- 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: test13-pre5
On Thu, Dec 28, 2000 at 12:25:23PM -0800, Linus Torvalds wrote: > - 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. I just noticed this (playing with some other stuff), but ext2 as a module is currently broken: $ make INSTALL_MOD_PATH=/tmp/foo modules_install ... if [ -r System.map ]; then /sbin/depmod -ae -F System.map -b /tmp/foo -r 2.4.0-test12; fi depmod: *** Unresolved symbols in /tmp/foo/lib/modules/2.4.0-test12/kernel/fs/ext2/ext2.o depmod: buffer_insert_inode_queue depmod: fsync_inode_buffers I tried the following locally and it fixes it. -- --- fs/Makefile.origFri Dec 29 10:35:50 2000 +++ fs/Makefile Fri Dec 29 10:36:06 2000 @@ -7,7 +7,7 @@ O_TARGET := fs.o -export-objs := filesystems.o +export-objs := filesystems.o buffer.o mod-subdirs := nls obj-y := open.o read_write.o devices.o file_table.o buffer.o \ --- fs/buffer.c.origFri Dec 29 10:33:21 2000 +++ fs/buffer.c Fri Dec 29 10:35:46 2000 @@ -29,6 +29,7 @@ /* async buffer flushing, 1999 Andrea Arcangeli <[EMAIL PROTECTED]> */ #include +#include #include #include #include @@ -579,6 +580,8 @@ spin_unlock(_list_lock); } +EXPORT_SYMBOL(buffer_insert_inode_queue); + /* The caller must have the lru_list lock before calling the remove_inode_queue functions. */ static void __remove_inode_queue(struct buffer_head *bh) @@ -900,6 +903,7 @@ return err2; } +EXPORT_SYMBOL(fsync_inode_buffers); /* * osync is designed to support O_SYNC io. It waits synchronously for -- -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send 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 08:04:21PM +0200, Petru Paler wrote:
> On Fri, Dec 29, 2000 at 04:53:40PM +0100, Andrea Arcangeli wrote:
> > On Fri, Dec 29, 2000 at 09:38:40AM +0200, Petru Paler wrote:
> > > 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...
> >
> > It can't scale in SMP.
>
> No one said it does, but it works nicely on UP.
What ?
The TCP stack is threaded, so things like checksum calculation will
take advantage of multiple processors - right ?
Thes rest of the work is roughly copying data that isn't already
cached from the disk into memory. Well, you have one disk so threads
will buy you zero there.
Unless you do blocking I/O on the files or on the sockets, I fail to
see how threads could possibly boost the performance on a web server
that serves *static*only* pages.
99% of the real work is done by the kernel, so whether you have your
user-space application threaded or not should not be an issue - the
way that I see it...
Andrea, or someone else, would you care to enlighten me on that ?
(The reason I'm curious is because I'm about a month away from implementing
something that would run high-bandwidth TCP transfers and I'm planning
on keeping it single-threaded - unless someone can tell me that's a bad
idea)
Thanks,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
To unsubscribe from this list: send 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 Fri, 29 Dec 2000, Chris Mason wrote: > BTW, the last anon space mapping patch I sent also works on test13-pre5. > The block_truncate_page fix does help my patch, since I have bdflush > locking pages ( thanks Marcelo ) Good to know. I thought that fix would not change performance noticeable. Now the ext2 changes will for sure make a difference since right now the superblock lock is suffering from contention. - To unsubscribe from this list: send 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 04:53:40PM +0100, Andrea Arcangeli wrote: > On Fri, Dec 29, 2000 at 09:38:40AM +0200, Petru Paler wrote: > > 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... > > It can't scale in SMP. No one said it does, but it works nicely on UP. -- 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: [RFC] changes to buffer.c (was Test12 ll_rw_block error)
Chris Mason wrote: > > On Thursday, December 28, 2000 11:29:01 AM -0800 Linus Torvalds > <[EMAIL PROTECTED]> wrote: > [ skipping io on the first walk in page_launder ] > > > > 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? > > My dbench speeds have always varied from run to run, but the average speed > went up about 9% with the anon space mapping patch and the page_launder > change. I could not find much difference in a pure test13-pre4, probably > because dbench doesn't generate much swap on my machine. I'll do more > tests when I get back on Monday night. > > Daniel, sounds like dbench varies less on your machine, what did the patch > do for you? > > BTW, the last anon space mapping patch I sent also works on test13-pre5. > The block_truncate_page fix does help my patch, since I have bdflush > locking pages ( thanks Marcelo ) Yes it does, but the little additional patch you posted no longer applies. Your patch is suffering badly under pre5 here, reducing throughput from around 10 MB/sec to 5-6 MB/sec, and highly variable. If you're not seeing this you should probably try to get a few others to run it. -- 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: test13-pre5
On Fri, 29 Dec 2000, Tim Wright wrote: > Yes, this is a very important point if we ever want to make serious use > of large memory machines on ia32. We ran into this with DYNIX/ptx when the > P6 added 36-bit physical addressing. Conserving KVA (kernel virtual address > space), became a very high priority. Eventually, we had to add code to play > silly segment games and "magically" materialize and dematerialize a 4GB > kernel virtual address space instead of the 1GB. This only comes into play > with really large amounts of memory, and is almost certainly not worth the > agony of implementation on Linux, but we'll need to be careful elsewhere to > conserve it as much as possible. Indeed. I'm compiling my kernels with 2GB virtual. Not as I want more NORMAL pages in the page cache (HIGH memory is fine), but as I need NORMAL pages for kernel data/structures (memory allocated from slab-caches) which need to be constantly mapped in. Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with ATX halt
Ryan Sizemore sez > >I am new this whole 'posting to the mailing list' thing, so please excuse > any obvious mistakes. >I have a comp. running mandrake 7.2, and when i go to power it down, it > gives me a screen full of errors, including a stackdump. It happens as the > very last thing (including being after the file system is unmounted, so I > highly doubt that the error is recorded somewhere. But i will hand-copy the > stack for whomever thinks it may be useful. The error is reproduced every > time, without equivication. Any insight or questions are much apriciated. > The motherboard is a Soyo 5EMA+ r1.0 w/ ETEQ EQ82C6638 Chipset, and it has > an Award BIOS. > Thanks in Advance. > I've seen this before with nearly every Mandrake distrib right out of the box. One of the many reasons I choose not to use Mandrake on my personal boxes. I think I solved it by recompiling the kernel and taking the "Power Management" things out of the kernel. Coy -- Coy Hile [EMAIL PROTECTED] "Two roads diverged in a wood, and I-- / I took the one less traveled by, And that has made all the difference." --Robert Frost - To unsubscribe from this list: send 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.1x unknown kernel messages in syslog
All, Running 2.2.19pre2 (but it happens w/ many previous 2.2.1(7-8) versions) built w/ egcs-2.91.66, while connected w/ ppp over analog modem to windows nt ras server; I get the following messages using ppp 2.4.0b4 (w/ MSCHAP-80) Dec 29 09:22:59 kodi pppd[905]: pppd 2.4.0b4 started by bpriest, uid 500 Dec 29 09:23:01 kodi chat[910]: abort on (BUSY) Dec 29 09:23:01 kodi chat[910]: abort on (NO ANSWER) Dec 29 09:23:01 kodi chat[910]: send (AT^M) Dec 29 09:23:01 kodi chat[910]: expect (OK) Dec 29 09:23:01 kodi chat[910]: AT^M^M Dec 29 09:23:01 kodi chat[910]: OK Dec 29 09:23:01 kodi chat[910]: -- got it Dec 29 09:23:01 kodi chat[910]: send (ATDTxx^M) Dec 29 09:23:01 kodi chat[910]: expect (CONNECT) Dec 29 09:23:01 kodi chat[910]: ^M Dec 29 09:23:34 kodi chat[910]: ATDTxx^M^M Dec 29 09:23:34 kodi chat[910]: CONNECT Dec 29 09:23:34 kodi chat[910]: -- got it Dec 29 09:23:34 kodi pppd[905]: Serial connection established. Dec 29 09:23:34 kodi pppd[905]: Using interface ppp0 Dec 29 09:23:34 kodi pppd[905]: Connect: ppp0 <--> /dev/ttyS3 Dec 29 09:23:34 kodi kernel: ppp_ioctl: set dbg flags to 1f Dec 29 09:23:34 kodi kernel: ppp_ioctl: set flags to 1f Dec 29 09:23:34 kodi kernel: ppp_tty_ioctl: set xasyncmap Dec 29 09:23:34 kodi kernel: ppp_tty_ioctl: set xmit asyncmap Dec 29 09:23:34 kodi kernel: ppp_ioctl: set flags to 1f Dec 29 09:23:34 kodi kernel: ppp_ioctl: set mru to 5dc Dec 29 09:23:34 kodi kernel: ppp_tty_ioctl: set rcv asyncmap Dec 29 09:23:36 kodi kernel: ppp_tty_ioctl: set xmit asyncmap 0 Dec 29 09:23:36 kodi kernel: ppp_ioctl: set flags to f1f0002 Dec 29 09:23:36 kodi kernel: ppp_ioctl: set mru to 5dc Dec 29 09:23:36 kodi kernel: ppp_tty_ioctl: set rcv asyncmap Dec 29 09:23:39 kodi kernel: ppp_ioctl: set flags to f1f0042 Dec 29 09:23:41 kodi pppd[905]: local IP address 192.168.220.50 Dec 29 09:23:41 kodi pppd[905]: remote IP address 192.168.220.46 Dec 29 09:23:41 kodi kernel: ppp_ioctl: set maxcid to 16 Dec 29 09:23:41 kodi kernel: ppp_ioctl: set flags to f1f0046 Dec 29 09:23:44 kodi kernel: ppp_ioctl: set flags to f1f0006 Dec 29 09:23:53 kodi PAM_pwdb[956]: (su) session opened for user root by bpriest(uid=500) Dec 29 09:24:38 kodi kernel: d (AT^M Dec 29 09:24:38 kodi kernel: hat[464 Dec 29 09:24:40 kodi kernel: 24 11 Dec 29 09:24:41 kodi kernel: i kerne Dec 29 09:24:42 kodi kernel: ).Dec 2 Dec 29 09:24:43 kodi kernel: .<.z Dec 29 09:24:44 kodi kernel: 15 36 Dec 29 09:24:45 kodi kernel: i k Dec 29 09:24:46 kodi kernel: Dec Dec 29 09:24:47 kodi kernel: kodi k Dec 29 09:24:48 kodi kernel: NO ANSW Dec 29 09:24:55 kodi kernel: 0 70 kodi pp Dec 29 09:24:56 kodi kernel: 0A 44 hangup.D Dec 29 09:24:57 kodi kernel: ablis Dec 29 09:24:59 kodi kernel: ec 26 Dec 29 09:29:15 kodi kernel: odi ker I'm not sure if they are causing a problem or not; (I seem to notice them more when I'm surfing w/ netscape), however, the above were received while only ftp'ing /var/log/messages to the remote machine. Note telephone numbers x'ed out for privacy. I'm not subscribe'ed to linux-kernel; so please copy me w/ any questions or replies. Note previously my asyncmap was set to 0 and the same thing occurred. Note that I transferred the file while I was driving to work and the windows ras machine timed out and disconnected (I presume). Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Bugs in knfsd -- Problem re-exporting an NFS share
Hi -- could you please CC me if you reply to this mail. My problem is that I get an error when setting up the following configuration: A: /exports/A - Redhat 7.0 B1/B2: mount /exports/A on /export/A from A - Redhat 6.2 C: mount /exports/A on /mnt/A from B1 or B2 - Redhat 6.2 I use knfsd/nfs-utils on each machine. bash# ls /mnt/A /mnt/A/A.txt: No such file or directory I searched for a while on deja.com, and there seemed to be some indications that knfsd was bugged and that using the user-mode code would work. However, no one replied specifically to my message, so I'm still not sure. BTW, what I tried to do was to set up a HA configuration of machines B1/B2 using A as a "shared disk". This is just to try out the HA software without buying more hardware. Thanks in advance for any help! Best regards, Frank Olsen PS Happy new year! - To unsubscribe from this list: send 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: PowerPC branch out of date
On Fri, Dec 29, 2000 at 02:40:41PM -0200, Rik van Riel wrote: > On Fri, 29 Dec 2000 [EMAIL PROTECTED] wrote: > > > How it's got there etc etc etc at this stage isn't important. > > First how to fix it and how to make sure it doesn't happen again > > does concern me. > > > I would REALLY appreciate it if this could be made to happen. > > Send patches to Linus and Alan ? test13-pre5-acXX is up-to-date with everything that's important anyways. Weather that makes it into Linus' tree is the important and unknown bit. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send 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: [BUG] in 2.4.0test12 and earlier
>the kernel locks up on my Alpha PC164 when network load is >high. It does it with several different NICs. >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. I hate to respond to my own mail, but does anyone here run linux on an Alpha? Is there a better place to ask these questions? --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/
wake-one-3 bug (affected 2.2.19pre3aa[123])
On Sun, Dec 24, 2000 at 04:40:09PM +0100, Andrea Arcangeli wrote: > On Sun, Dec 24, 2000 at 11:23:33AM +1100, Andrew Morton wrote: > > ack. > > This patch against 2.2.19pre3 should fix all races. (note that wait->flags > doesn't need to be initialized in the critical section in test1X too) > > >ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.19pre3/wake-one-3 > > Comments? Woops, it had a bug (I overlooked the usage of __add_wait_queue in sleep_on), the bug was reproduced and fixed by Chris Mason and his fix is obviously right, see: --- 2.2.19pre3aa3/kernel/sched.c.~1~Wed Dec 27 04:49:37 2000 +++ 2.2.19pre3aa3/kernel/sched.cFri Dec 29 17:03:09 2000 @@ -1018,6 +1018,7 @@ #defineSLEEP_ON_HEAD \ wait.task = current;\ + wait.flags = 0; \ write_lock_irqsave(_lock,flags); \ __add_wait_queue(p, ); \ write_unlock(_lock); New patch (revision n.4) against vanilla 2.2.19pre3 is here: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.19pre3/wake-one-4 Since 2.2.19pre3aa[123] included the wake-one-3 patch they can generate task in D state blocked in sleep_on* too. So if you're running 2.2.19pre3aa[123] you should either upgrade to 2.2.19pre3aa4 or to apply the above inlined one liner on top of 2.2.19pre3aa[123] sources and recompile (just make bzImage again will be enough). 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/
Re:[PATCH, v2] Processor autodetection (when configuring kernel)
Version 2:
. Added a PIII
. Corrected the name of Crusoe
. Added the generic Intel and AMD 486
. Corrected the braces {,} (wrong syntax)
giacomo
diff -urN old.linux/CREDITS linux/CREDITS
--- old.linux/CREDITS Fri Dec 29 13:32:46 2000
+++ linux/CREDITS Fri Dec 29 13:43:02 2000
@@ -458,6 +458,12 @@
S: Fremont, California 94539
S: USA
+N: Giacomo Catenazzi
+E: [EMAIL PROTECTED]
+D: Random kernel hack and fixes
+D: Author of scripts/cpu_detect.sh
+S: Switzerland
+
N: Gordon Chaffee
E: [EMAIL PROTECTED]
W: http://bmrc.berkeley.edu/people/chaffee/
diff -urN old.linux/Makefile linux/Makefile
--- old.linux/Makefile Fri Dec 29 11:26:55 2000
+++ linux/Makefile Fri Dec 29 13:32:10 2000
@@ -65,6 +65,16 @@
do-it-all: config
endif
+# Second stage configuration
+# Note that GNU make will read again this Makefile, so the CONFIG are
+# updated
+ifeq ($(CONFIG_CPU_CURRENT), y)
+CONFIGURATION = config2
+do-it-all: config2
+.config:config2
+ @echo "Rescanning the main Makefile"
+endif
+
#
# INSTALL_PATH specifies where to place the updated kernel and system
map
# images. Uncomment if you want to place them anywhere other than
root.
@@ -273,6 +283,14 @@
config: symlinks
$(CONFIG_SHELL) scripts/Configure arch/$(ARCH)/config.in
+
+config2:
+ echo "CONFIG_CPU_CURRENT=n" >> .config
+ echo `$(CONFIG_SHELL) $(TOPDIR)/scripts/cpu_detect.sh`=y >>
.config
+ $(MAKE) oldconfig
+
+config2.test:
+ echo "CONFIG_CPU_CURRENT=$(CONFIG_CPU_CURRENT)"
include/config/MARKER: scripts/split-include include/linux/autoconf.h
scripts/split-include include/linux/autoconf.h include/config
diff -urN old.linux/arch/i386/config.in linux/arch/i386/config.in
--- old.linux/arch/i386/config.in Fri Dec 29 11:26:55 2000
+++ linux/arch/i386/config.in Fri Dec 29 13:14:58 2000
@@ -26,7 +26,9 @@
mainmenu_option next_comment
comment 'Processor type and features'
-choice 'Processor family' \
+bool "Optimize for current CPU" CONFIG_CPU_CURRENT
+if [ "$CONFIG_CPU_CURRENT" != "y" ]; then
+ choice 'Processor family' \
"386CONFIG_M386 \
486CONFIG_M486 \
586/K5/5x86/6x86/6x86MXCONFIG_M586 \
@@ -41,6 +43,10 @@
Winchip-C6 CONFIG_MWINCHIPC6 \
Winchip-2 CONFIG_MWINCHIP2 \
Winchip-2A/Winchip-3 CONFIG_MWINCHIP3D" Pentium-Pro
+else
+ # First configuration stage: Allow all possible processors deps
+ define_bool CONFIG_M386 y
+fi
#
# Define implied options from the CPU selection here
#
diff -urN old.linux/scripts/cpu_detect.sh linux/scripts/cpu_detect.sh
--- old.linux/scripts/cpu_detect.sh Thu Jan 1 01:00:00 1970
+++ linux/scripts/cpu_detect.sh Fri Dec 29 17:10:23 2000
@@ -0,0 +1,38 @@
+#! /bin/bash
+
+# Copyright (C) 2000 Giacomo Catenazzi <[EMAIL PROTECTED]>
+# This is free software, see GNU General Public License 2 for details.
+
+# This script try to autodetect the CPU.
+# On SMP I assume that all processors are of the same type as the first
+
+
+if [ "$ARCH" = "i386" ] ; then
+ vendor=$(sed -n 's/^vendor_id.*: \([-A-Za-z0-9_]*\).*$/\1/pg'
/proc/cpuinfo)
+ cpu_fam=$(sed -n 's/^cpu family.*: \([0-9A-Za-z]*\).*$/\1/pg'
/proc/cpuinfo)
+ cpu_mod=$(sed -n 's/^model[^a-z]*: \([0-9A-Za-z]*\).*$/\1/pg'
/proc/cpuinfo)
+ cpu_id="$vendor:$cpu_fam:$cpu_mod"
+
+ #echo $cpu_id # for debug
+
+ case $cpu_id in
+GenuineIntel:4:*) echo CONFIG_M486 ;; # exists ?
+GenuineIntel:5:[0123] ) echo CONFIG_M586TSC ;;
+GenuineIntel:5:[48] ) echo CONFIG_M586MMX ;;
+GenuineIntel:6:[01356] ) echo CONFIG_M686 ;;
+GenuineIntel:6:[789]) echo CONFIG_M686FXSR ;;
+GenuineIntel:6:1[1] ) echo CONFIG_M686FXSR ;;
+AuthenticAMD:4:*) echo CONFIG_M486 ;;
+AuthenticAMD:5:[0123] ) echo CONFIG_M586 ;;
+AuthenticAMD:5:[89] ) echo CONFIG_MK6 ;;
+AuthenticAMD:5:1[01]) echo CONFIG_MK6 ;;
+AuthenticAMD:6:[0124] ) echo CONFIG_MK7 ;;
+UMC:4:[12] ) echo CONFIG_M486 ;; # "UMC" !
+NexGenDriven:5:0) echo CONFIG_M386 ;;
+TransmetaCPU:* ) echo CONFIG_MCRUSOE ;;
+GenuineTMx86:* ) echo CONFIG_MCRUSOE ;;
+
+# default value
+* ) echo CONFIG_M386 ;;
+ esac
+fi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test12-reiserfs oops in
...happens when http browsing the net (occurs regularly within 1 hour)... server:~# ksymoops -m /boot/System.map ] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210246 eax: ebx: ecx: c28f5f60 edx: c28f5f60 esi: 05c0 edi: c6ec75c0 ebp: 0570 esp: c02adbec ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02ad000) Stack: c28f5f60 a876 46aa9b3e 0014 c020b2e3 c28f5f60 c6ec75c0 c12ef680 c6ec75c0 c020db98 c02adcf0 012adc30 c022ca70 c6ec75c0 c02adce0 c030dfd8 c022c389 c6ec75c0 c02adce0 c030dfd8 c020db98 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [ ] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 3c 89 41 3c 8b 47 5c c7 47 18 00 00 00 00 01 41 18 8b >>EIP; c020af5e<= Trace; c020b2e3 Trace; c020db98 Trace; c022ca70 Trace; c022c389 Trace; c020db98 Trace; c011e7b9 Trace; c022960e Trace; c020db98 Trace; c01f101c Trace; c020db98 Trace; c020db98 Trace; c01f1233 Trace; c020db98 Trace; c020d1d9 Trace; c020db98 Trace; c0222fd8 Trace; c020d2ee Trace; c0222fd8 Trace; c02231cc Trace; c0222fd8 Trace; c02236fa Trace; f0debc9a Trace; c01f23e6 Trace; c022394d Trace; c020a2cb Trace; c020a817 Trace; c020a780 Trace; c01f126d Trace; c020a416 Trace; c020a780 Trace; c020aa5f Trace; c020a878 Trace; c01f126d Trace; c020a746 Trace; c020a878 Trace; c01f4bab Trace; c011b900 Trace; c010ba42 Trace; c0108ad0 Trace; e000 Trace; c010a7a0 Trace; c0108ad0 Trace; e000 Trace; c0108af3 Trace; c0108b57 Trace; c0105000 Trace; c0100191 Code; c020af5e <_EIP>: Code; c020af5e<= 0: 8b 40 3c mov0x3c(%eax),%eax <= Code; c020af61 3: 89 41 3c mov%eax,0x3c(%ecx) Code; c020af64 6: 8b 47 5c mov0x5c(%edi),%eax Code; c020af67 9: c7 47 18 00 00 00 00 movl $0x0,0x18(%edi) Code; c020af6e 10: 01 41 18 add%eax,0x18(%ecx) Code; c020af71 13: 8b 00 mov(%eax),%eax Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! -- If you talk to God, you are praying; if God talks to you, you have schizophrenia. -- Thomas Szasz - To unsubscribe from this list: send 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: PowerPC branch out of date
On Fri, 29 Dec 2000 [EMAIL PROTECTED] wrote: > How it's got there etc etc etc at this stage isn't important. > First how to fix it and how to make sure it doesn't happen again > does concern me. > I would REALLY appreciate it if this could be made to happen. Send patches to Linus and Alan ? 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: linux 2.2.19pre and thttpd (VM-global problem?)
Andrea Arcangeli wrote: > Petru Paler wrote: > > 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... > > It can't scale in SMP. thttpd is i/o bound, not CPU bound, so there's no need for SMP scaling. It's an effective little server as long as the active document tree fits in RAM. If it ain't broke, don't tell people how to fix it :-) (If for some reason SMP scaling was desirable, the thttpd way to do it would be to introduce one thread for each CPU, and have each thread run the same select() loop.) - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre5
On Fri, Dec 29, 2000 at 03:46:22PM +, Mark Hemment wrote: > Note, for those of us running on 32bit with lots of physical memory, the > available virtual address-space is of major consideration. Reducing the > size of the page structure is more than just reducing cache misses - it > gives us more virtual to play with... > > Mark > Yes, this is a very important point if we ever want to make serious use of large memory machines on ia32. We ran into this with DYNIX/ptx when the P6 added 36-bit physical addressing. Conserving KVA (kernel virtual address space), became a very high priority. Eventually, we had to add code to play silly segment games and "magically" materialize and dematerialize a 4GB kernel virtual address space instead of the 1GB. This only comes into play with really large amounts of memory, and is almost certainly not worth the agony of implementation on Linux, but we'll need to be careful elsewhere to conserve it as much as possible. 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/
Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again
the only thing you've to be careful is to make sure you set the correct options for the module (if you compiled it as module). # options=0x30 100mbps full duplex # options=0x20 100mbps half duplex # options=0 10mbps half duplex options eepro100 options=0 Otherwise, it'll cause a lot of unnecessary network traffic and slow down your network! These are not obvious unless you read the source code. Jeff. >From [EMAIL PROTECTED] Fri Dec 29 14:14:55 2000 X-Authentication-Warning: palladium.transmeta.com: mail set sender to [EMAIL PROTECTED] using -f To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Linus Torvalds) Subject: Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again Date: 28 Dec 2000 22:15:17 -0800 Organization: Transmeta Corporation References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] Precedence: bulk X-Mailing-List: [EMAIL PROTECTED] 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/ - To unsubscribe from this list: send 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] remove __mark_buffer_dirty and related changes
On Fri, 29 Dec 2000, Russell King wrote:
> Marcelo Tosatti writes:
> > +int mark_buffer_dirty(struct buffer_head *bh)
> > {
> > + if (!atomic_set_buffer_dirty(bh)) {
> > + return 1;
> > + }
> > + return 0;
> > }
>
> Any particular reason why you don't to:
>
> return !atomic_set_buffer_dirty(bh);
>
> which generates better code on some systems?
No.
If Linus applies the patch I'll change the code to the way you suggested.
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/
PCI IRQ Routing Problem - Kernel OOPS
I am having problems with something that looks like a PCI IRQ routing problem. Everything worked just fine up until test12-pre7. Test12-pre8 did not even boot, it hung when initializing the SCSI adapter. Everything after that (including test12) booted successfully, but crashed when I loaded the Firewire OHCI driver. All other drivers seem to work and if I don't try to load the IEEE-1394 subsystem, then the machine runs stable. I can observe the same problem with all test13-preX kernels up to pre5. Here is the output of lspci -v (this was done with a 2.2.18 kernel, which is what I use for "normal" work): 00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04) Flags: bus master, medium devsel, latency 16 Memory at e000 (32-bit, prefetchable) Capabilities: 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: e400-e7ff Prefetchable memory behind bridge: e800-e8ff 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47) Subsystem: VIA Technologies, Inc. MVP3 ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at 6400 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at 6800 00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10) Flags: medium devsel 00:09.0 Multimedia video controller: Brooktree Corporation Bt848 TV with DMA push (rev 12) Flags: bus master, medium devsel, latency 32, IRQ 9 Memory at ea004000 (32-bit, prefetchable) 00:0a.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 (prog-if 10 [OHCI]) Subsystem: Texas Instruments: Unknown device 8010 Flags: bus master, medium devsel, latency 32, IRQ 9 Memory at ea006000 (32-bit, non-prefetchable) Memory at ea00 (32-bit, non-prefetchable) Capabilities: 00:0b.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine 10/100] (rev 06) Subsystem: D-Link System Inc DFE-530TX Flags: bus master, medium devsel, latency 64, IRQ 12 I/O ports at 6c00 Memory at ea005000 (32-bit, non-prefetchable) Expansion ROM at e900 [disabled] 00:0c.0 SCSI storage controller: Adaptec AHA-7850 (rev 03) Subsystem: Adaptec AHA-2904/Integrated AIC-7850 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at 7000 Memory at ea007000 (32-bit, non-prefetchable) Capabilities: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G200 AGP Flags: bus master, medium devsel, latency 64 Memory at e800 (32-bit, prefetchable) Memory at e400 (32-bit, non-prefetchable) Memory at e500 (32-bit, non-prefetchable) Capabilities: ... and here is the OOPS which was captured in single user mode, if I do the same in multi user mode the problems occurs in the sound driver, which seems to be very odd: Unable to handle kernel NULL pointer dereference at virtual address d08b3669 *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010046 eax: ebx: c149a244 ecx: c149d980 edx: c149a220 esi: c149a240 edi: c149d940 ebp: d08c0090 esp: cfb2fd58 ds: 0018 es: 0018 ss: 0018 Process modprobe (pid: 52, stackpage=cfb2f000) Stack: cff24ec0 d08c 0001 0246 c149d980 ffc0 0002 d08b2715 d08c d08c d08bc1c0 d08b091d d08c cfa98014 d08b79df d08c 0001 0001 d08b9f00 c149a200 0401 0009 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 89 18 ff 74 24 10 9d 57 e8 72 d3 ff ff 83 c4 04 85 c0 75 2e >>EIP; d08b3669 <_end+10591855/1070c24c> <= Trace; d08c <_end+1059e1ec/1070c24c> Trace; d08b2715 <_end+10590901/1070c24c> Trace; d08c <_end+1059e1ec/1070c24c> Trace; d08c <_end+1059e1ec/1070c24c> Trace; d08bc1c0 <_end+1059a3ac/1070c24c> Trace; d08b091d <_end+1058eb09/1070c24c> Trace; d08c <_end+1059e1ec/1070c24c> Trace; d08b79df <_end+10595bcb/1070c24c> Trace; d08c <_end+1059e1ec/1070c24c> Trace; d08b9f00 <_end+105980ec/1070c24c> Trace; d08c <_end+1059e1ec/1070c24c> Trace;
Re: [RFC] changes to buffer.c (was Test12 ll_rw_block error)
On Thursday, December 28, 2000 11:29:01 AM -0800 Linus Torvalds <[EMAIL PROTECTED]> wrote: [ skipping io on the first walk in page_launder ] > > 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? My dbench speeds have always varied from run to run, but the average speed went up about 9% with the anon space mapping patch and the page_launder change. I could not find much difference in a pure test13-pre4, probably because dbench doesn't generate much swap on my machine. I'll do more tests when I get back on Monday night. Daniel, sounds like dbench varies less on your machine, what did the patch do for you? BTW, the last anon space mapping patch I sent also works on test13-pre5. The block_truncate_page fix does help my patch, since I have bdflush locking pages ( thanks Marcelo ) -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: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 09:38:40AM +0200, Petru Paler wrote: > 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... It can't scale in SMP. 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/
Re: test13-pre5
Hi, On Thu, 28 Dec 2000, 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. Checking test11 (which I'm running here), even with waitq debugging turned off, on 32-bit (IA32) the struct page is 68bytes (since the "age" member was re-introduced a while back). For my development testing, I'm running a _heavily_ hacked kernel. One of these hacks is to pull the wait_queue_head out of struct page; the waitq-heads are in a separate allocated area of memory, with a waitq-head pointer embedded in the page structure (allocated/initialised in free_area_init_core()). This gives a page structure of 60bytes, giving me one free double-word to play with (which I'm using as a pointer to a release function). Infact, there doesn't need to be a waitq-head allocated for each page structure - they can share; with a performance overhead on a false wakeup in __wait_on_page(). Note, for those of us running on 32bit with lots of physical memory, the available virtual address-space is of major consideration. Reducing the size of the page structure is more than just reducing cache misses - it gives us more virtual to play with... Mark - To unsubscribe from this list: send 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: aic7xxx 2.4.0 test12 hang
>> While I am in the code I also want to go digging around and see if I >> can find a >> way to turn of the in memory buffering that Linux does for block devices >> as this >> would make my fscking a LOT shorter, (18 gigs is slow), > >No, because you need to do the ordering too. You could drop reiserfs on the >disk if you are feeling adventurous as that will cut your fsck time right >down. Good point, sigh , I will look into reserfs but my adventurous nature is getting a good beat down lately. >> > i've read about similar hangs on an alpha on this list (same kind of >controller) >> > any solution there ... > >AIC7xxx makes invalid uses of 32bit values for set_bit() and friends so it >may be that for the Alpha and the like problems A CLUE! Cool I will dig into this weekend. Thanks a lot Leslie Donaldson This was also sent to me >> would make my fscking a LOT shorter, (18 gigs is slow), > >18G is small by today's standards. so I suspect the problem is >actually that you have sub-4K blocks, and or haven't enabled >sparse superblocks. both fairly dramatically speed up fsck. True 18 gigs is small and yes I don't have those two options turned on , but my problem is this crash occures while Writing to the drive not reading. So, Out of an estimated 24 crashes every last one of them have caused me to enter single user mode manually run e2fsck on the partition and hold down th y key for a few minutes. Then after booting I have to go and clean out the directory which (1-3) times results in another crash. Rexecute loop. What I was thinking about is if I could remove the buffer layer then I would have a lot less damage on the disk and maybe it could just reboot on it's own. sigh -- /\ Current Contractor: None |Leslie F. Donaldson | Current Customer : None |Computer Contractor | Skills: Unix/OS9/VMS/Linux/SUN-OS/C/C++/assembly | Have Computer will travel. | WWW : http://www.cs.rose-hulman.edu/~donaldlf \/ Email: mail:[EMAIL PROTECTED] Goth Code V1.1: GoCS$$ TYg(T6,T9) B11Bk!^1 C6b-- P0(1,7) M+ a24 n--- b++:+ H6'11" g m w+ r+++ D--~!% h+ s10 k+++ R-- Ssw LusCA++ - To unsubscribe from this list: send 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 09:40:54AM +0100, Jure Pecar wrote:
> problem on a similary configured 2.2.17 with VM-global patch 3. gcc
Good. Can you try to reproduce with 2.2.19pre3? (if you absolutely need raid
0.90 you can try again with 2.2.19pre3aa3 after backing out 04_wake-one-3 that
introduces a deadlocks spotted by Chris and that I'm debugging right now)
> select(7, [5], [6], NULL, {98, 547000}) = 1 (in [5], left {98, 21})
num_ready = fdwatch( tmr_mstimeout( ) );
if ( num_ready < 0 )
{
if ( errno == EINTR )
continue; /* try again */
syslog( LOG_ERR, "fdwatch - %m" );
exit( 1 );
}
> gettimeofday({978078109, 324744}, NULL) = 0
(void) gettimeofday( , (struct timezone*) 0 );
> accept(5, {sin_family=AF_INET, sin_port=htons(3687),
> sin_addr=inet_addr("62.76.36.242")}, [16]) = 7
httpd_get_conn( httpd_server* hs, int listen_fd, httpd_conn* hc )
[..]
hc->conn_fd = accept( listen_fd, , );
> fcntl(7, F_SETFD, FD_CLOEXEC) = 0
(void) fcntl( hc->conn_fd, F_SETFD, 1 );
> fcntl(7, F_GETFL) = 0x2 (flags O_RDWR)
flags = fcntl( c->hc->conn_fd, F_GETFL, 0 );
> fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)= 0
else if ( fcntl( c->hc->conn_fd, F_SETFL, flags | O_NDELAY ) < 0 )
> brk(0x8078000) = 0x8077000
> brk(0x8078000) = 0x8077000
for some unknown reason it doesn't notice it has to handle the new connection.
> time([978078109]) = 978078109
> getpid()= 22061
> send(3, "<27>Dec 29 09:21:49 thttpd[22061"..., 69, 0) = 69
shut_down();
syslog( LOG_NOTICE, "exiting" );
> munmap(0x125000, 4096) = 0
> _exit(1)= ?
However according to the latest sources (2.20b) shut_down() should at least
call gettimeofday at once and that's not the case for you:
shut_down( void )
{
int cnum;
struct timeval tv;
#ifdef STATS_TIME
show_stats( JunkClientData, (struct timeval*) 0 );
#endif /* STATS_TIME */
(void) gettimeofday( , (struct timezone*) 0 );
So you aren't using thttpd version 2.20b (or it's not the vanilla source).
Well, this would look like an userspace bug, but I understand it's strange that
it works well for three days Can you try to upgrade thttpd to the latest
version compiled from vanilla sources?
But regardless of the userspace upgrade, I still recommend to upgrade to
2.2.19pre3 or 2.2.19pre3aa3 minus 04_wake-one-3 (once I'll fix wake-one-3 I'll
release -4 revision and pre3aa4).
Thanks,
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/
SCSI Problems since upgrade from 2.2.16
Hello: I'm running an HP DAT 4mm Autochanger here and since going to 2.2.17 and 2.2.18 I'm seeing failures when it attempts to unload the tape and load a new one while backing up using BRU PE...utilizing the mt or mtx commands as follows: mt -f $DEV rewoffl 2>&1 >/dev/null OR /usr/local/bin/mtx -f /dev/sg1 eject 2>&1 >/dev/null If I use the MTX command set to "manually" change the tapes all is wellany thoughts on the cause or a fix...I don't think the hardware is broken due to the fact it runs fine "manually" by doing the mtx -f /dev/sg1 next commnand to load the next tape Pertinent info below: Information about installed SCSI devices Attached devices: Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: SEAGATE Model: ST32550N Rev: 0021 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 03 Lun: 00 Vendor: HP Model: C1553A Rev: NS01 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 03 Lun: 01 Vendor: HP Model: C1553A Rev: NS01 Type: Medium Changer ANSI SCSI revision: 02 Bus 0, device 9, function 0: SCSI storage controller: Adaptec AIC-7850 (rev 1). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=32. Min Gnt=4.Max Lat=4. I/O at 0xd000 [0xd001]. Non-prefetchable 32 bit memory at 0xdf00 [0xdf00]. SCSI support CONFIG_SCSI = 1 CONFIG_BLK_DEV_SD = 1 CONFIG_CHR_DEV_ST = 1 CONFIG_BLK_DEV_SR = 1 CONFIG_CHR_DEV_SG = 1 CONFIG_SCSI_MULTI_LUN = 1 CONFIG_SCSI_CONSTANTS = 1 CONFIG_SCSI_LOGGING = 1 SCSI low-level drivers CONFIG_SCSI_AIC7XXX = 1 CONFIG_AIC7XXX_CMDS_PER_DEVICE = (8) CONFIG_AIC7XXX_RESET_DELAY = (5) > Len: 20480 > > Dec 23 01:24:37 eagle kernel: [valid=0] Info fld=0x0, EOM Current > st09:00: sense key None > Dec 23 01:24:37 eagle kernel: Additional sense indicates > End-of-partition/medium detected > Dec 23 01:24:37 eagle kernel: st0: Async write error (write) 7fff. > Dec 23 01:24:40 eagle kernel: st0: File length 641863680 bytes. > Dec 23 01:24:40 eagle kernel: st0: Async write waits 30037, finished > 1304. > Dec 23 01:24:42 eagle kernel: st0: Error: 2802, cmd: 10 0 0 0 1 0 > Len: 0 > Dec 23 01:24:42 eagle kernel: [valid=0] Info fld=0x0, FMK EOM Current > st09:00: sense key None > Dec 23 01:24:42 eagle kernel: Additional sense indicates > End-of-partition/medium detected > Dec 23 01:24:42 eagle kernel: st0: Buffer flushed, 1 EOF(s) written ===[George R. Kasica]===+1 262 513 8503 President +1 206 374 6482 FAX Netwrx Consulting Inc. Waukesha, WI USA http://www.netwrx1.com [EMAIL PROTECTED] ICQ #12862186 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PowerPC branch out of date
Hi Linus, I'm one of the folks that works on the PowerPC portion of the kernel. I've noticed for some time that what's available at kernel.org and what's being worked on by those of us who maintain our little portion of the PowerPC tree is more and more out of sync. How it's got there etc etc etc at this stage isn't important. First how to fix it and how to make sure it doesn't happen again does concern me. Currently the diff between test13-preX and the master fsmlabs.com ppc tree is about 450k. Is the right thing to start with that patch get that into the test13-preX series? I would REALLY appreciate it if this could be made to happen. I've got a whole boatload of RS/6000 (aka pSeries) hardware that will be starting to work once this patch is in. It's truely a shame to have to explain to people that kernel.org *SHOULD* be the place to get a good kernel but given that things are out of sync to have to point them somewhere else. Regards, Tom -- Tom Gall - PowerPC Linux Team"Where's the ka-boom? There was Linux Technology Center supposed to be an earth (w) [EMAIL PROTECTED] shattering ka-boom!" (w) 507-253-4558 -- Marvin Martian (h) [EMAIL PROTECTED] http://oss.software.ibm.com/developerworks/opensource/linux - To unsubscribe from this list: send 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, Dec 29, 2000 at 01:06:30AM +, Albert Cranford wrote: > Simply executing > *p++ = htonl(fl->fl_pid); > before > start = loff_t_to_s64(fl->fl_start); > also works. Yes, confirmed. Since you're located in Florida I vote for this and I hope that Linus will elect it. :) --- linux/fs/lockd/xdr4.c.orig Fri Dec 29 01:35:32 2000 +++ linux/fs/lockd/xdr4.c Fri Dec 29 14:56:07 2000 @@ -167,13 +167,13 @@ || (fl->fl_end > NLM4_OFFSET_MAX && fl->fl_end != OFFSET_MAX)) return NULL; + *p++ = htonl(fl->fl_pid); start = loff_t_to_s64(fl->fl_start); if (fl->fl_end == OFFSET_MAX) len = 0; else len = loff_t_to_s64(fl->fl_end - fl->fl_start + 1); - *p++ = htonl(fl->fl_pid); p = xdr_encode_hyper(p, start); p = xdr_encode_hyper(p, len); -- 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: [PATCH] Processor autodetection (when configuring kernel)
On Fri, Dec 29, 2000 at 02:39:42PM +0100, Giacomo A. Catenazzi wrote:
> +{TransmetaCPU,GenuineTMx86}:* ) echo CONFIG_MCROSUE ;;
+{TransmetaCPU,GenuineTMx86}:* ) echo CONFIG_MCRUSOE ;;
This is just a typo, right? ;-)
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag
come and join the fun
-
To unsubscribe from this list: send 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] Processor autodetection (when configuring kernel)
Giacomo,
Further experimentation has revealed another problem with the script. The
use of curly braces in the case statement, i.e.
GenuineIntel:6:{8,9,11}) echo CONFIG_M686FXSR ;;
does not work. The construct below works, but I don't like it because of
its length:
GenuineIntel:6:8|GenuineIntel:6:9|GenuineIntel:6:11) echo
CONFIG_M686FXSR ;;
David
David Relson Osage Software Systems, Inc.
[EMAIL PROTECTED] Ann Arbor, MI 48103
www.osagesoftware.com tel: 734.821.8800
-
To unsubscribe from this list: send 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] Processor autodetection (when configuring kernel)
Giacomo,
I don't think cpu_info.sh is quite right. It identified my 500 Mhz Pentium
III as CONFIG_M386. I think CONFIG_M686 is closer, but as I don't know the
significance of all the flags (MMX, TSC, etc), I'm not certain. Since the
flags do include fxsr, the correct answer may be CONFIG_M686FXSR.
Anyhow, here are my results:
[relson@osage relson]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping: 3
cpu MHz : 501.147
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36
mmx fxsr xmm
bogomips: 999.42
[relson@osage relson]$ ARCH=i386 ; . cpu_detect.sh
GenuineIntel:6:7
CONFIG_M386
Also, here's a patch to make the script echo CONFIG_M686:
diff -urN cpu_detect.sh.orig cpu_detect.sh
--- cpu_detect.sh.orig Fri Dec 29 09:02:27 2000
+++ cpu_detect.sh Fri Dec 29 09:01:14 2000
@@ -18,7 +18,7 @@
case $cpu_id in
GenuineIntel:5:[0123] ) echo CONFIG_M586TSC ;;
GenuineIntel:5:[48]) echo CONFIG_M586MMX ;;
-GenuineIntel:6:[01356] ) echo CONFIG_M686 ;;
+GenuineIntel:6:[013567]) echo CONFIG_M686 ;;
GenuineIntel:6:{8,9,11}) echo CONFIG_M686FXSR ;;
AuthenticAMD:5:[0123] ) echo CONFIG_M586 ;;
AuthenticAMD:5:{8,9,10,11} ) echo CONFIG_MK6 ;;
David
P.S. I'm running 2.2.18, if it matters.
David Relson Osage Software Systems, Inc.
[EMAIL PROTECTED] Ann Arbor, MI 48103
www.osagesoftware.com tel: 734.821.8800
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
