Re: ps2 keyboard filter hook
On Fri, 15 Jun 2001, Dan Streetman wrote: >Date: Fri, 15 Jun 2001 17:03:38 -0400 (EDT) >From: Dan Streetman <[EMAIL PROTECTED]> >To: Jeff Garzik <[EMAIL PROTECTED]> >Cc: Linux Kernel <[EMAIL PROTECTED]> >Content-Type: TEXT/PLAIN; charset=US-ASCII >Subject: Re: ps2 keyboard filter hook > > >>Didn't we just conclude a discussion here on linux-kernel, which said >>that patches which simply add hooks allowing proprietary extensions are >>not accepted into the kernel? > >Yes (I assume you mean the whole 'sockreg' register/unregister thread(s)...;-) > >I never intended to get that patch in. In fact I would be shocked (and a bit >horrified) if it was accepted. > >But management doesn't listen to me when I say it will never get accepted so I >had to make a token effort of submitting it to prove it won't get accepted. > >And I did try hard to convince them to release the actual driver but it didn't >work. I find it very odd indeed with IBM's big voice of open source praise, yada yada, and what Lou has said in the past, that there would be any question at all of wether it would be open source or not. Isn't big blue behind open source? Or is it just for publicity? Makes me wonder now... Must be some real good rocket science in that interface that theres no way on earth someone else could come up with it for it to be important IP to protect. Makes me wonder what's hiding behind it... -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- DISCLAIMER - These opoi^H^H "damn", ^H, [esc :q :qq !q "shoot!" :Q! "Whaddya mean, Not an editor command?" :wq! ^C^C^C !STOP ^bye ^quit :quit! !halt ... ^w^q :!w :wq! ^D :qq!! ^STOP [HALT! HALT!!! "Why's it doing this?" :stopit! :wwqq!! ^Z ^L ^ESC STOP :bye bye bye! "Hey, what's this red button d..." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nonblinking VGA block cursor
On Sat, Jun 16, 2001 at 05:52:39AM +0200, Mike Galbraith wrote: > On Fri, 15 Jun 2001, Albert D. Cahalan wrote: > > Ever wonder why IBM supports Linux instead of FreeBSD? Hmmm? > > I bet it has more to do with growth curves than cursor style :) don't kid yourself. cursor style is the #1 reason for OS adoption in the US. -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: 24 horas num dia, 24 cervejas numa caixa. Coincidência? PGP signature
Re: [patch] nonblinking VGA block cursor
On Fri, 15 Jun 2001, Albert D. Cahalan wrote: > Of course FreeBSD has a block cursor. It was easy to program, > and it seems nice to the pot-smoking hippies out in Berkeley. > FreeBSD doesn't define standards. FreeBSD breaks standards. > (zombie creation, "ps -ef", partition tables, pty allocation...) > Gee, kind of like Microsoft, except Microsoft got the cursor right! > > Ever wonder why IBM supports Linux instead of FreeBSD? Hmmm? I bet it has more to do with growth curves than cursor style :) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Snowhite and the Seven Dwarfs - The REAL story!
Em Fri, Jun 15, 2001 at 08:11:35PM -0700, Michael Peddemors escreveu: > Or even better.. Rik? Are you using Microsoft again? > Now we get em in Spanish too.. Even Virus's sound better in Spanish.. > Or is that Portugese? yup, portuguese, I already got this damn virus in portuguese, english, spanish, french... ;( - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
psaux mouse driver + inland pro optical 100 mouse
Under linux 2.4.1 if I move the mouse slow enough it doesn't register at all in Xwindows. If I unplug the ps2 mouse and plug it back in, it works perfectly, no matter how slowly I move it the movement is registered. It is as if the linux kernel is imposing a threshold on the movement. Under windows it works fine. The problem is in linux. I've tried modifying pc_keyb.c code by sending an F6 byte to set defaults, using the aux_write_ack function in open_aux(), but that doesn't have any effect. Does anyone have a clue what the driver is doing to reduce the quality of the mouse? I'm not sure it is limited to this particular mouse, it is just the one I just bought at Fry's for $10. I'm running an athlon 1 gig, /proc/version is Linux version 2.4.1 (root@dave) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #17 Fri Jun 15 20:15:45 PDT 2001 Thanks! -Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Snowhite and the Seven Dwarfs - The REAL story!
Or even better.. Rik? Are you using Microsoft again? Now we get em in Spanish too.. Even Virus's sound better in Spanish.. Or is that Portugese? (Personally, I block em at the mailer, to protect those poor unfortunates that haven't switched to Linux Yet) Content-Type: application/octet-stream; name="enano porno.exe" ==> virus-20010614-12825 <== Received: (qmail 11723 invoked by uid 1004); 14 Jun 2001 23:28:19 - Received: from dl-tnt2-c8b06e1e.rio.terra.com.br (HELO paulo) (200.176.110.30) by mail.wizard.ca with SMTP; 14 Jun 2001 23:28:19 - From: Hahaha <[EMAIL PROTECTED]> Subject: Branca de Neve pornô! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--VE56J8TYRO9ABG1INC9EB8HU3" X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) On 15 Jun 2001 17:02:05 -0700, J Sloan wrote: > Tobias Ringstrom wrote: > > > Ah... the joy of reading mail using non-MS software, on a non-MS OS... > > > > Hahaha, indeed! > > Indeed, since: > > Jun 15 15:39:03 mirai sendmail[21499]: f5FMd2t21499: > from=<[EMAIL PROTECTED]>, size=33547, class=-60, nrcpts=1, > msgid=<[EMAIL PROTECTED]>, bodytype=7BIT, proto=ESMTP, daemon=MTA, > relay=freeside.toyota.com [63.87.74.7] > Jun 15 15:39:03 mirai scanmails[21501]: execution started > Jun 15 15:39:04 mirai scanmails[21501]: FOUND VIRUS IN MAIL from > [EMAIL PROTECTED] to jjs > > cu > > jjs > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > -- "Catch the Magic of Linux..." Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5-ac6 and 2.4.4-ac11 boot fails with APIC timer
> The message on the screen > > calibrating APIC timer . > CPU clock speed is 1395.7390MHz > ... host bus clock speed is 0. MHz > cpu: 0, clocks: 0, slic: 0 > > Then nothing. I had to push the reset button at this point. > ACPI and APM were disabled from the kernel config. > > This boot failure messages was obtained from > Pentium4 board GB-450(?) from Intel, NVIDIA M64 video. > Sound Blaster 128 PCI. Netgear PNIC fast ethernet > > The same kernel was able to boot up the other Pentium 4 board from > Gigabyte flawlessly. So, it depends on the motherboard manufacturers. > > Regards to all. > > G. Hugh Song Replying to my own message: When I chose "No" to "APIC support on uniprocessors", the above error message disappeared and the machine booted up OK with 2.4.5-ac13. Please refer to the following diff: diff .config.old .config 63,65c63 < CONFIG_X86_UP_APIC=y < # CONFIG_X86_UP_IOAPIC is not set < CONFIG_X86_LOCAL_APIC=y --- > # CONFIG_X86_UP_APIC is not set I think that APIC thing was defined by Intel themselves. They should have implemented it the best. How much penalty do I pay by not choosing "yes" to "APIC support on uniprocessors"? Best regards, G. Hugh Song - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tulip.c
Dear sirs,
Few year ago, I wrote patch for tulipl.c(kernel-version 2.0.35)
that works on MX98715,and I found that it mostly work version 2.2.1 and 2.2.11.
So I'll send patch for tulip.c(kernel-version 2.2.1, 2.2.11)
I tested it on 2.2.1 to 2.2.13, but I think it should work on 2.2.1 to 2.2.13.
Not need on later 2.2.14
Masaki
--
--- linux-2.2.1-org/drivers/net/tulip.c Wed Jan 20 06:18:45 1999
+++ linux-2.2.1-fw/drivers/net/tulip.c Thu Mar 8 06:50:51 2001
@@ -317,7 +317,7 @@
enum tulip_offsets {
CSR0=0,CSR1=0x08, CSR2=0x10, CSR3=0x18, CSR4=0x20, CSR5=0x28,
CSR6=0x30, CSR7=0x38, CSR8=0x40, CSR9=0x48, CSR10=0x50, CSR11=0x58,
- CSR12=0x60, CSR13=0x68, CSR14=0x70, CSR15=0x78 };
+ CSR12=0x60, CSR13=0x68, CSR14=0x70, CSR15=0x78, CSR20=0xa0 };
/* The bits in the CSR5 status registers, mostly interrupt sources. */
enum status_bits {
@@ -817,11 +817,17 @@
outl(0x0201F078, ioaddr + 0xB8); /* Turn on autonegotiation. */
}
break;
- case MX98713: case MX98715: case MX98725:
+ case MX98713:
outl(0x, ioaddr + CSR6);
outl(0x000711C0, ioaddr + CSR14); /* Turn on NWay. */
outl(0x0001, ioaddr + CSR13);
break;
+ case MX98715: case MX98725:
+ outl(0x03a60200, ioaddr + CSR6);
+ outl(0x000711C4, ioaddr + CSR14); /* Turn on NWay. */
+ outl(0x0001, ioaddr + CSR13);
+ outl(inl(ioaddr + CSR9)|0x3000L, ioaddr + CSR9);
+ break;
}
return dev;
@@ -1543,9 +1549,9 @@
if (media_cap[dev->if_port] & MediaIsMII) {
new_csr6 = 0x020E;
} else if (media_cap[dev->if_port] & MediaIsFx) {
- new_csr6 = 0x02860;
+ new_csr6 = 0x0286;
} else
- new_csr6 = 0x03860;
+ new_csr6 = 0x0382;
if (tulip_debug > 1)
printk(KERN_DEBUG "%s: No media description table, assuming "
"%s transceiver, CSR12 %2.2x.\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
First a little more data on the problem. 1) I've never seen it with the client and server program on the same computer. 2) It only repros on some systems. If I can repro it on some systems and then make the client the server and the server the client the bug will often fail to repro. 3) Once it repros it _consistently_ repros seemingly independent of kernel versions. Second, I really don't think it is a problem with the server. Running the test a few times I get the following behavior. The client reads up to message #19 before failing to ack, the server program keeps executing "prints" until the send buffer fills and then blocks on the next print at message #25. "netstat -t" on the server shows the following tcp0 8688 manny-out:20001 glottis:33193 ESTABLISHED If I run the test a few more times, the client will block on a different message (6,5,10,etc) and the server program will continue to fill the buffer with the same amount of data before blocking. What is more interesting to me is that if I add print statements before and after the client "recv" call then it appears that the client is blocking within the receive call. If I packet sniff the client then I see lots of packets from the server with happy acks from the client until one packet does not receive an ack. The server then does the right thing and resends the non-acked packet at increasing time intervals. Eventually the client sends an ack for the previously received packet (not the most recent that is being resent. This exchange continues indefinitely. I've appended a commented packet log to the end of this email. So the client app is in the recv call waiting for data and the interface is receiving the packet that should satisfy that block. Why would the client not be sending an ack? If the buffer is full then shouldn't the thread be returning from the recv call and releasing some of that data? One person emailed me a possible gotcha is that SIGINT is being triggered somehow by the system call but I added a trap to the original java app and now to the little perl script and it seems to never be triggered. Any other ideas for areas to investigate? Robert. Here are the logs. packet A sent 20:15:21.703718 < manny.20001 > glottis-in.33088: P 14729:14984(255) ack 1 win 5792 (DF) packet B sent 20:15:21.713719 < manny.20001 > glottis-in.33088: . 14984:16432(1448) ack 1 win 5792 (DF) ack up to packet B 20:15:21.713719 > glottis-in.33088 > manny.20001: . 1:1(0) ack 16432 win 34752 (DF) packet C sent 20:15:21.713719 < manny.20001 > glottis-in.33088: P 16432:16714(282) ack 1 win 5792 (DF) packet D sent 20:15:21.713719 < manny.20001 > glottis-in.33088: . 16714:18162(1448) ack 1 win 5792 (DF) ack up to packet D 20:15:21.713719 > glottis-in.33088 > manny.20001: . 1:1(0) ack 18162 win 37648 (DF) packet E sent 20:15:21.723719 < manny.20001 > glottis-in.33088: P 18162:18420(258) ack 1 win 5792 (DF) packet F sent 20:15:21.733719 < manny.20001 > glottis-in.33088: . 18420:19868(1448) ack 1 win 5792 (DF) packet G sent 20:15:21.743719 < manny.20001 > glottis-in.33088: . 19868:21316(1448) ack 1 win 5792 (DF) ack up to packet E 20:15:21.743719 > glottis-in.33088 > manny.20001: . 1:1(0) ack 18420 win 37648 (DF) packet H sent 20:15:21.743719 < manny.20001 > glottis-in.33088: P 21316:22139(823) ack 1 win 5792 (DF) ack up to packet E 20:15:21.743719 > glottis-in.33088 > manny.20001: . 1:1(0) ack 18420 win 37648 (DF) packet I sent 20:15:21.763720 < manny.20001 > glottis-in.33088: . 22139:23587(1448) ack 1 win 5792 (DF) ack up to packet E 20:15:21.763720 > glottis-in.33088 > manny.20001: . 1:1(0) ack 18420 win 37648 (DF) resend packet F many times in increasing time intervals. Why does the client not ack this? 20:15:21.763720 < manny.20001 > glottis-in.33088: . 18420:19868(1448) ack 1 win 5792 (DF) 20:15:21.973726 < manny.20001 > glottis-in.33088: . 18420:19868(1448) ack 1 win 5792 (DF) 20:15:22.413738 < manny.20001 > glottis-in.33088: . 18420:19868(1448) ack 1 win 5792 (DF) 20:15:23.293761 < manny.20001 > glottis-in.33088: . 18420:19868(1448) ack 1 win 5792 (DF) 20:15:25.053809 < manny.20001 > glottis-in.33088: . 18420:19868(1448) ack 1 win 5792 (DF) 20:15:28.573905 < manny.20001 > glottis-in.33088: . 18420:19868(1448) ack 1 win 5792 (DF) 20:15:35.614095 < manny.20001 > glottis-in.33088: . 18420:19868(1448) ack 1 win 5792 (DF) ack up to packet E 20:15:41.964268 > glottis-in.33088 > manny.20001: F 1:1(0) ack 18420 win 37648 (DF) Not sure what this is for... 20:15:41.964268 < manny.20001 > glottis-in.33088: . 23587:23587(0) ack 2 win 5792 (DF) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nonblinking VGA block cursor
On Saturday 16 June 2001 02:03, Josh Myer wrote: > Anyway, this is a silly discusson in general, i figured i would throw in > my $0.02 (strong US cents!) It's a slow news day ;-) -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: Snowhite and the Seven Dwarfs - The REAL story!
Tobias Ringstrom wrote: > Ah... the joy of reading mail using non-MS software, on a non-MS OS... > > Hahaha, indeed! Indeed, since: Jun 15 15:39:03 mirai sendmail[21499]: f5FMd2t21499: from=<[EMAIL PROTECTED]>, size=33547, class=-60, nrcpts=1, msgid=<[EMAIL PROTECTED]>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=freeside.toyota.com [63.87.74.7] Jun 15 15:39:03 mirai scanmails[21501]: execution started Jun 15 15:39:04 mirai scanmails[21501]: FOUND VIRUS IN MAIL from [EMAIL PROTECTED] to jjs cu jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nonblinking VGA block cursor
On Sat, 16 Jun 2001, Daniel Phillips wrote: > Ask the original poster if he's willing to take the risk of going with an xor > cursor. We are talking text mode, right? No way to get rid of that blinking > text cursor, ever. Tell me, do you like having the colon blink on your alarm > clock too? Personally, I opened the thing up and put a piece of tape over it. > Aha! A software weenie! A real hardware hacker would have snipped and soldered it to VCC to get a constant (or add a switch for solid/blink =). In any case, this strikes me as a matter of policy. I don't care one way or the other, but if people want a solid cursor, it's not something that we can really deny them that (unless it's a binary-only driver for the cursor, of course). Anyway, this is a silly discusson in general, i figured i would throw in my $0.02 (strong US cents!) > IBM had lots of ideas about how computers should work. Remember the keyboard > keys that when CLACK CLACK CLACK. Thank god they turned out to be too > expensive to clone - nobody misses them now. > *CLACK CLACK CLACK* (posted with a Model M) -- /jbm, but you can call me Josh. Really, you can. "When lasers are outlawed, only outlaws will have lasers" -- from http://www.altair.org/CO2laser.htm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Snowhite and the Seven Dwarfs - The REAL story! (VIRUS ALERT)
NM --- Matthew Dharm <[EMAIL PROTECTED]> wrote: > No kidding... getting this once was funny enough on > this mailing list... > but twice in the same day? I am just rolling in the > asiles here... > > Matt > > On Sat, Jun 16, 2001 at 01:34:59AM +0200, Tobias > Ringstrom wrote: > > On Fri, 15 Jun 2001, Hahaha wrote: > > > > > Today, Snowhite was turning 18. The 7 Dwarfs > always where very educated and > > > polite with Snowhite. When they go out work at > mornign, they promissed a > > > *huge* surprise. Snowhite was anxious. > Suddlently, the door open, and the Seven > > > Dwarfs enter... > > > > Ah... the joy of reading mail using non-MS > software, on a non-MS OS... > > > > Hahaha, indeed! > > > > /Tobias > > > > > > - > > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at > http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- > Matthew Dharm Home: > [EMAIL PROTECTED] > Maintainer, Linux USB Mass Storage Driver > > S: Another stupid question? > G: There's no such thing as a stupid question, only > stupid people. > -- Stef and Greg > User Friendly, 7/15/1998 > > ATTACHMENT part 2 application/pgp-signature __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Buffer management - interesting idea
Hello, please CC: replies to me, since I'm not subscribed to the list. On Fri, 15 Jun 2001 15:50:33 -0300 (BRST) Rik van Riel <[EMAIL PROTECTED]> wrote: > On Fri, 15 Jun 2001, Ivan Schreter wrote: >> In 2Q, when a page is present in LRU queue, you move it to the front of >> [...] > This description has me horribly confused. Do you have > any pointers to state diagrams of this thing? ;) Well, I posted an URL where is complete paper about 2Q, here it is again: http://citeseer.nj.nec.com/63909.html (click there in top right corner on download PS or PDF). In general, it is like LRU, but the pages make it into LRU only after going through FIFO. So a page which is requested only once (or few times in a row) will pass through this FIFO and be swapped out. When a page is actively used, it will pass through FIFO and on a new request for this page it will not be loaded into FIFO, but into LRU. Since FIFO is small relative to LRU (10% or so), you don't waste buffer space for long time for once (or few times) used pages which are not needed anymore (like big find, cat, dd, etc.). The trick is how to determine whether the page should be loaded into FIFO or into LRU at swap-in. And here comes another queue - they call it A1out in original paper. This queue (or cyclic buffer or whatever) is another FIFO queue, which stores INDICES of physical pages, which were swapped out of FIFO queue (and lived only shortly). When a page is found in this A1out queue, it is put into LRU (it is a "hot" page) and will live longer in LRU list. A1out queue size is up to experiments, I used 50% of memory buffer count and it performed well. And yes, look into the program I posted last time, look into functions r2q_page(), which loads a page into buffer and r2q_reclaim() which swaps out a page to make space. I was also doing some experiments with not swapping out hot pages out of FIFO queue (USE_FASTPAGE conditional), but they didn't bring any reasonable improvement (few tenths of percent up or down from original performance), so it's probably not worth it. BTW, this 2Q algorithm can be well used for madvise() syscall implementation, like this: - NORMAL - no change - RANDOM - no change - SEQUENTIAL - load pages in FIFO and DON'T put them in A1out after expiry - WILLNEED - load pages directly in LRU - DONTNEED - move pages to FRONT of FIFO (or TAIL of LRU) (see BSD madvise() syscall, but I believe you know what I'm talking about ;-) BTW2, I'm quite happy that people care about new ideas :-) I would be happy to hack the kernel full-time and implement them myself, but unfortunately I need to make money out of something, so no time :-) -- Ivan Schreter [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] blkdev_size_in_bytes
People want to read the last sector on a disk, but our present
code does not easily allow that, since size checking is done
in units of 1024 bytes, not in units of 512 bytes.
We have seen very ugly solutions ("add an ioctl to read the last sector")
and very kludgy solutions ("create a partition that starts at an odd sector,
just before the end of the disk").
In reality of course we just want to have finer grainer information
and do the checking right.
Below an example.
[blk_size can be replaced by blk_size_in_bytes once all drivers
have been adapted; here I only did the ide part]
[By the way, this presupposes the presence of the BLKGETBSZ/BLKSETBSZ
ioctls. We have seen several versions of that patch already.
My current version can be found on ftp.kernel.org under people/aeb.]
Andries
--
diff -u --recursive --new-file ../linux-2.4.6-pre3a/linux/drivers/block/blkpg.c
./linux/drivers/block/blkpg.c
--- ../linux-2.4.6-pre3a/linux/drivers/block/blkpg.cSat Jun 16 00:16:08 2001
+++ ./linux/drivers/block/blkpg.c Sat Jun 16 00:43:37 2001
@@ -207,6 +207,7 @@
int blk_ioctl(kdev_t dev, unsigned int cmd, unsigned long arg)
{
int intval;
+ long longval;
switch (cmd) {
case BLKROSET:
@@ -242,21 +243,14 @@
return 0;
case BLKSSZGET:
- /* get block device sector size as needed e.g. by fdisk */
+ /* get block device hardware sector size */
intval = get_hardsect_size(dev);
return put_user(intval, (int *) arg);
-#if 0
case BLKGETSIZE:
- /* Today get_gendisk() requires a linear scan;
- add this when dev has pointer type. */
- g = get_gendisk(dev);
- if (!g)
- longval = 0;
- else
- longval = g->part[MINOR(dev)].nr_sects;
+ /* get block device size in 512-byte sectors */
+ longval = (blkdev_size_in_bytes(dev) >> 9);
return put_user(longval, (long *) arg);
-#endif
#if 0
case BLKRRPART: /* Re-read partition tables */
if (!capable(CAP_SYS_ADMIN))
diff -u --recursive --new-file ../linux-2.4.6-pre3a/linux/drivers/block/ll_rw_blk.c
./linux/drivers/block/ll_rw_blk.c
--- ../linux-2.4.6-pre3a/linux/drivers/block/ll_rw_blk.cSat Jun 16 00:16:02
2001
+++ ./linux/drivers/block/ll_rw_blk.c Sat Jun 16 00:38:04 2001
@@ -76,7 +76,7 @@
/*
* blk_size contains the size of all block-devices in units of 1024 byte
- * sectors:
+ * blocks; it is obsoleted by blk_size_in_bytes
*
* blk_size[MAJOR][MINOR]
*
@@ -85,6 +85,17 @@
int * blk_size[MAX_BLKDEV];
/*
+ * blk_size_in_bytes contains the size of all block-devices in bytes
+ * (blk_size has too low a resolution, since we really need the size
+ * in 512 byte sectors, and fails on devices > 2 TB)
+ *
+ * blk_size_in_bytes[MAJOR][MINOR]
+ *
+ * if (!blk_size_in_bytes[MAJOR]) then no minor size checking is done.
+ */
+loff_t * blk_size_in_bytes[MAX_BLKDEV];
+
+/*
* blksize_size contains the size of all block-devices:
*
* blksize_size[MAJOR][MINOR]
@@ -858,35 +869,29 @@
* */
void generic_make_request (int rw, struct buffer_head * bh)
{
- int major = MAJOR(bh->b_rdev);
- int minorsize = 0;
+ unsigned long maxsector;
request_queue_t *q;
if (!bh->b_end_io)
BUG();
/* Test device size, when known. */
- if (blk_size[major])
- minorsize = blk_size[major][MINOR(bh->b_rdev)];
- if (minorsize) {
- unsigned long maxsector = (minorsize << 1) + 1;
+ maxsector = (blkdev_size_in_bytes(bh->b_rdev) >> 9);
+ if (maxsector) {
unsigned long sector = bh->b_rsector;
unsigned int count = bh->b_size >> 9;
if (maxsector < count || maxsector - count < sector) {
- /* Yecch */
- bh->b_state &= (1 << BH_Lock) | (1 << BH_Mapped);
-
/* This may well happen - the kernel calls bread()
without checking the size of the device, e.g.,
when mounting a device. */
printk(KERN_INFO
"attempt to access beyond end of device\n");
- printk(KERN_INFO "%s: rw=%d, want=%ld, limit=%d\n",
+ printk(KERN_INFO "%s: rw=%d, want=%ld, limit=%ld\n",
kdevname(bh->b_rdev), rw,
- (sector + count)>>1, minorsize);
+ (sector + count)>>1, maxsector>>1);
- /* Yecch again */
+
Re: Snowhite and the Seven Dwarfs - The REAL story!
On Fri, 15 Jun 2001, Hahaha wrote: > Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and > polite with Snowhite. When they go out work at mornign, they promissed a > *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven > Dwarfs enter... Ah... the joy of reading mail using non-MS software, on a non-MS OS... Hahaha, indeed! /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nonblinking VGA block cursor
On Friday 15 June 2001 21:38, Albert D. Cahalan wrote: > Daniel Phillips writes: > > On Friday 15 June 2001 21:21, Albert D. Cahalan wrote: > >> Non-blinking cursors are just wrong. You need to patch your brain. > >> You really fucked up, because now apps can't restore your cursor > >> to proper behavior as defined by IBM. > > > > Just one question Albert: why doesn't my mouse cursor blink? ;-) > > 1. confusion with the text cursor, which should blink > 2. need for continuous pixel-to-pixel accuracy with the mouse > 3. you can wiggle your mouse as needed to find the mouse cursor 4. It would be bloody annoying. Some people find the blinking text cursor equally annoying, you appear to be trying to dictate what their options should be. > Apps do funny things when you try to wiggle the text cursor > with the arrow keys, and movement tends to be harshly constrained. > So the blinking is important. Ask the original poster if he's willing to take the risk of going with an xor cursor. We are talking text mode, right? No way to get rid of that blinking text cursor, ever. Tell me, do you like having the colon blink on your alarm clock too? Personally, I opened the thing up and put a piece of tape over it. As I recall, one of the popular projects when the IBM PC first came out was trying to get the cursor to stop blinking. No luck, IBM had hardwired in a special trace to make sure you couldn't. You could or two blink patterns together, but never get it to stop. Since we are now in a position to dictate, why don't we continue that grand tradition. IBM had lots of ideas about how computers should work. Remember the keyboard keys that when CLACK CLACK CLACK. Thank god they turned out to be too expensive to clone - nobody misses them now. When people ask for such options it's not because they want to make *your* cursor stop blinking, it's because they want *theirs* to stop. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Snowhite and the Seven Dwarfs - The REAL story!
No kidding... getting this once was funny enough on this mailing list... but twice in the same day? I am just rolling in the asiles here... Matt On Sat, Jun 16, 2001 at 01:34:59AM +0200, Tobias Ringstrom wrote: > On Fri, 15 Jun 2001, Hahaha wrote: > > > Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and > > polite with Snowhite. When they go out work at mornign, they promissed a > > *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven > > Dwarfs enter... > > Ah... the joy of reading mail using non-MS software, on a non-MS OS... > > Hahaha, indeed! > > /Tobias > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver S: Another stupid question? G: There's no such thing as a stupid question, only stupid people. -- Stef and Greg User Friendly, 7/15/1998 PGP signature
Re: 2.4.2 yenta_socket problems on ThinkPad 240
On 6-Jun-2001, I reported: > I upgraded my IBM ThinkPad 240 (Type 2609-31U) from Red Hat 7.0 to > Red Hat 7.1, which uses the 2.4.2 kernel and the kernel PCMCIA drivers. > Before the upgrade, all my CardBus and PCMCIA devices were working fine. > Now the yenta_socket module seems to be causing problems, and none of > the cards work. Arjan van de Ven of Red Hat tracked my problem down to a broken BIOS, which is not configuring the TI PC1211 CardBus bridge correctly. Even IBM's latest BIOS for the ThinkPad 240, IRET75WW released 17-May-2001, has this problem. Apparently IBM has issued fixes for other ThinkPads because the problem occurs with Windows 2000, but since Windows 2000 is not supported on the ThinkPad 240, it is unlikely that they will fix it. A one line change to linux/include/asm-i386/pci.h fixes it: -#define pcibios_assign_all_busses()0 +#define pcibios_assign_all_busses()1 Given that this macro exists, I surmise that other people have been bitten by similar problems. So now my question is: Does it make sense to turn pcibios_assign_all_busses into a variable with a default value of zero, and implement a kernel argument to set it? That way people with broken BIOSes could solve it by simply adding the argument in their lilo.conf. In an ideal world the BIOSes would get fixed and such a workaround would be unnecessary, but in my experience trying to get a vendor to fix a BIOS problem is an exercise in futility. If no one is opposed to my proposed change, I'll be happy to generate a suitable patch and send it in. Thanks! Eric Smith - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] unpaired lock/unlock_kernel in fs/locks.c
Please apply the fix for unpaired lock/unlock_kernel in fs/locks.c
Andrey
--- fs/locks.c~ Fri Jun 15 17:14:05 2001
+++ fs/locks.c Fri Jun 15 19:16:31 2001
@@ -856,7 +856,7 @@
new_fl2 = locks_alloc_lock(0);
error = -ENOLCK; /* "no luck" */
if (!(new_fl && new_fl2))
- goto out;
+ goto out_nolock;
lock_kernel();
if (caller->fl_type != F_UNLCK) {
@@ -1004,6 +1004,7 @@
}
out:
unlock_kernel();
+out_nolock:
/*
* Free any unused locks.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ALi magik1 datasheet?
Does anyone have the ALi magik1 northbridge datasheet? (ALi M1647) The pdf "documentation" files on the ALi web site are just sales brochures. Yes, i've already asked ALi repeatedly in emails and filled out the online datasheet request forms and they have responded with deafening silence. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Snowhite and the Seven Dwarfs - The REAL story!
Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and polite with Snowhite. When they go out work at mornign, they promissed a *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven Dwarfs enter... >
Snowhite and the Seven Dwarfs - The REAL story!
Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and polite with Snowhite. When they go out work at mornign, they promissed a *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven Dwarfs enter... >
Re: ps2 keyboard filter hook
On Fri, Jun 15, 2001 at 06:14:05PM -0400, Dan Streetman wrote: > > >> Vojtech, could you comment on if the above is possible using the input > >layer? > > > >Yes, and quite easily it'll fit into the input layer. Basically the way > >to do it would be to open the PS/2 port in the filter driver (thus > >disabling the normal keyboard driver to open it) and then register a new > >PS/2 port which the normal keyboard driver would attach to. > > Sweet! Thanks. > > I assume this (along with the linux-console stuff) won't make it into the 2.4 > kernel for a while though, until after it's been in 2.5 for a while? It's planned for 2.5.0. If it'll make it back to 2.4.x, I can only hope. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Simple example of using slab allocator?
For 2.5, I'm planning on switching my driver over to the slab allocator, for a variety of reasons. Does anyone have a _dead_ simple example of how to use such a beast? I've seen the various web pages and document explaining the API, but I love to see working examples for reference (and to fill in the blanks). Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Okay, this isn't funny anymore! Let me down! I'll tell Bill on you!! -- Microsoft Salesman User Friendly, 4/1/1998 PGP signature
Re: ps2 keyboard filter hook
>> Vojtech, could you comment on if the above is possible using the input >layer? > >Yes, and quite easily it'll fit into the input layer. Basically the way >to do it would be to open the PS/2 port in the filter driver (thus >disabling the normal keyboard driver to open it) and then register a new >PS/2 port which the normal keyboard driver would attach to. Sweet! Thanks. I assume this (along with the linux-console stuff) won't make it into the 2.4 kernel for a while though, until after it's been in 2.5 for a while? Thanks again! -- Dan Streetman [EMAIL PROTECTED] -- 186,282 miles per second: It isn't just a good idea, it's the law! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac15
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org 2.4.5-ac15 o Enable MMX extensions on Cyrix MII (me) o Make pid on core dump configurable (Ben LaHaise) o Random UML fixups, add fcntl64/getdents64 (Jeff Dike) o Add multicast support to UML(Harland Welte) o Ensure promise raid driver doesnt look at non (Arjan van de Ven) disk devices o Fix IDE chipsets that incorrectly think a 64K (Mark Lord) DMA is in fact zero size o Fix generic alpha build trident driver (Michal Jaegermann) o SHM accounting fixes(Christoph Rohland) o Update refill_inactive to match Linus tree (Rik van Riel) o Add Asustek L8400K to the dmi data (me) o Add kernel mode keyboard rate setup (Sergey Tursanov) o Alpha compile fix (Richard Henderson) o Add Ali1533 to the isa dma quirks (Angelo Di Filippo) o Fix a procfs oops (Al Viro) o Alpha symbol/warning fixes (Michal Jaegermann) o Some laptops take a long time for the cs4281(Rik van Riel) and codec bus to wake up o Fix potential flags corruption on error path(me) in comx-mixcom driver 2.4.5-ac14 o Fix oops on command abort on aha152x(me) | This so far is only a partial fix o Switch to unlazy swap cache free up (Marcelo Tosatti) o Page launder changes(Rik van Riel) o Remove dead irda irlap compression code (Dag Brattli) o Fix bug where init/main.c executes freed code (Hans-Peter Nilsson) o Fix ramfs accounting. truncate/freepage hook(Christoph Rohland) o Add MTWEOF ioctl to parallel tape (Russ Ingram) o Add driver for CATC based USB ethernet (Vojtech Pavlik) o Update cris architecture code (Bjorn Wesen) o Clean up reiserfs tail->full page convert (Chris Mason) o Clean up lp init, fix lp= option handling (Tim Waugh) o Don't panic on out of memory during ps/2 setup (Andrey Panin) o Initialise vc_cons objects in full (Richard Hirst) o Futher Configure.help resync(Eric Raymond) o Fix misdeclaration of xtime (Petr Vandrovec) o Add yet more sb variants(Andrey Panin) o Fix bogus VIA warning triggers (I hope) (me) o Fix 3c509 symbols when building nonpnp (Keith Owens) 2.4.5-ac13 o Fix i2o_block to use invalidate_device (me) o Fix viodasd to use invalidate_device(me) o Fix missing ipc alloc check (Manfred Spraul) o Use skb_purge_queue in isdn (Kai Germaschewski) o Fix epic100 printk error(Francois Romieu) o Resync with master Configure.help (Eric Raymond) o Avoid oops when reading swap proc during swapon (Paul Menage) o Sony pi driver update (Stelian Pop) o Sony motioneye camera driver(Stelian Pop, Andrew Tridgell) o Fix eepro100 access by user to some registers (Andrey Savochkin) o Small APM real mode reboot clean ups(Stephen Rothwell) o Fix isofs buffer leak on invalid iocharset (Tachino Nobuhiro) o Fix default encoding on pwc videocam(Mark Cooke) o Clean up FAT further, fix endian bug, and times (OGAWA Hirofumi) before 1/1/1980 o Support combo parallel/serial PCI cards (Tim Waugh) o CS46xx mmap oops fix(me) 2.4.5-ac12 o Report apic timer vector in hex too (Philip Pokorny) | With 0x in front so we can tell on reports.. o Report card services differently if kernel (Jeff Garzik) o Don't terminate init on sysrq (Adam Slattery) unless forced o Add more pci wrappers when PCI is off (Jeff Garzik) o Remove 4K object from the stack in emu10k1 (me) o Remove 3.5K object from the i2o_proc stack (me) o Remove 3K object from the ewrk3 ioctl stack (me) o Fix bugs in the es1371 locking (me) o Fix ohci iso alignments (Roman Weissgaerber) o Updated megaraid driver (Atul Mukker) | In paticular this now uses the new PCI api 2.4.5-ac11 o Fix the megaraid driver ioctl check (me) o Fix the moxa ioctl checks
Re: Client receives TCP packets but does not ACK
On Fri, 15 Jun 2001, Mike Black wrote: > This is a very common misconception -- I worked a contract many years ago > where I actually had to quote the author of TCP to convince a banking > company I was working with that TCP is not a guaranteed protocol. > Guaranteed delivery at layer 5 - yes -- but NOT a guaranteed protcol. > > Guaranteed means that there is absolutely NO way that data can be dropped by > an application if either sender or receiver screws up. > > The only way to do this is at layer 7 of the OSI model -- even then you end > up making assumptions. You are mixing oranges (protocols) and apples (implementations and APIs) here. The layer that is expected to provide reliable end to end communication is layer 4 (transport layer). TCP, at least in theory, is as good as OSI transport in providing reliable end to end communication. > Here's some examples for layer 5 (which TCP operates at) but talking at > Layer 7: > > #1 - You send() data -- meanwhile the receiver terminates the connection -- > what happened to the data? It's gone! Your app never receives feedback > that it didn't send() correctly. You'll see the reset on the next read but > you don't know what happened to the data. > #2 - You send() data and overrun your IP queue -- nobody will ever know the > difference without a layer 7 protocol (or int the case quoted in this > subject it might lock up). > #3 - You send() data and either machine has bad RAM and flips a bit -- guess > what? -- data corruption. > > Even when you do layer 7 (with checksums and ack/nak) you make assumptions: > > #1 - You checksum the packet you just received -- what's to say a bit can't > flip? > > TCP may be guaranteed at layer 5 but we don't typically program at layer > 5 -- we program at layer 7 and then lots of people assume they're doing it > at layer 5 -- ergo the problems. Layers above layer 4 provide additionnal services for applications but they assume that layer 4 is reliable. In other words, a broken transport layer breaks all layers above it and thus the applications. In fact, when you build your application above layer 4 and need services normally provided by upper OSI layers, you have to implement equivalent services in your application, using layered protocols or not. > To look at it another way -- "Just 'cuz I told my C library to send a packet > doesn't mean it's going to work". > For example, if you're using non-blocking sockets you have to check to > ensure there's room in your IP queue to transmit. That's API semantic issue, not protocol issue. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EEPRO100/S support
> Hey all, > I just had an eepro/100 S delivered to me. I haven't dug through specs > yet, but has anyone looke at this? Supposedly has a 3DES ASIC built in to > the core. > > Any way we can use it? Good question. I've been wondering how exactly that ASIC would even benefit Windows users. Should 3DES functions be moved to the kernel? Anything's possible. Then get with the libcrypt people to get the 3DES acceleration supported transparently in glibc. FWIW, I believe Intel's Linux drivers will support this card under 2.4, and I believe (not 100% certain on this) that they're GPL. I'll have to check on that. Kelledin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ps2 keyboard filter hook
On Fri, Jun 15, 2001 at 05:30:03PM -0400, Dan Streetman wrote: > > >X11 likes to talk direct to the PS/2 port. I actually think you should > >instead > >talk to Vojtech for the mainstream kernel about the input device work. It > >sounds much cleaner and more close to what you need > > Ah, I didn't realize the input layer was handling PS/2 stuff...? Although I am > not sure it would work; the special needs of these keyboards requires the driver > to do some bizarre things, such as: > > - change scancodes. I was and still am shocked by this. I will say that it is > a 'legacy feature' that I'm told is due having to deal with Windoze... > - consume scancodes. The keyboard uses normal scancodes for the extra hardware > as well as normal keys, so if the driver can't filter them out large amounts > of strange characters will appear when (e.g.) a credit card is swiped. > - send large amounts of bytes (multi-KB) to the PS/2 port (I think this > may be possible). > > The filtering needs to be done fairly early (I think), or the keyboard state may > get corrupted by seemingly random 'normal' scancodes coming in (for non-raw > modes)... > > Vojtech, could you comment on if the above is possible using the input layer? Yes, and quite easily it'll fit into the input layer. Basically the way to do it would be to open the PS/2 port in the filter driver (thus disabling the normal keyboard driver to open it) and then register a new PS/2 port which the normal keyboard driver would attach to. See the input CVS (http://www.suse.cz/development/input/quick.html) -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Âèçû.Ïàñïîðòà.Ãðàæäàíñòâà.Ïðîáëåìû.=?ISO-8859-1?Q?=D0=E5=F8=E5
On Fri, 15 Jun 2001, Dan Hollis wrote: > Received: from [195.161.132.168] ([195.161.132.168]:38150 "HELO 777") > by vger.kernel.org with SMTP id ; > Fri, 15 Jun 2001 17:19:32 -0400 > > inetnum: 195.161.132.0 - 195.161.132.255 > netname: RT-CLNT-MMTEL > descr:Moscow Long Distance and International Telephone > > Anyone want to fire the nuclear larts? Me! 1. It's a spam. 2. It's in the dreaded windows-1251 charset. 3. The text in the header is mis-identified as ISO 8859-1 -- Alex -- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.0.35 limits
On Fri, 15 Jun 2001, Paul Faure wrote: > Just this morning, our firewall get a kernel panic after 500 days of > uptime. > > As you can see from the log files, the date starts at June 15th, where we > get two div by zeros, then jumps May 11th, then a kernel panic. A reboot > brings it back to June 15th. Since cron could not open /dev/rtc. My first > thought was an internal kernel limit on the time, but 500 days seems a bit > short. > > Any ideas ? (1<<32) / (24 * 60 * 60 * 100) == 497 IOW, 2^32 timer interrupts since the boot. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ps2 keyboard filter hook
>X11 likes to talk direct to the PS/2 port. I actually think you should >instead >talk to Vojtech for the mainstream kernel about the input device work. It >sounds much cleaner and more close to what you need Ah, I didn't realize the input layer was handling PS/2 stuff...? Although I am not sure it would work; the special needs of these keyboards requires the driver to do some bizarre things, such as: - change scancodes. I was and still am shocked by this. I will say that it is a 'legacy feature' that I'm told is due having to deal with Windoze... - consume scancodes. The keyboard uses normal scancodes for the extra hardware as well as normal keys, so if the driver can't filter them out large amounts of strange characters will appear when (e.g.) a credit card is swiped. - send large amounts of bytes (multi-KB) to the PS/2 port (I think this may be possible). The filtering needs to be done fairly early (I think), or the keyboard state may get corrupted by seemingly random 'normal' scancodes coming in (for non-raw modes)... Vojtech, could you comment on if the above is possible using the input layer? -- Dan Streetman [EMAIL PROTECTED] -- 186,282 miles per second: It isn't just a good idea, it's the law! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Âèçû.Ïàñïîðòà.Ãðàæäàíñòâà.Ïðîáëåìû.=?ISO-8859-1?Q?=D0=E5=F8=E5=ED=
On Sat, 16 Jun 2001, =?ISO-8859-1?Q? =C1=E5=EB=EE=E1=EE=F0=EE=E4=EE=E2?= wrote: > "Íåò íåðàçðåøèìûõ ñèòóàöèé, åñòü òîëüêî íåæåëàíèå èõ > [... drivel deleted ...] Received: from [195.161.132.168] ([195.161.132.168]:38150 "HELO 777") by vger.kernel.org with SMTP id ; Fri, 15 Jun 2001 17:19:32 -0400 inetnum: 195.161.132.0 - 195.161.132.255 netname: RT-CLNT-MMTEL descr:Moscow Long Distance and International Telephone Anyone want to fire the nuclear larts? -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.0.35 limits
Just this morning, our firewall get a kernel panic after 500 days of uptime. As you can see from the log files, the date starts at June 15th, where we get two div by zeros, then jumps May 11th, then a kernel panic. A reboot brings it back to June 15th. Since cron could not open /dev/rtc. My first thought was an internal kernel limit on the time, but 500 days seems a bit short. Any ideas ? Last message via e-mail was: Date: Fri, 15 Jun 2001 08:01:05 -0400 To: [EMAIL PROTECTED] From: Cron Daemon <[EMAIL PROTECTED]> Subject: Cron run-parts /etc/cron.hourly Unable to open /dev/rtc, open() errno = Device or resource busy (16) The log file has: ... Jun 15 08:01:13 tap PAM_pwdb[3491]: (su) session opened for user nobody by (uid=99) Jun 15 08:01:16 tap kernel: divide error: Jun 15 08:01:16 tap kernel: CPU:0 Jun 15 08:01:16 tap kernel: EIP:0010:[do_fast_gettimeoffset+71/120] Jun 15 08:01:16 tap kernel: EFLAGS: 00013002 Jun 15 08:01:16 tap kernel: eax: 0ccabc7c ebx: 01ea65e1 ecx: 0017 edx: 00146440 Jun 15 08:01:16 tap kernel: esi: eb72aa0f edi: ebp: bbd4 esp: 00718f88 Jun 15 08:01:16 tap kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Jun 15 08:01:16 tap kernel: Process hwclock (pid: 3495, process nr: 63, stackpage=00718000) Jun 15 08:01:16 tap kernel: Stack: 00718fb0 3246 0001 001109d6 bb3c 00117e08 00718fb0 Jun 15 08:01:16 tap kernel:00a84414 bea8 3b29f90c 7530 0010a989 bb3c Jun 15 08:01:16 tap kernel:bea8 0001 bbd4 ffda 002b 002b 002b 002b Jun 15 08:01:16 tap kernel: Call Trace: [do_gettimeofday+34/68] [sys_gettimeofday+44/112] [system_call+85/124] Jun 15 08:01:16 tap kernel: Code: f7 f1 ba 10 27 00 00 89 c1 31 c0 f7 f1 a3 e4 03 1d 00 89 c3 Jun 15 08:01:16 tap kernel: divide error: Jun 15 08:01:16 tap kernel: CPU:0 Jun 15 08:01:16 tap kernel: EIP:0010:[do_fast_gettimeoffset+71/120] Jun 15 08:01:16 tap kernel: EFLAGS: 00010002 Jun 15 08:01:16 tap kernel: eax: 0cf383d2 ebx: 01ea65e1 ecx: 0019 edx: 00146440 Jun 15 08:01:16 tap kernel: esi: eb9b7165 edi: ebp: bbd4 esp: 00ba1f88 Jun 15 08:01:16 tap kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Jun 15 08:01:16 tap kernel: Process hwclock (pid: 3509, process nr: 26, stackpage=00ba1000) Jun 15 08:01:16 tap kernel: Stack: 00ba1fb0 0246 3b29f90b 001109d6 bb2c 00117e08 00ba1fb0 Jun 15 08:01:16 tap kernel:00842c0c 3b29f90c 3b29f90c c350 0010a989 bb2c 0001 Jun 15 08:01:16 tap kernel:3b29f90c 3b29f90b bbd4 ffda 002b 002b 002b 002b ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 7829 now 7829. May 11 07:52:29 tap kernel: eth2: No link beat on the MII interface, status then 7829 now 7829. May 11 07:53:29 tap kernel: eth2: No link beat on the MII interface, status then 7829 now 7829. May 11 07:54:29 tap kernel: eth2: No link beat on the MII interface, status then 7829 now 7829. Jun 15 10:33:39 tap kernel: klogd 1.3-3, log source = /proc/kmsg started. Jun 15 10:33:40 tap kernel: Loaded 4215 symbols from /boot/System.map. Jun 15 10:33:40 tap kernel: Symbols match kernel version 2.0.35. ... Thank You. -- Paul N. Faure 613.266.3286 Chief Technical Officer, CertainKey Inc.[EMAIL PROTECTED] Carleton University Systems Eng. 3rd Year [EMAIL PROTECTED] Engineering Society Administrator [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Âèçû.Ïàñïîðòà.Ãðàæäàíñòâà.Ïðîáëåìû.Ðåøåíèÿ.Ñîõðàíèòå - ïðèãîäèòñÿ.
"Íåò íåðàçðåøèìûõ ñèòóàöèé, åñòü òîëüêî íåæåëàíèå èõ ðàçðåøèòü." Óâàæàåìûå ãîñïîäà. Ïðåäëàãàåì ðåàëüíóþ ïîìîùü â ðåøåíèè âîïðîñîâ âûåçäà. Ïàñïîðòà. Âèçû. Ãðàæäàíñòâà. Ïðîáëåìû. Ðåøåíèÿ. Âêëþ÷àÿ ïîëó÷åíèå âèç ñòðàí Øåíãåíñêîãî ïðîñòðàíñòâà. Îôîðìëåíèå ïàñïîðòîâ(â òîì ÷èñëå è ÌÈÄ). Ïîëó÷åíèå âèç ÑØÀ, Êàíàäû, Ãåðìàíèè è åùå íåêîòîðûõ ñòðàí áåç ñîáåñåäîâàíèÿ. Ñàìûå ðåàëüíûå(î÷åíü íåäîðîãèå) öåíû. Ñðîêè îò 1 äíÿ. Ñêèäêè àãåíñòâàì\àãåíòàì\ïîñðåäíèêàì äî 50 %. Ðàáîòàåì ñ ïîñðåäíèêàìè. Ïðèíîñèì ñâîè èçâèíåíèÿ çà áåñïîêîéñòâî. Åñëè äëÿ Âàñ ýòî íåèíòåðåñíî, íî áîëåå áåñïîêîèòü Âàñ íå áóäåì. Âèçû. Ïàñïîðòà. Ãðàæäàíñòâà. Ïðîáëåìû. Ðåøåíèÿ. DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US DO NOT SPAM. IT HURTS ALL OF US - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac14
Hi! Why the 2.4.5-ac series doesn't have merges from Linus 2.4.6-pre anymore? Regards, -- Thiago Vinhas de Moraes NetWorx - A SuaCompanhia.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4.5-ac12] New Sony Vaio Motion Eye camera driver
In alcove.lists.linux.kernel, you wrote: > >Well, not quite... I've had several X lockups while using the YUV > >acceleration code. Let's say one lockup per half an hour. > > Strange. I've watched DVD's etc. Maybe it's not the Xv code, but your > camera code? It can be, of course. However I never experienced problems when using the 'regular' X server, but quite often when using the patched server from gatos. And since the driver delivers YUV data in both cases, I see no difference (from its point of vue) between the two uses. > >Even the performances are controversial: with 320x240, I achieve > >great performance with xawtv/meye driver, I can even use the hardware > >scaling facilities (well, the xawtv sources need a little hacking for > >that), but in 640x480 the framerate achieved with Xv is below the > >one I get by converting YUV->RGB in software... > > There's something wrong with your setup. I watch full-screen DVD's on my > VAIO. It's not really fast enough with just the YUV conversion done in > hardware (it's plenty fast enough if MC and iDCT would be done in HW > too, but ATI doesn't release docs without strict NDA's). But there's no > way DVD's are watchable with sw YUV conversion and scaling. I said that YUV conversion and scaling _do_ work in hardware. Actually, using a capture size of 320x240 I can use those hardware features and scale the image to full screen and I get all the 30 fps. It seems however to work pretty bad in 640x480... but maybe it is my setup here... > >But the main question remains: does the MotionEye camera support > >overlay or not ? > > That one I have no clue about at all. Neither do I :-) Stelian. -- Stelian Pop <[EMAIL PROTECTED]> | Free Software Engineer -| | Alcôve - http://www.alcove.com - Tel: +33 1 49 22 68 00 | |- Alcôve, liberating software ---| - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ps2 keyboard filter hook
>Didn't we just conclude a discussion here on linux-kernel, which said >that patches which simply add hooks allowing proprietary extensions are >not accepted into the kernel? Yes (I assume you mean the whole 'sockreg' register/unregister thread(s)...;-) I never intended to get that patch in. In fact I would be shocked (and a bit horrified) if it was accepted. But management doesn't listen to me when I say it will never get accepted so I had to make a token effort of submitting it to prove it won't get accepted. And I did try hard to convince them to release the actual driver but it didn't work. -- Dan Streetman [EMAIL PROTECTED] 186,282 miles per second: It isn't just a good idea, it's the law! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
EEPRO100/S support
Hey all, I just had an eepro/100 S delivered to me. I haven't dug through specs yet, but has anyone looke at this? Supposedly has a 3DES ASIC built in to the core. Any way we can use it? -- Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Zip: what does that mean?
Greg, Just to make a point on that, as I recall Zip and other super floppy media *shouldn't* be partitioned. It's certainly possible to do but it's anyone's guess on how different OS+revs will treat it. Josh __SIG__ On Fri, 15 Jun 2001, Gregoire Favre wrote: > On Fri, Jun 15, 2001 at 08:40:57AM +0200, Philipp Matthias Hahn wrote: > > > Nothing. Somethings is reeding /proc/partitions which lists all known > > partitions. "fdisk" or "mount" do this. > > > > When reading the file the kernel has to check the media in your zip-drive. > > Problem is, you havn't put in one. So there is no partition table to read > > and the kernel complains and returns the default values of a typical > > 100MB zip media. > > Thanks for your answer, in fact, there was a media in my zip, but > without any partition (as I don't see any other reason than avoiding > those errors messages to make just one partition on my disk). > > Thanks, > > Greg > > http://ulima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED] > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kmallow_maxsize undelcared
hello, the kmallow_maxsize is reported as undeclared what i try to complile buzz.c for the iomega buzz driver in the new kernel 2.4.5. how should i fix this? -- Lee Leahu RICIS, Inc. Internet Technoligies Specialist708-444-2690 Voice [EMAIL PROTECTED] 708-444-2697 Fax 708-467-2044 Pager 866-RICIS-77 Toll Free 708-363-6860 Cell Phone http://.ricis.com/ - "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ps2 keyboard filter hook
[EMAIL PROTECTED] wrote: > In order to use these keyboards, a the standard PS/2 driver needs to behave a > bit differently; thus attached is a modifcation to the PS/2 driver which allows > other drivers to register with the PS/2 driver as 'filters'. There is a > arbitrary max number of 'filters' set to 1, which is a compile-time define. > The registered drivers are called (in order of registration) for every scancode, > and they may change or consume the scancode (or allow it to pass). Also the > 'filters' are given a function to send an variable-sized buffer to the keyboard > output port; this function is synchronized using a semaphore which also > coordinates with pckbd_leds(). Didn't we just conclude a discussion here on linux-kernel, which said that patches which simply add hooks allowing proprietary extensions are not accepted into the kernel? -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nonblinking VGA block cursor
On Fri, Jun 15, 2001 at 03:21:54PM -0400, Albert D. Cahalan wrote: > Non-blinking cursors are just wrong. You need to patch your brain. > You really fucked up, because now apps can't restore your cursor > to proper behavior as defined by IBM. I don't want them to, because I prefer non-blinking. It feels more solid, kind of like driving a tank instead of a little dune buggy ;) > The blinking cursor is implemented in your video hardware. > IBM knew what was right for you. Uh, said hardware lets you disable the blinking. Maybe in a slightly non-standard way, who cares? > Of course FreeBSD has a block cursor. It was easy to program, > and it seems nice to the pot-smoking hippies out in Berkeley. > FreeBSD doesn't define standards. FreeBSD breaks standards. > (zombie creation, "ps -ef", partition tables, pty allocation...) It's all about choice, man. I want the choice to have certain behaviour if I wish. -- lj breedt coder - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 data corruption
On Fri, Jun 15, 2001 at 11:54:20PM +0400, Eugene Crosser wrote: > In article <[EMAIL PROTECTED]>, > Alan Cox <[EMAIL PROTECTED]> writes: > >> any problems since 2.4.5 was published, they seem to have surfaced > >> immediately after I created a rather big file capturing video with > >> broadcast2000 (video card is bt848). Filesystem is ext2. > > > > Thats something I've seen reported elsehwere. The high bandwidth capture card > > stuff seems to show up problems. It could be drivers could be hardware. On > > my AMD 751 pre release board I see that problem but on the 751 production board > > I dont > > You must be right, today I created another big file with the same program > but without doing caputre and the filesystem was intact. OTOH, > Russell Leighton reports curruption when creating a file with dd... For what it is worth, after having three failures in a row, now it isn't happening. My test case is/was my nightly backup. If it happens again, I'll save the corrupted data so we can do more digging. I'm kicking myself for not having done it the first time around. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Zip: what does that mean?
On Fri, Jun 15, 2001 at 08:40:57AM +0200, Philipp Matthias Hahn wrote: > Nothing. Somethings is reeding /proc/partitions which lists all known > partitions. "fdisk" or "mount" do this. > > When reading the file the kernel has to check the media in your zip-drive. > Problem is, you havn't put in one. So there is no partition table to read > and the kernel complains and returns the default values of a typical > 100MB zip media. Thanks for your answer, in fact, there was a media in my zip, but without any partition (as I don't see any other reason than avoiding those errors messages to make just one partition on my disk). Thanks, Greg http://ulima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED] PGP signature
Re: drivers/usb/ov511.c does not compile
> While I could > fix this myself manually (and plan to do so), it would be nice to get > the developer's blessing on this, and also nice to know exactly what > version number to give this driver in 2.4.5 stock. F**k me, forget I asked about the version. I just read a little further down in the source. I think I'll crawl up in a corner and just generally feel stupid now. ;) Kelledin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ps2 keyboard filter hook
IBM Retail Store Solutions dept has certain PS/2 keyboards which extend the standard PS/2 specification in order to support addition hardware built into the keyboard (such as a Magnetic Strip Reader, Keylock, Tone generator, extra keys, extra LEDs, etc). This addition hardware behaves in a manner that makes it unusable if driven by a standard PS/2 driver (sadly, due to the fact that its design is "IP" I can't elaborate on how or why it is incompatible with the standard PS/2 specification). In order to use these keyboards, a the standard PS/2 driver needs to behave a bit differently; thus attached is a modifcation to the PS/2 driver which allows other drivers to register with the PS/2 driver as 'filters'. There is a arbitrary max number of 'filters' set to 1, which is a compile-time define. The registered drivers are called (in order of registration) for every scancode, and they may change or consume the scancode (or allow it to pass). Also the 'filters' are given a function to send an variable-sized buffer to the keyboard output port; this function is synchronized using a semaphore which also coordinates with pckbd_leds(). -Dan diff -urN 2.4.5-clean/Documentation/Configure.help linux/Documentation/Configure.help --- 2.4.5-clean/Documentation/Configure.helpThu May 24 18:03:06 2001 +++ linux/Documentation/Configure.help Fri Jun 15 13:34:18 2001 @@ -13274,6 +13274,21 @@ If you are unsure, say N and read the HOWTO nevertheless: it will tell you what you have. +PS/2 Keyboard Filter support +CONFIG_PC_KEYB_FILTER + This enables filter support in the PS/2 keyboard driver. With + this enabled, other drivers will be able to register with the + PS/2 driver and filter all incoming scancodes. This is useful + for keyboards which extend the PS/2 keyboard standard with + non-standard scancodes which should not be normally routed to + the current console. + + This option does not actually filter any scancodes, it only + allows other drivers (who will do the filtering) to register + with the PS/2 driver. + + If unsure, say N. + QIC-02 tape support CONFIG_QIC02_TAPE If you have a non-SCSI tape drive like that, say Y. Or, if you want diff -urN 2.4.5-clean/drivers/char/Config.in linux/drivers/char/Config.in --- 2.4.5-clean/drivers/char/Config.in Tue Mar 6 22:44:34 2001 +++ linux/drivers/char/Config.inFri Jun 15 13:34:18 2001 @@ -105,6 +105,11 @@ source drivers/char/joystick/Config.in +mainmenu_option next_comment +comment 'Keyboards' +bool 'PS/2 Keyboard Filter support' CONFIG_PC_KEYB_FILTER +endmenu + tristate 'QIC-02 tape support' CONFIG_QIC02_TAPE if [ "$CONFIG_QIC02_TAPE" != "n" ]; then bool ' Do you want runtime configuration for QIC-02' CONFIG_QIC02_DYNCONF diff -urN 2.4.5-clean/drivers/char/Makefile linux/drivers/char/Makefile --- 2.4.5-clean/drivers/char/Makefile Wed May 16 13:27:02 2001 +++ linux/drivers/char/Makefile Fri Jun 15 13:34:18 2001 @@ -21,7 +21,7 @@ # All of the (potential) objects that export symbols. # This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'. -export-objs := busmouse.o console.o keyboard.o sysrq.o \ +export-objs := busmouse.o console.o keyboard.o pc_keyb.o sysrq.o \ misc.o pty.o random.o selection.o serial.o \ tty_io.o diff -urN 2.4.5-clean/drivers/char/pc_keyb.c linux/drivers/char/pc_keyb.c --- 2.4.5-clean/drivers/char/pc_keyb.c Fri Apr 6 13:42:55 2001 +++ linux/drivers/char/pc_keyb.cFri Jun 15 13:34:18 2001 @@ -13,6 +13,11 @@ * Code fixes to handle mouse ACKs properly. * C. Scott Ananian <[EMAIL PROTECTED]> 1999-01-29. * + * Added optional scancode filtering, used in keyboards which + * (incompatibly) extend the standard PS/2 specification. + * Also added synchronized output writing using a semaphore. + * Dan Streetman <[EMAIL PROTECTED]> 2001-03-14 + * */ #include @@ -32,6 +37,7 @@ #include #include #include +#include #include #include @@ -60,6 +66,7 @@ static void kbd_write_command_w(int data); static void kbd_write_output_w(int data); +static void kb_wait(void); #ifdef CONFIG_PSMOUSE static void aux_write_ack(int val); static void __aux_write_ack(int val); @@ -68,7 +75,7 @@ static spinlock_t kbd_controller_lock = SPIN_LOCK_UNLOCKED; static unsigned char handle_kbd_event(void); -/* used only by send_data - set by keyboard_interrupt */ +/* used by send_data and send_data_buffer - set by keyboard_interrupt */ static volatile unsigned char reply_expected; static volatile unsigned char acknowledge; static volatile unsigned char resend; @@ -94,6 +101,104 @@ #define MAX_RETRIES60 /* some aux operations take long time*/ #endif /* CONFIG_PSMOUSE */ +#ifdef CONFIG_PC_KEYB_FILTER +/* Use an array (instead of a linked list) to save time in_interrupt() */ +static struct pc_keyb_filter
Re: drivers/usb/ov511.c does not compile
On Fri, Jun 15, 2001, Kelledin Tane <[EMAIL PROTECTED]> wrote: > Apologies if this has been posted before. I imagine it has. > > In kernel 2.4.5 stock, ov511.c fails to compile. A little intelligent > searching through 2.4.4 source reveals that the following line in 2.4.4: > > static const char version[] = "1.28"; > > is missing in 2.4.5, and this is why it does not compile. While I could > fix this myself manually (and plan to do so), it would be nice to get > the developer's blessing on this, and also nice to know exactly what > version number to give this driver in 2.4.5 stock. This has already been fixed in the 2.4.5 pre patches. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
drivers/usb/ov511.c does not compile
Apologies if this has been posted before. I imagine it has. In kernel 2.4.5 stock, ov511.c fails to compile. A little intelligent searching through 2.4.4 source reveals that the following line in 2.4.4: static const char version[] = "1.28"; is missing in 2.4.5, and this is why it does not compile. While I could fix this myself manually (and plan to do so), it would be nice to get the developer's blessing on this, and also nice to know exactly what version number to give this driver in 2.4.5 stock. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nonblinking VGA block cursor
On 15 Jun 01 at 21:34, Daniel Phillips wrote: > On Friday 15 June 2001 21:21, Albert D. Cahalan wrote: > > Non-blinking cursors are just wrong. You need to patch your brain. > > You really fucked up, because now apps can't restore your cursor > > to proper behavior as defined by IBM. > > Just one question Albert: why doesn't my mouse cursor blink? ;-) Because of you can move mouse cursor - moving mouse usually does not have serious side effect. Normal cursor cannot be moved without sideeffects, so you cannot find it so easy. If you want, just plug matrox into your laptop and use matroxfb. It restarts cursor blinking cycle on each character printed to screen, so while you are typing, you still see cursor, but if you stop typing, cursor starts blinking... Just my 0.02Kc. Best regards, Petr Vandrovec [EMAIL PROTECTED] [matroxfb has also noblink option because HPA wanted it. But it is another story] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Yes! I still need ISA support for an ne2000 card. On Wednesday, June 13, 2001, at 06:23 PM, Rafael Diniz wrote: >> No. There are still plenty of unique ISA cards around. > How about all the isa ne2000 around the world? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nonblinking VGA block cursor
Daniel Phillips writes: > On Friday 15 June 2001 21:21, Albert D. Cahalan wrote: >> Non-blinking cursors are just wrong. You need to patch your brain. >> You really fucked up, because now apps can't restore your cursor >> to proper behavior as defined by IBM. > > Just one question Albert: why doesn't my mouse cursor blink? ;-) 1. confusion with the text cursor, which should blink 2. need for continuous pixel-to-pixel accuracy with the mouse 3. you can wiggle your mouse as needed to find the mouse cursor Apps do funny things when you try to wiggle the text cursor with the arrow keys, and movement tends to be harshly constrained. So the blinking is important. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nonblinking VGA block cursor
On Friday 15 June 2001 21:21, Albert D. Cahalan wrote: > Non-blinking cursors are just wrong. You need to patch your brain. > You really fucked up, because now apps can't restore your cursor > to proper behavior as defined by IBM. Just one question Albert: why doesn't my mouse cursor blink? ;-) -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nonblinking VGA block cursor
Leon Breedt writes: > Attached is a patch to enforce a non-blinking, FreeBSD-syscons like > block cursor in console mode. > > This is useful for laptop types, or people like me who really really > detest a blinking cursor. > > NOTE: It disables the softcursor escape codes > (/usr/src/linux/Documentation/VGA-softcursor.txt), since I don't > ever want anything to change my cursor shape/style :) I've seen this 666 times too often. Non-blinking cursors are just wrong. You need to patch your brain. You really fucked up, because now apps can't restore your cursor to proper behavior as defined by IBM. The blinking cursor is implemented in your video hardware. IBM knew what was right for you. Millions of people know that the blinking cursor is good. It is so right that a proper GUI will implement the blinking cursor even without hardware support. Of course FreeBSD has a block cursor. It was easy to program, and it seems nice to the pot-smoking hippies out in Berkeley. FreeBSD doesn't define standards. FreeBSD breaks standards. (zombie creation, "ps -ef", partition tables, pty allocation...) Gee, kind of like Microsoft, except Microsoft got the cursor right! Ever wonder why IBM supports Linux instead of FreeBSD? Hmmm? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
> TCP is guaranteed delivery at layer 5 -- but that's all -- not a "guaranteed > protocol" For certain specific cases this is in itself not true either. Also for many many implementations. Specifically 1. If the receiver closes and there is unread data many TCP's forget to RST the sender to indicate that data was lost. 2. There is a flaw in the TCP protocol itself that is extremely unlikely to bite people but can in theory cause wrong data in some unusual circumstances that Ian Heavans found and has yet to be fixed by the keepers of the protocol. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Buffer management - interesting idea
On Fri, 15 Jun 2001, Ivan Schreter wrote: > In 2Q, when a page is present in LRU queue, you move it to the front of > LRU queue as usual. Otherwise, if it is in memory, it must be in A1 queue > (the FIFO one), so you DON'T do anything. When the page is NOT in memory, > you load it conditionally to Am LRU queue (if it is present in A1out > queue) or to A1 queue (FIFO), if not. > > It gets interesting when you need to swap out a page from memory. When the > size of A1 FIFO is greater than limit (e.g., 10% of buffer space), a page > from A1 is swapped out (and put into A1out list), otherwise a page from Am > LRU is swapped out (and NOT put into A1out, since it hasn't been accessed > for long time). This description has me horribly confused. Do you have any pointers to state diagrams of this thing? ;) regards, Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] APM, ACPI, and Wake on LAN - the bane of my existance
Thanks, I'll try to take a look at the source if I get a chance next week. Any tulip developers out there know off hand if this is enabled? Or can be disabled? Thanks, Alex David Christensen wrote: > > Alex, > > Looking at the back of a Linksys EtherFast 10/100 manual I happen to have, > they describe two different remote wake-up events, Magic Packet and Link > Change. The first one is pretty obvious and is probably not related to > your problems, but the second one may be. The manual states ""Link Change > is a remote wake up event that is triggered by any change in the EtherFast > card's link state." Plugging in a LAN cable is the example given that > would turn the system on. You may have to look at the driver source to see > if this is enabled by default or you may have to modify the driver to > disable this "feature" on the card. > > Regarding the WOL cable, this was used for older motherboards before PCI > 2.2, > though it is still present on newer motherboards to support older PCI cards. > A PCI 2.2 compliant motherboard and NIC use the #PME signal on the PCI bus > to signal the wake. > > Dave > > > > > I have an athlon system with a iwill kk266 motherboard (via > > kt133A). I > > have a linksys 10/100 PCI ethernet card with wake on lan > > capabilities. > > Anyway, when I shut the PC down it turns off, but refuses to > > stay off. > > Within a minute or two, it turns itself on again. If i run over and > > turn it off by hitting the power putton, it turns off, but then comes > > back on again at a later somewaht arbitrary time (1 minute to several > > hours later). I originally got the WOL card so I could > > remotely boot my > > PC, but at this point it has turned out to be more trouble than it's > > worth. I tried to disable WOL inthe BIOS, but that didn't change > > anything. So I removed the three pin cross connect that connects the > > card to the WOL header on the motherboard. That fixed it for a few > > days, but now it's doing it again, even without the cable installed. > > the only fix is to unplug the ethernet cable when I turn it off. > > > > I suspect the problem has something to do with WOL vs. resume on LAN. > > the system should only turn on when it recieves a magic packet, but it > > seems that any packet may cause it to boot (or resume, but since it is > > in the "off" state, boot). I've only been using APM, but perhaps acpi > > is required for this to work properly. As far as why it does > > this when > > the 3 pin WOL connector was not used, I'm not sure, maybe something to > > do with PCI 2.2. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lockup in 2.4.2 kernel ADSL PCI card ATM driver module
I apologize to all for my first post! To partly answer my own poorly documented problem:- First, once the code added for the debugger (int3) was removed from the driver, the driver worked fine with kernel version 2.4.2-ac28 (but still not with 2.4.2-2rh or 2.4.2). Second, with sincere apologies to all (some suffer from brain lapses more than others), I neglected to mention that the system hangs, in both 2.4.2-2rh and 2.4.2 kernels, when the driver performs: ... save_flags(flags); cli(); ... TimeRemain = interruptible_sleep_on_timeout(>WaitQue, WaitTime); restore_flags(flags); ... Again note that there were not any code changes to the driver, with the results that the driver worked for 2.4.0 and 2.4.2-ac28 but did not work for 2.4.2-2rh or 2.4.2. Does anyone know if there was a bug introduced between 2.4.0 and 2.4.2 in the interruptible sleep area that was fixed by 2.4.2-ac28? If not, then there might still be a timing related problem in our driver (or possibly the kernel). Thanks again, Dan Davidson [EMAIL PROTECTED] Conexant Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
Mike Black writes: > I'm concerned that you're probably just overruning your IP stack: ... > TCP is NOT a guaranteed protocol -- you can't just blast data from one port > to another and expect it to work. Yes you can. This is why we have TCP in fact. > a tcp-write is NOT guaranteed -- and as you've seen -- a recv() isn't either > (that's why you need timeouts). > You're probably overrunning the tcp buffer on your "print" statement and > truncating a block. > I don't see where you're checking forEAGAIN or EWOULDBLOCK (see man > send). You do have to check for partial writes due to the UNIX API. Then check for EAGAIN and EINTR at least. > You need a layer-7 protocol that will guarantee your transactions -- once > you're client acks/naks your server I'll bet everything works hunky-dory. > If you're not familiar with the OSI model > http://www.csihq.com/~mike/students/networking/iso/isomodel.html You don't need that crap. TCP/IP doesn't even fit the OSI model, and we're missing much of the OSI stack AFAIK. (Do we have that thing with 10-byte addresses? I think not.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Using cramfs as root filesystem on diskless machine
Mathias Killian wrote a patch to allow cramfs initrd's, see: http://www.cs.helsinki.fi/linux/linux-kernel/2001-01/1064.html Alexandr Andreev wrote: > > Hi, list. > > My MIPS machine has no any disks or flopies. So i obliged to use a RAM > disk with a file system on it, which is mounted as root. > I use gzipped initrd image, which is linked to the special section in the > kernel during compilation. Now, the RAM disk size is really big, so i > decide > to use cramfs instead of ext2. In scripts/cramfs/ I found an utility that > creates cramfs file system image. But i read in rd.c, that RAM disk driver > doesn't support the cramfs. > > After i create an image, how can i mount it as root file system? Where i > must put it? Which kernel command line options i must use? > > Please answer, or point me to any documentation or mailing list. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- David L. Parsley Network Administrator, Roanoke College "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
This is a very common misconception -- I worked a contract many years ago where I actually had to quote the author of TCP to convince a banking company I was working with that TCP is not a guaranteed protocol. Guaranteed delivery at layer 5 - yes -- but NOT a guaranteed protcol. Guaranteed means that there is absolutely NO way that data can be dropped by an application if either sender or receiver screws up. The only way to do this is at layer 7 of the OSI model -- even then you end up making assumptions. Here's some examples for layer 5 (which TCP operates at) but talking at Layer 7: #1 - You send() data -- meanwhile the receiver terminates the connection -- what happened to the data? It's gone! Your app never receives feedback that it didn't send() correctly. You'll see the reset on the next read but you don't know what happened to the data. #2 - You send() data and overrun your IP queue -- nobody will ever know the difference without a layer 7 protocol (or int the case quoted in this subject it might lock up). #3 - You send() data and either machine has bad RAM and flips a bit -- guess what? -- data corruption. Even when you do layer 7 (with checksums and ack/nak) you make assumptions: #1 - You checksum the packet you just received -- what's to say a bit can't flip? TCP may be guaranteed at layer 5 but we don't typically program at layer 5 -- we program at layer 7 and then lots of people assume they're doing it at layer 5 -- ergo the problems. To look at it another way -- "Just 'cuz I told my C library to send a packet doesn't mean it's going to work". For example, if you're using non-blocking sockets you have to check to ensure there's room in your IP queue to transmit. TCP is guaranteed delivery at layer 5 -- but that's all -- not a "guaranteed protocol" Michael D. Black Principal Engineer [EMAIL PROTECTED] 321-676-2923,x203 http://www.csihq.com Computer Science Innovations http://www.csihq.com/~mike My home page FAX 321-676-2355 - Original Message - From: "Heusden, Folkert van" <[EMAIL PROTECTED]> To: "Mike Black" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, June 15, 2001 8:53 AM Subject: RE: Client receives TCP packets but does not ACK > TCP is NOT a guaranteed protocol -- you can't just blast data from one port > to another and expect it to work. Isn't it? Are you really sure about that? I thought UDP was the not-guaranteed-one and TCP was the one guaranting that all data reaches the other end in order and all. Please enlighten me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Zip: what does that mean?
On Thu, 14 Jun 2001, Gregoire Favre wrote: > I have an IDE 250Mb Zip, it work fine, but I can see: > > Jun 11 23:52:35 greg kernel: ide-floppy: hdc: I/O error, pc = 5a, key = > 5, asc = 24, ascq = 0 > Jun 11 23:52:37 greg kernel: hdc: unknown partition table > Jun 11 23:52:37 greg kernel: hdc: 98304kB, 96/64/32 CHS, 4096 kBps, 512 > sector size, 2941 rpm > > Could someone explain me what's wrong? Nothing. Somethings is reeding /proc/partitions which lists all known partitions. "fdisk" or "mount" do this. When reading the file the kernel has to check the media in your zip-drive. Problem is, you havn't put in one. So there is no partition table to read and the kernel complains and returns the default values of a typical 100MB zip media. BYtE Philipp -- / / (_)__ __ __ Philipp Hahn / /__/ / _ \/ // /\ \/ / //_/_//_/\_,_/ /_/\_\ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.19 -> 80% Packet Loss
On Fri, 15 Jun 2001 [EMAIL PROTECTED] wrote: > > > You can fix this by upping the socket buffer that ping asks for (look > > for setsockopt( ... SO_RCVBUF ...)) and then tuning the kernel to > > allow larger socket buffers. The file to fiddle with is > > /proc/sys/net/core/rmem_max. > > Currently it is set to 65535. I doubled it several times and each time saw > no change when I sent it a ping flood with packet size 64590 or higher. > What sort of magnitude were you thinking? Did you change both /proc/sys/net/core/rmem_max *and* ping's setsockopt? Do an strace on ping and see what's happening. Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Using cramfs as root filesystem on diskless machine
David Woodhouse wrote: >It's not polite to respond to private messages in public fora. > >On Fri, 15 Jun 2001, Alexandr Andreev wrote: > >>Bootloader only jumps to the kernel entry point. The initrd image is >>compiled inside the kernel. >> > >So it's in a ROM or flash chip? Why copy it into memory then? We have >support for ROM and flash chips. > No any flash, disk, floppy... only RAM, image is inside kernel. #ls -s vmlinux 4852 vmlinux #objdump --headers vmlinux .data .text .bss .initrd <- Here is the image. ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc
Hey thanks, The memory i need is not for DMA usage so i don't care if it is contiguous or not. later, Petko Arnaldo Carvalho de Melo wrote: > > Em Fri, Jun 15, 2001 at 10:02:08AM -0700, Petko Manolov escreveu: > > Hi there, > > > > AFAIK there was similar discusion almos a year > > ago but i can't remember the details. > > > > kmalloc fails to allocate more than 128KB of > > memory regardless of the flags (GFP_KERNEL/USER/ATOMIC) > > > > Any ideas? > > > > I am not quite sure if this is the expected behavior. > > yes, expected behaviour, at most you can allocate 32 contiguous pages with > kmalloc, if you need more and it is not for DMA, use vmalloc, that will not > try to use contiguous pages > > - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Using cramfs as root filesystem on diskless machine
Hi, David. David Woodhouse wrote: >Where does the bootloader get the initrd from? > Bootloader only jumps to the kernel entry point. The initrd image is compiled inside the kernel. ( special section in the ELF kernel binary ) .config: ... CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_BLK_DEV_INITRD=y ... If 'root=/dev/ram' option is set in command line, the root file system will bi in RAM. When the linux kernel is booting, it tries to identify_ramdisk_image() ( at drivers/block/rd.c ). So it can only understand ext2, minix, romfs, and gzipped images. But what about cramfs? How can i use a cramfs image to mount it as my root file system? Is any patches to the rd.c requiried? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc
Em Fri, Jun 15, 2001 at 10:02:08AM -0700, Petko Manolov escreveu: > Hi there, > > AFAIK there was similar discusion almos a year > ago but i can't remember the details. > > kmalloc fails to allocate more than 128KB of > memory regardless of the flags (GFP_KERNEL/USER/ATOMIC) > > Any ideas? > > I am not quite sure if this is the expected behavior. yes, expected behaviour, at most you can allocate 32 contiguous pages with kmalloc, if you need more and it is not for DMA, use vmalloc, that will not try to use contiguous pages - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Next hop and o/p i/f IP address
Hi list Sorry to bother you with such a trivial query. To make a routing decision ip_route_input() is called. It fills the skb->dst with appropriate entry. Can anyone point to the exact location where I can find the next hop and output interface IP address. It seems skb->dst->dev->ip_ptr->in_dev->ifa_list->ifa_address is o/p i/f ip address and skb->dst->neighbour->dev->ip_ptr->in_dev->ifa_list->ifa_address is next hop IP address Please correct me if I am wrong. Thanks for all the help. Manoj __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Buffer management - interesting idea
Hello, I'm not subscribed to list, so please replies CC: to me On Fri, 15 Jun 2001 12:20:52 -0400 (EDT) John Clemens <[EMAIL PROTECTED]> wrote: > Is there any way for you to measure the relative computational overhead > required for the two algorithms? the benefit of the higher hit rate may > be lost of the computational time increases by too much. Well, *computational* overhead is negligible - processing is O(1), like LRU. Look at the program that was attached to my previous message. There is an implementation of this algorithm. In LRU, all you have to do is move page to the front of doubly-linked list when page is accessed and swap out last page when buffer is full and request for a new page is generated. In 2Q, when a page is present in LRU queue, you move it to the front of LRU queue as usual. Otherwise, if it is in memory, it must be in A1 queue (the FIFO one), so you DON'T do anything. When the page is NOT in memory, you load it conditionally to Am LRU queue (if it is present in A1out queue) or to A1 queue (FIFO), if not. It gets interesting when you need to swap out a page from memory. When the size of A1 FIFO is greater than limit (e.g., 10% of buffer space), a page from A1 is swapped out (and put into A1out list), otherwise a page from Am LRU is swapped out (and NOT put into A1out, since it hasn't been accessed for long time). So the general algorithm is not much more complicated as LRU. There is only one interesting question: How to implement A1out queue (also FIFO) so that we can quickly tell a page is in A1out. I'm currently using cyclic buffer for A1out in sample implementation and a flag in buffer map if a page is in A1out. In real system this flag must be replaced by some kind of hashtable which will contain an entry for all pages which are in A1out queue, so that we can decide in O(1) if a page is or isn't in A1out when loading it from the disk. Alternative is a bitmask, but then we need, e.g., for 64GB at 4kB sized pages, 2MB of RAM (which is too much). Considering we may have upto 32K pages mapped in memory (128MB buffer), is a hashtable with say 64K entries at 50% A1out (16K entries) much more memory efficient (512kB). If we limit A1out queue to something less (maybe 10-20% of buffer block count) we need even less space. Since I use it for database application and know in advance the size of the underlying dataspace, I use bitmask method in my program. This is probably not good for the kernel. Somebody should investigate the potential impact of the algorithm on real system. If you send me a trace from live system, I am willing to analyze it. Form for the trace: A text file with lines in format: time blockid buffersizecur buffersizemax time blockid touch where time is monotonically increasing, blockid is some unique ID of block requested (also for blocks already in memory!), buffersizecur is current size of buffer space (since we have variable buffer space under linux) and buffersizemax is buffersizecur + size of free memory (or a flag whether we can put a new block in a free memory block). Second form (with word "touch") is for the purposes of counting extra time needed for swapping out the block back to the disk. Optionally the time may be left out. -- Ivan Schreter [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc
Petko Manolov writes: > kmalloc fails to allocate more than 128KB of > memory regardless of the flags (GFP_KERNEL/USER/ATOMIC) > > Any ideas? Yes, this is the limit. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kmalloc
Hi there, AFAIK there was similar discusion almos a year ago but i can't remember the details. kmalloc fails to allocate more than 128KB of memory regardless of the flags (GFP_KERNEL/USER/ATOMIC) Any ideas? I am not quite sure if this is the expected behavior. Petko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kgdb for 2.4.5 kernels
Hi, Linux kernel source level debugger, kgdb is available for kernel version 2.4.5. It contains the same functionality as kgdb for 2.4.3. Please visit http://kgdb.sourceforge.net/ to download it. Regards. -- Amit S. Kale <[EMAIL PROTECTED]> Linux kernel source level debuggerhttp://kgdb.sourceforge.net/ Translation filesystemhttp://trfs.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH] even out background aging
On Fri, 15 Jun 2001, Rik van Riel wrote:
> [Request For Testers: please test this on your system...]
>
> Hi,
>
> the following patch makes use of the fact that refill_inactive()
> now calls swap_out() before calling refill_inactive_scan() and
> the fact that the inactive_dirty list is now reclaimed in a fair
> LRU order.
>
> Background scanning can now be replaced by a simple call to
> refill_inactive(), instead of the refill_inactive_scan(), which
> gave mapped pages an unfair advantage over unmapped ones.
Hi Rik,
While I was testing this suggestion (still actually) prior to your
RFT, the first thing I did was the straight substitution, but under
heavy load, the additional swap/aging when there is a ~persistant
shortage hurt ~fairly badly. What I did instead, and shows no ill
effects under any load I've tried so far was...
/* If needed, try to free some memory. */
if (inactive_shortage() || free_shortage())
do_try_to_free_pages(GFP_KSWAPD, 0);
else {
/* Do background page aging. */
swap_out(DEF_PRIORITY, GFP_KSWAPD);
refill_inactive_scan(DEF_PRIORITY, 0);
}
I still had the benefit of idle pages being pushed to disk quickly
and staying there :) IMHO, this is the first real candidate for a
sysctl tunable, as it's possibly not good for everyone. As indicated
privately, I like the effect of this suggestion a lot, but laptop
people may not because of the infrequent and miniscule swapin (which
_might_ be an irritant _if_ they are doing enough work etc etc).
-Mike
(this report would have landed in your mailbox tomorrow.. I was too
slow. sending it to lkml lest someone sees the same high load thing
I did and determine it's a loss unfairly)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Final call for testers][PATCH] superblock handling changes (2.4.6-pre3)
On Fri, Jun 15, 2001 at 01:10:00AM -0400, Alexander Viro wrote:
> +static inline void write_super(struct super_block *sb)
> +{
> + lock_super(sb);
> + if (sb->s_root && sb->s_dirt)
When I first looked at this, I thought it was a typo. I don't think we
should have s_dirty and s_dirt as fields of the superblock. how about
s_dirty_inodes and s_isdirty, respectively?
> +restart:
> + spin_lock(_lock);
> + sb = sb_entry(super_blocks.next);
> + while (sb != sb_entry(_blocks))
> + if (sb->s_dirt) {
> + sb->s_count++;
> + spin_unlock(_lock);
> + down_read(>s_umount);
> + write_super(sb);
> + drop_super(sb);
> + goto restart;
> + } else
> + sb = sb_entry(sb->s_list.next);
> + spin_unlock(_lock);
I think this could be clearer.
struct list_head *tmp;
restart:
spin_lock(_lock);
list_for_each(tmp, super_blocks) {
struct super_block *sb = sb_entry(tmp);
if (!sb->s_dirt)
continue;
spin_unlock(_lock);
down_read(>s_umount);
write_super(sb);
drop_super(sb);
goto restart;
}
spin_unlock(_lock);
> @@ -773,16 +810,16 @@
> void *data, int silent)
> {
> struct super_block * s;
> - s = get_empty_super();
> + s = alloc_super();
> if (!s)
> goto out;
> s->s_dev = dev;
> s->s_bdev = bdev;
> s->s_flags = flags;
> - s->s_dirt = 0;
> s->s_type = type;
> - s->s_dquot.flags = 0;
> - s->s_maxbytes = MAX_NON_LFS;
> + spin_lock(_lock);
> + list_add (>s_list, super_blocks.prev);
I'd use list_add_tail(>s_list, super_blocks);
> - if (mnt->mnt_instances.next != mnt->mnt_instances.prev) {
> + if (atomic_read(>s_active) > 1) {
I'm happy to see that line disappear. It was mightily confusing.
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3C905B -- EEPROM (i blive so) problem
On Wed, 13 Jun 2001, L. K. wrote: > I have a 3COM 3C905B ethernet card that has been hit by a power outage for > aprox. 0.5 sec. What do you mean by "power outage" ? If you mean cutting the power, this is not a serious reason for EEPROM damages, unless you were modifying it at that moment. > I do belive something happened to the eeprom of the card. I would like > to know if I can overwrite-it with a new one so that I can make my > ethernet card work again. Maybe 3Com's DOS-based tool (3c90xcfg.exe) can help. In order to re-write the EEPROM, you need to use vortex-diag; I think that you need to hack it a bit as the EEPROM writting code is not enabled. But most important is that you need a good EEPROM image to write; if you have another similar card, you can use vortex-diag to dump the EEPROM, then change the MAC address (if you put both cards on the same network segment). If you don't have a similar card... you have to download the card's documentation from 3Com and build your own EEPROM image based on what you know about your card's capabilities - having an EEPROM image from a different card might screw things up badly. If you decide to go the last way, maybe I can help with some interpretation of the docs - please e-mail me in private. Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
On Fri, Jun 15, 2001 at 08:37:15AM -0700, David S. Miller wrote: > > Pete Wyckoff writes: > > We're currently working on using both processors > > of the Tigon in parallel. > > It is my understanding that on the Tigon2, the second processor is > only for working around hw bugs in the DMA controller of the board and > cannot be used for other tasks. > > WRT. tigon3, it was mentioned on this list that it is a pair of arm9 > cpus, one for rx and one for tx. > Might be worth asking broadcom instead of 3com for the specs, as they seem to be selling it as a chip (BCM5700/5701), whereas 3com sells a board (3c996). -- Pekka Pietikainen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Enabling Netfilters to Mark packets in Red-Hat
I have been trying to enable Netfilters to mark ip packets, (i.e. using iptables and iproute2). My problem is that after upgrading from 2.2.4 kernel to a 2.4 version, I did the following: make menuconfig - enabling the appropriate options make dep make bzImage make bzlilo The problem is I cannot get iptables or ipoute2 working. I can see header files for iptables, but nothing eslse, and I cannot find any reference to iproute2 whatsoever. Can anyone mail me as to what I may be doing wrong? I am a relative newcomer to linux. Cheers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFT][PATCH] even out background aging
[Request For Testers: please test this on your system...]
Hi,
the following patch makes use of the fact that refill_inactive()
now calls swap_out() before calling refill_inactive_scan() and
the fact that the inactive_dirty list is now reclaimed in a fair
LRU order.
Background scanning can now be replaced by a simple call to
refill_inactive(), instead of the refill_inactive_scan(), which
gave mapped pages an unfair advantage over unmapped ones.
The special-casing of the amount to scan in refill_inactive_scan()
is removed as well, there's absolutely no reason we'd need it with
the current VM balance.
regards,
Rik
--
--- linux-2.4.6-pre3/mm/vmscan.c.orig Thu Jun 14 12:28:03 2001
+++ linux-2.4.6-pre3/mm/vmscan.cFri Jun 15 11:55:09 2001
@@ -695,13 +695,6 @@
int page_active = 0;
int nr_deactivated = 0;
- /*
-* When we are background aging, we try to increase the page aging
-* information in the system.
-*/
- if (!target)
- maxscan = nr_active_pages >> 4;
-
/* Take the lock while messing with the list... */
spin_lock(_lru_lock);
while (maxscan-- > 0 && (page_lru = active_list.prev) != _list) {
@@ -978,7 +971,7 @@
recalculate_vm_stats();
/* Do background page aging. */
- refill_inactive_scan(DEF_PRIORITY, 0);
+ refill_inactive(GFP_KSWAPD, 0);
}
run_task_queue(_disk);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
[EMAIL PROTECTED] said: > [EMAIL PROTECTED] writes: > > So are there any intresting changes one can make to the acenic? > > Like I said, there is an entire firmware developer kit, so the only > limit is your imagination and coding skills :-) I wrote a new firmware from scratch to offload most of a message passing implementation (MPI, actually) into the Alteon NIC, including timeout and retransmit, message matching, header building, etc. It's almost ready for release. We're currently working on using both processors of the Tigon in parallel. There is other work which has modified the Alteon firmware to do, for example, segmentation and reassembly (Underwood et al.), and further work in progress on other topics. Programmable NICs are fun. I'd like to get one of those Tigon3 cards to see if any of the register layout on the Tigon2 is still there, hoping the interface is similar at least. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Avoid !__GFP_IO allocations to eat from memoryreservations
On Thursday, June 14, 2001 09:59:43 AM -0300 Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > > In pre3, GFP_BUFFER allocations can eat from the "emergency" memory > reservations in case try_to_free_pages() fails for those allocations in > __alloc_pages(). > > > Here goes the (tested) patch to fix that: I started testing this because I expected problems under load with reiserfs on it. No deadlocks yet though...I owe Marcelo a beer ;-) -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Using cramfs as root filesystem on diskless machine
Hi, list. My MIPS machine has no any disks or flopies. So i obliged to use a RAM disk with a file system on it, which is mounted as root. I use gzipped initrd image, which is linked to the special section in the kernel during compilation. Now, the RAM disk size is really big, so i decide to use cramfs instead of ext2. In scripts/cramfs/ I found an utility that creates cramfs file system image. But i read in rd.c, that RAM disk driver doesn't support the cramfs. After i create an image, how can i mount it as root file system? Where i must put it? Which kernel command line options i must use? Please answer, or point me to any documentation or mailing list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
> I've installed several thousand 3com cards of various ages and > types. I've had less than 20 bad cards. > Nick Seconded. 3Com stuff is overpriced but reliable. They have also (prior to this event) been very good at working with the Linux community, including digging out docs for old MCA hardware they no longer even sell Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] nonblinking VGA block cursor
Hi,
Attached is a patch to enforce a non-blinking, FreeBSD-syscons like
block cursor in console mode.
This is useful for laptop types, or people like me who really really
detest a blinking cursor.
NOTE: It disables the softcursor escape codes
(/usr/src/linux/Documentation/VGA-softcursor.txt), since I don't
ever want anything to change my cursor shape/style :)
It applies cleanly against 2.4.5, to use, select:
'VGA block cursor (non-blinking) support' in the 'Console drivers'
section of menuconfig.
Have fun,
Leon.
--
lj breedt
coder
diff -uNr linux-2.4.5/arch/i386/config.in linux-2.4.5.nonblink/arch/i386/config.in
--- linux-2.4.5/arch/i386/config.in Fri May 25 00:14:08 2001
+++ linux-2.4.5.nonblink/arch/i386/config.inFri Jun 15 16:03:32 2001
@@ -356,6 +356,9 @@
mainmenu_option next_comment
comment 'Console drivers'
bool 'VGA text console' CONFIG_VGA_CONSOLE
+ if [ "$CONFIG_VGA_CONSOLE" = "y" ]; then
+ bool 'VGA block cursor (non-blinking) support' CONFIG_NON_BLINK_CURSOR
+ fi
bool 'Video mode selection support' CONFIG_VIDEO_SELECT
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
tristate 'MDA text console (dual-headed) (EXPERIMENTAL)' CONFIG_MDA_CONSOLE
diff -uNr linux-2.4.5/drivers/char/console.c
linux-2.4.5.nonblink/drivers/char/console.c
--- linux-2.4.5/drivers/char/console.c Fri Feb 9 21:30:22 2001
+++ linux-2.4.5.nonblink/drivers/char/console.c Fri Jun 15 15:47:58 2001
@@ -124,6 +124,11 @@
#define DEFAULT_BELL_PITCH 750
#define DEFAULT_BELL_DURATION (HZ/8)
+/*
+ * cursor_type value for non-blinking white block cursor
+ */
+#define CUR_NONBLINK 16748305
+
extern void vcs_make_devfs (unsigned int index, int unregister);
#ifndef MIN
@@ -1403,7 +1408,12 @@
kbd_table[currcons].ledflagstate = kbd_table[currcons].default_ledflagstate;
set_leds();
+#ifdef CONFIG_NON_BLINK_CURSOR
+ cursor_type = CUR_NONBLINK;
+#else
cursor_type = CUR_DEFAULT;
+#endif
+
complement_mask = s_complement_mask;
default_attr(currcons);
@@ -1595,6 +1605,7 @@
set_mode(currcons,0);
return;
case 'c':
+#ifndef CONFIG_NON_BLINK_CURSOR
if (ques) {
if (par[0])
cursor_type = par[0] | (par[1]<<8) |
(par[2]<<16);
@@ -1602,6 +1613,7 @@
cursor_type = CUR_DEFAULT;
return;
}
+#endif
break;
case 'm':
if (ques) {
@@ -2445,6 +2457,9 @@
save_screen(currcons);
gotoxy(currcons,x,y);
csi_J(currcons, 0);
+#ifdef CONFIG_NON_BLINK_CURSOR
+ cursor_type = CUR_NONBLINK;
+#endif
update_screen(fg_console);
printk("Console: %s %s %dx%d",
can_do_color ? "colour" : "mono",
Re: obsolete code must die
Claudio Martins <[EMAIL PROTECTED]> said: [...] > Anyone with a <486 probably shudders at the space and time requirements > of compiling modern kernels.. ... which they do on their newer machine anyway, as the i386 in the closet is a router that sports no compiler. > The older boxes don't support the new hardware anyways.. ... so support for old hardware has to stay (unless it hurts somewhere, which is rather uncommon) [...] > But in this age of 'disposability' more and more people just accept they > have to buy new hardware every 3-5 years.. For those that want to > maintain Linux on that, so be it.. There are places in the world where a i486sx is viewed with awe... and i386 are commonplace. Don't fall into the trap of "All Linux PCs are in the US". Besides, if the piece of junk does its job well, why buy an expensive, completely overqualified new machine for it? Sure would make PC makers happy, but I'm not _that_ interested in their happiness to tell the truth. > Maybe we need more Alan Cox's, and then we could have sperate kernel > trees, Linus's which is the mother.. (HI MOM!) and the pre-pentium > tree, the post-pentium tree, the embedded tree etc.. ... and a nightmare where nobody knows the state of in and has to cross-port all kind of stuff to get to work. > But in reality, with all the people contributing now to one tree, there > is still more work to be done.. Who wants to split those resources? Bingo! -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.19 -> 80% Packet Loss
> You can fix this by upping the socket buffer that ping asks for (look > for setsockopt( ... SO_RCVBUF ...)) and then tuning the kernel to > allow larger socket buffers. The file to fiddle with is > /proc/sys/net/core/rmem_max. Currently it is set to 65535. I doubled it several times and each time saw no change when I sent it a ping flood with packet size 64590 or higher. What sort of magnitude were you thinking? > That doesn't really answer why you'd want to fling that many 64k-ish > ping packets around, though. No reason specifically other than intuition. Just kinda stumbled on to this one. -Chuck -- Chuck Wolber System Administrator AltaServ Corporation (425)576-1202 ten.vresatla@wkcuhc Quidquid latine dictum sit, altum viditur. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: SMP spin-locks
On Fri, 15 Jun 2001, David Schwartz wrote: > > > Spinlocks are machine dependent. A simple increment of a byte > > memory variable, spinning if it's not 1 will do fine. Decrementing > > this variable will release the lock. A `lock` prefix is not necessary > > > because all Intel byte operations are atomic anyway. This assumes > > > that the lock was initialized to 0. It doesn't have to be. It > > could be initialized to 0xaa (anything) and spin if it's not > > 0xab (or anything + 1). > > If this is true, atomicity isn't enough to do it. Atomicity means that > there's a single instruction (and so it can't be interrupted mid-modify). > Atomicity (at least as the term is normally used) doesn't prevent the > cache-coherency logic from ping-ponging the memory location between two > processor's caches during the atomic operation. > > DS Try it. You'll like it. There are no simultaneous accesses from different CPUs to any address space of any kind on an Intel-based SMP machine. That is a fact. This is because there is only one group of decodes for this address space. This applies for both memory and I/O. Basically, the bus even though it may be broken into several units of different speeds, operates as a unit. So, only one operation can be occurring at any instant. Now, suppose you have a DSP that accesses it's own memory. It's on a different board than the main CPU. You provide a mechanism whereby your CPU can share a portion (or all) of this memory. For this, you "dual-port" the memory, or you access it via a PCI bus. Anyway, the DSP's memory now appears in your address space. When you access this memory at a time that the DSP could be writing to it, you need a `lock` prefix. Also hardware needs to handle the #LOCK signal properly or you may get some funny values from the DSP. As shown in the '486 manual, if you perform a read/modify/write operation you may need a lock prefix. Unlike CPUs that can only perform load and store operations upon memory, the ix86 can perform many operations directly. Amongst many of these wonderful instructions is the ability to increment or decrement a byte anywhere in memory. The CPU does not perform a read/modify/write operation in the general sense when it does this. Instead, the data is read, modified, and written in a single bus cycle. There is no way that another CPU can access the bus in between these operations. Memory access instructions that are complete in a single bus cycle (this is not a single CPU clock), would never need a lock prefix. The lock-prefix executes in only a single CPU clock. The idea is not to get rid of this. The idea is to get rid of the awful spin_lock_irqsave()/ spin_lock_irqrestore() code that has grown like some virus and replace it with simple working code that does not use a seperate segment for the spinning, etc. Also, the cache of all CPUs "knows" when a write within its cache-line has occurred so the next CPU will correctly see the result of the previous operation. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Client receives TCP packets but does not ACK
> TCP is NOT a guaranteed protocol -- you can't just blast data from one port > to another and expect it to work. Isn't it? Are you really sure about that? I thought UDP was the not-guaranteed-one and TCP was the one guaranting that all data reaches the other end in order and all. Please enlighten me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMP spin-locks
On Fri, 15 Jun 2001, Ingo Oeser wrote: > On Thu, Jun 14, 2001 at 05:05:07PM -0400, Richard B. Johnson wrote: > > The problem is that a data acquisition board across the PCI bus > > gives a data transfer rate of 10 to 11 megabytes per second > > with a UP kernel, and the transfer drops to 5-6 megabytes per > > second with a SMP kernel. The ISR is really simple and copies > > data, that's all. > > > > The 'read()' routine uses a spinlock when it modifies pointers. > > > > I started to look into where all the CPU clocks were going. The > > SMP spinlock code is where it's going. There is often contention > > for the lock because interrupts normally occur at 50 to 60 kHz. > > Then you need another (better?) queueing mechanism. > > Use multiple queues and a _overflowable_ sequence number as > global variable between the queues. > > N Queues (N := no. of CPUs + 1), which have a spin_lock for each > queue. > > optionally: One reader packet reassembly priority queue (APQ) ordered by >sequence number (implicitly or explicitly), if this shouldn't >be done in user space. > > In the writer ISR: > >Foreach Queue in RR order (start with remebered one): >- Try to lock it with spin_trylock (totally inline!) > + Failed > * if we failed to find a free queue for x "rounds", disable > device (we have no reader) and notify user space somehow >* increment "rounds" >* next queue > + Succeed >* Increment sequence number >* Put data record into queue > (* remember this queue as last queue used) > (* mark queue "not empty") >* do other IRQ work... > > In the reader routine: >Foreach Queue in RR order (start with remebered one): >- No data counter above threshold -> EAGAIN [1] >- Try to lock it with spin_trylock (totally inline!) > + Failed -> next queue > + Succeed >* if queue empty, unlock and try next one > (* remember this queue as last queue used) >* Get one data record from queue (in queue order!) >* Move data record into APQ >* Unlock queue >* Deliver as much data from the APQ, as the user wants and > is available > - if all queues empty or locked -> increment "no data round" > counter > > > Notes: >The "last queue used" variable is static, but local to routine. >It is there to decrease the number of iterations and distribute >the data to all queues as more equally. > > >Statistics about lock contention per queue, per round and per >try would be nice here to estimate the number of queues >needed. > >The APQ can be quite large, if the sequences are bad >distributed and some queues tend to be always locked, if the >reader wants to read from this queue. > >The above can be solved by 2^N "One entry queues" (aka slots) >and sequence numbers mapping to this slots. If you need many >slots (more then 256, I would say) then this is again >inaccaptable, because of the iteration cost in the ISR. > > What do you think? After some polishing this should decrease lock > contention noticibly. > > > Regards > > Ingo Oeser > > [1] Blocking will be harder to implement here, since we need to >notify the reader routine, that we have data available, which >involves some latency you cannot afford. Maybe this could be >done via schedule_task(), if needed. > -- > Use ReiserFS to get a faster fsck and Ext2 to fsck slowly and gently. > For further discussion I will take this off-list. However, you are correct. The very simple ISR that I have (I did preallocate buffers) leaves a great deal of room for improvement. However, the logic that you mention has execution overhead as well. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
Here's the end of my run -- I assume this means my config works OK?
I'm on a dual PIII/600 linux-2.4.6-pre3 -- ran it all on the local host.
received msg#90, name pad1, 1 blocks, 12 total bytes
received msg#91, name pad1, 1 blocks, 12 total bytes
received msg#92, name class tande.server.ClientMap, 1624 blocks, 3244 total
bytes
received msg#93, name pad1, 1 blocks, 12 total bytes
received msg#94, name pad1, 1 blocks, 12 total bytes
received msg#95, name pad1, 1 blocks, 12 total bytes
received msg#96, name class tande.server.ClientMap, 1624 blocks, 3244 total
bytes
successfully read all blocks
I'm concerned that you're probably just overruning your IP stack:
foreach $block (@blocks) {
print $client $block;
$bytes += length($block);
}
TCP is NOT a guaranteed protocol -- you can't just blast data from one port
to another and expect it to work.
a tcp-write is NOT guaranteed -- and as you've seen -- a recv() isn't either
(that's why you need timeouts).
You're probably overrunning the tcp buffer on your "print" statement and
truncating a block.
I don't see where you're checking forEAGAIN or EWOULDBLOCK (see man
send).
Not real sure how to do this in perl...
You need a layer-7 protocol that will guarantee your transactions -- once
you're client acks/naks your server I'll bet everything works hunky-dory.
If you're not familiar with the OSI model
http://www.csihq.com/~mike/students/networking/iso/isomodel.html
Michael D. Black Principal Engineer
[EMAIL PROTECTED] 321-676-2923,x203
http://www.csihq.com Computer Science Innovations
http://www.csihq.com/~mike My home page
FAX 321-676-2355
- Original Message -
From: "Robert Kleemann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2001 11:50 PM
Subject: Re: Client receives TCP packets but does not ACK
A couple people have requested a test case.
The problem first showed up in a very large java app. Since then I
wrote a small perl program to duplicate the behavior of the large app
by sending the same data, in the same order, in the same sized blocks,
from the server to the client.
If you want to test this on your configuration then download the
following two files:
http://www.kleemann.org/crap/clientserver
http://www.kleemann.org/crap/log1e1.txt
Place a copy of the files in the same directory on both the client and
the server and run the program the following way:
[server]$ ./clientserver -s log1e1.txt
listening on port 20001
[client]$ ./clientserver -c serverhostname log1e1.txt
The server will attempt to send the data to the client which then
verifies each byte received.
My client generally stops ack-ing between messages 15 and 25.
Robert.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SMP spin-locks
On Thu, Jun 14, 2001 at 05:05:07PM -0400, Richard B. Johnson wrote: > The problem is that a data acquisition board across the PCI bus > gives a data transfer rate of 10 to 11 megabytes per second > with a UP kernel, and the transfer drops to 5-6 megabytes per > second with a SMP kernel. The ISR is really simple and copies > data, that's all. > > The 'read()' routine uses a spinlock when it modifies pointers. > > I started to look into where all the CPU clocks were going. The > SMP spinlock code is where it's going. There is often contention > for the lock because interrupts normally occur at 50 to 60 kHz. Then you need another (better?) queueing mechanism. Use multiple queues and a _overflowable_ sequence number as global variable between the queues. N Queues (N := no. of CPUs + 1), which have a spin_lock for each queue. optionally: One reader packet reassembly priority queue (APQ) ordered by sequence number (implicitly or explicitly), if this shouldn't be done in user space. In the writer ISR: Foreach Queue in RR order (start with remebered one): - Try to lock it with spin_trylock (totally inline!) + Failed * if we failed to find a free queue for x "rounds", disable device (we have no reader) and notify user space somehow * increment "rounds" * next queue + Succeed * Increment sequence number * Put data record into queue (* remember this queue as last queue used) (* mark queue "not empty") * do other IRQ work... In the reader routine: Foreach Queue in RR order (start with remebered one): - No data counter above threshold -> EAGAIN [1] - Try to lock it with spin_trylock (totally inline!) + Failed -> next queue + Succeed * if queue empty, unlock and try next one (* remember this queue as last queue used) * Get one data record from queue (in queue order!) * Move data record into APQ * Unlock queue * Deliver as much data from the APQ, as the user wants and is available - if all queues empty or locked -> increment "no data round" counter Notes: The "last queue used" variable is static, but local to routine. It is there to decrease the number of iterations and distribute the data to all queues as more equally. Statistics about lock contention per queue, per round and per try would be nice here to estimate the number of queues needed. The APQ can be quite large, if the sequences are bad distributed and some queues tend to be always locked, if the reader wants to read from this queue. The above can be solved by 2^N "One entry queues" (aka slots) and sequence numbers mapping to this slots. If you need many slots (more then 256, I would say) then this is again inaccaptable, because of the iteration cost in the ISR. What do you think? After some polishing this should decrease lock contention noticibly. Regards Ingo Oeser [1] Blocking will be harder to implement here, since we need to notify the reader routine, that we have data available, which involves some latency you cannot afford. Maybe this could be done via schedule_task(), if needed. -- Use ReiserFS to get a faster fsck and Ext2 to fsck slowly and gently. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 data corruption
Nuther anecdote: I was creating a big swapfile on ext2 (because 2.4.5 needs too much swap) with dd (SCSI disk on Sym53c8-something controller) and corrupted the partition THEN fsck would cause the kernel to panic. I thought I had some bad hw ... the box sits on my office floor waiting resurrection. Eugene Crosser wrote: > In article <[EMAIL PROTECTED]>, > Alan Cox <[EMAIL PROTECTED]> writes: > >> Folks, I believe I have a reproducible test case which corrupts data in > >> 2.4.5. > > > > 2.4.5 has an out of date 3ware driver that is short > > These days I observed massive FS curruption on vanilla 2.4.5, > SCSI disk on Sym53c8-something controller (UW). I did not notice > any problems since 2.4.5 was published, they seem to have surfaced > immediately after I created a rather big file capturing video with > broadcast2000 (video card is bt848). Filesystem is ext2. > > Eugene > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- --- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Alan Cox wrote: > > Would it make sense to create some sort of 'make config' script that > > determines what you want in your kernel and then downloads only those > > components? After all, with the constant release of new hardware, isn't a > > 50MB kernel release not too far away? 100MB? > > This should be a FAQ entry. It is. 7.7 . Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: threading question
Since while using only a small subset of primitives provided by the pthreads the burden for the other primitive maintanence is much more so i too feel when we use only a small part its better to implement in our own requiredd way for performance issues. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of bert hubert Sent: Friday, June 15, 2001 12:32 AM To: Alan Cox Cc: Kip Macy; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: threading question On Thu, Jun 14, 2001 at 07:28:32PM +0100, Alan Cox wrote: > There are really only two reasons for threaded programming. > > - Poor programmer skills/language expression of event handling The converse is that pthreads are: - Very easy to use from C at a reasonable runtime overhead It is very convenient for a userspace coder to be able to just start a function in a different thread. Now it might be so that a kernel is not there to provide ease of use for userspace coders but it is a factor. I see lots of people only using: pthread_create()/pthread_join() mutex_lock/unlock sem_post/sem_wait no signals My gut feeling is that you could implement this subset in a way that is both fast and right - although it would not be 'pthreads compliant'. Can anybody confirm this feeling? Regards, bert -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac14: clock timer problem NOT resolved.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry to disappoint you. Still the VIA "clock timer configuration lost" error message on ASUS board, ca every 1 - 5 minutes. Either the messages are still bogus or the asus board is buggy too. best regards, Andreas - - Andreas K. Huettel [EMAIL PROTECTED] 81627 Muenchen [EMAIL PROTECTED] Germany http://www.akhuettel.de/ - - Please use GNUPG or PGP for signed and encrypted email. My public key can be found at http://www.akhuettel.de/pgp_key.html - - -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7KeuOL+gLs3iH94cRAucUAJwOifa0utbVMMCQ2LNV3st9TczcbgCeIqVZ 4MFY3mbYxCFiicvG86tBL10= =imZh -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: SMP spin-locks
> Spinlocks are machine dependent. A simple increment of a byte > memory variable, spinning if it's not 1 will do fine. Decrementing > this variable will release the lock. A `lock` prefix is not necessary > because all Intel byte operations are atomic anyway. This assumes > that the lock was initialized to 0. It doesn't have to be. It > could be initialized to 0xaa (anything) and spin if it's not > 0xab (or anything + 1). If this is true, atomicity isn't enough to do it. Atomicity means that there's a single instruction (and so it can't be interrupted mid-modify). Atomicity (at least as the term is normally used) doesn't prevent the cache-coherency logic from ping-ponging the memory location between two processor's caches during the atomic operation. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reg file system hash function
On Fri, Jun 15, 2001 at 03:52:52PM +0530, SATHISH.J wrote: > In the vfs layer when we see the lookup_dentry() function code we see that > a part of the code checks whether low level filesystem wants to use its > own hash. the part odf the code that calls the filesystem dependant > hashing is "error = base->d_op->d_hash->(base,);". Why should it > callfilesystem dependant hashing. What is the main purpose of hashing > here. > Please help me with these details. It is used in two cases. If a filesystem has: 1. case-insensitive filenames (its much better to have the names 'FOO' and 'foo' refer to the same dentry, since they refer to the same file) 2. a limited filename length and your filesystem truncates names (on a non-vfat filesystem 'dosfilen.ame' and 'dosfilename.ame' would be the same file and the same dentry structure). -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG at slab.c:1244! 2.4.5-ac13
I tend to get these after a few days uptime. This one locked X hard, ping and ssh over net etc still worked ok. Pretty standard x86 PC hardware. kernel BUG at slab.c:1244! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00213082 eax: 001b ebx: cfffc768 ecx: c0217700 edx: 0002906e esi: c8a5b000 edi: c8a5b9aa ebp: 00012800 esp: ca2e7df8 ds: 0018 es: 0018 ss: 0018 Process X (pid: 11139, stackpage=ca2e7000) Stack: c01e5225 04dc ceac71b4 c0273fa0 0007 0002 c8a5b000 1000 0020 00203246 c01a4e86 0a1c 0007 c58a97a0 09e0 c01a4671 09e0 0007 ce146ad4 09e0 c01d34e0 c58a94b4 ca2e6000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 8b 6b 10 f7 c5 00 04 00 00 74 53 b8 a5 c2 0f ksymoops 0.7c on i686 2.4.5-ac13. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac13/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00213082 eax: 001b ebx: cfffc768 ecx: c0217700 edx: 0002906e esi: c8a5b000 edi: c8a5b9aa ebp: 00012800 esp: ca2e7df8 ds: 0018 es: 0018 ss: 0018 Process X (pid: 11139, stackpage=ca2e7000) Stack: c01e5225 04dc ceac71b4 c0273fa0 0007 0002 c8a5b000 1000 0020 00203246 c01a4e86 0a1c 0007 c58a97a0 09e0 c01a4671 09e0 0007 ce146ad4 09e0 c01d34e0 c58a94b4 ca2e6000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 8b 6b 10 f7 c5 00 04 00 00 74 53 b8 a5 c2 0f >>EIP; c012842f<= Trace; c01a4e86 Trace; c01a4671 Trace; c01d34e0 Trace; c01d35df Trace; c01d34e0 Trace; c01a233d Trace; c01d34e0 Trace; c01a265c Trace; c01a26de Trace; c0130c93 Trace; c0117e65 Trace; c0130df9 Trace; c0106b17 Trace; c010002b Code; c012842f <_EIP>: Code; c012842f<= 0: 0f 0b ud2a <= Code; c0128431 2: 83 c4 08 add$0x8,%esp Code; c0128434 5: 8b 6b 10 mov0x10(%ebx),%ebp Code; c0128437 8: f7 c5 00 04 00 00 test $0x400,%ebp Code; c012843d e: 74 53 je 63 <_EIP+0x63> c0128492 Code; c012843f 10: b8 a5 c2 0f 00mov$0xfc2a5,%eax 1 warning issued. Results may not be reliable.-- -- LarsG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Reg file system hash function
Hi, In the vfs layer when we see the lookup_dentry() function code we see that a part of the code checks whether low level filesystem wants to use its own hash. the part odf the code that calls the filesystem dependant hashing is "error = base->d_op->d_hash->(base,);". Why should it callfilesystem dependant hashing. What is the main purpose of hashing here. Please help me with these details. Thanks in advance, Regards, sathish.j - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac14
Hi Dieter,
On Fri, 15 Jun 2001, Dieter Nützel wrote:
> I see 4.29 GB under shm with your latest try.
> something wrong?
Yes, this is nasty. The appended patch fixes that. (I am not really
happy to need the PG_marker flag for writepage.)
The patch also fixes two other problems:
- shmem_file_setup has to check the given size. Else we can corrupt
kernel memory on 64bit machines. (Thanks to Oliver Paukstadt for
detecting this)
- shmem_remount_fs does not initialize the parameters and thus
corrupts the sizes (detected by Joris van Rantwijk)
Alan, please apply.
Greetings
Christoph
diff -uNr 5-ac14/include/linux/mm.h 5-ac14-fix/include/linux/mm.h
--- 5-ac14/include/linux/mm.h Fri Jun 15 10:37:21 2001
+++ 5-ac14-fix/include/linux/mm.h Fri Jun 15 11:24:06 2001
@@ -357,6 +357,7 @@
#define PageMarker(page) test_bit(PG_marker, &(page)->flags)
#define SetPageMarker(page)set_bit(PG_marker, &(page)->flags)
+#define ClearPageMarker(page) clear_bit(PG_marker, &(page)->flags)
#ifdef CONFIG_HIGHMEM
#define PageHighMem(page) test_bit(PG_highmem, &(page)->flags)
diff -uNr 5-ac14/mm/shmem.c 5-ac14-fix/mm/shmem.c
--- 5-ac14/mm/shmem.c Fri Jun 15 10:09:21 2001
+++ 5-ac14-fix/mm/shmem.c Fri Jun 15 11:37:44 2001
@@ -34,6 +34,7 @@
#define TMPFS_MAGIC0x01021994
#define ENTRIES_PER_PAGE (PAGE_SIZE/sizeof(unsigned long))
+#define SHMEM_MAX_BLOCKS (SHMEM_NR_DIRECT + ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
#define SHMEM_SB(sb) (>u.shmem_sb)
@@ -56,10 +57,12 @@
struct inode *inode = (struct inode *)page->mapping->host;
struct shmem_sb_info * sbinfo = SHMEM_SB(inode->i_sb);
- inode->i_blocks -= BLOCKS_PER_PAGE;
- spin_lock (>stat_lock);
- sbinfo->free_blocks++;
- spin_unlock (>stat_lock);
+ if (!PageMarker(page)) {
+ inode->i_blocks -= BLOCKS_PER_PAGE;
+ spin_lock (>stat_lock);
+ sbinfo->free_blocks++;
+ spin_unlock (>stat_lock);
+ }
atomic_dec(_nrpages);
}
@@ -241,9 +244,10 @@
*entry = swap;
error = 0;
/* Remove the page from the page cache */
- atomic_dec(_nrpages);
lru_cache_del(page);
+ SetPageMarker(page);
remove_inode_page(page);
+ ClearPageMarker(page);
/* Add it to the swap cache */
add_to_swap_cache(page, swap);
@@ -1062,6 +1066,8 @@
unsigned long max_inodes, inodes;
struct shmem_sb_info *sbinfo = SHMEM_SB(sb);
+ max_blocks = sbinfo->max_blocks;
+ max_inodes = sbinfo->max_inodes;
if (shmem_parse_options (data, NULL, _blocks, _inodes))
return -EINVAL;
@@ -1110,7 +1116,7 @@
sbinfo->free_blocks = blocks;
sbinfo->max_inodes = inodes;
sbinfo->free_inodes = inodes;
- sb->s_maxbytes = (unsigned long long)(SHMEM_NR_DIRECT +
(ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)) << PAGE_CACHE_SHIFT;
+ sb->s_maxbytes = (unsigned long long) SHMEM_MAX_BLOCKS << PAGE_CACHE_SHIFT;
sb->s_blocksize = PAGE_CACHE_SIZE;
sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
sb->s_magic = TMPFS_MAGIC;
@@ -1311,9 +1317,11 @@
struct qstr this;
int vm_enough_memory(long pages);
- error = -ENOMEM;
+ if (size > (unsigned long long) SHMEM_MAX_BLOCKS << PAGE_CACHE_SHIFT)
+ return ERR_PTR(-EINVAL);
+
if (!vm_enough_memory((size) >> PAGE_SHIFT))
- goto out;
+ return ERR_PTR(-ENOMEM);
this.name = name;
this.len = strlen(name);
@@ -1321,7 +1329,7 @@
root = tmpfs_fs_type.kern_mnt->mnt_root;
dentry = d_alloc(root, );
if (!dentry)
- goto out;
+ return ERR_PTR(-ENOMEM);
error = -ENFILE;
file = get_empty_filp();
@@ -1347,7 +1355,6 @@
put_filp(file);
put_dentry:
dput (dentry);
-out:
return ERR_PTR(error);
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
