On Sun, 23 Apr 2017, Andreas Hartmann wrote: > Am 23.04.2017 um 18:09 schrieb Alan Stern: > > On Sat, 22 Apr 2017, Andreas Hartmann wrote: > > > >>> In the meanwhile, I see another problem. The SCSI residue value is > >>> getting overwritten when new firmware is sent to the device. Like I said > >>> before, it's amazing this driver has ever worked. > >> > >> It depends on how you define "worked" ... > > > > How well _did_ it work in the past? > > As you already could see it: sometimes it has been working, sometimes > not. It's been just chance. I was hoping to get it fixed this way. > > Some time ago, there was a OS driver provided by the manufacturer (?) > (keucr), which worked without any problem (for me). But this driver was > removed in 3.17 [1] and replaced by this one. This driver _never_ worked > reliably.
Ah. > I applied this new patch, too and attached the newly created debugs. But > first of all: you are great! The loading of the SD card now works as > expected! This is covered by the logfiles usb-ene-2*. It contains the > physical removing w/o loading the filesystem before (i.e. w/o mount / > unmount and remove procedure by software before) Well, the log does show that the patch wasn't quite correct. Below is an updated version. > The second pair of logfiles usb-ene-3* covers a *new* problem during > removing of SD cards via software after mount / umount. The problem is, > that on removing it via GUI, suddenly *3* device entries appear, which > could be activated (the same as the initial entry). After a few seconds, > 2 of them disappeared again and one stays. This happens with two > different SD cards here, another card doesn't show this problem. > > I would be very glad if you could fix this hopefully last issue, too :-) > (if it is a problem at all). It's possible that the updated patch will help with all those notifications. At least, the sense data should now be correct. As for the 3 device entries, I'm not sure where to look for them in your logs. > This is an example of simple logoutput during removing: ... > Apr 23 20:12:09 notebook2 kernel: sdb: sdb1 sdb2 Unless this is what you mean? Aren't these devices the same as you get when you first plug in the device? This could simply be the result of the wrong error code causing the GUI to scan the device again. Alan Stern > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: ioctl_internal_command return > code = 8070000 > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: Sense Key : Hardware Error > [current] > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: Add. Sense: No additional sense > information > Apr 23 20:12:09 notebook2 systemd[1]: Stopping LVM2 PV scan on device 8:18... > Apr 23 20:12:09 notebook2 systemd[1]: Stopped LVM2 PV scan on device 8:18. > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: ioctl_internal_command return > code = 8070000 > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: Sense Key : Hardware Error > [current] > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: Add. Sense: No additional sense > information > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: ioctl_internal_command return > code = 8070000 > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: Sense Key : Hardware Error > [current] > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: Add. Sense: No additional sense > information > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: ioctl_internal_command return > code = 8070000 > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: Sense Key : Hardware Error > [current] > Apr 23 20:12:09 notebook2 kernel: sd 6:0:0:0: Add. Sense: No additional sense > information > Apr 23 20:12:09 notebook2 systemd[1]: Starting LVM2 PV scan on device 8:18... > Apr 23 20:12:09 notebook2 systemd[1]: Started LVM2 PV scan on device 8:18. > Apr 23 20:12:10 notebook2 kernel: sd 6:0:0:0: ioctl_internal_command return > code = 8070000 > Apr 23 20:12:10 notebook2 kernel: sd 6:0:0:0: Sense Key : Hardware Error > [current] > Apr 23 20:12:10 notebook2 kernel: sd 6:0:0:0: Add. Sense: No additional sense > information > Apr 23 20:13:01 notebook2 kernel: usb 1-1.1: USB disconnect, device number 3 > Apr 23 20:13:01 notebook2 systemd[1]: Stopping LVM2 PV scan on device 8:18... > Apr 23 20:13:01 notebook2 systemd[1]: Stopped LVM2 PV scan on device 8:18. > > > > Thanks! > Regards, > Andreas > > > [1] http://lxr.free-electrons.com/source/drivers/staging/keucr/?v=3.16 Index: usb-4.x/drivers/usb/storage/ene_ub6250.c =================================================================== --- usb-4.x.orig/drivers/usb/storage/ene_ub6250.c +++ usb-4.x/drivers/usb/storage/ene_ub6250.c @@ -95,12 +95,12 @@ static struct us_unusual_dev ene_ub6250_ #define REG_HW_TRAP1 0xFF89 /* SRB Status */ -#define SS_SUCCESS 0x00 /* No Sense */ -#define SS_NOT_READY 0x02 -#define SS_MEDIUM_ERR 0x03 -#define SS_HW_ERR 0x04 -#define SS_ILLEGAL_REQUEST 0x05 -#define SS_UNIT_ATTENTION 0x06 +#define SS_SUCCESS 0x000000 /* No Sense */ +#define SS_NOT_READY 0x023A00 /* Medium not present */ +#define SS_MEDIUM_ERR 0x031100 /* Unrecovered read error */ +#define SS_HW_ERR 0x040800 /* Communication failure */ +#define SS_ILLEGAL_REQUEST 0x052000 /* Invalid command */ +#define SS_UNIT_ATTENTION 0x062900 /* Reset occurred */ /* ENE Load FW Pattern */ #define SD_INIT1_PATTERN 1 @@ -584,6 +584,22 @@ static int ene_send_scsi_cmd(struct us_d return USB_STOR_TRANSPORT_GOOD; } +static int do_scsi_request_sense(struct us_data *us, struct scsi_cmnd *srb) +{ + struct ene_ub6250_info *info = (struct ene_ub6250_info *) us->extra; + unsigned char buf[18]; + + memset(buf, 0, 18); + buf[0] = 0x70; /* Current error */ + buf[2] = info->SrbStatus >> 16; /* Sense key */ + buf[7] = 10; /* Additional length */ + buf[12] = info->SrbStatus >> 8; /* ASC */ + buf[13] = info->SrbStatus; /* ASCQ */ + + usb_stor_set_xfer_buf(buf, sizeof(buf), srb); + return USB_STOR_TRANSPORT_GOOD; +} + static int sd_scsi_test_unit_ready(struct us_data *us, struct scsi_cmnd *srb) { struct ene_ub6250_info *info = (struct ene_ub6250_info *) us->extra; @@ -2227,11 +2243,13 @@ static int sd_scsi_irp(struct us_data *u int result; struct ene_ub6250_info *info = (struct ene_ub6250_info *)us->extra; - info->SrbStatus = SS_SUCCESS; switch (srb->cmnd[0]) { case TEST_UNIT_READY: result = sd_scsi_test_unit_ready(us, srb); break; /* 0x00 */ + case REQUEST_SENSE: + result = do_scsi_request_sense(us, srb); + break; /* 0x03 */ case INQUIRY: result = sd_scsi_inquiry(us, srb); break; /* 0x12 */ @@ -2257,6 +2275,8 @@ static int sd_scsi_irp(struct us_data *u result = USB_STOR_TRANSPORT_FAILED; break; } + if (result == USB_STOR_TRANSPORT_GOOD) + info->SrbStatus = SS_SUCCESS; return result; } @@ -2267,11 +2287,14 @@ static int ms_scsi_irp(struct us_data *u { int result; struct ene_ub6250_info *info = (struct ene_ub6250_info *)us->extra; - info->SrbStatus = SS_SUCCESS; + switch (srb->cmnd[0]) { case TEST_UNIT_READY: result = ms_scsi_test_unit_ready(us, srb); break; /* 0x00 */ + case REQUEST_SENSE: + result = do_scsi_request_sense(us, srb); + break; /* 0x03 */ case INQUIRY: result = ms_scsi_inquiry(us, srb); break; /* 0x12 */ @@ -2292,6 +2315,8 @@ static int ms_scsi_irp(struct us_data *u result = USB_STOR_TRANSPORT_FAILED; break; } + if (result == USB_STOR_TRANSPORT_GOOD) + info->SrbStatus = SS_SUCCESS; return result; } -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
