Custom Query (1546 matches)
Results (400 - 402 of 1546)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #831 | fixed | FoxLine flssd240x4se is not in database | ||
| Description |
Drive is FoxLine SSD, model flssd240x4se |
|||
| #466 | invalid | FreeBSD 9.3: extended self-test log lifetime timestamp does not match reality | ||
| Description |
At some point in time (I'm not sure when), it looks like either smartmontools or FreeBSD (I'm not sure which) appears to have begun using the wrong time when doing self-tests. More precisely: when a self-test is run (ex. smartctl -t short /dev/ada0), the completion time as shown in the SMART self-test log is extremely distant/far off compared to attribute 9 Power_On_Hours. This problem is reproducible across multiple drive models (Samsung SSD 840 EVO, WD3003FZEX, WD1003FZEX). I cannot reproduce this problem on Windows XP Pro SP3 (32-bit) using smartmontools 6.3. I'll provide some hard data, including -r ataioctl,2 output, from multiple drives on a system, and show actual proof of this problem. I keep going back and forth trying to figure out if this is a smartmontools bug or a FreeBSD CAM/kernel bug (and if it's the latter, it manifests itself in an extremely bizarre way). Rolling back to smartmontools 6.2 does not fix the problem. |
|||
| #29 | fixed | FreeBSD: cam_close_device() called twice | ||
| Description |
Function: os_freebsd.cpp/freebsd_smart_interface::autodetect_smart_device() line 1800 Relevant part of the code: 1796 // now check if we are working with USB device, see umass.c
1797 if(strcmp(ccb.cpi.dev_name,"umass-sim") == 0) { // USB device found
1798 usbdevlist(bus,vendor_id, product_id, version);
1799 int bus=ccb.cpi.unit_number; // unit_number will match umass number
1800 cam_close_device(cam_dev);
1801 if(usbdevlist(bus,vendor_id, product_id, version)){
1802 const char * usbtype = get_usb_dev_type_by_id(vendor_id, product_id, version);
1803 if (!usbtype)
1804 return false;
1805 return get_sat_device(usbtype, new freebsd_scsi_device(this, name, ""));
1806 }
1807 }
1808 #if FREEBSDVER > 800100
1809 // check if we have ATA device connected to CAM (ada)
1810 if(ccb.cpi.protocol == PROTO_ATA){
1811 cam_close_device(cam_dev);
1812 return new freebsd_atacam_device(this, name, "");
1813 }
1814 #endif
1815 // close cam device, we don`t need it anymore
1816 cam_close_device(cam_dev);
The first cam_close_device(cam_dev) is called within if(strcmp(ccb.cpi.dev_name,"umass-sim") == 0) block. But such block may not end with return In such case the second cam_close_device(cam_dev) will be called on line 1811 or 1816. Double-close may cause several problems including memory corruption. It seems to be a simple typo. It's Alex's code (AFAIK), so I hope he can correct it easily. If he will not repair it then I will assign this ticket later to myself. Credits to Axel Beckert and Petr Salinger for it's help with problem identification and partial analysis. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561113 |
|||
