2010-09-01 20:16:30 +08:00
|
|
|
What: /sys/module/pch_phub/drivers/.../pch_mac
|
|
|
|
|
Date: August 2010
|
|
|
|
|
KernelVersion: 2.6.35
|
|
|
|
|
Contact: masa-korg@dsn.okisemi.com
|
|
|
|
|
Description: Write/read GbE MAC address.
|
|
|
|
|
|
|
|
|
|
What: /sys/module/pch_phub/drivers/.../pch_firmware
|
|
|
|
|
Date: August 2010
|
|
|
|
|
KernelVersion: 2.6.35
|
|
|
|
|
Contact: masa-korg@dsn.okisemi.com
|
|
|
|
|
Description: Write/read Option ROM data.
|
|
|
|
|
|
USB: EHCI: Allow users to override 80% max periodic bandwidth
There are cases, when 80% max isochronous bandwidth is too limiting.
For example I have two USB video capture cards which stream uncompressed
video, and to stream full NTSC + PAL videos we'd need
NTSC 640x480 YUV422 @30fps ~17.6 MB/s
PAL 720x576 YUV422 @25fps ~19.7 MB/s
isoc bandwidth.
Now, due to limited alt settings in capture devices NTSC one ends up
streaming with max_pkt_size=2688 and PAL with max_pkt_size=2892, both
with interval=1. In terms of microframe time allocation this gives
NTSC ~53us
PAL ~57us
and together
~110us > 100us == 80% of 125us uframe time.
So those two devices can't work together simultaneously because the'd
over allocate isochronous bandwidth.
80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and
both devices started to work together, so I though sometimes it would be
a good idea for users to override hardcoded default of max 80% isoc
bandwidth.
After all, isn't it a user who should decide how to load the bus? If I
can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB
newcomer, but that 80% set in stone by USB 2.0 specification seems to be
chosen pretty arbitrary to me, just to serve as a reasonable default.
NOTE 1
~~~~~~
for two streams with max_pkt_size=3072 (worst case) both time
allocation would be 60us+60us=120us which is 96% periodic bandwidth
leaving 4% for bulk and control. Alan Stern suggested that bulk then
would be problematic (less than 300*8 bittimes left per microframe), but
I think that is still enough for control traffic.
NOTE 2
~~~~~~
Sarah Sharp expressed concern that maxing out periodic bandwidth
could lead to vendor-specific hardware bugs on host controllers, because
> It's entirely possible that you'll run into
> vendor-specific bugs if you try to pack the schedule with isochronous
> transfers. I don't think any hardware designer would seriously test or
> validate their hardware with a schedule that is basically a violation of
> the USB bus spec (more than 80% for periodic transfers).
So far I've only tested this patch on my HP Mini 5103 with N10 chipset
kirr@mini:~$ lspci
00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge
00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller
00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI Controller (rev 02)
01:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8059 PCI-E Gigabit Ethernet Controller (rev 11)
and the system works stable with 110us/uframe (~88%) isoc bandwith allocated for
above-mentioned isochronous transfers.
NOTE 3
~~~~~~
This feature is off by default. I mean max periodic bandwidth is set to
100us/uframe by default exactly as it was before the patch. So only those of us
who need the extreme settings are taking the risk - normal users who do not
alter uframe_periodic_max sysfs attribute should not see any change at all.
NOTE 4
~~~~~~
I've tried to update documentation in Documentation/ABI/ thoroughly, but
only "TBD" was put into Documentation/usb/ehci.txt -- the text there seems
to be outdated and much needing refreshing, before it could be amended.
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-07-04 00:36:57 +08:00
|
|
|
|
|
|
|
|
What: /sys/module/ehci_hcd/drivers/.../uframe_periodic_max
|
|
|
|
|
Date: July 2011
|
|
|
|
|
KernelVersion: 3.1
|
|
|
|
|
Contact: Kirill Smelkov <kirr@mns.spb.ru>
|
|
|
|
|
Description: Maximum time allowed for periodic transfers per microframe (μs)
|
|
|
|
|
|
|
|
|
|
[ USB 2.0 sets maximum allowed time for periodic transfers per
|
|
|
|
|
microframe to be 80%, that is 100 microseconds out of 125
|
|
|
|
|
microseconds (full microframe).
|
|
|
|
|
|
|
|
|
|
However there are cases, when 80% max isochronous bandwidth is
|
|
|
|
|
too limiting. For example two video streams could require 110
|
|
|
|
|
microseconds of isochronous bandwidth per microframe to work
|
|
|
|
|
together. ]
|
|
|
|
|
|
|
|
|
|
Through this setting it is possible to raise the limit so that
|
|
|
|
|
the host controller would allow allocating more than 100
|
|
|
|
|
microseconds of periodic bandwidth per microframe.
|
|
|
|
|
|
|
|
|
|
Beware, non-standard modes are usually not thoroughly tested by
|
|
|
|
|
hardware designers, and the hardware can malfunction when this
|
|
|
|
|
setting differ from default 100.
|
2012-01-13 07:02:15 +08:00
|
|
|
|
|
|
|
|
What: /sys/module/*/{coresize,initsize}
|
|
|
|
|
Date: Jan 2012
|
|
|
|
|
KernelVersion:»·3.3
|
|
|
|
|
Contact: Kay Sievers <kay.sievers@vrfy.org>
|
|
|
|
|
Description: Module size in bytes.
|
|
|
|
|
|
|
|
|
|
What: /sys/module/*/taint
|
|
|
|
|
Date: Jan 2012
|
|
|
|
|
KernelVersion:»·3.3
|
|
|
|
|
Contact: Kay Sievers <kay.sievers@vrfy.org>
|
|
|
|
|
Description: Module taint flags:
|
|
|
|
|
P - proprietary module
|
|
|
|
|
O - out-of-tree module
|
|
|
|
|
F - force-loaded module
|
|
|
|
|
C - staging driver module
|
Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE
Users have reported being unable to trace non-signed modules loaded
within a kernel supporting module signature.
This is caused by tracepoint.c:tracepoint_module_coming() refusing to
take into account tracepoints sitting within force-loaded modules
(TAINT_FORCED_MODULE). The reason for this check, in the first place, is
that a force-loaded module may have a struct module incompatible with
the layout expected by the kernel, and can thus cause a kernel crash
upon forced load of that module on a kernel with CONFIG_TRACEPOINTS=y.
Tracepoints, however, specifically accept TAINT_OOT_MODULE and
TAINT_CRAP, since those modules do not lead to the "very likely system
crash" issue cited above for force-loaded modules.
With kernels having CONFIG_MODULE_SIG=y (signed modules), a non-signed
module is tainted re-using the TAINT_FORCED_MODULE taint flag.
Unfortunately, this means that Tracepoints treat that module as a
force-loaded module, and thus silently refuse to consider any tracepoint
within this module.
Since an unsigned module does not fit within the "very likely system
crash" category of tainting, add a new TAINT_UNSIGNED_MODULE taint flag
to specifically address this taint behavior, and accept those modules
within Tracepoints. We use the letter 'X' as a taint flag character for
a module being loaded that doesn't know how to sign its name (proposed
by Steven Rostedt).
Also add the missing 'O' entry to trace event show_module_flags() list
for the sake of completeness.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
NAKed-by: Ingo Molnar <mingo@redhat.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: David Howells <dhowells@redhat.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2014-03-13 09:41:30 +08:00
|
|
|
X - unsigned module
|