Yes, just got to it last night. Sorry about the delay, got
interrupted last week with a notice from my real estate and had to
reassess my finances.
Anyway, it seems to work - using the patched kernel I can
successfully read the block I was having trouble with without turning
lba48always on.
I am seeing freezes... first boot it froze during termrc, second was
fine, third boot it froze as I tried to run kbmap... well, it didn't
freeze - stats kept on running happily, letting me know about the
>1000 syscalls per second (which I'm seeing consistently every boot)

and faces kept on updating the time. I could move the mouse, but not
interact with rio at all. ^T^Tp still worked, but I forget the rest of
those debugging shortcuts and it was past my bedtime so I just left it
running, but it was in the same state when I woke up this morning.
Rebooted with ^T^Tr and it came up fine.
I'm not sure if this is related to the patch or just some other
incompatibility... still, it's progress compared to my last two
install attempts, in which venti choked on the second boot with a
whole lot of I/O errors.

PS. Any idea why your reply showed up here in an anonymous attachment
instead of the email body, erik?

On Sat, Apr 12, 2008 at 7:40 PM, erik quanstrom wrote:
> get a chance to test this yet?
> - erik
> ---------- Forwarded message ----------
> From: sqweek
> To: "Fans of the OS Plan 9 from Bell Labs" <>
> Date: Mon, 7 Apr 2008 00:19:00 +0800
> Subject: Re: [9fans] i/o error reading large sata disk
> On Sun, Apr 6, 2008 at 11:58 AM, erik quanstrom wrote:
> > (a) setting lba48always on
> > ; echo llba48always on>/dev/sd??/ctl
> > if this doesn't work, then i'm wrong.

> Thanks erik, that does the trick. Didn't get around to trying the
> patch yet, I'll be in touch.
> -sqweek