* Amazon Kindle disconnect after Synchronize Cache
@ 2021-03-05 16:54 Matthias Schwarzott
2021-03-05 19:14 ` Alan Stern
0 siblings, 1 reply; 33+ messages in thread
From: Matthias Schwarzott @ 2021-03-05 16:54 UTC (permalink / raw)
To: linux-usb, usb-storage; +Cc: hirofumi
Hi folks,
I have an issue with my Amazon Kindle. Since some time the device
disconnects 2 seconds after a sync command sent via USB.
See also this matching bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=203973
My current workaround is this udev-rule:
SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="disk",
ENV{ID_VENDOR}=="Kindle", RUN+="/bin/bash -c 'echo write\ through >
/sys/block/%k/queue/write_cache'"
But I like to find a proper solution.
I did various recordings of usb-traffic with wireshark on linux and windows.
On windows, the device does not disconnect after the "Synchronize Cache"
command.
One major difference I noticed looking at service answer time statistics:
Windows sends a lot more requests of type "Test Unit Ready".
* Windows: 6385 calls
* linux: 71 calls
After most of the "Synchronize Cache" commands on windows there was
directly a following "WRITE" command. It seems WRITE commands avoid the
disconnect.
But sending a plain "Synchronize Cache" under windows (8.1 and 10) does
not trigger the disconnect.
Windows:
1583 14.891478 host 1.6.1 USBMS 58 SCSI: Synchronize Cache(10) LUN: 0x00
(LBA: 0x00000000, Len: 0)
1584 14.891595 1.6.1 host USB 27 URB_BULK out
1585 14.891613 host 1.6.1 USB 27 URB_BULK in
1586 14.896866 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Synchronize
Cache(10)) (Good)
1589 15.687209 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
1590 15.687353 1.6.1 host USB 27 URB_BULK out
1591 15.687358 host 1.6.1 USB 27 URB_BULK in
1592 15.687405 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
Ready) (Good)
1713 16.699689 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
1714 16.699820 1.6.1 host USB 27 URB_BULK out
1715 16.699825 host 1.6.1 USB 27 URB_BULK in
1716 16.699915 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
Ready) (Good)
1717 17.709334 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
1718 17.709547 1.6.1 host USB 27 URB_BULK out
1719 17.709552 host 1.6.1 USB 27 URB_BULK in
1720 17.709586 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
Ready) (Good)
1721 18.712864 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
1722 18.713081 1.6.1 host USB 27 URB_BULK out
1723 18.713086 host 1.6.1 USB 27 URB_BULK in
1724 18.713148 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
Ready) (Good)
1741 19.735245 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
1742 19.735410 1.6.1 host USB 27 URB_BULK out
1743 19.735415 host 1.6.1 USB 27 URB_BULK in
1744 19.735474 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
Ready) (Good)
1811 20.747477 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
1812 20.747699 1.6.1 host USB 27 URB_BULK out
1813 20.747704 host 1.6.1 USB 27 URB_BULK in
1814 20.747766 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
Ready) (Good)
1905 21.755419 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
1906 21.755579 1.6.1 host USB 27 URB_BULK out
1907 21.755584 host 1.6.1 USB 27 URB_BULK in
1908 21.755674 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
Ready) (Good)
1911 22.769205 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
1912 22.769355 1.6.1 host USB 27 URB_BULK out
1913 22.769360 host 1.6.1 USB 27 URB_BULK in
1914 22.769415 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
Ready) (Good)
How can I get further on this topic?
Thanks
Matthias
linux:
===========================================================================
SCSI Service Antwortzeit - kindle-linux-copy.pcap:
Index Procedure Calls Min SRT (s) Max SRT (s) Avg SRT (s) Sum SRT (s)
---------------------------------------------------------------------------
SBC (disk)
Inquiry 18 1 0.000742 0.000742 0.000742 0.000742
Mode Sense(6) 26 6 0.104194 0.110284 0.108607
0.651640
Prevent/Allow Medium Removal 30 10 0.000115 0.015012
0.002431 0.024309
Read Capacity(10) 37 3 0.000631 0.001004 0.000835
0.002506
Read(10) 40 2200 0.000136 0.020928 0.002452 5.393555
Request Sense 3 27 0.000295 0.003102 0.001022
0.027604
Synchronize Cache(10) 53 6 0.000223 2.703190
0.654663 3.927976
Test Unit Ready 0 71 0.000081 0.007955 0.000816
0.057908
Write(10) 42 195 0.001204 0.236517 0.022452 4.378117
SBC (disk)
---------------------------------------------------------------------------
windows:
===========================================================================
SCSI Service Antwortzeit - Kindle-sideload-win81.pcapng:
Index Procedure Calls Min SRT (s) Max SRT (s) Avg SRT (s) Sum SRT (s)
---------------------------------------------------------------------------
SBC (disk)
Inquiry 18 6 0.001026 0.109327 0.055329 0.331972
Mode Select(6) 21 2 0.001499 0.002851 0.002175
0.004350
Mode Sense(6) 26 8 0.102380 0.116633 0.108400
0.867199
Prevent/Allow Medium Removal 30 9 0.000274 0.644009
0.072284 0.650556
Read Capacity(10) 37 51 0.000144 0.109027 0.009779
0.498711
Read(10) 40 1269 0.000537 0.107562 0.003026 3.840104
Request Sense 3 19 0.000461 0.001388 0.000889
0.016893
Start Stop Unit 27 1 0.001695 0.001695 0.001695
0.001695
Synchronize Cache(10) 53 7 0.000511 0.001765
0.001052 0.007362
Test Unit Ready 0 6385 0.000090 0.083883 0.000605
3.859785
Unknown-0x%02x 35 3 0.108739 0.111119 0.109720
0.329159
Write(10) 42 303 0.001117 0.257120 0.030089 9.117113
SBC (disk)
---------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-05 16:54 Amazon Kindle disconnect after Synchronize Cache Matthias Schwarzott
@ 2021-03-05 19:14 ` Alan Stern
[not found] ` <CAL411-qf+c_CB4cL=2349QqCCYimOBCYxXbsOfLbvVYOg0294g@mail.gmail.com>
2021-03-07 5:58 ` Matthias Schwarzott
0 siblings, 2 replies; 33+ messages in thread
From: Alan Stern @ 2021-03-05 19:14 UTC (permalink / raw)
To: Matthias Schwarzott; +Cc: linux-usb, usb-storage, hirofumi
On Fri, Mar 05, 2021 at 05:54:43PM +0100, Matthias Schwarzott wrote:
> Hi folks,
>
> I have an issue with my Amazon Kindle. Since some time the device
> disconnects 2 seconds after a sync command sent via USB.
>
> See also this matching bug report:
> https://bugzilla.kernel.org/show_bug.cgi?id=203973
>
> My current workaround is this udev-rule:
> SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="disk",
> ENV{ID_VENDOR}=="Kindle", RUN+="/bin/bash -c 'echo write\ through >
> /sys/block/%k/queue/write_cache'"
>
> But I like to find a proper solution.
>
> I did various recordings of usb-traffic with wireshark on linux and windows.
>
> On windows, the device does not disconnect after the "Synchronize Cache"
> command.
>
> One major difference I noticed looking at service answer time statistics:
> Windows sends a lot more requests of type "Test Unit Ready".
> * Windows: 6385 calls
> * linux: 71 calls
It's generally well known that Windows issues lots and lots of redundant
commands to USB storage drives.
> After most of the "Synchronize Cache" commands on windows there was directly
> a following "WRITE" command. It seems WRITE commands avoid the disconnect.
>
> But sending a plain "Synchronize Cache" under windows (8.1 and 10) does not
> trigger the disconnect.
>
> Windows:
> 1583 14.891478 host 1.6.1 USBMS 58 SCSI: Synchronize Cache(10) LUN: 0x00
> (LBA: 0x00000000, Len: 0)
> 1584 14.891595 1.6.1 host USB 27 URB_BULK out
> 1585 14.891613 host 1.6.1 USB 27 URB_BULK in
> 1586 14.896866 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Synchronize
> Cache(10)) (Good)
> 1589 15.687209 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
> 1590 15.687353 1.6.1 host USB 27 URB_BULK out
> 1591 15.687358 host 1.6.1 USB 27 URB_BULK in
> 1592 15.687405 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
> Ready) (Good)
> 1713 16.699689 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
> 1714 16.699820 1.6.1 host USB 27 URB_BULK out
> 1715 16.699825 host 1.6.1 USB 27 URB_BULK in
> 1716 16.699915 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
> Ready) (Good)
> 1717 17.709334 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
> 1718 17.709547 1.6.1 host USB 27 URB_BULK out
> 1719 17.709552 host 1.6.1 USB 27 URB_BULK in
> 1720 17.709586 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
> Ready) (Good)
> 1721 18.712864 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
> 1722 18.713081 1.6.1 host USB 27 URB_BULK out
> 1723 18.713086 host 1.6.1 USB 27 URB_BULK in
> 1724 18.713148 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
> Ready) (Good)
> 1741 19.735245 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
> 1742 19.735410 1.6.1 host USB 27 URB_BULK out
> 1743 19.735415 host 1.6.1 USB 27 URB_BULK in
> 1744 19.735474 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
> Ready) (Good)
> 1811 20.747477 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
> 1812 20.747699 1.6.1 host USB 27 URB_BULK out
> 1813 20.747704 host 1.6.1 USB 27 URB_BULK in
> 1814 20.747766 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
> Ready) (Good)
> 1905 21.755419 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
> 1906 21.755579 1.6.1 host USB 27 URB_BULK out
> 1907 21.755584 host 1.6.1 USB 27 URB_BULK in
> 1908 21.755674 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
> Ready) (Good)
> 1911 22.769205 host 1.6.1 USBMS 58 SCSI: Test Unit Ready LUN: 0x00
> 1912 22.769355 1.6.1 host USB 27 URB_BULK out
> 1913 22.769360 host 1.6.1 USB 27 URB_BULK in
> 1914 22.769415 1.6.1 host USBMS 40 SCSI: Response LUN: 0x00 (Test Unit
> Ready) (Good)
Unless the Kindle advertises removable media, there doesn't seem to be
any real point to all those TEST UNIT READY commands. Unless they are
what prevents the disconnections...
> How can I get further on this topic?
Is runtime power management enabled? Maybe the Kindle disconnects
whenever the computer tries to suspend it. This typically happens 2
seconds after the last command was issued, which matches your
observations. If runtime PM is enabled, you can try disabling it.
Alternatively, a number of Linux kernel developers work for Amazon (or
at least, use email addresses ending in "@amazon.com"), as shown by the
MAINTAINERS file. Maybe one of them can get in touch with the Kindle
software development people and find the actual answer.
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Amazon Kindle disconnect after Synchronize Cache
[not found] ` <CAL411-qf+c_CB4cL=2349QqCCYimOBCYxXbsOfLbvVYOg0294g@mail.gmail.com>
@ 2021-03-06 16:07 ` Alan Stern
0 siblings, 0 replies; 33+ messages in thread
From: Alan Stern @ 2021-03-06 16:07 UTC (permalink / raw)
To: Peter Chen; +Cc: Matthias Schwarzott, USB list, usb-storage, hirofumi
On Sat, Mar 06, 2021 at 10:19:54AM +0800, Peter Chen wrote:
> On Sat, Mar 6, 2021 at 3:17 AM Alan Stern <stern@rowland.harvard.edu> wrote:
> > Is runtime power management enabled? Maybe the Kindle disconnects
> > whenever the computer tries to suspend it. This typically happens 2
> > seconds after the last command was issued, which matches your
> > observations. If runtime PM is enabled, you can try disabling it.
> >
> >
> Alan, I think you may be right. It might want to support the feature like
> kindle goes to suspend after the Windows PC
> enters suspend (but VBUS is there), the Windows PC may never suspend the
> bus if a mass storage device is connected.
That's possible. I have never tried to measure the bus activity when a
Windows host is suspended.
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-05 19:14 ` Alan Stern
[not found] ` <CAL411-qf+c_CB4cL=2349QqCCYimOBCYxXbsOfLbvVYOg0294g@mail.gmail.com>
@ 2021-03-07 5:58 ` Matthias Schwarzott
2021-03-07 15:52 ` Alan Stern
1 sibling, 1 reply; 33+ messages in thread
From: Matthias Schwarzott @ 2021-03-07 5:58 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, usb-storage, hirofumi
Am 05.03.21 um 20:14 schrieb Alan Stern:
> On Fri, Mar 05, 2021 at 05:54:43PM +0100, Matthias Schwarzott wrote:
>> One major difference I noticed looking at service answer time statistics:
>> Windows sends a lot more requests of type "Test Unit Ready".
>> * Windows: 6385 calls
>> * linux: 71 calls
>
> It's generally well known that Windows issues lots and lots of redundant
> commands to USB storage drives.
>
>
> Unless the Kindle advertises removable media, there doesn't seem to be
> any real point to all those TEST UNIT READY commands. Unless they are
> what prevents the disconnections...
>
This is kernel log from connecting:
[41709.248006] usb 3-4: new high-speed USB device number 6 using xhci_hcd
[41709.380015] usb 3-4: New USB device found, idVendor=1949,
idProduct=0004, bcdDevice= 1.00
[41709.380019] usb 3-4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[41709.380021] usb 3-4: Product: Amazon Kindle
[41709.380022] usb 3-4: Manufacturer: Amazon
[41709.380023] usb 3-4: SerialNumber: REMOVED
[41709.493988] usb-storage 3-4:1.0: USB Mass Storage device detected
[41709.494080] scsi host6: usb-storage 3-4:1.0
[41710.510122] scsi 6:0:0:0: Direct-Access Kindle Internal Storage
0100 PQ: 0 ANSI: 2
[41710.510245] sd 6:0:0:0: Attached scsi generic sg3 type 0
[41710.513059] sd 6:0:0:0: Power-on or device reset occurred
[41710.526331] sd 6:0:0:0: [sdc] Attached SCSI removable disk
[41712.629152] sd 6:0:0:0: [sdc] 6688768 512-byte logical blocks: (3.42
GB/3.19 GiB)
[41712.846353] sd 6:0:0:0: [sdc] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[41712.846357] sdc: detected capacity change from 0 to 6688768
[41712.849499] sdc: sdc1
As it prints "Attached SCSI removable disk" the device advertises
removable media.
>> How can I get further on this topic?
>
> Is runtime power management enabled? Maybe the Kindle disconnects
> whenever the computer tries to suspend it. This typically happens 2
> seconds after the last command was issued, which matches your
> observations. If runtime PM is enabled, you can try disabling it.
>
I assume this means autosuspend is not used:
# cat /sys/block/sde/device/power/control
on
# lsusb:
[...]
Bus 003 Device 017: ID 1949:0004 Lab126, Inc. Amazon Kindle 3/4/Paperwhite
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1949 Lab126, Inc.
idProduct 0x0004 Amazon Kindle 3/4/Paperwhite
bcdDevice 1.00
iManufacturer 1 Amazon
iProduct 2 Amazon Kindle
iSerial 3 REMOVED....
bNumConfigurations 1
OTG Descriptor:
bLength 3
bDescriptorType 9
bmAttributes 0x03
SRP (Session Request Protocol)
HNP (Host Negotiation Protocol)
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0023
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 Self-powered
bmAttributes 0xc0
Self Powered
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 5 Mass Storage
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Regards
Matthias
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-07 5:58 ` Matthias Schwarzott
@ 2021-03-07 15:52 ` Alan Stern
2021-03-07 16:52 ` Matthias Schwarzott
0 siblings, 1 reply; 33+ messages in thread
From: Alan Stern @ 2021-03-07 15:52 UTC (permalink / raw)
To: Matthias Schwarzott; +Cc: linux-usb, usb-storage, hirofumi
On Sun, Mar 07, 2021 at 06:58:10AM +0100, Matthias Schwarzott wrote:
> Am 05.03.21 um 20:14 schrieb Alan Stern:
> > On Fri, Mar 05, 2021 at 05:54:43PM +0100, Matthias Schwarzott wrote:
> > > One major difference I noticed looking at service answer time statistics:
> > > Windows sends a lot more requests of type "Test Unit Ready".
> > > * Windows: 6385 calls
> > > * linux: 71 calls
> >
> > It's generally well known that Windows issues lots and lots of redundant
> > commands to USB storage drives.
> >
> >
> > Unless the Kindle advertises removable media, there doesn't seem to be
> > any real point to all those TEST UNIT READY commands. Unless they are
> > what prevents the disconnections...
> >
> This is kernel log from connecting:
> [41709.248006] usb 3-4: new high-speed USB device number 6 using xhci_hcd
> [41709.380015] usb 3-4: New USB device found, idVendor=1949, idProduct=0004,
> bcdDevice= 1.00
> [41709.380019] usb 3-4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [41709.380021] usb 3-4: Product: Amazon Kindle
> [41709.380022] usb 3-4: Manufacturer: Amazon
> [41709.380023] usb 3-4: SerialNumber: REMOVED
> [41709.493988] usb-storage 3-4:1.0: USB Mass Storage device detected
> [41709.494080] scsi host6: usb-storage 3-4:1.0
> [41710.510122] scsi 6:0:0:0: Direct-Access Kindle Internal Storage
> 0100 PQ: 0 ANSI: 2
> [41710.510245] sd 6:0:0:0: Attached scsi generic sg3 type 0
> [41710.513059] sd 6:0:0:0: Power-on or device reset occurred
> [41710.526331] sd 6:0:0:0: [sdc] Attached SCSI removable disk
> [41712.629152] sd 6:0:0:0: [sdc] 6688768 512-byte logical blocks: (3.42
> GB/3.19 GiB)
> [41712.846353] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled,
> doesn't support DPO or FUA
> [41712.846357] sdc: detected capacity change from 0 to 6688768
> [41712.849499] sdc: sdc1
>
> As it prints "Attached SCSI removable disk" the device advertises removable
> media.
Yes.
> > > How can I get further on this topic?
> >
> > Is runtime power management enabled? Maybe the Kindle disconnects
> > whenever the computer tries to suspend it. This typically happens 2
> > seconds after the last command was issued, which matches your
> > observations. If runtime PM is enabled, you can try disabling it.
> >
> I assume this means autosuspend is not used:
>
> # cat /sys/block/sde/device/power/control
> on
This means autosuspend isn't used for the sde drive. But the log
extract above shows that the Kindle is sdc, not sde.
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-07 15:52 ` Alan Stern
@ 2021-03-07 16:52 ` Matthias Schwarzott
2021-03-07 16:58 ` Alan Stern
0 siblings, 1 reply; 33+ messages in thread
From: Matthias Schwarzott @ 2021-03-07 16:52 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, usb-storage, hirofumi
Am 07.03.21 um 16:52 schrieb Alan Stern:
> On Sun, Mar 07, 2021 at 06:58:10AM +0100, Matthias Schwarzott wrote:
>> Am 05.03.21 um 20:14 schrieb Alan Stern:
>>> Is runtime power management enabled? Maybe the Kindle disconnects
>>> whenever the computer tries to suspend it. This typically happens 2
>>> seconds after the last command was issued, which matches your
>>> observations. If runtime PM is enabled, you can try disabling it.
>>>
>> I assume this means autosuspend is not used:
>>
>> # cat /sys/block/sde/device/power/control
>> on
>
> This means autosuspend isn't used for the sde drive. But the log
> extract above shows that the Kindle is sdc, not sde.
>
Yes, confusing. From different boots with another usb disc not detected.
This time Kindle is sde again:
# dmesg |tail
[83709.973141] usb-storage 3-4:1.0: USB Mass Storage device detected
[83709.973226] scsi host8: usb-storage 3-4:1.0
[83711.028665] scsi 8:0:0:0: Direct-Access Kindle Internal Storage
0100 PQ: 0 ANSI: 2
[83711.028792] sd 8:0:0:0: Attached scsi generic sg5 type 0
[83711.031536] sd 8:0:0:0: Power-on or device reset occurred
[83711.046604] sd 8:0:0:0: [sde] Attached SCSI removable disk
[83713.145467] sd 8:0:0:0: [sde] 6688768 512-byte logical blocks: (3.42
GB/3.19 GiB)
[83713.364900] sd 8:0:0:0: [sde] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[83713.364906] sde: detected capacity change from 0 to 6688768
[83713.368036] sde: sde1
# cat /sys/block/sde/device/power/control
on
power/control reports the same value for all sd? devices on this system.
Matthias
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-07 16:52 ` Matthias Schwarzott
@ 2021-03-07 16:58 ` Alan Stern
2021-03-08 21:59 ` Matthias Schwarzott
0 siblings, 1 reply; 33+ messages in thread
From: Alan Stern @ 2021-03-07 16:58 UTC (permalink / raw)
To: Matthias Schwarzott; +Cc: linux-usb, usb-storage, hirofumi
On Sun, Mar 07, 2021 at 05:52:19PM +0100, Matthias Schwarzott wrote:
> This time Kindle is sde again:
>
> # dmesg |tail
> [83709.973141] usb-storage 3-4:1.0: USB Mass Storage device detected
> [83709.973226] scsi host8: usb-storage 3-4:1.0
> [83711.028665] scsi 8:0:0:0: Direct-Access Kindle Internal Storage
> 0100 PQ: 0 ANSI: 2
> [83711.028792] sd 8:0:0:0: Attached scsi generic sg5 type 0
> [83711.031536] sd 8:0:0:0: Power-on or device reset occurred
> [83711.046604] sd 8:0:0:0: [sde] Attached SCSI removable disk
> [83713.145467] sd 8:0:0:0: [sde] 6688768 512-byte logical blocks: (3.42
> GB/3.19 GiB)
> [83713.364900] sd 8:0:0:0: [sde] Write cache: enabled, read cache: enabled,
> doesn't support DPO or FUA
> [83713.364906] sde: detected capacity change from 0 to 6688768
> [83713.368036] sde: sde1
> # cat /sys/block/sde/device/power/control
> on
>
> power/control reports the same value for all sd? devices on this system.
Okay. Can you collect a usbmon trace showing the events leading up to
and including a disconnection?
Alan Stern
PS: I suspect the SYNCHRONIZE CACHE commands are correlated with the
disconnections but don't cause them. That is, I suspect the
disconnections happen when the device has been idle -- and generally the
host computer sends a SYNCHRONIZE CACHE command before idling a
removable drive.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-07 16:58 ` Alan Stern
@ 2021-03-08 21:59 ` Matthias Schwarzott
2021-03-09 15:50 ` [usb-storage] " Alan Stern
0 siblings, 1 reply; 33+ messages in thread
From: Matthias Schwarzott @ 2021-03-08 21:59 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, usb-storage, hirofumi
[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]
Am 07.03.21 um 17:58 schrieb Alan Stern:
> On Sun, Mar 07, 2021 at 05:52:19PM +0100, Matthias Schwarzott wrote:
>> This time Kindle is sde again:
>>
>> # dmesg |tail
>> [83709.973141] usb-storage 3-4:1.0: USB Mass Storage device detected
>> [83709.973226] scsi host8: usb-storage 3-4:1.0
>> [83711.028665] scsi 8:0:0:0: Direct-Access Kindle Internal Storage
>> 0100 PQ: 0 ANSI: 2
>> [83711.028792] sd 8:0:0:0: Attached scsi generic sg5 type 0
>> [83711.031536] sd 8:0:0:0: Power-on or device reset occurred
>> [83711.046604] sd 8:0:0:0: [sde] Attached SCSI removable disk
>> [83713.145467] sd 8:0:0:0: [sde] 6688768 512-byte logical blocks: (3.42
>> GB/3.19 GiB)
>> [83713.364900] sd 8:0:0:0: [sde] Write cache: enabled, read cache: enabled,
>> doesn't support DPO or FUA
>> [83713.364906] sde: detected capacity change from 0 to 6688768
>> [83713.368036] sde: sde1
>> # cat /sys/block/sde/device/power/control
>> on
>>
>> power/control reports the same value for all sd? devices on this system.
>
> Okay. Can you collect a usbmon trace showing the events leading up to
> and including a disconnection?
>
The easiest reproducer is by calling sync while having a file/the device
open (and keeping it open afterwards).
1. I recorded usbmon trace like this:
# cat /sys/kernel/debug/usb/usbmon/3u >
/tmp/connect-python-sync-disconnect-usbmon.out
2. Connect Kindle device
3. Then trigger sync with python:
# python -c "import time; import os; f = open('/dev/sde', 'r+b');
time.sleep(1); os.fsync(f); time.sleep(5)"
4. After 2 seconds Kindle disconnects (does no longer show USB-Mode screen).
5. Ctrl+c the recording
When the final sleep in the python-command is missing, the Kindle does
not disconnect.
> Alan Stern
>
> PS: I suspect the SYNCHRONIZE CACHE commands are correlated with the
> disconnections but don't cause them. That is, I suspect the
> disconnections happen when the device has been idle -- and generally the
> host computer sends a SYNCHRONIZE CACHE command before idling a
> removable drive.
>
I cannot read the usbmon trace, but wireshark displayed a command "SCSI:
Prevent/Allow Medium Removal LUN: 0x00 ALLOW" when closing the file.
So I suspect this command also counts as activity (!idle).
Matthias
[-- Attachment #2: connect-python-sync-disconnect-usbmon.out --]
[-- Type: text/plain, Size: 64524 bytes --]
ffff88810279d840 2430120125 C Ii:3:002:1 0:8 8 = 00000000 00000000
ffff88810279d840 2430120151 S Ii:3:002:1 -115:8 8 <
ffff888101fe9600 2431723988 C Ii:3:001:1 0:2048 2 = 1000
ffff888101fe9600 2431723997 S Ii:3:001:1 -115:2048 4 <
ffff888389904300 2431724006 S Ci:3:001:0 s a3 00 0000 0004 0004 4 <
ffff888389904300 2431724013 C Ci:3:001:0 0 4 = 01010100
ffff888389904300 2431724016 S Co:3:001:0 s 23 01 0010 0004 0000 0
ffff888389904300 2431724019 C Co:3:001:0 0 0
ffff888389904300 2431724020 S Ci:3:001:0 s a3 00 0000 0004 0004 4 <
ffff888389904300 2431724022 C Ci:3:001:0 0 4 = 01010000
ffff888389904300 2431750650 S Ci:3:001:0 s a3 00 0000 0004 0004 4 <
ffff888389904300 2431750660 C Ci:3:001:0 0 4 = 01010000
ffff888389904300 2431777623 S Ci:3:001:0 s a3 00 0000 0004 0004 4 <
ffff888389904300 2431777637 C Ci:3:001:0 0 4 = 01010000
ffff888389904300 2431804663 S Ci:3:001:0 s a3 00 0000 0004 0004 4 <
ffff888389904300 2431804679 C Ci:3:001:0 0 4 = 01010000
ffff888389904300 2431831640 S Ci:3:001:0 s a3 00 0000 0004 0004 4 <
ffff888389904300 2431831649 C Ci:3:001:0 0 4 = 01010000
ffff888389904300 2431831691 S Co:3:001:0 s 23 03 0004 0004 0000 0
ffff888389904300 2431831696 C Co:3:001:0 0 0
ffff888389904300 2431893622 S Ci:3:001:0 s a3 00 0000 0004 0004 4 <
ffff888389904300 2431893641 C Ci:3:001:0 0 4 = 03051000
ffff888389904300 2431893643 S Co:3:001:0 s 23 01 0014 0004 0000 0
ffff888389904300 2431893646 C Co:3:001:0 0 0
ffff888389904300 2431945683 S Ci:3:000:0 s 80 06 0100 0000 0040 64 <
ffff888389904300 2431945785 C Ci:3:000:0 0 18 = 12010002 00000040 49190400 00010102 0301
ffff888389904300 2431945787 S Co:3:001:0 s 23 03 0004 0004 0000 0
ffff888389904300 2431945793 C Co:3:001:0 0 0
ffff888389904c00 2432007640 S Ci:3:001:0 s a3 00 0000 0004 0004 4 <
ffff888389904c00 2432007650 C Ci:3:001:0 0 4 = 03051000
ffff888389904c00 2432007653 S Co:3:001:0 s 23 01 0014 0004 0000 0
ffff888389904c00 2432007658 C Co:3:001:0 0 0
ffff888389904c00 2432071642 S Ci:3:039:0 s 80 06 0100 0000 0012 18 <
ffff888389904c00 2432071718 C Ci:3:039:0 0 18 = 12010002 00000040 49190400 00010102 0301
ffff888389904c00 2432071748 S Ci:3:039:0 s 80 06 0200 0000 0009 9 <
ffff888389904c00 2432072670 C Ci:3:039:0 0 9 = 09022300 010104c0 01
ffff888389904c00 2432072674 S Ci:3:039:0 s 80 06 0200 0000 0023 35 <
ffff888389904c00 2432073685 C Ci:3:039:0 0 35 = 09022300 010104c0 01030903 09040000 02080650 05070581 02000200 07050102
ffff88814e50d9c0 2432073702 S Ci:3:039:0 s 80 06 0300 0000 00ff 255 <
ffff88814e50d9c0 2432074626 C Ci:3:039:0 0 4 = 04030904
ffff88814e50d9c0 2432074634 S Ci:3:039:0 s 80 06 0302 0409 00ff 255 <
ffff88814e50d9c0 2432075643 C Ci:3:039:0 0 28 = 1c034100 6d006100 7a006f00 6e002000 4b006900 6e006400 6c006500
ffff88814e50d9c0 2432075653 S Ci:3:039:0 s 80 06 0301 0409 00ff 255 <
ffff88814e50d9c0 2432076650 C Ci:3:039:0 0 14 = 0e034100 6d006100 7a006f00 6e00
ffff88814e50d9c0 2432076660 S Ci:3:039:0 s 80 06 0303 0409 00ff 255 <
ffff88814e50d9c0 2432077655 C Ci:3:039:0 0 34 = 22033900 30003100 37003200 32003000 32003500 31003300 34003000 47003900
ffff88814e50d9c0 2432078680 S Co:3:039:0 s 00 09 0001 0000 0000 0
ffff88814e50d9c0 2432079986 C Co:3:039:0 0 0
ffff88814e50d9c0 2432079991 S Ci:3:039:0 s 80 06 0304 0409 00ff 255 <
ffff88814e50d9c0 2432080697 C Ci:3:039:0 0 26 = 1a035300 65006c00 66002d00 70006f00 77006500 72006500 6400
ffff88814e50d9c0 2432080724 S Ci:3:039:0 s 80 06 0305 0409 00ff 255 <
ffff88814e50d9c0 2432081680 C Ci:3:039:0 0 26 = 1a034d00 61007300 73002000 53007400 6f007200 61006700 6500
ffff88814e50d0c0 2433130657 S Ci:3:039:0 s a1 fe 0000 0000 0001 1 <
ffff88814e50d0c0 2433130761 C Ci:3:039:0 0 1 = 00
ffff88814e50d0c0 2433130812 S Bo:3:039:1 -115 31 = 55534243 01000000 24000000 80000612 00000024 00000000 00000000 000000
ffff88814e50d0c0 2433130829 C Bo:3:039:1 0 31 >
ffff88810e16a840 2433130847 S Bi:3:039:1 -115 36 <
ffff88810e16a840 2433131817 C Bi:3:039:1 0 36 = 00800202 1f000000 4b696e64 6c652020 496e7465 726e616c 2053746f 72616765
ffff88814e50d0c0 2433131833 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433131858 C Bi:3:039:1 0 13 = 55534253 01000000 00000000 00
ffff88814e50d0c0 2433132006 S Bo:3:039:1 -115 31 = 55534243 02000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433133185 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433133194 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433134034 C Bi:3:039:1 0 13 = 55534253 02000000 00000000 01
ffff88814e50d0c0 2433134042 S Bo:3:039:1 -115 31 = 55534243 03000000 12000000 80000603 00000012 00000000 00000000 000000
ffff88814e50d0c0 2433134070 C Bo:3:039:1 0 31 >
ffff88823b6f7000 2433134074 S Bi:3:039:1 -115 18 <
ffff88823b6f7000 2433134820 C Bi:3:039:1 0 18 = 70000600 0000000a 00000000 28000000 0000
ffff88814e50d0c0 2433134825 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433134850 C Bi:3:039:1 0 13 = 55534253 03000000 00000000 00
ffff88814e50d0c0 2433134894 S Bo:3:039:1 -115 31 = 55534243 04000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433135884 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433135887 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433136665 C Bi:3:039:1 0 13 = 55534253 04000000 00000000 00
ffff88814e50d0c0 2433136690 S Bo:3:039:1 -115 31 = 55534243 05000000 08000000 80000a25 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433136708 C Bo:3:039:1 0 31 >
ffff88823b6f7000 2433136712 S Bi:3:039:1 -115 8 <
ffff88823b6f7000 2433137673 C Bi:3:039:1 0 8 = 00660fff 00000200
ffff88814e50d0c0 2433137685 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433137747 C Bi:3:039:1 0 13 = 55534253 05000000 00000000 00
ffff88814e50d0c0 2433137773 S Bo:3:039:1 -115 31 = 55534243 06000000 c0000000 8000061a 003f00c0 00000000 00000000 000000
ffff88814e50d0c0 2433138648 C Bo:3:039:1 0 31 >
ffff88823b6f7000 2433138651 S Bi:3:039:1 -115 192 <
ffff88823b6f7000 2433139666 C Bi:3:039:1 -121 16 = 0f000000 080a0400 ffff0000 ffffffff
ffff88814e50d0c0 2433139669 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433240328 C Bi:3:039:1 -32 0
ffff88814e50d0c0 2433240342 S Co:3:039:0 s 02 01 0000 0081 0000 0
ffff88814e50d0c0 2433240390 C Co:3:039:0 0 0
ffff88814e50d0c0 2433240394 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433240428 C Bi:3:039:1 0 13 = 55534253 06000000 b0000000 00
ffff88814e50d0c0 2433240457 S Bo:3:039:1 -115 31 = 55534243 07000000 c0000000 8000061a 003f00c0 00000000 00000000 000000
ffff88814e50d0c0 2433240472 C Bo:3:039:1 0 31 >
ffff88823b6f7000 2433240475 S Bi:3:039:1 -115 192 <
ffff88823b6f7000 2433241414 C Bi:3:039:1 -121 16 = 0f000000 080a0400 ffff0000 ffffffff
ffff88814e50d0c0 2433241419 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433350395 C Bi:3:039:1 -32 0
ffff88814e50d0c0 2433350408 S Co:3:039:0 s 02 01 0000 0081 0000 0
ffff88814e50d0c0 2433350461 C Co:3:039:0 0 0
ffff88814e50d0c0 2433350473 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433350502 C Bi:3:039:1 0 13 = 55534253 07000000 b0000000 00
ffff88814e50d0c0 2433355745 S Bo:3:039:1 -115 31 = 55534243 08000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433355761 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433355764 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433355822 C Bi:3:039:1 0 13 = 55534253 08000000 00000000 00
ffff88814e50d0c0 2433355843 S Bo:3:039:1 -115 31 = 55534243 09000000 00000000 0000061e 00000001 00000000 00000000 000000
ffff88814e50d0c0 2433355876 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433355880 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433356790 C Bi:3:039:1 0 13 = 55534253 09000000 00000000 00
ffff88814e50d0c0 2433356825 S Bo:3:039:1 -115 31 = 55534243 0a000000 00100000 80000a28 00000000 00000008 00000000 000000
ffff88814e50d0c0 2433356843 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433356846 S Bi:3:039:1 -115 4096 <
ffff88810b78f540 2433357920 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433357924 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433357955 C Bi:3:039:1 0 13 = 55534253 0a000000 00000000 00
ffff88814e50d0c0 2433358106 S Bo:3:039:1 -115 31 = 55534243 0b000000 00000000 0000061e 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433358804 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433358808 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433365636 C Bi:3:039:1 0 13 = 55534253 0b000000 00000000 00
ffff88814e50d0c0 2433365751 S Bo:3:039:1 -115 31 = 55534243 0c000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433365766 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433365770 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433366659 C Bi:3:039:1 0 13 = 55534253 0c000000 00000000 00
ffff88814e50d0c0 2433366674 S Bo:3:039:1 -115 31 = 55534243 0d000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433366699 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433366713 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433367635 C Bi:3:039:1 0 13 = 55534253 0d000000 00000000 00
ffff88814e50d0c0 2433367665 S Bo:3:039:1 -115 31 = 55534243 0e000000 08000000 80000a25 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433367678 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433367684 S Bi:3:039:1 -115 8 <
ffff888361694cc0 2433368658 C Bi:3:039:1 0 8 = 00660fff 00000200
ffff88814e50d0c0 2433368673 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433368698 C Bi:3:039:1 0 13 = 55534253 0e000000 00000000 00
ffff88814e50d0c0 2433368727 S Bo:3:039:1 -115 31 = 55534243 0f000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433369662 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433369674 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433370683 C Bi:3:039:1 0 13 = 55534253 0f000000 00000000 00
ffff88814e50d0c0 2433370696 S Bo:3:039:1 -115 31 = 55534243 10000000 c0000000 8000061a 003f00c0 00000000 00000000 000000
ffff88814e50d0c0 2433370713 C Bo:3:039:1 0 31 >
ffff88823b6f7540 2433370716 S Bi:3:039:1 -115 192 <
ffff88823b6f7540 2433371681 C Bi:3:039:1 -121 16 = 0f000000 080a0400 ffff0000 ffffffff
ffff88814e50d0c0 2433371684 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433480345 C Bi:3:039:1 -32 0
ffff88814e50d0c0 2433480350 S Co:3:039:0 s 02 01 0000 0081 0000 0
ffff88814e50d0c0 2433480393 C Co:3:039:0 0 0
ffff88814e50d0c0 2433480396 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433480438 C Bi:3:039:1 0 13 = 55534253 10000000 b0000000 00
ffff88814e50d0c0 2433480468 S Bo:3:039:1 -115 31 = 55534243 11000000 c0000000 8000061a 003f00c0 00000000 00000000 000000
ffff88814e50d0c0 2433480484 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433480490 S Bi:3:039:1 -115 192 <
ffff888361694cc0 2433481439 C Bi:3:039:1 -121 16 = 0f000000 080a0400 ffff0000 ffffffff
ffff88814e50d0c0 2433481455 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433590396 C Bi:3:039:1 -32 0
ffff88814e50d0c0 2433590413 S Co:3:039:0 s 02 01 0000 0081 0000 0
ffff88814e50d0c0 2433590470 C Co:3:039:0 0 0
ffff88814e50d0c0 2433590474 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433590507 C Bi:3:039:1 0 13 = 55534253 11000000 b0000000 00
ffff88814e50d0c0 2433590568 S Bo:3:039:1 -115 31 = 55534243 12000000 00000000 0000061e 00000001 00000000 00000000 000000
ffff88814e50d0c0 2433590583 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433590585 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433591411 C Bi:3:039:1 0 13 = 55534253 12000000 00000000 00
ffff88814e50d0c0 2433592053 S Bo:3:039:1 -115 31 = 55534243 13000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433592068 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433592086 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433592817 C Bi:3:039:1 0 13 = 55534253 13000000 00000000 00
ffff88814e50d0c0 2433592958 S Bo:3:039:1 -115 31 = 55534243 14000000 00100000 80000a28 0000660f 80000008 00000000 000000
ffff88814e50d0c0 2433592972 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433592991 S Bi:3:039:1 -115 4096 <
ffff88810e16a780 2433593536 C Bi:3:039:1 0 4096 = 83d798a1 2e3c2f70 97978889 4292ff97 96899781 08438995 a57c706f 733a6669
ffff88814e50d0c0 2433593551 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433593575 C Bi:3:039:1 0 13 = 55534253 14000000 00000000 00
ffff88814e50d0c0 2433593592 S Bo:3:039:1 -115 31 = 55534243 15000000 00100000 80000a28 0000660f f0000008 00000000 000000
ffff88814e50d0c0 2433594439 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433594454 S Bi:3:039:1 -115 4096 <
ffff88810e16a780 2433595527 C Bi:3:039:1 0 4096 = 884f884d 748aa06c 65766583 2be56c65 80407420 2803e29d b9292c82 ca815e73
ffff88814e50d0c0 2433595543 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433595556 C Bi:3:039:1 0 13 = 55534253 15000000 00000000 00
ffff88814e50d0c0 2433595573 S Bo:3:039:1 -115 31 = 55534243 16000000 00100000 80000a28 00000000 00000008 00000000 000000
ffff88814e50d0c0 2433596423 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433596439 S Bi:3:039:1 -115 4096 <
ffff88810e16a780 2433597552 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433597568 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433597593 C Bi:3:039:1 0 13 = 55534253 16000000 00000000 00
ffff88814e50d0c0 2433597631 S Bo:3:039:1 -115 31 = 55534243 17000000 00100000 80000a28 00000000 08000008 00000000 000000
ffff88814e50d0c0 2433598412 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433598416 S Bi:3:039:1 -115 4096 <
ffff88810e16a780 2433599544 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433599559 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433599569 C Bi:3:039:1 0 13 = 55534253 17000000 00000000 00
ffff88814e50d0c0 2433599584 S Bo:3:039:1 -115 31 = 55534243 18000000 00020000 80000a28 0000660f f8000001 00000000 000000
ffff88814e50d0c0 2433600393 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433600418 S Bi:3:039:1 -115 512 <
ffff88810e16a780 2433601455 C Bi:3:039:1 0 512 = 0f810981 90a72a6a 61785f62 61736963 73a2ab96 ff96ff96 fc6831a0 4fa07fa0
ffff88814e50d0c0 2433601471 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433601535 C Bi:3:039:1 0 13 = 55534253 18000000 00000000 00
ffff88814e50d0c0 2433601570 S Bo:3:039:1 -115 31 = 55534243 19000000 00020000 80000a28 0000660f f9000001 00000000 000000
ffff88814e50d0c0 2433602416 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433602441 S Bi:3:039:1 -115 512 <
ffff88810e16a780 2433603448 C Bi:3:039:1 0 512 = 82409218 628ee180 4085d080 a0934894 50900862 65852092 b961ed61 73904084
ffff88814e50d0c0 2433603464 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433603515 C Bi:3:039:1 0 13 = 55534253 19000000 00000000 00
ffff88814e50d0c0 2433603557 S Bo:3:039:1 -115 31 = 55534243 1a000000 00020000 80000a28 0000660f fa000001 00000000 000000
ffff88814e50d0c0 2433604424 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433604449 S Bi:3:039:1 -115 512 <
ffff88810e16a780 2433605452 C Bi:3:039:1 0 512 = 479227a3 ff729de0 8b396f6e 6c79ba10 72749ee1 9e99888a 73746f72 792ec96e
ffff88814e50d0c0 2433605468 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433605485 C Bi:3:039:1 0 13 = 55534253 1a000000 00000000 00
ffff88814e50d0c0 2433605505 S Bo:3:039:1 -115 31 = 55534243 1b000000 00020000 80000a28 0000660f fb000001 00000000 000000
ffff88814e50d0c0 2433606424 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433606448 S Bi:3:039:1 -115 512 <
ffff88810e16a780 2433607596 C Bi:3:039:1 0 512 = 4882256b 696e646c 653a706f 733a6669 643a3030 374b3a6f 66668048 30801830
ffff88814e50d0c0 2433607612 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433607623 C Bi:3:039:1 0 13 = 55534253 1b000000 00000000 00
ffff88814e50d0c0 2433607635 S Bo:3:039:1 -115 31 = 55534243 1c000000 00020000 80000a28 0000660f fc000001 00000000 000000
ffff88814e50d0c0 2433608381 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433608396 S Bi:3:039:1 -115 512 <
ffff88810e16a780 2433609431 C Bi:3:039:1 0 512 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433609446 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433609497 C Bi:3:039:1 0 13 = 55534253 1c000000 00000000 00
ffff88814e50d0c0 2433609529 S Bo:3:039:1 -115 31 = 55534243 1d000000 00020000 80000a28 0000660f fd000001 00000000 000000
ffff88814e50d0c0 2433610421 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433610437 S Bi:3:039:1 -115 512 <
ffff88810e16a780 2433611432 C Bi:3:039:1 0 512 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433611447 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433611481 C Bi:3:039:1 0 13 = 55534253 1d000000 00000000 00
ffff88814e50d0c0 2433611506 S Bo:3:039:1 -115 31 = 55534243 1e000000 00020000 80000a28 0000660f fe000001 00000000 000000
ffff88814e50d0c0 2433612412 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433612428 S Bi:3:039:1 -115 512 <
ffff88810e16a780 2433613419 C Bi:3:039:1 0 512 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433613444 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433613497 C Bi:3:039:1 0 13 = 55534253 1e000000 00000000 00
ffff88814e50d0c0 2433613531 S Bo:3:039:1 -115 31 = 55534243 1f000000 00020000 80000a28 0000660f ff000001 00000000 000000
ffff88814e50d0c0 2433614396 C Bo:3:039:1 0 31 >
ffff88823b6f7540 2433614400 S Bi:3:039:1 -115 512 <
ffff88823b6f7540 2433615408 C Bi:3:039:1 0 512 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433615410 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433615434 C Bi:3:039:1 0 13 = 55534253 1f000000 00000000 00
ffff88814e50d0c0 2433615467 S Bo:3:039:1 -115 31 = 55534243 20000000 00100000 80000a28 0000660e f8000008 00000000 000000
ffff88814e50d0c0 2433616396 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433616412 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433617509 C Bi:3:039:1 0 4096 = d7889788 966c8398 82608789 88398303 6d6f7265 840784e8 83887573 83814347
ffff88814e50d0c0 2433617524 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433617566 C Bi:3:039:1 0 13 = 55534253 20000000 00000000 00
ffff88814e50d0c0 2433617587 S Bo:3:039:1 -115 31 = 55534243 21000000 00100000 80000a28 0000660f c0000008 00000000 000000
ffff88814e50d0c0 2433618415 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433618430 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433619523 C Bi:3:039:1 0 4096 = e6726f6d 8ad07795 60706167 866273c4 4f4ded65 74686f64 8e408310 8f30807c
ffff88814e50d0c0 2433619538 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433619580 C Bi:3:039:1 0 13 = 55534253 21000000 00000000 00
ffff88814e50d0c0 2433619604 S Bo:3:039:1 -115 31 = 55534243 22000000 00100000 80000a28 0000660f 00000008 00000000 000000
ffff88814e50d0c0 2433620373 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433620390 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433621513 C Bi:3:039:1 0 4096 = 7fa70354 5b0bdc06 05e38004 2a270921 fe04e1ef 0673d808 7be20b8f c80b9063
ffff88814e50d0c0 2433621529 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433621566 C Bi:3:039:1 0 13 = 55534253 22000000 00000000 00
ffff88814e50d0c0 2433621589 S Bo:3:039:1 -115 31 = 55534243 23000000 00100000 80000a28 0000660e 70000008 00000000 000000
ffff88814e50d0c0 2433622415 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433622432 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433623500 C Bi:3:039:1 0 4096 = 689af080 d86f75a8 89859863 65aad076 61696c61 626c982a 845f8458 54845f84
ffff88814e50d0c0 2433623526 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433623546 C Bi:3:039:1 0 13 = 55534253 23000000 00000000 00
ffff88814e50d0c0 2433623564 S Bo:3:039:1 -115 31 = 55534243 24000000 00100000 80000a28 0000660d b0000008 00000000 000000
ffff88814e50d0c0 2433624402 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433624418 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433625512 C Bi:3:039:1 0 4096 = 28fb469e 15c6394c b994836b 846be181 fd46a753 f7e472a6 95388f6f bb299bbd
ffff88814e50d0c0 2433625528 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433625565 C Bi:3:039:1 0 13 = 55534253 24000000 00000000 00
ffff88814e50d0c0 2433625587 S Bo:3:039:1 -115 31 = 55534243 25000000 00100000 80000a28 0000660d 58000008 00000000 000000
ffff88814e50d0c0 2433626368 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433626374 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433627507 C Bi:3:039:1 0 4096 = 18019d00 01000056 25019e00 09000026 4a019f00 02000046 94000000 08019f00
ffff88814e50d0c0 2433627525 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433627536 C Bi:3:039:1 0 13 = 55534253 25000000 00000000 00
ffff88814e50d0c0 2433627561 S Bo:3:039:1 -115 31 = 55534243 26000000 00100000 80000a28 0000660d 20000008 00000000 000000
ffff88814e50d0c0 2433628404 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433628421 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433629512 C Bi:3:039:1 0 4096 = a08a2488 3f821d53 883f8687 883f30b2 ad883f81 b154883f 81bf883a 881f881f
ffff88814e50d0c0 2433629529 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433629539 C Bi:3:039:1 0 13 = 55534253 26000000 00000000 00
ffff88814e50d0c0 2433629561 S Bo:3:039:1 -115 31 = 55534243 27000000 00100000 80000a28 0000660c 70000008 00000000 000000
ffff88814e50d0c0 2433630405 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433630421 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433631524 C Bi:3:039:1 0 4096 = 666f726d e56c656d 656eb8d1 86487461 6b82218c 008c4a86 af378e7e 6c697465
ffff88814e50d0c0 2433631537 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433631546 C Bi:3:039:1 0 13 = 55534253 27000000 00000000 00
ffff88814e50d0c0 2433631563 S Bo:3:039:1 -115 31 = 55534243 28000000 00100000 80000a28 0000660c 30000008 00000000 000000
ffff88814e50d0c0 2433632406 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433632421 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433633516 C Bi:3:039:1 0 4096 = d1747269 67676572 84649ad0 84336275 74746f6e 810970b9 9980f892 a984a485
ffff88814e50d0c0 2433633532 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433633593 C Bi:3:039:1 0 13 = 55534253 28000000 00000000 00
ffff88814e50d0c0 2433633627 S Bo:3:039:1 -115 31 = 55534243 29000000 00100000 80000a28 0000660c 20000008 00000000 000000
ffff88814e50d0c0 2433634403 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433634419 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433635511 C Bi:3:039:1 0 4096 = 813e80f9 81598110 88b74732 4488b788 b64a6176 61536372 69707427 73f46f6f
ffff88814e50d0c0 2433635527 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433635579 C Bi:3:039:1 0 13 = 55534253 29000000 00000000 00
ffff88814e50d0c0 2433635622 S Bo:3:039:1 -115 31 = 55534243 2a000000 00100000 80000a28 0000660c 48000008 00000000 000000
ffff88814e50d0c0 2433636400 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433636415 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433637509 C Bi:3:039:1 0 4096 = 81469238 81478144 34814781 46348147 81463581 47814635 81449e79 81674a48
ffff88814e50d0c0 2433637525 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433637576 C Bi:3:039:1 0 13 = 55534253 2a000000 00000000 00
ffff88814e50d0c0 2433637620 S Bo:3:039:1 -115 31 = 55534243 2b000000 00100000 80000a28 00006603 f0000008 00000000 000000
ffff88814e50d0c0 2433638400 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433638416 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433639524 C Bi:3:039:1 0 4096 = 30f29f8c db05a191 ef1a0320 1f128039 54f2c6ee 95903c69 7ffd4955 2ee9581d
ffff88814e50d0c0 2433639540 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433639602 C Bi:3:039:1 0 13 = 55534253 2b000000 00000000 00
ffff88814e50d0c0 2433639719 S Bo:3:039:1 -115 31 = 55534243 2c000000 00100000 80000a28 00000000 20000008 00000000 000000
ffff88814e50d0c0 2433640395 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433640410 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433641524 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433641540 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433641601 C Bi:3:039:1 0 13 = 55534253 2c000000 00000000 00
ffff88814e50d0c0 2433641702 S Bo:3:039:1 -115 31 = 55534243 2d000000 00100000 80000a28 00000000 40000008 00000000 000000
ffff88814e50d0c0 2433642399 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433642414 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433643515 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433643531 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433643542 C Bi:3:039:1 0 13 = 55534253 2d000000 00000000 00
ffff88814e50d0c0 2433643564 S Bo:3:039:1 -115 31 = 55534243 2e000000 00100000 80000a28 00000000 80000008 00000000 000000
ffff88814e50d0c0 2433644397 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433644422 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433645516 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433645541 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433645551 C Bi:3:039:1 0 13 = 55534253 2e000000 00000000 00
ffff88814e50d0c0 2433645574 S Bo:3:039:1 -115 31 = 55534243 2f000000 00100000 80000a28 00000001 00000008 00000000 000000
ffff88814e50d0c0 2433646400 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433646416 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433647510 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433647522 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433647531 C Bi:3:039:1 0 13 = 55534253 2f000000 00000000 00
ffff88814e50d0c0 2433647548 S Bo:3:039:1 -115 31 = 55534243 30000000 00100000 80000a28 00000002 00000008 00000000 000000
ffff88814e50d0c0 2433648403 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433648428 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433649524 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433649540 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433649603 C Bi:3:039:1 0 13 = 55534253 30000000 00000000 00
ffff88814e50d0c0 2433649637 S Bo:3:039:1 -115 31 = 55534243 31000000 00100000 80000a28 00000004 00000008 00000000 000000
ffff88814e50d0c0 2433650398 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433650414 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433651499 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433651525 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433651577 C Bi:3:039:1 0 13 = 55534253 31000000 00000000 00
ffff88814e50d0c0 2433651622 S Bo:3:039:1 -115 31 = 55534243 32000000 00100000 80000a28 00000008 00000008 00000000 000000
ffff88814e50d0c0 2433652400 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433652415 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433653508 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433653525 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433653535 C Bi:3:039:1 0 13 = 55534253 32000000 00000000 00
ffff88814e50d0c0 2433653557 S Bo:3:039:1 -115 31 = 55534243 33000000 00100000 80000a28 00000010 00000008 00000000 000000
ffff88814e50d0c0 2433654400 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433654415 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433655499 C Bi:3:039:1 0 4096 = 01390300 02390300 03390300 04390300 05390300 06390300 07390300 08390300
ffff88814e50d0c0 2433655525 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433655553 C Bi:3:039:1 0 13 = 55534253 33000000 00000000 00
ffff88814e50d0c0 2433655633 S Bo:3:039:1 -115 31 = 55534243 34000000 00100000 80000a28 00000020 00000008 00000000 000000
ffff88814e50d0c0 2433656369 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433656383 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433657525 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433657541 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433657552 C Bi:3:039:1 0 13 = 55534253 34000000 00000000 00
ffff88814e50d0c0 2433657590 S Bo:3:039:1 -115 31 = 55534243 35000000 00100000 80000a28 00000000 18000008 00000000 000000
ffff88814e50d0c0 2433658382 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433658407 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433659515 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433659541 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433659551 C Bi:3:039:1 0 13 = 55534253 35000000 00000000 00
ffff88814e50d0c0 2433659574 S Bo:3:039:1 -115 31 = 55534243 36000000 00100000 80000a28 00000000 38000008 00000000 000000
ffff88814e50d0c0 2433660400 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433660416 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433661509 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433661526 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433661537 C Bi:3:039:1 0 13 = 55534253 36000000 00000000 00
ffff88814e50d0c0 2433661559 S Bo:3:039:1 -115 31 = 55534243 37000000 00100000 80000a28 00000000 78000008 00000000 000000
ffff88814e50d0c0 2433662405 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433662420 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433663499 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433663525 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433663535 C Bi:3:039:1 0 13 = 55534253 37000000 00000000 00
ffff88814e50d0c0 2433663685 S Bo:3:039:1 -115 31 = 55534243 38000000 00100000 80000a28 00000000 10000008 00000000 000000
ffff88814e50d0c0 2433664383 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433664388 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433665509 C Bi:3:039:1 0 4096 = eb58906d 6b646f73 66730000 02107e09 02000000 00f80000 20004000 00000000
ffff88814e50d0c0 2433665525 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433665564 C Bi:3:039:1 0 13 = 55534253 38000000 00000000 00
ffff88814e50d0c0 2433665617 S Bo:3:039:1 -115 31 = 55534243 39000000 00200000 80000a28 00000000 28000010 00000000 000000
ffff88814e50d0c0 2433666388 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433666400 S Bi:3:039:1 -115 8192 <
ffff88810b78f540 2433667602 C Bi:3:039:1 0 8192 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433667605 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433667615 C Bi:3:039:1 0 13 = 55534253 39000000 00000000 00
ffff88814e50d0c0 2433667626 S Bo:3:039:1 -115 31 = 55534243 3a000000 00600000 80000a28 00000000 48000030 00000000 000000
ffff88814e50d0c0 2433668401 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433668404 S Bi:3:039:1 -115 24576 <
ffff88810b78f540 2433670001 C Bi:3:039:1 0 24576 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433670004 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433670570 C Bi:3:039:1 0 13 = 55534253 3a000000 00000000 00
ffff88814e50d0c0 2433670587 S Bo:3:039:1 -115 31 = 55534243 3b000000 00f00000 80000a28 00000000 88000078 00000000 000000
ffff88814e50d0c0 2433670621 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433670635 S Bi:3:039:1 -115 61440 <
ffff88810b78f540 2433673092 C Bi:3:039:1 0 61440 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433673096 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433673383 C Bi:3:039:1 0 13 = 55534253 3b000000 00000000 00
ffff88814e50d0c0 2433673405 S Bo:3:039:1 -115 31 = 55534243 3c000000 00100000 80000a28 00000001 08000008 00000000 000000
ffff88814e50d0c0 2433673433 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433673447 S Bi:3:039:1 -115 4096 <
ffff88810b78f540 2433674524 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433674527 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433674558 C Bi:3:039:1 0 13 = 55534253 3c000000 00000000 00
ffff88814e50d0c0 2433674614 S Bo:3:039:1 -115 31 = 55534243 3d000000 00e00100 80000a28 00000001 100000f0 00000000 000000
ffff88814e50d0c0 2433675399 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433675401 S Bi:3:039:1 -115 122880 <
ffff88810b78f540 2433680051 C Bi:3:039:1 0 122880 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433680066 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433680409 C Bi:3:039:1 0 13 = 55534253 3d000000 00000000 00
ffff88814e50d0c0 2433681056 S Bo:3:039:1 -115 31 = 55534243 3e000000 00000000 0000061e 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433681073 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433681074 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433681465 C Bi:3:039:1 0 13 = 55534253 3e000000 00000000 00
ffff88814e50d0c0 2433681480 S Bo:3:039:1 -115 31 = 55534243 3f000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433681492 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433681509 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433682395 C Bi:3:039:1 0 13 = 55534253 3f000000 00000000 00
ffff88814e50d0c0 2433682420 S Bo:3:039:1 -115 31 = 55534243 40000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433682433 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433682435 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433683421 C Bi:3:039:1 0 13 = 55534253 40000000 00000000 00
ffff88814e50d0c0 2433683446 S Bo:3:039:1 -115 31 = 55534243 41000000 00000000 0000061e 00000001 00000000 00000000 000000
ffff88814e50d0c0 2433683459 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433683476 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433684398 C Bi:3:039:1 0 13 = 55534253 41000000 00000000 00
ffff88814e50d0c0 2433684430 S Bo:3:039:1 -115 31 = 55534243 42000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433684445 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433684448 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433685392 C Bi:3:039:1 0 13 = 55534253 42000000 00000000 00
ffff88814e50d0c0 2433685421 S Bo:3:039:1 -115 31 = 55534243 43000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433685435 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433685438 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433686400 C Bi:3:039:1 0 13 = 55534253 43000000 00000000 00
ffff88814e50d0c0 2433686516 S Bo:3:039:1 -115 31 = 55534243 44000000 00100000 80000a28 0000660f 10000008 00000000 000000
ffff88814e50d0c0 2433686530 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433686534 S Bi:3:039:1 -115 4096 <
ffff888361694cc0 2433687502 C Bi:3:039:1 0 4096 = 4649839f 839b34bf 0fbf09a6 d0870f87 0f870f87 0f870f87 0f870f87 0b3c2f62
ffff88814e50d0c0 2433689958 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433689974 C Bi:3:039:1 0 13 = 55534253 44000000 00000000 00
ffff88814e50d0c0 2433690024 S Bo:3:039:1 -115 31 = 55534243 45000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433690039 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433690041 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433690995 C Bi:3:039:1 0 13 = 55534253 45000000 00000000 00
ffff88814e50d0c0 2433691280 S Bo:3:039:1 -115 31 = 55534243 46000000 00100000 80000a28 0000660f f0000008 00000000 000000
ffff88814e50d0c0 2433691294 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433691390 S Bi:3:039:1 -115 4096 <
ffff88810b78f540 2433692107 C Bi:3:039:1 0 4096 = 884f884d 748aa06c 65766583 2be56c65 80407420 2803e29d b9292c82 ca815e73
ffff88814e50d0c0 2433692115 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433692141 C Bi:3:039:1 0 13 = 55534253 46000000 00000000 00
ffff88814e50d0c0 2433692187 S Bo:3:039:1 -115 31 = 55534243 47000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433693001 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433693120 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433693992 C Bi:3:039:1 0 13 = 55534253 47000000 00000000 00
ffff88814e50d0c0 2433694144 S Bo:3:039:1 -115 31 = 55534243 48000000 00100000 80000a28 00000000 10000008 00000000 000000
ffff88814e50d0c0 2433694159 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433694162 S Bi:3:039:1 -115 4096 <
ffff88810b78f540 2433695106 C Bi:3:039:1 0 4096 = eb58906d 6b646f73 66730000 02107e09 02000000 00f80000 20004000 00000000
ffff88814e50d0c0 2433695113 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433695143 C Bi:3:039:1 0 13 = 55534253 48000000 00000000 00
ffff88814e50d0c0 2433695186 S Bo:3:039:1 -115 31 = 55534243 49000000 00100000 80000a28 00000000 18000008 00000000 000000
ffff88814e50d0c0 2433696002 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433696157 S Bi:3:039:1 -115 4096 <
ffff88810b78f540 2433697107 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433697168 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433697181 C Bi:3:039:1 0 13 = 55534253 49000000 00000000 00
ffff88814e50d0c0 2433697226 S Bo:3:039:1 -115 31 = 55534243 4a000000 00020000 80000a28 0000660f f8000001 00000000 000000
ffff88814e50d0c0 2433698000 C Bo:3:039:1 0 31 >
ffff88823b6f7540 2433698008 S Bi:3:039:1 -115 512 <
ffff88823b6f7540 2433699034 C Bi:3:039:1 0 512 = 0f810981 90a72a6a 61785f62 61736963 73a2ab96 ff96ff96 fc6831a0 4fa07fa0
ffff88814e50d0c0 2433699041 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433699074 C Bi:3:039:1 0 13 = 55534253 4a000000 00000000 00
ffff88814e50d0c0 2433699096 S Bo:3:039:1 -115 31 = 55534243 4b000000 00020000 80000a28 0000660f f9000001 00000000 000000
ffff88814e50d0c0 2433700002 C Bo:3:039:1 0 31 >
ffff88823b6f7540 2433700009 S Bi:3:039:1 -115 512 <
ffff88823b6f7540 2433701023 C Bi:3:039:1 0 512 = 82409218 628ee180 4085d080 a0934894 50900862 65852092 b961ed61 73904084
ffff88814e50d0c0 2433701030 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433701060 C Bi:3:039:1 0 13 = 55534253 4b000000 00000000 00
ffff88814e50d0c0 2433701083 S Bo:3:039:1 -115 31 = 55534243 4c000000 00020000 80000a28 0000660f fa000001 00000000 000000
ffff88814e50d0c0 2433702003 C Bo:3:039:1 0 31 >
ffff888361694cc0 2433702011 S Bi:3:039:1 -115 512 <
ffff888361694cc0 2433703022 C Bi:3:039:1 0 512 = 479227a3 ff729de0 8b396f6e 6c79ba10 72749ee1 9e99888a 73746f72 792ec96e
ffff88814e50d0c0 2433704199 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433704218 C Bi:3:039:1 0 13 = 55534253 4c000000 00000000 00
ffff88814e50d0c0 2433704247 S Bo:3:039:1 -115 31 = 55534243 4d000000 00020000 80000a28 0000660f fb000001 00000000 000000
ffff88814e50d0c0 2433704262 C Bo:3:039:1 0 31 >
ffff88823b6f7540 2433704272 S Bi:3:039:1 -115 512 <
ffff88823b6f7540 2433705025 C Bi:3:039:1 0 512 = 4882256b 696e646c 653a706f 733a6669 643a3030 374b3a6f 66668048 30801830
ffff88814e50d0c0 2433706332 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433706347 C Bi:3:039:1 0 13 = 55534253 4d000000 00000000 00
ffff88814e50d0c0 2433706385 S Bo:3:039:1 -115 31 = 55534243 4e000000 00020000 80000a28 0000660f fc000001 00000000 000000
ffff88814e50d0c0 2433706400 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433707119 S Bi:3:039:1 -115 512 <
ffff88810b78f540 2433707142 C Bi:3:039:1 0 512 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433707145 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433707182 C Bi:3:039:1 0 13 = 55534253 4e000000 00000000 00
ffff88814e50d0c0 2433707199 S Bo:3:039:1 -115 31 = 55534243 4f000000 00020000 80000a28 0000660f fd000001 00000000 000000
ffff88814e50d0c0 2433707998 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433708746 S Bi:3:039:1 -115 512 <
ffff88810b78f540 2433709024 C Bi:3:039:1 0 512 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433709028 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433709060 C Bi:3:039:1 0 13 = 55534253 4f000000 00000000 00
ffff88814e50d0c0 2433709079 S Bo:3:039:1 -115 31 = 55534243 50000000 00020000 80000a28 0000660f fe000001 00000000 000000
ffff88814e50d0c0 2433710002 C Bo:3:039:1 0 31 >
ffff88823b6f7480 2433710006 S Bi:3:039:1 -115 512 <
ffff88823b6f7480 2433711022 C Bi:3:039:1 0 512 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433711029 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433711059 C Bi:3:039:1 0 13 = 55534253 50000000 00000000 00
ffff88814e50d0c0 2433711082 S Bo:3:039:1 -115 31 = 55534243 51000000 00020000 80000a28 0000660f ff000001 00000000 000000
ffff88814e50d0c0 2433712003 C Bo:3:039:1 0 31 >
ffff888361694000 2433712021 S Bi:3:039:1 -115 512 <
ffff888361694000 2433713027 C Bi:3:039:1 0 512 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433713508 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433713524 C Bi:3:039:1 0 13 = 55534253 51000000 00000000 00
ffff88814e50d0c0 2433713583 S Bo:3:039:1 -115 31 = 55534243 52000000 00100000 80000a28 0000660e f8000008 00000000 000000
ffff88814e50d0c0 2433713997 C Bo:3:039:1 0 31 >
ffff888361694000 2433714008 S Bi:3:039:1 -115 4096 <
ffff888361694000 2433715107 C Bi:3:039:1 0 4096 = d7889788 966c8398 82608789 88398303 6d6f7265 840784e8 83887573 83814347
ffff88814e50d0c0 2433715118 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433715142 C Bi:3:039:1 0 13 = 55534253 52000000 00000000 00
ffff88814e50d0c0 2433715202 S Bo:3:039:1 -115 31 = 55534243 53000000 00100000 80000a28 00000000 30000008 00000000 000000
ffff88814e50d0c0 2433716000 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433716008 S Bi:3:039:1 -115 4096 <
ffff88810e16a780 2433717107 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433717114 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433717141 C Bi:3:039:1 0 13 = 55534253 53000000 00000000 00
ffff88814e50d0c0 2433717176 S Bo:3:039:1 -115 31 = 55534243 54000000 00100000 80000a28 00000000 50000008 00000000 000000
ffff88814e50d0c0 2433717996 C Bo:3:039:1 0 31 >
ffff888361694000 2433718004 S Bi:3:039:1 -115 4096 <
ffff888361694000 2433719125 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433719133 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433719161 C Bi:3:039:1 0 13 = 55534253 54000000 00000000 00
ffff88814e50d0c0 2433719203 S Bo:3:039:1 -115 31 = 55534243 55000000 00100000 80000a28 00000000 90000008 00000000 000000
ffff88814e50d0c0 2433720001 C Bo:3:039:1 0 31 >
ffff888361694000 2433720009 S Bi:3:039:1 -115 4096 <
ffff888361694000 2433721125 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433721272 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433721285 C Bi:3:039:1 0 13 = 55534253 55000000 00000000 00
ffff88814e50d0c0 2433721327 S Bo:3:039:1 -115 31 = 55534243 56000000 00100000 80000a28 00000001 10000008 00000000 000000
ffff88814e50d0c0 2433722000 C Bo:3:039:1 0 31 >
ffff888361694000 2433722005 S Bi:3:039:1 -115 4096 <
ffff888361694000 2433723110 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433723114 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433723151 C Bi:3:039:1 0 13 = 55534253 56000000 00000000 00
ffff88814e50d0c0 2433723187 S Bo:3:039:1 -115 31 = 55534243 57000000 00100000 80000a28 00000002 10000008 00000000 000000
ffff88814e50d0c0 2433724002 C Bo:3:039:1 0 31 >
ffff88810b78f540 2433724197 S Bi:3:039:1 -115 4096 <
ffff88810b78f540 2433725127 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433725134 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433725161 C Bi:3:039:1 0 13 = 55534253 57000000 00000000 00
ffff88814e50d0c0 2433725207 S Bo:3:039:1 -115 31 = 55534243 58000000 00100000 80000a28 00000004 10000008 00000000 000000
ffff88814e50d0c0 2433726002 C Bo:3:039:1 0 31 >
ffff88810b78f600 2433726007 S Bi:3:039:1 -115 4096 <
ffff88810b78f600 2433727112 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433727117 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433727151 C Bi:3:039:1 0 13 = 55534253 58000000 00000000 00
ffff88814e50d0c0 2433727184 S Bo:3:039:1 -115 31 = 55534243 59000000 00100000 80000a28 00000008 10000008 00000000 000000
ffff88814e50d0c0 2433728001 C Bo:3:039:1 0 31 >
ffff88810b78f600 2433728003 S Bi:3:039:1 -115 4096 <
ffff88810b78f600 2433729112 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433729116 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433729151 C Bi:3:039:1 0 13 = 55534253 59000000 00000000 00
ffff88814e50d0c0 2433729179 S Bo:3:039:1 -115 31 = 55534243 5a000000 00100000 80000a28 00000010 10000008 00000000 000000
ffff88814e50d0c0 2433729997 C Bo:3:039:1 0 31 >
ffff88810b78f600 2433730000 S Bi:3:039:1 -115 4096 <
ffff88810b78f600 2433731108 C Bi:3:039:1 0 4096 = 01410300 02410300 03410300 04410300 05410300 06410300 07410300 08410300
ffff88814e50d0c0 2433731127 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433731142 C Bi:3:039:1 0 13 = 55534253 5a000000 00000000 00
ffff88814e50d0c0 2433731185 S Bo:3:039:1 -115 31 = 55534243 5b000000 00100000 80000a28 00000020 10000008 00000000 000000
ffff88814e50d0c0 2433732001 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433732008 S Bi:3:039:1 -115 4096 <
ffff88810e16a780 2433733105 C Bi:3:039:1 0 4096 = 00000000 00000000 83e10400 97e10400 00000000 00000000 00000000 95e10400
ffff88814e50d0c0 2433733118 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433733142 C Bi:3:039:1 0 13 = 55534253 5b000000 00000000 00
ffff88814e50d0c0 2433733185 S Bo:3:039:1 -115 31 = 55534243 5c000000 00300000 80000a28 00000023 08000018 00000000 000000
ffff88814e50d0c0 2433734001 C Bo:3:039:1 0 31 >
ffff88810e16a780 2433734008 S Bi:3:039:1 -115 12288 <
ffff88810e16a780 2433735312 C Bi:3:039:1 0 12288 = 815d0600 825d0600 835d0600 845d0600 865d0600 9b5d0600 875d0600 885d0600
ffff88814e50d0c0 2433735318 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433735345 C Bi:3:039:1 0 13 = 55534253 5c000000 00000000 00
ffff88814e50d0c0 2433735408 S Bo:3:039:1 -115 31 = 55534243 5d000000 00100000 80000a28 00000000 28000008 00000000 000000
ffff88814e50d0c0 2433735994 C Bo:3:039:1 0 31 >
ffff888361694d80 2433736000 S Bi:3:039:1 -115 4096 <
ffff888361694d80 2433737105 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433737111 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433737143 C Bi:3:039:1 0 13 = 55534253 5d000000 00000000 00
ffff88814e50d0c0 2433737172 S Bo:3:039:1 -115 31 = 55534243 5e000000 00100000 80000a28 00000000 48000008 00000000 000000
ffff88814e50d0c0 2433738007 C Bo:3:039:1 0 31 >
ffff888361694d80 2433738012 S Bi:3:039:1 -115 4096 <
ffff888361694d80 2433739124 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433739138 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433739162 C Bi:3:039:1 0 13 = 55534253 5e000000 00000000 00
ffff88814e50d0c0 2433739215 S Bo:3:039:1 -115 31 = 55534243 5f000000 00100000 80000a28 00000000 88000008 00000000 000000
ffff88814e50d0c0 2433740007 C Bo:3:039:1 0 31 >
ffff888361694d80 2433740019 S Bi:3:039:1 -115 4096 <
ffff888361694d80 2433741124 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433741130 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433741162 C Bi:3:039:1 0 13 = 55534253 5f000000 00000000 00
ffff88814e50d0c0 2433741212 S Bo:3:039:1 -115 31 = 55534243 60000000 00100000 80000a28 00000000 20000008 00000000 000000
ffff88814e50d0c0 2433742005 C Bo:3:039:1 0 31 >
ffff88816fb43b40 2433742018 S Bi:3:039:1 -115 4096 <
ffff88816fb43b40 2433743104 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433743119 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433743143 C Bi:3:039:1 0 13 = 55534253 60000000 00000000 00
ffff88814e50d0c0 2433743167 S Bo:3:039:1 -115 31 = 55534243 61000000 00200000 80000a28 00000000 38000010 00000000 000000
ffff88814e50d0c0 2433744001 C Bo:3:039:1 0 31 >
ffff88816fb43b40 2433744004 S Bi:3:039:1 -115 8192 <
ffff88816fb43b40 2433745202 C Bi:3:039:1 0 8192 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433745205 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433745240 C Bi:3:039:1 0 13 = 55534253 61000000 00000000 00
ffff88814e50d0c0 2433745260 S Bo:3:039:1 -115 31 = 55534243 62000000 00600000 80000a28 00000000 58000030 00000000 000000
ffff88814e50d0c0 2433745994 C Bo:3:039:1 0 31 >
ffff88816fb43b40 2433746006 S Bi:3:039:1 -115 24576 <
ffff88816fb43b40 2433747587 C Bi:3:039:1 0 24576 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433747600 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433747994 C Bi:3:039:1 0 13 = 55534253 62000000 00000000 00
ffff88814e50d0c0 2433748017 S Bo:3:039:1 -115 31 = 55534243 63000000 00f00000 80000a28 00000000 98000078 00000000 000000
ffff88814e50d0c0 2433748034 C Bo:3:039:1 0 31 >
ffff88816fb43b40 2433748036 S Bi:3:039:1 -115 61440 <
ffff88816fb43b40 2433750699 C Bi:3:039:1 0 61440 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433750715 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433751044 C Bi:3:039:1 0 13 = 55534253 63000000 00000000 00
ffff88814e50d0c0 2433751093 S Bo:3:039:1 -115 31 = 55534243 64000000 00100000 80000a28 00000001 18000008 00000000 000000
ffff88814e50d0c0 2433751123 C Bo:3:039:1 0 31 >
ffff88816fb43b40 2433751145 S Bi:3:039:1 -115 4096 <
ffff88816fb43b40 2433752148 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433752163 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433752202 C Bi:3:039:1 0 13 = 55534253 64000000 00000000 00
ffff88814e50d0c0 2433752250 S Bo:3:039:1 -115 31 = 55534243 65000000 00e00100 80000a28 00000001 200000f0 00000000 000000
ffff88814e50d0c0 2433753020 C Bo:3:039:1 0 31 >
ffff88816fb43b40 2433753044 S Bi:3:039:1 -115 122880 <
ffff88816fb43b40 2433757621 C Bi:3:039:1 0 122880 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433757625 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433758023 C Bi:3:039:1 0 13 = 55534253 65000000 00000000 00
ffff88814e50d0c0 2433758181 S Bo:3:039:1 -115 31 = 55534243 66000000 00e00100 80000a28 00000002 180000f0 00000000 000000
ffff88814e50d0c0 2433758197 C Bo:3:039:1 0 31 >
ffff88816fb43b40 2433758213 S Bi:3:039:1 -115 122880 <
ffff88816fb43b40 2433762633 C Bi:3:039:1 0 122880 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433762645 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433763037 C Bi:3:039:1 0 13 = 55534253 66000000 00000000 00
ffff88814e50d0c0 2433763070 S Bo:3:039:1 -115 31 = 55534243 67000000 00200000 80000a28 00000003 08000010 00000000 000000
ffff88814e50d0c0 2433763083 C Bo:3:039:1 0 31 >
ffff88823b6f7600 2433763086 S Bi:3:039:1 -115 8192 <
ffff88823b6f7600 2433764210 C Bi:3:039:1 0 8192 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433764225 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433764279 C Bi:3:039:1 0 13 = 55534253 67000000 00000000 00
ffff88814e50d0c0 2433764351 S Bo:3:039:1 -115 31 = 55534243 68000000 00e00100 80000a28 00000003 180000f0 00000000 000000
ffff88814e50d0c0 2433765019 C Bo:3:039:1 0 31 >
ffff88823b6f7600 2433765032 S Bi:3:039:1 -115 122880 <
ffff88823b6f7600 2433769624 C Bi:3:039:1 0 122880 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433769633 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433770014 C Bi:3:039:1 0 13 = 55534253 68000000 00000000 00
ffff88814e50d0c0 2433770047 S Bo:3:039:1 -115 31 = 55534243 69000000 00100000 80000a28 00000004 08000008 00000000 000000
ffff88814e50d0c0 2433770060 C Bo:3:039:1 0 31 >
ffff88823b6f7600 2433770062 S Bi:3:039:1 -115 4096 <
ffff88823b6f7600 2433771148 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433771152 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433771160 C Bi:3:039:1 0 13 = 55534253 69000000 00000000 00
ffff88814e50d0c0 2433771260 S Bo:3:039:1 -115 31 = 55534243 6a000000 00e00100 80000a28 0000660a 100000f0 00000000 000000
ffff88814e50d0c0 2433772020 C Bo:3:039:1 0 31 >
ffff88823b6f7600 2433772024 S Bi:3:039:1 -115 122880 <
ffff88823b6f7600 2433776630 C Bi:3:039:1 0 122880 = fdb7ce9c 9e78b76e e0139c16 7ec39936 225dfc7b 528510fc e5bcff00 9c2bd721
ffff88814e50d0c0 2433776644 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433777029 C Bi:3:039:1 0 13 = 55534253 6a000000 00000000 00
ffff88814e50d0c0 2433777059 S Bo:3:039:1 -115 31 = 55534243 6b000000 00200000 80000a28 0000660b 00000010 00000000 000000
ffff88814e50d0c0 2433777075 C Bo:3:039:1 0 31 >
ffff88810b78f600 2433777078 S Bi:3:039:1 -115 8192 <
ffff88810b78f600 2433778226 C Bi:3:039:1 0 8192 = 36474722 3e564283 fb83e783 e7828d56 83e783e7 80ec4a8d 0883e74a 3183e783
ffff88814e50d0c0 2433778229 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433778283 C Bi:3:039:1 0 13 = 55534253 6b000000 00000000 00
ffff88814e50d0c0 2433778365 S Bo:3:039:1 -115 31 = 55534243 6c000000 00e00100 80000a28 0000660b 100000f0 00000000 000000
ffff88814e50d0c0 2433779036 C Bo:3:039:1 0 31 >
ffff88823b6f7600 2433779048 S Bi:3:039:1 -115 122880 <
ffff88823b6f7600 2433783649 C Bi:3:039:1 0 122880 = 6577e96d 706f7281 607482df 7480c8b2 c0726585 307389c0 89eb86d8 666597b0
ffff88814e50d0c0 2433783665 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433784055 C Bi:3:039:1 0 13 = 55534253 6c000000 00000000 00
ffff88814e50d0c0 2433784100 S Bo:3:039:1 -115 31 = 55534243 6d000000 00200000 80000a28 0000660c 00000010 00000000 000000
ffff88814e50d0c0 2433784117 C Bo:3:039:1 0 31 >
ffff88810b78f600 2433784120 S Bi:3:039:1 -115 8192 <
ffff88810b78f600 2433785227 C Bi:3:039:1 0 8192 = 6c617373 3d22746f 6322ec61 6e673d22 656e2281 4781434d 81478140 80f780f3
ffff88814e50d0c0 2433785230 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433785260 C Bi:3:039:1 0 13 = 55534253 6d000000 00000000 00
ffff88814e50d0c0 2433785375 S Bo:3:039:1 -115 31 = 55534243 6e000000 00e00100 80000a28 0000660c 100000f0 00000000 000000
ffff88814e50d0c0 2433786026 C Bo:3:039:1 0 31 >
ffff88823b6f7600 2433786030 S Bi:3:039:1 -115 122880 <
ffff88823b6f7600 2433790604 C Bi:3:039:1 0 122880 = 3ea9b88a 102c812b 6f6e2774 e8618ca8 8158676f e8756ea4 5a746872 6f756768
ffff88814e50d0c0 2433790616 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433791045 C Bi:3:039:1 0 13 = 55534253 6e000000 00000000 00
ffff88814e50d0c0 2433791082 S Bo:3:039:1 -115 31 = 55534243 6f000000 00200000 80000a28 0000660d 00000010 00000000 000000
ffff88814e50d0c0 2433791106 C Bo:3:039:1 0 31 >
ffff888361694f00 2433791129 S Bi:3:039:1 -115 8192 <
ffff888361694f00 2433792230 C Bi:3:039:1 0 8192 = 0440cd07 2eb007d4 bf089b73 0acb9f0b d1f70bdd 5901af44 03336503 cb2c03f0
ffff88814e50d0c0 2433792247 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433792258 C Bi:3:039:1 0 13 = 55534253 6f000000 00000000 00
ffff88814e50d0c0 2433792394 S Bo:3:039:1 -115 31 = 55534243 70000000 00e00100 80000a28 0000660d 100000f0 00000000 000000
ffff88814e50d0c0 2433793019 C Bo:3:039:1 0 31 >
ffff888361694f00 2433793043 S Bi:3:039:1 -115 122880 <
ffff888361694f00 2433797626 C Bi:3:039:1 0 122880 = 82d880a8 72820884 ad69742e 8dc78338 4297fb49 44582d43 48502d37 2d30359a
ffff88814e50d0c0 2433797635 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433798009 C Bi:3:039:1 0 13 = 55534253 70000000 00000000 00
ffff88814e50d0c0 2433798074 S Bo:3:039:1 -115 31 = 55534243 71000000 00200000 80000a28 0000660e 00000010 00000000 000000
ffff88814e50d0c0 2433798123 C Bo:3:039:1 0 31 >
ffff88810b78f600 2433798125 S Bi:3:039:1 -115 8192 <
ffff88810b78f600 2433799259 C Bi:3:039:1 0 8192 = 8a0af15d 0af3b90a f6170af7 920aff2b 0b127b0b 14090b14 470b14b6 0b14e80b
ffff88814e50d0c0 2433799261 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433799293 C Bi:3:039:1 0 13 = 55534253 71000000 00000000 00
ffff88814e50d0c0 2433799439 S Bo:3:039:1 -115 31 = 55534243 72000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433800026 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433800037 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433801045 C Bi:3:039:1 0 13 = 55534253 72000000 00000000 00
ffff88814e50d0c0 2433801111 S Bo:3:039:1 -115 31 = 55534243 73000000 00100000 80000a28 00000000 00000008 00000000 000000
ffff88814e50d0c0 2433801124 C Bo:3:039:1 0 31 >
ffff88816fb43b40 2433801141 S Bi:3:039:1 -115 4096 <
ffff88816fb43b40 2433802148 C Bi:3:039:1 0 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffff88814e50d0c0 2433802162 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433802172 C Bi:3:039:1 0 13 = 55534253 73000000 00000000 00
ffff88814e50d0c0 2433802895 S Bo:3:039:1 -115 31 = 55534243 74000000 00000000 0000061e 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433802993 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433803005 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433804088 C Bi:3:039:1 0 13 = 55534253 74000000 00000000 00
ffff88814e50d0c0 2433804109 S Bo:3:039:1 -115 31 = 55534243 75000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2433804122 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2433804124 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2433805014 C Bi:3:039:1 0 13 = 55534253 75000000 00000000 00
ffff88814e50d0c0 2435818652 S Bo:3:039:1 -115 31 = 55534243 76000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2435818682 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2435818685 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2435818819 C Bi:3:039:1 0 13 = 55534253 76000000 00000000 00
ffff88810279d840 2437424129 C Ii:3:002:1 0:8 8 = 02000000 00000000
ffff88810279d840 2437424152 S Ii:3:002:1 -115:8 8 <
ffff88814e50d0c0 2437866681 S Bo:3:039:1 -115 31 = 55534243 77000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2437866708 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2437866710 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2437866816 C Bi:3:039:1 0 13 = 55534253 77000000 00000000 00
ffff88810279d840 2438928127 C Ii:3:002:1 0:8 8 = 02004f00 00000000
ffff88810279d840 2438928151 S Ii:3:002:1 -115:8 8 <
ffff88810279d840 2438968072 C Ii:3:002:1 0:8 8 = 02000000 00000000
ffff88810279d840 2438968092 S Ii:3:002:1 -115:8 8 <
ffff88810279d840 2439136130 C Ii:3:002:1 0:8 8 = 00000000 00000000
ffff88810279d840 2439136151 S Ii:3:002:1 -115:8 8 <
ffff88814e50d0c0 2439914618 S Bo:3:039:1 -115 31 = 55534243 78000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2439914643 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2439914646 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2439914776 C Bi:3:039:1 0 13 = 55534253 78000000 00000000 00
ffff88810279d840 2440288128 C Ii:3:002:1 0:8 8 = 00002800 00000000
ffff88810279d840 2440288150 S Ii:3:002:1 -115:8 8 <
ffff88814e50d0c0 2440334800 S Bo:3:039:1 -115 31 = 55534243 79000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2440334822 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2440334824 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2440334909 C Bi:3:039:1 0 13 = 55534253 79000000 00000000 00
ffff88814e50d0c0 2440334922 S Bo:3:039:1 -115 31 = 55534243 7a000000 00000000 0000061e 00000001 00000000 00000000 000000
ffff88814e50d0c0 2440334949 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2440334951 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2440335817 C Bi:3:039:1 0 13 = 55534253 7a000000 00000000 00
ffff88810279d840 2440344100 C Ii:3:002:1 0:8 8 = 00000000 00000000
ffff88810279d840 2440344116 S Ii:3:002:1 -115:8 8 <
ffff88814e50d0c0 2441336674 S Bo:3:039:1 -115 31 = 55534243 7b000000 00000000 00000a35 00000000 00000000 00000000 000000
ffff88814e50d0c0 2441336697 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2441336699 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2441336911 C Bi:3:039:1 0 13 = 55534253 7b000000 00000000 00
ffff88814e50d0c0 2442346649 S Bo:3:039:1 -115 31 = 55534243 7c000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2442346700 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2442346702 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2442346799 C Bi:3:039:1 0 13 = 55534253 7c000000 00000000 00
ffff88810279d840 2444216130 C Ii:3:002:1 0:8 8 = 02000000 00000000
ffff88810279d840 2444216152 S Ii:3:002:1 -115:8 8 <
ffff88814e50d0c0 2444394684 S Bo:3:039:1 -115 31 = 55534243 7d000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2444394713 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2444394720 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444394804 C Bi:3:039:1 0 13 = 55534253 7d000000 00000000 01
ffff88814e50d0c0 2444394821 S Bo:3:039:1 -115 31 = 55534243 7e000000 12000000 80000603 00000012 00000000 00000000 000000
ffff88814e50d0c0 2444394866 C Bo:3:039:1 0 31 >
ffff88822c917540 2444394928 S Bi:3:039:1 -115 18 <
ffff88822c917540 2444395673 C Bi:3:039:1 0 18 = 70000200 0000000a 00000000 3a000000 0000
ffff88814e50d0c0 2444395696 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444395723 C Bi:3:039:1 0 13 = 55534253 7e000000 00000000 00
ffff88814e50d0c0 2444396221 S Bo:3:039:1 -115 31 = 55534243 7f000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2444397450 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2444397456 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444397671 C Bi:3:039:1 0 13 = 55534253 7f000000 00000000 01
ffff88814e50d0c0 2444397675 S Bo:3:039:1 -115 31 = 55534243 80000000 12000000 80000603 00000012 00000000 00000000 000000
ffff88814e50d0c0 2444397702 C Bo:3:039:1 0 31 >
ffff88823b6f7a80 2444397705 S Bi:3:039:1 -115 18 <
ffff88823b6f7a80 2444399142 C Bi:3:039:1 0 18 = 70000200 0000000a 00000000 3a000000 0000
ffff88814e50d0c0 2444399147 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444399176 C Bi:3:039:1 0 13 = 55534253 80000000 00000000 00
ffff88814e50d0c0 2444399225 S Bo:3:039:1 -115 31 = 55534243 81000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2444399709 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2444399712 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444400691 C Bi:3:039:1 0 13 = 55534253 81000000 00000000 01
ffff88814e50d0c0 2444400695 S Bo:3:039:1 -115 31 = 55534243 82000000 12000000 80000603 00000012 00000000 00000000 000000
ffff88814e50d0c0 2444400707 C Bo:3:039:1 0 31 >
ffff88823b6f7a80 2444400709 S Bi:3:039:1 -115 18 <
ffff88823b6f7a80 2444401692 C Bi:3:039:1 0 18 = 70000200 0000000a 00000000 3a000000 0000
ffff88814e50d0c0 2444401698 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444401714 C Bi:3:039:1 0 13 = 55534253 82000000 00000000 00
ffff88814e50d0c0 2444402556 S Bo:3:039:1 -115 31 = 55534243 83000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2444402637 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2444402641 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444404281 C Bi:3:039:1 0 13 = 55534253 83000000 00000000 01
ffff88814e50d0c0 2444404285 S Bo:3:039:1 -115 31 = 55534243 84000000 12000000 80000603 00000012 00000000 00000000 000000
ffff88814e50d0c0 2444404305 C Bo:3:039:1 0 31 >
ffff88823b6f7a80 2444404307 S Bi:3:039:1 -115 18 <
ffff88823b6f7a80 2444404699 C Bi:3:039:1 0 18 = 70000200 0000000a 00000000 3a000000 0000
ffff88814e50d0c0 2444404703 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444404747 C Bi:3:039:1 0 13 = 55534253 84000000 00000000 00
ffff88814e50d0c0 2444405346 S Bo:3:039:1 -115 31 = 55534243 85000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2444405979 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2444405984 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444406683 C Bi:3:039:1 0 13 = 55534253 85000000 00000000 01
ffff88814e50d0c0 2444406696 S Bo:3:039:1 -115 31 = 55534243 86000000 12000000 80000603 00000012 00000000 00000000 000000
ffff88814e50d0c0 2444406717 C Bo:3:039:1 0 31 >
ffff888361694cc0 2444406750 S Bi:3:039:1 -115 18 <
ffff888361694cc0 2444407744 C Bi:3:039:1 0 18 = 70000200 0000000a 00000000 3a000000 0000
ffff88814e50d0c0 2444407757 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444407809 C Bi:3:039:1 0 13 = 55534253 86000000 00000000 00
ffff88814e50d0c0 2444407906 S Bo:3:039:1 -115 31 = 55534243 87000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2444409448 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2444409464 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444409698 C Bi:3:039:1 0 13 = 55534253 87000000 00000000 01
ffff88814e50d0c0 2444409713 S Bo:3:039:1 -115 31 = 55534243 88000000 12000000 80000603 00000012 00000000 00000000 000000
ffff88814e50d0c0 2444409728 C Bo:3:039:1 0 31 >
ffff888361694cc0 2444409735 S Bi:3:039:1 -115 18 <
ffff888361694cc0 2444410683 C Bi:3:039:1 0 18 = 70000200 0000000a 00000000 3a000000 0000
ffff88814e50d0c0 2444410706 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444410749 C Bi:3:039:1 0 13 = 55534253 88000000 00000000 00
ffff88814e50d0c0 2444411148 S Bo:3:039:1 -115 31 = 55534243 89000000 00000000 00000600 00000000 00000000 00000000 000000
ffff88814e50d0c0 2444412261 C Bo:3:039:1 0 31 >
ffff88814e50d0c0 2444412265 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444412728 C Bi:3:039:1 0 13 = 55534253 89000000 00000000 01
ffff88814e50d0c0 2444412746 S Bo:3:039:1 -115 31 = 55534243 8a000000 12000000 80000603 00000012 00000000 00000000 000000
ffff88814e50d0c0 2444412767 C Bo:3:039:1 0 31 >
ffff88822c9173c0 2444412784 S Bi:3:039:1 -115 18 <
ffff88822c9173c0 2444413937 C Bi:3:039:1 0 18 = 70000200 0000000a 00000000 3a000000 0000
ffff88814e50d0c0 2444413954 S Bi:3:039:1 -115 13 <
ffff88814e50d0c0 2444413974 C Bi:3:039:1 0 13 = 55534253 8a000000 00000000 00
ffff88810279d840 2445200133 C Ii:3:002:1 0:8 8 = 02005000 00000000
ffff88810279d840 2445200153 S Ii:3:002:1 -115:8 8 <
ffff88810279d840 2445264104 C Ii:3:002:1 0:8 8 = 02000000 00000000
ffff88810279d840 2445264120 S Ii:3:002:1 -115:8 8 <
ffff88810279d840 2445384103 C Ii:3:002:1 0:8 8 = 00000000 00000000
ffff88810279d840 2445384126 S Ii:3:002:1 -115:8 8 <
ffff88810279d840 2445912136 C Ii:3:002:1 0:8 8 = 01000000 00000000
ffff88810279d840 2445912158 S Ii:3:002:1 -115:8 8 <
ffff88810279d840 2446328137 C Ii:3:002:1 0:8 8 = 01000600 00000000
ffff88810279d840 2446328158 S Ii:3:002:1 -115:8 8 <
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-08 21:59 ` Matthias Schwarzott
@ 2021-03-09 15:50 ` Alan Stern
2021-03-10 20:56 ` Matthias Schwarzott
0 siblings, 1 reply; 33+ messages in thread
From: Alan Stern @ 2021-03-09 15:50 UTC (permalink / raw)
To: Matthias Schwarzott; +Cc: linux-usb, usb-storage, hirofumi
On Mon, Mar 08, 2021 at 10:59:48PM +0100, Matthias Schwarzott wrote:
> Am 07.03.21 um 17:58 schrieb Alan Stern:
> > Okay. Can you collect a usbmon trace showing the events leading up to
> > and including a disconnection?
> >
> The easiest reproducer is by calling sync while having a file/the device
> open (and keeping it open afterwards).
>
> 1. I recorded usbmon trace like this:
> # cat /sys/kernel/debug/usb/usbmon/3u >
> /tmp/connect-python-sync-disconnect-usbmon.out
>
> 2. Connect Kindle device
>
> 3. Then trigger sync with python:
> # python -c "import time; import os; f = open('/dev/sde', 'r+b');
> time.sleep(1); os.fsync(f); time.sleep(5)"
>
> 4. After 2 seconds Kindle disconnects (does no longer show USB-Mode screen).
>
> 5. Ctrl+c the recording
>
> When the final sleep in the python-command is missing, the Kindle does not
> disconnect.
>
> > Alan Stern
> >
> > PS: I suspect the SYNCHRONIZE CACHE commands are correlated with the
> > disconnections but don't cause them. That is, I suspect the
> > disconnections happen when the device has been idle -- and generally the
> > host computer sends a SYNCHRONIZE CACHE command before idling a
> > removable drive.
> >
>
> I cannot read the usbmon trace, but wireshark displayed a command "SCSI:
> Prevent/Allow Medium Removal LUN: 0x00 ALLOW" when closing the file.
> So I suspect this command also counts as activity (!idle).
Here is the revelant part of the usbmon trace. The second value on each
line is a timestamp in microseconds.
> ffff88814e50d0c0 2440334800 S Bo:3:039:1 -115 31 = 55534243 79000000 00000000 00000600 00000000 00000000 00000000 000000
> ffff88814e50d0c0 2440334822 C Bo:3:039:1 0 31 >
> ffff88814e50d0c0 2440334824 S Bi:3:039:1 -115 13 <
> ffff88814e50d0c0 2440334909 C Bi:3:039:1 0 13 = 55534253 79000000 00000000 00
That is a TEST UNIT READY command, showing normal status.
> ffff88814e50d0c0 2440334922 S Bo:3:039:1 -115 31 = 55534243 7a000000 00000000 0000061e 00000001 00000000 00000000 000000
> ffff88814e50d0c0 2440334949 C Bo:3:039:1 0 31 >
> ffff88814e50d0c0 2440334951 S Bi:3:039:1 -115 13 <
> ffff88814e50d0c0 2440335817 C Bi:3:039:1 0 13 = 55534253 7a000000 00000000 00
That is a PREVENT MEDIUM REMOVAL command, sent when the device file was
opened by the Python program.
> ffff88814e50d0c0 2441336674 S Bo:3:039:1 -115 31 = 55534243 7b000000 00000000 00000a35 00000000 00000000 00000000 000000
> ffff88814e50d0c0 2441336697 C Bo:3:039:1 0 31 >
> ffff88814e50d0c0 2441336699 S Bi:3:039:1 -115 13 <
> ffff88814e50d0c0 2441336911 C Bi:3:039:1 0 13 = 55534253 7b000000 00000000 00
That is the SYNCHRONIZE CACHE command. Notice that the timestamp shows
it occurred one second after the PREVENT MEDIUM REMOVAL.
> ffff88814e50d0c0 2442346649 S Bo:3:039:1 -115 31 = 55534243 7c000000 00000000 00000600 00000000 00000000 00000000 000000
> ffff88814e50d0c0 2442346700 C Bo:3:039:1 0 31 >
> ffff88814e50d0c0 2442346702 S Bi:3:039:1 -115 13 <
> ffff88814e50d0c0 2442346799 C Bi:3:039:1 0 13 = 55534253 7c000000 00000000 00
One second later, a normal TEST UNIT READY.
> ffff88814e50d0c0 2444394684 S Bo:3:039:1 -115 31 = 55534243 7d000000 00000000 00000600 00000000 00000000 00000000 000000
> ffff88814e50d0c0 2444394713 C Bo:3:039:1 0 31 >
> ffff88814e50d0c0 2444394720 S Bi:3:039:1 -115 13 <
> ffff88814e50d0c0 2444394804 C Bi:3:039:1 0 13 = 55534253 7d000000 00000000 01
> ffff88814e50d0c0 2444394821 S Bo:3:039:1 -115 31 = 55534243 7e000000 12000000 80000603 00000012 00000000 00000000 000000
> ffff88814e50d0c0 2444394866 C Bo:3:039:1 0 31 >
> ffff88822c917540 2444394928 S Bi:3:039:1 -115 18 <
> ffff88822c917540 2444395673 C Bi:3:039:1 0 18 = 70000200 0000000a 00000000 3a000000 0000
> ffff88814e50d0c0 2444395696 S Bi:3:039:1 -115 13 <
> ffff88814e50d0c0 2444395723 C Bi:3:039:1 0 13 = 55534253 7e000000 00000000 00
Two seconds later, another TEST UNIT READY. This one returned a failure
status, with an error code saying that the medium is not present (in
spite of the fact that medium removal was supposed to be prevented).
The usbmon trace contains six more TEST UNIT READY commands, sent in
quick succession, all getting the same failure result. Notably, it does
not show any sort of disconnection. The final timestamp in the trace is
2446328158, which is just five seconds after the SYNCHRONIZE CACHE
command was sent -- there's no way to tell if anything happened after
that.
Maybe there's something else going on under Windows that we're not aware
of. The only significant different I can see between this trace and the
short Windows trace in your original email is the time interval between
TEST UNIT READY commands; here it is two seconds but with Windows it was
one second. You can change the interval by writing to
/sys/block/sde/events_poll_msecs
What happens if you set the value to 1000 before running the test?
Also, the usbmon trace shows that my guess about power management and
device disconnections was completely wrong. The bus does not get
suspended and the Kindle does not disconnect, even though it seems to
become unusable.
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-09 15:50 ` [usb-storage] " Alan Stern
@ 2021-03-10 20:56 ` Matthias Schwarzott
2021-03-10 21:46 ` Alan Stern
0 siblings, 1 reply; 33+ messages in thread
From: Matthias Schwarzott @ 2021-03-10 20:56 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, usb-storage, hirofumi
Am 09.03.21 um 16:50 schrieb Alan Stern:
> On Mon, Mar 08, 2021 at 10:59:48PM +0100, Matthias Schwarzott wrote:
>> Am 07.03.21 um 17:58 schrieb Alan Stern:
>
>>> Okay. Can you collect a usbmon trace showing the events leading up to
>>> and including a disconnection?
>>>
>> The easiest reproducer is by calling sync while having a file/the device
>> open (and keeping it open afterwards).
>>
>> 1. I recorded usbmon trace like this:
>> # cat /sys/kernel/debug/usb/usbmon/3u >
>> /tmp/connect-python-sync-disconnect-usbmon.out
>>
>> 2. Connect Kindle device
>>
>> 3. Then trigger sync with python:
>> # python -c "import time; import os; f = open('/dev/sde', 'r+b');
>> time.sleep(1); os.fsync(f); time.sleep(5)"
>>
>> 4. After 2 seconds Kindle disconnects (does no longer show USB-Mode screen).
>>
>> 5. Ctrl+c the recording
>>
>> When the final sleep in the python-command is missing, the Kindle does not
>> disconnect.
>>
>>> Alan Stern
>>>
>>> PS: I suspect the SYNCHRONIZE CACHE commands are correlated with the
>>> disconnections but don't cause them. That is, I suspect the
>>> disconnections happen when the device has been idle -- and generally the
>>> host computer sends a SYNCHRONIZE CACHE command before idling a
>>> removable drive.
>>>
>>
>> I cannot read the usbmon trace, but wireshark displayed a command "SCSI:
>> Prevent/Allow Medium Removal LUN: 0x00 ALLOW" when closing the file.
>> So I suspect this command also counts as activity (!idle).
>
> Here is the revelant part of the usbmon trace. The second value on each
> line is a timestamp in microseconds.
>
>> ffff88814e50d0c0 2440334800 S Bo:3:039:1 -115 31 = 55534243 79000000 00000000 00000600 00000000 00000000 00000000 000000
>> ffff88814e50d0c0 2440334822 C Bo:3:039:1 0 31 >
>> ffff88814e50d0c0 2440334824 S Bi:3:039:1 -115 13 <
>> ffff88814e50d0c0 2440334909 C Bi:3:039:1 0 13 = 55534253 79000000 00000000 00
>
> That is a TEST UNIT READY command, showing normal status.
>
>> ffff88814e50d0c0 2440334922 S Bo:3:039:1 -115 31 = 55534243 7a000000 00000000 0000061e 00000001 00000000 00000000 000000
>> ffff88814e50d0c0 2440334949 C Bo:3:039:1 0 31 >
>> ffff88814e50d0c0 2440334951 S Bi:3:039:1 -115 13 <
>> ffff88814e50d0c0 2440335817 C Bi:3:039:1 0 13 = 55534253 7a000000 00000000 00
>
> That is a PREVENT MEDIUM REMOVAL command, sent when the device file was
> opened by the Python program.
>
>> ffff88814e50d0c0 2441336674 S Bo:3:039:1 -115 31 = 55534243 7b000000 00000000 00000a35 00000000 00000000 00000000 000000
>> ffff88814e50d0c0 2441336697 C Bo:3:039:1 0 31 >
>> ffff88814e50d0c0 2441336699 S Bi:3:039:1 -115 13 <
>> ffff88814e50d0c0 2441336911 C Bi:3:039:1 0 13 = 55534253 7b000000 00000000 00
>
> That is the SYNCHRONIZE CACHE command. Notice that the timestamp shows
> it occurred one second after the PREVENT MEDIUM REMOVAL.
>
>> ffff88814e50d0c0 2442346649 S Bo:3:039:1 -115 31 = 55534243 7c000000 00000000 00000600 00000000 00000000 00000000 000000
>> ffff88814e50d0c0 2442346700 C Bo:3:039:1 0 31 >
>> ffff88814e50d0c0 2442346702 S Bi:3:039:1 -115 13 <
>> ffff88814e50d0c0 2442346799 C Bi:3:039:1 0 13 = 55534253 7c000000 00000000 00
>
> One second later, a normal TEST UNIT READY.
>
>> ffff88814e50d0c0 2444394684 S Bo:3:039:1 -115 31 = 55534243 7d000000 00000000 00000600 00000000 00000000 00000000 000000
>> ffff88814e50d0c0 2444394713 C Bo:3:039:1 0 31 >
>> ffff88814e50d0c0 2444394720 S Bi:3:039:1 -115 13 <
>> ffff88814e50d0c0 2444394804 C Bi:3:039:1 0 13 = 55534253 7d000000 00000000 01
>> ffff88814e50d0c0 2444394821 S Bo:3:039:1 -115 31 = 55534243 7e000000 12000000 80000603 00000012 00000000 00000000 000000
>> ffff88814e50d0c0 2444394866 C Bo:3:039:1 0 31 >
>> ffff88822c917540 2444394928 S Bi:3:039:1 -115 18 <
>> ffff88822c917540 2444395673 C Bi:3:039:1 0 18 = 70000200 0000000a 00000000 3a000000 0000
>> ffff88814e50d0c0 2444395696 S Bi:3:039:1 -115 13 <
>> ffff88814e50d0c0 2444395723 C Bi:3:039:1 0 13 = 55534253 7e000000 00000000 00
>
> Two seconds later, another TEST UNIT READY. This one returned a failure
> status, with an error code saying that the medium is not present (in
> spite of the fact that medium removal was supposed to be prevented).
>
> The usbmon trace contains six more TEST UNIT READY commands, sent in
> quick succession, all getting the same failure result. Notably, it does
> not show any sort of disconnection. The final timestamp in the trace is
> 2446328158, which is just five seconds after the SYNCHRONIZE CACHE
> command was sent -- there's no way to tell if anything happened after
> that.
>
> Maybe there's something else going on under Windows that we're not aware
> of. The only significant different I can see between this trace and the
> short Windows trace in your original email is the time interval between
> TEST UNIT READY commands; here it is two seconds but with Windows it was
> one second. You can change the interval by writing to
>
> /sys/block/sde/events_poll_msecs
>
> What happens if you set the value to 1000 before running the test?
>
I tested different values. At 1000 it still disconnects. At lower values
it no longer does this.
I tested 200 up to 900. Even 900 ms is good enough to keep it connected.
Btw. it is not a USB disconnect, but it just seems to plays medium ejected.
Out of interest I called "sg_start -v -l /dev/sde" after one of the
failing experiments. That made the Kindle go back to connected state.
To me the above experiments show that enough TEST UNIT READY commands
are needed in the 2 s after a SYNCHRONIZE CACHE.
> Also, the usbmon trace shows that my guess about power management and
> device disconnections was completely wrong. The bus does not get
> suspended and the Kindle does not disconnect, even though it seems to
> become unusable.
>
Regards
Matthias
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-10 20:56 ` Matthias Schwarzott
@ 2021-03-10 21:46 ` Alan Stern
2021-03-11 6:05 ` Matthias Schwarzott
0 siblings, 1 reply; 33+ messages in thread
From: Alan Stern @ 2021-03-10 21:46 UTC (permalink / raw)
To: Matthias Schwarzott; +Cc: linux-usb, usb-storage, hirofumi
On Wed, Mar 10, 2021 at 09:56:04PM +0100, Matthias Schwarzott wrote:
> > What happens if you set the value to 1000 before running the test?
> >
> I tested different values. At 1000 it still disconnects. At lower values it
> no longer does this.
> I tested 200 up to 900. Even 900 ms is good enough to keep it connected.
>
> Btw. it is not a USB disconnect, but it just seems to plays medium ejected.
>
> Out of interest I called "sg_start -v -l /dev/sde" after one of the failing
> experiments. That made the Kindle go back to connected state.
>
> To me the above experiments show that enough TEST UNIT READY commands are
> needed in the 2 s after a SYNCHRONIZE CACHE.
So you have found the solution to your problem. Congratulations!
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-10 21:46 ` Alan Stern
@ 2021-03-11 6:05 ` Matthias Schwarzott
2021-03-11 14:39 ` Alan Stern
0 siblings, 1 reply; 33+ messages in thread
From: Matthias Schwarzott @ 2021-03-11 6:05 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, usb-storage, hirofumi
Am 10.03.21 um 22:46 schrieb Alan Stern:
> On Wed, Mar 10, 2021 at 09:56:04PM +0100, Matthias Schwarzott wrote:
>>> What happens if you set the value to 1000 before running the test?
>>>
>> I tested different values. At 1000 it still disconnects. At lower values it
>> no longer does this.
>> I tested 200 up to 900. Even 900 ms is good enough to keep it connected.
>>
>> Btw. it is not a USB disconnect, but it just seems to plays medium ejected.
>>
>> Out of interest I called "sg_start -v -l /dev/sde" after one of the failing
>> experiments. That made the Kindle go back to connected state.
>>
>> To me the above experiments show that enough TEST UNIT READY commands are
>> needed in the 2 s after a SYNCHRONIZE CACHE.
>
> So you have found the solution to your problem. Congratulations!
>
Thank you for your support.
For longterm I think it should work automatically.
Some options I can think of (ordered by my preference):
1. Kernel sends one or more TEST UNIT READY commands after every
SYNCHRONIZE CACHE to a Kindle device. Regardless of triggered by kernel
or by some user code via ioctl.
2. Kernel automatically chooses a low enough value for events_poll_msecs
if it detects kindle.
3. udev rule is added that matches the Kindle and sets events_poll_msecs.
3a) SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="disk",
ATTRS{product}=="Amazon Kindle", ATTR{events_poll_msecs}="900"
3b) SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="disk",
ATTRS{idVendor}=="1949", ATTRS{idProduct}=="0004",
ATTR{events_poll_msecs}="900"
4. Kernel sends one or more TEST UNIT READY commands after every
SYNCHRONIZE CACHE to a device (without matching).
I guess options 1 and 2 require a new entry in unusual_devs together
with a (new?) quirk.
Option 3 requires to get a new rule into udev.
And option 4 is ugly as it changes behaviour for usb-storage or scsi
disk device.
I would prefer option 1 or 2.
Do you know how high the overhead of having more TEST UNIT READY
commands is? (=How much better option 1 is compared to option 2?)
Matthias
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-11 6:05 ` Matthias Schwarzott
@ 2021-03-11 14:39 ` Alan Stern
2021-03-16 5:26 ` Matthias Schwarzott
0 siblings, 1 reply; 33+ messages in thread
From: Alan Stern @ 2021-03-11 14:39 UTC (permalink / raw)
To: Matthias Schwarzott; +Cc: linux-usb, usb-storage, hirofumi
On Thu, Mar 11, 2021 at 07:05:00AM +0100, Matthias Schwarzott wrote:
> Am 10.03.21 um 22:46 schrieb Alan Stern:
> > On Wed, Mar 10, 2021 at 09:56:04PM +0100, Matthias Schwarzott wrote:
> > > > What happens if you set the value to 1000 before running the test?
> > > >
> > > I tested different values. At 1000 it still disconnects. At lower values it
> > > no longer does this.
> > > I tested 200 up to 900. Even 900 ms is good enough to keep it connected.
> > >
> > > Btw. it is not a USB disconnect, but it just seems to plays medium ejected.
> > >
> > > Out of interest I called "sg_start -v -l /dev/sde" after one of the failing
> > > experiments. That made the Kindle go back to connected state.
> > >
> > > To me the above experiments show that enough TEST UNIT READY commands are
> > > needed in the 2 s after a SYNCHRONIZE CACHE.
> >
> > So you have found the solution to your problem. Congratulations!
> >
> Thank you for your support.
>
> For longterm I think it should work automatically.
> Some options I can think of (ordered by my preference):
>
> 1. Kernel sends one or more TEST UNIT READY commands after every SYNCHRONIZE
> CACHE to a Kindle device. Regardless of triggered by kernel or by some user
> code via ioctl.
>
> 2. Kernel automatically chooses a low enough value for events_poll_msecs if
> it detects kindle.
>
> 3. udev rule is added that matches the Kindle and sets events_poll_msecs.
> 3a) SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="disk",
> ATTRS{product}=="Amazon Kindle", ATTR{events_poll_msecs}="900"
>
> 3b) SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="disk",
> ATTRS{idVendor}=="1949", ATTRS{idProduct}=="0004",
> ATTR{events_poll_msecs}="900"
>
> 4. Kernel sends one or more TEST UNIT READY commands after every SYNCHRONIZE
> CACHE to a device (without matching).
>
>
> I guess options 1 and 2 require a new entry in unusual_devs together with a
> (new?) quirk.
It's not that simple. usb-storage does not create SCSI commands; it
merely sends commands that it receives from other parts of the kernel.
> Option 3 requires to get a new rule into udev.
> And option 4 is ugly as it changes behaviour for usb-storage or scsi disk
> device.
>
> I would prefer option 1 or 2.
I prefer option 3, although 2 would be acceptable in a pinch. The main
reason is because 3 is the only option that doesn't involve changing the
kernel. It's probably much easier to change a udev script. (For
example, that's something any user can quickly do themselves.)
> Do you know how high the overhead of having more TEST UNIT READY commands
> is? (=How much better option 1 is compared to option 2?)
Options 1 and 4 would be rather difficult to implement. 2 and 3 are a
lot simpler.
The overhead of TEST UNIT READY is pretty small. You can get an idea
for yourself by looking at the timestamps in the annotated extract of
the usbmon log that I sent back to you.
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-11 14:39 ` Alan Stern
@ 2021-03-16 5:26 ` Matthias Schwarzott
2021-03-16 16:26 ` Alan Stern
0 siblings, 1 reply; 33+ messages in thread
From: Matthias Schwarzott @ 2021-03-16 5:26 UTC (permalink / raw)
To: Alan Stern
Cc: linux-usb, usb-storage, hirofumi, Lennart Poettering, systemd-devel
Am 11.03.21 um 15:39 schrieb Alan Stern:
> On Thu, Mar 11, 2021 at 07:05:00AM +0100, Matthias Schwarzott wrote:
>> Am 10.03.21 um 22:46 schrieb Alan Stern:
>>> On Wed, Mar 10, 2021 at 09:56:04PM +0100, Matthias Schwarzott wrote:
>>>>> What happens if you set the value to 1000 before running the test?
>>>>>
>>>> I tested different values. At 1000 it still disconnects. At lower values it
>>>> no longer does this.
>>>> I tested 200 up to 900. Even 900 ms is good enough to keep it connected.
>>>>
>>>> Btw. it is not a USB disconnect, but it just seems to plays medium ejected.
>>>>
>>>> Out of interest I called "sg_start -v -l /dev/sde" after one of the failing
>>>> experiments. That made the Kindle go back to connected state.
>>>>
>>>> To me the above experiments show that enough TEST UNIT READY commands are
>>>> needed in the 2 s after a SYNCHRONIZE CACHE.
>>>
>>> So you have found the solution to your problem. Congratulations!
>>>
>> Thank you for your support.
>>
>> For longterm I think it should work automatically.
>> Some options I can think of (ordered by my preference):
>>
>> 1. Kernel sends one or more TEST UNIT READY commands after every SYNCHRONIZE
>> CACHE to a Kindle device. Regardless of triggered by kernel or by some user
>> code via ioctl.
>>
>> 2. Kernel automatically chooses a low enough value for events_poll_msecs if
>> it detects kindle.
>>
>> 3. udev rule is added that matches the Kindle and sets events_poll_msecs.
>> 3a) SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="disk",
>> ATTRS{product}=="Amazon Kindle", ATTR{events_poll_msecs}="900"
>>
>> 3b) SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="disk",
>> ATTRS{idVendor}=="1949", ATTRS{idProduct}=="0004",
>> ATTR{events_poll_msecs}="900"
>>
>> 4. Kernel sends one or more TEST UNIT READY commands after every SYNCHRONIZE
>> CACHE to a device (without matching).
>>
>>
>> I guess options 1 and 2 require a new entry in unusual_devs together with a
>> (new?) quirk.
>
> It's not that simple. usb-storage does not create SCSI commands; it
> merely sends commands that it receives from other parts of the kernel.
>
>> Option 3 requires to get a new rule into udev.
>> And option 4 is ugly as it changes behaviour for usb-storage or scsi disk
>> device.
>>
>> I would prefer option 1 or 2.
>
> I prefer option 3, although 2 would be acceptable in a pinch. The main
> reason is because 3 is the only option that doesn't involve changing the
> kernel. It's probably much easier to change a udev script. (For
> example, that's something any user can quickly do themselves.)
>
>> Do you know how high the overhead of having more TEST UNIT READY commands
>> is? (=How much better option 1 is compared to option 2?)
>
> Options 1 and 4 would be rather difficult to implement. 2 and 3 are a
> lot simpler.
>
> The overhead of TEST UNIT READY is pretty small. You can get an idea
> for yourself by looking at the timestamps in the annotated extract of
> the usbmon log that I sent back to you.
>
I implemented solution 3b. This is the pullrequest for udev (systemd
repository):
https://github.com/systemd/systemd/pull/19002
Now Lennart asks if udev is the best place for such hacks/work-arounds?
Well, I implemented it as suggested by Alan (see above). This was the
simplest of the considered alternatives. Different quirks in kernel has
been considered, but are more effort to be implemented.
Regards
Matthias
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-16 5:26 ` Matthias Schwarzott
@ 2021-03-16 16:26 ` Alan Stern
2021-03-16 16:43 ` [systemd-devel] " Hans de Goede
2021-03-16 21:43 ` [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache Matthias Schwarzott
0 siblings, 2 replies; 33+ messages in thread
From: Alan Stern @ 2021-03-16 16:26 UTC (permalink / raw)
To: Matthias Schwarzott
Cc: linux-usb, usb-storage, hirofumi, Lennart Poettering, systemd-devel
On Tue, Mar 16, 2021 at 06:26:30AM +0100, Matthias Schwarzott wrote:
> I implemented solution 3b. This is the pullrequest for udev (systemd
> repository):
>
> https://github.com/systemd/systemd/pull/19002
>
> Now Lennart asks if udev is the best place for such hacks/work-arounds?
>
> Well, I implemented it as suggested by Alan (see above). This was the
> simplest of the considered alternatives. Different quirks in kernel has been
> considered, but are more effort to be implemented.
Lennart probably isn't aware how the usb-storage driver works. It does
not create commands on its own; it merely sends the commands that it
gets from higher SCSI layers.
It may be possible to modify the SCSI core, to make it send a TEST UNIT
READY command immediately following any SYNCHRONIZE CACHE to a Kindle.
However, there may be an easier solution. usb-storage does indeed send
a command of its own, REQUEST SENSE, to get error data when a command
fails. The patch below will make it do the same thing whenever it sends
a SYNCHRONIZE CACHE to a Kindle, failure or not.
The only question is whether the Kindle will regard REQUEST SENSE as a
sufficient indication that it shouldn't do an eject. The only way to
find out is by testing the patch.
Alan Stern
Index: usb-devel/drivers/usb/storage/transport.c
===================================================================
--- usb-devel.orig/drivers/usb/storage/transport.c
+++ usb-devel/drivers/usb/storage/transport.c
@@ -656,6 +656,13 @@ void usb_stor_invoke_transport(struct sc
need_auto_sense = 1;
}
+ /* Some devices (Kindle) require another command after SYNC CACHE */
+ if (us->fflags & US_FL_CHECK_AFTER_SYNC &&
+ srb->cmnd[0] == SYNCHRONIZE_CACHE) {
+ usb_stor_dbg(us, "-- sense after SYNC CACHE\n");
+ need_auto_sense = 1;
+ }
+
/*
* If we have a failure, we're going to do a REQUEST_SENSE
* automatically. Note that we differentiate between a command
Index: usb-devel/drivers/usb/storage/unusual_devs.h
===================================================================
--- usb-devel.orig/drivers/usb/storage/unusual_devs.h
+++ usb-devel/drivers/usb/storage/unusual_devs.h
@@ -2212,6 +2212,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0
US_FL_NO_READ_DISC_INFO ),
/*
+ * Reported by Matthias Schwarzott <zzam@gentoo.org>
+ * The Amazon Kindle treats SYNCHRONIZE CACHE as an indication that
+ * the host may be finished with it, and automatically ejects its
+ * media unless it receives another command within one second.
+ */
+UNUSUAL_DEV( 0x1949, 0x0004, 0x0000, 0x9999,
+ "Amazon",
+ "Kindle",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_CHECK_AFTER_SYNC ),
+
+/*
* Reported by Oliver Neukum <oneukum@suse.com>
* This device morphes spontaneously into another device if the access
* pattern of Windows isn't followed. Thus writable media would be dirty
Index: usb-devel/include/linux/usb_usual.h
===================================================================
--- usb-devel.orig/include/linux/usb_usual.h
+++ usb-devel/include/linux/usb_usual.h
@@ -86,6 +86,8 @@
/* lies about caching, so always sync */ \
US_FLAG(NO_SAME, 0x40000000) \
/* Cannot handle WRITE_SAME */ \
+ US_FLAG(CHECK_AFTER_SYNC, 0x80000000) \
+ /* Check sense after SYNCHRONIZE_CACHE */ \
#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-16 16:26 ` Alan Stern
@ 2021-03-16 16:43 ` Hans de Goede
2021-03-16 17:04 ` Alan Stern
2021-03-16 21:43 ` [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache Matthias Schwarzott
1 sibling, 1 reply; 33+ messages in thread
From: Hans de Goede @ 2021-03-16 16:43 UTC (permalink / raw)
To: Alan Stern, Matthias Schwarzott
Cc: usb-storage, linux-usb, systemd-devel, hirofumi
Hi,
On 3/16/21 5:26 PM, Alan Stern wrote:
> On Tue, Mar 16, 2021 at 06:26:30AM +0100, Matthias Schwarzott wrote:
>> I implemented solution 3b. This is the pullrequest for udev (systemd
>> repository):
>>
>> https://github.com/systemd/systemd/pull/19002
>>
>> Now Lennart asks if udev is the best place for such hacks/work-arounds?
>>
>> Well, I implemented it as suggested by Alan (see above). This was the
>> simplest of the considered alternatives. Different quirks in kernel has been
>> considered, but are more effort to be implemented.
>
> Lennart probably isn't aware how the usb-storage driver works. It does
> not create commands on its own; it merely sends the commands that it
> gets from higher SCSI layers.
>
> It may be possible to modify the SCSI core, to make it send a TEST UNIT
> READY command immediately following any SYNCHRONIZE CACHE to a Kindle.
>
> However, there may be an easier solution. usb-storage does indeed send
> a command of its own, REQUEST SENSE, to get error data when a command
> fails. The patch below will make it do the same thing whenever it sends
> a SYNCHRONIZE CACHE to a Kindle, failure or not.
>
> The only question is whether the Kindle will regard REQUEST SENSE as a
> sufficient indication that it shouldn't do an eject. The only way to
> find out is by testing the patch.
>
> Alan Stern
Thank you for this patch, yes if this works it would IMHO be
a much better solution then the udev rule.
One question though, if this works to fix the undesired ejects,
will an actual eject (using e.g. the eject utility as say
"sudo eject /dev/sda") still be seen as an eject by the kindle
after this ?
Because that is actually kind of important for everyone using their
Kindle with Calibre, breaking that would not be good.
Regards,
Hans
>
>
>
> Index: usb-devel/drivers/usb/storage/transport.c
> ===================================================================
> --- usb-devel.orig/drivers/usb/storage/transport.c
> +++ usb-devel/drivers/usb/storage/transport.c
> @@ -656,6 +656,13 @@ void usb_stor_invoke_transport(struct sc
> need_auto_sense = 1;
> }
>
> + /* Some devices (Kindle) require another command after SYNC CACHE */
> + if (us->fflags & US_FL_CHECK_AFTER_SYNC &&
> + srb->cmnd[0] == SYNCHRONIZE_CACHE) {
> + usb_stor_dbg(us, "-- sense after SYNC CACHE\n");
> + need_auto_sense = 1;
> + }
> +
> /*
> * If we have a failure, we're going to do a REQUEST_SENSE
> * automatically. Note that we differentiate between a command
> Index: usb-devel/drivers/usb/storage/unusual_devs.h
> ===================================================================
> --- usb-devel.orig/drivers/usb/storage/unusual_devs.h
> +++ usb-devel/drivers/usb/storage/unusual_devs.h
> @@ -2212,6 +2212,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0
> US_FL_NO_READ_DISC_INFO ),
>
> /*
> + * Reported by Matthias Schwarzott <zzam@gentoo.org>
> + * The Amazon Kindle treats SYNCHRONIZE CACHE as an indication that
> + * the host may be finished with it, and automatically ejects its
> + * media unless it receives another command within one second.
> + */
> +UNUSUAL_DEV( 0x1949, 0x0004, 0x0000, 0x9999,
> + "Amazon",
> + "Kindle",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_CHECK_AFTER_SYNC ),
> +
> +/*
> * Reported by Oliver Neukum <oneukum@suse.com>
> * This device morphes spontaneously into another device if the access
> * pattern of Windows isn't followed. Thus writable media would be dirty
> Index: usb-devel/include/linux/usb_usual.h
> ===================================================================
> --- usb-devel.orig/include/linux/usb_usual.h
> +++ usb-devel/include/linux/usb_usual.h
> @@ -86,6 +86,8 @@
> /* lies about caching, so always sync */ \
> US_FLAG(NO_SAME, 0x40000000) \
> /* Cannot handle WRITE_SAME */ \
> + US_FLAG(CHECK_AFTER_SYNC, 0x80000000) \
> + /* Check sense after SYNCHRONIZE_CACHE */ \
>
> #define US_FLAG(name, value) US_FL_##name = value ,
> enum { US_DO_ALL_FLAGS };
> _______________________________________________
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-16 16:43 ` [systemd-devel] " Hans de Goede
@ 2021-03-16 17:04 ` Alan Stern
2021-03-16 21:52 ` Matthias Schwarzott
2021-03-17 12:21 ` Hans de Goede
0 siblings, 2 replies; 33+ messages in thread
From: Alan Stern @ 2021-03-16 17:04 UTC (permalink / raw)
To: Hans de Goede
Cc: Matthias Schwarzott, usb-storage, linux-usb, systemd-devel, hirofumi
On Tue, Mar 16, 2021 at 05:43:34PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/16/21 5:26 PM, Alan Stern wrote:
> > On Tue, Mar 16, 2021 at 06:26:30AM +0100, Matthias Schwarzott wrote:
> >> I implemented solution 3b. This is the pullrequest for udev (systemd
> >> repository):
> >>
> >> https://github.com/systemd/systemd/pull/19002
> >>
> >> Now Lennart asks if udev is the best place for such hacks/work-arounds?
> >>
> >> Well, I implemented it as suggested by Alan (see above). This was the
> >> simplest of the considered alternatives. Different quirks in kernel has been
> >> considered, but are more effort to be implemented.
> >
> > Lennart probably isn't aware how the usb-storage driver works. It does
> > not create commands on its own; it merely sends the commands that it
> > gets from higher SCSI layers.
> >
> > It may be possible to modify the SCSI core, to make it send a TEST UNIT
> > READY command immediately following any SYNCHRONIZE CACHE to a Kindle.
> >
> > However, there may be an easier solution. usb-storage does indeed send
> > a command of its own, REQUEST SENSE, to get error data when a command
> > fails. The patch below will make it do the same thing whenever it sends
> > a SYNCHRONIZE CACHE to a Kindle, failure or not.
> >
> > The only question is whether the Kindle will regard REQUEST SENSE as a
> > sufficient indication that it shouldn't do an eject. The only way to
> > find out is by testing the patch.
> >
> > Alan Stern
>
> Thank you for this patch, yes if this works it would IMHO be
> a much better solution then the udev rule.
I think it would be mildly better, but not a whole lot. Since the
Kindle describes itself as having removable media, the kernel normally
probes it periodically to make sure the media remains present. The
default probing interval is 2 seconds. Reducing it to 0.9 seconds
doesn't represent an exorbitant additional load IMO -- especially since
Kindles don't tend to spend huge amounts of time connected to computers.
If it's merely a question of where to change the polling interval from
the default (automatically in the kernel or by userspace), that also
doesn't seem like a terribly important choice. Certainly a udev rule or
hwdb entry is a lot easier to maintain than special-case code in the
kernel.
> One question though, if this works to fix the undesired ejects,
> will an actual eject (using e.g. the eject utility as say
> "sudo eject /dev/sda") still be seen as an eject by the kindle
> after this ?
It should be. Maybe Matthias will try it and let us know.
> Because that is actually kind of important for everyone using their
> Kindle with Calibre, breaking that would not be good.
Of course.
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-16 16:26 ` Alan Stern
2021-03-16 16:43 ` [systemd-devel] " Hans de Goede
@ 2021-03-16 21:43 ` Matthias Schwarzott
1 sibling, 0 replies; 33+ messages in thread
From: Matthias Schwarzott @ 2021-03-16 21:43 UTC (permalink / raw)
To: Alan Stern
Cc: linux-usb, usb-storage, hirofumi, Lennart Poettering, systemd-devel
Am 16.03.21 um 17:26 schrieb Alan Stern:
> On Tue, Mar 16, 2021 at 06:26:30AM +0100, Matthias Schwarzott wrote:
>> I implemented solution 3b. This is the pullrequest for udev (systemd
>> repository):
>>
>> https://github.com/systemd/systemd/pull/19002
>>
>> Now Lennart asks if udev is the best place for such hacks/work-arounds?
>>
>> Well, I implemented it as suggested by Alan (see above). This was the
>> simplest of the considered alternatives. Different quirks in kernel has been
>> considered, but are more effort to be implemented.
>
> Lennart probably isn't aware how the usb-storage driver works. It does
> not create commands on its own; it merely sends the commands that it
> gets from higher SCSI layers.
>
> It may be possible to modify the SCSI core, to make it send a TEST UNIT
> READY command immediately following any SYNCHRONIZE CACHE to a Kindle.
>
> However, there may be an easier solution. usb-storage does indeed send
> a command of its own, REQUEST SENSE, to get error data when a command
> fails. The patch below will make it do the same thing whenever it sends
> a SYNCHRONIZE CACHE to a Kindle, failure or not.
>
> The only question is whether the Kindle will regard REQUEST SENSE as a
> sufficient indication that it shouldn't do an eject. The only way to
> find out is by testing the patch.
>
The patch is a lot shorter than I expected it to be.
I tried it. The new udev-rule is commented, so polling interval is back
at 2000 ms.
Testing it:
# cat /sys/block/sde/events_poll_msecs
-1
# cat /sys/module/block/parameters/events_dfl_poll_msecs
2000
# python -c "import time; import os; f = open('/dev/sde1', 'r+b');
os.fsync(f); time.sleep(4)"
This is wireshark output of the test:
85 4.701949 host 3.8.1 USBMS 95 SCSI: Test Unit Ready LUN: 0x00
86 4.701972 3.8.1 host USB 64 URB_BULK out
87 4.701975 host 3.8.1 USB 64 URB_BULK in
88 4.702030 3.8.1 host USBMS 77 SCSI: Response LUN: 0x00 (Test Unit
Ready) (Good)
89 4.702043 host 3.8.1 USBMS 95 SCSI: Prevent/Allow Medium Removal LUN:
0x00 PREVENT
90 4.702069 3.8.1 host USB 64 URB_BULK out
91 4.702072 host 3.8.1 USB 64 URB_BULK in
92 4.703006 3.8.1 host USBMS 77 SCSI: Response LUN: 0x00 (Prevent/Allow
Medium Removal) (Good)
93 4.703052 host 3.8.1 USBMS 95 SCSI: Synchronize Cache(10) LUN: 0x00
(LBA: 0x00000000, Len: 0)
94 4.703066 3.8.1 host USB 64 URB_BULK out
95 4.703067 host 3.8.1 USB 64 URB_BULK in
96 4.704146 3.8.1 host USBMS 77 SCSI: Response LUN: 0x00 (Synchronize
Cache(10)) (Good)
97 4.704149 host 3.8.1 USBMS 95 SCSI: Request Sense LUN: 0x00
98 4.704177 3.8.1 host USB 64 URB_BULK out
99 4.704179 host 3.8.1 USB 64 URB_BULK in
100 4.705032 3.8.1 host USBMS 82 SCSI: Data In LUN: 0x00 (Request Sense
Response Data)
101 4.705035 host 3.8.1 USB 64 URB_BULK in
102 4.705053 3.8.1 host USBMS 77 SCSI: Response LUN: 0x00 (Request
Sense) (Good)
105 6.740272 host 3.8.1 USBMS 95 SCSI: Test Unit Ready LUN: 0x00
106 6.740323 3.8.1 host USB 64 URB_BULK out
107 6.740326 host 3.8.1 USB 64 URB_BULK in
108 6.740410 3.8.1 host USBMS 77 SCSI: Response LUN: 0x00 (Test Unit
Ready) (Good)
195 8.709417 host 3.8.1 USBMS 95 SCSI: Prevent/Allow Medium Removal LUN:
0x00 ALLOW
196 8.709441 3.8.1 host USB 64 URB_BULK out
197 8.709445 host 3.8.1 USB 64 URB_BULK in
198 8.709645 3.8.1 host USBMS 77 SCSI: Response LUN: 0x00 (Prevent/Allow
Medium Removal) (Good)
The patch indeed works. The kindle does not disconnect.
I also tried with a sync on a mounted filesystem. The effect is the
same: No disconnect.
Calling "eject /dev/sde" still works as it should.
Tested-by: Matthias Schwarzott <zzam@gentoo.org>
Regards
Matthias
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-16 17:04 ` Alan Stern
@ 2021-03-16 21:52 ` Matthias Schwarzott
2021-03-17 12:21 ` Hans de Goede
1 sibling, 0 replies; 33+ messages in thread
From: Matthias Schwarzott @ 2021-03-16 21:52 UTC (permalink / raw)
To: Alan Stern, Hans de Goede; +Cc: usb-storage, linux-usb, systemd-devel, hirofumi
Am 16.03.21 um 18:04 schrieb Alan Stern:
> On Tue, Mar 16, 2021 at 05:43:34PM +0100, Hans de Goede wrote:
>>
>> Thank you for this patch, yes if this works it would IMHO be
>> a much better solution then the udev rule.
>
Thank you for the patch.
> I think it would be mildly better, but not a whole lot. Since the
> Kindle describes itself as having removable media, the kernel normally
> probes it periodically to make sure the media remains present. The
> default probing interval is 2 seconds. Reducing it to 0.9 seconds
> doesn't represent an exorbitant additional load IMO -- especially since
> Kindles don't tend to spend huge amounts of time connected to computers.
>
> If it's merely a question of where to change the polling interval from
> the default (automatically in the kernel or by userspace), that also
> doesn't seem like a terribly important choice. Certainly a udev rule or
> hwdb entry is a lot easier to maintain than special-case code in the
> kernel.
>
>> One question though, if this works to fix the undesired ejects,
>> will an actual eject (using e.g. the eject utility as say
>> "sudo eject /dev/sda") still be seen as an eject by the kindle
>> after this ?
>
> It should be. Maybe Matthias will try it and let us know.
>
Just for reference a direct answer here:
Yes, eject keeps working as it should.
>> Because that is actually kind of important for everyone using their
>> Kindle with Calibre, breaking that would not be good.
I also tried to upload a book using calibre (without disabling any
workarounds in calibre).
The full process did work fine.
Regards
Matthias
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-16 17:04 ` Alan Stern
2021-03-16 21:52 ` Matthias Schwarzott
@ 2021-03-17 12:21 ` Hans de Goede
2021-03-17 15:17 ` Alan Stern
1 sibling, 1 reply; 33+ messages in thread
From: Hans de Goede @ 2021-03-17 12:21 UTC (permalink / raw)
To: Alan Stern
Cc: Matthias Schwarzott, usb-storage, linux-usb, systemd-devel, hirofumi
Hi,
On 3/16/21 6:04 PM, Alan Stern wrote:
> On Tue, Mar 16, 2021 at 05:43:34PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 3/16/21 5:26 PM, Alan Stern wrote:
>>> On Tue, Mar 16, 2021 at 06:26:30AM +0100, Matthias Schwarzott wrote:
>>>> I implemented solution 3b. This is the pullrequest for udev (systemd
>>>> repository):
>>>>
>>>> https://github.com/systemd/systemd/pull/19002
>>>>
>>>> Now Lennart asks if udev is the best place for such hacks/work-arounds?
>>>>
>>>> Well, I implemented it as suggested by Alan (see above). This was the
>>>> simplest of the considered alternatives. Different quirks in kernel has been
>>>> considered, but are more effort to be implemented.
>>>
>>> Lennart probably isn't aware how the usb-storage driver works. It does
>>> not create commands on its own; it merely sends the commands that it
>>> gets from higher SCSI layers.
>>>
>>> It may be possible to modify the SCSI core, to make it send a TEST UNIT
>>> READY command immediately following any SYNCHRONIZE CACHE to a Kindle.
>>>
>>> However, there may be an easier solution. usb-storage does indeed send
>>> a command of its own, REQUEST SENSE, to get error data when a command
>>> fails. The patch below will make it do the same thing whenever it sends
>>> a SYNCHRONIZE CACHE to a Kindle, failure or not.
>>>
>>> The only question is whether the Kindle will regard REQUEST SENSE as a
>>> sufficient indication that it shouldn't do an eject. The only way to
>>> find out is by testing the patch.
>>>
>>> Alan Stern
>>
>> Thank you for this patch, yes if this works it would IMHO be
>> a much better solution then the udev rule.
>
> I think it would be mildly better, but not a whole lot. Since the
> Kindle describes itself as having removable media, the kernel normally
> probes it periodically to make sure the media remains present. The
> default probing interval is 2 seconds. Reducing it to 0.9 seconds
> doesn't represent an exorbitant additional load IMO -- especially since
> Kindles don't tend to spend huge amounts of time connected to computers.
Ah, I did not know that the default polling interval was that low(ish),
given that the default indeed is already that low, then changing it to
0.8 seconds would not be a big change. And we probably have a lot of
lower hanging fruit for unnecessary wakeups then that.
Regards,
Hans
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-17 12:21 ` Hans de Goede
@ 2021-03-17 15:17 ` Alan Stern
2021-03-17 16:47 ` Lennart Poettering
2021-03-17 17:56 ` [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache Matthias Schwarzott
0 siblings, 2 replies; 33+ messages in thread
From: Alan Stern @ 2021-03-17 15:17 UTC (permalink / raw)
To: Hans de Goede
Cc: Matthias Schwarzott, usb-storage, linux-usb, systemd-devel, hirofumi
On Wed, Mar 17, 2021 at 01:21:50PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/16/21 6:04 PM, Alan Stern wrote:
> > I think it would be mildly better, but not a whole lot. Since the
> > Kindle describes itself as having removable media, the kernel normally
> > probes it periodically to make sure the media remains present. The
> > default probing interval is 2 seconds. Reducing it to 0.9 seconds
> > doesn't represent an exorbitant additional load IMO -- especially since
> > Kindles don't tend to spend huge amounts of time connected to computers.
>
> Ah, I did not know that the default polling interval was that low(ish),
> given that the default indeed is already that low, then changing it to
> 0.8 seconds would not be a big change. And we probably have a lot of
> lower hanging fruit for unnecessary wakeups then that.
So we need to make a decision: Should the patch be merged, or should we
punt the issue to userspace tools?
On the plus side, the patch is rather small and non-invasive (although
it does allocate the last remaining bit in the 32-bit fflags field).
There's also the advantage of sending the extra command only when it is
needed, as opposed to increasing the overall frequency of TUR polling.
Any opinions?
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-17 15:17 ` Alan Stern
@ 2021-03-17 16:47 ` Lennart Poettering
[not found] ` <F279F9BC020000F5AE14D9EC@gwsmtp.uni-regensburg.de>
2021-03-17 17:56 ` [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache Matthias Schwarzott
1 sibling, 1 reply; 33+ messages in thread
From: Lennart Poettering @ 2021-03-17 16:47 UTC (permalink / raw)
To: Alan Stern
Cc: Hans de Goede, usb-storage, Matthias Schwarzott, linux-usb,
systemd-devel, hirofumi
On Mi, 17.03.21 11:17, Alan Stern (stern@rowland.harvard.edu) wrote:
> On Wed, Mar 17, 2021 at 01:21:50PM +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 3/16/21 6:04 PM, Alan Stern wrote:
> > > I think it would be mildly better, but not a whole lot. Since the
> > > Kindle describes itself as having removable media, the kernel normally
> > > probes it periodically to make sure the media remains present. The
> > > default probing interval is 2 seconds. Reducing it to 0.9 seconds
> > > doesn't represent an exorbitant additional load IMO -- especially since
> > > Kindles don't tend to spend huge amounts of time connected to computers.
> >
> > Ah, I did not know that the default polling interval was that low(ish),
> > given that the default indeed is already that low, then changing it to
> > 0.8 seconds would not be a big change. And we probably have a lot of
> > lower hanging fruit for unnecessary wakeups then that.
>
> So we need to make a decision: Should the patch be merged, or should we
> punt the issue to userspace tools?
>
> On the plus side, the patch is rather small and non-invasive (although
> it does allocate the last remaining bit in the 32-bit fflags field).
> There's also the advantage of sending the extra command only when it is
> needed, as opposed to increasing the overall frequency of TUR polling.
>
> Any opinions?
I'd argue that this should be done in the kernel.
IIUC the issue can actually lead to data corruption, no? i.e. some
program writes 25 different files to different places on such an fs,
then calls fsync() on one of them but not the others. Then quite
possibly the fsync() will trigger a device disconnect sooner or later
at which point the one file surely hit the disk, but there's no
guarantee for the other 24, they might remain cached in memory and are
never written out.
I'd say quirks that are necessary to avoid data corruption should
better be done in the kernel and udev's hwdb stuff is only for stuff
that "fills in gaps", i.e. adds additional tweaks that make things
prettier, cleaner, nicer, more efficient but not things that make the
basic things work, and data integrity sounds pretty basic to me.
Or to give a counter example: the device advertises it can do media
change, but actually cannot, right, it's not a floppy drive or cdrom
driver after all? maybe hwdb would thus actually be the place for the
opposite of the suggested fix: turn off the media change polling to
reduce needless wakeups.
I mean, I'd be more open to this if this was a frequent thing and the
database for devices like this was just tooo large for the kernel to
carry, but that's not the case here either: it's two devices afaik,
and such an issue wasn't seen elswhere.
Lennart
--
Lennart Poettering, Berlin
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-17 15:17 ` Alan Stern
2021-03-17 16:47 ` Lennart Poettering
@ 2021-03-17 17:56 ` Matthias Schwarzott
2021-03-17 18:31 ` Hans de Goede
2021-03-17 19:06 ` [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload Alan Stern
1 sibling, 2 replies; 33+ messages in thread
From: Matthias Schwarzott @ 2021-03-17 17:56 UTC (permalink / raw)
To: Alan Stern, Hans de Goede; +Cc: usb-storage, linux-usb, systemd-devel, hirofumi
Am 17.03.21 um 16:17 schrieb Alan Stern:
> On Wed, Mar 17, 2021 at 01:21:50PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 3/16/21 6:04 PM, Alan Stern wrote:
>>> I think it would be mildly better, but not a whole lot. Since the
>>> Kindle describes itself as having removable media, the kernel normally
>>> probes it periodically to make sure the media remains present. The
>>> default probing interval is 2 seconds. Reducing it to 0.9 seconds
>>> doesn't represent an exorbitant additional load IMO -- especially since
>>> Kindles don't tend to spend huge amounts of time connected to computers.
>>
>> Ah, I did not know that the default polling interval was that low(ish),
>> given that the default indeed is already that low, then changing it to
>> 0.8 seconds would not be a big change. And we probably have a lot of
>> lower hanging fruit for unnecessary wakeups then that.
>
> So we need to make a decision: Should the patch be merged, or should we
> punt the issue to userspace tools?
>
> On the plus side, the patch is rather small and non-invasive (although
> it does allocate the last remaining bit in the 32-bit fflags field).
> There's also the advantage of sending the extra command only when it is
> needed, as opposed to increasing the overall frequency of TUR polling.
>
> Any opinions?
I would vote to do in kernel as that is a cleaner solution:
1. It will work out of the box.
2. It only sends one extra command when needed.
3. It makes the block-device not break if user-space adjusts the poll
interval to higher values.
Matthias
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-17 17:56 ` [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache Matthias Schwarzott
@ 2021-03-17 18:31 ` Hans de Goede
2021-03-17 19:06 ` [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload Alan Stern
1 sibling, 0 replies; 33+ messages in thread
From: Hans de Goede @ 2021-03-17 18:31 UTC (permalink / raw)
To: Matthias Schwarzott, Alan Stern
Cc: usb-storage, linux-usb, systemd-devel, hirofumi
Hi,
On 3/17/21 6:56 PM, Matthias Schwarzott wrote:
> Am 17.03.21 um 16:17 schrieb Alan Stern:
>> On Wed, Mar 17, 2021 at 01:21:50PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 3/16/21 6:04 PM, Alan Stern wrote:
>>>> I think it would be mildly better, but not a whole lot. Since the
>>>> Kindle describes itself as having removable media, the kernel normally
>>>> probes it periodically to make sure the media remains present. The
>>>> default probing interval is 2 seconds. Reducing it to 0.9 seconds
>>>> doesn't represent an exorbitant additional load IMO -- especially since
>>>> Kindles don't tend to spend huge amounts of time connected to computers.
>>>
>>> Ah, I did not know that the default polling interval was that low(ish),
>>> given that the default indeed is already that low, then changing it to
>>> 0.8 seconds would not be a big change. And we probably have a lot of
>>> lower hanging fruit for unnecessary wakeups then that.
>>
>> So we need to make a decision: Should the patch be merged, or should we
>> punt the issue to userspace tools?
>>
>> On the plus side, the patch is rather small and non-invasive (although
>> it does allocate the last remaining bit in the 32-bit fflags field).
>> There's also the advantage of sending the extra command only when it is
>> needed, as opposed to increasing the overall frequency of TUR polling.
>>
>> Any opinions?
>
> I would vote to do in kernel as that is a cleaner solution:
>
> 1. It will work out of the box.
> 2. It only sends one extra command when needed.
> 3. It makes the block-device not break if user-space adjusts the poll interval to higher values.
FWIW my vote goes to the in kernel fix too.
Regards,
Hans
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload
2021-03-17 17:56 ` [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache Matthias Schwarzott
2021-03-17 18:31 ` Hans de Goede
@ 2021-03-17 19:06 ` Alan Stern
2021-03-18 11:39 ` Hans de Goede
2021-03-18 13:50 ` [systemd-devel] " Tomasz Torcz
1 sibling, 2 replies; 33+ messages in thread
From: Alan Stern @ 2021-03-17 19:06 UTC (permalink / raw)
To: Greg KH
Cc: Matthias Schwarzott, Hans de Goede, usb-storage, linux-usb,
systemd-devel, hirofumi
Matthias reports that the Amazon Kindle automatically removes its
emulated media if it doesn't receive another SCSI command within about
one second after a SYNCHRONIZE CACHE. It does so even when the host
has sent a PREVENT MEDIUM REMOVAL command. The reason for this
behavior isn't clear, although it's not hard to make some guesses.
At any rate, the results can be unexpected for anyone who tries to
access the Kindle in an unusual fashion, and in theory they can lead
to data loss (for example, if one file is closed and synchronized
while other files are still in the middle of being written).
To avoid such problems, this patch creates a new usb-storage quirks
flag telling the driver always to issue a REQUEST SENSE following a
SYNCHRONIZE CACHE command, and adds an unusual_devs entry for the
Kindle with the flag set. This is sufficient to prevent the Kindle
from doing its automatic unload, without interfering with proper
operation.
Another possible way to deal with this would be to increase the
frequency of TEST UNIT READY polling that the kernel normally carries
out for removable-media storage devices. However that would increase
the overall load on the system and it is not as reliable, because the
user can override the polling interval. Changing the driver's
behavior is safer and has minimal overhead.
Reported-and-tested-by: Matthias Schwarzott <zzam@gentoo.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
---
[as1953]
drivers/usb/storage/transport.c | 7 +++++++
drivers/usb/storage/unusual_devs.h | 12 ++++++++++++
include/linux/usb_usual.h | 2 ++
3 files changed, 21 insertions(+)
Index: usb-devel/drivers/usb/storage/transport.c
===================================================================
--- usb-devel.orig/drivers/usb/storage/transport.c
+++ usb-devel/drivers/usb/storage/transport.c
@@ -656,6 +656,13 @@ void usb_stor_invoke_transport(struct sc
need_auto_sense = 1;
}
+ /* Some devices (Kindle) require another command after SYNC CACHE */
+ if ((us->fflags & US_FL_SENSE_AFTER_SYNC) &&
+ srb->cmnd[0] == SYNCHRONIZE_CACHE) {
+ usb_stor_dbg(us, "-- sense after SYNC CACHE\n");
+ need_auto_sense = 1;
+ }
+
/*
* If we have a failure, we're going to do a REQUEST_SENSE
* automatically. Note that we differentiate between a command
Index: usb-devel/drivers/usb/storage/unusual_devs.h
===================================================================
--- usb-devel.orig/drivers/usb/storage/unusual_devs.h
+++ usb-devel/drivers/usb/storage/unusual_devs.h
@@ -2212,6 +2212,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0
US_FL_NO_READ_DISC_INFO ),
/*
+ * Reported by Matthias Schwarzott <zzam@gentoo.org>
+ * The Amazon Kindle treats SYNCHRONIZE CACHE as an indication that
+ * the host may be finished with it, and automatically ejects its
+ * emulated media unless it receives another command within one second.
+ */
+UNUSUAL_DEV( 0x1949, 0x0004, 0x0000, 0x9999,
+ "Amazon",
+ "Kindle",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_SENSE_AFTER_SYNC ),
+
+/*
* Reported by Oliver Neukum <oneukum@suse.com>
* This device morphes spontaneously into another device if the access
* pattern of Windows isn't followed. Thus writable media would be dirty
Index: usb-devel/include/linux/usb_usual.h
===================================================================
--- usb-devel.orig/include/linux/usb_usual.h
+++ usb-devel/include/linux/usb_usual.h
@@ -86,6 +86,8 @@
/* lies about caching, so always sync */ \
US_FLAG(NO_SAME, 0x40000000) \
/* Cannot handle WRITE_SAME */ \
+ US_FLAG(SENSE_AFTER_SYNC, 0x80000000) \
+ /* Do REQUEST_SENSE after SYNCHRONIZE_CACHE */ \
#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
^ permalink raw reply [flat|nested] 33+ messages in thread
* Antw: [EXT] Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
[not found] ` <52CC0074020000A3D68BC3D5@gwsmtp.uni-regensburg.de>
@ 2021-03-18 7:03 ` Ulrich Windl
2021-03-18 14:59 ` Alan Stern
0 siblings, 1 reply; 33+ messages in thread
From: Ulrich Windl @ 2021-03-18 7:03 UTC (permalink / raw)
To: Lennart Poettering, stern
Cc: zzam, systemd-devel, usb-storage, hirofumi, linux-usb
>>> Lennart Poettering <lennart@poettering.net> schrieb am 17.03.2021 um 17:47
in
Nachricht <YFIyidaZZmDoTevB@gardel-login>:
> On Mi, 17.03.21 11:17, Alan Stern (stern@rowland.harvard.edu) wrote:
>
>> On Wed, Mar 17, 2021 at 01:21:50PM +0100, Hans de Goede wrote:
>> > Hi,
>> >
>> > On 3/16/21 6:04 PM, Alan Stern wrote:
>> > > I think it would be mildly better, but not a whole lot. Since the
>> > > Kindle describes itself as having removable media, the kernel normally
>> > > probes it periodically to make sure the media remains present. The
>> > > default probing interval is 2 seconds. Reducing it to 0.9 seconds
>> > > doesn't represent an exorbitant additional load IMO ‑‑ especially
since
>> > > Kindles don't tend to spend huge amounts of time connected to
computers.
>> >
>> > Ah, I did not know that the default polling interval was that low(ish),
>> > given that the default indeed is already that low, then changing it to
>> > 0.8 seconds would not be a big change. And we probably have a lot of
>> > lower hanging fruit for unnecessary wakeups then that.
>>
>> So we need to make a decision: Should the patch be merged, or should we
>> punt the issue to userspace tools?
>>
>> On the plus side, the patch is rather small and non‑invasive (although
>> it does allocate the last remaining bit in the 32‑bit fflags field).
>> There's also the advantage of sending the extra command only when it is
>> needed, as opposed to increasing the overall frequency of TUR polling.
>>
>> Any opinions?
>
> I'd argue that this should be done in the kernel.
>
> IIUC the issue can actually lead to data corruption, no? i.e. some
> program writes 25 different files to different places on such an fs,
> then calls fsync() on one of them but not the others. Then quite
> possibly the fsync() will trigger a device disconnect sooner or later
> at which point the one file surely hit the disk, but there's no
> guarantee for the other 24, they might remain cached in memory and are
> never written out.
>
> I'd say quirks that are necessary to avoid data corruption should
> better be done in the kernel and udev's hwdb stuff is only for stuff
> that "fills in gaps", i.e. adds additional tweaks that make things
> prettier, cleaner, nicer, more efficient but not things that make the
> basic things work, and data integrity sounds pretty basic to me.
But seeing the list of bad, broken or ill-designed hardware grow year by year,
I wonder whether we really want all that bloat in the kernel.
>
> Or to give a counter example: the device advertises it can do media
> change, but actually cannot, right, it's not a floppy drive or cdrom
> driver after all? maybe hwdb would thus actually be the place for the
> opposite of the suggested fix: turn off the media change polling to
> reduce needless wakeups.
I actually think it would be best if those work-arounds could be loadable as
module, and the vendors of broken hardware can provide the modules that
document their broken design as well.
>
> I mean, I'd be more open to this if this was a frequent thing and the
> database for devices like this was just tooo large for the kernel to
> carry, but that's not the case here either: it's two devices afaik,
> and such an issue wasn't seen elswhere.
...two _more_ devices...
>
> Lennart
>
> ‑‑
> Lennart Poettering, Berlin
> _______________________________________________
> systemd‑devel mailing list
> systemd‑devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Antw: [EXT] Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
[not found] ` <474C42CD02000091AE14D9EC@gwsmtp.uni-regensburg.de>
@ 2021-03-18 7:04 ` Ulrich Windl
[not found] ` <D43A6F56020000F865972EEF@gwsmtp.uni-regensburg.de>
1 sibling, 0 replies; 33+ messages in thread
From: Ulrich Windl @ 2021-03-18 7:04 UTC (permalink / raw)
To: zzam, hdegoede, stern; +Cc: systemd-devel, usb-storage, hirofumi, linux-usb
>>> Matthias Schwarzott <zzam@gentoo.org> schrieb am 17.03.2021 um 18:56 in
Nachricht <5f8c0755-0884-f505-c4e8-3a5e89001d58@gentoo.org>:
> Am 17.03.21 um 16:17 schrieb Alan Stern:
>> On Wed, Mar 17, 2021 at 01:21:50PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 3/16/21 6:04 PM, Alan Stern wrote:
>>>> I think it would be mildly better, but not a whole lot. Since the
>>>> Kindle describes itself as having removable media, the kernel normally
>>>> probes it periodically to make sure the media remains present. The
>>>> default probing interval is 2 seconds. Reducing it to 0.9 seconds
>>>> doesn't represent an exorbitant additional load IMO ‑‑ especially since
>>>> Kindles don't tend to spend huge amounts of time connected to computers.
>>>
>>> Ah, I did not know that the default polling interval was that low(ish),
>>> given that the default indeed is already that low, then changing it to
>>> 0.8 seconds would not be a big change. And we probably have a lot of
>>> lower hanging fruit for unnecessary wakeups then that.
>>
>> So we need to make a decision: Should the patch be merged, or should we
>> punt the issue to userspace tools?
>>
>> On the plus side, the patch is rather small and non‑invasive (although
>> it does allocate the last remaining bit in the 32‑bit fflags field).
>> There's also the advantage of sending the extra command only when it is
>> needed, as opposed to increasing the overall frequency of TUR polling.
>>
>> Any opinions?
>
> I would vote to do in kernel as that is a cleaner solution:
>
> 1. It will work out of the box.
...once you have the right kernel
> 2. It only sends one extra command when needed.
> 3. It makes the block‑device not break if user‑space adjusts the poll
> interval to higher values.
>
> Matthias
> _______________________________________________
> systemd‑devel mailing list
> systemd‑devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Antw: [EXT] [systemd-devel] [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload
[not found] ` <D43A6F56020000F865972EEF@gwsmtp.uni-regensburg.de>
@ 2021-03-18 7:10 ` Ulrich Windl
2021-03-18 15:03 ` Alan Stern
0 siblings, 1 reply; 33+ messages in thread
From: Ulrich Windl @ 2021-03-18 7:10 UTC (permalink / raw)
To: Greg KH, stern; +Cc: zzam, systemd-devel, usb-storage, hirofumi, linux-usb
>>> Alan Stern <stern@rowland.harvard.edu> schrieb am 17.03.2021 um 20:06 in
Nachricht <20210317190654.GA497856@rowland.harvard.edu>:
> Matthias reports that the Amazon Kindle automatically removes its
> emulated media if it doesn't receive another SCSI command within about
> one second after a SYNCHRONIZE CACHE. It does so even when the host
> has sent a PREVENT MEDIUM REMOVAL command. The reason for this
> behavior isn't clear, although it's not hard to make some guesses.
Actually I think Amazon should fix the firmware.
It seems the main goal was to prevent the use of open software to manage the
content.
>
> At any rate, the results can be unexpected for anyone who tries to
> access the Kindle in an unusual fashion, and in theory they can lead
> to data loss (for example, if one file is closed and synchronized
> while other files are still in the middle of being written).
>
> To avoid such problems, this patch creates a new usb‑storage quirks
> flag telling the driver always to issue a REQUEST SENSE following a
> SYNCHRONIZE CACHE command, and adds an unusual_devs entry for the
> Kindle with the flag set. This is sufficient to prevent the Kindle
> from doing its automatic unload, without interfering with proper
> operation.
>
> Another possible way to deal with this would be to increase the
> frequency of TEST UNIT READY polling that the kernel normally carries
> out for removable‑media storage devices. However that would increase
> the overall load on the system and it is not as reliable, because the
> user can override the polling interval. Changing the driver's
> behavior is safer and has minimal overhead.
>
> Reported‑and‑tested‑by: Matthias Schwarzott <zzam@gentoo.org>
> Signed‑off‑by: Alan Stern <stern@rowland.harvard.edu>
> CC: <stable@vger.kernel.org>
>
> ‑‑‑
>
>
> [as1953]
>
>
> drivers/usb/storage/transport.c | 7 +++++++
> drivers/usb/storage/unusual_devs.h | 12 ++++++++++++
> include/linux/usb_usual.h | 2 ++
> 3 files changed, 21 insertions(+)
>
> Index: usb‑devel/drivers/usb/storage/transport.c
> ===================================================================
> ‑‑‑ usb‑devel.orig/drivers/usb/storage/transport.c
> +++ usb‑devel/drivers/usb/storage/transport.c
> @@ ‑656,6 +656,13 @@ void usb_stor_invoke_transport(struct sc
> need_auto_sense = 1;
> }
>
> + /* Some devices (Kindle) require another command after SYNC CACHE */
> + if ((us‑>fflags & US_FL_SENSE_AFTER_SYNC) &&
> + srb‑>cmnd[0] == SYNCHRONIZE_CACHE) {
> + usb_stor_dbg(us, "‑‑ sense after SYNC CACHE\n");
> + need_auto_sense = 1;
> + }
> +
> /*
> * If we have a failure, we're going to do a REQUEST_SENSE
> * automatically. Note that we differentiate between a command
> Index: usb‑devel/drivers/usb/storage/unusual_devs.h
> ===================================================================
> ‑‑‑ usb‑devel.orig/drivers/usb/storage/unusual_devs.h
> +++ usb‑devel/drivers/usb/storage/unusual_devs.h
> @@ ‑2212,6 +2212,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0
> US_FL_NO_READ_DISC_INFO ),
>
> /*
> + * Reported by Matthias Schwarzott <zzam@gentoo.org>
> + * The Amazon Kindle treats SYNCHRONIZE CACHE as an indication that
> + * the host may be finished with it, and automatically ejects its
> + * emulated media unless it receives another command within one second.
> + */
> +UNUSUAL_DEV( 0x1949, 0x0004, 0x0000, 0x9999,
> + "Amazon",
> + "Kindle",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_SENSE_AFTER_SYNC ),
> +
> +/*
> * Reported by Oliver Neukum <oneukum@suse.com>
> * This device morphes spontaneously into another device if the access
> * pattern of Windows isn't followed. Thus writable media would be dirty
> Index: usb‑devel/include/linux/usb_usual.h
> ===================================================================
> ‑‑‑ usb‑devel.orig/include/linux/usb_usual.h
> +++ usb‑devel/include/linux/usb_usual.h
> @@ ‑86,6 +86,8 @@
> /* lies about caching, so always sync */ \
> US_FLAG(NO_SAME, 0x40000000) \
> /* Cannot handle WRITE_SAME */ \
> + US_FLAG(SENSE_AFTER_SYNC, 0x80000000) \
> + /* Do REQUEST_SENSE after SYNCHRONIZE_CACHE */ \
>
> #define US_FLAG(name, value) US_FL_##name = value ,
> enum { US_DO_ALL_FLAGS };
> _______________________________________________
> systemd‑devel mailing list
> systemd‑devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload
2021-03-17 19:06 ` [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload Alan Stern
@ 2021-03-18 11:39 ` Hans de Goede
2021-03-18 13:50 ` [systemd-devel] " Tomasz Torcz
1 sibling, 0 replies; 33+ messages in thread
From: Hans de Goede @ 2021-03-18 11:39 UTC (permalink / raw)
To: Alan Stern, Greg KH
Cc: Matthias Schwarzott, usb-storage, linux-usb, systemd-devel, hirofumi
Hi,
On 3/17/21 8:06 PM, Alan Stern wrote:
> Matthias reports that the Amazon Kindle automatically removes its
> emulated media if it doesn't receive another SCSI command within about
> one second after a SYNCHRONIZE CACHE. It does so even when the host
> has sent a PREVENT MEDIUM REMOVAL command. The reason for this
> behavior isn't clear, although it's not hard to make some guesses.
>
> At any rate, the results can be unexpected for anyone who tries to
> access the Kindle in an unusual fashion, and in theory they can lead
> to data loss (for example, if one file is closed and synchronized
> while other files are still in the middle of being written).
>
> To avoid such problems, this patch creates a new usb-storage quirks
> flag telling the driver always to issue a REQUEST SENSE following a
> SYNCHRONIZE CACHE command, and adds an unusual_devs entry for the
> Kindle with the flag set. This is sufficient to prevent the Kindle
> from doing its automatic unload, without interfering with proper
> operation.
>
> Another possible way to deal with this would be to increase the
> frequency of TEST UNIT READY polling that the kernel normally carries
> out for removable-media storage devices. However that would increase
> the overall load on the system and it is not as reliable, because the
> user can override the polling interval. Changing the driver's
> behavior is safer and has minimal overhead.
>
> Reported-and-tested-by: Matthias Schwarzott <zzam@gentoo.org>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> CC: <stable@vger.kernel.org>
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
>
> ---
>
>
> [as1953]
>
>
> drivers/usb/storage/transport.c | 7 +++++++
> drivers/usb/storage/unusual_devs.h | 12 ++++++++++++
> include/linux/usb_usual.h | 2 ++
> 3 files changed, 21 insertions(+)
>
> Index: usb-devel/drivers/usb/storage/transport.c
> ===================================================================
> --- usb-devel.orig/drivers/usb/storage/transport.c
> +++ usb-devel/drivers/usb/storage/transport.c
> @@ -656,6 +656,13 @@ void usb_stor_invoke_transport(struct sc
> need_auto_sense = 1;
> }
>
> + /* Some devices (Kindle) require another command after SYNC CACHE */
> + if ((us->fflags & US_FL_SENSE_AFTER_SYNC) &&
> + srb->cmnd[0] == SYNCHRONIZE_CACHE) {
> + usb_stor_dbg(us, "-- sense after SYNC CACHE\n");
> + need_auto_sense = 1;
> + }
> +
> /*
> * If we have a failure, we're going to do a REQUEST_SENSE
> * automatically. Note that we differentiate between a command
> Index: usb-devel/drivers/usb/storage/unusual_devs.h
> ===================================================================
> --- usb-devel.orig/drivers/usb/storage/unusual_devs.h
> +++ usb-devel/drivers/usb/storage/unusual_devs.h
> @@ -2212,6 +2212,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0
> US_FL_NO_READ_DISC_INFO ),
>
> /*
> + * Reported by Matthias Schwarzott <zzam@gentoo.org>
> + * The Amazon Kindle treats SYNCHRONIZE CACHE as an indication that
> + * the host may be finished with it, and automatically ejects its
> + * emulated media unless it receives another command within one second.
> + */
> +UNUSUAL_DEV( 0x1949, 0x0004, 0x0000, 0x9999,
> + "Amazon",
> + "Kindle",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_SENSE_AFTER_SYNC ),
> +
> +/*
> * Reported by Oliver Neukum <oneukum@suse.com>
> * This device morphes spontaneously into another device if the access
> * pattern of Windows isn't followed. Thus writable media would be dirty
> Index: usb-devel/include/linux/usb_usual.h
> ===================================================================
> --- usb-devel.orig/include/linux/usb_usual.h
> +++ usb-devel/include/linux/usb_usual.h
> @@ -86,6 +86,8 @@
> /* lies about caching, so always sync */ \
> US_FLAG(NO_SAME, 0x40000000) \
> /* Cannot handle WRITE_SAME */ \
> + US_FLAG(SENSE_AFTER_SYNC, 0x80000000) \
> + /* Do REQUEST_SENSE after SYNCHRONIZE_CACHE */ \
>
> #define US_FLAG(name, value) US_FL_##name = value ,
> enum { US_DO_ALL_FLAGS };
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [systemd-devel] [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload
2021-03-17 19:06 ` [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload Alan Stern
2021-03-18 11:39 ` Hans de Goede
@ 2021-03-18 13:50 ` Tomasz Torcz
2021-03-18 15:07 ` Alan Stern
1 sibling, 1 reply; 33+ messages in thread
From: Tomasz Torcz @ 2021-03-18 13:50 UTC (permalink / raw)
To: Alan Stern
Cc: Greg KH, systemd-devel, usb-storage, linux-usb,
Matthias Schwarzott, hirofumi, Mike Tsai
Dnia Wed, Mar 17, 2021 at 03:06:54PM -0400, Alan Stern napisał(a):
> Matthias reports that the Amazon Kindle automatically removes its
> emulated media if it doesn't receive another SCSI command within about
> one second after a SYNCHRONIZE CACHE. It does so even when the host
> has sent a PREVENT MEDIUM REMOVAL command. The reason for this
> behavior isn't clear, although it's not hard to make some guesses.
Could Kindle be fixed not to required such workaround? Is there a way
to open a bug with Amazon?
--
Tomasz Torcz Once you've read the dictionary,
@ttorcz:pipebreaker.pl every other book is just a remix.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Antw: [EXT] Re: [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
2021-03-18 7:03 ` Antw: [EXT] " Ulrich Windl
@ 2021-03-18 14:59 ` Alan Stern
0 siblings, 0 replies; 33+ messages in thread
From: Alan Stern @ 2021-03-18 14:59 UTC (permalink / raw)
To: Ulrich Windl
Cc: Lennart Poettering, zzam, systemd-devel, usb-storage, hirofumi,
linux-usb
On Thu, Mar 18, 2021 at 08:03:07AM +0100, Ulrich Windl wrote:
> >>> Lennart Poettering <lennart@poettering.net> schrieb am 17.03.2021 um 17:47
> in
> Nachricht <YFIyidaZZmDoTevB@gardel-login>:
> > I'd say quirks that are necessary to avoid data corruption should
> > better be done in the kernel and udev's hwdb stuff is only for stuff
> > that "fills in gaps", i.e. adds additional tweaks that make things
> > prettier, cleaner, nicer, more efficient but not things that make the
> > basic things work, and data integrity sounds pretty basic to me.
>
> But seeing the list of bad, broken or ill-designed hardware grow year by year,
> I wonder whether we really want all that bloat in the kernel.
>
> >
> > Or to give a counter example: the device advertises it can do media
> > change, but actually cannot, right, it's not a floppy drive or cdrom
> > driver after all? maybe hwdb would thus actually be the place for the
> > opposite of the suggested fix: turn off the media change polling to
> > reduce needless wakeups.
>
> I actually think it would be best if those work-arounds could be loadable as
> module, and the vendors of broken hardware can provide the modules that
> document their broken design as well.
If you can come up with a way to do this (preferably in the form of a
patch), that would be great. I can't think of any way to remove this
information from the kernel.
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Antw: [EXT] [systemd-devel] [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload
2021-03-18 7:10 ` Antw: [EXT] [systemd-devel] [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload Ulrich Windl
@ 2021-03-18 15:03 ` Alan Stern
0 siblings, 0 replies; 33+ messages in thread
From: Alan Stern @ 2021-03-18 15:03 UTC (permalink / raw)
To: Ulrich Windl
Cc: Greg KH, zzam, systemd-devel, usb-storage, hirofumi, linux-usb
On Thu, Mar 18, 2021 at 08:10:56AM +0100, Ulrich Windl wrote:
> >>> Alan Stern <stern@rowland.harvard.edu> schrieb am 17.03.2021 um 20:06 in
> Nachricht <20210317190654.GA497856@rowland.harvard.edu>:
> > Matthias reports that the Amazon Kindle automatically removes its
> > emulated media if it doesn't receive another SCSI command within about
> > one second after a SYNCHRONIZE CACHE. It does so even when the host
> > has sent a PREVENT MEDIUM REMOVAL command. The reason for this
> > behavior isn't clear, although it's not hard to make some guesses.
>
> Actually I think Amazon should fix the firmware.
You are free to suggest to them that they change it. Even if you do
find the right people to ask about this, I'd be very surprised if they
agreed to make the change.
> It seems the main goal was to prevent the use of open software to manage the
> content.
This is guesswork on your part, and I disagree. I think the main goal
was to improve the user experience by making the Kindle return to normal
operating mode automatically when file transfers are finished, rather
than requiring the user to do something extra. But that's also just a
guess.
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [systemd-devel] [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload
2021-03-18 13:50 ` [systemd-devel] " Tomasz Torcz
@ 2021-03-18 15:07 ` Alan Stern
0 siblings, 0 replies; 33+ messages in thread
From: Alan Stern @ 2021-03-18 15:07 UTC (permalink / raw)
To: Tomasz Torcz
Cc: Greg KH, systemd-devel, usb-storage, linux-usb,
Matthias Schwarzott, hirofumi, Mike Tsai
On Thu, Mar 18, 2021 at 02:50:13PM +0100, Tomasz Torcz wrote:
> Dnia Wed, Mar 17, 2021 at 03:06:54PM -0400, Alan Stern napisał(a):
> > Matthias reports that the Amazon Kindle automatically removes its
> > emulated media if it doesn't receive another SCSI command within about
> > one second after a SYNCHRONIZE CACHE. It does so even when the host
> > has sent a PREVENT MEDIUM REMOVAL command. The reason for this
> > behavior isn't clear, although it's not hard to make some guesses.
>
> Could Kindle be fixed not to required such workaround? Is there a way
> to open a bug with Amazon?
You really should be asking people who work for Amazon. I suspect that
nobody who regularly reads this mailing list knows the answer.
(If you look through the MAINTAINERS file, you'll find there are a few
kernel developers who do work for Amazon, or at least, have @amazon.com
email addresses. Try asking some of them.)
But even if the Kindle firmware gets changed (which I doubt will
happen), we would still want to support all the old devices that aren't
running the updated firmware.
Alan Stern
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2021-03-18 15:08 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-05 16:54 Amazon Kindle disconnect after Synchronize Cache Matthias Schwarzott
2021-03-05 19:14 ` Alan Stern
[not found] ` <CAL411-qf+c_CB4cL=2349QqCCYimOBCYxXbsOfLbvVYOg0294g@mail.gmail.com>
2021-03-06 16:07 ` Alan Stern
2021-03-07 5:58 ` Matthias Schwarzott
2021-03-07 15:52 ` Alan Stern
2021-03-07 16:52 ` Matthias Schwarzott
2021-03-07 16:58 ` Alan Stern
2021-03-08 21:59 ` Matthias Schwarzott
2021-03-09 15:50 ` [usb-storage] " Alan Stern
2021-03-10 20:56 ` Matthias Schwarzott
2021-03-10 21:46 ` Alan Stern
2021-03-11 6:05 ` Matthias Schwarzott
2021-03-11 14:39 ` Alan Stern
2021-03-16 5:26 ` Matthias Schwarzott
2021-03-16 16:26 ` Alan Stern
2021-03-16 16:43 ` [systemd-devel] " Hans de Goede
2021-03-16 17:04 ` Alan Stern
2021-03-16 21:52 ` Matthias Schwarzott
2021-03-17 12:21 ` Hans de Goede
2021-03-17 15:17 ` Alan Stern
2021-03-17 16:47 ` Lennart Poettering
[not found] ` <F279F9BC020000F5AE14D9EC@gwsmtp.uni-regensburg.de>
[not found] ` <C63C44570200006665972EEF@gwsmtp.uni-regensburg.de>
[not found] ` <B960C12A020000A667ECE9F9@gwsmtp.uni-regensburg.de>
[not found] ` <B72C58530200001565972EEF@gwsmtp.uni-regensburg.de>
[not found] ` <0F2319EB020000F567ECE9F9@gwsmtp.uni-regensburg.de>
[not found] ` <DE3F57520200009E65972EEF@gwsmtp.uni-regensburg.de>
[not found] ` <52CC0074020000A3D68BC3D5@gwsmtp.uni-regensburg.de>
2021-03-18 7:03 ` Antw: [EXT] " Ulrich Windl
2021-03-18 14:59 ` Alan Stern
[not found] ` <474C42CD02000091AE14D9EC@gwsmtp.uni-regensburg.de>
2021-03-18 7:04 ` Ulrich Windl
[not found] ` <D43A6F56020000F865972EEF@gwsmtp.uni-regensburg.de>
2021-03-18 7:10 ` Antw: [EXT] [systemd-devel] [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload Ulrich Windl
2021-03-18 15:03 ` Alan Stern
2021-03-17 17:56 ` [systemd-devel] [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache Matthias Schwarzott
2021-03-17 18:31 ` Hans de Goede
2021-03-17 19:06 ` [PATCH] usb-storage: Add quirk to defeat Kindle's automatic unload Alan Stern
2021-03-18 11:39 ` Hans de Goede
2021-03-18 13:50 ` [systemd-devel] " Tomasz Torcz
2021-03-18 15:07 ` Alan Stern
2021-03-16 21:43 ` [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache Matthias Schwarzott
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.