Re: [2.6.2-rc1] sleep called from invalid context (8250/ACPI related?)

Re: [2.6.2-rc1] sleep called from invalid context (8250/ACPI related?)

[Andrew Morton]

Rui Saraiva <rmps-8boff9MBBEKJoy8PIJZ9VA@public.gmane.org> wrote:
>
> --------------------------------------------------------------------------------|
> 	Hello,
> 
> 	I've found this message in my logs while investigating some kernel Oops
> (in other message). If you need more info, please ask.
> 
> 	Regards,
> 		Rui Saraiva
> 
> 
> Debug: sleeping function called from invalid context at include/asm/semaphore.h:119
> in_atomic():1, irqs_disabled():0
> Call Trace:
>  [<c0122ddb>] __might_sleep+0xab/0xd0
>  [<d1bd2df6>] uart_unregister_port+0x76/0xa9 [serial_core]
>  [<d1bd9559>] unregister_serial+0x19/0x20 [8250]
>  [<d1bcb2de>] acpi_serial_remove+0x2e/0x50 [8250_acpi]
>  [<c02523f0>] acpi_driver_detach+0xcc/0x184
>  [<c0252621>] acpi_bus_unregister_driver+0x18/0x168
>  [<d1bcb312>] acpi_serial_exit+0x12/0x14 [8250_acpi]
>  [<c014510f>] sys_delete_module+0x13f/0x160
>  [<c0166307>] sys_munmap+0x57/0x80
>  [<c010a14f>] syscall_call+0x7/0xb

acpi_driver_detach is calling the acpi_driver.remove() method under
the acpi_device_lock spinlock.

uart_unregister_port() happens to be using a semaphore for its locking.

I do think that it would be better if ACPI were to permit this.  From a
quick peek it appears that acpi_device_lock can simply become a semaphore?



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn