[05/11] Fix i2c messsage flags in video drivers
-stable review patch. If anyone has any objections, please let us know.
--
While working on the saa7110 driver I found a problem with the way
various video drivers (found on Zoran-based boards) prepare i2c messages
to be used by i2c_transfer. The drivers improperly copy the i2c client
flags as the message flags, while both sets are mostly unrelated. The
net effect in this case is to trigger an I2C block read instead of the
expected I2C block write. The fix is simply not to pass any flag,
because none are needed.
I think this patch qualifies hands down as a critical bug fix to be
included in whatever bug-fix-only trees exist these days. As far as I
can see, all Zoran-based boards are broken in 2.6.11 without this patch.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/adv7170.c
linux-2.6.11-bk3/drivers/media/video/adv7170.c
--- linux-2.6.11-bk3/drivers/media/video.orig/adv7170.c Tue Mar 8 10:27:14 2005
+++ linux-2.6.11-bk3/drivers/media/video/adv7170.c Tue Mar 8 12:19:04 2005
@@ -130,7 +130,7 @@
u8 block_data[32];
msg.addr = client-addr;
- msg.flags = client-flags;
+ msg.flags = 0;
while (len = 2) {
msg.buf = (char *) block_data;
msg.len = 0;
diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/adv7175.c
linux-2.6.11-bk3/drivers/media/video/adv7175.c
--- linux-2.6.11-bk3/drivers/media/video.orig/adv7175.c Tue Mar 8 10:27:14 2005
+++ linux-2.6.11-bk3/drivers/media/video/adv7175.c Tue Mar 8 12:18:57 2005
@@ -126,7 +126,7 @@
u8 block_data[32];
msg.addr = client-addr;
- msg.flags = client-flags;
+ msg.flags = 0;
while (len = 2) {
msg.buf = (char *) block_data;
msg.len = 0;
diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/bt819.c
linux-2.6.11-bk3/drivers/media/video/bt819.c
--- linux-2.6.11-bk3/drivers/media/video.orig/bt819.c Tue Mar 8 10:27:15 2005
+++ linux-2.6.11-bk3/drivers/media/video/bt819.cTue Mar 8 12:18:51 2005
@@ -146,7 +146,7 @@
u8 block_data[32];
msg.addr = client-addr;
- msg.flags = client-flags;
+ msg.flags = 0;
while (len = 2) {
msg.buf = (char *) block_data;
msg.len = 0;
diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/saa7114.c
linux-2.6.11-bk3/drivers/media/video/saa7114.c
--- linux-2.6.11-bk3/drivers/media/video.orig/saa7114.c Tue Mar 8 10:27:15 2005
+++ linux-2.6.11-bk3/drivers/media/video/saa7114.c Tue Mar 8 12:18:20 2005
@@ -163,7 +163,7 @@
u8 block_data[32];
msg.addr = client-addr;
- msg.flags = client-flags;
+ msg.flags = 0;
while (len = 2) {
msg.buf = (char *) block_data;
msg.len = 0;
diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/saa7185.c
linux-2.6.11-bk3/drivers/media/video/saa7185.c
--- linux-2.6.11-bk3/drivers/media/video.orig/saa7185.c Tue Mar 8 10:27:15 2005
+++ linux-2.6.11-bk3/drivers/media/video/saa7185.c Tue Mar 8 12:18:12 2005
@@ -118,7 +118,7 @@
u8 block_data[32];
msg.addr = client-addr;
- msg.flags = client-flags;
+ msg.flags = 0;
while (len = 2) {
msg.buf = (char *) block_data;
msg.len = 0;
--
Jean Delvare
-
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/
-
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/
BK update for NFS client 2.6.11
Hi, Update of the NFS client. A lot of cleanups of the RPC auth code, but also a couple of notable new features: - flock support for NFS. - Improved ESTALE recovery (Chuck + Al Viro). - NFSv4 network partition recovery code - bugfixes. Cheers, Trond Please do a bk pull bk://nfsclient.bkbits.net/linux-2.6 This will update the following files: fs/lockd/clntproc.c | 39 +- fs/lockd/host.c |4 fs/locks.c|9 fs/namei.c| 33 + fs/nfs/dir.c | 170 + fs/nfs/file.c | 61 +++ fs/nfs/inode.c| 48 ++ fs/nfs/mount_clnt.c |4 fs/nfs/nfs3proc.c | 76 +--- fs/nfs/nfs4proc.c | 419 +--- fs/nfs/nfs4state.c| 76 +++- fs/nfs/nfs4xdr.c | 26 + fs/nfs/nfsroot.c | 13 fs/nfs/proc.c | 56 +-- fs/nfs/read.c |2 fs/nfs/unlink.c |9 fs/nfs/write.c| 29 + fs/nfsd/nfs4callback.c|4 include/linux/lockd/lockd.h |3 include/linux/namei.h |2 include/linux/nfs_fs.h| 47 -- include/linux/nfs_fs_sb.h |1 include/linux/nfs_xdr.h | 12 include/linux/sunrpc/auth.h | 19 - include/linux/sunrpc/auth_gss.h |7 include/linux/sunrpc/clnt.h |2 include/linux/sunrpc/gss_api.h| 14 include/linux/sunrpc/sched.h |8 include/linux/sunrpc/xprt.h |3 net/sunrpc/auth.c | 185 -- net/sunrpc/auth_gss/auth_gss.c| 586 +++--- net/sunrpc/auth_gss/gss_krb5_mech.c | 105 +++--- net/sunrpc/auth_gss/gss_mech_switch.c |8 net/sunrpc/auth_gss/gss_spkm3_mech.c | 133 --- net/sunrpc/auth_gss/svcauth_gss.c |5 net/sunrpc/auth_null.c| 60 +-- net/sunrpc/auth_unix.c| 74 ++-- net/sunrpc/clnt.c | 43 +- net/sunrpc/pmap_clnt.c|5 net/sunrpc/sched.c|7 net/sunrpc/xprt.c |5 41 files changed, 1435 insertions(+), 977 deletions(-) through these ChangeSets: [EMAIL PROTECTED] (05/03/10 1.2075) NFS: Ensure mount is always interruptible and soft Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2074) NFS: cleanup create() Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2073) NFS: mkdir() cleanup Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2072) NFS: mknod() cleanup Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2071) NFSv4: in readdir, use MOUNTED_ON_FILEID, rather than true fileid Some servers return an error if the READDIR call attempts to read the fileid of a mountpoint. Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2070) NFSv4: Allow recovery from network partitions Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2069) NFSv4: Add nfs4_state_recovery_ops We want to reuse the same code to recover the NFSv4 state after a server reboot, a network partition, or a failover situation. Add a structure to contain those operations will that depend on the recovery scenario under consideration. Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2068) NFS: Cleanups for the network partition reclaim code Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2067) NFSv4: Fix access mode checking when opening a delegated file. Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2066) NFSv4: NFSv4 errors in nfs4_init_client() must not leak to userland Fixes a potential Oops at mount time. Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2065) NFSv4: Exit without Oopsing from close when servers send us crazy errors. If retrying the request is not an option, we should just set state-state and be done with it. Signed-off-by: Trond Myklebust [EMAIL PROTECTED] [EMAIL PROTECTED] (05/03/10 1.2064) NFSv4: Handle the NFS4ERR_CLID_INUSE error in SETCLIENTID Encode the AUTH flavour in the clientid, since AUTH_UNIX and AUTH_GSS credentials will always conflict. Then, strategy is to first retry after sleeping for a lease period. If the server then still refuses our clientid, assume we have a conflicting
Re: [06/11] [TCP]: Put back tcp_timer_bug_msg[] symbol export.
On Thu, 10 Mar 2005 23:20:14 + Christoph Hellwig [EMAIL PROTECTED] wrote: --- a/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00 +++ b/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00 @@ -38,6 +38,7 @@ #ifdef TCP_DEBUG const char tcp_timer_bug_msg[] = KERN_DEBUG tcpbug: unknown timer value\n; +EXPORT_SYMBOL(tcp_timer_bug_msg); #endif not complaining about putting this into -stable, but why do people have TCP_DEBUG turned on for normal builds? It is on in everyone's build unless they edit include/net/tcp.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/
[10/11] sis900 kernel oops fix
-stable review patch. If anyone has any objections, please let us know.
--
Backport of fix described below.
From: Herbert Xu [EMAIL PROTECTED]
Fix bug #4223.
OK, this happened because we got preempted before sis900_mii_probe
finished setting the sis_priv-mii. Theoretically this can happen
with SMP as well but I suppose the number of SMP machines with sis900
is fairly small.
Anyway, the fix is to make sure that sis900_mii_probe is done before
the device can be opened. This patch does it by moving the setup
before register_netdevice.
Since the netdev name is not available before register_netdev, I've
changed the relevant printk's to use pci_name instead. Note that
one of those printk's may be called after register_netdev as well.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
--- 1.62/drivers/net/sis900.c 2005-01-10 08:52:27 -08:00
+++ edited/drivers/net/sis900.c 2005-03-10 12:23:49 -08:00
@@ -236,7 +236,7 @@ static int __devinit sis900_get_mac_addr
signature = (u16) read_eeprom(ioaddr, EEPROMSignature);
if (signature == 0x || signature == 0x) {
printk (KERN_INFO %s: Error EERPOM read %x\n,
- net_dev-name, signature);
+ pci_name(pci_dev), signature);
return 0;
}
@@ -268,7 +268,7 @@ static int __devinit sis630e_get_mac_add
if (!isa_bridge)
isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0018,
isa_bridge);
if (!isa_bridge) {
- printk(%s: Can not find ISA bridge\n, net_dev-name);
+ printk(%s: Can not find ISA bridge\n, pci_name(pci_dev));
return 0;
}
pci_read_config_byte(isa_bridge, 0x48, reg);
@@ -456,10 +456,6 @@ static int __devinit sis900_probe(struct
net_dev-tx_timeout = sis900_tx_timeout;
net_dev-watchdog_timeo = TX_TIMEOUT;
net_dev-ethtool_ops = sis900_ethtool_ops;
-
- ret = register_netdev(net_dev);
- if (ret)
- goto err_unmap_rx;
/* Get Mac address according to the chip revision */
pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, revision);
@@ -476,7 +472,7 @@ static int __devinit sis900_probe(struct
if (ret == 0) {
ret = -ENODEV;
- goto err_out_unregister;
+ goto err_unmap_rx;
}
/* 630ET : set the mii access mode as software-mode */
@@ -486,7 +482,7 @@ static int __devinit sis900_probe(struct
/* probe for mii transceiver */
if (sis900_mii_probe(net_dev) == 0) {
ret = -ENODEV;
- goto err_out_unregister;
+ goto err_unmap_rx;
}
/* save our host bridge revision */
@@ -496,6 +492,10 @@ static int __devinit sis900_probe(struct
pci_dev_put(dev);
}
+ ret = register_netdev(net_dev);
+ if (ret)
+ goto err_unmap_rx;
+
/* print some information about our NIC */
printk(KERN_INFO %s: %s at %#lx, IRQ %d, , net_dev-name,
card_name, ioaddr, net_dev-irq);
@@ -505,8 +505,6 @@ static int __devinit sis900_probe(struct
return 0;
- err_out_unregister:
- unregister_netdev(net_dev);
err_unmap_rx:
pci_free_consistent(pci_dev, RX_TOTAL_SIZE, sis_priv-rx_ring,
sis_priv-rx_ring_dma);
@@ -533,6 +531,7 @@ static int __devinit sis900_probe(struct
static int __init sis900_mii_probe(struct net_device * net_dev)
{
struct sis900_private * sis_priv = net_dev-priv;
+ const char *dev_name = pci_name(sis_priv-pci_dev);
u16 poll_bit = MII_STAT_LINK, status = 0;
unsigned long timeout = jiffies + 5 * HZ;
int phy_addr;
@@ -582,21 +581,20 @@ static int __init sis900_mii_probe(struc
mii_phy-phy_types =
(mii_status (MII_STAT_CAN_TX_FDX
| MII_STAT_CAN_TX)) ? LAN : HOME;
printk(KERN_INFO %s: %s transceiver found at
address %d.\n,
- net_dev-name, mii_chip_table[i].name,
+ dev_name, mii_chip_table[i].name,
phy_addr);
break;
}
if( !mii_chip_table[i].phy_id1 ) {
printk(KERN_INFO %s: Unknown PHY transceiver found at
address %d.\n,
- net_dev-name, phy_addr);
+ dev_name, phy_addr);
mii_phy-phy_types = UNKNOWN;
}
}
if (sis_priv-mii == NULL) {
- printk(KERN_INFO %s: No MII transceivers found!\n,
- net_dev-name);
+
[02/11] cramfs: small stat(2) fix
-stable review patch. If anyone has any objections, please let us know.
--
From: Eric Lammerts [EMAIL PROTECTED]
When I stat(2) a device node on a cramfs, the st_blocks field is bogus
(it's derived from the size field which in this case holds the major/minor
numbers). This makes du(1) output completely wrong.
Signed-off-by: Eric Lammerts [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
diff -puN fs/cramfs/inode.c~cramfs-small-stat2-fix fs/cramfs/inode.c
--- 25/fs/cramfs/inode.c~cramfs-small-stat2-fix 2005-03-04 13:15:57.0
-0800
+++ 25-akpm/fs/cramfs/inode.c 2005-03-04 13:15:57.0 -0800
@@ -70,6 +70,7 @@ static struct inode *get_cramfs_inode(st
inode-i_data.a_ops = cramfs_aops;
} else {
inode-i_size = 0;
+ inode-i_blocks = 0;
init_special_inode(inode, inode-i_mode,
old_decode_dev(cramfs_inode-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/
[01/11] fix amd64 2.6.11 oops on modprobe (saa7110)
-stable review patch. If anyone has any objections, please let us know.
--
This is a rewrite of the saa7110_write_block function, which was plain
broken in the case where the underlying adapter supports I2C_FUNC_I2C.
It also includes related fixes which ensure that different parts of the
driver agree on the number of registers the chip has.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
--- linux-2.6.11-bk3/drivers/media/video/saa7110.c.orig Tue Mar 8 10:27:15 2005
+++ linux-2.6.11-bk3/drivers/media/video/saa7110.c Tue Mar 8 12:02:45 2005
@@ -58,10 +58,12 @@
#define SAA7110_MAX_INPUT 9 /* 6 CVBS, 3 SVHS */
#define SAA7110_MAX_OUTPUT 0 /* its a decoder only */
-#defineI2C_SAA7110 0x9C/* or 0x9E */
+#define I2C_SAA71100x9C/* or 0x9E */
+
+#define SAA7110_NR_REG 0x35
struct saa7110 {
- unsigned char reg[54];
+ u8 reg[SAA7110_NR_REG];
int norm;
int input;
@@ -95,31 +97,28 @@
unsigned int len)
{
int ret = -1;
- u8 reg = *data++;
+ u8 reg = *data; /* first register to write to */
- len--;
+ /* Sanity check */
+ if (reg + (len - 1) SAA7110_NR_REG)
+ return ret;
/* the saa7110 has an autoincrement function, use it if
* the adapter understands raw I2C */
if (i2c_check_functionality(client-adapter, I2C_FUNC_I2C)) {
struct saa7110 *decoder = i2c_get_clientdata(client);
struct i2c_msg msg;
- u8 block_data[54];
- msg.len = 0;
- msg.buf = (char *) block_data;
+ msg.len = len;
+ msg.buf = (char *) data;
msg.addr = client-addr;
- msg.flags = client-flags;
- while (len = 1) {
- msg.len = 0;
- block_data[msg.len++] = reg;
- while (len-- = 1 msg.len 54)
- block_data[msg.len++] =
- decoder-reg[reg++] = *data++;
- ret = i2c_transfer(client-adapter, msg, 1);
- }
+ msg.flags = 0;
+ ret = i2c_transfer(client-adapter, msg, 1);
+
+ /* Cache the written data */
+ memcpy(decoder-reg + reg, data + 1, len - 1);
} else {
- while (len-- = 1) {
+ for (++data, --len; len; len--) {
if ((ret = saa7110_write(client, reg++,
*data++)) 0)
break;
@@ -192,7 +191,7 @@
return 0;
}
-static const unsigned char initseq[] = {
+static const unsigned char initseq[1 + SAA7110_NR_REG] = {
0, 0x4C, 0x3C, 0x0D, 0xEF, 0xBD, 0xF2, 0x03, 0x00,
/* 0x08 */ 0xF8, 0xF8, 0x60, 0x60, 0x00, 0x86, 0x18, 0x90,
/* 0x10 */ 0x00, 0x59, 0x40, 0x46, 0x42, 0x1A, 0xFF, 0xDA,
-
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] cpufreq 2.4 interface removal schedule
On Wed, Mar 09, 2005 at 05:32:00PM +, Linux Kernel wrote: ChangeSet 1.1994.11.3, 2005/03/09 09:32:00-08:00, [EMAIL PROTECTED] [PATCH] cpufreq 2.4 interface removal schedule ChangeSet 1.1994.11.2, 2005/03/09 09:31:40-08:00, [EMAIL PROTECTED] [PATCH] Add 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule please bk cset -x these. They shouldn't have ended up in your tree since this stuff got ripped out two months ago. 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: Someting's busted with serial in 2.6.11 latest
On Thursday 10 March 2005 03:59 pm, Russell King wrote:
On Thu, Mar 10, 2005 at 03:40:11PM -0700, Steven Cole wrote:
I'll test current bk tonight, but I don't see any recent fix to
drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6.
Ok, so Stephen's bug is already fixed. After testing the latest bk, if
you find your bug isn't resolved, please try to isolate the change by
applying this patch. If this doesn't resolve it, then your change of
behaviour hasn't been caused by changes to 8250.c, but must be down to
some other part of the kernel.
= linux-2.6-rmk/drivers/serial/8250.c 1.97 vs 1.95 =
--- 1.97/drivers/serial/8250.c2005-03-08 10:04:55 +00:00
+++ 1.95/drivers/serial/8250.c2005-02-28 16:05:18 +00:00
@@ -642,7 +642,6 @@
static void autoconfig_16550a(struct uart_8250_port *up)
{
unsigned char status1, status2;
- unsigned int iersave;
up-port.type = PORT_16550A;
up-capabilities |= UART_CAP_FIFO;
@@ -729,7 +728,6 @@
serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO | UART_FCR7_64BYTE);
status2 = serial_in(up, UART_IIR) 5;
serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
- serial_outp(up, UART_LCR, 0);
DEBUG_AUTOCONF(iir1=%d iir2=%d , status1, status2);
@@ -738,40 +736,6 @@
up-capabilities |= UART_CAP_AFE | UART_CAP_SLEEP;
return;
}
-
- /*
- * Try writing and reading the UART_IER_UUE bit (b6).
- * If it works, this is probably one of the Xscale platform's
- * internal UARTs.
- * We're going to explicitly set the UUE bit to 0 before
- * trying to write and read a 1 just to make sure it's not
- * already a 1 and maybe locked there before we even start start.
- */
- iersave = serial_in(up, UART_IER);
- serial_outp(up, UART_IER, iersave ~UART_IER_UUE);
- if (!(serial_in(up, UART_IER) UART_IER_UUE)) {
- /*
- * OK it's in a known zero state, try writing and reading
- * without disturbing the current state of the other bits.
- */
- serial_outp(up, UART_IER, iersave | UART_IER_UUE);
- if (serial_in(up, UART_IER) UART_IER_UUE) {
- /*
- * It's an Xscale.
- * We'll leave the UART_IER_UUE bit set to 1 (enabled).
- */
- DEBUG_AUTOCONF(Xscale );
- up-port.type = PORT_XSCALE;
- return;
- }
- } else {
- /*
- * If we got here we couldn't force the IER_UUE bit to 0.
- * Log it and continue.
- */
- DEBUG_AUTOCONF(Couldn't force IER_UUE to 0 );
- }
- serial_outp(up, UART_IER, iersave);
}
/*
I am currently doing a bk pull from linux.bkbits.net/linux-2.6, and can test
the above
patch if dialup via a serial modem breaks again, but I think I already know the
answer.
I first noticed this _after_ the last one-line change to drivers/serial/8250.c.
Last night, after establishing that 2.6.11-bk1 was the earliest kernel to have
the problem,
and reverting the Xscale patch fixed it, I tried with last night's bk-current.
It also failed as previously described, and worked with the Xscale patch
reverted.
Here is a snippet from dmesg from my current kernel (with Xscale reverted)
working
on dialup.via serial modem.
[ 43.034336] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 43.034520] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 43.034616] Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing
disabled
[ 43.034924] ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 43.038087] pnp: Device 00:01.00 activated.
[ 43.038329] ttyS1 at I/O 0x2f8 (irq = 10) is a 16550A
For completeness, here is the patch I applied with patch -p1 -R:
Steven
diff -Nru a/drivers/serial/8250.c b/drivers/serial/8250.c
--- a/drivers/serial/8250.c 2005-02-28 08:05:18 -08:00
+++ b/drivers/serial/8250.c 2005-01-24 08:00:57 -08:00
@@ -642,6 +642,7 @@
static void autoconfig_16550a(struct uart_8250_port *up)
{
unsigned char status1, status2;
+ unsigned int iersave;
up-port.type = PORT_16550A;
up-capabilities |= UART_CAP_FIFO;
@@ -736,6 +737,40 @@
up-capabilities |= UART_CAP_AFE | UART_CAP_SLEEP;
return;
}
+
+ /*
+ * Try writing and reading the UART_IER_UUE bit (b6).
+ * If it works, this is probably one of the Xscale platform's
+ * internal UARTs.
+ * We're going to explicitly set the UUE bit to 0 before
+ * trying to write and read a 1 just to make sure it's not
+ * already a 1 and maybe locked there before we even start start.
+ */
+ iersave = serial_in(up, UART_IER);
+ serial_outp(up, UART_IER, iersave ~UART_IER_UUE);
+ if (!(serial_in(up, UART_IER) UART_IER_UUE)) {
+ /*
+ * OK it's in a known zero state, try writing and reading
+ * without disturbing the current
[07/11] ppc32: trivial fix for e500 oprofile build
-stable review patch. If anyone has any objections, please let us know.
--
Fix for trivial fix for 2.6.11 oprofile compilation on e500 based ppc.
Signed-off-by: Andy Fleming [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
diff -Nru a/arch/ppc/oprofile/op_model_fsl_booke.c
b/arch/ppc/oprofile/op_model_fsl_booke.c
--- a/arch/ppc/oprofile/op_model_fsl_booke.c2005-03-04 13:02:52 -06:00
+++ b/arch/ppc/oprofile/op_model_fsl_booke.c2005-03-04 13:02:52 -06:00
@@ -150,7 +150,6 @@
int is_kernel;
int val;
int i;
- unsigned int cpu = smp_processor_id();
/* set the PMM bit (see comment below) */
mtmsr(mfmsr() | MSR_PMM);
@@ -162,7 +161,7 @@
val = ctr_read(i);
if (val 0) {
if (oprofile_running ctr[i].enabled) {
- oprofile_add_sample(pc, is_kernel, i, cpu);
+ oprofile_add_pc(pc, is_kernel, i);
ctr_write(i, reset_value[i]);
} else {
ctr_write(i, 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/
[09/11] r8169: receive descriptor length fix
-stable review patch. If anyone has any objections, please let us know.
--
The status and received packets indication in the Rx descriptor ring
are not correctly reset when a descriptor is recycled.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
diff -puN drivers/net/r8169.c~r8169-490 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-490 2005-03-08 00:01:26.0 +0100
+++ b/drivers/net/r8169.c 2005-03-09 00:38:34.235464833 +0100
@@ -1683,16 +1683,19 @@ static void rtl8169_free_rx_skb(struct r
rtl8169_make_unusable_by_asic(desc);
}
-static inline void rtl8169_return_to_asic(struct RxDesc *desc, int rx_buf_sz)
+static inline void rtl8169_mark_to_asic(struct RxDesc *desc, u32 rx_buf_sz)
{
- desc-opts1 |= cpu_to_le32(DescOwn + rx_buf_sz);
+ u32 eor = le32_to_cpu(desc-opts1) RingEnd;
+
+ desc-opts1 = cpu_to_le32(DescOwn | eor | rx_buf_sz);
}
-static inline void rtl8169_give_to_asic(struct RxDesc *desc, dma_addr_t
mapping,
- int rx_buf_sz)
+static inline void rtl8169_map_to_asic(struct RxDesc *desc, dma_addr_t mapping,
+ u32 rx_buf_sz)
{
desc-addr = cpu_to_le64(mapping);
- desc-opts1 |= cpu_to_le32(DescOwn + rx_buf_sz);
+ wmb();
+ rtl8169_mark_to_asic(desc, rx_buf_sz);
}
static int rtl8169_alloc_rx_skb(struct pci_dev *pdev, struct sk_buff **sk_buff,
@@ -1712,7 +1715,7 @@ static int rtl8169_alloc_rx_skb(struct p
mapping = pci_map_single(pdev, skb-tail, rx_buf_sz,
PCI_DMA_FROMDEVICE);
- rtl8169_give_to_asic(desc, mapping, rx_buf_sz);
+ rtl8169_map_to_asic(desc, mapping, rx_buf_sz);
out:
return ret;
@@ -2150,7 +2153,7 @@ static inline int rtl8169_try_rx_copy(st
skb_reserve(skb, NET_IP_ALIGN);
eth_copy_and_sum(skb, sk_buff[0]-tail, pkt_size, 0);
*sk_buff = skb;
- rtl8169_return_to_asic(desc, rx_buf_sz);
+ rtl8169_mark_to_asic(desc, rx_buf_sz);
ret = 0;
}
}
_
--
Ueimor
-
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/
[03/11] drm missing memset can crash X server..
-stable review patch. If anyone has any objections, please let us know. -- Egbert Eich reported a bug 2673 on bugs.freedesktop.org and tracked it down to a missing memset in the setversion ioctl, this causes X server crashes... From: Egbert Eich [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] Signed-off-by: Chris Wright [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] diff -Nru a/drivers/char/drm/drm_ioctl.c b/drivers/char/drm/drm_ioctl.c --- a/drivers/char/drm/drm_ioctl.c 2005-03-09 10:53:42 +11:00 +++ b/drivers/char/drm/drm_ioctl.c 2005-03-09 10:53:43 +11:00 @@ -326,6 +326,8 @@ DRM_COPY_FROM_USER_IOCTL(sv, argp, sizeof(sv)); + memset(version, 0, sizeof(version)); + dev-driver-version(version); retv.drm_di_major = DRM_IF_MAJOR; retv.drm_di_minor = DRM_IF_MINOR; - 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/
oops / 2.6.11 / run_timer_softirq (mountvirtfs)
On an VIA EPIA board, I got this single oops at boot. Wasn't stored on file so I had to take a screenshot with a digital camera. Basicallly goes along those lines: Process: S36mountvirtfs Call trace: run_timer_softirq+0x16f/0x200 __do_softirq do_softirq irq_exit do_IRQ common_interrupt Process is found here on my system: lrwxr-xr-x 1 root root 21 Mar 1 00:29 /etc/rcS.d/S36mountvirtfs - ../init.d/mountvirtfs The exact screenshot (500k) can be found here: http://coffeebreaks.dyndns.org/~jerome/static/images/linux/oops_2.6.11_run_timer_softirq_boot.jpg I can spend time copying the input into a file and doing the ksymoops stuff if someone wants to get it. Otherwise I will go back to try fixing the other problems that happens much more often... J - 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, RFC 3/3] Use sem_getcount in xfs
Convert XFS to use sem_getcount instead of nasty hack. Should fix warning
with XFS debugging on PARISC. Untested since there is no obvious way to
turn on XFS debugging.
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: 1394-dev/fs/xfs/linux-2.6/xfs_buf.c
===
--- 1394-dev.orig/fs/xfs/linux-2.6/xfs_buf.c2005-03-10 18:20:13.0
-0500
+++ 1394-dev/fs/xfs/linux-2.6/xfs_buf.c 2005-03-10 18:20:55.0 -0500
@@ -976,7 +976,7 @@ int
pagebuf_lock_value(
xfs_buf_t *pb)
{
- return(atomic_read(pb-pb_sema.count));
+ return(sem_getcount(pb-pb_sema));
}
#endif
-
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, RFC 2/3] Use sem_getcount in ieee1394
Convert 1394's node manager to use sem_getcount instead of nasty hack.
Tested on parisc (where it eliminates a warning), ia64, i386.
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: 1394-dev/drivers/ieee1394/nodemgr.c
===
--- 1394-dev.orig/drivers/ieee1394/nodemgr.c2005-03-08 16:50:40.0
-0500
+++ 1394-dev/drivers/ieee1394/nodemgr.c 2005-03-08 16:51:07.0 -0500
@@ -284,7 +284,7 @@ static DEVICE_ATTR(bus_options,S_IRUGO,f
static ssize_t fw_show_ne_tlabels_free(struct device *dev, char *buf)
{
struct node_entry *ne = container_of(dev, struct node_entry, device);
- return sprintf(buf, %d\n, atomic_read(ne-tpool-count.count) + 1);
+ return sprintf(buf, %d\n, sem_getcount(ne-tpool-count) + 1);
}
static DEVICE_ATTR(tlabels_free,S_IRUGO,fw_show_ne_tlabels_free,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/
[06/11] [TCP]: Put back tcp_timer_bug_msg[] symbol export.
-stable review patch. If anyone has any objections, please let us know. -- This wrecks the ipv6 modular build for a lot of people. In fact, since I always build ipv6 modular I am surprised I never hit this. My best guess is that my compiler is optimizing the reference away, but that can never be depended upon and the symbol export really is needed. [TCP]: Put back tcp_timer_bug_msg[] symbol export. It is needed for tcp_reset_xmit_timer(), which is invoked by tcp_prequeue() which is invoked from tcp_ipv6.c Signed-off-by: Hideaki YOSHIFUJI [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] Signed-off-by: Chris Wright [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] diff -Nru a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c --- a/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00 +++ b/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00 @@ -38,6 +38,7 @@ #ifdef TCP_DEBUG const char tcp_timer_bug_msg[] = KERN_DEBUG tcpbug: unknown timer value\n; +EXPORT_SYMBOL(tcp_timer_bug_msg); #endif /* - 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, RFC 1/3] Add sem_getcount() to arches that lack it
parisc and frv define sem_getcount() in semaphore.h, which returns the
current semaphore value. This is cleaner than doing
atomic_read(semaphore.count), currently done in
drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work
on all architectures if sem_getcount() is added.
This patch adds sem_getcount(). I will also send patches that convert
ieee1394 and xfs to use sem_getcount(), which fixes a warning on parisc
(and presumably frv.)
Any objections?
Jody
--
Adds sem_getcount() to architectures that were missing it. Renames
sema_count on arm for this purpose (sema_count has no current callers.)
Tested on i386, ia64, parisc.
Signed-off-by: Jody McIntyre [EMAIL PROTECTED]
Index: 1394-dev/include/asm-h8300/semaphore.h
===
--- 1394-dev.orig/include/asm-h8300/semaphore.h 2005-02-10 12:39:28.0
-0500
+++ 1394-dev/include/asm-h8300/semaphore.h 2005-03-08 16:38:06.0
-0500
@@ -59,6 +59,11 @@ static inline void init_MUTEX_LOCKED (st
sema_init(sem, 0);
}
+static inline int sem_getcount(struct semaphore *sem)
+{
+ return atomic_read(sem-count);
+}
+
asmlinkage void __down_failed(void /* special register calling convention */);
asmlinkage int __down_failed_interruptible(void /* params in registers */);
asmlinkage int __down_failed_trylock(void /* params in registers */);
Index: 1394-dev/include/asm-sh64/semaphore.h
===
--- 1394-dev.orig/include/asm-sh64/semaphore.h 2005-02-10 12:39:41.0
-0500
+++ 1394-dev/include/asm-sh64/semaphore.h 2005-03-08 16:42:14.0
-0500
@@ -72,6 +72,11 @@ static inline void init_MUTEX_LOCKED (st
sema_init(sem, 0);
}
+static inline int sem_getcount(struct semaphore *sem)
+{
+ return atomic_read(sem-count);
+}
+
#if 0
asmlinkage void __down_failed(void /* special register calling convention */);
asmlinkage int __down_failed_interruptible(void /* params in registers */);
Index: 1394-dev/include/asm-m68knommu/semaphore.h
===
--- 1394-dev.orig/include/asm-m68knommu/semaphore.h 2005-02-10
12:39:29.0 -0500
+++ 1394-dev/include/asm-m68knommu/semaphore.h 2005-03-08 16:39:18.0
-0500
@@ -59,6 +59,11 @@ static inline void init_MUTEX_LOCKED (st
sema_init(sem, 0);
}
+static inline int sem_getcount(struct semaphore *sem)
+{
+ return atomic_read(sem-count);
+}
+
asmlinkage void __down_failed(void /* special register calling convention */);
asmlinkage int __down_failed_interruptible(void /* params in registers */);
asmlinkage int __down_failed_trylock(void /* params in registers */);
Index: 1394-dev/include/asm-m32r/semaphore.h
===
--- 1394-dev.orig/include/asm-m32r/semaphore.h 2005-02-10 12:39:28.0
-0500
+++ 1394-dev/include/asm-m32r/semaphore.h 2005-03-08 16:38:26.0
-0500
@@ -64,6 +64,11 @@ static inline void init_MUTEX_LOCKED (st
sema_init(sem, 0);
}
+static inline int sem_getcount(struct semaphore *sem)
+{
+ return atomic_read(sem-count);
+}
+
asmlinkage void __down_failed(void /* special register calling convention */);
asmlinkage int __down_failed_interruptible(void /* params in registers */);
asmlinkage int __down_failed_trylock(void /* params in registers */);
Index: 1394-dev/include/asm-ia64/semaphore.h
===
--- 1394-dev.orig/include/asm-ia64/semaphore.h 2005-02-10 12:39:28.0
-0500
+++ 1394-dev/include/asm-ia64/semaphore.h 2005-03-08 16:38:21.0
-0500
@@ -50,6 +50,11 @@ init_MUTEX_LOCKED (struct semaphore *sem
sema_init(sem, 0);
}
+static inline int sem_getcount(struct semaphore *sem)
+{
+ return atomic_read(sem-count);
+}
+
extern void __down (struct semaphore * sem);
extern int __down_interruptible (struct semaphore * sem);
extern int __down_trylock (struct semaphore * sem);
Index: 1394-dev/include/asm-i386/semaphore.h
===
--- 1394-dev.orig/include/asm-i386/semaphore.h 2005-02-10 12:39:28.0
-0500
+++ 1394-dev/include/asm-i386/semaphore.h 2005-03-08 16:13:56.0
-0500
@@ -87,6 +87,13 @@ static inline void init_MUTEX_LOCKED (st
sema_init(sem, 0);
}
+typedef atomic_t semcount_t;
+
+static inline int sem_getcount(struct semaphore *sem)
+{
+ return atomic_read(sem-count);
+}
+
fastcall void __down_failed(void /* special register calling convention */);
fastcall int __down_failed_interruptible(void /* params in registers */);
fastcall int __down_failed_trylock(void /* params in registers */);
Index: 1394-dev/include/asm-sparc/semaphore.h
===
---
Re: binary drivers and development
On Thu, 10 Mar 2005, John Richard Moser wrote: A Linux specific binary driver format might be more useful, No, it wouldn't. I can use a source code driver on x86, x86-64 and PPC64 systems, but a binary driver is only usable on the architecture it was compiled for. Source code is way more portable than binary anything. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - 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: IrDA patches for 2.6.12-rc1
On Fri, 4 Mar 2005 16:23:39 -0800 Jean Tourrilhes [EMAIL PROTECTED] wrote: More trivial fixes in various places of the IrDA stack and driver, no biggies. Freshly tested on 2.6.11, most have been on my web pages for a while. This should go in 2.6.12-rc1. All applied, thanks Jean. - 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] -stable, how it's going to work.
On Thursday March 10, [EMAIL PROTECTED] wrote: On Thu, Mar 10, 2005 at 09:00:51PM +1100, Neil Brown wrote: On Tuesday March 8, [EMAIL PROTECTED] wrote: So here's a first cut at how this 2.6 -stable release process is going to work that Chris and I have come up with. Does anyone have any problems/issues/questions with this? One rule that I thought would make sense, but that I don't see listed is: - must fix a regression That, and a zillion other specific wordings that people suggested fall under the: or some oh, that's not good issue rule. I didn't feel like being all lawyer-like and explicitly spelling out all of the different kinds of bugs that we would be accepting patches for :) So yes, I don't have a problem with patches to fix regressions. I think you did not get the meaning that I was trying to convey... I didn't mean If it fixes a regression, it should be accepted. I meant If it does not fix a regression, it should not be accepted. I have the impression that the 2.6.x.y series were suggested because of regressions in 2.6.11 over 2.6.10 and we needed a way to respond to that. I think it should purely be a response to that. The issue that made me think through this is the locking bug in nfs (there is a significant delay in getting a contended lock after the holder drops it). It has been suggested at least twice for 2.6.11.y. While it would be nice to have it fixed, I really don't think it should be a candidate for 2.6.11.y. It should go into 2.6.12 (which it will) and that should be released 6-10 weeks post 2.6.11 which, given the bug as been around for a lot longer than that without being widely noticed, should be soon enough. I fear that if too many bug fixes go into 2.6.11.y, it might seem to take the pressure of 2.6.12 coming out in a timely fashion, and I wouldn't like to see that. NeilBrown - 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-inline sched functions
This could be part of the unknown 2% performance regression with
db transaction processing benchmark.
The four functions in the following patch use to be inline. They
are un-inlined since 2.6.7.
We measured that by re-inline them back on 2.6.9, it improves performance
for db transaction processing benchmark, +0.2% (on real hardware :-)
The cost is certainly larger kernel size, cost 928 bytes on x86, and
2728 bytes on ia64. But certainly worth the money for enterprise
customer since they improve performance on enterprise workload.
# size vmlinux.*
textdata bss dec hex filename
3261844 717184 262020 4241048 40b698 vmlinux.x86.orig
3262772 717488 262020 4242280 40bb68 vmlinux.x86.inline
textdata bss dec hex filename
5836933 903828 201940 6942701 69efed vmlinux.ia64.orig
5839661 903460 201940 6945061 69f925 vmlinux.ia64.inline
Possible we can introduce them back?
Signed-off-by: Ken Chen [EMAIL PROTECTED]
--- linux-2.6.11/kernel/sched.c.orig2005-03-10 15:31:10.0 -0800
+++ linux-2.6.11/kernel/sched.c 2005-03-10 15:36:32.0 -0800
@@ -164,7 +164,7 @@
#define SCALE_PRIO(x, prio) \
max(x * (MAX_PRIO - prio) / (MAX_USER_PRIO/2), MIN_TIMESLICE)
-static unsigned int task_timeslice(task_t *p)
+static inline unsigned int task_timeslice(task_t *p)
{
if (p-static_prio NICE_TO_PRIO(0))
return SCALE_PRIO(DEF_TIMESLICE*4, p-static_prio);
@@ -302,7 +302,7 @@ static DEFINE_PER_CPU(struct runqueue, r
* interrupts. Note the ordering: we can safely lookup the task_rq without
* explicitly disabling preemption.
*/
-static runqueue_t *task_rq_lock(task_t *p, unsigned long *flags)
+static inline runqueue_t *task_rq_lock(task_t *p, unsigned long *flags)
__acquires(rq-lock)
{
struct runqueue *rq;
@@ -426,7 +426,7 @@ struct file_operations proc_schedstat_op
/*
* rq_lock - lock a given runqueue and disable interrupts.
*/
-static runqueue_t *this_rq_lock(void)
+static inline runqueue_t *this_rq_lock(void)
__acquires(rq-lock)
{
runqueue_t *rq;
@@ -1323,7 +1323,7 @@ void fastcall sched_exit(task_t * p)
* with the lock held can cause deadlocks; see schedule() for
* details.)
*/
-static void finish_task_switch(task_t *prev)
+static inline void finish_task_switch(task_t *prev)
__releases(rq-lock)
{
runqueue_t *rq = this_rq();
-
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: oom with 2.6.11
Christian Kujau [EMAIL PROTECTED] wrote: i was going to compile 2.6.11-rc5-bk4, to sort out the bad kernel. compiling went fine. ok, finished some email, ok, suddenly my swap was used up again, and no memory left - uh oh! OOM again, with 2.6.11-rc5-bk2! Well if you ran out of swap then yes, the oom-killer will visit you. Why did you run out of swapspace? - 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: re-inline sched functions
Chen, Kenneth W [EMAIL PROTECTED] wrote: This could be part of the unknown 2% performance regression with db transaction processing benchmark. The four functions in the following patch use to be inline. They are un-inlined since 2.6.7. We measured that by re-inline them back on 2.6.9, it improves performance for db transaction processing benchmark, +0.2% (on real hardware :-) The cost is certainly larger kernel size, cost 928 bytes on x86, and 2728 bytes on ia64. But certainly worth the money for enterprise customer since they improve performance on enterprise workload. Less that 1k on x86 versus 2k on ia64. No wonder those things have such big caches ;) ... Possible we can introduce them back? OK by me. - 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: [PPC64] Allow emulation of mfpvr on ppc64 kernel
On Thu, Mar 10, 2005 at 11:17:03PM +0100, Ingo Oeser wrote: David Gibson wrote: Andrew, please apply. Allow userspace programs on ppc64 to use the (privileged) mfpvr instruction to determine the processor type. At the moment it emulates the instruction to provide the real PVR value, though it could be made to lie in future if for some reason we wish to restrict what CPU features userspace uses. Why not putting the required information into the AUX table when executing your ELF programs? I loved this feature in the ix86 arch. Because this is easy and is the way we already do it on ppc32..? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson - 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 4/5] audit mips fix
Hi Ralf,
On Thu, 10 Mar 2005 17:14:29 +
Ralf Baechle [EMAIL PROTECTED] wrote:
On Fri, Mar 04, 2005 at 01:16:57PM -0800, [EMAIL PROTECTED] wrote:
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
@@ -307,7 +308,7 @@ asmlinkage void do_syscall_trace(struct
{
if (unlikely(current-audit_context)) {
if (!entryexit)
- audit_syscall_entry(current, regs-orig_eax,
+ audit_syscall_entry(current, regs-regs[2],
Wrong. regs[2] can will contain the syscall return value and can be
modified by ptrace also.
Thank you for your comment,
I consider a good way based on your comment.
Do you already have a good idea?
Yoichi
-
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: [AGPGART] Map the graphic card to the bridge its connected to.
On Fri, 2005-03-11 at 10:02 +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-02-23 at 02:25 +, Linux Kernel Mailing List wrote: ChangeSet 1.1982.82.19, 2005/02/22 21:25:33-05:00, [EMAIL PROTECTED] [AGPGART] Map the graphic card to the bridge its connected to. Signed-off-by: Dave Jones [EMAIL PROTECTED] Note that the effect of reverting the patch gets a broken result too (btw... the code had a spurrious pci_dev_put() too ...) Anyway, paulus is working on a solution that should be good enough for both cases where the AGP bridge is a sibling of the device, and where the bridge is a parent of the device. Patch soon... 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/
Re: [PATCH] add a clear_pages function to clear pages of higher order
Changelog:
- use Kconfig and CONFIG_CLEAR_PAGES
The zeroing of a page of a arbitrary order in page_alloc.c and in hugetlb.c may
benefit from a
clear_page that is capable of zeroing multiple pages at once. The following
patch adds
a function clear_pages that is capable of clearing multiple continuous pages
at once.
Patch against 2.6.11-bk6
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Index: linux-2.6.11/mm/page_alloc.c
===
--- linux-2.6.11.orig/mm/page_alloc.c 2005-03-10 14:42:43.0 -0800
+++ linux-2.6.11/mm/page_alloc.c2005-03-10 15:01:53.0 -0800
@@ -628,11 +628,19 @@ void fastcall free_cold_page(struct page
free_hot_cold_page(page, 1);
}
-static inline void prep_zero_page(struct page *page, int order, int gfp_flags)
+void prep_zero_page(struct page *page, unsigned int order, unsigned int
gfp_flags)
{
int i;
BUG_ON((gfp_flags (__GFP_WAIT | __GFP_HIGHMEM)) == __GFP_HIGHMEM);
+
+#ifdef CONFIG_CLEAR_PAGES
+ if (!PageHighMem(page)) {
+ clear_pages(page_address(page), order);
+ return;
+ }
+#endif
+
for(i = 0; i (1 order); i++)
clear_highpage(page + i);
}
Index: linux-2.6.11/mm/hugetlb.c
===
--- linux-2.6.11.orig/mm/hugetlb.c 2005-03-01 23:38:12.0 -0800
+++ linux-2.6.11/mm/hugetlb.c 2005-03-10 15:01:53.0 -0800
@@ -78,7 +78,6 @@ void free_huge_page(struct page *page)
struct page *alloc_huge_page(void)
{
struct page *page;
- int i;
spin_lock(hugetlb_lock);
page = dequeue_huge_page();
@@ -89,8 +88,7 @@ struct page *alloc_huge_page(void)
spin_unlock(hugetlb_lock);
set_page_count(page, 1);
page[1].mapping = (void *)free_huge_page;
- for (i = 0; i (HPAGE_SIZE/PAGE_SIZE); ++i)
- clear_highpage(page[i]);
+ prep_zero_page(page, HUGETLB_PAGE_ORDER, GFP_HIGHUSER);
return page;
}
Index: linux-2.6.11/include/asm-ia64/page.h
===
--- linux-2.6.11.orig/include/asm-ia64/page.h 2005-03-01 23:37:48.0
-0800
+++ linux-2.6.11/include/asm-ia64/page.h2005-03-10 15:02:47.0
-0800
@@ -56,8 +56,9 @@
# ifdef __KERNEL__
# define STRICT_MM_TYPECHECKS
-extern void clear_page (void *page);
+extern void clear_pages (void *page, int order);
extern void copy_page (void *to, void *from);
+#define clear_page(__page) clear_pages(__page, 0)
/*
* clear_user_page() and copy_user_page() can't be inline functions because
Index: linux-2.6.11/arch/ia64/kernel/ia64_ksyms.c
===
--- linux-2.6.11.orig/arch/ia64/kernel/ia64_ksyms.c 2005-03-01
23:38:08.0 -0800
+++ linux-2.6.11/arch/ia64/kernel/ia64_ksyms.c 2005-03-10 15:01:53.0
-0800
@@ -38,7 +38,7 @@ EXPORT_SYMBOL(__down_trylock);
EXPORT_SYMBOL(__up);
#include asm/page.h
-EXPORT_SYMBOL(clear_page);
+EXPORT_SYMBOL(clear_pages);
#ifdef CONFIG_VIRTUAL_MEM_MAP
#include linux/bootmem.h
Index: linux-2.6.11/arch/ia64/lib/clear_page.S
===
--- linux-2.6.11.orig/arch/ia64/lib/clear_page.S2005-03-01
23:37:47.0 -0800
+++ linux-2.6.11/arch/ia64/lib/clear_page.S 2005-03-10 15:01:53.0
-0800
@@ -7,6 +7,7 @@
* 1/06/01 davidm Tuned for Itanium.
* 2/12/02 kchen Tuned for both Itanium and McKinley
* 3/08/02 davidm Some more tweaking
+ * 12/10/04 clameter Make it work on pages of order size
*/
#include linux/config.h
@@ -29,27 +30,33 @@
#define dst4 r11
#define dst_last r31
+#define totsizer14
-GLOBAL_ENTRY(clear_page)
+GLOBAL_ENTRY(clear_pages)
.prologue
- .regstk 1,0,0,0
- mov r16 = PAGE_SIZE/L3_LINE_SIZE-1 // main loop count,
-1=repeat/until
+ .regstk 2,0,0,0
+ mov r16 = PAGE_SIZE/L3_LINE_SIZE// main loop count
+ mov totsize = PAGE_SIZE
.save ar.lc, saved_lc
mov saved_lc = ar.lc
-
+ ;;
.body
+ adds dst1 = 16, in0
mov ar.lc = (PREFETCH_LINES - 1)
mov dst_fetch = in0
- adds dst1 = 16, in0
adds dst2 = 32, in0
+ shl r16 = r16, in1
+ shl totsize = totsize, in1
;;
.fetch:stf.spill.nta [dst_fetch] = f0, L3_LINE_SIZE
adds dst3 = 48, in0 // executing this multiple times is
harmless
br.cloop.sptk.few .fetch
+ add r16 = -1,r16
+ add dst_last = totsize, dst_fetch
+ adds dst4 = 64, in0
;;
- addl dst_last = (PAGE_SIZE - PREFETCH_LINES*L3_LINE_SIZE), dst_fetch
mov ar.lc = r16 // one L3 line per iteration
- adds dst4 = 64, in0
+ adds dst_last = -PREFETCH_LINES*L3_LINE_SIZE, dst_last
Re: Someting's busted with serial in 2.6.11 latest
On Thursday 10 March 2005 03:59 pm, Russell King wrote: On Thu, Mar 10, 2005 at 03:40:11PM -0700, Steven Cole wrote: I'll test current bk tonight, but I don't see any recent fix to drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6. Ok, so Stephen's bug is already fixed. After testing the latest bk, if you find your bug isn't resolved, please try to isolate the change by applying this patch. If this doesn't resolve it, then your change of behaviour hasn't been caused by changes to 8250.c, but must be down to some other part of the kernel. OK, latest 2.6.11-bk works just fine. Although I thought I had a failure with a fairly recent snapshot, I must have had a version before the fix. Sorry for any confusion. FWIW, the failing kernels reported: ttyS0 at I/O 0x3f8 (irq = 4) is a XScale But now, all is fine. Thanks. Steven - 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: oom with 2.6.11
Andrew Morton wrote: Christian Kujau [EMAIL PROTECTED] wrote: i was going to compile 2.6.11-rc5-bk4, to sort out the bad kernel. compiling went fine. ok, finished some email, ok, suddenly my swap was used up again, and no memory left - uh oh! OOM again, with 2.6.11-rc5-bk2! Well if you ran out of swap then yes, the oom-killer will visit you. Why did you run out of swapspace? hm, if i only knew. i don't know how long it took the other night to go from normal to OOM. but today, with 2.6.11-rc5-bk2 (well, yesterday actually) i was working normally, and all of a sudden swap goes from 170MB used swap (normal) to OOM. i think it took a minute or so, but i just can't tell which application went nuts. today the first process that got killed was ssh-agent, the other day it was mysqld. but even after this, it should've released some memory, right? but the oom-killer goes on and on and kills the next task. i'll monitor memory usage tonight and see what it gives. these pppd messages are suspicious though. thank you, Christian. -- BOFH excuse #135: You put the disk in upside down. - 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.11-mm2 + Radeon crash
When I try to start X, my machine reboots. The screen goes dark as usual when setting the video mode, but then I get a beep and I'm greeted with the BIOS boot messages. This happened 4/5 times i've tried, and once the video mode was actually set (at least I saw the usual X b/w pattern with some random framebuffer garbage), the machine didn't reboot but after that nothing happened. My keyboard was still responsive (ie NumLock LED would still go on/off), but i could neither kill X with CTRL-ALT-BACKSPACE nor could i switch back to console, so I ended up pressing reset. After the crashes I booted with a rescue CD to examine the logs, but I could not find any obvious errors. Everything works nicely on 2.6.10 and earlier kernels. I'm in the process of building 2.6.11.2 to see if the crash occurs there. Here is some info on my system: I've got an Athlon 1000C on a VIA KT133 chipset and a Radeon 7200 (the original Radeon with 32MB SDR RAM). I'm running Debian/sid. A copy of /var/log/XFree86.0.log and a copy of dmesg and copy of your .config if you could .. main things of interest whether you have fb drivers and drm drivers.. 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/
AGP bogosities
Linus,
I see that you did a cset -x on a changeset from Dave Jones that added
a bogus test for which AGP bridge a device is under. That has left us
with code in agp_collect_device_status that will never find any device
(just take a look and you'll see).
In fact there are other bogosities in drivers/char/agp/generic.c. I
can't believe Dave ever tested that code with an AGP 3.0 device. If
you pass in a mode that has the AGP 3.0 bit set, agp_v3_parse_one()
will first clear that bit (and print a message), and then complain
because you haven't got that bit set in the mode, with a message that
the caller is broken. Furthermore, if the mode passed in has both the
4x and 8x bits set, the new code will give you 4x where the old code
would give you 8x (which is what the caller wanted).
The patch below fixes these problems. It will work in the 99.99% of
cases where we have one AGP bridge and one AGP video card. We should
eventually cope with multiple AGP bridges, but doing the matching of
bridges to video cards is a hard problem because the video card is not
necessarily a child or sibling of the PCI device that we use for
controlling the AGP bridge. I think we need to see an actual example
of a system with multiple AGP bridges first.
Oh, and by the way, I have 3D working relatively well on my G5 with a
64-bit kernel (and 32-bit X server and clients), which is why I care
about AGP 3.0 support. :)
Paul.
diff -urN linux-2.5/drivers/char/agp/agp.h g5-bad/drivers/char/agp/agp.h
--- linux-2.5/drivers/char/agp/agp.h2005-03-07 14:01:44.0 +1100
+++ g5/drivers/char/agp/agp.h 2005-03-11 11:54:54.0 +1100
@@ -322,7 +322,7 @@
#define AGPCTRL_GTLBEN (17)
#define AGP2_RESERVED_MASK 0x00fffcc8
-#define AGP3_RESERVED_MASK 0x00ff00cc
+#define AGP3_RESERVED_MASK 0x00ff00c4
#define AGP_ERRATA_FASTWRITES 10
#define AGP_ERRATA_SBA 11
diff -urN linux-2.5/drivers/char/agp/generic.c g5-bad/drivers/char/agp/generic.c
--- linux-2.5/drivers/char/agp/generic.c2005-03-11 11:47:37.0
+1100
+++ g5/drivers/char/agp/generic.c 2005-03-11 12:08:29.0 +1100
@@ -515,13 +515,9 @@
printk (KERN_INFO PFX %s tried to set rate=x0. Setting to AGP3
x4 mode.\n, current-comm);
*requested_mode |= AGPSTAT3_4X;
}
- if (tmp == 3) {
- printk (KERN_INFO PFX %s tried to set rate=x3. Setting to AGP3
x4 mode.\n, current-comm);
- *requested_mode |= AGPSTAT3_4X;
- }
- if (tmp 3) {
- printk (KERN_INFO PFX %s tried to set rate=x%d. Setting to
AGP3 x8 mode.\n, current-comm, tmp);
- *requested_mode |= AGPSTAT3_8X;
+ if (tmp = 3) {
+ printk (KERN_INFO PFX %s tried to set rate=x%d. Setting to
AGP3 x8 mode.\n, current-comm, tmp * 4);
+ *requested_mode = (*requested_mode ~7) | AGPSTAT3_8X;
}
/* ARQSZ - Set the value to the maximum one.
@@ -642,11 +638,6 @@
return 0;
}
cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
- if (!cap_ptr) {
- pci_dev_put(device);
- continue;
- }
- cap_ptr = 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: [01/11] fix amd64 2.6.11 oops on modprobe (saa7110)
On Thu, 2005-03-10 at 15:07 -0800, Greg KH wrote: -stable review patch. If anyone has any objections, please let us know. -- This is a rewrite of the saa7110_write_block function, which was plain broken in the case where the underlying adapter supports I2C_FUNC_I2C. It also includes related fixes which ensure that different parts of the driver agree on the number of registers the chip has. Signed-off-by: Jean Delvare [EMAIL PROTECTED] Signed-off-by: Chris Wright [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- linux-2.6.11-bk3/drivers/media/video/saa7110.c.orig Tue Mar 8 10:27:15 2005 +++ linux-2.6.11-bk3/drivers/media/video/saa7110.cTue Mar 8 12:02:45 2005 @@ -58,10 +58,12 @@ #define SAA7110_MAX_INPUT9 /* 6 CVBS, 3 SVHS */ #define SAA7110_MAX_OUTPUT 0 /* its a decoder only */ -#define I2C_SAA7110 0x9C/* or 0x9E */ +#define I2C_SAA7110 0x9C/* or 0x9E */ Not that I really care, but isn't there a rule that a patch ... can not contain any trivial fixes in it (spelling changes, whitespace cleanups, etc.)? josh - 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] Support for GEODE CPUs
So.. did we end up deciding that the Geode patch should be reverted wholesale? - 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] -stable, how it's going to work.
On Thursday March 10, [EMAIL PROTECTED] wrote: On Thu, 2005-03-10 at 21:00 +1100, Neil Brown wrote: One rule that I thought would make sense, but that I don't see listed is: - must fix a regression If some problem was in 2.6.X and is still there in 2.6.X+1, then there is no great rush to fix it for 2.6.(X+1).1, it can wait for 2.6.(X+2). this is tricky. I mean, what if it's a datacorruption thing? Sure older kernels may have it too... yet at the same time it'd be nice to get it fixed. And once you go down this slipperly slope you end up with the original ruleset again, eg it must be somehow relatively important. My position is that - there are lots of things that it'd be nice to get it fixed, and that is what 2.6.X is for - It is a very slippery slope - No one expect Linux to be perfect. But people do expect it to get better without getting worse. It is precisely to fix this expectation that (I understand) 2.6.x.y was created. If a data corruption bug has been there for 10 weeks without being noticed, then the real risk is not that great. We are calling it -release, not -hardened. Just my shilling-and-six worth. NeilBrown - 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: inode cache, dentry cache, buffer heads usage
Badari Pulavarty [EMAIL PROTECTED] wrote: So, why is these slab cache are not getting purged/shrinked even under memory pressure ? (I have seen lowmem as low as 6MB). What can I do to keep the machine healthy ? Tried increasing /proc/sys/vm/vfs_cache_pressure? (That might not be in 2.6.8 though). - 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.11 low latency audio test results
On Thursday 10 March 2005 16:52, Lee Revell wrote: On Wed, 2005-03-09 at 08:27 -0600, K.R. Foley wrote: Lee Revell wrote: Of course all of the above settings provide flawless xrun-free performance with 2.6.11-rc4 + PREEMPT_RT. The above mentioned patch will apply (and build and run) just fine to 2.6.11 if you fix the EXTRAVERSION portion of the patch to not expect -rc4. Right, it sure does. No rejects except the Makefile. Looks like the release candidate process is getting tighter. Lee Maybe Lee, maybe. It kills tvtime, I built that into 2.6.11.2 yesterday to test. So I'm back in 2.6.11.2 with only the bk-ieee1394.patch applied over the .1 and .2 patches. - 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/ -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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: AGP bogosities
On Fri, 11 Mar 2005, Paul Mackerras wrote: Oh, and by the way, I have 3D working relatively well on my G5 with a 64-bit kernel (and 32-bit X server and clients), which is why I care about AGP 3.0 support. :) Ok, I can't even compile it on my G5, so you're obviously withholding some patches you shouldn't ;) Anyway, I fixed up the AGP discovery differently from your patch, so you should check that my version works for you. DaveJ, please give it a once-over too, since my G5 doesn't do the AGP thing yet. 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/
Re: re-inline sched functions
Andrew Morton wrote: Chen, Kenneth W [EMAIL PROTECTED] wrote: This could be part of the unknown 2% performance regression with db transaction processing benchmark. The four functions in the following patch use to be inline. They are un-inlined since 2.6.7. We measured that by re-inline them back on 2.6.9, it improves performance for db transaction processing benchmark, +0.2% (on real hardware :-) Can you also inline requeue_task? No performance gain expected, but it is just a simple wrapper around a list function. The cost is certainly larger kernel size, cost 928 bytes on x86, and 2728 bytes on ia64. But certainly worth the money for enterprise customer since they improve performance on enterprise workload. Less that 1k on x86 versus 2k on ia64. No wonder those things have such big caches ;) ... Possible we can introduce them back? OK by me. What happens if you leave task_timeslice out of line? It isn't exactly huge, but it is called from a handful of places. - 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: AGP bogosities
On Thursday, March 10, 2005 5:24 pm, Paul Mackerras wrote: The patch below fixes these problems. It will work in the 99.99% of cases where we have one AGP bridge and one AGP video card. We should eventually cope with multiple AGP bridges, but doing the matching of bridges to video cards is a hard problem because the video card is not necessarily a child or sibling of the PCI device that we use for controlling the AGP bridge. I think we need to see an actual example of a system with multiple AGP bridges first. We have real systems with multiple AGP bridges out there already, so we'd like to see this fixed properly. I think this is Mike's code, Mike? Oh, and by the way, I have 3D working relatively well on my G5 with a 64-bit kernel (and 32-bit X server and clients), which is why I care about AGP 3.0 support. :) I have a system in my office with several gfx pipes on different AGP busses, and I'd like that to work well too! :) 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: AGP bogosities
Jesse Barnes writes: I have a system in my office with several gfx pipes on different AGP busses, and I'd like that to work well too! :) Interesting, could you post the output from lspci -v on that system? What is the relationship in the PCI device tree between the video cards and their bridges? Is there for instance only one AGP bridge per host bridge? Paul. - 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: AGP bogosities
On Thursday, March 10, 2005 6:11 pm, Paul Mackerras wrote: What is the relationship in the PCI device tree between the video cards and their bridges? Is there for instance only one AGP bridge per host bridge? I *think* a TIO (numalink-agp numalink-pci) has two AGP busses coming off of it... Interesting, could you post the output from lspci -v on that system? flatearth:~ # lspci -v :01:01.0 Co-processor: Silicon Graphics, Inc. IOC4 I/O controller (rev 4f) Flags: bus master, 66Mhz, medium devsel, latency 255, IRQ 60 Memory at c0080f20 (32-bit, non-prefetchable) :01:03.0 Class 0106: Vitesse Semiconductor VSC7174 PCI/PCI-X Serial ATA Host Bus Controller (rev 01) Subsystem: Vitesse Semiconductor VSC7174 PCI/PCI-X Serial ATA Host Bus Controller Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 61 Memory at c0080f30 (64-bit, non-prefetchable) Capabilities: [e0] PCI-X non-bridge device. Capabilities: [e8] Power Management version 2 Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/2 Enable- :01:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15) Subsystem: Silicon Graphics, Inc. SGI IO9/IO10 Gigabit Ethernet (Copper) Flags: bus master, 66Mhz, medium devsel, latency 48, IRQ 62 Memory at c0080f31 (64-bit, non-prefetchable) Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- :02:01.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE/SG (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Xpert 128 Flags: bus master, stepping, medium devsel, latency 64, IRQ 63 Memory at c008a400 (32-bit, prefetchable) [size=c0080fe2] I/O ports at c0080fa0 [size=256] Memory at c0080fe0 (32-bit, non-prefetchable) [size=16K] Expansion ROM at 0002 [disabled] Capabilities: [5c] Power Management version 1 :02:02.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Orange Micro Root Hub Flags: bus master, medium devsel, latency 8, IRQ 64 Memory at c0080fe04000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 :02:02.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Orange Micro Root Hub Flags: bus master, medium devsel, latency 8, IRQ 65 Memory at c0080fe05000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 :02:02.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI]) Subsystem: Orange Micro Root hub Flags: bus master, medium devsel, latency 68, IRQ 65 Memory at c0080fe06000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 :17:00.0 VGA compatible controller: ATI Technologies Inc R350 NK [Fire GL X2] (rev 80) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0152 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0, IRQ 67 Memory at c041c800 (32-bit, prefetchable) [size=c041c012] I/O ports at c04023001000 [size=256] Memory at c041c010 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 0002 [disabled] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 :17:00.1 Display controller: ATI Technologies Inc: Unknown device 4e6b (rev80) Subsystem: ATI Technologies Inc: Unknown device 0153 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0 Memory at c041d000 (32-bit, prefetchable) [size=c041c000] Memory at c041c011 (32-bit, non-prefetchable) [size=64K] Expansion ROM at unassigned Capabilities: [50] Power Management version 2 :1b:00.0 VGA compatible controller: ATI Technologies Inc R350 NK [Fire GL X2] (rev 80) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0152 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0, IRQ 66 Memory at c0c1c800 (32-bit, prefetchable) [size=c0c1c012] I/O ports at c0c023001000 [size=256] Memory at c0c1c010 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 0002 [disabled] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 :1b:00.1 Display controller: ATI Technologies Inc: Unknown device 4e6b (rev80) Subsystem: ATI Technologies Inc: Unknown device 0153 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0 Memory at
Re: AGP bogosities
On Fri, Mar 11, 2005 at 01:18:36PM +1100, Paul Mackerras wrote:
Dave Jones writes:
cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
- if (!cap_ptr) {
- pci_dev_put(device);
- continue;
- }
- cap_ptr = 0;
}
This part I'm not so sure about.
The pci_get_class() call a few lines above will get a refcount that
we will now never release.
The point is that pci_get_class does a pci_dev_put() on the from
parameter, so your code ended up doing a double put.
After it does that pci_dev_put on the from, it does another pci_dev_get
on 'dev', which is what my put was releasing.
Or am I terribly confused ?
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: Can I get 200M contiguous physical memory?
Chris Wedgwood wrote: it's driver in windows can do it. windows can get 200MB of memory on a running system relaibly? does it swap like mad when you do this? I'm guessing that driver isn't too likely to pass WHQL testing on Windows either, whatever it's doing.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: AGP bogosities
Dave Jones writes:
cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
- if (!cap_ptr) {
- pci_dev_put(device);
- continue;
- }
- cap_ptr = 0;
}
This part I'm not so sure about.
The pci_get_class() call a few lines above will get a refcount that
we will now never release.
The point is that pci_get_class does a pci_dev_put() on the from
parameter, so your code ended up doing a double put.
Unfortunatly, no-one with ppc64 tested it there it seems :-(
I have only recently got AGP and DRI working on my G5. I'll post a
patch for AGP support on the G5 shortly.
Paul.
-
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.11 on AMD64 traps
On Wed, 09 Mar 2005 20:45:35 +0100 Patrick McHardy [EMAIL PROTECTED] wrote: Michal Vanco wrote: I see this problem running 2.6.11 on dual AMD64: Running quagga routing daemon (ospf+bgp) and issuing netstat -rn |wc -l command while quagga tries to load more than 154000 routes from its bgp neighbours causes this trap: This patch should fix it. The crash is caused by stale pointers, the pointers in fib_iter_state are not reloaded after seq-stop() followed by seq-start(pos 0). Applied, thanks Patrick. - 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: [PPC64] Allow emulation of mfpvr on ppc64 kernel
Ingo Oeser writes: Why not putting the required information into the AUX table when executing your ELF programs? I loved this feature in the ix86 arch. We do put an AT_HWCAP entry in the aux table, which is a bitmap of features supported by the cpu. But for some applications, such as programming the performance monitor hardware, you need to know the specific CPU model and version, and this is a way to provide that information. Paul. - 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: AGP bogosities
On Fri, 11 Mar 2005, Paul Mackerras wrote: The point is that pci_get_class does a pci_dev_put() on the from parameter, so your code ended up doing a double put. Ahh, I missed that too. Hmm.. We seem to not have any tests for the counts becoming negative, and this would seem to be an easy mistake to make considering that both I and Dave did it. 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/
Re: AGP bogosities
This part I'm not so sure about. The pci_get_class() call a few lines above will get a refcount that we will now never release. We will ... on the next loop iteration when we call pci_get_class again. Thanks for taking a look at this. The absense of hardware to test on means I pretty much rely on feedback from inclusion in -mm to hear about problems like this before it hits mainline. Unfortunatly, no-one with ppc64 tested it there it seems :-( And ppc32, and probably others... I have seen AGP layed out differently in quite a few cases 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/
Re: AGP bogosities
On Thu, 10 Mar 2005, Dave Jones wrote:
/* ARQSZ - Set the value to the maximum one.
@@ -642,11 +638,6 @@
return 0;
}
cap_ptr = pci_find_capability(device, PCI_CAP_ID_AGP);
- if (!cap_ptr) {
- pci_dev_put(device);
- continue;
- }
- cap_ptr = 0;
}
This part I'm not so sure about.
The pci_get_class() call a few lines above will get a refcount that
we will now never release.
That's the part I rewrote in my version, I think that one is good.
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/
Re: AGP bogosities
After it does that pci_dev_put on the from, it does another pci_dev_get on 'dev', which is what my put was releasing. Or am I terribly confused ? Well, pci_get_class() put's the passed-in device and get's() the returned one. So if you run it in a loop, you should never have to either get or put. When you exit the loop with a valid pci_dev, though, you should definitely put() it after you're done with it, but this is something that should be done only for that specific instance and after you are finished with it... 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/
Re: [RFC] -stable, how it's going to work.
On Fri, Mar 11, 2005 at 11:10:37AM +1100, Neil Brown wrote: I didn't mean If it fixes a regression, it should be accepted. I meant If it does not fix a regression, it should not be accepted. ... Presumably with the obvious exception for security fixes.--b. - 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: AGP bogosities
On Fri, Mar 11, 2005 at 01:35:40PM +1100, Benjamin Herrenschmidt wrote: This part I'm not so sure about. The pci_get_class() call a few lines above will get a refcount that we will now never release. We will ... on the next loop iteration when we call pci_get_class again. Ohhh, duh. Yes. now I follow. 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/
[PATCH] AGP support for powermac G5
This patch adds AGP support for the U3 northbridge used in Apple G5
machines to drivers/char/agp/uninorth-agp.c. This patch is based on
earlier work by Jerome Glisse. With this patch, the driver works in
both ppc32 and ppc64 kernels.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
diff -urN linux-2.5/drivers/char/agp/Kconfig g5/drivers/char/agp/Kconfig
--- linux-2.5/drivers/char/agp/Kconfig 2005-03-07 14:01:44.0 +1100
+++ g5/drivers/char/agp/Kconfig 2005-03-11 13:53:47.0 +1100
@@ -1,6 +1,6 @@
config AGP
tristate /dev/agpgart (AGP Support) if !GART_IOMMU
- depends on ALPHA || IA64 || PPC32 || X86
+ depends on ALPHA || IA64 || PPC || X86
default y if GART_IOMMU
---help---
AGP (Accelerated Graphics Port) is a bus system mainly used to
@@ -146,11 +146,11 @@
default AGP
config AGP_UNINORTH
- tristate Apple UniNorth AGP support
+ tristate Apple UniNorth U3 AGP support
depends on AGP PPC_PMAC
help
This option gives you AGP support for Apple machines with a
- UniNorth bridge.
+ UniNorth or U3 (Apple G5) bridge.
config AGP_EFFICEON
tristate Transmeta Efficeon support
diff -urN linux-2.5/drivers/char/agp/uninorth-agp.c
g5/drivers/char/agp/uninorth-agp.c
--- linux-2.5/drivers/char/agp/uninorth-agp.c 2005-03-11 11:47:37.0
+1100
+++ g5/drivers/char/agp/uninorth-agp.c 2005-03-11 11:54:54.0 +1100
@@ -9,8 +9,23 @@
#include linux/delay.h
#include asm/uninorth.h
#include asm/pci-bridge.h
+#include asm/prom.h
#include agp.h
+/*
+ * NOTES for uninorth3 (G5 AGP) supports :
+ *
+ * There maybe also possibility to have bigger cache line size for
+ * agp (see pmac_pci.c and look for cache line). Need to be investigated
+ * by someone.
+ *
+ * PAGE size are hardcoded but this may change, see asm/page.h.
+ *
+ * Jerome Glisse [EMAIL PROTECTED]
+ */
+static int uninorth_rev;
+static int is_u3;
+
static int uninorth_fetch_size(void)
{
int i;
@@ -40,14 +55,20 @@
static void uninorth_tlbflush(struct agp_memory *mem)
{
+ u32 ctrl = UNI_N_CFG_GART_ENABLE;
+
+ if (is_u3)
+ ctrl |= U3_N_CFG_GART_PERFRD;
pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_INVAL);
- pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_ENABLE);
- pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_2xRESET);
- pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_ENABLE);
+ ctrl | UNI_N_CFG_GART_INVAL);
+ pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL, ctrl);
+
+ if (uninorth_rev = 0x30) {
+ pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
+ ctrl | UNI_N_CFG_GART_2xRESET);
+ pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
+ ctrl);
+ }
}
static void uninorth_cleanup(void)
@@ -57,14 +78,16 @@
pci_read_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL, tmp);
if (!(tmp UNI_N_CFG_GART_ENABLE))
return;
- pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_INVAL);
- pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
- 0);
- pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
- UNI_N_CFG_GART_2xRESET);
- pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
- 0);
+ tmp |= UNI_N_CFG_GART_INVAL;
+ pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL, tmp);
+ pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL, 0);
+
+ if (uninorth_rev = 0x30) {
+ pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
+ UNI_N_CFG_GART_2xRESET);
+ pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
+ 0);
+ }
}
static int uninorth_configure(void)
@@ -87,8 +110,21 @@
* the AGP aperture isn't mapped at bus physical address 0
*/
agp_bridge-gart_bus_addr = 0;
+#ifdef CONFIG_PPC64
+ /* Assume U3 or later on PPC64 systems */
+ /* high 4 bits of GART physical address go in UNI_N_CFG_AGP_BASE */
+ pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_AGP_BASE,
+ (agp_bridge-gatt_bus_addr 32) 0xf);
+#else
pci_write_config_dword(agp_bridge-dev,
UNI_N_CFG_AGP_BASE, agp_bridge-gart_bus_addr);
+#endif
+
+ if (is_u3) {
+ pci_write_config_dword(agp_bridge-dev,
+
Re: AGP bogosities
On Thu, 2005-03-10 at 18:18 -0800, Jesse Barnes wrote: On Thursday, March 10, 2005 6:11 pm, Paul Mackerras wrote: What is the relationship in the PCI device tree between the video cards and their bridges? Is there for instance only one AGP bridge per host bridge? I *think* a TIO (numalink-agp numalink-pci) has two AGP busses coming off of it... Interesting, could you post the output from lspci -v on that system? flatearth:~ # lspci -v .../... That one is even worse... from what I see in your lspci output, you have no bridge with AGP capability at all, and the various AGP devices are all siblings... Are you sure there is any real AGP slot in there ? I'm afraid we may have to do the card - bridge machine as a bridge specific function. At least the bridge driver can know how the HW for that specific bridge lays out the PCI view of the AGP slot. 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/
Re: AGP bogosities
On Fri, Mar 11, 2005 at 01:40:24PM +1100, Benjamin Herrenschmidt wrote: After it does that pci_dev_put on the from, it does another pci_dev_get on 'dev', which is what my put was releasing. Or am I terribly confused ? Well, pci_get_class() put's the passed-in device and get's() the returned one. So if you run it in a loop, you should never have to either get or put. When you exit the loop with a valid pci_dev, though, you should definitely put() it after you're done with it, but this is something that should be done only for that specific instance and after you are finished with it... Yeah. Makes perfect sense now I've had it spelled out for me :-) I think Linus is right though that some extra bullet-proofing in kref_put to BUG() if it goes negative would've caught this. I wonder if anyone else has fallen into this trap. 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: current linus bk, error mounting root
On Thu, Mar 10, 2005 at 01:52:59PM -0500, Jon Smirl wrote: Here's a big clue, if I build ata_piix in I can boot. If it is a module I can't. The console output definitely shows that the module is being loaded. Can you post your config? -- Mathematics is the supreme nostalgia of our time. - 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: [uml-devel] [PATCH 3/9] UML - Hardware random number generator
On Wednesday 09 March 2005 09:15 pm, Jeff Dike wrote: This implements a hardware random number generator for UML which attaches itself to the host's /dev/random. Direct use of /dev/random always makes me nervous. I've had a recurring problem with /dev/random blocking, and generally configure as much as possible to use /dev/urandom instead. It's really easy for a normal user to drain the /dev/random entropy pool on a server (at least one that doesn't have a sound card you can tell it to read white noise from). cat /dev/random /dev/null I like /dev/urandom because it'll feed you as much entropy as it's got, but won't block, and will presumably round-robin insert real entropy in the streams that multiple users get from /dev/urandom. (I realize this may not be the best place to get gpg keys from.) I'm just thinking about those UML hosting farms, with several UML instances per machine, on machines which haven't got a keyboard attached constantly feeding entropy into the pool. If just ONE of them is serving ssl connections from its own /dev/urandom, that would drain the /dev/random entropy pool on the host machine almost immediately... Admittedly if UML used /dev/urandom instead of /dev/random, it wouldn't know how much real randomness it was getting and how much synthetic randomness, but this makes predicting the numbers it's producing easier how? Rob - 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: current linus bk, error mounting root
On Thu, 10 Mar 2005 19:11:37 -0800, Matt Mackall [EMAIL PROTECTED] wrote: On Thu, Mar 10, 2005 at 01:52:59PM -0500, Jon Smirl wrote: Here's a big clue, if I build ata_piix in I can boot. If it is a module I can't. The console output definitely shows that the module is being loaded. Can you post your config? The attached config works. If you change CONFIG_SCSI_ATA_PIIX to a module (make sure it is on initrd) it will fail. I have been running with CONFIG_SCSI_ATA_PIIX as a module since 2.5.30 or so. -- Jon Smirl [EMAIL PROTECTED] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11 # Thu Mar 10 17:53:22 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_CPUSETS is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODE is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=m # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set # CONFIG_ACPI_CONTAINER is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus)
User mode drivers: part 1, interrupt handling (patch for 2.6.11)
As many of you will be aware, we've been working on infrastructure for
user-mode PCI and other drivers. The first step is to be able to
handle interrupts from user space. Subsequent patches add
infrastructure for setting up DMA for PCI devices.
The user-level interrupt code doesn't depend on the other patches, and
is probably the most mature of this patchset.
This patch adds a new file to /proc/irq/nnn/ called irq. Suitably
privileged processes can open this file. Reading the file returns the
number of interrupts (if any) that have occurred since the last read.
If the file is opened in blocking mode, reading it blocks until
an interrupt occurs. poll(2) and select(2) work as one would expect, to
allow interrupts to be one of many events to wait for.
(If you didn't like the file, one could have a special system call to
return the file descriptor).
Interrupts are usually masked; while a thread is in poll(2) or read(2) on the
file they are unmasked.
All architectures that use CONFIG_GENERIC_HARDIRQ are supported by
this patch.
A low latency user level interrupt handler would do something like
this, on a CONFIG_PREEMPT kernel:
int irqfd;
int n_ints;
struct sched_param sched_param;
irqfd = open(/proc/irq/513/irq, O_RDONLY);
mlockall()
sched_param.sched_priority = sched_get_priority_max(SCHED_FIFO) - 10;
sched_setscheduler(0, SCHED_FIFO, sched_param);
while(read(irqfd, n_ints, sizeof n_ints) == sizeof nints) {
... talk to device to handle interrupt
}
If you don't care about latency, then forget about the mlockall() and
setting the priority, and you don't need CONFIG_PREEMPT.
Signed-off-by: Peter Chubb [EMAIL PROTECTED]
kernel/irq/proc.c | 163 ++
1 files changed, 153 insertions(+), 10 deletions(-)
Index: linux-2.6.11-usrdrivers/kernel/irq/proc.c
===
--- linux-2.6.11-usrdrivers.orig/kernel/irq/proc.c 2005-03-11
10:30:57.875619102 +1100
+++ linux-2.6.11-usrdrivers/kernel/irq/proc.c 2005-03-11 10:45:07.146928168
+1100
@@ -9,6 +9,8 @@
#include linux/irq.h
#include linux/proc_fs.h
#include linux/interrupt.h
+#include linux/poll.h
+#include internals.h
static struct proc_dir_entry *root_irq_dir, *irq_dir[NR_IRQS];
@@ -90,27 +92,168 @@
action-dir = proc_mkdir(name, irq_dir[irq]);
}
+struct irq_proc {
+ unsigned long irq;
+ wait_queue_head_t q;
+ atomic_t count;
+ char devname[TASK_COMM_LEN];
+};
+
+static irqreturn_t irq_proc_irq_handler(int irq, void *vidp, struct pt_regs
*regs)
+{
+ struct irq_proc *idp = (struct irq_proc *)vidp;
+
+ BUG_ON(idp-irq != irq);
+ disable_irq_nosync(irq);
+ atomic_inc(idp-count);
+ wake_up(idp-q);
+ return IRQ_HANDLED;
+}
+
+
+/*
+ * Signal to userspace an interrupt has occured.
+ */
+static ssize_t irq_proc_read(struct file *filp, char __user *bufp, size_t
len, loff_t *ppos)
+{
+ struct irq_proc *ip = (struct irq_proc *)filp-private_data;
+ irq_desc_t *idp = irq_desc + ip-irq;
+ int pending;
+
+ DEFINE_WAIT(wait);
+
+ if (len sizeof(int))
+ return -EINVAL;
+
+ pending = atomic_read(ip-count);
+ if (pending == 0) {
+ if (idp-status IRQ_DISABLED)
+ enable_irq(ip-irq);
+ if (filp-f_flags O_NONBLOCK)
+ return -EWOULDBLOCK;
+ }
+
+ while (pending == 0) {
+ prepare_to_wait(ip-q, wait, TASK_INTERRUPTIBLE);
+ pending = atomic_read(ip-count);
+ if (pending == 0)
+ schedule();
+ finish_wait(ip-q, wait);
+ if (signal_pending(current))
+ return -ERESTARTSYS;
+ }
+
+ if (copy_to_user(bufp, pending, sizeof pending))
+ return -EFAULT;
+
+ *ppos += sizeof pending;
+
+ atomic_sub(pending, ip-count);
+ return sizeof pending;
+}
+
+
+static int irq_proc_open(struct inode *inop, struct file *filp)
+{
+ struct irq_proc *ip;
+ struct proc_dir_entry *ent = PDE(inop);
+ int error;
+
+ ip = kmalloc(sizeof *ip, GFP_KERNEL);
+ if (ip == NULL)
+ return -ENOMEM;
+
+ memset(ip, 0, sizeof(*ip));
+ strcpy(ip-devname, current-comm);
+ init_waitqueue_head(ip-q);
+ atomic_set(ip-count, 0);
+ ip-irq = (unsigned long)ent-data;
+
+ error = request_irq(ip-irq,
+ irq_proc_irq_handler,
+ SA_INTERRUPT,
+ ip-devname,
+ ip);
+ if (error 0) {
+ kfree(ip);
+ return error;
+ }
+ filp-private_data = (void *)ip;
+
+ return 0;
+}
+
+static int irq_proc_release(struct inode *inop, struct file
User mode drivers: part 2: PCI device handling (patch 1/2 for 2.6.11)
USER LEVEL DRIVERS: enable PCI device drivers at user space. This patch adds the capability for suitably privileged user-level processes to enable a PCI device, and set up DMA for it. A subsequent patch hooks up the actual system calls. There are three new system calls: long usr_pci_open(int bus, int slot, int function, __u64 dma_mask); Returns a filedescriptor for the PCI device described by bus,slot,function. It also enables the device, and sets it up as a bus-mastering DMA device, with the specified dma mask. Error codes are: ENOMEM: insufficient kernel memory to fulfil your request ENOENT: the specified device doesn't exist, or is otherwise invisible to Linux. EBUSY: Another driver has claimed the device EIO: The specified dma mask is invalid for this device. ENFILE: too many open files long usr_pci_get_consistent(int fd, size_t size, void **vaddrp, unsigned long *dmaaddrp) Call pci_alloc_consistent() to get size worth of pci consistent memory (currently an error if size != PAGESIZE); map the allocated memory into the user's address space; return the virtual user address in *vaddrp, and the bus address in *dmaaddrp ERRORS: EINVAL: the filedescriptor was not one obtained from usr_pci_open(), or size != PAGESIZE ENOMEM: insufficient appropriate memory or insufficient free virtual address space in the user program. EFAULT: vaddrp or dmaaddrp didn't point to writeable memory. The mapping obtained can be cleaned up with munmap(). long usr_pci_mmap(int fd, struct mapping_info *mp) -- map some memory for DMA to/from the device represented by fd, which was obtained from usr_pci_open(). struct mapping_info contains: void *virtaddr -- the virtual address to dma to int size -- how many bytes to set up struct usr_pci_sglist *sglist -- a pointer to a scatterlist int nents -- how many entries in the scatterlist enum dma_data_direction direction --- which way the dma is going to happen. The scatterlist should be sized at least size/PAGESIZE + 2. usr_pci_mmap() will call pci_map_sg() on the virtual region, then copy the resulting scatterlist into *sglist. The nents field will be updated with the actual number of scatterlist entries filled in. Failure codes are: EINVAL: the fd wasn't obtained from usr_pci_open, or direction wasn't one of DMA_TO_DEVICE, DMA_FROM_DEVICE or DMA_BIDIRECTIONAL, or the size of the scatterlist is insufficient to map the region. EFAULT: mp was a bad pointer, or the region of memory spanned by (virtaddr, virtaddr + size) was not all mapped. ENOMEM: insufficient appropriate memory long usr_pci_munmap(int fd, struct mapping_info *mp) Unmap a dma region mapped by usr_pci_map(). Struct mapping info is the same one used in usr_pci_mmap(). Error codes are: EINVAL: : the fd wasn't obtained from usr_pci_open, or the struct mapping_info was never mapped for this device Signed-off-by: Peter Chubb [EMAIL PROTECTED] # # drivers/Makefile |3 # drivers/pci/Kconfig|6 # drivers/usr/Makefile |2 # drivers/usr/sys.c | 952 + # include/linux/usrdrv.h | 63 +++ # 5 files changed, 1026 insertions(+) # Index: linux-2.6.11-usrdrivers/drivers/Makefile === --- linux-2.6.11-usrdrivers.orig/drivers/Makefile 2005-03-11 12:25:29.169139978 +1100 +++ linux-2.6.11-usrdrivers/drivers/Makefile2005-03-11 12:25:41.159270471 +1100 @@ -13,6 +13,9 @@ # was used and do nothing if so obj-$(CONFIG_PNP) += pnp/ +# User level device drivers +obj-$(CONFIG_USRDEV) += usr/ + # char/ comes before serial/ etc so that the VT console is the boot-time # default. obj-y += char/ Index: linux-2.6.11-usrdrivers/drivers/usr/Makefile === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.11-usrdrivers/drivers/usr/Makefile2005-03-11 12:25:41.160247026 +1100 @@ -0,0 +1,2 @@ +obj-y += sys.o +obj-$(CONFIG_USRBLKDEV) += blkdev.o Index: linux-2.6.11-usrdrivers/drivers/usr/sys.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.11-usrdrivers/drivers/usr/sys.c 2005-03-11 14:15:59.897394833 +1100 @@ -0,0 +1,952 @@ +/* + * Expose PCI-DMA interface to user mode. + * + * Copyright 2005 Peter Chubb + * National ICT
User mode drivers: part 2: PCI device handling (patch 2/2 for 2.6.11)
User-level drivers: Add system calls for I386 and IA64. Signed-Off-By: Peter Chubb [EMAIL PROTECTED] # # arch/i386/kernel/entry.S |4 # arch/ia64/kernel/entry.S |8 # include/asm-i386/unistd.h |6 +- # include/asm-ia64/unistd.h |4 # 4 files changed, 17 insertions(+), 5 deletions(-) # Index: linux-2.6.11-usrdrivers/arch/ia64/kernel/entry.S === --- linux-2.6.11-usrdrivers.orig/arch/ia64/kernel/entry.S 2005-03-11 13:59:28.940744950 +1100 +++ linux-2.6.11-usrdrivers/arch/ia64/kernel/entry.S2005-03-11 13:59:41.236542676 +1100 @@ -1577,10 +1577,10 @@ data8 sys_add_key data8 sys_request_key data8 sys_keyctl - data8 sys_ni_syscall - data8 sys_ni_syscall// 1275 - data8 sys_ni_syscall - data8 sys_ni_syscall + data8 sys_usr_pci_open + data8 sys_usr_pci_mmap // 1275 + data8 sys_usr_pci_munmap + data8 sys_usr_pci_get_consistent data8 sys_ni_syscall data8 sys_ni_syscall Index: linux-2.6.11-usrdrivers/include/asm-i386/unistd.h === --- linux-2.6.11-usrdrivers.orig/include/asm-i386/unistd.h 2005-03-11 13:59:28.942698059 +1100 +++ linux-2.6.11-usrdrivers/include/asm-i386/unistd.h 2005-03-11 13:59:41.245331667 +1100 @@ -294,8 +294,12 @@ #define __NR_add_key 286 #define __NR_request_key 287 #define __NR_keyctl288 +#define __NR_usr_pci_open 289 +#define __NR_usr_pci_mmap (__NR_usr_pci_open+1) +#define __NR_usr_pci_munmap(__NR_usr_pci_open+2) +#define __NR_usr_pci_get_consistent(__NR_usr_pci_open+3) -#define NR_syscalls 289 +#define NR_syscalls 293 /* * user-visible error numbers are in the range -1 - -128: see Index: linux-2.6.11-usrdrivers/include/asm-ia64/unistd.h === --- linux-2.6.11-usrdrivers.orig/include/asm-ia64/unistd.h 2005-03-11 13:59:28.942698059 +1100 +++ linux-2.6.11-usrdrivers/include/asm-ia64/unistd.h 2005-03-11 13:59:41.247284776 +1100 @@ -263,6 +263,10 @@ #define __NR_add_key 1271 #define __NR_request_key 1272 #define __NR_keyctl1273 +#define __NR_usr_pci_open 1274 +#define __NR_usr_pci_mmap 1275 +#define __NR_usr_pci_unmap 1276 +#define __NR_usr_pci_get_consistent 1277 #ifdef __KERNEL__ Index: linux-2.6.11-usrdrivers/arch/i386/kernel/entry.S === --- linux-2.6.11-usrdrivers.orig/arch/i386/kernel/entry.S 2005-03-11 13:59:28.941721505 +1100 +++ linux-2.6.11-usrdrivers/arch/i386/kernel/entry.S2005-03-11 13:59:41.248261330 +1100 @@ -864,5 +864,9 @@ .long sys_add_key .long sys_request_key .long sys_keyctl + .long sys_usr_pci_open + .long sys_usr_pci_mmap /* 290 */ + .long sys_usr_pci_munmap + .long sys_usr_pci_get_consistent syscall_table_size=(.-sys_call_table) - 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: pci_fixup_video() bogosity
Patch to make detection of boot video device more robust. Should I
leave the printk in?
--
Jon Smirl
[EMAIL PROTECTED]
= arch/i386/pci/fixup.c 1.24 vs edited =
--- 1.24/arch/i386/pci/fixup.c 2005-01-11 19:42:41 -05:00
+++ edited/arch/i386/pci/fixup.c2005-03-10 22:32:35 -05:00
@@ -355,11 +355,12 @@
* is marked here since the boot video device will be the only enabled
* video device at this point.
*
- */static void __devinit pci_fixup_video(struct pci_dev *pdev)
+ */
+static void __devinit pci_fixup_video(struct pci_dev *pdev)
{
struct pci_dev *bridge;
struct pci_bus *bus;
- u16 l;
+ u16 config;
if ((pdev-class 8) != PCI_CLASS_DISPLAY_VGA)
return;
@@ -369,12 +370,16 @@
while (bus) {
bridge = bus-self;
if (bridge) {
- pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, l);
- if (!(l PCI_BRIDGE_CTL_VGA))
+ pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
config);
+ if (!(config PCI_BRIDGE_CTL_VGA))
return;
}
bus = bus-parent;
}
- pdev-resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+ pci_read_config_word(pdev, PCI_COMMAND, config);
+ if (config (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
+ pdev-resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+ printk(KERN_INFO Boot video device is %s\n, pci_name(pdev));
+ }
}
DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);
-
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/
FEB_comms statement - Best so far
To contact us, please do_not_replyto. See the bottom of this email to contact us by telephone or email. It's absolutely right. You are going to get emails like this very soon Quickly, send me an email or call me and you will get real com.miss.ion emails with this subject line and big, big comm_ission pa.yments from all the bus_inesses you pro_mote. To pro.ve it, for a limit_ed per_iod I will give.you 10 sign_ups (that will p.a.y. to j.o.i.n. your bus.in.ess) and I will not ask you for a sin.gle cent/penny to get you star-ted. Use these to gen_erate an in.stant in.com_e. Then sitback watch the_sign_ups join_you inst_antly in their droves and without you having to do much_at all. At the end of March you will get comm_ission state_ments showing that you have ear.ned tens_of thou_s_ands of doll_ars from your existing bus..iness.oppo.rtun.it.ies. Miss. this and def_in.it.ely miss.out on the ea-sie.st and fas.test mo.ney that you will ever ma.ke from your bu.sin_ess opp.or-tuni.ty You can call me on 00 44 791-365-8094 or +44 791-365-8094 or from USA 001 44 791-365-8094 or email me on [EMAIL PROTECTED] Please ring my number if you can't get through via email. My number is a normal rate UK mobile telephone. Thank you Jane Yale If you want to stop getting my emails please send me an email to [EMAIL PROTECTED] with US in the subject. - 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/
Microstate Accounting for 2.6.11
Microstate Accounting
-
Timing data on threads at present is pretty crude: when the timer
interrupt occurs, a tick is added to either system time or user time
for the currently running thread. Thus in an unpacthed kernel one can
distinguish three timed states: On-cpu in userspace, on-cpu in system
space, and not running.
The actual number of states is much larger. A thread can be on a
runqueue or the expired queue (i.e., ready to run but not running),
sleeping on a semaphore or on a futex, having its time stolen to
service an interrupt, etc., etc.
This patch adds timers per-state to each struct task_struct, so that
time in all these states can be tracked. This patch contains the core
code do the timing, and to initialise the timers. Subsequent patches
enable the code (by adding Kconfig options) and add hooks to track
state changes.
Signed-off-by: Peter Chubb [EMAIL PROTECTED]
include/asm-generic/msa.h | 21 ++
include/linux/msa-kernel.h | 99 +
include/linux/msa.h| 46
include/linux/sched.h |4
kernel/Makefile|2
kernel/fork.c |2
kernel/msa.c | 472 +
7 files changed, 645 insertions(+), 1 deletion(-)
Index: linux-2.6-ustate/kernel/msa.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-ustate/kernel/msa.c 2005-03-11 09:58:20.574030768 +1100
@@ -0,0 +1,472 @@
+/*
+ * Microstate accounting.
+ * Try to account for various states much more accurately than
+ * the normal code does.
+ *
+ * Copyright (c) Peter Chubb 2005
+ * UNSW and National ICT Australia
+ * This code is released under the Gnu Public Licence, version 2.
+ */
+
+
+#include linux/config.h
+#include linux/types.h
+#include linux/errno.h
+#include linux/linkage.h
+#ifdef CONFIG_MICROSTATE
+#include linux/irq.h
+#include linux/hardirq.h
+#include linux/sched.h
+#include linux/jiffies.h
+
+#include asm/uaccess.h
+
+/*
+ * Track time spend in interrupt handlers.
+ */
+struct msa_irq {
+ clk_t times;
+ clk_t last_entered;
+};
+
+/*
+ * When the scheduler last swapped active and expired queues
+ */
+static DEFINE_PER_CPU(clk_t, queueflip_time);
+
+/*
+ * Time spent in interrupt handlers
+ */
+static DEFINE_PER_CPU(struct msa_irq[NR_IRQS+1], msa_irq);
+
+
+/**
+ * msa_switch: Update microstate timers when switching from one task to
another.
+ * @prev, @next: The prev task is coming off the processor;
+ *the new task is about to run on the processor.
+ *
+ * Update the times in both prev and next. It may be necessary to infer the
+ * next state for each task.
+ *
+ */
+void
+msa_switch(struct task_struct *prev, struct task_struct *next)
+{
+ struct microstates *msprev = prev-microstates;
+ struct microstates *msnext = next-microstates;
+ clk_t now;
+ enum thread_state next_state;
+ int interrupted = msprev-cur_state == INTERRUPTED;
+
+ preempt_disable();
+
+ MSA_NOW(now);
+
+ if (msprev-flags QUEUE_FLIPPED) {
+ __get_cpu_var(queueflip_time) = now;
+ msprev-flags = ~QUEUE_FLIPPED;
+ }
+
+ /*
+* If the queues have been flipped,
+* update the state as of the last flip time.
+*/
+ if (msnext-cur_state == ONEXPIREDQUEUE) {
+ clk_t qfp = per_cpu(queueflip_time, msnext-lastqueued);
+ msnext-cur_state = ONACTIVEQUEUE;
+ msnext-timers[ONEXPIREDQUEUE] += qfp - msnext-last_change;
+ msnext-last_change = qfp;
+ }
+
+ msprev-timers[msprev-cur_state] += now - msprev-last_change;
+ msnext-timers[msnext-cur_state] += now - msnext-last_change;
+
+ /* Update states */
+ switch (msprev-next_state) {
+ case MSA_UNKNOWN:
+ /*
+* Infer from actual state
+*/
+ switch (prev-state) {
+ case TASK_INTERRUPTIBLE:
+ next_state = INTERRUPTIBLE_SLEEP;
+ break;
+
+ case TASK_UNINTERRUPTIBLE:
+ next_state = UNINTERRUPTIBLE_SLEEP;
+ break;
+
+ case TASK_STOPPED:
+ next_state = STOPPED;
+ break;
+
+ case EXIT_DEAD:
+ case EXIT_ZOMBIE:
+ next_state = ZOMBIE;
+ break;
+
+ case TASK_RUNNING:
+ next_state = ONACTIVEQUEUE;
+ break;
+
+ default:
+ next_state = MSA_UNKNOWN;
+ break;
+
+ }
+ break;
+
+ case PAGING_SLEEP: /*
+ * Sleep states are PAGING_SLEEP;
+
Re: pci_fixup_video() bogosity
On Thu, 2005-03-10 at 22:39 -0500, Jon Smirl wrote: Patch to make detection of boot video device more robust. Should I leave the printk in? Hrm... yes, but make it KERN_DEBUG. 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/
Re: Average power consumption in S3?
On Thu, Mar 10, 2005 at 07:08:26PM +0100, Moritz Muehlenhoff wrote:
I've got the e100 and with WOL disabled and Matthew's hacked radeontool
power consumption decreases to 970 mWh.
I have a T40p, and with the following patches (versus 2.6.11) and the
following sleep script, I have power consuption down to 580 mWh.
The 05-radeonfb-Thinkpad-Power.patch will have to patched with your
specific Thinkpad model number, or booted with the force_sleep option.
See the Linux thinkpad mailing list ([EMAIL PROTECTED])
archives for more information.
Warning: The 05-radeonfb-Thinkpad-Power.patch is not quite ready for
merging, but compared to completely pathetic battery life when using
ACPI's suspend-to-memory without them, it's definitely worth it.
- Ted
From: Christian Borntraeger [EMAIL PROTECTED]
During the wakeup from suspend-to-ram I get several warnings.
Signed-off-by: Christian Borntraeger [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
25-akpm/drivers/acpi/osl.c |4 ++--
25-akpm/drivers/acpi/pci_link.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff -puN drivers/acpi/osl.c~acpi-sleep-while-atomic-during-s3-resume-from-ram
drivers/acpi/osl.c
--- 25/drivers/acpi/osl.c~acpi-sleep-while-atomic-during-s3-resume-from-ram
2005-01-16 00:45:23.784364208 -0800
+++ 25-akpm/drivers/acpi/osl.c 2005-01-16 00:45:23.789363448 -0800
@@ -145,7 +145,7 @@ acpi_os_vprintf(const char *fmt, va_list
void *
acpi_os_allocate(acpi_size size)
{
- return kmalloc(size, GFP_KERNEL);
+ return kmalloc(size, GFP_ATOMIC);
}
void
@@ -905,7 +905,7 @@ acpi_os_wait_semaphore(
ACPI_DEBUG_PRINT ((ACPI_DB_MUTEX, Waiting for semaphore[%p|%d|%d]\n,
handle, units, timeout));
- if (in_atomic())
+ if (in_atomic() || irqs_disabled())
timeout = 0;
switch (timeout)
diff -puN
drivers/acpi/pci_link.c~acpi-sleep-while-atomic-during-s3-resume-from-ram
drivers/acpi/pci_link.c
---
25/drivers/acpi/pci_link.c~acpi-sleep-while-atomic-during-s3-resume-from-ram
2005-01-16 00:45:23.785364056 -0800
+++ 25-akpm/drivers/acpi/pci_link.c 2005-01-16 00:45:23.790363296 -0800
@@ -315,7 +315,7 @@ acpi_pci_link_set (
if (!link || !irq)
return_VALUE(-EINVAL);
- resource = kmalloc( sizeof(*resource)+1, GFP_KERNEL);
+ resource = kmalloc( sizeof(*resource)+1, GFP_ATOMIC);
if(!resource)
return_VALUE(-ENOMEM);
_
This is needed to remove another sleeping function called from invalid
context error message when resuming from sleep.
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
Index: src/drivers/acpi/utils.c
===
--- src.orig/drivers/acpi/utils.c 2005-03-03 13:08:44.0 -0500
+++ src/drivers/acpi/utils.c2005-03-03 13:10:04.0 -0500
@@ -252,7 +252,7 @@
if (!data)
return_ACPI_STATUS(AE_BAD_PARAMETER);
- element = kmalloc(sizeof(union acpi_object), GFP_KERNEL);
+ element = kmalloc(sizeof(union acpi_object), GFP_ATOMIC);
if(!element)
return_ACPI_STATUS(AE_NO_MEMORY);
= drivers/video/aty/radeon_base.c 1.40 vs edited =
--- 1.40/drivers/video/aty/radeon_base.c2005-02-15 21:25:30 -05:00
+++ edited/drivers/video/aty/radeon_base.c 2005-02-17 20:30:48 -05:00
@@ -273,6 +273,9 @@
#ifdef CONFIG_MTRR
static int nomtrr = 0;
#endif
+#if defined(CONFIG_PM) defined(CONFIG_X86)
+int radeon_force_sleep = 0;
+#endif
/*
* prototypes
@@ -2535,6 +2538,10 @@
force_measure_pll = 1;
} else if (!strncmp(this_opt, ignore_edid, 11)) {
ignore_edid = 1;
+#if defined(CONFIG_PM) defined(CONFIG_X86)
+ } else if (!strncmp(this_opt, force_sleep, 11)) {
+ radeon_force_sleep = 1;
+#endif
} else
mode_option = this_opt;
}
@@ -2574,3 +2581,5 @@
MODULE_PARM_DESC(panel_yres, int: set panel yres);
module_param(mode_option, charp, 0);
MODULE_PARM_DESC(mode_option, Specify resolution as
\xresxyres[-bpp][@refresh]\ );
+module_param(radeon_force_sleep, int, 0);
+MODULE_PARM_DESC(radeon_force_sleep, bool: force ACPI sleep mode on untested
machines);
= drivers/video/aty/radeon_pm.c 1.10 vs edited =
--- 1.10/drivers/video/aty/radeon_pm.c 2005-02-12 23:01:11 -05:00
+++ edited/drivers/video/aty/radeon_pm.c2005-02-17 20:23:57 -05:00
@@ -25,8 +25,97 @@
#include asm/pmac_feature.h
#endif
+/* For detecting supported PC laptops */
+#ifdef CONFIG_X86
+#include linux/dmi.h
+#endif
+
#include ati_ids.h
+#ifdef CONFIG_X86
+/* This array holds a list of supported PC laptops.
+ * Currently only few IBM models are tested.
+ * If you want to experiment, use dmidecode to find out
+ * vendor and product codes for Your laptop.
+ */
+static struct
Microstate Accounting for 2.6.11, patch 3/
Microstate Accounting: Track time in system calls and interrupts, i386 code.
Signed-off-by; Peter Chubb [EMAIL PROTECTED]
arch/i386/kernel/entry.S | 16
arch/i386/kernel/irq.c | 13 -
Index: linux-2.6-ustate/arch/i386/kernel/entry.S
===
--- linux-2.6-ustate.orig/arch/i386/kernel/entry.S 2005-03-10
09:13:01.448604031 +1100
+++ linux-2.6-ustate/arch/i386/kernel/entry.S 2005-03-10 09:16:14.888575341
+1100
@@ -222,10 +222,18 @@
/* Note, _TIF_SECCOMP is bit number 8, and so it needs testw and not
testb */
testw
$(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP),TI_flags(%ebp)
jnz syscall_trace_entry
+#ifdef CONFIG_MICROSTATE
+ pushl %eax
+ call msa_start_syscall
+ popl%eax
+#endif
cmpl $(nr_syscalls), %eax
jae syscall_badsys
call *sys_call_table(,%eax,4)
movl %eax,EAX(%esp)
+#ifdef CONFIG_MICROSTATE
+ call msa_end_syscall
+#endif
cli
movl TI_flags(%ebp), %ecx
testw $_TIF_ALLWORK_MASK, %cx
@@ -250,9 +258,17 @@
cmpl $(nr_syscalls), %eax
jae syscall_badsys
syscall_call:
+#ifdef CONFIG_MICROSTATE
+ pushl %eax
+ call msa_start_syscall
+ popl%eax
+#endif
call *sys_call_table(,%eax,4)
movl %eax,EAX(%esp) # store the return value
syscall_exit:
+#ifdef CONFIG_MICROSTATE
+ call msa_end_syscall
+#endif
cli # make sure we don't miss an interrupt
# setting need_resched or sigpending
# between sampling and the iret
Index: linux-2.6-ustate/arch/i386/kernel/irq.c
===
--- linux-2.6-ustate.orig/arch/i386/kernel/irq.c2005-03-10
09:13:00.115606274 +1100
+++ linux-2.6-ustate/arch/i386/kernel/irq.c 2005-03-10 09:16:16.032121680
+1100
@@ -55,6 +55,8 @@
#endif
irq_enter();
+ msa_start_irq(irq);
+
#ifdef CONFIG_DEBUG_STACKOVERFLOW
/* Debugging check for stack overflow: is there less than 1KB free? */
{
@@ -101,6 +103,7 @@
#endif
__do_IRQ(irq, regs);
+ msa_finish_irq(irq);
irq_exit();
return 1;
@@ -221,10 +224,18 @@
seq_printf(p, %3d: ,i);
#ifndef CONFIG_SMP
seq_printf(p, %10u , kstat_irqs(i));
+#ifdef CONFIG_MICROSTATE
+ seq_printf(p, %10llu, msa_irq_time(0, i));
+#endif
#else
for (j = 0; j NR_CPUS; j++)
- if (cpu_online(j))
+ if (cpu_online(j)) {
seq_printf(p, %10u , kstat_cpu(j).irqs[i]);
+#ifdef CONFIG_MICROSTATE
+ seq_printf(p, %10llu, msa_irq_time(j, i));
+#endif
+ }
+
#endif
seq_printf(p, %14s, irq_desc[i].handler-typename);
seq_printf(p, %s, action-name);
-
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/
Microstate Accounting for 2.6.11, patch 2/6
Microstate Accounting:
Add hooks into the scheduler to track state changes.
Arrange for parent process's child times to be updated at process exit.
kernel/sched.c |8
kernel/exit.c |3 +++
Index: linux-2.6-ustate/kernel/sched.c
===
--- linux-2.6-ustate.orig/kernel/sched.c2005-03-11 09:59:31.109628035
+1100
+++ linux-2.6-ustate/kernel/sched.c 2005-03-11 09:59:31.116463921 +1100
@@ -635,6 +635,7 @@
*/
static inline void __activate_task(task_t *p, runqueue_t *rq)
{
+ msa_set_timer(p, ONACTIVEQUEUE);
enqueue_task(p, rq-active);
rq-nr_running++;
}
@@ -1238,6 +1239,7 @@
if (unlikely(!current-array))
__activate_task(p, rq);
else {
+ msa_set_timer(p, ONACTIVEQUEUE);
p-prio = current-prio;
list_add_tail(p-run_list, current-run_list);
p-array = current-array;
@@ -2422,6 +2424,7 @@
if (!rq-expired_timestamp)
rq-expired_timestamp = jiffies;
if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq)) {
+ msa_next_state(p, ONEXPIREDQUEUE);
enqueue_task(p, rq-expired);
if (p-static_prio rq-best_expired_prio)
rq-best_expired_prio = p-static_prio;
@@ -2733,6 +2736,7 @@
array = rq-active;
rq-expired_timestamp = 0;
rq-best_expired_prio = MAX_PRIO;
+ msa_flip_expired(prev);
} else
schedstat_inc(rq, sched_noswitch);
@@ -2773,6 +2777,8 @@
rq-curr = next;
++*switch_count;
+ msa_switch(prev, next);
+
prepare_arch_switch(rq, next);
prev = context_switch(rq, prev, next);
barrier();
@@ -3693,6 +3699,8 @@
*/
if (rt_task(current))
target = rq-active;
+ else
+ msa_next_state(current, ONEXPIREDQUEUE);
if (current-array-nr_active == 1) {
schedstat_inc(rq, yld_act_empty);
Index: linux-2.6-ustate/kernel/exit.c
===
--- linux-2.6-ustate.orig/kernel/exit.c 2005-03-11 09:59:36.360564796 +1100
+++ linux-2.6-ustate/kernel/exit.c 2005-03-11 09:59:36.364471017 +1100
@@ -93,6 +93,9 @@
}
sched_exit(p);
+
+ msa_update_parent(p-parent, p);
+
write_unlock_irq(tasklist_lock);
spin_unlock(p-proc_lock);
proc_pid_flush(proc_dentry);
-
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] AGP support for powermac G5
Hi.
On Fri, 2005-03-11 at 14:02, Paul Mackerras wrote:
+struct agp_bridge_driver u3_agp_driver = {
+ .owner = THIS_MODULE,
+ .aperture_sizes = (void *)u3_sizes,
+ .size_type = U32_APER_SIZE,
+ .num_aperture_sizes = 8,
+ .configure = uninorth_configure,
+ .fetch_size = uninorth_fetch_size,
+ .cleanup= uninorth_cleanup,
+ .tlb_flush = uninorth_tlbflush,
+ .mask_memory= agp_generic_mask_memory,
+ .masks = NULL,
+ .cache_flush= null_cache_flush,
+ .agp_enable = uninorth_agp_enable,
+ .create_gatt_table = uninorth_create_gatt_table,
+ .free_gatt_table= uninorth_free_gatt_table,
+ .insert_memory = u3_insert_memory,
+ .remove_memory = u3_remove_memory,
+ .alloc_by_type = agp_generic_alloc_by_type,
+ .free_by_type = agp_generic_free_by_type,
+ .agp_alloc_page = agp_generic_alloc_page,
+ .agp_destroy_page = agp_generic_destroy_page,
+ .cant_use_aperture = 1,
+ .needs_scratch_page = 1,
+};
+
No power management support? :
Regards,
Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574
Maintainer of Suspend2 Kernel Patches http://suspend2.net
-
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/
Microstate Accounting for 2.6.11, patch 3/6
Microstate accounting:
Provide I386-dependent MSA clocks, and Kconfig options.
arch/i386/Kconfig | 39 ++-
include/asm-i386/msa.h | 49 +
2 files changed, 87 insertions(+), 1 deletion(-)
Signed-off-by: Peter Chubb [EMAIL PROTECTED]
Index: linux-2.6-ustate/arch/i386/Kconfig
===
--- linux-2.6-ustate.orig/arch/i386/Kconfig 2005-03-11 09:59:38.773632446
+1100
+++ linux-2.6-ustate/arch/i386/Kconfig 2005-03-11 09:59:38.777538666 +1100
@@ -923,8 +923,45 @@
If unsure, say Y. Only embedded should say N here.
-endmenu
+config MICROSTATE
+ bool Microstate accounting
+ help
+ This option causes the kernel to keep very accurate track of
+how long your threads spend on the runqueues, running, or asleep or
+stopped. It will slow down your kernel.
+Times are reported in /proc/pid/msa and through a new msa()
+system call.
+
+choice
+ depends on MICROSTATE
+ prompt Microstate timing source
+ default MICROSTATE_TSC
+
+config MICROSTATE_PM
+ bool Use Power-Management timer for microstate timings
+ depends on X86_PM_TIMER
+ help
+If your machine is ACPI enabled and uses power-management, then the
+TSC runs at a variable rate, which will distort the
+microstate measurements. This timer, although having
+slightly more overhead, and a lower resolution (279
+nanoseconds or so) will always run at a constant rate.
+
+config MICROSTATE_TSC
+ bool Use on-chip TSC for microstate timings
+ depends on X86_TSC
+ help
+ If your machine's clock runs at constant rate, then this timer
+gives you cycle precision in measureing times spent in microstates.
+
+config MICROSTATE_TOD
+ bool Use time-of-day clock for microstate timings
+ help
+ If none of the other timers are any good for you, this timer
+will give you micro-second precision.
+endchoice
+endmenu
menu Power management options (ACPI, APM)
depends on !X86_VOYAGER
Index: linux-2.6-ustate/include/asm-i386/msa.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-ustate/include/asm-i386/msa.h 2005-03-11 09:59:38.779491777
+1100
@@ -0,0 +1,49 @@
+/
+ * asm-i386/msa.h
+ *
+ * Provide an architecture-specific clock.
+ */
+
+#ifndef _ASM_I386_MSA_H
+# define _ASM_I386_MSA_H
+
+# include linux/config.h
+
+
+# if defined(CONFIG_MICROSTATE_TSC)
+/*
+ * Use the processor's time-stamp counter as a timesource
+ */
+# include asm/msr.h
+# include asm/div64.h
+
+# define MSA_NOW(now) rdtscll(now)
+
+extern unsigned long cpu_khz;
+# define MSA_TO_NSEC(clk) ({ clk_t _x = ((clk) * 100ULL); do_div(_x,
cpu_khz); _x; })
+
+# elif defined(CONFIG_MICROSTATE_PM)
+/*
+ * Use the system's monotonic clock as a timesource.
+ * This will only be enabled if the Power Management Timer is enabled.
+ */
+unsigned long long monotonic_clock(void);
+# define MSA_NOW(now) do { now = monotonic_clock(); } while (0)
+# define MSA_TO_NSEC(clk) (clk)
+
+# elif defined(CONFIG_MICROSTATE_TOD)
+/*
+ * Fall back to gettimeofday.
+ * This one is incompatible with interrupt-time measurement on some processors.
+ */
+static inline void msa_now(clk_t *nsp) {
+ struct timeval tv;
+ do_gettimeofday(tv);
+ *nsp = tv.tv_sec * 100 + tv.tv_usec;
+}
+# define MSA_NOW(x) msa_now(x)
+# define MSA_TO_NSEC(clk) ((clk) * 1000)
+# endif
+
+
+#endif /* _ASM_I386_MSA_H */
I386
-
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/
Microstate Accounting for 2.6.11, patch 5/6
Microstate accounting: Add the I386 system call. arch/i386/kernel/entry.S |2 +- include/asm-i386/unistd.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6-ustate/arch/i386/kernel/entry.S === --- linux-2.6-ustate.orig/arch/i386/kernel/entry.S 2005-03-10 09:16:14.888575341 +1100 +++ linux-2.6-ustate/arch/i386/kernel/entry.S 2005-03-10 09:16:15.446188457 +1100 @@ -876,7 +876,7 @@ .long sys_mq_getsetattr .long sys_ni_syscall/* reserved for kexec */ .long sys_waitid - .long sys_ni_syscall/* 285 */ /* available */ + .long sys_msa /* 285 */ /* available */ .long sys_add_key .long sys_request_key .long sys_keyctl Index: linux-2.6-ustate/include/asm-i386/unistd.h === --- linux-2.6-ustate.orig/include/asm-i386/unistd.h 2005-03-10 09:13:00.813843194 +1100 +++ linux-2.6-ustate/include/asm-i386/unistd.h 2005-03-10 09:16:15.448141568 +1100 @@ -290,7 +290,7 @@ #define __NR_mq_getsetattr (__NR_mq_open+5) #define __NR_sys_kexec_load283 #define __NR_waitid284 -/* #define __NR_sys_setaltroot 285 */ +#define __NR_sys_msa 285 #define __NR_add_key 286 #define __NR_request_key 287 #define __NR_keyctl288 - 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] Make primary boot video device detection more robust
When detecting the boot video device, allow for the case of multiple
cards on the same bus. Check each candidate to make sure that the card
is active.
Signed off by: Jon Smirl [EMAIL PROTECTED]
--
Jon Smirl
[EMAIL PROTECTED]
= arch/i386/pci/fixup.c 1.24 vs edited =
--- 1.24/arch/i386/pci/fixup.c 2005-01-11 19:42:41 -05:00
+++ edited/arch/i386/pci/fixup.c2005-03-10 22:50:30 -05:00
@@ -343,7 +343,7 @@
/*
* Fixup to mark boot BIOS video selected by BIOS before it changes
*
- * From information provided by Jon Smirl [EMAIL PROTECTED]
+ * From information provided by Jon Smirl [EMAIL PROTECTED]
*
* The standard boot ROM sequence for an x86 machine uses the BIOS
* to select an initial video card for boot display. This boot video
@@ -355,11 +355,12 @@
* is marked here since the boot video device will be the only enabled
* video device at this point.
*
- */static void __devinit pci_fixup_video(struct pci_dev *pdev)
+ */
+static void __devinit pci_fixup_video(struct pci_dev *pdev)
{
struct pci_dev *bridge;
struct pci_bus *bus;
- u16 l;
+ u16 config;
if ((pdev-class 8) != PCI_CLASS_DISPLAY_VGA)
return;
@@ -369,12 +370,16 @@
while (bus) {
bridge = bus-self;
if (bridge) {
- pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, l);
- if (!(l PCI_BRIDGE_CTL_VGA))
+ pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
config);
+ if (!(config PCI_BRIDGE_CTL_VGA))
return;
}
bus = bus-parent;
}
- pdev-resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+ pci_read_config_word(pdev, PCI_COMMAND, config);
+ if (config (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
+ pdev-resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+ printk(KERN_DEBUG Boot video device is %s\n, pci_name(pdev));
+ }
}
DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);
-
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/
Microstate Accounting for 2.6.11, patch 6/6
Microstate accounting: Track time spent asleep while paging, in poll() or select(), or on a futex separately from other sleeps. fs/select.c |2 ++ kernel/futex.c |2 ++ mm/memory.c |6 +- Index: linux-2.6-ustate/mm/memory.c === --- linux-2.6-ustate.orig/mm/memory.c 2005-03-10 09:12:59.492564100 +1100 +++ linux-2.6-ustate/mm/memory.c2005-03-10 09:16:16.583875465 +1100 @@ -2079,6 +2079,7 @@ if (is_vm_hugetlb_page(vma)) return VM_FAULT_SIGBUS; /* mapping truncation does this. */ + msa_next_state(current, PAGING_SLEEP); /* * We need the page table lock to synchronize with kswapd * and the SMP-safe atomic PTE updates. @@ -2098,10 +2099,13 @@ if (!pte) goto oom; - return handle_pte_fault(mm, vma, address, write_access, pte, pmd); + int ret = handle_pte_fault(mm, vma, address, write_access, pte, pmd); + msa_next_state(current, MSA_UNKNOWN); + return ret; oom: spin_unlock(mm-page_table_lock); + msa_next_state(current, MSA_UNKNOWN); return VM_FAULT_OOM; } Index: linux-2.6-ustate/kernel/futex.c === --- linux-2.6-ustate.orig/kernel/futex.c2005-03-10 09:12:58.843154938 +1100 +++ linux-2.6-ustate/kernel/futex.c 2005-03-10 09:16:17.109262256 +1100 @@ -39,6 +39,7 @@ #include linux/mount.h #include linux/pagemap.h #include linux/syscalls.h +#include linux/msa.h #define FUTEX_HASHBITS (CONFIG_BASE_SMALL ? 4 : 8) @@ -571,6 +572,7 @@ * wakes us up. */ + msa_next_state(current, FUTEX_SLEEP); /* add_wait_queue is the barrier after __set_current_state. */ __set_current_state(TASK_INTERRUPTIBLE); add_wait_queue(q.waiters, wait); Index: linux-2.6-ustate/fs/select.c === --- linux-2.6-ustate.orig/fs/select.c 2005-03-10 09:12:59.182996124 +1100 +++ linux-2.6-ustate/fs/select.c2005-03-10 09:16:16.843639194 +1100 @@ -256,6 +256,7 @@ retval = table.error; break; } + msa_next_state(current, POLL_SLEEP); __timeout = schedule_timeout(__timeout); } __set_current_state(TASK_RUNNING); @@ -447,6 +448,7 @@ count = wait-error; if (count) break; + msa_next_state(current, POLL_SLEEP); timeout = schedule_timeout(timeout); } __set_current_state(TASK_RUNNING); - 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: AGP bogosities
On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote: That one is even worse... from what I see in your lspci output, you have no bridge with AGP capability at all, and the various AGP devices are all siblings... Both of the video cards are sitting on agp busses in agp slots hooked up to host to agp bridges. Are you sure there is any real AGP slot in there ? Yes :) 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] AGP support for powermac G5
Nigel Cunningham writes: No power management support? : The suspend/resume methods are in the pci_driver struct, not the agp_bridge_driver struct. Not that we have suspend/resume on the G5 yet. Paul. - 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/
Microstate Accounting for 2.6.11, patch 4/6
Microstate accounting: Account for time in interrupt handlers for I386.
arch/i386/kernel/irq.c | 13 -
1 files changed, 12 insertions(+), 1 deletion(-)
Index: linux-2.6-ustate/arch/i386/kernel/irq.c
===
--- linux-2.6-ustate.orig/arch/i386/kernel/irq.c2005-03-10
09:13:00.115606274 +1100
+++ linux-2.6-ustate/arch/i386/kernel/irq.c 2005-03-10 09:16:16.032121680
+1100
@@ -55,6 +55,8 @@
#endif
irq_enter();
+ msa_start_irq(irq);
+
#ifdef CONFIG_DEBUG_STACKOVERFLOW
/* Debugging check for stack overflow: is there less than 1KB free? */
{
@@ -101,6 +103,7 @@
#endif
__do_IRQ(irq, regs);
+ msa_finish_irq(irq);
irq_exit();
return 1;
@@ -221,10 +224,18 @@
seq_printf(p, %3d: ,i);
#ifndef CONFIG_SMP
seq_printf(p, %10u , kstat_irqs(i));
+#ifdef CONFIG_MICROSTATE
+ seq_printf(p, %10llu, msa_irq_time(0, i));
+#endif
#else
for (j = 0; j NR_CPUS; j++)
- if (cpu_online(j))
+ if (cpu_online(j)) {
seq_printf(p, %10u , kstat_cpu(j).irqs[i]);
+#ifdef CONFIG_MICROSTATE
+ seq_printf(p, %10llu, msa_irq_time(j, i));
+#endif
+ }
+
#endif
seq_printf(p, %14s, irq_desc[i].handler-typename);
seq_printf(p, %s, action-name);
-
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: Microstate Accounting for 2.6.11
Peter Chubb [EMAIL PROTECTED] wrote: Timing data on threads at present is pretty crude: when the timer interrupt occurs, a tick is added to either system time or user time for the currently running thread. Thus in an unpacthed kernel one can distinguish three timed states: On-cpu in userspace, on-cpu in system space, and not running. The actual number of states is much larger. A thread can be on a runqueue or the expired queue (i.e., ready to run but not running), sleeping on a semaphore or on a futex, having its time stolen to service an interrupt, etc., etc. This patch adds timers per-state to each struct task_struct, so that time in all these states can be tracked. This patch contains the core code do the timing, and to initialise the timers. Subsequent patches enable the code (by adding Kconfig options) and add hooks to track state changes. Why does the kernel need this feature? Have you any numbers on the overhead? The preempt_disable() in sys_msa() seems odd. - 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] AGP support for powermac G5
No power management support? : Heh, not yet :) We can't really put a G5 to sleep yet. I haven't figured out the magic incantations for the PMU chip on those. 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/
Re: [PATCH] AGP support for powermac G5
Hi. On Fri, 2005-03-11 at 15:02, Paul Mackerras wrote: Nigel Cunningham writes: No power management support? : The suspend/resume methods are in the pci_driver struct, not the agp_bridge_driver struct. Not that we have suspend/resume on the G5 yet. Ah. Thought I'd seen some in others. Humble apologies. Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://suspend2.net - 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: AGP bogosities
On Thu, 2005-03-10 at 20:02 -0800, Jesse Barnes wrote: On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote: That one is even worse... from what I see in your lspci output, you have no bridge with AGP capability at all, and the various AGP devices are all siblings... Both of the video cards are sitting on agp busses in agp slots hooked up to host to agp bridges. Are you sure there is any real AGP slot in there ? Yes :) Well, according to your lspci, none of the bridges exposes a device with AGP capabilities... It looks like you aren't exposing the host self device on the bus. Do you have an AGP driver ? If yes, it certainly can't use any of the generic code anyway ... I still think that the matching between a bridge and a card should be a bridge callback (with eventually a generic one that works for whatever x86 are around) so that the bridge driver can deal with funky layouts. I have no time to toy with this at the moment though ;) 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/
Microstate accounting, IA64 support
Microstate Accounting:
Add suppoort for IA64.
linux-2.6-ustate/arch/ia64/Kconfig | 25 +++
linux-2.6-ustate/arch/ia64/kernel/entry.S| 44 +++
linux-2.6-ustate/arch/ia64/kernel/irq_ia64.c | 21 +++-
linux-2.6-ustate/arch/ia64/kernel/ivt.S |8 +++-
linux-2.6-ustate/include/asm-ia64/msa.h | 33
linux-2.6-ustate/include/asm-ia64/unistd.h |1
7 files changed, 129 insertions(+), 5 deletions(-)
Index: linux-2.6-ustate/arch/ia64/Kconfig
===
--- linux-2.6-ustate.orig/arch/ia64/Kconfig 2005-03-10 09:13:01.780632777
+1100
+++ linux-2.6-ustate/arch/ia64/Kconfig 2005-03-10 09:16:14.593655619 +1100
@@ -302,6 +302,31 @@
little bigger and slows down execution a bit, but it is generally
a good idea to turn this on. If you're unsure, say Y.
+config MICROSTATE
+ bool Microstate accounting
+ help
+ This option causes the kernel to keep very accurate track of
+ how long your threads spend on the runqueues, running, or asleep or
+ stopped. It will slow down your kernel.
+ Times are reported in /proc/pid/msa and through a new msa()
+ system call.
+choice
+ depends on MICROSTATE
+ prompt Microstate timing source
+ default MICROSTATE_ITC
+ help
+ On IA64 one can use two timeing sources for the microstate
+ accounting; the on-chip interval counter, or Linux's
+ time-of-day clock. The first is very cheap; the other is
+ more accurate on SMP systems.
+
+config MICROSTATE_ITC
+ bool Use on-chip ITC for microstate timing
+
+config MICROSTATE_TOD
+ bool Use time-of-day clock for microstate timings
+endchoice
+
config IA64_PALINFO
tristate /proc/pal support
help
Index: linux-2.6-ustate/include/asm-ia64/msa.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-ustate/include/asm-ia64/msa.h 2005-03-10 09:16:14.594632174
+1100
@@ -0,0 +1,33 @@
+/
+ * asm-ia64/msa.h
+ *
+ * Provide an architecture-specific clock.
+ */
+
+#ifndef _ASM_IA64_MSA_H
+#define _ASM_IA64_MSA_H
+
+#include asm/processor.h
+#include asm/timex.h
+#include asm/smp.h
+
+
+# if defined(CONFIG_MICROSTATE_ITC)
+# define MSA_NOW(now) do { now = (clk_t)get_cycles(); } while (0)
+
+# define MSA_TO_NSEC(clk) ((10*clk) /
cpu_data(smp_processor_id())-itc_freq)
+
+# elif defined(CONFIG_MICROSTATE_TOD)
+static inline void msa_now(clk_t *nsp) {
+ struct timeval tv;
+ do_gettimeofday(tv);
+ *nsp = tv.tv_sec * 100 + tv.tv_usec;
+}
+# define MSA_NOW(x) msa_now(x)
+# define MSA_TO_NSEC(clk) ((clk) * 1000)
+
+# else
+# include asm-generic/msa.h
+# endif
+
+#endif /* _ASM_IA64_MSA_H */
Microstate Accounting: Track time in system calls for IA64
arch/ia64/kernel/entry.S | 44
arch/ia64/kernel/ivt.S |8 ++--
2 files changed, 50 insertions(+), 2 deletions(-)
Index: linux-2.6-ustate/arch/ia64/kernel/entry.S
===
--- linux-2.6-ustate.orig/arch/ia64/kernel/entry.S 2005-03-10
09:13:01.149778160 +1100
+++ linux-2.6-ustate/arch/ia64/kernel/entry.S 2005-03-10 09:16:15.157128068
+1100
@@ -589,6 +589,46 @@
.ret4: br.cond.sptk ia64_leave_kernel
END(ia64_strace_leave_kernel)
+#ifdef CONFIG_MICROSTATE
+/*
+ * preserve input registers,
+ * and r8
+ */
+GLOBAL_ENTRY(invoke_msa_end_syscall)
+ .prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(8)
+ alloc loc1=ar.pfs,8,4,0,0
+ mov loc0=rp
+ .body
+ ;;
+ mov loc2=ret0
+ mov loc3=ret2
+ br.call.sptk.many rp=msa_end_syscall
+1: mov rp=loc0
+ mov ret0=loc2
+ mov ret2=loc3
+ mov ar.pfs=loc1
+ br.ret.sptk.many rp
+END(invoke_msa_end_syscall)
+/*
+ * Preserves in0-7, and all callee-save registers.
+ */
+GLOBAL_ENTRY(invoke_msa_start_syscall)
+ .prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(8)
+ alloc loc1=ar.pfs,8,4,0,0
+ mov loc0=rp
+ .body
+ mov loc2=r3
+ mov loc3=r15
+ ;;
+ br.call.sptk.many rp=msa_start_syscall
+1: mov r15=loc3
+ mov r3=loc2
+ mov ar.pfs=loc1
+ mov rp=loc0
+ br.ret.sptk.many rp
+END(invoke_msa_start_syscall)
+#endif /* CONFIG_MICROSTATE */
+
GLOBAL_ENTRY(ia64_ret_from_clone)
PT_REGS_UNWIND_INFO(0)
{ /*
@@ -671,6 +711,10 @@
*/
ENTRY(ia64_leave_syscall)
PT_REGS_UNWIND_INFO(0)
+#ifdef CONFIG_MICROSTATE
+ br.call.sptk.many rp=invoke_msa_end_syscall
+1:
+#endif
/*
* work.need_resched etc. mustn't get changed by this CPU before it
returns to
inappropriate use of in_atomic()
in_atomic() is not a reliable indication of whether it is currently safe to call schedule(). This is because the lockdepth beancounting which in_atomic() uses is only accumulated if CONFIG_PREEMPT=y. in_atomic() will return false inside spinlocks if CONFIG_PREEMPT=n. Consequently the use of in_atomic() in the below files is probably deadlocky if CONFIG_PREEMPT=n: arch/ppc64/kernel/viopath.c drivers/net/irda/sir_kthread.c drivers/net/wireless/airo.c drivers/video/amba-clcd.c drivers/acpi/osl.c drivers/ieee1394/ieee1394_transactions.c drivers/infiniband/core/mad.c Note that the same beancounting is used for the scheduling while atomic warning, so if the code calls schedule with locks held, we won't get a warning. Both are tied to CONFIG_PREEMPT=y. The kernel provides no reliable runtime way of detecting whether or not it is safe to call schedule(). Can we please find ways to change the above code to not use in_atomic()? Then we can whack #ifndef MODULE around its definition to reduce reoccurrences. Will probably rename it to something more scary as well. Thanks. - 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: inappropriate use of in_atomic()
Consequently the use of in_atomic() in the below files is probably deadlocky if CONFIG_PREEMPT=n: ... drivers/infiniband/core/mad.c Thanks for pointing this out. I'll get you a patch in the next day or two. As you can probably tell, the code is just trying to decide whether to use GFP_ATOMIC or GFP_KERNEL to allocate a couple of things, depending on what context we're being called from. So at worst we can just change to GFP_ATOMIC unconditionally. I'll check into whether we can do something cleverer, but just going the GFP_ATOMIC route won't be horrible. Thanks, Roland - 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, RFC 1/3] Add sem_getcount() to arches that lack it
Jody McIntyre [EMAIL PROTECTED] wrote: parisc and frv define sem_getcount() in semaphore.h, which returns the current semaphore value. This is cleaner than doing atomic_read(semaphore.count), currently done in drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work on all architectures if sem_getcount() is added. That's a fairly bizarre thing to want to do. Would it be hard to modify xfs and 1394 to stop wanting to read a semaphore's up() count? (Why do they want to do this anyway?) - 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: Average power consumption in S3?
On Thu, 2005-03-10 at 22:46 -0500, Theodore Ts'o wrote: On Thu, Mar 10, 2005 at 07:08:26PM +0100, Moritz Muehlenhoff wrote: I've got the e100 and with WOL disabled and Matthew's hacked radeontool power consumption decreases to 970 mWh. I have a T40p, and with the following patches (versus 2.6.11) and the following sleep script, I have power consuption down to 580 mWh. The 05-radeonfb-Thinkpad-Power.patch will have to patched with your specific Thinkpad model number, or booted with the force_sleep option. See the Linux thinkpad mailing list ([EMAIL PROTECTED]) archives for more information. Warning: The 05-radeonfb-Thinkpad-Power.patch is not quite ready for merging, but compared to completely pathetic battery life when using ACPI's suspend-to-memory without them, it's definitely worth it. Hi Ted ! Hopefully, somebody is gathering those patches. I intend to merge them all at one point, though I can't promise it will happen before 2.6.12. It would be good to ping me regulary though ;) I've sort-of been waiting for ATI to tell me how to retreive the proper memory register setting from the BIOS, since the code in there currently is quite powerbook specific, and might not write the exact correct value on all models. I suppose it works fine on yours so far, but I'd rather have a way to know the right value ... unfortunately, they didn't reply on this request. 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/
Re: oops / 2.6.11 / run_timer_softirq (mountvirtfs)
jerome lacoste [EMAIL PROTECTED] wrote: On an VIA EPIA board, I got this single oops at boot. Wasn't stored on file so I had to take a screenshot with a digital camera. Basicallly goes along those lines: Process: S36mountvirtfs Call trace: run_timer_softirq+0x16f/0x200 __do_softirq do_softirq irq_exit do_IRQ common_interrupt Process is found here on my system: lrwxr-xr-x 1 root root 21 Mar 1 00:29 /etc/rcS.d/S36mountvirtfs - ../init.d/mountvirtfs The exact screenshot (500k) can be found here: http://coffeebreaks.dyndns.org/~jerome/static/images/linux/oops_2.6.11_run_timer_softirq_boot.jpg An oops in cascade() is tricky. Normally it means that some piece of code has done something bad with a kernel timer. Later, a clock tick happens and the kernel falls over. We're left with no hints as to which part of the kernel misbehaved. Please try enabling CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC and see if that reveals any additional info. Apart from that, you have a lot of modules configured there. Please try disabling them all, see if the oops goes away. If it does then try re-enabling them, see if you can narrow it down to the one which is causing the timer list corruption. Thanks. - 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] -stable, how it's going to work.
Neil Brown wrote: If a data corruption bug has been there for 10 weeks without being noticed, then the real risk is not that great. We are calling it -release, not -hardened. I disagree. If there's a simple, obvious, small fix that passes all the other criteria, it should go into -stable ASAP after passing review. Then the -stable maintainers will push the fix to Andrew/Linux, and it will go into the next 2.6.x. Let's keep -stable as good as possible, while still abiding by all the other rules. 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/
Re: Microstate Accounting for 2.6.11
Andrew == Andrew Morton [EMAIL PROTECTED] writes: Andrew Peter Chubb [EMAIL PROTECTED] wrote: Timing data on threads at present is pretty crude: when the timer interrupt occurs, a tick is added to either system time or user time for the currently running thread. Thus in an unpacthed kernel one can distinguish three timed states: On-cpu in userspace, on-cpu in system space, and not running. The actual number of states is much larger. A thread can be on a runqueue or the expired queue (i.e., ready to run but not running), sleeping on a semaphore or on a futex, having its time stolen to service an interrupt, etc., etc. This patch adds timers per-state to each struct task_struct, so that time in all these states can be tracked. This patch contains the core code do the timing, and to initialise the timers. Subsequent patches enable the code (by adding Kconfig options) and add hooks to track state changes. Andrew Why does the kernel need this feature? I find that it's useful when trying to work out why a thread is going more slowly than it needs to. Userspace tools in the CVS repository at gelato.unsw.edu.au let you graph in real time the time spent in each state, so you get graphs like this: http://gelato.unsw.edu.au/patches/snapshot.png which shows mplay skipping because of a slow disk/filesystem. Andrew Have you any numbers on the overhead? Around 5% on LMbench context switch numbers for uniprocessor, negligeable on SMP (but SMP context switch results are horrible at the moment according to LMbench2 -- almost 16usec); select on 10 fd goes from 1.665 usec to 1.701; Andrew The preempt_disable() in sys_msa() seems odd. Yes I only added that yesterday. It's to prevent migration while updating the current timer. All the other places where the current timer are updated are naturally protected this. It should probably be a local_irq_disable() instead. Peter C - 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, RFC 1/3] Add sem_getcount() to arches that lack it
Andrew (Why do they want to do this anyway?) Neither use seems really fundamental. The XFS use is explicitly inside #ifdef DEBUG and seems to be used only for assertions. ieee1394 is just sticking the value in a read-only sysfs attribute. - R. - 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/
IA32 (2.6.11 - 2005-03-10.16.00) - 1 New warnings
drivers/video/intelfb/intelfbdrv.h:31: warning: 'intelfb_setup' declared `static' but never defined - 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: binary drivers and development
Lennart Sorensen writes: You forgot the very important: - Only works on architecture it was compiled for. So anyone not using i386 (and maybe later x86-64) is simply out of luck. What do nvidia users that want accelerated nvidia drivers for X DRI do right now if they have a powerpc or a sparc or an alpha? How about porting Linux to a new architecture. With binary drivers you now start out with no drivers on the new architecture except for the ones you have source for. Not very productive. Rik van Riel writes: No, it wouldn't. I can use a source code driver on x86, x86-64 and PPC64 systems, but a binary driver is only usable on the architecture it was compiled for. Source code is way more portable than binary anything. The kernel already has an AML interpreter for ACPI. **duck** As for portability, AML would do the job. It beats typical vendor source code IMHO, because endianness and integer size are well-defined. (like the Java VM and .net) For the x86 and ia64 users, the AML interpreter is probably already compiled into the kernel. Most people need it to set up SMP or power management. So, no added bloat even. AML code is fairly well controlled and isolated. There is of course the backdoor via DMA for the truly determined evil author, but such paranoia is rather extreme. AML is really designed for this sort of task. As with any interpreter, there are ways (JIT) to make the AML interpreter go faster if need be. - 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, RFC 1/3] Add sem_getcount() to arches that lack it
On Thu, Mar 10, 2005 at 09:10:42PM -0800, Roland Dreier wrote: Andrew (Why do they want to do this anyway?) Neither use seems really fundamental. The XFS use is explicitly inside #ifdef DEBUG and seems to be used only for assertions. Right, our peeking at that value is debug-only (so usually its not even compiled in). I wouldn't go out of your way to add a more permanent interface just for this, we can live without it. cheers. -- Nathan - 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/
2.6.10-as7
Hi, 2.6.10-as is now in purely maintenance mode; that is, I'll only include security fixes or quick things that people send me (that don't require much effort on my part :). This includes the security fix from 2.6.11.2. I'll have 2.6.11-as1 soon, after I sync up w/ Debian stuff and go through about 800 more changesets. We'll see where 2.6.x.y goes from there; if feeding patches is easy, then there won't be much need for -as; otherwise, I'll continue doing it as a vendor base (at least one person who does vendor kernels has expressed the opinion that they'd prefer 2.6.x.y to be a bit more liberal than it currently is). Also, note the email address; I'm trying to phase out usage of my voxel.net address, as I no longer work there. The -as tree is intended to include only security and bugfixes, from various sources. I do not include hardware driver updates (specifically, anything that changes how the hardware registers themselves are probed/poked), large subsystem updates, cleanups, and so on; only fixes that will not contain regressions. The hope is that vendors/distributors can use this tree as a base for their kernels. It is also what I'd want a 2.6.x.y tree to have. The kernel patches can be grabbed from here: http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as7/ 86f79bd2e50963829da3c0456804df0f ChangeLog e852090bafa5ea4ff7c6b922d33ec1e7 linux-2.6.10-as7.tar.gz 8ca1ac89c1eac2111f146cc21d6193c2 patch-2.6.10-as7.gz Changes from 2.6.10-as6: 2005-03-10 21:51:49 GMT Andres Salomon [EMAIL PROTECTED] patch-155 Summary: tag 2.6.10-as7 Revision: linux--dilinger--0--patch-155 modified files: 000-extraversion.patch 2005-03-10 21:50:21 GMT Andres Salomon [EMAIL PROTECTED] patch-154 Summary: 144-sys_epoll_wait_int_overflow.patch Revision: linux--dilinger--0--patch-154 [SECURITY] sys_epoll_wait contains an integer overflow; see http://seclists.org/lists/fulldisclosure/2005/Mar/0293.html for additional details. new files: .arch-ids/144-sys_epoll_wait_int_overflow.patch.id 144-sys_epoll_wait_int_overflow.patch 2005-03-10 21:46:21 GMT Andres Salomon [EMAIL PROTECTED] patch-153 Summary: 143-sysfs_write_file_signedness_problem.patch Revision: linux--dilinger--0--patch-153 [SYSFS] sysfs_write_file assigns the result of fill_write_buffer (which is signed and returns negative upon error) to an unsigned int. Clearly, bad and wrong.. new files: .arch-ids/143-sysfs_write_file_signedness_problem.patch.id 143-sysfs_write_file_signedness_problem.patch -- Andres Salomon [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [PATCH] PCI Express Advanced Error Reporting Driver
On Thu, Mar 10, 2005 at 03:04:18PM -0800, long wrote: PCI Express error signaling can occur on the PCI Express link itself or on behalf of transactions initiated on the link. PCI Express defines the Advanced Error Reporting capability, which is implemented with a PCI Express advanced error reporting extended capability structure, to provide more robust error reporting. With the Advanced Error Reporting capability a PCI Express component, which detects an error, can send an error message to the Root Port associated with its hierarchy. snip This patch was too big for lkml, and should also be sent to the linux-pci list. Care to split it up and resend it? Also, how does this tie into the recent discussion about pci error recovery? 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: User mode drivers: part 2: PCI device handling (patch 1/2 for 2.6.11)
Peter Chubb writes: There are three new system calls: long usr_pci_open(int bus, int slot, int function, __u64 dma_mask); Returns a filedescriptor for the PCI device described by bus,slot,function. It also enables the device, and sets it up as a bus-mastering DMA device, with the specified dma mask. You forgot the PCI domain (a.k.a. hose, phb...) number. Also, you might encode bus,slot,function according to the PCI spec. So that gives: long usr_pci_open(unsigned pcidomain, unsigned devspec, __u64 dmamask); (with the user library returning an int instead of long) - 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] don't call unblank at irq time
Hi !
This patch removes the call to unblank() from printk, and avoids calling
unblank at irq() time _unless_ oops_in_progress is 1. I also export
oops_in_progress() so drivers who care like radeonfb can test it and
know what to do. I audited call sites of unblank_screen(),
console_unblank(), etc... and I _hope_ I got them all, the patch
includes a small patch to the s390 bust_spinlocks code that sets
oops_in_progress back to 0 _after_ unblanking for example.
I added a few might_sleep() to help us catch possible remaining callers.
I'll soon write a document explaining fbdev locking. The current
situation after this patch is that:
- All callbacks have console_semaphore held (fbdev's are fully
serialised).
- Everything is called in schedule'able context, except the cfb_*
rendering operations and cursor operations, with the special case of
unblank who can be called at any time when oops_in_progress is true. A
driver that needs to sleep in it's unblank implementation is welcome to
test that variable and use a fallback path (or just do nothing if it's
not simple).
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Index: linux-work/kernel/printk.c
===
--- linux-work.orig/kernel/printk.c 2005-03-10 11:37:34.0 +1100
+++ linux-work/kernel/printk.c 2005-03-11 14:51:42.0 +1100
@@ -54,7 +54,12 @@
EXPORT_SYMBOL(console_printk);
+/*
+ * Low lever drivers may need that to know if they can schedule in
+ * their unblank() callback or not. So let's export it.
+ */
int oops_in_progress;
+EXPORT_SYMBOL(oops_in_progress);
/*
* console_sem protects the console_drivers list, and also
@@ -744,12 +749,15 @@
struct console *c;
/*
-* Try to get the console semaphore. If someone else owns it
-* we have to return without unblanking because console_unblank
-* may be called in interrupt context.
+* console_unblank can no longer be called in interrupt context unless
+* oops_in_progress is set to 1..
*/
- if (down_trylock(console_sem) != 0)
- return;
+ if (oops_in_progress) {
+ if (down_trylock(console_sem) != 0)
+ return;
+ } else
+ acquire_console_sem();
+
console_locked = 1;
console_may_schedule = 0;
for (c = console_drivers; c != NULL; c = c-next)
Index: linux-work/arch/s390/mm/fault.c
===
--- linux-work.orig/arch/s390/mm/fault.c2005-01-24 17:09:26.0
+1100
+++ linux-work/arch/s390/mm/fault.c 2005-03-11 14:46:21.0 +1100
@@ -62,8 +62,8 @@
oops_in_progress = 1;
} else {
int loglevel_save = console_loglevel;
- oops_in_progress = 0;
console_unblank();
+ oops_in_progress = 0;
/*
* OK, the message is on the console. Now we call printk()
* without oops_in_progress set so that printk will give klogd
Index: linux-work/drivers/char/vt.c
===
--- linux-work.orig/drivers/char/vt.c 2005-03-10 11:37:24.0 +1100
+++ linux-work/drivers/char/vt.c2005-03-11 14:54:05.0 +1100
@@ -2220,9 +2220,6 @@
}
set_cursor(vc);
- if (!oops_in_progress)
- poke_blanked_console();
-
quit:
clear_bit(0, printing);
}
@@ -2823,6 +2820,13 @@
{
struct vc_data *vc;
+ /* This should now always be called from a sane (read: can schedule)
+* context for the sake of the low level drivers, except in the special
+* case of oops_in_progress
+*/
+ if (!oops_in_progress)
+ might_sleep();
+
WARN_CONSOLE_UNLOCKED();
ignore_poke = 0;
@@ -2879,6 +2883,14 @@
{
WARN_CONSOLE_UNLOCKED();
+ /* Add this so we quickly catch whoever might call us in a non
+* safe context. Nowadays, unblank_screen() isn't to be called in
+* atomic contexts and is allowed to schedule (with the special case
+* of oops_in_progress, but that isn't of any concern for this
+* function. --BenH.
+*/
+ might_sleep();
+
/* This isn't perfectly race free, but a race here would be mostly
harmless,
* at worse, we'll do a spurrious blank and it's unlikely
*/
-
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, RFC 1/3] Add sem_getcount() to arches that lack it
On Thu, Mar 10, 2005 at 08:55:03PM -0800, Andrew Morton wrote: Jody McIntyre [EMAIL PROTECTED] wrote: parisc and frv define sem_getcount() in semaphore.h, which returns the current semaphore value. This is cleaner than doing atomic_read(semaphore.count), currently done in drivers/ieee1394/nodemgr.c and fs/xfs/linux-2.6/xfs_buf.c, and will work on all architectures if sem_getcount() is added. That's a fairly bizarre thing to want to do. Would it be hard to modify xfs and 1394 to stop wanting to read a semaphore's up() count? The count is the number of free transaction labels (1394 async is transaction-based) and is initialized to 64. When a new transaction label is needed, the requestor does a down(), then locks the tlabel variables and allocates a new one. When a transaction label is freed, an up() occurs. The semaphore's up() count is therefore the number of free tlabels, and the number of outstanding transactions is (64 - count). I can imagine situations in which this would be a useful statistic, but I'm not sure any of them actually exist. I haven't investigated xfs, but modifying 1394 would be fairly easy. I could add a second variable that tracks the up() count, or just drop the sysfs attribute that reports the number. The first option seems a bit wasteful, but only slightly. I thought this patch was worthwhile based on xfs wanting to do this and 3 arches already having (unused) implementations of sem_getcount/sema_count. If this patch isn't accepted, we should get rid of the xfs and 1394 hacks and delete sem_getcount (parisc, frv) and sema_count (arm) as they are unused. Jody (Why do they want to do this anyway?) -- - 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] sealevel 8 port RS-232/RS-422/RS-485 board
Vendor Sealevel suggested these changes for its new board. Tried them,
they work with the card. Please apply the patch below, which was made
from 2.6.10 but can be applied to 2.6.11.2 without errors.
Dick
--- linux/drivers/serial/8250_pci.orig 2005-03-10 13:09:39.0 -0600
+++ linux/drivers/serial/8250_pci.c 2005-03-10 15:03:39.0 -0600
@@ -1867,6 +1867,9 @@
{ PCI_VENDOR_ID_SEALEVEL, PCI_DEVICE_ID_SEALEVEL_COMM8,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b2_8_115200 },
+ { PCI_VENDOR_ID_SEALEVEL, PCI_DEVICE_ID_SEALEVEL_UCOMM8,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_b2_8_115200 },
{ PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_GTEK_SERIAL2,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
--- linux/drivers/pci/pci.ids.orig 2005-03-10 13:10:10.0 -0600
+++ linux/drivers/pci/pci.ids 2005-03-10 15:21:43.0 -0600
@@ -5714,6 +5714,7 @@
7401 Four Port RS-232 Interface
7402 Four Port RS-422/485 Interface
7801 Eight Port RS-232 Interface
+ 7804 Eight Port RS-232/422/485 Interface
8001 8001 Digital I/O Adapter
135f I-Data International A-S
1360 Meinberg Funkuhren
--- linux/include/linux/pci_ids.h.orig 2005-03-10 13:11:25.0 -0600
+++ linux/include/linux/pci_ids.h 2005-03-10 15:06:07.0 -0600
@@ -1780,6 +1780,7 @@
#define PCI_DEVICE_ID_SEALEVEL_UCOMM2320x7202
#define PCI_DEVICE_ID_SEALEVEL_COMM4 0x7401
#define PCI_DEVICE_ID_SEALEVEL_COMM8 0x7801
+#define PCI_DEVICE_ID_SEALEVEL_UCOMM8 0x7804
#define PCI_VENDOR_ID_HYPERCOPE0x1365
#define PCI_DEVICE_ID_HYPERCOPE_PLX0x9050
-
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 2.6.11] fix: drivers/base/class.c
fix: drivers/base/class.c
fix how? What are you fixing?
I'm sorry. Previous subject was [PATCH 2.6.11] fix call kobject_get_path()
with zero kobject argument in drivers/base/class.c
diff -uNrp linux/drivers/base/class.orig.c linux/drivers/base/class.c
--- linux/drivers/base/class.orig.c 2005-03-10 12:19:00.0 +0300
+++ linux/drivers/base/class.c 2005-03-10 13:59:27.0 +0300
@@ -307,12 +307,14 @@ static int class_hotplug(struct kset *ks
if (class_dev-dev) {
/* add physical device, backing this device */
struct device *dev = class_dev-dev;
Your email client ate all of the tabs, this patch can't be applied :(
oops :(
I send patch as attachment.
Let me guess, you are using an out-of-tree driver that incorrectly sets
up the kobject
I use standard cdc_acm driver from 2.6.11 for Motorola C350 mobile phone
build-in GPRS modem (USB).
In the function (see devices/usb/class/cdc-acm.c):
static void acm_tty_close(struct tty_struct *tty, struct file *filp)
{
struct acm *acm = tty-driver_data;
if (!acm || !acm-used)
return;
down(open_sem);
if (!--acm-used) {
if (acm-dev) {
acm_set_control(acm, acm-ctrlout = 0);
usb_kill_urb(acm-ctrlurb);
usb_kill_urb(acm-writeurb);
usb_kill_urb(acm-readurb);
} else {
-
Problem, take place here:
tty_unregister_device(acm_tty_driver, acm-minor);
--
acm_table[acm-minor] = NULL;
usb_free_urb(acm-ctrlurb);
usb_free_urb(acm-readurb);
usb_free_urb(acm-writeurb);
kfree(acm);
}
}
up(open_sem);
}
and the hotplug userspace code doesn't like the NULL in
the strings?
When I unplug my mobile phone (or my phone lost GPRS network) , I have OOPS:
Mar 6 00:55:52 toshiba kernel: 6usb 2-1: USB disconnect, address 4
Mar 6 00:55:53 toshiba kernel: 1Unable to handle kernel NULL pointer
dereference at virtual address
Mar 6 00:55:53 toshiba kernel: printing eip:
Mar 6 00:55:53 toshiba kernel: c0255299
Mar 6 00:55:53 toshiba kernel: *pde =
Mar 6 00:55:53 toshiba kernel: Oops: [#1]
Mar 6 00:55:53 toshiba kernel: PREEMPT
Mar 6 00:55:53 toshiba kernel: Modules linked in: ppp_deflate zlib_deflate
bsd_comp ppp_async crc_ccitt ppp_generic slhc i
pt_REJECT ipt_LOG iptable_filter ipt_MASQUERADE iptable_nat ip_conntrack
ip_tables pktcdvd snd_pcm_oss snd_mixer_oss rtc pcs
pkr usbhid intel_agp intelfb uhci_hcd ehci_hcd i8xx_tco 8250_pci 8250
serial_core snd_intel8x0m eepro100 mii evdev pcmcia ye
nta_socket rsrc_nonstatic pcmcia_core nls_koi8_r ntfs cdc_acm usb_storage
usbkbd usbmouse usbcore msr cpuid sg sd_mod scsi_m
od dummy ide_cd cdrom snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd
soundcore snd_page_alloc agpgart
Mar 6 00:55:53 toshiba kernel: CPU:0
Mar 6 00:55:53 toshiba kernel: EIP:0060:[c0255299]Not tainted VLI
Mar 6 00:55:53 toshiba kernel: EFLAGS: 00010246 (2.6.11)
Mar 6 00:55:53 toshiba kernel: EIP is at get_kobj_path_length+0x29/0x50
Mar 6 00:55:53 toshiba kernel: eax: ebx: ecx:
edx:
Mar 6 00:55:53 toshiba kernel: esi: 0001 edi: ebp: d4397d9c
esp: d4397d8c
Mar 6 00:55:53 toshiba kernel: ds: 007b es: 007b ss: 0068
Mar 6 00:55:53 toshiba kernel: Process pppd (pid: 6057, threadinfo=d4396000
task=d432da20)
Mar 6 00:55:53 toshiba kernel: Stack: dedf5bb8 00d0 dedf5b94 d6dfa298
d4397db8 c0255339 d4397dc4 dedf5bb8
Mar 6 00:55:53 toshiba kernel:c041f708 dedf5b94 d6dfa298 d4397dfc
c02bc68f 0286 fffd
Mar 6 00:55:53 toshiba kernel: 21ac27d7 de53d829 c039d8ab
c041f720 d6dfa90c
Mar 6 00:55:53 toshiba kernel: Call Trace:
Mar 6 00:55:53 toshiba kernel: [c0103e3a] show_stack+0x7a/0x90
Mar 6 00:55:53 toshiba kernel: [c0103fb9] show_registers+0x149/0x1b0
Mar 6 00:55:53 toshiba kernel: [c01041ad] die+0xdd/0x170
Mar 6 00:55:53 toshiba kernel: [c01157aa] do_page_fault+0x30a/0x65a
Mar 6 00:55:53 toshiba kernel: [c0103abf] error_code+0x2b/0x30
Mar 6 00:55:53 toshiba kernel: [c0255339] kobject_get_path+0x19/0x60
Mar 6 00:55:53 toshiba kernel: [c02bc68f] class_hotplug+0x6f/0x160
Mar 6 00:55:53 toshiba kernel: [c0255ec4] kobject_hotplug+0x1b4/0x2c0
Mar 6 00:55:53 toshiba kernel: [c0255660] kobject_del+0x10/0x20
Mar 6 00:55:53 toshiba kernel: [c02bcab2] class_device_del+0x92/0xc0
Mar 6 00:55:53 toshiba kernel: [c02bcaeb] class_device_unregister+0xb/0x20
Mar 6 00:55:53 toshiba kernel: [dfc795bc] acm_tty_close+0x14c/0x160
[cdc_acm]
Mar 6 00:55:53 toshiba kernel: [c029f6a2] release_dev+0x7f2/0x810
Mar 6 00:55:53 toshiba kernel: [c029fb12] tty_release+0x12/0x20
Mar 6 00:55:53 toshiba kernel: [c0156c9b] __fput+0x12b/0x140
Mar 6 00:55:53 toshiba kernel: [c01554cf] filp_close+0x4f/0x80
Mar 6 00:55:53 toshiba kernel: [c010300f] syscall_call+0x7/0xb
Mar 6 00:55:53 toshiba kernel: Code: 00 00 55 ba ff ff ff ff 89 e5 57 56 be 01
00 00 00 53 83 ec 04 31 db 89 45 f0 90 8d b
4 26 00 00 00 00 8b
Re: [BK PATCHES] kbuild updates
If this is the same version as in 2.6.11-mm2 (you didn't offer a GNU patch so that I could check it), the following is still present: http://www.ussg.iu.edu/hypermail/linux/kernel/0502.2/1507.html Thanks Adrian, I forgot about that one. It is now fixed and pushed to bk://linux-sam.bkbits.net/kbuild 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] ppc32: move powermac backlight stuff to a workqueue
Hi !
The powermac has a kernel-based driver for controlling the backlight
from the keyboard that used to call into some fbdev's from interrupt
contexts. This patch moves it to a workqueue (and additionally makes
sure the console semaphore is taken and held).
I hope I'll replace this by the new backlight framework in a future
kernel version, but for now, this will fix the immediate issues with
radeon.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Index: linux-work/arch/ppc/platforms/pmac_backlight.c
===
--- linux-work.orig/arch/ppc/platforms/pmac_backlight.c 2005-01-24
17:09:23.0 +1100
+++ linux-work/arch/ppc/platforms/pmac_backlight.c 2005-03-11
15:18:54.0 +1100
@@ -25,14 +25,19 @@
#include linux/adb.h
#include linux/pmu.h
-static struct backlight_controller *backlighter = NULL;
-static void* backlighter_data = NULL;
-static int backlight_autosave = 0;
+static struct backlight_controller *backlighter;
+static void* backlighter_data;
+static int backlight_autosave;
static int backlight_level = BACKLIGHT_MAX;
static int backlight_enabled = 1;
+static int backlight_req_level = -1;
+static int backlight_req_enable = -1;
-void __pmac
-register_backlight_controller(struct backlight_controller *ctrler, void *data,
char *type)
+static void backlight_callback(void *);
+static DECLARE_WORK(backlight_work, backlight_callback, NULL);
+
+void __pmac register_backlight_controller(struct backlight_controller *ctrler,
+ void *data, char *type)
{
struct device_node* bk_node;
char *prop;
@@ -83,16 +88,18 @@
backlight_level = req.reply[0] 4;
}
#endif
+ acquire_console_sem();
if (!backlighter-set_enable(1, backlight_level, data))
backlight_enabled = 1;
+ release_console_sem();
- printk(KERN_INFO Registered \%s\ backlight controller, level:
%d/15\n,
- type, backlight_level);
+ printk(KERN_INFO Registered \%s\ backlight controller,
+ level: %d/15\n, type, backlight_level);
}
EXPORT_SYMBOL(register_backlight_controller);
-void __pmac
-unregister_backlight_controller(struct backlight_controller *ctrler, void
*data)
+void __pmac unregister_backlight_controller(struct backlight_controller
+ *ctrler, void *data)
{
/* We keep the current backlight level (for now) */
if (ctrler == backlighter data == backlighter_data)
@@ -100,22 +107,29 @@
}
EXPORT_SYMBOL(unregister_backlight_controller);
-int __pmac
-set_backlight_enable(int enable)
+static int __pmac __set_backlight_enable(int enable)
{
int rc;
if (!backlighter)
return -ENODEV;
- rc = backlighter-set_enable(enable, backlight_level, backlighter_data);
+ acquire_console_sem();
+ rc = backlighter-set_enable(enable, backlight_level,
+backlighter_data);
if (!rc)
backlight_enabled = enable;
+ release_console_sem();
return rc;
}
+int __pmac set_backlight_enable(int enable)
+{
+ backlight_req_enable = enable;
+ schedule_work(backlight_work);
+}
+
EXPORT_SYMBOL(set_backlight_enable);
-int __pmac
-get_backlight_enable(void)
+int __pmac get_backlight_enable(void)
{
if (!backlighter)
return -ENODEV;
@@ -123,8 +137,7 @@
}
EXPORT_SYMBOL(get_backlight_enable);
-int __pmac
-set_backlight_level(int level)
+static int __pmac __set_backlight_level(int level)
{
int rc = 0;
@@ -134,10 +147,12 @@
level = BACKLIGHT_OFF;
if (level BACKLIGHT_MAX)
level = BACKLIGHT_MAX;
+ acquire_console_sem();
if (backlight_enabled)
rc = backlighter-set_level(level, backlighter_data);
if (!rc)
backlight_level = level;
+ release_console_sem();
if (!rc !backlight_autosave) {
level =1;
if (level 0x10)
@@ -146,13 +161,35 @@
}
return rc;
}
+int __pmac set_backlight_level(int level)
+{
+ backlight_req_level = level;
+ schedule_work(backlight_work);
+}
+
EXPORT_SYMBOL(set_backlight_level);
-int __pmac
-get_backlight_level(void)
+int __pmac get_backlight_level(void)
{
if (!backlighter)
return -ENODEV;
return backlight_level;
}
EXPORT_SYMBOL(get_backlight_level);
+
+static void backlight_callback(void *dummy)
+{
+ int level, enable;
+
+ do {
+ level = backlight_req_level;
+ enable = backlight_req_enable;
+ mb();
+
+ if (level = 0)
+ __set_backlight_level(level);
+ if (enable = 0)
+ __set_backlight_enable(enable);
+ } while(cmpxchg(backlight_req_level, level, -1) != level ||
+
