This patch adds the file linux-2.6.7/drivers/scsi/sata_nv.c, updates
linux-2.6.7/drivers/scsi/Makefile and linux-2.6.7/drivers/scsi/Kconfig
to include the new driver, and removes
PCI_DEVICE_ID_NVIDIA_NFORCE2S_SATA, PCI_DEVICE_ID_NVIDIA_NFORCE3S_SATA,
and PCI_DEVICE_ID_NVIDIA_NFORCE3S_SATA2 device IDs from the
linux-2.6.7/drivers/ide/pci/amd74xx.c driver (these IDs will now be in
the sata_nv.c driver).
This patch is to be applied to the linux-2.6.7 kernel.
Attaching patch file, as the patch is kind of large.
Hi,
Is there any reason why this driver doesn't support
CK804-SATA[2] and MCP04-SATA[2]?
Removing IDs from amd74xx.c is a bad idea,
it breaks boot on systems already using these IDs.
Cheers.
On Thursday 17 of June 2004 02:17, Andrew Chew wrote:
> This patch adds the file linux-2.6.7/drivers/scsi/sata_nv.c, updates
> linux-2.6.7/drivers/scsi/Makefile and linux-2.6.7/drivers/scsi/Kconfig
> to include the new driver, and removes
> PCI_DEVICE_ID_NVIDIA_NFORCE2S_SATA, PCI_DEVICE_ID_NVIDIA_NFORCE3S_SATA,
> and PCI_DEVICE_ID_NVIDIA_NFORCE3S_SATA2 device IDs from the
> linux-2.6.7/drivers/ide/pci/amd74xx.c driver (these IDs will now be in
> the sata_nv.c driver).
>
> This patch is to be applied to the linux-2.6.7 kernel.
>
> Attaching patch file, as the patch is kind of large.
> From: Bartlomiej Zolnierkiewicz
> Is there any reason why this driver doesn't support
> CK804-SATA[2] and MCP04-SATA[2]?
These will be supported by this driver eventually. We probably can
change it now, but silicon isn't available for these yet so I wasn't
able to test the driver.
> Removing IDs from amd74xx.c is a bad idea,
> it breaks boot on systems already using these IDs.
I assume these systems will be able to boot using the libata subsystem.
Is that a bad assumption?
On Thu, Jun 17, 2004 at 03:12:42AM +0200, Bartlomiej Zolnierkiewicz wrote:
> Removing IDs from amd74xx.c is a bad idea,
> it breaks boot on systems already using these IDs.
(FWIW for Andrew)
I'm going to apply Andrew's patch, but without the PCI id removals.
Then, I'll apply a patch that adds Kconfig questions
Include hardware that conflicts with libata SATA driver?
(in drivers/ide)
and
Include hardware that conflicts with IDE driver?
(in libata, drivers/scsi)
and apply the associated ifdefs to the low-level drivers.
This is necessary to both enable conflict prevention, and also make sure
we don't break existing setups in the move to libata for SATA stuff.
Jeff
On Wed, Jun 16, 2004 at 06:19:34PM -0700, Andrew Chew wrote:
> > From: Bartlomiej Zolnierkiewicz
>
> > Is there any reason why this driver doesn't support
> > CK804-SATA[2] and MCP04-SATA[2]?
>
> These will be supported by this driver eventually. We probably can
> change it now, but silicon isn't available for these yet so I wasn't
> able to test the driver.
If silicon isn't available yet, let's just remove those PCI IDs. That
way we can ensure that these are libata only, without two drivers
sharing the same PCI ids.
> > Removing IDs from amd74xx.c is a bad idea,
> > it breaks boot on systems already using these IDs.
>
> I assume these systems will be able to boot using the libata subsystem.
> Is that a bad assumption?
They can, but consider a system that uses 2.6.7 (IDE driver) then boots
into 2.6.8 (libata driver): the drives move from /dev/hdX to /dev/sdX.
That breaks stuff not using LABEL= in bootloader config and fstab.
Jeff
> On Thu, Jun 17, 2004 at 03:12:42AM +0200, Bartlomiej
> Zolnierkiewicz wrote:
> > Removing IDs from amd74xx.c is a bad idea,
> > it breaks boot on systems already using these IDs.
> From: Jeff Garzik [mailto:[email protected]]
> (FWIW for Andrew)
>
> I'm going to apply Andrew's patch, but without the PCI id removals.
>
> Then, I'll apply a patch that adds Kconfig questions
>
> Include hardware that conflicts with libata SATA driver?
> (in drivers/ide)
> and
> Include hardware that conflicts with IDE driver?
> (in libata, drivers/scsi)
>
> and apply the associated ifdefs to the low-level drivers.
>
> This is necessary to both enable conflict prevention, and
> also make sure we don't break existing setups in the move to
> libata for SATA stuff.
So the amd74xx driver won't be able to coexist with the sata_nv driver?
If the sata_nv driver is used (and amd74xx is not), then there won't be
a driver controlling the NVIDIA IDE controllers.
> From: Jeff Garzik [mailto:[email protected]]
> If silicon isn't available yet, let's just remove those PCI
> IDs. That way we can ensure that these are libata only,
> without two drivers sharing the same PCI ids.
If that's the case, I'd rather the CK804 and MCP04 SATA device IDs be
added to sata_nv, since we want distributions to support these SATA
controllers when silicon does become available.
> > > Removing IDs from amd74xx.c is a bad idea,
> > > it breaks boot on systems already using these IDs.
> >
> > I assume these systems will be able to boot using the libata
> > subsystem. Is that a bad assumption?
>
> They can, but consider a system that uses 2.6.7 (IDE driver)
> then boots into 2.6.8 (libata driver): the drives move from
> /dev/hdX to /dev/sdX. That breaks stuff not using LABEL= in
> bootloader config and fstab.
That's true. I kinda chalk this up as an inevitable kernel upgrade
issue (they'll be getting support for NVIDIA SATA under libata with
eventual device hotplug support, at the cost of some system
reconfiguration). Is there a good solution?
Andrew Chew wrote:
>>From: Jeff Garzik [mailto:[email protected]]
>
>
>>If silicon isn't available yet, let's just remove those PCI
>>IDs. That way we can ensure that these are libata only,
>>without two drivers sharing the same PCI ids.
>
>
> If that's the case, I'd rather the CK804 and MCP04 SATA device IDs be
> added to sata_nv, since we want distributions to support these SATA
> controllers when silicon does become available.
OK
>>>>Removing IDs from amd74xx.c is a bad idea,
>>>>it breaks boot on systems already using these IDs.
>>>
>>>I assume these systems will be able to boot using the libata
>>>subsystem. Is that a bad assumption?
>>
>>They can, but consider a system that uses 2.6.7 (IDE driver)
>>then boots into 2.6.8 (libata driver): the drives move from
>>/dev/hdX to /dev/sdX. That breaks stuff not using LABEL= in
>>bootloader config and fstab.
>
>
> That's true. I kinda chalk this up as an inevitable kernel upgrade
> issue (they'll be getting support for NVIDIA SATA under libata with
> eventual device hotplug support, at the cost of some system
> reconfiguration). Is there a good solution?
None really, other than trying to make sure we only add new SATA
hardware support under libata.
Most users with Red Hat or SuSE or whatever don't know enough other than
"I booted the new Fedora 2.6.x kernel, and it panic'd when it tried to
mount root filesystem"
Your patch represented the _ideal_, but unfortunately once added to the
IDE driver, those PCI ids should not be removed in the middle of a
stable kernel series. If both drivers were /dev/sdX, or /dev/hdX,
moving the PCI ids to another driver wouldn't be as big of a deal.
Overall... no worries. I have to deal with this issue for a couple
other chipsets, so I'll handle them all at the same time.
Jeff
Am Donnerstag, 17. Juni 2004 03:20 schrieben Sie:
[...]
> Then, I'll apply a patch that adds Kconfig questions
>
> Include hardware that conflicts with libata SATA driver?
> (in drivers/ide)
> and
> Include hardware that conflicts with IDE driver?
> (in libata, drivers/scsi)
>
> and apply the associated ifdefs to the low-level drivers.
>
This patch will address the conflict between sata_sil and siimage, too ?
Markus Kossmann wrote:
> Am Donnerstag, 17. Juni 2004 03:20 schrieben Sie:
> [...]
>
>>Then, I'll apply a patch that adds Kconfig questions
>>
>> Include hardware that conflicts with libata SATA driver?
>> (in drivers/ide)
>>and
>> Include hardware that conflicts with IDE driver?
>> (in libata, drivers/scsi)
>>
>>and apply the associated ifdefs to the low-level drivers.
>>
>
> This patch will address the conflict between sata_sil and siimage, too ?
Yep.
Jeff