[PATCH] [Bug 3736] Bug in tty_io.c after changes between 2.6.9-rc1-bk1 and 2.6.9-rc1-bk2
Tried to fix a bug http://bugzilla.kernel.org/show_bug.cgi?id=3736 which appeared between kernels 2.6.9-rc1-bk1 and 2.6.9-rc1-bk2. Suceeded to localize it to part of changes in drivers/char/tty_io.c. I guess changes were according changelog: --- [EMAIL PROTECTED], 2004-08-24 12:29:18-07:00, [EMAIL PROTECTED] [PATCH] /dev/ptmx open() fixes If tty_open() fails for a normal serial device, we end up doing cleanups that should only happen for failed open of /dev/ptmx. The results are not pretty - devpts et.al. end up very confused. That's what gave problems with ptmx. This splits ptmx file_operations from the normal case and cleans up both tty_open() and (new) ptmx_open(). Survived serious beating. --- Finally located that a problem seems to be a simple typo ( --- linux-2.6.10/drivers/char/tty_io.c~1 2004-12-24 23:34:58.0 +0200 +++ linux-2.6.10/drivers/char/tty_io.c 2005-01-22 10:54:32.0 +0200 @@ -1148,7 +1148,7 @@ static inline void pty_line_name(struct int i = index + driver->name_base; /* ->name is initialized to "ttyp", but "tty" is expected */ sprintf(p, "%s%c%x", - driver->subtype == PTY_TYPE_SLAVE ? "tty" : driver->name, + driver->subtype == PTY_TYPE_SLAVE ? "pty" : driver->name, ptychar[i >> 4 & 0xf], i & 0xf); } At least as I tested, it fixes the problem on one of systems on which I tested. Andris - 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]sched: Isochronous class v2 for unprivileged soft rt scheduling
Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> I'll try building a SCHED_RR version of JACK. I still don't think it >> will make any difference. But my intuition isn't working very well >> right now, so I need more data. > > Could be that despite what it appears, FIFO behaviour may be desirable > to RR. Also the RR in SCHED_ISO is pretty fast at 10ms. However with > nothing else really running it just shouldn't matter... That's the way I see it, too. > There is some sort of privileged memory handling when jackd is running > as root as well, so I don't know how that features here. I can't > imagine it's a real issue though. We use mlockall() to avoid page faults in the audio path. That should be happening in all these tests. The JACK server would complain if the request were failing, and it doesn't. How can I verify that the pages are actually locked? (Even without mlock(), I don't think I would run out of memory.) -- joq - 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][8/12] InfiniBand/mthca: test IRQ routing during initialization
When we switch to interrupt-driven command mode, test interrupt
generation with a NOP firmware command. Broken MSI/MSI-X and
interrupt line routing problems seem to be very common, and this makes
the error message much clearer -- before this change we would
mysteriously fail when initializing the QP table.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_cmd.h 2005-01-23
20:49:34.829362648 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_cmd.h2005-01-23
20:52:01.964994632 -0800
@@ -289,6 +289,7 @@
u8 *status);
int mthca_MGID_HASH(struct mthca_dev *dev, void *gid, u16 *hash,
u8 *status);
+int mthca_NOP(struct mthca_dev *dev, u8 *status);
#define MAILBOX_ALIGN(x) ((void *) ALIGN((unsigned long) (x),
MTHCA_CMD_MAILBOX_ALIGN))
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_main.c 2005-01-23
20:38:50.947247608 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_main.c 2005-01-23
20:52:01.962994936 -0800
@@ -570,6 +570,7 @@
static int __devinit mthca_setup_hca(struct mthca_dev *dev)
{
int err;
+ u8 status;
MTHCA_INIT_DOORBELL_LOCK(>doorbell_lock);
@@ -615,6 +616,18 @@
goto err_eq_table_free;
}
+ err = mthca_NOP(dev, );
+ if (err || status) {
+ mthca_err(dev, "NOP command failed to generate interrupt,
aborting.\n");
+ if (dev->mthca_flags & (MTHCA_FLAG_MSI | MTHCA_FLAG_MSI_X))
+ mthca_err(dev, "Try again with MSI/MSI-X disabled.\n");
+ else
+ mthca_err(dev, "BIOS or ACPI interrupt routing
problem?\n");
+
+ goto err_cmd_poll;
+ } else
+ mthca_dbg(dev, "NOP command IRQ test passed\n");
+
err = mthca_init_cq_table(dev);
if (err) {
mthca_err(dev, "Failed to initialize "
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_cmd.c 2005-01-23
20:49:34.828362800 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_cmd.c2005-01-23
20:52:01.963994784 -0800
@@ -1757,3 +1757,8 @@
pci_unmap_single(dev->pdev, indma, 16, PCI_DMA_TODEVICE);
return err;
}
+
+int mthca_NOP(struct mthca_dev *dev, u8 *status)
+{
+ return mthca_cmd(dev, 0, 0x1f, 0, CMD_NOP, msecs_to_jiffies(100),
status);
+}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][3/12] InfiniBand/mthca: implement modifying port attributes
Implement the port_modify() device method for mthca using the SET_IB
firmware command. In particular this allows changing the port
capability mask.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_cmd.h 2005-01-23
20:38:50.944248064 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_cmd.h2005-01-23
20:39:02.039561320 -0800
@@ -215,6 +215,13 @@
u64 si_guid;
};
+struct mthca_set_ib_param {
+ int set_si_guid;
+ int reset_qkey_viol;
+ u64 si_guid;
+ u32 cap_mask;
+};
+
int mthca_cmd_use_events(struct mthca_dev *dev);
void mthca_cmd_use_polling(struct mthca_dev *dev);
void mthca_cmd_event(struct mthca_dev *dev, u16 token,
@@ -241,6 +248,8 @@
int port, u8 *status);
int mthca_CLOSE_IB(struct mthca_dev *dev, int port, u8 *status);
int mthca_CLOSE_HCA(struct mthca_dev *dev, int panic, u8 *status);
+int mthca_SET_IB(struct mthca_dev *dev, struct mthca_set_ib_param *param,
+int port, u8 *status);
int mthca_MAP_ICM(struct mthca_dev *dev, struct mthca_icm *icm, u64 virt, u8
*status);
int mthca_MAP_ICM_page(struct mthca_dev *dev, u64 dma_addr, u64 virt, u8
*status);
int mthca_UNMAP_ICM(struct mthca_dev *dev, u64 virt, u32 page_count, u8
*status);
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_provider.c 2005-01-23
20:38:25.991041528 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_provider.c 2005-01-23
20:39:02.036561776 -0800
@@ -137,7 +137,35 @@
u8 port, int port_modify_mask,
struct ib_port_modify *props)
{
- return 0;
+ struct mthca_set_ib_param set_ib;
+ struct ib_port_attr attr;
+ int err;
+ u8 status;
+
+ if (down_interruptible(_mdev(ibdev)->cap_mask_mutex))
+ return -ERESTARTSYS;
+
+ err = mthca_query_port(ibdev, port, );
+ if (err)
+ goto out;
+
+ set_ib.set_si_guid = 0;
+ set_ib.reset_qkey_viol = !!(port_modify_mask & IB_PORT_RESET_QKEY_CNTR);
+
+ set_ib.cap_mask = (attr.port_cap_flags | props->set_port_cap_mask) &
+ ~props->clr_port_cap_mask;
+
+ err = mthca_SET_IB(to_mdev(ibdev), _ib, port, );
+ if (err)
+ goto out;
+ if (status) {
+ err = -EINVAL;
+ goto out;
+ }
+
+out:
+ up(_mdev(ibdev)->cap_mask_mutex);
+ return err;
}
static int mthca_query_pkey(struct ib_device *ibdev,
@@ -619,6 +647,8 @@
}
}
+ init_MUTEX(>cap_mask_mutex);
+
return 0;
}
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_cmd.c 2005-01-23
20:38:50.949247304 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_cmd.c2005-01-23
20:39:02.038561472 -0800
@@ -1238,6 +1238,41 @@
return mthca_cmd(dev, 0, 0, panic, CMD_CLOSE_HCA, HZ, status);
}
+int mthca_SET_IB(struct mthca_dev *dev, struct mthca_set_ib_param *param,
+int port, u8 *status)
+{
+ u32 *inbox;
+ dma_addr_t indma;
+ int err;
+ u32 flags = 0;
+
+#define SET_IB_IN_SIZE 0x40
+#define SET_IB_FLAGS_OFFSET0x00
+#define SET_IB_FLAG_SIG(1 << 18)
+#define SET_IB_FLAG_RQK(1 << 0)
+#define SET_IB_CAP_MASK_OFFSET 0x04
+#define SET_IB_SI_GUID_OFFSET 0x08
+
+ inbox = pci_alloc_consistent(dev->pdev, SET_IB_IN_SIZE, );
+ if (!inbox)
+ return -ENOMEM;
+
+ memset(inbox, 0, SET_IB_IN_SIZE);
+
+ flags |= param->set_si_guid ? SET_IB_FLAG_SIG : 0;
+ flags |= param->reset_qkey_viol ? SET_IB_FLAG_RQK : 0;
+ MTHCA_PUT(inbox, flags, SET_IB_FLAGS_OFFSET);
+
+ MTHCA_PUT(inbox, param->cap_mask, SET_IB_CAP_MASK_OFFSET);
+ MTHCA_PUT(inbox, param->si_guid, SET_IB_SI_GUID_OFFSET);
+
+ err = mthca_cmd(dev, indma, port, 0, CMD_SET_IB,
+ CMD_TIME_CLASS_B, status);
+
+ pci_free_consistent(dev->pdev, INIT_HCA_IN_SIZE, inbox, indma);
+ return err;
+}
+
int mthca_MAP_ICM(struct mthca_dev *dev, struct mthca_icm *icm, u64 virt, u8
*status)
{
return mthca_map_cmd(dev, CMD_MAP_ICM, icm, virt, status);
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_dev.h 2005-01-23
20:38:50.950247152 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_dev.h2005-01-23
20:39:02.036561776 -0800
@@ -234,6 +234,7 @@
u64 ddr_end;
MTHCA_DECLARE_DOORBELL_LOCK(doorbell_lock)
+ struct semaphore cap_mask_mutex;
void __iomem*hcr;
void __iomem*clr_base;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-rc2
I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). But oddly enough, only for sending mail, not reading it; and not through other (reading) applications... it's a regression with respect to rc1 and earlier kernels. Basically, it can only send REALLY TINY emails... What ethereal shows me is roughly: - SMTP connect, initial handshake, ok (ACKed later) - Send two 1500 byte Ethernet packets - Each gets an ICMP destination unreachable, frag needed, next hop MTU 1492 - ... all retransmits are 1500 bytes not 1492, triggering ICMPs ... Naturally the connection goes nowhere. - 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][6/12] InfiniBand/mthca: pass full process_mad info to firmware
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Pass full extended MAD information to firmware when a work completion is
supplied to
the MAD_IFC command. This allows B_Key checking/trap generation.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_cmd.h 2005-01-23
20:39:02.039561320 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_cmd.h2005-01-23
20:49:34.829362648 -0800
@@ -280,7 +280,8 @@
void *qp_context, u8 *status);
int mthca_CONF_SPECIAL_QP(struct mthca_dev *dev, int type, u32 qpn,
u8 *status);
-int mthca_MAD_IFC(struct mthca_dev *dev, int ignore_mkey, int port,
+int mthca_MAD_IFC(struct mthca_dev *dev, int ignore_mkey, int ignore_bkey,
+ int port, struct ib_wc* in_wc, struct ib_grh* in_grh,
void *in_mad, void *response_mad, u8 *status);
int mthca_READ_MGM(struct mthca_dev *dev, int index, void *mgm,
u8 *status);
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_provider.c 2005-01-23
20:39:02.036561776 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_provider.c 2005-01-23
20:49:34.826363104 -0800
@@ -59,8 +59,8 @@
in_mad->method = IB_MGMT_METHOD_GET;
in_mad->attr_id= IB_SMP_ATTR_NODE_INFO;
- err = mthca_MAD_IFC(to_mdev(ibdev), 1,
- 1, in_mad, out_mad,
+ err = mthca_MAD_IFC(to_mdev(ibdev), 1, 1,
+ 1, NULL, NULL, in_mad, out_mad,
);
if (err)
goto out;
@@ -104,8 +104,8 @@
in_mad->attr_id= IB_SMP_ATTR_PORT_INFO;
in_mad->attr_mod = cpu_to_be32(port);
- err = mthca_MAD_IFC(to_mdev(ibdev), 1,
- port, in_mad, out_mad,
+ err = mthca_MAD_IFC(to_mdev(ibdev), 1, 1,
+ port, NULL, NULL, in_mad, out_mad,
);
if (err)
goto out;
@@ -189,8 +189,8 @@
in_mad->attr_id= IB_SMP_ATTR_PKEY_TABLE;
in_mad->attr_mod = cpu_to_be32(index / 32);
- err = mthca_MAD_IFC(to_mdev(ibdev), 1,
- port, in_mad, out_mad,
+ err = mthca_MAD_IFC(to_mdev(ibdev), 1, 1,
+ port, NULL, NULL, in_mad, out_mad,
);
if (err)
goto out;
@@ -228,8 +228,8 @@
in_mad->attr_id= IB_SMP_ATTR_PORT_INFO;
in_mad->attr_mod = cpu_to_be32(port);
- err = mthca_MAD_IFC(to_mdev(ibdev), 1,
- port, in_mad, out_mad,
+ err = mthca_MAD_IFC(to_mdev(ibdev), 1, 1,
+ port, NULL, NULL, in_mad, out_mad,
);
if (err)
goto out;
@@ -248,8 +248,8 @@
in_mad->attr_id= IB_SMP_ATTR_GUID_INFO;
in_mad->attr_mod = cpu_to_be32(index / 8);
- err = mthca_MAD_IFC(to_mdev(ibdev), 1,
- port, in_mad, out_mad,
+ err = mthca_MAD_IFC(to_mdev(ibdev), 1, 1,
+ port, NULL, NULL, in_mad, out_mad,
);
if (err)
goto out;
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_cmd.c 2005-01-23
20:39:02.038561472 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_cmd.c2005-01-23
20:49:34.828362800 -0800
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include "mthca_dev.h"
#include "mthca_config_reg.h"
@@ -1626,13 +1627,24 @@
CMD_TIME_CLASS_B, status);
}
-int mthca_MAD_IFC(struct mthca_dev *dev, int ignore_mkey, int port,
- void *in_mad, void *response_mad, u8 *status) {
+int mthca_MAD_IFC(struct mthca_dev *dev, int ignore_mkey, int ignore_bkey,
+ int port, struct ib_wc* in_wc, struct ib_grh* in_grh,
+ void *in_mad, void *response_mad, u8 *status)
+{
void *box;
dma_addr_t dma;
int err;
+ u32 in_modifier = port;
+ u8 op_modifier = 0;
-#define MAD_IFC_BOX_SIZE 512
+#define MAD_IFC_BOX_SIZE 0x400
+#define MAD_IFC_MY_QPN_OFFSET 0x100
+#define MAD_IFC_RQPN_OFFSET 0x104
+#define MAD_IFC_SL_OFFSET 0x108
+#define MAD_IFC_G_PATH_OFFSET 0x109
+#define MAD_IFC_RLID_OFFSET 0x10a
+#define MAD_IFC_PKEY_OFFSET 0x10e
+#define MAD_IFC_GRH_OFFSET0x140
box = pci_alloc_consistent(dev->pdev, MAD_IFC_BOX_SIZE, );
if (!box)
@@ -1640,11 +1652,46 @@
memcpy(box, in_mad, 256);
- err = mthca_cmd_box(dev, dma, dma + 256, port, !!ignore_mkey,
+ /*
+* Key check traps can't be generated unless we have in_wc to
+* tell us where to send the trap.
+*/
+ if (ignore_mkey || !in_wc)
+ op_modifier |= 0x1;
+
[PATCH 2.4.29] nbd: fix ioctl permissions
Hi Marcelo,
Here's a patch for nbd that Rogier recently sent me. It allows non-root
to do BLKGETSIZE, et al. on nbd devices, which he needs for his data
recovery applications.
Tested against 2.4.29. Please apply.
Thanks,
Paul
From: Rogier Wolff <[EMAIL PROTECTED]>
Signed-Off-By: Paul Clements <[EMAIL PROTECTED]>
Description: We shouldn't need CAP_SYS_ADMIN to ask for disk capacity and such.
===
diff -ur linux-2.4.28.clean/drivers/block/nbd.c
linux-2.4.28.nbd-fix/drivers/block/nbd.c
--- linux-2.4.28.clean/drivers/block/nbd.c Wed Jan 19 18:14:01 2005
+++ linux-2.4.28.nbd-fix/drivers/block/nbd.cWed Jan 19 16:36:59 2005
@@ -408,10 +408,7 @@
int dev, error, temp;
struct request sreq ;
- /* Anyone capable of this syscall can do *real bad* things */
- if (!capable(CAP_SYS_ADMIN))
- return -EPERM;
if (!inode)
return -EINVAL;
dev = MINOR(inode->i_rdev);
@@ -419,6 +416,20 @@
return -ENODEV;
lo = _dev[dev];
+
+ /* these are innocent, but */
+ switch (cmd) {
+ case BLKGETSIZE:
+ return put_user(nbd_bytesizes[dev] >> 9, (unsigned long *) arg);
+ case BLKGETSIZE64:
+ return put_user((u64)nbd_bytesizes[dev], (u64 *) arg);
+ }
+
+ /* ... anyone capable of any of the below ioctls can do *real bad*
+ things */
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
switch (cmd) {
case NBD_DISCONNECT:
printk("NBD_DISCONNECT\n");
@@ -524,10 +535,6 @@
dev, lo->queue_head.next, lo->queue_head.prev,
requests_in, requests_out);
return 0;
#endif
- case BLKGETSIZE:
- return put_user(nbd_bytesizes[dev] >> 9, (unsigned long *) arg);
- case BLKGETSIZE64:
- return put_user((u64)nbd_bytesizes[dev], (u64 *) arg);
}
return -EINVAL;
}
Rediff's Auto Response
Hi friend, I had received your message just now. Thanks for sending your message. Yours lovingly, M.Baskaran. - 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]sched: Isochronous class v2 for unprivileged soft rt scheduling
Ingo Molnar <[EMAIL PROTECTED]> writes: > just finished a short testrun with nice--20 compared to SCHED_FIFO, on a > relatively slow 466 MHz box: Has anyone done this kind of realtime testing on an SMP system? I'd love to know how they compare. Unfortunately, I don't have access to one at the moment. Are they generally better or worse for this kind of work? I'm not asking about partitioning or processor affinity, but actually using the entire SMP complex as a realtime machine. Our current jack_test scripts wouldn't exercise a multiprocessor very well. But, even those results would be interesting to know. Then, I think we could modify them to start muliple JACK servers. That will probably require using the dummy backend driver, which would need a more accurate timer source than its current usleep() call to provide reliable low latency results. (We currently drive the audio cycle from ALSA driver interrupts, but each JACK server requires a dedicated sound card for that.) -- joq - 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]sched: Isochronous class v2 for unprivileged soft rt scheduling
Jack O'Quin wrote: I'll try building a SCHED_RR version of JACK. I still don't think it will make any difference. But my intuition isn't working very well right now, so I need more data. Could be that despite what it appears, FIFO behaviour may be desirable to RR. Also the RR in SCHED_ISO is pretty fast at 10ms. However with nothing else really running it just shouldn't matter... I still wonder if some coding error might occasionally be letting a lower priority process continue running after an interrupt when it ought to be preempted. That's one distinct possiblity. Preempt code is a particular problem. You are not running into the cpu limits of SCHED_ISO so something else must be responsible. If we are higher priority than everything else and do no expire in any way there is no reason we shouldn't perform as well as SCHED_FIFO. There is some sort of privileged memory handling when jackd is running as root as well, so I don't know how that features here. I can't imagine it's a real issue though. Con - 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: LSM hook addition?
* John Richard Moser ([EMAIL PROTECTED]) wrote:
> Can someone point me to documentation or give me a small patch to add an
> LSM hook to kernel 2.6.10 in fs/namei.c at line 1986:
>
> new_dentry = lookup_create(, 0);
> error = PTR_ERR(new_dentry);
> if (!IS_ERR(new_dentry)) {
> error = security_inode_make_hardlink(old_nd); // ADD
> error = vfs_link(old_nd.dentry, nd.dentry->d_inode,
> new_dentry);
It's already there. Look at the code in vfs_link. The security_inode_link
hook is documented in include/linux/security.h. And the restrictive policy
you're referring to is already codified in the owlsm module. See the
do_owlsm_link() function here (code's a bit old, but basic idea is still
relevant):
http://lsm.bkbits.net:8080/lsm-2.6/anno/security/[EMAIL
PROTECTED]|src/|src/security
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
Jack O'Quin <[EMAIL PROTECTED]> writes: > Will post the correct numbers shortly. Sorry for the screw-up. Here they are... http://www.joq.us/jack/benchmarks/sched-isoprio http://www.joq.us/jack/benchmarks/sched-isoprio+compile I moved the previous runs to the sched-fifo* directories where they belong. For convenience, I moved all the summary data logs here... http://www.joq.us/jack/benchmarks/.SUMMARY Unfortunately, these corrected tests do not compare favorably with the earlier sched-fifo runs (mistaken or otherwise). I wanted to believe the problem was just a matter of priorities, but evidently it is not. In fact, for this test the priority scheduler does not really help at all (though I believe it will for other things). The max delay numbers are still all over the place... ...benchmarks/sched-iso... Delay Maximum . . . . . . . . : 21410 usecs Delay Maximum . . . . . . . . : 36830 usecs Delay Maximum . . . . . . . . : 4062 usecs ...benchmarks/sched-iso+compile... Delay Maximum . . . . . . . . : 98909 usecs Delay Maximum . . . . . . . . : 39414 usecs Delay Maximum . . . . . . . . : 40294 usecs Delay Maximum . . . . . . . . : 217192 usecs Delay Maximum . . . . . . . . : 156989 usecs ...benchmarks/sched-isoprio... Delay Maximum . . . . . . . . : 37071 usecs Delay Maximum . . . . . . . . : 98193 usecs Delay Maximum . . . . . . . . : 36935 usecs ...benchmarks/sched-isoprio+compile... Delay Maximum . . . . . . . . : 59662 usecs Delay Maximum . . . . . . . . : 151624 usecs Delay Maximum . . . . . . . . : 39250 usecs I'll try building a SCHED_RR version of JACK. I still don't think it will make any difference. But my intuition isn't working very well right now, so I need more data. I still wonder if some coding error might occasionally be letting a lower priority process continue running after an interrupt when it ought to be preempted. -- joq - 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][7/12] InfiniBand/mthca: optimize event queue handling
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Event queue handling performance improvements:
- Only calculate EQ entry address once, and don't truncate the
consumer index until we really need to.
- Only read ECR once. If a new event occurs while we're in the
interrupt handler, we'll get another interrupt anyway, since we
only clear events once.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_provider.h 2005-01-23
08:30:27.0 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_provider.h 2005-01-23
20:51:23.739805744 -0800
@@ -66,11 +66,11 @@
struct mthca_dev *dev;
inteqn;
u32ecr_mask;
+ u32cons_index;
u16msi_x_vector;
u16msi_x_entry;
inthave_irq;
intnent;
- intcons_index;
struct mthca_buf_list *page_list;
struct mthca_mrmr;
};
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_eq.c2005-01-23
20:47:40.946675448 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_eq.c 2005-01-23
20:51:23.740805592 -0800
@@ -164,12 +164,12 @@
MTHCA_ASYNC_EVENT_MASK;
}
-static inline void set_eq_ci(struct mthca_dev *dev, int eqn, int ci)
+static inline void set_eq_ci(struct mthca_dev *dev, struct mthca_eq *eq, u32
ci)
{
u32 doorbell[2];
- doorbell[0] = cpu_to_be32(MTHCA_EQ_DB_SET_CI | eqn);
- doorbell[1] = cpu_to_be32(ci);
+ doorbell[0] = cpu_to_be32(MTHCA_EQ_DB_SET_CI | eq->eqn);
+ doorbell[1] = cpu_to_be32(ci & (eq->nent - 1));
mthca_write64(doorbell,
dev->kar + MTHCA_EQ_DOORBELL,
@@ -200,21 +200,22 @@
MTHCA_GET_DOORBELL_LOCK(>doorbell_lock));
}
-static inline struct mthca_eqe *get_eqe(struct mthca_eq *eq, int entry)
+static inline struct mthca_eqe *get_eqe(struct mthca_eq *eq, u32 entry)
{
- return eq->page_list[entry * MTHCA_EQ_ENTRY_SIZE / PAGE_SIZE].buf
- + (entry * MTHCA_EQ_ENTRY_SIZE) % PAGE_SIZE;
+ unsigned long off = (entry & (eq->nent - 1)) * MTHCA_EQ_ENTRY_SIZE;
+ return eq->page_list[off / PAGE_SIZE].buf + off % PAGE_SIZE;
}
-static inline int next_eqe_sw(struct mthca_eq *eq)
+static inline struct mthca_eqe* next_eqe_sw(struct mthca_eq *eq)
{
- return !(MTHCA_EQ_ENTRY_OWNER_HW &
-get_eqe(eq, eq->cons_index)->owner);
+ struct mthca_eqe* eqe;
+ eqe = get_eqe(eq, eq->cons_index);
+ return (MTHCA_EQ_ENTRY_OWNER_HW & eqe->owner) ? NULL : eqe;
}
-static inline void set_eqe_hw(struct mthca_eq *eq, int entry)
+static inline void set_eqe_hw(struct mthca_eqe *eqe)
{
- get_eqe(eq, entry)->owner = MTHCA_EQ_ENTRY_OWNER_HW;
+ eqe->owner = MTHCA_EQ_ENTRY_OWNER_HW;
}
static void port_change(struct mthca_dev *dev, int port, int active)
@@ -235,10 +236,10 @@
{
struct mthca_eqe *eqe;
int disarm_cqn;
+ int eqes_found = 0;
- while (next_eqe_sw(eq)) {
+ while ((eqe = next_eqe_sw(eq))) {
int set_ci = 0;
- eqe = get_eqe(eq, eq->cons_index);
/*
* Make sure we read EQ entry contents after we've
@@ -328,12 +329,13 @@
break;
};
- set_eqe_hw(eq, eq->cons_index);
- eq->cons_index = (eq->cons_index + 1) & (eq->nent - 1);
+ set_eqe_hw(eqe);
+ ++eq->cons_index;
+ eqes_found = 1;
if (set_ci) {
wmb(); /* see comment below */
- set_eq_ci(dev, eq->eqn, eq->cons_index);
+ set_eq_ci(dev, eq, eq->cons_index);
set_ci = 0;
}
}
@@ -347,8 +349,10 @@
* possibility of the HCA writing an entry and then
* having set_eqe_hw() overwrite the owner field.
*/
- wmb();
- set_eq_ci(dev, eq->eqn, eq->cons_index);
+ if (likely(eqes_found)) {
+ wmb();
+ set_eq_ci(dev, eq, eq->cons_index);
+ }
eq_req_not(dev, eq->eqn);
}
@@ -362,7 +366,7 @@
if (dev->eq_table.clr_mask)
writel(dev->eq_table.clr_mask, dev->eq_table.clr_int);
- while ((ecr = readl(dev->hcr + MTHCA_ECR_OFFSET + 4)) != 0) {
+ if ((ecr = readl(dev->hcr + MTHCA_ECR_OFFSET + 4)) != 0) {
work = 1;
writel(ecr, dev->hcr + MTHCA_ECR_CLR_OFFSET + 4);
@@ -440,7 +444,7 @@
}
for (i = 0; i < nent; ++i)
- set_eqe_hw(eq, i);
+ set_eqe_hw(get_eqe(eq, i));
eq->eqn = mthca_alloc(>eq_table.alloc);
if (eq->eqn == -1)
-
To unsubscribe from this list:
[PATCH][12/12] InfiniBand/mthca: remove x86 SSE pessimization
Get rid of the x86 SSE code for atomic 64-bit writes to doorbell
registers. Saving/setting CR0 plus a clts instruction are too
expensive for it to ever be a win, and the config option was just
confusing.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/hw/mthca/Kconfig 2005-01-23
08:30:27.0 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/Kconfig2005-01-23
21:00:44.744520064 -0800
@@ -14,13 +14,3 @@
This option causes the mthca driver produce a bunch of debug
messages. Select this is you are developing the driver or
trying to diagnose a problem.
-
-config INFINIBAND_MTHCA_SSE_DOORBELL
- bool "SSE doorbell code"
- depends on INFINIBAND_MTHCA && X86 && !X86_64
- default n
- ---help---
- This option will have the mthca driver use SSE instructions
- to ring hardware doorbell registers. This may improve
- performance for some workloads, but the driver will not run
- on processors without SSE instructions.
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_main.c 2005-01-23
20:58:55.771086544 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_main.c 2005-01-23
21:00:44.745519912 -0800
@@ -40,10 +40,6 @@
#include
#include
-#ifdef CONFIG_INFINIBAND_MTHCA_SSE_DOORBELL
-#include
-#endif
-
#include "mthca_dev.h"
#include "mthca_config_reg.h"
#include "mthca_cmd.h"
@@ -1117,22 +1113,6 @@
{
int ret;
- /*
-* TODO: measure whether dynamically choosing doorbell code at
-* runtime affects our performance. Is there a "magic" way to
-* choose without having to follow a function pointer every
-* time we ring a doorbell?
-*/
-#ifdef CONFIG_INFINIBAND_MTHCA_SSE_DOORBELL
- if (!cpu_has_xmm) {
- printk(KERN_ERR PFX "mthca was compiled with SSE doorbell code,
but\n");
- printk(KERN_ERR PFX "the current CPU does not support SSE.\n");
- printk(KERN_ERR PFX "Turn off
CONFIG_INFINIBAND_MTHCA_SSE_DOORBELL "
- "and recompile.\n");
- return -ENODEV;
- }
-#endif
-
ret = pci_register_driver(_driver);
return ret < 0 ? ret : 0;
}
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_doorbell.h 2005-01-23
08:30:38.0 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_doorbell.h 2005-01-23
21:00:44.746519760 -0800
@@ -32,9 +32,7 @@
* $Id: mthca_doorbell.h 1349 2004-12-16 21:09:43Z roland $
*/
-#include
#include
-#include
#define MTHCA_RD_DOORBELL 0x00
#define MTHCA_SEND_DOORBELL0x10
@@ -59,51 +57,13 @@
__raw_writeq(*(u64 *) val, dest);
}
-#elif defined(CONFIG_INFINIBAND_MTHCA_SSE_DOORBELL)
-/* Use SSE to write 64 bits atomically without a lock. */
-
-#define MTHCA_DECLARE_DOORBELL_LOCK(name)
-#define MTHCA_INIT_DOORBELL_LOCK(ptr)do { } while (0)
-#define MTHCA_GET_DOORBELL_LOCK(ptr) (NULL)
-
-static inline unsigned long mthca_get_fpu(void)
-{
- unsigned long cr0;
-
- preempt_disable();
- asm volatile("mov %%cr0,%0; clts" : "=r" (cr0));
- return cr0;
-}
-
-static inline void mthca_put_fpu(unsigned long cr0)
-{
- asm volatile("mov %0,%%cr0" : : "r" (cr0));
- preempt_enable();
-}
-
-static inline void mthca_write64(u32 val[2], void __iomem *dest,
-spinlock_t *doorbell_lock)
-{
- /* i386 stack is aligned to 8 bytes, so this should be OK: */
- u8 xmmsave[8] __attribute__((aligned(8)));
- unsigned long cr0;
-
- cr0 = mthca_get_fpu();
-
- asm volatile (
- "movlps %%xmm0,(%0); \n\t"
- "movlps (%1),%%xmm0; \n\t"
- "movlps %%xmm0,(%2); \n\t"
- "movlps (%0),%%xmm0; \n\t"
- :
- : "r" (xmmsave), "r" (val), "r" (dest)
- : "memory" );
-
- mthca_put_fpu(cr0);
-}
-
#else
-/* Just fall back to a spinlock to protect the doorbell */
+
+/*
+ * Just fall back to a spinlock to protect the doorbell if
+ * BITS_PER_LONG is 32 -- there's no portable way to do atomic 64-bit
+ * MMIO writes.
+ */
#define MTHCA_DECLARE_DOORBELL_LOCK(name) spinlock_t name;
#define MTHCA_INIT_DOORBELL_LOCK(ptr) spin_lock_init(ptr)
-
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][10/12] InfiniBand/core: add IsSM userspace support
Implement setting/clearing IsSM port capability bit from userspace via
"issm" special files (set IsSM bit on open, clear on close).
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/core/user_mad.c2005-01-23
20:57:19.946654072 -0800
+++ linux-bk/drivers/infiniband/core/user_mad.c 2005-01-23 20:57:56.183145288
-0800
@@ -45,6 +45,7 @@
#include
#include
+#include
#include
#include
@@ -54,7 +55,7 @@
MODULE_LICENSE("Dual BSD/GPL");
enum {
- IB_UMAD_MAX_PORTS = 256,
+ IB_UMAD_MAX_PORTS = 64,
IB_UMAD_MAX_AGENTS = 32
};
@@ -62,6 +63,12 @@
intdevnum;
struct cdevdev;
struct class_deviceclass_dev;
+
+ intsm_devnum;
+ struct cdevsm_dev;
+ struct class_devicesm_class_dev;
+ struct semaphore sm_sem;
+
struct ib_device *ib_dev;
struct ib_umad_device *umad_dev;
u8 port_num;
@@ -92,7 +99,7 @@
static dev_t base_dev;
static spinlock_t map_lock;
-static DECLARE_BITMAP(dev_map, IB_UMAD_MAX_PORTS);
+static DECLARE_BITMAP(dev_map, IB_UMAD_MAX_PORTS * 2);
static void ib_umad_add_one(struct ib_device *device);
static void ib_umad_remove_one(struct ib_device *device);
@@ -511,6 +518,54 @@
.release= ib_umad_close
};
+static int ib_umad_sm_open(struct inode *inode, struct file *filp)
+{
+ struct ib_umad_port *port =
+ container_of(inode->i_cdev, struct ib_umad_port, sm_dev);
+ struct ib_port_modify props = {
+ .set_port_cap_mask = IB_PORT_SM
+ };
+ int ret;
+
+ if (filp->f_flags & O_NONBLOCK) {
+ if (down_trylock(>sm_sem))
+ return -EAGAIN;
+ } else {
+ if (down_interruptible(>sm_sem))
+ return -ERESTARTSYS;
+ }
+
+ ret = ib_modify_port(port->ib_dev, port->port_num, 0, );
+ if (ret) {
+ up(>sm_sem);
+ return ret;
+ }
+
+ filp->private_data = port;
+
+ return 0;
+}
+
+static int ib_umad_sm_close(struct inode *inode, struct file *filp)
+{
+ struct ib_umad_port *port = filp->private_data;
+ struct ib_port_modify props = {
+ .clr_port_cap_mask = IB_PORT_SM
+ };
+ int ret;
+
+ ret = ib_modify_port(port->ib_dev, port->port_num, 0, );
+ up(>sm_sem);
+
+ return ret;
+}
+
+static struct file_operations umad_sm_fops = {
+ .owner = THIS_MODULE,
+ .open= ib_umad_sm_open,
+ .release = ib_umad_sm_close
+};
+
static struct ib_client umad_client = {
.name = "umad",
.add= ib_umad_add_one,
@@ -519,17 +574,18 @@
static ssize_t show_dev(struct class_device *class_dev, char *buf)
{
- struct ib_umad_port *port =
- container_of(class_dev, struct ib_umad_port, class_dev);
+ struct ib_umad_port *port = class_get_devdata(class_dev);
- return print_dev_t(buf, port->dev.dev);
+ if (class_dev == >class_dev)
+ return print_dev_t(buf, port->dev.dev);
+ else
+ return print_dev_t(buf, port->sm_dev.dev);
}
static CLASS_DEVICE_ATTR(dev, S_IRUGO, show_dev, NULL);
static ssize_t show_ibdev(struct class_device *class_dev, char *buf)
{
- struct ib_umad_port *port =
- container_of(class_dev, struct ib_umad_port, class_dev);
+ struct ib_umad_port *port = class_get_devdata(class_dev);
return sprintf(buf, "%s\n", port->ib_dev->name);
}
@@ -537,8 +593,7 @@
static ssize_t show_port(struct class_device *class_dev, char *buf)
{
- struct ib_umad_port *port =
- container_of(class_dev, struct ib_umad_port, class_dev);
+ struct ib_umad_port *port = class_get_devdata(class_dev);
return sprintf(buf, "%d\n", port->port_num);
}
@@ -554,11 +609,16 @@
static void ib_umad_release_port(struct class_device *class_dev)
{
- struct ib_umad_port *port =
- container_of(class_dev, struct ib_umad_port, class_dev);
+ struct ib_umad_port *port = class_get_devdata(class_dev);
+
+ if (class_dev == >class_dev) {
+ cdev_del(>dev);
+ clear_bit(port->devnum, dev_map);
+ } else {
+ cdev_del(>sm_dev);
+ clear_bit(port->sm_devnum, dev_map);
+ }
- cdev_del(>dev);
- clear_bit(port->devnum, dev_map);
kref_put(>umad_dev->ref, ib_umad_release_dev);
}
@@ -573,6 +633,94 @@
}
static CLASS_ATTR(abi_version, S_IRUGO, show_abi_version, NULL);
+static int ib_umad_init_port(struct ib_device *device, int port_num,
+struct ib_umad_port *port)
+{
+ spin_lock(_lock);
+ port->devnum = find_first_zero_bit(dev_map, IB_UMAD_MAX_PORTS);
+ if (port->devnum >= IB_UMAD_MAX_PORTS) {
+ spin_unlock(_lock);
+
[PATCH][11/12] InfiniBand/mthca: clean up ioremap()/request_region() usage
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Here are misc fixes for mthca mapping:
1. Thinkably, MSI tables or another region could fall between HCR
and ECR tables.
Thus its arguably wrong to map both tables in one region.
So, do it separately.
I think its also more readable to have ecr_base and access ecr there,
not access ecr with hcr pointer.
2. mthca_request_regions error handling was borken
(wrong order of cleanups). For example on all errors
pci_release_region was called which is wrong if the region
was not yet mapped. And other such cleanups.
3. Fixed some error messages too.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_eq.c2005-01-23
20:51:23.740805592 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_eq.c 2005-01-23
20:58:55.772086392 -0800
@@ -366,10 +366,11 @@
if (dev->eq_table.clr_mask)
writel(dev->eq_table.clr_mask, dev->eq_table.clr_int);
- if ((ecr = readl(dev->hcr + MTHCA_ECR_OFFSET + 4)) != 0) {
+ if ((ecr = readl(dev->ecr_base + 4)) != 0) {
work = 1;
- writel(ecr, dev->hcr + MTHCA_ECR_CLR_OFFSET + 4);
+ writel(ecr, dev->ecr_base +
+ MTHCA_ECR_CLR_BASE - MTHCA_ECR_BASE + 4);
for (i = 0; i < MTHCA_NUM_EQ; ++i)
if (ecr & dev->eq_table.eq[i].ecr_mask)
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_main.c 2005-01-23
20:52:01.962994936 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_main.c 2005-01-23
20:58:55.771086544 -0800
@@ -699,57 +699,83 @@
*/
if (!request_mem_region(pci_resource_start(pdev, 0) +
MTHCA_HCR_BASE,
- MTHCA_MAP_HCR_SIZE,
- DRV_NAME))
- return -EBUSY;
+ MTHCA_HCR_SIZE,
+ DRV_NAME)) {
+ err = -EBUSY;
+ goto err_hcr_failed;
+ }
+
+ if (!request_mem_region(pci_resource_start(pdev, 0) +
+ MTHCA_ECR_BASE,
+ MTHCA_MAP_ECR_SIZE,
+ DRV_NAME)) {
+ err = -EBUSY;
+ goto err_ecr_failed;
+ }
if (!request_mem_region(pci_resource_start(pdev, 0) +
MTHCA_CLR_INT_BASE,
MTHCA_CLR_INT_SIZE,
DRV_NAME)) {
err = -EBUSY;
- goto err_bar0_beg;
+ goto err_int_failed;
}
+
err = pci_request_region(pdev, 2, DRV_NAME);
if (err)
- goto err_bar0_end;
+ goto err_bar2_failed;
if (!ddr_hidden) {
err = pci_request_region(pdev, 4, DRV_NAME);
if (err)
- goto err_bar2;
+ goto err_bar4_failed;
}
return 0;
-err_bar0_beg:
- release_mem_region(pci_resource_start(pdev, 0) +
- MTHCA_HCR_BASE,
- MTHCA_MAP_HCR_SIZE);
+err_bar4_failed:
+
+ pci_release_region(pdev, 2);
+err_bar2_failed:
-err_bar0_end:
release_mem_region(pci_resource_start(pdev, 0) +
MTHCA_CLR_INT_BASE,
MTHCA_CLR_INT_SIZE);
+err_int_failed:
+
+ release_mem_region(pci_resource_start(pdev, 0) +
+ MTHCA_ECR_BASE,
+ MTHCA_MAP_ECR_SIZE);
+err_ecr_failed:
+
+ release_mem_region(pci_resource_start(pdev, 0) +
+ MTHCA_HCR_BASE,
+ MTHCA_HCR_SIZE);
+err_hcr_failed:
-err_bar2:
- pci_release_region(pdev, 2);
return err;
}
static void mthca_release_regions(struct pci_dev *pdev,
int ddr_hidden)
{
- release_mem_region(pci_resource_start(pdev, 0) +
- MTHCA_HCR_BASE,
- MTHCA_MAP_HCR_SIZE);
+ if (!ddr_hidden)
+ pci_release_region(pdev, 4);
+
+ pci_release_region(pdev, 2);
+
release_mem_region(pci_resource_start(pdev, 0) +
MTHCA_CLR_INT_BASE,
MTHCA_CLR_INT_SIZE);
- pci_release_region(pdev, 2);
- if (!ddr_hidden)
- pci_release_region(pdev, 4);
+
+ release_mem_region(pci_resource_start(pdev, 0) +
+ MTHCA_ECR_BASE,
+ MTHCA_MAP_ECR_SIZE);
+
+ release_mem_region(pci_resource_start(pdev, 0) +
+ MTHCA_HCR_BASE,
+ MTHCA_HCR_SIZE);
}
static int __devinit mthca_enable_msi_x(struct mthca_dev *mdev)
@@ -911,29 +937,39 @@
mdev->cmd.use_events = 0;
mthca_base = pci_resource_start(pdev, 0);
-
[PATCH][5/12] InfiniBand/mthca: don't write ECR in MSI-X mode
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]> We don't need to write to the ECR to clear events when using MSI-X, since we never read the ECR anyway. Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> --- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_eq.c2005-01-23 20:38:50.946247760 -0800 +++ linux-bk/drivers/infiniband/hw/mthca/mthca_eq.c 2005-01-23 20:47:40.946675448 -0800 @@ -381,7 +381,6 @@ struct mthca_eq *eq = eq_ptr; struct mthca_dev *dev = eq->dev; - writel(eq->ecr_mask, dev->hcr + MTHCA_ECR_CLR_OFFSET + 4); mthca_eq_int(dev, eq); /* MSI-X vectors always belong to us */ - 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][9/12] InfiniBand/ipoib: remove uses of yield()
Replace uses of yield() with msleep(1) as suggested by kernel janitors. Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> --- linux-bk.orig/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2005-01-23 08:31:58.0 -0800 +++ linux-bk/drivers/infiniband/ulp/ipoib/ipoib_ib.c2005-01-23 20:52:46.294255560 -0800 @@ -509,7 +509,7 @@ goto timeout; } - yield(); + msleep(1); } ipoib_dbg(priv, "All sends and receives done.\n"); @@ -535,7 +535,7 @@ break; } - yield(); + msleep(1); } return 0; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][4/12] InfiniBand/core: fix port capability enums bit order
Correct defines of port capability mask enum values (bits were ordered
backwards) and add new capability bits from IBA spec version 1.2.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/include/ib_verbs.h 2005-01-23
08:30:22.0 -0800
+++ linux-bk/drivers/infiniband/include/ib_verbs.h 2005-01-23
20:46:23.606432952 -0800
@@ -154,25 +154,28 @@
};
enum ib_port_cap_flags {
- IB_PORT_SM = (1<<31),
- IB_PORT_NOTICE_SUP = (1<<30),
- IB_PORT_TRAP_SUP= (1<<29),
- IB_PORT_AUTO_MIGR_SUP = (1<<27),
- IB_PORT_SL_MAP_SUP = (1<<26),
- IB_PORT_MKEY_NVRAM = (1<<25),
- IB_PORT_PKEY_NVRAM = (1<<24),
- IB_PORT_LED_INFO_SUP= (1<<23),
- IB_PORT_SM_DISABLED = (1<<22),
- IB_PORT_SYS_IMAGE_GUID_SUP = (1<<21),
- IB_PORT_PKEY_SW_EXT_PORT_TRAP_SUP = (1<<20),
- IB_PORT_CM_SUP = (1<<16),
- IB_PORT_SNMP_TUNNEL_SUP = (1<<15),
- IB_PORT_REINIT_SUP = (1<<14),
- IB_PORT_DEVICE_MGMT_SUP = (1<<13),
- IB_PORT_VENDOR_CLASS_SUP= (1<<12),
- IB_PORT_DR_NOTICE_SUP = (1<<11),
- IB_PORT_PORT_NOTICE_SUP = (1<<10),
- IB_PORT_BOOT_MGMT_SUP = (1<<9)
+ IB_PORT_SM = 1 << 1,
+ IB_PORT_NOTICE_SUP = 1 << 2,
+ IB_PORT_TRAP_SUP= 1 << 3,
+ IB_PORT_OPT_IPD_SUP = 1 << 4,
+ IB_PORT_AUTO_MIGR_SUP = 1 << 5,
+ IB_PORT_SL_MAP_SUP = 1 << 6,
+ IB_PORT_MKEY_NVRAM = 1 << 7,
+ IB_PORT_PKEY_NVRAM = 1 << 8,
+ IB_PORT_LED_INFO_SUP= 1 << 9,
+ IB_PORT_SM_DISABLED = 1 << 10,
+ IB_PORT_SYS_IMAGE_GUID_SUP = 1 << 11,
+ IB_PORT_PKEY_SW_EXT_PORT_TRAP_SUP = 1 << 12,
+ IB_PORT_CM_SUP = 1 << 16,
+ IB_PORT_SNMP_TUNNEL_SUP = 1 << 17,
+ IB_PORT_REINIT_SUP = 1 << 18,
+ IB_PORT_DEVICE_MGMT_SUP = 1 << 19,
+ IB_PORT_VENDOR_CLASS_SUP= 1 << 20,
+ IB_PORT_DR_NOTICE_SUP = 1 << 21,
+ IB_PORT_CAP_MASK_NOTICE_SUP = 1 << 22,
+ IB_PORT_BOOT_MGMT_SUP = 1 << 23,
+ IB_PORT_LINK_LATENCY_SUP= 1 << 24,
+ IB_PORT_CLIENT_REG_SUP = 1 << 25
};
enum ib_port_width {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][2/12] InfiniBand/mthca: more Arbel Mem-Free support
Continue development of Arbel Mem-Free support: we now compute a valid
profile, allocate context memory, map sufficient aux memory for HCA
page tables, map sufficient context memory to cover all reserved
firmware resources and successfully call the INIT_HCA and
QUERY_ADAPTER firmware commands. Fix a few error gotos that unwound
the wrong things.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_cmd.h 2005-01-23
08:30:23.0 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_cmd.h2005-01-23
20:26:07.036379712 -0800
@@ -174,27 +174,30 @@
struct mthca_init_hca_param {
u64 qpc_base;
- u8 log_num_qps;
u64 eec_base;
- u8 log_num_eecs;
u64 srqc_base;
- u8 log_num_srqs;
u64 cqc_base;
- u8 log_num_cqs;
u64 eqpc_base;
u64 eeec_base;
u64 eqc_base;
- u8 log_num_eqs;
u64 rdb_base;
u64 mc_base;
+ u64 mpt_base;
+ u64 mtt_base;
+ u64 uar_scratch_base;
+ u64 uarc_base;
u16 log_mc_entry_sz;
u16 mc_hash_sz;
+ u8 log_num_qps;
+ u8 log_num_eecs;
+ u8 log_num_srqs;
+ u8 log_num_cqs;
+ u8 log_num_eqs;
u8 log_mc_table_sz;
- u64 mpt_base;
u8 mtt_seg_sz;
u8 log_mpt_sz;
- u64 mtt_base;
- u64 uar_scratch_base;
+ u8 log_uar_sz;
+ u8 log_uarc_sz;
};
struct mthca_init_ib_param {
@@ -238,6 +241,13 @@
int port, u8 *status);
int mthca_CLOSE_IB(struct mthca_dev *dev, int port, u8 *status);
int mthca_CLOSE_HCA(struct mthca_dev *dev, int panic, u8 *status);
+int mthca_MAP_ICM(struct mthca_dev *dev, struct mthca_icm *icm, u64 virt, u8
*status);
+int mthca_MAP_ICM_page(struct mthca_dev *dev, u64 dma_addr, u64 virt, u8
*status);
+int mthca_UNMAP_ICM(struct mthca_dev *dev, u64 virt, u32 page_count, u8
*status);
+int mthca_MAP_ICM_AUX(struct mthca_dev *dev, struct mthca_icm *icm, u8
*status);
+int mthca_UNMAP_ICM_AUX(struct mthca_dev *dev, u8 *status);
+int mthca_SET_ICM_SIZE(struct mthca_dev *dev, u64 icm_size, u64 *aux_pages,
+ u8 *status);
int mthca_SW2HW_MPT(struct mthca_dev *dev, void *mpt_entry,
int mpt_index, u8 *status);
int mthca_HW2SW_MPT(struct mthca_dev *dev, void *mpt_entry,
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_profile.c 2005-01-23
08:32:07.0 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_profile.c2005-01-23
20:26:07.033380168 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2004 Topspin Communications. All rights reserved.
+ * Copyright (c) 2004, 2005 Topspin Communications. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -60,7 +60,7 @@
MTHCA_NUM_PDS = 1 << 15
};
-int mthca_make_profile(struct mthca_dev *dev,
+u64 mthca_make_profile(struct mthca_dev *dev,
struct mthca_profile *request,
struct mthca_dev_lim *dev_lim,
struct mthca_init_hca_param *init_hca)
@@ -116,6 +116,8 @@
profile[i].type = i;
profile[i].log_num = max(ffs(profile[i].num) - 1, 0);
profile[i].size*= profile[i].num;
+ if (dev->hca_type == ARBEL_NATIVE)
+ profile[i].size = max(profile[i].size, (u64) PAGE_SIZE);
}
if (dev->hca_type == ARBEL_NATIVE) {
@@ -239,6 +241,10 @@
case MTHCA_RES_UDAV:
dev->av_table.ddr_av_base = profile[i].start;
dev->av_table.num_ddr_avs = profile[i].num;
+ case MTHCA_RES_UARC:
+ init_hca->uarc_base = profile[i].start;
+ init_hca->log_uarc_sz = ffs(request->uarc_size) - 13;
+ init_hca->log_uar_sz = ffs(request->num_uar) - 1;
default:
break;
}
@@ -251,5 +257,5 @@
dev->limits.num_pds = MTHCA_NUM_PDS;
kfree(profile);
- return 0;
+ return total_size;
}
--- linux-bk.orig/drivers/infiniband/hw/mthca/mthca_memfree.c 2005-01-23
08:30:22.0 -0800
+++ linux-bk/drivers/infiniband/hw/mthca/mthca_memfree.c2005-01-23
20:26:07.037379560 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2004 Topspin Communications. All rights reserved.
+ * Copyright (c) 2004, 2005 Topspin Communications. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -34,6 +34,16 @@
#include "mthca_memfree.h"
#include "mthca_dev.h"
+#include "mthca_cmd.h"
+
+/*
+ * We allocate in as big chunks as we can, up to a maximum of 256 KB
+ * per chunk.
+ */
+enum {
+ MTHCA_ICM_ALLOC_SIZE = 1 << 18,
+
[PATCH][1/12] InfiniBand/core: compat_ioctl conversion minor fixes
Slightly tidy up Andi Kleen's compat_ioctl conversion for the
InfiniBand MAD driver by removing the no-longer-needed include of
ioctl32.h, killing unreachable code and doing some really anal
whitespace fixing.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-bk.orig/drivers/infiniband/core/user_mad.c2005-01-23
21:48:45.709546808 -0800
+++ linux-bk/drivers/infiniband/core/user_mad.c 2005-01-23 21:49:32.872376968
-0800
@@ -43,7 +43,6 @@
#include
#include
#include
-#include
#include
@@ -502,14 +501,14 @@
}
static struct file_operations umad_fops = {
- .owner = THIS_MODULE,
- .read= ib_umad_read,
- .write = ib_umad_write,
- .poll= ib_umad_poll,
+ .owner = THIS_MODULE,
+ .read = ib_umad_read,
+ .write = ib_umad_write,
+ .poll = ib_umad_poll,
.unlocked_ioctl = ib_umad_ioctl,
- .compat_ioctl = ib_umad_ioctl,
- .open= ib_umad_open,
- .release = ib_umad_close
+ .compat_ioctl = ib_umad_ioctl,
+ .open = ib_umad_open,
+ .release= ib_umad_close
};
static struct ib_client umad_client = {
@@ -705,8 +704,6 @@
return 0;
- ib_unregister_client(_client);
-
out_class:
class_unregister(_class);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][0/12] InfiniBand: updates for 2.6.11-rc2
Here are updates since the last merge of drivers/infiniband taken from the OpenIB repository. A couple small fixes, the addition of "issm" device support to allow userspace to set the IsSM port capability bit, and a bunch of mthca driver improvements. There shouldn't be anything risky (and it's all confined to drivers/infiniband). 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: [2.6.11-rc2] Badness in local_bh_enable at kernel/softirq.c:140
On Mon, Jan 24, 2005 at 01:39:26AM +0100, Ram?n Rey Vicente wrote: > Badness in local_bh_enable at kernel/softirq.c:140 The cause of this was reverted earlier today. --cw - 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/
LSM hook addition?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Can someone point me to documentation or give me a small patch to add an
LSM hook to kernel 2.6.10 in fs/namei.c at line 1986:
new_dentry = lookup_create(, 0);
error = PTR_ERR(new_dentry);
if (!IS_ERR(new_dentry)) {
error = security_inode_make_hardlink(old_nd); // ADD
error = vfs_link(old_nd.dentry, nd.dentry->d_inode,
new_dentry);
I believe this would be sufficient to finish an LSM module to implement
linking restrictions from GrSecurity. I did Symlinks in an LSM module,
but haven't tested it out; it's purely academic. I guess adding an LSM
hook would be an interesting academic experience; I'd enjoy examining a
patch that adds this hook, and then trying to add another hook myself.
The hook here would be used (in my academic exploration) to prevent hard
links from being created to files you don't own, unless you're root.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB9I5vhDd4aOud5P8RAmNNAJ44riGGJ6CP1sCC/CHfIJiD0u6augCeNFEI
PjjmHxipSD2wRyv4z+JElig=
=VDIo
-END PGP SIGNATURE-
-
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/
P35U
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does anyone have a p35u based camera? I have an EZCam Pro p35u based, still no driver I believe. Anything I can do to help with making one, like dump some sort of hardware data off it (yeah right)? - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9ILWhDd4aOud5P8RAkiXAJ9uAB/NHy9qQ6e+RRyM1i3jRSgZiwCffT1g K0rchySBqXcbfC0yBeg0iAQ= =VBqw -END PGP SIGNATURE- - 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: irq 3: nobody cared! with Intel 31244 SATA.... Advice??
Hi Atul, If I enable APIC on the 2.6.10 kernel I get exactly the same behavior as I got without APIC If I enable APIC-IO, then it starts barking about Interrupt 22 and never finishes... SO... At the minimum, both of these settings do not help and one makes the problem worse in that the sata-vsc module never finishes loading Thanks for your response though... At this point I am ready to climb a tree and bark at the moon if it will help ;) Dave On Mon, 24 Jan 2005, Atul Bhouraskar wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:linux-kernel- > > [EMAIL PROTECTED] On Behalf Of David Sims > > Sent: Monday, 24 January 2005 13:57 > > > > I then downloaded and built kernel 2.6.10 which boots up fine without > the > > sata_vsc module If you then load the sata_vsc module manually > using > > "modprobe sata_vsc" it will cause the following error once for each > > attached disk drive: > > > > Jan 23 09:08:21 linux kernel: Disabling IRQ #3 > > Jan 23 09:08:23 linux kernel: irq 3: nobody cared! > > I once had the same problem, I think enabling APIC solved it > > Atul > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/13] Qsort
"Rafael J. Wysocki" <[EMAIL PROTECTED]> said: [...] > To be precise, one needs ~(log N) of stack space for qsort, and frankly, one > should use something like the shell (or should I say Shell?) Shell. It is named for a person. > sort for sorting > small sets of elements in qsort as well. It makes no sense for smallish sets, insertion sort is better. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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]sched: Isochronous class v2 for unprivileged soft rt scheduling
Jack O'Quin <[EMAIL PROTECTED]> writes: > These results are indistinguishable from SCHED_FIFO... Disregard my previous message, it was an idiotic mistake. The results were indistinguishable form SCHED_FIFO because they *were* SCHED_FIFO. I'm running everything again, this time with the correct scheduling parameters. Will post the correct numbers shortly. Sorry for the screw-up. -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/13] Qsort
Matt Mackall <[EMAIL PROTECTED]> said: > On Sun, Jan 23, 2005 at 03:39:34AM +0100, Andi Kleen wrote: [...] > > -Andi (who thinks the glibc qsort is vast overkill for kernel purposes > > where there are only small data sets and it would be better to use a > > simpler one optimized for code size) > Mostly agreed. Except: > > a) the glibc version is not actually all that optimized > b) it's nice that it's not recursive > c) the three-way median selection does help avoid worst-case O(n^2) > behavior, which might potentially be triggerable by users in places > like XFS where this is used Shellsort is much simpler, and not much slower for small datasets. Plus no extra space for stacks. > I'll probably whip up a simpler version tomorrow or Monday and do some > size/space benchmarking. I've been meaning to contribute a qsort for > doubly-linked lists I've got lying around as well. Qsort is OK as long as you have direct access to each element. In case of lists, it is better to just use mergesort. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/13] Qsort
Andreas Gruenbacher <[EMAIL PROTECTED]> said: > Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]> > Acked-by: Olaf Kirch <[EMAIL PROTECTED]> [...] > +/* Order size using quicksort. This implementation incorporates > + four optimizations discussed in Sedgewick: > + > + 1. Non-recursive, using an explicit stack of pointer that store the > + next array partition to sort. To save time, this maximum amount > + of space required to store an array of SIZE_MAX is allocated on the > + stack. Assuming a 32-bit (64 bit) integer for size_t, this needs > + only 32 * sizeof(stack_node) == 256 bytes (for 64 bit: 1024 bytes). > + Pretty cheap, actually. Not really, given the strict size restrictions in-kernel. Has there been any comparison between the original and this one? Code size, stack use, speed, ...? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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]sched: Isochronous class v2 for unprivileged soft rt scheduling
Con Kolivas <[EMAIL PROTECTED]> writes: >>>Second the patch I sent you is fine for testing; I was hoping you >>>would try it. What you can't do with it is spawn lots of userspace >>>apps safely SCHED_ISO with it - it will crash, but it not take down >>>your hard disk. I've had significantly better results with that >>>patch so far. Then we cn take it from there. > It was for mm2, but should patch on an iso2 patched kernel. It does apply to 2.6.11-rc1 (on top of your previous patch) with just some minor chunk offsets. The results are excellent... http://www.joq.us/jack/benchmarks/sched-isoprio http://www.joq.us/jack/benchmarks/sched-isoprio+compile I updated the summary information to include them... http://www.joq.us/jack/benchmarks/cycle_max.log http://www.joq.us/jack/benchmarks/delay_max.log http://www.joq.us/jack/benchmarks/xrun_count.log These results are indistinguishable from SCHED_FIFO... ...benchmarks/sched-fifo... Delay Maximum . . . . . . . . : 347 usecs Delay Maximum . . . . . . . . : 277 usecs Delay Maximum . . . . . . . . : 246 usecs ...benchmarks/sched-fifo+compile... Delay Maximum . . . . . . . . : 285 usecs Delay Maximum . . . . . . . . : 269 usecs Delay Maximum . . . . . . . . : 277 usecs Delay Maximum . . . . . . . . : 569 usecs Delay Maximum . . . . . . . . : 461 usecs ...benchmarks/sched-isoprio... Delay Maximum . . . . . . . . : 199 usecs Delay Maximum . . . . . . . . : 261 usecs Delay Maximum . . . . . . . . : 305 usecs ...benchmarks/sched-isoprio+compile... Delay Maximum . . . . . . . . : 405 usecs Delay Maximum . . . . . . . . : 286 usecs Delay Maximum . . . . . . . . : 579 usecs ...benchmarks/sched-iso... Delay Maximum . . . . . . . . : 21410 usecs Delay Maximum . . . . . . . . : 36830 usecs Delay Maximum . . . . . . . . : 4062 usecs ...benchmarks/sched-iso+compile... Delay Maximum . . . . . . . . : 98909 usecs Delay Maximum . . . . . . . . : 39414 usecs Delay Maximum . . . . . . . . : 40294 usecs Delay Maximum . . . . . . . . : 217192 usecs Delay Maximum . . . . . . . . : 156989 usecs So, thread priorities clearly do matter, even in this relatively simple test. It's amazing how much is going on there, when you look at it closely. Is there any chance of these patches working with Ingo's latest RP patchset? I just downloaded realtime-preempt-2.6.11-rc2-V0.7.36-02, but haven't built it yet. -- joq - 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/
Help Regarding putting my module into the kernel
Hello linux-experts, I am intercepting a few syscalls in kernel 2.4.28. My module name is rsched.c. To put it in the kernel, I created a new subdirectory with the name rsched under /linux-2.4.28 source directory. I created the Makefile for it. I included the rsched subdirectory in the list of kernel subdirectories in the toplevel Makefile as SUDIRS := (all-available subdirectories) rsched But when I build the kernel depmod showed the following error: depmod: cannot read ELF header from /lib/modules/2.4.28-rsched/kernel/rsched/rsched.o How can I correct it and add my module into the kernel? Can anyone help me regarding this? I have also attached the Makefile here. Thanks, selva Makefile O_TARGET := rsched.o obj-m := $(O_TARGET) include $(TOPDIR)/Rules.make -- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: md and RAID 5 [was Re: LVM2]
On Friday January 21, [EMAIL PROTECTED] wrote: > Thank you all for having been so kind in your responses and help. > > However, there is one more set of questions I have. > > Does the md (software raid) have disk size or raid volume limits? 2^31 sectors for individual disks. Arrays do not have this limit. > > If I am using such things as USB or 1394 disks, is there a way to use > labels in /etc/raidtab and with the tools so that when the disks, if > they do, get renumbered in /dev that all works fine. I am aware that the > kernel will autodetect these devices, but that the raidtab needs to be > consistent. This is what I am trying to figure out how to do. Scrap raidtools and /etc/raidtab. Explore "mdadm" and /etc/mdadm.conf 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: Radeon framebuffer weirdness in -mm2
On Thu, 2005-01-20 at 22:09 -0800, Matt Mackall wrote: > > It's something in this batch. Which is good, as I'd be a bit > disappointed if the "vt leakage" were somehow attributable to the fb > layer. More bisection after dinner. Regarding the radeonfb reboot problem, can you try this patch on top of -mm2 ? --- linux-work.orig/drivers/video/aty/radeon_base.c 2005-01-24 12:19:09.0 +1100 +++ linux-work/drivers/video/aty/radeon_base.c 2005-01-24 14:59:14.0 +1100 @@ -2435,13 +2435,16 @@ radeonfb_pm_exit(rinfo); +#if 0 /* restore original state * -* Doesn't quite work yet, possibly because of the PPC hacking -* I do on startup, disable for now. --BenH +* Doesn't quite work yet, I suspect if we come from a legacy +* VGA mode (or worse, text mode), we need to do some VGA black +* magic here that I know nothing about. --BenH */ radeon_write_mode (rinfo, >init_state, 1); - + #endif + del_timer_sync(>lvds_timer); #ifdef CONFIG_MTRR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/13] Qsort
Here are semi-templated versions of quicksort and heapsort, just for
completeness. The quicksort uses the median of three.
Chuck
void quicksort0( *pl, *pr)
{
vp, SWAP_temp;
*stack[100], **sptr = stack, *pm, *pi, *pj, *pt;
for(;;) {
while ((pr - pl) > 15) {
/* quicksort partition */
pm = pl + ((pr - pl) >> 1);
if ((*pm,*pl)) SWAP(*pm,*pl);
if ((*pr,*pm)) SWAP(*pr,*pm);
if ((*pm,*pl)) SWAP(*pm,*pl);
vp = *pm;
pi = pl;
pj = pr - 1;
SWAP(*pm,*pj);
for(;;) {
do ++pi; while ((*pi,vp));
do --pj; while ((vp,*pj));
if (pi >= pj) break;
SWAP(*pi,*pj);
}
SWAP(*pi,*(pr-1));
/* push largest partition on stack */
if (pi - pl < pr - pi) {
*sptr++ = pi + 1;
*sptr++ = pr;
pr = pi - 1;
}else{
*sptr++ = pl;
*sptr++ = pi - 1;
pl = pi + 1;
}
}
/* insertion sort */
for(pi = pl + 1; pi <= pr; ++pi) {
vp = *pi;
for(pj = pi, pt = pi - 1; pj > pl && (vp,
*pt);) {
*pj-- = *pt--;
}
*pj = vp;
}
if (sptr == stack) break;
pr = *(--sptr);
pl = *(--sptr);
}
}
void heapsort0( *a, long n)
{
tmp;
long i,j,l;
/* The array needs to be offset by one for heapsort indexing */
a -= 1;
for (l = n>>1; l > 0; --l) {
tmp = a[l];
for (i = l, j = l<<1; j <= n;) {
if (j < n && (a[j], a[j+1]))
j += 1;
if ((tmp, a[j])) {
a[i] = a[j];
i = j;
j += j;
}else
break;
}
a[i] = tmp;
}
for (; n > 1;) {
tmp = a[n];
a[n] = a[1];
n -= 1;
for (i = 1, j = 2; j <= n;) {
if (j < n && (a[j], a[j+1]))
j++;
if ((tmp, a[j])) {
a[i] = a[j];
i = j;
j += j;
}else
break;
}
a[i] = tmp;
}
}
-
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: Kernel 2.6.11-rc1/2 goes Postal on LTP
Bryce Harrington wrote: On Fri, 21 Jan 2005, Chris Wright wrote: * Bryce Harrington ([EMAIL PROTECTED]) wrote: Well, I'm not having much luck. strace isn't installed on the system (and is giving errors when trying to compile it). Also, the ssh session (and sshd) quits whenever I try running the following growfiles command manually, so I'm having trouble replicating the kernel panic manually. Sounds very much like oom killer gone nuts. # growfiles -W gf14 -b -e 1 -u -i 0 -L 20 -w -l -C 1 -T 10 glseek19 glseek19.2 Anyway, if anyone wants to investigate this further, I can provide access to the machine (email me). Otherwise, I'm probably just going to wait for -rc2 and see if the problem's still there. Wait no longer, it's here ;-) Hmm, still the kernel is going nutso. LTP and everything else on the system is getting killed, including the test manager process. Below's a bit more info scraped from the console. This is from a run on RH 9.0. It looks like LTP got through 722 of its 2270 tests before the kernel goes postal on it. This time it got through all the growfile commands before it died (see bottom of this post), however it looks like the same growfile cmd I reported earlier is the one causing the problem. When I run: mkfifo gffifo18; strace growfiles -b -W gf13 -e 1 -u -i 0 -L 30 -I r -r 1-4096 gffifo18 &> /tmp/growfiles_strace_log.txt The following happens: * I get this strace log: http://developer.osdl.org/bryce/growfiles_strace_log.txt * The ssh session dies and returns to login prompt * A bunch of stuff similar to below is spewed to console Similar for me, easy to reproduce (3 times today). Here's a kernel messages log, with 32 processes killed, mostly hotplug, but also bash (2x), runltp, & some daemons. I could not login and do anything else, but I could/did SysRq-T, P, M, S, U, B to reboot. These are also in the log. log: http://developer.osdl.org/rddunlap/oom/oom_kill.txt config: http://developer.osdl.org/rddunlap/oom/config-2611rc2 on P4-UP, 1 GB RAM. -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: irq 3: nobody cared! with Intel 31244 SATA.... Advice??
> -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-kernel- > [EMAIL PROTECTED] On Behalf Of David Sims > Sent: Monday, 24 January 2005 13:57 > > I then downloaded and built kernel 2.6.10 which boots up fine without > the sata_vsc module If you then load the sata_vsc module manually > using "modprobe sata_vsc" it will cause the following error once for > each attached disk drive: > > Jan 23 09:08:21 linux kernel: Disabling IRQ #3 > Jan 23 09:08:23 linux kernel: irq 3: nobody cared! I once had the same problem; I think enabling APIC solved it Atul - 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/
Touchpad problems with 2.6.11-rc2
Hi, Vojtech:
Since the 2.6.11-rc2, I encounter problems with touchpad and keyboard
on my laptop, Dell Lattitude D600. The following patch appears to be
the culprit:
diff -urp -X dontdiff linux-2.6.11-rc1/drivers/input/mouse/psmouse-base.c
linux-2.6.11-rc2/drivers/input/mouse/psmouse-base.c
--- linux-2.6.11-rc1/drivers/input/mouse/psmouse-base.c 2005-01-12
16:20:42.0 -0800
+++ linux-2.6.11-rc2/drivers/input/mouse/psmouse-base.c 2005-01-22
14:54:14.0 -0800
@@ -451,14 +451,16 @@ static int psmouse_extensions(struct psm
/*
* Try ALPS TouchPad
*/
- if (max_proto > PSMOUSE_IMEX && alps_detect(psmouse, set_properties) ==
0) {
- if (!set_properties || alps_init(psmouse) == 0)
- return PSMOUSE_ALPS;
-
+ if (max_proto > PSMOUSE_IMEX) {
+ ps2_command(>ps2dev, NULL, PSMOUSE_CMD_RESET_DIS);
+ if (alps_detect(psmouse, set_properties) == 0) {
+ if (!set_properties || alps_init(psmouse) == 0)
+ return PSMOUSE_ALPS;
/*
* Init failed, try basic relative protocols
*/
- max_proto = PSMOUSE_IMEX;
+ max_proto = PSMOUSE_IMEX;
+ }
}
if (max_proto > PSMOUSE_IMEX && genius_detect(psmouse, set_properties)
== 0)
Without the patch, touchpad is not detected as such. Instead, dmesg shows:
input: PS/2 Generic Mouse on isa0060/serio1
With this patch, I see this:
ALPS Touchpad (Dualpoint) detected
Disabling hardware tapping
input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
Looks like detection is correct, however either ALPS specific code doesn't work
right, or it sets wrong parameters, I cannot tell. Here's the list of problems,
from worst to least annoying:
- Very often, keyboard stops working after a click. Typing anything has no
effect.
However, any smallest pointer movement will restore keyboard, and then an
application receives all buffered characters. This is very bad.
- Double-click sometimes fails to work. I have to wait a second and retry it.
Retrying right away is likely not to work again.
- Slow motion of finger produces no motion, then a jump. So, it's very hard to
target smaller UI elements and some web links.
I do not use the nipple, so I cannot tell if that one works or worked before.
Not everything is bad. For example, old input code (in 2.6.10) sometimes
"warped"
mouse to the bottom of the screen, or confused motion with clicks. This problem
appears to be gone now. It would be just great if you could look into keyboard
stoppages, too.
Have a great day,
-- Pete
P.S. I hate the tap, so keep it disabled by default, please :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/13] Qsort
On Mon, Jan 24, 2005 at 11:21:29AM +1100, Nathan Scott wrote: > On Sat, Jan 22, 2005 at 08:29:30PM -0800, Matt Mackall wrote: > > On Sun, Jan 23, 2005 at 03:39:34AM +0100, Andi Kleen wrote: > > > > c) the three-way median selection does help avoid worst-case O(n^2) > > behavior, which might potentially be triggerable by users in places > > like XFS where this is used > > XFS's needs are simple - we're just sorting dirents within a > single directory block or smaller, and sorting EA lists/ACLs - > all of which are small arrays, so a qsort optimised for small > arrays suits XFS well. Ok, I've worked up a much smaller, cleaner version that wins on lists of 1 entries or less and is still within 5% at 1M entries (ie well past what any kernel code has any business doing). More after I've fiddled around a bit more with the benchmarks. > Take care not to put any arrays on the > stack though, else the CONFIG_4KSTACKS punters won't be happy. I'm afraid I'm one of those punters - 4k stacks were getting cleaned up and tested in my -tiny tree long before mainline. -- 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/
irq 3: nobody cared! with Intel 31244 SATA.... Advice??
Hi folks, I have a Dell Powervault 745N appliance that I am trying to install Slackware Linux on I have temporarily installed a dual port IDE card in the expansion slot so I can have the benefit of a CD-ROM and IDE PATA HD Slackware 9.1 installs straightforwardly to the IDE PATA HD and it boots up fine I first tried to get the SATA disk talking with the 2.4.29 kernel... This kernel boots but hangs when it tries to load module sata_vsc either from rc.modules or manually after startup using "modprobe sata_vsc" I then downloaded and built kernel 2.6.10 which boots up fine without the sata_vsc module If you then load the sata_vsc module manually using "modprobe sata_vsc" it will cause the following error once for each attached disk drive: Jan 23 09:08:21 linux kernel: Disabling IRQ #3 Jan 23 09:08:23 linux kernel: irq 3: nobody cared! Jan 23 09:08:23 linux kernel: [] __report_bad_irq+0x22/0x90 Jan 23 09:08:23 linux kernel: [] note_interrupt+0x58/0x90 Jan 23 09:08:23 linux kernel: [] __do_IRQ+0xd8/0xe0 Jan 23 09:08:23 linux kernel: [] do_IRQ+0x1a/0x30 Jan 23 09:08:23 linux kernel: [] common_interrupt+0x1a/0x20 Jan 23 09:08:23 linux kernel: [] __do_softirq+0x30/0x90 Jan 23 09:08:23 linux kernel: [] do_softirq+0x35/0x40 Jan 23 09:08:23 linux kernel: [] do_IRQ+0x1f/0x30 Jan 23 09:08:23 linux kernel: [] common_interrupt+0x1a/0x20 Jan 23 09:08:23 linux kernel: [] default_idle+0x0/0x40 Jan 23 09:08:23 linux kernel: [] default_idle+0x24/0x40 Jan 23 09:08:23 linux kernel: [] cpu_idle+0x2e/0x40 Jan 23 09:08:23 linux kernel: [] start_kernel+0x15b/0x190 Jan 23 09:08:23 linux kernel: handlers: Jan 23 09:08:23 linux kernel: [] (ide_intr+0x0/0x120) Jan 23 09:08:23 linux kernel: [] (ide_intr+0x0/0x120) Jan 23 09:08:23 linux kernel: [] (vsc_sata_interrupt+0x0/0xa0 [sata_vsc]) but it will then load and work ok and allow me to fdisk, format and mount the disk normally. If I run 'modprobe sata_vsc' from rc.modules, then it hangs while trying to talk to the first disk just like kernel 2.4.29 did I have repetitively seen this behavior both with a module and with the module builtin to the kernel I have also built the kernel with and without ACPI as some of the traffic in the newsgroups indicated that could be a problem... This caused no change in behavior Since my ambition is to get this machine to boot from the SATA disk I am stuck at this point If anyone can provide a little advice or direction I would be indebted... I have fiddled with the PCI BIOS IRQ settings without joy... You can change which IRQ is used by the sata controller but then the error message just changes to that IRQ (i.e., irq 7: nobody cared!) It may be of interest to note that the SATA controller (Intel 31244) and the dual port IDE card in the expansion slot seem to be forced in the BIOS to share the IRQ that is assigned to either one... Again, any advice would be very welcome at this point TIA, Dave Sims Houston, Texas USA - 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] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
On Sunday 23 January 2005 20:01, andyliu wrote: >hi Gene > Thanks, I'll give it a shot and see if it fits my hardware. >i am lucky enough to have 2.6.11-rc2-V0.7.36-02 compile and run in > my i386 host. below is my config > ># ># Automatically generated make config: don't edit ># Linux kernel version: 2.6.11-rc2-RT-V0.7.36-02 ># Mon Jan 24 08:45:39 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="RT" >CONFIG_SWAP=y >CONFIG_SYSVIPC=y >CONFIG_POSIX_MQUEUE=y ># 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_EMBEDDED=y ># CONFIG_KALLSYMS is not set >CONFIG_FUTEX=y >CONFIG_EPOLL=y ># CONFIG_CC_OPTIMIZE_FOR_SIZE is not set ># CONFIG_SHMEM is not set >CONFIG_CC_ALIGN_FUNCTIONS=0 >CONFIG_CC_ALIGN_LABELS=0 >CONFIG_CC_ALIGN_LOOPS=0 >CONFIG_CC_ALIGN_JUMPS=0 >CONFIG_TINY_SHMEM=y > ># ># Loadable module support ># >CONFIG_MODULES=y ># CONFIG_MODULE_UNLOAD is not set >CONFIG_OBSOLETE_MODPARM=y ># CONFIG_MODVERSIONS is not set ># CONFIG_MODULE_SRCVERSION_ALL is not set >CONFIG_KMOD=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_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_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 is not set >CONFIG_SMP=y >CONFIG_NR_CPUS=2 >CONFIG_SCHED_SMT=y ># CONFIG_PREEMPT_NONE is not set ># CONFIG_PREEMPT_VOLUNTARY is not set ># CONFIG_PREEMPT_DESKTOP is not set >CONFIG_PREEMPT_RT=y >CONFIG_PREEMPT=y >CONFIG_PREEMPT_SOFTIRQS=y >CONFIG_PREEMPT_HARDIRQS=y >CONFIG_PREEMPT_BKL=y >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 is not set ># CONFIG_X86_MSR is not set ># CONFIG_X86_CPUID is not set > ># ># Firmware Drivers ># ># CONFIG_EDD is not set >CONFIG_NOHIGHMEM=y ># CONFIG_HIGHMEM4G is not set ># CONFIG_HIGHMEM64G is not set ># CONFIG_MATH_EMULATION is not set >CONFIG_MTRR=y >CONFIG_IRQBALANCE=y >CONFIG_HAVE_DEC_LOCK=y ># CONFIG_REGPARM is not set > ># ># Power management options (ACPI, APM) ># ># CONFIG_PM is not set > ># ># ACPI (Advanced Configuration and Power Interface) Support ># ># CONFIG_ACPI is not set >CONFIG_ACPI_BOOT=y >CONFIG_ACPI_BLACKLIST_YEAR=0 > ># ># 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_PCIEPORTBUS is not set ># CONFIG_PCI_MSI is not set >CONFIG_PCI_LEGACY_PROC=y >CONFIG_PCI_NAMES=y >CONFIG_ISA=y ># CONFIG_EISA is not set ># CONFIG_MCA is not set ># CONFIG_SCx200 is not set > ># ># PCCARD (PCMCIA/CardBus) support ># ># CONFIG_PCCARD is not set > ># ># PC-card bridges ># >CONFIG_PCMCIA_PROBE=y > ># ># PCI Hotplug Support ># ># CONFIG_HOTPLUG_PCI is not set > ># ># Executable file formats ># >CONFIG_BINFMT_ELF=y >CONFIG_BINFMT_AOUT=y >CONFIG_BINFMT_MISC=y > ># ># Device Drivers ># > ># ># Generic Driver Options ># >CONFIG_STANDALONE=y >CONFIG_PREVENT_FIRMWARE_BUILD=y >CONFIG_FW_LOADER=m > ># ># Memory Technology Devices (MTD) ># ># CONFIG_MTD is not set > ># ># Parallel port support ># >CONFIG_PARPORT=y >CONFIG_PARPORT_PC=y >CONFIG_PARPORT_PC_CML1=y ># CONFIG_PARPORT_SERIAL is not set ># CONFIG_PARPORT_PC_FIFO is not set ># CONFIG_PARPORT_PC_SUPERIO is not set ># CONFIG_PARPORT_OTHER is not set ># CONFIG_PARPORT_1284 is not set > ># ># Plug and Play support ># >CONFIG_PNP=y ># CONFIG_PNP_DEBUG is not set > ># ># Protocols ># ># CONFIG_ISAPNP is not set >#
Re: [PATCH 0/8] core-small: Introduce CONFIG_CORE_SMALL from -tiny
On Sun, Jan 23, 2005 at 01:05:14PM -0800, Andrew Morton wrote: > Matt Mackall <[EMAIL PROTECTED]> wrote: > > > > > I wish it didn't have "core" in the name. A little misleading. > > > > Well I've got another set called NET_SMALL. BASE? > > BASE works, I guess. > > > > #define PID_MAX_DEFAULT (CONFIG_CORE_SMALL ? 0x1000 : 0x8000) > > > #define UIDHASH_BITS (CONFIG_CORE_SMALL ? 3 : 8) > > > #define FUTEX_HASHBITS (CONFIG_CORE_SMALL ? 4 : 8) > > > etc. > > > > Hmm. I think we'd want a hidden config variable for this and I'm not > > sure how well the config language allows setting an int from a bool. > > config AKPM_BOOL > bool "akpm" > > config AKPM_INT > int > default 1 if AKPM_BOOL > default 0 if !AKPM_BOOL > > seems to do everything which it should. > > > And then it would need another name. On the whole, seems more complex > > than what I've done. > > No, it's quite simple and avoids lots of ifdeffing. Ok, will respin these Monday. -- 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: Patch to fix race between the NMI code and the CMOS clock
Andrew Morton wrote:
Corey Minyard <[EMAIL PROTECTED]> wrote:
This patch fixes a race between the CMOS clock setting and the NMI
code. The NMI code indiscriminatly sets index registers and values
in the same place the CMOS clock is set. If you are setting the
CMOS clock and an NMI occurs, Bad values could be written to or
read from the CMOS RAM, or the NMI operation might not occur
correctly.
Fixing this requires creating a special lock so the NMI code can
know its CPU owns the lock an "do the right thing" in that case.
hm, tricky patch. I can't see any holes in it. The volatile variable is
awkward but should be OK on x86 and I can see the need for it.
There's a preposterous amount of inlining happening in this code. Hence
your patch took the size of drivers/char/rtc.o from
textdata bss dec hex filename
3657 540 84205106d drivers/char/rtc.o
to
5419 540 85967174f drivers/char/rtc.o
Do you think you could take a look at uninlining everything sometime?
Ok, done. With the attached patch I get ~2300 bytes less text in that
file. It makes CMOS_READ and CMOS_WRITE functions. They were used all
over the place in drivers/char/rtc.o, and the extra locking stuff took a
lot of space. I also fixed some comment grammer and I discovered that
linux/smp.h needed to be included, since smp_processor_id() was being
called.
-Corey
This patch fixes a race between the CMOS clock setting and the NMI
code. The NMI code indiscriminatly sets index registers and values
in the same place the CMOS clock is set. If you are setting the
CMOS clock and an NMI occurs, Bad values could be written to or
read from the CMOS RAM, or the NMI operation might not occur
correctly.
Fixing this requires creating a special lock so the NMI code can
know its CPU owns the lock an "do the right thing" in that case.
This was discovered and the fix has been tested by a very demanding
customer who tests the heck of out the software we deliver.
Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc1/arch/i386/kernel/time.c
===
--- linux-2.6.11-rc1.orig/arch/i386/kernel/time.c 2005-01-23
13:23:01.0 -0600
+++ linux-2.6.11-rc1/arch/i386/kernel/time.c2005-01-23 13:56:13.0
-0600
@@ -83,6 +83,34 @@
spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED;
+/*
+ * This is a special lock that is owned by the CPU and holds the index
+ * register we are working with. It is required for NMI access to the
+ * CMOS/RTC registers. See include/asm-i386/mc146818rtc.h for details.
+ */
+volatile unsigned long cmos_lock = 0;
+EXPORT_SYMBOL(cmos_lock);
+
+/* Routines for accessing the CMOS RAM/RTC. */
+unsigned char rtc_cmos_read(unsigned char addr)
+{
+ unsigned char val;
+ lock_cmos_prefix(addr);
+ outb_p(addr, RTC_PORT(0));
+ val = inb_p(RTC_PORT(1));
+ lock_cmos_suffix(addr);
+ return val;
+}
+EXPORT_SYMBOL(rtc_cmos_read);
+void rtc_cmos_write(unsigned char val, unsigned char addr)
+{
+ lock_cmos_prefix(addr);
+ outb_p(addr, RTC_PORT(0));
+ outb_p(val, RTC_PORT(1));
+ lock_cmos_suffix(addr);
+}
+EXPORT_SYMBOL(rtc_cmos_write);
+
spinlock_t i8253_lock = SPIN_LOCK_UNLOCKED;
EXPORT_SYMBOL(i8253_lock);
Index: linux-2.6.11-rc1/include/asm-i386/mach-default/mach_traps.h
===
--- linux-2.6.11-rc1.orig/include/asm-i386/mach-default/mach_traps.h
2005-01-23 13:23:01.0 -0600
+++ linux-2.6.11-rc1/include/asm-i386/mach-default/mach_traps.h 2005-01-23
13:23:04.0 -0600
@@ -7,6 +7,8 @@
#ifndef _MACH_TRAPS_H
#define _MACH_TRAPS_H
+#include
+
static inline void clear_mem_error(unsigned char reason)
{
reason = (reason & 0xf) | 4;
@@ -20,10 +22,20 @@
static inline void reassert_nmi(void)
{
+ int old_reg = -1;
+
+ if (do_i_have_lock_cmos())
+ old_reg = current_lock_cmos_reg();
+ else
+ lock_cmos(0); /* register doesn't matter here */
outb(0x8f, 0x70);
inb(0x71); /* dummy */
outb(0x0f, 0x70);
inb(0x71); /* dummy */
+ if (old_reg >= 0)
+ outb(old_reg, 0x70);
+ else
+ unlock_cmos();
}
#endif /* !_MACH_TRAPS_H */
Index: linux-2.6.11-rc1/include/asm-i386/mc146818rtc.h
===
--- linux-2.6.11-rc1.orig/include/asm-i386/mc146818rtc.h2005-01-23
13:23:01.0 -0600
+++ linux-2.6.11-rc1/include/asm-i386/mc146818rtc.h 2005-01-23
14:03:09.0 -0600
@@ -5,24 +5,89 @@
#define _ASM_MC146818RTC_H
#include
+#include
+#include
#ifndef RTC_PORT
#define RTC_PORT(x)(0x70 + (x))
#define RTC_ALWAYS_BCD 1 /* RTC operates in binary mode */
#endif
+#ifdef __HAVE_ARCH_CMPXCHG
+/*
+ * This lock provides nmi access to
Problem with cpu_rest() change
Hi Ingo ! Could you explain me precisely what is the race you are fixing by adding local_irq_disable() to rest_init() ? This patch is causing lockups on boot on various ppc machines. I think i've found at least one possible reason for that in the ppc cpu_idle() code, which may not re-enable interrupts in some cases when need_resched() is not set, assuming they were enabled on entry. However, I'm wondering precisely what exact race you are trying to fix as my fix would cause IRQs to be re-enabled before the call to schedule() when need_resched() is not set, which goes against the comment you added to rest_init() about letting them be re-enable by schedule() itself... 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: usbmon, usb core, ARM
On Sunday 23 January 2005 5:17 pm, Pete Zaitcev wrote: > On Sun, 23 Jan 2005 15:34:23 -0800, David Brownell <[EMAIL PROTECTED]> wrote: > > ... > > > and this is what usbmon intercepts. > > > For one thing, dev is down-counted in usb_unlink_urb(). ^^ > > > > I don't see any refcounting calls in that routine. It couldn't change > > the refcounts, in any case ... the HCD owns the URB until giveback(), > > and all unlinking does is accelerate getting to that giveback(). > > I am talking about this code (in 2.6.11-rc2): > > static void urb_unlink (struct urb *urb) ^^ See what I mean? That's not usb_unlink_urb()! And if you look at that function, you'll see I was correct. If you're concerned about that little helper function then just call the URB tracing hooks earlier, or move the call to urb_unlink() later. That sequencing in giveback() obviously doesn't matter ... the sketches for hcd_monitor_hook() were probably correct when added, but that was a very LONG time ago, before things like urb_unlink() was added. > ... > > void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb, struct > pt_regs *regs) > ... > > Even if urb->dev was possible to dereference in the completion callback, > the hcd was not available. I'm not following your logic still. I see it as a parameter right there; how could it suddenly become unavailable And remember the hooking is done BEFORE the callback, not IN it. > > For example, how does userspace provide a filter to say what URBs > > it's interested in, and what level of information to report? > > I do not have plans to do that. In the network space, it's the difference > between BPF (and its spawn LPF), and, say DLPI tap or /dev/nit on SunOS. So you plan to spit EVERY urb up into userspace? Copy EVERY byte of data? I could understand that as an initial prototype, but as a long term plan it seems troublesome. It would certainly affect the protocol timings, and we know that USB peripherals can be sensitive to such things. And for applications like watching video captures, copying a 24 Mbyte/sec stream does make a noticeable performance hit. (Especially when it's done during IRQ processing...) Note that I didn't say any particular networking filter model should be applied, that was your implication. If one of those models works well for USB, so be it. But I wouldn't necessarily expect any of them to do that, even though one can argue that USB is a little network based on parallels of addressing. > However, nothing prevents you from adding another reader type to usbmon, > the one which does filtering. Heck, an ability to replace whole usbmon > is a design parameter. Indeed, that's exactly why I'd like to split out discussion of the hooks (currently living only as comments) from what's done with them (such as usbmon). The comments about an hcd_monitor_hook() were done with expectation that someone would someday want to plug in such components ... and have the ability to experiment with them. If we could agree on reusable monitor hooks, sufficient for your current work, that'd be a good step. - 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/
usbmon with explicit hooks
Hi, guys:
I thought the David's argument over and decided that it makes usbmon simpler
if hooks are made explicit. Most importantly, URBs are not tracked anymore
at all. This magically fixes ISO and interrupt URBs. The struct urb does
not have anything added anymore, there's no need to jiggle with urb->complete.
However, I still need to change how we help root hubs at ARM. This time
I do not touch pipe and use the old check when it's valid. This should
address everyone's concerns. If I hear no new howls of outrage, I'm going
to submit this to Greg.
Cheers,
-- Pete
diff -urpN -X dontdiff linux-2.6.11-rc2/drivers/usb/core/hcd.c
linux-2.6.11-rc2-lem/drivers/usb/core/hcd.c
--- linux-2.6.11-rc2/drivers/usb/core/hcd.c 2005-01-22 14:54:24.0
-0800
+++ linux-2.6.11-rc2-lem/drivers/usb/core/hcd.c 2005-01-23 17:19:18.0
-0800
@@ -86,6 +86,7 @@
/* host controllers we manage */
LIST_HEAD (usb_bus_list);
+EXPORT_SYMBOL_GPL (usb_bus_list);
/* used when allocating bus numbers */
#define USB_MAXBUS 64
@@ -96,6 +97,7 @@ static struct usb_busmap busmap;
/* used when updating list of hcds */
DECLARE_MUTEX (usb_bus_list_lock); /* exported only for usbfs */
+EXPORT_SYMBOL_GPL (usb_bus_list_lock);
/* used when updating hcd data */
static DEFINE_SPINLOCK(hcd_data_lock);
@@ -103,6 +105,10 @@ static DEFINE_SPINLOCK(hcd_data_lock);
/* wait queue for synchronous unlinks */
DECLARE_WAIT_QUEUE_HEAD(usb_kill_urb_queue);
+#if defined(CONFIG_USB_MON) || defined(CONFIG_USB_MON_MODULE)
+struct usb_mon_operations *mon_ops;
+#endif /* CONFIG_USB_MON */
+
/*-*/
/*
@@ -746,6 +752,7 @@ int usb_register_bus(struct usb_bus *bus
up (_bus_list_lock);
usbfs_add_bus (bus);
+ usbmon_notify_bus_add (bus);
dev_info (bus->controller, "new USB bus registered, assigned bus number
%d\n", bus->busnum);
return 0;
@@ -773,6 +780,7 @@ void usb_deregister_bus (struct usb_bus
list_del (>bus_list);
up (_bus_list_lock);
+ usbmon_notify_bus_remove (bus);
usbfs_remove_bus (bus);
clear_bit (bus->busnum, busmap.busmap);
@@ -1058,9 +1066,7 @@ static int hcd_submit_urb (struct urb *u
* as simple as possible.
*/
- // NOTE: a generic device/urb monitoring hook would go here.
- // hcd_monitor_hook(MONITOR_URB_SUBMIT, urb)
- // It would catch submission paths for all urbs.
+ usbmon_urb_submit(>self, urb);
/*
* Atomically queue the urb, first to our records, then to the HCD.
@@ -1087,6 +1093,7 @@ static int hcd_submit_urb (struct urb *u
spin_unlock_irqrestore (_data_lock, flags);
if (status) {
INIT_LIST_HEAD (>urb_list);
+ usbmon_urb_submit_error(>self, urb, status);
return status;
}
@@ -1103,8 +1110,6 @@ static int hcd_submit_urb (struct urb *u
* valid and usb_buffer_{sync,unmap}() not be needed, since
* they could clobber root hub response data.
*/
- urb->transfer_flags |= (URB_NO_TRANSFER_DMA_MAP
- | URB_NO_SETUP_DMA_MAP);
status = rh_urb_enqueue (hcd, urb);
goto done;
}
@@ -1139,6 +1144,7 @@ done:
if (urb->reject)
wake_up (_kill_urb_queue);
usb_put_urb (urb);
+ usbmon_urb_submit_error(>self, urb, status);
}
return status;
}
@@ -1461,14 +1467,13 @@ static struct usb_operations usb_hcd_ope
*/
void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb, struct
pt_regs *regs)
{
- urb_unlink (urb);
+ int at_root_hub;
- // NOTE: a generic device/urb monitoring hook would go here.
- // hcd_monitor_hook(MONITOR_URB_FINISH, urb, dev)
- // It would catch exit/unlink paths for all urbs.
+ at_root_hub = (urb->dev == hcd->self.root_hub);
+ urb_unlink (urb);
/* lower level hcd code should use *_dma exclusively */
- if (hcd->self.controller->dma_mask) {
+ if (hcd->self.controller->dma_mask && !at_root_hub) {
if (usb_pipecontrol (urb->pipe)
&& !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP))
dma_unmap_single (hcd->self.controller, urb->setup_dma,
@@ -1484,6 +1489,7 @@ void usb_hcd_giveback_urb (struct usb_hc
: DMA_TO_DEVICE);
}
+ usbmon_urb_complete (>self, urb);
/* pass ownership to the completion handler */
urb->complete (urb, regs);
atomic_dec (>use_count);
@@ -1591,3 +1597,43 @@ void usb_put_hcd (struct usb_hcd *hcd)
usb_bus_put(>self);
}
EXPORT_SYMBOL (usb_put_hcd);
+
+/*-*/
+
+#if defined(CONFIG_USB_MON)
Re: DVD burning still have problems
On Monday 24 Jan 2005 06:59, Alessandro Suardi wrote:
> On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
>
> <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > have you checked, that cdrecord is not suid root, and
> > growisofs/dvd+rw-tools is?
> >
> > I had some probs, solved with a simple chmod +s growisofs :)
>
> Lucky you. Burning as root here, cdrecord not suid. Tried also
> burning with a +s growisofs, but...
You can test if it's the kernel/growisofs clashing by hacking the
drivers/block/scsi_ioctl.c code
It's around line 193 in 2.6.9, and line 196 in 2.6.10
not sure about 2.6.11
find the code:
/* Write-safe commands just require a writable open.. */
if (type & CMD_WRITE_SAFE) {
if (file->f_mode & FMODE_WRITE)
return 0;
}
edit it to something like:
/* Write-safe commands just require a writable open.. */
if (type & CMD_WRITE_SAFE) {
printk ("Write safe command in ");
if (file->f_mode & FMODE_WRITE)
printk ("write mode.\n");
else
printk ("read mode.\n");
return 0;
}
Compile the kernel with that and that may make it work and burn dvd and let
you know if it's growisofs sending incorrect commands. You'll get messages in
dmesg like
Write safe command in read mode.
which means growisofs is still not right. Maybe later version fixed this?
tim
--
-
Tim & Therese Fairchild
Atchafalaya Border Collies.
Kuttabul, Queensland, Australia.
-
Email mailto:[EMAIL PROTECTED]
Homepagehttp://www.bcs4me.com
Photos http://www.pbase.com/amosf
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: 2.6.11-rc2 and -rc1 hang during boot on PowerMacs
On Sun, 2005-01-23 at 11:43 +1100, Benjamin Herrenschmidt wrote:
> I know about this problem, I'm working on a proper fix. Thanks for your
> report.
Can you send me the PVR value for both of these CPUs
(cat /proc/cpuinfo) ? I can't find right now why they would lock up
unless the default idle loop is _not_ run properly, that is for some
reason, NAP or DOZE mode end up not beeing enabled. Can you send me
your .config as well ?
Finally, try that patch and tell me if it makes a difference. It makes
sure we re-enable interrupts in cpu_idle, and thus should only be a
workaround. I found _one_ actual code path where we fail to re-enable
them, and this is when neither DOZE nor NAP mode is enabled, which
should not happen on any G3 (they should all support DOZE mode), and
might happe non some G4s if the chipset doesn't support NAP or
powersave_nap is set to 0 in proc, but that shouldn't be the case of an
eMac neither...
--- linux-work.orig/arch/ppc/kernel/idle.c 2005-01-24 11:42:35.0
+1100
+++ linux-work/arch/ppc/kernel/idle.c 2005-01-24 12:19:41.114353760 +1100
@@ -39,17 +39,15 @@
powersave = ppc_md.power_save;
if (!need_resched()) {
+ local_irq_enable();
if (powersave != NULL)
powersave();
else {
#ifdef CONFIG_SMP
set_thread_flag(TIF_POLLING_NRFLAG);
- local_irq_enable();
while (!need_resched())
barrier();
clear_thread_flag(TIF_POLLING_NRFLAG);
-#else
- local_irq_enable();
#endif
}
}
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: usbmon, usb core, ARM
On Sun, 23 Jan 2005 15:34:23 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> > so let me restate it. Simply put, neither dev nor hcd are available
> > at the time urb->complete is called,
>
> Completely untrue. They are at a minimum provided through the URB itself,
> and giveback (which is the only place that call is made!) is passed the HCD
> as a parameter. Or aren't you talking about 2.6.11 code?
> > and this is what usbmon intercepts.
> > For one thing, dev is down-counted in usb_unlink_urb().
>
> I don't see any refcounting calls in that routine. It couldn't change
> the refcounts, in any case ... the HCD owns the URB until giveback(),
> and all unlinking does is accelerate getting to that giveback().
I am talking about this code (in 2.6.11-rc2):
static void urb_unlink (struct urb *urb)
{
..
/* clear all state linking urb to this dev (and hcd) */
spin_lock_irqsave (_data_lock, flags);
list_del_init (>urb_list);
spin_unlock_irqrestore (_data_lock, flags);
usb_put_dev (urb->dev);<= What is this, chopped liver?
}
void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb, struct pt_regs
*regs)
{
urb_unlink (urb);
// NOTE: a generic device/urb monitoring hook would go here.
/* pass ownership to the completion handler */
urb->complete (urb, regs);
atomic_dec (>use_count);
if (unlikely (urb->reject))
wake_up (_kill_urb_queue);
usb_put_urb (urb);
}
Even if urb->dev was possible to dereference in the completion callback,
the hcd was not available.
But like I said, it's a moot point with explicit hooks.
> For example, how does userspace provide a filter to say what URBs
> it's interested in, and what level of information to report?
I do not have plans to do that. In the network space, it's the difference
between BPF (and its spawn LPF), and, say DLPI tap or /dev/nit on SunOS.
By loading rules into kernel BSD programmers hoped to save a few cycles
by reducing the number of packets delivered to tcpdump. As far as I can
tell, nobody has a practical use for it, savings are miniscule...
I think some distros do not even configure LPF into kernels anymore.
However, nothing prevents you from adding another reader type to usbmon,
the one which does filtering. Heck, an ability to replace whole usbmon
is a design parameter. Rusty rewrote netfilter from scractch two times
(ipfwadm, ip-something-which-I-forgot, iptables). I don't think I can do
everything right with usbmon at first pass either. So I expect other
developers to try out ideas and experiment. Build your filter and prove
me wrong.
-- Pete
-
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]sched: Isochronous class v2 for unprivileged soft rt scheduling
Jack O'Quin wrote: Con Kolivas <[EMAIL PROTECTED]> writes: There are two things that the SCHED_ISO you tried is not that SCHED_FIFO is - As you mentioned there is no priority support, and it is RR, not FIFO. I am not sure whether it is one and or the other responsible. Both can be added to SCHED_ISO. I haven't looked at jackd code but it should be trivial to change SCHED_FIFO to SCHED_RR to see if RR with priority support is enough or not. Sure, that's easy. I didn't do it because I assumed it would not matter. Since the RR scheduling quantum is considerably longer than the basic 1.45msec audio cycle, it should work exactly the same. I'll cobble together a JACK version to try that for you. If you already know the audio cycle is much less than 10ms then there isn't much point trying it. Second the patch I sent you is fine for testing; I was hoping you would try it. What you can't do with it is spawn lots of userspace apps safely SCHED_ISO with it - it will crash, but it not take down your hard disk. I've had significantly better results with that patch so far. Then we cn take it from there. Sorry. I took you literally when you said it was not yet ready to try. This would be the isoprio3 patch you posted? Yes it is. Do I have to use 2.6.11-rc1-mm2, or will it work with 2.6.11-rc1? It was for mm2, but should patch on an iso2 patched kernel. Thanks! Con - 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]sched: Isochronous class v2 for unprivileged soft rt scheduling
Con Kolivas <[EMAIL PROTECTED]> writes: > There are two things that the SCHED_ISO you tried is not that > SCHED_FIFO is - As you mentioned there is no priority support, and it > is RR, not FIFO. I am not sure whether it is one and or the other > responsible. Both can be added to SCHED_ISO. I haven't looked at jackd > code but it should be trivial to change SCHED_FIFO to SCHED_RR to see > if RR with priority support is enough or not. Sure, that's easy. I didn't do it because I assumed it would not matter. Since the RR scheduling quantum is considerably longer than the basic 1.45msec audio cycle, it should work exactly the same. I'll cobble together a JACK version to try that for you. > Second the patch I sent you is fine for testing; I was hoping you > would try it. What you can't do with it is spawn lots of userspace > apps safely SCHED_ISO with it - it will crash, but it not take down > your hard disk. I've had significantly better results with that > patch so far. Then we cn take it from there. Sorry. I took you literally when you said it was not yet ready to try. This would be the isoprio3 patch you posted? Do I have to use 2.6.11-rc1-mm2, or will it work with 2.6.11-rc1? -- joq - 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] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-00
hi Gene i am lucky enough to have 2.6.11-rc2-V0.7.36-02 compile and run in my i386 host. below is my config # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc2-RT-V0.7.36-02 # Mon Jan 24 08:45:39 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="RT" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # 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_EMBEDDED=y # CONFIG_KALLSYMS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_SHMEM is not set CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_TINY_SHMEM=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=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_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_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 is not set CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y 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 is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # # CONFIG_ACPI is not set CONFIG_ACPI_BOOT=y CONFIG_ACPI_BLACKLIST_YEAR=0 # # 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_PCIEPORTBUS is not set # CONFIG_PCI_MSI is not set CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PC-card bridges # CONFIG_PCMCIA_PROBE=y # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_MISC=y # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_CML1=y # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # # CONFIG_ISAPNP is not set # CONFIG_PNPBIOS is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set # CONFIG_BLK_DEV_LOOP is not set #
úaÐpa×Ëa ëõOSåRá FS-1000/1000+/1050/FS-1020D (N) × MocË×e.
Зaпpaвкa КYOSЕRА FS-1000/1000+/1050/FS-1020D (N) opигинaльным тoнepoм, гapaнтия. Зaпpaвкa НР, САNОN, SАМSUNG, дpyгиe фиpмы. Teл: 8-9OI-5IO-3053 Пн-Пт 10-18 ч. - 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: Memory leak in 2.6.11-rc1?
> I don't think I've ever really seen code to diagnose this.
>
> A simplistic approach would be to add eight or so ulongs into struct page,
> populate them with builtin_return_address(0...7) at allocation time, then
> modify sysrq-m to walk mem_map[] printing it all out for pages which have
> page_count() > 0. That'd find the culprit.
Hi Andrew
I put something similar together of what you described but I made it a
proc-file. It lists all pages owned by some caller and keeps a backtrace
of max 8 addresses. Each page has an order, -1 for unused and if used it lists
the order under which the first page is allocated, the rest in the group are
kept -1.
Below is also a program to sort the enormous amount of
output, it will group together backtraces that are alike and list them like:
5 times: Page allocated via order 0
[0x8015861f] __get_free_pages+31
[0x8015c0ef] cache_alloc_refill+719
[0x8015bd74] kmem_cache_alloc+84
[0x8015bddc] alloc_arraycache+60
[0x8015d15d] do_tune_cpucache+93
[0x8015bbf8] cache_alloc_debugcheck_after+280
[0x8015d31d] enable_cpucache+93
[0x8015d8a5] kmem_cache_create+1365
It's a bit of hackety-hack in the function trace routines because doing
__builtin_return_address(0) - 7 doesn't work very well when it
runs out of the stack and the function itself doesn't check for it.
Tested on x86 with and without CONFIG_FRAME_POINTER and x86-64 (which
might are the only archs it'll work on). I hope you like it ;)
Suggested use is
cat /proc/page_owner > pgown;
./below_program pgown pgsorted;
vim pgsorted
#include
#include
#include
#include
#include
#include
#include
struct block_list {
struct block_list *next;
char *txt;
int len;
int num;
};
struct block_list *block_head;
int read_block(char *buf, int fd)
{
int ret = 0, rd = 0;
int hit = 0;
char *curr = buf;
for (;;) {
rd = read(fd, curr, 1);
if (rd <= 0)
return -1;
ret += rd;
if (*curr == '\n' && hit == 1)
return ret - 1;
else if (*curr == '\n')
hit = 1;
else
hit = 0;
curr++;
}
}
int find_duplicate(char *buf, int len)
{
struct block_list *iterate, *item, *prev;
char *txt;
iterate = block_head;
while (iterate) {
if (len != iterate->len)
goto iterate;
if (!memcmp(buf, iterate->txt, len)) {
iterate->num++;
return 1;
}
iterate:
iterate = iterate->next;
}
/* this block didn't exist */
txt = malloc(len);
item = malloc(sizeof(struct block_list));
strncpy(txt, buf, len);
item->len = len;
item->txt = txt;
item->num = 1;
item->next = NULL;
if (block_head) {
prev = block_head->next;
block_head->next = item;
item->next = prev;
} else
block_head = item;
return 0;
}
int main(int argc, char **argv)
{
int fdin, fdout;
char buf[1024];
int ret;
struct block_list *item;
fdin = open(argv[1], O_RDONLY);
fdout = open(argv[2], O_CREAT | O_RDWR | O_EXCL, S_IWUSR | S_IRUSR);
if (fdin < 0 || fdout < 0) {
printf("Usage: ./program \n");
perror("open: ");
exit(2);
}
for(;;) {
ret = read_block(buf, fdin);
if (ret < 0)
break;
buf[ret] = '\0';
find_duplicate(buf, ret);
}
for (item = block_head; item; item = item->next) {
int written;
/* errors? what errors... */
ret = snprintf(buf, 1024, "%d times: ", item->num);
written = write(fdout, buf, ret);
written = write(fdout, item->txt, item->len);
written = write(fdout, "\n", 1);
}
return 0;
}
= fs/proc/proc_misc.c 1.113 vs edited =
--- 1.113/fs/proc/proc_misc.c 2005-01-12 01:42:35 +01:00
+++ edited/fs/proc/proc_misc.c 2005-01-24 00:59:23 +01:00
@@ -534,6 +534,62 @@ static struct file_operations proc_sysrq
};
#endif
+#if 1
+#include
+#include
+static ssize_t
+read_page_owner(struct file *file, char __user *buf, size_t count, loff_t
*ppos)
+{
+ struct page *start = pfn_to_page(min_low_pfn);
+ static struct page *page;
+ char *kbuf, *modname;
+ const char *symname;
+ int ret = 0, next_idx = 1;
+ char namebuf[128];
+ unsigned long offset = 0, symsize;
+ int i;
+
Re: Trying to fix radeonfb suspending on IBM Thinkpad T41
Ãhel kenal pÃeval (pÃhapÃev, 23. jaanuar 2005, 16:54-0500), kirjutas
Volker Braun:
> Update: I compiled a kernel with the radeonfb-massive-update-of-pm-
> code.patch. Now I can successfully resume from acpi S3 again. The power
> drain issue remains, it still uses about 5W in the suspend state.
radeonfb power management is not enabled on PC platform.
I cooked up some code to turn D2 sleep mode on for selected PC-s and
managed to get my ThinkPad to work.
Try this patch on top of radeonfb-massive.
NB! The patch has a model specific triger, so You MUST add Your laptop
model number to the top of the drivers/video/aty/radeon_pm.c.
--
Antti Andreimann - Security Expert
Using Linux since 1993
Member of ELUG since 29.01.2000
--- linux-2.6.11-rc2-tank/drivers/video/aty/radeon_pm.c.orig 2005-01-23 14:55:57.0 +0200
+++ linux-2.6.11-rc2-tank/drivers/video/aty/radeon_pm.c 2005-01-23 21:53:47.0 +0200
@@ -25,8 +25,31 @@
#include
#endif
+/* For detecting supported PC laptops */
+#ifdef CONFIG_X86
+#include
+#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 dmi_system_id __devinitdata radeonfb_dmi_table[] = {
+ {
+ .ident = "IBM ThinkPad T41 (2373-2FG)",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "IBM"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "23732FG"),
+ },
+ },
+ { },
+};
+#endif
+
void radeon_pm_disable_dynamic_mode(struct radeonfb_info *rinfo)
{
u32 tmp;
@@ -2748,6 +2771,24 @@
OUTREG(TV_DAC_CNTL, INREG(TV_DAC_CNTL) | 0x0700);
}
#endif /* defined(CONFIG_PM) && defined(CONFIG_PPC_OF) */
+
+/* The PM code also works on some PC laptops.
+ * Only a few models are actually tested so Your mileage may vary.
+ * We can do D2 on at least M7 and M9 on some IBM ThinkPad T41 models.
+ */
+#if defined(CONFIG_PM) && defined(CONFIG_X86)
+ if (dmi_check_system(radeonfb_dmi_table)) {
+ if (rinfo->is_mobility && rinfo->pm_reg &&
+ rinfo->family <= CHIP_FAMILY_RV250)
+ rinfo->pm_mode |= radeon_pm_d2;
+
+ /* Power down TV DAC, that saves a significant amount of power,
+ * we'll have something better once we actually have some TVOut
+ * support
+ */
+ OUTREG(TV_DAC_CNTL, INREG(TV_DAC_CNTL) | 0x0700);
+ }
+#endif /* defined(CONFIG_PM) && defined(CONFIG_X86) */
}
void radeonfb_pm_exit(struct radeonfb_info *rinfo)
Re: 2.6.11-rc2 complains badly aboud badness in local_bh_enable
Jasper Spaans wrote:
I'm seeing a similar problem on my machine - one that does not know what ppp
is. Main suspect is the network bridging code in combination with iptables;
the first lines of the message:
The patch which caused this has already been reverted.
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/01/20 13:24:38-08:00 [EMAIL PROTECTED]
# Cset exclude: [EMAIL PROTECTED]|ChangeSet|20050120063740|10274
#
# net/sched/sch_teql.c
# 2005/01/20 13:24:32-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# net/sched/sch_generic.c
# 2005/01/20 13:24:32-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# net/core/dev_mcast.c
# 2005/01/20 13:24:32-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# net/core/dev.c
# 2005/01/20 13:24:32-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# net/atm/clip.c
# 2005/01/20 13:24:32-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# include/linux/netdevice.h
# 2005/01/20 13:24:32-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# drivers/infiniband/ulp/ipoib/ipoib_main.c
# 2005/01/20 13:24:32-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# Documentation/networking/netdevices.txt
# 2005/01/20 13:24:32-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# net/core/pktgen.c
# 2005/01/20 13:24:31-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# net/core/netpoll.c
# 2005/01/20 13:24:31-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# drivers/net/tg3.h
# 2005/01/20 13:24:31-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# drivers/net/tg3.c
# 2005/01/20 13:24:31-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# drivers/net/sungem.h
# 2005/01/20 13:24:31-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# drivers/net/sungem.c
# 2005/01/20 13:24:31-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# drivers/net/e1000/e1000_main.c
# 2005/01/20 13:24:31-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# drivers/net/e1000/e1000.h
# 2005/01/20 13:24:31-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# drivers/infiniband/ulp/ipoib/ipoib_ib.c
# 2005/01/20 13:24:31-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
# drivers/infiniband/ulp/ipoib/ipoib.h
# 2005/01/20 13:24:31-08:00 [EMAIL PROTECTED] +0 -0
# Exclude
#
diff -Nru a/Documentation/networking/netdevices.txt
b/Documentation/networking/netdevices.txt
--- a/Documentation/networking/netdevices.txt 2005-01-24 01:38:51 +01:00
+++ b/Documentation/networking/netdevices.txt 2005-01-24 01:38:51 +01:00
@@ -45,9 +45,10 @@
Synchronization: dev->xmit_lock spinlock.
When the driver sets NETIF_F_LLTX in dev->features this will be
called without holding xmit_lock. In this case the driver
- has to execute it's transmission routine in a completely lockless
- manner. It is recommended only for queueless devices such
- loopback and tunnels.
+ has to lock by itself when needed. It is recommended to use a try lock
+ for this and return -1 when the spin lock fails.
+ The locking there should also properly protect against
+ set_multicast_list
Context: BHs disabled
Notes: netif_queue_stopped() is guaranteed false
Return codes:
@@ -55,6 +56,8 @@
o NETDEV_TX_BUSY Cannot transmit packet, try later
Usually a bug, means queue start/stop flow control is broken in
the driver. Note: the driver must NOT put the skb in its DMA ring.
+ o NETDEV_TX_LOCKED Locking failed, please retry quickly.
+ Only valid when NETIF_F_LLTX is set.
dev->tx_timeout:
Synchronization: dev->xmit_lock spinlock.
diff -Nru a/drivers/infiniband/ulp/ipoib/ipoib.h
b/drivers/infiniband/ulp/ipoib/ipoib.h
--- a/drivers/infiniband/ulp/ipoib/ipoib.h 2005-01-24 01:38:50 +01:00
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h 2005-01-24 01:38:51 +01:00
@@ -104,10 +104,10 @@
};
/*
- * Device private locking: netdev->xmit_lock protects members used
- * in TX fast path.
- * lock protects everything else. lock nests inside of xmit_lock (ie
- * xmit_lock must be acquired first if needed).
+ * Device private locking: tx_lock protects members used in TX fast
+ * path (and we use LLTX so upper layers don't do extra locking).
+ * lock protects everything else. lock nests inside of tx_lock (ie
+ * tx_lock must be acquired first if needed).
*/
struct ipoib_dev_priv {
spinlock_t lock;
@@ -150,6 +150,7 @@
struct ipoib_buf *rx_ring;
+ spinlock_ttx_lock;
struct ipoib_buf *tx_ring;
unsigned tx_head;
unsigned tx_tail;
diff -Nru a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2005-01-24 01:38:51 +01:00
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2005-01-24 01:38:51 +01:00
@@ -247,12 +247,12 @@
dev_kfree_skb_any(tx_req->skb);
- spin_lock_irqsave(>xmit_lock, flags);
+ spin_lock_irqsave(>tx_lock, flags);
++priv->tx_tail;
Re: FATAL: Error inserting fm -- invalid module format
On Jan 21, 2005, at 09:08, Srinivas G. wrote: FATAL: Error inserting fm (/lib/modules/2.6.4-52-default/kernel/drivers/block/fm.ko): Invalid module format As I know the error message indicates that I compiled the driver under 2.6.5-7.71 kernel where as I am trying to insert the module in 2.6.4-52-default kernel. My question is: Is it possible to compile and build a .ko file with out including the version information? (i.e. I want to build a RPM file using fm.ko file which was compiled using 2.6.5-7.71 and to run the RPM file on a different kernel versions.) This message means that if you load your module it is guaranteed to cause a crash because it is the wrong version. It would be best if you could license your source code under the GPL and publish a set of small discreet patches to the stock kernel to this list. That way it would be included and maintained across API revisions for you by the community. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - 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.11-rc2] Badness in local_bh_enable at kernel/softirq.c:140
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I get this with 2.6.11-rc2 Badness in local_bh_enable at kernel/softirq.c:140 ~ [] local_bh_enable+0x60/0x80 ~ [] destroy_conntrack+0xb7/0xe0 [ip_conntrack] ~ [] sock_wfree+0x0/0x40 ~ [] __kfree_skb+0x6c/0xe0 ~ [] rtl8139_start_xmit+0x75/0x120 [8139too] ~ [] qdisc_restart+0x51/0xe0 ~ [] dev_queue_xmit+0x15a/0x1e0 ~ [] neigh_resolve_output+0xcc/0x160 ~ [] ip_finish_output2+0x8b/0x180 ~ [] ip_finish_output2+0x0/0x180 ~ [] nf_hook_slow+0x91/0xc0 ~ [] dst_output+0x0/0x40 ~ [] ip_finish_output+0x1ab/0x1c0 ~ [] ip_finish_output2+0x0/0x180 ~ [] dst_output+0x0/0x40 ~ [] dst_output+0xb/0x40 ~ [] nf_hook_slow+0x91/0xc0 ~ [] ip_push_pending_frames+0x3ce/0x440 ~ [] dst_output+0x0/0x40 ~ [] ip_send_reply+0x18a/0x1e0 ~ [] ip_nat_setup_info+0x78/0x200 [iptable_nat] ~ [] ip_nat_fn+0x5/0x1c0 [iptable_nat] ~ [] tcp_v4_send_reset+0xca/0x120 ~ [] tcp_v4_checksum_init+0x82/0x140 ~ [] tcp_v4_rcv+0x389/0x6a0 ~ [] ip_local_deliver_finish+0x0/0x120 ~ [] ip_local_deliver_finish+0x97/0x120 ~ [] nf_hook_slow+0x91/0xc0 ~ [] ip_local_deliver+0x150/0x180 ~ [] ip_local_deliver_finish+0x0/0x120 ~ [] ip_rcv_finish+0x1b0/0x220 ~ [] ip_rcv_finish+0x0/0x220 ~ [] nf_hook_slow+0x91/0xc0 ~ [] ip_rcv+0x368/0x420 ~ [] ip_rcv_finish+0x0/0x220 ~ [] netif_receive_skb+0x115/0x180 ~ [] alloc_skb+0x32/0xe0 ~ [] rtl8139_rx+0x16e/0x2e0 [8139too] ~ [] rtl8139_poll+0x34/0xc0 [8139too] ~ [] net_rx_action+0x5f/0xe0 ~ [] __do_softirq+0x7a/0xa0 ~ [] do_softirq+0x39/0x40 ~ === ~ [] do_IRQ+0x3d/0x60 ~ [] common_interrupt+0x1a/0x20 - -- Ramón Rey Vicente JID [EMAIL PROTECTED] - GPG public key id 0x9F28E377 GPG Fingerprint 0BC2 8014 2445 51E8 DE87 C888 C385 A9D3 9F28 E377 Planet AUGCyL - http://augcyl.org/planet/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9EO+w4Wp058o43cRAuJ+AJ9XcoOKoBtRT21O5R4u4uVGR6LhMACfe+/p npPvZJZFoki0MvUcu9HKQ1w= =0BBb -END PGP SIGNATURE- - 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-rc1-mm1
Hi,
On Sun, 23 Jan 2005, Karim Yaghmour wrote:
> But how does relayfs organize the namespace then? What if I have
> multiple channels per CPU, each for a different type of data, will
> all channels for the same CPU be under the same directory or will
> each type of data have its own directory with one entry per CPU?
I'd say the latter, you already do this for ltt.
> I don't have an answer to that, and I don't know that we should. Why
> not just leave it to the client to organize his data as he wishes.
> If we must assume that everyone will have at least one channel per
> CPU, then why not provide helper functions built on top of very
> basic functions instead of fixing the namespace in stone?
How should simple do you want to have these helper functions, isn't
something like relay_create(path, num_chan) simple enough?
I don't think a directory structure is that bad, as that allows to add
more control files to the relay stream and still leave the option to write
out all buffers into one file.
> > I have to modify it a little (only the if (!buffer) part is new):
> >
> > cpu = get_cpu();
> > buffer = relay_get_buffer(chan, cpu);
> > while(1) {
> > offset = local_add_return(buffer->offset, length);
> > if (likely(offset + length <= buffer->size))
> > break;
> > buffer = relay_switch_buffer(chan, buffer, offset);
> > if (!buffer) {
> > put_cpu();
> > return;
> > }
> > }
> > memcpy(buffer->data + offset, data, length);
> > put_cpu();
> >
> > This has a very short fast path and I need very good reasons to change/add
> > anything here. OTOH the slow path with relay_switch_buffer() is less
> > critical and still leaves a lot of flexibility.
>
> This is not good for any client that doesn't know beforehand the exact
> size of their data units, as in the case of LTT. If LTT has to use this
> code that means we are going to loose performance because we will need to
> fill an intermediate data structure which will only be used for relay_write().
> Instead of zero-copy, we would have an extra unnecessary copy. There has
> got to be a way for clients to directly reserve and write as they wish.
Ok, let's change it a little so it's more familiar. :)
void *relay_reserve(chan, length, cpu)
{
buffer = relay_get_buffer(chan, cpu);
while(1) {
offset = local_add_return(buffer->offset, length);
if (likely(offset + length <= buffer->size))
return buffer->data + offset;
buffer = relay_switch_buffer(chan, buffer, offset);
if (!buffer)
return NULL;
}
}
All you have to do is to put between get_cpu()/put_cpu().
The same is also possible as macro, which allows you to directly jump out
of it to the failure code and avoid one test.
> > Look closer, it's already interrupt safe, the synchronization for the
> > buffer switch is left to relay_switch_buffer().
>
> Sorry, I'm still missing something. What exactly does local_add_return()
> do? I assume this code has got to be interrupt safe? Something like:
> #define local_add_return(OFFSET, LEN) \
> do {\
> ...
> local_irq_save(); \
> OFFSET += LEN;
> local_irq_restore(); \
> ...
> } while(0);
>
> I'm assuming local_irq_XXX because we were told by quite a few people
> in the related thread to avoid atomic ops because they are more expensive
> on most CPUs than cli/sti.
That would be about the generic implementation, but it allows archs to
provide more efficient implementations in , e.g. i386 can use
xadd.
> Also how does relay_get_buffer() operate?
#define relay_get_buffer(chan, cpu) chan->buffer[cpu]
> What if I'm writing an event
> from within a system call and I'm about to switch buffers and get
> an interrupt at the if(likely(...))? Isn't relay_get_buffer() going to
> return the same pointer as the one obtained for the syscall, and aren't
> both cases now going to effect relay_switch_buffer(), one of which will
> be superfluous?
The synchronization has to be done in relay_switch_buffer(), but catching
it there is still cheaper as in the fast path.
> > This adds a conditional and is not really needed. Above shows how to make
> > it interrupt safe and if the clients wants to reuse the same buffer, leave
> > the locking to the client.
>
> Fine, but how is the client going to be able to reuse the same buffer if
> relayfs always assumes per-CPU buffer as you said above? This would be
> solved if at its core relayfs' functions worked on single channels and
> additional code provided helpers for making the SMP case very simple.
What do you mean? Why not make SMP case simple (less to get wrong)? The
client can still serialize everything with a simple spinlock.
> > That's quite a lot of code with at least 14 conditions (or 13 conditions
> > too much) and this is just
[2.6.11-rc2] kernel BUG at fs/reiserfs/journal.c:2966!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I get this with 2.6.11-rc2 kernel BUG at fs/reiserfs/journal.c:2966! invalid operand: [#1] Modules linked in: r128 ipt_state iptable_filter iptable_nat ip_conntrack ip_tables 8139too mii crc32 snd_ens1371 snd_rawmidi snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc gameport uhci_hcd via_agp floppy ide_cd cdrom CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00210203 (2.6.11-rc2) EIP is at journal_end+0x50/0xe0 eax: cf48d400 ebx: c4040e6c ecx: 0004b7fd edx: cf48d400 esi: c4040e64 edi: 0001 ebp: c8fc091c esp: c4040e54 ds: 007b es: 007b ss: 0068 Process d4x (pid: 18036, threadinfo=c404 task=c26ddaa0) Stack: c8fc091c c4040e64 c0183fdf cf48d400 0001 0002 ~ 0004b7fd 0864d53b c4040e88 c4040e88 c4040e88 c4040e88 ~ 0007 c8fc091c c0160b04 c8fc091c c8fc09bc cf48d400 3b9aca00 Call Trace: ~ [] reiserfs_dirty_inode+0x5f/0x80 ~ [] __mark_inode_dirty+0x164/0x180 ~ [] inode_setattr+0x94/0x1c0 ~ [] reiserfs_setattr+0x148/0x1c0 ~ [] current_fs_time+0x40/0x60 ~ [] notify_change+0x178/0x1b2 ~ [] do_truncate+0x33/0x60 ~ [] do_IRQ+0x3d/0x60 ~ [] sys_ftruncate64+0x74/0x100 ~ [] sys_ftruncate64+0xaf/0x100 ~ [] syscall_call+0x7/0xb Code: 00 00 00 8b 4e 10 85 c9 74 61 8b 46 04 48 85 c0 89 46 04 7e 46 b8 00 f0 ff ff 21 e0 8b 00 8b 98 a8 04 00 00 8b 46 00 39 03 74 08 <0f> 0b 96 0b f3 16 26 c0 39 de 74 15 b9 24 00 00 00 89 f2 89 d8 - -- Ramón Rey Vicente JID [EMAIL PROTECTED] - GPG public key id 0x9F28E377 GPG Fingerprint 0BC2 8014 2445 51E8 DE87 C888 C385 A9D3 9F28 E377 Planet AUGCyL - http://augcyl.org/planet/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9ENNw4Wp058o43cRAlRtAJ9uNKkEBfc1Vn+4tk9X77MfaDK3mgCeNBsG WVo4sDzFURWlNQPw2nzIuNU= =dpPN -END PGP SIGNATURE- - 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: LVM2
On Jan 20, 2005, at 16:40, Norbert van Nobelen wrote: RAID5 in software works pretty good (survived a failed disk, and recovered another failing raid in 1 month). Hardware is better since you don't have a boot partition left which is usually just present on one disk (you can mirror that yourself ofcourse). Err, you _can_ boot completely from a software RAID, it just takes a bit more work. I have an old PowerMac G4 400MHz with a Promise 20268 controller and 3 80GB drives booting from a software RAID. You just set up a 250-500MB boot partition mirrored with RAID 1 across all drives, then set up a RAID 5 swap partition and a RAID 5 LVM partition on each drive. Once LVM is configured with each remaining filesystem, install your distro (The new Debian-installer does very well) and set up Yaboot/GRUB/whatever to install a boot sector on each drive. Then set up a RAID+LVM initrd (Debian does this mostly automatically too), and reboot. This computer boots a custom 2.6.8.1 kernel, has 896MB RAM, and a 400MHz CPU, but it reads 41.5MiByte/sec from its RAID 5 partition with a 1MiByte blocksize, and has 16.8MiByte/sec over LVM over RAID 5 with the same blocksize. I've been following the discussions on 2.6 instability and "New development model" problems, but AFAICT, 2.6 has been rock stable on this box, which acts as an IPv4/IPv6 router/firewall/server. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - 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/
chvt issue
HI all I was reading vt driver and I saw /* * To have permissions to do most of the vt ioctls, we either have * to be the owner of the tty, or have CAP_SYS_TTY_CONFIG. */ perm = 0; if (current->signal->tty == tty || capable(CAP_SYS_TTY_CONFIG)) perm = 1; (lines 382-388 - drivers/char/vt_ioctl.c) After reading the comment I thinked I can change vt from one of my own to another one of mine. so I opened vc/2 and vc/3 and a pts/0 $ w 01:26:45 up 1:33, 5 users, load average: 0,84, 0,66, 0,97 USER TTYLOGIN@ IDLE JCPU PCPU WHAT alx vc/2 01:07 18:51 0.00s 0.00s -bash alx vc/3 01:25 48.00s 0.00s 0.00s -bash alx :023:55 ?xdm? 4:21 0.84s gnome-session alx pts/0 01:220.00s 0.08s 0.00s w I went to vc/3 and I did $ tty /dev/vc/3 $ chvt 2 as i expected I changed my tty to 2 after that I tryied to do the same from pts/0 and $ tty /dev/pts/0 $ chvt 2 chvt: VT_ACTIVATE: Operation not permitted $ After that I went in vc/2 and I did $ chvt 12 after that i was watching at my syslog writing messages... I tryed the same from pts/0 and $ chvt 12 Couldnt get a file descriptor referring to the console So, there are some things I couldn't get about virtual terminal ioctls and fd... please note that use chvt having CAP_SYS_TTY_CONFIG (root) works fine. Is it possible to change terminal from an unprivileged user ? THanks in advance for the time you'll spend answering me. Alessandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/13] Qsort
> On Sunday, January 23, 2005, Rafael J. Wysocki wrote:
> > On Sunday, 23 of January 2005 06:05, Jesper Juhl wrote:
> > > On Sun, 23 Jan 2005, Andi Kleen wrote:
> > Even with large data sets that are mostly unsorted shell sorts performance
> > is close to qsort, and there's an optimization that gives it O(n^(3/2))
> > runtime (IIRC),
>
> Yes, there is.
After doing a small amount of research into this, according to the abstract at
http://www.cs.princeton.edu/~rs/shell/paperF.pdf you can get O(n^(4/3))
with different increment sequences. (1, 8, 23, 77, 281 ...)
So I guess the sort function could look something like this for XFS use
(for reference only!):
void shellsort(void *array, size_t total_elems, size_t size,
int (*cmp)(const void *, const void *))
{
size_t i, j;
int k, h;
register char *a = array;
const int incs[3] = {23, 8, 1};
for (k = 0; k < 3; k++) {
for (h = incs[k], i = h; i < total_elems; i++) {
j = i;
while (j >= h && cmp(a + (j-h) * size, a + j * size) > 0) {
swap(a + j * size, a + (j-h) * size);
j -= h;
}
}
}
}
-- James Lamanna
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/13] Qsort
On Sat, Jan 22, 2005 at 08:29:30PM -0800, Matt Mackall wrote: > On Sun, Jan 23, 2005 at 03:39:34AM +0100, Andi Kleen wrote: > > c) the three-way median selection does help avoid worst-case O(n^2) > behavior, which might potentially be triggerable by users in places > like XFS where this is used XFS's needs are simple - we're just sorting dirents within a single directory block or smaller, and sorting EA lists/ACLs - all of which are small arrays, so a qsort optimised for small arrays suits XFS well. Take care not to put any arrays on the stack though, else the CONFIG_4KSTACKS punters won't be happy. 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/
Re: [linux-usb-devel] Re: usbmon, usb core, ARM
On Saturday 22 January 2005 12:12 am, Pete Zaitcev wrote: > On Thu, 20 Jan 2005 22:28:31 -0800, David Brownell <[EMAIL PROTECTED]> wrote: > > > By the way ... on the topic of usbmon rather than changing > > usbcore, is there a brief writeup of what you want this > > new version to be doing -- and how? Like, why put the > > spy hooks in that location, rather than any of the other > > choices. (Many of them would be less surprising to me!) > > The main idea was to make usbmon invisible if it's not actively monitoring. > But after thinking about your message I see that it was a misguided approach. > I'm going to add "if (usbmon_is_running(bus)) usb_mon_hook(bus, urb);" into > hot paths instead, approximately where current suggestion comments are. OK ... > I cannot figure out if you understand the nature of the problem with current > usbmon, Where "current" == "research project from a couple years ago, which doesn't even compile any more"?!? I don't think many people would, which is why I wanted to see more info ... :) > so let me restate it. Simply put, neither dev nor hcd are available > at the time urb->complete is called, Completely untrue. They are at a minimum provided through the URB itself, and giveback (which is the only place that call is made!) is passed the HCD as a parameter. Or aren't you talking about 2.6.11 code? > and this is what usbmon intercepts. > For one thing, dev is down-counted in usb_unlink_urb(). I don't see any refcounting calls in that routine. It couldn't change the refcounts, in any case ... the HCD owns the URB until giveback(), and all unlinking does is accelerate getting to that giveback(). > Adding hooks explicitly has its disadvantages. Although the giveback > path is much better, in the submit path such hook cannot inform usbmon > if the submission fails, and an additional hook is needed. Anyhow, you'll > see it all in the patch, please give me a couple of days. OK. Though I'd still like to see the usbcore hooks as a separate patch (which can be easily reviewed), with docs (and maybe an example) to help (idiots like) me see how it's supposed to work. For example, how does userspace provide a filter to say what URBs it's interested in, and what level of information to report? (Like, "only the first N bytes of data", timestamping, etc.) That is, how would a USB analogue of tcpdump be able to say "spy on what happens with that device", or "spy on all enumeration". - Dave > Greetings, > -- Pete > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] posix-timers: CPU clock support for POSIX timers
POSIX requires that when you claim _POSIX_CPUTIME and _POSIX_THREAD_CPUTIME,
not only the clock_* calls but also timer_* calls must support the thread
and process CPU time clocks. This patch provides that support, building on
my recent additions to support these clocks in the POSIX clock_* interfaces.
This patch will not work without those changes, as well as the patch fixing
the timer lock-siglock deadlock problem.
The apparent pervasive changes to posix-timers.c are simply that some
fields of struct k_itimer have changed name and moved into a union.
This was appropriate since the data structures required for the existing
real-time timer support and for the new thread/process CPU-time timers are
quite different.
The glibc patches to support CPU time clocks using the new kernel support
is in http://people.redhat.com/roland/glibc/kernel-cpuclocks.patch, and
that includes tests for the timer support (if you build glibc with NPTL).
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
--- linux-2.6/include/linux/init_task.h
+++ linux-2.6/include/linux/init_task.h
@@ -51,6 +51,7 @@
.list = LIST_HEAD_INIT(sig.shared_pending.list),\
.signal = {{0}}}, \
.posix_timers= LIST_HEAD_INIT(sig.posix_timers),\
+ .cpu_timers = INIT_CPU_TIMERS(sig.cpu_timers), \
.rlim = INIT_RLIMITS, \
}
@@ -112,8 +113,16 @@ extern struct group_info init_groups;
.proc_lock = SPIN_LOCK_UNLOCKED, \
.switch_lock= SPIN_LOCK_UNLOCKED, \
.journal_info = NULL, \
+ .cpu_timers = INIT_CPU_TIMERS(tsk.cpu_timers), \
}
+#define INIT_CPU_TIMERS(cpu_timers)\
+{ \
+ LIST_HEAD_INIT(cpu_timers[0]), \
+ LIST_HEAD_INIT(cpu_timers[1]), \
+ LIST_HEAD_INIT(cpu_timers[2]), \
+}
+
#endif
--- linux-2.6/include/linux/posix-timers.h
+++ linux-2.6/include/linux/posix-timers.h
@@ -3,8 +3,21 @@
#include
#include
+#include
-#define CPUCLOCK_PID(clock)((pid_t) ~((clock) >> 3))
+union cpu_time_count {
+ cputime_t cpu;
+ unsigned long long sched;
+};
+
+struct cpu_timer_list {
+ struct list_head entry;
+ union cpu_time_count expires, incr;
+ struct task_struct *task;
+ int firing;
+};
+
+#define CPUCLOCK_PID(clock)((pid_t) ~((clock) >> 3))
#define CPUCLOCK_PERTHREAD(clock) \
(((clock) & (clockid_t) CPUCLOCK_PERTHREAD_MASK) != 0)
#define CPUCLOCK_PID_MASK 7
@@ -30,15 +43,21 @@ struct k_itimer {
int it_overrun; /* overrun on pending signal */
int it_overrun_last;/* overrun on last delivered signal */
int it_requeue_pending; /* waiting to requeue this timer */
+#define REQUEUE_PENDING 1
int it_sigev_notify;/* notify word of sigevent struct */
int it_sigev_signo; /* signo word of sigevent struct */
sigval_t it_sigev_value;/* value word of sigevent struct */
- unsigned long it_incr; /* interval specified in jiffies */
struct task_struct *it_process; /* process to send signal to */
- struct timer_list it_timer;
struct sigqueue *sigq; /* signal queue entry. */
- struct list_head abs_timer_entry; /* clock abs_timer_list */
- struct timespec wall_to_prev; /* wall_to_monotonic used when set */
+ union {
+ struct {
+ struct timer_list timer;
+ struct list_head abs_timer_entry; /* clock
abs_timer_list */
+ struct timespec wall_to_prev; /* wall_to_monotonic
used when set */
+ unsigned long incr; /* interval in jiffies */
+ } real;
+ struct cpu_timer_list cpu;
+ } it;
};
struct k_clock_abs {
@@ -57,6 +76,7 @@ struct k_clock {
struct itimerspec * new_setting,
struct itimerspec * old_setting);
int (*timer_del) (struct k_itimer * timr);
+#define TIMER_RETRY 1
void (*timer_get) (struct k_itimer * timr,
struct itimerspec * cur_setting);
};
@@ -82,10 +102,11 @@ struct now_struct {
#define posix_bump_timer(timr, now)\
do { \
long delta, orun;
\
- delta = now.jiffies - (timr)->it_timer.expires; \
+ delta = now.jiffies - (timr)->it.real.timer.expires; \
if (delta >= 0) {
Re: [ea-in-inode 0/5] Further fixes
On Sunday 23 January 2005 23:58, Andreas Gruenbacher wrote: > > Jan 23 06:54:38 dev4-003 kernel: journal_bmap: journal block not found at > > offset 1036 on sdc1 Jan 23 06:54:38 dev4-003 kernel: Aborting journal on > > device sdc1. > > Are you using data journaling on that filesystem? Does this test pass with > the patches backed out? With an external journal? There are 12 direct and 1024 indirect blocks on a filesystem with 4k blocksize, so block 1036 should be the first double-indirect block. It may be that something is messing up the double-indirect link or one of its fields. Interesting. Could you maybe try this patch as well? Index: linux-2.6.11-rc1-mm2/fs/ext3/inode.c === --- linux-2.6.11-rc1-mm2.orig/fs/ext3/inode.c +++ linux-2.6.11-rc1-mm2/fs/ext3/inode.c @@ -2653,7 +2653,7 @@ static int ext3_do_update_inode(handle_t } else for (block = 0; block < EXT3_N_BLOCKS; block++) raw_inode->i_block[block] = ei->i_data[block]; - if (EXT3_INODE_SIZE(inode->i_sb) > EXT3_GOOD_OLD_INODE_SIZE) + if (ei->i_extra_isize) raw_inode->i_extra_isize = cpu_to_le16(ei->i_extra_isize); BUFFER_TRACE(bh, "call ext3_journal_dirty_metadata"); Thanks, -- Andreas Gruenbacher <[EMAIL PROTECTED]> SUSE Labs, SUSE LINUX PRODUCTS GMBH - 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 5/7] make ITIMER_REAL per-process
POSIX requires that setitimer, getitimer, and alarm work on a per-process
basis. Currently, Linux implements these for individual threads. This
patch fixes these semantics for the ITIMER_REAL timer (which generates
SIGALRM), making it shared by all threads in a process (thread group).
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
--- linux-2.6/fs/proc/array.c
+++ linux-2.6/fs/proc/array.c
@@ -317,6 +317,7 @@ static int do_task_stat(struct task_stru
unsigned long min_flt = 0, maj_flt = 0;
cputime_t cutime, cstime, utime, stime;
unsigned long rsslim = 0;
+ unsigned long it_real_value = 0;
struct task_struct *t;
char tcomm[sizeof(task->comm)];
@@ -372,6 +373,7 @@ static int do_task_stat(struct task_stru
utime = cputime_add(utime, task->signal->utime);
stime = cputime_add(stime, task->signal->stime);
}
+ it_real_value = task->signal->it_real_value;
}
ppid = pid_alive(task) ? task->group_leader->real_parent->tgid : 0;
read_unlock(_lock);
@@ -420,7 +422,7 @@ static int do_task_stat(struct task_stru
priority,
nice,
num_threads,
- jiffies_to_clock_t(task->it_real_value),
+ jiffies_to_clock_t(it_real_value),
start_time,
vsize,
mm ? mm->rss : 0, /* you might want to shift this left 3 */
--- linux-2.6/include/linux/init_task.h
+++ linux-2.6/include/linux/init_task.h
@@ -90,9 +90,6 @@ extern struct group_info init_groups;
.children = LIST_HEAD_INIT(tsk.children), \
.sibling= LIST_HEAD_INIT(tsk.sibling), \
.group_leader = , \
- .real_timer = { \
- .function = it_real_fn\
- }, \
.group_info = _groups, \
.cap_effective = CAP_INIT_EFF_SET, \
.cap_inheritable = CAP_INIT_INH_SET,\
--- linux-2.6/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -300,6 +300,10 @@ struct signal_struct {
/* POSIX.1b Interval Timers */
struct list_head posix_timers;
+ /* ITIMER_REAL timer for the process */
+ struct timer_list real_timer;
+ unsigned long it_real_value, it_real_incr;
+
/* job control IDs */
pid_t pgrp;
pid_t tty_old_pgrp;
@@ -604,10 +608,8 @@ struct task_struct {
int __user *clear_child_tid;/* CLONE_CHILD_CLEARTID */
unsigned long rt_priority;
- unsigned long it_real_value, it_real_incr;
cputime_t it_virt_value, it_virt_incr;
cputime_t it_prof_value, it_prof_incr;
- struct timer_list real_timer;
cputime_t utime, stime;
unsigned long nvcsw, nivcsw; /* context switch counts */
struct timespec start_time;
--- linux-2.6/kernel/exit.c
+++ linux-2.6/kernel/exit.c
@@ -802,7 +802,6 @@ fastcall NORET_TYPE void do_exit(long co
}
tsk->flags |= PF_EXITING;
- del_timer_sync(>real_timer);
if (unlikely(in_atomic()))
printk(KERN_INFO "note: %s[%d] exited with preempt_count %d\n",
@@ -812,8 +811,10 @@ fastcall NORET_TYPE void do_exit(long co
acct_update_integrals();
update_mem_hiwater();
group_dead = atomic_dec_and_test(>signal->live);
- if (group_dead)
+ if (group_dead) {
+ del_timer_sync(>signal->real_timer);
acct_process(code);
+ }
exit_mm(tsk);
exit_sem(tsk);
--- linux-2.6/kernel/fork.c
+++ linux-2.6/kernel/fork.c
@@ -743,6 +743,11 @@ static inline int copy_signal(unsigned l
init_sigpending(>shared_pending);
INIT_LIST_HEAD(>posix_timers);
+ sig->it_real_value = sig->it_real_incr = 0;
+ sig->real_timer.function = it_real_fn;
+ sig->real_timer.data = (unsigned long) tsk;
+ init_timer(>real_timer);
+
sig->tty = current->signal->tty;
sig->pgrp = process_group(current);
sig->session = current->signal->session;
@@ -873,14 +878,10 @@ static task_t *copy_process(unsigned lon
clear_tsk_thread_flag(p, TIF_SIGPENDING);
init_sigpending(>pending);
- p->it_real_value = 0;
- p->it_real_incr = 0;
p->it_virt_value = cputime_zero;
p->it_virt_incr = cputime_zero;
p->it_prof_value = cputime_zero;
p->it_prof_incr = cputime_zero;
- init_timer(>real_timer);
- p->real_timer.data = (unsigned long) p;
p->utime = cputime_zero;
p->stime = cputime_zero;
--- linux-2.6/kernel/itimer.c
+++ linux-2.6/kernel/itimer.c
@@ -14,25 +14,31 @@
#include
+static
Re: negative diskspace usage
On Sun, Jan 23, 2005 at 11:56:28PM +0100, Wichert Akkerman wrote: > > Are you still able to examine the situation? > > No, but I do have some more information. A e2fsck run on that filesystem > was just as interesting: > > /dev/md4: clean, 16/132480 files, -15514/264960 blocks > > Forcing an e2fsck revelated a few groups with incorrect block counts: > > Free blocks count wrong for group #2 (34308, counted=32306). > Free blocks count wrong for group #6 (45805, counted=32306). > Free blocks count wrong for group #8 (14741, counted=2354). > Free blocks count wrong (280474, counted=252586). > > After fixing those everything returned to normal. I did run dumpe2fs > on the filesystem, if that is interesting I can retrieve and post that. It is an interesting situation, but probably there is not enough information to find out what happened. On the other hand, if your dumpe2fs output is not too big you might as well post it. Andries - 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 6/7] make ITIMER_PROF, ITIMER_VIRTUAL per-process
POSIX requires that setitimer, getitimer, and alarm work on a per-process
basis. Currently, Linux implements these for individual threads. This
patch fixes these semantics for the ITIMER_PROF timer (which generates
SIGPROF) and the ITIMER_VIRTUAL timer (which generates SIGVTALRM), making
them shared by all threads in a process (thread group).
This patch should be applied after the one that fixes ITIMER_REAL.
The essential machinery for these timers is tied into the new posix-timers
code for process CPU clocks and timers. This patch requires the cputimers
patch and its dependencies.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
--- linux-2.6/include/linux/posix-timers.h
+++ linux-2.6/include/linux/posix-timers.h
@@ -127,5 +127,7 @@ void run_posix_cpu_timers(struct task_st
void posix_cpu_timers_exit(struct task_struct *);
void posix_cpu_timers_exit_group(struct task_struct *);
+void set_process_cpu_timer(struct task_struct *, unsigned int,
+ cputime_t *, cputime_t *);
#endif
--- linux-2.6/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -304,6 +304,10 @@ struct signal_struct {
struct timer_list real_timer;
unsigned long it_real_value, it_real_incr;
+ /* ITIMER_PROF and ITIMER_VIRTUAL timers for the process */
+ cputime_t it_prof_expires, it_virt_expires;
+ cputime_t it_prof_incr, it_virt_incr;
+
/* job control IDs */
pid_t pgrp;
pid_t tty_old_pgrp;
@@ -608,8 +612,6 @@ struct task_struct {
int __user *clear_child_tid;/* CLONE_CHILD_CLEARTID */
unsigned long rt_priority;
- cputime_t it_virt_value, it_virt_incr;
- cputime_t it_prof_value, it_prof_incr;
cputime_t utime, stime;
unsigned long nvcsw, nivcsw; /* context switch counts */
struct timespec start_time;
--- linux-2.6/include/linux/signal.h
+++ linux-2.6/include/linux/signal.h
@@ -212,6 +212,7 @@ static inline void init_sigpending(struc
}
extern int group_send_sig_info(int sig, struct siginfo *info, struct
task_struct *p);
+extern int __group_send_sig_info(int, struct siginfo *, struct task_struct *);
extern long do_sigpending(void __user *, unsigned long);
extern int sigprocmask(int, sigset_t *, sigset_t *);
--- linux-2.6/kernel/exit.c
+++ linux-2.6/kernel/exit.c
@@ -757,8 +757,6 @@ static void exit_notify(struct task_stru
* Clear these here so that update_process_times() won't try to deliver
* itimer, profile or rlimit signals to this task while it is in late
exit.
*/
- tsk->it_virt_value = cputime_zero;
- tsk->it_prof_value = cputime_zero;
tsk->it_virt_expires = cputime_zero;
tsk->it_prof_expires = cputime_zero;
tsk->it_sched_expires = 0;
--- linux-2.6/kernel/fork.c
+++ linux-2.6/kernel/fork.c
@@ -748,6 +748,11 @@ static inline int copy_signal(unsigned l
sig->real_timer.data = (unsigned long) tsk;
init_timer(>real_timer);
+ sig->it_virt_expires = cputime_zero;
+ sig->it_virt_incr = cputime_zero;
+ sig->it_prof_expires = cputime_zero;
+ sig->it_prof_incr = cputime_zero;
+
sig->tty = current->signal->tty;
sig->pgrp = process_group(current);
sig->session = current->signal->session;
@@ -878,11 +883,6 @@ static task_t *copy_process(unsigned lon
clear_tsk_thread_flag(p, TIF_SIGPENDING);
init_sigpending(>pending);
- p->it_virt_value = cputime_zero;
- p->it_virt_incr = cputime_zero;
- p->it_prof_value = cputime_zero;
- p->it_prof_incr = cputime_zero;
-
p->utime = cputime_zero;
p->stime = cputime_zero;
p->sched_time = 0;
@@ -1031,7 +1031,11 @@ static task_t *copy_process(unsigned lon
set_tsk_thread_flag(p, TIF_SIGPENDING);
}
- if (!list_empty(>signal->cpu_timers[0]) ||
+ if (!cputime_eq(current->signal->it_virt_expires,
+ cputime_zero) ||
+ !cputime_eq(current->signal->it_prof_expires,
+ cputime_zero) ||
+ !list_empty(>signal->cpu_timers[0]) ||
!list_empty(>signal->cpu_timers[1]) ||
!list_empty(>signal->cpu_timers[2])) {
/*
--- linux-2.6/kernel/itimer.c
+++ linux-2.6/kernel/itimer.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
@@ -29,24 +30,67 @@ static unsigned long it_real_value(struc
int do_getitimer(int which, struct itimerval *value)
{
+ struct task_struct *tsk = current;
unsigned long interval, val;
+ cputime_t cinterval, cval;
switch (which) {
case ITIMER_REAL:
- spin_lock_irq(>sighand->siglock);
- interval = current->signal->it_real_incr;
- val = it_real_value(current->signal);
- spin_unlock_irq(>sighand->siglock);
+
[PATCH 7/7] make RLIMIT_CPU/SIGXCPU per-process
POSIX requires that the RLIMIT_CPU resource limit that generates SIGXCPU be
counted on a per-process basis. Currently, Linux implements this for
individual threads. This patch fixes the semantics to conform with POSIX.
The essential machinery for the process CPU limit is is tied into the new
posix-timers code for process CPU clocks and timers. This patch requires
the cputimers patch and its dependencies. This patch is also meant to be
applied after the setitimer fixes for CPU timers.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
--- linux-2.6/kernel/fork.c
+++ linux-2.6/kernel/fork.c
@@ -768,6 +768,15 @@ static inline int copy_signal(unsigned l
memcpy(sig->rlim, current->signal->rlim, sizeof sig->rlim);
task_unlock(current->group_leader);
+ if (sig->rlim[RLIMIT_CPU].rlim_cur != RLIM_INFINITY) {
+ /*
+* New sole thread in the process gets an expiry time
+* of the whole CPU time limit.
+*/
+ tsk->it_prof_expires =
+ secs_to_cputime(sig->rlim[RLIMIT_CPU].rlim_cur);
+ }
+
return 0;
}
@@ -1032,6 +1041,7 @@ static task_t *copy_process(unsigned lon
cputime_zero) ||
!cputime_eq(current->signal->it_prof_expires,
cputime_zero) ||
+ current->signal->rlim[RLIMIT_CPU].rlim_cur != RLIM_INFINITY
||
!list_empty(>signal->cpu_timers[0]) ||
!list_empty(>signal->cpu_timers[1]) ||
!list_empty(>signal->cpu_timers[2])) {
--- linux-2.6/kernel/posix-cpu-timers.c
+++ linux-2.6/kernel/posix-cpu-timers.c
@@ -549,6 +549,7 @@ static void arm_timer(struct k_itimer *t
struct list_head *head, *listpos;
struct cpu_timer_list *const nt = >it.cpu;
struct cpu_timer_list *next;
+ unsigned long i;
head = (CPUCLOCK_PERTHREAD(timer->it_clock) ?
p->cpu_timers : p->signal->cpu_timers);
@@ -619,6 +620,10 @@ static void arm_timer(struct k_itimer *t
cputime_lt(p->signal->it_prof_expires,
timer->it.cpu.expires.cpu))
break;
+ i = p->signal->rlim[RLIMIT_CPU].rlim_cur;
+ if (i != RLIM_INFINITY &&
+ i <=
cputime_to_secs(timer->it.cpu.expires.cpu))
+ break;
goto rebalance;
case CPUCLOCK_SCHED:
rebalance:
@@ -990,6 +995,7 @@ static void check_process_timers(struct
*/
if (list_empty([CPUCLOCK_PROF]) &&
cputime_eq(sig->it_prof_expires, cputime_zero) &&
+ sig->rlim[RLIMIT_CPU].rlim_cur == RLIM_INFINITY &&
list_empty([CPUCLOCK_VIRT]) &&
cputime_eq(sig->it_virt_expires, cputime_zero) &&
list_empty([CPUCLOCK_SCHED]))
@@ -1086,6 +1092,33 @@ static void check_process_timers(struct
virt_expires = sig->it_virt_expires;
}
}
+ if (sig->rlim[RLIMIT_CPU].rlim_cur != RLIM_INFINITY) {
+ unsigned long psecs = cputime_to_secs(ptime);
+ cputime_t x;
+ if (psecs >= sig->rlim[RLIMIT_CPU].rlim_max) {
+ /*
+* At the hard limit, we just die.
+* No need to calculate anything else now.
+*/
+ __group_send_sig_info(SIGKILL, SEND_SIG_PRIV, tsk);
+ return;
+ }
+ if (psecs >= sig->rlim[RLIMIT_CPU].rlim_cur) {
+ /*
+* At the soft limit, send a SIGXCPU every second.
+*/
+ __group_send_sig_info(SIGXCPU, SEND_SIG_PRIV, tsk);
+ if (sig->rlim[RLIMIT_CPU].rlim_cur
+ < sig->rlim[RLIMIT_CPU].rlim_max) {
+ sig->rlim[RLIMIT_CPU].rlim_cur++;
+ }
+ }
+ x = secs_to_cputime(sig->rlim[RLIMIT_CPU].rlim_cur);
+ if (cputime_eq(prof_expires, cputime_zero) ||
+ cputime_lt(x, prof_expires)) {
+ prof_expires = x;
+ }
+ }
if (!cputime_eq(prof_expires, cputime_zero) ||
!cputime_eq(virt_expires, cputime_zero) ||
@@ -1275,6 +1308,9 @@ void run_posix_cpu_timers(struct task_st
/*
* Set one of the process-wide special case CPU timers.
* The tasklist_lock and tsk->sighand->siglock must be held by the caller.
+ * The oldval argument is null for the RLIMIT_CPU timer, where *newval is
+ * absolute; non-null for ITIMER_*, where *newval is relative and we update
+ * it to be
[PATCH 2/7] posix-timers: high-resolution CPU clocks for POSIX clock_* syscalls
This patch provides support for thread and process CPU time clocks in
the POSIX clock interface. Both the existing utime and utime+stime
information (already available via getrusage et al) can be used, as well
as a new (potentially) more precise and accurate clock (which cannot
distinguish user from system time). The clock used is that provided by
the `sched_clock' function already used internally by the scheduler.
This gives a way for platforms to provide the highest-resolution CPU
time tracking that is available cheaply, and some already do so (such as
x86 using TSC). Because this clock is already sampled internally by the
scheduler, this new tracking adds only the tiniest new overhead to
accomplish the bookkeeping.
Some notes:
This allows per-thread clocks to be accessed only by other threads in
the same process. The only POSIX calls that access these are defined
only for in-process use, and having this check is necessary for the
userland implementations of the POSIX clock functions to robustly refuse
stale clockid_t's in the face of potential PID reuse.
This makes no constraint on who can see whose per-process clocks. This
information is already available for the VIRT and PROF (i.e. utime and
stime) information via /proc. I am open to suggestions on if/how
security constraints on who can see whose clocks should be imposed.
The SCHED clock information is now available only via clock_* syscalls.
This means that per-thread information is not available outside the process.
Perhaps /proc should show sched_time as well? This would let ps et al
show this more-accurate information.
When this code is merged, it will be supported in glibc.
I have written the support and added some test programs for glibc,
which are what I mainly used to test the new kernel code.
You can get those here:
http://people.redhat.com/roland/glibc/kernel-cpuclocks.patch
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
--- linux-2.6/include/linux/posix-timers.h
+++ linux-2.6/include/linux/posix-timers.h
@@ -4,6 +4,23 @@
#include
#include
+#define CPUCLOCK_PID(clock)((pid_t) ~((clock) >> 3))
+#define CPUCLOCK_PERTHREAD(clock) \
+ (((clock) & (clockid_t) CPUCLOCK_PERTHREAD_MASK) != 0)
+#define CPUCLOCK_PID_MASK 7
+#define CPUCLOCK_PERTHREAD_MASK4
+#define CPUCLOCK_WHICH(clock) ((clock) & (clockid_t) CPUCLOCK_CLOCK_MASK)
+#define CPUCLOCK_CLOCK_MASK3
+#define CPUCLOCK_PROF 0
+#define CPUCLOCK_VIRT 1
+#define CPUCLOCK_SCHED 2
+#define CPUCLOCK_MAX 3
+
+#define MAKE_PROCESS_CPUCLOCK(pid, clock) \
+ ((~(clockid_t) (pid) << 3) | (clockid_t) (clock))
+#define MAKE_THREAD_CPUCLOCK(tid, clock) \
+ MAKE_PROCESS_CPUCLOCK((tid), (clock) | CPUCLOCK_PERTHREAD_MASK)
+
/* POSIX.1b interval timer structure. */
struct k_itimer {
struct list_head list; /* free/ allocate list */
@@ -72,5 +89,18 @@ struct now_struct {
(timr)->it_overrun += orun; \
}
\
}while (0)
-#endif
+int posix_cpu_clock_getres(clockid_t which_clock, struct timespec *);
+int posix_cpu_clock_get(clockid_t which_clock, struct timespec *);
+int posix_cpu_clock_set(clockid_t which_clock, const struct timespec *tp);
+int posix_cpu_timer_create(struct k_itimer *);
+int posix_cpu_nsleep(clockid_t, int, struct timespec *);
+#define posix_cpu_timer_create do_posix_clock_notimer_create
+#define posix_cpu_nsleep do_posix_clock_nonanosleep
+int posix_cpu_timer_set(struct k_itimer *, int,
+ struct itimerspec *, struct itimerspec *);
+int posix_cpu_timer_del(struct k_itimer *);
+void posix_cpu_timer_get(struct k_itimer *, struct itimerspec *);
+
+
+#endif
--- linux-2.6/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -320,6 +320,14 @@ struct signal_struct {
unsigned long min_flt, maj_flt, cmin_flt, cmaj_flt;
/*
+* Cumulative ns of scheduled CPU time for dead threads in the
+* group, not including a zombie group leader. (This only differs
+* from jiffies_to_ns(utime + stime) if sched_clock uses something
+* other than jiffies.)
+*/
+ unsigned long long sched_time;
+
+ /*
* We don't bother to synchronize most readers of this at all,
* because there is no reader checking a limit that actually needs
* to get both rlim_cur and rlim_max atomically, and either one
@@ -540,6 +548,7 @@ struct task_struct {
unsigned long sleep_avg;
unsigned long long timestamp, last_ran;
+ unsigned long long sched_time; /* sched_clock time spent running */
int activated;
unsigned long policy;
@@ -749,6 +758,7 @@ static inline int set_cpus_allowed(task_
#endif
extern unsigned long long sched_clock(void);
+extern unsigned long long current_sched_time(const task_t *current_task);
/* sched_exec
[PATCH 3/7] posix-timers: fix posix-timers signals lock order
The posix-timers code establishes the locking order that k_itimer locks are
outside siglocks. However, when the signal code calls back into the
posix-timers code to reload a timer after its signal is dequeued, it holds
a siglock while calling do_schedule_next_timer, which gets a timer lock.
I'm not sure there is any deadlock scenario possible using the real-time
POSIX timers, because of the intricate arrangement of timer firing and
resetting synchronization. But with the new CPU timers code, this deadlock
pops up right away. Dropping the siglock here certainly doesn't hurt in
the real-time timer cases, and it really seems like the right thing here to
keep the locking details in the interface between signals and posix-timers
code comprehensible.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
--- linux-2.6/kernel/signal.c
+++ linux-2.6/kernel/signal.c
@@ -564,7 +564,15 @@ int dequeue_signal(struct task_struct *t
if ( signr &&
((info->si_code & __SI_MASK) == __SI_TIMER) &&
info->si_sys_private){
+ /*
+* Release the siglock to ensure proper locking order
+* of timer locks outside of siglocks. Note, we leave
+* irqs disabled here, since the posix-timers code is
+* about to disable them again anyway.
+*/
+ spin_unlock(>sighand->siglock);
do_schedule_next_timer(info);
+ spin_lock(>sighand->siglock);
}
return signr;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] posix-timers: tidy up clock interfaces and consolidate dispatch logic
This patch cleans up the posix-timers interfaces for defining clocks, and
the calls to them. It fixes some sloppy types, adds a clockid_t parameter
to the calls that lacked it, and adds a function pointer that can be used
for clock_getres. It further cleans up the posix-timers.c code using the
k_clock function pointers or default functions when no hooks are supplied,
consolidating repeated code into shared inline functions or macros.
This paves the way for adding the CPU clock hooks.
The mmtimer.c changes are untested, but obviously can't be wrong.
There aren't any other struct k_clock definitions in the tree, but any
others would need to be updated for the function signature changes.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
--- linux-2.6/drivers/char/mmtimer.c
+++ linux-2.6/drivers/char/mmtimer.c
@@ -378,7 +378,7 @@ static int sgi_clock_period;
static struct timespec sgi_clock_offset;
static int sgi_clock_period;
-static int sgi_clock_get(struct timespec *tp)
+static int sgi_clock_get(clockid_t clockid, struct timespec *tp)
{
u64 nsec;
@@ -389,7 +389,7 @@ static int sgi_clock_get(struct timespec
return 0;
};
-static int sgi_clock_set(struct timespec *tp)
+static int sgi_clock_set(clockid_t clockid, struct timespec *tp)
{
u64 nsec;
--- linux-2.6/include/linux/posix-timers.h
+++ linux-2.6/include/linux/posix-timers.h
@@ -30,12 +30,12 @@ struct k_clock_abs {
};
struct k_clock {
int res;/* in nano seconds */
+ int (*clock_getres) (clockid_t which_clock, struct timespec *tp);
struct k_clock_abs *abs_struct;
- int (*clock_set) (struct timespec * tp);
- int (*clock_get) (struct timespec * tp);
+ int (*clock_set) (clockid_t which_clock, struct timespec * tp);
+ int (*clock_get) (clockid_t which_clock, struct timespec * tp);
int (*timer_create) (struct k_itimer *timer);
- int (*nsleep) (int which_clock, int flags,
- struct timespec * t);
+ int (*nsleep) (clockid_t which_clock, int flags, struct timespec *);
int (*timer_set) (struct k_itimer * timr, int flags,
struct itimerspec * new_setting,
struct itimerspec * old_setting);
@@ -44,12 +44,12 @@ struct k_clock {
struct itimerspec * cur_setting);
};
-void register_posix_clock(int clock_id, struct k_clock *new_clock);
+void register_posix_clock(clockid_t clock_id, struct k_clock *new_clock);
/* Error handlers for timer_create, nanosleep and settime */
int do_posix_clock_notimer_create(struct k_itimer *timer);
-int do_posix_clock_nonanosleep(int which_clock, int flags, struct timespec *
t);
-int do_posix_clock_nosettime(struct timespec *tp);
+int do_posix_clock_nonanosleep(clockid_t, int flags, struct timespec *);
+int do_posix_clock_nosettime(clockid_t, struct timespec *tp);
/* function to call to trigger timer event */
int posix_timer_event(struct k_itimer *timr, int si_private);
--- linux-2.6/kernel/posix-timers.c
+++ linux-2.6/kernel/posix-timers.c
@@ -173,22 +173,12 @@ static struct k_clock posix_clocks[MAX_C
static struct k_clock_abs abs_list = {.list = LIST_HEAD_INIT(abs_list.list),
.lock = SPIN_LOCK_UNLOCKED};
-#define if_clock_do(clock_fun,alt_fun,parms) \
- (!clock_fun) ? alt_fun parms : clock_fun parms
-
-#define p_timer_get(clock,a,b) \
- if_clock_do((clock)->timer_get,do_timer_gettime, (a,b))
-
-#define p_nsleep(clock,a,b,c) \
- if_clock_do((clock)->nsleep, do_nsleep, (a,b,c))
-
-#define p_timer_del(clock,a) \
- if_clock_do((clock)->timer_del, do_timer_delete, (a))
-
-static int do_posix_gettime(struct k_clock *clock, struct timespec *tp);
+static void posix_timer_fn(unsigned long);
static u64 do_posix_clock_monotonic_gettime_parts(
struct timespec *tp, struct timespec *mo);
int do_posix_clock_monotonic_gettime(struct timespec *tp);
+static int do_posix_clock_monotonic_get(clockid_t, struct timespec *tp);
+
static struct k_itimer *lock_timer(timer_t timer_id, unsigned long *flags);
static inline void unlock_timer(struct k_itimer *timr, unsigned long flags)
@@ -197,6 +187,109 @@ static inline void unlock_timer(struct k
}
/*
+ * Define this to initialize every k_clock function table so all its
+ * function pointers are non-null, and always do indirect calls through the
+ * table. Leave it undefined to instead leave null function pointers and
+ * decide at the call sites between a direct call (maybe inlined) to the
+ * default function and an indirect call through the table when it's filled
+ * in. Which style is preferable is whichever performs better in the
+ * common case of using the default functions.
+ *
+#define CLOCK_DISPATCH_DIRECT
+ */
+
+#ifdef CLOCK_DISPATCH_DIRECT
+#define CLOCK_DISPATCH(clock, call, arglist) \
+ ((*posix_clocks[clock].call) arglist)
+#define
Re: [2.6 patch] security/seclvl.c: make some code static
* Adrian Bunk ([EMAIL PROTECTED]) wrote: > This patch makes some needlessly global code static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> ACK, I'll push this up if Andrew doesn't grab it. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
Jack O'Quin wrote: Looked at this way, there really is no question. The new scheduler prototypes are falling short significantly. Could this be due to their lack of priority distinctions between realtime threads? Maybe. I can't say for sure. I'll be interested to see what happens when Con is ready for me to try his new priority-based SCHED_ISO prototype. There are two things that the SCHED_ISO you tried is not that SCHED_FIFO is - As you mentioned there is no priority support, and it is RR, not FIFO. I am not sure whether it is one and or the other responsible. Both can be added to SCHED_ISO. I haven't looked at jackd code but it should be trivial to change SCHED_FIFO to SCHED_RR to see if RR with priority support is enough or not. Second the patch I sent you is fine for testing; I was hoping you would try it. What you can't do with it is spawn lots of userspace apps safely SCHED_ISO with it - it will crash, but it not take down your hard disk. I've had significantly better results with that patch so far. Then we cn take it from there. Cheers, Con signature.asc Description: OpenPGP digital signature
Re: [ea-in-inode 0/5] Further fixes
Hello, On Sunday 23 January 2005 23:09, Andrew Tridgell wrote: > Andreas, > > > Tridge, can you beat the code some more? > > > > Andrew has the five fixes in 2.6.11-rc1-mm2. > > It seemed to pass dbench runs OK, but then I started simultaneously > running dbench and nbench on two different disks (I have a new test > machine with more disks available). I am getting failures like this: > > Jan 23 06:54:38 dev4-003 kernel: journal_bmap: journal block not found at > offset 1036 on sdc1 Jan 23 06:54:38 dev4-003 kernel: Aborting journal on > device sdc1. Are you using data journaling on that filesystem? Does this test pass with the patches backed out? With an external journal? Thanks, -- Andreas Gruenbacher <[EMAIL PROTECTED]> SUSE Labs, SUSE LINUX PRODUCTS GMBH - 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: negative diskspace usage
Previously Andries Brouwer wrote: > I assume this was produced by statfs or statfs64 or so. statfs64 indeed. > Are you still able to examine the situation? No, but I do have some more information. A e2fsck run on that filesystem was just as interesting: /dev/md4: clean, 16/132480 files, -15514/264960 blocks Forcing an e2fsck revelated a few groups with incorrect block counts: Free blocks count wrong for group #2 (34308, counted=32306). Free blocks count wrong for group #6 (45805, counted=32306). Free blocks count wrong for group #8 (14741, counted=2354). Free blocks count wrong (280474, counted=252586). After fixing those everything returned to normal. I did run dumpe2fs on the filesystem, if that is interesting I can retrieve and post that. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - 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-rc2 complains badly aboud badness in local_bh_enable
Hoi, On Sun, Jan 23, 2005 at 03:57:56PM +0100, Marcel Holtmann wrote: > > -rc1 worked fine here. -rc2 complains a lot: > > > > Jan 23 12:59:50 amd kernel: Badness in local_bh_enable at > > kernel/softirq.c:140 [snip] > the problem is the PPP code (not Bluetooth btw.) like others reported so > far. I also see the same problem with the external MadWiFi driver. I'm seeing a similar problem on my machine - one that does not know what ppp is. Main suspect is the network bridging code in combination with iptables; the first lines of the message: Jan 23 07:50:56 spaans kernel: [local_bh_enable+42/109] local_bh_enable+0x2a/0x6d Jan 23 07:50:56 spaans kernel: [pg0+97971/1068110848] ipt_do_table+0x2db/0x310 [ip_tables] Jan 23 07:50:56 spaans kernel: [pg0+942403693/1068110848] ipt_local_out_hook+0x51/0x58 [iptable_filter] Jan 23 07:50:56 spaans kernel: [nf_iterate+64/137] nf_iterate+0x40/0x89 Jan 23 07:50:56 spaans kernel: [pg0+979631787/1068110848] br_nf_local_out_finish+0x0/0x77 [bridge] (Btw, this kernel is enhanced with hostap and swsusp2 support, if needed I can compile a vanilla -rc2) Groet, -- Jasper Spaans http://jsp.vs19.net/ 23:34:43 up 10203 days, 15:21, 0 users, load average: 6.00 6.06 6.20 signature.asc Description: Digital signature
Re: Kernel 2.6.11-rc1/2 goes Postal on LTP
Bryce Harrington wrote: On Fri, 21 Jan 2005, Chris Wright wrote: * Bryce Harrington ([EMAIL PROTECTED]) wrote: Well, I'm not having much luck. strace isn't installed on the system (and is giving errors when trying to compile it). Also, the ssh session (and sshd) quits whenever I try running the following growfiles command manually, so I'm having trouble replicating the kernel panic manually. Sounds very much like oom killer gone nuts. # growfiles -W gf14 -b -e 1 -u -i 0 -L 20 -w -l -C 1 -T 10 glseek19 glseek19.2 Anyway, if anyone wants to investigate this further, I can provide access to the machine (email me). Otherwise, I'm probably just going to wait for -rc2 and see if the problem's still there. Wait no longer, it's here ;-) Hmm, still the kernel is going nutso. LTP and everything else on the system is getting killed, including the test manager process. Below's a bit more info scraped from the console. This is from a run on RH 9.0. It looks like LTP got through 722 of its 2270 tests before the kernel goes postal on it. This time it got through all the growfile commands before it died (see bottom of this post), however it looks like the same growfile cmd I reported earlier is the one causing the problem. When I run: mkfifo gffifo18; strace growfiles -b -W gf13 -e 1 -u -i 0 -L 30 -I r -r 1-4096 gffifo18 &> /tmp/growfiles_strace_log.txt The following happens: * I get this strace log: http://developer.osdl.org/bryce/growfiles_strace_log.txt * The ssh session dies and returns to login prompt * A bunch of stuff similar to below is spewed to console Bryce Console === ...snip... Memory: 905212k/917504k available (2211k kernel code, 11840k reserved, 871k data, 192k init, 0k highmem) ...snip... Yes, about the same for me on P4-UP with 1 GB RAM (home PC :). No X running, just console and some daemons. -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ea-in-inode 0/5] Further fixes
Andreas, > Tridge, can you beat the code some more? > > Andrew has the five fixes in 2.6.11-rc1-mm2. It seemed to pass dbench runs OK, but then I started simultaneously running dbench and nbench on two different disks (I have a new test machine with more disks available). I am getting failures like this: Jan 23 06:54:38 dev4-003 kernel: journal_bmap: journal block not found at offset 1036 on sdc1 Jan 23 06:54:38 dev4-003 kernel: Aborting journal on device sdc1. Jan 23 13:19:43 dev4-003 kernel: journal_bmap: journal block not found at offset 1036 on sdd1 Jan 23 13:19:43 dev4-003 kernel: Aborting journal on device sdd1. Jan 23 13:19:43 dev4-003 kernel: EXT3-fs error (device sdd1) in start_transaction: Readonly filesystem The first failure was on the disk I am using for nbench (sdc). The second is during a later run on the disk I am using the dbench (sdd). I rebooted between the runs. It's interesting that its failing at exactly the same offset both times. Is there anything magic about offset 1036? The new test machine is a 4 way PIII, with 4G ram, and 4 36G SCSI disks. The test machine I have been using previously was a 2 way (+hyperthreaded) Xeon. I'll see if I can reproduce the problem with just dbench or just nbench. Cheers, Tridge - 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: System beeper - no sound from mobo's own speaker
Stephen Kitchener wrote: On Sunday 23 Jan 2005 19:50, Sergey Vlasov wrote: Does "modprobe pcspkr" help? In 2.6.x kernels the PC speaker support can be built as a loadable module; probably the startup scripts do not load it automatically. You know - I've just found that and yes it does help on one system, so I'm 50% better off - just need to find out where to put the command so that it loads it on startup...modules.conf would be it I guess. Put it on /etc/modprobe.preload -- Anssi Hannula - 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: Trying to fix radeonfb suspending on IBM Thinkpad T41
Update: I compiled a kernel with the radeonfb-massive-update-of-pm- code.patch. Now I can successfully resume from acpi S3 again. The power drain issue remains, it still uses about 5W in the suspend state. -Volker - 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: gcc randomly crashes on my PowerBook with recent kernels...
On Sun, Jan 16, 2005 at 01:34:42AM +0100, René Rebe wrote: > On 16. Jan 2005, at 1:07 Uhr, David Eger wrote: > > >>BenH mentioned PREEMPTION and ReiserFS (I use) might not > >>play that well - at least not on PowerPC. > > > >Interesting. I do have Pre-emption on (and I have Reiser compiled, > >but not in use). Sounds like time to kill it. > > Could you reply if you have some recompiled kernel results? Recompiling my kernel without PREEMPT seems to have fixed my problem... I haven't had a gcc crash badly since... -dte - 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/
sleeping function called from invalid context at mm/slab.c:2085
Hi, while suspending and resuming 2.6.11-rc2 i see the follwing: 1467 Jan 23 23:15:59 Debug: sleeping function called from invalid context at mm/slab.c:2085 1468 Jan 23 23:15:59 in_atomic():0, irqs_disabled():1 1469 Jan 23 23:15:59 [] __might_sleep+0xa6/0xb0 1470 Jan 23 23:15:59 [] kmem_cache_alloc+0x6d/0x70 1471 Jan 23 23:15:59 [] acpi_pci_link_set+0x7d/0x269 1472 Jan 23 23:15:59 [] acpi_pci_link_resume+0x48/0x86 1473 Jan 23 23:15:59 [] irqrouter_resume+0x45/0x70 1474 Jan 23 23:15:59 [] irqrouter_resume+0x0/0x70 1475 Jan 23 23:15:59 [] sysdev_resume+0x103/0x108 1476 Jan 23 23:15:59 [] device_power_up+0x5/0xa 1477 Jan 23 23:15:59 [] suspend_enter+0x36/0x50 1478 Jan 23 23:15:59 [] enter_state+0x59/0xa0 1479 Jan 23 23:15:59 [] state_store+0xa0/0xa8 1480 Jan 23 23:15:59 [] subsys_attr_store+0x3a/0x40 1481 Jan 23 23:15:59 [] flush_write_buffer+0x3e/0x50 1482 Jan 23 23:15:59 [] sysfs_write_file+0x93/0xb0 1483 Jan 23 23:15:59 [] vfs_write+0xc8/0x170 1484 Jan 23 23:15:59 [] filp_close+0x59/0x90 1485 Jan 23 23:15:59 [] sys_write+0x51/0x80 1486 Jan 23 23:15:59 [] syscall_call+0x7/0xb Regards-- mfg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/13] Qsort
On Sat, Jan 22, 2005 at 01:00:24PM -0800, vlobanov wrote:
> #define SWAP(a, b, size) \
> do { \
> register size_t __size = (size);\
> register char * __a = (a), * __b = (b); \
> do {\
> *__a ^= *__b; \
> *__b ^= *__a; \
> *__a ^= *__b; \
> __a++; \
> __b++; \
> } while ((--__size) > 0); \
> } while (0)
>
> What do you think? :)
I think you'll confuse the compiler and get worse results.
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/
Re: Linux 2.6.11-rc2
Hello On Saturday 22 January 2005 03.13, Linus Torvalds wrote: > Ok, trying to calm things down again for a 2.6.11 release. > > Tons of small cleanups, annotations and fixes here. Driver updates, > cpufreq, ppc, parisc, arm.. Pls check that I got it all. > > Linus > It doesn't compile here, here's the error: CC net/sched/sch_generic.o net/sched/sch_generic.c: In function `qdisc_restart': net/sched/sch_generic.c:128: error: label `requeue' used but not defined make[2]: *** [net/sched/sch_generic.o] Error 1 make[1]: *** [net/sched] Error 2 make: *** [net] Error 2 >From .config: CONFIG_NET_KEY=m CONFIG_IP_MULTICAST=y CONFIG_NET_IPIP=m CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=y CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_IPCOMP=m CONFIG_IPV6_TUNNEL=m CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_PHYSDEV=m CONFIG_IP_NF_MATCH_SCTP=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AHESP=m CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_IP_SCTP=m CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y CONFIG_NET_PKTGEN=m CONFIG_NET_POLL_CONTROLLER=y CONFIG_NET_ETHERNET=y CONFIG_NET_TULIP=y - 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 0/8] core-small: Introduce CONFIG_CORE_SMALL from -tiny
Matt Mackall <[EMAIL PROTECTED]> wrote: > > > I wish it didn't have "core" in the name. A little misleading. > > Well I've got another set called NET_SMALL. BASE? BASE works, I guess. > > #define PID_MAX_DEFAULT (CONFIG_CORE_SMALL ? 0x1000 : 0x8000) > > #define UIDHASH_BITS (CONFIG_CORE_SMALL ? 3 : 8) > > #define FUTEX_HASHBITS (CONFIG_CORE_SMALL ? 4 : 8) > > etc. > > Hmm. I think we'd want a hidden config variable for this and I'm not > sure how well the config language allows setting an int from a bool. config AKPM_BOOL bool "akpm" config AKPM_INT int default 1 if AKPM_BOOL default 0 if !AKPM_BOOL seems to do everything which it should. > And then it would need another name. On the whole, seems more complex > than what I've done. No, it's quite simple and avoids lots of ifdeffing. - 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: DVD burning still have problems
On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann <[EMAIL PROTECTED]> wrote: > Hi, > > have you checked, that cdrecord is not suid root, and growisofs/dvd+rw-tools > is? > > I had some probs, solved with a simple chmod +s growisofs :) Lucky you. Burning as root here, cdrecord not suid. Tried also burning with a +s growisofs, but... 794034176/4572807168 (17.4%) @2.4x, remaining 18:47 805339136/4572807168 (17.6%) @2.4x, remaining 18:42 :-[ [EMAIL PROTECTED] failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error builtin_dd: 396976*2KB out @ average 2.4x1385KBps :-( write failed: Input/output error /dev/hdc: flushing cache /dev/hdc: stopping de-icing /dev/hdc: writing lead-out > Glück Auf > Volker --alessandro "And every dream, every, is just a dream after all" (Heather Nova, "Paper Cup") - 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]sched: Isochronous class v2 for unprivileged soft rt scheduling
Ingo Molnar <[EMAIL PROTECTED]> writes: > thanks for the testing. The important result is that nice--20 > performance is roughly the same as SCHED_ISO. This somewhat > reduces the urgency of the introduction of SCHED_ISO. Doing more runs and a more thorough analysis has driven me to a different conclusion. The important result is that *neither* nice-20 *nor* SCHED_ISO work properly in their current forms. For further comparison, I booted an old 2.4.19 kernel with Andrew Morton's low-latency patches and ran the same test SCHED_FIFO, with and without background compiles. The results were roughly the same as SCHED_FIFO on 2.6.11-rc1... http://www.joq.us/jack/benchmarks/2.4ll-fifo http://www.joq.us/jack/benchmarks/2.4ll-fifo+compile In addition, I extracted some across the board information by grepping for key results. Looking at these numbers in aggregate paints a pretty convincing picture that neither of the new scheduler prototypes are performing adequately compared to SCHED_FIFO on either 2.4ll or 2.6. http://www.joq.us/jack/benchmarks/cycle_max.log http://www.joq.us/jack/benchmarks/delay_max.log http://www.joq.us/jack/benchmarks/xrun_count.log Looking at delay_max broken down by directory is particularly striking. Below, I grouped the values by scheduling class to show the striking differences. These kinds of worst-case numbers are what realtime applications designers are generally most interested in... = SCHED_FIFO == ...benchmarks/2.4ll-fifo... Delay Maximum . . . . . . . . : 823 usecs Delay Maximum . . . . . . . . : 303 usecs ...benchmarks/2.4ll-fifo+compile... Delay Maximum . . . . . . . . : 926 usecs Delay Maximum . . . . . . . . : 663 usecs ...benchmarks/sched-fifo... Delay Maximum . . . . . . . . : 347 usecs Delay Maximum . . . . . . . . : 277 usecs Delay Maximum . . . . . . . . : 246 usecs ...benchmarks/sched-fifo+compile... Delay Maximum . . . . . . . . : 285 usecs Delay Maximum . . . . . . . . : 269 usecs Delay Maximum . . . . . . . . : 277 usecs Delay Maximum . . . . . . . . : 569 usecs Delay Maximum . . . . . . . . : 461 usecs = nice(-20) == ...benchmarks/nice-20... Delay Maximum . . . . . . . . : 13818 usecs Delay Maximum . . . . . . . . : 155637 usecs Delay Maximum . . . . . . . . : 487 usecs Delay Maximum . . . . . . . . : 160328 usecs Delay Maximum . . . . . . . . : 495328 usecs ...benchmarks/nice-20+compile... Delay Maximum . . . . . . . . : 183083 usecs Delay Maximum . . . . . . . . : 5976 usecs Delay Maximum . . . . . . . . : 18155 usecs Delay Maximum . . . . . . . . : 557 usecs = SCHED_ISO == ...benchmarks/sched-iso... Delay Maximum . . . . . . . . : 21410 usecs Delay Maximum . . . . . . . . : 36830 usecs Delay Maximum . . . . . . . . : 4062 usecs ...benchmarks/sched-iso+compile... Delay Maximum . . . . . . . . : 98909 usecs Delay Maximum . . . . . . . . : 39414 usecs Delay Maximum . . . . . . . . : 40294 usecs Delay Maximum . . . . . . . . : 217192 usecs Delay Maximum . . . . . . . . : 156989 usecs Looked at this way, there really is no question. The new scheduler prototypes are falling short significantly. Could this be due to their lack of priority distinctions between realtime threads? Maybe. I can't say for sure. I'll be interested to see what happens when Con is ready for me to try his new priority-based SCHED_ISO prototype. On a different note, the fact that 2.6 is finally performing as well as 2.4+lowlat on this test represents significant progress. In fact, it performed slightly better (I don't know whether that improvement is statistically significant). Congratulations to all who had a hand in making this happen! -- joq - 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/
CPIA under 2.6.10-ac8 -- lacking sysfs support?
I'm getting a black screen from my Ezonics ez.com usb webcam: $ xawtv This is xawtv-3.94, running on Linux/i686 (2.6.10-ac8) xinerama 0: 1600x1200+0+0 xinerama 1: 1280x854+0+1200 /dev/video0 [v4l]: no overlay support v4l-conf had some trouble, trying to continue anyway ioctl: VIDIOCGFBUF(base=(nil);height=0;width=0;depth=0;bytesperline=0): Invalid argument ioctl: VIDIOCSPICT(brightness=32768;hue=32768;colour=32767;contrast=32768;whiteness=0;depth=24;palette=RGB24): Invalid argument ioctl: VIDIOCSPICT(brightness=32767;hue=32768;colour=32768;contrast=32768;whiteness=0;depth=24;palette=RGB24): Invalid argument ioctl: VIDIOCSPICT(brightness=32768;hue=32767;colour=32768;contrast=32768;whiteness=0;depth=24;palette=RGB24): Invalid argument ioctl: VIDIOCSPICT(brightness=32768;hue=32768;colour=32768;contrast=32767;whiteness=0;depth=24;palette=RGB24): Invalid argument The directory /proc/cpia exists but is empty, which means cpia-control isn't working. Is this a sysfs issue? dmesg says "Please fix your driver for proper sysfs support, see http://lwn.net/Articles/36850/; Cheers, Dave Details: I'm running Debian sid with kernel 2.6.10-ac8 and libsysfs1 1.2.0-4 sysfsutils 1.2.0-4 $ v4l-conf v4l-conf: using X11 display :0 dga: version 2.0 mode: 1600x2054, depth=24, bpp=32, bpl=7168, base=0xec00 /dev/video0 [v4l2]: ioctl VIDIOC_QUERYCAP: Invalid argument /dev/video0 [v4l]: no overlay support # dmesg: cpia: Ignoring new-style parameters in presence of obsolete ones V4L-Driver for Vision CPiA based cameras v1.2.3 Since in-kernel colorspace conversion is not allowed, it is disabled by default now. Users should fix the applic ations in case they don't work without conversion reenabled by setting the 'colorspace_conv' module parameter to 1<6>USB driver for Vision CPiA based cameras v1.2.3 USB CPiA camera found videodev: "CPiA Camera" has no release callback. Please fix your driver for proper sysfs support, see http://lwn.net/Articles/36850/ usbcore: registered new driver cpia # lspci: :00:0b.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) :00:0b.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 50) :00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) # lsusb Bus 002 Device 004: ID 0553:0002 STMicroelectronics Imaging Division (VLSI Vision) CPiA WebCam Bus 002 Device 003: ID 06bd:0001 AGFA-Gevaert NV SnapScan 1212U Bus 002 Device 002: ID 0451:1446 Texas Instruments, Inc. TUSB2040/2070 Hub Bus 002 Device 001: ID : Bus 001 Device 002: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse Bus 001 Device 001: ID : # lsusb -vvv Bus 002 Device 004: ID 0553:0002 STMicroelectronics Imaging Division (VLSI Vision) CPiA WebCam Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0553 STMicroelectronics Imaging Division (VLSI Vision) idProduct 0x0002 CPiA WebCam bcdDevice1.00 iManufacturer 0 iProduct1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 73 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 MaxPower 250mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x bytes 0 once bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x01c0 bytes 448 once bInterval 1 Interface Descriptor: bLength
Re: DVD burning still have problems
Hi, have you checked, that cdrecord is not suid root, and growisofs/dvd+rw-tools is? I had some probs, solved with a simple chmod +s growisofs :) Glück Auf Volker - 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/
Remove the number of acl entries limit
This patch removes the arbitrary limit of 32 acl entries on ext[23] when
writing acls. A patch that removes the same check when reding acls is in
BK since 12 March 2004, so all kernels since then are already able to
read large acls. I think that ten+ months are enough so that we can now
also remove the write limit.
This is the read-limit patch:
http://linux.bkbits.net:8080/linux-2.6/cset%404051e2863UsuQEgAQShmimgBooAXkg?nav=index.html
Even without this patch the xattr block could already contain less space
than needed for the acl, because other attributes might already use up
almost all space. So this patch does not introduce additional error
conditions. We have been shipping with this patch the last year
(almost).
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Index: linux-2.6.11-latest/fs/ext2/acl.c
===
--- linux-2.6.11-latest.orig/fs/ext2/acl.c
+++ linux-2.6.11-latest/fs/ext2/acl.c
@@ -255,8 +255,6 @@ ext2_set_acl(struct inode *inode, int ty
return -EINVAL;
}
if (acl) {
- if (acl->a_count > EXT2_ACL_MAX_ENTRIES)
- return -EINVAL;
value = ext2_acl_to_disk(acl, );
if (IS_ERR(value))
return (int)PTR_ERR(value);
Index: linux-2.6.11-latest/fs/ext2/acl.h
===
--- linux-2.6.11-latest.orig/fs/ext2/acl.h
+++ linux-2.6.11-latest/fs/ext2/acl.h
@@ -7,7 +7,6 @@
#include
#define EXT2_ACL_VERSION 0x0001
-#define EXT2_ACL_MAX_ENTRIES 32
typedef struct {
__le16 e_tag;
Index: linux-2.6.11-latest/fs/ext3/acl.c
===
--- linux-2.6.11-latest.orig/fs/ext3/acl.c
+++ linux-2.6.11-latest/fs/ext3/acl.c
@@ -259,8 +259,6 @@ ext3_set_acl(handle_t *handle, struct in
return -EINVAL;
}
if (acl) {
- if (acl->a_count > EXT3_ACL_MAX_ENTRIES)
- return -EINVAL;
value = ext3_acl_to_disk(acl, );
if (IS_ERR(value))
return (int)PTR_ERR(value);
Index: linux-2.6.11-latest/fs/ext3/acl.h
===
--- linux-2.6.11-latest.orig/fs/ext3/acl.h
+++ linux-2.6.11-latest/fs/ext3/acl.h
@@ -7,7 +7,6 @@
#include
#define EXT3_ACL_VERSION 0x0001
-#define EXT3_ACL_MAX_ENTRIES 32
typedef struct {
__le16 e_tag;
Regards,
--
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH
-
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: System beeper - no sound from mobo's own speaker
On Sunday 23 Jan 2005 19:50, Sergey Vlasov wrote: Hi Sergey, You know - I've just found that and yes it does help on one system, so I'm 50% better off - just need to find out where to put the command so that it loads it on startup...modules.conf would be it I guess. Thanks for quick reply. Steve > On Sun, 23 Jan 2005 19:37:53 + Stephen Kitchener wrote: > > I seem to have a problem that, in that when I am using the kernel > > supplied with Mandrake 10.0 and 10.1 and also fedora 3, there seems to be > > a distinct lack of beeps coming from the system, once it is up and > > running. I am NOT talking about sounds that might be coming from any > > sound card that might be connected to the system, but the plain old > > speaker that sits in the PC case. > > Does "modprobe pcspkr" help? In 2.6.x kernels the PC speaker support > can be built as a loadable module; probably the startup scripts do not > load it automatically. -- O o _\_ o \\/ o\ . //\___= '' Sun, 23 Jan 2005 20:04:43 + 20:04:43 up 10:19, 0 users, load average: 1.24, 1.14, 1.10 The crying baby on board your flight is always seated next to you -- Murphy's Laws for Frequent Flyers n°8 - 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: Memory leak in 2.6.11-rc1?
On Sun, Jan 23, 2005 at 02:32:48AM -0800, Andrew Morton wrote: > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > But I'm still stuck with all of my ram gone after a > > 600MB fillmem, half of it is just in swap. > > Well. Half of it has gone so far ;) > > > > > Attaching meminfo and sysrq-m after fillmem. > > (I meant a really big fillmem: a couple of 2GB ones. Not to worry.) > > It's not in slab and the pagecache and anonymous memory stuff seems to be > working OK. So it has to be something else, which does a bare > __alloc_pages(). Low-level block stuff, networking, arch code, perhaps. > > I don't think I've ever really seen code to diagnose this. > > A simplistic approach would be to add eight or so ulongs into struct page, > populate them with builtin_return_address(0...7) at allocation time, then > modify sysrq-m to walk mem_map[] printing it all out for pages which have > page_count() > 0. That'd find the culprit. I think I may be seeing something odd here, maybe a possible memory leak. The only problem I have is wondering whether I'm actually comparing like with like. Maybe some networking people can provide a hint? Below is gathered from 2.6.11-rc1. bash-2.05a# head -n2 /proc/slabinfo slabinfo - version: 2.1 # name bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo 115 ip_dst_cache 759885256 151 bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo 117 ip_dst_cache 770885256 151 bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo 133 ip_dst_cache 775885256 151 bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo 18 ip_dst_cache 664885256 151 bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo 20 ip_dst_cache 664885256 151 bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo 22 ip_dst_cache 673885256 151 bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo 23 ip_dst_cache 670885256 151 bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo 24 ip_dst_cache 675885256 151 bash-2.05a# cat /proc/net/rt_cache | wc -l; grep ip_dst /proc/slabinfo 24 ip_dst_cache 669885256 151 I'm fairly positive when I rebooted the machine a couple of days ago, ip_dst_cache was significantly smaller for the same number of lines in /proc/net/rt_cache. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - 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/
vt_def_color.patch
Hello, I've written a small patch meant to modfity the default vt color on 2.6 kernels. If usefull please aply :) --- linux-2.6.9/drivers/char/Kconfig2004-10-19 00:53:07.0 +0300 +++ linux-update/drivers/char/Kconfig 2004-11-19 00:05:10.0 +0200 @@ -57,6 +57,35 @@ If unsure, say Y. +config VT_COLOR + bool "Change default VT color." +depends on VT +default n +---help--- + This option will allow you to change the default color of your VT + terminal. + + If you say Y here, the next option will let you choose the hex + value. For more information see the help included for the option + below. + + This option should be safe. If unsure, say N. + +config VT_COLOR_NEW + hex "Choose default VT color" + depends on VT_COLOR + default 0x07 +---help--- + Choose default VT foreground color. Setting this option will let + you select the default color of your VT terminal. + + Tested options: +0x03 - cyan +0x05 - purple +0x07 - white (default) +0x09 - blue +0x0A - green + config HW_CONSOLE bool depends on VT && !S390 && !USERMODE --- linux-2.6.9/drivers/char/vt.c 2004-10-19 00:55:06.0 +0300 +++ linux-update/drivers/char/vt.c 2004-11-18 23:48:44.0 +0200 @@ -2555,7 +2555,7 @@ vc_cons[currcons].d->vc_palette[k++] = default_grn[j] ; vc_cons[currcons].d->vc_palette[k++] = default_blu[j] ; } - def_color = 0x07; /* white */ + def_color = CONFIG_VT_COLOR_NEW; /* new */ ulcolor = 0x0f; /* bold white */ halfcolor = 0x08; /* grey */ init_waitqueue_head(_cons[currcons]->paste_wait); signature.asc Description: This is a digitally signed message part
Re: System beeper - no sound from mobo's own speaker
On Sun, 23 Jan 2005 19:37:53 + Stephen Kitchener wrote: > I seem to have a problem that, in that when I am using the kernel supplied > with Mandrake 10.0 and 10.1 and also fedora 3, there seems to be a distinct > lack of beeps coming from the system, once it is up and running. I am NOT > talking about sounds that might be coming from any sound card that might be > connected to the system, but the plain old speaker that sits in the PC case. Does "modprobe pcspkr" help? In 2.6.x kernels the PC speaker support can be built as a loadable module; probably the startup scripts do not load it automatically. pgpdBKge1ndhx.pgp Description: PGP signature
System beeper - no sound from mobo's own speaker
Hi, I seem to have a problem that, in that when I am using the kernel supplied with Mandrake 10.0 and 10.1 and also fedora 3, there seems to be a distinct lack of beeps coming from the system, once it is up and running. I am NOT talking about sounds that might be coming from any sound card that might be connected to the system, but the plain old speaker that sits in the PC case. This, to my mind, is not very usefull for a server or a laptop that might generate system beeps, ie inserting a wifi card for instance on a laptop. As I'm running Mandrake I have posted this to them, but as of yet I have had no responce or reaction. I did do a search and I found at least one user of Redhat reporting the same sort of problem, so I am guessing that it's not a problem that is of Mandrakes doing, ie they forgot to include it in the kernel that they bult for their distribution. I have installed the latest kernel from fedora 2.6.10, but that didn't change things. Please let me know if I have posted something that is a known problem, and I'll shut up and wait for a new kernel to be release that has this fixed. I cannot beleive that this has been missed in testing, but at the same time I have no beeps at all from any of the 3 machines that I have tested and it has been reported to me, by a friend that is running Mandrake 10.1, he is running different hardware, and can confirm that it was working before the upgrade. The only common thing before we changed as that we were both running 2.4 kernels. I can supply details of hardware if wanted. -- O o _\_ o \\/ o\ . //\___= '' Sun, 23 Jan 2005 18:58:38 + 18:58:38 up 9:13, 0 users, load average: 1.30, 1.15, 1.05 Basic Definitions of Science: If it's green or wiggles, it's biology. If it stinks, it's chemistry. If it doesn't work, it's physics. - 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] Problems disabling SYSCTL
On Sun, Jan 23, 2005 at 02:35:00PM +, Matthew Wilcox wrote: > On Sun, Jan 23, 2005 at 04:01:02PM +1100, Anton Blanchard wrote: > > Create a cond_syscall for sys32_sysctl and make all architectures use > > it. Also fix the architectures that dont wrap their 32bit compat sysctl > > code. > > Is there any reason to not move the sys32_sysctl code to kernel/sysctl.c? iirc it relies on a unified address space (= user pointers still work in KERNEL_DS) -Andi - 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/
PROBLEM: sony usb dvdr drive locks system when mounting disc
First kernel bug report, sorry if I commit a faux pas. This occurs when I attempt to mount a disc in a Sony DRX-510UL drive connected by USB 2.0. dbus and hal are running, ivman (automounter) is not running. Turn on the drive, if there is a disc in it remove it. Boot system. Login to KDE. Place a disc in the drive. Open a terminal. Type "mount /dev/sr0" (the drive already exists in fstab). The disc spins up and after a few seconds the system becomes unresponsive. Sometimes the cursor can be moved by the mouse, but it won't interact with the desktop. The only way to "unlock" the system is to push the reset or power button on the CPU. The following were all captured BEFORE the disc was mounted, not possible to capture afterwards. Linux version: Linux version 2.6.10-gentoo-r6L ([EMAIL PROTECTED]) (gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)) #1 SMP Fri Jan 21 22:10:36 EST 2005 ver_linux: Linux LNX-Glamdring 2.6.10-gentoo-r6L #1 SMP Fri Jan 21 22:10:36 EST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz GenuineIntel GNU/Linux Gnu C 3.3.4 Gnu make 3.80 binutils 2.15.92.0.2 util-linux 2.12p mount 2.12p module-init-tools 3.0 e2fsprogs 1.35 reiserfsprogs 3.6.18 reiser4progs line Linux C Library2.3.4 Dynamic linker (ldd) 2.3.4 Procps 3.2.3 Net-tools 1.60 Kbd1.12 Sh-utils 5.2.1 Modules Loaded w83781d eeprom i2c_sensor i2c_isa sd_mod snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device 8139too snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd snd_page_alloc i2c_i801 i2c_core ehci_hcd usb_storage uhci_hcd intel_agp agpgart rtc usbcore sr_mod scsi_mod /proc/modules: w83781d 34344 0 - Live 0xe0ef9000 eeprom 6936 0 - Live 0xe0e86000 i2c_sensor 3968 2 w83781d,eeprom, Live 0xe0e84000 i2c_isa 2816 0 - Live 0xe086c000 sd_mod 14848 0 - Live 0xe0e91000 snd_pcm_oss 50212 0 - Live 0xe0eeb000 snd_mixer_oss 18944 1 snd_pcm_oss, Live 0xe0e8b000 snd_seq_oss 33408 0 - Live 0xe0ed1000 snd_seq_midi_event 7296 1 snd_seq_oss, Live 0xe0e81000 snd_seq 51984 4 snd_seq_oss,snd_seq_midi_event, Live 0xe0ec3000 snd_seq_device 7948 2 snd_seq_oss,snd_seq, Live 0xe0e7e000 8139too 22016 0 - Live 0xe0e6a000 snd_intel8x0 29600 0 - Live 0xe0e61000 snd_ac97_codec 74080 1 snd_intel8x0, Live 0xe0eaf000 snd_pcm 86788 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec, Live 0xe0e98000 snd_timer 22532 2 snd_seq,snd_pcm, Live 0xe0e29000 snd 47332 9 snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,snd_seq_device,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer, Live 0xe0e71000 snd_page_alloc 8580 2 snd_intel8x0,snd_pcm, Live 0xe0826000 i2c_i801 8460 0 - Live 0xe083a000 i2c_core 19456 5 w83781d,eeprom,i2c_sensor,i2c_isa,i2c_i801, Live 0xe0e3 ehci_hcd 28932 0 - Live 0xe0877000 usb_storage 29184 0 - Live 0xe0863000 uhci_hcd 31504 0 - Live 0xe086e000 intel_agp 20508 1 - Live 0xe085c000 agpgart 29484 1 intel_agp, Live 0xe0853000 rtc 11208 0 - Live 0xe0831000 usbcore 105720 4 ehci_hcd,usb_storage,uhci_hcd, Live 0xe0e0e000 sr_mod 16164 0 - Live 0xe082c000 scsi_mod 75488 3 sd_mod,usb_storage,sr_mod, Live 0xe083f000 /proc/ioports: -001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0070-0077 : rtc 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0290-0297 : w83781d 0376-0376 : ide1 03c0-03df : vga+ 03c0-03df : vesafb 03f6-03f6 : ide0 03f8-03ff : serial 0400-047f : :00:1f.0 0400-0403 : PM1a_EVT_BLK 0404-0405 : PM1a_CNT_BLK 0408-040b : PM_TMR 0428-042f : GPE0_BLK 0480-04bf : :00:1f.0 0500-051f : :00:1f.3 0500-050f : i801-smbus 0cf8-0cff : PCI conf1 9000-9fff : PCI Bus #01 9000-90ff : :01:00.0 a000-a0ff : :02:02.0 a000-a0ff : 8139too b000-b01f : :00:1d.1 b000-b01f : uhci_hcd b400-b41f : :00:1d.2 b400-b41f : uhci_hcd b800-b81f : :00:1d.3 b800-b81f : uhci_hcd bc00-bc1f : :00:1d.0 bc00-bc1f : uhci_hcd c000-c007 : :00:1f.2 c400-c403 : :00:1f.2 c800-c807 : :00:1f.2 cc00-cc03 : :00:1f.2 d000-d00f : :00:1f.2 d800-d8ff : :00:1f.5 d800-d8ff : Intel ICH5 dc00-dc3f : :00:1f.5 dc00-dc3f : Intel ICH5 f000-f00f : :00:1f.1 f000-f007 : ide0 f008-f00f : ide1 lspci -vvv: :00:00.0 Host bridge: Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) Subsystem: ABIT Computer Corp.: Unknown device 100a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- :00:01.0 PCI bridge: Intel Corp. 82865G/PE/P PCI to AGP Controller (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF-
