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?
Linus Torvalds replied:
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.
James Simmons announced:
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.
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 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.
Jeff V. Merkey reported:
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:
bh->b_end_io = my_end_io_handler;
submit_bh(WRITE, bh);
Jeff was very happy, and rushed off to code and test.
Jeff Garzik announced:
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/
Drew Bertola added, Sally Floyd's
page on Explicit Congrestion Notification in TCP/IP. http://www.aciri.org/floyd/ecn.html