HAL blocks suspend

Funky; not entirely sure how to debug this, presumbly it is itself blocking on a syscall or some such.

This happens to me to.

May 9 17:11:54 walkabouts kernel: [4298830.564000] stopping tasks failed (1 tasks remaining)
May 9 17:11:54 walkabouts kernel: [4298830.564000] Restarting tasks...<6> Strange, hald-addon-stor not stopped
May 9 17:11:54 walkabouts NetworkManager: <WARNING>^I nm_device_802_11_wireless_get_mode (): error getting card mode on eth0: No such device
May 9 17:11:54 walkabouts NetworkManager: <debug info>^I[1147187514.295227] nm_hal_device_removed (): Device removed (hal udi is '/org/freedesktop/Hal/devices/net_00_0f_1f_b9_6e_26').
May 9 17:11:54 walkabouts NetworkManager: <information>^IDeactivating device eth1.
May 9 17:11:54 walkabouts kernel: [4298830.768000] done

Happens to me during every other suspend attempt I make.

05/10/2006 08:31:07 AM Abila kernel [4336483.674000] ACPI: PCI interrupt for device 0000:02:01.0 disabled
05/10/2006 08:31:07 AM Abila kernel [4336483.677000] ieee80211_1_1_13_crypt: unregistered algorithm 'NULL'
05/10/2006 08:31:07 AM Abila kernel [4336483.693000] ACPI: PCI interrupt for device 0000:02:05.0 disabled
05/10/2006 08:31:16 AM Abila kernel [4336486.584000] Stopping tasks: ==========================================
05/10/2006 08:31:16 AM Abila kernel [4336492.585000] Restarting tasks...<6> Strange, hald-addon-stor not stopped
05/10/2006 08:31:16 AM Abila kernel [4336492.585000] stopping tasks failed (2 tasks remaining)
05/10/2006 08:31:16 AM Abila kernel [4336492.585000] Strange, hald-addon-stor not stopped
05/10/2006 08:31:16 AM Abila kernel [4336492.587000] done
05/10/2006 09:43:51 AM Abila kernel [4294667.296000] 110MB HIGHMEM available.
05/10/2006 09:43:51 AM Abila kernel [4294667.296000] 896MB LOWMEM available.

I'm also seeing this bug. How do I get hald to output more info about what it is doing to try and track down what is causing this?

I'm also having this problem in a Dell Inspiron 710m with Dapper. It sometimes suspend or hibernate correctly, but after some time of use, it stops working with the same output. If I look in ps aux I see 2 hald-addon-storage in D. I guess that's why the kernel can not stop them. Doing an strace on this processes I saw that they are monitoring the CDROM (/dev/hdc in this computer), and I think this is related to the fact that sometimes the cdrom does not automount and I have to restart the computer to be able to mount the cdrom.
Is there any information that I can gather to help the debug?

Lucas Chiesa

I have found that I don't see this bug when I leave a CD in the drive.

I have put the output of lshw up at http://ormiret.com/bugreport.txt
IDE chip is an Intel ICH6 family 82801FB/FBM/FR/FW/FRW with a PHILIPS CD-RW/DVD-ROM SCB5265

I have the exact same problem with a Compaq V2000. I also have a PHILIPS SCB5265.

Leaving a CD in the try did the trick here. The hald process no longer goes D.

I'm hitting the same problem on my dell inspiron 9300 here. Attaching dmesg, it contains a bunch of ata errors which look like they're related to the cd drive alright.

My IDE chipset is:
0000:00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03)

My cdrom is:
Vendor: PHILIPS Model: CDRW/DVD SCB5265 Rev: TD15

Updating the firmware on the dvd drive seems to have solved the problem for me. I used the firmware update from the Dell support site (version TD17) on my Compaq V2000 with a PHILIPS SCB5265. The update took a good three minutes, but I haven't had any problems so far.

If the process hangs in eternal kernel sleep, then it is probably hanging in some non-returning ioctl. Since it was fixed by a CD-ROM firmware upgrade, it's most likely a hardware problem, but maybe this can be timed out in the kernel in some way.

Hi. I found this bug report while coming from http://bugzilla.gnome.org/show_bug.cgi?id=356441 and it seems most likely that my problem is the same as described here, because I have that Philips SCB5265SE distributed on an Acer Travelmate 2428 notebook. I *guess* the firmware is TX11-C, that's what's written on the drive.

Anyhow, what I would like to say is:
- acer provides no firmware
- philips provides no firmware

I have no way of changing the firmware. Now, this is not such a big issue because I practically never use optical drives, so I just took out the drive (I will see if that fixes the problem). HOWEVER, I would think this would be important to be fixed in software, not just assuming that everyone should upgrade their firmware... Unless I am 100% confident the dell firmware would work on an acer one. Hmm :|

Could anyone confirm? I have the weird feeling this one got fixed after edgy final.

Nope, still happens sometimes.

Yes, I still get this on my 700m often (once out of 3 or 4 suspends).
Edgy made no change at all in this issue for me.

,Justin Becker

On 11/3/06, Jeff Fortin <email address hidden> wrote:
> Could anyone confirm? I have the weird feeling this one got fixed after
> edgy final.
>
> --
> HAL blocks suspend
> https://launchpad.net/bugs/40800
>

--
God Bless,
Justin G Becker
<email address hidden>
University of New Mexico

I haven't seen this problem again since I installed edgy (a while before release so I think it would have cropped up by now if it was going to...)

This problem is still present in edgy, in my Inspiron 710m. I've just updated the CD drive firmware to see if this solves the problem. I have a PHILIPS SCB5265 drive.

Hardy Heron 8.04 was recently released. It would be helpful if you could test the new release and verify if this is still an issue - http://www.ubuntu.com/testing . You should be able to test your bug using the LiveCD. Please let us know your results. Thanks.

 We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!