Bug#798787: linux-image-4.1.0-2-amd64: usb device recognised on i386 testing, but not on amd64: Alcor Micro Corp. Multi Flash Reader
Package: src:linux Version: 4.1.6-1 Severity: normal I have a Multiflash (usb) reader which works under testing on i386 architecture. Here is the lsusb -v detail from that working system: --- Bus 001 Device 004: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x058f Alcor Micro Corp. idProduct 0x6366 Multi Flash Reader bcdDevice1.00 iManufacturer 1 Generic iProduct2 Mass Storage Device iSerial 3 058F63666471 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) --- Here is the lsmod output on the working system: --- Module Size Used by uas20480 0 usb_storage53248 1 uas snd_hrtimer16384 1 snd_seq_midi 16384 0 snd_seq_midi_event 16384 1 snd_seq_midi snd_rawmidi24576 1 snd_seq_midi snd_seq53248 3 snd_seq_midi_event,snd_seq_midi snd_seq_device 16384 3 snd_seq,snd_rawmidi,snd_seq_midi cpufreq_powersave 16384 0 cpufreq_userspace 16384 0 cpufreq_stats 16384 0 cpufreq_conservative16384 0 nfsd 249856 13 auth_rpcgss49152 1 nfsd oid_registry 16384 1 auth_rpcgss nfs_acl16384 1 nfsd nfs 184320 0 lockd 73728 2 nfs,nfsd grace 16384 2 nfsd,lockd fscache45056 1 nfs sunrpc225280 22 nfs,nfsd,auth_rpcgss,lockd,nfs_acl arc4 16384 2 joydev 20480 0 iTCO_wdt 16384 0 iTCO_vendor_support16384 1 iTCO_wdt sparse_keymap 16384 0 uvcvideo 73728 0 videobuf2_vmalloc 16384 1 uvcvideo acerhdf16384 0 videobuf2_memops 16384 1 videobuf2_vmalloc videobuf2_core 40960 1 uvcvideo v4l2_common16384 1 videobuf2_core videodev 118784 3 uvcvideo,v4l2_common,videobuf2_core media 20480 2 uvcvideo,videodev coretemp 16384 0 ath5k 139264 0 ath24576 1 ath5k evdev 20480 21 pcspkr 16384 0 psmouse 102400 0 serio_raw 16384 0 snd_hda_codec_realtek65536 1 sg 32768 0 snd_hda_codec_generic65536 1 snd_hda_codec_realtek mac80211 503808 1 ath5k i2c_i801 20480 0 i915 937984 4 snd_hda_intel 28672 5 lpc_ich20480 0 mfd_core 16384 1 lpc_ich snd_hda_controller 28672 1 snd_hda_intel snd_hda_codec 86016 4 snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller rng_core 16384 0 drm_kms_helper 90112 1 i915 jmb38x_ms 20480 0 snd_hda_core 24576 4 snd_hda_codec_realtek,snd_hda_codec_generi
Re: Upstream source handling
On Sat, Sep 12, 2015 at 12:52:13PM +0200, maximilian attems wrote: > shouldn't one use subtrees these days and not submodules. > submodules only live in contrib. subtrees got merged in > main git. The problems solved by subtree and submodule are different. And in the git 2.5.1, subtree is contrib, submodule is main. Subtrees are merged trees into the container repo. They loose all information about there source. They can be manipulated further in the tree and later synced again. I did not look how using subtrees could work. Submodules are only pointers to commits. They don't add any volume of data to the tree. My proposal includes the frequent use to rebase. This mimics the current patch handling, where the applied patches are clearly shown. If we want to export a patch series for the package, we need that anyway. However, if we already maintain our own tree, using subtree does not provide much advantage, but it completely removes the automation around it. Bastian -- It would seem that evil retreats when forcibly confronted. -- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5
Bug#771224: Recurring traces from tcp_fragment+0x2b1/0x2c0 (linux-3.16.7/net/ipv4/tcp_output.c:1085)
Package: src:linux Followup-For: Bug #771224 Dear Maintainer, This issue is not reproducible on any of 4.* series kernels. -- Package-specific info: ** Version: Linux version 4.1.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-3) ) #1 SMP Debian 4.1.6-1 (2015-08-23) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.0-2-amd64 root=UUID=f99a9c37-6cc5-4c06-82b8-5f70809512a8 ro ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [ 16.815116] ohci-pci :00:14.5: new USB bus registered, assigned bus number 12 [ 16.815178] ohci-pci :00:14.5: irq 18, io mem 0xfeb06000 [ 16.874441] usb usb12: New USB device found, idVendor=1d6b, idProduct=0001 [ 16.874482] usb usb12: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 16.874522] usb usb12: Product: OHCI PCI host controller [ 16.874560] usb usb12: Manufacturer: Linux 4.1.0-2-amd64 ohci_hcd [ 16.874598] usb usb12: SerialNumber: :00:14.5 [ 16.874754] hub 12-0:1.0: USB hub found [ 16.874798] hub 12-0:1.0: 2 ports detected [ 16.875012] ohci-pci :00:16.0: OHCI PCI host controller [ 16.875054] ohci-pci :00:16.0: new USB bus registered, assigned bus number 13 [ 16.875120] ohci-pci :00:16.0: irq 22, io mem 0xfeb05000 [ 16.938355] usb usb13: New USB device found, idVendor=1d6b, idProduct=0001 [ 16.938396] usb usb13: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 16.938437] usb usb13: Product: OHCI PCI host controller [ 16.938474] usb usb13: Manufacturer: Linux 4.1.0-2-amd64 ohci_hcd [ 16.938512] usb usb13: SerialNumber: :00:16.0 [ 16.938678] hub 13-0:1.0: USB hub found [ 16.940469] hub 13-0:1.0: 4 ports detected [ 16.940821] snd_hda_intel :01:00.1: Handle VGA-switcheroo audio client [ 16.940867] snd_hda_intel :01:00.1: Force to non-snoop mode [ 17.090243] usb 10-1: new full-speed USB device number 2 using ohci-pci [ 17.141089] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input4 [ 17.141194] input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input5 [ 17.141533] input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input6 [ 17.141918] input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input7 [ 17.142252] input: HDA ATI HDMI HDMI/DP,pcm=10 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input8 [ 17.142521] input: HDA ATI HDMI HDMI/DP,pcm=11 as /devices/pci:00/:00:02.0/:01:00.1/sound/card1/input9 [ 17.257185] usb 10-1: New USB device found, idVendor=09da, idProduct=9090 [ 17.257230] usb 10-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 17.257274] usb 10-1: Product: USB Device [ 17.257315] usb 10-1: Manufacturer: A4TECH [ 17.267054] asus_wmi: ASUS WMI generic driver loaded [ 17.310527] asus_wmi: Initialization: 0x0 [ 17.310588] asus_wmi: BIOS WMI version: 0.9 [ 17.310670] asus_wmi: SFUN value: 0x0 [ 17.311056] input: Eee PC WMI hotkeys as /devices/platform/eeepc-wmi/input/input10 [ 17.311911] asus_wmi: Disabling ACPI video driver [ 17.601484] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC898: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line [ 17.601533] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 17.601577] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 17.601621] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [ 17.601663] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x11/0x1e [ 17.601704] snd_hda_codec_realtek hdaudioC0D0:inputs: [ 17.601746] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 [ 17.601788] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [ 17.601830] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a [ 17.619228] input: HDA ATI SB Front Mic as /devices/pci:00/:00:14.2/sound/card0/input11 [ 17.619333] input: HDA ATI SB Rear Mic as /devices/pci:00/:00:14.2/sound/card0/input12 [ 17.619435] input: HDA ATI SB Line as /devices/pci:00/:00:14.2/sound/card0/input13 [ 17.619533] input: HDA ATI SB Line Out Front as /devices/pci:00/:00:14.2/sound/card0/input14 [ 17.619632] input: HDA ATI SB Line Out Surround as /devices/pci:00/:00:14.2/sound/card0/input15 [ 17.619730] input: HDA ATI SB Line Out CLFE as /devices/pci:00/:00:14.2/sound/card0/input16 [ 17.619829] input: HDA ATI SB Line Out Side as /devices/pci:00/:00:14.2/sound/card0/input17 [ 17.619927] input: HDA ATI SB Front Headphone as /devices/pci:00/:00:14.2/sound/card0/input18 [ 18.046784] AVX version of gcm_enc/dec engaged. [ 18.046825] AES CTR mode by8 optimization enabled [ 18.048484] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) [ 18.108443] hidraw: raw HID
Re: Upstream source handling
On Tue, Sep 08, 2015 at 10:52:57PM +0200, Bastian Blank wrote: > During the linux packaging BoF at DebConf, Ben asked for usefull > upstream source handling. No compeling ones were mentioned. > > Some years ago (yes, years), I proposed some schema based on submodules, > but never got around to actually implement it. I finally managed to do > an initial implementation. It currently lives in the linux.git in > branch waldi/submodule. shouldn't one use subtrees these days and not submodules. submodules only live in contrib. subtrees got merged in main git. -- maks
Re: Upstream source handling
On Sat, 2015-09-12 at 12:05 +0200, Bastian Blank wrote: > Hi Ian > > On Sat, Sep 12, 2015 at 10:45:50AM +0100, Ian Campbell wrote: > > On Tue, 2015-09-08 at 22:52 +0200, Bastian Blank wrote: > > > Please take a look and let me know what you think about this > variant. > > > Most likely I've forgotten something, but I don't know what it > is. > > The submodules refer to local paths (../source/linux IIRC) rather > than > > URLs on alioth, is that on purpose? > > Relative URL references are expanded from the origin location, so > "../source/linux" based on ssh://git.debian.org/git/kernel/linux is > ssh://git.debian.org/git/kernel/source/linux. Hrm, this didn't appear to be working for me, and it was happy once I manually cloned something into ../source/linux. Might be dependent on git version or something? > > Would it be possible to arrange for the base featureset to actually be > > in the main tree at the toplevel rather than as a submodule do you > > think? That at least would seem to be a far more natural arrangement. > > Nope, a submodule can only live within an existing tree. I meant making the base featureset part of the main tree, not a submodule. I suppose the fact that it is rebasing knackers that idea though. Ian.
Re: Upstream source handling
On Sat, 2015-09-12 at 12:05 +0200, Bastian Blank wrote: > Hi Ian > > On Sat, Sep 12, 2015 at 10:45:50AM +0100, Ian Campbell wrote: > > On Tue, 2015-09-08 at 22:52 +0200, Bastian Blank wrote: > > > Please take a look and let me know what you think about this > variant. > > > Most likely I've forgotten something, but I don't know what it > is. > > The submodules refer to local paths (../source/linux IIRC) rather > than > > URLs on alioth, is that on purpose? > > Relative URL references are expanded from the origin location, so > "../source/linux" based on ssh://git.debian.org/git/kernel/linux is > ssh://git.debian.org/git/kernel/source/linux. Hrm, this didn't appear to be working for me, and it was happy once I manually cloned something into ../source/linux. Might be dependent on git version or something? > > Would it be possible to arrange for the base featureset to actually be > > in the main tree at the toplevel rather than as a submodule do you > > think? That at least would seem to be a far more natural arrangement. > > Nope, a submodule can only live within an existing tree. I meant making the base featureset part of the main tree, not a submodule. I suppose the fact that it is rebasing knackers that idea though. Ian.
Re: Upstream source handling
Hi Ian On Sat, Sep 12, 2015 at 10:45:50AM +0100, Ian Campbell wrote: > On Tue, 2015-09-08 at 22:52 +0200, Bastian Blank wrote: > > Please take a look and let me know what you think about this variant. > > Most likely I've forgotten something, but I don't know what it is. > The submodules refer to local paths (../source/linux IIRC) rather than > URLs on alioth, is that on purpose? Relative URL references are expanded from the origin location, so "../source/linux" based on ssh://git.debian.org/git/kernel/linux is ssh://git.debian.org/git/kernel/source/linux. > Or is it to avoid cloning the full > linux history for each submodule? (i.e. git doesn't realise they are > the same remote repo and can share stuff, so it would clone the full > history multiple times) It is not able to use a shared object store if not told by hand. > Also genorig seems to be broken (wants the dfsg series). I suspect this > now works completely differently? I did not change genorig for the time being. > Manually merging into all derived featuresets when changing the base > (==none) featureset sounds annoying, and liable to being forgotten, but > I guess that is pretty hard to automate? We can at least check for such errors. > Would it be possible to arrange for the base featureset to actually be > in the main tree at the toplevel rather than as a submodule do you > think? That at least would seem to be a far more natural arrangement. Nope, a submodule can only live within an existing tree. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Re: Upstream source handling
On Tue, 2015-09-08 at 22:52 +0200, Bastian Blank wrote: > Please take a look and let me know what you think about this variant. > Most likely I've forgotten something, but I don't know what it is. I had a (very brief) play. The submodules refer to local paths (../source/linux IIRC) rather than URLs on alioth, is that on purpose? Or is it to avoid cloning the full linux history for each submodule? (i.e. git doesn't realise they are the same remote repo and can share stuff, so it would clone the full history multiple times) Also genorig seems to be broken (wants the dfsg series). I suspect this now works completely differently? Manually merging into all derived featuresets when changing the base (==none) featureset sounds annoying, and liable to being forgotten, but I guess that is pretty hard to automate? Would it be possible to arrange for the base featureset to actually be in the main tree at the toplevel rather than as a submodule do you think? That at least would seem to be a far more natural arrangement. Ian.
