Scott,
# udevadm test /block/sda 21 | grep ^util_run_program:.*started
util_run_program: 'ata_id --export /dev/sda' started
util_run_program: 'scsi_id --whitelisted --replace-whitespace -p0x80
-d/dev/sda' started
util_run_program: 'path_id
I am doing this (on an otherwise idle UNR):
# sleep 120; logger devkit-disks-probe-ata-smart; /lib/udev/devkit-
disks-probe-ata-smart /dev/sda; sleep 120; logger done
And I get this in syslog (repeatably):
Dec 14 11:12:01 unus logger: devkit-disks-probe-ata-smart
Dec 14 11:12:35 unus kernel: [
I disabled /lib/udev/rules.d/95-devkit-disks.rules (using dpkg-divert).
And now I can boot without HSM violations. But I believe this is only a
workaround.
Note that the devkit-disks-probe-ata-smart tests did again result in
filesystem corruption.
Raf.
--
SSD stall during boot
On Mon, 2009-12-14 at 16:27 +, Raf wrote:
I disabled /lib/udev/rules.d/95-devkit-disks.rules (using dpkg-divert).
And now I can boot without HSM violations. But I believe this is only a
workaround.
Note that the devkit-disks-probe-ata-smart tests did again result in
filesystem
** Package changed: linux (Ubuntu) = libatasmart (Ubuntu)
** Summary changed:
- SSD stall during boot
+ devkit-disks-probe-ata-smart causes HSM Violations on SSD, and potential
hardware death
** Also affects: devicekit-disks (Ubuntu)
Importance: Undecided
Status: New
** Changed in:
On Fri, 2009-12-11 at 17:10 +, Raf wrote:
Yes, echo change /sys/block/sda/uevent results in the same error.
After entering that command, it takes about 20 to 30 seconds until the
error shows up.
Ok, excellent.
So what's happening is that one of the commands being run to probe the
disk
I had not zeroed my drive prior to installing Fedora 12 so I attempted to
follow Andrew's suggestion (#91). Unfortunately every time I try dd
if=/dev/zero of=/dev/sda (which is definitely my 32GB SSD) I get the following
error:
dd: writing to '/dev/sda': Input/output error
676065+0 records in
Stephen, try badblocks -wvs /dev/sda to make check your drive in read-write
mode
2009/12/11 Stephen O sogles...@yahoo.com
I had not zeroed my drive prior to installing Fedora 12 so I attempted to
follow Andrew's suggestion (#91). Unfortunately every time I try dd
if=/dev/zero of=/dev/sda
Stephen O - I also had this error unless I set the block size manually.
Try bs=1M.
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
@Scott,
int k = open(/dev/sda, O_WRONLY);
close(k);
That actually has quite a few side-effects that you might not
realise ;-)
It might be good then to warn people not to run parted --list to view
partition tables. That seems to open all your devices with O_WRONLY.
--
SSD stall during boot
Scott,
Yes, echo change /sys/block/sda/uevent results in the same error.
After entering that command, it takes about 20 to 30 seconds until the
error shows up.
Any idea why does works fine under Jaunty and not Karmic?
Raf.
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You
Just a consideration it might be worth making when we're testing the
different distros / kernals. Once I had experienced the problem, I could
not reliably get rid of it without doing a dd -if /dev/zero to both
disks. In #89 (Andrew Simpson) and #80 (Stephen O), when the problem was
exhibited in
I tried bootstrapping karmic from a jaunty livecd on a zeroed ssd. I installed
the 2.6.32 kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/ that I
have run from jaunty without any trouble.
I wanted to see if I could trigger the bug when karmic wasn't involved in the
creation or
I can't try this right now, but would it be possible to run gparted with
lots of debugging output to see exactly what it is doing when the bug is
triggered? If this is not possible, maybe we could ask someone who knows
the gparted codebase to help us out?
--
SSD stall during boot
Such an interesting thing: if only I launch parted from liveusb - I
immediately got our errors. Got same using cfdisk. And - it may be
interesting and important - it happens when I just run parted, when I exit
parted - and when I run/exit cfdisk too.
BUT!
Once I've removed libparted and all
I should have mentioned that this could be related to O_LARGEFILE, which
I had to define manually...
#define O_LARGEFILE 010
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
It seems that if I do this as root
int k = open(/dev/sda, O_WRONLY|O_LARGEFILE);
ioctl(k,BLKFLSBUF,0);
close(k);
...then 15~30 seconds later I see this on the console ...
[33458.988232] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[33458.994551] ata2.00: BMDMA stat
Oops, ignore that.
It seem that this is all I need to cause the error is just this...
int k = open(/dev/sda, O_WRONLY);
close(k);
BTW, my root file system is mounted on sda1 while I'm doing this.
(If I open with O_RDONLY instead, then there is no error)
--
SSD stall during boot
#97 also repeatably triggers the HSM violation for me. But only under
Karmic (not Jaunty).
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
But be warned, this has lead to disk corruption for me! I never had disk
corruptions before...
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
On Fri, 2009-12-11 at 01:07 +, rogmorri wrote:
Oops, ignore that.
It seem that this is all I need to cause the error is just this...
int k = open(/dev/sda, O_WRONLY);
close(k);
BTW, my root file system is mounted on sda1 while I'm doing this.
That actually has quite a few
Btw libata.dma=3 do not make SSD work in DMA mode though!
There's something to be told to developers, cause I stay on Jaunty so far
this stall goes away!
2009/12/8 Gav Mack gavin...@hotmail.com
Setting libata.dma=3 to grub seems to have stopped the hang on my AAO so
far, the entries in dmesg
You're correct - it was early days and premature! Though I could put up
with the slow boot time with anything other than basic web browsing I
couldn't handle the drop the disk read performance from 67mb/sec to
2Mb/sec never mind write. It was worse than my old stock AAO SSD was
with Jaunty
Agree completely, Gav Mack. Seems likely to me to be a regression in the
kernal that should be fixed. Unfortunately, it looks like the associated
kernal bug (#14583) is being put down to dodgy hardware.
The libata.dma=4 is just a workaround to keep us up and running in the
interim... if you can
Couldn't agree more Andrew. It's the easy way out to blame this on
hardware, they may have had a valid point but clearly none of us ever
had a problem with this until Karmic and the newer kernels. To
paraphrase that old saying If it looks like a Kernel Bug, acts like a
Kerrnel Bug then it's a
A small thing to keep in mind:
1. I load Karmic - and got this bug. Kernel 2.6.31 as to my mind
2. I load Karmic and 2.6.32 - still got this bug
3. I load Jaunty - and got not this bug. Kernel 2.6.28
4. I load Jaunty and 2.6.32 - and got NOT this bug
Though it's NOT a kernel bug I guess. Otherwise
#75 is correct. My karmic install always gives the error (even with
2.6.29-rc3*). But my jaunty never gives the error, even with 2.6.31-16.
However, there is one more difference between my karmic and jaunty
installs: karmic uses ext4, while jaunty uses ext2 (and for the record
all of those are
@Raf:
Don't think it's an ext4 issue - I'm very sure that when I first ran
Karmic Beta on the USB boot stick it hung on the detection of the SSD
before I even got to the partition menu. I tried ext2 first and got
corruption pretty quickly and then setup in ext4 before I spotted this
bug report
I can confirm this isn't an ext4 issue; I am using ext4 for my /
partition in Jaunty with a 2.6.30 kernel without any trouble
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I've got to agree with #77 - It isn't an ext4 issue. I installed Karmic
on my Eee with ext4 and again with ext2 and got similar errors both
times.
I can also confirm that even using kernels that cause no problems under
Jaunty cause problems under Karmic. So what's different about the boot
It's not just Karmic, as Gav pointed out. I installed Fedora 12 two days
ago in part because I was curious if this problem would follow me from
Karmic. Sure enough, a panel failed to load and my dmesg output had the
same ata errors as it did in karmic. Even though my partitioning scheme
was
What about the increased parallelism in the new upstart? Could this be
the cause of the problems: increased simultaneous disk access.
Doesn't Fedora also use upstart?
Unfortunately it looks like upstart cannot be serialized. (I am talking
about the jobs in /etc/init, not /etc/init.d)
--
SSD
I'm about to please somebody to look distinctly at upstart - can it be
removed (I have no info now on this - I'm still on 9.04). Can somebody try
removing?
2009/12/9 Raf 4283...@noduck.org
What about the increased parallelism in the new upstart? Could this be
the cause of the problems:
** Changed in: linux (Ubuntu)
Assignee: (unassigned) = Gav Mack (gavinmac)
** Changed in: linux (Ubuntu)
Assignee: Gav Mack (gavinmac) = (unassigned)
** Changed in: linux (Ubuntu)
Assignee: (unassigned) = Upstart Developers (upstart-devel)
--
SSD stall during boot
Notified the upstart devs - do any other distros other than Fedora 12
and Karmic use upstart?
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
** Changed in: linux (Ubuntu)
Assignee: Upstart Developers (upstart-devel) = (unassigned)
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Please do not subscribe that team, the team's own description explicitly
asks you not to.
This bug clearly is nothing to do with userspace, it should not be
possible for userspace to cause problems in this way (that's what the
kernel is there for).
It smells like a kernel driver bug to me,
Thanks for the debugging advice Scott.
The only issue for me is that when I install Karmic and it goes _very_
bad I end up with a bricked machine (IO errors on SSD causing me to drop
to initramfs promt). The only way to test other kernels is to dd zeros
over the SSD and reinstall the OS again,
2 Scott:
How could it be: same program (here I mean kernel version), same hardware -
and different behaviour on different systems of Ubuntu. Don't you think that
it would be rather strange, if 2 things work here and not there - than it's
not because that things gone bad, and the reason is
I don't think that there is a bug in upstart. More likely the increased
parallelism of upstart triggers a bug in the kernel, firmware, or
hardware.
If it is a kernel bug, it has been in the kernel for several releases. I
have tested with 2.6.29-rc3 (and most versions in between), that is the
@Raf #87
I've tested Karmic (ext2 filesystem) with the latest 2.6.28 kernel for
Jaunty, with similar results as for the Karmic kernels. (Of course, the
same kernel works just fine with Jaunty.)
Another issue with upstart being the cause of the problem - as #11
notes, this bug can be triggered
O.K., Reviewing what we do know:
Scott has suggested providing system information, however this already
seems to be listed in this bug report and in the upstream bug report.
He has also suggested trying different kernels to isolate when the
problem started. This is what we have been doing,
if a userspace application is able to trigger this issue I would say
this is a kernel bug since that is exactly the sort of thing the kernel
is supposed to be managing. No userspace application regardless of how
poorly written should be able to trigger a drop from UDMA to PIO.
I have tried
I had this issue on my EeePC 901. I took the following actions and have
not *yet* seen the issue reappear:
1. Boot from 9.10 NBR Live CD
2. dd if=/dev/zero of=/dev/sda bs=1M
3. dd if=/dev/zero of=/dev/sdb bs=1M
4. install 9.10 NBR
5. Add kernal command libata.dma=0 in GRUB2 config and rebuild
And yes- it's in libata!!
SSD is eating brains only when libata.dma=4
http://www.kernel.org/doc/Documentation/kernel-parameters.txt
libata.dma= [LIBATA] DMA control
libata.dma=0 Disable all PATA and SATA DMA
libata.dma=1 PATA and SATA
Setting libata.dma=3 to grub seems to have stopped the hang on my AAO so
far, the entries in dmesg are gone. Still taking over a minute to boot
though but that's something I'll live with for now.
It's early days but premature thanks go out to Andrew Squire in advance!
--
SSD stall during boot
I can confirm that upgrading from the stock SSD with Karmic already
installed to a Super Talent SSD produced this error which had not
previously been present.
Simon
Sent from My iPhone
On 7 Dec 2009, at 06:31, Andrew Simpson
andrew.simp...@paradise.net.nz wrote:
The upstream bug report
I can confirm kernel 2.6.30 works fine with my netbook (Acer Aspire One with 8
GB SSD) using a Jaunty userland. I am running 2.6.30-02063009-generic.
I am somewhat reluctant to try a karmic kernel since once I started getting the
errors after installing karmic to get rid of them in any
Telling kernel libata.force=noncq during boot-time from liveUSB had no
effect for me - still got hangups on the same place. It is interesting, that
this happens only after X and gdm is starting. Don't know why really.
Now I got this: booting into single-user mode gave an interesting
result:after
Ok, there's no way this is a hardware issue. I have on my desk two
idenical Eee 900's. Both have exhibited this issue under Jaunty and both
exhibit the issue under Karmic. If I roll them back to karmic and wipe
the SSD along the way, the error goes away.
I have now installed 9.10 UNR on one, and
The upstream bug report has asked whether anyone has tested kernels
2.6.29 or 2.6.30 as this would help narrow down when the bug was
(re)introduced to the kernel.
For my own interest, I have noted that the bug generally occurs with
newer/faster SSD units. For instance the Intel SSD originally
I am having a similar problem with an Acer Aspire 1410. Ubuntu LiveCD
booted perfectly off of the USB drive, but booting off the hard drive
give me either HSM Violations or timeouts.
Setting libata.force=noncq allowed the machine to finally boot up
without any errors.
--
SSD stall during boot
The kernel parameter mentioned in #61 has no effect on the stall/HSM
violation errors on my ASUS EeePC 701 (booted with the 9.10 Live CD and
added the parameter to the kernel options, as I have had to reinstall
Jaunty to use the machine daily).
Back to the drawing board, I guess.
--
SSD stall
This bug is still present with the 31-15 kernel and all other updates
applied on my eeePC 901 (1 Dec). There doesn't seem to be a lot going on
at linux-kernel-bugs 14583?
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member
this bug is not SSD specific.
here is output from my colleague's dmesg notebook dell 120L, this is hdd:
[ 6702.000206] ata1: lost interrupt (Status 0x58)
[ 6702.004018] ata1: drained 32768 bytes to clear DRQ.
[ 6702.093725] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[
I have the same computer and SSD (Acer Aspire One and SUPER TALENT
FEM32GF13M) as well as the same symptoms as Raf above.
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Here's one test of 2.6.32-rc6 on an ASUS eeepc 701 with 16GB SuperTalent
SSD: The original Karmic kernel also shows thus bug with the stock ASUS
8GB SSD.
$ uname -a
Linux eeepc 2.6.32-020632rc6-generic #020632rc6 SMP Wed Nov 4 10:54:30 UTC 2009
i686 GNU/Linux
Looks like the same thing is
I want people, and especially the dev team, to know how serious this
problem is. it killed my SSDs, as I reported in an duplicate bug of
unknown importance. I mean this is hardware issue. Nothing could get
either of my chips working get - not zeroing out, not a gparted live
USB, not Windows /
@Trey
Just a point of info for you. After I performed an in-place install of Karmic
over my existing Jaunty, I found my AAO-110's SuperTalent-upgrade SSD bricked.
I managed to recover it using HDDERASE version 3.3.
This DOS program uses the secure erase function of the drive to
completely
One more piece of information that may or may not be useful to the
develpoers:
On my other laptop, I have Jaunty installed with kernel 2.6.30.9 (from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30.9/ ) and the other
Intel-related patches from the Jaunty/Intel graphics performance howto
at
Trey I'm not sure about your specific situation, but for me a regular dd
didn't work, though a dd with of=/dev/sda bs=1M did work.
Just to back up what Rick is saying, I installed 2.6.28-12-netbook-eeepc
from array.org, and I still have the errors. Furthermore, I used the
jaunty kernel that was
Just want to confirm the whole bug on my EeePC 901 4G+16G. Installation
of fresh Karmic not working at all with mentioned errors in logs and
freezing of partitioning setup page. And surely all is good on Jaunty.
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this
I also see these log entries on my Acer Aspire One with SUPER TALENT
FEM32GF13M. However, I have not yet seen any corruption as a result of
this. In fact, sometimes this does not result in a stall during boot. If
it does stall the boot, it hangs for about 12 seconds.
--
SSD stall during boot
It actually seems that it gives a slightly different error message with
the old kernel, but has a similar effect. This error with the old
kernel only shows up after a dist-upgrade to karmic -- essentially a
karmic install with the old 2.6.28 kernel
I am attaching three dmesg outputs.
This has a timeout error rather than an HSM violation
** Attachment added: dmesg.oldkern
http://launchpadlibrarian.net/35864676/dmesg.oldkern
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Attachment added: dmesg.karmic
http://launchpadlibrarian.net/35864690/dmesg.karmic
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
I've been having this problem too on my Acer aoa110 (using UNR 9.10)
After a few days of using karmic and getting frustrated with the ~1:45 boot
times (from grub to desktop) along with the panel configuration problems, I
tried to use a PPA kernel (comment #20 in
Oh yeah, here's the output of one of the logs.
Btw, sorry about the long meandering story above ;)
ata2: lost interrupt (Status 0x58)
ata2: drained 2048 bytes to clear DRQ.
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata2.00: BMDMA stat 0x4
ata2.00: cmd
Reproduced on a stock eeepc 900 linux version, installing karmic to the
4G ssd. (I did a dist-upgrade from jaunty, which works fine) Also, I
have gotten many cases where I needed to overwrite the disk with zeros
to make it usable again. (this happens after one or two boots with
karmic, I then
@Ubuntu Bugs
Can you please have a look at the status of this bug (currently
'undecided')? This bug could do with some input from the Ubuntu devs.
Here's why:
1. The bug is occurring on a wide range of net books with SSD units.
This is a growing target audience for Ubuntu.
2. In the simplest
I contacted Leann on the kernel team and asked for some advice, and this
is her response. I'm not at home, but at UDS so can't try this right
now.. be good if someone else could:-
Thanks for the heads up Alan. I'll get this bug on our list for review.
It seems this has been forwarded upstream as
@Andrew
Don't get me wrong, i'm also convinced it's a software issue. I know little
about the linux kernel, but I know a lot about concurrent programming, and I
know certain bugs only manifest themselves under very specific conditions
usually related to very subtle differences in timing (which
I have noticed if I power up the AAO without mains power more often than
not it only freezes on the first part of the boot process and not during
GDM making all the applets fail, which gives me the most stable I've got
Karmic working so far. Fsck seems to want to run every boot now just
before the
I have the same issue as reported above with an eeepc 701 (with 16GB
SuperTalent SSD, and also with the original 8GB SSD).
An alternate method of fixing a Karmic-corrupted SSD - at least on the
701 - is to boot with ASUS's rescue DVD and allow it to reinstall the
default Xandros installation.
I'm a bit disappointed that the previously mentioned kernel bug is
discarded so quickly. Could it not still be related? There are indeed no
*optical* drives to be polled, however, on the acer one there are 2 card
readers (= pollable removeable media drives). Since the kernel bug
report claims that
I should add that boot-time, gnome login and gparted startup are
typically moments where I'd expect polling for media to take place.
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I notice changed behaviour when there are sd cards inserted: The stall
is longer with 2 cards inserted than with 1 card, and 1 card is worse
than no cards, though it does not disappear. How would I disable the
card readers entirely? (I see sdhci-pci mentioned, and when there are
cards inserted,
The eeepc 701 has one SD reader that can be disabled in the BIOS.
Disabling it doesn't seem to affect the SSD issues at all on my system.
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is
@Johan
Interesting comment. I have private doubts that this bug is totally due to
hardware 'quality' problems (see the current kernel bug report).
If the hardware was at fault then: firstly, the bug would not be spread
over such a range of differing hardware, and secondly, Ubuntu 9.04
should
Well after having this issue for a couple of weeks now my netbook will no
longer boot. I ran a live USB stick and gparted can't even read the
partition. As soon as I have time, I'm going back to 9.04 and I suggest
everyone else do the same before their drive craps out like mine did. It
seems to
@Andrew
Couldn't agree more that this is a code regression and not simply a hardware
quality issue.
I haven't checked the various changelogs, but I wouldn't be surprised if
something in the IDE IRQ handler or the hardware initialization was
subjected to optimization (in libdma?). Possibly the
A possible work around from the upstream bug report is to boot with
'irqpoll' in the kernel boot parameters. It's not a good fix, the logs
are still full of error messages, but at least the 'stall' is reduced.
Regrettably, it's probably best to avoid using Karmic on SSD equipped
netbooks. Use
I had exactly the same problem (boot stall) on an Asus eee 900. After 2 weeks
of use, i got a grub -error: error: biosdisk read error and the system become
completely useless, pending a disk wipe and full reinstall.
Similar situations are reported on: https://bugs.launchpad.net/bugs/387272
Ok, so after running 9.10 and discovering this issue. I now have booted
off a 9.04 USB stick and dd'ed /dev/zero over both sda and sdb. I then
installed 9.04 and have no issues.
So the hardware is not faulty.
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug
Linux kernel bug 14515 has nothing to do with this
** Changed in: linux
Importance: Unknown = Undecided
** Changed in: linux
Status: Confirmed = New
** Changed in: linux
Remote watch: Linux Kernel Bug Tracker #14515 = None
--
SSD stall during boot
Affects my asus eeepc 900. Please raise to critical before I have to
learn to hassle with Gentoo again.
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
** Bug watch added: Linux Kernel Bug Tracker #14583
http://bugzilla.kernel.org/show_bug.cgi?id=14583
** Changed in: linux
Importance: Undecided = Unknown
** Changed in: linux
Status: New = Unknown
** Changed in: linux
Remote watch: None = Linux Kernel Bug Tracker #14583
--
SSD
** Changed in: linux
Status: Unknown = Confirmed
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Playing with LiveCD (on a USB stick) with an Aspire One with Super
Talent 16Gb SSD:
- Normal LiveCD boot shows the problem in dmesg.
- Booting with 'libata.dma=0' in kernel line fixes the problem (by
disabling DMA) in dmesg.
- Booting with 'libata.ignore_hpa=0' had no affect.
Since the problem
acer aoa-110 some problem
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
I just verified that this bug still present for me in the just-released
kernel 2.6.31-15.
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Interestingly, if I use the Dell Mini 9 Factory SSD with 9.10 this
problem goes away.
** Attachment added: hdparm -I /dev/sda
http://launchpadlibrarian.net/35371422/hdparm.txt
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a
@andrey i. mavlyanov
Andrey,
I don't think that this is the same bug.
On this line:
Nov 4 08:18:45 aim-laptop kernel: [35132.010175] res
40/00:00:00:4f:c2/00:00:00:00:00/40 Emask 0x4 (timeout)
You are getting a 'timeout', whereas this bug is causing 'HSM
Violations'.
--
SSD stall during
A me too here
eeepc 900 fresh install of final 9.1.
Moreover if I have any kind of usb flash drives attached, machine
doesn't complete boot at all.
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which
Moreover. I got this error on non-SSD drive. Check
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/473765 for details
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags added: ubuntu
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
I have linked this bug report to (what looks to be) the same problem at
the kernel bug tracker. Not sure I've done the linking correctly ;-)
http://bugzilla.kernel.org/show_bug.cgi?id=14515
** Bug watch added: Linux Kernel Bug Tracker #14515
http://bugzilla.kernel.org/show_bug.cgi?id=14515
** Changed in: linux
Status: Unknown = Confirmed
--
SSD stall during boot
https://bugs.launchpad.net/bugs/445852
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Me too! AAO ZG5 running stock 8GB drive. Jaunty was booting in about
20 seconds and Karmic is taking about 90 seconds. I am attaching parts
from dmesg and the most recent copy of bootchart.
...
[7.242403] input: SynPS/2 Synaptics TouchPad as
/devices/platform/i8042/serio2/input/input8
[
I'd like to point out that even though the delays in the boot process
are annoying, what is worse is the series of applets crashing when
logging in to gnome. Usually I cannot log out again because that applet
has crashed. So I switch to tty1 and do a 'sudo service gdm restart'.
The next and
1 - 100 of 117 matches
Mail list logo
