Re: [patch V2 33/36] net: libertas: Use netif_rx_any_context()
On Tue, Sep 29, 2020 at 10:25:42PM +0200, Thomas Gleixner wrote: > From: Sebastian Andrzej Siewior > > The usage of in_interrupt() in non-core code is phased out. Ideally the > information of the calling context should be passed by the callers or the > functions be split as appropriate. > > libertas uses in_interupt() to select the netif_rx*() variant which matches > the calling context. The attempt to consolidate the code by passing an > arguemnt or by distangling it failed due lack of knowledge about this > driver and because the call chains are hard to follow. > > As a stop gap use netif_rx_any_context() which invokes the correct code > path depending on context and confines the in_interrupt() usage to core > code. > > Signed-off-by: Sebastian Andrzej Siewior > Signed-off-by: Thomas Gleixner > Acked-by: Kalle Valo Reviewed-by: James Cameron -- James Cameron http://quozl.netrek.org/
Re: [PATCH v4 0/20] MMP platform fixes
On Sun, Dec 02, 2018 at 11:29:30PM +0100, Pavel Machek wrote: > Hi! > > > > > The patch set has been tested on an OLPC XO-1.75 laptop. > > > > > > Excellent! > > > > OOooh, I have one of those... somewhere. > > Time to find it :-). It is still pretty great machine, can last 8? > hours on battery, sunlight readable screen, and if you meet a tiger > you can hit him on the head with it ... and it is still likely to work > afterwards :-). Yes. Best configuration is with laptop closed, ears locked, firmly held by handle, and use the narrow side edge to hit with. Users have tried the large flat surface behind the display, but the display tends to fail after five to ten hits. It will depend on the tiger. -- James Cameron http://quozl.netrek.org/
Re: [PATCH v4 0/20] MMP platform fixes
On Sun, Dec 02, 2018 at 11:29:30PM +0100, Pavel Machek wrote: > Hi! > > > > > The patch set has been tested on an OLPC XO-1.75 laptop. > > > > > > Excellent! > > > > OOooh, I have one of those... somewhere. > > Time to find it :-). It is still pretty great machine, can last 8? > hours on battery, sunlight readable screen, and if you meet a tiger > you can hit him on the head with it ... and it is still likely to work > afterwards :-). Yes. Best configuration is with laptop closed, ears locked, firmly held by handle, and use the narrow side edge to hit with. Users have tried the large flat surface behind the display, but the display tends to fail after five to ten hits. It will depend on the tiger. -- James Cameron http://quozl.netrek.org/
Re: [PATCH 06/15] Platform: OLPC: Add XO-1.75 EC driver
it?
> >
> > > + return 0;
> > > +}
> > > +
> > > +static int olpc_xo175_ec_resume_noirq(struct device *dev)
> > > +{
> > > + struct platform_device *pdev = to_platform_device(dev);
> > > + struct olpc_xo175_ec *priv = platform_get_drvdata(pdev);
> > > +
> > > + priv->suspended = false;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int olpc_xo175_ec_resume(struct device *dev)
> > > +{
> > > + struct platform_device *pdev = to_platform_device(dev);
> > > + struct olpc_xo175_ec *priv = platform_get_drvdata(pdev);
> > > + unsigned char x = 0;
> >
> > u8
> >
> > > + priv->suspended = false;
> >
> > Isn't it redundant since noirq callback above?
> >
> > > + /*
> > > +* The resume hint is only needed if no other commands are
> > > +* being sent during resume. all it does is tell the EC
> > > +* the SoC is definitely awake.
> > > +*/
> > > + olpc_ec_cmd(CMD_SUSPEND_HINT, , 1, NULL, 0);
> > > +
> > > + /* Enable all EC events while we're awake */
> > > + olpc_xo175_ec_set_event_mask(0x);
> >
> > #define EC_ALL_EVENTS GENMASK(15, 0)
> >
> > > +}
> > > +#endif
> > > +static struct platform_device *olpc_ec;
> >
> > I would rather see this at the top of file.
> >
> > > +static int olpc_xo175_ec_probe(struct spi_device *spi)
> > > +{
> > > + if (olpc_ec) {
> > > + dev_err(>dev, "OLPC EC already
> > > registered.\n");
> > > + return -EBUSY;
> > > + }
> >
> > It's racy against parallel probe called. I don't think it would be a
> > real issue, just let you know.
> >
> >
> > > + /* Set up power button input device */
> > > + priv->pwrbtn = devm_input_allocate_device(>dev);
> > > + if (!priv->pwrbtn)
> > > + return -ENOMEM;
> > > + priv->pwrbtn->name = "Power Button";
> > > + priv->pwrbtn->dev.parent = >dev;
> > > + input_set_capability(priv->pwrbtn, EV_KEY, KEY_POWER);
> > > + ret = input_register_device(priv->pwrbtn);
> > > + if (ret) {
> > > + dev_err(>dev, "error registering input device:
> > > %d\n", ret);
> > > + return ret;
> > > + }
> >
> > I would split out power button driver, but it's up to you.
> >
> >
> > > + /* Enable all EC events while we're awake */
> > > + olpc_xo175_ec_set_event_mask(0x);
> >
> > See above about this magic.
> >
> > > +}
> > > +#ifdef CONFIG_PM
> > > + .suspend= olpc_xo175_ec_suspend,
> > > + .resume_noirq = olpc_xo175_ec_resume_noirq,
> > > + .resume = olpc_xo175_ec_resume,
> > > +#endif
> >
> > SET_SYSTEM_SLEEP_PM_OPS() ?
> > SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() ?
> >
> > > +static const struct of_device_id olpc_xo175_ec_of_match[] = {
> > > + { .compatible = "olpc,xo1.75-ec" },
> > > + { },
> >
> > No comma for terminators.
> >
> > > +};
>
> Thanks,
> Lubo
>
--
James Cameron
http://quozl.netrek.org/
Re: [PATCH 06/15] Platform: OLPC: Add XO-1.75 EC driver
it?
> >
> > > + return 0;
> > > +}
> > > +
> > > +static int olpc_xo175_ec_resume_noirq(struct device *dev)
> > > +{
> > > + struct platform_device *pdev = to_platform_device(dev);
> > > + struct olpc_xo175_ec *priv = platform_get_drvdata(pdev);
> > > +
> > > + priv->suspended = false;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int olpc_xo175_ec_resume(struct device *dev)
> > > +{
> > > + struct platform_device *pdev = to_platform_device(dev);
> > > + struct olpc_xo175_ec *priv = platform_get_drvdata(pdev);
> > > + unsigned char x = 0;
> >
> > u8
> >
> > > + priv->suspended = false;
> >
> > Isn't it redundant since noirq callback above?
> >
> > > + /*
> > > +* The resume hint is only needed if no other commands are
> > > +* being sent during resume. all it does is tell the EC
> > > +* the SoC is definitely awake.
> > > +*/
> > > + olpc_ec_cmd(CMD_SUSPEND_HINT, , 1, NULL, 0);
> > > +
> > > + /* Enable all EC events while we're awake */
> > > + olpc_xo175_ec_set_event_mask(0x);
> >
> > #define EC_ALL_EVENTS GENMASK(15, 0)
> >
> > > +}
> > > +#endif
> > > +static struct platform_device *olpc_ec;
> >
> > I would rather see this at the top of file.
> >
> > > +static int olpc_xo175_ec_probe(struct spi_device *spi)
> > > +{
> > > + if (olpc_ec) {
> > > + dev_err(>dev, "OLPC EC already
> > > registered.\n");
> > > + return -EBUSY;
> > > + }
> >
> > It's racy against parallel probe called. I don't think it would be a
> > real issue, just let you know.
> >
> >
> > > + /* Set up power button input device */
> > > + priv->pwrbtn = devm_input_allocate_device(>dev);
> > > + if (!priv->pwrbtn)
> > > + return -ENOMEM;
> > > + priv->pwrbtn->name = "Power Button";
> > > + priv->pwrbtn->dev.parent = >dev;
> > > + input_set_capability(priv->pwrbtn, EV_KEY, KEY_POWER);
> > > + ret = input_register_device(priv->pwrbtn);
> > > + if (ret) {
> > > + dev_err(>dev, "error registering input device:
> > > %d\n", ret);
> > > + return ret;
> > > + }
> >
> > I would split out power button driver, but it's up to you.
> >
> >
> > > + /* Enable all EC events while we're awake */
> > > + olpc_xo175_ec_set_event_mask(0x);
> >
> > See above about this magic.
> >
> > > +}
> > > +#ifdef CONFIG_PM
> > > + .suspend= olpc_xo175_ec_suspend,
> > > + .resume_noirq = olpc_xo175_ec_resume_noirq,
> > > + .resume = olpc_xo175_ec_resume,
> > > +#endif
> >
> > SET_SYSTEM_SLEEP_PM_OPS() ?
> > SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() ?
> >
> > > +static const struct of_device_id olpc_xo175_ec_of_match[] = {
> > > + { .compatible = "olpc,xo1.75-ec" },
> > > + { },
> >
> > No comma for terminators.
> >
> > > +};
>
> Thanks,
> Lubo
>
--
James Cameron
http://quozl.netrek.org/
Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
G'day, Success, see below. On Tue, Oct 30, 2018 at 08:40:38PM +0100, Lubomir Rintel wrote: > Hello Pavel, > > On Tue, 2018-10-30 at 11:26 +0100, Pavel Machek wrote: > > Hi! > > > > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75 > > > > > > > > I didn't test it yet -- will do when I get home in the evening. > > > > But > > > > chances are it's good enough and I guess you'd be able to get it > > > > working even if I messed up some details. > > > > [...] > > Could I get prepared binary zImage for testing? > > https://github.com/hackerspace/olpc-xo175-buildroot/releases > > Here's a SD card image that works for me. The topmost commit in the > same repository is the build configuration that was used to generate > it: > > https://github.com/hackerspace/olpc-xo175-buildroot/commit/71783d599.patch > > Note it is only going to boot off the SD card, because the root= > argument is hardwired in the devicetree. Sorry about that -- I built > the image before I noticed you're booting off an USB stick and I don't > have the resources to regenerate the image at the moment. Your image does boot for me - after changing features on filesystem. http://dev.laptop.org/~quozl/y/1gHh5m.txt (dmesg) dumpe2fs of your image filesystem features; has_journal ext_attr resize_inode dir_index filetype flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum, and flags; signed_directory_hash. dumpe2fs of my image filesystem features; has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super uninit_bg dir_nlink extra_isize, and flags; unsigned_directory_hash. Our OLPC OS builder uses "mkfs.ext4 -O dir_index,^huge_file", from e2fsprogs 1.42.5. I'll look at the microSD card errors; by trying another one. Fantastic progress though, thanks! Wish I were a full time kernel developer, but so much else to do now. > If this won't boot for you, we may need fixes for older FW. Let me know what you need there; with a patch, and if it isn't too extensive I could spin a new build. We're not producing these models, so I don't _have_ to keep the factory test code working. https://github.com/quozl/openfirmware -- James Cameron http://quozl.netrek.org/
Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
G'day, Success, see below. On Tue, Oct 30, 2018 at 08:40:38PM +0100, Lubomir Rintel wrote: > Hello Pavel, > > On Tue, 2018-10-30 at 11:26 +0100, Pavel Machek wrote: > > Hi! > > > > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75 > > > > > > > > I didn't test it yet -- will do when I get home in the evening. > > > > But > > > > chances are it's good enough and I guess you'd be able to get it > > > > working even if I messed up some details. > > > > [...] > > Could I get prepared binary zImage for testing? > > https://github.com/hackerspace/olpc-xo175-buildroot/releases > > Here's a SD card image that works for me. The topmost commit in the > same repository is the build configuration that was used to generate > it: > > https://github.com/hackerspace/olpc-xo175-buildroot/commit/71783d599.patch > > Note it is only going to boot off the SD card, because the root= > argument is hardwired in the devicetree. Sorry about that -- I built > the image before I noticed you're booting off an USB stick and I don't > have the resources to regenerate the image at the moment. Your image does boot for me - after changing features on filesystem. http://dev.laptop.org/~quozl/y/1gHh5m.txt (dmesg) dumpe2fs of your image filesystem features; has_journal ext_attr resize_inode dir_index filetype flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum, and flags; signed_directory_hash. dumpe2fs of my image filesystem features; has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super uninit_bg dir_nlink extra_isize, and flags; unsigned_directory_hash. Our OLPC OS builder uses "mkfs.ext4 -O dir_index,^huge_file", from e2fsprogs 1.42.5. I'll look at the microSD card errors; by trying another one. Fantastic progress though, thanks! Wish I were a full time kernel developer, but so much else to do now. > If this won't boot for you, we may need fixes for older FW. Let me know what you need there; with a patch, and if it isn't too extensive I could spin a new build. We're not producing these models, so I don't _have_ to keep the factory test code working. https://github.com/quozl/openfirmware -- James Cameron http://quozl.netrek.org/
Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
G'day Pavel, On Tue, Oct 30, 2018 at 11:26:10AM +0100, Pavel Machek wrote: > Hi! > > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75 > > > > > > I didn't test it yet -- will do when I get home in the evening. But > > > chances are it's good enough and I guess you'd be able to get it > > > working even if I messed up some details. > > Instruction say make, but you really need to do make zImage and make > mmp2-olpc-xo-1-75.dtb . > > Instructions say "make -j", which is nice way to crash a machine. I > suggest "make -j 8" :-). > > Ok, I think I followed the instructions. I am using empty root > filesystem, just with /boot -- want to see kernel messages first > before I mess with the userland. > > But I don't get kernel messages during boot: > > OLPC 1B1, 512 MiB memory... > OpenFirmware Q4C02 EC Frimware 0.3.02 > > Type any key to interrupt... > (but keys do not interrupt anything, ouch). > Warning... partition type is 0xb... > Boot device: /usb/disk:\boot\olpc.fth Arguments: > Boot device > Warning... partition type is 0xb... That firmware has problems with USB drives. Please upgrade to Q4D38. Quickest tested method is http://wiki.laptop.org/go/Upgrading_firmware I'm firmware releaser and signer. > And that's it, cursor and no kernel messages. > > Any ideas? > > Could I get prepared binary zImage for testing? > > Thanks, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- James Cameron http://quozl.netrek.org/
Re: [PATCH v2 0/8] OLPC 1.75 Keyboard/Touchpad fixes
G'day Pavel, On Tue, Oct 30, 2018 at 11:26:10AM +0100, Pavel Machek wrote: > Hi! > > > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75 > > > > > > I didn't test it yet -- will do when I get home in the evening. But > > > chances are it's good enough and I guess you'd be able to get it > > > working even if I messed up some details. > > Instruction say make, but you really need to do make zImage and make > mmp2-olpc-xo-1-75.dtb . > > Instructions say "make -j", which is nice way to crash a machine. I > suggest "make -j 8" :-). > > Ok, I think I followed the instructions. I am using empty root > filesystem, just with /boot -- want to see kernel messages first > before I mess with the userland. > > But I don't get kernel messages during boot: > > OLPC 1B1, 512 MiB memory... > OpenFirmware Q4C02 EC Frimware 0.3.02 > > Type any key to interrupt... > (but keys do not interrupt anything, ouch). > Warning... partition type is 0xb... > Boot device: /usb/disk:\boot\olpc.fth Arguments: > Boot device > Warning... partition type is 0xb... That firmware has problems with USB drives. Please upgrade to Q4D38. Quickest tested method is http://wiki.laptop.org/go/Upgrading_firmware I'm firmware releaser and signer. > And that's it, cursor and no kernel messages. > > Any ideas? > > Could I get prepared binary zImage for testing? > > Thanks, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- James Cameron http://quozl.netrek.org/
Re: [PATCH 05/11] DT: marvell,mmp2: Add SSP1 and SSP3
On Wed, Oct 10, 2018 at 07:09:30PM +0200, Lubomir Rintel wrote: > There seem to be SSP2, SSP4 and perhaps SSP5 too, but Marvel keeps their > base addresses secret. > > The SSP1 and SSP3 addresses were taken from OLPC 1.75, OpenFirmware and > kernel respectively. Sorry for the delay. Love your work! From my notes, SSP2 is 0xd4036000, and SSP4 is 0xd4039000. Can be probed by hand in OpenFirmware or CForth once clocks are on. -- James Cameron http://quozl.netrek.org/
Re: [PATCH 05/11] DT: marvell,mmp2: Add SSP1 and SSP3
On Wed, Oct 10, 2018 at 07:09:30PM +0200, Lubomir Rintel wrote: > There seem to be SSP2, SSP4 and perhaps SSP5 too, but Marvel keeps their > base addresses secret. > > The SSP1 and SSP3 addresses were taken from OLPC 1.75, OpenFirmware and > kernel respectively. Sorry for the delay. Love your work! From my notes, SSP2 is 0xd4036000, and SSP4 is 0xd4039000. Can be probed by hand in OpenFirmware or CForth once clocks are on. -- James Cameron http://quozl.netrek.org/
Re: [PATCH] bcma: Use bcma_debug and not pr_cont in MIPS driver
On Wed, Oct 18, 2017 at 10:12:18PM -0700, Joe Perches wrote:
> Commit 66cc04424960 ("bcma: use bcma_debug and pr_cont in MIPS driver")
> converted a printk(KERN_DEBUG to bcma_debug.
>
> bcma_debug is guarded by a #define DEBUG via pr_debug.
>
> This means that the bcma_debug will generally not be emitted
> but any pr_cont following the bcma_debug will be emitted.
>
> Correct this by removing the uses of pr_cont by using a temporary.
>
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
> drivers/bcma/driver_mips.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
> index 5904ef1aa624..a929956150eb 100644
> --- a/drivers/bcma/driver_mips.c
> +++ b/drivers/bcma/driver_mips.c
> @@ -184,11 +184,14 @@ static void bcma_core_mips_print_irq(struct bcma_device
> *dev, unsigned int irq)
> {
> int i;
> static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
> +char interrupts[20];
> +char *ints = interrupts;
Tabs were changed to spaces.
>
> - bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
> - for (i = 0; i <= 6; i++)
> - pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
> - pr_cont("\n");
> +for (i = 0; i < ARRAY_SIZE(irq_name); i++)
> +ints += sprintf(ints, " %s%c",
> + irq_name[i], i == irq ? '*' : ' ');
But not on this line.
> +
> +bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id,
> interrupts);
> }
>
> static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
> --
> 2.10.0.rc2.1.g053435c
>
--
James Cameron
http://quozl.netrek.org/
Re: [PATCH] bcma: Use bcma_debug and not pr_cont in MIPS driver
On Wed, Oct 18, 2017 at 10:12:18PM -0700, Joe Perches wrote:
> Commit 66cc04424960 ("bcma: use bcma_debug and pr_cont in MIPS driver")
> converted a printk(KERN_DEBUG to bcma_debug.
>
> bcma_debug is guarded by a #define DEBUG via pr_debug.
>
> This means that the bcma_debug will generally not be emitted
> but any pr_cont following the bcma_debug will be emitted.
>
> Correct this by removing the uses of pr_cont by using a temporary.
>
> Signed-off-by: Joe Perches
> ---
> drivers/bcma/driver_mips.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
> index 5904ef1aa624..a929956150eb 100644
> --- a/drivers/bcma/driver_mips.c
> +++ b/drivers/bcma/driver_mips.c
> @@ -184,11 +184,14 @@ static void bcma_core_mips_print_irq(struct bcma_device
> *dev, unsigned int irq)
> {
> int i;
> static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
> +char interrupts[20];
> +char *ints = interrupts;
Tabs were changed to spaces.
>
> - bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
> - for (i = 0; i <= 6; i++)
> - pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
> - pr_cont("\n");
> +for (i = 0; i < ARRAY_SIZE(irq_name); i++)
> +ints += sprintf(ints, " %s%c",
> + irq_name[i], i == irq ? '*' : ' ');
But not on this line.
> +
> +bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id,
> interrupts);
> }
>
> static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
> --
> 2.10.0.rc2.1.g053435c
>
--
James Cameron
http://quozl.netrek.org/
Re: [ldv-project] [net] libertas: potential race condition
On Tue, Jun 14, 2016 at 05:16:11PM +0400, Pavel Andrianov wrote: > 08.06.2016 02:51, James Cameron пишет: > >On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote: > >>On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: > >>>Hi! > >>> > >>>There is a potential race condition in > >>>drivers/net/wireless/libertas/libertas.ko. > >>>In the function lbs_hard_start_xmit(..), line 159, a socket buffer > >>>is > >>>written to priv->current_skb with a spin_lock protection. > >>>In the function lbs_mac_event_disconnected(..), lines 50-51, the > >>>field > >>>current_skb is cleaned. There is no protection used. The > >>>corresponding > >>>handlers are activated at the same time in lbs_start_card(..) and > >>>then > >>>may be executed simultaneously. Note, there are two structures > >>>lbs_netdev_ops and mesh_netdev_ops, which have the target handler > >>>lbs_hard_start_xmit. > >>>Is it a real race or I have missed something? > >>Yeah, it looks like it should be grabbing priv->driver_lock before > >>clearing priv->currenttxskb in lbs_mac_event_disconnected(). Care to > >>submit a patch after testing? Do you have any of that hardware? > >I've hardware, with serial console. > > > >Can test any patch, on USB (8388) or SDIO (8686). > > > Hi! > > I've prepare the patch for this issue. Could you test it? > > Thank you. Tested on OLPC XO-1 (usb8388) and XO-1.5 (sd8686) with v4.7-rc3. Confirmed that lbs_mac_event_disconnected is being called on the station when hostapd on access point is given SIGHUP. Longer duration test was; - SSH to station and run "top -d 0.2", - send SIGHUP every six seconds, for 300 cycles, You may add my; Tested-by: James Cameron <qu...@laptop.org> -- James Cameron http://quozl.netrek.org/
Re: [ldv-project] [net] libertas: potential race condition
On Tue, Jun 14, 2016 at 05:16:11PM +0400, Pavel Andrianov wrote: > 08.06.2016 02:51, James Cameron пишет: > >On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote: > >>On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: > >>>Hi! > >>> > >>>There is a potential race condition in > >>>drivers/net/wireless/libertas/libertas.ko. > >>>In the function lbs_hard_start_xmit(..), line 159, a socket buffer > >>>is > >>>written to priv->current_skb with a spin_lock protection. > >>>In the function lbs_mac_event_disconnected(..), lines 50-51, the > >>>field > >>>current_skb is cleaned. There is no protection used. The > >>>corresponding > >>>handlers are activated at the same time in lbs_start_card(..) and > >>>then > >>>may be executed simultaneously. Note, there are two structures > >>>lbs_netdev_ops and mesh_netdev_ops, which have the target handler > >>>lbs_hard_start_xmit. > >>>Is it a real race or I have missed something? > >>Yeah, it looks like it should be grabbing priv->driver_lock before > >>clearing priv->currenttxskb in lbs_mac_event_disconnected(). Care to > >>submit a patch after testing? Do you have any of that hardware? > >I've hardware, with serial console. > > > >Can test any patch, on USB (8388) or SDIO (8686). > > > Hi! > > I've prepare the patch for this issue. Could you test it? > > Thank you. Tested on OLPC XO-1 (usb8388) and XO-1.5 (sd8686) with v4.7-rc3. Confirmed that lbs_mac_event_disconnected is being called on the station when hostapd on access point is given SIGHUP. Longer duration test was; - SSH to station and run "top -d 0.2", - send SIGHUP every six seconds, for 300 cycles, You may add my; Tested-by: James Cameron -- James Cameron http://quozl.netrek.org/
Re: [ldv-project] [net] libertas: potential race condition
On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote: > On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: > > Hi! > > > > There is a potential race condition in > > drivers/net/wireless/libertas/libertas.ko. > > In the function lbs_hard_start_xmit(..), line 159, a socket buffer > > is > > written to priv->current_skb with a spin_lock protection. > > In the function lbs_mac_event_disconnected(..), lines 50-51, the > > field > > current_skb is cleaned. There is no protection used. The > > corresponding > > handlers are activated at the same time in lbs_start_card(..) and > > then > > may be executed simultaneously. Note, there are two structures > > lbs_netdev_ops and mesh_netdev_ops, which have the target handler > > lbs_hard_start_xmit. > > Is it a real race or I have missed something? > > Yeah, it looks like it should be grabbing priv->driver_lock before > clearing priv->currenttxskb in lbs_mac_event_disconnected(). Care to > submit a patch after testing? Do you have any of that hardware? I've hardware, with serial console. Can test any patch, on USB (8388) or SDIO (8686). -- James Cameron http://quozl.netrek.org/
Re: [ldv-project] [net] libertas: potential race condition
On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote: > On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: > > Hi! > > > > There is a potential race condition in > > drivers/net/wireless/libertas/libertas.ko. > > In the function lbs_hard_start_xmit(..), line 159, a socket buffer > > is > > written to priv->current_skb with a spin_lock protection. > > In the function lbs_mac_event_disconnected(..), lines 50-51, the > > field > > current_skb is cleaned. There is no protection used. The > > corresponding > > handlers are activated at the same time in lbs_start_card(..) and > > then > > may be executed simultaneously. Note, there are two structures > > lbs_netdev_ops and mesh_netdev_ops, which have the target handler > > lbs_hard_start_xmit. > > Is it a real race or I have missed something? > > Yeah, it looks like it should be grabbing priv->driver_lock before > clearing priv->currenttxskb in lbs_mac_event_disconnected(). Care to > submit a patch after testing? Do you have any of that hardware? I've hardware, with serial console. Can test any patch, on USB (8388) or SDIO (8686). -- James Cameron http://quozl.netrek.org/
Re: [PATCH] net: mark DECnet as broken
On Thu, Apr 07, 2016 at 09:22:43AM +0200, Vegard Nossum wrote: > There are NULL pointer dereference bugs in DECnet which can be triggered > by unprivileged users and have been reported multiple times to LKML, > however nobody seems confident enough in the proposed fixes to merge them > and the consensus seems to be that nobody cares enough about DECnet to > see it fixed anyway. > > To shield unsuspecting users from the possible DOS, we should mark this > BROKEN until somebody who actually uses this code can fix it. > > Signed-off-by: Vegard Nossum <vegard.nos...@oracle.com> > Link: https://lkml.org/lkml/2015/12/17/666 > Cc: Eric Dumazet <eric.duma...@gmail.com> > Cc: Sasha Levin <sasha.le...@oracle.com> > Cc: David Miller <da...@davemloft.net> Reviewed-by: James Cameron <qu...@laptop.org> (An old DECnet application programmer from way back, ah what fun!) > --- > net/decnet/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/decnet/Kconfig b/net/decnet/Kconfig > index f3393e1..b040172 100644 > --- a/net/decnet/Kconfig > +++ b/net/decnet/Kconfig > @@ -3,6 +3,7 @@ > # > config DECNET > tristate "DECnet Support" > + depends on BROKEN > ---help--- > The DECnet networking protocol was used in many products made by > Digital (now Compaq). It provides reliable stream and sequenced fwiw, then Compaq merged into HP. > -- > 1.9.1 > -- James Cameron http://quozl.netrek.org/
Re: [PATCH] net: mark DECnet as broken
On Thu, Apr 07, 2016 at 09:22:43AM +0200, Vegard Nossum wrote: > There are NULL pointer dereference bugs in DECnet which can be triggered > by unprivileged users and have been reported multiple times to LKML, > however nobody seems confident enough in the proposed fixes to merge them > and the consensus seems to be that nobody cares enough about DECnet to > see it fixed anyway. > > To shield unsuspecting users from the possible DOS, we should mark this > BROKEN until somebody who actually uses this code can fix it. > > Signed-off-by: Vegard Nossum > Link: https://lkml.org/lkml/2015/12/17/666 > Cc: Eric Dumazet > Cc: Sasha Levin > Cc: David Miller Reviewed-by: James Cameron (An old DECnet application programmer from way back, ah what fun!) > --- > net/decnet/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/decnet/Kconfig b/net/decnet/Kconfig > index f3393e1..b040172 100644 > --- a/net/decnet/Kconfig > +++ b/net/decnet/Kconfig > @@ -3,6 +3,7 @@ > # > config DECNET > tristate "DECnet Support" > + depends on BROKEN > ---help--- > The DECnet networking protocol was used in many products made by > Digital (now Compaq). It provides reliable stream and sequenced fwiw, then Compaq merged into HP. > -- > 1.9.1 > -- James Cameron http://quozl.netrek.org/
Re: [PATCH for-4.4 1/2] mtd: spi-nor: fix Spansion regressions (aliased with Winbond)
On Wed, Mar 30, 2016 at 02:47:48PM +0200, Cyrille Pitchen wrote: > Hi all, > > [...] > > But this is interesting: I see the latest datasheet for Spansion > > s25fl064k says it supports the Block Protect bits in the Status > > Register, so presumably *some* version of s25fl064k should support > > write_sr(nor, 0) to unlock it at boot... > > > > If Felix's initial report is indeed correct, then I think we have: > > (1) Spansion s25fl064k without Block Protect support (that breaks if you > > try to write SR=0) > > (2) Spansion s25fl064k with Block Protect support (that requires you to > > unlock at boot by writing SR=0 (?)) > > (3) Winbond w25q64 with Block Protect support (that requires you to > > unlock at boot by writing SR=0) > > > > And (1)-(3) all report the same ID, and (1) is incompatible with (2) and > > (3). Am I right? Are flash vendors really this insane? Should we all > > just give up and go home? > > > > Just a general remark: maybe reading the JEDEC ID is not a so reliable mean to > discover SPI flash hardware capabilities at runtime. > > Two weeks ago some Macronix people came to Atmel to present us next evolutions > of SPI flashes. We took this opportunity to ask them some questions and one of > them was about memories with different hardware capabilities sharing the very > same JEDEC ID. One example is Macronix MX25L25635E vs MX25L25673G. > > They explained to us that for Macronix memories, the 2byte product ID is to be > split into a 1byte code for the memory type and a second byte for the memory > denstity. For instance: > C2: Manufacturer ID, Macronix > 20: Memory Type, SPI NOR flash > 19: Memory density, 256Mib > > Hence the JEDEC ID only provides information about the memory size and all > SPI NOR memories of a given size actually share the same JEDEC ID. Yes, that's true. (Reference: Open Firmware SPI Flash driver used at OLPC.) > > Similar cases can also be found with other manufacturers: Micron, Winbond, > Spansion... > > Also the Macronix engineers asked us how software applications drive the > (Q)SPI > memories. I answered them that Linux or u-boot use a static table indexed by > the JEDEC ID, which provides the hardware capabilities. I guess they didn't > expect software developers to use the JEDEC ID for this purpose. > Well, it's just a feeling. > > Then the Macronix engineers proposed to use the Serial Flash Discoverable > Parameter (SFDP) tables to make the difference between memories sharing the > same JEDEC ID. This might help us in some cases. > However we should be cautious when using this standard: last year, I've tried > to discover hardware parameters through these tables when I was working with > Spansion and Micron memories. I found out the Parameter Table Pointers inside > the SFDP Header were expressed as byte offset with one memory and as dword > offset with the other. > So I gave up using these tables since some memories diverged from the > standard, > which was "work in progress" at that time. Yes, I too was unable to use SFDP; some devices didn't have them, some didn't seem to be good data. > > Anyway if we cannot completely rely on the SFDP tables we could still use > DT properties but we should no longer expect to guess all hardware parameters > from the JEDEC ID alone. We solved this problem by not using our SPI Flash from the kernel, but that's not the best outcome. ;-) > > Best regards, > > Cyrille -- James Cameron http://quozl.netrek.org/
Re: [PATCH for-4.4 1/2] mtd: spi-nor: fix Spansion regressions (aliased with Winbond)
On Wed, Mar 30, 2016 at 02:47:48PM +0200, Cyrille Pitchen wrote: > Hi all, > > [...] > > But this is interesting: I see the latest datasheet for Spansion > > s25fl064k says it supports the Block Protect bits in the Status > > Register, so presumably *some* version of s25fl064k should support > > write_sr(nor, 0) to unlock it at boot... > > > > If Felix's initial report is indeed correct, then I think we have: > > (1) Spansion s25fl064k without Block Protect support (that breaks if you > > try to write SR=0) > > (2) Spansion s25fl064k with Block Protect support (that requires you to > > unlock at boot by writing SR=0 (?)) > > (3) Winbond w25q64 with Block Protect support (that requires you to > > unlock at boot by writing SR=0) > > > > And (1)-(3) all report the same ID, and (1) is incompatible with (2) and > > (3). Am I right? Are flash vendors really this insane? Should we all > > just give up and go home? > > > > Just a general remark: maybe reading the JEDEC ID is not a so reliable mean to > discover SPI flash hardware capabilities at runtime. > > Two weeks ago some Macronix people came to Atmel to present us next evolutions > of SPI flashes. We took this opportunity to ask them some questions and one of > them was about memories with different hardware capabilities sharing the very > same JEDEC ID. One example is Macronix MX25L25635E vs MX25L25673G. > > They explained to us that for Macronix memories, the 2byte product ID is to be > split into a 1byte code for the memory type and a second byte for the memory > denstity. For instance: > C2: Manufacturer ID, Macronix > 20: Memory Type, SPI NOR flash > 19: Memory density, 256Mib > > Hence the JEDEC ID only provides information about the memory size and all > SPI NOR memories of a given size actually share the same JEDEC ID. Yes, that's true. (Reference: Open Firmware SPI Flash driver used at OLPC.) > > Similar cases can also be found with other manufacturers: Micron, Winbond, > Spansion... > > Also the Macronix engineers asked us how software applications drive the > (Q)SPI > memories. I answered them that Linux or u-boot use a static table indexed by > the JEDEC ID, which provides the hardware capabilities. I guess they didn't > expect software developers to use the JEDEC ID for this purpose. > Well, it's just a feeling. > > Then the Macronix engineers proposed to use the Serial Flash Discoverable > Parameter (SFDP) tables to make the difference between memories sharing the > same JEDEC ID. This might help us in some cases. > However we should be cautious when using this standard: last year, I've tried > to discover hardware parameters through these tables when I was working with > Spansion and Micron memories. I found out the Parameter Table Pointers inside > the SFDP Header were expressed as byte offset with one memory and as dword > offset with the other. > So I gave up using these tables since some memories diverged from the > standard, > which was "work in progress" at that time. Yes, I too was unable to use SFDP; some devices didn't have them, some didn't seem to be good data. > > Anyway if we cannot completely rely on the SFDP tables we could still use > DT properties but we should no longer expect to guess all hardware parameters > from the JEDEC ID alone. We solved this problem by not using our SPI Flash from the kernel, but that's not the best outcome. ;-) > > Best regards, > > Cyrille -- James Cameron http://quozl.netrek.org/
Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call
On Tue, Mar 29, 2016 at 12:47:20PM +0800, Wei-Ning Huang wrote: > "single skb allocation failure" happens when system is under heavy > memory pressure. Add __GFP_REPEAT to skb allocation call so kernel > attempts to reclaim pages and retry the allocation. Oh, that's interesting, we're back to this symptom again. Nice to see this fix. Heavy memory pressure on 3.5 caused dev_alloc_skb failure in this driver. Tracked at OLPC as #12694. -- James Cameron http://quozl.netrek.org/
Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call
On Tue, Mar 29, 2016 at 12:47:20PM +0800, Wei-Ning Huang wrote: > "single skb allocation failure" happens when system is under heavy > memory pressure. Add __GFP_REPEAT to skb allocation call so kernel > attempts to reclaim pages and retry the allocation. Oh, that's interesting, we're back to this symptom again. Nice to see this fix. Heavy memory pressure on 3.5 caused dev_alloc_skb failure in this driver. Tracked at OLPC as #12694. -- James Cameron http://quozl.netrek.org/
Re: [PATCH] libertas: fix return value when processing invalid packet
On Thu, May 22, 2014 at 07:32:41AM -0500, Dan Williams wrote: > Nothing actually uses the return value yet, but we might as well > make it correct, like process_rxed_802_11_packet() does for the > same case. Also ensure that if monitor mode is enabled (and > thus process_rxed_802_11_packet() is called) that the debugging > enter/leave functions are balanced. > > Signed-off-by: Dan Williams Reviewed-by: James Cameron -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libertas: fix return value when processing invalid packet
On Thu, May 22, 2014 at 07:32:41AM -0500, Dan Williams wrote: Nothing actually uses the return value yet, but we might as well make it correct, like process_rxed_802_11_packet() does for the same case. Also ensure that if monitor mode is enabled (and thus process_rxed_802_11_packet() is called) that the debugging enter/leave functions are balanced. Signed-off-by: Dan Williams d...@redhat.com Reviewed-by: James Cameron qu...@laptop.org -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: rtl8192e: Fix typo in rtl8192e
On Fri, Apr 25, 2014 at 01:48:41AM +0900, Masanari Iida wrote:
> Fix spelling typo in comments within rtl8192e.
>
> Signed-off-by: Masanari Iida
> ---
> drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c | 2 +-
> drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c| 2 +-
> drivers/staging/rtl8192e/rtl8192e/rtl_wx.c| 2 +-
> drivers/staging/rtl8192e/rtl819x_TSProc.c | 2 +-
> drivers/staging/rtl8192e/rtllib_rx.c | 2 +-
> drivers/staging/rtl8192e/rtllib_softmac.c | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
...
> diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
> b/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
> index 498995d..59494f5 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
> @@ -1213,7 +1213,7 @@ static iw_handler r8192_wx_handlers[] = {
> };
>
> /*
> - * the following rule need to be follwing,
> + * the following rule need to be following,
> * Odd : get (world access),
> * even : set (root access)
> * */
The change is good, and a better change might be "s/rule/rules" and
"s/following/followed".
On the other hand, no other driver mentions this implementation detail
of IW_IS_SET in declaration of iw_priv_args, so perhaps the whole
comment block should be removed.
Either way;
Reviewed-by: James Cameron
p.s. nice to see you again.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: rtl8192e: Fix typo in rtl8192e
On Fri, Apr 25, 2014 at 01:48:41AM +0900, Masanari Iida wrote:
Fix spelling typo in comments within rtl8192e.
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c | 2 +-
drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c| 2 +-
drivers/staging/rtl8192e/rtl8192e/rtl_wx.c| 2 +-
drivers/staging/rtl8192e/rtl819x_TSProc.c | 2 +-
drivers/staging/rtl8192e/rtllib_rx.c | 2 +-
drivers/staging/rtl8192e/rtllib_softmac.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
...
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
index 498995d..59494f5 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
@@ -1213,7 +1213,7 @@ static iw_handler r8192_wx_handlers[] = {
};
/*
- * the following rule need to be follwing,
+ * the following rule need to be following,
* Odd : get (world access),
* even : set (root access)
* */
The change is good, and a better change might be s/rule/rules and
s/following/followed.
On the other hand, no other driver mentions this implementation detail
of IW_IS_SET in declaration of iw_priv_args, so perhaps the whole
comment block should be removed.
Either way;
Reviewed-by: James Cameron qu...@laptop.org
p.s. nice to see you again.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH V2] ARM: compressed: Move ramdisk forward to reserve more memory for kernel image
> + putstr("Searching ramdisk ...\n");
> + if (tags->hdr.tag == ATAG_CORE) {
> + putstr("Found tags ...\n");
> + for (tags = tag_next(tags); tags->hdr.size; tags =
> tag_next(tags)) {
> + if (tags->hdr.tag == ATAG_INITRD2) {
> + putstr("Found initrd2 tag ...\n");
> + found = 1;
> + break;
> + } else if (tags->hdr.tag == ATAG_INITRD) {
> + putstr("Found initrd tag ...\n");
> + found = 1;
> + break;
> + } else if (tags->hdr.tag == ATAG_RAMDISK) {
> + putstr("Found ramdisk tag ...\n");
> + found = 1;
> + type = 1;
> + break;
> + }
> + }
> + if (found) {
> + if (type == 0) {
> + start = tags->u.initrd.start;
> + size = tags->u.initrd.size;
> + target = start + MOVE_RAMDISK_OFFSET;
> + tags->u.initrd.start = target;
> + } else {
> + start = tags->u.ramdisk.start;
> + size = tags->u.ramdisk.size;
> + target = start + MOVE_RAMDISK_OFFSET;
> + tags->u.ramdisk.start = target;
> + }
> +
> + putstr("Moving ramdisk forward ...\n");
> + memcpy((char *)target, (char *)start, size +
> SIZE_FIXUP_OFFSET);
> + }
> + } else {
> + putstr("No tag found ...\n");
> + }
> +#endif
> +}
> diff --git a/arch/arm/boot/compressed/move_ramdisk.h
> b/arch/arm/boot/compressed/move_ramdisk.h
> new file mode 100644
> index 000..b824cde
> --- /dev/null
> +++ b/arch/arm/boot/compressed/move_ramdisk.h
> @@ -0,0 +1,35 @@
> +#ifndef _MOVE_RAMDISK_H
> +#define _MOVE_RAMDISK_H
> +
> +#include
> +#include
> +#include
> +
> +/* The physical base address of your platform, see PHYS_OFFSET */
> +#ifdef PLAT_PHYS_OFFSET
> +#define __PLAT_PHYS_OFFSET (PLAT_PHYS_OFFSET)
> +#else
> +
> +#ifdef defined (CONFIG_ARCH_ORION5X) || defined (CONFIG_ARCH_KIRKWOOD)
> +#define __PLAT_PHYS_OFFSETUL(0x)
> +#else
> +#error "Please define __PLAT_PHYS_OFFSET, the physical base address of DRAM"
> +#endif
> +
> +#endif /* PLAT_PHYS_OFFSET */
> +
> +/* Most boards put tag at the offset 0x100 with the base PHYS_OFFSET */
> +#define TAG_BASE_OFFSET (0x100)
> +
> +/* The tag address */
> +#ifdef __PLAT_PHYS_OFFSET
> +#define TAG_BASE_ADDR(__PLAT_PHYS_OFFSET + TAG_BASE_OFFSET)
> +#endif
> +
> +/* Some old Uboot pass the wrong size to kernel, fix up it with an offset. */
> +#define SIZE_FIXUP_OFFSET(1024)
> +
> +#define MOVE_RAMDISK_OFFSET (CONFIG_MOVE_RAMDISK_OFFSET_M * 1024 * 1024)
> +#define tag_next(t) ((struct tag *)((__u32 *)(t) + (t)->hdr.size))
> +
> +#endif /* _MOVE_RAMDISK_H */
> diff --git a/usr/Kconfig b/usr/Kconfig
> index 65b845b..ad5ce5b 100644
> --- a/usr/Kconfig
> +++ b/usr/Kconfig
> @@ -166,3 +166,32 @@ config INITRAMFS_COMPRESSION_LZO
> (both compression and decompression) is the fastest.
>
> endchoice
> +
> +config MOVE_RAMDISK
> + bool "Move ramdisk forward to reserve more memory for kernel image"
> + depends on ARM
> + help
> + During embedded linux system booting, before decompressing the kernel
> + image, the bootloader(E.g. Uboot) loads the compressed kernel image
> + and ramdisk into two contiguous memory space, these two memory space
> + are fixed after the Uboot is released, as a result, the maximum size
> + of the decompressed kernel image is limited by the size of the
> + reserved memory space (the difference of the two contiguous memory
> + addresses).
Same here.
> +
> + If want more functions or some debug options, the decompressed kernel
> + image may be bigger and may override the followed ramdisk and result
> + in kernel boot failure for missing a valid ramdisk.
> +
> + To fix up this issue, before decompressing the kernel image, this
> + option moves the loaded ramdisk image forward with a specified offset
> + and reserve more memory for the decompressed kernel image.
> +
> +config MOVE_RAMDISK_OFFSET_M
> + int "Set the move offset of ramdisk (in Mbytes)"
> + range 5 100
> + default "20"
> + depends on MOVE_RAMDISK
> + help
> + Specify the move offset of the ramdisk, if want a bigger kernel,
> please
> + Increase this size.
> --
> 1.7.10.4
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH V2] ARM: compressed: Move ramdisk forward to reserve more memory for kernel image
;
+ } else if (tags-hdr.tag == ATAG_INITRD) {
+ putstr(Found initrd tag ...\n);
+ found = 1;
+ break;
+ } else if (tags-hdr.tag == ATAG_RAMDISK) {
+ putstr(Found ramdisk tag ...\n);
+ found = 1;
+ type = 1;
+ break;
+ }
+ }
+ if (found) {
+ if (type == 0) {
+ start = tags-u.initrd.start;
+ size = tags-u.initrd.size;
+ target = start + MOVE_RAMDISK_OFFSET;
+ tags-u.initrd.start = target;
+ } else {
+ start = tags-u.ramdisk.start;
+ size = tags-u.ramdisk.size;
+ target = start + MOVE_RAMDISK_OFFSET;
+ tags-u.ramdisk.start = target;
+ }
+
+ putstr(Moving ramdisk forward ...\n);
+ memcpy((char *)target, (char *)start, size +
SIZE_FIXUP_OFFSET);
+ }
+ } else {
+ putstr(No tag found ...\n);
+ }
+#endif
+}
diff --git a/arch/arm/boot/compressed/move_ramdisk.h
b/arch/arm/boot/compressed/move_ramdisk.h
new file mode 100644
index 000..b824cde
--- /dev/null
+++ b/arch/arm/boot/compressed/move_ramdisk.h
@@ -0,0 +1,35 @@
+#ifndef _MOVE_RAMDISK_H
+#define _MOVE_RAMDISK_H
+
+#include asm/setup.h
+#include asm/memory.h
+#include asm/string.h
+
+/* The physical base address of your platform, see PHYS_OFFSET */
+#ifdef PLAT_PHYS_OFFSET
+#define __PLAT_PHYS_OFFSET (PLAT_PHYS_OFFSET)
+#else
+
+#ifdef defined (CONFIG_ARCH_ORION5X) || defined (CONFIG_ARCH_KIRKWOOD)
+#define __PLAT_PHYS_OFFSETUL(0x)
+#else
+#error Please define __PLAT_PHYS_OFFSET, the physical base address of DRAM
+#endif
+
+#endif /* PLAT_PHYS_OFFSET */
+
+/* Most boards put tag at the offset 0x100 with the base PHYS_OFFSET */
+#define TAG_BASE_OFFSET (0x100)
+
+/* The tag address */
+#ifdef __PLAT_PHYS_OFFSET
+#define TAG_BASE_ADDR(__PLAT_PHYS_OFFSET + TAG_BASE_OFFSET)
+#endif
+
+/* Some old Uboot pass the wrong size to kernel, fix up it with an offset. */
+#define SIZE_FIXUP_OFFSET(1024)
+
+#define MOVE_RAMDISK_OFFSET (CONFIG_MOVE_RAMDISK_OFFSET_M * 1024 * 1024)
+#define tag_next(t) ((struct tag *)((__u32 *)(t) + (t)-hdr.size))
+
+#endif /* _MOVE_RAMDISK_H */
diff --git a/usr/Kconfig b/usr/Kconfig
index 65b845b..ad5ce5b 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -166,3 +166,32 @@ config INITRAMFS_COMPRESSION_LZO
(both compression and decompression) is the fastest.
endchoice
+
+config MOVE_RAMDISK
+ bool Move ramdisk forward to reserve more memory for kernel image
+ depends on ARM
+ help
+ During embedded linux system booting, before decompressing the kernel
+ image, the bootloader(E.g. Uboot) loads the compressed kernel image
+ and ramdisk into two contiguous memory space, these two memory space
+ are fixed after the Uboot is released, as a result, the maximum size
+ of the decompressed kernel image is limited by the size of the
+ reserved memory space (the difference of the two contiguous memory
+ addresses).
Same here.
+
+ If want more functions or some debug options, the decompressed kernel
+ image may be bigger and may override the followed ramdisk and result
+ in kernel boot failure for missing a valid ramdisk.
+
+ To fix up this issue, before decompressing the kernel image, this
+ option moves the loaded ramdisk image forward with a specified offset
+ and reserve more memory for the decompressed kernel image.
+
+config MOVE_RAMDISK_OFFSET_M
+ int Set the move offset of ramdisk (in Mbytes)
+ range 5 100
+ default 20
+ depends on MOVE_RAMDISK
+ help
+ Specify the move offset of the ramdisk, if want a bigger kernel,
please
+ Increase this size.
--
1.7.10.4
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 02:34:17PM +0400, Sergei Ianovich wrote:
> On Fri, 2013-12-06 at 20:53 +1100, James Cameron wrote:
> > I don't understand why /dev/ttyS2 (4,66) changed to /dev/ttyS0 (4,64)
> > after the patch was applied to olpc-kernel/arm-3.5 but, as you say it
> > doesn't change, perhaps there is something between 3.5 and now for me
> > to watch out for. My problem.
>
> The old pxa.c set device ids explicitly:
> -static int serial_pxa_probe_dt(struct platform_device *pdev,
> - struct uart_pxa_port *sport)
> -{
> - struct device_node *np = pdev->dev.of_node;
> - int ret;
> -
> - if (!np)
> - return 1;
> -
> - ret = of_alias_get_id(np, "serial");
> - if (ret < 0) {
> - dev_err(>dev, "failed to get alias id, errno %d
> \n", ret);
> - return ret;
> - }
> - sport->port.line = ret;
> - return 0;
> -}
>
> and
>
> - ret = serial_pxa_probe_dt(dev, sport);
> - if (ret > 0)
> - sport->port.line = dev->id;
>
>
> However, this is not possible with 8250_core. The latter assigns device
> ids strictly in the call order of serial8250_register_8250_port().
>
> Hope it helps.
Yes, thanks, that explains it.
Your patch deprecates the use of property "linux,unit#" in the device
tree for serial ports, or the numbering according to the ordering of
the device tree.
(On OLPC XO-4, we set the numbering according to the ordering, we don't
use "linux,unit#".)
It is sad to see device tree sawdust. ;-)
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 01:28:51PM +0400, Sergei Ianovich wrote: > On Fri, 2013-12-06 at 00:17 +, Russell King - ARM Linux wrote: > > > I may be able to - one of the downsides though is that many of these > > systems had hard-coded scripts which started a getty on the original > > port - and that kind of makes it difficult to sort out. This kind of > > change becomes very much one of Linus' "flag days". > > > So I'd suggest that we have a period where the old driver is still > > available, so at least people can choose to use the old major/minor > > numbers for a while. > > The patch doesn't change how the driver looks from the outside. The old > driver was using 8250 name (ttyS), major (4) and first minor (64). So we > only resolve an internal conflict. I don't understand why /dev/ttyS2 (4,66) changed to /dev/ttyS0 (4,64) after the patch was applied to olpc-kernel/arm-3.5 but, as you say it doesn't change, perhaps there is something between 3.5 and now for me to watch out for. My problem. > Kernel configuration is the place where issues may appear, since the > patch removes CONFIG_SERIAL_PXA_CONSOLE option. I've updated all > in-kernel users. However, out-of-kernel configs will no longer provide > serial console, unless manually reconfigured. Is this the case we should > worry about? OLPC holds an out-of-kernel config (xo_4_defconfig); but no, I don't think we'd have trouble with this. Go for it. -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 01:09:31PM +0400, Sergei Ianovich wrote: > pxa2xx-uart was a separate uart platform driver. It was declaring > the same device names and numbers as 8250 driver. As a result, > it was impossible to use 8250 driver on PXA SoCs. > > Upon closer examination pxa2xx-uart turned out to be a clone of > 8250_core driver. > > Workaround for Erratum #19 according to Marvel(R) PXA270M Processor > Specification Update (April 19, 2010) is dropped. 8250_core reads > from FIFO immediately after checking DR bit in LSR. Reviewed-by: James Cameron Thanks. (for my notes ... V1 has passed 4.5 hours in OLPC's RUNIN test.) -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 01:09:31PM +0400, Sergei Ianovich wrote: pxa2xx-uart was a separate uart platform driver. It was declaring the same device names and numbers as 8250 driver. As a result, it was impossible to use 8250 driver on PXA SoCs. Upon closer examination pxa2xx-uart turned out to be a clone of 8250_core driver. Workaround for Erratum #19 according to Marvel(R) PXA270M Processor Specification Update (April 19, 2010) is dropped. 8250_core reads from FIFO immediately after checking DR bit in LSR. Reviewed-by: James Cameron qu...@laptop.org Thanks. (for my notes ... V1 has passed 4.5 hours in OLPC's RUNIN test.) -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 01:28:51PM +0400, Sergei Ianovich wrote: On Fri, 2013-12-06 at 00:17 +, Russell King - ARM Linux wrote: I may be able to - one of the downsides though is that many of these systems had hard-coded scripts which started a getty on the original port - and that kind of makes it difficult to sort out. This kind of change becomes very much one of Linus' flag days. So I'd suggest that we have a period where the old driver is still available, so at least people can choose to use the old major/minor numbers for a while. The patch doesn't change how the driver looks from the outside. The old driver was using 8250 name (ttyS), major (4) and first minor (64). So we only resolve an internal conflict. I don't understand why /dev/ttyS2 (4,66) changed to /dev/ttyS0 (4,64) after the patch was applied to olpc-kernel/arm-3.5 but, as you say it doesn't change, perhaps there is something between 3.5 and now for me to watch out for. My problem. Kernel configuration is the place where issues may appear, since the patch removes CONFIG_SERIAL_PXA_CONSOLE option. I've updated all in-kernel users. However, out-of-kernel configs will no longer provide serial console, unless manually reconfigured. Is this the case we should worry about? OLPC holds an out-of-kernel config (xo_4_defconfig); but no, I don't think we'd have trouble with this. Go for it. -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 02:34:17PM +0400, Sergei Ianovich wrote:
On Fri, 2013-12-06 at 20:53 +1100, James Cameron wrote:
I don't understand why /dev/ttyS2 (4,66) changed to /dev/ttyS0 (4,64)
after the patch was applied to olpc-kernel/arm-3.5 but, as you say it
doesn't change, perhaps there is something between 3.5 and now for me
to watch out for. My problem.
The old pxa.c set device ids explicitly:
-static int serial_pxa_probe_dt(struct platform_device *pdev,
- struct uart_pxa_port *sport)
-{
- struct device_node *np = pdev-dev.of_node;
- int ret;
-
- if (!np)
- return 1;
-
- ret = of_alias_get_id(np, serial);
- if (ret 0) {
- dev_err(pdev-dev, failed to get alias id, errno %d
\n, ret);
- return ret;
- }
- sport-port.line = ret;
- return 0;
-}
and
- ret = serial_pxa_probe_dt(dev, sport);
- if (ret 0)
- sport-port.line = dev-id;
However, this is not possible with 8250_core. The latter assigns device
ids strictly in the call order of serial8250_register_8250_port().
Hope it helps.
Yes, thanks, that explains it.
Your patch deprecates the use of property linux,unit# in the device
tree for serial ports, or the numbering according to the ordering of
the device tree.
(On OLPC XO-4, we set the numbering according to the ordering, we don't
use linux,unit#.)
It is sad to see device tree sawdust. ;-)
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 11:38:51AM +1100, James Cameron wrote: > On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote: > > pxa2xx-uart was a separate uart platform driver. It was declaring > > the same device names and numbers as 8250 driver. As a result, > > it was impossible to use 8250 driver on PXA SoCs. > > > > Upon closer examination pxa2xx-uart turned out to be a clone of > > 8250_core driver. > > I'm testing this backported to 3.5 on the OLPC XO-4 [1] [2]. > > As Russell says, the getty had to change, but after that the shell > worked fine; no more or no less responsive. > > What hasn't worked yet is the console; no kernel messages appear. I > have tried changing command line to console=ttyS0,115200. My error. Our kernel had CONFIG_CMDLINE set, changing that fixed it. Console is working fine. -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote:
> pxa2xx-uart was a separate uart platform driver. It was declaring
> the same device names and numbers as 8250 driver. As a result,
> it was impossible to use 8250 driver on PXA SoCs.
>
> Upon closer examination pxa2xx-uart turned out to be a clone of
> 8250_core driver.
[...]
> +/* Uart divisor latch write */
> +static void serial_pxa_dl_write(struct uart_8250_port *up, int value)
> +{
> + serial_out(up, UART_DLL, value & 0xff);
> + serial_out(up, UART_DLM, value >> 8 & 0xff);
> +}
This is a change. drivers/tty/serial/pxa.c did read back UART_DLL as
an errata work around:
> - /*
> - * work around Errata #75 according to Intel(R) PXA27x Processor Family
> - * Specification Update (Nov 2005)
> - */
> - dll = serial_in(up, UART_DLL);
> - WARN_ON(dll != (quot & 0xff));
If this is no longer needed, serial_pxa_dl_write can be removed
because it is same as default_serial_dl_write.
I did not check the other errata work arounds.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote: > pxa2xx-uart was a separate uart platform driver. It was declaring > the same device names and numbers as 8250 driver. As a result, > it was impossible to use 8250 driver on PXA SoCs. > > Upon closer examination pxa2xx-uart turned out to be a clone of > 8250_core driver. I'm testing this backported to 3.5 on the OLPC XO-4 [1] [2]. As Russell says, the getty had to change, but after that the shell worked fine; no more or no less responsive. What hasn't worked yet is the console; no kernel messages appear. I have tried changing command line to console=ttyS0,115200. 1. http://dev.laptop.org/~quozl/y/1VojGn.txt (diff relative to olpc-kernel/arm-3.5) 2. http://dev.laptop.org/~quozl/z/1VojLz.txt (dmesg) -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote: pxa2xx-uart was a separate uart platform driver. It was declaring the same device names and numbers as 8250 driver. As a result, it was impossible to use 8250 driver on PXA SoCs. Upon closer examination pxa2xx-uart turned out to be a clone of 8250_core driver. I'm testing this backported to 3.5 on the OLPC XO-4 [1] [2]. As Russell says, the getty had to change, but after that the shell worked fine; no more or no less responsive. What hasn't worked yet is the console; no kernel messages appear. I have tried changing command line to console=ttyS0,115200. 1. http://dev.laptop.org/~quozl/y/1VojGn.txt (diff relative to olpc-kernel/arm-3.5) 2. http://dev.laptop.org/~quozl/z/1VojLz.txt (dmesg) -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote:
pxa2xx-uart was a separate uart platform driver. It was declaring
the same device names and numbers as 8250 driver. As a result,
it was impossible to use 8250 driver on PXA SoCs.
Upon closer examination pxa2xx-uart turned out to be a clone of
8250_core driver.
[...]
+/* Uart divisor latch write */
+static void serial_pxa_dl_write(struct uart_8250_port *up, int value)
+{
+ serial_out(up, UART_DLL, value 0xff);
+ serial_out(up, UART_DLM, value 8 0xff);
+}
This is a change. drivers/tty/serial/pxa.c did read back UART_DLL as
an errata work around:
- /*
- * work around Errata #75 according to Intel(R) PXA27x Processor Family
- * Specification Update (Nov 2005)
- */
- dll = serial_in(up, UART_DLL);
- WARN_ON(dll != (quot 0xff));
If this is no longer needed, serial_pxa_dl_write can be removed
because it is same as default_serial_dl_write.
I did not check the other errata work arounds.
--
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: rewrite pxa2xx-uart to use 8250_core
On Fri, Dec 06, 2013 at 11:38:51AM +1100, James Cameron wrote: On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote: pxa2xx-uart was a separate uart platform driver. It was declaring the same device names and numbers as 8250 driver. As a result, it was impossible to use 8250 driver on PXA SoCs. Upon closer examination pxa2xx-uart turned out to be a clone of 8250_core driver. I'm testing this backported to 3.5 on the OLPC XO-4 [1] [2]. As Russell says, the getty had to change, but after that the shell worked fine; no more or no less responsive. What hasn't worked yet is the console; no kernel messages appear. I have tried changing command line to console=ttyS0,115200. My error. Our kernel had CONFIG_CMDLINE set, changing that fixed it. Console is working fine. -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ppp_mppe+pptp for 2.6.14?
My problems with ENOPROTOOPT were due to lack of coffee. They were caused by ICMP protocol unreachable responses from the test server because I'd taken away it's pppd. My mistake. On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote: > I've asked James Cameron, pptp project lead, to try a test to force > the server side to issue a CCP DOWN, to make sure the client-side > kernel ppp_generic module does the right thing and drops packets. I've tested this now with a host running kernel 2.6.13 with Matt's SC_MUST_COMP patch to the kernel and to ppp 2.4.4b1, sending SIGUSR2 to the pppd while flooding the connection with pings from the server. The result is an LCP TermReq from the server to the client, after which no further data packets appear. All the data packets up to the LCP TermReq are encrypted. The client sends an LCP TermAck, then takes down the interface. There's sign of CCP down, in that a CCP ConfReq appears from the server just after the LCP TermReq. I'm not sure this is an adequate test, and will take advice on that. Test configuration; - server, 2.6.13 + SC_MUST_COMP, ppp 2.4.4b1 + SC_MUST_COMP, pptpd 1.3.1 - client, 2.6.12.5 + SC_MUST_COMP, ppp 2.4.4b1 + SC_MUST_COMP, pptp 1.5.0 Client side pppd log fragment; local IP address 10.8.0.2 remote IP address 10.8.0.1 Script /etc/ppp/ip-up started (pid 5036) Script /etc/ppp/ip-up finished (pid 5036), status = 0x0 rcvd [LCP TermReq id=0x2 "MPPE disabled"] LCP terminated by peer (MPPE disabled) Connect time 0.4 minutes. Sent 262920 bytes, received 262920 bytes. Script /etc/ppp/ip-down started (pid 5048) sent [LCP TermAck id=0x2] rcvd [CCP ConfReq id=0x2 ] Discarded non-LCP packet when LCP not open Script /etc/ppp/ip-down finished (pid 5048), status = 0x0 Connection terminated. Modem hangup -- James Cameron signature.asc Description: Digital signature
Re: ppp_mppe+pptp for 2.6.14?
On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote: > I've asked James Cameron, pptp project lead, to try a test to force > the server side to issue a CCP DOWN, to make sure the client-side > kernel ppp_generic module does the right thing and drops packets. I'm still working on this; tried Matt's patch against 2.6.13 last night, but it seems 2.6.13 has broken raw sockets for pptp and pptpd ... ENOPROTOOPT returned from the read() on the raw socket carrying the GRE stream from pptp to the net. Wasn't happening with 2.6.12.5. My plan is to try Matt's patch against 2.6.12.5, and try 2.6.13 bare, to isolate the cause of the ENOPROTOOPT changed behaviour. The previous version of Matt's patch (before the SC_MUST_COMP feature) is working fine for me with 2.6.12.5. (If anyone has any ideas on raw socket breakage, let me know. 2.6.13 changed net/ipv4/raw.c but the changes look to me to be minor.) -- James Cameron signature.asc Description: Digital signature
Re: ppp_mppe+pptp for 2.6.14?
On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote: I've asked James Cameron, pptp project lead, to try a test to force the server side to issue a CCP DOWN, to make sure the client-side kernel ppp_generic module does the right thing and drops packets. I'm still working on this; tried Matt's patch against 2.6.13 last night, but it seems 2.6.13 has broken raw sockets for pptp and pptpd ... ENOPROTOOPT returned from the read() on the raw socket carrying the GRE stream from pptp to the net. Wasn't happening with 2.6.12.5. My plan is to try Matt's patch against 2.6.12.5, and try 2.6.13 bare, to isolate the cause of the ENOPROTOOPT changed behaviour. The previous version of Matt's patch (before the SC_MUST_COMP feature) is working fine for me with 2.6.12.5. (If anyone has any ideas on raw socket breakage, let me know. 2.6.13 changed net/ipv4/raw.c but the changes look to me to be minor.) -- James Cameron signature.asc Description: Digital signature
Re: ppp_mppe+pptp for 2.6.14?
My problems with ENOPROTOOPT were due to lack of coffee. They were caused by ICMP protocol unreachable responses from the test server because I'd taken away it's pppd. My mistake. On Mon, Aug 29, 2005 at 05:10:34PM -0500, Matt Domsch wrote: I've asked James Cameron, pptp project lead, to try a test to force the server side to issue a CCP DOWN, to make sure the client-side kernel ppp_generic module does the right thing and drops packets. I've tested this now with a host running kernel 2.6.13 with Matt's SC_MUST_COMP patch to the kernel and to ppp 2.4.4b1, sending SIGUSR2 to the pppd while flooding the connection with pings from the server. The result is an LCP TermReq from the server to the client, after which no further data packets appear. All the data packets up to the LCP TermReq are encrypted. The client sends an LCP TermAck, then takes down the interface. There's sign of CCP down, in that a CCP ConfReq appears from the server just after the LCP TermReq. I'm not sure this is an adequate test, and will take advice on that. Test configuration; - server, 2.6.13 + SC_MUST_COMP, ppp 2.4.4b1 + SC_MUST_COMP, pptpd 1.3.1 - client, 2.6.12.5 + SC_MUST_COMP, ppp 2.4.4b1 + SC_MUST_COMP, pptp 1.5.0 Client side pppd log fragment; local IP address 10.8.0.2 remote IP address 10.8.0.1 Script /etc/ppp/ip-up started (pid 5036) Script /etc/ppp/ip-up finished (pid 5036), status = 0x0 rcvd [LCP TermReq id=0x2 MPPE disabled] LCP terminated by peer (MPPE disabled) Connect time 0.4 minutes. Sent 262920 bytes, received 262920 bytes. Script /etc/ppp/ip-down started (pid 5048) sent [LCP TermAck id=0x2] rcvd [CCP ConfReq id=0x2 mppe +H -M +S -L -D -C] Discarded non-LCP packet when LCP not open Script /etc/ppp/ip-down finished (pid 5048), status = 0x0 Connection terminated. Modem hangup -- James Cameron signature.asc Description: Digital signature
