pata driver in libata is thwarted by HPA

With 2.6.20-6-generic this problem is gone.

Thanks for you comment. Not problem now?

Not a problem in a sense that my computer is usable. But the real solution would be fixing the via_pata driver in libata, not just using the old ata driver. :)

We're working on libata HPA support. Assigning to Kyle.

Herd 6 should contain preliminary HPA support, will follow up closer to the release. In the mean time, you can blacklist the libata modules in /etc/modprobe.d/blacklist to revert to using the drivers/ide modules.

Moving milestone forward.

2.6.20-10 contains "beta" quality HPA support for libata. Please give it a test by booting it, and look for "Host Protected Area detected."

If you're feeling brave, boot with "libata.ignore_hpa=1" to disable the host protected area (which should enable your whole disk). Please attach dmesg whether it was successful or not.

Thanks!
 Kyle

The sooner I get testers, the sooner I can enable it by default. :)

Since -10 I became unable to boot a MacBook C2D with ata abnormal status errors, could it be related to any of this?

Thanks :)

Unlikely, but posting a dmesg would be useful...

The disk isn't detected, there's no way I can grab the dmesg... The latest update doesn't work either, just -9. The grub keyboard issues make it suboptimal to change kernel at boot (most of the times the keyboard doesn't work).

I get the following errors:

ATA: abnormal status 0x7F on port 0x20CF
ATA: abnormal status 0x7F on port 0x20CF
ATA: abnormal status 0x7F on port 0x20CF
ata1.01: qc timeout (cmd 0x27)
ata1.01: failed to set xfermode (err_mask=0x40)
ata1.01: limiting speed to PIO0
ata1: failed to recover some devices, retrying in 5 secs
ATA: abnormal status 0x7F on port 0x20CF
ATA: abnormal status 0x7F on port 0x20CF
ATA: abnormal status 0x7F on port 0x20CF
ata1.01: qc timeout (cmd 0x27)
ata1.01: failed to set xfermode (err_mask=0x40)
ata1.01: disabled
ATA: abnormal status 0x7F on port 0x20C7

Then drops to a shell on the initramfs.

I'll try this next: http://www.odi.ch/prog/macbookpro/index.php#4

Reported already: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/91940

:)

Ok, I booted -11, but the affected drive is driven by normal ide drivers, not by libata. How can I tell it that it should use libata instead? (possibly in a way that can be easily reverted in case of problems).

I could be wrong, but I think my problem may also be related. I attempted a very standard install of Feisty Herd 5 alongside my Edgy install. Here's my fdisk output:

[CODE]
$ sudo fdisk -l /dev/hda

Disk /dev/hda: 40.0 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot Start End Blocks Id System
/dev/hda1 1 2980 23936818+ 83 Linux #Edgy
/dev/hda2 4737 4864 1028160 82 Linux swap / Solaris
/dev/hda3 2981 4736 14105070 83 Linux #Feisty

Partition table entries are not in disk order
[/CODE]

Feisty's boot hangs very early in the boot process. When in recovery mode, here's my final output:
[CODE]
Begin: Running /script/local-bottom ...
Done.
Done.
Begin: Running /scripts/init-bottom ...
Done.
[ 5.640000] attempt to access beyond end of device
[ 5.640000] sda:rw=32, want=71990972, limit=70501362
[ 5.640000] EXT3-fs error (device sda3): ext3_get_inode_loc: unable to read inode block - inode=1733313, block=3473410
init: Unable to execute "/bin/sh" for rcS: Permission denied
init: rcS process (2342) terminated with status 255
init: Unable to execute "/bin/sh" for rc-default: Permission denied
init: rc-default process (2343) terminated with status 255
[/CODE]

Thanks, and sorry if in missinterpreted something, this is my first time on launchpad.

Reed:

ad1. your partition table is OK, just the logical order of the partition is not the same as the physical order and the fdisk output is ordered by the logical layout.

ad2. The problem "attempt to access beyond end of device" can belong to this bug, please do what Kyle suggested:

> If you're feeling brave, boot with "libata.ignore_hpa=1" to disable the host protected
> area (which should enable your whole disk). Please attach dmesg whether it wasű
> successful or not.

Still no success; the boot process hung in the same spot. I'm currently downloading the new beta, and when I finish downloading, I'll reinstall and then hopefully it will boot. I'll post back with my results. Thanks.

Reed

:/ It appears things have regressed even with the beta. I couldn't get to a console to get a dmesg by booting to the feisty I have installed, so I booted up to the new beta cd I just burned and when I attempt an install, the partitioner does not even show my existing partitions...

On the prepare partitions dialog (step four, after I select to manually prepare disk space), the only device listed is /dev/sda. I don't even have an sda; it should be hda. No other partitions or devices are listed.

From the live cd, I ran a dmesg. It is attached, but I appologize, its very long - cluttered with "attempt to access beyond end of device," messages. I hope this helps.

FWIW, my system is a IBM Thinkpad T41.

I experienced the same issues today with feisty (dist-upgrade today).

Suddenly my /dev/hda became /dev/sda and thought the partitions were damaged and ran fsck on them, which failed every time.
When booting an older kernel (2.6.19.x) /dev/hda was identified and worked.

Now my system is totally f%(/" up.

http://home.danielnylander.se/vadda-fel.png

My (broken) system is also an IBM T41.

This is the only bug I could find that I thought might be related to my issue. I was going to try blacklisting the ata drivers as suggested above, but I'm not sure how to include all the necessary ones to get the old IDE driver (for now). I started having problems with 2.6.20-12, though -11 works fine. Like other symptoms reported here, it's detecting my devices as SCSI sda devices rather than the usual hda stuff, and I'm not sure whether this is an issue or by design, but -12 and -13 won't boot.

I managed to get a dmesg with -12 as /boot (hda1, though it saw it as sda1) managed to mount properly. I was getting warnings with -13, but I don't care, there's nothing valuable on this machine :). Cheers.

-Scott

Scott,

when using the old (non-sata based) ata drivers, you see the disks as hd*. When using the sata-based ata drivers, you see them as sd*.

This particular bugreport was opened for the scenario when the new sata-based drivers were used for disks with a host-protected area (HPA) present. In these cases you could see messages like this:

[ 663.015850] attempt to access beyond end of device
[ 663.015854] sdc: rw=0, want=234484734, limit=66055248

I'm seeing those messages, but nothing related to host protected area. So should I be using the old drivers, or open a new bug report for this?

It seems it boots successfully sometimes, but that (I think) depends on the order the devices are enumerated. I grabbed a dmesg of both a fail and success, and spotted a couple of differences (if it helps)--note I don't see any line about HPA, yet the old ide driver detects it (Host Protected Area detected, followed by disabled) so I apparently do have it... (- is fail, + is successful boot):

-ata1.00: 78125000 sectors, multi 16: LBA
+ata1.00: 80043264 sectors, multi 16: LBA

-SCSI device sda: 78125000 512-byte hdwr sectors (40000 MB)
+SCSI device sda: 80043264 512-byte hdwr sectors (40982 MB)

-SCSI device sda: 78125000 512-byte hdwr sectors (40000 MB)
+SCSI device sda: 80043264 512-byte hdwr sectors (40982 MB)

- sda: p3 exceeds device capacity
-attempt to access beyond end of device
-sda: rw=0, want=80043080, limit=78125000
-Buffer I/O error on device sda3, logical block 9864768

Besides the obvious disk size discrepancy, the only other noticable difference is that my network card gets initialized BEFORE the ATA driver in the successful bootand AFTER the ATA driver in the failed boot... so maybe it's an ACPI issue?

HTH, I see Kyle mentioned testers a couple of weeks ago, I'm not sure if that's what was in mind :).

I am having the same problem with Thinkpad A31 and with kernels 2.6.20-12 and 2.6.20-13. With 2.6.17* kernels my disks can be properly mounted, but with the 2.6.20* I am getting these errors:

attempt to access beyond end of device

and I cannot mount my partitions.

Same problem here, Acer TravelMate 8000 (8006LMi).

"attempt to access beyond end of device" and boot halts

Using 2.6.17-10 atm to boot, which works fine.

This is clearly quite a new problem and I can't find any useful information anywhere. I don't know enough to fix myself and this is my work system that I need so I can't mess about too much either.

Knew I should have waited for the release before upgrading... least I have a kernel that boots :)

We had to back out the changes as they broke booting on the MacBook.

Where can I find the .deb for an older kernel that will boot? Also, is there a time frame for when we might have an update to a new, working kernel? Are we to expect that this will be fixed in time for the final release? Thanks.

BTW, It seems to me that the issue that myself, and several others here are experiencing is different/distinct from the initial issue that Istvan Szekeres was experiencing. Can/should we split this bug report?

Reed: I have got 2.6.17-10 booting fine on my system. My other kernels will not boot (2.6.20-13, 2.6.20-12, 2.6.17-11).

I can confirm all the above problems (/dev/hda -> /dev/sda), the beta cd throws up the same dmesg as reported before.

I just noticed that today is the kernel freeze on the release schedule. Does that mean feisty is stuck w/ a kernel that won't boot on our systems?

Problem seems to be solved in 2.6.20-13 and is no back in 2.6.20-14
Also directories will be shown as unknown file formats.

It gets further than before (with 2.6.20-13), always says there are errors on sda1. Only kernel I have working (2.6.17-10) does not flag these errors. After the error check pumps out more errors and boot halts. I will photo the screen if needed.

kernel update on feisty: kernel 2.6.20-13 boots fine; kernel 2.6.20-14: failed to set xfermode (err_mask=4x0)

Ok, here's a testing kernel that handles HPA capable drives:

http://people.ubuntu.com/~bcollins/kernels/bug-82314/

There's on for amd64 and i386.

NOTE: This will not be in the RC. If you want this to make it in for release, please test ASAP, and email Kyle and myself directly with results:

<email address hidden>, <email address hidden>

Thanks

It fixed my problem! Thanks so much. With this testing kernel, feisty now boots on my ThinkPad T41. Please have this in on the final release.

I already sent Ben and Kyle an e-mail about this but I thought I should post my comments below in case other people have the same issue.

I tried the kernel from above and it did fix the end of device messages but I came up with the following error message when my system was trying to initialize my 400gb secondary drive.

[ 9.064000] ata1.01: n_sectors mismatch 66055248 != 9670832
[ 9.064000] ata1.01: revalidation failed (errno=-19)
[ 9.064000] ata1.01: disabled
[ 9.064000] ata1: failed to recover some devices, retrying in 5 secs

Ben responded back promptly with the following:

"Thanks for testing. I actually knew about this little bug already, and
have fixed it locally (didn't get a chance to rebuild new images yet)."

So hopefully a new image will be up and ready to go soon.

Thanks again.

This kernel works fine 4 me - please please please put these changes in the RC! In addition I have some problems in combination with my soundblaster live! card - but maybe that one is broken.

I've had a similar problem - boot hangs and I get "ata2.00: failed to set xfermode (err_mask=0x4)." since upgrading to 2.6.20-14; 2.6.20-13 still boots fine. I was hoping this patch would fix me up, but it does not...

I end up at the same place as before with this kernel, so it hasn't fixed the problems I've been having on my T40. Booting an older kernel works though. I get the "attempt to access beyond" errors. As some people have mentioned I think, I'm not using RAID or anything similar, just a single PATA disk.

Gar !! The (as of a few minutes ago) 2.6.20-14 23 version kernel is now giving me similar failure messages to those above (re-pasted from above):

[ 9.064000] ata1.01: n_sectors mismatch 66055248 != 9670832
[ 9.064000] ata1.01: revalidation failed (errno=-19)
[ 9.064000] ata1.01: disabled
[ 9.064000] ata1: failed to recover some devices, retrying in 5 secs

The module is of course sata_nv on a western digital sata disk via nvidia nvforce motherboard.

Is there no magic kernel boot option that will save me ? Irqpoll did it on the last kernel update but I'm totally dead in the water now. Oh well, I should know better than to be on unstable dev streams anyways... ;)

I am seeing the exact same thing as kuhnert. However only on one of the drives connected to my controller. I have been running feisty fine for a little while and today one drive gives me these errors. If it can help, I attached the output from dmesg. I am also available to test new kernels. Here is a snip that I think is relevent:
[ 4.016359] ata6: SATA max UDMA/133 cmd 0x0001ef88 ctl 0x0001ef86 bmdma 0x0001ee60 irq 18
[ 4.016459] ata7: SATA max UDMA/133 cmd 0x0001ef68 ctl 0x0001ef82 bmdma 0x0001ee68 irq 18
[ 4.016530] scsi5 : ata_piix
[ 4.186310] ata6.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 1857904
[ 4.186381] ata6.00: ATA-7: WDC WD2500KS-00MJB0, 02.01C03, max UDMA/133
[ 4.186435] ata6.00: 488397168 sectors, multi 16: LBA48
[ 4.198303] ata6.00: n_sectors mismatch 488397168 != 31170441795952
[ 4.198357] ata6.00: revalidation failed (errno=-19)
[ 4.198410] ata6.00: limiting speed to UDMA/133:PIO3

I'm all done freaking out now, the "hot to chroot" thread on ubuntuforums was very helpful in eventually getting me into a state where I could downgrade the kernel from apt archives. ...

Damn you Linus / Allen!

Same here. After update a few minutes ago I can no longer boot. Western Digital sata disk. jkuhnert, could you elaborate on how you got back to a bootable state. I'm forced to boot XP at the moment. Downloading a live CD right now, hopefully that will help.

I see some ata errors similar to those above.

My problem as described in the last comment is covered in bug #106063.

This is _REALLY_ fucked up. Been debian experimental / unstable user for years, switched to ubuntu and after few weeks such problems.

My machine just won't boot, I get the error other guys get (copied from above)-

[ 9.064000] ata1.01: n_sectors mismatch 66055248 != 9670832
[ 9.064000] ata1.01: revalidation failed (errno=-19)
[ 9.064000] ata1.01: disabled
[ 9.064000] ata1: failed to recover some devices, retrying in 5 secs

So- it disables my only (pata) hard drive and of course after disabling hard drive it can't boot.

Only 2.6.17.something boots (not 2.6.20.x) BUT there are no headers for 2.6.17 so I can't get into X with multiple monitor support (because I can't compile nvidia module).

So- are there any workarounds; is it possible to disable that behavior in GRUB? I'm really not into compiling custom kernel (and got overdriven in 1 day after new kernel is released).

I see there is, as of today, another kernel update, but I am cautious to take it. Does this include the above patch (the one that I'm on now, that fixed my system)? I see Bug #96857 and Bug #99648 referenced in the changelog, but no Bug #82314. :) Regardless, thanks for all your work Kyle, Ben, and others. You're doing great.

To the last comment, yeah downloading a livecd should allow you to chroot to your drive and fix the kernel issues by downgrading the kernel version.

If you want to be mad at someone ultimately you can direct it towards Linus Torvalds / Allen Cox. I stumbled upon a thread or two with them discussing these sorts of issues.

I ~guess~ they aren't the ones that applied whatever this f-ed up patch is and deployed it to us as a ~minor~ kernel update but oh well.......I hope they fix it soon.

I noticed the update this morning as well. I updated and now both the generic and 386 .14 kernels appear to be working.

Arghh! So which one is it? This is like russian roulette.

Nick, were you getting n_sectors mismatch errors or some other type of error ?

I'm afraid just because there are other hosed people reporting things that theoretically got pushed out this morning.

The update this morning is exactly what -broke- my machine in the first place. By the way, my drive is not a Western Digital Sata as I believed, but rather a Hitachi PATA drive, that seems to be mounted via a scsi interface. I don't plan to do any more kernel updates until I see positive feedback in bug #106063.

I was getting the errors originally posted at the top of this ticket.

The 2.6.20-15.24 kernel which Ben uploaded an hour or so ago and will be available soon ought to fix this. Please let us know if it doesn't.

Last night I got an update message for a new 2.6.20-14-generic kernel so I figured what the heck, I'll give it a try. I downloaded and installed the update and what do you know the thing actually boots without any problems. I'm a little confused though because I'm not sure if they released the 2.6.20-14-generic as a newer update to the old 2.6.20-14-generic and just didn't change the version number or what.

Something I did notice though, some of my hdparm optimizations like multicount and such no longer initialize in this drive using the new libata driver. My read speed went from around 60mb/sec down to 28mb/sec. I'm guessing this is still early code and over time will mature more.

One thing of note, on my system I had to disable most of the ide tweaks in the bios just to get the thing to boot with the 2.6.20 series kernels. I should add that I have two internal drives, one a 20gb and the other a 400gb. Ubuntu is on the 20gb and even with the older 2.6.20 kernels would boot okay, so long as I disabled things like UDMA access and DMA transfers and stuff in the bios. The 400gb drive is the one that gave me all of the problems regarding the host protected area and is what lead me to this thread. I have not tried enabling most of these tweaks in the bios with this "new 2.6.20-14-generic" kernel that recognizes the 400gb drive correctly. I will have to try that tonight.

The 2.6.20-15.24 kernel from http://people.ubuntu.com/~bcollins/kernels fixed a problem I had with my second SATA drive disappearing, in case this happens to anybody else - not quite related to PATA, as the only PATA device in the system is a CDROM, but this was the closest item I could find matching my problem this afternoon.

Available in 2.6.20-15.25

I just tried the 2.6.20.15.14 kernel and it has fixed my issue. Thanks guys!

Sorry, I meant 2.6.20-15.24, not 14.

2.6.20-15.25 breaks for me. See https://bugs.launchpad.net/ubuntu/+bug/106408 (probably can be considered a dupe), https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106418 (my dmesg)

I installed Fesity & everything went well, however on reboot....

well during the installation Fesity finds hdb1 & hdb2, on reboot this
not changed to sdb1 & sdb2 shown by fdisk -l

#########################################
root@duckie-desktop:~# fdisk -l

Disk /dev/sda: 80.0 GB, 80060424192 bytes
255 heads, 63 sectors/track, 9733 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

  Device Boot Start End Blocks Id System
/dev/sda1 * 1 3029 24330411 7 HPFS/NTFS
/dev/sda2 3030 8331 42588315 c W95 FAT32 (LBA)
/dev/sda3 8332 9733 11261565 83 Linux

Disk /dev/sdb: 164.6 GB, 164696555520 bytes
255 heads, 63 sectors/track, 20023 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

  Device Boot Start End Blocks Id System
/dev/sdb1 1 7841 62982801 c W95 FAT32 (LBA)
/dev/sdb2 7842 20023 97851915 83 Linux

Disk /dev/sdc: 81.9 GB, 81964302336 bytes
255 heads, 63 sectors/track, 9964 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

  Device Boot Start End Blocks Id System
/dev/sdc1 * 1 1958 15727603+ c W95 FAT32 (LBA)
/dev/sdc2 1959 9931 64043122+ c W95 FAT32 (LBA)
/dev/sdc3 9932 9964 265072+ 82 Linux swap / Solaris

Disk /dev/sdd: 20.0 GB, 20000267776 bytes
255 heads, 63 sectors/track, 2431 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

  Device Boot Start End Blocks Id System
/dev/sdd1 * 1 5 40131 0 Empty
/dev/sdd2 * 6 2431 19486845 c W95 FAT32 (LBA)
root@duckie-desktop:~#
##########################################

On boot-up however I get a fsck error 17,
unable to mount sdb1 & sdb2, special device not know...

If I edit the UUID sdb1 & sdb2 then it's ignored & the system boots up fine.
everything is using UUIDs in fstab, attained by using: ls -l /dev/disk/by-uuid.

uname -a gives:

duckie@duckie-desktop:~$ uname -a
Linux duckie-desktop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

I'm posting back to say thanks again, because Ubuntu has been working fine since the patch released by Ben Collins above.

I have a question though... was this problem specific to Ubuntu, or relevant all operating systems using the 2.6.20 kernel? Because I've tried to set my system up to dual boot with a couple other distributions recently, and none of them have worked. If this problem effects the linux kernel as a whole, has this patch been submitted upstream so other distributions will soon benefit from it as well?

I ask because I tried Sidux, Sayabon, and Arch. With Sidux, the live cd would boot fine, and installation would seem to go fine, but then after reboot, the OS would not boot. Sayabon's live cd would boot fine as well, but the partitioner would choke before I even got to installation. Arch (not a live cd) wouldn't even seem to access my hdd.

So will I need to pursue bug fixes on each of these distributions individually, or do I just need to wait now for them to update their kernels to a version including the above patch? Thanks, and sorry if this is the wrong place for this kind of question.

We tried as Kyle's recommendation, but it didn't work.
We tried this on Kernel-2.6.21 and Kernel-2.6.20.10.
We added libata.ignore-hap=1 on Grub config, and added on modprob.conf.
But after rebooting, we issued the command, "fdiks -l /dev/sda", but still we can't see the whole disk.
We just saw the disk area except hpa area.
We want to see the whole disk to use it fully.
.
Friendlu,
Nobel

>2.6.20-10 contains "beta" quality HPA support for libata. Please give it a test by booting it, and look >for "Host Protected Area detected."
>If you're feeling brave, boot with "libata.ignore_hpa=1" to disable the host protected area (which should >enable your whole disk). Please attach dmesg whether it was successful or not.

Not sure, but i have a similar problem here, while mounting my camera. I recently upgraded to 7.10, but that kernel did not work. Now i use an older kernel, the
2.6.20-16-386
Kernel. Output of dmesg:

[ 141.868000] usb 2-1: new full speed USB device using uhci_hcd and address 2
[ 142.040000] usb 2-1: configuration #1 chosen from 1 choice
[ 142.204000] usbcore: registered new interface driver libusual
[ 142.348000] Initializing USB Mass Storage driver...
[ 142.352000] scsi0 : SCSI emulation for USB Mass Storage devices
[ 142.352000] usb-storage: device found at 2
[ 142.352000] usb-storage: waiting for device to settle before scanning
[ 142.356000] usbcore: registered new interface driver usb-storage
[ 142.356000] USB Mass Storage support registered.
[ 147.352000] usb-storage: device scan complete
[ 147.356000] scsi 0:0:0:0: Direct-Access KM DiMAGE Z6 1.00 PQ: 0 ANSI: 0 CCS
[ 147.424000] SCSI device sda: 4022045 512-byte hdwr sectors (2059 MB)
[ 147.428000] sda: Write Protect is off
[ 147.428000] sda: Mode Sense: 02 00 00 00
[ 147.428000] sda: assuming drive cache: write through
[ 147.436000] SCSI device sda: 4022045 512-byte hdwr sectors (2059 MB)
[ 147.440000] sda: Write Protect is off
[ 147.440000] sda: Mode Sense: 02 00 00 00
[ 147.440000] sda: assuming drive cache: write through
[ 147.440000] sda: sda1
[ 148.132000] sda: p1 exceeds device capacity
[ 148.136000] sd 0:0:0:0: Attached scsi removable disk sda
[ 148.216000] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 149.916000] attempt to access beyond end of device
[ 149.916000] sda: rw=0, want=4022116, limit=4022045
[ 149.916000] Buffer I/O error on device sda1, logical block 4021888
[ 149.916000] attempt to access beyond end of device
[ 149.916000] sda: rw=0, want=4022117, limit=4022045
[ 149.916000] Buffer I/O error on device sda1, logical block 4021889
[ 149.916000] attempt to access beyond end of device
[ 149.916000] sda: rw=0, want=4022118, limit=4022045
[ 149.916000] Buffer I/O error on device sda1, logical block 4021890
[ 149.916000] attempt to access beyond end of device
[ 149.916000] sda: rw=0, want=4022119, limit=4022045
[ 149.916000] Buffer I/O error on device sda1, logical block 4021891
[ 149.916000] attempt to access beyond end of device
[ 149.916000] sda: rw=0, want=4022120, limit=4022045
[ 149.916000] Buffer I/O error on device sda1, logical block 4021892
[ 149.920000] attempt to access beyond end of device
[ 149.920000] sda: rw=0, want=4022121, limit=4022045
[ 149.920000] Buffer I/O error on device sda1, logical block 4021893
[ 149.920000] attempt to access beyond end of device
[ 149.920000] sda: rw=0, want=4022122, limit=4022045

Are there any workarounds yet?

Could it be that you have an unformatted disk attatched? Sounds strange but I got katchunked the same errors but after throwing a filesystem on the empty drive the libata driver ceased to complain about both devices, sda and sdb.

Same files, but attached to the bug report.