Re: [ patch 3/7] drivers/serial/jsm: new serial device driver
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
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
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)
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
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
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
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
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
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 ?
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
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
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
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
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)
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?
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
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
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
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*
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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)
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)
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)
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
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
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
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)
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
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
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 ?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ?
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
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
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
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
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
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
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
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
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
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
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
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/