|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
Table Of Contents
| 1. | 28 Jan 2000 - 2 Feb 2000 | (30 posts) | ToDo Before 2.4: Saga Continues |
| 2. | 28 Jan 2000 - 1 Feb 2000 | (24 posts) | WDC Drives: Strange Requirements |
| 3. | 29 Jan 2000 - 3 Feb 2000 | (11 posts) | Sex, Drugs, And Rock And Roll |
| 4. | 30 Jan 2000 - 1 Feb 2000 | (8 posts) | Initcall Policy |
| 5. | 31 Jan 2000 - 3 Feb 2000 | (14 posts) | Kernel Configuration Tools Lagging |
| 6. | 2 Feb 2000 - 3 Feb 2000 | (4 posts) | Compiling The Unstable Series For PowerMac |
| 7. | 3 Feb 2000 - 4 Feb 2000 | (7 posts) | Zip Drive On Sparc |
| 8. | 4 Feb 2000 - 5 Feb 2000 | (23 posts) | Read-Write Semaphores For Alpha |
| 9. | 4 Feb 2000 - 6 Feb 2000 | (4 posts) | Status Of Journalling |
| 10. | 6 Feb 2000 - 7 Feb 2000 | (5 posts) | Linux Trademarks |
Mailing List Stats For This Week
We looked at 950 posts in 4171K.
There were 420 different contributors. 159 posted more than once. 198 posted last week too.
The top posters of the week were:
1. ToDo Before 2.4: Saga Continues
28 Jan 2000 - 2 Feb 2000 (30 posts) Archive Link: "Updated 2.3.x job list (its getting shorter)"
Topics: Disk Arrays: RAID, Disks: IDE, Disks: SCSI, FS: NFS, FS: NTFS, Networking, PCI, Power Management: ACPI, Virtual Memory
People: Alan Cox, David S. Miller, Jamie Lokier, Jes Sorensen, David Woodhouse, Jakub Jelinek, James Simmons, Michael H. Warfield, Jeff Garzik, Andre Hedrick, Linus Torvalds, Richard Henderson
Following up on the thread covered in Issue #52, Section #1 (4 Jan 2000: ToDo Before 2.4) , Alan Cox posted the latest draft of his job list:
Michael H. Warfield replied, asking if encryption would make it into 2.4, given the new US crypto laws (covered in Issue #53, Section #3 (14 Jan 2000: US Crypto Laws) ). 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."
2. WDC Drives: Strange Requirements
28 Jan 2000 - 1 Feb 2000 (24 posts) Archive Link: "2.3.41-4 / hda: lost interrupt"
Topics: Disks: IDE, Microsoft, PCI
People: Andre Hedrick, 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.
3. Sex, Drugs, And Rock And Roll
29 Jan 2000 - 3 Feb 2000 (11 posts) Archive Link: "2.3.41 and TNT2 fbcon"
People: Lawrence Manning, Jeff Garzik, Alex Buell
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.
4. Initcall Policy
30 Jan 2000 - 1 Feb 2000 (8 posts) Archive Link: "Re: [linux-usb] __initcall diff, version 2"
Topics: Framebuffer
People: Linus Torvalds, Jeff Garzik
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.."
5. Kernel Configuration Tools Lagging
31 Jan 2000 - 3 Feb 2000 (14 posts) Archive Link: "2.3.41 is dep_bool officially broken? :)"
People: Michael Elizabeth Chastain, 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.
6. Compiling The Unstable Series For PowerMac
2 Feb 2000 - 3 Feb 2000 (4 posts) Archive Link: "Compilation problems on kernel 2.3.39 on PowerMac"
People: Andreas Tobler, Jeff Garzik
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."
7. Zip Drive On Sparc
3 Feb 2000 - 4 Feb 2000 (7 posts) Archive Link: "ZIP drive on Sparc?"
People: Tim Waugh, Riley Williams, 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.
8. Read-Write Semaphores For Alpha
4 Feb 2000 - 5 Feb 2000 (23 posts) Archive Link: "2.3.42 alpha updates"
People: Andrea Arcangeli, David S. Miller, Dominik Kubla, Richard Henderson, 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.
9. Status Of Journalling
4 Feb 2000 - 6 Feb 2000 (4 posts) Archive Link: "Journaling FS in 2.3?"
People: Hans Reiser
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.
10. Linux Trademarks
6 Feb 2000 - 7 Feb 2000 (5 posts) Archive Link: "Linux trademark garbage"
Topics: Real-Time: RTLinux
People: Gregory Maxwell, Alan Cox, Linus Torvalds
For a related article, see Issue #53, Section #6 (18 Jan 2000: Linus On Trademarks) .
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.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |