** 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 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 cor
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
https://bugs.laun
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: [ 7
Scott,
# udevadm test /block/sda 2>&1 | 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
/devices/pci:00/:00:1f.2/host1/target1:0:0/1
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
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
@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 dur
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
ubuntu-bugs@l
Stephen, try badblocks -wvs /dev/sda to make check your drive in read-write
mode
2009/12/11 Stephen O
> 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
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
67
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 quit
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
u
#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
ubunt
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
http
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 Ub
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 sta
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 packets
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
https://bugs.lau
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 populat
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 Fed
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 jaunty
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, HOWEV
@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 in
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
oldes
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 somewhere
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, the
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, especi
** 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
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
ub
** 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
https://bugs
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: incr
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 sta
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 differe
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
proces
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.
@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 on
#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 insi
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
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 Ke
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 p
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 playin
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
> Setting libata.dma=3 to grub seems to have stopped the hang on my AAO so
> far, the entries in dmesg are gone. Still ta
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
h
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
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 GR
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 ge
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 distro/ke
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
wrote:
> The upstream bug report has asked whether anyone has t
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 fit
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 h
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 du
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
h
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 of
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
[ 6702.09
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.
--
** 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
ubun
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
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.
dmesg.jaunt
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
http
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 bug
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
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 h
@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 era
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 / Par
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 happen
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
@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 ca
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 re
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 c8/00:08:87:31:01/00:00
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
http://bugs.launchpad.net/ubuntu/
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
@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 m
@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 Sup
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
@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 als
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 subscribed
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
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 U
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 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.
Wit
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 Ja
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 n
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
co
** 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
https://li
** 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
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 maili
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
https://bugs.launchpad.net/bugs/
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
ubuntu
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
https://lists.ubuntu.com/mailman/list
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
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
@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 boot
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.
--
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 i
** 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
https://lists.ubuntu.com/mailman/listinfo/ubu
Yeah I started to notice that kind of stuff as well. That is why I'm
leaving Jaunty on my wife's machine.
On Sat, Oct 31, 2009 at 8:51 AM, Johan Van den Neste wrote:
> 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 cr
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 subsequ
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
[
** 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
https://li
1 - 100 of 117 matches
Mail list logo
