System halts when entropy exhausted, continues when it receivews new entropy
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Expired
|
Undecided
|
Unassigned |
Bug Description
The system halts when entropy is exhausted, then continues when it receives more entropy.
This happens during boot, necessitating key-twiddling or mouse-jiggling in order to boot.
Once the system is fully booted, if one pings it, pings work at first, then halt when the entropy is exhausted. When new entropy is provided (mouse jiggle/key twiddle) they continue.
I'm checking entropy by looking in /proc/sys/
Note, I do not own this laptop, I was asked to fix it, and will return it to it's owner now, suggesting they install ubuntu 10.04 (which worked), or a different distro. Hopefully there will be enough information in the bug report to track down why the system is using entropy all the time.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: linux-image-
Regression: Yes
Reproducible: Yes
ProcVersionSign
Uname: Linux 2.6.35-22-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
AplayDevices:
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC272 Analog [ALC272 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
Architecture: i386
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC272 Analog [ALC272 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xf0440000 irq 46'
Mixer name : 'Realtek ALC272'
Components : 'HDA:10ec0272,
Controls : 17
Simple ctrls : 10
Date: Mon Oct 25 15:33:16 2010
HibernationDevice: RESUME=
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
MachineType: TOSHIBA TOSHIBA NB205
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
RelatedPackageV
SourcePackage: linux
dmi.bios.date: 04/07/2009
dmi.bios.vendor: TOSHIBA
dmi.bios.version: V1.20
dmi.board.name: KAVAA
dmi.board.vendor: TOSHIBA
dmi.board.version: 1.00
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.
dmi.modalias: dmi:bvnTOSHIBA:
dmi.product.name: TOSHIBA NB205
dmi.product.
dmi.sys.vendor: TOSHIBA
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
tags: | removed: regression-potential |
kschmitt, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http:// cdimage. ubuntu. com/daily- live/current/ .
If it remains an issue, could you please run the following command in the development release from a Terminal (Applications- >Accessories- >Terminal) , as it will automatically gather and attach updated debug information to this report:
apport-collect -p linux <replace- with-bug- number>
Also, could you please test the latest upstream kernel available following https:/ /wiki.ubuntu. com/KernelMainl ineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags: fixed-upstream fixed-upstream- VERSION- NUMBER
kernel-
kernel-
where VERSION-NUMBER is the version number of the kernel you tested. For example: fixed-upstream- v3.11-rc5
kernel-
This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag: testing
needs-upstream-
If the mainline kernel does not fix this bug, please add the following tags: bug-exists- upstream bug-exists- upstream- VERSION- NUMBER
kernel-
kernel-
As well, please remove the tag: testing
needs-upstream-
If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags: unable- to-test- upstream unable- to-test- upstream- VERSION- NUMBER
kernel-
kernel-
Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.