Kernel Traffic Zack Brown
Disk Arrays: RAID Disks: IDE Disks: SCSI FS: NFS FS: NTFS Networking PCI Power Management: ACPI Virtual Memory James Simmons Michael H. Warfield Jeff Garzik Andre Hedrick Linus Torvalds Richard Henderson

Following up on the thread covered in , Alan Cox posted the latest draft of his job list:

  1. Truncate races (Debian apt shows it nicely)
  2. Restore O_SYNC functionality
  3. Merge the network fixes - there is a ton of backed up stuff to do asap
  4. vmalloc(GFP_DMA) is needed for DMA drivers
  5. VM needs rebalancing
  6. Fix eth= command line
  7. Check O_APPEND atomicity bug fixing is complete
  8. Protection on isize (sct)
  9. Merge 2.2.13/14 changes
  10. Get RAID 0.90 in
  11. PAE36 failures
  12. Mikulas claims we need to fix the getblk/mark_buffer_uptodate thing for 2.3.x as well
  13. PIII/Athlon/MMX/etc acceleration merge from 2.2.x-ac
  14. Fix SPX socket code
  15. NCR5380 isnt smp safe
  16. Finish 64bit vfs merges (lockf64 and friends missing)
  17. Make syncppp use new ppp code
  18. Fbcon races
  19. Fix all remaining PCI code to use new resources and enable_Device
  20. Stackable fs ?? (Erez)
  21. Get the Emu10K merged
  22. Test PMC code on Athlon
  23. Fix module remove race bug (-- not in open so why did I see crashes ??? --)
  24. Per Process rtsigio
  25. Maybe merge the ibcs emulation code
  26. VFS?VM - mmap/write deadlock
  27. initrd is bust
  28. msync fails on NFS
  29. rw sempahores on page faults (mmap_sem)
  30. kiobuf seperate lock functions/bounce/page_address fixes
  31. per super block write_super needs an async flag
  32. addres_space needs a VM pressure/flush callback
  33. per file_op rw_kiovec
  34. enhanced disk statistics
  35. Fix routing by fwmark
  36. put_user appears to be broken for i386 machines
  37. Some FB drivers check the A000 area and find it busy then bomb out
  38. SCSI needs allocate/free functions to fix the gdth stuff
  39. NTFS needs updating/binning or something
  40. ACPI hangs on boot for some systems
  41. rw semaphores on inodes to fix read/truncate races ?
  42. Not all device drivers are safe now the write inode lock isnt taken on write
  43. File locking needs checking for races
  44. Multiwrite IDE breaks on a disk error

Michael H. Warfield replied, asking if encryption would make it into 2.4, given the new US crypto laws (covered in ). Alan replied, I have no idea. Linus Torvalds was silent.

David S. Miller replied to item 3 of Alan's list, with, 75% done, the remaining bits should be doable in 2 seperate code merges. I think I can get this done over the course of the upcoming 2 weeks.

Andre Hedrick replied to item 9 of Alan's list, saying he had pretty much finished the 2.2.13/2.2.14 merge. He added regarding item 44, that he thought he had fixed the multiwrite IDE error, but wanted to go over it again with Alan. Alan replied, I'll read over the current code and check. The problem was the error handling for multiwrite if you got a bad block in the multiblock seemed to fail all the blocks. Also I wasnt convinced the rq handling was safe there. At this point they probably took it to private email or IRC.

James Simmons replied to Alan's item 4, asking if it would be possible to allocate several megabytes for DMA. Alan replied that yes, it would be possible to allocate them as random pages, but not linear. James asked how that situation would be useful, and Jamie Lokier replied, Probably not useful. Being able to guarantee allocation of, say, 16k contiguous DMA is more much useful though. But Jes Sorensen said that lots of modern hardware would do scatter/gather DMA, which would be quite useful (Jeff Garzik added that according to Alan, even older hardware could often do scatter/gather). But Jamie replied to Jes, How much hardware can do _ISA_ scatter/gather DMA? GFP_DMA is for ISA only. The allocator changes are useful for folks doing 32 bit PCI DMA, but that's not the question that was asked here. Jes smiled and pleaded lack of coffee, conceding the point, and said, But then again, expecting to be able to allocate MB's contigous ISA space is kinda silly since there is just a total of 16MB to get anyway.

But David Woodhouse added, in reply to Jamie's "How much hardware can do _ISA_ scatter/gather DMA" comment:

Depends on how clever the motherboard chipset / ISA bridge is.

Any DMA-capable ISA card in an Alpha, for example, is quite happily capable of scatter/gather DMA, and it doesn't even have to know a thing about it.

The PCI/ISA bridge will perform any mapping it's asked to - but at the moment Linux doesn't use that capability, and just sets up a static mapping to the first 16Mb of RAM, AFAIK

Jakub Jelinek replied, It does in 2.3.41, at least on UltraSPARC. See Documentation/DMA-mapping.txt. Richard Henderson has patches to make this work on Alpha as well, but it probably needs there some more debugging and testing.

Disks: IDE Microsoft PCI Alan Cox

David Dyck reported that during 2.3.41-4's 'fsck' at bootup, he would sometimes see the error, "hda: lost interrupt". Rebooting to 2.3.40 seemed to get rid of the problem. A couple folks reported similar lost interrupts when warm-booting from a Microsoft OS. Andre Hedrick asked David what chipset and drive vendor he had, and David copied out his 'dmesg' output:

Uniform Multi-Platform E-IDE driver Revision: 6.30
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: not 100% native mode: will probe irqs later
hda: Maxtor 86480D6, ATA DISK drive
hdb: WDC AC32100H, ATA DISK drive
hdc: NEC CD-ROM DRIVE:28B, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: Maxtor 86480D6, 6149MB w/256kB Cache, CHS=784/255/63
hdb: WDC AC32100H, 2014MB w/128kB Cache, CHS=1023/64/63
hdc: ATAPI 32X CD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.06
Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 >
hdb: hdb1

Andre replied with a loud warning (cc:ed to Alan Cox):

I am using you problem as the example for the world, You need to split the Maxtor WDC pair before you corrupt your FS!!!!

Everyone this is the classic case stated many times but no examples. This one is different in that irq's are lost only and FS is not destroyed. Since the ASIC timing modes on the Maxtor are better than that of the WDC, and it is the faster drive, the error is minor.

This is only because the order is Maxtor then WDC. If the order was reversed WDC the Maxtor, you would watch the two destroy each other. One should never mix a UDMA Maxtor with DMA WDC, the chatter of the timings will kill.

In a later post, Andre summed up his findings:

Build a 386 kernel no problem.
Build a 486 kernel small random, minor.
Build a 586 kernel noticable problems, and permission fail.
Build a 686 kerenl and the disk data will fry.

It took me 5 weeks to reduce the variables and derive this answer. There is a timing issue that is drive dependent on the PIIX3/4. It is an echo bounce in the trigger levels of the signal gating.

This is line chatter on the bus that I have only observed with a WDC and Maxtor pair on the same channel.

He expanded:

WDC drives blow off the CRC check of UDMA.........This is BAD and STUPID. Several of the OEM chipset makers have allowed this crap to exist. ATA-2 (style) can not handle ATA-3/4 transfer rates without the CRC checks, you end up continuing the DMA writing regardless if you lost data that would have been saved if the UDMA CRC was intact.

This is a pure hardware issue........I do not know yet if there is a way to check/recover with out death to DMAing for all WDC products. The best case at the moment is to consider blocking all WDC products from using the ATA-3 and newere standard.

There was a bit more discussion, in which it came out that with WDC, the faster drive must be the master. A number of people kept seeing lost interrupts, and Andre began debugging the reports; no real resolution appeared on the list though.

In the course of reporting a problem with fbcon, Lawrence Manning said, I also noticed that the penguin is on a white strip in 2.3, but in 2.2 the area to the right of him is black. BTW, what sets which penguin is shown? In 2.2.14 the penguin is drinking some beer :-) but in 2.3 he's the regular penguin. Jeff Garzik replied, mmmmm. beeer. You see the beer icon in 16-color mode I think, with the regular penguin in 256-color mode. Alex Buell even has a penguin smoking a spliff, if you want such an icon :) Lawrence replied, Sounds interesting :) whats the limits to the logos size? Full screen boot logo/animation of tux drinking AND smoking a spliff would be excelent heheh! Maybe not... Alex Buell replied:

I've been intending to get around to putting that penguin smoking a spliff logo on my bootup screen.

A thumpin' techno-trance track on boot-up would be *way* cool. Probably would scare the PHBs though.
Framebuffer

In the course of discussion, Linus Torvalds explained:

I heartily encourage initcalls, they are _much_ nicer than explicit initialization. The explicit way only makes sense for (a) old drivers and (b) code that requires certain ordering.

However, instead of using "__initcall" directly, I would suggest using "module_init()" and "module_exit()". Which will do the right things for drivers whether that driver is compiled as a module or not (basically, a good driver these days should have NO code that is inside #ifdef MODULE any more).

Jeff Garzik replied:

Adding to this, for modules which require explicit init order like fbdev, you will typically find a single ifdef:

#ifdef MODULE
module_init(driver_init);
#endif
module_exit(driver_cleanup);

Ideally you can let Makefile link order take care of these things, but there are always special cases...

Linus replied, Well, even for that case you should be able to just make sure that the linking order is right, and this single ifdef is also unnecessary. However, it is certainly better as a half-measure than the jungle that some drivers have for historical reasons..

Andrzej Krzysztofowicz

In the course of a discussion about the Configure, Menuconfig, and xconfig tools in 2.3.41, Andrzej Krzysztofowicz asked if Michael Elizabeth Chastain was still their maintainer. Michael replied, Yes, I am. But I haven't had time to put much work into it lately. Andrzej or someone else, would you like to inherit the job? The discussion continued, but no volunteer stepped forward.

Someone was having trouble compiling 2.3.39 on LinuxPPC for powermac: doing a 'make zImage' would complain that includes/asm/ipcbuf.h and includes/asm/sembuf.h were not found. Andreas Tobler replied, Try 2.3.40, this should work. 2.3.41 and up are not yet adapted. If you need a 2.3.39 you can try the one from Paul M. on Linuxcare. You can access it via 'rsync -auvz linuxcare.com.au::linux-pmac-devel <dest-dir-on-your-machine>'

The original poster replied that 2.3.40 worked, and Jeff Garzik also said, 2.3.41-pre3 works beautifully on my PowerMac 7200/90. The only thing I had to hack, IIRC, is drivers/macintosh/Makefile.

Per Lundberg

Per Lundberg was trying to get his parallel port Zip drive working on his Sparc. 'make menuconfig' didn't reveal useful options for this. Tim Waugh felt it should be possible, with a little coding, and asked what type of Sparc Per was using. He added, The ppa driver assumes a PC-style parallel port, rather than using the parport interface. If you can change that, you should be able to get results. Per replied that his machine was a regular SparcStation 5. However, it struck him as stupid that the ppa driver would not use the parport interface, and he was ready to give up and use the Zip drive on one of his regular PCs. Tim explained, Historically, the ppa driver came first, and no-one ever really bothered changing it. It would be nice if someone did, and it wouldn't be much coding work; just testing, really.

Riley Williams volunteered, with, If somebody wants to loan me a Sparc, I'd certainly have a go, but without one, there's no real chance to do so... There was no reply.

Jakub Jelinek

Andrea Arcangeli implemented read-write semaphores for 2.3.42 on Alpha machines, based on normal spinlocks. He posted a patch, and added, they are not architecture-dependent so other archs can cut and past if necessary. David S. Miller replied, Although the generic implementation is useful, the Alpha version should use the ll/sc atomic update sequences. Have a look at the sparc64 version for one way to implement that. Richard Henderson replied that this had actually already been done, and that the patches had been posted to the 'axp-list' mailing list two days before. Andrea said he was only subscribed to 'linux-alpha', and asked what the difference was between the two, and why the patches were not posted to linux-alpha as well. Dominik Kubla replied, axp-list is for Redhat/Alpha. I am not subscribed either, since i don't care a bit about Redhat configuration problems (which used to be the prominent topic back when i still read it). He went on to suggest, Can we please agree on using the VGER lists as authoritative for the kernel and its ports and let the vendor-specific lists be just that: vendor-specific? he also pointed out that 'axp-list' only accepted posts from folks that were subscribed, which made it harder to see bug reports etc.; 'linux-alpha', he went on, accepted posts from anyone, subscribed or not. But Richard also replied to Andrea's query, with, The difference is that axp-list has been the only really active alpha list, so it's the one I think of.

Responding to Andrea's initial patch, Jakub Jelinek suggested that if it was architecture independant, it should be in include/asm-generic/semaphore.h but not into Alpha, which, he said, had a proper implementation already. Andrea replied that as far as that went, the code might as well go into include/linux/semaphore.h and lib/semaphore.c, and then each arch can select the generic semaphore implementation with a simple CONFIG_GENERIC_RWSEMAPHORE=y. All includes should be changed from asm/semaphore.h to linux/semaphore.h. Jakub felt this wasn't the best solution either, but that debate died off.

Someone asked what journalling filesystem options were available for the unstable series, and Hans Reiser replied, Our 2.3 port is in alpha, it lost performance in the porting but is stable, we are hunting for the performance loss source. Ragnar Kjorstad asked if the sources for the 2.3 port were available, and Hans replied, Not yet. End Of Thread.

Real-Time: RTLinux

For a related article, see .

Gregory Maxwell gave a pointer to a press release that claimed RTLinux as a trademark of VJY Associates L.L.C.

He went on to say, RT Linux has been the name of the RT Linux patches for ages. This seems to me to be a case of, "We can't close our code, so we'll make a generic trademark and prevent competaion".. and concluded by asking if they had been authorized to use "Linux" as part of their trademark. Alan Cox replied, Last time I checked RTLinux was written by one V Yodaiken, I wouldnt be suprised if he happened to be V J Yodaiken ...

This cleared it up somewhat for Gregory, who then added, I'm still not sure that trademarking RTLinux is good, as the use of such a generic name would make forking difficult.

Linus Torvalds replied:

We (Victor, me, maddog) agreed that "Realtime Linux" should _not_ be trademarkable, because that's too generic - while "RTLinux" is not really any more generic than "VA Linux" for example ;)

People just think that "RTLinux" is generic because it's been used for the code in question as a name for so long..

David Schleef added that there were actually already several real-time Linux patches, so forking would probably not be a problem. He pointed out that RTLinux just had the most attention at the moment.