Paul Jackson <[email protected]> wrote:
>
> Ok - down to the patch:
>
> 1) gregkh-driver-empty_release_functions_are_broken.patch - good
> 2) gregkh-driver-allow-sysfs-attribute-files-to-be-pollable.patch - special case
> 3) gregkh-driver-fix-up-the-sysfs-pollable-patch.patch - bad
>
> Up through and including (1), it all seems fine.
OK, thanks. So
gregkh-driver-allow-sysfs-attribute-files-to-be-pollable.patch is the
problem. Odd.
<looks at sysfs_poll()>
If that gets called on a top-level file in /sys, won't
filp->f_dentry->d_parent be pointing at a non-sysfs dentry?
> With (3) or more loaded, it fails to boot, with the crash
> given before (and appended below for completeness).
>
> With patchs up through (2) loaded, it boots, but complains 27
> times during the boot
>
> One of the 27 complaints for special case (2):
> ================================= begin =================================
> Debug: sleeping function called from invalid context at drivers/base/core.c:343^M
> in_atomic():1, irqs_disabled():0^M
> ^M
> Call Trace:^M
> [<a0000001000132c0>] show_stack+0x40/0xa0^M
> sp=e00002bc3a49f9b0 bsp=e00002bc3a499558^M
> [<a000000100013b50>] dump_stack+0x30/0x60^M
> sp=e00002bc3a49fb80 bsp=e00002bc3a499540^M
> [<a00000010008ff80>] __might_sleep+0x200/0x220^M
> sp=e00002bc3a49fb80 bsp=e00002bc3a499510^M
> [<a0000001004b58b0>] put_device+0x30/0x60^M
> sp=e00002bc3a49fb90 bsp=e00002bc3a4994f0^M
> [<a00000010051e470>] scsi_put_command+0x170/0x1a0^M
> sp=e00002bc3a49fb90 bsp=e00002bc3a499498^M
> [<a000000100528c80>] scsi_next_command+0x40/0x80^M
> sp=e00002bc3a49fb90 bsp=e00002bc3a499468^M
> [<a0000001005296a0>] scsi_end_request+0x1a0/0x1e0^M
> sp=e00002bc3a49fb90 bsp=e00002bc3a499420^M
> [<a000000100529a50>] scsi_io_completion+0x370/0x820^M
> sp=e00002bc3a49fb90 bsp=e00002bc3a499388^M
Yeah, known problem - big messiness in scsi. That's why -mm includes
revert-gregkh-driver-put_device-might_sleep.patch. Looks like I need to
add revert-gregkh-driver-allow-sysfs-attribute-files-to-be-pollable.patch too ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
