From: <kn...@mo...> - 2002-11-21 17:06:02
|
On Tue, 19 Nov 2002, Bruce Allen wrote: >It looks like the sourceforge CVS stuff may finally be getting sorted >out.... though I am still not sure if you have CVS access. Have you tried >recently? > >Also, I was curious if you'd made any further progress in understanding >the scsi segv problem that you were having with both smartmontools and >smartsuite... Well, I just committed a fix... that should answer both your questions, I think :) (megaraid-specific problem - it returns a blank answer to the mode_sense command - just zeros out the buffer. And a response length of zero is rather invalid. Worked around it.) In any event, by reading the megaraid driver, I've discovered that smart is entirely useless on this device's logical drives, AFAICT. It just returns "SUCCESS" to all mode_sense commands, no matter what. Oh well. -- Erik I. Bolsø | email: <knan at mo.himolde.no> The UNIX philosophy basically involves giving you enough rope to hang yourself. And then a couple of feet more, just to be sure. |
From: <kn...@mo...> - 2002-11-21 21:18:21
|
On Thu, 21 Nov 2002, Bruce Allen wrote: >Hi Erik, >> >Also, I was curious if you'd made any further progress in understanding >> >the scsi segv problem that you were having with both smartmontools and >> >smartsuite... >> >> Well, I just committed a fix... that should answer both your >> questions, I think :) > >Thank you. > >There is something that I am confused about in your fix. The function >that you fixed (modeselect()) is called in only one place: the function >scsiSmartModePage1CHandler(), line 457 of scsicmds.c. > >When called the last argument of modeselect is a pointer to >char tBuf[CDB_6_MAX_DATA_SIZE]. Yet with your modification, modeselect >writes to this array, starting from >tBuf[CDB_6_HDR_SIZE +MODE_DATA_HDR_SIZE] >and ending at tBuf[CDB_6_HDR_SIZE+CDB_6_MAX_DATA_SIZE-1]. >So it appears to me that it writes beyond the end of the array char tBuf >in scsiSmartModePage1CHandler. > >Could you please help me to understand this? In the previous version of >the code the amount of data written depended upon what was returned by >modesense() in scsiSmartModePage1CHandler. No, we copy _into_ the tbuf defined locally in modeselect. Which we allocate there and then. And then we send that tBuf to the scsi device as a command. MODE_SELECT is sending data to the device, MODE_SENSE is reading data from it. Let's see. We allocate an array of size 256+16 (CDB_6_MAX_DATA_SIZE + CDB_6_HDR_SIZE) on the stack. Then, at offset 16+12 (CDB_6_HDR_SIZE + MODE_DATA_HDR_SIZE) in the array, we copy 256-12 (CDB_6_MAX_DATA_SIZE - MODE_DATA_HDR_SIZE) bytes. As far as I can tell from simple arithmetic, no overflow of the array. And the pbuf we read from is CDB_MAX_DATA_SIZE long, 256, allocated in ModePage1CHandler. So no overflow on reading either, as far as I can tell. -- Erik I. Bolsø | email: <knan at mo.himolde.no> The UNIX philosophy basically involves giving you enough rope to hang yourself. And then a couple of feet more, just to be sure. |
From: Bruce A. <ba...@gr...> - 2002-11-21 21:29:28
|
> >Could you please help me to understand this? In the previous version of > >the code the amount of data written depended upon what was returned by > >modesense() in scsiSmartModePage1CHandler. > > No, we copy _into_ the tbuf defined locally in modeselect. Which we > allocate there and then. And then we send that tBuf to the scsi device as > a command. MODE_SELECT is sending data to the device, MODE_SENSE is Of course, you are right. I was concerned about reading past the end of pbuf in the memcpy but of course you start at pBuf + MODE_DATA_HDR_SIZE and read to pBuf + MODE_DATA_HDR_SIZE + (CDB_6_MAX_DATA_SIZE - MODE_DATA_HDR_SIZE)-1, so all is well. I need more sleep, more coffee, or both... [By the way, I've apparently introduced an obscure bug in smartd.8. Any idea what this means? smartd.8:245: a node is not allowed in a name smartd.8:246: a node is not allowed in a name Cheers, Bruce |
From: udo <ud...@ya...> - 2002-12-03 08:59:44
|
Hello, I have two IBM 20G ATA disks (IC35L020AVER07-0) in my P60. I am monitoring the temperatures of the disks via snmpd and mrtg. I noticed the temperature reading goes _UP_ when I remove the top of the case (it's a Tulip DT5/60) and goes down when I put the top of the case back. I use this tiny script: #!/bin/sh /usr/sbin/smartctl -v /dev/hd$1|/bin/grep Temperature_Celsius|/usr/bin/cut -b 77-80 It's started with either a or c as parameter. Could someone explain why this happens? Is the temerature reading really a temperature in degrees Celsius with these disks? There's no special cooling in the machine except the CPU fan and the fan in the PSU. How come the values go up when I open the case? Any ideas? Udo __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
From: Camille D. <dom...@cs...> - 2002-12-03 09:22:45
|
Hi, On Tue, Dec 03, 2002 at 12:59:37AM -0800, udo wrote: > There's no special cooling in the machine except the > CPU fan and the fan in the PSU. > How come the values go up when I open the case? > Any ideas? same here. i guess it's because the airflow pulled over the disks by the PSU-fan is better when the case is closed. -- Camille |
From: Bruce A. <ba...@gr...> - 2002-12-03 10:49:06
|
Hi Udo, > I have two IBM 20G ATA disks (IC35L020AVER07-0) in my P60. I am > monitoring the temperatures of the disks via snmpd and mrtg. I noticed > the temperature reading goes _UP_ when I remove the top of the case > (it's a Tulip DT5/60) and goes down when I put the top of the case > back. Interesting. > Could someone explain why this happens? Is the temerature reading > really a temperature in degrees Celsius with these disks? There's no > special cooling in the machine except the CPU fan and the fan in the > PSU. How come the values go up when I open the case? I really am not sure. I don't have any direct experience with your IBM disk though I have studied some similar ones http://smartmontools.sourceforge.net/examples/IC35L120AVVA07-0-1.txt In the IBM disks that we have studied, the temperature indication goes up and down as it should. One comment: are you sure that opening the case does not REDUCE the airflow over the disk? This could cause it to heat. If you case is the kind where air is pulled in at the front near the disk drive, this might be what is happening. I'd suggest a simple experiment to see if the temperature reported by smartctl is correct or not. Get an additional cooling fan and orient it to blow air directly over the disk, then compare temperatures with and without the fan. Or something similar. Cheers, Bruce |
From: Bruce A. <ba...@gr...> - 2002-11-21 20:42:53
|
Hi Erik, > >Also, I was curious if you'd made any further progress in understanding > >the scsi segv problem that you were having with both smartmontools and > >smartsuite... > > Well, I just committed a fix... that should answer both your > questions, I think :) Thank you. There is something that I am confused about in your fix. The function that you fixed (modeselect()) is called in only one place: the function scsiSmartModePage1CHandler(), line 457 of scsicmds.c. When called the last argument of modeselect is a pointer to char tBuf[CDB_6_MAX_DATA_SIZE]. Yet with your modification, modeselect writes to this array, starting from tBuf[CDB_6_HDR_SIZE +MODE_DATA_HDR_SIZE] and ending at tBuf[CDB_6_HDR_SIZE+CDB_6_MAX_DATA_SIZE-1]. So it appears to me that it writes beyond the end of the array char tBuf in scsiSmartModePage1CHandler. Could you please help me to understand this? In the previous version of the code the amount of data written depended upon what was returned by modesense() in scsiSmartModePage1CHandler. Cheers, Bruce |