[Bug #12263] Sata soft reset filling log

[Bug #12263] Sata soft reset filling log

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.27.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
Subject		: Sata soft reset filling log
Submitter	: Justin Madru <bevicm@dslextreme.com>
Date		: 2008-12-13 2:07 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4

[Bug #12263] Sata soft reset filling log

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
Subject		: Sata soft reset filling log
Submitter	: Justin Madru <bevicm@dslextreme.com>
Date		: 2008-12-13 2:07 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4

Re: [Bug #12263] Sata soft reset filling log

[Justin Madru]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
> Subject		: Sata soft reset filling log
> Submitter	: Justin Madru <bevicm-QP1aEjBt37AFQeE35raUng@public.gmane.org>
> Date		: 2008-12-13 2:07 (30 days old)
> References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4
>
>
>
>   
Yes, I'm still seeing this on .28 and even on .29-rc1.
I checked again and couldn't trigger the regression on a .27 kernel (at 
least with my hardware and config).
So, I'm fairly confident that it's a regression, not just a bug that's 
always been there.

Re: [Bug #12263] Sata soft reset filling log

[Rafael J. Wysocki]

On Tuesday 13 January 2009, Justin Madru wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
> > Subject		: Sata soft reset filling log
> > Submitter	: Justin Madru <bevicm-QP1aEjBt37AFQeE35raUng@public.gmane.org>
> > Date		: 2008-12-13 2:07 (30 days old)
> > References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4
> >
> >
> >
> >   
> Yes, I'm still seeing this on .28 and even on .29-rc1.
> I checked again and couldn't trigger the regression on a .27 kernel (at 
> least with my hardware and config).
> So, I'm fairly confident that it's a regression, not just a bug that's 
> always been there.

Thanks for the update.

Rafael

[Bug #12263] Sata soft reset filling log

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
Subject		: Sata soft reset filling log
Submitter	: Justin Madru <bevicm@dslextreme.com>
Date		: 2008-12-13 2:07 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4

2.6.29-rc3-git6: Reported regressions 2.6.27 -> 2.6.28

[Rafael J. Wysocki]

This message contains a list of some regressions introduced between 2.6.27 and
2.6.28, 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 introduced between 2.6.27
and 2.6.28, 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.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-02-04      149       33          30
  2009-01-20      144       30          27
  2009-01-11      139       33          30
  2008-12-21      120       19          17
  2008-12-13      111       14          13
  2008-12-07      106       20          17
  2008-12-04      106       29          21
  2008-11-22       93       25          15
  2008-11-16       89       32          18
  2008-11-09       73       40          27
  2008-11-02       55       41          29
  2008-10-25       26       25          20



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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12619
Subject		: Regression 2.6.28 and last - boot failed
Submitter	: jan sonnek <ha2nny@gmail.com>
Date		: 2009-02-01 19:59 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=123351836213969&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12612
Subject		: hard lockup when interrupting cdda2wav
Submitter	: Matthias Reichl <hias@horus.com>
Date		: 2009-01-28 16:41 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=123316111415677&w=4
Handled-By	: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12559
Subject		: Huawei E169 doesn't work as mass storage anymore
Submitter	: kpalberg <kpalberg@gmail.com>
Date		: 2009-01-28 02:34 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12520
Subject		: Cannot boot 2.6.28 under Dell OptiPlex 960
Submitter	: Denis Scherbakov <denis_scherbakov@yahoo.com>
Date		: 2009-01-22 04:37 (14 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12500
Subject		: r8169: NETDEV WATCHDOG: eth0 (r8169): transmit timed out
Submitter	: Justin Piszcz <jpiszcz@lucidpixels.com>
Date		: 2009-01-13 21:19 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=123188160811322&w=4
Handled-By	: Francois Romieu <romieu@fr.zoreil.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12465
Subject		: KVM guests stalling on 2.6.28 (bisected)
Submitter	: Kevin Shanahan <kmshanah@ucwb.org.au>
Date		: 2009-01-17 03:37 (19 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12426
Subject		: TMDC Joystick no longer works in kernel 2.6.28
Submitter	: Andrew S. Johnson <andy@asjohnson.com>
Date		: 2009-01-10 21:53 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=123162486415366&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12421
Subject		: GPF on 2.6.28 &amp; 2.6.28-rc9-git3    e1000e / e1000 issues
Submitter	: Doug Bazarnic <doug@bazarnic.net>
Date		: 2009-01-09 21:26 (27 days old)
References	: http://marc.info/?l=linux-kernel&m=123153653120204&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12411
Subject		: 2.6.28: BUG in r8169
Submitter	: Andrey Vul <andrey.vul@gmail.com>
Date		: 2008-12-31 18:37 (36 days old)
References	: http://marc.info/?l=linux-kernel&m=123074869611409&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12409
Subject		: NULL pointer dereference at get_stats()
Submitter	: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date		: 2008-12-30 12:53 (37 days old)
References	: http://marc.info/?l=linux-kernel&m=123064167008695&w=4
Handled-By	: Frederik Deweerdt <frederik.deweerdt@xprog.eu>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12408
Subject		: Funny problem with 2.6.28: Kernel stalls
Submitter	: Michael Roth <mroth@nessie.de>
Date		: 2008-12-25 15:14 (42 days old)
References	: http://marc.info/?l=linux-kernel&m=123021931714282&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12407
Subject		: Kernel 2.6.28 regression: Hang after hibernate
Submitter	: Frank Groeneveld <frankgroeneveld@gmail.com>
Date		: 2008-12-28 20:34 (39 days old)
References	: http://marc.info/?l=linux-kernel&m=123049651906081&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12405
Subject		: oops in __bounce_end_io_read under kvm
Submitter	: Christoph Hellwig <hch@lst.de>
Date		: 2008-12-26 17:36 (41 days old)
References	: http://marc.info/?l=linux-kernel&m=123031303400676&w=4
Handled-By	: Jens Axboe <jens.axboe@oracle.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12404
Subject		: Oops in 2.6.28-rc9 and -rc8 -- mtrr issues / e1000e
Submitter	: Kernel <kernel@bazarnic.net>
Date		: 2008-12-22 9:37 (45 days old)
References	: http://marc.info/?l=linux-kernel&m=122993873320150&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12403
Subject		: TTY problem on linux-2.6.28-rc7
Submitter	: sasa sasa <sasak.1983@gmail.com>
Date		: 2008-12-22 4:23 (45 days old)
References	: http://marc.info/?l=linux-kernel&m=122991914600390&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12401
Subject		: 2.6.28 regression: xbacklight broken on ThinkPad X61s
Submitter	: Tino Keitel <tino.keitel@gmx.de>
Date		: 2009-01-05 8:39 (31 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=22c13f9d8179f4c9caecfcb60a95214562b9addc
References	: http://marc.info/?l=linux-kernel&m=123114479110314&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12395
Subject		: 2.6.28-rc9: oprofile regression
Submitter	: Tim Blechmann <tim@klingt.org>
Date		: 2008-12-21 14:23 (46 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b99170288421c79f0c2efa8b33e26e65f4bb7fb8
References	: http://marc.info/?l=linux-kernel&m=122986946614791&w=4
Handled-By	: Andi Kleen <ak@linux.intel.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12393
Subject		: debugging in dosemu causes lots of 'scheduling while atomic'
Submitter	: Michal Suchanek <hramrach@centrum.cz>
Date		: 2009-01-09 07:28 (27 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12391
Subject		: Processor does not go below C2 state until usb.autosuspend is enabled
Submitter	: Gergely Imreh <imrehg@gmail.com>
Date		: 2009-01-09 02:35 (27 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12337
Subject		: ~100 extra wakeups reported by powertop
Submitter	: Alberto Gonzalez <luis6674@yahoo.com>
Date		: 2008-12-31 12:25 (36 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12265
Subject		: FPU emulation broken in 2.6.28-rc8 ?
Submitter	: Rogier Wolff <R.E.Wolff@bitwizard.nl>
Date		: 2008-12-17 8:56 (50 days old)
References	: http://marc.info/?l=linux-kernel&m=122950463030747&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12264
Subject		: i915: switching from kwin in opengl mode to a VT then back to x11, x11 freezes
Submitter	: Caleb Cushing <xenoterracide@gmail.com>
Date		: 2008-12-16 11:40 (51 days old)
References	: http://marc.info/?l=linux-kernel&m=122942777030666&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
Subject		: Sata soft reset filling log
Submitter	: Justin Madru <bevicm@dslextreme.com>
Date		: 2008-12-13 2:07 (54 days old)
References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12224
Subject		: journal activity on inactive partition causes inactive harddrive spinup
Submitter	: C Sights <csights@fastmail.fm>
Date		: 2008-12-14 11:39 (53 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c87591b719737b4e91eb1a9fa8fd55a4ff1886d6
Handled-By	: Eric Sandeen <sandeen@redhat.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12209
Subject		: oldish top core dumps (in its meminfo() function)
Submitter	: Andreas Mohr <andi@lisas.de>
Date		: 2008-12-12 18:49 (55 days old)
References	: http://marc.info/?l=linux-kernel&m=122910784006472&w=4
		  http://marc.info/?l=linux-kernel&m=122907511319288&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12208
Subject		: uml is very slow on 2.6.28 host
Submitter	: Miklos Szeredi <miklos@szeredi.hu>
Date		: 2008-12-12 9:35 (55 days old)
References	: http://marc.info/?l=linux-kernel&m=122907463518593&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12160
Subject		: networking oops after resume from s2ram (2.6.28-rc6)
Submitter	: Marcin Slusarz <marcin.slusarz@gmail.com>
Date		: 2008-11-28 21:15 (69 days old)
References	: http://marc.info/?l=linux-kernel&m=122790701615723&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12159
Subject		: 2.6.28-rc6-git1 -- No sound produced from Intel HDA ALSA driver
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2008-11-27 20:33 (70 days old)
References	: http://marc.info/?l=linux-kernel&m=122781805620212&w=4
Handled-By	: Takashi Iwai <tiwai@suse.de>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12061
Subject		: snd_hda_intel: power_save: sound cracks on powerdown
Submitter	: Jens Weibler <bugzilla-kernel@jensthebrain.de>
Date		: 2008-11-18 12:07 (79 days old)
Handled-By	: Takashi Iwai <tiwai@suse.de>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11849
Subject		: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Submitter	: Kumar Gala <galak@kernel.crashing.org>
Date		: 2008-10-24 12:45 (104 days old)
References	: http://marc.info/?l=linux-kernel&m=122485245924125&w=4


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12614
Subject		: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e
Submitter	: Philipp Matthias Hahn <pmhahn@titan.lahn.de>
Date		: 2009-01-29 6:31 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=123321232825316&w=4
Handled-By	: Yinghai Lu <yinghai@kernel.org>
Patch		: http://marc.info/?l=linux-kernel&m=123330459229248&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12406
Subject		: 2.6.28 thinks that my PS/2 mouse is a touchpad
Submitter	: Alexander E. Patrakov <patrakov@gmail.com>
Date		: 2008-12-27 9:06 (40 days old)
References	: http://marc.info/?l=linux-kernel&m=123036893817280&w=4
Handled-By	: Arjan Opmeer <arjan@opmeer.net>
Patch		: http://marc.info/?l=linux-kernel&m=123092147703236&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12396
Subject		: hwinfo problem since 2.6.28
Submitter	: Beschorner Daniel <Daniel.Beschorner@facton.com>
Date		: 2009-01-06 8:53 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=123123277800835&w=4
Handled-By	: Suresh Siddha <suresh.b.siddha@intel.com>
Patch		: http://marc.info/?l=linux-kernel&m=123154005127497&w=4


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 introduced
between 2.6.27 and 2.6.28, unresolved as well as resolved, at:

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

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-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug #11849] default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11849
Subject		: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Submitter	: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date		: 2008-10-24 12:45 (104 days old)
References	: http://marc.info/?l=linux-kernel&m=122485245924125&w=4

[Bug #12061] snd_hda_intel: power_save: sound cracks on powerdown

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12061
Subject		: snd_hda_intel: power_save: sound cracks on powerdown
Submitter	: Jens Weibler <bugzilla-kernel-6hJTtV8wudIr9FUcG+3rRQ@public.gmane.org>
Date		: 2008-11-18 12:07 (79 days old)
Handled-By	: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>

[Bug #12159] 2.6.28-rc6-git1 -- No sound produced from Intel HDA ALSA driver

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12159
Subject		: 2.6.28-rc6-git1 -- No sound produced from Intel HDA ALSA driver
Submitter	: Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-11-27 20:33 (70 days old)
References	: http://marc.info/?l=linux-kernel&m=122781805620212&w=4
Handled-By	: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>

[Bug #12160] networking oops after resume from s2ram (2.6.28-rc6)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12160
Subject		: networking oops after resume from s2ram (2.6.28-rc6)
Submitter	: Marcin Slusarz <marcin.slusarz@gmail.com>
Date		: 2008-11-28 21:15 (69 days old)
References	: http://marc.info/?l=linux-kernel&m=122790701615723&w=4

[Bug #12208] uml is very slow on 2.6.28 host

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12208
Subject		: uml is very slow on 2.6.28 host
Submitter	: Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org>
Date		: 2008-12-12 9:35 (55 days old)
References	: http://marc.info/?l=linux-kernel&m=122907463518593&w=4

[Bug #12209] oldish top core dumps (in its meminfo() function)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12209
Subject		: oldish top core dumps (in its meminfo() function)
Submitter	: Andreas Mohr <andi-5+Cda9B46AM@public.gmane.org>
Date		: 2008-12-12 18:49 (55 days old)
References	: http://marc.info/?l=linux-kernel&m=122910784006472&w=4
		  http://marc.info/?l=linux-kernel&m=122907511319288&w=4

[Bug #12224] journal activity on inactive partition causes inactive harddrive spinup

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12224
Subject		: journal activity on inactive partition causes inactive harddrive spinup
Submitter	: C Sights <csights-97jfqw80gc6171pxa8y+qA@public.gmane.org>
Date		: 2008-12-14 11:39 (53 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c87591b719737b4e91eb1a9fa8fd55a4ff1886d6
Handled-By	: Eric Sandeen <sandeen-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

[Bug #12265] FPU emulation broken in 2.6.28-rc8 ?

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12265
Subject		: FPU emulation broken in 2.6.28-rc8 ?
Submitter	: Rogier Wolff <R.E.Wolff-bu/CaDbLbdHGjfRZg6uqBA@public.gmane.org>
Date		: 2008-12-17 8:56 (50 days old)
References	: http://marc.info/?l=linux-kernel&m=122950463030747&w=4

[Bug #12264] i915: switching from kwin in opengl mode to a VT then back to x11, x11 freezes

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12264
Subject		: i915: switching from kwin in opengl mode to a VT then back to x11, x11 freezes
Submitter	: Caleb Cushing <xenoterracide-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-12-16 11:40 (51 days old)
References	: http://marc.info/?l=linux-kernel&m=122942777030666&w=4

[Bug #12263] Sata soft reset filling log

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
Subject		: Sata soft reset filling log
Submitter	: Justin Madru <bevicm-QP1aEjBt37AFQeE35raUng@public.gmane.org>
Date		: 2008-12-13 2:07 (54 days old)
References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4

[Bug #12337] ~100 extra wakeups reported by powertop

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12337
Subject		: ~100 extra wakeups reported by powertop
Submitter	: Alberto Gonzalez <luis6674-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Date		: 2008-12-31 12:25 (36 days old)

[Bug #12391] Processor does not go below C2 state until usb.autosuspend is enabled

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12391
Subject		: Processor does not go below C2 state until usb.autosuspend is enabled
Submitter	: Gergely Imreh <imrehg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-01-09 02:35 (27 days old)

[Bug #12395] 2.6.28-rc9: oprofile regression

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12395
Subject		: 2.6.28-rc9: oprofile regression
Submitter	: Tim Blechmann <tim-xpEK/MU0Hawdnm+yROfE0A@public.gmane.org>
Date		: 2008-12-21 14:23 (46 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b99170288421c79f0c2efa8b33e26e65f4bb7fb8
References	: http://marc.info/?l=linux-kernel&m=122986946614791&w=4
Handled-By	: Andi Kleen <ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

[Bug #12393] debugging in dosemu causes lots of 'scheduling while atomic'

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12393
Subject		: debugging in dosemu causes lots of 'scheduling while atomic'
Submitter	: Michal Suchanek <hramrach-aRb0bU7PRFPrBKCeMvbIDA@public.gmane.org>
Date		: 2009-01-09 07:28 (27 days old)

[Bug #12396] hwinfo problem since 2.6.28

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12396
Subject		: hwinfo problem since 2.6.28
Submitter	: Beschorner Daniel <Daniel.Beschorner-cdG02ZADnvLQT0dZR+AlfA@public.gmane.org>
Date		: 2009-01-06 8:53 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=123123277800835&w=4
Handled-By	: Suresh Siddha <suresh.b.siddha-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=123154005127497&w=4

[Bug #12401] 2.6.28 regression: xbacklight broken on ThinkPad X61s

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12401
Subject		: 2.6.28 regression: xbacklight broken on ThinkPad X61s
Submitter	: Tino Keitel <tino.keitel-Mmb7MZpHnFY@public.gmane.org>
Date		: 2009-01-05 8:39 (31 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=22c13f9d8179f4c9caecfcb60a95214562b9addc
References	: http://marc.info/?l=linux-kernel&m=123114479110314&w=4

[Bug #12406] 2.6.28 thinks that my PS/2 mouse is a touchpad

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12406
Subject		: 2.6.28 thinks that my PS/2 mouse is a touchpad
Submitter	: Alexander E. Patrakov <patrakov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-12-27 9:06 (40 days old)
References	: http://marc.info/?l=linux-kernel&m=123036893817280&w=4
Handled-By	: Arjan Opmeer <arjan-OssVvNj1wBysTnJN9+BGXg@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=123092147703236&w=4

[Bug #12403] TTY problem on linux-2.6.28-rc7

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12403
Subject		: TTY problem on linux-2.6.28-rc7
Submitter	: sasa sasa <sasak.1983-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-12-22 4:23 (45 days old)
References	: http://marc.info/?l=linux-kernel&m=122991914600390&w=4

[Bug #12405] oops in __bounce_end_io_read under kvm

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12405
Subject		: oops in __bounce_end_io_read under kvm
Submitter	: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Date		: 2008-12-26 17:36 (41 days old)
References	: http://marc.info/?l=linux-kernel&m=123031303400676&w=4
Handled-By	: Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>

[Bug #12404] Oops in 2.6.28-rc9 and -rc8 -- mtrr issues / e1000e

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12404
Subject		: Oops in 2.6.28-rc9 and -rc8 -- mtrr issues / e1000e
Submitter	: Kernel <kernel-nOyj/A09A+/k1uMJSBkQmQ@public.gmane.org>
Date		: 2008-12-22 9:37 (45 days old)
References	: http://marc.info/?l=linux-kernel&m=122993873320150&w=4

[Bug #12408] Funny problem with 2.6.28: Kernel stalls

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12408
Subject		: Funny problem with 2.6.28: Kernel stalls
Submitter	: Michael Roth <mroth-+8Z3Oe2AQjqzQB+pC5nmwQ@public.gmane.org>
Date		: 2008-12-25 15:14 (42 days old)
References	: http://marc.info/?l=linux-kernel&m=123021931714282&w=4

[Bug #12407] Kernel 2.6.28 regression: Hang after hibernate

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12407
Subject		: Kernel 2.6.28 regression: Hang after hibernate
Submitter	: Frank Groeneveld <frankgroeneveld-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-12-28 20:34 (39 days old)
References	: http://marc.info/?l=linux-kernel&m=123049651906081&w=4

[Bug #12409] NULL pointer dereference at get_stats()

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12409
Subject		: NULL pointer dereference at get_stats()
Submitter	: Tetsuo Handa <penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org>
Date		: 2008-12-30 12:53 (37 days old)
References	: http://marc.info/?l=linux-kernel&m=123064167008695&w=4
Handled-By	: Frederik Deweerdt <frederik.deweerdt-kjvbsxwSFqI@public.gmane.org>

[Bug #12411] 2.6.28: BUG in r8169

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12411
Subject		: 2.6.28: BUG in r8169
Submitter	: Andrey Vul <andrey.vul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2008-12-31 18:37 (36 days old)
References	: http://marc.info/?l=linux-kernel&m=123074869611409&w=4

[Bug #12426] TMDC Joystick no longer works in kernel 2.6.28

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12426
Subject		: TMDC Joystick no longer works in kernel 2.6.28
Submitter	: Andrew S. Johnson <andy-9eXmkf4BiQ2aMJb+Lgu22Q@public.gmane.org>
Date		: 2009-01-10 21:53 (26 days old)
References	: http://marc.info/?l=linux-kernel&m=123162486415366&w=4

[Bug #12465] KVM guests stalling on 2.6.28 (bisected)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12465
Subject		: KVM guests stalling on 2.6.28 (bisected)
Submitter	: Kevin Shanahan <kmshanah-biM/RbsGxha6c6uEtOJ/EA@public.gmane.org>
Date		: 2009-01-17 03:37 (19 days old)

[Bug #12500] r8169: NETDEV WATCHDOG: eth0 (r8169): transmit timed out

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12500
Subject		: r8169: NETDEV WATCHDOG: eth0 (r8169): transmit timed out
Submitter	: Justin Piszcz <jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org>
Date		: 2009-01-13 21:19 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=123188160811322&w=4
Handled-By	: Francois Romieu <romieu-W8zweXLXuWQS+FvcfC7Uqw@public.gmane.org>

[Bug #12520] Cannot boot 2.6.28 under Dell OptiPlex 960

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12520
Subject		: Cannot boot 2.6.28 under Dell OptiPlex 960
Submitter	: Denis Scherbakov <denis_scherbakov-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Date		: 2009-01-22 04:37 (14 days old)

[Bug #12559] Huawei E169 doesn't work as mass storage anymore

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12559
Subject		: Huawei E169 doesn't work as mass storage anymore
Submitter	: kpalberg <kpalberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-01-28 02:34 (8 days old)

[Bug #12612] hard lockup when interrupting cdda2wav

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12612
Subject		: hard lockup when interrupting cdda2wav
Submitter	: Matthias Reichl <hias-vtPv7MOkFPkAvxtiuMwx3w@public.gmane.org>
Date		: 2009-01-28 16:41 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=123316111415677&w=4
Handled-By	: FUJITA Tomonori <fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>

[Bug #12614] WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12614
Subject		: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e
Submitter	: Philipp Matthias Hahn <pmhahn-u4khhh1J0LzF41mA0N3lWw@public.gmane.org>
Date		: 2009-01-29 6:31 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=123321232825316&w=4
Handled-By	: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=123330459229248&w=4

[Bug #12619] Regression 2.6.28 and last - boot failed

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12619
Subject		: Regression 2.6.28 and last - boot failed
Submitter	: jan sonnek <ha2nny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2009-02-01 19:59 (4 days old)
References	: http://marc.info/?l=linux-kernel&m=123351836213969&w=4

Re: [Bug #12159] 2.6.28-rc6-git1 -- No sound produced from Intel HDA ALSA driver

[Miles Lane]

This bug is fixed in Linus' tree, afaict.

On Wed, Feb 4, 2009 at 5:58 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12159
> Subject         : 2.6.28-rc6-git1 -- No sound produced from Intel HDA ALSA driver
> Submitter       : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date            : 2008-11-27 20:33 (70 days old)
> References      : http://marc.info/?l=linux-kernel&m=122781805620212&w=4
> Handled-By      : Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>
>
>
>

Re: [Bug #12426] TMDC Joystick no longer works in kernel 2.6.28

[Jiri Kosina]

On Wed, 4 Feb 2009, Rafael J. Wysocki wrote:

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12426
> Subject		: TMDC Joystick no longer works in kernel 2.6.28
> Submitter	: Andrew S. Johnson <andy-9eXmkf4BiQ2aMJb+Lgu22Q@public.gmane.org>
> Date		: 2009-01-10 21:53 (26 days old)
> References	: http://marc.info/?l=linux-kernel&m=123162486415366&w=4

I asked [1] the Submitter some time ago to check whether reverting a 
particular commit fixes the issue, but never heard back.

[1] http://lkml.org/lkml/2009/1/26/70

-- 
Jiri Kosina
SUSE Labs

Re: [Bug #12396] hwinfo problem since 2.6.28

[Beschorner Daniel]

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28.  Please verify if it 
> still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12396
> Subject		: hwinfo problem since 2.6.28
> Submitter	: Beschorner Daniel <Daniel.Beschorner-cdG02ZADnvLQT0dZR+AlfA@public.gmane.org>
> Date		: 2009-01-06 8:53 (30 days old)
> References	: http://marc.info/?l=linux-kernel&m=123123277800835&w=4
> Handled-By	: Suresh Siddha <suresh.b.siddha-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Patch		: http://marc.info/?l=linux-kernel&m=123154005127497&w=4

Fixed with 2.6.28.3.

Daniel

Re: [Bug #12159] 2.6.28-rc6-git1 -- No sound produced from Intel HDA ALSA driver

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Miles Lane wrote:
> This bug is fixed in Linus' tree, afaict.

Closed already.

Thanks,
Rafael


> On Wed, Feb 4, 2009 at 5:58 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12159
> > Subject         : 2.6.28-rc6-git1 -- No sound produced from Intel HDA ALSA driver
> > Submitter       : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date            : 2008-11-27 20:33 (70 days old)
> > References      : http://marc.info/?l=linux-kernel&m=122781805620212&w=4
> > Handled-By      : Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>

Re: [Bug #12396] hwinfo problem since 2.6.28

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Beschorner Daniel wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28.  Please verify if it 
> > still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12396
> > Subject		: hwinfo problem since 2.6.28
> > Submitter	: Beschorner Daniel <Daniel.Beschorner-cdG02ZADnvLQT0dZR+AlfA@public.gmane.org>
> > Date		: 2009-01-06 8:53 (30 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123123277800835&w=4
> > Handled-By	: Suresh Siddha <suresh.b.siddha-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Patch		: http://marc.info/?l=linux-kernel&m=123154005127497&w=4
> 
> Fixed with 2.6.28.3.

Thanks, closed.

Rafael

Re: [Bug #12426] TMDC Joystick no longer works in kernel 2.6.28

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Jiri Kosina wrote:
> On Wed, 4 Feb 2009, Rafael J. Wysocki wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12426
> > Subject		: TMDC Joystick no longer works in kernel 2.6.28
> > Submitter	: Andrew S. Johnson <andy-9eXmkf4BiQ2aMJb+Lgu22Q@public.gmane.org>
> > Date		: 2009-01-10 21:53 (26 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123162486415366&w=4
> 
> I asked [1] the Submitter some time ago to check whether reverting a 
> particular commit fixes the issue, but never heard back.
> 
> [1] http://lkml.org/lkml/2009/1/26/70

Rejected as "insufficient data" and closed.

Thanks,
Rafael

Re: [Bug #12224] journal activity on inactive partition causes inactive harddrive spinup

[Theodore Tso]

On Wed, Feb 04, 2009 at 11:58:33AM +0100, Rafael J. Wysocki wrote:
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12224
> Subject		: journal activity on inactive partition causes inactive harddrive spinup
> Submitter	: C Sights <csights-97jfqw80gc6171pxa8y+qA@public.gmane.org>
> Date		: 2008-12-14 11:39 (53 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c87591b719737b4e91eb1a9fa8fd55a4ff1886d6
> Handled-By	: Eric Sandeen <sandeen-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Patches against ext3 have been posted by Jan Kara and have been sucked
into the mm tree.  I don't know if Andrew is planning on waiting until
the next merge window, or is planning on pushing it sooner given that
it is a regression.  (These supercede the ones currently posted by
Eric in the BZ entry.)

Similar patches have been posted against ext4, and I will be handling
them in the ext4 tree.

						- Ted

Re: [Bug #12224] journal activity on inactive partition causes inactive harddrive spinup

[Andrew Morton]

On Wed, 4 Feb 2009 21:00:13 -0500 Theodore Tso <tytso-3s7WtUTddSA@public.gmane.org> wrote:

> On Wed, Feb 04, 2009 at 11:58:33AM +0100, Rafael J. Wysocki wrote:
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12224
> > Subject		: journal activity on inactive partition causes inactive harddrive spinup
> > Submitter	: C Sights <csights-97jfqw80gc6171pxa8y+qA@public.gmane.org>
> > Date		: 2008-12-14 11:39 (53 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c87591b719737b4e91eb1a9fa8fd55a4ff1886d6
> > Handled-By	: Eric Sandeen <sandeen-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> 
> Patches against ext3 have been posted by Jan Kara and have been sucked
> into the mm tree.  I don't know if Andrew is planning on waiting until
> the next merge window, or is planning on pushing it sooner given that
> it is a regression.

Yes, I have jbd-fix-return-value-of-journal_start_commit.patch and
revert-ext3-wait-on-all-pending-commits-in-ext3_sync_fs.patch queued
for 2.6.29.

The secret algorithm for determining this is to peek in the series file
(http://userweb.kernel.org/~akpm/mmotm/series) and see where I positioned the
patch:

   #
-> # more 2.6.29 queue:
   #
   # me:
   #
   migration-migrate_vmas-should-check-vma.patch
   rtc-update-maintainership-of-pxa-rtc-driver.patch
   lxfb-properly-alloc-cmap-in-all-cases-and-dont-leak-the-memory.patch
   gxfb-properly-alloc-cmap-and-plug-cmap-leak.patch
   gx1fb-properly-alloc-cmap-and-plug-cmap-leak.patch
   mm-fix-dirty_bytes-dirty_background_bytes-sysctls-on-64bit-arches.patch
   mm-fix-dirty_bytes-dirty_background_bytes-sysctls-on-64bit-arches-fix.patch
-> jbd-fix-return-value-of-journal_start_commit.patch
-> revert-ext3-wait-on-all-pending-commits-in-ext3_sync_fs.patch
   writeback-fix-nr_to_write-counter.patch
   
   

Re: [Bug #12393] debugging in dosemu causes lots of 'scheduling while atomic'

[Michal Suchanek]

As I said earlier I have received a patch that I applied locally and
that fixes the problem.

As to if and when the patch actually appears in the kernel is out of
my control, and nobody told me that it was applied.

If you believe it was applied to a kernel version that is readily
available for download I am wiling to test such version.

Thanks

Michal

2009/2/4 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12393
> Subject         : debugging in dosemu causes lots of 'scheduling while atomic'
> Submitter       : Michal Suchanek <hramrach-aRb0bU7PRFPrBKCeMvbIDA@public.gmane.org>
> Date            : 2009-01-09 07:28 (27 days old)
>
>
>

Re: [Bug #12612] hard lockup when interrupting cdda2wav

[Matthias Reichl]

On Wed, Feb 04, 2009 at 11:58:51AM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12612
> Subject		: hard lockup when interrupting cdda2wav
> Submitter	: Matthias Reichl <hias-vtPv7MOkFPkAvxtiuMwx3w@public.gmane.org>
> Date		: 2009-01-28 16:41 (8 days old)
> References	: http://marc.info/?l=linux-kernel&m=123316111415677&w=4
> Handled-By	: FUJITA Tomonori <fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>

This bug is still present in 2.6.28.3.

so long,

Hias

=============================================
[ INFO: possible recursive locking detected ]
2.6.28.3-dbg #1
---------------------------------------------
swapper/0 is trying to acquire lock:
 (&q->__queue_lock){.+..}, at: [<ffffffff8040e5f5>] blk_put_request+0x25/0x60

but task is already holding lock:
 (&q->__queue_lock){.+..}, at: [<ffffffff8040e4da>] blk_end_io+0x5a/0xa0

other info that might help us debug this:
1 lock held by swapper/0:
 #0:  (&q->__queue_lock){.+..}, at: [<ffffffff8040e4da>] blk_end_io+0x5a/0xa0

stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.28.3-dbg #1
Call Trace:
 <IRQ>  [<ffffffff8026cc87>] __lock_acquire+0x1797/0x1930
 [<ffffffff806abd7b>] error_exit+0x29/0xa9
 [<ffffffff80521e20>] sg_rq_end_io+0x0/0x2e0
 [<ffffffff8026ceba>] lock_acquire+0x9a/0xe0
 [<ffffffff8040e5f5>] blk_put_request+0x25/0x60
 [<ffffffff806ab763>] _spin_lock_irqsave+0x43/0x90
 [<ffffffff8040e5f5>] blk_put_request+0x25/0x60
 [<ffffffff8040e5f5>] blk_put_request+0x25/0x60
 [<ffffffff80520974>] sg_finish_rem_req+0xa4/0x100
 [<ffffffff80522098>] sg_rq_end_io+0x278/0x2e0
 [<ffffffff8040e281>] end_that_request_last+0x61/0x260
 [<ffffffff8040e4e8>] blk_end_io+0x68/0xa0
 [<ffffffff80508061>] scsi_end_request+0x41/0xd0
 [<ffffffff80508750>] scsi_io_completion+0x130/0x470
 [<ffffffff804133e5>] blk_done_softirq+0x75/0x90
 [<ffffffff802488ab>] __do_softirq+0x9b/0x180
 [<ffffffff80213df3>] native_sched_clock+0x13/0x70
 [<ffffffff8020d6ec>] call_softirq+0x1c/0x30
 [<ffffffff8020f175>] do_softirq+0x65/0xa0
 [<ffffffff80248345>] irq_exit+0xa5/0xb0
 [<ffffffff8020f467>] do_IRQ+0x107/0x1d0
 [<ffffffff8020c7fb>] ret_from_intr+0x0/0xf
 <EOI>  [<ffffffff80214ba6>] mwait_idle+0x56/0x60
 [<ffffffff80214b9d>] mwait_idle+0x4d/0x60
 [<ffffffff8020b353>] cpu_idle+0x63/0xc0

Re: [Bug #12393] debugging in dosemu causes lots of 'scheduling while atomic'

[Rafael J. Wysocki]

On Thursday 05 February 2009, Michal Suchanek wrote:
> As I said earlier I have received a patch that I applied locally and
> that fixes the problem.
> 
> As to if and when the patch actually appears in the kernel is out of
> my control, and nobody told me that it was applied.
> 
> If you believe it was applied to a kernel version that is readily
> available for download I am wiling to test such version.

I don't at the moment.

Can you send me a URL to the patch, please?

Rafael

Re: [Bug #12612] hard lockup when interrupting cdda2wav

[Rafael J. Wysocki]

On Thursday 05 February 2009, Matthias Reichl wrote:
> On Wed, Feb 04, 2009 at 11:58:51AM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12612
> > Subject		: hard lockup when interrupting cdda2wav
> > Submitter	: Matthias Reichl <hias@horus.com>
> > Date		: 2009-01-28 16:41 (8 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123316111415677&w=4
> > Handled-By	: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> 
> This bug is still present in 2.6.28.3.
> 
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.28.3-dbg #1
> ---------------------------------------------
> swapper/0 is trying to acquire lock:
>  (&q->__queue_lock){.+..}, at: [<ffffffff8040e5f5>] blk_put_request+0x25/0x60
> 
> but task is already holding lock:
>  (&q->__queue_lock){.+..}, at: [<ffffffff8040e4da>] blk_end_io+0x5a/0xa0
> 
> other info that might help us debug this:
> 1 lock held by swapper/0:
>  #0:  (&q->__queue_lock){.+..}, at: [<ffffffff8040e4da>] blk_end_io+0x5a/0xa0
> 
> stack backtrace:
> Pid: 0, comm: swapper Not tainted 2.6.28.3-dbg #1
> Call Trace:
>  <IRQ>  [<ffffffff8026cc87>] __lock_acquire+0x1797/0x1930
>  [<ffffffff806abd7b>] error_exit+0x29/0xa9
>  [<ffffffff80521e20>] sg_rq_end_io+0x0/0x2e0
>  [<ffffffff8026ceba>] lock_acquire+0x9a/0xe0
>  [<ffffffff8040e5f5>] blk_put_request+0x25/0x60
>  [<ffffffff806ab763>] _spin_lock_irqsave+0x43/0x90
>  [<ffffffff8040e5f5>] blk_put_request+0x25/0x60
>  [<ffffffff8040e5f5>] blk_put_request+0x25/0x60
>  [<ffffffff80520974>] sg_finish_rem_req+0xa4/0x100
>  [<ffffffff80522098>] sg_rq_end_io+0x278/0x2e0
>  [<ffffffff8040e281>] end_that_request_last+0x61/0x260
>  [<ffffffff8040e4e8>] blk_end_io+0x68/0xa0
>  [<ffffffff80508061>] scsi_end_request+0x41/0xd0
>  [<ffffffff80508750>] scsi_io_completion+0x130/0x470
>  [<ffffffff804133e5>] blk_done_softirq+0x75/0x90
>  [<ffffffff802488ab>] __do_softirq+0x9b/0x180
>  [<ffffffff80213df3>] native_sched_clock+0x13/0x70
>  [<ffffffff8020d6ec>] call_softirq+0x1c/0x30
>  [<ffffffff8020f175>] do_softirq+0x65/0xa0
>  [<ffffffff80248345>] irq_exit+0xa5/0xb0
>  [<ffffffff8020f467>] do_IRQ+0x107/0x1d0
>  [<ffffffff8020c7fb>] ret_from_intr+0x0/0xf
>  <EOI>  [<ffffffff80214ba6>] mwait_idle+0x56/0x60
>  [<ffffffff80214b9d>] mwait_idle+0x4d/0x60
>  [<ffffffff8020b353>] cpu_idle+0x63/0xc0

Thanks for the update.

Rafael

Re: [Bug #12393] debugging in dosemu causes lots of 'scheduling while atomic'

[Ray Lee]

On Thu, Feb 5, 2009 at 8:09 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Thursday 05 February 2009, Michal Suchanek wrote:
>> As I said earlier I have received a patch that I applied locally and
>> that fixes the problem.
>>
>> As to if and when the patch actually appears in the kernel is out of
>> my control, and nobody told me that it was applied.
>>
>> If you believe it was applied to a kernel version that is readily
>> available for download I am wiling to test such version.
>
> I don't at the moment.
>
> Can you send me a URL to the patch, please?

http://lkml.org/lkml/2009/1/13/445

Re: [Bug #12465] KVM guests stalling on 2.6.28 (bisected)

[Kevin Shanahan]

On Wed, 2009-02-04 at 11:58 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
> 
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> be listed and let me know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12465
> Subject		: KVM guests stalling on 2.6.28 (bisected)
> Submitter	: Kevin Shanahan <kmshanah-biM/RbsGxha6c6uEtOJ/EA@public.gmane.org>
> Date		: 2009-01-17 03:37 (19 days old)

Yes, this should still be listed.

Please remove kmshanah-IiIpDuVlHfMLO379cgqW9odd74u8MsAO@public.gmane.org from the CC list.

Thanks,
Kevin.

Re: [Bug #12465] KVM guests stalling on 2.6.28 (bisected)

[Rafael J. Wysocki]

On Thursday 05 February 2009, Kevin Shanahan wrote:
> On Wed, 2009-02-04 at 11:58 +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12465
> > Subject		: KVM guests stalling on 2.6.28 (bisected)
> > Submitter	: Kevin Shanahan <kmshanah-biM/RbsGxha6c6uEtOJ/EA@public.gmane.org>
> > Date		: 2009-01-17 03:37 (19 days old)
> 
> Yes, this should still be listed.

Thanks for the update.
 
> Please remove kmshanah-IiIpDuVlHfMLO379cgqW9odd74u8MsAO@public.gmane.org from the CC list.

It gets added because it is present in the Author: field in
http://bugzilla.kernel.org/show_bug.cgi?id=12465#c5

This is how the script works, sorry for the inconvenience.

Rafael


> 
> Thanks,
> Kevin.
> 
> 
> 
> 


-- 
Everyone knows that debugging is twice as hard as writing a program
in the first place.  So if you're as clever as you can be when you write it,
how will you ever debug it? --- Brian Kernighan

Re: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e

[Philipp Matthias Hahn]

Hello!

On Thu, Jan 29, 2009 at 10:53:40PM -0800, Yinghai Lu wrote:
> can not find the reason why the WOL doesn't work...
> 
> please post
> 1. boot log for just after AC is pluged-in... ===> you should have
> "nv_probe: set workaround bit for reversed mac addr"
> 2. and boot log after boot from WOL...==> you have have "nv_probe: set
> workaround bit for reversed mac addr" too.

On Wed, Feb 04, 2009 at 11:58:53AM +0100, Rafael J. Wysocki wrote:
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12614
> Subject		: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e
> Submitter	: Philipp Matthias Hahn <pmhahn@titan.lahn.de>
> Date		: 2009-01-29 6:31 (7 days old)
> References	: http://marc.info/?l=linux-kernel&m=123321232825316&w=4
> Handled-By	: Yinghai Lu <yinghai@kernel.org>
> Patch		: http://marc.info/?l=linux-kernel&m=123330459229248&w=4

Strage, at the moment I can't seem to reproduce the problem. I've
switched back to the version of 2.6.28.3 and now it seems to work.
I'll continue with tesing.

Some additional data:
The BIOS-upgrade tool (Afud408.exe) resets the MAC address. I had to run
the tool a second time to re-programm the MAC-address using its /M
option. I useed the unreversed MAC-address back than.
I also tried the reversed address once, but after that forcedeth.c
complained about a wrong MAC-address.

If I completely turn off the power (pull the plug), WOL doesn't work,
even when it's enabled in the BIOS.

Only after I'v started Linux, do "echo NMAC > /proc/acpi/wakeup" and
"ethtool -s eth0 wol g" does it work again.

Nether the less here's the output of dmesg:
        forcedeth: Reverse Engineered nFoce ethernet driver. Version 0.61.
        ACPI: PCI Interrupt Link [LMAC] enables at IRQ 23
        forcedeth: 0000:00:14.0: PCI INT A -> Link[LMAC] -> GSI 23 (level, low) -> IRQ 23
        forcedeth: 0000:00:14.0: setting latency timer to 64
*       nv_probe: MAC_ADDR_REV ELSE
        nv_probe: set workaround bit for reversed mac addr
        forcedeth: 0000:00:14.0: ifname eth0, PHY OUI 0x732 @ 1, addr 00:19:db:f2:e1:35
        forcedeth: 0000:00:14.0: highdma pwrctl timirq gbit lnktim desc-v3
The line maked * was inserted by me in the source file for my debugging.

BYtE
Philipp Hahn
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

Re: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e

[Yinghai Lu]

On Thu, Feb 5, 2009 at 3:23 PM, Philipp Matthias Hahn
<pmhahn-u4khhh1J0LzF41mA0N3lWw@public.gmane.org> wrote:
> Hello!
>
> On Thu, Jan 29, 2009 at 10:53:40PM -0800, Yinghai Lu wrote:
>> can not find the reason why the WOL doesn't work...
>>
>> please post
>> 1. boot log for just after AC is pluged-in... ===> you should have
>> "nv_probe: set workaround bit for reversed mac addr"
>> 2. and boot log after boot from WOL...==> you have have "nv_probe: set
>> workaround bit for reversed mac addr" too.
>
> On Wed, Feb 04, 2009 at 11:58:53AM +0100, Rafael J. Wysocki wrote:
>> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=12614
>> Subject               : WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e
>> Submitter     : Philipp Matthias Hahn <pmhahn-u4khhh1J0LzF41mA0N3lWw@public.gmane.org>
>> Date          : 2009-01-29 6:31 (7 days old)
>> References    : http://marc.info/?l=linux-kernel&m=123321232825316&w=4
>> Handled-By    : Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Patch         : http://marc.info/?l=linux-kernel&m=123330459229248&w=4
>
> Strage, at the moment I can't seem to reproduce the problem. I've
> switched back to the version of 2.6.28.3 and now it seems to work.
> I'll continue with tesing.
>
> Some additional data:
> The BIOS-upgrade tool (Afud408.exe) resets the MAC address. I had to run
> the tool a second time to re-programm the MAC-address using its /M
> option. I useed the unreversed MAC-address back than.
> I also tried the reversed address once, but after that forcedeth.c
> complained about a wrong MAC-address.
>
> If I completely turn off the power (pull the plug), WOL doesn't work,
> even when it's enabled in the BIOS.
>
> Only after I'v started Linux, do "echo NMAC > /proc/acpi/wakeup" and
> "ethtool -s eth0 wol g" does it work again.
>
> Nether the less here's the output of dmesg:
>        forcedeth: Reverse Engineered nFoce ethernet driver. Version 0.61.
>        ACPI: PCI Interrupt Link [LMAC] enables at IRQ 23
>        forcedeth: 0000:00:14.0: PCI INT A -> Link[LMAC] -> GSI 23 (level, low) -> IRQ 23
>        forcedeth: 0000:00:14.0: setting latency timer to 64
> *       nv_probe: MAC_ADDR_REV ELSE
>        nv_probe: set workaround bit for reversed mac addr

that means your BIOS doesn't reverse mac addr.
this is the one for new BIOS or old BIOS?

YH

Re: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e

[Rafael J. Wysocki]

On Friday 06 February 2009, Philipp Matthias Hahn wrote:
> Hello!
> 
> On Thu, Jan 29, 2009 at 10:53:40PM -0800, Yinghai Lu wrote:
> > can not find the reason why the WOL doesn't work...
> > 
> > please post
> > 1. boot log for just after AC is pluged-in... ===> you should have
> > "nv_probe: set workaround bit for reversed mac addr"
> > 2. and boot log after boot from WOL...==> you have have "nv_probe: set
> > workaround bit for reversed mac addr" too.
> 
> On Wed, Feb 04, 2009 at 11:58:53AM +0100, Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12614
> > Subject		: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e
> > Submitter	: Philipp Matthias Hahn <pmhahn-u4khhh1J0LzF41mA0N3lWw@public.gmane.org>
> > Date		: 2009-01-29 6:31 (7 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123321232825316&w=4
> > Handled-By	: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Patch		: http://marc.info/?l=linux-kernel&m=123330459229248&w=4
> 
> Strage, at the moment I can't seem to reproduce the problem. I've
> switched back to the version of 2.6.28.3 and now it seems to work.
> I'll continue with tesing.

OK, but for now I'll close the bug as unreproducible.

> Some additional data:
> The BIOS-upgrade tool (Afud408.exe) resets the MAC address. I had to run
> the tool a second time to re-programm the MAC-address using its /M
> option. I useed the unreversed MAC-address back than.
> I also tried the reversed address once, but after that forcedeth.c
> complained about a wrong MAC-address.
> 
> If I completely turn off the power (pull the plug), WOL doesn't work,
> even when it's enabled in the BIOS.
> 
> Only after I'v started Linux, do "echo NMAC > /proc/acpi/wakeup" and
> "ethtool -s eth0 wol g" does it work again.

The "echo NMAC > /proc/acpi/wakeup" thing shouldn't be necessary if you do
"ethtool -s eth0 wol g".

Thanks,
Rafael

Re: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e

[Philipp Matthias Hahn]

Hello!

On Fri, Feb 06, 2009 at 01:13:30AM +0100, Rafael J. Wysocki wrote:
...
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12614
> > > Subject		: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e
...
> > Strage, at the moment I can't seem to reproduce the problem. I've
> > switched back to the version of 2.6.28.3 and now it seems to work.
> > I'll continue with tesing.
> 
> OK, but for now I'll close the bug as unreproducible.

Just this morning I had to use the reverted address to wake up my
desktop PC after 6 hours of poweroff.

Yesterdays tests were domething like the following:
	Grub: Linux "loglevel=9 ignore_loglevel break=modules"
	dmesg -c > /dev/null
	modprobe forcedeth
	dmesg
	ethtool -s eth0 wol g
	echo NMAC > /proc/acpi/wakeup
	reboot to Grub using Alt-SysRq-B
	Grub: "halt"
I have to reboot back to Grub, since doing a "poweroff" from initrd or
pressing Alt-SysRq-O seems to turn of WOL.

...
> The "echo NMAC > /proc/acpi/wakeup" thing shouldn't be necessary if you do
> "ethtool -s eth0 wol g".

Will try.

On Thu, Feb 05, 2009 at 03:35:25PM -0800, Yinghai Lu wrote:
> > Nether the less here's the output of dmesg:
> >        forcedeth: Reverse Engineered nFoce ethernet driver. Version 0.61.
> >        ACPI: PCI Interrupt Link [LMAC] enables at IRQ 23
> >        forcedeth: 0000:00:14.0: PCI INT A -> Link[LMAC] -> GSI 23 (level, low) -> IRQ 23
> >        forcedeth: 0000:00:14.0: setting latency timer to 64
> > *       nv_probe: MAC_ADDR_REV ELSE
> >        nv_probe: set workaround bit for reversed mac addr
> 
> that means your BIOS doesn't reverse mac addr.
> this is the one for new BIOS or old BIOS?

This is the new BIOS.

BYtE
Philipp Hahn
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn-u4khhh1J0LzF41mA0N3lWw@public.gmane.org

Re: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e

[Philipp Matthias Hahn]

Hello again!

On Fri, Feb 06, 2009 at 06:33:20AM +0100, Philipp Matthias Hahn wrote:
> Just this morning I had to use the reverted address to wake up my
> desktop PC after 6 hours of poweroff.

I did some structured tesing:

1. WOL does _not_ work at all when I do:
	(grub) boot into initrd
	(initrd) modprobe forcedeth
	(initrd) ethtool -s eth0 wol g
*	(initrd) poweroff

2. WOL does _not_ work at all when I do:
	(grub) boot into initrd
	(initrd) modprobe forcedeth
	(initrd) ethtool -s eth0 wol g
*	(initrd) Alt-SysRq-O

3. WOL works using the _un-reversed_ MAC when I do:
	(grub) boot into initrd
	(initrd) modprobe forcedeth
	(initrd) ethtool -s eth0 wol g
*	(initrd) Alt-SysRq-B
*	(grub) halt

4. WOL works using the _reversed_ MAC when I do:
	(grub) boot into initrd
	(initrd) modprobe forcedeth
	(initrd) ethtool -s eth0 wol g
	(initrd) exit
*	(Debian) poweroff

If I do the poweroff from linux (either initrd or Debian), forcedeth
seems to display some messages just before poweroff. I'll try to get
hands on a Serial-USB-Converter and a NULL-modem-cable to capture it,
since my laptop is legacy-free :-(

BYtE
Philipp Hahn

PS: initrd is actually initramfs, before somebody wonders.
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn-u4khhh1J0LzF41mA0N3lWw@public.gmane.org

Re: [Bug #12612] hard lockup when interrupting cdda2wav

[FUJITA Tomonori]

On Thu, 5 Feb 2009 14:16:44 +0100
Matthias Reichl <hias-vtPv7MOkFPkAvxtiuMwx3w@public.gmane.org> wrote:

> On Wed, Feb 04, 2009 at 11:58:51AM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12612
> > Subject		: hard lockup when interrupting cdda2wav
> > Submitter	: Matthias Reichl <hias-vtPv7MOkFPkAvxtiuMwx3w@public.gmane.org>
> > Date		: 2009-01-28 16:41 (8 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123316111415677&w=4
> > Handled-By	: FUJITA Tomonori <fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
> 
> This bug is still present in 2.6.28.3.

There is a fix against scsi-misc:

http://marc.info/?l=linux-scsi&m=123371501613019&w=2

I might need to fix it in a different way though.

There are other pending patches to fix other sg oops in scsi-misc so
the above fix can't be cleanly applied to 2.6.28.X. I'll send a patch
for 2.6.28.X once I get SCSI maintainer's ACK on it.

Sorry for the inconvenience,

Re: [Bug #12405] oops in __bounce_end_io_read under kvm

[Christoph Hellwig]

On Wed, Feb 04, 2009 at 11:58:40AM +0100, Rafael J. Wysocki wrote:
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12405
> Subject		: oops in __bounce_end_io_read under kvm
> Submitter	: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> Date		: 2008-12-26 17:36 (41 days old)
> References	: http://marc.info/?l=linux-kernel&m=123031303400676&w=4
> Handled-By	: Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>

Still around.  Btw, I'm not sure it's a regression as I only started
using virtio_blk heavily during the 2.6.28 cycle.

Re: [Bug #12426] TMDC Joystick no longer works in kernel 2.6.28

[Andrew S. Johnson]

On Wednesday 04 February 2009 07:34:55 pm Rafael J. Wysocki wrote:
> On Wednesday 04 February 2009, Jiri Kosina wrote:
> > On Wed, 4 Feb 2009, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a
> > > report of regressions introduced between 2.6.27 and 2.6.28.
> > >
> > > The following bug entry is on the current list of known
> > > regressions introduced between 2.6.27 and 2.6.28.  Please
> > > verify if it still should be listed and let me know (either
> > > way).
> > >
> > >
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12426
> > > Subject		: TMDC Joystick no longer works in kernel 2.6.28
> > > Submitter	: Andrew S. Johnson <andy-9eXmkf4BiQ2aMJb+Lgu22Q@public.gmane.org>
> > > Date		: 2009-01-10 21:53 (26 days old)
> > > References	:
> > > http://marc.info/?l=linux-kernel&m=123162486415366&w=4
> >
> > I asked [1] the Submitter some time ago to check whether
> > reverting a particular commit fixes the issue, but never heard
> > back.
> >
> > [1] http://lkml.org/lkml/2009/1/26/70
>
> Rejected as "insufficient data" and closed.

I never received the email referring to a particular commit because
I am not subscribed to LKML.  The commit revert seemed to work OK on 
gameport.c, but I get an error that gameport.h requires merge 
resolution.

Can you send the gameport.c and gameport.h files to me with the
reverted commit, or tell me how to get this resolved?

Please CC me directly.

Thanks,

Andy Johnson

>
> Thanks,
> Rafael

Re: [Bug #12426] TMDC Joystick no longer works in kernel 2.6.28

[Jiri Kosina]

On Fri, 6 Feb 2009, Andrew S. Johnson wrote:

> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12426
> > > > Subject		: TMDC Joystick no longer works in kernel 2.6.28
> > > > Submitter	: Andrew S. Johnson <andy-9eXmkf4BiQ2aMJb+Lgu22Q@public.gmane.org>
> > > > Date		: 2009-01-10 21:53 (26 days old)
> > > > References	:
> > > > http://marc.info/?l=linux-kernel&m=123162486415366&w=4
> > > I asked [1] the Submitter some time ago to check whether
> > > reverting a particular commit fixes the issue, but never heard
> > > back.
> > > [1] http://lkml.org/lkml/2009/1/26/70
> > Rejected as "insufficient data" and closed.
> I never received the email referring to a particular commit because I am 
> not subscribed to LKML.  

I CCed you, but your ISP blacklisted both of my SMTP servers I have tried 
for no apparent reason.

> The commit revert seemed to work OK on gameport.c, but I get an error 
> that gameport.h requires merge resolution.

Please try the patch below. It's not a simple revert of 6902c0be, needed 
some manual tweaking.

diff --git a/drivers/input/gameport/gameport.c b/drivers/input/gameport/gameport.c
index ebf4be5..5f2e729 100644
--- a/drivers/input/gameport/gameport.c
+++ b/drivers/input/gameport/gameport.c
@@ -231,7 +231,6 @@ static void gameport_find_driver(struct gameport *gameport)
 enum gameport_event_type {
 	GAMEPORT_REGISTER_PORT,
 	GAMEPORT_REGISTER_DRIVER,
-	GAMEPORT_ATTACH_DRIVER,
 };
 
 struct gameport_event {
@@ -246,12 +245,11 @@ static LIST_HEAD(gameport_event_list);
 static DECLARE_WAIT_QUEUE_HEAD(gameport_wait);
 static struct task_struct *gameport_task;
 
-static int gameport_queue_event(void *object, struct module *owner,
-				enum gameport_event_type event_type)
+static void gameport_queue_event(void *object, struct module *owner,
+			      enum gameport_event_type event_type)
 {
 	unsigned long flags;
 	struct gameport_event *event;
-	int retval = 0;
 
 	spin_lock_irqsave(&gameport_event_lock, flags);
 
@@ -270,34 +268,24 @@ static int gameport_queue_event(void *object, struct module *owner,
 		}
 	}
 
-	event = kmalloc(sizeof(struct gameport_event), GFP_ATOMIC);
-	if (!event) {
-		printk(KERN_ERR
-			"gameport: Not enough memory to queue event %d\n",
-			event_type);
-		retval = -ENOMEM;
-		goto out;
-	}
-
-	if (!try_module_get(owner)) {
-		printk(KERN_WARNING
-			"gameport: Can't get module reference, dropping event %d\n",
-			event_type);
-		kfree(event);
-		retval = -EINVAL;
-		goto out;
-	}
-
-	event->type = event_type;
-	event->object = object;
-	event->owner = owner;
+	if ((event = kmalloc(sizeof(struct gameport_event), GFP_ATOMIC))) {
+		if (!try_module_get(owner)) {
+			printk(KERN_WARNING "gameport: Can't get module reference, dropping event %d\n", event_type);
+			kfree(event);
+			goto out;
+		}
 
-	list_add_tail(&event->node, &gameport_event_list);
-	wake_up(&gameport_wait);
+		event->type = event_type;
+		event->object = object;
+		event->owner = owner;
 
+		list_add_tail(&event->node, &gameport_event_list);
+		wake_up(&gameport_wait);
+	} else {
+		printk(KERN_ERR "gameport: Not enough memory to queue event %d\n", event_type);
+	}
 out:
 	spin_unlock_irqrestore(&gameport_event_lock, flags);
-	return retval;
 }
 
 static void gameport_free_event(struct gameport_event *event)
@@ -390,10 +378,9 @@ static void gameport_handle_event(void)
 }
 
 /*
- * Remove all events that have been submitted for a given object,
- * be it a gameport port or a driver.
+ * Remove all events that have been submitted for a given gameport port.
  */
-static void gameport_remove_pending_events(void *object)
+static void gameport_remove_pending_events(struct gameport *gameport)
 {
 	struct list_head *node, *next;
 	struct gameport_event *event;
@@ -403,7 +390,7 @@ static void gameport_remove_pending_events(void *object)
 
 	list_for_each_safe(node, next, &gameport_event_list) {
 		event = list_entry(node, struct gameport_event, node);
-		if (event->object == object) {
+		if (event->object == gameport) {
 			list_del_init(node);
 			gameport_free_event(event);
 		}
@@ -717,40 +704,10 @@ static void gameport_add_driver(struct gameport_driver *drv)
 			drv->driver.name, error);
 }
 
-int __gameport_register_driver(struct gameport_driver *drv, struct module *owner,
-				const char *mod_name)
+void __gameport_register_driver(struct gameport_driver *drv, struct module *owner)
 {
-	int error;
-
 	drv->driver.bus = &gameport_bus;
-	drv->driver.owner = owner;
-	drv->driver.mod_name = mod_name;
-
-	/*
-	 * Temporarily disable automatic binding because probing
-	 * takes long time and we are better off doing it in kgameportd
-	 */
-	drv->ignore = 1;
-
-	error = driver_register(&drv->driver);
-	if (error) {
-		printk(KERN_ERR
-			"gameport: driver_register() failed for %s, error: %d\n",
-			drv->driver.name, error);
-		return error;
-	}
-
-	/*
-	 * Reset ignore flag and let kgameportd bind the driver to free ports
-	 */
-	drv->ignore = 0;
-	error = gameport_queue_event(drv, NULL, GAMEPORT_ATTACH_DRIVER);
-	if (error) {
-		driver_unregister(&drv->driver);
-		return error;
-	}
-
-	return 0;
+	gameport_queue_event(drv, owner, GAMEPORT_REGISTER_DRIVER);
 }
 
 void gameport_unregister_driver(struct gameport_driver *drv)
@@ -758,9 +715,7 @@ void gameport_unregister_driver(struct gameport_driver *drv)
 	struct gameport *gameport;
 
 	mutex_lock(&gameport_mutex);
-
 	drv->ignore = 1;	/* so gameport_find_driver ignores it */
-	gameport_remove_pending_events(drv);
 
 start_over:
 	list_for_each_entry(gameport, &gameport_list, node) {
@@ -773,7 +728,6 @@ start_over:
 	}
 
 	driver_unregister(&drv->driver);
-
 	mutex_unlock(&gameport_mutex);
 }
 
diff --git a/drivers/input/joystick/a3d.c b/drivers/input/joystick/a3d.c
index 6489f40..92498d4 100644
--- a/drivers/input/joystick/a3d.c
+++ b/drivers/input/joystick/a3d.c
@@ -414,7 +414,8 @@ static struct gameport_driver a3d_drv = {
 
 static int __init a3d_init(void)
 {
-	return gameport_register_driver(&a3d_drv);
+	gameport_register_driver(&a3d_drv);
+	return 0;
 }
 
 static void __exit a3d_exit(void)
diff --git a/drivers/input/joystick/adi.c b/drivers/input/joystick/adi.c
index 89c4c08..d1ca8a1 100644
--- a/drivers/input/joystick/adi.c
+++ b/drivers/input/joystick/adi.c
@@ -572,7 +572,8 @@ static struct gameport_driver adi_drv = {
 
 static int __init adi_init(void)
 {
-	return gameport_register_driver(&adi_drv);
+	gameport_register_driver(&adi_drv);
+	return 0;
 }
 
 static void __exit adi_exit(void)
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index 356b3a2..708c5ae 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -761,7 +761,9 @@ static struct gameport_driver analog_drv = {
 static int __init analog_init(void)
 {
 	analog_parse_options();
-	return gameport_register_driver(&analog_drv);
+	gameport_register_driver(&analog_drv);
+
+	return 0;
 }
 
 static void __exit analog_exit(void)
diff --git a/drivers/input/joystick/cobra.c b/drivers/input/joystick/cobra.c
index 3497b87..639b975 100644
--- a/drivers/input/joystick/cobra.c
+++ b/drivers/input/joystick/cobra.c
@@ -263,7 +263,8 @@ static struct gameport_driver cobra_drv = {
 
 static int __init cobra_init(void)
 {
-	return gameport_register_driver(&cobra_drv);
+	gameport_register_driver(&cobra_drv);
+	return 0;
 }
 
 static void __exit cobra_exit(void)
diff --git a/drivers/input/joystick/gf2k.c b/drivers/input/joystick/gf2k.c
index 67c207f..cb6eef1 100644
--- a/drivers/input/joystick/gf2k.c
+++ b/drivers/input/joystick/gf2k.c
@@ -375,7 +375,8 @@ static struct gameport_driver gf2k_drv = {
 
 static int __init gf2k_init(void)
 {
-	return gameport_register_driver(&gf2k_drv);
+	gameport_register_driver(&gf2k_drv);
+	return 0;
 }
 
 static void __exit gf2k_exit(void)
diff --git a/drivers/input/joystick/grip.c b/drivers/input/joystick/grip.c
index fc55899..684e07c 100644
--- a/drivers/input/joystick/grip.c
+++ b/drivers/input/joystick/grip.c
@@ -426,7 +426,8 @@ static struct gameport_driver grip_drv = {
 
 static int __init grip_init(void)
 {
-	return gameport_register_driver(&grip_drv);
+	gameport_register_driver(&grip_drv);
+	return 0;
 }
 
 static void __exit grip_exit(void)
diff --git a/drivers/input/joystick/grip_mp.c b/drivers/input/joystick/grip_mp.c
index 2d47baf..8279481 100644
--- a/drivers/input/joystick/grip_mp.c
+++ b/drivers/input/joystick/grip_mp.c
@@ -689,7 +689,8 @@ static struct gameport_driver grip_drv = {
 
 static int __init grip_init(void)
 {
-	return gameport_register_driver(&grip_drv);
+	gameport_register_driver(&grip_drv);
+	return 0;
 }
 
 static void __exit grip_exit(void)
diff --git a/drivers/input/joystick/guillemot.c b/drivers/input/joystick/guillemot.c
index 4058d4b..25ec3fa 100644
--- a/drivers/input/joystick/guillemot.c
+++ b/drivers/input/joystick/guillemot.c
@@ -283,7 +283,8 @@ static struct gameport_driver guillemot_drv = {
 
 static int __init guillemot_init(void)
 {
-	return gameport_register_driver(&guillemot_drv);
+	gameport_register_driver(&guillemot_drv);
+	return 0;
 }
 
 static void __exit guillemot_exit(void)
diff --git a/drivers/input/joystick/interact.c b/drivers/input/joystick/interact.c
index 2478289..8c3290b 100644
--- a/drivers/input/joystick/interact.c
+++ b/drivers/input/joystick/interact.c
@@ -317,7 +317,8 @@ static struct gameport_driver interact_drv = {
 
 static int __init interact_init(void)
 {
-	return gameport_register_driver(&interact_drv);
+	gameport_register_driver(&interact_drv);
+	return 0;
 }
 
 static void __exit interact_exit(void)
diff --git a/drivers/input/joystick/joydump.c b/drivers/input/joystick/joydump.c
index cd894a0..2a1b82c 100644
--- a/drivers/input/joystick/joydump.c
+++ b/drivers/input/joystick/joydump.c
@@ -161,7 +161,8 @@ static struct gameport_driver joydump_drv = {
 
 static int __init joydump_init(void)
 {
-	return gameport_register_driver(&joydump_drv);
+	gameport_register_driver(&joydump_drv);
+	return 0;
 }
 
 static void __exit joydump_exit(void)
diff --git a/drivers/input/joystick/sidewinder.c b/drivers/input/joystick/sidewinder.c
index ca13a6b..7b4865f 100644
--- a/drivers/input/joystick/sidewinder.c
+++ b/drivers/input/joystick/sidewinder.c
@@ -818,7 +818,8 @@ static struct gameport_driver sw_drv = {
 
 static int __init sw_init(void)
 {
-	return gameport_register_driver(&sw_drv);
+	gameport_register_driver(&sw_drv);
+	return 0;
 }
 
 static void __exit sw_exit(void)
diff --git a/drivers/input/joystick/tmdc.c b/drivers/input/joystick/tmdc.c
index d6c6098..60c37bc 100644
--- a/drivers/input/joystick/tmdc.c
+++ b/drivers/input/joystick/tmdc.c
@@ -438,7 +438,8 @@ static struct gameport_driver tmdc_drv = {
 
 static int __init tmdc_init(void)
 {
-	return gameport_register_driver(&tmdc_drv);
+	gameport_register_driver(&tmdc_drv);
+	return 0;
 }
 
 static void __exit tmdc_exit(void)
diff --git a/include/linux/gameport.h b/include/linux/gameport.h
index 0cd825f..f64e29c 100644
--- a/include/linux/gameport.h
+++ b/include/linux/gameport.h
@@ -146,11 +146,10 @@ static inline void gameport_unpin_driver(struct gameport *gameport)
 	mutex_unlock(&gameport->drv_mutex);
 }
 
-int __gameport_register_driver(struct gameport_driver *drv,
-				struct module *owner, const char *mod_name);
-static inline int __must_check gameport_register_driver(struct gameport_driver *drv)
+void __gameport_register_driver(struct gameport_driver *drv, struct module *owner);
+static inline void gameport_register_driver(struct gameport_driver *drv)
 {
-	return __gameport_register_driver(drv, THIS_MODULE, KBUILD_MODNAME);
+	__gameport_register_driver(drv, THIS_MODULE);
 }
 
 void gameport_unregister_driver(struct gameport_driver *drv);

Re: [Bug #12405] oops in __bounce_end_io_read under kvm

[Rafael J. Wysocki]

On Friday 06 February 2009, Christoph Hellwig wrote:
> On Wed, Feb 04, 2009 at 11:58:40AM +0100, Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12405
> > Subject		: oops in __bounce_end_io_read under kvm
> > Submitter	: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> > Date		: 2008-12-26 17:36 (41 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123031303400676&w=4
> > Handled-By	: Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> 
> Still around.  Btw, I'm not sure it's a regression as I only started
> using virtio_blk heavily during the 2.6.28 cycle.

Well, assuming that it is a regression raises its chances to be fixed faster. ;-)

Re: WOL with forcedeth broken since f55c21fd9a92a444e55ad1ca4e4732d56661bf2e

[Philipp Matthias Hahn]

HellO!

On Fri, Feb 06, 2009 at 07:59:12AM +0100, Philipp Matthias Hahn wrote:
> I did some structured tesing:

Here are my captured console logs:
scout=Desktop with nVidia Corporation MCP51 Ethernet Controller (rev a3)
euro=Laptop used for capturing and wakeup

(initramfs) modprobe forcedeth
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 23
forcedeth 0000:00:14.0: PCI INT A -> Link[LMAC] -> GSI 23 (level, low) -> IRQ 23
forcedeth 0000:00:14.0: setting latency timer to 64
nv_probe: MAC_ADDR_REV ELSE
nv_probe: set workaround bit for reversed mac addr
forcedeth 0000:00:14.0: ifname eth0, PHY OUI 0x732 @ 1, addr 00:19:db:f2:e1:35
forcedeth 0000:00:14.0: highdma pwrctl timirq gbit lnktim desc-v3
(initramfs) ethtool -s eth0 wol g
(initramfs) poweroff
...
forcedeth 0000:00:14.0: PCI INT A disabled
forcedeth 0000:00:14.0: PME# enabled
forcedeth 0000:00:14.0: wake-up capability enabled by ACPI
ACPI: Preparing to enter system sleep state S5
...
Power down.
acpi_power_off called

euro:~# etherwake -i eth0 00:19:db:f2:e1:35 # FAIL
euro:~# etherwake -i eth0 35:e1:f2:db:19:00 # FAIL


(initramfs) modprobe forcedeth
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 23
forcedeth 0000:00:14.0: PCI INT A -> Link[LMAC] -> GSI 23 (level, low) -> IRQ 23
forcedeth 0000:00:14.0: setting latency timer to 64
nv_probe: MAC_ADDR_REV ELSE
nv_probe: set workaround bit for reversed mac addr
forcedeth 0000:00:14.0: ifname eth0, PHY OUI 0x732 @ 1, addr 00:19:db:f2:e1:35
forcedeth 0000:00:14.0: highdma pwrctl timirq gbit lnktim desc-v3
(initramfs) ethtool -s eth0 wol g
(initramfs) echo o > /proc/sysrq-trigger
SysRq : Power Off
...
forcedeth 0000:00:14.0: PCI INT A disabled
forcedeth 0000:00:14.0: PME# enabled
forcedeth 0000:00:14.0: wake-up capability enabled by ACPI
ACPI: Preparing to enter system sleep state S5
...
Power down.
acpi_power_off called

euro:~# etherwake -i eth0 00:19:db:f2:e1:35 # FAIL
euro:~# etherwake -i eth0 35:e1:f2:db:19:00 # FAIL


(initramfs) modprobe forcedeth
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 23
forcedeth 0000:00:14.0: PCI INT A -> Link[LMAC] -> GSI 23 (level, low) -> IRQ 23
forcedeth 0000:00:14.0: setting latency timer to 64
nv_probe: MAC_ADDR_REV ELSE
nv_probe: set workaround bit for reversed mac addr
forcedeth 0000:00:14.0: ifname eth0, PHY OUI 0x732 @ 1, addr 00:19:db:f2:e1:35
forcedeth 0000:00:14.0: highdma pwrctl timirq gbit lnktim desc-v3
(initramfs) ethtool -s eth0 wol g
(initramfs) echo b > /proc/sysrq-trigger
SysRq : Resetting
(grub) halt

euro:~# etherwake -i eth0 35:e1:f2:db:19:00 # FAIL
euro:~# etherwake -i eth0 00:19:db:f2:e1:35 # SUCCESS


(initramfs) modprobe forcedeth
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 23
forcedeth 0000:00:14.0: PCI INT A -> Link[LMAC] -> GSI 23 (level, low) -> IRQ 23
forcedeth 0000:00:14.0: setting latency timer to 64
nv_probe: MAC_ADDR_REV ELSE
nv_probe: set workaround bit for reversed mac addr
forcedeth 0000:00:14.0: ifname eth0, PHY OUI 0x732 @ 1, addr 00:19:db:f2:e1:35
forcedeth 0000:00:14.0: highdma pwrctl timirq gbit lnktim desc-v3
(initramfs) ethtool -s eth0 wol g
(initramfs) exit
...
scout:~# poweroff
...
forcedeth 0000:00:14.0: PCI INT A disabled
forcedeth 0000:00:14.0: PME# enabled
forcedeth 0000:00:14.0: wake-up capability enabled by ACPI
ACPI: Preparing to enter system sleep state S5
...
Power down.
acpi_power_off called

euro:~# etherwake -i eth0 00:19:db:f2:e1:35 # FAIL
euro:~# etherwake -i eth0 35:e1:f2:db:19:00 # SUCCESS

BYtE
Philipp Hahn
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn-u4khhh1J0LzF41mA0N3lWw@public.gmane.org

[Bug #12263] Sata soft reset filling log

[Rafael J. Wysocki]

This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.

The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28.  Please verify if it still should
be listed and let me know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
Subject		: Sata soft reset filling log
Submitter	: Justin Madru <bevicm-QP1aEjBt37AFQeE35raUng@public.gmane.org>
Date		: 2008-12-13 2:07 (64 days old)
References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4

Re: [Bug #12263] Sata soft reset filling log

[Justin Madru]

Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
> Subject		: Sata soft reset filling log
> Submitter	: Justin Madru <bevicm@dslextreme.com>
> Date		: 2008-12-13 2:07 (64 days old)
> References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4
>
>
> --
> 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/
>
>
>
>   

I'm still seeing this on .29-rc5, and I think that my bug #12263 is a 
duplicate of bug #12609,
or more correctly it's a duplicate of mine because I reported first.

It seems like the bug has been fixed in tip/master for some time now.
Below is the diff of origin and tip from when I tested.

$ git diff origin/master..tip/master drivers/ata/

diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 54961c0..e004c25 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -310,7 +310,7 @@ static struct scsi_host_template piix_sht = {
 };
 
 static struct ata_port_operations piix_pata_ops = {
-    .inherits        = &ata_bmdma32_port_ops,
+    .inherits        = &ata_bmdma_port_ops,
     .cable_detect        = ata_cable_40wire,
     .set_piomode        = piix_set_piomode,
     .set_dmamode        = piix_set_dmamode,
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 9fbf059..1ed3966 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1482,7 +1482,7 @@ static int ata_hpa_resize(struct ata_device *dev)
     struct ata_eh_context *ehc = &dev->link->eh_context;
     int print_info = ehc->i.flags & ATA_EHI_PRINTINFO;
     u64 sectors = ata_id_n_sectors(dev->id);
-    u64 native_sectors;
+    u64 uninitialized_var(native_sectors);
     int rc;
 
     /* do we need to do it? */
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index b9747fa..d65b9b2 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3247,7 +3247,7 @@ void ata_scsi_scan_host(struct ata_port *ap, int sync)
     int tries = 5;
     struct ata_device *last_failed_dev = NULL;
     struct ata_link *link;
-    struct ata_device *dev;
+    struct ata_device *uninitialized_var(dev);
 
     if (ap->flags & ATA_FLAG_DISABLED)
         return;
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 0b299b0..416e3e2 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -80,13 +80,6 @@ const struct ata_port_operations ata_bmdma_port_ops = {
 };
 EXPORT_SYMBOL_GPL(ata_bmdma_port_ops);
 
-const struct ata_port_operations ata_bmdma32_port_ops = {
-    .inherits        = &ata_bmdma_port_ops,
-
-    .sff_data_xfer        = ata_sff_data_xfer32,
-};
-EXPORT_SYMBOL_GPL(ata_bmdma32_port_ops);
-
 /**
  *    ata_fill_sg - Fill PCI IDE PRD table
  *    @qc: Metadata associated with taskfile to be transferred
@@ -743,52 +736,6 @@ unsigned int ata_sff_data_xfer(struct ata_device 
*dev, unsigned char *buf,
 EXPORT_SYMBOL_GPL(ata_sff_data_xfer);
 
 /**
- *    ata_sff_data_xfer32 - Transfer data by PIO
- *    @dev: device to target
- *    @buf: data buffer
- *    @buflen: buffer length
- *    @rw: read/write
- *
- *    Transfer data from/to the device data register by PIO using 32bit
- *    I/O operations.
- *
- *    LOCKING:
- *    Inherited from caller.
- *
- *    RETURNS:
- *    Bytes consumed.
- */
-
-unsigned int ata_sff_data_xfer32(struct ata_device *dev, unsigned char 
*buf,
-                   unsigned int buflen, int rw)
-{
-    struct ata_port *ap = dev->link->ap;
-    void __iomem *data_addr = ap->ioaddr.data_addr;
-    unsigned int words = buflen >> 2;
-    int slop = buflen & 3;
-
-    /* Transfer multiple of 4 bytes */
-    if (rw == READ)
-        ioread32_rep(data_addr, buf, words);
-    else
-        iowrite32_rep(data_addr, buf, words);
-
-    if (unlikely(slop)) {
-        __le32 pad;
-        if (rw == READ) {
-            pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr));
-            memcpy(buf + buflen - slop, &pad, slop);
-        } else {
-            memcpy(&pad, buf + buflen - slop, slop);
-            iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);
-        }
-        words++;
-    }
-    return words << 2;
-}
-EXPORT_SYMBOL_GPL(ata_sff_data_xfer32);
-
-/**
  *    ata_sff_data_xfer_noirq - Transfer data by PIO
  *    @dev: device to target
  *    @buf: data buffer
diff --git a/drivers/ata/pata_ali.c b/drivers/ata/pata_ali.c
index eb99dbe..7cd48ea 100644
--- a/drivers/ata/pata_ali.c
+++ b/drivers/ata/pata_ali.c
@@ -151,7 +151,8 @@ static void ali_fifo_control(struct ata_port *ap, 
struct ata_device *adev, int o
 
     pci_read_config_byte(pdev, pio_fifo, &fifo);
     fifo &= ~(0x0F << shift);
-    fifo |= (on << shift);
+    if (on)
+        fifo |= (on << shift);
     pci_write_config_byte(pdev, pio_fifo, fifo);
 }
 
@@ -369,11 +370,10 @@ static struct ata_port_operations 
ali_early_port_ops = {
     .inherits    = &ata_sff_port_ops,
     .cable_detect    = ata_cable_40wire,
     .set_piomode    = ali_set_piomode,
-    .sff_data_xfer  = ata_sff_data_xfer32,
 };
 
 static const struct ata_port_operations ali_dma_base_ops = {
-    .inherits    = &ata_bmdma32_port_ops,
+    .inherits    = &ata_bmdma_port_ops,
     .set_piomode    = ali_set_piomode,
     .set_dmamode    = ali_set_dmamode,
 };
diff --git a/drivers/ata/pata_amd.c b/drivers/ata/pata_amd.c
index 63719ab..0ec9c7d 100644
--- a/drivers/ata/pata_amd.c
+++ b/drivers/ata/pata_amd.c
@@ -24,7 +24,7 @@
 #include <linux/libata.h>
 
 #define DRV_NAME "pata_amd"
-#define DRV_VERSION "0.3.11"
+#define DRV_VERSION "0.3.10"
 
 /**
  *    timing_setup        -    shared timing computation and load
@@ -345,7 +345,7 @@ static struct scsi_host_template amd_sht = {
 };
 
 static const struct ata_port_operations amd_base_port_ops = {
-    .inherits    = &ata_bmdma32_port_ops,
+    .inherits    = &ata_bmdma_port_ops,
     .prereset    = amd_pre_reset,
 };
 
diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
index 506adde..115eb00 100644
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -140,7 +140,7 @@ static void atiixp_set_dmamode(struct ata_port *ap, 
struct ata_device *adev)
         wanted_pio = 3;
     else if (adev->dma_mode == XFER_MW_DMA_0)
         wanted_pio = 0;
-    else BUG();
+    else panic("atiixp_set_dmamode: unknown DMA mode!");
 
     if (adev->pio_mode != wanted_pio)
         atiixp_set_pio_timing(ap, adev, wanted_pio);
diff --git a/drivers/ata/pata_mpiix.c b/drivers/ata/pata_mpiix.c
index aa576ca..7c8faa4 100644
--- a/drivers/ata/pata_mpiix.c
+++ b/drivers/ata/pata_mpiix.c
@@ -35,7 +35,7 @@
 #include <linux/libata.h>
 
 #define DRV_NAME "pata_mpiix"
-#define DRV_VERSION "0.7.7"
+#define DRV_VERSION "0.7.6"
 
 enum {
     IDETIM = 0x6C,        /* IDE control register */
@@ -146,7 +146,6 @@ static struct ata_port_operations mpiix_port_ops = {
     .cable_detect    = ata_cable_40wire,
     .set_piomode    = mpiix_set_piomode,
     .prereset    = mpiix_pre_reset,
-    .sff_data_xfer    = ata_sff_data_xfer32,
 };
 
 static int mpiix_init_one(struct pci_dev *dev, const struct 
pci_device_id *id)
diff --git a/drivers/ata/pata_sil680.c b/drivers/ata/pata_sil680.c
index 9e764e5..83580a5 100644
--- a/drivers/ata/pata_sil680.c
+++ b/drivers/ata/pata_sil680.c
@@ -32,7 +32,7 @@
 #include <linux/libata.h>
 
 #define DRV_NAME "pata_sil680"
-#define DRV_VERSION "0.4.9"
+#define DRV_VERSION "0.4.8"
 
 #define SIL680_MMIO_BAR        5
 
@@ -195,7 +195,7 @@ static struct scsi_host_template sil680_sht = {
 };
 
 static struct ata_port_operations sil680_port_ops = {
-    .inherits    = &ata_bmdma32_port_ops,
+    .inherits    = &ata_bmdma_port_ops,
     .cable_detect    = sil680_cable_detect,
     .set_piomode    = sil680_set_piomode,
     .set_dmamode    = sil680_set_dmamode,
diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c
index 5c62da9..f9803a2 100644
--- a/drivers/ata/sata_via.c
+++ b/drivers/ata/sata_via.c
@@ -566,7 +566,7 @@ static int svia_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
     static int printed_version;
     unsigned int i;
     int rc;
-    struct ata_host *host;
+    struct ata_host *uninitialized_var(host);
     int board_id = (int) ent->driver_data;
     const unsigned *bar_sizes;
 
Justin Madru

Re: [Bug #12263] Sata soft reset filling log

[Rafael J. Wysocki]

On Sunday 15 February 2009, Justin Madru wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
> > Subject		: Sata soft reset filling log
> > Submitter	: Justin Madru <bevicm@dslextreme.com>
> > Date		: 2008-12-13 2:07 (64 days old)
> > References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4
> 
> I'm still seeing this on .29-rc5, and I think that my bug #12263 is a 
> duplicate of bug #12609,
> or more correctly it's a duplicate of mine because I reported first.
> 
> It seems like the bug has been fixed in tip/master for some time now.
> Below is the diff of origin and tip from when I tested.

Ingo, do you know whinch patch in -tip fixes this regression?

> $ git diff origin/master..tip/master drivers/ata/
> 
> diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
> index 54961c0..e004c25 100644
> --- a/drivers/ata/ata_piix.c
> +++ b/drivers/ata/ata_piix.c
> @@ -310,7 +310,7 @@ static struct scsi_host_template piix_sht = {
>  };
>  
>  static struct ata_port_operations piix_pata_ops = {
> -    .inherits        = &ata_bmdma32_port_ops,
> +    .inherits        = &ata_bmdma_port_ops,
>      .cable_detect        = ata_cable_40wire,
>      .set_piomode        = piix_set_piomode,
>      .set_dmamode        = piix_set_dmamode,
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 9fbf059..1ed3966 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -1482,7 +1482,7 @@ static int ata_hpa_resize(struct ata_device *dev)
>      struct ata_eh_context *ehc = &dev->link->eh_context;
>      int print_info = ehc->i.flags & ATA_EHI_PRINTINFO;
>      u64 sectors = ata_id_n_sectors(dev->id);
> -    u64 native_sectors;
> +    u64 uninitialized_var(native_sectors);
>      int rc;
>  
>      /* do we need to do it? */
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index b9747fa..d65b9b2 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -3247,7 +3247,7 @@ void ata_scsi_scan_host(struct ata_port *ap, int sync)
>      int tries = 5;
>      struct ata_device *last_failed_dev = NULL;
>      struct ata_link *link;
> -    struct ata_device *dev;
> +    struct ata_device *uninitialized_var(dev);
>  
>      if (ap->flags & ATA_FLAG_DISABLED)
>          return;
> diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
> index 0b299b0..416e3e2 100644
> --- a/drivers/ata/libata-sff.c
> +++ b/drivers/ata/libata-sff.c
> @@ -80,13 +80,6 @@ const struct ata_port_operations ata_bmdma_port_ops = {
>  };
>  EXPORT_SYMBOL_GPL(ata_bmdma_port_ops);
>  
> -const struct ata_port_operations ata_bmdma32_port_ops = {
> -    .inherits        = &ata_bmdma_port_ops,
> -
> -    .sff_data_xfer        = ata_sff_data_xfer32,
> -};
> -EXPORT_SYMBOL_GPL(ata_bmdma32_port_ops);
> -
>  /**
>   *    ata_fill_sg - Fill PCI IDE PRD table
>   *    @qc: Metadata associated with taskfile to be transferred
> @@ -743,52 +736,6 @@ unsigned int ata_sff_data_xfer(struct ata_device 
> *dev, unsigned char *buf,
>  EXPORT_SYMBOL_GPL(ata_sff_data_xfer);
>  
>  /**
> - *    ata_sff_data_xfer32 - Transfer data by PIO
> - *    @dev: device to target
> - *    @buf: data buffer
> - *    @buflen: buffer length
> - *    @rw: read/write
> - *
> - *    Transfer data from/to the device data register by PIO using 32bit
> - *    I/O operations.
> - *
> - *    LOCKING:
> - *    Inherited from caller.
> - *
> - *    RETURNS:
> - *    Bytes consumed.
> - */
> -
> -unsigned int ata_sff_data_xfer32(struct ata_device *dev, unsigned char 
> *buf,
> -                   unsigned int buflen, int rw)
> -{
> -    struct ata_port *ap = dev->link->ap;
> -    void __iomem *data_addr = ap->ioaddr.data_addr;
> -    unsigned int words = buflen >> 2;
> -    int slop = buflen & 3;
> -
> -    /* Transfer multiple of 4 bytes */
> -    if (rw == READ)
> -        ioread32_rep(data_addr, buf, words);
> -    else
> -        iowrite32_rep(data_addr, buf, words);
> -
> -    if (unlikely(slop)) {
> -        __le32 pad;
> -        if (rw == READ) {
> -            pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr));
> -            memcpy(buf + buflen - slop, &pad, slop);
> -        } else {
> -            memcpy(&pad, buf + buflen - slop, slop);
> -            iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);
> -        }
> -        words++;
> -    }
> -    return words << 2;
> -}
> -EXPORT_SYMBOL_GPL(ata_sff_data_xfer32);
> -
> -/**
>   *    ata_sff_data_xfer_noirq - Transfer data by PIO
>   *    @dev: device to target
>   *    @buf: data buffer
> diff --git a/drivers/ata/pata_ali.c b/drivers/ata/pata_ali.c
> index eb99dbe..7cd48ea 100644
> --- a/drivers/ata/pata_ali.c
> +++ b/drivers/ata/pata_ali.c
> @@ -151,7 +151,8 @@ static void ali_fifo_control(struct ata_port *ap, 
> struct ata_device *adev, int o
>  
>      pci_read_config_byte(pdev, pio_fifo, &fifo);
>      fifo &= ~(0x0F << shift);
> -    fifo |= (on << shift);
> +    if (on)
> +        fifo |= (on << shift);
>      pci_write_config_byte(pdev, pio_fifo, fifo);
>  }
>  
> @@ -369,11 +370,10 @@ static struct ata_port_operations 
> ali_early_port_ops = {
>      .inherits    = &ata_sff_port_ops,
>      .cable_detect    = ata_cable_40wire,
>      .set_piomode    = ali_set_piomode,
> -    .sff_data_xfer  = ata_sff_data_xfer32,
>  };
>  
>  static const struct ata_port_operations ali_dma_base_ops = {
> -    .inherits    = &ata_bmdma32_port_ops,
> +    .inherits    = &ata_bmdma_port_ops,
>      .set_piomode    = ali_set_piomode,
>      .set_dmamode    = ali_set_dmamode,
>  };
> diff --git a/drivers/ata/pata_amd.c b/drivers/ata/pata_amd.c
> index 63719ab..0ec9c7d 100644
> --- a/drivers/ata/pata_amd.c
> +++ b/drivers/ata/pata_amd.c
> @@ -24,7 +24,7 @@
>  #include <linux/libata.h>
>  
>  #define DRV_NAME "pata_amd"
> -#define DRV_VERSION "0.3.11"
> +#define DRV_VERSION "0.3.10"
>  
>  /**
>   *    timing_setup        -    shared timing computation and load
> @@ -345,7 +345,7 @@ static struct scsi_host_template amd_sht = {
>  };
>  
>  static const struct ata_port_operations amd_base_port_ops = {
> -    .inherits    = &ata_bmdma32_port_ops,
> +    .inherits    = &ata_bmdma_port_ops,
>      .prereset    = amd_pre_reset,
>  };
>  
> diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
> index 506adde..115eb00 100644
> --- a/drivers/ata/pata_atiixp.c
> +++ b/drivers/ata/pata_atiixp.c
> @@ -140,7 +140,7 @@ static void atiixp_set_dmamode(struct ata_port *ap, 
> struct ata_device *adev)
>          wanted_pio = 3;
>      else if (adev->dma_mode == XFER_MW_DMA_0)
>          wanted_pio = 0;
> -    else BUG();
> +    else panic("atiixp_set_dmamode: unknown DMA mode!");
>  
>      if (adev->pio_mode != wanted_pio)
>          atiixp_set_pio_timing(ap, adev, wanted_pio);
> diff --git a/drivers/ata/pata_mpiix.c b/drivers/ata/pata_mpiix.c
> index aa576ca..7c8faa4 100644
> --- a/drivers/ata/pata_mpiix.c
> +++ b/drivers/ata/pata_mpiix.c
> @@ -35,7 +35,7 @@
>  #include <linux/libata.h>
>  
>  #define DRV_NAME "pata_mpiix"
> -#define DRV_VERSION "0.7.7"
> +#define DRV_VERSION "0.7.6"
>  
>  enum {
>      IDETIM = 0x6C,        /* IDE control register */
> @@ -146,7 +146,6 @@ static struct ata_port_operations mpiix_port_ops = {
>      .cable_detect    = ata_cable_40wire,
>      .set_piomode    = mpiix_set_piomode,
>      .prereset    = mpiix_pre_reset,
> -    .sff_data_xfer    = ata_sff_data_xfer32,
>  };
>  
>  static int mpiix_init_one(struct pci_dev *dev, const struct 
> pci_device_id *id)
> diff --git a/drivers/ata/pata_sil680.c b/drivers/ata/pata_sil680.c
> index 9e764e5..83580a5 100644
> --- a/drivers/ata/pata_sil680.c
> +++ b/drivers/ata/pata_sil680.c
> @@ -32,7 +32,7 @@
>  #include <linux/libata.h>
>  
>  #define DRV_NAME "pata_sil680"
> -#define DRV_VERSION "0.4.9"
> +#define DRV_VERSION "0.4.8"
>  
>  #define SIL680_MMIO_BAR        5
>  
> @@ -195,7 +195,7 @@ static struct scsi_host_template sil680_sht = {
>  };
>  
>  static struct ata_port_operations sil680_port_ops = {
> -    .inherits    = &ata_bmdma32_port_ops,
> +    .inherits    = &ata_bmdma_port_ops,
>      .cable_detect    = sil680_cable_detect,
>      .set_piomode    = sil680_set_piomode,
>      .set_dmamode    = sil680_set_dmamode,
> diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c
> index 5c62da9..f9803a2 100644
> --- a/drivers/ata/sata_via.c
> +++ b/drivers/ata/sata_via.c
> @@ -566,7 +566,7 @@ static int svia_init_one(struct pci_dev *pdev, const 
> struct pci_device_id *ent)
>      static int printed_version;
>      unsigned int i;
>      int rc;
> -    struct ata_host *host;
> +    struct ata_host *uninitialized_var(host);
>      int board_id = (int) ent->driver_data;
>      const unsigned *bar_sizes;
>  
> Justin Madru

Re: [Bug #12263] Sata soft reset filling log

[Ingo Molnar]

* Rafael J. Wysocki <rjw@sisk.pl> wrote:

> On Sunday 15 February 2009, Justin Madru wrote:
> > Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of regressions introduced between 2.6.27 and 2.6.28.
> > >
> > > The following bug entry is on the current list of known regressions
> > > introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> > > be listed and let me know (either way).
> > >
> > >
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
> > > Subject		: Sata soft reset filling log
> > > Submitter	: Justin Madru <bevicm@dslextreme.com>
> > > Date		: 2008-12-13 2:07 (64 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4
> > 
> > I'm still seeing this on .29-rc5, and I think that my bug #12263 is a 
> > duplicate of bug #12609,
> > or more correctly it's a duplicate of mine because I reported first.
> > 
> > It seems like the bug has been fixed in tip/master for some time now.
> > Below is the diff of origin and tip from when I tested.
> 
> Ingo, do you know whinch patch in -tip fixes this regression?

This one, done on Jan 10, more than a month ago:

  f1d26da: Revert "libata: Add 32bit PIO support"

When a commit causes trouble in -tip qa i immediately revert it in 95% 
of the cases, no questions asked. Especially if it's related to 
persistent storage.

	Ingo

Re: [Bug #12263] Sata soft reset filling log

[Rafael J. Wysocki]

On Sunday 15 February 2009, Ingo Molnar wrote:
> 
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > On Sunday 15 February 2009, Justin Madru wrote:
> > > Rafael J. Wysocki wrote:
> > > > This message has been generated automatically as a part of a report
> > > > of regressions introduced between 2.6.27 and 2.6.28.
> > > >
> > > > The following bug entry is on the current list of known regressions
> > > > introduced between 2.6.27 and 2.6.28.  Please verify if it still should
> > > > be listed and let me know (either way).
> > > >
> > > >
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
> > > > Subject		: Sata soft reset filling log
> > > > Submitter	: Justin Madru <bevicm@dslextreme.com>
> > > > Date		: 2008-12-13 2:07 (64 days old)
> > > > References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4
> > > 
> > > I'm still seeing this on .29-rc5, and I think that my bug #12263 is a 
> > > duplicate of bug #12609,
> > > or more correctly it's a duplicate of mine because I reported first.
> > > 
> > > It seems like the bug has been fixed in tip/master for some time now.
> > > Below is the diff of origin and tip from when I tested.
> > 
> > Ingo, do you know whinch patch in -tip fixes this regression?
> 
> This one, done on Jan 10, more than a month ago:
> 
>   f1d26da: Revert "libata: Add 32bit PIO support"
> 
> When a commit causes trouble in -tip qa i immediately revert it in 95% 
> of the cases, no questions asked. Especially if it's related to 
> persistent storage.

OK, thanks.

We seem to have a working fix patch for this issue in bug #12609.

Best,
Rafael

Re: [Bug #12263] Sata soft reset filling log

[Sergei Shtylyov]

Hello.

Rafael J. Wysocki wrote:

>>>>>This message has been generated automatically as a part of a report
>>>>>of regressions introduced between 2.6.27 and 2.6.28.

>>>>>The following bug entry is on the current list of known regressions
>>>>>introduced between 2.6.27 and 2.6.28.  Please verify if it still should
>>>>>be listed and let me know (either way).

>>>>>Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
>>>>>Subject		: Sata soft reset filling log
>>>>>Submitter	: Justin Madru <bevicm@dslextreme.com>
>>>>>Date		: 2008-12-13 2:07 (64 days old)
>>>>>References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4

>>>>I'm still seeing this on .29-rc5, and I think that my bug #12263 is a 
>>>>duplicate of bug #12609,
>>>>or more correctly it's a duplicate of mine because I reported first.

>>>>It seems like the bug has been fixed in tip/master for some time now.
>>>>Below is the diff of origin and tip from when I tested.

>>>Ingo, do you know whinch patch in -tip fixes this regression?

>>This one, done on Jan 10, more than a month ago:

>>  f1d26da: Revert "libata: Add 32bit PIO support"

>>When a commit causes trouble in -tip qa i immediately revert it in 95% 
>>of the cases, no questions asked. Especially if it's related to 
>>persistent storage.

> OK, thanks.

> We seem to have a working fix patch for this issue in bug #12609.

    Wait, if this is indeed post-2.6.27 regression, it couldn't possibly have 
been caused by that patch which got merged during 2.6.29-rc1 timeframe. 
Something's up with this bug...

MBR, Sergei

Re: [Bug #12263] Sata soft reset filling log

[Ingo Molnar]

* Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:

> Hello.
>
> Rafael J. Wysocki wrote:
>
>>>>>> This message has been generated automatically as a part of a report
>>>>>> of regressions introduced between 2.6.27 and 2.6.28.
>
>>>>>> The following bug entry is on the current list of known regressions
>>>>>> introduced between 2.6.27 and 2.6.28.  Please verify if it still should
>>>>>> be listed and let me know (either way).
>
>>>>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12263
>>>>>> Subject		: Sata soft reset filling log
>>>>>> Submitter	: Justin Madru <bevicm@dslextreme.com>
>>>>>> Date		: 2008-12-13 2:07 (64 days old)
>>>>>> References	: http://marc.info/?l=linux-kernel&m=122913412608533&w=4
>
>>>>> I'm still seeing this on .29-rc5, and I think that my bug #12263 
>>>>> is a duplicate of bug #12609,
>>>>> or more correctly it's a duplicate of mine because I reported first.
>
>>>>> It seems like the bug has been fixed in tip/master for some time now.
>>>>> Below is the diff of origin and tip from when I tested.
>
>>>> Ingo, do you know whinch patch in -tip fixes this regression?
>
>>> This one, done on Jan 10, more than a month ago:
>
>>>  f1d26da: Revert "libata: Add 32bit PIO support"
>
>>> When a commit causes trouble in -tip qa i immediately revert it in 
>>> 95% of the cases, no questions asked. Especially if it's related to  
>>> persistent storage.
>
>> OK, thanks.
>
>> We seem to have a working fix patch for this issue in bug #12609.
>
>    Wait, if this is indeed post-2.6.27 regression, it couldn't possibly 
> have been caused by that patch which got merged during 2.6.29-rc1 
> timeframe. Something's up with this bug...

SATA uses the SCSI layer, right? It could then perhaps be these bits in 
tip:out-of-tree:

 813104e: Revert "[SCSI] simplify scsi_io_completion()"
 84db545: Revert "[SCSI] Fix uninitialized variable error in scsi_io_completion"
 0eb6038: Revert "[SCSI] Fix error handling for DIF/DIX"
 3cd94dd: Revert "[SCSI] scsi_lib: don't decrement busy counters when inserting commands"
 c27aed5: Revert "[SCSI] scsi_lib: fix DID_RESET status problems"

i needed these to keep an aic7xxx box from crashing. This regression got 
introduced at around 2.6.28-rc1, so it fits the timeframe.

	Ingo

Re: [Bug #12263] Sata soft reset filling log

[Sergei Shtylyov]

Hello, I wrote:

>>>>>> This message has been generated automatically as a part of a report
>>>>>> of regressions introduced between 2.6.27 and 2.6.28.

>>>>>> The following bug entry is on the current list of known regressions
>>>>>> introduced between 2.6.27 and 2.6.28.  Please verify if it still 
>>>>>> should
>>>>>> be listed and let me know (either way).

>>>>>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=12263
>>>>>> Subject        : Sata soft reset filling log
>>>>>> Submitter    : Justin Madru <bevicm-QP1aEjBt37AFQeE35raUng@public.gmane.org>
>>>>>> Date        : 2008-12-13 2:07 (64 days old)
>>>>>> References    : 
>>>>>> http://marc.info/?l=linux-kernel&m=122913412608533&w=4

>>>>> I'm still seeing this on .29-rc5, and I think that my bug #12263 is 
>>>>> a duplicate of bug #12609,
>>>>> or more correctly it's a duplicate of mine because I reported first.

>>>>> It seems like the bug has been fixed in tip/master for some time now.
>>>>> Below is the diff of origin and tip from when I tested.

>>>> Ingo, do you know whinch patch in -tip fixes this regression?

>>> This one, done on Jan 10, more than a month ago:

>>>  f1d26da: Revert "libata: Add 32bit PIO support"

>>> When a commit causes trouble in -tip qa i immediately revert it in 
>>> 95% of the cases, no questions asked. Especially if it's related to 
>>> persistent storage.

>> OK, thanks.

>> We seem to have a working fix patch for this issue in bug #12609.

>    Wait, if this is indeed post-2.6.27 regression, it couldn't possibly 
> have been caused by that patch which got merged during 2.6.29-rc1 
> timeframe. Something's up with this bug...

    Also, it's been reported for a hard disk while regression in bug 12609 
only hits the ATAPI devices. I think that bug 12263 needs to be reopened.

MBR, Sergei

Re: [Bug #12263] Sata soft reset filling log

[Sergei Shtylyov]

Hello, I wrote:

>>>>>>> This message has been generated automatically as a part of a report
>>>>>>> of regressions introduced between 2.6.27 and 2.6.28.

>>>>>>> The following bug entry is on the current list of known regressions
>>>>>>> introduced between 2.6.27 and 2.6.28.  Please verify if it still 
>>>>>>> should
>>>>>>> be listed and let me know (either way).

>>>>>>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=12263
>>>>>>> Subject        : Sata soft reset filling log
>>>>>>> Submitter    : Justin Madru <bevicm-QP1aEjBt37AFQeE35raUng@public.gmane.org>
>>>>>>> Date        : 2008-12-13 2:07 (64 days old)
>>>>>>> References    : 
>>>>>>> http://marc.info/?l=linux-kernel&m=122913412608533&w=4

>>>>>> I'm still seeing this on .29-rc5, and I think that my bug #12263 
>>>>>> is a duplicate of bug #12609,
>>>>>> or more correctly it's a duplicate of mine because I reported first.

>>>>>> It seems like the bug has been fixed in tip/master for some time now.
>>>>>> Below is the diff of origin and tip from when I tested.

>>>>> Ingo, do you know whinch patch in -tip fixes this regression?

>>>> This one, done on Jan 10, more than a month ago:

>>>>  f1d26da: Revert "libata: Add 32bit PIO support"

>>>> When a commit causes trouble in -tip qa i immediately revert it in 
>>>> 95% of the cases, no questions asked. Especially if it's related to 
>>>> persistent storage.

>>> OK, thanks.

>>> We seem to have a working fix patch for this issue in bug #12609.

>>    Wait, if this is indeed post-2.6.27 regression, it couldn't 
>> possibly have been caused by that patch which got merged during 
>> 2.6.29-rc1 timeframe. Something's up with this bug...

>    Also, it's been reported for a hard disk while regression in bug 
> 12609 only hits the ATAPI devices.  I think that bug 12263 needs to be reopened.

    After referring to the SCSI command codes "cdb 0x1e" means ALLOW MEDIUM 
REMOVAL command -- which could hardly be addressed to an usual hard disk. So, 
it looks like we had a case of the confused bug report which has a lot of info 
on the hard disk while errors were most probably happening with a CD/DVD 
drive. :-)

MBR, Sergei

Re: [Bug #12263] Sata soft reset filling log

[Justin Madru]

Sergei Shtylyov wrote:

> After referring to the SCSI command codes "cdb 0x1e" means ALLOW MEDIUM REMOVAL command -- which
> could hardly be addressed to an usual hard disk. So, it looks like we had a case of the confused bug report which
> has a lot of info on the hard disk while errors were most probably happening with a CD/DVD drive.
Yes, I originally thought it was my hard disk because the kernel logs showed ata2.

But, Tejun Heo figured out it was my DVD drive (ATAPI) that was on the ata2 link.

(see http://marc.info/?l=linux-kernel&m=122993014109646&w=2)

I tried to bisect it, but around .28-rc1 I began to get numerous compile errors, so couldn't continue.

I also tried patches that Tejun sent me, but non of them worked, it just slightly change the error message.

So, yes this is a regression that was introduced in the .28 merge window, and I still think that bug #12609 is a duplicate of my bug.

I don't see this bug on tip/master and this is the diff of origin and tip at the time I tested.

$ git diff origin/master..tip/master drivers/ata/

diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c

index 54961c0..e004c25 100644

--- a/drivers/ata/ata_piix.c

+++ b/drivers/ata/ata_piix.c

@@ -310,7 +310,7 @@ static struct scsi_host_template piix_sht = {

};

static struct ata_port_operations piix_pata_ops = {

-    .inherits        = &ata_bmdma32_port_ops,

+    .inherits        = &ata_bmdma_port_ops,

    .cable_detect        = ata_cable_40wire,

    .set_piomode        = piix_set_piomode,

    .set_dmamode        = piix_set_dmamode,

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c

index 9fbf059..1ed3966 100644

--- a/drivers/ata/libata-core.c

+++ b/drivers/ata/libata-core.c

@@ -1482,7 +1482,7 @@ static int ata_hpa_resize(struct ata_device *dev)

    struct ata_eh_context *ehc = &dev->link->eh_context;

    int print_info = ehc->i.flags & ATA_EHI_PRINTINFO;

    u64 sectors = ata_id_n_sectors(dev->id);

-    u64 native_sectors;

+    u64 uninitialized_var(native_sectors);

    int rc;

    /* do we need to do it? */

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c

index b9747fa..d65b9b2 100644

--- a/drivers/ata/libata-scsi.c

+++ b/drivers/ata/libata-scsi.c

@@ -3247,7 +3247,7 @@ void ata_scsi_scan_host(struct ata_port *ap, int sync)

    int tries = 5;

    struct ata_device *last_failed_dev = NULL;

    struct ata_link *link;

-    struct ata_device *dev;

+    struct ata_device *uninitialized_var(dev);

    if (ap->flags & ATA_FLAG_DISABLED)

        return;

diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c

index 0b299b0..416e3e2 100644

--- a/drivers/ata/libata-sff.c

+++ b/drivers/ata/libata-sff.c

@@ -80,13 +80,6 @@ const struct ata_port_operations ata_bmdma_port_ops = {

};

EXPORT_SYMBOL_GPL(ata_bmdma_port_ops);

-const struct ata_port_operations ata_bmdma32_port_ops = {

-    .inherits        = &ata_bmdma_port_ops,

-

-    .sff_data_xfer        = ata_sff_data_xfer32,

-};

-EXPORT_SYMBOL_GPL(ata_bmdma32_port_ops);

-

/**

 *    ata_fill_sg - Fill PCI IDE PRD table

 *    @qc: Metadata associated with taskfile to be transferred

@@ -743,52 +736,6 @@ unsigned int ata_sff_data_xfer(struct ata_device *dev, unsigned char *buf,

EXPORT_SYMBOL_GPL(ata_sff_data_xfer);

/**

- *    ata_sff_data_xfer32 - Transfer data by PIO

- *    @dev: device to target

- *    @buf: data buffer

- *    @buflen: buffer length

- *    @rw: read/write

- *

- *    Transfer data from/to the device data register by PIO using 32bit

- *    I/O operations.

- *

- *    LOCKING:

- *    Inherited from caller.

- *

- *    RETURNS:

- *    Bytes consumed.

- */

-

-unsigned int ata_sff_data_xfer32(struct ata_device *dev, unsigned char *buf,

-                   unsigned int buflen, int rw)

-{

-    struct ata_port *ap = dev->link->ap;

-    void __iomem *data_addr = ap->ioaddr.data_addr;

-    unsigned int words = buflen >> 2;

-    int slop = buflen & 3;

-

-    /* Transfer multiple of 4 bytes */

-    if (rw == READ)

-        ioread32_rep(data_addr, buf, words);

-    else

-        iowrite32_rep(data_addr, buf, words);

-

-    if (unlikely(slop)) {

-        __le32 pad;

-        if (rw == READ) {

-            pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr));

-            memcpy(buf + buflen - slop, &pad, slop);

-        } else {

-            memcpy(&pad, buf + buflen - slop, slop);

-            iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);

-        }

-        words++;

-    }

-    return words << 2;

-}

-EXPORT_SYMBOL_GPL(ata_sff_data_xfer32);

-

-/**

 *    ata_sff_data_xfer_noirq - Transfer data by PIO

 *    @dev: device to target

 *    @buf: data buffer

diff --git a/drivers/ata/pata_ali.c b/drivers/ata/pata_ali.c

index eb99dbe..7cd48ea 100644

--- a/drivers/ata/pata_ali.c

+++ b/drivers/ata/pata_ali.c

@@ -151,7 +151,8 @@ static void ali_fifo_control(struct ata_port *ap, struct ata_device *adev, int o

    pci_read_config_byte(pdev, pio_fifo, &fifo);

    fifo &= ~(0x0F << shift);

-    fifo |= (on << shift);

+    if (on)

+        fifo |= (on << shift);

    pci_write_config_byte(pdev, pio_fifo, fifo);

}

@@ -369,11 +370,10 @@ static struct ata_port_operations ali_early_port_ops = {

    .inherits    = &ata_sff_port_ops,

    .cable_detect    = ata_cable_40wire,

    .set_piomode    = ali_set_piomode,

-    .sff_data_xfer  = ata_sff_data_xfer32,

};

static const struct ata_port_operations ali_dma_base_ops = {

-    .inherits    = &ata_bmdma32_port_ops,

+    .inherits    = &ata_bmdma_port_ops,

    .set_piomode    = ali_set_piomode,

    .set_dmamode    = ali_set_dmamode,

};

diff --git a/drivers/ata/pata_amd.c b/drivers/ata/pata_amd.c

index 63719ab..0ec9c7d 100644

--- a/drivers/ata/pata_amd.c

+++ b/drivers/ata/pata_amd.c

@@ -24,7 +24,7 @@

#include <linux/libata.h>

#define DRV_NAME "pata_amd"

-#define DRV_VERSION "0.3.11"

+#define DRV_VERSION "0.3.10"

/**

 *    timing_setup        -    shared timing computation and load

@@ -345,7 +345,7 @@ static struct scsi_host_template amd_sht = {

};

static const struct ata_port_operations amd_base_port_ops = {

-    .inherits    = &ata_bmdma32_port_ops,

+    .inherits    = &ata_bmdma_port_ops,

    .prereset    = amd_pre_reset,

};

diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c

index 506adde..115eb00 100644

--- a/drivers/ata/pata_atiixp.c

+++ b/drivers/ata/pata_atiixp.c

@@ -140,7 +140,7 @@ static void atiixp_set_dmamode(struct ata_port *ap, struct ata_device *adev)

        wanted_pio = 3;

    else if (adev->dma_mode == XFER_MW_DMA_0)

        wanted_pio = 0;

-    else BUG();

+    else panic("atiixp_set_dmamode: unknown DMA mode!");

    if (adev->pio_mode != wanted_pio)

        atiixp_set_pio_timing(ap, adev, wanted_pio);

diff --git a/drivers/ata/pata_mpiix.c b/drivers/ata/pata_mpiix.c

index aa576ca..7c8faa4 100644

--- a/drivers/ata/pata_mpiix.c

+++ b/drivers/ata/pata_mpiix.c

@@ -35,7 +35,7 @@

#include <linux/libata.h>

#define DRV_NAME "pata_mpiix"

-#define DRV_VERSION "0.7.7"

+#define DRV_VERSION "0.7.6"

enum {

    IDETIM = 0x6C,        /* IDE control register */

@@ -146,7 +146,6 @@ static struct ata_port_operations mpiix_port_ops = {

    .cable_detect    = ata_cable_40wire,

    .set_piomode    = mpiix_set_piomode,

    .prereset    = mpiix_pre_reset,

-    .sff_data_xfer    = ata_sff_data_xfer32,

};

static int mpiix_init_one(struct pci_dev *dev, const struct pci_device_id *id)

diff --git a/drivers/ata/pata_sil680.c b/drivers/ata/pata_sil680.c

index 9e764e5..83580a5 100644

--- a/drivers/ata/pata_sil680.c

+++ b/drivers/ata/pata_sil680.c

@@ -32,7 +32,7 @@

#include <linux/libata.h>

#define DRV_NAME "pata_sil680"

-#define DRV_VERSION "0.4.9"

+#define DRV_VERSION "0.4.8"

#define SIL680_MMIO_BAR        5

@@ -195,7 +195,7 @@ static struct scsi_host_template sil680_sht = {

};

static struct ata_port_operations sil680_port_ops = {

-    .inherits    = &ata_bmdma32_port_ops,

+    .inherits    = &ata_bmdma_port_ops,

    .cable_detect    = sil680_cable_detect,

    .set_piomode    = sil680_set_piomode,

    .set_dmamode    = sil680_set_dmamode,

diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c

index 5c62da9..f9803a2 100644

--- a/drivers/ata/sata_via.c

+++ b/drivers/ata/sata_via.c

@@ -566,7 +566,7 @@ static int svia_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)

    static int printed_version;

    unsigned int i;

    int rc;

-    struct ata_host *host;

+    struct ata_host *uninitialized_var(host);

    int board_id = (int) ent->driver_data;

    const unsigned *bar_sizes;

Justin Madru

Re: [Bug #12263] Sata soft reset filling log

[Sergei Shtylyov]

Hello.

Justin Madru wrote:

>> After referring to the SCSI command codes "cdb 0x1e" means ALLOW 
>> MEDIUM REMOVAL command -- which
>> could hardly be addressed to an usual hard disk. So, it looks like we 
>> had a case of the confused bug report which
>> has a lot of info on the hard disk while errors were most probably 
>> happening with a CD/DVD drive.

> Yes, I originally thought it was my hard disk because the kernel logs 
> showed ata2.

> But, Tejun Heo figured out it was my DVD drive (ATAPI) that was on the 
> ata2 link.

> (see http://marc.info/?l=linux-kernel&m=122993014109646&w=2)

> I tried to bisect it, but around .28-rc1 I began to get numerous compile 
> errors, so couldn't continue.

> I also tried patches that Tejun sent me, but non of them worked, it just 
> slightly change the error message.

> So, yes this is a regression that was introduced in the .28 merge 
> window, and I still think that bug #12609 is a duplicate of my bug.

    If 12609 is truly a post-2.6.28 regression and 12263 is post-2.6.27 
regresssion, this just cannot be.

> I don't see this bug on tip/master and this is the diff of origin and 
> tip at the time I tested.

> $ git diff origin/master..tip/master drivers/ata/

    What tree is that?

WBR, Sergei

Re: [Bug #12263] Sata soft reset filling log

[Justin Madru]

Sergei Shtylyov wrote:

> Hello.
>> Justin Madru wrote:
>>> After referring to the SCSI command codes "cdb 0x1e" means ALLOW 
>>> MEDIUM REMOVAL command -- which
>>> could hardly be addressed to an usual hard disk. So, it looks like 
>>> we had a case of the confused bug report which
>>> has a lot of info on the hard disk while errors were most probably 
>>> happening with a CD/DVD drive.
>>
>> Yes, I originally thought it was my hard disk because the kernel logs 
>> showed ata2.
>> But, Tejun Heo figured out it was my DVD drive (ATAPI) that was on 
>> the ata2 link.
>> (see http://marc.info/?l=linux-kernel&m=122993014109646&w=2)
>> I tried to bisect it, but around .28-rc1 I began to get numerous 
>> compile errors, so couldn't continue.
>> I also tried patches that Tejun sent me, but non of them worked, it 
>> just slightly change the error message.
>> So, yes this is a regression that was introduced in the .28 merge 
>> window, and I still think that bug #12609 is a duplicate of my bug.
>
> If 12609 is truly a post-2.6.28 regression and 12263 is post-2.6.27 
> regresssion, this just cannot be.

Maybe the reporter of #12609 didn't notice/test kernels 28-rc1 to 28. Or 
maybe the difference in hardware is
the issue, but the bug is still the same. Don't know.


>> I don't see this bug on tip/master and this is the diff of origin and 
>> tip at the time I tested.
>> $ git diff origin/master..tip/master drivers/ata/
>
> What tree is that?

This is what I have in .git/config and I get the same diff if I run:
git diff master..tip drivers/ata/  or  git diff master...tip drivers/ata/

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[remote "tip"]
    url = 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
    fetch = +refs/heads/*:refs/remotes/tip/*
[branch "tip"]
    remote = tip
    merge = refs/heads/master

Justin Madru

Re: [Bug #12263] Sata soft reset filling log

[Hugh Dickins]

On Mon, 16 Feb 2009, Justin Madru wrote:
> Sergei Shtylyov wrote:
> >
> > If 12609 is truly a post-2.6.28 regression and 12263 is post-2.6.27
> > regresssion, this just cannot be.
> 
> Maybe the reporter of #12609 didn't notice/test kernels 28-rc1 to 28. Or maybe
> the difference in hardware is
> the issue, but the bug is still the same. Don't know.

Sorry Justin, you must be confused: as Sergei says,
#12609 and #12263 can only be different.

I was one of the reporters of #12609, and I do know it's a post-2.6.28
regression (and Larry said so too), and one fix (not the preferred fix)
is to revert the ata_bmdma32_port_ops from 2.6.29-rc, and the preferred
fix is to improve the ata_sff_data_xfer32() introduced in 2.6.29-rc1.

2.6.28 does not contain any ata_bmdma32_port_ops, nor ata_sff_data_xfer32(),
not did 2.6.28-rc1 contain them.  So it is impossible for the reversion of
the patch that introduced them to fix any problem on 2.6.28.

I'm quite prepared to believe that your #12263 manifests similarly to
#12609, and that a tip tree which contains a fix for #12609 contains
a fix for #12263; but please, those bugs are not the same, and they
don't have the same fix.

Hugh

Re: [Bug #12263] Sata soft reset filling log

[Justin Madru]

Hugh Dickins wrote:
> On Mon, 16 Feb 2009, Justin Madru wrote:
>   
>> Sergei Shtylyov wrote:
>>     
>>> If 12609 is truly a post-2.6.28 regression and 12263 is post-2.6.27
>>> regresssion, this just cannot be.
>>>       
>> Maybe the reporter of #12609 didn't notice/test kernels 28-rc1 to 28. Or maybe
>> the difference in hardware is
>> the issue, but the bug is still the same. Don't know.
>>     
>
> Sorry Justin, you must be confused: as Sergei says,
> #12609 and #12263 can only be different.
>
> I was one of the reporters of #12609, and I do know it's a post-2.6.28
> regression (and Larry said so too), and one fix (not the preferred fix)
> is to revert the ata_bmdma32_port_ops from 2.6.29-rc, and the preferred
> fix is to improve the ata_sff_data_xfer32() introduced in 2.6.29-rc1.
>
> 2.6.28 does not contain any ata_bmdma32_port_ops, nor ata_sff_data_xfer32(),
> not did 2.6.28-rc1 contain them.  So it is impossible for the reversion of
> the patch that introduced them to fix any problem on 2.6.28.
>
> I'm quite prepared to believe that your #12263 manifests similarly to
> #12609, and that a tip tree which contains a fix for #12609 contains
> a fix for #12263; but please, those bugs are not the same, and they
> don't have the same fix.
>
> Hugh
>
>   
Well, like I said: "[I] Don't know". I'm not a kernel developer (or even 
any developer... yet).
I'm just someone that tests the -rc kernels to see if there's any 
problems with my hardware.
I try to report any regressions to lkml, and hopefully help the developers.

To me, who has no knowledge of all these low level issues, the following 
error messages
look strikingly similar with a quick glance.

# bug 12609
# http://marc.info/?l=linux-kernel&m=123254501314058&w=4
#
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
         cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
         res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for UDMA/33
ata2: EH complete

# bug 12263
# http://marc.info/?l=linux-kernel&m=122913412608533&w=4
#
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata2.00: ST_FIRST: !(DRQ|ERR|DF)
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
         cdb 1e 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
         res 50/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
ata2.00: status: { DRDY }
ata2: soft resetting link
ata2.00: configured for UDMA/33
ata2: EH complete

# bug 12609
# http://marc.info/?l=linux-kernel&m=123275478111406&w=4
#
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
         cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
         res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for PIO4
ata2: EH complete

So, will the patch for 12609 fix my issue also, or does there need to be 
another patch?

Justin Madru

Re: [Bug #12263] Sata soft reset filling log

[Sergei Shtylyov]

Hello.

Justin Madru wrote:

>>>> If 12609 is truly a post-2.6.28 regression and 12263 is post-2.6.27
>>>> regresssion, this just cannot be.
>>>>       
>>> Maybe the reporter of #12609 didn't notice/test kernels 28-rc1 to 
>>> 28. Or maybe
>>> the difference in hardware is
>>> the issue, but the bug is still the same. Don't know.
>>>     
>>
>> Sorry Justin, you must be confused: as Sergei says,
>> #12609 and #12263 can only be different.
>>
>> I was one of the reporters of #12609, and I do know it's a post-2.6.28
>> regression (and Larry said so too), and one fix (not the preferred fix)
>> is to revert the ata_bmdma32_port_ops from 2.6.29-rc, and the preferred
>> fix is to improve the ata_sff_data_xfer32() introduced in 2.6.29-rc1.
>>
>> 2.6.28 does not contain any ata_bmdma32_port_ops, nor 
>> ata_sff_data_xfer32(),
>> not did 2.6.28-rc1 contain them.  So it is impossible for the 
>> reversion of
>> the patch that introduced them to fix any problem on 2.6.28.
>>
>> I'm quite prepared to believe that your #12263 manifests similarly to
>> #12609, and that a tip tree which contains a fix for #12609 contains
>> a fix for #12263; but please, those bugs are not the same, and they
>> don't have the same fix.
>>
>> Hugh
>>
>>   
> Well, like I said: "[I] Don't know". I'm not a kernel developer (or 
> even any developer... yet).
> I'm just someone that tests the -rc kernels to see if there's any 
> problems with my hardware.
> I try to report any regressions to lkml, and hopefully help the 
> developers.
>
> To me, who has no knowledge of all these low level issues, the 
> following error messages
> look strikingly similar with a quick glance.
>
> # bug 12609
> # http://marc.info/?l=linux-kernel&m=123254501314058&w=4
> #
> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
>         cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>         res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
> ata2.00: status: { DRDY ERR }
> ata2: soft resetting link
> ata2.00: configured for UDMA/33
> ata2: EH complete
>
> # bug 12263
> # http://marc.info/?l=linux-kernel&m=122913412608533&w=4
> #
> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata2.00: ST_FIRST: !(DRQ|ERR|DF)
> ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
>         cdb 1e 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>         res 50/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)

   Note the different value of the status, error and interrupt reason 
registers: 51/20:03 vs 50/00:01. The former means (unexpected?) status 
phase interrupt with error indication and the sense key NOT READY, the 
latter means (unexpected?) command phase interrupt with no error. IIUC, 
the former happens once the 'sr' driver first sends the TEST UNIT READY 
command while probing the CD/DVD drive, the latter seems to be a result 
of some polling process (originated from userland) -- I'm not seeing 
ALLOW_MEDIUM_REMOVAL anywhere in this driver. So they only look similar, 
I think...


> So, will the patch for 12609 fix my issue also, or does there need to 
> be another patch?

   Most probably it'll need another patch.

> Justin Madru

MBR, Sergei

Re: [Bug #12263] Sata soft reset filling log

[Justin Madru]

Sergei Shtylyov wrote:
> Hello.
>
> Justin Madru wrote:
>
>>>>> If 12609 is truly a post-2.6.28 regression and 12263 is post-2.6.27
>>>>> regresssion, this just cannot be.
>>>>>       
>>>> Maybe the reporter of #12609 didn't notice/test kernels 28-rc1 to 
>>>> 28. Or maybe
>>>> the difference in hardware is
>>>> the issue, but the bug is still the same. Don't know.
>>>>     
>>>
>>> Sorry Justin, you must be confused: as Sergei says,
>>> #12609 and #12263 can only be different.
>>>
>>> I was one of the reporters of #12609, and I do know it's a post-2.6.28
>>> regression (and Larry said so too), and one fix (not the preferred fix)
>>> is to revert the ata_bmdma32_port_ops from 2.6.29-rc, and the preferred
>>> fix is to improve the ata_sff_data_xfer32() introduced in 2.6.29-rc1.
>>>
>>> 2.6.28 does not contain any ata_bmdma32_port_ops, nor 
>>> ata_sff_data_xfer32(),
>>> not did 2.6.28-rc1 contain them.  So it is impossible for the 
>>> reversion of
>>> the patch that introduced them to fix any problem on 2.6.28.
>>>
>>> I'm quite prepared to believe that your #12263 manifests similarly to
>>> #12609, and that a tip tree which contains a fix for #12609 contains
>>> a fix for #12263; but please, those bugs are not the same, and they
>>> don't have the same fix.
>>>
>>> Hugh
>>>
>>>   
>> Well, like I said: "[I] Don't know". I'm not a kernel developer (or 
>> even any developer... yet).
>> I'm just someone that tests the -rc kernels to see if there's any 
>> problems with my hardware.
>> I try to report any regressions to lkml, and hopefully help the 
>> developers.
>>
>> To me, who has no knowledge of all these low level issues, the 
>> following error messages
>> look strikingly similar with a quick glance.
>>
>> # bug 12609
>> # http://marc.info/?l=linux-kernel&m=123254501314058&w=4
>> #
>> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>> ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
>>         cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>>         res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
>> ata2.00: status: { DRDY ERR }
>> ata2: soft resetting link
>> ata2.00: configured for UDMA/33
>> ata2: EH complete
>>
>> # bug 12263
>> # http://marc.info/?l=linux-kernel&m=122913412608533&w=4
>> #
>> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>> ata2.00: ST_FIRST: !(DRQ|ERR|DF)
>> ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
>>         cdb 1e 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>>         res 50/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x2 (HSM 
>> violation)
>
>   Note the different value of the status, error and interrupt reason 
> registers: 51/20:03 vs 50/00:01. The former means (unexpected?) status 
> phase interrupt with error indication and the sense key NOT READY, the 
> latter means (unexpected?) command phase interrupt with no error. 
> IIUC, the former happens once the 'sr' driver first sends the TEST 
> UNIT READY command while probing the CD/DVD drive, the latter seems to 
> be a result of some polling process (originated from userland) -- I'm 
> not seeing ALLOW_MEDIUM_REMOVAL anywhere in this driver. So they only 
> look similar, I think...

And that is why I'm a tester and you're a developer ;) Thanks for the 
info! Next time I'll look closer
and maybe know what I'm actually looking at.
>
>
>> So, will the patch for 12609 fix my issue also, or does there need to 
>> be another patch?
>
>   Most probably it'll need another patch.
So then, #12263 should be reopened and marked as not a duplicate.
Anyways, if tip/master gets merged how it is now then my bug should be 
fixed.

Justin Madru