Re: freeze with 2.4.5-ac16
On Wed, 20 Jun 2001, Justin Guyett wrote: the offending process is memeat (allocates 192*1024*1024 bytes, then memsets it to 0, then sleeps forever, though apparently it never gets to that part). It has to be in memset(ptr, 0, 192*1024*1024). ksymoops from sysrq-m attached, hmm, well here's the seperated-by-process ksymoops, decoded on the right machine even! justin freesibling task PCstack pid father child younger older init R current 0 1 0 1312 (NOTLB) Call Trace: [c01279a1] [c0127b06] [c012863a] [c01286dc] [c012588b] [c0125a1f] [c0136ca9] [c0137bbd] [c0134d4e] [c0106aeb] keventd S 0 2 1 3 (L-TLB) Call Trace: [c011d2eb] [c010545c] kswapdR C1451FA8 0 3 1 4 2 (L-TLB) Call Trace: [c0110cbb] [c0110c00] [c011122a] [c0127aa1] [c010545c] kreclaimd S 0286 0 4 1 5 3 (L-TLB) Call Trace: [c0d5] [c0127b52] [c010545c] bdflush S 0282 0 5 1 6 4 (L-TLB) Call Trace: [c0d5] [c0131144] [c010545c] kupdated S C1479FC8 0 6 1 8 5 (L-TLB) Call Trace: [c0110cbb] [c0110c00] [c01311b9] [c010545c] kreiserfsdS CFAB9FB4 0 8 112 6 (L-TLB) Call Trace: [c0110cbb] [c0110c00] [c011122a] [c016b6f7] [c010545c] devfsdS CF706000 812 122 8 (NOTLB) Call Trace: [c015126c] [c015d890] [c015e145] [c0164cf7] [c016551f] [c0194725] [c0165a22] [c0190948] [c01909a2] [c0157395] [c015758d] [c0164b20] [c0157a79] [c0164cf7] [c016551f] [c013457c] [c012e040] [c0158b16] [c0158f12] [c0164cf7] [c016551f] [d081a044] [c016c87a] [c016cc09] [c016c256] [c0159073] [c0136e95] [c0134e14] [c012d7b6] [c0106aeb] klogd S 7FFF 022 12712 (NOTLB) Call Trace: [c0110c5f] [c01da0af] [c01da967] [c01a8345] [c01a856e] [c012d87b] [c0106aeb] syslogd R 027 13022 (NOTLB) Call Trace: [c012858c] [c01286dc] [c013ae57] [c01acdf0] [c01a874f] [c013b036] [c013b490] [c0106aeb] kapm-idledS CF23FF94 030 15327 (L-TLB) Call Trace: [c0110cbb] [c0110c00] [d090a9d7] [d090bcdc] [d090c08c] [d090c08c] [d090b2e5] [c0105453] [c010545c] cardmgr S 7FFF 481253 17230 (NOTLB) Call Trace: [c0110c5f] [c019ff9c] [c013b0f1] [c013b490] [c0106aeb] sshd S 7FFF 072 17453 (NOTLB) Call Trace: [c0110c5f] [c013b0f1] [c013b490] [c0106aeb] xfs S CE65FF2C 074 17872 (NOTLB) Call Trace: [c0110cbb] [c0110c00] [c013b0f1] [c013b490] [c0106aeb] zsh S CF94FFB0 078 1 1338 7974 (NOTLB) Call Trace: [c0105cc7] [fffafefe] [c0106aeb] agettyS 7FFF 117279 18178 (NOTLB) Call Trace: [c0110c5f] [c017754d] [c0173738] [c012d7b6] [c0106aeb] zsh S 7FFF 081 1 12279 (NOTLB) Call Trace: [c0110c5f] [c017754d] [c0173738] [c012d7b6] [c0106aeb] zsh S CF1BDFB0 0 122 1 138 14881 (NOTLB) Call Trace: [c0105cc7] [fffafefe] [c0106aeb] zsh S C30FFFB0 4708 138122 150 (NOTLB) Call Trace: [c0105cc7] [fffafefe] [c0106aeb] gpm S C32D3F2C 4640 148 1 151 122 (NOTLB) Call Trace: [c0110cbb] [c0110c00] [c013b0f1] [c013b490] [c0106aeb] [c010002b] ssh S 7FFF 0 150138 (NOTLB) Call Trace: [c0110c5f] [c013b0f1] [c013b490] [c0106aeb] agettyS 7FFF 0 151 1 1312 148 (NOTLB) Call Trace: [c0110c5f] [c017754d] [c0173738] [c012d7b6] [c0106aeb] zsh S C9BCDFB024 1312 1 1431 151 (NOTLB) Call Trace: [c0105cc7] [fffafefe] [c0106aeb] zsh S C1AB2000 0 1319 78 14321338 (NOTLB) Call Trace: [c013614c] [c0136223] [c012d7b6] [c0106aeb] tail S CE86FF8C24 1338 781319 (NOTLB) Call Trace: [c0110cbb] [c0110c00] [c0119a48] [c0106aeb] memeatR 376 1431 1312 (NOTLB) Call Trace: [c012858c] [c011f0be] [c011f14b] [c011f25b] [c0110374] [c01104d4] [c0110374] [c01aae1b] [c01194f9] [c01193d7] [c01195c4] [c010a9f8] [c0110f3c] [c0110374] [c0106c18] zsh R 4600 1432 1319 (NOTLB) Call Trace: [c012858c] [c011eba2] [c011f291] [c0110374] [c01104d4] [c0110374] [c0128c75] [c012d47c] [c0106c18] Proc; init EIP; 000c Before first symbol = Trace; c01279a1 do_try_to_free_pages+19/58 Trace; c0127b06 try_to_free_pages+22/2c Trace; c012863a __alloc_pages+1b2/240 Trace; c01286dc __get_free_pages+14/20 Trace; c012588b
Re: Linux 2.4.5-ac15
On Thu, 21 Jun 2001, Marcelo Tosatti wrote: 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 198 1 ^ Ok, I suspect that GFP_BUFFER allocations are fucking up here (they can't block on IO, so they loop insanely). Why doesn't the VM hang the syncing of queued IO on these guys via wait_event or such instead of trying to just let the allocation fail? (which seems to me will only cause the allocation to be resubmitted, effectively changing nothing but adding overhead) Does failing the allocation in fact accomplish more than what I'm (uhoh:) assuming? -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/
Cannot complie aic7xxx_mod.o
Hi, I get the source code of aic7xxx untar it in my Linux Kernel directory and go to the directory /usr/src/linux/drivers/scsi/aic7xxx to make aic7xxx_mod.o. But i cannot make the modules. The error is as follows: My Linux is RedHat 6.2 and kernel version is 2.2.14-5.0 . Please give me some instructions to achieve it. Best Regards Warren - 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-ac15
On Thu, 21 Jun 2001, Mike Galbraith wrote: On Thu, 21 Jun 2001, Marcelo Tosatti wrote: 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 198 1 ^ Ok, I suspect that GFP_BUFFER allocations are fucking up here (they can't block on IO, so they loop insanely). Why doesn't the VM hang the syncing of queued IO on these guys via wait_event or such instead of trying to just let the allocation fail? Actually the VM should limit the amount of data being queued for _all_ kind of allocations. The problem is the lack of a mechanism which allows us to account the approximated amount of queued IO by the VM. (except for swap pages) You can see it this way: To get free memory we're polling instead of waiting on the IO completion of pages. (which seems to me will only cause the allocation to be resubmitted, effectively changing nothing but adding overhead) Yes. Does failing the allocation in fact accomplish more than what I'm (uhoh:) assuming? No. It sucks really badly. - 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: aic7xxx oops with 2.4.5-ac13
On Thu, 21 Jun 2001 03:05:02, Jeff V. Merkey [EMAIL PROTECTED] wrote: Ditto. I am also seeing this oops calling the sg driver for a robotic tape library, and it also seems to happen on 2.4.4. In my case it appears that it was the symptom of severe bus problems. About 5 minutes after I posted the initial report I discovered that the cable from the back of the Nikon to the MO drive had fallen off so the bus was running unterminated. Replugging it fixed teh bus error and the oops. Looks like error handling is all fscked up... -- Trevor Hemsley, Brighton, UK. [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: temperature standard - global config option?
[EMAIL PROTECTED] (Chris Boot) wrote on 08.06.01 in [EMAIL PROTECTED]: Only the truly stupid would assume accuracy from decimal places. Well then, tell all the teachers in this world that they're stupid, and tell everyone who learnt from them as well. *All*? I'm in high school (gd. 11, junior) and my physics teacher is always screaming at us for putting too many decimal places or having them inconsistent. Ok, *yours*. But yours is not all. I certainly don't remember ever seeing that attitude in school. And yes, this behaviour *is* stupid. Someone who thinks like that should never be allowed to become a science teacher. MfG Kai - 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/
State changes for T/TCP
Hi everyone, I am trying to implement T/TCP in linux 2.2.14. I am using a Linux box as a client and a FreeBSD box as server. I have the following problem: I send multiple data packets from the client, the sequence looks like this: 1. Client sends syn with data SYN, PSH 2. Client sends data PSH 3. Client sends data along with its fin FIN, PSH 4. Server sends synack SYN, ACK 5. Server sends his data and finishes FIN, PSH, ACK 6. Client acks the data ACK 7. Server sends fin again FIN, ACK 8. Client sends reset RST My problem is in segment 8. In segment 5 the client is already in FIN_WAIT2 since the server acked his fin (client's fin in segment 3) in previous segments (shown with dots), and when he gets the fin from the server he acks (segment 6) it and gets in TIME_WAIT (tcp_time_wait() in 2.2.14). But in tcp_time_wait() the original socket gets linked to another socket-like structure and then gets closed (CLOSE). Now, when the segment 7 arrives it is dropped by the client (since its socket is in CLOSE state) and a RST is send back. But what should happen in T/TCP is that in segment 8 i should have an ACK for the FIN in segment 7. My question now (provided that all that i have mentioned before are correct) is: Should i change the above behaviour of original TCP? If i leave the socket in TIME_WAIT instead of CLOSE, would that require further changes? Thank you all in advance Tasos p.s. please CC your e-mail to my address ([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: [OT] Threads, inelegance, and Java
Rob Landley writes: On Wednesday 20 June 2001 15:53, Martin Dalecki wrote: Mike Harrold wrote: super computing, hmm what about some PowerPC CPU variant - they very compettetiv in terms of cost and FPU performance! Transmeta isn't the adequate choice here. You honestly think you can fit 142 PowerPC processors in a single 1U, air cooled? That 142 would be what, a SHARC DSP system? It sure doesn't look like Transmeta's Crueso. The best I found was 6 and 8 per 1U: RLX has managed to tuck 24 servers into a 3U enclosure -- 8/U WebBunker units can hold 12 processors [in 2U] -- 6/U For PowerPC I found 32/U to 40/U, in increments of 9U. See www.mc.com for an example. The processor gets you 4 (four!) floating-point fused multiply-add operations per cycle, typically at 400 MHz. Being optimistic, that's a teraflop in 9U. Liquid air cooled, maybe... Nope, plain old air or conduction. If you're going to rant about off-topic junk, at least try to throw in a few useful references so people can check facts and maybe take advantage of whatever it is you're ranting about. (yeah, yeah, sorry about the VGA console thing) - 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.6pre iptables masquerading seems to kill eth0
I have a home network with two machines connected with 3c905B cards. The main machine also has a isdn dialup connection. Networking works well except if I let the main machine masquerade so the other can use the internet too. I use iptables for this. It works for a day or so, then eth0 goes silent on the main machine. (Rebooting it shows that the other one was fine all the time.) The symptoms is that there is no contact between the two machines. No ping or anything. ifconfig shows the interface is up with the correct ip address, but all packets just disappear. There are no error messages except from programs that time out. Bringing the interface down and up again with ifconfig does not help. It is compiled into the kernel, so I can't try module reloading. Is this some sort of known problem? Or is there something I could do to find out more? I couldn't find anything in the logfiles. Helge Hafting. - 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: The latest Microsoft FUD. This time from BillG, himself.
On Wed, Jun 20, 2001 at 05:53:44PM -0500, [EMAIL PROTECTED] wrote: Not I. The slides for my last meeting were done as TIFF files and I used xv to display them. Plus, the most recent documentation I wrote for one of our mainframe applications was done with vi and LaTeX. What, in addition to the printed copies, you want a copy of the Word document? There is no Word document. But I'll convert it to Rich Text for you and you can take it from there. If my employer didn't require me to use them occasionally, I'd delete every Microsoft product on my laptop. It's not that I have anything against proprietary software. It's just Microsoft that I despise. I did the slides for my last LUG talk in MagicPoint (apt-get install mgp, or on rpmfind.net, or wherever, maybe even with RH, I don't know). Very clean format - see http://kabuki.sfarc.net/daniel/netfilter/netfilter.mgp -- Daniel Stone [EMAIL PROTECTED] Nuke can NE1 help me aim nuclear weaponz? /MSG 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/
cproto use in the kernel source tree?
I would like to automate generating the prototype list for smbfs. The list in include/linux/smb_fs.h is probably mostly correct ... or not. Does anyone use this type of tool anywhere else in the kernel sources? Any input on how to set it up right is appreciated. Here is what I have right now. arch/i386/math-emu/Makefile has this rule proto: cproto -e -DMAKING_PROTO *.c fpu_proto.h If I do that in the smbfs Makefile, and run it as: $ make TOPDIR=`pwd` -C fs/smbfs proto I get heaps of errors (some of which I also get for the math-emu rule and fpu_proto.h is definitly hand edited, so I wonder if it is really used). For one thing it goes digging in /usr/include/asm/ which isn't exactly what I want. I can improve it by changing the rule to: proto: cproto -e -I$(TOPDIR)/include -D__KERNEL__ -DMAKING_PROTO *.c proto.h And that seems to sort of work. The only thing is that I get wierd errors on some gcc header: /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdarg.h, line 43: parse error at token '__builtin_va_list' Expected: auto char define-name double extern inline register static ... union $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.0) $ rpm -qf `which gcc` gcc-2.96-69 $ rpm -qf `which cproto` cproto-4.6-5 I know it stops working (it misses some functions and complains more :) after I apply some of my non-released patches. But that is probably something I do wrong. Is cproto even a good tool for doing this in the kernel tree? /Urban - 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: aic7xxx oops with 2.4.5-ac13
Hello,
At Thu, 21 Jun 2001 08:15:10,
Trevor Hemsley wrote:
On Thu, 21 Jun 2001 03:05:02, Jeff V. Merkey
[EMAIL PROTECTED] wrote:
Ditto. I am also seeing this oops calling the sg driver for a
robotic tape library, and it also seems to happen on 2.4.4.
In my case it appears that it was the symptom of severe bus problems.
About 5 minutes after I posted the initial report I discovered that
the cable from the back of the Nikon to the MO drive had fallen off so
the bus was running unterminated. Replugging it fixed teh bus error
and the oops.
Looks like error handling is all fscked up...
I saw this oops too. The following patch is working for me, but I don't
know this is a correct fix.
diff -r -N -u linux.org/drivers/scsi/aic7xxx/aic7xxx_linux.c
linux/drivers/scsi/aic7xxx/aic7xxx_linux.c
--- linux.org/drivers/scsi/aic7xxx/aic7xxx_linux.c Fri Mar 16 13:47:01 2001
+++ linux/drivers/scsi/aic7xxx/aic7xxx_linux.c Fri Mar 16 13:54:34 2001
@@ -1872,7 +1872,9 @@
break;
case AC_BUS_RESET:
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,3,0)
- scsi_report_bus_reset(ahc-platform_data-host, channel - 'A');
+ if (ahc-platform_data-host) {
+ scsi_report_bus_reset(ahc-platform_data-host, channel - 'A');
+ }
#endif
break;
default:
-
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-ac15
On Thu, 21 Jun 2001, Marcelo Tosatti wrote: On Thu, 21 Jun 2001, Mike Galbraith wrote: On Thu, 21 Jun 2001, Marcelo Tosatti wrote: 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 198 1 ^ Ok, I suspect that GFP_BUFFER allocations are fucking up here (they can't block on IO, so they loop insanely). Why doesn't the VM hang the syncing of queued IO on these guys via wait_event or such instead of trying to just let the allocation fail? Actually the VM should limit the amount of data being queued for _all_ kind of allocations. Limiting the amount of data being queued for IO will make things less ragged, but you can't limit the IO.. pages returning to service upon completion is the only thing keeping you alive. That's why I hate not seeing my disk utterly saturated when things get hot and heavy. The only thing that I can see that's possible is to let tasks proceed in an ordered fashion as pages return.. take a number and wait. IMHO, right now we try to maintain low latency way too long and end up with the looping problem because of that. We need a more controlled latency roll-down to the full disk speed wall. We hit it and go splat ;-) The problem is the lack of a mechanism which allows us to account the approximated amount of queued IO by the VM. (except for swap pages) Ingo once mentioned an io thingy for vm, but I got kind of dizzy trying to figure out exactly how I'd impliment, what with clustering and getting information to seperate io threads and back ;-) You can see it this way: To get free memory we're polling instead of waiting on the IO completion of pages. (which seems to me will only cause the allocation to be resubmitted, effectively changing nothing but adding overhead) Yes. (not that overhead really matters once you are well and truely iobound) -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: SCSI Tape corruption - update
On Tue, 8 May 2001, Geert Uytterhoeven wrote:
On Mon, 7 May 2001, Lorenzo Marcantonio wrote:
On Mon, 7 May 2001, Rob Turk wrote:
Have you ruled out hardware failures? There's been a few isolated reports
That tape drive (Sony SDT-9000, less than 2 years of service) works
perfectly on Windows NT (were it was before) and even on Linux 2.2
Also the cartridge was brand new.
In the mean time I down/upgraded to 2.2.17 on my PPC box (CHRP LongTrail,
Sym53c875, HP C5136A DDS1) and I can confirm that the problem does not happen
under 2.2.17 neither.
My experiences:
- reading works fine, writing doesn't
- 2.2.x works fine, 2.4.x doesn't (at least since 2.4.0-test1-ac10)
- hardware compression doesn't matter
- I have a sym53c875, Lorenzo has an Adaptec, so most likely it's not a
SCSI hardware driver bug
- I have a PPC, Lorenzo doesn't, so it's not CPU-specific
- corruption is always a block of 32 bytes being replaced by 32 bytes from
the previous tape block (depending on block size!) (approx. 6 errors per
256 MB)
Lorenzo, can you please investigate the exact nature of the corruption on your
system?
- How many successive bytes are corrupted?
- Where do the corrupted data come from?
Yesterday I noticed the same corruption under 2.2.19 (yes, I run amverify after
backing up my system now, so it detects corruption through the gzip CRCs).
I'll do some more tests (when I find time) to get a higher statistical
certainty that it really doesn't happen under earlier 2.2.x kernels.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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] Threads, inelegance, and Java
I have seen school projects with interfaces done in java (to be 'portable') and you could go to have a coffee while a menu pulled down. Yeah, but the slowness there comes from the phrase school project and not the phrase done in java. I've seen menuing interfaces on a 1 mhz commodore 64 that refreshed faster than the screen retrace, and I've WRITTEN java programs that calculated animated mathematical function plots point by point in realtime on a 486. Sure, but the Commodore had highly-optimised code working for it. I think I'm a long way beyong the school project stage, but I've had REAL difficulty getting Java to perform well. As one of the assignments in my 1st-year CompSci course, we got to write a program which checked for balanced braces in a source file. We were supposed to do this in Java - at the time, the Blackdown 1.1.8 JVM was current. I and a classmate used a 160K C source file from a MUD as a test load. He ran it multiple times on the Solaris system provided for 1st-year programming, I ran it on my Linux 486. My first effort was a nice clean OOP-friendly implementation which made heavy use of Java's nice-looking String operators. As anyone who has worked with Java will be able to guess, this was also an extremely slow and inefficient implementation. I recall it took upwards of 2 minutes to parse that source file and confirm that it had properly-paired braces. This on a machine which now handles DNS, e-mail, webcaching, webserving, and sometimes gateway duties for my other machines. Much work later, I garnered an implementation that used more C-like operators and looked much messier, but ran 6 times quicker. Most of the work went into eliminating object creation and destruction, which tickled Java's extremely slow garbage collection. I still don't fully understand why free() has no equivalent in Java. My classmate got his version running even faster, but I don't know how he managed it. Then I quickly hacked up a C version of the same program using the same algorithm, and compiled it using GCC. It immediately ran 6 times quicker still, and consumed less than a 50th of the memory. With 28Mb RAM, I could only run 4 copies of the Java program in parallel before the machine started thrashing, but the C version got to 20 copies before the terminal simply got too sluggish to start any more (the machine was not thrashing, it was just under severe load). All 20 copies completed in less time than a single instance of the original Java implementation. Incidentally, I've used VB as well, and it's even worse. I couldn't get a P75 to drive a stepper-motor at more than 4 steps per second, and that was hardly a complex algorithm. Given that I learned basic programming techniques using BBC BASIC on a 2MHz 6502, I *know* that's pathetic even for interpreted BASIC. When an ARM610 at 40MHz running interpreted BASIC can outperform highly-optimised 16-bit x86 assembly on a 486SX/40, you know Acorn got their interpreter done better than M$ did. Until java can be efficiently compiled, it is no more than a toy. I haven't played with Jikes. Nor have I. But frankly, I don't care. Neither C, nor C++, nor Java make good beginner's languages. The former two are efficient and safe if handled with some care. The latter is safe but not efficient even in an expert's hands. I still had the GOOD bits of C++ syntax without having to worry about conflicting virtual base classes. H... a well-designed C++ system doesn't have to worry about that either. C++'s features are only bad if misused - it's an expert's language for crying out loud. See above. Traversing a list of objects to draw is not time consuming, implementing a zbuffer or texturing is. Try to implement a zbuffer in java. I'll top that, I tried to implement deflate in java 1.0. (I was porting info-zip to java when java 1.1 came out. Yeah, the performance sucked. But the performance of IBM's OS/2 java 1.0 jdk sucked compared to anything anybody's using today (even without JIT). That reminds me... allocating a two-dimensional array in Java is a *real* *pain*. You have to declare the darn thing as an array of arrays, and then allocate that array of arrays explicitly, and then loop through that bloody array and allocate each subarray individually! The alternative is to allocate a one-dimensional array and use what amounts to heavy pointer arithmetic, which can't be cheap on the CPU. The problem with java is that people tries to use it as a general purpose programming language, and it is not efficient. It can be used to organize your program and to interface to low-level libraries written in C. But do not try to implement any fast path in java. I once wrote an equation parser that took strings, substituted values for variables via string search and replace, and performed the calculation the string described. It did this for every x pixel in a 300 pixel or so
AGP for 760MP chipset
I managed to get my hands on a dual athlon box and get it working fairly well. I have been unable to get agpgart working however because it is an unrecognized chipset. It would be great to get this working and I would be happy to supply any info or do some testing for the developers. On a side note the kernel cannot identify many of the interfaces. For example: 00:00.0 Host bridge: Advanced Micro Devices [AMD]: Unknown device 700c (rev 11) 00:01.0 PCI bridge: Advanced Micro Devices [AMD]: Unknown device 700d 00:07.0 ISA bridge: Advanced Micro Devices [AMD]: Unknown device 7410 (rev 02) 00:07.1 IDE interface: Advanced Micro Devices [AMD]: Unknown device 7411 (rev 01) 00:07.3 Bridge: Advanced Micro Devices [AMD]: Unknown device 7413 (rev 01) 00:07.4 USB Controller: Advanced Micro Devices [AMD]: Unknown device 7414 (rev 07) 00:0a.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 04) 00:0a.1 Input device controller: Creative Labs SB Live! (rev 01) 00:0c.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c895 (rev 01) 00:0f.0 Ethernet controller: 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T] (rev 78) 00:10.0 Ethernet controller: 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T] (rev 78) 01:05.0 VGA compatible controller: nVidia Corporation NV15 Bladerunner (Geforce2 GTS) (rev a4) Though it's not that big of a deal it would make it look more purty. Steven - 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: The latest Microsoft FUD. This time from BillG, himself.
Alan Cox wrote: http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html Of course the URL that goes with that is : http://www.microsoft.com/windows2000/interix/features.asp Yes., Microsoft ship GNU C (quite legally) as part of their offerings... Do they include the source? There's a CD of source that you can buy for $20 but gcc isn't listed - 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.6-preX and MediaGX
Hi, I'm trying to build a kernel for Cyrix MediaGX. Kernel version is 2.4.6-pre3 as it comes straight from the XFS devel tree. Processor type is set to 586/K5/5x86/6x86/6x86MX. Everything compiles fine. Here comes my problem : the darn thing won't boot. I've seen at least 3 different behaviours after the Uncompressing Linux... Ok, booting the kernel message : Most of the time, it just crashes, nothing special. Sometimes, the screen blinks and turns blank (FB is not in...) Once or twice out of 20+ times, kernel panics. Any idea ? If you need the kernel panic trace I can try to reproduce it, though it seems very random. Regards, Thibaut - 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/
Is it useful to support user level drivers
I realize that the Linux kernel supports user level drivers (via ioperm, etc). However interrupts at user level are not supported, does anyone think it would be a good idea to add user level interrupt support ? I have a framework for it, but it still needs a lot of work. Depending on the response I get, I can send out more email. Please cc me to the replies as I am no longer a part of the Linux kernel mailing list - due to the humble size of my mail box. Balbir __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.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/
Kernel hooks
Can anyone tell me how I can use kernel hooks in my program? I want to raise an action when a network connection to my server is established? Ufuk Yuzereroglu - 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.6-preX and MediaGX
Thibaut LAURENT [EMAIL PROTECTED] wrote: Any idea ? Try without APIC support compiled into the kernel. I've seen too many different setup's barf on that! ;-) Danny -- Holland Hosting www.hoho.nl [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: Is it useful to support user level drivers
On Thu, Jun 21, 2001 at 03:41:32AM -0700, Balbir Singh wrote: I realize that the Linux kernel supports user level drivers (via ioperm, etc). However interrupts at user level are not supported, does anyone think it would be a good idea to add user level interrupt support ? I have a framework for it, but it still needs a lot of work. Well, for parallel port devices, take a look at libieee1284 and /dev/parport0. Tim. */ PGP signature
Re: temperature standard - global config option?
Only the truly stupid would assume accuracy from decimal places. Well then, tell all the teachers in this world that they're stupid, and tell everyone who learnt from them as well. *All*? I'm in high school (gd. 11, junior) and my physics teacher is always screaming at us for putting too many decimal places or having them inconsistent. Ok, *yours*. But yours is not all. I certainly don't remember ever seeing that attitude in school. And yes, this behaviour *is* stupid. Someone who thinks like that should never be allowed to become a science teacher. *cough* I've been taught by every Maths, Engineering and Physics teacher/lecturer I've encountered to write down significant figures consistent with the precision of the value. So blindly writing down a value of 59.42886726469 ±2°C is obviously ludicrous, even if that's what my calculator gives me. I should instead write 59 ±2°C, since that is the most precision I can possibly know it to. With some advanced measuring techniques it *may* be acceptable to write 59.43 ±2°C *at most*, and then only if you really know why you need the extra information. The UK education system is one of the better ones available, and the above philosophy is consistently held throughout it. I'd be well advised not to argue, especially since it's common sense. -- -- from: Jonathan Chromatix Morton mail: [EMAIL PROTECTED] (not for attachments) website: http://www.chromatix.uklinux.net/vnc/ geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) tagline: The key to knowledge is not to rely on people to teach you it. - 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: ip_tables/ipchains
On Wed, 20 Jun 2001, Pete Toscano wrote: I had a similar problem with this yesterday. Try moving your .config file to a safe place, making mrproper, then moving your .config back and rebuilding. I did this and all was well. HTH, pete Thanks Pete. I will give that a try.. On Wed, 20 Jun 2001, Ted Gervais wrote: Wondering something.. I ran insmod to bring up ip_tables.o and I received the following error: /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved symbol nf_unregister_sockopt /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved symbol nf_register_sockopt This is with kernel 2.4.5 and Slackware 7.1 is the distribution. Does anyone know what these unresolved symbols are about?? --- Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire Ted Gervais [EMAIL PROTECTED] 44.135.34.201 linux.ve1drg.ampr.org - 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/
Loop encryption module locking bug (linux-2.4.5).
Hi,
There is a bug in the locking scheme for the encryption functions,
which can be hooked into the loop device. I have a patch
which resolves the problem. First what happens:
If you do (for example) a losetup -e twofish /dev/loop0 test.lop
the following happens:
The loop0 device gets opened (to use ioctl after that). Because no cipher
is selected, the loop device hasn't an associated transfer function
(lo-lo_encrypt_type is zero). That means, that lo_open doesn't call a lock
function.
Then you set your password and loop_set_status is called (via ioctl), which
sets lo-lo_encrypt_type to the correct cipher and also calls the
lock function of the cipher.
When this is done, losetup closes the device and lo_release is called.
Now lo-lo_encrypt_type contains the right value and this leads to
calling the unlock function of the appropriate cipher.
After that the cipher isn't locked any more, so you can
rmmod the corresponding cipher, regardless of the fact that
the loop device still has hooks into it.
If lo_open doesn't call the cipher lock function and
lo_release doesn't call the cipher unlock function, the issue
is resolved. (So code gets deleted in the patch.)
xfer_funcs[type]-lock is then called, when a cipher is selected for a
specific loop device. Unlock is called when a cipher is deselected for a
specific loop device. It doesn't matter if the device is opened or
not, which isn't important for the locking anyway.
The patch which is attached, is against linux-2.4.5.
I try to get this patch in the kernel for quite some time, but
it seems I do something wrong (or no one is interested) ?
Perhaps it will go in this time...
so long
Ingo
PS: Because I try to understand the inner workings of the loop
device better, I have a question:
In lo_send is a loop: while (len0). How can I configure
a loop device, so that this loop is executed more than once.
It seems this is only possible if bh-b_size is greater
than PAGE_CACHE_SIZE. Does this mean, you have to work on
a filesystem which uses blocks of a size PAGE_CACHE_SIZE,
or is bh-b_size a fixed value (which is always less than
PAGE_CACHE_SIZE) ?
--- drivers/block/loop.c~ Mon Apr 30 17:59:20 2001
+++ drivers/block/loop.cThu May 31 14:41:01 2001
@@ -864,7 +864,7 @@
static int lo_open(struct inode *inode, struct file *file)
{
struct loop_device *lo;
- int dev, type;
+ int dev;
if (!inode)
return -EINVAL;
@@ -879,10 +879,6 @@
lo = loop_dev[dev];
MOD_INC_USE_COUNT;
down(lo-lo_ctl_mutex);
-
- type = lo-lo_encrypt_type;
- if (type xfer_funcs[type] xfer_funcs[type]-lock)
- xfer_funcs[type]-lock(lo);
lo-lo_refcnt++;
up(lo-lo_ctl_mutex);
return 0;
@@ -891,7 +887,7 @@
static int lo_release(struct inode *inode, struct file *file)
{
struct loop_device *lo;
- int dev, type;
+ int dev;
if (!inode)
return 0;
@@ -906,11 +902,7 @@
lo = loop_dev[dev];
down(lo-lo_ctl_mutex);
- type = lo-lo_encrypt_type;
--lo-lo_refcnt;
- if (xfer_funcs[type] xfer_funcs[type]-unlock)
- xfer_funcs[type]-unlock(lo);
-
up(lo-lo_ctl_mutex);
MOD_DEC_USE_COUNT;
return 0;
Re: Is it useful to support user level drivers
On Thu, 21 Jun 2001, Balbir Singh wrote: I realize that the Linux kernel supports user level drivers (via ioperm, etc). However interrupts at user level are not supported, does anyone think it would be a good idea to add user level interrupt support ? I have a framework for it, but it still needs a lot of work. http://www.ibiblio.org/pub/Linux/kernel/irq-1.68.2.tar.gz ftp://ftp.inp.nsk.su/export/fedorov/soft/irq-1.68.2.tar.gz (2.0.x - 2.2.x kernels) kernel module to delivery hardware interrupts to user space programs. Hardware interrupts (IRQ) are accessible by character devices /dev/irq[0-15]. Interrupts delivered by signals and select(2)/poll(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: temperature standard - global config option?
Jonathan Morton wrote: I should instead write 59 ±2°C, since that is the most precision I can possibly know it to. With some advanced measuring techniques it *may* be acceptable to write 59.43 ±2°C *at most*, and then only if you really know why you need the extra information. It's easy to conceive of a device which, for whatever reason, gives an absolute reading accurate ±2°C, but which tracks temperature changes somewhat more accurately. And hence a small difference between successive readings still has significance. A real-world example is a mercury thermometer in which the glass has been physically shifted relative to an adjacent scale. So 18°C reads as 20°C, etc. Cheers, Phil - Phil Randal Network Engineer Herefordshire Council Hereford, UK - 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/
[OOPS] Failed to boot 2.4.6-pre5
Hi,
[1.] One line summary of the problem:
I can not start 2.4.6-pre5 on my machine.
[2.] Full description of the problem/report:
I've tried to upgrade from 2.4.5-pre1 to 2.4.6-pre5 but it failed the new
kernel failed to boot. It OOPS-es while it's starting. I managed to write
down some of the OOPS parameters.
[3.] Keywords (i.e., modules, networking, kernel):
kernel boot.
[4.] Kernel version (from /proc/version):
2.4.6-pre5
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
All information that I have not saved is replaced with zeroes. So I got
only the EIP, call trace and the Code:
ksymoops 2.3.4 on i686 2.4.5-pre1. Options used
-v /usr/src/linux/vmlinux (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.4.5-pre1/ (default)
-m /boot/System.map (specified)
No modules in ksyms, skipping objects
Oops: 0001
CPU:1
EIP:0010:[c0116f72]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS:
eax: ebx: ecx: edx:
esi: edi: ebp: esp:
ds: es: ss:
Process swapper (pid: 0, stackpage=)
Call Trace: [c0116d8d] [c0107fe9] [c0105000] [c0106bd0] [c0105000]
[c0105000]
Code: 0f 0b 83 c4 0c 90 8b 43 08 85 c0 75 15 fb 8b 43 10 50 8b 43
EIP; c0116f72 tasklet_hi_action+6a/ac =
Trace; c0116d8d do_softirq+45/6c
Trace; c0107fe9 do_IRQ+9d/b0
Trace; c0105000 _stext+0/0
Trace; c0106bd0 ret_from_intr+0/7
Trace; c0105000 _stext+0/0
Trace; c0105000 _stext+0/0
Code; c0116f72 tasklet_hi_action+6a/ac
_EIP:
Code; c0116f72 tasklet_hi_action+6a/ac =
0: 0f 0b ud2a =
Code; c0116f74 tasklet_hi_action+6c/ac
2: 83 c4 0c addl $0xc,%esp
Code; c0116f77 tasklet_hi_action+6f/ac
5: 90nop
Code; c0116f78 tasklet_hi_action+70/ac
6: 8b 43 08 movl 0x8(%ebx),%eax
Code; c0116f7b tasklet_hi_action+73/ac
9: 85 c0 testl %eax,%eax
Code; c0116f7d tasklet_hi_action+75/ac
b: 75 15 jne22 _EIP+0x22 c0116f94
tasklet_hi_action+8c/ac
Code; c0116f7f tasklet_hi_action+77/ac
d: fbsti
Code; c0116f80 tasklet_hi_action+78/ac
e: 8b 43 10 movl 0x10(%ebx),%eax
Code; c0116f83 tasklet_hi_action+7b/ac
11: 50pushl %eax
Code; c0116f84 tasklet_hi_action+7c/ac
12: 8b 43 00 movl 0x0(%ebx),%eax
[6.] A small shell script or example program which triggers the
problem (if possible)
N/A.
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux cyrix 2.4.5-pre1 #1 Tue May 8 11:27:27 EEST 2001 i686 unknown
Gnu C egcs-2.91.66
Gnu make 3.77
binutils 2.9.1.0.25
usage: fdformat [ -n ] device
mount 2.9v
modutils 2.4.6
e2fsprogs 1.15
PPP2.4.0b1
Linux C Library2.2.3
Dynamic linker (ldd) 2.2.3
Procps 2.0.6
Net-tools 1.52
Kbd0.99
Sh-utils 1.16
Modules Loaded
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : CyrixInstead
cpu family : 6
model : 2
model name : 6x86MX 2.5x Core/Bus Clock
stepping: 7
cpu MHz : 166.451
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: yes
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 pge cmov mmx cyrix_arr
bogomips: 331.77
[7.3.] Module information (from /proc/modules):
No modules are loaded.
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
0280-029f : eth0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
4000-403f : Intel Corporation 82371AB PIIX4 ACPI
5000-501f : Intel Corporation 82371AB PIIX4 ACPI
6400-641f : Intel Corporation 82371AB PIIX4 USB
6800-68ff : Realtek Semiconductor Co., Ltd. RTL-8139
6800-68ff : 8139too
6c00-6c1f : Realtek Semiconductor Co., Ltd. RTL-8029(AS)
6c00-6c1f : ne2k-pci
7000-70ff : Realtek Semiconductor Co., Ltd. RTL-8139 (#2)
7000-70ff : 8139too
7400-741f : Realtek Semiconductor Co., Ltd. RTL-8029(AS) (#2)
7400-741f : ne2k-pci
f000-f00f : Intel Corporation
Re: Loop encryption module locking bug (linux-2.4.5).
sarcasm I think your mail is offtopic for linux-kernel: it doesn't mention Microsoft or user space java programming or pointer to random unrelated web pages, but an actual kernel bug. /sarcasm Ingo Rohloff [EMAIL PROTECTED] writes: If lo_open doesn't call the cipher lock function and lo_release doesn't call the cipher unlock function, the issue is resolved. (So code gets deleted in the patch.) I think it would be better if the low level module stays locked also while the control fd is open. That would match the semantics of most other devices. Right fix probably is to call -lock twice in loop_set_status() [Also the locking is not SMP safe, but that's a different issue, for the e.g. -lock would need to be replaced with a struct module *owner and also some other locking] -Andi - 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: wait_for_cmd_done timeout
---Reply to mail from Dionysius Wilson Almeida about eepro100: wait_for_cmd_done timeout No..that was pretty much what i saw in the logs. I see wait_for_cmd_done timeout being the only one being repeated in the logs The same here with 2.4.1 and 2.4.3. Rafael Martinez - 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: temperature standard - global config option?
On Thu, 21 Jun 2001, Randal, Phil wrote: Jonathan Morton wrote: I should instead write 59 ±2°C, since that is the most precision I can possibly know it to. With some advanced measuring techniques it *may* be acceptable to write 59.43 ±2°C *at most*, and then only if you really know why you need the extra information. It's easy to conceive of a device which, for whatever reason, gives an absolute reading accurate ±2°C, but which tracks temperature changes somewhat more accurately. And hence a small difference between successive readings still has significance. A real-world example is a mercury thermometer in which the glass has been physically shifted relative to an adjacent scale. So 18°C reads as 20°C, etc. Cheers, Phil - Phil Randal Network Engineer Herefordshire Council Hereford, UK - The difference between accuracy and resolution is often not understood. Without insulting everybody with grade-school math, suffice to say that it is possible, and even useful for a 8-bit (0 to 255) ADC software to display a number such as 1.23456. It is also possible for the very next value displayed to be 1.23457, i.e., no missing output codes. Note, 123457 requires 17 bits to be displayed with no missing codes (intervals). This is done by sampling the ADC at a fixed time interval and averaging, actually using an IIR filter. With a very simple average, i.e. value = (value + new_sample) / 2, you end up with a bias slightly less than 2, so this is not useful in precision work, but the result improves the resolution by sqrt(2) = 1.41. Working versions of sampling + IIR filters can improve the resolution by any amount you want to wait for. Accuracy involves comparison against some standard. ADCs are not generally accurate. However they can be calibrated and even continuously calibrated so that the result is almost as accurate as the standard. The heat sensors in newer Ix86 Machines are not accurate nor are they meant to be. It is a waste of CPU resources to precisely sample and filter these sensors. However, very simple integer math will give you a decimal point. If you don't use a decimal point, then you are throwing away potentially useful information. If the heat-sink is getting hotter and hotter and hotter... etc., do you want to know it right away or have to wait for the temperature to get to another even (integer) interval? The answer is obvious. Don't throw away any information, even though the displayed result implies some unobtainable accuracy. 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: The latest Microsoft FUD. This time from BillG, himself.
On Thu, 21 Jun 2001, Paul Flinders wrote: Alan Cox wrote: http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html Of course the URL that goes with that is : http://www.microsoft.com/windows2000/interix/features.asp Yes., Microsoft ship GNU C (quite legally) as part of their offerings... Do they include the source? There's a CD of source that you can buy for $20 but gcc isn't listed I'm not sure if they are allowed to do that. See clause 1 (c): http://msdn.microsoft.com/msdn-files/027/001/516/eula_mit.htm 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: The latest Microsoft FUD. This time from BillG, himself.
On Wed, Jun 20, 2001 at 11:09:10PM +0100, Alan Cox wrote: http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html Of course the URL that goes with that is : http://www.microsoft.com/windows2000/interix/features.asp Yes., Microsoft ship GNU C (quite legally) as part of their offerings... Which brings up an interesting question for us all. Let's postulate, for the sake of discussion, that we agree on the following: a) Linux (or just about any Unix) is a better low level OS than NT b) Microsoft's application infrastructure is better (the COM layer, the stuff that lets apps talk to each, the desktop, etc). Not completly - the COM layer is (my opinion) part of what propagates some of their security problems. What else would be capable of disabling a cruser so fast (and take two hours to restart)... There appears to be no functional difference between COM and CORBA (based on superficial knowlege only) except specification availability. I know we can argue that KDE/GNOME/whatever is going to get there or is there or is better, etc., but for the time being lets just pretend that the Microsoft stuff is better. What would be wrong with Microsoft/Linux? It would be: a) the Linux kernel b) the Microsoft API ported to X c) Microsoft apps d) Linux apps Since Microsoft is all about making money, it doesn't matter if they charge for the dll's or the OS, either one is fine, you can't run Word without them. If you don't need the Microsoft apps, you could strip them off and strip off the dlls and ship all the rest of it without giving Microsoft a dime. If you do need the apps or you want the app infrastructure, you have to give Microsoft exactly what you have to give them today - money - but you can run Word side by side with Ghostview or whatever. Microsoft could charge exactly the same amount for the dll's as they charge for the OS, none of the end users can tell the difference anyway. Ah yes, raise the Mr. Bill tax... The DLLs ought to be less than half the price of the OS .. after all, they are a small part of the distribution and belong to the application(s). If you attempt to find a full installation of NT (JUST the OS), it will cost ~400+ dollars (US). If you then add Office, add an additional 200. If you want program development, add another 200 to 600, maybe more since I haven't looked recently. For the most part, I wouldn't complain too much about their prices. If the products would work. If they didn't have such horrible security. If the patches supplied would also work and not introduce more and different failures. BTW, the prices are actually slightly less than what ATT, SCO, and others charged for pieces of a unix system when they were originally sold ($600 base os, $600 application development, $600 documentation workbench all values approximate, from memory). I'm unimpressed with what Microsoft calls an operating system and I'm equally unimpressed with what Unix calls an application layer. For the last 10 years, Unix has gotten the OS right and the apps wrong and Microsoft has gotten the apps right and the OS wrong. Seems like there is potential for a win-win. I'm equally unimpressed by their applications - how many macro viruses exist? How do they propagate? How many times do they change file formats? How many patches are (re)issued to fix the same problem? The biggest improvement would be that users could remain with a version that works for them and NOT be forced to pay more money for the same functionality (watch out for the XP license virus... also known as a logic bomb). You can scream all you want that it isn't free software but the fact of the matter is that you all scream that and then go do your slides for your Linux talks in PowerPoint. Not by choice - I'm forced to use M$ crap because the conferences will not accept anything else (yet another monopoly point). Personally, I would prefer to use Applix, StarOffice, WordPerfect, FrameMaker, ... Only one of which is free. I agree that M$ applications should be available. But until M$ quits appropriating other peoples code and calling it theirs I, for one, don't want to be forced to use them. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - 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/
fealnx problem
I have an Surecom EP-320X-S Ethernet adapter which apparently uses a Myson MTD-8xx chip. It works well with the fealnx driver (labeled Myson MTD-8xx PCI Ethernet support in kernel config) except for one thing: After a while in use it stops working and prints Jun 21 12:18:18 naut kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 21 12:18:18 naut kernel: eth0: Transmit timed out, status , resetting... Jun 21 12:18:18 naut kernel: Rx ring c1272140: 8000 8000 8000 8000 8000 8000 8000 8000 8000 8000 8000 8000 Jun 21 12:18:18 naut kernel: Tx ring c12722c0: 8000 8000 8000 8000 8000 a few times in the kernel log. Then I have to bring the interface down and up again (ifdown/ifup) to get it working. It seems that the higher network load the sooner it will stop working, but it always does eventually. It's impossible to transfer a large file (over, say 5 MB) via FTP for example, but with scp it often works (the encryption makes the transfer slower). CC me. thanks, --zzed # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # # CONFIG_IP_NF_CONNTRACK is not set # CONFIG_IP_NF_IPTABLES is not set # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD
Re: The latest Microsoft FUD. This time from BillG, himself.
Larry McVoy wrote: You can scream all you want that it isn't free software but the fact of the matter is that you all scream that and then go do your slides for your Linux talks in PowerPoint. Never used powerpoint. If I need slides I use a (linux-based) word processor and a bigger font than for paper. Or html if I need something more fancy than text. Html works great, and is also nifty if I need to put the stuff on the web for later reference. No conversion needed, and readers don't need anything but the browser they're using. Helge Hafting - 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] i810 watchdog driver: support for i815/i8[2456]0 chipsets
Hi all,
this small patch (2.4.5-ac16) adds Intel i815/i820/i840/i850/i860 chipsets support
into i810 TCO watchdog driver, also MODULE_DEVICE_TABLE added.
Should work but untested (can't stop server just to test it :)
Best regards.
--
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc
diff -ur linux.vanilla/drivers/char/i810-tco.c linux/drivers/char/i810-tco.c
--- linux.vanilla/drivers/char/i810-tco.c Thu Jun 21 10:52:57 2001
+++ linux/drivers/char/i810-tco.c Thu Jun 21 10:55:48 2001
@@ -232,18 +232,40 @@
}
}
+/*
+ * Data for PCI driver interface
+ *
+ * This data only exists for exporting the supported
+ * PCI ids via MODULE_DEVICE_TABLE. We do not actually
+ * register a pci_driver, because someone else might one day
+ * want to register another driver on the same PCI id.
+ */
+static struct pci_device_id i810tco_pci_tbl[] __initdata = {
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_0, PCI_ANY_ID,
+PCI_ANY_ID, },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_0, PCI_ANY_ID,
+PCI_ANY_ID, },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0, PCI_ANY_ID,
+PCI_ANY_ID, },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_10, PCI_ANY_ID,
+PCI_ANY_ID, },
+ { 0, },
+};
+MODULE_DEVICE_TABLE (pci, i810tco_pci_tbl);
+
static struct pci_dev *i810tco_pci;
static unsigned char i810tco_getdevice (void)
{
+ struct pci_dev *dev;
u8 val1, val2;
u16 badr;
/*
-* Find the PCI device which has vendor id 0x8086
-* and device ID 0x2410
+* Find the PCI device
*/
- i810tco_pci = pci_find_device (PCI_VENDOR_ID_INTEL,
- PCI_DEVICE_ID_INTEL_82801AA_0, NULL);
+
+ pci_for_each_dev(dev) {
+ i810tco_pci = pci_match_device(i810tco_pci_tbl, dev);
+ if (i810tco_pci != NULL)
+ break;
+ }
+
if (i810tco_pci) {
/*
* Find the ACPI base I/O address which is the base
Re: Linux 2.4.5-ac15
On Thursday 21 June 2001 07:44, Marcelo Tosatti wrote: On Thu, 21 Jun 2001, Mike Galbraith wrote: On Thu, 21 Jun 2001, Marcelo Tosatti wrote: Ok, I suspect that GFP_BUFFER allocations are fucking up here (they can't block on IO, so they loop insanely). Why doesn't the VM hang the syncing of queued IO on these guys via wait_event or such instead of trying to just let the allocation fail? Actually the VM should limit the amount of data being queued for _all_ kind of allocations. The problem is the lack of a mechanism which allows us to account the approximated amount of queued IO by the VM. (except for swap pages) Coincidence - that's what I started working on two days ago, and I'm moving into the second generation design today. Look at 'queued_sectors'. I found pretty quickly it's not enough, today I'm adding 'submitted_sectors' to the soup. This will allow me to distinguish between traffic generated by my own thread and other traffic. Does failing the allocation in fact accomplish more than what I'm (uhoh:) assuming? No. It sucks really badly. Amen. -- 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/
Unable to handle kernel NULL pointer dereference at virtual address - 2.4.5
Hello I have got a error in my syslog about a Null pointer in the kernel: Kernel 2.4.5 glibc 2.2.12 gcc version 2.96 2731 (Red Hat Linux 7.0) Modell: ISP2150 Motherboard: L440GX+ DP CPU: 2 x Intel Pentium III (Coppermine) 850 MHz L2 cache: 256K / Bus: 100 MHz RAM: 256 MB SCSI controller: Adaptec AIC-7896/7 Ultra2 *** Error log *** Unable to handle kernel NULL pointer dereference at virtual address 0015 printing eip: c014db72 *pde = Oops: 0002 CPU:1 EIP:0010:[c014db72] EFLAGS: 00010206 eax: 0005 ebx: cc870440 ecx: 0020 edx: c1c12000 esi: c0287140 edi: 000c ebp: c0287490 esp: c63e7e6c ds: 0018 es: 0018 ss: 0018 Process top (pid: 21710, stackpage=c63e7000) Stack: c0149366 cc870440 c1c12000 c014ee0c cc870440 c1c12000 000c c023b269 c014f096 c144f000 c1c12000 000c c1c12000 ffea cf6190e0 c01470d6 c1445060 0007 c63e6000 fff4 cf6190e0 cc80b260 c013e403 Call Trace: [c0149366] [c014ee0c] [c014f096] [c01470d6] [c013e403] [c013ec85] [c013f5a2] [c0132f26] [c013e08b] [c013322a] [c0106df7] [c010002b] Code: f0 ff 48 10 8b 42 24 83 48 14 08 52 e8 dd fe ff ff 5a c3 8d Unable to handle kernel NULL pointer dereference at virtual address 0015 printing eip: c014db72 *pde = Oops: 0002 CPU:0 EIP:0010:[c014db72] EFLAGS: 00010206 eax: 0005 ebx: cfbf1080 ecx: 0020 edx: ca546000 esi: c0287140 edi: 000c ebp: c0287490 esp: cb817e6c ds: 0018 es: 0018 ss: 0018 Process top (pid: 25765, stackpage=cb817000) Stack: c0149366 cfbf1080 ca546000 c014ee0c cfbf1080 ca546000 000c c023b269 c014f096 c144f000 ca546000 000c ca546000 ffea cfbf1260 c01470d6 c1445060 0007 cb816000 fff4 cfbf1260 cd9075a0 c013e403 Call Trace: [c0149366] [c014ee0c] [c014f096] [c01470d6] [c013e403] [c013ec85] [c013f5a2] [c0132f26] [c013e08b] [c013322a] [c0106df7] [c010002b] Code: f0 ff 48 10 8b 42 24 83 48 14 08 52 e8 dd fe ff ff 5a c3 8d *** Sincerely Rafael Martinez - 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: temperature standard - global config option?
59.42886726469 ±2°C is obviously ludicrous, even if that's what my calculator gives me. I should instead write 59 ±2°C, since So, if I follow you argument then shouldn't you be writing 58 ±2°C or should it be 60 ±2°C ? Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK - 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: Unable to handle kernel NULL pointer dereference at virtual address - 2.4.5
Rafael Martinez wrote: Hello I have got a error in my syslog about a Null pointer in the kernel: Kernel 2.4.5 glibc 2.2.12 gcc version 2.96 2731 (Red Hat Linux 7.0) Modell: ISP2150 Motherboard: L440GX+ DP CPU: 2 x Intel Pentium III (Coppermine) 850 MHz L2 cache: 256K / Bus: 100 MHz RAM: 256 MB SCSI controller: Adaptec AIC-7896/7 Ultra2 Please run oops messages through ksymoops before posting them here. The message is meaningless without knowing what symbols are mapped to what address. See linux/Documentation/oops-tracing.txt. -- Brian Gerst - 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/
needed this to run 2.4.6-pre4
still not in 2.4.6-pre4. Without this, you'll get a lot of undefined symbols referencing do_softirq Jeff [ [EMAIL PROTECTED] ] --- include/asm-i386/softirq.h Thu Jun 14 17:10:34 2001 +++ include/asm-i386/softirq.h.new Thu Jun 14 17:17:15 2001 @@ -36,13 +36,13 @@ \ .section .text.lock,\ax\; \ 2: pushl %%eax; pushl %%ecx; pushl %%edx; \ - call do_softirq; \ + call %c1; \ popl %%edx; popl %%ecx; popl %%eax; \ jmp 1b; \ .previous;\ \ : /* no output */ \ - : r (ptr) \ + : r (ptr), i (do_softirq) \ /* no registers clobbered */ ); \ } while (0) - 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: Is it useful to support user level drivers
On Thu, Jun 21, 2001 at 06:38:09PM +0700, Dmitry A. Fedorov wrote: kernel module to delivery hardware interrupts to user space programs. Hardware interrupts (IRQ) are accessible by character devices /dev/irq[0-15]. Interrupts delivered by signals and select(2)/poll(2) i believe libgpio uses the existing usb/iee1394/serial/parallel interfaces to provide a limited userspace driver capability. gphoto2 uses this to support a LOT of digital cameras entirely in userspace... obviously this concept isn't covering everything but it sure covers a lot of bases. also depends on what you understand a driver to be... from a common user's perspective it just means it makes my WinWidget work! it's similar to what you describe above in that there's a kernel interface, but it's more specific than /dev/irq5. this is good in that you don't want a different usb driver for every userspace usb device driver... http://sourceforge.net/projects/gphoto/ (i think) j. -- Bobby, jiggle Grandpa's rat so it looks alive, please -- gary larson - 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: The latest Microsoft FUD. This time from BillG, himself.
On Thursday 21 June 2001 10:46, Henning P. Schmiedehausen wrote: My last LinuxExpo talk was also made with PP, This makes about as much sense as going to a cocktail party with nose glasses on. -- 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/
[Patch] tmpfs fixes against 2.4.6-pre
Hi Linus,
the appended patch fixes several tmpfs problems:
1) writing out of a mapping of a tmpfs file into the same file can
deadlock
2) shmem_remount_fs garbles parameters which are not supplied
3) shmem_file_setup should check the maximum size
Please apply
Christoph
diff -uNr 6-pre5/include/linux/shmem_fs.h 6-pre5-fix/include/linux/shmem_fs.h
--- 6-pre5/include/linux/shmem_fs.h Sun Apr 29 20:33:00 2001
+++ 6-pre5-fix/include/linux/shmem_fs.h Thu Jun 21 15:52:25 2001
@@ -19,6 +19,7 @@
struct shmem_inode_info {
spinlock_t lock;
+ struct semaphore sem;
unsigned long max_index;
swp_entry_t i_direct[SHMEM_NR_DIRECT]; /* for the first blocks */
swp_entry_t **i_indirect; /* doubly indirect blocks */
diff -uNr 6-pre5/mm/shmem.c 6-pre5-fix/mm/shmem.c
--- 6-pre5/mm/shmem.c Tue Jun 12 09:49:28 2001
+++ 6-pre5-fix/mm/shmem.c Thu Jun 21 15:52:26 2001
@@ -3,7 +3,8 @@
*
* Copyright (C) 2000 Linus Torvalds.
* 2000 Transmeta Corp.
- * 2000 Christoph Rohland
+ * 2000-2001 Christoph Rohland
+ * 2000-2001 SAP AG
*
* This file is released under the GPL.
*/
@@ -33,7 +34,7 @@
#define TMPFS_MAGIC0x01021994
#define ENTRIES_PER_PAGE (PAGE_SIZE/sizeof(unsigned long))
-#define NR_SINGLE (ENTRIES_PER_PAGE + SHMEM_NR_DIRECT)
+#define SHMEM_MAX_BLOCKS (SHMEM_NR_DIRECT + ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
static struct super_operations shmem_ops;
static struct address_space_operations shmem_aops;
@@ -161,6 +162,7 @@
swp_entry_t **base, **ptr, **last;
struct shmem_inode_info * info = inode-u.shmem_i;
+ down(info-sem);
inode-i_ctime = inode-i_mtime = CURRENT_TIME;
spin_lock (info-lock);
index = (inode-i_size + PAGE_CACHE_SIZE - 1) PAGE_CACHE_SHIFT;
@@ -193,10 +195,14 @@
}
out:
- info-max_index = index;
+ if (index = SHMEM_MAX_BLOCKS)
+ info-max_index = index;
+ else
+ info-max_index = SHMEM_MAX_BLOCKS + 1;
info-swapped -= freed;
shmem_recalc_inode(inode);
spin_unlock (info-lock);
+ up(info-sem);
}
static void shmem_delete_inode(struct inode * inode)
@@ -281,15 +287,12 @@
* still need to guard against racing with shm_writepage(), which might
* be trying to move the page to the swap cache as we run.
*/
-static struct page * shmem_getpage_locked(struct inode * inode, unsigned long idx)
+static struct page * shmem_getpage_locked(struct shmem_inode_info *info, struct inode
+* inode, unsigned long idx)
{
struct address_space * mapping = inode-i_mapping;
- struct shmem_inode_info *info;
struct page * page;
swp_entry_t *entry;
- info = inode-u.shmem_i;
-
repeat:
page = find_lock_page(mapping, idx);
if (page)
@@ -393,6 +396,7 @@
static int shmem_getpage(struct inode * inode, unsigned long idx, struct page **ptr)
{
+ struct shmem_inode_info *info;
struct address_space * mapping = inode-i_mapping;
int error;
@@ -407,27 +411,28 @@
page_cache_release(*ptr);
}
- down (inode-i_sem);
- /* retest we may have slept */
+ info = inode-u.shmem_i;
+ down (info-sem);
+ /* retest we may have slept */
+
+ *ptr = ERR_PTR(-EFAULT);
if (inode-i_size (loff_t) idx * PAGE_CACHE_SIZE)
- goto sigbus;
- *ptr = shmem_getpage_locked(inode, idx);
+ goto failed;
+
+ *ptr = shmem_getpage_locked(inode-u.shmem_i, inode, idx);
if (IS_ERR (*ptr))
goto failed;
+
UnlockPage(*ptr);
- up (inode-i_sem);
+ up (info-sem);
return 0;
failed:
- up (inode-i_sem);
+ up (info-sem);
error = PTR_ERR(*ptr);
- *ptr = NOPAGE_OOM;
- if (error != -EFBIG)
- *ptr = NOPAGE_SIGBUS;
- return error;
-sigbus:
- up (inode-i_sem);
*ptr = NOPAGE_SIGBUS;
- return -EFAULT;
+ if (error == -ENOMEM)
+ *ptr = NOPAGE_OOM;
+ return error;
}
struct page * shmem_nopage(struct vm_area_struct * vma, unsigned long address, int
no_share)
@@ -500,6 +505,7 @@
struct inode *shmem_get_inode(struct super_block *sb, int mode, int dev)
{
struct inode * inode;
+ struct shmem_inode_info *info;
spin_lock (sb-u.shmem_sb.stat_lock);
if (!sb-u.shmem_sb.free_inodes) {
@@ -519,7 +525,9 @@
inode-i_rdev = NODEV;
inode-i_mapping-a_ops = shmem_aops;
inode-i_atime = inode-i_mtime = inode-i_ctime = CURRENT_TIME;
- spin_lock_init (inode-u.shmem_i.lock);
+ info = inode-u.shmem_i;
+ spin_lock_init (info-lock);
+ sema_init (info-sem, 1);
switch (mode S_IFMT) {
default:
Re: Is it useful to support user level drivers
At 23:50 +1000 2001-06-21, john slee wrote: i believe libgpio uses the existing usb/iee1394/serial/parallel interfaces to provide a limited userspace driver capability. That only means, however, that the specific kernel drivers explicitly support mid-level usermode access. They still handle the actual hardware state changes without usermode support. -- Matthias Urlichs - 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: Is it useful to support user level drivers
On Thu, Jun 21, 2001 at 03:58:33PM +0200, Matthias Urlichs wrote: At 23:50 +1000 2001-06-21, john slee wrote: i believe libgpio uses the existing usb/iee1394/serial/parallel interfaces to provide a limited userspace driver capability. That only means, however, that the specific kernel drivers explicitly support mid-level usermode access. They still handle the actual hardware state changes without usermode support. yes, that was the point. while it might be a stretch of the mechanism, not policy argument, i like having drivers organized this way. it makes a lot of sense for hotpluggable things like usb. j. -- Bobby, jiggle Grandpa's rat so it looks alive, please -- gary larson - 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: Alan Cox quote? (was: Re: accounting for threads)
Rob Landley [EMAIL PROTECTED]:
On Wednesday 20 June 2001 17:20, Albert D. Cahalan wrote:
Rob Landley writes:
My only real gripe with Linux's threads right now [...] is
that ps and top and such aren't thread aware and don't group them
right.
I'm told they added some kind of threadgroup field to processes
that allows top and ps and such to get the display right. I haven't
noticed any upgrades, and haven't had time to go hunting myself.
There was a threadgroup added just before the 2.4 release.
Linus said he'd remove it if he didn't get comments on how
useful it was, examples of usage, etc. So I figured I'd look at
the code that weekend, but the patch was removed before then!
Can we give him feedback now, asking him to put it back?
Submit patches to me, under the LGPL please. The FSF isn't likely
to care. What, did you think this was the GNU system or something?
I've stopped even TRYING to patch bash. try a for loop calling echo $$,
eery single process bash forks off has the PARENT'S value for $$, which is
REALLY annoying if you spend an afternoon writing code not knowing that and
then wonder why the various process's temp file sare stomping each other...
Actually - you have an error there. $$ gets evaluated during the parse, not
during execution of the subprocess. To get what you are describing it is
necessary to sh -c 'echo $$' to force the delay of evaluation. The only
bug interpretation is in the evaluation of the quotes. IF echo '$$'
delayed the interpretation of $$, then when the subprocess shell
echo $$ reparsed the line the $$ would be substituted as you wanted.
This delay can only be done via the sh -c ... method. (its the same with
bourne/korn shell).
Oh, and anybody who can explain this is welcome to try:
lines=`ls -l | awk '{print \$0\}'`
for i in $lines
do
echo line:$i
done
That depends on what you are trying to do. Are you trying to echo the
entire ls -l? or are you trying to convert an ls -l into a single
column based on a field extracted from ls -l.
If the latter, then the script should be:
ls -l | awk '{print $fieldno}' | while read i
do
echo line: $i
done
If the fields don't matter, but you want each line processed in the
loop do:
ls -l | while read i
do
echo line:$i
done
Bash doesn't need patching for this.
Again, the evaluation of the quotes is biting you. When the $lines
parameter is evaluated, the quotes are present.
bash is doing a double evaluation for for loop. It expects
a list of single tokens, rather than a list of quoted strings. This is
the same as in the bourne/korn shell.
If you want such elaborate handling of strings, I suggest using perl.
-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]
Any opinions expressed are solely my own.
-
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: The latest Microsoft FUD. This time from BillG, himself.
You can scream all you want that it isn't free software but the fact of the matter is that you all scream that and then go do your slides for your Linux talks in PowerPoint. I think this is an unfair generalization. Not really. In Linus's book he describes that his presentations used to be (and possibly still are?) done in powerpoint. In fact at one point he says thank god for Microsoft. Given the context, I'm not sure if he was joking or not. Not that it matters. I share Linus's opinion that it's not an issue of hating Microsoft. It's an issue of keeping your energies focused on progress because Microsoft will be irrelevant in the very near future. The momentum is on our side... -- Chuck Wolber| steward: Are you the pilot? System Administrator| pilot: Yes, why? AltaServ Corporation| steward, handing box to pilot: Then this is for you. (425)576-1202 | pilot, looking inside box: Oh, it's a new altimeter. ten.vresatla@wkcuhc | --Chris Kennedy - 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: wait_for_cmd_done timeout
Hi! On Wed, 20 Jun 2001 16:31:34 -0700 Dionysius Wilson Almeida Dionysius Wilson Almeida [EMAIL PROTECTED] wrote: Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout! Jun 20 16:14:38 debianlap last message repeated 5 times I saw the same message. The comment before wait_for_cmd_done() function in linux/drivers/net/eepro100.c says: /* How to wait for the command unit to accept a command. Typically this takes 0 ticks. */ And the initial value for the bogus counter, named wait, is 1000. Is it enough for your machine? I applied attached patch, eepro100.patch. After that, I've never seen the message from wait_for_cmd_done(). And, my NIC works fine. You may want to adjust the initial value for the bogus counter. I don't know the appropriate value for this bogus counter. I hope this helps you. -- Masaru Kawashima eepro100.patch
correction: fs/buffer.c underlocking async pages
Hi,
I ran into some problems with buffer.c trying to unlock a page of async io
buffer heads more
than once.
IMHO end_buffer_io_async() shouldn't rely on the value of b_end_io to
decide if the whole
page can be unlocked. It would make it easier for other layers (well
remappers like md or
lvm) to create an end_io chain without the need of allocating new buffer
heads just for that.
Is the comparision on b_end_io really necessary? I would assume that all
bh on the same
page belong to async io.
Otherwise, could something like below be done instead?
Linux for eServer development
[EMAIL PROTECTED]
Phone: +49 (7031) 16-2472
--
When all other means of communication fail, try words.
diff -ruN old/fs/buffer.c new/fs/buffer.c
--- old/fs/buffer.c Thu Jun 21 09:47:20 2001
+++ new/fs/buffer.c Thu Jun 21 10:44:01 2001
@@ -798,11 +798,12 @@
* that unlock the page..
*/
spin_lock_irqsave(page_uptodate_lock, flags);
+ clear_bit(BH_Async, bh-b_state);
unlock_buffer(bh);
atomic_dec(bh-b_count);
tmp = bh-b_this_page;
while (tmp != bh) {
- if (tmp-b_end_io == end_buffer_io_async
buffer_locked(tmp))
+ if (test_bit(BH_Async, tmp-b_state)
buffer_locked(tmp))
goto still_busy;
tmp = tmp-b_this_page;
}
@@ -834,6 +835,7 @@
void set_buffer_async_io(struct buffer_head *bh) {
bh-b_end_io = end_buffer_io_async ;
+ set_bit(BH_Async, bh-b_state);
}
/*
@@ -1535,6 +1537,7 @@
do {
lock_buffer(bh);
bh-b_end_io = end_buffer_io_async;
+ set_bit(BH_Async, bh-b_state);
atomic_inc(bh-b_count);
set_bit(BH_Uptodate, bh-b_state);
clear_bit(BH_Dirty, bh-b_state);
@@ -1736,6 +1739,7 @@
struct buffer_head * bh = arr[i];
lock_buffer(bh);
bh-b_end_io = end_buffer_io_async;
+ set_bit(BH_Async, bh-b_state);
atomic_inc(bh-b_count);
}
@@ -2182,6 +2186,7 @@
bh-b_blocknr = *(b++);
set_bit(BH_Mapped, bh-b_state);
bh-b_end_io = end_buffer_io_async;
+ set_bit(BH_Async, bh-b_state);
atomic_inc(bh-b_count);
bh = bh-b_this_page;
} while (bh != head);
diff -ruN old/include/linux/fs.h new/include/linux/fs.h
--- old/include/linux/fs.h Thu Jun 21 09:47:51 2001
+++ new/include/linux/fs.h Thu Jun 21 09:48:20 2001
@@ -207,6 +207,7 @@
#define BH_Mapped 4 /* 1 if the buffer has a disk mapping */
#define BH_New 5 /* 1 if the buffer is new and not yet
written out */
#define BH_Protected 6 /* 1 if the buffer is protected */
+#define BH_Async 7 /* 1 if the buffer is used for asyncronous io */
/*
* Try to keep the most commonly used fields in single cache lines (16
---
-
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: wait_for_cmd_done timeout
Dionysius Wilson Almeida Dionysius Wilson Almeida [EMAIL PROTECTED] wrote: Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout! Jun 20 16:14:38 debianlap last message repeated 5 times I saw the same message. The comment before wait_for_cmd_done() function in linux/drivers/net/eepro100.c says: /* How to wait for the command unit to accept a command. Typically this takes 0 ticks. */ And the initial value for the bogus counter, named wait, is 1000. Is it enough for your machine? I applied attached patch, eepro100.patch. After that, I've never seen the message from wait_for_cmd_done(). And, my NIC works fine. You may want to adjust the initial value for the bogus counter. I don't know the appropriate value for this bogus counter. int wait is set to 2 in my eepro100.c (stock 2.2.19), and I still get these errors. Think the patch with the udelay() will still work? John -- John Madden UNIX Systems Engineer Ivy Tech State College [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/
2.4.x deadlocking
Hi, My collegue has a Lifetec 9888 laptop (PII) that suffers from IRQ deadlocking : His TI PCMCIA bridge locates itself on IRQ 12, and so does his mouse. System boots fine, but as soon as he types anything or moves his mouse, the keyboard locks. 2.2.x doesn't seem to allocate a IRQ to the bridge, so no problems there. Remote access is still possible, and the system works fine excepts that his keyboard / mouse are dead :) Not starting GPM prevents the lock. Is there any way to tell the PCI subsystem to leave IRQ 12 alone ? The pci_setup() routine seems to be a pretty noop. Regards, Igmar Palsenberg -- Igmar Palsenberg JDI Media Solutions Boulevard Heuvelink 102 6828 KT Arnhem The Netherlands mailto: [EMAIL PROTECTED] PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar - 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: Is it useful to support user level drivers
On Thu, 21 Jun 2001, Oliver Neukum wrote: Lastly an IRQ kernel module can disable_irq() from interrupt handler and enable it again only on explicit acknowledge from user. Unless you need that interrupt to be enabled to deliver the signal or let Need not. Signal and other event delivery mechanisms has nothing common with disable/enable_irq(). userspace reenable the interrupt. user acknowledge is mean that. In addition, how do you handle shared interrupts ? It is impossible, see my another message. - 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: correction: fs/buffer.c underlocking async pages
On Thu, Jun 21, 2001 at 04:39:11PM +0200, [EMAIL PROTECTED] wrote:
Hi,
I ran into some problems with buffer.c trying to unlock a page of
sorry for the huge delay in the answer, I was going to answer your
previous two emails very shortly (I didn't forgotten ;).
async io buffer heads more than once. IMHO end_buffer_io_async()
shouldn't rely on the value of b_end_io to decide if the whole page
can be unlocked. It would make it easier for other layers (well
remappers like md or lvm) to create an end_io chain without the need
of allocating new buffer heads just for that. Is the comparision on
It seems we can more simply drop the tmp-b_end_io == end_buffer_io_async
check enterely and safely. Possibly we could build a debugging logic to
make sure nobody ever lock down a buffer mapped on a pagecache that is
under async I/O (which in realty is sync I/O, you know the async/sync
names of the kernel io callbacks are the opposite of realty ;).
The reason it seems safe to me is that when a pagecache is under async
I/O (async in kernel terms) it says locked all the time until the last
call of the async I/O callback, and _nobody_ is ever allowed to mess
with the anon bh overlapped on the pagecache while the page stays locked
down. As far as the async end_io callback is recalled it means the page
is still locked down so we know if the end_io callback points to
something else it's because of a underlying remapper, nobody else would
be allowed to play the bh of a page locked down.
so in short:
--- 2.4.6pre5aa1/fs/buffer.c.~1~Thu Jun 21 16:22:40 2001
+++ 2.4.6pre5aa1/fs/buffer.cThu Jun 21 17:05:18 2001
@@ -850,7 +850,7 @@
atomic_dec(bh-b_count);
tmp = bh-b_this_page;
while (tmp != bh) {
- if (tmp-b_end_io == end_buffer_io_async buffer_locked(tmp))
+ if (buffer_locked(tmp))
goto still_busy;
tmp = tmp-b_this_page;
}
can anybody see a problem in the above patch? Al, Ingo, Linus?
Andrea
-
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: correction: fs/buffer.c underlocking async pages
On Thursday, June 21, 2001 05:08:13 PM +0200 Andrea Arcangeli [EMAIL PROTECTED] wrote: It seems we can more simply drop the tmp-b_end_io == end_buffer_io_async check enterely and safely. Possibly we could build a debugging logic to make sure nobody ever lock down a buffer mapped on a pagecache that is under async I/O (which in realty is sync I/O, you know the async/sync names of the kernel io callbacks are the opposite of realty ;). The reason it seems safe to me is that when a pagecache is under async I/O (async in kernel terms) it says locked all the time until the last call of the async I/O callback, and _nobody_ is ever allowed to mess with the anon bh overlapped on the pagecache while the page stays locked down. As far as the async end_io callback is recalled it means the page is still locked down so we know if the end_io callback points to something else it's because of a underlying remapper, nobody else would be allowed to play the bh of a page locked down. Think of a mixture of fsync_inode_buffers and async i/o on page. Since fsync_inode_buffers uses ll_rw_block, if that end_io handler is the last to run the page never gets unlocked. -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/
Re: Is it useful to support user level drivers
On Thursday, 21. June 2001 16:46, Dmitry A. Fedorov wrote: On Thu, 21 Jun 2001, Oliver Neukum wrote: Lastly an IRQ kernel module can disable_irq() from interrupt handler and enable it again only on explicit acknowledge from user. Unless you need that interrupt to be enabled to deliver the signal or let Need not. Signal and other event delivery mechanisms has nothing common with disable/enable_irq(). And how do you ensure that no interrupt is lost ? In fact you now are likely to have a race condition reading device status or the like. userspace reenable the interrupt. user acknowledge is mean that. In addition, how do you handle shared interrupts ? It is impossible, see my another message. Which IMHO makes the concept pretty much useless. Interrupt sharing is pretty much the norm today. And there is no evidence for this to change in the near future. Rather the opposite seems to happen in fact. Which devices were you thinking of, that need a hardware IRQ and no kernel driver ? Regards Oliver - 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: correction: fs/buffer.c underlocking async pages
On Thu, Jun 21, 2001 at 11:16:42AM -0400, Chris Mason wrote: Think of a mixture of fsync_inode_buffers and async i/o on page. Since fsync_inode_buffers uses ll_rw_block, if that end_io handler is the last to run the page never gets unlocked. correct Andrea - 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: The latest Microsoft FUD
All, Wouldn't microsoft be happy to see so many linux developers and extraordinaries while away their time on a trivial issue instead of coming up with other befitting replies. Not to mention, it reduces the SNR of kernel list pretty much. We all _love_ linux and let's focus on that. best of luck __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.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: correction: fs/buffer.c underlocking async pages
On Thu, Jun 21, 2001 at 04:39:11PM +0200, [EMAIL PROTECTED] wrote:
diff -ruN old/fs/buffer.c new/fs/buffer.c
--- old/fs/buffer.c Thu Jun 21 09:47:20 2001
+++ new/fs/buffer.c Thu Jun 21 10:44:01 2001
@@ -798,11 +798,12 @@
* that unlock the page..
*/
spin_lock_irqsave(page_uptodate_lock, flags);
+ clear_bit(BH_Async, bh-b_state);
unlock_buffer(bh);
atomic_dec(bh-b_count);
tmp = bh-b_this_page;
while (tmp != bh) {
- if (tmp-b_end_io == end_buffer_io_async
buffer_locked(tmp))
+ if (test_bit(BH_Async, tmp-b_state)
buffer_locked(tmp))
goto still_busy;
tmp = tmp-b_this_page;
}
@@ -834,6 +835,7 @@
void set_buffer_async_io(struct buffer_head *bh) {
bh-b_end_io = end_buffer_io_async ;
+ set_bit(BH_Async, bh-b_state);
}
/*
@@ -1535,6 +1537,7 @@
do {
lock_buffer(bh);
bh-b_end_io = end_buffer_io_async;
+ set_bit(BH_Async, bh-b_state);
atomic_inc(bh-b_count);
set_bit(BH_Uptodate, bh-b_state);
clear_bit(BH_Dirty, bh-b_state);
@@ -1736,6 +1739,7 @@
struct buffer_head * bh = arr[i];
lock_buffer(bh);
bh-b_end_io = end_buffer_io_async;
+ set_bit(BH_Async, bh-b_state);
atomic_inc(bh-b_count);
}
@@ -2182,6 +2186,7 @@
bh-b_blocknr = *(b++);
set_bit(BH_Mapped, bh-b_state);
bh-b_end_io = end_buffer_io_async;
+ set_bit(BH_Async, bh-b_state);
atomic_inc(bh-b_count);
bh = bh-b_this_page;
} while (bh != head);
diff -ruN old/include/linux/fs.h new/include/linux/fs.h
--- old/include/linux/fs.h Thu Jun 21 09:47:51 2001
+++ new/include/linux/fs.h Thu Jun 21 09:48:20 2001
@@ -207,6 +207,7 @@
#define BH_Mapped 4 /* 1 if the buffer has a disk mapping */
#define BH_New 5 /* 1 if the buffer is new and not yet
written out */
#define BH_Protected 6 /* 1 if the buffer is protected */
+#define BH_Async 7 /* 1 if the buffer is used for asyncronous io */
/*
* Try to keep the most commonly used fields in single cache lines (16
I think the patch is ok. We must have a way to track down which bh are
actually getting read, the others could be just uptodate and dirty and
waiting kupdate to flush them under us (and we cannot defer the unlock
of the page due those locked buffers under flush write-I/O or we
deadlock).
Andrea
-
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: temperature standard - global config option?
On Thu, Jun 21, 2001 at 12:18:12PM +0100, Jonathan Morton wrote: I've been taught by every Maths, Engineering and Physics teacher/lecturer I've encountered to write down significant figures consistent with the precision of the value. So blindly writing down a value of 59.42886726469 ±2°C is obviously ludicrous, even if that's what my calculator gives me. I should instead write 59 ±2°C, since that is the most precision I can possibly know it to. With some advanced measuring techniques it *may* be acceptable to write 59.43 ±2°C *at most*, and then only if you really know why you need the extra information. What they teached me in school is about the same. But the rule for the precision was to use two signicifant(?) decimals. So you end up with 59.4 ± 2.0 °C or something. Also note that you have to round up the precision, so it couldn't have been 2.01, but could have been 1.01 the way you wrote it. Kurt - 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: One more ZDNet article with BillG hammering Linux and OpenSource.
simple source access. I don't know that anyone has ever asked for the source code for Word. If they did, we would give it to them. But it's not a typical request. So who wants to go ask for the source code to word then? I mean we have Bill's word that they will give it to us. Brent Norris Executive Advisor -- WKU-Linux - 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: spindown
Pavel Machek wrote: Isn't this why noflushd exists or is this an evil thing that shouldn't ever be used and will eventually eat my disks for breakfast? It would eat your flash for breakfast. You know, flash memories have no spinning parts, so there's nothing to spin down. Btw Pavel, does noflushd work with 2.4.4? The noflushd version 2.4 I tried said it couldn't find some kernel process (kflushd? I don't remember) and that I should use bdflush. The manual says that's appropriate for older kernels, but not 2.4.4 surely. -- Jamie - 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: wait_for_cmd_done timeout
Hi, again!
I'ts me, Masaru Kawashima, from home.
I'm sorry I made a stupid mistake last time!
This time, I promise you that I attach the proper patch for
linux/drivers/net/eepro100.c. (running version)
On Thu, 21 Jun 2001 23:19:39 +0900
Masaru Kawashima Masaru Kawashima [EMAIL PROTECTED] wrote:
Hi!
On Wed, 20 Jun 2001 16:31:34 -0700
Dionysius Wilson Almeida Dionysius Wilson Almeida [EMAIL PROTECTED]
wrote:
Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
Jun 20 16:14:38 debianlap last message repeated 5 times
I saw the same message.
The comment before wait_for_cmd_done() function in
linux/drivers/net/eepro100.c says:
/* How to wait for the command unit to accept a command.
Typically this takes 0 ticks. */
And the initial value for the bogus counter, named wait, is 1000.
Is it enough for your machine?
I applied attached patch, eepro100.patch. After that, I've never seen
the message from wait_for_cmd_done(). And, my NIC works fine.
You may want to adjust the initial value for the bogus counter.
I don't know the appropriate value for this bogus counter.
I hope this helps you.
--
Masaru Kawashima
--
Masaru Kawashima
--- linux-2.4.5/drivers/net/eepro100.c.org Fri May 25 18:59:03 2001
+++ linux-2.4.5/drivers/net/eepro100.c Fri Jun 22 00:55:03 2001
@@ -309,8 +309,9 @@
static inline void wait_for_cmd_done(long cmd_ioaddr)
{
int wait = 1000;
- do ;
- while(inb(cmd_ioaddr) --wait = 0);
+ while(inb(cmd_ioaddr) --wait = 0){
+ udelay(1);
+ }
#ifndef final_version
if (wait 0)
printk(KERN_ALERT eepro100: wait_for_cmd_done timeout!\n);
Re: Is it useful to support user level drivers
Dmitry A. Fedorov wrote: On Thu, 21 Jun 2001, Oliver Neukum wrote: Lastly an IRQ kernel module can disable_irq() from interrupt handler and enable it again only on explicit acknowledge from user. Unless you need that interrupt to be enabled to deliver the signal or let Need not. Signal and other event delivery mechanisms has nothing common with disable/enable_irq(). userspace reenable the interrupt. user acknowledge is mean that. In addition, how do you handle shared interrupts ? It is impossible, see my another message. I don't see why you think it's impossible, the only thing you need is that your kernel module know how to discriminate the interrupt source. You can do this also with a irq.o module and other tiny modules that register their irq source detection code. Then you have /dev/irqX with the following API: - ioctl(fd, IRQ_SUBSCRIBE, source_id); - ioctl(fd, IRQ_ACK, source_id); - poll - async notification Interrupts received between notification and acknowledge are queued (i.e. counted). An alternative to queuing (user selectable) is to block interrupt generation at hardware level in kernel space immediately before notification. I'm missing something? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - 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-ac17
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
2.4.5-ac17
o Sanity check the BIOS tables for bootflag (me)
o Update multicast support by devices doc (Ralf Baechle)
o Fix iohi=0 option in parport(Tim Waugh)
o First set of ipt_unclean fixes (Rusty Russell)
o Add YUV420P to the pwc driver ('Nemosoft')
| This is the compromise - its simply an unpacking order option
| not RGB/YUV
o Swapfile bugfix (Rik van Riel)
o Allow readahead to be tuned for big arrays (Craig Hagan)
o Add PIRQ router support for the AMD756 (Jhon Caicedo)
o Fix bootflag bitmasks (Dave Jones)
o Fix lseek limit handling(Martin Frey)
o The joystick/gameport symbol game continued (Keith Owens)
o Update i810 tco driver to know about 815,820 .. (Andrey Panin)
o Fix missing allocation failure checks in
drm, mtd, aironet, skfp, scsi, irda (Chip Turner)
o Further lvm updates (Joe Thornber)
| Fixes VG_CREATE_OLD problem
2.4.5-ac16
o Drop the shmem/removepage changes to see if they(me)
are cuaisng the instabilities in ac15
o Fix bug in pci_init_module causing serial crash (me)
| Figured out by Niels Jensen
o Alpha build fixes for keyboard change (Jay Thorne)
o Tidy up imsttfb driver (Paul Mundt)
o Fix tdfxfb warning (Steven Walter)
o Fix fat fs build on ARM (Russell King)
o Fix catc help text (Brad Hards)
o Fix missing unlock_kernel in fs/locks.c (Andrey Savochkin)
o Minixfs alloc_branch fixes (Al Viro)
o Support bootflag extension (me)
| Experimental
o Add EMC Symmetrix to the sparselun list (Alar Aun)
o Update the ioc3 ethernet(Ralf Baechle)
o Add ataraid to the known root names (Arjan van de Ven)
o Further Sony Pi driver upgrades (Stelian Pop)
o Add geometry queries to the ataraid driver (Arjan van de Ven)
o Add ALi IRDA FIR support(Benjamin Kong)
o Fix gameport compile failures (Keith Owens)
o Fixes IrLMP states stuck in CONN_PEND state (Jean Tourrilhes)
o Small cris config fixes (Andrzej Krzysztofowicz)
o Fix some potential irlan bugs/stack abuse (Ted Unangst)
o Fix OSS API bug in USB audio(Bruce Nesbitt)
o Update the MIPS64 core (Ralf Baechle,
Thiemo Seurer, and others)
o Update the MIPS32 core (Ralf Baechle, Kevin Kissell,
Carsten Langgaard, Justin Carlson,
Jun Sun)
o Add a driver for the AU1000 ethernet(P Popov)
o Fix security problems with i810 and MGA drm (Jeff Hartmann)
o Use a saner computation for maxthreads (Rik van Riel)
o Update matroxfb, support G100 SGRAM (Petr Vandrovec)
o Fix hang in scsi generic with cdrdao(Doug Gilbert)
o Correct aha152x abort fix (Jüergen E. Fischer)
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
loop device broken in 2.4.6-pre5
File backed loop device on 4k block size ext2 filesystem: debian:/root # dd if=/dev/zero of=file1 bs=1024 count=10 10+0 records in 10+0 records out debian:/root # losetup /dev/loop0 file1 debian:/root # dd if=/dev/zero of=/dev/loop0 bs=1024 count=10 conv=notrunc dd: /dev/loop0: No space left on device =ERROR= 9+0 records in 8+0 records out debian:/root # tune2fs -l /dev/hda1 21| grep Block size Block size: 4096 debian:/root # uname -a Linux debian 2.4.6-pre5 #1 Thu Jun 21 14:27:25 EEST 2001 i686 unknown Stock 2.4.5 and 2.4.5-ac15 don't have this problem. Regards, Jari Ruusu [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: One more ZDNet article with BillG hammering Linux and Open Source.
simple source access. I don't know that anyone has ever asked for the source code for Word. If they did, we would give it to them. But it's not a typical request. So who wants to go ask for the source code to word then? I mean we have Bill's word that they will give it to us. If we go and do it, this will be automatically tagged as a typical annoying request of an lkml subscriber. He only speaks about non-typical request. :) - 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: correction: fs/buffer.c underlocking async pages
On Thu, 21 Jun 2001, Andrea Arcangeli wrote:
It seems we can more simply drop the tmp-b_end_io == end_buffer_io_async
check enterely and safely.
I doubt it.
Think about somebody who writes a partial page (but a full buffer).
Somebody _else_ then reads the rest of the page. You'll have one buffer
up-to-date (but possibly under write-back IO), and the others being read
in asynchronously.
+++ 2.4.6pre5aa1/fs/buffer.c Thu Jun 21 17:05:18 2001
@@ -850,7 +850,7 @@
atomic_dec(bh-b_count);
tmp = bh-b_this_page;
while (tmp != bh) {
- if (tmp-b_end_io == end_buffer_io_async buffer_locked(tmp))
+ if (buffer_locked(tmp))
goto still_busy;
tmp = tmp-b_this_page;
}
can anybody see a problem in the above patch? Al, Ingo, Linus?
The above _will_ break. tmp may be locked due to the write - and the
write will never call end_buffer_io_async because writes do not unlock
the page. So if the write finishes last, you'll _never_ unlock the page.
I don't see why Stefan wants to change the current logic. The current
logic is correct, and if there are double-unlock problems then those are
due to some other bug.
Linus
-
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: temperature standard - global config option?
Richard J Moore wrote: 59.42886726469 ±2°C is obviously ludicrous, even if that's what my calculator gives me. I should instead write 59 ±2°C, since So, if I follow you argument then shouldn't you be writing 58 ±2°C or should it be 60 ±2°C ? What it means is that whatever dingus measured the temperature, reported the temperature as 59C. Also it is known that the accuracy of said dingus is +-2C, so the real temperature can be anywhere between 57C and 61C. That assuming that the dingus is calibrated. -- [EMAIL PROTECTED] * Man created god as His image * * Man has horrid imagination * - 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-ac17
On Thu, 21 Jun 2001, Alan Cox wrote: 2.4.5-ac17 o Swapfile bugfix (Rik van Riel) Written by Stephen Tweedie ... 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: RPC vs Socket
== Blesson Paul [EMAIL PROTECTED] writes: hi all I am in the way of building a new remote file system. Presently I decided to use sockets for remote communication. Lately I understood that RPC is used in coda and nfs file systems(is it so). I want to know the fessibility in using RPC in the new file system. Should be no problem. The RPC layer is not tied to any particular filesystem. On the client, you need to set up struct rpc_procinfo with the necessary RPC XDR routines, which you then declare to the RPC layer using a struct rpc_program and a call to rpc_create_client(). See for instance linux/fs/lockd/mon.c, or linux/fs/nfs/mount_clnt.c... For the server, things are likely to be a bit more complex in that you need to declare the routines using structs svc_program, svc_version and rpc_procinfo (again) and then set up a daemon process. Examples of use include linux/fs/lockd/svc.c and linux/fs/nfsd/nfssvc.c... Cheers, Trond - 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: correction: fs/buffer.c underlocking async pages
On Thu, Jun 21, 2001 at 09:54:47AM -0700, Linus Torvalds wrote: The above _will_ break. tmp may be locked due to the write - and the indeed, I missed the pending writes sorry. Andrea - 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: needed this to run 2.4.6-pre4
Jeff Chua wrote: still not in 2.4.6-pre4. Without this, you'll get a lot of undefined symbols referencing do_softirq it's already in pre5... -- 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: correction: fs/buffer.c underlocking async pages
On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote: What's the problem with the existing code, and why do people want to add a (unnecessary) new bit? there's no problem with the existing code, what I understood is that they cannot overwrite the -b_end_io callback in the lowlevel blkdev layer or the page will be unlocked too early. Andrea - 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: The latest Microsoft FUD. This time from BillG, himself.
On 21 Jun 2001 15:48:11 +0200, Daniel Phillips wrote: On Thursday 21 June 2001 10:46, Henning P. Schmiedehausen wrote: My last LinuxExpo talk was also made with PP, This makes about as much sense as going to a cocktail party with nose glasses on. One of the mantras that get hammered into Microsoft employees is Eat your own dogfood. Which means that people working at Microsoft should attempt to use the company's products throughout the day in order to surface problems and give incentive to those folks to make things better. Obviously, the EYODF work doesn't kick in until there is some minimal level of functionality. It may be that Linux/OSS office applications simply aren't useful enough yet for anyone to stomach using them throughout the day. It would be nice to see more Linux folks eating the dogfood and making those applications better, though. For my part, I test Enlightenment, Gnome, XFree86 and Mozilla, in addition to Linux kernels. Miles - 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/
more gendisk stuff
An hour ago or so I put 07-2.4.6pre5-gendisk on ftp.kernel.org (and rediffed the previous six patches against 2.4.6pre5). It has add_gendisk, del_gendisk, get_gendisk, blk_gendisk[] (a.k.a. register_gendisk, unregister_gendisk, find_gendisk), so that one now can find the gendisk structure given a kdev_t. Interestingly, there were complaints several places in the source about the lack of these, but none of the complainers added them. Al, I don't know whether you are interested in this stuff, but comments (other than: the stuff is full of races) are welcome. Andries - 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/
Problem with patch 2.4.6pre5
Hello, After applying this patch, I suddenly got flooded by iptables with tonnes of messages being flagged as TAINTED by my firewall. I previously ran 2.4.6pre3 with no problems whatsoever, so I think the additional network driver updates might have caused a problem? I'm using a 3c905b if that helps any. Sorry if this has already been reported, I hadn't been subscribed before and I didn't see any archives that I know of up-to-date to see if it had. If you could, please cc me and let me know if it's truly a kernel problem, or I just have something configured wrong that is only now showing up. Thanks, Troy Edwards - 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-ac17
On Thu, Jun 21, 2001 at 05:38:56PM +0100, Alan Cox wrote: [snip] 2.4.5-ac17 [snip] Hi Alan Sorry to bug you but could you tell us what's up with the synchronisation between your tree and Linus' please? I haven't seen any ac stuff being spooled into Linus' tree for a while and the trees seem to be drifting further apart ... it would be nice if there wasn't much difference other than the device name and the page cache VFS stuff. I know you're both hectically busy but it would be nice to know that the plan is not to let things drift too far apart. It's getting tricky to decide which tree to dabble with! Thank you! --Craig - 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: correction: fs/buffer.c underlocking async pages
On Thu, Jun 21, 2001 at 07:15:22PM +0200, Andrea Arcangeli wrote:
On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
What's the problem with the existing code, and why do people want to add a
(unnecessary) new bit?
there's no problem with the existing code, what I understood is that
they cannot overwrite the -b_end_io callback in the lowlevel blkdev
layer or the page will be unlocked too early.
I rediffed it a bit so the buffer_async and buffer_locked check can get
merged in a single asm instruction by gcc and cleaned up the
set_buffer_async_io logic a bit inside buffer.c:
--- bh-async/fs/buffer.c.~1~Thu Jun 21 08:03:49 2001
+++ bh-async/fs/buffer.cThu Jun 21 18:13:46 2001
@@ -806,11 +806,12 @@
* that unlock the page..
*/
spin_lock_irqsave(page_uptodate_lock, flags);
+ mark_buffer_async(bh, 0);
unlock_buffer(bh);
atomic_dec(bh-b_count);
tmp = bh-b_this_page;
while (tmp != bh) {
- if (tmp-b_end_io == end_buffer_io_async buffer_locked(tmp))
+ if (buffer_async(tmp) buffer_locked(tmp))
goto still_busy;
tmp = tmp-b_this_page;
}
@@ -840,8 +841,9 @@
return;
}
-void set_buffer_async_io(struct buffer_head *bh) {
+inline void set_buffer_async_io(struct buffer_head *bh) {
bh-b_end_io = end_buffer_io_async ;
+mark_buffer_async(bh, 1);
}
/*
@@ -1531,7 +1533,7 @@
/* Stage 2: lock the buffers, mark them clean */
do {
lock_buffer(bh);
- bh-b_end_io = end_buffer_io_async;
+ set_buffer_async_io(bh);
atomic_inc(bh-b_count);
set_bit(BH_Uptodate, bh-b_state);
clear_bit(BH_Dirty, bh-b_state);
@@ -1732,7 +1734,7 @@
for (i = 0; i nr; i++) {
struct buffer_head * bh = arr[i];
lock_buffer(bh);
- bh-b_end_io = end_buffer_io_async;
+ set_buffer_async_io(bh);
atomic_inc(bh-b_count);
}
@@ -2178,7 +2180,7 @@
lock_buffer(bh);
bh-b_blocknr = *(b++);
set_bit(BH_Mapped, bh-b_state);
- bh-b_end_io = end_buffer_io_async;
+ set_buffer_async_io(bh);
atomic_inc(bh-b_count);
bh = bh-b_this_page;
} while (bh != head);
--- bh-async/include/linux/fs.h.~1~ Thu Jun 21 08:03:56 2001
+++ bh-async/include/linux/fs.h Thu Jun 21 18:10:38 2001
@@ -215,6 +215,7 @@
BH_Mapped, /* 1 if the buffer has a disk mapping */
BH_New, /* 1 if the buffer is new and not yet written out */
BH_Protected, /* 1 if the buffer is protected */
+ BH_Async, /* 1 if the buffer is under end_buffer_io_async I/O */
BH_PrivateStart,/* not a state bit, but the first bit available
* for private allocation by other entities
@@ -275,6 +276,7 @@
#define buffer_mapped(bh) __buffer_state(bh,Mapped)
#define buffer_new(bh) __buffer_state(bh,New)
#define buffer_protected(bh) __buffer_state(bh,Protected)
+#define buffer_async(bh) __buffer_state(bh,Async)
#define bh_offset(bh) ((unsigned long)(bh)-b_data ~PAGE_MASK)
@@ -1109,6 +,14 @@
extern void FASTCALL(mark_buffer_dirty(struct buffer_head *bh));
#define atomic_set_buffer_dirty(bh) test_and_set_bit(BH_Dirty, (bh)-b_state)
+
+static inline void mark_buffer_async(struct buffer_head * bh, int on)
+{
+ if (on)
+ set_bit(BH_Async, bh-b_state);
+ else
+ clear_bit(BH_Async, bh-b_state);
+}
/*
* If an error happens during the make_request, this function
This way looks more robust to me.
However I want to add a very fat warning about not allocating a new bh:
never assume b_private and b_end_io and possibly otheres weren't remapped
by another logical layer before you or the stacking will break badly, we
want everything to remains transparent so we can stack multiple layers
one on the top of the other.
Andrea
-
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] Threads, inelegance, and Java
Rob Landley [EMAIL PROTECTED] writes: However, the very concept of Java encourages not caring about performance, system-design or any elegance whatsoever. The same arguments were made 30 years ago about writing the OS in a high level language like C rather than in raw assembly. 30 years ago we didn't have C compilers that produce better code than you can write by hand. ;) -- Adam Sampson [EMAIL PROTECTED] URL:http://azz.us-lot.org/ - 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/
Controversy over dynamic linking -- how to end the panic
As you know, there's been another flap recently about the GPL status of loadable kernel modules. You have a note that touches on this in the kernel COPYING file, but it is not sufficient to resolve the questions that keep coming up. Earlier today I was contacted by a principal at a well-known Linux company who was in a mild panic over recent arguments by Alan Cox and David Miller. This company (not VA or Red Hat, BTW) fears that their customers will run from Linux if they get the idea that linking drivers to the kernel might force them open. I wrote back as follows: Alan's posting beginning Linus opinion on this is irrelevant is not a `perspective' that he can be argued out of. He is not arguing about whether allowing proprietary binary modules is good, bad, or indifferent. Alan is merely stating legal facts as he understands them -- and, in fact, I agree with his assessment. The key question is whether the particular kind of linking involved with loading binary modules propagates derivative-work status under copyright law. This is a legal question a court may rule on someday. Until one does, anyone who relies on such linking is taking a legal risk. Alan is not quite right that Linus's opinion is irrelevant. It is irrelevant to the underlying legal question, but not to the associated business risk. As copyright holder of the Linux kernel, Linus is the only person with standing to sue for license violation. Therefore, when he says binary modules are OK, he is stating a policy intention which your customers may include in their evaluation of legal risk. This means that in order for them to lose, a court must rule that module linking propagates derivative-work status *and* Linus must reverse himself and sue. So I'm proposing a solution. We can't resolve the underlying legal question yet, but you can make your policy clearer. In the existing kernel COPYING file: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. I suggest replacing this with something resembling the following: The GPL license reproduced below is copyrighted by the Free Software Foundation, but the Linux kernel is copyrighted by me and others who actually wrote it. The GPL license requires that derivative works of the Linux kernel also fall under GPL terms, including the requirement to disclose source. The meaning of derivative work has been well established for traditional media, and those precedents can be applied to inclusion of source code in a straightforward way. But as of mid-2001, neither case nor statute law has yet settled under what circumstances *binary* linkage of code to a kernel makes that code a derivative work of the kernel. To calm down the lawyers, I as the principal kernel maintainer and anthology copyright holder on the code am therefore adding the following interpretations to the kernel license: 1. Userland programs which request kernel services via normal system calls *are not* to be considered derivative works of the kernel. 2. A driver or other kernel component which is statically linked to the kernel *is* to be considered a derivative work. 3. A kernel module loaded at runtime, after kernel build, *is not* to be considered a derivative work. These terms are to be considered part of the kernel license, applying to all code included in the kernel distribution. They define your rights to use the code in *this* distribution, however any future court may rule on the underlying legal question and regardless of how the license or interpretations attached to future distributions may change. I believe this would express the present policy clearly enough to soothe jittery nerves at a lot of companies that are worried about this issue. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Government: If you refuse to pay unjust taxes, your property will be confiscated. If you attempt to defend your property, you will be arrested. If you resist arrest, you will be clubbed. If you defend yourself against clubbing, you will be shot dead. These procedures are known as the Rule of Law. -- Edward Abbey - 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: correction: fs/buffer.c underlocking async pages
On Thursday, June 21, 2001 07:15:22 PM +0200 Andrea Arcangeli
[EMAIL PROTECTED] wrote:
On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
What's the problem with the existing code, and why do people want to add
a
(unnecessary) new bit?
there's no problem with the existing code, what I understood is that
they cannot overwrite the -b_end_io callback in the lowlevel blkdev
layer or the page will be unlocked too early.
Just to be more explicit, the big problem is mixing different async
callbacks on the same page. The patch would also allow things like this:
fs_specific_end_io() {
do something special
end_buffer_io_async()
}
-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/
Re: Loop encryption module locking bug (linux-2.4.5).
Ingo Rohloff writes: PS: Because I try to understand the inner workings of the loop device better, I have a question: In lo_send is a loop: while (len0). How can I configure a loop device, so that this loop is executed more than once. It seems this is only possible if bh-b_size is greater than PAGE_CACHE_SIZE. Does this mean, you have to work on a filesystem which uses blocks of a size PAGE_CACHE_SIZE, or is bh-b_size a fixed value (which is always less than PAGE_CACHE_SIZE) ? Currently, filesystems must have block size = PAGE_CACHE_SIZE. This may not be true in the future, so it is likely that the loop code is forward looking to try to still work if the block size can exceed the PAGE_CACHE_SIZE. Cheers, Andreas -- Andreas Dilger \ If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry? http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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/
[RFC][PATCH] cutting up struct kernel_stat into cpu_stat
The attached patch-in-progress removes the per-cpu statistics from
struct kernel_stat and puts them in a cpu_stat structure, one per cpu,
cacheline padded. The data is still coolated and presented through
/proc/stat, but another file /proc/cpustat is also added. The locking
is as nonexistant as it was with kernel_stat, but who cares, they're
just fuzzy stats to be eyeballed by system tuners :).
A tool for printing the cpu stats specifically can be found near:
http://www.osdlab.org/sw_resources/cpustat/index.shtml
Its output is almost identical to solaris' mpstat.
I'm not sure I like the macro use, but it shields the callers from the
union garbage. We can easily also make a THIS_CPU_STAT_ADD() interface,
as some have hinted would be nice :)
Currently its mostly ( :) ) only collecting the stats that were
collected in kernel_stat. I'd like to add more stats -- page faults,
syscalls, cross-cpu calls, etc. I understand people not wanting more
live cachelines in the fast paths. I can make CPU_CRITICAL_STAT defines
that are config-ed out..
comments? If its ok I can whip up a patch that updates all the ports
use of -irqs[] as well.
- z
[ heading out for lunch :) ]
--- linux-2.4.5-cpustat/fs/proc/proc_misc.c.cpustat Fri Apr 13 20:26:07 2001
+++ linux-2.4.5-cpustat/fs/proc/proc_misc.c Thu Jun 21 12:23:49 2001
@@ -265,32 +265,36 @@
int i, len;
extern unsigned long total_forks;
unsigned long jif = jiffies;
- unsigned int sum = 0, user = 0, nice = 0, system = 0;
+ unsigned int sum = 0, user = 0, nice = 0, system = 0, ctxt = 0;
int major, disk;
for (i = 0 ; i smp_num_cpus; i++) {
int cpu = cpu_logical_map(i), j;
- user += kstat.per_cpu_user[cpu];
- nice += kstat.per_cpu_nice[cpu];
- system += kstat.per_cpu_system[cpu];
+ user += CPU_STAT_VAL(cpu, user);
+ nice += CPU_STAT_VAL(cpu, nice);
+ system += CPU_STAT_VAL(cpu, system);
+ ctxt += CPU_STAT_VAL(cpu, context_swtch);
#if !defined(CONFIG_ARCH_S390)
for (j = 0 ; j NR_IRQS ; j++)
- sum += kstat.irqs[cpu][j];
+ sum += CPU_STAT_VAL(cpu, irqs[j]);
#endif
}
len = sprintf(page, cpu %u %u %u %lu\n, user, nice, system,
jif * smp_num_cpus - (user + nice + system));
- for (i = 0 ; i smp_num_cpus; i++)
+ for (i = 0 ; i smp_num_cpus; i++) {
+ unsigned int user_i, nice_i, system_i;
+
+ user_i = CPU_STAT_VAL(cpu_logical_map(i), user);
+ nice_i = CPU_STAT_VAL(cpu_logical_map(i), nice);
+ system_i = CPU_STAT_VAL(cpu_logical_map(i), system);
+
len += sprintf(page + len, cpu%d %u %u %u %lu\n,
i,
- kstat.per_cpu_user[cpu_logical_map(i)],
- kstat.per_cpu_nice[cpu_logical_map(i)],
- kstat.per_cpu_system[cpu_logical_map(i)],
- jif - ( kstat.per_cpu_user[cpu_logical_map(i)] \
- + kstat.per_cpu_nice[cpu_logical_map(i)] \
- + kstat.per_cpu_system[cpu_logical_map(i)]));
+ user_i, nice_i, system_i,
+ jif - ( user_i + nice_i + system_i ) );
+ }
len += sprintf(page + len,
page %u %u\n
swap %u %u\n
@@ -330,13 +334,58 @@
\nctxt %u\n
btime %lu\n
processes %lu\n,
- kstat.context_swtch,
+ ctxt,
xtime.tv_sec - jif / HZ,
total_forks);
return proc_calc_metrics(page, start, off, count, eof, len);
}
+static int cstat_read_proc(char *page, char **start, off_t off,
+int count, int *eof, void *data)
+{
+ int i, len;
+
+ len = sprintf(page, cpu_stat 0.0\n);
+
+ for (i = 0 ; i smp_num_cpus; i++) {
+ unsigned int user, nice, system;
+ int j, cpu = cpu_logical_map(i);
+
+#if !defined(CONFIG_ARCH_S390)
+ len += sprintf(page + len, cpu%d irqs , cpu);
+ for (j = 0 ; j NR_IRQS ; j++) {
+ len += sprintf(page + len, %u,
+ CPU_STAT_VAL(cpu, irqs[j]));
+ }
+ len += sprintf(page + len, \n);
+#endif
+#if defined(CONFIG_SMP)
+ len += sprintf(page + len, cpu%d context_migration %u\n,
+ cpu, CPU_STAT_VAL(cpu, context_migration));
+#endif
+ len += sprintf(page + len, cpu%d bottom_halves %u\n,
+ cpu, CPU_STAT_VAL(cpu, bh));
+ len += sprintf(page + len, cpu%d context_switches %u\n,
+ cpu, CPU_STAT_VAL(cpu, context_swtch));
+
+ user =
Re: Controversy over dynamic linking -- how to end the panic
Eric S. Raymond wrote: The GPL license reproduced below is copyrighted by the Free Software Foundation, but the Linux kernel is copyrighted by me and others who actually wrote it. The GPL license requires that derivative works of the Linux kernel also fall under GPL terms, including the requirement to disclose source. The meaning of derivative work has been well established for traditional media, and those precedents can be applied to inclusion of source code in a straightforward way. But as of mid-2001, neither case nor statute law has yet settled under what circumstances *binary* linkage of code to a kernel makes that code a derivative work of the kernel. To calm down the lawyers, I as the principal kernel maintainer and anthology copyright holder on the code am therefore adding the following interpretations to the kernel license: 1. Userland programs which request kernel services via normal system calls *are not* to be considered derivative works of the kernel. 2. A driver or other kernel component which is statically linked to the kernel *is* to be considered a derivative work. 3. A kernel module loaded at runtime, after kernel build, *is not* to be considered a derivative work. These terms are to be considered part of the kernel license, applying to all code included in the kernel distribution. They define your rights to use the code in *this* distribution, however any future court may rule on the underlying legal question and regardless of how the license or interpretations attached to future distributions may change. I disagree with 2. Consider the following: - GPL library foo is used by application bar. bar must be GPL because foo is. I agree with this. - Non-GPL library foo is used by GPL application bar. foo does NOT become GPL just because bar is, even if bar statically linked foo in. The kernel is the equivalent of an application. If someone needs to statically link in a driver, which is the equivalent of a library, I don't see how that should make the driver GPL. -Jeff P.S. I don't claim to be a lawyer, this is just my opinion. -- Jeff Golds Sr. Software Engineer [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/
2.4.6pre5aa1
Diff between 2.4.6pre3aa2 and 2.4.6pre5aa1:
-
Moved on top of 2.4.6pre5.
Only in 2.4.6pre3aa2: 00_alpha-warnings-1
Only in 2.4.6pre3aa2: 00_backout-udelay-1
Only in 2.4.6pre3aa2: 00_locks-1
Only in 2.4.6pre3aa2: 00_xircom-tulip-cb-2.4.5ac13-1
Only in 2.4.6pre3aa2: 10_alpha-udelay-1
Merged in pre5.
Only in 2.4.6pre5aa1: 00_alpha-irq_err_count-1
Fix alpha compile from Jeff.
(recommended)
Only in 2.4.6pre5aa1: 00_bh-async-1
Patch to [EMAIL PROTECTED] to allow lowlevel layer
to override bh-b_end_io callback without breaking the
async I/O.
(nice to have)
Only in 2.4.6pre3aa2: 00_ksoftirqd-6
Only in 2.4.6pre5aa1: 00_ksoftirqd-7
%c1 do_softirq merged in mainline, fix reject.
Only in 2.4.6pre3aa2: 00_ksoftirqd-6_ppc-1
Only in 2.4.6pre5aa1: 00_ksoftirqd-7_ppc-2
Dropped a comment (no code change). ('and' is really needed
because lwz doesn't update the equal bit state of the cpu)
Only in 2.4.6pre3aa2: 10_no-virtual-1
Only in 2.4.6pre5aa1: 10_no-virtual-2
Comments generated rejects, fixup.
Only in 2.4.6pre3aa2/30_tux: 30_tux-2
Only in 2.4.6pre5aa1/30_tux: 30_tux-3
Include init.h to fix some compilation trouble and drop the
__KERNEL_SYSCALLS__ #defines from the .c files.
-
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1.bz2
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/30_tux/
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/40_experimental/
In the 40_experimental there's the latest blkdev in pagecache and it has
to be applied after all the other patches. Issue to solve in the
blkdev-pagecache-3 patch are:
- fix ramdisk: lookup on pagecache and pin blkdev address space
while the ramdisk stays allocated
- I/O granularity is fixed to 4k, this can be easily decreased with
a recompile, but I'm wondering if we should make the granularity
dynamic somehow to avoid the partial write to do too many
read-modify-write cycles
- Currently the pagecache assumes the end of the device is aligned
for excess on the next 4k (in genereal BUFFERED_BLOCKSIZE)
boundary to be sure we can read and write all bytes of the disk.
(see buffered_blk_size) I don't expect problems but blkdev layer
must be able to cope with it.
I'm running this patch on all my systems and I didn't had problems yet
(though you cannot expect to get ramdisk and in turn initrd working
[ramfs works fine of course]). As said in a earlier email you can do
rawio now by simply openeing the blkdev with O_DIRECT (however you get
the BUFFERED_BLOCKSIZE granularity for it too, instead of the
hardblocksize granularity of the /dev/raw rawio, but this also means you
pay less cycles for bulding a flood of 512 bytes large bh) and mmap
private and shared on the blkdev works like with files in the fs.
Andrea
-
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: Controversy over dynamic linking -- how to end the panic
** Reply to message from Eric S. Raymond [EMAIL PROTECTED] on Thu, 21 Jun 2001 14:14:42 -0400 To calm down the lawyers, I as the principal kernel maintainer and anthology copyright holder on the code am therefore adding the following interpretations to the kernel license: 1. Userland programs which request kernel services via normal system calls *are not* to be considered derivative works of the kernel. 2. A driver or other kernel component which is statically linked to the kernel *is* to be considered a derivative work. 3. A kernel module loaded at runtime, after kernel build, *is not* to be considered a derivative work. Although these are good things to add, I don't think they're compatible with the GPL. That is, Linus can't just state these interpretations and add them to the GPL, because it will weaken the GPL as a whole. I say that because you do not include any language that clarifies that from a legal sense. I heard recently that kernel modules are technically, from the GPL point-of-view, a derivative work, because they include kernel header files. However, since Linus understands that this precludes binary-only modules, he has made an exception to the Linux kernel license. The problem with that is that I have never seen any written evidence of this. IANAL, but IMO, there are only two solutions: 1. License the Linux kernel under a different license that is effectively the GPL but with additional text that clarifies the binary module issue. Unfortunately, this license cannot be called the GPL. Politically, this would probably be a bad idea. 2. License the Linux kernel under TWO licenses, one the GPL, and another which talks about the binary module issue. Unfortunately, this would probably not work either, as technically these two licenses are incompatible. I guess what I'm trying to say is that this issue won't be resolve simply by some interpretations by Linus as to what is and is not a derived work. I think the FSF needs to be involved in this. To be honest, I disagree that #include'ing a GPL header file should force your app to be GPL as well. That may be how the license reads, but I think it's a very bad idea. I could write 1 million lines of original code, but if someone told me that but simply adding #include stdio.h my code is now a derivative of the stdio.h, I'd tell him to go screw himself. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.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: correction: fs/buffer.c underlocking async pages
On Thu, 21 Jun 2001, Andrea Arcangeli wrote: On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote: What's the problem with the existing code, and why do people want to add a (unnecessary) new bit? there's no problem with the existing code, what I understood is that they cannot overwrite the -b_end_io callback in the lowlevel blkdev layer or the page will be unlocked too early. Oh, fair enough. I don't have any objections to the patch in that case, although it does end up being a 2.5.x issue as far as I'm concerned (and don't worry, 2.5.x looks like it will open in a week or two, so we're not talking about long timeframes). Obviously 2.5.x code may be back-ported to 2.4.x later. That will be up to Alan. Linus - 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: Controversy over dynamic linking -- how to end the panic
On Thu, Jun 21, 2001 at 11:39:13AM -0700, Jeff Golds wrote: Eric S. Raymond wrote: The GPL license reproduced below is copyrighted by the Free Software Foundation, but the Linux kernel is copyrighted by me and others who actually wrote it. The GPL license requires that derivative works of the Linux kernel also fall under GPL terms, including the requirement to disclose source. The meaning of derivative work has been well established for traditional media, and those precedents can be applied to inclusion of source code in a straightforward way. But as of mid-2001, neither case nor statute law has yet settled under what circumstances *binary* linkage of code to a kernel makes that code a derivative work of the kernel. To calm down the lawyers, I as the principal kernel maintainer and anthology copyright holder on the code am therefore adding the following interpretations to the kernel license: 1. Userland programs which request kernel services via normal system calls *are not* to be considered derivative works of the kernel. 2. A driver or other kernel component which is statically linked to the kernel *is* to be considered a derivative work. 3. A kernel module loaded at runtime, after kernel build, *is not* to be considered a derivative work. These terms are to be considered part of the kernel license, applying to all code included in the kernel distribution. They define your rights to use the code in *this* distribution, however any future court may rule on the underlying legal question and regardless of how the license or interpretations attached to future distributions may change. I disagree with 2. Consider the following: - GPL library foo is used by application bar. bar must be GPL because foo is. I agree with this. - Non-GPL library foo is used by GPL application bar. foo does NOT become GPL just because bar is, even if bar statically linked foo in. The kernel is the equivalent of an application. If someone needs to statically link in a driver, which is the equivalent of a library, I don't see how that should make the driver GPL. -Jeff P.S. I don't claim to be a lawyer, this is just my opinion. http://www.gnu.org/copyleft/gpl-faq.html#WritingFSWithNFLibs offers some insight on linking free software with non-free libraries. However, I'm not sure I agree with your interpretation of the relationship between kernel and driver. The kernel is fully functional (excluding use of the hardware for which the driver provides an interface) without the driver code - however, the driver requires the kernel to be usable. Still using your analogy, it would seem the driver is the application, and the kernel is the library. The facilities that the driver provides to the kernel don't seem to be much more than callbacks used in traditional library schemes to implement application specific behavior as part of a larger library framework. My 2c. -Jeff -- Jeff Mahoney [EMAIL PROTECTED] [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: Controversy over dynamic linking -- how to end the panic
On 21 Jun 2001 13:46:48 -0500, Timur Tabi wrote: ** Reply to message from Eric S. Raymond [EMAIL PROTECTED] on Thu, 21 Jun 2001 14:14:42 -0400 To calm down the lawyers, I as the principal kernel maintainer and anthology copyright holder on the code am therefore adding the following interpretations to the kernel license: 1. Userland programs which request kernel services via normal system calls *are not* to be considered derivative works of the kernel. 2. A driver or other kernel component which is statically linked to the kernel *is* to be considered a derivative work. 3. A kernel module loaded at runtime, after kernel build, *is not* to be considered a derivative work. Although these are good things to add, I don't think they're compatible with the GPL. That is, Linus can't just state these interpretations and add them to the GPL, because it will weaken the GPL as a whole. I say that because you do not include any language that clarifies that from a legal sense. Hell, why does the linux community need to care about other *greedy* people who don't want to GPL their work anyway? If you want to protect GPL as the principle in Linux, well, screw the device driver makers! I heard recently that kernel modules are technically, from the GPL point-of-view, a derivative work, because they include kernel header files. However, since Linus understands that this precludes binary-only modules, he has made an exception to the Linux kernel license. The problem with that is that I have never seen any written evidence of this. IANAL, but IMO, there are only two solutions: 1. License the Linux kernel under a different license that is effectively the GPL but with additional text that clarifies the binary module issue. Unfortunately, this license cannot be called the GPL. Politically, this would probably be a bad idea. 2. License the Linux kernel under TWO licenses, one the GPL, and another which talks about the binary module issue. Unfortunately, this would probably not work either, as technically these two licenses are incompatible. I guess what I'm trying to say is that this issue won't be resolve simply by some interpretations by Linus as to what is and is not a derived work. I think the FSF needs to be involved in this. To be honest, I disagree that #include'ing a GPL header file should force your app to be GPL as well. That may be how the license reads, but I think it's a very bad idea. I could write 1 million lines of original code, but if someone told me that but simply adding #include stdio.h my code is now a derivative of the stdio.h, I'd tell him to go screw himself. What is the difference between including kernel header file and including GPLed header file? Best Regards, Wei - 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/
Bad bridge mapping problem: PCMCIA card not started
Hi, I hope that I post this at the right place. There was no answer at various other places. Please CC me for any reply. I would like to know if the problem I encounter can be fixed: I upgraded the system memory from 192 MB to 512 MB. The system clearly detected the upgrade and linux booted. However, at the cardmgr step, cardmgr complains not finding an entry in /proc/devices for pcmcia (which is correct). I checked with /var/log/syslog and apparently the problem appears before, because of a bridge mapping problem. in syslog: kernel: Linux PCMCIA Card Services 3.1.25 kernel: kernel build: 2.4.3-20mdk #1 Sun Apr 15 23:03:10 CEST 2001 kernel: options: [pci] [cardbus] [apm] kernel: Intel PCIC probe: PCI: Found IRQ 11 for device 00:03.0 kernel: PCI: The same IRQ used for device 00:03.1 kernel: PCI: The same IRQ used for device 00:07.2 kernel: kernel: Bad bridge mapping at 0x17ff! kernel: not found kernel: ds: no socket drivers loaded This problem occurs with 256+64,256+128,256+256, but not 192 or 256 MB. The Multifunction Card I have is the XIRCOM Realport Ethernet 10/100-56K, known as REM56-100BTX With 192 MB (when it's OK), the syslog message goes like this: kernel: Linux PCMCIA Card Services 3.1.25 kernel: kernel build: 2.4.3-20mdk #1 Sun Apr 15 23:03:10 CEST 2001 kernel: options: [pci] [cardbus] [apm] kernel: Intel PCIC probe: PCI: Found IRQ 11 for device 00:03.0 kernel: PCI: The same IRQ used for device 00:03.1 kernel: PCI: The same IRQ used for device 00:07.2 kernel: PCI: Found IRQ 11 for device 00:03.1 kernel: PCI: The same IRQ used for device 00:03.1 kernel: PCI: The same IRQ used for device 00:07.2 kernel: kernel: TI 1420 rev 00 PCI-to-Cardbus at slot 00:03, mem 0x1000 kernel:hos opts [0]: [ring] [serial pci irq] [pci irq 11] [lat 32/32] [bus 2/5] kernel:hos opts [1]: [ring] [serial pci irq] [pci irq 11] [lat 32/32] [bus 6/9] kernel: spurious 8259A interrupt: IRQ7 kernel:ISA irqs (scanned) = 3,4,7,10 PCI status changes kernel: cs: memory probe 0xa000-0xa0ff: clean kernel: xirc2ps_cs.c 1.31 1998/12/09 19:32:55 (dd9jn+kvh) kernel: cs: IO probe 0x0100-0x04ff: excluding 0x378-0x37f etc... Thanks for any help, Regards, Marc - 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] Threads, inelegance, and Java
On Wednesday 20 June 2001 23:13, Pete Zaitcev wrote: Then again JavaOS was an abortion on top of Slowaris. [...] This is a false statemenet, Rob. It was an abortion, all right, but not related to Solaris in any way at all. I worked on the sucker for six months at IBM in 1997. I don't know if the code we worked on is the code you're thinking of, but we had a unix kernel (which my coworkers SAID was solaris) with a JVM running on top of it as the init task. Ported to Power PC by some overseas IBM lab (might have been the japanese guys). We had two flavors of it to test, one the Power PC build and one the Intel build, and to make the Intel build work first we installed Solaris for Intel. Other fun little details included that when I left IBM it still couldn't read from the hard drive, so the entire system TFTP'd itself through the network at boot, including a compressed ramdisk image containing Lotus Desktop. The machine required 64 megs of memory to run that (~32 megs or so of which was for the ramdisk, and no it didn't run executables straight out of the ramdisk, it copied them into MORE ram to run). JavaOS existed in two flavours minimum, which had very little in common. The historically first of them (Luna), was a home-made executive with pretty rudimentary abilities. I believe that's what we were using, and that home-made executive was a stripped down version of the solaris kernel. Second flavour of JavaOS was made on top of Chorus, and, _I think_, used large parts of Luna in the the JVM department, but it had decent kernel, with such novations as a device driver interface :) You haven't lived until you've seen java code, with inline assembly, claiming to be a video framebuffer device driver thing. That sort of thing gives you a real appreciation for the portions of your life where you DON'T have to deal with that kind of thing. I only had to go into there to debug stuff though, mostly I was working on the application end of things. (Taking third party closed source beta-release nonsense from people who wanted a single point of contact with IBM who turned out to be someone in Poughkipsee who had quit the company a couple weeks back. So it didn't work, we didn't have source, the people who supplied it wouldn't talk to us, and when we did trace a problem to the JavaOS code and reported it to Sun they went we fixed that over a month ago and we've been sending you twice-weekly drops! But of course our codebase didn't sync with their codebase more than once a month or so because there was so much porting effort involved... And you wonder why I quit... Such a thing existed. I do not remember its proper name, but I remember that it booted from hard disk. Floppy was too small for it. Maybe. Wouldn't have been nearly as big as JavaOS, though. FAR better suited to an embedded system... Porting half of Solaris to Power PC for JavaOS has got to be one of the most peverse things I've seen in my professional career. I never heard of PPC port of either of JavaOSes, although Chorus runs on PPC. Perhaps this is what you mean. It was called JavaOS for Business... http://www.javaworld.com/javaworld/jw-05-1998/jw-05-idgns.javaos.html And was killed about a year later... http://news.cnet.com/news/0-1003-200-346375.html?tag=bplst I worked on it for six months in the second half of 1997. Solaris for PPC existed, but never was widespread. It did not have JVM bundled. We mostly used AIX on the PPC systems that weren't directly testing the new code. I'm upset that Red Hat 7.1 won't install on that old laptop because it only has 24 megs of ram and RedHat won't install in that. [...] You blew adding a swap partition, I suspect... This was before it let me run fdisk or Disk Druid. I'll try again this weekend... -- Pete Rob - 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: temperature standard - global config option?
[EMAIL PROTECTED] (Lauri Tischler) wrote on 21.06.01 in [EMAIL PROTECTED]: Richard J Moore wrote: 59.42886726469 ±2°C is obviously ludicrous, even if that's what my calculator gives me. I should instead write 59 ±2°C, since So, if I follow you argument then shouldn't you be writing 58 ±2°C or should it be 60 ±2°C ? What it means is that whatever dingus measured the temperature, reported the temperature as 59C. Well, maybe. And maybe it reported the temperature as 76 units, where a unit is approximately 0.69°C, and zero units are approximately 6.99°C, and we happen to know the accuracy is 3 units. (That makes out to 59.43 ±2.07°C, or 57.36 to 61.50°C, whereas 59 ±2°C works out to 57.00 to 61.00°C - they do overlap, but they're not the same. Now you might not care - but then again, you might care.) MfG Kai - 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: Controversy over dynamic linking -- how to end the panic
** Reply to message from Mike Harrold [EMAIL PROTECTED] on Thu, 21 Jun 2001 15:04:21 -0400 (EDT) Not to mention utterly unenforceable. Consider: 1) Oracle Corp. builds their database for Linux on a Linux system. 2) Said system comes with standard header files, which happen in this case to be GPL'd header files. 3) Oracle Corp.'s database becomes GPL. There's not a court in the civilised world that would uphold the GPL in that scenario. I do believe, however, that in these cases the header files in question are under the LGPL, which does specifically allow linking and #including in non-GPL and non-LGPL code. In my opinion, this whole thing would just go away (including some of Microsoft's anti-GPL rants), if the FSF officially declared that under the GPL, #including a GPL header file does NOT force your code to be also GPL. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.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: Controversy over dynamic linking -- how to end the panic
To be honest, I disagree that #include'ing a GPL header file should force your app to be GPL as well. That may be how the license reads, but I think it's a very bad idea. I could write 1 million lines of original code, but if someone told me that but simply adding #include stdio.h my code is now a derivative of the stdio.h, I'd tell him to go screw himself. Not to mention utterly unenforceable. Consider: 1) Oracle Corp. builds their database for Linux on a Linux system. 2) Said system comes with standard header files, which happen in this case to be GPL'd header files. 3) Oracle Corp.'s database becomes GPL. There's not a court in the civilised world that would uphold the GPL in that scenario. Regards, /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/
rename problem on vfat file systems
Hi,
I have been having problems using rename system call
on vfat file systems. I have looked at the kernel code
and tried everything I could do to figure out what
might be going wrong. As a last resort I thought you
might be able to help me.
The /etc/fstab entry for the drive that I mount looks
like this
/dev/sdc1 /mnt/sns-c vfat noauto,sync,user 0 0
here's the code snippet of what I am trying to do
int copy_seg_file(char *segFile)
{
char command[128];
sprintf(command, cp %s /mnt/sns-c/tmp/segfile,
*segFile);
system(command);
sync();
rename(/mnt/sns-c/tmp/segfile,
/mnt/sns-c/segments/segfile);
printf(file copied\n);
}
initially the file is copied to the temporary
directory to deal with the power outage during the
file copy. Once the file is completely copied, it will
be renamed to the final destination.
If I reboot the machine just after the rename() call
is completed, when the machine comes up the file
/mnt/sns-c/segments/segfile has zero bytes and there
is no file in the tmp directory. Effectively the file
is lost some where. Running fsck recovers the file,
but it doesn't help me much because I would be copying
hundreds of files and its difficult to match the
files.
Can you think of any thing that might be causing this.
Any help is highly appreciated.
Thanks,
Kumar
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.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: rename problem on vfat file systems
On Thu, 21 Jun 2001, abc abc wrote: If I reboot the machine just after the rename() call is completed, when the machine comes up the file /mnt/sns-c/segments/segfile has zero bytes and there is no file in the tmp directory. Effectively the file is lost some where. Running fsck recovers the file, but it doesn't help me much because I would be copying hundreds of files and its difficult to match the files. Can you think of any thing that might be causing this. Crappy filesystem layout. If you want to do something a-la journalling for VFAT - seek professional help. - 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: Controversy over dynamic linking -- how to end the panic
On Thu, 21 Jun 2001, Timur Tabi wrote: In my opinion, this whole thing would just go away (including some of Microsoft's anti-GPL rants), if the FSF officially declared that under the GPL, #including a GPL header file does NOT force your code to be also GPL. The problem being, there is no such thing as header file from C point of view. I can do cat my_file.c EOF #include /home/you/your_file.c EOF and be done with that. And yes, it's abusing cpp. - 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: Alan Cox quote? (was: Re: accounting for threads)
On Thursday 21 June 2001 10:02, Jesse Pollard wrote: Rob Landley [EMAIL PROTECTED]: On Wednesday 20 June 2001 17:20, Albert D. Cahalan wrote: Rob Landley writes: My only real gripe with Linux's threads right now [...] is that ps and top and such aren't thread aware and don't group them right. I'm told they added some kind of threadgroup field to processes that allows top and ps and such to get the display right. I haven't noticed any upgrades, and haven't had time to go hunting myself. There was a threadgroup added just before the 2.4 release. Linus said he'd remove it if he didn't get comments on how useful it was, examples of usage, etc. So I figured I'd look at the code that weekend, but the patch was removed before then! Can we give him feedback now, asking him to put it back? Submit patches to me, under the LGPL please. The FSF isn't likely to care. What, did you think this was the GNU system or something? I've stopped even TRYING to patch bash. try a for loop calling echo $$, eery single process bash forks off has the PARENT'S value for $$, which is REALLY annoying if you spend an afternoon writing code not knowing that and then wonder why the various process's temp file sare stomping each other... Actually - you have an error there. $$ gets evaluated during the parse, not during execution of the subprocess. Well, that would explain it then. (So $$ isn't actually an environment variable, it just looks like one? I had my threads calling a seperate function...) To get what you are describing it is necessary to sh -c 'echo $$' to force the delay of evaluation. Except that this spawns a new child and gives me the PID of the child, which lives for maybe a tenth of a second... Maybe I could do something with eval...? Either way, I switched the project in question to python. That depends on what you are trying to do. A couple people emailed me and pointed out I had to set IFS=$'\n', (often after first saying there's no way to do that and then correcting themselves towards the end of the message...) My first attempt to do it was to pipe the data into a sub-function do read a line at a time and store the results in an array. (Seemed pretty straightforward.) Except there's no way to get that array back out of the function, and that IS documented at the end of the bash man page. As I said: Python. Are you trying to echo the entire ls -l? or are you trying to convert an ls -l into a single column based on a field extracted from ls -l. I was trying to convert the lines into an array I could then iterate through. If the fields don't matter, but you want each line processed in the loop do: ls -l | while read i do echo line:$i done Hmmm... If that avoids the need to export the array from one shell instance to another, maybe it'd work. (I'm not really doing echo, I was doing var[$i]=line, with some other misc stuff.) But I got it to work via IFS, and that's good enough for right now. If you want such elaborate handling of strings, I suggest using perl. I came to the same conclusion, but would like for more than one person to be able to work on the same piece of code, so it's python. (Or PHP if Carl's the one who gets around to porting it first. :) But in the meantime, the shell script is now working. Thanks everybody...) Back to talking about the kernel.:) Rob - 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: fealnx problem
Jon Forsberg [EMAIL PROTECTED] écrit :
I have an Surecom EP-320X-S Ethernet adapter which apparently uses a
Myson MTD-8xx chip. It works well with the fealnx driver (labeled
Myson MTD-8xx PCI Ethernet support in kernel config) except for one thing:
After a while in use it stops working and prints
Jun 21 12:18:18 naut kernel: NETDEV WATCHDOG: eth0: transmit timed out
[...]
Could you give this a try please ?
It may crash.
--- linux-2.4.5.orig/drivers/net/fealnx.c Wed Jun 6 09:13:43 2001
+++ linux-2.4.5/drivers/net/fealnx.cThu Jun 21 21:18:59 2001
@@ -418,7 +418,7 @@
static struct net_device_stats *get_stats(struct net_device *dev);
static int mii_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static int netdev_close(struct net_device *dev);
-
+static void reset_rx_descriptors(struct net_device *dev);
void stop_nic_tx(long ioaddr, long crvalue)
{
@@ -1121,14 +1121,13 @@
{
struct netdev_private *np = dev-priv;
long ioaddr = dev-base_addr;
+ int i;
printk(KERN_WARNING %s: Transmit timed out, status %8.8x,
resetting...\n, dev-name, readl(ioaddr + ISR));
#ifndef __alpha__
{
- int i;
-
printk(KERN_DEBUG Rx ring %8.8x: , (int) np-rx_ring);
for (i = 0; i RX_RING_SIZE; i++)
printk( %8.8x, (unsigned int) np-rx_ring[i].status);
@@ -1139,12 +1138,36 @@
}
#endif
- /* Perhaps we should reinitialize the hardware here. Just trigger a
- Tx demand for now. */
+ dev-if_port = np-default_port;
+ /* Reinit. Gross */
+
+ /* Reset the chip's Tx and Rx processes. */
+ stop_nic_tx(ioaddr, 0);
+ reset_rx_descriptors(dev);
+
+ /* Disable interrupts by clearing the interrupt mask. */
+ writel(0x, ioaddr + IMR);
+
+ /* Reset the chip to erase previous misconfiguration. */
+ writel(0x0001, ioaddr + BCR);
+ for (i = 0; i 50; i++) {
+ readl(ioaddr + BCR);
+ rmb();
+ }
+
+ writel(virt_to_bus(np-cur_tx), ioaddr + TXLBA);
+ writel(virt_to_bus(np-cur_rx), ioaddr + RXLBA);
+
+ writel(np-bcrvalue, ioaddr + BCR);
+
+ writel(0, dev-base_addr + RXPDR);
+ set_rx_mode(dev);
+ /* Clear and Enable interrupts by setting the interrupt mask. */
+ writel(FBE | TUNF | CNTOVF | RBU | TI | RI, ioaddr + ISR);
+ writel(np-imrvalue, ioaddr + IMR);
+
writel(0, dev-base_addr + TXPDR);
- dev-if_port = 0;
- /* Stop and restart the chip's Tx processes . */
dev-trans_start = jiffies;
np-stats.tx_errors++;
--
Ueimor
-
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/
