Am 30.04.2007 21:46 schrieb Andrew Morton:
> Not really - everything's tangled up. A bisection search on the
> 2.6.21-rc7-mm2 driver tree would be the best bet.
And the winner is:
gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
again.
I'll try building 2.6.21-git3 minus that one next, but I'll have
to revert it manually, because my naive attempt to "patch -R" it
failed 1 out of 2 hunks.
HTH
T.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -
On Wed, May 02, 2007 at 09:01:22AM +0200, Tilman Schmidt wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
> > Not really - everything's tangled up. A bisection search on the
> > 2.6.21-rc7-mm2 driver tree would be the best bet.
>
> And the winner is:
>
> gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
>
> Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> again.
>
> I'll try building 2.6.21-git3 minus that one next, but I'll have
> to revert it manually, because my naive attempt to "patch -R" it
> failed 1 out of 2 hunks.
Ok, that's just wierd, it only adds a new feature, it doesn't touch any
existing code to cause things to go wrong.
Can you try using 'git bisect' on Linus's tree instead? That should
show the real problem much easier.
thanks,
greg k-h
On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <[email protected]> wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
> > Not really - everything's tangled up. A bisection search on the
> > 2.6.21-rc7-mm2 driver tree would be the best bet.
>
> And the winner is:
>
> gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
>
> Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> again.
cripes.
+static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct kobject *top_kobj;
+ struct kset *kset;
+ char *envp[32];
+ char data[PAGE_SIZE];
That won't work too well with 4k stacks.
Who's reviewing this stuff? The patch headers indicate that no mailing list was
cc'ed?
Tilman Schmidt wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
>
>>Not really - everything's tangled up. A bisection search on the
>>2.6.21-rc7-mm2 driver tree would be the best bet.
>
>
> And the winner is:
>
> gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
+ struct kobject *top_kobj;
+ struct kset *kset;
+ char *envp[32];
+ char data[PAGE_SIZE];
+ char *pos;
+ int i;
+ size_t count = 0;
+ int retval;
... that seems like a lot of stack to be using.
--
SUSE Labs, Novell Inc.
On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <[email protected]> wrote:
>
> > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > Not really - everything's tangled up. A bisection search on the
> > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> >
> > And the winner is:
> >
> > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> >
> > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > again.
>
> cripes.
>
> +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct kobject *top_kobj;
> + struct kset *kset;
> + char *envp[32];
> + char data[PAGE_SIZE];
>
> That won't work too well with 4k stacks.
Oh crap. Yeah, that's not nice.
> Who's reviewing this stuff? The patch headers indicate that no mailing list was
> cc'ed?
Kay and I did this, sorry, it should have been cc:ed to lkml.
I'll go fix it up now...
thanks,
greg k-h
On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <[email protected]> wrote:
>
> > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > Not really - everything's tangled up. A bisection search on the
> > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> >
> > And the winner is:
> >
> > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> >
> > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > again.
>
> cripes.
>
> +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct kobject *top_kobj;
> + struct kset *kset;
> + char *envp[32];
> + char data[PAGE_SIZE];
>
> That won't work too well with 4k stacks.
Wait, even though this isn't good, it shouldn't have been hit by anyone,
that file used to not be readable, so I doubt userspace would have been
trying to read it...
Tilman, what version of HAL and udev do you have on your machine?
Kay, did you get the 'read the uevent file' code already into udev
and/or HAL?
thanks,
greg k-h
On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <[email protected]> wrote:
>
> > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > Not really - everything's tangled up. A bisection search on the
> > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> >
> > And the winner is:
> >
> > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> >
> > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > again.
>
> cripes.
>
> +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct kobject *top_kobj;
> + struct kset *kset;
> + char *envp[32];
> + char data[PAGE_SIZE];
>
> That won't work too well with 4k stacks.
Tilman, here's a patch, can you try this on top of your tree that dies?
thanks,
greg k-h
---
drivers/base/core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -252,7 +252,7 @@ static ssize_t show_uevent(struct device
struct kobject *top_kobj;
struct kset *kset;
char *envp[32];
- char data[PAGE_SIZE];
+ char *data = NULL;
char *pos;
int i;
size_t count = 0;
@@ -276,6 +276,10 @@ static ssize_t show_uevent(struct device
if (!kset->uevent_ops->filter(kset, &dev->kobj))
goto out;
+ data = (char *)get_zeroed_page(GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
/* let the kset specific function add its keys */
pos = data;
retval = kset->uevent_ops->uevent(kset, &dev->kobj,
@@ -290,6 +294,7 @@ static ssize_t show_uevent(struct device
count += sprintf(pos, "%s\n", envp[i]);
}
out:
+ free_page((unsigned long)data);
return count;
}
On Wed, 2 May 2007 00:43:05 -0700, "Greg KH" <[email protected]> said:
> > > And the winner is:
> > >
> > > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> > >
> > > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > > again.
>
> Wait, even though this isn't good, it shouldn't have been hit by anyone,
> that file used to not be readable, so I doubt userspace would have been
> trying to read it...
>
> Tilman, what version of HAL and udev do you have on your machine?
The ones that came with SuSE 10.0:
hal-0.5.4-6.4
udev-068git20050831-9
HTH
Tilman
PS: I'll test your patch and git-bisect when I'm back at the machine.
--
Tilman Schmidt
[email protected]
On 5/2/07, Greg KH <[email protected]> wrote:
> On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> > On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <[email protected]> wrote:
> >
> > > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > > Not really - everything's tangled up. A bisection search on the
> > > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> > >
> > > And the winner is:
> > >
> > > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> > >
> > > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > > again.
> >
> > cripes.
> >
> > +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct kobject *top_kobj;
> > + struct kset *kset;
> > + char *envp[32];
> > + char data[PAGE_SIZE];
> >
> > That won't work too well with 4k stacks.
Yeah, sorry.
> Wait, even though this isn't good, it shouldn't have been hit by anyone,
> that file used to not be readable, so I doubt userspace would have been
> trying to read it...
>
> Tilman, what version of HAL and udev do you have on your machine?
>
> Kay, did you get the 'read the uevent file' code already into udev
> and/or HAL?
Only udevtest uses this at the moment, but that is only used for debugging.
It's probably the brain-dead libsysfs, which opens and reads every
file in /sys, even when nobody is interested in the data.
Thanks,
Kay
Am 02.05.2007 09:52 schrieb Greg KH:
> Tilman, here's a patch, can you try this on top of your tree that dies?
2.6.21-git3 plus that patch comes up fine.
(Except for a UDP problem I seem to remember I already saw reported
on lkml and which I'll ignore for now in order not to blur the
picture.)
Started to git-bisect mainline now, but that will take some time.
It's more than 800 patches to check and I don't get more than 2-3
iterations per day out of that machine.
HTH
T.
> ---
> drivers/base/core.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -252,7 +252,7 @@ static ssize_t show_uevent(struct device
> struct kobject *top_kobj;
> struct kset *kset;
> char *envp[32];
> - char data[PAGE_SIZE];
> + char *data = NULL;
> char *pos;
> int i;
> size_t count = 0;
> @@ -276,6 +276,10 @@ static ssize_t show_uevent(struct device
> if (!kset->uevent_ops->filter(kset, &dev->kobj))
> goto out;
>
> + data = (char *)get_zeroed_page(GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> /* let the kset specific function add its keys */
> pos = data;
> retval = kset->uevent_ops->uevent(kset, &dev->kobj,
> @@ -290,6 +294,7 @@ static ssize_t show_uevent(struct device
> count += sprintf(pos, "%s\n", envp[i]);
> }
> out:
> + free_page((unsigned long)data);
> return count;
> }
>
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -
On Wed, 02 May 2007 19:36:03 +0200
Tilman Schmidt <[email protected]> wrote:
> Am 02.05.2007 09:52 schrieb Greg KH:
> > Tilman, here's a patch, can you try this on top of your tree that dies?
>
> 2.6.21-git3 plus that patch comes up fine.
>
> (Except for a UDP problem I seem to remember I already saw reported
> on lkml and which I'll ignore for now in order not to blur the
> picture.)
Thanks.
> Started to git-bisect mainline now, but that will take some time.
> It's more than 800 patches to check and I don't get more than 2-3
> iterations per day out of that machine.
I don't think there's much point in you doing that. We know what the bug is.
Switching to 8k stacks will probably fix things up too.
Am 02.05.2007 22:07 schrieb Andrew Morton:
>> Started to git-bisect mainline now, but that will take some time.
[...]
> I don't think there's much point in you doing that. We know what the bug is.
Good. Saves me some work. :-)
If you'd like me to test anything, just let me know.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -
On Wed, May 02, 2007 at 11:41:22AM +0200, Tilman Schmidt wrote:
> On Wed, 2 May 2007 00:43:05 -0700, "Greg KH" <[email protected]> said:
>
> > > > And the winner is:
> > > >
> > > > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> > > >
> > > > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > > > again.
> >
> > Wait, even though this isn't good, it shouldn't have been hit by anyone,
> > that file used to not be readable, so I doubt userspace would have been
> > trying to read it...
> >
> > Tilman, what version of HAL and udev do you have on your machine?
>
> The ones that came with SuSE 10.0:
>
> hal-0.5.4-6.4
> udev-068git20050831-9
Ah, ok, that explains it, the really old libsysfs walks and opens all
files in sysfs for some odd, strange, and broken reason. This has been
fixed in newer versions, and explains why you are seeing this happen.
I'll send my fix for this to Linus in a few hours.
thanks for testing and tracking this down, I really appreciate it.
greg k-h