S.M.A.R.T. Monitoring Tools

Hi,
I have a reproduceable hard lockup when using smartctl on a Promise 20265
IDE-controller (pdc202xx-driver, no RAID, just 2 separate drives). 

Details: 

It never happend with 2.4.18 or earlier, but always appears with 2.4.19 (and
the patch for drives >120GB) or 2.4.20 (with enabled ide-taskfile). So maybe
it has something to do with the taskfile... BTW: I use the kernel from the
XFS-CVS, but I don't think that it has anything to do with the FS.

It happens only for /dev/hde and /dev/hdf, hd[a-d] have no problems with
smartctl (V2.1).

The connected disks are Maxtor 4K080H4&98196H8 (each about 80GB).

The lockup happens for all commands I have tried (smartctrl -e /dev/hde is
the easiest way).

There is _NO OOPS_, even kdb and alt-sysreq don't work anymore (a rarely
seen situation...), but the IDE-LED is on, so the request seems to be
started (at least ;-)

There are no other problems (disk access, DMA, etc.) for the drives
connected to the Promise IDE-port, it happens _only_ with smartctl.

I don't know if this is the right place to ask, but maybe you know a better
one :-)

Thanks.
-- 
         Georg Acher, acher@...         
         http://wwwbode.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Bruce Allen <ballen@gr...> - 2002-12-26 06:14 Hi Greg, Thanks for your note. I'm sorry to hear that you are having problems with smartmontools. I'm adding this to the WARNINGS file -- if it's resolved then I'll remove it. Before I act further on this, I need a bit of help to understand what's going on. > I have a reproduceable hard lockup when using smartctl on a Promise > 20265 IDE-controller (pdc202xx-driver, no RAID, just 2 separate > drives). OK, this is just a 2-drive IDE controller PCI card, right? > It never happend with 2.4.18 or earlier, but always appears with > 2.4.19 (and the patch for drives >120GB) or 2.4.20 (with enabled > ide-taskfile). So maybe it has something to do with the taskfile... > BTW: I use the kernel from the XFS-CVS, but I don't think that it has > anything to do with the FS. So this card requires its own ide driver (pdc202xx-driver)? And you're building it with ide-taskfile enabled? It would help if you could be specific about any IDE-related config options you are using. > It happens only for /dev/hde and /dev/hdf, hd[a-d] have no problems > with smartctl (V2.1). OK, two questions here. First, when you say it only happens for hde and hdf, are these the two disks that are controlled by the pdc202xx-driver, whereas hd[a-d] are controlled by the normal ide driver? Or are hd[a-d] also controlled by the pdc202xx-driver? Second question: I don't know what is meant by smartctl (V2.1). Could you please send the output of smartctl -V to the mailing list so I can see what version you are using? > The connected disks are Maxtor 4K080H4&98196H8 (each about 80GB). > > The lockup happens for all commands I have tried (smartctrl -e /dev/hde is > the easiest way). > > There is _NO OOPS_, even kdb and alt-sysreq don't work anymore (a rarely > seen situation...), but the IDE-LED is on, so the request seems to be > started (at least ;-) > > There are no other problems (disk access, DMA, etc.) for the drives > connected to the Promise IDE-port, it happens _only_ with smartctl. I suspect it is related to the ide-taskfile support. Though I'll have to see the output of smartctl -V to see if this is even used in the smartctl -e command. > I don't know if this is the right place to ask, but maybe you know a better > one :-) The only other place to inquire is with the pdc202xx-driver developers/maintainers. The fact that it works in 2.4.18 and broke in 2.4.19 suggests that something may have changed in the ide-taskfile support. Have you asked? Cheers, Bruce

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Georg Acher <acher@in...> - 2002-12-26 13:27 On Thu, Dec 26, 2002 at 12:14:35AM -0600, Bruce Allen wrote: > Hi Greg, It's "Georg" ;-) > Thanks for your note. I'm sorry to hear that you are having problems with > smartmontools. I'm adding this to the WARNINGS file -- if it's resolved > then I'll remove it. > > Before I act further on this, I need a bit of help to understand what's > going on. > > > I have a reproduceable hard lockup when using smartctl on a Promise > > 20265 IDE-controller (pdc202xx-driver, no RAID, just 2 separate > > drives). > > OK, this is just a 2-drive IDE controller PCI card, right? It's a Asus K7V mainboard with this controller on-board, the regular chipset controller is a VIA 82C686. The Promise chip has two additional IDE-ports (Ultra-whatever), but I'm using only one for the two drives. In total there are 6 IDE-drives installed. > > It never happend with 2.4.18 or earlier, but always appears with > > 2.4.19 (and the patch for drives >120GB) or 2.4.20 (with enabled > > ide-taskfile). So maybe it has something to do with the taskfile... > > BTW: I use the kernel from the XFS-CVS, but I don't think that it has > > anything to do with the FS. > > So this card requires its own ide driver (pdc202xx-driver)? And you're > building it with ide-taskfile enabled? It would help if you could be > specific about any IDE-related config options you are using. Yes, the pdc202xx-driver is needed. Here's are the selected IDE-options (for 2.4.20): #define CONFIG_BLK_DEV_IDE 1 #define CONFIG_BLK_DEV_IDEDISK 1 #define CONFIG_IDEDISK_MULTI_MODE 1 #define CONFIG_IDEDISK_STROKE 1 #define CONFIG_BLK_DEV_IDECD 1 #define CONFIG_IDE_TASK_IOCTL 1 #define CONFIG_BLK_DEV_IDEPCI 1 #define CONFIG_IDEPCI_SHARE_IRQ 1 #define CONFIG_BLK_DEV_IDEDMA_PCI 1 #define CONFIG_IDEDMA_PCI_AUTO 1 #define CONFIG_BLK_DEV_IDEDMA 1 #define CONFIG_BLK_DEV_ADMA 1 #define CONFIG_BLK_DEV_PDC202XX 1 #define CONFIG_PDC202XX_BURST 1 #define CONFIG_BLK_DEV_VIA82CXXX 1 #define CONFIG_IDEDMA_AUTO 1 #define CONFIG_BLK_DEV_IDE_MODES 1 > > It happens only for /dev/hde and /dev/hdf, hd[a-d] have no problems > > with smartctl (V2.1). > > OK, two questions here. First, when you say it only happens for hde and > hdf, are these the two disks that are controlled by the pdc202xx-driver, > whereas hd[a-d] are controlled by the normal ide driver? Or are hd[a-d] > also controlled by the pdc202xx-driver? Yes, only hd[e-f] are controlled by pdc202xx, hd[a-d] are handled by the normal/VIA-driver. > Second question: I don't know what is meant by smartctl (V2.1). Could you > please send the output of smartctl -V to the mailing list so I can see > what version you are using? braindead5:/root> smartctl -V smartctl version 2.1 - S.M.A.R.T. Control Program <...> > > The connected disks are Maxtor 4K080H4&98196H8 (each about 80GB). > > > > The lockup happens for all commands I have tried (smartctrl -e /dev/hde is > > the easiest way). > > > > There is _NO OOPS_, even kdb and alt-sysreq don't work anymore (a rarely > > seen situation...), but the IDE-LED is on, so the request seems to be > > started (at least ;-) > > > > There are no other problems (disk access, DMA, etc.) for the drives > > connected to the Promise IDE-port, it happens _only_ with smartctl. > > I suspect it is related to the ide-taskfile support. Though I'll have to > see the output of smartctl -V to see if this is even used in the smartctl > -e command. > > > I don't know if this is the right place to ask, but maybe you know a better > > one :-) > > The only other place to inquire is with the pdc202xx-driver > developers/maintainers. The fact that it works in 2.4.18 and broke in > 2.4.19 suggests that something may have changed in the ide-taskfile > support. Have you asked? Will do... -- Georg Acher, acher@... http://wwwbode.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Bruce Allen <ballen@gr...> - 2002-12-28 13:38 Hi Georg, > It's "Georg" ;-) Sorry! > > Second question: I don't know what is meant by smartctl (V2.1). Could you > > please send the output of smartctl -V to the mailing list so I can see > > what version you are using? > > braindead5:/root> smartctl -V > smartctl version 2.1 - S.M.A.R.T. Control Program > <...> You are using smartctl from the smartsuite package, not smartctl from the smartmontools package. I suspect that you will have the same problem with smartmontools/smartctl, but I'd appreciate it if you could please try it and report back. Look at smartmontools.sourceforge.net to get the smartmontools version (5.0.49) of smartctl. Please let us know if this does anything different than smartsuite/smartctl did. Cheers, Bruce Allen

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Georg Acher <acher@in...> - 2002-12-28 17:03 On Sat, Dec 28, 2002 at 07:38:25AM -0600, Bruce Allen wrote: > > > Second question: I don't know what is meant by smartctl (V2.1). Could you > > > please send the output of smartctl -V to the mailing list so I can see > > > what version you are using? > > > > braindead5:/root> smartctl -V > > smartctl version 2.1 - S.M.A.R.T. Control Program > > <...> > > You are using smartctl from the smartsuite package, not smartctl from the > smartmontools package. I suspect that you will have the same problem with > smartmontools/smartctl, but I'd appreciate it if you could please try it > and report back. Look at smartmontools.sourceforge.net to get the > smartmontools version (5.0.49) of smartctl. > > Please let us know if this does anything different than > smartsuite/smartctl did. No, it didn't change anything, it works with hda-hdd and freezes with hde. But I made a few more observations: - The last system call before the freeze is ioctl( ,HDIO_DRIVE_CMD), which is merely the first thing smartctl actually calls... - I was using the soundcard for playback at that time. Usually, a hard Oops even in interrupt cause the music to be looped in 0.2-0.5s intervals since the DMA buffer is still being read out by the soundcard. I had enough such crashs during USB development, so I know the sound of Oops :-) But here, I only hear a very high tone, which looks like the whole PCI-bus is permanently blocked, and the sound FIFO runs empty. So it "sounds" really like a brutal hardware crash at its best. It's not easy to crash the PCI bus ;-) So I will contact the pdcx-maintainers... -- Georg Acher, acher@... http://wwwbode.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Georg Acher <georg@ac...> - 2002-12-28 16:54 On Sat, Dec 28, 2002 at 07:38:25AM -0600, Bruce Allen wrote: > > > Second question: I don't know what is meant by smartctl (V2.1). Could you > > > please send the output of smartctl -V to the mailing list so I can see > > > what version you are using? > > > > braindead5:/root> smartctl -V > > smartctl version 2.1 - S.M.A.R.T. Control Program > > <...> > > You are using smartctl from the smartsuite package, not smartctl from the > smartmontools package. I suspect that you will have the same problem with > smartmontools/smartctl, but I'd appreciate it if you could please try it > and report back. Look at smartmontools.sourceforge.net to get the > smartmontools version (5.0.49) of smartctl. > > Please let us know if this does anything different than > smartsuite/smartctl did. No, it didn't change anything, it works with hda-hdd and freezes with hde. But I made a few more observations: - The last system call before the freeze is ioctl( ,HDIO_DRIVE_CMD), which is merely the first thing smartctl actually calls... - I was using the soundcard for playback at that time. Usually, a hard Oops even in interrupt cause the music to be looped in 0.2-0.5s intervals since the DMA buffer is still being read out by the soundcard. I had enough such crashs during USB development, so I know the sound of Oops :-) But here, I only hear a very high tone, which looks like the whole PCI-bus is permanently blocked, and the sound FIFO runs empty. So it "sounds" really like a brutal hardware crash at its best. It's not easy to crash the PCI bus ;-) So I will contact the pdcx-maintainers... -- Georg Acher, georg@... http://www.acher.org "Oh no, not again !" The bowl of petunias

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Bruce Allen <ballen@gr...> - 2002-12-29 06:55 Hi Georg, > > You are using smartctl from the smartsuite package, not smartctl from the > > smartmontools package. I suspect that you will have the same problem with > > smartmontools/smartctl, but I'd appreciate it if you could please try it > > and report back. Look at smartmontools.sourceforge.net to get the > > smartmontools version (5.0.49) of smartctl. > > > > Please let us know if this does anything different than > > smartsuite/smartctl did. > > No, it didn't change anything, it works with hda-hdd and freezes with hde. > But I made a few more observations: > > - The last system call before the freeze is ioctl( ,HDIO_DRIVE_CMD), which is > merely the first thing smartctl actually calls... It sounds like this is a pretty elementary problem. The first ioctl that smartctl issues is for the mandatory "Drive Identity" command: int ataReadHDIdentity (int device, struct hd_driveid *buf){ unsigned short driveidchecksum; unsigned char parms[HDIO_DRIVE_CMD_HDR_SIZE+sizeof(*buf)]= {WIN_IDENTIFY, 0, 0, 1,}; if (ioctl(device ,HDIO_DRIVE_CMD,parms)){ // See if device responds to packet command... parms[0]=WIN_PIDENTIFY; if (ioctl(device ,HDIO_DRIVE_CMD,parms)){ syserror("Error ATA GET HD Identity Failed"); return -1; } } Could you please try running hdparm -i or hdparm -I and see if this dies in the same way? I think that hdparm also issues a drive ID command as its first command. > So I will contact the pdcx-maintainers... If you can reproduce the problem with hdparm, then that ought to get their attention very quickly. Cheers, Bruce

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Georg Acher <acher@in...> - 2002-12-29 14:51 On Sun, Dec 29, 2002 at 12:54:53AM -0600, Bruce Allen wrote: > > No, it didn't change anything, it works with hda-hdd and freezes with hde. > > But I made a few more observations: > > > > - The last system call before the freeze is ioctl( ,HDIO_DRIVE_CMD), which is > > merely the first thing smartctl actually calls... > > It sounds like this is a pretty elementary problem. The first ioctl that > smartctl issues is for the mandatory "Drive Identity" command: <...> > Could you please try running hdparm -i or hdparm -I and see if this dies > in the same way? I think that hdparm also issues a drive ID command as > its first command. hdparm -i works as usual (it does not use HDIO_DRIVE_CMD), but hdparm -I causes the same freeze when calling HDIO_DRIVE_CMD. > > So I will contact the pdcx-maintainers... > > If you can reproduce the problem with hdparm, then that ought to get their > attention very quickly. I hope so ;-) Thanks for the hdparm-suggestion... -- Georg Acher, acher@... http://wwwbode.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Bruce Allen <ballen@gr...> - 2002-12-30 05:27 Hi Georg, > > It sounds like this is a pretty elementary problem. The first ioctl that > > smartctl issues is for the mandatory "Drive Identity" command: > <...> > > Could you please try running hdparm -i or hdparm -I and see if this dies > > in the same way? I think that hdparm also issues a drive ID command as > > its first command. > > hdparm -i works as usual (it does not use HDIO_DRIVE_CMD), but hdparm -I > causes the same freeze when calling HDIO_DRIVE_CMD. Very nice -- you have isolated the problem. hdparm -i uses the function ioctl(device, HDIO_GET_IDENTITY, buf) which interrogates the BIOS to find out about the disk identity information when the system was booted. hdparm -I uses the function ioctl(device ,HDIO_DRIVE_CMD,parms) with parms[HDIO_DRIVE_CMD_HDR_SIZE+sizeof(*buf)]={WIN_IDENTIFY, 0, 0, 1,}; to issue the ATA Drive Identity command. This is what is failing on your Promise 20265 IDE-controller (pdc202xx-driver) combo. smartmontools also uses this latter ioctl(). Thanks for contacting the pdcx maintainers. I'm copying this email to Mark Lord so he'll know what's wrong if he gets problem reports about hdparm on this Promise controller. Mark, you can see the thread here: http://sourceforge.net/mailarchive/forum.php?thread_id=1457979&forum_id=12495 Cheers, Bruce

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Georg Acher <acher@in...> - 2002-12-30 22:09 On Mon, Dec 30, 2002 at 10:43:54AM -0500, Mark Lord wrote: > Mmm.. if this is true, then the following should ALSO fail: > > cat /proc/ide/hd*/identify > > Does it? I can't (don't want to) currently test that, I'm about 100km away from that machine. And it has no watchdog (neither electronical nor human) ;-) I'm back next monday and I will try it then. -- Georg Acher, acher@... http://wwwbode.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Mark Lord <mlord@po...> - 2002-12-30 15:44 Mmm.. if this is true, then the following should ALSO fail: cat /proc/ide/hd*/identify Does it? Cheers -- Mark Lord Real-Time Remedies Inc. mlord@... Bruce Allen wrote: > Hi Georg, > > >>>It sounds like this is a pretty elementary problem. The first ioctl that >>>smartctl issues is for the mandatory "Drive Identity" command: >> >><...> >> >>>Could you please try running hdparm -i or hdparm -I and see if this dies >>>in the same way? I think that hdparm also issues a drive ID command as >>>its first command. >> >>hdparm -i works as usual (it does not use HDIO_DRIVE_CMD), but hdparm -I >>causes the same freeze when calling HDIO_DRIVE_CMD. > > > Very nice -- you have isolated the problem. > > hdparm -i uses the function ioctl(device, HDIO_GET_IDENTITY, buf) which > interrogates the BIOS to find out about the disk identity information when > the system was booted. > > hdparm -I uses the function ioctl(device ,HDIO_DRIVE_CMD,parms) with > parms[HDIO_DRIVE_CMD_HDR_SIZE+sizeof(*buf)]={WIN_IDENTIFY, 0, 0, 1,}; > to issue the ATA Drive Identity command. This is what is failing on your > Promise 20265 IDE-controller (pdc202xx-driver) combo. > > smartmontools also uses this latter ioctl(). > > Thanks for contacting the pdcx maintainers. > > I'm copying this email to Mark Lord so he'll know what's wrong if he gets > problem reports about hdparm on this Promise controller. Mark, you can > see the thread here: > > http://sourceforge.net/mailarchive/forum.php?thread_id=1457979&forum_id=12495 > > Cheers, > Bruce > > >

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Bruce Allen <ballen@gr...> - 2003-01-01 08:02 Mark, Georg, Every few days, I do a google search to see what's turned up that's relevant to smartmontools. Here's something of relevance to our promise-related thread. Mark, I think it suggests an answer to your question (that yes, the command below WILL fail) but I'd still like to see what happens when Georg has a chance to try it... http://groups.google.com/groups?q=smartctl+-freshmeat+-slackware&hl=en&lr=&ie=UTF-8&oe=UTF-8&scoring=d&selm=200212201338.45492.marvin%40synapse.net&rnum=5 Cheers, Bruce On Mon, 30 Dec 2002, Mark Lord wrote: > Mmm.. if this is true, then the following should ALSO fail: > > cat /proc/ide/hd*/identify > > Does it? > > Cheers > -- > Mark Lord > Real-Time Remedies Inc. > mlord@... > > > > > Bruce Allen wrote: > > Hi Georg, > > > > > >>>It sounds like this is a pretty elementary problem. The first ioctl that > >>>smartctl issues is for the mandatory "Drive Identity" command: > >> > >><...> > >> > >>>Could you please try running hdparm -i or hdparm -I and see if this dies > >>>in the same way? I think that hdparm also issues a drive ID command as > >>>its first command. > >> > >>hdparm -i works as usual (it does not use HDIO_DRIVE_CMD), but hdparm -I > >>causes the same freeze when calling HDIO_DRIVE_CMD. > > > > > > Very nice -- you have isolated the problem. > > > > hdparm -i uses the function ioctl(device, HDIO_GET_IDENTITY, buf) which > > interrogates the BIOS to find out about the disk identity information when > > the system was booted. > > > > hdparm -I uses the function ioctl(device ,HDIO_DRIVE_CMD,parms) with > > parms[HDIO_DRIVE_CMD_HDR_SIZE+sizeof(*buf)]={WIN_IDENTIFY, 0, 0, 1,}; > > to issue the ATA Drive Identity command. This is what is failing on your > > Promise 20265 IDE-controller (pdc202xx-driver) combo. > > > > smartmontools also uses this latter ioctl(). > > > > Thanks for contacting the pdcx maintainers. > > > > I'm copying this email to Mark Lord so he'll know what's wrong if he gets > > problem reports about hdparm on this Promise controller. Mark, you can > > see the thread here: > > > > http://sourceforge.net/mailarchive/forum.php?thread_id=1457979&forum_id=12495 > > > > Cheers, > > Bruce > > > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Smartmontools-support mailing list > Smartmontools-support@... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support >

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Bruce Allen <ballen@gr...> - 2003-01-01 08:07 Another thread of relevance: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=fa.mu2pj6v.5624bf%40ifi.uio.no&rnum=7&prev=/groups%3Fq%3Dsmartctl%2B-freshmeat%2B-slackware%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26scoring%3Dd%26selm%3Dfa.mu2pj6v.5624bf%2540ifi.uio.no%26rnum%3D7 Cheers, Bruce > Mark, Georg, > > Every few days, I do a google search to see what's turned up that's > relevant to smartmontools. Here's something of relevance to our > promise-related thread. Mark, I think it suggests an answer to your > question (that yes, the command below WILL fail) but I'd still like to see > what happens when Georg has a chance to try it... > > http://groups.google.com/groups?q=smartctl+-freshmeat+-slackware&hl=en&lr=&ie=UTF-8&oe=UTF-8&scoring=d&selm=200212201338.45492.marvin%40synapse.net&rnum=5 > > Cheers, > Bruce > > On Mon, 30 Dec 2002, Mark Lord wrote: > > > Mmm.. if this is true, then the following should ALSO fail: > > > > cat /proc/ide/hd*/identify > > > > Does it? > > > > Cheers > > -- > > Mark Lord > > Real-Time Remedies Inc. > > mlord@... > > > > > > > > > > Bruce Allen wrote: > > > Hi Georg, > > > > > > > > >>>It sounds like this is a pretty elementary problem. The first ioctl that > > >>>smartctl issues is for the mandatory "Drive Identity" command: > > >> > > >><...> > > >> > > >>>Could you please try running hdparm -i or hdparm -I and see if this dies > > >>>in the same way? I think that hdparm also issues a drive ID command as > > >>>its first command. > > >> > > >>hdparm -i works as usual (it does not use HDIO_DRIVE_CMD), but hdparm -I > > >>causes the same freeze when calling HDIO_DRIVE_CMD. > > > > > > > > > Very nice -- you have isolated the problem. > > > > > > hdparm -i uses the function ioctl(device, HDIO_GET_IDENTITY, buf) which > > > interrogates the BIOS to find out about the disk identity information when > > > the system was booted. > > > > > > hdparm -I uses the function ioctl(device ,HDIO_DRIVE_CMD,parms) with > > > parms[HDIO_DRIVE_CMD_HDR_SIZE+sizeof(*buf)]={WIN_IDENTIFY, 0, 0, 1,}; > > > to issue the ATA Drive Identity command. This is what is failing on your > > > Promise 20265 IDE-controller (pdc202xx-driver) combo. > > > > > > smartmontools also uses this latter ioctl(). > > > > > > Thanks for contacting the pdcx maintainers. > > > > > > I'm copying this email to Mark Lord so he'll know what's wrong if he gets > > > problem reports about hdparm on this Promise controller. Mark, you can > > > see the thread here: > > > > > > http://sourceforge.net/mailarchive/forum.php?thread_id=1457979&forum_id=12495 > > > > > > Cheers, > > > Bruce > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Smartmontools-support mailing list > > Smartmontools-support@... > > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Smartmontools-support mailing list > Smartmontools-support@... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support >

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Georg Acher <acher@in...> - 2003-01-02 20:06 On Wed, Jan 01, 2003 at 01:59:39AM -0600, Bruce Allen wrote: > Mark, Georg, > > Every few days, I do a google search to see what's turned up that's > relevant to smartmontools. Here's something of relevance to our > promise-related thread. Mark, I think it suggests an answer to your > question (that yes, the command below WILL fail) but I'd still like to see > what happens when Georg has a chance to try it... > > http://groups.google.com/groups?q=smartctl+-freshmeat+-slackware&hl=en&lr=&ie=UTF-8&oe=UTF-8&scoring=d&selm=200212201338.45492.marvin%40synapse.net&rnum=5 Sounds very similar to my setup. I have also disabled the Promise-Bios, since it takes so long to detect the disks. When I'm back home, I'll try whether enabling it will help or not. -- Georg Acher, acher@... http://wwwbode.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Georg Acher <acher@in...> - 2003-01-06 14:43 On Thu, Jan 02, 2003 at 09:04:51PM +0100, Georg Acher wrote: > On Wed, Jan 01, 2003 at 01:59:39AM -0600, Bruce Allen wrote: > > Mark, Georg, > > > > Every few days, I do a google search to see what's turned up that's > > relevant to smartmontools. Here's something of relevance to our > > promise-related thread. Mark, I think it suggests an answer to your > > question (that yes, the command below WILL fail) but I'd still like to see > > what happens when Georg has a chance to try it... > > > > http://groups.google.com/groups?q=smartctl+-freshmeat+-slackware&hl=en&lr=&ie=UTF-8&oe=UTF-8&scoring=d&selm=200212201338.45492.marvin%40synapse.net&rnum=5 > > Sounds very similar to my setup. I have also disabled the Promise-Bios, > since it takes so long to detect the disks. When I'm back home, I'll try > whether enabling it will help or not. Ok, back at home: /cat/proc/hde/identify also crashes the machine. But more important: Enabling the Promise-Bios (aka ATA100-Bios) again solves all troubles. So it's not taskfile related in any way, it's a incomplete initialization of the Promise chip in the kernel driver. Thanks for all the support, now I know that my drives are still healthy ;-) -- Georg Acher, acher@... http://wwwbode.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Bruce Allen <ballen@gr...> - 2003-01-06 15:56 Georg, I'm glad that this is sorted out. I want to modify the smartmontools WARNING file to help users overcome this problem. I'll put in "Enable the Promise-BIOS (ATA100-BIOS) or the machine will hang". But please tell me if this is not the right thing to say, or if I should say more. Cheers, Bruce On Mon, 6 Jan 2003, Georg Acher wrote: > On Thu, Jan 02, 2003 at 09:04:51PM +0100, Georg Acher wrote: > > On Wed, Jan 01, 2003 at 01:59:39AM -0600, Bruce Allen wrote: > > > Mark, Georg, > > > > > > Every few days, I do a google search to see what's turned up that's > > > relevant to smartmontools. Here's something of relevance to our > > > promise-related thread. Mark, I think it suggests an answer to your > > > question (that yes, the command below WILL fail) but I'd still like to see > > > what happens when Georg has a chance to try it... > > > > > > http://groups.google.com/groups?q=smartctl+-freshmeat+-slackware&hl=en&lr=&ie=UTF-8&oe=UTF-8&scoring=d&selm=200212201338.45492.marvin%40synapse.net&rnum=5 > > > > Sounds very similar to my setup. I have also disabled the Promise-Bios, > > since it takes so long to detect the disks. When I'm back home, I'll try > > whether enabling it will help or not. > > Ok, back at home: /cat/proc/hde/identify also crashes the machine. But more > important: Enabling the Promise-Bios (aka ATA100-Bios) again solves all > troubles. So it's not taskfile related in any way, it's a incomplete > initialization of the Promise chip in the kernel driver. > > Thanks for all the support, now I know that my drives are still healthy ;-) > > -- > Georg Acher, acher@... > http://wwwbode.in.tum.de/~acher > "Oh no, not again !" The bowl of petunias > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Smartmontools-support mailing list > Smartmontools-support@... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support >

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Georg Acher <acher@in...> - 2003-01-06 16:57 On Mon, Jan 06, 2003 at 09:56:28AM -0600, Bruce Allen wrote: > Georg, > > I'm glad that this is sorted out. Me too :-) > I want to modify the smartmontools WARNING file to help users overcome > this problem. I'll put in "Enable the Promise-BIOS (ATA100-BIOS) or the > machine will hang". But please tell me if this is not the right thing to > say, or if I should say more. That should be enough. Alernatively (the luxury version ;-), you can check /for proc/ide/pdc202xx in the program, issue a warning and continue after a small delay to give X the chance for a screen sync... -- Georg Acher, acher@... http://wwwbode.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

Re: [Smartmontools-support]Hard lockup for smartctl and Promise 20265(+ide-taskfile?) From: Bruce Allen <ballen@gr...> - 2003-01-06 17:18 Georg, > That should be enough. Alernatively (the luxury version ;-), you can check > /for proc/ide/pdc202xx in the program, issue a warning and continue after a > small delay to give X the chance for a screen sync... Can you send me a diff or code patch? Bruce

8 messages have been excluded from this view by a project administrator.