Date: Mon, 25 Mar 2013 00:31:09 -0400 From: Chris Ross <cross+freebsd@distal.com> To: "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org> Subject: Re: CAM timeouts on Netra X1 Message-ID: <FAC3CA6E-6C8D-4665-886E-8FD27F4DCAB3@distal.com> In-Reply-To: <B0C7D281-1EAE-4BFE-945B-C088C405830D@distal.com> References: <B2952A89-81DA-4392-99F7-DE2F107DBA0D@distal.com> <B0C7D281-1EAE-4BFE-945B-C088C405830D@distal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
After messing with this issue for a couple of hours, I'm 99% sure that =
the ATA_CAM is the crux of my problem. While fixing that issue would be =
the best option, I was trying a "right now" option. I'm not sure how to =
build a kernel, and release.iso (or the like) without CAM. I've been =
trying numerous things with modified versions of GENERIC, but am not =
sure I've gotten anything working the way I want it to.
Has anyone else done this sort of custom-kernel-patched-into-a-stable =
sort of thing before?
- Chris
On Mar 24, 2013, at 21:46 , Chris Ross <cross+freebsd@distal.com> wrote:
> Okay. I noticed both:
>=20
> atapci0: <AcerLabs M5229 UDMA66 controller> port =
0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x=
1022f at device 13.0 on pci0
> atapci0: using PIO transfers above 137GB as workaround for 48bit DMA =
access bug, expect reduced performance
>=20
> and
>=20
> =
http://lists.freebsd.org/pipermail/freebsd-bugs/2012-January/047385.html
>=20
> Perhaps it's a CAM problem where CAM isn't using PIO on the parts of =
the disk it needs to? =20
>=20
> - Chris
>=20
> On Mar 24, 2013, at 21:20 , Chris Ross <cross+freebsd@distal.com> =
wrote:
>> This may not be sparc64 specific, but. I have a Netra X1 that I've =
been netbooting, to eventually install FreeBSD onto its disks. Booting =
a recent stable/9. with the old disks (one 80G, one 250G), I would see =
the following [sort] of errors during [net]boot:
>>=20
>> (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 cf cf b5 40 25 00 00 00 01 =
00
>> (ada0:ata2:0:0:0): CAM status: Command timeout
>> (ada0:ata2:0:0:0): Retrying command
>> (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 cf cf b5 40 25 00 00 00 01 =
00
>> (ada0:ata2:0:0:0): CAM status: Command timeout
>> (ada0:ata2:0:0:0): Retrying command
>> (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 cf cf b5 40 25 00 00 00 01 =
00
>> (ada0:ata2:0:0:0): CAM status: Command timeout
>> (ada0:ata2:0:0:0): Retrying command
>> (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 cf cf b5 40 25 00 00 00 01 =
00
>> (ada0:ata2:0:0:0): CAM status: Command timeout
>> (ada0:ata2:0:0:0): Retrying command
>> (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 cf cf b5 40 25 00 00 00 01 =
00
>> (ada0:ata2:0:0:0): CAM status: Command timeout
>> (ada0:ata2:0:0:0): Error 5, Retries exhausted
>>=20
>> In the past, with the old disks, it was ada1, not ada0, and that was =
the 250G disk that has been reporting errors when the system was running =
off of it (NetBSD 5.1). So I assumed that was the problem. However, =
I've replaced the disks with a pair of 320GB disks, and am now having =
that same problem and messages both during boot, and when trying to =
configure the disks with gpart, for both disks.
>>=20
>> Is this some sort of size issue? And, is there any way around it? =
NetBSD works on the machine, so I assume it's not that the hardware is =
deficient in some way with larger PATA disks...
>>=20
>> - Chris
>>=20
>> _______________________________________________
>> freebsd-sparc64@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
>> To unsubscribe, send any mail to =
"freebsd-sparc64-unsubscribe@freebsd.org"
>=20
> _______________________________________________
> freebsd-sparc64@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
> To unsubscribe, send any mail to =
"freebsd-sparc64-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FAC3CA6E-6C8D-4665-886E-8FD27F4DCAB3>