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. ScottReceived on Thu Oct 30 2008 - 05:30:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:36 UTC