Created attachment 305022 [details]
dmesg error from the card reader

Please try this again after applying the commit in

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?id=a6ff6e7a9dd69364547751db0f626a10a6d628d2

(In reply to Alan Stern from comment #2)
> Please try this again after applying the commit in
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/
> ?id=a6ff6e7a9dd69364547751db0f626a10a6d628d2

The commit is included in Kernel 6.5 already, which my system is currently running. 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/storage/alauda.c?h=v6.5

On previous versions of the kernel before this patch, the card reader reported no media and generated an error about how the transfer buffer is on stack. Chances are this broke 6 or so years ago when the kernel behavior was changed to block drivers that did that behavior (see: https://linux.kernel.narkive.com/YOK3Jf56/patch-v2-usb-core-warn-if-an-urb-s-transfer-buffer-is-on-stack) but I might have to do some testing to see what Linux version in particular broke it. Here is the error on Kernel 5.15 as an example on Ubuntu 22.04:

[   43.057770] usb 1-1: new full-speed USB device number 5 using xhci_hcd
[   43.221275] usb 1-1: New USB device found, idVendor=0584, idProduct=0008, bcdDevice= 1.02
[   43.221284] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   43.221288] usb 1-1: Product: USB SmartMedia Adapter
[   43.221291] usb 1-1: Manufacturer: YAMAICHI ELECTRONICS Co.,Ltd.
[   43.307610] usbcore: registered new interface driver usb-storage
[   43.310782] ums-alauda 1-1:1.0: USB Mass Storage device detected
[   43.315826] scsi host1: usb-storage 1-1:1.0
[   43.316038] usbcore: registered new interface driver ums-alauda
[   44.316803] scsi 1:0:0:0: Direct-Access     Fujifilm DPC-R1 (Alauda)  0102 PQ: 0 ANSI: 0 CCS
[   44.316936] scsi 1:0:0:1: Direct-Access     Fujifilm DPC-R1 (Alauda)  0102 PQ: 0 ANSI: 0 CCS
[   44.317379] ------------[ cut here ]------------
[   44.317381] transfer buffer is on stack
[   44.317400] sd 1:0:0:0: Attached scsi generic sg0 type 0
[   44.317404] WARNING: CPU: 0 PID: 3177 at drivers/usb/core/hcd.c:1498 usb_hcd_map_urb_for_dma+0x4a9/0x4f0
[   44.317421] Modules linked in: ums_alauda usb_storage ccm rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc snd_hda_codec_hdmi snd_soc_sst_dsp snd_soc_acpi_intel_match snd_ctl_led snd_hda_codec_conexant snd_soc_acpi snd_hda_codec_generic ledtrig_audio intel_rapl_msr snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec mei_hdcp snd_hda_core snd_hwdep snd_pcm uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_seq_midi btusb btrtl videobuf2_common btbcm btintel videodev snd_seq_midi_event mc intel_rapl_common intel_tcc_cooling snd_rawmidi x86_pkg_temp_thermal intel_powerclamp coretemp binfmt_misc bluetooth kvm_intel kvm ecdh_generic ecc rapl snd_seq nls_iso8859_1 intel_cstate hp_wmi snd_seq_device sparse_keymap platform_profile iwlmvm intel_wmi_thunderbolt snd_timer joydev input_leds snd mac80211 serio_raw wmi_bmof libarc4 iwlwifi ee1004 soundcore
[   44.317549]  cfg80211 mei_me intel_pch_thermal intel_xhci_usb_role_switch mei hp_accel mac_hid lis3lv02d wireless_hotkey tpm_infineon acpi_pad sch_fq_codel msr parport_pc ppdev lp ramoops parport reed_solomon pstore_blk pstore_zone efi_pstore ip_tables x_tables autofs4 i915 i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops rtsx_pci_sdmmc cec crct10dif_pclmul crc32_pclmul rc_core i2c_i801 nvme ghash_clmulni_intel aesni_intel crypto_simd cryptd psmouse e1000e i2c_smbus drm nvme_core xhci_pci xhci_pci_renesas rtsx_pci ahci intel_lpss_pci intel_lpss libahci idma64 wmi video pinctrl_sunrisepoint
[   44.317637] CPU: 0 PID: 3177 Comm: usb-storage Not tainted 5.15.0-82-generic #91-Ubuntu
[   44.317643] Hardware name: HP HP EliteBook 840 G3/8079, BIOS N75 Ver. 01.57 07/28/2022
[   44.317646] RIP: 0010:usb_hcd_map_urb_for_dma+0x4a9/0x4f0
[   44.317654] Code: ff 4c 89 f2 48 c7 c7 00 e5 84 87 48 89 c6 e8 8f 60 37 00 0f 0b eb c1 48 c7 c7 25 3b 8a 87 c6 05 fb 7b 85 01 01 e8 78 60 37 00 <0f> 0b 41 be f5 ff ff ff 41 8b 54 24 5c e9 3d fc ff ff 0f 0b 41 be
[   44.317658] RSP: 0018:ffffa3e3410a3bc0 EFLAGS: 00010282
[   44.317663] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027
[   44.317667] RDX: ffff910623820588 RSI: 0000000000000001 RDI: ffff910623820580
[   44.317670] RBP: ffffa3e3410a3bf8 R08: 0000000000000003 R09: fffffffffffd1a70
[   44.317673] R10: 000000000000001d R11: 0000000000000001 R12: ffff91040aec6540
[   44.317676] R13: ffff910400ca0000 R14: 0000000000000000 R15: 0000000000000c00
[   44.317680] FS:  0000000000000000(0000) GS:ffff910623800000(0000) knlGS:0000000000000000
[   44.317684] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   44.317688] CR2: 00007fd828fc8ae0 CR3: 0000000043410006 CR4: 00000000003706f0
[   44.317692] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   44.317695] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   44.317698] Call Trace:
[   44.317700]  <TASK>
[   44.317710]  xhci_map_urb_for_dma+0x149/0x170
[   44.317717]  usb_hcd_submit_urb+0x81/0x300
[   44.317724]  usb_submit_urb+0x254/0x6d0
[   44.317734]  usb_stor_msg_common+0xa3/0x150 [usb_storage]
[   44.317747]  usb_stor_ctrl_transfer+0xa0/0xd0 [usb_storage]
[   44.317757]  alauda_check_media+0x68/0x190 [ums_alauda]
[   44.317765]  alauda_transport+0x119/0x36c [ums_alauda]
[   44.317771]  ? schedule+0x69/0x110
[   44.317783]  usb_stor_invoke_transport+0x3b/0x550 [usb_storage]
[   44.317793]  ? __wait_for_common+0xf7/0x150
[   44.317798]  ? usleep_range_state+0x90/0x90
[   44.317806]  usb_stor_transparent_scsi_command+0xe/0x20 [usb_storage]
[   44.317812]  usb_stor_control_thread+0x195/0x290 [usb_storage]
[   44.317819]  ? storage_probe+0xe0/0xe0 [usb_storage]
[   44.317826]  kthread+0x127/0x150
[   44.317832]  ? set_kthread_struct+0x50/0x50
[   44.317837]  ret_from_fork+0x1f/0x30
[   44.317845]  </TASK>
[   44.317847] ---[ end trace 09f7f04fe1319ab9 ]---
[   44.317943] sd 1:0:0:0: [sda] Media removed, stopped polling
[   44.317966] sd 1:0:0:1: [sdb] Media removed, stopped polling
[   44.318106] sd 1:0:0:1: Attached scsi generic sg1 type 0
[   44.322084] sd 1:0:0:0: [sda] Attached SCSI removable disk
[   44.322208] sd 1:0:0:1: [sdb] Attached SCSI removable disk

Created attachment 305027 [details]
Fix IO buffer on stack in alauda subdriver

Try the attached patch.  It should fix all the other instances of I/O done to a buffer on the stack in the alauda driver.

(In reply to Alan Stern from comment #4)
> Created attachment 305027 [details]
> Fix IO buffer on stack in alauda subdriver
> 
> Try the attached patch.  It should fix all the other instances of I/O done
> to a buffer on the stack in the alauda driver.

It fixes that error, but not the deference error:

[   63.134053] usb 1-1.2: new full-speed USB device number 6 using ehci-pci
[   63.260694] usb 1-1.2: New USB device found, idVendor=0584, idProduct=0008, bcdDevice= 1.02
[   63.260715] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   63.260721] usb 1-1.2: Product: USB SmartMedia Adapter
[   63.260726] usb 1-1.2: Manufacturer: YAMAICHI ELECTRONICS Co.,Ltd.
[   63.341974] usbcore: registered new interface driver usb-storage
[   63.348722] ums-alauda 1-1.2:1.0: USB Mass Storage device detected
[   63.348926] scsi host6: usb-storage 1-1.2:1.0
[   63.349032] usbcore: registered new interface driver ums-alauda
[   64.355307] scsi 6:0:0:0: Direct-Access     Fujifilm DPC-R1 (Alauda)  0102 PQ: 0 ANSI: 0 CCS
[   64.355494] scsi 6:0:0:1: Direct-Access     Fujifilm DPC-R1 (Alauda)  0102 PQ: 0 ANSI: 0 CCS
[   64.356335] sd 6:0:0:0: Attached scsi generic sg1 type 0
[   64.356814] sd 6:0:0:0: [sdb] Media removed, stopped polling
[   64.356970] sd 6:0:0:1: Attached scsi generic sg2 type 0
[   64.357651] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[   95.571120] usb 1-1.2: reset full-speed USB device number 6 using ehci-pci
[   95.686034] sd 6:0:0:1: [sdc] 16000 512-byte logical blocks: (8.19 MB/7.81 MiB)
[   95.686147] sd 6:0:0:1: [sdc] Test WP failed, assume Write Enabled
[   95.686243] sd 6:0:0:1: [sdc] Asking for cache data failed
[   95.686260] sd 6:0:0:1: [sdc] Assuming drive cache: write through
[  126.209261] BUG: kernel NULL pointer dereference, address: 0000000000000000
[  126.209295] #PF: supervisor read access in kernel mode
[  126.209306] #PF: error_code(0x0000) - not-present page
[  126.209453] PGD 0 P4D 0 
[  126.209474] Oops: 0000 [#1] PREEMPT SMP PTI
[  126.209491] CPU: 3 PID: 2777 Comm: usb-storage Not tainted 6.5.1-custom #3
[  126.209507] Hardware name: LENOVO 42872VU/42872VU, BIOS 8DET54WW (1.24 ) 10/18/2011
[  126.209513] RIP: 0010:alauda_transport+0x4e6/0x12e2 [ums_alauda]
[  126.209538] Code: 0f 4c 8b b1 98 00 00 00 49 83 fe 01 0f 87 6f 0a 00 00 4b 8d 0c 76 44 89 e8 44 8b 6d a8 48 c1 e1 04 48 8b 4c 0b 20 48 8b 04 c1 <42> 0f b7 04 68 66 83 f8 ff 0f 84 18 ff ff ff 44 0f b7 f8 49 83 fe
[  126.209546] RSP: 0018:ffffa17ac0bb3cd0 EFLAGS: 00010206
[  126.209555] RAX: 0000000000000000 RBX: ffff8ab097457a80 RCX: ffff8ab1913c6ac8
[  126.209561] RDX: 00000000019c2003 RSI: ffffd88bc0000000 RDI: 0000000000000000
[  126.209567] RBP: ffffa17ac0bb3db0 R08: 0000000000000000 R09: 0000000000000000
[  126.209573] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8ab08121c000
[  126.209578] R13: 0000000000000000 R14: 0000000000000001 R15: ffff8ab081915138
[  126.209584] FS:  0000000000000000(0000) GS:ffff8ab19a2c0000(0000) knlGS:0000000000000000
[  126.209591] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  126.209597] CR2: 0000000000000000 CR3: 000000008e03c006 CR4: 00000000000606e0
[  126.209604] Call Trace:
[  126.209610]  <TASK>
[  126.209618]  ? show_regs+0x6e/0x80
[  126.209632]  ? __die+0x29/0x70
[  126.209641]  ? page_fault_oops+0x154/0x4a0
[  126.209654]  ? alauda_transport+0x4e6/0x12e2 [ums_alauda]
[  126.209671]  ? search_exception_tables+0x65/0x70
[  126.209686]  ? kernelmode_fixup_or_oops+0xa2/0x120
[  126.209697]  ? __bad_area_nosemaphore+0x179/0x280
[  126.209712]  ? bad_area_nosemaphore+0x16/0x20
[  126.209725]  ? do_user_addr_fault+0x2ce/0x6b0
[  126.209741]  ? exc_page_fault+0x7d/0x190
[  126.209755]  ? asm_exc_page_fault+0x2b/0x30
[  126.209774]  ? alauda_transport+0x4e6/0x12e2 [ums_alauda]
[  126.209799]  ? __schedule+0x3cb/0x15d0
[  126.209825]  usb_stor_invoke_transport+0x45/0x520 [usb_storage]
[  126.209856]  ? __wait_for_common+0x15b/0x190
[  126.209868]  ? __pfx_schedule_timeout+0x10/0x10
[  126.209881]  usb_stor_transparent_scsi_command+0x12/0x20 [usb_storage]
[  126.209905]  usb_stor_control_thread+0x20b/0x2d0 [usb_storage]
[  126.209931]  ? __pfx_usb_stor_control_thread+0x10/0x10 [usb_storage]
[  126.209955]  kthread+0xfb/0x130
[  126.209967]  ? __pfx_kthread+0x10/0x10
[  126.209978]  ret_from_fork+0x40/0x60
[  126.209988]  ? __pfx_kthread+0x10/0x10
[  126.209998]  ret_from_fork_asm+0x1b/0x30
[  126.210016]  </TASK>
[  126.210020] Modules linked in: ums_alauda usb_storage rfcomm ccm bnep intel_rapl_msr mei_hdcp snd_hda_codec_hdmi snd_ctl_led snd_hda_codec_conexant snd_hda_codec_generic uvcvideo videobuf2_vmalloc uvc snd_hda_intel btusb snd_intel_dspcfg btrtl snd_intel_sdw_acpi videobuf2_memops btbcm btintel btmtk videobuf2_v4l2 bluetooth snd_hda_codec videodev videobuf2_common mc ecdh_generic intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp binfmt_misc snd_hda_core rapl snd_hwdep intel_cstate iwldvm snd_pcm nls_iso8859_1 think_lmi input_leds joydev mac80211 at24 serio_raw firmware_attributes_class wmi_bmof libarc4 snd_seq_midi snd_seq_midi_event iwlwifi snd_rawmidi thinkpad_acpi snd_seq snd_seq_device nvram snd_timer ledtrig_audio mei_me platform_profile cfg80211 snd mei soundcore mac_hid sch_fq_codel msr parport_pc ppdev lp pstore_blk parport ramoops pstore_zone reed_solomon efi_pstore ip_tables x_tables autofs4 i915 drm_buddy i2c_algo_bit ttm crct10dif_pclmul drm_display_helper crc32_pclmul ghash_clmulni_intel cec
[  126.210212]  sha512_ssse3 rc_core aesni_intel sdhci_pci crypto_simd drm_kms_helper ahci cryptd cqhci psmouse i2c_i801 libahci drm i2c_smbus lpc_ich e1000e sdhci video wmi
[  126.210262] CR2: 0000000000000000
[  126.210270] ---[ end trace 0000000000000000 ]---
[  126.974625] RIP: 0010:alauda_transport+0x4e6/0x12e2 [ums_alauda]
[  126.974660] Code: 0f 4c 8b b1 98 00 00 00 49 83 fe 01 0f 87 6f 0a 00 00 4b 8d 0c 76 44 89 e8 44 8b 6d a8 48 c1 e1 04 48 8b 4c 0b 20 48 8b 04 c1 <42> 0f b7 04 68 66 83 f8 ff 0f 84 18 ff ff ff 44 0f b7 f8 49 83 fe
[  126.974670] RSP: 0018:ffffa17ac0bb3cd0 EFLAGS: 00010206
[  126.974680] RAX: 0000000000000000 RBX: ffff8ab097457a80 RCX: ffff8ab1913c6ac8
[  126.974687] RDX: 00000000019c2003 RSI: ffffd88bc0000000 RDI: 0000000000000000
[  126.974693] RBP: ffffa17ac0bb3db0 R08: 0000000000000000 R09: 0000000000000000
[  126.974698] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8ab08121c000
[  126.974703] R13: 0000000000000000 R14: 0000000000000001 R15: ffff8ab081915138
[  126.974709] FS:  0000000000000000(0000) GS:ffff8ab19a2c0000(0000) knlGS:0000000000000000
[  126.974716] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  126.974722] CR2: 0000000000000000 CR3: 0000000113a8a005 CR4: 00000000000606e0
[  126.974729] note: usb-storage[2777] exited with irqs disabled

There really isn't enough information in that crash report to tell what's going wrong.  Can you rebuild the driver with CONFIG_USB_DEBUG turned on and run the test again?

Created attachment 305037 [details]
entire dmesg

I enabled debug messages for the mass storage driver and USB, recompiled, and this is what I got. Instead of oopsing it instead ran past the error and failed to read the 8mb card. I'm going to test the reader on a second computer with the proper OS to rule out any reader issues as well.

Created attachment 305038 [details]
usbmon output

Created attachment 305044 [details]
dmesg oops with debug on

I tested the reader in another PC with Windows XP and it did work, when I tried one more time on the laptop with Linux I was able to get an oops error with the debug settings on to show more information.

Created attachment 305045 [details]
usbmon output during oops

It's hard to tell exactly what's happening.  There are several different odd things going on.

In the first test, the device seems to alternate between saying that the media is present and that it isn't present.  No way to tell why it's doing this.

The oops in the second test results from the fact that the alauda_ensure_map_for_zone() routine doesn't check the return value from its call to alauda_read_map().  That's bad programming.  But the reason the call failed was because the command transferred by alauda_get_redu_data() wasn't accepted by the device.  Instead the command timed out and the driver had to cancel it and reset the device.

The same thing happened with the command transferred by alauda_reset_media() in the first test.  I can't tell if the problem is that the command isn't being sent properly or that the device isn't working properly.

Can you collect a USB trace on the Windows system (with Wireshark or something similar)?  If it shows the same command being sent and accepted by the device, it will mean there's something wrong with the way the commands are transferred on the Linux system.

Created attachment 305052 [details]
Wireshark dump from Windows 7

I tested the same card and reader on a laptop with Windows 7 32-bit and used Wireshark to record the USB output of the reader from the second it's plugged in with the door shut and card inserted, and also performed several functions including opening a text file, opening and closing the door to disconnect and connect the card, and reading the directory.

There is a significant difference between the two reports: the bulk endpoint numbers.  The Windows output shows it using endpoint 3 for bulk OUT whereas Linux uses endpoint 1.  That's got to be the reason why the Bulk Reset Media and Bulk Get Redundancy Data commands are failing.

Let's see what "lsusb -v" shows for this device.  I expect it will list both endpoints, and the Windows driver uses one but the Linux driver uses the other.

(In reply to Alan Stern from comment #13)
> There is a significant difference between the two reports: the bulk endpoint
> numbers.  The Windows output shows it using endpoint 3 for bulk OUT whereas
> Linux uses endpoint 1.  That's got to be the reason why the Bulk Reset Media
> and Bulk Get Redundancy Data commands are failing.
> 
> Let's see what "lsusb -v" shows for this device.  I expect it will list both
> endpoints, and the Windows driver uses one but the Linux driver uses the
> other.

Here is the lsusb -v output for this device and there are in fact two different endpoints. 

Bus 001 Device 006: ID 0584:0008 RATOC System, Inc. Fujifilm MemoryCard ReaderWriter
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0584 RATOC System, Inc.
  idProduct          0x0008 Fujifilm MemoryCard ReaderWriter
  bcdDevice            1.02
  iManufacturer           1 YAMAICHI ELECTRONICS Co.,Ltd.
  iProduct                2 USB SmartMedia Adapter
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0027
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               80mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

Created attachment 305064 [details]
Override default bulk-OUT pipe

All right!  So let's see what happens when the driver uses endpoint 3 instead of endpoint 1.  That's what the attached patch will do.

Created attachment 305075 [details]
dmesg and usbmon with patch

The good news is now there's progress as the reader is a lot "chattier" in dmesg with debug on, to the point of actually filling up the buffer. The bad news is it still doesn't work, but now there's actual communication happening more often.

What do you mean by "it still doesn't work"?  What does it do wrong?

Essentially I can't read/write to the disk or mount it, or see it in gparted/partition managers. There's an error in the attachment about some wrong command or unable to read part of the card or something similar to that.

Are you referring to the attachment in comment #16?  Whatever error messages it contains are completely swamped by the usb-storage verbose debugging output; in practice it's impossible to find them.

In any case, we've pretty much reached the limit of my knowledge about this driver.  Everything so far has involved fixing some pretty straightforward bugs (i.e., bad interactions between the driver and the rest of the kernel), but problems involving the data sent between the driver and the device are beyond me, since I have no idea how Alauda devices are meant to work.

If you want to proceed farther, there are two things you might try.  One is to get in touch with the people who originally wrote the driver, to see if they still remember how it's supposed to operate and can help fix the problems.

The other is to try running an older version of the Linux kernel, back from when the driver did work right (assuming it ever did -- something I'm not sure of).  If you do manage to find a version of the driver that works, comparing it with the current version may indicate what needs to be fixed.

One other thing: You remember that comparing the usbmon trace with the Windows Wireshark recording showed that the Linux driver was using the wrong endpoint for some of its commands.  Well, in fact the recording shows that Windows uses _both_ bulk_OUT endpoints at various times.  Therefore the fact that the Linux driver uses only one of them is rather suspicious.  But I don't know what each endpoint is supposed to do or when they are supposed to be used.  (Also, this is partly why I wonder whether the driver ever really worked, given that it has never used more than one of the bulk-OUT endpoints.  Just possibly, the devices it was written for were somehow different from the device you are using now.)