lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 27 Sep 2006 18:28:57 -0700
From:	David Brownell <david-b@...bell.net>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-usb-devel@...ts.sourceforge.net,
	David Hollis <dhollis@...ehollis.com>, support@...chip.com,
	dbrownell@...rs.sourceforge.net, linux-kernel@...r.kernel.org,
	Michael Helmling <supermihi@....de>
Subject: Re: [PATCH 1/3] driver for mcs7830 (aka DeLOCK) USB ethernet adapter

On Saturday 16 September 2006 4:02 pm, Arnd Bergmann wrote:
> This driver adds support for the DeLOCK USB ethernet adapter
> and potentially others based on the MosChip MCS7830 chip.
> 
> It is based on the usbnet and asix drivers as well as the
> original device driver provided by MosChip, which in turn
> was based on the usbnet driver.
> 
> It has been tested successfully on an OHCI, but interestingly
> there seems to be a problem with the mcs7830 when connected to
> the ICH6/EHCI in my thinkpad: it keeps receiving lots of
> broken packets in the RX interrupt. The problem goes away when
> I'm using an active USB hub, so I assume it's not related to
> the device driver, but rather to the hardware.
> 
> Signed-off-by: Arnd Bergmann <arnd@...db.de>

Signed-off-by: David Brownell <dbrownell@...rs.sourceforge.net>

... yes, I'd assume it's a hardware issue too.  Try different
cables; if you have a fast 'scope, you might see what kind of
eye diagram you get.  The hub might improve the signal quality.


Do you know how the remote wakeup mechanism works for this chip?
It'd be interesting to see "usbnet" be taught how to autosuspend
chips which will wake up the USB host when they get the right
kind of packet ... for example, passing the multicast/broadcast
filter, or addressed directly to that adapter.

Such an autosuspend mechanism would let the host controller stop
polling a mostly-idle network link, getting rid of one source of
periodic DMA transfers and thus allowing deeper sleep states for
many x86 family CPUs.  And also, I'd expect, giving fewer
opportunities for those broken RX packets.  :)

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ