If you like Kernel Traffic and want to send me a little money, click here:
Christian Axelsson asked, Whats the
current status of the Intel PRO/Wireless 2100 MiniPCI? Some rumours says
that its based upon the prisma 2.5 chip but I havent had any luck with those
drivers. Intel stays passive it seems.
Anders Karlsson replied:
It is not a Prism 2.5 chipset, it is an Intel chipset that currently is unsupported. I have not had a response from Intel in my last mail to them, but I guess there could be holiday time there.
For the time being those mini-PCI cards is dead weight in the laptop I am afraid. I hope that either Intel suddenly sees sense (snowflake in hell analogy coming on) or some bright spark reverse engineers the card and writes an alpha driver that surpasses the functionality of the Intel beta drivers they keep under lock and key internally.
I'll probably locate some Prism CardBus card in the meantime to use.
Bas Mevissen suggested for brave souls:
My dead weight was called Dell TrueMobile 1300 (with BroadCom chipset). What I did is buying a NetGear WG311 PCI card (802.11b/g). It contains a mini-pci card in a slot unders a metal cover and some small stuff on the PCI-shape PCB.
The cover is easy to remove (only 3 pins) and the antenna is not soldered, but connected with the same connector as in my notebook. I could only connect 1 (main) antenna, but the PCI card has only one antenna too. So you only loose antenna diversity.
The NetGear contains an Atheros chipset. There is some open source stuff available (URL forgotten) and a driver (mafwifi) with a binary-only hardware abstraction. Not really what you want, but at least a start. A combination of both may lead to a more desirable result. But for me it is fine to use. Only I can not issue bug reports when the driver has been loaded since the last boot.
James W. Laferriere asked, Do you (or
anyone else) know which of the 'PCI' based cards are use the 'mini-pci'
cards on a bridge card ? I'd really like more of a selection to choose from
than just Netgear . The Netgear card you spoke of below religously doesn't
mention Linux in it's support sections . But , (hopefully) it appears that
you are using under linux , correct ?
Bas replied, I use it with Linux. Actually, I did not more than a few tests. But
I know it works and I verified it with the XP install that came with the
notebook. I just had to install the PCI-card drivers there.
As for
James' bridge card question, Bas added, Probably
all PCI-cards that have a huge metal casing. PCI WLAN cards are not so common
(desktop and wireless is a bit silly :-))and hence the development costs
for a "real" PCI WLAN card might be too high compared to the extra cost of
using a Mini-PCI and a bridge. Actually, "bridge" is too much honour for
the remaining card. Slot converter is more appropriate.
Bas also urged people to exercise caution when tinkering with their systems
as he had. He said, Note that this kind of use of
mini-pci modules is all on your own risk and responsibility. Maybe I better
had not told this on LKML. But now that has happened, I advise people to
think twice before doing it and ask me for details in private if they feel
uncertain about it.
Erik Andersen announced:
Not too long ago I submitted an IDE patch fixing CONFIG_IDEDISK_STROKE. That in turn prompted a flurry of patches fixing a number of related IDE capacity problems.
I have backported the lot (which includes my original fix) to 2.4.x. I believe these should be included into 2.4.x, but I leave the final call to you. I am running with all of these patches in my 2.4.x kernel and everything is working nicely.
After some private comments from folks on the list he posted a revised patch, but Alan Cox had objections. He said:
Its sufficient to stop bad things happening, its not sufficient to get the desired end user result of being able to read their disk if it moved controller. Bartlomiej pointed out that because of the other traps the problem doesn't occur right now except moving a disk.
I'll post an additional diff tomorrow which adds hwif->dma_addressing (or dma_lba48 given the changes to naming people seem to prefer) so that can get fixed.
Joern Engel to remove Daniel Quinlan from the MAINTAINERS file as maintainer
of CramFS, when Daniel failed to respond to an email. Pavel Machek suggested
at least CCing Daniel on the patch to remove him, and Joern clarified, His mail as in MAINTAINERS bounces and Linus tried to contact
him a while ago. No reply that I am aware of.
William Stearns gave
an address for Daniel, but Joern reiterated that Linus had been unable to
reach him. Then Daniel said, Well, I don't see any
Linus email me about this, but just the same, sorry about the non-responses.
In the short run, if you resend your patch, I'll get back to you for real.
In the long run, cramfs (and the sourceforge tools project) probably could
use a new maintainer and it really should be the same person.
Ruben Puettmann asked, What's up with
linux-2.2 now? Who will do Alan's job in the next year? Marc
[Marc-Christian Petersen] is intrested doing
this job. I know Marc from linux-2.2.x-secure and from the wolk project, see
http://wolk.sourceforge.net. Why not Marc? He can surely differentiate between
mainstream and a private kernel fork tree.
[...] I can't see postings from other people who want to take 2.2.
I think 2.2 is not dead. I often see 2.2 kernels running on systems like wlan
access points or dsl routers from different vendors. 2.2 is often used where
stability is a must-have. At least security fixes have to go in.
A. De
Faccio replied that it did seem that 2.2 should continue to be maintained.
Marc-Christian said he saw a lot of stuff that could be done in 2.2, and
indicated that he would be willing to take over from Alan Cox as maintainer;
but he added, Anyway, no comment from
Alan, so I think he don't want to give 2.2 away to me.
Alan replied,
but avoided that questions, saying, The problem is
that change breaks stuff. a lot of the 2.2 users will happily trade lack of
LBA48 support for stability and predictability. Thats why I took a basically
"if its not a serious bugfix its not going in" approach.
Aaron Lehmann reported:
At the *root* of a fresh checkout:
$ head -2 Makefile # # Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved.It's the XFS makefile...
Larry McVoy's mind snapped, and he replied:
This is your message recast in the context of the kernel, or at least this is what it sounded like to me:
*Sigh*. The kernel oops *again*. How dare you give me this kernel for free and then break it. Fix it, right now, and I'd like an apology along with the fix. Hurry up.Maybe you didn't intend it to sound like that and you'd like to rephrase it.
Ken Moffat replied, just because the subject
contains the magic letters "bk" does not mean it's neccesarily an attack on
your product.
Larry replied angrily:
Let's put this into context. I got up this morning to find Aaron's posting and I started looking into the problem. It turned into a mess and rather than spend Saturday with my wife and kids I sent them out of the house so I could focus on this and fix it. It took several hours to track down the bug and the tree has been rebuilding since about 1pm.
I gave up half my weekend to fix this stuff. I made my family get out of the house for your benefit, my wife is pissed at me, my kids are pissed at me, and people here are rude to me for giving them something for free that they should have built themselves. Hey, wrong answer and I'm the idiot for putting up with it. So I pointed out to the list that I don't like it and I tried to make it clear by pointing out that you wouldn't put it with that sort of bug report from me about the kernel.
Apparently I wasn't clear enough so here is try #2:
- We don't owe you this service
- You could have built this service
- People are routinely rude about it when there are problems
- Keep it up and the service goes away
We didn't get a nice message saying "please look at bk2cvs, it seems broken", we got an annoyed message from some guy with an ax to grind. Here's a quote from him talking about Pavel's oh-so-great BitKeeper clone:
"It would be better if you stored it in BitKeeper just to piss Larry off."
http://marc.theaimsgroup.com/?l=linux-kernel&m=104653836702419&w=2
The bk2cvs gateway is a free service, it costs us money to provide it. People seem to think we are obligated to provide it and support it, and they think it's OK to be rude. Here's a feedback loop for you: every time I get a rude mail about this service the gateway gets shut down. First time is 1 day and it doubles every time after that. That means that you all as a community need to pass the word that it's not healthy to be rude. I'm sick of it, I've had it with that, I have absolutely zero tolerance for it and no sense of humor about it.
Some people have gotten the message, Ben Collins is a great example. He's been polite and pleasant to deal with and as a result we host the BK2SVN gateway next to the BK2CVS gateway. If you're nice I'll bend over backwards to help you but I've had it with rude people. It doesn't take any substantial effort to be polite and you as a community need to require that politeness or give up the gateway. It's that simple.
Elsewhere, Aaron said to Larry, The disrespect
wasn't directed towards you, but at the problem. BKcvs is a great resource,
but it's got some recurring bugs, and they're quite frustrating. While I
realize you're the author, everyone makes mistakes. Your work on the CVS
gateway is appreciated, even though it isn't flawless yet.
Voicu Liviu was planning to migrate to a 2.6 kernel, and wanted to know whether LVM or EVMS was the best way to handle multiple disk volumes. Jose Luis Domingo Lopez replied:
2.6.0 will have many changes with respect to LVM and EVMS. LVM is updated to newer version 2 (LVM2), based on DM (Device Mapper), sort of a simplified in-kernel LVM that just handles discovering the drives. Updated userspace utilities (LVM2) are already available to drive this.
On the other part, EVMS was completely redesigned. Former EVMS implementation was duplicating too much code, and in general it was regarded as a bad implementation on a very good idea, so the people at IBM in charge on EVMS development took what it look to everyone as a very clever move, and for 2.6.x they implemented EVMS on top of DM. User space utilities for EVMS are (from the user's point of view) the same as before, but now the inner details are different: no reimplementation of software RAID, no reimplementation of LVM, etc.
Have a look at both projects websites to get more accurate and detailled information about them:
http://evms.sourceforge.net/
http://www.sistina.com/products_lvm.htm
Wakko Warner remarked, I noticed the kernel
doesn't have LVM as an option now. Does both projects just use the DM from
userspace?
Wichert Akkerman confirmed that yes, they did. Voicu
Liviu asked for some more explanation, and Jose replied:
In 2.6.x there is just support for Device Mapper. From "Multi-device support (RAID and LVM)" you can see:
x x <M> Device mapper support x x [*] ioctl interface version 4Both LVM2 and EVMS (from version 2.0.0) use Device Mapper. For LVM2 you just need to get updated userspace tools from your vendor or directly from www.sistina.com. For EVMS to work, see: http://evms.sourceforge.net/install-2.0.html
Marcelo Tosatti announced 2.4.22-rc3 and said that would hopefully be
the last -rc release before 2.4.22 proper. He added, The ACPI changes should fix most of well known ACPI issues.
Willy Tarreau gave it a whirl and said, it's OK
for me, both on my Dual Athlon and my VAIO (ACPI still OK BTW). I also
encountered the unresolved dependency that Eyal reported for tc35815,
but that's harmless.
And David van Hoose also confirmed, ACPI is still working perfectly for me on my Asus
P4S8X. No USB or ethernet problems like with 2.6. No odd ACPI warnings or
non-fatal errors either. Whatever these fixes are, they should also go in
2.6 ASAP. :-)
Elsewhere, under the Subject: "Linux 2.4.22-rc4", Marcelo put out 2.4.22-rc4
after all, to fix x86-64 ia32 emulation and a few other problems that had
cropped up. Then finally under the Subject: "linux-2.4.22 released", he
released 2.4.22 with no changes from -rc4. Matthias Andree asked, What are the plans for 2.4.23? XFS merge perhaps
<hint>?
Christoph Hellwig said he was preparing some XFS patches
for that purpose, but if the merge-rate doesn't
increase it's more like 2.4.24 or 2.4.25..
A lot of other folks wanted
to see ALSA in 2.4, but a number of folks argued that there was no need for
this, since 2.6 had ALSA, and folks could use that if they needed it. It
was also pointed out that ALSA would be easy to install in 2.4 separately,
without requiring integration in the official sources.
Elsewhere, Nick Piggin suggested that some of Andrea Arcangeli's Virtual
Memory work should go into 2.4, and Marcelo replied, Definately. Thats the first thing I'm going to do after looking
through "2.4.23-pre-patches" folder.
Elsewhere Alan Cox suggested that as little as possible should go into 2.4,
especialyl stuff that affects driver interfaces. 2.6-test
is the place to direct your latest and greatest works IMHO.
Jan Niehusmann said:
Two weeks ago, I tried two patches against 2.4.21 regarding LBA48 support. One limits the size of a drive to 137GB if LBA48 is not available. Without this patch, severe data corruption is possible.
http://gondor.com/linux/patch-limit48-2.4.21
The other one is making LBA48 support work with pdc 20265 controllers.
http://gondor.com/linux/patch-pdc-lba48-2.4.22
I think they should be candidates for inclusion in 2.4.23, as well as a fix for hdparm -I (and other commands going directly to the drive) on (some?) promise controllers:
http://marc.theaimsgroup.com/?l=linux-kernel&m=104250818527780&w=2
Bartlomiej Zolnierkiewicz asked Marcelo Tosatti to apply those patches, and Erik Andersen also said that his recent patches also fixed the same problem. And close by, Alan Cox said that both patches looked wrong to him. Bartlomiej didn't think this was the case, and the thread ended inconclusively.
Ricky Beam noticed that the public BitKeeper repository had not been updated
for several days, and asked if there were a problem with the BitMover servers.
Jeff Garzik explained that Linus Torvalds was just on vacation, and that
was why no patches had been committed. Larry McVoy also asked Andrew Morton
(who will apparently maintain 2.6 when Linus lets it go), Hmm. Andrew, what's the workflow? Is Linus still the guy who pushes
to bkbits or is that now your or him? If you need to be able to do it I'll set
that up.
Andrew confirmed that Linus still handled all 2.6 pushes, and
added, There's no pressing need at this time thanks.
It could be that we keep going this way until 2.7 is forked off.