LinuxQuestions.org - Brother DCP7030 scanner: Invalid argument

- Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)

- - Brother DCP7030 scanner: Invalid argument (https://www.linuxquestions.org/questions/linux-hardware-18/brother-dcp7030-scanner-invalid-argument-4175444547/)

Quote:

Quote:
Capabilities: <access denied>
In regard to the chipset;Never seen this before-

Why denied and in reference to what?

That just means that lspci was executed without root privileges.

Code:

sudo /sbin/lspci -vvv

You have the EHCI (USB 2.0) hardware

Code:

00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) (prog-if 20 [EHCI])

        Subsystem: Dell Device 04b0

        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 0

        Interrupt: pin A routed to IRQ 23

        Region 0: Memory at f7b07000 (32-bit, non-prefetchable) [size=1K]

        Capabilities: <access denied>

        Kernel driver in use: ehci_hcd

and the XHCI (USB 3.0) hardware

Code:

0b:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller (rev 02) (prog-if 30 [XHCI])

        Subsystem: Dell Device 04b0

        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 0, Cache Line Size: 64 bytes

        Interrupt: pin A routed to IRQ 16

        Region 0: Memory at f7900000 (64-bit, non-prefetchable) [size=64K]

        Region 2: Memory at f7910000 (64-bit, non-prefetchable) [size=8K]

        Capabilities: <access denied>

        Kernel driver in use: xhci_hcd

Quote:

Can I just force USB3.0 to work as 2.0 inside Linux?

It should have been as simple as unloading the xhci_hcd kernel module. This should leave the EHCI hardware active. (The same technique is often used for USB 2.0 HCI and associated USB 1.x HCI hardware, where the ehci_hcd driver is unloaded, leaving the uhci_hcd driver loaded.)

As an aside, are all the ports labelled USB 3.0, or do you have some USB 2.0-only ports on your laptop?

Quote:

As an aside, are all the ports labelled USB 3.0, or do you have some USB 2.0-only ports on your laptop?

+1 to that.

This hardware is looking a little quirky. According to the specs in the link http://www.cnet.com/laptops/dell-ins...-35127205.html the Dell N5110 has 2xUSB3.0, a USB2.0 and a USB2.0/eSATA port yet the OP reports only USB3.0 and a USB/eSATA port.
The output from lspci shows

Quote:

0b:00.0 USB controller: Texas Instruments SuperSpeed USB 3.0 xHCI Host Controller (rev 02) (prog-if 30 [XHCI])

yet other reports of lspci output from the Dell N5110 show

Quote:

0b:00.0 USB Controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04)

http://lists.debian.org/debian-boot/.../msg00417.html
and

Quote:

0b:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

http://forums.freebsd.org/showthread.php?t=34157

The hardware on the OP's machine is likely using a TUSB7340, which should not be a problem, as it should be fully supported by the xhci-hcd kernel module.

It is also intriguing that the 3.7 kernel did not make a difference, although there have been a number of bug fixes to xhci since the 3.2 kernel that the OP originally reported using.

A very desperate suggestion would be to try booting using the 'nomsi' kernel parameter.

Quote:

Originally Posted by ferrari (Post 4878228)

That just means that lspci was executed without root privileges.

Code:

sudo /sbin/lspci -vvv

Thanks; thought it was something else-

Reading throught the output at the pastebin link-

EHCI is recognized and in regard to the kernel the echi_hcd is in use.

Looks good so far- (still reading)

Code:

it is also intriguing that the 3.7 kernel did not make a difference,

I thought so to Allend :)
As I was taught that on a stable system users only install a new kernel if they need support for hardware
or to correct a performance problem.

Quote:

Originally Posted by DuskGlow (Post 4878217)

As to the commands and links, I'll gather them all in a couple of days.

The full lspci -vvv I can see as root looks like this: http://pastebin.com/ejeFSixM

In a couple of days is fine; don't rush-

Paying attention to line #274 Dev sta Corr Err-UncorrErr.......etc.
This was a bug with a Mac and the member was running Ubuntu. Not sure if it's a serious concern-

http://www.mail-archive.com/ubuntu-b...sg1882408.html

And line # 321 lead me to this Linux Archive
http://lkml.indiana.edu/hypermail/li...2.3/00202.html
This search was in regard to a Dell Inspiron with no sound and the member wondering if it was the motherboard-
And I used this to compare with yours.
http://lists.us.dell.com/pipermail/l...er/003386.html
http://satsky.spb.ru/articles/LinuxO.../lspcivvv.html
Line #365 and it's output lead me to:
http://lkml.indiana.edu/hypermail/li...2.2/02853.html

Just baffling-

Going to the Dell site-

Quote:

This hardware is looking a little quirky

Could that be because the firmware was modified or updated and is causing the device (scanner) to fail?

Over the next 2-3 weeks I'll be gathering information in regard to this thread and composing an article for the How To's in regard to using a Brother Printer along with the distro's Crunchbang, Ubuntu and Debian.

Clearly Brother printers work with Arch Linux considerably with ease but from this thread it's complex to say the least with the compatability of other distributions.

The article will provide instructions, how to's and commands to run to provide the user with what is needed to get the printer working.

Anyone that would like to advise, help construct or contribute to the article 'pm' me @Ztcoracat

Thanks to Allend and Ferrari

Solved for me by looking @ USB device from scanner which is a brother for me

Code:

pg@pipoTower: ~$ lsusb 

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 011 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 010 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 005 Device 002: ID 046d:c50e Logitech, Inc. Cordless Mouse Receiver

Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 004 Device 002: ID 046d:c50b Logitech, Inc. Cordless Desktop Optical

Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 008 Device 003: ID 04f9:01fd Brother Industries, Ltd 

Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

And changing rigths

Code:

sudo chmod 0664 /dev/bus/usb/008/003

or adding a udev rule into file

Code:

# Brother DCP-7055

ATTR{idVendor}=="04f9", ATTR{idProduct}=="01fd", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes"

That's not a persistent change, just a temporary meeasure. (In any case 0664 is better.) It's usual to have a udev rule take care of this as soon as the USB-connected device is attached. For example

Code:

# Brother DCP-7055

ATTR{idVendor}=="04f9", ATTR{idProduct}=="01fd", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes"

Of course it makes sense to change the commented model info to match the actuall model the rule is inteded for. I had edited my udev rule to match your particular Brother chipset, and didn't change the name. :)