Re: bcm43xx regression in 2.6.24 (with patch)
On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote: > [1] bcm43xx is unmaintained. Larry used to be the maintainer until > he dropped it a few months ago. Doesn't that mean that Alexey gets to be the maintainer, as he's the one patching it ? Xav -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote: [1] bcm43xx is unmaintained. Larry used to be the maintainer until he dropped it a few months ago. Doesn't that mean that Alexey gets to be the maintainer, as he's the one patching it ? Xav -- 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: currently active Linux kernel versions
On mar, 2008-02-12 at 22:18 +0100, Ferenc Wagner wrote: > Xavier Bestel <[EMAIL PROTECTED]> writes: > > > On mar, 2008-02-12 at 21:27 +0100, Wagner Ferenc wrote: > > > >> which are the "currently active Linux kernel versions" at any point in > >> time? The quote is taken from http://lkml.org/lkml/2008/2/11/29. > >> Or more precisely: which are the "stable" versions I can depend on for > >> a more or less critical server, those that have active security > >> support or receive at least critical bugfixes? I know about the > >> 2.6.2[34].y stable git trees, but I wonder how long will those receive > >> attention (that is, security fixes). Can I find a written policy > >> somewhere? > > > > The answer is at http://kernel.org/ > > Not quite, at least I can't find 2.6.23.y there, even though that > branch seems to be maintained... Ah yes, sorry. Maybe you should monitor ftp://ftp.eu.kernel.org/pub/linux/kernel/v2.6/ then. Xav -- 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: currently active Linux kernel versions
Hi, On mar, 2008-02-12 at 21:27 +0100, Wagner Ferenc wrote: > Hi, > > which are the "currently active Linux kernel versions" at any point in > time? The quote is taken from http://lkml.org/lkml/2008/2/11/29. > Or more precisely: which are the "stable" versions I can depend on for > a more or less critical server, those that have active security > support or receive at least critical bugfixes? I know about the > 2.6.2[34].y stable git trees, but I wonder how long will those receive > attention (that is, security fixes). Can I find a written policy > somewhere? The answer is at http://kernel.org/ You're welcome, Xav -- 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: currently active Linux kernel versions
On mar, 2008-02-12 at 22:18 +0100, Ferenc Wagner wrote: Xavier Bestel [EMAIL PROTECTED] writes: On mar, 2008-02-12 at 21:27 +0100, Wagner Ferenc wrote: which are the currently active Linux kernel versions at any point in time? The quote is taken from http://lkml.org/lkml/2008/2/11/29. Or more precisely: which are the stable versions I can depend on for a more or less critical server, those that have active security support or receive at least critical bugfixes? I know about the 2.6.2[34].y stable git trees, but I wonder how long will those receive attention (that is, security fixes). Can I find a written policy somewhere? The answer is at http://kernel.org/ Not quite, at least I can't find 2.6.23.y there, even though that branch seems to be maintained... Ah yes, sorry. Maybe you should monitor ftp://ftp.eu.kernel.org/pub/linux/kernel/v2.6/ then. Xav -- 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: currently active Linux kernel versions
Hi, On mar, 2008-02-12 at 21:27 +0100, Wagner Ferenc wrote: Hi, which are the currently active Linux kernel versions at any point in time? The quote is taken from http://lkml.org/lkml/2008/2/11/29. Or more precisely: which are the stable versions I can depend on for a more or less critical server, those that have active security support or receive at least critical bugfixes? I know about the 2.6.2[34].y stable git trees, but I wonder how long will those receive attention (that is, security fixes). Can I find a written policy somewhere? The answer is at http://kernel.org/ You're welcome, Xav -- 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: ndiswrapper and GPL-only symbols redux
On Wed, 2008-02-06 at 12:50 +0200, Adrian Bunk wrote: > The Linux kernel is licenced under the GPLv2. > > Ndiswrapper loads and executes code with not GPLv2 compatible > licences > in a way in the kernel that might be considered similar to a GPLv2'ed > userspace program dlopen() a dynamic library file with a not GPLv2 > compatible licence. > > IANAL, but I do think there might be real copyright issues with > ndiswrapper. There are issue as soon as ndiswrapper loads a proprietary NDIS. But a system with just ndiswrapper loaded shouldn't be tainted. Xav -- 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: ndiswrapper and GPL-only symbols redux
On Wed, 2008-02-06 at 12:50 +0200, Adrian Bunk wrote: The Linux kernel is licenced under the GPLv2. Ndiswrapper loads and executes code with not GPLv2 compatible licences in a way in the kernel that might be considered similar to a GPLv2'ed userspace program dlopen() a dynamic library file with a not GPLv2 compatible licence. IANAL, but I do think there might be real copyright issues with ndiswrapper. There are issue as soon as ndiswrapper loads a proprietary NDIS. But a system with just ndiswrapper loaded shouldn't be tainted. Xav -- 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/1] Nikon D80 usb-storage quirk needs modified, new FW
On Tue, 2008-02-05 at 13:43 +0100, Konstantin Kletschke wrote: > Nikon did update their FW for the Nikon D80 and usb-storage got > unusable: [...] > I relized the unusal_devs.h needs to be adapted to > reflect new FW Version, then it works fine again: > > --- linux-2.6.23/drivers/usb/storage/unusual_devs.h_orig2008-02-05 > 13:33:55.010623616 +0100 > +++ linux-2.6.23/drivers/usb/storage/unusual_devs.h 2008-02-05 > 13:32:22.926623601 +0100 > @@ -342,7 +342,7 @@ > US_FL_FIX_CAPACITY), > > /* Reported by Emil Larsson <[EMAIL PROTECTED]> */ > -UNUSUAL_DEV( 0x04b0, 0x0411, 0x0100, 0x0101, > +UNUSUAL_DEV( 0x04b0, 0x0411, 0x0100, 0x0110, > "NIKON", > "NIKON DSC D80", > US_SC_DEVICE, US_PR_DEVICE, NULL, > > > What I wonder is, why are there other examples only reflecting the > newest Firmware, are older ones also catched? Maybe you should leave them both here. Xav -- 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/1] Nikon D80 usb-storage quirk needs modified, new FW
On Tue, 2008-02-05 at 13:43 +0100, Konstantin Kletschke wrote: Nikon did update their FW for the Nikon D80 and usb-storage got unusable: [...] I relized the unusal_devs.h needs to be adapted to reflect new FW Version, then it works fine again: --- linux-2.6.23/drivers/usb/storage/unusual_devs.h_orig2008-02-05 13:33:55.010623616 +0100 +++ linux-2.6.23/drivers/usb/storage/unusual_devs.h 2008-02-05 13:32:22.926623601 +0100 @@ -342,7 +342,7 @@ US_FL_FIX_CAPACITY), /* Reported by Emil Larsson [EMAIL PROTECTED] */ -UNUSUAL_DEV( 0x04b0, 0x0411, 0x0100, 0x0101, +UNUSUAL_DEV( 0x04b0, 0x0411, 0x0100, 0x0110, NIKON, NIKON DSC D80, US_SC_DEVICE, US_PR_DEVICE, NULL, What I wonder is, why are there other examples only reflecting the newest Firmware, are older ones also catched? Maybe you should leave them both here. Xav -- 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: Kernel Development & Objective-C
On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote: > > > Has Objective-C ever been considered for kernel development? > > > > Why not C# instead ? > > Why not Haskell nor Erlang instead ? :-D I heard of a bash compiler. That would enable development time rationalization and maximize the collaborative convergence of a community-oriented synergy. - 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: Kernel Development & Objective-C
On Thu, 2007-11-29 at 12:14 +, Ben Crowhurst wrote: > Has Objective-C ever been considered for kernel development? Why not C# instead ? - 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: Kernel Development Objective-C
On Thu, 2007-11-29 at 12:14 +, Ben Crowhurst wrote: Has Objective-C ever been considered for kernel development? Why not C# instead ? - 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: Kernel Development Objective-C
On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote: Has Objective-C ever been considered for kernel development? Why not C# instead ? Why not Haskell nor Erlang instead ? :-D I heard of a bash compiler. That would enable development time rationalization and maximize the collaborative convergence of a community-oriented synergy. - 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: Relax permissions for reading hard drive serial number?
On Thu, 2007-11-29 at 07:13 -0800, Dan Kegel wrote: > A few years on, Wine has matured to the point where it's > ready to run quite a few apps, even some protected by Safedisc. > One sticking point is that apps like Photoshop and probably > Punkbuster want to retrieve the hard drive's serial number So they can't be installed on a network drive ? Xav - 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: Relax permissions for reading hard drive serial number?
On Thu, 2007-11-29 at 07:13 -0800, Dan Kegel wrote: A few years on, Wine has matured to the point where it's ready to run quite a few apps, even some protected by Safedisc. One sticking point is that apps like Photoshop and probably Punkbuster want to retrieve the hard drive's serial number So they can't be installed on a network drive ? Xav - 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/
How to disable ECC with bootparam ?
Hi, I have replaced my machine with another one which gives many ECC errors. At first sight they may be pessimistic because memtest (with ECC off) doesn't find anything (I'm letting run it overnight, I'll see tomorrow morning if it really didn't find anything). I'd like to let it run without thoses ECC messages (which slow it down pretty much), but - man bootparam doesn't say anything - my git tree is on that machine, so I can't access it - I couldn't successfully google for it Thanks for your help, Xav - 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/
How to disable ECC with bootparam ?
Hi, I have replaced my machine with another one which gives many ECC errors. At first sight they may be pessimistic because memtest (with ECC off) doesn't find anything (I'm letting run it overnight, I'll see tomorrow morning if it really didn't find anything). I'd like to let it run without thoses ECC messages (which slow it down pretty much), but - man bootparam doesn't say anything - my git tree is on that machine, so I can't access it - I couldn't successfully google for it Thanks for your help, Xav - 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: Coding Style: indenting with tabs vs. spaces
Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit : > Hi Benny :) > > * Benny Halevy <[EMAIL PROTECTED]> dixit: > > I would like to hear peoples opinion about the indentation convention > > described below that I personally found the most practical with > > several different editors. > > While I respect you opinion about tabs, I find tab indentation the most > evil thing ever invented. Even if done right (that is, not indenting > using a mixture of spaces and tabs), the only advantage is that you save > a few bytes. Who cares ? The only advantage is that people can make tabs as big (or as small) as they wish. Tabs become "logical indentation". So one's indentation isn't forced on anotherone's editor. Xav - 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: Coding Style: indenting with tabs vs. spaces
Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit : Hi Benny :) * Benny Halevy [EMAIL PROTECTED] dixit: I would like to hear peoples opinion about the indentation convention described below that I personally found the most practical with several different editors. While I respect you opinion about tabs, I find tab indentation the most evil thing ever invented. Even if done right (that is, not indenting using a mixture of spaces and tabs), the only advantage is that you save a few bytes. Who cares ? The only advantage is that people can make tabs as big (or as small) as they wish. Tabs become logical indentation. So one's indentation isn't forced on anotherone's editor. Xav - 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: eradicating out of tree modules
On Tue, 2007-10-30 at 09:11 -0400, linux-os (Dick Johnson) wrote: > I'm sure that the majority of Linux users would never acquire > the 4-board assembly that we use to acquire X-Ray data and > generate real-time images for the baggage scanners in use > at the world's major airports. That assembly, containing > numerous CPUs and other high-speed pipelined stuff would > cost the user about US$100,000 so I'm pretty sure that > are not many takers so it is very unlikely that any modules > to support it would never get into the mainstream kernel. As long as you're maintaining them proprely, I don't why. Xav - 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: eradicating out of tree modules
On Tue, 2007-10-30 at 09:11 -0400, linux-os (Dick Johnson) wrote: I'm sure that the majority of Linux users would never acquire the 4-board assembly that we use to acquire X-Ray data and generate real-time images for the baggage scanners in use at the world's major airports. That assembly, containing numerous CPUs and other high-speed pipelined stuff would cost the user about US$100,000 so I'm pretty sure that are not many takers so it is very unlikely that any modules to support it would never get into the mainstream kernel. As long as you're maintaining them proprely, I don't why. Xav - 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: TODO list for kernel beginer?
On Wed, 2007-10-24 at 15:09 +0200, jan sonnek wrote: > Hello, > where can I find actually TODO list for kernel beginer? > Many Thanks, On http://kernelnewbies.org/ Cheers, Xav - 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: TODO list for kernel beginer?
On Wed, 2007-10-24 at 15:09 +0200, jan sonnek wrote: Hello, where can I find actually TODO list for kernel beginer? Many Thanks, On http://kernelnewbies.org/ Cheers, Xav - 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] Intel Manageability Engine Interface driver
Hi, Le lundi 22 octobre 2007 à 13:22 -0400, Anas Nashif a écrit : > The Manageability Engine Interface (aka HECI) allows applications to > communicate with the Intel(R) Manageability Engine (ME) firmware. > > It is meant to be used by user-space manageability applications to > access ME features such as Intel(R) Active Management Technology, > Intel(R) Quiet System Technology and ASF. Could you briefly explain all these terms ? Thanks, Xav - 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] Intel Manageability Engine Interface driver
Hi, Le lundi 22 octobre 2007 à 13:22 -0400, Anas Nashif a écrit : The Manageability Engine Interface (aka HECI) allows applications to communicate with the Intel(R) Manageability Engine (ME) firmware. It is meant to be used by user-space manageability applications to access ME features such as Intel(R) Active Management Technology, Intel(R) Quiet System Technology and ASF. Could you briefly explain all these terms ? Thanks, Xav - 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: WANTED: kernel projects for CS students
On Mon, 2007-10-15 at 18:36 +0200, Philippe Elie wrote: > > > Increase speed for a build with no updates > > > == > > > On a resonably fast machine with a decent config it takes > > > roughly 10 seconds to do a make where nothing is updated. > > > Generating one single Makefile is assumed to speed up things > > > and will in addition allow a simpler syntax as what is used today > > > for some of the uglier constructs. > > > > > > Contact: Sam Ravnborg <[EMAIL PROTECTED]> > > > Difficulty: 5 > > > Language: Perl or C > > > > Isn't make -j 2 or more implemented by running multiple make in sub-dirs ? > > Parallel make is more and more used even on cheap hardware. > > Errm, I misread what you said, it can be a single Makefile in each sub-dirs make -j works fine with an unique Makefile, if that's the question. Xav - 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: WANTED: kernel projects for CS students
On Mon, 2007-10-15 at 18:36 +0200, Philippe Elie wrote: Increase speed for a build with no updates == On a resonably fast machine with a decent config it takes roughly 10 seconds to do a make where nothing is updated. Generating one single Makefile is assumed to speed up things and will in addition allow a simpler syntax as what is used today for some of the uglier constructs. Contact: Sam Ravnborg [EMAIL PROTECTED] Difficulty: 5 Language: Perl or C Isn't make -j 2 or more implemented by running multiple make in sub-dirs ? Parallel make is more and more used even on cheap hardware. Errm, I misread what you said, it can be a single Makefile in each sub-dirs make -j works fine with an unique Makefile, if that's the question. Xav - 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 for WindowsMobile5 on Linux Kernel
On Tue, 2007-10-09 at 11:32 +0200, Bernd Petrovitsch wrote:
> On Die, 2007-10-09 at 12:20 +0300, Grosjo.net - jom wrote:
> [...]
> > Would it be possible to include the patches (available on www.synce.org)
> > for WindowsMobile5, as most mobile phones are under Window$, and it is
> > very convenient to connect it to the laptop under Linux
>
> do {
>Test them
>review them
>sent them as patches hereover
>handle feedback
> until(accepted)
FWIW, the patch in question is a one-liner:
--- linux-2.6.22-rc3-orig/drivers/net/usb/rndis_host.c 2007-05-25
22:55:14.0 -0400
+++ linux-2.6.22-rc3/drivers/net/usb/rndis_host.c 2007-05-27
17:06:16.0 -0400
@@ -499,8 +499,7 @@
net->hard_header_len += sizeof (struct rndis_data_hdr);
dev->hard_mtu = net->mtu + net->hard_header_len;
- dev->rx_urb_size = dev->hard_mtu + (dev->maxpacket + 1);
- dev->rx_urb_size &= ~(dev->maxpacket - 1);
+ dev->rx_urb_size = (dev->udev->speed == USB_SPEED_FULL) ? 16384 : 8192;
u.init->max_transfer_size = cpu_to_le32(dev->rx_urb_size);
net->change_mtu = NULL;
Xav
-
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 for WindowsMobile5 on Linux Kernel
On Tue, 2007-10-09 at 11:32 +0200, Bernd Petrovitsch wrote:
On Die, 2007-10-09 at 12:20 +0300, Grosjo.net - jom wrote:
[...]
Would it be possible to include the patches (available on www.synce.org)
for WindowsMobile5, as most mobile phones are under Window$, and it is
very convenient to connect it to the laptop under Linux
do {
Test them
review them
sent them as patches hereover
handle feedback
until(accepted)
FWIW, the patch in question is a one-liner:
--- linux-2.6.22-rc3-orig/drivers/net/usb/rndis_host.c 2007-05-25
22:55:14.0 -0400
+++ linux-2.6.22-rc3/drivers/net/usb/rndis_host.c 2007-05-27
17:06:16.0 -0400
@@ -499,8 +499,7 @@
net-hard_header_len += sizeof (struct rndis_data_hdr);
dev-hard_mtu = net-mtu + net-hard_header_len;
- dev-rx_urb_size = dev-hard_mtu + (dev-maxpacket + 1);
- dev-rx_urb_size = ~(dev-maxpacket - 1);
+ dev-rx_urb_size = (dev-udev-speed == USB_SPEED_FULL) ? 16384 : 8192;
u.init-max_transfer_size = cpu_to_le32(dev-rx_urb_size);
net-change_mtu = NULL;
Xav
-
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: Floating Point Issue
On Thu, 2007-09-27 at 12:41 +0100, mahamuni ashish wrote:
> int main()
> {
> float f= 1256.35;
> char ch[4];
>
> printf("\n1. f : %f",f);
> memset(ch,'\0',strlen(ch) );
Can't work. ch[]'s content is undefined, so strlen(ch) may read anywhere
in memory, and/or memset() write anywhere.
Xav
-
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: Floating Point Issue
On Thu, 2007-09-27 at 12:41 +0100, mahamuni ashish wrote:
int main()
{
float f= 1256.35;
char ch[4];
printf(\n1. f : %f,f);
memset(ch,'\0',strlen(ch) );
Can't work. ch[]'s content is undefined, so strlen(ch) may read anywhere
in memory, and/or memset() write anywhere.
Xav
-
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: Wasting our Bandwidth
Le mardi 18 septembre 2007 à 06:29 -0500, Marco Peereboom a écrit : > Now if they'd fix the copyright message to only mention Reyk all would > be good. All this mess so easily solved ? Too good to be true. Xav - 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: Wasting our Bandwidth
Le mardi 18 septembre 2007 à 06:29 -0500, Marco Peereboom a écrit : Now if they'd fix the copyright message to only mention Reyk all would be good. All this mess so easily solved ? Too good to be true. Xav - 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: r8169: can't send magic packet for Wake-On-Lan
On Wed, 2007-09-12 at 23:20 +0200, Francois Romieu wrote: > Xavier Bestel <[EMAIL PROTECTED]> : > [...] > > Err sorry, I mixed up everything ... I'm using *etherwake* to make the > > WOL magic packet, and ethtool to check the interface options. > > Weird. > > Can you capture the traffic from the receiving (live) r8169 whith > both senders and specify the kernel version of the sender/receiver ? Sorry for not following up: the packet arrives correctly to the receiving host when it's running, the problem is that it doesn't wake up. As I have changed the switch at the same time (gigabit upgrade) maybe when the host is powered off the switch doesn't forward the magic packet ? I'll dig the old 10/100 hub and try again. Thanks, Xav - 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: r8169: can't send magic packet for Wake-On-Lan
On Wed, 2007-09-12 at 23:20 +0200, Francois Romieu wrote: Xavier Bestel [EMAIL PROTECTED] : [...] Err sorry, I mixed up everything ... I'm using *etherwake* to make the WOL magic packet, and ethtool to check the interface options. Weird. Can you capture the traffic from the receiving (live) r8169 whith both senders and specify the kernel version of the sender/receiver ? Sorry for not following up: the packet arrives correctly to the receiving host when it's running, the problem is that it doesn't wake up. As I have changed the switch at the same time (gigabit upgrade) maybe when the host is powered off the switch doesn't forward the magic packet ? I'll dig the old 10/100 hub and try again. Thanks, Xav - 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: r8169: can't send magic packet for Wake-On-Lan
Le mardi 11 septembre 2007 à 23:30 +0200, Francois Romieu a écrit : > Xavier Bestel <[EMAIL PROTECTED]> : > [...] > > with the r8169 I can't send a magic packet anymore. I'm using ethtool > > for that, with the previous one (an rtl8139b) it was working very well. > > ethtool -D apparently says it could send the packet ok. > > I see no "-D" option in the sources from the git repository of ethtool. > > Where did you find it ? Err sorry, I mixed up everything ... I'm using *etherwake* to make the WOL magic packet, and ethtool to check the interface options. Xav - 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/
r8169: can't send magic packet for Wake-On-Lan
Hi again, with the r8169 I can't send a magic packet anymore. I'm using ethtool for that, with the previous one (an rtl8139b) it was working very well. ethtool -D apparently says it could send the packet ok. The receiving side hasn't changed (it's an r8169 too), it's setup for wake-on-lan and is soft-powered-off with ACPI as it should (no change in config since a few years). Do I have to set something special on the sending end ? Thanks, Xav - 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: r8169: instant reboot and interface renaming
On Tue, 2007-09-11 at 15:32 +0100, Arjan van de Ven wrote: > this is userspace doing "eth name by MAC address", your new card has a > different MAC address than your old card, the userspace application > tries to bind each name uniquely to an ethX name so it keeps eth0 free > for your old card. > > If you have a RH/Fedora like distribution, you can hack out the mac > address from the /etc/sysconfig/network-scripts/ifcfg-eth0 file Thanks, that was it. For those who are interested, under debian it's /etc/udev/rules.d/z25_persistent-net.rules > > The other problem I have is, as soon as I do > > ifconfig eth3 up > > the machine is rebooting (like if I pressed the reset button). > > Adding "acpi=noirq" to the boot cmdline seems to solve this, but > > I wonder if it's the proper > > solution ? > > it's obviously not the proper solution :) > it's odd though; it could entirely be a bios bug. you may want to file > a bug at bugzilla.kernel.org against the acpi component, and make sure > you include the full dmesg of a boot at least... OK, filed http://bugzilla.kernel.org/show_bug.cgi?id=9007 Thanks, Xav - 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/
r8169: instant reboot and interface renaming
Hi, I just replaced a fast ethernet card with a Realtek 8169 Gigabit ethernet card on an old DELL Poweredge running debian. I upgraded the kernel to 2.6.22 but it didn't solve my problems. At boot, the kernel says: r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded eth0: RTL8169s/8110s at 0xe0848400, 00:1b:2f:2b:b3:b4, IRQ 17 but then eth0 doesn't exist and is renamed to eth3. Does anybody know why, and how to get it back to eth0 ? There's probably a FAQ on this somewhere, but I couldn't find it. The other problem I have is, as soon as I do ifconfig eth3 up the machine is rebooting (like if I pressed the reset button). Adding "acpi=noirq" to the boot cmdline seems to solve this, but I wonder if it's the proper solution ? Thanks for your help, Xav - 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/
r8169: instant reboot and interface renaming
Hi, I just replaced a fast ethernet card with a Realtek 8169 Gigabit ethernet card on an old DELL Poweredge running debian. I upgraded the kernel to 2.6.22 but it didn't solve my problems. At boot, the kernel says: r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded eth0: RTL8169s/8110s at 0xe0848400, 00:1b:2f:2b:b3:b4, IRQ 17 but then eth0 doesn't exist and is renamed to eth3. Does anybody know why, and how to get it back to eth0 ? There's probably a FAQ on this somewhere, but I couldn't find it. The other problem I have is, as soon as I do ifconfig eth3 up the machine is rebooting (like if I pressed the reset button). Adding acpi=noirq to the boot cmdline seems to solve this, but I wonder if it's the proper solution ? Thanks for your help, Xav - 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: r8169: instant reboot and interface renaming
On Tue, 2007-09-11 at 15:32 +0100, Arjan van de Ven wrote: this is userspace doing eth name by MAC address, your new card has a different MAC address than your old card, the userspace application tries to bind each name uniquely to an ethX name so it keeps eth0 free for your old card. If you have a RH/Fedora like distribution, you can hack out the mac address from the /etc/sysconfig/network-scripts/ifcfg-eth0 file Thanks, that was it. For those who are interested, under debian it's /etc/udev/rules.d/z25_persistent-net.rules The other problem I have is, as soon as I do ifconfig eth3 up the machine is rebooting (like if I pressed the reset button). Adding acpi=noirq to the boot cmdline seems to solve this, but I wonder if it's the proper solution ? it's obviously not the proper solution :) it's odd though; it could entirely be a bios bug. you may want to file a bug at bugzilla.kernel.org against the acpi component, and make sure you include the full dmesg of a boot at least... OK, filed http://bugzilla.kernel.org/show_bug.cgi?id=9007 Thanks, Xav - 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/
r8169: can't send magic packet for Wake-On-Lan
Hi again, with the r8169 I can't send a magic packet anymore. I'm using ethtool for that, with the previous one (an rtl8139b) it was working very well. ethtool -D apparently says it could send the packet ok. The receiving side hasn't changed (it's an r8169 too), it's setup for wake-on-lan and is soft-powered-off with ACPI as it should (no change in config since a few years). Do I have to set something special on the sending end ? Thanks, Xav - 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: r8169: can't send magic packet for Wake-On-Lan
Le mardi 11 septembre 2007 à 23:30 +0200, Francois Romieu a écrit : Xavier Bestel [EMAIL PROTECTED] : [...] with the r8169 I can't send a magic packet anymore. I'm using ethtool for that, with the previous one (an rtl8139b) it was working very well. ethtool -D apparently says it could send the packet ok. I see no -D option in the sources from the git repository of ethtool. Where did you find it ? Err sorry, I mixed up everything ... I'm using *etherwake* to make the WOL magic packet, and ethtool to check the interface options. Xav - 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/
[OT] Re: very very strange simultaneous RAID resync on sep 2, 01:06 CEST (+2)
On Mon, 2007-09-03 at 10:06 +0200, Patrick Mau wrote: > My debian installation has a system cronjob that will perform a resync > every first Sunday morning at 1:06 AM: > > [EMAIL PROTECTED] cat /etc/cron.d/mdadm > ... > 6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) - > le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet > > I did not read the manpage, but my guess is that 'quiet' will suppress > the mail notification. Yes, that was it, checkarray leaves traces in the syslog. Now I'm really ashamed I jumped on my mailer before using what's left of my braincells. Could I take it back please ? Thanks, Xav - 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/
forget the noise (Re: very very strange simultaneous RAID resync on sep 2, 01:06 CEST (+2))
On Mon, 2007-09-03 at 09:56 +0200, Xavier Bestel wrote: > In itself, this event is already strange. But what's even stranger is > that another guy had the same resync exactely at the same time That mystery is solved, see /etc/cron.d/mdadm: # By default, run at 01:06 on every Sunday, but do nothing unless the day of # the month is less than or equal to 7. Thus, only run on the first Sunday of # each month. crontab(5) sucks, unfortunately, in this regard; therefore this # hack (see #380425). 6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet Sorry for the noise. Xav - 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/
very very strange simultaneous RAID resync on sep 2, 01:06 CEST (+2)
Hi, I have a server running with RAID5 disks, under debian/stable, kernel 2.6.18-5-686. Yesterday the RAID resync'd for no apparent reason, without even mdamd sending a mail to warn about that: Sep 2 01:06:01 awak kernel: md: syncing RAID array md0 Sep 2 01:06:01 awak kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc. Sep 2 01:06:01 awak kernel: md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for reconstruction. Sep 2 01:06:01 awak kernel: md: using 128k window, over a total of 48064 blocks. Sep 2 01:06:01 awak kernel: md: delaying resync of md1 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 awak kernel: md: delaying resync of md2 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:05 awak kernel: md: md0: sync done. Sep 2 01:06:05 awak kernel: RAID1 conf printout: Sep 2 01:06:05 awak kernel: --- wd:3 rd:3 Sep 2 01:06:05 awak kernel: disk 0, wo:0, o:1, dev:hda1 Sep 2 01:06:05 awak kernel: disk 1, wo:0, o:1, dev:hde1 Sep 2 01:06:05 awak kernel: disk 2, wo:0, o:1, dev:hdc1 Sep 2 01:06:05 awak kernel: md: delaying resync of md2 until md1 has finished resync (they share one or more physical units) Sep 2 01:06:05 awak kernel: md: syncing RAID array md1 Sep 2 01:06:05 awak kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc. Sep 2 01:06:05 awak kernel: md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for reconstruction. Sep 2 01:06:05 awak kernel: md: using 128k window, over a total of 1384 blocks. In itself, this event is already strange. But what's even stranger is that another guy had the same resync exactely at the same time (all times are CEST (+0200)): Sep 2 01:06:01 in22 kernel: md: syncing RAID array md0 Sep 2 01:06:01 in22 kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc. Sep 2 01:06:01 in22 kernel: md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for reconstruction. Sep 2 01:06:01 in22 kernel: md: using 128k window, over a total of 1003904 blocks. Sep 2 01:06:01 in22 kernel: md: delaying resync of md1 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 in22 kernel: md: delaying resync of md2 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 in22 kernel: md: delaying resync of md1 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 in22 kernel: md: delaying resync of md3 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 in22 kernel: md: delaying resync of md1 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 in22 kernel: md: delaying resync of md2 until md3 has finished resync (they share one or more physical units) Sep 2 01:06:39 in22 kernel: md: md0: sync done. Sep 2 01:06:39 in22 kernel: md: delaying resync of md2 until md3 has finished resync (they share one or more physical units) Sep 2 01:06:39 in22 kernel: md: syncing RAID array md1 Sep 2 01:06:39 in22 kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc. Sep 2 01:06:39 in22 kernel: md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for reconstruction. Sep 2 01:06:39 in22 kernel: md: using 128k window, over a total of 7004224 blocks. Sep 2 01:06:39 in22 kernel: md: delaying resync of md3 until md1 has finished resync (they share one or more physical units) Sep 2 01:06:39 in22 kernel: RAID1 conf printout: Sep 2 01:06:39 in22 kernel: --- wd:2 rd:2 Sep 2 01:06:39 in22 kernel: disk 0, wo:0, o:1, dev:hda1 Sep 2 01:06:39 in22 kernel: disk 1, wo:0, o:1, dev:hdb1 (reboot) I'm still gathering informations (no idea what his disks are, etc.), but does anyone have the same problem ? Does anyone know where it can come from (debian trouble, md bug, drive firmware problem, rootkit, ..) and how I can pinpoint that ? Thanks, Xav - 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/
very very strange simultaneous RAID resync on sep 2, 01:06 CEST (+2)
Hi, I have a server running with RAID5 disks, under debian/stable, kernel 2.6.18-5-686. Yesterday the RAID resync'd for no apparent reason, without even mdamd sending a mail to warn about that: Sep 2 01:06:01 awak kernel: md: syncing RAID array md0 Sep 2 01:06:01 awak kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc. Sep 2 01:06:01 awak kernel: md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for reconstruction. Sep 2 01:06:01 awak kernel: md: using 128k window, over a total of 48064 blocks. Sep 2 01:06:01 awak kernel: md: delaying resync of md1 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 awak kernel: md: delaying resync of md2 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:05 awak kernel: md: md0: sync done. Sep 2 01:06:05 awak kernel: RAID1 conf printout: Sep 2 01:06:05 awak kernel: --- wd:3 rd:3 Sep 2 01:06:05 awak kernel: disk 0, wo:0, o:1, dev:hda1 Sep 2 01:06:05 awak kernel: disk 1, wo:0, o:1, dev:hde1 Sep 2 01:06:05 awak kernel: disk 2, wo:0, o:1, dev:hdc1 Sep 2 01:06:05 awak kernel: md: delaying resync of md2 until md1 has finished resync (they share one or more physical units) Sep 2 01:06:05 awak kernel: md: syncing RAID array md1 Sep 2 01:06:05 awak kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc. Sep 2 01:06:05 awak kernel: md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for reconstruction. Sep 2 01:06:05 awak kernel: md: using 128k window, over a total of 1384 blocks. In itself, this event is already strange. But what's even stranger is that another guy had the same resync exactely at the same time (all times are CEST (+0200)): Sep 2 01:06:01 in22 kernel: md: syncing RAID array md0 Sep 2 01:06:01 in22 kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc. Sep 2 01:06:01 in22 kernel: md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for reconstruction. Sep 2 01:06:01 in22 kernel: md: using 128k window, over a total of 1003904 blocks. Sep 2 01:06:01 in22 kernel: md: delaying resync of md1 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 in22 kernel: md: delaying resync of md2 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 in22 kernel: md: delaying resync of md1 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 in22 kernel: md: delaying resync of md3 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 in22 kernel: md: delaying resync of md1 until md0 has finished resync (they share one or more physical units) Sep 2 01:06:01 in22 kernel: md: delaying resync of md2 until md3 has finished resync (they share one or more physical units) Sep 2 01:06:39 in22 kernel: md: md0: sync done. Sep 2 01:06:39 in22 kernel: md: delaying resync of md2 until md3 has finished resync (they share one or more physical units) Sep 2 01:06:39 in22 kernel: md: syncing RAID array md1 Sep 2 01:06:39 in22 kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc. Sep 2 01:06:39 in22 kernel: md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for reconstruction. Sep 2 01:06:39 in22 kernel: md: using 128k window, over a total of 7004224 blocks. Sep 2 01:06:39 in22 kernel: md: delaying resync of md3 until md1 has finished resync (they share one or more physical units) Sep 2 01:06:39 in22 kernel: RAID1 conf printout: Sep 2 01:06:39 in22 kernel: --- wd:2 rd:2 Sep 2 01:06:39 in22 kernel: disk 0, wo:0, o:1, dev:hda1 Sep 2 01:06:39 in22 kernel: disk 1, wo:0, o:1, dev:hdb1 (reboot) I'm still gathering informations (no idea what his disks are, etc.), but does anyone have the same problem ? Does anyone know where it can come from (debian trouble, md bug, drive firmware problem, rootkit, ..) and how I can pinpoint that ? Thanks, Xav - 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/
forget the noise (Re: very very strange simultaneous RAID resync on sep 2, 01:06 CEST (+2))
On Mon, 2007-09-03 at 09:56 +0200, Xavier Bestel wrote: In itself, this event is already strange. But what's even stranger is that another guy had the same resync exactely at the same time That mystery is solved, see /etc/cron.d/mdadm: # By default, run at 01:06 on every Sunday, but do nothing unless the day of # the month is less than or equal to 7. Thus, only run on the first Sunday of # each month. crontab(5) sucks, unfortunately, in this regard; therefore this # hack (see #380425). 6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] [ $(date +\%d) -le 7 ] /usr/share/mdadm/checkarray --cron --all --quiet Sorry for the noise. Xav - 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/
[OT] Re: very very strange simultaneous RAID resync on sep 2, 01:06 CEST (+2)
On Mon, 2007-09-03 at 10:06 +0200, Patrick Mau wrote: My debian installation has a system cronjob that will perform a resync every first Sunday morning at 1:06 AM: [EMAIL PROTECTED] cat /etc/cron.d/mdadm ... 6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] [ $(date +\%d) - le 7 ] /usr/share/mdadm/checkarray --cron --all --quiet I did not read the manpage, but my guess is that 'quiet' will suppress the mail notification. Yes, that was it, checkarray leaves traces in the syslog. Now I'm really ashamed I jumped on my mailer before using what's left of my braincells. Could I take it back please ? Thanks, Xav - 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: speeding up swapoff
On Thu, 2007-08-30 at 16:06 +0200, Helge Hafting wrote: > Xavier Bestel wrote: > > On Thu, 2007-08-30 at 15:55 +0200, Helge Hafting wrote: > > > >> If the swap device is full, then there is no need for random > >> seeks as the swap pages can be read in disk order. > >> > > > > If the swap file is full, you probably have a machine dead into a swap > > storm. > Only if you have enough swap. :-) Yeah, sure. But these days disk space is cheap and I tend to put too big swap partitions, and I always regret it later ... Xav - 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: speeding up swapoff
On Thu, 2007-08-30 at 15:55 +0200, Helge Hafting wrote: > If the swap device is full, then there is no need for random > seeks as the swap pages can be read in disk order. If the swap file is full, you probably have a machine dead into a swap storm. - 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: speeding up swapoff
On Thu, 2007-08-30 at 15:55 +0200, Helge Hafting wrote: If the swap device is full, then there is no need for random seeks as the swap pages can be read in disk order. If the swap file is full, you probably have a machine dead into a swap storm. - 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: speeding up swapoff
On Thu, 2007-08-30 at 16:06 +0200, Helge Hafting wrote: Xavier Bestel wrote: On Thu, 2007-08-30 at 15:55 +0200, Helge Hafting wrote: If the swap device is full, then there is no need for random seeks as the swap pages can be read in disk order. If the swap file is full, you probably have a machine dead into a swap storm. Only if you have enough swap. :-) Yeah, sure. But these days disk space is cheap and I tend to put too big swap partitions, and I always regret it later ... Xav - 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 4/5] Net: ath5k, license is GPLv2
On Wed, 2007-08-29 at 08:35 -0200, Jiri Slaby wrote: > On 8/29/07, Johannes Berg <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-08-28 at 12:00 -0400, Jiri Slaby wrote: > > > > > The files are available only under GPLv2 since now. > > > > Since the BSD people are already getting upset about (for various > > reasons among which seem to be a clear non-understanding) I'd suggest > > changing it to: > > yes, please. Can somebody do it, I'm away from my box. > > > + * Parts of this file were originally licenced under the BSD licence: > > + * > > > * Permission to use, copy, modify, and distribute this software for any > > > * purpose with or without fee is hereby granted, provided that the above > > > * copyright notice and this permission notice appear in all copies. > > > * > > > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL > > WARRANTIES > > > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > > > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > > > * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > > > * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > > > * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > > + * > > + * Further changes to this file since the moment this notice was extended > > + * are now distributed under the terms of the GPL version two as published > > + * by the Free Software Foundation > > > > johannes How about asking for changes to be dual-licenced too ? Xav - 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 4/5] Net: ath5k, license is GPLv2
On Wed, 2007-08-29 at 08:35 -0200, Jiri Slaby wrote: On 8/29/07, Johannes Berg [EMAIL PROTECTED] wrote: On Tue, 2007-08-28 at 12:00 -0400, Jiri Slaby wrote: The files are available only under GPLv2 since now. Since the BSD people are already getting upset about (for various reasons among which seem to be a clear non-understanding) I'd suggest changing it to: yes, please. Can somebody do it, I'm away from my box. + * Parts of this file were originally licenced under the BSD licence: + * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + * + * Further changes to this file since the moment this notice was extended + * are now distributed under the terms of the GPL version two as published + * by the Free Software Foundation yaddaya johannes How about asking for changes to be dual-licenced too ? Xav - 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: CFS review
On Tue, 2007-08-28 at 07:37 +0300, Al Boldi wrote: > start gears like this: > > # gears & gears & gears & > > Then lay them out side by side to see the periodic stallings for > ~10sec. Are you sure they are stalled ? What you may have is simple gears running at a multiple of your screen refresh rate, so they only appear stalled. Plus, as said Linus, you're not really testing the kernel scheduler. gears is really bad benchmark, it should die. Xav - 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: CFS review
On Tue, 2007-08-28 at 07:37 +0300, Al Boldi wrote: start gears like this: # gears gears gears Then lay them out side by side to see the periodic stallings for ~10sec. Are you sure they are stalled ? What you may have is simple gears running at a multiple of your screen refresh rate, so they only appear stalled. Plus, as said Linus, you're not really testing the kernel scheduler. gears is really bad benchmark, it should die. Xav - 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: USB Key light on/off state depending on mount
On Sat, 25 Aug 2007 21:26:09 +0200 (CEST), Guennadi Liakhovetski <[EMAIL PROTECTED]> wrote: > On Fri, 24 Aug 2007, Josh Boyer wrote: > >> On 8/24/07, Casey Dahlin <[EMAIL PROTECTED]> wrote: >> > Most USB keys nowadays have a small LED somewhere inside of them that >> > lights up when they are plugged in. On a windows box, the key is lit > up >> > whenever it is mounted, and as soon as it is unmounted it turns off, >> > giving a handy physical indicator that the key is safe to remove. On >> > linux, the light is simply on whenever the key is plugged in. Windows powers off the USB device on unmount, whereas linus does not. I think the problem may lie in HAL. Xav - 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: USB Key light on/off state depending on mount
On Sat, 25 Aug 2007 21:26:09 +0200 (CEST), Guennadi Liakhovetski [EMAIL PROTECTED] wrote: On Fri, 24 Aug 2007, Josh Boyer wrote: On 8/24/07, Casey Dahlin [EMAIL PROTECTED] wrote: Most USB keys nowadays have a small LED somewhere inside of them that lights up when they are plugged in. On a windows box, the key is lit up whenever it is mounted, and as soon as it is unmounted it turns off, giving a handy physical indicator that the key is safe to remove. On linux, the light is simply on whenever the key is plugged in. Windows powers off the USB device on unmount, whereas linus does not. I think the problem may lie in HAL. Xav - 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: [OT] Re: Thinking outside the box on file systems
On Mon, 2007-08-20 at 09:21 -0700, Randy Dunlap wrote: > so enlighten us. What editor do you use/suggest/push? Corbet ! - 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: [OT] Re: Thinking outside the box on file systems
On Mon, 2007-08-20 at 09:21 -0700, Randy Dunlap wrote: so enlighten us. What editor do you use/suggest/push? Corbet ! - 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: Noatime vs relatime
On Fri, 2007-08-10 at 07:26 -0700, Vlad wrote: > Relatime seems to be wasteful of both IO resources _and_ CPU cycles. > Instead of performing a single IO operation (as atime does), relatime > performs at least three IO operations and three CPU-dependent > operations: > > 1) a read IO operation to find out the old atime > 2) a read IO operation to find out the old ctime > 3) a read IO operation to find out the old mtime > 4) Comparison of "old atime is <= than mtime/ctime" > 5) Find out current time > 6) Comparison of "current time minus old atime is > X" As all [acm]times are stored in the same block (inode), I bet all this is one single IO, plus some insignificant computation (3 comparisons plus reading time is really smaller than one block IO). Xav - 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: Noatime vs relatime
On Fri, 2007-08-10 at 07:26 -0700, Vlad wrote: Relatime seems to be wasteful of both IO resources _and_ CPU cycles. Instead of performing a single IO operation (as atime does), relatime performs at least three IO operations and three CPU-dependent operations: 1) a read IO operation to find out the old atime 2) a read IO operation to find out the old ctime 3) a read IO operation to find out the old mtime 4) Comparison of old atime is = than mtime/ctime 5) Find out current time 6) Comparison of current time minus old atime is X As all [acm]times are stored in the same block (inode), I bet all this is one single IO, plus some insignificant computation (3 comparisons plus reading time is really smaller than one block IO). Xav - 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 Device.
On Thu, 2007-08-09 at 06:39 +0300, jonatan perry wrote: > Hello, > I would like to know who the USB system works under linux, I mean, > I would like to write a kernel module who will create a virtual USB > device, so that the kernel will think that a hardware USB device is > exists, were can I start? Look at the "usb gadgets" subsystem. Xav - 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 Device.
On Thu, 2007-08-09 at 06:39 +0300, jonatan perry wrote: Hello, I would like to know who the USB system works under linux, I mean, I would like to write a kernel module who will create a virtual USB device, so that the kernel will think that a hardware USB device is exists, were can I start? Look at the usb gadgets subsystem. Xav - 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: Is it time for remove (crap) ALSA from kernel tree ?
On Thu, 2007-06-28 at 18:34 +0200, Anton Petrusevich wrote: > > Please always use Reply-to-All on this list -- subscribers here like to > > also get personal copies. > > I am not subscribed to linux-kernel, I am reading it on the web. Then please subscribe just for the time you want to participate to the discussion. Xav - 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: Is it time for remove (crap) ALSA from kernel tree ?
On Thu, 2007-06-28 at 18:34 +0200, Anton Petrusevich wrote: Please always use Reply-to-All on this list -- subscribers here like to also get personal copies. I am not subscribed to linux-kernel, I am reading it on the web. Then please subscribe just for the time you want to participate to the discussion. Xav - 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: NVidia Driver Support - 1680x1050 mode
On Wed, 2007-06-27 at 05:58 -0700, Marc Perkel wrote: > Quite frankly, I don't understand why digital LCD > monitor even have scan rates in the first place. It's > not a CRT that actually has an electron beam. You > would thing that it would have a digital interface > where the computer told the monitor what to draw and > the monitor deals with it. That's it. Information is simply the content of the video RAM, given serially at a certain rate (as the DVI interface is a serial interface with a fixed rate, you can't redraw the display at 60fps above a certain pixel quantity). Xav - 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: NVidia Driver Support - 1680x1050 mode
On Wed, 2007-06-27 at 06:42 -0400, Kyle Moffett wrote: > > If you're using a DVI cable, ensure it is dual-link. > > Uhh, no; 1680x1050 does not require a dual-link DVI port/cable. FWIW single-link DVI can do 1920x1200 - for that the X server uses a "reduced blanking" mode, i.e. the vertical and horizontal retrace intervals (useless for LCD/TFT anyway, there's no beam to move) are shortened. Xav - 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: NVidia Driver Support - 1680x1050 mode
On Wed, 2007-06-27 at 06:42 -0400, Kyle Moffett wrote: If you're using a DVI cable, ensure it is dual-link. Uhh, no; 1680x1050 does not require a dual-link DVI port/cable. FWIW single-link DVI can do 1920x1200 - for that the X server uses a reduced blanking mode, i.e. the vertical and horizontal retrace intervals (useless for LCD/TFT anyway, there's no beam to move) are shortened. Xav - 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: NVidia Driver Support - 1680x1050 mode
On Wed, 2007-06-27 at 05:58 -0700, Marc Perkel wrote: Quite frankly, I don't understand why digital LCD monitor even have scan rates in the first place. It's not a CRT that actually has an electron beam. You would thing that it would have a digital interface where the computer told the monitor what to draw and the monitor deals with it. That's it. Information is simply the content of the video RAM, given serially at a certain rate (as the DVI interface is a serial interface with a fixed rate, you can't redraw the display at 60fps above a certain pixel quantity). Xav - 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: Please release a stable kernel Linux 3.0
On Thu, 2007-06-21 at 23:49 +0200, Zoltán HUBERT wrote: > While some of you dislike > closed source drivers, the choices "we users" face are: > - closed source drivers with closed source OS > - closed source drivers with open source OS > Please consider that we are living in a REAL world, and not > Disney-Land. Strange, I'm currently using this option: - open source drivers with open source OS and I'm sure I'm not living in Disney-Land. Xav - 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: Please release a stable kernel Linux 3.0
On Thu, 2007-06-21 at 23:49 +0200, Zoltán HUBERT wrote: While some of you dislike closed source drivers, the choices we users face are: - closed source drivers with closed source OS - closed source drivers with open source OS Please consider that we are living in a REAL world, and not Disney-Land. Strange, I'm currently using this option: - open source drivers with open source OS and I'm sure I'm not living in Disney-Land. Xav - 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
On Thu, 2007-06-14 at 14:40 +0200, Nicolas Mailhot wrote: > And drm keys are hardware? Nope, they're a string of bytes. Looks like > software to me. Apparently that's the single point of contention. Not yet resolved by the courts, so everybody can brag his own POV. Xav - 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
On Thu, 2007-06-14 at 14:40 +0200, Nicolas Mailhot wrote: And drm keys are hardware? Nope, they're a string of bytes. Looks like software to me. Apparently that's the single point of contention. Not yet resolved by the courts, so everybody can brag his own POV. Xav - 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: A kexec approach to hibernation
On Mon, 2007-06-11 at 11:51 -0400, Jeremy Maitin-Shepard wrote: > Xavier Bestel <[EMAIL PROTECTED]> writes: > > > On Mon, 2007-06-11 at 11:01 -0400, Jeremy Maitin-Shepard wrote: > >> >> You might claim then that the solution is to simply keep the network > >> >> driver quiesced or stopped. But then it is impossible to write the > >> >> image over the network. The way to get around this problem is to write > >> >> the image over the network using a fresh network stack. > >> > >> > Or teach the driver stack about the difference/reset it. Remember that > >> > even if you get a fresh network stack, you'll still be getting packets > >> > for the old stack. Getting a new ip (assuming one is available) won't > >> > stop other connections getting killed, either because we send resets > >> > from the kexec'd kernel, or because they timeout looking for the old > >> > ip. > >> > >> I could be mistaken, but I think that bringing up the network interface > >> with a different IP address would prevent it from reseting existing TCP > >> connections, because it would never receive the packets for those > >> existing connections. > > > That can't work. There are networks where the client must have a fixed > > IP, or must accept the adress given by dhcp in order to talk to > > fileservers. And you still have the same mac adress, which may cause > > problems. > > I wasn't suggesting that using a different IP address would be a general > solution. It might be a solution for a few people. > > In general, I'd imagine that most people would not bring up the network > interface at all, and most of the people that do would bring it up with > the same IP address, causing some existing TCP connections to possibly > be reset. > > I think that causing connections to be reset is, however, far better > than acking packets that are then silently thrown away. If I were helping you coding I'd suggest to only concentrate on having your project work on standard filesystems, and then when it works maybe think about suspending on crypto-over-loop-over-fuse-over-vpn-over-wifi. But talk is cheap so I'm shutting up. Right now. :) Xav - 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: A kexec approach to hibernation
On Mon, 2007-06-11 at 11:01 -0400, Jeremy Maitin-Shepard wrote: > >> You might claim then that the solution is to simply keep the network > >> driver quiesced or stopped. But then it is impossible to write the > >> image over the network. The way to get around this problem is to write > >> the image over the network using a fresh network stack. > > > Or teach the driver stack about the difference/reset it. Remember that > > even if you get a fresh network stack, you'll still be getting packets > > for the old stack. Getting a new ip (assuming one is available) won't > > stop other connections getting killed, either because we send resets > > from the kexec'd kernel, or because they timeout looking for the old > > ip. > > I could be mistaken, but I think that bringing up the network interface > with a different IP address would prevent it from reseting existing TCP > connections, because it would never receive the packets for those > existing connections. That can't work. There are networks where the client must have a fixed IP, or must accept the adress given by dhcp in order to talk to fileservers. And you still have the same mac adress, which may cause problems. Xav - 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 7/8] fdmap v2 - implement sys_socket2
On Fri, 2007-06-08 at 20:30 +0100, Alan Cox wrote: > > To avoid exactly the kind of problem we have now in future: programs > > relying on specific patterns. > > Which you seem to think is a bad thing, yet is actually a very good thing > because it means that crashes are repeatable and problems are debuggable > from end user reports. You can have both. Look at malloc(): when you write your program you can't really guess which address will be returned by a malloc() call, but you know that if you launch it twice and if it has the same input, malloc()'s behavior is repeatable so it's debuggable. Xav - 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 7/8] fdmap v2 - implement sys_socket2
On Fri, 2007-06-08 at 20:30 +0100, Alan Cox wrote: To avoid exactly the kind of problem we have now in future: programs relying on specific patterns. Which you seem to think is a bad thing, yet is actually a very good thing because it means that crashes are repeatable and problems are debuggable from end user reports. You can have both. Look at malloc(): when you write your program you can't really guess which address will be returned by a malloc() call, but you know that if you launch it twice and if it has the same input, malloc()'s behavior is repeatable so it's debuggable. Xav - 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: A kexec approach to hibernation
On Mon, 2007-06-11 at 11:01 -0400, Jeremy Maitin-Shepard wrote: You might claim then that the solution is to simply keep the network driver quiesced or stopped. But then it is impossible to write the image over the network. The way to get around this problem is to write the image over the network using a fresh network stack. Or teach the driver stack about the difference/reset it. Remember that even if you get a fresh network stack, you'll still be getting packets for the old stack. Getting a new ip (assuming one is available) won't stop other connections getting killed, either because we send resets from the kexec'd kernel, or because they timeout looking for the old ip. I could be mistaken, but I think that bringing up the network interface with a different IP address would prevent it from reseting existing TCP connections, because it would never receive the packets for those existing connections. That can't work. There are networks where the client must have a fixed IP, or must accept the adress given by dhcp in order to talk to fileservers. And you still have the same mac adress, which may cause problems. Xav - 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: A kexec approach to hibernation
On Mon, 2007-06-11 at 11:51 -0400, Jeremy Maitin-Shepard wrote: Xavier Bestel [EMAIL PROTECTED] writes: On Mon, 2007-06-11 at 11:01 -0400, Jeremy Maitin-Shepard wrote: You might claim then that the solution is to simply keep the network driver quiesced or stopped. But then it is impossible to write the image over the network. The way to get around this problem is to write the image over the network using a fresh network stack. Or teach the driver stack about the difference/reset it. Remember that even if you get a fresh network stack, you'll still be getting packets for the old stack. Getting a new ip (assuming one is available) won't stop other connections getting killed, either because we send resets from the kexec'd kernel, or because they timeout looking for the old ip. I could be mistaken, but I think that bringing up the network interface with a different IP address would prevent it from reseting existing TCP connections, because it would never receive the packets for those existing connections. That can't work. There are networks where the client must have a fixed IP, or must accept the adress given by dhcp in order to talk to fileservers. And you still have the same mac adress, which may cause problems. I wasn't suggesting that using a different IP address would be a general solution. It might be a solution for a few people. In general, I'd imagine that most people would not bring up the network interface at all, and most of the people that do would bring it up with the same IP address, causing some existing TCP connections to possibly be reset. I think that causing connections to be reset is, however, far better than acking packets that are then silently thrown away. If I were helping you coding I'd suggest to only concentrate on having your project work on standard filesystems, and then when it works maybe think about suspending on crypto-over-loop-over-fuse-over-vpn-over-wifi. But talk is cheap so I'm shutting up. Right now. :) Xav - 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: A kexec approach to hibernation
On Tue, 2007-06-05 at 11:34 +0200, Stefan Seyfried wrote: > On Tue, Jun 05, 2007 at 10:15:41AM +0200, Xavier Bestel wrote: > > FWIW, on my old laptop apm beats any kernel solution hands down in terms > > of speed > > This might be true on 64MB systems. It is surely not true on multi-Gigabyte- > RAM setups. At least not if you actually use that memory for anything > including filesystem cache. > And you simply cannot buy a new machine today that still supports APM suspend > to disk. I don't contest that. I just say that technically, an "external kernel" can suspend/hibernate a laptop very well. Xav - 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: A kexec approach to hibernation
On Tue, 2007-06-05 at 08:36 +1000, Nigel Cunningham wrote: > I spent some time, last I think, seriously considering this approach. > The more I thought about the details, the more I realised that it wasn't > a viable approach. As I said before, it does indeed sound like a dream > at first, but once you get into the details, it becomes more and more of > a nightmare. >From very far, it looks like apm suspend (i.e. an "external" system taking control of the computer for hibernation and resuming). FWIW, on my old laptop apm beats any kernel solution hands down in terms of speed and robustness. Not that this means anything for kexec-suspend. Xav - 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: A kexec approach to hibernation
On Tue, 2007-06-05 at 08:36 +1000, Nigel Cunningham wrote: I spent some time, last I think, seriously considering this approach. The more I thought about the details, the more I realised that it wasn't a viable approach. As I said before, it does indeed sound like a dream at first, but once you get into the details, it becomes more and more of a nightmare. From very far, it looks like apm suspend (i.e. an external system taking control of the computer for hibernation and resuming). FWIW, on my old laptop apm beats any kernel solution hands down in terms of speed and robustness. Not that this means anything for kexec-suspend. Xav - 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: A kexec approach to hibernation
On Tue, 2007-06-05 at 11:34 +0200, Stefan Seyfried wrote: On Tue, Jun 05, 2007 at 10:15:41AM +0200, Xavier Bestel wrote: FWIW, on my old laptop apm beats any kernel solution hands down in terms of speed This might be true on 64MB systems. It is surely not true on multi-Gigabyte- RAM setups. At least not if you actually use that memory for anything including filesystem cache. And you simply cannot buy a new machine today that still supports APM suspend to disk. I don't contest that. I just say that technically, an external kernel can suspend/hibernate a laptop very well. Xav - 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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
Le mercredi 23 mai 2007 à 11:22 -0700, Ian Romanick a écrit : > > I think some people forget that X11 has its own scheduler for graphics > > operations. > > And in the direct-rendering case, this scheduler is not used for OpenGL. > The client-side driver submits rendering commands directly to its > kernel module. It is possible that some kernel modules perform some > sort of scheduling, but none of the open-source drivers implement such a > thing. True, but glxgears isn't a pure DRI app: it calls XNextEvent() each time it refreshes its window (which is quite often). Xav - 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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
On Wed, 2007-05-23 at 07:23 +0200, Michael Gerdau wrote: > For me the huge difference you have for sd to the others increases the > likelyhood the glxgears benchmark does not measure scheduling of graphic > but something else. I think some people forget that X11 has its own scheduler for graphics operations. Xav - 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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
On Wed, 2007-05-23 at 07:23 +0200, Michael Gerdau wrote: For me the huge difference you have for sd to the others increases the likelyhood the glxgears benchmark does not measure scheduling of graphic but something else. I think some people forget that X11 has its own scheduler for graphics operations. Xav - 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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
Le mercredi 23 mai 2007 à 11:22 -0700, Ian Romanick a écrit : I think some people forget that X11 has its own scheduler for graphics operations. And in the direct-rendering case, this scheduler is not used for OpenGL. The client-side driver submits rendering commands directly to its kernel module. It is possible that some kernel modules perform some sort of scheduling, but none of the open-source drivers implement such a thing. True, but glxgears isn't a pure DRI app: it calls XNextEvent() each time it refreshes its window (which is quite often). Xav - 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: [RFC] enhancing the kernel's graphics subsystem
On Mon, 2007-05-21 at 17:27 +0100, Dave Airlie wrote: > > What about modifying the existing fbdev API? You could start with > one > > fbdev device per CRTC and then add a new IOCTL to control the output > > device. I haven't seen anything yet that justifies abandoning the > > existing fbdev API. > > Then you can't aribtrate properly output hooking is a root level > thing, you cannot allow the user in multiseat to just pick his own > outputs, if you claim to want a truly flexible interfaces, also the > crtc->output mappings aren't always simple, there are limitations on > most hw about which crtc can map to which output and when you can > clone etc.. putting policy for this stuff in-kernel would heavily > restrict what the user can do... Policy for this kind of thing should just go in HAL's ConsoleKit: http://lists.freedesktop.org/archives/hal/2007-January/007111.html Xav - 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: [RFC] enhancing the kernel's graphics subsystem
On Mon, 2007-05-21 at 17:27 +0100, Dave Airlie wrote: What about modifying the existing fbdev API? You could start with one fbdev device per CRTC and then add a new IOCTL to control the output device. I haven't seen anything yet that justifies abandoning the existing fbdev API. Then you can't aribtrate properly output hooking is a root level thing, you cannot allow the user in multiseat to just pick his own outputs, if you claim to want a truly flexible interfaces, also the crtc-output mappings aren't always simple, there are limitations on most hw about which crtc can map to which output and when you can clone etc.. putting policy for this stuff in-kernel would heavily restrict what the user can do... Policy for this kind of thing should just go in HAL's ConsoleKit: http://lists.freedesktop.org/archives/hal/2007-January/007111.html Xav - 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: tracking down disk spinups.
Le lundi 14 mai 2007 à 12:24 -0700, Jeremy Fitzhardinge a écrit : > I don't think you can change filesystem types with remount. Doesn't > that just change flags on an existing mount? +1 - 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: tracking down disk spinups.
Le lundi 14 mai 2007 à 14:57 -0400, Dave Jones a écrit : > (14:49:52:[EMAIL PROTECTED]:~)# mount > /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) > (14:49:56:[EMAIL PROTECTED]:~)# mount /dev/mapper/VolGroup00-LogVol00 / -t > ext2 -o remount,rw > (14:50:37:[EMAIL PROTECTED]:~)# mount > /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) > > Why did the kernel ignore what I told it to do ? > I'm sure it thinks it knows better than me for a reason, but > I'd like to know what it is. Are you sure it's the kernel, and not just mount ? Did you try cat /proc/mounts ? Xav - 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: tracking down disk spinups.
Le lundi 14 mai 2007 à 14:57 -0400, Dave Jones a écrit : (14:49:52:[EMAIL PROTECTED]:~)# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) (14:49:56:[EMAIL PROTECTED]:~)# mount /dev/mapper/VolGroup00-LogVol00 / -t ext2 -o remount,rw (14:50:37:[EMAIL PROTECTED]:~)# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) Why did the kernel ignore what I told it to do ? I'm sure it thinks it knows better than me for a reason, but I'd like to know what it is. Are you sure it's the kernel, and not just mount ? Did you try cat /proc/mounts ? Xav - 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: tracking down disk spinups.
Le lundi 14 mai 2007 à 12:24 -0700, Jeremy Fitzhardinge a écrit : I don't think you can change filesystem types with remount. Doesn't that just change flags on an existing mount? +1 - 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: Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)
On Thu, 2007-05-10 at 16:51 +0200, Jan Engelhardt wrote: > >(But Andrew never saw your email, I suspect: "[EMAIL PROTECTED]" is > probably > >some strange mixup of Andrew Morton and Andi Kleen in your mind ;) > > What do the letters kp stand for? "Keep Patching" ? - 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: Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)
On Thu, 2007-05-10 at 16:51 +0200, Jan Engelhardt wrote: (But Andrew never saw your email, I suspect: [EMAIL PROTECTED] is probably some strange mixup of Andrew Morton and Andi Kleen in your mind ;) What do the letters kp stand for? Keep Patching ? - 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: staircase deadline 0.37 backport 2.6.18.8 and 2.6.19.7 & debian sarge/etch kernel availability
On ven, 2007-03-30 at 07:39 -0400, Fortier,Vincent [Montreal] wrote: > Hi all, > > Backports of the staircase deadline cpu scheduler version 0.37 for > 2.6.18.8 and 2.6.19.7 kernels are available at > http://linux-dev.qc.ec.gc.ca/. BTW thanks a lot Vincent, I regularly use your .deb kernels (instead of compiling them myself) for testing SD & CFS, they're working great ! Xav - 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: staircase deadline 0.37 backport 2.6.18.8 and 2.6.19.7 debian sarge/etch kernel availability
On ven, 2007-03-30 at 07:39 -0400, Fortier,Vincent [Montreal] wrote: Hi all, Backports of the staircase deadline cpu scheduler version 0.37 for 2.6.18.8 and 2.6.19.7 kernels are available at http://linux-dev.qc.ec.gc.ca/. BTW thanks a lot Vincent, I regularly use your .deb kernels (instead of compiling them myself) for testing SD CFS, they're working great ! Xav - 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/
