2.6.25-rc6-git6: Reported regressions from 2.6.24 - Kernel

This is a discussion on 2.6.25-rc6-git6: Reported regressions from 2.6.24 - Kernel ; This message contains a list of some regressions from 2.6.24 reported since 2.6.25-rc1 was released, for which there are no fixes in the mainline I know of. *If any of them have been fixed already, please let me know. If ...

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast
Results 1 to 20 of 97

Thread: 2.6.25-rc6-git6: Reported regressions from 2.6.24

  1. 2.6.25-rc6-git6: Reported regressions from 2.6.24

    This message contains a list of some regressions from 2.6.24 reported since
    2.6.25-rc1 was released, for which there are no fixes in the mainline I know
    of. *If any of them have been fixed already, please let me know.

    If you know of any other unresolved regressions from 2.6.24, please let me know
    either and I'll add them to the list. *Also, please let me know if any of the
    entries below are invalid.


    Listed regressions statistics:

    Date Total Pending Unresolved
    ----------------------------------------
    2008-03-22 159 35 31
    2008-03-17 148 38 30
    2008-03-16 146 42 35
    2008-03-14 145 45 39
    2008-03-12 143 51 41
    2008-03-11 141 58 43
    2008-03-10 138 66 47
    2008-03-03 115 65 49
    2008-02-25 90 51 39
    2008-02-17 61 45 37


    Unresolved regressions
    ----------------------

    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9412
    Subject : Since commit 'x86: enable iommu_merge by default' (948062683004d13ca21c8c05ac052d387978a449) 2.6 is no go on SB600 AHCI
    Submitter : Srihari Vijayaraghavan
    Date : 2007-11-19 14:43 (124 days old)


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9962
    Subject : mount: could not find filesystem
    Submitter : Kamalesh Babulal
    Date : 2008-02-12 14:34 (39 days old)
    References : http://lkml.org/lkml/2008/2/12/91
    Handled-By : Bartlomiej Zolnierkiewicz
    Yinghai Lu


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9976
    Subject : BUG: 2.6.25-rc1: iptables postrouting setup causes oops
    Submitter : Ben Nizette
    Date : 2008-02-12 12:46 (39 days old)
    References : http://lkml.org/lkml/2008/2/12/148
    Handled-By : Haavard Skinnemoen


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9978
    Subject : 2.6.25-rc1: volanoMark regression
    Submitter : Zhang, Yanmin
    Date : 2008-02-13 10:30 (38 days old)
    References : http://lkml.org/lkml/2008/2/13/128
    http://lkml.org/lkml/2008/3/12/52
    http://lkml.org/lkml/2008/3/18/81
    Handled-By : Srivatsa Vaddagiri
    Balbir Singh


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9980
    Subject : 2.6.25-rc1 on Sun Ultra 40- HPET clocksource which causes it to hang
    Submitter : Jasper Bryant-Greene
    Date : 2008-02-13 12:25 (38 days old)
    References : http://lkml.org/lkml/2008/2/13/181
    Handled-By : Yinghai Lu


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9995
    Subject : 2.6.25-rc1 regression - backlight controlls do not work - ThinkPad T61
    Submitter : Lukas Hejtmanek
    Date : 2008-02-15 04:51 (36 days old)
    Handled-By : Zhang Rui


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10011
    Subject : The computer is blocked when X is started - unless max_cstate=2 - Acer Travelmate 4001 Lmi
    Submitter : Franšois Valenduc
    Date : 2008-02-17 06:28 (34 days old)
    Handled-By : Thomas Gleixner


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10027
    Subject : 2.6.25-rc[12] Video4Linux Bttv Regression
    Submitter : Bongani Hlope
    Date : 2008-02-17 09:36 (34 days old)
    References : http://lkml.org/lkml/2008/2/17/55
    Handled-By : Mauro Carvalho Chehab


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10041
    Subject : 2.6.25-rc1/2 regression: first-time login into gnome fails
    Submitter : Romano Giannetti
    Date : 2008-02-18 11:56 (33 days old)
    References : http://lkml.org/lkml/2008/2/18/145
    Handled-By : Ray Lee


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10051
    Subject : Spurious messages at boot, eventually hangs the usb subsustem
    Submitter : Jean-Luc Coulon
    Date : 2008-02-20 09:10 (31 days old)


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10065
    Subject : 2.6.25-rc2 regression - hang on suspend
    Submitter : Soeren Sonnenburg
    Date : 2008-02-19 12:59 (32 days old)
    References : http://lkml.org/lkml/2008/2/19/165
    http://lkml.org/lkml/2008/2/17/381
    Handled-By : Rafael J. Wysocki


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10067
    Subject : TUNER_TDA8290=y, VIDEO_DEV=n build error
    Submitter : Toralf F÷rster
    Date : 2008-02-22 10:36 (29 days old)
    References : http://lkml.org/lkml/2008/2/19/262


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10080
    Subject : 2.6.25-rc2: ohci1394 problem (MMIO broken)
    Submitter : Thomas Meyer
    Date : 2008-02-20 08:47 (31 days old)
    References : http://lkml.org/lkml/2008/2/20/58
    Handled-By : Stefan Richter


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10082
    Subject : 2.6.25-rc2-git4 - Kernel oops while running kernbench and tbench on powerpc
    Submitter : Kamalesh Babulal
    Date : 2008-02-20 16:01 (31 days old)
    References : http://lkml.org/lkml/2008/2/20/218
    http://lkml.org/lkml/2008/1/18/71


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10093
    Subject : 2.6.25-current-git hangs on boot unless CONFIG_CPU_IDLE=n - Apple
    Submitter : Soeren Sonnenburg
    Date : 2008-02-23 18:55 (28 days old)
    References : http://lkml.org/lkml/2008/2/23/263
    http://marc.info/?l=linux-acpi&m=120387537018467&w=4
    Handled-By : Pallipadi, Venkatesh


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10117
    Subject : 2.6.25-current-git hangs on boot (pci=nommconf helps)
    Submitter : Soeren Sonnenburg
    Date : 2008-02-23 18:55 (28 days old)
    References : http://lkml.org/lkml/2008/2/23/263


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10133
    Subject : INFO: possible circular locking in the resume
    Submitter : Zdenek Kabelac
    Date : 2008-02-27 (24 days old)
    References : http://lkml.org/lkml/2008/2/26/479
    Handled-By : Gautham R Shenoy


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10146
    Subject : 2.6.25-rc: complete lockup on boot/start of X (bisected)
    Submitter : Marcin Slusarz
    Date : 2008-03-02 20:00 (20 days old)
    References : http://lkml.org/lkml/2008/3/2/91
    Handled-By : Peter Zijlstra


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10156
    Subject : KVM & Qemu crashed with infinite recursive kernel loop in the guest
    Submitter : Zdenek Kabelac
    Date : 2008-02-28 11:25 (23 days old)
    References : http://lkml.org/lkml/2008/2/28/106


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10172
    Subject : kvm: INFO: inconsistent lock state
    Submitter : Zdenek Kabelac
    Date : 2008-03-05 03:26 (17 days old)


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10235
    Subject : 2.6.25-rc5: Blank Screen with Intel 945
    Submitter : Justin Madru
    Date : 2008-03-12 12:02 (10 days old)
    References : http://lkml.org/lkml/2008/3/12/290
    Handled-By : Jesse Barnes


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10242
    Subject : rm command hangs
    Submitter : Jean-Luc Coulon
    Date : 2008-03-14 05:47 (8 days old)


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10271
    Subject : dm raid1: bitops bug
    Submitter : Heiko Carstens
    Date : 2008-03-17 16:45 (5 days old)
    References : http://lkml.org/lkml/2008/3/17/174
    Handled-By : Alasdair G Kergon


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10290
    Subject : [BUG] Linux 2.6.25-rc6 - kernel BUG at fs/mpage.c:476! on powerpc
    Submitter : Kamalesh Babulal
    Date : 2008-03-20 13:13 (2 days old)
    References : http://lkml.org/lkml/2008/3/20/39


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10291
    Subject : 2.6.25-rc6 hangs at resume after suspend to RAM on Mac mini Core Duo
    Submitter : Tino Keitel
    Date : 2008-03-20 07:05 (2 days old)
    References : http://lkml.org/lkml/2008/3/20/23


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10295
    Subject : rfkill continous console output
    Submitter : Bruce Duncan
    Date : 2008-03-21 02:01 (1 days old)


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10300
    Subject : volume wheel does not work in 2.6.25-rc6
    Submitter : Romano Giannetti
    Date : 2008-03-21 11:42 (1 days old)


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10302
    Subject : 2.6.25-git regression with snd-hda-intel on Dell XPS M1330, no analog sound
    Submitter : Andre Tomt
    Date : 2008-03-21 20:03 (1 days old)
    References : http://lkml.org/lkml/2008/3/21/295
    Handled-By : Matthew Ranostay


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10303
    Subject : [BUG] oopses in different processes since 2.6.25-rc5-git4
    Submitter : Markus Rehbach
    Date : 2008-03-21 17:18 (1 days old)
    References : http://lkml.org/lkml/2008/3/21/202


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10304
    Subject : 2.6.25-rc5-git5 KVM memory not freed
    Submitter : Ioan Ionita
    Date : 2008-03-20 18:41 (2 days old)
    References : http://lkml.org/lkml/2008/3/20/136


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10305
    Subject : 2.6.25-rc6: kernel BUG at fs/sysfs/file.c:89
    Submitter : Christian Kujau
    Date : 2008-03-21 23:35 (1 days old)
    References : http://lkml.org/lkml/2008/3/21/408


    Regressionn with patches
    ------------------------

    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9969
    Subject : 2.6.24-git15 Keyboard Issue?
    Submitter : Chris Holvenstot
    Date : 2008-02-06 14:02 (45 days old)
    References : http://lkml.org/lkml/2008/2/6/100
    http://lkml.org/lkml/2008/2/13/82
    Handled-By : Thomas Gleixner
    Patch : http://lkml.org/lkml/2008/2/15/343


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10153
    Subject : (regression) kernel/timeconst.h bugs with HZ=128
    Submitter : David Brownell
    Date : 2008-02-26 19:32 (25 days old)
    References : http://lkml.org/lkml/2008/2/26/294
    Handled-By : H. Peter Anvin
    Patch : http://bugzilla.kernel.org/attachmen...14&action=view
    http://bugzilla.kernel.org/attachmen...15&action=view


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10186
    Subject : SCSI_AIC94XX must depend on SCSI
    Submitter : Toralf F÷rster
    Date : 2008-03-06 19:09 (16 days old)
    References : http://marc.info/?l=linux-kernel&m=120483073617232&w=2
    Handled-By : Adrian Bunk
    Patch : http://marc.info/?l=linux-kernel&m=120483499725928&w=2


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10207
    Subject : INFO: task mount:11202 blocked for more than 120 seconds
    Submitter : Christian Kujau
    Date : 2008-03-07 21:32 (15 days old)
    References : http://lkml.org/lkml/2008/3/7/308
    http://lkml.org/lkml/2008/3/9/186
    Handled-By : David Chinner
    Milan Broz
    Patch : http://lkml.org/lkml/2008/3/14/71
    http://lkml.org/lkml/2008/3/17/214


    For details, please visit the bug entries and follow the links given in
    references.

    As you can see, there is a Bugzilla entry for each of the listed regressions.
    There also is a Bugzilla entry used for tracking the regressions from 2.6.24,
    unresolved as well as resolved, at:

    http://bugzilla.kernel.org/show_bug.cgi?id=9832

    Please let me know if there are any Bugzilla entries that should be added to
    the list in there.

    Thanks,
    Rafael

    --
    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/

  2. Re: 2.6.25-rc6-git6: Reported regressions from 2.6.24

    Rafael J. Wysocki wrote:
    > Unresolved regressions
    > ----------------------
    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9412
    > Subject : Since commit 'x86: enable iommu_merge by default' (948062683004d13ca21c8c05ac052d387978a449) 2.6 is no go on SB600 AHCI
    > Submitter : Srihari Vijayaraghavan
    > Date : 2007-11-19 14:43 (124 days old)



    This one seems to imply that the workaround approved by AMD/ATI didn't
    work...

    (AMD folks CC'd...)

    Jeff


    --
    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/

  3. Re: 2.6.25-rc6-git6: Reported regressions from 2.6.24

    On Sat, 22 Mar 2008 02:59:47 +0100 "Rafael J. Wysocki" wrote:

    > Listed regressions statistics:
    >
    > Date Total Pending Unresolved
    > ----------------------------------------
    > 2008-03-22 159 35 31
    > 2008-03-17 148 38 30
    > 2008-03-16 146 42 35
    > 2008-03-14 145 45 39
    > 2008-03-12 143 51 41
    > 2008-03-11 141 58 43
    > 2008-03-10 138 66 47
    > 2008-03-03 115 65 49
    > 2008-02-25 90 51 39
    > 2008-02-17 61 45 37
    >
    > ...
    >
    > Date : 2007-11-19 14:43 (124 days old)
    > Date : 2008-02-12 14:34 (39 days old)
    > Date : 2008-02-12 12:46 (39 days old)
    > Date : 2008-02-13 10:30 (38 days old)
    > Date : 2008-02-13 12:25 (38 days old)
    > Date : 2008-02-15 04:51 (36 days old)
    > Date : 2008-02-17 06:28 (34 days old)
    > Date : 2008-02-17 09:36 (34 days old)
    > Date : 2008-02-18 11:56 (33 days old)
    > Date : 2008-02-20 09:10 (31 days old)
    > Date : 2008-02-19 12:59 (32 days old)
    > Date : 2008-02-22 10:36 (29 days old)
    > Date : 2008-02-20 08:47 (31 days old)
    > Date : 2008-02-20 16:01 (31 days old)
    > Date : 2008-02-23 18:55 (28 days old)
    > Date : 2008-02-23 18:55 (28 days old)
    > Date : 2008-02-27 (24 days old)
    > Date : 2008-03-02 20:00 (20 days old)
    > Date : 2008-02-28 11:25 (23 days old)
    > Date : 2008-03-05 03:26 (17 days old)
    > Date : 2008-03-12 12:02 (10 days old)
    > Date : 2008-03-14 05:47 (8 days old)
    > Date : 2008-03-17 16:45 (5 days old)
    > Date : 2008-03-20 13:13 (2 days old)
    > Date : 2008-03-20 07:05 (2 days old)
    > Date : 2008-03-21 02:01 (1 days old)
    > Date : 2008-03-21 11:42 (1 days old)
    > Date : 2008-03-21 20:03 (1 days old)
    > Date : 2008-03-21 17:18 (1 days old)
    > Date : 2008-03-20 18:41 (2 days old)
    > Date : 2008-03-21 23:35 (1 days old)



    --
    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/

  4. Re: 2.6.25-rc6-git6: Reported regressions from 2.6.24


    * Andrew Morton wrote:

    > > ...
    > >
    > > Date : 2007-11-19 14:43 (124 days old)


    btw., this one appears to be an accounting artifact: two regressions
    with similar (same?) symptoms in the same bugzilla. The first regression
    was resolved after 7 days, the second was reopened 10 days ago. (It
    could easily be about the same underlying (hw?) problem, but the
    regression window for users was very small.)

    Ingo
    --
    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/

  5. Re: 2.6.25-rc6-git6: Reported regressions from 2.6.24


    * Jeff Garzik wrote:

    >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9412
    >> Subject : Since commit 'x86: enable iommu_merge by default' (948062683004d13ca21c8c05ac052d387978a449) 2.6 is no go on SB600 AHCI
    >> Submitter : Srihari Vijayaraghavan
    >> Date : 2007-11-19 14:43 (124 days old)

    >
    > This one seems to imply that the workaround approved by AMD/ATI didn't
    > work...
    >
    > (AMD folks CC'd...)


    note, the 'Subject' is wrong, we resolved the original regression on
    2007-11-26, 7 days after it was reported. This is about a bug with
    similar symptoms, reopened 10 days ago. Jeff, could you please change
    the bugzilla entry so that it reflects that it's an SB600 problem?

    Ingo
    --
    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/

  6. Re: 2.6.25-rc6-git6: Reported regressions from 2.6.24

    On Sat, Mar 22, 2008 at 02:59:47AM +0100, Rafael J. Wysocki wrote:
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10271
    > Subject : dm raid1: bitops bug
    > Submitter : Heiko Carstens
    > Date : 2008-03-17 16:45 (5 days old)
    > References : http://lkml.org/lkml/2008/3/17/174
    > Handled-By : Alasdair G Kergon


    For this one a patch is available in -mm. Qouted patch can be seen
    via the lkml.org link above
    --
    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/

  7. ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

    Rafael J. Wysocki wrote:
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10080
    > Subject : 2.6.25-rc2: ohci1394 problem (MMIO broken)
    > Submitter : Thomas Meyer
    > Date : 2008-02-20 08:47 (31 days old)
    > References : http://lkml.org/lkml/2008/2/20/58
    > Handled-By : Stefan Richter


    This bug is alas an orphan. It is /not/ handled by me, because it is
    not an IEEE 1394 subsystem bug and I have no idea what to do about it.

    Note the following:

    - Several or all of ohci1394's MMIO reads return ~0 (all bits set
    to one) --- or 0 --- where different values are expected.

    - In http://lkml.org/lkml/2008/2/23/244 we get to see a
    WARNING: at arch/x86/mm/ioremap.c:137 __ioremap+0xa7/0x16a()
    which is "WARN_ON_ONCE(page_is_ram(pfn));".
    After that, the failures start.
    But before that, "Unknown symbol" messages pop up when ohci1394
    is loaded. These symbols are implemented by ieee1394 on which
    ohci1394 depends.

    More context from http://lkml.org/lkml/2008/2/23/244:

    > [ 199.908169] ath_pci: wifi0: Atheros 5424/2424: mem=0x94300000, irq=17


    ath_hal taints the kernel.

    > [ 847.318678] ohci1394: Unknown symbol hpsb_iso_wake
    > [ 847.318791] ohci1394: Unknown symbol hpsb_resume_host

    ....

    Some unexplained build problem.

    > [ 856.789954] ACPI: PCI Interrupt 0000:0c:03.0[A] -> GSI 19 (level,
    > low) -> IRQ 19
    > [ 856.790040] ------------[ cut here ]------------
    > [ 856.790044] WARNING: at arch/x86/mm/ioremap.c:137 __ioremap+0xa7/0x16a()
    > [ 856.790048] Modules linked in: ohci1394(+) ieee1394 wlan_wep
    > wlan_scan_sta ath_rate_sample ath_pci wlan ath_hal(P) firmware_class
    > fuse snd_seq snd_seq_device nls_iso8859_15 nls_cp850 vfat fat usbhid
    > appletouch applesmc input_polldev led_class dummy binfmt_misc tun
    > pktcdvd loop msr cpuid coretemp hwmon eeprom cpufreq_powersave
    > cpufreq_conservative acpi_cpufreq thermal ehci_hcd tpm_infineon i2c_i801
    > i2c_core tpm uhci_hcd usbcore tpm_bios processor ac battery sr_mod
    > rng_core iTCO_wdt button firewire_ohci firewire_core sg snd_hda_intel
    > snd_pcm snd_timer snd soundcore snd_page_alloc evdev intel_agp cdrom
    > [last unloaded: microcode]
    > [ 856.790119] Pid: 7140, comm: insmod Tainted: P 2.6.25-rc2 #115
    > [ 856.790125] [] warn_on_slowpath+0x40/0x4f
    > [ 856.790143] [] __wake_up+0x29/0x39
    > [ 856.790154] [] netlink_broadcast+0x26e/0x2af
    > [ 856.790169] [] kobject_uevent_env+0x33d/0x361
    > [ 856.790178] [] pci_mmcfg_write+0xc4/0xd5
    > [ 856.790187] [] raw_pci_write+0x3e/0x46
    > [ 856.790200] [] __ioremap+0xa7/0x16a
    > [ 856.790210] [] ohci1394_pci_probe+0x20c/0x5a6 [ohci1394]
    > [ 856.790226] [] pci_device_probe+0x36/0x55
    > [ 856.790236] [] driver_probe_device+0x9d/0x114

    ....
    > [ 856.790598] ---[ end trace 5b0384c17c339107 ]---
    > [ 856.943807] ohci1394: fw-host0: Get PHY Reg timeout
    > [0x00008400/0x00000000/100]


    MMIO read expected 0x00008400, got 0x00000000.

    ....
    > [ 921.826439] ohci1394: fw-host0: Unhandled interrupt(s) 0xfc7cfe0c


    MMIO read got random bits in the interrupt event register.

    ....
    > [ 994.471724] ohci1394: fw-host0: OHCI-1394 0.35 (PCI): IRQ=[19]
    > MMIO=[100000000-1000007ff] Max Packet=[65536] IR/IT contexts=[32/32]


    The values for Max Packet and IR/IT contexts came from bogus MMIO reads.

    Thomas, you wrote in http://lkml.org/lkml/2008/3/17/316 that the problem
    resurfaced.
    - Are the "Unknown symbol"s still there? These are not supposed to
    happen.
    - Is the "WARNING: at arch/x86/mm/ioremap.c" still there?
    - Can you reproduce it without the atheros driver?

    Rafael, no matter how it looks, this is not "handled-by: me". :-)
    I don't know nothing about kbuild nor about arch/x86/mm nor about WLAN.
    The IEEE 1394 bits in the bug of which I know something about are purely
    accidental.
    --
    Stefan Richter
    -=====-==--- --== =-==-
    http://arcgraph.de/sr/
    --
    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/

  8. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

    Stefan Richter schrieb:
    > Rafael J. Wysocki wrote:
    >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10080
    >> Subject : 2.6.25-rc2: ohci1394 problem (MMIO broken)
    >> Submitter : Thomas Meyer
    >> Date : 2008-02-20 08:47 (31 days old)
    >> References : http://lkml.org/lkml/2008/2/20/58
    >> Handled-By : Stefan Richter

    >
    > This bug is alas an orphan. It is /not/ handled by me, because it is
    > not an IEEE 1394 subsystem bug and I have no idea what to do about it.
    >
    > Note the following:
    >
    > - Several or all of ohci1394's MMIO reads return ~0 (all bits set
    > to one) --- or 0 --- where different values are expected.
    >
    > - In http://lkml.org/lkml/2008/2/23/244 we get to see a
    > WARNING: at arch/x86/mm/ioremap.c:137 __ioremap+0xa7/0x16a()
    > which is "WARN_ON_ONCE(page_is_ram(pfn));".
    > After that, the failures start.
    > But before that, "Unknown symbol" messages pop up when ohci1394
    > is loaded. These symbols are implemented by ieee1394 on which
    > ohci1394 depends.
    >
    > More context from http://lkml.org/lkml/2008/2/23/244:
    >
    >> [ 199.908169] ath_pci: wifi0: Atheros 5424/2424: mem=0x94300000, irq=17

    >
    > ath_hal taints the kernel.

    I removed the ath driver, see bug
    http://bugzilla.kernel.org/show_bug.cgi?id=10080.
    >
    >> [ 847.318678] ohci1394: Unknown symbol hpsb_iso_wake
    >> [ 847.318791] ohci1394: Unknown symbol hpsb_resume_host

    > ...
    >
    > Some unexplained build problem.

    I moved ohci1394.ko + ieee1394.ko file manually to avoid automatic
    loading. then i used insmod on those files and forgot to insmod ieee1394
    first. That's all. This is not related to the bug.
    >
    >> [ 856.789954] ACPI: PCI Interrupt 0000:0c:03.0[A] -> GSI 19 (level,
    >> low) -> IRQ 19
    >> [ 856.790040] ------------[ cut here ]------------
    >> [ 856.790044] WARNING: at arch/x86/mm/ioremap.c:137
    >> __ioremap+0xa7/0x16a()
    >> [ 856.790048] Modules linked in: ohci1394(+) ieee1394 wlan_wep
    >> wlan_scan_sta ath_rate_sample ath_pci wlan ath_hal(P) firmware_class
    >> fuse snd_seq snd_seq_device nls_iso8859_15 nls_cp850 vfat fat usbhid
    >> appletouch applesmc input_polldev led_class dummy binfmt_misc tun
    >> pktcdvd loop msr cpuid coretemp hwmon eeprom cpufreq_powersave
    >> cpufreq_conservative acpi_cpufreq thermal ehci_hcd tpm_infineon
    >> i2c_i801 i2c_core tpm uhci_hcd usbcore tpm_bios processor ac battery
    >> sr_mod rng_core iTCO_wdt button firewire_ohci firewire_core sg
    >> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc evdev
    >> intel_agp cdrom [last unloaded: microcode]
    >> [ 856.790119] Pid: 7140, comm: insmod Tainted: P 2.6.25-rc2
    >> #115
    >> [ 856.790125] [] warn_on_slowpath+0x40/0x4f
    >> [ 856.790143] [] __wake_up+0x29/0x39
    >> [ 856.790154] [] netlink_broadcast+0x26e/0x2af
    >> [ 856.790169] [] kobject_uevent_env+0x33d/0x361
    >> [ 856.790178] [] pci_mmcfg_write+0xc4/0xd5
    >> [ 856.790187] [] raw_pci_write+0x3e/0x46
    >> [ 856.790200] [] __ioremap+0xa7/0x16a
    >> [ 856.790210] [] ohci1394_pci_probe+0x20c/0x5a6 [ohci1394]
    >> [ 856.790226] [] pci_device_probe+0x36/0x55
    >> [ 856.790236] [] driver_probe_device+0x9d/0x114

    > ...
    >> [ 856.790598] ---[ end trace 5b0384c17c339107 ]---
    >> [ 856.943807] ohci1394: fw-host0: Get PHY Reg timeout
    >> [0x00008400/0x00000000/100]

    >
    > MMIO read expected 0x00008400, got 0x00000000.
    >
    > ...
    >> [ 921.826439] ohci1394: fw-host0: Unhandled interrupt(s) 0xfc7cfe0c

    >
    > MMIO read got random bits in the interrupt event register.
    >
    > ...
    >> [ 994.471724] ohci1394: fw-host0: OHCI-1394 0.35 (PCI): IRQ=[19]
    >> MMIO=[100000000-1000007ff] Max Packet=[65536] IR/IT contexts=[32/32]

    >
    > The values for Max Packet and IR/IT contexts came from bogus MMIO reads.
    >
    > Thomas, you wrote in http://lkml.org/lkml/2008/3/17/316 that the
    > problem resurfaced.
    > - Are the "Unknown symbol"s still there? These are not supposed to
    > happen.

    No. (See explanation above).
    > - Is the "WARNING: at arch/x86/mm/ioremap.c" still there?

    No. I couldn't reproduce this warning, yet.

    > - Can you reproduce it without the atheros driver?

    Yes.

    See http://bugzilla.kernel.org/show_bug.cgi?id=10080.

    >
    > Rafael, no matter how it looks, this is not "handled-by: me". :-)
    > I don't know nothing about kbuild nor about arch/x86/mm nor about WLAN.
    > The IEEE 1394 bits in the bug of which I know something about are
    > purely accidental.

    Seems so.


    --
    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/

  9. Re: 2.6.25-rc6-git6: Reported regressions from 2.6.24

    On Saturday, 22 of March 2008, Ingo Molnar wrote:
    >
    > * Andrew Morton wrote:
    >
    > > > ...
    > > >
    > > > Date : 2007-11-19 14:43 (124 days old)

    >
    > btw., this one appears to be an accounting artifact: two regressions
    > with similar (same?) symptoms in the same bugzilla. The first regression
    > was resolved after 7 days, the second was reopened 10 days ago. (It
    > could easily be about the same underlying (hw?) problem, but the
    > regression window for users was very small.)


    Hm, perhaps we should create another bugzilla entry for the problem
    described in http://bugzilla.kernel.org/show_bug.cgi?id=9412#c5.

    If that turns out to be a duplicate of bug #9412, it'll be easy to close.
    Otherwise, it's just _very_ confusing.

    Thanks,
    Rafael
    --
    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/

  10. Re: 2.6.25-rc6-git6: Reported regressions from 2.6.24

    On Saturday, 22 of March 2008, Heiko Carstens wrote:
    > On Sat, Mar 22, 2008 at 02:59:47AM +0100, Rafael J. Wysocki wrote:
    > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10271
    > > Subject : dm raid1: bitops bug
    > > Submitter : Heiko Carstens
    > > Date : 2008-03-17 16:45 (5 days old)
    > > References : http://lkml.org/lkml/2008/3/17/174
    > > Handled-By : Alasdair G Kergon

    >
    > For this one a patch is available in -mm. Qouted patch can be seen
    > via the lkml.org link above


    Well, I tried to find a link to this patch, but I gave up after some time.

    Please attach it to bug #10271 or put the link to it in there.

    Thanks,
    Rafael
    --
    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/

  11. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

    On Saturday, 22 of March 2008, Thomas Meyer wrote:
    > Stefan Richter schrieb:
    > > Rafael J. Wysocki wrote:
    > >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10080
    > >> Subject : 2.6.25-rc2: ohci1394 problem (MMIO broken)
    > >> Submitter : Thomas Meyer
    > >> Date : 2008-02-20 08:47 (31 days old)
    > >> References : http://lkml.org/lkml/2008/2/20/58
    > >> Handled-By : Stefan Richter

    > >
    > > This bug is alas an orphan. It is /not/ handled by me, because it is
    > > not an IEEE 1394 subsystem bug and I have no idea what to do about it.
    > >
    > > Note the following:
    > >
    > > - Several or all of ohci1394's MMIO reads return ~0 (all bits set
    > > to one) --- or 0 --- where different values are expected.
    > >
    > > - In http://lkml.org/lkml/2008/2/23/244 we get to see a
    > > WARNING: at arch/x86/mm/ioremap.c:137 __ioremap+0xa7/0x16a()
    > > which is "WARN_ON_ONCE(page_is_ram(pfn));".
    > > After that, the failures start.
    > > But before that, "Unknown symbol" messages pop up when ohci1394
    > > is loaded. These symbols are implemented by ieee1394 on which
    > > ohci1394 depends.
    > >
    > > More context from http://lkml.org/lkml/2008/2/23/244:
    > >
    > >> [ 199.908169] ath_pci: wifi0: Atheros 5424/2424: mem=0x94300000, irq=17

    > >
    > > ath_hal taints the kernel.

    > I removed the ath driver, see bug
    > http://bugzilla.kernel.org/show_bug.cgi?id=10080.
    > >
    > >> [ 847.318678] ohci1394: Unknown symbol hpsb_iso_wake
    > >> [ 847.318791] ohci1394: Unknown symbol hpsb_resume_host

    > > ...
    > >
    > > Some unexplained build problem.

    > I moved ohci1394.ko + ieee1394.ko file manually to avoid automatic
    > loading. then i used insmod on those files and forgot to insmod ieee1394
    > first. That's all. This is not related to the bug.
    > >
    > >> [ 856.789954] ACPI: PCI Interrupt 0000:0c:03.0[A] -> GSI 19 (level,
    > >> low) -> IRQ 19
    > >> [ 856.790040] ------------[ cut here ]------------
    > >> [ 856.790044] WARNING: at arch/x86/mm/ioremap.c:137
    > >> __ioremap+0xa7/0x16a()
    > >> [ 856.790048] Modules linked in: ohci1394(+) ieee1394 wlan_wep
    > >> wlan_scan_sta ath_rate_sample ath_pci wlan ath_hal(P) firmware_class
    > >> fuse snd_seq snd_seq_device nls_iso8859_15 nls_cp850 vfat fat usbhid
    > >> appletouch applesmc input_polldev led_class dummy binfmt_misc tun
    > >> pktcdvd loop msr cpuid coretemp hwmon eeprom cpufreq_powersave
    > >> cpufreq_conservative acpi_cpufreq thermal ehci_hcd tpm_infineon
    > >> i2c_i801 i2c_core tpm uhci_hcd usbcore tpm_bios processor ac battery
    > >> sr_mod rng_core iTCO_wdt button firewire_ohci firewire_core sg
    > >> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc evdev
    > >> intel_agp cdrom [last unloaded: microcode]
    > >> [ 856.790119] Pid: 7140, comm: insmod Tainted: P 2.6.25-rc2
    > >> #115
    > >> [ 856.790125] [] warn_on_slowpath+0x40/0x4f
    > >> [ 856.790143] [] __wake_up+0x29/0x39
    > >> [ 856.790154] [] netlink_broadcast+0x26e/0x2af
    > >> [ 856.790169] [] kobject_uevent_env+0x33d/0x361
    > >> [ 856.790178] [] pci_mmcfg_write+0xc4/0xd5
    > >> [ 856.790187] [] raw_pci_write+0x3e/0x46
    > >> [ 856.790200] [] __ioremap+0xa7/0x16a
    > >> [ 856.790210] [] ohci1394_pci_probe+0x20c/0x5a6 [ohci1394]
    > >> [ 856.790226] [] pci_device_probe+0x36/0x55
    > >> [ 856.790236] [] driver_probe_device+0x9d/0x114

    > > ...
    > >> [ 856.790598] ---[ end trace 5b0384c17c339107 ]---
    > >> [ 856.943807] ohci1394: fw-host0: Get PHY Reg timeout
    > >> [0x00008400/0x00000000/100]

    > >
    > > MMIO read expected 0x00008400, got 0x00000000.
    > >
    > > ...
    > >> [ 921.826439] ohci1394: fw-host0: Unhandled interrupt(s) 0xfc7cfe0c

    > >
    > > MMIO read got random bits in the interrupt event register.
    > >
    > > ...
    > >> [ 994.471724] ohci1394: fw-host0: OHCI-1394 0.35 (PCI): IRQ=[19]
    > >> MMIO=[100000000-1000007ff] Max Packet=[65536] IR/IT contexts=[32/32]

    > >
    > > The values for Max Packet and IR/IT contexts came from bogus MMIO reads.
    > >
    > > Thomas, you wrote in http://lkml.org/lkml/2008/3/17/316 that the
    > > problem resurfaced.
    > > - Are the "Unknown symbol"s still there? These are not supposed to
    > > happen.

    > No. (See explanation above).
    > > - Is the "WARNING: at arch/x86/mm/ioremap.c" still there?

    > No. I couldn't reproduce this warning, yet.
    >
    > > - Can you reproduce it without the atheros driver?

    > Yes.
    >
    > See http://bugzilla.kernel.org/show_bug.cgi?id=10080.
    >
    > >
    > > Rafael, no matter how it looks, this is not "handled-by: me". :-)
    > > I don't know nothing about kbuild nor about arch/x86/mm nor about WLAN.
    > > The IEEE 1394 bits in the bug of which I know something about are
    > > purely accidental.

    > Seems so.


    Yes, I tend to forget about it. I'll do my best to remember.

    Thanks,
    Rafael
    --
    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/

  12. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

    Thomas Meyer wrote:
    > Stefan Richter schrieb:
    >> - Several or all of ohci1394's MMIO reads return ~0 (all bits set
    >> to one) --- or 0 --- where different values are expected.
    >>
    >> - In http://lkml.org/lkml/2008/2/23/244 we get to see a
    >> WARNING: at arch/x86/mm/ioremap.c:137 __ioremap+0xa7/0x16a()
    >> which is "WARN_ON_ONCE(page_is_ram(pfn));".
    >> After that, the failures start.
    >> But before that, "Unknown symbol" messages pop up when ohci1394
    >> is loaded. These symbols are implemented by ieee1394 on which
    >> ohci1394 depends.

    ....
    >> Thomas, you wrote in http://lkml.org/lkml/2008/3/17/316 that the
    >> problem resurfaced.
    >> - Are the "Unknown symbol"s still there? These are not supposed to
    >> happen.

    > No. (See explanation above).
    >> - Is the "WARNING: at arch/x86/mm/ioremap.c" still there?

    > No. I couldn't reproduce this warning, yet.
    >
    >> - Can you reproduce it without the atheros driver?

    > Yes.
    >
    > See http://bugzilla.kernel.org/show_bug.cgi?id=10080.


    Thanks. Summary from today's bugzilla comments:
    No ioremap warning, but MMIO reads still give bogus values and let
    ohci1394 fail. ohci1394 still got the MMIO region 0x1'0000'0000 -
    0x1'0000'07ff, FWIW. The length of the region is correct, but its
    contents bogus.
    --
    Stefan Richter
    -=====-==--- --== =-==-
    http://arcgraph.de/sr/
    --
    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/

  13. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

    I wrote:
    > Thomas Meyer wrote:
    >> Stefan Richter schrieb:
    >>> - Is the "WARNING: at arch/x86/mm/ioremap.c" still there?

    >> No. I couldn't reproduce this warning, yet.
    >>
    >>> - Can you reproduce it without the atheros driver?

    >> Yes.
    >>
    >> See http://bugzilla.kernel.org/show_bug.cgi?id=10080.

    >
    > Thanks. Summary from today's bugzilla comments:
    > No ioremap warning, but MMIO reads still give bogus values and let
    > ohci1394 fail. ohci1394 still got the MMIO region 0x1'0000'0000 -
    > 0x1'0000'07ff, FWIW. The length of the region is correct, but its
    > contents bogus.


    Can an MMIO region reside above 0x1'0000'0000 on x86-32? ... Apparently
    yes, if CONFIG_RESOURCES_64BIT=y.

    From Thomas' dmesg:
    http://bugzilla.kernel.org/attachment.cgi?id=15397

    BIOS-provided physical RAM map:
    BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
    BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
    BIOS-e820: 00000000000ede00 - 0000000000100000 (reserved)
    BIOS-e820: 0000000000100000 - 000000007f0c8000 (usable)
    BIOS-e820: 000000007f0c8000 - 000000007f2c9000 (ACPI NVS)
    BIOS-e820: 000000007f2c9000 - 000000007feb9000 (ACPI data)
    BIOS-e820: 000000007feb9000 - 000000007feef000 (ACPI NVS)
    BIOS-e820: 000000007feef000 - 000000007ff00000 (ACPI data)
    BIOS-e820: 000000007ff00000 - 0000000080000000 (reserved)
    BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
    BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
    BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
    BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved)
    BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
    BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
    1136MB HIGHMEM available.
    896MB LOWMEM available.
    ....
    ACPI: RSDP 000FE020, 0024 (r2 APPLE )
    ACPI: XSDT 7FEFD120, 0074 (r1 APPLE Apple00 55 1000013)
    ACPI: FACP 7FEFB000, 00F4 (r3 APPLE Apple00 55 Loki 5F)
    ACPI: DSDT 7FEF0000, 48C0 (r1 APPLE MacBookP 10001 INTL 20050309)

    From Thomas' .config:
    http://bugzilla.kernel.org/attachment.cgi?id=15396
    CONFIG_RESOURCES_64BIT=y

    I have a Mac mini but run x86-64 on it. However, I've got another
    i945GM based PC with x86-32 and three OHCI-1394 controllers in it.
    I always had CONFIG_RESOURCES_64BIT switched off. I shall try
    CONFIG_RESOURCES_64BIT=y on that PC.

    Thomas, did you use CONFIG_RESOURCES_64BIT=y already under Linux 2.6.24?

    All, is there anything special that drivers need to take care of for
    CONFIG_RESOURCES_64BIT=y?

    We use resource_size_t ohci_base to request the MMIO region in
    drivers/ieee1394/ohci1394.c:hci1394_pci_probe(). And we use struct
    ti_ohci::void __iomem *registers to store the MMIO base we get from
    ioremap, and readl(ohci->registers + (int)offset) and writel((u32)data,
    ohci->registers + (int)offset) to peek and poke in them; see
    drivers/ieee1394/ohci1394.h.
    --
    Stefan Richter
    -=====-==--- --== =-==-
    http://arcgraph.de/sr/
    --
    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/

  14. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)



    On Sat, 22 Mar 2008, Stefan Richter wrote:
    >
    > Can an MMIO region reside above 0x1'0000'0000 on x86-32? ... Apparently yes,
    > if CONFIG_RESOURCES_64BIT=y.


    Hmm. It would only work if PAE (HIGHMEM64G) is enabled too.

    And obviously the hardware has to have working 64-bit BAR's.

    AND no, I don't think our x86-32 ioremap() actually works for this case,
    because while the resource data may have the full 64 bits, when the
    ioremap() happens it gets truncated to 32 bits.

    Ingo/Thomas - should ioremap*() perhaps take "resource_size_t" or a "u64"
    for the address (and then "__ioremap()" should probably take a PFN, not a
    physical address, and that one can remain just a "unsigned long"?)

    Has anybody ever had a working 64-bit BAR on x86? Ivan? Maybe I'm missing
    something..

    Linus
    --
    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/

  15. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

    Linus Torvalds wrote:
    >
    > Ingo/Thomas - should ioremap*() perhaps take "resource_size_t" or a "u64"
    > for the address (and then "__ioremap()" should probably take a PFN, not a
    > physical address, and that one can remain just a "unsigned long"?)
    >


    resource_size_t seems to make sense here. In the case when we have
    64-bit resources but no PAE support we should error our when the
    resource is out of range rather than silently fail.

    > Has anybody ever had a working 64-bit BAR on x86? Ivan? Maybe I'm missing
    > something..


    64-bit BAR, certainly. 64-bit BAR with a value beyond 4 GB I would find
    questionable at best... I suspect the answer is "no".

    -hpa


    --
    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/

  16. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

    On Sat, 22 Mar 2008, Linus Torvalds wrote:
    > On Sat, 22 Mar 2008, Stefan Richter wrote:
    > >
    > > Can an MMIO region reside above 0x1'0000'0000 on x86-32? ... Apparently yes,
    > > if CONFIG_RESOURCES_64BIT=y.

    >
    > Hmm. It would only work if PAE (HIGHMEM64G) is enabled too.
    >
    > And obviously the hardware has to have working 64-bit BAR's.
    >
    > AND no, I don't think our x86-32 ioremap() actually works for this case,
    > because while the resource data may have the full 64 bits, when the
    > ioremap() happens it gets truncated to 32 bits.
    >
    > Ingo/Thomas - should ioremap*() perhaps take "resource_size_t" or a "u64"
    > for the address (and then "__ioremap()" should probably take a PFN, not a
    > physical address, and that one can remain just a "unsigned long"?)


    Hmm. No idea. I look into that on monday (tomorrow is family
    day). Right now I'm too tired to provide any useful input.

    > Has anybody ever had a working 64-bit BAR on x86? Ivan? Maybe I'm missing
    > something..


    Same here.

    Thanks,

    tglx
    --
    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/

  17. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24) [Bug 10080]

    H. Peter Anvin wrote at
    http://bugzilla.kernel.org/show_bug.cgi?id=10080#c9 :
    > I'm confused about this. I looked at the original threads, and what really
    > stands out to me is that the original reporter had two drivers loaded for the
    > same hardware (firewire-ohci and ohci1394.) *In the best case* there is a
    > fundamental race condition there, meaning unpredictable behaviour would be the
    > norm.



    Hmm, right -- I didn't see this until now. Today's dmesg:
    http://bugzilla.kernel.org/attachmen...97&action=view
    [ 1.236587] firewire_ohci: Failed to remap registers
    [ 243.640549] ohci1394: fw-host0: Get PHY Reg timeout
    (etc.)

    However, the two drivers for the same device don't seem to be the
    problem. Looks like firewire-ohci was attempted to be bound to the
    controller much earlier than ohci1394. The error message means that
    firewire-ohci's pci_request_region() succeeded but pci_iomap() failed,
    hence the pci_driver.probe failed, hence firewire-ohci wasn't bound to
    the device, hence subsequent loading of ohci1394 (manually, I presume)
    was a valid action.

    IOW firewire-ohci was indeed already loaded, but not bound to the device
    because of the .probe failure; and ohci1394 was loaded much later.

    Same thing in the report in February:
    http://lkml.org/lkml/2008/2/23/244
    [ 1.326958] firewire_ohci: Failed to remap registers
    [ 856.943807] ohci1394: fw-host0: Get PHY Reg timeout
    (here: ohci1394 manually loaded by insmod)

    (Let's see if bugme-daemon captures this...)
    --
    Stefan Richter
    -=====-==--- --== =-==-
    http://arcgraph.de/sr/
    --
    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/

  18. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)



    On Sat, 22 Mar 2008, Linus Torvalds wrote:
    >
    > AND no, I don't think our x86-32 ioremap() actually works for this case,
    > because while the resource data may have the full 64 bits, when the
    > ioremap() happens it gets truncated to 32 bits.


    Does this patch make any difference?

    (ENTIRELY untested, I checked that it compiles on x86-64, but didn't even
    test a 32-bit build, I'm hoping whoever sees this issue can also fix up
    the inevitable small missed pieces)

    Linus

    ---
    arch/x86/mm/ioremap.c | 6 +++---
    include/asm-x86/io_32.h | 6 +++---
    include/asm-x86/io_64.h | 6 +++---
    lib/iomap.c | 2 +-
    4 files changed, 10 insertions(+), 10 deletions(-)

    diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
    index 8fe576b..4afaba0 100644
    --- a/arch/x86/mm/ioremap.c
    +++ b/arch/x86/mm/ioremap.c
    @@ -106,7 +106,7 @@ static int ioremap_change_attr(unsigned long vaddr, unsigned long size,
    * have to convert them into an offset in a page-aligned mapping, but the
    * caller shouldn't need to know that small detail.
    */
    -static void __iomem *__ioremap(unsigned long phys_addr, unsigned long size,
    +static void __iomem *__ioremap(resource_size_t phys_addr, unsigned long size,
    enum ioremap_mode mode)
    {
    unsigned long pfn, offset, last_addr, vaddr;
    @@ -193,13 +193,13 @@ static void __iomem *__ioremap(unsigned long phys_addr, unsigned long size,
    *
    * Must be freed with iounmap.
    */
    -void __iomem *ioremap_nocache(unsigned long phys_addr, unsigned long size)
    +void __iomem *ioremap_nocache(resource_size_t phys_addr, unsigned long size)
    {
    return __ioremap(phys_addr, size, IOR_MODE_UNCACHED);
    }
    EXPORT_SYMBOL(ioremap_nocache);

    -void __iomem *ioremap_cache(unsigned long phys_addr, unsigned long size)
    +void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
    {
    return __ioremap(phys_addr, size, IOR_MODE_CACHED);
    }
    diff --git a/include/asm-x86/io_32.h b/include/asm-x86/io_32.h
    index 58d2c45..d4d8fbd 100644
    --- a/include/asm-x86/io_32.h
    +++ b/include/asm-x86/io_32.h
    @@ -114,13 +114,13 @@ static inline void * phys_to_virt(unsigned long address)
    * If the area you are trying to map is a PCI BAR you should have a
    * look at pci_iomap().
    */
    -extern void __iomem *ioremap_nocache(unsigned long offset, unsigned long size);
    -extern void __iomem *ioremap_cache(unsigned long offset, unsigned long size);
    +extern void __iomem *ioremap_nocache(resource_size_t offset, unsigned long size);
    +extern void __iomem *ioremap_cache(resource_size_t offset, unsigned long size);

    /*
    * The default ioremap() behavior is non-cached:
    */
    -static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
    +static inline void __iomem *ioremap(resource_size_t offset, unsigned long size)
    {
    return ioremap_nocache(offset, size);
    }
    diff --git a/include/asm-x86/io_64.h b/include/asm-x86/io_64.h
    index f64a59c..db0be20 100644
    --- a/include/asm-x86/io_64.h
    +++ b/include/asm-x86/io_64.h
    @@ -158,13 +158,13 @@ extern void early_iounmap(void *addr, unsigned long size);
    * it's useful if some control registers are in such an area and write combining
    * or read caching is not desirable:
    */
    -extern void __iomem *ioremap_nocache(unsigned long offset, unsigned long size);
    -extern void __iomem *ioremap_cache(unsigned long offset, unsigned long size);
    +extern void __iomem *ioremap_nocache(resource_size_t offset, unsigned long size);
    +extern void __iomem *ioremap_cache(resource_size_t offset, unsigned long size);

    /*
    * The default ioremap() behavior is non-cached:
    */
    -static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
    +static inline void __iomem *ioremap(resource_size_t offset, unsigned long size)
    {
    return ioremap_nocache(offset, size);
    }
    diff --git a/lib/iomap.c b/lib/iomap.c
    index db004a9..dd6ca48 100644
    --- a/lib/iomap.c
    +++ b/lib/iomap.c
    @@ -256,7 +256,7 @@ EXPORT_SYMBOL(ioport_unmap);
    * */
    void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
    {
    - unsigned long start = pci_resource_start(dev, bar);
    + resource_size_t start = pci_resource_start(dev, bar);
    unsigned long len = pci_resource_len(dev, bar);
    unsigned long flags = pci_resource_flags(dev, bar);

    --
    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/

  19. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

    On Sat, Mar 22, 2008 at 2:59 PM, H. Peter Anvin wrote:
    > Linus Torvalds wrote:
    > >
    > > Ingo/Thomas - should ioremap*() perhaps take "resource_size_t" or a "u64"
    > > for the address (and then "__ioremap()" should probably take a PFN, not a
    > > physical address, and that one can remain just a "unsigned long"?)
    > >

    >
    > resource_size_t seems to make sense here. In the case when we have
    > 64-bit resources but no PAE support we should error our when the
    > resource is out of range rather than silently fail.
    >
    >
    > > Has anybody ever had a working 64-bit BAR on x86? Ivan? Maybe I'm missing
    > > something..

    >
    > 64-bit BAR, certainly. 64-bit BAR with a value beyond 4 GB I would find
    > questionable at best... I suspect the answer is "no".
    >

    Opteron system with coprocessor on socket or HTX slot. will use 64bit
    BAR above 4g and size is more than 4g too.

    YH
    --
    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/

  20. Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

    Yinghai Lu wrote:
    > Opteron system with coprocessor on socket or HTX slot. will use 64bit
    > BAR above 4g and size is more than 4g too.


    And it's working, with a 32-bit kernel?

    (64-bit, no problem, obviously.)

    -hpa
    --
    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/

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast