linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux 3.4-rc4
@ 2012-04-21 22:43 Linus Torvalds
  2012-04-22  4:07 ` Nick Bowler
  2012-04-22  8:38 ` Bjarke Istrup Pedersen
  0 siblings, 2 replies; 33+ messages in thread
From: Linus Torvalds @ 2012-04-21 22:43 UTC (permalink / raw)
  To: Linux Kernel Mailing List

Things looked fairly calm for a while, but that certainly changed
yesterday. I think either people time their pulls for the -rc releases
too, or it's just a matter of many developers actually having a
somewhat normal Mon-Fri workweek these days and they close the week by
sending my their pull request. Regardless of why, it meant that my
"oh, things are really calming down nicely" state on Thursday changed
to "Uhhuh, not quite yet" on Friday - when more than half the commits
for this whole -rc release came in.

Oh well.

That said, even with the uptick on Friday, I do think things have been
fairly calm. We've got a few reverts and a few cleanups, but the bulk
of it is trivial small fixes. Almost all of it in drivers with a few
filesystem updates (many of them endianness fixes from Al) thrown in
too. The traditional (non-rename) diff is dominated by a m68k bootlogo
movement, but we all use those nice git diffs these days, don't we?
Then it's 50% drivers (usb, mfd, xen, mmc, gpu, media..), 20% arch,
15+% fs, and a smattering of random stuff.

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.

I'll be mostly off-line for a couple of days (scuba cylinder
inspection class etc), but if this pattern of "people send me stuff on
Friday" holds true, I guess nobody will actually care. Plus I will
have my laptop and work environment, so if something *does* come up,
we're fine anyway, I'm just not quite as on-line as I normally am.

                     Linus

---

Aaro Koskinen (1):
      ARM: OMAP1: mux: add missing include

Adrian Hunter (2):
      mmc: fixes for eMMC v4.5 discard operation
      mmc: fixes for eMMC v4.5 sanitize operation

Ajay Kumar Gupta (1):
      usb: musb: fix bug in musb_cleanup_urb

Al Viro (15):
      nfsd: fix b0rken error value for setattr on read-only mount
      nfsd: fix error values returned by nfsd4_lockt() when nfsd_open() fails
      nfsd: fix endianness breakage in TEST_STATEID handling
      nfsd: fix error value on allocation failure in nfsd4_decode_test_stateid()
      nfsd: fix compose_entry_fh() failure exits
      ext4: fix endianness breakage in ext4_split_extent_at()
      btrfs: btrfs_root_readonly() broken on big-endian
      ocfs2: ->l_next_free_req breakage on big-endian
      ocfs: ->rl_used breakage on big-endian
      ocfs2: ->rl_count endianness breakage
      ocfs2: ->e_leaf_clusters endianness breakage
      lockd: fix the endianness bug
      aio: don't bother with unmapping when aio_free_ring() is coming
from exit_aio()
      perfmon: kill some helpers and arguments
      kill mm argument of vm_munmap()

Alan Stern (3):
      USB: fix deadlock in bConfigurationValue attribute method
      EHCI: fix criterion for resuming the root hub
      EHCI: always clear the STS_FLR status bit

Alex Deucher (1):
      drm/radeon/si: add missing radeon_bo_unreserve in si_rlc_init() v2

Alex Williamson (2):
      KVM: unmap pages from the iommu when slots are removed
      KVM: lock slots_lock around device assignment

Alexander Shiyan (1):
      ARM: clps711x: serial driver hungs are a result of call
disable_irq within ISR

Alexey Khoroshilov (1):
      [media] drxk: Does not unlock mutex if sanity check failed in
scu_command()

Anand Avati (1):
      fuse: O_DIRECT support for files

Anatolij Gustschin (1):
      USB: ehci-fsl: Fix kernel crash on mpc5121e

Andre Przywara (1):
      hwmon: fam15h_power: fix bogus values with current BIOSes

Andrzej Pietrasiewicz (3):
      usb: gadget: FunctionFS: clear FFS_FL_BOUND flag on unbind (bugfix)
      usb: gadget: FunctionFS: make module init & exit __init & __exit
      usb: gadget: eliminate NULL pointer dereference (bugfix)

Anton Tikhomirov (5):
      usb: s3c-hsotg: Fix TX FIFOs allocation
      usb: s3c-hsotg: Fix maximum patcket size setting for EP0
      usb: s3c-hsotg: Avoid TxFIFO corruption in DMA mode
      usb: s3c-hsotg: Fix big buffers transfer in DMA mode
      usb: dwc3: Free event buffers array

Archit Taneja (1):
      ARM: OMAP2/3: VENC hwmods: Remove OCPIF_SWSUP_IDLE flag from
VENC slave interface

Avi Kivity (1):
      KVM: VMX: Fix kvm_set_shared_msr() called in preemptible context

Bhupesh Sharma (1):
      usb: gadget: uvc: Remove non-required locking from
'uvc_queue_next_buffer' routine

Bjørn Mork (1):
      USB: sierra: avoid QMI/wwan interface on MC77xx

Casey Schaufler (1):
      Smack: move label list initialization

Chanho Park (1):
      perf archive: Correct cutting of symbolic link

Chris Ball (1):
      mmc: omap_hsmmc: build fix for CONFIG_OF=y and CONFIG_MMC_OMAP_HS=m

Chris Wilson (2):
      drm/i915: Hold mode_config lock whilst changing mode for lastclose()
      drm/i915: Do not set "Enable Panel Fitter" on SNB pageflips

Chuanxiao Dong (1):
      mmc: remove MMC bus legacy suspend/resume method

Dan Carpenter (1):
      sata_mv: silence an uninitialized variable warning

Dan Williams (1):
      libata: make ata_print_id atomic

Daniel Drake (1):
      mmc: sdhci: refine non-removable card checking for card detection

Daniel Lezcano (1):
      mfd : Fix dbx500 compilation error

Daniel Vetter (1):
      drm/i915: don't clobber the special upscaling lvds timings

Dave Airlie (3):
      drm/radeon: disable MSI on RV515
      drm/usb: fix module license on drm/usb layer.
      drm/radeon: fix load detect on rn50 with hardcoded EDIDs.

David Gibson (1):
      virtio_balloon: Fix endian bug

David Härdeman (1):
      [media] rc-core: set mode for winbond-cir

Dennis Chen (1):
      [S390] s390/char/vmur.c: fix memory leak

Dmitry Artamonow (1):
      mfd: Fix asic3_gpio_to_irq

Dong Aisheng (1):
      pinctrl: fix compile error if not select PINMUX support

Eric Bénard (1):
      mmc: unbreak sdhci-esdhc-imx on i.MX25

Eric Paris (1):
      fcaps: clear the same personality flags as suid when fcaps are used

Fabio Estevam (2):
      ARM: imx_v4_v5_defconfig: Add support for CONFIG_REGULATOR_FIXED_VOLTAGE
      ARM: imx27-dt: Fix build due to removal of irq_domain_add_simple()

Felipe Balbi (2):
      usb: gadget: udc-core: stop UDC on device-initiated disconnect
      usb: dwc3: ep0: increment "actual" on bounced ep0 case

Fernando Guzman Lugo (1):
      ARM: OMAP2+: hwmod: add softreset delay field and OMAP4 data

Gerard Cauvy (1):
      usb: dwc3: ep0: add a default case for SetFeature command

Gleb Natapov (1):
      KVM: PMU emulation: GLOBAL_CTRL MSR should be enabled on reset

Govindraj.R (1):
      ARM: OMAP2+: UART: Fix incorrect population of default uart pads

Grazvydas Ignotas (3):
      usb: musb: fix some runtime_pm issues
      usb: musb: wake the device before ulpi transfers
      ARM: OMAP: sram: fix BUG in dpll code for !PM case

Greg Ungerer (4):
      m68knommu: remove the unused bootlogo.h processing for 68EZ328 and 68VZ328
      m68knommu: move and fix the 68VZ328 platform bootlogo.h
      m68knommu: fix id number for second eth device on 5275 ColdFire
      m68knommu: make sure 2nd FEC eth interface pins are enabled on
5275 ColdFire

Guennadi Liakhovetski (2):
      [media] V4L: mt9m032: fix two dead-locks
      [media] V4L: mt9m032: fix compilation breakage

Guenter Roeck (1):
      hwmon: (ads1015) Fix build warning

H Hartley Sweeten (1):
      mmc: cd-gpio: Include header to pickup exported symbol prototypes

Heiko Carstens (2):
      [S390] irq: simple coding style change
      [S390] cpum_cf: get rid of compile warnings

Henrik Rydberg (1):
      nouveau: Set special lane map for the right chipset

Horia Geanta (1):
      crypto: talitos - properly lock access to global talitos registers

Hugh Dickins (1):
      memcg: fix Bad page state after replace_page_cache

J. Bruce Fields (1):
      nfsd: don't fail unchecked creates of non-special files

Jaehoon Chung (1):
      mmc: dw_mmc: prevent NULL dereference for dma_ops

Jean-Christophe PLAGNIOL-VILLARD (2):
      ARM: at91: fix rm9200ek flash size
      ARM: at91: fix at91sam9261ek Ethernet dm9000 irq

Jeff Layton (1):
      nfsd: include cld.h in the headers_install target

Jerome Glisse (1):
      radeon: fix r600/agp when vram is after AGP (v3)

Jesper Juhl (1):
      mpi: Avoid using freed pointer in mpi_lshift_limbs()

Jim Meyering (1):
      drm/nouveau/pm: don't read/write beyond end of stack buffer

Jiri Kosina (1):
      HID: tivo: fix support for bluetooth version of tivo Slide

Jiri Olsa (2):
      perf session: Skip event correctly for unknown id/machine
      perf tools: Fix parsers' rules to dependencies

Joachim Eastwood (5):
      ARM: at91: Export at91_st_base
      ARM: at91: Export at91_ramc_base
      ARM: at91: Export at91_pmc_base
      ARM: at91: Export at91_matrix_base
      ARM: at91: remove empty at91_init_serial function

Joe Perches (1):
      checkpatch: revert --strict test for net/ and drivers/net block
comment style

Jonas Aaberg (1):
      ARM: ux500: wake secondary cpu via resched

Jonghwan Choi (1):
      security: fix compile error in commoncap.c

Joonyoung Shim (1):
      drm: fix page_flip error handling

Josh Boyer (1):
      HID: default HID_BATTERY_STRENGTH to no

Julia Lawall (4):
      [S390] drivers/s390/block/dasd_eckd.c: add missing dasd_sfree_request
      xen/grant-table: add error-handling code on failure of gnttab_resume
      drivers/usb/misc/usbtest.c: add kfrees
      drivers/tty/amiserial.c: add missing tty_unlock

Kent Yoder (1):
      crypto: sha512 - Fix byte counter overflow in SHA-512

Keshava Munegowda (1):
      ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

Kishon Vijay Abraham I (2):
      usb: musb: omap: fix crash when musb glue (omap) gets initialized
      usb: gadget: udc-core: fix asymmetric calls in remove_driver

Konrad Rzeszutek Wilk (4):
      xen/blkback: Fix warning error.
      xen/xenbus: Add quirk to deal with misconfigured backends.
      xen/resume: Fix compile warnings.
      Revert "xen/p2m: m2p_find_override: use list_for_each_entry_safe"

Kuninori Morimoto (1):
      ALSA: workaround: change the timing of alsa_sound_last_init()

Lasse Collin (1):
      xz: Enable BCJ filters on SPARC and 32-bit x86

Lee Jones (1):
      ARM: ux500: Fix unmet direct dependency

Lin Ming (1):
      libata: forbid port runtime pm by default, fixing regression

Linus Torvalds (5):
      Revert "ACPI: ignore FADT reset-reg-sup flag"
      VM: add "vm_brk()" helper function
      VM: add "vm_munmap()" helper function
      VM: add "vm_mmap()" helper function
      Linux 3.4-rc4

Linus Walleij (1):
      ARM: ux500: update defconfig

Lukasz Majewski (1):
      usb: gadget: rndis: fix Missing req->context assignment

Marcos Paulo de Souza (1):
      drivers: gpu: drm: gma500: mdfld_dsi_output.h: Remove not
unneeded include of version.h

Martin Schwidefsky (2):
      [S390] fix tlb flushing for page table pages
      [S390] Fix compile error in swab.h

Masami Hiramatsu (1):
      x86: Handle failures of parsing immediate operands in the
instruction decoder

Mauro Carvalho Chehab (1):
      [media] dvb_frontend: Fix a regression when switching back to DVB-S

Michael Holzheu (3):
      [S390] kernel: Use local_irq_save() for memcpy_real()
      [S390] update default configuration
      [S390] Fix stfle() lowcore protection problem

Michael Krufky (1):
      [media] xc5000: support 32MHz & 31.875MHz xtal using the 41.024.5 firmware

Michael S. Tsirkin (1):
      virtio_balloon: fix handling of PAGE_SIZE != 4k

Michał Wróbel (1):
      crypto: ixp4xx - include fix

Miklos Szeredi (3):
      fuse: fix nlink after unlink
      fuse: allow nanosecond granularity
      fuse: use flexible array in fuse.h

Moiz Sonasath (1):
      usb: dwc3: ep0: Handle requests greater than wMaxPacketSize

Namhyung Kim (1):
      perf tools: Ignore auto-generated bison/flex files

Nicolas Ferre (5):
      ARM: at91: fix typo in at91_pmc_base assembly declaration
      leds-atmel-pwm.c: Make pwmled_probe() __devinit
      USB: ohci-at91: change annotations for probe/remove functions
      USB: gadget/at91_udc: add gpio_to_irq() function to vbus interrupt
      dmaengine: Kconfig: fix Atmel at_hdmac entry

Oliver Neukum (2):
      uwb: fix use of del_timer_sync() in interrupt
      uwb: fix error handling

Paul Gortmaker (2):
      mfd: Fix modular builds of rc5t583 regulator support
      ARM: bcmring: fix UART declarations

Paul Walmsley (2):
      ARM: OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make
omap_hwmod_softreset wait for reset status"
      ARM: OMAP1: DMTIMER: fix broken timer clock source selection

Peter Chen (1):
      usb: fsl_udc_core: prime status stage once data stage has primed

Peter Ujfalusi (1):
      mfd: Convert twl6040 to i2c driver, and separate it from twl core

Prathyush (1):
      drm: Releasing FBs before releasing GEM objects during drm_release

Rafael J. Wysocki (1):
      PCI: Retry BARs restoration for Type 0 headers only

Rajendra Nayak (1):
      mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage

Randy Dunlap (2):
      Documentation: maintainer change
      ALSA: fix core/vmaster.c kernel-doc warning

Ren Mingxin (1):
      virtio_blk: helper function to format disk names

Robert Lee (1):
      ARM: imx: Fix imx5 idle logic bug

Sachin Prabhu (2):
      Cleanup handling of NULL value passed for a mount option
      Fix number parsing in cifs_parse_mount_options

Santosh Shilimkar (1):
      ARM: OMAP: serial: Fix the ocp smart idlemode handling bug

Seth Heasley (1):
      ata_piix: IDE-mode SATA patch for Intel DH89xxCC DeviceIDs

Seungwon Jeon (1):
      mmc: dw_mmc: Fix switch from DMA to PIO

Shubhrajyoti D (1):
      usb: musb: omap: fix the error check for pm_runtime_get_sync

Stefano Stabellini (2):
      xen/gntdev: do not set VM_PFNMAP
      xen/p2m: m2p_find_override: use list_for_each_entry_safe

Stephane Eranian (1):
      perf tools: fix NO_GTK2 Makefile config error

Stephen Warren (3):
      pinctrl: include <linux/bug.h> to prevent compile errors
      pinctrl: implement pinctrl_check_ops
      USB: ehci-tegra: don't call set_irq_flags(IRQF_VALID)

Sylwester Nawrocki (1):
      [media] V4L: DocBook: Fix typos in the multi-plane formats description

Takashi Iwai (5):
      ALSA: hda/realtek - Fix regression on Quanta/Gericom KN1
      ALSA: hda/sigmatel - Fix inverted mute LED
      drm/radeon/kms: fix the regression of DVI connector check
      ALSA: hda/conexant - Don't set HP pin-control bit unconditionally
      ALSA: hda/conexant - Set up the missing docking-station pins

Tejun Heo (1):
      memblock: memblock should be able to handle zero length operations

Theodore Ts'o (2):
      ext4: address scalability issue by removing extent cache statistics
      ext4: fix handling of journalled quota options

Thomas Gleixner (1):
      Revert "ACPI: Make ACPI interrupt threaded"

Tomoki Sekiyama (2):
      USB: yurex: Remove allocation of coherent buffer for setup-packet buffer
      USB: yurex: Fix missing URB_NO_TRANSFER_DMA_MAP flag in urb

Tomoya MORINAGA (1):
      pch_uart: Fix dma channel unallocated issue

Tony Luck (1):
      ia64: fix futex_atomic_cmpxchg_inatomic()

Ulf Hansson (1):
      mmc: core: Do not pre-claim host in suspend

Vladimir Zapolskiy (1):
      usb: musb: fix oops on omap2430 module unload

Xi Wang (2):
      usb: usbtest: avoid integer overflow in test_ctrl_queue()
      usb: usbtest: avoid integer overflow in alloc_sglist()

Yong Zhang (1):
      sparc32,leon: add notify_cpu_starting()

Yuri Matylitski (1):
      USB: serial: cp210x: Fixed usb_control_msg timeout values

Zhi Yong Wu (1):
      tools/virtio: fix up vhost/test module build

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Linux 3.4-rc4
  2012-04-21 22:43 Linux 3.4-rc4 Linus Torvalds
@ 2012-04-22  4:07 ` Nick Bowler
  2012-04-22  4:51   ` Linus Torvalds
  2012-04-22  8:38 ` Bjarke Istrup Pedersen
  1 sibling, 1 reply; 33+ messages in thread
From: Nick Bowler @ 2012-04-22  4:07 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

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] 33+ messages in thread

* Re: Linux 3.4-rc4
  2012-04-22  4:07 ` Nick Bowler
@ 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; 33+ messages in thread
From: Linus Torvalds @ 2012-04-22  4:51 UTC (permalink / raw)
  To: David Airlie, Ben Skeggs, Martin Peres, dri-devel
  Cc: Linux Kernel Mailing List, Nick Bowler

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] 33+ messages in thread

* Re: Linux 3.4-rc4
  2012-04-22  4:51   ` 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; 33+ messages in thread
From: Dave Airlie @ 2012-04-22  7:26 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: David Airlie, Ben Skeggs, Martin Peres, dri-devel, Nick Bowler,
	Linux Kernel Mailing List

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] 33+ messages in thread

* Re: Linux 3.4-rc4
  2012-04-21 22:43 Linux 3.4-rc4 Linus Torvalds
  2012-04-22  4:07 ` Nick Bowler
@ 2012-04-22  8:38 ` Bjarke Istrup Pedersen
  1 sibling, 0 replies; 33+ messages in thread
From: Bjarke Istrup Pedersen @ 2012-04-22  8:38 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

22. apr. 2012 00.43 skrev Linus Torvalds <torvalds@linux-foundation.org>:
> Things looked fairly calm for a while, but that certainly changed
> yesterday. I think either people time their pulls for the -rc releases
> too, or it's just a matter of many developers actually having a
> somewhat normal Mon-Fri workweek these days and they close the week by
> sending my their pull request. Regardless of why, it meant that my
> "oh, things are really calming down nicely" state on Thursday changed
> to "Uhhuh, not quite yet" on Friday - when more than half the commits
> for this whole -rc release came in.
>
> Oh well.
>
> That said, even with the uptick on Friday, I do think things have been
> fairly calm. We've got a few reverts and a few cleanups, but the bulk
> of it is trivial small fixes. Almost all of it in drivers with a few
> filesystem updates (many of them endianness fixes from Al) thrown in
> too. The traditional (non-rename) diff is dominated by a m68k bootlogo
> movement, but we all use those nice git diffs these days, don't we?
> Then it's 50% drivers (usb, mfd, xen, mmc, gpu, media..), 20% arch,
> 15+% fs, and a smattering of random stuff.
>
> 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.

Hey,

I know it is a small issue, but it would be nice to have this fix
applied before 3.4 goes final: https://lkml.org/lkml/2012/4/10/484
If not possible, could it be possible to revert
da4e3302949f4a702f1ddfefe067762232d363d5, since that removes the old
driver, and adds the new one, where it is inverted.

I've been trying sending it to the platform-x86-drivers mailing list,
resulting in silence.

Thanks,
Bjarke

> I'll be mostly off-line for a couple of days (scuba cylinder
> inspection class etc), but if this pattern of "people send me stuff on
> Friday" holds true, I guess nobody will actually care. Plus I will
> have my laptop and work environment, so if something *does* come up,
> we're fine anyway, I'm just not quite as on-line as I normally am.
>
>                     Linus
>
> ---
>
> Aaro Koskinen (1):
>      ARM: OMAP1: mux: add missing include
>
> Adrian Hunter (2):
>      mmc: fixes for eMMC v4.5 discard operation
>      mmc: fixes for eMMC v4.5 sanitize operation
>
> Ajay Kumar Gupta (1):
>      usb: musb: fix bug in musb_cleanup_urb
>
> Al Viro (15):
>      nfsd: fix b0rken error value for setattr on read-only mount
>      nfsd: fix error values returned by nfsd4_lockt() when nfsd_open() fails
>      nfsd: fix endianness breakage in TEST_STATEID handling
>      nfsd: fix error value on allocation failure in nfsd4_decode_test_stateid()
>      nfsd: fix compose_entry_fh() failure exits
>      ext4: fix endianness breakage in ext4_split_extent_at()
>      btrfs: btrfs_root_readonly() broken on big-endian
>      ocfs2: ->l_next_free_req breakage on big-endian
>      ocfs: ->rl_used breakage on big-endian
>      ocfs2: ->rl_count endianness breakage
>      ocfs2: ->e_leaf_clusters endianness breakage
>      lockd: fix the endianness bug
>      aio: don't bother with unmapping when aio_free_ring() is coming
> from exit_aio()
>      perfmon: kill some helpers and arguments
>      kill mm argument of vm_munmap()
>
> Alan Stern (3):
>      USB: fix deadlock in bConfigurationValue attribute method
>      EHCI: fix criterion for resuming the root hub
>      EHCI: always clear the STS_FLR status bit
>
> Alex Deucher (1):
>      drm/radeon/si: add missing radeon_bo_unreserve in si_rlc_init() v2
>
> Alex Williamson (2):
>      KVM: unmap pages from the iommu when slots are removed
>      KVM: lock slots_lock around device assignment
>
> Alexander Shiyan (1):
>      ARM: clps711x: serial driver hungs are a result of call
> disable_irq within ISR
>
> Alexey Khoroshilov (1):
>      [media] drxk: Does not unlock mutex if sanity check failed in
> scu_command()
>
> Anand Avati (1):
>      fuse: O_DIRECT support for files
>
> Anatolij Gustschin (1):
>      USB: ehci-fsl: Fix kernel crash on mpc5121e
>
> Andre Przywara (1):
>      hwmon: fam15h_power: fix bogus values with current BIOSes
>
> Andrzej Pietrasiewicz (3):
>      usb: gadget: FunctionFS: clear FFS_FL_BOUND flag on unbind (bugfix)
>      usb: gadget: FunctionFS: make module init & exit __init & __exit
>      usb: gadget: eliminate NULL pointer dereference (bugfix)
>
> Anton Tikhomirov (5):
>      usb: s3c-hsotg: Fix TX FIFOs allocation
>      usb: s3c-hsotg: Fix maximum patcket size setting for EP0
>      usb: s3c-hsotg: Avoid TxFIFO corruption in DMA mode
>      usb: s3c-hsotg: Fix big buffers transfer in DMA mode
>      usb: dwc3: Free event buffers array
>
> Archit Taneja (1):
>      ARM: OMAP2/3: VENC hwmods: Remove OCPIF_SWSUP_IDLE flag from
> VENC slave interface
>
> Avi Kivity (1):
>      KVM: VMX: Fix kvm_set_shared_msr() called in preemptible context
>
> Bhupesh Sharma (1):
>      usb: gadget: uvc: Remove non-required locking from
> 'uvc_queue_next_buffer' routine
>
> Bjørn Mork (1):
>      USB: sierra: avoid QMI/wwan interface on MC77xx
>
> Casey Schaufler (1):
>      Smack: move label list initialization
>
> Chanho Park (1):
>      perf archive: Correct cutting of symbolic link
>
> Chris Ball (1):
>      mmc: omap_hsmmc: build fix for CONFIG_OF=y and CONFIG_MMC_OMAP_HS=m
>
> Chris Wilson (2):
>      drm/i915: Hold mode_config lock whilst changing mode for lastclose()
>      drm/i915: Do not set "Enable Panel Fitter" on SNB pageflips
>
> Chuanxiao Dong (1):
>      mmc: remove MMC bus legacy suspend/resume method
>
> Dan Carpenter (1):
>      sata_mv: silence an uninitialized variable warning
>
> Dan Williams (1):
>      libata: make ata_print_id atomic
>
> Daniel Drake (1):
>      mmc: sdhci: refine non-removable card checking for card detection
>
> Daniel Lezcano (1):
>      mfd : Fix dbx500 compilation error
>
> Daniel Vetter (1):
>      drm/i915: don't clobber the special upscaling lvds timings
>
> Dave Airlie (3):
>      drm/radeon: disable MSI on RV515
>      drm/usb: fix module license on drm/usb layer.
>      drm/radeon: fix load detect on rn50 with hardcoded EDIDs.
>
> David Gibson (1):
>      virtio_balloon: Fix endian bug
>
> David Härdeman (1):
>      [media] rc-core: set mode for winbond-cir
>
> Dennis Chen (1):
>      [S390] s390/char/vmur.c: fix memory leak
>
> Dmitry Artamonow (1):
>      mfd: Fix asic3_gpio_to_irq
>
> Dong Aisheng (1):
>      pinctrl: fix compile error if not select PINMUX support
>
> Eric Bénard (1):
>      mmc: unbreak sdhci-esdhc-imx on i.MX25
>
> Eric Paris (1):
>      fcaps: clear the same personality flags as suid when fcaps are used
>
> Fabio Estevam (2):
>      ARM: imx_v4_v5_defconfig: Add support for CONFIG_REGULATOR_FIXED_VOLTAGE
>      ARM: imx27-dt: Fix build due to removal of irq_domain_add_simple()
>
> Felipe Balbi (2):
>      usb: gadget: udc-core: stop UDC on device-initiated disconnect
>      usb: dwc3: ep0: increment "actual" on bounced ep0 case
>
> Fernando Guzman Lugo (1):
>      ARM: OMAP2+: hwmod: add softreset delay field and OMAP4 data
>
> Gerard Cauvy (1):
>      usb: dwc3: ep0: add a default case for SetFeature command
>
> Gleb Natapov (1):
>      KVM: PMU emulation: GLOBAL_CTRL MSR should be enabled on reset
>
> Govindraj.R (1):
>      ARM: OMAP2+: UART: Fix incorrect population of default uart pads
>
> Grazvydas Ignotas (3):
>      usb: musb: fix some runtime_pm issues
>      usb: musb: wake the device before ulpi transfers
>      ARM: OMAP: sram: fix BUG in dpll code for !PM case
>
> Greg Ungerer (4):
>      m68knommu: remove the unused bootlogo.h processing for 68EZ328 and 68VZ328
>      m68knommu: move and fix the 68VZ328 platform bootlogo.h
>      m68knommu: fix id number for second eth device on 5275 ColdFire
>      m68knommu: make sure 2nd FEC eth interface pins are enabled on
> 5275 ColdFire
>
> Guennadi Liakhovetski (2):
>      [media] V4L: mt9m032: fix two dead-locks
>      [media] V4L: mt9m032: fix compilation breakage
>
> Guenter Roeck (1):
>      hwmon: (ads1015) Fix build warning
>
> H Hartley Sweeten (1):
>      mmc: cd-gpio: Include header to pickup exported symbol prototypes
>
> Heiko Carstens (2):
>      [S390] irq: simple coding style change
>      [S390] cpum_cf: get rid of compile warnings
>
> Henrik Rydberg (1):
>      nouveau: Set special lane map for the right chipset
>
> Horia Geanta (1):
>      crypto: talitos - properly lock access to global talitos registers
>
> Hugh Dickins (1):
>      memcg: fix Bad page state after replace_page_cache
>
> J. Bruce Fields (1):
>      nfsd: don't fail unchecked creates of non-special files
>
> Jaehoon Chung (1):
>      mmc: dw_mmc: prevent NULL dereference for dma_ops
>
> Jean-Christophe PLAGNIOL-VILLARD (2):
>      ARM: at91: fix rm9200ek flash size
>      ARM: at91: fix at91sam9261ek Ethernet dm9000 irq
>
> Jeff Layton (1):
>      nfsd: include cld.h in the headers_install target
>
> Jerome Glisse (1):
>      radeon: fix r600/agp when vram is after AGP (v3)
>
> Jesper Juhl (1):
>      mpi: Avoid using freed pointer in mpi_lshift_limbs()
>
> Jim Meyering (1):
>      drm/nouveau/pm: don't read/write beyond end of stack buffer
>
> Jiri Kosina (1):
>      HID: tivo: fix support for bluetooth version of tivo Slide
>
> Jiri Olsa (2):
>      perf session: Skip event correctly for unknown id/machine
>      perf tools: Fix parsers' rules to dependencies
>
> Joachim Eastwood (5):
>      ARM: at91: Export at91_st_base
>      ARM: at91: Export at91_ramc_base
>      ARM: at91: Export at91_pmc_base
>      ARM: at91: Export at91_matrix_base
>      ARM: at91: remove empty at91_init_serial function
>
> Joe Perches (1):
>      checkpatch: revert --strict test for net/ and drivers/net block
> comment style
>
> Jonas Aaberg (1):
>      ARM: ux500: wake secondary cpu via resched
>
> Jonghwan Choi (1):
>      security: fix compile error in commoncap.c
>
> Joonyoung Shim (1):
>      drm: fix page_flip error handling
>
> Josh Boyer (1):
>      HID: default HID_BATTERY_STRENGTH to no
>
> Julia Lawall (4):
>      [S390] drivers/s390/block/dasd_eckd.c: add missing dasd_sfree_request
>      xen/grant-table: add error-handling code on failure of gnttab_resume
>      drivers/usb/misc/usbtest.c: add kfrees
>      drivers/tty/amiserial.c: add missing tty_unlock
>
> Kent Yoder (1):
>      crypto: sha512 - Fix byte counter overflow in SHA-512
>
> Keshava Munegowda (1):
>      ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
>
> Kishon Vijay Abraham I (2):
>      usb: musb: omap: fix crash when musb glue (omap) gets initialized
>      usb: gadget: udc-core: fix asymmetric calls in remove_driver
>
> Konrad Rzeszutek Wilk (4):
>      xen/blkback: Fix warning error.
>      xen/xenbus: Add quirk to deal with misconfigured backends.
>      xen/resume: Fix compile warnings.
>      Revert "xen/p2m: m2p_find_override: use list_for_each_entry_safe"
>
> Kuninori Morimoto (1):
>      ALSA: workaround: change the timing of alsa_sound_last_init()
>
> Lasse Collin (1):
>      xz: Enable BCJ filters on SPARC and 32-bit x86
>
> Lee Jones (1):
>      ARM: ux500: Fix unmet direct dependency
>
> Lin Ming (1):
>      libata: forbid port runtime pm by default, fixing regression
>
> Linus Torvalds (5):
>      Revert "ACPI: ignore FADT reset-reg-sup flag"
>      VM: add "vm_brk()" helper function
>      VM: add "vm_munmap()" helper function
>      VM: add "vm_mmap()" helper function
>      Linux 3.4-rc4
>
> Linus Walleij (1):
>      ARM: ux500: update defconfig
>
> Lukasz Majewski (1):
>      usb: gadget: rndis: fix Missing req->context assignment
>
> Marcos Paulo de Souza (1):
>      drivers: gpu: drm: gma500: mdfld_dsi_output.h: Remove not
> unneeded include of version.h
>
> Martin Schwidefsky (2):
>      [S390] fix tlb flushing for page table pages
>      [S390] Fix compile error in swab.h
>
> Masami Hiramatsu (1):
>      x86: Handle failures of parsing immediate operands in the
> instruction decoder
>
> Mauro Carvalho Chehab (1):
>      [media] dvb_frontend: Fix a regression when switching back to DVB-S
>
> Michael Holzheu (3):
>      [S390] kernel: Use local_irq_save() for memcpy_real()
>      [S390] update default configuration
>      [S390] Fix stfle() lowcore protection problem
>
> Michael Krufky (1):
>      [media] xc5000: support 32MHz & 31.875MHz xtal using the 41.024.5 firmware
>
> Michael S. Tsirkin (1):
>      virtio_balloon: fix handling of PAGE_SIZE != 4k
>
> Michał Wróbel (1):
>      crypto: ixp4xx - include fix
>
> Miklos Szeredi (3):
>      fuse: fix nlink after unlink
>      fuse: allow nanosecond granularity
>      fuse: use flexible array in fuse.h
>
> Moiz Sonasath (1):
>      usb: dwc3: ep0: Handle requests greater than wMaxPacketSize
>
> Namhyung Kim (1):
>      perf tools: Ignore auto-generated bison/flex files
>
> Nicolas Ferre (5):
>      ARM: at91: fix typo in at91_pmc_base assembly declaration
>      leds-atmel-pwm.c: Make pwmled_probe() __devinit
>      USB: ohci-at91: change annotations for probe/remove functions
>      USB: gadget/at91_udc: add gpio_to_irq() function to vbus interrupt
>      dmaengine: Kconfig: fix Atmel at_hdmac entry
>
> Oliver Neukum (2):
>      uwb: fix use of del_timer_sync() in interrupt
>      uwb: fix error handling
>
> Paul Gortmaker (2):
>      mfd: Fix modular builds of rc5t583 regulator support
>      ARM: bcmring: fix UART declarations
>
> Paul Walmsley (2):
>      ARM: OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make
> omap_hwmod_softreset wait for reset status"
>      ARM: OMAP1: DMTIMER: fix broken timer clock source selection
>
> Peter Chen (1):
>      usb: fsl_udc_core: prime status stage once data stage has primed
>
> Peter Ujfalusi (1):
>      mfd: Convert twl6040 to i2c driver, and separate it from twl core
>
> Prathyush (1):
>      drm: Releasing FBs before releasing GEM objects during drm_release
>
> Rafael J. Wysocki (1):
>      PCI: Retry BARs restoration for Type 0 headers only
>
> Rajendra Nayak (1):
>      mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
>
> Randy Dunlap (2):
>      Documentation: maintainer change
>      ALSA: fix core/vmaster.c kernel-doc warning
>
> Ren Mingxin (1):
>      virtio_blk: helper function to format disk names
>
> Robert Lee (1):
>      ARM: imx: Fix imx5 idle logic bug
>
> Sachin Prabhu (2):
>      Cleanup handling of NULL value passed for a mount option
>      Fix number parsing in cifs_parse_mount_options
>
> Santosh Shilimkar (1):
>      ARM: OMAP: serial: Fix the ocp smart idlemode handling bug
>
> Seth Heasley (1):
>      ata_piix: IDE-mode SATA patch for Intel DH89xxCC DeviceIDs
>
> Seungwon Jeon (1):
>      mmc: dw_mmc: Fix switch from DMA to PIO
>
> Shubhrajyoti D (1):
>      usb: musb: omap: fix the error check for pm_runtime_get_sync
>
> Stefano Stabellini (2):
>      xen/gntdev: do not set VM_PFNMAP
>      xen/p2m: m2p_find_override: use list_for_each_entry_safe
>
> Stephane Eranian (1):
>      perf tools: fix NO_GTK2 Makefile config error
>
> Stephen Warren (3):
>      pinctrl: include <linux/bug.h> to prevent compile errors
>      pinctrl: implement pinctrl_check_ops
>      USB: ehci-tegra: don't call set_irq_flags(IRQF_VALID)
>
> Sylwester Nawrocki (1):
>      [media] V4L: DocBook: Fix typos in the multi-plane formats description
>
> Takashi Iwai (5):
>      ALSA: hda/realtek - Fix regression on Quanta/Gericom KN1
>      ALSA: hda/sigmatel - Fix inverted mute LED
>      drm/radeon/kms: fix the regression of DVI connector check
>      ALSA: hda/conexant - Don't set HP pin-control bit unconditionally
>      ALSA: hda/conexant - Set up the missing docking-station pins
>
> Tejun Heo (1):
>      memblock: memblock should be able to handle zero length operations
>
> Theodore Ts'o (2):
>      ext4: address scalability issue by removing extent cache statistics
>      ext4: fix handling of journalled quota options
>
> Thomas Gleixner (1):
>      Revert "ACPI: Make ACPI interrupt threaded"
>
> Tomoki Sekiyama (2):
>      USB: yurex: Remove allocation of coherent buffer for setup-packet buffer
>      USB: yurex: Fix missing URB_NO_TRANSFER_DMA_MAP flag in urb
>
> Tomoya MORINAGA (1):
>      pch_uart: Fix dma channel unallocated issue
>
> Tony Luck (1):
>      ia64: fix futex_atomic_cmpxchg_inatomic()
>
> Ulf Hansson (1):
>      mmc: core: Do not pre-claim host in suspend
>
> Vladimir Zapolskiy (1):
>      usb: musb: fix oops on omap2430 module unload
>
> Xi Wang (2):
>      usb: usbtest: avoid integer overflow in test_ctrl_queue()
>      usb: usbtest: avoid integer overflow in alloc_sglist()
>
> Yong Zhang (1):
>      sparc32,leon: add notify_cpu_starting()
>
> Yuri Matylitski (1):
>      USB: serial: cp210x: Fixed usb_control_msg timeout values
>
> Zhi Yong Wu (1):
>      tools/virtio: fix up vhost/test module build
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Linux 3.4-rc4
  2012-04-22  4:51   ` 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-04-23  2:45 UTC (permalink / raw)
  To: Nick Bowler
  Cc: Linus Torvalds, Martin Peres, 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ messages in thread
From: Ben Skeggs @ 2012-04-25  2:56 UTC (permalink / raw)
  To: Nick Bowler
  Cc: Konrad Rzeszutek Wilk, Linus Torvalds, Martin Peres, dri-devel,
	Linux Kernel Mailing List

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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ messages in thread
From: Nick Bowler @ 2012-04-28 15:33 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Ben Skeggs, Martin Peres, Linus Torvalds,
	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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ messages in thread
From: Luca Tettamanti @ 2012-04-30 11:01 UTC (permalink / raw)
  To: Maarten Maathuis
  Cc: Dmitry Torokhov, Nick Bowler, Martin Peres, Linus Torvalds,
	Linux Kernel Mailing List, dri-devel, 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

^ permalink raw reply	[flat|nested] 33+ 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; 33+ 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] 33+ 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; 33+ messages in thread
From: Alan Cox @ 2012-05-01 15:09 UTC (permalink / raw)
  To: Nick Bowler
  Cc: Maarten Maathuis, Dmitry Torokhov, Martin Peres,
	Linux Kernel Mailing List, dri-devel, 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] 33+ 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; 33+ messages in thread
From: Nick Bowler @ 2012-05-01 15:31 UTC (permalink / raw)
  To: Alan Cox
  Cc: Maarten Maathuis, Dmitry Torokhov, Martin Peres,
	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] 33+ 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; 33+ 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] 33+ 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; 33+ messages in thread
From: Nick Bowler @ 2012-05-02  1:20 UTC (permalink / raw)
  To: Maarten Maathuis
  Cc: Dmitry Torokhov, Martin Peres, Linux Kernel Mailing List,
	dri-devel, Linus Torvalds, Ben Skeggs

(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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ messages in thread
From: Ben Skeggs @ 2012-05-04  5:08 UTC (permalink / raw)
  To: Jean Delvare
  Cc: Bowler, Dmitry Torokhov, Linux Kernel Mailing List, dri-devel,
	Nick, Martin Peres, Linus Torvalds

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] 33+ 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; 33+ messages in thread
From: Dave Airlie @ 2012-05-04  9:20 UTC (permalink / raw)
  To: Nick Bowler
  Cc: Maarten Maathuis, 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


^ permalink raw reply related	[flat|nested] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ messages in thread

end of thread, other threads:[~2012-05-05 15:39 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-21 22:43 Linux 3.4-rc4 Linus Torvalds
2012-04-22  4:07 ` Nick Bowler
2012-04-22  4:51   ` 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
2012-04-22  8:38 ` Bjarke Istrup Pedersen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).