Re: "Default Linux Capabilities" default in 2.6.24
On Tue, 29 Jan 2008 07:08:25 -0600 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > Quoting James Morris ([EMAIL PROTECTED]): > > On Mon, 28 Jan 2008, Matt LaPlante wrote: > > > > > On Thu, 24 Jan 2008 19:12:01 -0600 > > > Matt LaPlante <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > I'm doing a make oldconfig with the new 2.6.24 kernel. I came to the > > > > prompt for "Default Linux Capabilities" which defaults to No: > > > > > > > > --- > > > > Default Linux Capabilities (SECURITY_CAPABILITIES) [N/y/?] (NEW) ? > > > > --- > > > > > > > > However the help text recommends saying Yes. > > > > > > > > --- > > > > This enables the "default" Linux capabilities functionality. > > > > If you are unsure how to answer this question, answer Y. > > > > --- > > > > > > > > Does this seem incongruous? Also, what's the "question"? :) > > > > > > > > Thanks, > > > > Matt LaPlante > > > > > > Anyone? > > > > I think this should be default y. > > True, it was made the default when CONFIG_SECURITY=n a few years ago, > and switching it off when toggling CONFIG_SECURITY is probably unsafe > for unsuspecting users/testers. > > Thanks Matt. > > -serge > > From 0528f582de5534b972abddbb3294a3fb11435a21 Mon Sep 17 00:00:00 2001 > From: [EMAIL PROTECTED] <[EMAIL PROTECTED](none)> > Date: Tue, 29 Jan 2008 05:04:43 -0800 > Subject: [PATCH 1/1] security: compile capabilities by default > > Capabilities have long been the default when CONFIG_SECURITY=n, > and its help text suggests turning it on when CONFIG_SECURITY=y. > But it is set to default n. > > Default it to y instead. > > Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]> > --- > security/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/security/Kconfig b/security/Kconfig > index 8086e61..389e151 100644 > --- a/security/Kconfig > +++ b/security/Kconfig > @@ -76,6 +76,7 @@ config SECURITY_NETWORK_XFRM > config SECURITY_CAPABILITIES > bool "Default Linux Capabilities" > depends on SECURITY > + default y > help > This enables the "default" Linux capabilities functionality. > If you are unsure how to answer this question, answer Y. > -- > 1.5.1 > Acked-by: Matt LaPlante <[EMAIL PROTECTED]> -- 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: Default Linux Capabilities default in 2.6.24
On Tue, 29 Jan 2008 07:08:25 -0600 Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting James Morris ([EMAIL PROTECTED]): On Mon, 28 Jan 2008, Matt LaPlante wrote: On Thu, 24 Jan 2008 19:12:01 -0600 Matt LaPlante [EMAIL PROTECTED] wrote: I'm doing a make oldconfig with the new 2.6.24 kernel. I came to the prompt for Default Linux Capabilities which defaults to No: --- Default Linux Capabilities (SECURITY_CAPABILITIES) [N/y/?] (NEW) ? --- However the help text recommends saying Yes. --- This enables the default Linux capabilities functionality. If you are unsure how to answer this question, answer Y. --- Does this seem incongruous? Also, what's the question? :) Thanks, Matt LaPlante Anyone? I think this should be default y. True, it was made the default when CONFIG_SECURITY=n a few years ago, and switching it off when toggling CONFIG_SECURITY is probably unsafe for unsuspecting users/testers. Thanks Matt. -serge From 0528f582de5534b972abddbb3294a3fb11435a21 Mon Sep 17 00:00:00 2001 From: [EMAIL PROTECTED] [EMAIL PROTECTED](none) Date: Tue, 29 Jan 2008 05:04:43 -0800 Subject: [PATCH 1/1] security: compile capabilities by default Capabilities have long been the default when CONFIG_SECURITY=n, and its help text suggests turning it on when CONFIG_SECURITY=y. But it is set to default n. Default it to y instead. Signed-off-by: Serge Hallyn [EMAIL PROTECTED] --- security/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/security/Kconfig b/security/Kconfig index 8086e61..389e151 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -76,6 +76,7 @@ config SECURITY_NETWORK_XFRM config SECURITY_CAPABILITIES bool Default Linux Capabilities depends on SECURITY + default y help This enables the default Linux capabilities functionality. If you are unsure how to answer this question, answer Y. -- 1.5.1 Acked-by: Matt LaPlante [EMAIL PROTECTED] -- 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: "Default Linux Capabilities" default in 2.6.24
On Thu, 24 Jan 2008 19:12:01 -0600 Matt LaPlante <[EMAIL PROTECTED]> wrote: > > I'm doing a make oldconfig with the new 2.6.24 kernel. I came to the prompt > for "Default Linux Capabilities" which defaults to No: > > --- > Default Linux Capabilities (SECURITY_CAPABILITIES) [N/y/?] (NEW) ? > --- > > However the help text recommends saying Yes. > > --- > This enables the "default" Linux capabilities functionality. > If you are unsure how to answer this question, answer Y. > --- > > Does this seem incongruous? Also, what's the "question"? :) > > Thanks, > Matt LaPlante Anyone? -- 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: Default Linux Capabilities default in 2.6.24
On Thu, 24 Jan 2008 19:12:01 -0600 Matt LaPlante [EMAIL PROTECTED] wrote: I'm doing a make oldconfig with the new 2.6.24 kernel. I came to the prompt for Default Linux Capabilities which defaults to No: --- Default Linux Capabilities (SECURITY_CAPABILITIES) [N/y/?] (NEW) ? --- However the help text recommends saying Yes. --- This enables the default Linux capabilities functionality. If you are unsure how to answer this question, answer Y. --- Does this seem incongruous? Also, what's the question? :) Thanks, Matt LaPlante Anyone? -- 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/
"Default Linux Capabilities" default in 2.6.24
I'm doing a make oldconfig with the new 2.6.24 kernel. I came to the prompt for "Default Linux Capabilities" which defaults to No: --- Default Linux Capabilities (SECURITY_CAPABILITIES) [N/y/?] (NEW) ? --- However the help text recommends saying Yes. --- This enables the "default" Linux capabilities functionality. If you are unsure how to answer this question, answer Y. --- Does this seem incongruous? Also, what's the "question"? :) Thanks, Matt LaPlante -- 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/
Default Linux Capabilities default in 2.6.24
I'm doing a make oldconfig with the new 2.6.24 kernel. I came to the prompt for Default Linux Capabilities which defaults to No: --- Default Linux Capabilities (SECURITY_CAPABILITIES) [N/y/?] (NEW) ? --- However the help text recommends saying Yes. --- This enables the default Linux capabilities functionality. If you are unsure how to answer this question, answer Y. --- Does this seem incongruous? Also, what's the question? :) Thanks, Matt LaPlante -- 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/
A little coding style nugget of joy
Since everyone loves random statistics, here are a few gems to give you a break from your busy day: Number of lines in the 2.6.22 Linux kernel source that include one or more trailing whitespaces: 135209 Bytes saved by removing said whitespace: 151809 Lines in the (unified) diff: 455437 Size of the diff: 15M People brave enough to submit the patch: ~0 Take care. :) - Matt - 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/
A little coding style nugget of joy
Since everyone loves random statistics, here are a few gems to give you a break from your busy day: Number of lines in the 2.6.22 Linux kernel source that include one or more trailing whitespaces: 135209 Bytes saved by removing said whitespace: 151809 Lines in the (unified) diff: 455437 Size of the diff: 15M People brave enough to submit the patch: ~0 Take care. :) - Matt - 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: Problem charging blackberry 8700c with berry_charge (2.6.22.6)
On Mon, 10 Sep 2007 23:35:02 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > > > Sep 9 13:49:01 prizm kernel: [ 584.407498] drivers/usb/core/inode.c: > > creating file '003' > > Sep 9 13:49:01 prizm kernel: [ 584.407509] hub 5-0:1.0: state 7 ports 8 > > chg evt 0004 > > Sep 9 13:49:01 prizm kernel: [ 584.407520] hub 1-0:1.0: state 7 ports 2 > > chg evt 0004 > > Sep 9 13:49:03 prizm kernel: [ 586.405512] usb 1-2: usb auto-suspend > > Sep 9 13:49:03 prizm kernel: [ 586.421471] hub 5-0:1.0: hub_suspend > > Sep 9 13:49:03 prizm kernel: [ 586.421481] ehci_hcd :00:10.4: suspend > > root hub > > Sep 9 13:49:03 prizm kernel: [ 586.421496] usb usb5: usb auto-suspend > > Sep 9 13:49:05 prizm kernel: [ 588.421351] hub 1-0:1.0: hub_suspend > > Sep 9 13:49:05 prizm kernel: [ 588.421361] usb usb1: suspend_rh > > Sep 9 13:49:05 prizm kernel: [ 588.421481] usb usb1: usb auto-suspend > > Ah, oh wait, now we just turned the power off. > > Try disabling CONFIG_USB_SUSPEND and see if that fixes this issue. Or > you can manually turn the power back on to your blackberry by writing to > the autosuspend file for the usb device in sysfs, but that can be a > pain. > > Let me know if just changing that config option works for you. > And now for the dramatic conclusion... To begin, I have no access to the original machine at the moment, as I'm now out of that area for a couple weeks. I built a similar kernel (same version) on another box that I have at my current location. The new machine is different hardware, so some kernel re-configuring was required, but I kept with the same USB settings (and similar overall design). Interestingly, this machine didn't reproduce the "magic command failed" error, but it did fail very similarly to the original at charging the device. I disabled CONFIG_USB_SUSPEND as suggested, and lo and behold, it now charges the berry. Looks like an excellent diagnosis to me, doctor. Thanks! :) > thanks, > > greg k-h -- Matt - 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: Problem charging blackberry 8700c with berry_charge (2.6.22.6)
On Mon, 10 Sep 2007 23:35:02 -0700 Greg KH [EMAIL PROTECTED] wrote: Sep 9 13:49:01 prizm kernel: [ 584.407498] drivers/usb/core/inode.c: creating file '003' Sep 9 13:49:01 prizm kernel: [ 584.407509] hub 5-0:1.0: state 7 ports 8 chg evt 0004 Sep 9 13:49:01 prizm kernel: [ 584.407520] hub 1-0:1.0: state 7 ports 2 chg evt 0004 Sep 9 13:49:03 prizm kernel: [ 586.405512] usb 1-2: usb auto-suspend Sep 9 13:49:03 prizm kernel: [ 586.421471] hub 5-0:1.0: hub_suspend Sep 9 13:49:03 prizm kernel: [ 586.421481] ehci_hcd :00:10.4: suspend root hub Sep 9 13:49:03 prizm kernel: [ 586.421496] usb usb5: usb auto-suspend Sep 9 13:49:05 prizm kernel: [ 588.421351] hub 1-0:1.0: hub_suspend Sep 9 13:49:05 prizm kernel: [ 588.421361] usb usb1: suspend_rh Sep 9 13:49:05 prizm kernel: [ 588.421481] usb usb1: usb auto-suspend Ah, oh wait, now we just turned the power off. Try disabling CONFIG_USB_SUSPEND and see if that fixes this issue. Or you can manually turn the power back on to your blackberry by writing to the autosuspend file for the usb device in sysfs, but that can be a pain. Let me know if just changing that config option works for you. And now for the dramatic conclusion... To begin, I have no access to the original machine at the moment, as I'm now out of that area for a couple weeks. I built a similar kernel (same version) on another box that I have at my current location. The new machine is different hardware, so some kernel re-configuring was required, but I kept with the same USB settings (and similar overall design). Interestingly, this machine didn't reproduce the magic command failed error, but it did fail very similarly to the original at charging the device. I disabled CONFIG_USB_SUSPEND as suggested, and lo and behold, it now charges the berry. Looks like an excellent diagnosis to me, doctor. Thanks! :) thanks, greg k-h -- Matt - 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/
Problem charging blackberry 8700c with berry_charge (2.6.22.6)
I'm running the 2.6.22.6 kernel with the berry_charge module loaded. I connect my 8700c via USB, but the blackberry does not appear to charge. The power icon does not change, and even after staying connected for an extended period, the device does not appear to be gaining any power. The cable is good, as I can plug it into my Windows machine and it begins charging immediately. I see the following in dmesg: [ 6638.606493] usb 1-2: new full speed USB device using uhci_hcd and address 2 [ 6638.776524] usb 1-2: configuration #1 chosen from 1 choice [ 6639.639611] usbcore: registered new interface driver berry_charge [ 6639.837097] usb 1-2: Second magic command failed: -71. [ 6639.866430] usb 1-2: USB disconnect, address 2 [ 6640.610385] usb 1-2: new full speed USB device using uhci_hcd and address 3 [ 6640.775947] usb 1-2: configuration #1 chosen from 1 choice I'd be glad to provide more information if needed. -- Matt LaPlante - 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/
Problem charging blackberry 8700c with berry_charge (2.6.22.6)
I'm running the 2.6.22.6 kernel with the berry_charge module loaded. I connect my 8700c via USB, but the blackberry does not appear to charge. The power icon does not change, and even after staying connected for an extended period, the device does not appear to be gaining any power. The cable is good, as I can plug it into my Windows machine and it begins charging immediately. I see the following in dmesg: [ 6638.606493] usb 1-2: new full speed USB device using uhci_hcd and address 2 [ 6638.776524] usb 1-2: configuration #1 chosen from 1 choice [ 6639.639611] usbcore: registered new interface driver berry_charge [ 6639.837097] usb 1-2: Second magic command failed: -71. [ 6639.866430] usb 1-2: USB disconnect, address 2 [ 6640.610385] usb 1-2: new full speed USB device using uhci_hcd and address 3 [ 6640.775947] usb 1-2: configuration #1 chosen from 1 choice I'd be glad to provide more information if needed. -- Matt LaPlante - 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] 2.6.21-git15 - Kconfig Cleanup
On Fri, 18 May 2007 15:09:53 -0400 Matt LaPlante <[EMAIL PROTECTED]> wrote: > On Fri, 18 May 2007 20:01:54 +0200 > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote: > > > > > ping? > > > > Noone disagreed, and trivial patches will be forwarded again during the > > 2.6.23 merge window. > This patch doesn't appear to have ever found its way into the trivial git after it was accepted, and as a result doesn't seem to have made it into 2.6.23 before the window closed. Was there a problem? FWIW, I have a second patch that also doesn't seem to have made it to the trivial git yet... but unlike the patch above, the second one is only a few weeks old and may just be sitting in the old inbox (http://article.gmane.org/gmane.linux.kernel/554613). Thanks, Matt > > > > > cu > > Adrian > > > > -- > > > >"Is there not promise of rain?" Ling Tan asked suddenly out > > of the darkness. There had been need of rain for many days. > >"Only a promise," Lao Er said. > >Pearl S. Buck - Dragon Seed > > > > - 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] 2.6.21-git15 - Kconfig Cleanup
On Fri, 18 May 2007 15:09:53 -0400 Matt LaPlante [EMAIL PROTECTED] wrote: On Fri, 18 May 2007 20:01:54 +0200 Adrian Bunk [EMAIL PROTECTED] wrote: On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote: ping? Noone disagreed, and trivial patches will be forwarded again during the 2.6.23 merge window. This patch doesn't appear to have ever found its way into the trivial git after it was accepted, and as a result doesn't seem to have made it into 2.6.23 before the window closed. Was there a problem? FWIW, I have a second patch that also doesn't seem to have made it to the trivial git yet... but unlike the patch above, the second one is only a few weeks old and may just be sitting in the old inbox (http://article.gmane.org/gmane.linux.kernel/554613). Thanks, Matt cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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] 2.6.22 - Documentation Cleanup
Thanks Jesper. Updated below, sans one: On Fri, 13 Jul 2007 00:09:36 +0200 "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > > orred in. > > "orred"?? Wouldn't "OR'ed" or similar be better? I don't know the right answer here, so I'm opting out of making the change in this patch for lack of a decisive answer. The apostrophe in OR'ed seems wrong to me, but ORed looks a bit odd too. If I get a chance to do a bit more research, I'll try to go back to it (and others) later on. -- diff -ru a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-11 21:47:43.0 -0400 @@ -5,7 +5,7 @@ The kernel provides an interface to manage DMA transfers - using the DMA channels in the cpu, so that the central + using the DMA channels in the CPU, so that the central duty of managing channel mappings, and programming the channel generators is in one place. @@ -17,15 +17,15 @@ channels to all sources, which means that some devices have a restricted number of channels that can be used. - To allow flexibilty for each cpu type and board, the - dma code can be given an dma ordering structure which + To allow flexibility for each CPU type and board, the + DMA code can be given a DMA ordering structure which allows the order of channel search to be specified, as well as allowing the prohibition of certain claims. struct s3c24xx_dma_order has a list of channels, and - each channel within has a slot for a list of dma - channel numbers. The slots are searched in order, for - the presence of a dma channel number with DMA_CH_VALID + each channel within has a slot for a list of DMA + channel numbers. The slots are searched in order for + the presence of a DMA channel number with DMA_CH_VALID orred in. If the order has the flag DMA_CH_NEVER set, then after @@ -33,8 +33,8 @@ found channel, thus denying the request. A board support file can call s3c24xx_dma_order_set() - to register an complete ordering set. The routine will - copy the data, so the original can be discared with + to register a complete ordering set. The routine will + copy the data, so the original can be discarded with __initdata. diff -ru a/Documentation/devices.txt b/Documentation/devices.txt --- a/Documentation/devices.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/devices.txt 2007-07-08 23:46:00.0 -0400 @@ -2186,7 +2186,7 @@ 136-143 char Unix98 PTY slaves 0 = /dev/pts/0First Unix98 pseudo-TTY - 1 = /dev/pts/1Second Unix98 pesudo-TTY + 1 = /dev/pts/1Second Unix98 pseudo-TTY ... These device nodes are automatically generated with diff -ru a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt --- a/Documentation/driver-model/devres.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/driver-model/devres.txt 2007-07-09 12:19:28.0 -0400 @@ -32,7 +32,7 @@ For one reason or another, low level drivers don't receive as much attention or testing as core code, and bugs on driver detach or -initilaization failure doesn't happen often enough to be noticeable. +initialization failure doesn't happen often enough to be noticeable. Init failure path is worse because it's much less travelled while needs to handle multiple entry points. @@ -160,7 +160,7 @@ devres_release_group(dev, NULL); return err_code; -As resource acquision failure usually means probe failure, constructs +As resource acquisition failure usually means probe failure, constructs like above are usually useful in midlayer driver (e.g. libata core layer) where interface function shouldn't have side effect on failure. For LLDs, just returning error code suffices in most cases. diff -ru a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt --- a/Documentation/fb/deferred_io.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/fb/deferred_io.txt 2007-07-08 22:59:22.0 -0400 @@ -3,7 +3,7 @@ Deferred IO is a way to delay and repurpose IO. It uses host memory as a buffer and the MMU pagefault as a pretrigger for when to perform the device -IO. The following example may be a useful explaination of how one such setup +IO. The following example may be a useful explanation of how one such setup works: - userspace app like Xfbdev mmaps framebuffer @@ -28,7 +28,7 @@ For some types of nonvolatile high latency displays, the desired image is the final image rather than the intermediate stages which is why it's okay -to not update for each write that is occuring. +to not update for each write that is occurring. It may be the case that this is useful in other scenarios as well. Paul Mundt has
Re: [PATCH] 2.6.22 - Documentation Cleanup
Thanks Jesper. Updated below, sans one: On Fri, 13 Jul 2007 00:09:36 +0200 Jesper Juhl [EMAIL PROTECTED] wrote: orred in. orred?? Wouldn't OR'ed or similar be better? I don't know the right answer here, so I'm opting out of making the change in this patch for lack of a decisive answer. The apostrophe in OR'ed seems wrong to me, but ORed looks a bit odd too. If I get a chance to do a bit more research, I'll try to go back to it (and others) later on. -- diff -ru a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-11 21:47:43.0 -0400 @@ -5,7 +5,7 @@ The kernel provides an interface to manage DMA transfers - using the DMA channels in the cpu, so that the central + using the DMA channels in the CPU, so that the central duty of managing channel mappings, and programming the channel generators is in one place. @@ -17,15 +17,15 @@ channels to all sources, which means that some devices have a restricted number of channels that can be used. - To allow flexibilty for each cpu type and board, the - dma code can be given an dma ordering structure which + To allow flexibility for each CPU type and board, the + DMA code can be given a DMA ordering structure which allows the order of channel search to be specified, as well as allowing the prohibition of certain claims. struct s3c24xx_dma_order has a list of channels, and - each channel within has a slot for a list of dma - channel numbers. The slots are searched in order, for - the presence of a dma channel number with DMA_CH_VALID + each channel within has a slot for a list of DMA + channel numbers. The slots are searched in order for + the presence of a DMA channel number with DMA_CH_VALID orred in. If the order has the flag DMA_CH_NEVER set, then after @@ -33,8 +33,8 @@ found channel, thus denying the request. A board support file can call s3c24xx_dma_order_set() - to register an complete ordering set. The routine will - copy the data, so the original can be discared with + to register a complete ordering set. The routine will + copy the data, so the original can be discarded with __initdata. diff -ru a/Documentation/devices.txt b/Documentation/devices.txt --- a/Documentation/devices.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/devices.txt 2007-07-08 23:46:00.0 -0400 @@ -2186,7 +2186,7 @@ 136-143 char Unix98 PTY slaves 0 = /dev/pts/0First Unix98 pseudo-TTY - 1 = /dev/pts/1Second Unix98 pesudo-TTY + 1 = /dev/pts/1Second Unix98 pseudo-TTY ... These device nodes are automatically generated with diff -ru a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt --- a/Documentation/driver-model/devres.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/driver-model/devres.txt 2007-07-09 12:19:28.0 -0400 @@ -32,7 +32,7 @@ For one reason or another, low level drivers don't receive as much attention or testing as core code, and bugs on driver detach or -initilaization failure doesn't happen often enough to be noticeable. +initialization failure doesn't happen often enough to be noticeable. Init failure path is worse because it's much less travelled while needs to handle multiple entry points. @@ -160,7 +160,7 @@ devres_release_group(dev, NULL); return err_code; -As resource acquision failure usually means probe failure, constructs +As resource acquisition failure usually means probe failure, constructs like above are usually useful in midlayer driver (e.g. libata core layer) where interface function shouldn't have side effect on failure. For LLDs, just returning error code suffices in most cases. diff -ru a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt --- a/Documentation/fb/deferred_io.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/fb/deferred_io.txt 2007-07-08 22:59:22.0 -0400 @@ -3,7 +3,7 @@ Deferred IO is a way to delay and repurpose IO. It uses host memory as a buffer and the MMU pagefault as a pretrigger for when to perform the device -IO. The following example may be a useful explaination of how one such setup +IO. The following example may be a useful explanation of how one such setup works: - userspace app like Xfbdev mmaps framebuffer @@ -28,7 +28,7 @@ For some types of nonvolatile high latency displays, the desired image is the final image rather than the intermediate stages which is why it's okay -to not update for each write that is occuring. +to not update for each write that is occurring. It may be the case that this is useful in other scenarios as well. Paul Mundt has mentioned a
Re: [PATCH] 2.6.22 - Documentation Cleanup
Version 2 with fixes suggested by Randy & Joe. On Mon, 9 Jul 2007 13:45:16 -0400 Matt LaPlante <[EMAIL PROTECTED]> wrote: > Fix misc small issues/typos/grammar in Documentation txts for 2.6.22. > > Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]> > -- diff -ru a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-11 21:47:43.0 -0400 @@ -5,7 +5,7 @@ The kernel provides an interface to manage DMA transfers - using the DMA channels in the cpu, so that the central + using the DMA channels in the CPU, so that the central duty of managing channel mappings, and programming the channel generators is in one place. @@ -17,15 +17,15 @@ channels to all sources, which means that some devices have a restricted number of channels that can be used. - To allow flexibilty for each cpu type and board, the - dma code can be given an dma ordering structure which + To allow flexibility for each CPU type and board, the + DMA code can be given a DMA ordering structure which allows the order of channel search to be specified, as well as allowing the prohibition of certain claims. struct s3c24xx_dma_order has a list of channels, and - each channel within has a slot for a list of dma - channel numbers. The slots are searched in order, for - the presence of a dma channel number with DMA_CH_VALID + each channel within has a slot for a list of DMA + channel numbers. The slots are searched in order for + the presence of a DMA channel number with DMA_CH_VALID orred in. If the order has the flag DMA_CH_NEVER set, then after @@ -33,8 +33,8 @@ found channel, thus denying the request. A board support file can call s3c24xx_dma_order_set() - to register an complete ordering set. The routine will - copy the data, so the original can be discared with + to register a complete ordering set. The routine will + copy the data, so the original can be discarded with __initdata. diff -ru a/Documentation/devices.txt b/Documentation/devices.txt --- a/Documentation/devices.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/devices.txt 2007-07-08 23:46:00.0 -0400 @@ -2186,7 +2186,7 @@ 136-143 char Unix98 PTY slaves 0 = /dev/pts/0First Unix98 pseudo-TTY - 1 = /dev/pts/1Second Unix98 pesudo-TTY + 1 = /dev/pts/1Second Unix98 pseudo-TTY ... These device nodes are automatically generated with diff -ru a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt --- a/Documentation/driver-model/devres.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/driver-model/devres.txt 2007-07-09 12:19:28.0 -0400 @@ -32,7 +32,7 @@ For one reason or another, low level drivers don't receive as much attention or testing as core code, and bugs on driver detach or -initilaization failure doesn't happen often enough to be noticeable. +initialization failure doesn't happen often enough to be noticeable. Init failure path is worse because it's much less travelled while needs to handle multiple entry points. @@ -160,7 +160,7 @@ devres_release_group(dev, NULL); return err_code; -As resource acquision failure usually means probe failure, constructs +As resource acquisition failure usually means probe failure, constructs like above are usually useful in midlayer driver (e.g. libata core layer) where interface function shouldn't have side effect on failure. For LLDs, just returning error code suffices in most cases. diff -ru a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt --- a/Documentation/fb/deferred_io.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/fb/deferred_io.txt 2007-07-08 22:59:22.0 -0400 @@ -3,7 +3,7 @@ Deferred IO is a way to delay and repurpose IO. It uses host memory as a buffer and the MMU pagefault as a pretrigger for when to perform the device -IO. The following example may be a useful explaination of how one such setup +IO. The following example may be a useful explanation of how one such setup works: - userspace app like Xfbdev mmaps framebuffer @@ -28,7 +28,7 @@ For some types of nonvolatile high latency displays, the desired image is the final image rather than the intermediate stages which is why it's okay -to not update for each write that is occuring. +to not update for each write that is occurring. It may be the case that this is useful in other scenarios as well. Paul Mundt has mentioned a case where it is beneficial to use the page count to decide diff -ru a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt --- a/Documentation/filesystems/9p.txt 2007-07-08 19
Re: [PATCH] 2.6.22 - Documentation Cleanup
Thanks as always... comments below, new patch coming separately. On Mon, 9 Jul 2007 16:39:49 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Mon, 9 Jul 2007 13:45:16 -0400 Matt LaPlante wrote: > > > Fix misc small issues/typos/grammar in Documentation txts for 2.6.22. > > > > Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]> > > -- > > patching file Documentation/input/iforce-protocol.txt > Hunk #1 FAILED at 7. > Hunk #2 FAILED at 151. > Hunk #3 FAILED at 239. > 3 out of 3 hunks FAILED -- saving rejects to file > Documentation/input/iforce-protocol.txt.rej Hrm... I double checked against both virgin 2.6.22 and 22-git2, and both applied without error... are you sure about this? > > > > diff -ru a/Documentation/arm/Samsung-S3C24XX/DMA.txt > > b/Documentation/arm/Samsung-S3C24XX/DMA.txt > > --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 > > 19:32:17.0 -0400 > > +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 > > 23:11:21.0 -0400 > > @@ -17,15 +17,15 @@ > > channels to all sources, which means that some devices > > have a restricted number of channels that can be used. > > > > - To allow flexibilty for each cpu type and board, the > > - dma code can be given an dma ordering structure which > > + To allow flexibility for each cpu type and board, the > > + DMA code can be given a DMA ordering structure which > > allows the order of channel search to be specified, as > > well as allowing the prohibition of certain claims. > > Why uppercase DMA and not cpu? Maybe I was subconciously trying not to set a precedent for that one... :) Changed now. > > > struct s3c24xx_dma_order has a list of channels, and > > - each channel within has a slot for a list of dma > > - channel numbers. The slots are searched in order, for > > - the presence of a dma channel number with DMA_CH_VALID > > + each channel within has a slot for a list of DMA > > + channel numbers. The slots are searched in order for > > + the presence of a DMA channel number with DMA_CH_VALID > > orred in. > > > > If the order has the flag DMA_CH_NEVER set, then after > > @@ -33,8 +33,8 @@ > > found channel, thus denying the request. > > > > A board support file can call s3c24xx_dma_order_set() > > - to register an complete ordering set. The routine will > > - copy the data, so the original can be discared with > > + to register a complete ordering set. The routine will > > + copy the data, so the original can be discarded with > > __initdata. > > > > > > diff -ru a/Documentation/input/iforce-protocol.txt > > b/Documentation/input/iforce-protocol.txt > > --- a/Documentation/input/iforce-protocol.txt 2007-07-08 > > 19:32:17.0 -0400 > > +++ b/Documentation/input/iforce-protocol.txt 2007-07-08 > > 22:26:12.0 -0400 > > @@ -239,7 +239,7 @@ > > 3. Play the effect, and watch what happens on the spy screen. > > > > A few words about ComPortSpy: > > -At first glance, this soft seems, hum, well... buggy. In fact, data appear > > with a few seconds latency. Personnaly, I restart it every time I play an > > effect. > > +At first glance, this soft seems, hum, well... buggy. In fact, data appear > > with a few seconds latency. Personally, I restart it every time I play an > > effect. > > Those lines are too long. agreed... chopped up the offenders in that file > > > Remember it's free (as in free beer) and alpha! > > > > ** URLS ** > > > diff -ru a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt > > --- a/Documentation/scsi/ibmmca.txt 2007-07-08 19:32:17.0 -0400 > > +++ b/Documentation/scsi/ibmmca.txt 2007-07-09 12:47:52.0 -0400 > > @@ -72,12 +72,12 @@ > > 1 Abstract > > -- > > This README-file describes the IBM SCSI-subsystem low level driver for > > - Linux. The descriptions which were formerly kept in the source-code > > have > > - been taken out to this file to easify the codes' readability. The > > driver > > + Linux. The descriptions which were formerly kept in the source code > > have > > + been taken out of this file to simplify the codes readability. The > > driver > > code's > > and that line ends with a space. There are several new patch lines > that end with a space. Please check/remove those trailing spaces. $ find ./Documenta
Re: [PATCH] 2.6.22 - Documentation Cleanup
Thanks as always... comments below, new patch coming separately. On Mon, 9 Jul 2007 16:39:49 -0700 Randy Dunlap [EMAIL PROTECTED] wrote: On Mon, 9 Jul 2007 13:45:16 -0400 Matt LaPlante wrote: Fix misc small issues/typos/grammar in Documentation txts for 2.6.22. Signed-off-by: Matt LaPlante [EMAIL PROTECTED] -- patching file Documentation/input/iforce-protocol.txt Hunk #1 FAILED at 7. Hunk #2 FAILED at 151. Hunk #3 FAILED at 239. 3 out of 3 hunks FAILED -- saving rejects to file Documentation/input/iforce-protocol.txt.rej Hrm... I double checked against both virgin 2.6.22 and 22-git2, and both applied without error... are you sure about this? diff -ru a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 23:11:21.0 -0400 @@ -17,15 +17,15 @@ channels to all sources, which means that some devices have a restricted number of channels that can be used. - To allow flexibilty for each cpu type and board, the - dma code can be given an dma ordering structure which + To allow flexibility for each cpu type and board, the + DMA code can be given a DMA ordering structure which allows the order of channel search to be specified, as well as allowing the prohibition of certain claims. Why uppercase DMA and not cpu? Maybe I was subconciously trying not to set a precedent for that one... :) Changed now. struct s3c24xx_dma_order has a list of channels, and - each channel within has a slot for a list of dma - channel numbers. The slots are searched in order, for - the presence of a dma channel number with DMA_CH_VALID + each channel within has a slot for a list of DMA + channel numbers. The slots are searched in order for + the presence of a DMA channel number with DMA_CH_VALID orred in. If the order has the flag DMA_CH_NEVER set, then after @@ -33,8 +33,8 @@ found channel, thus denying the request. A board support file can call s3c24xx_dma_order_set() - to register an complete ordering set. The routine will - copy the data, so the original can be discared with + to register a complete ordering set. The routine will + copy the data, so the original can be discarded with __initdata. diff -ru a/Documentation/input/iforce-protocol.txt b/Documentation/input/iforce-protocol.txt --- a/Documentation/input/iforce-protocol.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/input/iforce-protocol.txt 2007-07-08 22:26:12.0 -0400 @@ -239,7 +239,7 @@ 3. Play the effect, and watch what happens on the spy screen. A few words about ComPortSpy: -At first glance, this soft seems, hum, well... buggy. In fact, data appear with a few seconds latency. Personnaly, I restart it every time I play an effect. +At first glance, this soft seems, hum, well... buggy. In fact, data appear with a few seconds latency. Personally, I restart it every time I play an effect. Those lines are too long. agreed... chopped up the offenders in that file Remember it's free (as in free beer) and alpha! ** URLS ** diff -ru a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt --- a/Documentation/scsi/ibmmca.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/scsi/ibmmca.txt 2007-07-09 12:47:52.0 -0400 @@ -72,12 +72,12 @@ 1 Abstract -- This README-file describes the IBM SCSI-subsystem low level driver for - Linux. The descriptions which were formerly kept in the source-code have - been taken out to this file to easify the codes' readability. The driver + Linux. The descriptions which were formerly kept in the source code have + been taken out of this file to simplify the codes readability. The driver code's and that line ends with a space. There are several new patch lines that end with a space. Please check/remove those trailing spaces. $ find ./Documentation -name *.txt | xargs pcregrep \S+ $ | wc -l 3494 Good grief! This may require a seperate patch or two. :) Instances in this patch should be fixed (not necessarily in context lines). description has been updated, as most of the former description was already quite outdated. The history of the driver development is also kept inside here. Multiple historical developments have been summarized to shorten the - textsize a bit. At the end of this file you can find a small manual for + text size a bit. At the end of this file you can find a small manual for this driver and hints to get it running on your machine. 2 Driver Description
Re: [PATCH] 2.6.22 - Documentation Cleanup
Version 2 with fixes suggested by Randy Joe. On Mon, 9 Jul 2007 13:45:16 -0400 Matt LaPlante [EMAIL PROTECTED] wrote: Fix misc small issues/typos/grammar in Documentation txts for 2.6.22. Signed-off-by: Matt LaPlante [EMAIL PROTECTED] -- diff -ru a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-11 21:47:43.0 -0400 @@ -5,7 +5,7 @@ The kernel provides an interface to manage DMA transfers - using the DMA channels in the cpu, so that the central + using the DMA channels in the CPU, so that the central duty of managing channel mappings, and programming the channel generators is in one place. @@ -17,15 +17,15 @@ channels to all sources, which means that some devices have a restricted number of channels that can be used. - To allow flexibilty for each cpu type and board, the - dma code can be given an dma ordering structure which + To allow flexibility for each CPU type and board, the + DMA code can be given a DMA ordering structure which allows the order of channel search to be specified, as well as allowing the prohibition of certain claims. struct s3c24xx_dma_order has a list of channels, and - each channel within has a slot for a list of dma - channel numbers. The slots are searched in order, for - the presence of a dma channel number with DMA_CH_VALID + each channel within has a slot for a list of DMA + channel numbers. The slots are searched in order for + the presence of a DMA channel number with DMA_CH_VALID orred in. If the order has the flag DMA_CH_NEVER set, then after @@ -33,8 +33,8 @@ found channel, thus denying the request. A board support file can call s3c24xx_dma_order_set() - to register an complete ordering set. The routine will - copy the data, so the original can be discared with + to register a complete ordering set. The routine will + copy the data, so the original can be discarded with __initdata. diff -ru a/Documentation/devices.txt b/Documentation/devices.txt --- a/Documentation/devices.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/devices.txt 2007-07-08 23:46:00.0 -0400 @@ -2186,7 +2186,7 @@ 136-143 char Unix98 PTY slaves 0 = /dev/pts/0First Unix98 pseudo-TTY - 1 = /dev/pts/1Second Unix98 pesudo-TTY + 1 = /dev/pts/1Second Unix98 pseudo-TTY ... These device nodes are automatically generated with diff -ru a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt --- a/Documentation/driver-model/devres.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/driver-model/devres.txt 2007-07-09 12:19:28.0 -0400 @@ -32,7 +32,7 @@ For one reason or another, low level drivers don't receive as much attention or testing as core code, and bugs on driver detach or -initilaization failure doesn't happen often enough to be noticeable. +initialization failure doesn't happen often enough to be noticeable. Init failure path is worse because it's much less travelled while needs to handle multiple entry points. @@ -160,7 +160,7 @@ devres_release_group(dev, NULL); return err_code; -As resource acquision failure usually means probe failure, constructs +As resource acquisition failure usually means probe failure, constructs like above are usually useful in midlayer driver (e.g. libata core layer) where interface function shouldn't have side effect on failure. For LLDs, just returning error code suffices in most cases. diff -ru a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt --- a/Documentation/fb/deferred_io.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/fb/deferred_io.txt 2007-07-08 22:59:22.0 -0400 @@ -3,7 +3,7 @@ Deferred IO is a way to delay and repurpose IO. It uses host memory as a buffer and the MMU pagefault as a pretrigger for when to perform the device -IO. The following example may be a useful explaination of how one such setup +IO. The following example may be a useful explanation of how one such setup works: - userspace app like Xfbdev mmaps framebuffer @@ -28,7 +28,7 @@ For some types of nonvolatile high latency displays, the desired image is the final image rather than the intermediate stages which is why it's okay -to not update for each write that is occuring. +to not update for each write that is occurring. It may be the case that this is useful in other scenarios as well. Paul Mundt has mentioned a case where it is beneficial to use the page count to decide diff -ru a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt --- a/Documentation/filesystems/9p.txt 2007-07-08 19:32:17.0 -0400 +++ b
[PATCH] 2.6.22 - Documentation Cleanup
Fix misc small issues/typos/grammar in Documentation txts for 2.6.22. Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]> -- diff -ru a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 23:11:21.0 -0400 @@ -17,15 +17,15 @@ channels to all sources, which means that some devices have a restricted number of channels that can be used. - To allow flexibilty for each cpu type and board, the - dma code can be given an dma ordering structure which + To allow flexibility for each cpu type and board, the + DMA code can be given a DMA ordering structure which allows the order of channel search to be specified, as well as allowing the prohibition of certain claims. struct s3c24xx_dma_order has a list of channels, and - each channel within has a slot for a list of dma - channel numbers. The slots are searched in order, for - the presence of a dma channel number with DMA_CH_VALID + each channel within has a slot for a list of DMA + channel numbers. The slots are searched in order for + the presence of a DMA channel number with DMA_CH_VALID orred in. If the order has the flag DMA_CH_NEVER set, then after @@ -33,8 +33,8 @@ found channel, thus denying the request. A board support file can call s3c24xx_dma_order_set() - to register an complete ordering set. The routine will - copy the data, so the original can be discared with + to register a complete ordering set. The routine will + copy the data, so the original can be discarded with __initdata. diff -ru a/Documentation/devices.txt b/Documentation/devices.txt --- a/Documentation/devices.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/devices.txt 2007-07-08 23:46:00.0 -0400 @@ -2186,7 +2186,7 @@ 136-143 char Unix98 PTY slaves 0 = /dev/pts/0First Unix98 pseudo-TTY - 1 = /dev/pts/1Second Unix98 pesudo-TTY + 1 = /dev/pts/1Second Unix98 pseudo-TTY ... These device nodes are automatically generated with diff -ru a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt --- a/Documentation/driver-model/devres.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/driver-model/devres.txt 2007-07-09 12:19:28.0 -0400 @@ -32,7 +32,7 @@ For one reason or another, low level drivers don't receive as much attention or testing as core code, and bugs on driver detach or -initilaization failure doesn't happen often enough to be noticeable. +initialization failure doesn't happen often enough to be noticeable. Init failure path is worse because it's much less travelled while needs to handle multiple entry points. @@ -160,7 +160,7 @@ devres_release_group(dev, NULL); return err_code; -As resource acquision failure usually means probe failure, constructs +As resource acquisition failure usually means probe failure, constructs like above are usually useful in midlayer driver (e.g. libata core layer) where interface function shouldn't have side effect on failure. For LLDs, just returning error code suffices in most cases. diff -ru a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt --- a/Documentation/fb/deferred_io.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/fb/deferred_io.txt 2007-07-08 22:59:22.0 -0400 @@ -3,7 +3,7 @@ Deferred IO is a way to delay and repurpose IO. It uses host memory as a buffer and the MMU pagefault as a pretrigger for when to perform the device -IO. The following example may be a useful explaination of how one such setup +IO. The following example may be a useful explanation of how one such setup works: - userspace app like Xfbdev mmaps framebuffer @@ -28,7 +28,7 @@ For some types of nonvolatile high latency displays, the desired image is the final image rather than the intermediate stages which is why it's okay -to not update for each write that is occuring. +to not update for each write that is occurring. It may be the case that this is useful in other scenarios as well. Paul Mundt has mentioned a case where it is beneficial to use the page count to decide diff -ru a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt --- a/Documentation/filesystems/9p.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/filesystems/9p.txt 2007-07-09 12:22:03.0 -0400 @@ -40,7 +40,7 @@ aname=name aname specifies the file tree to access when the server is offering several exported file systems. - cache=mode specifies a cacheing policy. By default, no caches are used. + cache=mode specifies a caching policy. By default, no caches are used. loose = no attempts are made at consi
[PATCH] 2.6.22 - Documentation Cleanup
Fix misc small issues/typos/grammar in Documentation txts for 2.6.22. Signed-off-by: Matt LaPlante [EMAIL PROTECTED] -- diff -ru a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt 2007-07-08 23:11:21.0 -0400 @@ -17,15 +17,15 @@ channels to all sources, which means that some devices have a restricted number of channels that can be used. - To allow flexibilty for each cpu type and board, the - dma code can be given an dma ordering structure which + To allow flexibility for each cpu type and board, the + DMA code can be given a DMA ordering structure which allows the order of channel search to be specified, as well as allowing the prohibition of certain claims. struct s3c24xx_dma_order has a list of channels, and - each channel within has a slot for a list of dma - channel numbers. The slots are searched in order, for - the presence of a dma channel number with DMA_CH_VALID + each channel within has a slot for a list of DMA + channel numbers. The slots are searched in order for + the presence of a DMA channel number with DMA_CH_VALID orred in. If the order has the flag DMA_CH_NEVER set, then after @@ -33,8 +33,8 @@ found channel, thus denying the request. A board support file can call s3c24xx_dma_order_set() - to register an complete ordering set. The routine will - copy the data, so the original can be discared with + to register a complete ordering set. The routine will + copy the data, so the original can be discarded with __initdata. diff -ru a/Documentation/devices.txt b/Documentation/devices.txt --- a/Documentation/devices.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/devices.txt 2007-07-08 23:46:00.0 -0400 @@ -2186,7 +2186,7 @@ 136-143 char Unix98 PTY slaves 0 = /dev/pts/0First Unix98 pseudo-TTY - 1 = /dev/pts/1Second Unix98 pesudo-TTY + 1 = /dev/pts/1Second Unix98 pseudo-TTY ... These device nodes are automatically generated with diff -ru a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt --- a/Documentation/driver-model/devres.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/driver-model/devres.txt 2007-07-09 12:19:28.0 -0400 @@ -32,7 +32,7 @@ For one reason or another, low level drivers don't receive as much attention or testing as core code, and bugs on driver detach or -initilaization failure doesn't happen often enough to be noticeable. +initialization failure doesn't happen often enough to be noticeable. Init failure path is worse because it's much less travelled while needs to handle multiple entry points. @@ -160,7 +160,7 @@ devres_release_group(dev, NULL); return err_code; -As resource acquision failure usually means probe failure, constructs +As resource acquisition failure usually means probe failure, constructs like above are usually useful in midlayer driver (e.g. libata core layer) where interface function shouldn't have side effect on failure. For LLDs, just returning error code suffices in most cases. diff -ru a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt --- a/Documentation/fb/deferred_io.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/fb/deferred_io.txt 2007-07-08 22:59:22.0 -0400 @@ -3,7 +3,7 @@ Deferred IO is a way to delay and repurpose IO. It uses host memory as a buffer and the MMU pagefault as a pretrigger for when to perform the device -IO. The following example may be a useful explaination of how one such setup +IO. The following example may be a useful explanation of how one such setup works: - userspace app like Xfbdev mmaps framebuffer @@ -28,7 +28,7 @@ For some types of nonvolatile high latency displays, the desired image is the final image rather than the intermediate stages which is why it's okay -to not update for each write that is occuring. +to not update for each write that is occurring. It may be the case that this is useful in other scenarios as well. Paul Mundt has mentioned a case where it is beneficial to use the page count to decide diff -ru a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt --- a/Documentation/filesystems/9p.txt 2007-07-08 19:32:17.0 -0400 +++ b/Documentation/filesystems/9p.txt 2007-07-09 12:22:03.0 -0400 @@ -40,7 +40,7 @@ aname=name aname specifies the file tree to access when the server is offering several exported file systems. - cache=mode specifies a cacheing policy. By default, no caches are used. + cache=mode specifies a caching policy. By default, no caches are used. loose = no attempts are made at consistency
Re: [PATCH] 2.6.21-git15 - Kconfig Cleanup
On Fri, 18 May 2007 20:01:54 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote: > > > ping? > > Noone disagreed, and trivial patches will be forwarded again during the > 2.6.23 merge window. Ok, I didn't know it would be acceptable without an ack from someone... (is Randy on vacation? :) I know we've discussed the logic behind trivial merges going in prior to RC candidates, and generally I think it's sound enough (we don't want to disrupt the merging of patches that actually "matter," etc). I don't want to create a redundant conversation here, but I'm compelled to ask for opinions on this... I think the Kconfigs are a fairly prominent kernel feature, and would expect a lot of systems people will be seeing them when the new version goes final. That also means that a lot more people will be seeing the "trivial" errors in spelling or grammar that are being left in until the next version. In this round, for example, the new blackfin entries were really in need of some love. I don't really know how many people will report such things, or submit duplicate patches for them before we actually get to the next kernel cycle, but it seems like a waste to me. I don't really care so much about fixes to the Documentation texts or source comments because, in my estimation, they probably have a much smaller audience than the kernel configuration interface. I guess I'm just more sensitive to the presentation aspects of a project than the average developer, but I can't help feel it's a shame when we're willing to show the public such an unpolished face in a "final" product. To me, good code is taken down a notch by haphazard presentation. Thoughts? Cheers, Matt > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed > -- Matt LaPlante CCNP, CCDP, A+, Linux+, CQS [EMAIL PROTECTED] - 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] 2.6.21-git15 - Kconfig Cleanup
ping? On Fri, 11 May 2007 22:05:01 -0400 Matt LaPlante <[EMAIL PROTECTED]> wrote: > Fix misc small issues/typos/grammar in Kconfigs for 2.6.21-git15. > > Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]> > -- > > diff -ru a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig > --- a/arch/arm/plat-s3c24xx/Kconfig 2007-04-25 23:08:32.0 -0400 > +++ b/arch/arm/plat-s3c24xx/Kconfig 2007-05-11 21:44:06.0 -0400 > @@ -70,7 +70,7 @@ > help > Set the chunksize in Kilobytes of the CRC for checking memory > corruption over suspend and resume. A smaller value will mean that > - the CRC data block will take more memory, but wil identify any > + the CRC data block will take more memory, but will identify any > faults with better precision. > > See > diff -ru a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig > --- a/arch/blackfin/Kconfig 2007-05-11 20:32:24.0 -0400 > +++ b/arch/blackfin/Kconfig 2007-05-11 21:33:28.0 -0400 > @@ -435,100 +435,100 @@ > default y > help > If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked > - into L1 instruction memory.(less latency) > + into L1 instruction memory. (less latency) > > config EXCPT_IRQ_SYSC_L1 > - bool "Locate entire ASM lowlevel excepetion / interrupt - Syscall and > CPLB handler code in L1 Memory" > + bool "Locate entire ASM lowlevel exception / interrupt - Syscall and > CPLB handler code in L1 Memory" > default y > help > - If enabled entire ASM lowlevel exception and interrupt entry code > (STORE/RESTORE CONTEXT) is linked > - into L1 instruction memory.(less latency) > + If enabled, the entire ASM lowlevel exception and interrupt entry > code > + (STORE/RESTORE CONTEXT) is linked into L1 instruction memory. (less > latency) > > config DO_IRQ_L1 > bool "Locate frequently called do_irq dispatcher function in L1 Memory" > default y > help > - If enabled frequently called do_irq dispatcher function is linked > - into L1 instruction memory.(less latency) > + If enabled, the frequently called do_irq dispatcher function is linked > + into L1 instruction memory. (less latency) > > config CORE_TIMER_IRQ_L1 > bool "Locate frequently called timer_interrupt() function in L1 Memory" > default y > help > - If enabled frequently called timer_interrupt() function is linked > - into L1 instruction memory.(less latency) > + If enabled, the frequently called timer_interrupt() function is linked > + into L1 instruction memory. (less latency) > > config IDLE_L1 > bool "Locate frequently idle function in L1 Memory" > default y > help > - If enabled frequently called idle function is linked > - into L1 instruction memory.(less latency) > + If enabled, the frequently called idle function is linked > + into L1 instruction memory. (less latency) > > config SCHEDULE_L1 > bool "Locate kernel schedule function in L1 Memory" > default y > help > - If enabled frequently called kernel schedule is linked > - into L1 instruction memory.(less latency) > + If enabled, the frequently called kernel schedule is linked > + into L1 instruction memory. (less latency) > > config ARITHMETIC_OPS_L1 > bool "Locate kernel owned arithmetic functions in L1 Memory" > default y > help > If enabled arithmetic functions are linked > - into L1 instruction memory.(less latency) > + into L1 instruction memory. (less latency) > > config ACCESS_OK_L1 > bool "Locate access_ok function in L1 Memory" > default y > help > - If enabled access_ok function is linked > - into L1 instruction memory.(less latency) > + If enabled, the access_ok function is linked > + into L1 instruction memory. (less latency) > > config MEMSET_L1 > bool "Locate memset function in L1 Memory" > default y > help > - If enabled memset function is linked > - into L1 instruction memory.(less latency) > + If enabled, the memset function is linked > + into L1 instruction memory. (less latency) > > config MEMCPY_L1 > bool "Locate memcpy function in L1 Memory" > default y > help > - If enabled memcpy function is linked > - into L1 instruction memory.(less latency) > + If enabled, the m
Re: [PATCH] 2.6.21-git15 - Kconfig Cleanup
ping? On Fri, 11 May 2007 22:05:01 -0400 Matt LaPlante [EMAIL PROTECTED] wrote: Fix misc small issues/typos/grammar in Kconfigs for 2.6.21-git15. Signed-off-by: Matt LaPlante [EMAIL PROTECTED] -- diff -ru a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig --- a/arch/arm/plat-s3c24xx/Kconfig 2007-04-25 23:08:32.0 -0400 +++ b/arch/arm/plat-s3c24xx/Kconfig 2007-05-11 21:44:06.0 -0400 @@ -70,7 +70,7 @@ help Set the chunksize in Kilobytes of the CRC for checking memory corruption over suspend and resume. A smaller value will mean that - the CRC data block will take more memory, but wil identify any + the CRC data block will take more memory, but will identify any faults with better precision. See file:Documentation/arm/Samsung-S3C24XX/Suspend.txt diff -ru a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig --- a/arch/blackfin/Kconfig 2007-05-11 20:32:24.0 -0400 +++ b/arch/blackfin/Kconfig 2007-05-11 21:33:28.0 -0400 @@ -435,100 +435,100 @@ default y help If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked - into L1 instruction memory.(less latency) + into L1 instruction memory. (less latency) config EXCPT_IRQ_SYSC_L1 - bool Locate entire ASM lowlevel excepetion / interrupt - Syscall and CPLB handler code in L1 Memory + bool Locate entire ASM lowlevel exception / interrupt - Syscall and CPLB handler code in L1 Memory default y help - If enabled entire ASM lowlevel exception and interrupt entry code (STORE/RESTORE CONTEXT) is linked - into L1 instruction memory.(less latency) + If enabled, the entire ASM lowlevel exception and interrupt entry code + (STORE/RESTORE CONTEXT) is linked into L1 instruction memory. (less latency) config DO_IRQ_L1 bool Locate frequently called do_irq dispatcher function in L1 Memory default y help - If enabled frequently called do_irq dispatcher function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called do_irq dispatcher function is linked + into L1 instruction memory. (less latency) config CORE_TIMER_IRQ_L1 bool Locate frequently called timer_interrupt() function in L1 Memory default y help - If enabled frequently called timer_interrupt() function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called timer_interrupt() function is linked + into L1 instruction memory. (less latency) config IDLE_L1 bool Locate frequently idle function in L1 Memory default y help - If enabled frequently called idle function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called idle function is linked + into L1 instruction memory. (less latency) config SCHEDULE_L1 bool Locate kernel schedule function in L1 Memory default y help - If enabled frequently called kernel schedule is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called kernel schedule is linked + into L1 instruction memory. (less latency) config ARITHMETIC_OPS_L1 bool Locate kernel owned arithmetic functions in L1 Memory default y help If enabled arithmetic functions are linked - into L1 instruction memory.(less latency) + into L1 instruction memory. (less latency) config ACCESS_OK_L1 bool Locate access_ok function in L1 Memory default y help - If enabled access_ok function is linked - into L1 instruction memory.(less latency) + If enabled, the access_ok function is linked + into L1 instruction memory. (less latency) config MEMSET_L1 bool Locate memset function in L1 Memory default y help - If enabled memset function is linked - into L1 instruction memory.(less latency) + If enabled, the memset function is linked + into L1 instruction memory. (less latency) config MEMCPY_L1 bool Locate memcpy function in L1 Memory default y help - If enabled memcpy function is linked - into L1 instruction memory.(less latency) + If enabled, the memcpy function is linked + into L1 instruction memory. (less latency) config SYS_BFIN_SPINLOCK_L1 bool Locate sys_bfin_spinlock function in L1 Memory default y help - If enabled sys_bfin_spinlock function is linked - into L1 instruction memory.(less latency) + If enabled, the sys_bfin_spinlock function is linked + into L1 instruction memory. (less latency) config IP_CHECKSUM_L1 bool Locate IP Checksum function in L1 Memory default n help
Re: [PATCH] 2.6.21-git15 - Kconfig Cleanup
On Fri, 18 May 2007 20:01:54 +0200 Adrian Bunk [EMAIL PROTECTED] wrote: On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote: ping? Noone disagreed, and trivial patches will be forwarded again during the 2.6.23 merge window. Ok, I didn't know it would be acceptable without an ack from someone... (is Randy on vacation? :) I know we've discussed the logic behind trivial merges going in prior to RC candidates, and generally I think it's sound enough (we don't want to disrupt the merging of patches that actually matter, etc). I don't want to create a redundant conversation here, but I'm compelled to ask for opinions on this... I think the Kconfigs are a fairly prominent kernel feature, and would expect a lot of systems people will be seeing them when the new version goes final. That also means that a lot more people will be seeing the trivial errors in spelling or grammar that are being left in until the next version. In this round, for example, the new blackfin entries were really in need of some love. I don't really know how many people will report such things, or submit duplicate patches for them before we actually get to the next kernel cycle, but it seems like a waste to me. I don't really care so much about fixes to the Documentation texts or source comments because, in my estimation, they probably have a much smaller audience than the kernel configuration interface. I guess I'm just more sensitive to the presentation aspects of a project than the average developer, but I can't help feel it's a shame when we're willing to show the public such an unpolished face in a final product. To me, good code is taken down a notch by haphazard presentation. Thoughts? Cheers, Matt cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- Matt LaPlante CCNP, CCDP, A+, Linux+, CQS [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.6.21-git15 - Kconfig Cleanup
Fix misc small issues/typos/grammar in Kconfigs for 2.6.21-git15. Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]> -- diff -ru a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig --- a/arch/arm/plat-s3c24xx/Kconfig 2007-04-25 23:08:32.0 -0400 +++ b/arch/arm/plat-s3c24xx/Kconfig 2007-05-11 21:44:06.0 -0400 @@ -70,7 +70,7 @@ help Set the chunksize in Kilobytes of the CRC for checking memory corruption over suspend and resume. A smaller value will mean that - the CRC data block will take more memory, but wil identify any + the CRC data block will take more memory, but will identify any faults with better precision. See diff -ru a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig --- a/arch/blackfin/Kconfig 2007-05-11 20:32:24.0 -0400 +++ b/arch/blackfin/Kconfig 2007-05-11 21:33:28.0 -0400 @@ -435,100 +435,100 @@ default y help If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked - into L1 instruction memory.(less latency) + into L1 instruction memory. (less latency) config EXCPT_IRQ_SYSC_L1 - bool "Locate entire ASM lowlevel excepetion / interrupt - Syscall and CPLB handler code in L1 Memory" + bool "Locate entire ASM lowlevel exception / interrupt - Syscall and CPLB handler code in L1 Memory" default y help - If enabled entire ASM lowlevel exception and interrupt entry code (STORE/RESTORE CONTEXT) is linked - into L1 instruction memory.(less latency) + If enabled, the entire ASM lowlevel exception and interrupt entry code + (STORE/RESTORE CONTEXT) is linked into L1 instruction memory. (less latency) config DO_IRQ_L1 bool "Locate frequently called do_irq dispatcher function in L1 Memory" default y help - If enabled frequently called do_irq dispatcher function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called do_irq dispatcher function is linked + into L1 instruction memory. (less latency) config CORE_TIMER_IRQ_L1 bool "Locate frequently called timer_interrupt() function in L1 Memory" default y help - If enabled frequently called timer_interrupt() function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called timer_interrupt() function is linked + into L1 instruction memory. (less latency) config IDLE_L1 bool "Locate frequently idle function in L1 Memory" default y help - If enabled frequently called idle function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called idle function is linked + into L1 instruction memory. (less latency) config SCHEDULE_L1 bool "Locate kernel schedule function in L1 Memory" default y help - If enabled frequently called kernel schedule is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called kernel schedule is linked + into L1 instruction memory. (less latency) config ARITHMETIC_OPS_L1 bool "Locate kernel owned arithmetic functions in L1 Memory" default y help If enabled arithmetic functions are linked - into L1 instruction memory.(less latency) + into L1 instruction memory. (less latency) config ACCESS_OK_L1 bool "Locate access_ok function in L1 Memory" default y help - If enabled access_ok function is linked - into L1 instruction memory.(less latency) + If enabled, the access_ok function is linked + into L1 instruction memory. (less latency) config MEMSET_L1 bool "Locate memset function in L1 Memory" default y help - If enabled memset function is linked - into L1 instruction memory.(less latency) + If enabled, the memset function is linked + into L1 instruction memory. (less latency) config MEMCPY_L1 bool "Locate memcpy function in L1 Memory" default y help - If enabled memcpy function is linked - into L1 instruction memory.(less latency) + If enabled, the memcpy function is linked + into L1 instruction memory. (less latency) config SYS_BFIN_SPINLOCK_L1 bool "Locate sys_bfin_spinlock function in L1 Memory" default y help - If enabled sys_bfin_spinlock function is linked - into L1 instruction memory.(less latency) + If enabled, the sys_bfin_spinlock function is linked + into L1 instruction memory. (less latency) config IP_CHECKSUM_L1 bool "Loc
[PATCH] 2.6.21-git15 - Kconfig Cleanup
Fix misc small issues/typos/grammar in Kconfigs for 2.6.21-git15. Signed-off-by: Matt LaPlante [EMAIL PROTECTED] -- diff -ru a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig --- a/arch/arm/plat-s3c24xx/Kconfig 2007-04-25 23:08:32.0 -0400 +++ b/arch/arm/plat-s3c24xx/Kconfig 2007-05-11 21:44:06.0 -0400 @@ -70,7 +70,7 @@ help Set the chunksize in Kilobytes of the CRC for checking memory corruption over suspend and resume. A smaller value will mean that - the CRC data block will take more memory, but wil identify any + the CRC data block will take more memory, but will identify any faults with better precision. See file:Documentation/arm/Samsung-S3C24XX/Suspend.txt diff -ru a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig --- a/arch/blackfin/Kconfig 2007-05-11 20:32:24.0 -0400 +++ b/arch/blackfin/Kconfig 2007-05-11 21:33:28.0 -0400 @@ -435,100 +435,100 @@ default y help If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked - into L1 instruction memory.(less latency) + into L1 instruction memory. (less latency) config EXCPT_IRQ_SYSC_L1 - bool Locate entire ASM lowlevel excepetion / interrupt - Syscall and CPLB handler code in L1 Memory + bool Locate entire ASM lowlevel exception / interrupt - Syscall and CPLB handler code in L1 Memory default y help - If enabled entire ASM lowlevel exception and interrupt entry code (STORE/RESTORE CONTEXT) is linked - into L1 instruction memory.(less latency) + If enabled, the entire ASM lowlevel exception and interrupt entry code + (STORE/RESTORE CONTEXT) is linked into L1 instruction memory. (less latency) config DO_IRQ_L1 bool Locate frequently called do_irq dispatcher function in L1 Memory default y help - If enabled frequently called do_irq dispatcher function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called do_irq dispatcher function is linked + into L1 instruction memory. (less latency) config CORE_TIMER_IRQ_L1 bool Locate frequently called timer_interrupt() function in L1 Memory default y help - If enabled frequently called timer_interrupt() function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called timer_interrupt() function is linked + into L1 instruction memory. (less latency) config IDLE_L1 bool Locate frequently idle function in L1 Memory default y help - If enabled frequently called idle function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called idle function is linked + into L1 instruction memory. (less latency) config SCHEDULE_L1 bool Locate kernel schedule function in L1 Memory default y help - If enabled frequently called kernel schedule is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called kernel schedule is linked + into L1 instruction memory. (less latency) config ARITHMETIC_OPS_L1 bool Locate kernel owned arithmetic functions in L1 Memory default y help If enabled arithmetic functions are linked - into L1 instruction memory.(less latency) + into L1 instruction memory. (less latency) config ACCESS_OK_L1 bool Locate access_ok function in L1 Memory default y help - If enabled access_ok function is linked - into L1 instruction memory.(less latency) + If enabled, the access_ok function is linked + into L1 instruction memory. (less latency) config MEMSET_L1 bool Locate memset function in L1 Memory default y help - If enabled memset function is linked - into L1 instruction memory.(less latency) + If enabled, the memset function is linked + into L1 instruction memory. (less latency) config MEMCPY_L1 bool Locate memcpy function in L1 Memory default y help - If enabled memcpy function is linked - into L1 instruction memory.(less latency) + If enabled, the memcpy function is linked + into L1 instruction memory. (less latency) config SYS_BFIN_SPINLOCK_L1 bool Locate sys_bfin_spinlock function in L1 Memory default y help - If enabled sys_bfin_spinlock function is linked - into L1 instruction memory.(less latency) + If enabled, the sys_bfin_spinlock function is linked + into L1 instruction memory. (less latency) config IP_CHECKSUM_L1 bool Locate IP Checksum function in L1 Memory default n help - If enabled IP Checksum
Re: [PATCH 21-rc4] misc doc and kconfig typos
On Sat, 17 Mar 2007 21:59:03 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Sat, 17 Mar 2007 14:44:51 -0400 Matt LaPlante wrote: > > > Fix various typos in kernel docs and Kconfigs, 2.6.21-rc4. > > > > Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]> > > Acked-by: Randy Dunlap <[EMAIL PROTECTED]> > > Thanks, Matt. > > BTW, I would prefer to see doc and kconfig patches in separate > files. Anyone else pro or con on that? > Sorry bout that... fwiw I'm usually more organized, but the doc fixes in this patch were leftover from a patch I never submitted a couple versions ago so I tossed them in. > --- > ~Randy > *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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 21-rc4] misc doc and kconfig typos
On Sat, 17 Mar 2007 21:59:03 -0700 Randy Dunlap [EMAIL PROTECTED] wrote: On Sat, 17 Mar 2007 14:44:51 -0400 Matt LaPlante wrote: Fix various typos in kernel docs and Kconfigs, 2.6.21-rc4. Signed-off-by: Matt LaPlante [EMAIL PROTECTED] Acked-by: Randy Dunlap [EMAIL PROTECTED] Thanks, Matt. BTW, I would prefer to see doc and kconfig patches in separate files. Anyone else pro or con on that? Sorry bout that... fwiw I'm usually more organized, but the doc fixes in this patch were leftover from a patch I never submitted a couple versions ago so I tossed them in. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 21-rc4] misc doc and kconfig typos
Fix various typos in kernel docs and Kconfigs, 2.6.21-rc4. Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]> -- diff -ru a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig --- a/arch/arm/mach-at91/Kconfig2007-03-17 13:20:34.0 -0400 +++ b/arch/arm/mach-at91/Kconfig2007-03-17 13:37:28.0 -0400 @@ -100,7 +100,7 @@ depends on ARCH_AT91SAM9260 help Select this if you are using Atmel's AT91SAM9XE System-on-Chip. - They are basicaly AT91SAM9260s with various sizes of embedded Flash. + They are basically AT91SAM9260s with various sizes of embedded Flash. comment "AT91SAM9260 / AT91SAM9XE Board Type" diff -ru a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig --- a/arch/arm/mach-omap1/Kconfig 2007-02-04 13:44:54.0 -0500 +++ b/arch/arm/mach-omap1/Kconfig 2007-03-17 13:45:35.0 -0400 @@ -84,7 +84,7 @@ Support for the Palm Tungsten E PDA. Currently only the LCD panel is supported. To boot the kernel, you'll need a PalmOS compatible bootloader; check out http://palmtelinux.sourceforge.net for more - informations. + information. Say Y here if you have such a PDA, say NO otherwise. config MACH_NOKIA770 Only in b/arch/cris/arch-v10/drivers: eeprom.c.rej diff -ru a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig --- a/arch/powerpc/Kconfig 2007-03-17 13:20:35.0 -0400 +++ b/arch/powerpc/Kconfig 2007-03-17 13:47:58.0 -0400 @@ -625,7 +625,7 @@ depends PPC_IBM_CELL_BLADE help PMI (Platform Management Interrupt) is a way to - communicate with the BMC (Baseboard Mangement Controller). + communicate with the BMC (Baseboard Management Controller). It is used in some IBM Cell blades. default m diff -ru a/Documentation/block/ioprio.txt b/Documentation/block/ioprio.txt --- a/Documentation/block/ioprio.txt2007-02-04 13:44:54.0 -0500 +++ b/Documentation/block/ioprio.txt2007-03-17 14:21:29.0 -0400 @@ -6,10 +6,10 @@ - With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io -priorities is supported for reads on files. This enables users to io nice -processes or process groups, similar to what has been possible to cpu -scheduling for ages. This document mainly details the current possibilites -with cfq, other io schedulers do not support io priorities so far. +priorities are supported for reads on files. This enables users to io nice +processes or process groups, similar to what has been possible with cpu +scheduling for ages. This document mainly details the current possibilities +with cfq; other io schedulers do not support io priorities thus far. Scheduling classes -- diff -ru a/Documentation/cpu-freq/cpufreq-stats.txt b/Documentation/cpu-freq/cpufreq-stats.txt --- a/Documentation/cpu-freq/cpufreq-stats.txt 2007-02-04 13:44:54.0 -0500 +++ b/Documentation/cpu-freq/cpufreq-stats.txt 2007-03-17 13:33:57.0 -0400 @@ -17,7 +17,7 @@ 1. Introduction -cpufreq-stats is a driver that provices CPU frequency statistics for each CPU. +cpufreq-stats is a driver that provides CPU frequency statistics for each CPU. These statistics are provided in /sysfs as a bunch of read_only interfaces. This interface (when configured) will appear in a separate directory under cpufreq in /sysfs (/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU. diff -ru a/Documentation/driver-model/platform.txt b/Documentation/driver-model/platform.txt --- a/Documentation/driver-model/platform.txt 2007-03-17 13:20:34.0 -0400 +++ b/Documentation/driver-model/platform.txt 2007-03-17 13:33:57.0 -0400 @@ -16,7 +16,7 @@ into system-on-chip platforms. What they usually have in common is direct addressing from a CPU bus. Rarely, a platform_device will be connected through a segment of some other kind of bus; but its -registers will still be directly addressible. +registers will still be directly addressable. Platform devices are given a name, used in driver binding, and a list of resources such as addresses and IRQs. diff -ru a/Documentation/fb/imacfb.txt b/Documentation/fb/imacfb.txt --- a/Documentation/fb/imacfb.txt 2007-02-04 13:44:54.0 -0500 +++ b/Documentation/fb/imacfb.txt 2007-03-17 13:33:57.0 -0400 @@ -17,7 +17,7 @@ == Imacfb does not have any kind of autodetection of your machine. -You have to add the fillowing kernel parameters in your elilo.conf: +You have to add the following kernel parameters in your elilo.conf: Macbook : video=imacfb:macbook MacMini : diff -ru a/Documentation/filesystems/hpfs.txt b/Documentation/filesystems/hpfs.txt --- a/Documentation/filesystems/hpfs.txt2007-02-04 13:44:54.0 -0500 +++ b/Documentation/filesystems/hpfs.txt2007-03-17 13:33:57.
[PATCH 21-rc4] misc doc and kconfig typos
Fix various typos in kernel docs and Kconfigs, 2.6.21-rc4. Signed-off-by: Matt LaPlante [EMAIL PROTECTED] -- diff -ru a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig --- a/arch/arm/mach-at91/Kconfig2007-03-17 13:20:34.0 -0400 +++ b/arch/arm/mach-at91/Kconfig2007-03-17 13:37:28.0 -0400 @@ -100,7 +100,7 @@ depends on ARCH_AT91SAM9260 help Select this if you are using Atmel's AT91SAM9XE System-on-Chip. - They are basicaly AT91SAM9260s with various sizes of embedded Flash. + They are basically AT91SAM9260s with various sizes of embedded Flash. comment AT91SAM9260 / AT91SAM9XE Board Type diff -ru a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig --- a/arch/arm/mach-omap1/Kconfig 2007-02-04 13:44:54.0 -0500 +++ b/arch/arm/mach-omap1/Kconfig 2007-03-17 13:45:35.0 -0400 @@ -84,7 +84,7 @@ Support for the Palm Tungsten E PDA. Currently only the LCD panel is supported. To boot the kernel, you'll need a PalmOS compatible bootloader; check out http://palmtelinux.sourceforge.net for more - informations. + information. Say Y here if you have such a PDA, say NO otherwise. config MACH_NOKIA770 Only in b/arch/cris/arch-v10/drivers: eeprom.c.rej diff -ru a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig --- a/arch/powerpc/Kconfig 2007-03-17 13:20:35.0 -0400 +++ b/arch/powerpc/Kconfig 2007-03-17 13:47:58.0 -0400 @@ -625,7 +625,7 @@ depends PPC_IBM_CELL_BLADE help PMI (Platform Management Interrupt) is a way to - communicate with the BMC (Baseboard Mangement Controller). + communicate with the BMC (Baseboard Management Controller). It is used in some IBM Cell blades. default m diff -ru a/Documentation/block/ioprio.txt b/Documentation/block/ioprio.txt --- a/Documentation/block/ioprio.txt2007-02-04 13:44:54.0 -0500 +++ b/Documentation/block/ioprio.txt2007-03-17 14:21:29.0 -0400 @@ -6,10 +6,10 @@ - With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io -priorities is supported for reads on files. This enables users to io nice -processes or process groups, similar to what has been possible to cpu -scheduling for ages. This document mainly details the current possibilites -with cfq, other io schedulers do not support io priorities so far. +priorities are supported for reads on files. This enables users to io nice +processes or process groups, similar to what has been possible with cpu +scheduling for ages. This document mainly details the current possibilities +with cfq; other io schedulers do not support io priorities thus far. Scheduling classes -- diff -ru a/Documentation/cpu-freq/cpufreq-stats.txt b/Documentation/cpu-freq/cpufreq-stats.txt --- a/Documentation/cpu-freq/cpufreq-stats.txt 2007-02-04 13:44:54.0 -0500 +++ b/Documentation/cpu-freq/cpufreq-stats.txt 2007-03-17 13:33:57.0 -0400 @@ -17,7 +17,7 @@ 1. Introduction -cpufreq-stats is a driver that provices CPU frequency statistics for each CPU. +cpufreq-stats is a driver that provides CPU frequency statistics for each CPU. These statistics are provided in /sysfs as a bunch of read_only interfaces. This interface (when configured) will appear in a separate directory under cpufreq in /sysfs (sysfs root/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU. diff -ru a/Documentation/driver-model/platform.txt b/Documentation/driver-model/platform.txt --- a/Documentation/driver-model/platform.txt 2007-03-17 13:20:34.0 -0400 +++ b/Documentation/driver-model/platform.txt 2007-03-17 13:33:57.0 -0400 @@ -16,7 +16,7 @@ into system-on-chip platforms. What they usually have in common is direct addressing from a CPU bus. Rarely, a platform_device will be connected through a segment of some other kind of bus; but its -registers will still be directly addressible. +registers will still be directly addressable. Platform devices are given a name, used in driver binding, and a list of resources such as addresses and IRQs. diff -ru a/Documentation/fb/imacfb.txt b/Documentation/fb/imacfb.txt --- a/Documentation/fb/imacfb.txt 2007-02-04 13:44:54.0 -0500 +++ b/Documentation/fb/imacfb.txt 2007-03-17 13:33:57.0 -0400 @@ -17,7 +17,7 @@ == Imacfb does not have any kind of autodetection of your machine. -You have to add the fillowing kernel parameters in your elilo.conf: +You have to add the following kernel parameters in your elilo.conf: Macbook : video=imacfb:macbook MacMini : diff -ru a/Documentation/filesystems/hpfs.txt b/Documentation/filesystems/hpfs.txt --- a/Documentation/filesystems/hpfs.txt2007-02-04 13:44:54.0 -0500 +++ b/Documentation/filesystems/hpfs.txt2007-03-17 13:33:57.0
RE: Fw: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13
Patch worked like a charm here, no more kernel panics! Excellent work, many
thanks for the quick fix...more people should have such a work ethic.
Cheers,
Matt
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-kernel-
> [EMAIL PROTECTED] On Behalf Of Herbert Xu
> Sent: Tuesday, September 06, 2005 8:20 AM
> To: Andrew Morton
> Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> bugs.osdl.org; Matt LaPlante; Linux Kernel Mailing List; David S. Miller
> Subject: Re: Fw: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13
>
> On Tue, Sep 06, 2005 at 04:08:56AM -0700, Andrew Morton wrote:
> >
> > Problem Description:
> >
> > Oops: [#1]
> > PREEMPT
> > Modules linked in:
> > CPU:0
> > EIP:0060:[]Not tainted VLI
> > EFLAGS: 00010216 (2.6.13)
> > EIP is at sha1_update+0x7c/0x160
>
> Thanks for the report. Matt LaPlante had exactly the same problem
> a couple of days ago. I've tracked down now to my broken crypto
> cipher wrapper functions which will step over a page boundary if
> it's not aligned correctly.
>
>
> [CRYPTO] Fix boundary check in standard multi-block cipher processors
>
> The boundary check in the standard multi-block cipher processors are
> broken when nbytes is not a multiple of bsize. In those cases it will
> always process an extra block.
>
> This patch corrects the check so that it processes at most nbytes of data.
>
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Fw: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13
Patch worked like a charm here, no more kernel panics! Excellent work, many
thanks for the quick fix...more people should have such a work ethic.
Cheers,
Matt
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-kernel-
[EMAIL PROTECTED] On Behalf Of Herbert Xu
Sent: Tuesday, September 06, 2005 8:20 AM
To: Andrew Morton
Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
bugs.osdl.org; Matt LaPlante; Linux Kernel Mailing List; David S. Miller
Subject: Re: Fw: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13
On Tue, Sep 06, 2005 at 04:08:56AM -0700, Andrew Morton wrote:
Problem Description:
Oops: [#1]
PREEMPT
Modules linked in:
CPU:0
EIP:0060:[c01f562c]Not tainted VLI
EFLAGS: 00010216 (2.6.13)
EIP is at sha1_update+0x7c/0x160
Thanks for the report. Matt LaPlante had exactly the same problem
a couple of days ago. I've tracked down now to my broken crypto
cipher wrapper functions which will step over a page boundary if
it's not aligned correctly.
[CRYPTO] Fix boundary check in standard multi-block cipher processors
The boundary check in the standard multi-block cipher processors are
broken when nbytes is not a multiple of bsize. In those cases it will
always process an extra block.
This patch corrects the check so that it processes at most nbytes of data.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Potential IPSec DoS/Kernel Panic with 2.6.13
I did a direct serial connection and boy was that a lot easier. Anyway,
without further adeu, the crash:
#
Unable to handle kernel paging request at virtual address 50c86502
printing eip:
c01bd216
*pde =
Oops: [#1]
PREEMPT
Modules linked in: aes_i586 esp6 ah6 ipcomp esp4 ah4 af_key xfrm_user
michael_mic deflate twofish khazad wp512 arc4 serpent tea sha512 blowfish
sha256 md5 md4 cast6 cast5 des crypto_null zlib_deflate ipv6 ipt_ULOG
ipt_REJECT ipt_LOG ipt_state ipt_pkttype ipt_CONNMARK ipt_connmark ipt_owner
ipt_recent ipt_iprange ipt_multiport ip_nat_irc ip_nat_tftp ip_conntrack_irc
ip_conntrack_tftp evdev floppy pcspkr intel_agp via_rhine mii tulip agpgart
psmouse ide_cd cdrom
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010216 (2.6.13-Firewall.CyberDog.v12)
EIP is at sha1_update+0x96/0xe0
eax: cd485f0c ebx: 000c ecx: 0003 edx: 0244
esi: 50c86502 edi: cd485f5c ebp: 50c86502 esp: c0333c40
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c0332000 task=c02edb80)
Stack: 0244 cd485f0c
Call Trace:
[] update+0x91/0xd0
[] crypto_hmac_update+0x11/0x20
[] skb_icv_walk+0xe3/0x200
[] esp_hmac_digest+0x63/0xa0 [esp4]
[] crypto_hmac_update+0x0/0x20
[] cbc_encrypt+0x44/0x50
[] esp_output+0x350/0x420 [esp4]
[] xfrm4_output+0x70/0x170
[] ip_forward_finish+0x0/0x40
[] ip_forward+0x16f/0x2c0
[] ip_forward_finish+0x0/0x40
[] ip_rcv+0x365/0x4d0
[] ip_rcv_finish+0x0/0x280
[] packet_rcv_spkt+0x186/0x260
[] tulip_poll+0x0/0x680 [tulip]
[] netif_receive_skb+0x1a9/0x260
[] tulip_poll+0x465/0x680 [tulip]
[] rhine_interrupt+0x42/0x240 [via_rhine]
[] net_rx_action+0xac/0x1b0
[] __do_softirq+0x79/0x90
[] do_softirq+0x27/0x30
[] irq_exit+0x35/0x40
[] do_IRQ+0x1e/0x30
[] common_interrupt+0x1a/0x20
[] default_idle+0x0/0x30
[] default_idle+0x23/0x30
[] cpu_idle+0x50/0x60
[] start_kernel+0x177/0x1c0
[] unknown_bootoption+0x0/0x1c0
Code: 83 e1 03 74 02 f3 a4 81 c4 48 01 00 00 5b 5e 5f 5d c3 8d 76 00 8b 44
24 04 bb 40 00 00 00 29 f3 89 d9 8d 7c 06 1c 89 ee c1 e9 02 a5 89 d9 83
e1 03 74 02 f3 a4 89 c6 8d 7c 24 08 89 c2 83 c6
<0>Kernel panic - not syncing: Fatal exception in interrupt
#
Hope that helps! If you need more info just ask!
-
Matt
-
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: Potential IPSec DoS/Kernel Panic with 2.6.13
> -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-kernel- > [EMAIL PROTECTED] On Behalf Of Jesper Juhl > Sent: Sunday, September 04, 2005 2:49 PM > To: Matt LaPlante > Cc: Herbert Xu; linux-kernel@vger.kernel.org > Subject: Re: Potential IPSec DoS/Kernel Panic with 2.6.13 > > > > serial console over a cross-over cable to a second box. > netconsole will let you put the console on a different box over the > network. > console on line printer will let you have a permanent record of the > console output on paper. > > See > Documentation/serial-console.txt > Documentation/networking/netconsole.txt > the help entry for "config LP_CONSOLE" (in drivers/char/Kconfig) > Well I've tried for several hours now to get netconsole working, but it just won't give me output. I've tried using both built in as well as module, and I've tried two different clients using both netcat and syslogd on different ports. The most output I ever get is when loading the module I manage to receive one message saying "netconsole: network logging started". I've verified all the netconsole settings are correct in the kernel logs when it loads. I'm not one to give up easily, but this one's got me stumped. I know the option to use a printer is out...I might be able to manage a serial connection, but I'll have to rebuild my kernel to support it. I'll look into that later... - Matt - 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: Potential IPSec DoS/Kernel Panic with 2.6.13
> -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-kernel- > [EMAIL PROTECTED] On Behalf Of Herbert Xu > Sent: Sunday, September 04, 2005 4:24 AM > To: Matt LaPlante > Cc: linux-kernel@vger.kernel.org > Subject: Re: Potential IPSec DoS/Kernel Panic with 2.6.13 > > Matt LaPlante <[EMAIL PROTECTED]> wrote: > > > > network connectivity on my router. Upon further inspection I noticed > the > > packet had actually caused a kernel panic (visible only on the monitor, > now > > also unresponsive). > > Thanks for the report. I'll try to track it down. > > If you could jot down the important bits of the panic message > (IP, Call-Trace) it would help me find the problem much quicker. I'd be more than happy to help you track this one down. The problem here is that the panic scrolls up and off the screen after which the system is unusable. Is there a way for me to capture it or redirect it somewhere that I can read it? I can also include my kernel config or any other system details of interest. Thanks. - Matt - 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: Potential IPSec DoS/Kernel Panic with 2.6.13
-Original Message- From: [EMAIL PROTECTED] [mailto:linux-kernel- [EMAIL PROTECTED] On Behalf Of Herbert Xu Sent: Sunday, September 04, 2005 4:24 AM To: Matt LaPlante Cc: linux-kernel@vger.kernel.org Subject: Re: Potential IPSec DoS/Kernel Panic with 2.6.13 Matt LaPlante [EMAIL PROTECTED] wrote: network connectivity on my router. Upon further inspection I noticed the packet had actually caused a kernel panic (visible only on the monitor, now also unresponsive). Thanks for the report. I'll try to track it down. If you could jot down the important bits of the panic message (IP, Call-Trace) it would help me find the problem much quicker. I'd be more than happy to help you track this one down. The problem here is that the panic scrolls up and off the screen after which the system is unusable. Is there a way for me to capture it or redirect it somewhere that I can read it? I can also include my kernel config or any other system details of interest. Thanks. - Matt - 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: Potential IPSec DoS/Kernel Panic with 2.6.13
-Original Message- From: [EMAIL PROTECTED] [mailto:linux-kernel- [EMAIL PROTECTED] On Behalf Of Jesper Juhl Sent: Sunday, September 04, 2005 2:49 PM To: Matt LaPlante Cc: Herbert Xu; linux-kernel@vger.kernel.org Subject: Re: Potential IPSec DoS/Kernel Panic with 2.6.13 serial console over a cross-over cable to a second box. netconsole will let you put the console on a different box over the network. console on line printer will let you have a permanent record of the console output on paper. See Documentation/serial-console.txt Documentation/networking/netconsole.txt the help entry for config LP_CONSOLE (in drivers/char/Kconfig) Well I've tried for several hours now to get netconsole working, but it just won't give me output. I've tried using both built in as well as module, and I've tried two different clients using both netcat and syslogd on different ports. The most output I ever get is when loading the module I manage to receive one message saying netconsole: network logging started. I've verified all the netconsole settings are correct in the kernel logs when it loads. I'm not one to give up easily, but this one's got me stumped. I know the option to use a printer is out...I might be able to manage a serial connection, but I'll have to rebuild my kernel to support it. I'll look into that later... - Matt - 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: Potential IPSec DoS/Kernel Panic with 2.6.13
I did a direct serial connection and boy was that a lot easier. Anyway,
without further adeu, the crash:
#
Unable to handle kernel paging request at virtual address 50c86502
printing eip:
c01bd216
*pde =
Oops: [#1]
PREEMPT
Modules linked in: aes_i586 esp6 ah6 ipcomp esp4 ah4 af_key xfrm_user
michael_mic deflate twofish khazad wp512 arc4 serpent tea sha512 blowfish
sha256 md5 md4 cast6 cast5 des crypto_null zlib_deflate ipv6 ipt_ULOG
ipt_REJECT ipt_LOG ipt_state ipt_pkttype ipt_CONNMARK ipt_connmark ipt_owner
ipt_recent ipt_iprange ipt_multiport ip_nat_irc ip_nat_tftp ip_conntrack_irc
ip_conntrack_tftp evdev floppy pcspkr intel_agp via_rhine mii tulip agpgart
psmouse ide_cd cdrom
CPU:0
EIP:0060:[c01bd216]Not tainted VLI
EFLAGS: 00010216 (2.6.13-Firewall.CyberDog.v12)
EIP is at sha1_update+0x96/0xe0
eax: cd485f0c ebx: 000c ecx: 0003 edx: 0244
esi: 50c86502 edi: cd485f5c ebp: 50c86502 esp: c0333c40
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c0332000 task=c02edb80)
Stack: 0244 cd485f0c
Call Trace:
[c01bc881] update+0x91/0xd0
[c01bcf11] crypto_hmac_update+0x11/0x20
[c02a28c3] skb_icv_walk+0xe3/0x200
[d0aa5d23] esp_hmac_digest+0x63/0xa0 [esp4]
[c01bcf00] crypto_hmac_update+0x0/0x20
[c01bc524] cbc_encrypt+0x44/0x50
[d0aa5350] esp_output+0x350/0x420 [esp4]
[c029c920] xfrm4_output+0x70/0x170
[c0260510] ip_forward_finish+0x0/0x40
[c02603bf] ip_forward+0x16f/0x2c0
[c0260510] ip_forward_finish+0x0/0x40
[c025ed85] ip_rcv+0x365/0x4d0
[c025f0a0] ip_rcv_finish+0x0/0x280
[c02a67a6] packet_rcv_spkt+0x186/0x260
[d09e77f0] tulip_poll+0x0/0x680 [tulip]
[c0244ea9] netif_receive_skb+0x1a9/0x260
[d09e7c55] tulip_poll+0x465/0x680 [tulip]
[d09df692] rhine_interrupt+0x42/0x240 [via_rhine]
[c02450fc] net_rx_action+0xac/0x1b0
[c0119c19] __do_softirq+0x79/0x90
[c0119c57] do_softirq+0x27/0x30
[c0119d25] irq_exit+0x35/0x40
[c01047be] do_IRQ+0x1e/0x30
[c0102df2] common_interrupt+0x1a/0x20
[c0100bf0] default_idle+0x0/0x30
[c0100c13] default_idle+0x23/0x30
[c0100cb0] cpu_idle+0x50/0x60
[c0334787] start_kernel+0x177/0x1c0
[c0334340] unknown_bootoption+0x0/0x1c0
Code: 83 e1 03 74 02 f3 a4 81 c4 48 01 00 00 5b 5e 5f 5d c3 8d 76 00 8b 44
24 04 bb 40 00 00 00 29 f3 89 d9 8d 7c 06 1c 89 ee c1 e9 02 f3 a5 89 d9 83
e1 03 74 02 f3 a4 89 c6 8d 7c 24 08 89 c2 83 c6
0Kernel panic - not syncing: Fatal exception in interrupt
#
Hope that helps! If you need more info just ask!
-
Matt
-
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/
Potential IPSec DoS/Kernel Panic with 2.6.13
I've found what I believe is a potential DoS condition in IPSec using Debian but I need help isolating the culprit. First my system: Debian 3.1 stable with all updates as of 9/2. Custom Linux kernel 2.6.13 (no patches) IPTables 1.3.3 (no patches) Shorewall 2.4.3 I use my system as a multipurpose firewall/DHCP/DNS gateway on my broadband home connection. I have another system with the same specs on a remote network. Just recently I installed the racoon debian package on both machines and established an IPSec VPN tunnel between the two routers. All has worked generally as expected and I have connectivity between my local and remote LAN while having regular internet service running alongside. Here is my racoon-tool config: # # Configuration file for racoon-tool # # See racoon-tool.conf(5) for details # global: log: notify connection(test): src_range: 192.168.4.0/24 dst_range: 192.168.1.0/24 src_ip: A.B.C.D dst_ip: W.X.Y.Z authentication_algorithm: hmac_sha1 admin_status: yes peer(A.B.C.D): passive: off verify_identifier: on lifetime: time 30 min hash_algorithm[0]: sha1 encryption_algorithm[0]: aes my_identifier: address A.B.C.D peers_identifier: address W.X.Y.Z Now with this config, I can ping the remote LAN from my Win XP machine successfully using "ping -t -l 1024 192.168.1.2". I was just randomly messing around with some settings when I ran the following: "ping -t -l 2048 192.168.1.2" Now I'm well aware that this command won't likely succeed due to the excessive size of the packet (2048 bytes). What I wasn't expecting was that I would be totally and completely unable to access my router via SSH or have any internet connectivity. Yes, the oversize ping packet took down all the network connectivity on my router. Upon further inspection I noticed the packet had actually caused a kernel panic (visible only on the monitor, now also unresponsive). I shut down with a hard power down, rebooted, and tried again...with the dead same result. This oversize ping packet seems to repeatedly crash the system. I tried while booting the current Debian stock kernel (2.6.8-2-686), and this problem was NOT present. I think due to this, it is unlikely related to any supporting software on my system. I'm not sure where to proceed from here. I'd be glad to send in the kernel traces, but I don't know how to capture them...they aren't being logged anywhere that I can find, so I need to know how to capture them and submit them if they're necessary. I want to emphasize that this is somehow related to IPSec, as I tested the exact same command but substituted www.google.com for my remote LAN IP address and there were NO crashes/problems whatsoever. This bug seems to be a high threat because: -It occurs reproducibly. -It occurs in the latest kernel with *no* patches. -It did not occur with a previous kernel. -It causes a complete system failure. -It is extremely simple to exploit. I will gladly provide more details upon request. I'm not experienced enough at the low level system aspects to provide detailed debugging info from scratch, but I do have extensive experience with administering these systems so I can give any information necessary with a little guidance. Note: I'm trying posting this under a 2nd email address. I tried posting with my subscribed email address, but the post has not appeared on the list in 24 hours, even though I'm receiving posts normally. If it results in double posts I apologize. - Matt LaPlante - 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/
Potential IPSec DoS/Kernel Panic with 2.6.13
I've found what I believe is a potential DoS condition in IPSec using Debian but I need help isolating the culprit. First my system: Debian 3.1 stable with all updates as of 9/2. Custom Linux kernel 2.6.13 (no patches) IPTables 1.3.3 (no patches) Shorewall 2.4.3 I use my system as a multipurpose firewall/DHCP/DNS gateway on my broadband home connection. I have another system with the same specs on a remote network. Just recently I installed the racoon debian package on both machines and established an IPSec VPN tunnel between the two routers. All has worked generally as expected and I have connectivity between my local and remote LAN while having regular internet service running alongside. Here is my racoon-tool config: # # Configuration file for racoon-tool # # See racoon-tool.conf(5) for details # global: log: notify connection(test): src_range: 192.168.4.0/24 dst_range: 192.168.1.0/24 src_ip: A.B.C.D dst_ip: W.X.Y.Z authentication_algorithm: hmac_sha1 admin_status: yes peer(A.B.C.D): passive: off verify_identifier: on lifetime: time 30 min hash_algorithm[0]: sha1 encryption_algorithm[0]: aes my_identifier: address A.B.C.D peers_identifier: address W.X.Y.Z Now with this config, I can ping the remote LAN from my Win XP machine successfully using ping -t -l 1024 192.168.1.2. I was just randomly messing around with some settings when I ran the following: ping -t -l 2048 192.168.1.2 Now I'm well aware that this command won't likely succeed due to the excessive size of the packet (2048 bytes). What I wasn't expecting was that I would be totally and completely unable to access my router via SSH or have any internet connectivity. Yes, the oversize ping packet took down all the network connectivity on my router. Upon further inspection I noticed the packet had actually caused a kernel panic (visible only on the monitor, now also unresponsive). I shut down with a hard power down, rebooted, and tried again...with the dead same result. This oversize ping packet seems to repeatedly crash the system. I tried while booting the current Debian stock kernel (2.6.8-2-686), and this problem was NOT present. I think due to this, it is unlikely related to any supporting software on my system. I'm not sure where to proceed from here. I'd be glad to send in the kernel traces, but I don't know how to capture them...they aren't being logged anywhere that I can find, so I need to know how to capture them and submit them if they're necessary. I want to emphasize that this is somehow related to IPSec, as I tested the exact same command but substituted www.google.com for my remote LAN IP address and there were NO crashes/problems whatsoever. This bug seems to be a high threat because: -It occurs reproducibly. -It occurs in the latest kernel with *no* patches. -It did not occur with a previous kernel. -It causes a complete system failure. -It is extremely simple to exploit. I will gladly provide more details upon request. I'm not experienced enough at the low level system aspects to provide detailed debugging info from scratch, but I do have extensive experience with administering these systems so I can give any information necessary with a little guidance. Note: I'm trying posting this under a 2nd email address. I tried posting with my subscribed email address, but the post has not appeared on the list in 24 hours, even though I'm receiving posts normally. If it results in double posts I apologize. - Matt LaPlante - 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/
