Re: [argyllcms] Re: [PATCH] usb/hid: Blacklist the Gretag-Macbeth Huey display colorimeter
[Replying twice because I replied to the wrong message at first] Le dimanche 16 décembre 2007 à 17:59 +0100, Jiri Kosina a écrit : > What exactly is the problem here? I didn't seem to catch the beginning of > the thread (or it happened off the list I am subscribed to). For more info on usb colorimeter problems you can check http://www.freelists.org/archives/argyllcms/12-2007/ It seems Graeme Gill, the Argyll CMS author has hit several linux usb problems over the years but has not coordinated well with the Linux usb maintainers. We're finding all the ugly bits now that we're trying to meger Argyll CMS in various distributions (Fedora, Mandriva, Ubuntu, etc) It's a bit difficult to follow this thread because the argyllcms list is killing CCs and not everyone is putting them back in. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [argyllcms] Re: [PATCH] usb/hid: Blacklist the Gretag-Macbeth Huey display colorimeter
[Replying twice because I replied to the wrong message at first] Le dimanche 16 décembre 2007 à 17:59 +0100, Jiri Kosina a écrit : What exactly is the problem here? I didn't seem to catch the beginning of the thread (or it happened off the list I am subscribed to). For more info on usb colorimeter problems you can check http://www.freelists.org/archives/argyllcms/12-2007/ It seems Graeme Gill, the Argyll CMS author has hit several linux usb problems over the years but has not coordinated well with the Linux usb maintainers. We're finding all the ugly bits now that we're trying to meger Argyll CMS in various distributions (Fedora, Mandriva, Ubuntu, etc) It's a bit difficult to follow this thread because the argyllcms list is killing CCs and not everyone is putting them back in. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [argyllcms] Re: [PATCH] usb/hid: Blacklist the Gretag-Macbeth Huey display colorimeter
Le vendredi 14 décembre 2007 à 22:46 +1100, Graeme Gill a écrit : > Nicolas Mailhot wrote: > > >>Care to make up a patch as per the Documentation/SubmittingPatches file > >>and send it to this list and the HID driver maintainer? That way you > >>get the proper credit for this change. > > > > The things I do as a public service, I don't even have the damn Huey > > myself:( > > Actually (to put it frankly), I'm amazed that this exceptions list is > compiled into the driver. I would have thought that such a list should > at least be in a configuration file that an installed application can > add or delete, if not something more sophisticated. Something more sophisticated will happen someday, this is what we have now. > What will happen if the > HID driver is fixed to allow arbitrary messages, and I want to switch > back to using it rather than libusb ? Then the person doing the HID code fix should remove the blacklist entry at the same time. > And the question still remains as to why usb_detach_kernel_driver_np() > works fine on some systems (ie. the one I'm testing on), and not (apparently) > others. I'm not saying it does not work, I'm saying I don't want my users to fool with kernel modules when we know the default should not be HID for huey right now. If you prefer enhancing the kernel HID driver, and switching argyll to it, just do it. I don't care as long as I don't have to maintain workarounds distro-side. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
[PATCH] usb/hid: Blacklist the Gretag-Macbeth Huey display colorimeter
Le jeudi 13 décembre 2007 à 21:38 -0800, Greg KH a écrit :
> On Thu, Dec 13, 2007 at 11:37:40PM +0100, Nicolas Mailhot wrote:
> > The Gretag-Macbeth Huey display colorimeter claims to be an HID device
> > but isn't. As a result the linux HID device will claim it, preventing
> > FLOSS software like Argyll CMS (http://www.argyllcms.com/) from talking
> > to it,
> > Frédéric Crozat from Mandriva has such a device and may provide more
> > info.
> Care to make up a patch as per the Documentation/SubmittingPatches file
> and send it to this list and the HID driver maintainer? That way you
> get the proper credit for this change.
The things I do as a public service, I don't even have the damn Huey
myself:(
There seems to be some complains about libusb BTW
(http://www.freelists.org/archives/argyllcms/12-2007/msg00068.html)
Signed-off-by: Nicolas Mailhot <[EMAIL PROTECTED]>
diff -uNr linux-2.6.24-rc5.orig/drivers/hid/usbhid/hid-quirks.c
linux-2.6.24-rc5/drivers/hid/usbhid/hid-quirks.c
--- linux-2.6.24-rc5.orig/drivers/hid/usbhid/hid-quirks.c 2007-12-11
04:48:43.0 +0100
+++ linux-2.6.24-rc5/drivers/hid/usbhid/hid-quirks.c2007-12-14
10:41:01.0 +0100
@@ -85,6 +85,9 @@
#define USB_VENDOR_ID_CHIC 0x05fe
#define USB_DEVICE_ID_CHIC_GAMEPAD 0x0014
+#define USB_VENDOR_ID_GRETAGMACBETH0x0971
+#define USB_DEVICE_ID_GRETAGMACBETH_HUEY 0x2005
+
#define USB_VENDOR_ID_CIDC 0x1677
#define USB_VENDOR_ID_CMEDIA 0x0d8c
@@ -423,6 +426,7 @@
{ USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_SUPER_Q2, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_GOGOPEN, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_PENPOWER, HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_GRETAGMACBETH, USB_DEVICE_ID_GRETAGMACBETH_HUEY,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_POWERMATE, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_SOUNDKNOB, HID_QUIRK_IGNORE },
--
Nicolas Mailhot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb/hid: Blacklist the Gretag-Macbeth Huey display colorimeter
Le jeudi 13 décembre 2007 à 21:38 -0800, Greg KH a écrit :
On Thu, Dec 13, 2007 at 11:37:40PM +0100, Nicolas Mailhot wrote:
The Gretag-Macbeth Huey display colorimeter claims to be an HID device
but isn't. As a result the linux HID device will claim it, preventing
FLOSS software like Argyll CMS (http://www.argyllcms.com/) from talking
to it,
Frédéric Crozat from Mandriva has such a device and may provide more
info.
Care to make up a patch as per the Documentation/SubmittingPatches file
and send it to this list and the HID driver maintainer? That way you
get the proper credit for this change.
The things I do as a public service, I don't even have the damn Huey
myself:(
There seems to be some complains about libusb BTW
(http://www.freelists.org/archives/argyllcms/12-2007/msg00068.html)
Signed-off-by: Nicolas Mailhot [EMAIL PROTECTED]
diff -uNr linux-2.6.24-rc5.orig/drivers/hid/usbhid/hid-quirks.c
linux-2.6.24-rc5/drivers/hid/usbhid/hid-quirks.c
--- linux-2.6.24-rc5.orig/drivers/hid/usbhid/hid-quirks.c 2007-12-11
04:48:43.0 +0100
+++ linux-2.6.24-rc5/drivers/hid/usbhid/hid-quirks.c2007-12-14
10:41:01.0 +0100
@@ -85,6 +85,9 @@
#define USB_VENDOR_ID_CHIC 0x05fe
#define USB_DEVICE_ID_CHIC_GAMEPAD 0x0014
+#define USB_VENDOR_ID_GRETAGMACBETH0x0971
+#define USB_DEVICE_ID_GRETAGMACBETH_HUEY 0x2005
+
#define USB_VENDOR_ID_CIDC 0x1677
#define USB_VENDOR_ID_CMEDIA 0x0d8c
@@ -423,6 +426,7 @@
{ USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_SUPER_Q2, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_GOGOPEN, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GOTOP, USB_DEVICE_ID_PENPOWER, HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_GRETAGMACBETH, USB_DEVICE_ID_GRETAGMACBETH_HUEY,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_POWERMATE, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_GRIFFIN, USB_DEVICE_ID_SOUNDKNOB, HID_QUIRK_IGNORE },
--
Nicolas Mailhot
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [argyllcms] Re: [PATCH] usb/hid: Blacklist the Gretag-Macbeth Huey display colorimeter
Le vendredi 14 décembre 2007 à 22:46 +1100, Graeme Gill a écrit : Nicolas Mailhot wrote: Care to make up a patch as per the Documentation/SubmittingPatches file and send it to this list and the HID driver maintainer? That way you get the proper credit for this change. The things I do as a public service, I don't even have the damn Huey myself:( Actually (to put it frankly), I'm amazed that this exceptions list is compiled into the driver. I would have thought that such a list should at least be in a configuration file that an installed application can add or delete, if not something more sophisticated. Something more sophisticated will happen someday, this is what we have now. What will happen if the HID driver is fixed to allow arbitrary messages, and I want to switch back to using it rather than libusb ? Then the person doing the HID code fix should remove the blacklist entry at the same time. And the question still remains as to why usb_detach_kernel_driver_np() works fine on some systems (ie. the one I'm testing on), and not (apparently) others. I'm not saying it does not work, I'm saying I don't want my users to fool with kernel modules when we know the default should not be HID for huey right now. If you prefer enhancing the kernel HID driver, and switching argyll to it, just do it. I don't care as long as I don't have to maintain workarounds distro-side. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: 2.6.23-rc4-mm1
Mats Johannesson bredband.net> writes: > > On 2007-09-01 16:07:48 Torsten Kaiser wrote: > [...] > > The good: > >> +hpet-force-enable-on-vt8235-37-chipsets.patch > >> +hpet-force-enable-on-vt8235-37-chipsets-fix.patch > > > > Kernel 2.6.23-rc4-mm1 works on one of my systems with: > > 00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host > > Bridge (rev 01) > > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge > > [K8T800/K8T890 South] > > And glory, glory, my Acer Aspire 1520 (1524) AMD64 notebook with the > old vt8235 chipset got a good kick in the behind as well. Now we have working HPET override for Intel and Via, could Nvidia users be considered too? The required info has been known for ages: http://marc.info/?l=linux-kernel=117679014505031 Regards, -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc4-mm1
Mats Johannesson spamcan at bredband.net writes: On 2007-09-01 16:07:48 Torsten Kaiser wrote: [...] The good: +hpet-force-enable-on-vt8235-37-chipsets.patch +hpet-force-enable-on-vt8235-37-chipsets-fix.patch Kernel 2.6.23-rc4-mm1 works on one of my systems with: 00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] And glory, glory, my Acer Aspire 1520 (1524) AMD64 notebook with the old vt8235 chipset got a good kick in the behind as well. Now we have working HPET override for Intel and Via, could Nvidia users be considered too? The required info has been known for ages: http://marc.info/?l=linux-kernelm=117679014505031 Regards, -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le mardi 19 juin 2007 à 21:56 +0200, Diego Calleja a écrit : > Please, stop pretending you are hardware manufacturers. You are not. Please, stop pretending the end user has no say in the GPL. The GPL (v2 or v3) is written with the end user not the hardware manufacturer in mind. Also I can tell you the enterprises who make the living of Red Hat, Novell and IBM (to name some major kernel contributors) care very much about their part of the GPL deal. That is they can dump a supplier (hardware or software) at any moment because he has no lock on their system. Should the kernel devs ally themselves with entities like Tivo who put the vendor lock-in back in free/libre systems, said systems attractivity will decrease sharply (and it only takes a few managers to notice their Linux systems are just as locked as the usual proprietary ones) Tivo didn't make the Linux success. More Tivos can definitely undo it. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le mardi 19 juin 2007 à 10:50 -0700, David Schwartz a écrit : > > > The GPL was never about allowing you to load modified software > > > onto hardware > > > where the legitimate creators/owners of that hardware say, "no, > > > you may not > > > modify the software running on this hardware". > > > Good try but you had to add creators there so the sentence actually > > supported your opinion. It's still an obvious alien insert. > > It's simply shorter than saying "owners of the right or ability to decide > what software runs on that hardware". Right is not the same thing as ability. You have a technical ability which has been converted in a "right" which in turn is used as argument to reject GPLv3. But did the original conversion happened with the approval of everyone having rights to the result? I think not. All the "GPLv2 didn't think of DRM therefore DRM is GPLv2-protected" arguments make me sick. If tomorrow Ford starts mass+producing flying saucers will they be exempt from traffic regulations because current traffic regulations only consider cars? I think not. Yet the same argument is the core of most GPL v3 objections we've seen in this thread. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> The GPL was never about allowing you to load modified software onto hardware > where the legitimate creators/owners of that hardware say, "no, you may not > modify the software running on this hardware". Good try but you had to add creators there so the sentence actually supported your opinion. It's still an obvious alien insert. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> > But you're not the user of the software on my laptop. I am. > > ahh, but by your own argument you aren't > > the software on your laptop is owned by people like Linus, Al Viro, David > M, Alan Cox, etc. More accurately according to the GPL v2 theory Linus advanced the laptop you paid is a shared property of the laptop manufacturer (who can install whatever he likes without your input thanks to DRM) and the kernel developper (who gets the source code). You as end-user are only there to give this technical elite the money they need to continue their activities (I'm forcing the point? Find me one anti-GPL-v3 message in this thread that acknowledged the buyer/user had any right) This thanks to DRM which was not provided for when GPL v2 was written and has been retroactively declared kosher. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
But you're not the user of the software on my laptop. I am. ahh, but by your own argument you aren't the software on your laptop is owned by people like Linus, Al Viro, David M, Alan Cox, etc. More accurately according to the GPL v2 theory Linus advanced the laptop you paid is a shared property of the laptop manufacturer (who can install whatever he likes without your input thanks to DRM) and the kernel developper (who gets the source code). You as end-user are only there to give this technical elite the money they need to continue their activities (I'm forcing the point? Find me one anti-GPL-v3 message in this thread that acknowledged the buyer/user had any right) This thanks to DRM which was not provided for when GPL v2 was written and has been retroactively declared kosher. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
The GPL was never about allowing you to load modified software onto hardware where the legitimate creators/owners of that hardware say, no, you may not modify the software running on this hardware. Good try but you had to add creators there so the sentence actually supported your opinion. It's still an obvious alien insert. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le mardi 19 juin 2007 à 10:50 -0700, David Schwartz a écrit : The GPL was never about allowing you to load modified software onto hardware where the legitimate creators/owners of that hardware say, no, you may not modify the software running on this hardware. Good try but you had to add creators there so the sentence actually supported your opinion. It's still an obvious alien insert. It's simply shorter than saying owners of the right or ability to decide what software runs on that hardware. Right is not the same thing as ability. You have a technical ability which has been converted in a right which in turn is used as argument to reject GPLv3. But did the original conversion happened with the approval of everyone having rights to the result? I think not. All the GPLv2 didn't think of DRM therefore DRM is GPLv2-protected arguments make me sick. If tomorrow Ford starts mass+producing flying saucers will they be exempt from traffic regulations because current traffic regulations only consider cars? I think not. Yet the same argument is the core of most GPL v3 objections we've seen in this thread. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le mardi 19 juin 2007 à 21:56 +0200, Diego Calleja a écrit : Please, stop pretending you are hardware manufacturers. You are not. Please, stop pretending the end user has no say in the GPL. The GPL (v2 or v3) is written with the end user not the hardware manufacturer in mind. Also I can tell you the enterprises who make the living of Red Hat, Novell and IBM (to name some major kernel contributors) care very much about their part of the GPL deal. That is they can dump a supplier (hardware or software) at any moment because he has no lock on their system. Should the kernel devs ally themselves with entities like Tivo who put the vendor lock-in back in free/libre systems, said systems attractivity will decrease sharply (and it only takes a few managers to notice their Linux systems are just as locked as the usual proprietary ones) Tivo didn't make the Linux success. More Tivos can definitely undo it. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> I read it: the flash contains everything from the bootloader to the > kernel and file system. The bootloader contains the public key and > checks if the kernel/fs > are ok. That includes calculating hashes and checking signatures. > No encryption/decryption there at all. > > Right? > > Then how hard would it be to reprogram the flash, to get rid of all > this crap? Or to just put your public key there. Legally totally impossible under DMCA, EUCD and friends That why the GPLv3 has the distributor of the software both give installation info (a key authorized on the device, not necessarily a key authorized on all devices or even the same key as the manufacturer), and declare he gaves up any DMCA-like right to legally forbid installation by the user. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton wrote: >> I always did imply a "within reason". To me that means "if it is >> simple for them to do it and can be simply extended to me as well >> then they have to extend it". Handing out a SHA1 key definitely is >> simple and thus IMO something I can expect them to do. > But the "within reason" isn't there. That some people have inferred that term > applies doesn't matter. You know I was reading the "Wizard of the crow" yesterday (a terrific book about an imaginary dictatorship in Africa) and at one point a minister makes the mistake of using a wording that implies the Ruler and the Country may not be one and the same. Realising his error he quickly suggests adding to the constitution Ruler=Country. Which fails to mollify the Ruler who replies something like "the constitution does not writes the Sun shines, should it?"¹ Law texts are not self-contained logical units like software code. There is always an implied "#include common-sense.h and #include reason.h" in them. Law texts won't spell out common-sense limits. Law texts won't write about situations not happening in real life. Which brings me to another point. What happens when a new situation arises? Is it sufficient to do a litteral reading of existing legal texts to decide what's authorised or not? I'll say no. If something obviously new happens (like DRM did those past years) you *have* to check intent and not just verify if you can weasel by existing wording (and of course ideally wording is adjusted to lift any ambiguïty). Alan Cox could sue Tivo today for all his code they use because his reading of the license he released code under is not the same as theirs. Hell if Linus was named Tivo CEO today Alan could probably sue Linus successfully too. All the messages of people who claim they know the legal status of Tivo WRT its use of GPL-v2 Linux code under DRM is just this – noise. It's trivial to show GPL-v2 didn't envision DRM. It's trivial to show many smart people do not have the same GPLv2 interpretation as Linus. Till the intent of every significant kernel contributor is checked there is no legal certainty. Refusing to look it up may be expedient but won't lift the legal cloud. ¹ Hope this will lighten the mood a bit -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar wrote: > and that's where the GPLv3 errs: it arbitrarily attempts to "define" > some work that can _easily_ be completely separate from the GPL-ed > work to be under the scope of "source code". Well thanksfuly the last draft doesn't and puts keys and other such stuff under "installation information¹". Which does not mean they may not in fact be some sort of derived object, but I find the new language makes the license intent much clearer. And that's the primary objective of a license text. Yes the technical wording is important too, but a judge does not expect the technical wording to be perfect or time-proof, so if you focus on technicalities you get to argue on broken technicalities later because there is not clear intent for the court to rule on. Some would say other parts of the last GPLv3 draft forgot this and focused on technicalities over making the intent clear, and I wouldn't disagree. But the DRM bit has been controversial enough its current re-wording is quite good IMHO. This may be anathema to many on this list but I don't actually care about the original code author well being. I've done my share of contributions to FLOSS projects (in code, testing, money, etc) but I've no illusion the number of projects I've contributed to will be dwarfed by the number of projects I'll use in my everyday-life. So to me software licenses and the various GPL versions are primarily user-enabling tools. You'll note the GPL v2 doesn't particularly care about the original software author either. Source code (and various peripheral bits Alan cares about) must be made available to the end user, not the original code author. It worked out this user was often the original author, or if not said user had an incentive to retransmit the modifications to the original author. But he can choose to have someone else work on the source code without involving original upstream in any way, and the license is fine with that. In fact that is what happens when there is a rift in a project and both parties go working on their own fork. So contrarily to what many people wrote on this list the payback for GPL-ing some code is not access to modifications of this code but maintaining an open technical environment. You increase the FLOSS pool size, you increase the chance the software you use in your everyday life is FLOSS and open to changes. Either changes you do yourself or most often changes someone else made and you download somewhere (because everyone is not a software god, and even those who are will never have the time to fix themselves all the software they interact with²). When you get this software with or for some hardware you care about deploying the changes on hardware you have (usually the same hardware you go the software with) Another way to describe this open technical environment is an environment with no vendor lock-in. For a very long time the GPLv2 served this purpose admirably. Unfortunately nowadays the standalone general-purpose open PC is not playing such a big part in everyday life, and we've been invaded by embedded computers. What's worse the manufacturers of those computers are control-freaks and making changes to the software of those computers is no longer just a matter of having code access. Lastly there is a definite temptation to re-make the PC on their image and add installation controls on it too. Therefore the GPLv2 is not sufficient to this end anymore and something like GPLv3 is necessary. The environment changed. Being able to install is no longer a given but something protected by law you have to explicitely require (yes require, the industry is perfectly able to fuck-itself up collectively for years if let alone, just look at the HDDVD/Blue-ray debacle). What use is the source code of a mobile app to me if the mobile industry decides to lock all the mobiles sold with a DRM lock? Now it could be many people on this list don't care about end users, think only the hardware people/software people relations matter, and are quite happy with the perspective of an environment restricted to a technical elite. In which case I suppose a lot of users are going to revisit their FLOSS over freeware bias in the next years, and we'll find out the exact weight of development in the FLOSS ecosystem. ¹ Information clearly does not mean shipping users all sorts of physical tools to change the hardware, just the knowledge necessary to install stuff ² Rockbox is a terrific example of Free Software logic in action in the embedded space outside technical circles, and would probably be the first casualty of DRM extensions -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar wrote: and that's where the GPLv3 errs: it arbitrarily attempts to define some work that can _easily_ be completely separate from the GPL-ed work to be under the scope of source code. Well thanksfuly the last draft doesn't and puts keys and other such stuff under installation information¹. Which does not mean they may not in fact be some sort of derived object, but I find the new language makes the license intent much clearer. And that's the primary objective of a license text. Yes the technical wording is important too, but a judge does not expect the technical wording to be perfect or time-proof, so if you focus on technicalities you get to argue on broken technicalities later because there is not clear intent for the court to rule on. Some would say other parts of the last GPLv3 draft forgot this and focused on technicalities over making the intent clear, and I wouldn't disagree. But the DRM bit has been controversial enough its current re-wording is quite good IMHO. This may be anathema to many on this list but I don't actually care about the original code author well being. I've done my share of contributions to FLOSS projects (in code, testing, money, etc) but I've no illusion the number of projects I've contributed to will be dwarfed by the number of projects I'll use in my everyday-life. So to me software licenses and the various GPL versions are primarily user-enabling tools. You'll note the GPL v2 doesn't particularly care about the original software author either. Source code (and various peripheral bits Alan cares about) must be made available to the end user, not the original code author. It worked out this user was often the original author, or if not said user had an incentive to retransmit the modifications to the original author. But he can choose to have someone else work on the source code without involving original upstream in any way, and the license is fine with that. In fact that is what happens when there is a rift in a project and both parties go working on their own fork. So contrarily to what many people wrote on this list the payback for GPL-ing some code is not access to modifications of this code but maintaining an open technical environment. You increase the FLOSS pool size, you increase the chance the software you use in your everyday life is FLOSS and open to changes. Either changes you do yourself or most often changes someone else made and you download somewhere (because everyone is not a software god, and even those who are will never have the time to fix themselves all the software they interact with²). When you get this software with or for some hardware you care about deploying the changes on hardware you have (usually the same hardware you go the software with) Another way to describe this open technical environment is an environment with no vendor lock-in. For a very long time the GPLv2 served this purpose admirably. Unfortunately nowadays the standalone general-purpose open PC is not playing such a big part in everyday life, and we've been invaded by embedded computers. What's worse the manufacturers of those computers are control-freaks and making changes to the software of those computers is no longer just a matter of having code access. Lastly there is a definite temptation to re-make the PC on their image and add installation controls on it too. Therefore the GPLv2 is not sufficient to this end anymore and something like GPLv3 is necessary. The environment changed. Being able to install is no longer a given but something protected by law you have to explicitely require (yes require, the industry is perfectly able to fuck-itself up collectively for years if let alone, just look at the HDDVD/Blue-ray debacle). What use is the source code of a mobile app to me if the mobile industry decides to lock all the mobiles sold with a DRM lock? Now it could be many people on this list don't care about end users, think only the hardware people/software people relations matter, and are quite happy with the perspective of an environment restricted to a technical elite. In which case I suppose a lot of users are going to revisit their FLOSS over freeware bias in the next years, and we'll find out the exact weight of development in the FLOSS ecosystem. ¹ Information clearly does not mean shipping users all sorts of physical tools to change the hardware, just the knowledge necessary to install stuff ² Rockbox is a terrific example of Free Software logic in action in the embedded space outside technical circles, and would probably be the first casualty of DRM extensions -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton wrote: I always did imply a within reason. To me that means if it is simple for them to do it and can be simply extended to me as well then they have to extend it. Handing out a SHA1 key definitely is simple and thus IMO something I can expect them to do. But the within reason isn't there. That some people have inferred that term applies doesn't matter. You know I was reading the Wizard of the crow yesterday (a terrific book about an imaginary dictatorship in Africa) and at one point a minister makes the mistake of using a wording that implies the Ruler and the Country may not be one and the same. Realising his error he quickly suggests adding to the constitution Ruler=Country. Which fails to mollify the Ruler who replies something like the constitution does not writes the Sun shines, should it?¹ Law texts are not self-contained logical units like software code. There is always an implied #include common-sense.h and #include reason.h in them. Law texts won't spell out common-sense limits. Law texts won't write about situations not happening in real life. Which brings me to another point. What happens when a new situation arises? Is it sufficient to do a litteral reading of existing legal texts to decide what's authorised or not? I'll say no. If something obviously new happens (like DRM did those past years) you *have* to check intent and not just verify if you can weasel by existing wording (and of course ideally wording is adjusted to lift any ambiguïty). Alan Cox could sue Tivo today for all his code they use because his reading of the license he released code under is not the same as theirs. Hell if Linus was named Tivo CEO today Alan could probably sue Linus successfully too. All the messages of people who claim they know the legal status of Tivo WRT its use of GPL-v2 Linux code under DRM is just this – noise. It's trivial to show GPL-v2 didn't envision DRM. It's trivial to show many smart people do not have the same GPLv2 interpretation as Linus. Till the intent of every significant kernel contributor is checked there is no legal certainty. Refusing to look it up may be expedient but won't lift the legal cloud. ¹ Hope this will lighten the mood a bit -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
I read it: the flash contains everything from the bootloader to the kernel and file system. The bootloader contains the public key and checks if the kernel/fs are ok. That includes calculating hashes and checking signatures. No encryption/decryption there at all. Right? Then how hard would it be to reprogram the flash, to get rid of all this crap? Or to just put your public key there. Legally totally impossible under DMCA, EUCD and friends That why the GPLv3 has the distributor of the software both give installation info (a key authorized on the device, not necessarily a key authorized on all devices or even the same key as the manufacturer), and declare he gaves up any DMCA-like right to legally forbid installation by the user. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le vendredi 15 juin 2007 à 13:27 -0400, Rob Landley a écrit : > Er, yes and no. > > The GPL evolved from the "Emacs License", and _that_ was heavily influenced > by > Stallman's fight with James Gosling over Gosling revoking permission to use > Gosmacs code in GNU Emacs after Gosling sold his codebase to a commercial > entity. > > http://www.free-soft.org/gpl_history/ no and yes :) The second paragraph of this page makes the GNU philosophy the other source of the GPL, and that was definitively influenced by the printer incident -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le vendredi 15 juin 2007 à 12:18 -0400, Florin Malita a écrit : > On 06/15/2007 10:33 AM, Nicolas Mailhot wrote: > > Le Ven 15 juin 2007 15:41, Jesper Juhl a écrit : > > > >> But the only thing that *actually* matters is what the license text > >> *says*. It doesn't matter what the authors of the license text > >> intended > >> > > > > Judges would disagree there > > > > I very much doubt that, read Jesper's phrase carefully: what may matter > is the intent of the *copyrighted work's* author, not the intent of the > *license* author. The intent of the latter is (well, should be) > completely irrelevant to the case. You're right though I suspect even in the case where the copyrighted work author and the licensing author are not the same, a judge will listen to the licensing author if licensor and licensee disagree on a point (the licensing author being a neutral third-party that presumably knows what's in the licence it wrote). Though in this case license author is nothing more than an expert witness -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton wrote > If "DRM" was against the license then an extra section clearly > explaining that could have been added. (in the DRM case I actually > understand the reasoning and agree with it.) Changing licenses is not like changing software code, re-licensing is a major hassle so "release early, release often" is not a viable strategy. That means GPL v3 is not a nice localised incremental patch but a huge patchset on all the issues that have accumulated since GPLv2 was written (and one can discuss the correctness of parts of this patchset) -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar wrote: * Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> > Do they have to provide a ROM burner if the ROM is socketed rather >> > than soldered into place? > >> Of course not. They just can't impose restrictions on your obtaining >> a ROM burner and doing the work yourself. > do you realize that you have just admitted that the Tivo is perfectly > fine and legal? > because you can solder off the ROM from the Tivo and can put in a new > ROM with another bootloader that does not check the SHA1 key. Nope. ROM alone is not the problem The problem is that in this particular case, removing a ROM used to vet software makes you liable under DMCA and friends That's why something that could be tolerated in GPLv2 time before the new IP world order can not be tolerated anymore. DRM is not deadly because of the technical measures but the legal ones GPLv3 is not there to change the technical equation but the legal equation. Blame the change on IP law apprentice sorcerers, not the on FSF -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[Re-sending with the right subject] >> > by your argument, the user has some "right to modify the software", on >> > that piece of hardware it bought which had free software on it, correct? >> >> Yes. This means the hardware distributor who put the software in there must not place roadblocks that impede the user to get where she wants with the software, not that the vendor must offer the user a sport car to take her there. >Okay. That means that if I ship Linux on a ROM chip I have to somehow make >it so that the person purchasing the chip can modify the copy of Linux installed on the chip *if* I want to follow both the spirit and the letter >of the GPLv2. The key word there is "can" You don't have to send the buyer the hardware design, replace the ROM with a flash, use a rom socket that allows easy switching etc. But you can not add measures to your hardware specifically designed to stop the user from modifying the GPL software part. Especially if those measures are something like DRM that do not make the tinkering just technically hard, but legally forbidden. As long as the restrictions result from technical choices not targetted at forbidding changes you're ok. However if the restrictions are deliberately added, have a legal component (and legal is not "may" but absolute "can not"), that's another thing entirely. To take a simple example people will understand: - everywhere around the world judges can order newspapers to publish corrections after a slander trial - these corrections take different forms depending on the media: in the original article for on-line stuff, in new editions for printed stuff So the fact there is a legal obligation to allow judges to change articles does not imply newspapers are forced to forgo read-only paper prints. However editors can not refuse to change the online edition because they have the technical possibility to do so. "Software" change oblications (articles) are not dictating "hardware" (read-only paper prints) Now do anyone has a doubt how a judge would react if the newspaper told him it wouldn't change the online edition because it's protected by a DRM-like lock the newspaper does not want to change or share? DRM is not a technical limitation like paper print, it's a self-imposed artificial limitation. -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> And, as I've taken the time to explain to you, lacking any clear > statement, written at the exact same time as the license, a statement of > intent or spirit cannot have any real legal weight when the text of a > license is finally decided upon. Fortunately the Law recognizes humans are not computers, natural langage is not unambiguous binary code, so statements of intent *have* legal value when a legal text is open to interpretations. That's why ten-line law paragraphs are published with the hundreds of pages of parliamentary discussions on them, which the judge will consider if there's any doubt in his mind. -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le Ven 15 juin 2007 15:41, Jesper Juhl a écrit : > On 15/06/07, Nicolas Mailhot <[EMAIL PROTECTED]> wrote: > >> You'll note I was answering to a message about what the GPL >> intended, >> not the strict literal reading of the GPLv2 words. >> >> And what the GPL authors intended is obvious from the fact it all >> started with a printer driver and the need to change the software >> used >> to control this particular hardware (not some mythical other device >> without manufacturer restrictions >> > But the only thing that *actually* matters is what the license text > *says*. It doesn't matter what the authors of the license text > intended Judges would disagree there > - if they intended something else than what they actually > wrote in the license text, then they made a mistake, Sure > but that's their problem. Nope. That's the problem of anyone who accepted "GPL" contributions and wants to claim a particular intent of the contributors. You can't say all the people who contributed to Linux in the past support GPLv2 over GPLv3 before GPLv3 is finished and you actually ask them. Many of them may support the way FSF clarified a use case no one cared about before Tivo & friends made a legal "breakthrough". > And what is actually in the license text is obviously what > some other people (like Linus for instance) want, so for those people > the GPLv2 is a perfectly fine license that doesn't need to be fixed > because it says exactely what they want it to say. And for others it's not what they want. Some like Alan will say GPLv2 is the better text, but have a different reading than Linus. Other will take the GPLv3 with all its warts rather than let people interpret the GPLv2 contrary to their wishes. Please do them the courtesy to let them do their mind on their own code. > You can talk all you want about the spirit of the license but that > will never change the fact that it's the actual text of the license > that matters in the end. What matters in the end is the code authors will. If they had the same intent as the FSF, the GPLv2 served them right a long time, but no longer, and they can still relicense their code. In the short term, the understanding a licensee had of the license is as important of the licensor intent should there be a trial, but for anything that was released before DRM was generalised I suspect a judge would not make a literal reading of the license, but try to find out what the licensor intentions were and if the licensee deliberately bypassed them through technicalities. -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le Ven 15 juin 2007 12:53, Jesper Juhl a écrit : > On 15/06/07, Nicolas Mailhot <[EMAIL PROTECTED]> wrote: >> >> > by your argument, the user has some "right to modify the >> software", on >> >> > that piece of hardware it bought which had free software on it, >> correct? >> >> >> >> Yes. This means the hardware distributor who put the software in >> >> there must not place roadblocks that impede the user to get where >> she >> >> wants with the software, not that the vendor must offer the user >> a >> >> sport car to take her there. >> >> >Okay. That means that if I ship Linux on a ROM chip I have to >> somehow >> make >> >it so that the person purchasing the chip can modify the copy of >> Linux >> >installed on the chip *if* I want to follow both the spirit and the >> letter >> >of the GPLv2. >> >> The key word there is "can" >> >> You don't have to send the buyer the hardware design, replace the >> ROM >> with a flash, use a rom socket that allows easy switching etc. >> >> But you can not add measures to your hardware specifically designed >> to >> stop the user from modifying the GPL software part. Especially if >> those measures are something like DRM that do not make the tinkering >> just technically hard, but legally forbidden. >> >> As long as the restrictions result from technical choices not >> targetted at forbidding changes you're ok. >> > That's simply not true. > > As long as you get a copy of the source code for the software that's > running on the hardware it's OK. That's all the GPLv2 says. You'll note I was answering to a message about what the GPL intended, not the strict literal reading of the GPLv2 words. And what the GPL authors intended is obvious from the fact it all started with a printer driver and the need to change the software used to control this particular hardware (not some mythical other device without manufacturer restrictions -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
>> > by your argument, the user has some "right to modify the software", on >> > that piece of hardware it bought which had free software on it, correct? >> >> Yes. This means the hardware distributor who put the software in >> there must not place roadblocks that impede the user to get where she >> wants with the software, not that the vendor must offer the user a >> sport car to take her there. >Okay. That means that if I ship Linux on a ROM chip I have to somehow make >it so that the person purchasing the chip can modify the copy of Linux >installed on the chip *if* I want to follow both the spirit and the letter >of the GPLv2. The key word there is "can" You don't have to send the buyer the hardware design, replace the ROM with a flash, use a rom socket that allows easy switching etc. But you can not add measures to your hardware specifically designed to stop the user from modifying the GPL software part. Especially if those measures are something like DRM that do not make the tinkering just technically hard, but legally forbidden. As long as the restrictions result from technical choices not targetted at forbidding changes you're ok. However if the restrictions are deliberately added, have a legal component (and legal is not "may" but absolute "can not"), that's another thing entirely. To take a simple example people will understand: - everywhere around the world judges can order newspapers to publish corrections after a slander trial - these corrections take different forms depending on the media: in the original article for on-line stuff, in new editions for printed stuff So the fact there is a legal obligation to allow judges to change articles does not imply newspapers are forced to forgo read-only paper prints. However editors can not refuse to change the online edition because they have the technical possibility to do so. "Software" change oblications (articles) are not dictating "hardware" (read-only paper prints) Now do anyone has a doubt how a judge would react if the newspaper told him it wouldn't change the online edition because it's protected by a DRM-like lock the newspaper does not want to change or share? -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz wrote : > The GPL is about having the legal right to modify the software and being > able to put other people's distributed improvements back into the > original code base. It does not guarantee that you will actually be able > to modify the software and get it to work on some particular hardware. This is obviously wrong. Need I remind everyone the "origin" of the GNU movement is RMS getting a buggy printer driver from its manufacturer, and finding out he had no way to fix it? What use would RMS have had for putting other people's distributed improvements back into the original code base and not being allowed to get his printer to work? (And yes driver was os-side but only because devices had little computing capabilities then. Nowadays a lot of this very same stuff happens on the DRM-protected flashable firmware) The aim from the start was for the ultimate software recipient (not the software author) to be able to fix a software blob provided with a hardware device, and use it with the original hardware device. Translated on modern hardware that's exactly what people (even non-developper people) do when they download a rockbox image and put it on their MP3 player, and exactly the use case DRM forbids. The plain truth is the GPL v2 didn't target explicitely DRM when it was written because hardware manufacturers hadn't come up with DRM yet. Getting source code available was sufficient because no one "protected" hardware against binaries built from this source code, and embedded hardware logic was either bog-simple and foolproof because neither the manufacturer nor anyone else could change it, or wide open to everyone (the manufacturer but also the buyer of the device). Modern DRM targets this original GPL assumption. GPLv3 only clarifies the intended effects of previous GPL versions. It is a shameless rewriting of history to say the GPLv2 writers considered DRM and wrote a license that allowed it. It is a shameless rewriting of history to claim anyone (Linus included) who released GPL v2 code before DRM was used considered DRM and okayed it. It is a shameless rewriting of history to claim the GPLv3 "spirit" WRT combined software + hardware bundles is any different from the GPLv2 one. The first documented reason for free/libre software was a software+hardware bundle. They never were isolated parts. Moreover many people write about GPLv3 imposing "software" rules on "hardware" design. DRM is wholly about using "software" rules on hardware design. Hardware can be broken and the law allows buyers to break what they bought. The attractiveness of DRM to hardware manufacturers and content producers is precisely it's not hardware, but software that has many interesting legal properties: - it's not sold but licensed, and you can attach strings to the license you can't on a pure hardware deal (Hardware is not licensed. An hardware design may be licensed to other manufacturers, but the hardware implementation buyers receive has no particular legal protection against modifications) - copyright law gives you exclusive rights (supposedly for a time), so you can legaly lock out users and competitors when the law is very clear you're not allowed to for hardware. So to take the ROM case it's very difficult for a user to take a ROM out and replace it with something else. However he can legally do it. Aside from introducing an assymetry between the user and the manufacturer, DRM makes replacement legally forbidden. GPLv3 does not target the technical difficulty but the new legal impossibility (by forcing the GPLv3 distributor to relinquish any legal entitlement to block changes on the GPLv3 part. That it also unlocks the rest of the device is only cheap design that does not distinguish between the parts it blocks) Now kernel authors can choose whatever license they want for code they wrote. They can specify the conditions of acceptance of submitted patches (but not what the authors of the submitted patches think about the GPLv3). They definitively do not have to switch to the GPLv3 just because the FSF released it. However if they want to discuss the rationality of their choice of GPLv2 over GPLv3, it would be nice to get rational arguments and not the gross exagerations, name-callings and dubious analogies this thread is full of. -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz wrote : The GPL is about having the legal right to modify the software and being able to put other people's distributed improvements back into the original code base. It does not guarantee that you will actually be able to modify the software and get it to work on some particular hardware. This is obviously wrong. Need I remind everyone the origin of the GNU movement is RMS getting a buggy printer driver from its manufacturer, and finding out he had no way to fix it? What use would RMS have had for putting other people's distributed improvements back into the original code base and not being allowed to get his printer to work? (And yes driver was os-side but only because devices had little computing capabilities then. Nowadays a lot of this very same stuff happens on the DRM-protected flashable firmware) The aim from the start was for the ultimate software recipient (not the software author) to be able to fix a software blob provided with a hardware device, and use it with the original hardware device. Translated on modern hardware that's exactly what people (even non-developper people) do when they download a rockbox image and put it on their MP3 player, and exactly the use case DRM forbids. The plain truth is the GPL v2 didn't target explicitely DRM when it was written because hardware manufacturers hadn't come up with DRM yet. Getting source code available was sufficient because no one protected hardware against binaries built from this source code, and embedded hardware logic was either bog-simple and foolproof because neither the manufacturer nor anyone else could change it, or wide open to everyone (the manufacturer but also the buyer of the device). Modern DRM targets this original GPL assumption. GPLv3 only clarifies the intended effects of previous GPL versions. It is a shameless rewriting of history to say the GPLv2 writers considered DRM and wrote a license that allowed it. It is a shameless rewriting of history to claim anyone (Linus included) who released GPL v2 code before DRM was used considered DRM and okayed it. It is a shameless rewriting of history to claim the GPLv3 spirit WRT combined software + hardware bundles is any different from the GPLv2 one. The first documented reason for free/libre software was a software+hardware bundle. They never were isolated parts. Moreover many people write about GPLv3 imposing software rules on hardware design. DRM is wholly about using software rules on hardware design. Hardware can be broken and the law allows buyers to break what they bought. The attractiveness of DRM to hardware manufacturers and content producers is precisely it's not hardware, but software that has many interesting legal properties: - it's not sold but licensed, and you can attach strings to the license you can't on a pure hardware deal (Hardware is not licensed. An hardware design may be licensed to other manufacturers, but the hardware implementation buyers receive has no particular legal protection against modifications) - copyright law gives you exclusive rights (supposedly for a time), so you can legaly lock out users and competitors when the law is very clear you're not allowed to for hardware. So to take the ROM case it's very difficult for a user to take a ROM out and replace it with something else. However he can legally do it. Aside from introducing an assymetry between the user and the manufacturer, DRM makes replacement legally forbidden. GPLv3 does not target the technical difficulty but the new legal impossibility (by forcing the GPLv3 distributor to relinquish any legal entitlement to block changes on the GPLv3 part. That it also unlocks the rest of the device is only cheap design that does not distinguish between the parts it blocks) Now kernel authors can choose whatever license they want for code they wrote. They can specify the conditions of acceptance of submitted patches (but not what the authors of the submitted patches think about the GPLv3). They definitively do not have to switch to the GPLv3 just because the FSF released it. However if they want to discuss the rationality of their choice of GPLv2 over GPLv3, it would be nice to get rational arguments and not the gross exagerations, name-callings and dubious analogies this thread is full of. -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
by your argument, the user has some right to modify the software, on that piece of hardware it bought which had free software on it, correct? Yes. This means the hardware distributor who put the software in there must not place roadblocks that impede the user to get where she wants with the software, not that the vendor must offer the user a sport car to take her there. Okay. That means that if I ship Linux on a ROM chip I have to somehow make it so that the person purchasing the chip can modify the copy of Linux installed on the chip *if* I want to follow both the spirit and the letter of the GPLv2. The key word there is can You don't have to send the buyer the hardware design, replace the ROM with a flash, use a rom socket that allows easy switching etc. But you can not add measures to your hardware specifically designed to stop the user from modifying the GPL software part. Especially if those measures are something like DRM that do not make the tinkering just technically hard, but legally forbidden. As long as the restrictions result from technical choices not targetted at forbidding changes you're ok. However if the restrictions are deliberately added, have a legal component (and legal is not may but absolute can not), that's another thing entirely. To take a simple example people will understand: - everywhere around the world judges can order newspapers to publish corrections after a slander trial - these corrections take different forms depending on the media: in the original article for on-line stuff, in new editions for printed stuff So the fact there is a legal obligation to allow judges to change articles does not imply newspapers are forced to forgo read-only paper prints. However editors can not refuse to change the online edition because they have the technical possibility to do so. Software change oblications (articles) are not dictating hardware (read-only paper prints) Now do anyone has a doubt how a judge would react if the newspaper told him it wouldn't change the online edition because it's protected by a DRM-like lock the newspaper does not want to change or share? -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le Ven 15 juin 2007 12:53, Jesper Juhl a écrit : On 15/06/07, Nicolas Mailhot [EMAIL PROTECTED] wrote: by your argument, the user has some right to modify the software, on that piece of hardware it bought which had free software on it, correct? Yes. This means the hardware distributor who put the software in there must not place roadblocks that impede the user to get where she wants with the software, not that the vendor must offer the user a sport car to take her there. Okay. That means that if I ship Linux on a ROM chip I have to somehow make it so that the person purchasing the chip can modify the copy of Linux installed on the chip *if* I want to follow both the spirit and the letter of the GPLv2. The key word there is can You don't have to send the buyer the hardware design, replace the ROM with a flash, use a rom socket that allows easy switching etc. But you can not add measures to your hardware specifically designed to stop the user from modifying the GPL software part. Especially if those measures are something like DRM that do not make the tinkering just technically hard, but legally forbidden. As long as the restrictions result from technical choices not targetted at forbidding changes you're ok. That's simply not true. As long as you get a copy of the source code for the software that's running on the hardware it's OK. That's all the GPLv2 says. You'll note I was answering to a message about what the GPL intended, not the strict literal reading of the GPLv2 words. And what the GPL authors intended is obvious from the fact it all started with a printer driver and the need to change the software used to control this particular hardware (not some mythical other device without manufacturer restrictions -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le Ven 15 juin 2007 15:41, Jesper Juhl a écrit : On 15/06/07, Nicolas Mailhot [EMAIL PROTECTED] wrote: You'll note I was answering to a message about what the GPL intended, not the strict literal reading of the GPLv2 words. And what the GPL authors intended is obvious from the fact it all started with a printer driver and the need to change the software used to control this particular hardware (not some mythical other device without manufacturer restrictions But the only thing that *actually* matters is what the license text *says*. It doesn't matter what the authors of the license text intended Judges would disagree there - if they intended something else than what they actually wrote in the license text, then they made a mistake, Sure but that's their problem. Nope. That's the problem of anyone who accepted GPL contributions and wants to claim a particular intent of the contributors. You can't say all the people who contributed to Linux in the past support GPLv2 over GPLv3 before GPLv3 is finished and you actually ask them. Many of them may support the way FSF clarified a use case no one cared about before Tivo friends made a legal breakthrough. And what is actually in the license text is obviously what some other people (like Linus for instance) want, so for those people the GPLv2 is a perfectly fine license that doesn't need to be fixed because it says exactely what they want it to say. And for others it's not what they want. Some like Alan will say GPLv2 is the better text, but have a different reading than Linus. Other will take the GPLv3 with all its warts rather than let people interpret the GPLv2 contrary to their wishes. Please do them the courtesy to let them do their mind on their own code. You can talk all you want about the spirit of the license but that will never change the fact that it's the actual text of the license that matters in the end. What matters in the end is the code authors will. If they had the same intent as the FSF, the GPLv2 served them right a long time, but no longer, and they can still relicense their code. In the short term, the understanding a licensee had of the license is as important of the licensor intent should there be a trial, but for anything that was released before DRM was generalised I suspect a judge would not make a literal reading of the license, but try to find out what the licensor intentions were and if the licensee deliberately bypassed them through technicalities. -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
And, as I've taken the time to explain to you, lacking any clear statement, written at the exact same time as the license, a statement of intent or spirit cannot have any real legal weight when the text of a license is finally decided upon. Fortunately the Law recognizes humans are not computers, natural langage is not unambiguous binary code, so statements of intent *have* legal value when a legal text is open to interpretations. That's why ten-line law paragraphs are published with the hundreds of pages of parliamentary discussions on them, which the judge will consider if there's any doubt in his mind. -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[Re-sending with the right subject] by your argument, the user has some right to modify the software, on that piece of hardware it bought which had free software on it, correct? Yes. This means the hardware distributor who put the software in there must not place roadblocks that impede the user to get where she wants with the software, not that the vendor must offer the user a sport car to take her there. Okay. That means that if I ship Linux on a ROM chip I have to somehow make it so that the person purchasing the chip can modify the copy of Linux installed on the chip *if* I want to follow both the spirit and the letter of the GPLv2. The key word there is can You don't have to send the buyer the hardware design, replace the ROM with a flash, use a rom socket that allows easy switching etc. But you can not add measures to your hardware specifically designed to stop the user from modifying the GPL software part. Especially if those measures are something like DRM that do not make the tinkering just technically hard, but legally forbidden. As long as the restrictions result from technical choices not targetted at forbidding changes you're ok. However if the restrictions are deliberately added, have a legal component (and legal is not may but absolute can not), that's another thing entirely. To take a simple example people will understand: - everywhere around the world judges can order newspapers to publish corrections after a slander trial - these corrections take different forms depending on the media: in the original article for on-line stuff, in new editions for printed stuff So the fact there is a legal obligation to allow judges to change articles does not imply newspapers are forced to forgo read-only paper prints. However editors can not refuse to change the online edition because they have the technical possibility to do so. Software change oblications (articles) are not dictating hardware (read-only paper prints) Now do anyone has a doubt how a judge would react if the newspaper told him it wouldn't change the online edition because it's protected by a DRM-like lock the newspaper does not want to change or share? DRM is not a technical limitation like paper print, it's a self-imposed artificial limitation. -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar wrote: * Alexandre Oliva [EMAIL PROTECTED] wrote: Do they have to provide a ROM burner if the ROM is socketed rather than soldered into place? Of course not. They just can't impose restrictions on your obtaining a ROM burner and doing the work yourself. do you realize that you have just admitted that the Tivo is perfectly fine and legal? because you can solder off the ROM from the Tivo and can put in a new ROM with another bootloader that does not check the SHA1 key. Nope. ROM alone is not the problem The problem is that in this particular case, removing a ROM used to vet software makes you liable under DMCA and friends That's why something that could be tolerated in GPLv2 time before the new IP world order can not be tolerated anymore. DRM is not deadly because of the technical measures but the legal ones GPLv3 is not there to change the technical equation but the legal equation. Blame the change on IP law apprentice sorcerers, not the on FSF -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton wrote If DRM was against the license then an extra section clearly explaining that could have been added. (in the DRM case I actually understand the reasoning and agree with it.) Changing licenses is not like changing software code, re-licensing is a major hassle so release early, release often is not a viable strategy. That means GPL v3 is not a nice localised incremental patch but a huge patchset on all the issues that have accumulated since GPLv2 was written (and one can discuss the correctness of parts of this patchset) -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le vendredi 15 juin 2007 à 12:18 -0400, Florin Malita a écrit : On 06/15/2007 10:33 AM, Nicolas Mailhot wrote: Le Ven 15 juin 2007 15:41, Jesper Juhl a écrit : But the only thing that *actually* matters is what the license text *says*. It doesn't matter what the authors of the license text intended Judges would disagree there I very much doubt that, read Jesper's phrase carefully: what may matter is the intent of the *copyrighted work's* author, not the intent of the *license* author. The intent of the latter is (well, should be) completely irrelevant to the case. You're right though I suspect even in the case where the copyrighted work author and the licensing author are not the same, a judge will listen to the licensing author if licensor and licensee disagree on a point (the licensing author being a neutral third-party that presumably knows what's in the licence it wrote). Though in this case license author is nothing more than an expert witness -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Le vendredi 15 juin 2007 à 13:27 -0400, Rob Landley a écrit : Er, yes and no. The GPL evolved from the Emacs License, and _that_ was heavily influenced by Stallman's fight with James Gosling over Gosling revoking permission to use Gosmacs code in GNU Emacs after Gosling sold his codebase to a commercial entity. http://www.free-soft.org/gpl_history/ no and yes :) The second paragraph of this page makes the GNU philosophy the other source of the GPL, and that was definitively influenced by the printer incident -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Since everyone is having fun, and the kernel includes a few bytes from yours truly, I figured I could state my opinion too. 1. Linus' "clarifications" of GPL2-only may apply to the kernel work as a whole, and to patches submitted from the clarification moment, but not to the individual patches submitted before. A lot of noise is made about dead author wishes but nobody seems to care about the wishes of live authors who may not have a hard GPL2-only stance and have been retroactively tagged GPLv2-only supporters. (that's for all the diatribes about the evil FSF unduly speaking for others) 2. Seems there are enough GPLv3 supporters to do the heavy legwork and get clear statements about licensing status of past code submissions should the core kernel hackers agree to GPLv3 licensing. So a licensing change is technically possible Daniel Hazelton wrote: > And this is what the FSF, RMS and yes, *YOU*, Alexandre, fail to realize > - the GPL covers *ONLY* the software. It has *ZERO* legal standing when > applied to hardware. And drm keys are hardware? Nope, they're a string of bytes. Looks like software to me. You're the one who's confusing hardware with software, and trying to apply software legal rules (limited usage rights) to hardware. No law forbids taking hardware you bought and modifying it outside the original manufacturer control (including crazy things like turning cars in boats or planes). In fact many laws especially target attempts to restrict modification to "blessed" original manufacturer parts (I'll intentionaly skip over recent creative lawmaking which confused everyone including the people who rubber-tamped lobby texts) That may suck but while you can technicaly substitute a cheaper software implementation to a hardware one, they are not covered by the same laws. You have a technical continuum but not a legal continuum. Your software substitute is going to be subject to the software legal corpus. That means licensing limits. If you wrote your own code you can use whatever restrictive software license you want. If you didn't you have to abide with the original author licensing, which may be something like the GPLv3 that forbids you to extend software restrictions to hardware (and one is not more amoral than the other) GPLv3 only controls the software part of the equation. You can still manufacture hardware however you want. What you can't do any longer is use software and software exclusive licensing terms to control hardware (Bear in mind even if you sold a device with a physicaly welded hood the law allows the buyer to take a hammer and crack it open. Legal manufacturer control just does not exist past this point. That should tell you who is crossing the lines in the drm case). You may still limit modifications if you don't sell a device but rent it, but many tivo-ing entities around the world want to eat their cake and keep it by selling hardware and using drm to lock it (trying to apply software rules to hardware) If the GPLv3 actually tried to use copyright law to control hardware, it wouldn't stand in court. -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Since everyone is having fun, and the kernel includes a few bytes from yours truly, I figured I could state my opinion too. 1. Linus' clarifications of GPL2-only may apply to the kernel work as a whole, and to patches submitted from the clarification moment, but not to the individual patches submitted before. A lot of noise is made about dead author wishes but nobody seems to care about the wishes of live authors who may not have a hard GPL2-only stance and have been retroactively tagged GPLv2-only supporters. (that's for all the diatribes about the evil FSF unduly speaking for others) 2. Seems there are enough GPLv3 supporters to do the heavy legwork and get clear statements about licensing status of past code submissions should the core kernel hackers agree to GPLv3 licensing. So a licensing change is technically possible Daniel Hazelton wrote: And this is what the FSF, RMS and yes, *YOU*, Alexandre, fail to realize - the GPL covers *ONLY* the software. It has *ZERO* legal standing when applied to hardware. And drm keys are hardware? Nope, they're a string of bytes. Looks like software to me. You're the one who's confusing hardware with software, and trying to apply software legal rules (limited usage rights) to hardware. No law forbids taking hardware you bought and modifying it outside the original manufacturer control (including crazy things like turning cars in boats or planes). In fact many laws especially target attempts to restrict modification to blessed original manufacturer parts (I'll intentionaly skip over recent creative lawmaking which confused everyone including the people who rubber-tamped lobby texts) That may suck but while you can technicaly substitute a cheaper software implementation to a hardware one, they are not covered by the same laws. You have a technical continuum but not a legal continuum. Your software substitute is going to be subject to the software legal corpus. That means licensing limits. If you wrote your own code you can use whatever restrictive software license you want. If you didn't you have to abide with the original author licensing, which may be something like the GPLv3 that forbids you to extend software restrictions to hardware (and one is not more amoral than the other) GPLv3 only controls the software part of the equation. You can still manufacture hardware however you want. What you can't do any longer is use software and software exclusive licensing terms to control hardware (Bear in mind even if you sold a device with a physicaly welded hood the law allows the buyer to take a hammer and crack it open. Legal manufacturer control just does not exist past this point. That should tell you who is crossing the lines in the drm case). You may still limit modifications if you don't sell a device but rent it, but many tivo-ing entities around the world want to eat their cake and keep it by selling hardware and using drm to lock it (trying to apply software rules to hardware) If the GPLv3 actually tried to use copyright law to control hardware, it wouldn't stand in court. -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 8473] New: Oops: 0010 [1] SMP
Le jeudi 17 mai 2007 à 18:59 +0200, Nicolas Mailhot a écrit : > Le jeudi 17 mai 2007 à 09:45 -0700, Randy Dunlap a écrit : > > > Can you boot with "kstack=32" so that we can see more of the stack? > > I can try. It's not triggering quickly though Seems I was completely wrong about the trigger, but anyway it happened again, this time on 2.6.22-rc2.mm1.cfs14 (and I had kept kstack=32) BUG: using smp_processor_id() in preemptible [0001] code: bash/3857 caller is oops_begin+0xb/0x6f Call Trace: [] show_trace+0x34/0x4f [] dump_stack+0x12/0x17 [] debug_smp_processor_id+0xad/0xbc [] oops_begin+0xb/0x6f [] do_page_fault+0x66a/0x7c0 [] error_exit+0x0/0x84 Unable to handle kernel NULL pointer dereference at RIP: [<>] PGD bdd2067 PUD c133067 PMD 0 Oops: 0010 [1] PREEMPT SMP CPU 1 Pid: 3857, comm: bash Not tainted 2.6.22-0.8.rc2.mm1.cfs14.fc8.nim #1 RIP: 0010:[<>] [<>] RSP: 0018:81000cb03ee0 EFLAGS: 00010296 RAX: 8044dbc0 RBX: 81000c3aa8c0 RCX: 7fff549dcae4 RDX: 5410 RSI: 81000c3aa8c0 RDI: 81000ba913d8 RBP: 7fff549dcae4 R08: R09: R10: 0008 R11: 0246 R12: 5410 R13: 00ff R14: 00ff R15: FS: 2b06560d8f40() GS:810004017180() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 0bc55000 CR4: 06e0 Process bash (pid: 3857, threadinfo 81000cb02000, task 81000adc59a0) Stack: 8028ada9 81000c3aa8c0 7fff549dcae4 7fff549dcae4 8028b016 5410 00ff 81000c3aa8c0 7fff549dcae4 5410 00ff 8028b088 80209571 7fff549dce87 0f11 7fff549dcfb8 7fff549dddb0 802095dc 0246 0008 ffda 7fff549dcae4 5410 00ff 0010 003d340c9117 Call Trace: Inexact backtrace: [] do_ioctl+0x55/0x6b [] vfs_ioctl+0x257/0x270 [] sys_ioctl+0x59/0x79 [] tracesys+0xdc/0xe1 INFO: lockdep is turned off. Code: Bad RIP value. RIP [<0000>] RSP CR2: -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8473] New: Oops: 0010 [1] SMP
Le jeudi 17 mai 2007 à 18:59 +0200, Nicolas Mailhot a écrit : Le jeudi 17 mai 2007 à 09:45 -0700, Randy Dunlap a écrit : Can you boot with kstack=32 so that we can see more of the stack? I can try. It's not triggering quickly though Seems I was completely wrong about the trigger, but anyway it happened again, this time on 2.6.22-rc2.mm1.cfs14 (and I had kept kstack=32) BUG: using smp_processor_id() in preemptible [0001] code: bash/3857 caller is oops_begin+0xb/0x6f Call Trace: [8020ab4d] show_trace+0x34/0x4f [8020ab7a] dump_stack+0x12/0x17 [8030d92d] debug_smp_processor_id+0xad/0xbc [8042388f] oops_begin+0xb/0x6f [8042520b] do_page_fault+0x66a/0x7c0 [804234bd] error_exit+0x0/0x84 Unable to handle kernel NULL pointer dereference at RIP: [] PGD bdd2067 PUD c133067 PMD 0 Oops: 0010 [1] PREEMPT SMP CPU 1 Pid: 3857, comm: bash Not tainted 2.6.22-0.8.rc2.mm1.cfs14.fc8.nim #1 RIP: 0010:[] [] RSP: 0018:81000cb03ee0 EFLAGS: 00010296 RAX: 8044dbc0 RBX: 81000c3aa8c0 RCX: 7fff549dcae4 RDX: 5410 RSI: 81000c3aa8c0 RDI: 81000ba913d8 RBP: 7fff549dcae4 R08: R09: R10: 0008 R11: 0246 R12: 5410 R13: 00ff R14: 00ff R15: FS: 2b06560d8f40() GS:810004017180() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 0bc55000 CR4: 06e0 Process bash (pid: 3857, threadinfo 81000cb02000, task 81000adc59a0) Stack: 8028ada9 81000c3aa8c0 7fff549dcae4 7fff549dcae4 8028b016 5410 00ff 81000c3aa8c0 7fff549dcae4 5410 00ff 8028b088 80209571 7fff549dce87 0f11 7fff549dcfb8 7fff549dddb0 802095dc 0246 0008 ffda 7fff549dcae4 5410 00ff 0010 003d340c9117 Call Trace: Inexact backtrace: [8028ada9] do_ioctl+0x55/0x6b [8028b016] vfs_ioctl+0x257/0x270 [8028b088] sys_ioctl+0x59/0x79 [802095dc] tracesys+0xdc/0xe1 INFO: lockdep is turned off. Code: Bad RIP value. RIP [] RSP 81000cb03ee0 CR2: -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
[BUG] USB input death then system freeze
Most recent kernel where this bug did *NOT* occur: pre 2.6.21 mm kernels, non-mm 2.6.22-rc2 Distribution: Fedora Devel Hardware Environment: EHCI input on external powered hub with CK804 mainboard Software Environment: Nothing specific Problem Description: After a few hours of activity 2.6.22-rc1-mm1 and 2.6.22-rc2-mm1 will lose USB HID INPUT (keyboard or mice with no priority), then the system will freeze If the mouse/tackball is lost first switching to the console and moving the ball will output random text. Restarting gpm will rescue the mouse (but the system will lock up soon after anyway) Same system with similar config works fine with mainline or older mm kernels Last trace capture in logs before lockup: Kernel: drivers/hid/usbhid/hid-core.c: input irq status -75 received Xorg: ProcXCloseDevice to close or not ? ProcXCloseDevice to close or not ? (II) nek4k-enhanced-usb-:00:02.1-8.1/input1: Off (II) track-expl-usb-:00:02.1-8.3/input0: Off Steps to reproduce: Just run the system for some time More info there (logs, configs, etc) http://bugzilla.kernel.org/show_bug.cgi?id=8535 -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
[BUG] USB input death then system freeze
Most recent kernel where this bug did *NOT* occur: pre 2.6.21 mm kernels, non-mm 2.6.22-rc2 Distribution: Fedora Devel Hardware Environment: EHCI input on external powered hub with CK804 mainboard Software Environment: Nothing specific Problem Description: After a few hours of activity 2.6.22-rc1-mm1 and 2.6.22-rc2-mm1 will lose USB HID INPUT (keyboard or mice with no priority), then the system will freeze If the mouse/tackball is lost first switching to the console and moving the ball will output random text. Restarting gpm will rescue the mouse (but the system will lock up soon after anyway) Same system with similar config works fine with mainline or older mm kernels Last trace capture in logs before lockup: Kernel: drivers/hid/usbhid/hid-core.c: input irq status -75 received Xorg: ProcXCloseDevice to close or not ? ProcXCloseDevice to close or not ? (II) nek4k-enhanced-usb-:00:02.1-8.1/input1: Off (II) track-expl-usb-:00:02.1-8.3/input0: Off Steps to reproduce: Just run the system for some time More info there (logs, configs, etc) http://bugzilla.kernel.org/show_bug.cgi?id=8535 -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [patch] CFS scheduler, -v14
Le mercredi 23 mai 2007 à 21:57 +0200, Ingo Molnar a écrit : > * Nicolas Mailhot <[EMAIL PROTECTED]> wrote: > > > Ingo Molnar elte.hu> writes: > > > > Hi Ingo > > > > > i'm pleased to announce release -v14 of the CFS scheduler patchset. > > > > > > The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be > > > downloaded from the usual place: > > > > > > http://people.redhat.com/mingo/cfs-scheduler/ > > > > I get a forbidden access on > > http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22-rc2-mm1-v14.patch > > oops - fixed it. Works now, thanks! -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [patch] CFS scheduler, -v14
Ingo Molnar elte.hu> writes: Hi Ingo > i'm pleased to announce release -v14 of the CFS scheduler patchset. > > The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be > downloaded from the usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ I get a forbidden access on http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22-rc2-mm1-v14.patch Regards, -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v14
Ingo Molnar mingo at elte.hu writes: Hi Ingo i'm pleased to announce release -v14 of the CFS scheduler patchset. The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ I get a forbidden access on http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22-rc2-mm1-v14.patch Regards, -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v14
Le mercredi 23 mai 2007 à 21:57 +0200, Ingo Molnar a écrit : * Nicolas Mailhot [EMAIL PROTECTED] wrote: Ingo Molnar mingo at elte.hu writes: Hi Ingo i'm pleased to announce release -v14 of the CFS scheduler patchset. The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ I get a forbidden access on http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22-rc2-mm1-v14.patch oops - fixed it. Works now, thanks! -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8473] New: Oops: 0010 [1] SMP
Le jeudi 17 mai 2007 à 09:45 -0700, Randy Dunlap a écrit : > On Thu, 17 May 2007 12:00:02 +0200 Nicolas Mailhot wrote: > > > Le lundi 14 mai 2007 à 01:25 +0200, Nicolas Mailhot a écrit : > > > > > It happened once so far. The load was moderate (and certainly not > > > comparable to what I did for Mel yesterday) > > > > Make that twice. The interesting thing is it was preceded by CD/DVD > > access just before, to something is rotten there. > > > > 10:52:35 ISO 9660 Extensions: RRIP_1991A > > 11:52:36 Unable to handle kernel NULL pointer dereference at > > RIP: > > 11:52:36 [<>] > > 11:52:36 PGD 2438a067 PUD c484067 PMD 0 > > 11:52:36 Oops: 0010 [1] SMP > > 11:52:36 CPU 1 > > 11:52:36 Pid: 30655, comm: bash Not tainted 2.6.21-11.mm2.fc7.nim #1 > > so just what is this kernel? A hybrid of -mm and -fc7 or what? -mm + md-improve-partition-detection-in-md-array.patch revert + Mel's patches for bug #8464 + the fedora nouveau patch the fc7.nim is there because it was build in an F7 buildroot, not because it carries the full Fedora patchset > Can you boot with "kstack=32" so that we can see more of the stack? I can try. It's not triggering quickly though -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8473] New: Oops: 0010 [1] SMP
Le lundi 14 mai 2007 à 01:25 +0200, Nicolas Mailhot a écrit : > It happened once so far. The load was moderate (and certainly not > comparable to what I did for Mel yesterday) Make that twice. The interesting thing is it was preceded by CD/DVD access just before, to something is rotten there. 10:52:35 ISO 9660 Extensions: RRIP_1991A 11:52:36 Unable to handle kernel NULL pointer dereference at RIP: 11:52:36 [<>] 11:52:36 PGD 2438a067 PUD c484067 PMD 0 11:52:36 Oops: 0010 [1] SMP 11:52:36 CPU 1 11:52:36 Pid: 30655, comm: bash Not tainted 2.6.21-11.mm2.fc7.nim #1 11:52:36 RIP: 0010:[<>] [<>] 11:52:36 RSP: :810006199ee0 EFLAGS: 00010296 11:52:36 RAX: 804426a0 RBX: 81000903f800 RCX: 7fff8a5e9874 11:52:36 RDX: 5410 RSI: 81000903f800 RDI: 810006a37b88 11:52:36 RBP: 7fff8a5e9874 R08: R09: 0004 11:52:36 R10: 0008 R11: 0246 R12: 5410 11:52:36 R13: 00ff R14: 00ff R15: 0008 11:52:36 FS: 2b1c204ccf40() GS:810004017180() knlGS: 11:52:36 CS: 0010 DS: ES: CR0: 8005003b 11:52:36 CR2: CR3: 0f83b000 CR4: 06e0 11:52:36 Process bash (pid: 30655, threadinfo 810006198000, task 810024319c80) 11:52:36 Stack: 80285451 81000903f800 7fff8a5e9874 7fff8a5e9874 11:52:36 802856be 5410 00ff 81000903f800 11:52:36 7fff8a5e9874 5410 00ff 11:52:36 Call Trace: 11:52:36 [] do_ioctl+0x55/0x6b 11:52:36 [] vfs_ioctl+0x257/0x270 11:52:36 [] sys_ioctl+0x59/0x79 11:52:36 [] tracesys+0xdc/0xe1 11:52:36 11:52:36 INFO: lockdep is turned off. 11:52:36 11:52:36 Code: Bad RIP value. 11:52:36 RIP [<>] 11:52:36 RSP 11:52:36 CR2: I'd try rc2-mm1, but I don't know if the patches of Mel Gorman & Christoph Lameter for bug #8464 have been merged yet Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8473] New: Oops: 0010 [1] SMP
Le lundi 14 mai 2007 à 01:25 +0200, Nicolas Mailhot a écrit : It happened once so far. The load was moderate (and certainly not comparable to what I did for Mel yesterday) Make that twice. The interesting thing is it was preceded by CD/DVD access just before, to something is rotten there. 10:52:35 ISO 9660 Extensions: RRIP_1991A 11:52:36 Unable to handle kernel NULL pointer dereference at RIP: 11:52:36 [] 11:52:36 PGD 2438a067 PUD c484067 PMD 0 11:52:36 Oops: 0010 [1] SMP 11:52:36 CPU 1 11:52:36 Pid: 30655, comm: bash Not tainted 2.6.21-11.mm2.fc7.nim #1 11:52:36 RIP: 0010:[] [] 11:52:36 RSP: :810006199ee0 EFLAGS: 00010296 11:52:36 RAX: 804426a0 RBX: 81000903f800 RCX: 7fff8a5e9874 11:52:36 RDX: 5410 RSI: 81000903f800 RDI: 810006a37b88 11:52:36 RBP: 7fff8a5e9874 R08: R09: 0004 11:52:36 R10: 0008 R11: 0246 R12: 5410 11:52:36 R13: 00ff R14: 00ff R15: 0008 11:52:36 FS: 2b1c204ccf40() GS:810004017180() knlGS: 11:52:36 CS: 0010 DS: ES: CR0: 8005003b 11:52:36 CR2: CR3: 0f83b000 CR4: 06e0 11:52:36 Process bash (pid: 30655, threadinfo 810006198000, task 810024319c80) 11:52:36 Stack: 80285451 81000903f800 7fff8a5e9874 7fff8a5e9874 11:52:36 802856be 5410 00ff 81000903f800 11:52:36 7fff8a5e9874 5410 00ff 11:52:36 Call Trace: 11:52:36 [80285451] do_ioctl+0x55/0x6b 11:52:36 [802856be] vfs_ioctl+0x257/0x270 11:52:36 [80285730] sys_ioctl+0x59/0x79 11:52:36 [8020955c] tracesys+0xdc/0xe1 11:52:36 11:52:36 INFO: lockdep is turned off. 11:52:36 11:52:36 Code: Bad RIP value. 11:52:36 RIP [] 11:52:36 RSP 810006199ee0 11:52:36 CR2: I'd try rc2-mm1, but I don't know if the patches of Mel Gorman Christoph Lameter for bug #8464 have been merged yet Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8473] New: Oops: 0010 [1] SMP
Le jeudi 17 mai 2007 à 09:45 -0700, Randy Dunlap a écrit : On Thu, 17 May 2007 12:00:02 +0200 Nicolas Mailhot wrote: Le lundi 14 mai 2007 à 01:25 +0200, Nicolas Mailhot a écrit : It happened once so far. The load was moderate (and certainly not comparable to what I did for Mel yesterday) Make that twice. The interesting thing is it was preceded by CD/DVD access just before, to something is rotten there. 10:52:35 ISO 9660 Extensions: RRIP_1991A 11:52:36 Unable to handle kernel NULL pointer dereference at RIP: 11:52:36 [] 11:52:36 PGD 2438a067 PUD c484067 PMD 0 11:52:36 Oops: 0010 [1] SMP 11:52:36 CPU 1 11:52:36 Pid: 30655, comm: bash Not tainted 2.6.21-11.mm2.fc7.nim #1 so just what is this kernel? A hybrid of -mm and -fc7 or what? -mm + md-improve-partition-detection-in-md-array.patch revert + Mel's patches for bug #8464 + the fedora nouveau patch the fc7.nim is there because it was build in an F7 buildroot, not because it carries the full Fedora patchset Can you boot with kstack=32 so that we can see more of the stack? I can try. It's not triggering quickly though -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8473] New: Oops: 0010 [1] SMP
Le dimanche 13 mai 2007 à 15:47 -0700, Andrew Morton a écrit : > On Sun, 13 May 2007 14:02:50 -0700 [EMAIL PROTECTED] wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=8473 > > Please follow up via emailed reply-to-all. > > In fact, please report -mm bugs via email. bugzilla is more suited to > longer-term problems, and -mm bugs are super-short-term, we hope. Can't attach trace screenshots or long log dumps to mails :( > May 13 22:59:43 rousalka kernel: Unable to handle kernel NULL pointer > dereference at RIP: > May 13 22:59:43 rousalka kernel: [<>] > Anything you can do to make that wordwrapping go away for ever would be > great, thanks. You have the full kernel log with no wrapping there http://bugzilla.kernel.org/attachment.cgi?id=11492 > I don't know what would have caused this. do_ioctl() did a jump-to-zero, > but it has code in there to explicitly test for null pointers. > > Perhaps some weird race, although I find it hard to imagine how we could > have such a race in any ioctl which bash is likely to be calling. > > Is it repeatable at all? It happened once so far. The load was moderate (and certainly not comparable to what I did for Mel yesterday) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le samedi 12 mai 2007 à 20:24 +0100, Mel Gorman a écrit : > On (12/05/07 20:58), Nicolas Mailhot didst pronounce: > > Le samedi 12 mai 2007 à 20:09 +0200, Nicolas Mailhot a écrit : > > > Le samedi 12 mai 2007 à 17:42 +0100, Mel Gorman a écrit : > > > > > > > order-2 (at least 19 pages but more are there) and higher pages were > > > > free > > > > and this was a NORMAL allocation. It should also be above watermarks so > > > > something screwy is happening > > > > > > > > *peers suspiciously* > > > > > > > > Can you try the following patch on top of the kswapd patch please? It is > > > > also available from http://www.csn.ul.ie/~mel/watermarks.patch > > And this one failed testing too > > And same thing, you have suitable free memory. The last patch was > wrong because I forgot the !in_interrupt() part which was careless > and dumb. Please try the following, again on top of the kswapd patch - > http://www.csn.ul.ie/~mel/watermarks-v2.patch This one survived 12h of testing so far. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le samedi 12 mai 2007 à 20:24 +0100, Mel Gorman a écrit : On (12/05/07 20:58), Nicolas Mailhot didst pronounce: Le samedi 12 mai 2007 à 20:09 +0200, Nicolas Mailhot a écrit : Le samedi 12 mai 2007 à 17:42 +0100, Mel Gorman a écrit : order-2 (at least 19 pages but more are there) and higher pages were free and this was a NORMAL allocation. It should also be above watermarks so something screwy is happening *peers suspiciously* Can you try the following patch on top of the kswapd patch please? It is also available from http://www.csn.ul.ie/~mel/watermarks.patch And this one failed testing too And same thing, you have suitable free memory. The last patch was wrong because I forgot the !in_interrupt() part which was careless and dumb. Please try the following, again on top of the kswapd patch - http://www.csn.ul.ie/~mel/watermarks-v2.patch This one survived 12h of testing so far. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8473] New: Oops: 0010 [1] SMP
Le dimanche 13 mai 2007 à 15:47 -0700, Andrew Morton a écrit : On Sun, 13 May 2007 14:02:50 -0700 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8473 Please follow up via emailed reply-to-all. In fact, please report -mm bugs via email. bugzilla is more suited to longer-term problems, and -mm bugs are super-short-term, we hope. Can't attach trace screenshots or long log dumps to mails :( May 13 22:59:43 rousalka kernel: Unable to handle kernel NULL pointer dereference at RIP: May 13 22:59:43 rousalka kernel: [] Anything you can do to make that wordwrapping go away for ever would be great, thanks. You have the full kernel log with no wrapping there http://bugzilla.kernel.org/attachment.cgi?id=11492 I don't know what would have caused this. do_ioctl() did a jump-to-zero, but it has code in there to explicitly test for null pointers. Perhaps some weird race, although I find it hard to imagine how we could have such a race in any ioctl which bash is likely to be calling. Is it repeatable at all? It happened once so far. The load was moderate (and certainly not comparable to what I did for Mel yesterday) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le samedi 12 mai 2007 à 17:42 +0100, Mel Gorman a écrit : > order-2 (at least 19 pages but more are there) and higher pages were free > and this was a NORMAL allocation. It should also be above watermarks so > something screwy is happening > > *peers suspiciously* > > Can you try the following patch on top of the kswapd patch please? It is > also available from http://www.csn.ul.ie/~mel/watermarks.patch Ok, testing now -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le samedi 12 mai 2007 à 17:42 +0100, Mel Gorman a écrit : order-2 (at least 19 pages but more are there) and higher pages were free and this was a NORMAL allocation. It should also be above watermarks so something screwy is happening *peers suspiciously* Can you try the following patch on top of the kswapd patch please? It is also available from http://www.csn.ul.ie/~mel/watermarks.patch Ok, testing now -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le vendredi 11 mai 2007 à 19:45 +0200, Nicolas Mailhot a écrit : > Le vendredi 11 mai 2007 à 18:38 +0100, Mel Gorman a écrit : > > so I'd like to look at the > > alternative option with kswapd as well. Could you put that patch back in > > again > > please and try the following patch instead? > > I'll try this one now (if it applies) Well it doesn't seem to apply. Are you sure you have a clean tree? (I have vanilla mm2 + revert of md-improve-partition-detection-in-md-array.patch for another bug) + umask 022 + cd /builddir/build/BUILD + LANG=C + export LANG + unset DISPLAY + cd /builddir/build/BUILD + rm -rf linux-2.6.21 + /usr/bin/bzip2 -dc /builddir/build/SOURCES/linux-2.6.21.tar.bz2 + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd linux-2.6.21 ++ /usr/bin/id -u + '[' 499 = 0 ']' ++ /usr/bin/id -u + '[' 499 = 0 ']' + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #2 (2.6.21-mm2.bz2):' Patch #2 (2.6.21-mm2.bz2): + /usr/bin/bzip2 -d + patch -p1 -s + STATUS=0 + '[' 0 -ne 0 ']' + echo 'Patch #3 (md-improve-partition-detection-in-md-array.patch):' Patch #3 (md-improve-partition-detection-in-md-array.patch): + patch -p1 -R -s + echo 'Patch #4 (bug-8464.patch):' Patch #4 (bug-8464.patch): + patch -p1 -s 1 out of 1 hunk FAILED -- saving rejects to file mm/slub.c.rej 2 out of 3 hunks FAILED -- saving rejects to file mm/vmscan.c.r -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le vendredi 11 mai 2007 à 18:38 +0100, Mel Gorman a écrit : > On (11/05/07 13:51), Nicolas Mailhot didst pronounce: > > Le vendredi 11 mai 2007 à 10:08 +0100, Mel Gorman a écrit : > > > > > > seems to have cured the system so far (need to charge it a bit longer to > > > > be sure) > > > > > > > > > > The longer it runs the better, particularly under load and after > > > updatedb has run. Thanks a lot for testing > > > > After a few hours of load testing still nothing in the logs, so the > > revert was probably the right thing to do > > Excellent. I am somewhat suprised by the result And you're probably right, it just banged after a day working fine 19:20:00 tar: page allocation failure. order:2, mode:0x84020 19:20:00 19:20:00 Call Trace: 19:20:00 [] __alloc_pages+0x2aa/0x2c3 19:20:00 [] __slab_alloc+0x196/0x586 19:20:00 [] radix_tree_node_alloc+0x36/0x7e 19:20:00 [] kmem_cache_alloc+0x32/0x4e 19:20:00 [] radix_tree_node_alloc+0x36/0x7e 19:20:00 [] radix_tree_insert+0x5d/0x18c 19:20:00 [] add_to_page_cache+0x3d/0x95 19:20:00 [] generic_file_buffered_write+0x222/0x7c8 19:20:00 [] :jbd:do_get_write_access+0x506/0x53d 19:20:00 [] current_fs_time+0x3b/0x40 19:20:00 [] __generic_file_aio_write_nolock+0x342/0x3ac 19:20:00 [] __mutex_lock_slowpath+0x216/0x221 19:20:00 [] generic_file_aio_write+0x61/0xc1 19:20:00 [] :ext3:ext3_file_write+0x16/0x94 19:20:00 [] do_sync_write+0xc9/0x10c 19:20:00 [] autoremove_wake_function+0x0/0x2e 19:20:00 [] vfs_write+0xce/0x177 19:20:00 [] sys_write+0x45/0x6e 19:20:00 [] tracesys+0xdc/0xe1 19:20:00 19:20:00 Mem-info: 19:20:00 DMA per-cpu: 19:20:00 CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 19:20:00 CPU1: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 19:20:00 DMA32 per-cpu: 19:20:00 CPU0: Hot: hi: 186, btch: 31 usd: 149 Cold: hi: 62, btch: 15 usd: 19 19:20:00 CPU1: Hot: hi: 186, btch: 31 usd: 147 Cold: hi: 62, btch: 15 usd: 2 19:20:00 Active:348968 inactive:105561 dirty:23054 writeback:0 unstable:0 19:20:00 free:9776 slab:28092 mapped:23015 pagetables:10226 bounce:0 19:20:00 DMA free:7960kB min:20kB low:24kB high:28kB active:0kB inactive:0kB present:7648kB pages_scanned:0 all_unreclaimable? yes 19:20:00 lowmem_reserve[]: 0 1988 1988 1988 19:20:00 DMA32 free:31144kB min:5692kB low:7112kB high:8536kB active:1395872kB inactive:422244kB present:2036004kB pages_scanned:0 all_unreclaimable? no 19:20:00 lowmem_reserve[]: 0 0 0 0 19:20:00 DMA: 6*4kB 6*8kB 7*16kB 3*32kB 8*64kB 8*128kB 6*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 7960kB 19:20:00 DMA32: 7560*4kB 0*8kB 8*16kB 0*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 31072kB 19:20:00 Swap cache: add 1527, delete 1521, find 216/286, race 397+0 19:20:00 Free swap = 4192824kB 19:20:00 Total swap = 4192944kB 19:20:00 Free swap: 4192824kB 19:20:00 524272 pages of RAM 19:20:00 14123 reserved pages 19:20:00 252562 pages shared 19:20:00 6 pages swap cached > so I'd like to look at the > alternative option with kswapd as well. Could you put that patch back in again > please and try the following patch instead? I'll try this one now (if it applies) Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le vendredi 11 mai 2007 à 10:08 +0100, Mel Gorman a écrit : > > seems to have cured the system so far (need to charge it a bit longer to > > be sure) > > > > The longer it runs the better, particularly under load and after > updatedb has run. Thanks a lot for testing After a few hours of load testing still nothing in the logs, so the revert was probably the right thing to do -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le vendredi 11 mai 2007 à 10:08 +0100, Mel Gorman a écrit : seems to have cured the system so far (need to charge it a bit longer to be sure) The longer it runs the better, particularly under load and after updatedb has run. Thanks a lot for testing After a few hours of load testing still nothing in the logs, so the revert was probably the right thing to do -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le vendredi 11 mai 2007 à 18:38 +0100, Mel Gorman a écrit : On (11/05/07 13:51), Nicolas Mailhot didst pronounce: Le vendredi 11 mai 2007 à 10:08 +0100, Mel Gorman a écrit : seems to have cured the system so far (need to charge it a bit longer to be sure) The longer it runs the better, particularly under load and after updatedb has run. Thanks a lot for testing After a few hours of load testing still nothing in the logs, so the revert was probably the right thing to do Excellent. I am somewhat suprised by the result And you're probably right, it just banged after a day working fine 19:20:00 tar: page allocation failure. order:2, mode:0x84020 19:20:00 19:20:00 Call Trace: 19:20:00 [8025b5c3] __alloc_pages+0x2aa/0x2c3 19:20:00 [802751f5] __slab_alloc+0x196/0x586 19:20:00 [80300d79] radix_tree_node_alloc+0x36/0x7e 19:20:00 [8027597a] kmem_cache_alloc+0x32/0x4e 19:20:00 [80300d79] radix_tree_node_alloc+0x36/0x7e 19:20:00 [8030118e] radix_tree_insert+0x5d/0x18c 19:20:00 [80256ac4] add_to_page_cache+0x3d/0x95 19:20:00 [80257aa4] generic_file_buffered_write+0x222/0x7c8 19:20:00 [88013c74] :jbd:do_get_write_access+0x506/0x53d 19:20:00 [8022c7d5] current_fs_time+0x3b/0x40 19:20:00 [8025838c] __generic_file_aio_write_nolock+0x342/0x3ac 19:20:00 [80416ac1] __mutex_lock_slowpath+0x216/0x221 19:20:00 [80258457] generic_file_aio_write+0x61/0xc1 19:20:00 [880271be] :ext3:ext3_file_write+0x16/0x94 19:20:00 [8027938c] do_sync_write+0xc9/0x10c 19:20:00 [80239c56] autoremove_wake_function+0x0/0x2e 19:20:00 [80279ba7] vfs_write+0xce/0x177 19:20:00 [8027a16a] sys_write+0x45/0x6e 19:20:00 [8020955c] tracesys+0xdc/0xe1 19:20:00 19:20:00 Mem-info: 19:20:00 DMA per-cpu: 19:20:00 CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 19:20:00 CPU1: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 19:20:00 DMA32 per-cpu: 19:20:00 CPU0: Hot: hi: 186, btch: 31 usd: 149 Cold: hi: 62, btch: 15 usd: 19 19:20:00 CPU1: Hot: hi: 186, btch: 31 usd: 147 Cold: hi: 62, btch: 15 usd: 2 19:20:00 Active:348968 inactive:105561 dirty:23054 writeback:0 unstable:0 19:20:00 free:9776 slab:28092 mapped:23015 pagetables:10226 bounce:0 19:20:00 DMA free:7960kB min:20kB low:24kB high:28kB active:0kB inactive:0kB present:7648kB pages_scanned:0 all_unreclaimable? yes 19:20:00 lowmem_reserve[]: 0 1988 1988 1988 19:20:00 DMA32 free:31144kB min:5692kB low:7112kB high:8536kB active:1395872kB inactive:422244kB present:2036004kB pages_scanned:0 all_unreclaimable? no 19:20:00 lowmem_reserve[]: 0 0 0 0 19:20:00 DMA: 6*4kB 6*8kB 7*16kB 3*32kB 8*64kB 8*128kB 6*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 7960kB 19:20:00 DMA32: 7560*4kB 0*8kB 8*16kB 0*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 31072kB 19:20:00 Swap cache: add 1527, delete 1521, find 216/286, race 397+0 19:20:00 Free swap = 4192824kB 19:20:00 Total swap = 4192944kB 19:20:00 Free swap: 4192824kB 19:20:00 524272 pages of RAM 19:20:00 14123 reserved pages 19:20:00 252562 pages shared 19:20:00 6 pages swap cached so I'd like to look at the alternative option with kswapd as well. Could you put that patch back in again please and try the following patch instead? I'll try this one now (if it applies) Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le vendredi 11 mai 2007 à 19:45 +0200, Nicolas Mailhot a écrit : Le vendredi 11 mai 2007 à 18:38 +0100, Mel Gorman a écrit : so I'd like to look at the alternative option with kswapd as well. Could you put that patch back in again please and try the following patch instead? I'll try this one now (if it applies) Well it doesn't seem to apply. Are you sure you have a clean tree? (I have vanilla mm2 + revert of md-improve-partition-detection-in-md-array.patch for another bug) + umask 022 + cd /builddir/build/BUILD + LANG=C + export LANG + unset DISPLAY + cd /builddir/build/BUILD + rm -rf linux-2.6.21 + /usr/bin/bzip2 -dc /builddir/build/SOURCES/linux-2.6.21.tar.bz2 + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd linux-2.6.21 ++ /usr/bin/id -u + '[' 499 = 0 ']' ++ /usr/bin/id -u + '[' 499 = 0 ']' + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #2 (2.6.21-mm2.bz2):' Patch #2 (2.6.21-mm2.bz2): + /usr/bin/bzip2 -d + patch -p1 -s + STATUS=0 + '[' 0 -ne 0 ']' + echo 'Patch #3 (md-improve-partition-detection-in-md-array.patch):' Patch #3 (md-improve-partition-detection-in-md-array.patch): + patch -p1 -R -s + echo 'Patch #4 (bug-8464.patch):' Patch #4 (bug-8464.patch): + patch -p1 -s 1 out of 1 hunk FAILED -- saving rejects to file mm/slub.c.rej 2 out of 3 hunks FAILED -- saving rejects to file mm/vmscan.c.r -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le jeudi 10 mai 2007 à 16:01 -0700, Christoph Lameter a écrit : > On Fri, 11 May 2007, Mel Gorman wrote: > > > Nicholas, could you backout the patch > > dont-group-high-order-atomic-allocations.patch and test again please? > > The following patch has the same effect. Thanks > > Great! Thanks. The proposed patch did not apply + cd /builddir/build/BUILD + rm -rf linux-2.6.21 + /usr/bin/bzip2 -dc /builddir/build/SOURCES/linux-2.6.21.tar.bz2 + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd linux-2.6.21 ++ /usr/bin/id -u + '[' 499 = 0 ']' ++ /usr/bin/id -u + '[' 499 = 0 ']' + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #2 (2.6.21-mm2.bz2):' Patch #2 (2.6.21-mm2.bz2): + /usr/bin/bzip2 -d + patch -p1 -s + STATUS=0 + '[' 0 -ne 0 ']' + echo 'Patch #3 (md-improve-partition-detection-in-md-array.patch):' Patch #3 (md-improve-partition-detection-in-md-array.patch): + patch -p1 -R -s + echo 'Patch #4 (bug-8464.patch):' Patch #4 (bug-8464.patch): + patch -p1 -s 1 out of 1 hunk FAILED -- saving rejects to file include/linux/pageblock-flags.h .rej 6 out of 6 hunks FAILED -- saving rejects to file mm/page_alloc.c.rej Backing out dont-group-high-order-atomic-allocations.patch worked and seems to have cured the system so far (need to charge it a bit longer to be sure) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8464] New: autoreconf: page allocation failure. order:2, mode:0x84020
Le jeudi 10 mai 2007 à 16:01 -0700, Christoph Lameter a écrit : On Fri, 11 May 2007, Mel Gorman wrote: Nicholas, could you backout the patch dont-group-high-order-atomic-allocations.patch and test again please? The following patch has the same effect. Thanks Great! Thanks. The proposed patch did not apply + cd /builddir/build/BUILD + rm -rf linux-2.6.21 + /usr/bin/bzip2 -dc /builddir/build/SOURCES/linux-2.6.21.tar.bz2 + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd linux-2.6.21 ++ /usr/bin/id -u + '[' 499 = 0 ']' ++ /usr/bin/id -u + '[' 499 = 0 ']' + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #2 (2.6.21-mm2.bz2):' Patch #2 (2.6.21-mm2.bz2): + /usr/bin/bzip2 -d + patch -p1 -s + STATUS=0 + '[' 0 -ne 0 ']' + echo 'Patch #3 (md-improve-partition-detection-in-md-array.patch):' Patch #3 (md-improve-partition-detection-in-md-array.patch): + patch -p1 -R -s + echo 'Patch #4 (bug-8464.patch):' Patch #4 (bug-8464.patch): + patch -p1 -s 1 out of 1 hunk FAILED -- saving rejects to file include/linux/pageblock-flags.h .rej 6 out of 6 hunks FAILED -- saving rejects to file mm/page_alloc.c.rej Backing out dont-group-high-order-atomic-allocations.patch worked and seems to have cured the system so far (need to charge it a bit longer to be sure) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [PATCH] x86-64 highres/dyntick support
Le lundi 07 mai 2007 à 17:28 +0200, Thomas Gleixner a écrit : > On Mon, 2007-05-07 at 09:16 +0000, Nicolas Mailhot wrote: > > Thomas Gleixner linutronix.de> writes: > > > > > > > > I'm pleased to announce the first cut of the final x86_64 > > > highres/dyntick support, which I did based on Chris Wright's patch set, > > > which is again based on Arjan van de Ven's initial work: > > > > Do you have a 2.6.21-mm1 patchset? > > Not yet, but it should be halfways easy to do one. Stay tuned. Ok, tuning now Thanks -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support
Le lundi 07 mai 2007 à 17:28 +0200, Thomas Gleixner a écrit : On Mon, 2007-05-07 at 09:16 +, Nicolas Mailhot wrote: Thomas Gleixner tglx at linutronix.de writes: I'm pleased to announce the first cut of the final x86_64 highres/dyntick support, which I did based on Chris Wright's patch set, which is again based on Arjan van de Ven's initial work: Do you have a 2.6.21-mm1 patchset? Not yet, but it should be halfways easy to do one. Stay tuned. Ok, tuning now Thanks -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v9
Ingo Molnar elte.hu> writes: > i'm pleased to announce release -v9 of the CFS scheduler patchset. (The > main goal of CFS is to implement "desktop scheduling" with as high > quality as technically possible.) Now that Andrew decided to kick scheduler patches out of -mm, can we have for-mm cfs and sd patchsets pretty please? Regards, -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support
Thomas Gleixner linutronix.de> writes: > > I'm pleased to announce the first cut of the final x86_64 > highres/dyntick support, which I did based on Chris Wright's patch set, > which is again based on Arjan van de Ven's initial work: Do you have a 2.6.21-mm1 patchset? Regards, -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support
Thomas Gleixner tglx at linutronix.de writes: I'm pleased to announce the first cut of the final x86_64 highres/dyntick support, which I did based on Chris Wright's patch set, which is again based on Arjan van de Ven's initial work: Do you have a 2.6.21-mm1 patchset? Regards, -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v9
Ingo Molnar mingo at elte.hu writes: i'm pleased to announce release -v9 of the CFS scheduler patchset. (The main goal of CFS is to implement desktop scheduling with as high quality as technically possible.) Now that Andrew decided to kick scheduler patches out of -mm, can we have for-mm cfs and sd patchsets pretty please? Regards, -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
veloper-oriented systems (e-mail) what makes them work are the go-betweens (who happen to do the less sexy and hardest part of the process). They're the ones who mediate between: 1. reporters who just want to report a problem without spending a month learning the habits of the people in charge of the code 2. developers who want gold-plated reports So IMHO: 1. people like Adrian should be the ones choosing the reporting method so it makes *their* job not the reporter or developer ones easier 2. when they bend backwards to send reports in the developer-preferred form (like Adrian did) it's criminal to ignore them like a random e-mail or bugzilla report. The bug may be more work than the technical problem is worth but that's not the point. People like Adrian are not replaceable. When they've invested so much time producing nice reports you have to act on them if only to mark your respect for people doing a thankless but necessary job. -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
spending a month learning the habits of the people in charge of the code 2. developers who want gold-plated reports So IMHO: 1. people like Adrian should be the ones choosing the reporting method so it makes *their* job not the reporter or developer ones easier 2. when they bend backwards to send reports in the developer-preferred form (like Adrian did) it's criminal to ignore them like a random e-mail or bugzilla report. The bug may be more work than the technical problem is worth but that's not the point. People like Adrian are not replaceable. When they've invested so much time producing nice reports you have to act on them if only to mark your respect for people doing a thankless but necessary job. -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OHCI: USB webcam works, but not on USB Hub
Michael Bueker wrote : > I'm using a USB Webcam with the gspca driver (from > http://mxhaard.free.fr/download.html), which has been working fine with the > latest kernels. ... > Now, I'm writing to this list because one of the followups to that post > (http://lists.zerezo.com/spca50x-devs/msg00665.html) states that this is due > to a problem with the Linux USB layer: >> pls file a bug "ohci driver can't handle low+fullspeed devices on the same >> root hub" to linux usb devel list. Do the gspca driver authors even intend to merge their module in mainline anytime soon? This kind of problem if typical of out-of-tree development. -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OHCI: USB webcam works, but not on USB Hub
Michael Bueker wrote : I'm using a USB Webcam with the gspca driver (from http://mxhaard.free.fr/download.html), which has been working fine with the latest kernels. ... Now, I'm writing to this list because one of the followups to that post (http://lists.zerezo.com/spca50x-devs/msg00665.html) states that this is due to a problem with the Linux USB layer: pls file a bug ohci driver can't handle low+fullspeed devices on the same root hub to linux usb devel list. Do the gspca driver authors even intend to merge their module in mainline anytime soon? This kind of problem if typical of out-of-tree development. -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC] HID bus design overview.
> Er, I also want to know what are drawbacks of "flip-flopping" ? This will cause major havoc as soon as hot-plugging and apps listening to HAL events (xorg eventually) enter in play. -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC] HID bus design overview.
Er, I also want to know what are drawbacks of flip-flopping ? This will cause major havoc as soon as hot-plugging and apps listening to HAL events (xorg eventually) enter in play. -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
[adding some people in CC that expressed interest in the problem before] Le samedi 31 mars 2007 à 12:37 +0200, Krzysztof Halasa a écrit : > Nicolas Mailhot <[EMAIL PROTECTED]> writes: > > > Oh, is looks so close to my system > > > > 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) > > 00: de 10 50 00 0f 00 a0 00 a3 00 01 06 00 00 80 00 > > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 11 0c > > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 40: 58 14 11 0c 00 f0 ff fe fa 3e ff 00 fa 3e ff 00 > > ^^^ > > Usual HPET base address > > 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff > > 60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 f9 ff > > 70: 10 00 ff ff c1 00 00 00 00 00 04 19 18 d2 80 0d > > ^^ > > c1 => HPET disabled (according to your reference) > > > > I don't have an HPET toggle in my bios > > For reference: HPET enabled in BIOS, MSI K9N platinum board: > > dmesg | grep HPET > ACPI: HPET (v001 A M I OEMHPET0 0x02000701 MSFT 0x0097) > @ 0x3ffd5480 > ACPI: HPET id: 0x10de8201 base: 0xfed0 > time.c: Using 25.00 MHz WALL HPET GTOD HPET timer. > > 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) > Subsystem: Micro-Star International Co., Ltd. Unknown device 7250 > Flags: bus master, 66MHz, fast devsel, latency 0 > I/O ports at 2f00 [size=128] > 00: de 10 62 03 0f 00 a0 00 a2 00 01 06 00 00 80 00 > 10: 01 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 50 72 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00 > 40: 62 14 50 72 00 00 d0 fe fa 3e ff 00 fa 3e ff 00 > ^^^ > Dword at 0x44 indeed seems to be the address > > 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 fe 3f > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 ff > 70: 10 00 ff ff c5 80 00 00 00 00 45 19 00 c6 40 00 > ^^ > Enabled = consistent with http://lkml.org/lkml/2006/12/17/69 > > 80: 09 20 00 10 1d 08 00 00 f0 00 00 01 f0 00 00 00 > 90: 00 08 00 00 00 00 00 00 21 47 95 86 ef cd ab 00 > a0: 01 00 00 81 00 00 00 00 00 00 00 00 00 00 00 00 > ^^ > Not sure about 0xa3, though. > > b0: 00 00 00 00 00 0a 7f 0a 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 44 00 00 fe fd d3 00 a0 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 Here is the full reference on my system 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) Subsystem: Giga-byte Technology GA-K8N Ultra-9 Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- signature.asc Description: Ceci est une partie de message numériquement signée
Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
[adding some people in CC that expressed interest in the problem before] Le samedi 31 mars 2007 à 12:37 +0200, Krzysztof Halasa a écrit : Nicolas Mailhot [EMAIL PROTECTED] writes: Oh, is looks so close to my system 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) 00: de 10 50 00 0f 00 a0 00 a3 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 11 0c 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 58 14 11 0c 00 f0 ff fe fa 3e ff 00 fa 3e ff 00 ^^^ Usual HPET base address 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff 60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 f9 ff 70: 10 00 ff ff c1 00 00 00 00 00 04 19 18 d2 80 0d ^^ c1 = HPET disabled (according to your reference) I don't have an HPET toggle in my bios For reference: HPET enabled in BIOS, MSI K9N platinum board: dmesg | grep HPET ACPI: HPET (v001 A M I OEMHPET0 0x02000701 MSFT 0x0097) @ 0x3ffd5480 ACPI: HPET id: 0x10de8201 base: 0xfed0 time.c: Using 25.00 MHz WALL HPET GTOD HPET timer. 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) Subsystem: Micro-Star International Co., Ltd. Unknown device 7250 Flags: bus master, 66MHz, fast devsel, latency 0 I/O ports at 2f00 [size=128] 00: de 10 62 03 0f 00 a0 00 a2 00 01 06 00 00 80 00 10: 01 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 50 72 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00 40: 62 14 50 72 00 00 d0 fe fa 3e ff 00 fa 3e ff 00 ^^^ Dword at 0x44 indeed seems to be the address 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 fe 3f 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 ff 70: 10 00 ff ff c5 80 00 00 00 00 45 19 00 c6 40 00 ^^ Enabled = consistent with http://lkml.org/lkml/2006/12/17/69 80: 09 20 00 10 1d 08 00 00 f0 00 00 01 f0 00 00 00 90: 00 08 00 00 00 00 00 00 21 47 95 86 ef cd ab 00 a0: 01 00 00 81 00 00 00 00 00 00 00 00 00 00 00 00 ^^ Not sure about 0xa3, though. b0: 00 00 00 00 00 0a 7f 0a 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 44 00 00 fe fd d3 00 a0 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 Here is the full reference on my system 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) Subsystem: Giga-byte Technology GA-K8N Ultra-9 Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 00: de 10 50 00 0f 00 a0 00 a3 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 11 0c 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 58 14 11 0c 00 f0 ff fe fa 3e ff 00 fa 3e ff 00 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff 60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 f9 ff 70: 10 00 ff ff c1 00 00 00 00 00 04 19 18 d2 80 0d 80: 09 20 00 d8 01 01 00 00 c0 00 00 01 00 00 00 00 90: 00 00 00 00 00 00 00 00 21 64 87 a9 de bc 00 00 a0: 03 00 30 c1 00 00 00 00 00 00 00 00 00 00 00 00 b0: 95 02 f4 02 00 08 5f 08 00 00 00 00 00 00 00 00 c0: 35 82 80 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 14 10 01 00 00 00 d0 00 80 30 00 20 61 44 44 11 f0: 5a ff 5f bf 00 00 00 c0 10 ff ff ff 00 00 30 07 I'm crazy enough to test a patch if someone cooks it, but I'm way out of my depth there :) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
RE: [PATCH 1/5] RT kernel: force detect HPET from PCI space
Le samedi 31 mars 2007 à 01:09 +0300, Mikko Tiihonen a écrit : > > Anyone got the same thing for CK804? I had my hopes high, and then I saw > > the DECLARE_PCI_FIXUP_HEADER values [and the thread title was misleading] > > I have an A8N-E motherboard with AthlonX2 and the ACPI definitions are > missing the HPET (standard feature of Asus motherboards). > > I too got interested to get my motherboard working. Luckily I found this > http://lkml.org/lkml/2006/12/17/69 Oh, is looks so close to my system 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) Subsystem: Giga-byte Technology GA-K8N Ultra-9 Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- HPET disabled (according to your reference) I don't have an HPET toggle in my bios > from which I generated the following patch: I'd love to test it, but what kernel baseline did you use? 2.6.21-rc5-mm2? -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
Le vendredi 30 mars 2007 à 09:59 -0700, Venki Pallipadi a écrit : > On Fri, Mar 30, 2007 at 06:50:19PM +0200, Nicolas Mailhot wrote: > > Anyone got the same thing for CK804? I had my hopes high, and then I saw > > the DECLARE_PCI_FIXUP_HEADER values [and the thread title was > > misleading] > > > > Sorry about the wrong subject. It should have had ICH in the subject > somewhere. I think I'll recover :) > On the brighter side, if you find the chipset document for your chipset, > It should be as easy as this patch to force enable it :-). It's only at the rainbow end, right? -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/5] RT kernel: force detect HPET from PCI space
Anyone got the same thing for CK804? I had my hopes high, and then I saw the DECLARE_PCI_FIXUP_HEADER values [and the thread title was misleading] -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/5] RT kernel: force detect HPET from PCI space
Anyone got the same thing for CK804? I had my hopes high, and then I saw the DECLARE_PCI_FIXUP_HEADER values [and the thread title was misleading] -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
Le vendredi 30 mars 2007 à 09:59 -0700, Venki Pallipadi a écrit : On Fri, Mar 30, 2007 at 06:50:19PM +0200, Nicolas Mailhot wrote: Anyone got the same thing for CK804? I had my hopes high, and then I saw the DECLARE_PCI_FIXUP_HEADER values [and the thread title was misleading] Sorry about the wrong subject. It should have had ICH in the subject somewhere. I think I'll recover :) On the brighter side, if you find the chipset document for your chipset, It should be as easy as this patch to force enable it :-). It's only at the rainbow end, right? -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/5] RT kernel: force detect HPET from PCI space
Le samedi 31 mars 2007 à 01:09 +0300, Mikko Tiihonen a écrit : Anyone got the same thing for CK804? I had my hopes high, and then I saw the DECLARE_PCI_FIXUP_HEADER values [and the thread title was misleading] I have an A8N-E motherboard with AthlonX2 and the ACPI definitions are missing the HPET (standard feature of Asus motherboards). I too got interested to get my motherboard working. Luckily I found this http://lkml.org/lkml/2006/12/17/69 Oh, is looks so close to my system 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) Subsystem: Giga-byte Technology GA-K8N Ultra-9 Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 00: de 10 50 00 0f 00 a0 00 a3 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 11 0c 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 58 14 11 0c 00 f0 ff fe fa 3e ff 00 fa 3e ff 00 ^^^ Usual HPET base address 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff 60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 f9 ff 70: 10 00 ff ff c1 00 00 00 00 00 04 19 18 d2 80 0d ^^ c1 = HPET disabled (according to your reference) I don't have an HPET toggle in my bios from which I generated the following patch: I'd love to test it, but what kernel baseline did you use? 2.6.21-rc5-mm2? -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: 2.6.21-rc4-mm1
Firmware loading is broken for all subsystems, not just network → http://bugzilla.kernel.org/show_bug.cgi?id=8239 -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
Firmware loading is broken for all subsystems, not just network → http://bugzilla.kernel.org/show_bug.cgi?id=8239 -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BIG] Re: sched rsdl fix for 0.28
Le dimanche 11 mars 2007 à 11:07 +1100, Con Kolivas a écrit : > sched rsdl fix Doesn't change a thing. Always breaks at the same place (though depending on hardware timings? the trace is not always the same). Pretty sure nothing happens before this failure -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
[BIG] Re: sched rsdl fix for 0.28
Le dimanche 11 mars 2007 à 11:07 +1100, Con Kolivas a écrit : sched rsdl fix Doesn't change a thing. Always breaks at the same place (though depending on hardware timings? the trace is not always the same). Pretty sure nothing happens before this failure -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [PATCH][RSDL-mm 0/6] Rotating Staircase DeadLine scheduler for -mm
Le dimanche 11 mars 2007 à 01:03 +1100, Con Kolivas a écrit : > On Saturday 10 March 2007 22:49, Nicolas Mailhot wrote: > > Oops > > > > ⇒ http://bugzilla.kernel.org/show_bug.cgi?id=8166 > > Thanks very much. I can't get your config to boot on qemu, but could you > please try this debugging patch? It's not a patch you can really run the > machine with but might find where the problem occurs. Specifically I'm > looking for the warning MISSING STATIC BIT in your case. > > http://ck.kolivas.org/patches/crap/sched-rsdl-0.28-stuff.patch I attached a screenshot of the patched kernel boot -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [PATCH][RSDL-mm 0/6] Rotating Staircase DeadLine scheduler for -mm
Oops ⇒ http://bugzilla.kernel.org/show_bug.cgi?id=8166 -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [PATCH][RSDL-mm 0/6] Rotating Staircase DeadLine scheduler for -mm
Oops ⇒ http://bugzilla.kernel.org/show_bug.cgi?id=8166 -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [PATCH][RSDL-mm 0/6] Rotating Staircase DeadLine scheduler for -mm
Le dimanche 11 mars 2007 à 01:03 +1100, Con Kolivas a écrit : On Saturday 10 March 2007 22:49, Nicolas Mailhot wrote: Oops ⇒ http://bugzilla.kernel.org/show_bug.cgi?id=8166 Thanks very much. I can't get your config to boot on qemu, but could you please try this debugging patch? It's not a patch you can really run the machine with but might find where the problem occurs. Specifically I'm looking for the warning MISSING STATIC BIT in your case. http://ck.kolivas.org/patches/crap/sched-rsdl-0.28-stuff.patch I attached a screenshot of the patched kernel boot -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8136] 2.6.21-rc2-mm2 won't boot
Le mardi 06 mars 2007 à 16:15 -0800, Andrew Morton a écrit : > On Tue, 6 Mar 2007 15:36:29 -0800 > [EMAIL PROTECTED] wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=8136 > So rc2-mm2 panics due to "MP-BIOS bug: 8254 timer not connected to IO-APIC" > and > rc2-mm1 does not. > > Could be ACPI, could be x86_64 timer changes, could be something else. > > Would you have time to bisect it? > > I'd suggest you drill in on the patches between > x86_64-mm-defconfig-update.patch and > optimize-and-simplify-get_cycles_sync.patch: the x86 changes. Removing the x86 patchset (342-430) and utrace (647-663) makes the system boot. (no surprise, but good to confirm). I'll try a few more tests tomorrow, need to sleep now. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [Bug 8136] 2.6.21-rc2-mm2 won't boot
Le mardi 06 mars 2007 à 16:15 -0800, Andrew Morton a écrit : On Tue, 6 Mar 2007 15:36:29 -0800 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8136 So rc2-mm2 panics due to MP-BIOS bug: 8254 timer not connected to IO-APIC and rc2-mm1 does not. Could be ACPI, could be x86_64 timer changes, could be something else. Would you have time to bisect it? I'd suggest you drill in on the patches between x86_64-mm-defconfig-update.patch and optimize-and-simplify-get_cycles_sync.patch: the x86 changes. Removing the x86 patchset (342-430) and utrace (647-663) makes the system boot. (no surprise, but good to confirm). I'll try a few more tests tomorrow, need to sleep now. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
