Ian FREISLICH wrote:
> Scott Long wrote:
>> Ian FREISLICH wrote:
>>> Scott Long wrote:
>>>> Ian Freislich wrote:
>>>>> But I'm unable to boot into multi-user off the disk. The kernel
>>>>> boots and then I get reports of UFS corruption (truncated inodes
>>>>> and missing blocks etc) and it can't find /libexec/ld-elf.so.1.
>>>>>
>>>>> I'm tempted to just say that the card is junk and to give up.
>>>>> Am I correct in my analysis?
>>>>>
>>>> Try setting the following from the loader at boot:
>>>>
>>>> hw.amr.force_sg32=1
>>> Ok, that fixed it. What exactly does this do?
>>>

>> Limits the driver to only use 32-bit addresses, and bounces
>> (copies) anything above that down to the lower 32bits of the
>> address space. Can you send me the output of 'pciconf -lv'?

>
> Scott, I thought I was clear in the original email, but I see now
> that I wasn't. I haven't tried this card on current owing to the
> difficulty of having to potentially downgrade and I was wanting
> to find out if migrating this system to current would help. I'm
> mostly satisfied with this solution as long as it doesn't point to
> a driver bug. Of course, in that case I'm happy to take the pain
> in the interests of helping getting the driver fixed.
>


I don't really care if you're using 8-CURRENT or 7-STABLE, the driver
source is nearly the same in both. The problem exists in both, and the
workaround is the same in both. However, I was looking to collect
the PCI identification information for this 150-6 card so I could
hopefully teach the driver to automatically handle this card specially.
Thank you for providing the information.

Scott
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"