Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver
On Mon, Mar 07, 2005 at 08:27:16AM +0100, Kenan Esau wrote: > > > > > At the end of this mail you'll find some traces I did. > > > > > > > > > > I also wonder if it is possible at all to probe this device. I think > > > > > not. IMHO we should go for a module-parameter which enforces the > > > > > lifebook-protokoll. Something like "force_lb=1". Any Ideas / > > > > > suggestions? > > > > > > > > I'd suggest using psmouse.proto=lifebook > > > > > > The current patch has implemented it that way. But the meaning is a > > > little bit different. With proto=lifebook you ENFORCE the lifebook > > > protocol. As far as I read the meaning of the other ones this does not > > > really enforce these protocols. > > > > That's OK. I'd like to keep the DMI probing as well, though, so it's not > > absolutely necessary to provide the parameter. > > You mean if the device is in the appropriate DMI-database use the > lifebook protocol and if the parameter is provided use it also (although > it might not be in the DMI database)? Yes. > > > > > How does this work out with a second/external mouse? > > > > > > > > The external mouse has to be in bare PS/2 mode anyway, so we don't need > > > > to care. > > > > > > Why that? > > > > Can you send any commands to the external mouse? How the touchscreen > > reacts when the mouse starts sending 4-byte responses? > > No idea yet -- I will test this. OK. > > We process the external mouse packets inside lifebook.c anyway and > > we don't have any support for the enhanced protocols there. > > Ah OK. However, if it was possible to forward commands to the external mouse, we could implement a full passthrough like synaptics.c has, and then support any kind of external mouse (including wheels, bells and whistles.) > I personally never used an external mouse. But last weekend I played > around a little bit and recognized that there are some BIOS-settings > which control the behavior of the touchscreen, quickpoint-device and > external mouse. I have to play around with those a little bit more. But > as far as I can see you can never have all three at the same time. That's probably because the quickpoint is connected in place of the external mouse. -- Vojtech Pavlik SuSE Labs, SuSE CR - 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] ppc64: Mode 2 PCI-X config space size fix
This patch is from Brian King <[EMAIL PROTECTED]>.
When working with a PCI-X Mode 2 adapter on a PCI-X Mode 1 PPC64
system, the current code used to determine the config space size
of a device results in a PCI Master abort and an EEH error, resulting
in the device being taken offline. This patch checks OF to see if
the PCI bridge supports PCI-X Mode 2 and fails config accesses beyond
256 bytes if it does not.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
diff -urN linux-2.5/arch/ppc64/kernel/iSeries_pci.c
test/arch/ppc64/kernel/iSeries_pci.c
--- linux-2.5/arch/ppc64/kernel/iSeries_pci.c 2005-01-22 09:25:41.0
+1100
+++ test/arch/ppc64/kernel/iSeries_pci.c2005-03-07 18:21:41.0
+1100
@@ -610,6 +610,10 @@
if (node == NULL)
return PCIBIOS_DEVICE_NOT_FOUND;
+ if (offset > 255) {
+ *val = ~0;
+ return PCIBIOS_BAD_REGISTER_NUMBER;
+ }
fn = hv_cfg_read_func[(size - 1) & 3];
HvCall3Ret16(fn, &ret, node->DsaAddr.DsaAddr, offset, 0);
@@ -636,6 +640,8 @@
if (node == NULL)
return PCIBIOS_DEVICE_NOT_FOUND;
+ if (offset > 255)
+ return PCIBIOS_BAD_REGISTER_NUMBER;
fn = hv_cfg_write_func[(size - 1) & 3];
ret = HvCall4(fn, node->DsaAddr.DsaAddr, offset, val, 0);
diff -urN linux-2.5/arch/ppc64/kernel/pSeries_pci.c
test/arch/ppc64/kernel/pSeries_pci.c
--- linux-2.5/arch/ppc64/kernel/pSeries_pci.c 2005-01-12 18:20:48.0
+1100
+++ test/arch/ppc64/kernel/pSeries_pci.c2005-03-07 18:21:41.0
+1100
@@ -52,6 +52,16 @@
extern struct mpic *pSeries_mpic;
+static int config_access_valid(struct device_node *dn, int where)
+{
+ if (where < 256)
+ return 1;
+ if (where < 4096 && dn->pci_ext_config_space)
+ return 1;
+
+ return 0;
+}
+
static int rtas_read_config(struct device_node *dn, int where, int size, u32
*val)
{
int returnval = -1;
@@ -60,10 +70,11 @@
if (!dn)
return PCIBIOS_DEVICE_NOT_FOUND;
- if (where & (size - 1))
+ if (!config_access_valid(dn, where))
return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = (dn->busno << 16) | (dn->devfn << 8) | where;
+ addr = ((where & 0xf00) << 20) | (dn->busno << 16) |
+ (dn->devfn << 8) | (where & 0xff);
buid = dn->phb->buid;
if (buid) {
ret = rtas_call(ibm_read_pci_config, 4, 2, &returnval,
@@ -108,10 +119,11 @@
if (!dn)
return PCIBIOS_DEVICE_NOT_FOUND;
- if (where & (size - 1))
+ if (!config_access_valid(dn, where))
return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = (dn->busno << 16) | (dn->devfn << 8) | where;
+ addr = ((where & 0xf00) << 20) | (dn->busno << 16) |
+ (dn->devfn << 8) | (where & 0xff);
buid = dn->phb->buid;
if (buid) {
ret = rtas_call(ibm_write_pci_config, 5, 1, NULL, addr, buid >>
32, buid & 0x, size, (ulong) val);
diff -urN linux-2.5/arch/ppc64/kernel/pci_dn.c test/arch/ppc64/kernel/pci_dn.c
--- linux-2.5/arch/ppc64/kernel/pci_dn.c2005-01-12 18:20:48.0
+1100
+++ test/arch/ppc64/kernel/pci_dn.c 2005-03-07 18:21:41.0 +1100
@@ -37,6 +37,7 @@
static void * __devinit update_dn_pci_info(struct device_node *dn, void *data)
{
struct pci_controller *phb = data;
+ int *type = (int *)get_property(dn, "ibm,pci-config-space-type", NULL);
u32 *regs;
dn->phb = phb;
@@ -46,6 +47,8 @@
dn->busno = (regs[0] >> 16) & 0xff;
dn->devfn = (regs[0] >> 8) & 0xff;
}
+
+ dn->pci_ext_config_space = (type && *type == 1);
return NULL;
}
diff -urN linux-2.5/include/asm-ppc64/prom.h test/include/asm-ppc64/prom.h
--- linux-2.5/include/asm-ppc64/prom.h 2005-01-29 09:58:49.0 +1100
+++ test/include/asm-ppc64/prom.h 2005-03-07 18:21:41.0 +1100
@@ -137,6 +137,7 @@
int devfn; /* for pci devices */
int eeh_mode; /* See eeh.h for possible EEH_MODEs */
int eeh_config_addr;
+ int pci_ext_config_space; /* for pci devices */
struct pci_controller *phb;/* for pci devices */
struct iommu_table *iommu_table; /* for phb's or bridges */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver
Sorry for the late response. Am Dienstag, den 01.03.2005, 13:08 +0100 schrieb Vojtech Pavlik: > On Tue, Mar 01, 2005 at 09:11:49AM +0100, Kenan Esau wrote: > > > > This looks like it either expects some other data (like a second > > > parameter to the command?) or just wants the 0x07 again (and not the > > > whole command) to make sure you really mean it. > > > > > > Could you try sending 0xe8 0x07 0x07? > > > > My old driver did that. But with the same result. It doesn't seem to > > matter what the first and the second bytes are -- the answers from the > > device are alway the same. > > So even 0xe8 0x03 returns error? No -- I meant only 0xe8 0x07 and 0xe8 0x06 . For those it doesn't matter if you repeat the parameter or send something else. The answers from the device for those command/parameters are always the same. > Maybe we should send a command after this (any command), to make sure > the > > psmouse->set_rate(psmouse, psmouse->rate); > > call succeeds and is not confused by the 0xfc response. OK -- I will send the command after 0xe8 0x07 twice. > > > > At the end of this mail you'll find some traces I did. > > > > > > > > I also wonder if it is possible at all to probe this device. I think > > > > not. IMHO we should go for a module-parameter which enforces the > > > > lifebook-protokoll. Something like "force_lb=1". Any Ideas / > > > > suggestions? > > > > > > I'd suggest using psmouse.proto=lifebook > > > > The current patch has implemented it that way. But the meaning is a > > little bit different. With proto=lifebook you ENFORCE the lifebook > > protocol. As far as I read the meaning of the other ones this does not > > really enforce these protocols. > > That's OK. I'd like to keep the DMI probing as well, though, so it's not > absolutely necessary to provide the parameter. You mean if the device is in the appropriate DMI-database use the lifebook protocol and if the parameter is provided use it also (although it might not be in the DMI database)? > > > > How does this work out with a second/external mouse? > > > > > > The external mouse has to be in bare PS/2 mode anyway, so we don't need > > > to care. > > > > Why that? > > Can you send any commands to the external mouse? How the touchscreen > reacts when the mouse starts sending 4-byte responses? No idea yet -- I will test this. > We process the > external mouse packets inside lifebook.c anyway and we don't have any > support for the enhanced protocols there. Ah OK. I personally never used an external mouse. But last weekend I played around a little bit and recognized that there are some BIOS-settings which control the behavior of the touchscreen, quickpoint-device and external mouse. I have to play around with those a little bit more. But as far as I can see you can never have all three at the same 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: New ALPS code in -mm
On Mon, Mar 07, 2005 at 02:14:17AM -0500, Daniel Barkalow wrote:
> On Fri, 4 Mar 2005, Vojtech Pavlik wrote:
>
> > /* Relative movement packet */
> > if (z == 127) {
> > - input_report_rel(dev2, REL_X, (x > 383 ? x : (x -
> > 768)));
> > - input_report_rel(dev2, REL_Y, -(y > 255 ? y : (x -
> > 512)));
> > + input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) :
> > x));
> > + input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) :
> > y));
>
> Not that I have any idea, but (y - 512) seems much more likely here.
>
> > + if ((priv->i->flags & ALPS_DUALPOINT) && z == 127) {
> > + input_report_key(dev2, BTN_LEFT, left);
> > + input_report_key(dev2, BTN_RIGHT, right);
> > + input_report_key(dev2, BTN_MIDDLE, middle);
> > + input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) : x));
> > + input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) : y));
>
> Also here.
Indeed. It took me a while to find it.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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/
[ANNOUNCE 5/6] Open-iSCSI High-Performance Initiator for Linux
include/linux/netlink.h changes (added new protocol NETLINK_ISCSI) Signed-off-by: Alex Aizman <[EMAIL PROTECTED]> Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]> --- linux-2.6.11.orig/include/linux/netlink.h 2005-03-01 23:38:25.0 -0800 +++ linux-2.6.11.dima/include/linux/netlink.h 2005-03-04 17:50:11.143413101 -0800 @@ -14,6 +14,7 @@ #define NETLINK_SELINUX7 /* SELinux event notifications */ #define NETLINK_ARPD 8 #define NETLINK_AUDIT 9 /* auditing */ +#define NETLINK_ISCSI 10 /* iSCSI Open Interface */ #define NETLINK_ROUTE6 11 /* af_inet6 route comm channel */ #define NETLINK_IP6_FW 13 #define NETLINK_DNRTMSG14 /* DECnet routing messages */
[ANNOUNCE 4/6] Open-iSCSI High-Performance Initiator for Linux
drivers/scsi/Makefile changes. Signed-off-by: Alex Aizman <[EMAIL PROTECTED]> Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]> --- linux-2.6.11.orig/drivers/scsi/Makefile 2005-03-01 23:38:19.0 -0800 +++ linux-2.6.11.dima/drivers/scsi/Makefile 2005-03-04 17:50:11.142413217 -0800 @@ -30,6 +30,8 @@ obj-$(CONFIG_SCSI_FC_ATTRS)+= scsi_transport_fc.o obj-$(CONFIG_SCSI_ISCSI_ATTRS) += scsi_transport_iscsi.o +obj-$(CONFIG_ISCSI_IF) += iscsi_if.o +obj-$(CONFIG_ISCSI_TCP)+= iscsi_tcp.o obj-$(CONFIG_SCSI_AMIGA7XX)+= amiga7xx.o 53c7xx.o obj-$(CONFIG_A3000_SCSI) += a3000.o wd33c93.o obj-$(CONFIG_A2091_SCSI) += a2091.o wd33c93.o
[ANNOUNCE 6/6] Open-iSCSI High-Performance Initiator for Linux
Documentation/scsi/iscsi.txt Signed-off-by: Alex Aizman <[EMAIL PROTECTED]> Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]> diff -Nru linux-2.6.11.orig/Documentation/scsi/iscsi.txt linux-2.6.11.dima/Documentation/scsi/iscsi.txt --- linux-2.6.11.orig/Documentation/scsi/iscsi.txt 1969-12-31 16:00:00.0 -0800 +++ linux-2.6.11.dima/Documentation/scsi/iscsi.txt 2005-03-04 17:50:11.145412869 -0800 @@ -0,0 +1,279 @@ += + +Linux* Open-iSCSI + += + +March 04, 2005 + +Contents + + +- 1. In This Release +- 2. Introduction +- 3. Installation +- 4. Open-iSCSI daemon +- 5. Open-iSCSI Configuration Utility +- 6. Configuration +- 7. Getting Started +- 8. TBD +- Appendix A. SendTargets snapshot. + + + +1. In This Release +== + +This file describes the Linux* Open-iSCSI Initiator. + +The latest development release is available at: +http://www.open-iscsi.org + +For questions, comments, contributions send e-mail to: [EMAIL PROTECTED] + +1.1. Features + +- highly optimized and very small-footprint data path; +- multiple outstanding R2Ts; +- persistent configuration database; +- SendTargets discovery; +- CHAP; +- PDU header Digest; +- multiple sessions; +- multi-connection sessions. + +For the most recent list of features please refer to: +http://www.open-iscsi.org/cgi-bin/wiki.pl/Roadmap + + + +2. Introduction +=== + +Open-iSCSI project is a high-performance, transport independent, +multi-platform implementation of RFC3720 iSCSI. + +Open-iSCSI is partitioned into user and kernel parts. + +The kernel portion of Open-iSCSI is a from-scratch code +licensed under GPL. The kernel part implements iSCSI data path +(that is, iSCSI Read and iSCSI Write), and consists of two +loadable modules: iscsi_if.ko and iscsi_tcp.ko. + +User space contains the entire control plane: configuration +manager, iSCSI Discovery, Login and Logout processing, +connection-level error processing, Nop-In and Nop-Out handling, +and (in the future:) Text processing, iSNS, SLP, Radius, etc. + +The user space Open-iSCSI consists of a daemon process called +iscsid, and a management utility iscsiadm. + + +3. Installation +=== + +You need to enable "Cryptographic API" under "Cryptographic options" +in the kernel config. You also need to enable "CRC32c CRC algorithm" if +you use header or data digests. They are the kernel options, +CONFIG_CRYPTO and CONFIG_CRYPTO_CRC32C, respectively. + + +4. Open-iSCSI daemon + + +The daemon implements control path of iSCSI protocol, plus some management +facilities. For example, the daemon could be configured to automatically +re-start discovery at startup, based on the contents of persistent +iSCSI database (see next section). + +For help, run: + + ./iscsid --help + +Usage: iscsid [OPTION] + + -c, --config=[path] Execute in the config file (/etc/iscsid.conf). + -f, --foregroundrun iscsid in the foreground + -d, --debug debuglevel print debugging information + -u, --uid=uid run as uid, default is current user + -g, --gid=gid run as gid, default is current user group + -h, --help display this help and exit + -v, --version display version and exit + + + +5. Open-iSCSI Configuration Utility +=== + +Open-iSCSI persistent configuration is implemented as a DBM database +available on all Linux installations. + +The database contains two tables: + +- Discovery table (discovery.db); +- Node table (node.db). + +The regular place for iSCSI database files: /var/db/iscsi/*.db + +The iscsiadm utility is a command-line tool to manage (update, delete, +insert, query) the persistent database. + +The utility presents set of operations that a user can perform +on iSCSI nodes, sessions, connections, and discovery records. + +Note that some of the iSCSI Node and iSCSI Discovery operations +do not require iSCSI daemon (iscsid) loaded. + +For help, run: + + ./iscsiadm --help + +Usage: iscsiadm [OPTION] + + -m, --mode specify operational mode op = + -m discovery --type=[type] --portal=[ip:port] --login + perform [type] discovery for target portal with + ip-address [ip] and port [port]. Initiate Login for + each discovered target if --login is specified + -m discoverydisplay all discovery records from internal + persistent discovery database + -m discovery --record=[id] --login + perform discovery based on record [id] in database + -m discovery --record=[id] --op=[op] [--name=[name] --value=[value]] + perform
[ANNOUNCE 3/6] Open-iSCSI High-Performance Initiator for Linux
drivers/scsi/Kconfig changes. Signed-off-by: Alex Aizman <[EMAIL PROTECTED]> Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]> diff -Nru --exclude 'iscsi*' --exclude Makefile linux-2.6.11.orig/drivers/scsi/Kconfig linux-2.6.11.dima/drivers/scsi/Kconfig --- linux-2.6.11.orig/drivers/scsi/Kconfig 2005-03-01 23:38:25.0 -0800 +++ linux-2.6.11.dima/drivers/scsi/Kconfig 2005-03-04 17:50:11.14141 -0800 @@ -185,6 +185,44 @@ there should be no noticeable performance impact as long as you have logging turned off. +config ISCSI_IF + tristate "iSCSI Open Transport Interface" + depends on SCSI && INET + ---help--- + To compile this driver as a module, choose M here: the + module will be called iscsi_if. + + This driver manages multiple iSCSI transports. This module is required + for normal iscsid operation. + + See more detailed information here: + + http://www.open-iscsi.org + +config ISCSI_TCP + tristate "iSCSI Initiator over TCP/IP" + depends on ISCSI_IF + default y + select CRYPTO + select CRYPTO_MD5 + select CRYPTO_CRC32C + ---help--- + To compile this driver as a module, choose M here: the + module will be called iscsi_tcp. + + The iSCSI Driver provides a host with the ability to access storage + through an IP network. The driver uses the iSCSI protocol to transport + SCSI requests and responses over a TCP/IP network between the host + (the "initiator") and "targets". Architecturally, the iSCSI driver + combines with the host's TCP/IP stack, network drivers, and Network + Interface Card (NIC) to provide the same functions as a SCSI or a + Fibre Channel (FC) adapter driver with a Host Bus Adapter (HBA). + + The userspace component needed to initialize the driver, documentation, + and sample configuration files can be found here: + + http://www.open-iscsi.org + menu "SCSI Transport Attributes" depends on SCSI
[ANNOUNCE 2/6] Open-iSCSI High-Performance Initiator for Linux
Common header files:
- iscsi_ifev.h (user/kernel events).
- iscsi_if.h (iSCSI open interface over netlink);
- iscsi_proto.h (RFC3720 #defines and types);
Signed-off-by: Alex Aizman <[EMAIL PROTECTED]>
Signed-off-by: Dmitry Yusupov <[EMAIL PROTECTED]>
diff -Nru linux-2.6.11.orig/include/scsi/iscsi_ifev.h
linux-2.6.11.dima/include/scsi/iscsi_ifev.h
--- linux-2.6.11.orig/include/scsi/iscsi_ifev.h 1969-12-31 16:00:00.0
-0800
+++ linux-2.6.11.dima/include/scsi/iscsi_ifev.h 2005-03-04 17:50:11.138413681
-0800
@@ -0,0 +1,105 @@
+/*
+ * iSCSI Kernel/User Interface Events
+ *
+ * Copyright (C) 2005 Dmitry Yusupov, Alex Aizman
+ * maintained by [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * See the file COPYING included with this distribution for more details.
+ */
+
+#ifndef ISCSI_IFEV_H
+#define ISCSI_IFEV_H
+
+typedef enum iscsi_uevent_e {
+ ISCSI_UEVENT_UNKNOWN= 0,
+
+ /* down events */
+ ISCSI_UEVENT_CREATE_SESSION = UEVENT_BASE + 1,
+ ISCSI_UEVENT_DESTROY_SESSION= UEVENT_BASE + 2,
+ ISCSI_UEVENT_CREATE_CNX = UEVENT_BASE + 3,
+ ISCSI_UEVENT_DESTROY_CNX= UEVENT_BASE + 4,
+ ISCSI_UEVENT_BIND_CNX = UEVENT_BASE + 5,
+ ISCSI_UEVENT_SET_PARAM = UEVENT_BASE + 6,
+ ISCSI_UEVENT_START_CNX = UEVENT_BASE + 7,
+ ISCSI_UEVENT_STOP_CNX = UEVENT_BASE + 8,
+ ISCSI_UEVENT_SEND_PDU = UEVENT_BASE + 9,
+
+ /* up events */
+ ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1,
+ ISCSI_KEVENT_CNX_ERROR = KEVENT_BASE + 2,
+} iscsi_uevent_e;
+
+struct iscsi_uevent {
+ uint32_t type; /* k/u events type */
+ uint32_t transport_id;
+
+ union {
+ /* messages u -> k */
+ struct msg_create_session {
+ uint64_tsession_handle;
+ uint32_tinitial_cmdsn;
+ } c_session;
+ struct msg_destroy_session {
+ uint64_tsession_handle;
+ } d_session;
+ struct msg_create_cnx {
+ uint64_tsession_handle;
+ uint64_tcnx_handle;
+ uint32_tcid;
+ } c_cnx;
+ struct msg_bind_cnx {
+ uint64_tsession_handle;
+ uint64_tcnx_handle;
+ uint32_ttransport_fd;
+ uint32_tis_leading;
+ } b_cnx;
+ struct msg_destroy_cnx {
+ uint64_tcnx_handle;
+ } d_cnx;
+ struct msg_send_pdu {
+ uint32_thdr_size;
+ uint32_tdata_size;
+ uint64_tcnx_handle;
+ } send_pdu;
+ struct msg_set_param {
+ uint64_tcnx_handle;
+ uint32_tparam; /* iscsi_param_e */
+ uint32_tvalue;
+ } set_param;
+ struct msg_start_cnx {
+ uint64_tcnx_handle;
+ } start_cnx;
+ struct msg_stop_cnx {
+ uint64_tcnx_handle;
+ } stop_cnx;
+ } u;
+ union {
+ /* messages k -> u */
+ uint64_thandle;
+ int retcode;
+ struct msg_create_session_ret {
+ uint64_thandle;
+ uint32_tsid;
+ } c_session_ret;
+ struct msg_recv_req {
+ uint64_trecv_handle;
+ uint64_tcnx_handle;
+ } recv_req;
+ struct msg_cnx_error {
+ uint64_tcnx_handle;
+ uint32_terror; /* iscsi_err_e */
+ } cnxerror;
+ } r;
+};
+
+#endif /* ISCSI_IFEV_H */
diff -Nru linux-2.6.11.orig/include/scsi/iscsi_if.h
linux-2.6.11.dima/include/scsi/iscsi_if.h
--- linux-2.6.11.orig/include/scsi/iscsi_if.h 1969-12-31 16:00:00.0
-0800
+++ linux-2.6.11.dima/include/scsi/iscsi_if.h 2005-03-04 17:50:11.137413797
-0800
@@ -0,0 +1,140 @@
+/*
+ * iSCSI User/Kernel Int
Re: New ALPS code in -mm
On Fri, 4 Mar 2005, Vojtech Pavlik wrote:
> /* Relative movement packet */
> if (z == 127) {
> - input_report_rel(dev2, REL_X, (x > 383 ? x : (x -
> 768)));
> - input_report_rel(dev2, REL_Y, -(y > 255 ? y : (x -
> 512)));
> + input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) :
> x));
> + input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) :
> y));
Not that I have any idea, but (y - 512) seems much more likely here.
> + if ((priv->i->flags & ALPS_DUALPOINT) && z == 127) {
> + input_report_key(dev2, BTN_LEFT, left);
> + input_report_key(dev2, BTN_RIGHT, right);
> + input_report_key(dev2, BTN_MIDDLE, middle);
> + input_report_rel(dev2, REL_X, (x > 383 ? (x - 768) : x));
> + input_report_rel(dev2, REL_Y, -(y > 255 ? (x - 512) : y));
Also here.
-Daniel
*This .sig left intentionally blank*
-
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][3/3] swsusp: use non-contiguous memory
On Fri, Mar 04, 2005 at 08:51:53PM +0100, Rafael J. Wysocki wrote: > From: Hu Gang <[EMAIL PROTECTED]> > > Subject: swsusp: use non-contiguous memory on resume - ppc support > > This patch contains the architecture-dependent changes for ppc > required for using a linklist instead of an array of page backup entries > during resume. > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Signed-off-by: Hu Gang <[EMAIL PROTECTED]> ... -- Hu Gang .-. /v\ // \\ Linux User /( )\ [204016] GPG Key ID ^^-^^ http://soulinfo.com/~hugang/hugang.asc - 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/
[ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
This is to announce Open-iSCSI project: High-Performance iSCSI Initiator for Linux. MOTIVATION == Our initial motivations for the project were: (1) implement the right user/kernel split, and (2) design iSCSI data path for performance. Recently we added (3): get accepted into the mainline kernel. As far as user/kernel, the existing iSCSI initiators bloat the kernel with ever-growing control plane code, including but not limited to: iSCSI discovery, Login (Authentication and Operational), session and connection management, connection-level error processing, iSCSI Text, Nop-Out/In, Async Message, iSNS, SLP, Radius... Open-iSCSI puts the entire control plane in the user space. This control plane talks to the data plane via well defined interface over the netlink transport. (Side note: prior to closing on the netlink we considered: sysfs, ioctl, and syscall. Because the entire control plane logic resides in the user space, we needed a real bi-directional transport that could support asynchronous API to transfer iSCSI control PDUs: Login, Logout, Nop-in, Nop-Out, Text, Async Message. Performance. This is the major goal and motivation for this project. As it happens, iSCSI has to compete with Fibre Channel, which is a more entrenched technology in the storage space. In addition, the "soft" iSCSI implementation have to show good results in presence of specialized hardware offloads. Our today's performance numbers are: - 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block size); - 320MB/sec Write on a single connection (2-way 2.4Ghz Opteron, 64KB block size); - 50,000 Read IOPS on a single connection (2-way 2.4Ghz Opteron, 4KB block size). Prior to starting from-scratch the data path code we did evaluate the sfnet Initiator. And eventually decided against patching it. Instead, we reused its Discovery, Login, etc. control plane code. Technically, it was the shortest way to achieve the (1) and (2) goals stated above. We believe that it remains the easiest and the most practical thing on the larger scale of: iSCSI for Linux. STATUS == There's a 100% working code that interoperates with all (count=5) iSCSI targets we could get our hands on. The software was tested on AMD Opteron (TM) and Intel Xeon (TM). Code is available online via either Subversion source control database or the latest development release (i.e., the tarball containing Open-iSCSI sources, including user space, that will build and run on kernels starting 2.6.10). http://www.open-iscsi.org Features: - highly optimized and small-footprint data path; - multiple outstanding R2Ts; - thread-less receive; - sendpage() based transmit; - zero-copy header processing on receive; - no data path memory allocations at runtime; - persistent configuration database; - SendTargets discovery; - CHAP; - DataSequenceInOrder=No; - PDU header Digest; - multiple sessions; - MC/S (note: disabled in the patch); - SCSI-level recovery via Abort Task and session re-open. TODO The near term plan is: test, test, and test. We need to stabilize the existing code, after 5 months of development this seems to be the right thing to do. Other short-term plans include: a) process community feedback, implement comments and apply patches; b) cleanup user side of the iSCSI open interface; use API calls (instead of directly constructing events); c) eliminate runtime control path memory allocations (for Nop-In, Nop-Out, etc.); d) implement Write path optimizations (delayed because of the self-imposed submission deadline); e) oProfile the data path, use the reports for further optimization; f) complete the readme. Comments, code reviews, patches - are greatly appreciated! THANKS == Special thanks to our first reviewers: Christoph Hellwig and Mike Christie. Special thanks to Ming Zhang for help in testing and for insightful questions. Regards, Alex Aizman & Dmitry Yusupov = The following 6 patches alltogether represent the Open-iSCSI Initiator: Patch 1: SCSI LLDD consists of 3 files: - iscsi_if.c (iSCSI open interface over netlink); - iscsi_tcp.[ch] (iSCSI transport over TCP/IP). Patch 2: Common header files: - iscsi_if.h (iSCSI open interface over netlink); - iscsi_proto.h (RFC3720 #defines and types); - iscsi_ifev.h (user/kernel events). Patch 3: drivers/scsi/Kconfig changes. Patch 4: drivers/scsi/Makefile changes. Patch 5: include/linux/netlink.h changes (added new protocol NETLINK_ISCSI) Patch 6: Documentation/scsi/iscsi.txt - 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] Consolidate the last compat sigvals
Hi Andrew, Linus,
This patch just consolidates the last of the (what should have been)
compat_sigval_ts. It also fixes S390 that had a sigval_t in its struct
compat_siginfo.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
This patch needs to be applied on top of my "add and use
COMPAT_SIGEV_PAD_SIZE" patch posted a few minutes ago.
P.S. this patch has not even been compiled as I don't have acces to any of
the platforms involved, but has been acked by Dave Miller.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
diff -ruNp linus-SIGEV/arch/ia64/ia32/ia32priv.h
linus-sigval/arch/ia64/ia32/ia32priv.h
--- linus-SIGEV/arch/ia64/ia32/ia32priv.h 2005-02-21 12:02:07.0
+1100
+++ linus-sigval/arch/ia64/ia32/ia32priv.h 2005-03-07 17:52:28.0
+1100
@@ -225,11 +225,6 @@ struct stat64 {
unsigned intst_ino_hi;
};
-typedef union sigval32 {
- int sival_int;
- unsigned int sival_ptr;
-} sigval_t32;
-
typedef struct compat_siginfo {
int si_signo;
int si_errno;
@@ -249,7 +244,7 @@ typedef struct compat_siginfo {
timer_t _tid; /* timer id */
int _overrun; /* overrun count */
char _pad[sizeof(unsigned int) - sizeof(int)];
- sigval_t32 _sigval; /* same as below */
+ compat_sigval_t _sigval;/* same as below */
int _sys_private; /* not to be passed to user */
} _timer;
@@ -257,7 +252,7 @@ typedef struct compat_siginfo {
struct {
unsigned int _pid; /* sender's pid */
unsigned int _uid; /* sender's uid */
- sigval_t32 _sigval;
+ compat_sigval_t _sigval;
} _rt;
/* SIGCHLD */
@@ -283,7 +278,7 @@ typedef struct compat_siginfo {
} compat_siginfo_t;
typedef struct sigevent32 {
- sigval_t32 sigev_value;
+ compat_sigval_t sigev_value;
int sigev_signo;
int sigev_notify;
union {
diff -ruNp linus-SIGEV/arch/mips/kernel/signal32.c
linus-sigval/arch/mips/kernel/signal32.c
--- linus-SIGEV/arch/mips/kernel/signal32.c 2005-02-04 04:10:36.0
+1100
+++ linus-sigval/arch/mips/kernel/signal32.c2005-03-02 14:25:33.0
+1100
@@ -32,11 +32,6 @@
#define SI_PAD_SIZE32 ((SI_MAX_SIZE/sizeof(int)) - 3)
-typedef union sigval32 {
- int sival_int;
- s32 sival_ptr;
-} sigval_t32;
-
typedef struct compat_siginfo {
int si_signo;
int si_code;
@@ -89,7 +84,7 @@ typedef struct compat_siginfo {
struct {
compat_pid_t _pid; /* sender's pid */
compat_uid_t _uid; /* sender's uid */
- sigval_t32 _sigval;
+ compat_sigval_t _sigval;
} _rt;
} _sifields;
diff -ruNp linus-SIGEV/arch/s390/kernel/compat_linux.h
linus-sigval/arch/s390/kernel/compat_linux.h
--- linus-SIGEV/arch/s390/kernel/compat_linux.h 2005-02-21 12:02:07.0
+1100
+++ linus-sigval/arch/s390/kernel/compat_linux.h2005-03-07
17:49:16.0 +1100
@@ -29,11 +29,6 @@ struct old_sigaction32 {
__u32 sa_restorer;/* Another 32 bit pointer */
};
-typedef union sigval32 {
-int sival_int;
-__u32 sival_ptr;
-} sigval_t32;
-
typedef struct compat_siginfo {
int si_signo;
int si_errno;
@@ -52,7 +47,7 @@ typedef struct compat_siginfo {
struct {
timer_t _tid; /* timer id */
int _overrun; /* overrun count */
- sigval_t _sigval; /* same as below */
+ compat_sigval_t _sigval;/* same as below */
int _sys_private; /* not to be passed to user */
} _timer;
@@ -60,7 +55,7 @@ typedef struct compat_siginfo {
struct {
pid_t _pid; /* sender's pid */
uid_t _uid; /* sender's uid */
- sigval_t32 _sigval;
+ compat_sigval_t _sigval;
} _rt;
/* SIGCHLD */
diff -ruNp linus-SIGEV/arch/sparc64/kernel/signal32.c
linus-sigval/arch/sparc64/kernel/signal32.c
--- linus-SIGEV/arch/sparc64/kernel/signal32.c 2005-02-04 04:10:36.0
+1100
+++ linus-sigval/arch/sparc64/kernel/signal32.c 2005-03-02 14:25:33.0
+1100
@@ -104,7 +104,7 @@ typedef struct compat_siginfo{
struct {
timer_t _tid; /* timer id */
int _overrun; /* overrun count
Re: [PATCH] Treat ALPS mouse buttons as mouse buttons
On Sun, Mar 06, 2005 at 10:35:26PM -0800, Micheal Marineau wrote: > > Thanks. Could you also attach the one from -mm1? It's a bit different. > > > here is the mm1 version: > I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 > N: Name="AT Translated Set 2 keyboard" > P: Phys=isa0060/serio0/input0 > H: Handlers=kbd mouse0 > B: EV=120017 > B: KEY=4 4 200 3802078 f840d001 b2df ffef fffe > B: REL=140 > B: MSC=10 > B: LED=7 > > I: Bus=0011 Vendor=0002 Product=0008 Version= > N: Name="PS/2 Mouse" > P: Phys=isa0060/serio1/input1 > H: Handlers=mouse1 > B: EV=7 > B: KEY=7 0 0 0 0 0 0 0 0 > B: REL=3 > > I: Bus=0011 Vendor=0002 Product=0008 Version=6337 > N: Name="AlpsPS/2 ALPS GlidePoint" > P: Phys=isa0060/serio1/input0 > H: Handlers=mouse2 > B: EV=f > B: KEY=420 0 7 0 0 0 0 0 0 0 0 > B: REL=3 > B: ABS=103 Thanks! -- Vojtech Pavlik SuSE Labs, SuSE CR - 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] add and use COMPAT_SIGEV_PAD_SIZE
Hi all,
All the 32 bit architectures (effectively) define SIGEV_PAD_SIZE to be
((SIGEV_MAX_SIZE/sizeof(int)) - 3). So define COMPAT_SIGEV_PAD_SIZE to be
this and replace SIGEV_PAD_SIZE32 where it is used. It also needs to be
used in the definition of struct compat_sigevent as most of the
architectures would have had it 4 bytes too small in the kernel (since we
were using SIGEV_PAD_SIZE).
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
diff -ruNp linus/arch/ia64/ia32/ia32priv.h linus-SIGEV/arch/ia64/ia32/ia32priv.h
--- linus/arch/ia64/ia32/ia32priv.h 2005-01-05 17:06:07.0 +1100
+++ linus-SIGEV/arch/ia64/ia32/ia32priv.h 2005-02-21 12:02:07.0
+1100
@@ -230,8 +230,6 @@ typedef union sigval32 {
unsigned int sival_ptr;
} sigval_t32;
-#define SIGEV_PAD_SIZE32 ((SIGEV_MAX_SIZE/sizeof(int)) - 3)
-
typedef struct compat_siginfo {
int si_signo;
int si_errno;
@@ -289,7 +287,7 @@ typedef struct sigevent32 {
int sigev_signo;
int sigev_notify;
union {
- int _pad[SIGEV_PAD_SIZE32];
+ int _pad[COMPAT_SIGEV_PAD_SIZE];
struct {
u32 _function;
u32 _attribute; /* really pthread_attr_t */
diff -ruNp linus/arch/s390/kernel/compat_linux.h
linus-SIGEV/arch/s390/kernel/compat_linux.h
--- linus/arch/s390/kernel/compat_linux.h 2005-02-04 13:05:31.0
+1100
+++ linus-SIGEV/arch/s390/kernel/compat_linux.h 2005-02-21 12:02:07.0
+1100
@@ -199,7 +199,6 @@ struct ucontext32 {
compat_sigset_t uc_sigmask; /* mask last for extensibility
*/
};
-#define SIGEV_PAD_SIZE32 ((SIGEV_MAX_SIZE/sizeof(int)) - 3)
struct sigevent32 {
union {
int sival_int;
@@ -208,7 +207,7 @@ struct sigevent32 {
int sigev_signo;
int sigev_notify;
union {
- int _pad[SIGEV_PAD_SIZE32];
+ int _pad[COMPAT_SIGEV_PAD_SIZE];
int _tid;
struct {
u32 *_function;
diff -ruNp linus/include/asm-sparc64/siginfo.h
linus-SIGEV/include/asm-sparc64/siginfo.h
--- linus/include/asm-sparc64/siginfo.h 2005-01-05 17:06:08.0 +1100
+++ linus-SIGEV/include/asm-sparc64/siginfo.h 2005-02-21 12:02:07.0
+1100
@@ -4,7 +4,6 @@
#define SI_PAD_SIZE32 ((SI_MAX_SIZE/sizeof(int)) - 3)
#define SIGEV_PAD_SIZE ((SIGEV_MAX_SIZE/sizeof(int)) - 4)
-#define SIGEV_PAD_SIZE32 ((SIGEV_MAX_SIZE/sizeof(int)) - 3)
#define __ARCH_SI_PREAMBLE_SIZE(4 * sizeof(int))
#define __ARCH_SI_TRAPNO
@@ -47,7 +46,7 @@ typedef struct sigevent32 {
int sigev_signo;
int sigev_notify;
union {
- int _pad[SIGEV_PAD_SIZE32];
+ int _pad[COMPAT_SIGEV_PAD_SIZE];
struct {
u32 _function;
diff -ruNp linus/include/linux/compat.h linus-SIGEV/include/linux/compat.h
--- linus/include/linux/compat.h2005-03-07 13:06:24.0 +1100
+++ linus-SIGEV/include/linux/compat.h 2005-03-07 14:07:26.0 +1100
@@ -101,12 +101,14 @@ typedef union compat_sigval {
compat_uptr_t sival_ptr;
} compat_sigval_t;
+#define COMPAT_SIGEV_PAD_SIZE ((SIGEV_MAX_SIZE/sizeof(int)) - 3)
+
typedef struct compat_sigevent {
compat_sigval_t sigev_value;
compat_int_t sigev_signo;
compat_int_t sigev_notify;
union {
- compat_int_t _pad[SIGEV_PAD_SIZE];
+ compat_int_t _pad[COMPAT_SIGEV_PAD_SIZE];
compat_int_t _tid;
struct {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-mm1] mips: more convert verify_area to access_ok
On Mon, 7 Mar 2005 00:55:30 +0100 (CET) Jesper Juhl <[EMAIL PROTECTED]> wrote: > On Sun, 6 Mar 2005, Yoichi Yuasa wrote: > > > This patch converts verify_area to access_ok for include/asm-mips. > > > Yeah, that's one of the few bits I had not done yet. Thank you for taking > a look at that. > > I don't believe your patch is correct though. See below for what I think > is a better one. That's right. I forgot to assign 0 to __gu_err/__pu_err after access_ok(). Thanks, Yoichi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Treat ALPS mouse buttons as mouse buttons
Vojtech Pavlik wrote: > On Sun, Mar 06, 2005 at 10:12:00PM -0800, Micheal Marineau wrote: > > The following patch changes the ALPS touchpad driver to treat some mouse buttons as mouse buttons rather than what appears to be joystick buttons. This is needed for the Dell Inspiron 8500's DualPoint stick buttons. Without this patch only the touchpad buttons behave properly. >>> >>> >>>Thanks for the patch. I'll try to put this change into my the latest >>>version of the ALPS driver, which, unfortunately, has been reworked >>>significantly. >>> >>>Can you send me the output of /proc/bus/input/devices on your machine? >>>I'd like to know the ID of your ALPS dualpoint. >> >>I just looked at the new version in 2.6.11-mm1 and it appears that my >>change as already been covered in different ways and I'm not having any >>problem with the buttons on mm1. > > > Good. I just noticed the same. :) > > >>Just in case you still want to know, >>the following is the ouptput if /proc/bus/input/devices. >> >>I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 >>N: Name="AT Translated Set 2 keyboard" >>P: Phys=isa0060/serio0/input0 >>H: Handlers=kbd >>B: EV=120013 >>B: KEY=4 200 3802078 f840d001 f2df ffef fffe >>B: MSC=10 >>B: LED=7 >> >>I: Bus=0011 Vendor=0002 Product=0008 Version= >>N: Name="AlpsPS/2 ALPS TouchPad" >>P: Phys=isa0060/serio1/input0 >>H: Handlers=mouse0 >>B: EV=f >>B: KEY=420 0 67 0 0 0 0 0 0 0 0 >>B: REL=3 >>B: ABS=103 > > > Thanks. Could you also attach the one from -mm1? It's a bit different. > here is the mm1 version: I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd mouse0 B: EV=120017 B: KEY=4 4 200 3802078 f840d001 b2df ffef fffe B: REL=140 B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0002 Product=0008 Version= N: Name="PS/2 Mouse" P: Phys=isa0060/serio1/input1 H: Handlers=mouse1 B: EV=7 B: KEY=7 0 0 0 0 0 0 0 0 B: REL=3 I: Bus=0011 Vendor=0002 Product=0008 Version=6337 N: Name="AlpsPS/2 ALPS GlidePoint" P: Phys=isa0060/serio1/input0 H: Handlers=mouse2 B: EV=f B: KEY=420 0 7 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=103 -- Michael Marineau [EMAIL PROTECTED] Oregon State University signature.asc Description: OpenPGP digital signature
Re: [PATCH] Treat ALPS mouse buttons as mouse buttons
On Sun, Mar 06, 2005 at 10:12:00PM -0800, Micheal Marineau wrote: > >>The following patch changes the ALPS touchpad driver to treat some mouse > >>buttons as mouse buttons rather than what appears to be joystick buttons. > >>This is needed for the Dell Inspiron 8500's DualPoint stick buttons. Without > >>this patch only the touchpad buttons behave properly. > > > > > > Thanks for the patch. I'll try to put this change into my the latest > > version of the ALPS driver, which, unfortunately, has been reworked > > significantly. > > > > Can you send me the output of /proc/bus/input/devices on your machine? > > I'd like to know the ID of your ALPS dualpoint. > > I just looked at the new version in 2.6.11-mm1 and it appears that my > change as already been covered in different ways and I'm not having any > problem with the buttons on mm1. Good. I just noticed the same. :) > Just in case you still want to know, > the following is the ouptput if /proc/bus/input/devices. > > I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 > N: Name="AT Translated Set 2 keyboard" > P: Phys=isa0060/serio0/input0 > H: Handlers=kbd > B: EV=120013 > B: KEY=4 200 3802078 f840d001 f2df ffef fffe > B: MSC=10 > B: LED=7 > > I: Bus=0011 Vendor=0002 Product=0008 Version= > N: Name="AlpsPS/2 ALPS TouchPad" > P: Phys=isa0060/serio1/input0 > H: Handlers=mouse0 > B: EV=f > B: KEY=420 0 67 0 0 0 0 0 0 0 0 > B: REL=3 > B: ABS=103 Thanks. Could you also attach the one from -mm1? It's a bit different. -- Vojtech Pavlik SuSE Labs, SuSE CR - 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] Treat ALPS mouse buttons as mouse buttons
On Sun, Mar 06, 2005 at 04:58:15PM -0800, Micheal Marineau wrote: > The following patch changes the ALPS touchpad driver to treat some mouse > buttons as mouse buttons rather than what appears to be joystick buttons. > This is needed for the Dell Inspiron 8500's DualPoint stick buttons. Without > this patch only the touchpad buttons behave properly. After investigating the problem deeper it looks like this should already be fixed in Andrew Morton's -mm tree. Can you try it? > --- linux-2.6.11/drivers/input/mouse/alps.c 2005-03-01 23:38:13.0 > -0800 > +++ linux-2.6.11-gentoo-r2/drivers/input/mouse/alps.c 2005-03-06 > 16:45:07.0 -0800 > @@ -97,8 +97,8 @@ > > input_report_rel(dev, REL_X, x); > input_report_rel(dev, REL_Y, -y); > - input_report_key(dev, BTN_A, left); > - input_report_key(dev, BTN_B, right); > + input_report_key(dev, BTN_LEFT, left); > + input_report_key(dev, BTN_RIGHT, right); > input_sync(dev); > return; > } > @@ -389,8 +389,6 @@ > psmouse->dev.evbit[LONG(EV_REL)] |= BIT(EV_REL); > psmouse->dev.relbit[LONG(REL_X)] |= BIT(REL_X); > psmouse->dev.relbit[LONG(REL_Y)] |= BIT(REL_Y); > - psmouse->dev.keybit[LONG(BTN_A)] |= BIT(BTN_A); > - psmouse->dev.keybit[LONG(BTN_B)] |= BIT(BTN_B); > > psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); > input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0); -- Vojtech Pavlik SuSE Labs, SuSE CR - 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] Treat ALPS mouse buttons as mouse buttons
Vojtech Pavlik wrote: > On Sun, Mar 06, 2005 at 04:58:15PM -0800, Micheal Marineau wrote: > > >>The following patch changes the ALPS touchpad driver to treat some mouse >>buttons as mouse buttons rather than what appears to be joystick buttons. >>This is needed for the Dell Inspiron 8500's DualPoint stick buttons. Without >>this patch only the touchpad buttons behave properly. > > > Thanks for the patch. I'll try to put this change into my the latest > version of the ALPS driver, which, unfortunately, has been reworked > significantly. > > Can you send me the output of /proc/bus/input/devices on your machine? > I'd like to know the ID of your ALPS dualpoint. > I just looked at the new version in 2.6.11-mm1 and it appears that my change as already been covered in different ways and I'm not having any problem with the buttons on mm1. Just in case you still want to know, the following is the ouptput if /proc/bus/input/devices. I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd B: EV=120013 B: KEY=4 200 3802078 f840d001 f2df ffef fffe B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0002 Product=0008 Version= N: Name="AlpsPS/2 ALPS TouchPad" P: Phys=isa0060/serio1/input0 H: Handlers=mouse0 B: EV=f B: KEY=420 0 67 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=103 -- Michael Marineau [EMAIL PROTECTED] Oregon State University signature.asc Description: OpenPGP digital signature
Re: [BK PATCH] I2C patches for 2.6.11
On Sat, Mar 05, 2005 at 12:59:02PM +0100, Jean Delvare wrote: > Hi Greg, > > > Here is a I2C update for 2.6.11. It includes a number of fixes, and > > some new i2c drivers. All of these patches have been in the past few > > -mm releases. > > I checked against my own list of patches and found that I have two more, > which were posted to the sensors and kernel-janitors list in early > february: > http://archives.andrew.net.au/lm-sensors/msg29340.html > http://archives.andrew.net.au/lm-sensors/msg29342.html > > They never made it to your own i2c tree, nor Andrew's tree. What do we > want to do with these? They should show up in the -kj tree, right? That will make it to the -mm tree, and then the kernel janitor maintainer will split them up and send them to me and you. Or Nish can get frustrated at how long the whole process is taking, and just resend them again :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/5] setup_per_zone_lowmem_reserve() oops fix
On Fri, Mar 04, 2005 at 01:16:55PM -0800, [EMAIL PROTECTED] wrote: > > > If you do 'echo 0 0 > /proc/sys/vm/lowmem_reserve_ratio' the kernel gets a > divide-by-zero. > > Prevent that, and fiddle with some whitespace too. Due to the whitespace fiddling, I'd say no to this patch, based on the "criteria". thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] nicksched for 2.6.11
Prakash Punnoor wrote: Nick Piggin schrieb: I've had a few queries about this, so by "popular" demand, I've put my latest nicksched stuff here: www.kerneltrap.org/~npiggin/2.6.11-nicksched.gz It includes all the multiprocessor stuff that's in -mm, and also my alternate scheduler policy. Hi, just to make sure, is it still advised to renice X when using your scheduler? Yes it is. I have a hack in there that automatically renices any binary starting with 'XF' to -10 for people who forget. So this includes XFree86, though maybe it doesn't get the x.org server? Nick - 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/
hw watchdog vs softdog fix.
The comment at the top of the Makefile suggests that the current ordering is incorrect. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> --- linux-2.6.11/drivers/char/watchdog/Makefile~2005-03-07 00:57:53.0 -0500 +++ linux-2.6.11/drivers/char/watchdog/Makefile 2005-03-07 00:58:18.0 -0500 @@ -2,11 +2,6 @@ # Makefile for the WatchDog device drivers. # -# Only one watchdog can succeed. We probe the hardware watchdog -# drivers first, then the softdog driver. This means if your hardware -# watchdog dies or is 'borrowed' for some reason the software watchdog -# still gives you some cover. - obj-$(CONFIG_PCWATCHDOG) += pcwd.o obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o @@ -24,7 +19,6 @@ obj-$(CONFIG_SH_WDT) += shwdt.o obj-$(CONFIG_S3C2410_WATCHDOG) += s3c2410_wdt.o obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o obj-$(CONFIG_EUROTECH_WDT) += eurotechwdt.o -obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o obj-$(CONFIG_W83877F_WDT) += w83877f_wdt.o obj-$(CONFIG_W83627HF_WDT) += w83627hf_wdt.o obj-$(CONFIG_SC520_WDT) += sc520_wdt.o @@ -39,3 +33,10 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb. obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o + +# Only one watchdog can succeed. We probe the hardware watchdog +# drivers first, then the softdog driver. This means if your hardware +# watchdog dies or is 'borrowed' for some reason the software watchdog +# still gives you some cover. + +obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o - 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] Treat ALPS mouse buttons as mouse buttons
On Sun, Mar 06, 2005 at 04:58:15PM -0800, Micheal Marineau wrote: > The following patch changes the ALPS touchpad driver to treat some mouse > buttons as mouse buttons rather than what appears to be joystick buttons. > This is needed for the Dell Inspiron 8500's DualPoint stick buttons. Without > this patch only the touchpad buttons behave properly. Thanks for the patch. I'll try to put this change into my the latest version of the ALPS driver, which, unfortunately, has been reworked significantly. Can you send me the output of /proc/bus/input/devices on your machine? I'd like to know the ID of your ALPS dualpoint. > --- linux-2.6.11/drivers/input/mouse/alps.c 2005-03-01 23:38:13.0 > -0800 > +++ linux-2.6.11-gentoo-r2/drivers/input/mouse/alps.c 2005-03-06 > 16:45:07.0 -0800 > @@ -97,8 +97,8 @@ > > input_report_rel(dev, REL_X, x); > input_report_rel(dev, REL_Y, -y); > - input_report_key(dev, BTN_A, left); > - input_report_key(dev, BTN_B, right); > + input_report_key(dev, BTN_LEFT, left); > + input_report_key(dev, BTN_RIGHT, right); > input_sync(dev); > return; > } > @@ -389,8 +389,6 @@ > psmouse->dev.evbit[LONG(EV_REL)] |= BIT(EV_REL); > psmouse->dev.relbit[LONG(REL_X)] |= BIT(REL_X); > psmouse->dev.relbit[LONG(REL_Y)] |= BIT(REL_Y); > - psmouse->dev.keybit[LONG(BTN_A)] |= BIT(BTN_A); > - psmouse->dev.keybit[LONG(BTN_B)] |= BIT(BTN_B); > > psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); > input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0); -- Vojtech Pavlik SuSE Labs, SuSE CR - 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: Slowdown on 3000 socket-machines tracked down
On Mon, Mar 07, 2005 at 04:42:10PM +1100, Nick Piggin wrote: > Nick Piggin wrote: > >Willy Tarreau wrote: > > > >>thousands of sockets). I never had enough time to investigate more, so I > >>went back to 2.4. > >> > > > >I have heard other complaints about this, and they are definitely > >related to the scheduler (not saying yours is, but it is very possible). > > > > Oh, and if you could dig this thing up too, that might be > good: someone else may have time to investigate more. I would love to, since my major concern with 2.6 has always been the scheduler (but that's not to you that I will learn this). At the moment, I really don't have time for this, I promised that I would send a full reproducible report, but it takes a lot of time. Cheers, Willy - 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: Slowdown on 3000 socket-machines tracked down
Nick Piggin wrote: Willy Tarreau wrote: thousands of sockets). I never had enough time to investigate more, so I went back to 2.4. I have heard other complaints about this, and they are definitely related to the scheduler (not saying yours is, but it is very possible). Oh, and if you could dig this thing up too, that might be good: someone else may have time to investigate more. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Slowdown on 3000 socket-machines tracked down
Willy Tarreau wrote: On Mon, Mar 07, 2005 at 04:14:37PM +1100, Nick Piggin wrote: I think you would have better luck in reproducing this problem if you did the full sendfile thing. I think it is becoming disk bound due to page reclaim problems, which is causing the slowdown. In that case, writing the network only test would help to confirm the problem is not a networking one - so not useless by any means. Not necessarily, Nick. I have written an HTTP testing tool which matches the description of Ben's : non-blocking, single-threaded, no disk I/O, etc... It works flawlessly under 2.4, and gives me random numbers in 2.6, No you're right, I'm not 100% sure, so I'm definitely not saying Ben's test will be useless. Just that if it is not too hard to make one with sendfile, I think he should. If he makes a network-only version and cannot reproduce the problems, that *doesn't* mean it is *not* a network problem. However if he reproduces the problem with a full sendfile version and not the network only one, then that is a better indicator... but I'm rambling. especially if I start some CPU activity on the system, I can get pauses of up to 13 seconds without this tool doing anything !!! At first I believed it was because of the scheduler, but it might also be related to what is described here since I had somewhat the same setup (gigE, 1500, thousands of sockets). I never had enough time to investigate more, so I went back to 2.4. I have heard other complaints about this, and they are definitely related to the scheduler (not saying yours is, but it is very possible). - 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 10/13] remove aggressive idle balancing
Siddha, Suresh B wrote: By code inspection, I see an issue with this patch [PATCH 10/13] remove aggressive idle balancing Why are we removing cpu_and_siblings_are_idle check from active_load_balance? In case of SMT, we want to give prioritization to an idle package while doing active_load_balance(infact, active_load_balance will be kicked mainly because there is an idle package) Just the re-addition of cpu_and_siblings_are_idle check to active_load_balance might not be enough. We somehow need to communicate this to move_tasks, otherwise can_migrate_task will fail and we will never be able to do active_load_balance. Active balancing should only kick in after the prescribed number of rebalancing failures - can_migrate_task will see this, and will allow the balancing to take place. That said, we currently aren't doing _really_ well for SMT on some workloads, however with this patch we are heading in the right direction I think. I have been mainly looking at tuning CMP Opterons recently (they are closer to a "traditional" SMP+NUMA than SMT, when it comes to the scheduler's point of view). However, in earlier revisions of the patch I had been looking at SMT performance and was able to get it much closer to perfect: I was working on a 4 socket x440 with HT. The problem area is usually when the load is lower than the number of logical CPUs. So on tbench, we do say 450MB/s with 4 or more threads without HT, and 550MB/s with 8 or more threads with HT, however we only do 300MB/s with 4 threads. Those aren't the exact numbers, but that's basically what they look like. Now I was able to bring the 4 thread + HT case much closer to the 4 thread - HT numbers, but with earlier patchsets. When I get a chance I will do more tests on the HT system, but the x440 is infuriating for fine tuning performance, because it is a NUMA system, but it doesn't tell the kernel about it, so it will randomly schedule things on "far away" CPUs, and results vary. PS. Another thing I would like to see tested is a 3 level domain setup (SMT + SMP + NUMA). I don't have access to one though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 12/14] drivers/dmapool: use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
Nish Aravamudan <[EMAIL PROTECTED]> wrote: > > > Also, __set_current_state() can be user here: the add_wait_queue() contains > > the necessary barriers. (Grubby, but we do that in quite a few places with > > this particular code sequence (we should have an add_wait_queue() variant > > which does the add_wait_queue+__set_current_state all in one hit (but let's > > not, else I'll be buried in another 1000 cleanuplets))). > > Ok, I will re-spin this patch. Or would you prefer an incremental one? Let's forget about this one while we work out whether that code is doing what we want it to do. - 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: Slowdown on 3000 socket-machines tracked down
On Mon, Mar 07, 2005 at 04:14:37PM +1100, Nick Piggin wrote: > I think you would have better luck in reproducing this problem if you > did the full sendfile thing. > > I think it is becoming disk bound due to page reclaim problems, which > is causing the slowdown. > > In that case, writing the network only test would help to confirm the > problem is not a networking one - so not useless by any means. Not necessarily, Nick. I have written an HTTP testing tool which matches the description of Ben's : non-blocking, single-threaded, no disk I/O, etc... It works flawlessly under 2.4, and gives me random numbers in 2.6, especially if I start some CPU activity on the system, I can get pauses of up to 13 seconds without this tool doing anything !!! At first I believed it was because of the scheduler, but it might also be related to what is described here since I had somewhat the same setup (gigE, 1500, thousands of sockets). I never had enough time to investigate more, so I went back to 2.4. It makes me think that for the problem described here, we have no indication of CPU & I/O activity, which might help Ben try to reproduce. Cheers, Willy - 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: Slowdown on 3000 socket-machines tracked down
Ben Greear wrote: Christian Schmid wrote: Ben Greear wrote: How many bytes are you sending with each call to write()/sendto() whatever? I am using sendfile-call every 100 ms per socket with the poll-api. So basically around 40 kb per round. My application is single-threaded, uses non-blocking IO, and sends/rcvs from/to memory. It will be a good test of the TCP stack, but will not use the sendfile logic, nor will it touch the HD. I think you would have better luck in reproducing this problem if you did the full sendfile thing. I think it is becoming disk bound due to page reclaim problems, which is causing the slowdown. In that case, writing the network only test would help to confirm the problem is not a networking one - so not useless by any means. - 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: amd64 2.6.11 oops on modprobe
Andrei Mikhailovsky wrote:
Hi Randy,
Done the kstack=32, here is the output:
cat /proc/cmdline
root=/dev/hda2 ro kstack=32 console=tty0
P.S. Yeah, this oops is repeatable; hapens everytime
I have one other request. Load each (related) module one at a time,
to make sure that there is no module racing going on here.
Something like (but I'm not sure about the order of these modprobes):
echo /bin/true > /proc/sys/kernel/hotplug
modprobe zr36067
modprobe videocodec
modprobe zr36060
modprobe adv7175
modprobe saa7110
Output-
Unable to handle kernel paging request at 880db000 RIP:
{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3de65067 PTE 0
Oops: [1]
CPU 0
Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv
libata snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd snd_page_alloc i2c_nforce2 it87 eeprom i2c_sensor i2c_isa
sk98lin
Pid: 3213, comm: modprobe Not tainted 2.6.11-amd64
RIP: 0010:[]
{:saa7110:saa7110_write_block+127}
RSP: 0018:81003e9a3b78 EFLAGS: 00010287
RAX: 139f RBX: ec36 RCX: 002a
RDX: 009f RSI: 0001 RDI: 880bf838
RBP: 139f R08: R09: 8100067713a8
R10: 0001 R11: 802f75d0 R12: 880db000
R13: 810037277400 R14: 81003e4efe00 R15: 0001
FS: 2aac5520() GS:80500180()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 880db000 CR3: 3fa2b000 CR4: 06e0
Process modprobe (pid: 3213, threadinfo 81003e9a2000, task
81003e8096c0)
Stack: 0076
81003e4efe28
002a0001004e 81003e9a3b78 81003e4efe28
810037277400
81003e4efe00 81003e4eff70
880bf808
880d9930 880d9ab4
004e 004e
0003
880dab60 802f6812
880dab50
880bf808 880bf9a8 880bf908
80474f90
Call Trace:{:saa7110:saa7110_detect_client+0}
{:saa7110:saa7110_detect_client+388}
{i2c_probe+642}
{i2c_add_adapter+468}
{i2c_bit_add_bus+840}
{:zr36067:init_dc10_cards+1536}
{sys_init_module+5857}
{do_lookup+55}
{prio_tree_insert+48}
{:zr36067:init_dc10_cards+0}
{sys_mmap+191} {system_call
+126}
Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44
RIP {:saa7110:saa7110_write_block+127} RSP
CR2: 880db000
---Output end---
If you need any further info, please let me know
--
Andrei
On Sat, 2005-03-05 at 16:53 -0800, Randy.Dunlap wrote:
Andrei Mikhailovsky wrote:
I get the oops during the boot up process. This did not happen in
2.6.10/2.6.9.
Here is the output from dmesg:
Unable to handle kernel paging request at 880db000 RIP:
{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3ee64067 PTE 0
Oops: [1]
CPU 0
Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv
libata snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd snd_page_alloc i2c_nforce2 it87 eeprom i2c_sensor i2c_isa
sk98lin
Pid: 2604, comm: modprobe Not tainted 2.6.11-amd64
RIP: 0010:[]
{:saa7110:saa7110_write_block+127}
RSP: 0018:81003f6c5b78 EFLAGS: 00010287
RAX: 139f RBX: ec36 RCX: 002a
RDX: 009f RSI: 0001 RDI: 880bf838
RBP: 139f R08: R09: 81003efd63a8
R10: 0001 R11: 802f75d0 R12: 880db000
R13: 81003f3e0200 R14: 81003e0df200 R15: 0001
FS: 2aac5520() GS:80500180()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 880db000 CR3: 3e125000 CR4: 06e0
Process modprobe (pid: 2604, threadinfo 81003f6c4000, task
81003ed59700)
Stack: 0076
81003e0df228
002a0001004e 81003f6c5b78
Call Trace:{:saa7110:saa7110_detect_client+0}
{:saa7110:saa7110_detect_client+388}
{i2c_probe+642}
{i2c_add_adapter+468}
{i2c_bit_add_bus+840}
{:zr36067:init_dc10_cards+1536}
{sys_init_module+5857}
{do_lookup+55}
{prio_tree_insert+48}
{:zr36067:init_dc10_cards+0}
{sys_mmap+191} {system_call
+126}
Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44
RIP {:saa7110:saa7110_write_block+127} RSP
CR2: 880db000
--
~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://
[PATCH] kconfig: DEBUG_PAGEALLOC and SOFTWARE_SUSPEND are incompatible on i386
On i386, SOFTWARE_SUSPEND requires the CPU to have PSE support, but DEBUG_PAGEALLOC disables PSE. Thus, allowing both options to be enabled simultaneously makes no sense. This patch disables DEBUG_PAGEALLOC if SOFTWARE_SUSPEND is enabled; it also displays a comment to briefly explain why DEBUG_PAGEALLOC is missing in that case. I have tested this patch against oldconfig and menuconfig on 2.6.11-bk2. Signed-off-by: Barry K. Nathan <[EMAIL PROTECTED]> --- linux-2.6.11-bk2/arch/i386/Kconfig.debug2004-12-24 13:34:45.0 -0800 +++ linux-2.6.11-bk2-bkn2/arch/i386/Kconfig.debug 2005-03-06 20:59:07.0 -0800 @@ -38,9 +38,12 @@ This option will slow down process creation somewhat. +comment "Page alloc debug is incompatible with Software Suspend on i386" + depends on DEBUG_KERNEL && SOFTWARE_SUSPEND + config DEBUG_PAGEALLOC bool "Page alloc debugging" - depends on DEBUG_KERNEL + depends on DEBUG_KERNEL && !SOFTWARE_SUSPEND help Unmap pages from the kernel linear mapping after free_pages(). This results in a large slowdown, but helps to find certain types - 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: slab corruption in skb allocs
On Mar 6, 2005, at 10:40 AM, Richard Fuchs wrote: Scott Feldman wrote: A bug in the driver. I have a hunch: please try this patch with 2.6.9 or higher: http://marc.theaimsgroup.com/?l=linux-netdev&m=110726809431611&w=2 bingo, that fixes it. too bad neither this patch nor the removal of the NAPI config option made it into 2.6.11... Jesse Brandeburg @ Intel found the fix for the bug but I don't think it's been pushed out to Jeff's tree yet, AFAIK. Soon, I would guess. Would you mind giving this patch a try against 2.6.11? I think it's equivalent to Jesse's patch, but less intrusive to the driver. --- linux-2.6.11/drivers/net/e100.c.origSun Mar 6 20:58:15 2005 +++ linux-2.6.11/drivers/net/e100.c Sun Mar 6 21:01:34 2005 @@ -1471,8 +1471,12 @@ static inline int e100_rx_indicate(struc /* If data isn't ready, nothing to indicate */ if(unlikely(!(rfd_status & cb_complete))) - return -EAGAIN; + return -ENODATA; + /* This allows for a fast restart without re-enabling interrupts */ + if(le16_to_cpu(rfd->command) & cb_el) + nic->ru_running = 0; + /* Get actual data size */ actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF; if(unlikely(actual_size > RFD_BUF_LEN - sizeof(struct rfd))) @@ -1527,7 +1531,11 @@ static inline void e100_rx_clean(struct break; /* Better luck next time (see watchdog) */ } - e100_start_receiver(nic); + /* NAPI: attempt to restart the receiver iff the list is +* totally clean otherwise we'll race between hardware and +* nic->rx_to_clean. */ + if(!work_done || *work_done == 0) + e100_start_receiver(nic); } static void e100_rx_clean_list(struct nic *nic) No. e1000 is a totally different driver/device with very similar name. too bad, i was hoping for an explanation for some unexplainable crashes i've been experiencing... ;) Take the e1000 issue to linux-netdev. -scott - 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 12/14] drivers/dmapool: use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
On Sun, 6 Mar 2005 19:44:14 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
> >
> > Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
> > ---
> >
> >
> > kj-domen/drivers/base/dmapool.c |2 +-
> > 1 files changed, 1 insertion(+), 1 deletion(-)
> >
> > diff -puN drivers/base/dmapool.c~task_unint-drivers_base_dmapool
> > drivers/base/dmapool.c
> > --- kj/drivers/base/dmapool.c~task_unint-drivers_base_dmapool
> > 2005-03-05 16:11:21.0 +0100
> > +++ kj-domen/drivers/base/dmapool.c 2005-03-05 16:11:21.0 +0100
> > @@ -293,7 +293,7 @@ restart:
> > if (mem_flags & __GFP_WAIT) {
> > DECLARE_WAITQUEUE (wait, current);
> >
> > -current->state = TASK_INTERRUPTIBLE;
> > +set_current_state(TASK_UNINTERRUPTIBLE);
> > add_wait_queue (&pool->waitq, &wait);
> > spin_unlock_irqrestore (&pool->lock, flags);
>
> This code is alread a bit odd. If we're prepared to sleep in there, then
> why use GFP_ATOMIC?
>
> If it is so that we can dig a bit deeper into the free page pools then
> something like __GFP_WAIT|__GFP_HIGH would be preferable.
>
> And why isn't mem_flags passed into pool_alloc_page() verbatim?
Sorry, far beyond my abilities :(
> I agree on the TASK_UNINTERRUPTIBLE change: if the calling task happens to
> have signal_pending() then the schedule_timeout() will fall right through.
> Why should we change kernel memory allocation strategy if the user hit ^C?
Yup, didn't make much sense to me.
> Also, __set_current_state() can be user here: the add_wait_queue() contains
> the necessary barriers. (Grubby, but we do that in quite a few places with
> this particular code sequence (we should have an add_wait_queue() variant
> which does the add_wait_queue+__set_current_state all in one hit (but let's
> not, else I'll be buried in another 1000 cleanuplets))).
Ok, I will re-spin this patch. Or would you prefer an incremental one?
Thanks,
Nish
-
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 05/14] char/hvsi: use wait_event_timeout()
On Sun, 6 Mar 2005 19:32:36 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Please consider applying. This is my first wait-queue related patch, so
> > comments
> > are very welcome.
> >
> > Use wait_event_timeout() in place of custom wait-queue code. The
> > code is not changed in any way (I don't think), but is cleaned up quite a
> > bit
> > (will get expanded to almost identical code).
> >
> > ...
> > +if(!wait_event_timeout(hp->stateq, (hp->state == state), jiffies +
> > HVSI_TIMEOUT))
> > +ret = -EIO;
>
> wait_event_timeout()'s `timeout' arg is number-of-milliseconds-to-wait,
> not an absolute time, yes?
D'oh. I will fix this and any other timeout version that are being
pushed to you tomorrow. Sadly, wait_event*() do not take milliseconds,
but jiffies. I am hoping to push some patches to change that, but it
may have to wait a while.
> Also, it's conventional to put a space between the `if' and the `('.
>
> It's nice to squeeze the code into an 80-column xterm, too.
Will fix these both as well.
Thanks,
Nish
-
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 breaks ALSA Intel AC97 audio
Thanks Lee, that fixed it. On Mon, 7 Mar 2005 12:09, Lee Revell wrote: > On Mon, 2005-03-07 at 11:09 +1100, Michael Ellerman wrote: > > Hi Lars, > > > > Yeah I've got no audio on my T41, which I think uses the AC97 too. I > > haven't had time to look into it though :/ > > Did you disable "Headphone Jack Sense" and "Line Jack Sense" in > alsamixer? > > Lee pgpnUUUKA07zb.pgp Description: PGP signature
Re: More trouble with i386 EFLAGS and ptrace
On Sun, Mar 06, 2005 at 07:16:37PM -0800, Roland McGrath wrote: > > I think mine is more correct; the problem doesn't occur because the > > debugger cancelled a signal, it occurs because a bogus TF bit was saved > > to the signal context. I like keeping solutions close to their > > problems. But that's just aesthetic. > > I understand the scenario. Understanding how it comes about made me > recognize there is another scenario that is also handled wrong. > I didn't say the second scenario was what you are seeing. > > Dan's patch covers the case of PTRACE_SINGLESTEP called to deliver a signal > that has a handler to run. That's because there TF is set after the ptrace > stop, when it's resuming. This is a "normalize register state" operation. > I think it would be a little clearer to do this in handle_signal where the > similar case of tweaking register state to back up a system call is done. > > The patch I posted moves the resetting of TF from the trap handler to > ptrace_signal_deliver. This is necessary to ensure that TF is not shown as > set in the registers retrieved by the debugger when the process stops for > something other than the single-step trap requested by PTRACE_SINGLESTEP. Is this semantically different from the patch I posted, i.e. is there any case which one of them covers and not the other? > Here is a patch that does both of those things. This had no effect on any > of the gdb testsuite cases (for good or ill) aside from sigstep.exp, and: > > $ grep 'FAIL.*sigstep' testsuite/gdb.sum > KFAIL: gdb.base/sigstep.exp: finish from handleri; leave handler (could not > set breakpoint) (PRMS: gdb/1736) > > I don't know what that one is about, but it was KFAIL before the change too. That is an inability to set breakpoints in the vsyscall page. Andrew told me (last May, wow) that he thought this worked in Fedora, but I haven't seen any signs of the code. It would certainly be a Good Thing if it is possible! > -- Daniel Jacobowitz CodeSourcery, LLC - 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/
symlink to proc file
dear sir i want to create a symbolic link to my own proc file system (which has been already created in /fs/proc/root.c) from the /kernel/fork.c how to do it i actually want to write inside the proc directory using the syslink what will be the syntax and the parameter passed could you plz explain me the parameters passed to struct proc_dir_entry* proc_symlink(const char* name, struct proc_dir_entry* parent, const char* dest); thanks sounak Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony - 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] inotify for 2.6.11
On Mon, 2005-03-07 at 01:23 +, Christoph Hellwig wrote: > It means that every re3vision of inotify so far has been buggy in some > respect and ig got dropped from -mm again and again. It should get some > more testing there and not sent firectly for mainline. It was dropped from 2.6-mm once. Robert Love - 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.1
Shawn Starr wrote: Sure, I can do this. Wrt to trivial patches, will these patches that go into rusty's patch bot go into Linus's tree or into the -mm tree? The reason I ask that is because a trivial patch may fix an oops if there's an off-by-one problem and typically I'd submit that to the trivial patch bot. No offense intended, but Rusty's trivial bot is often too slow for critical patches, so trivial-but-critical would be better off going to thru the x.y tree IMO. That's why I was wondering about why this tree doesn't except trivial changes. It will if they fix real problems that people are experiencing. The trivil bot and/or kernel-janitors paths for patches are better used for slow/non-critical patches, not patches that need quick attention and merging. Thanks, Shawn. On March 6, 2005 00:06, you wrote: On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote: Sounds great, I can be a QA resource for what machines I have. How do people get involved in QAing these releases? Get the last release and test it out. If you have problems, and have simple/obvious patches, send them on. -- ~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: amd64 2.6.11 oops on modprobe
Andrei Mikhailovsky wrote:
Hi Randy,
Done the kstack=32, here is the output:
cat /proc/cmdline
root=/dev/hda2 ro kstack=32 console=tty0
P.S. Yeah, this oops is repeatable; hapens everytime
Well thanks, I've looked thru this but I'm not getting anywhere
on it. Also, there aren't many changes in this driver or in
the relevant I2C drivers between 2.6.10 and 2.6.11 AFAICT.
If the maintainer(s) of this don't see/know the problem here,
we'll have to ask you to do a binary search on the 2.6.11-rcN
patches to see when this began. Would you do that, please?
Andrei, you don't have CONFIG_PREEMPT enabled, right?
Just checking.
Output-
Unable to handle kernel paging request at 880db000 RIP:
{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3de65067 PTE 0
Oops: [1]
CPU 0
Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv
libata snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd snd_page_alloc i2c_nforce2 it87 eeprom i2c_sensor i2c_isa
sk98lin
Pid: 3213, comm: modprobe Not tainted 2.6.11-amd64
RIP: 0010:[]
{:saa7110:saa7110_write_block+127}
RSP: 0018:81003e9a3b78 EFLAGS: 00010287
RAX: 139f RBX: ec36 RCX: 002a
RDX: 009f RSI: 0001 RDI: 880bf838
RBP: 139f R08: R09: 8100067713a8
R10: 0001 R11: 802f75d0 R12: 880db000
R13: 810037277400 R14: 81003e4efe00 R15: 0001
FS: 2aac5520() GS:80500180()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 880db000 CR3: 3fa2b000 CR4: 06e0
Process modprobe (pid: 3213, threadinfo 81003e9a2000, task
81003e8096c0)
Stack: 0076
81003e4efe28
002a0001004e 81003e9a3b78 81003e4efe28
810037277400
81003e4efe00 81003e4eff70
880bf808
880d9930 880d9ab4
004e 004e
0003
880dab60 802f6812
880dab50
880bf808 880bf9a8 880bf908
80474f90
Call Trace:{:saa7110:saa7110_detect_client+0}
{:saa7110:saa7110_detect_client+388}
{i2c_probe+642}
{i2c_add_adapter+468}
{i2c_bit_add_bus+840}
{:zr36067:init_dc10_cards+1536}
{sys_init_module+5857}
{do_lookup+55}
{prio_tree_insert+48}
{:zr36067:init_dc10_cards+0}
{sys_mmap+191} {system_call
+126}
Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44
RIP {:saa7110:saa7110_write_block+127} RSP
CR2: 880db000
---Output end---
If you need any further info, please let me know
--
Andrei
On Sat, 2005-03-05 at 16:53 -0800, Randy.Dunlap wrote:
Andrei Mikhailovsky wrote:
I get the oops during the boot up process. This did not happen in
2.6.10/2.6.9.
Here is the output from dmesg:
Unable to handle kernel paging request at 880db000 RIP:
{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3ee64067 PTE 0
Oops: [1]
CPU 0
Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv
libata snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd snd_page_alloc i2c_nforce2 it87 eeprom i2c_sensor i2c_isa
sk98lin
Pid: 2604, comm: modprobe Not tainted 2.6.11-amd64
RIP: 0010:[]
{:saa7110:saa7110_write_block+127}
RSP: 0018:81003f6c5b78 EFLAGS: 00010287
RAX: 139f RBX: ec36 RCX: 002a
RDX: 009f RSI: 0001 RDI: 880bf838
RBP: 139f R08: R09: 81003efd63a8
R10: 0001 R11: 802f75d0 R12: 880db000
R13: 81003f3e0200 R14: 81003e0df200 R15: 0001
FS: 2aac5520() GS:80500180()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 880db000 CR3: 3e125000 CR4: 06e0
Process modprobe (pid: 2604, threadinfo 81003f6c4000, task
81003ed59700)
Stack: 0076
81003e0df228
002a0001004e 81003f6c5b78
Call Trace:{:saa7110:saa7110_detect_client+0}
{:saa7110:saa7110_detect_client+388}
{i2c_probe+642}
{i2c_add_adapter+468}
{i2c_bit_add_bus+840}
{:zr36067:init_dc10_cards+1536}
{sys_init_module+5857}
{do_lookup+55}
{prio_tree_insert+48}
{:zr36067:init_dc10_cards+0}
{sys_mmap+191} {system_call
+126}
Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44
RIP {:saa7110:saa7110_write_block+127} RSP
CR2: 880db000
If anyone need more debugging info, I am ready to hel
Re: Linux 2.6.11.1
Sure, I can do this. Wrt to trivial patches, will these patches that go into rusty's patch bot go into Linus's tree or into the -mm tree? The reason I ask that is because a trivial patch may fix an oops if there's an off-by-one problem and typically I'd submit that to the trivial patch bot. That's why I was wondering about why this tree doesn't except trivial changes. Thanks, Shawn. On March 6, 2005 00:06, you wrote: > On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote: > > Sounds great, I can be a QA resource for what machines I have. > > > > How do people get involved in QAing these releases? > > Get the last release and test it out. If you have problems, and have > simple/obvious patches, send them on. > > thanks, > > greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 4298] swsusp fails to suspend if CONFIG_DEBUG_PAGEALLOC is also enabled
Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> Hi!
>
> > Problem Description:
> > swsusp normally works, but if I enable CONFIG_DEBUG_PAGEALLOC, it breaks --
> > after "PM: snapshotting memory", swsusp never gets to the "critical
> > section" and
> > it kind of bounces back from the suspend attempt, for lack of a better way
> > for
> > me to describe the effect.
>
> Okay, that is because low-level assembly requires PSE (4mb pages for
> kernel) and DEBUG_PAGEALLOC disables that capability.
>
> If you feel like rewriting assembly code to turn off paging (and thus
> working with PSE), go ahead, but I do not think it is worth the
> trouble.
>
> OTOH we should at least tell people what went wrong, some people seen
> same problem on VIA cpus... Please apply,
>
Isn't some Kconfig solution appropriate here?
>
> --- clean/include/asm-i386/suspend.h 2004-12-25 13:35:02.0 +0100
> +++ linux/include/asm-i386/suspend.h 2005-03-02 01:05:33.0 +0100
> @@ -10,10 +10,12 @@
> arch_prepare_suspend(void)
> {
> /* If you want to make non-PSE machine work, turn off paging
> - in do_magic. swsusp_pg_dir should have identity mapping, so
> + in swsusp_arch_suspend. swsusp_pg_dir should have identity
> mapping, so
> it could work... */
> - if (!cpu_has_pse)
> + if (!cpu_has_pse) {
> + printk(KERN_ERR "PSE is required for swsusp.\n");
> return -EPERM;
> + }
> return 0;
> }
>
> --
> People were complaining that M$ turns users into beta-testers...
> ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/8] isdn/capi: replace interruptible_sleep_on() with wait_event_interruptible()
[EMAIL PROTECTED] wrote:
>
>
>
> Use wait_event_interruptible() instead of the deprecated
> interruptible_sleep_on(). Patch is straight-forward as current sleep is
> conditionally looped. Patch is compile-tested.
>
> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
> ---
>
>
> kj-domen/drivers/isdn/capi/capi.c |9 ++---
> 1 files changed, 2 insertions(+), 7 deletions(-)
>
> diff -puN drivers/isdn/capi/capi.c~int_sleep_on-drivers_isdn_capi_capi
> drivers/isdn/capi/capi.c
> --- kj/drivers/isdn/capi/capi.c~int_sleep_on-drivers_isdn_capi_capi
> 2005-03-05 16:11:36.0 +0100
> +++ kj-domen/drivers/isdn/capi/capi.c 2005-03-05 16:11:36.0 +0100
> @@ -675,13 +675,8 @@ capi_read(struct file *file, char __user
> if (file->f_flags & O_NONBLOCK)
> return -EAGAIN;
>
> - for (;;) {
> - interruptible_sleep_on(&cdev->recvwait);
> - if ((skb = skb_dequeue(&cdev->recvqueue)) != 0)
> - break;
> - if (signal_pending(current))
> - break;
> - }
> + wait_event_interruptible(cdev->recvwait,
> + ((skb = skb_dequeue(&cdev->recvqueue)) == 0));
> if (skb == 0)
> return -ERESTARTNOHAND;
> }
hmm, OK. Putting an expression with side-effect such as this into a macro
which evaluates the expression multiple times is a bit of a worry, but it
appears that everything will work OK.
That being said, I'd prefer that this come in via the ISDN team, after
having been tested 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 12/14] drivers/dmapool: use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
[EMAIL PROTECTED] wrote:
>
> use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
>
> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
> ---
>
>
> kj-domen/drivers/base/dmapool.c |2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN drivers/base/dmapool.c~task_unint-drivers_base_dmapool
> drivers/base/dmapool.c
> --- kj/drivers/base/dmapool.c~task_unint-drivers_base_dmapool
> 2005-03-05 16:11:21.0 +0100
> +++ kj-domen/drivers/base/dmapool.c 2005-03-05 16:11:21.0 +0100
> @@ -293,7 +293,7 @@ restart:
> if (mem_flags & __GFP_WAIT) {
> DECLARE_WAITQUEUE (wait, current);
>
> -current->state = TASK_INTERRUPTIBLE;
> +set_current_state(TASK_UNINTERRUPTIBLE);
> add_wait_queue (&pool->waitq, &wait);
> spin_unlock_irqrestore (&pool->lock, flags);
This code is alread a bit odd. If we're prepared to sleep in there, then
why use GFP_ATOMIC?
If it is so that we can dig a bit deeper into the free page pools then
something like __GFP_WAIT|__GFP_HIGH would be preferable.
And why isn't mem_flags passed into pool_alloc_page() verbatim?
I agree on the TASK_UNINTERRUPTIBLE change: if the calling task happens to
have signal_pending() then the schedule_timeout() will fall right through.
Why should we change kernel memory allocation strategy if the user hit ^C?
Also, __set_current_state() can be user here: the add_wait_queue() contains
the necessary barriers. (Grubby, but we do that in quite a few places with
this particular code sequence (we should have an add_wait_queue() variant
which does the add_wait_queue+__set_current_state all in one hit (but let's
not, else I'll be buried in another 1000 cleanuplets))).
-
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 10/14] serial/crisv10: replace schedule_timeout() with msleep()
[EMAIL PROTECTED] wrote:
>
> Use msleep() instead of schedule_timeout() to guarantee the task
> delays as expected. The current code uses TASK_INTERRUPTIBLE, but does not
> care
> about signals, so I believe msleep() should be ok.
>
> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
> ---
>
>
> kj-domen/drivers/serial/crisv10.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff -puN drivers/serial/crisv10.c~msleep-drivers_serial_crisv10
> drivers/serial/crisv10.c
> --- kj/drivers/serial/crisv10.c~msleep-drivers_serial_crisv10
> 2005-03-05 16:10:52.0 +0100
> +++ kj-domen/drivers/serial/crisv10.c2005-03-05 16:10:52.0
> +0100
> @@ -3757,10 +3757,8 @@ rs_write(struct tty_struct * tty, int fr
> e100_enable_rx_irq(info);
> #endif
>
> -if (info->rs485.delay_rts_before_send > 0) {
> -set_current_state(TASK_INTERRUPTIBLE);
> -schedule_timeout((info->rs485.delay_rts_before_send *
> HZ)/1000);
> -}
> +if (info->rs485.delay_rts_before_send > 0)
> +msleep(info->rs485.delay_rts_before_send);
Behavioural change: we'll no longer break out of the sleep if a signal is
pending. Which probably means you fixed a bug ;)
Please work it with Mikael.
-
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: Page fault scalability patch V18: Overview
Hi Christoph On Sun, 06 Mar 2005, Christoph Lameter wrote: > On Mon, 7 Mar 2005, Darren Williams wrote: > > > Hi Christoph > > > > On Fri, 04 Mar 2005, Christoph Lameter wrote: > > > > > Make sure that scrubd_stop on startup is set to 2 and no zero in > > > mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. > > > > > unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ > > > > This is the assignment when page zero fails. > > Could you just test this with the prezeroing patches alone? > Include a dmesg from a successful boot and then tell me what > you changed and where the boot failed. Which version of the patches did > you apply? > PATCHES: ftp://oss.sgi.com/projects/page_fault_performance/download/prezero/patch/patchset-2.6.11/ No scrubd_stop cat /proc/sys/vm/scrub_stop 2 /etc/sysctl.conf vm.scrub_stop=2 CONFIG_SCRUBD =N=Y Boots OK FAILED Oops of failed prezero boot: /dev/sdb4 has been mounted 31 times without being checked, check forced.Unable to handle kernel NULL pointer dereference (address )% kscrubd0[362]: Oops 11012296146944 [1] Pid: 362, CPU 0, comm: kscrubd0 psr : 121008022038 ifs : 8308 ip : []Not tainted ip is at scrubd_rmpage+0x61/0x140 unat: pfs : 0308 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001000cf7f0 b6 : a0012d70 b7 : a0019ff0 f6 : 1003e6db6db6db6db6db7 f7 : 0fff4847277b8 f8 : 1003e1c07c8b4 f9 : 1003ec4367cec f10 : 10017a77079199649f035 f11 : 1003e014ee0f2 r1 : a00100a53d80 r2 : 00100100 r3 : e721fe04fdd0 r8 : 001008026038 r9 : e70020041070 r10 : 0008 r11 : 00200200 r12 : e721fe04fdc0 r13 : e721fe048000 r14 : r15 : fffd r16 : r17 : a0007fffabf48000 r18 : c000 r19 : r20 : efff r21 : 0001 r22 : 0002 r23 : r24 : r25 : r26 : r27 : 001008026038 r28 : e721fe04fdd0 r29 : a0007fffabf4a7e0 r30 : r31 : e70020041080 Call Trace: [] show_stack+0x80/0xa0 sp=e721fe04f980 bsp=e721fe049010 [] show_regs+0x7e0/0x800 sp=e721fe04fb50 bsp=e721fe048fa8 [] die+0x150/0x1c0 sp=e721fe04fb60 bsp=e721fe048f68 [] ia64_do_page_fault+0x370/0x980 sp=e721fe04fb60 bsp=e721fe048f00 [] ia64_leave_kernel+0x0/0x260 sp=e721fe04fbf0 bsp=e721fe048f00 [] scrubd_rmpage+0x60/0x140 sp=e721fe04fdc0 bsp=e721fe048ec0 [] zero_highest_order_page+0x120/0x2c0 sp=e721fe04fdc0 bsp=e721fe048e68 [] scrub_pgdat+0x110/0x1c0 sp=e721fe04fdd0 bsp=e721fe048e30 [] kscrubd+0x220/0x240 sp=e721fe04fdd0 bsp=e721fe048e00 [] kernel_thread_helper+0xd0/0x100 sp=e721fe04fe30 bsp=e721fe048dd0 [] start_kernel_thread+0x20/0x40 sp=e721fe04fe30 bsp=e721fe048dd0 <1>Unable to handle kernel NULL pointer dereference (address ) kscrubd1[363]: Oops 11012296146944 [2] Pid: 363, CPU 6, comm: kscrubd1 psr : 121008022018 ifs : 8308 ip : []Not tainted ip is at scrubd_rmpage+0x61/0x140 unat: pfs : 0308 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001000cf7f0 b6 : a0012d70 b7 : a0019ff0 f6 : 1003e6db6db6db6db6db7 f7 : 0fff68a476010 f8 : 1003e1c87f85a f9 : 1003ec7b7ca76 f10 : 100188a47600ff75b89ff f11 : 1003e02291d80 r1 : a00100a53d80 r2 : 00100100 r3 : e741fe427dd0 r8 : 001008026018 r9 : e72510f0 r10 : 0008 r11 : 00200200 r12 : e741fe427dc0 r13 : e741fe42 r14 : r15 : fffd r16 : r17 : a0007fffc7ff r18 : c000 r19 : r20 : efff r21 : 0001 r22 : 0001 r23 : r24 : r25 : r26 : r27 : 001008026018 r28 : e741fe427dd0 r29 : a0007fffc7ff13f8 r30 : r31 : e7251100 Call Trace: [] show_stack+0x80/0xa0
Re: [patch 05/14] char/hvsi: use wait_event_timeout()
[EMAIL PROTECTED] wrote:
>
> Please consider applying. This is my first wait-queue related patch, so
> comments
> are very welcome.
>
> Use wait_event_timeout() in place of custom wait-queue code. The
> code is not changed in any way (I don't think), but is cleaned up quite a bit
> (will get expanded to almost identical code).
>
> ...
> diff -puN drivers/char/hvsi.c~wait_event_timeout-drivers_char_hvsi
> drivers/char/hvsi.c
> --- kj/drivers/char/hvsi.c~wait_event_timeout-drivers_char_hvsi
> 2005-03-05 16:11:27.0 +0100
> +++ kj-domen/drivers/char/hvsi.c 2005-03-05 16:11:27.0 +0100
> @@ -44,6 +44,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -631,27 +632,10 @@ static int __init poll_for_state(struct
> /* wait for irq handler to change our state */
> static int wait_for_state(struct hvsi_struct *hp, int state)
> {
> -unsigned long end_jiffies = jiffies + HVSI_TIMEOUT;
> -unsigned long timeout;
> int ret = 0;
>
> -DECLARE_WAITQUEUE(myself, current);
> -set_current_state(TASK_INTERRUPTIBLE);
> -add_wait_queue(&hp->stateq, &myself);
> -
> -for (;;) {
> -set_current_state(TASK_INTERRUPTIBLE);
> -if (hp->state == state)
> -break;
> -timeout = end_jiffies - jiffies;
> -if (time_after(jiffies, end_jiffies)) {
> -ret = -EIO;
> -break;
> -}
> -schedule_timeout(timeout);
> -}
> -remove_wait_queue(&hp->stateq, &myself);
> -set_current_state(TASK_RUNNING);
> +if(!wait_event_timeout(hp->stateq, (hp->state == state), jiffies +
> HVSI_TIMEOUT))
> +ret = -EIO;
wait_event_timeout()'s `timeout' arg is number-of-milliseconds-to-wait,
not an absolute time, yes?
Also, it's conventional to put a space between the `if' and the `('.
It's nice to squeeze the code into an 80-column xterm, too.
-
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] inotify for 2.6.11
Christoph Hellwig writes: > On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote: >> On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote: >>> The user interface is still bogus. >> >> I presume you are talking about the ioctl. I have tried to engage you >> and others on what exactly you prefer instead. I have said that moving >> to a write interface is fine but I don't see how ut is _any_ better than >> the ioctl. Write is less typed, in fact, since we lose the command >> versus argument delineation. >> >> But if it is a anonymous decision, I'll switch it. Or take patches. ;-) >> It isn't a big deal. > > See the review I sent. Write is exactly the right interface for that kind > of thing. For comment vs argument either put the number first so we don't > have the problem of finding a delinator that isn't a valid filename, or > use '\0' as such. That's just putrid. You've proposed an interface that combines the worst of ASCII with the worst of binary. It is now well-established that ASCII interfaces are horribly slow. This one will be no exception... but with the '\0' in there, you have a binary interface. So, it's an evil hybrid. An ioctl() is a syscall with scope restricting it to a single fd. This is a fine user interface, not a bogus one. (keep 32-on-64 operation in mind to be polite) If you'd rather have a normal (global) system call though, that'll do too, likely leading to a bit more type checking in the glibc-provided headers. Adding plain old syscalls is rather nice actually. It's only a pain at first, while waiting for glibc to catch up. - 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: Slowdown on 3000 socket-machines tracked down
Christian Schmid wrote: Ben Greear wrote: I have a tool that can also generate TCP traffic on a large number of sockets. If I can understand what you are trying to do, I may be able to reproduce the problem. My biggest machine at present has only 2GB of RAM, however...not sure if that matters or not. It should not matter. Low-memory is both just 1 GB if you have default 32 bit with 3/1 split. Are you sending traffic in only one direction, or more of a full-duplex configuration? Its a full-duplex. Its a download-service with 3000 downloaders all over the world. So actually it's really mostly one-way traffic, ie in the download direction. Anything significant at all going upstream, other than ACKs, etc? Is each socket running the same bandwidth? No. It ranges from 3 kb/sec to 100 kb/sec. 100 kb/sec is the limit because of the send-buffer limits. What is this bandwidth? 1000 MBit Are you setting the send & rcv buffers in the socket creation code? (To what values if so?) Yes. send-buffer to 64 kbytes and receive buffer to 16 kbytes. With regard to this note in the 'man 7 socket' man page: NOTES Linux assumes that half of the send/receive buffer is used for internal kernel struc- tures; thus the sysctls are twice what can be observed on the wire. What value are you using for the sockopt call? How many bytes are you sending with each call to write()/sendto() whatever? I am using sendfile-call every 100 ms per socket with the poll-api. So basically around 40 kb per round. My application is single-threaded, uses non-blocking IO, and sends/rcvs from/to memory. It will be a good test of the TCP stack, but will not use the sendfile logic, nor will it touch the HD. Is there any significant latency between your sender and receiver machine? If so, how much? 3000 different downloaders, 3000 different locations, 3000 different machines ;) I can emulate delay if I need to, but I'd rather just stick with one delay setting and not have to set up a separate delay for each connection. Maybe 30ms is average for round-trip time? Have you tried benchmarking your app in a controlled manner, or are you just letting a random 3000 machines hit it and start downloading? If the latter, then I'd suggest getting more controll over your testing environment, otherwise it may be impossible to really figure out where the problem lies. I'll set up a configuration similar to the values discussed above and see what I can see. Will probably be late tomorrow before I can do the test though... Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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: BUG: Slowdown on 3000 socket-machines tracked down
I have a tool that can also generate TCP traffic on a large number of
sockets. If I can understand what you are trying to do, I may be able
to reproduce the problem. My biggest machine at present has only
2GB of RAM, however...not sure if that matters or not.
But if the problem is what I think it is, you should get the problem by
doing the following.
Best use 2.6.11 since the problem got even worse there compared to 2.6.10.
Create a server on one machine. This server should wait for incoming sockets and when they come,
just send out bytes ("x" or whatever, it just doesn't matter) to that sockets. Please use a
send-buffer of 64 kbytes.
On the other machine you just create clients, which connect to the server and read the data. They
just need to read them, nothing more. Please limit the reading to once per 300 ms, so they only read
around 200 kb/sec each. Then watch your traffic as you create more sockets. When you reach 2000
sockets on 2.6.11, it should slow down more and more. You should see the same like me on the
attached graph.
First one 2.6.11, second one 2.6.10
Chris
<>
Re: BUG: Slowdown on 3000 socket-machines tracked down
Ben Greear wrote: Christian Schmid wrote: Hello. After weeks of work, I can now give a detailed report about the bug and when it appears: Attached is another traffic-image. This one is with 2.6.10 and a 3/1 split, preemtive kernel, so all defaults. What are the units on your graph. You say "MB" several places, but do you mean Mb (ie, Mega-bit) instead? The unit on this graph is kilobytes. So 8 there means 80 megabytes per second. I have a tool that can also generate TCP traffic on a large number of sockets. If I can understand what you are trying to do, I may be able to reproduce the problem. My biggest machine at present has only 2GB of RAM, however...not sure if that matters or not. It should not matter. Low-memory is both just 1 GB if you have default 32 bit with 3/1 split. Are you sending traffic in only one direction, or more of a full-duplex configuration? Its a full-duplex. Its a download-service with 3000 downloaders all over the world. Is each socket running the same bandwidth? No. It ranges from 3 kb/sec to 100 kb/sec. 100 kb/sec is the limit because of the send-buffer limits. What is this bandwidth? 1000 MBit Are you setting the send & rcv buffers in the socket creation code? (To what values if so?) Yes. send-buffer to 64 kbytes and receive buffer to 16 kbytes. How many bytes are you sending with each call to write()/sendto() whatever? I am using sendfile-call every 100 ms per socket with the poll-api. So basically around 40 kb per round. Is there any significant latency between your sender and receiver machine? If so, how much? 3000 different downloaders, 3000 different locations, 3000 different machines ;) What is the physical transport...GigE? 1500 MTU? Yes. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] inotify for 2.6.11-mm1
Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > -mm has a list of inodes per superblock, which Andrew said he'd send > along to lines, you should probably use that one. That was merged a month or two ago. superblock.s_inodes, linked via inode.i_sb_list, protected by inode_lock. - 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] inotify for 2.6.11
On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote: > On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote: > > > The user interface is still bogus. > > I presume you are talking about the ioctl. I have tried to engage you > and others on what exactly you prefer instead. I have said that moving > to a write interface is fine but I don't see how ut is _any_ better than > the ioctl. Write is less typed, in fact, since we lose the command > versus argument delineation. > > But if it is a anonymous decision, I'll switch it. Or take patches. ;-) > It isn't a big deal. See the review I sent. Write is exactly the right interface for that kind of thing. For comment vs argument either put the number first so we don't have the problem of finding a delinator that isn't a valid filename, or use '\0' as such. > > Also now version of it has stayed in -mm long enough because bad > > bugs pop up almost weekly. > > I don't follow this sentence. It means that every re3vision of inotify so far has been buggy in some respect and ig got dropped from -mm again and again. It should get some more testing there and not sent firectly for mainline. - 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] irq and softirq handler measurement
Hi, The supplied address of the patch was wrong, because the trailing dot of the finished sentence corrupted the URL in the LKML archive. Correct URL: http://friends.s5.net/pogacnik/patch-2.6.0-test11-usage-0.1 -- Samo - 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] inotify for 2.6.11-mm1
> - if ((ret + (type == READ)) > 0)
> - dnotify_parent(file->f_dentry,
> - (type == READ) ? DN_ACCESS : DN_MODIFY);
> + if ((ret + (type == READ)) > 0) {
> + struct dentry *dentry = file->f_dentry;
> + if (type == READ)
> + fsnotify_access(dentry, dentry->d_inode,
> + dentry->d_name.name);
> + else
> + fsnotify_modify(dentry, dentry->d_inode,
> + dentry->d_name.name);
> + }
Both fsnotify_access and fsnotify_modify always get the second argument
as ->d_inode and third argument as ->d_name.name of the first, please fix
this blatantly stupid API.
> + fsnotify_close(dentry, inode, file->f_mode, dentry->d_name.name);
dito for thw second and last argument here.. In fact fsnotify_close
should just get a struct file *
> might_sleep();
this one seems totally unrelated.
> +/*
> + * struct inotify_device - represents an open instance of an inotify device
> + *
> + * This structure is protected by 'lock'.
> + */
> +struct inotify_device {
> + wait_queue_head_t wq; /* wait queue for i/o */
> + struct idr idr;/* idr mapping wd -> watch */
> + struct list_headevents; /* list of queued events */
> + struct list_headwatches;/* list of watches */
> + spinlock_t lock; /* protects this bad boy */
> + atomic_tcount; /* reference count */
> + struct user_struct *user; /* user who opened this dev */
> + unsigned intqueue_size; /* size of the queue (bytes) */
> + unsigned intevent_count;/* number of pending events */
> + unsigned intmax_events; /* maximum number of events */
> +};
> +/*
> + * kernel_event - create a new kernel event with the given parameters
> + */
> +static struct inotify_kernel_event * kernel_event(s32 wd, u32 mask, u32
> cookie,
> + const char *name)
> +{
> + struct inotify_kernel_event *kevent;
> +
> + /* XXX: optimally, we should use GFP_KERNEL */
> + kevent = kmem_cache_alloc(event_cachep, GFP_ATOMIC);
indeed. having a new atomic memory allocation in every filesystem operation
sounds like a really bad idea.
> + /* XXX: optimally, we should use GFP_KERNEL */
> + kevent->name = kmalloc(len, GFP_ATOMIC);
and two is even worse. A notification that fails under slight load
isn't that helpfull.
> +static inline int inotify_dev_has_events(struct inotify_device *dev)
> +{
> + return !list_empty(&dev->events);
> +}
just remove this bit of obsfucation.
> + if (kevent->name)
> + kfree(kevent->name);
kfree(NULL) is just fine.
> +
> +repeat:
> + if (unlikely(!idr_pre_get(&dev->idr, GFP_KERNEL)))
> + return -ENOSPC;
> + spin_lock(&dev->lock);
> + ret = idr_get_new(&dev->idr, watch, &watch->wd);
> + spin_unlock(&dev->lock);
> + if (ret == -EAGAIN) /* more memory is required, try again */
> + goto repeat;
what's the problem with a proper do { } while loop here?
> + watch->inode = inode;
> + spin_lock(&inode_lock);
> + __iget(inode);
> + spin_unlock(&inode_lock);
do you ever calls this when igrab() would fail? Don't think so,
and in that case I'd prefer you to use igrab instead of using these
lowlevel functions.
> +void inotify_dentry_parent_queue_event(struct dentry *dentry, u32 mask,
> +u32 cookie, const char *name)
> +{
> + struct dentry *parent;
> + struct inode *inode;
> +
> + spin_lock(&dentry->d_lock);
> + parent = dentry->d_parent;
> + inode = parent->d_inode;
> + if (!list_empty(&inode->inotify_watches)) {
So what's protecting ->inotify_watches? There can be multiple dentries
so d_lock is not sufficient.
> +
> +/**
> + * inotify_super_block_umount - process watches on an unmounted fs
> + * @sb: the super_block of the filesystem in question
> + */
> +void inotify_super_block_umount(struct super_block *sb)
> +{
> + struct inode *inode;
> +
> + /* Walk the list of inodes and find those on this superblock */
> + spin_lock(&inode_lock);
> + list_for_each_entry(inode, &inode_in_use, i_list) {
> + struct inotify_watch *watch, *next;
> + struct list_head *watches;
> +
> + if (inode->i_sb != sb)
> + continue;
> +
> + /* for each watch, send IN_UNMOUNT and then remove it */
> + spin_lock(&inode->inotify_lock);
> + watches = &inode->inotify_watches;
> + list_for_each_entry_safe(watch, next, watches, i_list) {
> + struct inotify_device *dev = watch->dev;
> + spin_lock(&dev->lock);
> +
Re: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header
Leo Yuriev wrote: Kernel 2.6 (2.6.11) When ethernet-bridge forward a packet and such ethernet-frame has VLAN-tag, bridge should update skb->prioriry for properly QoS handling. This small patch does this. Currently vlan_TCI-priority directly mapped to skb->priority, but this looks enough. If this packet came in from an 802.1Q VLAN device, the VLAN code already has the logic necessary to map the .1q priority to an arbitrary skb->priority. See the vconfig commands: set_egress_map [vlan-name] [skb_priority] [vlan_qos] set_ingress_map [vlan-name] [skb_priority] [vlan_qos] Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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: BUG: Slowdown on 3000 socket-machines tracked down
Christian Schmid wrote: Hello. After weeks of work, I can now give a detailed report about the bug and when it appears: Attached is another traffic-image. This one is with 2.6.10 and a 3/1 split, preemtive kernel, so all defaults. What are the units on your graph. You say "MB" several places, but do you mean Mb (ie, Mega-bit) instead? I have a tool that can also generate TCP traffic on a large number of sockets. If I can understand what you are trying to do, I may be able to reproduce the problem. My biggest machine at present has only 2GB of RAM, however...not sure if that matters or not. Are you sending traffic in only one direction, or more of a full-duplex configuration? Is each socket running the same bandwidth? What is this bandwidth? Are you setting the send & rcv buffers in the socket creation code? (To what values if so?) How many bytes are you sending with each call to write()/sendto() whatever? Is there any significant latency between your sender and receiver machine? If so, how much? What is the physical transport...GigE? 1500 MTU? Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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: [PATCH 2.6.11-mm1] mtd: fix INFTL failure handling
Hi Panagiotis,
Panagiotis Issaris wrote:
The INFTL mount code contains a kmalloc() followed by a memset() without
handling a possible memory allocation failure.
Signed-off-by: <[EMAIL PROTECTED]>
OK, that looks good.
Dave do you want to take this, or do you want me to submit it?
Regards
Greg
diff -pruN linux-2.6.11-orig/drivers/mtd/inftlmount.c linux-2.6.11-pi/drivers/mtd/inftlmount.c
--- linux-2.6.11-orig/drivers/mtd/inftlmount.c 2005-03-05 03:08:52.0 +0100
+++ linux-2.6.11-pi/drivers/mtd/inftlmount.c 2005-03-06 18:17:15.0 +0100
@@ -574,6 +574,12 @@ int INFTL_mount(struct INFTLrecord *s)
/* Temporary buffer to store ANAC numbers. */
ANACtable = kmalloc(s->nb_blocks * sizeof(u8), GFP_KERNEL);
+ if (!ANACtable) {
+ printk(KERN_WARNING "INFTL: allocation of ANACtable "
+"failed (%zd bytes)\n",
+s->nb_blocks * sizeof(u8));
+ return -ENOMEM;
+ }
memset(ANACtable, 0, s->nb_blocks);
/*
--
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a CyberGuard CompanyPHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.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: [PATCH] FAT: Support synchronous update
OGAWA Hirofumi <[EMAIL PROTECTED]> wrote: > > Hi, > > These patches adds the `-o sync' and `-o dirsync' supports to fatfs. > If user specified that option, the fatfs does traditional ordered > updates by using synchronous writes. If compared to before, these > patches will show a improvement of robustness I think. > > `-o sync'- writes all buffers out before returning from syscall. > `-o dirsync' - writes the directory's metadata, and unreferencing >operations of data block. > > remaining to be done > fat_generic_ioctl(), fat_notify_change(), >ATTR_ARCH of fat_xxx_write[v], >and probably, filling hole in cont_prepare_write(), > > NOTE: Since fatfs doesn't have link-count, unfortunately ->rename() is > not safe order at all. It may make the shared blocks, but user > shouldn't lose the data by ->rename(). > > Please apply. > > > If you test this, please use attached dosfstools. This is fixing > several bugs of dosfstools. And "2/29" patch from hpa adds new ioctl, > the attached archive is also including the commands for testing it. > -- > OGAWA Hirofumi <[EMAIL PROTECTED]> > > OK. This email was way too big for linux-kernel, so nobody saw it. I put the modified fatfsprogs at http://www.zip.com.au/~akpm/linux/patches/stuff/fatfsprogs.tar.bz2 and updated the changlog to mention that. Is there an official place where people should go to download the modified fatfsprogs? - 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 breaks ALSA Intel AC97 audio
On Mon, 2005-03-07 at 11:09 +1100, Michael Ellerman wrote: > Hi Lars, > > Yeah I've got no audio on my T41, which I think uses the AC97 too. I haven't > had time to look into it though :/ > Did you disable "Headphone Jack Sense" and "Line Jack Sense" in alsamixer? Lee - 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] Consolidate compat_sys_waitid
Hi Andrew, Linus,
This patch does:
- consolidate the three implementations of compat_sys_waitid
(some were called sys32_waitid).
- adds sys_waitid syscall to ppc
- adds sys_waitid and compat_sys_waitid syscalls to ppc64
I have left PARISC and MIPS to their own devices (by request).
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
Diffstat looks like this:
arch/ia64/ia32/ia32_entry.S |2 +-
arch/ia64/ia32/sys_ia32.c | 26 --
arch/ppc/kernel/misc.S|1 +
arch/ppc64/kernel/misc.S |2 ++
arch/sparc64/kernel/sys_sparc32.c | 31 ---
arch/x86_64/ia32/ia32entry.S |2 +-
arch/x86_64/ia32/sys_ia32.c | 26 --
include/asm-ppc/unistd.h |3 ++-
include/asm-ppc64/unistd.h|3 ++-
include/linux/compat.h|7 ++-
kernel/compat.c | 31 +++
11 files changed, 46 insertions(+), 88 deletions(-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
diff -ruNp linus/arch/ia64/ia32/ia32_entry.S
linus-waitid.1/arch/ia64/ia32/ia32_entry.S
--- linus/arch/ia64/ia32/ia32_entry.S 2005-01-16 07:07:51.0 +1100
+++ linus-waitid.1/arch/ia64/ia32/ia32_entry.S 2005-03-07 10:58:57.0
+1100
@@ -494,7 +494,7 @@ ia32_syscall_table:
data8 compat_sys_mq_notify
data8 compat_sys_mq_getsetattr
data8 sys_ni_syscall/* reserved for kexec */
- data8 sys32_waitid
+ data8 compat_sys_waitid
// guard against failures to increase IA32_NR_syscalls
.org ia32_syscall_table + 8*IA32_NR_syscalls
diff -ruNp linus/arch/ia64/ia32/sys_ia32.c
linus-waitid.1/arch/ia64/ia32/sys_ia32.c
--- linus/arch/ia64/ia32/sys_ia32.c 2005-02-11 13:05:29.0 +1100
+++ linus-waitid.1/arch/ia64/ia32/sys_ia32.c2005-03-07 10:58:57.0
+1100
@@ -2633,32 +2633,6 @@ long sys32_fadvise64_64(int fd, __u32 of
advice);
}
-asmlinkage long sys32_waitid(int which, compat_pid_t pid,
-compat_siginfo_t __user *uinfo, int options,
-struct compat_rusage __user *uru)
-{
- siginfo_t info;
- struct rusage ru;
- long ret;
- mm_segment_t old_fs = get_fs();
-
- info.si_signo = 0;
- set_fs (KERNEL_DS);
- ret = sys_waitid(which, pid, (siginfo_t __user *) &info, options,
-uru ? (struct rusage __user *) &ru : NULL);
- set_fs (old_fs);
-
- if (ret < 0 || info.si_signo == 0)
- return ret;
-
- if (uru && (ret = put_compat_rusage(&ru, uru)))
- return ret;
-
- BUG_ON(info.si_code & __SI_MASK);
- info.si_code |= __SI_CHLD;
- return copy_siginfo_to_user32(uinfo, &info);
-}
-
#ifdef NOTYET /* UNTESTED FOR IA64 FROM HERE DOWN */
asmlinkage long sys32_setreuid(compat_uid_t ruid, compat_uid_t euid)
diff -ruNp linus/arch/ppc/kernel/misc.S linus-waitid.1/arch/ppc/kernel/misc.S
--- linus/arch/ppc/kernel/misc.S2005-01-04 17:05:28.0 +1100
+++ linus-waitid.1/arch/ppc/kernel/misc.S 2005-03-07 10:58:58.0
+1100
@@ -1450,3 +1450,4 @@ _GLOBAL(sys_call_table)
.long sys_add_key
.long sys_request_key /* 270 */
.long sys_keyctl
+ .long sys_waitid
diff -ruNp linus/arch/ppc64/kernel/misc.S
linus-waitid.1/arch/ppc64/kernel/misc.S
--- linus/arch/ppc64/kernel/misc.S 2005-01-16 07:07:51.0 +1100
+++ linus-waitid.1/arch/ppc64/kernel/misc.S 2005-03-07 10:58:58.0
+1100
@@ -939,6 +939,7 @@ _GLOBAL(sys_call_table32)
.llong .sys32_add_key
.llong .sys32_request_key
.llong .compat_sys_keyctl
+ .llong .compat_sys_waitid
.balign 8
_GLOBAL(sys_call_table)
@@ -1214,3 +1215,4 @@ _GLOBAL(sys_call_table)
.llong .sys_add_key
.llong .sys_request_key /* 270 */
.llong .sys_keyctl
+ .llong .sys_waitid
diff -ruNp linus/arch/sparc64/kernel/sys_sparc32.c
linus-waitid.1/arch/sparc64/kernel/sys_sparc32.c
--- linus/arch/sparc64/kernel/sys_sparc32.c 2005-02-19 07:06:16.0
+1100
+++ linus-waitid.1/arch/sparc64/kernel/sys_sparc32.c2005-03-07
10:58:58.0 +1100
@@ -1121,34 +1121,3 @@ sys32_timer_create(u32 clock, struct sig
return err;
}
-
-asmlinkage long compat_sys_waitid(u32 which, u32 pid,
- struct compat_siginfo __user *uinfo,
- u32 options, struct compat_rusage __user *uru)
-{
- siginfo_t info;
- struct rusage ru;
- long ret;
- mm_segment_t old_fs = get_fs();
-
- memset(&info, 0, sizeof(info));
-
- set_fs (KERNEL_DS);
- ret = sys_waitid(which, pid, (siginfo_t __user *) &info,
-options,
-
[PATCH] Treat ALPS mouse buttons as mouse buttons
The following patch changes the ALPS touchpad driver to treat some mouse buttons as mouse buttons rather than what appears to be joystick buttons. This is needed for the Dell Inspiron 8500's DualPoint stick buttons. Without this patch only the touchpad buttons behave properly. --- linux-2.6.11/drivers/input/mouse/alps.c 2005-03-01 23:38:13.0 -0800 +++ linux-2.6.11-gentoo-r2/drivers/input/mouse/alps.c 2005-03-06 16:45:07.0 -0800 @@ -97,8 +97,8 @@ input_report_rel(dev, REL_X, x); input_report_rel(dev, REL_Y, -y); - input_report_key(dev, BTN_A, left); - input_report_key(dev, BTN_B, right); + input_report_key(dev, BTN_LEFT, left); + input_report_key(dev, BTN_RIGHT, right); input_sync(dev); return; } @@ -389,8 +389,6 @@ psmouse->dev.evbit[LONG(EV_REL)] |= BIT(EV_REL); psmouse->dev.relbit[LONG(REL_X)] |= BIT(REL_X); psmouse->dev.relbit[LONG(REL_Y)] |= BIT(REL_Y); - psmouse->dev.keybit[LONG(BTN_A)] |= BIT(BTN_A); - psmouse->dev.keybit[LONG(BTN_B)] |= BIT(BTN_B); psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0); -- Michael Marineau [EMAIL PROTECTED] Oregon State University signature.asc Description: OpenPGP digital signature
Re: [patch 11/12] sound/oss/emu10k1/* - compile warning cleanup
[EMAIL PROTECTED] wrote:
>
> @@ -316,7 +320,10 @@ static void copy_block(u8 __user *dst, u
>
> for (i = 0; i < len; i++) {
> byte = src[2 * i] ^ 0x80;
> - __copy_to_user(dst + i, &byte, 1);
> + if (__copy_to_user(dst + i, &byte, 1)) {
> + printk( KERN_ERR "emu10k1: %s: copy_to_user
> failed\n",__FUNCTION__);
> + return;
> + }
> }
This allows users to spam the logs without bounds, which is normally
something we try to avoid. If it's a privileged operation then OK. But it
would be better to propagate an error back to userspace.
I'll drop the patch for now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 11/12] sound/oss/emu10k1/* - compile warning cleanup
[EMAIL PROTECTED] wrote:
>
>
> compile warning cleanup - handle copy_to/from_user error
> returns
If a write() gets a fault it's supposed to return the number of bytes which
it actually wrote, which may be zero.
Still, returning -EFAULT is better than appearing to have succeeded.
> + printk( KERN_ERR "emu10k1: %s: copy_to_user
> failed\n",__FUNCTION__);
Someone needs to read Documentation/CodingStyle. I'll change these to
printk(KERN_ERR "emu10k1: %s: copy_to_user failed\n", __FUNCTION__);
> + return;
> + }
> + }
> else {
> u8 byte;
> u32 i;
> @@ -316,7 +320,10 @@ static void copy_block(u8 __user *dst, u
>
> for (i = 0; i < len; i++) {
> byte = src[2 * i] ^ 0x80;
> - __copy_to_user(dst + i, &byte, 1);
> + if (__copy_to_user(dst + i, &byte, 1)) {
> + printk( KERN_ERR "emu10k1: %s: copy_to_user
> failed\n",__FUNCTION__);
> + return;
> + }
> }
> }
> }
> diff -puN sound/oss/emu10k1/passthrough.c~return_code-sound_oss_emu10k1
> sound/oss/emu10k1/passthrough.c
> --- kj/sound/oss/emu10k1/passthrough.c~return_code-sound_oss_emu10k1
> 2005-03-05 16:13:11.0 +0100
> +++ kj-domen/sound/oss/emu10k1/passthrough.c 2005-03-05 16:13:11.0
> +0100
> @@ -162,12 +162,14 @@ ssize_t emu10k1_pt_write(struct file *fi
>
> DPD(3, "prepend size %d, prepending %d bytes\n",
> pt->prepend_size, needed);
> if (count < needed) {
> - copy_from_user(pt->buf + pt->prepend_size, buffer,
> count);
> + if (copy_from_user(pt->buf + pt->prepend_size, buffer,
> count))
> + return -EFAULT;
> pt->prepend_size += count;
> DPD(3, "prepend size now %d\n", pt->prepend_size);
> return count;
> }
> - copy_from_user(pt->buf + pt->prepend_size, buffer, needed);
> + if (copy_from_user(pt->buf + pt->prepend_size, buffer, needed))
> + return -EFAULT;
> r = pt_putblock(wave_dev, (u16 *) pt->buf, nonblock);
> if (r)
> return r;
> @@ -178,7 +180,8 @@ ssize_t emu10k1_pt_write(struct file *fi
> blocks_copied = 0;
> while (blocks > 0) {
> u16 __user *bufptr = (u16 __user *) buffer + (bytes_copied/2);
> - copy_from_user(pt->buf, bufptr, PT_BLOCKSIZE);
> + if (copy_from_user(pt->buf, bufptr, PT_BLOCKSIZE))
> + return -EFAULT;
> r = pt_putblock(wave_dev, (u16 *)pt->buf, nonblock);
> if (r) {
> if (bytes_copied)
> @@ -193,7 +196,8 @@ ssize_t emu10k1_pt_write(struct file *fi
> i = count - bytes_copied;
> if (i) {
> pt->prepend_size = i;
> - copy_from_user(pt->buf, buffer + bytes_copied, i);
> + if (copy_from_user(pt->buf, buffer + bytes_copied, i))
> + return -EFAULT;
> bytes_copied += i;
> DPD(3, "filling prepend buffer with %d bytes", i);
> }
> _
-
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 10/12] arch/i386/math-emu/* - compile warning cleanup
[EMAIL PROTECTED] wrote:
>
>
> compile warning cleanup - handle copy_to/from_user error
> returns
>
We made some changes like this in there a while back, and things broke
subtly. I'd prefer that someone who remembers how this code works take a
good look at this. But I don't think anyone remembers how this code works.
>
> diff -puN arch/i386/math-emu/fpu_entry.c~return_code-arch_i386_math-emu
> arch/i386/math-emu/fpu_entry.c
> --- kj/arch/i386/math-emu/fpu_entry.c~return_code-arch_i386_math-emu
> 2005-03-05 16:13:04.0 +0100
> +++ kj-domen/arch/i386/math-emu/fpu_entry.c 2005-03-05 16:13:04.0
> +0100
> @@ -742,7 +742,8 @@ int save_i387_soft(void *s387, struct _f
>S387->fcs &= ~0xf800;
>S387->fos |= 0x;
> #endif /* PECULIAR_486 */
> - __copy_to_user(d, &S387->cwd, 7*4);
> + if (__copy_to_user(d, &S387->cwd, 7*4))
> +return -1;
>RE_ENTRANT_CHECK_ON;
>
>d += 7*4;
> diff -puN arch/i386/math-emu/reg_ld_str.c~return_code-arch_i386_math-emu
> arch/i386/math-emu/reg_ld_str.c
> --- kj/arch/i386/math-emu/reg_ld_str.c~return_code-arch_i386_math-emu
> 2005-03-05 16:13:04.0 +0100
> +++ kj-domen/arch/i386/math-emu/reg_ld_str.c 2005-03-05 16:13:04.0
> +0100
> @@ -89,12 +89,17 @@ int FPU_tagof(FPU_REG *ptr)
> int FPU_load_extended(long double __user *s, int stnr)
> {
>FPU_REG *sti_ptr = &st(stnr);
> + int user_copy_err;
>
>RE_ENTRANT_CHECK_OFF;
>FPU_verify_area(VERIFY_READ, s, 10);
> - __copy_from_user(sti_ptr, s, 10);
> + user_copy_err = __copy_from_user(sti_ptr, s, 10);
>RE_ENTRANT_CHECK_ON;
>
> + if (user_copy_err) {
> + EXCEPTION(EX_INTERNAL);
> + return TAG_Special;
> + }
>return FPU_tagof(sti_ptr);
> }
>
> @@ -240,13 +245,19 @@ int FPU_load_int64(long long __user *_s)
> {
>long long s;
>int sign;
> + int user_copy_err;
>FPU_REG *st0_ptr = &st(0);
>
>RE_ENTRANT_CHECK_OFF;
>FPU_verify_area(VERIFY_READ, _s, 8);
> - copy_from_user(&s,_s,8);
> + user_copy_err = copy_from_user(&s,_s,8);
>RE_ENTRANT_CHECK_ON;
>
> + if (user_copy_err) {
> + EXCEPTION(EX_INTERNAL);
> + return TAG_Special;
> + }
> +
>if (s == 0)
> {
>reg_copy(&CONST_Z, st0_ptr);
> @@ -859,6 +870,7 @@ int FPU_store_int64(FPU_REG *st0_ptr, u_
>FPU_REG t;
>long long tll;
>int precision_loss;
> + int user_copy_err;
>
>if ( st0_tag == TAG_Empty )
> {
> @@ -907,9 +919,14 @@ int FPU_store_int64(FPU_REG *st0_ptr, u_
>
>RE_ENTRANT_CHECK_OFF;
>FPU_verify_area(VERIFY_WRITE,d,8);
> - copy_to_user(d, &tll, 8);
> + user_copy_err = copy_to_user(d, &tll, 8);
>RE_ENTRANT_CHECK_ON;
>
> + if (user_copy_err) {
> + EXCEPTION(EX_INTERNAL);
> + return 0;
> + }
> +
>return 1;
> }
>
> @@ -1271,15 +1288,21 @@ void frstor(fpu_addr_modes addr_modes, u
>int i, regnr;
>u_char __user *s = fldenv(addr_modes, data_address);
>int offset = (top & 7) * 10, other = 80 - offset;
> + int user_copy_err;
>
>/* Copy all registers in stack order. */
>RE_ENTRANT_CHECK_OFF;
>FPU_verify_area(VERIFY_READ,s,80);
> - __copy_from_user(register_base+offset, s, other);
> - if ( offset )
> -__copy_from_user(register_base, s+other, offset);
> + user_copy_err = __copy_from_user(register_base+offset, s, other);
> + if (!user_copy_err && offset)
> +user_copy_err = __copy_from_user(register_base, s+other, offset);
>RE_ENTRANT_CHECK_ON;
>
> + if (user_copy_err) {
> + EXCEPTION(EX_INTERNAL);
> + return;
> + }
> +
>for ( i = 0; i < 8; i++ )
> {
>regnr = (i+top) & 7;
> @@ -1325,6 +1348,7 @@ u_char __user *fstenv(fpu_addr_modes add
> }
>else
> {
> + int user_copy_err;
>RE_ENTRANT_CHECK_OFF;
>FPU_verify_area(VERIFY_WRITE, d, 7*4);
> #ifdef PECULIAR_486
> @@ -1336,8 +1360,12 @@ u_char __user *fstenv(fpu_addr_modes add
>I387.soft.fcs &= ~0xf800;
>I387.soft.fos |= 0x;
> #endif /* PECULIAR_486 */
> - __copy_to_user(d, &control_word, 7*4);
> + user_copy_err = __copy_to_user(d, &control_word, 7*4);
>RE_ENTRANT_CHECK_ON;
> +
> + if (user_copy_err)
> + EXCEPTION(EX_INTERNAL);
> +
>d += 0x1c;
> }
>
> @@ -1352,6 +1380,7 @@ void fsave(fpu_addr_modes addr_modes, u_
> {
>u_char __user *d;
>int offset = (top & 7) * 10, other = 80 - offset;
> + int user_copy_err;
>
>d = fstenv(addr_modes, data_address);
>
> @@ -1359,11 +1388,14 @@ void fsave(fpu_addr_modes addr_modes, u_
>FPU_verify_area(VERIFY_WRITE,d,80);
>
>/* Copy all registers in stack order. */
> - __copy_to_user(d, register_base+offset, other);
> - if ( offset )
> -__copy_to_user(d+other, register_base, offset);
> + user_copy_err = __copy_to_user(d, register_base+offset, other);
> + if (!user_copy_err && offset)
> +user_copy_err = __copy_to_user(d+other, register_base, offset);
>RE_ENTRANT_CHECK_ON;
>
> + if (user_
Re: BUG: Slowdown on 3000 socket-machines tracked down
Christian Schmid wrote: Today I tested with 5000 sockets. The problem is the same like above but the more sockets there come, it just doesnt claim more bandwidth as it SHOULD of course do. It seems it doesn't slow down but it just doesnt scale anymore. The badwidth doesnt go over 80 MB/Sec, no matter what I do. Then I did the following: I raised lower_zone_protection to 1024 (above I did 1024000 which is bullshit but it doesnt matter as it seems to just protect the whole low-mem which is what I want) and it was at 80 MB. then I lowered to 0 again and suddenly it peaked up to full bandwidth (100 MB) for about 5 seconds until the whole protected area was in use. Then it slowed down drastically again. This confirms my suspicion that lowmem / highmem scanning is not properly balanced. When you raise lower_zone_protection a great deal, lowmem is no longer used for pagecache, and your problem goes away. I gave you a patch to try for this - unfortunately I can't make much more progress than that if I don't have a test case and you can't test patches :\ Nick - 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 09/12] include/linux/module.h - compile warning cleanup
[EMAIL PROTECTED] wrote: > > , extinguish warning for module structure that is still > live when module is compiled into the kernel; do this in one central > place so all such type warnings are automatically taken care of > > Signed-off-by: Stephen Biggs <[EMAIL PROTECTED]> > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> > --- > > > kj-domen/include/linux/module.h |5 - > 1 files changed, 4 insertions(+), 1 deletion(-) > > diff -puN include/linux/module.h~extinguish_warnings-include_linux_module.h > include/linux/module.h > --- kj/include/linux/module.h~extinguish_warnings-include_linux_module.h > 2005-03-05 16:12:03.0 +0100 > +++ kj-domen/include/linux/module.h 2005-03-05 16:12:03.0 +0100 > @@ -93,7 +93,10 @@ extern struct module __this_module; > > #else /* !MODULE */ > > -#define MODULE_GENERIC_TABLE(gtype,name) > +#define MODULE_GENERIC_TABLE(gtype,name) \ > +extern const struct gtype##_id __not_mod_##name##_unused \ > + __attribute__ ((unused, weak, alias(__stringify(name > + There's already a patch similar to this in Sam's bk-kbuild tree. - 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: More trouble with i386 EFLAGS and ptrace
On Sun, 6 Mar 2005, Daniel Jacobowitz wrote: > > I bought it, but the GDB testsuite didn't. Both copies seem to be > necessary; there's generally no signal handler for SIGTRAP Ahh, duh, yes. I was looking at it and saying "debug fault always generates a sigtrap", but you're right, it obviously doesn't - usually it's caught by the tracer. Your patch looks fine. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/12] Re: radio-sf16fmi cleanup
[EMAIL PROTECTED] wrote:
>
>
> This is small cleanup of radio-sf16fmi driver.
Well, yes, but it is a functional change, no?
Previously the kernel accepted the `sf16fm=' option. Now the users must
switch over to, umm, `radio-sf16fmi.io=', yes?
> Signed-off-by: Marcel Sebek <[EMAIL PROTECTED]>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
> ---
>
>
> kj-domen/Documentation/kernel-parameters.txt |3 ---
> kj-domen/drivers/media/radio/radio-sf16fmi.c | 10 --
> 2 files changed, 13 deletions(-)
>
> diff -puN Documentation/kernel-parameters.txt~kill_kernel_parameter-sf16fm
> Documentation/kernel-parameters.txt
> --- kj/Documentation/kernel-parameters.txt~kill_kernel_parameter-sf16fm
> 2005-03-05 16:11:31.0 +0100
> +++ kj-domen/Documentation/kernel-parameters.txt 2005-03-05
> 16:11:31.0 +0100
> @@ -1148,9 +1148,6 @@ running once the system is up.
>
> serialnumber[BUGS=IA-32]
>
> - sf16fm= [HW] SF16FMI radio driver for Linux
> - Format:
> -
> sg_def_reserved_size=
> [SCSI]
>
> diff -puN drivers/media/radio/radio-sf16fmi.c~kill_kernel_parameter-sf16fm
> drivers/media/radio/radio-sf16fmi.c
> --- kj/drivers/media/radio/radio-sf16fmi.c~kill_kernel_parameter-sf16fm
> 2005-03-05 16:11:31.0 +0100
> +++ kj-domen/drivers/media/radio/radio-sf16fmi.c 2005-03-05
> 16:11:31.0 +0100
> @@ -326,13 +326,3 @@ static void __exit fmi_cleanup_module(vo
>
> module_init(fmi_init);
> module_exit(fmi_cleanup_module);
> -
> -#ifndef MODULE
> -static int __init fmi_setup_io(char *str)
> -{
> - get_option(&str, &io);
> - return 1;
> -}
> -
> -__setup("sf16fm=", fmi_setup_io);
> -#endif
> _
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2/2 Prezeroing large blocks of pages during allocation
On Mon, 28 Feb 2005, Christoph Lameter wrote: > On Sun, 27 Feb 2005, Mel Gorman wrote: > > > The patch also counts how many blocks of each order were zeroed. This gives > > a rough indicator if large blocks are frequently zeroed or not. I found > > that order-0 are the most frequent zeroed block because of the per-cpu > > caches. This means we rarely win with zeroing in the allocator but the > > accounting mechanisms are still handy for the scrubber daemon. > > Thanks for your efforts in integrating zeroing into your patches to reduce > fragmentation. No problem. > It is true that you do not win with zeroing pages in the > allocator. However, you may avoid additional zeroing by zeroing higher > order pages and then breaking them into lower order pages (but this will > then lead to additional fragmentation). > I got around the fragmentation problem by having a userzero and kernzero pool. I also taught rmqueue_bulk() to allocate memory in as large as chunks as possible and break it up into appropriate sizes. This means that when the per-cpu caches are allocating 16 pages, we can now allocate this as one 2**4 allocation rather than 16 2**0 allocations (which is possibly a win in general, not just the prezeroing case, but I have not measured it). The zeroblock counts after a stress test now look something like this; Zeroblock count 96968 145994 125787 75329 32553 110 11 73 26 5 175 That is a big improvement as we are not zeroing order-0 pages nearly as often as we were. It is no longer regressing in terms of fragmentation either which is important. I need to test the patch more but hope to post a new version by tomorrow evening. It will also need careful reviewing to make sure I did not miss something with the per-cpu caches. > > This patch seriously regresses how well fragmentation is handled making it > > perform almost as badly as the standard allocator. It is because the > > fallback > > ordering for USERZERO has a tendency to clobber the reserved lists because > > of the mix of allocation types that need to be zeroed. > > Having pages of multiple orders in zeroed and not zeroed state invariably > leads to more fragmentation. I have also observed that with my patches > under many configurations. Seems that the only solution is to > intentionally either zero all free pages (which means you can coalesce > them all but you are zeroing lots of pages that did not need zeroing > after all) or you disregard the zeroed state during coalescing, either > insure that both are zeroed or mark the results as unzeroed... both > solutions introduce additional overhead. > My approach is to ignore zero pages during free/coalescing and to treat kernel allocations for zero pages differently to userspace allocations for zero pages. > My favorite solution has been so far to try to zero all > pages from the highest order downward but only when the system is idle > (or there is some hardware that does zeroing for us). And maybe we better > drop the zeroed status if a zeroed and an unzeroed page can be coalesced > to a higher order page? However, there will still be lots of unnecessary > zeroing. > When splitting, I zero the largest possible block on the assumption it makes sense to zero larger blocks. During coalesing, I ignore the zero state altogether as I could not think of a fast way of determining if a page was zeroed or not. > Since most of the request for zeroed pages are order-0 requests, we could > do a similar thing to that M$ Windows does > (http://www.windowsitpro.com/Articles/Index.cfm?ArticleID=3774&pg=2): Keep > a list of zeroed order 0 pages around, only put things on that list if > the system is truly idle and pick pages up for order 0 zeroed accesses. > > These zero lists would needed to be managed more like cpu hotlists and > not like we do currently as buddy allocator freelists. > I went with a variation of this approach. In my latest tree, I have pageset and pageset_zero to represent a per-CPU cache of normal pages and of zeroed pages. I have the buddy free lists to zero pages that are only filled when splitting up a large block of pages for a zero page allocation. -- Mel Gorman - 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 04/12] drivers/net/myri_code.h cleanup
[EMAIL PROTECTED] wrote:
>
> Cleanup initialization to 0.
>
> Basically it does:
> -static unsigned char lanai4_data[20472] __initdata = {
> -0x00,0x00,
> - a bunch of zeroes
> -0x00,0x00, 0x00,0x00, 0x00,0x00, } ;
> +static unsigned char lanai4_data[20472] __initdata = { };
Fair enough. If someone regenerates that header then we'll be back to the
same silliness. I guess we just need to keep an eye out for that.
-
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 breaks ALSA Intel AC97 audio
Hi Lars, Yeah I've got no audio on my T41, which I think uses the AC97 too. I haven't had time to look into it though :/ cheers On Sun, 6 Mar 2005 10:10, Lars wrote: > With Kernel 2.6.11 the Audio driver in my ThinkPad T42 stopped working. > The dsp device is detected and readable/writable, but there's no > audible sound. > Everything worked fine with 2.6.9 and 2.6.10. > Did anybody else see this? > > /proc/pci: > -- > >Bus 0, device 31, function 5: > Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM > (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 1). >IRQ 11. >I/O at 0x1c00 [0x1cff]. >I/O at 0x18c0 [0x18ff]. >Non-prefetchable 32 bit memory at 0xcc00 [0xcdff]. >Non-prefetchable 32 bit memory at 0xc800 [0xc8ff]. > > Kernel sound config: > > > # > # Sound > # > CONFIG_SOUND=m > > # > # Advanced Linux Sound Architecture > # > CONFIG_SND=m > CONFIG_SND_TIMER=m > CONFIG_SND_PCM=m > CONFIG_SND_RAWMIDI=m > CONFIG_SND_SEQUENCER=m > CONFIG_SND_SEQ_DUMMY=m > CONFIG_SND_OSSEMUL=y > CONFIG_SND_MIXER_OSS=m > CONFIG_SND_PCM_OSS=m > CONFIG_SND_SEQUENCER_OSS=y > CONFIG_SND_RTCTIMER=m > # CONFIG_SND_VERBOSE_PRINTK is not set > # CONFIG_SND_DEBUG is not set > > # > # Generic devices > # > CONFIG_SND_MPU401_UART=m > # CONFIG_SND_DUMMY is not set > # CONFIG_SND_VIRMIDI is not set > # CONFIG_SND_MTPAV is not set > # CONFIG_SND_SERIAL_U16550 is not set > CONFIG_SND_MPU401=m > > # > # PCI devices > # > CONFIG_SND_AC97_CODEC=m > # CONFIG_SND_ALI5451 is not set > # CONFIG_SND_ATIIXP is not set > # CONFIG_SND_ATIIXP_MODEM is not set > # CONFIG_SND_AU8810 is not set > # CONFIG_SND_AU8820 is not set > # CONFIG_SND_AU8830 is not set > # CONFIG_SND_AZT3328 is not set > # CONFIG_SND_BT87X is not set > # CONFIG_SND_CS46XX is not set > # CONFIG_SND_CS4281 is not set > # CONFIG_SND_EMU10K1 is not set > # CONFIG_SND_EMU10K1X is not set > # CONFIG_SND_CA0106 is not set > # CONFIG_SND_KORG1212 is not set > # CONFIG_SND_MIXART is not set > # CONFIG_SND_NM256 is not set > # CONFIG_SND_RME32 is not set > # CONFIG_SND_RME96 is not set > # CONFIG_SND_RME9652 is not set > # CONFIG_SND_HDSP is not set > # CONFIG_SND_TRIDENT is not set > # CONFIG_SND_YMFPCI is not set > # CONFIG_SND_ALS4000 is not set > # CONFIG_SND_CMIPCI is not set > # CONFIG_SND_ENS1370 is not set > # CONFIG_SND_ENS1371 is not set > # CONFIG_SND_ES1938 is not set > # CONFIG_SND_ES1968 is not set > # CONFIG_SND_MAESTRO3 is not set > # CONFIG_SND_FM801 is not set > # CONFIG_SND_ICE1712 is not set > # CONFIG_SND_ICE1724 is not set > CONFIG_SND_INTEL8X0=m > CONFIG_SND_INTEL8X0M=m > # CONFIG_SND_SONICVIBES is not set > # CONFIG_SND_VIA82XX is not set > # CONFIG_SND_VIA82XX_MODEM is not set > # CONFIG_SND_VX222 is not set > > Loaded Modules: > --- > > snd_intel8x0 28864 1 > snd_ac97_codec 75256 1 snd_intel8x0 > snd_pcm_oss50016 0 > snd_mixer_oss 17856 1 snd_pcm_oss > snd_pcm82120 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss > snd_timer 20740 1 snd_pcm > snd45156 8 > snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer > soundcore 7008 1 snd > snd_page_alloc 7620 2 snd_intel8x0,snd_pcm > > - > 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/ -- Michael Ellerman OzLabs Canberra IBM Linux Technology Centre Phone: +61 2 6212 1183 Email: [EMAIL PROTECTED] WWWeb: http://michael.ellerman.id.au pgp5NOlDFzmWb.pgp Description: PGP signature
Re: [patch 1/8] isdn_bsdcomp.c - vfree() checking cleanups
On 07/03/05 00:07 +, Ralph Corderoy wrote:
>
> Hi Domen,
>
> > - if (db->dict) {
> > - vfree (db->dict);
> > - db->dict = NULL;
> > - }
> > + vfree (db->dict);
> > + db->dict = NULL;
>
> Is it really worth always calling vfree() which calls __vunmap() before
> db->dict is determined to be NULL in order to turn three lines into two?
Four lines into two :-)
> Plus the write to db->dict which might otherwise not be needed. The old
> code was clear, clean, and fast, no?
Shorter and more readable code is always better, right? And speed really
doesn't seem to be an issue here.
Domen
-
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/8] isdn_bsdcomp.c - vfree() checking cleanups
Hi Domen,
> - if (db->dict) {
> - vfree (db->dict);
> - db->dict = NULL;
> - }
> + vfree (db->dict);
> + db->dict = NULL;
Is it really worth always calling vfree() which calls __vunmap() before
db->dict is determined to be NULL in order to turn three lines into two?
Plus the write to db->dict which might otherwise not be needed. The old
code was clear, clean, and fast, no?
Cheers,
Ralph.
-
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: Page fault scalability patch V18: Overview
On Mon, 7 Mar 2005, Darren Williams wrote: > Hi Christoph > > On Fri, 04 Mar 2005, Christoph Lameter wrote: > > > Make sure that scrubd_stop on startup is set to 2 and no zero in > > mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. > > > unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ > > This is the assignment when page zero fails. Could you just test this with the prezeroing patches alone? Include a dmesg from a successful boot and then tell me what you changed and where the boot failed. Which version of the patches did you apply? - 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] irq and softirq handler measurement
Hello, I'd like to propose a modification of the linux kernel, which enables IRQ and SOFTIRQ handler measurement. The patch currently covers only i386 architecture, but could be extented to other architectures as well. I tried to measure time spent in mentioned hendler functions, by summarizing times spent in every part of their execution. This means that a new nested interrupt ends one part of time measurement for the first (previously running) IRQ or SOFTIRQ and starts a new part of time measurement for the second (newly started) IRQ. It may not be the most optimal solution (suggestions are most welcome), but it's been helpfull to me. Measurements may be usefull, for developing new drivers or if you are optimising your system. The linux (2.6.0-test11) patch has not been pasted at the end of the following usage description, because it is quite long, so here is the URL: http://friends.s5.net/pogacnik/patch-2.6.0-test11-usage-0.1. === Usage description: 1. Measure IRQ handlers This option enables measurement of time spent in each IRQ handler. Measured data is being displayed through the /proc/interrupts file. The CPU usage mean value for each IRQ handler and the maximum continuous time spent in each IRQ handler are being calculated for the time elapsed between two subsequent reads of the /proc/interrupts file. 2. Measure SOFTIRQ handlers This option enables measurement of time spent in each SOFTIRQ handler. Measurement includes every tasklet, that is being registered for this measure through the tasklet_register() function. The tasklet_init() calls register tasklets automaticaly. Measured data is being displayed through the /proc/softirqs file. The CPU usage mean value for each SOFTIRQ handler and the maximum continuous time spent in each SOFTIRQ handler are being calculated for the time elapsed between two subsequent reads of the /proc/softirqs file. Additionally the number of invocations for each SOFTIRQ handler (as well as for each tasklet) is being displayed through the /proc/softirqs file. 3. The patch This linux patch allows you to configure the kernel for compilation without any of the above options. First read of interrupts (or softirqs) file can not calculate CPU usage correctly, because there is no previous time reference. === kind regards to all Linux developers, Samo Pogacnik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-mm1] mips: more convert verify_area to access_ok
On Sun, 6 Mar 2005, Yoichi Yuasa wrote:
> This patch converts verify_area to access_ok for include/asm-mips.
>
Yeah, that's one of the few bits I had not done yet. Thank you for taking
a look at that.
I don't believe your patch is correct though. See below for what I think
is a better one.
> Yoichi
>
> Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
>
> diff -urN -X dontdiff a-orig/include/asm-mips/uaccess.h
> a/include/asm-mips/uaccess.h
> --- a-orig/include/asm-mips/uaccess.h Sat Mar 5 04:15:22 2005
> +++ a/include/asm-mips/uaccess.h Sun Mar 6 15:51:02 2005
> @@ -254,13 +254,11 @@
> ({ \
> __typeof__(*(ptr)) __gu_val = 0;\
> long __gu_addr; \
> - long __gu_err; \
> + long __gu_err = -EFAULT;\
> \
> might_sleep(); \
> __gu_addr = (long) (ptr); \
> - __gu_err = verify_area(VERIFY_READ, (void *) __gu_addr, size); \
> - \
> - if (likely(!__gu_err)) {\
> + if (access_ok(VERIFY_READ, (void *) __gu_addr, size)) { \
> switch (size) { \
> case 1: __get_user_asm("lb", __gu_err); break; \
> case 2: __get_user_asm("lh", __gu_err); break; \
with this change, __gu_err will always be -EFAULT. With the original code
it was either -EFAULT or 0 depending on the return value from verify_area.
Same goes for the next hunk in your patch.
I believe a more correct patch would be this :
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
diff -up linux-2.6.11-mm1-orig/include/asm-mips/uaccess.h
linux-2.6.11-mm1/include/asm-mips/uaccess.h
--- linux-2.6.11-mm1-orig/include/asm-mips/uaccess.h2005-03-05
00:39:40.0 +0100
+++ linux-2.6.11-mm1/include/asm-mips/uaccess.h 2005-03-07 00:49:24.0
+0100
@@ -258,7 +258,8 @@ struct __large_struct { unsigned long bu
\
might_sleep(); \
__gu_addr = (long) (ptr); \
- __gu_err = verify_area(VERIFY_READ, (void *) __gu_addr, size); \
+ __gu_err = access_ok(VERIFY_READ, (void *) __gu_addr, size) \
+ ? 0 : -EFAULT; \
\
if (likely(!__gu_err)) {\
switch (size) { \
@@ -353,7 +354,8 @@ extern void __get_user_unknown(void);
might_sleep(); \
__pu_val = (x); \
__pu_addr = (long) (ptr); \
- __pu_err = verify_area(VERIFY_WRITE, (void *) __pu_addr, size); \
+ __pu_err = access_ok(VERIFY_WRITE, (void *) __pu_addr, size)\
+ ? 0 : -EFAULT; \
\
if (likely(!__pu_err)) {\
switch (size) { \
It preserves the exact behaviour of the original.
--
Jesper
-
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.6.11-mm1] mips: fix section type conflict about mpc30x
This patch fixes section type conflict about mpc30x
CC arch/mips/pci/fixup-mpc30x.o
arch/mips/pci/fixup-mpc30x.c:26: error: internal_func_irqs causes a section
type conflict
make[1]: *** [arch/mips/pci/fixup-mpc30x.o] Error 1
make: *** [arch/mips/pci] Error 2
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff a-orig/arch/mips/pci/fixup-mpc30x.c
a/arch/mips/pci/fixup-mpc30x.c
--- a-orig/arch/mips/pci/fixup-mpc30x.c Fri Nov 5 00:42:26 2004
+++ a/arch/mips/pci/fixup-mpc30x.c Mon Jan 10 23:54:09 2005
@@ -29,7 +29,7 @@
VRC4173_USB_IRQ,
};
-static char irq_tab_mpc30x[] __initdata = {
+static const int irq_tab_mpc30x[] __initdata = {
[12] = VRC4173_PCMCIA1_IRQ,
[13] = VRC4173_PCMCIA2_IRQ,
[29] = MQ200_IRQ,
-
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/8] isdn/capi: replace interruptible_sleep_on() with wait_event_interruptible()
Use wait_event_interruptible() instead of the deprecated
interruptible_sleep_on(). Patch is straight-forward as current sleep is
conditionally looped. Patch is compile-tested.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/isdn/capi/capi.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff -puN drivers/isdn/capi/capi.c~int_sleep_on-drivers_isdn_capi_capi
drivers/isdn/capi/capi.c
--- kj/drivers/isdn/capi/capi.c~int_sleep_on-drivers_isdn_capi_capi
2005-03-05 16:11:36.0 +0100
+++ kj-domen/drivers/isdn/capi/capi.c 2005-03-05 16:11:36.0 +0100
@@ -675,13 +675,8 @@ capi_read(struct file *file, char __user
if (file->f_flags & O_NONBLOCK)
return -EAGAIN;
- for (;;) {
- interruptible_sleep_on(&cdev->recvwait);
- if ((skb = skb_dequeue(&cdev->recvqueue)) != 0)
- break;
- if (signal_pending(current))
- break;
- }
+ wait_event_interruptible(cdev->recvwait,
+ ((skb = skb_dequeue(&cdev->recvqueue)) == 0));
if (skb == 0)
return -ERESTARTNOHAND;
}
_
-
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 09/14] tc/zs: replace schedule_timeout() with msleep_interruptible()
Use msleep_interruptible() instead of schedule_timeout() to
guarantee the task delays as expected.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Maximilian Attems <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/tc/zs.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff -puN drivers/tc/zs.c~msleep_interruptible-drivers_tc_zs drivers/tc/zs.c
--- kj/drivers/tc/zs.c~msleep_interruptible-drivers_tc_zs 2005-03-05
16:09:39.0 +0100
+++ kj-domen/drivers/tc/zs.c2005-03-05 16:09:39.0 +0100
@@ -1368,8 +1368,7 @@ static void rs_close(struct tty_struct *
info->tty = 0;
if (info->blocked_open) {
if (info->close_delay) {
- current->state = TASK_INTERRUPTIBLE;
- schedule_timeout(info->close_delay);
+
msleep_interruptible(jiffies_to_msecs(info->close_delay));
}
wake_up_interruptible(&info->open_wait);
}
@@ -1403,8 +1402,7 @@ static void rs_wait_until_sent(struct tt
if (timeout)
char_time = min(char_time, timeout);
while ((read_zsreg(info->zs_channel, 1) & Tx_BUF_EMP) == 0) {
- current->state = TASK_INTERRUPTIBLE;
- schedule_timeout(char_time);
+ msleep_interruptible(jiffies_to_msecs(char_time));
if (signal_pending(current))
break;
if (timeout && time_after(jiffies, orig_jiffies + timeout))
_
-
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 08/14] list_for_each_entry: arch-um-drivers-chan_kern.c
Make code more readable with list_for_each_reverse.
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Signed-off-by: Maximilian Attems <[EMAIL PROTECTED]>
Acked-by: Jeff Dike <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/arch/um/drivers/chan_kern.c |4 +---
1 files changed, 1 insertion(+), 3 deletions(-)
diff -puN arch/um/drivers/chan_kern.c~list-for-each-entry-drivers_chan_kern
arch/um/drivers/chan_kern.c
--- kj/arch/um/drivers/chan_kern.c~list-for-each-entry-drivers_chan_kern
2005-03-05 16:09:00.0 +0100
+++ kj-domen/arch/um/drivers/chan_kern.c2005-03-05 16:09:00.0
+0100
@@ -218,7 +218,6 @@ void enable_chan(struct list_head *chans
void close_chan(struct list_head *chans)
{
- struct list_head *ele;
struct chan *chan;
/* Close in reverse order as open in case more than one of them
@@ -226,8 +225,7 @@ void close_chan(struct list_head *chans)
* state. Then, the first one opened will have the original state,
* so it must be the last closed.
*/
-for(ele = chans->prev; ele != chans; ele = ele->prev){
-chan = list_entry(ele, struct chan, list);
+ list_for_each_entry_reverse(chan, chans, list) {
if(!chan->opened) continue;
if(chan->ops->close != NULL)
(*chan->ops->close)(chan->fd, chan->data);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 06/14] 16/34: char/istallion: replace interruptible_sleep_on() with wait_event_interruptible()
Use wait_event_interruptible() instead of the deprecated
interruptible_sleep_on(). The replacements were all straight-forward as every
sleep was conditionally-looped. Patch is compile-tested (still warns about
{save,restore}_flags(),cli()).
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/char/istallion.c | 76 --
1 files changed, 33 insertions(+), 43 deletions(-)
diff -puN drivers/char/istallion.c~int_sleep_on-drivers_char_istallion
drivers/char/istallion.c
--- kj/drivers/char/istallion.c~int_sleep_on-drivers_char_istallion
2005-03-05 16:11:34.0 +0100
+++ kj-domen/drivers/char/istallion.c 2005-03-05 16:11:34.0 +0100
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1068,11 +1069,10 @@ static int stli_open(struct tty_struct *
tty->driver_data = portp;
portp->refcount++;
- while (test_bit(ST_INITIALIZING, &portp->state)) {
- if (signal_pending(current))
- return(-ERESTARTSYS);
- interruptible_sleep_on(&portp->raw_wait);
- }
+ wait_event_interruptible(portp->raw_wait,
+ !test_bit(ST_INITIALIZING, &portp->state));
+ if (signal_pending(current))
+ return(-ERESTARTSYS);
if ((portp->flags & ASYNC_INITIALIZED) == 0) {
set_bit(ST_INITIALIZING, &portp->state);
@@ -1275,12 +1275,11 @@ static int stli_rawopen(stlibrd_t *brdp,
* order of opens and closes may not be preserved across shared
* memory, so we must wait until it is complete.
*/
- while (test_bit(ST_CLOSING, &portp->state)) {
- if (signal_pending(current)) {
- restore_flags(flags);
- return(-ERESTARTSYS);
- }
- interruptible_sleep_on(&portp->raw_wait);
+ wait_event_interruptible(portp->raw_wait,
+ !test_bit(ST_CLOSING, &portp->state));
+ if (signal_pending(current)) {
+ restore_flags(flags);
+ return -ERESTARTSYS;
}
/*
@@ -1309,13 +1308,10 @@ static int stli_rawopen(stlibrd_t *brdp,
*/
rc = 0;
set_bit(ST_OPENING, &portp->state);
- while (test_bit(ST_OPENING, &portp->state)) {
- if (signal_pending(current)) {
- rc = -ERESTARTSYS;
- break;
- }
- interruptible_sleep_on(&portp->raw_wait);
- }
+ wait_event_interruptible(portp->raw_wait,
+ !test_bit(ST_OPENING, &portp->state));
+ if (signal_pending(current))
+ rc = -ERESTARTSYS;
restore_flags(flags);
if ((rc == 0) && (portp->rc != 0))
@@ -1352,12 +1348,11 @@ static int stli_rawclose(stlibrd_t *brdp
* occurs on this port.
*/
if (wait) {
- while (test_bit(ST_CLOSING, &portp->state)) {
- if (signal_pending(current)) {
- restore_flags(flags);
- return(-ERESTARTSYS);
- }
- interruptible_sleep_on(&portp->raw_wait);
+ wait_event_interruptible(portp->raw_wait,
+ !test_bit(ST_CLOSING, &portp->state));
+ if (signal_pending(current)) {
+ restore_flags(flags);
+ return -ERESTARTSYS;
}
}
@@ -1385,13 +1380,10 @@ static int stli_rawclose(stlibrd_t *brdp
* to come back.
*/
rc = 0;
- while (test_bit(ST_CLOSING, &portp->state)) {
- if (signal_pending(current)) {
- rc = -ERESTARTSYS;
- break;
- }
- interruptible_sleep_on(&portp->raw_wait);
- }
+ wait_event_interruptible(portp->raw_wait,
+ !test_bit(ST_CLOSING, &portp->state));
+ if (signal_pending(current))
+ rc = -ERESTARTSYS;
restore_flags(flags);
if ((rc == 0) && (portp->rc != 0))
@@ -1420,22 +1412,20 @@ static int stli_cmdwait(stlibrd_t *brdp,
save_flags(flags);
cli();
- while (test_bit(ST_CMDING, &portp->state)) {
- if (signal_pending(current)) {
- restore_flags(flags);
- return(-ERESTARTSYS);
- }
- interruptible_sleep_on(&portp->raw_wait);
+ wait_event_interruptible(portp->raw_wait,
+ !test_bit(ST_CMDING, &portp->state));
+ if (signal_pending(current)) {
+ restore_flags(flags);
+ return -ERESTARTSYS;
}
stli_sendcmd(brdp, portp, cmd, arg, size, copyback);
- while (test_bit(ST_CMDING, &portp->state)) {
- if (signal_pending(current
[patch 10/14] serial/crisv10: replace schedule_timeout() with msleep()
Use msleep() instead of schedule_timeout() to guarantee the task
delays as expected. The current code uses TASK_INTERRUPTIBLE, but does not care
about signals, so I believe msleep() should be ok.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/serial/crisv10.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff -puN drivers/serial/crisv10.c~msleep-drivers_serial_crisv10
drivers/serial/crisv10.c
--- kj/drivers/serial/crisv10.c~msleep-drivers_serial_crisv10 2005-03-05
16:10:52.0 +0100
+++ kj-domen/drivers/serial/crisv10.c 2005-03-05 16:10:52.0 +0100
@@ -3757,10 +3757,8 @@ rs_write(struct tty_struct * tty, int fr
e100_enable_rx_irq(info);
#endif
- if (info->rs485.delay_rts_before_send > 0) {
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout((info->rs485.delay_rts_before_send *
HZ)/1000);
- }
+ if (info->rs485.delay_rts_before_send > 0)
+ msleep(info->rs485.delay_rts_before_send);
}
#endif /* CONFIG_ETRAX_RS485 */
_
-
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 14/14] drivers/message/fusion/*: convert to pci_register_driver
convert from pci_module_init to pci_register_driver Signed-off-by: Christophe Lucas <[EMAIL PROTECTED]> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> --- kj-domen/drivers/message/fusion/mptbase.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/message/fusion/mptbase.c~pci_register_driver-drivers_message_fusion drivers/message/fusion/mptbase.c --- kj/drivers/message/fusion/mptbase.c~pci_register_driver-drivers_message_fusion 2005-03-05 16:12:30.0 +0100 +++ kj-domen/drivers/message/fusion/mptbase.c 2005-03-05 16:12:30.0 +0100 @@ -5913,7 +5913,7 @@ fusion_init(void) #ifdef CONFIG_PROC_FS (void) procmpt_create(); #endif - r = pci_module_init(&mptbase_driver); + r = pci_register_driver(&mptbase_driver); if(r) return(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/
[patch 1/8] isdn_bsdcomp.c - vfree() checking cleanups
isdn_bsdcomp.c vfree() checking cleanups.
Signed-off by: James Lamanna <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/isdn/i4l/isdn_bsdcomp.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff -puN drivers/isdn/i4l/isdn_bsdcomp.c~vfree-drivers_isdn_i4l_isdn_bsdcomp
drivers/isdn/i4l/isdn_bsdcomp.c
--- kj/drivers/isdn/i4l/isdn_bsdcomp.c~vfree-drivers_isdn_i4l_isdn_bsdcomp
2005-03-05 16:10:31.0 +0100
+++ kj-domen/drivers/isdn/i4l/isdn_bsdcomp.c2005-03-05 16:10:31.0
+0100
@@ -283,18 +283,14 @@ static void bsd_free (void *state)
/*
* Release the dictionary
*/
- if (db->dict) {
- vfree (db->dict);
- db->dict = NULL;
- }
+ vfree (db->dict);
+ db->dict = NULL;
/*
* Release the string buffer
*/
- if (db->lens) {
- vfree (db->lens);
- db->lens = NULL;
- }
+ vfree (db->lens);
+ db->lens = NULL;
/*
* Finally release the structure itself.
_
-
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 12/14] drivers/dmapool: use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/base/dmapool.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/base/dmapool.c~task_unint-drivers_base_dmapool
drivers/base/dmapool.c
--- kj/drivers/base/dmapool.c~task_unint-drivers_base_dmapool 2005-03-05
16:11:21.0 +0100
+++ kj-domen/drivers/base/dmapool.c 2005-03-05 16:11:21.0 +0100
@@ -293,7 +293,7 @@ restart:
if (mem_flags & __GFP_WAIT) {
DECLARE_WAITQUEUE (wait, current);
- current->state = TASK_INTERRUPTIBLE;
+ set_current_state(TASK_UNINTERRUPTIBLE);
add_wait_queue (&pool->waitq, &wait);
spin_unlock_irqrestore (&pool->lock, flags);
_
-
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 11/14] message/mptbase: replace schedule_timeout() with ssleep()
Use ssleep() instead of schedule_timeout() to guarantee
the task delays as expected. The original code does use TASK_INTERRUPTIBLE, but
does not check for signals or early return from schedule_timeout() so ssleep()
seems more appropriate.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/message/fusion/mptbase.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
diff -puN
drivers/message/fusion/mptbase.c~ssleep-drivers_message_fusion_mptbase
drivers/message/fusion/mptbase.c
--- kj/drivers/message/fusion/mptbase.c~ssleep-drivers_message_fusion_mptbase
2005-03-05 16:11:15.0 +0100
+++ kj-domen/drivers/message/fusion/mptbase.c 2005-03-05 16:11:15.0
+0100
@@ -3137,8 +3137,7 @@ mpt_diag_reset(MPT_ADAPTER *ioc, int ign
/* wait 1 sec */
if (sleepFlag == CAN_SLEEP) {
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(1000 * HZ / 1000);
+ ssleep(1);
} else {
mdelay (1000);
}
_
-
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: serial CardBus card does not wake up after sleep
On Sun, Mar 06, 2005 at 02:09:46PM -0600, Hendrik Hoeth wrote:
> I'm using a serial CardBus card (Sony Ericsson GC79 -- combined GPRS and
> WiFi, I'm talking about the GPRS modem part of it) in a Samsung P35
> laptop, kernel version 2.6.11. If I put the laptop in S3 leaving the
> card in the laptop, the card does not wake up on resume. I need to
> remove and reinsert the card.
Looks like the card wasn't resumed properly. Please try this patch:
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x *.orig -x *.rej
orig/drivers/serial/8250_pci.c linux/drivers/serial/8250_pci.c
--- orig/drivers/serial/8250_pci.c Wed Mar 2 14:40:16 2005
+++ linux/drivers/serial/8250_pci.c Sun Mar 6 22:38:46 2005
@@ -1759,7 +1759,7 @@ static void __devexit pciserial_remove_o
}
}
-static int pciserial_suspend_one(struct pci_dev *dev, u32 state)
+static int pciserial_suspend_one(struct pci_dev *dev, pm_message_t state)
{
struct serial_private *priv = pci_get_drvdata(dev);
@@ -1769,6 +1769,8 @@ static int pciserial_suspend_one(struct
for (i = 0; i < priv->nr; i++)
serial8250_suspend_port(priv->line[i]);
}
+ pci_save_state(dev);
+ pci_set_power_state(dev, pci_choose_state(dev, state));
return 0;
}
@@ -1776,10 +1778,18 @@ static int pciserial_resume_one(struct p
{
struct serial_private *priv = pci_get_drvdata(dev);
+ pci_set_power_state(dev, PCI_D0);
+ pci_restore_state(dev);
+
if (priv) {
int i;
/*
+* The device may have been disabled. Re-enable it.
+*/
+ pci_enable_device(dev);
+
+ /*
* Ensure that the board is correctly configured.
*/
if (priv->quirk->init)
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 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/
[patch 13/14] drivers/eisa/*: convert to pci_register_driver
convert from pci_module_init to pci_register_driver
Signed-off-by: Christophe Lucas <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/eisa/pci_eisa.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/eisa/pci_eisa.c~pci_register_driver-drivers_eisa
drivers/eisa/pci_eisa.c
--- kj/drivers/eisa/pci_eisa.c~pci_register_driver-drivers_eisa 2005-03-05
16:12:19.0 +0100
+++ kj-domen/drivers/eisa/pci_eisa.c2005-03-05 16:12:19.0 +0100
@@ -59,7 +59,7 @@ static struct pci_driver pci_eisa_driver
static int __init pci_eisa_init_module (void)
{
- return pci_module_init (&pci_eisa_driver);
+ return pci_register_driver (&pci_eisa_driver);
}
device_initcall(pci_eisa_init_module);
_
-
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 03/14] char/sx: replace schedule_timeout() with msleep_interruptible()
Please consider applying.
Use msleep_interruptible() instead of schedule_timeout() to
guarantee consistent timing regardless of HZ value. schedule_timeout(1) will
vary between 10 and 1 milliseconds, depending on the value of HZ (100 or 1000
respectively). For consistent behavior, msleep_interruptible() should be used.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/char/sx.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff -puN drivers/char/sx.c~msleep_interruptible-drivers_char_sx
drivers/char/sx.c
--- kj/drivers/char/sx.c~msleep_interruptible-drivers_char_sx 2005-03-05
16:11:01.0 +0100
+++ kj-domen/drivers/char/sx.c 2005-03-05 16:11:01.0 +0100
@@ -1515,13 +1515,9 @@ static void sx_close (void *ptr)
sx_reconfigure_port(port);
sx_send_command (port, HS_CLOSE, 0, 0);
- while (to-- && (sx_read_channel_byte (port, hi_hstat) !=
HS_IDLE_CLOSED)) {
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout (1);
- if (signal_pending (current))
+ while (to-- && (sx_read_channel_byte (port, hi_hstat) !=
HS_IDLE_CLOSED))
+ if (msleep_interruptible(10))
break;
- }
- current->state = TASK_RUNNING;
if (sx_read_channel_byte (port, hi_hstat) != HS_IDLE_CLOSED) {
if (sx_send_command (port, HS_FORCE_CLOSED, -1, HS_IDLE_CLOSED)
!= 1) {
printk (KERN_ERR
_
-
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 01/14] char/snsc: reorder set_current_state() and add_wait_queue()
Any comments would be, as always, appreciated. -Nish Reorder add_wait_queue() and set_current_state() as a signal could be lost in between the two functions. Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> --- kj-domen/drivers/char/snsc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/char/snsc.c~reorder-state-drivers_char_snsc drivers/char/snsc.c --- kj/drivers/char/snsc.c~reorder-state-drivers_char_snsc 2005-03-05 16:09:54.0 +0100 +++ kj-domen/drivers/char/snsc.c2005-03-05 16:09:54.0 +0100 @@ -192,8 +192,8 @@ scdrv_read(struct file *file, char __use } len = CHUNKSIZE; - add_wait_queue(&sd->sd_rq, &wait); set_current_state(TASK_INTERRUPTIBLE); + add_wait_queue(&sd->sd_rq, &wait); spin_unlock_irqrestore(&sd->sd_rlock, flags); schedule_timeout(SCDRV_TIMEOUT); @@ -288,8 +288,8 @@ scdrv_write(struct file *file, const cha return -EAGAIN; } - add_wait_queue(&sd->sd_wq, &wait); set_current_state(TASK_INTERRUPTIBLE); + add_wait_queue(&sd->sd_wq, &wait); spin_unlock_irqrestore(&sd->sd_wlock, flags); schedule_timeout(SCDRV_TIMEOUT); _ - 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 05/14] char/hvsi: use wait_event_timeout()
Please consider applying. This is my first wait-queue related patch, so comments
are very welcome.
Use wait_event_timeout() in place of custom wait-queue code. The
code is not changed in any way (I don't think), but is cleaned up quite a bit
(will get expanded to almost identical code).
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/char/hvsi.c | 41 -
1 files changed, 4 insertions(+), 37 deletions(-)
diff -puN drivers/char/hvsi.c~wait_event_timeout-drivers_char_hvsi
drivers/char/hvsi.c
--- kj/drivers/char/hvsi.c~wait_event_timeout-drivers_char_hvsi 2005-03-05
16:11:27.0 +0100
+++ kj-domen/drivers/char/hvsi.c2005-03-05 16:11:27.0 +0100
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -631,27 +632,10 @@ static int __init poll_for_state(struct
/* wait for irq handler to change our state */
static int wait_for_state(struct hvsi_struct *hp, int state)
{
- unsigned long end_jiffies = jiffies + HVSI_TIMEOUT;
- unsigned long timeout;
int ret = 0;
- DECLARE_WAITQUEUE(myself, current);
- set_current_state(TASK_INTERRUPTIBLE);
- add_wait_queue(&hp->stateq, &myself);
-
- for (;;) {
- set_current_state(TASK_INTERRUPTIBLE);
- if (hp->state == state)
- break;
- timeout = end_jiffies - jiffies;
- if (time_after(jiffies, end_jiffies)) {
- ret = -EIO;
- break;
- }
- schedule_timeout(timeout);
- }
- remove_wait_queue(&hp->stateq, &myself);
- set_current_state(TASK_RUNNING);
+ if(!wait_event_timeout(hp->stateq, (hp->state == state), jiffies +
HVSI_TIMEOUT))
+ ret = -EIO;
return ret;
}
@@ -868,24 +852,7 @@ static int hvsi_open(struct tty_struct *
/* wait for hvsi_write_worker to empty hp->outbuf */
static void hvsi_flush_output(struct hvsi_struct *hp)
{
- unsigned long end_jiffies = jiffies + HVSI_TIMEOUT;
- unsigned long timeout;
-
- DECLARE_WAITQUEUE(myself, current);
- set_current_state(TASK_UNINTERRUPTIBLE);
- add_wait_queue(&hp->emptyq, &myself);
-
- for (;;) {
- set_current_state(TASK_UNINTERRUPTIBLE);
- if (hp->n_outbuf <= 0)
- break;
- timeout = end_jiffies - jiffies;
- if (time_after(jiffies, end_jiffies))
- break;
- schedule_timeout(timeout);
- }
- remove_wait_queue(&hp->emptyq, &myself);
- set_current_state(TASK_RUNNING);
+ wait_event_timeout(hp->emptyq, (hp->n_outbuf <= 0), jiffies +
HVSI_TIMEOUT);
/* 'writer' could still be pending if it didn't see n_outbuf = 0 yet */
cancel_delayed_work(&hp->writer);
_
-
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: RFD: Kernel release numbering
On Sul, 2005-03-06 at 07:53, Andres Salomon wrote: > On Thu, 03 Mar 2005 23:15:03 +0100, Adrian Bunk wrote: > There's also no other (suitable) place to announce kernel trees. Debian > kernels get announced on various debian-related lists; I'd imagine FC > kernels have the same thing. The only place to announce non-distro trees > is lkml (and I've had requests for an -as specific announce list, I > haven't haven't found the time to get something going). Please keep announcing them here - its useful to see all the trees in one place. I certainly look at the others to make sure I don't miss stuff. We might not agree on what should be merged but the cross checking is valuable. - 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.6.11-mm1] mips: add spare timer init
This patch adds spare timer initialization for NEC VR41xx.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/init.c
a/arch/mips/vr41xx/common/init.c
--- a-orig/arch/mips/vr41xx/common/init.c Thu Mar 3 07:26:49 2005
+++ a/arch/mips/vr41xx/common/init.cThu Mar 3 07:30:17 2005
@@ -19,9 +19,11 @@
*/
#include
#include
+#include
#include
#include
+#include
#include
#define IO_MEM_RESOURCE_START 0UL
@@ -33,6 +35,29 @@
iomem_resource.end = IO_MEM_RESOURCE_END;
}
+static void __init setup_timer_frequency(void)
+{
+ unsigned long tclock;
+
+ tclock = vr41xx_get_tclock_frequency();
+ if (current_cpu_data.processor_id == PRID_VR4131_REV2_0 ||
+ current_cpu_data.processor_id == PRID_VR4131_REV2_1)
+ mips_hpt_frequency = tclock / 2;
+ else
+ mips_hpt_frequency = tclock / 4;
+}
+
+static void __init setup_timer_irq(struct irqaction *irq)
+{
+ setup_irq(TIMER_IRQ, irq);
+}
+
+static void __init timer_init(void)
+{
+ board_time_init = setup_timer_frequency;
+ board_timer_setup = setup_timer_irq;
+}
+
void __init prom_init(void)
{
int argc, i;
@@ -48,6 +73,8 @@
}
vr41xx_calculate_clock_frequency();
+
+ timer_init();
iomem_resource_init();
}
diff -urN -X dontdiff a-orig/include/asm-mips/vr41xx/vr41xx.h
a/include/asm-mips/vr41xx/vr41xx.h
--- a-orig/include/asm-mips/vr41xx/vr41xx.h Thu Mar 3 07:26:49 2005
+++ a/include/asm-mips/vr41xx/vr41xx.h Thu Mar 3 07:29:10 2005
@@ -84,7 +84,7 @@
#define INT2_CASCADE_IRQ MIPS_CPU_IRQ(4)
#define INT3_CASCADE_IRQ MIPS_CPU_IRQ(5)
#define INT4_CASCADE_IRQ MIPS_CPU_IRQ(6)
-#define MIPS_COUNTER_IRQ MIPS_CPU_IRQ(7)
+#define TIMER_IRQ MIPS_CPU_IRQ(7)
/* SYINT1 Interrupt Numbers */
#define SYSINT1_IRQ_BASE 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: [PATCH] trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
On Gwe, 2005-03-04 at 16:27, Greg KH wrote: > Ok, based on consensus, I've applied this one too. > > Yes, we will get a bk-stable-commits tree up and running, still working > out the infrastructure... Cool. Once you've done so make sure there are also no bk snapshots and I'll push you some of the tiny but critical fixes (security, non working ULI tulip etc) from 11-ac1 when I upload it. Alan - 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: sound/isa/gus/gus_lfo.c is unused (fwd)
Hi Jaroslav, I didn't receive any answer regarding this question. Any comments or shall I send a patch to remove this file? cu Adrian - Forwarded message from Adrian Bunk <[EMAIL PROTECTED]> - Date: Wed, 24 Nov 2004 23:07:42 +0100 From: Adrian Bunk <[EMAIL PROTECTED]> To: Jaroslav Kysela <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Subject: 2.6: sound/isa/gus/gus_lfo.c is unused Hi Jaroslav, in kernel 2.6 (I've checked 2.6.10-rc2-mm3), the file sound/isa/gus/gus_lfo.c is completely unused (it's never built, and all code using it in other files is #if 0'ed). What's the status of this file? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/ - End forwarded message - - 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/8] drivers/isdn/pcbit/* - compile warning cleanup
compile warning cleanup - handle copy_to/from_user error
returns
Signed-off-by: Stephen Biggs <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
kj-domen/drivers/isdn/pcbit/drv.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff -puN drivers/isdn/pcbit/drv.c~return_code-drivers_isdn_pcbit
drivers/isdn/pcbit/drv.c
--- kj/drivers/isdn/pcbit/drv.c~return_code-drivers_isdn_pcbit 2005-03-05
16:13:08.0 +0100
+++ kj-domen/drivers/isdn/pcbit/drv.c 2005-03-05 16:13:08.0 +0100
@@ -727,23 +727,26 @@ int pcbit_stat(u_char __user *buf, int l
if (stat_st < stat_end)
{
- copy_to_user(buf, statbuf + stat_st, len);
+ if (copy_to_user(buf, statbuf + stat_st, len))
+ return -EFAULT;
stat_st += len;
}
else
{
if (len > STATBUF_LEN - stat_st)
{
- copy_to_user(buf, statbuf + stat_st,
- STATBUF_LEN - stat_st);
- copy_to_user(buf, statbuf,
- len - (STATBUF_LEN - stat_st));
+ if (copy_to_user(buf, statbuf + stat_st,
+ STATBUF_LEN - stat_st) ||
+ copy_to_user(buf, statbuf,
+ len - (STATBUF_LEN - stat_st)))
+ return -EFAULT;
stat_st = len - (STATBUF_LEN - stat_st);
}
else
{
- copy_to_user(buf, statbuf + stat_st, len);
+ if (copy_to_user(buf, statbuf + stat_st, len))
+ return -EFAULT;
stat_st += len;
_
-
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/
