On Maw, 2005-08-16 at 22:42 +0200, Bartlomiej Zolnierkiewicz wrote:
> IMO this is much better solution as:
> * you go from working code into small steps (evolution)
If there was working code to go from maybe. The IDE core code is far too
broken for that to be the case. The drivers are different ma
On 8/16/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > * non-functional HDIO_REGISTER_HWIF ioctl (ain't really working either)
> >
> > HDIO_SCAN_HWIF - I don't know about this one. How are we supposed to
> > follow the "new ports shouldn't define IDE_ARCH_OBSOLETE_INIT" injunction
> > if we lose
On 8/16/05, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> On Tuesday 16 August 2005 3:38 am, Bartlomiej Zolnierkiewicz wrote:
> > On 8/15/05, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > > On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> > Agreed but I have few comments:
> > * is this change OK w.r
> > * non-functional HDIO_REGISTER_HWIF ioctl (ain't really working either)
>
> HDIO_SCAN_HWIF - I don't know about this one. How are we supposed to
> follow the "new ports shouldn't define IDE_ARCH_OBSOLETE_INIT" injunction
> if we lose all this functionality without it? ia64 is about as clos
On Tuesday 16 August 2005 3:38 am, Bartlomiej Zolnierkiewicz wrote:
> On 8/15/05, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> Agreed but I have few comments:
> * is this change OK w.r.t. IA64_HP_SIM?
Kernels for the HP simulator (ski) use a SCSI
On 8/16/05, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 16, 2005 at 01:55:58PM +0100, Alan Cox wrote:
> > On Maw, 2005-08-16 at 11:38 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
> > > * non-functional ide-cs driver (but
On Maw, 2005-08-16 at 12:02 +0200, Bartlomiej Zolnierkiewicz wrote:
> On 8/11/05, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> > > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > > around in I/O port s
On Tue, Aug 16, 2005 at 01:55:58PM +0100, Alan Cox wrote:
> On Maw, 2005-08-16 at 11:38 +0200, Bartlomiej Zolnierkiewicz wrote:
> > * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
> > * non-functional ide-cs driver (but there is no PCMCIA on IA64?)
>
> IA64 systems can support PC
On 8/16/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Maw, 2005-08-16 at 11:38 +0200, Bartlomiej Zolnierkiewicz wrote:
> > * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
> > * non-functional ide-cs driver (but there is no PCMCIA on IA64?)
>
> IA64 systems can support PCI->Cardbus
On Maw, 2005-08-16 at 11:38 +0200, Bartlomiej Zolnierkiewicz wrote:
> * removing IDE_ARCH_OBSOLETE_INIT define has some implications,
> * non-functional ide-cs driver (but there is no PCMCIA on IA64?)
IA64 systems can support PCI->Cardbus/PCMCIA cards so they do actually
need this support. They
On 8/11/05, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > around in I/O port space. Poking at things that don't exist causes MCAs
> > on HP ia64 systems.
On 8/16/05, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 8/15/05, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> > > Assuming all IA-64 boxes are PCI or better then you actually want to
> > > edit include/asm-ia64/ide.h and edi
Hi,
On 8/15/05, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> > Assuming all IA-64 boxes are PCI or better then you actually want to
> > edit include/asm-ia64/ide.h and edit ide_default_io_base where someone
> > years ago cut and pasted x86-32 value
On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> Assuming all IA-64 boxes are PCI or better then you actually want to
> edit include/asm-ia64/ide.h and edit ide_default_io_base where someone
> years ago cut and pasted x86-32 values so that case 2-5 are removed.
> Then you will just probe the com
>Maybe it should instead depend on those systems where it is available.
>Anything but X86?
x86_64?
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-in
On Thu, 11 Aug 2005, Bjorn Helgaas wrote:
> So the scenario in question (correct me if I'm wrong) is that we
> have a PCI IDE device that is handed off in compatibility mode (and
> may only work in that mode). In that case, the PCI *device* still
> exists, so shouldn't the IDE PCI code claim that
On Iau, 2005-08-11 at 14:24 -0600, Bjorn Helgaas wrote:
> IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> around in I/O port space. Poking at things that don't exist causes MCAs
> on HP ia64 systems.
>
> Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Nak-by: Alan Cox
On Iau, 2005-08-11 at 17:07 -0600, Bjorn Helgaas wrote:
> So the scenario in question (correct me if I'm wrong) is that we
> have a PCI IDE device that is handed off in compatibility mode (and
> may only work in that mode). In that case, the PCI *device* still
> exists, so shouldn't the IDE PCI co
Bjorn Helgaas wrote:
You deduce this by the absence of SecO and PriO? I wonder if lspci
should be enhanced to notice this, too. I assume that the IRQ 169
doesn't correspond to anything in /proc/interrupts.
Correct.
So the scenario in question (correct me if I'm wrong) is that we
have a PCI
(resend with correct cc list).
On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> around in I/O port space. Poking at things that don't exist causes MCAs
> on HP ia64 systems.
H, can you change the test
On Thursday 11 August 2005 3:56 pm, Jeff Garzik wrote:
> Jeff Garzik wrote:
> > 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE
> > Controller
> > (rev 02) (prog-if 8a [Master SecP PriP])
> > Subsystem: Hewlett-Packard Company d530 CMT (DG746A)
> > Control: I/
On Thu, Aug 11, 2005 at 03:42:07PM -0600, Bjorn Helgaas wrote:
> On Thursday 11 August 2005 2:56 pm, Jeff Garzik wrote:
> > Bjorn Helgaas wrote:
> > > On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> > >>Bjorn Helgaas wrote:
> > >>> config IDE_GENERIC
> > >>> tristate "generic/defau
Luck, Tony wrote:
Tony, others, does this change give you any heartburn? On
the 460GX and 870 boxes I have, IDE is a PCI device.
No heartburn for me ... as you say IDE is built into one
of the 870 chips.
I don't know whether any non-Intel chipsets provide legacy IDE.
The question is not ab
>Tony, others, does this change give you any heartburn? On
>the 460GX and 870 boxes I have, IDE is a PCI device.
No heartburn for me ... as you say IDE is built into one
of the 870 chips.
I don't know whether any non-Intel chipsets provide legacy IDE.
-Tony
-
To unsubscribe from this list: sen
Jeff Garzik wrote:
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller
(rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: Hewlett-Packard Company d530 CMT (DG746A)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- Fa
On Thu, Aug 11, 2005 at 03:42:07PM -0600, Bjorn Helgaas wrote:
> Tony, others, does this change give you any heartburn? On
> the 460GX and 870 boxes I have, IDE is a PCI device.
>
> (I have been told that the SGI ia64 simulator depends on
> IDE_GENERIC. But it really should make the IDE device
>
On Thursday 11 August 2005 2:56 pm, Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> >>Bjorn Helgaas wrote:
> >>> config IDE_GENERIC
> >>> tristate "generic/default IDE chipset support"
> >>>+ depends on !IA64
> >>
> >>hm. Are you PO
Bjorn Helgaas wrote:
On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
Bjorn Helgaas wrote:
IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
around in I/O port space. Poking at things that don't exist causes MCAs
on HP ia64 systems.
Signed-off-by: Bjorn Helgaas
On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > around in I/O port space. Poking at things that don't exist causes MCAs
> > on HP ia64 systems.
> >
> > Signed-off-by: Bjorn Helgaas <[EMA
On Thursday 11 August 2005 2:34 pm, Christoph Hellwig wrote:
> On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > around in I/O port space. Poking at things that don't exist causes MCAs
> > on HP ia64 syst
Bjorn Helgaas wrote:
IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
around in I/O port space. Poking at things that don't exist causes MCAs
on HP ia64 systems.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-vga/drivers/ide/Kconfig
===
On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> around in I/O port space. Poking at things that don't exist causes MCAs
> on HP ia64 systems.
Maybe it should instead depend on those systems where it is ava
IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
around in I/O port space. Poking at things that don't exist causes MCAs
on HP ia64 systems.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-vga/drivers/ide/Kconfig
==
33 matches
Mail list logo