Kernel Traffic #116 For 30 Apr 2001

There were 518 different contributors. 262 posted more than once. 185 posted last week too.

Michael Reinelt reported that his PCI card with NetMos chip had worked up until 2.4.3, with a custom patch he'd submitted to the serial and PCI maintainers. With 2.4.3, he found that he could only get either the card's parallel port or serial port to work, but not both, depending on which (parallel or serial) driver was loaded first into the kernel. Michael traced the problem to the pci_announce_device() function in pci.c, which would be called only if no other driver claimed a given device. Since the card showed up on the PCI bus as a single device, only the first driver loaded would see it. He added, "I'm afraid this is not a bug, but a design issue, and will be hard to solve. Maybe we need a flag for such devices which allows it to be claimed ba more thean one driver?"

Tough. The PCI specification has a perfectly good way to handle this, namely by having subfunctions on the same chip. The particular chip designer was lazy or something, and didn't do it the proper way. Which means that you cannot, and should not, use a generic PCI driver for the chip. Because it doesn't show up as separate devices for the separate functions.

Now, that doesn't mean that you can't use the card, or the existing drivers. It only means that you should fix up the total braindamage of the hardware.

It only means that you should probably approach it as being a special "invisible PCI bridge", and basically have a specific driver for that chip that acts as a _bridge_ driver.

Writing a bridge driver is not that hard: your init routine will instantiate the devices behind the bridge (ie you would allocate two "struct pci_device" structures and you would add them to behind the "bridge", and you would make _those_ look like real serial and parallell devices.

See for example drivers/pcmcia/cardbus.c: cb_alloc() for how to create a new "pci_dev" (see the "for i = 0; i < fn ; i++)" loop: it creates the devices for each subfunction found behind the cardbus bridge. It really boils down to "dev = kmalloc(); initialize_dev(dev); pci_insert_dev(dev, bus);").

At which point you can happily use the current drivers without any modifications.

Jeff Garzik praised this solution, but cautioned, "that's a slippery slope... If you do this as a solution for multifunction devices, you also have to consider even more stupid hardware which exports one PCI function, but multiple BARs for different purposes..."

Elsewhere, Gerard Roudier spat upon the makers of Michael's card, saying, "A single function PCI device that provides several functionnalities commonly handled by separate sub-systems, is nothing but a bag of shit we should not want to support in any O/S in my opinion. Let me claim that ingenieers that want O/Ses to support such hardware are either morons or bastards." But Brian Gerst pointed out, "Unfortunately, Windoze supports this configuration, and that's enough for most hardware designers. This is also an issue with the joystick ports on many PCI sound cards."

Elsewhere, Jeff asked where Michael's patch was, since he'd never seen it. Michael replied that he'd sent it to Jens Maurer, Theodore Y. Ts'o, and Tim Waugh; and Tim gave a link to it on his page.

Steve Modica and others had found that the Acenic card for the 3COM gigabit ethernet card did not enable 64-bit DMAs. Steve said that Jes Sorensen had suggested creating a pci_enable_dma64() function, and just having the driver call that function instead of setting the dma_mask variable by hand, as some drivers already did. He added that using a function would have the added benefit of helping to debug situations in which drivers attempted to set 64-bit DMAs on non-64-bit busses. Jeff Garzik replied that the pci_set_dma_mask() function already existed, and that no one should set the variable directly anymore, but should always go through that function. But Jes replied:

Hmmm, I was wondering if could come up with a pretty way to do this on 32 bit boxes that wants to enable highmem DMA. Right now pci_set_dma_mask() wants a dma_addr_t which means you have to do #ifdef CONFIG_HIGHMEM <blah> #else <bleh> #endif.

Introducing a new function that takes bit flags as arguments might be better?

Alan Cox thought this would be fine, and pointed out a way to take account of non-64-bit architectures at the same time. Everyone seemed in agreement, and went off to code.

Alan Cox announced 2.4.3-ac7, and Chris Meadors asked about an ACPI fix that had been floating around. Alan replied, "Ask Andrew Grover. I don't follow the ACPI threads. Having attempted to use ACPI both on Linux and other OS's I've given up. Adding a bloated interpreter for an obscure, misdesigned bios hardware description language is simply not my idea of progress. Its an extremely complicated way for intel to try and keep stuff like speedstep proprietary, nothing more." Andrew Grover also replied to Chris, saying that he'd be submitting a big ACPI patch to Alan and Linus Torvalds soon.

Eric S. Raymond announced CML2 version 1.1.3 at the CML2 home page. He said that this release included only bug fixes and UI cleanup. Marko Kreen gave a good review, saying, "I must say that versions 1.1.2, 1.1.3 are much faster than previous, I really cannot say that CML2 is in some way unusable for me. Good work!" Elsehwere, there was some discussion of Eric's color choices for xconfig. John Cowan suggested that no color choice would suit everyone, and that Eric should just take the colors from the .Xdefaults system. James Rich agreed, saying, "Yes, truly this should be done. Sensible defaults should be used (and I think we may be at that point) and then use .Xdefaults (.Xresources or whatever) to allow site overrides. And I really do think .Xdefaults and not .xconfigrc or something. I've already got enough .files and I like the syntax of .Xdefaults." But Eric felt this would lead to bloat, since there was no existing Python library to parse the .Xdefaults format. John Cowan replied that at the very least, the colors should not be hard-coded into the system. Some mechanism was needed for user configuration, he felt. Close by, Peter Samuelson pointed out, "I thought you were just using Python bindings to Tk. Are you telling us the Tk library, which for 8 or 10 years has been pretty much *the* X toolkit/widget set for scripting, does not include an interface to X resources?" Eric replied that he hadn't seen such a thing documented anywhere, but Andrew Pimlott and Olaf Titz pointed him to the 'option' command in Tcl/Tk.

The Linux GFX project grew out the need for a higher performance X server that has a much faster developement cycle. In the last few years the graphics card and multimedia environments have grow at such a rate the current X solutions can no longer keep pace nor do they focus on producing high performance X servers specifically for linux. Also the community has demanded for specific functionality which has never come to light.

This project looks to start from scratch to develope a new X enviroment that addresses these issues. I posted here because we will addressing several issues about hardware management between the kernel and the X window enevironment. Of course the X enrvironment is extremly broad so this will require skills from several areas as well as many programmers. So we welcome anyone how would like to see a alternative to the current X implemenation. If you like to subscribe to our mailing list just follow the link below. Thank you.

http://lists.sourceforge.net/lists/listinfo/linuxgfx-dev

David S. Miller told James not to waste his time. He said, "The X tree, it's assosciated protocols and APIs, are complicated enough as it is, and the xfree86 project has some of the most talented and capable people in this area. It would be a step backwards to do things outside of xfree86 development. If the issue is that "things don't happen fast enough in the xfree86 tree", why not lend them a hand and submitting patches to them instead of complaining?" Miles Lane agreed, and added to James, "the main impediment to XFree86 giving really good accelleration support for a broad array of hardware is the lack of technical documentation from the manufacturers. Unless you plan on trying to get hardware manufactures to have you develop their closed-source drivers for them, I don't see how you'll be able to do any better than the XFree86 organization is already doing."

Elsewhere, Larry McVoy said that the last thing the free software community needed was another project. He said, "What the world does need is people who roll up their sleeves and do real work. You may well be one of them, that would be cool. But what would be even cooler is if we join together on real, existing efforts and work on them rather than just constantly make up a new project. Yeah, it's a lot harder, you have to put at least part of your ego aside and accept someone else's leadership, but more gets done that way." Richard Gooch replied, "Fixing NFS corruption would be a good project to work on. Despite years of banging away at this problem, the community has yet to fix it."

Later, James replied to the conversation in general, saying, "Thank you. It is true all I want to do is help the community. I feel as alot of people do XFree86 can not meet the needs of the community. It is very sad that people feel that no amount of people in the open source community can make code of the same or better quality as XFree86 in a shorter period of time. I don't feel this way. Now I'm off to work on code and documentation for the project. Thank you."

Daniel Phillips locked his brain into the True Source, in order to discover why deleting a million files took four times as long as creating them. Emerging from his reverie, he said, "It's simple. It followed from observing that there is actually a lot more disk space devoted to the inodes of a directory than the directory entries themselves, something like 6 times more. Inodes are packed together 32 per block (4K blocks). With really big directories not all inode blocks can fit in cache. Now, if you go deleting files in random order there will be a lot of inode blocks in cache with some, but not all, of the inodes on them deleted. Some of these blocks will be chosen for writeout to make space for new blocks that have to be updated, and they will have to be read back in later to delete the rest of the inodes on them." He tested this in practice with some code included in his post, and proposed several possible solutions. There was a bit of discussion, but nothing conclusive came out of it.

Wayne Brown asked about the status of write support for the NTFS filesystem. For more on this, see Issue #106, Section #21 (3 Feb 2001: Linux NTFS Project Announced) . Anton Altaparmakov replied, "It is extremely dangerous. Never use unless you are desperate. It creates corrupt files and especially directories. It also cannot delete at all (not implemented). - If you do write you have to run ntfsfix utility on the partition after umount before rebooting into Windows which will let chkdsk run on next reboot which should fix all problems created by the driver. - ntfsfix is part of the Linux-NTFS project. You can download the source/source rpm or pre-compiled rpm from http://sourceforge.net/projects/linux-ntfs/" . He suggested using FAT32 instead of NTFS. Lee Leahu asked what the developers were doing to get NTFS write support working, and Joanne Dow replied, "My understanding of the situation is that writing to an NTFS volume is not quite 100% guaranteed to destroy the disk directory structure. MS mutates it faster than people can reverse engineer it in a proper "clean" manner. The person who had been working the issue had access to MS information in support of some other products. MS came down on him about supporting NTFS. So he has surrendered such materials as he has rather than continue with the MS product support and is concentrating on Linux. But until his NDA runs out he cannot work on the NTFS code. Other people have picked up the ball. But as noted MS mutates NTFS remarkably rapidly so I'd not look for support for NTFS in the near future." Doug McNaught also replied to Lee, saying, "It's dangerous because NTFS is a proprietary format, and the full rules for updating it (including journals etc) are known only to Microsoft and those that have signed Microsoft NDAs. If you update it incorrectly it gets corrupted and you will lose data. It's certainly possible to reverse-engineer these rules, but very difficult and time-consuming."

Whomever removed WRITERAW has broken NWFS. WRITE requests call _refile_buffer() after the I/O request and take my locally created buffer heads and munge them back into the linux buffer cache, causing massive memory corruption in the system. These buffers don't belong in Linus' buffer cache, they are owned by my LRU and ll_rw_block should not be blindly filing them back into the buffer cache.

Please put something back in to allow me to write without the buffer heads always getting filed into Linus' buffer cache. This has broken NWFS on 2.4.3 and above.

As for using Linus' buffer cache, until you put in the ability to create logical block mapping instead of physical, I will not be able to use it. Hopefully, this will make it in 2.5. I have some folks trying to use this with 2.4.3 and they are dead in the water until this gets addressed.

Jens Axboe posted a way for Jeff to do his writes as he wanted, using the following construct:

As ECN deployment increases, people are increasingly noticing that some key web sites are still inaccessible when ECN is enabled.

A Web site has been created to assist with this transition, with two key features: (1) ECN-related fixes are posted on this Web page, and (2) vendors whose products are broken are posted on this Web page.

The address is http://gtf.org/garzik/ecn/


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	7 Apr 2001 - 19 Apr 2001	(47 posts)	Multi-Function PCI Devices
2.	12 Apr 2001 - 18 Apr 2001	(8 posts)	Enabling 64-Bit DMAs
3.	16 Apr 2001 - 19 Apr 2001	(21 posts)	Status Of ACPI
4.	16 Apr 2001 - 21 Apr 2001	(19 posts)	CML2 Looking Good
5.	18 Apr 2001 - 20 Apr 2001	(14 posts)	New Open Source X Server Project
6.	18 Apr 2001 - 19 Apr 2001	(11 posts)	Ext2 File Deletion Performance
7.	20 Apr 2001 - 21 Apr 2001	(18 posts)	Status Of NTFS Write Support
8.	23 Apr 2001	(3 posts)	NWFS Glitches In 2.4.3
9.	25 Apr 2001	(2 posts)	ECN Vendor Support Page

Kernel Traffic #116 For 30 Apr 2001

By Zack Brown