* Re: Linux 3.4-rc4
[not found] ` <20120422040715.GA30689@elliptictech.com>
@ 2012-04-22 4:51 ` Linus Torvalds
2012-04-22 7:26 ` Dave Airlie
2012-04-22 16:40 ` Nick Bowler
0 siblings, 2 replies; 30+ messages in thread
From: Linus Torvalds @ 2012-04-22 4:51 UTC (permalink / raw)
To: David Airlie, Ben Skeggs, Martin Peres, dri-devel
Cc: Nick Bowler, Linux Kernel Mailing List
David & co, any ideas?
There are other reports of problems with 3.3.x kernels, there's a
report from Tim <timliette@woh.rr.com> which may be related (also
apparently working in 3.2, broken black screen in all 3.3.x).
Nick, I realize you had trouble with a bisection already, but it might
really be worth trying again. Do a
git bisect visualize
and try to pick a good commit (avoding the problems you hit) when you
hit a problem, and then do
git reset --hard <that-point>
to force bisection to try another place. That way you can sometimes
avoid the problem spots, and continue the bisection.
Linus
On Sat, Apr 21, 2012 at 9:07 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
> On 2012-04-21 15:43 -0700, Linus Torvalds wrote:
>> But none of it really looks all that scary. It looks like the 3.4
>> release is all on track, but please do holler if you see regressions.
>
> OK, I'll holler. Nouveau is still broken in mainline, as it has been
> since March or so, first reported here:
>
> Subject: Regression: black screen on VGA w/ nouveau in Linux 3.3.
> http://thread.gmane.org/gmane.linux.kernel/1269631
>
> So far, attempts to elicit a response of any kind from maintainers has
> been about as successful as talking to my doorknob.
>
> Thanks,
> --
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-22 4:51 ` Linux 3.4-rc4 Linus Torvalds
@ 2012-04-22 7:26 ` Dave Airlie
2012-04-22 16:42 ` Nick Bowler
2012-04-23 3:16 ` Ben Skeggs
2012-04-22 16:40 ` Nick Bowler
1 sibling, 2 replies; 30+ messages in thread
From: Dave Airlie @ 2012-04-22 7:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nick Bowler, Martin Peres, Linux Kernel Mailing List, dri-devel,
Ben Skeggs
On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> David & co, any ideas?
I've been asking Ben about this, I might have to use a bit more pressure,
It would be worth bisecting drivers/gpu/drm only, I doubt its going to
be outside that area.
Dave.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-22 4:51 ` Linux 3.4-rc4 Linus Torvalds
2012-04-22 7:26 ` Dave Airlie
@ 2012-04-22 16:40 ` Nick Bowler
2012-04-22 18:20 ` Geert Uytterhoeven
2012-04-23 0:05 ` Nick Bowler
1 sibling, 2 replies; 30+ messages in thread
From: Nick Bowler @ 2012-04-22 16:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Airlie, Ben Skeggs, Martin Peres, dri-devel,
Linux Kernel Mailing List
On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> Nick, I realize you had trouble with a bisection already, but it might
> really be worth trying again. Do a
>
> git bisect visualize
>
> and try to pick a good commit (avoding the problems you hit) when you
> hit a problem, and then do
>
> git reset --hard <that-point>
>
> to force bisection to try another place. That way you can sometimes
> avoid the problem spots, and continue the bisection.
Unfortunately, I think the whole swath of commits bisect wants to test
are broken (as in, they panic before I get to see whether or not the VGA
is working), because the commit from which most of the drm trees were
based appears to be broken. Nevertheless, I've included the new bisect
log (four new commits marked skip as opposed to last time). I've also
included the boot log from a crashing kernel, in case someone recognizes
how I can avoid this during bisection. Note that this crash is *not* a
regression that exists in current mainline -- bisecting this issue was
the first time I had ever seen it.
(Aside: is there a way to run "git bisect skip" without causing a new
working tree to be immediately checked out? When I'm going to be
picking the next commit manually anyway, having git bisect checkout a
new tree arbitrarily, potentially forcing a complete recompile (~30
minutes) when the commit I picked could have been incrementally compiled
in ~1 minute is pretty annoying...)
git bisect start 'drivers/gpu'
# bad: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3
git bisect bad c16fa4f2ad19908a47c63d8fa436a1178438c7e7
# good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610
# skip: [5d56fe5fd794a98c4f446f8665fd06b82e93ff64] Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-core-next
git bisect skip 5d56fe5fd794a98c4f446f8665fd06b82e93ff64
# good: [dffc9ceb55695f121adc57dd1fde7304c3afe81e] gma500: kill virtual mapping support
git bisect good dffc9ceb55695f121adc57dd1fde7304c3afe81e
# skip: [5c2a5ce689c99037771a6c110374461781a6f042] drm: add missing exports for i810 driver.
git bisect skip 5c2a5ce689c99037771a6c110374461781a6f042
# skip: [44517c44496062180a6376cc704b33129441ce60] drm/radeon/kms: Add an MSI quirk for Dell RS690
git bisect skip 44517c44496062180a6376cc704b33129441ce60
# --- The commits below this point are newly tested ---
# skip: [f7b24c42da1a7bbb98145d27aa716d8af3cae2a6] drm/nouveau/ttm: fix crash as a result of a recent ttm change
git bisect skip f7b24c42da1a7bbb98145d27aa716d8af3cae2a6
# skip: [0c101461e267850925218d6a6872c379f2498b16] drm/nv40/pm: parse fan pwm divisor from vbios tables
git bisect skip 0c101461e267850925218d6a6872c379f2498b16
# skip: [06e4cd64174b48345cbd99179b780a2bf4f96ab6] drm/radeon/kms: don't use 0 bpc for adjusting hdmi clock
git bisect skip 06e4cd64174b48345cbd99179b780a2bf4f96ab6
# skip: [1fbe6f625f69e48c4001051dc1431afc704acfaa] Merge tag 'v3.2-rc6' of /home/airlied/devel/kernel/linux-2.6 into drm-core-next
git bisect skip 1fbe6f625f69e48c4001051dc1431afc704acfaa
Linux version 3.2.0-rc6-bisect-00099-g1fbe6f6 (nick@artemis) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #60 PREEMPT Sun Apr 22 12:04:36 EDT 2012
Command line: root=md:name=newroot console=ttyS0,115200n8
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007ffc0000 (usable)
BIOS-e820: 000000007ffc0000 - 000000007ffd0000 (ACPI data)
BIOS-e820: 000000007ffd0000 - 0000000080000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ff7c0000 - 0000000100000000 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
AGP bridge at 00:00:00
Aperture from AGP @ f8000000 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f8000000 size 32 MB (APSIZE 0)
last_pfn = 0x7ffc0 max_arch_pfn = 0x400000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [ffff8800000ff780] ff780
init_memory_mapping: 0000000000000000-000000007ffc0000
RAMDISK: 37c9c000 - 37ff0000
ACPI: RSDP 00000000000f9cb0 00021 (v02 ACPIAM)
ACPI: XSDT 000000007ffc0100 0003C (v01 A M I OEMXSDT 01000618 MSFT 00000097)
ACPI: FACP 000000007ffc0290 000F4 (v03 A M I OEMFACP 01000618 MSFT 00000097)
ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110623/tbfadt-529)
ACPI Warning: Optional field Gpe1Block has zero address or length: 0x00000000000044A0/0x0 (20110623/tbfadt-560)
ACPI: DSDT 000000007ffc0400 04524 (v01 A0055 A0055003 00000003 INTL 02002026)
ACPI: FACS 000000007ffd0000 00040
ACPI: APIC 000000007ffc0390 00068 (v01 A M I OEMAPIC 01000618 MSFT 00000097)
ACPI: OEMB 000000007ffd0040 00041 (v01 A M I OEMBIOS 01000618 MSFT 00000097)
Zone PFN ranges:
DMA 0x00000010 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal empty
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000010 -> 0x0000009f
0: 0x00000100 -> 0x0007ffc0
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 80000000 (gap: 80000000:7ec00000)
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 516939
Kernel command line: root=md:name=newroot console=ttyS0,115200n8
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Checking aperture...
AGP bridge at 00:00:00
Aperture from AGP @ f8000000 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f8000000 size 32 MB (APSIZE 0)
Node 0: aperture @ f8000000 size 64 MB
Memory: 2053596k/2096896k available (3110k kernel code, 452k absent, 42848k reserved, 3386k data, 496k init)
NR_IRQS:4352 nr_irqs:256 16
Extended CMOS year: 2000
Console: colour VGA+ 80x25
console [ttyS0] enabled
kmemleak: Kernel memory leak detector disabled
Fast TSC calibration using PIT
Detected 2009.331 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 4018.66 BogoMIPS (lpj=2009331)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 256
mce: CPU supports 5 MCE banks
CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 08
ACPI: Core revision 20110623
Performance Events: AMD PMU driver.
... version: 0
... bit width: 48
... generic registers: 4
... value mask: 0000ffffffffffff
... max period: 00007fffffffffff
... fixed-purpose events: 0
... event mask: 000000000000000f
MCE: In-kernel MCE decoding enabled.
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
devtmpfs: initialized
NET: Registered protocol family 16
TOM: 0000000080000000 aka 2048M
ACPI: bus type pci registered
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Executed 1 blocks of module-level executable AML code
ACPI: Actual Package length (234) is larger than NumElements field (3), truncated
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: Power Resource [ISAV] (on)
ACPI: No dock devices found.
PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
pci 0000:00:0b.0: PCI bridge to [bus 01-01]
pci 0000:00:0e.0: PCI bridge to [bus 02-02]
pci0000:00: Unable to request _OSC control (_OSC support mask: 0x18)
ACPI: PCI Interrupt Link [LNKA] (IRQs 16 17 18 19) *10
ACPI: PCI Interrupt Link [LNKB] (IRQs 16 17 18 19) *9
ACPI: PCI Interrupt Link [LNKC] (IRQs 16 17 18 19) *7
ACPI: PCI Interrupt Link [LNKD] (IRQs 16 17 18 19) *9
ACPI: PCI Interrupt Link [LNKE] (IRQs 16 17 18 19) *11
ACPI: PCI Interrupt Link [LUS0] (IRQs 20 21 22) *5
ACPI: PCI Interrupt Link [LUS1] (IRQs 20 21 22) *9
ACPI: PCI Interrupt Link [LUS2] (IRQs 20 21 22) *10
ACPI: PCI Interrupt Link [LKLN] (IRQs 20 21 22) *3
ACPI: PCI Interrupt Link [LAUI] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [LKMO] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [LKSM] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [LTID] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [LTIE] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [LATA] (IRQs 20 21 22) *14
vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:01:00.0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
wmi: Mapper loaded
PCI: Using ACPI for IRQ routing
pci 0000:00:00.0: address space collision: [mem 0xf8000000-0xfbffffff pref] conflicts with GART [mem 0xf8000000-0xfbffffff]
pnp: PnP ACPI init
ACPI: bus type pnp registered
system 00:06: [io 0x0190-0x0193] has been reserved
system 00:06: [io 0x04d0-0x04d1] has been reserved
system 00:06: [io 0x4000-0x40ff window] has been reserved
system 00:06: [io 0x4400-0x44ff window] has been reserved
system 00:06: [io 0x4800-0x48ff window] has been reserved
system 00:07: [mem 0xfec00000-0xfec00fff] could not be reserved
system 00:07: [mem 0xfee00000-0xfeefffff] could not be reserved
system 00:07: [mem 0xff780000-0xff7bffff] has been reserved
system 00:08: [io 0x0480-0x0487] has been reserved
system 00:08: [io 0x0d00-0x0d07] has been reserved
pnp 00:0a: disabling [mem 0x00000000-0x0009ffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x03ffffff pref]
pnp 00:0a: disabling [mem 0x000c0000-0x000dffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x03ffffff pref]
pnp 00:0a: disabling [mem 0x000e0000-0x000fffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x03ffffff pref]
pnp 00:0a: disabling [mem 0x00100000-0x7fffffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x03ffffff pref]
system 00:0a: [mem 0xff7c0000-0xffffffff] has been reserved
pnp: PnP ACPI: found 11 devices
ACPI: ACPI bus type pnp unregistered
Switching to clocksource acpi_pm
pci 0000:00:0b.0: PCI bridge to [bus 01-01]
pci 0000:00:0b.0: bridge window [mem 0xfc800000-0xfe8fffff]
pci 0000:00:0b.0: bridge window [mem 0xd4700000-0xf46fffff pref]
pci 0000:00:0e.0: PCI bridge to [bus 02-02]
pci 0000:00:0e.0: bridge window [io 0xa000-0xcfff]
pci 0000:00:0e.0: bridge window [mem 0xfe900000-0xfeafffff]
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
UDP hash table entries: 1024 (order: 3, 32768 bytes)
UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 3408k freed
agpgart-amd64 0000:00:00.0: AGP bridge [10de/00e1]
agpgart-amd64 0000:00:00.0: aperture size 4096 MB is not right, using settings from NB
agpgart-amd64 0000:00:00.0: setting up Nforce3 AGP
agpgart-amd64 0000:00:00.0: AGP aperture is 64M @ 0xf8000000
msgmni has been set to 4017
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
ACPI: Power Button [PWRB]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
ACPI: Power Button [PWRF]
ACPI: processor limited to max C-state 1
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.12b
Linux agpgart interface v0.103
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19
nouveau 0000:01:00.0: PCI INT A -> Link[LNKE] -> GSI 19 (level, low) -> IRQ 19
[drm] nouveau 0000:01:00.0: Detected an NV30 generation card (0x436200a1)
[drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN
[drm] nouveau 0000:01:00.0: ... appears to be valid
[drm] nouveau 0000:01:00.0: BMP BIOS found
[drm] nouveau 0000:01:00.0: BMP version 5.40
[drm] nouveau 0000:01:00.0: Bios version 04.36.20.21
[drm] nouveau 0000:01:00.0: Found Display Configuration Block version 2.2
[drm] nouveau 0000:01:00.0: Raw DCB entry 0: 01000300 00009c40
[drm] nouveau 0000:01:00.0: Raw DCB entry 1: 02010310 00009c40
[drm] nouveau 0000:01:00.0: Raw DCB entry 2: 04000302 00000000
[drm] nouveau 0000:01:00.0: Raw DCB entry 3: 02020321 00000303
[drm] nouveau 0000:01:00.0: Loading NV17 power sequencing microcode
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xF01D
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xF4E1
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xF723
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xF896
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xF8B3
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 5 at offset 0xF8D0
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 6 at offset 0xF959
Apr 22 16:12:33 modprobe: FATAL: Could not open '/lib/modules/3.2.0-rc6-bisect-00099-g1fbe6f6/kernel/drivers/hwmon/lm90.ko': No such file or directory
[drm] nouveau 0000:01:00.0: 0 available performance level(s)
[drm] nouveau 0000:01:00.0: c: core 425MHz memory 501MHz voltage 1350mV
[TTM] Zone kernel: Available graphics memory: 1028502 kiB.
[TTM] Initializing pool allocator.
[TTM] Initializing DMA pool allocator.
[drm] nouveau 0000:01:00.0: Detected 256MiB VRAM
agpgart-amd64 0000:00:00.0: AGP 3.0 bridge
agpgart: swapper tried to set rate=x12. Setting to AGP3 x8 mode.
agpgart-amd64 0000:00:00.0: putting AGP V3 device into 8x mode
nouveau 0000:01:00.0: putting AGP V3 device into 8x mode
[drm] nouveau 0000:01:00.0: 64 MiB GART (aperture)
[drm] nouveau 0000:01:00.0: Saving VGA fonts
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff811acbfa>] nouveau_ttm_tt_populate+0xb9/0x194
PGD 0
Oops: 0002 [#1] PREEMPT
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 3.2.0-rc6-bisect-00099-g1fbe6f6 #60 ASUSTek Computer Inc. K8N-E-Deluxe/'K8N-E-Deluxe'
RIP: 0010:[<ffffffff811acbfa>] [<ffffffff811acbfa>] nouveau_ttm_tt_populate+0xb9/0x194
RSP: 0018:ffff88007d05d7e0 EFLAGS: 00010202
RAX: 000000007c061000 RBX: ffff88007d34cec0 RCX: 0000000000001000
RDX: ffffea0001b21558 RSI: ffff88007d05d8f0 RDI: ffffffff8149508d
RBP: ffff88007d05d820 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: dead000000100100 R12: 0000000000000000
R13: 0000000000000000 R14: ffff88007d184000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff8161c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000007d349000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff88007d05c000, task ffff88007d050ac0)
Stack:
ffffffff816520b8 0000000001b63980 00000000000000c0 ffff88007d34cec0
ffff88007c2002f8 ffff88007d05d8f0 ffff88007d05d800 0000000000000000
ffff88007d05d850 ffffffff8119c59c ffff88007c2002f8 ffff88007d05d8f0
Call Trace:
[<ffffffff8119c59c>] ttm_tt_bind+0x2c/0x4f
[<ffffffff8119e23c>] ttm_bo_handle_move_mem+0x110/0x29e
[<ffffffff8119f07e>] ttm_bo_move_buffer+0xe9/0x124
[<ffffffff81191ecd>] ? drm_mm_kmalloc+0x28/0xa5
[<ffffffff8119f16b>] ttm_bo_validate+0xb2/0xed
[<ffffffff8119f506>] ttm_bo_init+0x360/0x399
[<ffffffff811ad163>] nouveau_bo_new+0x220/0x23a
[<ffffffff811acd46>] ? nouveau_ttm_tt_create+0x71/0x71
[<ffffffff811c8ae3>] ? nouveau_ramht_insert+0x225/0x32e
[<ffffffff811afce4>] nouveau_gem_new+0x55/0xe5
[<ffffffff811ab0b5>] ? nouveau_gpuobj_channel_init+0x637/0x68a
[<ffffffff811ab4de>] nouveau_notifier_init_channel+0x5f/0x134
[<ffffffff811a7945>] nouveau_channel_alloc+0x1fd/0x568
[<ffffffff811a6569>] nouveau_card_init+0x134c/0x14be
[<ffffffff811a6d93>] nouveau_load+0x5d8/0x61f
[<ffffffff8118f723>] drm_get_pci_dev+0x158/0x25d
[<ffffffff81301f3e>] nouveau_pci_probe+0x10/0x12
[<ffffffff8111854b>] local_pci_probe+0x12/0x16
[<ffffffff811187b5>] pci_device_probe+0x65/0x96
[<ffffffff810dedf1>] ? sysfs_create_link+0xe/0x10
[<ffffffff81224ae1>] driver_probe_device+0xa3/0x131
[<ffffffff81224bc7>] __driver_attach+0x58/0x7c
[<ffffffff81224b6f>] ? driver_probe_device+0x131/0x131
[<ffffffff81223dd4>] bus_for_each_dev+0x51/0x7d
[<ffffffff812247e4>] driver_attach+0x19/0x1b
[<ffffffff81224470>] bus_add_driver+0xb2/0x206
[<ffffffff81224f1a>] driver_register+0x96/0x103
[<ffffffff81118a24>] __pci_register_driver+0x47/0xb3
[<ffffffff8118f8ad>] drm_pci_init+0x85/0xea
[<ffffffff8167c30f>] ? ttm_init+0x62/0x62
[<ffffffff8167c30f>] ? ttm_init+0x62/0x62
[<ffffffff8167c35e>] nouveau_init+0x4f/0x51
[<ffffffff810002e2>] do_one_initcall+0x78/0x126
[<ffffffff8165ab3a>] kernel_init+0x8b/0x10b
[<ffffffff81025bd9>] ? schedule_tail+0x16/0x3d
[<ffffffff81306cc4>] kernel_thread_helper+0x4/0x10
[<ffffffff8165aaaf>] ? start_kernel+0x31d/0x31d
[<ffffffff81306cc0>] ? gs_change+0xb/0xb
Code: 88 00 00 00 48 8b 80 70 01 00 00 48 85 c0 75 0b eb 02 31 ff 48 8b 05 66 c1 46 00 45 31 c9 45 31 c0 31 d2 b9 00 10 00 00 ff 50 10
89 07 48 8b 43 50 4a 8b 34 e8 49 8b 86 c0 02 00 00 48 89 c7
RIP [<ffffffff811acbfa>] nouveau_ttm_tt_populate+0xb9/0x194
RSP <ffff88007d05d7e0>
CR2: 0000000000000000
---[ end trace eb6d24f9d33e5957 ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G D 3.2.0-rc6-bisect-00099-g1fbe6f6 #60
Call Trace:
[<ffffffff81303729>] panic+0x9a/0x19e
[<ffffffff8102c76b>] do_exit+0x8e/0x68c
[<ffffffff8102b0b7>] ? kmsg_dump+0xe5/0xf6
[<ffffffff8100487c>] oops_end+0x9d/0xa5
[<ffffffff8101c951>] no_context+0x1fd/0x20c
[<ffffffff8101e511>] ? change_page_attr_set_clr+0x265/0x335
[<ffffffff8101cb10>] __bad_area_nosemaphore+0x1b0/0x1d0
[<ffffffff8101cb3e>] bad_area_nosemaphore+0xe/0x10
[<ffffffff8101ced9>] do_page_fault+0x173/0x36e
[<ffffffff810312f7>] ? ns_capable+0x43/0x58
[<ffffffff8119c499>] ? ttm_mem_global_alloc_zone.clone.3+0x126/0x148
[<ffffffff8119c51e>] ? ttm_mem_global_alloc_page+0x50/0x52
[<ffffffff81305b5f>] page_fault+0x1f/0x30
[<ffffffff811acbfa>] ? nouveau_ttm_tt_populate+0xb9/0x194
[<ffffffff8119c59c>] ttm_tt_bind+0x2c/0x4f
[<ffffffff8119e23c>] ttm_bo_handle_move_mem+0x110/0x29e
[<ffffffff8119f07e>] ttm_bo_move_buffer+0xe9/0x124
[<ffffffff81191ecd>] ? drm_mm_kmalloc+0x28/0xa5
[<ffffffff8119f16b>] ttm_bo_validate+0xb2/0xed
[<ffffffff8119f506>] ttm_bo_init+0x360/0x399
[<ffffffff811ad163>] nouveau_bo_new+0x220/0x23a
[<ffffffff811acd46>] ? nouveau_ttm_tt_create+0x71/0x71
[<ffffffff811c8ae3>] ? nouveau_ramht_insert+0x225/0x32e
[<ffffffff811afce4>] nouveau_gem_new+0x55/0xe5
[<ffffffff811ab0b5>] ? nouveau_gpuobj_channel_init+0x637/0x68a
[<ffffffff811ab4de>] nouveau_notifier_init_channel+0x5f/0x134
[<ffffffff811a7945>] nouveau_channel_alloc+0x1fd/0x568
[<ffffffff811a6569>] nouveau_card_init+0x134c/0x14be
[<ffffffff811a6d93>] nouveau_load+0x5d8/0x61f
[<ffffffff8118f723>] drm_get_pci_dev+0x158/0x25d
[<ffffffff81301f3e>] nouveau_pci_probe+0x10/0x12
[<ffffffff8111854b>] local_pci_probe+0x12/0x16
[<ffffffff811187b5>] pci_device_probe+0x65/0x96
[<ffffffff810dedf1>] ? sysfs_create_link+0xe/0x10
[<ffffffff81224ae1>] driver_probe_device+0xa3/0x131
[<ffffffff81224bc7>] __driver_attach+0x58/0x7c
[<ffffffff81224b6f>] ? driver_probe_device+0x131/0x131
[<ffffffff81223dd4>] bus_for_each_dev+0x51/0x7d
[<ffffffff812247e4>] driver_attach+0x19/0x1b
[<ffffffff81224470>] bus_add_driver+0xb2/0x206
[<ffffffff81224f1a>] driver_register+0x96/0x103
[<ffffffff81118a24>] __pci_register_driver+0x47/0xb3
[<ffffffff8118f8ad>] drm_pci_init+0x85/0xea
[<ffffffff8167c30f>] ? ttm_init+0x62/0x62
[<ffffffff8167c30f>] ? ttm_init+0x62/0x62
[<ffffffff8167c35e>] nouveau_init+0x4f/0x51
[<ffffffff810002e2>] do_one_initcall+0x78/0x126
[<ffffffff8165ab3a>] kernel_init+0x8b/0x10b
[<ffffffff81025bd9>] ? schedule_tail+0x16/0x3d
[<ffffffff81306cc4>] kernel_thread_helper+0x4/0x10
[<ffffffff8165aaaf>] ? start_kernel+0x31d/0x31d
[<ffffffff81306cc0>] ? gs_change+0xb/0xb
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-22 7:26 ` Dave Airlie
@ 2012-04-22 16:42 ` Nick Bowler
2012-04-23 3:16 ` Ben Skeggs
1 sibling, 0 replies; 30+ messages in thread
From: Nick Bowler @ 2012-04-22 16:42 UTC (permalink / raw)
To: Dave Airlie
Cc: Linus Torvalds, David Airlie, Ben Skeggs, Martin Peres, dri-devel,
Linux Kernel Mailing List
On 2012-04-22 08:26 +0100, Dave Airlie wrote:
> I've been asking Ben about this, I might have to use a bit more pressure,
>
> It would be worth bisecting drivers/gpu/drm only, I doubt its going to
> be outside that area.
Since the original bisection was restricted to drivers/gpu, and there
appears to be exactly 0 commits between v3.2 and v3.3 that touch files
in drivers/gpu outside of drivers/gpu/drm, I think this should make no
difference?
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-22 16:40 ` Nick Bowler
@ 2012-04-22 18:20 ` Geert Uytterhoeven
2012-04-23 0:05 ` Nick Bowler
1 sibling, 0 replies; 30+ messages in thread
From: Geert Uytterhoeven @ 2012-04-22 18:20 UTC (permalink / raw)
To: Nick Bowler
Cc: Linus Torvalds, David Airlie, Ben Skeggs, Martin Peres, dri-devel,
Linux Kernel Mailing List
On Sun, Apr 22, 2012 at 18:40, Nick Bowler <nbowler@elliptictech.com> wrote:
> (Aside: is there a way to run "git bisect skip" without causing a new
> working tree to be immediately checked out? When I'm going to be
> picking the next commit manually anyway, having git bisect checkout a
> new tree arbitrarily, potentially forcing a complete recompile (~30
> minutes) when the commit I picked could have been incrementally compiled
> in ~1 minute is pretty annoying...)
I can recommend using ccache for all your compiles.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-22 16:40 ` Nick Bowler
2012-04-22 18:20 ` Geert Uytterhoeven
@ 2012-04-23 0:05 ` Nick Bowler
2012-04-23 2:45 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 30+ messages in thread
From: Nick Bowler @ 2012-04-23 0:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Airlie, Ben Skeggs, Martin Peres, dri-devel,
Linux Kernel Mailing List
On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > Nick, I realize you had trouble with a bisection already, but it might
> > really be worth trying again. Do a
> >
> > git bisect visualize
> >
> > and try to pick a good commit (avoding the problems you hit) when you
> > hit a problem, and then do
> >
> > git reset --hard <that-point>
> >
> > to force bisection to try another place. That way you can sometimes
> > avoid the problem spots, and continue the bisection.
>
> Unfortunately, I think the whole swath of commits bisect wants to test
> are broken (as in, they panic before I get to see whether or not the VGA
> is working), because the commit from which most of the drm trees were
> based appears to be broken. Nevertheless, I've included the new bisect
> log (four new commits marked skip as opposed to last time). I've also
> included the boot log from a crashing kernel, in case someone recognizes
> how I can avoid this during bisection. Note that this crash is *not* a
> regression that exists in current mainline -- bisecting this issue was
> the first time I had ever seen it.
Following up on the above, the commit which introduces the panics during
boot is this one:
commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
Author: Jerome Glisse <jglisse@redhat.com>
Date: Wed Nov 9 17:15:26 2011 -0500
drm/ttm: isolate dma data from ttm_tt V4
Move dma data to a superset ttm_dma_tt structure which herit
from ttm_tt. This allow driver that don't use dma functionalities
to not have to waste memory for it.
V2 Rebase on top of no memory account changes (where/when is my
delorean when i need it ?)
V3 Make sure page list is initialized empty
V4 typo/syntax fixes
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
and the previous commit (3230cfc34fca: "drm/nouveau: enable the ttm dma
pool when swiotlb is active V3") works properly.
Sometime this week I suppose I'll try to track down the commit which
fixed the crashes...
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-23 0:05 ` Nick Bowler
@ 2012-04-23 2:45 ` Konrad Rzeszutek Wilk
2012-04-24 1:03 ` Nick Bowler
0 siblings, 1 reply; 30+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-04-23 2:45 UTC (permalink / raw)
To: Nick Bowler
Cc: Martin Peres, Linus Torvalds, Ben Skeggs, dri-devel,
Linux Kernel Mailing List
On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> > On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > > Nick, I realize you had trouble with a bisection already, but it might
> > > really be worth trying again. Do a
> > >
> > > git bisect visualize
> > >
> > > and try to pick a good commit (avoding the problems you hit) when you
> > > hit a problem, and then do
> > >
> > > git reset --hard <that-point>
> > >
> > > to force bisection to try another place. That way you can sometimes
> > > avoid the problem spots, and continue the bisection.
> >
> > Unfortunately, I think the whole swath of commits bisect wants to test
> > are broken (as in, they panic before I get to see whether or not the VGA
> > is working), because the commit from which most of the drm trees were
> > based appears to be broken. Nevertheless, I've included the new bisect
> > log (four new commits marked skip as opposed to last time). I've also
> > included the boot log from a crashing kernel, in case someone recognizes
> > how I can avoid this during bisection. Note that this crash is *not* a
> > regression that exists in current mainline -- bisecting this issue was
> > the first time I had ever seen it.
>
> Following up on the above, the commit which introduces the panics during
> boot is this one:
I think
dea7e0a ttm: fix agp since ttm tt rework
fixed that.
>
> commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> Author: Jerome Glisse <jglisse@redhat.com>
> Date: Wed Nov 9 17:15:26 2011 -0500
>
> drm/ttm: isolate dma data from ttm_tt V4
>
> Move dma data to a superset ttm_dma_tt structure which herit
> from ttm_tt. This allow driver that don't use dma functionalities
> to not have to waste memory for it.
>
> V2 Rebase on top of no memory account changes (where/when is my
> delorean when i need it ?)
> V3 Make sure page list is initialized empty
> V4 typo/syntax fixes
>
> Signed-off-by: Jerome Glisse <jglisse@redhat.com>
> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
>
> and the previous commit (3230cfc34fca: "drm/nouveau: enable the ttm dma
> pool when swiotlb is active V3") works properly.
>
> Sometime this week I suppose I'll try to track down the commit which
> fixed the crashes...
>
> Cheers,
> --
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-22 7:26 ` Dave Airlie
2012-04-22 16:42 ` Nick Bowler
@ 2012-04-23 3:16 ` Ben Skeggs
1 sibling, 0 replies; 30+ messages in thread
From: Ben Skeggs @ 2012-04-23 3:16 UTC (permalink / raw)
To: Dave Airlie
Cc: Linus Torvalds, Nick Bowler, Martin Peres,
Linux Kernel Mailing List, dri-devel
On Sun, 2012-04-22 at 08:26 +0100, Dave Airlie wrote:
> On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > David & co, any ideas?
>
> I've been asking Ben about this, I might have to use a bit more pressure,
I unfortunately haven't yet had any ideas which could be useful aside
from continuing to try and narrow down the change that caused the issue.
I've been using the VGA output on a lot of different boards (including
of the same generation as the one in the original bug report) with the
latest code without an issue..
Ben.
>
> It would be worth bisecting drivers/gpu/drm only, I doubt its going to
> be outside that area.
>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-23 2:45 ` Konrad Rzeszutek Wilk
@ 2012-04-24 1:03 ` Nick Bowler
2012-04-24 15:11 ` Konrad Rzeszutek Wilk
2012-04-25 1:35 ` Nick Bowler
0 siblings, 2 replies; 30+ messages in thread
From: Nick Bowler @ 2012-04-24 1:03 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Linus Torvalds, Martin Peres, Ben Skeggs, dri-devel,
Linux Kernel Mailing List
On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> > Following up on the above, the commit which introduces the panics during
> > boot is this one:
> >
> > commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> > Author: Jerome Glisse <jglisse@redhat.com>
> > Date: Wed Nov 9 17:15:26 2011 -0500
> >
> > drm/ttm: isolate dma data from ttm_tt V4
>
> I think
>
> dea7e0a ttm: fix agp since ttm tt rework
>
> fixed that.
Yes, I just tested this commit and the one immediately before it. The
one before crashes in the usual way, and dea7e0a boots (with the VGA
output black as in the original report). So this fixed the crash.
Now, returning to the original bisection, I marked that commit as "bad"
and dropped all the earlier "skip" markings. Git asks me to test commit
2a44e4997c5f ("drm/nouveau/disp: introduce proper init/fini, separate
from create/destroy"). I cherry picked the aforementioned ttm fix:
git cherry-pick -n dea7e0a
which succeeded. Howevew, the resulting kernel still crashes early,
although now in a different way. I just can't win :(
Linux version 3.2.0-rc6-bisect-00190-g2a44e49-dirty (nick@artemis) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #72 PREEMPT Mon Apr 23 20:23:10 EDT 2012
Command line: root=md:name=newroot console=ttyS0,115200n8
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007ffc0000 (usable)
BIOS-e820: 000000007ffc0000 - 000000007ffd0000 (ACPI data)
BIOS-e820: 000000007ffd0000 - 0000000080000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ff7c0000 - 0000000100000000 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
AGP bridge at 00:00:00
Aperture from AGP @ f8000000 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f8000000 size 32 MB (APSIZE 0)
last_pfn = 0x7ffc0 max_arch_pfn = 0x400000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [ffff8800000ff780] ff780
init_memory_mapping: 0000000000000000-000000007ffc0000
RAMDISK: 37c9c000 - 37ff0000
ACPI: RSDP 00000000000f9cb0 00021 (v02 ACPIAM)
ACPI: XSDT 000000007ffc0100 0003C (v01 A M I OEMXSDT 01000618 MSFT 00000097)
ACPI: FACP 000000007ffc0290 000F4 (v03 A M I OEMFACP 01000618 MSFT 00000097)
ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110623/tbfadt-529)
ACPI Warning: Optional field Gpe1Block has zero address or length: 0x00000000000044A0/0x0 (20110623/tbfadt-560)
ACPI: DSDT 000000007ffc0400 04524 (v01 A0055 A0055003 00000003 INTL 02002026)
ACPI: FACS 000000007ffd0000 00040
ACPI: APIC 000000007ffc0390 00068 (v01 A M I OEMAPIC 01000618 MSFT 00000097)
ACPI: OEMB 000000007ffd0040 00041 (v01 A M I OEMBIOS 01000618 MSFT 00000097)
Zone PFN ranges:
DMA 0x00000010 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal empty
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000010 -> 0x0000009f
0: 0x00000100 -> 0x0007ffc0
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 80000000 (gap: 80000000:7ec00000)
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 516939
Kernel command line: root=md:name=newroot console=ttyS0,115200n8
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Checking aperture...
AGP bridge at 00:00:00
Aperture from AGP @ f8000000 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f8000000 size 32 MB (APSIZE 0)
Node 0: aperture @ f8000000 size 64 MB
Memory: 2053596k/2096896k available (3122k kernel code, 452k absent, 42848k reserved, 3374k data, 496k init)
NR_IRQS:4352 nr_irqs:256 16
Extended CMOS year: 2000
Console: colour VGA+ 80x25
console [ttyS0] enabled
kmemleak: Kernel memory leak detector disabled
Fast TSC calibration using PIT
Detected 2009.519 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 4019.03 BogoMIPS (lpj=2009519)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 256
mce: CPU supports 5 MCE banks
CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 08
ACPI: Core revision 20110623
Performance Events: AMD PMU driver.
... version: 0
... bit width: 48
... generic registers: 4
... value mask: 0000ffffffffffff
... max period: 00007fffffffffff
... fixed-purpose events: 0
... event mask: 000000000000000f
MCE: In-kernel MCE decoding enabled.
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
devtmpfs: initialized
NET: Registered protocol family 16
TOM: 0000000080000000 aka 2048M
ACPI: bus type pci registered
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Executed 1 blocks of module-level executable AML code
ACPI: Actual Package length (234) is larger than NumElements field (3), truncated
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: Power Resource [ISAV] (on)
ACPI: No dock devices found.
PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
pci 0000:00:0b.0: PCI bridge to [bus 01-01]
pci 0000:00:0e.0: PCI bridge to [bus 02-02]
pci0000:00: Unable to request _OSC control (_OSC support mask: 0x18)
ACPI: PCI Interrupt Link [LNKA] (IRQs 16 17 18 19) *10
ACPI: PCI Interrupt Link [LNKB] (IRQs 16 17 18 19) *9
ACPI: PCI Interrupt Link [LNKC] (IRQs 16 17 18 19) *7
ACPI: PCI Interrupt Link [LNKD] (IRQs 16 17 18 19) *9
ACPI: PCI Interrupt Link [LNKE] (IRQs 16 17 18 19) *11
ACPI: PCI Interrupt Link [LUS0] (IRQs 20 21 22) *5
ACPI: PCI Interrupt Link [LUS1] (IRQs 20 21 22) *9
ACPI: PCI Interrupt Link [LUS2] (IRQs 20 21 22) *10
ACPI: PCI Interrupt Link [LKLN] (IRQs 20 21 22) *3
ACPI: PCI Interrupt Link [LAUI] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [LKMO] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [LKSM] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [LTID] (IRQs 20 21 22) *0
ACPI: PCI Interrupt Link [LTIE] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [LATA] (IRQs 20 21 22) *14
vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:01:00.0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
wmi: Mapper loaded
PCI: Using ACPI for IRQ routing
pci 0000:00:00.0: address space collision: [mem 0xf8000000-0xfbffffff pref] conflicts with GART [mem 0xf8000000-0xfbffffff]
pnp: PnP ACPI init
ACPI: bus type pnp registered
system 00:06: [io 0x0190-0x0193] has been reserved
system 00:06: [io 0x04d0-0x04d1] has been reserved
system 00:06: [io 0x4000-0x40ff window] has been reserved
system 00:06: [io 0x4400-0x44ff window] has been reserved
system 00:06: [io 0x4800-0x48ff window] has been reserved
system 00:07: [mem 0xfec00000-0xfec00fff] could not be reserved
system 00:07: [mem 0xfee00000-0xfeefffff] could not be reserved
system 00:07: [mem 0xff780000-0xff7bffff] has been reserved
system 00:08: [io 0x0480-0x0487] has been reserved
system 00:08: [io 0x0d00-0x0d07] has been reserved
pnp 00:0a: disabling [mem 0x00000000-0x0009ffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x03ffffff pref]
pnp 00:0a: disabling [mem 0x000c0000-0x000dffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x03ffffff pref]
pnp 00:0a: disabling [mem 0x000e0000-0x000fffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x03ffffff pref]
pnp 00:0a: disabling [mem 0x00100000-0x7fffffff] because it overlaps 0000:00:00.0 BAR 0 [mem 0x00000000-0x03ffffff pref]
system 00:0a: [mem 0xff7c0000-0xffffffff] has been reserved
pnp: PnP ACPI: found 11 devices
ACPI: ACPI bus type pnp unregistered
Switching to clocksource acpi_pm
pci 0000:00:0b.0: PCI bridge to [bus 01-01]
pci 0000:00:0b.0: bridge window [mem 0xfc800000-0xfe8fffff]
pci 0000:00:0b.0: bridge window [mem 0xd4700000-0xf46fffff pref]
pci 0000:00:0e.0: PCI bridge to [bus 02-02]
pci 0000:00:0e.0: bridge window [io 0xa000-0xcfff]
pci 0000:00:0e.0: bridge window [mem 0xfe900000-0xfeafffff]
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
UDP hash table entries: 1024 (order: 3, 32768 bytes)
UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 3408k freed
agpgart-amd64 0000:00:00.0: AGP bridge [10de/00e1]
agpgart-amd64 0000:00:00.0: aperture size 4096 MB is not right, using settings from NB
agpgart-amd64 0000:00:00.0: setting up Nforce3 AGP
agpgart-amd64 0000:00:00.0: AGP aperture is 64M @ 0xf8000000
msgmni has been set to 4017
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
ACPI: Power Button [PWRB]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
ACPI: Power Button [PWRF]
ACPI: processor limited to max C-state 1
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.12b
Linux agpgart interface v0.103
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19
nouveau 0000:01:00.0: PCI INT A -> Link[LNKE] -> GSI 19 (level, low) -> IRQ 19
[drm] nouveau 0000:01:00.0: Detected an NV30 generation card (0x436200a1)
[drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN
[drm] nouveau 0000:01:00.0: ... appears to be valid
[drm] nouveau 0000:01:00.0: BMP BIOS found
[drm] nouveau 0000:01:00.0: BMP version 5.40
[drm] nouveau 0000:01:00.0: Bios version 04.36.20.21
[drm] nouveau 0000:01:00.0: Found Display Configuration Block version 2.2
[drm] nouveau 0000:01:00.0: Raw DCB entry 0: 01000300 00009c40
[drm] nouveau 0000:01:00.0: Raw DCB entry 1: 02010310 00009c40
[drm] nouveau 0000:01:00.0: Raw DCB entry 2: 04000302 00000000
[drm] nouveau 0000:01:00.0: Raw DCB entry 3: 02020321 00000303
[drm] nouveau 0000:01:00.0: Loading NV17 power sequencing microcode
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xF01D
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xF4E1
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xF723
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xF896
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xF8B3
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 5 at offset 0xF8D0
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 6 at offset 0xF959
Apr 24 00:58:07 modprobe: FATAL: Could not open '/lib/modules/3.2.0-rc6-bisect-00190-g2a44e49-dirty/kernel/drivers/hwmon/lm90.ko': No such file or directory
[drm] nouveau 0000:01:00.0: 0 available performance level(s)
[drm] nouveau 0000:01:00.0: c: core 425MHz memory 501MHz voltage 1350mV
[TTM] Zone kernel: Available graphics memory: 1028502 kiB.
[TTM] Initializing pool allocator.
[TTM] Initializing DMA pool allocator.
[drm] nouveau 0000:01:00.0: Detected 256MiB VRAM
agpgart-amd64 0000:00:00.0: AGP 3.0 bridge
agpgart: swapper tried to set rate=x12. Setting to AGP3 x8 mode.
agpgart-amd64 0000:00:00.0: putting AGP V3 device into 8x mode
nouveau 0000:01:00.0: putting AGP V3 device into 8x mode
[drm] nouveau 0000:01:00.0: 64 MiB GART (aperture)
[drm] nouveau 0000:01:00.0: Saving VGA fonts
[drm] nouveau 0000:01:00.0: 0xE51A: Parsing digital output script table
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff811b7978>] nouveau_hw_load_state+0x1ffb/0x25b7
PGD 0
Oops: 0000 [#1] PREEMPT
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 3.2.0-rc6-bisect-00190-g2a44e49-dirty #72 ASUSTek Computer Inc. K8N-E-Deluxe/'K8N-E-Deluxe'
RIP: 0010:[<ffffffff811b7978>] [<ffffffff811b7978>] nouveau_hw_load_state+0x1ffb/0x25b7
RSP: 0018:ffff88007d05daa0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88007d1a5000 RCX: 0000000000000086
RDX: ffff88007c2129f8 RSI: ffffc90000680800 RDI: ffffc90000680800
RBP: ffff88007d05db20 R08: 00000000000c03c5 R09: ffff88007d0c0500
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88007c2129f8 R14: 0000000000000000 R15: 0000000000600800
FS: 0000000000000000(0000) GS:ffffffff8161c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000007d34b000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff88007d05c000, task ffff88007d050ac0)
Stack:
0000d52c0000d510 0000d56c0000d550 00000000006013d5 00000000006013d4
000000007d34fb38 00000000006013da 00000000006013c0 0000000000000000
ffff88007c212aa9 ffff88007c2129f8 ffff88007d05db20 ffff88007d35d000
Call Trace:
[<ffffffff8120a0d9>] nv_crtc_restore+0x7f/0x118
[<ffffffff8120c9d4>] nv04_display_init+0x61/0x7c
[<ffffffff811c4ce9>] nouveau_display_create+0x2ec/0x310
[<ffffffff811a6677>] nouveau_card_init+0x1386/0x1537
[<ffffffff811a6f17>] nouveau_load+0x60f/0x656
[<ffffffff8118f7b7>] drm_get_pci_dev+0x158/0x25d
[<ffffffff8130501e>] nouveau_pci_probe+0x10/0x12
[<ffffffff8111854b>] local_pci_probe+0x12/0x16
[<ffffffff811187b5>] pci_device_probe+0x65/0x96
[<ffffffff810dedf1>] ? sysfs_create_link+0xe/0x10
[<ffffffff81227bb9>] driver_probe_device+0xa3/0x131
[<ffffffff81227c9f>] __driver_attach+0x58/0x7c
[<ffffffff81227c47>] ? driver_probe_device+0x131/0x131
[<ffffffff81226eac>] bus_for_each_dev+0x51/0x7d
[<ffffffff812278bc>] driver_attach+0x19/0x1b
[<ffffffff81227548>] bus_add_driver+0xb2/0x206
[<ffffffff81227ff2>] driver_register+0x96/0x103
[<ffffffff81118a24>] __pci_register_driver+0x47/0xb3
[<ffffffff8118f941>] drm_pci_init+0x85/0xea
[<ffffffff8167c30f>] ? ttm_init+0x62/0x62
[<ffffffff8167c30f>] ? ttm_init+0x62/0x62
[<ffffffff8167c35e>] nouveau_init+0x4f/0x51
[<ffffffff810002e2>] do_one_initcall+0x78/0x126
[<ffffffff8165ab3a>] kernel_init+0x8b/0x10b
[<ffffffff81025bd9>] ? schedule_tail+0x16/0x3d
[<ffffffff81309dc4>] kernel_thread_helper+0x4/0x10
[<ffffffff8165aaaf>] ? start_kernel+0x31d/0x31d
[<ffffffff81309dc0>] ? gs_change+0xb/0xb
Code: 55 88 e8 b9 ef 14 00 44 8b 55 88 48 8b 83 f0 02 00 00 44 89 fe 44 89 d7 48 03 70 20 e8 e0 48 f5 ff 48 8b 83 10 02 00 00 45 31 d2
83 3c b0 00 41 0f 95 c2 41 83 fc 01 45 19 ff 41 81 e7 00 e0
RIP [<ffffffff811b7978>] nouveau_hw_load_state+0x1ffb/0x25b7
RSP <ffff88007d05daa0>
CR2: 0000000000000000
---[ end trace 6be61658f674fe9e ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G D 3.2.0-rc6-bisect-00190-g2a44e49-dirty #72
Call Trace:
[<ffffffff81306809>] panic+0x9a/0x19e
[<ffffffff8102c76b>] do_exit+0x8e/0x68c
[<ffffffff8102b0b7>] ? kmsg_dump+0xe5/0xf6
[<ffffffff8100487c>] oops_end+0x9d/0xa5
[<ffffffff8101c951>] no_context+0x1fd/0x20c
[<ffffffff8101cb10>] __bad_area_nosemaphore+0x1b0/0x1d0
[<ffffffff8101cb3e>] bad_area_nosemaphore+0xe/0x10
[<ffffffff8101ced9>] do_page_fault+0x173/0x36e
[<ffffffff811bc856>] ? init_idx_addr_latched+0x147/0x162
[<ffffffff811b9482>] ? parse_init_table+0xf3/0x1e6
[<ffffffff81308c5f>] page_fault+0x1f/0x30
[<ffffffff811b7978>] ? nouveau_hw_load_state+0x1ffb/0x25b7
[<ffffffff8120a0d9>] nv_crtc_restore+0x7f/0x118
[<ffffffff8120c9d4>] nv04_display_init+0x61/0x7c
[<ffffffff811c4ce9>] nouveau_display_create+0x2ec/0x310
[<ffffffff811a6677>] nouveau_card_init+0x1386/0x1537
[<ffffffff811a6f17>] nouveau_load+0x60f/0x656
[<ffffffff8118f7b7>] drm_get_pci_dev+0x158/0x25d
[<ffffffff8130501e>] nouveau_pci_probe+0x10/0x12
[<ffffffff8111854b>] local_pci_probe+0x12/0x16
[<ffffffff811187b5>] pci_device_probe+0x65/0x96
[<ffffffff810dedf1>] ? sysfs_create_link+0xe/0x10
[<ffffffff81227bb9>] driver_probe_device+0xa3/0x131
[<ffffffff81227c9f>] __driver_attach+0x58/0x7c
[<ffffffff81227c47>] ? driver_probe_device+0x131/0x131
[<ffffffff81226eac>] bus_for_each_dev+0x51/0x7d
[<ffffffff812278bc>] driver_attach+0x19/0x1b
[<ffffffff81227548>] bus_add_driver+0xb2/0x206
[<ffffffff81227ff2>] driver_register+0x96/0x103
[<ffffffff81118a24>] __pci_register_driver+0x47/0xb3
[<ffffffff8118f941>] drm_pci_init+0x85/0xea
[<ffffffff8167c30f>] ? ttm_init+0x62/0x62
[<ffffffff8167c30f>] ? ttm_init+0x62/0x62
[<ffffffff8167c35e>] nouveau_init+0x4f/0x51
[<ffffffff810002e2>] do_one_initcall+0x78/0x126
[<ffffffff8165ab3a>] kernel_init+0x8b/0x10b
[<ffffffff81025bd9>] ? schedule_tail+0x16/0x3d
[<ffffffff81309dc4>] kernel_thread_helper+0x4/0x10
[<ffffffff8165aaaf>] ? start_kernel+0x31d/0x31d
[<ffffffff81309dc0>] ? gs_change+0xb/0xb
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-24 1:03 ` Nick Bowler
@ 2012-04-24 15:11 ` Konrad Rzeszutek Wilk
2012-04-25 1:35 ` Nick Bowler
1 sibling, 0 replies; 30+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-04-24 15:11 UTC (permalink / raw)
To: Nick Bowler
Cc: Linus Torvalds, Martin Peres, Ben Skeggs, dri-devel,
Linux Kernel Mailing List
On Mon, Apr 23, 2012 at 09:03:45PM -0400, Nick Bowler wrote:
> On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
> > On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> > > Following up on the above, the commit which introduces the panics during
> > > boot is this one:
> > >
> > > commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> > > Author: Jerome Glisse <jglisse@redhat.com>
> > > Date: Wed Nov 9 17:15:26 2011 -0500
> > >
> > > drm/ttm: isolate dma data from ttm_tt V4
> >
> > I think
> >
> > dea7e0a ttm: fix agp since ttm tt rework
> >
> > fixed that.
>
> Yes, I just tested this commit and the one immediately before it. The
> one before crashes in the usual way, and dea7e0a boots (with the VGA
> output black as in the original report). So this fixed the crash.
>
> Now, returning to the original bisection, I marked that commit as "bad"
> and dropped all the earlier "skip" markings. Git asks me to test commit
> 2a44e4997c5f ("drm/nouveau/disp: introduce proper init/fini, separate
> from create/destroy"). I cherry picked the aforementioned ttm fix:
>
> git cherry-pick -n dea7e0a
>
> which succeeded. Howevew, the resulting kernel still crashes early,
> although now in a different way. I just can't win :(
Perhaps there is a better way. You could do this:
git log --oneline -r v3.2..v3.3 drivers/gpu/drm/nouveau
to get an idea of the set of patches that went in. And use that, so
git bisect start -- drivers/gpu/drm/nouveau [this should only do the bisection on those patches]
git bisect good v3.2
git bisect bad v3.3
And keep in mind the dea7e0a might need to be stuck on some of these.
This _should_ limit the bisection to just the nouveau changes, I hope.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-24 1:03 ` Nick Bowler
2012-04-24 15:11 ` Konrad Rzeszutek Wilk
@ 2012-04-25 1:35 ` Nick Bowler
2012-04-25 2:56 ` Ben Skeggs
1 sibling, 1 reply; 30+ messages in thread
From: Nick Bowler @ 2012-04-25 1:35 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Linus Torvalds, Martin Peres, Ben Skeggs, dri-devel,
Linux Kernel Mailing List
On 2012-04-23 21:03 -0400, Nick Bowler wrote:
> On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
> > On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> > > Following up on the above, the commit which introduces the panics during
> > > boot is this one:
> > >
> > > commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> > > Author: Jerome Glisse <jglisse@redhat.com>
> > > Date: Wed Nov 9 17:15:26 2011 -0500
> > >
> > > drm/ttm: isolate dma data from ttm_tt V4
[...]
> > dea7e0a ttm: fix agp since ttm tt rework
> >
> > fixed that.
>
> Yes, I just tested this commit and the one immediately before it. The
> one before crashes in the usual way, and dea7e0a boots (with the VGA
> output black as in the original report). So this fixed the crash.
OK, here's what I did:
- Since dea7e0a is the first commit that both (a) boots and (b) has
broken VGA, I checked it out on a new branch:
git checkout -b crazy dea7e0a
- Next, I reverted *all* (well, I missed one by accident) the remaining
nouveau-specific commits between 3230cfc34 ("drm/nouveau: enable the
ttm dma pool when swiotlb is active V3") (i.e., the last commit that
(a) boots and (b) has non-broken VGA) and dea7e0a:
git revert --no-edit 0c101461e267..f7b24c42da1a
- Amazingly, the resulting kernel booted and had working VGA, so I did
a "backwards" bisect on this branch of reverts. In a strange twist
of fate, this actually managed to produce bootable kernels the entire
time. The bisection pinpointed the following commit as the culprit:
commit a0b25635515ef5049f93b032a1e37f18b16e0f6f
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Mon Nov 21 16:41:48 2011 +1000
drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues
- moves out of nouveau_bios.c and demagics the logical state definitions
- simplifies chipset-specific driver interface
- makes most of gpio irq handling common, will use for nv4x hpd later
- api extended to allow both direct gpio access, and access using the
logical function states
- api extended to allow for future use of gpio extender chips
- pre-nv50 was handled very badly, the main issue being that all GPIOs
were being treated as output-only.
- fixes nvd0 so gpio changes actually stick, magic reg needs bashing
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Unfortunately, there are a number of seemingly non-trivial conflicts
trying to revert just this one gigantic commit. So to avoid any
conflicts, I reverted all of the following (in this order) on top of
3.3.3 (there are even more conflicts trying to revert on top of Linus'
master):
7df898b1a70b ("drm/nouveau/disp: check that panel power gpio is enabled at init time")
52c4d767437b ("drm/nouveau: move hpd enable/disable to common code")
47e5d5cb83d4 ("drm/nv40/disp: implement support for hotplug irq")
a0b25635515e ("drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues")
and my VGA is working again!
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-25 1:35 ` Nick Bowler
@ 2012-04-25 2:56 ` Ben Skeggs
2012-04-27 5:20 ` Ben Skeggs
0 siblings, 1 reply; 30+ messages in thread
From: Ben Skeggs @ 2012-04-25 2:56 UTC (permalink / raw)
To: Nick Bowler
Cc: Martin Peres, Linus Torvalds, Linux Kernel Mailing List,
dri-devel
On Tue, 2012-04-24 at 21:35 -0400, Nick Bowler wrote:
> On 2012-04-23 21:03 -0400, Nick Bowler wrote:
> > On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> > > > Following up on the above, the commit which introduces the panics during
> > > > boot is this one:
> > > >
> > > > commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> > > > Author: Jerome Glisse <jglisse@redhat.com>
> > > > Date: Wed Nov 9 17:15:26 2011 -0500
> > > >
> > > > drm/ttm: isolate dma data from ttm_tt V4
> [...]
> > > dea7e0a ttm: fix agp since ttm tt rework
> > >
> > > fixed that.
> >
> > Yes, I just tested this commit and the one immediately before it. The
> > one before crashes in the usual way, and dea7e0a boots (with the VGA
> > output black as in the original report). So this fixed the crash.
>
> OK, here's what I did:
>
> - Since dea7e0a is the first commit that both (a) boots and (b) has
> broken VGA, I checked it out on a new branch:
>
> git checkout -b crazy dea7e0a
>
> - Next, I reverted *all* (well, I missed one by accident) the remaining
> nouveau-specific commits between 3230cfc34 ("drm/nouveau: enable the
> ttm dma pool when swiotlb is active V3") (i.e., the last commit that
> (a) boots and (b) has non-broken VGA) and dea7e0a:
>
> git revert --no-edit 0c101461e267..f7b24c42da1a
>
> - Amazingly, the resulting kernel booted and had working VGA, so I did
> a "backwards" bisect on this branch of reverts. In a strange twist
> of fate, this actually managed to produce bootable kernels the entire
> time. The bisection pinpointed the following commit as the culprit:
>
> commit a0b25635515ef5049f93b032a1e37f18b16e0f6f
> Author: Ben Skeggs <bskeggs@redhat.com>
> Date: Mon Nov 21 16:41:48 2011 +1000
>
> drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues
>
> - moves out of nouveau_bios.c and demagics the logical state definitions
> - simplifies chipset-specific driver interface
> - makes most of gpio irq handling common, will use for nv4x hpd later
> - api extended to allow both direct gpio access, and access using the
> logical function states
> - api extended to allow for future use of gpio extender chips
> - pre-nv50 was handled very badly, the main issue being that all GPIOs
> were being treated as output-only.
> - fixes nvd0 so gpio changes actually stick, magic reg needs bashing
>
> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Excellent! That makes things possible.
Are you able to mount debugfs, and email /debugfs/dri/0/vbios.rom for me
(privately if you wish) and I'll attempt to track down what broke for
you.
Thanks!
Ben.
>
> Unfortunately, there are a number of seemingly non-trivial conflicts
> trying to revert just this one gigantic commit. So to avoid any
> conflicts, I reverted all of the following (in this order) on top of
> 3.3.3 (there are even more conflicts trying to revert on top of Linus'
> master):
>
> 7df898b1a70b ("drm/nouveau/disp: check that panel power gpio is enabled at init time")
> 52c4d767437b ("drm/nouveau: move hpd enable/disable to common code")
> 47e5d5cb83d4 ("drm/nv40/disp: implement support for hotplug irq")
> a0b25635515e ("drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues")
>
> and my VGA is working again!
>
> Cheers,
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-25 2:56 ` Ben Skeggs
@ 2012-04-27 5:20 ` Ben Skeggs
2012-04-28 0:39 ` Nick Bowler
0 siblings, 1 reply; 30+ messages in thread
From: Ben Skeggs @ 2012-04-27 5:20 UTC (permalink / raw)
To: Nick Bowler
Cc: Martin Peres, Linus Torvalds, Linux Kernel Mailing List,
dri-devel
On Wed, 2012-04-25 at 12:56 +1000, Ben Skeggs wrote:
> On Tue, 2012-04-24 at 21:35 -0400, Nick Bowler wrote:
> > On 2012-04-23 21:03 -0400, Nick Bowler wrote:
> > > On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> > > > > Following up on the above, the commit which introduces the panics during
> > > > > boot is this one:
> > > > >
> > > > > commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> > > > > Author: Jerome Glisse <jglisse@redhat.com>
> > > > > Date: Wed Nov 9 17:15:26 2011 -0500
> > > > >
> > > > > drm/ttm: isolate dma data from ttm_tt V4
> > [...]
> > > > dea7e0a ttm: fix agp since ttm tt rework
> > > >
> > > > fixed that.
> > >
> > > Yes, I just tested this commit and the one immediately before it. The
> > > one before crashes in the usual way, and dea7e0a boots (with the VGA
> > > output black as in the original report). So this fixed the crash.
> >
> > OK, here's what I did:
> >
> > - Since dea7e0a is the first commit that both (a) boots and (b) has
> > broken VGA, I checked it out on a new branch:
> >
> > git checkout -b crazy dea7e0a
> >
> > - Next, I reverted *all* (well, I missed one by accident) the remaining
> > nouveau-specific commits between 3230cfc34 ("drm/nouveau: enable the
> > ttm dma pool when swiotlb is active V3") (i.e., the last commit that
> > (a) boots and (b) has non-broken VGA) and dea7e0a:
> >
> > git revert --no-edit 0c101461e267..f7b24c42da1a
> >
> > - Amazingly, the resulting kernel booted and had working VGA, so I did
> > a "backwards" bisect on this branch of reverts. In a strange twist
> > of fate, this actually managed to produce bootable kernels the entire
> > time. The bisection pinpointed the following commit as the culprit:
> >
> > commit a0b25635515ef5049f93b032a1e37f18b16e0f6f
> > Author: Ben Skeggs <bskeggs@redhat.com>
> > Date: Mon Nov 21 16:41:48 2011 +1000
> >
> > drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues
> >
> > - moves out of nouveau_bios.c and demagics the logical state definitions
> > - simplifies chipset-specific driver interface
> > - makes most of gpio irq handling common, will use for nv4x hpd later
> > - api extended to allow both direct gpio access, and access using the
> > logical function states
> > - api extended to allow for future use of gpio extender chips
> > - pre-nv50 was handled very badly, the main issue being that all GPIOs
> > were being treated as output-only.
> > - fixes nvd0 so gpio changes actually stick, magic reg needs bashing
> >
> > Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
> Excellent! That makes things possible.
>
> Are you able to mount debugfs, and email /debugfs/dri/0/vbios.rom for me
> (privately if you wish) and I'll attempt to track down what broke for
> you.
Does this patch help you at all?
http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
Cheers,
Ben.
>
> Thanks!
> Ben.
>
> >
> > Unfortunately, there are a number of seemingly non-trivial conflicts
> > trying to revert just this one gigantic commit. So to avoid any
> > conflicts, I reverted all of the following (in this order) on top of
> > 3.3.3 (there are even more conflicts trying to revert on top of Linus'
> > master):
> >
> > 7df898b1a70b ("drm/nouveau/disp: check that panel power gpio is enabled at init time")
> > 52c4d767437b ("drm/nouveau: move hpd enable/disable to common code")
> > 47e5d5cb83d4 ("drm/nv40/disp: implement support for hotplug irq")
> > a0b25635515e ("drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues")
> >
> > and my VGA is working again!
> >
> > Cheers,
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-27 5:20 ` Ben Skeggs
@ 2012-04-28 0:39 ` Nick Bowler
2012-04-28 6:19 ` Alex Deucher
0 siblings, 1 reply; 30+ messages in thread
From: Nick Bowler @ 2012-04-28 0:39 UTC (permalink / raw)
To: Ben Skeggs
Cc: Martin Peres, Linus Torvalds, Linux Kernel Mailing List,
dri-devel
Hi Ben,
On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
> Does this patch help you at all?
>
> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
Yes. I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
this appears to solve the "black screen on VGA" problem described in the
original report. Thanks!
Unfortunately, that's not the end of my VGA-related regressions. :(
While tracking down the black screen issue, I've been having the monitor
directly connected to the video card the whole time, but now when I'm
connected through my KVM switch (an IOGear GCS1804), it appears that
something's going wrong with reading the EDID, because the available
modes are all screwed up (both console and X decide they want to drive
the display at 1024x768). Here's the output of xrandr on 3.2.15:
% xrandr
Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 352mm x 264mm
1600x1200 75.0*+ 70.0 65.0 60.0
1280x1024 85.0 + 75.0 60.0
1920x1440 60.0
1856x1392 60.0
1792x1344 60.0
1920x1200 74.9 59.9
1680x1050 84.9 74.9 60.0
1400x1050 85.0 74.9 60.0
1440x900 84.8 75.0 59.9
1280x960 85.0 60.0
1360x768 60.0
1280x800 84.9 74.9 59.8
1152x864 75.0
1280x768 84.8 74.9 59.9
1024x768 85.0 75.1 75.0 70.1 60.0 43.5 43.5
832x624 74.6
800x600 85.1 72.2 75.0 60.3 56.2
848x480 60.0
640x480 85.0 75.0 72.8 72.8 66.7 60.0 59.9
720x400 85.0 87.8 70.1
640x400 85.1
640x350 85.1
320x200 165.1
And on 3.4-rc4+ (with your patch cherry-picked):
% xrandr
Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1024x768 60.0*
800x600 60.3 56.2
848x480 60.0
640x480 59.9
320x200 165.1
Running xrandr on 3.4-rc4+ also causes the screen to go black for a
second when it does not on 3.2.15. It also causes several messages of
the form
[drm] nouveau 0000:01:00.0: Load detected on output B
to be logged. Also, looking at /sys/class/drm/card0-VGA-1/edid I see
that it is empty on 3.4-rc4+ and it is correct on 3.2.15. Things seem
to work OK when the KVM is not involved.
This is probably caused by a different commit than the black screen
because I also saw this problem on the 3.3.3+reverts kernel; I just
haven't noticed it until now because, well, the VGA wasn't working at
all until now.
Anyway, I can try to track down what causes this one next week...
Thanks,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-28 0:39 ` Nick Bowler
@ 2012-04-28 6:19 ` Alex Deucher
2012-04-28 15:33 ` Nick Bowler
0 siblings, 1 reply; 30+ messages in thread
From: Alex Deucher @ 2012-04-28 6:19 UTC (permalink / raw)
To: Nick Bowler
Cc: Ben Skeggs, Martin Peres, Linus Torvalds,
Linux Kernel Mailing List, dri-devel
On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
> Hi Ben,
>
> On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
>> Does this patch help you at all?
>>
>> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
>
> Yes. I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
> this appears to solve the "black screen on VGA" problem described in the
> original report. Thanks!
>
> Unfortunately, that's not the end of my VGA-related regressions. :(
>
> While tracking down the black screen issue, I've been having the monitor
> directly connected to the video card the whole time, but now when I'm
> connected through my KVM switch (an IOGear GCS1804), it appears that
> something's going wrong with reading the EDID, because the available
> modes are all screwed up (both console and X decide they want to drive
> the display at 1024x768). Here's the output of xrandr on 3.2.15:
>
> % xrandr
> Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
> VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 352mm x 264mm
> 1600x1200 75.0*+ 70.0 65.0 60.0
> 1280x1024 85.0 + 75.0 60.0
> 1920x1440 60.0
> 1856x1392 60.0
> 1792x1344 60.0
> 1920x1200 74.9 59.9
> 1680x1050 84.9 74.9 60.0
> 1400x1050 85.0 74.9 60.0
> 1440x900 84.8 75.0 59.9
> 1280x960 85.0 60.0
> 1360x768 60.0
> 1280x800 84.9 74.9 59.8
> 1152x864 75.0
> 1280x768 84.8 74.9 59.9
> 1024x768 85.0 75.1 75.0 70.1 60.0 43.5 43.5
> 832x624 74.6
> 800x600 85.1 72.2 75.0 60.3 56.2
> 848x480 60.0
> 640x480 85.0 75.0 72.8 72.8 66.7 60.0 59.9
> 720x400 85.0 87.8 70.1
> 640x400 85.1
> 640x350 85.1
> 320x200 165.1
>
> And on 3.4-rc4+ (with your patch cherry-picked):
>
> % xrandr
> Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
> VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
> 1024x768 60.0*
> 800x600 60.3 56.2
> 848x480 60.0
> 640x480 59.9
> 320x200 165.1
>
> Running xrandr on 3.4-rc4+ also causes the screen to go black for a
> second when it does not on 3.2.15. It also causes several messages of
> the form
>
> [drm] nouveau 0000:01:00.0: Load detected on output B
>
> to be logged. Also, looking at /sys/class/drm/card0-VGA-1/edid I see
> that it is empty on 3.4-rc4+ and it is correct on 3.2.15. Things seem
> to work OK when the KVM is not involved.
Were you ever able to fetch a EDID with the KVM involved? KVMs are
notorious for not connecting the ddc pins.
Alex
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-28 6:19 ` Alex Deucher
@ 2012-04-28 15:33 ` Nick Bowler
2012-04-29 22:37 ` Dmitry Torokhov
0 siblings, 1 reply; 30+ messages in thread
From: Nick Bowler @ 2012-04-28 15:33 UTC (permalink / raw)
To: Alex Deucher
Cc: Linus Torvalds, Martin Peres, Linux Kernel Mailing List,
dri-devel
On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
> > Hi Ben,
> >
> > On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
> >> Does this patch help you at all?
> >>
> >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
> >
> > Yes. I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
> > this appears to solve the "black screen on VGA" problem described in the
> > original report. Thanks!
> >
> > Unfortunately, that's not the end of my VGA-related regressions. :(
> >
> > While tracking down the black screen issue, I've been having the monitor
> > directly connected to the video card the whole time, but now when I'm
> > connected through my KVM switch (an IOGear GCS1804), it appears that
> > something's going wrong with reading the EDID, because the available
> > modes are all screwed up (both console and X decide they want to drive
> > the display at 1024x768). Here's the output of xrandr on 3.2.15:
> >
> > % xrandr
> > Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
> > VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 352mm x 264mm
> > 1600x1200 75.0*+ 70.0 65.0 60.0
> > 1280x1024 85.0 + 75.0 60.0
> > 1920x1440 60.0
> > 1856x1392 60.0
> > 1792x1344 60.0
> > 1920x1200 74.9 59.9
> > 1680x1050 84.9 74.9 60.0
> > 1400x1050 85.0 74.9 60.0
> > 1440x900 84.8 75.0 59.9
> > 1280x960 85.0 60.0
> > 1360x768 60.0
> > 1280x800 84.9 74.9 59.8
> > 1152x864 75.0
> > 1280x768 84.8 74.9 59.9
> > 1024x768 85.0 75.1 75.0 70.1 60.0 43.5 43.5
> > 832x624 74.6
> > 800x600 85.1 72.2 75.0 60.3 56.2
> > 848x480 60.0
> > 640x480 85.0 75.0 72.8 72.8 66.7 60.0 59.9
> > 720x400 85.0 87.8 70.1
> > 640x400 85.1
> > 640x350 85.1
> > 320x200 165.1
> >
> > And on 3.4-rc4+ (with your patch cherry-picked):
> >
> > % xrandr
> > Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
> > VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
> > 1024x768 60.0*
> > 800x600 60.3 56.2
> > 848x480 60.0
> > 640x480 59.9
> > 320x200 165.1
> >
> > Running xrandr on 3.4-rc4+ also causes the screen to go black for a
> > second when it does not on 3.2.15. It also causes several messages of
> > the form
> >
> > [drm] nouveau 0000:01:00.0: Load detected on output B
> >
> > to be logged. Also, looking at /sys/class/drm/card0-VGA-1/edid I see
> > that it is empty on 3.4-rc4+ and it is correct on 3.2.15. Things seem
> > to work OK when the KVM is not involved.
>
> Were you ever able to fetch a EDID with the KVM involved? KVMs are
> notorious for not connecting the ddc pins.
Yes, it works on 3.2.15 as described above.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-28 15:33 ` Nick Bowler
@ 2012-04-29 22:37 ` Dmitry Torokhov
2012-04-30 9:07 ` Maarten Maathuis
0 siblings, 1 reply; 30+ messages in thread
From: Dmitry Torokhov @ 2012-04-29 22:37 UTC (permalink / raw)
To: Nick Bowler
Cc: Alex Deucher, Ben Skeggs, Martin Peres, Linus Torvalds,
Linux Kernel Mailing List, dri-devel
On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
> > > Hi Ben,
> > >
> > > On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
> > >> Does this patch help you at all?
> > >>
> > >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
> > >
> > > Yes. I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
> > > this appears to solve the "black screen on VGA" problem described in the
> > > original report. Thanks!
> > >
> > > Unfortunately, that's not the end of my VGA-related regressions. :(
> > >
> > > While tracking down the black screen issue, I've been having the monitor
> > > directly connected to the video card the whole time, but now when I'm
> > > connected through my KVM switch (an IOGear GCS1804), it appears that
> > > something's going wrong with reading the EDID, because the available
> > > modes are all screwed up (both console and X decide they want to drive
> > > the display at 1024x768). Here's the output of xrandr on 3.2.15:
> > >
> > > % xrandr
> > > Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
> > > VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 352mm x 264mm
> > > 1600x1200 75.0*+ 70.0 65.0 60.0
> > > 1280x1024 85.0 + 75.0 60.0
> > > 1920x1440 60.0
> > > 1856x1392 60.0
> > > 1792x1344 60.0
> > > 1920x1200 74.9 59.9
> > > 1680x1050 84.9 74.9 60.0
> > > 1400x1050 85.0 74.9 60.0
> > > 1440x900 84.8 75.0 59.9
> > > 1280x960 85.0 60.0
> > > 1360x768 60.0
> > > 1280x800 84.9 74.9 59.8
> > > 1152x864 75.0
> > > 1280x768 84.8 74.9 59.9
> > > 1024x768 85.0 75.1 75.0 70.1 60.0 43.5 43.5
> > > 832x624 74.6
> > > 800x600 85.1 72.2 75.0 60.3 56.2
> > > 848x480 60.0
> > > 640x480 85.0 75.0 72.8 72.8 66.7 60.0 59.9
> > > 720x400 85.0 87.8 70.1
> > > 640x400 85.1
> > > 640x350 85.1
> > > 320x200 165.1
> > >
> > > And on 3.4-rc4+ (with your patch cherry-picked):
> > >
> > > % xrandr
> > > Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
> > > VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
> > > 1024x768 60.0*
> > > 800x600 60.3 56.2
> > > 848x480 60.0
> > > 640x480 59.9
> > > 320x200 165.1
> > >
> > > Running xrandr on 3.4-rc4+ also causes the screen to go black for a
> > > second when it does not on 3.2.15. It also causes several messages of
> > > the form
> > >
> > > [drm] nouveau 0000:01:00.0: Load detected on output B
> > >
> > > to be logged. Also, looking at /sys/class/drm/card0-VGA-1/edid I see
> > > that it is empty on 3.4-rc4+ and it is correct on 3.2.15. Things seem
> > > to work OK when the KVM is not involved.
> >
> > Were you ever able to fetch a EDID with the KVM involved? KVMs are
> > notorious for not connecting the ddc pins.
>
> Yes, it works on 3.2.15 as described above.
I have the same (or similar) KVM (not in the office at the moment) and I
can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
if EDED retrieval succeeds or if it fails with:
Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.317063] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
Earlier kernels were able to retrieve EDEDs reliably.
This is with:
[ 1.678392] [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x086b00a2)
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-29 22:37 ` Dmitry Torokhov
@ 2012-04-30 9:07 ` Maarten Maathuis
2012-04-30 11:01 ` Luca Tettamanti
2012-05-01 13:23 ` Nick Bowler
0 siblings, 2 replies; 30+ messages in thread
From: Maarten Maathuis @ 2012-04-30 9:07 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Nick Bowler, Martin Peres, Linux Kernel Mailing List, dri-devel,
Linus Torvalds
On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
>> > > Hi Ben,
>> > >
>> > > On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
>> > >> Does this patch help you at all?
>> > >>
>> > >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
>> > >
>> > > Yes. I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
>> > > this appears to solve the "black screen on VGA" problem described in the
>> > > original report. Thanks!
>> > >
>> > > Unfortunately, that's not the end of my VGA-related regressions. :(
>> > >
>> > > While tracking down the black screen issue, I've been having the monitor
>> > > directly connected to the video card the whole time, but now when I'm
>> > > connected through my KVM switch (an IOGear GCS1804), it appears that
>> > > something's going wrong with reading the EDID, because the available
>> > > modes are all screwed up (both console and X decide they want to drive
>> > > the display at 1024x768). Here's the output of xrandr on 3.2.15:
>> > >
>> > > % xrandr
>> > > Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
>> > > VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 352mm x 264mm
>> > > 1600x1200 75.0*+ 70.0 65.0 60.0
>> > > 1280x1024 85.0 + 75.0 60.0
>> > > 1920x1440 60.0
>> > > 1856x1392 60.0
>> > > 1792x1344 60.0
>> > > 1920x1200 74.9 59.9
>> > > 1680x1050 84.9 74.9 60.0
>> > > 1400x1050 85.0 74.9 60.0
>> > > 1440x900 84.8 75.0 59.9
>> > > 1280x960 85.0 60.0
>> > > 1360x768 60.0
>> > > 1280x800 84.9 74.9 59.8
>> > > 1152x864 75.0
>> > > 1280x768 84.8 74.9 59.9
>> > > 1024x768 85.0 75.1 75.0 70.1 60.0 43.5 43.5
>> > > 832x624 74.6
>> > > 800x600 85.1 72.2 75.0 60.3 56.2
>> > > 848x480 60.0
>> > > 640x480 85.0 75.0 72.8 72.8 66.7 60.0 59.9
>> > > 720x400 85.0 87.8 70.1
>> > > 640x400 85.1
>> > > 640x350 85.1
>> > > 320x200 165.1
>> > >
>> > > And on 3.4-rc4+ (with your patch cherry-picked):
>> > >
>> > > % xrandr
>> > > Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
>> > > VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
>> > > 1024x768 60.0*
>> > > 800x600 60.3 56.2
>> > > 848x480 60.0
>> > > 640x480 59.9
>> > > 320x200 165.1
>> > >
>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black for a
>> > > second when it does not on 3.2.15. It also causes several messages of
>> > > the form
>> > >
>> > > [drm] nouveau 0000:01:00.0: Load detected on output B
>> > >
>> > > to be logged. Also, looking at /sys/class/drm/card0-VGA-1/edid I see
>> > > that it is empty on 3.4-rc4+ and it is correct on 3.2.15. Things seem
>> > > to work OK when the KVM is not involved.
>> >
>> > Were you ever able to fetch a EDID with the KVM involved? KVMs are
>> > notorious for not connecting the ddc pins.
>>
>> Yes, it works on 3.2.15 as described above.
>
> I have the same (or similar) KVM (not in the office at the moment) and I
> can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
> if EDED retrieval succeeds or if it fails with:
>
> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
> Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
> Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.317063] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
>
> Earlier kernels were able to retrieve EDEDs reliably.
>
> This is with:
>
> [ 1.678392] [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x086b00a2)
>
> Thanks.
>
> --
> Dmitry
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Just a crazy thought, but didn't we change some timings related to
EDID retrieval? To make it faster.
--
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-30 9:07 ` Maarten Maathuis
@ 2012-04-30 11:01 ` Luca Tettamanti
2012-05-02 7:54 ` Jean Delvare
2012-05-01 13:23 ` Nick Bowler
1 sibling, 1 reply; 30+ messages in thread
From: Luca Tettamanti @ 2012-04-30 11:01 UTC (permalink / raw)
To: Maarten Maathuis
Cc: Nick Bowler, Martin Peres, Dmitry Torokhov,
Linux Kernel Mailing List, dri-devel, Linus Torvalds,
Jean Delvare
On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis <madman2003@gmail.com> wrote:
> On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
>>> > > Hi Ben,
>>> > >
>>> > > On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
>>> > >> Does this patch help you at all?
>>> > >>
>>> > >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
>>> > >
>>> > > Yes. I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
>>> > > this appears to solve the "black screen on VGA" problem described in the
>>> > > original report. Thanks!
>>> > >
>>> > > Unfortunately, that's not the end of my VGA-related regressions. :(
>>> > >
>>> > > While tracking down the black screen issue, I've been having the monitor
>>> > > directly connected to the video card the whole time, but now when I'm
>>> > > connected through my KVM switch (an IOGear GCS1804), it appears that
>>> > > something's going wrong with reading the EDID, because the available
>>> > > modes are all screwed up (both console and X decide they want to drive
>>> > > the display at 1024x768). Here's the output of xrandr on 3.2.15:
>>> > >
>>> > > % xrandr
>>> > > Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
>>> > > VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 352mm x 264mm
>>> > > 1600x1200 75.0*+ 70.0 65.0 60.0
>>> > > 1280x1024 85.0 + 75.0 60.0
>>> > > 1920x1440 60.0
>>> > > 1856x1392 60.0
>>> > > 1792x1344 60.0
>>> > > 1920x1200 74.9 59.9
>>> > > 1680x1050 84.9 74.9 60.0
>>> > > 1400x1050 85.0 74.9 60.0
>>> > > 1440x900 84.8 75.0 59.9
>>> > > 1280x960 85.0 60.0
>>> > > 1360x768 60.0
>>> > > 1280x800 84.9 74.9 59.8
>>> > > 1152x864 75.0
>>> > > 1280x768 84.8 74.9 59.9
>>> > > 1024x768 85.0 75.1 75.0 70.1 60.0 43.5 43.5
>>> > > 832x624 74.6
>>> > > 800x600 85.1 72.2 75.0 60.3 56.2
>>> > > 848x480 60.0
>>> > > 640x480 85.0 75.0 72.8 72.8 66.7 60.0 59.9
>>> > > 720x400 85.0 87.8 70.1
>>> > > 640x400 85.1
>>> > > 640x350 85.1
>>> > > 320x200 165.1
>>> > >
>>> > > And on 3.4-rc4+ (with your patch cherry-picked):
>>> > >
>>> > > % xrandr
>>> > > Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
>>> > > VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
>>> > > 1024x768 60.0*
>>> > > 800x600 60.3 56.2
>>> > > 848x480 60.0
>>> > > 640x480 59.9
>>> > > 320x200 165.1
>>> > >
>>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black for a
>>> > > second when it does not on 3.2.15. It also causes several messages of
>>> > > the form
>>> > >
>>> > > [drm] nouveau 0000:01:00.0: Load detected on output B
>>> > >
>>> > > to be logged. Also, looking at /sys/class/drm/card0-VGA-1/edid I see
>>> > > that it is empty on 3.4-rc4+ and it is correct on 3.2.15. Things seem
>>> > > to work OK when the KVM is not involved.
>>> >
>>> > Were you ever able to fetch a EDID with the KVM involved? KVMs are
>>> > notorious for not connecting the ddc pins.
>>>
>>> Yes, it works on 3.2.15 as described above.
>>
>> I have the same (or similar) KVM (not in the office at the moment) and I
>> can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
>> if EDED retrieval succeeds or if it fails with:
>>
>> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.317063] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
>>
>> Earlier kernels were able to retrieve EDEDs reliably.
>>
>> This is with:
>>
>> [ 1.678392] [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x086b00a2)
>
> Just a crazy thought, but didn't we change some timings related to
> EDID retrieval? To make it faster.
Hum, this commit:
commit 1849ecb22fb3b5d57b65e7369a3957adf9f26f39
Author: Jean Delvare <jdelvare@suse.de>
Date: Sat Jan 28 11:07:09 2012 +0100
drm/kms: Make i2c buses faster
doubled the data rate but only for radeon and intel drivers. nouveau
doesn't use the standard i2c-algo-bit helpers (BTW: the cond_resched()
has been removed), and AFAICS it's using 1us delay; the other drivers
are using 10us, 1us seems a bit too low...
Luca
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-30 9:07 ` Maarten Maathuis
2012-04-30 11:01 ` Luca Tettamanti
@ 2012-05-01 13:23 ` Nick Bowler
2012-05-01 15:09 ` Alan Cox
2012-05-02 1:20 ` Nick Bowler
1 sibling, 2 replies; 30+ messages in thread
From: Nick Bowler @ 2012-05-01 13:23 UTC (permalink / raw)
To: Maarten Maathuis
Cc: Dmitry Torokhov, Martin Peres, Linux Kernel Mailing List,
dri-devel, Linus Torvalds
On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
> On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> >> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> >> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
> >> > > While tracking down the black screen issue, I've been having the monitor
> >> > > directly connected to the video card the whole time, but now when I'm
> >> > > connected through my KVM switch (an IOGear GCS1804), it appears that
> >> > > something's going wrong with reading the EDID, because the available
> >> > > modes are all screwed up (both console and X decide they want to drive
> >> > > the display at 1024x768).
[...]
> >> > > Also, looking at /sys/class/drm/card0-VGA-1/edid I see that it
> >> > > is empty on 3.4-rc4+ and it is correct on 3.2.15. Things seem
> >> > > to work OK when the KVM is not involved.
> >> >
> >> > Were you ever able to fetch a EDID with the KVM involved? KVMs are
> >> > notorious for not connecting the ddc pins.
> >>
> >> Yes, it works on 3.2.15 as described above.
> >
> > I have the same (or similar) KVM (not in the office at the moment) and I
> > can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
> > if EDED retrieval succeeds or if it fails with:
> >
> > Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
[...]
> > Earlier kernels were able to retrieve EDEDs reliably.
FWIW, for me EDID failure on new kernels is 100% reproducible, and there
are no such checksum errors in the log. It's just missing.
> Just a crazy thought, but didn't we change some timings related to
> EDID retrieval? To make it faster.
OK, this time bisecting started off relatively smoothly (doing the same
"backwards" bisect on the branch-o-reverts as last time), but then my
disk died halfway through... So I'll post the partial bisection results
now (11 commits left to test), but I clearly have other things to fix
before I can get back to this issue.
git bisect start 'drivers/gpu/drm'
# good: [9232969e19ae7251a93ab72e405cf71e5109ec05] drm/nv40/pm: implement first type of pwm fanspeed funcs
git bisect good 9232969e19ae7251a93ab72e405cf71e5109ec05
# bad: [dea7e0ac45fd28f90bbc38ff226d36a9f788efbf] ttm: fix agp since ttm tt rework
git bisect bad dea7e0ac45fd28f90bbc38ff226d36a9f788efbf
# good: [d2491567cdbcb87b2682e0948a69d73c4dd8987e] drm/nv50/pm: only touch 0x611200 on nv92-
git bisect good d2491567cdbcb87b2682e0948a69d73c4dd8987e
# good: [f9f9f536312d4c3ca39502ccf6a3af60cfe38ff4] drm/nouveau/bios: pass drm_device to ROMPTR, rather than nvbios
git bisect good f9f9f536312d4c3ca39502ccf6a3af60cfe38ff4
# bad: [d4c2c99bdc8385a0e51ce4ef2df124d14b6b9c9d] drm/nouveau/dp: remove broken display depth function, use the improved one
git bisect bad d4c2c99bdc8385a0e51ce4ef2df124d14b6b9c9d
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-05-01 13:23 ` Nick Bowler
@ 2012-05-01 15:09 ` Alan Cox
2012-05-01 15:31 ` Nick Bowler
2012-05-02 1:20 ` Nick Bowler
1 sibling, 1 reply; 30+ messages in thread
From: Alan Cox @ 2012-05-01 15:09 UTC (permalink / raw)
To: Nick Bowler
Cc: Martin Peres, Dmitry Torokhov, Kernel Mailing List, dri-devel,
Linux, Linus Torvalds
> OK, this time bisecting started off relatively smoothly (doing the same
> "backwards" bisect on the branch-o-reverts as last time), but then my
> disk died halfway through... So I'll post the partial bisection results
> now (11 commits left to test), but I clearly have other things to fix
> before I can get back to this issue.
You may get stupid answers because of
commit eeefa4bea1af34207c5299f989fffe03628ea164
commit 8353e6c632aeaea1470a286b83e68ca233073068
Been there, trying to chase down a GMA500 problemt that was muddled in
with the broken edid.h patch as well as a driver bug.
Alan
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-05-01 15:09 ` Alan Cox
@ 2012-05-01 15:31 ` Nick Bowler
2012-05-01 15:45 ` Alan Cox
0 siblings, 1 reply; 30+ messages in thread
From: Nick Bowler @ 2012-05-01 15:31 UTC (permalink / raw)
To: Alan Cox
Cc: Martin Peres, Dmitry Torokhov, Linux Kernel Mailing List,
dri-devel, Linus Torvalds
On 2012-05-01 16:09 +0100, Alan Cox wrote:
> > OK, this time bisecting started off relatively smoothly (doing the same
> > "backwards" bisect on the branch-o-reverts as last time), but then my
> > disk died halfway through... So I'll post the partial bisection results
> > now (11 commits left to test), but I clearly have other things to fix
> > before I can get back to this issue.
>
> You may get stupid answers because of
>
> commit eeefa4bea1af34207c5299f989fffe03628ea164
> commit 8353e6c632aeaea1470a286b83e68ca233073068
>
> Been there, trying to chase down a GMA500 problemt that was muddled in
> with the broken edid.h patch as well as a driver bug.
I'm afraid I don't understand. These commits do not appear to be in
Linus' tree?
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-05-01 15:31 ` Nick Bowler
@ 2012-05-01 15:45 ` Alan Cox
0 siblings, 0 replies; 30+ messages in thread
From: Alan Cox @ 2012-05-01 15:45 UTC (permalink / raw)
To: Nick Bowler
Cc: Maarten Maathuis, Dmitry Torokhov, Martin Peres,
Linux Kernel Mailing List, dri-devel, Linus Torvalds
On Tue, 1 May 2012 11:31:23 -0400
Nick Bowler <nbowler@elliptictech.com> wrote:
> On 2012-05-01 16:09 +0100, Alan Cox wrote:
> > > OK, this time bisecting started off relatively smoothly (doing the same
> > > "backwards" bisect on the branch-o-reverts as last time), but then my
> > > disk died halfway through... So I'll post the partial bisection results
> > > now (11 commits left to test), but I clearly have other things to fix
> > > before I can get back to this issue.
> >
> > You may get stupid answers because of
> >
> > commit eeefa4bea1af34207c5299f989fffe03628ea164
> > commit 8353e6c632aeaea1470a286b83e68ca233073068
> >
> > Been there, trying to chase down a GMA500 problemt that was muddled in
> > with the broken edid.h patch as well as a driver bug.
>
> I'm afraid I don't understand. These commits do not appear to be in
Ok they only got as far as the DRM tree - thats good, so you ought to get
a sane answer.
Alan
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-05-01 13:23 ` Nick Bowler
2012-05-01 15:09 ` Alan Cox
@ 2012-05-02 1:20 ` Nick Bowler
2012-05-04 9:20 ` Dave Airlie
1 sibling, 1 reply; 30+ messages in thread
From: Nick Bowler @ 2012-05-02 1:20 UTC (permalink / raw)
To: Maarten Maathuis
Cc: Martin Peres, Dmitry Torokhov, Linux Kernel Mailing List,
dri-devel, Ben Skeggs, Linus Torvalds
(re-adding Ben to the Cc because he was apparently dropped somewhere in
this thread)
On 2012-05-01 09:23 -0400, Nick Bowler wrote:
> On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
> > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > > On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> > >> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> > >> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
> > >> > > While tracking down the black screen issue, I've been having the monitor
> > >> > > directly connected to the video card the whole time, but now when I'm
> > >> > > connected through my KVM switch (an IOGear GCS1804), it appears that
> > >> > > something's going wrong with reading the EDID, because the available
> > >> > > modes are all screwed up (both console and X decide they want to drive
> > >> > > the display at 1024x768).
> [...]
> > >> > > Also, looking at /sys/class/drm/card0-VGA-1/edid I see that it
> > >> > > is empty on 3.4-rc4+ and it is correct on 3.2.15. Things seem
> > >> > > to work OK when the KVM is not involved.
> > >> >
> > >> > Were you ever able to fetch a EDID with the KVM involved? KVMs are
> > >> > notorious for not connecting the ddc pins.
> > >>
> > >> Yes, it works on 3.2.15 as described above.
> > >
> > > I have the same (or similar) KVM (not in the office at the moment) and I
> > > can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
> > > if EDED retrieval succeeds or if it fails with:
> > >
> > > Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
> [...]
> > > Earlier kernels were able to retrieve EDEDs reliably.
>
> FWIW, for me EDID failure on new kernels is 100% reproducible, and there
> are no such checksum errors in the log. It's just missing.
>
> > Just a crazy thought, but didn't we change some timings related to
> > EDID retrieval? To make it faster.
>
> OK, this time bisecting started off relatively smoothly (doing the same
> "backwards" bisect on the branch-o-reverts as last time), but then my
> disk died halfway through...
[...]
OK, system is back online and I finished the bisection. The commit that
broke it for me is the following, and reverting it on top of 3.3.4 + the
"make VGA work at all" patch fixes this particular issue for me.
commit f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Wed Dec 21 18:09:12 2011 +1000
drm/nouveau/i2c: handle bit-banging ourselves
i2c-algo-bit doesn't actually work very well on one card I have access to
(NVS 300), random single-bit errors occur most of the time - what we're
doing now is closer to what xf86i2c.c does.
The original plan was to figure out why i2c-algo-bit fails on the NVS 300,
and fix it. However, while investigating I discovered i2c-algo-bit calls
cond_resched(), which makes it a bad idea for us to be using as we execute
VBIOS scripts from a tasklet, and there may very well be i2c transfers as
a result.
So, since I already wrote this code in userspace to track down the NVS 300
bug, and it's not really much code - lets use it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-04-30 11:01 ` Luca Tettamanti
@ 2012-05-02 7:54 ` Jean Delvare
2012-05-02 11:31 ` Ben Skeggs
0 siblings, 1 reply; 30+ messages in thread
From: Jean Delvare @ 2012-05-02 7:54 UTC (permalink / raw)
To: Luca Tettamanti
Cc: Maarten Maathuis, Dmitry Torokhov, Nick Bowler, Martin Peres,
Linus Torvalds, Linux Kernel Mailing List, dri-devel, Ben Skeggs
Hi Luca, Maarten,
On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis <madman2003@gmail.com> wrote:
> > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> >
> > <dmitry.torokhov@gmail.com> wrote:
> >> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> >>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> >>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
> >>> > > Unfortunately, that's not the end of my VGA-related
> >>> > > regressions. :(
> >>> > >
> >>> > > While tracking down the black screen issue, I've been having
> >>> > > the monitor directly connected to the video card the whole
> >>> > > time, but now when I'm connected through my KVM switch (an
> >>> > > IOGear GCS1804), it appears that something's going wrong with
> >>> > > reading the EDID, because the available modes are all screwed
> >>> > > up (both console and X decide they want to drive the display
> >>> > > at 1024x768). Here's the output of xrandr on 3.2.15:
> >>> > >
> >>> > > % xrandr
> >>> > > Screen 1: minimum 320 x 200, current 1600 x 1200, maximum
> >>> > > 4096 x 4096 VGA-1 connected 1600x1200+0+0 (normal left
> >>> > > inverted right x axis y axis) 352mm x 264mm
> >>> > > 1600x1200 75.0*+ 70.0 65.0 60.0
> >>> > > 1280x1024 85.0 + 75.0 60.0
> >>> > > 1920x1440 60.0
> >>> > > 1856x1392 60.0
> >>> > > 1792x1344 60.0
> >>> > > 1920x1200 74.9 59.9
> >>> > > 1680x1050 84.9 74.9 60.0
> >>> > > 1400x1050 85.0 74.9 60.0
> >>> > > 1440x900 84.8 75.0 59.9
> >>> > > 1280x960 85.0 60.0
> >>> > > 1360x768 60.0
> >>> > > 1280x800 84.9 74.9 59.8
> >>> > > 1152x864 75.0
> >>> > > 1280x768 84.8 74.9 59.9
> >>> > > 1024x768 85.0 75.1 75.0 70.1 60.0 43.5 43.5
> >>> > > 832x624 74.6
> >>> > > 800x600 85.1 72.2 75.0 60.3 56.2
> >>> > > 848x480 60.0
> >>> > > 640x480 85.0 75.0 72.8 72.8 66.7 60.0 59.9
> >>> > > 720x400 85.0 87.8 70.1
> >>> > > 640x400 85.1
> >>> > > 640x350 85.1
> >>> > > 320x200 165.1
> >>> > >
> >>> > > And on 3.4-rc4+ (with your patch cherry-picked):
> >>> > >
> >>> > > % xrandr
> >>> > > Screen 1: minimum 320 x 200, current 1024 x 768, maximum
> >>> > > 4096 x 4096 VGA-1 connected 1024x768+0+0 (normal left
> >>> > > inverted right x axis y axis) 0mm x 0mm
> >>> > > 1024x768 60.0*
> >>> > > 800x600 60.3 56.2
> >>> > > 848x480 60.0
> >>> > > 640x480 59.9
> >>> > > 320x200 165.1
> >>> > >
> >>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black
> >>> > > for a second when it does not on 3.2.15. It also causes
> >>> > > several messages of the form
> >>> > >
> >>> > > [drm] nouveau 0000:01:00.0: Load detected on output B
> >>> > >
> >>> > > to be logged. Also, looking at
> >>> > > /sys/class/drm/card0-VGA-1/edid I see that it is empty on
> >>> > > 3.4-rc4+ and it is correct on 3.2.15. Things seem to work OK
> >>> > > when the KVM is not involved.
> >>> >
> >>> > Were you ever able to fetch a EDID with the KVM involved? KVMs
> >>> > are notorious for not connecting the ddc pins.
> >>>
> >>> Yes, it works on 3.2.15 as described above.
> >>
> >> I have the same (or similar) KVM (not in the office at the moment)
> >> and I can confirm that with newer kernels EDID fecthing in flaky.
> >> It's 50/50 if EDED retrieval succeeds or if it fails with:
> >>
> >> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208
> >>
> >> Earlier kernels were able to retrieve EDEDs reliably.
> >>
> >> This is with:
> >>
> >> [ 1.678392] [drm] nouveau 0000:01:00.0: Detected an NV50
> >> generation card (0x086b00a2)
> >
> > Just a crazy thought, but didn't we change some timings related to
> > EDID retrieval? To make it faster.
>
> Hum, this commit:
>
> commit 1849ecb22fb3b5d57b65e7369a3957adf9f26f39
> Author: Jean Delvare <jdelvare@suse.de>
> Date: Sat Jan 28 11:07:09 2012 +0100
>
> drm/kms: Make i2c buses faster
>
> doubled the data rate but only for radeon and intel drivers. nouveau
> doesn't use the standard i2c-algo-bit helpers (BTW: the
> cond_resched() has been removed), and AFAICS it's using 1us delay;
> the other drivers are using 10us, 1us seems a bit too low...
As I read the code, it is actually using a 6 us delay. This is fast
but reasonable, especially when the code handles clock stretching
Ben Skeggs (Cc'd) rewrote the I2C handling code in the nouveau
driver completely in kernel 3.3:
commit f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Wed Dec 21 18:09:12 2011 +1000
drm/nouveau/i2c: handle bit-banging ourselves
i2c-algo-bit doesn't actually work very well on one card I have access to
(NVS 300), random single-bit errors occur most of the time - what we're
doing now is closer to what xf86i2c.c does.
The original plan was to figure out why i2c-algo-bit fails on the NVS 300,
and fix it. However, while investigating I discovered i2c-algo-bit calls
cond_resched(), which makes it a bad idea for us to be using as we execute
VBIOS scripts from a tasklet, and there may very well be i2c transfers as
a result.
So, since I already wrote this code in userspace to track down the NVS 300
bug, and it's not really much code - lets use it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
So if the regression happened between 3.2.15 and 3.4-rc4, that would be
a good candidate.
BTW, Ben, there were two interesting fixes to i2c-algo-bit meanwhile,
you may want to try using it again.
Maarten, another commit you may want to try reverting is
9292f37e1f5c79400254dca46f83313488093825 . If none of the above works,
it would be great if you could test your KVM with another graphics
adapter, so that we know if we are looking for a nouveau-specific bug
or rather an issue in the common i2c or edid code. Otherwise a plain
bisection is probably the way to go.
--
Jean Delvare
Suse L3
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-05-02 7:54 ` Jean Delvare
@ 2012-05-02 11:31 ` Ben Skeggs
2012-05-04 5:08 ` Ben Skeggs
0 siblings, 1 reply; 30+ messages in thread
From: Ben Skeggs @ 2012-05-02 11:31 UTC (permalink / raw)
To: Jean Delvare
Cc: Luca Tettamanti, Maarten Maathuis, Dmitry Torokhov, Nick Bowler,
Martin Peres, Linus Torvalds, Linux Kernel Mailing List,
dri-devel
On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
> Hi Luca, Maarten,
>
> On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> > On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis <madman2003@gmail.com> wrote:
> > > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> > >
> > > <dmitry.torokhov@gmail.com> wrote:
> > >> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> > >>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> > >>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
> > >>> > > Unfortunately, that's not the end of my VGA-related
> > >>> > > regressions. :(
> > >>> > >
> > >>> > > While tracking down the black screen issue, I've been having
> > >>> > > the monitor directly connected to the video card the whole
> > >>> > > time, but now when I'm connected through my KVM switch (an
> > >>> > > IOGear GCS1804), it appears that something's going wrong with
> > >>> > > reading the EDID, because the available modes are all screwed
> > >>> > > up (both console and X decide they want to drive the display
> > >>> > > at 1024x768). Here's the output of xrandr on 3.2.15:
> > >>> > >
> > >>> > > % xrandr
> > >>> > > Screen 1: minimum 320 x 200, current 1600 x 1200, maximum
> > >>> > > 4096 x 4096 VGA-1 connected 1600x1200+0+0 (normal left
> > >>> > > inverted right x axis y axis) 352mm x 264mm
> > >>> > > 1600x1200 75.0*+ 70.0 65.0 60.0
> > >>> > > 1280x1024 85.0 + 75.0 60.0
> > >>> > > 1920x1440 60.0
> > >>> > > 1856x1392 60.0
> > >>> > > 1792x1344 60.0
> > >>> > > 1920x1200 74.9 59.9
> > >>> > > 1680x1050 84.9 74.9 60.0
> > >>> > > 1400x1050 85.0 74.9 60.0
> > >>> > > 1440x900 84.8 75.0 59.9
> > >>> > > 1280x960 85.0 60.0
> > >>> > > 1360x768 60.0
> > >>> > > 1280x800 84.9 74.9 59.8
> > >>> > > 1152x864 75.0
> > >>> > > 1280x768 84.8 74.9 59.9
> > >>> > > 1024x768 85.0 75.1 75.0 70.1 60.0 43.5 43.5
> > >>> > > 832x624 74.6
> > >>> > > 800x600 85.1 72.2 75.0 60.3 56.2
> > >>> > > 848x480 60.0
> > >>> > > 640x480 85.0 75.0 72.8 72.8 66.7 60.0 59.9
> > >>> > > 720x400 85.0 87.8 70.1
> > >>> > > 640x400 85.1
> > >>> > > 640x350 85.1
> > >>> > > 320x200 165.1
> > >>> > >
> > >>> > > And on 3.4-rc4+ (with your patch cherry-picked):
> > >>> > >
> > >>> > > % xrandr
> > >>> > > Screen 1: minimum 320 x 200, current 1024 x 768, maximum
> > >>> > > 4096 x 4096 VGA-1 connected 1024x768+0+0 (normal left
> > >>> > > inverted right x axis y axis) 0mm x 0mm
> > >>> > > 1024x768 60.0*
> > >>> > > 800x600 60.3 56.2
> > >>> > > 848x480 60.0
> > >>> > > 640x480 59.9
> > >>> > > 320x200 165.1
> > >>> > >
> > >>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black
> > >>> > > for a second when it does not on 3.2.15. It also causes
> > >>> > > several messages of the form
> > >>> > >
> > >>> > > [drm] nouveau 0000:01:00.0: Load detected on output B
> > >>> > >
> > >>> > > to be logged. Also, looking at
> > >>> > > /sys/class/drm/card0-VGA-1/edid I see that it is empty on
> > >>> > > 3.4-rc4+ and it is correct on 3.2.15. Things seem to work OK
> > >>> > > when the KVM is not involved.
> > >>> >
> > >>> > Were you ever able to fetch a EDID with the KVM involved? KVMs
> > >>> > are notorious for not connecting the ddc pins.
> > >>>
> > >>> Yes, it works on 3.2.15 as described above.
> > >>
> > >> I have the same (or similar) KVM (not in the office at the moment)
> > >> and I can confirm that with newer kernels EDID fecthing in flaky.
> > >> It's 50/50 if EDED retrieval succeeds or if it fails with:
> > >>
> > >> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208
> > >>
> > >> Earlier kernels were able to retrieve EDEDs reliably.
> > >>
> > >> This is with:
> > >>
> > >> [ 1.678392] [drm] nouveau 0000:01:00.0: Detected an NV50
> > >> generation card (0x086b00a2)
> > >
> > > Just a crazy thought, but didn't we change some timings related to
> > > EDID retrieval? To make it faster.
> >
> > Hum, this commit:
> >
> > commit 1849ecb22fb3b5d57b65e7369a3957adf9f26f39
> > Author: Jean Delvare <jdelvare@suse.de>
> > Date: Sat Jan 28 11:07:09 2012 +0100
> >
> > drm/kms: Make i2c buses faster
> >
> > doubled the data rate but only for radeon and intel drivers. nouveau
> > doesn't use the standard i2c-algo-bit helpers (BTW: the
> > cond_resched() has been removed), and AFAICS it's using 1us delay;
> > the other drivers are using 10us, 1us seems a bit too low...
>
> As I read the code, it is actually using a 6 us delay. This is fast
> but reasonable, especially when the code handles clock stretching
>
> Ben Skeggs (Cc'd) rewrote the I2C handling code in the nouveau
> driver completely in kernel 3.3:
>
> commit f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d
> Author: Ben Skeggs <bskeggs@redhat.com>
> Date: Wed Dec 21 18:09:12 2011 +1000
>
> drm/nouveau/i2c: handle bit-banging ourselves
>
> i2c-algo-bit doesn't actually work very well on one card I have access to
> (NVS 300), random single-bit errors occur most of the time - what we're
> doing now is closer to what xf86i2c.c does.
>
> The original plan was to figure out why i2c-algo-bit fails on the NVS 300,
> and fix it. However, while investigating I discovered i2c-algo-bit calls
> cond_resched(), which makes it a bad idea for us to be using as we execute
> VBIOS scripts from a tasklet, and there may very well be i2c transfers as
> a result.
>
> So, since I already wrote this code in userspace to track down the NVS 300
> bug, and it's not really much code - lets use it.
>
> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>
> So if the regression happened between 3.2.15 and 3.4-rc4, that would be
> a good candidate.
>
> BTW, Ben, there were two interesting fixes to i2c-algo-bit meanwhile,
> you may want to try using it again.
Hey Jean,
Thanks! I did notice this, and your email, a while back. I just
haven't yet had the time to see how the NVS300 goes now. I do
definitely plan on taking a peek however.
Ben.
>
> Maarten, another commit you may want to try reverting is
> 9292f37e1f5c79400254dca46f83313488093825 . If none of the above works,
> it would be great if you could test your KVM with another graphics
> adapter, so that we know if we are looking for a nouveau-specific bug
> or rather an issue in the common i2c or edid code. Otherwise a plain
> bisection is probably the way to go.
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-05-02 11:31 ` Ben Skeggs
@ 2012-05-04 5:08 ` Ben Skeggs
2012-05-04 14:12 ` Jean Delvare
0 siblings, 1 reply; 30+ messages in thread
From: Ben Skeggs @ 2012-05-04 5:08 UTC (permalink / raw)
To: Jean Delvare
Cc: Bowler, Martin Peres, Dmitry Torokhov, Linux Kernel Mailing List,
dri-devel, Linus Torvalds, Nick
On Wed, 2012-05-02 at 21:31 +1000, Ben Skeggs wrote:
> On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
> > Hi Luca, Maarten,
> >
> > On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> > > On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis <madman2003@gmail.com> wrote:
> > > > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> > > >
> > > > <dmitry.torokhov@gmail.com> wrote:
> > > >> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> > > >>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> > > >>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@elliptictech.com> wrote:
> > > >>> > > Unfortunately, that's not the end of my VGA-related
> > > >>> > > regressions. :(
> > > >>> > >
> > > >>> > > While tracking down the black screen issue, I've been having
> > > >>> > > the monitor directly connected to the video card the whole
> > > >>> > > time, but now when I'm connected through my KVM switch (an
> > > >>> > > IOGear GCS1804), it appears that something's going wrong with
> > > >>> > > reading the EDID, because the available modes are all screwed
> > > >>> > > up (both console and X decide they want to drive the display
> > > >>> > > at 1024x768). Here's the output of xrandr on 3.2.15:
> > > >>> > >
> > > >>> > > % xrandr
> > > >>> > > Screen 1: minimum 320 x 200, current 1600 x 1200, maximum
> > > >>> > > 4096 x 4096 VGA-1 connected 1600x1200+0+0 (normal left
> > > >>> > > inverted right x axis y axis) 352mm x 264mm
> > > >>> > > 1600x1200 75.0*+ 70.0 65.0 60.0
> > > >>> > > 1280x1024 85.0 + 75.0 60.0
> > > >>> > > 1920x1440 60.0
> > > >>> > > 1856x1392 60.0
> > > >>> > > 1792x1344 60.0
> > > >>> > > 1920x1200 74.9 59.9
> > > >>> > > 1680x1050 84.9 74.9 60.0
> > > >>> > > 1400x1050 85.0 74.9 60.0
> > > >>> > > 1440x900 84.8 75.0 59.9
> > > >>> > > 1280x960 85.0 60.0
> > > >>> > > 1360x768 60.0
> > > >>> > > 1280x800 84.9 74.9 59.8
> > > >>> > > 1152x864 75.0
> > > >>> > > 1280x768 84.8 74.9 59.9
> > > >>> > > 1024x768 85.0 75.1 75.0 70.1 60.0 43.5 43.5
> > > >>> > > 832x624 74.6
> > > >>> > > 800x600 85.1 72.2 75.0 60.3 56.2
> > > >>> > > 848x480 60.0
> > > >>> > > 640x480 85.0 75.0 72.8 72.8 66.7 60.0 59.9
> > > >>> > > 720x400 85.0 87.8 70.1
> > > >>> > > 640x400 85.1
> > > >>> > > 640x350 85.1
> > > >>> > > 320x200 165.1
> > > >>> > >
> > > >>> > > And on 3.4-rc4+ (with your patch cherry-picked):
> > > >>> > >
> > > >>> > > % xrandr
> > > >>> > > Screen 1: minimum 320 x 200, current 1024 x 768, maximum
> > > >>> > > 4096 x 4096 VGA-1 connected 1024x768+0+0 (normal left
> > > >>> > > inverted right x axis y axis) 0mm x 0mm
> > > >>> > > 1024x768 60.0*
> > > >>> > > 800x600 60.3 56.2
> > > >>> > > 848x480 60.0
> > > >>> > > 640x480 59.9
> > > >>> > > 320x200 165.1
> > > >>> > >
> > > >>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black
> > > >>> > > for a second when it does not on 3.2.15. It also causes
> > > >>> > > several messages of the form
> > > >>> > >
> > > >>> > > [drm] nouveau 0000:01:00.0: Load detected on output B
> > > >>> > >
> > > >>> > > to be logged. Also, looking at
> > > >>> > > /sys/class/drm/card0-VGA-1/edid I see that it is empty on
> > > >>> > > 3.4-rc4+ and it is correct on 3.2.15. Things seem to work OK
> > > >>> > > when the KVM is not involved.
> > > >>> >
> > > >>> > Were you ever able to fetch a EDID with the KVM involved? KVMs
> > > >>> > are notorious for not connecting the ddc pins.
> > > >>>
> > > >>> Yes, it works on 3.2.15 as described above.
> > > >>
> > > >> I have the same (or similar) KVM (not in the office at the moment)
> > > >> and I can confirm that with newer kernels EDID fecthing in flaky.
> > > >> It's 50/50 if EDED retrieval succeeds or if it fails with:
> > > >>
> > > >> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208
> > > >>
> > > >> Earlier kernels were able to retrieve EDEDs reliably.
> > > >>
> > > >> This is with:
> > > >>
> > > >> [ 1.678392] [drm] nouveau 0000:01:00.0: Detected an NV50
> > > >> generation card (0x086b00a2)
> > > >
> > > > Just a crazy thought, but didn't we change some timings related to
> > > > EDID retrieval? To make it faster.
> > >
> > > Hum, this commit:
> > >
> > > commit 1849ecb22fb3b5d57b65e7369a3957adf9f26f39
> > > Author: Jean Delvare <jdelvare@suse.de>
> > > Date: Sat Jan 28 11:07:09 2012 +0100
> > >
> > > drm/kms: Make i2c buses faster
> > >
> > > doubled the data rate but only for radeon and intel drivers. nouveau
> > > doesn't use the standard i2c-algo-bit helpers (BTW: the
> > > cond_resched() has been removed), and AFAICS it's using 1us delay;
> > > the other drivers are using 10us, 1us seems a bit too low...
> >
> > As I read the code, it is actually using a 6 us delay. This is fast
> > but reasonable, especially when the code handles clock stretching
> >
> > Ben Skeggs (Cc'd) rewrote the I2C handling code in the nouveau
> > driver completely in kernel 3.3:
> >
> > commit f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d
> > Author: Ben Skeggs <bskeggs@redhat.com>
> > Date: Wed Dec 21 18:09:12 2011 +1000
> >
> > drm/nouveau/i2c: handle bit-banging ourselves
> >
> > i2c-algo-bit doesn't actually work very well on one card I have access to
> > (NVS 300), random single-bit errors occur most of the time - what we're
> > doing now is closer to what xf86i2c.c does.
> >
> > The original plan was to figure out why i2c-algo-bit fails on the NVS 300,
> > and fix it. However, while investigating I discovered i2c-algo-bit calls
> > cond_resched(), which makes it a bad idea for us to be using as we execute
> > VBIOS scripts from a tasklet, and there may very well be i2c transfers as
> > a result.
> >
> > So, since I already wrote this code in userspace to track down the NVS 300
> > bug, and it's not really much code - lets use it.
> >
> > Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
> >
> > So if the regression happened between 3.2.15 and 3.4-rc4, that would be
> > a good candidate.
> >
> > BTW, Ben, there were two interesting fixes to i2c-algo-bit meanwhile,
> > you may want to try using it again.
> Hey Jean,
>
> Thanks! I did notice this, and your email, a while back. I just
> haven't yet had the time to see how the NVS300 goes now. I do
> definitely plan on taking a peek however.
I had the NVS300 in today for some other work so I took the chance to
see how it went now. The good news is, i2c-algo-bit works with it now
\o/
I've got a patch ready removing our custom implementation, and it'll be
in nouveau git later today.
Thanks a heap for the heads up, and for fixing my issues with
i2c-algo-bit!
Ben.
>
> Ben.
>
> >
> > Maarten, another commit you may want to try reverting is
> > 9292f37e1f5c79400254dca46f83313488093825 . If none of the above works,
> > it would be great if you could test your KVM with another graphics
> > adapter, so that we know if we are looking for a nouveau-specific bug
> > or rather an issue in the common i2c or edid code. Otherwise a plain
> > bisection is probably the way to go.
> >
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-05-02 1:20 ` Nick Bowler
@ 2012-05-04 9:20 ` Dave Airlie
2012-05-05 15:39 ` Nick Bowler
0 siblings, 1 reply; 30+ messages in thread
From: Dave Airlie @ 2012-05-04 9:20 UTC (permalink / raw)
To: Nick Bowler
Cc: Martin Peres, Dmitry Torokhov, Linux Kernel Mailing List,
dri-devel, Ben Skeggs, Linus Torvalds
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
>>
>> FWIW, for me EDID failure on new kernels is 100% reproducible, and there
>> are no such checksum errors in the log. It's just missing.
>>
>> > Just a crazy thought, but didn't we change some timings related to
>> > EDID retrieval? To make it faster.
>>
>> OK, this time bisecting started off relatively smoothly (doing the same
>> "backwards" bisect on the branch-o-reverts as last time), but then my
>> disk died halfway through...
> [...]
>
> OK, system is back online and I finished the bisection. The commit that
> broke it for me is the following, and reverting it on top of 3.3.4 + the
> "make VGA work at all" patch fixes this particular issue for me.
>
Can you test with the attached patch? its a revert mostly of Ben's patch, and
he says with the i2c core change stuff is working for him again.
Dave.
[-- Attachment #2: 0001-drm-nouveau-i2c-resume-use-of-i2c-algo-bit-rather-th.patch --]
[-- Type: application/octet-stream, Size: 6615 bytes --]
From 281a02ece2245254f415172306a8577dca96eda3 Mon Sep 17 00:00:00 2001
From: Ben Skeggs <bskeggs@redhat.com>
Date: Fri, 4 May 2012 14:38:49 +1000
Subject: [PATCH] drm/nouveau/i2c: resume use of i2c-algo-bit, rather than
custom stack
Previous issues with i2c-algo-bit have now been resolved.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
---
drivers/gpu/drm/nouveau/nouveau_i2c.c | 199 ++++-----------------------------
drivers/gpu/drm/nouveau/nouveau_i2c.h | 1 +
2 files changed, 22 insertions(+), 178 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_i2c.c b/drivers/gpu/drm/nouveau/nouveau_i2c.c
index e2be95a..77e5646 100644
--- a/drivers/gpu/drm/nouveau/nouveau_i2c.c
+++ b/drivers/gpu/drm/nouveau/nouveau_i2c.c
@@ -29,10 +29,6 @@
#include "nouveau_i2c.h"
#include "nouveau_hw.h"
-#define T_TIMEOUT 2200000
-#define T_RISEFALL 1000
-#define T_HOLD 5000
-
static void
i2c_drive_scl(void *data, int state)
{
@@ -113,175 +109,6 @@ i2c_sense_sda(void *data)
return 0;
}
-static void
-i2c_delay(struct nouveau_i2c_chan *port, u32 nsec)
-{
- udelay((nsec + 500) / 1000);
-}
-
-static bool
-i2c_raise_scl(struct nouveau_i2c_chan *port)
-{
- u32 timeout = T_TIMEOUT / T_RISEFALL;
-
- i2c_drive_scl(port, 1);
- do {
- i2c_delay(port, T_RISEFALL);
- } while (!i2c_sense_scl(port) && --timeout);
-
- return timeout != 0;
-}
-
-static int
-i2c_start(struct nouveau_i2c_chan *port)
-{
- int ret = 0;
-
- port->state = i2c_sense_scl(port);
- port->state |= i2c_sense_sda(port) << 1;
- if (port->state != 3) {
- i2c_drive_scl(port, 0);
- i2c_drive_sda(port, 1);
- if (!i2c_raise_scl(port))
- ret = -EBUSY;
- }
-
- i2c_drive_sda(port, 0);
- i2c_delay(port, T_HOLD);
- i2c_drive_scl(port, 0);
- i2c_delay(port, T_HOLD);
- return ret;
-}
-
-static void
-i2c_stop(struct nouveau_i2c_chan *port)
-{
- i2c_drive_scl(port, 0);
- i2c_drive_sda(port, 0);
- i2c_delay(port, T_RISEFALL);
-
- i2c_drive_scl(port, 1);
- i2c_delay(port, T_HOLD);
- i2c_drive_sda(port, 1);
- i2c_delay(port, T_HOLD);
-}
-
-static int
-i2c_bitw(struct nouveau_i2c_chan *port, int sda)
-{
- i2c_drive_sda(port, sda);
- i2c_delay(port, T_RISEFALL);
-
- if (!i2c_raise_scl(port))
- return -ETIMEDOUT;
- i2c_delay(port, T_HOLD);
-
- i2c_drive_scl(port, 0);
- i2c_delay(port, T_HOLD);
- return 0;
-}
-
-static int
-i2c_bitr(struct nouveau_i2c_chan *port)
-{
- int sda;
-
- i2c_drive_sda(port, 1);
- i2c_delay(port, T_RISEFALL);
-
- if (!i2c_raise_scl(port))
- return -ETIMEDOUT;
- i2c_delay(port, T_HOLD);
-
- sda = i2c_sense_sda(port);
-
- i2c_drive_scl(port, 0);
- i2c_delay(port, T_HOLD);
- return sda;
-}
-
-static int
-i2c_get_byte(struct nouveau_i2c_chan *port, u8 *byte, bool last)
-{
- int i, bit;
-
- *byte = 0;
- for (i = 7; i >= 0; i--) {
- bit = i2c_bitr(port);
- if (bit < 0)
- return bit;
- *byte |= bit << i;
- }
-
- return i2c_bitw(port, last ? 1 : 0);
-}
-
-static int
-i2c_put_byte(struct nouveau_i2c_chan *port, u8 byte)
-{
- int i, ret;
- for (i = 7; i >= 0; i--) {
- ret = i2c_bitw(port, !!(byte & (1 << i)));
- if (ret < 0)
- return ret;
- }
-
- ret = i2c_bitr(port);
- if (ret == 1) /* nack */
- ret = -EIO;
- return ret;
-}
-
-static int
-i2c_addr(struct nouveau_i2c_chan *port, struct i2c_msg *msg)
-{
- u32 addr = msg->addr << 1;
- if (msg->flags & I2C_M_RD)
- addr |= 1;
- return i2c_put_byte(port, addr);
-}
-
-static int
-i2c_bit_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
-{
- struct nouveau_i2c_chan *port = (struct nouveau_i2c_chan *)adap;
- struct i2c_msg *msg = msgs;
- int ret = 0, mcnt = num;
-
- while (!ret && mcnt--) {
- u8 remaining = msg->len;
- u8 *ptr = msg->buf;
-
- ret = i2c_start(port);
- if (ret == 0)
- ret = i2c_addr(port, msg);
-
- if (msg->flags & I2C_M_RD) {
- while (!ret && remaining--)
- ret = i2c_get_byte(port, ptr++, !remaining);
- } else {
- while (!ret && remaining--)
- ret = i2c_put_byte(port, *ptr++);
- }
-
- msg++;
- }
-
- i2c_stop(port);
- return (ret < 0) ? ret : num;
-}
-
-static u32
-i2c_bit_func(struct i2c_adapter *adap)
-{
- return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
-}
-
-const struct i2c_algorithm nouveau_i2c_bit_algo = {
- .master_xfer = i2c_bit_xfer,
- .functionality = i2c_bit_func
-};
-
static const uint32_t nv50_i2c_port[] = {
0x00e138, 0x00e150, 0x00e168, 0x00e180,
0x00e254, 0x00e274, 0x00e764, 0x00e780,
@@ -384,12 +211,10 @@ nouveau_i2c_init(struct drm_device *dev)
case 0: /* NV04:NV50 */
port->drive = entry[0];
port->sense = entry[1];
- port->adapter.algo = &nouveau_i2c_bit_algo;
break;
case 4: /* NV4E */
port->drive = 0x600800 + entry[1];
port->sense = port->drive;
- port->adapter.algo = &nouveau_i2c_bit_algo;
break;
case 5: /* NV50- */
port->drive = entry[0] & 0x0f;
@@ -402,7 +227,6 @@ nouveau_i2c_init(struct drm_device *dev)
port->drive = 0x00d014 + (port->drive * 0x20);
port->sense = port->drive;
}
- port->adapter.algo = &nouveau_i2c_bit_algo;
break;
case 6: /* NV50- DP AUX */
port->drive = entry[0];
@@ -413,7 +237,7 @@ nouveau_i2c_init(struct drm_device *dev)
break;
}
- if (!port->adapter.algo) {
+ if (!port->adapter.algo && !port->drive) {
NV_ERROR(dev, "I2C%d: type %d index %x/%x unknown\n",
i, port->type, port->drive, port->sense);
kfree(port);
@@ -429,7 +253,26 @@ nouveau_i2c_init(struct drm_device *dev)
port->dcb = ROM32(entry[0]);
i2c_set_adapdata(&port->adapter, i2c);
- ret = i2c_add_adapter(&port->adapter);
+ if (port->adapter.algo != &nouveau_dp_i2c_algo) {
+ port->adapter.algo_data = &port->bit;
+ port->bit.udelay = 10;
+ port->bit.timeout = usecs_to_jiffies(2200);
+ port->bit.data = port;
+ port->bit.setsda = i2c_drive_sda;
+ port->bit.setscl = i2c_drive_scl;
+ port->bit.getsda = i2c_sense_sda;
+ port->bit.getscl = i2c_sense_scl;
+
+ i2c_drive_scl(port, 0);
+ i2c_drive_sda(port, 1);
+ i2c_drive_scl(port, 1);
+
+ ret = i2c_bit_add_bus(&port->adapter);
+ } else {
+ port->adapter.algo = &nouveau_dp_i2c_algo;
+ ret = i2c_add_adapter(&port->adapter);
+ }
+
if (ret) {
NV_ERROR(dev, "I2C%d: failed register: %d\n", i, ret);
kfree(port);
diff --git a/drivers/gpu/drm/nouveau/nouveau_i2c.h b/drivers/gpu/drm/nouveau/nouveau_i2c.h
index 4d2e4e9..1d08389 100644
--- a/drivers/gpu/drm/nouveau/nouveau_i2c.h
+++ b/drivers/gpu/drm/nouveau/nouveau_i2c.h
@@ -34,6 +34,7 @@
struct nouveau_i2c_chan {
struct i2c_adapter adapter;
struct drm_device *dev;
+ struct i2c_algo_bit_data bit;
struct list_head head;
u8 index;
u8 type;
--
1.7.7.6
[-- Attachment #3: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-05-04 5:08 ` Ben Skeggs
@ 2012-05-04 14:12 ` Jean Delvare
0 siblings, 0 replies; 30+ messages in thread
From: Jean Delvare @ 2012-05-04 14:12 UTC (permalink / raw)
To: skeggsb
Cc: Bowler, Dmitry Torokhov, Linux Kernel Mailing List, dri-devel,
Nick, Martin Peres, Linus Torvalds
(Testing new e-mail client at work, please forgive and bear with me if
anything goes wrong.)
On ven., 2012-05-04 at 15:08 +1000, Ben Skeggs wrote:
> On Wed, 2012-05-02 at 21:31 +1000, Ben Skeggs wrote:
> > On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
> > > BTW, Ben, there were two interesting fixes to i2c-algo-bit meanwhile,
> > > you may want to try using it again.
> > Hey Jean,
> >
> > Thanks! I did notice this, and your email, a while back. I just
> > haven't yet had the time to see how the NVS300 goes now. I do
> > definitely plan on taking a peek however.
> I had the NVS300 in today for some other work so I took the chance to
> see how it went now. The good news is, i2c-algo-bit works with it now
> \o/
>
> I've got a patch ready removing our custom implementation, and it'll be
> in nouveau git later today.
This is good news. Maybe it will even fix Maarten's issue.
> Thanks a heap for the heads up, and for fixing my issues with
> i2c-algo-bit!
All the praise should go to Ville Syrjälä, he spotted the 10 year old
bug and fixed it. Great timing too :)
--
Jean Delvare
Suse L3
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Linux 3.4-rc4
2012-05-04 9:20 ` Dave Airlie
@ 2012-05-05 15:39 ` Nick Bowler
0 siblings, 0 replies; 30+ messages in thread
From: Nick Bowler @ 2012-05-05 15:39 UTC (permalink / raw)
To: Dave Airlie
Cc: Maarten Maathuis, Martin Peres, Dmitry Torokhov,
Linux Kernel Mailing List, dri-devel, Ben Skeggs, Linus Torvalds
On 2012-05-04 10:20 +0100, Dave Airlie wrote:
> >>
> >> FWIW, for me EDID failure on new kernels is 100% reproducible, and there
> >> are no such checksum errors in the log. It's just missing.
> >>
> >> > Just a crazy thought, but didn't we change some timings related to
> >> > EDID retrieval? To make it faster.
> >>
> >> OK, this time bisecting started off relatively smoothly (doing the same
> >> "backwards" bisect on the branch-o-reverts as last time), but then my
> >> disk died halfway through...
> > [...]
> >
> > OK, system is back online and I finished the bisection. The commit that
> > broke it for me is the following, and reverting it on top of 3.3.4 + the
> > "make VGA work at all" patch fixes this particular issue for me.
> >
> Can you test with the attached patch? its a revert mostly of Ben's patch, and
> he says with the i2c core change stuff is working for him again.
Yup, this one seems to work on top of Linus' master.
Thanks,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2012-05-05 15:39 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CA+55aFzQD4UyPVDQesrWq7JkM=BoQevdJpQt1YyaG10MtfM-Pw@mail.gmail.com>
[not found] ` <20120422040715.GA30689@elliptictech.com>
2012-04-22 4:51 ` Linux 3.4-rc4 Linus Torvalds
2012-04-22 7:26 ` Dave Airlie
2012-04-22 16:42 ` Nick Bowler
2012-04-23 3:16 ` Ben Skeggs
2012-04-22 16:40 ` Nick Bowler
2012-04-22 18:20 ` Geert Uytterhoeven
2012-04-23 0:05 ` Nick Bowler
2012-04-23 2:45 ` Konrad Rzeszutek Wilk
2012-04-24 1:03 ` Nick Bowler
2012-04-24 15:11 ` Konrad Rzeszutek Wilk
2012-04-25 1:35 ` Nick Bowler
2012-04-25 2:56 ` Ben Skeggs
2012-04-27 5:20 ` Ben Skeggs
2012-04-28 0:39 ` Nick Bowler
2012-04-28 6:19 ` Alex Deucher
2012-04-28 15:33 ` Nick Bowler
2012-04-29 22:37 ` Dmitry Torokhov
2012-04-30 9:07 ` Maarten Maathuis
2012-04-30 11:01 ` Luca Tettamanti
2012-05-02 7:54 ` Jean Delvare
2012-05-02 11:31 ` Ben Skeggs
2012-05-04 5:08 ` Ben Skeggs
2012-05-04 14:12 ` Jean Delvare
2012-05-01 13:23 ` Nick Bowler
2012-05-01 15:09 ` Alan Cox
2012-05-01 15:31 ` Nick Bowler
2012-05-01 15:45 ` Alan Cox
2012-05-02 1:20 ` Nick Bowler
2012-05-04 9:20 ` Dave Airlie
2012-05-05 15:39 ` Nick Bowler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox