Re: UDMA interfering with install
Dag-Erling Smorgrav wrote: Terry Lambert [EMAIL PROTECTED] writes: So we removed it from the kernel config... and the damn thing enabled it again. You're thinking of ATA_ENABLE_ATAPI_DMA, which is only for ATAPI devices (i.e. CD-ROMs), not for disks. Yes, thank you; you saved me beating on James to get access to the machine that was barfing... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
Terry Lambert [EMAIL PROTECTED] writes: So we removed it from the kernel config... and the damn thing enabled it again. You're thinking of ATA_ENABLE_ATAPI_DMA, which is only for ATAPI devices (i.e. CD-ROMs), not for disks. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
I am thinking of what _was_ 'sysctl hw.atamodes' (or similar) in -STABLE. j. -- When you get the choice to sit it out or dance, I hope you dance -- I Hope You Dance, Lee Ann Womack Jon C.: [Microsoft] pops up all over the place Jon S.: Like a Virus -- From an online discussion one night Jon Smith On 16 Jun 2001, Dag-Erling Smorgrav wrote: Date: 16 Jun 2001 03:16:48 +0200 From: Dag-Erling Smorgrav [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Jonathan Smith [EMAIL PROTECTED], John Hay [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: UDMA interfering with install Terry Lambert [EMAIL PROTECTED] writes: So we removed it from the kernel config... and the damn thing enabled it again. You're thinking of ATA_ENABLE_ATAPI_DMA, which is only for ATAPI devices (i.e. CD-ROMs), not for disks. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
Jonathan Smith [EMAIL PROTECTED] writes: I am thinking of what _was_ 'sysctl hw.atamodes' (or similar) in -STABLE. You are not Terry. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
Jonathan Smith wrote: That's good enough. :) Thanks Maybe _that_ will keep that ata code from over-riding the bios to disable dma (or maybe the bios just wasn't doing it's job right ;) This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. So we removed it from the kernel config... and the damn thing enabled it again. I don't know if the #ifdef was intended to only guard in the boot case, but it doesn't help, because there are several missign guards around the code, if that's the case, and at least four places in the code ignore the tuning variable, as well, if it isn't commented out of the kernel at build time (thus disabling one of the places). Look for the #ifdef, and then look for the function call to do the enable, and the problem will be obvious. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
It seems Terry Lambert wrote: Jonathan Smith wrote: That's good enough. :) Thanks Maybe _that_ will keep that ata code from over-riding the bios to disable dma (or maybe the bios just wasn't doing it's job right ;) This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. Just set hw.ata.ata_dma=0 in /boot/loader.conf and it will not enabled DMA.. So we removed it from the kernel config... and the damn thing enabled it again. There is nothing in the config file that affects DMA... I don't know if the #ifdef was intended to only guard in the boot case, but it doesn't help, because there are several missign guards around the code, if that's the case, and at least four places in the code ignore the tuning variable, as well, if it isn't commented out of the kernel at build time (thus disabling one of the places). Look for the #ifdef, and then look for the function call to do the enable, and the problem will be obvious. You lost me here, what version of FreeBSD are we talking about ? I thought it was 4.3 but that doesn't contain any ifdef's about DMA at all -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
That's good enough. :) Thanks Maybe _that_ will keep that ata code from over-riding the bios to disable dma (or maybe the bios just wasn't doing it's job right ;) This won't work. What do you mean with this? The procedure that I described (barring typos) do work here and was used here to install and run FreeBSD on a silly A+ motherboard. Without disabling the DMA the install would fail and even if I installed with DMA disabled, but rebooted afterwards with DMA enabled, it would corrupt the filesystem to an almost unusable state. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. So we removed it from the kernel config... and the damn thing enabled it again. I don't know if the #ifdef was intended to only guard in the boot case, but it doesn't help, because there are several missign guards around the code, if that's the case, and at least four places in the code ignore the tuning variable, as well, if it isn't commented out of the kernel at build time (thus disabling one of the places). Look for the #ifdef, and then look for the function call to do the enable, and the problem will be obvious. I'm not sure where the #ifdef comes into play. I didn't even recompile anything, so whatever #ifdef can be whatever it likes to be. Jun 5 18:42:51 d-5-71 /boot/kernel/kernel: ad0: 4104MB SAMSUNG SW0434A (4.3GB) [8896/15/63] at ata0-master PIO4 John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
Søren Schmidt wrote: Maybe _that_ will keep that ata code from over-riding the bios to disable dma (or maybe the bios just wasn't doing it's job right ;) This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. Just set hw.ata.ata_dma=0 in /boot/loader.conf and it will not enabled DMA.. So we removed it from the kernel config... and the damn thing enabled it again. There is nothing in the config file that affects DMA... This was a 4.3 system -- things seem to have changed in the source tree since then. In 4.3, it's not possible to disable DMA, because it gets reenabled in many places (atapi.c, etc.). This was off-topic for -current, unless the original poster was running 4.3-RELEASE or a RELENG_4_3_0_RELEASE... Sorry for the confusion. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
It seems Terry Lambert wrote: Søren Schmidt wrote: This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. Just set hw.ata.ata_dma=0 in /boot/loader.conf and it will not enabled DMA.. So we removed it from the kernel config... and the damn thing enabled it again. There is nothing in the config file that affects DMA... This was a 4.3 system -- things seem to have changed in the source tree since then. Nope. In 4.3, it's not possible to disable DMA, because it gets reenabled in many places (atapi.c, etc.). there is no atapi.c... This was off-topic for -current, unless the original poster was running 4.3-RELEASE or a RELENG_4_3_0_RELEASE... Sorry for the confusion. I think you are confused :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
S?ren Schmidt wrote: This was a 4.3 system -- things seem to have changed in the source tree since then. Nope. In 4.3, it's not possible to disable DMA, because it gets reenabled in many places (atapi.c, etc.). there is no atapi.c... This was off-topic for -current, unless the original poster was running 4.3-RELEASE or a RELENG_4_3_0_RELEASE... Sorry for the confusion. I think you are confused :) I expected you might say this... I will beat on the system in question for its source code revisions and file names tomorrow (it's not mine: it has IDE drives). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
UDMA interfering with install
Unfortunately, the UDMA chipset on my ASUS P5A doesn't work well with Western Vegetable drives So, I need to forcibly sysctl it into pio mode. Is there *any* way to do this from sysinstall on the 5.0-200105250-CURRENT (or later snap on current.freebsd.org) floppy bootup? Thanks j. -- When you get the choice to sit it out or dance, I hope you dance -- I Hope You Dance, Lee Ann Womack Jon C.: [Microsoft] pops up all over the place Jon S.: Like a Virus -- From an online discussion one night Jon Smith To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
