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
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
> > * 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
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
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
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
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
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
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
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
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
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 values so
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 edit
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 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/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/PCMCIA
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 space.
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
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 there is
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
* 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 close to
a
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.t.
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 all this
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
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
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
>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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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
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
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
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 code
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 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
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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
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:
(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
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
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
>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:
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-
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
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
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
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
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
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
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 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 systems.
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 [EMAIL
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: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 POSITIVE that the legacy
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
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-
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: send
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
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/default IDE chipset
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/O+ Mem+
(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
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
66 matches
Mail list logo
