Re: Facing serious problems after hardware upgrade with FreeBSD 10.3

2016-10-22 Thread Steven Hartland 

TBH sounds like you may have some bad / incompatible hardware.

For the ata errors first thing I'd do is check cabling.

Is the disk fine if you remove the scanner from the equation (disconnect 
it)?


On 22/10/2016 19:08, Manish Jain wrote:

Hi,

I am running FreeBSD 10.3 amd64.

Over the last couple of months, I have made a major upgrade of my
computer - an upgrade which has knocked out virtually everything except
the CPU (AMD Athlon X2 270).

In phase 1 (about 2 months ago), I moved the motherboard to a new
Gigabyte SB970 based board (paired with the the old Athlon CPU) and the
hard disk to a Samsung EVO 850 SSD

In phase 2 (yesterday), I upgraded other components (new components
listed) : PSU (Corsair RM650x), RAM (Kingston HyperX, 8 GB, single
piece), DVD drive (Asus DRW-24D5MT), cabinet (Circle 821).

The USB peripherals remain the same ; mouse, keyboard, printer, scanner.

The USB scanner (Canon MG 2470 Pixma; multi-function device serving
purely as scanner) is the one that is of most interest.

After phase 2 of the upgrade was over, I have been facing this situation
(since yesterday) :

If I run 'scanimage -L' as root on the console at ttyv4 (no X), most of
the times it returns with a listing of the Canon scanner. At the same
time, on ttyv0, I also get the following diagnostics :

ata0: FAILURE - odd-sized DMA transfer attempt 5 % 2
ata0: setting up DMA failed

Once in about 2-3 tries, the command actually gets totally stuck. Not
even Control-C wakes it up. In such cases, the system usually has to be
rebooted - sometimes forcibly by hard-pressing the switch on the cabinet.

Further, at the time I boot, I sometimes also see the following
diagnostics on ttyv0 :

(ada0:ata0:0:1:0): READ_DMA48. ACB: 25 00 df ea ff 40 33 00 00 00 01 00
(ada0:ata0:0:1:0): CAM status: Command timeout
(ada0:ata0:0:1:0): Retrying command

The last time I spotted the above error ("CAM status: Command timeout")
was in a single user shell running fsck after an unclean shutdown. No
other command except fsck and reboot was given to the system during that
session.

I am trying to determine whether the errors I am facing are a problem
with the hardware; with the kernel; or with the USB code. The only other
thing notable I can add is the USB scanner works seamlessly under
Windows XP (which serves as my second OS on my dual-boot machine).

If anybody can help me determine what is wrong with the system, I shall
be highly grateful - I feel practically paralysed after investing so
much time, money and energy upgrading the hardware, only to be feeling
as if now I am stuck in no man's land.


Thanks
Manish Jain
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"


___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: ehci breaking Supermicro IPMI keyboard on uhci?

2014-11-04 Thread Steven Hartland 

On 04/11/2014 07:22, Hans Petter Selasky wrote:

On 11/04/14 01:05, Steven Hartland wrote:

Had the problem where the Supermicro IPMI keyboard wouldn't work on some
machines for a while, tonight I finally had time to play with all the
options to see if anything would make it work.

Turns out adding the following to loader.conf does fixes the issue:
hint.ehci.0.disabled=1

So the question is why would this help?

Surely disabling one controller shouldn't make devices attached to
another work?



Hi,

The USB device is failing to enumerate. Are you sure there is no XHCI 
controller on this device?
I did try removing xhci from my kernel config, but that had no effect, 
only when I disabled the ehci controller did it correctly enumerate the 
devices attached to the uhci controller.


Attached is the outuput from pciconf -l -v in case that helps. If 
there's anything else I can provide which will help just let me know.


For reference I'm currently testing 10.1-RC4 on this box.

Regards
Steve
pciconf -l -v
hostb0@pci0:0:0:0:  class=0x06 card=0xa28015d9 chip=0x40038086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset Memory Controller Hub'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:   class=0x060400 card=0xa28015d9 chip=0x40218086 rev=0x20 
hdr=0x01
vendor = 'Intel Corporation'
device = '5400 Chipset PCI Express Port 1'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:3:0:   class=0x060400 card=0xa28015d9 chip=0x40238086 rev=0x20 
hdr=0x01
vendor = 'Intel Corporation'
device = '5400 Chipset PCI Express Port 3'
class  = bridge
subclass   = PCI-PCI
pcib3@pci0:0:5:0:   class=0x060400 card=0xa28015d9 chip=0x40258086 rev=0x20 
hdr=0x01
vendor = 'Intel Corporation'
device = '5400 Chipset PCI Express Port 5'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:7:0:   class=0x060400 card=0xa28015d9 chip=0x40278086 rev=0x20 
hdr=0x01
vendor = 'Intel Corporation'
device = '5400 Chipset PCI Express Port 7'
class  = bridge
subclass   = PCI-PCI
pcib10@pci0:0:9:0:  class=0x060400 card=0xa28015d9 chip=0x40298086 rev=0x20 
hdr=0x01
vendor = 'Intel Corporation'
device = '5400 Chipset PCI Express Port 9'
class  = bridge
subclass   = PCI-PCI
hostb1@pci0:0:16:0: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset FSB Registers'
class  = bridge
subclass   = HOST-PCI
hostb2@pci0:0:16:1: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset FSB Registers'
class  = bridge
subclass   = HOST-PCI
hostb3@pci0:0:16:2: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset FSB Registers'
class  = bridge
subclass   = HOST-PCI
hostb4@pci0:0:16:3: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset FSB Registers'
class  = bridge
subclass   = HOST-PCI
hostb5@pci0:0:16:4: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset FSB Registers'
class  = bridge
subclass   = HOST-PCI
hostb6@pci0:0:17:0: class=0x06 card=0xa28015d9 chip=0x40318086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset CE/SF Registers'
class  = bridge
subclass   = HOST-PCI
hostb7@pci0:0:21:0: class=0x06 card=0xa28015d9 chip=0x40358086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset FBD Registers'
class  = bridge
subclass   = HOST-PCI
hostb8@pci0:0:21:1: class=0x06 card=0xa28015d9 chip=0x40358086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset FBD Registers'
class  = bridge
subclass   = HOST-PCI
hostb9@pci0:0:22:0: class=0x06 card=0xa28015d9 chip=0x40368086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset FBD Registers'
class  = bridge
subclass   = HOST-PCI
hostb10@pci0:0:22:1:class=0x06 card=0xa28015d9 chip=0x40368086 rev=0x20 
hdr=0x00
vendor = 'Intel Corporation'
device = '5400 Chipset FBD Registers'
class  = bridge
subclass   = HOST-PCI
pcib11@pci0:0:28:0: class=0x060400 card=0xa28015d9 chip=0x26908086 rev=0x09 
hdr=0x01
vendor = 'Intel Corporation'
device = '631xESB/632xESB/3100 Chipset PCI Express Root Port 1'
class  = bridge
subclass   = PCI-PCI
uhci0@pci0:0:29:0:  class=0x0c0300 card=0xa28015d9 chip=0x26888086 rev=0x09 
hdr=0x00
vendor = 'Intel Corporation

Re: ehci breaking Supermicro IPMI keyboard on uhci?

2014-11-04 Thread Steven Hartland 


On 04/11/2014 16:45, Hans Petter Selasky wrote:

On 11/04/14 17:40, Steven Hartland wrote:

On 04/11/2014 07:22, Hans Petter Selasky wrote:

On 11/04/14 01:05, Steven Hartland wrote:
Had the problem where the Supermicro IPMI keyboard wouldn't work on 
some

machines for a while, tonight I finally had time to play with all the
options to see if anything would make it work.

Turns out adding the following to loader.conf does fixes the issue:
hint.ehci.0.disabled=1

So the question is why would this help?

Surely disabling one controller shouldn't make devices attached to
another work?



Hi,

The USB device is failing to enumerate. Are you sure there is no XHCI
controller on this device?

I did try removing xhci from my kernel config, but that had no effect,
only when I disabled the ehci controller did it correctly enumerate the
devices attached to the uhci controller.

Attached is the outuput from pciconf -l -v in case that helps. If
there's anything else I can provide which will help just let me know.

For reference I'm currently testing 10.1-RC4 on this box.

 Regards
 Steve


Maybe you can check the PCI IDs with Linux EHCI driver, if your 
hardware requires some special quirks?
I cant find any mention of quirks for the Intel USB controller PCI IDs 
but I might be looking in the wrong place, do you have a link to what I 
should be searching though?


I did however find the following which is for the exact device I'm 
having issues with and seems to indicate the HW might have an issue with 
HighSpeed mode.


https://lkml.org/lkml/2012/4/19/224
http://lkml.iu.edu//hypermail/linux/kernel/1204.3/03115.html

Which makes me wonder if hw.usb.ehci.no_hs=1 would also result in a 
working device.


Regards
Steve
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

ehci breaking Supermicro IPMI keyboard on uhci?

2014-11-03 Thread Steven Hartland 
Had the problem where the Supermicro IPMI keyboard wouldn't work on some 
machines for a while, tonight I finally had time to play with all the 
options to see if anything would make it work.


Turns out adding the following to loader.conf does fixes the issue:
hint.ehci.0.disabled=1

So the question is why would this help?

Surely disabling one controller shouldn't make devices attached to 
another work?


Messages when working (with ehci.0 disabled):
Nov  3 23:18:42 test1 kernel: usbus0 on uhci0
Nov  3 23:18:42 test1 kernel: usbus1 on uhci1
Nov  3 23:18:42 test1 kernel: usbus2 on uhci2
Nov  3 23:18:42 test1 kernel: usbus0: 12Mbps Full Speed USB v1.0
Nov  3 23:18:42 test1 kernel: usbus1: 12Mbps Full Speed USB v1.0
Nov  3 23:18:42 test1 kernel: usbus2: 12Mbps Full Speed USB v1.0
Nov  3 23:18:42 test1 kernel: ugen1.1: Intel at usbus1
Nov  3 23:18:42 test1 kernel: uhub0: Intel UHCI root HUB, class 9/0, 
rev 1.00/1.00, addr 1 on usbus1

Nov  3 23:18:42 test1 kernel: ugen0.1: Intel at usbus0
Nov  3 23:18:42 test1 kernel: uhub1: Intel UHCI root HUB, class 9/0, 
rev 1.00/1.00, addr 1 on usbus0

Nov  3 23:18:42 test1 kernel: ugen2.1: Intel at usbus2
Nov  3 23:18:42 test1 kernel: uhub2: Intel UHCI root HUB, class 9/0, 
rev 1.00/1.00, addr 1 on usbus2

Nov  3 23:18:42 test1 kernel: Root mount waiting for: usbus2
Nov  3 23:18:42 test1 kernel: ugen2.2: Peppercon AG at usbus2
Nov  3 23:18:42 test1 kernel: ukbd0: Peppercon AG Multidevice, class 
0/0, rev 2.00/0.01, addr 2 on usbus2


usbconfig list
ugen1.1: UHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=FULL 
(12Mbps) pwr=SAVE (0mA)
ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=FULL 
(12Mbps) pwr=SAVE (0mA)
ugen2.1: UHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=FULL 
(12Mbps) pwr=SAVE (0mA)
ugen2.2: Multidevice Peppercon AG at usbus2, cfg=0 md=HOST spd=FULL 
(12Mbps) pwr=ON (100mA)


Messages when not working:
Nov  3 23:02:45 test1 kernel: usbus0 on uhci0
Nov  3 23:02:45 test1 kernel: usbus1 on uhci1
Nov  3 23:02:45 test1 kernel: usbus2 on uhci2
Nov  3 23:02:45 test1 kernel: usbus3: EHCI version 1.0
Nov  3 23:02:45 test1 kernel: usbus3 on ehci0
Nov  3 23:02:45 test1 kernel: usbus0: 12Mbps Full Speed USB v1.0
Nov  3 23:02:45 test1 kernel: usbus1: 12Mbps Full Speed USB v1.0
Nov  3 23:02:45 test1 kernel: usbus2: 12Mbps Full Speed USB v1.0
Nov  3 23:02:45 test1 kernel: usbus3: 480Mbps High Speed USB v2.0
Nov  3 23:02:45 test1 kernel: ugen1.1: Intel at usbus1
Nov  3 23:02:45 test1 kernel: uhub0: Intel UHCI root HUB, class 9/0, 
rev 1.00/1.00, addr 1 on usbus1

Nov  3 23:02:45 test1 kernel: ugen0.1: Intel at usbus0
Nov  3 23:02:45 test1 kernel: uhub1: Intel UHCI root HUB, class 9/0, 
rev 1.00/1.00, addr 1 on usbus0

Nov  3 23:02:45 test1 kernel: ugen3.1: Intel at usbus3
Nov  3 23:02:45 test1 kernel: uhub2: Intel EHCI root HUB, class 9/0, 
rev 2.00/1.00, addr 1 on usbus3

Nov  3 23:02:45 test1 kernel: ugen2.1: Intel at usbus2
Nov  3 23:02:45 test1 kernel: uhub3: Intel UHCI root HUB, class 9/0, 
rev 1.00/1.00, addr 1 on usbus2

Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: usb_alloc_device: set address 2 failed 
(USB_ERR_IOERROR, ignored)

Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_IOERROR

Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: usbd_req_re_enumerate: addr=2, set address 
failed! (USB_ERR_IOERROR, ignored)

Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_IOERROR

Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: usbd_req_re_enumerate: addr=2, set address 
failed! (USB_ERR_IOERROR, ignored)

Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_IOERROR

Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: usbd_req_re_enumerate: addr=2, set address 
failed! (USB_ERR_IOERROR, ignored)

Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_IOERROR

Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: usbd_req_re_enumerate: addr=2, set address 
failed! (USB_ERR_IOERROR, ignored)

Nov  3 23:02:45 test1 kernel: Root mount waiting for: usbus3
Nov  3 23:02:45 test1 kernel: