ESCD Support for 2.4.6-ac1/PNPBIOS (was: reading/writing CMOS beyond 256 bytes?)

[Gunther Mayer]

Hi,
with a litte patch to linux-2.4.6ac1 (which includes PNPBIOS)
the ESCD data is easily accessible.

Then "lsescd" will verbosely decode /proc/bus/pnp/escd.

This lets you access important info which would be beneficial for correctly
configuring PnP in Linux (e.g. when you set an IRQ to "reserved for legacy ISA"
in your BIOS setup or you can see what's the difference between selecting
"_PNP OS_" to yes/no in your BIOS setup screen).

Regards, Gunther

P.S. There is an additional potential benefit for ISAPNP: you can
get the PNP Port configured by your BIOS. Previously all cards had
to be reset to use a new port. Linux suffers serverly from not
doing PnP failsafe, burdening configuration tasks onto the user.

cat /proc/bus/pnp/pnpconfig_info 
Revision=1 No_Csn=1 ISAPNP_Port=0x20b
  ^^^

Download from:
http://home.t-online.de/home/gunther.mayer/lsescd-0.10.tar.bz2



Alan Cox wrote:
> 
> > Unfortunately, it seems that some settings are not in the 128 (or 256)
> > bytes accessible this way, so they must be stored elsewhere.
> 
> Large numbers of BIOS settings are in the NVRAM ESCD area in modern systems
> (EISA config, ISAPNP config, etc)
> 
> > Does anyone know where I should look for the remaining parts of CMOS
> > (short of having to sign some NDA with Intel?)?
> 
> The PnPBIOS and ESCD specs are publically available if a little impenetrable
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ESCD Support for 2.4.6-ac1/PNPBIOS (was: reading/writing CMOS beyond 256 bytes?)

[Gunther Mayer]

Hi,
with a litte patch to linux-2.4.6ac1 (which includes PNPBIOS)
the ESCD data is easily accessible.

Then lsescd will verbosely decode /proc/bus/pnp/escd.

This lets you access important info which would be beneficial for correctly
configuring PnP in Linux (e.g. when you set an IRQ to reserved for legacy ISA
in your BIOS setup or you can see what's the difference between selecting
_PNP OS_ to yes/no in your BIOS setup screen).

Regards, Gunther

P.S. There is an additional potential benefit for ISAPNP: you can
get the PNP Port configured by your BIOS. Previously all cards had
to be reset to use a new port. Linux suffers serverly from not
doing PnP failsafe, burdening configuration tasks onto the user.

cat /proc/bus/pnp/pnpconfig_info 
Revision=1 No_Csn=1 ISAPNP_Port=0x20b
  ^^^

Download from:
http://home.t-online.de/home/gunther.mayer/lsescd-0.10.tar.bz2



Alan Cox wrote:
 
  Unfortunately, it seems that some settings are not in the 128 (or 256)
  bytes accessible this way, so they must be stored elsewhere.
 
 Large numbers of BIOS settings are in the NVRAM ESCD area in modern systems
 (EISA config, ISAPNP config, etc)
 
  Does anyone know where I should look for the remaining parts of CMOS
  (short of having to sign some NDA with Intel?)?
 
 The PnPBIOS and ESCD specs are publically available if a little impenetrable
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)V3

[Gunther Mayer]

Andre Hedrick wrote:
> 
> That is a legacy bit from ATA-2 but it is one of those things you can not
> get rid of :-( even thou things are obsoleted, they are not retired.
> This means that you have to go back into the past to see how it was used,
> silly!  I hope you agree to that point.

No,
in ANSI X3.279-1996, "AT Attachment Interface with Extensions (ATA-2)",
Approved September 11, 1996 , control register bit 3-7 are reserved.

However ANSI X3.221-1994, "AT Attachment Interface for Disk Drives",
Approved May 12, 1994, bit3 is "1" and bits 4-7 are "x". No further explanation.

How far back must we go, to get the sense ?

> 
> This is the drive->ctrl register pointer.
> 
> outp(drive->ctl|0x02, IDE_CONTROL_REG);
> 
> typedef union {
> unsigned all: 8;/* all of the bits together */
> struct {
> unsigned bit0   : 1;
> unsigned nIEN   : 1;/* device INTRQ to host */
> unsigned SRST   : 1;/* host soft reset bit */
> unsigned bit3   : 1;/* ATA-2 thingy */
> unsigned reserved456: 3;
> unsigned HOB: 1;/* 48-bit address ordering */
> } b;
> } control_t;
> 
> This is a new struct that is to be added for 48-bit addressing and it will
> reflect drive->ctl soon.  I have not decided how to use it best or at all,
> but it has meaning and once I add-in the real def of bit3 then I will not
> need to look it up again.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)V3

[Gunther Mayer]

Andre Hedrick wrote:
 
 That is a legacy bit from ATA-2 but it is one of those things you can not
 get rid of :-( even thou things are obsoleted, they are not retired.
 This means that you have to go back into the past to see how it was used,
 silly!  I hope you agree to that point.

No,
in ANSI X3.279-1996, AT Attachment Interface with Extensions (ATA-2),
Approved September 11, 1996 , control register bit 3-7 are reserved.

However ANSI X3.221-1994, AT Attachment Interface for Disk Drives,
Approved May 12, 1994, bit3 is 1 and bits 4-7 are x. No further explanation.

How far back must we go, to get the sense ?

 
 This is the drive-ctrl register pointer.
 
 outp(drive-ctl|0x02, IDE_CONTROL_REG);
 
 typedef union {
 unsigned all: 8;/* all of the bits together */
 struct {
 unsigned bit0   : 1;
 unsigned nIEN   : 1;/* device INTRQ to host */
 unsigned SRST   : 1;/* host soft reset bit */
 unsigned bit3   : 1;/* ATA-2 thingy */
 unsigned reserved456: 3;
 unsigned HOB: 1;/* 48-bit address ordering */
 } b;
 } control_t;
 
 This is a new struct that is to be added for 48-bit addressing and it will
 reflect drive-ctl soon.  I have not decided how to use it best or at all,
 but it has meaning and once I add-in the real def of bit3 then I will not
 need to look it up again.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards) V3

[Gunther Mayer]

Andre Hedrick wrote:
> 
> It fixes a BUG in CFA, but what will it do to the other stuff?
> Parse it exclusive to CFA and there is not an issue.
...
> Not all ./arch have a control register doing this randomly without know the
> rest of the driver will kill more than it fixes.
> 

Thanks for pointing out this implementation bug. Although I fixed another problem
in ide-cs, where ctl_base could eventually be 0.

I would rather not add a special hwif->is_pcmcia flag, as
the control register (if it exists) is well defined
(bit2=softreset bit1=nIEN, others reserved; however there is
 a hardcoded value of 0x08 somewhere in the ide code?).

-
Gunther



--- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
+++ linux/drivers/ide/ide-cs.c  Thu Jun 28 18:04:27 2001
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -223,6 +224,15 @@
 #define CFG_CHECK(fn, args...) \
 if (CardServices(fn, args) != 0) goto next_entry
 
+int idecs_register (int arg1, int arg2, int irq)
+{
+hw_regs_t hw;
+ide_init_hwif_ports(, (ide_ioreg_t) arg1, (ide_ioreg_t) arg2, NULL);
+hw.irq = irq;
+hw.chipset = ide_pci; // this enables IRQ sharing w/ PCI irqs
+return ide_register_hw(, NULL);
+}
+
 void ide_config(dev_link_t *link)
 {
 client_handle_t handle = link->handle;
@@ -326,10 +336,12 @@
 
 /* retry registration in case device is still spinning up */
 for (i = 0; i < 10; i++) {
-   hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
+   if(ctl_base) outb(0x02, ctl_base); // Set nIEN = disable device interrupts
+   hd = idecs_register(io_base, ctl_base, link->irq.AssignedIRQ);
if (hd >= 0) break;
if (link->io.NumPorts1 == 0x20) {
-   hd = ide_register(io_base+0x10, ctl_base+0x10,
+   if(ctl_base) outb(0x02, ctl_base+0x10);
+   hd = idecs_register(io_base+0x10, ctl_base+0x10,
  link->irq.AssignedIRQ);
if (hd >= 0) {
io_base += 0x10; ctl_base += 0x10;
--- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
+++ linux/drivers/ide/ide-probe.c   Thu Jun 28 18:43:43 2001
@@ -685,6 +685,9 @@
 #else /* !CONFIG_IDEPCI_SHARE_IRQ */
int sa = (hwif->chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
SA_INTERRUPT;
 #endif /* CONFIG_IDEPCI_SHARE_IRQ */
+
+   if(hwif->io_ports[IDE_CONTROL_OFFSET])
+   OUT_BYTE(0x00, hwif->io_ports[IDE_CONTROL_OFFSET]); // clear 
+nIEN == enable irqs
if (ide_request_irq(hwif->irq, _intr, sa, hwif->name, hwgroup)) {
if (!match)
kfree(hwgroup);
--- linux245.orig/drivers/ide/ide.c Wed May  2 01:05:00 2001
+++ linux/drivers/ide/ide.c Thu Jun 28 18:04:42 2001
@@ -2181,6 +2181,7 @@
memcpy(hwif->io_ports, hwif->hw.io_ports, sizeof(hwif->hw.io_ports));
hwif->irq = hw->irq;
hwif->noprobe = 0;
+   hwif->chipset = hw->chipset;
 
if (!initializing) {
ide_probe_module();
--- linux245.orig/include/linux/ide.h   Sat May 26 03:02:42 2001
+++ linux/include/linux/ide.h   Thu Jun 28 18:18:05 2001
@@ -226,6 +226,19 @@
 #endif
 
 /*
+ * hwif_chipset_t is used to keep track of the specific hardware
+ * chipset used by each IDE interface, if known.
+ */
+typedef enum {  ide_unknown,ide_generic,ide_pci,
+ide_cmd640, ide_dtc2278,ide_ali14xx,
+ide_qd6580, ide_umc8672,ide_ht6560b,
+ide_pdc4030,ide_rz1000, ide_trm290,
+ide_cmd646, ide_cy82c693,   ide_4drives,
+ide_pmac
+} hwif_chipset_t;
+
+
+/*
  * Structure to hold all information about the location of this port
  */
 typedef struct hw_regs_s {
@@ -234,6 +247,7 @@
int dma;/* our dma entry */
ide_ack_intr_t  *ack_intr;  /* acknowledge interrupt */
void*priv;  /* interface specific data */
+   hwif_chipset_t  chipset;
 } hw_regs_t;
 
 /*
@@ -396,17 +410,6 @@
 typedef void (ide_maskproc_t) (ide_drive_t *, int);
 typedef void (ide_rw_proc_t) (ide_drive_t *, ide_dma_action_t);
 
-/*
- * hwif_chipset_t is used to keep track of the specific hardware
- * chipset used by each IDE interface, if known.
- */
-typedef enum { ide_unknown,ide_generic,ide_pci,
-   ide_cmd640, ide_dtc2278,ide_ali14xx,
-   ide_qd6580, ide_umc8672,ide_ht6560b,
-   ide_pdc4030,ide_rz1000, ide_trm290,
-   ide_cmd646, ide_cy82c693,   ide_4drives,
-   ide_pmac
-} hwif_chipset_t;
 
 #ifdef CONFIG_BLK_DEV_IDEPCI
 typedef struct ide_pci_devid_s {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards) V3

[Gunther Mayer]

Andre Hedrick wrote:
 
 It fixes a BUG in CFA, but what will it do to the other stuff?
 Parse it exclusive to CFA and there is not an issue.
...
 Not all ./arch have a control register doing this randomly without know the
 rest of the driver will kill more than it fixes.
 

Thanks for pointing out this implementation bug. Although I fixed another problem
in ide-cs, where ctl_base could eventually be 0.

I would rather not add a special hwif-is_pcmcia flag, as
the control register (if it exists) is well defined
(bit2=softreset bit1=nIEN, others reserved; however there is
 a hardcoded value of 0x08 somewhere in the ide code?).

-
Gunther



--- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
+++ linux/drivers/ide/ide-cs.c  Thu Jun 28 18:04:27 2001
@@ -42,6 +42,7 @@
 #include linux/ioport.h
 #include linux/hdreg.h
 #include linux/major.h
+#include linux/ide.h
 
 #include asm/io.h
 #include asm/system.h
@@ -223,6 +224,15 @@
 #define CFG_CHECK(fn, args...) \
 if (CardServices(fn, args) != 0) goto next_entry
 
+int idecs_register (int arg1, int arg2, int irq)
+{
+hw_regs_t hw;
+ide_init_hwif_ports(hw, (ide_ioreg_t) arg1, (ide_ioreg_t) arg2, NULL);
+hw.irq = irq;
+hw.chipset = ide_pci; // this enables IRQ sharing w/ PCI irqs
+return ide_register_hw(hw, NULL);
+}
+
 void ide_config(dev_link_t *link)
 {
 client_handle_t handle = link-handle;
@@ -326,10 +336,12 @@
 
 /* retry registration in case device is still spinning up */
 for (i = 0; i  10; i++) {
-   hd = ide_register(io_base, ctl_base, link-irq.AssignedIRQ);
+   if(ctl_base) outb(0x02, ctl_base); // Set nIEN = disable device interrupts
+   hd = idecs_register(io_base, ctl_base, link-irq.AssignedIRQ);
if (hd = 0) break;
if (link-io.NumPorts1 == 0x20) {
-   hd = ide_register(io_base+0x10, ctl_base+0x10,
+   if(ctl_base) outb(0x02, ctl_base+0x10);
+   hd = idecs_register(io_base+0x10, ctl_base+0x10,
  link-irq.AssignedIRQ);
if (hd = 0) {
io_base += 0x10; ctl_base += 0x10;
--- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
+++ linux/drivers/ide/ide-probe.c   Thu Jun 28 18:43:43 2001
@@ -685,6 +685,9 @@
 #else /* !CONFIG_IDEPCI_SHARE_IRQ */
int sa = (hwif-chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
SA_INTERRUPT;
 #endif /* CONFIG_IDEPCI_SHARE_IRQ */
+
+   if(hwif-io_ports[IDE_CONTROL_OFFSET])
+   OUT_BYTE(0x00, hwif-io_ports[IDE_CONTROL_OFFSET]); // clear 
+nIEN == enable irqs
if (ide_request_irq(hwif-irq, ide_intr, sa, hwif-name, hwgroup)) {
if (!match)
kfree(hwgroup);
--- linux245.orig/drivers/ide/ide.c Wed May  2 01:05:00 2001
+++ linux/drivers/ide/ide.c Thu Jun 28 18:04:42 2001
@@ -2181,6 +2181,7 @@
memcpy(hwif-io_ports, hwif-hw.io_ports, sizeof(hwif-hw.io_ports));
hwif-irq = hw-irq;
hwif-noprobe = 0;
+   hwif-chipset = hw-chipset;
 
if (!initializing) {
ide_probe_module();
--- linux245.orig/include/linux/ide.h   Sat May 26 03:02:42 2001
+++ linux/include/linux/ide.h   Thu Jun 28 18:18:05 2001
@@ -226,6 +226,19 @@
 #endif
 
 /*
+ * hwif_chipset_t is used to keep track of the specific hardware
+ * chipset used by each IDE interface, if known.
+ */
+typedef enum {  ide_unknown,ide_generic,ide_pci,
+ide_cmd640, ide_dtc2278,ide_ali14xx,
+ide_qd6580, ide_umc8672,ide_ht6560b,
+ide_pdc4030,ide_rz1000, ide_trm290,
+ide_cmd646, ide_cy82c693,   ide_4drives,
+ide_pmac
+} hwif_chipset_t;
+
+
+/*
  * Structure to hold all information about the location of this port
  */
 typedef struct hw_regs_s {
@@ -234,6 +247,7 @@
int dma;/* our dma entry */
ide_ack_intr_t  *ack_intr;  /* acknowledge interrupt */
void*priv;  /* interface specific data */
+   hwif_chipset_t  chipset;
 } hw_regs_t;
 
 /*
@@ -396,17 +410,6 @@
 typedef void (ide_maskproc_t) (ide_drive_t *, int);
 typedef void (ide_rw_proc_t) (ide_drive_t *, ide_dma_action_t);
 
-/*
- * hwif_chipset_t is used to keep track of the specific hardware
- * chipset used by each IDE interface, if known.
- */
-typedef enum { ide_unknown,ide_generic,ide_pci,
-   ide_cmd640, ide_dtc2278,ide_ali14xx,
-   ide_qd6580, ide_umc8672,ide_ht6560b,
-   ide_pdc4030,ide_rz1000, ide_trm290,
-   ide_cmd646, ide_cy82c693,   ide_4drives,
-   ide_pmac
-} hwif_chipset_t;
 
 #ifdef CONFIG_BLK_DEV_IDEPCI
 typedef struct ide_pci_devid_s {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo 

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Andre Hedrick wrote:
> 
> PARANIOA.

This is not a valid reason.

This clearly fixes a bug in linux. Note: the irq disable
is local to ide-cs. Are you paranoid enough to believe
enabling the irq by writing globally to the control register that
existed since ATA will have ill effects? 

You claim the relevant PCMCIA ATA behaviour is not ATA(>3?) compliant,
however you didn`t yet give any facts to support this !

You claim this locks the driver, again no facts.


> 
> Remember that ATAPI is generally screwed beyond reality, so adjusting the
> probe code in general (global) is a bad thing.
...
> On Wed, 27 Jun 2001, Alan Cox wrote:
> 
> > > obsoleting ATA-2 did their attention at CFA become alarmed.  I agree that
> > > there needs to be a fix, but not at the price of locking the rest of the
> > > driver.  Since we now the identity of the device prior to assigned the
> > > interrupt we can handle the execption, but you do not go around blanket
> > > wacking the control register of all devices.

The proposed patch is very simple (as per Linus' liking). When considering to
install an earlier (and  global) irq handler I believe you can see
this will impose a much greater risk !

> >
> > I dont see why it locks up the driver ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

patch(2.4.5): 2nd ed. Fix PCMCIA ATA/IDE + PCI IRQ sharing

[Gunther Mayer]

Hi,
this includes the last fix + now it is willing to share PCI irqs.
Of course you still need CONFIG_IDEPCI_SHARE_IRQ set.

Now CF is working very fine, hdparm-4.1 shows 1.27 MB/sec.
(Only after treaking the source for small (i.e. <64MB) devices).

Regards, Gunther




--- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
+++ linux/drivers/ide/ide-cs.c  Wed Jun 27 20:19:45 2001
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -223,6 +224,15 @@
 #define CFG_CHECK(fn, args...) \
 if (CardServices(fn, args) != 0) goto next_entry
 
+int idecs_register (int arg1, int arg2, int irq)
+{
+hw_regs_t hw;
+ide_init_hwif_ports(, (ide_ioreg_t) arg1, (ide_ioreg_t) arg2, NULL);
+hw.irq = irq;
+hw.chipset = ide_pci; // this enables IRQ sharing w/ PCI irqs
+return ide_register_hw(, NULL);
+}
+
 void ide_config(dev_link_t *link)
 {
 client_handle_t handle = link->handle;
@@ -324,12 +334,15 @@
 if (link->io.NumPorts2)
release_region(link->io.BasePort2, link->io.NumPorts2);
 
+outb(0x02, ctl_base); // Set nIEN = disable device interrupts
+ // else it hangs on PCI-Cardbus Add-in cards wedging irq
+
 /* retry registration in case device is still spinning up */
 for (i = 0; i < 10; i++) {
-   hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
+   hd = idecs_register(io_base, ctl_base, link->irq.AssignedIRQ);
if (hd >= 0) break;
if (link->io.NumPorts1 == 0x20) {
-   hd = ide_register(io_base+0x10, ctl_base+0x10,
+   hd = idecs_register(io_base+0x10, ctl_base+0x10,
  link->irq.AssignedIRQ);
if (hd >= 0) {
io_base += 0x10; ctl_base += 0x10;
--- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
+++ linux/drivers/ide/ide-probe.c   Wed Jun 27 17:31:45 2001
@@ -685,6 +685,8 @@
 #else /* !CONFIG_IDEPCI_SHARE_IRQ */
int sa = (hwif->chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
SA_INTERRUPT;
 #endif /* CONFIG_IDEPCI_SHARE_IRQ */
+
+   outb(0x00, hwif->io_ports[IDE_CONTROL_OFFSET]); // clear nIEN == 
+enable irqs
if (ide_request_irq(hwif->irq, _intr, sa, hwif->name, hwgroup)) {
if (!match)
kfree(hwgroup);
--- linux245.orig/drivers/ide/ide.c Wed May  2 01:05:00 2001
+++ linux/drivers/ide/ide.c Wed Jun 27 20:18:23 2001
@@ -2181,6 +2181,7 @@
memcpy(hwif->io_ports, hwif->hw.io_ports, sizeof(hwif->hw.io_ports));
hwif->irq = hw->irq;
hwif->noprobe = 0;
+   hwif->chipset = hw->chipset;
 
if (!initializing) {
ide_probe_module();
--- linux245.orig/include/linux/ide.h   Sat May 26 03:02:42 2001
+++ linux/include/linux/ide.h   Wed Jun 27 19:01:35 2001
@@ -226,6 +226,19 @@
 #endif
 
 /*
+ * hwif_chipset_t is used to keep track of the specific hardware
+ * chipset used by each IDE interface, if known.
+ */
+typedef enum {  ide_unknown,ide_generic,ide_pci,
+ide_cmd640, ide_dtc2278,ide_ali14xx,
+ide_qd6580, ide_umc8672,ide_ht6560b,
+ide_pdc4030,ide_rz1000, ide_trm290,
+ide_cmd646, ide_cy82c693,   ide_4drives,
+ide_pmac
+} hwif_chipset_t;
+
+
+/*
  * Structure to hold all information about the location of this port
  */
 typedef struct hw_regs_s {
@@ -234,6 +247,7 @@
int dma;/* our dma entry */
ide_ack_intr_t  *ack_intr;  /* acknowledge interrupt */
void*priv;  /* interface specific data */
+   hwif_chipset_t  chipset;
 } hw_regs_t;
 
 /*
@@ -396,17 +410,6 @@
 typedef void (ide_maskproc_t) (ide_drive_t *, int);
 typedef void (ide_rw_proc_t) (ide_drive_t *, ide_dma_action_t);
 
-/*
- * hwif_chipset_t is used to keep track of the specific hardware
- * chipset used by each IDE interface, if known.
- */
-typedef enum { ide_unknown,ide_generic,ide_pci,
-   ide_cmd640, ide_dtc2278,ide_ali14xx,
-   ide_qd6580, ide_umc8672,ide_ht6560b,
-   ide_pdc4030,ide_rz1000, ide_trm290,
-   ide_cmd646, ide_cy82c693,   ide_4drives,
-   ide_pmac
-} hwif_chipset_t;
 
 #ifdef CONFIG_BLK_DEV_IDEPCI
 typedef struct ide_pci_devid_s {



P.S.


However, my "lsata"'s heuristics shows this as ATA1
(i.e. no ATA2 features used):

lsata /dev/hde

ihack for pcmcia compact flash
ATA Level = 1
ATAPI (Packet Interface): no
ATA Device Information for Command 0xEC

Conforming to 'AT Attachment for Disk Drives'
ANSI X3.221-1994
X3T10 791D Revision 4c Working Draft
All reserved Bits shall be zero (Chap. 8.8, p.25)

Word 0 General Configuration
1 Shall be 0. Reserved for non-magnetic drives
0 Format speed tolerance gap required ? 'no' : 'yes'
0 Track Offset 

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Andre Hedrick wrote:
> 
> I can not help if you have a device that not compliant to the rules.
> ATA-2 is OBSOLETED thus we forced (the NCITS Standards Body) the CFA
> people to move to ATA-4 or ATA-5.

See Alan's point about existing hardware.

> 
> That device is enabling (with its ablity to assert) its device->host
> interrupt regardless of the HOST...that is a bad device.

Does this imply ATA-4 specifies the device should
come up with nIEN set (i.e. interrupts disabled)?


> 
> Send me the manufacturer and I will tear them apart for making a
> non-compliant device.  

see below.

>Then figure out a way to de-assert the like
> regardless if it exists without hang the rest of the driver.
>

My patch has figured this out !
It enables interrupts again (clear nIEN) shortly before it registers the irq handler.
At least boot+root on /dev/hda do not hang.

Regards, Gunther



1) Compact Flash 48MB, Silicon Tech/Hitachi 
===
dump_cis
Socket 0:
  dev_info
fn_specific 400ns, 2kb
  common_jedec 0xdf 0x01
  manfid 0x014d, 0x0001
  vers_1 4.1, "SiliconTech,Inc.", "48MB Compact PC Card", "Ver 3.0"
  funcid fixed_disk [post]
  disk_interface [ide]
  disk_features [silicon] [unique] [single]
[sleep] [standby] [idle] [low power]
  config base 0x0200 mask 0x000f last_index 0x03
  cftable_entry 0x00 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V
memory 0x-0x07ff @ 0x
  cftable_entry 0x00
Vcc Vnom 3300mV Ipeak 45mA
  cftable_entry 0x01 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V
io 0x-0x000f [lines=4] [8bit] [16bit]
irq mask 0x [level] [pulse] [shared]
  cftable_entry 0x01
Vcc Vnom 3300mV Ipeak 45mA
  cftable_entry 0x02 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V
io 0x01f0-0x01f7, 0x03f6-0x03f7 [lines=10] [8bit] [16bit] [range]
irq 14 [level] [pulse] [shared]
  cftable_entry 0x02
Vcc Vnom 3300mV Ipeak 45mA
  cftable_entry 0x03 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V
io 0x0170-0x0177, 0x0376-0x0377 [lines=10] [8bit] [16bit] [range]
irq 14 [level] [pulse] [shared]
  cftable_entry 0x03
Vcc Vnom 3300mV Ipeak 45mA

Jun 27 17:32:13 linux kernel: hde: Hitachi CV 7.1.1, ATA DISK drive

2) Iomega Clik40

 dump_cis
Socket 0:
  dev_info
NULL 0ns, 512b
  attr_dev_info
EEPROM 250ns, 2kb
  vers_1 4.1, "PC CARD MANUFACTURER", "PCMCIA ATA/ATAPI Adapter",
"Version 3.00"
  manfid 0x, 0x0003
  funcid fixed_disk
  disk_interface [ide]
  config base 0x0800 mask 0x0001 last_index 0x05
  cftable_entry 0x25 [default]
io 0x0180-0x0187, 0x0386-0x0387 [lines=10] [16bit] [range]
irq mask 0xfe00 [level] [pulse]
  cftable_entry 0x0d
io 0x0170-0x0177, 0x0376-0x0377 [lines=10] [16bit] [range]
  cftable_entry 0x15
io 0x01e8-0x01ef, 0x03ee-0x03ef [lines=10] [16bit] [range]
  cftable_entry 0x1d
io 0x0168-0x016f, 0x036e-0x036f [lines=10] [16bit] [range]
  cftable_entry 0x05
io 0x01f0-0x01f7, 0x03f6-0x03f7 [lines=10] [16bit] [range]

Jun 27 17:36:39 linux kernel: hde: IOMEGA Clik! 40 CZ ATAPI, ATAPI cdrom or floppy?, 
assuming FLOPPY drive

> 
> On Tue, 26 Jun 2001, Gunther Mayer wrote:
> 
> > Hi,
> >
> > this patch fixes the hard hang (no SYSRQ) on inserting
> > any PCMCIA ATA/IDE card (e.g. CompactFlash, Clik40 etc)
> > to a PCI-Cardbus bridge add-in card.
> >
> > Thanks David for his valuable explanation about what happens:
> > ide-probe registers it's irq handler too late! After it
> > triggers the interrupt during the probe the (shared) irq
> > loops forever, effectively wedging the machine completely.
> >
> > Regards, Gunther
> >
> >
> >
> > --- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
> > +++ linux/drivers/ide/ide-cs.c  Tue Jun 26 21:22:19 2001
> > @@ -324,6 +324,9 @@
> >  if (link->io.NumPorts2)
> > release_region(link->io.BasePort2, link->io.NumPorts2);
> >
> > +outb(0x02, ctl_base); // Set nIEN = disable device interrupts
> > + // else it hangs on PCI-Cardbus add-in cards, wedging irq
> > +
> >  /* retry registration in case device is still spinning up */
> >  for (i = 0; i < 10; i++) {
> > hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
> > --- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
> > +++ linux/drivers/ide/ide-probe.c   Tue Jun 26 21:25:07 2001
> > @@ -685,6 +685,8 @@
> >  #else /* !CONFIG_IDEPCI_SHARE_IRQ */
> > int sa = (hwif->chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
>SA_INTERRUPT;
> >  #endif /* CONFIG_IDEPCI_SHARE_IRQ */
> > +
> > +   outb(0x00, hwif->io_ports[

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Andre Hedrick wrote:
 
 I can not help if you have a device that not compliant to the rules.
 ATA-2 is OBSOLETED thus we forced (the NCITS Standards Body) the CFA
 people to move to ATA-4 or ATA-5.

See Alan's point about existing hardware.

 
 That device is enabling (with its ablity to assert) its device-host
 interrupt regardless of the HOST...that is a bad device.

Does this imply ATA-4 specifies the device should
come up with nIEN set (i.e. interrupts disabled)?


 
 Send me the manufacturer and I will tear them apart for making a
 non-compliant device.  

see below.

Then figure out a way to de-assert the like
 regardless if it exists without hang the rest of the driver.


My patch has figured this out !
It enables interrupts again (clear nIEN) shortly before it registers the irq handler.
At least boot+root on /dev/hda do not hang.

Regards, Gunther



1) Compact Flash 48MB, Silicon Tech/Hitachi 
===
dump_cis
Socket 0:
  dev_info
fn_specific 400ns, 2kb
  common_jedec 0xdf 0x01
  manfid 0x014d, 0x0001
  vers_1 4.1, SiliconTech,Inc., 48MB Compact PC Card, Ver 3.0
  funcid fixed_disk [post]
  disk_interface [ide]
  disk_features [silicon] [unique] [single]
[sleep] [standby] [idle] [low power]
  config base 0x0200 mask 0x000f last_index 0x03
  cftable_entry 0x00 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V
memory 0x-0x07ff @ 0x
  cftable_entry 0x00
Vcc Vnom 3300mV Ipeak 45mA
  cftable_entry 0x01 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V
io 0x-0x000f [lines=4] [8bit] [16bit]
irq mask 0x [level] [pulse] [shared]
  cftable_entry 0x01
Vcc Vnom 3300mV Ipeak 45mA
  cftable_entry 0x02 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V
io 0x01f0-0x01f7, 0x03f6-0x03f7 [lines=10] [8bit] [16bit] [range]
irq 14 [level] [pulse] [shared]
  cftable_entry 0x02
Vcc Vnom 3300mV Ipeak 45mA
  cftable_entry 0x03 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V
io 0x0170-0x0177, 0x0376-0x0377 [lines=10] [8bit] [16bit] [range]
irq 14 [level] [pulse] [shared]
  cftable_entry 0x03
Vcc Vnom 3300mV Ipeak 45mA

Jun 27 17:32:13 linux kernel: hde: Hitachi CV 7.1.1, ATA DISK drive

2) Iomega Clik40

 dump_cis
Socket 0:
  dev_info
NULL 0ns, 512b
  attr_dev_info
EEPROM 250ns, 2kb
  vers_1 4.1, PC CARD MANUFACTURER, PCMCIA ATA/ATAPI Adapter,
Version 3.00
  manfid 0x, 0x0003
  funcid fixed_disk
  disk_interface [ide]
  config base 0x0800 mask 0x0001 last_index 0x05
  cftable_entry 0x25 [default]
io 0x0180-0x0187, 0x0386-0x0387 [lines=10] [16bit] [range]
irq mask 0xfe00 [level] [pulse]
  cftable_entry 0x0d
io 0x0170-0x0177, 0x0376-0x0377 [lines=10] [16bit] [range]
  cftable_entry 0x15
io 0x01e8-0x01ef, 0x03ee-0x03ef [lines=10] [16bit] [range]
  cftable_entry 0x1d
io 0x0168-0x016f, 0x036e-0x036f [lines=10] [16bit] [range]
  cftable_entry 0x05
io 0x01f0-0x01f7, 0x03f6-0x03f7 [lines=10] [16bit] [range]

Jun 27 17:36:39 linux kernel: hde: IOMEGA Clik! 40 CZ ATAPI, ATAPI cdrom or floppy?, 
assuming FLOPPY drive

 
 On Tue, 26 Jun 2001, Gunther Mayer wrote:
 
  Hi,
 
  this patch fixes the hard hang (no SYSRQ) on inserting
  any PCMCIA ATA/IDE card (e.g. CompactFlash, Clik40 etc)
  to a PCI-Cardbus bridge add-in card.
 
  Thanks David for his valuable explanation about what happens:
  ide-probe registers it's irq handler too late! After it
  triggers the interrupt during the probe the (shared) irq
  loops forever, effectively wedging the machine completely.
 
  Regards, Gunther
 
 
 
  --- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
  +++ linux/drivers/ide/ide-cs.c  Tue Jun 26 21:22:19 2001
  @@ -324,6 +324,9 @@
   if (link-io.NumPorts2)
  release_region(link-io.BasePort2, link-io.NumPorts2);
 
  +outb(0x02, ctl_base); // Set nIEN = disable device interrupts
  + // else it hangs on PCI-Cardbus add-in cards, wedging irq
  +
   /* retry registration in case device is still spinning up */
   for (i = 0; i  10; i++) {
  hd = ide_register(io_base, ctl_base, link-irq.AssignedIRQ);
  --- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
  +++ linux/drivers/ide/ide-probe.c   Tue Jun 26 21:25:07 2001
  @@ -685,6 +685,8 @@
   #else /* !CONFIG_IDEPCI_SHARE_IRQ */
  int sa = (hwif-chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
SA_INTERRUPT;
   #endif /* CONFIG_IDEPCI_SHARE_IRQ */
  +
  +   outb(0x00, hwif-io_ports[IDE_CONTROL_OFFSET]); // clear nIEN == 
enable irqs
  if (ide_request_irq(hwif-irq, ide_intr, sa, hwif-name, 
hwgroup)) {
  if (!match)
  kfree(hwgroup);
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org

patch(2.4.5): 2nd ed. Fix PCMCIA ATA/IDE + PCI IRQ sharing

[Gunther Mayer]

Hi,
this includes the last fix + now it is willing to share PCI irqs.
Of course you still need CONFIG_IDEPCI_SHARE_IRQ set.

Now CF is working very fine, hdparm-4.1 shows 1.27 MB/sec.
(Only after treaking the source for small (i.e. 64MB) devices).

Regards, Gunther




--- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
+++ linux/drivers/ide/ide-cs.c  Wed Jun 27 20:19:45 2001
@@ -42,6 +42,7 @@
 #include linux/ioport.h
 #include linux/hdreg.h
 #include linux/major.h
+#include linux/ide.h
 
 #include asm/io.h
 #include asm/system.h
@@ -223,6 +224,15 @@
 #define CFG_CHECK(fn, args...) \
 if (CardServices(fn, args) != 0) goto next_entry
 
+int idecs_register (int arg1, int arg2, int irq)
+{
+hw_regs_t hw;
+ide_init_hwif_ports(hw, (ide_ioreg_t) arg1, (ide_ioreg_t) arg2, NULL);
+hw.irq = irq;
+hw.chipset = ide_pci; // this enables IRQ sharing w/ PCI irqs
+return ide_register_hw(hw, NULL);
+}
+
 void ide_config(dev_link_t *link)
 {
 client_handle_t handle = link-handle;
@@ -324,12 +334,15 @@
 if (link-io.NumPorts2)
release_region(link-io.BasePort2, link-io.NumPorts2);
 
+outb(0x02, ctl_base); // Set nIEN = disable device interrupts
+ // else it hangs on PCI-Cardbus Add-in cards wedging irq
+
 /* retry registration in case device is still spinning up */
 for (i = 0; i  10; i++) {
-   hd = ide_register(io_base, ctl_base, link-irq.AssignedIRQ);
+   hd = idecs_register(io_base, ctl_base, link-irq.AssignedIRQ);
if (hd = 0) break;
if (link-io.NumPorts1 == 0x20) {
-   hd = ide_register(io_base+0x10, ctl_base+0x10,
+   hd = idecs_register(io_base+0x10, ctl_base+0x10,
  link-irq.AssignedIRQ);
if (hd = 0) {
io_base += 0x10; ctl_base += 0x10;
--- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
+++ linux/drivers/ide/ide-probe.c   Wed Jun 27 17:31:45 2001
@@ -685,6 +685,8 @@
 #else /* !CONFIG_IDEPCI_SHARE_IRQ */
int sa = (hwif-chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
SA_INTERRUPT;
 #endif /* CONFIG_IDEPCI_SHARE_IRQ */
+
+   outb(0x00, hwif-io_ports[IDE_CONTROL_OFFSET]); // clear nIEN == 
+enable irqs
if (ide_request_irq(hwif-irq, ide_intr, sa, hwif-name, hwgroup)) {
if (!match)
kfree(hwgroup);
--- linux245.orig/drivers/ide/ide.c Wed May  2 01:05:00 2001
+++ linux/drivers/ide/ide.c Wed Jun 27 20:18:23 2001
@@ -2181,6 +2181,7 @@
memcpy(hwif-io_ports, hwif-hw.io_ports, sizeof(hwif-hw.io_ports));
hwif-irq = hw-irq;
hwif-noprobe = 0;
+   hwif-chipset = hw-chipset;
 
if (!initializing) {
ide_probe_module();
--- linux245.orig/include/linux/ide.h   Sat May 26 03:02:42 2001
+++ linux/include/linux/ide.h   Wed Jun 27 19:01:35 2001
@@ -226,6 +226,19 @@
 #endif
 
 /*
+ * hwif_chipset_t is used to keep track of the specific hardware
+ * chipset used by each IDE interface, if known.
+ */
+typedef enum {  ide_unknown,ide_generic,ide_pci,
+ide_cmd640, ide_dtc2278,ide_ali14xx,
+ide_qd6580, ide_umc8672,ide_ht6560b,
+ide_pdc4030,ide_rz1000, ide_trm290,
+ide_cmd646, ide_cy82c693,   ide_4drives,
+ide_pmac
+} hwif_chipset_t;
+
+
+/*
  * Structure to hold all information about the location of this port
  */
 typedef struct hw_regs_s {
@@ -234,6 +247,7 @@
int dma;/* our dma entry */
ide_ack_intr_t  *ack_intr;  /* acknowledge interrupt */
void*priv;  /* interface specific data */
+   hwif_chipset_t  chipset;
 } hw_regs_t;
 
 /*
@@ -396,17 +410,6 @@
 typedef void (ide_maskproc_t) (ide_drive_t *, int);
 typedef void (ide_rw_proc_t) (ide_drive_t *, ide_dma_action_t);
 
-/*
- * hwif_chipset_t is used to keep track of the specific hardware
- * chipset used by each IDE interface, if known.
- */
-typedef enum { ide_unknown,ide_generic,ide_pci,
-   ide_cmd640, ide_dtc2278,ide_ali14xx,
-   ide_qd6580, ide_umc8672,ide_ht6560b,
-   ide_pdc4030,ide_rz1000, ide_trm290,
-   ide_cmd646, ide_cy82c693,   ide_4drives,
-   ide_pmac
-} hwif_chipset_t;
 
 #ifdef CONFIG_BLK_DEV_IDEPCI
 typedef struct ide_pci_devid_s {



P.S.


However, my lsata's heuristics shows this as ATA1
(i.e. no ATA2 features used):

lsata /dev/hde

ihack for pcmcia compact flash
ATA Level = 1
ATAPI (Packet Interface): no
ATA Device Information for Command 0xEC

Conforming to 'AT Attachment for Disk Drives'
ANSI X3.221-1994
X3T10 791D Revision 4c Working Draft
All reserved Bits shall be zero (Chap. 8.8, p.25)

Word 0 General Configuration
1 Shall be 0. Reserved for non-magnetic drives
0 Format speed 

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Andre Hedrick wrote:
 
 PARANIOA.

This is not a valid reason.

This clearly fixes a bug in linux. Note: the irq disable
is local to ide-cs. Are you paranoid enough to believe
enabling the irq by writing globally to the control register that
existed since ATA will have ill effects? 

You claim the relevant PCMCIA ATA behaviour is not ATA(3?) compliant,
however you didn`t yet give any facts to support this !

You claim this locks the driver, again no facts.


 
 Remember that ATAPI is generally screwed beyond reality, so adjusting the
 probe code in general (global) is a bad thing.
...
 On Wed, 27 Jun 2001, Alan Cox wrote:
 
   obsoleting ATA-2 did their attention at CFA become alarmed.  I agree that
   there needs to be a fix, but not at the price of locking the rest of the
   driver.  Since we now the identity of the device prior to assigned the
   interrupt we can handle the execption, but you do not go around blanket
   wacking the control register of all devices.

The proposed patch is very simple (as per Linus' liking). When considering to
install an earlier (and  global) irq handler I believe you can see
this will impose a much greater risk !

 
  I dont see why it locks up the driver ?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Hi,

this patch fixes the hard hang (no SYSRQ) on inserting
any PCMCIA ATA/IDE card (e.g. CompactFlash, Clik40 etc)
to a PCI-Cardbus bridge add-in card.

Thanks David for his valuable explanation about what happens:
ide-probe registers it's irq handler too late! After it
triggers the interrupt during the probe the (shared) irq
loops forever, effectively wedging the machine completely.

Regards, Gunther



--- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
+++ linux/drivers/ide/ide-cs.c  Tue Jun 26 21:22:19 2001
@@ -324,6 +324,9 @@
 if (link->io.NumPorts2)
release_region(link->io.BasePort2, link->io.NumPorts2);
 
+outb(0x02, ctl_base); // Set nIEN = disable device interrupts
+ // else it hangs on PCI-Cardbus add-in cards, wedging irq
+
 /* retry registration in case device is still spinning up */
 for (i = 0; i < 10; i++) {
hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
--- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
+++ linux/drivers/ide/ide-probe.c   Tue Jun 26 21:25:07 2001
@@ -685,6 +685,8 @@
 #else /* !CONFIG_IDEPCI_SHARE_IRQ */
int sa = (hwif->chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
SA_INTERRUPT;
 #endif /* CONFIG_IDEPCI_SHARE_IRQ */
+
+   outb(0x00, hwif->io_ports[IDE_CONTROL_OFFSET]); // clear nIEN == 
+enable irqs
if (ide_request_irq(hwif->irq, _intr, sa, hwif->name, hwgroup)) {
if (!match)
kfree(hwgroup);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Hi,

this patch fixes the hard hang (no SYSRQ) on inserting
any PCMCIA ATA/IDE card (e.g. CompactFlash, Clik40 etc)
to a PCI-Cardbus bridge add-in card.

Thanks David for his valuable explanation about what happens:
ide-probe registers it's irq handler too late! After it
triggers the interrupt during the probe the (shared) irq
loops forever, effectively wedging the machine completely.

Regards, Gunther



--- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
+++ linux/drivers/ide/ide-cs.c  Tue Jun 26 21:22:19 2001
@@ -324,6 +324,9 @@
 if (link-io.NumPorts2)
release_region(link-io.BasePort2, link-io.NumPorts2);
 
+outb(0x02, ctl_base); // Set nIEN = disable device interrupts
+ // else it hangs on PCI-Cardbus add-in cards, wedging irq
+
 /* retry registration in case device is still spinning up */
 for (i = 0; i  10; i++) {
hd = ide_register(io_base, ctl_base, link-irq.AssignedIRQ);
--- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
+++ linux/drivers/ide/ide-probe.c   Tue Jun 26 21:25:07 2001
@@ -685,6 +685,8 @@
 #else /* !CONFIG_IDEPCI_SHARE_IRQ */
int sa = (hwif-chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
SA_INTERRUPT;
 #endif /* CONFIG_IDEPCI_SHARE_IRQ */
+
+   outb(0x00, hwif-io_ports[IDE_CONTROL_OFFSET]); // clear nIEN == 
+enable irqs
if (ide_request_irq(hwif-irq, ide_intr, sa, hwif-name, hwgroup)) {
if (!match)
kfree(hwgroup);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PNP BIOS and parport_pc - dma found but not used

[Gunther Mayer]

Pavel Roskin wrote:
> 
> Hello, Gunther!
> 
> On Thu, 19 Apr 2001, Gunther Mayer wrote:
> 
> > > PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=-1
> >^^ culprit !
> 
> For some reason I'm not getting that message anymore. PnPBIOS is in the
> kernel, parport_pc is a module. This time I rebooted with the parport_pc
> module already installed, as opposed to the first time when I compiled and
> inserted it without a reboot.

Did you load "insmod pnpbios" the first time (as opposed to built-in)?

> 
> I'm puzzled. Just in case, it's my .config:
> http://www.red-bean.com/~proski/linux/config
> 
> Anyway, the result is still the same, just without this message.
> 
> > 1) Search for the right two-digit PNP handle for device "0104d041":
> 
> this is 01.
> 
> >cat /proc/bus/pnb/devices
> 
> 01  0104d04107:01:000080
> 02  0105d04107:00:020180
> 06  0007d04101:02:000003
> 08  010cd04105:00:000003
> 09  d04108:00:010003
> 0a  0001d04108:02:010003
> 0b  000bd04108:03:010003
> 0c  0303d04109:00:00000b
> 0d  040cd0410b:01:000003
> 0e  0002d04108:01:010003
> 0f  0008d04108:80:000003
> 10  030ad04106:04:000003
> 11  020cd04108:80:ff0003
> 
> > 2) Send cat /proc/bus/pnp/01 | od -tx1
> 
> 000 2a 00 00 22 80 00 47 01 78 03 78 03 00 08 47 01
 ^^
 This is "NO DMA" (we map this in parport to -1, which means Unknown).
Your PNPBIOS is buggy, this should be "08" for dma=3


> 020 78 07 78 07 00 08 79 00 30 2a 0a 00 22 80 00 47
^^
Possible settings are: 08|02 i.e. dma=3|1
> 040 01 bc 03 bc 03 00 03 47 01 bc 07 bc 07 00 03 30
> 060 2a 0a 00 22 80 00 47 01 78 03 78 03 00 08 47 01
> 100 78 07 78 07 00 08 30 2a 0a 00 22 20 00 47 01 78
> 120 02 78 02 00 08 47 01 78 06 78 06 00 08 38 79 00
> 140 79 00
> 
> Settings:
> Parallel port mode: ECP+EPP
> ECP DMA select: 3

Try to get an update for your BIOS or file a bug report to your
mainboard vendor else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PNP BIOS and parport_pc - dma found but not used

[Gunther Mayer]

Pavel Roskin wrote:
...
> 
> There is another interesting line in the log that you didn't quote. The
> driver actually knows about DMA 3:
> 
> 0x378: ECP settings irq=7 dma=3

The parport code only uses DMA when told by the user, so 
insmod parport_pc dma=auto
should to the trick. Parport DMA transfers are considered experimental still,
so this is not the default.

> 
> Just in case, that board is Asus P5A-B with the latest BIOS:
> P5A-B BIOS ver. 1010, 05/31/2000
> 
> For comparison, I took a board with VIA chipset and PhoenixBIOS 4.0
> Release 6.0, and it works properly with another 2.4.3-ac9 kernel:

Fine. With PNPBIOS or ACPI you don't currently need dma=auto.
This is subject to change probably (see above).

> 
> Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
> SMSC Super-IO detection, now testing Ports 2F0, 370 ...
> PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=3
> 0x378: FIFO is 16 bytes
> 0x378: writeIntrThreshold is 8
> 0x378: readIntrThreshold is 8
> 0x378: PWord is 8 bits
> 0x378: Interrupts are ISA-Pulses
> 0x378: ECP port cfgA=0x10 cfgB=0x4b
> 0x378: ECP settings irq=7 dma=3
> parport0: PC-style at 0x378 (0x778), irq 7, dma 3
> [PCSPP,TRISTATE,COMPAT,ECP,DMA]
> parport0: cpp_daisy: aa5500ff(38)
> parport0: assign_addrs: aa5500ff(38)
> parport0: cpp_daisy: aa5500ff(38)
> parport0: assign_addrs: aa5500ff(38)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PNP BIOS and parport_pc - dma found but not used

[Gunther Mayer]

Pavel Roskin wrote:
> 
> Hello!
> 
> I've compiled 2.4.3-ac9 with support for PNP BIOS. I understand that this
> is a new feature experimental and the feedback is requested.
> 
> The setting is BIOS is to use irq 7 and dma 3. I normally use "options
> parport_pc io=0x378 irq=7 dma=3" in /etc/modules.conf, but this time I
> commented them out hoping that the driver will ask BIOS.
> 
> Although the kernel can see those settings, the dma is not used by the
> driver. This is the output from dmesg.
> 
> PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=-1
   ^^ culprit !

Send me the raw PNP resource data so I can look into this:

1) Search for the right two-digit PNP handle for device "0104d041":
   cat /proc/bus/pnb/devices
   01  0104d04107:01:000080
   02  0105d04107:00:020180
   03  1005d04107:00:020180
   04  0007d04101:02:000003
   ...

   The number in the first column (here: 01) is the handle
   to be used in step 2.

2) Send cat /proc/bus/pnp/01 | od -tx1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PNP BIOS and parport_pc - dma found but not used

[Gunther Mayer]

Pavel Roskin wrote:
 
 Hello!
 
 I've compiled 2.4.3-ac9 with support for PNP BIOS. I understand that this
 is a new feature experimental and the feedback is requested.
 
 The setting is BIOS is to use irq 7 and dma 3. I normally use "options
 parport_pc io=0x378 irq=7 dma=3" in /etc/modules.conf, but this time I
 commented them out hoping that the driver will ask BIOS.
 
 Although the kernel can see those settings, the dma is not used by the
 driver. This is the output from dmesg.
 
 PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=-1
   ^^ culprit !

Send me the raw PNP resource data so I can look into this:

1) Search for the right two-digit PNP handle for device "0104d041":
   cat /proc/bus/pnb/devices
   01  0104d04107:01:000080
   02  0105d04107:00:020180
   03  1005d04107:00:020180
   04  0007d04101:02:000003
   ...

   The number in the first column (here: 01) is the handle
   to be used in step 2.

2) Send cat /proc/bus/pnp/01 | od -tx1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PNP BIOS and parport_pc - dma found but not used

[Gunther Mayer]

Pavel Roskin wrote:
...
 
 There is another interesting line in the log that you didn't quote. The
 driver actually knows about DMA 3:
 
 0x378: ECP settings irq=7 dma=3

The parport code only uses DMA when told by the user, so 
insmod parport_pc dma=auto
should to the trick. Parport DMA transfers are considered experimental still,
so this is not the default.

 
 Just in case, that board is Asus P5A-B with the latest BIOS:
 P5A-B BIOS ver. 1010, 05/31/2000
 
 For comparison, I took a board with VIA chipset and PhoenixBIOS 4.0
 Release 6.0, and it works properly with another 2.4.3-ac9 kernel:

Fine. With PNPBIOS or ACPI you don't currently need dma=auto.
This is subject to change probably (see above).

 
 Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
 SMSC Super-IO detection, now testing Ports 2F0, 370 ...
 PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=3
 0x378: FIFO is 16 bytes
 0x378: writeIntrThreshold is 8
 0x378: readIntrThreshold is 8
 0x378: PWord is 8 bits
 0x378: Interrupts are ISA-Pulses
 0x378: ECP port cfgA=0x10 cfgB=0x4b
 0x378: ECP settings irq=7 dma=3
 parport0: PC-style at 0x378 (0x778), irq 7, dma 3
 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
 parport0: cpp_daisy: aa5500ff(38)
 parport0: assign_addrs: aa5500ff(38)
 parport0: cpp_daisy: aa5500ff(38)
 parport0: assign_addrs: aa5500ff(38)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: (ide.2.2.19.04092001.patch:) DiskPerf compile problem

[Gunther Mayer]

Andre Hedrick wrote:
> 
...
> DiskPerf /dev/hde
> Device: IBM-DTLA-307075 Serial Number: YSDYSFA5874
> LBA 0 DMA Read Test  = 63.35 MB/Sec (3.95 Seconds)
> Outer Diameter Sequential DMA Read Test  = 35.89 MB/Sec (6.97 Seconds)
> Inner Diameter Sequential DMA Read Test  = 17.64 MB/Sec (14.17 Seconds)

Where can I get the latest DiskPerf?

The version on:
http://www.xx.kernel.org/pub/linux/kernel/people/hedrick/utility-patches/DiskPerf-1.0.1.tar.gz
does not compile at all:

linux:~/DiskPerf-1.0 # make
gcc -o DiskPerf -O3 -lglib DiskPerf.c
DiskPerf.c: In function `ataRead':
DiskPerf.c:155: storage size of `reqtask' isn't known
DiskPerf.c:156: storage size of `taskfile' isn't known
DiskPerf.c:157: `ide_reg_valid_t' undeclared (first use in this function)
...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: (ide.2.2.19.04092001.patch:) DiskPerf compile problem

[Gunther Mayer]

Andre Hedrick wrote:
 
...
 DiskPerf /dev/hde
 Device: IBM-DTLA-307075 Serial Number: YSDYSFA5874
 LBA 0 DMA Read Test  = 63.35 MB/Sec (3.95 Seconds)
 Outer Diameter Sequential DMA Read Test  = 35.89 MB/Sec (6.97 Seconds)
 Inner Diameter Sequential DMA Read Test  = 17.64 MB/Sec (14.17 Seconds)

Where can I get the latest DiskPerf?

The version on:
http://www.xx.kernel.org/pub/linux/kernel/people/hedrick/utility-patches/DiskPerf-1.0.1.tar.gz
does not compile at all:

linux:~/DiskPerf-1.0 # make
gcc -o DiskPerf -O3 -lglib DiskPerf.c
DiskPerf.c: In function `ataRead':
DiskPerf.c:155: storage size of `reqtask' isn't known
DiskPerf.c:156: storage size of `taskfile' isn't known
DiskPerf.c:157: `ide_reg_valid_t' undeclared (first use in this function)
...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mouse problems in 2.4.2 -> lost byte -> Patch(2.4.3)!

[Gunther Mayer]

Original Problem: PS/2 mouse pointer goes upper right corner and stays there.
Diagnosis: one byte was lost and this is fatal for the mouse driver.

Various people wrote:
> 
> On Wed, Mar 28, 2001 at 05:19:33PM -0600, [EMAIL PROTECTED] wrote:
..
> > > > > > > I am experiencing debilitating intermittent mouse problems & was about
> > > > > >
> > > > > > This is easily explained: some byte of the mouse protocol was lost.
> 
> Plus, it's very likely the new PS/2 code will break on some systems that
> have not-so-compatible i8042 chips, so it is really something that can't


Losing bytes on psaux is a bug!

We must first understand, how bytes can be lost (most probable first):
- transmission error on the line can easily happen in noisy environments
   and is _not_ handled correctly by linux (i.e. should do RESEND)
- 0xAA is always handled as reconnect, if the mouse generates this byte,
   Linux will de-sync the mouse driver
- Mouse is defective or keyboard controller defective
- An error in the linux kbd/mouse driver (e.g. triggered by X11<->console switching)

This patch printk's necessary information on the first 2 cases and
should be applied to the stable kernel, as this will help to resolve a severe bug !

Regards, Gunther

P.S.
These messages can be generated:
Apr  8 21:49:23 linux kernel: psaux: reconnect 0xAA detected
Apr  8 21:49:42 linux kernel: pc_keyb: mouse error (0x75), byte ignored(ff).
Apr  8 21:49:43 linux kernel: psaux: reconnect 0xAA detected


--- linux-2.4.3-orig/drivers/char/pc_keyb.c Wed Apr  4 19:46:42 2001
+++ linux/drivers/char/pc_keyb.cSun Apr  8 21:45:37 2001
@@ -404,6 +404,11 @@
mouse_reply_expected = 0;
}
else if(scancode == AUX_RECONNECT){
+   // Under normal operation most mice don't generate 0xAA.
+   // But, Other devices might be unusable with this policy.
+   //  (My mouse easily generates 0xAAs on rapid movements,
+   //   when set to 10 samples/sec.)
+   printk("psaux: reconnect detected(0xaa), sending AUX_ENABLE.\n");
queue->head = queue->tail = 0;  /* Flush input queue */
__aux_write_ack(AUX_ENABLE_DEV);  /* ping the mouse :) */
return;
@@ -420,6 +425,9 @@
kill_fasync(>fasync, SIGIO, POLL_IN);
wake_up_interruptible(>proc_list);
}
+   else
+   // 2K buffer is enough for about 10 sec under normal 
+operations, here.
+   printk("psaux: buffer overflow, byte dropped.\n");
}
 #endif
 }
@@ -465,6 +473,11 @@
else
handle_keyboard_event(scancode);
}
+   else
+   // Fixme: Ignoring bytes will de-sync mouse protocol.
+   printk("pc_keyb: %s error (0x%02x), byte ignored(%02x).\n",
+   (status & KBD_STAT_MOUSE_OBF)?"mouse":"kbd",status,scancode);
+
 
status = kbd_read_status();
}
 gmdiff-lx243-psaux-error-reporting

Re: mouse problems in 2.4.2 - lost byte - Patch(2.4.3)!

[Gunther Mayer]

Original Problem: PS/2 mouse pointer goes upper right corner and stays there.
Diagnosis: one byte was lost and this is fatal for the mouse driver.

Various people wrote:
 
 On Wed, Mar 28, 2001 at 05:19:33PM -0600, [EMAIL PROTECTED] wrote:
..
   I am experiencing debilitating intermittent mouse problems  was about
 
  This is easily explained: some byte of the mouse protocol was lost.
 
 Plus, it's very likely the new PS/2 code will break on some systems that
 have not-so-compatible i8042 chips, so it is really something that can't


Losing bytes on psaux is a bug!

We must first understand, how bytes can be lost (most probable first):
- transmission error on the line can easily happen in noisy environments
   and is _not_ handled correctly by linux (i.e. should do RESEND)
- 0xAA is always handled as reconnect, if the mouse generates this byte,
   Linux will de-sync the mouse driver
- Mouse is defective or keyboard controller defective
- An error in the linux kbd/mouse driver (e.g. triggered by X11-console switching)

This patch printk's necessary information on the first 2 cases and
should be applied to the stable kernel, as this will help to resolve a severe bug !

Regards, Gunther

P.S.
These messages can be generated:
Apr  8 21:49:23 linux kernel: psaux: reconnect 0xAA detected
Apr  8 21:49:42 linux kernel: pc_keyb: mouse error (0x75), byte ignored(ff).
Apr  8 21:49:43 linux kernel: psaux: reconnect 0xAA detected


--- linux-2.4.3-orig/drivers/char/pc_keyb.c Wed Apr  4 19:46:42 2001
+++ linux/drivers/char/pc_keyb.cSun Apr  8 21:45:37 2001
@@ -404,6 +404,11 @@
mouse_reply_expected = 0;
}
else if(scancode == AUX_RECONNECT){
+   // Under normal operation most mice don't generate 0xAA.
+   // But, Other devices might be unusable with this policy.
+   //  (My mouse easily generates 0xAAs on rapid movements,
+   //   when set to 10 samples/sec.)
+   printk("psaux: reconnect detected(0xaa), sending AUX_ENABLE.\n");
queue-head = queue-tail = 0;  /* Flush input queue */
__aux_write_ack(AUX_ENABLE_DEV);  /* ping the mouse :) */
return;
@@ -420,6 +425,9 @@
kill_fasync(queue-fasync, SIGIO, POLL_IN);
wake_up_interruptible(queue-proc_list);
}
+   else
+   // 2K buffer is enough for about 10 sec under normal 
+operations, here.
+   printk("psaux: buffer overflow, byte dropped.\n");
}
 #endif
 }
@@ -465,6 +473,11 @@
else
handle_keyboard_event(scancode);
}
+   else
+   // Fixme: Ignoring bytes will de-sync mouse protocol.
+   printk("pc_keyb: %s error (0x%02x), byte ignored(%02x).\n",
+   (status  KBD_STAT_MOUSE_OBF)?"mouse":"kbd",status,scancode);
+
 
status = kbd_read_status();
}
 gmdiff-lx243-psaux-error-reporting

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Gérard Roudier wrote:
> 
> On Sat, 7 Apr 2001, Tim Waugh wrote:
> 
> > On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote:
> >
> > > Please apply this little patch instead of wasting time by
> > > finger-pointing and arguing.
> >
> > This patch would make me happy.
> >
> > It would allow support for new multi-IO cards to generally be the
> > addition of about two lines to two files (which is currently how it's
> > done), rather than having separate mutant hybrid monstrosity drivers
> > for each card (IMHO)..
> 
> It is possible to design a single function PCI device that is able to do
> everything. Your approach is just encouraging this kind of monstrosity.
> Such montrosity will look like some single-IRQ capable ISA remake, thus
> worse than 20 years old ISA.
> 
> If we want to encourage that, then we want to stay stupid for life, in my
> nervous opinion.

If you want to discourage hardware vendors, they will stay with Windows.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Jeff Garzik wrote:
> 
 Like I mentioned in a
> previous message, the Via parport code is ugly and should go into a Via
> superio driver.  It is simply not scalable to consider the alternative
> -- add superio code to parport_pc.c for each ISA bridge out there.  I
> think the same principle applies to this discussion as well.  

Yes, superio will go away and replaced by user level utility:
http://home.t-online.de/home/gunther.mayer/lssuperio-0.61.tar.bz2

PNPBIOS and ACPI will help to configure parallel ports (and others),
after some issues have been resolved.

Again this will be builtin to parport (and not parport_acpi.o etc)
to make it failproof.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Jeff Garzik wrote:
> 
> Gunther Mayer wrote:
> > Hardware has always needed quirks (linux-2.4.3 has about 60 occurences
> > of the word "quirks", not to mention workaround, blacklist and other synonyms)!
> >
> > Please apply this little patch instead of wasting time by finger-pointing
> > and arguing.
> >
> > Martin, comments?
> 
> Is Martin still alive?  He hasn't been active in PCI development well
> over six months, maybe a year now.  Ivan (alpha hacker) appeared on the
> scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA
> stuff, and I've added a couple driver-related things.  I haven't seen
> code from Martin in a long long time, and only a comment or two in
> recent memory.

See linux/MAINTAINERS for "PCI Subsystem", the attribute is even called:
 "Supported:  Someone is actually paid to look after this".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Jeff Garzik wrote:
> 
> Tim Waugh wrote:
> > It would allow support for new multi-IO cards to generally be the
> > addition of about two lines to two files (which is currently how it's
> > done), rather than having separate mutant hybrid monstrosity drivers
> > for each card (IMHO)..
> 
> ;-)
> 
> My point of view is that hacking the kernel so that two device drivers
> can pretend they are not driving the same hardware is silly.  With such
> hardware there are always inter-dependencies, and you can either hack
> special case code into two or more drivers, or create one central
> control point from which knowledge is dispatched.  Like I mentioned in a

My point of view is making it easy for the average user.
This is the same as making it easy for maintainers of hardware drivers !

More module interdependencies == More complicated == More clueless users

Many users will be surprised if they must load another module (e.g."pci_multiio")
to get their parallel and serial ports working.

Thus _must not_ happen in the stable release.

Regards, Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Tim Waugh wrote:
> 
> On Sat, Apr 07, 2001 at 04:57:29AM -0400, Jeff Garzik wrote:
> 
> > Where is this patch available?  I haven't heard of an extension to the
> > pci id tables, so I wonder if it's really in the queue for the official
> > kernel.
> 
> It is.  http://people.redhat.com/twaugh/patches/>  The
> 'extension' is just 'more entries', AFAIR.
> 
> > > I'm afraid this is not a bug, but a design issue, and will be hard to
> > > solve. Maybe we need a flag for such devices which allows it to be
> > > claimed ba more thean one driver?
> >
> > Not so hard.
> 
> *sigh* Jeff, when I spoke to you about this last year you said
>  'tough', or words to that effect. :-(
> 
> > There is no need to register more than one driver per PCI device -- just
> > create a PCI driver whose probe routine registers serial and parallel,
> > and whose remove routine unregisters same.
> 
> *cough* modularity *cough*
> 
> Wnat to show us some elegant code that does that?

Hardware has always needed quirks (linux-2.4.3 has about 60 occurences
of the word "quirks", not to mention workaround, blacklist and other synonyms)!

Please apply this little patch instead of wasting time by finger-pointing
and arguing.

Martin, comments?


Regards, Gunther 



--- linux-2.4.3-orig/include/linux/pci.hWed Apr  4 19:46:49 2001
+++ linux/include/linux/pci.h   Sat Apr  7 20:01:51 2001
@@ -454,6 +454,9 @@
void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not a 
hot-plug capable driver) */
void (*suspend)(struct pci_dev *dev);   /* Device suspended */
void (*resume)(struct pci_dev *dev);/* Device woken up */
+   int multifunction_quirks;   /* Quirks for PCI serial+parport cards,
+   here multiple drivers are allowed 
+to register
+   for the same pci id match */
 };


--- linux-2.4.3-orig/drivers/pci/pci.c  Wed Apr  4 19:46:46 2001
+++ linux/drivers/pci/pci.c Sat Apr  7 19:59:47 2001
@@ -453,7 +453,7 @@

list_add_tail(>node, _drivers);
pci_for_each_dev(dev) {
-   if (!pci_dev_driver(dev))
+   if (!pci_dev_driver(dev) || drv->multifunction_quirks)
count += pci_announce_device(drv, dev);
}
return count;
--- linux-2.4.3-orig/drivers/parport/parport_pc.c   Wed Apr  4 19:46:46 2001
+++ linux/drivers/parport/parport_pc.c  Sat Apr  7 20:18:37 2001
@@ -2539,6 +2539,7 @@
name:   "parport_pc",
id_table:   parport_pc_pci_tbl,
probe:  parport_pc_pci_probe,
+   multifunction_quirks: 1,
 };

 static int __init parport_pc_init_superio (void)
--- linux-2.4.3-orig/drivers/char/serial.c  Wed Apr  4 19:46:43 2001
+++ linux/drivers/char/serial.c Sat Apr  7 20:00:00 2001
@@ -4178,7 +4178,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
-   if (pci_get_subvendor(dev) == ids[j]) {
+   if (pci_get_subdevice(dev) == ids[j]) {
board->num_ports = timedia_data[i].num;
return 0;
}
@@ -4718,6 +4718,7 @@
probe:  serial_init_one,
remove:serial_remove_one,
id_table:   serial_pci_tbl,
+   multifunction_quirks: 1,
 };
 gmdiff-lx243-pci-multi_io

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Tim Waugh wrote:
 
 On Sat, Apr 07, 2001 at 04:57:29AM -0400, Jeff Garzik wrote:
 
  Where is this patch available?  I haven't heard of an extension to the
  pci id tables, so I wonder if it's really in the queue for the official
  kernel.
 
 It is.  URL:http://people.redhat.com/twaugh/patches/  The
 'extension' is just 'more entries', AFAIR.
 
   I'm afraid this is not a bug, but a design issue, and will be hard to
   solve. Maybe we need a flag for such devices which allows it to be
   claimed ba more thean one driver?
 
  Not so hard.
 
 *sigh* Jeff, when I spoke to you about this last year you said
  'tough', or words to that effect. :-(
 
  There is no need to register more than one driver per PCI device -- just
  create a PCI driver whose probe routine registers serial and parallel,
  and whose remove routine unregisters same.
 
 *cough* modularity *cough*
 
 Wnat to show us some elegant code that does that?

Hardware has always needed quirks (linux-2.4.3 has about 60 occurences
of the word "quirks", not to mention workaround, blacklist and other synonyms)!

Please apply this little patch instead of wasting time by finger-pointing
and arguing.

Martin, comments?


Regards, Gunther 



--- linux-2.4.3-orig/include/linux/pci.hWed Apr  4 19:46:49 2001
+++ linux/include/linux/pci.h   Sat Apr  7 20:01:51 2001
@@ -454,6 +454,9 @@
void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not a 
hot-plug capable driver) */
void (*suspend)(struct pci_dev *dev);   /* Device suspended */
void (*resume)(struct pci_dev *dev);/* Device woken up */
+   int multifunction_quirks;   /* Quirks for PCI serial+parport cards,
+   here multiple drivers are allowed 
+to register
+   for the same pci id match */
 };


--- linux-2.4.3-orig/drivers/pci/pci.c  Wed Apr  4 19:46:46 2001
+++ linux/drivers/pci/pci.c Sat Apr  7 19:59:47 2001
@@ -453,7 +453,7 @@

list_add_tail(drv-node, pci_drivers);
pci_for_each_dev(dev) {
-   if (!pci_dev_driver(dev))
+   if (!pci_dev_driver(dev) || drv-multifunction_quirks)
count += pci_announce_device(drv, dev);
}
return count;
--- linux-2.4.3-orig/drivers/parport/parport_pc.c   Wed Apr  4 19:46:46 2001
+++ linux/drivers/parport/parport_pc.c  Sat Apr  7 20:18:37 2001
@@ -2539,6 +2539,7 @@
name:   "parport_pc",
id_table:   parport_pc_pci_tbl,
probe:  parport_pc_pci_probe,
+   multifunction_quirks: 1,
 };

 static int __init parport_pc_init_superio (void)
--- linux-2.4.3-orig/drivers/char/serial.c  Wed Apr  4 19:46:43 2001
+++ linux/drivers/char/serial.c Sat Apr  7 20:00:00 2001
@@ -4178,7 +4178,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
-   if (pci_get_subvendor(dev) == ids[j]) {
+   if (pci_get_subdevice(dev) == ids[j]) {
board-num_ports = timedia_data[i].num;
return 0;
}
@@ -4718,6 +4718,7 @@
probe:  serial_init_one,
remove:serial_remove_one,
id_table:   serial_pci_tbl,
+   multifunction_quirks: 1,
 };
 gmdiff-lx243-pci-multi_io

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Jeff Garzik wrote:
 
 Gunther Mayer wrote:
  Hardware has always needed quirks (linux-2.4.3 has about 60 occurences
  of the word "quirks", not to mention workaround, blacklist and other synonyms)!
 
  Please apply this little patch instead of wasting time by finger-pointing
  and arguing.
 
  Martin, comments?
 
 Is Martin still alive?  He hasn't been active in PCI development well
 over six months, maybe a year now.  Ivan (alpha hacker) appeared on the
 scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA
 stuff, and I've added a couple driver-related things.  I haven't seen
 code from Martin in a long long time, and only a comment or two in
 recent memory.

See linux/MAINTAINERS for "PCI Subsystem", the attribute is even called:
 "Supported:  Someone is actually paid to look after this".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Jeff Garzik wrote:
 
 Tim Waugh wrote:
  It would allow support for new multi-IO cards to generally be the
  addition of about two lines to two files (which is currently how it's
  done), rather than having separate mutant hybrid monstrosity drivers
  for each card (IMHO)..
 
 ;-)
 
 My point of view is that hacking the kernel so that two device drivers
 can pretend they are not driving the same hardware is silly.  With such
 hardware there are always inter-dependencies, and you can either hack
 special case code into two or more drivers, or create one central
 control point from which knowledge is dispatched.  Like I mentioned in a

My point of view is making it easy for the average user.
This is the same as making it easy for maintainers of hardware drivers !

More module interdependencies == More complicated == More clueless users

Many users will be surprised if they must load another module (e.g."pci_multiio")
to get their parallel and serial ports working.

Thus _must not_ happen in the stable release.

Regards, Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Jeff Garzik wrote:
 
 Like I mentioned in a
 previous message, the Via parport code is ugly and should go into a Via
 superio driver.  It is simply not scalable to consider the alternative
 -- add superio code to parport_pc.c for each ISA bridge out there.  I
 think the same principle applies to this discussion as well.  

Yes, superio will go away and replaced by user level utility:
http://home.t-online.de/home/gunther.mayer/lssuperio-0.61.tar.bz2

PNPBIOS and ACPI will help to configure parallel ports (and others),
after some issues have been resolved.

Again this will be builtin to parport (and not parport_acpi.o etc)
to make it failproof.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Grard Roudier wrote:
 
 On Sat, 7 Apr 2001, Tim Waugh wrote:
 
  On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote:
 
   Please apply this little patch instead of wasting time by
   finger-pointing and arguing.
 
  This patch would make me happy.
 
  It would allow support for new multi-IO cards to generally be the
  addition of about two lines to two files (which is currently how it's
  done), rather than having separate mutant hybrid monstrosity drivers
  for each card (IMHO)..
 
 It is possible to design a single function PCI device that is able to do
 everything. Your approach is just encouraging this kind of monstrosity.
 Such montrosity will look like some single-IRQ capable ISA remake, thus
 worse than 20 years old ISA.
 
 If we want to encourage that, then we want to stay stupid for life, in my
 nervous opinion.

If you want to discourage hardware vendors, they will stay with Windows.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mouse problems in 2.4.2 -> lost byte

[Gunther Mayer]

[EMAIL PROTECTED] wrote:
> 
> It's been rumoured that Gunther Mayer said:
> >
> > > I am experiencing debilitating intermittent mouse problems & was about
> > ...
> > > Symptoms:
> > > After a long time of flawless operation (ranging from nearly a week to
> > > as little as five minutes), the X11 pointer flies up to top-right corner,
> >   
> > > and mostly wants to stay there.  Moving the mouse causes a cascade of
> > > spurious button-press events get generated.
> >
> > This is easily explained: some byte of the mouse protocol was lost.
> 
> Bing!
> 
> That's it! This would also explain why gpm seems to work i.e. correctly
> process the events, even when X11 can't.  I will take this up on the
> Xf86 lists ...
> 
> > (Some mouse protocols are even designed to allow
> >  easy resync/recovery by fixed bit patterns!)
> 
> This mouse seems to set every fourth byte to zero, which should allow
> syncing ...

The fourth byte is propably the wheel or 5 button support, see
http://www.microsoft.com/hwdev/input/5b_wheel.htm
to get a hint about mouse protocol variations.

Getting resync right is not as easy as detecting zero bytes. You
should account for wild protocol variations in the world wide mouse
population, too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mouse problems in 2.4.2 -> lost byte

[Gunther Mayer]

James Simmons wrote:
> 
> >Where can I get your driver?
> 
> I attach it to the other posting to this thread. I also have it in CVS at
> http://linuxconsole.sourceforge.net with a bunch of other input drivers.
> 
> >> Section "Pointer"
> >> Protocol"ImPS/2"
> >> Device  "/dev/input/mice"
> >
> >What is better in using /dev/input/mice than /dev/psaux
> >on this problem exactly?
> 
> The reason to use /dev/input/mice is the PS/2 mouse driver itself has not
^^^

So you recommend to connect the mouse to USB (instead of psaux) because
psaux+Xfree86 are losing bytes under circumstances (e.g. some load pattern).

This is a fine solution for users with dual protocol mice, but doesn't
resolve the problem for other poor ps/2 mouse owners !

> been ported over to the input suite for 2.4.X. You can use the above for
> the USB mouse now. Now if you have a USB mouse plus a PS/2 mouse then
> having both use /dev/psaux would require a reworking of the PS/2 driver.
> I rather port over the PS/2 mouse to use /dev/input/mice. I have done this
> for my CVS but since the PS/2 mouse shares the same chipset as the PS/2
> keyboard you have to use both input drivers. It would be better if XFree86
> would have a /dev/eventX driver but we would wait a long time for that to
> happen :-(

Even with PS/2 mouse support in the "new input" driver I wouldn't expect the 
psaux-byte-lost bug to disappear magically.
-

Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mouse problems in 2.4.2 - lost byte

[Gunther Mayer]

James Simmons wrote:
 
 Where can I get your driver?
 
 I attach it to the other posting to this thread. I also have it in CVS at
 http://linuxconsole.sourceforge.net with a bunch of other input drivers.
 
  Section "Pointer"
  Protocol"ImPS/2"
  Device  "/dev/input/mice"
 
 What is better in using /dev/input/mice than /dev/psaux
 on this problem exactly?
 
 The reason to use /dev/input/mice is the PS/2 mouse driver itself has not
^^^

So you recommend to connect the mouse to USB (instead of psaux) because
psaux+Xfree86 are losing bytes under circumstances (e.g. some load pattern).

This is a fine solution for users with dual protocol mice, but doesn't
resolve the problem for other poor ps/2 mouse owners !

 been ported over to the input suite for 2.4.X. You can use the above for
 the USB mouse now. Now if you have a USB mouse plus a PS/2 mouse then
 having both use /dev/psaux would require a reworking of the PS/2 driver.
 I rather port over the PS/2 mouse to use /dev/input/mice. I have done this
 for my CVS but since the PS/2 mouse shares the same chipset as the PS/2
 keyboard you have to use both input drivers. It would be better if XFree86
 would have a /dev/eventX driver but we would wait a long time for that to
 happen :-(

Even with PS/2 mouse support in the "new input" driver I wouldn't expect the 
psaux-byte-lost bug to disappear magically.
-

Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mouse problems in 2.4.2 - lost byte

[Gunther Mayer]

[EMAIL PROTECTED] wrote:
 
 It's been rumoured that Gunther Mayer said:
 
   I am experiencing debilitating intermittent mouse problems  was about
  ...
   Symptoms:
   After a long time of flawless operation (ranging from nearly a week to
   as little as five minutes), the X11 pointer flies up to top-right corner,

   and mostly wants to stay there.  Moving the mouse causes a cascade of
   spurious button-press events get generated.
 
  This is easily explained: some byte of the mouse protocol was lost.
 
 Bing!
 
 That's it! This would also explain why gpm seems to work i.e. correctly
 process the events, even when X11 can't.  I will take this up on the
 Xf86 lists ...
 
  (Some mouse protocols are even designed to allow
   easy resync/recovery by fixed bit patterns!)
 
 This mouse seems to set every fourth byte to zero, which should allow
 syncing ...

The fourth byte is propably the wheel or 5 button support, see
http://www.microsoft.com/hwdev/input/5b_wheel.htm
to get a hint about mouse protocol variations.

Getting resync right is not as easy as detecting zero bytes. You
should account for wild protocol variations in the world wide mouse
population, too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mouse problems in 2.4.2 -> lost byte

[Gunther Mayer]

James Simmons wrote:
> 
> >This is easily explained: some byte of the mouse protocol was lost.
> >(Some mouse protocols are even designed to allow
> >easy resync/recovery by fixed bit patterns!)
> >
> >Write an intelligent mouse driver for XFree86 to compensate for
> >lost bytes.
> 
> Or write a kernel input device driver. In fact I probable have a mouse
> driver for you. 

Where can I get your driver?


>What kind of mouse do you have? Then set your X config to
> have the following:
> 
> Section "Pointer"
> Protocol"ImPS/2"
> Device  "/dev/input/mice"

What is better in using /dev/input/mice than /dev/psaux
on this problem exactly?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mouse problems in 2.4.2 -> lost byte

[Gunther Mayer]

[EMAIL PROTECTED] wrote:

> 
> I am experiencing debilitating intermittent mouse problems & was about
...
> Symptoms:
> After a long time of flawless operation (ranging from nearly a week to
> as little as five minutes), the X11 pointer flies up to top-right corner,
  
> and mostly wants to stay there.  Moving the mouse causes a cascade of
> spurious button-press events get generated.

This is easily explained: some byte of the mouse protocol was lost.
(Some mouse protocols are even designed to allow
 easy resync/recovery by fixed bit patterns!)

Write an intelligent mouse driver for XFree86 to compensate for
lost bytes. 

Regards, Gunther

APPENDIX


Output ot litte test program:
> a.out
Simulating 1 lost byte
1 -- ff 00 08 ---   -256 : -248   Buttons=MRL Overflow/errors:XY 
2 -- 00 04 08 ---  4 :8   Buttons=Overflow/errors:  T
3 -- 00 04 08 ---  4 :8   Buttons=Overflow/errors:  T
4 -- 00 03 08 ---  3 :8   Buttons=Overflow/errors:  T
5 -- 00 03 18 ---  3 :   24   Buttons=Overflow/errors:  T
6 -- ff 02 08 ---   -254 : -248   Buttons=MRL Overflow/errors:XY 
7 -- 00 02 08 ---  2 :8   Buttons=Overflow/errors:  T
8 -- 00 03 18 ---  3 :   24   Buttons=Overflow/errors:  T
9 -- ff 03 18 ---   -253 : -232   Buttons=MRL Overflow/errors:XY 
   10 -- ff 03 08 ---   -253 : -248   Buttons=MRL Overflow/errors:XY 
...

Probably XFree ignores data packets with XY overflow set. All other
packets move you to top-right corner.

Moving your mouse will quickly show button mania, as described by your post.
 gm_psauxprint.c

Re: mouse problems in 2.4.2 - lost byte

[Gunther Mayer]

[EMAIL PROTECTED] wrote:

 
 I am experiencing debilitating intermittent mouse problems  was about
...
 Symptoms:
 After a long time of flawless operation (ranging from nearly a week to
 as little as five minutes), the X11 pointer flies up to top-right corner,
  
 and mostly wants to stay there.  Moving the mouse causes a cascade of
 spurious button-press events get generated.

This is easily explained: some byte of the mouse protocol was lost.
(Some mouse protocols are even designed to allow
 easy resync/recovery by fixed bit patterns!)

Write an intelligent mouse driver for XFree86 to compensate for
lost bytes. 

Regards, Gunther

APPENDIX


Output ot litte test program:
 a.out
Simulating 1 lost byte
1 -- ff 00 08 ---   -256 : -248   Buttons=MRL Overflow/errors:XY 
2 -- 00 04 08 ---  4 :8   Buttons=Overflow/errors:  T
3 -- 00 04 08 ---  4 :8   Buttons=Overflow/errors:  T
4 -- 00 03 08 ---  3 :8   Buttons=Overflow/errors:  T
5 -- 00 03 18 ---  3 :   24   Buttons=Overflow/errors:  T
6 -- ff 02 08 ---   -254 : -248   Buttons=MRL Overflow/errors:XY 
7 -- 00 02 08 ---  2 :8   Buttons=Overflow/errors:  T
8 -- 00 03 18 ---  3 :   24   Buttons=Overflow/errors:  T
9 -- ff 03 18 ---   -253 : -232   Buttons=MRL Overflow/errors:XY 
   10 -- ff 03 08 ---   -253 : -248   Buttons=MRL Overflow/errors:XY 
...

Probably XFree ignores data packets with XY overflow set. All other
packets move you to top-right corner.

Moving your mouse will quickly show button mania, as described by your post.
 gm_psauxprint.c

Re: mouse problems in 2.4.2 - lost byte

[Gunther Mayer]

James Simmons wrote:
 
 This is easily explained: some byte of the mouse protocol was lost.
 (Some mouse protocols are even designed to allow
 easy resync/recovery by fixed bit patterns!)
 
 Write an intelligent mouse driver for XFree86 to compensate for
 lost bytes.
 
 Or write a kernel input device driver. In fact I probable have a mouse
 driver for you. 

Where can I get your driver?


What kind of mouse do you have? Then set your X config to
 have the following:
 
 Section "Pointer"
 Protocol"ImPS/2"
 Device  "/dev/input/mice"

What is better in using /dev/input/mice than /dev/psaux
on this problem exactly?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch(2.4.2): serial.c timedia oneliner (Resend)

[Gunther Mayer]

Hi,
please apply this oneliner to fix the Timedia/Sunix series PCI cards.

Regards, Gunther


P.S.
I'm sending this since 3 months to the maintainer ([EMAIL PROTECTED])
and even submitted to serial.sourceforge.net but never got a reaction.
Anybody knows if Ted is still active?


--- linux/drivers/char/serial.c-242-origFri Mar 16 09:32:22 2001
+++ linux/drivers/char/serial.c Fri Mar 16 09:34:32 2001
@@ -4175,7 +4175,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
-   if (pci_get_subvendor(dev) == ids[j]) {
+   if (pci_get_subdevice(dev) == ids[j]) {
board->num_ports = timedia_data[i].num;
return 0;
}
 gmdiff-lx242-serialc-timedia-oneliner

Patch(2.4.2): isapnp detect fix (wrong checksum)

[Gunther Mayer]

Hi,
this fix lets linux detect cards which don't
have a correct checksum.

These are probably common, it seems isapnptools _silently_
fixes this up !

Please apply if you like, comments welcome.

Regards, Gunther

--- linux/drivers/pnp/isapnp.c-2.4.2-orig   Fri Mar 16 09:08:47 2001
+++ linux/drivers/pnp/isapnp.c  Fri Mar 16 09:21:45 2001
@@ -993,10 +993,15 @@
header[4], header[5], header[6], header[7], header[8]);
printk("checksum = 0x%x\n", checksum);
 #endif
-   if (checksum == 0x00 || checksum != header[8])  /* not valid CSN */
+   /* Don't be strict on the checksum, here !
+   e.g. 'SCM SwapBox Plug and Play' has header[8]==0 (should be: b7)*/
+   if (header[8] == 0)
+   ;
+   else if (checksum == 0x00 || checksum != header[8]) /* not valid 
+CSN */
continue;
if ((card = isapnp_alloc(sizeof(struct pci_bus))) == NULL)
continue;
+
card->number = csn;
card->vendor = (header[1] << 8) | header[0];
card->device = (header[3] << 8) | header[2];
 gmdiff-242-isapnp-checksum-swapbox

Patch(2.4.2): isapnp detect fix (wrong checksum)

[Gunther Mayer]

Hi,
this fix lets linux detect cards which don't
have a correct checksum.

These are probably common, it seems isapnptools _silently_
fixes this up !

Please apply if you like, comments welcome.

Regards, Gunther

--- linux/drivers/pnp/isapnp.c-2.4.2-orig   Fri Mar 16 09:08:47 2001
+++ linux/drivers/pnp/isapnp.c  Fri Mar 16 09:21:45 2001
@@ -993,10 +993,15 @@
header[4], header[5], header[6], header[7], header[8]);
printk("checksum = 0x%x\n", checksum);
 #endif
-   if (checksum == 0x00 || checksum != header[8])  /* not valid CSN */
+   /* Don't be strict on the checksum, here !
+   e.g. 'SCM SwapBox Plug and Play' has header[8]==0 (should be: b7)*/
+   if (header[8] == 0)
+   ;
+   else if (checksum == 0x00 || checksum != header[8]) /* not valid 
+CSN */
continue;
if ((card = isapnp_alloc(sizeof(struct pci_bus))) == NULL)
continue;
+
card-number = csn;
card-vendor = (header[1]  8) | header[0];
card-device = (header[3]  8) | header[2];
 gmdiff-242-isapnp-checksum-swapbox

Patch(2.4.2): serial.c timedia oneliner (Resend)

[Gunther Mayer]

Hi,
please apply this oneliner to fix the Timedia/Sunix series PCI cards.

Regards, Gunther


P.S.
I'm sending this since 3 months to the maintainer ([EMAIL PROTECTED])
and even submitted to serial.sourceforge.net but never got a reaction.
Anybody knows if Ted is still active?


--- linux/drivers/char/serial.c-242-origFri Mar 16 09:32:22 2001
+++ linux/drivers/char/serial.c Fri Mar 16 09:34:32 2001
@@ -4175,7 +4175,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
-   if (pci_get_subvendor(dev) == ids[j]) {
+   if (pci_get_subdevice(dev) == ids[j]) {
board-num_ports = timedia_data[i].num;
return 0;
}
 gmdiff-lx242-serialc-timedia-oneliner

Patch(2.4.2): Fix Timdia/Sunix serial PCI cards

[Gunther Mayer]

Hi,
this patch fixes subvendor vs. subdevice and
makes my serial PCI card happy again.

Linus, please apply if you like.

Regards, Gunther

--- linux/drivers/char/serial.c-241-origSat Feb  3 13:00:53 2001
+++ linux/drivers/char/serial.c Sat Feb  3 13:31:33 2001
@@ -3845,7 +3845,6 @@
offset = board->first_uart_offset;
 
/* Timedia/SUNIX uses a mixture of BARs and offsets */
-   /* Ugh, this is ugly as all hell --- TYT */
if(dev->vendor == PCI_VENDOR_ID_TIMEDIA )  /* 0x1409 */
switch(idx) {
case 0: base_idx=0;
@@ -4175,12 +4174,17 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
-   if (pci_get_subvendor(dev) == ids[j]) {
+   if (pci_get_subdevice(dev) == ids[j]) {
board->num_ports = timedia_data[i].num;
+   printk("serial: Timedia/Sunix/Exsys PCI with %d ports 
+(%x:%x)\n",
+   board->num_ports, pci_get_subvendor(dev),
+   pci_get_subdevice(dev));
return 0;
}
}
}
+   printk("serial: ignoring unknown Timedia/Sunix card (%x:%x)\n",
+   pci_get_subvendor(dev),pci_get_subdevice(dev));
return 0;
 }
 gmdiff-lx241-serial-timedia-fix

Patch(2.4.2): Fix Timdia/Sunix serial PCI cards

[Gunther Mayer]

Hi,
this patch fixes subvendor vs. subdevice and
makes my serial PCI card happy again.

Linus, please apply if you like.

Regards, Gunther

--- linux/drivers/char/serial.c-241-origSat Feb  3 13:00:53 2001
+++ linux/drivers/char/serial.c Sat Feb  3 13:31:33 2001
@@ -3845,7 +3845,6 @@
offset = board-first_uart_offset;
 
/* Timedia/SUNIX uses a mixture of BARs and offsets */
-   /* Ugh, this is ugly as all hell --- TYT */
if(dev-vendor == PCI_VENDOR_ID_TIMEDIA )  /* 0x1409 */
switch(idx) {
case 0: base_idx=0;
@@ -4175,12 +4174,17 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
-   if (pci_get_subvendor(dev) == ids[j]) {
+   if (pci_get_subdevice(dev) == ids[j]) {
board-num_ports = timedia_data[i].num;
+   printk("serial: Timedia/Sunix/Exsys PCI with %d ports 
+(%x:%x)\n",
+   board-num_ports, pci_get_subvendor(dev),
+   pci_get_subdevice(dev));
return 0;
}
}
}
+   printk("serial: ignoring unknown Timedia/Sunix card (%x:%x)\n",
+   pci_get_subvendor(dev),pci_get_subdevice(dev));
return 0;
 }
 gmdiff-lx241-serial-timedia-fix

Re: PCI serial card (VScom): BARs+Offset mix

[Gunther Mayer]

Hi Tim,

this mapping must be hardcoded like I did for Timedia serial:

serial.c: get_pci_port
e.g.
/* Timedia/SUNIX uses a mixture of BARs and offsets */
if(dev->vendor == PCI_VENDOR_ID_TIMEDIA )  /* 0x1409 */
switch(idx) {
case 0: base_idx=0;
break;
case 1: base_idx=0; offset=8;
break;
case 2: base_idx=1;
break;
case 3: base_idx=1; offset=8;
break;
case 4: /* BAR 2*/
case 5: /* BAR 3 */
case 6: /* BAR 4*/
case 7: base_idx=idx-2; /* BAR 5*/
}
--->/* VScom uses another mixture */
if(VScom)
  YOUR CODE HERE PLEASE
...

This maps:  idx -> (base_idx, offset),
where idx:  goes from 0 to number_of_serial_ports,
  base_idx: BAR,
  offset:   added to the BAR IO-address to find actual port.

BAR mapping is set by a flag, here you need "SPCI_FL_BASE_TABLE":
e.g.{   PCI_VENDOR_ID_TIMEDIA, PCI_DEVICE_ID_TIMEDIA_1889,
PCI_VENDOR_ID_TIMEDIA, PCI_ANY_ID,
SPCI_FL_BASE_TABLE, 1, 921600,
0, 0, pci_timedia_fn },
 Footnote: This entry is fixed up at detect time and num_ports set by pci_timedia_fn,
   Ted fixed my table to a nice collapsed data structure for subids.

Hope this helps,
Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Printing to off-line printer in 2.4.0-prerelease

[Gunther Mayer]

Jesse Pollard wrote:
> Originally, (wayback machine on) this was handled by a pull-up resistor
> in the parallel interface, on the "off-line" signal. ANY time the printer
> was powered off, set offline, or cable unplugged, the "off-line" signal
> was raised by the pull-up. No data lost.
> 
> Now the parallel interface is bidirectional, and can have multiple devices
> attached - this "fix" cannot be used. The interface is now more of a
> buss than a single attached interface, and signals from a missing device
> (powered off or disconnected) are floating. They may float high or low,
> and depending on the environment (and which end of the cable is unplugged)
> any thing in between.

Not true. Electrical characteristics for parallel port implementations/cards
differ wildly, nevertheless most implementations have:
- data lines: bidirectional (see datasheets)
- signal lines: see datasheets, never floating !

Floating signal lines are a silicon bug/bad engineering and have nothing
to do with bidirectional interfaces ! 

Nowadays most integrated chips have internal signal line pull-ups internally, e.g. 
W83877TF says:
-BUSY, ACK, PE, SLCT, ERR:
  TTL level input pin. This pin is pulled high internally.
-AFD, STB, INIT, SLIN
  Open-drain output pin with 12 mA sink capability. Pulled up internally.
-Data lines:
  TTL level bi-directional with 24 mA source-sink capability.

Of course I would expect add-in cards to exist, with not so sophisticated chipsets
and makers that have "forgotten" external pull-ups for economical reasons (2 cents :-)
We should NOT care for broken hardware !!! I haven't seen any of these yet, even.

On the other hand printer implmentations vary wildly, too.
LJ1100: leave signal lines alone if powered off (0x7f)
i.e. signal printer-not-ready ack-active out-of-paper
DJ500: signal printer-error and off-line when powered off (0x87) !!!
=> Linux would dump data on this printer, if switched off.

I think the current linux lp code tries to handle exotic/weird printers 
gracefully and leaves mainstream printers and users alone.
-
Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Printing to off-line printer in 2.4.0-prerelease

[Gunther Mayer]

Jesse Pollard wrote:
 Originally, (wayback machine on) this was handled by a pull-up resistor
 in the parallel interface, on the "off-line" signal. ANY time the printer
 was powered off, set offline, or cable unplugged, the "off-line" signal
 was raised by the pull-up. No data lost.
 
 Now the parallel interface is bidirectional, and can have multiple devices
 attached - this "fix" cannot be used. The interface is now more of a
 buss than a single attached interface, and signals from a missing device
 (powered off or disconnected) are floating. They may float high or low,
 and depending on the environment (and which end of the cable is unplugged)
 any thing in between.

Not true. Electrical characteristics for parallel port implementations/cards
differ wildly, nevertheless most implementations have:
- data lines: bidirectional (see datasheets)
- signal lines: see datasheets, never floating !

Floating signal lines are a silicon bug/bad engineering and have nothing
to do with bidirectional interfaces ! 

Nowadays most integrated chips have internal signal line pull-ups internally, e.g. 
W83877TF says:
-BUSY, ACK, PE, SLCT, ERR:
  TTL level input pin. This pin is pulled high internally.
-AFD, STB, INIT, SLIN
  Open-drain output pin with 12 mA sink capability. Pulled up internally.
-Data lines:
  TTL level bi-directional with 24 mA source-sink capability.

Of course I would expect add-in cards to exist, with not so sophisticated chipsets
and makers that have "forgotten" external pull-ups for economical reasons (2 cents :-)
We should NOT care for broken hardware !!! I haven't seen any of these yet, even.

On the other hand printer implmentations vary wildly, too.
LJ1100: leave signal lines alone if powered off (0x7f)
i.e. signal printer-not-ready ack-active out-of-paper
DJ500: signal printer-error and off-line when powered off (0x87) !!!
= Linux would dump data on this printer, if switched off.

I think the current linux lp code tries to handle exotic/weird printers 
gracefully and leaves mainstream printers and users alone.
-
Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PCI serial card (VScom): BARs+Offset mix

[Gunther Mayer]

Hi Tim,

this mapping must be hardcoded like I did for Timedia serial:

serial.c: get_pci_port
e.g.
/* Timedia/SUNIX uses a mixture of BARs and offsets */
if(dev-vendor == PCI_VENDOR_ID_TIMEDIA )  /* 0x1409 */
switch(idx) {
case 0: base_idx=0;
break;
case 1: base_idx=0; offset=8;
break;
case 2: base_idx=1;
break;
case 3: base_idx=1; offset=8;
break;
case 4: /* BAR 2*/
case 5: /* BAR 3 */
case 6: /* BAR 4*/
case 7: base_idx=idx-2; /* BAR 5*/
}
---/* VScom uses another mixture */
if(VScom)
  YOUR CODE HERE PLEASE
...

This maps:  idx - (base_idx, offset),
where idx:  goes from 0 to number_of_serial_ports,
  base_idx: BAR,
  offset:   added to the BAR IO-address to find actual port.

BAR mapping is set by a flag, here you need "SPCI_FL_BASE_TABLE":
e.g.{   PCI_VENDOR_ID_TIMEDIA, PCI_DEVICE_ID_TIMEDIA_1889,
PCI_VENDOR_ID_TIMEDIA, PCI_ANY_ID,
SPCI_FL_BASE_TABLE, 1, 921600,
0, 0, pci_timedia_fn },
 Footnote: This entry is fixed up at detect time and num_ports set by pci_timedia_fn,
   Ted fixed my table to a nice collapsed data structure for subids.

Hope this helps,
Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RESOLVED: lx240test12 hangs VAIO: P-III kernel hangs on P-II

[Gunther Mayer]

Hi,
compiling the kernel for P-II resolved my problem.

What would be necessary to print an error message
instead of just hanging?

-
Gunther

Gunther Mayer wrote:
> 
> Hi,
> Linux-2.4.0-test12 doesn't boot on VAIO PCG-N505SN,
> whereas linux-2.2.10 works fine (both booted by lilo-21).
> 
> It just hangs after printing:
> Uncompressing Linux... Ok, booting the kernel.
> HANG
> 
> Btw. Raw bzImage booted over USB-floppy just reboots...
> 
> Can this be infamous A20 again ?
> 
> Regards, Gunther
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Patch: test13-pre2 fails "make xconfig" in isdn/Config.in

[Gunther Mayer]

Hi Linus,
apply this patch if like to fix this obvious error
with "make xconfig" on plain tree:
./tkparse < ../arch/i386/config.in >> kconfig.tk
drivers/isdn/Config.in: 98: can't handle dep_bool/dep_mbool/dep_tristate 
condition
make[1]: *** [kconfig.tk] Error 1
make[1]: Leaving directory `/usr/src/linux/scripts'

-
Gunther




--- linux/drivers/isdn/Config.in-240t13pre2-origSat Dec 16 12:20:59 2000
+++ linux/drivers/isdn/Config.inSat Dec 16 12:21:48 2000
@@ -95,7 +95,7 @@
   dep_bool  'Eicon PCI DIVA Server BRI/PRI/4BRI support' 
CONFIG_ISDN_DRV_EICON_PCI $CONFIG_PCI
   bool  'Eicon S,SX,SCOM,Quadro,S2M support' CONFIG_ISDN_DRV_EICON_ISA
fi
-   dep_tristate '  Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS
+   bool '  Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS
 fi
 
 # CAPI subsystem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Patch: test13-pre2 fails make xconfig in isdn/Config.in

[Gunther Mayer]

Hi Linus,
apply this patch if like to fix this obvious error
with "make xconfig" on plain tree:
./tkparse  ../arch/i386/config.in  kconfig.tk
drivers/isdn/Config.in: 98: can't handle dep_bool/dep_mbool/dep_tristate 
condition
make[1]: *** [kconfig.tk] Error 1
make[1]: Leaving directory `/usr/src/linux/scripts'

-
Gunther




--- linux/drivers/isdn/Config.in-240t13pre2-origSat Dec 16 12:20:59 2000
+++ linux/drivers/isdn/Config.inSat Dec 16 12:21:48 2000
@@ -95,7 +95,7 @@
   dep_bool  'Eicon PCI DIVA Server BRI/PRI/4BRI support' 
CONFIG_ISDN_DRV_EICON_PCI $CONFIG_PCI
   bool  'Eicon S,SX,SCOM,Quadro,S2M support' CONFIG_ISDN_DRV_EICON_ISA
fi
-   dep_tristate '  Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS
+   bool '  Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS
 fi
 
 # CAPI subsystem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RESOLVED: lx240test12 hangs VAIO: P-III kernel hangs on P-II

[Gunther Mayer]

Hi,
compiling the kernel for P-II resolved my problem.

What would be necessary to print an error message
instead of just hanging?

-
Gunther

Gunther Mayer wrote:
 
 Hi,
 Linux-2.4.0-test12 doesn't boot on VAIO PCG-N505SN,
 whereas linux-2.2.10 works fine (both booted by lilo-21).
 
 It just hangs after printing:
 Uncompressing Linux... Ok, booting the kernel.
 HANG
 
 Btw. Raw bzImage booted over USB-floppy just reboots...
 
 Can this be infamous A20 again ?
 
 Regards, Gunther
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

lx240test12 hangs VAIO after "OK, booting the kernel"

[Gunther Mayer]

Hi,
Linux-2.4.0-test12 doesn't boot on VAIO PCG-N505SN,
whereas linux-2.2.10 works fine (both booted by lilo-21).

It just hangs after printing:
Uncompressing Linux... Ok, booting the kernel.
HANG

Btw. Raw bzImage booted over USB-floppy just reboots...

Can this be infamous A20 again ?

Regards, Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

lx240test12 hangs VAIO after OK, booting the kernel

[Gunther Mayer]

Hi,
Linux-2.4.0-test12 doesn't boot on VAIO PCG-N505SN,
whereas linux-2.2.10 works fine (both booted by lilo-21).

It just hangs after printing:
Uncompressing Linux... Ok, booting the kernel.
HANG

Btw. Raw bzImage booted over USB-floppy just reboots...

Can this be infamous A20 again ?

Regards, Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/