Custom Query (1111 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (25 - 27 of 1111)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Ticket Resolution Summary Owner Reporter
#23 fixed strict-aliasing warnings from gcc 4.4.1 on Linux x86_64 somebody Christian Franke
Description

Build from smartmontools-5.39-rc.tar.gz (r2990) with gcc 4.4.1:

g++ [...] -g -O2 -Wall -W [...] -c -o os_linux.o os_linux.cpp os_linux.cpp: In member function 'bool os_linux::linux_megaraid_device::megasas_cmd(int, void*, int, void*, int, void*, int)': os_linux.cpp:1108: warning: dereferencing pointer 'pthru' does break strict-aliasing rules [...] os_linux.cpp:1079: warning: dereferencing pointer 'pthru' does break strict-aliasing rules os_linux.cpp:1078: note: initialized from here

(source:trunk/smartmontools/os_linux.cpp@2990#L1069)

#47 fixed strange disk count when dealing with external cciss arrays somebody anonymous
Description

I have 2 MSA arrays off of my system, each with 28 disks. I also have the internal smart array on my system, with a variable number of disks.

When I run my smartctl, I do have to enter -d cciss,{disk_number} /dev/cciss/cXd0. This is expected and makes sense to me, somewhat.

Running smartctl -d cciss,7 gets me the 8th disk in the array from controller 0, as I understand it (cciss,0-7 all return good values). This makes sense to me, too.

The next controller starts the weirdness. Running smartctl -d cciss,28 /dev/cciss/c1d0 gets me the 28th disk of the first external array (I think). I get values for cciss,0-28, which means I get 29 values from 28 disks. Then, running smartctl -d cciss,29 /dev/cciss/c2d0 gets me the 28th disk of the second external array (again, I think). I get values for cciss,0-29, meaning I get 30 values for 28 disks.

My assumption is that some of these are actually reporting on, say, the bus of the array, not just the disks. So, how can I know what is disk response, and what isn't?

#12 wontfix smartmontools: In Self-test log, LifeTime wraps at 65536 hours somebody Giuseppe Iuculano
Description

smartctl -a gives here:

[...] ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE [...]

9 Power_On_Hours 0x0012 001 001 000 Old_age Always - 66120

[...] SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime?(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 572 - # 2 Short offline Completed without error 00% 548 - # 3 Short offline Completed without error 00% 524 - # 4 Short offline Completed without error 00% 500 - # 5 Short offline Completed without error 00% 476 - # 6 Short offline Completed without error 00% 452 - # 7 Short offline Completed without error 00% 428 - # 8 Short offline Completed without error 00% 404 - # 9 Short offline Completed without error 00% 380 - #10 Short offline Completed without error 00% 356 - #11 Short offline Completed without error 00% 332 - #12 Short offline Completed without error 00% 308 - #13 Short offline Completed without error 00% 284 - #14 Short offline Completed without error 00% 260 - #15 Short offline Completed without error 00% 236 - #16 Short offline Completed without error 00% 212 - #17 Short offline Completed without error 00% 188 - #18 Short offline Completed without error 00% 164 - #19 Short offline Completed without error 00% 140 - #20 Short offline Completed without error 00% 116 - #21 Short offline Completed without error 00% 92 -

As you can see, in the SMART attributes, the life time (Power_On_Hours) is OK: 66120. But in the log, it has wrapped at 65536.

Found in 5.38 and svn revision 2879 Original bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535298

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Note: See TracQuery for help on using queries.