Re: [ patch 3/7] drivers/serial/jsm: new serial device driver

2005-03-04 Thread Wen Xiong
Jeff Garzik wrote:
Wen Xiong wrote:
+static inline void neo_set_rts_flow_control(struct channel_t *ch)
+{
+uchar ier = readb(ch-ch_neo_uart-ier);
+uchar efr = readb(ch-ch_neo_uart-efr);

Do not invent new types like ushort or uchar.
For situations where specific size is required, use a size-specific 
type:  u8, u16, u32, etc.

+static inline void neo_set_ixon_flow_control(struct channel_t *ch)

This function is vaguely large.  Why is it inline
+static inline void neo_set_ixoff_flow_control(struct channel_t *ch)

+/* Give time for the UART to actually raise/drop the signals */
+udelay(10);

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

For patch3, Jeff and Greg gave me detail comments. Thanks for your comments.
Fixes non-standard type and PCI posting problems.
Signed-off-by: Wen Xiong [EMAIL PROTECTED]

diff -Nuar linux-2.6.11.org/drivers/serial/jsm/jsm_neo.c 
linux-2.6.11.new/drivers/serial/jsm/jsm_neo.c
--- linux-2.6.11.org/drivers/serial/jsm/jsm_neo.c   1969-12-31 
18:00:00.0 -0600
+++ linux-2.6.11.new/drivers/serial/jsm/jsm_neo.c   2005-03-04 
11:46:12.0 -0600
@@ -0,0 +1,1375 @@
+/
+ * Copyright 2003 Digi International (www.digi.com)
+ *
+ * Copyright (C) 2004 IBM Corporation. All rights reserved.
+ *
+ * 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, or (at your option)
+ * any later version.
+ * 
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY, EXPRESS OR IMPLIED; without even the 
+ * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR 
+ * PURPOSE.  See the GNU General Public License for more details.
+ * 
+ * You should have received a copy of the GNU General Public License 
+ * along with this program; if not, write to the Free Software 
+ * Foundation, Inc., 59 * Temple Place - Suite 330, Boston,
+ * MA  02111-1307, USA.
+ *
+ * Contact Information:
+ * Scott H Kilau [EMAIL PROTECTED]
+ * Wendy Xiong   [EMAIL PROTECTED]
+ *
+ ***/
+
+#include linux/sched.h   /* For jiffies, task states */
+#include linux/interrupt.h   /* For tasklet and interrupt structs/defines */
+#include asm/io.h/* For read[bwl]/write[bwl] */
+
+#include jsm_driver.h/* Driver main header file */
+
+static u32 jsm_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 
0x80 };
+
+static void neo_set_cts_flow_control(struct jsm_channel *ch)
+{
+   u8 ier = readb(ch-ch_neo_uart-ier);
+   u8 efr = readb(ch-ch_neo_uart-efr);
+
+   DPRINTK(PARAM, INFO, Setting CTSFLOW\n);
+
+   /* Turn on auto CTS flow control */
+   ier |= (UART_17158_IER_CTSDSR);
+   efr |= (UART_17158_EFR_ECB | UART_17158_EFR_CTSDSR);
+
+   /* Turn off auto Xon flow control */
+   efr = ~(UART_17158_EFR_IXON);
+
+   /* Why? Becuz Exar's spec says we have to zero it out before setting it 
*/
+   writeb(0, ch-ch_neo_uart-efr);
+
+   /* Turn on UART enhanced bits */
+   writeb(efr, ch-ch_neo_uart-efr);
+
+   /* Turn on table D, with 8 char hi/low watermarks */
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
ch-ch_neo_uart-fctr);
+
+   /* Feed the UART our trigger levels */
+   writeb(8, ch-ch_neo_uart-tfifo);
+   ch-ch_t_tlevel = 8;
+
+   writeb(ier, ch-ch_neo_uart-ier);
+}
+
+static void neo_set_rts_flow_control(struct jsm_channel *ch)
+{
+   u8 ier = readb(ch-ch_neo_uart-ier);
+   u8 efr = readb(ch-ch_neo_uart-efr);
+
+   DPRINTK(PARAM, INFO, Setting RTSFLOW\n);
+
+   /* Turn on auto RTS flow control */
+   ier |= (UART_17158_IER_RTSDTR);
+   efr |= (UART_17158_EFR_ECB | UART_17158_EFR_RTSDTR);
+
+   /* Turn off auto Xoff flow control */
+   ier = ~(UART_17158_IER_XOFF);
+   efr = ~(UART_17158_EFR_IXOFF);
+
+   /* Why? Becuz Exar's spec says we have to zero it out before setting it 
*/
+   writeb(0, ch-ch_neo_uart-efr);
+
+   /* Turn on UART enhanced bits */
+   writeb(efr, ch-ch_neo_uart-efr);
+
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
ch-ch_neo_uart-fctr);
+   ch-ch_r_watermark = 4;
+
+   writeb(56, ch-ch_neo_uart-rfifo);
+   ch-ch_r_tlevel = 56;
+
+   writeb(ier, ch-ch_neo_uart-ier);
+
+   /*
+* From the Neo UART spec sheet:
+* The auto RTS/DTR function must be started by asserting
+* RTS/DTR# output pin (MCR bit-0 or 1 to logic 1 after
+* it is enabled.
+*/
+   ch-ch_mostat |= (UART_MCR_RTS);
+}
+
+
+static void 

[BK PATCH] I2C patches for 2.6.11

2005-03-04 Thread Greg KH
Hi,

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.

Please pull from:
bk://kernel.bkbits.net/gregkh/linux/i2c-2.6

Patches will be posted to linux-kernel and sensors as a follow-up thread
for those who want to see them.

thanks,

greg k-h

 Documentation/i2c/porting-clients |6 
 Documentation/i2c/writing-clients |6 
 MAINTAINERS   |4 
 drivers/acorn/char/i2c.c  |2 
 drivers/acorn/char/pcf8583.c  |1 
 drivers/i2c/algos/i2c-algo-ite.c  |4 
 drivers/i2c/algos/i2c-algo-pca.c  |   30 
 drivers/i2c/algos/i2c-algo-pcf.c  |2 
 drivers/i2c/algos/i2c-algo-sgi.c  |2 
 drivers/i2c/busses/Kconfig|   12 
 drivers/i2c/busses/Makefile   |1 
 drivers/i2c/busses/i2c-au1550.c   |2 
 drivers/i2c/busses/i2c-elektor.c  |1 
 drivers/i2c/busses/i2c-ibm_iic.c  |2 
 drivers/i2c/busses/i2c-iop3xx.c   |2 
 drivers/i2c/busses/i2c-ixp4xx.c   |4 
 drivers/i2c/busses/i2c-keywest.c  |2 
 drivers/i2c/busses/i2c-mpc.c  |2 
 drivers/i2c/busses/i2c-mv64xxx.c  |  596 
 drivers/i2c/busses/i2c-nforce2.c  |6 
 drivers/i2c/busses/i2c-s3c2410.c  |5 
 drivers/i2c/chips/Kconfig |   46 +
 drivers/i2c/chips/Makefile|4 
 drivers/i2c/chips/adm1021.c   |9 
 drivers/i2c/chips/adm1025.c   |   12 
 drivers/i2c/chips/adm1026.c   |   87 --
 drivers/i2c/chips/adm1031.c   |9 
 drivers/i2c/chips/asb100.c|9 
 drivers/i2c/chips/ds1621.c|9 
 drivers/i2c/chips/eeprom.c|4 
 drivers/i2c/chips/fscher.c|   11 
 drivers/i2c/chips/fscpos.c|  643 +
 drivers/i2c/chips/gl518sm.c   |   12 
 drivers/i2c/chips/gl520sm.c   |  754 
 drivers/i2c/chips/isp1301_omap.c  |1 
 drivers/i2c/chips/it87.c  |   76 +-
 drivers/i2c/chips/lm63.c  |5 
 drivers/i2c/chips/lm75.c  |9 
 drivers/i2c/chips/lm77.c  |9 
 drivers/i2c/chips/lm78.c  |   58 -
 drivers/i2c/chips/lm80.c  |   30 
 drivers/i2c/chips/lm83.c  |   12 
 drivers/i2c/chips/lm85.c  |   14 
 drivers/i2c/chips/lm87.c  |   12 
 drivers/i2c/chips/lm90.c  |   12 
 drivers/i2c/chips/m41t00.c|  247 ++
 drivers/i2c/chips/max1619.c   |   13 
 drivers/i2c/chips/pc87360.c   |4 
 drivers/i2c/chips/pcf8574.c   |4 
 drivers/i2c/chips/pcf8591.c   |4 
 drivers/i2c/chips/rtc8564.c   |   18 
 drivers/i2c/chips/sis5595.c   |  794 ++
 drivers/i2c/chips/smsc47b397.c|5 
 drivers/i2c/chips/smsc47m1.c  |9 
 drivers/i2c/chips/via686a.c   |6 
 drivers/i2c/chips/w83627hf.c  |   26 
 drivers/i2c/chips/w83781d.c   |   29 
 drivers/i2c/chips/w83l785ts.c |   12 
 drivers/i2c/i2c-core.c|   81 +-
 drivers/i2c/i2c-dev.c |9 
 drivers/i2c/i2c-sensor-detect.c   |7 
 drivers/macintosh/therm_windtunnel.c  |4 
 drivers/media/common/saa7146_i2c.c|8 
 drivers/media/dvb/b2c2/skystar2.c |2 
 drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c  |2 
 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |2 
 drivers/media/video/adv7170.c |5 
 drivers/media/video/adv7175.c |5 
 drivers/media/video/bt819.c   |   11 
 drivers/media/video/bt856.c   |5 
 drivers/media/video/bttv-i2c.c|3 
 drivers/media/video/cx88/cx88-i2c.c   |1 
 drivers/media/video/ovcamchip/ovcamchip_core.c|1 
 drivers/media/video/saa5246a.c|1 
 drivers/media/video/saa5249.c |1 
 drivers/media/video/saa7110.c |5 
 drivers/media/video/saa7111.c |5 
 

[PATCH] PCI Hotplug: Fix OSHP calls in shpchp and pciehp drivers

2005-03-04 Thread Greg KH
ChangeSet 1.1998.11.17, 2005/02/17 15:05:32-08:00, [EMAIL PROTECTED]

[PATCH] PCI Hotplug: Fix OSHP calls in shpchp and pciehp drivers

Here is a patch to fix a problem in OSHP calls in shpchp and pciehp
drivers that was detected in 2.6.11-rc3. In this kernel, calls to
acpi_evaluate_object() to evaluate OSHP returned AE_BUFFER_OVERFLOW
with the existing code.  Earlier kernels didn't return this error
code.  The correct fix should be making return_buffer pointer NULL
for no value is returned from this method.

Signed-off-by: Dely Sy [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]


 drivers/pci/hotplug/pciehprm_acpi.c |3 +--
 drivers/pci/hotplug/shpchprm_acpi.c |3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)


diff -Nru a/drivers/pci/hotplug/pciehprm_acpi.c 
b/drivers/pci/hotplug/pciehprm_acpi.c
--- a/drivers/pci/hotplug/pciehprm_acpi.c   2005-03-04 12:42:18 -08:00
+++ b/drivers/pci/hotplug/pciehprm_acpi.c   2005-03-04 12:42:18 -08:00
@@ -254,10 +254,9 @@
 {
acpi_status status;
u8  *path_name = acpi_path_name(ab-handle);
-   struct acpi_buffer  ret_buf = { 0, NULL};
 
/* run OSHP */
-   status = acpi_evaluate_object(ab-handle, METHOD_NAME_OSHP, NULL, 
ret_buf);
+   status = acpi_evaluate_object(ab-handle, METHOD_NAME_OSHP, NULL, NULL);
if (ACPI_FAILURE(status)) {
err(acpi_pciehprm:%s OSHP fails=0x%x\n, path_name, status);
oshp_run_status = (status == AE_NOT_FOUND) ? OSHP_NOT_EXIST : 
OSHP_RUN_FAILED;
diff -Nru a/drivers/pci/hotplug/shpchprm_acpi.c 
b/drivers/pci/hotplug/shpchprm_acpi.c
--- a/drivers/pci/hotplug/shpchprm_acpi.c   2005-03-04 12:42:18 -08:00
+++ b/drivers/pci/hotplug/shpchprm_acpi.c   2005-03-04 12:42:18 -08:00
@@ -242,10 +242,9 @@
 {
acpi_status status;
u8  *path_name = acpi_path_name(ab-handle);
-   struct acpi_buffer  ret_buf = { 0, NULL};
 
/* run OSHP */
-   status = acpi_evaluate_object(ab-handle, METHOD_NAME_OSHP, NULL, 
ret_buf);
+   status = acpi_evaluate_object(ab-handle, METHOD_NAME_OSHP, NULL, NULL);
if (ACPI_FAILURE(status)) {
err(acpi_pciehprm:%s OSHP fails=0x%x\n, path_name, status);
} else

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] I2C: Kill i2c_client.id (1/5)

2005-03-04 Thread Greg KH
ChangeSet 1.2083, 2005/03/02 11:51:51-08:00, [EMAIL PROTECTED]

[PATCH] I2C: Kill i2c_client.id (1/5)

(1/5) Stop using i2c_client.id in i2c/chips drivers (mostly hardware
  monitoring drivers).

Drivers affected:
* adm1021
* adm1025
* adm1026
* adm1031
* ds1621
* fscher
* gl518sm
* isp1301_omap
* lm75
* lm77
* lm80
* lm83
* lm85
* lm87
* lm90
* max1619
* pcf8574
* pcf8591
* rtc8564
* smsc47m1
* w83l785ts

The vast majority of these drivers simply defined the i2c_client id
struct member but never used it, so they are not affected at all by the
change. Exceptions are:

* lm85 and rtc8564, which would at least display the id in a debug
message when assigning it. Not really useful though, as the id was then
never used.

* adm1026, which used the assigned id in all driver messages. However,
since dev_* calls will append the bus number and client address to these
messages, the id information is redundant and can go away. Also, the
driver would allow some GPIO reprogramming on the first client only
(id=0) and removing the id doesn't allow that anymore. I would restore a
similar functionality if needed, but the ADM1026 chip is found on very
few motherboards and none of these has more than one ADM1026 chip AFAIK,
so it doesn't seem to be worth the effort.

Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]


 drivers/i2c/chips/adm1021.c  |4 -
 drivers/i2c/chips/adm1025.c  |7 ---
 drivers/i2c/chips/adm1026.c  |   80 +++
 drivers/i2c/chips/adm1031.c  |4 -
 drivers/i2c/chips/ds1621.c   |4 -
 drivers/i2c/chips/fscher.c   |7 ---
 drivers/i2c/chips/gl518sm.c  |7 ---
 drivers/i2c/chips/isp1301_omap.c |1 
 drivers/i2c/chips/lm75.c |4 -
 drivers/i2c/chips/lm77.c |4 -
 drivers/i2c/chips/lm80.c |8 ---
 drivers/i2c/chips/lm83.c |7 ---
 drivers/i2c/chips/lm85.c |9 
 drivers/i2c/chips/lm87.c |7 ---
 drivers/i2c/chips/lm90.c |7 ---
 drivers/i2c/chips/max1619.c  |7 ---
 drivers/i2c/chips/pcf8574.c  |4 -
 drivers/i2c/chips/pcf8591.c  |4 -
 drivers/i2c/chips/rtc8564.c  |2 
 drivers/i2c/chips/smsc47m1.c |5 --
 drivers/i2c/chips/w83l785ts.c|7 ---
 21 files changed, 32 insertions(+), 157 deletions(-)


diff -Nru a/drivers/i2c/chips/adm1021.c b/drivers/i2c/chips/adm1021.c
--- a/drivers/i2c/chips/adm1021.c   2005-03-04 12:26:25 -08:00
+++ b/drivers/i2c/chips/adm1021.c   2005-03-04 12:26:25 -08:00
@@ -147,8 +147,6 @@
.detach_client  = adm1021_detach_client,
 };
 
-static int adm1021_id;
-
 #define show(value)\
 static ssize_t show_##value(struct device *dev, char *buf) \
 {  \
@@ -299,8 +297,6 @@
/* Fill in the remaining client fields and put it into the global list 
*/
strlcpy(new_client-name, type_name, I2C_NAME_SIZE);
data-type = kind;
-
-   new_client-id = adm1021_id++;
data-valid = 0;
init_MUTEX(data-update_lock);
 
diff -Nru a/drivers/i2c/chips/adm1025.c b/drivers/i2c/chips/adm1025.c
--- a/drivers/i2c/chips/adm1025.c   2005-03-04 12:26:25 -08:00
+++ b/drivers/i2c/chips/adm1025.c   2005-03-04 12:26:25 -08:00
@@ -148,12 +148,6 @@
 };
 
 /*
- * Internal variables
- */
-
-static int adm1025_id;
-
-/*
  * Sysfs stuff
  */
 
@@ -397,7 +391,6 @@
 
/* We can fill in the remaining client fields */
strlcpy(new_client-name, name, I2C_NAME_SIZE);
-   new_client-id = adm1025_id++;
data-valid = 0;
init_MUTEX(data-update_lock);
 
diff -Nru a/drivers/i2c/chips/adm1026.c b/drivers/i2c/chips/adm1026.c
--- a/drivers/i2c/chips/adm1026.c   2005-03-04 12:26:25 -08:00
+++ b/drivers/i2c/chips/adm1026.c   2005-03-04 12:26:25 -08:00
@@ -313,8 +313,6 @@
.detach_client  = adm1026_detach_client,
 };
 
-static int adm1026_id;
-
 int adm1026_attach_adapter(struct i2c_adapter *adapter)
 {
if (!(adapter-class  I2C_CLASS_HWMON)) {
@@ -363,49 +361,47 @@
int value, i;
struct adm1026_data *data = i2c_get_clientdata(client);
 
-dev_dbg(client-dev,(%d): Initializing device\n, client-id);
+dev_dbg(client-dev, Initializing device\n);
/* Read chip config */
data-config1 = adm1026_read_value(client, ADM1026_REG_CONFIG1);
data-config2 = adm1026_read_value(client, ADM1026_REG_CONFIG2);
data-config3 = adm1026_read_value(client, ADM1026_REG_CONFIG3);
 
/* Inform user of chip config */
-   dev_dbg(client-dev, (%d): ADM1026_REG_CONFIG1 is: 0x%02x\n,
-   client-id, data-config1);
+   dev_dbg(client-dev, ADM1026_REG_CONFIG1 is: 0x%02x\n,
+   data-config1);
if ((data-config1  CFG1_MONITOR) == 0) {
-   dev_dbg(client-dev, (%d): Monitoring not currently 
-   

[PATCH] I2C: Enable I2C_PIIX4 for 64-bit platforms

2005-03-04 Thread Greg KH
ChangeSet 1.2103, 2005/03/02 12:18:19-08:00, [EMAIL PROTECTED]

[PATCH] I2C: Enable I2C_PIIX4 for 64-bit platforms

 Is there any specific reason for the PIIX4 SMBus driver to be disabled on
64-bit platforms?  If not, then please apply the following change.  The
MIPS Technologies Malta development board has the 82371EB chip and
supports 64-bit configurations.  I've verified the driver to work
correctly using 64-bit kernels for both endiannesses.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]


 drivers/i2c/busses/Kconfig |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)


diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-03-04 12:24:09 -08:00
+++ b/drivers/i2c/busses/Kconfig2005-03-04 12:24:09 -08:00
@@ -287,7 +287,7 @@
 
 config I2C_PIIX4
tristate Intel PIIX4
-   depends on I2C  PCI  EXPERIMENTAL  !64BIT
+   depends on I2C  PCI  EXPERIMENTAL
help
  If you say yes to this option, support will be included for the Intel
  PIIX4 family of mainboard I2C interfaces.  Specifically, the following

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] I2C: add ST M41T00 I2C RTC chip driver

2005-03-04 Thread Greg KH
ChangeSet 1.2098, 2005/03/02 12:16:55-08:00, [EMAIL PROTECTED]

[PATCH] I2C: add ST M41T00 I2C RTC chip driver

This patch adds support for the ST M41T00 I2C RTC chip.

This rtc chip has no mechanism to freeze it's registers while being
read; however, it will delay updating the external values of the
registers for 250ms after a register is read.  To ensure that a sane
time value is read, the driver verifies that the same registers values
were read twice before returning.

Also, when setting the rtc from an interrupt handler, a tasklet is used
to provide the context required by the i2c core code.


Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]


 drivers/i2c/chips/Kconfig  |9 +
 drivers/i2c/chips/Makefile |1 
 drivers/i2c/chips/m41t00.c |  247 +
 3 files changed, 257 insertions(+)


diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
--- a/drivers/i2c/chips/Kconfig 2005-03-04 12:24:43 -08:00
+++ b/drivers/i2c/chips/Kconfig 2005-03-04 12:24:43 -08:00
@@ -382,4 +382,13 @@
  This driver can also be built as a module.  If so, the module
  will be called isp1301_omap.
 
+config SENSORS_M41T00
+   tristate ST M41T00 RTC chip
+   depends on I2C  PPC32
+   help
+ If you say yes here you get support for the ST M41T00 RTC chip.
+
+ This driver can also be built as a module.  If so, the module
+ will be called m41t00.
+
 endmenu
diff -Nru a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
--- a/drivers/i2c/chips/Makefile2005-03-04 12:24:43 -08:00
+++ b/drivers/i2c/chips/Makefile2005-03-04 12:24:43 -08:00
@@ -27,6 +27,7 @@
 obj-$(CONFIG_SENSORS_LM87) += lm87.o
 obj-$(CONFIG_SENSORS_LM90) += lm90.o
 obj-$(CONFIG_SENSORS_MAX1619)  += max1619.o
+obj-$(CONFIG_SENSORS_M41T00)   += m41t00.o
 obj-$(CONFIG_SENSORS_PC87360)  += pc87360.o
 obj-$(CONFIG_SENSORS_PCF8574)  += pcf8574.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
diff -Nru a/drivers/i2c/chips/m41t00.c b/drivers/i2c/chips/m41t00.c
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/chips/m41t00.c2005-03-04 12:24:43 -08:00
@@ -0,0 +1,247 @@
+/*
+ * drivers/i2c/chips/m41t00.c
+ *
+ * I2C client/driver for the ST M41T00 Real-Time Clock chip.
+ *
+ * Author: Mark A. Greer [EMAIL PROTECTED]
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed as is without any warranty of any kind, whether express
+ * or implied.
+ */
+/*
+ * This i2c client/driver wedges between the drivers/char/genrtc.c RTC
+ * interface and the SMBus interface of the i2c subsystem.
+ * It would be more efficient to use i2c msgs/i2c_transfer directly but, as
+ * recommened in .../Documentation/i2c/writing-clients section
+ * Sending and receiving, using SMBus level communication is preferred.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/rtc.h
+#include linux/bcd.h
+
+#include asm/time.h
+#include asm/rtc.h
+
+#defineM41T00_DRV_NAME m41t00
+
+static DECLARE_MUTEX(m41t00_mutex);
+
+static struct i2c_driver m41t00_driver;
+static struct i2c_client *save_client;
+
+static unsigned short ignore[] = { I2C_CLIENT_END };
+static unsigned short normal_addr[] = { 0x68, I2C_CLIENT_END };
+
+static struct i2c_client_address_data addr_data = {
+   .normal_i2c = normal_addr,
+   .normal_i2c_range   = ignore,
+   .probe  = ignore,
+   .probe_range= ignore,
+   .ignore = ignore,
+   .ignore_range   = ignore,
+   .force  = ignore,
+};
+
+ulong
+m41t00_get_rtc_time(void)
+{
+   s32 sec, min, hour, day, mon, year;
+   s32 sec1, min1, hour1, day1, mon1, year1;
+   ulong   limit = 10;
+
+   sec = min = hour = day = mon = year = 0;
+   sec1 = min1 = hour1 = day1 = mon1 = year1 = 0;
+
+   down(m41t00_mutex);
+   do {
+   if (((sec = i2c_smbus_read_byte_data(save_client, 0)) = 0)
+((min = i2c_smbus_read_byte_data(save_client, 1))
+   = 0)
+((hour = i2c_smbus_read_byte_data(save_client, 2))
+   = 0)
+((day = i2c_smbus_read_byte_data(save_client, 4))
+   = 0)
+((mon = i2c_smbus_read_byte_data(save_client, 5))
+   = 0)
+((year = i2c_smbus_read_byte_data(save_client, 6))
+   = 0)
+((sec == sec1)  (min == min1)  (hour == hour1)
+(day == day1)  (mon == mon1)
+(year == year1)))
+
+   break;
+
+  

[PATCH] 2.6.11-mm1 nobh support for ext3 writeback mode

2005-03-04 Thread Badari Pulavarty
Hi Andrew,

Here is the 2.6.11-mm1 patch to add nobh support to ext3 
writeback mode. Can you please add this to -mm ?

BTW, this patch depends on add-writepage patch, which is
in -mm tree.

Thanks,
Badari


diff -Naurp -Xdontdiff linux-2.6.11/fs/ext3/inode.c linux-2.6.11.new/fs/ext3/inode.c
--- linux-2.6.11/fs/ext3/inode.c	2005-03-04 16:43:22.536143072 -0800
+++ linux-2.6.11.new/fs/ext3/inode.c	2005-03-04 16:48:08.532664992 -0800
@@ -20,6 +20,7 @@
  * 	([EMAIL PROTECTED])
  *
  *  Assorted race fixes, rewrite of ext3_get_block() by Al Viro, 2000
+ *  Add nobh support for ext3 writeback mode - [EMAIL PROTECTED]
  */
 
 #include linux/module.h
@@ -1016,7 +1017,10 @@ retry:
 		ret = PTR_ERR(handle);
 		goto out;
 	}
-	ret = block_prepare_write(page, from, to, ext3_get_block);
+	if (test_opt(inode-i_sb, NOBH))
+		ret = nobh_prepare_write(page, from, to, ext3_get_block);
+	else
+		ret = block_prepare_write(page, from, to, ext3_get_block);
 	if (ret)
 		goto prepare_write_failed;
 
@@ -1100,7 +1104,12 @@ static int ext3_writeback_commit_write(s
 	new_i_size = ((loff_t)page-index  PAGE_CACHE_SHIFT) + to;
 	if (new_i_size  EXT3_I(inode)-i_disksize)
 		EXT3_I(inode)-i_disksize = new_i_size;
-	ret = generic_commit_write(file, page, from, to);
+
+	if (test_opt(inode-i_sb, NOBH))
+		ret = nobh_commit_write(file, page, from, to);
+	else
+		ret = generic_commit_write(file, page, from, to);
+
 	ret2 = ext3_journal_stop(handle);
 	if (!ret)
 		ret = ret2;
@@ -1385,7 +1394,11 @@ static int ext3_writeback_writepage(stru
 		goto out_fail;
 	}
 
-	ret = block_write_full_page(page, ext3_get_block, wbc);
+	if (test_opt(inode-i_sb, NOBH))
+		ret = nobh_writepage(page, ext3_get_block, wbc);
+	else
+		ret = block_write_full_page(page, ext3_get_block, wbc);
+
 	err = ext3_journal_stop(handle);
 	if (!ret)
 		ret = err;
@@ -1646,13 +1659,34 @@ static int ext3_block_truncate_page(hand
 	unsigned blocksize, iblock, length, pos;
 	struct inode *inode = mapping-host;
 	struct buffer_head *bh;
-	int err;
+	int err = 0;
 	void *kaddr;
 
 	blocksize = inode-i_sb-s_blocksize;
 	length = blocksize - (offset  (blocksize - 1));
 	iblock = index  (PAGE_CACHE_SHIFT - inode-i_sb-s_blocksize_bits);
 
+	if (test_opt(inode-i_sb, NOBH)  !page_has_buffers(page)) {
+		if (!PageUptodate(page)) {
+			err = mpage_readpage(page, ext3_get_block);
+			if ((err == 0)  !PageUptodate(page))
+wait_on_page_locked(page);
+			lock_page(page);
+		}
+		if (err == 0  PageUptodate(page)) {
+			kaddr = kmap_atomic(page, KM_USER0);
+			memset(kaddr + offset, 0, length);
+			flush_dcache_page(page);
+			kunmap_atomic(kaddr, KM_USER0);
+			set_page_dirty(page);
+			goto unlock;
+		}
+		/* 
+		 * Well, we tried to work without buffers and failed.
+		 * Fallback to creating buffers
+		 */
+	}
+	
 	if (!page_has_buffers(page))
 		create_empty_buffers(page, blocksize, 0);
 
diff -Naurp -Xdontdiff linux-2.6.11/fs/ext3/super.c linux-2.6.11.new/fs/ext3/super.c
--- linux-2.6.11/fs/ext3/super.c	2005-03-01 23:38:38.0 -0800
+++ linux-2.6.11.new/fs/ext3/super.c	2005-03-04 16:45:22.038975880 -0800
@@ -576,7 +576,7 @@ enum {
 	Opt_resgid, Opt_resuid, Opt_sb, Opt_err_cont, Opt_err_panic, Opt_err_ro,
 	Opt_nouid32, Opt_check, Opt_nocheck, Opt_debug, Opt_oldalloc, Opt_orlov,
 	Opt_user_xattr, Opt_nouser_xattr, Opt_acl, Opt_noacl,
-	Opt_reservation, Opt_noreservation, Opt_noload,
+	Opt_reservation, Opt_noreservation, Opt_noload, Opt_nobh,
 	Opt_commit, Opt_journal_update, Opt_journal_inum,
 	Opt_abort, Opt_data_journal, Opt_data_ordered, Opt_data_writeback,
 	Opt_usrjquota, Opt_grpjquota, Opt_offusrjquota, Opt_offgrpjquota,
@@ -611,6 +611,7 @@ static match_table_t tokens = {
 	{Opt_reservation, reservation},
 	{Opt_noreservation, noreservation},
 	{Opt_noload, noload},
+	{Opt_nobh, nobh},
 	{Opt_commit, commit=%u},
 	{Opt_journal_update, journal=update},
 	{Opt_journal_inum, journal=%u},
@@ -924,6 +925,9 @@ clear_qf_name:
 			match_int(args[0], option);
 			*n_blocks_count = option;
 			break;
+		case Opt_nobh:
+			set_opt(sbi-s_mount_opt, NOBH);
+			break;
 		default:
 			printk (KERN_ERR
 EXT3-fs: Unrecognized mount option \%s\ 
@@ -1563,6 +1567,19 @@ static int ext3_fill_super (struct super
 		break;
 	}
 
+	if (test_opt(sb, NOBH)) {
+		if (sb-s_blocksize_bits != PAGE_CACHE_SHIFT) {
+			printk(KERN_WARNING EXT3-fs: Ignoring nobh option 
+since filesystem blocksize doesn't match 
+pagesize\n);
+			clear_opt(sbi-s_mount_opt, NOBH);
+		}
+		if (!(test_opt(sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA)) {
+			printk(KERN_WARNING EXT3-fs: Ignoring nobh option - 
+its supported only with writeback mode\n);
+			clear_opt(sbi-s_mount_opt, NOBH);
+		}
+	}
 	/*
 	 * The journal_load will have done any necessary log recovery,
 	 * so we can safely mount the rest of the filesystem now.
diff -Naurp -Xdontdiff linux-2.6.11/include/linux/ext3_fs.h linux-2.6.11.new/include/linux/ext3_fs.h
--- linux-2.6.11/include/linux/ext3_fs.h	2005-03-01 23:38:10.0 -0800
+++ 

Re: [ patch 1/7] drivers/serial/jsm: new serial device driver

2005-03-04 Thread Jeff Garzik
Thanks for making the updates.
Please resubmit the entire series to LKML, so we can review it in total.
Jeff

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


Re: 2.6.11-mm1

2005-03-04 Thread Alexander Nyberg
   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm1/
   
   
   - Added the new bk-audit tree.  Contains updates to the kernel's audit
 feature.  Maintained by David Woodhouse.
   
   - The Dell keyboard problems should be fixed.  Testing needed.
   
   - Dmitry's bk-dtor-input tree is no longer active and has been dropped.
  
  Just booted up a box and tried to log onto ssh which didn't worked so I
  looked at kernel log and behold, 128MB box with no swap, had just
  booted. Couldn't get any access after this.
  A few kernel debugging options were chosen notably CONFIG_DEBUG_SLAB 
  CONFIG_DEBUG_PAGEALLOC
 
 So you're saying that the box has run out of memory?
 
 Please send me the .config then disable CONFIG_DEBUG_PAGEALLOC and retest,
 thanks.
 

Sorry for not making it clear, it was a one-time thing unfortunately.

I'll be hitting the reset button on the box to see if I can trigger it
again somehow.

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-mm1
# Fri Mar  4 16:34:58 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
# CONFIG_HOTPLUG is not set
# CONFIG_KOBJECT_UEVENT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_KMOD is not set

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODE is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_HPET_TIMER=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y
CONFIG_SECCOMP=y

#
# Performance-monitoring counters support
#
# CONFIG_PERFCTR is not set
CONFIG_PHYSICAL_START=0x10
CONFIG_KEXEC=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
# CONFIG_ACPI_VIDEO is not set
# CONFIG_ACPI_FAN is not set
# CONFIG_ACPI_PROCESSOR is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support

Re: Something is broken with SATA RAID ?

2005-03-04 Thread J.A. Magallon

On 03.03, Jeff Garzik wrote:
 On Thu, Mar 03, 2005 at 12:39:41AM +, J.A. Magallon wrote:
  Hi...
  
  I posted this in other mail, but now I can confirm this.
  
  I have a box with a SATA RAID-5, and with 2.6.11-rc3-mm2+libata-dev1
  works like a charm as a samba server, I dropped it 12Gb from an
  osx client, and people does backups from W2k boxes and everything was fine.
  With 2.6.11-rc4-mm1, it hangs shortly after the mac starts copying
  files. No oops, no messages... It even hanged on a local copy (wget),
  so I will discard samba as the buggy piece in the puzzle.
  
  I'm going to make a definitive test with rc5-mm1 vs rc5-mm1+libata-dev1.
  I already know that plain rc5-mm1 hangs. I have to wait the md 
  reconstruction
  of the 1.2 TB to check rc5-mm1+libata (and no user putting things there...)
 
 Please eliminate -mm and -libata-dev from the equation.
 

One piece at last...
I have tried
- 2.6.11
- 2.6.11 + libata-dev1 + netdev1 + shrinkers-at-tail + 1Gb-lowmem

Bot work fine and survived several gigas dumped both through smb and afp.
Happy man ;).

If there was something strange, it must be in -mm. rc5-mm1 did not work,
but plain 2.6.11 works. I will try 2.6.11-mm1 on monday...

Just a note. Net throughput seems a bit slower in the second case (measured
with iftop). And it degrades over time. With a 8 Gb copy, it started at
about 50Mb/s and dropped to 25 at the end. Not sure if the one to blame
is linux or osx...

Hardware (just for the record): 
2 x PDC20319 (FastTrak S150 TX4) (rev 02)
6 x 250Gb Maxtor 7Y250M0  YAR5, 3 on each.

RAID-5
nada:~# mdadm -D /dev/md0
/dev/md0:
Version : 00.90.01
  Creation Time : Fri Sep  3 02:17:28 2004
 Raid Level : raid5
 Array Size : 1225557760 (1168.78 GiB 1254.97 GB)
Device Size : 245111552 (233.76 GiB 250.99 GB)
   Raid Devices : 6
  Total Devices : 6
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Fri Mar  4 21:34:00 2005
  State : clean
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

 Layout : left-symmetric
 Chunk Size : 256K

   UUID : fd6fcad0:21da140b:072a82b1:11b3db21
 Events : 0.156336

Number   Major   Minor   RaidDevice State
   0   810  active sync   /dev/sda1
   1   8   171  active sync   /dev/sdb1
   2   8   332  active sync   /dev/sdc1
   3   8   493  active sync   /dev/sdd1
   4   8   654  active sync   /dev/sde1
   5   8   815  active sync   /dev/sdf1

/dev/md0:
 Timing cached reads:   756 MB in  2.01 seconds = 376.93 MB/sec
 Timing buffered disk reads:  158 MB in  3.02 seconds =  52.26 MB/sec

Thanks.

--
J.A. Magallon jamagallon()able!es \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.11-jam1 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Greg KH
On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote:
 Linus Torvalds [EMAIL PROTECTED] wrote:
 
  
  
  On Fri, 4 Mar 2005, Andrew Morton wrote:

 Ok, care to forward them on?
   
   Sure.  How do they get to Linus?
  
  I'll just pull from the sucker-tree. 
  
 
 That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix.

Then when the authors of those patches go to submit the fix to Linus,
they can revert them, or bk can handle the merge properly :)

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/


[PATCH] FUSE: inode leak fix

2005-03-04 Thread Miklos Szeredi
Hi Andrew!

This patch fixes an inode leak in fuse_get_dentry().  With libfuse
this practically never triggers, but a DoS exploit could be written.

Please Apply.

Thanks,
Miklos

Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]

diff -rup linux-2.6.11-mm1/fs/fuse/inode.c linux-fuse/fs/fuse/inode.c
--- linux-2.6.11-mm1/fs/fuse/inode.c2005-03-04 23:26:59.0 +0100
+++ linux-fuse/fs/fuse/inode.c  2005-03-04 23:32:36.0 +0100
@@ -446,8 +446,12 @@ static struct dentry *fuse_get_dentry(st
return ERR_PTR(-ESTALE);
 
inode = ilookup5(sb, nodeid, fuse_inode_eq, nodeid);
-   if (!inode || inode-i_generation != generation)
+   if (!inode)
return ERR_PTR(-ESTALE);
+   if (inode-i_generation != generation) {
+   iput(inode);
+   return ERR_PTR(-ESTALE);
+   }
 
entry = d_alloc_anon(inode);
if (!entry) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Andries Brouwer
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote:

 Here's the list of things which we might choose to put into 2.6.11.2.
...
 nfsd--exportfs-reduce-stack-usage.patch
...

Different people want different things with our 2.6.x.y.
I would hope that criteria include (i) patch is obvious,
and (ii) patch fixes an embarrassing flaw.

I see no reason to include random small improvements.

(Always some of these small improvements will be a mistake,
so, in .y, when something is not really broken, don't fix it.
Maybe people were actually seeing stack overflows here?)

Andries



 From: NeilBrown [EMAIL PROTECTED]

 find_exported_dentry() declares
char nbuf[NAME_MAX+1];
 in 2 separate places, and gcc allocates space on the stack for both
 of them.  Having just one of them will suffice, if we can put put
 with its scope.

 Reduces function stack usage on x86-32 from 0x230 to 0x130.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: swsusp: allow resume from initramfs

2005-03-04 Thread Nigel Cunningham
Hi.

On Sat, 2005-03-05 at 09:07, Pavel Machek wrote:
 Hi!
 
You guys are reinventing the wheel a lot at the moment and I'm in the
middle of doing it for x86_64 lowlevel code : Can we see if we can work
a little more closely - perhaps we can get some shared code going that
will allow us to handle these issues without stepping on each others'
feet? In particular, shared code for

- initramfs and initrd support
   
   Its actually done, and it was few strategically placed lines of code
   (like 20 lines). I do not think it can be meaningfully shared.
  
  Mmm. But if we're both putting hooks in the same places...
 
 There are very little hooks... But we may want to make sure we have
 same userland interface. swsusp uses echo 3:5  /sys/power/resume to
 trigger resume from device major 3 minor 5.
 
- lowlevel suspend  resume
   
   This makes very good sense to share. We have i386, x86-64 and ppc
   versions. They simply walk list of pbe's; that should be simple enough
   to be usable for suspend2, too
  
  The CPU save and restore, yes. But I use a different format for
  recording the image metadata (I use bitmaps to record the locations of
  pages). Perhaps I should hasten to mention the bitmaps are discontiguous
  - single pages connected by a kmalloc'd list. The copyback itself will
  need to stay distinct.
 
 Hmm, bitmaps? Okay, then low-level code needs to stay separate. (And
 thats bad, I wanted that one to be shared most).

Mmm. As you might remember, I used extents from 1.0 to save space. The
feedback from the last submission to LKML about getting rid of the
page_alloc.c hooks made me re-examine the use of the memory pool, which
made me re-examine the format in which the data was stored. Switching to
bitmaps meant that after saving the LRU pages, I can recalculate what
remains to be saved without ever changing the result in the process.
(Using extents, there was a small chance that the recalculated metadata
would require an extra extent on an extra page, which means you have to
recalculate everything again :. With discontiguous bitmaps, I get
efficient storage, no need for  order zero allocations and no feedback
whatsoever when recalculating image metadata. Besides removing the
memory pool code, I've already removed some more, and am about to
simplify the code for the remaining extents (for storage metadata). I
hope to also be able to further simplify the image preparation code too.

All that to say Bitmaps were a definite win!. Perhaps I can sell you
on the advantages of using them :

By the way, did you see the effect of the memory eating patch? I didn't
think about it until someone emailed me, but the improvement was 50x
speed in the best case!

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: BIOS overwritten during resume (was: Re: Asus L5D resume on battery power)

2005-03-04 Thread Pavel Machek
Hi!

  Actually, take a look at Nigel's patch. He simply uses PageNosave
  instead of PageLocked -- that is cleaner.
 
 Yes.  I thought about using PG_nosave in the begining, but there's a
 
 BUG_ON(PageReserved(page)  PageNosave(page));
 
 in swsusp.c:saveable() that I just didn't want to trigger.  It seems to me,
 though, that we don't need it any more, do we?

No, we can just kill it. It was if something unexpected happens, bail
out soon.

  He also found a few places where reserved page becomes un-reserved,
  and you probably need to fix those, too.
 
 Yes, I think I'll just port the Nigel's patch to x86-64.  BTW, it's striking
 that we found similar solutions independently (I didn't know the Nigel's
 patch before :-)).
 
 Unfortunately, it turns out that the patch does not fix my problem with random
 reboots during resume on battery power, but I really think that we
 need to mark

:-( too bad.

 non-RAM areas with PG_nosave, at least for sanity reasons (eg to be sure that
 we do not break things by dumping stuff to where we should not write to).

I'm not sure if it is not better to save  restore non-RAM areas, but
it probably just does not matter.
Pavel
-- 
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/


size of /proc/kcore grows?

2005-03-04 Thread Christian
hi,
i've just tried to search for something in the RAM, so i thougt 
/proc/kcore would be a good address to start. i really only wanted to 
grep for raw data throught it, i did not need any specific meta-data.

ok, i checked:
$ ls -lah /proc/kcore
-r  1 root root 256M Mar  4 23:25 /proc/kcore
which makes sense, since i have 256MB RAM.
$ su -
Password:
root$ cp /proc/kcore /data/Incoming/
`/proc/kcore' - `/data/Incoming/kcore'
root$ ls -la /proc/kcore /data/Incoming/kcore
-r  1 root root 1.0G Mar  4 23:26 /data/Incoming/kcore
-r  1 root root 1.0G Mar  4 23:27 /proc/kcore
whooha! /proc/kcore and its new on-disk copy are now both 1GB in size.
how comes? i could imagine, that when cp tried to copy /proc/kcore the 
RAM gets filled with /proc/kcore again, thus doubling it...somehow...but 
cp continued with no errors, why should it double /proc/kcore 
(256MB-512MB) and then again (512MB-1024MB), but stop after this? i 
would've expected cp to never stop copying...

i don't get it,
Christian.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: SVGATextMode on 2.6.11

2005-03-04 Thread Alan Curry
I wrote:

Was SVGATextMode's cursor-setting ability removed as a result of an
intentional change, or might it get fixed? Or might CUR_DEFAULT become
tunable? Maybe another control sequence could make the current cursor
settings the default, like setterm -store does for foreground and background
colors.

I found the cause of this new behavior: font loading. SVGATextMode can be
configured to load a font with consolechars. It does that after setting the
cursor. In 2.6.11 vgacon_adjust_height() was changed to reset the cursor in
addition to the font size. The solution is: disable SVGATextMode's font
loading, and if you want to change the font, do it before you run SVGATextMode.

The second problem remains a mystery:

On another note, the resize function of SVGATextMode has been affected
strangely too. Sometimes, when resizing the screen to a mode larger than
80x25, the video settings come out correctly but the terminal only uses the
first 25 lines, with the bottom of the screen being blank. This one is hard
to reproduce. I can reproduce it by doing a full boot (which includes an
SVGATextMode call from /etc/rcS.d/S60svgatextmode) followed by a manual
SVGATextMode on tty2. The first one works, and the second one screws up the
terminal size. When I try to reproduce that series of events without the call
from /etc/rcS.d, the problem doesn't show up.

In any case, when that problem _does_ show up, it can be fixed by immediately
running the same command again, on the same tty where it just screwed up. And
it never fails twice without an intervening reboot.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [ patch 4/7] drivers/serial/jsm: new serial device driver

2005-03-04 Thread Greg KH
On Fri, Mar 04, 2005 at 04:08:17PM -0500, Wen Xiong wrote:
 +int get_jsm_board_number(void)
 +{
 +struct list_head *tmp;
 +struct jsm_board *cur_board_entry;
 +int adapter_count = 0;
 +u64 lock_flags;
 +
 +spin_lock_irqsave(jsm_board_head_lock, lock_flags);
 +list_for_each(tmp, jsm_board_head) {
 +cur_board_entry =
 +list_entry(tmp, struct jsm_board,
 +jsm_board_entry);
 +adapter_count++;
 +}
 +spin_unlock_irqrestore(jsm_board_head_lock, lock_flags);
 +
 +return adapter_count;
 +}

Should this be static?

And it's returning the number of boards, not the current board number,
right?

And you have a indenting error in the list_for_each() section...

 +static ssize_t jsm_driver_version_show(struct device_driver *ddp, char *buf)
 +{
 + return snprintf(buf, PAGE_SIZE, jsm_version: %s\n, jsm: 
 1.1-1-INKERNEL);

Shouldn't that value also be in MODULE_VERSION()?  And if so, it should
be a #define somewhere.

Also, don't put jsm: in your sysfs files, the file name describes what
the value should be.  That goes for a lot of your sysfs files.

 +static ssize_t jsm_driver_debug_show(struct device_driver *ddp, char *buf)
 +{
 + return snprintf(buf, PAGE_SIZE, 0x%x\n, debug);
 +}

debug is not a nice variable to have in the global namespace :(

Also, why not just make this a module paramater, that way it can be
modified through that interface, and you don't have to create your own?

 +#define JSM_VERIFY_BOARD(p, bd)  \
 + if (!p) \
 + return 0;   \
 + bd = (struct jsm_board *)dev_get_drvdata(p);\

Cast is not needed.

 + if (!bd)\
 + return 0;   \
 + if (bd-state != BOARD_READY)   \
 + return 0;   \

Don't break out of functions from within a macro.  Will cause headaches
for people reviewing your code in the future.

And shouldn't you be returning an error if one of these checks fail?

 +static ssize_t jsm_ports_state_show(struct device *p, char *buf)
 +{
 + struct jsm_board *bd;
 + int count = 0;
 + int i = 0;
 +
 + JSM_VERIFY_BOARD(p, bd);
 +
 + for (i = 0; i  bd-nasync; i++) {
 + count += snprintf(buf + count, PAGE_SIZE - count,
 + %d %s\n, bd-channels[i]-ch_portnum,
 + bd-channels[i]-ch_open_count ? Open : Closed);
 + }
 + return count;

No, make this a per-port value.  You are showing more than one value in
a single file.  You do this for a few other sysfs files :(

And who cares about this value?

 +static ssize_t jsm_ports_baud_show(struct device *p, char *buf)
 +{
 + struct jsm_board *bd;
 + int count = 0;
 + int i = 0;
 +
 + JSM_VERIFY_BOARD(p, bd);
 +
 + for (i = 0; i  bd-nasync; i++) {
 + count +=  snprintf(buf + count, PAGE_SIZE - count,
 + %d %d\n, bd-channels[i]-ch_portnum, 
 bd-channels[i]-ch_old_baud);
 + }
 + return count;
 +}
 +static DEVICE_ATTR(ports_baud, S_IRUSR, jsm_ports_baud_show, NULL);

What's wrong with the standard tty ioctls that return this value, and
the other values you are exporting through sysfs?  What is all of this
data needed for?

 +#define JSM_VERIFY_CHANNEL(p, ch)\
 + if (!p) \
 + return 0;   \
 + ch = (struct jsm_channel *)class_get_devdata(p);\
 + if (!ch)\
 + return 0;   \
 + if (ch-ch_bd-state != BOARD_READY)\
 + return 0;   \

Again, don't put return in a macro, and return an error if there really
is one.

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: swsusp: allow resume from initramfs

2005-03-04 Thread Pavel Machek
Hi!

  Hmm, bitmaps? Okay, then low-level code needs to stay separate. (And
  thats bad, I wanted that one to be shared most).
 
 Mmm. As you might remember, I used extents from 1.0 to save space. The
 feedback from the last submission to LKML about getting rid of the
 page_alloc.c hooks made me re-examine the use of the memory pool, which
 made me re-examine the format in which the data was stored. Switching to
 bitmaps meant that after saving the LRU pages, I can recalculate what
 remains to be saved without ever changing the result in the process.
 (Using extents, there was a small chance that the recalculated metadata
 would require an extra extent on an extra page, which means you have to
 recalculate everything again :. With discontiguous bitmaps, I get
 efficient storage, no need for  order zero allocations and no feedback
 whatsoever when recalculating image metadata. Besides removing the
 memory pool code, I've already removed some more, and am about to
 simplify the code for the remaining extents (for storage metadata). I
 hope to also be able to further simplify the image preparation code too.
 
 All that to say Bitmaps were a definite win!. Perhaps I can sell you
 on the advantages of using them :

Not sure, if one bit goes wrong you put everything in the wrong places
:-). Linklist seems just okay to me, no  4K allocations. I'm not sure
why recalculation is that big problem.

 By the way, did you see the effect of the memory eating patch? I didn't
 think about it until someone emailed me, but the improvement was 50x
 speed in the best case!

Well, more interesting was that you actually freed much more memory
with your patch. *You actually made memory freeing to work*. So yes, I
like that one.
Pavel
-- 
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/


[PATCH] w1: replace obsoleted *sleep_on*

2005-03-04 Thread Greg KH
ChangeSet 1.2084, 2005/03/02 16:59:25-08:00, [EMAIL PROTECTED]

[PATCH] w1: replace obsoleted *sleep_on*

Remove obsoleded *sleep_on*.

Since they are used only to wait for a given flags and awakening
only happens on signals, we can just replace them with
msleep_interruptible.

Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]


 drivers/w1/w1.c |   18 +-
 drivers/w1/w1.h |1 -
 drivers/w1/w1_int.c |1 -
 3 files changed, 5 insertions(+), 15 deletions(-)


diff -Nru a/drivers/w1/w1.c b/drivers/w1/w1.c
--- a/drivers/w1/w1.c   2005-03-04 12:37:58 -08:00
+++ b/drivers/w1/w1.c   2005-03-04 12:37:58 -08:00
@@ -58,7 +58,6 @@
 static pid_t control_thread;
 static int control_needs_exit;
 static DECLARE_COMPLETION(w1_control_complete);
-static DECLARE_WAIT_QUEUE_HEAD(w1_control_wait);
 
 static int w1_master_match(struct device *dev, struct device_driver *drv)
 {
@@ -649,7 +648,7 @@
struct w1_slave *sl;
struct w1_master *dev;
struct list_head *ent, *ment, *n, *mn;
-   int err, have_to_wait = 0, timeout;
+   int err, have_to_wait = 0;
 
daemonize(w1_control);
allow_signal(SIGTERM);
@@ -657,11 +656,8 @@
while (!control_needs_exit || have_to_wait) {
have_to_wait = 0;
 
-   timeout = w1_timeout*HZ;
-   do {
-   timeout = 
interruptible_sleep_on_timeout(w1_control_wait, timeout);
-   try_to_freeze(PF_FREEZE);
-   } while (!signal_pending(current)  (timeout  0));
+   try_to_freeze(PF_FREEZE);
+   msleep_interruptible(w1_timeout * 1000);
 
if (signal_pending(current))
flush_signals(current);
@@ -721,7 +717,6 @@
 int w1_process(void *data)
 {
struct w1_master *dev = (struct w1_master *) data;
-   unsigned long timeout;
struct list_head *ent, *n;
struct w1_slave *sl;
 
@@ -729,11 +724,8 @@
allow_signal(SIGTERM);
 
while (!dev-need_exit) {
-   timeout = w1_timeout*HZ;
-   do {
-   timeout = interruptible_sleep_on_timeout(dev-kwait, 
timeout);
-   try_to_freeze(PF_FREEZE);
-   } while (!signal_pending(current)  (timeout  0));
+   try_to_freeze(PF_FREEZE);
+   msleep_interruptible(w1_timeout * 1000);
 
if (signal_pending(current))
flush_signals(current);
diff -Nru a/drivers/w1/w1.h b/drivers/w1/w1.h
--- a/drivers/w1/w1.h   2005-03-04 12:37:58 -08:00
+++ b/drivers/w1/w1.h   2005-03-04 12:37:58 -08:00
@@ -115,7 +115,6 @@
 
int need_exit;
pid_t   kpid;
-   wait_queue_head_t   kwait;
struct semaphoremutex;
 
struct device_driver*driver;
diff -Nru a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
--- a/drivers/w1/w1_int.c   2005-03-04 12:37:58 -08:00
+++ b/drivers/w1/w1_int.c   2005-03-04 12:37:58 -08:00
@@ -74,7 +74,6 @@
INIT_LIST_HEAD(dev-slist);
init_MUTEX(dev-mutex);
 
-   init_waitqueue_head(dev-kwait);
init_completion(dev-dev_released);
init_completion(dev-dev_exited);
 

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


[patch 3/5] ppc32: Compilation fixes for Ebony, Luan and Ocotea

2005-03-04 Thread akpm

From: Matt Porter [EMAIL PROTECTED]

this patch fixes the problem, that the current kernel (linux-2.6.11-rc5)
could not be compiled, when support for early boot texts over serial port
(CONFIG_SERIAL_TEXT_DEBUG=y) is active.

Signed-off-by: Gerhard Jaeger [EMAIL PROTECTED]
Signed-off-by: Matt Porter [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/arch/ppc/platforms/4xx/ebony.h  |4 ++--
 25-akpm/arch/ppc/platforms/4xx/luan.h   |6 +++---
 25-akpm/arch/ppc/platforms/4xx/ocotea.h |4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff -puN 
arch/ppc/platforms/4xx/ebony.h~ppc32-compilation-fixes-for-ebony-luan-and-ocotea
 arch/ppc/platforms/4xx/ebony.h
--- 
25/arch/ppc/platforms/4xx/ebony.h~ppc32-compilation-fixes-for-ebony-luan-and-ocotea
 2005-03-04 13:16:17.0 -0800
+++ 25-akpm/arch/ppc/platforms/4xx/ebony.h  2005-03-04 13:16:17.0 
-0800
@@ -61,8 +61,8 @@
  */
 
 /* OpenBIOS defined UART mappings, used before early_serial_setup */
-#define UART0_IO_BASE  (u8 *) 0xE200
-#define UART1_IO_BASE  (u8 *) 0xE300
+#define UART0_IO_BASE  0xE200
+#define UART1_IO_BASE  0xE300
 
 /* external Epson SG-615P */
 #define BASE_BAUD  691200
diff -puN 
arch/ppc/platforms/4xx/luan.h~ppc32-compilation-fixes-for-ebony-luan-and-ocotea 
arch/ppc/platforms/4xx/luan.h
--- 
25/arch/ppc/platforms/4xx/luan.h~ppc32-compilation-fixes-for-ebony-luan-and-ocotea
  2005-03-04 13:16:17.0 -0800
+++ 25-akpm/arch/ppc/platforms/4xx/luan.h   2005-03-04 13:16:17.0 
-0800
@@ -47,9 +47,9 @@
 #define RS_TABLE_SIZE  3
 
 /* PIBS defined UART mappings, used before early_serial_setup */
-#define UART0_IO_BASE  (u8 *) 0xa200
-#define UART1_IO_BASE  (u8 *) 0xa300
-#define UART2_IO_BASE  (u8 *) 0xa600
+#define UART0_IO_BASE  0xa200
+#define UART1_IO_BASE  0xa300
+#define UART2_IO_BASE  0xa600
 
 #define BASE_BAUD  11059200
 #define STD_UART_OP(num)   \
diff -puN 
arch/ppc/platforms/4xx/ocotea.h~ppc32-compilation-fixes-for-ebony-luan-and-ocotea
 arch/ppc/platforms/4xx/ocotea.h
--- 
25/arch/ppc/platforms/4xx/ocotea.h~ppc32-compilation-fixes-for-ebony-luan-and-ocotea
2005-03-04 13:16:17.0 -0800
+++ 25-akpm/arch/ppc/platforms/4xx/ocotea.h 2005-03-04 13:16:17.0 
-0800
@@ -56,8 +56,8 @@
 #define RS_TABLE_SIZE  2
 
 /* OpenBIOS defined UART mappings, used before early_serial_setup */
-#define UART0_IO_BASE  (u8 *) 0xE200
-#define UART1_IO_BASE  (u8 *) 0xE300
+#define UART0_IO_BASE  0xE200
+#define UART1_IO_BASE  0xE300
 
 #define BASE_BAUD  11059200/16
 #define STD_UART_OP(num)   \
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] I2C: Fix some gcc 4.0 compile failures and warnings

2005-03-04 Thread Mickey Stein
Greg KH wrote:
ChangeSet 1.2108, 2005/03/02 15:02:27-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Fix some gcc 4.0 compile failures and warnings
gcc 4.0.x cvs seems to dislike include/linux/i2c.h file and others due
to a current gcc 4.0.x change having to do with array declarations.
Example error msg:   include/linux/i2c.h:{55,194} error: array type has
incomplete element type
A. Daplas has recently done a workaround for this on another header
file. A thread discussing this can be found by following the link below:
http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html
The patch changes the array(struct i2c_msg) declaration used by
*i2c_transfer and *master_xfer from struct i2c_msg msg[] format to
struct i2c_msg *msg.
After some grepping, I came up with about a dozen files that used the
format disliked by gcc4 that're addressed by the attached patch.
Tested on gcc 3.x  gcc 4.x by configuring kernel with all i2c switches
enabled as module, and saw no errors or warnings in i2c.
Signed-off-by: Mickey Stein [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
Documentation/i2c/writing-clients |2 +-
drivers/i2c/algos/i2c-algo-ite.c  |4 ++--
drivers/i2c/algos/i2c-algo-pca.c  |2 +-
drivers/i2c/algos/i2c-algo-pcf.c  |2 +-
drivers/i2c/algos/i2c-algo-sgi.c  |2 +-
drivers/i2c/busses/i2c-au1550.c   |2 +-
drivers/i2c/busses/i2c-ibm_iic.c  |2 +-
drivers/i2c/busses/i2c-iop3xx.c   |2 +-
drivers/i2c/busses/i2c-keywest.c  |2 +-
drivers/i2c/busses/i2c-mpc.c  |2 +-
drivers/i2c/busses/i2c-s3c2410.c  |4 ++--
drivers/i2c/i2c-core.c|2 +-
drivers/media/common/saa7146_i2c.c|8 
drivers/media/dvb/b2c2/skystar2.c |2 +-
drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c  |2 +-
drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |2 +-
drivers/media/video/bttv-i2c.c|2 +-
drivers/media/video/saa7134/saa7134-i2c.c |2 +-
include/linux/i2c.h   |4 ++--
include/media/saa7146.h   |2 +-
20 files changed, 26 insertions(+), 26 deletions(-)
diff -Nru a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
--- a/Documentation/i2c/writing-clients	2005-03-04 12:23:35 -08:00
+++ b/Documentation/i2c/writing-clients	2005-03-04 12:23:35 -08:00
@@ -638,7 +638,7 @@
parameter contains the bytes the read/write, the third the length of the
buffer. Returned is the actual number of bytes read/written.
  
-  extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
+  extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,
  int num);

This sends a series of messages. Each message can be a read or write,
diff -Nru a/drivers/i2c/algos/i2c-algo-ite.c b/drivers/i2c/algos/i2c-algo-ite.c
--- a/drivers/i2c/algos/i2c-algo-ite.c	2005-03-04 12:23:35 -08:00
+++ b/drivers/i2c/algos/i2c-algo-ite.c	2005-03-04 12:23:35 -08:00
@@ -490,7 +490,7 @@
 * condition.
 */
#if 0
-static int iic_combined_transaction(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[], int num) 
+static int iic_combined_transaction(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs, int num) 
{
   int i;
   struct i2c_msg *pmsg;
@@ -600,7 +600,7 @@
 * verify that the bus is not busy or in some unknown state.
 */
static int iic_xfer(struct i2c_adapter *i2c_adap,
-		struct i2c_msg msgs[], 
+		struct i2c_msg *msgs, 
		int num)
{
	struct i2c_algo_iic_data *adap = i2c_adap-algo_data;
diff -Nru a/drivers/i2c/algos/i2c-algo-pca.c b/drivers/i2c/algos/i2c-algo-pca.c
--- a/drivers/i2c/algos/i2c-algo-pca.c	2005-03-04 12:23:35 -08:00
+++ b/drivers/i2c/algos/i2c-algo-pca.c	2005-03-04 12:23:35 -08:00
@@ -178,7 +178,7 @@
}

static int pca_xfer(struct i2c_adapter *i2c_adap,
-struct i2c_msg msgs[],
+struct i2c_msg *msgs,
int num)
{
struct i2c_algo_pca_data *adap = i2c_adap-algo_data;
diff -Nru a/drivers/i2c/algos/i2c-algo-pcf.c b/drivers/i2c/algos/i2c-algo-pcf.c
--- a/drivers/i2c/algos/i2c-algo-pcf.c  2005-03-04 12:23:35 -08:00
+++ b/drivers/i2c/algos/i2c-algo-pcf.c  2005-03-04 12:23:35 -08:00
@@ -332,7 +332,7 @@
}
static int pcf_xfer(struct i2c_adapter *i2c_adap,
-		struct i2c_msg msgs[], 
+		struct i2c_msg *msgs, 
		int num)
{
	struct i2c_algo_pcf_data *adap = i2c_adap-algo_data;
diff -Nru a/drivers/i2c/algos/i2c-algo-sgi.c b/drivers/i2c/algos/i2c-algo-sgi.c
--- a/drivers/i2c/algos/i2c-algo-sgi.c	2005-03-04 12:23:35 -08:00
+++ b/drivers/i2c/algos/i2c-algo-sgi.c	2005-03-04 12:23:35 -08:00
@@ -131,7 +131,7 @@
	return 0;
}

-static int sgi_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[],
+static int sgi_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg 

Re: [PATCH] 2.6.11-mm1 ext3 writepages support for writeback mode

2005-03-04 Thread Andrew Morton
Badari Pulavarty [EMAIL PROTECTED] wrote:

 Hi Andrew,
 
 Here is the 2.6.11-mm1 patch for adding writepages support
 for ext3 writeback mode. Could you include it in -mm tree ?

spose so.  Does it work?

Do you have any benchmarking results handy?

 +static int
 +ext3_writeback_writepages(struct address_space *mapping, 
 + struct writeback_control *wbc)
 +{
 + struct inode *inode = mapping-host;
 + handle_t *handle = NULL;
 + int err, ret = 0;
 +
 + if (!mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
 + return ret;

Can we please add a comment explaining why this is here?  I've already
forgotten why we put it there.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] convert pci_dev-slot_name usage to pci_name()

2005-03-04 Thread Jeff Garzik
Greg KH wrote:
On Fri, Mar 04, 2005 at 04:00:29PM -0500, Jeff Garzik wrote:
Greg KH wrote:
ChangeSet 1.1998.11.6, 2005/02/07 14:36:14-08:00, [EMAIL PROTECTED]
[PATCH] convert pci_dev-slot_name usage to pci_name()
Prepare for removal of pci_dev-slot_name
Can you split this up and send me the drivers/net/* portion?

Here ya go.
thanks,
greg k-h
Thanks, applied.
Jeff

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


Re: [SATA] libata-dev queue updated

2005-03-04 Thread Joerg Sommrey
On Fri, Mar 04, 2005 at 03:43:38PM -0500, Jeff Garzik wrote:
 Joerg Sommrey wrote:
 On Fri, Mar 04, 2005 at 01:07:16PM -0500, Jeff Garzik wrote:
 
 Joerg Sommrey wrote:
 
 On Fri, Mar 04, 2005 at 02:10:14AM -0500, Jeff Garzik wrote:
 
 
 Joerg Sommrey wrote:
 
 
 On Thu, Mar 03, 2005 at 11:09:26PM -0500, Jeff Garzik wrote:
 
 
 
 Joerg Sommrey wrote:
 
 
 
 On Wed, Mar 02, 2005 at 05:43:59PM -0500, Jeff Garzik wrote:
 
 
 
 
 Joerg Sommrey wrote:
 
 
 
 
 Jeff Garzik wrote:
 
 
 
 
 Patch:
 http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.11-rc5-bk4-libata-dev1.patch.bz2
 
 
 Still not usable here.  The same errors as before when backing up:
 
 Please try 2.6.11 without any patches.
 
 Plain 2.6.11 doesn't work either.  All of 2.6.10-ac11, 2.6.11-rc5,
 2.6.11-rc5 + 2.6.11-rc5-bk4-libata-dev1.patch and 2.6.11 fail with 
 the
 same symptoms. 
 
 Reverting to stable 2.6.10-ac8 :-)
 
 Does reverting the attached patch in 2.6.11 (apply with patch -R) fix 
 things?
 
 
 
 Still the same with this patch reverted.
 
 Does reverting the attached patch in 2.6.11 fix things?  (apply with 
 patch -R)
 
 This patch reverts the entire libata back to 2.6.10.
 
 
 I'm confused.  Still the same with everything reverted.  What shall I do
 now?
 
 Well, first, thanks for your patience in narrowing this down.
 
 This means we have eliminated libata as a problem source, but we still 
 have the rest of the kernel go to through :)
 
 Try disabling ACPI with 'acpi=off' or 'pci=biosirq' to see if that fixes 
 things.
 
 
 I tried both settings with plain 2.6.11. Almost the same results, in my
 impression apci=off causes the failure to appear even faster.
 
 Just to make sure I have things right, please tell me if this is correct:
 
 * 2.6.10 vanilla works
 
 * 2.6.11 vanilla does not work
 
 * 2.6.11 vanilla + 2.6.10 libata does not work
   [2.6.10 libata == reverting all libata changes]
 
 Is that all correct?

Thanks for asking these precise questions.  After double-checking
everything I found a typo in my configuration that changes things a bit.
I repeated some tests and the correct answers are now:
* 2.6.10 vanillaworks
* 2.6.10-ac8works
* 2.6.10-ac11   does not work
* 2.6.11 vanilladoes not work
* 2.6.11 w/o promise.patch  does not work
* 2.6.11 + 2.6.10 libataworks!

This looks much more consistent to me but brings the case back to
libata.

-jo

-- 
-rw-r--r--  1 jo users 63 2005-03-04 22:48 /home/jo/.signature
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] FUSE: use after free fix

2005-03-04 Thread Miklos Szeredi
Hi Andrew!

I should have known that bragging about the stability of FUSE will get
me into trouble.

This patch fixes a use after free bug, which could in theory cause
memory corruption.  It was actually found with DEBUG_PAGEALLOC by
Magnus Johansson. 

Please apply.

Thanks,
Miklos

Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]

diff -rup linux-2.6.11-mm1/fs/fuse/dev.c linux-fuse/fs/fuse/dev.c
--- linux-2.6.11-mm1/fs/fuse/dev.c  2005-03-04 23:26:59.0 +0100
+++ linux-fuse/fs/fuse/dev.c2005-03-04 23:32:36.0 +0100
@@ -121,12 +121,11 @@ struct fuse_req *fuse_get_request_nonint
 
 static void fuse_putback_request(struct fuse_conn *fc, struct fuse_req *req)
 {
-   if (!req-preallocated)
-   fuse_request_free(req);
-
spin_lock(fuse_lock);
if (req-preallocated)
list_add(req-list, fc-unused_list);
+   else
+   fuse_request_free(req);
 
if (fc-outstanding_debt)
fc-outstanding_debt--;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Andrew Morton
Greg KH [EMAIL PROTECTED] wrote:

 On Fri, Mar 04, 2005 at 01:59:33PM -0800, Andrew Morton wrote:
  Linus Torvalds [EMAIL PROTECTED] wrote:
  
   
   
   On Fri, 4 Mar 2005, Andrew Morton wrote:
 
  Ok, care to forward them on?

Sure.  How do they get to Linus?
   
   I'll just pull from the sucker-tree. 
   
  
  That tree has the not-for-linus raid6 fix and the not-for-linus i8042 fix.
 
 Then when the authors of those patches go to submit the fix to Linus,
 they can revert them, or bk can handle the merge properly :)
 

Well yeah.  That's what I mentioned yesterday - I revert the notfix while
merging up the realfix.

OK for really small stuff, but it could get messy.  We'll see.

But we end up with a cset in the permanent kernel history which simply
should not have been there.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH/RFC] I/O-check interface for driver's error handling

2005-03-04 Thread Pavel Machek
Hi!

  Hmm, before we go async way (nasty locking, no?) could driver simply
  ask did something bad happen while I was sleeping? at begining of each
  function?
  
  For DMA problems, driver probably has its own, timer-based,
  something is wrong timer, anyway, no?
 
 No, there is no nasty locking, when the callback happens, pretty much
 all IOs have stopped anyway due to errors, and we aren't on a critical
 code path.

What prevents driver from being run on another CPU, maybe just doing
mdelay() between hardware accesses? 

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


[PATCH][Trivial] Kconfig help text update for config FB_NVIDIA

2005-03-04 Thread Jesper Juhl

Tiny trivial patch to fix up the help text for config FB_NVIDIA, cut 
against 2.6.11-mm1


Signed-off-by: Jesper Juhl [EMAIL PROTECTED]

--- linux-2.6.11-mm1-orig/drivers/video/Kconfig 2005-03-05 00:39:33.0 
+0100
+++ linux-2.6.11-mm1/drivers/video/Kconfig  2005-03-05 00:56:36.0 
+0100
@@ -619,12 +619,11 @@ config FB_NVIDIA
help
  This driver supports graphics boards with the nVidia chips, TNT
  and newer. For very old chipsets, such as the RIVA128, then use
- the the rivafb.
+ the rivafb.
  Say Y if you have such a graphics board.
 
  To compile this driver as a module, choose M here: the
  module will be called nvidiafb.
-  none yet
 
 config FB_NVIDIA_I2C
bool Enable DDC Support


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 IrDA] support NSC PC8738x

2005-03-04 Thread Jean Tourrilhes
ir261_nsc_38x.diff :
~~
Original patch from Steffen Pingel
o [FEATURE] support NSC PC8738x chipset (IBM x40  ...)
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]


diff -u -p linux/drivers/net/irda/nsc-ircc.d0.c  
linux/drivers/net/irda/nsc-ircc.c
--- linux/drivers/net/irda/nsc-ircc.d0.cFri Feb  4 16:17:07 2005
+++ linux/drivers/net/irda/nsc-ircc.c   Mon Feb  7 14:35:05 2005
@@ -94,16 +94,13 @@ static nsc_chip_t chips[] = {
  nsc_ircc_probe_108, nsc_ircc_init_108 },
{ PC87338, { 0x398, 0x15c, 0x2e }, 0x08, 0xb0, 0xf8, 
  nsc_ircc_probe_338, nsc_ircc_init_338 },
+   /* Contributed by Steffen Pingel - IBM X40 */
+   { PC8738x, { 0x164e, 0x4e, 0x0 }, 0x20, 0xf4, 0xff,
+ nsc_ircc_probe_39x, nsc_ircc_init_39x },
/* Contributed by Jan Frey - IBM A30/A31 */
{ PC8739x, { 0x2e, 0x4e, 0x0 }, 0x20, 0xea, 0xff, 
  nsc_ircc_probe_39x, nsc_ircc_init_39x },
{ NULL }
-#if 0
-   /* Probably bogus, PC8739x should be the real thing. Jean II */
-   /* Contributed by Kevin Thayer - OmniBook 6100 */
-   { PC87338?, { 0x2e, 0x15c, 0x398 }, 0x08, 0x00, 0xf8, 
- nsc_ircc_probe_338, nsc_ircc_init_338 },
-#endif
 };
 
 /* Max 4 instances 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] 2.6.11-mm1 nobh support for ext3 writeback mode

2005-03-04 Thread Badari Pulavarty
On Fri, 2005-03-04 at 16:23, Andrew Morton wrote:
 Badari Pulavarty [EMAIL PROTECTED] wrote:
 
  @@ -1646,13 +1659,34 @@ static int ext3_block_truncate_page(hand
  unsigned blocksize, iblock, length, pos;
  struct inode *inode = mapping-host;
  struct buffer_head *bh;
  -   int err;
  +   int err = 0;
  void *kaddr;
   
  blocksize = inode-i_sb-s_blocksize;
  length = blocksize - (offset  (blocksize - 1));
  iblock = index  (PAGE_CACHE_SHIFT - inode-i_sb-s_blocksize_bits);
   
  +   if (test_opt(inode-i_sb, NOBH)  !page_has_buffers(page)) {
  +   if (!PageUptodate(page)) {
  +   err = mpage_readpage(page, ext3_get_block);
  +   if ((err == 0)  !PageUptodate(page))
  +   wait_on_page_locked(page);
  +   lock_page(page);
  +   }
  +   if (err == 0  PageUptodate(page)) {
  +   kaddr = kmap_atomic(page, KM_USER0);
  +   memset(kaddr + offset, 0, length);
  +   flush_dcache_page(page);
  +   kunmap_atomic(kaddr, KM_USER0);
  +   set_page_dirty(page);
  +   goto unlock;
  +   }
  +   /* 
 
 What's all this doing?  (It needs comments please - it's very unobvious).

All its trying to do is - to make sure the page is uptodate so that
it can zero out the portion thats needed. 

I can do getblock() and ll_rw_block(READ) instead. I was
trying to re-use the code and mpage_readpage() drops the lock.
What do you think ?


 
 Dropping and reacquiring the page lock in the middle of the truncate there
 is a bit of a worry - need to think about that.
 
 Err, yes, it's buggy - page reclaim can come in, grab the page lock and
 whip the page off the mapping.  We end up with an anonymous page and we
 then start trying to write it into the file and all sorts of things.
 
 
 This bit:
 
   if ((err == 0)  !PageUptodate(page))
   wait_on_page_locked(page);
 
 can simply be removed.  We're about to lock the page anyway.


Thanks,
Badari

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Barry K. Nathan
On Fri, Mar 04, 2005 at 12:07:23PM -0700, Steven Cole wrote:
 
 Here's an idea which might just be too simple, but here it is anyway:
 
 Modifiy the bk snapshot scripts to name the 2.6.x series snapshots as -PREy
 instead of -BKy.  That way, the general population of users will see
 the -bk snapshots as -pre releases.  According to Linus, pre == bk.  So,
 name them as such.

I heartily second this!! If pre == bk, then make it pre!

 Linus, wait for at least two weeks before releasing the first -rc.
 That way, the bulk on the thundering herd of patches will be hopefully
 be merged by then.  And users will have 2.6.x-PRE[1..14] to test.
 The hard part for the kernel.org script writer might be to disable
 the -bk/-pre snapshot once the first -rc is out.

Errh... personally, I find the -rc-bk snapshots to be useful sync
points. They're also what seems to make it into davej's
rawhide/fc-devel Fedora testing kernels. (Perhaps those don't get
widely tested, but they do get *some* testing -- e.g. they're how I
managed to hit (and get fixed) the TCP stack overflow.)

I guess the best thing would be for the script to revert to the current
(-bk) naming scheme once -rc1 is out. Otherwise it would need to do,
say, 2.6.12-rc2-pre1 instead of 2.6.12-rc1-bk1, and while that seems
natural to me, I don't know how the rest of the planet's human population
would react...

-Barry K. Nathan [EMAIL PROTECTED]

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


Re: [PATCH] 2.6.11-mm1 nobh support for ext3 writeback mode

2005-03-04 Thread Andrew Morton
Badari Pulavarty [EMAIL PROTECTED] wrote:

 @@ -1646,13 +1659,34 @@ static int ext3_block_truncate_page(hand
   unsigned blocksize, iblock, length, pos;
   struct inode *inode = mapping-host;
   struct buffer_head *bh;
 - int err;
 + int err = 0;
   void *kaddr;
  
   blocksize = inode-i_sb-s_blocksize;
   length = blocksize - (offset  (blocksize - 1));
   iblock = index  (PAGE_CACHE_SHIFT - inode-i_sb-s_blocksize_bits);
  
 + if (test_opt(inode-i_sb, NOBH)  !page_has_buffers(page)) {
 + if (!PageUptodate(page)) {
 + err = mpage_readpage(page, ext3_get_block);
 + if ((err == 0)  !PageUptodate(page))
 + wait_on_page_locked(page);
 + lock_page(page);
 + }
 + if (err == 0  PageUptodate(page)) {
 + kaddr = kmap_atomic(page, KM_USER0);
 + memset(kaddr + offset, 0, length);
 + flush_dcache_page(page);
 + kunmap_atomic(kaddr, KM_USER0);
 + set_page_dirty(page);
 + goto unlock;
 + }
 + /* 

What's all this doing?  (It needs comments please - it's very unobvious).

Dropping and reacquiring the page lock in the middle of the truncate there
is a bit of a worry - need to think about that.

Err, yes, it's buggy - page reclaim can come in, grab the page lock and
whip the page off the mapping.  We end up with an anonymous page and we
then start trying to write it into the file and all sorts of things.


This bit:

if ((err == 0)  !PageUptodate(page))
wait_on_page_locked(page);

can simply be removed.  We're about to lock the page anyway.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2.6 IrDA] arbitrary lsap connect

2005-03-04 Thread Jean Tourrilhes
ir261_connect_lsap-2.diff :
~
Original patch from Iavor Fetvadjie
o [FEATURE] allow IrDA socket to connect on arbitrary LSAPs
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]


diff -u -p linux/net/irda/af_irda.d0.c linux/net/irda/af_irda.c
--- linux/net/irda/af_irda.d0.c Fri Feb  4 14:45:33 2005
+++ linux/net/irda/af_irda.cFri Feb  4 15:16:26 2005
@@ -1012,11 +1012,23 @@ static int irda_connect(struct socket *s
self-daddr = addr-sir_addr;
IRDA_DEBUG(1, %s(), daddr = %08x\n, __FUNCTION__, 
self-daddr);
 
-   /* Query remote LM-IAS */
-   err = irda_find_lsap_sel(self, addr-sir_name);
-   if (err) {
-   IRDA_DEBUG(0, %s(), connect failed!\n, __FUNCTION__);
-   return err;
+   /* If we don't have a valid service name, we assume the
+* user want to connect on a specific LSAP. Prevent
+* the use of invalid LSAPs (IrLMP 1.1 p10). Jean II */
+   if((addr-sir_name[0] != '\0') ||
+  (addr-sir_lsap_sel = 0x70)) {
+   /* Query remote LM-IAS using service name */
+   err = irda_find_lsap_sel(self, addr-sir_name);
+   if (err) {
+   IRDA_DEBUG(0, %s(), connect failed!\n, 
__FUNCTION__);
+   return err;
+   }
+   } else {
+   /* Directly connect to the remote LSAP
+* specified by the sir_lsap field.
+* Please use with caution, in IrDA LSAPs are
+* dynamic and there is no well-known LSAP. */
+   self-dtsap_sel = addr-sir_lsap_sel;
}
}
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 IrDA] cleanup obsolete construct in IrCOMM

2005-03-04 Thread Jean Tourrilhes
ir261_ircomm_write_cleanup.diff :
~~~
o [FEATURE] cleanup some construct obsoleted by Linus's patch
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]



diff -u -p linux/net/irda/ircomm/ircomm_tty.d0.c 
linux/net/irda/ircomm/ircomm_tty.c
--- linux/net/irda/ircomm/ircomm_tty.d0.c   Fri Feb  4 16:19:03 2005
+++ linux/net/irda/ircomm/ircomm_tty.c  Fri Feb  4 16:20:54 2005
@@ -671,10 +671,9 @@ static void ircomm_tty_do_softint(void *
  *accepted for writing. This routine is mandatory.
  */
 static int ircomm_tty_write(struct tty_struct *tty,
-   const unsigned char *ubuf, int count)
+   const unsigned char *buf, int count)
 {
struct ircomm_tty_cb *self = (struct ircomm_tty_cb *) tty-driver_data;
-   unsigned char *kbuf;/* Buffer in kernel space */
unsigned long flags;
struct sk_buff *skb;
int tailroom = 0;
@@ -714,9 +713,6 @@ static int ircomm_tty_write(struct tty_s
if (count  1)
return 0;
 
-   /* The buffer is already in kernel space */
-   kbuf = (unsigned char *) ubuf;
-
/* Protect our manipulation of self-tx_skb and related */
spin_lock_irqsave(self-spinlock, flags);
 
@@ -779,7 +775,7 @@ static int ircomm_tty_write(struct tty_s
}
 
/* Copy data */
-   memcpy(skb_put(skb,size), kbuf + len, size);
+   memcpy(skb_put(skb,size), buf + len, size);
 
count -= size;
len += size;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2.6 IrDA] Mark exit code properly in VIA driver

2005-03-04 Thread Jean Tourrilhes
irXXX_via_devexit.diff :
~~
Patch from Randy Dunlap
o [CORRECT] Mark exit code properly in VIA driver
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]



diff -Naurp ./drivers/net/irda/via-ircc.c~irda_via_devexit 
./drivers/net/irda/via-ircc.c
--- ./drivers/net/irda/via-ircc.c~irda_via_devexit  2004-12-24 
13:33:47.0 -0800
+++ ./drivers/net/irda/via-ircc.c   2005-01-06 21:18:49.742203456 -0800
@@ -83,7 +83,7 @@ static struct via_ircc_cb *dev_self[] = 
 
 /* Some prototypes */
 static int via_ircc_open(int i, chipio_t * info, unsigned int id);
-static int __exit via_ircc_close(struct via_ircc_cb *self);
+static int via_ircc_close(struct via_ircc_cb *self);
 static int via_ircc_dma_receive(struct via_ircc_cb *self);
 static int via_ircc_dma_receive_complete(struct via_ircc_cb *self,
 int iobase);
@@ -111,7 +111,7 @@ static void hwreset(struct via_ircc_cb *
 static int via_ircc_dma_xmit(struct via_ircc_cb *self, u16 iobase);
 static int upload_rxdata(struct via_ircc_cb *self, int iobase);
 static int __devinit via_init_one (struct pci_dev *pcidev, const struct 
pci_device_id *id);
-static void __exit via_remove_one (struct pci_dev *pdev);
+static void __devexit via_remove_one (struct pci_dev *pdev);
 
 /* FIXME : Should use udelay() instead, even if we are x86 only - Jean II */
 static void iodelay(int udelay)
@@ -140,7 +140,7 @@ static struct pci_driver via_driver = {
.name   = VIA_MODULE_NAME,
.id_table   = via_pci_tbl,
.probe  = via_init_one,
-   .remove = via_remove_one,
+   .remove = __devexit_p(via_remove_one),
 };
 
 
@@ -273,7 +273,7 @@ static int __devinit via_init_one (struc
  *Close all configured chips
  *
  */
-static void __exit via_ircc_clean(void)
+static void via_ircc_clean(void)
 {
int i;
 
@@ -285,7 +285,7 @@ static void __exit via_ircc_clean(void)
}
 }
 
-static void __exit via_remove_one (struct pci_dev *pdev)
+static void __devexit via_remove_one (struct pci_dev *pdev)
 {
IRDA_DEBUG(3, %s()\n, __FUNCTION__);
 
@@ -468,7 +468,7 @@ static __devinit int via_ircc_open(int i
  *Close driver instance
  *
  */
-static int __exit via_ircc_close(struct via_ircc_cb *self)
+static int via_ircc_close(struct via_ircc_cb *self)
 {
int iobase;
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 IrDA] remove unneeded EXPORT_SYMBOL's from irport.c

2005-03-04 Thread Jean Tourrilhes
irXXX_irport_exports.diff :
~
Patch from Adrian Bunk
o [FEATURE] make needlessly global code static
o [FEATURE] remove unneeded EXPORT_SYMBOL's from irport.c
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]


--- linux-2.6.11-rc3-mm2-full/drivers/net/irda/irtty-sir.c.old  2005-02-16 
15:40:41.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/irda/irtty-sir.c  2005-02-16 
15:40:52.0 +0100
@@ -413,7 +413,7 @@
 
 /* --- */
 
-struct sir_driver sir_tty_drv = {
+static struct sir_driver sir_tty_drv = {
.owner  = THIS_MODULE,
.driver_name= sir_tty,
.start_dev  = irtty_start_dev,
--- linux-2.6.11-rc3-mm2-full/drivers/net/irda/smsc-ircc2.c.old 2005-02-16 
15:41:08.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/irda/smsc-ircc2.c 2005-02-16 
15:41:17.0 +0100
@@ -203,7 +203,7 @@
 
 /* Transceivers for SMSC-ircc */
 
-smsc_transceiver_t smsc_transceivers[]=
+static smsc_transceiver_t smsc_transceivers[]=
 {
{ Toshiba Satellite 1800 (GP data pin select), 
smsc_ircc_set_transceiver_toshiba_sat1800, 
smsc_ircc_probe_transceiver_toshiba_sat1800},
{ Fast pin select, 
smsc_ircc_set_transceiver_smsc_ircc_fast_pin_select, 
smsc_ircc_probe_transceiver_smsc_ircc_fast_pin_select},
--- linux-2.6.11-rc3-mm2-full/drivers/net/irda/irport.h.old 2005-02-16 
15:42:36.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/irda/irport.h 2005-02-16 
15:43:24.0 +0100
@@ -77,14 +77,4 @@
int (*interrupt)(int irq, void *dev_id, struct pt_regs *regs);
 };
 
-struct irport_cb *irport_open(int i, unsigned int iobase, unsigned int irq);
-int  irport_close(struct irport_cb *self);
-void irport_start(struct irport_cb *self);
-void irport_stop(struct irport_cb *self);
-void irport_change_speed(void *priv, __u32 speed);
-irqreturn_t irport_interrupt(int irq, void *dev_id, struct pt_regs *regs);
-int  irport_hard_xmit(struct sk_buff *skb, struct net_device *dev);
-int  irport_net_open(struct net_device *dev);
-int  irport_net_close(struct net_device *dev);
-
 #endif /* IRPORT_H */
--- linux-2.6.11-rc3-mm2-full/drivers/net/irda/irport.c.old 2005-02-16 
15:43:34.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/irda/irport.c 2005-02-16 
15:49:06.0 +0100
@@ -87,50 +87,14 @@
 static int irport_change_speed_complete(struct irda_task *task);
 static void irport_timeout(struct net_device *dev);
 
-EXPORT_SYMBOL(irport_open);
-EXPORT_SYMBOL(irport_close);
-EXPORT_SYMBOL(irport_start);
-EXPORT_SYMBOL(irport_stop);
-EXPORT_SYMBOL(irport_interrupt);
-EXPORT_SYMBOL(irport_hard_xmit);
-EXPORT_SYMBOL(irport_timeout);
-EXPORT_SYMBOL(irport_change_speed);
-EXPORT_SYMBOL(irport_net_open);
-EXPORT_SYMBOL(irport_net_close);
+static irqreturn_t irport_interrupt(int irq, void *dev_id,
+   struct pt_regs *regs);
+static int irport_hard_xmit(struct sk_buff *skb, struct net_device *dev);
+static void irport_change_speed(void *priv, __u32 speed);
+static int irport_net_open(struct net_device *dev);
+static int irport_net_close(struct net_device *dev);
 
-static int __init irport_init(void)
-{
-   int i;
-
-   for (i=0; (io[i]  2000)  (i  4); i++) {
-   if (irport_open(i, io[i], irq[i]) != NULL)
-   return 0;
-   }
-   /* 
-* Maybe something failed, but we can still be usable for FIR drivers 
-*/
-   return 0;
-}
-
-/*
- * Function irport_cleanup ()
- *
- *Close all configured ports
- *
- */
-static void __exit irport_cleanup(void)
-{
-   int i;
-
-IRDA_DEBUG( 4, %s()\n, __FUNCTION__);
-
-   for (i=0; i  4; i++) {
-   if (dev_self[i])
-   irport_close(dev_self[i]);
-   }
-}
-
-struct irport_cb *
+static struct irport_cb *
 irport_open(int i, unsigned int iobase, unsigned int irq)
 {
struct net_device *dev;
@@ -254,7 +218,7 @@
return NULL;
 }
 
-int irport_close(struct irport_cb *self)
+static int irport_close(struct irport_cb *self)
 {
ASSERT(self != NULL, return -1;);
 
@@ -285,40 +249,40 @@
return 0;
 }
 
-void irport_start(struct irport_cb *self)
+static void irport_stop(struct irport_cb *self)
 {
int iobase;
 
iobase = self-io.sir_base;
 
-   irport_stop(self);
-   
/* We can't lock, we may be called from a FIR driver - Jean II */
 
-   /* Initialize UART */
-   outb(UART_LCR_WLEN8, iobase+UART_LCR);  /* Reset DLAB */
-   outb((UART_MCR_DTR | UART_MCR_RTS | UART_MCR_OUT2), iobase+UART_MCR);
+   /* We are not transmitting any more */
+   self-transmitting = 0;
+
+   /* Reset UART */
+   outb(0, iobase+UART_MCR);

-   /* Turn on interrups */
-   outb(UART_IER_RLSI | UART_IER_RDI |UART_IER_THRI, 

Re: [PATCH] 2.6.11-mm1 nobh support for ext3 writeback mode

2005-03-04 Thread Badari Pulavarty
On Fri, 2005-03-04 at 16:31, Andrew Morton wrote:
 Andrew Morton [EMAIL PROTECTED] wrote:
 
  page reclaim can come in, grab the page lock and
  whip the page off the mapping.
 
 No it can't - we hold an additional ref on the page, so reclaim will back
 off.  Still, it feels a bit flakey.
 
 And we're not supposed to take lock_page() inside journal_start, because
 that's a ranking violation.  Probably i_sem will prevent an actual deadlock
 occurring, however.
 

Here is the new patch to deal with locking, with more code :(

Thanks,
Badari


diff -Naurp -Xdontdiff linux-2.6.11/fs/ext3/inode.c linux-2.6.11.new/fs/ext3/inode.c
--- linux-2.6.11/fs/ext3/inode.c	2005-03-04 16:43:22.536143072 -0800
+++ linux-2.6.11.new/fs/ext3/inode.c	2005-03-04 17:43:16.719744112 -0800
@@ -20,6 +20,7 @@
  * 	([EMAIL PROTECTED])
  *
  *  Assorted race fixes, rewrite of ext3_get_block() by Al Viro, 2000
+ *  Add nobh support for ext3 writeback mode - [EMAIL PROTECTED]
  */
 
 #include linux/module.h
@@ -1016,7 +1017,10 @@ retry:
 		ret = PTR_ERR(handle);
 		goto out;
 	}
-	ret = block_prepare_write(page, from, to, ext3_get_block);
+	if (test_opt(inode-i_sb, NOBH))
+		ret = nobh_prepare_write(page, from, to, ext3_get_block);
+	else
+		ret = block_prepare_write(page, from, to, ext3_get_block);
 	if (ret)
 		goto prepare_write_failed;
 
@@ -1100,7 +1104,12 @@ static int ext3_writeback_commit_write(s
 	new_i_size = ((loff_t)page-index  PAGE_CACHE_SHIFT) + to;
 	if (new_i_size  EXT3_I(inode)-i_disksize)
 		EXT3_I(inode)-i_disksize = new_i_size;
-	ret = generic_commit_write(file, page, from, to);
+
+	if (test_opt(inode-i_sb, NOBH))
+		ret = nobh_commit_write(file, page, from, to);
+	else
+		ret = generic_commit_write(file, page, from, to);
+
 	ret2 = ext3_journal_stop(handle);
 	if (!ret)
 		ret = ret2;
@@ -1385,7 +1394,11 @@ static int ext3_writeback_writepage(stru
 		goto out_fail;
 	}
 
-	ret = block_write_full_page(page, ext3_get_block, wbc);
+	if (test_opt(inode-i_sb, NOBH))
+		ret = nobh_writepage(page, ext3_get_block, wbc);
+	else
+		ret = block_write_full_page(page, ext3_get_block, wbc);
+
 	err = ext3_journal_stop(handle);
 	if (!ret)
 		ret = err;
@@ -1646,13 +1659,46 @@ static int ext3_block_truncate_page(hand
 	unsigned blocksize, iblock, length, pos;
 	struct inode *inode = mapping-host;
 	struct buffer_head *bh;
-	int err;
+	int err = 0;
 	void *kaddr;
 
 	blocksize = inode-i_sb-s_blocksize;
 	length = blocksize - (offset  (blocksize - 1));
 	iblock = index  (PAGE_CACHE_SHIFT - inode-i_sb-s_blocksize_bits);
 
+	if (test_opt(inode-i_sb, NOBH)  !page_has_buffers(page)) {
+		if (!PageUptodate(page)) {
+			struct buffer_head map_bh;
+			bh = map_bh;
+			bh-b_state = 0;
+			clear_buffer_mapped(bh);
+			ext3_get_block(inode, iblock, bh, 0);
+			if (!buffer_mapped(bh)) 
+goto unlock;
+			err = -EIO;
+			set_bh_page(bh, page, 0);
+			bh-b_this_page = 0;
+			bh-b_size = 1  inode-i_blkbits;
+			ll_rw_block(READ, 1, bh);
+			wait_on_buffer(bh);
+			if (!buffer_uptodate(bh))
+goto unlock;
+			SetPageMappedToDisk(page);
+		}
+		if (err == 0  PageUptodate(page)) {
+			kaddr = kmap_atomic(page, KM_USER0);
+			memset(kaddr + offset, 0, length);
+			flush_dcache_page(page);
+			kunmap_atomic(kaddr, KM_USER0);
+			set_page_dirty(page);
+			goto unlock;
+		}
+		/* 
+		 * Well, we tried to work without buffers and failed.
+		 * Fallback to creating buffers
+		 */
+	}
+	
 	if (!page_has_buffers(page))
 		create_empty_buffers(page, blocksize, 0);
 
diff -Naurp -Xdontdiff linux-2.6.11/fs/ext3/super.c linux-2.6.11.new/fs/ext3/super.c
--- linux-2.6.11/fs/ext3/super.c	2005-03-01 23:38:38.0 -0800
+++ linux-2.6.11.new/fs/ext3/super.c	2005-03-04 16:45:22.038975880 -0800
@@ -576,7 +576,7 @@ enum {
 	Opt_resgid, Opt_resuid, Opt_sb, Opt_err_cont, Opt_err_panic, Opt_err_ro,
 	Opt_nouid32, Opt_check, Opt_nocheck, Opt_debug, Opt_oldalloc, Opt_orlov,
 	Opt_user_xattr, Opt_nouser_xattr, Opt_acl, Opt_noacl,
-	Opt_reservation, Opt_noreservation, Opt_noload,
+	Opt_reservation, Opt_noreservation, Opt_noload, Opt_nobh,
 	Opt_commit, Opt_journal_update, Opt_journal_inum,
 	Opt_abort, Opt_data_journal, Opt_data_ordered, Opt_data_writeback,
 	Opt_usrjquota, Opt_grpjquota, Opt_offusrjquota, Opt_offgrpjquota,
@@ -611,6 +611,7 @@ static match_table_t tokens = {
 	{Opt_reservation, reservation},
 	{Opt_noreservation, noreservation},
 	{Opt_noload, noload},
+	{Opt_nobh, nobh},
 	{Opt_commit, commit=%u},
 	{Opt_journal_update, journal=update},
 	{Opt_journal_inum, journal=%u},
@@ -924,6 +925,9 @@ clear_qf_name:
 			match_int(args[0], option);
 			*n_blocks_count = option;
 			break;
+		case Opt_nobh:
+			set_opt(sbi-s_mount_opt, NOBH);
+			break;
 		default:
 			printk (KERN_ERR
 EXT3-fs: Unrecognized mount option \%s\ 
@@ -1563,6 +1567,19 @@ static int ext3_fill_super (struct super
 		break;
 	}
 
+	if (test_opt(sb, NOBH)) {
+		if (sb-s_blocksize_bits != PAGE_CACHE_SHIFT) {
+			printk(KERN_WARNING EXT3-fs: Ignoring nobh option 
+since filesystem 

Re: [PATCH] 2.6.11-mm1 nobh support for ext3 writeback mode

2005-03-04 Thread Andrew Morton
Badari Pulavarty [EMAIL PROTECTED] wrote:

  What's all this doing?  (It needs comments please - it's very unobvious).
 
 All its trying to do is - to make sure the page is uptodate so that
 it can zero out the portion thats needed. 

OK.

 I can do getblock() and ll_rw_block(READ) instead. I was
 trying to re-use the code and mpage_readpage() drops the lock.
 What do you think ?

Can you just call -prepare_write, as nobh_truncate_page() does?  That'll
cause a nested transaction, but that's legal.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Greg KH
On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote:
 But we end up with a cset in the permanent kernel history which simply
 should not have been there.

Is this really a big deal?

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.6.11-mm1 nobh support for ext3 writeback mode

2005-03-04 Thread Badari Pulavarty
On Fri, 2005-03-04 at 16:45, Andrew Morton wrote:
 Badari Pulavarty [EMAIL PROTECTED] wrote:
 
   What's all this doing?  (It needs comments please - it's very unobvious).
  
  All its trying to do is - to make sure the page is uptodate so that
  it can zero out the portion thats needed. 
 
 OK.
 
  I can do getblock() and ll_rw_block(READ) instead. I was
  trying to re-use the code and mpage_readpage() drops the lock.
  What do you think ?
 
 Can you just call -prepare_write, as nobh_truncate_page() does?  That'll
 cause a nested transaction, but that's legal.
 

Thats what I tried earlier, but never got it working. Lots of journal
asserts :( 

I guess I really need to learn journaling code someday.

Thanks,
Badari

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] pci_ids.h correction for Intel ICH7M - 2.6.11

2005-03-04 Thread Jason Gaston
This patch corrects the ICH7M LPC controller DID in pci_ids.h from x27B1 to 
x27B9.  This patch was build against 2.6.11.
If acceptable, please apply.

Thanks,

Jason Gaston

Signed-off-by:  Jason Gaston [EMAIL PROTECTED]

--- linux-2.6.11/include/linux/pci_ids.h.orig   2005-03-04 17:58:10.490587200 
-0800
+++ linux-2.6.11/include/linux/pci_ids.h2005-03-04 17:58:29.990622744 
-0800
@@ -2261,7 +2261,7 @@
 #define PCI_DEVICE_ID_INTEL_ICH6_180x266e
 #define PCI_DEVICE_ID_INTEL_ICH6_190x266f
 #define PCI_DEVICE_ID_INTEL_ICH7_0 0x27b8
-#define PCI_DEVICE_ID_INTEL_ICH7_1 0x27b1
+#define PCI_DEVICE_ID_INTEL_ICH7_1 0x27b9
 #define PCI_DEVICE_ID_INTEL_ICH7_2 0x27c0
 #define PCI_DEVICE_ID_INTEL_ICH7_3 0x27c1
 #define PCI_DEVICE_ID_INTEL_ICH7_4 0x27c2

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [MC] [CHECKER] Do ext2, jfs and reiserfs respect mount -o sync/dirsync option?

2005-03-04 Thread Junfeng Yang
 From a quick parse, ext2 seems to be full of MS_SYNCHRONOUS holes, and
 there might be some O_SYNC ones there as well.

I should be able to easily add O_SYNC check to FiSC.  Several questions:
1. Does O_SYNC apply to directory as well?
2. For the same file, if I open twice, once with O_SYNC and another time
without, only writes through the O_SYNC fd will be sychonous, right?
3. I open a file w/o O_SYNC, issue a bunch of writes, then call
ioctl(FIOASYNC) to set the fd sync, then issure a second set of writes.
Only the second set of writes are synchronous?

btw, man page show that O_DSYNC and O_RSYNC are just O_SYNC.  Is this true
for current linux kernel (2.6)?

 So this wild scattergun patch probably does extra work and possibly extra
 I/O all over the place, but I'd be interested if Junfeng could give it a
 quick test.   It's against 2.6.11.

I checked 2.6.11 with your patch just now.  Looks like the problem is
still there.  If you need more information, let me know.  Image is at
http://fisc.stanford.edu/bug2/crash-1.img.bz2.  Below is the output from
e2fsck.

e2fsck 1.36 (05-Feb-2005)
/dev/ide/host0/bus0/target0/lun0/part9 was not cleanly unmounted, check
forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 13, i_blocks is 16, should be 2.  Fix? yes

Inode 15 is a zero-length directory.  Clear? yes

Pass 2: Checking directory structure
Entry '0005' in / (2) has deleted/unused inode 15.  Clear? yes

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 2 ref count is 4, should be 3.  Fix? yes

Pass 5: Checking group summary information
Block bitmap differences:  -21
Fix? yes

Free blocks count wrong for group #0 (38, counted=39).
Fix? yes

Free blocks count wrong (38, counted=39).
Fix? yes

Inode bitmap differences:  -15
Fix? yes

Free inodes count wrong for group #0 (1, counted=2).
Fix? yes

Directories count wrong for group #0 (3, counted=2).
Fix? yes

Free inodes count wrong (1, counted=2).
Fix? yes


/dev/ide/host0/bus0/target0/lun0/part9: * FILE SYSTEM WAS MODIFIED
*
/dev/ide/host0/bus0/target0/lun0/part9: 14/16 files (0.0% non-contiguous),
21/60 blocks


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: BIOS overwritten during resume (was: Re: Asus L5D resume on battery power)

2005-03-04 Thread Nigel Cunningham
Hi.

On Sat, 2005-03-05 at 10:26, Rafael J. Wysocki wrote:
 Yes.  I thought about using PG_nosave in the begining, but there's a
 
 BUG_ON(PageReserved(page)  PageNosave(page));
 
 in swsusp.c:saveable() that I just didn't want to trigger.  It seems to me,
 though, that we don't need it any more, do we?
 
  He also found a few places where reserved page becomes un-reserved,
  and you probably need to fix those, too.
 
 Yes, I think I'll just port the Nigel's patch to x86-64.  BTW, it's striking
 that we found similar solutions independently (I didn't know the Nigel's
 patch before :-)).

I should clarify credit. I didn't work on that code. I don't recall now
whether it was Michael Frank or Bernard Blackham that came up with this
version. (This was about a year ago IIRC).

 Unfortunately, it turns out that the patch does not fix my problem with random
 reboots during resume on battery power, but I really think that we need to 
 mark
 non-RAM areas with PG_nosave, at least for sanity reasons (eg to be sure that
 we do not break things by dumping stuff to where we should not write to).

Yes. I believed that that's what this patch does. Since I didn't write
it myself, I'm a little fuzzy on that issue. I'll bring Bernard in,
perhaps he can clarify?..

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: BIOS overwritten during resume (was: Re: Asus L5D resume on battery power)

2005-03-04 Thread Rafael J. Wysocki
Hi,

On Friday, 4 of March 2005 21:11, Pavel Machek wrote:
 Hi!
 
 IIRC kernel code/data is marked as PageReserved(), that's why we need
 to save that :(. Not sure what to do with data e820 marked as
 reserved...

Perhaps we need another page flag, like PG_readonly, and mark the pages
reserved by the e820 as PG_reserved | PG_readonly (the same for the 
areas
that are not returned by e820 at all).  Would that be acceptable?
   
   This flags are little in the short supply, but being able to tell
   kernel code from memory hole seems like must have, so yes, that
   looks ok.
   
   You could get subtle and reuse some other pageflag. I do not think
   PG_reserved can have PG_locked... So using for example PG_locked for
   this purpose should be okay.
  
  The following patch does this.  It is only for x86-64 without
  CONFIG_DISCONTIGMEM, but it has no effect in other cases.
 
 Actually, take a look at Nigel's patch. He simply uses PageNosave
 instead of PageLocked -- that is cleaner.

Yes.  I thought about using PG_nosave in the begining, but there's a

BUG_ON(PageReserved(page)  PageNosave(page));

in swsusp.c:saveable() that I just didn't want to trigger.  It seems to me,
though, that we don't need it any more, do we?

 He also found a few places where reserved page becomes un-reserved,
 and you probably need to fix those, too.

Yes, I think I'll just port the Nigel's patch to x86-64.  BTW, it's striking
that we found similar solutions independently (I didn't know the Nigel's
patch before :-)).

Unfortunately, it turns out that the patch does not fix my problem with random
reboots during resume on battery power, but I really think that we need to mark
non-RAM areas with PG_nosave, at least for sanity reasons (eg to be sure that
we do not break things by dumping stuff to where we should not write to).

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: BIOS overwritten during resume (was: Re: Asus L5D resume on battery power)

2005-03-04 Thread Nigel Cunningham
Hi.

On Sat, 2005-03-05 at 10:41, Pavel Machek wrote:
  non-RAM areas with PG_nosave, at least for sanity reasons (eg to be sure 
  that
  we do not break things by dumping stuff to where we should not write to).
 
 I'm not sure if it is not better to save  restore non-RAM areas, but
 it probably just does not matter.

IIRC, it does matter. I think there were situations where you got
something nasty (MCE/oops/freeze) if you tried reading memory that
doesn't exist. If you push me I'll put the effort into looking up
suspend2 archives to find the discussion :

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: swsusp: allow resume from initramfs

2005-03-04 Thread Nigel Cunningham
Hi.

On Sat, 2005-03-05 at 09:55, Pavel Machek wrote:
  All that to say Bitmaps were a definite win!. Perhaps I can sell you
  on the advantages of using them :
 
 Not sure, if one bit goes wrong you put everything in the wrong places
 :-). Linklist seems just okay to me, no  4K allocations. I'm not sure
 why recalculation is that big problem.

So you make sure all the bits are right : I can understand you being
happy with linked lists; it's just that they're really inefficient
spacewise. Since you're freeing far more memory at the moment, it's not
an issue.

Regarding recalculation being a problem, I want Suspend to always work.
If you have unpredictable variation, you have a potential source of
failure.

  By the way, did you see the effect of the memory eating patch? I didn't
  think about it until someone emailed me, but the improvement was 50x
  speed in the best case!
 
 Well, more interesting was that you actually freed much more memory
 with your patch. *You actually made memory freeing to work*. So yes, I
 like that one.

You might be misreading me. When you set the image size limit setting in
Suspend2, it's a soft limit. The image size wouldn't actually get down
to 2 meg; Suspend would just aim for that and eat memory until it saw it
wasn't getting anywhere.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 nobh support for ext3 writeback mode

2005-03-04 Thread Badari Pulavarty
On Fri, 2005-03-04 at 16:45, Andrew Morton wrote:
 Badari Pulavarty [EMAIL PROTECTED] wrote:
 
   What's all this doing?  (It needs comments please - it's very unobvious).
  
  All its trying to do is - to make sure the page is uptodate so that
  it can zero out the portion thats needed. 
 
 OK.
 
  I can do getblock() and ll_rw_block(READ) instead. I was
  trying to re-use the code and mpage_readpage() drops the lock.
  What do you think ?
 
 Can you just call -prepare_write, as nobh_truncate_page() does?  That'll
 cause a nested transaction, but that's legal.
 

Please ignore my previous patch. I forgot to clear err value.

Here is the updated patch.

Thanks,
Badari


diff -Naurp -Xdontdiff linux-2.6.11/fs/ext3/inode.c linux-2.6.11.new/fs/ext3/inode.c
--- linux-2.6.11/fs/ext3/inode.c	2005-03-04 16:43:22.536143072 -0800
+++ linux-2.6.11.new/fs/ext3/inode.c	2005-03-04 18:02:13.418939568 -0800
@@ -20,6 +20,7 @@
  * 	([EMAIL PROTECTED])
  *
  *  Assorted race fixes, rewrite of ext3_get_block() by Al Viro, 2000
+ *  Add nobh support for ext3 writeback mode - [EMAIL PROTECTED]
  */
 
 #include linux/module.h
@@ -1016,7 +1017,10 @@ retry:
 		ret = PTR_ERR(handle);
 		goto out;
 	}
-	ret = block_prepare_write(page, from, to, ext3_get_block);
+	if (test_opt(inode-i_sb, NOBH))
+		ret = nobh_prepare_write(page, from, to, ext3_get_block);
+	else
+		ret = block_prepare_write(page, from, to, ext3_get_block);
 	if (ret)
 		goto prepare_write_failed;
 
@@ -1100,7 +1104,12 @@ static int ext3_writeback_commit_write(s
 	new_i_size = ((loff_t)page-index  PAGE_CACHE_SHIFT) + to;
 	if (new_i_size  EXT3_I(inode)-i_disksize)
 		EXT3_I(inode)-i_disksize = new_i_size;
-	ret = generic_commit_write(file, page, from, to);
+
+	if (test_opt(inode-i_sb, NOBH))
+		ret = nobh_commit_write(file, page, from, to);
+	else
+		ret = generic_commit_write(file, page, from, to);
+
 	ret2 = ext3_journal_stop(handle);
 	if (!ret)
 		ret = ret2;
@@ -1385,7 +1394,11 @@ static int ext3_writeback_writepage(stru
 		goto out_fail;
 	}
 
-	ret = block_write_full_page(page, ext3_get_block, wbc);
+	if (test_opt(inode-i_sb, NOBH))
+		ret = nobh_writepage(page, ext3_get_block, wbc);
+	else
+		ret = block_write_full_page(page, ext3_get_block, wbc);
+
 	err = ext3_journal_stop(handle);
 	if (!ret)
 		ret = err;
@@ -1646,13 +1659,41 @@ static int ext3_block_truncate_page(hand
 	unsigned blocksize, iblock, length, pos;
 	struct inode *inode = mapping-host;
 	struct buffer_head *bh;
-	int err;
+	int err = 0;
 	void *kaddr;
 
 	blocksize = inode-i_sb-s_blocksize;
 	length = blocksize - (offset  (blocksize - 1));
 	iblock = index  (PAGE_CACHE_SHIFT - inode-i_sb-s_blocksize_bits);
 
+	if (test_opt(inode-i_sb, NOBH)  !page_has_buffers(page)) {
+		if (!PageUptodate(page)) {
+			struct buffer_head map_bh;
+			bh = map_bh;
+			bh-b_state = 0;
+			clear_buffer_mapped(bh);
+			ext3_get_block(inode, iblock, bh, 0);
+			if (!buffer_mapped(bh)) 
+goto unlock;
+			err = -EIO;
+			set_bh_page(bh, page, 0);
+			bh-b_this_page = 0;
+			bh-b_size = 1  inode-i_blkbits;
+			ll_rw_block(READ, 1, bh);
+			wait_on_buffer(bh);
+			if (!buffer_uptodate(bh))
+goto unlock;
+			SetPageMappedToDisk(page);
+		}
+		kaddr = kmap_atomic(page, KM_USER0);
+		memset(kaddr + offset, 0, length);
+		flush_dcache_page(page);
+		kunmap_atomic(kaddr, KM_USER0);
+		set_page_dirty(page);
+		err = 0;
+		goto unlock;
+	}
+	
 	if (!page_has_buffers(page))
 		create_empty_buffers(page, blocksize, 0);
 
diff -Naurp -Xdontdiff linux-2.6.11/fs/ext3/super.c linux-2.6.11.new/fs/ext3/super.c
--- linux-2.6.11/fs/ext3/super.c	2005-03-01 23:38:38.0 -0800
+++ linux-2.6.11.new/fs/ext3/super.c	2005-03-04 16:45:22.038975880 -0800
@@ -576,7 +576,7 @@ enum {
 	Opt_resgid, Opt_resuid, Opt_sb, Opt_err_cont, Opt_err_panic, Opt_err_ro,
 	Opt_nouid32, Opt_check, Opt_nocheck, Opt_debug, Opt_oldalloc, Opt_orlov,
 	Opt_user_xattr, Opt_nouser_xattr, Opt_acl, Opt_noacl,
-	Opt_reservation, Opt_noreservation, Opt_noload,
+	Opt_reservation, Opt_noreservation, Opt_noload, Opt_nobh,
 	Opt_commit, Opt_journal_update, Opt_journal_inum,
 	Opt_abort, Opt_data_journal, Opt_data_ordered, Opt_data_writeback,
 	Opt_usrjquota, Opt_grpjquota, Opt_offusrjquota, Opt_offgrpjquota,
@@ -611,6 +611,7 @@ static match_table_t tokens = {
 	{Opt_reservation, reservation},
 	{Opt_noreservation, noreservation},
 	{Opt_noload, noload},
+	{Opt_nobh, nobh},
 	{Opt_commit, commit=%u},
 	{Opt_journal_update, journal=update},
 	{Opt_journal_inum, journal=%u},
@@ -924,6 +925,9 @@ clear_qf_name:
 			match_int(args[0], option);
 			*n_blocks_count = option;
 			break;
+		case Opt_nobh:
+			set_opt(sbi-s_mount_opt, NOBH);
+			break;
 		default:
 			printk (KERN_ERR
 EXT3-fs: Unrecognized mount option \%s\ 
@@ -1563,6 +1567,19 @@ static int ext3_fill_super (struct super
 		break;
 	}
 
+	if (test_opt(sb, NOBH)) {
+		if (sb-s_blocksize_bits != PAGE_CACHE_SHIFT) {
+			printk(KERN_WARNING EXT3-fs: Ignoring nobh option 
+since filesystem blocksize 

Re: [Linux-fbdev-devel] [2.6 patch] make savagefb one module

2005-03-04 Thread Adrian Bunk
On Fri, Mar 04, 2005 at 10:17:17AM +0100, Geert Uytterhoeven wrote:
 On Fri, 4 Mar 2005, Adrian Bunk wrote:
  This patch links all selected files under drivers/video/savagefb/ into 
  one module.
  
  This required a renaming of savagefb.c to savagefb_driver.c .
  
  As a side effect, the EXPORT_SYMBOL's in this directory are no longer 
  required.
  
  ---
  
  Other names than savagefb_driver.c (e.g. savagefb_main.c) are easily 
  possible - I do not claim being good at picking names...
 
 savagefb_core.c?

Antonino, what's your opinion?

 Gr{oetje,eeting}s,
 
   Geert

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/


Re: BIOS overwritten during resume (was: Re: Asus L5D resume on battery power)

2005-03-04 Thread Bernard Blackham
On Sat, Mar 05, 2005 at 10:37:29AM +1100, Nigel Cunningham wrote:
 On Sat, 2005-03-05 at 10:26, Rafael J. Wysocki wrote:
  Yes, I think I'll just port the Nigel's patch to x86-64.  BTW, it's striking
  that we found similar solutions independently (I didn't know the Nigel's
  patch before :-)).
 
 I should clarify credit. I didn't work on that code. I don't recall now
 whether it was Michael Frank or Bernard Blackham that came up with this
 version. (This was about a year ago IIRC).

Definitely not me, sorry :)

Bernard.

-- 
 Bernard Blackham bernard at blackham dot com dot au
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 IrDA] stir4200 turnaround calculation fix

2005-03-04 Thread Jean Tourrilhes
ir261_stir_turn.diff :

Patch from John K. Luebs
o [CORRECT] Proper turnaround computations in the stir4200 driver
o [CORRECT] Take care of Tx packet without IrDA metadata (speed)
Signed-off-by: John K. Luebs [EMAIL PROTECTED]
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]


diff -u -p linux/drivers/net/irda/stir4200.d0.c  
linux/drivers/net/irda/stir4200.c
--- linux/drivers/net/irda/stir4200.d0.cMon Feb  7 16:35:45 2005
+++ linux/drivers/net/irda/stir4200.c   Mon Feb  7 16:37:25 2005
@@ -671,7 +671,8 @@ static void turnaround_delay(const struc
return;
 
do_gettimeofday(now);
-   us -= (now.tv_sec - stir-rx_time.tv_sec) * USEC_PER_SEC;
+   if (now.tv_sec - stir-rx_time.tv_sec  0)
+   us -= USEC_PER_SEC;
us -= now.tv_usec - stir-rx_time.tv_usec;
if (us  10)
return;
@@ -787,7 +788,7 @@ static int stir_transmit_thread(void *ar
stir_send(stir, skb);
dev_kfree_skb(skb);
 
-   if (stir-speed != new_speed) {
+   if ((new_speed != -1)  (stir-speed != new_speed)) {
if (fifo_txwait(stir, -1) ||
change_speed(stir, new_speed))
break;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Linus Torvalds


On Fri, 4 Mar 2005, Greg KH wrote:

 On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote:
  But we end up with a cset in the permanent kernel history which simply
  should not have been there.
 
 Is this really a big deal?

Once? No. If it ends up being par for the course, it's bad.

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: nothing in /proc/fs/nfs/exports ?

2005-03-04 Thread J.A. Magallon

On 03.04, Trond Myklebust wrote:
 fr den 04.03.2005 Klokka 11:58 (+) skreiv J.A. Magallon:
 
  = /proc/fs/nfs/exports
  # Version 1.1
  # Path Client(Flags) # IPs
  
  Nothing in xtab ? Nothing in /proc ? Why ?
  
 
 man exportfs. Read all about the 2.6 kernel's new mechanism for
 communication between mountd and the kernel.
 

Thanks. After reading that twice, I realized I had not /proc/fs/nfs
mounted !!

BTW, my system has two dirs in /proc/fs, both nfs and nfsd. Which
is the correct one ? Is that a bug ?
I will have a manual mount of that, until I discover why my initscripts
stopped mounting that.

TIA

--
J.A. Magallon jamagallon()able!es \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.11-jam1 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1


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


The never ending hpusbscsi storry

2005-03-04 Thread Rene Rebe
Hi,
Matthias Kindtner wrote:
scanimage -L
scanimage: symbol lookup error: /usr/lib/sane/libsane-avision.so.1: undefined 
symbol: sanei_usb_set_timeout
With the latest backed you need to update include/sane/sanei_usb.h and 
sanei/sanei_usb.c from my SVN repository (will go into SANE CVS in the 
next day).

device `avision:/dev/sg0' is a Minolta Dimage Scan Dual II film scanner
Don't ever use hpusbscsi. I though I already told all vedors it is that 
broken that they should never ever ship it. It is the first thing that 
will be removed in Linux 2.7.

If it would be me it would be removed from _all kernels right now_ ...
Mar  4 23:40:51 runningdug scsi: Device offlined - not ready after error 
recovery: host 1 channel 0 id 0 lun 0
Mar  4 23:40:51 runningdug scsi1 (0:0): rejecting I/O to offline device
Mar  4 23:40:51 runningdug scsi1 (0:0): rejecting I/O to offline device
Mar  4 23:40:51 runningdug scsi1 (0:0): rejecting I/O to offline device

A simple plug-out plug-in of the usb solve the problem and I can start once
again
... hpusbscsi as it lifes ...
I hope there are all messages you need in the mail, otherwise I send it to.
You have any Idea for me??
find /lib/modules -name hpusbscsi.*o | xargs rm -fv
(or so - assuming no spaces in filenames ...)
and build the backend with the updated sanei_usb* files. Or 
alternatively use a avision backed that is two weeks old (man svn) which 
does not need the updated sanei functionality.

Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30  255 897 45
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Jeff Garzik
Andrew Morton wrote:
Greg KH [EMAIL PROTECTED] wrote:
Here's the list of things which we might choose to put into 2.6.11.2.  I was
 planning on sending them in for 2.6.12 when that was going to be
 errata-only.
Ok, care to forward them on?

Sure.  How do they get to Linus?
linux-release team should send a please pull request to Linus.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: slab corruption in skb allocs

2005-03-04 Thread Matt Mackall
On Fri, Mar 04, 2005 at 10:52:38PM +0100, Richard Fuchs wrote:
 Matt Mackall wrote:
 
 Doh. 'ethtool -k' is what's needed, sorry.
 
 doh myself. :) this won't be very helpful though, as i get the same on 
 all machines (with both drivers):
 
 Offload parameters for eth0:
 Cannot get device rx csum settings: Operation not supported
 Cannot get device tx csum settings: Operation not supported
 Cannot get device scatter-gather settings: Operation not supported
 Cannot get device tcp segmentation offload settings: Operation not supported
 no offload info available

Which card/driver is this? Is this the same card that's showing ssh
troubles? My theory about your ssh trouble only applies to cards with
checksum offload.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2.6 IrDA] irda-usb sysfs support

2005-03-04 Thread Jean Tourrilhes
ir261_irda-usb_sysfs-kill_urb-2.diff :

o [CORRECT] Forgot to convert a few usb_unlink_urb() in usb_kill_urb()
Patch from John K. Luebs
o [FEATURE] Proper sysfs support
Signed-off-by: John K. Luebs [EMAIL PROTECTED]
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]



diff -u -p linux/drivers/net/irda/irda-usb.d0.c 
linux/drivers/net/irda/irda-usb.c
--- linux/drivers/net/irda/irda-usb.d0.cFri Mar  4 15:37:25 2005
+++ linux/drivers/net/irda/irda-usb.c   Fri Mar  4 15:38:38 2005
@@ -998,7 +998,7 @@ static int irda_usb_net_close(struct net
struct urb *urb = self-rx_urb[i];
struct sk_buff *skb = (struct sk_buff *) urb-context;
/* Cancel the receive command */
-   usb_unlink_urb(urb);
+   usb_kill_urb(urb);
/* The skb is ours, free it */
if(skb) {
dev_kfree_skb(skb);
@@ -1367,12 +1367,12 @@ static int irda_usb_probe(struct usb_int
if (!net) 
goto err_out;
 
+   SET_MODULE_OWNER(net);
+   SET_NETDEV_DEV(net, intf-dev);
self = net-priv;
self-netdev = net;
spin_lock_init(self-lock);
 
-   SET_MODULE_OWNER(net);
-
/* Create all of the needed urbs */
for (i = 0; i  IU_MAX_RX_URBS; i++) {
self-rx_urb[i] = usb_alloc_urb(0, GFP_KERNEL);
@@ -1516,7 +1516,7 @@ static void irda_usb_disconnect(struct u
netif_stop_queue(self-netdev);
/* Stop all the receive URBs */
for (i = 0; i  IU_MAX_RX_URBS; i++)
-   usb_unlink_urb(self-rx_urb[i]);
+   usb_kill_urb(self-rx_urb[i]);
/* Cancel Tx and speed URB.
 * Toggle flags to make sure it's synchronous. */
self-tx_urb-transfer_flags = ~URB_ASYNC_UNLINK;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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-rc3 08/08] ide: remove REQ_DRIVE_CMD handling

2005-03-04 Thread Tejun Heo

08_ide_remove_REQ_DRIVE_CMD.patch

Remove REQ_DRIVE_CMD handling.  ide_init_drive_cmd() now
defaults to REQ_DRIVE_TASKFILE (now the only drive command :-).

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 drivers/block/ll_rw_blk.c |1 
 drivers/ide/ide-disk.c|1 
 drivers/ide/ide-io.c  |  132 +-
 drivers/ide/ide-lib.c |8 --
 include/linux/blkdev.h|2 
 5 files changed, 17 insertions(+), 127 deletions(-)

Index: linux-taskfile-ng/drivers/block/ll_rw_blk.c
===
--- linux-taskfile-ng.orig/drivers/block/ll_rw_blk.c2005-03-05 
10:37:51.398401518 +0900
+++ linux-taskfile-ng/drivers/block/ll_rw_blk.c 2005-03-05 10:47:00.319763980 
+0900
@@ -850,7 +850,6 @@ static char *rq_flags[] = {
REQ_FAILED,
REQ_QUIET,
REQ_SPECIAL,
-   REQ_DRIVE_CMD,
REQ_DRIVE_TASKFILE,
REQ_PREEMPT,
REQ_PM_SUSPEND,
Index: linux-taskfile-ng/drivers/ide/ide-disk.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-disk.c   2005-03-05 
10:46:59.684863236 +0900
+++ linux-taskfile-ng/drivers/ide/ide-disk.c2005-03-05 10:47:00.319763980 
+0900
@@ -638,7 +638,6 @@ static int set_multcount(ide_drive_t *dr
if (drive-special.b.set_multmode)
return -EBUSY;
ide_init_drive_cmd (rq);
-   rq.flags = REQ_DRIVE_CMD;
drive-mult_req = arg;
drive-special.b.set_multmode = 1;
(void) ide_do_drive_cmd (drive, rq, ide_wait);
Index: linux-taskfile-ng/drivers/ide/ide-io.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-io.c 2005-03-05 10:46:59.685863080 
+0900
+++ linux-taskfile-ng/drivers/ide/ide-io.c  2005-03-05 10:47:00.320763824 
+0900
@@ -97,7 +97,7 @@ static struct request *ide_queue_flush_c
ide_task_init_flush(drive, task);
 
ide_init_drive_cmd(flush_rq);
-   flush_rq-flags = REQ_DRIVE_TASKFILE | REQ_STARTED;
+   flush_rq-flags = REQ_STARTED;
flush_rq-nr_sectors = rq-nr_sectors;
flush_rq-special = task;
 
@@ -429,7 +429,6 @@ static void ide_complete_barrier(ide_dri
  
 void ide_end_drive_cmd (ide_drive_t *drive, u8 stat, u8 err)
 {
-   ide_hwif_t *hwif = HWIF(drive);
unsigned long flags;
struct request *rq;
 
@@ -437,17 +436,7 @@ void ide_end_drive_cmd (ide_drive_t *dri
rq = HWGROUP(drive)-rq;
spin_unlock_irqrestore(ide_lock, flags);
 
-   if (rq-flags  REQ_DRIVE_CMD) {
-   u8 *args = (u8 *) rq-buffer;
-   if (rq-errors == 0)
-   rq-errors = !OK_STAT(stat,READY_STAT,BAD_STAT);
-
-   if (args) {
-   args[0] = stat;
-   args[1] = err;
-   args[2] = hwif-INB(IDE_NSECTOR_REG);
-   }
-   } else if (rq-flags  REQ_DRIVE_TASKFILE) {
+   if (rq-flags  REQ_DRIVE_TASKFILE) {
ide_task_t *args = (ide_task_t *) rq-special;
if (rq-errors == 0)
rq-errors = !OK_STAT(stat,READY_STAT,BAD_STAT);
@@ -622,7 +611,7 @@ ide_startstop_t ide_error (ide_drive_t *
return ide_stopped;
 
/* retry only normal I/O: */
-   if (rq-flags  (REQ_DRIVE_CMD | REQ_DRIVE_TASKFILE)) {
+   if (rq-flags  REQ_DRIVE_TASKFILE) {
rq-errors = 1;
ide_end_drive_cmd(drive, stat, err);
return ide_stopped;
@@ -673,7 +662,7 @@ ide_startstop_t ide_abort(ide_drive_t *d
return ide_stopped;
 
/* retry only normal I/O: */
-   if (rq-flags  (REQ_DRIVE_CMD | REQ_DRIVE_TASKFILE)) {
+   if (rq-flags  REQ_DRIVE_TASKFILE) {
rq-errors = 1;
ide_end_drive_cmd(drive, BUSY_STAT, 0);
return ide_stopped;
@@ -688,63 +677,6 @@ ide_startstop_t ide_abort(ide_drive_t *d
return __ide_abort(drive, rq);
 }
 
-/**
- * ide_cmd -   issue a simple drive command
- * @drive: drive the command is for
- * @cmd: command byte
- * @nsect: sector byte
- * @handler: handler for the command completion
- *
- * Issue a simple drive command with interrupts.
- * The drive must be selected beforehand.
- */
-
-static void ide_cmd (ide_drive_t *drive, u8 cmd, u8 nsect,
-   ide_handler_t *handler)
-{
-   ide_hwif_t *hwif = HWIF(drive);
-   if (IDE_CONTROL_REG)
-   hwif-OUTB(drive-ctl,IDE_CONTROL_REG); /* clear nIEN */
-   SELECT_MASK(drive,0);
-   hwif-OUTB(nsect,IDE_NSECTOR_REG);
-   ide_execute_command(drive, cmd, handler, WAIT_CMD, NULL);
-}
-
-/**
- * drive_cmd_intr  -   drive command completion interrupt
- * @drive: drive the completion interrupt occurred on
- *
- * drive_cmd_intr() is invoked on completion of a special 

Re: [PATCH 2.6.11-rc3 05/08] ide: use ide_task_t-tf.protocol instead of ide_task_t-data_phase

2005-03-04 Thread Tejun Heo

05_ide_use_protocol.patch

Remove ide_task_t-{data_phase,command_type,prehandler,rq} and
use tf-protocol instead.  Now the protocol value wholey
defines how to drive a taskfile except for NODATA cases where
a caller can optionally specify handler (for special
commands).  The following behavior changes occur.

* ide_taskfile_ioctl(): req_task-command_type is ignored.
  This doesn't make any difference except for error/crash
  cases in the original code.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 drivers/ide/ide-disk.c |   70 +---
 drivers/ide/ide-io.c   |   29 +
 drivers/ide/ide-taskfile.c |  257 ++---
 include/linux/ide.h|   11 -
 4 files changed, 142 insertions(+), 225 deletions(-)

Index: linux-taskfile-ng/drivers/ide/ide-disk.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-disk.c   2005-03-05 
10:46:59.081957489 +0900
+++ linux-taskfile-ng/drivers/ide/ide-disk.c2005-03-05 10:46:59.684863236 
+0900
@@ -233,10 +233,10 @@ ide_startstop_t __ide_do_rw_disk (ide_dr
 
if (rq_data_dir(rq) == READ) {
if (drive-mult_count) {
-   hwif-data_phase = TASKFILE_MULTI_IN;
+   hwif-protocol = ATA_PROT_PIO_MULT;
command = lba48 ? WIN_MULTREAD_EXT : WIN_MULTREAD;
} else {
-   hwif-data_phase = TASKFILE_IN;
+   hwif-protocol = ATA_PROT_PIO;
command = lba48 ? WIN_READ_EXT : WIN_READ;
}
 
@@ -245,10 +245,10 @@ ide_startstop_t __ide_do_rw_disk (ide_dr
return ide_started;
} else {
if (drive-mult_count) {
-   hwif-data_phase = TASKFILE_MULTI_OUT;
+   hwif-protocol = ATA_PROT_PIO_MULT;
command = lba48 ? WIN_MULTWRITE_EXT : WIN_MULTWRITE;
} else {
-   hwif-data_phase = TASKFILE_OUT;
+   hwif-protocol = ATA_PROT_PIO;
command = lba48 ? WIN_WRITE_EXT : WIN_WRITE;
}
 
@@ -301,6 +301,7 @@ static u64 idedisk_read_native_max_addre
/* Create IDE/ATA command request structure */
memset(args, 0, sizeof(ide_task_t));
 
+   tf-protocol= ATA_PROT_NODATA;
tf-flags   = ATA_TFLAG_OUT_DEVICE | ATA_TFLAG_IN_ADDR;
tf-device  = ATA_LBA;
if (lba48) {
@@ -311,11 +312,8 @@ static u64 idedisk_read_native_max_addre
tf-command = WIN_READ_NATIVE_MAX;
}
 
-   args.command_type   = IDE_DRIVE_TASK_NO_DATA;
-   args.handler= task_no_data_intr;
-
 /* submit command request */
-   if (ide_raw_taskfile(drive, args, NULL) == 0) {
+   if (ide_raw_taskfile(drive, args, 0, NULL) == 0) {
/* if OK, compute maximum address value */
addr = ide_tf_get_address(drive, tf);
addr++; /* since the return value is (maxlba - 1), we add 1 */
@@ -337,6 +335,7 @@ static u64 idedisk_set_max_address(ide_d
/* Create IDE/ATA command request structure */
memset(args, 0, sizeof(ide_task_t));
 
+   tf-protocol= ATA_PROT_NODATA;
tf-flags   = ATA_TFLAG_OUT_DEVICE | ATA_TFLAG_ISADDR;
tf-device  = ATA_LBA;
tf-lbal= addr_req;
@@ -354,11 +353,8 @@ static u64 idedisk_set_max_address(ide_d
tf-command = WIN_SET_MAX;
}
 
-   args.command_type   = IDE_DRIVE_TASK_NO_DATA;
-   args.handler= task_no_data_intr;
-
/* submit command request */
-   if (ide_raw_taskfile(drive, args, NULL) == 0) {
+   if (ide_raw_taskfile(drive, args, 0, NULL) == 0) {
addr_set = ide_tf_get_address(drive, tf);
addr_set++;
}
@@ -474,15 +470,14 @@ static int smart_enable(ide_drive_t *dri
 
memset(args, 0, sizeof(ide_task_t));
 
+   tf-protocol= ATA_PROT_NODATA;
tf-flags   = ATA_TFLAG_OUT_ADDR;
tf-feature = SMART_ENABLE;
tf-lbam= SMART_LCYL_PASS;
tf-lbah= SMART_HCYL_PASS;
tf-command = WIN_SMART;
 
-   args.command_type   = IDE_DRIVE_TASK_NO_DATA;
-   args.handler= task_no_data_intr;
-   return ide_raw_taskfile(drive, args, NULL);
+   return ide_raw_taskfile(drive, args, 0, NULL);
 }
 
 static int get_smart_values(ide_drive_t *drive, u8 *buf)
@@ -490,8 +485,11 @@ static int get_smart_values(ide_drive_t 
ide_task_t args;
struct ata_taskfile *tf = args.tf;
 
+   smart_enable(drive);
+
memset(args, 0, sizeof(ide_task_t));
 
+   tf-protocol= ATA_PROT_PIO;
tf-flags  

Re: [PATCH] 2.6.11-mm1 nobh support for ext3 writeback mode

2005-03-04 Thread Andrew Morton
Badari Pulavarty [EMAIL PROTECTED] wrote:

   iblock = index  (PAGE_CACHE_SHIFT - inode-i_sb-s_blocksize_bits);

It would still be nice to add a comment in here...

 + if (test_opt(inode-i_sb, NOBH)  !page_has_buffers(page)) {
 + if (!PageUptodate(page)) {
 + struct buffer_head map_bh;
 + bh = map_bh;
 + bh-b_state = 0;
 + clear_buffer_mapped(bh);
 + ext3_get_block(inode, iblock, bh, 0);
 + if (!buffer_mapped(bh)) 
 + goto unlock;
 + err = -EIO;
 + set_bh_page(bh, page, 0);
 + bh-b_this_page = 0;
 + bh-b_size = 1  inode-i_blkbits;
 + ll_rw_block(READ, 1, bh);
 + wait_on_buffer(bh);
 + if (!buffer_uptodate(bh))
 + goto unlock;
 + SetPageMappedToDisk(page);
 + }
 + kaddr = kmap_atomic(page, KM_USER0);
 + memset(kaddr + offset, 0, length);
 + flush_dcache_page(page);
 + kunmap_atomic(kaddr, KM_USER0);
 + set_page_dirty(page);
 + err = 0;
 + goto unlock;
 + }
 + 
   if (!page_has_buffers(page))
   create_empty_buffers(page, blocksize, 0);

Given that we're about to go add buffers to the page, why not do that
first, and use the page's own buffer_head rather than cooking up a local
one?  Then we can simply use sb_bread().

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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-mm1

2005-03-04 Thread Alexander Nyberg
fre 2005-03-04 klockan 03:32 -0800 skrev Andrew Morton:
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm1/
 
 
 - Added the new bk-audit tree.  Contains updates to the kernel's audit
   feature.  Maintained by David Woodhouse.
 
 - The Dell keyboard problems should be fixed.  Testing needed.
 
 - Dmitry's bk-dtor-input tree is no longer active and has been dropped.

Just booted up a box and tried to log onto ssh which didn't worked so I
looked at kernel log and behold, 128MB box with no swap, had just
booted. Couldn't get any access after this.
A few kernel debugging options were chosen notably CONFIG_DEBUG_SLAB 
CONFIG_DEBUG_PAGEALLOC

This is just as a note, I have no idea what happened. 


swapper: page allocation failure. order:0, mode:0x20
swapper: page allocation failure. order:0, mode:0x20
[c0103b77] dump_stack+0x17/0x20
[c0135a3e] __alloc_pages+0x25e/0x3a0
[c013806f] kmem_getpages+0x2f/0x90
[c01393e0] cache_grow+0x90/0x110
[c013999d] cache_alloc_refill+0x17d/0x250
[c0139f68] __kmalloc+0x98/0xb0
[c0338659] alloc_skb+0x39/0xd0
[c034693a] find_skb+0x2a/0x80
[c0346a3b] netpoll_send_udp+0x2b/0x230
[c03061ba] write_msg+0x3a/0x50
[c0119532] __call_console_drivers+0x52/0x60
[c011962f] call_console_drivers+0x7f/0x100
[c0119986] release_console_sem+0x36/0xa0
[c0119886] vprintk+0xe6/0x120
[c0119798] printk+0x18/0x20
[c0135a39] __alloc_pages+0x259/0x3a0
[c013806f] kmem_getpages+0x2f/0x90
[c01393e0] cache_grow+0x90/0x110
[c013999d] cache_alloc_refill+0x17d/0x250
[c0139e76] kmem_cache_alloc+0x66/0x70
[c034109d] dst_alloc+0x2d/0x90
[c034cf0a] ip_route_input_slow+0x23a/0x710
[c034f2f9] ip_rcv+0x319/0x3e0
[c033debb] netif_receive_skb+0x12b/0x190
[c033df9e] process_backlog+0x7e/0x100
[c033e085] net_rx_action+0x65/0xe0
[c011d8ba] __do_softirq+0x7a/0x90
[c0104fc4] do_softirq+0x44/0x60
===
[c0104ea1] do_IRQ+0x61/0xa0
[c0103726] common_interrupt+0x1a/0x20
[c01010f0] cpu_idle+0x50/0x60
[c045e79a] start_kernel+0x12a/0x150
[c010019f] 0xc010019f
swapper: page allocation failure. order:0, mode:0x20
[c0103b77] dump_stack+0x17/0x20
[c0135a3e] __alloc_pages+0x25e/0x3a0
[c013806f] kmem_getpages+0x2f/0x90
[c01393e0] cache_grow+0x90/0x110
[c013999d] cache_alloc_refill+0x17d/0x250
[c0139f68] __kmalloc+0x98/0xb0
[c0338659] alloc_skb+0x39/0xd0
[c03468a4] refill_skbs+0x24/0x50
[c0346989] find_skb+0x79/0x80
[c0346a3b] netpoll_send_udp+0x2b/0x230
[c03061ba] write_msg+0x3a/0x50
[c0119532] __call_console_drivers+0x52/0x60
[c011962f] call_console_drivers+0x7f/0x100
[c0119986] release_console_sem+0x36/0xa0
[c0119886] vprintk+0xe6/0x120
[c0119798] printk+0x18/0x20
[c0135a39] __alloc_pages+0x259/0x3a0
[c013806f] kmem_getpages+0x2f/0x90
[c01393e0] cache_grow+0x90/0x110
[c013999d] cache_alloc_refill+0x17d/0x250
[c0139e76] kmem_cache_alloc+0x66/0x70
[c034109d] dst_alloc+0x2d/0x90
[c034cf0a] ip_route_input_slow+0x23a/0x710
[c034f2f9] ip_rcv+0x319/0x3e0
[c033debb] netif_receive_skb+0x12b/0x190
[c033df9e] process_backlog+0x7e/0x100
[c033e085] net_rx_action+0x65/0xe0
[c011d8ba] __do_softirq+0x7a/0x90
[c0104fc4] do_softirq+0x44/0x60
===
[c0104ea1] do_IRQ+0x61/0xa0
[c0103726] common_interrupt+0x1a/0x20
[c01010f0] cpu_idle+0x50/0x60
[c045e79a] start_kernel+0x12a/0x150
[c010019f] 0xc010019f
swapper: page allocation failure. order:0, mode:0x20
[c0103b77] dump_stack+0x17/0x20
[c0135a3e] __alloc_pages+0x25e/0x3a0
[c013806f] kmem_getpages+0x2f/0x90
[c01393e0] cache_grow+0x90/0x110
[c013999d] cache_alloc_refill+0x17d/0x250
[c0139f68] __kmalloc+0x98/0xb0
[c0338659] alloc_skb+0x39/0xd0
[c034693a] find_skb+0x2a/0x80
[c0346a3b] netpoll_send_udp+0x2b/0x230
[c03061ba] write_msg+0x3a/0x50
[c0119532] __call_console_drivers+0x52/0x60
[c011962f] call_console_drivers+0x7f/0x100
[c0119986] release_console_sem+0x36/0xa0
[c0119886] vprintk+0xe6/0x120
[c0119798] printk+0x18/0x20
[c0135a39] __alloc_pages+0x259/0x3a0
[c013806f] kmem_getpages+0x2f/0x90
[c01393e0] cache_grow+0x90/0x110
[c013999d] cache_alloc_refill+0x17d/0x250
[c0139e76] kmem_cache_alloc+0x66/0x70
[c034109d] dst_alloc+0x2d/0x90
[c034cf0a] ip_route_input_slow+0x23a/0x710
[c034f2f9] ip_rcv+0x319/0x3e0
[c033debb] netif_receive_skb+0x12b/0x190
[c033df9e] process_backlog+0x7e/0x100
[c033e085] net_rx_action+0x65/0xe0
[c011d8ba] __do_softirq+0x7a/0x90
[c0104fc4] do_softirq+0x44/0x60
===
[c0104ea1] do_IRQ+0x61/0xa0
[c0103726] common_interrupt+0x1a/0x20
[c01010f0] cpu_idle+0x50/0x60
[c045e79a] start_kernel+0x12a/0x150
[c010019f] 0xc010019f
swapper: page allocation failure. order:0, mode:0x20
[c0103b77] dump_stack+0x17/0x20
[c0135a3e] __alloc_pages+0x25e/0x3a0
[c013806f] kmem_getpages+0x2f/0x90
[c01393e0] cache_grow+0x90/0x110
[c013999d] cache_alloc_refill+0x17d/0x250
[c0139f68] __kmalloc+0x98/0xb0
[c0338659] alloc_skb+0x39/0xd0
[c034693a] find_skb+0x2a/0x80
[c0346a3b] netpoll_send_udp+0x2b/0x230
[c03061ba] write_msg+0x3a/0x50
[c0119532] __call_console_drivers+0x52/0x60
[c011962f] call_console_drivers+0x7f/0x100
[c0119986] 

[PATCH 2.6 IrDA] fix IrNET poll with empty disco log

2005-03-04 Thread Jean Tourrilhes
ir261_irnet_poll_fix-2.diff :
~~~
o [CORRECT] poll would improperly exit when the discovery log was empty
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]



diff -u -p linux/net/irda/irnet/irnet_irda.j1.c 
linux/net/irda/irnet/irnet_irda.c
--- linux/net/irda/irnet/irnet_irda.j1.cFri Feb  4 16:28:22 2005
+++ linux/net/irda/irnet/irnet_irda.c   Fri Feb  4 16:28:58 2005
@@ -632,7 +632,7 @@ irda_irnet_destroy(irnet_socket *   self)
   self-iriap = NULL;
 }
 
-  /* Cleanup eventual discoveries from connection attempt */
+  /* Cleanup eventual discoveries from connection attempt or control channel */
   if(self-discoveries != NULL)
 {
   /* Cleanup our copy of the discovery log */
diff -u -p linux/net/irda/irnet/irnet_ppp.j1.c linux/net/irda/irnet/irnet_ppp.c
--- linux/net/irda/irnet/irnet_ppp.j1.c Fri Feb  4 16:28:30 2005
+++ linux/net/irda/irnet/irnet_ppp.cFri Feb  4 16:28:58 2005
@@ -171,18 +171,44 @@ irnet_ctrl_write(irnet_socket *   ap,
 #ifdef INITIAL_DISCOVERY
 /*--*/
 /*
- * Function irnet_read_discovery_log (self)
+ * Function irnet_get_discovery_log (self)
+ *
+ *Query the content on the discovery log if not done
+ *
+ * This function query the current content of the discovery log
+ * at the startup of the event channel and save it in the internal struct.
+ */
+static void
+irnet_get_discovery_log(irnet_socket * ap)
+{
+  __u16mask = irlmp_service_to_hint(S_LAN);
+
+  /* Ask IrLMP for the current discovery log */
+  ap-discoveries = irlmp_get_discoveries(ap-disco_number, mask,
+ DISCOVERY_DEFAULT_SLOTS);
+
+  /* Check if the we got some results */
+  if(ap-discoveries == NULL)
+ap-disco_number = -1;
+
+  DEBUG(CTRL_INFO, Got the log (0x%p), size is %d\n,
+   ap-discoveries, ap-disco_number);
+}
+
+/*--*/
+/*
+ * Function irnet_read_discovery_log (self, event)
  *
  *Read the content on the discovery log
  *
  * This function dump the current content of the discovery log
  * at the startup of the event channel.
- * Return 1 if written on the control channel...
+ * Return 1 if wrote an event on the control channel...
  *
  * State of the ap-disco_XXX variables :
- * at socket creation :disco_index = 0 ; disco_number = 0
- * while reading : disco_index = X ; disco_number = Y
- * After reading : disco_index = Y ; disco_number = -1
+ * Socket creation :  discoveries = NULL ; disco_index = 0 ; disco_number = 0
+ * While reading :discoveries = ptr  ; disco_index = X ; disco_number = Y
+ * After reading :discoveries = NULL ; disco_index = Y ; disco_number = -1
  */
 static inline int
 irnet_read_discovery_log(irnet_socket *ap,
@@ -201,19 +227,8 @@ irnet_read_discovery_log(irnet_socket *
 }
 
   /* Test if it's the first time and therefore we need to get the log */
-  if(ap-disco_index == 0)
-{
-  __u16mask = irlmp_service_to_hint(S_LAN);
-
-  /* Ask IrLMP for the current discovery log */
-  ap-discoveries = irlmp_get_discoveries(ap-disco_number, mask,
- DISCOVERY_DEFAULT_SLOTS);
-  /* Check if the we got some results */
-  if(ap-discoveries == NULL)
-   ap-disco_number = -1;
-  DEBUG(CTRL_INFO, Got the log (0x%p), size is %d\n,
-   ap-discoveries, ap-disco_number);
-}
+  if(ap-discoveries == NULL)
+irnet_get_discovery_log(ap);
 
   /* Check if we have more item to dump */
   if(ap-disco_index  ap-disco_number)
@@ -417,7 +432,14 @@ irnet_ctrl_poll(irnet_socket * ap,
 mask |= POLLIN | POLLRDNORM;
 #ifdef INITIAL_DISCOVERY
   if(ap-disco_number != -1)
-mask |= POLLIN | POLLRDNORM;
+{
+  /* Test if it's the first time and therefore we need to get the log */
+  if(ap-discoveries == NULL)
+   irnet_get_discovery_log(ap);
+  /* Recheck */
+  if(ap-disco_number != -1)
+   mask |= POLLIN | POLLRDNORM;
+}
 #endif /* INITIAL_DISCOVERY */
 
   DEXIT(CTRL_TRACE,  - mask=0x%X\n, mask);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


IrDA patches for 2.6.12-rc1

2005-03-04 Thread Jean Tourrilhes
Hi David,

More trivial fixes in various places of the IrDA stack and
driver, no biggies. Freshly tested on 2.6.11, most have been on my web
pages for a while.
This should go in 2.6.12-rc1.
Thanks !

Jean

---

[FEATURE] : Add a new feature to the IrDA stack
[CORRECT] : Fix to have the correct/expected behaviour
[CRITICA] : Fix potential kernel crash

ir261_irnet_poll_fix-2.diff :
~~~
o [CORRECT] poll would improperly exit when the discovery log was empty
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]

ir261_irda-usb_sysfs-kill_urb-2.diff :

o [CORRECT] Forgot to convert a few usb_unlink_urb() in usb_kill_urb()
Patch from John K. Luebs
o [FEATURE] Proper sysfs support
Signed-off-by: John K. Luebs [EMAIL PROTECTED]
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]

ir261_stir_turn.diff :

Patch from John K. Luebs
o [CORRECT] Proper turnaround computations in the stir4200 driver
o [CORRECT] Take care of Tx packet without IrDA metadata (speed)
Signed-off-by: John K. Luebs [EMAIL PROTECTED]
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]

irXXX_via_devexit.diff :
~~
Patch from Randy Dunlap
o [CORRECT] Make exit code properly in VIA driver
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]

ir261_connect_lsap-2.diff :
~
Original patch from Iavor Fetvadjie
o [FEATURE] allow IrDA socket to connect on arbitrary LSAPs
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]

ir261_nsc_38x.diff :
~~
Original patch from Steffen Pingel
o [FEATURE] support NSC PC8738x chipset (IBM x40  ...)
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]

ir261_ircomm_write_cleanup.diff :
~~~
o [FEATURE] cleanup some construct obsoleted by Linus's patch
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]

irXXX_irport_exports.diff :
~
Patch from Adrian Bunk
o [FEATURE] make needlessly global code static
o [FEATURE] remove unneeded EXPORT_SYMBOL's from irport.c
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] ext3/jbd race: releasing in-use journal_heads

2005-03-04 Thread Andrew Morton
Stephen C. Tweedie [EMAIL PROTECTED] wrote:

 For the past few months there has been a slow but steady trickle of
 reports of oopses in kjournald.

Yes, really tenuous stuff.  Very glad if this is the fix!

  Recently I got a couple of reports that
 were repeatable enough to rerun with extra debugging code.
 
 It turns out that we're releasing a journal_head while it is still
 linked onto the transaction's t_locked_list.  The exact location is in
 journal_unmap_buffer().  On several exit paths, that does:
 
   spin_unlock(journal-j_list_lock); 
   jbd_unlock_bh_state(bh);
   spin_unlock(journal-j_state_lock);
   journal_put_journal_head(jh);
 
 releasing the jh *after* dropping the j_list_lock and j_state_lock.
 
 kjournald can then be doing journal_commit_transaction():
 
   spin_lock(journal-j_list_lock);
 ...
   if (buffer_locked(bh)) {
   BUFFER_TRACE(bh, locked);
   if (!inverted_lock(journal, bh))
   goto write_out_data;
   __journal_unfile_buffer(jh);
   __journal_file_buffer(jh, commit_transaction,
   BJ_Locked);
   jbd_unlock_bh_state(bh);
 
 The problem happens if journal_unmap_buffer()'s own put_journal_head()
 manages to get in between kjournald's *unfile_buffer and the following
 *file_buffer.  Because journal_unmap_buffer() has dropped its bh_state
 lock by this point, there's nothing to prevent this, leading to a
 variety of unpleasant situations.  In particular, the jh is unfiled at
 this point, so there's nothing to stop the put_journal_head() from
 freeing the memory we're just about to link onto the BJ_Locked list.

Right.  I don't know why journal_put_journal_head() looks at
-b_transaction, really.  Should have made presence on a list contribute to
b_jcount.  Oh well, it's been that way since 2.5.0 or older..

Don't we have the same race anywhere where we're doing a
journal_refile_buffer() (or equiv) in parallel with a
journal_put_journal_head() outside locks?  There seem to be many such.

Perhaps we could also fix this by elevating b_jcount whenever the jh is
being moved between lists?

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: swsusp: allow resume from initramfs

2005-03-04 Thread Pavel Machek
Hi!

   You guys are reinventing the wheel a lot at the moment and I'm in the
   middle of doing it for x86_64 lowlevel code : Can we see if we can work
   a little more closely - perhaps we can get some shared code going that
   will allow us to handle these issues without stepping on each others'
   feet? In particular, shared code for
   
   - initramfs and initrd support
  
  Its actually done, and it was few strategically placed lines of code
  (like 20 lines). I do not think it can be meaningfully shared.
 
 Mmm. But if we're both putting hooks in the same places...

There are very little hooks... But we may want to make sure we have
same userland interface. swsusp uses echo 3:5  /sys/power/resume to
trigger resume from device major 3 minor 5.

   - lowlevel suspend  resume
  
  This makes very good sense to share. We have i386, x86-64 and ppc
  versions. They simply walk list of pbe's; that should be simple enough
  to be usable for suspend2, too
 
 The CPU save and restore, yes. But I use a different format for
 recording the image metadata (I use bitmaps to record the locations of
 pages). Perhaps I should hasten to mention the bitmaps are discontiguous
 - single pages connected by a kmalloc'd list. The copyback itself will
 need to stay distinct.

Hmm, bitmaps? Okay, then low-level code needs to stay separate. (And
thats bad, I wanted that one to be shared most).
Pavel

-- 
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: Re: 2.6.11 ps/2 mouse is dead

2005-03-04 Thread Leonid Petrov
Dmitry,

 On Friday 04 March 2005 00:52, Leonid Petrov wrote:
 I upgraded from 2.6.10 to 2.6.11 using make oldconfig and my
 Logitech ps/2 mouse is dead. cat /dev/input/mice shows
 nothing. Nothing suspicios in /var/log/messages
 The same mousce works fine with 2.6.10


 Does it work with i8042.noacpi kernel boot option?


  I've inserted an option i8042.noacpi:

kernel /boot/vmlinuz-2.6.11 ro root=/dev/hda4 rhgb quiet i8042.noacpi

  to my /boot/grub/menu.lst, and, oh miracle, it works. Moreover, this
option fixed the old problem: mouse and keyboard were dead when I enabled
hyperthreading in BIOS. Now it works with hyperthreading. Excellent!
Thank you very much!

 If it helps woudl you mind sending me your dsdt (cat /proc/acpi/dsdt  
 dsdt.hex)?

Sure. I've put it in http://lpetrov.net/misc/dsdt.hex

Leonid
2005.03.04_20:40:33
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Tim Bird
Matt Mackall wrote:
 One last plea for the 2.4 scheme:
 
 I think naming the interim releases -pre/-rc has done this admirably
 for 2.4.

I agree.  This makes more sense to me than some implicit understanding
about the parity of the revision.

rc is easy to understand, and '-pre' is easy to understand
once you recognize it means 'beta'.

I've been bothered in the 2.6 series that rc (release candidate?)
tags were applied to kernels that were clearly NOT release candidates.


=
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 patch] remove drivers/char/tpqic02.c

2005-03-04 Thread Adrian Bunk
Since at about half a year, this driver was no longer selectable via
Kconfig.

Since it seems noone missed this driver, therefore this patch removes
it.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

This patch was already sent on:
- 5 Feb 2005
- 25 Feb 2005

 drivers/char/Makefile   |1
 drivers/char/tpqic02.c  | 2811 
 fs/compat_ioctl.c   |   63
 include/linux/major.h   |1
 include/linux/mtio.h|   28
 include/linux/tpqic02.h |  738 --
 6 files changed, 3642 deletions(-)

Due to the 100kB size limit at linux-kernel, a compressed version is 
attached.


patch-remove-tpqic02.gz
Description: Binary data


[PATCH] Toshiba ACPI failure handling

2005-03-04 Thread Panagiotis Issaris
Hi,

Adds the missing failure handling for a kmalloc in the Toshiba
ACPI driver.

Signed-off-by: Panagiotis Issaris [EMAIL PROTECTED]

diff -pruN linux-2.6.11-orig/drivers/acpi/toshiba_acpi.c 
linux-2.6.11-pi/drivers/acpi/toshiba_acpi.c
--- linux-2.6.11-orig/drivers/acpi/toshiba_acpi.c   2005-03-05 
01:04:40.0 +0100
+++ linux-2.6.11-pi/drivers/acpi/toshiba_acpi.c 2005-03-05 01:03:13.0 
+0100
@@ -263,6 +263,9 @@ dispatch_write(struct file* file, const 
 * destination so that sscanf can be used on it safely.
 */
tmp_buffer = kmalloc(count + 1, GFP_KERNEL);
+   if(!tmp_buffer)
+   return -ENOMEM;
+
if (copy_from_user(tmp_buffer, buffer, count)) {
result = -EFAULT;
}

-- 
  K.U.Leuven, Mechanical Eng.,  Mechatronics  Robotics Research Group
  http://people.mech.kuleuven.ac.be/~pissaris/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Ext2-devel] [RFC] ext3/jbd race: releasing in-use journal_heads

2005-03-04 Thread Badari Pulavarty
Stephen,


I looked at few journalling bugs recently on RHEL4 testing here.
I am wondering if your patch fixes this following BUG also ?
I never got to bottom of some of these journal panics -
since they are not easily reproducible + I don't understand
journal code well enough :(

Assertion failure in journal_commit_transaction() at fs/jbd/commit.c:790: 
jh-b_next_transaction == ((void *)0)
kernel BUG in journal_commit_transaction at fs/jbd/commit.c:790!
cpu 0x8: Vector: 700 (Program Check) at [c0001fcc3870]
pc: d00a7cd4: .journal_commit_transaction+0x1378/0x155c [jbd]
lr: d00a7cd0: .journal_commit_transaction+0x1374/0x155c [jbd]
sp: c0001fcc3af0
   msr: 80029032
  current = 0xc0002fd86b30
  paca= 0xc03de000
pid   = 272, comm = kjournald
enter ? for help

Thanks,
Badari


On Fri, 2005-03-04 at 11:54, Stephen C. Tweedie wrote:
 Hi all,
 
 For the past few months there has been a slow but steady trickle of
 reports of oopses in kjournald.  Recently I got a couple of reports that
 were repeatable enough to rerun with extra debugging code.
 
 It turns out that we're releasing a journal_head while it is still
 linked onto the transaction's t_locked_list.  The exact location is in
 journal_unmap_buffer().  On several exit paths, that does:
 
   spin_unlock(journal-j_list_lock); 
   jbd_unlock_bh_state(bh);
   spin_unlock(journal-j_state_lock);
   journal_put_journal_head(jh);
 
 releasing the jh *after* dropping the j_list_lock and j_state_lock.
 
 kjournald can then be doing journal_commit_transaction():
 
   spin_lock(journal-j_list_lock);
 ...
   if (buffer_locked(bh)) {
   BUFFER_TRACE(bh, locked);
   if (!inverted_lock(journal, bh))
   goto write_out_data;
   __journal_unfile_buffer(jh);
   __journal_file_buffer(jh, commit_transaction,
   BJ_Locked);
   jbd_unlock_bh_state(bh);
 
 The problem happens if journal_unmap_buffer()'s own put_journal_head()
 manages to get in between kjournald's *unfile_buffer and the following
 *file_buffer.  Because journal_unmap_buffer() has dropped its bh_state
 lock by this point, there's nothing to prevent this, leading to a
 variety of unpleasant situations.  In particular, the jh is unfiled at
 this point, so there's nothing to stop the put_journal_head() from
 freeing the memory we're just about to link onto the BJ_Locked list.
 
 I _think_ that the attached patch deals with this, but I'm still
 awaiting further testing to be sure.  I thought I might as well get some
 other ext3 eyes on it while I wait for that -- I'll let you know as soon
 as I hear back from the other testing.
 
 The patch works by making sure that the various exits from
 journal_unmap_buffer() always call journal_put_journal_head() *before*
 unlocking the j_list_lock.  This is correct according to the documented
 lock ranking, and it also matches the order in the existing main exit
 path at the end of the function.
 
 Cheers,
   Stephen
 
 
 __
 
 --- linux-2.6-ext3/fs/jbd/transaction.c.=K=.orig
 +++ linux-2.6-ext3/fs/jbd/transaction.c
 @@ -1775,10 +1775,10 @@ static int journal_unmap_buffer(journal_
   JBUFFER_TRACE(jh, checkpointed: add to BJ_Forget);
   ret = __dispose_buffer(jh,
   journal-j_running_transaction);
 + journal_put_journal_head(jh);
   spin_unlock(journal-j_list_lock);
   jbd_unlock_bh_state(bh);
   spin_unlock(journal-j_state_lock);
 - journal_put_journal_head(jh);
   return ret;
   } else {
   /* There is no currently-running transaction. So the
 @@ -1789,10 +1789,10 @@ static int journal_unmap_buffer(journal_
   JBUFFER_TRACE(jh, give to committing trans);
   ret = __dispose_buffer(jh,
   journal-j_committing_transaction);
 + journal_put_journal_head(jh);
   spin_unlock(journal-j_list_lock);
   jbd_unlock_bh_state(bh);
   spin_unlock(journal-j_state_lock);
 - journal_put_journal_head(jh);
   return ret;
   } else {
   /* The orphan record's transaction has
 @@ -1813,10 +1813,10 @@ static int journal_unmap_buffer(journal_
   journal-j_running_transaction);
   jh-b_next_transaction = NULL;
   }
 + 

[PATCH] FUSE: use generic_file_llseek

2005-03-04 Thread Miklos Szeredi
Hi Andrew!

This patch adds generic_file_llseek to fuse_file_operations and
fuse_dir_operations, replacing the implicit default_llseek.

Please Apply.

Thanks,
Miklos

Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]

diff -rup linux-2.6.11-mm1/fs/fuse/dir.c linux-fuse/fs/fuse/dir.c
--- linux-2.6.11-mm1/fs/fuse/dir.c  2005-03-04 23:26:59.0 +0100
+++ linux-fuse/fs/fuse/dir.c2005-03-04 23:32:36.0 +0100
@@ -894,6 +894,7 @@ static struct inode_operations fuse_dir_
 };
 
 static struct file_operations fuse_dir_operations = {
+   .llseek = generic_file_llseek,
.read   = generic_read_dir,
.readdir= fuse_readdir,
.open   = fuse_dir_open,
diff -rup linux-2.6.11-mm1/fs/fuse/file.c linux-fuse/fs/fuse/file.c
--- linux-2.6.11-mm1/fs/fuse/file.c 2005-03-04 23:26:59.0 +0100
+++ linux-fuse/fs/fuse/file.c   2005-03-04 23:32:36.0 +0100
@@ -517,6 +517,7 @@ static int fuse_set_page_dirty(struct pa
 }
 
 static struct file_operations fuse_file_operations = {
+   .llseek = generic_file_llseek,
.read   = fuse_file_read,
.write  = fuse_file_write,
.mmap   = fuse_file_mmap,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] I2C: Fix some gcc 4.0 compile failures and warnings

2005-03-04 Thread Greg KH
On Fri, Mar 04, 2005 at 02:55:11PM -0800, Mickey Stein wrote:
 I was just scanning this email and it looks like you possibly grabbed 
 the first of my patches with a typo because this last little bit I 
 corrected in a prior email to you.   It  got into the  *mm* tree  ok.  
 So I'm not sure where this took a wrong turn again.

You missed the follow-on patch that fixed this up :)

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: [MC] [CHECKER] Do ext2, jfs and reiserfs respect mount -o sync/dirsync option?

2005-03-04 Thread Andrew Morton
Junfeng Yang [EMAIL PROTECTED] wrote:

  From a quick parse, ext2 seems to be full of MS_SYNCHRONOUS holes, and
  there might be some O_SYNC ones there as well.
 
 I should be able to easily add O_SYNC check to FiSC.  Several questions:
 1. Does O_SYNC apply to directory as well?

Only if you can open directores for writing ;)

 2. For the same file, if I open twice, once with O_SYNC and another time
 without, only writes through the O_SYNC fd will be sychonous, right?

Yes, O_SYNC is a per-fd thing.

 3. I open a file w/o O_SYNC, issue a bunch of writes, then call
 ioctl(FIOASYNC) to set the fd sync, then issure a second set of writes.
 Only the second set of writes are synchronous?

FIOSYNC is unrelated to O_SYNC.  OSYNC can only be set at open().

 btw, man page show that O_DSYNC and O_RSYNC are just O_SYNC.  Is this true
 for current linux kernel (2.6)?

The kernel only supports O_SYNC (equivalent behaviour to O_RSYNC|O_DSYNC). 
Perhaps glibc does a conversion.

  So this wild scattergun patch probably does extra work and possibly extra
  I/O all over the place, but I'd be interested if Junfeng could give it a
  quick test.   It's against 2.6.11.
 
 I checked 2.6.11 with your patch just now.  Looks like the problem is
 still there.  If you need more information, let me know.  Image is at
 http://fisc.stanford.edu/bug2/crash-1.img.bz2.  Below is the output from
 e2fsck.

ugh.  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/


[PATCH] 2.6.11-mm1 ext3 writepages support for writeback mode

2005-03-04 Thread Badari Pulavarty
Hi Andrew,

Here is the 2.6.11-mm1 patch for adding writepages support
for ext3 writeback mode. Could you include it in -mm tree ?

Thanks,
Badari


diff -Naurp -X dontdiff linux-2.6.11/fs/ext3/inode.c linux-2.6.11.new/fs/ext3/inode.c
--- linux-2.6.11/fs/ext3/inode.c	2005-03-01 23:38:13.0 -0800
+++ linux-2.6.11.new/fs/ext3/inode.c	2005-03-04 15:35:02.304473032 -0800
@@ -858,6 +858,12 @@ get_block:
 	return ret;
 }
 
+static int ext3_writepages_get_block(struct inode *inode, sector_t iblock,
+			struct buffer_head *bh, int create)
+{
+	return ext3_direct_io_get_blocks(inode, iblock, 1, bh, create);
+}
+
 /*
  * `handle' can be NULL if create is zero
  */
@@ -1323,6 +1329,45 @@ out_fail:
 	return ret;
 }
 
+static int 
+ext3_writeback_writepage_helper(struct page *page,
+struct writeback_control *wbc)
+{
+	return block_write_full_page(page, ext3_get_block, wbc);
+}
+
+static int
+ext3_writeback_writepages(struct address_space *mapping, 
+struct writeback_control *wbc)
+{
+	struct inode *inode = mapping-host;
+	handle_t *handle = NULL;
+	int err, ret = 0;
+
+	if (!mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
+		return ret;
+
+	handle = ext3_journal_start(inode, ext3_writepage_trans_blocks(inode));
+	if (IS_ERR(handle)) {
+		ret = PTR_ERR(handle);
+		return ret;
+	}
+
+ret = __mpage_writepages(mapping, wbc, ext3_writepages_get_block,
+	ext3_writeback_writepage_helper);
+
+	/*
+	 * Need to reaquire the handle since ext3_writepages_get_block()
+	 * can restart the handle
+	 */
+	handle = journal_current_handle();
+
+	err = ext3_journal_stop(handle);
+	if (!ret)
+		ret = err;
+	return ret;
+}
+
 static int ext3_writeback_writepage(struct page *page,
 struct writeback_control *wbc)
 {
@@ -1554,6 +1599,7 @@ static struct address_space_operations e
 	.readpage	= ext3_readpage,
 	.readpages	= ext3_readpages,
 	.writepage	= ext3_writeback_writepage,
+	.writepages	= ext3_writeback_writepages,
 	.sync_page	= block_sync_page,
 	.prepare_write	= ext3_prepare_write,
 	.commit_write	= ext3_writeback_commit_write,
diff -Naurp -X dontdiff linux-2.6.11/fs/mpage.c linux-2.6.11.new/fs/mpage.c
--- linux-2.6.11/fs/mpage.c	2005-03-04 16:01:06.302709160 -0800
+++ linux-2.6.11.new/fs/mpage.c	2005-03-04 15:58:30.608378296 -0800
@@ -626,6 +626,15 @@ int
 mpage_writepages(struct address_space *mapping,
 		struct writeback_control *wbc, get_block_t get_block)
 {
+	return __mpage_writepages(mapping, wbc, get_block,
+		mapping-a_ops-writepage);
+}
+
+int
+__mpage_writepages(struct address_space *mapping,
+		struct writeback_control *wbc, get_block_t get_block,
+		writepage_t writepage_fn)
+{
 	struct backing_dev_info *bdi = mapping-backing_dev_info;
 	struct bio *bio = NULL;
 	sector_t last_block_in_bio = 0;
@@ -715,7 +724,7 @@ retry:
 			} else {
 bio = __mpage_writepage(bio, page, get_block,
 		last_block_in_bio, ret, wbc,
-		page-mapping-a_ops-writepage);
+		writepage_fn);
 			}
 			if (ret || (--(wbc-nr_to_write) = 0))
 done = 1;
@@ -743,6 +752,7 @@ retry:
 	return ret;
 }
 EXPORT_SYMBOL(mpage_writepages);
+EXPORT_SYMBOL(__mpage_writepages);
 
 int mpage_writepage(struct page *page, get_block_t get_block,
 	struct writeback_control *wbc)
diff -Naurp -X dontdiff linux-2.6.11/include/linux/mpage.h linux-2.6.11.new/include/linux/mpage.h
--- linux-2.6.11/include/linux/mpage.h	2005-03-04 16:01:07.654503656 -0800
+++ linux-2.6.11.new/include/linux/mpage.h	2005-03-04 15:35:56.778191768 -0800
@@ -20,6 +20,9 @@ int mpage_writepages(struct address_spac
 		struct writeback_control *wbc, get_block_t get_block);
 int mpage_writepage(struct page *page, get_block_t *get_block,
 		struct writeback_control *wbc);
+int __mpage_writepages(struct address_space *mapping,
+		struct writeback_control *wbc, get_block_t get_block,
+		writepage_t writepage);
 
 static inline int
 generic_writepages(struct address_space *mapping, struct writeback_control *wbc)


Re: [PATCH 2.6.11-rc3 02/08] ide: convert __ide_do_rw_disk() to use ide_load_taskfile()

2005-03-04 Thread Tejun Heo

02_ide_use_load_taskfile_in_do_rw_disk.patch

Reimplements __ide_do_rw_disk() using ide_load_taskfile().
While at it, clean up the function a little bit.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 ide-disk.c |  163 -
 1 files changed, 65 insertions(+), 98 deletions(-)

Index: linux-taskfile-ng/drivers/ide/ide-disk.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-disk.c   2005-03-05 
10:46:58.305078940 +0900
+++ linux-taskfile-ng/drivers/ide/ide-disk.c2005-03-05 10:46:58.762007508 
+0900
@@ -158,114 +158,80 @@ static int lba_capacity_is_ok (struct hd
  */
 ide_startstop_t __ide_do_rw_disk (ide_drive_t *drive, struct request *rq, 
sector_t block)
 {
-   ide_hwif_t *hwif= HWIF(drive);
-   unsigned int dma= drive-using_dma;
-   u8 lba48= (drive-addressing == 1) ? 1 : 0;
-   task_ioreg_t command= WIN_NOP;
-   ata_nsector_t   nsectors;
-
-   nsectors.all= (u16) rq-nr_sectors;
-
-   if (hwif-no_lba48_dma  lba48  dma) {
-   if (block + rq-nr_sectors  1ULL  28)
-   dma = 0;
-   }
-
-   if (!dma) {
-   ide_init_sg_cmd(drive, rq);
-   ide_map_sg(drive, rq);
-   }
+   ide_hwif_t *hwif = drive-hwif;
+   int lba48 = (drive-addressing == 1) ? 1 : 0;
+   ide_task_t task;
+   struct ata_taskfile *tf = task.tf;
+   u8 command;
 
+   /* ALL Command Block Executions SHALL clear nIEN. */
if (IDE_CONTROL_REG)
hwif-OUTB(drive-ctl, IDE_CONTROL_REG);
-
/* FIXME: SELECT_MASK(drive, 0) ? */
 
-   if (drive-select.b.lba) {
-   if (drive-addressing == 1) {
-   task_ioreg_t tasklets[10];
-
-   pr_debug(%s: LBA=0x%012llx\n, drive-name, block);
+   memset(task, 0, sizeof(task));
 
-   tasklets[0] = 0;
-   tasklets[1] = 0;
-   tasklets[2] = nsectors.b.low;
-   tasklets[3] = nsectors.b.high;
-   tasklets[4] = (task_ioreg_t) block;
-   tasklets[5] = (task_ioreg_t) (block8);
-   tasklets[6] = (task_ioreg_t) (block16);
-   tasklets[7] = (task_ioreg_t) (block24);
-   if (sizeof(block) == 4) {
-   tasklets[8] = (task_ioreg_t) 0;
-   tasklets[9] = (task_ioreg_t) 0;
-   } else {
-   tasklets[8] = (task_ioreg_t)((u64)block  32);
-   tasklets[9] = (task_ioreg_t)((u64)block  40);
-   }
-#ifdef DEBUG
-   printk(%s: 0x%02x%02x 0x%02x%02x%02x%02x%02x%02x\n,
-   drive-name, tasklets[3], tasklets[2],
-   tasklets[9], tasklets[8], tasklets[7],
-   tasklets[6], tasklets[5], tasklets[4]);
-#endif
-   hwif-OUTB(tasklets[1], IDE_FEATURE_REG);
-   hwif-OUTB(tasklets[3], IDE_NSECTOR_REG);
-   hwif-OUTB(tasklets[7], IDE_SECTOR_REG);
-   hwif-OUTB(tasklets[8], IDE_LCYL_REG);
-   hwif-OUTB(tasklets[9], IDE_HCYL_REG);
-
-   hwif-OUTB(tasklets[0], IDE_FEATURE_REG);
-   hwif-OUTB(tasklets[2], IDE_NSECTOR_REG);
-   hwif-OUTB(tasklets[4], IDE_SECTOR_REG);
-   hwif-OUTB(tasklets[5], IDE_LCYL_REG);
-   hwif-OUTB(tasklets[6], IDE_HCYL_REG);
-   hwif-OUTB(0x00|drive-select.all,IDE_SELECT_REG);
-   } else {
-   hwif-OUTB(0x00, IDE_FEATURE_REG);
-   hwif-OUTB(nsectors.b.low, IDE_NSECTOR_REG);
-   hwif-OUTB(block, IDE_SECTOR_REG);
-   hwif-OUTB(block=8, IDE_LCYL_REG);
-   hwif-OUTB(block=8, IDE_HCYL_REG);
-   
hwif-OUTB(((block8)0x0f)|drive-select.all,IDE_SELECT_REG);
-   }
+   if (drive-select.b.lba) {
+   /* LBA28/LBA48 */
+   tf-flags   |= ATA_TFLAG_OUT_ADDR | ATA_TFLAG_OUT_DEVICE;
+   tf-nsect   = rq-nr_sectors;
+   tf-lbal= block;
+   tf-lbam= block  8;
+   tf-lbah= block  16;
+
+   if (lba48) {
+   tf-flags   |= ATA_TFLAG_OUT_LBA48;
+   tf-hob_nsect   = rq-nr_sectors  8;
+   tf-hob_lbal= block  24;
+   tf-hob_lbam= block  32;
+   tf-hob_lbah= block  40;
+   } else
+   tf-device  = (block  24)  0xf;

Fwd: non-fatal oops with EIP at skb_release_data, available for debugging

2005-03-04 Thread Alessandro Suardi
Hmm, doesn't seem this ever made the lkml, no idea why...
 CC'ing netdev in case someone can spot anything interesting

The machine (running FC3) is still up and running after
 the oops.

-- Forwarded message --
From: Alessandro Suardi [EMAIL PROTECTED]
Date: Fri, 4 Mar 2005 21:48:18 +0100
Subject: non-fatal oops with EIP at skb_release_data, available for debugging
To: Linux Kernel Mailing List linux-kernel@vger.kernel.org


This is my K7-800, 256MB RAM machine running as
 ed2k/bittorrent 24/7 box... metacity died, but the
 windows are still alive (and working) so if someone
 wants to get more info about it, just ping me...

[EMAIL PROTECTED] ~]# cat /proc/version
Linux version 2.6.11-rc3-bk8 ([EMAIL PROTECTED]) (gcc version 3.4.2
20041017 (Red Hat 3.4.2-6.fc3)) #1 Sat Feb 12 00:01:28 CET 2005
[EMAIL PROTECTED] ~]# lsmod
Module  Size  Used by
loop   15368  -
nls_iso8859_1   3840  -
parport_pc 29444  -
parport24704  -
8139too24896  -
floppy 57392  -

From the dmesg ring:

kernel BUG at include/linux/mm.h:343!
invalid operand:  [#1]
PREEMPT
Modules linked in: loop nls_iso8859_1 parport_pc parport 8139too floppy
CPU:0
EIP:0060:[c02da6a2]Not tainted VLI
EFLAGS: 00210256   (2.6.11-rc3-bk8)
EIP is at skb_release_data+0x92/0xa0
eax:    ebx:    ecx: cca36f80   edx: c11a97c0
esi: c4205f20   edi: c4205f20   ebp: cd149dcc   esp: cd149dc4
ds: 007b   es: 007b   ss: 0068
Process metacity (pid: 2109, threadinfo=cd148000 task=ce8935d0)
Stack: c4205f20  cd149dd8 c02da6bb c6e9a0c0 cd149df8 c02da737 c5134250
    c4205f20 c5134250 c4205f20 c5134250 cd149e4c c02feba6 
   0040 cc68c454  0001 cc68c444 cd148000 0001 
Call Trace:
 [c0102b2a] show_stack+0x7a/0x90
 [c0102cad] show_registers+0x14d/0x1c0
 [c0102ea4] die+0xe4/0x180
 [c01032e3] do_invalid_op+0xa3/0xb0
 [c01027a7] error_code+0x2b/0x30
 [c02da6bb] kfree_skbmem+0xb/0x20
 [c02da737] __kfree_skb+0x67/0xf0
 [c02feba6] tcp_recvmsg+0x5f6/0x710
 [c02da1e6] sock_common_recvmsg+0x46/0x60
 [c02d6bbe] sock_aio_read+0xee/0x100
 [c014e427] do_sync_read+0x97/0xf0
 [c014e511] vfs_read+0x91/0x120
 [c014e7ed] sys_read+0x3d/0x70
 [c01025a9] sysenter_past_esp+0x52/0x75
Code: c9 e9 03 e5 e5 ff 8d 76 00 5b 5e c9 c3 89 d0 e8 c5 f2 e5 ff eb
cf 89 f0 e8 0c ff ff ff 5b 8b 86 98 00 00 00 5e c9 e9 de e4 e5 ff 0f
0b 57 01 ab c5 35 c0 eb a5 8d 74 26 00 55 89 e5 53 89 c3 e8

Thanks,

 
--alessandro

  There is no distance that I don't see
  I do have a will - No limit to my reach
  
(Wallflowers, Empire In My Mind)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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-rc3 00/08] ide: taskfile cleanup

2005-03-04 Thread Tejun Heo

 Hello, Bartlomiej.
 Hello, Jeff.

 These eight patches

 * define ATA_TFLAG_{OUT|IN}_* flags
 * unify/generalize taskfile transport
 * cleanup ide driver accordingly

 For behavior changes by #03.  I don't think defining a special flag
to handle the TASKFILE case is necessary.  The change isn't
user-visible.  And for the TASK ioctl, I think we should modify all
ioctls to disallow changing the upper nibble of the DEVICE register
except for the LBA bit.  What do you think?

 I tried hard not to break things and tested changes but I'm pretty
sure that I've missed something.  So, please comment.  :-)

[ Start of patch descriptions ]

01_ide_TFLAG_OUT_IN.patch
: add individual ATA_TFLAG_{OUT|IN}_* flags

This patch replaces ide_task_t-tf_{out|in}_flags handling
with newly defined individual ATA_TFLAG_{OUT|IN}_* flags and
helper functions ide_{load|read}_taskfile().  To ease
transition of the IDE code, temporary flags
ATA_TFLAG_IDE_FLAGGED and ATA_TFLAG_IDE_LBA48 are defined.
This patch is tit-for-tat and shouldn't change any behavior.

02_ide_use_load_taskfile_in_do_rw_disk.patch
: convert __ide_do_rw_disk() to use ide_load_taskfile()

Reimplements __ide_do_rw_disk() using ide_load_taskfile().
While at it, clean up the function a little bit.

03_ide_remove_flagged_taskfile.patch
: remove flagged_taskfile() and unify taskfile paths

This patch removes flagged_taskfile().  All taskfile command
issuing goes through do_rw_taskfile().  do_rw_taskfile()
doesn't modify mangle with load flags anymore.  It's now
caller's responsibility to set appropriate flags.  Likewise,
ide_end_drive_cmd() is modified not to mangle with read flags,
and ide_dma_intr() now also finishes commands with
task_end_request().  Above changes make taskfile path unified
 generic.

As all ioctl subtleties are now responsibility of respective
ioctl functions.  TASKFILE and TASK ioctl functions are
updated to set flags according to old behaviors.  The
following two behavior changes occur.

* TASKFILE ioctl: taskfile registers are read back whether or
  not the command fails.  As copying back to user doesn't
  happen in cases where reading back didn't occur before, this
  change isn't user-visible.  Defining  using a flag like
  ATA_TFLAG_READ_ON_ERROR will remove this issue.
* TASK ioctl: drive-select.all  ~ATA_LBA is OR'd to device
  value.  Previously, only ATA_DEV bit was OR'd.

Also, all ide_{raw|diag}_taskfile(), do_rw_taskfile() users
are converted to use the new individual OUT/IN flags.  As
results, the following behavior changes occur.

* idedisk_read_native_max_address(): ADDR/LBA48 regs are not
  loaded.  LBA48/DEVICE registers are not read back unless
  necessary.
* idedisk_set_max_address(): DEVICE register is not read
  unless necessary.
* smart_enable(): DEVICE register is not loaded.  Registers
  are not read back.
* smart_disable(): ditto
* get_smart_threshold(): DEVICE register is not loaded.
* ide_task_init_flush(): ADDR/LBA48/DEVICE registers are not
  loaded.
* ide_init_specify_cmd(): Register aren't read back.
* ide_init_restore_cmd(): DEVICE register not loaded.  No read back.
* ide_init_setmult_cmd(): ditto

04_ide_remove_unused_fields.patch
: remove unused fields ide_drive_t-rq and ide_task_t-special

Remove unused fields ide_drive_t-rq and ide_task_t-special

05_ide_use_protocol.patch
: use ide_task_t-tf.protocol instead of ide_task_t-data_phase

Remove ide_task_t-{data_phase,command_type,prehandler,rq} and
use tf-protocol instead.  Now the protocol value wholey
defines how to drive a taskfile except for NODATA cases where
a caller can optionally specify handler (for special
commands).  The following behavior changes occur.

* ide_taskfile_ioctl(): req_task-command_type is ignored.
  This doesn't make any difference except for error/crash
  cases in the original code.

06_ide_taskfile_set_xfer_rate.patch
: convert set_xfer_rate() to use taskfile ioctl

Convert set_xfer_rate() to use taskfile ioctl.

07_ide_taskfile_cmd_ioctl.patch
: reimplement ide_cmd_ioctl() using taskfile

Reimplement ide_cmd_ioctl() using taskfile.

08_ide_remove_REQ_DRIVE_CMD.patch
: remove REQ_DRIVE_CMD handling

Remove REQ_DRIVE_CMD handling.  ide_init_drive_cmd() now
defaults to REQ_DRIVE_TASKFILE (now the only drive command :-).

[ End of patch descriptions ]

 Thanks.

--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

[PATCH] ata_piix.c: check PCI sub-class code before AHCI disabling

2005-03-04 Thread Greg Felix
This patch adds functionality to check the PCI sub-class code of an
AHCI capable device before disabling AHCI.  It fixes a bug where an
ICH7 sata controller is being setup by the BIOS as sub-class 1 (ide)
and the AHCI control registers weren't being initialized, thus causing
an IO error in piix_disable_ahci().

Thanks,
Greg Felix


Signed-off-by: Gregory Felix [EMAIL PROTECTED]

--- drivers/scsi/ata_piix.c.orig2005-03-04 15:25:48.966846795 -0700
+++ drivers/scsi/ata_piix.c 2005-03-04 15:27:55.942404850 -0700
@@ -38,6 +38,7 @@ enum {
PIIX_IOCFG  = 0x54, /* IDE I/O configuration register */
ICH5_PMR= 0x90, /* port mapping register */
ICH5_PCS= 0x92, /* port control and status */
+   PIIX_SCC= 0x0A, /* sub-class code register */

PIIX_FLAG_AHCI  = (1  28), /* AHCI possible */
PIIX_FLAG_CHECKINTR = (1  29), /* make sure PCI INTx enabled */
@@ -61,6 +62,8 @@ enum {
ich6_sata   = 3,
ich6_sata_rm= 4,
ich7_sata   = 5,
+
+   PIIX_AHCI_DEVICE= 6,
 };

 static int piix_init_one (struct pci_dev *pdev,
@@ -609,9 +612,13 @@ static int piix_init_one (struct pci_dev
port_info[1] = NULL;

if (port_info[0]-host_flags  PIIX_FLAG_AHCI) {
-   int rc = piix_disable_ahci(pdev);
-   if (rc)
-   return rc;
+   u8 tmp;
+   pci_read_config_byte(pdev, PIIX_SCC, tmp);
+   if (tmp == PIIX_AHCI_DEVICE) {
+   int rc = piix_disable_ahci(pdev);
+   if (rc)
+   return rc;
+   }
}

if (port_info[0]-host_flags  PIIX_FLAG_COMBINED) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH/RFC] I/O-check interface for driver's error handling

2005-03-04 Thread Pavel Machek
On So 05-03-05 10:03:37, Benjamin Herrenschmidt wrote:
 On Fri, 2005-03-04 at 23:57 +0100, Pavel Machek wrote:
 
  What prevents driver from being run on another CPU, maybe just doing
  mdelay() between hardware accesses? 
 
 Almost all drivers that I know have some sort of locking. Nothing nasty
 about it. Besides, you can't expect everything to be as simple as
 putting two bit of lego together, the problem isn't simple.

If error() is allowed to sleep, then yes, its probably easy enough. If
it is not allowed to sleep, it will just postpone work to context that
is allowed to sleep, and it will probably be okay, too.

= there are some locking issues, but they are probably easy
enough. Sorry for noise.
Pavel

-- 
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/RFC] I/O-check interface for driver's error handling

2005-03-04 Thread Benjamin Herrenschmidt
On Sat, 2005-03-05 at 00:18 +0100, Pavel Machek wrote:
 On So 05-03-05 10:03:37, Benjamin Herrenschmidt wrote:
  On Fri, 2005-03-04 at 23:57 +0100, Pavel Machek wrote:
  
   What prevents driver from being run on another CPU, maybe just doing
   mdelay() between hardware accesses? 
  
  Almost all drivers that I know have some sort of locking. Nothing nasty
  about it. Besides, you can't expect everything to be as simple as
  putting two bit of lego together, the problem isn't simple.
 
 If error() is allowed to sleep, then yes, its probably easy enough. If
 it is not allowed to sleep, it will just postpone work to context that
 is allowed to sleep, and it will probably be okay, too.

Yes, it's my itend that the notification callback is to be called in a
task context where it can sleep.

 = there are some locking issues, but they are probably easy
 enough. Sorry for noise.
   Pavel
 
-- 
Benjamin Herrenschmidt [EMAIL PROTECTED]

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


Re: [PATCH] 2.6.11-mm1 ext3 writepages support for writeback mode

2005-03-04 Thread Badari Pulavarty
On Fri, 2005-03-04 at 15:43, Andrew Morton wrote:
 Badari Pulavarty [EMAIL PROTECTED] wrote:
 
  Hi Andrew,
  
  Here is the 2.6.11-mm1 patch for adding writepages support
  for ext3 writeback mode. Could you include it in -mm tree ?
 
 spose so.  Does it work?
 
 Do you have any benchmarking results handy?

I did few benchmarks earlier which showed 5-7% improvement
on throughput. I will run the numbers again.

 
  +static int
  +ext3_writeback_writepages(struct address_space *mapping, 
  +   struct writeback_control *wbc)
  +{
  +   struct inode *inode = mapping-host;
  +   handle_t *handle = NULL;
  +   int err, ret = 0;
  +
  +   if (!mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
  +   return ret;
 
 Can we please add a comment explaining why this is here?  I've already
 forgotten why we put it there.

This is to avoid not starting the journal when we are trying to
destroy journal inode. I will add comments.

   journal_destory()
   iput(journal inode)
   do_writepages()
   generic_writepages()
   ext3_writeback_writepage()
   journal_start()

 
Thanks,
Badari


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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-rc3 07/08] ide: reimplement ide_cmd_ioctl() using taskfile

2005-03-04 Thread Tejun Heo

07_ide_taskfile_cmd_ioctl.patch

Reimplement ide_cmd_ioctl() using taskfile.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 drivers/ide/ide-taskfile.c |  105 +
 include/linux/ide.h|8 ---
 2 files changed, 60 insertions(+), 53 deletions(-)

Index: linux-taskfile-ng/drivers/ide/ide-taskfile.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-taskfile.c   2005-03-05 
10:46:59.686862923 +0900
+++ linux-taskfile-ng/drivers/ide/ide-taskfile.c2005-03-05 
10:47:00.116795711 +0900
@@ -770,75 +770,90 @@ abort:
return err;
 }
 
-int ide_wait_cmd (ide_drive_t *drive, u8 cmd, u8 nsect, u8 feature, u8 
sectors, u8 *buf)
+int ide_cmd_ioctl(ide_drive_t *drive, unsigned int cmd, unsigned long arg)
 {
-   struct request rq;
-   u8 buffer[4];
-
-   if (!buf)
-   buf = buffer;
-   memset(buf, 0, 4 + SECTOR_WORDS * 4 * sectors);
-   ide_init_drive_cmd(rq);
-   rq.buffer = buf;
-   *buf++ = cmd;
-   *buf++ = nsect;
-   *buf++ = feature;
-   *buf++ = sectors;
-   return ide_do_drive_cmd(drive, rq, ide_wait);
-}
-
-/*
- * FIXME : this needs to map into at taskfile. [EMAIL PROTECTED]
- */
-int ide_cmd_ioctl (ide_drive_t *drive, unsigned int cmd, unsigned long arg)
-{
-   int err = 0;
-   u8 args[4], *argbuf = args;
-   u8 xfer_rate = 0;
-   int argsize = 4;
-   ide_task_t tfargs;
-   struct ata_taskfile *tf = tfargs.tf;
+   void __user *p = (void __user *)arg;
+   u8 args[4];
+   ide_task_t task;
+   struct ata_taskfile *tf = task.tf;
+   void *buf = NULL;
+   int xfer_rate = 0, in_size, err;
 
-   if (NULL == (void *) arg) {
+   if (p == NULL) {
struct request rq;
ide_init_drive_cmd(rq);
return ide_do_drive_cmd(drive, rq, ide_wait);
}
 
-   if (copy_from_user(args, (void __user *)arg, 4))
+   if (copy_from_user(args, p, 4))
return -EFAULT;
 
-   memset(tfargs, 0, sizeof(ide_task_t));
+   memset(task, 0, sizeof(task));
+
+   /*
+* Due to a bug in the original code, args[1] was not loaded
+* into lbal but instead loaded into nsect except for
+* WIN_SMART.  IOW, args[3] was used for sector count to setup
+* the command but it was args[1] which actually got into the
+* nsect register.
+*
+* Another problem is that lbal is used in the
+* WIN_SETFEATURES/SETFEATURES_XFER command.  The original
+* code worked because ide_set_xfer_rate() issued the command
+* again with correct registers loaded.
+*
+* So, here, we load args[1] for WIN_SMART and
+* SETFEATURES_XFER; otherwise, we ignore args[1].
+*/
+   tf-flags   = ATA_TFLAG_OUT_FEATURE | ATA_TFLAG_IN_FEATURE  |
+ ATA_TFLAG_OUT_NSECT   | ATA_TFLAG_IN_NSECT|
+ ATA_TFLAG_IO_16BIT;
tf-feature = args[2];
tf-nsect   = args[3];
tf-lbal= args[1];
tf-command = args[0];
 
-   if (args[3]) {
-   argsize = 4 + (SECTOR_WORDS * 4 * args[3]);
-   argbuf = kmalloc(argsize, GFP_KERNEL);
-   if (argbuf == NULL)
-   return -ENOMEM;
-   memcpy(argbuf, args, 4);
+   if (set_transfer(drive, task)) {
+   tf-flags   |= ATA_TFLAG_OUT_LBAL;
+   xfer_rate   = args[1];
+   if (ide_ata66_check(drive, task))
+   return -EIO;
}
-   if (set_transfer(drive, tfargs)) {
-   xfer_rate = args[1];
-   if (ide_ata66_check(drive, tfargs))
-   goto abort;
+
+   /* SMART needs its secret keys in lcyl and hcyl registers. */
+   if (tf-command == WIN_SMART) {
+   tf-flags   |= ATA_TFLAG_OUT_LBAL | ATA_TFLAG_OUT_LBAM |
+  ATA_TFLAG_OUT_LBAH;
+   tf-lbam= SMART_LCYL_PASS;
+   tf-lbah= SMART_HCYL_PASS;
}
 
-   err = ide_wait_cmd(drive, args[0], args[1], args[2], args[3], argbuf);
+   in_size = 4 * SECTOR_WORDS * args[3];
+
+   if (in_size) {
+   tf-protocol= ATA_PROT_PIO;
+   if ((buf = kmalloc(in_size, GFP_KERNEL)) == NULL)
+   return -ENOMEM;
+   memset(buf, 0, in_size);/* paranoia */
+   } else
+   tf-protocol= ATA_PROT_NODATA;
+
+   err = ide_diag_taskfile(drive, task, READ, in_size, buf);
 
if (!err  xfer_rate) {
/* active-retuning-calls future */
ide_set_xfer_rate(drive, xfer_rate);
ide_driveid_update(drive);
}
-abort:
-   if (copy_to_user((void __user *)arg, argbuf, argsize))
+
+   args[0] = 

Re: [PATCH 2.6.11-rc3 06/08] ide: convert set_xfer_rate() to use taskfile ioctl

2005-03-04 Thread Tejun Heo

06_ide_taskfile_set_xfer_rate.patch

Convert set_xfer_rate() to use taskfile ioctl.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 ide.c |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)

Index: linux-taskfile-ng/drivers/ide/ide.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide.c2005-03-05 10:37:51.451393268 
+0900
+++ linux-taskfile-ng/drivers/ide/ide.c 2005-03-05 10:46:59.933824315 +0900
@@ -1250,10 +1250,19 @@ static int set_pio_mode (ide_drive_t *dr
 
 static int set_xfer_rate (ide_drive_t *drive, int arg)
 {
-   int err = ide_wait_cmd(drive,
-   WIN_SETFEATURES, (u8) arg,
-   SETFEATURES_XFER, 0, NULL);
+   ide_task_t task;
+   struct ata_taskfile *tf = task.tf;
+   int err;
+
+   memset(task, 0, sizeof(task));
+
+   tf-protocol= ATA_PROT_NODATA;
+   tf-flags   = ATA_TFLAG_OUT_ADDR;
+   tf-feature = SETFEATURES_XFER;
+   tf-nsect   = arg;
+   tf-command = WIN_SETFEATURES;
 
+   err = ide_raw_taskfile(drive, task, 0, NULL);
if (!err  arg) {
ide_set_xfer_rate(drive, (u8) arg);
ide_driveid_update(drive);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Russell King
On Fri, Mar 04, 2005 at 02:48:08PM -0800, Andrew Morton wrote:
 Russell King [EMAIL PROTECTED] wrote:
 
  On Fri, Mar 04, 2005 at 02:22:19PM -0800, Andrew Morton wrote:
   That's now eight architectures I'll compile-test mm kernels on.
  
  Cool, but please check whether this produces an error:
  
  echo mov r0, #foo | arm-linux-as -o /dev/null -
  
  you should get:
  {standard input}: Assembler messages:
  {standard input}:1: Error: undefined symbol foo used as an immediate value
 
 I did get that.

Great - this will help ensure that any breakage due to that binutils
problem should get caught relatively quickly no matter how it gets in
to either your or Linus' kernel.  This is a definite plus.  Thanks.

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


Re: RFD: Kernel release numbering

2005-03-04 Thread Andrew Morton
Russell King [EMAIL PROTECTED] wrote:

 On Fri, Mar 04, 2005 at 02:22:19PM -0800, Andrew Morton wrote:
  That's now eight architectures I'll compile-test mm kernels on.
 
 Cool, but please check whether this produces an error:
 
 echo mov r0, #foo | arm-linux-as -o /dev/null -
 
 you should get:
 {standard input}: Assembler messages:
 {standard input}:1: Error: undefined symbol foo used as an immediate value

I did get 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: [SATA] libata-dev queue updated

2005-03-04 Thread Joerg Sommrey
On Fri, Mar 04, 2005 at 11:06:23PM +0100, Joerg Sommrey wrote:
 On Fri, Mar 04, 2005 at 03:43:38PM -0500, Jeff Garzik wrote:
  Joerg Sommrey wrote:
  On Fri, Mar 04, 2005 at 01:07:16PM -0500, Jeff Garzik wrote:
  
  Joerg Sommrey wrote:
  
  On Fri, Mar 04, 2005 at 02:10:14AM -0500, Jeff Garzik wrote:
  
  
  Joerg Sommrey wrote:
  
  
  On Thu, Mar 03, 2005 at 11:09:26PM -0500, Jeff Garzik wrote:
  
  
  
  Joerg Sommrey wrote:
  
  
  
  On Wed, Mar 02, 2005 at 05:43:59PM -0500, Jeff Garzik wrote:
  
  
  
  
  Joerg Sommrey wrote:
  
  
  
  
  Jeff Garzik wrote:
  
  
  
  
  Patch:
  http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.11-rc5-bk4-libata-dev1.patch.bz2
  
  
  Still not usable here.  The same errors as before when backing up:
  
  Please try 2.6.11 without any patches.
  
  Plain 2.6.11 doesn't work either.  All of 2.6.10-ac11, 2.6.11-rc5,
  2.6.11-rc5 + 2.6.11-rc5-bk4-libata-dev1.patch and 2.6.11 fail with 
  the
  same symptoms. 
  
  Reverting to stable 2.6.10-ac8 :-)
  
  Does reverting the attached patch in 2.6.11 (apply with patch -R) fix 
  things?
  
  
  
  Still the same with this patch reverted.
  
  Does reverting the attached patch in 2.6.11 fix things?  (apply with 
  patch -R)
  
  This patch reverts the entire libata back to 2.6.10.
  
  
  I'm confused.  Still the same with everything reverted.  What shall I do
  now?
  
  Well, first, thanks for your patience in narrowing this down.
  
  This means we have eliminated libata as a problem source, but we still 
  have the rest of the kernel go to through :)
  
  Try disabling ACPI with 'acpi=off' or 'pci=biosirq' to see if that fixes 
  things.
  
  
  I tried both settings with plain 2.6.11. Almost the same results, in my
  impression apci=off causes the failure to appear even faster.
  
  Just to make sure I have things right, please tell me if this is correct:
  
  * 2.6.10 vanilla works
  
  * 2.6.11 vanilla does not work
  
  * 2.6.11 vanilla + 2.6.10 libata does not work
[2.6.10 libata == reverting all libata changes]
  
  Is that all correct?
 
 Thanks for asking these precise questions.  After double-checking
 everything I found a typo in my configuration that changes things a bit.
 I repeated some tests and the correct answers are now:
 * 2.6.10 vanilla  works
 * 2.6.10-ac8  works
 * 2.6.10-ac11 does not work
 * 2.6.11 vanilla  does not work
 * 2.6.11 w/o promise.patchdoes not work
 * 2.6.11 + 2.6.10 libata  works!
 
 This looks much more consistent to me but brings the case back to
 libata.

After one more test using 2.6.11 + 2.6.10 libata I got some errors.
They are different, they end after some time and they don't lock the system:

Mar  4 23:15:00 bear kernel: ata1: status=0x51 { DriveReady SeekComplete Error 
}Mar  4 23:15:00 bear kernel: sdb: Current: sense key: Recovered Error
Mar  4 23:15:00 bear kernel: ASC=0x26 vendor ASCQ=0xc0
Mar  4 23:15:00 bear kernel: FMK, ILI

Got 1900 of these in 90 seconds and silence afterwards.  Maybe that
helps. I'll keep this kernel running and watch it.

-jo

-- 
-rw-r--r--  1 jo users 63 2005-03-04 23:12 /home/jo/.signature
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: slab corruption in skb allocs

2005-03-04 Thread Richard Fuchs
Matt Mackall wrote:
Which card/driver is this? Is this the same card that's showing ssh
troubles? My theory about your ssh trouble only applies to cards with
checksum offload.
i got the same on all three machines i was testing with, with both the 
e100 and the eepro100 driver. one of those three machines was the one 
with the ssh troubles, its card is identified as Intel Corp. 82557/8/9 
[Ethernet Pro 100] (rev 08), pci id 8086:1229. plus, i couldn't 
reproduce those problems on a machine with e1000, which does support all 
kinds of checksum offloading. (there might still be something fishy with 
the e1000 as well, as i'm not entirely trusting the errors from the slab 
checkers alone. especially since i don't see those messages when i 
enable page alloc debugging.)

another machine behaves even more strangely... its nic is identified as 
Intel Corp. 82801BD PRO/100 VE (LOM) Ethernet Controller (rev 81), pci 
id 8086:1039, also apparently not supporting hardware checksums. it does 
immediately produce the slab debug errors when i bombard it with udp 
packets while having disk access w/o dma, but remains silent when doing 
the same with a tcp transfer instead of udp packets. neither ssh traffic 
nor /dev/zero piped through netcat (no matter in which direction) makes 
it catch any errors. i only got a _single_ message from the slab 
debugger when sending /dev/zero through netcat in _both_ directions at 
the same time (in and out). however, i do get pages and pages of those 
messages when sending a simple stream of udp packets to the box... 
again, this is all with the e100 driver, i couldn't produce any similar 
results with the eepro100 or the e1000 driver yet, but apparently this 
doesn't necessarily mean that there isn't something wrong anyway...

cheers
richard
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Jeff Garzik
Greg KH wrote:
On Fri, Mar 04, 2005 at 02:36:14PM -0800, Andrew Morton wrote:
But we end up with a cset in the permanent kernel history which simply
should not have been there.

Is this really a big deal?
If you are pushing linux-release to Linus/Andrew rapidly, quick fixes 
will land in linux-2.6 rapidly, and more invasive stuff will land only 
in linux-2.6 when the invasive stuff is ready to go.  It even takes the 
pressure off pushing invasive stuff ASAP.

Have you pushed linux-2.6.11.1 upstream yet?  :)
Jeff

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


Re: Something is broken with SATA RAID ?

2005-03-04 Thread Andrew Morton
J.A. Magallon [EMAIL PROTECTED] wrote:

 One piece at last...
  I have tried
  - 2.6.11
  - 2.6.11 + libata-dev1 + netdev1 + shrinkers-at-tail + 1Gb-lowmem
 
  Bot work fine and survived several gigas dumped both through smb and afp.
  Happy man ;).
 
  If there was something strange, it must be in -mm. rc5-mm1 did not work,
  but plain 2.6.11 works. I will try 2.6.11-mm1 on monday...

Please enable NMI watchdog, CONFIG_DETECT_SOFTLOCKUP and try sysrq-T and
sysrq-P.  See if we can somehow get a trace.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 nobh support for ext3 writeback mode

2005-03-04 Thread Andrew Morton
Andrew Morton [EMAIL PROTECTED] wrote:

 page reclaim can come in, grab the page lock and
 whip the page off the mapping.

No it can't - we hold an additional ref on the page, so reclaim will back
off.  Still, it feels a bit flakey.

And we're not supposed to take lock_page() inside journal_start, because
that's a ranking violation.  Probably i_sem will prevent an actual deadlock
occurring, however.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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-rc3 03/08] ide: remove flagged_taskfile() and unify taskfile paths

2005-03-04 Thread Tejun Heo

03_ide_remove_flagged_taskfile.patch

This patch removes flagged_taskfile().  All taskfile command
issuing goes through do_rw_taskfile().  do_rw_taskfile()
doesn't modify mangle with load flags anymore.  It's now
caller's responsibility to set appropriate flags.  Likewise,
ide_end_drive_cmd() is modified not to mangle with read flags,
and ide_dma_intr() now also finishes commands with
task_end_request().  Above changes make taskfile path unified
 generic.

As all ioctl subtleties are now responsibility of respective
ioctl functions.  TASKFILE and TASK ioctl functions are
updated to set flags according to old behaviors.  The
following two behavior changes occur.

* TASKFILE ioctl: taskfile registers are read back whether or
  not the command fails.  As copying back to user doesn't
  happen in cases where reading back didn't occur before, this
  change isn't user-visible.  Defining  using a flag like
  ATA_TFLAG_READ_ON_ERROR will remove this issue.
* TASK ioctl: drive-select.all  ~ATA_LBA is OR'd to device
  value.  Previously, only ATA_DEV bit was OR'd.

Also, all ide_{raw|diag}_taskfile(), do_rw_taskfile() users
are converted to use the new individual OUT/IN flags.  As
results, the following behavior changes occur.

* idedisk_read_native_max_address(): ADDR/LBA48 regs are not
  loaded.  LBA48/DEVICE registers are not read back unless
  necessary.
* idedisk_set_max_address(): DEVICE register is not read
  unless necessary.
* smart_enable(): DEVICE register is not loaded.  Registers
  are not read back.
* smart_disable(): ditto
* get_smart_threshold(): DEVICE register is not loaded.
* ide_task_init_flush(): ADDR/LBA48/DEVICE registers are not
  loaded.
* ide_init_specify_cmd(): Register aren't read back.
* ide_init_restore_cmd(): DEVICE register not loaded.  No read back.
* ide_init_setmult_cmd(): ditto

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 drivers/ide/ide-disk.c |   31 ++---
 drivers/ide/ide-dma.c  |   16 --
 drivers/ide/ide-io.c   |   21 +--
 drivers/ide/ide-taskfile.c |  263 +
 include/linux/ata.h|6 -
 include/linux/ide.h|6 -
 6 files changed, 136 insertions(+), 207 deletions(-)

Index: linux-taskfile-ng/drivers/ide/ide-disk.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-disk.c   2005-03-05 
10:46:58.762007508 +0900
+++ linux-taskfile-ng/drivers/ide/ide-disk.c2005-03-05 10:46:59.081957489 
+0900
@@ -301,21 +301,22 @@ static u64 idedisk_read_native_max_addre
/* Create IDE/ATA command request structure */
memset(args, 0, sizeof(ide_task_t));
 
-   tf-device  = 0x40;
+   tf-flags   = ATA_TFLAG_OUT_DEVICE | ATA_TFLAG_IN_ADDR;
+   tf-device  = ATA_LBA;
if (lba48) {
+   tf-flags |= ATA_TFLAG_IN_LBA48;
tf-command = WIN_READ_NATIVE_MAX_EXT;
-   tf-flags |= ATA_TFLAG_IDE_LBA48;
-   } else
+   } else {
+   tf-flags |= ATA_TFLAG_IN_DEVICE;
tf-command = WIN_READ_NATIVE_MAX;
+   }
 
args.command_type   = IDE_DRIVE_TASK_NO_DATA;
args.handler= task_no_data_intr;
 
 /* submit command request */
-ide_raw_taskfile(drive, args, NULL);
-
-   /* if OK, compute maximum address value */
-   if ((tf-command  1) == 0) {
+   if (ide_raw_taskfile(drive, args, NULL) == 0) {
+   /* if OK, compute maximum address value */
addr = ide_tf_get_address(drive, tf);
addr++; /* since the return value is (maxlba - 1), we add 1 */
}
@@ -336,19 +337,20 @@ static u64 idedisk_set_max_address(ide_d
/* Create IDE/ATA command request structure */
memset(args, 0, sizeof(ide_task_t));
 
+   tf-flags   = ATA_TFLAG_OUT_DEVICE | ATA_TFLAG_ISADDR;
+   tf-device  = ATA_LBA;
tf-lbal= addr_req;
tf-lbam= addr_req  8;
tf-lbah= addr_req  16;
if (lba48) {
+   tf-flags   |= ATA_TFLAG_LBA48;
tf-hob_lbal= addr_req  24;
tf-hob_lbam= addr_req  32;
tf-hob_lbah= addr_req  40;
-   tf-device  = 0x40;
tf-command = WIN_SET_MAX_EXT;
-
-   tf-flags |= ATA_TFLAG_IDE_LBA48;
} else {
-   tf-device  = ((addr_req  24)  0xf) | 0x40;
+   tf-flags   |= ATA_TFLAG_IN_DEVICE;
+   tf-device  |= (addr_req  24)  0xf;
tf-command = WIN_SET_MAX;
}
 
@@ -356,9 +358,7 @@ static u64 

Re: [PATCH 2.6.11-rc3 01/08] ide: add individual ATA_TFLAG_{OUT|IN}_* flags

2005-03-04 Thread Tejun Heo

01_ide_TFLAG_OUT_IN.patch

This patch replaces ide_task_t-tf_{out|in}_flags handling
with newly defined individual ATA_TFLAG_{OUT|IN}_* flags and
helper functions ide_{load|read}_taskfile().  To ease
transition of the IDE code, temporary flags
ATA_TFLAG_IDE_FLAGGED and ATA_TFLAG_IDE_LBA48 are defined.
This patch is tit-for-tat and shouldn't change any behavior.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 drivers/ide/ide-disk.c |4 
 drivers/ide/ide-io.c   |   35 +--
 drivers/ide/ide-taskfile.c |  220 +++--
 include/linux/ata.h|   66 -
 include/linux/ide.h|   10 +-
 5 files changed, 213 insertions(+), 122 deletions(-)

Index: linux-taskfile-ng/drivers/ide/ide-disk.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-disk.c   2005-03-05 
10:37:51.738348597 +0900
+++ linux-taskfile-ng/drivers/ide/ide-disk.c2005-03-05 10:46:58.305078940 
+0900
@@ -337,7 +337,7 @@ static u64 idedisk_read_native_max_addre
tf-device  = 0x40;
if (lba48) {
tf-command = WIN_READ_NATIVE_MAX_EXT;
-   tf-flags |= ATA_TFLAG_LBA48;
+   tf-flags |= ATA_TFLAG_IDE_LBA48;
} else
tf-command = WIN_READ_NATIVE_MAX;
 
@@ -379,7 +379,7 @@ static u64 idedisk_set_max_address(ide_d
tf-device  = 0x40;
tf-command = WIN_SET_MAX_EXT;
 
-   tf-flags |= ATA_TFLAG_LBA48;
+   tf-flags |= ATA_TFLAG_IDE_LBA48;
} else {
tf-device  = ((addr_req  24)  0xf) | 0x40;
tf-command = WIN_SET_MAX;
Index: linux-taskfile-ng/drivers/ide/ide-io.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-io.c 2005-03-05 10:37:51.738348597 
+0900
+++ linux-taskfile-ng/drivers/ide/ide-io.c  2005-03-05 10:46:58.307078627 
+0900
@@ -64,7 +64,7 @@ void ide_task_init_flush(ide_drive_t *dr
if (ide_id_has_flush_cache_ext(drive-id) 
(drive-capacity64 = (1UL  28))) {
tf-command = WIN_FLUSH_CACHE_EXT;
-   tf-flags |= ATA_TFLAG_LBA48;
+   tf-flags |= ATA_TFLAG_IDE_LBA48;
} else
tf-command = WIN_FLUSH_CACHE;
 
@@ -322,7 +322,7 @@ u64 ide_tf_get_address(ide_drive_t *driv
 {
u32 high, low;
 
-   if (tf-flags  ATA_TFLAG_LBA48) {
+   if (tf-flags  ATA_TFLAG_IDE_LBA48) {
high = (tf-hob_lbah  16) | (tf-hob_lbam  8) | 
tf-hob_lbal;
low = (tf-lbah  16) | (tf-lbam  8) | tf-lbal;
} else {
@@ -458,31 +458,10 @@ void ide_end_drive_cmd (ide_drive_t *dri

if (args) {
struct ata_taskfile *tf = args-tf;
-
-   if (args-tf_in_flags.b.data)
-   args-data = hwif-INW(IDE_DATA_REG);
-
-   tf-feature = err;
-
-   /* be sure we're looking at the low order bits */
-   hwif-OUTB(drive-ctl  ~0x80, IDE_CONTROL_REG);
-
-   tf-nsect   = hwif-INB(IDE_NSECTOR_REG);
-   tf-lbal= hwif-INB(IDE_SECTOR_REG);
-   tf-lbam= hwif-INB(IDE_LCYL_REG);
-   tf-lbah= hwif-INB(IDE_HCYL_REG);
-   tf-device  = hwif-INB(IDE_SELECT_REG);
-   tf-command = stat;
-
-   if (tf-flags  ATA_TFLAG_LBA48) {
-   hwif-OUTB(drive-ctl|0x80, IDE_CONTROL_REG);
-
-   tf-hob_feature = hwif-INB(IDE_FEATURE_REG);
-   tf-hob_nsect   = hwif-INB(IDE_NSECTOR_REG);
-   tf-hob_lbal= hwif-INB(IDE_SECTOR_REG);
-   tf-hob_lbam= hwif-INB(IDE_LCYL_REG);
-   tf-hob_lbah= hwif-INB(IDE_HCYL_REG);
-   }
+   tf-flags |= ATA_TFLAG_IN_ADDR | ATA_TFLAG_IN_DEVICE;
+   if (tf-flags  ATA_TFLAG_IDE_LBA48)
+   tf-flags |= ATA_TFLAG_IN_LBA48;
+   ide_read_taskfile(drive, args, stat, err);
}
} else if (blk_pm_request(rq)) {
 #ifdef DEBUG_PM
@@ -935,7 +914,7 @@ static ide_startstop_t execute_drive_cmd
break;
}
 
-   if (args-tf_out_flags.all != 0) 
+   if (args-tf.flags  ATA_TFLAG_IDE_FLAGGED)
return flagged_taskfile(drive, args);
return do_rw_taskfile(drive, args);
} else if (rq-flags  REQ_DRIVE_CMD) {
Index: linux-taskfile-ng/drivers/ide/ide-taskfile.c
===
--- 

Re: [PATCH 2.6.11-rc3 00/08] ide: taskfile cleanup

2005-03-04 Thread Tejun Heo
 Oh, all the patches are against ide-dev-t + 9 recent patches +
ide_dma_intr fix.

--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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-rc3 04/08] ide: remove unused fields ide_drive_t-rq and ide_task_t-special

2005-03-04 Thread Tejun Heo

04_ide_remove_unused_fields.patch

Remove unused fields ide_drive_t-rq and ide_task_t-special

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 drivers/ide/ide-tape.c |1 -
 include/linux/ide.h|2 --
 2 files changed, 3 deletions(-)

Index: linux-taskfile-ng/drivers/ide/ide-tape.c
===
--- linux-taskfile-ng.orig/drivers/ide/ide-tape.c   2005-03-05 
10:37:51.567375213 +0900
+++ linux-taskfile-ng/drivers/ide/ide-tape.c2005-03-05 10:46:59.482894810 
+0900
@@ -1733,7 +1733,6 @@ static int idetape_end_request(ide_drive
}
ide_end_drive_cmd(drive, 0, 0);
 // blkdev_dequeue_request(rq);
-// drive-rq = NULL;
 // end_that_request_last(rq);
 
if (remove_stage)
Index: linux-taskfile-ng/include/linux/ide.h
===
--- linux-taskfile-ng.orig/include/linux/ide.h  2005-03-05 10:46:59.095955301 
+0900
+++ linux-taskfile-ng/include/linux/ide.h   2005-03-05 10:46:59.483894654 
+0900
@@ -660,7 +660,6 @@ typedef struct ide_drive_s {
 
request_queue_t *queue; /* request queue */
 
-   struct request  *rq;/* current request */
struct ide_drive_s  *next;  /* circular list of hwgroup drives */
struct ide_driver_s *driver;/* (ide_driver_t *) */
void*driver_data;   /* extra driver data */
@@ -934,7 +933,6 @@ typedef struct ide_task_s {
ide_pre_handler_t   *prehandler;
ide_handler_t   *handler;
struct request  *rq;/* copy of request */
-   void*special;   /* valid_t generally */
 } ide_task_t;
 
 typedef struct hwgroup_s {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH/RFC] I/O-check interface for driver's error handling

2005-03-04 Thread Benjamin Herrenschmidt
On Fri, 2005-03-04 at 14:54 +0100, Pavel Machek wrote:
 Hi!
 
   If there's no -error method, at leat call -remove so one device only
   takes itself down.
  
   Does this make sense?
  
  This was my thought too last time we had this discussion.  A completely 
  asynchronous call is probably needed in addition to Hidetoshi's proposed 
  API, 
  since as you point out, the driver may not be running when an error occurs 
  (e.g. in the case of a DMA error or more general bus problem).  The async
 
 Hmm, before we go async way (nasty locking, no?) could driver simply
 ask did something bad happen while I was sleeping? at begining of each
 function?
 
 For DMA problems, driver probably has its own, timer-based,
 something is wrong timer, anyway, no?

No, there is no nasty locking, when the callback happens, pretty much
all IOs have stopped anyway due to errors, and we aren't on a critical
code path.

Polling for error might be possible, but async notification is the way
to go because whatever does error management need to be able to
separately: 

 - notify all drivers on the affected bus segment
 - one the above is done, and based on system/driver capabilities (API
to be defined) eventually re-enable IO access and do a new round of
notifications
 - based on system/driver capabilities, eventually reset the slot and
notify drivers to re-initialize themselves.

Ben.


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


Re: 2.6.11-mm1

2005-03-04 Thread Andrew Morton
Alexander Nyberg [EMAIL PROTECTED] wrote:

 fre 2005-03-04 klockan 03:32 -0800 skrev Andrew Morton:
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm1/
  
  
  - Added the new bk-audit tree.  Contains updates to the kernel's audit
feature.  Maintained by David Woodhouse.
  
  - The Dell keyboard problems should be fixed.  Testing needed.
  
  - Dmitry's bk-dtor-input tree is no longer active and has been dropped.
 
 Just booted up a box and tried to log onto ssh which didn't worked so I
 looked at kernel log and behold, 128MB box with no swap, had just
 booted. Couldn't get any access after this.
 A few kernel debugging options were chosen notably CONFIG_DEBUG_SLAB 
 CONFIG_DEBUG_PAGEALLOC

So you're saying that the box has run out of memory?

Please send me the .config then disable CONFIG_DEBUG_PAGEALLOC and retest,
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/


[RFQ] Rules for accepting patches into the linux-releases tree

2005-03-04 Thread Greg KH
Anything else anyone can think of?  Any objections to any of these?
I based them off of Linus's original list.

thanks,

greg k-h

--

Rules on what kind of patches are accepted, and what ones are not, into
the linux-release tree.

 - It can not bigger than 100 lines, with context.
 - It must fix only one thing.
 - It must fix a real bug that bothers people (not a, This could be a
   problem... type thing.)
 - It must fix a problem that causes a build error (but not for things
   marked CONFIG_BROKEN), an oops, a hang, or a real security issue.
 - No theoretical race condition issues, unless an explanation of how
   the race can be exploited.
 - It can not contain any trivial fixes in it (spelling changes,
   whitespace cleanups, etc.)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Andrew Morton
Richard Purdie [EMAIL PROTECTED] wrote:

 As an experiment I ran bitbake meta-sdk on my copy of openemedded. A while 
 later I have these in the deploy directory amongst other things.
 
 http://www.rpsys.net/openzaurus/arm-cross/binutils-cross-sdk-2.15.91.0.2-r5.tar.gz
  
 (3.8MB)
 http://www.rpsys.net/openzaurus/arm-cross/gcc-cross-sdk-3.4.2-r0.tar.gz 
 (17.5MB)

Bless you.  I just built an arm kernel!

That compiler is *fast*.  47 seconds.  Weird.

For reference, untar the above in / and use


#!/bin/sh
export ARCH=arm
export CROSS_COMPILE=arm-linux-
W=/usr/local/arm/oe/bin

MAKE=make

if [ -z $1 ]
then
WHAT=vmlinux
else
WHAT=$1
fi

nr_cpus=$(grep processor /proc/cpuinfo|wc -l)
j=$(expr $nr_cpus \* 3 / 2)

MAKE_ARGS=ARCH=$ARCH CROSS_COMPILE=$W/arm-linux-

if [ x$DISTCC_HOSTS != x ]
then
$MAKE -j 12 CC=ccache distcc --ccache-skip $W/$CROSS_COMPILEgcc 
$MAKE_ARGS $WHAT 2/tmp/log
else
$MAKE -j $j $MAKE_ARGS CC=$W/$CROSS_COMPILEgcc $WHAT 2/tmp/log
fi
cat /tmp/log


That's now eight architectures I'll compile-test mm kernels on.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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

2005-03-04 Thread Dave Jones
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote:

  wrt the nfsd patches, Neil said:
  
  The problem they fix is that currently:
  Client A holds a lock
  Client B tries to get the lock and blocks
  Client A drops the lock
**Client B doesn't get the lock immediately, but has to wait for a
 timeout. (several seconds)

Sounds like a performance thing than oh my god the world is falling apart
type thing.  Given it recovers after a few seconds, is it worth it ?

Dave

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


Re: Linux 2.6.11.1

2005-03-04 Thread Linus Torvalds


On Fri, 4 Mar 2005, Andrew Morton wrote:
  
   Ok, care to forward them on?
 
 Sure.  How do they get to Linus?

I'll just pull from the sucker-tree. 

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/


<    4   5   6   7   8   9   10   >