Fwd: ACPI & I4L irq confilct: bug reporting on kernel 2.4.0-test8-pre4
>Hi ! >This is a bug reporting, included are the output of various /proc file on >my system: >Motherboard: ASUS P2B-F with the latest bios bx2f113.awd (microcode update) >ISDN: Winbond based card (Hisax type=36) >Distribution: based on updated SuSE 6.4 >The problem is that if I compile the kernel (2.4.0-test8 pre1,pre2,pre3,pre4) >with both ACPI support and ISDN support there is a conflict in irq 9. >I think ACPI first get irq 9 and then Hisax can't get it. Consequentially >Hisax doesn't work if ACPI support is enabled. >With ACPI turned off, everything works fine as with previous kernel test6 >and test5 and >Many thanx. after further testing the problem seems to be in IRQ SHARING. in fact, with acpi disabled, once the hisax has got irq 9 (it is not possible for card type 36 to change the irq), i can load the ethernet modules 8390 and ne2k-pci for my ethernet PCI NE2000 card, but the ne2k-pci driver also set its irq=9, so everytime i try to do: ifconfig eth0 up i get: SIOCSIFFLAGS: resource temporarily unavailable why don't add the irq parameter to the hisax winbond driver and to the ne2k-pci driver ? p.s. my motherboard has pci slot 4 and slot 5 condivided and the isdn card is on slot 4 while ethernet on slot 5 so one may say "change your motherboard", but everything worked fine with previous kernels (ACPI, Hisax, ethernet) Please help me. Many thanx. Please answer only via email: [EMAIL PROTECTED] -- bye, Guido Trentalancia CPU0 0: 140258 XT-PIC timer 1: 4460 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 425229 XT-PIC es1371 9: 9840 XT-PIC HiSax 10: 16940 XT-PIC aic7xxx 12: 53956 XT-PIC PS/2 Mouse 13: 1 XT-PIC fpu NMI: 0 ERR: 0 Character devices: 1 mem 2 pty 3 ttyp 4 ttyS 5 cua 7 vcs 10 misc 14 sound 43 ttyI 44 cui 45 isdn 128 ptm 136 pts 162 raw Block devices: 8 sd 65 sd 66 sd -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 02f8-02ff : serial(auto) 03c0-03df : vga+ 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 b000-b01f : Realtek Semiconductor Co., Ltd. RTL-8029(AS) b000-b01f : ne2k-pci b400-b4ff : Adaptec AHA-2940U2/W b400-b4fe : aic7xxx b800-b83f : Ensoniq ES1371 [AudioPCI-97] b800-b83f : es1371 d000-d0ff : Dynalink IS64PH ISDN Adapter d000-d0ff : TA XXX d400-d41f : Intel Corporation 82371AB PIIX4 USB d800-d80f : Intel Corporation 82371AB PIIX4 IDE e400-e43f : Intel Corporation 82371AB PIIX4 ACPI e800-e81f : Intel Corporation 82371AB PIIX4 ACPI Linux version 2.4.0-test8 (root@kleopatra) (gcc version 2.95.2 19991024 (release)) #1 Wed Sep 6 13:11:45 CEST 2000 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.599904 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 1399.19 Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: DNES-309170W Rev: SA30 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: PLEXTOR Model: CD-ROM PX-32TS Rev: 1.02 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 02 Lun: 00 Vendor: YAMAHA Model: CRW8424S Rev: 1.0j Type: CD-ROM ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 03 Lun: 00 Vendor: Model: Scanner 636A4Rev: 1.10 Type: Scanner ANSI SCSI revision: 02
Re: Fwd: ACPI & I4L irq confilct: bug reporting on kernel 2.4.0-test8-pre4
On Wed, 06 Sep 2000, you wrote: > Guido Trentalancia schrieb: > > Hello Guido, > > > >Hi ! > > >This is a bug reporting, included are the output of various /proc file > > > on my system: > > >Motherboard: ASUS P2B-F with the latest bios bx2f113.awd (microcode > > > update) ISDN: Winbond based card (Hisax type=36) > > >Distribution: based on updated SuSE 6.4 > > > > > >The problem is that if I compile the kernel (2.4.0-test8 > > > pre1,pre2,pre3,pre4) with both ACPI support and ISDN support there is a > > > conflict in irq 9. I think ACPI first get irq 9 and then Hisax can't > > > get it. Consequentially Hisax doesn't work if ACPI support is enabled. > > >With ACPI turned off, everything works fine as with previous kernel > > > test6 and test5 and > > >Many thanx. > > > > after further testing the problem seems to be in IRQ SHARING. > > in fact, with acpi disabled, once the hisax has got irq 9 (it is not > > possible for card type 36 to change the irq), i can load the ethernet > > modules 8390 and ne2k-pci for my ethernet PCI NE2000 card, but the > > ne2k-pci driver also set its irq=9, so everytime i try to do: > > > > ifconfig eth0 up > > > > i get: > > > > SIOCSIFFLAGS: resource temporarily unavailable > > > > why don't add the irq parameter to the hisax winbond driver and to the > > ne2k-pci driver ? > > there is no need or even sense to add such parameter, as irqs are > assigned by the bios or OS for PCI type cards. The driver is supplied > with the selected irq which is normally assigned during boot by the > systems bios. > You should change the bios PCI/Pnp setup to reflect your needs. > I don't know if the Winbond driver supports IRQ-sharing, but other i4l > drivers like the HFC-PCI which I maintain allow irq sharing without any > problems even if 3 cards share it. > So please setup your bios correctly and everything will work fine. > > > p.s. > > my motherboard has pci slot 4 and slot 5 condivided and the isdn card is > > on slot 4 while ethernet on slot 5 so one may say "change your > > motherboard", but everything worked fine with previous kernels (ACPI, > > Hisax, ethernet) > > > > Please help me. > > Many thanx. > > Please answer only via email: [EMAIL PROTECTED] > > -- > > bye, > > Guido Trentalancia > > Werner my bios irq settings are currently set to AUTO. i don't know why 3 resources (ne2k-pci, the winbond isdn module and the acpi) want the same irq 9 whereas there are a lot of free irqs... the manteiner of the ACPI driver sayd his driver is ok for irq sharing what about ne2k and winbond isdn ? i don't know how to contact the manteiners of this drivers Summarizing the problem My system load modules in this order: 1) ACPI 2) ISDN (Windbond - HiSax) 3) RealTek PCI NE2000 ethernet -If I compile the kernel with ACPI on, step 2 fails -If I compile the kernel with ACPI off step 2 is ok (hisax modules loaded on irq 9) but ne2k-pci conflicts is also assigned to irq 9, correctly loaded but with the SIOCFIFFLAGS error and unusable with ifconfig. My bios only allow me to change irq setting from AUTO to irq X (on slot 4 (isdn) and 5 (eth0) simultaneously). I tried to set it from AUTO to 12 but it didn't resolve the conflict... The most strange thing is that with previous 2.4.0 test kernels everything worked fine Many thanx. -- bye, Guido Trentalancia - 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: Fwd: ACPI & I4L irq confilct: bug reporting on kernel 2.4.0-test8-pre4
On Wed, 06 Sep 2000, you wrote: > On Wed, 6 Sep 2000, Guido Trentalancia wrote: > > On Wed, 06 Sep 2000, you wrote: > > > Guido Trentalancia schrieb: > > > > >Motherboard: ASUS P2B-F with the latest bios bx2f113.awd (microcode > > > > > update) ISDN: Winbond based card (Hisax type=36) > > > > >The problem is that if I compile the kernel (2.4.0-test8 > > > > > pre1,pre2,pre3,pre4) with both ACPI support and ISDN support there > > > > > is a conflict in irq 9. I think ACPI first get irq 9 and then Hisax > > > > > can't get it. Consequentially Hisax doesn't work if ACPI support is > > > > > enabled. With ACPI turned off, everything works fine as with > > > > > previous kernel test6 and test5 and > > > > > > > > after further testing the problem seems to be in IRQ SHARING. > > > > in fact, with acpi disabled, once the hisax has got irq 9 (it is not > > > > possible for card type 36 to change the irq), i can load the ethernet > > > > modules 8390 and ne2k-pci for my ethernet PCI NE2000 card, but the > > > > ne2k-pci driver also set its irq=9, so everytime i try to do: > > > > > > > > ifconfig eth0 up > > > > SIOCSIFFLAGS: resource temporarily unavailable > > > > > > > > why don't add the irq parameter to the hisax winbond driver and to > > > > the ne2k-pci driver ? > > > > > > there is no need or even sense to add such parameter, as irqs are > > > assigned by the bios or OS for PCI type cards. The driver is supplied > > > with the selected irq which is normally assigned during boot by the > > > systems bios. > > > > my bios irq settings are currently set to AUTO. > > i don't know why 3 resources (ne2k-pci, the winbond isdn module and the > > acpi) want the same irq 9 whereas there are a lot of free irqs... > > the manteiner of the ACPI driver sayd his driver is ok for irq > > sharing what about ne2k and winbond isdn ? i don't know how to > > contact the manteiners of this drivers > > The ne2k-pci driver will share IRQs. > The 'ne' driver will work for PCI cards, but is intended for ISA cards. It > will not share the IRQ. > > Documentation for the ne2k-pci driver is at >http://www.scyld.com/network/ne2k-pci.html > > > 1) ACPI > > 2) ISDN (Windbond - HiSax) > > 3) RealTek PCI NE2000 ethernet > > Is the ISDN card a PCI device? If not, it cannot share IRQs. yes it is > If it is a PCI device, the driver is broken. in fact this is the most probrably hypothesis of my problems this reply has been also forwarded to the author of the winbond driver (a guy from the czech republic) and to cornelius (many thanx for your comments). to confirm this hypotesis i can just compile the kernel with both acpi and ethernet but without the isdn driver. if irq sharing is ok then the problem must be in the file drivers/isdn/w6692.[ch] thanx a lot to everybody supporting linux and in particular to those who are helping me in this tedious problem. > > Donald Becker [EMAIL PROTECTED] > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Beowulf-II Cluster Distribution > Annapolis MD 21403 -- bye, Guido Trentalancia please reply via email: [EMAIL PROTECTED] - 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: Fwd: ACPI & I4L irq confilct: bug reporting on kernel 2.4.0-test8-pre4
On Wed, 06 Sep 2000, you wrote: > Guido Trentalancia schrieb: > > Hello Guido, > > > >Hi ! > > >This is a bug reporting, included are the output of various /proc file > > > on my system: > > >Motherboard: ASUS P2B-F with the latest bios bx2f113.awd (microcode > > > update) ISDN: Winbond based card (Hisax type=36) > > >Distribution: based on updated SuSE 6.4 > > > > > >The problem is that if I compile the kernel (2.4.0-test8 > > > pre1,pre2,pre3,pre4) with both ACPI support and ISDN support there is a > > > conflict in irq 9. I think ACPI first get irq 9 and then Hisax can't > > > get it. Consequentially Hisax doesn't work if ACPI support is enabled. > > >With ACPI turned off, everything works fine as with previous kernel > > > test6 and test5 and > > >Many thanx. > > > > after further testing the problem seems to be in IRQ SHARING. > > in fact, with acpi disabled, once the hisax has got irq 9 (it is not > > possible for card type 36 to change the irq), i can load the ethernet > > modules 8390 and ne2k-pci for my ethernet PCI NE2000 card, but the > > ne2k-pci driver also set its irq=9, so everytime i try to do: > > > > ifconfig eth0 up > > > > i get: > > > > SIOCSIFFLAGS: resource temporarily unavailable > > > > why don't add the irq parameter to the hisax winbond driver and to the > > ne2k-pci driver ? > > there is no need or even sense to add such parameter, as irqs are > assigned by the bios or OS for PCI type cards. The driver is supplied > with the selected irq which is normally assigned during boot by the > systems bios. > You should change the bios PCI/Pnp setup to reflect your needs. > I don't know if the Winbond driver supports IRQ-sharing, but other i4l > drivers like the HFC-PCI which I maintain allow irq sharing without any > problems even if 3 cards share it. > So please setup your bios correctly and everything will work fine. > > > p.s. > > my motherboard has pci slot 4 and slot 5 condivided and the isdn card is > > on slot 4 while ethernet on slot 5 so one may say "change your > > motherboard", but everything worked fine with previous kernels (ACPI, > > Hisax, ethernet) > > > > Please help me. > > Many thanx. > > Please answer only via email: [EMAIL PROTECTED] > > -- > > bye, > > Guido Trentalancia > > Werner the problems seems to be in the winbond driver (driver/isdn/hisax/w6692.[ch]) i tried to contact the author but the email address doen't exists anymore ([EMAIL PROTECTED]) could you help me ? ACPI and NE2000 seems to be ok... many thanx. -- -- bye, Guido Trentalancia please reply via email p.s. use gnupg ! ftp://ftp.gnupg.org use gnupg !...
l'unione europea ha le palle quadrate !!!
w la Sun ! vittoria alle persone giuste ed oneste ! l'oligopolio รจ finito http://www.cnnitalia.it/2000/ECONOMIA/08/03/microsoft_ue/index.html#1 -- Peace & Love, Guido Trentalancia - 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/
i'm sorry
I'm sorry 4 posting the article in italian and abusing of the kernel mailng list. Good work! -- Have a nice day, Guido Trentalancia - 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] scsi: ignore Synchronize Cache command failures to keep using drives not supporting it
Many obsolete hard drives do not support the Synchronize Cache SCSI
command. Such command is generally issued during fsync() calls which
at the moment therefore fail with the ILLEGAL_REQUEST sense key.
Since this failure is currently treated as critical in the kernel SCSI
disk driver, such obsolete hard drives cannot be used anymore (at least
since kernel 4.10, maybe even earlier): they cannot be formatted,
mounted and/or checked using tools such as e2fsprogs.
Because there is nothing which can be done if the drive does not support
such command, such ILLEGAL_REQUEST should be treated as non-critical so
that the underlying operation does not fail and the obsolete hard drive
can be used normally.
Of course, using such hard drives which do not feature the Synchronize
Cache SCSI command implies a very high risk (or maybe even certainty) of
data loss in case of power cuts, USB cable disconnects and so on -
SO YOU HAVE BEEN WARNED - IN DOUBT, UPGRADE TO A NEWER HARD DRIVE !!!
Signed-off-by: Guido Trentalancia
---
drivers/scsi/sd.c | 17 +
1 file changed, 17 insertions(+)
--- linux-5.0.2-orig/drivers/scsi/sd.c 2019-03-17 18:22:04.822720851 +0100
+++ linux-5.0.2/drivers/scsi/sd.c 2019-03-17 18:47:06.405881720 +0100
@@ -1633,6 +1633,16 @@ static int sd_sync_cache(struct scsi_dis
}
if (res) {
+ /*
+* sshdr.sense_key == ILLEGAL_REQUEST means this drive
+* doesn't support sync. There's not much to do and
+* sync shouldn't fail.
+*/
+ if (sshdr->sense_key == ILLEGAL_REQUEST && sshdr->asc == 0x20) {
+ sd_printk(KERN_NOTICE, sdkp, "Drive does not support
Synchronize Cache(10) command: ignoring.\n");
+ return 0;
+ }
+
sd_print_result(sdkp, "Synchronize Cache(10) failed", res);
if (driver_byte(res) == DRIVER_SENSE)
@@ -2022,6 +2032,13 @@ static int sd_done(struct scsi_cmnd *SCp
req->rq_flags |= RQF_QUIET;
}
break;
+ case SYNCHRONIZE_CACHE:
+ if (sshdr.asc == 0x20) {
+ sd_printk(KERN_NOTICE, sdkp, "Drive
does not support Synchronize Cache(10) command: ignoring.\n");
+ SCpnt->result = 0;
+ good_bytes = scsi_bufflen(SCpnt);
+ }
+ break;
}
}
break;
[PATCH v2] scsi: ignore Synchronize Cache command failures to keep using drives not supporting it
Many obsolete hard drives do not support the Synchronize Cache SCSI
command. Such command is generally issued during fsync() calls which
at the moment therefore fail with the ILLEGAL_REQUEST sense key.
Since this failure is currently treated as critical in the kernel SCSI
disk driver, such obsolete hard drives cannot be used anymore (at least
since kernel 4.10, maybe even earlier): they cannot be formatted,
mounted and/or checked using tools such as e2fsprogs.
Because there is nothing which can be done if the drive does not support
such command, such ILLEGAL_REQUEST should be treated as non-critical so
that the underlying operation does not fail and the obsolete hard drive
can be used normally.
This second version of the patch (v2) disables the Write Cache feature
as a precaution on hard drives which do not support the Synchronize Cache
command and therefore the cache flushing functionality.
Although the Write Cache is disabled (v2) when using such hard drives
which do not feature the Synchronize Cache SCSI command there is still
some risk of data loss in case of power cuts, USB cable disconnects and
so on: YOU HAVE BEEN WARNED - THE DRIVE MANIFACTURER SHOULD HAVE BEEN
WARNED YOU IN THE FIRST PLACE - IN DOUBT, UPGRADE TO A NEWER HARD DRIVE !!
Signed-off-by: Guido Trentalancia
---
drivers/scsi/sd.c | 29 +
1 file changed, 29 insertions(+)
diff -pru linux-5.0.2-orig/drivers/scsi/sd.c linux-5.0.2/drivers/scsi/sd.c
--- linux-5.0.2-orig/drivers/scsi/sd.c 2019-03-17 18:22:04.822720851 +0100
+++ linux-5.0.2/drivers/scsi/sd.c 2019-03-20 17:41:44.526957307 +0100
@@ -22,6 +22,10 @@
* - Badari Pulavarty , Matthew Wilcox
*, Kurt Garloff :
*Support 32k/1M disks.
+ * - Guido Trentalancia ignore Synchronize
+ *Cache command failures on hard-drives that do not support it
+ *and disable the Write Cache functionality on such devices as a
+ *precaution: this allows to keep using several obsolete drives.
*
* Logging policy (needs CONFIG_SCSI_LOGGING defined):
* - setting up transfer: SCSI_LOG_HLQUEUE levels 1 and 2
@@ -1633,6 +1637,20 @@ static int sd_sync_cache(struct scsi_dis
}
if (res) {
+ /*
+* sshdr.sense_key == ILLEGAL_REQUEST means this drive
+* doesn't support sync. There's not much to do and
+* sync shouldn't fail.
+*/
+ if (sshdr->sense_key == ILLEGAL_REQUEST && sshdr->asc == 0x20) {
+ if (sdkp->WCE) {
+ sdkp->WCE = 0;
+ sd_printk(KERN_NOTICE, sdkp, "Drive does not
support Synchronize Cache(10) command: disabling write cache.\n");
+ sd_set_flush_flag(sdkp);
+ }
+ return 0;
+ }
+
sd_print_result(sdkp, "Synchronize Cache(10) failed", res);
if (driver_byte(res) == DRIVER_SENSE)
@@ -2022,6 +2040,17 @@ static int sd_done(struct scsi_cmnd *SCp
req->rq_flags |= RQF_QUIET;
}
break;
+ case SYNCHRONIZE_CACHE:
+ if (sshdr.asc == 0x20) {
+ if (sdkp->WCE) {
+ sdkp->WCE = 0;
+ sd_printk(KERN_NOTICE, sdkp,
"Drive does not support Synchronize Cache(10) command: disabling write
cache.\n");
+ sd_set_flush_flag(sdkp);
+ }
+ SCpnt->result = 0;
+ good_bytes = scsi_bufflen(SCpnt);
+ }
+ break;
}
}
break;
