Re: Is a process with a priority of 0 legal ?
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote: > If the weight & priority of all runnable processes is 0 then the > recalculate with recalculate p->counter=0 for all runnable > processes, & the code will go into a tight loop between the > goodness calculation & recalculate. p->priority can never become 0. The minimum value allowed is 1. The only way the value could become 0 is when something scribbles all over memory (and in that case I'd prefer a hang to possible data corruption). regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Question: slow network performance between Linux and Solaris 7
HI all, Thanks for all the help. I have switched to a low-end 16-bit PCMCIA network card by 3COM 3C589 10/BT. And now everything works as it should. Before making this change, I thought that my problem was caused by the TCP/IP layer -- between Linux and Sun, because I could get good network performance between two Liux boxes. Anyhow, after start to use this 3COM card, it works. So, I think the problem IS Xircom Cardbus card related. Thanks to all who responded! ... The best thing I got back from this that the support from Linux is just good as ever... and it is the problem with the Xircom driver, not the TCP/IP layer... :-) Jack David Hinds wrote: > > On Thu, Sep 07, 2000 at 03:34:46AM +, Andrew Morton wrote: > > > > Seconded. In both 2.2 (tulip_cb) and 2.4 (xircom_tulip_cb) on 100baseT > > the driver reports a huge number of Tx carrier errors and sustains 50 > > mbits/sec on TCP Tx and 1 mbit/sec on TCP Rx. It should do 98 mbits/sec > > each way (using netperf). > > This is fixed in my latest PCMCIA beta, on projects.sourceforge.net in > /pub/pcmcia-cs/NEW. > > (there are two bugs... the driver doesn't monitor the MII to determine > when to switch the Tulip into full duplex, and also, even in full > duplex mode, the bogus Xircom chip still reports carrier errors) > > > And (less seriously), with or without Andrea's recent patch the > > interface doesn't work after poweron or hotplug. It needs a down/up or > > it needs to be set into promiscuous mode long enough to receive a > > packet. > > I don't know what the deal is with the promiscuous thing. I find that > with my card, Andrea's patch doesn't really make a difference; with or > without it, the card sometimes needs to be toggled into promiscuous > mode. It seems random. > > -- Dave -- Jack Duan, [EMAIL PROTECTED] Systems Architect, iPlanet Infrastructure Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
> Well, there's butt-loads of ugly Makefile shit all over the place. It > isn't going away. Some of it went away when Keith Owens rewrote modules-install. More of it went away between 2.2 and 2.4. Check out drivers/net/Makefile or drivers/scsi/Makefile or lots of other Makefiles, for instance. They are 1/3 the size they used to be. Even more of it's going away in 2.5. Here's my contribution to making it go away: ftp://ftp.shout.net/pub/users/mec/kbuild/dancing-makefiles-2.3.26 ftp://ftp.shout.net/pub/users/mec/kbuild/x-Dkm-9.diff Where is yours? > Yes and no. You can only insmod _one_ serial.o so the name does have > to be unique at the time it's loaded. True. But the Makefiles are no longer part of this problem. > (BTW, the current modutils (2.3.15) won't see all the modules from a > modules_install.) Oh? That would be a bug. Which modules does it fail to see? > From an efficiency standpoint, one file per directory is a hideous waste > of both filesystem space (one inode and one block) and system resources > (file access times, dcache, et. al.) So, go benchmark "insmods per second". I want to see a %age from some controlled test where the only differences are the module arrangement and the version of modutils used. Then tell us about what use case you have where this metric matters. If you say "I have a custom embedded system where every filesystem block matters", then I will say: "so go into the modules directory and arrange the directory structure the way you like it". I'll tell you what matters to me: correctness and simplicity. Keith killed a lot of swampy nasty code and I'm grateful. That's way more important to me than the "file access time" difference between /lib/modules/2.4.0/char/serial.o and /lib/modules/2.4.0/kernel/drivers/char/serial.o. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: What the Heck? [Fwd: Returned mail: User unknown]
Igmar Palsenberg writes: > > Ugh. What rubbish. > > > > The moment I detect my provider changing anything beyond a TTL is the > > moment I find a new provider. > > The 'problem' is a bunch of stupid American politics (excuse anyone > American), than passed a law that all spam containing a remove adress is > legal. > > So that means I get all kinds of spam containing 'This is legal because > blahblah Bill blablah' > > Well, I don't live in the US, and that bill is not legal here. There was a Senate bill 1918 in the US that proposed this but it did not pass. It's not legal in the US either. Any reference to "S.1918 section 301" you might see in a spam is bogus. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test8-pre6
On Thu, 7 Sep 2000, Bill Wendling wrote: > Also sprach dean gaudet: > } On Wed, 6 Sep 2000, Linus Torvalds wrote: > } > } > Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we > } > fixed it now several times, and I was always wrong. > } > } obpainintheass: haven't you anti-debugger-religion folks been claiming > } that if you don't have a debugger you're forced to "think about the code > } to find the correct fix"? so, like, why are you guessing right now? :) > } > Don't be stupid. dude, i gave at least three hints that i was joking up there. stupid would be if i claimed that it was obvious that a debugger would have helped this situation. instead all i'm claiming is that it's orthogonal. > Because some bugs are very hard to fix no matter what tool/brain you > throw at it... so you got my point after all. -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Scalability Efforts
On Thu, 7 Sep 2000, Henry Worth wrote: > With all the talk of improving Linux's scalability to > large-scale SMP and ccNUMA platforms -- including efforts > at several HW companies and now OSDL forming to throw > hardware at the effort -- is there any move afoot to > coordinate these efforts? Nothing coordinated, AFAIK... > Or is it all, whatever there may be of it, taking > place offline? Most of the times I've talked about this topic it was in person with other developers at various conferences. For the VM subsystem and the scheduler we have some ideas to improve scalability for NUMA machines. It's not been implemented yet, but for most of it the design seems to be pretty ok and ready to be implemented for 2.5. OTOH, some of the develish details still aren't resolved. If there are people interested in discussing this topic, I'll setup a mailing list for it ... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux kernel TCP, network connections and iptables
Hello! > I believe that the DoS is that the path through the kernel turns out to be > long and that a lot of these packets will bring a machine to its knees. It is not longer than path for any other kind of packet. In the reported case it is much shorter. 8) Apparently, you try to remind about that silly pseudo-attack against some kind of BSD? 8) First, it was different, because flood was made for port, which was listened. The path is really longer there, but the difference is ridiculuous. Second, machines _are_ killed with high pps rates, no doubts. But it has nothing to do either with TCP or with special packet pattern. And any kind of policing is useless to fight this. Just do not attach slow machines to fast but LANs, if you are afraid of local pps floods. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote: >(1) Rules.make had a load of ugly code to translate from the source tree >to the symlink farm. This code had plenty of bugs and race conditions >(e.g. if two subdirectories have the same MOD_LIST_NAME and make >runs in parallel). > >(2) The top Makefile had a butt-load of even uglier code to translate >from the symlink farm to the install tree. This code needed to >be coordinated with modutils releases. It also suffered from bugs, >such as configuration changes leaving stale files around. Well, there's butt-loads of ugly Makefile shit all over the place. It isn't going away. I'll agree the symlink farm was a bad idea. However, the mass of one file per directory crap is no better an idea. >(3) Module names had to be unique across the entire kernel tree, >which is a silly limitation. Yes and no. You can only insmod _one_ serial.o so the name does have to be unique at the time it's loaded. This is the "serial.o" vs. "usb serial.o" problem. If you need both modules loaded at the same time then they still have to be unique. >So now, the module installation code is simple and correct and doesn't >need to be updated in tandem with modutils every two weeks. WRONG. The current system will be slinging directories left and right. If someone doesn't tell modutils about them, then it doesn't work. There's already been heated arguements about the modutils scaling the directory tree in search of modules. It was generally conceeded to be a bad idea. (BTW, the current modutils (2.3.15) won't see all the modules from a modules_install.) >From an efficiency standpoint, one file per directory is a hideous waste of both filesystem space (one inode and one block) and system resources (file access times, dcache, et. al.) --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux kernel TCP, network connections and iptables
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote: > Hello! > > - Could there be some kind of handling for such packets (meaning TCP packets > > reaching at an unused port with ACK bit set - with no previous SYN etc packet) > > to avoid such DoS attacks? Is the same happening to newer kernels? If yes, > > should we just eat it and shut up (because that's the way TCP works and it > > will not change)? > > TCP MUST do this and this cannot be changed. > > > - To do something about the above DoS,... > > By any _formal_ criteria there is no DoS here. You reply with one packet > to each incoming packet and do not hold any state. Where is DoS? I believe that the DoS is that the path through the kernel turns out to be long and that a lot of these packets will bring a machine to its knees. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3ware controllers and fatal failure mode design decision
On Tue, Sep 05, 2000 at 02:27:02PM -0700, [EMAIL PROTECTED] wrote: > I was wondering if any one knows of a way around the following problem, > and I wanted to warn people considering 3ware controllers as a storage > solution. > > I talked to 3ware already and they don't have a solution. > > The latest 3ware firmware for their current products requires that > all drives in an array be absolutely identical. > > Say you setup an 8 drive RAID 10 array and a year later a drive > blows out. You *MUST* replace it with an absolutely identical > drive. It must ID completely identifical! > > Whoa! What if the drive isn't made anymore? > > Seems like a nightmare scenario to me. Adam from 3ware contacted me and disputes the claims of the 3ware technical support department. He says that you can replace a failed drive with any drive, not just one identical to the rest of the array. This is helpful, if true. However, he did not address that rationale for considering a Maxtor 53073H6 so different from a Maxtor 53073U6 so as to refuse to use them to build an array. He did claim that a change is in the works, that I assume may address my concerns. -- Brian Litzinger <[EMAIL PROTECTED]> Copyright (c) 2000 By Brian Litzinger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was
Hello! > Well, now GCC does CSE across "asm" and will eliminate memory loads, > even though it may not move them! I suspect it always did CSE across > "asm" and we just never got hit by the bug. dummy_lock trick is equivalent to "memory" clobber. So that there is no real bug. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Hangup: Promise ATA100 (PDC20267) and Quantum disk
On Mon, 4 Sep 2000, Lars Knudsen wrote: > I have have serious problems using a specific Quantum disk connected > to a Promise ATA/100 controller. The disk causing problems is the > QUANTUM FIREBALLlct10 30. The disk simply locks up the machine solid > during boot at the point where it should report its IRQ (normally > 'ide2 at 0x8890-0x8897,0x88aa on irq 7'). No Magic SysRQ or > ATX-poweroff works. I have tried this under latest 2.4 kernels and on > 2.2.16 with latest IDE patches (from > http://www.kernel.org/pub/linux/kernel/people/hedrick). Same result. > > There is no abnormal messages or oops posted to console - everything > looks normal apart from the lockup. I tried the behaviour in 2 > different boxes (different chipset). Same problem. I tried the disk on > a normal PIIX4 IDE controller where it works perfect. I tried the > controller using a IBM-DPTA-373420 34 GB drive. Worked perfectly. > > At last I tried using the controller with the Quantum drive on a > Windows box (urrgh). It worked perfectly.. > > No output is attached as it looks perfectly normal. More information > available upon request (here or by email). I am seeing exactly the same problem under 2.4.0-test7. Mine is a little different. I'm using the Promise Ultra66 controllers (I have 2). It works fine on 2.2.15pre13 with the uniform IDE 6.30. The system locks up in the same fasion (No SysRQ, complete lockup) when lvm starts (which scans all the drives) Here the relevant bootup (From the 2.2.15pre13 that works): Uniform Multi-Platform E-IDE driver Revision: 6.30 PIIX4: IDE controller on PCI bus 00 dev 21 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA PDC20262: IDE controller on PCI bus 00 dev 48 PDC20262: not 100% native mode: will probe irqs later PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pio PDC20262: IDE controller on PCI bus 00 dev 50 PDC20262: not 100% native mode: will probe irqs later PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide4: BM-DMA at 0x8400-0x8407, BIOS settings: hdi:pio, hdj:DMA ide5: BM-DMA at 0x8408-0x840f, BIOS settings: hdk:pio, hdl:DMA hda: QUANTUM BIGFOOT1280A, ATA DISK drive hdb: QUANTUM BIGFOOT TS19.2A, ATA DISK drive hdc: Maxtor 84320D4, ATA DISK drive hdd: QUANTUM BIGFOOT TS19.2A, ATA DISK drive hde: QUANTUM BIGFOOT TS19.2A, ATA DISK drive hdf: NEC CD-ROM DRIVE:252, ATAPI CDROM drive hdg: ST317242A, ATA DISK drive hdh: IBM-DJNA-352500, ATA DISK drive hdi: IBM-DPTA-373420, ATA DISK drive hdj: IBM-DPTA-353750, ATA DISK drive hdk: IBM-DTLA-307075, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 ide2 at 0xb400-0xb407,0xb002 on irq 7 ide3 at 0xa800-0xa807,0xa402 on irq 7 ide4 at 0x9800-0x9807,0x9402 on irq 12 ide5 at 0x9000-0x9007,0x8802 on irq 12 hda: QUANTUM BIGFOOT1280A, 1226MB w/87kB Cache, CHS=623/64/63, DMA hdb: QUANTUM BIGFOOT TS19.2A, 18366MB w/418kB Cache, CHS=2341/255/63, UDMA(33) hdc: Maxtor 84320D4, 4120MB w/256kB Cache, CHS=8930/15/63, UDMA(33) hdd: QUANTUM BIGFOOT TS19.2A, 18366MB w/418kB Cache, CHS=37317/16/63, UDMA(33) hde: QUANTUM BIGFOOT TS19.2A, 18366MB w/418kB Cache, CHS=37317/16/63, UDMA(33) hdg: ST317242A, 16446MB w/512kB Cache, CHS=33416/16/63, UDMA(66) hdh: IBM-DJNA-352500, 24405MB w/1966kB Cache, CHS=49585/16/63, UDMA(66) hdi: IBM-DPTA-373420, 32634MB w/1961kB Cache, CHS=66305/16/63, UDMA(66) hdj: IBM-DPTA-353750, 35772MB w/1961kB Cache, CHS=72680/16/63, UDMA(66) hdk: IBM-DTLA-307075, 73308MB w/1916kB Cache, CHS=148945/16/63, UDMA(66) hdf: ATAPI 6X CD-ROM changer w/4 slots, 128kB Cache Uniform CDROM driver Revision: 2.56 --- Terry Hardie[EMAIL PROTECTED] SHOUTip Engineering Product Manager ICQ#: 977679 net.com, 6530 Paseo Padre Parkway Mailstop #2207, Fremont, CA 94555, USA V: +1-510-574-2366 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
On Thu, 7 Sep 2000, Jeff V. Merkey wrote: > [...] so it takes me longer to ponder and digest things -- [...] i'll quote a few 'digesting' comments of you: - about the Linux networking code: " [...] what a mess indeed. " - about Linux itself: " The lack of a Kernel Debugger and other basic kernel level facilities on Linux make TRG's job about 20 times harder on Linux and take almost 10 times as long as is possible on NT, NetWare [...] " - about people who argue that kernel debuggers are not necesserily the panacea: " They seem focused on keeping us in the dark ages. We need tools to make it faster and easier for folks to perform kernel development and make field support of Linux easier. " " A kernel debugger will reduce development costs. No one cares what's underneath, they just care about getting their stuff out the door and reducing the $$$ to support it. This whole argument is one of control and not of technical merit. " i have trouble recognizing this as a digesting process ;-) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test8-pre6
Also sprach dean gaudet: } On Wed, 6 Sep 2000, Linus Torvalds wrote: } } > Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we } > fixed it now several times, and I was always wrong. } } obpainintheass: haven't you anti-debugger-religion folks been claiming } that if you don't have a debugger you're forced to "think about the code } to find the correct fix"? so, like, why are you guessing right now? :) } Don't be stupid. Because some bugs are very hard to fix no matter what tool/brain you throw at it... -- || Bill Wendling[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA: 3CCFE575CT initialization probem under 2.4.0-test7
On Thu, Sep 07, 2000 at 12:25:41PM -0400, Claude LeFrancois (LMC) wrote: > > cardmgr[386]: executing: './network start 3c575_cb' > cardmgr[386]: + usage: ifup > cardmgr[386]: start cmd exited with status 1 The new hot plug PCI interface does not provide a method for passing the correct device name to cardmgr. There is no fix at this time. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Thu, 7 Sep 2000, Alexander Viro wrote: > On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote: > > scale in the end. We'll either see forking, see another OS like FreeBSD > > fill the void, or (worst case) Solaris. > > Somehow I doubt that arguments from marketshare/field circus/etc. peppered > with threats of coprorat world turning to Solaris, etc. will win you much > love from FreeBSD core team. First of all I'm not trying to threaten anyone. Second of all, I'm not trying to affect FreeBSD at all. I'm pointing out there's a void. FreeBSD could fill that void. Or they could choose not to. > I _really_ doubt that they will make any > effect on the development decisions. You see, these guys are bastards > too - comes with the territory. So are NetBSD and OpenBSD folks - try to > speak to Theo that way and you will realize that Linus _is_ a nice guy, > after all. I've gotten into flamewars with Theo on comp.security.unix before. You don't need to explain that to me either. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
On Thu, 31 Aug 2000, Alan Cox wrote: > > /lib/modules//.config is a big step up from the current situation > > and I'm grateful. But I do want /proc/config.gz in the kernel. > > So cat it with a magic lead in after the bzImage gzip block into the bzImage. > If you dont even know what file you are running for kernel you have other > problems anyway There are still plenty of situations where this doesn't help. Booted from unsupported USB floppy or CDROM? Netboot? Linload? ROM image? As for the >4k bug, this was a punt on my part. There should be better helper code in procfs to deal with handing out multiple pages and I didn't feel like creating it. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sd.c Resource allocation fixes + cleanups
Em Thu, Sep 07, 2000 at 01:14:24PM +0200, Torben Mathiasen escreveu: > Linus and others, > > Please take a look at the patch attached, and consider applying. It fixes > some of the OOM issues with sd.c and does general cleanups (module_init/exit, > removing casts, etc.). > > I just searched the archives and found that Arnaldo Carvalho de Melo submitted > a similar patch for test7-pre7 that didn't get in. Please let me know if > something is missing from this one, or if Analdo is currently working on this. I'm just waiting for it to get in 8) - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was
On Thu, 7 Sep 2000, Jamie Lokier wrote: >Common Subexpression Elimination. > >If the compiler sees an expression equivalent to one it evaluated >earlier, there is no need to evaluate it a second time. > >So "a = x+x; b = x+x" will evaluate "x+x" just once and store it twice. I didn't know the name of that particular optimization, thanks. >In more complicated cases, where the result of the first read is >actually used before the "asm", the "memory" clobber causes the second >read to occur as well as the first. Indeed. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was
> "andrea" == Andrea Arcangeli <[EMAIL PROTECTED]> writes: andrea> On Thu, 7 Sep 2000, Jamie Lokier wrote: >> Well, now GCC does CSE across "asm" and will eliminate memory loads, andrea> What is "CSE"? Common Subexpresion Elimination. You can get a lot of info in "The Dragon book". Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Thu, 7 Sep 2000, Jeff V. Merkey wrote: > > > [...] Hardware problems require a debugger or logic analyzer to fix. > > > [...] > > > > 'kernel problems need a kernel debugger to fix'. How wrong. > > It says "hardware problems" not "kernel problems". read it again. translation of my sentence: "you earlier claimed that kernel problems need a kernel debugger to fix efficiently. Both of your claims are wrong." Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was
Andrea Arcangeli wrote: > >Well, now GCC does CSE across "asm" and will eliminate memory loads, > > What is "CSE"? Common Subexpression Elimination. If the compiler sees an expression equivalent to one it evaluated earlier, there is no need to evaluate it a second time. So "a = x+x; b = x+x" will evaluate "x+x" just once and store it twice. This applies to memory reads too. If you read from memory once, and read it again later, the later read can be eliminated. You have the right value in a register already. Memory CSE depends on proving that no intermediate operation clobbers the data at that address. That is why "memory" clobbers are important. They indicate that the data at that address _may_ have been clobbered, so it must be read again after the clobbering operation. Sometimes, after you've forced the second read, you can eliminate the first one :-) That's why "memory" appears to just move the read in our test case. It's really forcing a read after the "asm", which in turn allows the read before the "asm" to be eliminated. In more complicated cases, where the result of the first read is actually used before the "asm", the "memory" clobber causes the second read to occur as well as the first. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
> And what's up with the explosion of directories? The existing system had at least three problems: (1) Rules.make had a load of ugly code to translate from the source tree to the symlink farm. This code had plenty of bugs and race conditions (e.g. if two subdirectories have the same MOD_LIST_NAME and make runs in parallel). (2) The top Makefile had a butt-load of even uglier code to translate from the symlink farm to the install tree. This code needed to be coordinated with modutils releases. It also suffered from bugs, such as configuration changes leaving stale files around. (3) Module names had to be unique across the entire kernel tree, which is a silly limitation. So now, the module installation code is simple and correct and doesn't need to be updated in tandem with modutils every two weeks. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: We are as good as our tools
On Thu, 7 Sep 2000, Horst von Brand wrote:
> Alexander Viro <[EMAIL PROTECTED]> said:
>
> [...]
>
> > BTW, tools are really nice, but I wouldn't call conventional debuggers
> > a-la [asg]db good ones. I've been _very_ impressed by Acid - after gdb it
> > feels like a switch from MCR to sh. Small core providing a language with
> > enough primitives to build the rest of debugger + library + ability to
> > write new functions. _That_ would be very useful thing to have - you are
> > not limited to stepping/poking anymore and can actually write functions
> > that check state consistency/get stats/whatever and use them. I would
> > really recommend everyone involved in that thread look through the
> > papers on this thing (USENIX '94; available online on the
> > plan9.bell-labs.com/sys/doc/) and look at it in work. Something similar
> > could be really useful - unlike gbd it allows to look at the large picture
> > without wearing your fingers to bones. Essentially, Acid libraries can be
> > used as documentation on the state - very expressive beast.
>
> Is this animal available in source together with plan9? Could it be adapted
> for use on more conventional systems (licence and otehrwise)?
Yes (/sys/src/cmd/acid/*, /sys/src/libmach/*). As for porting... I suspect
that it's easier to write a native equivalent than to emulate their procfs
mechanisms and notes handling. Heck, core stuff (.../acid/*) is 90Kb of
sparse C; our ext2 implementation is several times larger. License is the
usual Plan 9 one, but it applies to source, not to ideas or language
itself... If the core is to be embedded into a kernel (*note*: these guys
didn't bother with that themselves) it certainly needs rewrite anyway.
Note on C style: they keep all library API in one include file, e.g.
libc.h, libmach.h, libregex.h, etc. u.h is the kernel API. libfoo.h
normally contains #pragma lib "libfoo.a", so they don't have to mention
libraries in mkfiles explicitly - derive that information from what is
included. mkfile is equivalent of Makefile - slightly different syntax,
but mostly isomorphic to GNU make. Directory hierarchy is different from
usual for recent Unices - their /usr is our /home and /sys - our /usr;
machine-dependent stuff lives in /{386,alpha,sparc,...}/{bin,lib,include}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
Ingo Molnar wrote: > > On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > > > [...] Hardware problems require a debugger or logic analyzer to fix. > > [...] > > 'kernel problems need a kernel debugger to fix'. How wrong. It says "hardware problems" not "kernel problems". read it again. :-) Jeff > > Ingo > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>I tried it with two compilers, one older than yours and one newer:
So maybe I'm just been unlucky/lucky (depends on the point of view :) or
maybe we patched something I'm not aware of to make the kernel to compile
right.
>.ident "GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)"
>.ident "GCC: (GNU) 2.96 2724 (experimental)"
>
>The command lines were:
>
> gcc -S -O2 test4.c
> kgcc -S -O2 test4.c
>
>In both cases, the memory read occurs before "zzz".
andrea@inspiron:~ > cat p.c
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : );
x = *p;
return x;
}
andrea@inspiron:~ > gcc -O2 -S p.c
andrea@inspiron:~ > cat p.s
.file "p.c"
.version"01.01"
gcc2_compiled.:
.text
.align 16
.globl func
.typefunc,@function
func:
pushl %ebp
movl %esp,%ebp
#APP
#NO_APP
^^^
movl p,%eax
movl %ebp,%esp
popl %ebp
movl (%eax),%eax
ret
.Lfe1:
.sizefunc,.Lfe1-func
.comm p,4,4
.ident "GCC: (GNU) 2.95.2 19991024 (release)"
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
If you want to look at an existing source-code analyzer that works hand-in-glove with compilers, to skim for good or bad ideas, take a look at the LSE/SCA combo from the DECset tools. (Dunno if DECset is even still available; I lost track of what went where as they were dicing up the company.) -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] 2000-05-05 13:27:15 GMT -- still no icebergs in the White River - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
Ingo, I did read it. You have to understand, I'm not a young guy but an old man, so it takes me longer to ponder and digest things -- not because I'm slower, but becasue I'm older. I used to blindy charge at anything when a red flag was waved in front of my face in my youth. As I got older, I learned that at times, it's best to examine things for a while since there can be "barbed wire" between you and the target that not immediately visible, and a person can get tangled up in it. :-) Jeff Ingo Molnar wrote: > > Jeff, please read Linus' mail for an explanation about the dangers of > kernel debuggers. > > Ingo > > On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > > > > > Ingo, > > > > KDB is a user mode debugger designed to debug user space apps that's > > been hacked to run with a driver. It's not designed as a kernel level > > debugger and in real world situations has tons of shortcomings period. > > If someone is working on a car, do they use a wrench, or just pry the > > bolts loose with their teeth? All this "We don' need better tools > > because we are real men" crap I've seen on the list is absurd. Try > > taking a tire off a car with a lug wrench. It's tough. But if you have > > an air socket wrench, like professional auto garage's use, the tire is > > off in under 30 seconds, as opposed to 15 minutes if you do it by hand. > > The whole point here is putting the best kernel level tools in possible > > makes development go way faster, and makes it funner. > > > > :-) > > > > Jeff > > > > Ingo Molnar wrote: > > > > > > On Tue, 5 Sep 2000, Richard Gooch wrote: > > > > > > > Would you classify IKD as a pile of warts you wouldn't want to see in > > > > the kernel? > > > > > > the quality of IKD is IMO excellent ( having written parts of it), > > > yet i wouldnt want to see it in the kernel. That having said, i *did* > > > author and integrate one of the IKD subsystems into the mainstream kernel > > > - the NMI oopser on SMP systems. If a debugging aid is localized then > > > there are no source-code health issues. In the case of the NMI-oopser the > > > case was even clearer: nor a developer, nor a user can do anything useful > > > with a hard lockup, apart from complaining that it 'locked up'. We clearly > > > needed more information than that. > > > > > > KDB is not a code health issue either, it's quite localized. But KDB has > > > the other bad social side-effect David was talking about, it promotes > > > band-aids. So it's a tough call IMO. > > > > > > but the other IKD components, like the soft lockup detector, kernel > > > tracer, leak detector and other goodies, are clearly intrusive. It's > > > also a pain (and distraction) to 'drag' all that functionality along > > > in a developer kernel - i'm sure Mike can attest to that, IDK is > > > frequently broken by lowlevel changes. > > > > > > > Surely there must be some useful features that can be included in the > > > > kernel without uglyfing it or slowing it down (configed > > > > out)? [...] > > > > > > sure, and we have a number of them included already. And we rutinely > > > include debugging facilities along newly rewritten code (witness the > > > spinlock debugging helpers, the waitqueue and highmem debugging helpers, > > > the io.h debugging helper). These things do get removed rutinely though. > > > (maybe except the spinlock.h stuff - IMO we still have too much flux in > > > the SMP code.) > > > > > > it's always a matter of balancing - we have multiple conflicting > > > requirements. One factor in judging a debugging facility is the frequency > > > and difficulty of bugs it detects. If a bug doesnt happen often and is > > > easy to analyze then we need no debugging facility for it. Another factor > > > is the impact of the patch on the kernel proper - memleak for example is > > > extremely intrusive. Yet another factor is the maintainance 'drag' on the > > > generic kernel (this is an issue even if the subsystem itself is > > > localized) - eg. the mcount() debugging aids (on which several IKD > > > features are based) periodically caused merging problems in the x86 arch, > > > and they will continue causing problems once we implement fast-syscalls on > > > x86. I'm happy that Mike and Andrea are maintaining IKD - but we dont want > > > to force this maintainance overhead on Linus. Plus the social factors > > > mentioned by David and Alexander. There are easy decisions and there are > > > hard decisions. KDB is IMO not an easy call. > > > > > > Ingo > > > > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to [EMAIL PROTECTED] > > > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Thu, 7 Sep 2000, Jamie Lokier wrote: >Yes, it does. Nice. >.ident "GCC: (GNU) 2.96 2724 (experimental)" > >>From the Red Hat 7 beta. Ok. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > [...] Hardware problems require a debugger or logic analyzer to fix. > [...] 'kernel problems need a kernel debugger to fix'. How wrong. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
Andrea Arcangeli wrote:
> >int *p;
> >int func()
> >{
> > int x;
> > x = *p;
> > __asm__ __volatile__ ("" : : : "memory");
> > x = *p;
> > return x;
> >}
>
> Defintely none difference here (-fstrict-aliasing doesn't change anything
> either).
>
> andrea@inspiron:~ > gcc -v
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
I tried it with two compilers, one older than yours and one newer:
.ident "GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)"
.ident "GCC: (GNU) 2.96 2724 (experimental)"
The command lines were:
gcc -S -O2 test4.c
kgcc -S -O2 test4.c
In both cases, the memory read occurs before "zzz".
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test8-pre6
On Wed, 6 Sep 2000, Linus Torvalds wrote: > Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that we > fixed it now several times, and I was always wrong. obpainintheass: haven't you anti-debugger-religion folks been claiming that if you don't have a debugger you're forced to "think about the code to find the correct fix"? so, like, why are you guessing right now? :) -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
Andrea Arcangeli wrote:
> Said that if your compiler puts the read before the spin_lock without the
> memory clobber, it is allowed to do that, and in such case you would proof
> it was a real world bug (not just a "documentation" one).
Yes, it does.
> Or maybe your testcase was a bit different then mine, in such case please
> send it to me (I'm curious indeed :).
int *p;
int func()
{
int x = *p;
__asm__ __volatile ("zzz" : :);
x = *p;
return x;
}
In output:
.ident "GCC: (GNU) 2.96 2724 (experimental)"
>From the Red Hat 7 beta.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was
On Thu, 7 Sep 2000, Jamie Lokier wrote: >Well, now GCC does CSE across "asm" and will eliminate memory loads, What is "CSE"? Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>int *p;
>int func()
>{
> int x;
> x = *p;
> __asm__ __volatile__ ("" : : : "memory");
> x = *p;
> return x;
>}
>
Defintely none difference here (-fstrict-aliasing doesn't change anything
either).
andrea@inspiron:~ > gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
Linus Torvalds wrote:
> Nope. "memory" fills that role too. Remember: "memory" doesn't actually
> say "this clobbers all memory". That would be silly: an asm that just
> wipes all memory would not be a very useful asm (or rather, it would have
> just _one_ use: "execve()"). So "memory" really says that the asm clobbers
> _some_ memory.
>
> Which in turn means that the code scheduler has to synchronize all memory
> accesses around it - as if the asm was reading all memory. Because if the
> scheduler would move a store to after the asm, it would give the wrong
> results if the asm happened to clobber _that_ memory. And the scheduler
> obviously cannot just drop the store ("Oh, the asm will clobber this
> anyway"), because it doesn't know which memory regions get clobbered.
There are other reasons why stores can be eliminated, and "memory" does
not prevent those.
Example: you have two stores to the same address. An "asm" with
"memory" is in between the stores.
The first store can still be dropped, even though we don't know _which_
memory the "memory" clobbers.
Now, "memory" may well mean "this asm is considered to read some memory
and clobber some memory". But that's not what the manual says, and it
would be inconsistent with other kinds of clobber.
> Now, the fact that the "memory" clobber also seems to clobber local
> variables is a bug, I think.
If you are thinking of my examples, "memory" doesn't clobber local
variables. It does affect the scheduling of reads from general memory
into a local variable.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: linux kernel TCP, network connections and iptables
On Thu, 07 Sep 2000, George Athanassopoulos wrote: Possibly post this message on the netfilter mailing list. [EMAIL PROTECTED] Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
On Tue, 5 Sep 2000, Jeff V. Merkey wrote: > Ingo Molnar wrote: > > > Your arguments are personal, not technical. [...] > > > > no, my arguments are technical, but are simply focused towards the > > conceptual (horizontal) development of Linux, not the vertical > > development of Linux (drivers) and support issues. > > They seem focused on keeping us in the dark ages. We need tools to make > it faster and easier for folks to perform kernel development and make > field support of Linux easier. tools can sometimes bring the dark ages faster than anything else. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Interestingly enough, the local variable case is one where "memory" does
>make a difference. Without "memory":
>
>movlp, %eax
>movl(%eax), %eax
>#APP
>#NO_APP
>
>With "memory":
>
>#APP
>#NO_APP
>movlp, %eax
>movl(%eax), %eax
My gcc doesn't make differences between "memory" and non "memory" in this
testcase:
int * p;
extern f(int);
main()
{
int a;
a = *p;
__asm__ __volatile__("zzz" : :);
a = *p;
f(a);
}
My compiler _always_ produced first the zzz and then it loads p
(regardless of "memory" clobber or not). That's why I said I couldn't
reproduce miscompilations.
>As you can see from above, there are cases where
>
> local_var = shared->mumble;
> // ...
^^
> spin_lock (&spinlock);
> local_var = shared->mumble;
>
>requires a "memory" clobber, otherwise the second read, which is in a
>critical region, won't be emitted by the compiler.
In your testcase have only `//' in the underlined line, so the compiler is
100% allowed to throw away the first read to local_val, so far so good.
So the compiler does only one read from the `p' pointer and on with my
compiler it's always done _after_ the spin_lock (or after the __asm__
__volatile__ in the above testcase).
Of course "memory" should enforce the read to be done after the spin_lock
but in real life it seems to do the right thing anyway and I couldn't
reproduce miscompilation.
Said that if your compiler puts the read before the spin_lock without the
memory clobber, it is allowed to do that, and in such case you would proof
it was a real world bug (not just a "documentation" one).
Or maybe your testcase was a bit different then mine, in such case please
send it to me (I'm curious indeed :).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
Jeff, please read Linus' mail for an explanation about the dangers of kernel debuggers. Ingo On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > > Ingo, > > KDB is a user mode debugger designed to debug user space apps that's > been hacked to run with a driver. It's not designed as a kernel level > debugger and in real world situations has tons of shortcomings period. > If someone is working on a car, do they use a wrench, or just pry the > bolts loose with their teeth? All this "We don' need better tools > because we are real men" crap I've seen on the list is absurd. Try > taking a tire off a car with a lug wrench. It's tough. But if you have > an air socket wrench, like professional auto garage's use, the tire is > off in under 30 seconds, as opposed to 15 minutes if you do it by hand. > The whole point here is putting the best kernel level tools in possible > makes development go way faster, and makes it funner. > > :-) > > Jeff > > Ingo Molnar wrote: > > > > On Tue, 5 Sep 2000, Richard Gooch wrote: > > > > > Would you classify IKD as a pile of warts you wouldn't want to see in > > > the kernel? > > > > the quality of IKD is IMO excellent ( having written parts of it), > > yet i wouldnt want to see it in the kernel. That having said, i *did* > > author and integrate one of the IKD subsystems into the mainstream kernel > > - the NMI oopser on SMP systems. If a debugging aid is localized then > > there are no source-code health issues. In the case of the NMI-oopser the > > case was even clearer: nor a developer, nor a user can do anything useful > > with a hard lockup, apart from complaining that it 'locked up'. We clearly > > needed more information than that. > > > > KDB is not a code health issue either, it's quite localized. But KDB has > > the other bad social side-effect David was talking about, it promotes > > band-aids. So it's a tough call IMO. > > > > but the other IKD components, like the soft lockup detector, kernel > > tracer, leak detector and other goodies, are clearly intrusive. It's > > also a pain (and distraction) to 'drag' all that functionality along > > in a developer kernel - i'm sure Mike can attest to that, IDK is > > frequently broken by lowlevel changes. > > > > > Surely there must be some useful features that can be included in the > > > kernel without uglyfing it or slowing it down (configed > > > out)? [...] > > > > sure, and we have a number of them included already. And we rutinely > > include debugging facilities along newly rewritten code (witness the > > spinlock debugging helpers, the waitqueue and highmem debugging helpers, > > the io.h debugging helper). These things do get removed rutinely though. > > (maybe except the spinlock.h stuff - IMO we still have too much flux in > > the SMP code.) > > > > it's always a matter of balancing - we have multiple conflicting > > requirements. One factor in judging a debugging facility is the frequency > > and difficulty of bugs it detects. If a bug doesnt happen often and is > > easy to analyze then we need no debugging facility for it. Another factor > > is the impact of the patch on the kernel proper - memleak for example is > > extremely intrusive. Yet another factor is the maintainance 'drag' on the > > generic kernel (this is an issue even if the subsystem itself is > > localized) - eg. the mcount() debugging aids (on which several IKD > > features are based) periodically caused merging problems in the x86 arch, > > and they will continue causing problems once we implement fast-syscalls on > > x86. I'm happy that Mike and Andrea are maintaining IKD - but we dont want > > to force this maintainance overhead on Linus. Plus the social factors > > mentioned by David and Alexander. There are easy decisions and there are > > hard decisions. KDB is IMO not an easy call. > > > > Ingo > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was
[EMAIL PROTECTED] wrote: > Just hint. I remember the time when "memory" clobber option > was _absent_ in gcc. And we managed to compile kernel with such gcc. 8) > To all that I understand, "asm" (like function calls) implied barrier > that time and constraints and clobber option were used only for > register allocation and reloading. Well, now GCC does CSE across "asm" and will eliminate memory loads, even though it may not move them! I suspect it always did CSE across "asm" and we just never got hit by the bug. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
modules_install?
What's the point of running depmod at the end of modules_install? The System.map doesn't contain any versioned symbols so it just bitches about everything as being undefined. (depmod needs a "-i" to temporarily ignore versioning and it still bitches) And looking at the System.map is a bad way to judge missing symbols -- unless depmod knows to look for the exported tags. And what's up with the explosion of directories? People bitch because things aren't being divided up -- everything pilling up in misc. Other's bitch in favor of a flat directory. And the answer is this?!? I'm all for organization and the removal of the intermidary "symlink farm", but this is INSANE. (did I miss a memo or something?) Hmm, /lib/modules//kernel/fs/*... only ONE directory has more than one file in it and it (nls) _isn't_ a file system. --Ricky PS: Gez, the linux build system has become the largest pile of rotting spaghetti I've ever seen. (It's like watching the old Spam Cam.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Availability of kdb
Timur Tabi wrote: > Well, if it really is just his hobby, then he shouldn't be chanting > the "World Domination" mantra. Why not? World Domination is my hobby too :-) -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
Linus Torvalds wrote:
> Change it to something like
>
> __asm__("":"=r" (x):"0" (x));
>
> and the "volatile" should matter.
Yes it does. Without "volatile", the asm disappears :-)
> Not for memory references, perhaps. But for the movement issues.
The compiler isn't moving memory references around "asm volatile", but
it is doing CSE around them to _eliminate_ memory references.
Thus spin_lock needs the memory clobber, to prevent CSE of non-volatile
memory references between the critical region and outside the critical
region.
Maybe spin_unlock doesn't need one because CSE doesn't work the other
way. (I'd put that clobber in anyway, to be sure).
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
I loose track at times Stephen -- sorry. I was talking about kgdb with this statement. :-) Jeff "Stephen C. Tweedie" wrote: > > Hi, > > On Wed, Sep 06, 2000 at 09:44:54AM -0600, Jeff V. Merkey wrote: > > > > KDB is a user mode debugger designed to debug user space apps that's > > been hacked to run with a driver. > > Absolutely not true. You're probably thinking about kgdb, the gdb > stub for remote kernel source level debugging. > > kdb is a dedicated low-level kernel debugger. It hasn't been > "hacked". It was never designed for user space. It doesn't do > source-level debugging, though --- it's very much a low-level > poke-around-the-kernel tool. > > Cheers, > Stephen > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Thu, 7 Sep 2000, Jamie Lokier wrote: > > It's ok for the compiler to do that (given we don't know what "volatile" > means anyway :-). But it does have implications for spin_lock: > spin_lock must say that it clobbers memory. Yup. We should just fix that. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Crash] 2.4.0-test7
On Sun, Sep 03, 2000 at 02:59:43PM +0200, Pauline Middelink wrote: > > Anyway, linux-2.4.0-test7 wont boot on a Cyrix computer. > test6 has no problems whatsoever and 7 stops right after > 'Uncompressing kernel...' > > Kernel as always compiled for 586. > > Sounds familiar? Any solutions/tips? > > # > # Processor type and features > # > # CONFIG_M386 is not set > # CONFIG_M486 is not set > CONFIG_M586=y > # CONFIG_M586TSC is not set > # CONFIG_M586MMX is not set > # CONFIG_M686 is not set > # CONFIG_M686FXSR 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_X86_WP_WORKS_OK=y > CONFIG_X86_INVLPG=y > CONFIG_X86_CMPXCHG=y > CONFIG_X86_BSWAP=y > CONFIG_X86_POPAD_OK=y > CONFIG_X86_L1_CACHE_BYTES=32 > CONFIG_X86_USE_STRING_486=y > CONFIG_X86_ALIGNMENT_16=y > # 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 > It *sounds* very familiar. From Documentation/Configure.help: Processor family CONFIG_M386 This is the processor type of your CPU. This information is used for optimizing purposes. In order to compile a kernel that can run on all x86 CPU types (albeit not optimally fast), you can specify "386" here. The kernel will not necessarily run on earlier architectures than the one you have chosen, e.g. a Pentium optimized kernel will run on a PPro, but not necessarily on a i486. Here are the settings recommended for greatest speed: - "386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI 486DLC/DLC2, UMC 486SX-S and NexGen Nx586. Only "386" kernels will run on a 386 class machine. - "486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S. - "586" for generic Pentium CPUs, possibly lacking the TSC (time stamp counter) register. - "Pentium-Classic" for the Intel Pentium. - "Pentium-MMX" for the Intel Pentium MMX. - "Pentium-Pro" for the Intel Pentium Pro/Celeron/Pentium II. - "Pentium-III" for the Intel Pentium III. - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D). - "Athlon" for the AMD Athlon (K7). - "Crusoe" for the Transmeta Crusoe series. - "Winchip-C6" for original IDT Winchip. - "Winchip-2" for IDT Winchip 2. - "Winchip-2A" for IDT Winchips with 3dNow! capabilities. If you don't know what to do, choose "386". According to this, it looks like you should be building for (I presume) a 486. PGP signature
Re: Screen corruption on startup 2.4.0-test7
On Wed, Sep 06, 2000 at 04:13:50PM -0400, James Simmons wrote: > > > > > What video driver are you using? Fbcon or vgacon? If Fbcon which fbdev > > > driver in particular? > > > > > This would be vgacon, having never figured out if it's even possible > > to get framebuffers working on the machine. > > > > Also, the normal power-saving/screen-saving function of blanking the > > screen is not working. > > Vgacon !!! Have you tried putting that video card in another machine and > testing the same kernel? Trust me. When I was a sys admin the first thing > we did was swap hardware into another machine to see if it was a hardware > problem. > A further follow-up to my previous response to this... Now I have rebooted the old laptop under 2.2.17. It was pretty ugly. I suspect (because this is what I've seen with incarnations of this problem in previous versions) that the video hardware was still upset with whatever happened with 2.4.0-test7. A full shutdown/power off and reboot cleared the problem. Note that this problem has only appeared after rebooting from a 2.3.x or 2.4.0-testx kernel without a full power down. As long as I never bring up a newer kernel AND do a shutdown -r, I don't have this problem. I'm a little puzzled that my previous response hasn't appeared on this list yet but I've seen long delays before so I guess I shouldn't be too alarmed. Basically, it came down to noting that it's difficult to move a video card from a laptop and that the problem seemed to have gone away after I rebooted to 2.2.16 (though I recall now seeing some corruption while it was booting, but nothing like the full-scale lockout I had with 2.4.0-test7) -- the keyboard was usable under 2.2.16. -- David Benfell [EMAIL PROTECTED] ICQ 59438240 [e-mail first for access] --- There are no physicists in the hottest parts of hell, because the existence of a "hottest part" implies a temperature difference, and any marginally competent physicist would immediately use this to run a heat engine and make some other part of hell comfortably cool. This is obviously impossible. -- Richard Davisson [from fortune] PGP signature
Re: Question: slow network performance between Linux and Solaris 7
Hello! > installed RH6.2 with Linux kernel 2.2.16 on my Dell laptop (P3-500, > 256MB RAM). One thing that I found is the networking performance > between this Linux box and all my Solaris 7 based servers are very very > slow. Make tcpdump before all. > least 1000K/s, normally 3000k/s. Something is broken too. It should be >11MB/sec. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Screen corruption on startup 2.4.0-test7
On Wed, Sep 06, 2000 at 04:13:50PM -0400, James Simmons wrote: > > > > What video driver are you using? Fbcon or vgacon? If Fbcon which fbdev > > > driver in particular? > > > > > This would be vgacon, having never figured out if it's even possible > > to get framebuffers working on the machine. > > > > Also, the normal power-saving/screen-saving function of blanking the > > screen is not working. > > Vgacon !!! Have you tried putting that video card in another machine and > testing the same kernel? Trust me. When I was a sys admin the first thing > we did was swap hardware into another machine to see if it was a hardware > problem. > This is a laptop. The video chipset is Neomagic 2160. The problem reappeared with a reboot but disappeared when I went back to 2.2.16. I've built 2.2.17 for it but haven't gotten around to rebooting it to see how that goes. -- David Benfell [EMAIL PROTECTED] ICQ 59438240 [e-mail first for access] --- There are no physicists in the hottest parts of hell, because the existence of a "hottest part" implies a temperature difference, and any marginally competent physicist would immediately use this to run a heat engine and make some other part of hell comfortably cool. This is obviously impossible. -- Richard Davisson [from fortune] PGP signature
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>
> ps. There is a _clobber_ for memory, but no way to say "this asm _reads_
> arbitrary memory". __volatile__ may be filling that role though.
Nope. "memory" fills that role too. Remember: "memory" doesn't actually
say "this clobbers all memory". That would be silly: an asm that just
wipes all memory would not be a very useful asm (or rather, it would have
just _one_ use: "execve()"). So "memory" really says that the asm clobbers
_some_ memory.
Which in turn means that the code scheduler has to synchronize all memory
accesses around it - as if the asm was reading all memory. Because if the
scheduler would move a store to after the asm, it would give the wrong
results if the asm happened to clobber _that_ memory. And the scheduler
obviously cannot just drop the store ("Oh, the asm will clobber this
anyway"), because it doesn't know which memory regions get clobbered.
Now, the fact that the "memory" clobber also seems to clobber local
variables is a bug, I think. Or at least a misfeature. It should not be
considered to clobber reloads, as those are really in "registers" - at
least as far as the asm is concerned (the compiler could have chosen to
just allocate a hard register to that local variable or argument).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
Linus Torvalds wrote:
> "volatile" should be equivalent to clobbering memory, although the gcc
> manual pages are certainly not very verbose on the issue.
It isn't. Try the following with/without the memory clobber:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : : "memory");
x = *p;
return x;
}
With or without, the program reads *p only once. However, with the
clobber it reads _after_ the asm; without, it reads _before_ the asm.
It's ok for the compiler to do that (given we don't know what "volatile"
means anyway :-). But it does have implications for spin_lock:
spin_lock must say that it clobbers memory.
spin_unlock should also say it clobbers memory but I have no test case
to demonstrate the compiler moving reads down past an asm.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
PCMCIA: cardmgr only reads one socket under 2.4.0-test7
Hello, I have a Compaq Armada 7400 running Mandrake 7.0 with the kernel 2.4.0-test7 and the pcmcia-3.1.19. I have two PCMCIA sockets in my system and only one seems to work. I can read the following information in the /var/log/messages: pcmcia: Linux PCMCIA Card Services 3.1.11 kernel: options: [pci] [cardbus] [pm] kernel: modules kernel: Yenta IRQ list 0698, PCI irq11 kernel: Socket status: 3020 kernel: Yenta IRQ list 0698, PCI irq11 kernel: Socket status: 3006 kernel: cs: cb_alloc(bus 2): vendor 0x10b7, device 0x5257 kernel: PCI: Enabling device 02:00.0 ( -> 0003) kernel: PCI: No IRQ known for interrupt pin A of device 02:00.0 pcmcia: cardmgr. cardmgr[386]: starting, version is 3.1.11 cardmgr[386]: watching 1 sockets Does it mean only socket 0 is activated ? If yes, why the socket 1 is not activated ? I have a 3CCFE575CT in the socket 0 and nothing in the socket 1. If I insert another card in the socket 1, nothing is detected, nothing happens... I have also two occurences of the [CardBus Watcher] kernel thread. Is this OK ? The cardctl reports me status and ident only for socket 0. If somebody can help me, please, let me now. Thanks a lot, Claude. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote: >BTW Look also into asm-i386/bitops.h and dummy cast to some crap there. >Are you impressed? 8) Yep 8). If we add "memory" such stuff could be removed I think. As far I can see the object of such stuff is to cause gcc to say `I'm too lazy to see exactly what memory this guy is trying to change, so just assume he added "memory" in the clobber list' :)) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux kernel TCP, network connections and iptables
Hello! > - Could there be some kind of handling for such packets (meaning TCP packets > reaching at an unused port with ACK bit set - with no previous SYN etc packet) > to avoid such DoS attacks? Is the same happening to newer kernels? If yes, > should we just eat it and shut up (because that's the way TCP works and it > will not change)? TCP MUST do this and this cannot be changed. > - To do something about the above DoS,... By any _formal_ criteria there is no DoS here. You reply with one packet to each incoming packet and do not hold any state. Where is DoS? Note, that as soon as you will try to remember state, you open way for true DoSes. 8) Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
Andrea Arcangeli wrote:
> >>int a = *p;
> >>__asm__ __volatile__("" : :);
> >>a = *p;
> >>
> >> (to do two explicit reads)
> >
> >Sorry, that does just one read, kgcc (old stable gcc) and also with
> >gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
>
> I wrote the above not just as a complete testecase, but just to mean what
> the case I was talking about. You made int a a local variable and the
> thing you noticed is an otimization that the compiler is allowed to do
> regardless of the "memory" clobber too (`int a' have to be at least extern
> otherwise the compiler understands the first read can go away).
Interestingly enough, the local variable case is one where "memory" does
make a difference. Without "memory":
movlp, %eax
movl(%eax), %eax
#APP
#NO_APP
With "memory":
#APP
#NO_APP
movlp, %eax
movl(%eax), %eax
> Try to add "memory" as clobber to the above testcase and nothing will
> change. (that's what I meant in my previous email saying that even w/o
> "memory" things got compiled right at least in my simple testcases)
As you can see from above, there are cases where
local_var = shared->mumble;
// ...
spin_lock (&spinlock);
local_var = shared->mumble;
requires a "memory" clobber, otherwise the second read, which is in a
critical region, won't be emitted by the compiler.
-- Jamie
ps. There is a _clobber_ for memory, but no way to say "this asm _reads_
arbitrary memory". __volatile__ may be filling that role though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Thu, 7 Sep 2000, Jamie Lokier wrote:
> asm *__volatile__* seems to make no difference. I've tried a few things.
>
> Andrea Arcangeli wrote:
> > Maybe we can rely on the __volatile__ statement of the asm that will
> > enforce that if we write:
> >
> > *p = 0;
> > __asm__ __volatile__("" : :);
> > *p = 1;
> >
> > in the assembler we'll then find both a write of 0 and then a write of 1
> > to memory.
>
> That does 2 writes with gcc-2.96 and also egcs-2.91.66/19990314
> (Red Hat's kgcc), with or without -fstrict-aliasing.
>
> It also does 2 writes without __volatile__.
Your test is broken.
Read the gcc documentation. A inline asm with no outputs is implicitly
considered volatile. So _both_ your tests had volatile there.
Now, that may not matter that much fo ryour test-case: gcc gets careful
around inline asm anyway, even without the volatile.
Change it to something like
__asm__("":"=r" (x):"0" (x));
and the "volatile" should matter.
Not for memory references, perhaps. But for the movement issues.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test8-pre6] misc fixes
the "vm_mm->mm" was of course a typo and should be read as "vma->vm_mm". Sorry. On Thu, 7 Sep 2000, Tigran Aivazian wrote: > On Thu, 7 Sep 2000, Tigran Aivazian wrote: > > > On Thu, 7 Sep 2000, Linus Torvalds wrote: > > > > > > > > > > > On Thu, 7 Sep 2000, Tigran Aivazian wrote: > > > > > > > > k) all swapout functions in mm/vmscan.c can be optimized by removing 'mm' > > > >argument. This part was reviewed by Rick van Riel and approved. > > > > > > But they then get "mm" themselves anyway. > > > > > > What's the point? With argument passing, on certain architectures it stays > > > in registers. On other architectures it is in memory on the stack, but > > > that's not slower than accessing it from memory off another pointer. > > > > > > Linus > > > > Linus, I am sorry to say this (because I know you are busy) but it would > > appear you didn't look at the patch (that part of it). The patch does the > > right thing, I believe, but my description was too brief. > > > > If you look at those functions you will see that they sometimes access > > 'mm' via argument and sometimes via vm_mm->mm - this is a complete mess so > > my patch tidies it up a bit. > > > > In other words, if that 'mm' is available via vm_mm->mm there is no point > > in passing it on the stack. Or if we pass it on the stack, there is no > > point accessing it via vm_mm->mm. See my point now? > > in case, even this is too brief, here is more: > > ... so, I had a choice between: > > a) remove 'mm' argument > > or > > b) make all access to 'mm' go via this 'mm' argument > > and I thought removing the argument, i.e. choice a) was better than b). > > And, yes, I do understand how arguments are passed and what gcc can do > about it. > > Regards, > Tigran > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells <[EMAIL PROTECTED]> said: [...] > Anyway, I though I could get away with it, but on reflection, perhaps > not... If two threads of the same process try and issue ReleaseMutex() > simultaneously on one mutex, then theoretically, one should succeed and the > other fail, but given the above code, you are right... there would be a > race. Lost me there. If after releasing the mutex it is free, the release was sucessful AFAIAC. If two threads try to do it at the same time, so what? Releasing an already free mutex is broken, OK. But two threads owning the mutex at the same time is much worse... -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DAC960 SMP deadlock fix
On Thu, 7 Sep 2000, Andi Kleen wrote:
>On Thu, Sep 07, 2000 at 09:00:29AM -0700, Leonard N. Zubkoff wrote:
>> WaitQueue_T WaitQueueEntry = { current, NULL };
>> add_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
>> current->state = TASK_UNINTERRUPTIBLE;
>> spin_unlock(&io_request_lock);
>> schedule();
>> current->state = TASK_RUNNING;
>> remove_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
>> spin_lock_irq(&io_request_lock);
>>
>> Is the fix simply moving the spin_unlock right before the call to
>> add_wait_queue?
>
>When you do that you should probably change it to a spin_unlock_irq()
I didn't changed that because not doing __sti() is faster, because
schedule() waste time doing an __sti() unconditionally. By the time we'll
remove sti() from schedule() we'll add a debugging code that check the IF
in the CPU is disabled and that BUG in that case (and that won't happen
before 2.5.x when all the sleep_on will die).
However if you want to replace it with a spin_unlock_irq(&io_request_lock)
in prevision to the possible removal of sti() from schedule() go ahead :).
It's just not necessary right now (and I only addressed the deadlock
condition with the patch).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test8-pre6] misc fixes
On Thu, 7 Sep 2000, Tigran Aivazian wrote: > On Thu, 7 Sep 2000, Linus Torvalds wrote: > > > > > > > On Thu, 7 Sep 2000, Tigran Aivazian wrote: > > > > > > k) all swapout functions in mm/vmscan.c can be optimized by removing 'mm' > > >argument. This part was reviewed by Rick van Riel and approved. > > > > But they then get "mm" themselves anyway. > > > > What's the point? With argument passing, on certain architectures it stays > > in registers. On other architectures it is in memory on the stack, but > > that's not slower than accessing it from memory off another pointer. > > > > Linus > > Linus, I am sorry to say this (because I know you are busy) but it would > appear you didn't look at the patch (that part of it). The patch does the > right thing, I believe, but my description was too brief. > > If you look at those functions you will see that they sometimes access > 'mm' via argument and sometimes via vm_mm->mm - this is a complete mess so > my patch tidies it up a bit. > > In other words, if that 'mm' is available via vm_mm->mm there is no point > in passing it on the stack. Or if we pass it on the stack, there is no > point accessing it via vm_mm->mm. See my point now? in case, even this is too brief, here is more: ... so, I had a choice between: a) remove 'mm' argument or b) make all access to 'mm' go via this 'mm' argument and I thought removing the argument, i.e. choice a) was better than b). And, yes, I do understand how arguments are passed and what gcc can do about it. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Availability of kdb
** Reply to message from "J. Dow" <[EMAIL PROTECTED]> on Thu, 7 Sep 2000 02:50:37 -0700 > Aw, Tigran, give the kid his hobby, OK? We can try to bang some > sense into his head and suggest ways his hobby could offer more > satisfaction from good results achieved and make it more fun for > the rest of us. But this IS his model train setup we're playing on. So > in the final analysis he gets to choose the means of train control we > use and everything else, as well. Well, if it really is just his hobby, then he shouldn't be chanting the "World Domination" mantra. Either Linux belongs to Linus, in which case it's irrelevant outside his personal world, or it is a tool for all computer users. If Linus really doesn't care who uses his OS, then he should not be encouraging community participation, and he shouldn't be accepting speaking engagements at major conventions where business users attend to decide whether Linux is for them or not. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was
Hello! > tried to grep gcc but my gcc knowledge is too low to reverse engeneer the > implement semantics of the "memory" clobber fast Just hint. I remember the time when "memory" clobber option was _absent_ in gcc. And we managed to compile kernel with such gcc. 8) To all that I understand, "asm" (like function calls) implied barrier that time and constraints and clobber option were used only for register allocation and reloading. Alexey BTW Look also into asm-i386/bitops.h and dummy cast to some crap there. Are you impressed? 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>asm *__volatile__* seems to make no difference. I've tried a few things.
It makes a difference, see below.
>
>Andrea Arcangeli wrote:
>> Maybe we can rely on the __volatile__ statement of the asm that will
>> enforce that if we write:
>>
>> *p = 0;
>> __asm__ __volatile__("" : :);
>> *p = 1;
>>
>> in the assembler we'll then find both a write of 0 and then a write of 1
>> to memory.
>
>That does 2 writes with gcc-2.96 and also egcs-2.91.66/19990314
>(Red Hat's kgcc), with or without -fstrict-aliasing.
>
>It also does 2 writes without __volatile__.
>
>> int a = *p;
>> __asm__ __volatile__("" : :);
>> a = *p;
>>
>> (to do two explicit reads)
>
>Sorry, that does just one read, kgcc (old stable gcc) and also with
>gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
I wrote the above not just as a complete testecase, but just to mean what
the case I was talking about. You made int a a local variable and the
thing you noticed is an otimization that the compiler is allowed to do
regardless of the "memory" clobber too (`int a' have to be at least extern
otherwise the compiler understands the first read can go away). Try this:
int * p;
int a;
extern f(int);
main()
{
a = *p;
__asm__ __volatile__("zzz" : : );
a = *p;
f(a);
}
Try to add "memory" as clobber to the above testcase and nothing will
change. (that's what I meant in my previous email saying that even w/o
"memory" things got compiled right at least in my simple testcases)
>Again, __volatile__ makes no difference.
Note that __volatile__ really makes a difference if for example you
speficy as output an operand that isn't used anymore.
Try this:
main()
{
int a;
__asm__("zzz" : "=r" (a));
}
and then this:
main()
{
int a;
__asm__ __volatile__("zzz" : "=r" (a));
}
--- p.s.nonvolatile Thu Sep 7 18:05:30 2000
+++ p.s Thu Sep 7 18:05:53 2000
@@ -6,10 +6,13 @@
.globl main
.typemain,@function
main:
pushl %ebp
movl %esp,%ebp
+#APP
+ zzz
+#NO_APP
movl %ebp,%esp
popl %ebp
ret
.Lfe1:
.sizemain,.Lfe1-main
>I cannot tell from the GCC manual whether either of these behaviours is
>correct or not.
The behaviour of what you described is definitely correct/safe.
My only wondering was about "memory" non-"memory" as clobber because gcc
was doing things right just with the __asm__ __volatile__ thing w/o
"memory" as clobber. However I had the confirm my worries was right and
that "memory" is needed for all the spinlocks.
BTW, we had a bug in the alpha port last month in the
linux/include/asm-alpha/fpu.h:wrfpcr() function, read it for a real world
example of where __volatile__ must be used.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: DAC960 SMP deadlock fix
On Thu, 7 Sep 2000, Leonard N. Zubkoff wrote:
>I tried retrieving that file but was unsuccessful; is that the correct URL?
I guess I cut and pasted too much directories, sorry. I attached the file
since it's small.
>Is the fix simply moving the spin_unlock right before the call to
>add_wait_queue?
A little more, we also have to make sure not to miss events and the
__wait_event interfaces addersses that second issue.
>I should be able to release a new driver very shortly with such a fix; I
>just have one or two other minor nits I'm finishing up.
Good, thanks!
Andrea
After reading the two NMI dumps and the assembler of the .text.lock
section of the vmlinux ELF image I think I found it.
It seems a regular SMP lock inversion in the DAC960 driver that is
acquiring the waitqueue_lock with the io_request_lock still acquired. Here
the trace that I deducted:
CPU0CPU1
-- ---
spin_lock_irqsave(&io_request_lock)
DAC9xx_request_fn()
wake_up(something...)
read_lock(&waitqueue_lock)
aic7xxx_irq_handler()
DAC9xx_WaitForCommand()
add_to_wait_queue(something)
write_lock_irqsave(&waitqueue_lock)
/* hanging because of the read_lock
on the other side */
spin_lock_irqsave(&io_request_lock)
/* hanging because it's
acquired from the other
side */
/* DEADLOCK */
Here the fix (uncompiled and untested):
--- 2.2.18pre2aa2/drivers/block/DAC960.cWed Aug 30 03:42:29 2000
+++ /tmp/DAC960.c Thu Sep 7 02:10:39 2000
@@ -310,13 +310,8 @@
static void DAC960_WaitForCommand(DAC960_Controller_T *Controller)
{
- WaitQueue_T WaitQueueEntry = { current, NULL };
- add_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
- current->state = TASK_UNINTERRUPTIBLE;
spin_unlock(&io_request_lock);
- schedule();
- current->state = TASK_RUNNING;
- remove_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
+ __wait_event(Controller->CommandWaitQueue, Controller->FreeCommands);
spin_lock_irq(&io_request_lock);
}
PCMCIA: 3CCFE575CT initialization probem under 2.4.0-test7
Hello,
I am using a 3CCFE575CT with a Compaq Armada under the kernel 2.4.0-test7
and pcmcia-3.1.19. I am running Mandrake 7.0. The problem concerns the
cardmgr and/or the 3c59x kernel module. When the pcmcia service starts, it
initializes the cardmgr, reads the sockets, installs the proper kernel
modules and runs the network configuration scripts if a network card is
found. I have modified the /etc/pcmcia/config by replacing all the 3c575_cb
strings by the 3c59x string. Then, the cardmgr was able to load the 3c59x
module instead of the 3c575_cb module for my 3CCFE575CT. When the network
scripts are run, I can read the following from the /var/log/messages and my
network configuration is not executed:
cardmgr[386]: executing: './network start 3c575_cb'
cardmgr[386]: + usage: ifup
cardmgr[386]: start cmd exited with status 1
Should not I read "./network start eth0" instead of "./network start
3c575_cb" ? It seems the kernel module is not giving the proper information
to the cardmgr or the cardmgr is not reading the good one from the 3c59x
kernel module. I have modified some code inside the 3c59x.c module. I have
changed "3c575_cb" to "eth0" in the next structure and I got the card to
work:
static struct pci_driver vortex_driver = {
name: "3c575_cb",
...
};
But, I guess this change is not good. It will only work for eth0... Please,
can you help me with that one ? BTW, the 3CCE589ET is working fine.
Many thanks for your support,
Claude.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test8-pre6] misc fixes
On Thu, 7 Sep 2000, Linus Torvalds wrote: > > > On Thu, 7 Sep 2000, Tigran Aivazian wrote: > > > > k) all swapout functions in mm/vmscan.c can be optimized by removing 'mm' > >argument. This part was reviewed by Rick van Riel and approved. > > But they then get "mm" themselves anyway. > > What's the point? With argument passing, on certain architectures it stays > in registers. On other architectures it is in memory on the stack, but > that's not slower than accessing it from memory off another pointer. > > Linus Linus, I am sorry to say this (because I know you are busy) but it would appear you didn't look at the patch (that part of it). The patch does the right thing, I believe, but my description was too brief. If you look at those functions you will see that they sometimes access 'mm' via argument and sometimes via vm_mm->mm - this is a complete mess so my patch tidies it up a bit. In other words, if that 'mm' is available via vm_mm->mm there is no point in passing it on the stack. Or if we pass it on the stack, there is no point accessing it via vm_mm->mm. See my point now? Regards, Tigran. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Error in fs/nls/Config.in in 2.2.18-pre3
On Thu, 7 Sep 2000, G. Hugh Song wrote: > if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ > -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ > -o "$CONFIG_SMB_FS" != n ]; then n vs "n" is my error. However 'make menuconfig' works with just n. I know I should have tested with all types of configs but I probably felt that make oldconfig and menuconfig was enough. make config seems happy too. > I simply thought putting n inside an double-quoting n would solve > the problem. But it did not. It should and does for me when I apply the patch below. Did you do something else? /Urban --- linux/fs/nls/Config.in.orig Thu Sep 7 18:12:43 2000 +++ linux/fs/nls/Config.in Thu Sep 7 18:12:56 2000 @@ -5,7 +5,7 @@ # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != n ]; then + -o "$CONFIG_SMB_FS" != "n" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Availability of kdb
Tigran Aivazian writes: > On Thu, 7 Sep 2000, George Anzinger wrote: > > I like this one better: > > > > "And I'm right. I'm always right, but in this case I'm just a bit more > > right than I usually am." -- Linus Torvalds, Sunday Aug 27, 2000. > > > > I like this one even better: > > "Little children, keep yourselves from idols" -- St John, Ist century. Hm. Does that apply also to all the statues of saints, the virgin mother and all those crosses with Jesus that you find in churches, hanging off people's necks and in some places on every street corner? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test8-pre6] misc fixes
On Thu, 7 Sep 2000, Tigran Aivazian wrote: > > k) all swapout functions in mm/vmscan.c can be optimized by removing 'mm' >argument. This part was reviewed by Rick van Riel and approved. But they then get "mm" themselves anyway. What's the point? With argument passing, on certain architectures it stays in registers. On other architectures it is in memory on the stack, but that's not slower than accessing it from memory off another pointer. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
[EMAIL PROTECTED] said: > > If there's other stuff on the run queue, it won't return immediately, > > will it? > It most likely will return immediately. Oh well in that case it ought to task its task to something other than TASK_RUNNING... > > Otherwise, it would be TASK_UNINTERRUPTIBLE. > UNINTERRUPTIBLE refers to being open to signals. Indeed. That's what I want. I should have phrased it a little better. "If I'm wrong about it not returning immediately, then it should be TASK_UNINTERRUPTIBLE" -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Weirdness in block device queues.
Doug Gilbert and I ran across some weirdness in the way the block device queues are plugged/unplugged. It turned up with some benchmarks of the SCSI generics driver - with the new queueing code, the generics driver is inserting requests into the same queue that block device requests are inserted. The oddness is this. We were observing stalls in the processing of commands that was traced to the fact that the queue had remained plugged for an excessive amount of time. The stalls last for about 5 seconds or so. Some investigation revealed that part of the answer is that the bdflush daemon essentially forces a bunch of dirty pages to be written to disk, but never bothers to unplug the queue when it is done. The result is that the queue remains plugged until someone else comes along and unplugs it. As it turns out, kupdate() does unplug the queue, and kupdate runs every 5 seconds or so. Patching bdflush to run tq_disk after flushing buffers (i.e. before the schedule()) fixed *most* of the problem, but evidently not all of it (Doug was still observing stalls, but a lot less frequently). In other words, there is someone else out there queueing requests in such a way that the queue can remain plugged for some amount of time. My gut tells me that it is wrong for bdflush to not unplug the queue when it is done queueing I/O requests. My gut also tells me that the generics driver probably wants to be unplugging the one specific queue that it is using to ensure that I/O gets queued right away (it doesn't make sense to unplug all queues in this instance). Comments? -Eric
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Thu, 7 Sep 2000, Andrea Arcangeli wrote: > On Mon, 4 Sep 2000, Andrea Arcangeli wrote: > > >barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber > >"memory". > > I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber > memory (it looks necessary to make sure the compiler doesn't delay to > write data to the memory out of the critical section). "volatile" should be equivalent to clobbering memory, although the gcc manual pages are certainly not very verbose on the issue. Adding a memory clobber certainly migth be a good idea. David, who knows what gcc actually does wrt "volatile"? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > So it seems to be a bug at least in terms of timing. Unfortunately I > > only got about 4 replies to the patches that touched 20+ drivers. I > > suppose I should just hassle maintainers until they fix it or tell me > > where I've gone wrong ... > > Actually, I was quite happy calling schedule_timeout in the flash drivers > without changing current->state. I'm waiting to something to happen, and > just to be considerate, I'm asking to be put to sleep for the 'expected' > amount of time for whatever's happening. If there's other stuff on the run > queue, it won't return immediately, will it? It most likely will return immediately. The only case it would not is if, while you were running: A tick happened and some other task in the run queue then had a higher count of remaining ticks, or Something event happened to cause the system to want to run some other task (i.e. need_resched is set) In no case will the system wait for anything related to the time you send to schedule_timeout() (which, I think should be called something like xxx_sleep(). >If there isn't other stuff on > the run queue, I'll just busy wait till the flash chip's finished. No you will _almost always_ busy wait. > > Otherwise, it would be TASK_UNINTERRUPTIBLE. UNINTERRUPTIBLE refers to being open to signals. A task waiting UNINTERRUPTIBLE can not be killed (or otherwise signaled) while it is waiting. Signals that come in against the task are just queued until the task allows them to be recognized (by exiting to user land or explicitly calling signal delivery (which very few code paths do)). By waiting INTERRUPTIBLE, the system will wake_up() the task when a signal is posted against it. The task still has to respond to it in one of the above two ways. For what it is worth, I think the system needs a "deliver_signal()" function just for this. I think that this function should have: a.) A "task being killed" call back function, so callers can clean up if the call is not going to return, but instead is killing the task. This would allow drivers to test for being killed as opposed to just being handed some other relatively unimportant signal and to clean up their act if needed. b.) An indication (return value) that tells if a user handler was called. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Andi Kleen <[EMAIL PROTECTED]> wrote:
> This is far from a single CPU instruction between the test_bit and the
> set_bit. Even with a single CPU instruction you would need a cmpxchg with
> retry BTW, to handle the case of multiple CPUs entering the instruction at
> the same time. The easiest fix is to add a spinlock per mutex.
>
> if (test_bit(0,&mutex->wm_state) || mutex->wm_owner!=filp) {
> ret = 0; /* false */
> } else {
> ret = 1;
> mutex->wm_owner = NULL;
> set_bit(0,&mutex->wm_state);
> SignalObject(obj,1);
> }
I see what you're getting at... (I was thinking of the mutex grab stage, not
the release stage).
Anyway, I though I could get away with it, but on reflection, perhaps
not... If two threads of the same process try and issue ReleaseMutex()
simultaneously on one mutex, then theoretically, one should succeed and the
other fail, but given the above code, you are right... there would be a race.
Between threads of different "processes" I don't think it'll actually be a
problem, since mutex theft isn't permitted. I also don't think there'll be a
conflict between grab and release, since the actual release is the last thing
done by the ReleaseMutex function, and the actual grab is the first thing done
by the MutexPoll function.
But you are right... It should be guarded anyway. Perhaps what I should do is
to use the owner field as the mutex (NULL is available) and use cmpxchgl to do
the grab _and_ the release.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: DAC960 SMP deadlock fix
On Thu, Sep 07, 2000 at 09:00:29AM -0700, Leonard N. Zubkoff wrote:
> WaitQueue_T WaitQueueEntry = { current, NULL };
> add_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
> current->state = TASK_UNINTERRUPTIBLE;
> spin_unlock(&io_request_lock);
> schedule();
> current->state = TASK_RUNNING;
> remove_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
> spin_lock_irq(&io_request_lock);
>
> Is the fix simply moving the spin_unlock right before the call to
> add_wait_queue?
When you do that you should probably change it to a spin_unlock_irq()
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Panic in 2.4.0-test7 with MP Configuration Table parsing
We had some problems booting 2.4.0-test7, and discovered that Linux fell into a panic while parsing the MP Configuration table. After some debugging, we found that there are 4 Busses entries: Bus #0 is PCI Bus #1 is PCI Bus #18 is XPRESS Bus #19 is EISA Unfortunately, the XPRESS bus parsing calls panic(), since unhandled. We just commented out the panic and the system went up as in 2.2.14. We are ready to submit a patch to make our MP-system (NCR S40) boot, but we do not know exactly what to do with such bus. BTW, do you think that it is the same bus as the X-Bus which supports RTC, Keyboard, Mouse and BIOS within a PCI bus ? Thanks in advance, -Eric +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE Web : http://www.ri.silicomp.com/~paire | Groupe SILICOMP - Research Institute Email: [EMAIL PROTECTED] | 2, avenue de Vignate Phone: +33 (0) 476 63 48 71 | F-38610 Gieres Fax : +33 (0) 476 51 05 32 | FRANCE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells writes: > I've done an implementation of some of the Win32 "system calls" > in a kernel module in an attempt to speed up Wine. Oh my. How dare you! I like it. :-) > The preliminary benchmarks that I made, while not very real-world > since I don't think I have managed to implement enough for that yet, > seem to indicate that in some tests, I can beat Win2000 by 20% on > syscall latency, and Wine by 900%. If you implement enough to run the common Windows benchmarks, we can have loads of fun. > Other methods that have been mentioned include persuading Linus to > reserve a syscall number specifically for this purpose, and having > the module supply a handler for it. If this stuff isn't too insane, just make it available for all software to use. That includes regular SPARC Linux executables, etc. Use a regular system call without a module. I suppose you ought to have a config option if this gets to be over 200 kB of bloat. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DAC960 SMP deadlock fix
Date: Thu, 7 Sep 2000 16:50:51 +0200 (CEST)
From: Andrea Arcangeli <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], Alan Cox <[EMAIL PROTECTED]>
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
Hi Leonard,
this night I (hopefully) finally spotted and fixed a longstanding deadlock
that was hitting us on heavily loaded server running the DAC960.
The bug is present also in the earlier 2.2.x and 2.4.x and it's _not_ been
introduced with the DAC960 updates in 2.2.17.
In 2.4.x the SMP deadlock can't trigger because of two reasons:
1) the waitqueue uses a per-queue spinlock and the driver always wakeup
the waitqueue with the io_request_lock acquired
2) the waitqueue lock in 2.4.x at the moment is a spinlock_t (thus
there isn't a __cli-less read_lock (no-irqsave) wake_up).
The bug triggers in 2.2.x because the waitqueue_lock is shard by all
waitqueues and the wake_up uses a read_lock (that can be interrupted by
irq handlers that can later spin on the io_request_lock).
The SMP locking rule that was not enforced by the driver and that was
causing the deadlock is:
"never run add_wait_queue with the io_request_lock acquired"
The reason of the rule is that the irq_request_lock can be acquired by
interrupt handlers as well.
The patch with a description of the problem is here:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre2/patches/v2.2/2.2.18pre2/DAC960-SMP-lock-inversion-1
I recommend adding the above fix to 2.2.18pre3.
Andrea
I tried retrieving that file but was unsuccessful; is that the correct URL?
As for the comments above, I expect you are right. I had originally used a
much simpler sleep_on implementation until Manfred Spraul pointed out an SMP
problem with that and suggested the alternative sequence the driver now uses.
Looking at DAC960_WaitForRequest, we have:
WaitQueue_T WaitQueueEntry = { current, NULL };
add_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
current->state = TASK_UNINTERRUPTIBLE;
spin_unlock(&io_request_lock);
schedule();
current->state = TASK_RUNNING;
remove_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
spin_lock_irq(&io_request_lock);
Is the fix simply moving the spin_unlock right before the call to
add_wait_queue?
I should be able to release a new driver very shortly with such a fix; I just
have one or two other minor nits I'm finishing up.
Leonard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
> Maybe we can rely on the __volatile__ statement of the asm that will
> enforce that if we write:
>
> *p = 0;
> __asm__ __volatile__("" : :);
> *p = 1;
>
> in the assembler we'll then find both a write of 0 and then a write of 1
> to memory.
That does 2 writes with gcc-2.96 and also egcs-2.91.66/19990314
(Red Hat's kgcc), with or without -fstrict-aliasing.
It also does 2 writes without __volatile__.
> int a = *p;
> __asm__ __volatile__("" : :);
> a = *p;
>
> (to do two explicit reads)
Sorry, that does just one read, kgcc (old stable gcc) and also with
gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
Again, __volatile__ makes no difference.
I cannot tell from the GCC manual whether either of these behaviours is
correct or not.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Thu, 7 Sep 2000, Franz Sirl wrote: >In short terms: > >- __volatile__ assures that the code isn't reordered against other >__volatile__ and isn't hoisted out of loops, nothing else >- the "memory" clobber makes sure the asm isn't reordered against other >memory accesses Ok. That's all I wanted to hear. So _definitely_ all spinlocks needs "memory" in the clobber list. I'll do a new patch reinserting "memory" in __sti and inserting "memory" also in the spin_unlock() case. The reason of my doubt was that I only got one agreement by Pavel and none other comment. Furthmore in practice there was no miscompilation thus I was wondering if I misunderstood the semantics of __volatile__ (but then of course I was asking myself what "memory" was good for :)) >Essentially, you _always_ have to tell the compiler if you touch memory >behind it's back, this includes inline assembly to flush the cache or the I understand this completly. And as said we can't do that with the spinlocks (at least with the current API to spin_lock and friends) thus we need "memory" in the clobber list. >General rule of thumb for inline assembly: > > Give the compiler as much information as possible!! > >If you know inline assembly read/writes memory, tell it to the compiler, as >detailed as possible! Indeed :). If we could teach all the memory changes to the inline assembly then "memory" wouldn't be necessary anymore into the clobber list. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[the end?] RE: Availability of kdb
On Thu, 7 Sep 2000, Mike Jagdis wrote: > > Q: Then why isn't kdb in the kernel? > > A: Uh... > > More to the point, why don't the people that want a kernel > debugger maintain kdb and simply drop in the patch when they > need it? If Jeff releases his debugger will anyone care enough > to maintain it? Less talk, more action methinks :-). Hmm.. my name is on the to line, so I guess that this is directed at me too? I have _no problem_ with Linus not liking/integrating KDB. I only suggested that it _could_ improve bug report quality and encourage folks to try to solve problems if it were integrated. I also pointed out that debuggers are readily available for those who want them. Now (having gotten the last word in) let's stop talking about something that's _not going to happen_ and chase down bugs so 2.4 _can_ happen :) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
"initial req->mss below 8"
Hi, In the past few days, a couple of our webservers (dual P3s) have started to emit $SUBJECT into the kernel logs fairly frequently: Sep 7 06:41:04 web2 kernel: initial req->mss below 8 Sep 7 06:56:03 web2 last message repeated 18 times Sep 7 07:56:04 web2 last message repeated 18 times Sep 7 08:41:03 web2 last message repeated 18 times Sep 7 08:56:04 web2 last message repeated 18 times Sep 7 09:26:03 web2 last message repeated 18 times Sep 7 09:41:03 web2 last message repeated 18 times Sep 7 10:41:04 web2 last message repeated 20 times Sep 7 10:56:04 web2 last message repeated 18 times Sep 7 11:41:11 web2 last message repeated 18 times Sep 7 12:41:02 web2 last message repeated 18 times Sep 7 13:11:03 web2 last message repeated 18 times Sep 7 13:26:03 web2 last message repeated 18 times Sep 7 13:41:05 web2 last message repeated 20 times Sep 7 13:56:04 web2 last message repeated 32 times Sep 7 14:41:03 web2 last message repeated 18 times Sep 7 14:56:02 web2 last message repeated 18 times Sep 7 14:56:02 web2 last message repeated 17 times Sep 7 15:11:04 web2 kernel: initial req->mss below 8 Sep 7 15:11:04 web2 last message repeated 17 times Sep 7 15:26:05 web2 kernel: initial req->mss below 8 Sep 7 16:26:04 web2 last message repeated 18 times The machines are running RH6.2's stock kernel (haven't found time to upgrade them yet). One has been up 35 days, the other 4 days. Should I be at all worried about the messages? The source around it suggests that it might have come from a dubious header field in a received packet. Is something sending us dodgy packets? Matthew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
At 17:03 07.09.00, Andrea Arcangeli wrote:
>On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>
> >barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
> >"memory".
>
>I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
>memory (it looks necessary to make sure the compiler doesn't delay to
>write data to the memory out of the critical section).
>
>And in practice I can't reproduce any corruption with any subtle testcase
>by removing "memory" from the clobber list of all the
>spinlocks/__sti/__cli, so it may be the other way around. Maybe we can
>rely on the __volatile__ statement of the asm that will enforce that if we
>write:
>
> *p = 0;
> __asm__ __volatile__("" : :);
> *p = 1;
>
>in the assembler we'll then find both a write of 0 and then a write of 1
>to memory. I'd say with the current compiler we can rely on it (infact the
>spinlock doesn't seems to get miscompiled at the moment even while they
>aren't clobbering "memory".
>
>Same with:
>
> int a = *p;
> __asm__ __volatile__("" : :);
> a = *p;
>
>(to do two explicit reads)
>
>If "memory" isn't necessary in spin_lock, then all the "memory" clobbers
>around include/*/* (also in mb() and __cli() and even barrier()) are not
>necessary. But then "why" we need a "memory" clobber in first place if the
>"memory" isn't necessary? :)) Also the gcc documentation seems to say we
>need "memory" in all such operations (also in __sti() and
>spin_unlock() unlike I said in my earlier email).
>
>I'd like if some compiler guy could comment (I got no one reply yet). I
>tried to grep gcc but my gcc knowledge is too low to reverse engeneer the
>implement semantics of the "memory" clobber fast (though I would
>appreciate a pointer in the gcc sources to start to understand some gcc
>code :).
In short terms:
- __volatile__ assures that the code isn't reordered against other
__volatile__ and isn't hoisted out of loops, nothing else
- the "memory" clobber makes sure the asm isn't reordered against other
memory accesses
Essentially, you _always_ have to tell the compiler if you touch memory
behind it's back, this includes inline assembly to flush the cache or the
write back queue. Since you usually don't know which part of the memory
gets touched, you need the global "memory" clobber. If you know which
addresses you touch, you can get away with something like this, from
asm-ppc/io.h:
extern inline unsigned in_be32(volatile unsigned *addr)
{
unsigned ret;
__asm__ __volatile__("lwz%U1%X1 %0,%1; eieio" : "=r" (ret) : "m"
(*addr));
return ret;
}
extern inline void out_le32(volatile unsigned *addr, int val)
{
__asm__ __volatile__("stwbrx %1,0,%2; eieio" : "=m" (*addr) :
"r" (val), "r" (addr));
}
General rule of thumb for inline assembly:
Give the compiler as much information as possible!!
If you know inline assembly read/writes memory, tell it to the compiler, as
detailed as possible!
Franz.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC] Wine speedup through kernel module
David Howells <[EMAIL PROTECTED]> schrieb / wrote am / at : 07.09.2000 16:25:29 > > Hold on a moment... You said "between the test bit and set bit"... this is a > single CPU instruction! With the lock prefix, there should be no between. > > Also, a quote from asm/bitops.h: > - /* > - * These have to be done with inline assembly: that way the bit-setting > - * is guaranteed to be atomic. All bit operations return 0 if the bit > - * was cleared before the operation and != 0 if it was not. > - * > - * bit 0 is the LSB of addr; bit 32 is the LSB of (addr+1). > - */ > > Doesn't "atomic" mean SMP safe? > > What's the point in the lock prefix if it doesn't make things SMP safe (after > all, the unadorned instructions are UP safe...)? The Pentium Processor manual (section 19) explicitly mentions the BTx instructions together with the LOCK prefix as an SMP save way to access semaphores. Bernhard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Thu, Sep 07, 2000 at 04:25:29PM +0100, David Howells wrote:
>
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> > But that's not race free on SMP. Two CPUs can set the bit in parallel
> > and you'll never notice. You would need at least a protecting spinlock
> > between the test bit and set bit (or a cmpxchg on x86)
>
> Are you sure? I understood that the "lock" prefix on a i386 made the
> instruction it guarded SMP safe.
>
> If not, I suppose I can use the xchg() macro instead.
>
> Hold on a moment... You said "between the test bit and set bit"... this is a
> single CPU instruction! With the lock prefix, there should be no between.
This is far from a single CPU instruction between the test_bit and the
set_bit. Even with a single CPU instruction you would need a cmpxchg with
retry BTW, to handle the case of multiple CPUs entering the instruction at
the same time. The easiest fix is to add a spinlock per mutex.
if (test_bit(0,&mutex->wm_state) || mutex->wm_owner!=filp) {
ret = 0; /* false */
} else {
ret = 1;
mutex->wm_owner = NULL;
set_bit(0,&mutex->wm_state);
SignalObject(obj,1);
}
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test* on alpha noritake
-test7 was the first one I tried that actually booted, the rest just froze. I only tried 2 kernels. The first was compiled with CONFIG_ALPHA_LEGACY_START_ADDRESS set to n, and the 2nd was with y. First was -test6 when booting -test7, it can't find any IRQs for the PCI devices. This is an AlphaServer 1000a 4/266 noritake. Only addon boards are: ISA modem, PCI tulip (original DEC 2114x) nic, 3com 3c905 nic, and a permedia 2v pci video. If this isn't the correct list, let me know which is. P.S. If anyone knows how to get an adaptec EISA aha-2742T card working on this thing, email me (not cc'd to list) Sorry, had to throw that in. -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Andi Kleen <[EMAIL PROTECTED]> wrote: > But that's not race free on SMP. Two CPUs can set the bit in parallel > and you'll never notice. You would need at least a protecting spinlock > between the test bit and set bit (or a cmpxchg on x86) Are you sure? I understood that the "lock" prefix on a i386 made the instruction it guarded SMP safe. If not, I suppose I can use the xchg() macro instead. Hold on a moment... You said "between the test bit and set bit"... this is a single CPU instruction! With the lock prefix, there should be no between. Also, a quote from asm/bitops.h: - /* - * These have to be done with inline assembly: that way the bit-setting - * is guaranteed to be atomic. All bit operations return 0 if the bit - * was cleared before the operation and != 0 if it was not. - * - * bit 0 is the LSB of addr; bit 32 is the LSB of (addr+1). - */ Doesn't "atomic" mean SMP safe? What's the point in the lock prefix if it doesn't make things SMP safe (after all, the unadorned instructions are UP safe...)? > That also does not help for protecting your objects, it only protects > the wait queue. Yes. I don't see what more needs to be done, at least on the mutex. It is either available when we come to grab it, and we find this out and grab it in a single operation, or it isn't, and we wait. Furthermore, the objects also have atomic_t reference counts like other kernel modules, so they aren't going to go away whilst in use. > The processes look it up in a shared name table (shmem). Yes they have > to negoitate in this case -- it'll only be a win when they usually do not > share. And really horrible when they do share. Plus you still have to jump through all the same synchronisation hoops to control access to the shmem that the kernel does when governing access to its objects. > Probably, it is a DoS. Surely a DoS attack is only possible if there is a limit in force? Namespace DoS attacks are possible whatever the underlying system, wineserver, kernel module, or Windows itself. Of course, when I said "number of processes (not threads) * ~1020" what I actually meant is "number of interested processed...", since any process not interested can't actually issue the Win32 calls anyway. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Compiler warnings
I just found out that gcc-2.96 won't compile glibc-2.1.93 or glibc-2.1.2 or glibc-2.1.3 successfully whereas gcc-2.95.2 will. It bombs in a couple of places. I just downgraded my machine to 2.95.2 to prove the point. Guess I'll wait for gcc-3.0. Michael D. Black Principal Engineer [EMAIL PROTECTED] 321-676-2923,x203 http://www.csihq.com Computer Science Innovations http://www.csihq.com/~mike My home page FAX 321-676-2355 - Original Message - From: "Jamie Lokier" <[EMAIL PROTECTED]> To: "David Woodhouse" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, September 07, 2000 10:55 AM Subject: Re: Compiler warnings David Woodhouse wrote: > You cannot safely compile even 2.4 kernels with gcc-2.96 on any platform, as > far as I'm aware. It's an insane thing to do. Use a sensible compiler. Oh. I've been using gcc-2.96 with test7 for a while, no problems except the ## warnings. Never occured to me that gcc-2.95.2 would be better, which I was using for ages before that... -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Test
Test -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test8-pre6] misc fixes
Hi Linus,
This patch was reviewed by human kind for several hours and there was
found no fault in it.
It fixes:
a) bugfix to read_kmem() which currently can fail on low memory when it
should succeed (i.e. when it doesn't need that page)
b) nvram driver doesn't handle failures from misc_register() and
create_proc_read_entry() properly. Also it initializes static variable to
0 which increases the kernel size - silly.
c) wdt driver doesn't handle failures from request_irq(),
request_region(), misc_register() and register_reboot_notifier()
d) same fixes for wdt_pci as for wdt
e) BusLogic drivers initializes some stuff to 0 which is not needed
f) block_dev.c:block_write() can be optimized a tiny bit
g) inodes_stat doesn't need to be initialised to 0
h) init_procfs_fs() doesn't handle failures from kern_mount gracefully
i) kernel/signal.c contains a typo sigueue -> sigqueue
j) mem_map is initialized to NULL - unnecessary
k) all swapout functions in mm/vmscan.c can be optimized by removing 'mm'
argument. This part was reviewed by Rick van Riel and approved.
l) if sk_cachep SLAB cache creation fails we must at least print a
KERN_CRIT message to the console. I agree with Alan Cox that panic may be
a bit over the top for this one...
Everything tested under 2.4.0-test8-pre6.
Regards,
Tigran
diff -urN -X dontdiff linux/drivers/char/mem.c linux-2.4.0-test8-p6/drivers/char/mem.c
--- linux/drivers/char/mem.cSat Jun 24 12:44:26 2000
+++ linux-2.4.0-test8-p6/drivers/char/mem.c Thu Sep 7 02:52:41 2000
@@ -258,25 +258,27 @@
count -= read;
}
- kbuf = (char *)__get_free_page(GFP_KERNEL);
- if (!kbuf)
- return -ENOMEM;
- while (count > 0) {
- int len = count;
+ if (count > 0) {
+ kbuf = (char *)__get_free_page(GFP_KERNEL);
+ if (!kbuf)
+ return -ENOMEM;
+ while (count > 0) {
+ int len = count;
- if (len > PAGE_SIZE)
- len = PAGE_SIZE;
- len = vread(kbuf, (char *)p, len);
- if (len && copy_to_user(buf, kbuf, len)) {
- free_page((unsigned long)kbuf);
- return -EFAULT;
+ if (len > PAGE_SIZE)
+ len = PAGE_SIZE;
+ len = vread(kbuf, (char *)p, len);
+ if (len && copy_to_user(buf, kbuf, len)) {
+ free_page((unsigned long)kbuf);
+ return -EFAULT;
+ }
+ count -= len;
+ buf += len;
+ virtr += len;
+ p += len;
}
- count -= len;
- buf += len;
- virtr += len;
- p += len;
+ free_page((unsigned long)kbuf);
}
- free_page((unsigned long)kbuf);
*ppos = p;
return virtr + read;
}
diff -urN -X dontdiff linux/drivers/char/nvram.c
linux-2.4.0-test8-p6/drivers/char/nvram.c
--- linux/drivers/char/nvram.c Thu Sep 7 02:03:52 2000
+++ linux-2.4.0-test8-p6/drivers/char/nvram.c Thu Sep 7 03:07:38 2000
@@ -109,7 +109,7 @@
extern spinlock_t rtc_lock;
-static int nvram_open_cnt = 0; /* #times opened */
+static int nvram_open_cnt; /* #times opened */
static int nvram_open_mode;/* special open modes */
#defineNVRAM_WRITE 1 /* opened for writing
(exclusive) */
#defineNVRAM_EXCL 2 /* opened with O_EXCL */
@@ -415,14 +415,29 @@
static int __init nvram_init(void)
{
+ int ret;
+
/* First test whether the driver should init at all */
if (!CHECK_DRIVER_INIT())
return( -ENXIO );
- printk(KERN_INFO "Non-volatile memory driver v%s\n", NVRAM_VERSION );
- misc_register( &nvram_dev );
- create_proc_read_entry("driver/nvram",0,0,nvram_read_proc,NULL);
- return( 0 );
+ ret = misc_register( &nvram_dev );
+ if (ret) {
+ printk(KERN_ERR "nvram: can't misc_register on minor=%d\n",
+NVRAM_MINOR);
+ goto out;
+ }
+ if (!create_proc_read_entry("driver/nvram",0,0,nvram_read_proc,NULL)) {
+ printk(KERN_ERR "nvram: can't create /proc/driver/nvram\n");
+ ret = -ENOMEM;
+ goto outmisc;
+ }
+ ret = 0;
+ printk(KERN_INFO "Non-volatile memory driver v" NVRAM_VERSION "\n");
+out:
+ return( ret );
+outmisc:
+ misc_deregister( &nvram_dev );
+ goto out;
}
static void __exit nvram_cleanup_module (void)
diff -urN -X dontdiff linux/drivers/char/wdt.c linux-2.4.0-test8-p6/drivers/char/wdt.c
--- linux/drivers/char/wdt.cFri Jul 28 09:58:59 2000
+++ linux-2.4.0-test8-p6/drivers/char/wdt.c Thu Sep 7 04:00:04 2000
@@ -26,6 +2
[patch-2.4.0-test8-pre6] bugfix in microcode driver
Hi Linus,
This patch (courtesy of Eric W. Biederman <[EMAIL PROTECTED]>) allows
the microcode driver to make the correct decision about patch revision
even if there were no update done by the BIOS at all.
Regards,
Tigran
--- linux/arch/i386/kernel/microcode.c Thu Aug 24 08:08:43 2000
+++ work/arch/i386/kernel/microcode.c Thu Sep 7 15:59:57 2000
@@ -37,6 +37,13 @@
* Removed ->release(). Removed exclusive open and status bitmap.
* Added microcode_rwsem to serialize read()/write()/ioctl().
* Removed global kernel lock usage.
+ * 1.0707 Sep 2000, Tigran Aivazian <[EMAIL PROTECTED]>
+ * Write 0 to 0x8B msr and then cpuid before reading revision,
+ * so that it works even if there were no update done by the
+ * BIOS. Otherwise, reading from 0x8B gives junk (which happened
+ * to be 0 on my machine which is why it worked even when I
+ * disabled update by the BIOS)
+ * Thanks to Eric W. Biederman <[EMAIL PROTECTED]> for the fix.
*/
#include
@@ -51,7 +58,7 @@
#include
#include
-#define MICROCODE_VERSION "1.06"
+#define MICROCODE_VERSION "1.07"
MODULE_DESCRIPTION("Intel CPU (P6) microcode update driver");
MODULE_AUTHOR("Tigran Aivazian <[EMAIL PROTECTED]>");
@@ -188,7 +195,8 @@
microcode[i].ldrver == 1 && microcode[i].hdrver == 1) {
found=1;
-
+ wrmsr(0x8B, 0, 0);
+ __asm__ __volatile__ ("cpuid" : : : "ax", "bx", "cx", "dx");
rdmsr(0x8B, val[0], rev);
if (microcode[i].rev <= rev) {
printk(KERN_ERR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [wasRe: [patch] waitqueue optimization, 2.4.0-test7]
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
>"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure the compiler doesn't delay to
write data to the memory out of the critical section).
And in practice I can't reproduce any corruption with any subtle testcase
by removing "memory" from the clobber list of all the
spinlocks/__sti/__cli, so it may be the other way around. Maybe we can
rely on the __volatile__ statement of the asm that will enforce that if we
write:
*p = 0;
__asm__ __volatile__("" : :);
*p = 1;
in the assembler we'll then find both a write of 0 and then a write of 1
to memory. I'd say with the current compiler we can rely on it (infact the
spinlock doesn't seems to get miscompiled at the moment even while they
aren't clobbering "memory".
Same with:
int a = *p;
__asm__ __volatile__("" : :);
a = *p;
(to do two explicit reads)
If "memory" isn't necessary in spin_lock, then all the "memory" clobbers
around include/*/* (also in mb() and __cli() and even barrier()) are not
necessary. But then "why" we need a "memory" clobber in first place if the
"memory" isn't necessary? :)) Also the gcc documentation seems to say we
need "memory" in all such operations (also in __sti() and
spin_unlock() unlike I said in my earlier email).
I'd like if some compiler guy could comment (I got no one reply yet). I
tried to grep gcc but my gcc knowledge is too low to reverse engeneer the
implement semantics of the "memory" clobber fast (though I would
appreciate a pointer in the gcc sources to start to understand some gcc
code :).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
David Woodhouse wrote: > But how much work would it require to do so? If your theoretical vendor of > closed-source compiler backends were to believe that a shared lib of the > GCC frontend would be legal, surely they'd just make it shared themselves, > then use it as such? It's hardly a effective preventative measure. Yes, there is nothing to prevent a vendor doing that _if_ they take care to ensure their proprietary code doesn't include inline functions / large macros etc. from the GCC header files. A clean interface to the shared library, where the interface is written by that vendor would do it. The interface code would have to be released under a GPL compatible license, that also permits the vendor to make use of it. E.g. LGPL would do for the interface header files, as would many other licenses. Such a thing won't be accepted into the main GCC distribution though. It's probably easier to use a pipe anyway. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
linux kernel TCP, network connections and iptables
Hello, I am not sure if this is the right list to point out some linux TCP implementation "weakness" but I think that something should be done first at the kernel level and after with any other way (firewalling etc). The problem: I am using 2.0.38 and I am receiving lots of DoS attacks on one of my servers (used as ftp and irc server as well). A piece of tcpdump follows: 02:52:44.448067 213.11.1.241.1969 > 155.207.19.200.122: . ack 1247023010 win 655 35 (DF) 02:52:44.448067 155.207.19.200.122 > 213.11.1.241.1969: R 1247023010:1247023010( 0) win 0 02:52:44.448067 213.11.1.154.1695 > 155.207.19.200.123: . ack 1247023010 win 655 35 (DF) 02:52:44.448067 155.207.19.200.123 > 213.11.1.154.1695: R 1247023010:1247023010( 0) win 0 02:52:44.448067 213.11.37.32.1397 > 155.207.19.200.11: . ack 1628640333 win 6553 5 (DF) 02:52:44.448067 155.207.19.200.11 > 213.11.37.32.1397: R 1628640333:1628640333(0 ) win 0 The DoS is caused by the machine itself since it floods out itself with RST packets, since the machine replies to MANY repeated incoming ACK packets hitting unused ports. The questions: - Could there be some kind of handling for such packets (meaning TCP packets reaching at an unused port with ACK bit set - with no previous SYN etc packet) to avoid such DoS attacks? Is the same happening to newer kernels? If yes, should we just eat it and shut up (because that's the way TCP works and it will not change)? - To do something about the above DoS, I am raw monitoring every incoming packet and, for every incoming packet I receive with ACK bit set, I bind to that port and if it is used, then I let it pass or else I block it (for some random minutes) with ipfw. I tried to read /proc/net/tcp to find out which ports are used but that came out to be bad because if I read /proc/net/tcp too fast and many times per second, the load average goes really high. So, is there any way, any documentation about any system call or any more direct, faster kernel-way to get what /proc/net/tcp gives at any time? If yes, could you please direct me there? I haven't used iptables yet but I think they can handle packets with various bits sets (including RST), unlike ipfw. But, is there any way with iptables to know if a port is "used" or "unused" at any time? And if yes, at what state (listening, at the middle of a 3-way TCP handshaking etc) also? Good day to all. -- George Athanassopoulos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Is a process with a priority of 0 legal ?
If it is the 2.2.16 scheduler & other linux'es have a bug.
The following code snippets can go into a tight loop.
while (p != &init_task)
{
if (can_schedule(p))
{
int weight = goodness(prev, p, this_cpu);
if (weight > c)
c = weight, next = p;
}
p = p->next_run;
}
/* Do we need to re-calculate counters? */
if (!c)
goto recalculate;
recalculate:
{
struct task_struct *p;
spin_unlock_irq(&runqueue_lock);
read_lock(&tasklist_lock);
for_each_task(p)
p->counter = (p->counter >> 1) + p->priority;
read_unlock(&tasklist_lock);
spin_lock_irq(&runqueue_lock);
goto repeat_schedule;
}
If the weight & priority of all runnable processes is 0 then the
recalculate with recalculate p->counter=0 for all runnable processes,
& the code will go into a tight loop between the goodness calculation &
recalculate.
Not very robust in my opinion.
D.J. Barrow Linux for S/390 kernel developer
eMail: [EMAIL PROTECTED],[EMAIL PROTECTED]
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Error in fs/nls/Config.in in 2.2.18-pre3
"make xconfig" failed in line 8 of fs/nls/Config.in. --- # # Native language support configuration # # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ -o "$CONFIG_SMB_FS" != n ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n fi -- I simply thought putting n inside an double-quoting n would solve the problem. But it did not. Best regards, G. Hugh Song - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test8-pre6
Linus Torvalds wrote: > Yeah. Maybe we fixed truncate, and maybe we didn't. I've thought that > we fixed it now several times, and I was always wrong. Time for some > reverse phychology: > > I'm sure this one doesn't fix the truncate bug either. So far things look really promising here. No ext2 breakage yet. Maybe this time you're wrong again and truncate is indeed fixed. I'll beat it some more in the next couple of days and see if I can get it to break somehow. Cheers, Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Compiler warnings
David Woodhouse wrote: > You cannot safely compile even 2.4 kernels with gcc-2.96 on any platform, as > far as I'm aware. It's an insane thing to do. Use a sensible compiler. Oh. I've been using gcc-2.96 with test7 for a while, no problems except the ## warnings. Never occured to me that gcc-2.95.2 would be better, which I was using for ages before that... -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
DAC960 SMP deadlock fix
Hi Leonard, this night I (hopefully) finally spotted and fixed a longstanding deadlock that was hitting us on heavily loaded server running the DAC960. The bug is present also in the earlier 2.2.x and 2.4.x and it's _not_ been introduced with the DAC960 updates in 2.2.17. In 2.4.x the SMP deadlock can't trigger because of two reasons: 1) the waitqueue uses a per-queue spinlock and the driver always wakeup the waitqueue with the io_request_lock acquired 2) the waitqueue lock in 2.4.x at the moment is a spinlock_t (thus there isn't a __cli-less read_lock (no-irqsave) wake_up). The bug triggers in 2.2.x because the waitqueue_lock is shard by all waitqueues and the wake_up uses a read_lock (that can be interrupted by irq handlers that can later spin on the io_request_lock). The SMP locking rule that was not enforced by the driver and that was causing the deadlock is: "never run add_wait_queue with the io_request_lock acquired" The reason of the rule is that the irq_request_lock can be acquired by interrupt handlers as well. The patch with a description of the problem is here: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre2/patches/v2.2/2.2.18pre2/DAC960-SMP-lock-inversion-1 I recommend adding the above fix to 2.2.18pre3. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
