Re: [PATCH 28/30] r/o bind mounts: track numbers of writers to mounts
On Mon, 2008-02-18 at 17:10 +0100, Miklos Szeredi wrote:
>
> > + /*
> > + * We don't have to hold all of the locks at the
> > + * same time here because we know that we're the
> > + * last reference to mnt and that no new writers
> > + * can come in.
> > + */
> > + for_each_possible_cpu(cpu) {
> > + struct mnt_writer *cpu_writer = _cpu(mnt_writers, cpu);
> > + if (cpu_writer->mnt != mnt)
> > + continue;
> > + spin_lock(_writer->lock);
> > + atomic_add(cpu_writer->count, >__mnt_writers);
> > + cpu_writer->count = 0;
>
> I think you should also add a
>
> cpu_writer->mnt = NULL;
>
> here. It's not a bug, but I had to think a bit about why it's not a
> bug.
Yeah, I kinda copied the code from __clear_mnt_count() where keeping
->mnt is actually a mini optimization. But, there is certainly no
chance of that mnt popping up again after a __mntput(), so I clear it in
there now. I also added a comment explaining.
-- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add the debugfs interface for the sysprof tool
On Wed, 20 Feb 2008 21:58:42 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-02-20 at 11:26 -0800, Arjan van de Ven wrote: > > > feel free to reinvent a whole GUI just to avoid a 200 line kernel > > module. sysprof is here. it works. > > > the gui is REALLY nice. > > I guess we have to agree to disagree here. Its plain useless from my > POV. that's fine. Different tools for different people. sysprof isn't aimed at kernel developers. "If all you have is an allen wrench, everything looks like Ikea" it's ok to have different tools for really different things -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008, Pierre Ossman wrote: > > And why not simply fail the suspend if the resume routine doesn't exist > > and the suspend routine does? Maybe with an error message in the > > system log. > > For the asymmetric case, I guess that would do. But I still want to remove > devices when the bus handler has no suspend handling. Then it appears the correct approach is to use the new device_pm_schedule_removal() routine. It schedules the removal of a suspended device for a time when the system suspend is over. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] redo locking of tty->pgrp
Historically tty->pgrp and friends were pid_t and the code "knew" they
were safe. The change to pid structs opened up a few races and the
removal of the BKL in places made them quite hittable. We put tty->pgrp
under the ctrl_lock for the tty.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/tty_io.c
linux-2.6.25-rc2-mm1/drivers/char/tty_io.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/tty_io.c 2008-02-19
11:03:26.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/tty_io.c 2008-02-20 12:31:54.0
+
@@ -1162,26 +1162,37 @@
* not in the foreground, send a SIGTTOU. If the signal is blocked or
* ignored, go ahead and perform the operation. (POSIX 7.2)
*
- * Locking: none - FIXME: review this
+ * Locking: ctrl_lock - FIXME: review this
*/
int tty_check_change(struct tty_struct *tty)
{
+ unsigned long flags;
+ int ret = 0;
+
if (current->signal->tty != tty)
return 0;
+
+ spin_lock_irqsave(>ctrl_lock, flags);
+
if (!tty->pgrp) {
printk(KERN_WARNING "tty_check_change: tty->pgrp == NULL!\n");
- return 0;
+ goto out;
}
if (task_pgrp(current) == tty->pgrp)
- return 0;
+ goto out;
if (is_ignored(SIGTTOU))
- return 0;
- if (is_current_pgrp_orphaned())
- return -EIO;
+ goto out;
+ if (is_current_pgrp_orphaned()) {
+ ret = -EIO;
+ goto out;
+ }
kill_pgrp(task_pgrp(current), SIGTTOU, 1);
set_thread_flag(TIF_SIGPENDING);
- return -ERESTARTSYS;
+ ret = -ERESTARTSYS;
+out:
+ spin_unlock_irqrestore(>ctrl_lock, flags);
+ return ret;
}
EXPORT_SYMBOL(tty_check_change);
@@ -1361,6 +1372,7 @@
struct task_struct *p;
struct tty_ldisc *ld;
intclosecount = 0, n;
+ unsigned long flags;
if (!tty)
return;
@@ -1437,19 +1449,24 @@
__group_send_sig_info(SIGHUP, SEND_SIG_PRIV, p);
__group_send_sig_info(SIGCONT, SEND_SIG_PRIV, p);
put_pid(p->signal->tty_old_pgrp); /* A noop */
+ spin_lock_irqsave(>ctrl_lock, flags);
if (tty->pgrp)
p->signal->tty_old_pgrp = get_pid(tty->pgrp);
+ spin_unlock_irqrestore(>ctrl_lock, flags);
spin_unlock_irq(>sighand->siglock);
} while_each_pid_task(tty->session, PIDTYPE_SID, p);
}
read_unlock(_lock);
+ spin_lock_irqsave(>ctrl_lock, flags);
tty->flags = 0;
put_pid(tty->session);
put_pid(tty->pgrp);
tty->session = NULL;
tty->pgrp = NULL;
tty->ctrl_status = 0;
+ spin_unlock_irqrestore(>ctrl_lock, flags);
+
/*
* If one of the devices matches a console pointer, we
* cannot just call hangup() because that will cause
@@ -1624,10 +1641,13 @@
/* It is possible that do_tty_hangup has free'd this tty */
tty = get_current_tty();
if (tty) {
+ unsigned long flags;
+ spin_lock_irqsave(>ctrl_lock, flags);
put_pid(tty->session);
put_pid(tty->pgrp);
tty->session = NULL;
tty->pgrp = NULL;
+ spin_unlock_irqrestore(>ctrl_lock, flags);
} else {
#ifdef TTY_DEBUG_HANGUP
printk(KERN_DEBUG "error attempted to write to tty [0x%p]"
@@ -1743,10 +1763,8 @@
* for hung up devices before calling the line discipline method.
*
* Locking:
- * Locks the line discipline internally while needed
- * For historical reasons the line discipline read method is
- * invoked under the BKL. This will go away in time so do not rely on it
- * in new code. Multiple read calls may be outstanding in parallel.
+ * Locks the line discipline internally while needed. Multiple
+ * read calls may be outstanding in parallel.
*/
static ssize_t tty_read(struct file *file, char __user *buf, size_t count,
@@ -2846,6 +2992,7 @@
static int tty_fasync(int fd, struct file *filp, int on)
{
struct tty_struct *tty;
+ unsigned long flags;
int retval;
tty = (struct tty_struct *)filp->private_data;
@@ -2861,6 +3008,7 @@
struct pid *pid;
if (!waitqueue_active(>read_wait))
tty->minimum_to_wake = 1;
+ spin_lock_irqsave(>ctrl_lock, flags);
if (tty->pgrp) {
pid = tty->pgrp;
type = PIDTYPE_PGID;
@@ -2868,6 +3016,7 @@
pid = task_pid(current);
type = PIDTYPE_PID;
Re: [PATCH] mmu notifiers #v6
On Wed, Feb 20, 2008 at 11:39:42AM +0100, Andrea Arcangeli wrote: > Given Nick's comments I ported my version of the mmu notifiers to > latest mainline. There are no known bugs AFIK and it's obviously safe > (nothing is allowed to schedule inside rcu_read_lock taken by > mmu_notifier() with my patch). > I ported the GRU driver to use the latest #v6 patch and ran a series of tests on it using our system simulator. The simulator is slow so true stress or swapping is not possible - at least within a finite amount of time. Functionally, the #v6 patch seems to work for the GRU. However, I did notice two significant differences that make the #v6 performance worse for the GRU than Christoph's patch. I think one difference is easily fixable but the other is more difficult: - the location of the mmu_notifier_release() callout is at a different place in the 2 patches. Christoph has the callout BEFORE the call to unmap_vmas() whereas you have it AFTER. The net result is that the GRU does a LOT of 1-page TLB flushes during process teardown. These flushes are not done with Christops's patch. - the range callouts in Christoph's patch benefit the GRU because multiple TLB entries can be flushed with a single GRU instruction (the GRU hardware supports a range flush using a vaddr & length). The #v6 patch does a TLB flush for each page in the range. Flushing on the GRU is slow so being able to flush multiple pages with a single request is a benefit. Seems like the latter difference could be significant for other users of mmu notifiers. --- jack -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nfs: fix sparse warnings
fs/nfs/nfs4state.c:788:34: warning: Using plain integer as NULL pointer
fs/nfs/delegation.c:52:34: warning: Using plain integer as NULL pointer
fs/nfs/idmap.c:312:12: warning: Using plain integer as NULL pointer
fs/nfs/callback_xdr.c:257:6: warning: Using plain integer as NULL pointer
fs/nfs/callback_xdr.c:270:6: warning: Using plain integer as NULL pointer
fs/nfs/callback_xdr.c:281:6: warning: Using plain integer as NULL pointer
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Rollup patches 1-4.
fs/nfs/callback_xdr.c |6 +++---
fs/nfs/delegation.c |2 +-
fs/nfs/idmap.c|2 +-
fs/nfs/nfs4state.c|2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/nfs/callback_xdr.c b/fs/nfs/callback_xdr.c
index c63eb72..13619d2 100644
--- a/fs/nfs/callback_xdr.c
+++ b/fs/nfs/callback_xdr.c
@@ -254,7 +254,7 @@ static __be32 encode_attr_change(struct xdr_stream *xdr,
const uint32_t *bitmap,
if (!(bitmap[0] & FATTR4_WORD0_CHANGE))
return 0;
p = xdr_reserve_space(xdr, 8);
- if (unlikely(p == 0))
+ if (unlikely(!p))
return htonl(NFS4ERR_RESOURCE);
p = xdr_encode_hyper(p, change);
return 0;
@@ -267,7 +267,7 @@ static __be32 encode_attr_size(struct xdr_stream *xdr,
const uint32_t *bitmap, u
if (!(bitmap[0] & FATTR4_WORD0_SIZE))
return 0;
p = xdr_reserve_space(xdr, 8);
- if (unlikely(p == 0))
+ if (unlikely(!p))
return htonl(NFS4ERR_RESOURCE);
p = xdr_encode_hyper(p, size);
return 0;
@@ -278,7 +278,7 @@ static __be32 encode_attr_time(struct xdr_stream *xdr,
const struct timespec *ti
__be32 *p;
p = xdr_reserve_space(xdr, 12);
- if (unlikely(p == 0))
+ if (unlikely(!p))
return htonl(NFS4ERR_RESOURCE);
p = xdr_encode_hyper(p, time->tv_sec);
*p = htonl(time->tv_nsec);
diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index b9eadd1..00a5e44 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -49,7 +49,7 @@ static int nfs_delegation_claim_locks(struct nfs_open_context
*ctx, struct nfs4_
struct file_lock *fl;
int status;
- for (fl = inode->i_flock; fl != 0; fl = fl->fl_next) {
+ for (fl = inode->i_flock; fl != NULL; fl = fl->fl_next) {
if (!(fl->fl_flags & (FL_POSIX|FL_FLOCK)))
continue;
if (nfs_file_open_context(fl->fl_file) != ctx)
diff --git a/fs/nfs/idmap.c b/fs/nfs/idmap.c
index 8ae5dba..86147b0 100644
--- a/fs/nfs/idmap.c
+++ b/fs/nfs/idmap.c
@@ -309,7 +309,7 @@ nfs_idmap_name(struct idmap *idmap, struct idmap_hashtable
*h,
mutex_lock(>idmap_im_lock);
he = idmap_lookup_id(h, id);
- if (he != 0) {
+ if (he) {
memcpy(name, he->ih_name, he->ih_namelen);
ret = he->ih_namelen;
goto out;
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 6233eb5..b962397 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -785,7 +785,7 @@ static int nfs4_reclaim_locks(struct
nfs4_state_recovery_ops *ops, struct nfs4_s
struct file_lock *fl;
int status = 0;
- for (fl = inode->i_flock; fl != 0; fl = fl->fl_next) {
+ for (fl = inode->i_flock; fl != NULL; fl = fl->fl_next) {
if (!(fl->fl_flags & (FL_POSIX|FL_FLOCK)))
continue;
if (nfs_file_open_context(fl->fl_file)->state != state)
--
1.5.4.2.200.g99e75
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wednesday, 20 of February 2008, Pierre Ossman wrote: > On Wed, 20 Feb 2008 14:26:16 -0500 (EST) > Alan Stern <[EMAIL PROTECTED]> wrote: > > > > > Do I understand this correctly? You've got special handling for the > > case where a bus handler doesn't have a resume routine, but no special > > handling for the case where it doesn't have a suspend routine? > > Hmm... There should be checks for both, but the code seems to suggest > otherwise. > > > Why bother to remove the device if neither routine exists (there won't be > > any need to revive it since the bus never got suspended)? > > The bus always gets suspended. The checks are to determine if state is saved > or not. If it isn't, then a suspend/resume is treated as a removal/insertion. > > > And why not simply fail the suspend if the resume routine doesn't exist > > and the suspend routine does? Maybe with an error message in the > > system log. > > For the asymmetric case, I guess that would do. But I still want to remove > devices when the bus handler has no suspend handling. I think I know how to handle that, but there's a more urgent issue I need to fix first. Stay tuned. :-) Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add the debugfs interface for the sysprof tool
On Wed, 2008-02-20 at 11:26 -0800, Arjan van de Ven wrote:
> feel free to reinvent a whole GUI just to avoid a 200 line kernel module.
> sysprof is here. it works.
> the gui is REALLY nice.
I guess we have to agree to disagree here. Its plain useless from my
POV.
> I think it's the wrong tradeoff though... oprofile exists for how long?
Dunno, years, and has served me well.
The thing I worry about is the wild-growth of duplicate functionality
and interfaces. You might say, 'its in /debug' so no API crap, but if
enough user-space depends on it people _will_ complain if it breaks.
Hopefully someone will consolidate stuff - soon. I can agree with the
fact that the oprofile user-interface is quite horrible, and perhaps the
kernel code isn't pretty (never looked at it), so if people want to
replace it, feel free, but offer a full replacement so we can deprecate
and remove the old stuff, and not carry everything around.
Currently we have: readprofile, oprofile, perfmon and now sysprof.
Also, sysprof is a misnomer, you cannot be a system wide profiler and
have code like:
+ if (!is_user) {
+ /* kernel */
+ trace->pid = current->pid;
+ trace->truncated = 0;
+ trace->n_addresses = 1;
+
+ /* 0x1 is taken by sysprof to mean "in kernel" */
+ trace->addresses[0] = 0x1;
+ }
The kernel is an integral part of the system, it can often help to know
where in the kernel time is spent - even if you're not directly
interested in 'fixing' the kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs: removing unused fops from struct char_device_struct
Hi,
seems struct char_device_struct::fops is no longer used, removing it.
I checked with "make allyesconfig" and got proper compile.
Signed-off-by: Jiri Olsa <[EMAIL PROTECTED]>
---
fs/char_dev.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/char_dev.c b/fs/char_dev.c
index c3bfa76..e4527fb 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -55,7 +55,6 @@ static struct char_device_struct {
unsigned int baseminor;
int minorct;
char name[64];
- struct file_operations *fops;
struct cdev *cdev; /* will die */
} *chrdevs[CHRDEV_MAJOR_HASH_SIZE];
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] state of GEN_RTC vs rtc subsystem
Alessandro Zummo wrote: On Wed, 20 Feb 2008 10:11:23 -0600 Kumar Gala <[EMAIL PROTECTED]> wrote: Is the functionality provided by drivers/char/gen_rtc.c completely handled by the rtc subsystem in drivers/rtc? I ask for two reasons: 1. should we make it mutually exclusive in Kconfig 2. I've enabled both and get (we'll my defconfig did): They shouldn't be enabled at once. I think a patch for Kconfig has been recently submitted to give a warning in such a case. rtc-cmos should be able to handle the vast majority of x86 rtcs out there. The only real open issue is related to the ntp synchronization mode and will be solved only when we can get rid of it :) On ARM genrtc has been arbitrary disabled in Kconfig circa 2.6.19 and the change to rtc_cmos it is not 100% transparent (ARM Netwinder, Debian). If I want to use a current (Etch) hwclock binary - I need genrtc with /dev/rtc at 10,135, however new rtc_cmos creates /dev/rtc0 at 254,0. As a result on new kernels hwclock claims that it is not able to access hardware. However upgrading the util-linux package will (sometime in the "unstable" future) solve it, so it is not completely broken... Still, at the moment - genrtc seems to be a better solution... Just my $.02... Woody Suwalski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Wednesday 20 February 2008 at 3:29 pm, Linus Torvalds penned about "Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green." > Can we please get this fixed some day? I can't say I even come close to understand what's going on but getting s2ram to work on my Dell M4300 has been a nightmare. Even after writing up how to get it to work (posted on the suspend-devel list - but no one answered .. yet again), I'm having some quirks. If I had a bizillion $'s, I'd buy an M4300 for Linus and give him a million to get it to s2ram! :p Cheers, -- Pablo Sanchez - Blueoak Database Engineering, Inc Ph:819.459.1926 Toll free: 888.459.1926 Fax: 603.720.7723 (US) Text Page: [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb-serial: Prepare for BKL push down
Take the lock in usb-serial instead. As it relies on the BKL internally
we can't push it any deeper yet.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/usb-serial.c
linux-2.6.25-rc2-mm1/drivers/usb/serial/usb-serial.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/usb-serial.c
2008-02-19 11:03:01.0 +
+++ linux-2.6.25-rc2-mm1/drivers/usb/serial/usb-serial.c2008-02-20
11:53:06.0 +
@@ -401,11 +401,13 @@
struct usb_serial_port *port = tty->driver_data;
int retval = -ENODEV;
+ lock_kernel();
if (!port)
goto exit;
dbg("%s - port %d, cmd 0x%.4x", __FUNCTION__, port->number, cmd);
+ /* Caution - port->open_count is BKL protected */
if (!port->open_count) {
dbg ("%s - port not open", __FUNCTION__);
goto exit;
@@ -416,8 +418,8 @@
retval = port->serial->type->ioctl(port, file, cmd, arg);
else
retval = -ENOIOCTLCMD;
-
exit:
+ unlock_kernel();
return retval;
}
@@ -446,19 +448,24 @@
{
struct usb_serial_port *port = tty->driver_data;
- if (!port)
+ lock_kernel();
+ if (!port) {
+ unlock_kernel();
return;
+ }
dbg("%s - port %d", __FUNCTION__, port->number);
if (!port->open_count) {
dbg("%s - port not open", __FUNCTION__);
+ unlock_kernel();
return;
}
/* pass on to the driver specific version of this function if it is
available */
if (port->serial->type->break_ctl)
port->serial->type->break_ctl(port, break_state);
+ unlock_kernel();
}
static int serial_read_proc (char *page, char **start, off_t off, int count,
int *eof, void *data)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] serial_core: Prepare for BKL push down
Instead of checking for the BKL in these methods, take it ourselves. That
avoids propogating it into the serial drivers and we can then fix them
later on.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/serial/serial_core.c
linux-2.6.25-rc2-mm1/drivers/serial/serial_core.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/serial/serial_core.c 2008-02-19
11:03:01.0 +
+++ linux-2.6.25-rc2-mm1/drivers/serial/serial_core.c 2008-02-20
16:22:49.0 +
@@ -907,14 +914,14 @@
struct uart_state *state = tty->driver_data;
struct uart_port *port = state->port;
- BUG_ON(!kernel_locked());
-
+ lock_kernel();
mutex_lock(>mutex);
if (port->type != PORT_UNKNOWN)
port->ops->break_ctl(port, break_state);
mutex_unlock(>mutex);
+ unlock_kernel();
}
static int uart_do_autoconfig(struct uart_state *state)
@@ -1052,7 +1059,7 @@
}
/*
- * Called via sys_ioctl under the BKL. We can use spin_lock_irq() here.
+ * Called via sys_ioctl. We can use spin_lock_irq() here.
*/
static int
uart_ioctl(struct tty_struct *tty, struct file *filp, unsigned int cmd,
@@ -1062,8 +1069,8 @@
void __user *uarg = (void __user *)arg;
int ret = -ENOIOCTLCMD;
- BUG_ON(!kernel_locked());
+ lock_kernel();
/*
* These ioctls don't rely on the hardware to be present.
*/
@@ -1136,6 +1143,7 @@
out_up:
mutex_unlock(>mutex);
out:
+ unlock_kernel();
return ret;
}
@@ -1146,7 +1154,6 @@
unsigned long flags;
unsigned int cflag = tty->termios->c_cflag;
- BUG_ON(!kernel_locked());
/*
* These are the bits that are used to setup various
@@ -1158,9 +1165,11 @@
if ((cflag ^ old_termios->c_cflag) == 0 &&
tty->termios->c_ospeed == old_termios->c_ospeed &&
tty->termios->c_ispeed == old_termios->c_ispeed &&
- RELEVANT_IFLAG(tty->termios->c_iflag ^ old_termios->c_iflag) == 0)
+ RELEVANT_IFLAG(tty->termios->c_iflag ^ old_termios->c_iflag) == 0) {
return;
+ }
+ lock_kernel();
uart_change_speed(state, old_termios);
/* Handle transition to B0 status */
@@ -1193,7 +1202,7 @@
}
spin_unlock_irqrestore(>port->lock, flags);
}
-
+ unlock_kernel();
#if 0
/*
* No need to wake up processes in open wait, since they
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] uart_get_baud_rate: stop mangling termios
Russell King noticed this one: We have to avoid replacing B0 when we pick
a baud rate for a "hung up" port. Ugly but the proper fix is in the tty
layer and means changing the tty<->serial interfaces so we will defer
that for now.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/serial/serial_core.c
linux-2.6.25-rc2-mm1/drivers/serial/serial_core.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/serial/serial_core.c 2008-02-19
11:03:01.0 +
+++ linux-2.6.25-rc2-mm1/drivers/serial/serial_core.c 2008-02-20
16:22:49.0 +
@@ -329,13 +329,15 @@
* If it's still invalid, we try 9600 baud.
*
* Update the @termios structure to reflect the baud rate
- * we're actually going to be using.
+ * we're actually going to be using. Don't do this for the case
+ * where B0 is requested ("hang up").
*/
unsigned int
uart_get_baud_rate(struct uart_port *port, struct ktermios *termios,
struct ktermios *old, unsigned int min, unsigned int max)
{
unsigned int try, baud, altbaud = 38400;
+ int hung_up;
upf_t flags = port->flags & UPF_SPD_MASK;
if (flags == UPF_SPD_HI)
@@ -360,8 +362,10 @@
/*
* Special case: B0 rate.
*/
- if (baud == 0)
+ if (baud == 0) {
+ hung_up = 1;
baud = 9600;
+ }
if (baud >= min && baud <= max)
return baud;
@@ -373,7 +377,9 @@
termios->c_cflag &= ~CBAUD;
if (old) {
baud = tty_termios_baud_rate(old);
- tty_termios_encode_baud_rate(termios, baud, baud);
+ if (!hung_up)
+ tty_termios_encode_baud_rate(termios,
+ baud, baud);
old = NULL;
continue;
}
@@ -382,7 +388,8 @@
* As a last resort, if the quotient is zero,
* default to 9600 bps
*/
- tty_termios_encode_baud_rate(termios, 9600, 9600);
+ if (!hung_up)
+ tty_termios_encode_baud_rate(termios, 9600, 9600);
}
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008 14:26:16 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > > Do I understand this correctly? You've got special handling for the > case where a bus handler doesn't have a resume routine, but no special > handling for the case where it doesn't have a suspend routine? Hmm... There should be checks for both, but the code seems to suggest otherwise. > Why bother to remove the device if neither routine exists (there won't be > any need to revive it since the bus never got suspended)? The bus always gets suspended. The checks are to determine if state is saved or not. If it isn't, then a suspend/resume is treated as a removal/insertion. > And why not simply fail the suspend if the resume routine doesn't exist > and the suspend routine does? Maybe with an error message in the > system log. For the asymmetric case, I guess that would do. But I still want to remove devices when the bus handler has no suspend handling. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] crisv10: prepare for BKL push down
Just the modem bits this time
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/serial/crisv10.c
linux-2.6.25-rc2-mm1/drivers/serial/crisv10.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/serial/crisv10.c 2008-02-19
11:03:01.0 +
+++ linux-2.6.25-rc2-mm1/drivers/serial/crisv10.c 2008-02-20
11:52:24.0 +
@@ -3581,6 +3581,8 @@
unsigned int set, unsigned int clear)
{
struct e100_serial *info = (struct e100_serial *)tty->driver_data;
+
+ lock_kernel();
if (clear & TIOCM_RTS)
e100_rts(info, 0);
@@ -3601,6 +3603,8 @@
e100_ri_out(info, 1);
if (set & TIOCM_CD)
e100_cd_out(info, 1);
+
+ unlock_kernel();
return 0;
}
@@ -3610,6 +3614,7 @@
struct e100_serial *info = (struct e100_serial *)tty->driver_data;
unsigned int result;
+ lock_kernel();
result =
(!E100_RTS_GET(info) ? TIOCM_RTS : 0)
| (!E100_DTR_GET(info) ? TIOCM_DTR : 0)
@@ -3617,6 +3622,8 @@
| (!E100_DSR_GET(info) ? TIOCM_DSR : 0)
| (!E100_CD_GET(info) ? TIOCM_CAR : 0)
| (!E100_CTS_GET(info) ? TIOCM_CTS : 0);
+
+ unlock_kernel();
#ifdef SERIAL_DEBUG_IO
printk(KERN_DEBUG "ser%i: modem state: %i 0x%08X\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix tty speed handling on 8250
We try and write the correct speed back but the serial midlayer already mangles the speed on us and that means if we request B0 we report back B9600 when we should not. For now we'll hack around this in the drivers and serial code, pending a better long term solution. Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.25-rc2-mm1/drivers/serial/8250.c linux-2.6.25-rc2-mm1/drivers/serial/8250.c --- linux.vanilla-2.6.25-rc2-mm1/drivers/serial/8250.c 2008-02-19 11:03:01.0 + +++ linux-2.6.25-rc2-mm1/drivers/serial/8250.c 2008-02-20 16:31:16.0 + @@ -2174,7 +2174,9 @@ } serial8250_set_mctrl(>port, up->port.mctrl); spin_unlock_irqrestore(>port.lock, flags); - tty_termios_encode_baud_rate(termios, baud, baud); + /* Don't rewrite B0 */ + if (tty_termios_baud_rate(termios)) + tty_termios_encode_baud_rate(termios, baud, baud); } static void -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Wednesday 20 February 2008, Chris Vine wrote: > > On Wed, 2008-02-20 at 11:05 -0500, Dan Williams wrote: > > On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote: > > > On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote: > > > > Hi, > > > > > > > > [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] > > > > > > > > > > > > I have a series of tests I would like to request from you, > > > > > > > > you mentioned you already enabled debugfs, and that is just > > > > > > > > what we need. ;) > > > > > > > > Please use attached script to create dumps of the hardware > > > > > > > > register contents. > > > > > > > > > > > > > > > > There are specific moments that should be dumped: > > > > > > > > - kernel 2.6.24 (last known working version for you). > > > > > > > > - kernel 2.6.25-rc2 (after ifup, before TX dies) > > > > > > > > - kernel 2.6.25-rc2 (after ifup, after TX dies) > > > > > > > > > > > > > > > > > > > > > > These diagnostics are attached, with obvious filenames. > > > > > > > > > > > > Thanks. I think I found something, please test below patch: > > > > > > > > > > > > > > > > I've tried the patch but, unfortunately, my wireless LAN still dies > > > > > after a few pings. > > > > > > rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2 > > > kernel (not wireless-2.6/rt2x00 git). The modules load when I plug the > > > stick in but I then get a complete kernel lock up with two flashing > > > leds. Nothing is recorded to system logs. The last logged messages are > > > that usbcore has registered new interface driver rt73usb, and that the > > > rate control algorithm has been selected on phy0. This happens whether > > > the simple or pid mac80211 rate control algorithms have been chosen. > > > > > > This is a shame because 2.0.14 was working really well for me until the > > > mac80211 changes 2 or 3 weeks ago broke it. (Shortly followed by the > > > release of 2.1.*). > > > > Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a > > picture of the panic if one shows up. _Something_ should show up on the > > VT. > > I did that yesterday and it just reported a kernel panic on the terminal > with the message: > > Kernel panic - not syncing: Aiee, killing interrupt handler! I have an idea, could you try below patch? Note that while applying it will mention something about a line offset, but that can be ignored. This could perhaps also fix the TX/RX issue mentioned earlier in the thread, but I am not quite sure about that. --- diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c index b63bc66..460ef2f 100644 --- a/drivers/net/wireless/rt2x00/rt2400pci.c +++ b/drivers/net/wireless/rt2x00/rt2400pci.c @@ -953,8 +953,12 @@ static int rt2400pci_set_device_state(struct rt2x00_dev *rt2x00dev, rt2400pci_disable_radio(rt2x00dev); break; case STATE_RADIO_RX_ON: + case STATE_RADIO_RX_ON_LINK: + rt2400pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON); + break; case STATE_RADIO_RX_OFF: - rt2400pci_toggle_rx(rt2x00dev, state); + case STATE_RADIO_RX_OFF_LINK: + rt2400pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF); break; case STATE_DEEP_SLEEP: case STATE_SLEEP: diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c index add8aff..ffcd996 100644 --- a/drivers/net/wireless/rt2x00/rt2500pci.c +++ b/drivers/net/wireless/rt2x00/rt2500pci.c @@ -1106,8 +1106,12 @@ static int rt2500pci_set_device_state(struct rt2x00_dev *rt2x00dev, rt2500pci_disable_radio(rt2x00dev); break; case STATE_RADIO_RX_ON: + case STATE_RADIO_RX_ON_LINK: + rt2500pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON); + break; case STATE_RADIO_RX_OFF: - rt2500pci_toggle_rx(rt2x00dev, state); + case STATE_RADIO_RX_OFF_LINK: + rt2500pci_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF); break; case STATE_DEEP_SLEEP: case STATE_SLEEP: diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c index d9643c5..9f59db9 100644 --- a/drivers/net/wireless/rt2x00/rt2500usb.c +++ b/drivers/net/wireless/rt2x00/rt2500usb.c @@ -996,8 +996,12 @@ static int rt2500usb_set_device_state(struct rt2x00_dev *rt2x00dev, rt2500usb_disable_radio(rt2x00dev); break; case STATE_RADIO_RX_ON: + case STATE_RADIO_RX_ON_LINK: + rt2500usb_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON); + break; case STATE_RADIO_RX_OFF: - rt2500usb_toggle_rx(rt2x00dev, state); + case STATE_RADIO_RX_OFF_LINK: + rt2500usb_toggle_rx(rt2x00dev, STATE_RADIO_RX_OFF); break; case STATE_DEEP_SLEEP: case
[PATCH 1/2] nfsd: fix sparse warnings
Add extern to nfsd/nfsd.h
fs/nfsd/nfssvc.c:146:5: warning: symbol 'nfsd_nrthreads' was not declared.
Should it be static?
fs/nfsd/nfssvc.c:261:5: warning: symbol 'nfsd_nrpools' was not declared. Should
it be static?
fs/nfsd/nfssvc.c:269:5: warning: symbol 'nfsd_get_nrthreads' was not declared.
Should it be static?
fs/nfsd/nfssvc.c:281:5: warning: symbol 'nfsd_set_nrthreads' was not declared.
Should it be static?
fs/nfsd/export.c:1534:23: warning: symbol 'nfs_exports_op' was not declared.
Should it be static?
Add include of auth.h
fs/nfsd/auth.c:27:5: warning: symbol 'nfsd_setuser' was not declared. Should it
be static?
Make static, move forward declaration closer to where it's needed.
fs/nfsd/nfs4state.c:1877:1: warning: symbol 'laundromat_main' was not declared.
Should it be static?
Make static, forward declaration was already marked static.
fs/nfsd/nfs4idmap.c:206:1: warning: symbol 'idtoname_parse' was not declared.
Should it be static?
fs/nfsd/vfs.c:1156:1: warning: symbol 'nfsd_create_setattr' was not declared.
Should it be static?
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/nfsd/auth.c|1 +
fs/nfsd/nfs4idmap.c |2 +-
fs/nfsd/nfs4state.c | 10 +-
fs/nfsd/nfsctl.c |7 ---
fs/nfsd/vfs.c |2 +-
include/linux/nfsd/nfsd.h |8
6 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/fs/nfsd/auth.c b/fs/nfsd/auth.c
index d13403e..294992e 100644
--- a/fs/nfsd/auth.c
+++ b/fs/nfsd/auth.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include "auth.h"
int nfsexp_flags(struct svc_rqst *rqstp, struct svc_export *exp)
{
diff --git a/fs/nfsd/nfs4idmap.c b/fs/nfsd/nfs4idmap.c
index 996bd88..5b39842 100644
--- a/fs/nfsd/nfs4idmap.c
+++ b/fs/nfsd/nfs4idmap.c
@@ -202,7 +202,7 @@ static struct cache_detail idtoname_cache = {
.alloc = ent_alloc,
};
-int
+static int
idtoname_parse(struct cache_detail *cd, char *buf, int buflen)
{
struct ent ent, *res;
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index bcb97d8..c7c92ae 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1762,10 +1762,6 @@ out:
return status;
}
-static struct workqueue_struct *laundry_wq;
-static void laundromat_main(struct work_struct *);
-static DECLARE_DELAYED_WORK(laundromat_work, laundromat_main);
-
__be32
nfsd4_renew(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
clientid_t *clid)
@@ -1873,7 +1869,11 @@ nfs4_laundromat(void)
return clientid_val;
}
-void
+static struct workqueue_struct *laundry_wq;
+static void laundromat_main(struct work_struct *);
+static DECLARE_DELAYED_WORK(laundromat_work, laundromat_main);
+
+static void
laundromat_main(struct work_struct *not_used)
{
time_t t;
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index 8516137..73d3f28 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -149,7 +149,6 @@ static const struct file_operations transaction_ops = {
.release= simple_transaction_release,
};
-extern struct seq_operations nfs_exports_op;
static int exports_open(struct inode *inode, struct file *file)
{
return seq_open(file, _exports_op);
@@ -347,8 +346,6 @@ static ssize_t write_filehandle(struct file *file, char
*buf, size_t size)
return mesg - buf;
}
-extern int nfsd_nrthreads(void);
-
static ssize_t write_threads(struct file *file, char *buf, size_t size)
{
/* if size > 0, look for a number of threads and call nfsd_svc
@@ -371,10 +368,6 @@ static ssize_t write_threads(struct file *file, char *buf,
size_t size)
return strlen(buf);
}
-extern int nfsd_nrpools(void);
-extern int nfsd_get_nrthreads(int n, int *);
-extern int nfsd_set_nrthreads(int n, int *);
-
static ssize_t write_pool_threads(struct file *file, char *buf, size_t size)
{
/* if size > 0, look for an array of number of threads per node
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 46f59d5..0265310 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1152,7 +1152,7 @@ nfsd_commit(struct svc_rqst *rqstp, struct svc_fh *fhp,
}
#endif /* CONFIG_NFSD_V3 */
-__be32
+static __be32
nfsd_create_setattr(struct svc_rqst *rqstp, struct svc_fh *resfhp,
struct iattr *iap)
{
diff --git a/include/linux/nfsd/nfsd.h b/include/linux/nfsd/nfsd.h
index 8caf4c4..f4de14d 100644
--- a/include/linux/nfsd/nfsd.h
+++ b/include/linux/nfsd/nfsd.h
@@ -56,12 +56,20 @@ extern struct svc_program nfsd_program;
extern struct svc_version nfsd_version2, nfsd_version3,
nfsd_version4;
extern struct svc_serv *nfsd_serv;
+
+extern struct seq_operations nfs_exports_op;
+
/*
* Function prototypes.
*/
intnfsd_svc(unsigned short port, int nrservs);
intnfsd_dispatch(struct svc_rqst *rqstp, __be32 *statp);
+intnfsd_nrthreads(void);
+intnfsd_nrpools(void);
[PATCH 2/2] nfsd: fix sparse warning in vfs.c
fs/nfsd/vfs.c:991:27: warning: Using plain integer as NULL pointer
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/nfsd/vfs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 0265310..17ac51b 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -988,7 +988,7 @@ nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh *fhp,
struct file *file,
* flushing the data to disk is handled separately below.
*/
- if (file->f_op->fsync == 0) {/* COMMIT3 cannot work */
+ if (!file->f_op->fsync) {/* COMMIT3 cannot work */
stable = 2;
*stablep = 2; /* FILE_SYNC */
}
--
1.5.4.2.200.g99e75
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Wednesday, 20 of February 2008, Linus Torvalds wrote: > > On Wed, 20 Feb 2008, Rafael J. Wysocki wrote: > > > > I think we should export the target sleep state somehow. > > Yeah. By *not* using "->suspend()" for freezing or hibernate. > > Please, Rafael - just make the f*cking suspend-to-disk use other routines > already. Okay, I think I'll just start sending patches for that, but rather not earlier than in the 2.6.27 time frame. No one else works on that and I've been busy with other things recently. Besides, I'm not even a full time kernel developer ... > 99% of all hardware needs to do exactly *nothing* on suspend-to-disk, and the > ones that really do need things tend to need to not do a whole lot. > > For example, the "freeze" action for USB (which is one of the hardest > things to suspend) should literally be something like just setting the > controller STOP bit, and waiting for it to have stopped. The "unfreeze" > should be to just clear the stop bit, while the "restart" should be just a > controller reset to use the current memory image. > > NONE OF THIS HAS ABSOLUTELY ANYTHING TO DO WITH SUSPEND. > > It never did. I've told people so for years. Maybe actually seeing the > problems will make people realize. I think so. > So please, we shouldn't call "->suspend[_late]" or "->resume[_early]" at > all. Not with PMSG_FREEZE, not with PMSG_*anything*. > > Can we please get this fixed some day? Yes, we can (hopefully). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 68360serial: Note that there isn't any info->mcr locking
Noticed while auditing the code for the BKL elimination project Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.25-rc2-mm1/drivers/serial/68360serial.c linux-2.6.25-rc2-mm1/drivers/serial/68360serial.c --- linux.vanilla-2.6.25-rc2-mm1/drivers/serial/68360serial.c 2008-02-19 11:01:44.0 + +++ linux-2.6.25-rc2-mm1/drivers/serial/68360serial.c 2008-02-20 11:52:17.0 + @@ -1281,7 +1281,7 @@ if (tty->flags & (1 << TTY_IO_ERROR)) return -EIO; - + /* FIXME: locking on info->mcr */ if (set & TIOCM_RTS) info->mcr |= UART_MCR_RTS; if (set & TIOCM_DTR) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] isdn_tty: Prepare for BKL push down
Three things here
- Remove softcar handler
- Correct termios change detection logic
- Wrap break/ioctl in lock_kernel ready to drop it in the caller
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/isdn/i4l/isdn_tty.c
linux-2.6.25-rc2-mm1/drivers/isdn/i4l/isdn_tty.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/isdn/i4l/isdn_tty.c2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/isdn/i4l/isdn_tty.c2008-02-20
11:50:10.0 +
@@ -1352,12 +1352,14 @@
if (tty->flags & (1 << TTY_IO_ERROR))
return -EIO;
+ lock_kernel();
#ifdef ISDN_DEBUG_MODEM_IOCTL
printk(KERN_DEBUG "ttyI%d ioctl TIOCMGET\n", info->line);
#endif
control = info->mcr;
status = info->msr;
+ unlock_kernel();
return ((control & UART_MCR_RTS) ? TIOCM_RTS : 0)
| ((control & UART_MCR_DTR) ? TIOCM_DTR : 0)
| ((status & UART_MSR_DCD) ? TIOCM_CAR : 0)
@@ -1381,6 +1383,7 @@
printk(KERN_DEBUG "ttyI%d ioctl TIOCMxxx: %x %x\n", info->line, set,
clear);
#endif
+ lock_kernel();
if (set & TIOCM_RTS)
info->mcr |= UART_MCR_RTS;
if (set & TIOCM_DTR) {
@@ -1402,6 +1405,7 @@
isdn_tty_modem_hup(info, 1);
}
}
+ unlock_kernel();
return 0;
}
@@ -1435,21 +1439,6 @@
return retval;
tty_wait_until_sent(tty, 0);
return 0;
- case TIOCGSOFTCAR:
-#ifdef ISDN_DEBUG_MODEM_IOCTL
- printk(KERN_DEBUG "ttyI%d ioctl TIOCGSOFTCAR\n",
info->line);
-#endif
- return put_user(C_CLOCAL(tty) ? 1 : 0, (ulong __user *)
arg);
- case TIOCSSOFTCAR:
-#ifdef ISDN_DEBUG_MODEM_IOCTL
- printk(KERN_DEBUG "ttyI%d ioctl TIOCSSOFTCAR\n",
info->line);
-#endif
- if (get_user(arg, (ulong __user *) arg))
- return -EFAULT;
- tty->termios->c_cflag =
- ((tty->termios->c_cflag & ~CLOCAL) |
-(arg ? CLOCAL : 0));
- return 0;
case TIOCSERGETLSR: /* Get line status register */
#ifdef ISDN_DEBUG_MODEM_IOCTL
printk(KERN_DEBUG "ttyI%d ioctl TIOCSERGETLSR\n",
info->line);
@@ -1472,13 +1461,14 @@
if (!old_termios)
isdn_tty_change_speed(info);
else {
- if (tty->termios->c_cflag == old_termios->c_cflag)
+ if (tty->termios->c_cflag == old_termios->c_cflag &&
+ tty->termios->c_ispeed == old_termios->c_ispeed &&
+ tty->termios->c_ospeed == old_termios->c_ospeed)
return;
isdn_tty_change_speed(info);
if ((old_termios->c_cflag & CRTSCTS) &&
- !(tty->termios->c_cflag & CRTSCTS)) {
+ !(tty->termios->c_cflag & CRTSCTS))
tty->hw_stopped = 0;
- }
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vt_ioctl: Prepare for BKL push down
This one could do with some eyeballs on it. In theory it simply wraps the
ioctl handler in lock/unlock_kernel ready for the lock/unlocks to be
pushed into specific switch values. To do that means changing the code to
return via a common exit path not all over the place as it does now,
hence the big diff
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c
linux-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c2008-02-19
11:01:43.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c2008-02-20
11:49:34.0 +
@@ -373,11 +373,17 @@
unsigned char ucval;
void __user *up = (void __user *)arg;
int i, perm;
-
+ int ret = 0;
+
console = vc->vc_num;
+
+ lock_kernel();
- if (!vc_cons_allocated(console))/* impossible? */
- return -ENOIOCTLCMD;
+ if (!vc_cons_allocated(console)) { /* impossible? */
+ ret = -ENOIOCTLCMD;
+ goto out;
+ }
+
/*
* To have permissions to do most of the vt ioctls, we either have
@@ -391,15 +397,15 @@
switch (cmd) {
case KIOCSOUND:
if (!perm)
- return -EPERM;
+ goto eperm;
if (arg)
arg = CLOCK_TICK_RATE / arg;
kd_mksound(arg, 0);
- return 0;
+ break;
case KDMKTONE:
if (!perm)
- return -EPERM;
+ goto eperm;
{
unsigned int ticks, count;
@@ -412,7 +418,7 @@
if (count)
count = CLOCK_TICK_RATE / count;
kd_mksound(count, ticks);
- return 0;
+ break;
}
case KDGKBTYPE:
@@ -435,14 +441,18 @@
* KDADDIO and KDDELIO may be able to add ports beyond what
* we reject here, but to be safe...
*/
- if (arg < GPFIRST || arg > GPLAST)
- return -EINVAL;
- return sys_ioperm(arg, 1, (cmd == KDADDIO)) ? -ENXIO : 0;
+ if (arg < GPFIRST || arg > GPLAST) {
+ ret = -EINVAL;
+ break;
+ }
+ ret = sys_ioperm(arg, 1, (cmd == KDADDIO)) ? -ENXIO : 0;
+ break;
case KDENABIO:
case KDDISABIO:
- return sys_ioperm(GPFIRST, GPNUM,
+ ret = sys_ioperm(GPFIRST, GPNUM,
(cmd == KDENABIO)) ? -ENXIO : 0;
+ break;
#endif
/* Linux m68k/i386 interface for setting the keyboard delay/repeat rate
*/
@@ -450,19 +460,20 @@
case KDKBDREP:
{
struct kbd_repeat kbrep;
- int err;
if (!capable(CAP_SYS_TTY_CONFIG))
- return -EPERM;
+ goto eperm;
- if (copy_from_user(, up, sizeof(struct kbd_repeat)))
- return -EFAULT;
- err = kbd_rate();
- if (err)
- return err;
+ if (copy_from_user(, up, sizeof(struct kbd_repeat))) {
+ ret = -EFAULT;
+ break;
+ }
+ ret = kbd_rate();
+ if (ret)
+ break;
if (copy_to_user(up, , sizeof(struct kbd_repeat)))
- return -EFAULT;
- return 0;
+ ret = -EFAULT;
+ break;
}
case KDSETMODE:
@@ -475,7 +486,7 @@
* need to restore their engine state. --BenH
*/
if (!perm)
- return -EPERM;
+ goto eperm;
switch (arg) {
case KD_GRAPHICS:
break;
@@ -485,13 +496,14 @@
case KD_TEXT:
break;
default:
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
if (vc->vc_mode == (unsigned char) arg)
- return 0;
+ break;
vc->vc_mode = (unsigned char) arg;
if (console != fg_console)
- return 0;
+ break;
/*
* explicitly blank/unblank the screen if switching modes
*/
@@ -501,7 +513,7 @@
else
do_blank_screen(1);
release_console_sem();
- return 0;
+ break;
Re: [patch 1/3] x86_64: CPA, fix cache attribute inconsistency bug, v2.6.22 backport
On Wed, Feb 20, 2008 at 03:30:18PM -0500, Vivek Goyal wrote:
> On Fri, Feb 15, 2008 at 08:58:22PM +0100, Ingo Molnar wrote:
> >
> > fix CPA cache attribute bug in v2.6.23. When phys_base is nonzero
> > (when CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates
> > the secondary alias address by -14 MB (depending on the configured
> > offset).
> >
> > The default 64-bit kernels of Fedora and Ubuntu are affected:
> >
> >$ grep RELOCA /boot/config-2.6.23.9-85.fc8
> > CONFIG_RELOCATABLE=y
> >
> >$ grep RELOC /boot/config-2.6.22-14-generic
> > CONFIG_RELOCATABLE=y
> >
> > and probably on many other distros as well.
> >
> > the bug affects all pages in the first 40 MB of physical RAM that
> > are allocated by some subsystem that does ioremap_nocache() on them:
> >
> >if (__pa(address) < KERNEL_TEXT_SIZE) {
> >
> > Hence we might leave page table entries with inconsistent cache
> > attributes around (pages mapped at both UnCacheable and Write-Back),
> > and we can also set the wrong kernel text pages to UnCacheable.
> >
> > the effects of this bug can be random slowdowns and other misbehavior.
> > If for example AGP allocates its aperture pages into the first 40 MB
> > of physical RAM, then the -14 MB bug might mark random kernel texto
> > pages as uncacheable, slowing down a random portion of the 64-bit
> > kernel until the AGP driver is unloaded.
> >
> > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> > Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
> > ---
> > arch/x86_64/mm/pageattr.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Index: linux-tmp/arch/x86_64/mm/pageattr.c
> > ===
> > --- linux-tmp.orig/arch/x86_64/mm/pageattr.c
> > +++ linux-tmp/arch/x86_64/mm/pageattr.c
> > @@ -204,7 +204,7 @@ int change_page_attr_addr(unsigned long
> > if (__pa(address) < KERNEL_TEXT_SIZE) {
>
> Hi Ingo,
>
> Should we change above condition also to something like following.
>
> kernel_phys_start = __pa(__START_KERNEL_map) + phys_base
Oops. Just noticed that __pa() is already taking care of adding phys_base.
So it should probably be.
kernel_phys_start = __pa(__START_KERNEL_map);
kernel_phys_end = kernel_phys_start + KERNEL_TEXT_SIZE;
if (__pa(address) >= kernel_phys_start
&& __pa(address) <= kernel_phys_end)
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] nfs: fix sparse warning in nfs4state.c
On Wed, 2008-02-20 at 12:10 -0800, Harvey Harrison wrote:
> fs/nfs/nfs4state.c:788:34: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
> ---
> fs/nfs/nfs4state.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
> index 6233eb5..b962397 100644
> --- a/fs/nfs/nfs4state.c
> +++ b/fs/nfs/nfs4state.c
> @@ -785,7 +785,7 @@ static int nfs4_reclaim_locks(struct
> nfs4_state_recovery_ops *ops, struct nfs4_s
> struct file_lock *fl;
> int status = 0;
>
> - for (fl = inode->i_flock; fl != 0; fl = fl->fl_next) {
> + for (fl = inode->i_flock; fl != NULL; fl = fl->fl_next) {
> if (!(fl->fl_flags & (FL_POSIX|FL_FLOCK)))
> continue;
> if (nfs_file_open_context(fl->fl_file)->state != state)
Could you please just wrap these 4 up into a single patch? They are all
fixing up the same issue, and they are trivial to review, so there is
very little benefit in separating them.
Thanks
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] documentation: fix firmware_sample_firmware_class to build
On Wed, Feb 20, 2008 at 12:10:36PM -0800, Randy Dunlap wrote: > Greg KH wrote: >> On Mon, Feb 18, 2008 at 04:22:16PM -0800, Randy Dunlap wrote: >>> From: Randy Dunlap <[EMAIL PROTECTED]> >>> >>> Fix firmware_sample_firmware_class module to build without error. >>> sysfs.h already has the function prototypes and has them correctly. >>> >>> Documentation/firmware_class/firmware_sample_firmware_class.c:37: error: >>> conflicting types for 'sysfs_remove_bin_file' >>> include/linux/sysfs.h:100: error: previous declaration of >>> 'sysfs_remove_bin_file' was here >>> >>> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> >>> --- >>> Documentation/firmware_class/firmware_sample_firmware_class.c |3 --- >>> 1 file changed, 3 deletions(-) >> Can we move this file to the samples/ directory, so the build will catch >> stuff like this? >> What's the final version of this patch? > > I've moved it to samples/, but it (still) has a build problem: > > ERROR: "firmware_class" > [samples/firmware_class/firmware_sample_firmware_class.ko] undefined! > > Can you give me hint(s) about how to fix that? Ah, yeah, that class went away a while ago. Care to send me the patch you have, and I'll be glad to fix it up and get it in? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Wednesday, February 20, 2008 12:29 pm Linus Torvalds wrote: > On Wed, 20 Feb 2008, Rafael J. Wysocki wrote: > > I think we should export the target sleep state somehow. > > Yeah. By *not* using "->suspend()" for freezing or hibernate. > > Please, Rafael - just make the f*cking suspend-to-disk use other routines > already. 99% of all hardware needs to do exactly *nothing* on > suspend-to-disk, and the ones that really do need things tend to need to > not do a whole lot. In talking with Rafael on IRC about this, I think we're agreed that we need separate entry points. Even with a kexec based hibernate, we'll probably want ->hibernate callbacks so we don't end up shutting down the device. The current callback system looks like this (according to Rafael and the last time I looked): ->suspend(PMSG_FREEZE) ->resume() ->suspend(PMSG_SUSPEND) *enter S3 or power off* ->resume() The fact that we get suspend/resume called once before suspend again in the hibernate case is somewhat obnoxious, but it's even worse that we don't know what we're about to enter after ->suspend(PMSG_SUSPEND). So in the short term it would be nice to at least get the target state exported. And in the long term we could have: ->suspend() *enter S3* ->resume() or: ->hibernate() *kexec to another kernel to save image* *power off* ->return_from_hibernate() (or somesuch) Jesse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] synclink series: Prepare for BKL pushdown
As these are quite complex I've simply pushed the BKL down into the ioctl
handler not tried to do anything neater.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclink.c
linux-2.6.25-rc2-mm1/drivers/char/synclink.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclink.c2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/synclink.c2008-02-20
11:49:03.0 +
@@ -2945,6 +2945,7 @@
unsigned int cmd, unsigned long arg)
{
struct mgsl_struct * info = (struct mgsl_struct *)tty->driver_data;
+ int ret;
if (debug_level >= DEBUG_LEVEL_INFO)
printk("%s(%d):mgsl_ioctl %s cmd=%08X\n", __FILE__,__LINE__,
@@ -2959,7 +2960,10 @@
return -EIO;
}
- return mgsl_ioctl_common(info, cmd, arg);
+ lock_kernel();
+ ret = mgsl_ioctl_common(info, cmd, arg);
+ unlock_kernel();
+ return ret;
}
static int mgsl_ioctl_common(struct mgsl_struct *info, unsigned int cmd,
unsigned long arg)
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclink_gt.c
linux-2.6.25-rc2-mm1/drivers/char/synclink_gt.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclink_gt.c 2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/synclink_gt.c 2008-02-20
11:49:09.0 +
@@ -1098,6 +1098,7 @@
struct serial_icounter_struct __user *p_cuser; /* user space */
unsigned long flags;
void __user *argp = (void __user *)arg;
+ int ret;
if (sanity_check(info, tty->name, "ioctl"))
return -ENODEV;
@@ -1108,38 +1109,55 @@
if (tty->flags & (1 << TTY_IO_ERROR))
return -EIO;
}
+
+ lock_kernel();
switch (cmd) {
case MGSL_IOCGPARAMS:
- return get_params(info, argp);
+ ret = get_params(info, argp);
+ break;
case MGSL_IOCSPARAMS:
- return set_params(info, argp);
+ ret = set_params(info, argp);
+ break;
case MGSL_IOCGTXIDLE:
- return get_txidle(info, argp);
+ ret = get_txidle(info, argp);
+ break;
case MGSL_IOCSTXIDLE:
- return set_txidle(info, (int)arg);
+ ret = set_txidle(info, (int)arg);
+ break;
case MGSL_IOCTXENABLE:
- return tx_enable(info, (int)arg);
+ ret = tx_enable(info, (int)arg);
+ break;
case MGSL_IOCRXENABLE:
- return rx_enable(info, (int)arg);
+ ret = rx_enable(info, (int)arg);
+ break;
case MGSL_IOCTXABORT:
- return tx_abort(info);
+ ret = tx_abort(info);
+ break;
case MGSL_IOCGSTATS:
- return get_stats(info, argp);
+ ret = get_stats(info, argp);
+ break;
case MGSL_IOCWAITEVENT:
- return wait_mgsl_event(info, argp);
+ ret = wait_mgsl_event(info, argp);
+ break;
case TIOCMIWAIT:
- return modem_input_wait(info,(int)arg);
+ ret = modem_input_wait(info,(int)arg);
+ break;
case MGSL_IOCGIF:
- return get_interface(info, argp);
+ ret = get_interface(info, argp);
+ break;
case MGSL_IOCSIF:
- return set_interface(info,(int)arg);
+ ret = set_interface(info,(int)arg);
+ break;
case MGSL_IOCSGPIO:
- return set_gpio(info, argp);
+ ret = set_gpio(info, argp);
+ break;
case MGSL_IOCGGPIO:
- return get_gpio(info, argp);
+ ret = get_gpio(info, argp);
+ break;
case MGSL_IOCWAITGPIO:
- return wait_gpio(info, argp);
+ ret = wait_gpio(info, argp);
+ break;
case TIOCGICOUNT:
spin_lock_irqsave(>lock,flags);
cnow = info->icount;
@@ -1156,12 +1174,14 @@
put_user(cnow.parity, _cuser->parity) ||
put_user(cnow.brk, _cuser->brk) ||
put_user(cnow.buf_overrun, _cuser->buf_overrun))
- return -EFAULT;
- return 0;
+ ret = -EFAULT;
+ ret = 0;
+ break;
default:
- return -ENOIOCTLCMD;
+ ret = -ENOIOCTLCMD;
}
- return 0;
+ unlock_kernel();
+ return ret;
}
/*
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclinkmp.c
[PATCH] viocons: BKL locking
For some weird reason I can't ascertain (translation "I think its broken") the viocons driver calls directly into the n_tty ldisc code even if another ldisc is in use. It'll probably break if you do that but I'm just fixing the locking and adding a comment that its horked. Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.25-rc2-mm1/drivers/char/viocons.c linux-2.6.25-rc2-mm1/drivers/char/viocons.c --- linux.vanilla-2.6.25-rc2-mm1/drivers/char/viocons.c 2008-02-19 11:01:44.0 + +++ linux-2.6.25-rc2-mm1/drivers/char/viocons.c 2008-02-20 11:49:24.0 + @@ -704,8 +704,11 @@ case KDSKBLED: return 0; } - - return n_tty_ioctl(tty, file, cmd, arg); + /* FIXME: WTF is this being called for ??? */ + lock_kernel(); + ret = n_tty_ioctl(tty, file, cmd, arg); + unlock_kernel(); + return ret; } /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
On Wed, 2008-02-20 at 15:18 +0300, Anton Vorontsov wrote: > On Wed, Feb 20, 2008 at 11:56:35AM +1100, Paul Mackerras wrote: > > Andrew Morton writes: > > > > > Bizarrely, the original author of the patch (Anton) has fallen off the > > > cc. > > > Could whoever did that please thwap himself? > > > > > > Anyway, my head is now officially spinning. Did anyone actually have a > > > reason why we shouldn't proceed with Anton's patch? > > > > I was wondering if it would be sufficient to provide alternative > > versions of fb_readl, fb_writel etc. that do byte-swapping. > > This is of course viable alternative. And I was considering this, but > later I abandoned the idea: that way we'll end up doing math in the > native endianness and then converting it to the foreign. This feels > ugly in contrast when we can do the right math in the first place, per > framebuffer. Also, the type of swap to do in fb_readl/writel would have to depend on the bit depth which is kind of ugly. > > That > > would mean that all framebuffers would have to have the same > > endianness, > > Yup, another downside of changing the code to fix some narrow > problem. Plus, this means things will break if/when we'll attach > PCI video card into the MPC8360E-RDK. Right. Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sx: prepare for BKL pushdown
Wrap the ioctl handler, and in this case the break handler also in the
BKL. Remove bogus softcar handlers.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/sx.c
linux-2.6.25-rc2-mm1/drivers/char/sx.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/sx.c 2008-02-19
11:01:44.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/sx.c 2008-02-20 11:49:03.0
+
@@ -1844,6 +1844,7 @@
int rv;
func_enter();
+ lock_kernel();
if (flag)
rv = sx_send_command(port, HS_START, -1, HS_IDLE_BREAK);
@@ -1852,7 +1853,7 @@
if (rv != 1)
printk(KERN_ERR "sx: couldn't send break (%x).\n",
read_sx_byte(port->board, CHAN_OFFSET(port, hi_hstat)));
-
+ unlock_kernel();
func_exit();
}
@@ -1888,23 +1889,12 @@
int rc;
struct sx_port *port = tty->driver_data;
void __user *argp = (void __user *)arg;
- int ival;
/* func_enter2(); */
rc = 0;
+ lock_kernel();
switch (cmd) {
- case TIOCGSOFTCAR:
- rc = put_user(((tty->termios->c_cflag & CLOCAL) ? 1 : 0),
- (unsigned __user *)argp);
- break;
- case TIOCSSOFTCAR:
- if ((rc = get_user(ival, (unsigned __user *)argp)) == 0) {
- tty->termios->c_cflag =
- (tty->termios->c_cflag & ~CLOCAL) |
- (ival ? CLOCAL : 0);
- }
- break;
case TIOCGSERIAL:
rc = gs_getserial(>gs, argp);
break;
@@ -1915,6 +1905,7 @@
rc = -ENOIOCTLCMD;
break;
}
+ unlock_kernel();
/* func_exit(); */
return rc;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver updates
Divy Le Ray wrote:
Jeff Garzik wrote:
Mostly fixes, a few cleanups (generally assisting fixes), and an
exception for PS3 wireless because it had been posted, reviewed and
acked for a while, just not committed.
Please pull from 'upstream-davem' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-davem
to receive the following updates:
drivers/net/cxgb3/sge.c | 35 +-
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index 9ca8c66..979f3fc 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -1059,6 +1059,14 @@ static void write_tx_pkt_wr(struct adapter
*adap, struct sk_buff *skb,
htonl(V_WR_TID(q->token)));
}
+static inline void t3_stop_queue(struct net_device *dev, struct
sge_qset *qs,
+ struct sge_txq *q)
+{
+netif_stop_queue(dev);
+set_bit(TXQ_ETH, >txq_stopped);
+q->stops++;
+}
+
/**
*eth_xmit - add a packet to the Ethernet Tx queue
*@skb: the packet
@@ -1090,31 +1098,18 @@ int t3_eth_xmit(struct sk_buff *skb, struct
net_device *dev)
ndesc = calc_tx_descs(skb);
if (unlikely(credits < ndesc)) {
-if (!netif_queue_stopped(dev)) {
-netif_stop_queue(dev);
-set_bit(TXQ_ETH, >txq_stopped);
-q->stops++;
-dev_err(>pdev->dev,
-"%s: Tx ring %u full while queue awake!\n",
-dev->name, q->cntxt_id & 7);
-}
+t3_stop_queue(dev, qs, q);
+dev_err(>pdev->dev,
+"%s: Tx ring %u full while queue awake!\n",
+dev->name, q->cntxt_id & 7);
spin_unlock(>lock);
return NETDEV_TX_BUSY;
}
q->in_use += ndesc;
-if (unlikely(credits - ndesc < q->stop_thres)) {
-q->stops++;
-netif_stop_queue(dev);
-set_bit(TXQ_ETH, >txq_stopped);
-#if !USE_GTS
-if (should_restart_tx(q) &&
-test_and_clear_bit(TXQ_ETH, >txq_stopped)) {
-q->restarts++;
-netif_wake_queue(dev);
-}
-#endif
-}
+if (unlikely(credits - ndesc < q->stop_thres))
+if (USE_GTS || !should_restart_tx(q))
+t3_stop_queue(dev, qs, q);
gen = q->gen;
q->unacked += ndesc;
Hi Jeff,
I thought I had NAK'ed the patch modifying sge.c from Krishna Kumar.
Looking back at my answer at the time, I was obviously unclear.
Can you please revert the drivers/net/cxgb3sge.c change ?
Explain why, so I can include it in the changelog please...
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] Re: [PATCH 4/12] riscom8: fix SMP brokenness
Ingo Molnar wrote:
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
After analyzing the elements that save_flags/cli/sti/restore_flags
were protecting, convert their usages to a global spinlock (the
easiest and most obvious next-step). There were some usages of flags
being intentionally cached, because the code already knew the state of
interrupts. These have been taken into account.
This allows us to remove CONFIG_BROKEN_ON_SMP. Completely untested.
regression for sale :-) The above patch, after sitting in -mm for
approximately 3 months, just went upstream today via commit
d9afa43532adf8a31b93c4c7601f and promptly broke tonight's x86.git
randconfig qa run via tons of these messages:
[3.768431] BUG: scheduling while atomic: swapper/1/0x0002
[3.769430] 1 lock held by swapper/1:
[3.770437] #0: (riscom_lock){--..}, at: [<80389ceb>]
rc_release_drivers+0xe/0x33
[3.776430] Pid: 1, comm: swapper Not tainted 2.6.24 #14
[3.777428] [<801167d3>] __schedule_bug+0x6e/0x75
[3.779427] [<80756065>] schedule+0x35c/0x429
[3.781427] [<80103a0b>] ? restore_nocheck+0x12/0x15
[3.784427] [<80103a0b>] ? restore_nocheck+0x12/0x15
[3.786426] [<80756381>] schedule_timeout+0x69/0xa2
[3.788426] [<80758337>] ? _spin_unlock_irq+0x25/0x40
[3.790426] [<80755c0e>] wait_for_common+0x96/0x10d
[3.792425] [<80115edc>] ? default_wake_function+0x0/0xd
[3.794425] [<80755d07>] wait_for_completion+0x12/0x14
[3.796425] [<801282fe>] call_usermodehelper_exec+0x78/0x8c
[3.798424] [<8015a041>] ? slob_alloc+0xd8/0x1ad
[3.800424] [<80301640>] kobject_uevent_env+0x3ae/0x3c5
[3.802424] [<803ac361>] ? dev_uevent+0x0/0x25a
[3.804424] [<80301661>] kobject_uevent+0xa/0xc
[3.806423] [<803acc06>] device_del+0x139/0x15d
[3.808423] [<803acc58>] device_unregister+0x2e/0x3b
[3.810423] [<803acc8e>] device_destroy+0x29/0x2f
[3.812422] [<8035965f>] tty_unregister_device+0x18/0x1a
[3.814422] [<8035970b>] tty_unregister_driver+0xaa/0xf6
[3.816422] [<80389cf7>] rc_release_drivers+0x1a/0x33
[3.818421] [<80ac5e16>] riscom8_init_module+0x4ff/0x539
[3.820421] [<8012e76f>] ? ktime_get_ts+0x44/0x49
[3.822421] [<80aaf701>] kernel_init+0x9a/0x263
[3.824421] [<80ac5917>] ? riscom8_init_module+0x0/0x539
[3.827420] [<80aaf667>] ? kernel_init+0x0/0x263
[3.829420] [<8010455f>] kernel_thread_helper+0x7/0x18
[3.831419] ===
This is unfortunately very low on the priority stack. I was a bit
surprised when it went in, honestly, since I hadn't gotten any "it
works" test reports yet... but that's my fault for not keeping akpm up
to date.
We'll want to revert this for 2.6.25 release, if it doesn't get fixed up.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] stallion: Prepare for BKL push down
Remove broken softcar functions, wrap ioctl handler in BKL
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/stallion.c
linux-2.6.25-rc2-mm1/drivers/char/stallion.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/stallion.c2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/stallion.c2008-02-20
11:49:03.0 +
@@ -1273,18 +1273,9 @@
rc = 0;
+ lock_kernel();
+
switch (cmd) {
- case TIOCGSOFTCAR:
- rc = put_user(((tty->termios->c_cflag & CLOCAL) ? 1 : 0),
- (unsigned __user *) argp);
- break;
- case TIOCSSOFTCAR:
- if (get_user(ival, (unsigned int __user *) arg))
- return -EFAULT;
- tty->termios->c_cflag =
- (tty->termios->c_cflag & ~CLOCAL) |
- (ival ? CLOCAL : 0);
- break;
case TIOCGSERIAL:
rc = stl_getserial(portp, argp);
break;
@@ -1308,7 +1299,7 @@
rc = -ENOIOCTLCMD;
break;
}
-
+ unlock_kernel();
return rc;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] specialix: Prepare for BKL pushdown
Lock the ioctl handlers and remove bogus softcar handling.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/specialix.c
linux-2.6.25-rc2-mm1/drivers/char/specialix.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/specialix.c 2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/specialix.c 2008-02-20
11:48:55.0 +
@@ -1924,29 +1924,13 @@
int change_speed;
func_enter();
- /*
- if (!access_ok(VERIFY_READ, (void *) newinfo, sizeof(tmp))) {
- func_exit();
- return -EFAULT;
- }
- */
+
if (copy_from_user(, newinfo, sizeof(tmp))) {
func_enter();
return -EFAULT;
}
-
-#if 0
- if ((tmp.irq != bp->irq) ||
- (tmp.port != bp->base) ||
- (tmp.type != PORT_CIRRUS) ||
- (tmp.baud_base != (SX_OSCFREQ + CD186x_TPC/2) / CD186x_TPC) ||
- (tmp.custom_divisor != 0) ||
- (tmp.xmit_fifo_size != CD186x_NFIFO) ||
- (tmp.flags & ~SPECIALIX_LEGAL_FLAGS)) {
- func_exit();
- return -EINVAL;
- }
-#endif
+
+ lock_kernel();
change_speed = ((port->flags & ASYNC_SPD_MASK) !=
(tmp.flags & ASYNC_SPD_MASK));
@@ -1958,6 +1942,7 @@
((tmp.flags & ~ASYNC_USR_MASK) !=
(port->flags & ~ASYNC_USR_MASK))) {
func_exit();
+ unlock_kernel();
return -EPERM;
}
port->flags = ((port->flags & ~ASYNC_USR_MASK) |
@@ -1974,6 +1959,7 @@
sx_change_speed(bp, port);
}
func_exit();
+ unlock_kernel();
return 0;
}
@@ -1986,12 +1972,8 @@
func_enter();
- /*
- if (!access_ok(VERIFY_WRITE, (void *) retinfo, sizeof(tmp)))
- return -EFAULT;
- */
-
memset(, 0, sizeof(tmp));
+ lock_kernel();
tmp.type = PORT_CIRRUS;
tmp.line = port - sx_port;
tmp.port = bp->base;
@@ -2002,6 +1984,7 @@
tmp.closing_wait = port->closing_wait * HZ/100;
tmp.custom_divisor = port->custom_divisor;
tmp.xmit_fifo_size = CD186x_NFIFO;
+ unlock_kernel();
if (copy_to_user(retinfo, , sizeof(tmp))) {
func_exit();
return -EFAULT;
@@ -2047,23 +2030,6 @@
sx_send_break(port, arg ? arg*(HZ/10) : HZ/4);
func_exit();
return 0;
-case TIOCGSOFTCAR:
-if (put_user(C_CLOCAL(tty)?1:0, (unsigned long __user *)argp))
{
-func_exit();
-return -EFAULT;
-}
-func_exit();
- return 0;
-case TIOCSSOFTCAR:
-if (get_user(arg, (unsigned long __user *) argp)) {
-func_exit();
-return -EFAULT;
-}
- tty->termios->c_cflag =
- ((tty->termios->c_cflag & ~CLOCAL) |
- (arg ? CLOCAL : 0));
- func_exit();
- return 0;
case TIOCGSERIAL:
func_exit();
return sx_get_serial_info(port, argp);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] serial167: prepare to push BKL down into drivers
Kill the softcar handlers again, wrap the ioctl handler in the BKL
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/serial167.c
linux-2.6.25-rc2-mm1/drivers/char/serial167.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/serial167.c 2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/serial167.c 2008-02-20
11:48:49.0 +
@@ -1539,6 +1539,8 @@
printk("cy_ioctl %s, cmd = %x arg = %lx\n", tty->name, cmd, arg);
/* */
#endif
+ lock_kernel();
+
switch (cmd) {
case CYGETMON:
ret_val = get_mon_info(info, argp);
@@ -1584,18 +1586,6 @@
break;
/* The following commands are incompletely implemented!!! */
- case TIOCGSOFTCAR:
- ret_val =
- put_user(C_CLOCAL(tty) ? 1 : 0,
-(unsigned long __user *)argp);
- break;
- case TIOCSSOFTCAR:
- ret_val = get_user(val, (unsigned long __user *)argp);
- if (ret_val)
- break;
- tty->termios->c_cflag =
- ((tty->termios->c_cflag & ~CLOCAL) | (val ? CLOCAL : 0));
- break;
case TIOCGSERIAL:
ret_val = get_serial_info(info, argp);
break;
@@ -1605,6 +1595,7 @@
default:
ret_val = -ENOIOCTLCMD;
}
+ unlock_kernel();
#ifdef SERIAL_DEBUG_OTHER
printk("cy_ioctl done\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rocket: Prepare for BKL pushdown
Wrap the ioctl code in lock_kernel calls
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/rocket.c
linux-2.6.25-rc2-mm1/drivers/char/rocket.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/rocket.c 2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/rocket.c 2008-02-20 11:48:44.0
+
@@ -1432,29 +1432,38 @@
{
struct r_port *info = (struct r_port *) tty->driver_data;
void __user *argp = (void __user *)arg;
+ int ret = 0;
if (cmd != RCKP_GET_PORTS && rocket_paranoia_check(info, "rp_ioctl"))
return -ENXIO;
+ lock_kernel();
+
switch (cmd) {
case RCKP_GET_STRUCT:
if (copy_to_user(argp, info, sizeof (struct r_port)))
- return -EFAULT;
- return 0;
+ ret = -EFAULT;
+ break;
case RCKP_GET_CONFIG:
- return get_config(info, argp);
+ ret = get_config(info, argp);
+ break;
case RCKP_SET_CONFIG:
- return set_config(info, argp);
+ ret = set_config(info, argp);
+ break;
case RCKP_GET_PORTS:
- return get_ports(info, argp);
+ ret = get_ports(info, argp);
+ break;
case RCKP_RESET_RM2:
- return reset_rm2(info, argp);
+ ret = reset_rm2(info, argp);
+ break;
case RCKP_GET_VERSION:
- return get_version(info, argp);
+ ret = get_version(info, argp);
+ break;
default:
- return -ENOIOCTLCMD;
+ ret = -ENOIOCTLCMD;
}
- return 0;
+ unlock_kernel();
+ return ret;
}
static void rp_send_xchar(struct tty_struct *tty, char ch)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: USB OOPS 2.6.25-rc2-git1
David Brownell wrote: On Tuesday 19 February 2008, Andre Tomt wrote: Can you try this diagnostic patch, to see if it reports any messages about IAA and/or IAAD oddities? There's surely a quick workaround for this, but I'd rather understand the root cause before patching. Doesn't seem to have triggered anything. dmesg attached in case I missed anything. You don't seem to have enabled CONFIG_USB_DEBUG, as the patch instructions say is needed to get such diagnostics ... I can tell because the startup messages from USB are pretty minimal. (See appended, vs what you sent...) Please try again with USB debugging enabled. Argh, silly me. Here you go (attached). It has not crashed yet with the patch though. Initializing cgroup subsys cpuset Linux version 2.6.25-rc2-git1 ([EMAIL PROTECTED]) (gcc version 4.2.3 (Debian 4.2.3-1)) #5 SMP Wed Feb 20 09:40:27 CET 2008 Command line: root=/dev/sda1 ro rootflags=noatime rootfstype=ext2 console=ttyS0,38400 verbose BIOS-provided physical RAM map: BIOS-e820: - 0009bc00 (usable) BIOS-e820: 0009bc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7fee (usable) BIOS-e820: 7fee - 7fee3000 (ACPI NVS) BIOS-e820: 7fee3000 - 7fef (ACPI data) BIOS-e820: 7fef - 7ff0 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) Entering add_active_range(0, 0, 155) 0 entries of 3200 used Entering add_active_range(0, 256, 524000) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP 000F7850, 0014 (r0 IntelR) ACPI: RSDT 7FEE3040, 0038 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: FACP 7FEE30C0, 0074 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: DSDT 7FEE3180, 463D (r1 INTELR AWRDACPI 1000 MSFT 300) ACPI: FACS 7FEE, 0040 ACPI: HPET 7FEE7900, 0038 (r1 IntelR AWRDACPI 42302E31 AWRD 98) ACPI: MCFG 7FEE7980, 003C (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: APIC 7FEE7800, 0084 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: SSDT 7FEE8020, 02F1 (r1 PmRefCpuPm 3000 INTL 20040311) No NUMA configuration found Faking a node at -7fee Entering add_active_range(0, 0, 155) 0 entries of 3200 used Entering add_active_range(0, 256, 524000) 1 entries of 3200 used Bootmem setup node 0 -7fee NODE_DATA [c000 - 00012fff] bootmap [00013000 - 00022fdf] pages 10 early res: 0 [0-fff] BIOS data page early res: 1 [6000-7fff] SMP_TRAMPOLINE early res: 2 [20-565977] TEXT DATA BSS early res: 3 [37a43000-37fef4eb] RAMDISK early res: 4 [9bc00-abbff] EBDA early res: 5 [8000-bfff] PGTABLE [e200-e21f] PMD ->81000120 on node 0 [e220-e23f] PMD ->81000160 on node 0 [e240-e25f] PMD ->810001a0 on node 0 [e260-e27f] PMD ->810001e0 on node 0 [e280-e29f] PMD ->81000220 on node 0 [e2a0-e2bf] PMD ->81000260 on node 0 [e2c0-e2df] PMD ->810002a0 on node 0 [e2e0-e2ff] PMD ->810002e0 on node 0 [e2000100-e200011f] PMD ->81000320 on node 0 [e2000120-e200013f] PMD ->81000360 on node 0 [e2000140-e200015f] PMD ->810003a0 on node 0 [e2000160-e200017f] PMD ->810003e0 on node 0 [e2000180-e200019f] PMD ->81000420 on node 0 [e20001a0-e20001bf] PMD ->81000460 on node 0 Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 -> 155 0: 256 -> 524000 On node 0 totalpages: 523899 DMA zone: 56 pages used for memmap DMA zone: 894 pages reserved DMA zone: 3045 pages, LIFO batch:0 DMA32 zone: 7108 pages used for memmap DMA32 zone: 512796 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 4, address 0xfec0, GSI 0-23 ACPI:
Re: [PATCH 1/4] make dev_to_node return online node
please use this one instead. this one is less intrusive, and pcibus_to_node will work too and don't need other changes. YH --- [PATCH] make dev_to_node return online node v2 some numa system ( with multi HT chains) may return node without ram. aka it is not online. try to get one online node, otherwise return -1 Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c index c163ad1..2c1a651 100644 --- a/arch/x86/pci/acpi.c +++ b/arch/x86/pci/acpi.c @@ -213,6 +213,9 @@ struct pci_bus * __devinit pci_acpi_scan_root(struct acpi_device *device, int do set_mp_bus_to_node(busnum, node); else node = get_mp_bus_to_node(busnum); + + if (node != -1 && !node_online(node)) + node = -1; #endif /* Allocate per-root-bus (not per bus) arch-specific data. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver
On Wed, 2008-02-20 at 11:05 -0500, Dan Williams wrote: > On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote: > > On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote: > > > Hi, > > > > > > [added rt2400-devel (rt2x00 development mailinglist) to the CC list.] > > > > > > > > > > I have a series of tests I would like to request from you, > > > > > > > you mentioned you already enabled debugfs, and that is just what > > > > > > > we need. ;) > > > > > > > Please use attached script to create dumps of the hardware > > > > > > > register contents. > > > > > > > > > > > > > > There are specific moments that should be dumped: > > > > > > > - kernel 2.6.24 (last known working version for you). > > > > > > > - kernel 2.6.25-rc2 (after ifup, before TX dies) > > > > > > > - kernel 2.6.25-rc2 (after ifup, after TX dies) > > > > > > > > > > > > > > > > > > > These diagnostics are attached, with obvious filenames. > > > > > > > > > > Thanks. I think I found something, please test below patch: > > > > > > > > > > > > > I've tried the patch but, unfortunately, my wireless LAN still dies > > > > after a few pings. > > > > rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2 > > kernel (not wireless-2.6/rt2x00 git). The modules load when I plug the > > stick in but I then get a complete kernel lock up with two flashing > > leds. Nothing is recorded to system logs. The last logged messages are > > that usbcore has registered new interface driver rt73usb, and that the > > rate control algorithm has been selected on phy0. This happens whether > > the simple or pid mac80211 rate control algorithms have been chosen. > > > > This is a shame because 2.0.14 was working really well for me until the > > mac80211 changes 2 or 3 weeks ago broke it. (Shortly followed by the > > release of 2.1.*). > > Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a > picture of the panic if one shows up. _Something_ should show up on the > VT. I did that yesterday and it just reported a kernel panic on the terminal with the message: Kernel panic - not syncing: Aiee, killing interrupt handler! There is a complete lock up. Even the two leds don't send a dump in morse code (if that is still a feature of the 2.6 kernels). They just flash together at 1 second intervals. However, I do not have debugging enabled on 2.6.25-rc2 (I was just interested to see how it worked). If it is thought to be useful I can recompile the kernel with debugging enabled, but this should be reproducible by anyone with a rt73 stick. By way of a further data point, I can scan OK using 2.6.25-rc2 and it will report all the available access points in my area. But as soon as association is attempted, it blows up. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] riscom8: Prepare for BKL pushdown
Push the locking down into a couple of functions that need it and remove
bogus TIOCG/SSOFTCAR handling
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/riscom8.c
linux-2.6.25-rc2-mm1/drivers/char/riscom8.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/riscom8.c 2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/riscom8.c 2008-02-20 11:48:38.0
+
@@ -1385,7 +1385,7 @@
{
struct riscom_port *port = (struct riscom_port *)tty->driver_data;
void __user *argp = (void __user *)arg;
- int retval;
+ int retval = 0;
if (rc_paranoia_check(port, tty->name, "rc_ioctl"))
return -ENODEV;
@@ -1406,23 +1406,20 @@
tty_wait_until_sent(tty, 0);
rc_send_break(port, arg ? arg*(HZ/10) : HZ/4);
break;
-case TIOCGSOFTCAR:
- return put_user(C_CLOCAL(tty) ? 1 : 0, (unsigned __user *)argp);
-case TIOCSSOFTCAR:
- if (get_user(arg,(unsigned __user *) argp))
- return -EFAULT;
- tty->termios->c_cflag =
- ((tty->termios->c_cflag & ~CLOCAL) |
- (arg ? CLOCAL : 0));
+case TIOCGSERIAL:
+ lock_kernel();
+ retval = rc_get_serial_info(port, argp);
+ unlock_kernel();
break;
-case TIOCGSERIAL:
- return rc_get_serial_info(port, argp);
case TIOCSSERIAL:
- return rc_set_serial_info(port, argp);
+ lock_kernel();
+ retval = rc_set_serial_info(port, argp);
+ unlock_kernel();
+ break;
default:
- return -ENOIOCTLCMD;
+ retval = -ENOIOCTLCMD;
}
- return 0;
+ return retval;
}
static void rc_throttle(struct tty_struct * tty)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] x86_64: CPA, fix cache attribute inconsistency bug, v2.6.22 backport
On Fri, Feb 15, 2008 at 08:58:22PM +0100, Ingo Molnar wrote:
>
> fix CPA cache attribute bug in v2.6.23. When phys_base is nonzero
> (when CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates
> the secondary alias address by -14 MB (depending on the configured
> offset).
>
> The default 64-bit kernels of Fedora and Ubuntu are affected:
>
>$ grep RELOCA /boot/config-2.6.23.9-85.fc8
> CONFIG_RELOCATABLE=y
>
>$ grep RELOC /boot/config-2.6.22-14-generic
> CONFIG_RELOCATABLE=y
>
> and probably on many other distros as well.
>
> the bug affects all pages in the first 40 MB of physical RAM that
> are allocated by some subsystem that does ioremap_nocache() on them:
>
>if (__pa(address) < KERNEL_TEXT_SIZE) {
>
> Hence we might leave page table entries with inconsistent cache
> attributes around (pages mapped at both UnCacheable and Write-Back),
> and we can also set the wrong kernel text pages to UnCacheable.
>
> the effects of this bug can be random slowdowns and other misbehavior.
> If for example AGP allocates its aperture pages into the first 40 MB
> of physical RAM, then the -14 MB bug might mark random kernel texto
> pages as uncacheable, slowing down a random portion of the 64-bit
> kernel until the AGP driver is unloaded.
>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
> ---
> arch/x86_64/mm/pageattr.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-tmp/arch/x86_64/mm/pageattr.c
> ===
> --- linux-tmp.orig/arch/x86_64/mm/pageattr.c
> +++ linux-tmp/arch/x86_64/mm/pageattr.c
> @@ -204,7 +204,7 @@ int change_page_attr_addr(unsigned long
> if (__pa(address) < KERNEL_TEXT_SIZE) {
Hi Ingo,
Should we change above condition also to something like following.
kernel_phys_start = __pa(__START_KERNEL_map) + phys_base
kernel_phys_end = kernel_phys_start + KERNEL_TEXT_SIZE
if (__pa(address) >= kernel_phys_start
&& __pa(address) <= kernel_phys_end)
Looks like we are trying to see if a physical page has been mapped
by kernel text/data region also then change the caching attributes there too.
In case of relocatable kernel, not necessarily first 40MB will be mapped by
the kernel text/data region, If boot loader decides to load kernel
at a higher address and phys_base is non-zero.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nozomi: Prepare for BKL pushdown
We leave the BKL around the rts/dtr handler because there is *no* locking
of any kind on this in the driver. It's not "right" with this change but
it's the same wrong as before..
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/nozomi.c
linux-2.6.25-rc2-mm1/drivers/char/nozomi.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/nozomi.c 2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/nozomi.c 2008-02-20 11:45:57.0
+
@@ -1716,6 +1716,7 @@
static int ntty_tiocmset(struct tty_struct *tty, struct file *file,
unsigned int set, unsigned int clear)
{
+ lock_kernel(); /* FIXME: Add internal locking */
if (set & TIOCM_RTS)
set_rts(tty, 1);
else if (clear & TIOCM_RTS)
@@ -1725,7 +1726,7 @@
set_dtr(tty, 1);
else if (clear & TIOCM_DTR)
set_dtr(tty, 0);
-
+ unlock_kernel();
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote: > > I think we should export the target sleep state somehow. Yeah. By *not* using "->suspend()" for freezing or hibernate. Please, Rafael - just make the f*cking suspend-to-disk use other routines already. 99% of all hardware needs to do exactly *nothing* on suspend-to-disk, and the ones that really do need things tend to need to not do a whole lot. For example, the "freeze" action for USB (which is one of the hardest things to suspend) should literally be something like just setting the controller STOP bit, and waiting for it to have stopped. The "unfreeze" should be to just clear the stop bit, while the "restart" should be just a controller reset to use the current memory image. NONE OF THIS HAS ABSOLUTELY ANYTHING TO DO WITH SUSPEND. It never did. I've told people so for years. Maybe actually seeing the problems will make people realize. So please, we shouldn't call "->suspend[_late]" or "->resume[_early]" at all. Not with PMSG_FREEZE, not with PMSG_*anything*. Can we please get this fixed some day? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mxser: prepare for BKL pushdown
Push the BKL down into various internal routines in the driver ready to
remove it from the break, ioctl and other call points.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/mxser.c
linux-2.6.25-rc2-mm1/drivers/char/mxser.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/mxser.c 2008-02-19
11:03:26.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/mxser.c 2008-02-20 11:45:57.0
+
@@ -1658,6 +1658,7 @@
struct mxser_port *port;
int result, status;
unsigned int i, j;
+ int ret = 0;
switch (cmd) {
case MOXA_GET_MAJOR:
@@ -1665,18 +1666,21 @@
case MOXA_CHKPORTENABLE:
result = 0;
-
+ lock_kernel();
for (i = 0; i < MXSER_BOARDS; i++)
for (j = 0; j < MXSER_PORTS_PER_BOARD; j++)
if (mxser_boards[i].ports[j].ioaddr)
result |= (1 << i);
-
+ unlock_kernel();
return put_user(result, (unsigned long __user *)argp);
case MOXA_GETDATACOUNT:
+ lock_kernel();
if (copy_to_user(argp, _log, sizeof(mxvar_log)))
- return -EFAULT;
- return 0;
+ ret = -EFAULT;
+ unlock_kernel();
+ return ret;
case MOXA_GETMSTATUS:
+ lock_kernel();
for (i = 0; i < MXSER_BOARDS; i++)
for (j = 0; j < MXSER_PORTS_PER_BOARD; j++) {
port = _boards[i].ports[j];
@@ -1713,6 +1717,7 @@
else
GMStatus[i].cts = 0;
}
+ unlock_kernel();
if (copy_to_user(argp, GMStatus,
sizeof(struct mxser_mstatus) * MXSER_PORTS))
return -EFAULT;
@@ -1722,7 +1727,8 @@
unsigned long opmode;
unsigned cflag, iflag;
- for (i = 0; i < MXSER_BOARDS; i++)
+ lock_kernel();
+ for (i = 0; i < MXSER_BOARDS; i++) {
for (j = 0; j < MXSER_PORTS_PER_BOARD; j++) {
port = _boards[i].ports[j];
if (!port->ioaddr)
@@ -1787,13 +1793,14 @@
mon_data_ext.iftype[i] = opmode;
}
- if (copy_to_user(argp, _data_ext,
- sizeof(mon_data_ext)))
- return -EFAULT;
-
- return 0;
-
- } default:
+ }
+ unlock_kernel();
+ if (copy_to_user(argp, _data_ext,
+ sizeof(mon_data_ext)))
+ return -EFAULT;
+ return 0;
+ }
+ default:
return -ENOIOCTLCMD;
}
return 0;
@@ -1849,16 +1856,20 @@
opmode != RS422_MODE &&
opmode != RS485_4WIRE_MODE)
return -EFAULT;
+ lock_kernel();
mask = ModeMask[p];
shiftbit = p * 2;
val = inb(info->opmode_ioaddr);
val &= mask;
val |= (opmode << shiftbit);
outb(val, info->opmode_ioaddr);
+ unlock_kernel();
} else {
+ lock_kernel();
shiftbit = p * 2;
opmode = inb(info->opmode_ioaddr) >> shiftbit;
opmode &= OP_MODE_MASK;
+ unlock_kernel();
if (put_user(opmode, (int __user *)argp))
return -EFAULT;
}
@@ -1885,19 +1896,18 @@
tty_wait_until_sent(tty, 0);
mxser_send_break(info, arg ? arg * (HZ / 10) : HZ / 4);
return 0;
- case TIOCGSOFTCAR:
- return put_user(!!C_CLOCAL(tty), (unsigned long __user *)argp);
- case TIOCSSOFTCAR:
- if (get_user(arg, (unsigned long __user *)argp))
- return -EFAULT;
- tty->termios->c_cflag = ((tty->termios->c_cflag & ~CLOCAL) |
(arg ? CLOCAL : 0));
- return 0;
case TIOCGSERIAL:
- return mxser_get_serial_info(info, argp);
+ lock_kernel();
+ retval = mxser_get_serial_info(info, argp);
+ unlock_kernel();
+ return retval;
case TIOCSSERIAL:
- return mxser_set_serial_info(info, argp);
+ lock_kernel();
+
Re: 2.6.25-rc[1,2]: failed to setup dm-crypt key mapping
On Feb 20, 2008 7:58 PM, Herbert Xu <[EMAIL PROTECTED]> wrote: > On Wed, Feb 20, 2008 at 06:47:58PM +0100, Milan Broz wrote: > > > > I just tested one affected configuration and problem was in missing > > "chainiv.ko" module on ramdisk. > > Ah OK. We probably should merge chainiv into the blkcipher > module too since it's the default IV generator. I'll take > care of it. Right. Manually adding chainiv.ko to initramfs makes it boot again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] moxa: prepare for BKL pushdown
Moxa needs a few routines wrapping with the BKL for now. It also snoops
the TIOCG/SSOFTCAR function so needs its own implementation for now. That
wants fixing by turning it into a termios set downcall into the drivers
later.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/moxa.c
linux-2.6.25-rc2-mm1/drivers/char/moxa.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/moxa.c2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/moxa.c2008-02-20 11:45:50.0
+
@@ -686,8 +686,8 @@
int flag = 0, dtr, rts;
port = tty->index;
- if ((port != MAX_PORTS) && (!ch))
- return (-EINVAL);
+ if (port != MAX_PORTS && !ch)
+ return -EINVAL;
MoxaPortGetLineOut(ch->port, , );
if (dtr)
@@ -712,9 +712,10 @@
int dtr, rts;
port = tty->index;
- if ((port != MAX_PORTS) && (!ch))
- return (-EINVAL);
+ if (port != MAX_PORTS && !ch)
+ return -EINVAL;
+ lock_kernel();
MoxaPortGetLineOut(ch->port, , );
if (set & TIOCM_RTS)
rts = 1;
@@ -725,6 +726,7 @@
if (clear & TIOCM_DTR)
dtr = 0;
MoxaPortLineCtrl(ch->port, dtr, rts);
+ unlock_kernel();
return 0;
}
@@ -734,52 +736,56 @@
struct moxa_port *ch = (struct moxa_port *) tty->driver_data;
register int port;
void __user *argp = (void __user *)arg;
- int retval;
-
+ int retval = 0;
+
port = tty->index;
- if ((port != MAX_PORTS) && (!ch))
- return (-EINVAL);
+ if (port != MAX_PORTS && !ch)
+ return -EINVAL;
switch (cmd) {
case TCSBRK:/* SVID version: non-zero arg --> no break */
retval = tty_check_change(tty);
if (retval)
- return (retval);
+ break;
moxa_setup_empty_event(tty);
tty_wait_until_sent(tty, 0);
if (!arg)
MoxaPortSendBreak(ch->port, 0);
- return (0);
+ break;
case TCSBRKP: /* support for POSIX tcsendbreak() */
retval = tty_check_change(tty);
if (retval)
- return (retval);
+ break;
moxa_setup_empty_event(tty);
tty_wait_until_sent(tty, 0);
MoxaPortSendBreak(ch->port, arg);
- return (0);
- case TIOCGSOFTCAR:
- return put_user(C_CLOCAL(tty) ? 1 : 0, (unsigned long __user *)
argp);
+ break;
case TIOCSSOFTCAR:
if(get_user(retval, (unsigned long __user *) argp))
return -EFAULT;
arg = retval;
+ mutex_lock(>termios_mutex);
tty->termios->c_cflag = ((tty->termios->c_cflag & ~CLOCAL) |
(arg ? CLOCAL : 0));
if (C_CLOCAL(tty))
ch->asyncflags &= ~ASYNC_CHECK_CD;
else
ch->asyncflags |= ASYNC_CHECK_CD;
- return (0);
+ mutex_unlock(>termios_mutex);
+ break;
case TIOCGSERIAL:
return moxa_get_serial_info(ch, argp);
-
case TIOCSSERIAL:
- return moxa_set_serial_info(ch, argp);
+ lock_kernel();
+ retval = moxa_set_serial_info(ch, argp);
+ unlock_kernel();
+ break;
default:
+ lock_kernel();
retval = MoxaDriverIoctl(cmd, arg, port);
+ unlock_kernel();
}
- return (retval);
+ return retval;
}
static void moxa_throttle(struct tty_struct *tty)
@@ -2414,6 +2420,7 @@
struct serial_struct tmp;
memset(, 0, sizeof(tmp));
+ lock_kernel();
tmp.type = info->type;
tmp.line = info->port;
tmp.port = 0;
@@ -2424,6 +2431,7 @@
tmp.closing_wait = info->closing_wait;
tmp.custom_divisor = 0;
tmp.hub6 = 0;
+ unlock_kernel();
if(copy_to_user(retinfo, , sizeof(*retinfo)))
return -EFAULT;
return (0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] isicom: istallion prepare for lock_kernel pushdown
This is an ancient driver so just wrap it in lock_kernel internally and
be done.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/istallion.c
linux-2.6.25-rc2-mm1/drivers/char/istallion.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/istallion.c 2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/istallion.c 2008-02-20
11:45:50.0 +
@@ -4433,6 +4433,8 @@
done = 0;
rc = 0;
+ lock_kernel();
+
switch (cmd) {
case COM_GETPORTSTATS:
rc = stli_getportstats(NULL, argp);
@@ -4455,7 +4457,8 @@
done++;
break;
}
-
+ unlock_kernel();
+
if (done)
return rc;
@@ -4472,6 +4475,8 @@
if (brdp->state == 0)
return -ENODEV;
+ lock_kernel();
+
switch (cmd) {
case STL_BINTR:
EBRDINTR(brdp);
@@ -4494,6 +4499,7 @@
rc = -ENOIOCTLCMD;
break;
}
+ unlock_kernel();
return rc;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.25-rc2-mm1 - Kernel panic while bootup caused by signal_group_exit()
On Wed, 20 Feb 2008 14:34:17 -0500 Rik van Riel <[EMAIL PROTECTED]> wrote: > On Sun, 17 Feb 2008 09:40:33 +0530 > Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > > > [ 25.512919] BUG: unable to handle kernel paging request at 9d74e37b > > [ 25.514926] IP: [] proc_flush_task+0x5b/0x223 > > I wonder if this one is related. Also with 2.6.25-rc2-mm1 on x86_64: Probably - am testing some locking patches now -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] isicom: prepare for lock_kernel push down
Again lock the bits we can't trivially prove are safe without the BKL and
remove the broken TIOCS/GSOFTCAR handler.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/isicom.c
linux-2.6.25-rc2-mm1/drivers/char/isicom.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/isicom.c 2008-02-19
11:01:44.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/isicom.c 2008-02-20 11:45:50.0
+
@@ -1258,6 +1258,8 @@
if (copy_from_user(, info, sizeof(newinfo)))
return -EFAULT;
+ lock_kernel();
+
reconfig_port = ((port->flags & ASYNC_SPD_MASK) !=
(newinfo.flags & ASYNC_SPD_MASK));
@@ -1265,8 +1267,10 @@
if ((newinfo.close_delay != port->close_delay) ||
(newinfo.closing_wait != port->closing_wait) ||
((newinfo.flags & ~ASYNC_USR_MASK) !=
- (port->flags & ~ASYNC_USR_MASK)))
+ (port->flags & ~ASYNC_USR_MASK))) {
+ unlock_kernel();
return -EPERM;
+ }
port->flags = ((port->flags & ~ ASYNC_USR_MASK) |
(newinfo.flags & ASYNC_USR_MASK));
}
@@ -1282,6 +1286,7 @@
isicom_config_port(port);
spin_unlock_irqrestore(>card->card_lock, flags);
}
+ unlock_kernel();
return 0;
}
@@ -1290,6 +1295,7 @@
{
struct serial_struct out_info;
+ lock_kernel();
memset(_info, 0, sizeof(out_info));
/* out_info.type = ? */
out_info.line = port - isi_ports;
@@ -1299,6 +1305,7 @@
/* out_info.baud_base = ? */
out_info.close_delay = port->close_delay;
out_info.closing_wait = port->closing_wait;
+ unlock_kernel();
if (copy_to_user(info, _info, sizeof(out_info)))
return -EFAULT;
return 0;
@@ -1331,19 +1338,6 @@
tty_wait_until_sent(tty, 0);
isicom_send_break(port, arg ? arg * (HZ/10) : HZ/4);
return 0;
-
- case TIOCGSOFTCAR:
- return put_user(C_CLOCAL(tty) ? 1 : 0,
- (unsigned long __user *)argp);
-
- case TIOCSSOFTCAR:
- if (get_user(arg, (unsigned long __user *) argp))
- return -EFAULT;
- tty->termios->c_cflag =
- ((tty->termios->c_cflag & ~CLOCAL) |
- (arg ? CLOCAL : 0));
- return 0;
-
case TIOCGSERIAL:
return isicom_get_serial_info(port, argp);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] epca: lock_kernel push down
Prepare epca for removing the lock from above. Most of epca is internally
locked so we can trivially push it down to a few bits of code. Drop the
TIOCG/SSOFTCAR handling as that is done *properly* with locks by the mid layer.
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/epca.c
linux-2.6.25-rc2-mm1/drivers/char/epca.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/epca.c2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/epca.c2008-02-20 11:45:43.0
+
@@ -2206,21 +2206,6 @@
tty_wait_until_sent(tty, 0);
digi_send_break(ch, arg ? arg*(HZ/10) : HZ/4);
return 0;
- case TIOCGSOFTCAR:
- if (put_user(C_CLOCAL(tty)?1:0, (unsigned long __user *)arg))
- return -EFAULT;
- return 0;
- case TIOCSSOFTCAR:
- {
- unsigned int value;
-
- if (get_user(value, (unsigned __user *)argp))
- return -EFAULT;
- tty->termios->c_cflag =
- ((tty->termios->c_cflag & ~CLOCAL) |
-(value ? CLOCAL : 0));
- return 0;
- }
case TIOCMODG:
mflag = pc_tiocmget(tty, file);
if (put_user(mflag, (unsigned long __user *)argp))
@@ -2253,6 +2238,7 @@
break;
case DIGI_SETAW:
case DIGI_SETAF:
+ lock_kernel();
if (cmd == DIGI_SETAW) {
/* Setup an event to indicate when the transmit buffer
empties */
spin_lock_irqsave(_lock, flags);
@@ -2264,6 +2250,7 @@
if (tty->ldisc.flush_buffer)
tty->ldisc.flush_buffer(tty);
}
+ unlock_kernel();
/* Fall Thru */
case DIGI_SETA:
if (copy_from_user(>digiext, argp, sizeof(digi_t)))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] esp: lock_kernel push down
Push the BKL down into a few internal bits of code in this driver.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/esp.c
linux-2.6.25-rc2-mm1/drivers/char/esp.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/esp.c 2008-02-19
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/esp.c 2008-02-20 11:45:43.0
+
@@ -1355,6 +1355,7 @@
{
struct serial_struct tmp;
+ lock_kernel();
memset(, 0, sizeof(tmp));
tmp.type = PORT_16550A;
tmp.line = info->line;
@@ -1367,6 +1368,7 @@
tmp.closing_wait = info->closing_wait;
tmp.custom_divisor = info->custom_divisor;
tmp.hub6 = 0;
+ unlock_kernel();
if (copy_to_user(retinfo,,sizeof(*retinfo)))
return -EFAULT;
return 0;
@@ -1381,6 +1383,7 @@
return -EFAULT;
memset(, 0, sizeof(tmp));
+ lock_kernel();
tmp.rx_timeout = info->config.rx_timeout;
tmp.rx_trigger = info->config.rx_trigger;
tmp.tx_trigger = info->config.tx_trigger;
@@ -1388,7 +1391,8 @@
tmp.flow_on = info->config.flow_on;
tmp.pio_threshold = info->config.pio_threshold;
tmp.dma_channel = (info->stat_flags & ESP_STAT_NEVER_DMA ? 0 : dma);
-
+ unlock_kernel();
+
return copy_to_user(retinfo, , sizeof(*retinfo)) ? -EFAULT : 0;
}
@@ -1766,6 +1770,7 @@
struct serial_icounter_struct __user *p_cuser; /* user space */
void __user *argp = (void __user *)arg;
unsigned long flags;
+ int ret;
if (serial_paranoia_check(info, tty->name, "rs_ioctl"))
return -ENODEV;
@@ -1783,7 +1788,10 @@
case TIOCGSERIAL:
return get_serial_info(info, argp);
case TIOCSSERIAL:
- return set_serial_info(info, argp);
+ lock_kernel();
+ ret = set_serial_info(info, argp);
+ unlock_kernel();
+ return ret;
case TIOCSERCONFIG:
/* do not reconfigure after initial configuration */
return 0;
@@ -1855,11 +1863,13 @@
return -EFAULT;
return 0;
- case TIOCGHAYESESP:
- return get_esp_config(info, argp);
- case TIOCSHAYESESP:
- return set_esp_config(info, argp);
-
+ case TIOCGHAYESESP:
+ return get_esp_config(info, argp);
+ case TIOCSHAYESESP:
+ lock_kernel();
+ ret = set_esp_config(info, argp);
+ unlock_kernel();
+ return ret;
default:
return -ENOIOCTLCMD;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/37] Permit filesystem local caching
Serge E. Hallyn <[EMAIL PROTECTED]> wrote: > Seems *really* weird that every time you send this, patch 6 doesn't seem > to reach me in any of my mailboxes... (did get it from the url > you listed) It's the largest of the patches, so that's not entirely surprising. Hence why I included the URL to the tarball also. > I'm sorry if I miss where you explicitly state this, but is it safe to > assume, as perusing the patches suggests, that > > 1. tsk->sec never changes other than in task_alloc_security()? Correct. > 2. tsk->act_as is only ever dereferenced from (a) current-> That ought to be correct. > except (b) in do_coredump? Actually, do_coredump() only deals with current->act_as. > (thereby carefully avoiding locking issues) That's the idea. > I'd still like to see some performance numbers. Not to object to > these patches, just to make sure there's no need to try and optimize > more of the dereferences away when they're not needed. I hope that the performance impact is minimal. The kernel should spend very little time looking at the security data. I'll try and get some though. > Oh, manually copied from patch 6, I see you have in the task_security > struct definition: > > kernel_cap_tcap_bset; /* ? */ > > That comment can be filled in with 'capability bounding set' (for this > task and all its future descendents). Thanks. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] lguest: fix undefined asm-offsets symbols
lguest uses asm-offsets to generate ... offsets, obviously, for use in the lguest switcher code. When the hypervisor code is built as a module though, the asm offsets it needs won't be generated since CONFIG_LGUEST will be undefined. Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> --- diff --git a/arch/x86/kernel/asm-offsets_32.c b/arch/x86/kernel/asm-offsets_32.c index a33d530..44bafdd 100644 --- a/arch/x86/kernel/asm-offsets_32.c +++ b/arch/x86/kernel/asm-offsets_32.c @@ -134,7 +134,7 @@ void foo(void) OFFSET(LGUEST_DATA_pgdir, lguest_data, pgdir); #endif -#ifdef CONFIG_LGUEST +#if defined(CONFIG_LGUEST) || defined(CONFIG_LGUEST_MODULE) BLANK(); OFFSET(LGUEST_PAGES_host_gdt_desc, lguest_pages, state.host_gdt_desc); OFFSET(LGUEST_PAGES_host_idt_desc, lguest_pages, state.host_idt_desc); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cyclades: Prepare for relaxed locking in callers
Basically wrap it in lock_kernel where it is hard to prove the locking is
ok.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/cyclades.c
linux-2.6.25-rc2-mm1/drivers/char/cyclades.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/cyclades.c2008-02-19
11:01:43.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/cyclades.c2008-02-20
11:45:28.0 +
@@ -3464,6 +3464,8 @@
if (serial_paranoia_check(info, tty->name, __FUNCTION__))
return -ENODEV;
+ lock_kernel();
+
card = info->card;
channel = info->line - card->first_line;
if (!IS_CYC_Z(*card)) {
@@ -3506,10 +3508,12 @@
((lstatus & C_RS_CTS) ? TIOCM_CTS : 0);
} else {
result = 0;
+ unlock_kernel();
return -ENODEV;
}
}
+ unlock_kernel();
return result;
} /* cy_tiomget */
@@ -3880,6 +3884,7 @@
printk(KERN_DEBUG "cyc:cy_ioctl ttyC%d, cmd = %x arg = %lx\n",
info->line, cmd, arg);
#endif
+ lock_kernel();
switch (cmd) {
case CYGETMON:
@@ -3988,47 +3993,47 @@
p_cuser = argp;
ret_val = put_user(cnow.cts, _cuser->cts);
if (ret_val)
- return ret_val;
+ break;
ret_val = put_user(cnow.dsr, _cuser->dsr);
if (ret_val)
- return ret_val;
+ break;
ret_val = put_user(cnow.rng, _cuser->rng);
if (ret_val)
- return ret_val;
+ break;
ret_val = put_user(cnow.dcd, _cuser->dcd);
if (ret_val)
- return ret_val;
+ break;
ret_val = put_user(cnow.rx, _cuser->rx);
if (ret_val)
- return ret_val;
+ break;
ret_val = put_user(cnow.tx, _cuser->tx);
if (ret_val)
- return ret_val;
+ break;
ret_val = put_user(cnow.frame, _cuser->frame);
if (ret_val)
- return ret_val;
+ break;
ret_val = put_user(cnow.overrun, _cuser->overrun);
if (ret_val)
- return ret_val;
+ break;
ret_val = put_user(cnow.parity, _cuser->parity);
if (ret_val)
- return ret_val;
+ break;
ret_val = put_user(cnow.brk, _cuser->brk);
if (ret_val)
- return ret_val;
+ break;
ret_val = put_user(cnow.buf_overrun, _cuser->buf_overrun);
if (ret_val)
- return ret_val;
+ break;
ret_val = 0;
break;
default:
ret_val = -ENOIOCTLCMD;
}
+ unlock_kernel();
#ifdef CY_DEBUG_OTHER
printk(KERN_DEBUG "cyc:cy_ioctl done\n");
#endif
-
return ret_val;
} /* cy_ioctl */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ide: remove IDE_HFLAG_CY82C693 host flag
Sergei suggested that it shouldn't be necessary + it had no effect
anyway since ide_id_dma_bug() is called earlier in ide_tune_dma().
Cc: Sergei Shtylyov <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
I went ahead since I urgently needed to re-cycle one host flag.
drivers/ide/ide-dma.c | 10 ++
drivers/ide/pci/cy82c693.c |2 +-
include/linux/ide.h|2 --
3 files changed, 3 insertions(+), 11 deletions(-)
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -747,14 +747,8 @@ static int ide_tune_dma(ide_drive_t *dri
speed = ide_max_dma_mode(drive);
- if (!speed) {
-/* is this really correct/needed? */
- if ((hwif->host_flags & IDE_HFLAG_CY82C693) &&
- ide_dma_good_drive(drive))
- return 1;
- else
- return 0;
- }
+ if (!speed)
+ return 0;
if (hwif->host_flags & IDE_HFLAG_NO_SET_MODE)
return 1;
Index: b/drivers/ide/pci/cy82c693.c
===
--- a/drivers/ide/pci/cy82c693.c
+++ b/drivers/ide/pci/cy82c693.c
@@ -410,7 +410,7 @@ static const struct ide_port_info cy82c6
.init_iops = init_iops_cy82c693,
.init_hwif = init_hwif_cy82c693,
.chipset= ide_cy82c693,
- .host_flags = IDE_HFLAG_SINGLE | IDE_HFLAG_CY82C693,
+ .host_flags = IDE_HFLAG_SINGLE,
.pio_mask = ATA_PIO4,
.swdma_mask = ATA_SWDMA2,
.mwdma_mask = ATA_MWDMA2,
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1089,8 +1089,6 @@ enum {
/* unmask IRQs */
IDE_HFLAG_UNMASK_IRQS = (1 << 25),
IDE_HFLAG_ABUSE_SET_DMA_MODE= (1 << 26),
- /* host is CY82C693 */
- IDE_HFLAG_CY82C693 = (1 << 27),
/* force host out of "simplex" mode */
IDE_HFLAG_CLEAR_SIMPLEX = (1 << 28),
/* DSC overlap is unsupported */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] amiserial: Prepare for locking relaxation in caller.
Just wrap this one in a lock_kernel. As I understand it there is no M68K
SMP anyway.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/amiserial.c
linux-2.6.25-rc2-mm1/drivers/char/amiserial.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/amiserial.c 2008-02-19
11:01:44.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/amiserial.c 2008-02-20
11:45:28.0 +
@@ -1074,6 +1074,7 @@
if (!retinfo)
return -EFAULT;
memset(, 0, sizeof(tmp));
+ lock_kernel();
tmp.type = state->type;
tmp.line = state->line;
tmp.port = state->port;
@@ -1084,6 +1085,7 @@
tmp.close_delay = state->close_delay;
tmp.closing_wait = state->closing_wait;
tmp.custom_divisor = state->custom_divisor;
+ unlock_kernel();
if (copy_to_user(retinfo,,sizeof(*retinfo)))
return -EFAULT;
return 0;
@@ -1099,13 +1101,17 @@
if (copy_from_user(_serial,new_info,sizeof(new_serial)))
return -EFAULT;
+
+ lock_kernel();
state = info->state;
old_state = *state;
change_irq = new_serial.irq != state->irq;
change_port = (new_serial.port != state->port);
- if(change_irq || change_port || (new_serial.xmit_fifo_size !=
state->xmit_fifo_size))
+ if(change_irq || change_port || (new_serial.xmit_fifo_size !=
state->xmit_fifo_size)) {
+ unlock_kernel();
return -EINVAL;
+ }
if (!serial_isroot()) {
if ((new_serial.baud_base != state->baud_base) ||
@@ -1122,8 +1128,10 @@
goto check_and_exit;
}
- if (new_serial.baud_base < 9600)
+ if (new_serial.baud_base < 9600) {
+ unlock_kernel();
return -EINVAL;
+ }
/*
* OK, past this point, all the error checking has been done.
@@ -1157,6 +1165,7 @@
}
} else
retval = startup(info);
+ unlock_kernel();
return retval;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ide: fix enabling DMA on it821x in "smart" mode
ide_tune_dma() should return '1' if IDE_HFLAG_NO_SET_MODE host flag is set. Cc: Sergei Shtylyov <[EMAIL PROTECTED]> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- I wonder how this could have slipped in :( Sergei, please double-check this patch. Thanks! drivers/ide/ide-dma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/drivers/ide/ide-dma.c === --- a/drivers/ide/ide-dma.c +++ b/drivers/ide/ide-dma.c @@ -757,7 +757,7 @@ static int ide_tune_dma(ide_drive_t *dri } if (hwif->host_flags & IDE_HFLAG_NO_SET_MODE) - return 0; + return 1; if (ide_set_dma_mode(drive, speed)) return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Wednesday, 20 of February 2008, Jesse Barnes wrote:
> On Wednesday, February 20, 2008 11:18 am Jesse Barnes wrote:
> > On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > > On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > > > > So, next I'll try "shutdown" to see if it work. I was using
> > > > > "platform".
> > > >
> > > > Ok, that would be good to try.
> > >
> > > "shutdown" does power down properly. But still green on resume.
> >
> > Ok, so Linus' theory about something later in the resume path trying to
> > touch video is looking good.
> >
> > Rafael, is there anyway to prevent the device shutdown in the hibernate
> > path?
>
> Given the way the PM core works, do we need to set a flag like this? I
> really
> hope there's a better way of doing this...
I think we should export the target sleep state somehow.
> diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
> index 4048f39..a2d6242 100644
> --- a/drivers/char/drm/i915_drv.c
> +++ b/drivers/char/drm/i915_drv.c
> @@ -238,6 +238,13 @@ static void i915_restore_vga(struct drm_device *dev)
>
> }
>
> +/*
> + * If we're doing a suspend to disk, we don't want to power off the device.
> + * Unfortunately, the PM core doesn't tell us if we're headed for a regular
> + * S3 state or that it's about to shut down the machine, so we use this flag.
> + */
> +static int i915_hibernate;
> +
> static int i915_suspend(struct drm_device *dev, pm_message_t state)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -252,6 +259,9 @@ static int i915_suspend(struct drm_device *dev,
> pm_message_t state)
> if (state.event == PM_EVENT_PRETHAW)
> return 0;
>
> + if (state.event == PM_EVENT_FREEZE)
> + i915_hibernate = 1;
> +
> pci_save_state(dev->pdev);
> pci_read_config_byte(dev->pdev, LBB, _priv->saveLBB);
>
> @@ -366,7 +376,7 @@ static int i915_suspend(struct drm_device *dev,
> pm_message_t state)
>
> i915_save_vga(dev);
>
> - if (state.event == PM_EVENT_SUSPEND) {
> + if (!i915_hibernate) {
> /* Shut down the device */
> pci_disable_device(dev->pdev);
> pci_set_power_state(dev->pdev, PCI_D3hot);
> @@ -385,6 +395,8 @@ static int i915_resume(struct drm_device *dev)
> if (pci_enable_device(dev->pdev))
> return -1;
>
> + i915_hibernate = 0;
> +
> pci_write_config_byte(dev->pdev, LBB, dev_priv->saveLBB);
>
> /* Pipe & plane A info */
Then, the .resume() called after the image creation will clear the flag and I
don't think it's safe to allow it to survive i915_resume() ...
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] nfs: fix sparse warnings in callback_xdr.c
fs/nfs/callback_xdr.c:257:6: warning: Using plain integer as NULL pointer fs/nfs/callback_xdr.c:270:6: warning: Using plain integer as NULL pointer fs/nfs/callback_xdr.c:281:6: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- fs/nfs/callback_xdr.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/nfs/callback_xdr.c b/fs/nfs/callback_xdr.c index c63eb72..13619d2 100644 --- a/fs/nfs/callback_xdr.c +++ b/fs/nfs/callback_xdr.c @@ -254,7 +254,7 @@ static __be32 encode_attr_change(struct xdr_stream *xdr, const uint32_t *bitmap, if (!(bitmap[0] & FATTR4_WORD0_CHANGE)) return 0; p = xdr_reserve_space(xdr, 8); - if (unlikely(p == 0)) + if (unlikely(!p)) return htonl(NFS4ERR_RESOURCE); p = xdr_encode_hyper(p, change); return 0; @@ -267,7 +267,7 @@ static __be32 encode_attr_size(struct xdr_stream *xdr, const uint32_t *bitmap, u if (!(bitmap[0] & FATTR4_WORD0_SIZE)) return 0; p = xdr_reserve_space(xdr, 8); - if (unlikely(p == 0)) + if (unlikely(!p)) return htonl(NFS4ERR_RESOURCE); p = xdr_encode_hyper(p, size); return 0; @@ -278,7 +278,7 @@ static __be32 encode_attr_time(struct xdr_stream *xdr, const struct timespec *ti __be32 *p; p = xdr_reserve_space(xdr, 12); - if (unlikely(p == 0)) + if (unlikely(!p)) return htonl(NFS4ERR_RESOURCE); p = xdr_encode_hyper(p, time->tv_sec); *p = htonl(time->tv_nsec); -- 1.5.4.2.200.g99e75 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] documentation: fix firmware_sample_firmware_class to build
Greg KH wrote: On Mon, Feb 18, 2008 at 04:22:16PM -0800, Randy Dunlap wrote: From: Randy Dunlap <[EMAIL PROTECTED]> Fix firmware_sample_firmware_class module to build without error. sysfs.h already has the function prototypes and has them correctly. Documentation/firmware_class/firmware_sample_firmware_class.c:37: error: conflicting types for 'sysfs_remove_bin_file' include/linux/sysfs.h:100: error: previous declaration of 'sysfs_remove_bin_file' was here Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- Documentation/firmware_class/firmware_sample_firmware_class.c |3 --- 1 file changed, 3 deletions(-) Can we move this file to the samples/ directory, so the build will catch stuff like this? What's the final version of this patch? I've moved it to samples/, but it (still) has a build problem: ERROR: "firmware_class" [samples/firmware_class/firmware_sample_firmware_class.ko] undefined! Can you give me hint(s) about how to fix that? -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-kernel] Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver
Actually, disparaging things as "one idiotic system" doesn't seem like a long-term thoughtful process - it's not even accurate. There are more such systems that are running code today than the total number of 486 systems ever manufactured. The production rate is $1M/month. a) ENE chips are "documented" to receive port 80, and also it is the case that modern chipsets will happily diagnose writes to non-existent ports as MCE's. Using side effects that depend on non-existent ports just creates a brittle failure mode down the road. And it's not just post ACPI "initialization". The pcspkr use of port 80 caused solid freezes if you typed "tab" to complete a command line and there were more than one choice, leading to beeps. b) sad to say, Linux is not what hardware vendors use as the system that their BIOSes MUST work with. That's Windows, and Windows, whether we like it or not does not require hardware vendors to stay away from port 80. IMHO, calling something "idiotic" is hardly evidence-based decision making. Maybe you love to hate Microsoft, but until Intel writes an architecture standard that says explicitly that a "standard PC" must not use port 80 for any peripheral, the port 80 thing is folklore, and one that is solely Linux-defined. Rene Herman wrote: On 20-02-08 18:05, H. Peter Anvin wrote: Rene Herman wrote: _Something_ like this would seem to be the only remaining option. It seems fairly unuseful to #ifdef around that switch statement for kernels without support for the earlier families, but if you insist... "Only remaining option" other than the one we've had all along. Even on the one idiotic set of systems which break, it only breaks post-ACPI intialization, IIRC. Linus vetoed the DMI switch. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] nfs: fix sparse warning in idmap.c
fs/nfs/idmap.c:312:12: warning: Using plain integer as NULL pointer
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/nfs/idmap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfs/idmap.c b/fs/nfs/idmap.c
index 8ae5dba..86147b0 100644
--- a/fs/nfs/idmap.c
+++ b/fs/nfs/idmap.c
@@ -309,7 +309,7 @@ nfs_idmap_name(struct idmap *idmap, struct idmap_hashtable
*h,
mutex_lock(>idmap_im_lock);
he = idmap_lookup_id(h, id);
- if (he != 0) {
+ if (he) {
memcpy(name, he->ih_name, he->ih_namelen);
ret = he->ih_namelen;
goto out;
--
1.5.4.2.200.g99e75
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] firewire: fix NULL pointer deref. and resource leak
By supplying ioctl()s in the wrong order, a userspace client was able to
trigger NULL pointer dereferences. Furthermore, by calling
ioctl_create_iso_context more than once, new contexts could be created
without ever freeing the previously created contexts.
Thanks to Anders Blomdell for the report.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/firewire/fw-cdev.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux/drivers/firewire/fw-cdev.c
===
--- linux.orig/drivers/firewire/fw-cdev.c
+++ linux/drivers/firewire/fw-cdev.c
@@ -646,6 +646,10 @@ static int ioctl_create_iso_context(stru
struct fw_cdev_create_iso_context *request = buffer;
struct fw_iso_context *context;
+ /* We only support one context at this time. */
+ if (client->iso_context != NULL)
+ return -EBUSY;
+
if (request->channel > 63)
return -EINVAL;
@@ -792,8 +796,9 @@ static int ioctl_start_iso(struct client
{
struct fw_cdev_start_iso *request = buffer;
- if (request->handle != 0)
+ if (client->iso_context == NULL || request->handle != 0)
return -EINVAL;
+
if (client->iso_context->type == FW_ISO_CONTEXT_RECEIVE) {
if (request->tags == 0 || request->tags > 15)
return -EINVAL;
@@ -810,7 +815,7 @@ static int ioctl_stop_iso(struct client
{
struct fw_cdev_stop_iso *request = buffer;
- if (request->handle != 0)
+ if (client->iso_context == NULL || request->handle != 0)
return -EINVAL;
return fw_iso_context_stop(client->iso_context);
--
Stefan Richter
-=-==--- --=- =-=--
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] nfs: fix sparse warning in delegation.c
fs/nfs/delegation.c:52:34: warning: Using plain integer as NULL pointer
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/nfs/delegation.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index b9eadd1..00a5e44 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -49,7 +49,7 @@ static int nfs_delegation_claim_locks(struct nfs_open_context
*ctx, struct nfs4_
struct file_lock *fl;
int status;
- for (fl = inode->i_flock; fl != 0; fl = fl->fl_next) {
+ for (fl = inode->i_flock; fl != NULL; fl = fl->fl_next) {
if (!(fl->fl_flags & (FL_POSIX|FL_FLOCK)))
continue;
if (nfs_file_open_context(fl->fl_file) != ctx)
--
1.5.4.2.200.g99e75
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Wednesday, February 20, 2008 11:18 am Jesse Barnes wrote:
> On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > > > So, next I'll try "shutdown" to see if it work. I was using
> > > > "platform".
> > >
> > > Ok, that would be good to try.
> >
> > "shutdown" does power down properly. But still green on resume.
>
> Ok, so Linus' theory about something later in the resume path trying to
> touch video is looking good.
>
> Rafael, is there anyway to prevent the device shutdown in the hibernate
> path?
Given the way the PM core works, do we need to set a flag like this? I really
hope there's a better way of doing this...
Thanks,
Jesse
diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index 4048f39..a2d6242 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -238,6 +238,13 @@ static void i915_restore_vga(struct drm_device *dev)
}
+/*
+ * If we're doing a suspend to disk, we don't want to power off the device.
+ * Unfortunately, the PM core doesn't tell us if we're headed for a regular
+ * S3 state or that it's about to shut down the machine, so we use this flag.
+ */
+static int i915_hibernate;
+
static int i915_suspend(struct drm_device *dev, pm_message_t state)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -252,6 +259,9 @@ static int i915_suspend(struct drm_device *dev,
pm_message_t state)
if (state.event == PM_EVENT_PRETHAW)
return 0;
+ if (state.event == PM_EVENT_FREEZE)
+ i915_hibernate = 1;
+
pci_save_state(dev->pdev);
pci_read_config_byte(dev->pdev, LBB, _priv->saveLBB);
@@ -366,7 +376,7 @@ static int i915_suspend(struct drm_device *dev,
pm_message_t state)
i915_save_vga(dev);
- if (state.event == PM_EVENT_SUSPEND) {
+ if (!i915_hibernate) {
/* Shut down the device */
pci_disable_device(dev->pdev);
pci_set_power_state(dev->pdev, PCI_D3hot);
@@ -385,6 +395,8 @@ static int i915_resume(struct drm_device *dev)
if (pci_enable_device(dev->pdev))
return -1;
+ i915_hibernate = 0;
+
pci_write_config_byte(dev->pdev, LBB, dev_priv->saveLBB);
/* Pipe & plane A info */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] nfs: fix sparse warning in nfs4state.c
fs/nfs/nfs4state.c:788:34: warning: Using plain integer as NULL pointer
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
fs/nfs/nfs4state.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 6233eb5..b962397 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -785,7 +785,7 @@ static int nfs4_reclaim_locks(struct
nfs4_state_recovery_ops *ops, struct nfs4_s
struct file_lock *fl;
int status = 0;
- for (fl = inode->i_flock; fl != 0; fl = fl->fl_next) {
+ for (fl = inode->i_flock; fl != NULL; fl = fl->fl_next) {
if (!(fl->fl_flags & (FL_POSIX|FL_FLOCK)))
continue;
if (nfs_file_open_context(fl->fl_file)->state != state)
--
1.5.4.2.200.g99e75
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.25-rc2-mm1 - Kernel panic while bootup caused by signal_group_exit()
On 02/20, Rik van Riel wrote: > > On Sun, 17 Feb 2008 09:40:33 +0530 > Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > > > [ 25.512919] BUG: unable to handle kernel paging request at 9d74e37b > > [ 25.514926] IP: [] proc_flush_task+0x5b/0x223 > > I wonder if this one is related. Also with 2.6.25-rc2-mm1 on x86_64: > > BUG: unable to handle kernel paging request at 00200200 > IP: [] free_pid+0x35/0x90 > ... > Call Trace: > [] ? release_task+0x1be/0x346 > [] ? do_wait+0x6c2/0xa0e > [] ? trace_hardirqs_on_caller+0xf2/0x115 > [] ? default_wake_function+0x0/0xe > [] ? trace_hardirqs_on_caller+0xf2/0x115 > [] ? sys_wait4+0x8a/0xa1 > [] ? system_call_after_swapgs+0x7b/0x80 Yes, please look at http://marc.info/?t=12030984056 Btw. The bug in tty_io.c _can_ explain this trace, but it would be nice to ensure we don't have other problems. Could you try this http://marc.info/?l=linux-kernel=120352655031911 patch? (I can't understand why this happens at the boot time, and it is not reproducable on my side). Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] (linus git 02/19/08) Smack update for file capabilities
--- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > Quoting Casey Schaufler ([EMAIL PROTECTED]): > > From: Casey Schaufler <[EMAIL PROTECTED]> > > > > Update the Smack LSM to allow the registration of the capability > > "module" as a secondary LSM. Integrate the new hooks required for > > file based capabilities. > > Hi Casey, > > to help people keep their mailboxes straight it'd be good to have a > changelog here pointing out that you addressed Stephen's point. Thanks for the reminder. > Looks good to me. It's too bad the logic has to be quite so convoluted > between the two, but I'm not sure it can be improved upon... It's not so bad. > And thanks Stephen, I well might have missed the issue you pointed out. Indeed. The careful review is much appreciated. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/37] Permit filesystem local caching
Quoting David Howells ([EMAIL PROTECTED]): > > > These patches add local caching for network filesystems such as NFS. > > The patches can roughly be broken down into a number of sets: > > (*) 01-keys-inc-payload.diff > (*) 02-keys-search-keyring.diff > (*) 03-keys-callout-blob.diff > > Three patches to the keyring code made to help the CIFS people. > Included because of patches 05-08. > > (*) 04-keys-get-label.diff > > A patch to allow the security label of a key to be retrieved. > Included because of patches 05-08. > > (*) 05-security-current-fsugid.diff > (*) 06-security-separate-task-bits.diff Seems *really* weird that every time you send this, patch 6 doesn't seem to reach me in any of my mailboxes... (did get it from the url you listed) I'm sorry if I miss where you explicitly state this, but is it safe to assume, as perusing the patches suggests, that 1. tsk->sec never changes other than in task_alloc_security()? 2. tsk->act_as is only ever dereferenced from (a) current-> except (b) in do_coredump? (thereby carefully avoiding locking issues) I'd still like to see some performance numbers. Not to object to these patches, just to make sure there's no need to try and optimize more of the dereferences away when they're not needed. Oh, manually copied from patch 6, I see you have in the task_security struct definition: kernel_cap_tcap_bset; /* ? */ That comment can be filled in with 'capability bounding set' (for this task and all its future descendents). thanks, -serge > (*) 07-security-subjective.diff > (*) 08-security-kernel_service-class.diff > (*) 09-security-kernel-service.diff > (*) 10-security-nfsd.diff > > Patches to permit the subjective security of a task to be overridden. > All the security details in task_struct are decanted into a new struct > that task_struct then has two pointers two: one that defines the > objective security of that task (how other tasks may affect it) and one > that defines the subjective security (how it may affect other objects). > > Note that I have dropped the idea of struct cred for the moment. With > the amount of stuff that was excluded from it, it wasn't actually any > use to me. However, it can be added later. > > Required for cachefiles. > > (*) 11-release-page.diff > (*) 12-fscache-page-flags.diff > (*) 13-add_wait_queue_tail.diff > (*) 14-fscache.diff > > Patches to provide a local caching facility for network filesystems. > > (*) 15-cachefiles-ia64.diff > (*) 16-cachefiles-ext3-f_mapping.diff > (*) 17-cachefiles-write.diff > (*) 18-cachefiles-monitor.diff > (*) 19-cachefiles-export.diff > (*) 20-cachefiles.diff > > Patches to provide a local cache in a directory of an already mounted > filesystem. > > (*) 21-nfs-comment.diff > (*) 22-nfs-fscache-option.diff > (*) 23-nfs-fscache-kconfig.diff > (*) 24-nfs-fscache-top-index.diff > (*) 25-nfs-fscache-server-obj.diff > (*) 26-nfs-fscache-super-obj.diff > (*) 27-nfs-fscache-inode-obj.diff > (*) 28-nfs-fscache-use-inode.diff > (*) 29-nfs-fscache-invalidate-pages.diff > (*) 30-nfs-fscache-iostats.diff > (*) 31-nfs-fscache-page-management.diff > (*) 32-nfs-fscache-read-context.diff > (*) 33-nfs-fscache-read-fallback.diff > (*) 34-nfs-fscache-read-from-cache.diff > (*) 35-nfs-fscache-store-to-cache.diff > (*) 36-nfs-fscache-mount.diff > (*) 37-nfs-fscache-display.diff > > Patches to provide NFS with local caching. > > A couple of questions on the NFS iostat changes: (1) Should I update the > iostat version number; (2) is it permitted to have conditional iostats? > > > I've brought the patchset up to date with respect to the 2.6.25-rc1 merge > window, in particular altering Smack to handle the split in objective and > subjective security in the task_struct. > > -- > A tarball of the patches is available at: > > > http://people.redhat.com/~dhowells/fscache/patches/nfs+fscache-30.tar.bz2 > > > To use this version of CacheFiles, the cachefilesd-0.9 is also required. It > is available as an SRPM: > > http://people.redhat.com/~dhowells/fscache/cachefilesd-0.9-1.fc7.src.rpm > > Or as individual bits: > > http://people.redhat.com/~dhowells/fscache/cachefilesd-0.9.tar.bz2 > http://people.redhat.com/~dhowells/fscache/cachefilesd.fc > http://people.redhat.com/~dhowells/fscache/cachefilesd.if > http://people.redhat.com/~dhowells/fscache/cachefilesd.te > http://people.redhat.com/~dhowells/fscache/cachefilesd.spec > > The .fc, .if and .te files are for manipulating SELinux. > > David > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send
Re: [PATCH] falconide: fix resources reservation
On Wednesday 20 February 2008, Geert Uytterhoeven wrote:
> On Wed, 20 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
> > * Tell IDE layer to not manage resources by setting
> > hwif->mmio flag and request resources in falconide_init().
> >
> > * Use request_mem_region() for resources reservation.
> >
> > * Use driver name for resources reservation.
> >
> > Cc: Geert Uytterhoeven <[EMAIL PROTECTED]>
> > Cc: Michael Schmitz <[EMAIL PROTECTED]>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> > ---
> > drivers/ide/legacy/falconide.c |7 +++
> > 1 file changed, 7 insertions(+)
> >
> > Index: b/drivers/ide/legacy/falconide.c
> > ===
> > --- a/drivers/ide/legacy/falconide.c
> > +++ b/drivers/ide/legacy/falconide.c
> > @@ -22,6 +22,7 @@
> > #include
> > #include
> >
> > +#define DRV_NAME "falconide"
> >
> > /*
> > * Base of the IDE interface
> > @@ -74,6 +75,11 @@ static int __init falconide_init(void)
> >
> > printk(KERN_INFO "ide: Falcon IDE controller\n");
> >
> > + if (!request_mem_region(ATA_HD_BASE, 0x40, DRV_NAME)) {
> > + printk(KERN_ERR "%s: resources busy\n");
> ^^
> Woops, missing parameter?
thanks, fixed
> pr_error()?
dunno...
From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Subject: [PATCH] falconide: fix resources reservation (take 2)
* Tell IDE layer to not manage resources by setting
hwif->mmio flag and request resources in falconide_init().
* Use request_mem_region() for resources reservation.
* Use driver name for resources reservation.
v2:
* Fix missing printk() parameter. (Noticed by Geert Uytterhoeven)
Cc: Geert Uytterhoeven <[EMAIL PROTECTED]>
Cc: Michael Schmitz <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/legacy/falconide.c |7 +++
1 file changed, 7 insertions(+)
Index: b/drivers/ide/legacy/falconide.c
===
--- a/drivers/ide/legacy/falconide.c
+++ b/drivers/ide/legacy/falconide.c
@@ -22,6 +22,7 @@
#include
#include
+#define DRV_NAME "falconide"
/*
* Base of the IDE interface
@@ -74,6 +75,11 @@ static int __init falconide_init(void)
printk(KERN_INFO "ide: Falcon IDE controller\n");
+ if (!request_mem_region(ATA_HD_BASE, 0x40, DRV_NAME)) {
+ printk(KERN_ERR "%s: resources busy\n", DRV_NAME);
+ return -EBUSY;
+ }
+
falconide_setup_ports();
hwif = ide_find_port();
@@ -83,6 +89,7 @@ static int __init falconide_init(void)
ide_init_port_data(hwif, index);
ide_init_port_hw(hwif, );
+ hwif->mmio = 1;
ide_get_lock(NULL, NULL);
ide_device_add(idx, NULL);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2/3] mn10300: cleanup - drop .data.idt section in vmlinux.lds script
The section .data.idt is not used at all - so drop it.
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
vmlinux.lds.S |3 ---
1 file changed, 3 deletions(-)
Index: linux-2.6.git/arch/mn10300/kernel/vmlinux.lds.S
===
--- linux-2.6.git.orig/arch/mn10300/kernel/vmlinux.lds.S2008-02-10
10:46:37.0 +0300
+++ linux-2.6.git/arch/mn10300/kernel/vmlinux.lds.S 2008-02-20
22:26:01.0 +0300
@@ -61,9 +61,6 @@ SECTIONS
. = ALIGN(4096);
__nosave_end = .;
- . = ALIGN(4096);
- .data.page_aligned : { *(.data.idt) }
-
. = ALIGN(32);
.data.cacheline_aligned : { *(.data.cacheline_aligned) }
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 3/3] s390: cleanup - drop .data.idt section in vmlinux.lds script
The section .data.idt is not used at all - so drop it.
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
vmlinux.lds.S |5 -
1 file changed, 5 deletions(-)
Index: linux-2.6.git/arch/s390/kernel/vmlinux.lds.S
===
--- linux-2.6.git.orig/arch/s390/kernel/vmlinux.lds.S 2008-02-06
23:15:14.0 +0300
+++ linux-2.6.git/arch/s390/kernel/vmlinux.lds.S2008-02-20
22:30:30.0 +0300
@@ -71,11 +71,6 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__nosave_end = .;
- . = ALIGN(PAGE_SIZE);
- .data.page_aligned : {
- *(.data.idt)
- }
-
. = ALIGN(0x100);
.data.cacheline_aligned : {
*(.data.cacheline_aligned)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 0/3] eliminate .data.idt section for the archs which do not use it
This patch series do a small clean up over vmlinux.lds script for several architectures where the section .data.idt is not used. Please review. Thanks. - Cyrill - -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/3] m32r: cleanup - drop .data.idt section in vmlinux.lds script
The section .data.idt is not used at all - so drop it.
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
vmlinux.lds.S |3 ---
1 file changed, 3 deletions(-)
Index: linux-2.6.git/arch/m32r/kernel/vmlinux.lds.S
===
--- linux-2.6.git.orig/arch/m32r/kernel/vmlinux.lds.S 2008-02-10
10:46:37.0 +0300
+++ linux-2.6.git/arch/m32r/kernel/vmlinux.lds.S2008-02-20
22:23:46.0 +0300
@@ -60,9 +60,6 @@ SECTIONS
. = ALIGN(4096);
__nosave_end = .;
- . = ALIGN(4096);
- .data.page_aligned : { *(.data.idt) }
-
. = ALIGN(32);
.data.cacheline_aligned : { *(.data.cacheline_aligned) }
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Tasklets: Avoid duplicating __tasklet_{,hi_}schedule() code
On Wed, Feb 20, 2008 at 03:20:52PM +0100, Dmitry Adamushko wrote: > On 20/02/2008, Ahmed S. Darwish <[EMAIL PROTECTED]> wrote: > > On Wed, Feb 20, 2008 at 11:41:13AM +0100, Ingo Molnar wrote: > > > > > > * Ahmed S. Darwish <[EMAIL PROTECTED]> wrote: > > > > > > > > > - local_irq_disable(); > > > > > > - t->next = __get_cpu_var(tasklet_vec).list; > > > > > > - __get_cpu_var(tasklet_vec).list = t; > > > > > > - __raise_softirq_irqoff(TASKLET_SOFTIRQ); > > > > > > - local_irq_enable(); > > > > > > + /* We were not lucky enough to run, reschedule. */ > > > > > > + __tasklet_schedule(t); > > > > > > > > > > i think there's a subtle difference that you missed: this one does > > > > > __raise_softirq_irqoff(), while __tasklet_schedule() does a > > > > > raise_softirq_irqoff(). (note the lack of undescores) > > > > > > > > > > the reason is to avoid infinitely self-activating tasklets. > > > > > > > > Indeed, thanks a lot for the explanation. (maybe it's time to check > > > > for new eyeglasses ;)). > > > > > > nah, it's rather subtle and the code looked good to me at first but i > > > remembered that there was some small detail here to watch out for. > > > > > > i really dont like tasklets due to their many, arbitrary scheduling > > > limitations, we should really use the "turn tasklets into kthreads" > > > patch i posted last year. > > > > > > > While we are at it, there's a small question that is bothering me > > for a while (and I'm really thankful for help). > > > > I keep reading that softirqs (and naturally, tasklets) got executed > > in interrupt context at the return from hardirq code path. > > > > Checking entry_32.S, I find no mentioning of softirqs on the return > > path (beginning from ret_from_intr: to restore_all: ) > > > > The only invocation I'm able to find is from local_bh_enable() and > > from ksoftirqd/n threads (by calling do_softirq()). AFAIK, both > > invocations occur in a _nont-interrupt_ context (exception context). > > > > So, where does the interrupt-context tasklets invocation really > > occur ? > > Look at irq_exit() in softirq.c. > > The common sequence is ... -> do_IRQ() --> irq_exit() --> invoke_softirq() > > Great, this was the last missing block in my understanding of softirqs :). Thank you. [btw, your MUA broke the CC list] -- Ahmed S. Darwish Homepage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] Fix b43 driver build for arm
On Wed, Feb 20, 2008 at 03:44:04PM +0100, Michael Buesch wrote: > On Wednesday 20 February 2008 01:44:38 Gordon Farquharson wrote: > > Hi Michael > > > > On Feb 19, 2008 3:41 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > > > [2] > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7492d4a416d68ab4bd254b36ffcc4e0138daa8ff > > > > > > > > > > That doesn't cause me to magically sign off this sort of patches, too. > > > The sanity check is clearly broken in file2alias.c, as it checks something > > > from the target kernel against the host environment it is compiled on. > > > That doesn't make any sense at all. > > > > I think that you make some good points, but I'm at a loss as to how to > > fix the problem. Do you have any suggestions? > > Remove the broken sanity check, if it's not possible the check there. The check is valid for > 99% of the kernel builds as cross compile builds are not that typical. And the check is there for the sake of modutils. The details I do not remember. So we have a few possiblities: 1) Remove the consistency check and try to deal with the rare cases where it fails and spend many hours investigating before we realise it is difference in layout of data. 2) Pad a few structures with a few bytes so this consitency check works even in cross build environments. 3) Detect that we are doing cross builds and skip the check in this case. Option 1) is the worst of the three as that can cost of many hours bug-hunting. Option 3) may seem optimal but I do not like to add more complexity to this part of the build. And really I do not know a reliable way to detech when we do cross builds anyway. Leaving us with option 2) that is simple, strighforward and harmless. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] kgdb: support for ARCH=arm
This patch adds the ARCH=arm specific a kgdb backend, originally
written by Deepak Saxena <[EMAIL PROTECTED]> and George Davis
<[EMAIL PROTECTED]>. Geoff Levand <[EMAIL PROTECTED]>,
Nicolas Pitre, and Manish Lachwani have contributed various fixups
here as well.
The changes to setup the traps earlier allow for early debugging with
a uart based KGDB I/O driver. The do_undefinstr() routine also needed
to allow the lookup of kernel address space in order for the debugger
to plant undefined instructions in kernel memory space and receive the
correct notification.
Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
---
arch/arm/Kconfig |1 +
arch/arm/kernel/Makefile |1 +
arch/arm/kernel/kgdb.c | 219 ++
arch/arm/kernel/setup.c |5 +
arch/arm/kernel/traps.c | 11 +++
include/asm-arm/kgdb.h | 101 +
include/asm-arm/traps.h |2 +
7 files changed, 340 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/kernel/kgdb.c
create mode 100644 include/asm-arm/kgdb.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9619c43..9e2e631 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -11,6 +11,7 @@ config ARM
select RTC_LIB
select SYS_SUPPORTS_APM_EMULATION
select HAVE_OPROFILE
+ select HAVE_ARCH_KGDB
select HAVE_KPROBES if (!XIP_KERNEL)
help
The ARM series is a line of low-power-consumption RISC chip designs
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 00d44c6..9bb17e6 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_KEXEC) += machine_kexec.o
relocate_kernel.o
obj-$(CONFIG_KPROBES) += kprobes.o kprobes-decode.o
obj-$(CONFIG_ATAGS_PROC) += atags.o
obj-$(CONFIG_OABI_COMPAT) += sys_oabi-compat.o
+obj-$(CONFIG_KGDB) += kgdb.o
obj-$(CONFIG_CRUNCH) += crunch.o crunch-bits.o
AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
new file mode 100644
index 000..4f5b297
--- /dev/null
+++ b/arch/arm/kernel/kgdb.c
@@ -0,0 +1,219 @@
+/*
+ * arch/arm/kernel/kgdb.c
+ *
+ * ARM KGDB support
+ *
+ * Copyright (c) 2002-2004 MontaVista Software, Inc
+ * Copyright (c) 2008 Wind River Systems, Inc.
+ *
+ * Authors: George Davis <[EMAIL PROTECTED]>
+ * Deepak Saxena <[EMAIL PROTECTED]>
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Make a local copy of the registers passed into the handler (bletch) */
+void pt_regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *kernel_regs)
+{
+ int regno;
+
+ /* Initialize all to zero. */
+ for (regno = 0; regno < GDB_MAX_REGS; regno++)
+ gdb_regs[regno] = 0;
+
+ gdb_regs[_R0] = kernel_regs->ARM_r0;
+ gdb_regs[_R1] = kernel_regs->ARM_r1;
+ gdb_regs[_R2] = kernel_regs->ARM_r2;
+ gdb_regs[_R3] = kernel_regs->ARM_r3;
+ gdb_regs[_R4] = kernel_regs->ARM_r4;
+ gdb_regs[_R5] = kernel_regs->ARM_r5;
+ gdb_regs[_R6] = kernel_regs->ARM_r6;
+ gdb_regs[_R7] = kernel_regs->ARM_r7;
+ gdb_regs[_R8] = kernel_regs->ARM_r8;
+ gdb_regs[_R9] = kernel_regs->ARM_r9;
+ gdb_regs[_R10] = kernel_regs->ARM_r10;
+ gdb_regs[_FP] = kernel_regs->ARM_fp;
+ gdb_regs[_IP] = kernel_regs->ARM_ip;
+ gdb_regs[_SPT] = kernel_regs->ARM_sp;
+ gdb_regs[_LR] = kernel_regs->ARM_lr;
+ gdb_regs[_PC] = kernel_regs->ARM_pc;
+ gdb_regs[_CPSR] = kernel_regs->ARM_cpsr;
+}
+
+/* Copy local gdb registers back to kgdb regs, for later copy to kernel */
+void gdb_regs_to_pt_regs(unsigned long *gdb_regs, struct pt_regs *kernel_regs)
+{
+ kernel_regs->ARM_r0 = gdb_regs[_R0];
+ kernel_regs->ARM_r1 = gdb_regs[_R1];
+ kernel_regs->ARM_r2 = gdb_regs[_R2];
+ kernel_regs->ARM_r3 = gdb_regs[_R3];
+ kernel_regs->ARM_r4 = gdb_regs[_R4];
+ kernel_regs->ARM_r5 = gdb_regs[_R5];
+ kernel_regs->ARM_r6 = gdb_regs[_R6];
+ kernel_regs->ARM_r7 = gdb_regs[_R7];
+ kernel_regs->ARM_r8 = gdb_regs[_R8];
+ kernel_regs->ARM_r9 = gdb_regs[_R9];
+ kernel_regs->ARM_r10 = gdb_regs[_R10];
+ kernel_regs->ARM_fp = gdb_regs[_FP];
+ kernel_regs->ARM_ip = gdb_regs[_IP];
+ kernel_regs->ARM_sp = gdb_regs[_SPT];
+ kernel_regs->ARM_lr = gdb_regs[_LR];
+ kernel_regs->ARM_pc = gdb_regs[_PC];
+ kernel_regs->ARM_cpsr = gdb_regs[_CPSR];
+}
+
+void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs,
+struct task_struct *task)
+{
+ int regno;
+ struct pt_regs *thread_regs;
+
+ /* Just making sure... */
+ if (task == NULL)
+ return;
+
+ /* Initialize
Re: [BUG] 2.6.25-rc2-mm1 - Kernel panic while bootup caused by signal_group_exit()
On Sun, 17 Feb 2008 09:40:33 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > [ 25.512919] BUG: unable to handle kernel paging request at 9d74e37b > [ 25.514926] IP: [] proc_flush_task+0x5b/0x223 I wonder if this one is related. Also with 2.6.25-rc2-mm1 on x86_64: BUG: unable to handle kernel paging request at 00200200 IP: [] free_pid+0x35/0x90 PGD 43c00c067 PUD 43e5f1067 PMD 0 Oops: 0002 [1] SMP last sysfs file: /sys/devices/pnp0/00:0b/id CPU 7 Modules linked in: dm_multipath qla2xxx bnx2 iTCO_wdt iTCO_vendor_support serio_raw rtc_cmos pcspkr watchdog_core scsi_transport_fc watchdog_dev i5000_edac edac_core button dcdbas joydev sg sr_mod cdrom usb_storage ata_piix libata dm_snapshot dm_zero dm_mirror dm_mod shpchp megaraid_sas sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode] Pid: 1992, comm: S05kudzu Not tainted 2.6.25-rc2-mm1 #4 RIP: 0010:[] [] free_pid+0x35/0x90 RSP: 0018:81043c895e58 EFLAGS: 00010046 RAX: RBX: 81043dd31440 RCX: 81043e5ffb08 RDX: 00200200 RSI: 0046 RDI: RBP: 81043b9703c0 R08: R09: 0001 R10: 81043d1a R11: R12: 81043e5ffac0 R13: R14: R15: 008cd530 FS: 7f68f99786f0() GS:81043e7100c0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 00200200 CR3: 000436c1f000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process S05kudzu (pid: 1992, threadinfo 81043c894000, task 81043b9acb40) Stack: 81043dd31440 81043b9703c0 81043c84ae40 81035a6d 81043b9703c0 07cd 810362b7 81043c895f18 81051316 7fff01989514 Call Trace: [] ? release_task+0x1be/0x346 [] ? do_wait+0x6c2/0xa0e [] ? trace_hardirqs_on_caller+0xf2/0x115 [] ? default_wake_function+0x0/0xe [] ? trace_hardirqs_on_caller+0xf2/0x115 [] ? sys_wait4+0x8a/0xa1 [] ? system_call_after_swapgs+0x7b/0x80 -- All Rights Reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] kgdb: fix optional arch functions and probe_kernel_*
Fix two regressions dealing with the kgdb core.
1) kgdb_skipexception and kgdb_post_primary_code are optional
functions that are only required on archs that need special exception
fixups.
2) The kernel address space scope must be set on any probe_kernel_*
function or archs such as ARCH=arm will not allow access to the kernel
memory space. As an example, it is required to allow the full kernel
address space is when you the kernel debugger to inspect a system
call.
Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
---
kernel/kgdb.c | 11 +++
mm/maccess.c |6 ++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/kernel/kgdb.c b/kernel/kgdb.c
index 68aea78..31425e0 100644
--- a/kernel/kgdb.c
+++ b/kernel/kgdb.c
@@ -200,6 +200,17 @@ int __weak kgdb_arch_init(void)
return 0;
}
+int __weak kgdb_skipexception(int exception, struct pt_regs *regs)
+{
+ return 0;
+}
+
+void __weak
+kgdb_post_primary_code(struct pt_regs *regs, int e_vector, int err_code)
+{
+ return;
+}
+
/**
* kgdb_disable_hw_debug - Disable hardware debugging while we in kgdb.
* @regs: Current pt_regs.
diff --git a/mm/maccess.c b/mm/maccess.c
index 24f81b9..ac40796 100644
--- a/mm/maccess.c
+++ b/mm/maccess.c
@@ -17,11 +17,14 @@
long probe_kernel_read(void *dst, void *src, size_t size)
{
long ret;
+ mm_segment_t old_fs = get_fs();
+ set_fs(KERNEL_DS);
pagefault_disable();
ret = __copy_from_user_inatomic(dst,
(__force const void __user *)src, size);
pagefault_enable();
+ set_fs(old_fs);
return ret ? -EFAULT : 0;
}
@@ -39,10 +42,13 @@ EXPORT_SYMBOL_GPL(probe_kernel_read);
long probe_kernel_write(void *dst, void *src, size_t size)
{
long ret;
+ mm_segment_t old_fs = get_fs();
+ set_fs(KERNEL_DS);
pagefault_disable();
ret = __copy_to_user_inatomic((__force void __user *)dst, src, size);
pagefault_enable();
+ set_fs(old_fs);
return ret ? -EFAULT : 0;
}
--
1.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] kgdb: kgdboc pl011 I/O module
Implement the serial polling hooks for the pl011 uart for use with
kgdboc.
This patch was specifically tested on the ARM Versatile AB reference
platform.
Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
drivers/serial/amba-pl011.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/amba-pl011.c b/drivers/serial/amba-pl011.c
index 40604a0..ecd3dad 100644
--- a/drivers/serial/amba-pl011.c
+++ b/drivers/serial/amba-pl011.c
@@ -314,6 +314,32 @@ static void pl011_break_ctl(struct uart_port *port, int
break_state)
spin_unlock_irqrestore(>port.lock, flags);
}
+#ifdef CONFIG_CONSOLE_POLL
+static int pl010_get_poll_char(struct uart_port *port)
+{
+ struct uart_amba_port *uap = (struct uart_amba_port *)port;
+ unsigned int status;
+ int ch;
+ do {
+ status = readw(uap->port.membase + UART01x_FR);
+ } while (status & UART01x_FR_RXFE);
+ ch = readw(uap->port.membase + UART01x_DR);
+
+ return ch;
+}
+
+static void pl010_put_poll_char(struct uart_port *port,
+unsigned char ch)
+{
+ struct uart_amba_port *uap = (struct uart_amba_port *)port;
+
+ while (readw(uap->port.membase + UART01x_FR) & UART01x_FR_TXFF)
+ barrier();
+ writew(ch, uap->port.membase + UART01x_DR);
+}
+
+#endif /* CONFIG_CONSOLE_POLL */
+
static int pl011_startup(struct uart_port *port)
{
struct uart_amba_port *uap = (struct uart_amba_port *)port;
@@ -572,6 +598,10 @@ static struct uart_ops amba_pl011_pops = {
.request_port = pl010_request_port,
.config_port= pl010_config_port,
.verify_port= pl010_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+ .poll_get_char = pl010_get_poll_char,
+ .poll_put_char = pl010_put_poll_char,
+#endif
};
static struct uart_amba_port *amba_ports[UART_NR];
--
1.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] kgdb: fixes and ARCH=arm support
Here are 3 more patches against the kgdb-light. Porting kgdb-light to another arch has found 2 regressions, which are fixed in the first patch. The second patch adds hooks for an additional kgdboc uart driver which was required to complete the testing with real hardware. The third patch adds the ARCH=arm support for kgdb-light. For initial merge of kgdb-light targeted at 2.6.26, the first patch in this series is required. The other patches are there for further community review and to show the effort of integrating kgdb into another arch with the API provided in the kgdb-light patch series. Jason. The following changes since commit 4ce04a959ef2ba9338217966013b832ff0ff9003: Jason Wessel (1): kgdb-light-v10: x86 HW breakpoints are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git for_ingo Jason Wessel (3): kgdb: fix optional arch functions and probe_kernel_* kgdb: kgdboc pl011 I/O module kgdb: support for ARCH=arm arch/arm/Kconfig|1 + arch/arm/kernel/Makefile|1 + arch/arm/kernel/kgdb.c | 219 +++ arch/arm/kernel/setup.c |5 + arch/arm/kernel/traps.c | 11 ++ drivers/serial/amba-pl011.c | 30 ++ include/asm-arm/kgdb.h | 101 include/asm-arm/traps.h |2 + kernel/kgdb.c | 11 ++ mm/maccess.c|6 + 10 files changed, 387 insertions(+), 0 deletions(-) create mode 100644 arch/arm/kernel/kgdb.c create mode 100644 include/asm-arm/kgdb.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB regression (and other failures) in 2.6.2[45]* - mostly resolved
On Wed, 20 Feb 2008, Andrew Buehler wrote: > In other words: I don't think that's likely to be practical in the > present instance. If you have reason to believe otherwise (past positive > experience with Novell, for instance), I'd be glad to hear it. Greg KH may be able to help in that respect. > Is there any place (aside from maybe the kernel changelog, which > contains a whole lot - if not several lots - of unrelated information) > where I could find a list of config-symbol name additions, changes, > deletions and meaning changes by version or by date? That would at least > let me build a mapping between the symbols in the older config and the > ones in the new one, which is about where I would have to start. Not as far as I know. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote: > On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > > So, next I'll try "shutdown" to see if it work. I was using "platform". > > > > Ok, that would be good to try. > > "shutdown" does power down properly. But still green on resume. Ok, so Linus' theory about something later in the resume path trying to touch video is looking good. Rafael, is there anyway to prevent the device shutdown in the hibernate path? > > Looks like the AR registers are hosed, which is what I thought I fixed... > > Can you attach your i915_drv.c file just so I can sanity check it? > > Attached. Hm, looks right. Let me see if I can reproduce this on my T61. Thanks, Jesse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add the debugfs interface for the sysprof tool
On Wed, 20 Feb 2008 19:53:42 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-02-20 at 10:39 -0800, Arjan van de Ven wrote: > > On Wed, 20 Feb 2008 19:16:15 +0100 > > Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > > > > > On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote: > > > > From: Soren Sandmann <[EMAIL PROTECTED]> > > > > Subject: [PATCH] x86: add the debugfs interface for the sysprof > > > > tool > > > > > > > > The sysprof tool is a very easy to use GUI tool to find out > > > > where userspace is spending CPU time. See > > > > http://www.daimi.au.dk/~sandmann/sysprof/ > > > > for more information and screenshots on this tool. > > > > > > > > Sysprof needs a 200 line kernel module to do it's work, this > > > > module puts some simple profiling data into debugfs. > > > > > > What is the added value over oprofile? > > > > it actually works and is usable by humans ;) > > # sysprof > > (sysprof:12480): Gtk-WARNING **: cannot open display: > > -ENOX > > > what oprofile doesn't do is the nice userland hierarchy of where > > cpu time is spend. (and that is also what makes it mostly useless > > in practice) > > so why not fix oprofile callgraph output and build a GUI on top of > oprofile for those of us who really want RSI from mouse movement :-) feel free to reinvent a whole GUI just to avoid a 200 line kernel module. sysprof is here. it works. the gui is REALLY nice. I think it's the wrong tradeoff though... oprofile exists for how long? -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Wed, 20 Feb 2008, Pierre Ossman wrote: > Not really. But you have some things confused. What it checks is if > the mmc bus handler (not a proper driver model, just a way of > separating the MMC, SD and SDIO stuff) has a resume function. And if > it doesn't, it removes the card (since it cannot revive it at > resume). > > So the only thing I can think of is to delay the removal until the > resume routine, if that is safer. Do I understand this correctly? You've got special handling for the case where a bus handler doesn't have a resume routine, but no special handling for the case where it doesn't have a suspend routine? Why bother to remove the device if neither routine exists (there won't be any need to revive it since the bus never got suspended)? And why not simply fail the suspend if the resume routine doesn't exist and the suspend routine does? Maybe with an error message in the system log. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Thu, Feb 21, 2008 at 02:49:39AM +0800, Jeff Chua wrote: > Here's an interesting discovery. After I found that "echo reboot > > /sys/power/disk" does reboot, I tried "echo shutdown > > /sys/power/disk", it does shutdown properly. > > With "platform" it refuses to shutdown. Both reboot and shutdown still > end up with Mr. Green at resume. That kind of suggests that the ACPI platform code is hitting the hardware directly - we've seen similar issues with PATA controllers. The right thing to do here is almost certainly just to avoid explicitly powering down hardware on hibernation. -- Matthew Garrett | [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION] FRV: linking error?
[Sam Ravnborg - Wed, Feb 20, 2008 at 08:19:38PM +0100] | On Wed, Feb 20, 2008 at 09:15:00PM +0300, Cyrill Gorcunov wrote: | > [David Howells - Wed, Feb 20, 2008 at 06:13:15PM +] | > | Cyrill Gorcunov <[EMAIL PROTECTED]> wrote: | > | | > | > Sam, maybe we should just eliminate this section at least for FRV? | > | | > | You should have a patch in your inbox to do just that. | > | | > | David | > | | > | > Thanks David! I've got them all. | > I think Sam will take care of them to be included in mainline. | | arch stuff like this is preferably going via the arch maintainer. | Sometimes I do all-arch patches but when they are independent | like this one they should go via the arch maintainer. | | Cyrill - I would like you to do the same cleanup for | m32r + mn10300 + s390 | and send the patch to the respective maintainers with a cc to me. | | Thanks, | Sam | ok, I will do it - Cyrill - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION] FRV: linking error?
On Wed, Feb 20, 2008 at 09:15:00PM +0300, Cyrill Gorcunov wrote: > [David Howells - Wed, Feb 20, 2008 at 06:13:15PM +] > | Cyrill Gorcunov <[EMAIL PROTECTED]> wrote: > | > | > Sam, maybe we should just eliminate this section at least for FRV? > | > | You should have a patch in your inbox to do just that. > | > | David > | > > Thanks David! I've got them all. > I think Sam will take care of them to be included in mainline. arch stuff like this is preferably going via the arch maintainer. Sometimes I do all-arch patches but when they are independent like this one they should go via the arch maintainer. Cyrill - I would like you to do the same cleanup for m32r + mn10300 + s390 and send the patch to the respective maintainers with a cc to me. Thanks, Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > So, next I'll try "shutdown" to see if it work. I was using "platform".
> Ok, that would be good to try.
"shutdown" does power down properly. But still green on resume.
> Looks like the AR registers are hosed, which is what I thought I fixed... Can
> you attach your i915_drv.c file just so I can sanity check it?
Attached.
Thanks,
Jeff.
/* i915_drv.c -- i830,i845,i855,i865,i915 driver -*- linux-c -*-
*/
/*
*
* Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
* All Rights Reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the
* "Software"), to deal in the Software without restriction, including
* without limitation the rights to use, copy, modify, merge, publish,
* distribute, sub license, and/or sell copies of the Software, and to
* permit persons to whom the Software is furnished to do so, subject to
* the following conditions:
*
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial portions
* of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
* OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
* IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
* ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*
*/
#include "drmP.h"
#include "drm.h"
#include "i915_drm.h"
#include "i915_drv.h"
#include "drm_pciids.h"
static struct pci_device_id pciidlist[] = {
i915_PCI_IDS
};
enum pipe {
PIPE_A = 0,
PIPE_B,
};
static bool i915_pipe_enabled(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev->dev_private;
if (pipe == PIPE_A)
return (I915_READ(DPLL_A) & DPLL_VCO_ENABLE);
else
return (I915_READ(DPLL_B) & DPLL_VCO_ENABLE);
}
static void i915_save_palette(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev->dev_private;
unsigned long reg = (pipe == PIPE_A ? PALETTE_A : PALETTE_B);
u32 *array;
int i;
if (!i915_pipe_enabled(dev, pipe))
return;
if (pipe == PIPE_A)
array = dev_priv->save_palette_a;
else
array = dev_priv->save_palette_b;
for(i = 0; i < 256; i++)
array[i] = I915_READ(reg + (i << 2));
}
static void i915_restore_palette(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev->dev_private;
unsigned long reg = (pipe == PIPE_A ? PALETTE_A : PALETTE_B);
u32 *array;
int i;
if (!i915_pipe_enabled(dev, pipe))
return;
if (pipe == PIPE_A)
array = dev_priv->save_palette_a;
else
array = dev_priv->save_palette_b;
for(i = 0; i < 256; i++)
I915_WRITE(reg + (i << 2), array[i]);
}
static u8 i915_read_indexed(u16 index_port, u16 data_port, u8 reg)
{
outb(reg, index_port);
return inb(data_port);
}
static u8 i915_read_ar(u16 st01, u8 reg, u16 palette_enable)
{
inb(st01);
outb(palette_enable | reg, VGA_AR_INDEX);
return inb(VGA_AR_DATA_READ);
}
static void i915_write_ar(u8 st01, u8 reg, u8 val, u16 palette_enable)
{
inb(st01);
outb(palette_enable | reg, VGA_AR_INDEX);
outb(val, VGA_AR_DATA_WRITE);
}
static void i915_write_indexed(u16 index_port, u16 data_port, u8 reg, u8 val)
{
outb(reg, index_port);
outb(val, data_port);
}
static void i915_save_vga(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
int i;
u16 cr_index, cr_data, st01;
/* VGA color palette registers */
dev_priv->saveDACMASK = inb(VGA_DACMASK);
/* DACCRX automatically increments during read */
outb(0, VGA_DACRX);
/* Read 3 bytes of color data from each index */
for (i = 0; i < 256 * 3; i++)
dev_priv->saveDACDATA[i] = inb(VGA_DACDATA);
/* MSR bits */
dev_priv->saveMSR = inb(VGA_MSR_READ);
if (dev_priv->saveMSR & VGA_MSR_CGA_MODE) {
cr_index = VGA_CR_INDEX_CGA;
cr_data = VGA_CR_DATA_CGA;
st01 = VGA_ST01_CGA;
} else {
cr_index = VGA_CR_INDEX_MDA;
cr_data = VGA_CR_DATA_MDA;
st01 = VGA_ST01_MDA;
}
/* CRT controller regs */
i915_write_indexed(cr_index, cr_data, 0x11,
i915_read_indexed(cr_index, cr_data, 0x11)
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Wednesday, February 20, 2008 10:29 am Jeff Chua wrote: > > I know I fixed that problem in at least one configuration... Can you > > try: # echo test > /sys/power/disk > > # echo disk > /sys/power/state > > and see if that also turns your screen green? > > Yes, still green. But I got it to actual reboot with ... > > echo reboot > /sys/power/disk > > So, next I'll try "shutdown" to see if it work. I was using "platform". Ok, that would be good to try. > > Also, getting a GPU register dump would be helpful. The intel_reg_dumper > > tool > > Attached are the two dumps from console. One prior to suspend, and one > after resume. Looks like the AR registers are hosed, which is what I thought I fixed... Can you attach your i915_drv.c file just so I can sanity check it? Thanks, Jesse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
did someone say interface/API documentation ooops ... seriously this is lacking and im sure as time goes on some volenteer (sucker) will get it up and running.this is not a show stoper but a nice to have.ill perhaps even help out a bit with things, i have some comments on useage and module parameters that could be usefull to the would be users.remember mISDN is just the kernel bits there is a user lib that takes care of userland bits. > >> b) still doesn't support all the hardware isdn4linux supports. > > That's a show stopper of course. of course not all hardware is supported and in some cases more hardware is supported ... there is a precident for this OSS/ALSA where the one is marked as DEPRICATED and the other promoted initialy as EXPERMENTAL ... over all the most common devices are better supported under mISDN than isdn4linux. and as with OSS/ALSA both can coexist on the system as modules (only one can be loaded at a time or else they dont play nice). i really think this is a storm in a tea cup been blown into a hurricane after all if it were mainlined (in -mm even) the result would be better support and more choice there are far worse supported drivers than the mISDN stack.the reality is that isdn4linux is dead idealy unsuported drivers need to be ported to mISDN or kept on life support. -- This message has been scanned for viruses and dangerous content by Superset Technology, and is believed to be clean. http://www.superset.co.za -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tty && pid problems
On 02/20/2008 05:28 PM, Oleg Nesterov wrote: I think you can revert the tty-bkl-pushdown.patch. Or, as Eric suggested, just revert this @@ -1222,7 +1221,7 @@ static const struct file_operations tty_ .read = tty_read, .write = tty_write, .poll = tty_poll, - .ioctl = tty_ioctl, + .unlocked_ioctl = tty_ioctl, .compat_ioctl = tty_compat_ioctl, .open = tty_open, .release= tty_release, @@ -1235,7 +1234,7 @@ static const struct file_operations ptmx .read = tty_read, .write = tty_write, .poll = tty_poll, - .ioctl = tty_ioctl, + .unlocked_ioctl = tty_ioctl, .compat_ioctl = tty_compat_ioctl, .open = ptmx_open, .release= tty_release, @@ -1248,7 +1247,7 @@ static const struct file_operations cons .read = tty_read, .write = redirected_tty_write, .poll = tty_poll, - .ioctl = tty_ioctl, + .unlocked_ioctl = tty_ioctl, .compat_ioctl = tty_compat_ioctl, .open = tty_open, .release= tty_release, @@ -1260,7 +1259,7 @@ static const struct file_operations hung .read = hung_up_tty_read, .write = hung_up_tty_write, .poll = hung_up_tty_poll, - .ioctl = hung_up_tty_ioctl, + .unlocked_ioctl = hung_up_tty_ioctl, .compat_ioctl = hung_up_tty_compat_ioctl, .release= tty_release, }; chunk. This would result in unpredictable behaviour. If I left locking apart, ioctl prototype != unlocked_ioctl prototype. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add the debugfs interface for the sysprof tool
On Wed, 2008-02-20 at 19:53 +0100, Peter Zijlstra wrote: > On Wed, 2008-02-20 at 10:39 -0800, Arjan van de Ven wrote: > > On Wed, 20 Feb 2008 19:16:15 +0100 > > Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > > > > > On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote: > > > > From: Soren Sandmann <[EMAIL PROTECTED]> > > > > Subject: [PATCH] x86: add the debugfs interface for the sysprof tool > > > > > > > > The sysprof tool is a very easy to use GUI tool to find out where > > > > userspace is spending CPU time. See > > > > http://www.daimi.au.dk/~sandmann/sysprof/ > > > > for more information and screenshots on this tool. > > > > > > > > Sysprof needs a 200 line kernel module to do it's work, this > > > > module puts some simple profiling data into debugfs. > > > > > > What is the added value over oprofile? > > > > it actually works and is usable by humans ;) > > # sysprof > > (sysprof:12480): Gtk-WARNING **: cannot open display: > > -ENOX Usable for me is a cli interface. Also, I absolutely love opannotate. For a fact, most of my professional userspace development days, I had to profile on remote machines with no X. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.
On Wednesday, February 20, 2008 10:37 am Linus Torvalds wrote: > This *sounds* like some part of the suspend-to-disk sequence is doing > something stupid like trying to access the screen after it has been turned > off, which doesn't surprise me at all. My oft-stated opinion has been that > suspend-to-disk isn't a suspend at all, and should never have been > confused with "suspending" anything. > > It's "snapshot-and-restore", and my opinion is that: > > - it should *never* call "suspend()"/"resume()" at all (that should be >reserved purely for suspend-to-RAM and has real power management >issues!) > > - it should have a totally separate "halt/unhalt/restore" thing >that has nothing what-so-ever to do with power management, and is >purely about stopping the hardware for things like USB and network >cards (which otherwise do things like scan their command lists >asynchronously) and making sure that the driver state is consistent >with that stopped hw state. > > - the people who confuse snapshot/restore with suspend/resume are >horrible people that cause problems exactly because driver people then >get those things mixed up, and something like the video suspend/resume >should probably never have impacted suspend-to-disk in the first place! Totally agreed. I remember when I started getting hibernation bug reports against this new code and boggling at how hibernate was actually done. The driver actually gets its ->suspend routine called twice with two different pm_message_t values. We tried to do different stuff depending on the pm_message_t (like only putting the device in D3hot if PM_EVENT_SUSPEND), but it appears we're not doing enough... > So there seems to be two (probably largely independent) problems: > > - the hang at shutdown that requires you to press-and-hold the power >button to actually cut power. > >At a guess: putting the VGA device into D3hot makes the ACPI code that >actually does the shutoff unhappy. Probably because it wants to access >the device, and ends up not ever getting the replies it wants, since >the hardware has been turned off. Sounds like a good theory... now if we could just use set_power_state in the suspend case only. That's what the latest code *tries* to do... JEsse -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add the debugfs interface for the sysprof tool
On Wed, 2008-02-20 at 10:39 -0800, Arjan van de Ven wrote: > On Wed, 20 Feb 2008 19:16:15 +0100 > Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > > On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote: > > > From: Soren Sandmann <[EMAIL PROTECTED]> > > > Subject: [PATCH] x86: add the debugfs interface for the sysprof tool > > > > > > The sysprof tool is a very easy to use GUI tool to find out where > > > userspace is spending CPU time. See > > > http://www.daimi.au.dk/~sandmann/sysprof/ > > > for more information and screenshots on this tool. > > > > > > Sysprof needs a 200 line kernel module to do it's work, this > > > module puts some simple profiling data into debugfs. > > > > What is the added value over oprofile? > > it actually works and is usable by humans ;) # sysprof (sysprof:12480): Gtk-WARNING **: cannot open display: -ENOX > what oprofile doesn't do is the nice userland hierarchy of where cpu time is > spend. > (and that is also what makes it mostly useless in practice) so why not fix oprofile callgraph output and build a GUI on top of oprofile for those of us who really want RSI from mouse movement :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86_64: Fold pda into per cpu area v3
Ingo Molnar wrote: > * Mike Travis <[EMAIL PROTECTED]> wrote: > >> * Declare the pda as a per cpu variable. This will move the pda area >> to an address accessible by the x86_64 per cpu macros. >> Subtraction of __per_cpu_start will make the offset based from the >> beginning of the per cpu area. Since %gs is pointing to the pda, >> it will then also point to the per cpu variables and can be >> accessed thusly: >> >> %gs:[_cpu_ - __per_cpu_start] > > randconfig QA on x86.git found a crash on x86.git#testing with > nmi_watchdog=2 (config attached) - and i bisected it down to this patch. > > config and crashlog attached. You can pick up x86.git#testing via: > > http://people.redhat.com/mingo/x86.git/README > > (since i had to hand-merge the patch when integrating it, i've attached > the merged version below.) > > Ingo > I must need some different test machines as my AMD box does not fail with either yours or Thomas's configs, and the Intel box complains about the PCI-e e1000 driver and dies. I'll see about configuring a new box. Did you try Eric's patch to see if that fixed the failure? Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Document huge memory/cache overhead of memory controller in Kconfig
On Wed 2008-02-20 19:28:03, Jan Engelhardt wrote: > > On Feb 20 2008 18:19, Pavel Machek wrote: > >> > >> For ordinary desktop people, memory controller is what developers > >> know as MMU or sometimes even some other mysterious piece of silicon > >> inside the heavy box. > > > >Actually I'd guess 'memory controller' == 'DRAM controller' == part of > >northbridge that talks to DRAM. > > Yeah that must have been it when Windows says it found a new controller > after changing the mainboard underneath. Just for fun... this option really has to be renamed: Memory controller ~ >From Wikipedia, the free encyclopedia The memory controller is a chip on a computer's motherboard or CPU die which manages the flow of data going to and from the memory. Most computers based on an Intel processor have a memory controller implemented on their motherboard's north bridge, though some modern microprocessors, such as AMD's Athlon 64 and Opteron processors, IBM's POWER5, and Sun Microsystems UltraSPARC T1 have a memory controller on the CPU die to reduce the memory latency. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Sat, Feb 16, 2008 at 05:20:49PM +, Pavel Machek wrote: > Is cat /dev/zero > file enough to reproduce this? yes. > ext3 filesystem? yes. > Will cat /etc/passwd work while machine is unresponsive? yes. while find does not work: time find / / /etc /etc/manpath.config /etc/update-manager /etc/update-manager/release-upgrades /etc/gshadow- /etc/inputrc /etc/openalrc /etc/bonobo-activation /etc/bonobo-activation/bonobo-activation-config.xml /etc/gnome-vfs-2.0 /etc/gnome-vfs-2.0/modules /etc/gnome-vfs-2.0/modules/obex-module.conf /etc/gnome-vfs-2.0/modules/extra-modules.conf /etc/gnome-vfs-2.0/modules/theme-method.conf /etc/gnome-vfs-2.0/modules/font-method.conf /etc/gnome-vfs-2.0/modules/default-modules.conf ^C real0m7.982s user0m0.003s sys 0m0.000s i.e., it took 8 seconds to list just 17 dir entries. It looks like I have this problem: http://www.linuxinsight.com/first_benchmarks_of_the_ext4_file_system.html#comment-619 (the last comment with title: Sustained writes 2 or more times the amount of memfree) -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
