Re: 2.6.19-rc3-mm1 - udev doesn't work (was: ATI SATA controller not detected)

Re: 2.6.19-rc3-mm1 - udev doesn't work (was: ATI SATA controller not detected)

[Rafael J. Wysocki]

On Monday, 30 October 2006 21:57, Greg KH wrote:
> On Mon, Oct 30, 2006 at 09:48:33PM +0100, Rafael J. Wysocki wrote:
> > On Monday, 30 October 2006 21:22, Greg KH wrote:
> > > On Mon, Oct 30, 2006 at 09:15:37PM +0100, Rafael J. Wysocki wrote:
> > > > Sorry, I was wrong.
> > > > 
> > > > The controller _is_ detected and handled properly, but udev is apparently
> > > > unable to create the special device files for SATA drives/partitions even
> > > > though CONFIG_SYSFS_DEPRECATED is set.
> > > 
> > > This config option should not affect the block device sysfs files at all
> > > at this point in time.
> > > 
> > > What does 'tree /sys/block/' show?
> > 
> > I can't run 'tree', but 'ls' works somehow (can't mount the root fs).  The
> > block device sysfs files seem to be present
> 
> If they are there, then udev should work just fine.
> 
> > > If the files show up there properly, udev should handle them just fine.
> > 
> > It doesn't.
> > 
> > Well, I can binary search for the offending patch if that helps.
> 
> That would be very helpful, thanks.

It's one of these:

git-acpi.patch
git-acpi-fixup.patch
git-acpi-more-build-fixes.patch

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: 2.6.19-rc3-mm1 - udev doesn't work (was: ATI SATA controller not detected)

[Rafael J. Wysocki]

[Resending due to a network problem on my side.]

On Monday, 30 October 2006 21:57, Greg KH wrote:
> On Mon, Oct 30, 2006 at 09:48:33PM +0100, Rafael J. Wysocki wrote:
> > On Monday, 30 October 2006 21:22, Greg KH wrote:
> > > On Mon, Oct 30, 2006 at 09:15:37PM +0100, Rafael J. Wysocki wrote:
> > > > Sorry, I was wrong.
> > > > 
> > > > The controller _is_ detected and handled properly, but udev is apparently
> > > > unable to create the special device files for SATA drives/partitions even
> > > > though CONFIG_SYSFS_DEPRECATED is set.
> > > 
> > > This config option should not affect the block device sysfs files at all
> > > at this point in time.
> > > 
> > > What does 'tree /sys/block/' show?
> > 
> > I can't run 'tree', but 'ls' works somehow (can't mount the root fs).  The
> > block device sysfs files seem to be present
> 
> If they are there, then udev should work just fine.
> 
> > > If the files show up there properly, udev should handle them just fine.
> > 
> > It doesn't.
> > 
> > Well, I can binary search for the offending patch if that helps.
> 
> That would be very helpful, thanks.

It's one of these:

git-acpi.patch
git-acpi-fixup.patch
git-acpi-more-build-fixes.patch

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: 2.6.19-rc3-mm1 - udev doesn't work (was: ATI SATA controller not detected)

[Andrew Morton]

On Tue, 31 Oct 2006 08:29:28 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> [Resending due to a network problem on my side.]
> 
> On Monday, 30 October 2006 21:57, Greg KH wrote:
> > On Mon, Oct 30, 2006 at 09:48:33PM +0100, Rafael J. Wysocki wrote:
> > > On Monday, 30 October 2006 21:22, Greg KH wrote:
> > > > On Mon, Oct 30, 2006 at 09:15:37PM +0100, Rafael J. Wysocki wrote:
> > > > > Sorry, I was wrong.
> > > > > 
> > > > > The controller _is_ detected and handled properly, but udev is apparently
> > > > > unable to create the special device files for SATA drives/partitions even
> > > > > though CONFIG_SYSFS_DEPRECATED is set.
> > > > 
> > > > This config option should not affect the block device sysfs files at all
> > > > at this point in time.
> > > > 
> > > > What does 'tree /sys/block/' show?
> > > 
> > > I can't run 'tree', but 'ls' works somehow (can't mount the root fs).  The
> > > block device sysfs files seem to be present
> > 
> > If they are there, then udev should work just fine.
> > 
> > > > If the files show up there properly, udev should handle them just fine.
> > > 
> > > It doesn't.
> > > 
> > > Well, I can binary search for the offending patch if that helps.
> > 
> > That would be very helpful, thanks.
> 
> It's one of these:
> 
> git-acpi.patch
> git-acpi-fixup.patch
> git-acpi-more-build-fixes.patch
> 

You might need to resend the original report so the acpi guys can see it.

Meanwhile, I'll have to drop the acpi tree.

Re: 2.6.19-rc3-mm1 - udev doesn't work (was: ATI SATA controller not detected)

[Rafael J. Wysocki]

On Tuesday, 31 October 2006 08:40, Andrew Morton wrote:
> On Tue, 31 Oct 2006 08:29:28 +0100
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > [Resending due to a network problem on my side.]
> > 
> > On Monday, 30 October 2006 21:57, Greg KH wrote:
> > > On Mon, Oct 30, 2006 at 09:48:33PM +0100, Rafael J. Wysocki wrote:
> > > > On Monday, 30 October 2006 21:22, Greg KH wrote:
> > > > > On Mon, Oct 30, 2006 at 09:15:37PM +0100, Rafael J. Wysocki wrote:
> > > > > > Sorry, I was wrong.
> > > > > > 
> > > > > > The controller _is_ detected and handled properly, but udev is apparently
> > > > > > unable to create the special device files for SATA drives/partitions even
> > > > > > though CONFIG_SYSFS_DEPRECATED is set.
> > > > > 
> > > > > This config option should not affect the block device sysfs files at all
> > > > > at this point in time.
> > > > > 
> > > > > What does 'tree /sys/block/' show?
> > > > 
> > > > I can't run 'tree', but 'ls' works somehow (can't mount the root fs).  The
> > > > block device sysfs files seem to be present
> > > 
> > > If they are there, then udev should work just fine.
> > > 
> > > > > If the files show up there properly, udev should handle them just fine.
> > > > 
> > > > It doesn't.
> > > > 
> > > > Well, I can binary search for the offending patch if that helps.
> > > 
> > > That would be very helpful, thanks.
> > 
> > It's one of these:
> > 
> > git-acpi.patch
> > git-acpi-fixup.patch
> > git-acpi-more-build-fixes.patch
> > 
> 
> You might need to resend the original report so the acpi guys can see it.

Okay, I will.

> Meanwhile, I'll have to drop the acpi tree.

Well, I'd prefer to find the offending commit within the tree, as the majority
of changes look pretty innocent.  Are the commits available somewhere as
individual patches?

Re: 2.6.19-rc3-mm1 - udev doesn't work (was: ATI SATA controller not detected)

[Andrew Morton]

On Tue, 31 Oct 2006 08:48:01 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> > > It's one of these:
> > > 
> > > git-acpi.patch
> > > git-acpi-fixup.patch
> > > git-acpi-more-build-fixes.patch
> > > 
> > 
> > You might need to resend the original report so the acpi guys can see it.
> 
> Okay, I will.

Thanks.

> > Meanwhile, I'll have to drop the acpi tree.
> 
> Well, I'd prefer to find the offending commit within the tree, as the majority
> of changes look pretty innocent.  Are the commits available somewhere as
> individual patches?

git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test

I've not had much success persuading git to emit a series of applyable
patches.

Re: 2.6.19-rc3-mm1 - udev doesn't work

[Andy Whitcroft]

Andrew Morton wrote:
> On Tue, 31 Oct 2006 08:48:01 +0100
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
>>>> It's one of these:
>>>>
>>>> git-acpi.patch
>>>> git-acpi-fixup.patch
>>>> git-acpi-more-build-fixes.patch
>>>>
>>> You might need to resend the original report so the acpi guys can see it.
>> Okay, I will.
> 
> Thanks.
> 
>>> Meanwhile, I'll have to drop the acpi tree.
>> Well, I'd prefer to find the offending commit within the tree, as the majority
>> of changes look pretty innocent.  Are the commits available somewhere as
>> individual patches?
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test
> 
> I've not had much success persuading git to emit a series of applyable
> patches.

git-format-patch can make a patch file for each commit in range, each
prefixed with a four digit patch number and named similarly to patches
in -mm:

    git format-patch -o <dir> <from>..<to>

For example:

    0009-DM-kill-bogus-uninit-warning.txt
    0010-drivers-net-drivers-net-Silence-more-bogosities.txt
    0011-debug-shared-irqs.txt
    0012-debug-shared-irqs-kconfig-fix.txt
    0013-make-frame_pointer-default-y.txt

It can also produce an mbox mailbox:

    git format-patch --stdout <from>..<to>

I've used this second form in combination with a 'mailbomb' exploder to
extract the patches with a series file.

-apw