[polynomial-c@gmx.de: Re: SCSI CD problems]
- Forwarded message from Poly <[EMAIL PROTECTED]> - From: Poly <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: SCSI CD problems Date: Sat, 19 May 2001 18:11:14 +0200 Hi, I'm not at the kernel-mailinglist so maybe you can forward this message to them. I have read your message you posted to the Linux-kernel mailinglist about your SCSI problems. Since my last motherboard-change (from EPoX EP-8KTA+/Thunderbird-B 850 to EPoX EP-8KTA3/Thunderbird-C 1000) I have experienced nearly the same problems as you have on my SuSE Linux 7.1 distribution. I have two SCSI-controllers, one is a Dawicontrol DC-2976UW (sym53c875e) and the other is a Dawicontrol DC-2980U2W (sym53c895). The 2976UW hosts three CD-ROM devices, a Plextor PX-40TS, a Plextor PX-W124TS and a Yamaha CRW4416S. The DC-2980U2W hosts three IBM (DDRS-34560D, DNES-309170W, DDYS-T09170N) harddrives. The problem appears in unregularly times when transferring some data over the SCSI-busses (it doesn't matter which SCSI-Bus is used). You can make the errors appearing more often, when you transfer a big amount of small files. By the way: I have n e v e r experienced data corruption or anything like that (maybe because I'm using ReiserFS). Only all SCSI devices hang sometimes for about 10-20 seconds. The following appears in /var/log/messages after any SCSI-hang-up (this should be seen as an example of how the errormessages look like, they are not always exactly the same of course): May 19 05:45:50 Troll kernel: scsi : aborting command due to timeout : pid 0, scsi1, channel 0, id 1, lun 0 0x28 00 00 68 19 a6 00 00 08 00 May 19 05:45:50 Troll kernel: sym53c8xx_abort: pid=0 serial_number=14280 serial_number_at_timeout=14280 May 19 05:45:53 Troll kernel: SCSI host 1 abort (pid 0) timed out - resetting May 19 05:45:53 Troll kernel: SCSI bus is being reset for host 1 channel 0. May 19 05:45:53 Troll kernel: sym53c8xx_reset: pid=0 reset_flags=2 serial_number=14280 serial_number_at_timeout=14280 May 19 05:45:54 Troll kernel: sym53c895-1-<1,*>: FAST-40 WIDE SCSI 80.0 MB/s (25.0 ns, offset 15) May 19 05:46:05 Troll kernel: sym53c895-1-<5,*>: FAST-40 WIDE SCSI 80.0 MB/s (25.0 ns, offset 31) May 19 05:46:21 Troll kernel: sym53c895-1-<2,*>: FAST-40 WIDE SCSI 80.0 MB/s (25.0 ns, offset 30) When I first recognized that kind of error I tried several kernels (2.2.18; 2.2.19; 2.4.0 to 2.4.4) but with each kernel the error appears again. After a while of testing around to find the reason for these hang-ups I found out, that it was caused by KDE-2.1.1 when it was running. Having a session with another windowmanager (fvwm2) or running on the console and transferring datas did not cause any SCSI-errors. So burning CDs for me only works if I have KDE2 not running. Attatched to this mail are the output of dmesg and lspci -v. If somebody needs more information, just send me an e-mail. I hope my mail helps a little and everybody can understand my bad english ;-) bye Lars Wendler Content-Description: textfile Linux version 2.4.4 (root@Troll) (gcc version 2.95.2 19991024 (release)) #1 Don Mai 3 05:42:45 CEST 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1000 (usable) BIOS-e820: - 0001 (reserved) On node 0 totalpages: 65536 zone(0): 4096 pages. zone(1): 61440 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=lin-2.4.4 ro root=806 BOOT_FILE=/boot/2.4.4-knl_02 reboot=warm mem=256M init 2 Initializing CPU#0 Detected 1002.306 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1998.84 BogoMIPS Memory: 255408k/262144k available (1122k kernel code, 6348k reserved, 397k data, 220k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfb3f0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:07.0 Applying VIA P
Re: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sun, 20 May 2001, Mike Galbraith wrote: > On Sat, 19 May 2001, Rik van Riel wrote: > > On Sat, 19 May 2001, Mike Galbraith wrote: > > > On Fri, 18 May 2001, Stephen C. Tweedie wrote: > > > > > > > That's the main problem with static parameters. The problem you are > > > > trying to solve is fundamentally dynamic in most cases (which is also > > > > why magic numbers tend to suck in the VM.) > > > > > > Magic numbers might be sucking some performance right now ;-) > > > > ... so you replace them with some others ... ;) > > I reused one of our base numbers to classify the severity of the > situation.. not the same as inventing new ones. (well, not quite > the same anyway.. half did come from the south fourty;) *nod* ;) (not that I'm saying this is bad ... it's just that I'd like to know why things work before looking at applying them) > > > (yes, the last hunk looks out of place wrt my text. > > > > It also looks kind of bogus and geared completely towards this > > particular workload ;) > > I'm not sure why that helps. I didn't put it in as a trick or > anything though. I put it in because it didn't seem like a > good idea to ever have more cleaned pages than free pages at a > time when we're yammering for help.. so I did that and it helped. ^ Note that this is not the normal situation. Now think about the amount of data you'd be blowing away from the inactive_clean pages after a bit of background aging has gone on on a lightly loaded system. Not Good(tm) regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ATA/ATAPI driver development
I'm getting ready to make some changes to the ide-floppy driver (to support dynamic media change notification), and after spending a few days reviewing most of the IDE driver code (ide, ide-disk, ide-cd, ide-floppy and ide-probe), I think I've got a good handle on what needs to be done. However, since what I need to do involves sending some ATA (not ATAPI) commands to the drive, that will add some complexity to the ide-floppy driver. I'm not opposed to that, but it appears that many of the other drivers (ide, ide-disk and ide-cd) already have code to send an ATA command (writing to the registers), and interrupt handlers to handle sending or receiving the buffer(s) of data that the command wants to transfer. Is this the way it is intended to be, with this code duplicated in multiple subdrivers? The sheer complexity of the DMA interface would make me think it would be far better for this "infrastructure" stuff to all be in ide.c, and just be used by the subdrivers. I can certainly make yet another copy of the code for the few commands that ide-floppy will need to be able to issue, but before I went about that I thought I'd see if there was a better plan... Thanks for your attention. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ethtool and pre4
pre4 is out, and a couple ethernet drivers have gained support for ethtool. In order to take advantage of the new support, you can download ethtool 1.2 from http://sf.net/projects/gkernel/ or check it out of CVS (instruction at the above URL). -- Jeff Garzik | "Do you have to make light of everything?!" Building 1024| "I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems with buslogic and osst driver
I (and others on the OnStream osst driver mailing) list cannot get this tape drive to work with BusLogic SCSI host adapters. This is with 2.2.19 and 2.4.3 and either a MultiMaster or FlashPoint card. I have been in contact with Willem Reide (the author of the osst driver) and he has identified some spurious errors surfacing from the BusLogic driver. Willem has suggested some workarounds for the osst driver that ignore these errors, but they are not sufficient to get the tape going. So I thought that it was time to bring in Leonard Zubkoff, who is still listed as the maintainer for the Buslogic driver. I haven't exchanged E-Mail with Leonard since 1995, but I sent off some mail anyway. I have as yet had no reply from him. So I have 2 questions: 1) Does anyone know if Leonard Zubkoff is still around? 2) Is anyone else looking after the BusLogic driver these days? Regards, Andy -- - Andrew Bray, PWMS, MA, | preferred:mailto:[EMAIL PROTECTED] London, England | or: mailto:[EMAIL PROTECTED] PGP id/fingerprint: D811F5C9/26 B5 42 C6 F4 00 B2 71 BA EA 9B 81 6C 65 59 07 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ide-pci.c for 2.4.5-pre4
There's an error in ide-pci.c that prevented it from compiling 2.4.5-pre4.
Try this.
Thanks,
Jeff
[ [EMAIL PROTECTED] ]
--- drivers/ide/ide-pci.c Sun May 20 11:56:48 2001
+++ drivers/ide/ide-pci.c.new Sun May 20 11:56:45 2001
@@ -708,7 +708,7 @@
/*
* Set up BM-DMA capability (PnP BIOS should have done
this)
*/
- if (!IDE_PCI_DEVID_EQ(d->devid, DEVID_CS5530)
+ if (!IDE_PCI_DEVID_EQ(d->devid, DEVID_CS5530))
hwif->autodma = 0; /* default DMA off if
we had to configure it here */
(void) pci_write_config_word(dev, PCI_COMMAND, pcicmd
| PCI_COMMAND_MASTER);
if (pci_read_config_word(dev, PCI_COMMAND, &pcicmd) ||
!(pcicmd & PCI_COMMAND_MASTER)) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel.org: 2.4.5-pre4 missing ChangeLog info - scratch that
It's in ChangeLog but not patch-2.4.5.log. Shawn. On Sat, 19 May 2001, Shawn Starr wrote: > Someone add the changelog info to kernel.org? > > merci. > > Shawn. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel.org: 2.4.5-pre4 missing ChangeLog info
Someone add the changelog info to kernel.org? merci. Shawn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sun, 20 May 2001, Dieter Nützel wrote: > > > Three back to back make -j 30 runs for three different kernels. > > > Swap cache numbers are taken immediately after last completion. > > > > The performance increase is nice, though. Do you see similar > > changes in different kinds of workloads ? > > I you have a patch against 2.4.4-ac11 I will do some tests with some > (interactive) 3D apps. I don't have an ac kernel resident atm, but since Alan merged here very recently, it will probably go in ok. If not, just holler and I'll download ac11 and make you a clean patch. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sat, 19 May 2001, Rik van Riel wrote: > On Sat, 19 May 2001, Mike Galbraith wrote: > > On Fri, 18 May 2001, Stephen C. Tweedie wrote: > > > > > That's the main problem with static parameters. The problem you are > > > trying to solve is fundamentally dynamic in most cases (which is also > > > why magic numbers tend to suck in the VM.) > > > > Magic numbers might be sucking some performance right now ;-) > > ... so you replace them with some others ... ;) I reused one of our base numbers to classify the severity of the situation.. not the same as inventing new ones. (well, not quite the same anyway.. half did come from the south fourty;) > > Three back to back make -j 30 runs for three different kernels. > > Swap cache numbers are taken immediately after last completion. > > The performance increase is nice, though. Do you see similar > changes in different kinds of workloads ? I don't have much to test with here, but I'll see if I can find something. I'd rather see someone with a server load try it. > > (yes, the last hunk looks out of place wrt my text. > > It also looks kind of bogus and geared completely towards this > particular workload ;) I'm not sure why that helps. I didn't put it in as a trick or anything though. I put it in because it didn't seem like a good idea to ever have more cleaned pages than free pages at a time when we're yammering for help.. so I did that and it helped. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, 19 May 2001, Richard Gooch wrote: > > Matthew Wilcox writes: > > On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote: > > > The transaction(2) syscall can be just as easily abused as ioctl(2) in > > > this respect. > > > > But read() and write() cannot. > > Sure they can. I can pass a pointer to a structure to either of them. You're missing the point. It's ok to do "read()/write()" on structures. In fact, people do that all the time (and then they complain about the file not being portable ;) The problem with ioctl is that not only are people passing ioctl's pointers to structures, but: - they're not telling how big the structure is - the structure can have pointers to other places - sometimes it modifies the structure passed in None of which are "network-nice". Basically, ioctl() is historically used as a "pass any crap into driver , and the driver - and ONLY the driver - will know what to do with it". And when _only_ a driver knows what the arguments mean, upper layers can't encapsulate them. Upper layers cannot make a packet of the argument and send it over the network to another machine. Upper layers cannot do sanity-checking on things like "is this argument a valid pointer". Which means, for example, that not only can you not send the ioctl arguments anywhere, but ioctl's have also historically been a hot-bed of bugs. Example traditional ioctl bugs: use kernel pointers to access the argument (because it just happens to work on x86, never mind the fact that if the argument is bad you'll get a kernel oops and/or a serious security error). Other example: different drivers/f ilesystems implementing the same ioctl, but disagreeing on what the argument means (is it a pointer to an integer argument, or the integer itself?). Now, the advantage of using read()/write() is (a) that it's unambiguous where the argument comes from and how big it is and (b) because of that the _psychology_ is different. You don't get into this "pass random crap around, let the kernel modify user data structures directly" mentality. And psychology is important. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files
On Sat, 19 May 2001 22:14:33 -0400, Ben Bridgwater <[EMAIL PROTECTED]> wrote: >To present a dumbed down UI targeted for "Aunt Millie" or >whoever against the protests of the mainstream kernel tool audience >makes zero sense to me, as don't Eric's repeated antagonistic comments. How many times do we have to say this? CML2 supports everybody from Aunt Millie (novice mode) through non-standard machine configurations (expert mode) through Linus (vi .config, make oldconfig). Pick the level of configuration that you need. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
Alexander Viro writes: > > > On Sat, 19 May 2001, Richard Gooch wrote: > > > The transaction(2) syscall can be just as easily abused as ioctl(2) in > > this respect. People can pass pointers to ill-designed structures very > > Right. Moreover, it's not needed. The same functionality can be > trivially implemented by write() and read(). As the matter of fact, > had been done in userland context for decades. Go and buy > Stevens. Read it. Then come back. I don't need to read it. Don't be insulting. Sure, you *can* use a write(2)/read(2) cycle. But that's two syscalls compared to one with ioctl(2) or transaction(2). That can matter to some applications. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Sat, May 19, 2001 at 11:11:31PM +0400, Ivan Kokshaysky wrote: > On Sat, May 19, 2001 at 03:55:02PM +0200, Andrea Arcangeli wrote: > > Reading the tsunami specs I learnt 1 tlb entry caches 8 pagetables (not 1) > > so the tlb flush will be invalidate immediatly by any PCI DMA run after > > the flush on any of the other 7 mappings cached in the same tlb entry. > > I have neither tsunami docs nor the tsunami box to play with :-( > so my guesses might be totally wrong... > But -- assuming that tsunami is similar to cia/pyxis, that is incorrect. > We're invalidating not the cached ptes, but the TLB tags, with all 4 (on > pyxis, and 8 on tsunami, I guess) associated ptes. The reason why we exactly. > align new entries at 4*PAGE_SIZE on cia/pyxis is a hardware bug -- if cached > pte is invalid, it doesn't cause TLB miss. I wouldn't be surprised at all if > tsunami has the same bug; in this case your fix is urgently needed, of course. It only depends on the specs if it has to be called a bug or a feature. > BTW, look at Richard's code in core_cia.c/verify_tb_operation() for > "valid tag invalid pte reload" test, it could be easily ported to tsunami. I didn't checked very closely what this code is doing but it seems it's not triggering any DMA transaction from a DMA bus master so it shouldn't be able to trigger the race, and as far I can tell as soon as you do DMA on an invalid pagetable cached in a tlb the machine will lock hard. So I expect if you try to probe if you need the 8 alignment at runtime you won't be able to finish the probe ;). > > then I also enlarged the pci SG space to 1G beause runing out of entries > > right now breaks the whole world: > > It would just delay the painful death, I think ;-) I _have_ to completly hide the painful death because as soon as I run out of entries the machine crashes immedatly because lots of drivers aren't checking for running out of ptes. Fixing that is a brainer thing, it may need to partly redesign the driver so you can take a fail path where you coulnd't previously, in some place you may need to re-issue a softirq later to try again, in others you must run_task_queue(&tq_disk) and sched_yield and try again later (you have the guarantee those entries will return available so it would be not deadlock prone to do that), in other places you can just drop the skb. Each driver has to be fixed in its right way. It seems for a lot of cases people just replaced the virt_to_bus with the pci_map_single and they didn't thought pci_map_single may even return 0 which _doesn't_ mean bus address 0 ;) The reason it's not too bad to hide it is that you can usually calculate an high bound of how many pci mappings a certain given machine may need at the same time at runtime, so I can give you the guarantee that you won't be able to reproduce any of that kind of driver bugs on a certain given machine, this is the only point of the change, just to get this guarantee on a larger subset of machines until all those bugs are fixed. > I'm almost sure that all these "pci_map_sg failed" reports are caused > by some buggy driver[s], which calls pci_map_xx() without proper > pci_unmap_xx(). This is harmless on i386, and on alpha if all IO is going I'm not talking about that kind of leak bug. The fact some driver is leaking ptes is a completly different kind of bug. I was only talking about when you get the "pci_map_sg failed" because you have not 3 but 300 scsi disks connected to your system and you are writing to all them at the same time allocating zillons of pte, and one of your drivers (possibly not even a storage driver) is actually not checking the reval of the pci_map_* functions. You don't need a pte memleak to trigger it, even regardless of the fact I grown the dynamic window to 1G which makes it 8 times harder to trigger than in mainline. For now with a a couple of disks and a few nics and a 1G of dynamic window size it doesn't trigger and the 1G thing gives a fairly large margin for most machines out there. I cannot care less about the 2M-128k memory wastage at this point in time, but as I said I wanted at least to optimize the 2M pte arena allocation away completly if the machine has less than 2G, that would be a very worthwhile optimization. > I've got some debugging code checking for this (perhaps it worth > posting or even porting to i386 ;-) > For now I can confirm that all drivers I'm currently using are fine > wrt pci_map/unmap: > 3c59x, tulip, sym53c8xx, IDE. all the drivers I'm using are definitely not leaking pte entries either, but if you give me not 10 but 1000 scsi disks be sure I will trigger the missing checks for pci_map_* retval without the need of any driver leaking ptes. The bug you are talking about is even worse and I never experienced it myself, but I agree it's likely some driver has it too because it's not reproducible on x86, so if you have the x86 debugging code that's welcome so we will be able to reproduce it on a larger variety of mach
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, 19 May 2001, Richard Gooch wrote: > The transaction(2) syscall can be just as easily abused as ioctl(2) in > this respect. People can pass pointers to ill-designed structures very Right. Moreover, it's not needed. The same functionality can be trivially implemented by write() and read(). As the matter of fact, had been done in userland context for decades. Go and buy Stevens. Read it. Then come back. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD blockdevice buffers
In article <[EMAIL PROTECTED]>, Jens Axboe <[EMAIL PROTECTED]> wrote: >> >> As a result the system performance goes down. I'm still able to use >> my applications, but es every single piece of unused memory is swapped >> out, and swapping in costs a certain amount of time. > >That's why streaming media applications like a dvd player should use raw >I/O -- to bypass system cache. See /dev/raw* I disagree.. The fact is that the block device fs infrastructure is just sadly broken. By using the buffer cache, it makes memory management very hard, and just upgrading to the page cache would (a) speed stuff up and (b) make it much easier for the kernel to do the right thing wrt the MM use. Right now we don't try to aggressively drop streaming pages, but it's possible. Using raw devices is a silly work-around that should not be needed, and this load shows a real problem in current Linux (one soon to be fixed, I think - Andrea already has some experimental patches for the page-cache thing). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote: > The transaction(2) syscall can be just as easily abused as ioctl(2) in > this respect. But read() and write() cannot. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, 19 May 2001, Richard Gooch wrote: > There is another reason to use ioctl(2): when you need to send data to > the kernel/driver and wait for a response. It supports transactions, > which read(2) and write(2) cannot. Therefore it remains useful. Somebody, run to database vendors and tell them that they were selling snake oil all that time - Richard had just shown that support of remote transactions is impossible. Can't do that with read() and write(), dontcha know? Richard, I hate to break it on you, but fd = open(foo, 2); /* kernel creates a new struct file, as usual */ write(fd, data, len); /* kernel starts the operation */ read(fd, reply, size); /* we block */ /* operation is completed */ /* kernel passes reply to user and wakes it up */ _is_ a support of transactions. And yes, we can trivially distinguish between requests from different sources - struct file * passed to ->write() is more than enough for that. Moreover, we can easily block other writers until the action is completed. Please, get a bloody clue. There are reasons for and against ioctls, but need to send data and wait for responce is _NOT_ one of them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
Matthew Wilcox writes: > On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote: > > Al, if you really want to kill ioctl(2), then perhaps you should > > implement a transaction(2) syscall. Something like: > > int transaction (int fd, void *rbuf, size_t rlen, > > void *wbuf, size_t wlen); > > > > Of course, there wouldn't be any practical gain, since we already have > > ioctl(2). Any gain would be aesthetic. > > I can tell you haven't had to write any 32-bit ioctl emulation code for > a 64-bit kernel recently. The transaction(2) syscall can be just as easily abused as ioctl(2) in this respect. People can pass pointers to ill-designed structures very easily. The main advantage of transaction(2) is that hopefully, people will not be so bone-headed as to forget to pass sizeof *structptr as the size field. So perhaps some error trapping is possible. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.4-ac11 network drivers cleaning
Keith Owens wrote:
>
> On Sat, 19 May 2001 17:58:49 -0400,
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >Finally, I don't know if I mentioned this earlier, but to be complete
> >and optimal, version strings should be a single variable 'version', such
> >that it can be passed directly to printk like
> >
> > printk(version);
>
> Nit pick. That has random side effects if version contains any '%'
> characters. Make it
>
> printk("%s\n", version);
>
> Not quite as optimal but safer.
I disagree. Don't work around an escape bug in a version string, fix
it...
--
Jeff Garzik | "Do you have to make light of everything?!"
Building 1024| "I'm extremely serious about nailing your
MandrakeSoft | step-daughter, but other than that, yes."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files
Miles Lane wrote: > > On 19 May 2001 21:06:51 -0400, Benedict Bridgwater wrote: > > > This bug unconditionally disables a configuration question -- and it's > > > so old that it has propagated across three port files, without either > > > of the people who did the cut and paste for the latter two noticing it. > > > > > > This sort of thing would never ship in CML2, because the compiler > > > would throw an undefined-symbol warning on BLK_DEV_ST. The temptation > > > to engage in sarcastic commentary at the expense of people who still > > > think CML2 is an unnecessary pain in the butt is great. But I will > > > restrain myself. This time. > > > > So a shortcoming of the CML1 tools justifies the CML2 language? > > > > I guess the next bug found in the Python2 interpreter will justify > > writing CML3 in FORTRAN. > > IIRC, Eric floated the CML2 idea over a year ago, provided some > rudimentary code and requested feedback. There has seemed, for a long > time, to be agreement amoungst most kernel developers that there were > serious problems with CML1 and that it needed to be junked. There are > many things that CML1 was not going to allow us to do that will be > possible with CML2 (subsetting of the code tree, etc). I don't think > Eric's statement about this particular brown-paper-bag bug means that he > thinks that this alone justifies migrating to CML2. There are a lot of > good reasons for the migration. It isn't, perhaps, a perfect solution, > but it is one that Eric has implemented with a year's worth of effort, > with full knowledge of the kernel development community and with an open > invitation for contributions and feedback. To rag on it now seems > belated and unhelpful. It would be more useful if you helped Eric > improve CML2, since there appears to be agreement that it will be used > in 2.5. Well if Eric is so concerned about his target audience then he certainly doesn't show it through his arrogant comments. CML2 itself may be well justified (although not on grounds of a diagnostic that CML1 tools could be changed to generate!), but there's no reason the tools utilizing the CML2 based rules shouldn't present a *superset* of the existing functionality. To present a dumbed down UI targeted for "Aunt Millie" or whoever against the protests of the mainstream kernel tool audience makes zero sense to me, as don't Eric's repeated antagonistic comments. Ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
Andries Brouwer writes: > Andrew Morton writes: > > > > (2) what about bootstrapping? how do you find the root device? > > > Do you do "root=/dev/hda/offset=63,limit=1235823"? Bit nasty. > > > > Ben's patch makes initrd mandatory. > > Can this be fixed? I've *never* had to futz with initrd. > Probably most systems are the same. It seems a step > backward to make it necessary. > > I don't think so. It is necessary, and it is good. It most certainly is not. This attitude of pushing more and more stuff out of the kernel and into initrd is really annoying. Initrd is messy, nasty and opaque. It makes the boot process more complex. There is no way in hell I want to be forced to use it. Removing N lines from the kernel at the cost of adding N+k lines to user-space is a *loss*, not a gain. I want my *system* to be simple and transparent. > But it is easy to make the transition painless. No, initrd is fundamentally painful. Let go of this ideology of removing code from the kernel at all costs. A super-slim kernel which requires a more complex to administer user-space is too high a cost. The benefits of removing partition support from the kernel are basically zero. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
Alan Cox writes: > > ioctls are evil, period. At least with these names you can use normal > > scripting and don't need any special tools. Every ioctl means a binary > > that has no business to exist. > > That is not IMHO a rational argument. It isn't my fault that your > shell does not support ioctls usefully. If you used perl as your > login shell you would have no problem there. There is another reason to use ioctl(2): when you need to send data to the kernel/driver and wait for a response. It supports transactions, which read(2) and write(2) cannot. Therefore it remains useful. Al, if you really want to kill ioctl(2), then perhaps you should implement a transaction(2) syscall. Something like: int transaction (int fd, void *rbuf, size_t rlen, void *wbuf, size_t wlen); Of course, there wouldn't be any practical gain, since we already have ioctl(2). Any gain would be aesthetic. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.4-ac11 network drivers cleaning
On Sat, 19 May 2001 17:58:49 -0400,
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>Finally, I don't know if I mentioned this earlier, but to be complete
>and optimal, version strings should be a single variable 'version', such
>that it can be passed directly to printk like
>
> printk(version);
Nit pick. That has random side effects if version contains any '%'
characters. Make it
printk("%s\n", version);
Not quite as optimal but safer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: DVD blockdevice buffers
On Sun, 20 May 2001, Jens Axboe wrote: > On Sat, May 19 2001, Adam Schrotenboer wrote: > > /dev/raw* Where? I can't find it in my .config (grep RAW .config). I am > > using 2.4.4-ac11 and playing w/ 2.4.5-pre3. > > It's automagically included, no config options necessary > (drivers/char/raw.c) then why can't I find /dev/raw* (I'm using devfs, FWIW) > > -- > Jens Axboe > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files
On 19 May 2001 21:06:51 -0400, Benedict Bridgwater wrote: > > This bug unconditionally disables a configuration question -- and it's > > so old that it has propagated across three port files, without either > > of the people who did the cut and paste for the latter two noticing it. > > > > This sort of thing would never ship in CML2, because the compiler > > would throw an undefined-symbol warning on BLK_DEV_ST. The temptation > > to engage in sarcastic commentary at the expense of people who still > > think CML2 is an unnecessary pain in the butt is great. But I will > > restrain myself. This time. > > So a shortcoming of the CML1 tools justifies the CML2 language? > > I guess the next bug found in the Python2 interpreter will justify > writing CML3 in FORTRAN. IIRC, Eric floated the CML2 idea over a year ago, provided some rudimentary code and requested feedback. There has seemed, for a long time, to be agreement amoungst most kernel developers that there were serious problems with CML1 and that it needed to be junked. There are many things that CML1 was not going to allow us to do that will be possible with CML2 (subsetting of the code tree, etc). I don't think Eric's statement about this particular brown-paper-bag bug means that he thinks that this alone justifies migrating to CML2. There are a lot of good reasons for the migration. It isn't, perhaps, a perfect solution, but it is one that Eric has implemented with a year's worth of effort, with full knowledge of the kernel development community and with an open invitation for contributions and feedback. To rag on it now seems belated and unhelpful. It would be more useful if you helped Eric improve CML2, since there appears to be agreement that it will be used in 2.5. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files
On 19 May 2001 21:06:51 -0400, Benedict Bridgwater wrote: > > This bug unconditionally disables a configuration question -- and it's > > so old that it has propagated across three port files, without either > > of the people who did the cut and paste for the latter two noticing it. > > > > This sort of thing would never ship in CML2, because the compiler > > would throw an undefined-symbol warning on BLK_DEV_ST. The temptation > > to engage in sarcastic commentary at the expense of people who still > > think CML2 is an unnecessary pain in the butt is great. But I will > > restrain myself. This time. > > So a shortcoming of the CML1 tools justifies the CML2 language? > > I guess the next bug found in the Python2 interpreter will justify > writing CML3 in FORTRAN. IIRC, Eric floated the CML2 idea over a year ago, provided some rudimentary code and requested feedback. There has seemed, for a long time, to be agreement amoungst most kernel developers that there were serious problems with CML1 and that it needed to be junked. There are many things that CML1 was not going to allow us to do that will be possible with CML2 (subsetting of the code tree, etc). I don't think Eric's statement about this particular brown-paper-bag bug means that he thinks that this alone justifies migrating to CML2. There are a lot of good reasons for the migration. It isn't, perhaps, a perfect solution, but it is one that Eric has implemented with a year's worth of effort, with full knowledge of the kernel development community and with an open invitation for contributions and feedback. To rag on it now seems belated and unhelpful. It would be more useful if you helped Eric improve CML2, since there appears to be agreement that it will be used in 2.5. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Fri, May 18, 2001 at 09:46:17PM +0400, Ivan Kokshaysky wrote:
> -void
> -cia_pci_tbi(struct pci_controller *hose, dma_addr_t start, dma_addr_t end)
> -{
> - wmb();
> - *(vip)CIA_IOC_PCI_TBIA = 3; /* Flush all locked and unlocked. */
> - mb();
> - *(vip)CIA_IOC_PCI_TBIA;
> -}
I'd rather keep this around. It should be possible to use on CIA2.
> +/* Even if the tbia works, we cannot use it. It effectively locks the
> + * chip (as well as direct write to the tag registers) if there is a
> + * SG DMA operation in progress. This is true at least for PYXIS rev. 1.
Uggg. How did you discover this?
> +/* __save_and_cli(flags); Don't need this -- we're called from
> + pci_unmap_xx() or iommu_arena_alloc()
> + with IPL_MAX after spin_lock_irqsave() */
Just delete it, don't comment it out. You might mention in the
function header comment that we're called with interrupts disabled.
> *(vip)CIA_IOC_CIA_CTRL = ctrl;
> mb();
> - *(vip)CIA_IOC_CIA_CTRL;
> - mb();
I'm pretty sure you don't want to do this. You're risking a
subsequent i/o being posted through the PCI bridge before this
takes effect. An "mb" is only effective inside the CPU.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files
> This bug unconditionally disables a configuration question -- and it's > so old that it has propagated across three port files, without either > of the people who did the cut and paste for the latter two noticing it. > > This sort of thing would never ship in CML2, because the compiler > would throw an undefined-symbol warning on BLK_DEV_ST. The temptation > to engage in sarcastic commentary at the expense of people who still > think CML2 is an unnecessary pain in the butt is great. But I will > restrain myself. This time. So a shortcoming of the CML1 tools justifies the CML2 language? I guess the next bug found in the Python2 interpreter will justify writing CML3 in FORTRAN. Ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Here's a dumb question, and I apologize if I am questioning computer science dogma... Why are LVM and EVMS(competing LVM project) needed at all? Surely the same can be accomplished with * md * snapshot blkdev (attached in previous e-mail) * giving partitions and blkdevs the ability to grow and shrink * giving filesystems the ability to grow and shrink On-line optimization (defrag, etc) shouldn't be hard once you have the ability to move blocks and files around, which would come with the ability to grow and shrink blkdevs and fs's. -- Jeff Garzik | "Do you have to make light of everything?!" Building 1024| "I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Linus Torvalds wrote:
> There are some strong arguments that we should have filesystem
> "backdoors" for maintenance purposes, including backup.
I think I agree with something Al said over IRC, that fs-level snapshots
are preferred over block level snapshots.
fs-level snapshots should become easy if you have a generic transaction
layer. The OS spits out file ops, which get processed into a set of fs
transactions. (remember that fs-level stuff like "change this block
bitmap" is also a transaction, just like the more generic "update this
inode's mtime")
Also, I think there should be generic block allocation strategies that
fs's can use. Implementing fs-specific strategies such as ext2's
readahead or XFS's delayed allocation is not a solution, IMHO, but
working towards solving the real problem.
> You can, of course, so parts of this on a LVM level, and doing backups
> with "disk snapshots" may be a valid approach. However, even that is
> debatable: there is very little that says that the disk image has to be
> up-to-date at any particular point in time, so even with a disk snapshot
> capability (which is not necessarily reasonable under all circumstances)
> there are arguments for maintenance interfaces.
I've been hacking on the attached, a snapshot block device driver, which
doesn't require LVM at all. (warning: compiled and updated per outside
review, but very alpha... do not apply)
The point of the driver is to provide a sync point at snapshot time, at
which all metadata and data is flushed to the block device.
My question... is there a fundamental flaw in this plan? Ideally when
userspace says "start snapshot", the fsync_dev occurs [a
simplification]. At that point, userspace can safely run dump or tar or
whatever on the virtual snapshot device.
--
Jeff Garzik | "Do you have to make light of everything?!"
Building 1024| "I'm extremely serious about nailing your
MandrakeSoft | step-daughter, but other than that, yes."
Index: linux_2_4/drivers/block/Config.in
diff -u linux_2_4/drivers/block/Config.in:1.1.1.44
linux_2_4/drivers/block/Config.in:1.1.1.44.4.1
--- linux_2_4/drivers/block/Config.in:1.1.1.44 Tue May 15 04:43:24 2001
+++ linux_2_4/drivers/block/Config.in Wed May 16 15:44:59 2001
@@ -46,4 +46,6 @@
fi
dep_bool ' Initial RAM disk (initrd) support' CONFIG_BLK_DEV_INITRD
$CONFIG_BLK_DEV_RAM
+tristate 'Snapshot device support' CONFIG_BLK_DEV_SNAP
+
endmenu
Index: linux_2_4/drivers/block/Makefile
diff -u linux_2_4/drivers/block/Makefile:1.1.1.46
linux_2_4/drivers/block/Makefile:1.1.1.46.4.1
--- linux_2_4/drivers/block/Makefile:1.1.1.46 Tue May 15 04:43:24 2001
+++ linux_2_4/drivers/block/MakefileWed May 16 15:44:59 2001
@@ -31,6 +31,7 @@
obj-$(CONFIG_BLK_DEV_DAC960) += DAC960.o
obj-$(CONFIG_BLK_DEV_NBD) += nbd.o
+obj-$(CONFIG_BLK_DEV_SNAP) += snap.o
subdir-$(CONFIG_PARIDE) += paride
Index: linux_2_4/drivers/block/snap.c
diff -u /dev/null linux_2_4/drivers/block/snap.c:1.1.6.10
--- /dev/null Sat May 19 17:36:30 2001
+++ linux_2_4/drivers/block/snap.c Thu May 17 11:48:54 2001
@@ -0,0 +1,1055 @@
+/*
+ Copyright 2001 Jeff Garzik <[EMAIL PROTECTED]>
+ Copyright (C) 2000 Jens Axboe <[EMAIL PROTECTED]>
+
+ May be copied or modified under the terms of the GNU General Public
+ License. See linux/COPYING for more information.
+
+ Several ideas and some code taken from Jens Axboe's pktcdvd.c 0.0.2j.
+
+ To-Do list:
+ * Write support. It's easy, and might be useful in isolated circumstances.
+ * Convert MAX_SNAPDEVS to a module parameter.
+ * Wrap use of "%" operator, to prepare for 64-bit-sized blockdevs on
+ 32-bit processors
+
+ */
+
+#define VERSION_CODE "v0.5.0-take6 17 May 2001 Jeff Garzik
+<[EMAIL PROTECTED]>"
+#define MODNAME"snap"
+#define PFXMODNAME ": "
+#define MAX_SNAPDEVS 16
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int *snap_sizes;
+static int *snap_blksize;
+static int *snap_readahead;
+static struct snap_device *snap_devs;
+static int snap_major = -1;
+static spinlock_t snap_lock = SPIN_LOCK_UNLOCKED;
+
+
+/*
+ * a bit of a kludge, but we want to be able to pass source, log,
+ * or snap dev and get the right one.
+ */
+static struct snap_device *snap_find_dev(kdev_t dev)
+{
+ int i, j;
+ struct snap_device *sd;
+
+ spin_lock(&snap_lock);
+
+ for (i = 0; i < MAX_SNAPDEVS; i++) {
+ sd = &snap_devs[i];
+ if ((sd->src.dev == dev) || (sd->snap_dev == dev))
+ goto out;
+ for (j = 0; j < sd->n_logs; j++)
+ if (sd->logs[j].dev == dev)
+ goto out;
+ }
+ sd = NULL;
+
+out:
+ spin_unlock(&snap_lock);
+ return sd;
+}
+
+static request_queue_t *snap_get_queue(kdev_t dev)
+{
+ struct snap_device *sd =
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Sat, May 19, 2001 at 05:11:30PM +0100, Alan Cox wrote: > If it had been a manufacturer in most respectable areas of business they'd be > recalling and reissuing components, and paying for the end resllers to notify > each customer This is consumer hardware. Consumer products are optimized for a good buzzword count per $ ratio. Everything else is secondary. Producing cheap stuff has its price. And being so smart an buing cheapest available has the same price. QA and recalling are expensive as hell. That's why cheap products usally have this quality tradeoff. Most consumers don't like to pay for quality. Germany has learned this lesson and thus "Made in Germany" doesn't mean anything for certain products anymore :-( Regards Ingo Oeser -- To the systems programmer, users and applications serve only to provide a test load. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sat, 19 May 2001, Alexander Viro wrote: > > On Sun, 20 May 2001, Edgar Toernig wrote: > > > That assumption is totally bogus. Even for regular files you have side > > effects (atime); for anything else they're unpredictable. > > That means only one thing: safe backups are possible only in single-user > mode. There are some strong arguments that we should have filesystem "backdoors" for maintenance purposes, including backup. You can, of course, so parts of this on a LVM level, and doing backups with "disk snapshots" may be a valid approach. However, even that is debatable: there is very little that says that the disk image has to be up-to-date at any particular point in time, so even with a disk snapshot capability (which is not necessarily reasonable under all circumstances) there are arguments for maintenance interfaces. Thinks like "lazy fsck" (ie fsck while already running the filesystem) and defragmentation simply is not feasible on a LVM level. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Re: Linux 2.4.4-ac10
> > Three back to back make -j 30 runs for three different kernels. > > Swap cache numbers are taken immediately after last completion. > > The performance increase is nice, though. Do you see similar > changes in different kinds of workloads ? I you have a patch against 2.4.4-ac11 I will do some tests with some (interactive) 3D apps. -Dieter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sun, 20 May 2001, Edgar Toernig wrote: > That assumption is totally bogus. Even for regular files you have side > effects (atime); for anything else they're unpredictable. That means only one thing: safe backups are possible only in single-user mode. For values of safe being "not triggering these side effects on arbitrary files outside of the area you are trying to backup". You can't pin an object down until you open it. You can check that it's the same object you think it is, but that will require fstat(). I.e. opening the thing. If all effects of open() either disappear on close() or are something you don't care about - fine. Otherwise you have a problem. On any UNIX. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
> On Sun, 20 May 2001, Ingo Oeser wrote: > > PS: English is neither mine, nor Linus native language. Why do > >the English natives complain instead of us? ;-) > > Because we had some experience with, erm, localized systems and for > Alan it's most likely pure theory? ;-) I think its important its considered. I do like the idea of a sensible ioctl encoding (including ascii potentially) and being able to ship ioctls over the network. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
> No, my point was, if I don't have SCSI or RAID on this box, I don't want > them to be built into the kernel! They arent built into the kernel. I still think you have your facts confused - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
nitpicking: a system call without side effects would be pretty useless. Alexander Viro wrote: > A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a > no-op. Breaking that assumption is a Bad Thing(tm). That assumption is totally bogus. Even for regular files you have side effects (atime); for anything else they're unpredictable. Ciao, ET. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
On Sat, 19 May 2001, Pavel Machek wrote: > I thought about how to do networking without sockets, and it seems to > me like this kind of modify syscall is needed, because network sockets > connect to *two* different places (one local address and one > remote). Sockets are really nasty :-(. Pavel, take a look at http://plan9.bell-labs.com/sys/man/3/ip - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
On Sat, 19 May 2001, Linus Torvalds wrote: > > On Sat, 19 May 2001, Pavel Machek wrote: > > > > Well, if we did something like modify(int fd, char *how), you could do > > > > modify(0, "nonblock,9600") > > What you're really proposing is to make ioctl's be ASCII strings. > > Which is not necessarily a bad idea, and I think plan9 did something > similar (or rather, if I remember correctly, plan9 has control streams > that were ASCII. Or am I confused?). You are not. Control streams in question look like normal files. Normally driver exports a tree with several data files (e.g. fd0, fd1, fd2, fd3) and several control files (e.g. fd0ctl, fd1ctl, fd2ctl, fd3ctl). write() to the latter passes commands. No extra syscalls needed. Notice that sometimes it's not ASCII - depends on the nature of stuff you are passing. Things like setting font, etc. need to pass bitmaps, so some parts of the stuff you write end up as binary. Which is perfectly sane. > And a "stream of bytes" is in a very real sense the simplest structure, > and is the unix way (and the plan9 way is to avoid binary streams, and use > ASCII text instead when possible, whihc probably also makes sense). s/possible/makes sense/. For commands ASCII is OK, but for cases when you pass binary data as a part of command (not just "something large", but something that really happens to be a bitmap, etc.) you write it as binary data. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Ingo Oeser wrote: > PS: English is neither mine, nor Linus native language. Why do >the English natives complain instead of us? ;-) Because we had some experience with, erm, localized systems and for Alan it's most likely pure theory? ;-) Al, still shuddering at the memories - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sat, 19 May 2001, Jeff Garzik wrote: > Are we talking about device arguments just for chrdevs and blkdevs? > (ie. drivers) or for regular files too? Let's distinguish between per-fd effects (that's what name in open(name, flags) is for - you are asking for descriptor and telling what behaviour do you want for IO on it) and system-wide side effects. IMO encoding the former into name is perfectly fine, and no write on another file can be sanely used for that purpose. For the latter, though, we need to write commands into files and here your miscdevices (or procfs files, or /dev/foo/ctl - whatever) is needed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Jeff Garzik wrote: > Notice also a "metadata miscdev" solves the problem of passing options > on open -- just pass those options to the miscdev before you open it... to be more clear, "it" == the data device, not the metadata miscdev -- Jeff Garzik | "Do you have to make light of everything?!" Building 1024| "I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Are we talking about device arguments just for chrdevs and blkdevs? (ie. drivers) or for regular files too? Speaking about drivers specifically, a controlling miscdev, one per device or one per group of devices depending on your needs, is a much more clean solution for passing ioctl-type data. You are free to come up with whatever method of communication with the driver is most efficient for your needs -- without perverting open(2). Notice also a "metadata miscdev" solves the problem of passing options on open -- just pass those options to the miscdev before you open it... metadata miscdevs are a clean solution to what procfs hacks and ioctls are trying to accomplish. Jeff -- Jeff Garzik | "Do you have to make light of everything?!" Building 1024| "I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sat, 19 May 2001, Matthew Wilcox wrote: > On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote: > > clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add > > unopened descriptors. I.e. no IO until you open it (turning the thing into > > opened one), but we can do lookups (move to child), we can clone and > > kill them and we can stat them. > > Those who would like a more detailed explanation can find one at > http://plan9.bell-labs.com/sys/man/5/INDEX.html Umm... Yes, it's an allusion to 9P, but no, I'm not serious about exporting that to userland. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD blockdevice buffers
On Sat, May 19 2001, Adam Schrotenboer wrote: > /dev/raw* Where? I can't find it in my .config (grep RAW .config). I am > using 2.4.4-ac11 and playing w/ 2.4.5-pre3. It's automagically included, no config options necessary (drivers/char/raw.c) -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, May 19, 2001 at 11:34:48AM -0700, Linus Torvalds wrote: [Reasons] > So the "English is bad" argument is a complete non-argument. Jepp, I have to agree. English is used more or less as an communication protocol in computer science and for operating computers. Once you know how to operate an computer in English, you can operate nearly every computer in the world, because they have English as default locale. Let's not repeat Babel please :-( PS: English is neither mine, nor Linus native language. Why do the English natives complain instead of us? ;-) And be glad that's not German, that has this role. English sentences are WAY easier to parse by computers, because it doesn't use much suffixes and prefixes on words and has very few exceptions. Also these exceptions are eleminated from command languages WITHOUT influencing readability and comprehensability. Regards Ingo Oeser -- To the systems programmer, users and applications serve only to provide a test load. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Brown-paper-bag bug in m68k, sparc, and sparc64config files
On Sat, 19 May 2001, Eric S. Raymond wrote: > This bug unconditionally disables a configuration question -- and it's > so old that it has propagated across three port files, without either > of the people who did the cut and paste for the latter two noticing it. in fact it was originally in i386 too. I noticed and fixed it, didn't even think about the other archs. > This sort of thing would never ship in CML2, because the compiler > would throw an undefined-symbol warning on BLK_DEV_ST. The temptation > to engage in sarcastic commentary at the expense of people who still > think CML2 is an unnecessary pain in the butt is great. But I will Most of these people don't seem to have been subscribed to kbuild-devel anyway, and missed most of the commentary over the past months. > - if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then > + if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then john -- "A reasonable probability is the only certainty." - E. W. Howe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Brown-paper-bag bug in m68k, sparc, and sparc64 config files
This bug unconditionally disables a configuration question -- and it's so old that it has propagated across three port files, without either of the people who did the cut and paste for the latter two noticing it. This sort of thing would never ship in CML2, because the compiler would throw an undefined-symbol warning on BLK_DEV_ST. The temptation to engage in sarcastic commentary at the expense of people who still think CML2 is an unnecessary pain in the butt is great. But I will restrain myself. This time. --- arch/m68k/config.in 2001/05/19 21:36:57 1.1 +++ arch/m68k/config.in 2001/05/19 21:37:12 @@ -192,7 +192,7 @@ int 'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 fi dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then + if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi dep_tristate ' SCSI CD-ROM support' CONFIG_BLK_DEV_SR $CONFIG_SCSI --- arch/sparc/config.in2001/05/19 21:34:54 1.1 +++ arch/sparc/config.in2001/05/19 21:35:21 @@ -162,7 +162,7 @@ dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then + if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi --- arch/sparc64/config.in 2001/05/19 21:37:33 1.1 +++ arch/sparc64/config.in 2001/05/19 21:37:45 @@ -146,7 +146,7 @@ dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then + if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Conservatism is the blind and fear-filled worship of dead radicals. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Has anybody a working pppoed for 2.4 (2.4.4-ac10/11)?
I have pppoed-0.48b1-6, ppp-2.4.0-5 (SuSE 7.1) but it didn't work (with kernel pppoe.o/pppox.o). So I have to use rp-pppoe-2.5-5 (which should be slower I've heard) for the German Telekom ADSL (product name TDSL). Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.4-ac11 aironet fixes
Patch looks generally ok. Comments: * you forgot to cc Elmer Joandi, the maintainer, who wakes up every now and then :) * When is aironet4500_card version string printed, for the modular case? * did you actually trace the code paths to mark sure code marked __init was never called by the pcmcia hotplug part of the code? I just want to make sure you didn't mark them __init due to an assumption based on function name. -- Jeff Garzik | "Do you have to make light of everything?!" Building 1024| "I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.4-ac11 network drivers cleaning
Patch looks decent. Adding module descriptions was quite nice. One flaw that is repeated multiple times is that you add #ifdef MODULE printk(version); #endif in an ISA driver's probe routine. This instead should always be the first operation of init_module. Also make sure to go through the 'ac' patch and review the earlier version string changes. Some of them were buggy, like static const char version[] __initdata = "..."; const combined with __[dev]initdata causes a section type conflict. A few of those popped up after the earlier patch was applied to 'ac'. Finally, I don't know if I mentioned this earlier, but to be complete and optimal, version strings should be a single variable 'version', such that it can be passed directly to printk like printk(version); Some net drivers are already like this, as I'm sure you know. Some net drivers have 'version', 'version2', 'version3' instead of just one long string. Some net drivers add KERN_xxx at printk time, instead of adding it to the 'version' var. Some net drivers do the following, which is really silly considering you know all strings at compile time: printk(KERN_INFO "%s\n", version); -- Jeff Garzik | "Do you have to make light of everything?!" Building 1024| "I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Alan Cox wrote: >>Second, how many kernels does Redhat ship in order to have one for >>386/486/586/k6/Athlon . . . . >>Quite a pain in the ass. And look at how much shit has to be built in >>in order to get a kernel that works for everybody! People bitch at >>Microsoft for doing it, then turn around and do the same thing. >> > >No people bitch at microsoft for precisely the opposite - not including a >way to build fully optimised setups for each cpu type - not including all the >stuff that is needed (try a generic win2k install on a vaio one day) > >I think you have your facts backwards > >Alan > No, my point was, if I don't have SCSI or RAID on this box, I don't want them to be built into the kernel! In other words, "stuff I don't need, just like Microsoft". -b -- "One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's alright not to know anything. That to me is far more dangerous than a little pornography on the Internet." - Carl Sagan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4 del_timer_sync oops in schedule_timeout
This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in. The oops got eaten by klogd, my apologies, but it seems sane even so. I haven't tried newer -ac or -pre kernels so I'm sure it's probably already fixed there but just in case it isn't... kdm[350]: Server for display :0 terminated unexpectedly: 2816 Unable to handle kernel paging request at virtual address 78626970 printing eip: c011bf13 *pde = Oops: 0002 CPU:0 EIP:0010:[del_timer_sync+47/132] EFLAGS: 00010006 eax: 732e7872 ebx: 0246 ecx: c651ff28 edx: 7862696c esi: edi: 0010 ebp: c651df3c esp: c651df0c ds: 0018 es: 0018 ss: 0018 Process XFree86 (pid: 356, stackpage=c651d000) Stack: c651ff28 0007edbb c0112b54 c651ff28 c651df28 c3b45260 c02ec12c c02ec12c 0007edbb c651c000 c0112a80 c651df70 c0140b7c 0008 0020 c7aea140 0304 c651c000 2d24 0015 Call Trace: [schedule_timeout+120/144] [process_timeout+0/92] [do_select+456/512] [sys_select+816/1136] [system_call+55/64] Code: 89 42 04 89 10 b8 01 00 00 00 01 c6 a1 68 20 30 c0 c7 41 04 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sat, 19 May 2001, Mike Galbraith wrote: > On Fri, 18 May 2001, Stephen C. Tweedie wrote: > > > That's the main problem with static parameters. The problem you are > > trying to solve is fundamentally dynamic in most cases (which is also > > why magic numbers tend to suck in the VM.) > > Magic numbers might be sucking some performance right now ;-) ... so you replace them with some others ... ;) > Three back to back make -j 30 runs for three different kernels. > Swap cache numbers are taken immediately after last completion. The performance increase is nice, though. Do you see similar changes in different kinds of workloads ? > (yes, the last hunk looks out of place wrt my text. It also looks kind of bogus and geared completely towards this particular workload ;) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.4-ac11 aironet fixes
Hi,
The following patch fixes aironet drivers. It contains
- fixed Config.in to disable non-working configurations (PNP without isapnp,
built-in ISA or I365)
- marked __init/__devinit/__devinitdata some initial code/variables
- disable (#if 0) currently unused function (awc4500_pnp_hw_reset)
- version printing fixes
- long delay fixes (udelay()->mdelay())
- added MODULE_PARM_DESC
- functions with local onlu use marked static
- removes duplicated version string from PCMCIA driver.
Andrzej
diff -ur linux-2.4.4-ac11/drivers/net/Config.in linux/drivers/net/Config.in
--- linux-2.4.4-ac11/drivers/net/Config.in Fri May 18 17:56:21 2001
+++ linux/drivers/net/Config.in Fri May 18 23:27:59 2001
@@ -260,10 +260,14 @@
tristate ' Aironet 4500/4800 series adapters' CONFIG_AIRONET4500
dep_tristate ' Aironet 4500/4800 ISA/PCI/PNP/365 support '
CONFIG_AIRONET4500_NONCS $CONFIG_AIRONET4500
if [ "$CONFIG_AIRONET4500" != "n" -a "$CONFIG_AIRONET4500_NONCS" != "n" ]; then
- bool ' Aironet 4500/4800 PNP support ' CONFIG_AIRONET4500_PNP
+ if [ "$CONFIG_AIRONET4500_NONCS" = "m" -a "$CONFIG_ISAPNP" = "m" -o
+"$CONFIG_ISAPNP" = "y" ]; then
+bool ' Aironet 4500/4800 PNP support ' CONFIG_AIRONET4500_PNP
+ fi
dep_bool ' Aironet 4500/4800 PCI support ' CONFIG_AIRONET4500_PCI
$CONFIG_PCI
- dep_bool ' Aironet 4500/4800 ISA broken support (EXPERIMENTAL)'
CONFIG_AIRONET4500_ISA $CONFIG_EXPERIMENTAL
- dep_bool ' Aironet 4500/4800 I365 broken support (EXPERIMENTAL)'
CONFIG_AIRONET4500_I365 $CONFIG_EXPERIMENTAL
+ if [ "$CONFIG_AIRONET4500_NONCS" = "m" ]; then
+dep_bool ' Aironet 4500/4800 ISA broken support (EXPERIMENTAL)'
+CONFIG_AIRONET4500_ISA $CONFIG_EXPERIMENTAL
+dep_bool ' Aironet 4500/4800 I365 broken support (EXPERIMENTAL)'
+CONFIG_AIRONET4500_I365 $CONFIG_EXPERIMENTAL
+ fi
fi
dep_tristate ' Aironet 4500/4800 PROC interface ' CONFIG_AIRONET4500_PROC
$CONFIG_AIRONET4500 m
diff -ur linux-2.4.4-ac11/drivers/net/aironet4500_card.c
linux/drivers/net/aironet4500_card.c
--- linux-2.4.4-ac11/drivers/net/aironet4500_card.c Tue May 1 21:14:31 2001
+++ linux/drivers/net/aironet4500_card.cFri May 18 22:59:20 2001
@@ -11,10 +11,6 @@
* Jeff Garzik - softnet, cleanups
*
*/
-#ifdef MODULE
-static const char *awc_version =
-"aironet4500_cards.c v0.2 Feb 27, 2000 Elmer Joandi, [EMAIL PROTECTED]\n";
-#endif
#include
#include
@@ -56,6 +52,11 @@
#define AIRONET4500_3654
+static char awc_version[] __devinitdata =
+KERN_INFO "aironet4500_cards.c v0.2 Feb 27, 2000 Elmer Joandi,
[EMAIL PROTECTED]\n";
+
+static int version_printed __devinitdata = 0;
+
#ifdef CONFIG_AIRONET4500_PCI
#include
@@ -75,7 +76,7 @@
int ioaddr, int cis_addr, int mem_addr,u8 pci_irq_line) ;
-int awc4500_pci_probe(struct net_device *dev)
+int __devinit awc4500_pci_probe(struct net_device *dev)
{
int cards_found = 0;
static int pci_index; /* Static, for multiple probe calls. */
@@ -136,6 +137,11 @@
// request_region(pci_cisaddr, AIRONET4X00_CIS_SIZE, "aironet4x00 cis");
// request_region(pci_memaddr, AIRONET4X00_MEM_SIZE, "aironet4x00 mem");
+#ifndef MODULE
+ if (!version_printed++)
+ printk(awc_version);
+#endif /* MODULE */
+
mdelay(10);
pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
@@ -164,7 +170,7 @@
}
-static int awc_pci_init(struct net_device * dev, struct pci_dev *pdev,
+static int __devinit awc_pci_init(struct net_device * dev, struct pci_dev *pdev,
int ioaddr, int cis_addr, int mem_addr, u8 pci_irq_line) {
int i, allocd_dev = 0;
@@ -294,6 +300,7 @@
#define PNP_BUS_NUMBER number
#define PNP_DEV_NUMBER devfn
+#if 0 /* unused ? */
int awc4500_pnp_hw_reset(struct net_device *dev){
struct isapnp_logdev *logdev;
@@ -331,8 +338,9 @@
return 0;
}
+#endif /* 0 */
-int awc4500_pnp_probe(struct net_device *dev)
+int __init awc4500_pnp_probe(struct net_device *dev)
{
int isa_index = 0;
int isa_irq_line = 0;
@@ -383,6 +391,12 @@
return -ENOMEM;
}
}
+
+#ifndef MODULE
+ if (!version_printed++)
+ printk(awc_version);
+#endif /* MODULE */
+
dev->priv = kmalloc(sizeof(struct awc_private),GFP_KERNEL );
memset(dev->priv,0,sizeof(struct awc_private));
if (!dev->priv) {
@@ -523,7 +537,7 @@
-int awc4500_isa_probe(struct net_device *dev)
+static int __init awc4500_isa_probe(struct net_device *dev)
{
// int cards_found = 0;
// static int isa_index; /* Static, for multiple probe calls. */
@@ -670,18 +684,18 @@
int product;
};
-inline u8 i365_in (struct i365_socket * s, int offset
[PATCH] 2.4.4-ac11 network drivers cleaning
>From kufel!root Sat May 19 23:39:35 2001
Return-Path:
Received: from kufel.UUCP (uucp@localhost)
by green.mif.pg.gda.pl (8.9.3/8.9.3) with UUCP id XAA02226
for green.mif.pg.gda.pl!ankry; Sat, 19 May 2001 23:39:35 +0200
Received: (from root@localhost)
by kufel.dom (8.9.3/8.9.3) id XAA02243
for ankry@green; Sat, 19 May 2001 23:40:52 +0200
Date: Sat, 19 May 2001 23:40:52 +0200
From: root
Message-Id: <[EMAIL PROTECTED]>
To: kufel!green.mif.pg.gda.pl!ankry
Subject: 3com
Hi Alan,
The following patch is a preliminary attempt for cleaning network drivers in
2.4 (drivers for 3Com boards for beginning). It contains:
- cleaning version printing as Jeff suggests (modular - always, built in -
if detected)
- added MODULE_PARM_DESC (the main reason I've created the patch)
- made version __initdata
- a comment fix (3c501)
- added KERN_* markers to some printk's (only a few)
- enabled modular isapnp usage by 3c509
BTW, Looking at the "options" parameter in some drivers I found that using
it might be ugly in some cases and do not allow specyfic settings. For
example it is difficult to set 10Mbps/half-duplex not changing media type in
some drivers as it requires "options=0" setting, which is simply ignored.
Parameters like duplex setting should be IMO three-state (full/half/not
changed) while there's only one bit in "options" assigned to them currently.
Jeff, Alan, what do you think of changing the method for media/link type
setting and unifying it across drivers ?
Of course, I think of it as a 2.5 project...
Andrzej
**
diff -ur linux-2.4.4-ac11/drivers/net/3c501.c linux/drivers/net/3c501.c
--- linux-2.4.4-ac11/drivers/net/3c501.cTue May 1 21:14:30 2001
+++ linux/drivers/net/3c501.c Fri May 18 23:44:28 2001
@@ -238,6 +238,10 @@
SET_MODULE_OWNER(dev);
+#ifdef MODULE
+ printk(version);
+#endif /* MODULE */
+
if (base_addr > 0x1ff) /* Check a single specified location. */
return el1_probe1(dev, base_addr);
else if (base_addr != 0)/* Don't probe at all. */
@@ -251,7 +255,7 @@
}
/**
- * el1_probe:
+ * el1_probe1:
* @dev: The device structure to use
* @ioaddr: An I/O address to probe at.
*
@@ -270,6 +274,7 @@
unsigned char station_addr[6];
int autoirq = 0;
int i;
+ static int printed_version;
/*
* Reserve I/O resource for exclusive use by this driver
@@ -340,15 +345,17 @@
if (autoirq)
dev->irq = autoirq;
+#ifndef MODULE
+ if (!printed_version++)
+ printk(version);
+#endif /* MODULE */
+
printk(KERN_INFO "%s: %s EtherLink at %#lx, using %sIRQ %d.\n", dev->name,
mname, dev->base_addr,
autoirq ? "auto":"assigned ", dev->irq);
#ifdef CONFIG_IP_MULTICAST
printk(KERN_WARNING "WARNING: Use of the 3c501 in a multicast kernel is NOT
recommended.\n");
-#endif
-
- if (el_debug)
- printk(version);
+#endif /* CONFIG_IP_MULTICAST */
/*
* Initialize the device structure.
@@ -925,6 +932,8 @@
static int irq=5;
MODULE_PARM(io, "i");
MODULE_PARM(irq, "i");
+MODULE_PARM_DESC(io, "EtherLink I/O base address");
+MODULE_PARM_DESC(irq, "EtherLink IRQ number");
/**
* init_module:
diff -ur linux-2.4.4-ac11/drivers/net/3c503.c linux/drivers/net/3c503.c
--- linux-2.4.4-ac11/drivers/net/3c503.cTue May 1 21:14:30 2001
+++ linux/drivers/net/3c503.c Fri May 18 23:45:06 2001
@@ -178,8 +178,10 @@
goto out;
}
-if (ei_debug && version_printed++ == 0)
+#ifndef MODULE
+if (version_printed++ == 0)
printk(version);
+#endif /* MODULE */
dev->base_addr = ioaddr;
/* Allocate dev->priv and fill in 8390 specific dev fields. */
@@ -615,6 +617,8 @@
MODULE_PARM(io, "1-" __MODULE_STRING(MAX_EL2_CARDS) "i");
MODULE_PARM(irq, "1-" __MODULE_STRING(MAX_EL2_CARDS) "i");
MODULE_PARM(xcvr, "1-" __MODULE_STRING(MAX_EL2_CARDS) "i");
+MODULE_PARM_DESC(io, "EtherLink II I/O base address(es)");
+MODULE_PARM_DESC(irq, "EtherLink II IRQ number(s) (assigned)");
/* This is set up so that only a single autoprobe takes place per call.
ISA device autoprobes on a running machine are not recommended. */
@@ -623,6 +627,7 @@
{
int this_dev, found = 0;
+ printk(version);
for (this_dev = 0; this_dev < MAX_EL2_CARDS; this_dev++) {
struct net_device *dev = &dev_el2[this_dev];
dev->irq = irq[this_dev];
diff -ur linux-2.4.4-ac11/drivers/net/3c505.c linux/drivers/net/3c505.c
--- linux-2.4.4-ac11/drivers/net/3c505.cSat Apr 28 20:34:50 2001
+++ linux/drivers/net/3c505.c Fri May 18 19:38:44 2001
@@ -1621,6 +1621,9 @@
MODULE_PARM(io, "1-" __MODULE_STRING(ELP_MAX_CARDS) "i");
MODULE_PARM(irq, "1-" __MODULE_STRING(ELP_MAX_CARDS) "i");
MODULE_PARM(dma, "1-" __MODULE_STRING(ELP_MAX
serpent loopback crypto "EXT2-fs: group descriptors corrupted"
hi, i created a 10mb file called .enc2 with random data and ran "# losetup -e serpent -k 128 /dev/loop0 /mnt/hda7/.enc2" then i ran "# mke2fs /dev/loop0" and tried to "# mount /dev/loop0 /enc". but i get the following error messages when trying to mount: May 19 21:32:10 HOST2 kernel: EXT2-fs error (device loop(7,0)): ext2_check_descriptors: Block bitmap for group 16 not in group (block 0)! May 19 21:32:10 HOST2 kernel: EXT2-fs: group descriptors corrupted ! im using kernel 2.4.4 patched with crypto patch 2.4.3.1 [and util linux 2.11a patched with the patch from that crypto patch] i also got the same errors with a 2gb file and by creating the loop device directly on my 19.5gb /dev/hda7 i tried a few times again and sometimes the encrypted loopback fs works perfectly, sometimes the error occurs!? anyone got an idea what this is!? i will supply more information on request thx for your help - peter k. ps: dont kill me if im doing something wrong, this is the first time im mailing to this list ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Sat, May 19, 2001 at 02:48:15PM +0400, Ivan Kokshaysky wrote: > This is incorrect. If you want directly mapped PCI window then you don't > need the iommu_arena for it. If you want scatter-gather mapping, you > should write address of the SG page table into the T3_BASE register. i've tried both direct mapped and sg, but it still get pci_map_sg() failures in sym53c8xx. the sg version, below, won't boot (scsi commands all timeout). while the added direct map version does boot, it suffers the same problem as the stock code. third direct map: hose->sg_pci = NULL; hose->sg_isa = iommu_arena_new(hose, 0x0080, 0x0080, 32768); __direct_map_base = 0x4000; __direct_map_size = 0x8800; *(vip)CIA_IOC_PCI_W3_BASE = 0xc000 | 1; *(vip)CIA_IOC_PCI_W3_MASK = (0x0800 - 1) & 0xfff0; *(vip)CIA_IOC_PCI_T3_BASE = 0x8000 >> 2; sg (doesn't work): hose->sg_isa = iommu_arena_new(hose, 0x0080, 0x0080, 32768); hose->sg_pci = iommu_arena_new(hose, 0xc000, 0x0800, 32768); __direct_map_base = 0x4000; __direct_map_size = 0x8000; *(vip)CIA_IOC_PCI_W3_BASE = hose->sg_pci->dma_base | 3; *(vip)CIA_IOC_PCI_W3_MASK = (hose->sg_pci->size - 1) & 0xfff0; *(vip)CIA_IOC_PCI_T3_BASE = virt_to_phys(hose->sg_pci->ptes) >> 2; -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, May 19, 2001 at 09:38:03PM +0200, Erik Mouw wrote: > > But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see > > if it's there. writing to files that aren't shown in directory listings > > is plain evil. I really don't want to explain why. It's extremely > > messy and unintuitive. > > > > It would be better to do this with a file that does exist, for example > > writing something to /proc/disks/sda/arguments. Then again, I don't > > even think much of dynamic file systems in the first place. > > A network socket also isn't a file in a filesystem, you can't do ls on > it, it doesn't even exist until you create one, but still you use it as > a file by reading and writing it. I don't see any difference in the way > you create /dev/sda/offset=234234,limit=626737537 by just using it. I think you're kind of missing the point. Erik is saying that, by the path, it appears to be a file, even though it isn't listed as a file in the directory /dev/sda. Network sockets don't have a path, unless its a Unix domain socket, and then you /can/ 'ls' it. My opinion is that putting options directly in the open is no nicer than an ioctl. I think that where this scheme really shines, though, is where there are multiple logical channels to a device, as in the /dev/fb0/control example. I like that. What could be done, therefore, is have a /dev/ttyS0/control file, where you could "echo 'baud=19200,parity=odd' > /dev/ttyS0/control" or even "echo '19200' > /dev/ttyS0/baud" and "echo 'odd' > /dev/ttyS0/parity". That seems to me to be the cleanest and most logical solution. As for this partition stuff, it seems a bad example to me. Maybe I'm just spoiled, but I think partitions is something that the kernel can and should abstract. None of this /dev/sda/offset=12345,limit=45678 madness. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Fri, May 18, 2001 at 03:17:50PM +0100, Stephen C. Tweedie wrote: > Hi, > > On Wed, May 16, 2001 at 12:18:15PM -0400, Michael Meissner wrote: > > > With the current LABEL= support, you won't be able to mount the disks with > > duplicate labels, but you can still mount them via /dev/sd. > > Or you can fall back to mounting by UUID, which is globally unique and > still avoids referencing physical location. You also don't need to > manually set LABELs for UUID to work: all e2fsprogs over the past > couple of years have set UUID on partitions, and e2fsck will create a > new UUID if it sees an old filesystem that doesn't already have one. Presumably, a new UUID is created each time format a partition, which means it is a slight bit of hassle if you have to reload a partition from a dump, or copy a partition to another disk drive. In the scheme of things, it is not a large hassle perhaps, but it is a hassle. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]
On Saturday 19 May 2001 21:43, Pavel Machek wrote: > I think that plan9 uses something different -- they have ttyS0 and > ttyS0ctl. This would leave us with problem "how do I get handle to > ttyS0ctl when I only have handle to ttyS0"? One possibility is to add multiforked (multi-stream) file support to Linux, then you could have a control stream. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potential help for VIA problems and ASUS motherboards
John Cavan wrote: > > Hi, > > I've seen a lot of messages regarding problems with the VIA chipset... > I've experienced them myself. > > Anyways, I just put in a new ASUS CUV4X-D motherboard, BIOS revision > 1004. Once installed, I ran into a raft of problems when IO-APIC was > enabled... and discovered that ASUS had a BIOS update (revision 1007) > available. Once the BIOS was updated and MPS 1.4 support was disabled, > everything has been working fine, including USB with IO-APIC enabled. I > also don't seem to be getting the timer problem anymore. > > Anyways, if you have one of these boards, you may want to flash your > BIOS and see if the problems are fixed. YMMV, but it worked for me. I'm curious if 2.4.5-pre3 works for you... when using MPS 1.4, or, without the BIOS update. Regards, Jeff -- Jeff Garzik | "Do you have to make light of everything?!" Building 1024| "I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA politics (was: VIA's Southbridge bug: Latest (pseudo-)patch)
On Sat, May 19, 2001 at 05:11:30PM +0100, Alan Cox wrote:
> > This are the latest suggestions for handling the VIA Southbridge bug as
> > derived from the hardware site www.au-ja.de (Many thanks to doelf).
>
> I'd rather people left this except for the obvious fixed that were done for
> non VIA northbridge combinations until 2.5. 2.4 is not an appropriate place
> to play with possibly disk corrupting PCI hacks without documentation.
>
> What is pathetic is that VIA have yet to place anything in the public domain
> giving correct workarounds. People are picking at BIOSes praying to spot all
> the changes (which may not be in the PCI registers even) because a vendor
> hasn't got the decency to admit they screwed up and then to issue proper
> fixes
these are my feelings, too. But I try to be an optimist - this is the reason
for the extended Cc: list, maybe it might trigger some change of those
politics. Note that Yiping Chen <[EMAIL PROTECTED]> had contacted this
list a few weeks ago to ask how to contribute drivers to Linux, indicating
perhaps a first step towards VIA going public domain.
Placing more documentation in the public domain would also help Linux
construct the right pirq routing tables, which is also a showstopper for
certain KT133A setups.
> If it had been a manufacturer in most respectable areas of business they'd
> be recalling and reissuing components, and paying for the end resllers to
> notify each customer
Let's hope VIA will indeed change politics. Either the bug is not fixable and
VIA should recall, or the bug/fix should be cleanly documented. Currently VIA
is hoping to survive this fiasco by not drawing too much attention ("it was
the SB"), but this may become a boomerang (I for my part will try to have the
motherboard replaced after having been haunted for the last 6 weeks).
At the very end there are us, the user, who would not want to wait for 2.5
(speak 2.6 for the common user ...). Of course Linux is not to blame, but it
is indeed a big user community hit by this.
Regards, Axel.
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
Linus Torvalds wrote:
>
> [ Attribution is gone, so I just deleted it.. ]
>
> > > > > fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> > > >
> > > > Hmm, there might be problem with this. How do you change speed without
> > > > reopening device? [Remember: your mice knows when you close device]
>
> The naming scheme is not a replacement for these kinds of ioctl's - it's
> just a way to make them less critical, and get people thinking in other
> directions so that we don't get _more_ ioctl's.
However
fchdir(fd);
s = open("speed");
write(s, "19200\n", 6);
would be enough to solve the problem Pavel is pointing also without the
need to use ioctl.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Getting FS access events
On Sat, 19 May 2001, Pavel Machek wrote: > > > Don't get _too_ hung up about the power-management kind of "invisible > > suspend/resume" sequence where you resume the whole kernel state. > > Ugh. Now I'm confused. How do you do usefull resume from disk when you > don't restore complete state? Do you propose something like "write > only pagecache to disk"? Go back to the original _reason_ for this whole discussion. It's not really a "resume" event, it's a "populate caches really efficiently at boot" event. But the two are basically the same problem, it's only a matter of how much you populate (do you populate _everything_ or do you populate just disk caches. Populating just the caches is the smaller and simpler problem, that only solves the "fast boot" issue). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Getting FS access events
Hi! > > resume from disk is actually pretty hard to do in way it is readed linearily. > > > > While playing with swsusp patches (== suspend to disk) I found out that > > it was slow. It needs to do atomic snapshot, and only reasonable way to > > do that is free half of RAM, cli() and copy. > > Note that "resume from disk" does _not_ have to necessarily resume kernel > data structures. It is enough if it just resumes the caches etc. > Don't get _too_ hung up about the power-management kind of "invisible > suspend/resume" sequence where you resume the whole kernel state. Ugh. Now I'm confused. How do you do usefull resume from disk when you don't restore complete state? Do you propose something like "write only pagecache to disk"? Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]
Hi! > > Well, if we did something like modify(int fd, char *how), you could do > > > > modify(0, "nonblock,9600") > > What you're really proposing is to make ioctl's be ASCII strings. Yup. > Which is not necessarily a bad idea, and I think plan9 did something > similar (or rather, if I remember correctly, plan9 has control streams > that were ASCII. Or am I confused?). I think that plan9 uses something different -- they have ttyS0 and ttyS0ctl. This would leave us with problem "how do I get handle to ttyS0ctl when I only have handle to ttyS0"? ... > However, you can't really use a string. It would really have to be two > memory regions: incoming and outgoing, with an ASCII representation being > the _preferred_ method for stuff that isn't obviously structured or > performance-critical. What are cases where it is usefull to pass data back from kernel? ...aha, serial controls include possibility to read stuff, right? Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] Signal-per-fd for RT signals
Vitaly Luban wrote: > > Hi, > > the form of POLL_... This will bring functionality of RT > signals event notification on the level with 'select' or > 'poll' one, while more efficient and scalable. If there's > an interest in such a feature, I'd be eager to publish a > patch. > > Thanks, > Vitaly. > I have been waiting for this patch since 2.4.0. The SIGIO signal is a nightmare when it arrives : The machine is already under high load and has to stop using the most efficient way to handle it. The filter changes would be the cream on top of this patch. Do not hurry, but please not for long. best Regards Gerold - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Getting FS access events
On Tue, 15 May 2001, Pavel Machek wrote: > > resume from disk is actually pretty hard to do in way it is readed linearily. > > While playing with swsusp patches (== suspend to disk) I found out that > it was slow. It needs to do atomic snapshot, and only reasonable way to > do that is free half of RAM, cli() and copy. Note that "resume from disk" does _not_ have to necessarily resume kernel data structures. It is enough if it just resumes the caches etc. Don't get _too_ hung up about the power-management kind of "invisible suspend/resume" sequence where you resume the whole kernel state. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, May 19, 2001 at 10:45:11AM -0700, Aaron Lehmann wrote: > On Sat, May 19, 2001 at 06:48:19PM +0200, Erik Mouw wrote: > > One of the fundamentals of Unix is that "everything is a file" and that > > you can do everything by reading or writing that file. > > But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see > if it's there. writing to files that aren't shown in directory listings > is plain evil. I really don't want to explain why. It's extremely > messy and unintuitive. > > It would be better to do this with a file that does exist, for example > writing something to /proc/disks/sda/arguments. Then again, I don't > even think much of dynamic file systems in the first place. A network socket also isn't a file in a filesystem, you can't do ls on it, it doesn't even exist until you create one, but still you use it as a file by reading and writing it. I don't see any difference in the way you create /dev/sda/offset=234234,limit=626737537 by just using it. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
On Sat, 19 May 2001, Pavel Machek wrote: > > Well, if we did something like modify(int fd, char *how), you could do > > modify(0, "nonblock,9600") What you're really proposing is to make ioctl's be ASCII strings. Which is not necessarily a bad idea, and I think plan9 did something similar (or rather, if I remember correctly, plan9 has control streams that were ASCII. Or am I confused?). > I thought about how to do networking without sockets, and it seems to > me like this kind of modify syscall is needed, because network sockets > connect to *two* different places (one local address and one > remote). Sockets are really nasty :-(. One of the horrors of ioctl's is indeed that they are not very well-defined, and as such cannot be transported over a network without knowing more about them. Structuring them some way would already be very useful. the _IOC() macros do this partially, of course, but because it is a voluntary thing it is not actually followed all that well in general, and most ioctl names are just random numbers that don't tell the structure of the arguments or return values. And a "stream of bytes" is in a very real sense the simplest structure, and is the unix way (and the plan9 way is to avoid binary streams, and use ASCII text instead when possible, whihc probably also makes sense). However, you can't really use a string. It would really have to be two memory regions: incoming and outgoing, with an ASCII representation being the _preferred_ method for stuff that isn't obviously structured or performance-critical. Let's not take this too far, though. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion codeinuserspace
On Sat, 19 May 2001, Brad Boyer wrote: > > If I understand the status of stuff correctly, I think this would make it > a lot more painful to admin if it became a requirement to use initrd on > everything just to be able to boot. Don't get too hung up on initrd. Symbolic links really _are_ workable ways to basically cache the information across boots, and the real problems are elsewhere. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
Aaron Lehmann wrote: > On Sat, May 19, 2001 at 08:05:02PM +0200, [EMAIL PROTECTED] wrote: > > > initrd is an unnecessary pain in the ass for most people. > > > It had better not become mandatory. > > > > You would not notice the difference, only your kernel would be > > a bit smaller and the RRPART ioctl disappears. > > Would I not notice the difference as a user, as a sysadmin, as a > kernel builder, as a kernel hacker, or all of the above? If I understand the status of stuff correctly, I think this would make it a lot more painful to admin if it became a requirement to use initrd on everything just to be able to boot. If you've ever seen the way some of the bootloaders for alterate platforms (like ppc and 68k) handle booting, you'd see what a pain it can be to have anything more than a simple string of options getting passed to the kernel. It's particularly bad on some of the embedded ppc platforms. I suspect that if this happened, it would never be allowed into many people's trees, because it would be worth their effort to maintain different code so they don't have to squeeze an initrd on flash along with their kernel and root filesystem. If I'm missing the boat here, please tell me, but it sure seems like a bad idea to me. Brad Boyer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mount misbehaviour?
> root@bug:/zip# mount /zip > root@bug:/zip# ls -al > total 8 > drwxr-xr-x2 root root 4096 Dec 1 08:29 . > drwxr-xr-x 31 65534root 4096 Apr 24 20:56 .. > root@bug:/zip# cd /zip > root@bug:/zip# ls -al > total 22182 > ... > Is that okay? Yes. Your working directory does not change when you mount something. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Number Registrants]
Hi!
> > > > > fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> > > >
> > > > Hmm, there might be problem with this. How do you change speed without
> > > > reopening device? [Remember: your mice knows when you close device]
>
> The naming scheme is not a replacement for these kinds of ioctl's - it's
> just a way to make them less critical, and get people thinking in other
> directions so that we don't get _more_ ioctl's.
>
> Remember, the serial lines we already have legacy support for, that's not
> going away. The termios-based stuff isn't Linux-only, and we'll
> obviously maintain it for the forseeable future.
Well, if we did something like modify(int fd, char *how), you could do
modify(0, "nonblock,9600")
which looks slightly better than special ioctl. You could even hack
libc to emulate ioctl with modify.
I thought about how to do networking without sockets, and it seems to
me like this kind of modify syscall is needed, because network sockets
connect to *two* different places (one local address and one
remote). Sockets are really nasty :-(.
> But if we can use naming to avoid ioctl's in the future, then THAT is
> good. I'm in particular thinking about frame-buffer and similar things,
> where we might be able to avoid making the situation worse.
Yup. OTOH making "new" system so powerfull that it could lead to
ioctls emulated in libc would be very nice, too.
Pavel
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
From [EMAIL PROTECTED] Sat May 19 20:07:23 2001 > > initrd is an unnecessary pain in the ass for most people. > > It had better not become mandatory. > > You would not notice the difference, only your kernel would be > a bit smaller and the RRPART ioctl disappears. Would I not notice the difference as a user, as a sysadmin, as a kernel builder, as a kernel hacker, or all of the above? All of the above. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Sat, May 19, 2001 at 03:55:02PM +0200, Andrea Arcangeli wrote: > Reading the tsunami specs I learnt 1 tlb entry caches 8 pagetables (not 1) > so the tlb flush will be invalidate immediatly by any PCI DMA run after > the flush on any of the other 7 mappings cached in the same tlb entry. I have neither tsunami docs nor the tsunami box to play with :-( so my guesses might be totally wrong... But -- assuming that tsunami is similar to cia/pyxis, that is incorrect. We're invalidating not the cached ptes, but the TLB tags, with all 4 (on pyxis, and 8 on tsunami, I guess) associated ptes. The reason why we align new entries at 4*PAGE_SIZE on cia/pyxis is a hardware bug -- if cached pte is invalid, it doesn't cause TLB miss. I wouldn't be surprised at all if tsunami has the same bug; in this case your fix is urgently needed, of course. BTW, look at Richard's code in core_cia.c/verify_tb_operation() for "valid tag invalid pte reload" test, it could be easily ported to tsunami. > then I also enlarged the pci SG space to 1G beause runing out of entries > right now breaks the whole world: It would just delay the painful death, I think ;-) I'm almost sure that all these "pci_map_sg failed" reports are caused by some buggy driver[s], which calls pci_map_xx() without proper pci_unmap_xx(). This is harmless on i386, and on alpha if all IO is going through direct-access windows. I've got some debugging code checking for this (perhaps it worth posting or even porting to i386 ;-) For now I can confirm that all drivers I'm currently using are fine wrt pci_map/unmap: 3c59x, tulip, sym53c8xx, IDE. Ivan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mount misbehaviour?
Hi! I just had small surprise with 2.4.0: root@bug:/zip# mount /zip root@bug:/zip# ls -al total 8 drwxr-xr-x2 root root 4096 Dec 1 08:29 . drwxr-xr-x 31 65534root 4096 Apr 24 20:56 .. root@bug:/zip# cd /zip root@bug:/zip# ls -al total 22182 drwxr-xr-x4 root root16384 Jan 1 1970 . drwxr-xr-x 31 65534root 4096 Apr 24 20:56 .. -rw-r--r--1 root root 22687788 May 18 11:48 delme.wav drwxr-xr-x2 root root 2048 May 18 11:30 karantena drwxr-xr-x5 root root 2048 May 9 14:15 statnice ...Mounting directory under me does not seem healthy. cd fixes it... Is that okay? Pavel PS: Al, would you please add credit line for yourselves? pavel@bug:/usr/src/linux$ grep Viro CREDITS pavel@bug:/usr/src/linux$ grep Viro MAINTAINERS pavel@bug:/usr/src/linux$ -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
[ Attribution is gone, so I just deleted it.. ]
> > > > fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> > >
> > > Hmm, there might be problem with this. How do you change speed without
> > > reopening device? [Remember: your mice knows when you close device]
The naming scheme is not a replacement for these kinds of ioctl's - it's
just a way to make them less critical, and get people thinking in other
directions so that we don't get _more_ ioctl's.
Remember, the serial lines we already have legacy support for, that's not
going away. The termios-based stuff isn't Linux-only, and we'll
obviously maintain it for the forseeable future.
But if we can use naming to avoid ioctl's in the future, then THAT is
good. I'm in particular thinking about frame-buffer and similar things,
where we might be able to avoid making the situation worse.
And remember where this discussion started: not ioctl's, but device
numbers. The _biggest_ advantage of naming may be to get rid of the need
for extra major and minor numbers, and cleaning up /dev in the process-
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, 19 May 2001, Alan Cox wrote: > > > Now that I'm awake and refreshed, yeah, that's awful. But > > echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane. Heck, > > the system can even send back result codes that way. > > Only to an English speaker. I suspect Quebec City canadians would prefer a > different command set. I was waiting for the "anglo-saxon" argument. I don't think it's a valid argument. You already have "/dev". You already have english names for the numbers in ioctl's (and let's not be mentally dishonest and say "numbers are cross-cultural", because NOBODY MUST EVER USE THE RAW NUMBERS - you have to use the anglo-saxon #define'd names because the numbers aren't even cross-platform on Linux, much less portable to other systems). So the "English is bad" argument is a complete non-argument. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion codein userspace
On Sat, 19 May 2001, Ben LaHaise wrote: > > 1. Generic lookup method and argument parsiing (fs/lookupargs.c) Looks sane. > 2. Restricted block device (drivers/block/blkrestrict.c) This is not very user-friendly, but along with symlinks this makes perfect sense. It would make partition handling a _lot_ simpler. Note, however, that I think the "restricted block device" is a much more generic issue than just block devices. I've already discussed with Alan the possibility of making _all_ file descriptors have the notion of "restrictions", notably the "start, end" kind of things. It is very useful for other things too - imagine opening /dev/mem, and wanting to pass a restricted portiong of it to other processes with the standard file descriptor passing facilities (think "secure DGA" for the X server, but also think untrusted users that can read parts of shared files etc - a suid program that opens a file, restricts it, drops privileges and knows that the program can only access a specific part of the file) > 3. Userspace partition code proposal Yes and no. I absolutely thihnk the idea that users actually _using_ these names is a horrible one, and fraught with potential for much too easy mistakes that end up being disastrous. But having symlinks that are created by a special program would be ok. [ Also, note how symlinks would make the point of initrd completely moot. You don't have to have initrd to initialize the thing, you can initialize the thing at installation time and when doing fdisk, and the symlinks would act as the permanent markers. ] HOWEVER, you have to realize that there are serious security and maintenance issues here, and I think your idea breaks down completely because of that. The thing is, you only have permissions on a "per-object" basis, and it's common practice to have different permissions for different partitions. Your scheme does not allow this. Which means that it is fundamentally broken. Sorry. So don't go overboard. The name-based thing is useful, but it's useful for only certain things. And you must _never_ forget the security and management issues. For example, if you can open a serial port in the first place, you can set its baud-rate. So it's ok to make baud-rate part of the name. And once you have permission to read /dev/fd0 it doesn't make sense to limit you to one particular format. So it's ok to have the disk format be part of the name. But it's not possible to make the partition be a "name" issue. Because while you obviously need different names, you _also_ need different permissions. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Make Acer Extensa 50X Sound work without hanging the
Hello, On 19-May-2001 Alan Cox wrote: >> since ages owners of a Extensa 50X notebook apply the following diff to the >> kernel to make the sound work without hanging the whole system. > > With what sound card ? > opl3sa2. I use alsa 0.5.11. -- Bye, Michael Leun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Chris Wedgwood wrote: > > Or you can fall back to mounting by UUID, which is globally > unique and still avoids referencing physical location. You also > don't need to manually set LABELs for UUID to work: all e2fsprogs > over the past couple of years have set UUID on partitions, and > e2fsck will create a new UUID if it sees an old filesystem that > doesn't already have one. > > Other filesystems such as reiserfs at present don't have such a > thing. I brought this a while ago and in theory it's not too hard, we > just need to get Hans to officially designate part of the SB or > whatever for the UUID. > > --cw > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ work out a patch with monstr, and I am sure he will accept it. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DVD blockdevice buffers
/dev/raw* Where? I can't find it in my .config (grep RAW .config). I am using 2.4.4-ac11 and playing w/ 2.4.5-pre3. TIA Adam Schrotenboer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sat, 19 May 2001, Alexander Viro wrote:
>
> Folks, before you get all excited about cramming side effects into
> open(2), consider the following case:
Your argument is stupid, imnsho.
Side-effects are perfectly fine if they are _local_ to the file
descriptor. Your example is contrieved and idiotic.
Filename extensions would not replace ioctl's. But they are wonderful ways
to avoid unnecessary binary name-spaces, like the ones we have with
"callout" TTY names, and the one that the fb people had.
For example, do a "ls -l /dev/fd0*", and ponder. Also, realize that we
have these hard-coded names in _addition_ to the magic ioctl to set even
more parameters. These are all stupid and bad, and it would have been a
_lot_ cleaner to be able to do
open("/dev/fd0/H1440", O_RDWR)..
or
open("/dev/fd0/HD,18,85", O_RDWD)
to open special non-standard high-density modes.
We already did this, in a very limited and stupid way, by encoding the
minor number and generating a standard naming scheme. We can do the same
thing in a _much_ more generic way by just realizing that we wanted the
open to be name-based in the first place.
These are _not_ side effects. They are very much naming conventions. If I
want to open a the floppy in one of the special extended modes, it makes a
LOT more sense to just open it with the naming, than to open a "generic"
floppy device only to them use a magic and very unreadable ioctl to set
the mode of the device.
In short, I don't buy your arguments for one single second.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
On Sat, May 19, 2001 at 08:05:02PM +0200, [EMAIL PROTECTED] wrote: > > initrd is an unnecessary pain in the ass for most people. > > It had better not become mandatory. > > You would not notice the difference, only your kernel would be > a bit smaller and the RRPART ioctl disappears. Would I not notice the difference as a user, as a sysadmin, as a kernel builder, as a kernel hacker, or all of the above? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
> initrd is an unnecessary pain in the ass for most people. > It had better not become mandatory. You would not notice the difference, only your kernel would be a bit smaller and the RRPART ioctl disappears. [Besides: we have lived with DOS-type partition tables for ten years, but they will not last another ten years. Very soon disk partitions will look very different. It will be good to move knowledge about these things out of the kernel before this happens.] Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Q: ioctl BLKGETSIZE return value units?
> What are the units of the return value of the BLKGETSIZE ioctl on Linux? Sectors of size 512. > or is it in units of sector size bytes as returned by BLKSSZGET No. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Potential help for VIA problems and ASUS motherboards
Hi, I've seen a lot of messages regarding problems with the VIA chipset... I've experienced them myself. Anyways, I just put in a new ASUS CUV4X-D motherboard, BIOS revision 1004. Once installed, I ran into a raft of problems when IO-APIC was enabled... and discovered that ASUS had a BIOS update (revision 1007) available. Once the BIOS was updated and MPS 1.4 support was disabled, everything has been working fine, including USB with IO-APIC enabled. I also don't seem to be getting the timer problem anymore. Anyways, if you have one of these boards, you may want to flash your BIOS and see if the problems are fixed. YMMV, but it worked for me. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote: > > >Make your config script look at the hardware MAC addresses. Those don't >> >change. >> >> They're not necessarily unique, though. > >So if you plug both into the same network segment, that segment is broken? >That looks like very stupid design to me. > >It's not as if getting enough unique MAC addresses was particularly >expensive. These days, even el-cheapo PC network cards get that right. >(And have for quite a number of years.) Many do, some don't. Moreover, the MAC address is volatile in that it can be changed at will (via, eg, ifconfig). I assume that the reason that Sun (for example) defaults to all MAC addresses on a system being the same is that it doesn't make sense, ordinarily, to plug two Ethernet interfaces into the same network segment. If, for some reason, you really want to do that, there's ifconfig ready to reassign the MAC address. If I plug both into the same network segments by accident (because I can't tell which is which, say), then my configuration is nearly as broken with different MAC addresses as with identical ones; the fix is to replug correctly, not to change MAC addresses. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
At 10:42 AM +0200 2001-05-19, Kai Henningsen wrote: > > Jeff Garzik's ethtool > > extension at least tells me the PCI bus/dev/fcn, though, and from >> that I can write a userland mapping function to the physical >> location. > >I don't see how PCI bus/dev/fcn lets you do that. I know from system documentation, or can figure out once and for all by experimentation, the correspondence between PCI bus/dev/fcn and physical locations. Jeff's extension gives me the mapping between eth# and PCI bus/dev/fcn, which is not otherwise available (outside the kernel). -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
On Sat, May 19, 2001 at 01:30:14PM +0200, [EMAIL PROTECTED] wrote: > I don't think so. It is necessary, and it is good. > > But it is easy to make the transition painless. > Instead of the current choice between INITRD (yes/no) > we have INITRD (default built-in / external). > The built-in version can then slowly become smaller and die. initrd is an unnecessary pain in the ass for most people. It had better not become mandatory. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, May 19, 2001 at 06:48:19PM +0200, Erik Mouw wrote: > One of the fundamentals of Unix is that "everything is a file" and that > you can do everything by reading or writing that file. But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see if it's there. writing to files that aren't shown in directory listings is plain evil. I really don't want to explain why. It's extremely messy and unintuitive. It would be better to do this with a file that does exist, for example writing something to /proc/disks/sda/arguments. Then again, I don't even think much of dynamic file systems in the first place. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.4 fix bug in nfs_refresh_inode() and cleanup...
Linus,
A bug was recently found in which nfs_refresh_inode() was returning
EIO when servers, such as the Hummingbird, don't return the optional
attributes on calls such as the setattr() call. This error was then
being passed back to userland.
When investigating the bug, I also found a load of `debugging' code
at the start of nfs_refresh_inode() that would actually mask serious
bugs for us (returning EIO again, instead of Oopsing).
The following patch fixes the bug, and gets rid of the bogus
debugging stuff.
Cheers,
Trond
diff -u --recursive --new-file linux-2.4.4-fixes/fs/nfs/inode.c
linux-2.4.4-refresh/fs/nfs/inode.c
--- linux-2.4.4-fixes/fs/nfs/inode.cWed Apr 25 23:58:17 2001
+++ linux-2.4.4-refresh/fs/nfs/inode.c Mon May 14 15:02:14 2001
@@ -887,40 +887,23 @@
* A very similar scenario holds for the dir cache.
*/
int
-nfs_refresh_inode(struct inode *inode, struct nfs_fattr *fattr)
+__nfs_refresh_inode(struct inode *inode, struct nfs_fattr *fattr)
{
__u64 new_size, new_mtime;
loff_t new_isize;
int invalid = 0;
- int error = -EIO;
-
- if (!inode || !fattr) {
- printk(KERN_ERR "nfs_refresh_inode: inode or fattr is NULL\n");
- goto out;
- }
- if (inode->i_mode == 0) {
- printk(KERN_ERR "nfs_refresh_inode: empty inode\n");
- goto out;
- }
-
- if ((fattr->valid & NFS_ATTR_FATTR) == 0)
- goto out;
-
- if (is_bad_inode(inode))
- goto out;
dfprintk(VFS, "NFS: refresh_inode(%x/%ld ct=%d info=0x%x)\n",
inode->i_dev, inode->i_ino,
atomic_read(&inode->i_count), fattr->valid);
-
if (NFS_FSID(inode) != fattr->fsid ||
NFS_FILEID(inode) != fattr->fileid) {
printk(KERN_ERR "nfs_refresh_inode: inode number mismatch\n"
"expected (0x%Lx/0x%Lx), got (0x%Lx/0x%Lx)\n",
(long long)NFS_FSID(inode), (long long)NFS_FILEID(inode),
(long long)fattr->fsid, (long long)fattr->fileid);
- goto out;
+ goto out_err;
}
/*
@@ -933,8 +916,6 @@
new_size = fattr->size;
new_isize = nfs_size_to_loff_t(fattr->size);
- error = 0;
-
/*
* Update the read time so we don't revalidate too often.
*/
@@ -1024,11 +1005,9 @@
if (invalid)
nfs_zap_caches(inode);
+ return 0;
-out:
- return error;
-
-out_changed:
+ out_changed:
/*
* Big trouble! The inode has become a different object.
*/
@@ -1042,7 +1021,8 @@
* (But we fall through to invalidate the caches.)
*/
nfs_invalidate_inode(inode);
- goto out;
+ out_err:
+ return -EIO;
}
/*
diff -u --recursive --new-file linux-2.4.4-fixes/include/linux/nfs_fs.h
linux-2.4.4-refresh/include/linux/nfs_fs.h
--- linux-2.4.4-fixes/include/linux/nfs_fs.hSat Apr 28 00:49:37 2001
+++ linux-2.4.4-refresh/include/linux/nfs_fs.h Mon May 14 15:00:18 2001
@@ -142,7 +142,7 @@
struct nfs_fattr *);
extern struct inode *nfs_fhget(struct dentry *, struct nfs_fh *,
struct nfs_fattr *);
-extern int nfs_refresh_inode(struct inode *, struct nfs_fattr *);
+extern int __nfs_refresh_inode(struct inode *, struct nfs_fattr *);
extern int nfs_revalidate(struct dentry *);
extern int nfs_permission(struct inode *, int);
extern int nfs_open(struct inode *, struct file *);
@@ -271,6 +271,14 @@
if (time_before(jiffies, NFS_READTIME(inode)+NFS_ATTRTIMEO(inode)))
return NFS_STALE(inode) ? -ESTALE : 0;
return __nfs_revalidate_inode(server, inode);
+}
+
+static inline int
+nfs_refresh_inode(struct inode *inode, struct nfs_fattr *fattr)
+{
+ if ((fattr->valid & NFS_ATTR_FATTR) == 0)
+ return 0;
+ return __nfs_refresh_inode(inode,fattr);
}
static inline loff_t
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] Re: Linux 2.4.4-ac10
Hi,
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> That's the main problem with static parameters. The problem you are
> trying to solve is fundamentally dynamic in most cases (which is also
> why magic numbers tend to suck in the VM.)
Magic numbers might be sucking some performance right now ;-)
Three back to back make -j 30 runs for three different kernels.
Swap cache numbers are taken immediately after last completion.
Reference runs (bad numbers. cache collapse hurts.. a lot)
real12m8.157s 11m41.192s 11m36.069s 2.4.4.virgin
user7m57.710s 7m57.820s 7m57.150s
sys 0m37.200s 0m37.070s 0m37.020s
Swap cache: add 785029, delete 781670, find 243396/1051626
oddball.. infrequent, but happens
real10m30.470s 9m36.478s 9m50.512s 2.4.5-pre3.virgin
user7m54.300s 7m53.430s 7m55.200s
sys 0m36.010s 0m36.850s 0m35.230s
Swap cache: add 1018892, delete 1007053, find 821456/1447811
real9m9.679s9m18.291s 8m55.981s 3.4.5-pre3.tweak
user7m55.590s 7m57.060s 7m55.850s
sys 0m34.890s 0m34.370s 0m34.330s
Swap cache: add 656966, delete 646676, find 325186/865183
--- linux-2.4.5-pre3/mm/vmscan.c.orgThu May 17 16:44:23 2001
+++ linux-2.4.5-pre3/mm/vmscan.cSat May 19 11:52:40 2001
@@ -824,39 +824,17 @@
#define DEF_PRIORITY (6)
static int refill_inactive(unsigned int gfp_mask, int user)
{
- int count, start_count, maxtry;
-
- if (user) {
- count = (1 << page_cluster);
- maxtry = 6;
- } else {
- count = inactive_shortage();
- maxtry = 1 << DEF_PRIORITY;
- }
-
- start_count = count;
- do {
- if (current->need_resched) {
- __set_current_state(TASK_RUNNING);
- schedule();
- if (!inactive_shortage())
- return 1;
- }
-
- count -= refill_inactive_scan(DEF_PRIORITY, count);
- if (count <= 0)
- goto done;
-
- /* If refill_inactive_scan failed, try to page stuff out.. */
- swap_out(DEF_PRIORITY, gfp_mask);
-
- if (--maxtry <= 0)
- return 0;
-
- } while (inactive_shortage());
-
-done:
- return (count < start_count);
+ int shortage = inactive_shortage();
+ int large = freepages.high/2;
+ int scale;
+
+ scale = shortage/large;
+ scale += free_shortage()/large;
+ if (scale > DEF_PRIORITY-1)
+ scale = DEF_PRIORITY-1;
+ if (refill_inactive_scan(DEF_PRIORITY-scale, shortage) < shortage)
+ return swap_out(DEF_PRIORITY, gfp_mask);
+ return 1;
}
static int do_try_to_free_pages(unsigned int gfp_mask, int user)
@@ -976,7 +954,8 @@
* We go to sleep for one second, but if it's needed
* we'll be woken up earlier...
*/
- if (!free_shortage() || !inactive_shortage()) {
+ if (current->need_resched || !free_shortage() ||
+ !inactive_shortage()) {
interruptible_sleep_on_timeout(&kswapd_wait, HZ);
/*
* If we couldn't free enough memory, we see if it was
@@ -1054,7 +1033,7 @@
if (!zone->size)
continue;
- while (zone->free_pages < zone->pages_low) {
+ while (zone->free_pages < zone->inactive_clean_pages) {
struct page * page;
page = reclaim_page(zone);
if (!page)
Now, lets go back to the patch I posted which reduced context switches
under load by ~40% (of ~685000) for a moment. Kswapd is asleep while
awaiting IO completion. The guys who are pestering the sleeping kswapd
are going to be doing page_launder to fix the shortage they're yammering
at kswapd about. We're nibbling away at the free shortage.. and the
inactive_dirty list. So now, we have an inactive shortage as well as
a large free shortage when we enter refill_inactive. (shortages became
large because kswapd is sleeping on the job)
6 * (1 << page_cluster) is larger than MAX_LAUNDER, but I don't see any
reason to sneak up on the shortage instead of correcting it all at once.
It takes too long to find out it's going to fail. Why not just get it
over with before every scrubber in the system is sleeping on IO.. except
the ones doing swap pagebuffer allocations. They can swapout, but they
can't help push swap, so it'll all sit there until somebody wakes up no?
If I'm interpreting the results right, taking it all on at once is saving
a lot of what looks to me to be unnecessary swap. I can't see those
swap numbers as being anyth
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH] device arguments from lookup)
On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote: > clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add > unopened descriptors. I.e. no IO until you open it (turning the thing into > opened one), but we can do lookups (move to child), we can clone and > kill them and we can stat them. Those who would like a more detailed explanation can find one at http://plan9.bell-labs.com/sys/man/5/INDEX.html -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Negative inode-nr ?
On Sat, May 19, 2001 at 01:33:10PM -0300, Rik van Riel wrote:
> On Sat, 19 May 2001, [iso-8859-1] Jakob Østergaard wrote:
>
> > What do you think of this ?
> > [root]# cat /proc/sys/fs/inode-nr
> > 157097 -180
>
> I think you should upgrade to a newer kernel; Al Viro
> fixed this bug and the fix went into 2.4.5-pre1.
Thank you Rik (and others who sent me roughly the same answer)
Now *that's* support ;)
Cheers,
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, May 19, 2001 at 03:02:47PM +0100, Alan Cox wrote: > > ioctls are evil, period. At least with these names you can use normal > > scripting and don't need any special tools. Every ioctl means a binary > > that has no business to exist. > > That is not IMHO a rational argument. It isn't my fault that your shell does > not support ioctls usefully. If you used perl as your login shell you would > have no problem there. Sure, you're right, but Al's point is that you shouldn't need to. One of the fundamentals of Unix is that "everything is a file" and that you can do everything by reading or writing that file. The devices are the big exception, they need ioctls to control them. With Al's proposal we can get rid of the ioctls and let the devices behave like normal files. Erik [who remembers a discussion like this years ago on comp.os.linux.kernel with similar conclusion: ioctls are bad, we should get rid of them] -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Hi, On Sat, May 19, 2001 at 05:29:32PM +1200, Chris Wedgwood wrote: > > Or you can fall back to mounting by UUID, which is globally > unique and still avoids referencing physical location. You also > don't need to manually set LABELs for UUID to work: all e2fsprogs > over the past couple of years have set UUID on partitions, and > e2fsck will create a new UUID if it sees an old filesystem that > doesn't already have one. > > Other filesystems such as reiserfs at present don't have such a > thing. I brought this a while ago and in theory it's not too hard, we > just need to get Hans to officially designate part of the SB or > whatever for the UUID. There are other ways to deal with it: both md and (I think, in newer releases) LVM can pick up their logical config from scanning physical volumes for IDs, and so present a consistent logical device namespace despite physical devices moving around. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
