From: lee.jones@canonical.com (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Stop ARM boards crashing when CUPS is loaded - 2.6.35-rc5
Date: Fri, 16 Jul 2010 10:08:26 +0100 [thread overview]
Message-ID: <4C40218A.4090806@canonical.com> (raw)
In-Reply-To: <20100715200618.GA6773@n2100.arm.linux.org.uk>
On 15/07/10 21:06, Russell King - ARM Linux wrote:
> On Thu, Jul 15, 2010 at 01:02:14PM -0700, Andrew Morton wrote:
>>> BugLink: http://bugs.launchpad.net/bugs/601226
>>>
>>> When CUPS loads, it tries to load several drivers that it may need.
>>> When one of these drivers, specifically parport_pc is loaded on ARM
>>> based systems, it causes a segmentation fault as the ISA addresses
>>> which are attempted are not writable on non-PC based architectures.
>>> This code prevents ISA addresses from being attempted except on x86.
>>>
>>
>> That sounds like a pretty serious problem. But presumably it isn't -
>> otherwise it would have been fixed earlier!
Well it is a problem on OMAP based boards.
I've personally tested it on OMAP3 and OMAP4 based machines.
Perhaps the memory is not reserved correctly.
>> So what actions are required to trigger this bug and why aren't others
>> seeing it?
Probably because most other chips either manage to reserve the memory
successfully, or do not attempt to load the parport_pc driver, either as
a module or built-in.
All I have to do to recreate this bug is load the module or build in the
parport_pc driver.
> Note that we have machines which have ISA parallel ports, so it's not
> this simple.
Do they have ISA parallel ports, or do they just pretend to?
I found this scattered about:
/*
* We don't actually have real ISA nor PCI buses, but there is so many
* drivers out there that might just work if we fake them...
*/
Clearly parport_pc isn't one of them. :)
> Why not just avoid selecting and building parport_pc on these machines?
> I mean, the Beagleboard doesn't have PCI nor ISA, so why is parport_pc
> being built for production use?
I am happy to make a Kconfig change to disallow OMAP builds from building
the parport_pc driver. Do you think this would be more sensible?
WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@canonical.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] Stop ARM boards crashing when CUPS is loaded - 2.6.35-rc5
Date: Fri, 16 Jul 2010 10:08:26 +0100 [thread overview]
Message-ID: <4C40218A.4090806@canonical.com> (raw)
In-Reply-To: <20100715200618.GA6773@n2100.arm.linux.org.uk>
On 15/07/10 21:06, Russell King - ARM Linux wrote:
> On Thu, Jul 15, 2010 at 01:02:14PM -0700, Andrew Morton wrote:
>>> BugLink: http://bugs.launchpad.net/bugs/601226
>>>
>>> When CUPS loads, it tries to load several drivers that it may need.
>>> When one of these drivers, specifically parport_pc is loaded on ARM
>>> based systems, it causes a segmentation fault as the ISA addresses
>>> which are attempted are not writable on non-PC based architectures.
>>> This code prevents ISA addresses from being attempted except on x86.
>>>
>>
>> That sounds like a pretty serious problem. But presumably it isn't -
>> otherwise it would have been fixed earlier!
Well it is a problem on OMAP based boards.
I've personally tested it on OMAP3 and OMAP4 based machines.
Perhaps the memory is not reserved correctly.
>> So what actions are required to trigger this bug and why aren't others
>> seeing it?
Probably because most other chips either manage to reserve the memory
successfully, or do not attempt to load the parport_pc driver, either as
a module or built-in.
All I have to do to recreate this bug is load the module or build in the
parport_pc driver.
> Note that we have machines which have ISA parallel ports, so it's not
> this simple.
Do they have ISA parallel ports, or do they just pretend to?
I found this scattered about:
/*
* We don't actually have real ISA nor PCI buses, but there is so many
* drivers out there that might just work if we fake them...
*/
Clearly parport_pc isn't one of them. :)
> Why not just avoid selecting and building parport_pc on these machines?
> I mean, the Beagleboard doesn't have PCI nor ISA, so why is parport_pc
> being built for production use?
I am happy to make a Kconfig change to disallow OMAP builds from building
the parport_pc driver. Do you think this would be more sensible?
next prev parent reply other threads:[~2010-07-16 9:08 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-13 14:05 [PATCH] Stop ARM boards crashing when CUPS is loaded - 2.6.35-rc5 Lee Jones
2010-07-15 20:02 ` Andrew Morton
2010-07-15 20:02 ` Andrew Morton
2010-07-15 20:06 ` Russell King - ARM Linux
2010-07-15 20:06 ` Russell King - ARM Linux
2010-07-16 9:08 ` Lee Jones [this message]
2010-07-16 9:08 ` Lee Jones
2010-07-16 9:20 ` Russell King - ARM Linux
2010-07-16 9:20 ` Russell King - ARM Linux
2010-07-16 9:32 ` Lee Jones
2010-07-16 9:32 ` Lee Jones
2010-07-16 11:12 ` Lee Jones
2010-07-16 11:12 ` Lee Jones
2010-07-26 22:26 ` Greg KH
2010-07-26 22:26 ` Greg KH
2010-07-16 16:23 ` Milton Miller
2010-07-16 16:23 ` Milton Miller
2010-07-16 16:42 ` Lee Jones
2010-07-16 16:42 ` Lee Jones
2010-07-16 19:38 ` Milton Miller
2010-07-16 19:38 ` Milton Miller
2010-07-16 20:54 ` Russell King - ARM Linux
2010-07-16 20:54 ` Russell King - ARM Linux
2010-07-16 9:37 ` Martin Michlmayr
2010-07-16 9:37 ` Martin Michlmayr
2010-07-16 13:27 ` Woody Suwalski
2010-07-16 13:27 ` Woody Suwalski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C40218A.4090806@canonical.com \
--to=lee.jones@canonical.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.