On Sun, 7 May 2017, Andreas Hartmann wrote:
> > Therefore there's no disadvantage in saying that the media is not
> > removable. That's what the patch below does.
>
> The patch achieved the goal: it's working perfectly now. No more
> additional entries in device manager. Just as it should!
On Sat, 6 May 2017, Andreas Hartmann wrote:
> Am 06.05.2017 um 19:27 schrieb Andreas Hartmann:
> > On 05/06/2017 at 06:43 PM Alan Stern wrote:
> >> For future tests, usbmon traces won't be useful. The patches don't
> >> make any difference to the USB traffic (other than fixing that original
> >>
On Sun, 7 May 2017, Andreas Hartmann wrote:
> Am 07.05.2017 um 04:11 schrieb Alan Stern:
> > On Sat, 6 May 2017, Andreas Hartmann wrote:
> >
> >> Am 06.05.2017 um 19:27 schrieb Andreas Hartmann:
> >>> On 05/06/2017 at 06:43 PM Alan Stern wrote:
> For future tests, usbmon traces won't be
Am 07.05.2017 um 16:06 schrieb Alan Stern:
On Sun, 7 May 2017, Andreas Hartmann wrote:
Am 07.05.2017 um 04:11 schrieb Alan Stern:
On Sat, 6 May 2017, Andreas Hartmann wrote:
Am 06.05.2017 um 19:27 schrieb Andreas Hartmann:
On 05/06/2017 at 06:43 PM Alan Stern wrote:
For future tests,
On 05/06/2017 at 06:43 PM Alan Stern wrote:
> On Sat, 6 May 2017, Andreas Hartmann wrote:
>
>> Am 06.05.2017 um 17:16 schrieb Alan Stern:
>>> On Fri, 5 May 2017, Andreas Hartmann wrote:
>>>
> Ah, I see. The card reader disconnects itself from the USB bus when
> there is no card inserted.
On Sat, 6 May 2017, Andreas Hartmann wrote:
> Am 06.05.2017 um 17:16 schrieb Alan Stern:
> > On Fri, 5 May 2017, Andreas Hartmann wrote:
> >
> >>> Ah, I see. The card reader disconnects itself from the USB bus when
> >>> there is no card inserted. This means you shouldn't even need to write
>
On Fri, 5 May 2017, Andreas Hartmann wrote:
> > Ah, I see. The card reader disconnects itself from the USB bus when
> > there is no card inserted. This means you shouldn't even need to write
> > to /sys/block/sdb/device/delete; after unmounting all you have to do is
> > remove the card. Then
On Thu, 4 May 2017, Andreas Hartmann wrote:
> Am 04.05.2017 um 20:01 schrieb Alan Stern:
> > On Thu, 4 May 2017, Andreas Hartmann wrote:
> [...]
> >> echo 1 > /sys/block/sdh/device/delete removes the device from the list
> >> of available devices. You have to replug the device again to see the
>
Am 04.05.2017 um 20:01 schrieb Alan Stern:
On Thu, 4 May 2017, Andreas Hartmann wrote:
[...]
echo 1 > /sys/block/sdh/device/delete removes the device from the list
of available devices. You have to replug the device again to see the
initial entry again.
How would that work with the card
On Thu, 4 May 2017, Andreas Hartmann wrote:
> On 05/03/2017 at 08:10 PM, Alan Stern wrote:
> > On Wed, 3 May 2017, Andreas Hartmann wrote:
> >
> The remove part should start in usb-ene-3.log.gz with
>
> [ 4261.261188] *** thread awakened
> >>>
> >>> Starting from that point, the
On 05/03/2017 at 08:10 PM, Alan Stern wrote:
> On Wed, 3 May 2017, Andreas Hartmann wrote:
>
The remove part should start in usb-ene-3.log.gz with
[ 4261.261188] *** thread awakened
>>>
>>> Starting from that point, the log file shows four apparently successful
>>> writes,
On Wed, 3 May 2017, Andreas Hartmann wrote:
> >> The remove part should start in usb-ene-3.log.gz with
> >>
> >> [ 4261.261188] *** thread awakened
> >
> > Starting from that point, the log file shows four apparently successful
> > writes, followed by what looks like a re-scan of the device and
On 05/01/2017 at 10:58 PM, Alan Stern wrote:
> On Wed, 26 Apr 2017, Andreas Hartmann wrote:
>
>> On 04/24/2017 at 10:39 PM Alan Stern wrote:
>>> 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:
On Wed, 26 Apr 2017, Andreas Hartmann wrote:
> On 04/24/2017 at 10:39 PM Alan Stern wrote:
> > 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
On 04/24/2017 at 10:39 PM Alan Stern wrote:
> On Sun, 23 Apr 2017, Andreas Hartmann wrote:
>
>> Am 23.04.2017 um 18:09 schrieb Alan Stern:
>> 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
>>
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
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" ...
On Fri, 21 Apr 2017, Andreas Hartmann wrote:
> Here it goes:
>
> [ 337.698916] usb 1-1.1: new high-speed USB device number 3 using ehci-pci
> [ 337.808695] usb 1-1.1: New USB device found, idVendor=0cf2, idProduct=6250
> [ 337.808702] usb 1-1.1: New USB device strings: Mfr=1, Product=2,
>
Am 21.04.2017 um 20:53 schrieb Alan Stern:
On Fri, 21 Apr 2017, Andreas Hartmann wrote:
Same here. So the reason usb_stor_set_xfer_buf() wasn't working is
because it never got called!
Knowing that, it's easy to see where the bug is. It's a completely
different issue from the bad DMA
On Fri, 21 Apr 2017, Andreas Hartmann wrote:
> > Same here. So the reason usb_stor_set_xfer_buf() wasn't working is
> > because it never got called!
> >
> > Knowing that, it's easy to see where the bug is. It's a completely
> > different issue from the bad DMA problem. In fact, I'm surprised
On Thu, 20 Apr 2017, Andreas Hartmann wrote:
> >> Apr 19 19:25:39 notebook2 kernel: scsi host6: scsi scan: INQUIRY result
> >> too short (5), using 36
> >
> > But that is wrong! Even though it's for a working test. It means the
> > usb_stor_set_xfer_buf() subroutine isn't doing what it should.
Am 21.04.2017 um 16:48 schrieb Alan Stern:
On Thu, 20 Apr 2017, Andreas Hartmann wrote:
Apr 19 19:25:39 notebook2 kernel: scsi host6: scsi scan: INQUIRY result too
short (5), using 36
But that is wrong! Even though it's for a working test. It means the
usb_stor_set_xfer_buf() subroutine
Am 19.04.2017 um 23:07 schrieb Alan Stern:
On Wed, 19 Apr 2017, Andreas Hartmann wrote:
Am 19.04.2017 um 17:49 schrieb Alan Stern:
On Tue, 18 Apr 2017, Andreas Hartmann wrote:
Am 18.04.2017 um 21:31 schrieb Alan Stern:
On Mon, 17 Apr 2017, Andreas Hartmann wrote:
Good start, but there
On Wed, 19 Apr 2017, Andreas Hartmann wrote:
> Am 19.04.2017 um 17:49 schrieb Alan Stern:
> > On Tue, 18 Apr 2017, Andreas Hartmann wrote:
> >
> >> Am 18.04.2017 um 21:31 schrieb Alan Stern:
> >>> On Mon, 17 Apr 2017, Andreas Hartmann wrote:
> >>>
> > Good start, but there are five (!) other
Am 19.04.2017 um 17:49 schrieb Alan Stern:
On Tue, 18 Apr 2017, Andreas Hartmann wrote:
Am 18.04.2017 um 21:31 schrieb Alan Stern:
On Mon, 17 Apr 2017, Andreas Hartmann wrote:
Good start, but there are five (!) other places in this driver where
the same bug occurs, at lines 904, 1350, 1577,
On Tue, 18 Apr 2017, Andreas Hartmann wrote:
> Am 18.04.2017 um 21:31 schrieb Alan Stern:
> > On Mon, 17 Apr 2017, Andreas Hartmann wrote:
> >
> >>> Good start, but there are five (!) other places in this driver where
> >>> the same bug occurs, at lines 904, 1350, 1577, 2088, and 2157. Would
>
Am 18.04.2017 um 21:31 schrieb Alan Stern:
On Mon, 17 Apr 2017, Andreas Hartmann wrote:
Good start, but there are five (!) other places in this driver where
the same bug occurs, at lines 904, 1350, 1577, 2088, and 2157. Would
you like to fix them too?
Maybe it would be easier for the driver
On Mon, 17 Apr 2017, Andreas Hartmann wrote:
> > Good start, but there are five (!) other places in this driver where
> > the same bug occurs, at lines 904, 1350, 1577, 2088, and 2157. Would
> > you like to fix them too?
> >
> > Maybe it would be easier for the driver to allocate a single
On 04/17/2017 at 09:10 PM, Alan Stern wrote:
> On Mon, 17 Apr 2017, Greg KH wrote:
>
>> On Mon, Apr 17, 2017 at 11:28:44AM +0200, Andreas Hartmann wrote:
>>> Hello!
>>>
>>> Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
>>> CONFIG_VMAP_STACK is disabled.
>>>
>>> I would be glad if
On Mon, 17 Apr 2017, Greg KH wrote:
> On Mon, Apr 17, 2017 at 11:28:44AM +0200, Andreas Hartmann wrote:
> > Hello!
> >
> > Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
> > CONFIG_VMAP_STACK is disabled.
> >
> > I would be glad if it would be fixed.
>
> Ah, nice catch, thanks
On Mon, Apr 17, 2017 at 11:28:44AM +0200, Andreas Hartmann wrote:
> Hello!
>
> Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
> CONFIG_VMAP_STACK is disabled.
>
> I would be glad if it would be fixed.
Ah, nice catch, thanks for finding this.
Does the patch below fix this for
Hello!
Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
CONFIG_VMAP_STACK is disabled.
I would be glad if it would be fixed.
Thanks,
kind regards,
Andreas
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: new high-speed USB device number 3
using ehci-pci
Apr 15 17:58:54 notebook2
32 matches
Mail list logo
