Re: Initio 9100 Driver for Linux
On Fri, 6 Jul 2001 07:56:39, [EMAIL PROTECTED] wrote: > What I don't get about your patch is the following: Two things: 1) I must not try to type in patches while watching my phone bill to BT click up the pennies! 2) I must check the source I'm diffing against to make sure that Alan hasn't fixed the bug in the AC series already! ;-) -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: Initio 9100 Driver for Linux
On Fri, 6 Jul 2001 07:56:39, [EMAIL PROTECTED] wrote: What I don't get about your patch is the following: Two things: 1) I must not try to type in patches while watching my phone bill to BT click up the pennies! 2) I must check the source I'm diffing against to make sure that Alan hasn't fixed the bug in the AC series already! ;-) -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
On Thu, 5 Jul 2001 03:06:11, Erik Mouw <[EMAIL PROTECTED]> wrote: > Hmm, Cardbus and USB problems... you probably have both Cardbus and > i82365 support in your kernel configuration. Once I have the BIOS set to "cardbus/16 bit" instead of "auto-detect" I don't have a problem with having both Cardbus and i82365 support compiled in. If the BIOS is set to auto then the PCI tables don't have an IRQ specified and yenta.c uses IRQ 0! -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: Initio 9100 Driver for Linux
On Thu, 5 Jul 2001 11:32:12, [EMAIL PROTECTED] wrote:
> > I have a problem with the driver for Initio SCSI Controller 9100 SCSI,
> > a dual channel UW SCSI-Controller. On checking the SCSI bus the systems
> > has problems to initialize the CD-RW Sanyo (aka Brainwave) BP4-N SCSI
> > The CD-RW has SCSI-ID 6 on the second Controller. It is shown on
> > system startup an GENERIC CRD-BP4
> >
> > I had this problem both with Kernel 2.2.17 and 2.2.19.
>
> Check your termination. The initio drivers are very sensitive to
> termination errors (use active if possible), and make sure you follow all
> the normal rules regarding scsi.
>
> Most problems I've seen are caused by lousy termination, or using three
> way busses. I've also seen some problems with some cd writers (Yamaha to
> be exact), that I haven't been able to solve yet.
There's a bug in i91uscsi.c, init_tulip where it cycles through the onboard NVRAM
config. On the controller there's a single byte per device but it cycles through the
NVRAM in words. Since x86 words are two bytes a piece this means that the
code uses the NVRAM config for the device on twice the SCSI id - the only one
that's right is the one on id 0.
The patch below has been working here since January - though I've just extracted
this one fix from a much larger modification that I've done to the driver - proc fs
support, merging of i91uscsi.h and ini9100u.h since they contain many of the
same definitions but the two definitions are different which looks extremely
dangerous to me! i91uscsi.h is no more here.
I may have missed something with this one fix.
--- drivers/scsi/i91uscsi.cold Thu Jul 5 20:50:04 2001
+++ drivers/scsi/i91uscsi.c Thu Jul 5 20:55:03 2001
@@ -590,8 +590,8 @@
int init_tulip(HCS * pCurHcb, SCB * scbp, int tul_num_scb, BYTE * pbBiosAdr, int
seconds)
{
int i;
- BYTE *pwFlags;
BYTE *pbHeads;
+ UCHAR *pTarg;
SCB *pTmpScb, *pPrevScb = NULL;
pCurHcb->HCS_NumScbs = tul_num_scb;
@@ -673,12 +673,12 @@
TUL_WR(pCurHcb->HCS_Base + TUL_GCTRL1,
((pCurHcb->HCS_Config & HCC_AUTO_TERM) >> 4) |
(TUL_RD(pCurHcb->HCS_Base, TUL_GCTRL1) & 0xFE));
+ pTarg = >NVMSCSIInfo[0].MVM_Targ0Config;
for (i = 0,
-pwFlags = & (i91unvramp->NVM_SCSIInfo[0].NVM_Targ0Config),
pbHeads = pbBiosAdr + 0x180;
i < pCurHcb->HCS_MaxTar;
-i++, pwFlags++) {
- pCurHcb->HCS_Tcs[i].TCS_Flags = *pwFlags & ~(TCF_SYNC_DONE |
TCF_WDTR_DONE);
+i++) {
+ pCurHcb->HCS_Tcs[i].TCS_Flags = *(pTarg+i);
if (pCurHcb->HCS_Tcs[i].TCS_Flags & TCF_EN_255)
pCurHcb->HCS_Tcs[i].TCS_DrvFlags = TCF_DRV_255_63;
else
Trevor Hemsley, Brighton, UK.
[EMAIL PROTECTED]
-
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: Initio 9100 Driver for Linux
On Thu, 5 Jul 2001 11:32:12, [EMAIL PROTECTED] wrote:
I have a problem with the driver for Initio SCSI Controller 9100 SCSI,
a dual channel UW SCSI-Controller. On checking the SCSI bus the systems
has problems to initialize the CD-RW Sanyo (aka Brainwave) BP4-N SCSI
The CD-RW has SCSI-ID 6 on the second Controller. It is shown on
system startup an GENERIC CRD-BP4
I had this problem both with Kernel 2.2.17 and 2.2.19.
Check your termination. The initio drivers are very sensitive to
termination errors (use active if possible), and make sure you follow all
the normal rules regarding scsi.
Most problems I've seen are caused by lousy termination, or using three
way busses. I've also seen some problems with some cd writers (Yamaha to
be exact), that I haven't been able to solve yet.
There's a bug in i91uscsi.c, init_tulip where it cycles through the onboard NVRAM
config. On the controller there's a single byte per device but it cycles through the
NVRAM in words. Since x86 words are two bytes a piece this means that the
code uses the NVRAM config for the device on twice the SCSI id - the only one
that's right is the one on id 0.
The patch below has been working here since January - though I've just extracted
this one fix from a much larger modification that I've done to the driver - proc fs
support, merging of i91uscsi.h and ini9100u.h since they contain many of the
same definitions but the two definitions are different which looks extremely
dangerous to me! i91uscsi.h is no more here.
I may have missed something with this one fix.
--- drivers/scsi/i91uscsi.cold Thu Jul 5 20:50:04 2001
+++ drivers/scsi/i91uscsi.c Thu Jul 5 20:55:03 2001
@@ -590,8 +590,8 @@
int init_tulip(HCS * pCurHcb, SCB * scbp, int tul_num_scb, BYTE * pbBiosAdr, int
seconds)
{
int i;
- BYTE *pwFlags;
BYTE *pbHeads;
+ UCHAR *pTarg;
SCB *pTmpScb, *pPrevScb = NULL;
pCurHcb-HCS_NumScbs = tul_num_scb;
@@ -673,12 +673,12 @@
TUL_WR(pCurHcb-HCS_Base + TUL_GCTRL1,
((pCurHcb-HCS_Config HCC_AUTO_TERM) 4) |
(TUL_RD(pCurHcb-HCS_Base, TUL_GCTRL1) 0xFE));
+ pTarg = i91unvramp-NVMSCSIInfo[0].MVM_Targ0Config;
for (i = 0,
-pwFlags = (i91unvramp-NVM_SCSIInfo[0].NVM_Targ0Config),
pbHeads = pbBiosAdr + 0x180;
i pCurHcb-HCS_MaxTar;
-i++, pwFlags++) {
- pCurHcb-HCS_Tcs[i].TCS_Flags = *pwFlags ~(TCF_SYNC_DONE |
TCF_WDTR_DONE);
+i++) {
+ pCurHcb-HCS_Tcs[i].TCS_Flags = *(pTarg+i);
if (pCurHcb-HCS_Tcs[i].TCS_Flags TCF_EN_255)
pCurHcb-HCS_Tcs[i].TCS_DrvFlags = TCF_DRV_255_63;
else
Trevor Hemsley, Brighton, UK.
[EMAIL PROTECTED]
-
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: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
On Thu, 5 Jul 2001 03:06:11, Erik Mouw [EMAIL PROTECTED] wrote: Hmm, Cardbus and USB problems... you probably have both Cardbus and i82365 support in your kernel configuration. Once I have the BIOS set to cardbus/16 bit instead of auto-detect I don't have a problem with having both Cardbus and i82365 support compiled in. If the BIOS is set to auto then the PCI tables don't have an IRQ specified and yenta.c uses IRQ 0! -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
On Tue, 3 Jul 2001 00:30:10, "Trevor Hemsley" <[EMAIL PROTECTED]> wrote: > Somewhere between 2.4.2 and 2.4.5-ac13, PCMCIA card insertion and > removal appears to have broken on my Toshiba Libretto. On 2.4.2 all was > fine. On both 2.4.5-ac13 and ac22 it's broken. The whole machine freezes > solid, no SAK-s, SAK-u, SAK-b, no Ctrl-Alt-Fn to switch VC's. No messages > are issued. Problem occurs when inserting/removing any of YE-Data PCMCIA > floppy, TDK Smartmedia adapter (ide_cs), or 3c589 ethernet card. [large snip] OK, I've done quite a lot more work on this. It isn't 2.4.5, I'd compiled USB support in when I went to 2.4.5 and it's that that causes the problems. I backed out all changes made between 2.4.2 and 2.4.5 in drivers/pcmcia and that made no difference to the lockup so then I went back to the .config file from 2.4.2 and that worked. My best guess is that the USB support is using IRQ 11 and that the PCMCIA card sockets are wired to use that as well. I have a bypass for now - if I set the Toshiba BIOS up to use the slots in PCIC mode then it assigns them IRQ 15. In cardbus mode they get assigned IRQ 11 in Win9x but dmesg reports Linux Kernel Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: No IRQ known for interrupt pin A of device 00:06.0. Please try using pci=biosirq. PCI: No IRQ known for interrupt pin B of device 00:06.1. Please try using pci=biosirq. and Yenta IRQ list 0eb8, PCI irq0 Socket status: 3007 Yenta IRQ list 0eb8, PCI irq0 Socket status: 3007 Using pci=biosirq makes no difference when in cardbus mode. Ah, got it, flipping the PCMCIA setup in the BIOS from "Auto-detect" to "Cardbus/16 bit" fixes it. lspci -vv now lists the cardbus ports as having IRQ 11 assigned (instead of 0 before). Everything (famous last words) appears to be working. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
On Tue, 3 Jul 2001 00:30:10, Trevor Hemsley [EMAIL PROTECTED] wrote: Somewhere between 2.4.2 and 2.4.5-ac13, PCMCIA card insertion and removal appears to have broken on my Toshiba Libretto. On 2.4.2 all was fine. On both 2.4.5-ac13 and ac22 it's broken. The whole machine freezes solid, no SAK-s, SAK-u, SAK-b, no Ctrl-Alt-Fn to switch VC's. No messages are issued. Problem occurs when inserting/removing any of YE-Data PCMCIA floppy, TDK Smartmedia adapter (ide_cs), or 3c589 ethernet card. [large snip] OK, I've done quite a lot more work on this. It isn't 2.4.5, I'd compiled USB support in when I went to 2.4.5 and it's that that causes the problems. I backed out all changes made between 2.4.2 and 2.4.5 in drivers/pcmcia and that made no difference to the lockup so then I went back to the .config file from 2.4.2 and that worked. My best guess is that the USB support is using IRQ 11 and that the PCMCIA card sockets are wired to use that as well. I have a bypass for now - if I set the Toshiba BIOS up to use the slots in PCIC mode then it assigns them IRQ 15. In cardbus mode they get assigned IRQ 11 in Win9x but dmesg reports Linux Kernel Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: No IRQ known for interrupt pin A of device 00:06.0. Please try using pci=biosirq. PCI: No IRQ known for interrupt pin B of device 00:06.1. Please try using pci=biosirq. and Yenta IRQ list 0eb8, PCI irq0 Socket status: 3007 Yenta IRQ list 0eb8, PCI irq0 Socket status: 3007 Using pci=biosirq makes no difference when in cardbus mode. Ah, got it, flipping the PCMCIA setup in the BIOS from Auto-detect to Cardbus/16 bit fixes it. lspci -vv now lists the cardbus ports as having IRQ 11 assigned (instead of 0 before). Everything (famous last words) appears to be working. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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/
pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_HOTPLUG=y CONFIG_PCMCIA=y CONFIG_CARDBUS=y CONFIG_I82365=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_PM=y CONFIG_APM=y CONFIG_APM_DISPLAY_BLANK=y CONFIG_APM_RTC_IS_GMT=y CONFIG_APM_ALLOW_INTS=y CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_FD_PCMCIA=y CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_SYN_COOKIES=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_IDE_MODES=y CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_INPUT=m CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_SCREEN_X=800 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=480 CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_I2C=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ELV=m CONFIG_I2C_VELLEMAN=m CONFIG_I2C_ALGOPCF=m CONFIG_I2C_ELEKTOR=m CONFIG_I2C_CHARDEV=m CONFIG_MOUSE=y CONFIG_PSMOUSE=y CONFIG_PCMCIA_SERIAL_CS=m CONFIG_AUTOFS4_FS=y CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_TMPFS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_MINIX_FS=m CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_UTF8=m CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_SOUND=m CONFIG_SOUND_OSS=m CONFIG_SOUND_TRACEINIT=y CONFIG_SOUND_YM3812=m CONFIG_SOUND_OPL3SA2=m CONFIG_USB=m CONFIG_USB_DEVICEFS=y CONFIG_USB_OHCI=m CONFIG_USB_HID=m CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y No need to cc me as I read the newsgroup archive of linux-kernel and should get replies there, thanks. Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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/
pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_HOTPLUG=y CONFIG_PCMCIA=y CONFIG_CARDBUS=y CONFIG_I82365=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_PM=y CONFIG_APM=y CONFIG_APM_DISPLAY_BLANK=y CONFIG_APM_RTC_IS_GMT=y CONFIG_APM_ALLOW_INTS=y CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_FD_PCMCIA=y CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_SYN_COOKIES=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_IDE_MODES=y CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_INPUT=m CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_SCREEN_X=800 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=480 CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_I2C=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ELV=m CONFIG_I2C_VELLEMAN=m CONFIG_I2C_ALGOPCF=m CONFIG_I2C_ELEKTOR=m CONFIG_I2C_CHARDEV=m CONFIG_MOUSE=y CONFIG_PSMOUSE=y CONFIG_PCMCIA_SERIAL_CS=m CONFIG_AUTOFS4_FS=y CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_TMPFS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_MINIX_FS=m CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT=iso8859-1 CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_UTF8=m CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_SOUND=m CONFIG_SOUND_OSS=m CONFIG_SOUND_TRACEINIT=y CONFIG_SOUND_YM3812=m CONFIG_SOUND_OPL3SA2=m CONFIG_USB=m CONFIG_USB_DEVICEFS=y CONFIG_USB_OHCI=m CONFIG_USB_HID=m CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y No need to cc me as I read the newsgroup archive of linux-kernel and should get replies there, thanks. Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: aic7xxx oops with 2.4.5-ac13
On Thu, 21 Jun 2001 03:05:02, "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: > Ditto. I am also seeing this oops calling the sg driver for a > robotic tape library, and it also seems to happen on 2.4.4. In my case it appears that it was the symptom of severe bus problems. About 5 minutes after I posted the initial report I discovered that the cable from the back of the Nikon to the MO drive had fallen off so the bus was running unterminated. Replugging it fixed teh bus error and the oops. Looks like error handling is all fscked up... -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: aic7xxx oops with 2.4.5-ac13
On Thu, 21 Jun 2001 03:05:02, Jeff V. Merkey [EMAIL PROTECTED] wrote: Ditto. I am also seeing this oops calling the sg driver for a robotic tape library, and it also seems to happen on 2.4.4. In my case it appears that it was the symptom of severe bus problems. About 5 minutes after I posted the initial report I discovered that the cable from the back of the Nikon to the MO drive had fallen off so the bus was running unterminated. Replugging it fixed teh bus error and the oops. Looks like error handling is all fscked up... -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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/
aic7xxx oops with 2.4.5-ac13
3e4fd <[aic7xxx]ahc_reset+3a5/470> Trace; d913e539 <[aic7xxx]ahc_reset+3e1/470> Trace; c0115b98 Trace; c011 Trace; d9136b89 <[aic7xxx]ahc_pci_map_registers+1c5/254> Trace; e6948262 Trace; c019c9a2 Trace; c011c635 Trace; d9132ad4 <[serial].bss.end+1351/18dd> Trace; c0108301 Trace; c01084e6 Trace; c0105160 Trace; c0105160 Trace; c010a82e Trace; c0105160 Trace; c0105160 Trace; c0100018 Trace; c010518d Trace; c01051f2 Trace; c0105000 Trace; c01001cf Code; c018d250 <_EIP>: Code; c018d250<= 0: 8b 40 04 mov0x4(%eax),%eax <= Code; c018d253 3: 85 c0 test %eax,%eax Code; c018d255 5: 74 15 je 1c <_EIP+0x1c> c018d26c Code; c018d257 7: 3b 90 6c 00 00 00 cmp0x6c(%eax),%edx Code; c018d25d d: 75 07 jne16 <_EIP+0x16> c018d266 Code; c018d25f f: 80 88 fc 00 00 00 00 orb$0x0,0xfc(%eax) <0> Kernel panic: Aiee, killing interrupt handler! 1070 warnings issued. Results may not be reliable. Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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/
aic7xxx oops with 2.4.5-ac13
Trace; d91356ee [aic7xxx]ahc_filter_command+20a/2a4 Trace; d913e18f [aic7xxx]ahc_reset+37/470 Trace; d913e4fd [aic7xxx]ahc_reset+3a5/470 Trace; d913e539 [aic7xxx]ahc_reset+3e1/470 Trace; c0115b98 release_console_sem+94/98 Trace; c011 mtrr_close+34/c8 Trace; d9136b89 [aic7xxx]ahc_pci_map_registers+1c5/254 Trace; e6948262 END_OF_CODE+d78b186/ Trace; c019c9a2 cursor_timer_handler+22/28 Trace; c011c635 timer_bh+259/2b0 Trace; d9132ad4 [serial].bss.end+1351/18dd Trace; c0108301 handle_IRQ_event+4d/78 Trace; c01084e6 do_IRQ+a6/f4 Trace; c0105160 default_idle+0/34 Trace; c0105160 default_idle+0/34 Trace; c010a82e call_do_IRQ+5/b Trace; c0105160 default_idle+0/34 Trace; c0105160 default_idle+0/34 Trace; c0100018 startup_32+18/cb Trace; c010518d default_idle+2d/34 Trace; c01051f2 cpu_idle+3e/54 Trace; c0105000 prepare_namespace+0/8 Trace; c01001cf L6+0/2 Code; c018d250 scsi_report_bus_reset+8/28 _EIP: Code; c018d250 scsi_report_bus_reset+8/28 = 0: 8b 40 04 mov0x4(%eax),%eax = Code; c018d253 scsi_report_bus_reset+b/28 3: 85 c0 test %eax,%eax Code; c018d255 scsi_report_bus_reset+d/28 5: 74 15 je 1c _EIP+0x1c c018d26c scsi_report_bus_reset+24/28 Code; c018d257 scsi_report_bus_reset+f/28 7: 3b 90 6c 00 00 00 cmp0x6c(%eax),%edx Code; c018d25d scsi_report_bus_reset+15/28 d: 75 07 jne16 _EIP+0x16 c018d266 scsi_report_bus_reset+1e/28 Code; c018d25f scsi_report_bus_reset+17/28 f: 80 88 fc 00 00 00 00 orb$0x0,0xfc(%eax) 0 Kernel panic: Aiee, killing interrupt handler! 1070 warnings issued. Results may not be reliable. Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: P-III Oddity.
On Sat, 7 Apr 2001 19:58:15, Dave Jones <[EMAIL PROTECTED]> wrote: > On Sat, 7 Apr 2001, Rogier Wolff wrote: > > > One machine regularly crashes. > > Linux version 2.2.16-3 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 >19990314/Linux (egcs-1.1.2 release)) #1 Mon Jun 19 19:11:44 EDT 2000 > > Probably unrelated to the issue below. Try a more recent 2.2 ? > > > cpuid level : 2 > > CPU serial number disabled. > > > cpuid level : 3 > > CPU serial number enabled. I've got this on my dual processor P-III 600MHz. One of the cpus in this box reports cpuid level 2, the other 3. Serial number is disabled in the BIOS. > You should be able to confirm this with my x86info tool. > ftp://ftp.suse.com/pub/people/davej/x86info/x86info-1.0.tgz > > If this isn't the case, can you send me the output of > x86info -a on both CPUs ? x86info v1.0. Dave Jones 2001 Feedback to <[EMAIL PROTECTED]>. Found 2 CPU seax in: 0, eax = 0002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69 eax in: 1, eax = 0673 ebx = ecx = edx = 0383fbff eax in: 2, eax = 03020101 ebx = ecx = edx = 0c040843 Vendor ID: "GenuineIntel"; Max CPUID level 2 Intel-specific functions Family: 6 Model: 7 Type 0 [Pentium III/Pentium III Xeon Original OEM] Stepping: 3 Reserved: 0 Feature flags 0383fbff: FPUFloating Point Unit VMEVirtual 8086 Mode Enhancements DE Debugging Extensions PSEPage Size Extensions TSCTime Stamp Counter MSRModel Specific Registers PAEPhysical Address Extension MCEMachine Check Exception CX8COMPXCHG8B Instruction APIC On-chip Advanced Programmable Interrupt Controller present and enabled SEPFast System Call MTRR Memory Type Range Registers PGEPTE Global Flag MCAMachine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension MMXMMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore XMMStreaming SIMD Extensions instruction set Instruction TLB: 4KB pages, 4-way set assoc, 32 entries Instruction TLB: 4MB pages, fully assoc, 2 entries Data TLB: 4KB pages, 4-way set assoc, 64 entries L2 unified cache: 512KB, 4-way set assoc, 32 byte line size Instruction cache: 16KB, 4-way set assoc, 32 byte line size Data TLB: 4MB pages, 4-way set assoc, 8 entries Data cache: 16KB, 2-way or 4-way set assoc, 32 byte line size eax in: 0, eax = 0002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69 eax in: 1, eax = 0673 ebx = ecx = edx = 0383fbff eax in: 2, eax = 03020101 ebx = ecx = edx = 0c040843 Vendor ID: "GenuineIntel"; Max CPUID level 2 Intel-specific functions Family: 6 Model: 7 Type 0 [Pentium III/Pentium III Xeon Original OEM] Stepping: 3 Reserved: 0 Feature flags 0383fbff: FPUFloating Point Unit VMEVirtual 8086 Mode Enhancements DE Debugging Extensions PSEPage Size Extensions TSCTime Stamp Counter MSRModel Specific Registers PAEPhysical Address Extension MCEMachine Check Exception CX8COMPXCHG8B Instruction APIC On-chip Advanced Programmable Interrupt Controller present and enabled SEPFast System Call MTRR Memory Type Range Registers PGEPTE Global Flag MCAMachine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension MMXMMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore XMMStreaming SIMD Extensions instruction set Instruction TLB: 4KB pages, 4-way set assoc, 32 entries Instruction TLB: 4MB pages, fully assoc, 2 entries Data TLB: 4KB pages, 4-way set assoc, 64 entries L2 unified cache: 512KB, 4-way set assoc, 32 byte line size Instruction cache: 16KB, 4-way set assoc, 32 byte line size Data TLB: 4MB pages, 4-way set assoc, 8 entries Data cache: 16KB, 2-way or 4-way set assoc, 32 byte line size /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 598.407 cache size : 512 KB fdiv_bug: no hlt_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 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1192.75 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 598.407 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca c
Re: P-III Oddity.
On Sat, 7 Apr 2001 19:58:15, Dave Jones [EMAIL PROTECTED] wrote: On Sat, 7 Apr 2001, Rogier Wolff wrote: One machine regularly crashes. Linux version 2.2.16-3 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Jun 19 19:11:44 EDT 2000 Probably unrelated to the issue below. Try a more recent 2.2 ? cpuid level : 2 CPU serial number disabled. cpuid level : 3 CPU serial number enabled. I've got this on my dual processor P-III 600MHz. One of the cpus in this box reports cpuid level 2, the other 3. Serial number is disabled in the BIOS. You should be able to confirm this with my x86info tool. ftp://ftp.suse.com/pub/people/davej/x86info/x86info-1.0.tgz If this isn't the case, can you send me the output of x86info -a on both CPUs ? x86info v1.0. Dave Jones 2001 Feedback to [EMAIL PROTECTED]. Found 2 CPU seax in: 0, eax = 0002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69 eax in: 1, eax = 0673 ebx = ecx = edx = 0383fbff eax in: 2, eax = 03020101 ebx = ecx = edx = 0c040843 Vendor ID: "GenuineIntel"; Max CPUID level 2 Intel-specific functions Family: 6 Model: 7 Type 0 [Pentium III/Pentium III Xeon Original OEM] Stepping: 3 Reserved: 0 Feature flags 0383fbff: FPUFloating Point Unit VMEVirtual 8086 Mode Enhancements DE Debugging Extensions PSEPage Size Extensions TSCTime Stamp Counter MSRModel Specific Registers PAEPhysical Address Extension MCEMachine Check Exception CX8COMPXCHG8B Instruction APIC On-chip Advanced Programmable Interrupt Controller present and enabled SEPFast System Call MTRR Memory Type Range Registers PGEPTE Global Flag MCAMachine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension MMXMMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore XMMStreaming SIMD Extensions instruction set Instruction TLB: 4KB pages, 4-way set assoc, 32 entries Instruction TLB: 4MB pages, fully assoc, 2 entries Data TLB: 4KB pages, 4-way set assoc, 64 entries L2 unified cache: 512KB, 4-way set assoc, 32 byte line size Instruction cache: 16KB, 4-way set assoc, 32 byte line size Data TLB: 4MB pages, 4-way set assoc, 8 entries Data cache: 16KB, 2-way or 4-way set assoc, 32 byte line size eax in: 0, eax = 0002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69 eax in: 1, eax = 0673 ebx = ecx = edx = 0383fbff eax in: 2, eax = 03020101 ebx = ecx = edx = 0c040843 Vendor ID: "GenuineIntel"; Max CPUID level 2 Intel-specific functions Family: 6 Model: 7 Type 0 [Pentium III/Pentium III Xeon Original OEM] Stepping: 3 Reserved: 0 Feature flags 0383fbff: FPUFloating Point Unit VMEVirtual 8086 Mode Enhancements DE Debugging Extensions PSEPage Size Extensions TSCTime Stamp Counter MSRModel Specific Registers PAEPhysical Address Extension MCEMachine Check Exception CX8COMPXCHG8B Instruction APIC On-chip Advanced Programmable Interrupt Controller present and enabled SEPFast System Call MTRR Memory Type Range Registers PGEPTE Global Flag MCAMachine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension MMXMMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore XMMStreaming SIMD Extensions instruction set Instruction TLB: 4KB pages, 4-way set assoc, 32 entries Instruction TLB: 4MB pages, fully assoc, 2 entries Data TLB: 4KB pages, 4-way set assoc, 64 entries L2 unified cache: 512KB, 4-way set assoc, 32 byte line size Instruction cache: 16KB, 4-way set assoc, 32 byte line size Data TLB: 4MB pages, 4-way set assoc, 8 entries Data cache: 16KB, 2-way or 4-way set assoc, 32 byte line size /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 598.407 cache size : 512 KB fdiv_bug: no hlt_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 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1192.75 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 598.407 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1196.03 -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] -
Re: Matrox G400 Dualhead
On Mon, 2 Apr 2001 17:43:42, Petr Vandrovec <[EMAIL PROTECTED]> wrote: > Trevor Hemsley wrote: > > > I get this as well on my G200. From observation it appears that the > > refresh rate is being doubled when you exit X and that's why the > > console appears blank. On my system I normally use > > > > modprobe matroxfb vesa=263 fv=85 > > > > to give a large text console. On return from X, if I blindly type > > > > fbset "640x480-60" > > > > then I get a visible screen back but my monitor tells me that it's > > running at 640x480@119Hz. Same thing for 800x600-60 only this one says > > 120Hz. > > Unfortunately Matrox datasheet says that it is impossible :-( Can you > try 'fbset -depth 0; fbset -depth 8' ? Yes, that fixes it. Issuing the first fbset command brings me back some sort of display, all fsck'ed up but vaguely readable with shimmering bits of text all over it in the wrong places. The second fbset gets it back correctly at the right resolution and right refresh rate. Thanks, a workaround at least. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: Matrox G400 Dualhead
On Mon, 2 Apr 2001 17:43:42, Petr Vandrovec [EMAIL PROTECTED] wrote: Trevor Hemsley wrote: I get this as well on my G200. From observation it appears that the refresh rate is being doubled when you exit X and that's why the console appears blank. On my system I normally use modprobe matroxfb vesa=263 fv=85 to give a large text console. On return from X, if I blindly type fbset "640x480-60" then I get a visible screen back but my monitor tells me that it's running at 640x480@119Hz. Same thing for 800x600-60 only this one says 120Hz. Unfortunately Matrox datasheet says that it is impossible :-( Can you try 'fbset -depth 0; fbset -depth 8' ? Yes, that fixes it. Issuing the first fbset command brings me back some sort of display, all fsck'ed up but vaguely readable with shimmering bits of text all over it in the wrong places. The second fbset gets it back correctly at the right resolution and right refresh rate. Thanks, a workaround at least. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: Matrox G400 Dualhead
On Sat, 31 Mar 2001 07:17:19, "Rafael E. Herrera" <[EMAIL PROTECTED]> wrote: > J Brook wrote: > > > > >With 2.4.2 it was working just fine. > > > > I have also noticed problems with the 2.4.3 release. I have a G450 > > 32Mb, that I use in single-head mode. The console framebuffer runs > > fine at boot time, but when I load X (4.0.3 compiled with Matrox HAL > > library) and then return to the console, I get a blank screen (signal > > lost). > > In my case, when lilo boots my G450 on any video mode other than > 'normal', going into X and then back into console, leads to a blank > screen. I've observed this behavior in 2.2 and 2.4. Otherwise, I've no > problem using the card in single or dual head. I get this as well on my G200. From observation it appears that the refresh rate is being doubled when you exit X and that's why the console appears blank. On my system I normally use modprobe matroxfb vesa=263 fv=85 to give a large text console. On return from X, if I blindly type fbset "640x480-60" then I get a visible screen back but my monitor tells me that it's running at 640x480@119Hz. Same thing for 800x600-60 only this one says 120Hz. Base system is SuSE 7.1 using XFree86 4.0.2. If I switch to 3.3.6 then it works OK. If I don't load matroxfb then it also works OK. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: Matrox G400 Dualhead
On Sat, 31 Mar 2001 07:17:19, "Rafael E. Herrera" [EMAIL PROTECTED] wrote: J Brook wrote: With 2.4.2 it was working just fine. I have also noticed problems with the 2.4.3 release. I have a G450 32Mb, that I use in single-head mode. The console framebuffer runs fine at boot time, but when I load X (4.0.3 compiled with Matrox HAL library) and then return to the console, I get a blank screen (signal lost). In my case, when lilo boots my G450 on any video mode other than 'normal', going into X and then back into console, leads to a blank screen. I've observed this behavior in 2.2 and 2.4. Otherwise, I've no problem using the card in single or dual head. I get this as well on my G200. From observation it appears that the refresh rate is being doubled when you exit X and that's why the console appears blank. On my system I normally use modprobe matroxfb vesa=263 fv=85 to give a large text console. On return from X, if I blindly type fbset "640x480-60" then I get a visible screen back but my monitor tells me that it's running at 640x480@119Hz. Same thing for 800x600-60 only this one says 120Hz. Base system is SuSE 7.1 using XFree86 4.0.2. If I switch to 3.3.6 then it works OK. If I don't load matroxfb then it also works OK. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: 2.4.2 broke in-kernel ide_cs support
On Mon, 5 Mar 2001 08:14:42, Pavel Machek <[EMAIL PROTECTED]> wrote: > > I do not yet know details, but it worked in 2.4.1 and it does not work > now: > > Mar 5 09:12:05 bug cardmgr[69]: initializing socket 1 > Mar 5 09:12:05 bug cardmgr[69]: socket 1: ATA/IDE Fixed Disk > Mar 5 09:12:05 bug cardmgr[69]: module //pcmcia/ide_cs.o not > available > Mar 5 09:12:06 bug cardmgr[69]: get dev info on socket 1 failed: > Resource temporarily unavailable > Pavel > ((Module not available is okay, it should be compiled into kernel)) /etc/pcmcia/config refers to ide_cs but module is ide-cs. I've edited /etc/pcmcia/config and changed all ide_cs to ide-cs and it works. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: 2.4.2 broke in-kernel ide_cs support
On Mon, 5 Mar 2001 08:14:42, Pavel Machek [EMAIL PROTECTED] wrote: I do not yet know details, but it worked in 2.4.1 and it does not work now: Mar 5 09:12:05 bug cardmgr[69]: initializing socket 1 Mar 5 09:12:05 bug cardmgr[69]: socket 1: ATA/IDE Fixed Disk Mar 5 09:12:05 bug cardmgr[69]: module //pcmcia/ide_cs.o not available Mar 5 09:12:06 bug cardmgr[69]: get dev info on socket 1 failed: Resource temporarily unavailable Pavel ((Module not available is okay, it should be compiled into kernel)) /etc/pcmcia/config refers to ide_cs but module is ide-cs. I've edited /etc/pcmcia/config and changed all ide_cs to ide-cs and it works. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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/
IDE errors on APM resume
riveReady SeekComplete DataRequest }
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hda: drive not ready for command
ide0: unexpected interrupt, status=0xd0, count=1
ide0: reset: success
Trying to free nonexistent resource <03a8-03af>
Trying to free nonexistent resource <03a8-03af>
eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:60:97:8B:2B:2B
8K FIFO split 5:3 Rx:Tx, auto xcvr
eth0: flipped to 10baseT
inserting floppy driver for 2.4.2
floppy0: pcmcia=1
Floppy drive(s): fd0 is 1.44M
FDC 0 is an 8272A
trevor5:/ # rpm -qf `which apm`
apmd-3.0beta9-3
After the resume, hdparm reports
trevor5:/ # hdparm /dev/hda
/dev/hda:
multcount= 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 789/255/63, sectors = 12685680, start = 0
but beforehand it says
trevor5:/ # hdparm /dev/hda
/dev/hda:
multcount= 8 (on)
I/O support = 1 (32-bit)
unmaskirq= 1 (on)
using_dma= 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 789/255/63, sectors = 12685680, start = 0
Trevor Hemsley, Brighton, UK.
[EMAIL PROTECTED]
-
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/
IDE errors on APM resume
SeekComplete DataRequest }
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hda: drive not ready for command
ide0: unexpected interrupt, status=0xd0, count=1
ide0: reset: success
Trying to free nonexistent resource 03a8-03af
Trying to free nonexistent resource 03a8-03af
eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:60:97:8B:2B:2B
8K FIFO split 5:3 Rx:Tx, auto xcvr
eth0: flipped to 10baseT
inserting floppy driver for 2.4.2
floppy0: pcmcia=1
Floppy drive(s): fd0 is 1.44M
FDC 0 is an 8272A
trevor5:/ # rpm -qf `which apm`
apmd-3.0beta9-3
After the resume, hdparm reports
trevor5:/ # hdparm /dev/hda
/dev/hda:
multcount= 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 789/255/63, sectors = 12685680, start = 0
but beforehand it says
trevor5:/ # hdparm /dev/hda
/dev/hda:
multcount= 8 (on)
I/O support = 1 (32-bit)
unmaskirq= 1 (on)
using_dma= 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead= 8 (on)
geometry = 789/255/63, sectors = 12685680, start = 0
Trevor Hemsley, Brighton, UK.
[EMAIL PROTECTED]
-
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: Proliant hangs with 2.4 but works with 2.2.
On Sun, 18 Feb 2001 23:09:17, "lafanga lafanga" <[EMAIL PROTECTED]> wrote: > I have a Compaq Proliant 1600 server which can be hung on demand with all > the 2.4 series kernels I have tried (2.4, 2.4.1 & 2.4.2-pre3). Kernel 2.2.16 > runs perfectly (from a default RH7.0). > > I have ensured that the server meets the necessary requirements for the 2.4 > kernels (modutils etc) and I have tried kgcc and various gcc versions. When > compiling I have tried default configs and also minimalist configs (with > only cpqarray and tlan). I have also ensured that I have the latest current > SmartStart CD (4.9) and have setup the firmware for installing Linux. If you cat /proc/ioports does cpqarray show any registered ioports? I think it has a bug that means it doesn't request_region() for the ioports it uses and this means that any other driver that tries to auto-detect hardware by probing ports can stomp on its toes. This is certainly the case for EISA cpqarray controllers which is where I found this. I sent a report into [EMAIL PROTECTED] or whatever the address listed in the maintainers file is but haven't heard anything. This bug _may_ only exist for EISA controllers - I couldn't test the PCI version since the only machine I have with one in is running that other o/s. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: Proliant hangs with 2.4 but works with 2.2.
On Sun, 18 Feb 2001 23:09:17, "lafanga lafanga" [EMAIL PROTECTED] wrote: I have a Compaq Proliant 1600 server which can be hung on demand with all the 2.4 series kernels I have tried (2.4, 2.4.1 2.4.2-pre3). Kernel 2.2.16 runs perfectly (from a default RH7.0). I have ensured that the server meets the necessary requirements for the 2.4 kernels (modutils etc) and I have tried kgcc and various gcc versions. When compiling I have tried default configs and also minimalist configs (with only cpqarray and tlan). I have also ensured that I have the latest current SmartStart CD (4.9) and have setup the firmware for installing Linux. If you cat /proc/ioports does cpqarray show any registered ioports? I think it has a bug that means it doesn't request_region() for the ioports it uses and this means that any other driver that tries to auto-detect hardware by probing ports can stomp on its toes. This is certainly the case for EISA cpqarray controllers which is where I found this. I sent a report into [EMAIL PROTECTED] or whatever the address listed in the maintainers file is but haven't heard anything. This bug _may_ only exist for EISA controllers - I couldn't test the PCI version since the only machine I have with one in is running that other o/s. -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - 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: display problem with matroxfb
On Mon, 29 Jan 2001 00:30:34, Petr Vandrovec <[EMAIL PROTECTED]> wrote: > > > you do not have to specify vesa,pixclock,hslen and vslen, as you leave > > > them on defaults. > > > > Talking of defaults for matroxfb, would you consider limiting the fv: > > value default to something reasonable that'll work on all monitors? It > > took me several recompiles/reboots to get a setting that would not put > > my monitor into auto-powerdown. If you defaulted to fv:60 then it > > would work on 99.9% of monitors and then people could override that > > upwards. I have a Philips 201B 21" monitor and was using > > > > append="video=matrox:vesa:400" > > > > and this was setting too high a vertical refresh rate for the monitors > > capabilities. Adding fv:85 lets it work. The card is a Matrox > > Millennium G200 8MB SDRAM. > > Are you sure that it did not run out of horizontal sync, or something > like that? vesa:400 == vesa:0x190 == 1152x864/60Hz... And it powers > up in 60Hz, at least here ;-) > > See timmings array in drivers/video/matrox/matroxfb_base.c - all videomodes > except XXXx400 powerups in fv=60Hz unless you specified fh/fv/pixclock. > XXXx400 powerups with fv=70Hz, like standard VGA does. Looks like one you've already fixed. I've retested and recreated it but it only happens with 2.2.13 not with the other two kernel sources I have (2.2.18 and 2.4.0). I also misinformed you about the way to recreate it, I had specified only append="matrox" in my lilo.conf. It was 2.2.13 that I did my experimentation on to get it to work in the first place and never bothered to retest afterwards. Sorry for the false alarm... -- Trevor Hemsley, Brighton, UK. [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: display problem with matroxfb
On Mon, 29 Jan 2001 00:30:34, Petr Vandrovec [EMAIL PROTECTED] wrote: you do not have to specify vesa,pixclock,hslen and vslen, as you leave them on defaults. Talking of defaults for matroxfb, would you consider limiting the fv: value default to something reasonable that'll work on all monitors? It took me several recompiles/reboots to get a setting that would not put my monitor into auto-powerdown. If you defaulted to fv:60 then it would work on 99.9% of monitors and then people could override that upwards. I have a Philips 201B 21" monitor and was using append="video=matrox:vesa:400" and this was setting too high a vertical refresh rate for the monitors capabilities. Adding fv:85 lets it work. The card is a Matrox Millennium G200 8MB SDRAM. Are you sure that it did not run out of horizontal sync, or something like that? vesa:400 == vesa:0x190 == 1152x864/60Hz... And it powers up in 60Hz, at least here ;-) See timmings array in drivers/video/matrox/matroxfb_base.c - all videomodes except XXXx400 powerups in fv=60Hz unless you specified fh/fv/pixclock. XXXx400 powerups with fv=70Hz, like standard VGA does. Looks like one you've already fixed. I've retested and recreated it but it only happens with 2.2.13 not with the other two kernel sources I have (2.2.18 and 2.4.0). I also misinformed you about the way to recreate it, I had specified only append="matrox" in my lilo.conf. It was 2.2.13 that I did my experimentation on to get it to work in the first place and never bothered to retest afterwards. Sorry for the false alarm... -- Trevor Hemsley, Brighton, UK. [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: display problem with matroxfb
On Tue, 23 Jan 2001 21:57:56, "Petr Vandrovec" <[EMAIL PROTECTED]> wrote: > you do not have to specify vesa,pixclock,hslen and vslen, as you leave > them on defaults. Talking of defaults for matroxfb, would you consider limiting the fv: value default to something reasonable that'll work on all monitors? It took me several recompiles/reboots to get a setting that would not put my monitor into auto-powerdown. If you defaulted to fv:60 then it would work on 99.9% of monitors and then people could override that upwards. I have a Philips 201B 21" monitor and was using append="video=matrox:vesa:400" and this was setting too high a vertical refresh rate for the monitors capabilities. Adding fv:85 lets it work. The card is a Matrox Millennium G200 8MB SDRAM. trevor@trevor4:/usr/src/linux > grep ^C .config|grep FB CONFIG_FB=y CONFIG_FB_MATROX=y CONFIG_FB_MATROX_G100=y CONFIG_FBCON_ADVANCED=y CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y CONFIG_FBCON_FONTS=y -- Trevor Hemsley, Brighton, UK. [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: Incorrect module init message..
On Wed, 17 Jan 2001 09:09:01, "Mike A. Harris" <[EMAIL PROTECTED]> wrote: > 1 root@asdf:/# mcdr > Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 > sr0: scsi3-mmc drive: 6x/6x writer cd/rw xa/form2 cdda tray > ^ > > HP7200i burner 2x/2x/6x (CDR/CDRW/read) > > Don't know if anyone cares to fix the message.. The message is reporting current/maximum read speeds. There's no indication that this is or is not what was intended to be reported. If it was intended to be max write/read speeds then it should be using the two bytes at +18 and 19 of mode page 2a not the ones at +14 and 15. -- Trevor Hemsley, Brighton, UK. [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: Incorrect module init message..
On Wed, 17 Jan 2001 09:09:01, "Mike A. Harris" [EMAIL PROTECTED] wrote: 1 root@asdf:/# mcdr Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 sr0: scsi3-mmc drive: 6x/6x writer cd/rw xa/form2 cdda tray ^ HP7200i burner 2x/2x/6x (CDR/CDRW/read) Don't know if anyone cares to fix the message.. The message is reporting current/maximum read speeds. There's no indication that this is or is not what was intended to be reported. If it was intended to be max write/read speeds then it should be using the two bytes at +18 and 19 of mode page 2a not the ones at +14 and 15. -- Trevor Hemsley, Brighton, UK. [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/
[PATCH] i91uscsi.c misreads BIOS settings
Here's a patch for i91uscsi.c as delivered with the 2.4.0 kernel to correct the
problem
of it reading the BIOS settings for double the SCSI id that it should be looking at.
This is a two liner to correct this problem but I've done some fairly major cosmetic
surgery on the rest of the driver - it currently uses two header files, i91uscsi.h and
ini9100u.h - and these contain duplicate definitions of the same structs but with
different contents.
This sounds to me like a recipe for problems so I've combined the two header files
and eliminated the duplication. I've also added /proc fs support. The resulting patch
is too big to post to a mailing list and a complete replacement of the source can be
found on http://www.os2warp.org/sysbench/i91uv104.tar.gz - this
adds ini9100_proc.c but i91uscsi.h can be rm'ed as no longer required. This
replacement has been tested on 2.2.13, 2.2.18 and 2.4.0 compiled into the
kernel and also on 2.4.0 as a module.
--- /backup/linuxold/drivers/scsi/i91uscsi.cMon Aug 23 17:23:23 1999
+++ /backup/linux/drivers/scsi/i91uscsi.c Thu Jan 18 21:42:52 2001
@@ -590,7 +590,7 @@
int init_tulip(HCS * pCurHcb, SCB * scbp, int tul_num_scb, BYTE * pbBiosAdr, int
seconds)
{
int i;
- WORD *pwFlags;
+ BYTE *pwFlags;
BYTE *pbHeads;
SCB *pTmpScb, *pPrevScb = NULL;
@@ -674,7 +674,7 @@
((pCurHcb->HCS_Config & HCC_AUTO_TERM) >> 4) |
(TUL_RD(pCurHcb->HCS_Base, TUL_GCTRL1) & 0xFE));
for (i = 0,
-pwFlags = (WORD *) & (i91unvramp->NVM_SCSIInfo[0].NVM_Targ0Config),
+pwFlags = & (i91unvramp->NVM_SCSIInfo[0].NVM_Targ0Config),
pbHeads = pbBiosAdr + 0x180;
i < pCurHcb->HCS_MaxTar;
i++, pwFlags++) {
Trevor Hemsley, Brighton, UK.
[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/
[PATCH] i91uscsi.c misreads BIOS settings
Here's a patch for i91uscsi.c as delivered with the 2.4.0 kernel to correct the
problem
of it reading the BIOS settings for double the SCSI id that it should be looking at.
This is a two liner to correct this problem but I've done some fairly major cosmetic
surgery on the rest of the driver - it currently uses two header files, i91uscsi.h and
ini9100u.h - and these contain duplicate definitions of the same structs but with
different contents.
This sounds to me like a recipe for problems so I've combined the two header files
and eliminated the duplication. I've also added /proc fs support. The resulting patch
is too big to post to a mailing list and a complete replacement of the source can be
found on http://www.os2warp.org/sysbench/i91uv104.tar.gz - this
adds ini9100_proc.c but i91uscsi.h can be rm'ed as no longer required. This
replacement has been tested on 2.2.13, 2.2.18 and 2.4.0 compiled into the
kernel and also on 2.4.0 as a module.
--- /backup/linuxold/drivers/scsi/i91uscsi.cMon Aug 23 17:23:23 1999
+++ /backup/linux/drivers/scsi/i91uscsi.c Thu Jan 18 21:42:52 2001
@@ -590,7 +590,7 @@
int init_tulip(HCS * pCurHcb, SCB * scbp, int tul_num_scb, BYTE * pbBiosAdr, int
seconds)
{
int i;
- WORD *pwFlags;
+ BYTE *pwFlags;
BYTE *pbHeads;
SCB *pTmpScb, *pPrevScb = NULL;
@@ -674,7 +674,7 @@
((pCurHcb-HCS_Config HCC_AUTO_TERM) 4) |
(TUL_RD(pCurHcb-HCS_Base, TUL_GCTRL1) 0xFE));
for (i = 0,
-pwFlags = (WORD *) (i91unvramp-NVM_SCSIInfo[0].NVM_Targ0Config),
+pwFlags = (i91unvramp-NVM_SCSIInfo[0].NVM_Targ0Config),
pbHeads = pbBiosAdr + 0x180;
i pCurHcb-HCS_MaxTar;
i++, pwFlags++) {
Trevor Hemsley, Brighton, UK.
[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/
Initio 9x00 SCSI driver status
I've been doing some work on the Initio 9100UW SCSI driver that is distributed with 2.4.0. I've fixed a couple of bugs and added /proc support to my copy of the source. Is there an active maintainer of this driver at present? Is there anything that tells what to do to add support for the new error handling code so it doesn't use scsi_old.c any more? I'm reading this via fa.linux.kernel so should pick up replies that way but email is fine too. Trevor Hemsley, Brighton, UK. [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/
Initio 9x00 SCSI driver status
I've been doing some work on the Initio 9100UW SCSI driver that is distributed with 2.4.0. I've fixed a couple of bugs and added /proc support to my copy of the source. Is there an active maintainer of this driver at present? Is there anything that tells what to do to add support for the new error handling code so it doesn't use scsi_old.c any more? I'm reading this via fa.linux.kernel so should pick up replies that way but email is fine too. Trevor Hemsley, Brighton, UK. [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/
