On Tuesday, 31 October 2006 08:40, Andrew Morton wrote: > On Tue, 31 Oct 2006 08:29:28 +0100 > "Rafael J. Wysocki" <rjw@xxxxxxx> 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? - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
