twitter: linux.kernel - 26 new messages in 14 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* USB: EHCI & UHCI: fix race between root-hub suspend and port resume - 5
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a6559c6a78c8c9b0?hl=en
* Open Intents, lookup_instantiate_filp() And All That Shit(tm) - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/fca0cbdc1743a322?hl=en
* whiteout: jffs2 whiteout support - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cf3d48d7765a24f2?hl=en
* oprofile fixes for v2.6.33 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2915761a5b76e9c7?hl=en
* firewire: net: fix panic in fwnet_write_complete - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cd3e82993aba4f23?hl=en
* clocksource: Prevent potential kgdb dead lock - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
* typo in ./crypto/Kconfig - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/905222266d9257c5?hl=en
* dma: Add barrierless dma mapping/unmapping api - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3756402bfba9b5ed?hl=en
* radeon kms - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/da301c22e0b6fda3?hl=en
* HDA Intel Audio hang on boot - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a0ad5b25d979d11d?hl=en
* ata: Disable NCQ for Crucial M225 brand SSDs - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/89c4d92bc1e1249b?hl=en
* BUG at mm/slab.c:2990 with 2.6.33-rc5-tuxonice - 3 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/fa2f4f9561a0a52a?hl=en
* firewire: ohci: fix crashes with TSB43AB23 on 64bit systems - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/391b26dffa38755f?hl=en
* which fields in /proc/meminfo are orthogonal? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/01c4ea8ee5701c41?hl=en

==============================================================================
TOPIC: USB: EHCI & UHCI: fix race between root-hub suspend and port resume
http://groups.google.com/group/linux.kernel/t/a6559c6a78c8c9b0?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Jan 26 2010 11:40 am
From: Greg KH

2.6.27-stable review patch. If anyone has any objections, please let us know.

------------------

From: Alan Stern <stern@rowland.harvard.edu>

commit cec3a53c7fe794237b582e8e77fc0e48465e65ee upstream.

This patch (as1321) fixes a problem with EHCI and UHCI root-hub
suspends: If the suspend occurs while a port is trying to resume, the
resume doesn't finish and simply gets lost. When remote wakeup is
enabled, this is undesirable behavior.

The patch checks first to see if any port resumes are in progress, and
if they are then it fails the root-hub suspend with -EBUSY.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
drivers/usb/host/ehci-hub.c | 20 +++++++++++++++++++-
drivers/usb/host/uhci-hcd.c | 15 ++++++++++++++-
2 files changed, 33 insertions(+), 2 deletions(-)

--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -119,9 +119,26 @@ static int ehci_bus_suspend (struct usb_
del_timer_sync(&ehci->watchdog);
del_timer_sync(&ehci->iaa_watchdog);

- port = HCS_N_PORTS (ehci->hcs_params);
spin_lock_irq (&ehci->lock);

+ /* Once the controller is stopped, port resumes that are already
+ * in progress won't complete. Hence if remote wakeup is enabled
+ * for the root hub and any ports are in the middle of a resume or
+ * remote wakeup, we must fail the suspend.
+ */
+ if (hcd->self.root_hub->do_remote_wakeup) {
+ port = HCS_N_PORTS(ehci->hcs_params);
+ while (port--) {
+ if (ehci->reset_done[port] != 0) {
+ spin_unlock_irq(&ehci->lock);
+ ehci_dbg(ehci, "suspend failed because "
+ "port %d is resuming\n",
+ port + 1);
+ return -EBUSY;
+ }
+ }
+ }
+
/* stop schedules, clean any completed work */
if (HC_IS_RUNNING(hcd->state)) {
ehci_quiesce (ehci);
@@ -137,6 +154,7 @@ static int ehci_bus_suspend (struct usb_
*/
ehci->bus_suspended = 0;
ehci->owned_ports = 0;
+ port = HCS_N_PORTS(ehci->hcs_params);
while (port--) {
u32 __iomem *reg = &ehci->regs->port_status [port];
u32 t1 = ehci_readl(ehci, reg) & ~PORT_RWC_BITS;
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -750,7 +750,20 @@ static int uhci_rh_suspend(struct usb_hc
spin_lock_irq(&uhci->lock);
if (!test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags))
rc = -ESHUTDOWN;
- else if (!uhci->dead)
+ else if (uhci->dead)
+ ; /* Dead controllers tell no tales */
+
+ /* Once the controller is stopped, port resumes that are already
+ * in progress won't complete. Hence if remote wakeup is enabled
+ * for the root hub and any ports are in the middle of a resume or
+ * remote wakeup, we must fail the suspend.
+ */
+ else if (hcd->self.root_hub->do_remote_wakeup &&
+ uhci->resuming_ports) {
+ dev_dbg(uhci_dev(uhci), "suspend failed because a port "
+ "is resuming\n");
+ rc = -EBUSY;
+ } else
suspend_rh(uhci, UHCI_RH_SUSPENDED);
spin_unlock_irq(&uhci->lock);
return rc;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 5 ==
Date: Tues, Jan 26 2010 11:40 am
From: Greg KH

2.6.27-stable review patch. If anyone has any objections, please let us know.

------------------

From: Dan Carpenter <error27@gmail.com>

commit ece550f51ba175c14ec3ec047815927d7386ea1f upstream.

The "full_alg_name" variable is used on a couple error paths, so we
shouldn't free it until the end.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
fs/ecryptfs/crypto.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1733,7 +1733,7 @@ ecryptfs_process_key_cipher(struct crypt
char *cipher_name, size_t *key_size)
{
char dummy_key[ECRYPTFS_MAX_KEY_BYTES];
- char *full_alg_name;
+ char *full_alg_name = NULL;
int rc;

*key_tfm = NULL;
@@ -1748,7 +1748,6 @@ ecryptfs_process_key_cipher(struct crypt
if (rc)
goto out;
*key_tfm = crypto_alloc_blkcipher(full_alg_name, 0, CRYPTO_ALG_ASYNC);
- kfree(full_alg_name);
if (IS_ERR(*key_tfm)) {
rc = PTR_ERR(*key_tfm);
printk(KERN_ERR "Unable to allocate crypto cipher with name "
@@ -1770,6 +1769,7 @@ ecryptfs_process_key_cipher(struct crypt
goto out;
}
out:
+ kfree(full_alg_name);
return rc;
}

== 3 of 5 ==
Date: Tues, Jan 26 2010 11:40 am
From: Greg KH

2.6.27-stable review patch. If anyone has any objections, please let us know.

------------------

From: Bryn M. Reeves <bmr@redhat.com>

commit bb7d3f24c71e528989501617651b669fbed798cb upstream.

/sys/bus/pci/drivers/megaraid_sas/poll_mode_io defaults to being
world-writable, which seems bad (letting any user affect kernel driver
behavior).

This turns off group and user write permissions, so that on typical
production systems only root can write to it.

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
drivers/scsi/megaraid/megaraid_sas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/megaraid/megaraid_sas.c
+++ b/drivers/scsi/megaraid/megaraid_sas.c
@@ -3462,7 +3462,7 @@ out:
return retval;
}

-static DRIVER_ATTR(poll_mode_io, S_IRUGO|S_IWUGO,
+static DRIVER_ATTR(poll_mode_io, S_IRUGO|S_IWUSR,
megasas_sysfs_show_poll_mode_io,
megasas_sysfs_set_poll_mode_io);

== 4 of 5 ==
Date: Tues, Jan 26 2010 11:40 am
From: Greg KH

2.6.27-stable review patch. If anyone has any objections, please let us know.

------------------

From: Greg Kroah-Hartman <gregkh@suse.de>

commit 703625118069f9f8960d356676662d3db5a9d116 upstream.

We need to keep the lock held over the call to __f_setown() to
prevent a PID race.

Thanks to Al Viro for pointing out the problem, and to Travis for
making us look here in the first place.

Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Julien Tinnes <jln@google.com>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
drivers/char/tty_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -2437,8 +2437,8 @@ static int tty_fasync(int fd, struct fil
pid = task_pid(current);
type = PIDTYPE_PID;
}
- spin_unlock_irqrestore(&tty->ctrl_lock, flags);
retval = __f_setown(filp, pid, type, 0);
+ spin_unlock_irqrestore(&tty->ctrl_lock, flags);
if (retval)
goto out;
} else {

== 5 of 5 ==
Date: Tues, Jan 26 2010 12:00 pm
From: ebiederm@xmission.com (Eric W. Biederman)

Greg KH <gregkh@suse.de> writes:

> 2.6.27-stable review patch. If anyone has any objections, please let us know.

Only that __f_setown by way of f_modown unconditionally enables interrupts. So
without touching f_modown as well in mainline we have nasty sounding lockdep warnings.

Eric

> ------------------
>
> From: Greg Kroah-Hartman <gregkh@suse.de>
>
> commit 703625118069f9f8960d356676662d3db5a9d116 upstream.
>
> We need to keep the lock held over the call to __f_setown() to
> prevent a PID race.
>
> Thanks to Al Viro for pointing out the problem, and to Travis for
> making us look here in the first place.
>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Cc: Al Viro <viro@ZenIV.linux.org.uk>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Tavis Ormandy <taviso@google.com>
> Cc: Jeff Dike <jdike@addtoit.com>
> Cc: Julien Tinnes <jln@google.com>
> Cc: Matt Mackall <mpm@selenic.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
> ---
> drivers/char/tty_io.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/char/tty_io.c
> +++ b/drivers/char/tty_io.c
> @@ -2437,8 +2437,8 @@ static int tty_fasync(int fd, struct fil
> pid = task_pid(current);
> type = PIDTYPE_PID;
> }
> - spin_unlock_irqrestore(&tty->ctrl_lock, flags);
> retval = __f_setown(filp, pid, type, 0);
> + spin_unlock_irqrestore(&tty->ctrl_lock, flags);
> if (retval)
> goto out;
> } else {
--
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/

==============================================================================
TOPIC: Open Intents, lookup_instantiate_filp() And All That Shit(tm)
http://groups.google.com/group/linux.kernel/t/fca0cbdc1743a322?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 11:50 am
From: Al Viro

[fsdevel Cc'd; see the horror story/semi-rant below]

On Tue, Jan 26, 2010 at 12:59:07PM -0500, Mimi Zohar wrote:

> I still don't see that the
> calls to do_filp_open() in the lookup_instantiate_filp(), but will take
> a closer look once these patches are out. Also not sure if there is
> anything in the alloc_file() path.

OK... lookup_instantiate_filp() is a god-awful mess, so it's OK to be
confused by it - its authors definitely had been ;-)

The thing is, currently lookup_instantiate_filp() is called *only* from
call chains starting in do_filp_open(). And place right after
nameidata_to_filp() is downstream from both those call chains and
from the call chain leading from do_filp_open() to dentry_open().

Gory and revolting details follow.

What's happening is easier to understand with code massage done in
vfs-2.6.git#untested; basically, the logics of do_filp_open() (in
_very_ obfuscated form in the mainline kernel) is this:
* find parent directory + last component of pathname
* do "open or create file with this name in that directory" actions
* we can
+ get opened struct file. We are done.
+ get ERR_PTR(-error). Fail.
+ be told that it's a symlink
* try to follow it
+ if it fails, fail.
+ if it's a "direct" symlink a-la procfs, we just get to
open the file it points to. It *will* exist, so O_CREAT|O_EXCL => fail,
and O_CREAT alone gets ignored.
+ if it's a normal symlink, we'd just followed it up to
the last component. Now we have new directory and new filename; repeat
the steps above.

That's the high-level overview. The reason for that kind of loop lies in
the messy semantics of O_CREAT on dangling symlinks; nevermind that part
of the horror show for now.

The really interesting part is opening a file in known directory.
Normal filesystems do d_lookup + either ->lookup() or ->d_revalidate()
+ dentry_open() which will call ->open(). For file creation it may become
d_lookup + either ->lookup() or ->d_revalidate() + ->create() + dentry_open().

*However*, NFS really wants to issue a single request to server that would
do lookup + maybe create + open in one step. Atomically. Fair enough,
but they have a nasty problem - which of existing fs methods would do that?
Neither ->d_revalidate() nor ->lookup() are going to get struct file from
their caller, after all...

Now, the sane solution would be to introduce a new method that would do
lookup-or-d_revalidate+maybe-create+open. With normal filesystems defaulting
to the usual sequence. And have its caller pass all we need to it (struct
file, flags, mode, etc.). That, BTW, is where #untested leads to - a large
part of things done in fs/namei.c:do_last() there will eventually bud off
into default instance of that new method.

However, that's *NOT* what had been done. Instead of that the arguments
(struct file *, etc.) are hidden in struct nameidata and a pointer
to nameidata is added to argument lists of ->d_revalidate(), ->lookup(), etc.
And NFS has added "let's talk to server and try atomic open" into those
methods. If that attempt succeeds, they call a helper
(lookup_instantiate_filp()) that fills the struct file indirectly passed
to the damn thing via pointer in nameidata.

Eventually, we emerge from all that mess back into do_filp_open(). There
we look at the struct file that had been refered to from nameidata and
check if it had already been filled. _THEN_ we do dentry_open() in case
file hadn't been already filled by call of lookup_instantiate_filp() issued
by one of fs methods. That's nameidata_to_filp().

So any call of lookup_instantiate_filp() will be followed by nameidata_to_filp()
and that's where we'll pick the results of the former. If there'd been no
such call (we are on a normal fs, or NFS doesn't feel like doing atomic open
for that one), nameidata_to_filp() will be the place that calls dentry_open().

IOW, the point directly after nameidata_to_filp() is where all those paths
converge. And yes, it's a horrible mess. One I'd been slowly massaging into
saner shape for a year already ;-/

Eventually nameidata_to_filp() and lookup_instantiate_filp() will go to hell
and we'll get one or two methods getting unopened struct file, dentry (unhashed
new one or found in dcache) and the rest of open() arguments. Default will
be to do ->lookup() or ->d_revalidate() + possibly ->create() + dentry_open();
NFS will be able to do its atomic open stuff ending with dentry_open().
In either case we'll get success, error or "it's a symlink, deal with it
yourself" and caller will act accordingly. And that'll be the place to
do any immediately-after-open things, including ima_path_check(). With
only do_filp_open() ever calling that method.
--
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/

==============================================================================
TOPIC: whiteout: jffs2 whiteout support
http://groups.google.com/group/linux.kernel/t/cf3d48d7765a24f2?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 12:00 pm
From: Valerie Aurora

On Mon, Nov 30, 2009 at 02:51:05AM -0500, Erez Zadok wrote:
> In message <1256152779-10054-17-git-send-email-vaurora@redhat.com>, Valerie Aurora writes:
> > From: Felix Fietkau <nbd@openwrt.org>
> >
> > Add support for whiteout dentries to jffs2.
> >
> > Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> > Signed-off-by: Valerie Aurora <vaurora@redhat.com>
> > Cc: David Woodhouse <dwmw2@infradead.org>
> > Cc: linux-mtd@lists.infradead.org
> > ---
> > fs/jffs2/dir.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++-
> > fs/jffs2/fs.c | 4 ++
> > fs/jffs2/super.c | 2 +-
> > include/linux/jffs2.h | 2 +
> > 4 files changed, 82 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/jffs2/dir.c b/fs/jffs2/dir.c
> > index 6f60cc9..46a2e1b 100644
> > --- a/fs/jffs2/dir.c
> > +++ b/fs/jffs2/dir.c
> > @@ -34,6 +34,8 @@ static int jffs2_mknod (struct inode *,struct dentry *,int,dev_t);
> > static int jffs2_rename (struct inode *, struct dentry *,
> > struct inode *, struct dentry *);
> >
> > +static int jffs2_whiteout (struct inode *, struct dentry *, struct dentry *);
> > +
> > const struct file_operations jffs2_dir_operations =
> > {
> > .read = generic_read_dir,
> > @@ -55,6 +57,7 @@ const struct inode_operations jffs2_dir_inode_operations =
> > .rmdir = jffs2_rmdir,
> > .mknod = jffs2_mknod,
> > .rename = jffs2_rename,
> > + .whiteout = jffs2_whiteout,
> > .permission = jffs2_permission,
> > .setattr = jffs2_setattr,
> > .setxattr = jffs2_setxattr,
> > @@ -98,8 +101,18 @@ static struct dentry *jffs2_lookup(struct inode *dir_i, struct dentry *target,
> > fd = fd_list;
> > }
> > }
> > - if (fd)
> > - ino = fd->ino;
> > + if (fd) {
> > + spin_lock(&target->d_lock);
> > + switch(fd->type) {
> > + case DT_WHT:
> > + target->d_flags |= DCACHE_WHITEOUT;
> > + break;
> > + default:
> > + ino = fd->ino;
> > + break;
> > + }
> > + spin_unlock(&target->d_lock);
> > + }
>
> The switch statement above should be simplified into this:
>
> if (fd->type == DT_WHT)
> target->d_flags |= DCACHE_WHITEOUT;
> else
> ino = fd->ino;

This is because later we add a third case for fallthrus, at which
point a switch statement is easier to read. But it is confusing and
distracting by itself in this patch, so I changed it as you suggested.

> > + /* If it's a directory, then check whether it is really empty
> > + */
>
> Format above comment on one line.

Fixxed, thanks.

-VAL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Jan 26 2010 12:10 pm
From: Valerie Aurora

On Mon, Nov 30, 2009 at 03:02:44AM -0500, Erez Zadok wrote:
> In message <1256152779-10054-20-git-send-email-vaurora@redhat.com>, Valerie Aurora writes:
> > From: Jan Blunck <jblunck@suse.de>
> >
> > Add per mountpoint flag for Union Mount support. You need additional patches
> > to util-linux for that to work - see:
> >
> > git://git.kernel.org/pub/scm/utils/util-linux-ng/val/util-linux-ng.git
> >
> > Signed-off-by: Jan Blunck <jblunck@suse.de>
> > Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
> > Signed-off-by: Valerie Aurora <vaurora@redhat.com>
> > ---
> > fs/namespace.c | 5 ++++-
> > include/linux/fs.h | 1 +
> > include/linux/mount.h | 1 +
> > 3 files changed, 6 insertions(+), 1 deletions(-)
> [...]
>
> > diff --git a/include/linux/mount.h b/include/linux/mount.h
> > index 5d52753..e175c47 100644
> > --- a/include/linux/mount.h
> > +++ b/include/linux/mount.h
> > @@ -35,6 +35,7 @@ struct mnt_namespace;
> > #define MNT_SHARED 0x1000 /* if the vfsmount is a shared mount */
> > #define MNT_UNBINDABLE 0x2000 /* if the vfsmount is a unbindable mount */
> > #define MNT_PNODE_MASK 0x3000 /* propagation flag mask */
> > +#define MNT_UNION 0x4000 /* if the vfsmount is a union mount */
>
> I it correct to just add another flag here? How does it relate to this
> 'propagation mask' right above it? If there's some code out there which
> masks out which MNT flags get propagated and which don't, then you need to
> make a decision whether MNT_UNION needs to be propagated as well. Either
> way, please document your decision in a comment here so no one will have to
> ask the same question again.

I sat down and puzzled this out and sent a separate patch to clean up
and comment this part of the code.

== 3 of 3 ==
Date: Tues, Jan 26 2010 12:10 pm
From: Valerie Aurora

On Mon, Nov 30, 2009 at 02:57:30AM -0500, Erez Zadok wrote:
> In message <1256152779-10054-18-git-send-email-vaurora@redhat.com>, Valerie Aurora writes:
> > From: Jan Blunck <jblunck@suse.de>
> >
> > Add a path_whiteout() helper for vfs_whiteout().
> >
> > Signed-off-by: Jan Blunck <jblunck@suse.org>
> > Signed-off-by: Valerie Aurora <vaurora@redhat.com>
> > ---
> > fs/namei.c | 15 ++++++++++++++-
> > include/linux/fs.h | 1 -
> > 2 files changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 9a62c75..408380d 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -2231,7 +2231,7 @@ static inline int may_whiteout(struct inode *dir, struct dentry *victim,
> > * After this returns with success, don't make any assumptions about the inode.
> > * Just dput() it dentry.
> > */
> > -int vfs_whiteout(struct inode *dir, struct dentry *dentry, int isdir)
> > +static int vfs_whiteout(struct inode *dir, struct dentry *dentry, int isdir)
>
> Didn't some other patch introduce vfs_whiteout? So why have a second patch
> which makes vfs_whiteout a static? Why not introduce both vfs_whiteout and
> path_whiteout in one patch?

You're right, I merged those patches.

> > {
> > int err;
> > struct inode *old_inode = dentry->d_inode;
> > @@ -2283,6 +2283,19 @@ int vfs_whiteout(struct inode *dir, struct dentry *dentry, int isdir)
> > return err;
> > }
> >
> > +int path_whiteout(struct path *dir_path, struct dentry *dentry, int isdir)
>
> Please document the behavior of path_whiteout in a proper comment above ii
> (kernel-doc). Describe return values, side effects, etc.

Superseded by improved vfs_whiteout() documentation.

Thanks,

==============================================================================
TOPIC: oprofile fixes for v2.6.33
http://groups.google.com/group/linux.kernel/t/2915761a5b76e9c7?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:10 pm
From: Andrew Morton

On Tue, 26 Jan 2010 13:53:24 +0100 Robert Richter <robert.richter@amd.com> wrote:

> On 25.01.10 23:23:18, Andrew Morton wrote:
> > On Mon, 25 Jan 2010 20:29:22 +0100 Robert Richter <robert.richter@amd.com> wrote:
> >
> > > Suravee Suthikulpanit (1):
> > > oprofile/x86: fix crash when profiling more than 28 events
> >
> > Did you consider a cc:stable on this one?
>
> Yes, will send it to the stable tree after I got the upstream commit
> id.

You don't need to do that - simply add

Cc: <stable@kernel.org>

to the changelog and the -stable guys will later grab the commit by magic.
--
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/

==============================================================================
TOPIC: firewire: net: fix panic in fwnet_write_complete
http://groups.google.com/group/linux.kernel/t/cd3e82993aba4f23?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:20 pm
From: Stefan Richter

Stefan Richter wrote:
> My own testing on a dual core box --- peered with another Linux box
> which ran the older eth1394 --- worked OK so far for transfers of
> massive files (> 4 GiB) back and forth via FTP and ssh running on a text
> console.
>
> But in my first attempt to use FTP on X11 --- i.e. with more concurrent
> interrupt sources --- the firewire-net box crashed very soon. In that
> test I used Dolphin of KDE as FTP client, and the crash already happened
> after Dolphin had loaded and displayed the remote home directory and was
> peeking into files for preview data. I got the following trace:
>
> ------------: cut here ]------------
> kernel: BUG at mm/slab.c:2885!
[...]
> EIP: is at cache_free_debugcheck+0x1e8/0x2e8
[...]
> Call: Trace:
> ? __kfree_skb+0x6e/0x71
> ? kmem_cache_free+0x56/0xb0
> ? __kfree_skb+0x6e/0x71
> ? kfree_skb+0x2b/0x2d
> ? unix_stream_recvmsg+0x3c3/0x48d
> ? file_read_actor+0x74/0xcc
> ? sock_aio_read+0xf2/0x107
> ? do_sync_read+0x89/0xc7

Hi Илья,

I am going to send a pull request for some other unrelated firewire
fixes to Linus about tomorrow.

firewire-net on the other hand needs still more work than my
fwnet_write_complete patch since you and I now get these kmem cache
corruption related bugs.

What is your impression --- does this first incomplete fix decrease the
likelihood of crashes enough to make it worth to include it in a pull
request already? I haven't done more extensive firewire-net tests since
last week yet, hence it is hard to tell for me how severe the new issue
is in practical use.

(Also, I have no idea yet whether I will be quick or slow to find this
other problem and whether it can be fixed in a manner that is suitable
for a mainline merge before 2.6.33 is going to be released.)
--
Stefan Richter
-=====-==-=- ---= ==-=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: clocksource: Prevent potential kgdb dead lock
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 12:20 pm
From: Andrew Morton

On Tue, 26 Jan 2010 14:09:45 GMT tip-bot for Thomas Gleixner <tglx@linutronix.de> wrote:

> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -343,7 +343,19 @@ static void clocksource_resume_watchdog(void)
> {
> unsigned long flags;
>
> - spin_lock_irqsave(&watchdog_lock, flags);
> + /*
> + * We use trylock here to avoid a potential dead lock when
> + * kgdb calls this code after the kernel has been stopped with
> + * watchdog_lock held. When watchdog_lock is held we just
> + * return and accept, that the watchdog might trigger and mark
> + * the monitored clock source (usually TSC) unstable.
> + *
> + * This does not affect the other caller clocksource_resume()
> + * because at this point the kernel is UP, interrupts are
> + * disabled and nothing can hold watchdog_lock.
> + */
> + if (!spin_trylock_irqsave(&watchdog_lock, flags))
> + return;
> clocksource_reset_watchdog();
> spin_unlock_irqrestore(&watchdog_lock, flags);
> }
>
> @@ -458,8 +470,8 @@ void clocksource_resume(void)
> * clocksource_touch_watchdog - Update watchdog
> *
> * Update the watchdog after exception contexts such as kgdb so as not
> - * to incorrectly trip the watchdog.
> - *
> + * to incorrectly trip the watchdog. This might fail when the kernel
> + * was stopped in code which holds watchdog_lock.
> */
> void clocksource_touch_watchdog(void)
> {

It would be neater and a shade more reliable to add a separate
clocksource_try_touch_watchdog() for kgdb's use. Which could be inside
#ifdef CONFIG_KGDB.

== 2 of 2 ==
Date: Tues, Jan 26 2010 12:50 pm
From: Jason Wessel

Andrew Morton wrote:
> On Tue, 26 Jan 2010 14:09:45 GMT tip-bot for Thomas Gleixner <tglx@linutronix.de> wrote:
>
>
>> --- a/kernel/time/clocksource.c
>> +++ b/kernel/time/clocksource.c
>> @@ -343,7 +343,19 @@ static void clocksource_resume_watchdog(void)
>> {
>> unsigned long flags;
>>
>> - spin_lock_irqsave(&watchdog_lock, flags);
>> + /*
>> + * We use trylock here to avoid a potential dead lock when
>> + * kgdb calls this code after the kernel has been stopped with
>> + * watchdog_lock held. When watchdog_lock is held we just
>> + * return and accept, that the watchdog might trigger and mark
>> + * the monitored clock source (usually TSC) unstable.
>> + *
>> + * This does not affect the other caller clocksource_resume()
>> + * because at this point the kernel is UP, interrupts are
>> + * disabled and nothing can hold watchdog_lock.
>> + */
>> + if (!spin_trylock_irqsave(&watchdog_lock, flags))
>> + return;
>> clocksource_reset_watchdog();
>> spin_unlock_irqrestore(&watchdog_lock, flags);
>> }
>>
>> @@ -458,8 +470,8 @@ void clocksource_resume(void)
>> * clocksource_touch_watchdog - Update watchdog
>> *
>> * Update the watchdog after exception contexts such as kgdb so as not
>> - * to incorrectly trip the watchdog.
>> - *
>> + * to incorrectly trip the watchdog. This might fail when the kernel
>> + * was stopped in code which holds watchdog_lock.
>> */
>> void clocksource_touch_watchdog(void)
>> {
>>
>
> It would be neater and a shade more reliable to add a separate
> clocksource_try_touch_watchdog() for kgdb's use. Which could be inside
> #ifdef CONFIG_KGDB.
>
>

The kernel debugger is the only user of this API function so
realistically you do not need a new function, and could simply rename
this one, if the name does not fit.

-- more notes on the problem --

I further diagnosed the problem, and it is reasonably rare that it
happens in the first place. I had an instrumented version of the kernel
debugger which showed the problem happening quite frequently, while
trying to fix hw breakpoints.

The problem is not actually an interprocessor deadlock, but that of
re-entering the spin_lock() when it is already held by the interrupted
task on the same cpu. There is no obvious way that I could see to check
for this specific condition and to abort.

For now the patch Thomas created is sufficient, and given some time
we'll decide how to best live with the side effects or to consider any
further changes.

Jason.

Tested-by: Jason Wessel <jason.wessel@windriver.com>

==============================================================================
TOPIC: typo in ./crypto/Kconfig
http://groups.google.com/group/linux.kernel/t/905222266d9257c5?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:20 pm
From: Toralf Förster

Hello,

line 819 lacks an "e":

"ANSI X9.31 A.2.4. Not this option must be enabled if CRYPTO_FIPS"

, isn't it ?

--
MfG/Sincerely
Toralf Förster
--
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/

==============================================================================
TOPIC: dma: Add barrierless dma mapping/unmapping api
http://groups.google.com/group/linux.kernel/t/3756402bfba9b5ed?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:20 pm
From: Abhijeet Dharmapurikar

FUJITA Tomonori wrote:
> On Tue, 26 Jan 2010 15:30:10 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> On Mon, 2010-01-25 at 18:35 -0800, adharmap@codeaurora.org wrote:
>>> From: Abhijeet Dharmapurikar <adharmap@quicinc.com>
>>>
>
>> There are people nowadays putting AXI bridges and the whole ARM
>> paraphernalia of IP cores behind them on PowerPC cores for example and I
>> can see that happening with x86 as well.
>>
>> In your case, I believe your are fixing the wrong problem anyways. The
>> right approach would be instead to put all your buffer into an sglist
>> and use dma_map/unmap_sg().
>
> Agreed again. That's exactly what I suggested before:
>
> http://marc.info/?l=linux-kernel&m=126294076917753&w=2

I somehow missed your post, my apologies. Agreed that dma_map/unmap_sg
would be the correct api to use here, however they still call the
dmac_.*_range to map buffers. I could change those calls to do a barrier
only after mapping the last buffer. This would be much more cleaner
than introducing a .*_nobarrier API.

Thanks for all the replies.

==============================================================================
TOPIC: radeon kms
http://groups.google.com/group/linux.kernel/t/da301c22e0b6fda3?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:30 pm
From: Alex Deucher

On Tue, Jan 26, 2010 at 9:35 AM, John Kacur <jkacur@redhat.com> wrote:
> On Tue, Jan 26, 2010 at 3:19 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Tue, Jan 26, 2010 at 9:10 AM, John Kacur <jkacur@redhat.com> wrote:
>>> On Tue, Jan 26, 2010 at 2:59 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>> On Tue, Jan 26, 2010 at 8:21 AM, John Kacur <jkacur@redhat.com> wrote:
>>>>>
>>>>>
>>>>> On Fri, 15 Jan 2010, Jerome Glisse wrote:
>>>>>
>>>>>> On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote:
>>>>>> >
>>>>>> >
>>>>>> > On Fri, 15 Jan 2010, John Kacur wrote:
>>>>>> >
>>>>>> > > The oops is triggered because I am missing the firmware for
>>>>>> > > radeon/R700_rlc.bin and
>>>>>> > > radeon/R600_rlc.bin
>>>>>> > >
>>>>>> > > However, I think it should be able to deal with this more gracefully.
>>>>>> > >
>>>>>> > > ATOM BIOS: 9498.11.22.6.0.AS03
>>>>>> > > [drm] Clocks initialized !
>>>>>> > > [drm] Detected VRAM RAM=256M, BAR=256M
>>>>>> > > [drm] RAM width 128bits DDR
>>>>>> > > [TTM] Zone kernel: Available graphics memory: 3050912 kiB.
>>>>>> > > [TTM] Zone dma32: Available graphics memory: 2097152 kiB.
>>>>>> > > [drm] radeon: 256M of VRAM memory ready
>>>>>> > > [drm] radeon: 512M of GTT memory ready.
>>>>>> > > alloc irq_desc for 33 on node -1
>>>>>> > > alloc kstat_irqs on node -1
>>>>>> > > radeon 0000:02:00.0: irq 33 for MSI/MSI-X
>>>>>> > > [drm] radeon: using MSI.
>>>>>> > > [drm] radeon: irq initialized.
>>>>>> > > [drm] GART: num cpu pages 131072, num gpu pages 131072
>>>>>> > > [drm] Loading RV730 Microcode
>>>>>> > > platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin
>>>>>> > > platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin
>>>>>> > > platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin
>>>>>> > > r600_cp: Failed to load firmware "radeon/R700_rlc.bin"
>>>>>> > > [drm:rv770_startup] *ERROR* Failed to load firmware!
>>>>>> > > radeon 0000:02:00.0: ffff8801a20b5400 unpin not necessary
>>>>>> > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
>>>>>> > > IP: [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [ttm]
>>>>>> > > PGD 1a1a74067 PUD 1a19b8067 PMD 0
>>>>>> > > Oops: 0000 [#1] SMP
>>>>>> > > last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading
>>>>>> > > CPU 4
>>>>>> > > Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R
>>>>>> > > RIP: 0010:[<ffffffffa0061034>] [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [t
>>>>>> > > tm]
>>>>>> > > RSP: 0018:ffff8801a1a8fb68 EFLAGS: 00010292
>>>>>> > > RAX: ffff880100000000 RBX: 0000000000000000 RCX: 0000000000000000
>>>>>> > > RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000048
>>>>>> > > RBP: ffff8801a1a8fba8 R08: 0000000000000000 R09: 0000000000000000
>>>>>> > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>>>>> > > R13: ffff8801a8838000 R14: 0000000000000024 R15: 0000000000002000
>>>>>> > > FS: 00007f0f9c6dc700(0000) GS:ffff88002e400000(0000) knlGS:0000000000000000
>>>>>> > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>>>>> > > CR2: 0000000000000048 CR3: 00000001a195d000 CR4: 00000000000006e0
>>>>>> > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>>>> > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>>>>> > > Process modprobe (pid: 168, threadinfo ffff8801a1a8e000, task ffff8801a22c0000)
>>>>>> > > Stack:
>>>>>> > > ffff880100000000 ffff8801a27e2900 ffff8801a1a8fb88 0000000000000000
>>>>>> > > <0> 0000000000000000 ffff8801a8838000 0000000000000024 0000000000002000
>>>>>> > > <0> ffff8801a1a8fbd8 ffffffffa00ba05b ffff8801a1a8fbd8 ffff8801a27f4000
>>>>>> > > Call Trace:
>>>>>> > > [<ffffffffa00ba05b>] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon]
>>>>>> > > [<ffffffffa00bb441>] rv770_suspend+0x43/0x69 [radeon]
>>>>>> > > [<ffffffffa00bb6cf>] rv770_init+0x1a4/0x22d [radeon]
>>>>>> > > [<ffffffffa0089593>] radeon_device_init+0x27f/0x300 [radeon]
>>>>>> > > [<ffffffffa008a0fb>] radeon_driver_load_kms+0xff/0x184 [radeon]
>>>>>> > > [<ffffffffa001e1a6>] drm_get_dev+0x3c4/0x4c5 [drm]
>>>>>> > > [<ffffffff8122ea73>] ? pci_match_device+0x22/0xd0
>>>>>> > > [<ffffffffa00c3bb8>] radeon_pci_probe+0x15/0x268 [radeon]
>>>>>> > > [<ffffffff8122e941>] local_pci_probe+0x17/0x1b
>>>>>> > > [<ffffffff8122f721>] pci_device_probe+0xcd/0xfd
>>>>>> > > [<ffffffff812ce793>] ? driver_sysfs_add+0x4c/0x71
>>>>>> > > [<ffffffff812ce95c>] driver_probe_device+0xde/0x1fe
>>>>>> > > [<ffffffff812cead9>] __driver_attach+0x5d/0x81
>>>>>> > > [<ffffffff812cea7c>] ? __driver_attach+0x0/0x81
>>>>>> > > [<ffffffff812cdded>] bus_for_each_dev+0x59/0x8e
>>>>>> > > [<ffffffff812ce6f2>] driver_attach+0x1e/0x20
>>>>>> > > [<ffffffff812ce330>] bus_add_driver+0xd8/0x240
>>>>>> > > [<ffffffff812cedcb>] driver_register+0x9d/0x10e
>>>>>> > > [<ffffffff8122f969>] __pci_register_driver+0x68/0xd8
>>>>>> > > [<ffffffff81439aa2>] ? printk+0x41/0x47
>>>>>> > > [<ffffffffa00f7000>] ? radeon_init+0x0/0xc1 [radeon]
>>>>>> > > [<ffffffffa0018eb3>] drm_init+0x75/0xdb [drm]
>>>>>> > > [<ffffffffa00f7000>] ? radeon_init+0x0/0xc1 [radeon]
>>>>>> > > [<ffffffffa00f70bf>] radeon_init+0xbf/0xc1 [radeon]
>>>>>> > > [<ffffffff81002069>] do_one_initcall+0x5e/0x15e
>>>>>> > > [<ffffffff81087788>] sys_init_module+0xd8/0x23a
>>>>>> > > [<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
>>>>>> > > Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5
>>>>>> > > 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 <4c> 8b 27 48 89 fb 41 88
>>>>>> > > f5 41 88 d6 41 88 cf 44 89 45 c8 49 81
>>>>>> > > RIP [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [ttm]
>>>>>> > > RSP <ffff8801a1a8fb68>
>>>>>> > > CR2: 0000000000000048
>>>>>> > > ---[ end trace 604e2e318733e108 ]---
>>>>>> > > udevd-work[166]: '/sbin/modprobe -b pci:v00001002d00009498sv00001043sd00000300bc
>>>>>> > > 03sc00i00' unexpected exit with status 0x0009
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>> > I forgot to mention that this is kernel version 2.6.33-rc4.
>>>>>> >
>>>>>> > Thanks.
>>>>>>
>>>>>> Yes, we didn't paid enough attention to failure path :( Sorry for that
>>>>>> Fix should be in next rc, patch is:
>>>>>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=30d2d9a54d48e4fefede0389ded1b6fc2d44a522
>>>>>>
>>>>>
>>>>> I think your fix didn't make it to 2.6.33-rc5 because I'm still oopsing
>>>>> when I don't grab the firmware from the internet. (instead of merely
>>>>> reverting to vga mode).
>>>>>
>>>>> Furthermore, why is the firmware not shipped with the kernel?
>>>>> I never needed to fetch firmware for the 2.6.31 kernels and my graphic
>>>>> card worked fine.
>>>>>
>>>>> Am I right to conclude that the license is a problem?
>>>>> http://people.freedesktop.org/~agd5f/radeon_ucode/LICENSE.radeon
>>>>>
>>>>> This is a huge step backwards if we are exchanging a working driver with
>>>>> what shipped with the linux kernel to one that only works with blobs that
>>>>> don't ship with the kernel.
>>>>
>>>> In general, microcode is slowly being moved out of the kernel and into
>>>> the Linux firmware tree:
>>>> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree
>>>> Eventually all of the radeon microcode will end up out up in that tree.
>>>>
>>>
>>> Okay, but why are R600_rlc.bin R700_rlc.bin in particular missing
>>> from the firmware?
>>>
>>
>> Missing from where? We aren't adding any new microcode to the kernel
>> source and they haven't made it into the firmware tree yet. Until
>> they end up in the firmware tree, you need to grab them from:
>> http://people.freedesktop.org/~agd5f/radeon_ucode
>>
>
> I meant why are they missing from the firmware tree? What is holding that up?

Just hasn't been done yet.

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

==============================================================================
TOPIC: HDA Intel Audio hang on boot
http://groups.google.com/group/linux.kernel/t/a0ad5b25d979d11d?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 12:30 pm
From: Takashi Iwai

At Tue, 26 Jan 2010 19:22:35 +0100,
Rafael J. Wysocki wrote:
>
> On Tuesday 26 January 2010, Sid Boyce wrote:
> > On 26/01/10 12:55, Takashi Iwai wrote:
> > > At Tue, 26 Jan 2010 12:02:44 +0000,
> > > Sid Boyce wrote:
> > >>
> > >> On 26/01/10 06:58, Takashi Iwai wrote:
> > >>> At Tue, 26 Jan 2010 07:40:03 +0100,
> > >>> I wrote:
> > >>>>
> > >>>> At Tue, 26 Jan 2010 00:59:15 +0000,
> > >>>> Sid Boyce wrote:
> > >>>>>
> > >>>>> On 25/01/10 21:55, Takashi Iwai wrote:
> > >>>>>> At Mon, 25 Jan 2010 22:54:23 +0100,
> > >>>>>> I wrote:
> > >>>>>>>
> > >>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100,
> > >>>>>>> Rafael J. Wysocki wrote:
> > >>>>>>>>
> > >>>>>>>> On Monday 25 January 2010, Sid Boyce wrote:
> > >>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote:
> > >>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get
> > >>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio
> > >>>>>>>>> is not disabled in the BIOS.
> > >>>>>>>>
> > >>>>>>>> I guess we should let Takashi know.
> > >>>>>>>
> > >>>>>>> Thanks.
> > >>>>>>>
> > >>>>>>>>>> tindog:~ # uname -r
> > >>>>>>>>>> 2.6.33-rc4-smp
> > >>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:-
> > >>>>>>>>>> oss.card_id = 'HDA NVidia'
> > >>>>>>>>>> oss.card_id = 'HDA NVidia'
> > >>>>>>>>>> oss.card_id = 'HDA NVidia'
> > >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> > >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> > >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> > >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> > >>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device'
> > >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> > >>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device'
> > >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> > >>>>>>>>>> info.product = 'HDA NVidia Sound Card'
> > >>>>>>>>>> sound.card_id = 'HDA NVidia'
> > >>>>>>>>>> info.linux.driver = 'HDA Intel'
> > >>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel
> > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> > >>>>>>>>>> HDA Intel: module = snd_hda_intel
> > >>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel"
> > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> > >>>>>>>>>> HDA Intel: module = snd_hda_intel
> > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> > >>>>>>>>>> HDA Intel: module = snd_hda_intel
> > >>>>>>>>>> E: DRIVER=HDA Intel
> > >>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level,
> > >>>>>>>>>> low) -> IRQ 22
> > >>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64
> > >>>>>>>>>> Driver: "HDA Intel"
> > >>>>>>>
> > >>>>>>> What I'd try first is to pass enable_msi=0 option.
> > >>>>>>
> > >>>>>> Just to be sure -- it's an option for snd-hda-intel module.
> > >>>>>>
> > >>>>>>
> > >>>>>> Takashi
> > >>>>>>
> > >>>>>
> > >>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command
> > >>>>> line,
> > >>>
> > >>> Oh, I overlooked this text. Of course, this can't work :)
> > >>>
> > >>> "modprobe..." isn't for the kernel command line but for modprobe
> > >>> configs, usually specified in /etc/modprobe.d/* file.
> > >>>
> > >> I had already tried that... it locks up at the same point also with
> > >> "enable_msi=1".
> > >> tindog:/etc/modprobe.d # less 50-sound.conf
> > >>
> > >> options snd slots=snd-hda-intel,enable_msi=0
> > >
> > > This is the option for module snd, not snd-hda-intel.
> > >
> > >
> > > Takashi
> > >
> > options snd,enable_msi=0 slots=snd-hda-intel
>
> options snd enable_msi=0 slots=snd-hda-intel
>
> (ie. the comma shouldn't be present in there).

Heh, not quite right :)
You need just a new line containing:

options snd-hda-intel enable_msi=0

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Jan 26 2010 1:00 pm
From: Sid Boyce

On 26/01/10 20:25, Takashi Iwai wrote:
> At Tue, 26 Jan 2010 19:22:35 +0100,
> Rafael J. Wysocki wrote:
>>
>> On Tuesday 26 January 2010, Sid Boyce wrote:
>>> On 26/01/10 12:55, Takashi Iwai wrote:
>>>> At Tue, 26 Jan 2010 12:02:44 +0000,
>>>> Sid Boyce wrote:
>>>>>
>>>>> On 26/01/10 06:58, Takashi Iwai wrote:
>>>>>> At Tue, 26 Jan 2010 07:40:03 +0100,
>>>>>> I wrote:
>>>>>>>
>>>>>>> At Tue, 26 Jan 2010 00:59:15 +0000,
>>>>>>> Sid Boyce wrote:
>>>>>>>>
>>>>>>>> On 25/01/10 21:55, Takashi Iwai wrote:
>>>>>>>>> At Mon, 25 Jan 2010 22:54:23 +0100,
>>>>>>>>> I wrote:
>>>>>>>>>>
>>>>>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100,
>>>>>>>>>> Rafael J. Wysocki wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Monday 25 January 2010, Sid Boyce wrote:
>>>>>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote:
>>>>>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get
>>>>>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio
>>>>>>>>>>>> is not disabled in the BIOS.
>>>>>>>>>>>
>>>>>>>>>>> I guess we should let Takashi know.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>>>>> tindog:~ # uname -r
>>>>>>>>>>>>> 2.6.33-rc4-smp
>>>>>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:-
>>>>>>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device'
>>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device'
>>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>>> info.product = 'HDA NVidia Sound Card'
>>>>>>>>>>>>> sound.card_id = 'HDA NVidia'
>>>>>>>>>>>>> info.linux.driver = 'HDA Intel'
>>>>>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel
>>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel"
>>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>>>>>>> E: DRIVER=HDA Intel
>>>>>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level,
>>>>>>>>>>>>> low) -> IRQ 22
>>>>>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64
>>>>>>>>>>>>> Driver: "HDA Intel"
>>>>>>>>>>
>>>>>>>>>> What I'd try first is to pass enable_msi=0 option.
>>>>>>>>>
>>>>>>>>> Just to be sure -- it's an option for snd-hda-intel module.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Takashi
>>>>>>>>>
>>>>>>>>
>>>>>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command
>>>>>>>> line,
>>>>>>
>>>>>> Oh, I overlooked this text. Of course, this can't work :)
>>>>>>
>>>>>> "modprobe..." isn't for the kernel command line but for modprobe
>>>>>> configs, usually specified in /etc/modprobe.d/* file.
>>>>>>
>>>>> I had already tried that... it locks up at the same point also with
>>>>> "enable_msi=1".
>>>>> tindog:/etc/modprobe.d # less 50-sound.conf
>>>>>
>>>>> options snd slots=snd-hda-intel,enable_msi=0
>>>>
>>>> This is the option for module snd, not snd-hda-intel.
>>>>
>>>>
>>>> Takashi
>>>>
>>> options snd,enable_msi=0 slots=snd-hda-intel
>>
>> options snd enable_msi=0 slots=snd-hda-intel
>>
>> (ie. the comma shouldn't be present in there).
>
> Heh, not quite right :)
> You need just a new line containing:
>
> options snd-hda-intel enable_msi=0
>
>
> Takashi
>
Apologies, with the following it boots successfully.
options slots=snd-hda-intel
# 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio
alias snd-card-0 snd-hda-intel
options snd-hda-intel enable_msi=0

Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

== 3 of 3 ==
Date: Tues, Jan 26 2010 1:00 pm
From: Sid Boyce

I forgot to mention 2.6.33-rc5 now boots successfully.
Regards
Sid.

On 26/01/10 18:22, Rafael J. Wysocki wrote:
> On Tuesday 26 January 2010, Sid Boyce wrote:
>> On 26/01/10 12:55, Takashi Iwai wrote:
>>> At Tue, 26 Jan 2010 12:02:44 +0000,
>>> Sid Boyce wrote:
>>>>
>>>> On 26/01/10 06:58, Takashi Iwai wrote:
>>>>> At Tue, 26 Jan 2010 07:40:03 +0100,
>>>>> I wrote:
>>>>>>
>>>>>> At Tue, 26 Jan 2010 00:59:15 +0000,
>>>>>> Sid Boyce wrote:
>>>>>>>
>>>>>>> On 25/01/10 21:55, Takashi Iwai wrote:
>>>>>>>> At Mon, 25 Jan 2010 22:54:23 +0100,
>>>>>>>> I wrote:
>>>>>>>>>
>>>>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100,
>>>>>>>>> Rafael J. Wysocki wrote:
>>>>>>>>>>
>>>>>>>>>> On Monday 25 January 2010, Sid Boyce wrote:
>>>>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote:
>>>>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get
>>>>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio
>>>>>>>>>>> is not disabled in the BIOS.
>>>>>>>>>>
>>>>>>>>>> I guess we should let Takashi know.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>>>> tindog:~ # uname -r
>>>>>>>>>>>> 2.6.33-rc4-smp
>>>>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:-
>>>>>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device'
>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device'
>>>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>>>> info.product = 'HDA NVidia Sound Card'
>>>>>>>>>>>> sound.card_id = 'HDA NVidia'
>>>>>>>>>>>> info.linux.driver = 'HDA Intel'
>>>>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel
>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel"
>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>>>>>> E: DRIVER=HDA Intel
>>>>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level,
>>>>>>>>>>>> low) -> IRQ 22
>>>>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64
>>>>>>>>>>>> Driver: "HDA Intel"
>>>>>>>>>
>>>>>>>>> What I'd try first is to pass enable_msi=0 option.
>>>>>>>>
>>>>>>>> Just to be sure -- it's an option for snd-hda-intel module.
>>>>>>>>
>>>>>>>>
>>>>>>>> Takashi
>>>>>>>>
>>>>>>>
>>>>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command
>>>>>>> line,
>>>>>
>>>>> Oh, I overlooked this text. Of course, this can't work :)
>>>>>
>>>>> "modprobe..." isn't for the kernel command line but for modprobe
>>>>> configs, usually specified in /etc/modprobe.d/* file.
>>>>>
>>>> I had already tried that... it locks up at the same point also with
>>>> "enable_msi=1".
>>>> tindog:/etc/modprobe.d # less 50-sound.conf
>>>>
>>>> options snd slots=snd-hda-intel,enable_msi=0
>>>
>>> This is the option for module snd, not snd-hda-intel.
>>>
>>>
>>> Takashi
>>>
>> options snd,enable_msi=0 slots=snd-hda-intel
>
> options snd enable_msi=0 slots=snd-hda-intel
>
> (ie. the comma shouldn't be present in there).
>
>> # 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio
>> alias snd-card-0 snd-hda-intel
>
> Rafael
>

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

==============================================================================
TOPIC: ata: Disable NCQ for Crucial M225 brand SSDs
http://groups.google.com/group/linux.kernel/t/89c4d92bc1e1249b?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 12:40 pm
From: Willy Tarreau

On Tue, Jan 26, 2010 at 09:49:18PM +0530, Vishal Rao wrote:
> At least one user of Intel SSDs reports no issues with existing
> kernels and I've read that
> they do NCQ right.

FWIW, I can confirm that both the 40 and 80 GB X25-M V2 work like
a charm on 2.6.32 here (main desktop and netbook).

Willy

== 2 of 2 ==
Date: Tues, Jan 26 2010 1:00 pm
From: David Rees

On Tue, Jan 26, 2010 at 8:19 AM, Vishal Rao <vishalrao@gmail.com> wrote:
> 2010/1/26 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>>> Should work with 64, 128 (tested) and 256 GB capacities with any
>>> firmware versions in
>>> drivers/ata/libata-core.c because of ATA errors in dmesg, hangs and
>>> filesystem corruption.
>>
>> If you've only tested one type why list all three ? Also you've not
>> listed a firmware version so do you know which are affected ?
>>
>> What controllers did you test with ?
>
> The 3 IDs should match I believe and the firmware parameter is NULL.
> Affected firmware versions include at least the latest 1916 and the
> previous 1819, likely older ones as well.
>
> Tested with my own Crucial CT128M225 model which has the IndiLinx
> Barefoot controller.
>
> The libata-core.c file has an existing line for "OCZ_CORESSD" for a
> particular firmware version
> but I suspect many, if not all of those controllers may have this issue?
> At least one user of Intel SSDs reports no issues with existing
> kernels and I've read that
> they do NCQ right.

A lot of different SSDs use the Indilinx Barefoot controller and the
firmware between each should be nearly identical.

Have there been any other reports of NCQ issues with similar Crucial
drives or Indilinx?

I would be hesitant to apply this branch to the trunk without seeing
at least a couple other cases of issues.

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

==============================================================================
TOPIC: BUG at mm/slab.c:2990 with 2.6.33-rc5-tuxonice
http://groups.google.com/group/linux.kernel/t/fa2f4f9561a0a52a?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 12:40 pm
From: Nigel Cunningham

Hi.

Pedro Ribeiro wrote:
> Hi,
>
> I hit a bug at mm/slab.c:2990 with .33-rc5.
> Unfortunately nothing more is available than a screen picture with a
> crash dump, although it is a good one.
> The bug was hit almost at the end of a hibernation cycle with
> Tux-on-Ice, while saving memory contents to an encrypted swap
> partition.
>
> The image is here http://img264.imageshack.us/img264/9634/mmslab.jpg (150 kb)
>
> Hopefully it is of any use for you. Please let me know if you need any
> more info.

Looks to me to be completely unrelated to TuxOnIce - at least at a first
glance.

Ccing the slab allocator maintainers listed in MAINTAINERS.

Regards,

Nigel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Jan 26 2010 1:00 pm
From: Matt Mackall

On Wed, 2010-01-27 at 07:39 +1100, Nigel Cunningham wrote:
> Hi.
>
> Pedro Ribeiro wrote:
> > Hi,
> >
> > I hit a bug at mm/slab.c:2990 with .33-rc5.
> > Unfortunately nothing more is available than a screen picture with a
> > crash dump, although it is a good one.
> > The bug was hit almost at the end of a hibernation cycle with
> > Tux-on-Ice, while saving memory contents to an encrypted swap
> > partition.
> >
> > The image is here http://img264.imageshack.us/img264/9634/mmslab.jpg (150 kb)
> >
> > Hopefully it is of any use for you. Please let me know if you need any
> > more info.
>
> Looks to me to be completely unrelated to TuxOnIce - at least at a first
> glance.
>
> Ccing the slab allocator maintainers listed in MAINTAINERS.

Not sure if this will do us any good, it's the second oops.

--
http://selenic.com : development and support for Mercurial and Linux

== 3 of 3 ==
Date: Tues, Jan 26 2010 1:00 pm
From: Pekka Enberg

Matt Mackall wrote:
> On Wed, 2010-01-27 at 07:39 +1100, Nigel Cunningham wrote:
>> Hi.
>>
>> Pedro Ribeiro wrote:
>>> Hi,
>>>
>>> I hit a bug at mm/slab.c:2990 with .33-rc5.
>>> Unfortunately nothing more is available than a screen picture with a
>>> crash dump, although it is a good one.
>>> The bug was hit almost at the end of a hibernation cycle with
>>> Tux-on-Ice, while saving memory contents to an encrypted swap
>>> partition.
>>>
>>> The image is here http://img264.imageshack.us/img264/9634/mmslab.jpg (150 kb)
>>>
>>> Hopefully it is of any use for you. Please let me know if you need any
>>> more info.
>> Looks to me to be completely unrelated to TuxOnIce - at least at a first
>> glance.
>>
>> Ccing the slab allocator maintainers listed in MAINTAINERS.
>
> Not sure if this will do us any good, it's the second oops.

Looks like slab corruption to me which is usually not a slab bug but
caused by buggy callers. Is CONFIG_DEBUG_SLAB enabled?
--
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/

==============================================================================
TOPIC: firewire: ohci: fix crashes with TSB43AB23 on 64bit systems
http://groups.google.com/group/linux.kernel/t/391b26dffa38755f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 12:40 pm
From: Stefan Richter

Unsurprisingly, Texas Instruments TSB43AB23 exhibits the same behaviour
as TSB43AB22/A in dual buffer IR DMA mode: If descriptors are located
at physical addresses above the 31 bit address range (2 GB), the
controller will overwrite random memory. With luck, this merely
prevents video reception. With only a little less luck, the machine
crashes.

We use the same workaround here as with TSB43AB22/A: Switch off the
dual buffer capability flag and use packet-per-buffer IR DMA instead.
Another possible workaround would be to limit the coherent DMA mask to
31 bits.

In Linux 2.6.33, this change serves effectively only as documentation
since dual buffer mode is not used for any controller anymore. But
somebody might want to re-enable it in the future to make use of
features of dual buffer DMA that are not available in packet-per-buffer
mode.

In Linux 2.6.32 and older, this update is vital for anyone with this
controller, more than 2 GB RAM, a 64 bit kernel, and FireWire video or
audio applications.

We have at least four reports:
http://bugzilla.kernel.org/show_bug.cgi?id=13808
http://marc.info/?l=linux1394-user&m=126154279004083
https://bugzilla.redhat.com/show_bug.cgi?id=552142
http://marc.info/?l=linux1394-user&m=126432246128386

Reported-by: Paul Johnson
Reported-by: Ronneil Camara
Reported-by: G Zornetzer
Reported-by: Mark Thompson
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/firewire/ohci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

Index: linux/drivers/firewire/ohci.c
===================================================================
--- linux.orig/drivers/firewire/ohci.c
+++ linux/drivers/firewire/ohci.c
@@ -2420,6 +2420,7 @@ static void ohci_pmac_off(struct pci_dev

#define PCI_VENDOR_ID_AGERE PCI_VENDOR_ID_ATT
#define PCI_DEVICE_ID_AGERE_FW643 0x5901
+#define PCI_DEVICE_ID_TI_TSB43AB23 0x8024

static int __devinit pci_probe(struct pci_dev *dev,
const struct pci_device_id *ent)
@@ -2488,7 +2489,8 @@ static int __devinit pci_probe(struct pc
#if !defined(CONFIG_X86_32)
/* dual-buffer mode is broken with descriptor addresses above 2G */
if (dev->vendor == PCI_VENDOR_ID_TI &&
- dev->device == PCI_DEVICE_ID_TI_TSB43AB22)
+ (dev->device == PCI_DEVICE_ID_TI_TSB43AB22 ||
+ dev->device == PCI_DEVICE_ID_TI_TSB43AB23))
ohci->use_dualbuffer = false;

twitter

Tuesday, January 26, 2010

linux.kernel - 26 new messages in 14 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts