Bug 15521 - Undock button missing event - ThinkPad X40
Undock button missing event - ThinkPad X40
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: Config-Hotplug
All Linux
: P1 normal
Assigned To: Zhang Rui
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-12 11:29 UTC by Robert de Rooy
Modified: 2010-04-16 19:57 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.33
Tree: Fedora
Regression: No


Attachments
X40 DSTD (496.49 KB, text/plain)
2010-03-12 11:29 UTC, Robert de Rooy
Details
debug patch (994 bytes, patch)
2010-03-17 06:58 UTC, Zhang Rui
Details | Diff
syslog (34.13 KB, text/plain)
2010-03-17 09:49 UTC, Robert de Rooy
Details
debug patch 2 (1.04 KB, patch)
2010-03-18 01:59 UTC, Zhang Rui
Details | Diff
syslog (36.62 KB, text/plain)
2010-03-18 16:06 UTC, Robert de Rooy
Details
patch to fix the warning, based on https://patchwork.kernel.org/patch/66412/ (824 bytes, patch)
2010-03-19 01:36 UTC, Zhang Rui
Details | Diff

Description Robert de Rooy 2010-03-12 11:29:00 UTC
Created attachment 25482 [details]
X40 DSTD

Pressing the undock button on a "ThinkPad X4 Dock" with a ThinkPad X40 does not cause any udev events. And the lights on the dock never change to indicate it is safe to undock.

kernel-2.6.33-8.fc13.i686

This did not work with Fedora 12 either, so I decided to try F13alpha, but it made no difference.

# dmesg |grep -i acpi
 BIOS-e820: 000000004f6e0000 - 000000004f6f7000 (ACPI data)
 BIOS-e820: 000000004f6f7000 - 000000004f6f9000 (ACPI NVS)
ACPI: RSDP 000f6d10 00024 (v02 IBM   )
ACPI: XSDT 4f6e7e57 00054 (v01 IBM    TP-1U    00002080  LTP 00000000)
ACPI: FACP 4f6e7f00 000F4 (v03 IBM    TP-1U    00002080 IBM  00000001)
ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20091214/tbfadt-526)
ACPI Warning: Optional field Gpe1Block has zero address or length: 000000000000102C/0 (20091214/tbfadt-557)
ACPI: DSDT 4f6e80e7 0ECE9 (v01 IBM    TP-1U    00002080 MSFT 0100000E)
ACPI: FACS 4f6f8000 00040
ACPI: SSDT 4f6e80b4 00033 (v01 IBM    TP-1U    00002080 MSFT 0100000E)
ACPI: ECDT 4f6f6dd0 00052 (v01 IBM    TP-1U    00002080 IBM  00000001)
ACPI: TCPA 4f6f6e22 00032 (v01 IBM    TP-1U    00002080 PTL  00000001)
ACPI: APIC 4f6f6e54 0005A (v01 IBM    TP-1U    00002080 IBM  00000001)
ACPI: BOOT 4f6f6fd8 00028 (v01 IBM    TP-1U    00002080  LTP 00000001)
ACPI: Local APIC address 0xfee00000
  #6 [0000003000 - 0000007000]      ACPI WAKEUP ==> [0000003000 - 0000007000]
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: Core revision 20091214
ACPI: bus type pci registered
ACPI: EC: EC description table is found, configuring boot EC
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
ACPI: Power Resource [PUBS] (on)
ACPI: ACPI Dock Station Driver: 4 docks/bays found
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci_root PNP0A03:00: ignoring host bridge windows from ACPI; boot with "pci=use_crs" to use them
pci 0000:00:1f.0: quirk: [io  0x1000-0x107f] claimed by ICH4 ACPI/GPIO/TCO
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11)
PCI: Using ACPI for IRQ routing
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
apm: overridden by ACPI.
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp: Slot [1] registered
ACPI: AC Adapter [AC] (on-line)
ACPI: Lid Switch [LID]
ACPI: Sleep Button [SLPB]
ACPI: Power Button [PWRF]
Switching to clocksource acpi_pm
ACPI: Thermal Zone [THM0] (53 C)
ACPI: Battery Slot [BAT0] (battery present)
ehci_hcd 0000:00:1d.7: power state changed by ACPI to D0
uhci_hcd 0000:00:1d.0: power state changed by ACPI to D0
uhci_hcd 0000:00:1d.1: power state changed by ACPI to D0
ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
i915 0000:00:02.0: power state changed by ACPI to D0
parport_pc 00:0a: reported by Plug and Play ACPI
thinkpad_acpi: ThinkPad ACPI Extras v0.24
thinkpad_acpi: http://ibm-acpi.sf.net/
thinkpad_acpi: ThinkPad BIOS 1UETD3WW (2.08 ), EC 1UHTB2WW-1.62
thinkpad_acpi: IBM ThinkPad X40, model 2386F1U
thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is blocked
Registered led device: tpacpi::thinklight
Registered led device: tpacpi::power
Registered led device: tpacpi::standby
thinkpad_acpi: Console audio control enabled, mode: monitor (read only)
input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input7
Comment 1 Zhang Rui 2010-03-15 06:31:43 UTC
please verify if it's a duplicate of bug #15318.
i.e. please try the patch at http://bugzilla.kernel.org/show_bug.cgi?id=15318#c10 and see if it helps.
Comment 2 Robert de Rooy 2010-03-15 08:55:40 UTC
No, I had already tried that patch. Also that issue is resolved in 2.6.33.
Comment 3 Robert de Rooy 2010-03-15 09:13:29 UTC
Not sure how I can remove the Needinfo flag. I only seem to be able to change the status to resolved/verified/rejected/deferred/closed. None of which apply as there is no fix.
Comment 4 Zhang Rui 2010-03-16 01:11:06 UTC
please apply the debug patch in comment #4 and #6 and do the same test mentioned in bug #15318.
Comment 5 Robert de Rooy 2010-03-16 13:10:49 UTC
With the two patches applied on a 2.6.33.1 kernel, I get these messages when pressing the undock button

Mar 16 14:03:54 x40 kernel: Notification 0x3 to device \_SB_.MDCK
Mar 16 14:03:54 x40 kernel: Rui: in acpi_dock_notifier_calli, event 3
Comment 6 Robert de Rooy 2010-03-16 13:13:33 UTC
# grep . /sys/bus/acpi/drivers/*/*/path
/sys/bus/acpi/drivers/ac/ACPI0003:00/path:\_SB_.PCI0.LPC_.EC__.AC__
/sys/bus/acpi/drivers/battery/PNP0C0A:00/path:\_SB_.PCI0.LPC_.EC__.BAT0
/sys/bus/acpi/drivers/button/PNP0C0D:00/path:\_SB_.LID_
/sys/bus/acpi/drivers/button/PNP0C0E:00/path:\_SB_.SLPB
/sys/bus/acpi/drivers/ec/PNP0C09:00/path:\_SB_.PCI0.LPC_.EC__
/sys/bus/acpi/drivers/pci_link/PNP0C0F:00/path:\_SB_.LNKA
/sys/bus/acpi/drivers/pci_link/PNP0C0F:01/path:\_SB_.LNKB
/sys/bus/acpi/drivers/pci_link/PNP0C0F:02/path:\_SB_.LNKC
/sys/bus/acpi/drivers/pci_link/PNP0C0F:03/path:\_SB_.LNKD
/sys/bus/acpi/drivers/pci_link/PNP0C0F:04/path:\_SB_.LNKE
/sys/bus/acpi/drivers/pci_link/PNP0C0F:05/path:\_SB_.LNKF
/sys/bus/acpi/drivers/pci_link/PNP0C0F:06/path:\_SB_.LNKG
/sys/bus/acpi/drivers/pci_link/PNP0C0F:07/path:\_SB_.LNKH
/sys/bus/acpi/drivers/pci_root/PNP0A03:00/path:\_SB_.PCI0
/sys/bus/acpi/drivers/power/LNXPOWER:00/path:\_SB_.PCI0.LPC_.EC__.PUBS
/sys/bus/acpi/drivers/processor/LNXCPU:00/path:\_PR_.CPU_
/sys/bus/acpi/drivers/thermal/LNXTHERM:01/path:\_TZ_.THM0
/sys/bus/acpi/drivers/thinkpad_hotkey/IBM0068:00/path:\_SB_.PCI0.LPC_.EC__.HKEY
/sys/bus/acpi/drivers/video/LNXVIDEO:00/path:\_SB_.PCI0.VID_
Comment 7 Zhang Rui 2010-03-17 06:58:29 UTC
Created attachment 25562 [details]
debug patch

please apply this patch on top of the previous patches and attach the dmesg output after pressing the undock button.
Comment 8 Robert de Rooy 2010-03-17 09:49:08 UTC
Created attachment 25566 [details]
syslog

That patch causes the following to be printed in syslog during boot

ACPI: ACPI Dock Station Driver: 4 docks/bays found
\_SB_.PCI0.IDE0.SCDM.MSTR
\_SB_.PCI0.IDE0.SCND.MSTR
\_SB_.PCI0.LPC_.EC__.BAT1
\_SB_.GDCK

There is no change when pressing the undock button. Messages are the same as in Comment #5.
Comment 9 Robert de Rooy 2010-03-17 09:54:19 UTC
It seems a bit strange that it is called "\_SB_.GDCK" during boot, but "\_SB_.MDCK" when pressing the button.
Comment 10 Zhang Rui 2010-03-18 01:59:34 UTC
Created attachment 25574 [details]
debug patch 2

please apply this patch on top of the previous ones and see if the problem still exists.

The MDCK device should be added as a dock device after this patch applied.
And it handles the undock event when pressing the undock button.

please attach the full dmesg output after the undock button pressed.
Comment 11 Robert de Rooy 2010-03-18 16:06:25 UTC
Created attachment 25591 [details]
syslog

With the latest patch, it undocks, and the LEDs on the dock change to indicate it was safe to undock. But I do get a traceback.

Mar 18 17:02:07 x40 kernel: Notification 0x3 to device \_SB_.MDCK
Mar 18 17:02:07 x40 kernel: Rui: in acpi_dock_notifier_calli, event 3
Mar 18 17:02:07 x40 kernel:
Mar 18 17:02:07 x40 kernel: =======================================================
Mar 18 17:02:07 x40 kernel: [ INFO: possible circular locking dependency detected ]
Mar 18 17:02:07 x40 kernel: 2.6.33.1 #3
Mar 18 17:02:07 x40 kernel: -------------------------------------------------------
Mar 18 17:02:07 x40 kernel: kacpi_hotplug/18 is trying to acquire lock:
Mar 18 17:02:07 x40 kernel: (kacpid){+.+.+.}, at: [<c044f5d8>] flush_workqueue+0x0/0x94
Mar 18 17:02:07 x40 kernel:
Mar 18 17:02:07 x40 kernel: but task is already holding lock:
Mar 18 17:02:07 x40 kernel: ((&dpc->work)){+.+.+.}, at: [<c044eead>] worker_thread+0x15d/0x262
Mar 18 17:02:07 x40 kernel:
Mar 18 17:02:07 x40 kernel: which lock already depends on the new lock.
Mar 18 17:02:07 x40 kernel:
Mar 18 17:02:07 x40 kernel:
Mar 18 17:02:07 x40 kernel: the existing dependency chain (in reverse order) is:
Mar 18 17:02:07 x40 kernel:
Mar 18 17:02:07 x40 kernel: -> #1 ((&dpc->work)){+.+.+.}:
Mar 18 17:02:07 x40 kernel:       [<c0463be7>] __lock_acquire+0xa2b/0xb91
Mar 18 17:02:07 x40 kernel:       [<c0463de0>] lock_acquire+0x93/0xb1
Mar 18 17:02:07 x40 kernel:       [<c044eee9>] worker_thread+0x199/0x262
Mar 18 17:02:07 x40 kernel:       [<c045230c>] kthread+0x6f/0x74
Mar 18 17:02:07 x40 kernel:       [<c0403842>] kernel_thread_helper+0x6/0x10
Mar 18 17:02:07 x40 kernel:
Mar 18 17:02:07 x40 kernel: -> #0 (kacpid){+.+.+.}:
Mar 18 17:02:07 x40 kernel:       [<c0463ae9>] __lock_acquire+0x92d/0xb91
Mar 18 17:02:07 x40 kernel:       [<c0463de0>] lock_acquire+0x93/0xb1
Mar 18 17:02:07 x40 kernel:       [<c044f624>] flush_workqueue+0x4c/0x94
Mar 18 17:02:07 x40 kernel:       [<c05f7feb>] acpi_os_wait_events_complete+0x12/0x1e
Mar 18 17:02:07 x40 kernel:       [<c05f8013>] acpi_os_execute_deferred+0x1c/0x2d
Mar 18 17:02:07 x40 kernel:       [<c044eeef>] worker_thread+0x19f/0x262
Mar 18 17:02:07 x40 kernel:       [<c045230c>] kthread+0x6f/0x74
Mar 18 17:02:07 x40 kernel:       [<c0403842>] kernel_thread_helper+0x6/0x10
Mar 18 17:02:07 x40 kernel:
Mar 18 17:02:07 x40 kernel: other info that might help us debug this:
Mar 18 17:02:07 x40 kernel:
Mar 18 17:02:07 x40 kernel: 2 locks held by kacpi_hotplug/18:
Mar 18 17:02:07 x40 kernel: #0:  (kacpi_hotplug){+.+...}, at: [<c044eead>] worker_thread+0x15d/0x262
Mar 18 17:02:07 x40 kernel: #1:  ((&dpc->work)){+.+.+.}, at: [<c044eead>] worker_thread+0x15d/0x262
Mar 18 17:02:07 x40 kernel:
Mar 18 17:02:07 x40 kernel: stack backtrace:
Mar 18 17:02:07 x40 kernel: Pid: 18, comm: kacpi_hotplug Not tainted 2.6.33.1 #3
Mar 18 17:02:07 x40 kernel: Call Trace:
Mar 18 17:02:07 x40 kernel: [<c07a93db>] ? printk+0x14/0x19
Mar 18 17:02:07 x40 kernel: [<c0462e87>] print_circular_bug+0x91/0x9d
Mar 18 17:02:07 x40 kernel: [<c0463ae9>] __lock_acquire+0x92d/0xb91
Mar 18 17:02:07 x40 kernel: [<c0463c2a>] ? __lock_acquire+0xa6e/0xb91
Mar 18 17:02:07 x40 kernel: [<c0463de0>] lock_acquire+0x93/0xb1
Mar 18 17:02:07 x40 kernel: [<c044f5d8>] ? flush_workqueue+0x0/0x94
Mar 18 17:02:07 x40 kernel: [<c044f624>] flush_workqueue+0x4c/0x94
Mar 18 17:02:07 x40 kernel: [<c044f5d8>] ? flush_workqueue+0x0/0x94
Mar 18 17:02:07 x40 kernel: [<c05f7feb>] acpi_os_wait_events_complete+0x12/0x1e
Mar 18 17:02:07 x40 kernel: [<c05f8013>] acpi_os_execute_deferred+0x1c/0x2d
Mar 18 17:02:07 x40 kernel: [<c044eeef>] worker_thread+0x19f/0x262
Mar 18 17:02:07 x40 kernel: [<c044eead>] ? worker_thread+0x15d/0x262
Mar 18 17:02:07 x40 kernel: [<c05f7ff7>] ? acpi_os_execute_deferred+0x0/0x2d
Mar 18 17:02:07 x40 kernel: [<c0452688>] ? autoremove_wake_function+0x0/0x34
Mar 18 17:02:07 x40 kernel: [<c044ed50>] ? worker_thread+0x0/0x262
Mar 18 17:02:07 x40 kernel: [<c045230c>] kthread+0x6f/0x74
Mar 18 17:02:07 x40 kernel: [<c045229d>] ? kthread+0x0/0x74
Mar 18 17:02:07 x40 kernel: [<c0403842>] kernel_thread_helper+0x6/0x10
Mar 18 17:02:07 x40 kernel: Rui: in dock_notify, ds->flags 0x10, event 3
Mar 18 17:02:07 x40 kernel: Rui: event 3, dock_in_progress: no
Mar 18 17:02:07 x40 kernel: ACPI: \_SB_.MDCK - undocking
Mar 18 17:02:07 x40 kernel: usb 1-1: USB disconnect, address 2
Comment 12 Zhang Rui 2010-03-19 01:36:26 UTC
Created attachment 25601 [details]
patch to fix the warning, based on https://patchwork.kernel.org/patch/66412/

please apply this patch on top and see if it helps.
Comment 13 Robert de Rooy 2010-03-19 08:08:06 UTC
Thanks!
That takes care of the warning. Any chance of submitting these for 2.6.33-stable?

Here is what I see now on a Undock, followed by a dock

Mar 19 09:03:14 x40 kernel: Notification 0x3 to device \_SB_.MDCK
Mar 19 09:03:14 x40 kernel: Rui: in acpi_dock_notifier_calli, event 3
Mar 19 09:03:14 x40 kernel: Rui: in dock_notify, ds->flags 0x10, event 3
Mar 19 09:03:14 x40 kernel: Rui: event 3, dock_in_progress: no
Mar 19 09:03:14 x40 kernel: ACPI: \_SB_.MDCK - undocking
Mar 19 09:03:14 x40 kernel: usb 1-1: USB disconnect, address 2
Mar 19 09:03:32 x40 kernel: e1000: eth0 NIC Link is Down
Mar 19 09:03:32 x40 NetworkManager: <info>  (eth0): carrier now OFF (device state 8, deferring action for 4 seconds)

Mar 19 09:03:33 x40 kernel: Notification 0x3 to device \_SB_.GDCK
Mar 19 09:03:33 x40 kernel: Rui: in acpi_dock_notifier_calli, event 3
Mar 19 09:03:33 x40 kernel: Notification 0x3 to device \_SB_.MDCK
Mar 19 09:03:33 x40 kernel: Rui: in acpi_dock_notifier_calli, event 3
Mar 19 09:03:33 x40 kernel: Rui: in dock_notify, ds->flags 0x10, event 3
Mar 19 09:03:33 x40 kernel: Rui: event 3, dock_in_progress: no
Mar 19 09:03:33 x40 kernel: ACPI: \_SB_.GDCK - undocking
Mar 19 09:03:33 x40 kernel: Rui: in dock_notify, ds->flags 0x10, event 3
Mar 19 09:03:33 x40 kernel: Rui: event 3, dock_in_progress: no
Mar 19 09:03:33 x40 kernel: ACPI: \_SB_.MDCK - undocking
Mar 19 09:03:36 x40 kernel: e1000: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
Mar 19 09:03:36 x40 NetworkManager: <info>  (eth0): carrier now ON (device state 8)
Mar 19 09:03:37 x40 kernel: Notification 0x0 to device \_SB_.MDCK
Mar 19 09:03:37 x40 kernel: Rui: in acpi_dock_notifier_calli, event 0
Mar 19 09:03:37 x40 kernel: usb 1-1: new high speed USB device using ehci_hcd and address 3
Mar 19 09:03:37 x40 kernel: usb 1-1: New USB device found, idVendor=04b3, idProduct=4484
Mar 19 09:03:37 x40 kernel: usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Mar 19 09:03:37 x40 kernel: hub 1-1:1.0: USB hub found
Mar 19 09:03:37 x40 kernel: hub 1-1:1.0: 3 ports detected
Mar 19 09:03:38 x40 kernel: Rui: in dock_notify, ds->flags 0x10, event 0
Mar 19 09:03:38 x40 kernel: Rui: event 0, dock_in_progress: no
Mar 19 09:03:38 x40 kernel: ACPI: \_SB_.MDCK - docking
Mar 19 09:03:38 x40 kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
Mar 19 09:03:38 x40 kernel: ata2: ACPI event, ACPI event
Mar 19 09:03:38 x40 kernel: ata2: soft resetting link
Mar 19 09:03:38 x40 pulseaudio[1428]: ratelimit.c: 6 events suppressed
Mar 19 09:03:38 x40 kernel: ata2: EH complete
Comment 14 Zhang Rui 2010-03-22 07:51:41 UTC
patches are sent to ACPI mail list.
please refer to
https://patchwork.kernel.org/patch/87371/
https://patchwork.kernel.org/patch/87373/

BTW: I agree they are good candidates for 2.6.33 stable.
Comment 15 Len Brown 2010-03-23 04:20:55 UTC
applied both patches in comment #14 to acpi tree
Comment 16 Len Brown 2010-04-16 19:57:16 UTC
patches below shipped in linux-2.6.34-rc4 
closed

commit bc73675b99fd9850dd914be01d71af99c5d2a1ae
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Mon Mar 22 15:48:54 2010 +0800

    ACPI: fixes a false alarm from lockdep
    
    fixes a false alarm from lockdep, as acpi hotplug workqueue waits other
    workqueues.
    http://bugzilla.kernel.org/show_bug.cgi?id=14553
    https://bugzilla.kernel.org/show_bug.cgi?id=15521
    
    Original-patch-from: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 1ee4d61fd9822fb89e63b88a66848477087cd82e
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Mon Mar 22 15:46:49 2010 +0800

    ACPI dock: support multiple ACPI dock devices
    
    There may be multiple ACPI dock devices exist in ACPI namespace
    and we should probe all of them.
    http://bugzilla.kernel.org/show_bug.cgi?id=15521
    
    CC: Li Shaohua <shaohua.li@intel.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

Note You need to log in before you can comment on or make changes to this bug.