Linux kernels 3.2 and 3.1.7 are broken!
Posted by Gary Dobson
|
Re: Linux kernels 3.2 and 3.1.7 are broken! February 06, 2012 07:06AM |
Registered: 14 years ago Posts: 26 |
|
Re: Linux kernels 3.2 and 3.1.7 are broken! February 06, 2012 12:57PM |
Registered: 13 years ago Posts: 502 |
Well, as they are, the 3.2.y and 3.3.0-rcN kernels will most likely just not boot. The current idea/blame is due to the L2 cache needing to be disabled at boot. It may be some time before this is fixed upstream. Until then, you are prolly best served by sticking w/ the official 3.1.y debian kernel.
=====================================================
=====================================================
- davy's Github Repo's rescue-dg
|
Robert Mugabe
Re: Linux kernels 3.2 and 3.1.7 are broken! February 06, 2012 05:16PM |
I've just been checking the Linux Kernel Driver DataBase and specifically the dependencies of CONFIG_ARM_PATCH_PHYS_VIRT that are relevant to kernels 3.2 and 3.3-rc+HEAD:
I've checked my kernel 3.2.4 .config file: CONFIG_ARM_PATCH_PHYS_VIRT=y and CONFIG_EMBEDDED is not set (the remaining dependencies are satisfied.) Given that CONFIG_ARM_PATCH_PHYS_VIRT depends on CONFIG_EMBEDDED it would appear that the kernel is misconfigured. My intention is to recompile with CONFIG_EMBEDDED=y.
CONFIG_ARM_PATCH_PHYS_VIRT should only be disabled if the kernel is being built for a single machine and the kernel needs to be shrunk to a minimal size.
Prior to kernel 3.2 CONFIG_ARM_PATCH_PHYS_VIRT was not used by default. Is CONFIG_ARM_PATCH_PHYS_VIRT really necessary; without it would the same kernel be able to run on the Dockstar, Pogoplug, iConnect, etc?
depends on: ( CONFIG_EMBEDDED ) && (! CONFIG_XIP_KERNEL && CONFIG_MMU ) && (! CONFIG_ARCH_REALVIEW || ! CONFIG_SPARSEMEM )
I've checked my kernel 3.2.4 .config file: CONFIG_ARM_PATCH_PHYS_VIRT=y and CONFIG_EMBEDDED is not set (the remaining dependencies are satisfied.) Given that CONFIG_ARM_PATCH_PHYS_VIRT depends on CONFIG_EMBEDDED it would appear that the kernel is misconfigured. My intention is to recompile with CONFIG_EMBEDDED=y.
CONFIG_ARM_PATCH_PHYS_VIRT should only be disabled if the kernel is being built for a single machine and the kernel needs to be shrunk to a minimal size.
Prior to kernel 3.2 CONFIG_ARM_PATCH_PHYS_VIRT was not used by default. Is CONFIG_ARM_PATCH_PHYS_VIRT really necessary; without it would the same kernel be able to run on the Dockstar, Pogoplug, iConnect, etc?
|
Re: Linux kernels 3.2 and 3.1.7 are broken! February 06, 2012 05:51PM |
Registered: 13 years ago Posts: 502 |
Robert Mugabe Wrote:
-------------------------------------------------------
> I've just been checking the Linux Kernel Driver
> DataBase and specifically the dependencies of
> [url=http://cateee.net/lkddb/web-lkddb/ARM_PATCH_P
> HYS_VIRT.html]CONFIG_ARM_PATCH_PHYS_VIRT[/url]
> that are relevant to kernels 3.2 and 3.3-rc+HEAD:
Yes, I've seen that as well. (not in the database, but just in the code)
> [code]
> depends on: ( CONFIG_EMBEDDED ) && (!
> CONFIG_XIP_KERNEL && CONFIG_MMU ) && (!
> CONFIG_ARCH_REALVIEW || ! CONFIG_SPARSEMEM )
> [/code]
>
> I've checked my kernel 3.2.4 [i].config[/i] file:
> [b]CONFIG_ARM_PATCH_PHYS_VIRT=y[/b] and
> [b]CONFIG_EMBEDDED is not set[/b] (the remaining
> dependencies are satisfied.) Given that
> [b]CONFIG_ARM_PATCH_PHYS_VIRT[/b] depends on
> [b]CONFIG_EMBEDDED[/b] it would appear that the
> kernel is misconfigured. My intention is to
> recompile with [b]CONFIG_EMBEDDED=y[/b].
Others have hacked kconfig to disable ARM_PATCH_PHYS_VIRT, and the nonbooting behavior ceases (ie. boots as it should).
If it works for you, please post back your config. I tried this earlier today, but I'm now sure that I had the wrong value for the phy add of main memory.
[code]
[ ] Patch physical to virtual translations at runtime
( ???? ) Physical address of main memory
[/code]
What is the value for the phy add of main memory?
> [b]CONFIG_ARM_PATCH_PHYS_VIRT[/b] should only be
> disabled if the kernel is being built for a single
> machine and the kernel needs to be shrunk to a
> minimal size.
>
> Prior to kernel 3.2
> [b]CONFIG_ARM_PATCH_PHYS_VIRT[/b] was not used by
> default. Is [b]CONFIG_ARM_PATCH_PHYS_VIRT[/b]
> really necessary; without it would the same kernel
> be able to run on the Dockstar, Pogoplug,
> iConnect, [i]etc[/i]?
I don't think it is inherently necessary, but from what I saw, Pitre & others working on ARMish things last year had been trying to hash out what would be default, what would be expected, etc... [url]https://lkml.org/lkml/2011/10/14/434[/url]
I think they were hoping to pass along board info to the kernel in some "nicer" fashion...
=====================================================
[list]
[*][url=https://github.com/davygravy/]davy's Github Repo's [/url]rescue-dg
[/list]
Edited 2 time(s). Last edit at 02/06/2012 06:42PM by davygravy.
-------------------------------------------------------
> I've just been checking the Linux Kernel Driver
> DataBase and specifically the dependencies of
> [url=http://cateee.net/lkddb/web-lkddb/ARM_PATCH_P
> HYS_VIRT.html]CONFIG_ARM_PATCH_PHYS_VIRT[/url]
> that are relevant to kernels 3.2 and 3.3-rc+HEAD:
Yes, I've seen that as well. (not in the database, but just in the code)
> [code]
> depends on: ( CONFIG_EMBEDDED ) && (!
> CONFIG_XIP_KERNEL && CONFIG_MMU ) && (!
> CONFIG_ARCH_REALVIEW || ! CONFIG_SPARSEMEM )
> [/code]
>
> I've checked my kernel 3.2.4 [i].config[/i] file:
> [b]CONFIG_ARM_PATCH_PHYS_VIRT=y[/b] and
> [b]CONFIG_EMBEDDED is not set[/b] (the remaining
> dependencies are satisfied.) Given that
> [b]CONFIG_ARM_PATCH_PHYS_VIRT[/b] depends on
> [b]CONFIG_EMBEDDED[/b] it would appear that the
> kernel is misconfigured. My intention is to
> recompile with [b]CONFIG_EMBEDDED=y[/b].
Others have hacked kconfig to disable ARM_PATCH_PHYS_VIRT, and the nonbooting behavior ceases (ie. boots as it should).
If it works for you, please post back your config. I tried this earlier today, but I'm now sure that I had the wrong value for the phy add of main memory.
[code]
[ ] Patch physical to virtual translations at runtime
( ???? ) Physical address of main memory
[/code]
What is the value for the phy add of main memory?
> [b]CONFIG_ARM_PATCH_PHYS_VIRT[/b] should only be
> disabled if the kernel is being built for a single
> machine and the kernel needs to be shrunk to a
> minimal size.
>
> Prior to kernel 3.2
> [b]CONFIG_ARM_PATCH_PHYS_VIRT[/b] was not used by
> default. Is [b]CONFIG_ARM_PATCH_PHYS_VIRT[/b]
> really necessary; without it would the same kernel
> be able to run on the Dockstar, Pogoplug,
> iConnect, [i]etc[/i]?
I don't think it is inherently necessary, but from what I saw, Pitre & others working on ARMish things last year had been trying to hash out what would be default, what would be expected, etc... [url]https://lkml.org/lkml/2011/10/14/434[/url]
I think they were hoping to pass along board info to the kernel in some "nicer" fashion...
=====================================================
[list]
[*][url=https://github.com/davygravy/]davy's Github Repo's [/url]rescue-dg
[/list]
Edited 2 time(s). Last edit at 02/06/2012 06:42PM by davygravy.
|
Re: Linux kernels 3.2 and 3.1.7 are broken! February 06, 2012 10:27PM |
Registered: 13 years ago Posts: 502 |
OK, I agree something is mixed up with config on the kernel, but seems pretty basic that checking and quality control may not have been taken care of on 3.2.
I tried building the kirkwood_defconfig and it wouldn't boot. Enough said.
...but...
Like Ian Campbell from the Debian bug discussion mentioned, disabling ARM_PATCH_PHYS_VIRT did yield a booting kernel for me, when I took the kirkwood_defconfig and simply unhid ARM_PATCH_PHYS_VIRT from behind EMBEDDED. I used CONFIG_PHYS_OFFSET=0x00000000.
I'm retrying w/ a more standard Debian config & ARM_PHYS_ disabled...
===========================================
Mugabe, it did work, and required just those three changes: EMBEDDED=y so that ARM_PATCH_PHYS_VIRT is unhidden, so that it can in turn be disabled. Then that requires CONFIG_PHYS_OFFSET=0x00000000 - at least that hex value worked fine for me.
It doesn't make sense that the kernel will not boot when compiled with the supplied kirkwood_defconfig.
So what Ian said regarding hacking kconfig wasn't untrue, it just seems unnecessary.
=====================================================
Edited 1 time(s). Last edit at 02/06/2012 10:50PM by davygravy.
I tried building the kirkwood_defconfig and it wouldn't boot. Enough said.
...but...
Like Ian Campbell from the Debian bug discussion mentioned, disabling ARM_PATCH_PHYS_VIRT did yield a booting kernel for me, when I took the kirkwood_defconfig and simply unhid ARM_PATCH_PHYS_VIRT from behind EMBEDDED. I used CONFIG_PHYS_OFFSET=0x00000000.
Loading file "/boot/uImage" from usb device 0:1 (usbda1) 1 bytes read Found bootable drive on usb 0:1 Loading file "/boot/uImage" from usb device 0:1 (usbda1) 2311424 bytes read Loading file "/boot/uInitrd" from usb device 0:1 (usbda1) 1197305 bytes read ## Booting kernel from Legacy Image at 00800000 ... Image Name: Linux-3.2.2 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2311360 Bytes = 2.2 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: initramfs-3.2.2-kirkwood Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 1197241 Bytes = 1.1 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 3.2.2-kirkwood (root@bitbaker64) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ) #1 PREEMPT M on Feb 6 22:06:06 CST 2012 CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 CPU: VIVT data cache, VIVT instruction cache Machine: Seagate FreeAgent DockStar Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyS0,115200 root=/dev/sda1 rootdelay=10 rootfstype=ext2 mtdparts=orion_nand:1M(u-boot), 4M(uImage),32M(rootfs),-(data) PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 125028k/125028k available, 6044k reserved, 0K highmem ... Waiting 10sec before mounting root device... Root-NFS: no NFS server address VFS: Unable to mount root fs via NFS, trying floppy. Freeing init memory: 120K Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance. [<c000d744>] (unwind_backtrace+0x0/0xf0) from [<c02ffcc8>] (panic+0x70/0x19c) [<c02ffcc8>] (panic+0x70/0x19c) from [<c02ffa10>] (init_post+0xa0/0xc4) [<c02ffa10>] (init_post+0xa0/0xc4) from [<c03f2808>] (kernel_init+0xec/0x114)and it died, but at least it began the booting process...
I'm retrying w/ a more standard Debian config & ARM_PHYS_ disabled...
===========================================
Mugabe, it did work, and required just those three changes: EMBEDDED=y so that ARM_PATCH_PHYS_VIRT is unhidden, so that it can in turn be disabled. Then that requires CONFIG_PHYS_OFFSET=0x00000000 - at least that hex value worked fine for me.
It doesn't make sense that the kernel will not boot when compiled with the supplied kirkwood_defconfig.
So what Ian said regarding hacking kconfig wasn't untrue, it just seems unnecessary.
=====================================================
- davy's Github Repo's rescue-dg
Edited 1 time(s). Last edit at 02/06/2012 10:50PM by davygravy.
|
Robert Mugabe
Re: Linux kernels 3.2 and 3.1.7 are broken! February 07, 2012 05:24AM |
Just recompiled kernel 3.3.0-rc2 with the following parameters, and (Jeff's Dockstar) u-boot is able to boot the compressed kernel image.
As far as I am concerned, CONFIG_ARM_PATCH_PHYS_VIRT should remain "experimental", assuming that a base address of 0x0 is applicable to all Kirkwood devices.
I agree, hacking kconfig is unnecessary and somewhat drastic: the underlying problem was/is with the compulsory use of CONFIG_ARM_PATCH_PHYS_VIRT; by default it should not be used. But there should be a way to enter the CONFIG_PHYS_OFFSET value at the menuconfig stage: I had to manually edit .config.
I'm quite happy that this problem appears to have been solved, as I was quite content to use an uncompressed kernel image!
Robert Madman Mugabe - Harare
#CONFIG_ARM_PATCH_PHYS_VIRT is not set CONFIG_PHYS_OFFSET=0x0 CONFIG_EMBEDDED=y
As far as I am concerned, CONFIG_ARM_PATCH_PHYS_VIRT should remain "experimental", assuming that a base address of 0x0 is applicable to all Kirkwood devices.
I agree, hacking kconfig is unnecessary and somewhat drastic: the underlying problem was/is with the compulsory use of CONFIG_ARM_PATCH_PHYS_VIRT; by default it should not be used. But there should be a way to enter the CONFIG_PHYS_OFFSET value at the menuconfig stage: I had to manually edit .config.
I'm quite happy that this problem appears to have been solved, as I was quite content to use an uncompressed kernel image!
Robert Madman Mugabe - Harare
|
Re: Linux kernels 3.2 and 3.1.7 are broken! February 09, 2012 08:29AM |
Registered: 14 years ago Posts: 9 |
|
Re: Linux kernels 3.2 and 3.1.7 are broken! February 10, 2012 05:10PM |
Registered: 13 years ago Posts: 128 |
Robert Mugabe Wrote:
-------------------------------------------------------
> Just recompiled kernel 3.3.0-rc2 with the
> following parameters, and (Jeff's Dockstar) u-boot
> is able to boot the compressed kernel image.
>
>
>
> As far as I am concerned,
> CONFIG_ARM_PATCH_PHYS_VIRT should remain
> "experimental", assuming that a base address of
> 0x0 is applicable to all Kirkwood devices.
>
> I agree, hacking kconfig is unnecessary and
> somewhat drastic: the underlying problem was/is
> with the compulsory use of
> CONFIG_ARM_PATCH_PHYS_VIRT; by default it should
> not be used. But there should be a way to enter
> the CONFIG_PHYS_OFFSET value at the menuconfig
> stage: I had to manually edit .config.
>
> I'm quite happy that this problem appears
> to have been solved, as I was quite content to use
> an uncompressed kernel image!
>
> Robert Madman Mugabe - Harare
Thanks Robert, this will definitely save me a lot of time. I'm going to try to compile a patched
linux-image-3.2.0-1 from Wheezy's repo so that it works with my GoFlex Net and iOmega
iConnect. I'll report when it's done.
-------------------------------------------------------
> Just recompiled kernel 3.3.0-rc2 with the
> following parameters, and (Jeff's Dockstar) u-boot
> is able to boot the compressed kernel image.
>
>
> #CONFIG_ARM_PATCH_PHYS_VIRT is not set > CONFIG_PHYS_OFFSET=0x0 > CONFIG_EMBEDDED=y >>
>
> As far as I am concerned,
> CONFIG_ARM_PATCH_PHYS_VIRT should remain
> "experimental", assuming that a base address of
> 0x0 is applicable to all Kirkwood devices.
>
> I agree, hacking kconfig is unnecessary and
> somewhat drastic: the underlying problem was/is
> with the compulsory use of
> CONFIG_ARM_PATCH_PHYS_VIRT; by default it should
> not be used. But there should be a way to enter
> the CONFIG_PHYS_OFFSET value at the menuconfig
> stage: I had to manually edit .config.
>
> I'm quite happy that this problem appears
> to have been solved, as I was quite content to use
> an uncompressed kernel image!
>
> Robert Madman Mugabe - Harare
Thanks Robert, this will definitely save me a lot of time. I'm going to try to compile a patched
linux-image-3.2.0-1 from Wheezy's repo so that it works with my GoFlex Net and iOmega
iConnect. I'll report when it's done.
|
Re: Linux kernels 3.2 and 3.1.7 are broken! February 11, 2012 06:09AM |
Registered: 13 years ago Posts: 128 |
Hmm, it seems that the Arch Linux ARM patch for the 3.1 kernel (which enables GoFlex and iConnect support)
https://github.com/archlinuxarm/PKGBUILDs/blob/eb886eb2e8f5f88864afd69e041159584ebcd307/core/linux/archlinuxarm.patch
is not compatible with 3.2. When I try to compile the kernel with this patch applied, I get errors like
Edit:
Aha, looks like boot_params was recently renamed to atag_offset. Furthermore, machine_is_pogoplugv4 is missing in
include/generated/mach-types.h.
Edited 1 time(s). Last edit at 02/11/2012 06:46AM by Vlad.
https://github.com/archlinuxarm/PKGBUILDs/blob/eb886eb2e8f5f88864afd69e041159584ebcd307/core/linux/archlinuxarm.patch
is not compatible with 3.2. When I try to compile the kernel with this patch applied, I get errors like
arch/arm/mach-kirkwood/pogoplugv4-setup.c: In function 'pogoplugv4_pci_init': arch/arm/mach-kirkwood/pogoplugv4-setup.c:179:2: error: implicit declaration of function 'machine_is_pogoplugv4' arch/arm/mach-kirkwood/pogoplugv4-setup.c: At top level: arch/arm/mach-kirkwood/pogoplugv4-setup.c:186:1: error: 'MACH_TYPE_POGOPLUGV4' undeclared here (not in a function) arch/arm/mach-kirkwood/pogoplugv4-setup.c:188:2: error: unknown field 'boot_params' specified in initializerThe errors can be removed if you delete the boot_params variable from the correspnding source files, but I still feel that this is not the correct way to fix the problem, especially if you don't really understand, what the problem is. So I guess I'll stick to 3.1 from the wheezy repo. Must check if that one compiles fine.
Edit:
Aha, looks like boot_params was recently renamed to atag_offset. Furthermore, machine_is_pogoplugv4 is missing in
include/generated/mach-types.h.
Edited 1 time(s). Last edit at 02/11/2012 06:46AM by Vlad.
|
Re: Linux kernels 3.2 and 3.1.7 are broken! February 11, 2012 12:54PM |
Registered: 13 years ago Posts: 128 |
Just in case someone is interested: I got a self compiled linux-image-3.2.0-1-kirkwood_3.2.4-1 (Wheezy repo) working
on my iOmega iConnect. For this I had to slightly modify the archlinuxarm.patch. The new patch is attached to this post.
Furthermore, as Robert and davygravy already mentioned, one has to set
on my iOmega iConnect. For this I had to slightly modify the archlinuxarm.patch. The new patch is attached to this post.
Furthermore, as Robert and davygravy already mentioned, one has to set
General setup -> Embedded System -> Enable Patch physical to virtual translations at runtime -> DisableThen in arch/arm/Kconfig find the passage that looks like this (around line 222)
config PHYS_OFFSET
hex "Physical address of main memory" if MMU
depends on !ARM_PATCH_PHYS_VIRT && !NEED_MACH_MEMORY_H
default DRAM_BASE if !MMU
help
and change it to
config PHYS_OFFSET
hex "Physical address of main memory" if MMU
default 0x0
help
So far everything looks pretty good.
|
Re: Linux kernels 3.2 and 3.1.7 are broken! May 20, 2012 05:09PM |
Registered: 12 years ago Posts: 1 |
First:
i managed to install the new uboot without serial cable using
The second thing i want to mention:
DO NOT SET
If you do this your system won't recognize any attached usb-sticks. It took me hours to debug because i thought it was caused by the new uboot. The kernel output looked like this:
a healthy output with CONFIG_USB_EHCI_MV disabled looks like this:
i managed to install the new uboot without serial cable using
flash_erase /dev/mtd0 0 4 nandwrite /dev/mtd0 /tmp/uboot.mtd0.kwb-2011.12-L2Cdisabled-davysconfig nanddump -o -l 0x80000 -f /tmp/mtd0.uboot /dev/mtd0 && md5sum /tmp/mtd0.uboot md5sum /tmp/uboot.mtd0.kwb-2011.12-L2Cdisabled-davysconfigBut my output still differs:
U-Boot 2011.12 (Feb 12 2012 - 21:33:07) Seagate FreeAgent DockStar SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB WARNING: Caches not enabled NAND: 256 MiB In: serial Out: serial Err: serial Net: egiga0
The second thing i want to mention:
DO NOT SET
CONFIG_USB_EHCI_MV!
If you do this your system won't recognize any attached usb-sticks. It took me hours to debug because i thought it was caused by the new uboot. The kernel output looked like this:
[ 5.506691] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4 [ 5.513868] mv643xx_eth smi: probed [ 5.519684] mv643xx_eth_port mv643xx_eth_port.0: eth0: port 0 with MAC address 00:10:75:1a:d1:1e [ 5.528764] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 5.535676] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 5.542042] Initializing USB Mass Storage driver... [ 5.547128] usbcore: registered new interface driver usb-storage [ 5.553206] USB Mass Storage support registered.
a healthy output with CONFIG_USB_EHCI_MV disabled looks like this:
[ 8.546746] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4 [ 8.553823] mv643xx_eth smi: probed [ 8.559529] mv643xx_eth_port mv643xx_eth_port.0: eth0: port 0 with MAC address 00:10:75:1a:d1:1e [ 8.568708] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 8.575373] orion-ehci orion-ehci.0: Marvell Orion EHCI [ 8.580637] orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1 [ 8.612472] orion-ehci orion-ehci.0: irq 19, io mem 0xf1050000 [ 8.632462] orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00 [ 8.638475] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 8.645315] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 8.652583] usb usb1: Product: Marvell Orion EHCI [ 8.657311] usb usb1: Manufacturer: Linux 3.1.1-gentoo-dockstar ehci_hcd [ 8.664057] usb usb1: SerialNumber: orion-ehci.0 [ 8.669273] hub 1-0:1.0: USB hub found [ 8.673101] hub 1-0:1.0: 1 port detected [ 8.677663] Initializing USB Mass Storage driver... [ 8.682800] usbcore: registered new interface driver usb-storage [ 8.688832] USB Mass Storage support registered.
|
Re: Linux kernels 3.2 and 3.1.7 are broken! May 21, 2012 07:54PM |
Registered: 13 years ago Posts: 502 |
Yes, see : http://www.spinics.net/lists/linux-usb/msg60204.html
=====================================================
=====================================================
- davy's Github Repo's rescue-dg
