Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Aug 2005 21:47:41 +0200
From:      Chris Gilbert <Chris@LainOS.org>
To:        =?iso-8859-1?q?S=F8ren_Schmidt?= <sos@FreeBSD.org>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: Panic during install on Sparc64 - Only with large HDD
Message-ID:  <200508142147.42045.Chris@LainOS.org>
In-Reply-To: <DDA34AD5-6279-4E7F-B40E-2537389591CE@FreeBSD.org>
References:  <200508132321.37654.Chris@LainOS.org> <200508142016.17769.Chris@LainOS.org> <DDA34AD5-6279-4E7F-B40E-2537389591CE@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi S=F8ren,

Thanks a bunch for your reply!

Yea, I thought it may have been a 137GB limitation, I wasn't positive thoug=
h.

Thanks for clearing it up.

Also, shouldn't we modify the output with a dev_printf or something of the=
=20
like on device init to note this if the drive attached is > 137GB?

It would seem a shame for this tread to be brought up over and over because=
=20
people like myself didn't know any better. :)

Also, some users had reported success by removing the CDROM drive, putting =
in=20
an 40 pin cable, etc.

I tried all of these and while they did seem to fix other unrelated issues,=
=20
they did not effect the problem at hand.

Perhaps also a proper solution would be to report attached drives on it in =
DMA=20
mode which are > 137GB as 137GB.=20

At least this way it would be less likely to generate PRs and would=20
successfully install FreeBSD.

Thanks again for the feedback.

OT: Also, judging by your name/domain it would appear you are here in Denma=
rk.=20
If/when you get the chance to implement that PIO override let me know, and=
=20
next time you are in the Copenhagen area I'll buy you a beer. :)

=2D-=20
Thanks,
Chris (Lance) Gilbert
Ph: +45 33 73 29 31 (UTC +0100)

On Sunday 14 August 2005 21:41, S=F8ren Schmidt wrote:
> On 14/08/2005, at 20:16, Chris Gilbert wrote:
> > Also, it seems that setting hw.ata.ata_dma=3D0 (forcing it into PIO
> > mode) fixes
> > the issue.
> >
> > # sysctl -a hw.ata.ata_dma
> > hw.ata.ata_dma: 0
> >
> > # dd count=3D1 obs=3D1024 seek=3D93321656 if=3D/dev/urandom of=3D/dev/a=
d0g
> > 1+0 records in
> > 0+1 records out
> > 512 bytes transferred in 0.001390 secs (368351 bytes/sec)
> >
> > Also, seems there is a bug summitted on this, and a posting to the
> > freebsd-sparc64 mailing list.
> >
> > http://lists.freebsd.org/pipermail/freebsd-sparc64/2005-June/
> > 003212.html
> >
> > Will continue looking into the chipset docs and FreeBSD driver...
> > but thought
> > I should point this out.
>
> Actually the problem is in the Acer chip, it cant handle 48bit
> addressing in DMA mode, unless the version is above 0xc4 IIRC.
>
> Either you should use disks with a size less137GB, or you need to
> engage PIO mode.
>
> A workaround in ATA could be to use PIO mode when crossing the
> boundary, but there is no framework for quirks like that present yet,
> could be pretty easily done though so give a me few days (I'm busy as
> usual)
>
> -S=F8ren
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508142147.42045.Chris>