Re: [PATCH 2/2] rename thread_info to stack
> It is unpleasing that this code is forced to implicitly assume that the > thing pointed to by task_struct.stack has type `struct thread_info'. I can change that to typeof -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] 1-Wire ds2760 chip battery driver
This is driver for batteries with ds2760 chip inside, found inside
almost every HP iPaq and HTC PDAs/phones.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/power/Kconfig |7 +
drivers/power/Makefile |2 +
drivers/power/ds2760_battery.c | 520
include/linux/ds2760_battery.h | 32 +++
4 files changed, 561 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/ds2760_battery.c
create mode 100644 include/linux/ds2760_battery.h
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 791fa0c..9214562 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -28,4 +28,11 @@ config APM_POWER
Say Y here to enable support APM status emulation using
battery class devices.
+config BATTERY_DS2760
+ tristate "DS2760 battery driver (HP iPAQ & others)"
+ select W1
+ select W1_SLAVE_DS2760
+ help
+ Say Y here to enable support for batteries with ds2760 chip.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index a8fbc7e..492df05 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -16,3 +16,5 @@ obj-$(CONFIG_POWER_SUPPLY) += power_supply.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
+
+obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
diff --git a/drivers/power/ds2760_battery.c b/drivers/power/ds2760_battery.c
new file mode 100644
index 000..86c562c
--- /dev/null
+++ b/drivers/power/ds2760_battery.c
@@ -0,0 +1,520 @@
+/*
+ * Driver for batteries with DS2760 chips inside.
+ *
+ * Copyright (c) 2007 Anton Vorontsov
+ * 2004-2007 Matt Reimer
+ * 2004 Szabolcs Gyurko
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ * Author: Anton Vorontsov <[EMAIL PROTECTED]>
+ * February 2007
+ *
+ * Matt Reimer <[EMAIL PROTECTED]>
+ * April 2004, 2005, 2007
+ *
+ * Szabolcs Gyurko <[EMAIL PROTECTED]>
+ * September 2004
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../w1/w1.h"
+#include "../w1/slaves/w1_ds2760.h"
+
+struct ds2760_device_info {
+ struct power_supply_info *bi;
+ struct device *dev;
+
+ /* DS2760 data, valid after calling ds2760_battery_read_status() */
+ unsigned long update_time; /* jiffies when data read */
+ char raw[DS2760_DATA_SIZE]; /* raw DS2760 data */
+ int voltage_raw;/* units of 4.88 mV */
+ int voltage_uV; /* units of uV */
+ int current_raw;/* units of 0.625 mA */
+ int current_uA; /* units of uA */
+ int accum_current_raw; /* units of 0.25 mAh */
+ int accum_current_uAh; /* units of uAh */
+ int temp_raw; /* units of 0.125 C */
+ int temp_C; /* units of 0.1 C */
+ int rated_capacity; /* units of uAh */
+ int rem_capacity; /* percentage */
+ int full_active_uAh;/* units of uAh */
+ int empty_uAh; /* units of uAh */
+ int life_sec; /* units of seconds */
+ int charge_status; /* POWER_SUPPLY_STATUS_* */
+
+ int full_counter;
+ struct power_supply bat;
+ struct device *w1_dev;
+ struct workqueue_struct *monitor_wqueue;
+ struct delayed_work monitor_work;
+};
+
+static unsigned int cache_time = 1000;
+module_param(cache_time, uint, 0644);
+MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
+
+/* Some batteries have their rated capacity stored a N * 10 mAh, while
+ * others use an index into this table. */
+static int rated_capacities[] = {
+ 0,
+ 920,/* Samsung */
+ 920,/* BYD */
+ 920,/* Lishen */
+ 920,/* NEC */
+ 1440, /* Samsung */
+ 1440, /* BYD */
+ 1440, /* Lishen */
+ 1440, /* NEC */
+ 2880, /* Samsung */
+ 2880, /* BYD */
+ 2880, /* Lishen */
+ 2880/* NEC */
+};
+
+/* array is level at temps 0C, 10C, 20C, 30C, 40C
+ * temp is in Celsius */
+static int battery_interpolate(int array[], int temp)
+{
+ int index, dt;
+
+ if (temp <= 0)
+ return array[0];
+ if (temp >= 40)
+ return array[4];
+
+ index = temp / 10;
+ dt= temp % 10;
+
+ return array[index] + (((array[index + 1] - array[index]) * dt) / 10);
+}
+
+static int ds2760_battery_read_status(struct ds2760_device_info *di)
+{
+ int ret, i, start, count, scale[5];
+
+ if (di->update_time && time_before(jiffies, di->update_time +
+
[PATCH 8/8] One Laptop Per Child power/battery driver
This probably should be marked as BROKEN because, according
to David Woodhouse, EC-acccess method will change. Plus currently
it lacks mutexes. So this driver is just for reference. Converted
from the battery-2.6 repository, 1:1.
But nevertheless it should work.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/power/Kconfig|6 +
drivers/power/Makefile |1 +
drivers/power/olpc_battery.c | 300 ++
3 files changed, 307 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/olpc_battery.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 051724f..3ac79c3 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -42,4 +42,10 @@ config BATTERY_PMU
Say Y here to expose battery information on Apple machines
through the generic battery class.
+config BATTERY_OLPC
+ tristate "One Laptop Per Child battery"
+ depends on X86_32
+ help
+ Say Y to enable support for the battery on the $100 laptop.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 0ebdc6d..62b58ca 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_APM_POWER)+= apm_power.o
obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
+obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
new file mode 100644
index 000..40f76bb
--- /dev/null
+++ b/drivers/power/olpc_battery.c
@@ -0,0 +1,300 @@
+/*
+ * Battery driver for One Laptop Per Child ($100 laptop) board.
+ *
+ * Copyright б╘ 2006 David Woodhouse <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define wBAT_VOLTAGE 0xf900 /* *9.76/32,mV */
+#define wBAT_CURRENT 0xf902 /* *15.625/120, mA */
+#define wBAT_TEMP0xf906 /* *256/1000, б╟C */
+#define wAMB_TEMP0xf908 /* *256/1000, б╟C */
+#define SOC 0xf910 /* percentage*/
+#define sMBAT_STATUS 0xfaa4
+#definesBAT_PRESENT 1
+#definesBAT_FULL 2
+#definesBAT_DESTROY 4 /* what is this exactly? */
+#definesBAT_LOW 32
+#definesBAT_DISCHG 64
+#define sMCHARGE_STATUS 0xfaa5
+#definesBAT_CHARGE 1
+#definesBAT_OVERTEMP 4
+#definesBAT_NiMH 8
+#define sPOWER_FLAG 0xfa40
+#defineADAPTER_IN1
+
+/*
+ * EC locking and access
+ */
+
+static int lock_ec(void)
+{
+ unsigned long timeo = jiffies + HZ / 20;
+
+ while (1) {
+ unsigned char lock = inb(0x6c) & 0x80;
+ if (!lock)
+ return 0;
+ if (time_after(jiffies, timeo)) {
+ printk(KERN_ERR "olpc_battery: failed to lock EC for "
+ "battery access\n");
+ return 1;
+ }
+ yield();
+ }
+}
+
+static void unlock_ec(void)
+{
+ outb(0xff, 0x6c);
+ return;
+}
+
+static unsigned char read_ec_byte(unsigned short adr)
+{
+ outb(adr >> 8, 0x381);
+ outb(adr, 0x382);
+ return inb(0x383);
+}
+
+static unsigned short read_ec_word(unsigned short adr)
+{
+ return (read_ec_byte(adr) << 8) | read_ec_byte(adr + 1);
+}
+
+/*
+ * Power
+ */
+
+static int olpc_ac_get_prop(struct power_supply *psy,
+enum power_supply_property psp,
+union power_supply_propval *val)
+{
+ int ret = 0;
+
+ if (lock_ec())
+ return -EIO;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ if (!(read_ec_byte(sMBAT_STATUS) & sBAT_PRESENT)) {
+ ret = -ENODEV;
+ goto out;
+ }
+ val->intval = !!(read_ec_byte(sPOWER_FLAG) & ADAPTER_IN);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+out:
+ unlock_ec();
+ return ret;
+}
+
+static enum power_supply_property olpc_ac_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static struct power_supply olpc_ac = {
+ .name = "olpc-ac",
+ .type = POWER_SUPPLY_TYPE_AC,
+ .properties = olpc_ac_props,
+ .num_properties =
[PATCH 4/8] pda power driver
Common power driver for PDAs and phones with one or two external
power supplies (AC/USB) connected to main and backup batteries,
and optional builtin charger.
It's used to stop logic duplication through different embedded
devices. So, power supply *logic* is here. pda_power register
power supplies, and will take care about notifying batteries
about power changes through external power interface.
AC/USB power consumption issues should be handled by platform
code, inside set_charge function.
Signed-off-by: Roman Moravcik <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/power/Kconfig |7 ++
drivers/power/Makefile|2 +
drivers/power/pda_power.c | 256 +
include/linux/pda_power.h | 28 +
4 files changed, 293 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/pda_power.c
create mode 100644 include/linux/pda_power.h
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 7811fa6..cc70644 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -14,4 +14,11 @@ config POWER_SUPPLY_DEBUG
Say Y here to enable debugging messages for power supply class
and drivers.
+config PDA_POWER
+ tristate "Generic PDA/phone power driver"
+ help
+ Say Y here to enable generic power driver for PDAs and phones with
+ one or two external power supplies (AC/USB) connected to main and
+ backup batteries, and optional builtin charger.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 95085ba..1808b69 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -13,3 +13,5 @@ EXTRA_CFLAGS += -DDEBUG
endif
obj-$(CONFIG_POWER_SUPPLY) += power_supply.o
+
+obj-$(CONFIG_PDA_POWER)+= pda_power.o
diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
new file mode 100644
index 000..a36936e
--- /dev/null
+++ b/drivers/power/pda_power.c
@@ -0,0 +1,256 @@
+/*
+ * Common power driver for PDAs and phones with one or two external
+ * power supplies (AC/USB) connected to main and backup batteries,
+ * and optional builtin charger.
+ *
+ * Copyright 2007 Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static inline unsigned int get_irq_flags(struct resource *res)
+{
+ unsigned int flags = IRQF_DISABLED | IRQF_SHARED;
+
+ flags |= res->flags & IRQF_TRIGGER_MASK;
+
+ return flags;
+}
+
+static struct device *dev;
+static struct pda_power_pdata *pdata;
+static struct resource *ac_irq, *usb_irq;
+static struct timer_list charger_timer;
+static struct timer_list supply_timer;
+
+static int pda_power_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ if (psy->type == POWER_SUPPLY_TYPE_AC)
+ val->intval = pdata->is_ac_online ?
+ pdata->is_ac_online() : 0;
+ else
+ val->intval = pdata->is_usb_online ?
+ pdata->is_usb_online() : 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static enum power_supply_property pda_power_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static char *pda_power_supplied_to[] = {
+ "main-battery",
+ "backup-battery",
+};
+
+static struct power_supply pda_power_supplies[] = {
+ {
+ .name = "ac",
+ .type = POWER_SUPPLY_TYPE_AC,
+ .supplied_to = pda_power_supplied_to,
+ .num_supplicants = ARRAY_SIZE(pda_power_supplied_to),
+ .properties = pda_power_props,
+ .num_properties = ARRAY_SIZE(pda_power_props),
+ .get_property = pda_power_get_property,
+ },
+ {
+ .name = "usb",
+ .type = POWER_SUPPLY_TYPE_USB,
+ .supplied_to = pda_power_supplied_to,
+ .num_supplicants = ARRAY_SIZE(pda_power_supplied_to),
+ .properties = pda_power_props,
+ .num_properties = ARRAY_SIZE(pda_power_props),
+ .get_property = pda_power_get_property,
+ },
+};
+
+static void update_charger(void)
+{
+ if (!pdata->set_charge)
+ return;
+
+ if (pdata->is_ac_online && pdata->is_ac_online()) {
+ dev_dbg(dev, "charger on (AC)\n");
+ pdata->set_charge(PDA_POWER_CHARGE_AC);
+ }
+ else if (pdata->is_usb_online &&
[PATCH 5/8] APM emulation driver for class batteries
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/power/Kconfig |7 ++
drivers/power/Makefile|1 +
drivers/power/apm_power.c | 249 +
3 files changed, 257 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/apm_power.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index cc70644..791fa0c 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -21,4 +21,11 @@ config PDA_POWER
one or two external power supplies (AC/USB) connected to main and
backup batteries, and optional builtin charger.
+config APM_POWER
+ tristate "APM emulation for class batteries"
+ depends on APM_EMULATION
+ help
+ Say Y here to enable support APM status emulation using
+ battery class devices.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 1808b69..a8fbc7e 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -15,3 +15,4 @@ endif
obj-$(CONFIG_POWER_SUPPLY) += power_supply.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
+obj-$(CONFIG_APM_POWER)+= apm_power.o
diff --git a/drivers/power/apm_power.c b/drivers/power/apm_power.c
new file mode 100644
index 000..6a3a2f5
--- /dev/null
+++ b/drivers/power/apm_power.c
@@ -0,0 +1,249 @@
+/*
+ * Copyright (c) 2007 Anton Vorontsov <[EMAIL PROTECTED]>
+ * Copyright (c) 2007 Eugeny Boger <[EMAIL PROTECTED]>
+ *
+ * Author: Eugeny Boger <[EMAIL PROTECTED]>
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ */
+
+#include
+#include
+#include
+
+#ifdef current
+#undef current /* it expands to get_current() */
+#endif
+
+#define PSY_PROP(psy, prop, val) psy->get_property(psy, \
+ POWER_SUPPLY_PROP_##prop, val)
+
+#define _MPSY_PROP(prop, val) main_battery->get_property(main_battery, \
+ prop, val)
+
+#define MPSY_PROP(prop, val) _MPSY_PROP(POWER_SUPPLY_PROP_##prop, val)
+
+static struct power_supply *main_battery;
+
+static void find_main_battery(void)
+{
+ struct device *dev;
+ struct power_supply *bat, *batm;
+ union power_supply_propval full;
+ int max_charge = 0;
+
+ main_battery = NULL;
+ batm = NULL;
+ list_for_each_entry(dev, _supply_class->devices, node) {
+ bat = dev_get_drvdata(dev);
+ /* If none of battery devices cantains 'use_for_apm' flag,
+ choice one with maximum design charge */
+ if (!PSY_PROP(bat, CHARGE_FULL_DESIGN, )) {
+ if (full.intval > max_charge) {
+ batm = bat;
+ max_charge = full.intval;
+ }
+ }
+
+ if (bat->use_for_apm)
+ main_battery = bat;
+ }
+ if (!main_battery)
+ main_battery = batm;
+
+ return;
+}
+
+static int calculate_time(int status)
+{
+ union power_supply_propval charge_full, charge_empty;
+ union power_supply_propval charge, current;
+
+ if (MPSY_PROP(CHARGE_FULL, _full)) {
+ /* if battery can't report this property, use design value */
+ if (MPSY_PROP(CHARGE_FULL_DESIGN, _full))
+ return -1;
+ }
+
+ if (MPSY_PROP(CHARGE_EMPTY, _empty)) {
+ /* if battery can't report this property, use design value */
+ if (MPSY_PROP(CHARGE_EMPTY_DESIGN, _empty))
+ charge_empty.intval = 0;
+ }
+
+ if (MPSY_PROP(CHARGE_AVG, )) {
+ /* if battery can't report average value, use momentary */
+ if (MPSY_PROP(CHARGE_NOW, ))
+ return -1;
+ }
+
+ if (MPSY_PROP(CURRENT_AVG, )) {
+ /* if battery can't report average value, use momentary */
+ if (MPSY_PROP(CURRENT_NOW, ))
+ return -1;
+ }
+
+ if (status == POWER_SUPPLY_STATUS_CHARGING)
+ return ((charge.intval - charge_full.intval) * 60L) /
+ current.intval;
+ else
+ return -((charge.intval - charge_empty.intval) * 60L) /
+ current.intval;
+}
+
+static int calculate_capacity(int using_charge)
+{
+ enum power_supply_property full_prop, empty_prop;
+ enum power_supply_property full_design_prop, empty_design_prop;
+ enum power_supply_property now_prop, avg_prop;
+ union power_supply_propval empty, full, cur;
+ int ret;
+
+ if (using_charge) {
+ full_prop = POWER_SUPPLY_PROP_CHARGE_FULL;
+ empty_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
+ full_design_prop = POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN;
+
[PATCH 7/8] Apple PMU driver
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/power/Kconfig |7 ++
drivers/power/Makefile |1 +
drivers/power/pmu_battery.c | 215 +++
3 files changed, 223 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/pmu_battery.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 9214562..051724f 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -35,4 +35,11 @@ config BATTERY_DS2760
help
Say Y here to enable support for batteries with ds2760 chip.
+config BATTERY_PMU
+ tristate "Apple PMU battery"
+ depends on ADB_PMU
+ help
+ Say Y here to expose battery information on Apple machines
+ through the generic battery class.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 492df05..0ebdc6d 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
+obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
diff --git a/drivers/power/pmu_battery.c b/drivers/power/pmu_battery.c
new file mode 100644
index 000..d52e302
--- /dev/null
+++ b/drivers/power/pmu_battery.c
@@ -0,0 +1,215 @@
+/*
+ * Battery class driver for Apple PMU
+ *
+ * Copyright б╘ 2006 David Woodhouse <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct pmu_battery_dev {
+ struct power_supply bat;
+ struct pmu_battery_info *pbi;
+ char name[16];
+ int propval;
+} *pbats[PMU_MAX_BATTERIES];
+
+#define to_pmu_battery_dev(x) container_of(x, struct pmu_battery_dev, bat)
+
+/*
+ * Power
+ */
+
+static int pmu_get_ac_prop(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = (!!(pmu_power_flags & PMU_PWR_AC_PRESENT)) ||
+ (pmu_battery_count == 0);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static enum power_supply_property pmu_ac_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static struct power_supply pmu_ac = {
+ .name = "pmu-ac",
+ .type = POWER_SUPPLY_TYPE_AC,
+ .properties = pmu_ac_props,
+ .num_properties = ARRAY_SIZE(pmu_ac_props),
+ .get_property = pmu_get_ac_prop,
+};
+
+/*
+ * Battery properties
+ */
+
+static char *pmu_batt_types[] = {
+ "Smart", "Comet", "Hooper", "Unknown"
+};
+
+static char *pmu_bat_get_model_name(struct pmu_battery_info *pbi)
+{
+ switch (pbi->flags & PMU_BATT_TYPE_MASK) {
+ case PMU_BATT_TYPE_SMART:
+ return pmu_batt_types[0];
+ case PMU_BATT_TYPE_COMET:
+ return pmu_batt_types[1];
+ case PMU_BATT_TYPE_HOOPER:
+ return pmu_batt_types[2];
+ default: break;
+ }
+ return pmu_batt_types[3];
+}
+
+static int pmu_bat_get_property(struct power_supply *psy,
+enum power_supply_property psp,
+union power_supply_propval *val)
+{
+ struct pmu_battery_dev *pbat = to_pmu_battery_dev(psy);
+ struct pmu_battery_info *pbi = pbat->pbi;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_STATUS:
+ if (pbi->flags & PMU_BATT_CHARGING)
+ val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ else
+ val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = !!(pbi->flags & PMU_BATT_PRESENT);
+ break;
+ case POWER_SUPPLY_PROP_MODEL_NAME:
+ val->strval = pmu_bat_get_model_name(pbi);
+ break;
+ case POWER_SUPPLY_PROP_ENERGY_AVG:
+ val->intval = pbi->charge * 1000; /* mWh -> б╣Wh */
+ break;
+ case POWER_SUPPLY_PROP_ENERGY_FULL:
+ val->intval = pbi->max_charge * 1000; /* mWh -> б╣Wh */
+ break;
+ case POWER_SUPPLY_PROP_CURRENT_AVG:
+ val->intval = pbi->amperage * 1000; /* mA -> б╣A */
+ break;
+ case
[PATCH 3/8] Universal power supply class (was: battery class)
This class is result of "external power" and "battery" classes merge, as suggested by David Woodhouse. He also implemented uevent support. Here how userspace seeing it now: # ls /sys/class/power\ supply/ ac main-battery usb # cat /sys/class/power\ supply/ ac/ main-battery/ usb/ # cat /sys/class/power\ supply/ac/type AC # cat /sys/class/power\ supply/usb/type USB # cat /sys/class/power\ supply/main-battery/type Battery # cat /sys/class/power\ supply/ac/online 1 # cat /sys/class/power\ supply/usb/online 0 # cat /sys/class/power\ supply/main-battery/status Charging # cat /sys/class/leds/h5400\:red-left/trigger none h5400-radio timer hwtimer ac-online usb-online main-battery-charging-or-full [main-battery-charging] main-battery-full Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- Documentation/power_supply_class.txt | 167 ++ drivers/Kconfig |2 + drivers/Makefile |1 + drivers/power/Kconfig| 17 +++ drivers/power/Makefile | 15 ++ drivers/power/power_supply.h | 42 ++ drivers/power/power_supply_core.c| 168 ++ drivers/power/power_supply_leds.c| 176 +++ drivers/power/power_supply_sysfs.c | 254 ++ include/linux/power_supply.h | 169 ++ 10 files changed, 1011 insertions(+), 0 deletions(-) create mode 100644 Documentation/power_supply_class.txt create mode 100644 drivers/power/Kconfig create mode 100644 drivers/power/Makefile create mode 100644 drivers/power/power_supply.h create mode 100644 drivers/power/power_supply_core.c create mode 100644 drivers/power/power_supply_leds.c create mode 100644 drivers/power/power_supply_sysfs.c create mode 100644 include/linux/power_supply.h diff --git a/Documentation/power_supply_class.txt b/Documentation/power_supply_class.txt new file mode 100644 index 000..666941f --- /dev/null +++ b/Documentation/power_supply_class.txt @@ -0,0 +1,167 @@ +Linux power supply class + + +Synopsis + +Power supply class used to represent battery, UPS, AC or DC power supply +properties to user-space. + +It defines core set of attributes, which should be applicable to (almost) +every power supply out there. Attributes are available via sysfs and uevent +interfaces. + +Each attribute has well defined meaning, up to unit of measure used. While +the attributes provided are believed to be universally applicable to any +power supply, specific monitoring hardware may not be able to provide them +all, so any of them may be skipped. + +Power supply class is extensible, and allows to define drivers own attributes. +The core attribute set is subject to the standard Linux evolution (i.e. +if it will be found that some attribute is applicable to many power supply +types or their drivers, it can be added to the core set). + +It also integrates with LED framework, for the purpose of providing +typically expected feedback of battery charging/fully charged status and +AC/USB power supply online status. (Note that specific details of the +indication (including whether to use it at all) are fully controllable by +user and/or specific machine defaults, per design principles of LED +framework). + + +Attributes/properties +~ +Power supply class has predefined set of attributes, this eliminates code +duplication across drivers. Power supply class insist on reusing its +predefined attributes *and* their units. + +So, userspace gets predictable set of attributes and their units for any +kind of power supply, and can process/present them to a user in consistent +manner. Results for different power supplies and machines are also directly +comparable. + +See drivers/power/ds2760_battery.c and drivers/power/pda_power.c for the +example how to declare and handle attributes. + + +Units +~ +Quoting include/linux/power_supply.h: + + All voltages, currents, charges, energies, time and temperatures in uV, + uA, uAh, uWh, seconds and tenths of degree Celsius unless otherwise + stated. It's driver's job to convert its raw values to units in which + this class operates. + + +Attributes/properties detailed +~~ + +~ ~ ~ ~ ~ ~ ~ Charge/Energy/Capacity - how to not confuse ~ ~ ~ ~ ~ ~ ~ +~ ~ +~ Because both "charge" (uAh) and "energy" (uWh) represents "capacity" ~ +~ of battery, this class distinguish these terms. Don't mix them! ~ +~ ~ +~ CHARGE_* attributes represents capacity in uAh only. ~ +~ ENERGY_*
[PATCH 1/8] remove "#if 0" from find_bus function, export it.
This function were placed in "#if 0" because nobody was using it.
We using it now.
See http://lwn.net/Articles/210610/
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/base/bus.c |5 ++---
include/linux/device.h |2 ++
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 253868e..971efa2 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -667,14 +667,13 @@ void put_bus(struct bus_type * bus)
*
* Note that kset_find_obj increments bus' reference count.
*/
-#if 0
+
struct bus_type * find_bus(char * name)
{
struct kobject * k = kset_find_obj(_subsys.kset, name);
return k ? to_bus(k) : NULL;
}
-#endif /* 0 */
-
+EXPORT_SYMBOL_GPL(find_bus);
/**
* bus_add_attrs - Add default attributes for this bus.
diff --git a/include/linux/device.h b/include/linux/device.h
index 5cf30e9..4015b39 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -68,6 +68,8 @@ extern void bus_unregister(struct bus_type * bus);
extern int __must_check bus_rescan_devices(struct bus_type * bus);
+extern struct bus_type *find_bus(char *name);
+
/* iterator helpers for buses */
int bus_for_each_dev(struct bus_type * bus, struct device * start, void * data,
--
1.5.1.1-dirty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] ds2760 W1 slave
This is W1 slave for ds2760 chip, found inside almost every HP iPaq and
HTC PDAs/phones.
Acked-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/w1/slaves/Kconfig | 13
drivers/w1/slaves/Makefile|1 +
drivers/w1/slaves/w1_ds2760.c | 125 +
drivers/w1/slaves/w1_ds2760.h | 50
drivers/w1/w1_family.h|1 +
5 files changed, 190 insertions(+), 0 deletions(-)
create mode 100644 drivers/w1/slaves/w1_ds2760.c
create mode 100644 drivers/w1/slaves/w1_ds2760.h
diff --git a/drivers/w1/slaves/Kconfig b/drivers/w1/slaves/Kconfig
index 904e5ae..df95d6c 100644
--- a/drivers/w1/slaves/Kconfig
+++ b/drivers/w1/slaves/Kconfig
@@ -35,4 +35,17 @@ config W1_SLAVE_DS2433_CRC
Each block has 30 bytes of data and a two byte CRC16.
Full block writes are only allowed if the CRC is valid.
+config W1_SLAVE_DS2760
+ tristate "Dallas 2760 battery monitor chip (HP iPAQ & others)"
+ depends on W1
+ help
+ If you enable this you will have the DS2760 battery monitor
+ chip support.
+
+ The battery monitor chip is used in many batteries/devices
+ as the one who is responsible for charging/discharging/monitoring
+ Li+ batteries.
+
+ If you are unsure, say N.
+
endmenu
diff --git a/drivers/w1/slaves/Makefile b/drivers/w1/slaves/Makefile
index 725dcfd..a8eb752 100644
--- a/drivers/w1/slaves/Makefile
+++ b/drivers/w1/slaves/Makefile
@@ -5,4 +5,5 @@
obj-$(CONFIG_W1_SLAVE_THERM) += w1_therm.o
obj-$(CONFIG_W1_SLAVE_SMEM)+= w1_smem.o
obj-$(CONFIG_W1_SLAVE_DS2433) += w1_ds2433.o
+obj-$(CONFIG_W1_SLAVE_DS2760) += w1_ds2760.o
diff --git a/drivers/w1/slaves/w1_ds2760.c b/drivers/w1/slaves/w1_ds2760.c
new file mode 100644
index 000..5a340d1
--- /dev/null
+++ b/drivers/w1/slaves/w1_ds2760.c
@@ -0,0 +1,125 @@
+/*
+ * 1-Wire implementation for the ds2760 chip
+ *
+ * Copyright (c) 2004-2005, Szabolcs Gyurko <[EMAIL PROTECTED]>
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include "../w1.h"
+#include "../w1_int.h"
+#include "../w1_family.h"
+#include "w1_ds2760.h"
+
+static int w1_ds2760_io(struct device *dev, char *buf, int addr, size_t count,
+int io)
+{
+ struct w1_slave *sl = container_of(dev, struct w1_slave, dev);
+
+ if (!dev)
+ return 0;
+
+ mutex_lock(>master->mutex);
+
+ if (addr > DS2760_DATA_SIZE || addr < 0) {
+ count = 0;
+ goto out;
+ }
+ if (addr + count > DS2760_DATA_SIZE)
+ count = DS2760_DATA_SIZE - addr;
+
+ if (!w1_reset_select_slave(sl)) {
+ if (!io) {
+ w1_write_8(sl->master, W1_DS2760_READ_DATA);
+ w1_write_8(sl->master, addr);
+ count = w1_read_block(sl->master, buf, count);
+ } else {
+ w1_write_8(sl->master, W1_DS2760_WRITE_DATA);
+ w1_write_8(sl->master, addr);
+ w1_write_block(sl->master, buf, count);
+ /* XXX w1_write_block returns void, not n_written */
+ }
+ }
+
+out:
+ mutex_unlock(>master->mutex);
+
+ return count;
+}
+
+int w1_ds2760_read(struct device *dev, char *buf, int addr, size_t count)
+{
+ return w1_ds2760_io(dev, buf, addr, count, 0);
+}
+
+int w1_ds2760_write(struct device *dev, char *buf, int addr, size_t count)
+{
+ return w1_ds2760_io(dev, buf, addr, count, 1);
+}
+
+static ssize_t w1_ds2760_read_bin(struct kobject *kobj, char *buf, loff_t off,
+ size_t count)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ return w1_ds2760_read(dev, buf, off, count);
+}
+
+static struct bin_attribute w1_ds2760_bin_attr = {
+ .attr = {
+ .name = "w1_slave",
+ .mode = S_IRUGO,
+ .owner = THIS_MODULE,
+ },
+ .size = DS2760_DATA_SIZE,
+ .read = w1_ds2760_read_bin,
+};
+
+static int w1_ds2760_add_slave(struct w1_slave *sl)
+{
+ return sysfs_create_bin_file(>dev.kobj, _ds2760_bin_attr);
+}
+
+static void w1_ds2760_remove_slave(struct w1_slave *sl)
+{
+ sysfs_remove_bin_file(>dev.kobj, _ds2760_bin_attr);
+}
+
+static struct w1_family_ops w1_ds2760_fops = {
+ .add_slave= w1_ds2760_add_slave,
+ .remove_slave = w1_ds2760_remove_slave,
+};
+
+static struct w1_family w1_ds2760_family = {
+ .fid = W1_FAMILY_DS2760,
+ .fops = _ds2760_fops,
+};
+
+static int __init w1_ds2760_init(void)
+{
+ printk(KERN_INFO "1-Wire driver for the DS2760 battery monitor "
+ " chip - (c) 2004-2005, Szabolcs
Re: [PATCH 2/6] Create asm-i386/cmpxchg.h
On Wed, May 02, 2007 at 05:55:22PM +0200, Eric Dumazet wrote: > My guess is ff means firstfloor :) > > https://www.x86-64.org/pipermail/discuss/2006-January/007467.html Thanks! That makes much more sense than my funky German keyboard theory... Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: scheduling oddity on 2.6.20.3 stock
On Thu, 3 May 2007, David Schwartz wrote: I needed to recompress some files from .bz2 to .gz so I setup a script to do bunzip2 -c $file.bz2 |gzip -9 >$file.gz I expected that the two CPU heavy processes would end up on different cpu's and spend a little time shuffling data between the two cpu's on a system (dual core opteron) however, instead what I find is that each process is getting 50% of one cpu while the other cpu is 97% idle. That would only be possible if the compression/decompression block size is small compared to the maximum pipe buffer size. I suspect the reverse is the case. It would be interesting to write an intermediate process that basically enlarged the pipe buffers and see if that changed anything. Basically, the intermediate process would allocate a large buffer (16MB or so) and fill it from 'bunzip2' while draining it to 'gzip' in a non-blocking way (unless the buffer was full/empty, of course). hmm, how about bunzip2 -c $file.bz2 |dd bs=8m |gzip -9 >$file.gz should that work? David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] - SN: validate smp_affinity mask on intr redirect
I'll rework as per your suggestions.
Thanks,
John
>
> On Thu, 03 May 2007 07:56:02 -0500
> John Keller <[EMAIL PROTECTED]> wrote:
>
> > On SN, only allow one bit to be set in the smp_affinty mask
> > when redirecting an interrupt. Currently setting multiple
> > bits is allowed, but only the first bit is used in
> > determining the CPU to redirect to. This has caused confusion
> > among some customers.
> >
> > ...
> >
> > +
> > +int is_affinity_mask_valid(cpumask_t cpumask)
> > +{
> > + if (ia64_platform_is("sn2")) {
> > + /* Only allow one CPU to be specified in the smp_affinity mask
> > */
> > + if (cpus_weight(cpumask) != 1)
> > + return 0;
> > + }
> > + return 1;
> > +}
>
> A bool returning true or false would be appropriate, given this function's
> clearly-boolean name.
>
> > +#ifndef ARCH_HAS_IRQ_AFFINITY_VALIDATION
> > +#define is_irq_affinity_mask_valid(cpumask) 1
> > +#endif
>
> The ARCH_HAS_FOO things have never been popular. There are a couple of
> alternatives going around:
>
> a) use __attribute__((weak)) and provide a one-line default
>implementation in kernel/irq/proc.c. This has a small runtime cost.
>
> b) In include/asm-ia64/irq.h, do
>
>#define is_affinity_mask_valid is_affinity_mask_valid
>
>and in kernel/irq/proc.c do
>
>#ifndef is_affinity_mask_valid
>#define is_affinity_mask_valid() 1
>#endif
>
>This has minimal runtime cost, but is a bit tricksy.
>
>It has the advantage that it doesn't introduce some new identifier
>which needs to be maintained.
>
> > extern int irq_set_affinity(unsigned int irq, cpumask_t cpumask);
> > extern int irq_can_set_affinity(unsigned int irq);
> >
> > Index: linux-2.6/include/asm-ia64/irq.h
> > ===
> > --- linux-2.6.orig/include/asm-ia64/irq.h 2007-05-01 15:47:01.660643076
> > -0500
> > +++ linux-2.6/include/asm-ia64/irq.h2007-05-01 15:48:42.729254805
> > -0500
> > @@ -11,6 +11,8 @@
> > * 02/29/00 D.Mosbergermoved most things into hw_irq.h
> > */
> >
> > +#include
> > +
>
> This is the sort of inclusion which tends to make things blow up. I trust
> this was carefully compile-tested.
>
> With a) above, the is_affinity_mask_valid() declaration would be in a
> different header. With b), no additional include will be needed.
>
> > #define NR_IRQS256
> > #define NR_IRQ_VECTORS NR_IRQS
> >
> > @@ -30,4 +32,7 @@ extern void disable_irq_nosync (unsigned
> > extern void enable_irq (unsigned int);
> > extern void set_irq_affinity_info (unsigned int irq, int dest, int redir);
> >
> > +#define ARCH_HAS_IRQ_AFFINITY_VALIDATION
> > +extern int is_affinity_mask_valid(cpumask_t cpumask);
> > +
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] rename thread_info to stack
On Tue, 1 May 2007 02:10:34 +0200 (CEST) Roman Zippel <[EMAIL PROTECTED]> wrote: > This finally renames the thread_info field in task structure to stack, > so that the assumptions about this field are gone and archs have more > freedom about placing the thread_info structure. It needed this build fix: --- a/include/asm-x86_64/system.h~rename-thread_info-to-stack-fix +++ a/include/asm-x86_64/system.h @@ -39,7 +39,7 @@ [threadrsp] "i" (offsetof(struct task_struct, thread.rsp)), \ [ti_flags] "i" (offsetof(struct thread_info, flags)),\ [tif_fork] "i" (TIF_FORK), \ - [thread_info] "i" (offsetof(struct task_struct, thread_info)), \ + [thread_info] "i" (offsetof(struct task_struct, stack)), \ [pda_pcurrent] "i" (offsetof(struct x8664_pda, pcurrent)) \ : "memory", "cc" __EXTRA_CLOBBER) _ It is unpleasing that this code is forced to implicitly assume that the thing pointed to by task_struct.stack has type `struct thread_info'. Are we sure this patch is a good thing? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22 -mm merge plans: slub on PowerPC
On Thu, 3 May 2007, Hugh Dickins wrote: > On Thu, 3 May 2007, Hugh Dickins wrote: > > > > Seems we're all wrong in thinking Christoph's Kconfiggery worked > > as intended: maybe it just works some of the time. I'm not going > > to hazard a guess as to how to fix it up, will resume looking at > > the powerpc's quicklist potential later. > > Here's the patch I've been testing on G5, with 4k and with 64k pages, > with SLAB and with SLUB. But, though it doesn't crash, the pgd > kmem_cache in the 4k-page SLUB case is revealing SLUB's propensity > for using highorder allocations where SLAB would stick to order 0: > under load, exec's mm_init gets page allocation failure on order 4 > - SLUB's calculate_order may need some retuning. (I'd expect it to > be going for order 3 actually, I'm not sure how order 4 comes about.) There are SLUB patches pending (not in rc7-mm2 as far as I can recall) that reduce the default page order sizes to head off this issue. The defaults were initially too large (and they still default to large for testing if Mel's Antifrag work is detected to be active). > - return kmem_cache_alloc(pgtable_cache[PTE_CACHE_NUM], > - GFP_KERNEL|__GFP_REPEAT); > + return quicklist_alloc(0, GFP_KERNEL|__GFP_REPEAT, NULL); __GFP_REPEAT is unusual here but this was carried over from the kmem_cache_alloc it seems. Hmm... There is some variance on how we do this between arches. Should we uniformly set or not set this flag? [EMAIL PROTECTED]:~/software/linux-2.6.21-rc7-mm2$ grep quicklist_alloc include/asm-ia64/* include/asm-ia64/pgalloc.h: return quicklist_alloc(0, GFP_KERNEL, NULL); include/asm-ia64/pgalloc.h: return quicklist_alloc(0, GFP_KERNEL, NULL); include/asm-ia64/pgalloc.h: return quicklist_alloc(0, GFP_KERNEL, NULL); include/asm-ia64/pgalloc.h: void *pg = quicklist_alloc(0, GFP_KERNEL, NULL); include/asm-ia64/pgalloc.h: return quicklist_alloc(0, GFP_KERNEL, NULL); [EMAIL PROTECTED]:~/software/linux-2.6.21-rc7-mm2$ grep quicklist_alloc arch/i386/mm/* arch/i386/mm/pgtable.c: pgd_t *pgd = quicklist_alloc(0, GFP_KERNEL, pgd_ctor); [EMAIL PROTECTED]:~/software/linux-2.6.21-rc7-mm2$ grep quicklist_alloc include/asm-sparc64/* include/asm-sparc64/pgalloc.h: return quicklist_alloc(0, GFP_KERNEL, NULL); include/asm-sparc64/pgalloc.h: return quicklist_alloc(0, GFP_KERNEL, NULL); include/asm-sparc64/pgalloc.h: return quicklist_alloc(0, GFP_KERNEL, NULL); include/asm-sparc64/pgalloc.h: void *pg = quicklist_alloc(0, GFP_KERNEL, NULL); [EMAIL PROTECTED]:~/software/linux-2.6.21-rc7-mm2$ grep quicklist_alloc include/asm-x86_64/* include/asm-x86_64/pgalloc.h: return (pmd_t *)quicklist_alloc(QUICK_PT, GFP_KERNEL|__GFP_REPEAT, NULL); include/asm-x86_64/pgalloc.h: return (pud_t *)quicklist_alloc(QUICK_PT, GFP_KERNEL|__GFP_REPEAT, NULL); include/asm-x86_64/pgalloc.h: pgd_t *pgd = (pgd_t *)quicklist_alloc(QUICK_PGD, include/asm-x86_64/pgalloc.h: return (pte_t *)quicklist_alloc(QUICK_PT, GFP_KERNEL|__GFP_REPEAT, NULL); include/asm-x86_64/pgalloc.h: void *p = (void *)quicklist_alloc(QUICK_PT, GFP_KERNEL|__GFP_REPEAT, NULL); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext3 vs NTFS performance
On Thu, May 03, 2007 at 01:44:14AM +1000, David Chinner wrote: > On Tue, May 01, 2007 at 01:43:18PM -0700, Cabot, Mason B wrote: > > Hello all, > > > > I've been testing the NAS performance of ext3/Openfiler 2.2 against > > NTFS/WinXP and have found that NTFS significantly outperforms ext3 for > > video workloads. The Windows CIFS client will attempt a poor-man's > > pre-allocation of the file on the server by sending 1-byte writes at > > 128K-byte strides, breaking block allocation on ext3 and leading to > > fragmentation and poor performance. This will happen for many > > applications (including iTunes) as the CIFS client issues these > > pre-allocates under the application layer. > > > > I've posted a brief paper on Intel's OSS website > > (http://softwarecommunity.intel.com/articles/eng/1259.htm). Please give > > it a read and let me know what you think. In particular, I'd like to > > arrive at the right place to fix this problem: is it in the filesystem, > > VFS, or Samba? > > As I commented on IRC to Val Henson - the XFS performance indicates > that it is not a VFS or Samba problem. In terms of what piece of code we can swap out and get good performance, the problem is indeed in ext3 - it's clear that the cause of the bad performance is the 1-byte writes resulting in ext3 fragmenting the on-disk layout of the file, and replacing it with XFS results in nice, clean, unfragmented files. But in terms of what we should do to fix it, there is the possibility of some debate. In general, I think there is a lot of code stuck down in individual file systems - especially in XFS - that could be usefully hoisted up to a higher level as generic helper functions. For example, we've got at least two implementations of reservations, one in XFS and one in ext3/4. At least some of the code could be generic - both file systems want to reserve long contiguous extents - with the actual mechanics of looking up and reserving free blocks implemented in per-fs code. I'd really like to see a generic VFS-level detection of read()/write()/creat()/mkdir()/etc. patterns which could detect things like "Oh, this file is likely to be deleted immediately, wait and see if it goes away and don't bother sending it on to the FS immediately" or "Looks like this file will grow pretty big, let's go pre-allocate some space for it." This is probably best done as a set of helper functions in the usual way. For this particular case, Ted is probably right and the only place we'll ever see this insane poor man's pre-allocate pattern is from the Windows CIFS client, in which case fixing this in Samba makes sense - although I'm a bit horrified by the idea of writing 128K of zeroes to pre-allocate... oh well, it's temporary, and what we care about here is the read performance, more than the write performance. -VAL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Remove apparently dead CONFIG_NO_ATA_LEGACY code.
On Thu, 3 May 2007 13:53:06 -0400 (EDT) "Robert P. J. Day" <[EMAIL PROTECTED]> wrote: > > Remove the single snippet of code conditional on the non-existent > CONFIG_NO_ATA_LEGACY Kconfig variable. > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> NAK This option is not dead and is relevant (although the platform using it may not have the relevant bits merged yet). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Routing 600+ vlan's via linux problems (looks like arp problems)
On 5/3/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: On May 3 2007 22:53, Willy Tarreau wrote: >> For the rest all we see in the arp cache is (incomplete) > >I suspect that your arp cache is full (128 entries by default). >Check /proc/sys/net/ipv4/neigh/gc_thresh1 (128 for me). You can >set it as high as gc_thresh2 (512 for me), and I don't know what >happens above. Above, you will perhaps need the not-so-elegant userspace arpd :-/ Yes, i was suspecting that the arp cache got full, but i will try increasing it :) Would there be any huge bugs if i change these lines in arp.c: .gc_thresh1 = 128, .gc_thresh2 = 512, to .gc_thresh1 = 700, .gc_thresh2 = 700, under the definition for struct arp_tbl? This setup will only run for about 1-2 hours while we fix the hardware router (it is running now, but only on a backup flash card solution. the harddrive in it died ;) I have been looking at arpd, but i quickly discarded it as an option since its marked both experimental and obsolete ;) regards Øyvind Vågen Jægtnes +47 96 22 03 08 [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: scheduling oddity on 2.6.20.3 stock
> I needed to recompress some files from .bz2 to .gz so I setup a script to > do > > bunzip2 -c $file.bz2 |gzip -9 >$file.gz > > I expected that the two CPU heavy processes would end up on different > cpu's and spend a little time shuffling data between the two cpu's on a > system (dual core opteron) > > however, instead what I find is that each process is getting 50% of one > cpu while the other cpu is 97% idle. That would only be possible if the compression/decompression block size is small compared to the maximum pipe buffer size. I suspect the reverse is the case. It would be interesting to write an intermediate process that basically enlarged the pipe buffers and see if that changed anything. Basically, the intermediate process would allocate a large buffer (16MB or so) and fill it from 'bunzip2' while draining it to 'gzip' in a non-blocking way (unless the buffer was full/empty, of course). DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Need help on block device error handling.
I've got a device driver for the Xilinx SystemACE CompactFlash interface that I'm working on and I'm having problems adding error handling and notification. Specifically, I need to deal with the case where the CF card might get pulled out by the user at any time without notice. While this situation will obviously result in data loss, I need to make sure that the system is able to recover gracefully (ie. the user will be ticked if it hangs or crashes. :) So, here are my questions. - When a new CF is inserted/removed, how should I notify the block/filesystem layer? - If the CF is removed mid-transfer, how do I abort all pending bios and block new requests? What is the impact on user space processes using the device, will they get signaled? AFAICT, I've got two options. One is to use the media_changed() and revalidate_disk() so the block layer can determine when things have changed. However, I cannot figure out how to force all activity to stop when the CF is removed while the device is still open. The other seems to be not call add_gendisk() until media is inserted, and then call del_gendisk() when it is removed, but I don't know if this is safe, and it still doesn't solve the problem of cancling pending transactions and forcing the block layer to close the device. Should I be using invalidate_partition() for this? Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/33] m68k: Atari keyboard and mouse support.
Hi, On Thu, 3 May 2007, Dmitry Torokhov wrote: > > I never said that. Many keyboard _types_ need a separate key mapping. > > Localization is a completely different problem (and could be solved via > > separate localization tables). > > Most of it can be solved in userspace and we wouldn't have to enumerate > > every possible single key the kernel never cares about in . > > > > I am not sure that solving it all in userspace is right solution. What userspace are you talking about? There is one main user - X, for it and all the rest you could provide a simple input library. > Consider a sleep button. It can be hooked up via ACPI, located on AT > keyboard, USB keyboard or even on a remote control or some userspace > daemon getting data from the network. If kernel just passes raw data > to userspace then userspace programs need to know all these potential > sources and handle them separately. But with unified input device > interface userspace program only needs to monotor appearance of new > event devices, latch onto them and wait for EV_KEY/KEY_SLEEP. And it > is not much burden for the kernel because kernel already interfaces > with all these devices. In fact there probably savings because kernel > uses single interface layer. If the kernel would do it properly, you would have a point... > > You still completely ignore the problem of how said application should > > properly support multiple keyboard mappings... > > > > I am afraid this statement is too vague, we need to discuss specific > scenarios... > > Consider this scenario: > > You use 2 PS/2 keyboards with your laptop - built-in and external one > on a separate serio port. Your built-in has media keys generating some > non-standard scancodes. The external one also has same media keys but > generating different set of keycodes. With unified input events you > can "fix" your keboards to generate same input events and the rest of > your stack does not care. That's not the problem. Your keycode mapping has no idea about alternative mappings. How does the application know that "Shift"+"2" may mean '"' or '@'? bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.22 -mm merge plans: slub on PowerPC
On Thu, 3 May 2007, Hugh Dickins wrote:
>
> Seems we're all wrong in thinking Christoph's Kconfiggery worked
> as intended: maybe it just works some of the time. I'm not going
> to hazard a guess as to how to fix it up, will resume looking at
> the powerpc's quicklist potential later.
Here's the patch I've been testing on G5, with 4k and with 64k pages,
with SLAB and with SLUB. But, though it doesn't crash, the pgd
kmem_cache in the 4k-page SLUB case is revealing SLUB's propensity
for using highorder allocations where SLAB would stick to order 0:
under load, exec's mm_init gets page allocation failure on order 4
- SLUB's calculate_order may need some retuning. (I'd expect it to
be going for order 3 actually, I'm not sure how order 4 comes about.)
I don't know how offensive Ben and Paulus may find this patch:
the kmem_cache use was nicely done and this messes it up a little.
The SLUB allocator relies on struct page fields first_page and slab,
overwritten by ptl when SPLIT_PTLOCK: so the SLUB allocator cannot then
be used for the lowest level of pagetable pages. This was obstructing
SLUB on PowerPC, which uses kmem_caches for its pagetables. So convert
its pte level to use quicklist pages (whereas pmd, pud and 64k-page pgd
want partpages, so continue to use kmem_caches for pmd, pud and pgd).
But to keep up appearances for pgtable_free, we still need PTE_CACHE_NUM.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig |4
arch/powerpc/mm/init_64.c | 17 ++---
include/asm-powerpc/pgalloc.h | 26 +++---
3 files changed, 21 insertions(+), 26 deletions(-)
--- 2.6.21-rc7-mm2/arch/powerpc/Kconfig 2007-04-26 13:33:51.0 +0100
+++ linux/arch/powerpc/Kconfig 2007-05-03 20:45:12.0 +0100
@@ -31,6 +31,10 @@ config MMU
bool
default y
+config QUICKLIST
+ bool
+ default y
+
config GENERIC_HARDIRQS
bool
default y
--- 2.6.21-rc7-mm2/arch/powerpc/mm/init_64.c2007-04-26 13:33:51.0
+0100
+++ linux/arch/powerpc/mm/init_64.c 2007-05-03 20:45:12.0 +0100
@@ -146,21 +146,16 @@ static void zero_ctor(void *addr, struct
memset(addr, 0, kmem_cache_size(cache));
}
-#ifdef CONFIG_PPC_64K_PAGES
-static const unsigned int pgtable_cache_size[3] = {
- PTE_TABLE_SIZE, PMD_TABLE_SIZE, PGD_TABLE_SIZE
-};
-static const char *pgtable_cache_name[ARRAY_SIZE(pgtable_cache_size)] = {
- "pte_pmd_cache", "pmd_cache", "pgd_cache",
-};
-#else
static const unsigned int pgtable_cache_size[2] = {
- PTE_TABLE_SIZE, PMD_TABLE_SIZE
+ PGD_TABLE_SIZE, PMD_TABLE_SIZE
};
static const char *pgtable_cache_name[ARRAY_SIZE(pgtable_cache_size)] = {
- "pgd_pte_cache", "pud_pmd_cache",
-};
+#ifdef CONFIG_PPC_64K_PAGES
+ "pgd_cache", "pmd_cache",
+#else
+ "pgd_cache", "pud_pmd_cache",
#endif /* CONFIG_PPC_64K_PAGES */
+};
#ifdef CONFIG_HUGETLB_PAGE
/* Hugepages need one extra cache, initialized in hugetlbpage.c. We
--- 2.6.21-rc7-mm2/include/asm-powerpc/pgalloc.h2007-02-04
18:44:54.0 +
+++ linux/include/asm-powerpc/pgalloc.h 2007-05-03 20:45:12.0 +0100
@@ -10,21 +10,15 @@
#include
#include
#include
+#include
extern struct kmem_cache *pgtable_cache[];
-#ifdef CONFIG_PPC_64K_PAGES
-#define PTE_CACHE_NUM 0
-#define PMD_CACHE_NUM 1
-#define PGD_CACHE_NUM 2
-#define HUGEPTE_CACHE_NUM 3
-#else
-#define PTE_CACHE_NUM 0
-#define PMD_CACHE_NUM 1
-#define PUD_CACHE_NUM 1
#define PGD_CACHE_NUM 0
+#define PUD_CACHE_NUM 1
+#define PMD_CACHE_NUM 1
#define HUGEPTE_CACHE_NUM 2
-#endif
+#define PTE_CACHE_NUM 3 /* from quicklist rather than kmem_cache */
/*
* This program is free software; you can redistribute it and/or
@@ -97,8 +91,7 @@ static inline void pmd_free(pmd_t *pmd)
static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm,
unsigned long address)
{
- return kmem_cache_alloc(pgtable_cache[PTE_CACHE_NUM],
- GFP_KERNEL|__GFP_REPEAT);
+ return quicklist_alloc(0, GFP_KERNEL|__GFP_REPEAT, NULL);
}
static inline struct page *pte_alloc_one(struct mm_struct *mm,
@@ -109,7 +102,7 @@ static inline struct page *pte_alloc_one
static inline void pte_free_kernel(pte_t *pte)
{
- kmem_cache_free(pgtable_cache[PTE_CACHE_NUM], pte);
+ quicklist_free(0, NULL, pte);
}
static inline void pte_free(struct page *ptepage)
@@ -136,7 +129,10 @@ static inline void pgtable_free(pgtable_
void *p = (void *)(pgf.val & ~PGF_CACHENUM_MASK);
int cachenum = pgf.val & PGF_CACHENUM_MASK;
- kmem_cache_free(pgtable_cache[cachenum], p);
+ if (cachenum == PTE_CACHE_NUM)
+ quicklist_free(0, NULL, p);
+ else
+ kmem_cache_free(pgtable_cache[cachenum], p);
}
extern void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf);
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Mauro Carvalho Chehab wrote: > Enough. Let's stop arguing non technical issues. > > If either one of you have any technical argue against the Trent's > patches, please point where the fix is wrong. Otherwise, if you wish, > you may send an acked-by agreeing with the fix. > Why don't you stop this childish behaviour ? After explaining to you the reasons in the previous mail: being the author and maintainer of dst/dst_ca and maintainer of dvb-bt8xx, i NACK this change (1) You aren't DVB maintainer I've seen that too often already, now we could point to a mail someone sent to Uwe regarding maintainership. You wouldn't be better at the moment, Mauro at least aknowlidges the work of others. I don't know what problems you have with Mauro I heard that there have been some mails between you and some other developers as well and the whole situation is just terrible. If you want to change the whole situation, think about what you can do for improving the whole situation even if it means that you have to work with people you don't like. (2) one shouldn't make such judgement calls on somebody else's driver unless it falls within your own maintainership I wrote what I'd like to see from you, it would be a start if you could work on that first. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH 35/36] Use menuconfig objects II - DVB
On May 3 2007 13:39, Trent Piepho wrote: > >> >The point rised by Trent is that, currently, this is not prepared to >> >handle the "menuconfig" and "if/endif" tags. > >BTW, I've now fixed this. > >Jan, have you looked at the effect these changes have when using xconfig, and >not just menuconfig? "The mouse is used to point at the xterm you want to type in." So, sorry, no, I did not. However, Stefan notes his experience with some earlier patches with [xg]config: http://lkml.org/lkml/2007/4/10/326 For you, I installed qt3-devel/libglade2-devel on my machine and ran it in [xg]config. >While your changes make menuconfig better, they have nearly opposite effect on >xconfig. > >xconfig has the menu tree display in the left panel, where one can see the >overall layout of the menu tree and jump directly to any menu (even one >multiple levels deep). All the menuconfigs that used to be menus don't show >up here anymore. That seems very much like a bug^Wmissing feature in [xg]config's "Split View". It does work in Single View and Tree View. >It looks like your changes are going in, so I suppose the solution is to >improve the way xconfig handles "menuconfig". >[...] >The reason is that a frontend would easily be able to understand the coupling >between the "menuconfig " and the "if ". It will make it easier for >the frontend to see that all the options are inside and controlled by the >enclosing menuconfig. It works a bit different than 'menu'. An object will be put into a menuconfig-menu IFF it has a depends on the menuconfig item. This is different from menu-menus, which have "sort of" an implicit "if/endif" block. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Routing 600+ vlan's via linux problems (looks like arp problems)
On Thu, May 03, 2007 at 10:53:41PM +0200, Willy Tarreau wrote: > On Thu, May 03, 2007 at 10:25:48PM +0200, Øyvind Vågen Jægtnes wrote: > > Hi, > > > > We have a one gigabit internet connection that is normally > > routed by a hardware juniper router. The drive in this is down > > and we need to use a linux machine (Pentium D 3 ghz) as a > > temporary router. > > Now setting up all the 600 vlans and assigning ip addresses > > is no problem. We have testet all by using a laptop, setting up > > 600 vlan interfaces on this and running dhcpclient on all. > > This worked just fine, all the interfaces got address. > > > > Now for the real setup. > > We closed the mac of the juniper to the network card that > > would be connected to the internal LAN, set up the interfaces, > > and swapped cables. This worked fine for approximately 100 > > of the computers that are connected, but the rest would not > > get IP. The connected 100 computers were routed just fine. > > > > What we think the problem is, is that the arp cache on the > > linux router seems strange. It can resolve the MAC for the > > 100 clients that actually got through. > > For the rest all we see in the arp cache is (incomplete) > > I suspect that your arp cache is full (128 entries by default). > Check /proc/sys/net/ipv4/neigh/gc_thresh1 (128 for me). You can ^ insert /default/ here. > set it as high as gc_thresh2 (512 for me), and I don't know what > happens above. Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Routing 600+ vlan's via linux problems (looks like arp problems)
On May 3 2007 22:53, Willy Tarreau wrote: >> For the rest all we see in the arp cache is (incomplete) > >I suspect that your arp cache is full (128 entries by default). >Check /proc/sys/net/ipv4/neigh/gc_thresh1 (128 for me). You can >set it as high as gc_thresh2 (512 for me), and I don't know what >happens above. Above, you will perhaps need the not-so-elegant userspace arpd :-/ Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Routing 600+ vlan's via linux problems (looks like arp problems)
On Thu, May 03, 2007 at 10:25:48PM +0200, Øyvind Vågen Jægtnes wrote: > Hi, Hi Øyvind. Forwarding your mail to netdev where the networking people are hanging out. Maybe they can help you. Sam > > We have a one gigabit internet connection that is normally > routed by a hardware juniper router. The drive in this is down > and we need to use a linux machine (Pentium D 3 ghz) as a > temporary router. > Now setting up all the 600 vlans and assigning ip addresses > is no problem. We have testet all by using a laptop, setting up > 600 vlan interfaces on this and running dhcpclient on all. > This worked just fine, all the interfaces got address. > > Now for the real setup. > We closed the mac of the juniper to the network card that > would be connected to the internal LAN, set up the interfaces, > and swapped cables. This worked fine for approximately 100 > of the computers that are connected, but the rest would not > get IP. The connected 100 computers were routed just fine. > > What we think the problem is, is that the arp cache on the > linux router seems strange. It can resolve the MAC for the > 100 clients that actually got through. > For the rest all we see in the arp cache is (incomplete) > > Here is some of the listing for arp -n: > 193.239.155.118 ether 00:0A:E4:59:75:66 C > eth1.1087 > 193.239.154.74 (incomplete) > eth1.1016 > 193.239.155.7ether 00:11:95:D2:3F:FD C > eth1.2002 > 83.143.114.222 (incomplete) > eth1.1305 > 83.143.113.246 ether 00:0B:5D:4B:B8:77 C > eth1.1247 > 83.143.116.126 (incomplete) > eth1.1409 > 83.143.118.114 (incomplete) > eth1.1534 > 193.239.154.210 ether 00:03:0D:2F:1B:7F C > eth1.1050 > 169.254.69.247 ether 00:15:C5:C2:31:6C C > eth1.1262 > 83.143.112.38(incomplete) > eth1.1131 > 83.143.118.18(incomplete) > eth1.1510 > 83.143.112.118 ether 00:11:95:CE:BF:72 C > eth1.1151 > 192.168.1.2 ether 00:0D:88:78:C0:00 C > eth1.2050 > 83.143.117.138 (incomplete) > eth1.1476 > 83.143.116.18(incomplete) > eth1.1382 > 83.143.118.26(incomplete) > eth1.1512 > 83.143.112.6 (incomplete) > eth1.1123 > 193.239.155.62 (incomplete) > eth1.1073 > > `arp -n|wc -l` returns around 350, which is the number of active ports on > the > edge switches... > this number is confirmed by snmp > > I have looked through the source for arp.c but i can't see any immediate > problems. There is no messages in dmesg, kern.log og messages (except for > eth1.vlanid up * 600). > > If anyone know what the problem can be, if this is a bug, or if PSBKC i > would > much appreciate it. > > regards > Øyvind Vågen Jægtnes > +47 96 22 03 08 > [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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Routing 600+ vlan's via linux problems (looks like arp problems)
On Thu, May 03, 2007 at 10:25:48PM +0200, Øyvind Vågen Jægtnes wrote: > Hi, > > We have a one gigabit internet connection that is normally > routed by a hardware juniper router. The drive in this is down > and we need to use a linux machine (Pentium D 3 ghz) as a > temporary router. > Now setting up all the 600 vlans and assigning ip addresses > is no problem. We have testet all by using a laptop, setting up > 600 vlan interfaces on this and running dhcpclient on all. > This worked just fine, all the interfaces got address. > > Now for the real setup. > We closed the mac of the juniper to the network card that > would be connected to the internal LAN, set up the interfaces, > and swapped cables. This worked fine for approximately 100 > of the computers that are connected, but the rest would not > get IP. The connected 100 computers were routed just fine. > > What we think the problem is, is that the arp cache on the > linux router seems strange. It can resolve the MAC for the > 100 clients that actually got through. > For the rest all we see in the arp cache is (incomplete) I suspect that your arp cache is full (128 entries by default). Check /proc/sys/net/ipv4/neigh/gc_thresh1 (128 for me). You can set it as high as gc_thresh2 (512 for me), and I don't know what happens above. Hoping this helps, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH 35/36] Use menuconfig objects II - DVB
Please include Roman Zippel when you propose kconfig changes. Sam > > Jan, have you looked at the effect these changes have when using xconfig, and > not just menuconfig? > > While your changes make menuconfig better, they have nearly opposite effect on > xconfig. > > xconfig has the menu tree display in the left panel, where one can see the > overall layout of the menu tree and jump directly to any menu (even one > multiple levels deep). All the menuconfigs that used to be menus don't show > up here anymore. > > To turn a menuconfig off, you must go to the top level menu containing the > menuconfig you want (and you must know which one that is!). Then you have to > drill down through each menu level one by one, by finding that menu in the top > panel (which also has all the config options listed) and clicking on it to get > to the next one. When you get to the menuconfig you want, you must enter it > and then you finally get the box to turn that menuconfig off. > > It looks like your changes are going in, so I suppose the solution is to > improve the way xconfig handles "menuconfig". > > I wonder, would it be possible to change the kconfig language so that: > menuconfig > boolean "name of menu" > > Did the same thing as: > config > boolean "name of menu" > menu "name of menu" > depends on > > This way you could change this: > > menuconfig > if > [all the other options] > endif > > Into this: > > menuconfig > [all the other options] > endmenu > > The reason is that a frontend would easily be able to understand the coupling > between the "menuconfig " and the "if ". It will make it easier for > the frontend to see that all the options are inside and controlled by the > enclosing menuconfig. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, VDR User <[EMAIL PROTECTED]> wrote: STOP FIGHTING ALL THE DAMN TIME! From an outsiders perspective there is a lot of unnecessary & childish behavior going on at the expense of good ideas and coding. It seems as though the Markus/Mauro team will go against anything Manu says simply because Manu is the one saying it. From what I've seen he is very knowledgeable and a good coder. From his technical knowledge he's as ok as many other developers are who have been involved for several years now. He tries to become the DVB Maintainer, from my side I wrote he first has to prove it for at least a half year that he supports the project and helps out people. Till now I haven't seen any response to the technical questions I had. And telling that the politicians here are so bad to everyone who'd like to help finding a solution for it is definitelly the wrong way either, so other people will not even be able to get an insight into the whole story. Manu is an asset and all the personal bickering and immature attitudes being displayed do not benefit any projects in any way. If you can't get past your personal problems then step down until you can learn to be unbiased and start treating these projects with some sanity/common sense. When you drive good people away, guess who loses? EVERYONE. Grow up and quit letting your personal feelings interfere in places it should not be in the first place!! Since all these issues have been there for more than one year now it either would be better that he leaves the project OR starts to seriously discuss the issues and how it would be best to solve them (and in a way where everyone agrees here) He just nacks the changes proposed by Uwe which got implemented by Trent and now Mauro wants to get it done somehow, either in a way explaining what he wants to do with it in future or changing these few lines NOW. I couldn't care less what will happen with his driver, the whole story gets blown up just because one party here doesn't understand that the other one doesn't know what he wants to do (and if he seriously will do something) I apologize for going off-topic but this is relevant to dvb dev as a whole. Things have degraded to a ridiculous state and it's time to knock it off. Enough is enough. The dvb projects should NOT have to suffer simply because people have lost the decency to act civil towards one another! Lastly, the opinions I'm sharing in this post are held by many others, although they hesitate to do the same publicly for certain reasons. I fully agree with that. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH 35/36] Use menuconfig objects II - DVB
> > The out of tree v4l-dvb build system uses the same Kconfig/Makefiles as it > does in the kernel. This part of the kernel build system is not easily > exported to out of tree modules, so we have some scripts to handle this. Can you elaborate of what was causing your troubles. Maybe kbuild/kconfig can be improved in this respect.. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] - SN: validate smp_affinity mask on intr redirect
On Thu, 03 May 2007 07:56:02 -0500
John Keller <[EMAIL PROTECTED]> wrote:
> On SN, only allow one bit to be set in the smp_affinty mask
> when redirecting an interrupt. Currently setting multiple
> bits is allowed, but only the first bit is used in
> determining the CPU to redirect to. This has caused confusion
> among some customers.
>
> ...
>
> +
> +int is_affinity_mask_valid(cpumask_t cpumask)
> +{
> + if (ia64_platform_is("sn2")) {
> + /* Only allow one CPU to be specified in the smp_affinity mask
> */
> + if (cpus_weight(cpumask) != 1)
> + return 0;
> + }
> + return 1;
> +}
A bool returning true or false would be appropriate, given this function's
clearly-boolean name.
> +#ifndef ARCH_HAS_IRQ_AFFINITY_VALIDATION
> +#define is_irq_affinity_mask_valid(cpumask) 1
> +#endif
The ARCH_HAS_FOO things have never been popular. There are a couple of
alternatives going around:
a) use __attribute__((weak)) and provide a one-line default
implementation in kernel/irq/proc.c. This has a small runtime cost.
b) In include/asm-ia64/irq.h, do
#define is_affinity_mask_valid is_affinity_mask_valid
and in kernel/irq/proc.c do
#ifndef is_affinity_mask_valid
#define is_affinity_mask_valid() 1
#endif
This has minimal runtime cost, but is a bit tricksy.
It has the advantage that it doesn't introduce some new identifier
which needs to be maintained.
> extern int irq_set_affinity(unsigned int irq, cpumask_t cpumask);
> extern int irq_can_set_affinity(unsigned int irq);
>
> Index: linux-2.6/include/asm-ia64/irq.h
> ===
> --- linux-2.6.orig/include/asm-ia64/irq.h 2007-05-01 15:47:01.660643076
> -0500
> +++ linux-2.6/include/asm-ia64/irq.h 2007-05-01 15:48:42.729254805 -0500
> @@ -11,6 +11,8 @@
> * 02/29/00 D.Mosberger moved most things into hw_irq.h
> */
>
> +#include
> +
This is the sort of inclusion which tends to make things blow up. I trust
this was carefully compile-tested.
With a) above, the is_affinity_mask_valid() declaration would be in a
different header. With b), no additional include will be needed.
> #define NR_IRQS 256
> #define NR_IRQ_VECTORS NR_IRQS
>
> @@ -30,4 +32,7 @@ extern void disable_irq_nosync (unsigned
> extern void enable_irq (unsigned int);
> extern void set_irq_affinity_info (unsigned int irq, int dest, int redir);
>
> +#define ARCH_HAS_IRQ_AFFINITY_VALIDATION
> +extern int is_affinity_mask_valid(cpumask_t cpumask);
> +
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] make cancel_rearming_delayed_work() reliable
Thanks to Jarek Poplawski for the ideas and for spotting the bug in the
initial draft patch.
cancel_rearming_delayed_work() currently has many limitations, because it
requires that dwork always re-arms itself via queue_delayed_work(). So it
hangs forever if dwork doesn't do this, or cancel_rearming_delayed_work/
cancel_delayed_work was already called. It uses flush_workqueue() in a loop,
so it can't be used if workqueue was freezed, and it is potentially live-
lockable on busy system if delay is small.
With this patch cancel_rearming_delayed_work() doesn't make any assumptions
about dwork, it can re-arm itself via queue_delayed_work(), or queue_work(),
or do nothing.
As a "side effect", cancel_work_sync() was changed to handle re-arming works
as well.
Disadvantages:
- this patch adds wmb() to insert_work().
- slowdowns the fast path (when del_timer() succeeds on entry) of
cancel_rearming_delayed_work(), because wait_on_work() is called
unconditionally. In that case, compared to the old version, we are
doing "unneeded" lock/unlock for each online CPU.
On the other hand, this means we don't need to use cancel_work_sync()
after cancel_rearming_delayed_work().
- complicates the code (.text grows by 130 bytes).
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- OLD/kernel/workqueue.c~1_CRDW 2007-05-02 23:29:07.0 +0400
+++ OLD/kernel/workqueue.c 2007-05-03 22:42:29.0 +0400
@@ -120,6 +120,11 @@ static void insert_work(struct cpu_workq
struct work_struct *work, int tail)
{
set_wq_data(work, cwq);
+ /*
+* Ensure that we get the right work->data if we see the
+* result of list_add() below, see try_to_grab_pending().
+*/
+ smp_wmb();
if (tail)
list_add_tail(>entry, >worklist);
else
@@ -381,7 +386,46 @@ void fastcall flush_workqueue(struct wor
}
EXPORT_SYMBOL_GPL(flush_workqueue);
-static void wait_on_work(struct cpu_workqueue_struct *cwq,
+/*
+ * Upon a successfull return, the caller "owns" WORK_STRUCT_PENDING bit,
+ * so this work can't be re-armed in any way.
+ */
+static int try_to_grab_pending(struct work_struct *work)
+{
+ struct cpu_workqueue_struct *cwq;
+ int ret = 0;
+
+ if (!test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work)))
+ return 1;
+
+ /*
+* The queueing is in progress, or it is already queued. Try to
+* steal it from ->worklist without clearing WORK_STRUCT_PENDING.
+*/
+
+ cwq = get_wq_data(work);
+ if (!cwq)
+ return ret;
+
+ spin_lock_irq(>lock);
+ if (!list_empty(>entry)) {
+ /*
+* This work is queued, but perhaps we locked the wrong cwq.
+* In that case we must see the new value after rmb(), see
+* insert_work()->wmb().
+*/
+ smp_rmb();
+ if (cwq == get_wq_data(work)) {
+ list_del_init(>entry);
+ ret = 1;
+ }
+ }
+ spin_unlock_irq(>lock);
+
+ return ret;
+}
+
+static void wait_on_cpu_work(struct cpu_workqueue_struct *cwq,
struct work_struct *work)
{
struct wq_barrier barr;
@@ -398,20 +442,7 @@ static void wait_on_work(struct cpu_work
wait_for_completion();
}
-/**
- * cancel_work_sync - block until a work_struct's callback has terminated
- * @work: the work which is to be flushed
- *
- * cancel_work_sync() will attempt to cancel the work if it is queued. If the
- * work's callback appears to be running, cancel_work_sync() will block until
- * it has completed.
- *
- * cancel_work_sync() is designed to be used when the caller is tearing down
- * data structures which the callback function operates upon. It is expected
- * that, prior to calling cancel_work_sync(), the caller has arranged for the
- * work to not be requeued.
- */
-void cancel_work_sync(struct work_struct *work)
+static void wait_on_work(struct work_struct *work)
{
struct cpu_workqueue_struct *cwq;
struct workqueue_struct *wq;
@@ -421,29 +452,59 @@ void cancel_work_sync(struct work_struct
might_sleep();
cwq = get_wq_data(work);
- /* Was it ever queued ? */
if (!cwq)
return;
- /*
-* This work can't be re-queued, no need to re-check that
-* get_wq_data() is still the same when we take cwq->lock.
-*/
- spin_lock_irq(>lock);
- list_del_init(>entry);
- work_clear_pending(work);
- spin_unlock_irq(>lock);
-
wq = cwq->wq;
cpu_map = wq_cpu_map(wq);
for_each_cpu_mask(cpu, *cpu_map)
- wait_on_work(per_cpu_ptr(wq->cpu_wq, cpu), work);
+ wait_on_cpu_work(per_cpu_ptr(wq->cpu_wq, cpu), work);
+}
+
+/**
+ *
Re: [v4l-dvb-maintainer] [PATCH 35/36] Use menuconfig objects II - DVB
On Thu, 3 May 2007, Jan Engelhardt wrote: > On May 3 2007 09:37, Mauro Carvalho Chehab wrote: > >Trent is mentioning an out-of-tree building system to allow easier > >testing of V4L/DVB patches by end users and developers and during driver > >development time. The building system allows faster > >compilation/linkedition during driver development, by allowing you to > >use: > > make menuconfig/qconfig/xconfig > > > >inside the tree, unselecting the drivers that you're not working. > > Is that all? Because you can do Before I bore you to death with v4l-dvb stuff, I've written something about the "use menuconfig objects" patches at the end. No, it's much more than that. The v4l-dvb tree at linuxtv.org is significantly different than just a copy of linux/drivers/media. For one thing, the v4l-dvb tree will build on kernels between 2.6.12 and the latest git kernel. There still some support for pre 2.6 kernels too, but it's not maintained. This way we can ask people to download the latest hg (we use Mercurial) and test it, without also telling them to download and compile the latest kernel from git. The out of tree v4l-dvb build system uses the same Kconfig/Makefiles as it does in the kernel. This part of the kernel build system is not easily exported to out of tree modules, so we have some scripts to handle this. Some drivers won't work on older kernels, and we have a way to detecting this and modifying kconfig entries to disable the driver. If someone has ISA disabled in their kernel, or is lacking OSS header files, they can not use an ISA radio card driver or compile an OSS tvcard sound module. On the other hand, if someone has disabled DVB in their kernel, it's still possible to build and use the out of tree DVB drivers. There is a perl script that understands the kconfig language and deals with resolving kconfig dependencies (Rather than write a kconfig expression parser and evaluator, I wrote a kconfig expression to perl expression translator). We take care of needing to use the kernel autoconf.h file, yet wanting to override the options set in the out of tree v4l-dvb configuration. > >The point rised by Trent is that, currently, this is not prepared to > >handle the "menuconfig" and "if/endif" tags. BTW, I've now fixed this. Jan, have you looked at the effect these changes have when using xconfig, and not just menuconfig? While your changes make menuconfig better, they have nearly opposite effect on xconfig. xconfig has the menu tree display in the left panel, where one can see the overall layout of the menu tree and jump directly to any menu (even one multiple levels deep). All the menuconfigs that used to be menus don't show up here anymore. To turn a menuconfig off, you must go to the top level menu containing the menuconfig you want (and you must know which one that is!). Then you have to drill down through each menu level one by one, by finding that menu in the top panel (which also has all the config options listed) and clicking on it to get to the next one. When you get to the menuconfig you want, you must enter it and then you finally get the box to turn that menuconfig off. It looks like your changes are going in, so I suppose the solution is to improve the way xconfig handles "menuconfig". I wonder, would it be possible to change the kconfig language so that: menuconfig boolean "name of menu" Did the same thing as: config boolean "name of menu" menu "name of menu" depends on This way you could change this: menuconfig if [all the other options] endif Into this: menuconfig [all the other options] endmenu The reason is that a frontend would easily be able to understand the coupling between the "menuconfig " and the "if ". It will make it easier for the frontend to see that all the options are inside and controlled by the enclosing menuconfig. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add info about whitespace to SubmitChecklist
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> --- diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist index bd23dc0..6491b2c 100644 --- a/Documentation/SubmitChecklist +++ b/Documentation/SubmitChecklist @@ -80,3 +80,7 @@ kernel patches. 23: Tested after it has been merged into the -mm patchset to make sure that it still works with all of the other queued patches and various changes in the VM, VFS, and other subsystems. + +24: Avoid whitespace damage such as indenting with spaces or whitespace +at the end of lines. You can test this by feeding the patch to +"git apply --check --whitespace=error-all" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 -rt] wrong usage of smp_processor_id()
On Thu, 2007-05-03 at 16:31 -0400, Steven Rostedt wrote: > Daniel Walker wrote: > > >>> Index: linux-2.6.21/kernel/latency_trace.c > >>> === > >>> --- linux-2.6.21.orig/kernel/latency_trace.c > >>> +++ linux-2.6.21/kernel/latency_trace.c > >>> @@ -105,7 +105,7 @@ static inline int DEBUG_WARN_ON(int cond > >>> #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING > >>> # ifdef CONFIG_CRITICAL_PREEMPT_TIMING > >>> static DEFINE_PER_CPU(int, trace_cpu_idle); > >>> -# define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && > >>> preempt_count()) > >>> +# define irqs_off_preempt_count() (preempt_count() && > >>> !__get_cpu_var(trace_cpu_idle)) > >>> # else > >>> # define irqs_off_preempt_count() 0 > >>> # endif > > > > Isn't it a generic problem? It doesn't look specific to your change > > unless you made some changes to entry.S . > > > > See: http://lkml.org/lkml/2007/4/23/183 > Ahh, well safe bet I think. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Routing 600+ vlan's via linux problems (looks like arp problems)
On May 3 2007 22:25, Øyvind Vågen Jægtnes wrote: > > Now for the real setup. > We closed the mac of the juniper to the network card that > would be connected to the internal LAN, set up the interfaces, > and swapped cables. This worked fine for approximately 100 > of the computers that are connected, but the rest would not > get IP. The connected 100 computers were routed just fine. Try tcpdump. See if dhcpd actually hands out leases, and run another tcpdump on a dhcp client machine, to see if it even arrives. Furthermore, you could > 193.239.155.118 ether 00:0A:E4:59:75:66 C > eth1.1087 > 193.239.154.74 (incomplete) > eth1.1016 check if eth1.1016 even "works", by ping -bf 255.255.255.255 -I eth1.1016 if it lights up in the correct places, packets must be flowing. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 -rt] wrong usage of smp_processor_id()
Daniel Walker wrote: Index: linux-2.6.21/kernel/latency_trace.c === --- linux-2.6.21.orig/kernel/latency_trace.c +++ linux-2.6.21/kernel/latency_trace.c @@ -105,7 +105,7 @@ static inline int DEBUG_WARN_ON(int cond #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING # ifdef CONFIG_CRITICAL_PREEMPT_TIMING static DEFINE_PER_CPU(int, trace_cpu_idle); -# define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && preempt_count()) +# define irqs_off_preempt_count() (preempt_count() && !__get_cpu_var(trace_cpu_idle)) # else # define irqs_off_preempt_count() 0 # endif Isn't it a generic problem? It doesn't look specific to your change unless you made some changes to entry.S . See: http://lkml.org/lkml/2007/4/23/183 Specifically: #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING # ifdef CONFIG_CRITICAL_PREEMPT_TIMING -# define irqs_off_preempt_count() preempt_count() + static DEFINE_PER_CPU(int, trace_cpu_idle); +# define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && preempt_count()) # else # define irqs_off_preempt_count() 0 # endif @@ -2153,6 +2154,20 @@ void notrace unmask_preempt_count(unsign } EXPORT_SYMBOL(unmask_preempt_count); -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Strange soft lockup detected message
I have had this happen a few times recently and was wondering if anyone has an idea what could be going on: BUG: soft lockup detected on CPU#0! [] dump_stack+0x24/0x30 [] softlockup_tick+0x7e/0xc0 [] update_process_times+0x33/0x80 [] timer_interrupt+0x39/0x80 [] handle_IRQ_event+0x3d/0x70 [] __do_IRQ+0xa9/0x150 [] do_IRQ+0x25/0x60 [] common_interrupt+0x1a/0x20 [] pcnet32_dwio_read_csr+0xc/0x20 [pcnet32] [] pcnet32_interrupt+0x42/0x2b0 [pcnet32] [] handle_IRQ_event+0x3d/0x70 [] __do_IRQ+0xa9/0x150 [] do_IRQ+0x25/0x60 [] common_interrupt+0x1a/0x20 [] handle_IRQ_event+0x18/0x70 [] __do_IRQ+0xa9/0x150 [] do_IRQ+0x25/0x60 [] common_interrupt+0x1a/0x20 [<5791>] 0x5791 This is on a system running a Geode LX at 500MHz, using 2.6.18 based kernel (specifically a slightly modified debian 4.0 Etch kernel). I am really wondering where do I go looking for the cause of this. The same kernel running on a Geode SC1200 (GX1) does not appear to do this. If I knew what the error meant I would have a better idea how to debug it and fix it. -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] revoke: change revoke_table to fileset and revoke_details
On Thu, 3 May 2007, Andrew Morton wrote:
> > +/**
> > + * fileset - an array of file pointers.
> > + * @files:the array of file pointers
> > + * @nr: number of elements in the array
> > + * @end: index to next unused file pointer
> > + */
> > +struct fileset {
> > + struct file **files;
> > + unsigned long nr;
> > + unsigned long end;
> > +};
>
> What's the locking protocol for all this?
What do you mean? There is no concurrent access going on here.
On Thu, 3 May 2007, Andrew Morton wrote:
> > +static void free_fset(struct fileset *fset)
> > +{
> > + int i;
> > +
> > + for (i = fset->end; i < fset->nr; i++)
> > + fput(fset->files[i]);
> > +
> > + kfree(fset->files);
> > + kfree(fset);
> > +}
>
> Confused. Shouldn't it be
>
> for (i = 0; i < fset->end; i++)
No. The fset->end is an index to the first _unused_ file pointer. All
entries before that are in use by revoked file descriptors so we don't
want to fput() them.
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/33] m68k: Atari keyboard and mouse support.
On 5/3/07, Roman Zippel <[EMAIL PROTECTED]> wrote: Hi, On Thu, 3 May 2007, Dmitry Torokhov wrote: > > I explained already at a earlier occasion, why this "generic" keycode > > thing is broken by design, which makes connecting multiple keyboards with > > different mappings impossible. > > > > No, I don't think so. Your points were: > > 1) You did not want to adjust your legacy keymap on Amiga Adjusting wouldn't be really a problem, if it had some value... > 2) You want userspace programs to know how to program scancodes for > every type of keyboard and have different keymaps for different type > of keyboards (So you need to have n_kbd_types * > n_international_mappings keymaps). I never said that. Many keyboard _types_ need a separate key mapping. Localization is a completely different problem (and could be solved via separate localization tables). Most of it can be solved in userspace and we wouldn't have to enumerate every possible single key the kernel never cares about in . I am not sure that solving it all in userspace is right solution. Consider a sleep button. It can be hooked up via ACPI, located on AT keyboard, USB keyboard or even on a remote control or some userspace daemon getting data from the network. If kernel just passes raw data to userspace then userspace programs need to know all these potential sources and handle them separately. But with unified input device interface userspace program only needs to monotor appearance of new event devices, latch onto them and wait for EV_KEY/KEY_SLEEP. And it is not much burden for the kernel because kernel already interfaces with all these devices. In fact there probably savings because kernel uses single interface layer. > As far as 2) goes I think it is better to have unified keyboard map > across different types of keyboards and then overlay > internatinalization/other settings. And you still have per-keyboard > configurability as you can change scancode->keycode mapping on a > per-device basis via evdev ioctl. You still completely ignore the problem of how said application should properly support multiple keyboard mappings... I am afraid this statement is too vague, we need to discuss specific scenarios... Consider this scenario: You use 2 PS/2 keyboards with your laptop - built-in and external one on a separate serio port. Your built-in has media keys generating some non-standard scancodes. The external one also has same media keys but generating different set of keycodes. With unified input events you can "fix" your keboards to generate same input events and the rest of your stack does not care. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20.1] BUG: soft lockup detected on CPU#1!
On 03/05/07, Folkert van Heusden <[EMAIL PROTECTED]> wrote: My P4 with HT and 2GB of ram on an IDE disk succeeded in triggering another bug: [273187.872796] usb 7-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 161 rq 1 len 10 ret -110 [273902.586320] BUG: soft lockup detected on CPU#1! [273902.586385] [] show_trace_log_lvl+0x1a/0x30 [273902.586472] [] show_trace+0x12/0x14 [273902.586557] [] dump_stack+0x16/0x18 [273902.586636] [] softlockup_tick+0xa6/0xc2 [273902.586724] [] run_local_timers+0x12/0x14 [273902.586810] [] update_process_times+0x72/0xa1 [273902.586893] [] tick_sched_timer+0x53/0xb6 [273902.586977] [] hrtimer_interrupt+0x16b/0x1c2 [273902.587062] [] local_apic_timer_interrupt+0x55/0x5b [273902.587147] [] smp_apic_timer_interrupt+0x2a/0x39 [273902.587230] [] apic_timer_interrupt+0x33/0x38 [273902.587312] [] cpu_idle+0x6b/0x85 [273902.587393] [] start_secondary+0xe8/0x30a [273902.587476] [<>] 0x0 [273902.587568] === [277740.475464] usb 7-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 161 rq 1 len 10 ret -110 ... [285799.322391] usb 7-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 161 rq 1 len 10 ret -110 [286630.885843] BUG: soft lockup detected on CPU#1! [286630.885901] [] show_trace_log_lvl+0x1a/0x30 [286630.885988] [] show_trace+0x12/0x14 [286630.886071] [] dump_stack+0x16/0x18 [286630.886152] [] softlockup_tick+0xa6/0xc2 [286630.886235] [] run_local_timers+0x12/0x14 [286630.886323] [] update_process_times+0x72/0xa1 [286630.886406] [] tick_sched_timer+0x53/0xb6 [286630.886488] [] hrtimer_interrupt+0x16b/0x1c2 [286630.886571] [] local_apic_timer_interrupt+0x55/0x5b [286630.886657] [] smp_apic_timer_interrupt+0x2a/0x39 [286630.886741] [] apic_timer_interrupt+0x33/0x38 [286630.886824] [] cpu_idle+0x6b/0x85 [286630.886907] [] start_secondary+0xe8/0x30a [286630.886991] [<>] 0x0 [286630.887088] === [290177.972351] usb 7-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 161 rq 1 len 10 ret -110 My .config can be found here: http://keetweej.vanheusden.com/~folkert/config-2.6.21.1 Folkert van Heusden Thomas, this looks very similar to http://lkml.org/lkml/2007/5/2/511 Already on list of known regressions. Regards, Michal -- Michal K. K. Piotrowski Kernel Monkeys (http://kernel.wikidot.com/start) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Routing 600+ vlan's via linux problems (looks like arp problems)
Hi, We have a one gigabit internet connection that is normally routed by a hardware juniper router. The drive in this is down and we need to use a linux machine (Pentium D 3 ghz) as a temporary router. Now setting up all the 600 vlans and assigning ip addresses is no problem. We have testet all by using a laptop, setting up 600 vlan interfaces on this and running dhcpclient on all. This worked just fine, all the interfaces got address. Now for the real setup. We closed the mac of the juniper to the network card that would be connected to the internal LAN, set up the interfaces, and swapped cables. This worked fine for approximately 100 of the computers that are connected, but the rest would not get IP. The connected 100 computers were routed just fine. What we think the problem is, is that the arp cache on the linux router seems strange. It can resolve the MAC for the 100 clients that actually got through. For the rest all we see in the arp cache is (incomplete) Here is some of the listing for arp -n: 193.239.155.118 ether 00:0A:E4:59:75:66 C eth1.1087 193.239.154.74 (incomplete) eth1.1016 193.239.155.7ether 00:11:95:D2:3F:FD C eth1.2002 83.143.114.222 (incomplete) eth1.1305 83.143.113.246 ether 00:0B:5D:4B:B8:77 C eth1.1247 83.143.116.126 (incomplete) eth1.1409 83.143.118.114 (incomplete) eth1.1534 193.239.154.210 ether 00:03:0D:2F:1B:7F C eth1.1050 169.254.69.247 ether 00:15:C5:C2:31:6C C eth1.1262 83.143.112.38(incomplete) eth1.1131 83.143.118.18(incomplete) eth1.1510 83.143.112.118 ether 00:11:95:CE:BF:72 C eth1.1151 192.168.1.2 ether 00:0D:88:78:C0:00 C eth1.2050 83.143.117.138 (incomplete) eth1.1476 83.143.116.18(incomplete) eth1.1382 83.143.118.26(incomplete) eth1.1512 83.143.112.6 (incomplete) eth1.1123 193.239.155.62 (incomplete) eth1.1073 `arp -n|wc -l` returns around 350, which is the number of active ports on the edge switches... this number is confirmed by snmp I have looked through the source for arp.c but i can't see any immediate problems. There is no messages in dmesg, kern.log og messages (except for eth1.vlanid up * 600). If anyone know what the problem can be, if this is a bug, or if PSBKC i would much appreciate it. regards Øyvind Vågen Jægtnes +47 96 22 03 08 [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/2] revoke: change revoke_table to fileset and revoke_details
On Thu, 3 May 2007 17:53:07 +0300 (EEST)
Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> The revoke_table struct is overloaded because it serves two purposes:
> it manages the pre-allocated set of files and tracks the revoke
> operation so that we know where to start restore if the operation
> fails. This splits file set management to separate struct fileset and
> renames struct revoke_table to revoke_details.
>
> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
> ---
> fs/revoke.c | 171
> +++-
> 1 file changed, 101 insertions(+), 70 deletions(-)
>
> Index: 26-mm/fs/revoke.c
> ===
> --- 26-mm.orig/fs/revoke.c2007-05-03 17:10:56.0 +0300
> +++ 26-mm/fs/revoke.c 2007-05-03 17:14:49.0 +0300
> @@ -18,19 +18,71 @@ * Copyright (C) 2006-2007 Pekka Enberg
> #include
> #include
>
> -/*
> - * This is used for pre-allocating an array of file pointers so that we don't
> - * have to do memory allocation under tasklist_lock.
> +/**
> + * fileset - an array of file pointers.
> + * @files:the array of file pointers
> + * @nr: number of elements in the array
> + * @end: index to next unused file pointer
> + */
> +struct fileset {
> + struct file **files;
> + unsigned long nr;
> + unsigned long end;
> +};
What's the locking protocol for all this?
> +static void free_fset(struct fileset *fset)
> +{
> + int i;
> +
> + for (i = fset->end; i < fset->nr; i++)
> + fput(fset->files[i]);
> +
> + kfree(fset->files);
> + kfree(fset);
> +}
Confused. Shouldn't it be
for (i = 0; i < fset->end; i++)
?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -rt] wrong usage of smp_processor_id()
On Thu, 2007-05-03 at 16:12 -0400, Steven Rostedt wrote: > Daniel Walker wrote: > > > --- > > kernel/latency_trace.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Index: linux-2.6.21/kernel/latency_trace.c > > === > > --- linux-2.6.21.orig/kernel/latency_trace.c > > +++ linux-2.6.21/kernel/latency_trace.c > > @@ -105,7 +105,7 @@ static inline int DEBUG_WARN_ON(int cond > > #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING > > # ifdef CONFIG_CRITICAL_PREEMPT_TIMING > > static DEFINE_PER_CPU(int, trace_cpu_idle); > > -# define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && > > preempt_count()) > > +# define irqs_off_preempt_count() (preempt_count() && > > !__get_cpu_var(trace_cpu_idle)) > > # else > > # define irqs_off_preempt_count() 0 > > # endif > > Ingo, > > This is on top of one of my patches that I sent you (the cpu idle one). > So it's not for the 2.6.21-rt1, but if you apply my patch, this needs to > be added too. Isn't it a generic problem? It doesn't look specific to your change unless you made some changes to entry.S . Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parallel port problems with 2.6.21_rc5 and 2.6.21_rc6_git3-20070410174235
On Wed, 11 Apr 2007 20:40:23 +0200 Markus Koßmann wrote: > When using either the unpatched 2.6.21_rc5 or SUSEs patched > 2.6.21_rc6_git3-20070410174235 on a SUSE-10.2 x86_64 system the parallel port > doesn't work right. If I "cat some_asciifile >/dev/lp0" the output on my > Epson Stylus Color 880 is unreadable. "cat /dev/zero >/dev/lp0" creates > random characters on the paper. Printing using cups also doesn't work any > more. > Switching back to SUSEs 2.6.18.8-0.1 kernel fixes the problem. > Any Ideas, what might be broken here ? Nope, but I have the same problem. I'll dig into it some day, but it's not very high priority for me. I haven't tested it lately. Do you still see this problem? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: console font limits
On May 3 2007 13:15, H. Peter Anvin wrote: >Jan Engelhardt wrote: >> >>> Put people didn't like that, and disabled text output when the console >>> is in KD_GRAPHICS mode... >> >> at the cost of not getting the kernel oops, heh. > >I thought the reason we didn't display text in KD_GRAPHICS mode was that >KD_GRAPHICS might mean "in a completely different mode that only >userspace knows about." Hrm. Maybe we need a distinction into KD_KGRAPHICS and KD_UGRAPHICS then. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: console font limits
Jan Engelhardt wrote: > >> Put people didn't like that, and disabled text output when the console >> is in KD_GRAPHICS mode... > > at the cost of not getting the kernel oops, heh. > I thought the reason we didn't display text in KD_GRAPHICS mode was that KD_GRAPHICS might mean "in a completely different mode that only userspace knows about." -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 -rt] wrong usage of smp_processor_id()
Daniel Walker wrote: --- kernel/latency_trace.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.21/kernel/latency_trace.c === --- linux-2.6.21.orig/kernel/latency_trace.c +++ linux-2.6.21/kernel/latency_trace.c @@ -105,7 +105,7 @@ static inline int DEBUG_WARN_ON(int cond #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING # ifdef CONFIG_CRITICAL_PREEMPT_TIMING static DEFINE_PER_CPU(int, trace_cpu_idle); -# define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && preempt_count()) +# define irqs_off_preempt_count() (preempt_count() && !__get_cpu_var(trace_cpu_idle)) # else # define irqs_off_preempt_count() 0 # endif Ingo, This is on top of one of my patches that I sent you (the cpu idle one). So it's not for the 2.6.21-rt1, but if you apply my patch, this needs to be added too. Acked-by: Steven Rostedt <[EMAIL PROTECTED]> -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21 1/3] x86_64: EFI64 support
On Thu, 03 May 2007 12:20:30 -0700 chandramouli narayanan wrote: > Randy Dunlap wrote: > > Can you share EFI code as much as possible among ia64, i386, > > and x86_64 instead of duplicating it? > Hi Randy, > > Based on the feedback from Andi and you, these are the areas: > > 1. conversion of EFI memory map to e820 map > 2. Consolidation/sharing of efi code among the architectures. > 3. Coding style violations/typos/clarity in comments. > > First I apologize for the coding style violations where I should have > done better. I will fix these in the next patch. > > I would like to address the above in stages with patch updates. This > will take me some time with the fixes and testing. > > A while back, Edgar Hucek submitted a patch (probably 2.6.18 mm tree?) > for efi to e820 memory mapping for i386.I don't see this code in the > 2.6.21 release which makes me wonder whether it was accepted and the > history behind it. Any pointers in this regard? I guess that Edgar stopped pushing it. Sometimes persistence is required. Linus said that the patch "looks fine per se", http://marc.info/?l=linux-kernel=115380564326171=2 but needs more testers. Presumably you have done more testing. :) --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] [NETLINK]: Fix use after free in netlink_recvmsg
From: Marcel Holtmann <[EMAIL PROTECTED]> Date: Thu, 03 May 2007 14:27:16 +0200 > Hi Dave, > > > > When the user passes in MSG_TRUNC the skb is used after getting freed. > > > > > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> > > > Signed-off-by: David Howells <[EMAIL PROTECTED]> > > > > Ugh, good catch, applied :-) > > it seems this could be easily exploited and is at least a local DoS. It > should be a candidate for the -stable kernel. The MSG_TRUNC change is in 2.6.22 GIT only. You might want to check such things before making such statements. :-/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MTD - Linux Nand Driver problems
Hi, Im using Linux Kernel 2.6.18. Im using a large nand page device. In my device nand starts from 0x8 offset of nand. My kernel is around 1MB, I have allocated 2 MB space in my mtd partition structure. Similarly My Filesystem starts from 0x28 offset of nand. MY erase block size is 0x2 (128 KB) mkfs.jffs2 -p -l --eraseblock=128KiB -n -v -r ./rootfs -o /tmp/rootfs.jffs2 When boot my system i get hundreds of messages like: Empty flash at 0x02327ffc ends at 0x02328000 Empty flash at 0x0232fffc ends at 0x0233 Empty flash at 0x02337ffc ends at 0x02338000 Empty flash at 0x02347ffc ends at 0x02348000 Empty flash at 0x0234fffc ends at 0x0235 Empty flash at 0x02357ffc ends at 0x02358000 Empty flash at 0x02367ffc ends at 0x02368000 Empty flash at 0x0236fffc ends at 0x0237 Empty flash at 0x02377ffc ends at 0x02378000 Empty flash at 0x0238fffc ends at 0x0239 Empty flash at 0x023a7ffc ends at 0x023a8000 Empty flash at 0x023cfffc ends at 0x023d Empty flash at 0x023f7ffc ends at 0x023f8000 Empty flash at 0x02407ffc ends at 0x02408000 Empty flash at 0x02417ffc ends at 0x02418000 Empty flash at 0x0242fffc ends at 0x0243 Empty flash at 0x02447ffc ends at 0x02448000 Empty flash at 0x02477ffc ends at 0x02478000 Empty flash at 0x024a7ffc ends at 0x024a8000 Empty flash at 0x02527ffc ends at 0x02528000 Empty flash at 0x0252ffac ends at 0x0253 Empty flash at 0x02531abc ends at 0x02532000 I know the flash is empty - How does one prevent these messages at boot time. Regards, Jo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 -rt] wrong usage of smp_processor_id()
Found this while debugging with Steve .. trace_hardirqs_on() isn't always called with interrupt off. BUG: using smp_processor_id() in preemptible [] code: init/1 caller is trace_hardirqs_on+0x16/0xe0 [] show_trace_log_lvl+0x21/0x50 [] show_trace+0x12/0x20 [] dump_stack+0x16/0x20 [] debug_smp_processor_id+0xa9/0xb0 [] trace_hardirqs_on+0x16/0xe0 [] do_notify_resume+0x115/0x7b0 [] work_notifysig+0x13/0x1b === --- | preempt count: 0001 ] | 1-level deep critical section nesting: .. [] debug_smp_processor_id+0x53/0xb0 .[] .. ( <= trace_hardirqs_on+0x16/0xe0) Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]> --- kernel/latency_trace.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.21/kernel/latency_trace.c === --- linux-2.6.21.orig/kernel/latency_trace.c +++ linux-2.6.21/kernel/latency_trace.c @@ -105,7 +105,7 @@ static inline int DEBUG_WARN_ON(int cond #ifdef CONFIG_CRITICAL_IRQSOFF_TIMING # ifdef CONFIG_CRITICAL_PREEMPT_TIMING static DEFINE_PER_CPU(int, trace_cpu_idle); -# define irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle) && preempt_count()) +# define irqs_off_preempt_count() (preempt_count() && !__get_cpu_var(trace_cpu_idle)) # else # define irqs_off_preempt_count() 0 # endif -- -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] fix for async scsi scan sysfs problem (resend)
I doubt it's in the fc transport - it's doing what it always did, which has nothing to do with coherency of the sdev's. We're seeing like problems, and it looks like it's related to the scan_mutex being held when some of the entry points are being called via the recent async scan code (which also still has a bunch of issues around rmmod). We should be sending some patches shortly. -- james s James Bottomley wrote: On Mon, 2007-04-23 at 14:13 -0400, Josef Bacik wrote: Ok I have a new patch that I've built and tested on both my UP and SMP machine and it appears to work fine. I took the async check out of scsi_add_lun, I don't really see the point in waiting to do the sysfs registration stuff (if theres a reason I haven't been able to find it in the original submission of this functionality). Please let me know if this is incorrect. Thank you, Yes, it's incorrect ... if you do this, the devices will come up in a random order for multiple SCSI cards. One of the original design goals was not to require udev, so the final ordering should be the same as for the sync case. I think the root cause of the problem is somewhere in the fc transport rport addition code. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Broken process startup times after suspend (regression)
On Thu, 2007-05-03 at 17:03 +0200, Tomas Janousek wrote: > Hi, > > the commits > 411187fb05cd11676b0979d9fbf3291db69dbce2 (GTOD: persistent clock support) > c1d370e167d66b10bca3b602d3740405469383de (i386: use GTOD persistent clock > support) > caused a change in the way uptime is measured and introduced a regression such > that it's no longer possible to obtain a correct process start time or the > system boot time. > > These two commits make the monotonic time not jump by hudreds of seconds after > the kernel resumes from suspend, but they achieve it by moving the > wall_to_monotonic offset, which is used for all boot time / uptime > calculations. It's not possible to read the real boot time / process start > time then. Indeed. The monotonic clock's behavior around suspend and resume is poorly defined. When we increased it, folks didn't like the fact that uptime would increase while a system was suspended. > I was thinking about a solution and I am posting the least intrusive one I > found. I add a total_sleep_time variable which is to be added to > wall_to_monotonic when one wants the proper boot time. I do by no means say > it's the best one, I expect comments. While I'd prefer wrapping it in a interface and keeping it in timekeeping (rather then exporting a collection of values that should be combined in varying ways), I think this approach is probably the best. Rather then forcing one behavior or the other we can provide both smooth monotonic and monotonic w/ sleep. > This requires a patch to procps that makes it use /proc/stat's btime instead > of "now - uptime". This was written by Tomas Smetana and I'm attaching it as > well. (It was posted upstream as it fixes another bug in ps as well.) Or we > could just make the /proc/uptime contain "now - btime" like it used to before > those two commits. > > --- > fs/proc/proc_misc.c |2 +- > include/linux/time.h |1 + > kernel/fork.c|1 + > kernel/timer.c |6 ++ > 4 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/fs/proc/proc_misc.c b/fs/proc/proc_misc.c > index e2c4c0a..a29309e 100644 > --- a/fs/proc/proc_misc.c > +++ b/fs/proc/proc_misc.c > @@ -456,7 +456,7 @@ static int show_stat(struct seq_file *p, void *v) > > user = nice = system = idle = iowait = > irq = softirq = steal = cputime64_zero; > - jif = - wall_to_monotonic.tv_sec; > + jif = - (wall_to_monotonic.tv_sec + total_sleep_time); > if (wall_to_monotonic.tv_nsec) > --jif; As I said, could we wrap this in a function? Maybe something like get_monotonicwithsleep_time() (feel free to come up with a better name :). > diff --git a/include/linux/time.h b/include/linux/time.h > index 8ea8dea..cb87616 100644 > --- a/include/linux/time.h > +++ b/include/linux/time.h > @@ -90,6 +90,7 @@ static inline struct timespec timespec_sub(struct timespec > lhs, > > extern struct timespec xtime; > extern struct timespec wall_to_monotonic; > +extern unsigned long total_sleep_time; > extern seqlock_t xtime_lock __attribute__((weak)); > > extern unsigned long read_persistent_clock(void); > diff --git a/kernel/fork.c b/kernel/fork.c > index 6af959c..c051f17 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1056,6 +1056,7 @@ static struct task_struct *copy_process(unsigned long > clone_flags, > > p->lock_depth = -1; /* -1 = no lock */ > do_posix_clock_monotonic_gettime(>start_time); > + p->start_time.tv_sec += total_sleep_time; > p->security = NULL; > p->io_context = NULL; > p->io_wait = NULL; > diff --git a/kernel/timer.c b/kernel/timer.c > index dd6c2c1..13eb201 100644 > --- a/kernel/timer.c > +++ b/kernel/timer.c > @@ -759,9 +759,13 @@ unsigned long next_timer_interrupt(void) > * at zero at system boot time, so wall_to_monotonic will be negative, > * however, we will ALWAYS keep the tv_nsec part positive so we can use > * the usual normalization. > + * > + * One needs to add total_sleep_time to wall_to_monotonic to get the real > boot > + * time. > */ > struct timespec xtime __attribute__ ((aligned (16))); > struct timespec wall_to_monotonic __attribute__ ((aligned (16))); > +unsigned long total_sleep_time; > > EXPORT_SYMBOL(xtime); > > @@ -975,6 +979,7 @@ void __init timekeeping_init(void) > xtime.tv_nsec = 0; > set_normalized_timespec(_to_monotonic, > -xtime.tv_sec, -xtime.tv_nsec); > + total_sleep_time = 0; > > write_sequnlock_irqrestore(_lock, flags); > } > @@ -1004,6 +1009,7 @@ static int timekeeping_resume(struct sys_device *dev) > > xtime.tv_sec += sleep_length; > wall_to_monotonic.tv_sec -= sleep_length; > + total_sleep_time += sleep_length; > } > /* re-base the last cycle value */ > clock->cycle_last = clocksource_read(clock); Otherwise it looks good. Thanks for bringing this up! -john - To unsubscribe from this list:
Re: [patch] CFS scheduler, -v7
* Ting Yang <[EMAIL PROTECTED]> wrote: >> then how much time is needed for "curr" to build a 2 * 32 difference >> on fair_key, with every 1 ms it updates fair_key by 1/32 ? 2 * 32 * >> 32 ! On Thu, May 03, 2007 at 09:48:27PM +0200, Ingo Molnar wrote: > yes - but the "*32" impacts the rescheduling granularity, the "/32" > impacts the speed of how the key moves. So the total execution speed of > the nice -10 task is still "*32" of a nice 0 task - it's just that not > only it gets 32 times more CPU time, it also gets it at 32 times larger > chunks at once. But the rescheduling granularity does _not_ impact the > CPU share the task gets, so there's no quadratic effect. > but this is really simple to test: boot up CFS, start two infinite > loops, one at nice 0 and one at nice +10 and look at it via "top" and > type 's 60' in top to get a really long update interval for precise > results. You wont see quadratically less CPU time used up by the nice > +10 task, you'll see it getting the intended 1/32 share of CPU time. Davide has code to test this more rigorously. Looks like I don't need to do very much to get a nice test going at all, besides fiddling with options parsing and maybe a few other things. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] CFS scheduler, -v8
On Thu, 2007-05-03 at 08:53 -0700, William Lee Irwin III wrote: >> Tong Li's Trio scheduler does a bit of this, though it doesn't seem to >> have the mindshare cfs seems to have acquired. >> The hyperlink seems to have broken, though: >> http://www.cs.duke.edu/~tongli/linux/linux-2.6.19.2-trio.patch On Thu, May 03, 2007 at 11:44:27AM -0700, Li, Tong N wrote: > Yeah, I just fixed the link. The code was written based on the 2.6.19.2 > scheduler. I could forward-port it to the latest kernel if there's > interest and I can find time. :) Here's a description of the design: > http://lkml.org/lkml/2007/4/20/286 I have the interest. I don't see performance issues with any of the schedulers, but am rather interested in the feature. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic with 2.6.21-gdc87c398
Hi Ben, On 03/05/07, Ben Castricum <[EMAIL PROTECTED]> wrote: Roughly 5 minutes after trying 2.6.21-gdc87c398 it paniced. I took a couple of pictures of the screen and rebooted. So far it hasn't happened again. I uploaded all the info into http://www.bencastricum.nl/2.6.21-gdc87c398/ Hopefully this helps. Ben This is a known bug, here is a patch http://lkml.org/lkml/2007/5/3/38 Regards, Michal -- Michal K. K. Piotrowski Kernel Monkeys (http://kernel.wikidot.com/start) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] CFS scheduler, -v7
* Ting Yang <[EMAIL PROTECTED]> wrote: > then how much time is needed for "curr" to build a 2 * 32 difference > on fair_key, with every 1 ms it updates fair_key by 1/32 ? 2 * 32 * > 32 ! yes - but the "*32" impacts the rescheduling granularity, the "/32" impacts the speed of how the key moves. So the total execution speed of the nice -10 task is still "*32" of a nice 0 task - it's just that not only it gets 32 times more CPU time, it also gets it at 32 times larger chunks at once. But the rescheduling granularity does _not_ impact the CPU share the task gets, so there's no quadratic effect. but this is really simple to test: boot up CFS, start two infinite loops, one at nice 0 and one at nice +10 and look at it via "top" and type 's 60' in top to get a really long update interval for precise results. You wont see quadratically less CPU time used up by the nice +10 task, you'll see it getting the intended 1/32 share of CPU time. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/33] m68k: Atari keyboard and mouse support.
Hi, On Thu, 3 May 2007, Dmitry Torokhov wrote: > > I explained already at a earlier occasion, why this "generic" keycode > > thing is broken by design, which makes connecting multiple keyboards with > > different mappings impossible. > > > > No, I don't think so. Your points were: > > 1) You did not want to adjust your legacy keymap on Amiga Adjusting wouldn't be really a problem, if it had some value... > 2) You want userspace programs to know how to program scancodes for > every type of keyboard and have different keymaps for different type > of keyboards (So you need to have n_kbd_types * > n_international_mappings keymaps). I never said that. Many keyboard _types_ need a separate key mapping. Localization is a completely different problem (and could be solved via separate localization tables). Most of it can be solved in userspace and we wouldn't have to enumerate every possible single key the kernel never cares about in . > As far as 2) goes I think it is better to have unified keyboard map > across different types of keyboards and then overlay > internatinalization/other settings. And you still have per-keyboard > configurability as you can change scancode->keycode mapping on a > per-device basis via evdev ioctl. You still completely ignore the problem of how said application should properly support multiple keyboard mappings... bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: build system: no module target ending with slash?
On Thu, May 03, 2007 at 09:17:15AM +0200, Christian Hesse wrote: > On Thursday 03 May 2007, Sam Ravnborg wrote: > > On Thu, May 03, 2007 at 06:25:11AM +0200, Sam Ravnborg wrote: > > > On Thu, May 03, 2007 at 12:43:43AM +0200, Christian Hesse wrote: > > > > Hi James, hi everybody, > > > > > > > > playing with iwlwifi I try to patch it into the kernel and to build it > > > > from there. But I have a problem with the build system. > > > > > > > > The file drivers/net/wireless/mac80211/Makefile contains one single > > > > line: > > > > > > > > obj-$(CONFIG_IWLWIFI) += iwlwifi/ > > > > > > > > When CONFIG_IWLWIFI=m in scripts/Makefile.lib line 29 the target is > > > > filtered as it ends with a slash. That results in > > > > drivers/net/wireless/mac80211/built-in.o not being built and the build > > > > process breaks with an error. What is the correct way to handle this? > > > > Why are targets ending with a slash filtered? > > > > > > Looks buggy. I will take a look tonight. > > > > After some coffee... > > > > Line 29 in Kbuild.include find all modules and a directory is not a module. > > In line 26 in same file the directory iwlwifi is included in the list > > of directories to visit. > > So there is something else going on. > > In scripts/Kbuild.include line 26 is empty and line 29 is a comment... Do I > look at the wrong place? I looked at lxr.linux.no - so probarly an outdated version. > > I still believe in my version: built-in.o is built if any of $(obj-y) > $(obj-m) > $(obj-n) $(obj-) $(lib-target) contains anything in scripts/Makefile.build > line 77. As scripts/Makefile.lib line 29 filters the only target the object > file is not built. I have applied your patch and tried it out. The reason for the problem is the placeholder directory mac80211. kbuild will not waste time building built-in.o for a directory where it is not necessary. So for mac80211 no built-in.o is created since there is no need. The only reference is to a module. The quick-and-dirty workaround is to add a single obj-n := xx in mac80211/Makefile and kbuild is happy again. I could teach kbuild to create built-in.o also in the case where we refer to a subdirectory only. But then we would end up with a built-in.o in all directories where we have a kbuild MAkefile (almost) and that is not desireable. So I recommend the proposed workaround for now with a proper comment. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.21-rt1 - mips compile bugs
Ingo Molnar wrote: > i have released the v2.6.20-rt1 kernel... There was also a problem with the patch for arch/mips/kernel/entry.S Some kind of cruft was in the patch. Below is a patch which fixes both issues. It at least allows compilation. I haven't turned anything on, or looked at runtime yet. Index: alp-linux/arch/mips/kernel/entry.S === --- alp-linux.orig/arch/mips/kernel/entry.S 2007-05-03 12:28:38.0 -0700 +++ alp-linux/arch/mips/kernel/entry.S 2007-05-03 12:21:47.0 -0700 @@ -21,8 +21,6 @@ #endif #ifndef CONFIG_PREEMPT -<<< delete local_irq_disable - raw_local_irq_disable #define resume_kernel restore_all #else #define __ret_from_irq ret_from_exception @@ -32,7 +30,7 @@ .align 5 #ifndef CONFIG_PREEMPT FEXPORT(ret_from_exception) - local_irq_disable # preempt stop + raw_local_irq_disable # preempt stop b __ret_from_irq #endif FEXPORT(ret_from_irq) Index: alp-linux/include/asm-mips/atomic.h === --- alp-linux.orig/include/asm-mips/atomic.h2007-05-03 12:28:38.0 -0700 +++ alp-linux/include/asm-mips/atomic.h 2007-05-03 11:56:58.0 -0700 @@ -566,7 +566,6 @@ raw_local_irq_restore(flags); } #endif -#endif smp_mb(); = 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/
Re: [patch 01/10] compiler: define __attribute_unused__
On Thu, 3 May 2007, Adrian Bunk wrote: > > static external variables are certainly still static code and gcc issues > > the proper warnings if I do: > > > > static struct bootnode nodes[MAX_NUMNODES]; > > > > and I never reference nodes. > > No disagreement. > > But you said: > What about automatic or static external variables that are declared but ... > Ahh, I see the problem. I was talking about "automatic variables" and "static external variables" implicitly, both of which emit compiler warnings if they are unreferenced as we saw in the arch/i386/pci/init.c case and the example above, respectively. The only advantage this gives us as opposed to just removing an unreferenced variable completely is the case when its usage depends on multiple preprocessor macros. Like in the arch/i386/pci/init.c example, the use of 'type' depends on CONFIG_PCI_DIRECT or CONFIG_PCI_MMCONFIG. It gets sloppy pretty quickly when we're adding #if defined(CONFIG_PCI_DIRECT) || defined(CONFIG_PCI_MMCONFIG) around the variable declarations. Unfortunately we still have the drawback of perhaps leaving abandoned declarations in the code but now there will be an easy way to detect it: defining __maybe_unused and __used to be empty. Then we won't have hardcoded __attribute__ ((unused)) text sprinkled around the tree that would require examination on an individual basis. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at include/net/tcp.h:739 (was Re: kernel panic with 2.6.21-gdc87c398)
On Thu, May 03, 2007 at 09:01:56PM +0200, Ben Castricum wrote: > It crashed again, this time leaving more useable info on screen (see the > Crash2.jpg in the same directory). > > >I uploaded all the info into > > > >http://www.bencastricum.nl/2.6.21-gdc87c398/ Follow this thread http://marc.info/?t=11781374955=1=2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21 1/3] x86_64: EFI64 support
Randy Dunlap wrote: Can you share EFI code as much as possible among ia64, i386, and x86_64 instead of duplicating it? Hi Randy, Based on the feedback from Andi and you, these are the areas: 1. conversion of EFI memory map to e820 map 2. Consolidation/sharing of efi code among the architectures. 3. Coding style violations/typos/clarity in comments. First I apologize for the coding style violations where I should have done better. I will fix these in the next patch. I would like to address the above in stages with patch updates. This will take me some time with the fixes and testing. A while back, Edgar Hucek submitted a patch (probably 2.6.18 mm tree?) for efi to e820 memory mapping for i386.I don't see this code in the 2.6.21 release which makes me wonder whether it was accepted and the history behind it. Any pointers in this regard? thanks - mouli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/33] m68k: Atari keyboard and mouse support.
Hi Roman,
On 5/3/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
On Thu, 3 May 2007, Michael Schmitz wrote:
> > > + for (i = 1; i < 0x72; i++) {
> > > + atakbd_keycode[i] = i;
> > > + set_bit(atakbd_keycode[i], atakbd_dev->keybit);
> >
> > It looks like this driver is not using standard input event codes.
Actually it does, it just sort of works because Atari generates mostly
AT keycodes.
But not the input core codes, does it?
> > If
> > Roman does not want to adjust keymaps on Amiga and Atari that should
> > be handled in legacy keyboard driver (drivers/char/keyboard.c). As it
> > is programs using /dev/input/eventX have no chance of working.
I explained already at a earlier occasion, why this "generic" keycode
thing is broken by design, which makes connecting multiple keyboards with
different mappings impossible.
No, I don't think so. Your points were:
1) You did not want to adjust your legacy keymap on Amiga
2) You want userspace programs to know how to program scancodes for
every type of keyboard and have different keymaps for different type
of keyboards (So you need to have n_kbd_types *
n_international_mappings keymaps).
Answering 1) I sent you once a patch for review that would have amikbd
send raw scancode events in additional to standard input events and
drivers/char/keyboard.c pick these raw events on amiga so both legacy
driver and evdev could work, but I never heard from you.
As far as 2) goes I think it is better to have unified keyboard map
across different types of keyboards and then overlay
internatinalization/other settings. And you still have per-keyboard
configurability as you can change scancode->keycode mapping on a
per-device basis via evdev ioctl.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] NFS client updates for 2.6.22...
On Wed, 2007-05-02 at 07:52 -0700, Trond Myklebust wrote: > Hi Linus, > > Please pull from the repository at > >git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git I can confirm that this solves my missing IO completions problem; or at least, my test has been running for 8h+ and still going strong, whereas previous I would be lucky to get 1h. Would it be reasonable to include the relevant patches in a later .21-stable release? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.21-rt1 - bug in asm-mips/atomic.h
Ingo Molnar wrote:
> i have released the v2.6.20-rt1 kernel...
Ingo,
There appears to be a bug in the patch for include/asm-mips/atomic.h
In the hunk for line 554, it has 2 #endifs.
I think it should only have one.
A portion of the patch reads:
Index: new-linux/include/asm-mips/atomic.h
===
--- new-linux.orig/include/asm-mips/atomic.h2007-04-25 20:08:32.0
-0700
+++ new-linux/include/asm-mips/atomic.h 2007-04-26 16:15:14.0 -0700
@@ -545,7 +554,9 @@
: "=" (result), "=" (temp), "=m" (v->counter)
: "Ir" (i), "m" (v->counter)
: "memory");
- } else {
+ }
+#if !defined(CONFIG_NO_SPINLOCK) && !defined(CONFIG_PREEMPT_RT)
+ else {
unsigned long flags;
raw_local_irq_save(flags);
@@ -554,6 +565,8 @@
v->counter = result;
raw_local_irq_restore(flags);
}
+#endif
+#endif
smp_mb();
When I applied the patch to 2.6.21 and tried to compile for MIPS I got:
CHK include/linux/utsrelease.h
CC arch/mips/kernel/asm-offsets.s
In file included from
/home/tbird/work/alp-3.0/alp-linux/include/linux/rt_lock.h:14,
from
/home/tbird/work/alp-3.0/alp-linux/include/linux/spinlock.h:116,
from
/home/tbird/work/alp-3.0/alp-linux/include/linux/capability.h:45,
from
/home/tbird/work/alp-3.0/alp-linux/include/linux/sched.h:47,
from
/home/tbird/work/alp-3.0/alp-linux/arch/mips/kernel/asm-offsets.c:14:
include2/asm/atomic.h:571: error: expected '(' before 'volatile'
include2/asm/atomic.h:573: error: expected identifier or '(' before 'return'
include2/asm/atomic.h:574: error: expected identifier or '(' before '}' token
include2/asm/atomic.h:576: error: expected declaration specifiers or '...'
before 'atomic64_t'
include2/asm/atomic.h: In function 'atomic64_sub_return':
include2/asm/atomic.h:593: error: 'v' undeclared (first use in this function)
include2/asm/atomic.h:593: error: (Each undeclared identifier is reported only
once
include2/asm/atomic.h:593: error: for each function it appears in.)
include2/asm/atomic.h:585: error: invalid lvalue in asm output 2
include2/asm/atomic.h:585: error: memory input 4 is not directly addressable
include2/asm/atomic.h:599: error: invalid lvalue in asm output 2
include2/asm/atomic.h:599: error: memory input 4 is not directly addressable
include2/asm/atomic.h: At top level:
include2/asm/atomic.h:638: error: expected declaration specifiers or '...'
before 'atomic64_t'
include2/asm/atomic.h: In function 'atomic64_sub_if_positive':
include2/asm/atomic.h:659: error: 'v' undeclared (first use in this function)
include2/asm/atomic.h:647: error: invalid lvalue in asm output 2
include2/asm/atomic.h:647: error: memory input 4 is not directly addressable
include2/asm/atomic.h:665: error: invalid lvalue in asm output 2
include2/asm/atomic.h:665: error: memory input 4 is not directly addressable
In file included from
/home/tbird/work/alp-3.0/alp-linux/include/linux/rt_lock.h:14,
from
/home/tbird/work/alp-3.0/alp-linux/include/linux/spinlock.h:116,
from
/home/tbird/work/alp-3.0/alp-linux/include/linux/capability.h:45,
from
/home/tbird/work/alp-3.0/alp-linux/include/linux/sched.h:47,
from
/home/tbird/work/alp-3.0/alp-linux/arch/mips/kernel/asm-offsets.c:14:
include2/asm/atomic.h:779:2: error: #endif without #if
After removing the second #endif in the second hunk above, things compiled
better.
-- Tim
=
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.20.1] BUG: soft lockup detected on CPU#1!
My P4 with HT and 2GB of ram on an IDE disk succeeded in triggering another bug: [273187.872796] usb 7-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 161 rq 1 len 10 ret -110 [273902.586320] BUG: soft lockup detected on CPU#1! [273902.586385] [] show_trace_log_lvl+0x1a/0x30 [273902.586472] [] show_trace+0x12/0x14 [273902.586557] [] dump_stack+0x16/0x18 [273902.586636] [] softlockup_tick+0xa6/0xc2 [273902.586724] [] run_local_timers+0x12/0x14 [273902.586810] [] update_process_times+0x72/0xa1 [273902.586893] [] tick_sched_timer+0x53/0xb6 [273902.586977] [] hrtimer_interrupt+0x16b/0x1c2 [273902.587062] [] local_apic_timer_interrupt+0x55/0x5b [273902.587147] [] smp_apic_timer_interrupt+0x2a/0x39 [273902.587230] [] apic_timer_interrupt+0x33/0x38 [273902.587312] [] cpu_idle+0x6b/0x85 [273902.587393] [] start_secondary+0xe8/0x30a [273902.587476] [<>] 0x0 [273902.587568] === [277740.475464] usb 7-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 161 rq 1 len 10 ret -110 ... [285799.322391] usb 7-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 161 rq 1 len 10 ret -110 [286630.885843] BUG: soft lockup detected on CPU#1! [286630.885901] [] show_trace_log_lvl+0x1a/0x30 [286630.885988] [] show_trace+0x12/0x14 [286630.886071] [] dump_stack+0x16/0x18 [286630.886152] [] softlockup_tick+0xa6/0xc2 [286630.886235] [] run_local_timers+0x12/0x14 [286630.886323] [] update_process_times+0x72/0xa1 [286630.886406] [] tick_sched_timer+0x53/0xb6 [286630.886488] [] hrtimer_interrupt+0x16b/0x1c2 [286630.886571] [] local_apic_timer_interrupt+0x55/0x5b [286630.886657] [] smp_apic_timer_interrupt+0x2a/0x39 [286630.886741] [] apic_timer_interrupt+0x33/0x38 [286630.886824] [] cpu_idle+0x6b/0x85 [286630.886907] [] start_secondary+0xe8/0x30a [286630.886991] [<>] 0x0 [286630.887088] === [290177.972351] usb 7-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 161 rq 1 len 10 ret -110 My .config can be found here: http://keetweej.vanheusden.com/~folkert/config-2.6.21.1 Folkert van Heusden -- MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff- view', vs. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/33] m68k: Atari keyboard and mouse support.
Hi Michael,
On 5/3/07, Michael Schmitz <[EMAIL PROTECTED]> wrote:
>
> > +
> > + if (!(atakbd_dev = input_allocate_device()))
> > + return -ENOMEM;
> > +
> > + // need to init core driver if not already done so
> > + if (atari_keyb_init())
>
> Memory leak
How so? If the core has been initialized already this will just return ...
You just allocated atakbd_dev. If atari_keyb_init() fails you leak it.
> > + for (i = 1; i < 0x72; i++) {
> > + atakbd_keycode[i] = i;
> > + set_bit(atakbd_keycode[i], atakbd_dev->keybit);
>
> It looks like this driver is not using standard input event codes. If
> Roman does not want to adjust keymaps on Amiga and Atari that should
> be handled in legacy keyboard driver (drivers/char/keyboard.c). As it
> is programs using /dev/input/eventX have no chance of working.
The translation map should not have been overwritten like above, is that
what you mean?
My original patch didn't have that bit; scancodes were translated to
input keycodes using atakbd_keycode[scancode] instead. I'll have that
reverted...
Does KEY_1 actually maps to scancode 2 on atari?
Thanks,
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] export hrtimer_forward
Hello. Peter Zijlstra wrote: It seems hrtimer_forward was forgotten to export - other symbols of the hrtimers API Are there actual in-tree users of this symbol? Without we usually leave the symbol unexported, this saves some space. Do you mean it was really left intentional? Unbeleivable! But why the other parts of a hrtimer API are exported nevertheless, and only this particular function not? As for the users - I am porting my pcsp driver to it and I need that function. It is not exactly in-tree stuff, but it was in an ALSA tree for years already, so it is a close one. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 01/10] compiler: define __attribute_unused__
On Thu, May 03, 2007 at 11:56:34AM -0700, David Rientjes wrote: > On Thu, 3 May 2007, Adrian Bunk wrote: > > > > That's only addressing part of the issue. What about automatic or static > > > external variables that are declared but may go unreferenced depending on > > > > This is only about static code. For non-static code it would be > > impossible for gcc to issue warnings. > > static external variables are certainly still static code and gcc issues > the proper warnings if I do: > > static struct bootnode nodes[MAX_NUMNODES]; > > and I never reference nodes. No disagreement. But you said: What about automatic or static external variables that are declared but ... 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: [patch 14/22] pollfs: pollable futex
On 5/3/07, Davide Libenzi <[EMAIL PROTECTED]> wrote: I thought you were talking about the poll/epoll interface in general, and the approach on how to extend it for the very few cases that ppl asks for. but I see we're focusing on futexes ... Futexes must be part of the whole approach. If they cannot sanely be integrated the whole approach is more than questionable IMO. I'm not sure if futexes are the best approach to do that, but a way for the user to signal an event into a main event loop is needed. I haven't necessarily seen much of this demand and, as you pointed out yourself, there is already a completely valid and POSIX compliant way to achieve that. The situation would be very different if you couldn't reliably implement this. I don't suggest this as a long term solution, it's neither nice nor fast. But it is a way to achieve the goal until a real soution comes along. Signals cannot serve as a justification for introducing these new concepts. IMO it is better to leave futexes alone. They are great for syncronizing MT apps, but do not properly fit an fd-based solution. For that, something like eventfd is enough. That's ridiculously short-sighted. All objects upon which one can wait must be unified. This is possible. The kevent interface gives enough flexibility. Let's just finish the design and implementation of the real solution. Be it kevent (modified to meet the last comments, I think I still have some myself), or something completely different which you can propose. Then all programs which really care about performance can use that code. If a program doesn't care about performance then they might just as well use pipes in signal handlers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Mauro Carvalho Chehab wrote: > Enough. Let's stop arguing non technical issues. > > If either one of you have any technical argue against the Trent's > patches, please point where the fix is wrong. Otherwise, if you wish, > you may send an acked-by agreeing with the fix. > Why don't you stop this childish behaviour ? After explaining to you the reasons in the previous mail: being the author and maintainer of dst/dst_ca and maintainer of dvb-bt8xx, i NACK this change (1) You aren't DVB maintainer (2) one shouldn't make such judgement calls on somebody else's driver unless it falls within your own maintainership > Mauro. > > Em Qui, 2007-05-03 às 19:19 +0200, Markus Rechberger escreveu: >> On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: >>> Markus Rechberger wrote: >>> Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. >>> You very well know the reason why i am ignoring your mails. You just >>> tend to flame people for nothing. I tend to ignore the flamers. >>> >> You should stop to rely on the history, since such a flame needs at >> least 2 parties and back then you were also involved. There's nothing >> else to say about that. >> If you don't change that attitude immediatelly I'd really wish to get you banned of this community until you're open for discussions. http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html there's a bugreport and you fully ignore it, and you blame it on the "politicians" here, telling me that there are mails out there somewhere shows that you're not interested in getting forward. >>> That bug report very well proves my point. >> Well it would be nice if you could answer the question in that mail >> then, I don't see any reason why you shouldn't answer it. >> >> It's just a guess, but it seems like that you had a problem with other >> developers at that part and it seems like it didn't get to an end >> (probably because both parties didn't agree with each other) >> >> Markus >> - >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to [EMAIL PROTECTED] >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support
On Thursday 03 May 2007, Segher Boessenkool wrote: > > For example, you could make this > > > > compatible = "8xx\0mpc885ads"; > > "mpc885ads-pcmcia\0mpc8xx-pcmcia" or something like that. Right. I can never remember what goes first... Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic with 2.6.21-gdc87c398
Roughly 5 minutes after trying 2.6.21-gdc87c398 it paniced. I took a couple of pictures of the screen and rebooted. So far it hasn't happened again. It crashed again, this time leaving more useable info on screen (see the Crash2.jpg in the same directory). I uploaded all the info into http://www.bencastricum.nl/2.6.21-gdc87c398/ Hopefully this helps. 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/
[git patches] ocfs2 fixes
Here's some various fixes and cleanups I had slated for a later pull, but
our Ocfs2 testing is ahead of schedule.
Please pull from 'upstream-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git upstream-linus
to receive the following updates:
fs/ocfs2/alloc.c |6 ++--
fs/ocfs2/aops.c | 11
fs/ocfs2/cluster/heartbeat.c |2 -
fs/ocfs2/cluster/tcp.c | 10 +++
fs/ocfs2/dir.c |7 -
fs/ocfs2/dlm/dlmast.c| 12 -
fs/ocfs2/dlm/dlmrecovery.c |4 +--
fs/ocfs2/dlm/dlmthread.c |2 -
fs/ocfs2/dlmglue.c | 54 +++
fs/ocfs2/dlmglue.h |7 -
fs/ocfs2/export.c|6 +++-
fs/ocfs2/file.c | 17 +
fs/ocfs2/file.h |5 ---
fs/ocfs2/inode.c | 35 +++
fs/ocfs2/inode.h |1
fs/ocfs2/ioctl.c | 24 +++
fs/ocfs2/ioctl.h |1
fs/ocfs2/journal.c |7 +++--
fs/ocfs2/namei.c |5 ++-
fs/ocfs2/ocfs2.h | 12 -
fs/ocfs2/ocfs2_fs.h |2 +
fs/ocfs2/suballoc.c | 10 +++
fs/ocfs2/super.c |2 -
23 files changed, 151 insertions(+), 91 deletions(-)
Adrian Bunk:
fs/ocfs2/: make 3 functions static
Jan Kara:
Copy i_flags to ocfs2 inode flags on write
Joel Becker:
ocfs2: Wrap access of directory allocations with ip_alloc_sem.
Mark Fasheh:
ocfs2: Implement compat_ioctl()
ocfs2: fix sparse warnings in fs/ocfs2
ocfs2: fix sparse warnings in fs/ocfs2/dlm
ocfs2: fix sparse warnings in fs/ocfs2/cluster
ocfs2: Force use of GFP_NOFS in ocfs2_write()
Milind Arun Choudhary:
ocfs2: use __set_current_state()
diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
index a0c8667..19712a7 100644
--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -2869,7 +2869,7 @@ int ocfs2_complete_truncate_log_recovery
tl = _copy->id2.i_dealloc;
num_recs = le16_to_cpu(tl->tl_used);
mlog(0, "cleanup %u records from %llu\n", num_recs,
-(unsigned long long)tl_copy->i_blkno);
+(unsigned long long)le64_to_cpu(tl_copy->i_blkno));
mutex_lock(_inode->i_mutex);
for(i = 0; i < num_recs; i++) {
@@ -3801,8 +3801,8 @@ int ocfs2_prepare_truncate(struct ocfs2_
fe = (struct ocfs2_dinode *) fe_bh->b_data;
mlog(0, "fe->i_clusters = %u, new_i_clusters = %u, fe->i_size ="
-"%llu\n", fe->i_clusters, new_i_clusters,
-(unsigned long long)fe->i_size);
+"%llu\n", le32_to_cpu(fe->i_clusters), new_i_clusters,
+(unsigned long long)le64_to_cpu(fe->i_size));
*tc = kzalloc(sizeof(struct ocfs2_truncate_context), GFP_KERNEL);
if (!(*tc)) {
diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c
index 56963e6..8e7cafb 100644
--- a/fs/ocfs2/aops.c
+++ b/fs/ocfs2/aops.c
@@ -78,7 +78,8 @@ static int ocfs2_symlink_get_block(struc
if (!OCFS2_IS_VALID_DINODE(fe)) {
mlog(ML_ERROR, "Invalid dinode #%llu: signature = %.*s\n",
-(unsigned long long)fe->i_blkno, 7, fe->i_signature);
+(unsigned long long)le64_to_cpu(fe->i_blkno), 7,
+fe->i_signature);
goto bail;
}
@@ -939,9 +940,9 @@ out:
* Returns a negative error code or the number of bytes copied into
* the page.
*/
-int ocfs2_write_data_page(struct inode *inode, handle_t *handle,
- u64 *p_blkno, struct page *page,
- struct ocfs2_write_ctxt *wc, int new)
+static int ocfs2_write_data_page(struct inode *inode, handle_t *handle,
+u64 *p_blkno, struct page *page,
+struct ocfs2_write_ctxt *wc, int new)
{
int ret, copied = 0;
unsigned int from = 0, to = 0;
@@ -1086,7 +1087,7 @@ static ssize_t ocfs2_write(struct file *
for(i = 0; i < numpages; i++) {
index = start + i;
- cpages[i] = grab_cache_page(mapping, index);
+ cpages[i] = find_or_create_page(mapping, index, GFP_NOFS);
if (!cpages[i]) {
ret = -ENOMEM;
mlog_errno(ret);
diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index eba282d..9791134 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -438,7 +438,7 @@ static inline void o2hb_prepare_block(st
hb_block));
mlog(ML_HB_BIO, "our node generation = 0x%llx, cksum = 0x%x\n",
-(long long)cpu_to_le64(generation),
+(long long)generation,
le32_to_cpu(hb_block->hb_cksum));
}
diff --git a/fs/ocfs2/cluster/tcp.c
Re: [patch 01/10] compiler: define __attribute_unused__
On Thu, 3 May 2007, Adrian Bunk wrote: > > That's only addressing part of the issue. What about automatic or static > > external variables that are declared but may go unreferenced depending on > > This is only about static code. For non-static code it would be > impossible for gcc to issue warnings. > static external variables are certainly still static code and gcc issues the proper warnings if I do: static struct bootnode nodes[MAX_NUMNODES]; and I never reference nodes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] export hrtimer_forward
On Thu, 2007-05-03 at 21:57 +0400, Stas Sergeev wrote: > Hello. > > It seems hrtimer_forward was forgotten to > export - other symbols of the hrtimers API > are already exported. > Unless I am missing something, using the > hrtimers without that function is problematic. > > Andrew, could you please apply? Are there actual in-tree users of this symbol? Without we usually leave the symbol unexported, this saves some space. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] CFS scheduler, -v8
On Thu, 2007-05-03 at 08:53 -0700, William Lee Irwin III wrote: > On Thu, May 03, 2007 at 03:29:32PM +0200, Damien Wyart wrote: > >> What are your thoughts/plans concerning merging CFS into mainline ? Is > >> it a bit premature to get it into 2.6.22 ? I remember Linus was ok to > >> change the default scheduler rapidly (the discussion was about sd at > >> that time) to get more testing than in -mm. > > On Thu, May 03, 2007 at 08:23:18PM +0530, Srivatsa Vaddagiri wrote: > > And what about group scheduling extensions? Do you have plans to work on > > it? I was begining to work on a prototype to do group scheduling based > > on CFS, basically on the lines of what you and Linus had outlined > > earlier: > > http://lkml.org/lkml/2007/4/18/271 > > http://lkml.org/lkml/2007/4/18/244 > > Tong Li's Trio scheduler does a bit of this, though it doesn't seem to > have the mindshare cfs seems to have acquired. > > The hyperlink seems to have broken, though: > http://www.cs.duke.edu/~tongli/linux/linux-2.6.19.2-trio.patch Yeah, I just fixed the link. The code was written based on the 2.6.19.2 scheduler. I could forward-port it to the latest kernel if there's interest and I can find time. :) Here's a description of the design: http://lkml.org/lkml/2007/4/20/286 Thanks, tong - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] utrace: remove exports
On Mon, Apr 30, 2007 at 10:12:44AM +0100, Christoph Hellwig wrote: > On Sun, Apr 29, 2007 at 09:02:32PM -0700, Roland McGrath wrote: > > > EXPORT_SYMBOL_GPL(utrace_attach); > > > > > > There is not modular user of this, so this and the other utrace_ > > > functions should not be exported. Nor do I think that exporting > > > such a low-level process control is nessecary a good idea, but > > > we'll have to evaluate that if patches to add users show up. > > > > If you remove the exports, just throw the whole thing away. > > The reason utrace exists is to be used by modules. > > used != used by modules. Even without things exported you can use > things in the kernel. Once we have a valid modular use case we can > add exports. Christoph, it's at http://people.redhat.com/roland/utrace/crash-suspend.c The file crash-suspend.c is a simple example of a loadable kernel module using the new infrastructure. It implements the old GNU feature of doing a job suspend on crash, so you can attach a debugger right then instead of just looking at the core file afterwards. Try for example: $ sudo /sbin/insmod crash-suspend.ko pid=$$ to load the module and attach it to your shell. It then attaches to any children of your shell. Now run something that crashes and would ordinarily dump core--you can just run cat or sleep and hit ^\ to crash it with a SIGQUIT. See it suspend. Try "jobs -l" and see it stopped with a non-stop signal. If you resume it with "fg" it will go ahead and dump core. Or, you can attach a debugger like gdb first, and then debug it. Most certainly, it should be included into utrace patchset to pin some exports. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] CIFS: make sec=none force an anonymous mount
On Thu, May 03, 2007 at 02:32:33PM -0400, Jeff Layton wrote: > We had a customer report that attempting to make CIFS mount with a null > username (i.e. doing an anonymous mount) doesn't work. Looking through the > code, it looks like CIFS expects a NULL username from userspace in order > to trigger an anonymous mount. The mount.cifs code doesn't seem to ever > pass a null username to the kernel, however. > > It looks also like the kernel can take a sec=none option, but it only seems > to look at it if the username is already NULL. This seems redundant and > effectively makes sec=none useless. > > The following patch makes sec=none force an anonymous mount. I've briefly > tested it and it seems to work. I suppose we could alternately do some > stuff in userspace to make mount.cifs force a null username instead, but this > seems more straightforward to me. Looks useful. In case you have some spare time at your hand it would be really nice to convert cifs option parsing to the lib/parser.c code and move all validation of the arguments into one place, so it's easily understanable and better to maintain. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] crypto: convert crypto.h to UTF-8
On May 3 2007 11:35, John Anthony Kazos Jr. wrote:
>
>> >non-stupid/non-broken distributions of GNU/Linux and other major Un*ces
>> >should be based on (or at least compatible with) UTF-8 in basic
>> >operations. Files like the keymaps will be more work to convert, but they
>> >can be as well.
>> >
>> >I'm operating on the assumption that anything in the tree that isn't UTF-8
>> >is ISO-8859-1. Of course, I'm also checking it by hand to make sure a
>> >small-O-with-umlaut doesn't become the Klingon logo...
>>
>> This is probably all you'll ever see:
>> http://lkml.org/lkml/2007/1/8/222
>
>Does this mean you're doing it and I'll be ignored, or that few people
>care and I'll be ignored?
Nah. I did a walkthrough once, and my discoveries were that
iso-8859-{2 .. 14} was a real minority if not nonexistant,
leaving you with almost obvious choices to guess what a file's
encoding is. If a name looks good, it must be UTF8 already.
Else try ISO-8859-1. If it still looks odd -- perhaps because
it's a weirdo character like "1/2" or it "does not sound right",
try cp437. etc.
> I figure if I just repost my patches to LKML
>once per month, they'll eventually get merged (or at least I'll get
>comments on how people actually want them). Things are tough on a
>high-volume list. I think the git method may have the best chance of
>success. We'll see.
>
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH 35/36] Use menuconfig objects II - DVB
Em Qui, 2007-05-03 às 14:54 +0200, Jan Engelhardt escreveu: > On May 3 2007 09:37, Mauro Carvalho Chehab wrote: > >Trent is mentioning an out-of-tree building system to allow easier > >testing of V4L/DVB patches by end users and developers and during driver > >development time. The building system allows faster > >compilation/linkedition during driver development, by allowing you to > >use: > > make menuconfig/qconfig/xconfig > > > >inside the tree, unselecting the drivers that you're not working. > > Is that all? Because you can do > > make drivers/media/video/ > > today and it will only build that directory (or even > drivers/media/video/foo.o) to only do that one. I know. Use this procedure also. This is a very nice feature for kernel developers. However, you cannot use this procedure at the newest kernel to generate a foo.ko driver for an older kernel. Using the out-of-tree building system allows to compile also against older kernel versions, helping us to receive more feedback from end users. This is important for V4L/DVB development, since there are a number of normal users that just bought a new video capture board or webcam and want to compile the newest driver, without risking on compiling the entire kernel, and selecting several items they don't understand. There are more than 500 different supported boards, with lots of different variations. Probably, there are more board variations than subscribed users at V4L ML. Believe-me, it is not easy to find people with all those variations, asking they to replace their kernels to the newest version, although this is the recommended way. So, it is important to have an easy procedure for they to test V4L/DVB. They just need to clone the tree or retrieve a tarball, and do "make; make install" (providing that the kernel were compiled with modules option enabled). Advanced users may also do "make menuconfig" to select just the driver for his board. They don't need to touch on other kernel parameters. Anyway, Trent's wrote a fix for our building system, adding the missing Kconfig vocabulary used on drivers/media Kconfig. -- Cheers, Mauro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: console font limits
On May 3 2007 17:56, Geert Uytterhoeven wrote: >> >> Actually, the kernel could just "jump in". That is, when you start >> in fb mode, you get the regular 8x16 vga font - on your choice of >> resolution, and can also set it with setfont. So far so nice. >> Now, when you start fbiterm -- for example to read CJK --, fbiterm >> presents you with what looks like a 12x24 font. Also good. >> It _looks_ to me like fbiterm does the drawing itself; ok too. >> Now when the kernel is oopsing, it could just spew out the oops >> trace in the regular font (vga8x16 or in case you use CONFIG_FONTS, >> then that), possibly obstructing some output generated by fbiterm, >> but in case of oops, I think this is ok. > >Funny, that's exactly how kernel messages where handled in the early >fbdev days: just draw them to the frame buffer, whatever mode it is >in... >Just like on the SunOS boxes ;-) Right, I remember! But not only SunOS, _SPARCs_ 'themselves' also do it. OBP is always sun-style, i.e. black-on-white and a big 12x22 font, even if you jump to it from Linux using Stop-A. >Put people didn't like that, and disabled text output when the console >is in KD_GRAPHICS mode... at the cost of not getting the kernel oops, heh. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel panic with 2.6.21-gdc87c398
Roughly 5 minutes after trying 2.6.21-gdc87c398 it paniced. I took a couple of pictures of the screen and rebooted. So far it hasn't happened again. I uploaded all the info into http://www.bencastricum.nl/2.6.21-gdc87c398/ Hopefully this helps. 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/
[PATCH] CIFS: make sec=none force an anonymous mount
We had a customer report that attempting to make CIFS mount with a null
username (i.e. doing an anonymous mount) doesn't work. Looking through the
code, it looks like CIFS expects a NULL username from userspace in order
to trigger an anonymous mount. The mount.cifs code doesn't seem to ever
pass a null username to the kernel, however.
It looks also like the kernel can take a sec=none option, but it only seems
to look at it if the username is already NULL. This seems redundant and
effectively makes sec=none useless.
The following patch makes sec=none force an anonymous mount. I've briefly
tested it and it seems to work. I suppose we could alternately do some
stuff in userspace to make mount.cifs force a null username instead, but this
seems more straightforward to me.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index cf40e24..330e290 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -1721,12 +1721,13 @@ cifs_mount(struct super_block *sb, struct cifs_sb_info
*cifs_sb,
return -EINVAL;
}
- if (volume_info.username) {
+ if (volume_info.nullauth) {
+ cFYI(1,("null user"));
+ volume_info.username = NULL;
+ } else if (volume_info.username) {
/* BB fixme parse for domain name here */
cFYI(1, ("Username: %s ", volume_info.username));
- } else if (volume_info.nullauth) {
- cFYI(1,("null user"));
} else {
cifserror("No username specified");
/* In userspace mount helper we can get user name from alternate
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] export hrtimer_forward
Hello. It seems hrtimer_forward was forgotten to export - other symbols of the hrtimers API are already exported. Unless I am missing something, using the hrtimers without that function is problematic. Andrew, could you please apply? Signed-off-by: <[EMAIL PROTECTED]> --- a/kernel/hrtimer.c 2007-04-27 13:00:25.0 +0400 +++ b/kernel/hrtimer.c 2007-05-03 17:27:40.0 +0400 @@ -666,6 +666,7 @@ return orun; } +EXPORT_SYMBOL_GPL(hrtimer_forward); /* * enqueue_hrtimer - internal function to (re)start a timer
Re: [patch 14/22] pollfs: pollable futex
I thought you were talking about the poll/epoll interface in general, and the approach on how to extend it for the very few cases that ppl asks for. but I see we're focusing on futexes ... On Thu, 3 May 2007, Ulrich Drepper wrote: > On 5/2/07, Davide Libenzi <[EMAIL PROTECTED]> wrote: > > 99% of the fds you'll find inside an event loop you care to scale about, > > are *already* fd based. > > You are missing the point. To get acceptable behavior of the wakeup > it is necessary with this approach to open one descriptor _per thread_ > for a futex. Otherwise all threads get woken upon FUTEX_WAKE. > > This also means you need individual epoll sets for each thread. You > cannot share them anymore among all the threads in the process. I'm not sure if futexes are the best approach to do that, but a way for the user to signal an event into a main event loop is needed. > > On top of that, those fds are very cheap in terms of memory > > They might be when they are counted in dozens. But here we are > talking about the possible need to use thousands of additional file > descriptors. If they are so cheap to allow thousands of descriptors > with ease, why would the rlimit for files default to a small number > (1024 on Fedora right now)? Right now, ppl do that using pipes. That costs 2 file descriptors and at least 4KB of kernel data (plus an inode, a dentry and a file). This just to have a way to signal to an event loop dispatcher. The patches I posted a few weeks ago introduce an eventfd, that reduces the amount of kernel memory to basically a dentry and a file (plus uses only one file descriptor, and its 2-3 times faster than pipes. Add to that cost, about 200 lines of code in fs/eventfd.c. > > And this approach is not bound to a completely new and monolitic interface. > > So? It's stil additional, new code for an approach which will have to > be superceded real soon. That's just pure overhead to me. IMO it is better to leave futexes alone. They are great for syncronizing MT apps, but do not properly fit an fd-based solution. For that, something like eventfd is enough. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dead CONFIG_ variables: th-th-that's all, folks
you've been a great crowd, really. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dead CONFIG_ variables under drivers/serial/
this one's a biggie, with a few obvious false positives.
$ ../dead_config.sh drivers/serial
== 68328_SERIAL_UART2 ==
drivers/serial/68328serial.h:184:#ifndef CONFIG_68328_SERIAL_UART2
== ALMA_ANS ==
drivers/serial/68328serial.c:109:#if defined(CONFIG_M68EZ328ADS) ||
defined(CONFIG_ALMA_ANS) || defined(CONFIG_DRAGONIXVZ)
== CONSOLE ==
drivers/serial/68328serial.c:82:#ifdef CONFIG_CONSOLE
drivers/serial/68328serial.c:309:#ifdef CONFIG_CONSOLE
arch/m68k/kernel/head.S:156: * #ifdef CONSOLE/#endif clauses so it doesn't have
to ship in known-good
arch/m68k/kernel/head.S:201: * CONSOLE: There is support for head.S console in
this file. This
arch/m68k/kernel/head.S:276:#define CONSOLE
arch/m68k/kernel/head.S:493:#if defined(CONSOLE) || defined(SERIAL_DEBUG)
arch/m68k/kernel/head.S:496:#ifdef CONSOLE
arch/m68k/kernel/head.S:502:#if defined(CONSOLE) || defined(SERIAL_DEBUG)
arch/m68k/kernel/head.S:522:#if defined(CONSOLE) || defined(SERIAL_DEBUG)
arch/m68k/kernel/head.S:913:#ifdef CONSOLE
arch/m68k/kernel/head.S:919:#endif /* CONSOLE */
arch/m68k/kernel/head.S:1424:#if defined(CONSOLE)
arch/m68k/kernel/head.S:3210:#ifdef CONSOLE
arch/m68k/kernel/head.S:3239:#ifdef CONSOLE
arch/m68k/kernel/head.S:3301:#ifdef CONSOLE
arch/m68k/kernel/head.S:3782:#endif /* CONSOLE */
arch/m68k/kernel/head.S:3827:#if defined(CONSOLE)
arch/m68k/kernel/head.S:3839:#endif /* CONSOLE */
arch/alpha/kernel/err_common.c:248: printk("%s*** CONSOLE DATA LOG FOR
CPU %d. ***\n"
arch/alpha/kernel/err_common.c:259: " END OF CONSOLE DATA LOG
FOR CPU %d \n",
arch/s390/kernel/setup.c:238: cpcmd("QUERY CONSOLE", query_buffer,
1024, NULL);
Documentation/ia64/serial.txt:43:CONSOLE SELECTION
Documentation/ia64/serial.txt:70:EARLY SERIAL CONSOLE
Documentation/ia64/serial.txt:83:TROUBLESHOOTING SERIAL CONSOLE PROBLEMS
Documentation/sh/kgdb.txt:160:NOTE: TO AVOID LOSSING CONSOLE MESSAGES IN CASE
THE KERNEL CONSOLE AND
Documentation/s390/config3270.sh:59:elif [ $maj = CONSOLE ]; then
include/asm-sh/snapgear.h:58: * D4 ttySC0 DCD (7100) CONSOLE
include/linux/fb.h:515:/* CONSOLE-SPECIFIC: get console to framebuffer
mapping */
include/linux/fb.h:517:/* CONSOLE-SPECIFIC: set console to framebuffer
mapping */
MAINTAINERS:3028:SGI SN-IA64 (Altix) SERIAL CONSOLE DRIVER
== CONSOLE_115200 ==
drivers/serial/68360serial.c:309:#elif defined(CONFIG_CONSOLE_115200)
== CONSOLE_19200 ==
drivers/serial/68360serial.c:307:#elif defined(CONFIG_CONSOLE_19200)
== CONSOLE_9600 ==
drivers/serial/68360serial.c:305:#if defined(CONFIG_CONSOLE_9600)
== CPU_S3C2413 ==
drivers/serial/s3c2410.c:1530:#if defined(CONFIG_CPU_S3C2412) ||
defined(CONFIG_CPU_S3C2413)
== DRAGONIXVZ ==
drivers/serial/68328serial.c:109:#if defined(CONFIG_M68EZ328ADS) ||
defined(CONFIG_ALMA_ANS) || defined(CONFIG_DRAGONIXVZ)
== ETRAX_EXTERN_PB6CLK_ENABLED ==
drivers/serial/crisv10.c:3445:#ifdef CONFIG_ETRAX_EXTERN_PB6CLK_ENABLED
== ETRAX_RS485_LTC1387 ==
drivers/serial/crisv10.c:1762:#if defined(CONFIG_ETRAX_RS485_LTC1387)
drivers/serial/crisv10.c:4397:#if defined(CONFIG_ETRAX_RS485_LTC1387)
== ETRAX_RS485_ON_PORT_G ==
drivers/serial/crisv10.c:471:#if defined(CONFIG_ETRAX_RS485_ON_PA) &&
defined(CONFIG_ETRAX_RS485_ON_PORT_G)
drivers/serial/crisv10.c:472:#error "Disable either CONFIG_ETRAX_RS485_ON_PA or
CONFIG_ETRAX_RS485_ON_PORT_G"
drivers/serial/crisv10.c:845:#if defined(CONFIG_ETRAX_RS485_ON_PORT_G)
drivers/serial/crisv10.c:1758:#if defined(CONFIG_ETRAX_RS485_ON_PORT_G)
drivers/serial/crisv10.c:4393:#if defined(CONFIG_ETRAX_RS485_ON_PORT_G)
== ETRAX_SERIAL_PROC_ENTRY ==
drivers/serial/crisv10.c:295: * CONFIG_ETRAX_SERIAL_PROC_ENTRY together.
drivers/serial/crisv10.c:299: * Added CONFIG_ETRAX_SERIAL_PROC_ENTRY for
statistics and debug info.
drivers/serial/crisv10.c:813:#ifdef CONFIG_ETRAX_SERIAL_PROC_ENTRY
drivers/serial/crisv10.c:835:#endif /* CONFIG_ETRAX_SERIAL_PROC_ENTRY */
== ETRAX_SERX_DTR_RI_DSR_CD_MIXED ==
drivers/serial/crisv10.c:1097:#define CONFIG_ETRAX_SERX_DTR_RI_DSR_CD_MIXED
drivers/serial/crisv10.c:1100:#ifdef CONFIG_ETRAX_SERX_DTR_RI_DSR_CD_MIXED
drivers/serial/crisv10.c:1193:#else /* CONFIG_ETRAX_SERX_DTR_RI_DSR_CD_MIXED */
drivers/serial/crisv10.c:1275:#endif /* !CONFIG_ETRAX_SERX_DTR_RI_DSR_CD_MIXED
*/
== GILBARCO ==
drivers/serial/mcfserial.c:64: defined(CONFIG_M5329EVB) ||
defined(CONFIG_GILBARCO)
== HARD_PPS ==
drivers/serial/68360serial.c:559:#ifdef CONFIG_HARD_PPS
== M68EZ328ADS ==
drivers/serial/68328serial.c:109:#if defined(CONFIG_M68EZ328ADS) ||
defined(CONFIG_ALMA_ANS) || defined(CONFIG_DRAGONIXVZ)
arch/m68knommu/kernel/setup.c:199: printk(KERN_INFO "M68EZ328ADS board
support (C) 1999 Vladimir Gurevich <[EMAIL PROTECTED]>\n");
Re: Remove apparently dead CONFIG_NO_ATA_LEGACY code.
On Thu, 3 May 2007 13:53:06 -0400 (EDT) Robert P. J. Day wrote:
>
> Remove the single snippet of code conditional on the non-existent
> CONFIG_NO_ATA_LEGACY Kconfig variable.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> i would have mailed a note about this to the ATA maintainer but it
> wasn't clear who that was. this is the only dead CONFIG_ variable
> under drivers/ata so i figured i'd just submit the patch.
from that source file:
* Maintained by: Jeff Garzik <[EMAIL PROTECTED]>
* Please ALWAYS copy [EMAIL PROTECTED]
* on emails.
> diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
> index d211db6..5a4821a 100644
> --- a/drivers/ata/libata-sff.c
> +++ b/drivers/ata/libata-sff.c
> @@ -985,16 +985,6 @@ int ata_pci_init_one (struct pci_dev *pdev, struct
> ata_port_info **port_info,
> mask = (1 << 2) | (1 << 0);
> if ((tmp8 & mask) != mask)
> legacy_mode = (1 << 3);
> -#if defined(CONFIG_NO_ATA_LEGACY)
> - /* Some platforms with PCI limits cannot address compat
> -port space. In that case we punt if their firmware has
> -left a device in compatibility mode */
> - if (legacy_mode) {
> - printk(KERN_ERR "ata: Compatibility mode ATA is not
> supported on this platform, skipping.\n");
> - rc = -EOPNOTSUPP;
> - goto err_out;
> - }
> -#endif
> }
>
> /* alloc and init host */
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
dead CONFIG_ variables under drivers/pcmcia
$ ../dead_config.sh drivers/pcmcia == M32RPCC_SLOT2 == drivers/pcmcia/m32r_pcc.c:710:#ifdef CONFIG_M32RPCC_SLOT2 == MPC860T == drivers/pcmcia/m8xx_pcmcia.c:95:#if defined(CONFIG_MPC860T) || defined(CONFIG_MPC860) || defined(CONFIG_MPC821) arch/ppc/8xx_io/fec.c:7: * for the control of the LevelOne LXT970 transceiver. The MPC860T manual drivers/net/fec.c:7: * for the control of the LevelOne LXT970 transceiver. The MPC860T manual drivers/net/fec.c:1791: * Code specific to the MPC860T setup. include/asm-ppc/8xx_immap.h:388:/* MPC860T Fast Ethernet Controller. It isn't part of the CPM, but == PCMCIA_SLOT_A == drivers/pcmcia/m8xx_pcmcia.c:79:#if !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) drivers/pcmcia/m8xx_pcmcia.c:89:#define CONFIG_PCMCIA_SLOT_A drivers/pcmcia/m8xx_pcmcia.c:96:#define CONFIG_PCMCIA_SLOT_A drivers/pcmcia/m8xx_pcmcia.c:103:#define CONFIG_PCMCIA_SLOT_A drivers/pcmcia/m8xx_pcmcia.c:109:#define CONFIG_PCMCIA_SLOT_A drivers/pcmcia/m8xx_pcmcia.c:113:#endif /* !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) */ drivers/pcmcia/m8xx_pcmcia.c:115:#if defined(CONFIG_PCMCIA_SLOT_A) && defined(CONFIG_PCMCIA_SLOT_B) drivers/pcmcia/m8xx_pcmcia.c:123:#elif defined(CONFIG_PCMCIA_SLOT_A) || defined(CONFIG_PCMCIA_SLOT_B) drivers/pcmcia/m8xx_pcmcia.c:132:#ifdef CONFIG_PCMCIA_SLOT_A == PCMCIA_SLOT_B == drivers/pcmcia/m8xx_pcmcia.c:79:#if !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) drivers/pcmcia/m8xx_pcmcia.c:83:#define CONFIG_PCMCIA_SLOT_B drivers/pcmcia/m8xx_pcmcia.c:98:#define CONFIG_PCMCIA_SLOT_B drivers/pcmcia/m8xx_pcmcia.c:110:#define CONFIG_PCMCIA_SLOT_B drivers/pcmcia/m8xx_pcmcia.c:113:#endif /* !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) */ drivers/pcmcia/m8xx_pcmcia.c:115:#if defined(CONFIG_PCMCIA_SLOT_A) && defined(CONFIG_PCMCIA_SLOT_B) drivers/pcmcia/m8xx_pcmcia.c:123:#elif defined(CONFIG_PCMCIA_SLOT_A) || defined(CONFIG_PCMCIA_SLOT_B) == PRxK == drivers/pcmcia/m8xx_pcmcia.c:108:#ifdef CONFIG_PRxK drivers/pcmcia/m8xx_pcmcia.c:545:#if defined(CONFIG_PRxK) drivers/pcmcia/m8xx_pcmcia.c:605:#endif /* CONFIG_PRxK */ rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] synclink_gt add compat_ioctl
Add compat_ioctl handler to synclink_gt driver.
The one case requiring a separate 32 bit handler could be
removed by redefining the associated structure in
a way compatible with both 32 and 64 bit systems. But that
approach would break existing native 64 bit user applications.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/include/linux/synclink.h 2007-04-25 22:08:32.0 -0500
+++ b/include/linux/synclink.h 2007-05-03 12:44:09.0 -0500
@@ -9,6 +9,8 @@
* the terms of the GNU Public License (GPL)
*/
+#include
+
#ifndef _SYNCLINK_H_
#define _SYNCLINK_H_
#define SYNCLINK_H_VERSION 3.6
@@ -167,6 +169,24 @@ typedef struct _MGSL_PARAMS
} MGSL_PARAMS, *PMGSL_PARAMS;
+/* provide 32 bit ioctl compatibility on 64 bit systems */
+struct MGSL_PARAMS32
+{
+ compat_ulong_t mode;
+ unsigned char loopback;
+ unsigned short flags;
+ unsigned char encoding;
+ compat_ulong_t clock_speed;
+ unsigned char addr_filter;
+ unsigned short crc_type;
+ unsigned char preamble_length;
+ unsigned char preamble;
+ compat_ulong_t data_rate;
+ unsigned char data_bits;
+ unsigned char stop_bits;
+ unsigned char parity;
+};
+
#define MICROGATE_VENDOR_ID 0x13c0
#define SYNCLINK_DEVICE_ID 0x0010
#define MGSCC_DEVICE_ID 0x0020
@@ -276,6 +296,8 @@ struct gpio_desc {
#define MGSL_MAGIC_IOC 'm'
#define MGSL_IOCSPARAMS_IOW(MGSL_MAGIC_IOC,0,struct
_MGSL_PARAMS)
#define MGSL_IOCGPARAMS_IOR(MGSL_MAGIC_IOC,1,struct
_MGSL_PARAMS)
+#define MGSL_IOCSPARAMS32 _IOW(MGSL_MAGIC_IOC,0,struct MGSL_PARAMS32)
+#define MGSL_IOCGPARAMS32 _IOR(MGSL_MAGIC_IOC,1,struct MGSL_PARAMS32)
#define MGSL_IOCSTXIDLE_IO(MGSL_MAGIC_IOC,2)
#define MGSL_IOCGTXIDLE_IO(MGSL_MAGIC_IOC,3)
#define MGSL_IOCTXENABLE _IO(MGSL_MAGIC_IOC,4)
--- a/drivers/char/synclink_gt.c2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/synclink_gt.c2007-05-03 12:40:36.0 -0500
@@ -73,6 +73,7 @@
#include
#include
#include
+#include
#include
#include
@@ -530,6 +531,10 @@ static int set_interface(struct slgt_in
static int set_gpio(struct slgt_info *info, struct gpio_desc __user *gpio);
static int get_gpio(struct slgt_info *info, struct gpio_desc __user *gpio);
static int wait_gpio(struct slgt_info *info, struct gpio_desc __user *gpio);
+#ifdef CONFIG_COMPAT
+static long set_params32(struct slgt_info *info, struct MGSL_PARAMS32 __user
*new_params);
+static long get_params32(struct slgt_info *info, struct MGSL_PARAMS32 __user
*new_params);
+#endif
/*
* driver functions
@@ -1170,6 +1175,55 @@ static int ioctl(struct tty_struct *tty,
return 0;
}
+#ifdef CONFIG_COMPAT
+static long compat_ioctl(struct tty_struct *tty, struct file *file,
+unsigned int cmd, unsigned long arg)
+{
+ struct slgt_info *info = tty->driver_data;
+ int rc = -ENOIOCTLCMD;
+
+ if (sanity_check(info, tty->name, "compat_ioctl"))
+ return -ENODEV;
+ DBGINFO(("%s compat_ioctl() cmd=%08X\n", info->device_name, cmd));
+
+ switch (cmd) {
+
+ case MGSL_IOCSPARAMS32:
+ rc = set_params32(info, compat_ptr(arg));
+ break;
+
+ case MGSL_IOCGPARAMS32:
+ rc = get_params32(info, compat_ptr(arg));
+ break;
+
+ case MGSL_IOCGPARAMS:
+ case MGSL_IOCSPARAMS:
+ case MGSL_IOCGTXIDLE:
+ case MGSL_IOCGSTATS:
+ case MGSL_IOCWAITEVENT:
+ case MGSL_IOCGIF:
+ case MGSL_IOCSGPIO:
+ case MGSL_IOCGGPIO:
+ case MGSL_IOCWAITGPIO:
+ case TIOCGICOUNT:
+ rc = ioctl(tty, file, cmd, (unsigned long)(compat_ptr(arg)));
+ break;
+
+ case MGSL_IOCSTXIDLE:
+ case MGSL_IOCTXENABLE:
+ case MGSL_IOCRXENABLE:
+ case MGSL_IOCTXABORT:
+ case TIOCMIWAIT:
+ case MGSL_IOCSIF:
+ rc = ioctl(tty, file, cmd, arg);
+ break;
+ }
+
+ DBGINFO(("%s compat_ioctl() cmd=%08X rc=%d\n", info->device_name, cmd,
rc));
+ return rc;
+}
+#endif
+
/*
* proc fs support
*/
@@ -2507,6 +2561,60 @@ static int set_params(struct slgt_info *
return 0;
}
+#ifdef CONFIG_COMPAT
+static long get_params32(struct slgt_info *info, struct MGSL_PARAMS32 __user
*user_params)
+{
+ struct MGSL_PARAMS32 tmp_params;
+
+ DBGINFO(("%s get_params32\n", info->device_name));
+ tmp_params.mode= (compat_ulong_t)info->params.mode;
+ tmp_params.loopback= info->params.loopback;
+ tmp_params.flags = info->params.flags;
+ tmp_params.encoding= info->params.encoding;
+ tmp_params.clock_speed = (compat_ulong_t)info->params.clock_speed;
+ tmp_params.addr_filter = info->params.addr_filter;
+ tmp_params.crc_type= info->params.crc_type;
dead CONFIG_ variables under drivers/char
$ ../dead_config.sh drivers/char == COBALT == drivers/char/nvram.c:52:# if defined(CONFIG_COBALT) drivers/char/nvram.c:45:#define COBALT 3 drivers/char/nvram.c:54:#define MACH COBALT drivers/char/nvram.c:79:#if MACH == COBALT drivers/char/nvram.c:607:#if MACH == COBALT drivers/char/nvram.c:776:#endif /* MACH == COBALT */ include/asm-mips/bootinfo.h:83: * Valid machtype for group COBALT == HARD_PPS == drivers/char/amiserial.c:391:#ifdef CONFIG_HARD_PPS drivers/char/ChangeLog:225: the carrier detect line (CONFIG_HARD_PPS). == PSMOUSE == drivers/char/ec3104_keyb.c:89:#ifdef CONFIG_PSMOUSE == REMOTE_DEBUG == drivers/char/serial167.c:180:#ifdef CONFIG_REMOTE_DEBUG drivers/char/serial167.c:531:#ifdef CONFIG_REMOTE_DEBUG drivers/char/serial167.c:656:#ifdef CONFIG_REMOTE_DEBUG drivers/char/serial167.c:2274:#ifdef CONFIG_REMOTE_DEBUG drivers/char/serial167.c:2603:#ifdef CONFIG_REMOTE_DEBUG == XFREE86_VERSION == drivers/char/drm/i810_drm.h:105:#if CONFIG_XFREE86_VERSION < XFREE86_VERSION(4,1,0,0) drivers/char/drm/drm.h:69:#ifndef CONFIG_XFREE86_VERSION drivers/char/drm/drm.h:70:#define CONFIG_XFREE86_VERSION XFREE86_VERSION(4,1,0,0) drivers/char/drm/drm.h:73:#if CONFIG_XFREE86_VERSION < XFREE86_VERSION(4,1,0,0) drivers/char/drm/drm.h:83:#if CONFIG_XFREE86_VERSION >= XFREE86_VERSION(4,1,0,0) drivers/char/drm/r128_drm.h:225:#if CONFIG_XFREE86_VERSION < XFREE86_VERSION(4,1,0,0) drivers/char/drm/r128_drm.h:243:#if CONFIG_XFREE86_VERSION < XFREE86_VERSION(4,1,0,0) drivers/char/drm/r128_drm.h:267:#if CONFIG_XFREE86_VERSION < XFREE86_VERSION(4,1,0,0) drivers/char/drm/r128_drm.h:272:#if CONFIG_XFREE86_VERSION >= XFREE86_VERSION(4,1,0,0) drivers/char/drm/i810_drm.h:105:#if CONFIG_XFREE86_VERSION < XFREE86_VERSION(4,1,0,0) drivers/char/drm/drm.h:66:#define XFREE86_VERSION(major,minor,patch,snap) \ drivers/char/drm/drm.h:70:#define CONFIG_XFREE86_VERSION XFREE86_VERSION(4,1,0,0) drivers/char/drm/drm.h:73:#if CONFIG_XFREE86_VERSION < XFREE86_VERSION(4,1,0,0) drivers/char/drm/drm.h:83:#if CONFIG_XFREE86_VERSION >= XFREE86_VERSION(4,1,0,0) drivers/char/drm/r128_drm.h:225:#if CONFIG_XFREE86_VERSION < XFREE86_VERSION(4,1,0,0) drivers/char/drm/r128_drm.h:243:#if CONFIG_XFREE86_VERSION < XFREE86_VERSION(4,1,0,0) drivers/char/drm/r128_drm.h:267:#if CONFIG_XFREE86_VERSION < XFREE86_VERSION(4,1,0,0) drivers/char/drm/r128_drm.h:272:#if CONFIG_XFREE86_VERSION >= XFREE86_VERSION(4,1,0,0) rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dead CONFIG_ variable under drivers/block
$ ../dead_config.sh drivers/block == MM_MAP_MEMORY == drivers/block/umem.c:109:#ifdef CONFIG_MM_MAP_MEMORY drivers/block/umem.c:876:#ifdef CONFIG_MM_MAP_MEMORY drivers/block/umem.c:907:#ifdef CONFIG_MM_MAP_MEMORY drivers/block/umem.c:925: printk(KERN_INFO "MM%d: MEM area not remapped (CONFIG_MM_MAP_MEMORY not set)\n", drivers/block/umem.c:1095:#ifdef CONFIG_MM_MAP_MEMORY drivers/block/umem.c:1120:#ifdef CONFIG_MM_MAP_MEMORY rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] [Patch 1/3] readahead statistics slimmed down, statistics prereq
The statistics infrastruture used to offer two different counter
implementations: one that just counted the number of samples, and
another one that summed up all samples. Users were required to chose
one, while it is often useful to have both pieces of information. This
patches merges them. Output looks like:
Signed-off-by: Martin Peschke <[EMAIL PROTECTED]>
---
include/linux/statistic.h | 16 +++---
lib/statistic.c | 72 +-
2 files changed, 38 insertions(+), 50 deletions(-)
Index: linux/include/linux/statistic.h
===
--- linux.orig/include/linux/statistic.h
+++ linux/include/linux/statistic.h
@@ -75,8 +75,7 @@ enum statistic_state {
};
enum statistic_type {
- STAT_CNTR_INC,
- STAT_CNTR_PROD,
+ STAT_CNTR,
STAT_UTIL,
STAT_HGRAM_LIN,
STAT_HGRAM_LOG2,
@@ -156,8 +155,7 @@ extern void statistic_add_key(struct sta
* The declarations are needed to allow optimisation of _statistic_add_as()
* at compile time.
*/
-extern void statistic_add_counter_inc(struct statistic *, s64, u64);
-extern void statistic_add_counter_prod(struct statistic *, s64, u64);
+extern void statistic_add_counter(struct statistic *, s64, u64);
extern void statistic_add_util(struct statistic *, s64, u64);
extern void statistic_add_histogram_lin(struct statistic *, s64, u64);
extern void statistic_add_histogram_log2(struct statistic *, s64, u64);
@@ -191,11 +189,8 @@ static inline void _statistic_add_as(int
{
if (stat[i].state == STATISTIC_STATE_ON) {
switch (type) {
- case STAT_CNTR_INC:
- statistic_add_counter_inc([i], value, incr);
- break;
- case STAT_CNTR_PROD:
- statistic_add_counter_prod([i], value, incr);
+ case STAT_CNTR:
+ statistic_add_counter([i], value, incr);
break;
case STAT_UTIL:
statistic_add_util([i], value, incr);
@@ -269,8 +264,7 @@ static inline void _statistic_add_as_key
{
if (stat[i].state == STATISTIC_STATE_ON) {
switch (type) {
- case STAT_CNTR_INC:
- case STAT_CNTR_PROD:
+ case STAT_CNTR:
case STAT_UTIL:
case STAT_HGRAM_LIN:
case STAT_HGRAM_LOG2:
Index: linux/lib/statistic.c
===
--- linux.orig/lib/statistic.c
+++ linux/lib/statistic.c
@@ -740,57 +740,60 @@ static struct file_operations statistic_
/* code concerned with single value statistics */
+struct statistic_entry_counter {
+ u64 num;
+ s64 acc;
+};
+
size_t statistic_size_counter(struct statistic *stat)
{
- return sizeof(u64);
+ return sizeof(struct statistic_entry_counter);
}
static void statistic_reset_counter(struct statistic *stat, void *ptr)
{
- *(u64*)ptr = 0;
-}
+ struct statistic_entry_counter *count = ptr;
-void statistic_add_counter_inc(struct statistic *stat, s64 value, u64 incr)
-{
- *(u64*)percpu_ptr(stat->data, smp_processor_id()) += incr;
+ count->num = 0;
+ count->acc = 0;
}
-EXPORT_SYMBOL_GPL(statistic_add_counter_inc);
-void statistic_add_counter_prod(struct statistic *stat, s64 value, u64 incr)
+void statistic_add_counter(struct statistic *stat, s64 value, u64 incr)
{
- if (unlikely(value < 0))
- value = -value;
- *(u64*)percpu_ptr(stat->data, smp_processor_id()) += value * incr;
-}
-EXPORT_SYMBOL_GPL(statistic_add_counter_prod);
+ struct statistic_entry_counter *count;
-static void statistic_set_counter_inc(struct statistic *stat,
- s64 value, u64 total)
-{
- *(u64*)stat->data = total;
+ count = percpu_ptr(stat->data, smp_processor_id());
+ count->num += incr;
+ count->acc += value * incr;
}
+EXPORT_SYMBOL_GPL(statistic_add_counter);
-static void statistic_set_counter_prod(struct statistic *stat,
- s64 value, u64 total)
+static void statistic_set_counter(struct statistic *stat, s64 value, u64 total)
{
- if (unlikely(value < 0))
- value = -value;
- *(u64*)stat->data = value * total;
+ struct statistic_entry_counter *count = stat->data;
+
+ count->num = total;
+ count->acc = value * total;
}
static void statistic_merge_counter(struct statistic *stat,
- void *dst, void *src)
+ void *_dst, void *_src)
{
- *(u64*)dst += *(u64*)src;
+ struct statistic_entry_counter *dst = _dst, *src = _src;
+
+ dst->num += src->num;
+ dst->acc += src->acc;
}
static void statistic_data_counter(struct statistic *stat, struct seq_file
*seq,
[RFC] [Patch 2/3] readahead statistics slimmed down, adapt zfcp
This patch adapts zfcp to the counter changes in lib/statistics.c.
Signed-off-by: Martin Peschke <[EMAIL PROTECTED]>
---
zfcp_ccw.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/drivers/s390/scsi/zfcp_ccw.c
===
--- linux.orig/drivers/s390/scsi/zfcp_ccw.c
+++ linux/drivers/s390/scsi/zfcp_ccw.c
@@ -137,7 +137,7 @@ static struct statistic_info zfcp_statin
.name = "qdio_outb_full",
.x_unit = "sbals_left",
.y_unit = "",
- .defaults = "type=counter_inc"
+ .defaults = "type=counter"
},
[ZFCP_STAT_A_QO] = {
.name = "qdio_outb",
@@ -155,7 +155,7 @@ static struct statistic_info zfcp_statin
.name = "erp",
.x_unit = "",
.y_unit = "",
- .defaults = "type=counter_inc"
+ .defaults = "type=counter"
}
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] [Patch 3/3] readahead statistics slimmed down
This patch implements the bulk of the existing the adaptive readahead
statistics with lib/statistics.c.
The output format differs somewhat as the the statistics code just emits
lists of items and doesn't do tables. It is feasible to leave
reformating and beautification to some user scripts, if needed. This
patch omits some summary data, most of which can be done in user space
as well.
Sample output (from dd'ing a disk):
cache_miss.total 0 0
cache_miss.initial 0 0
cache_miss.clock 10 10
cache_miss.context 0 0
cache_miss.contexta 0 0
cache_miss.backward 0 0
cache_miss.onthrash 0 0
cache_miss.none 257 257
random_read.total 0 0
random_read.initial 0 0
random_read.clock 9 9
random_read.context 0 0
random_read.contexta 0 0
random_read.backward 0 0
random_read.onthrash 0 0
random_read.none 256 256
io_congestion.total 0 0
io_congestion.initial 0 0
io_congestion.clock 0 0
io_congestion.context 0 0
io_congestion.contexta 0 0
io_congestion.backward 0 0
io_congestion.onthrash 0 0
io_congestion.none 0 0
io_cache_hit.total 0 0
io_cache_hit.initial 0 0
io_cache_hit.clock 43 293
io_cache_hit.context 0 0
io_cache_hit.contexta 2 28
io_cache_hit.backward 0 0
io_cache_hit.onthrash 0 0
io_cache_hit.none 0 0
io_block.total 0 0
io_block.initial 49 49
io_block.clock 13215 13215
io_block.context 0 0
io_block.contexta 4 4
io_block.backward 0 0
io_block.onthrash 0 0
io_block.none 256 256
readahead.total 0 0
readahead.initial 50 149
readahead.clock 7041 1801864
readahead.context 0 0
readahead.contexta 2 484
readahead.backward 0 0
readahead.onthrash 0 0
readahead.none 0 0
readahead_hit.total 0 0
readahead_hit.initial 125 125
readahead_hit.clock 1801884 1801884
readahead_hit.context 0 0
readahead_hit.contexta 484 484
readahead_hit.backward 0 0
readahead_hit.onthrash 0 0
readahead_hit.none 0 0
lookahead.total 0 0
lookahead.initial 3 19
lookahead.clock 7041 1802147
lookahead.context 0 0
lookahead.contexta 2 384
lookahead.backward 0 0
lookahead.onthrash 0 0
lookahead.none 0 0
lookahead_hit.total 0 0
lookahead_hit.initial 1 2
lookahead_hit.clock 7040 1801891
lookahead_hit.context 0 0
lookahead_hit.contexta 2 384
lookahead_hit.backward 0 0
lookahead_hit.onthrash 0 0
lookahead_hit.none 0 0
readahead_mmap.total 0 0
readahead_mmap.initial 0 0
readahead_mmap.clock 0 0
readahead_mmap.context 0 0
readahead_mmap.contexta 0 0
readahead_mmap.backward 0 0
readahead_mmap.onthrash 0 0
readahead_mmap.none 0 0
readahead_eof.total 0 0
readahead_eof.initial 49 133
readahead_eof.clock 2 173
readahead_eof.context 0 0
readahead_eof.contexta 0 0
readahead_eof.backward 0 0
readahead_eof.onthrash 0 0
readahead_eof.none 0 0
readahead_thrash.total 0 0
readahead_thrash.initial 0 0
readahead_thrash.clock 0 0
readahead_thrash.context 0 0
readahead_thrash.contexta 0 0
readahead_thrash.backward 0 0
readahead_thrash.onthrash 0 0
readahead_thrash.none 0 0
readahead_mutilt.total 0 0
readahead_mutilt.initial 0 0
readahead_mutilt.clock 0 0
readahead_mutilt.context 0 0
readahead_mutilt.contexta 0 0
readahead_mutilt.backward 0 0
readahead_mutilt.onthrash 0 0
readahead_mutilt.none 0 0
readahead_rescue.total 0 0
readahead_rescue.initial 0 0
readahead_rescue.clock 0 0
readahead_rescue.context 0 0
readahead_rescue.contexta 0 0
readahead_rescue.backward 0 0
readahead_rescue.onthrash 0 0
readahead_rescue.none 0 0
Signed-off-by: Martin Peschke <[EMAIL PROTECTED]>
---
readahead.c | 170
1 file changed, 34 insertions(+), 136 deletions(-)
Index: linux/mm/readahead.c
===
--- linux.orig/mm/readahead.c
+++ linux/mm/readahead.c
@@ -93,7 +93,6 @@ enum ra_event {
RA_EVENT_READAHEAD_MUTILATE,/* read-ahead mutilated by imbalanced
aging */
RA_EVENT_READAHEAD_RESCUE, /* read-ahead rescued */
- RA_EVENT_READAHEAD_CUBE,
RA_EVENT_COUNT
};
@@ -1784,9 +1783,19 @@ void readahead_cache_hit(struct file_ra_
#ifdef CONFIG_DEBUG_READAHEAD
#include
-#include
#include
-#include
+#include
+
+#define RA_STAT_COUNT (RA_EVENT_COUNT * RA_CLASS_COUNT)
+
+static struct statisticra_stat[RA_STAT_COUNT];
+static struct statistic_info ra_stat_info[RA_STAT_COUNT];
+
+static struct statistic_interface ra_stat_if = {
+ .stat = ra_stat,
+ .info = ra_stat_info,
+ .number = RA_STAT_COUNT
+};
static const char * const ra_class_name[] = {
"total",
@@ -1816,162 +1825,51 @@ static const char * const ra_event_name[
"readahead_rescue"
};
-static unsigned long ra_events[RA_CLASS_COUNT][RA_EVENT_COUNT][2];
+#define RA_STAT_NAME_SIZE 32
+static charra_stat_name[RA_STAT_COUNT][RA_STAT_NAME_SIZE];
+
+static struct statistic_info ra_stat_info_template = {
+ .x_unit = "pages",
+ .y_unit = "request",
+ .defaults = "type=counter",
+};
static void ra_account(struct file_ra_state *ra, enum ra_event e, int pages)
{
enum ra_class
Remove apparently dead CONFIG_NO_ATA_LEGACY code.
Remove the single snippet of code conditional on the non-existent
CONFIG_NO_ATA_LEGACY Kconfig variable.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
i would have mailed a note about this to the ATA maintainer but it
wasn't clear who that was. this is the only dead CONFIG_ variable
under drivers/ata so i figured i'd just submit the patch.
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index d211db6..5a4821a 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -985,16 +985,6 @@ int ata_pci_init_one (struct pci_dev *pdev, struct
ata_port_info **port_info,
mask = (1 << 2) | (1 << 0);
if ((tmp8 & mask) != mask)
legacy_mode = (1 << 3);
-#if defined(CONFIG_NO_ATA_LEGACY)
- /* Some platforms with PCI limits cannot address compat
- port space. In that case we punt if their firmware has
- left a device in compatibility mode */
- if (legacy_mode) {
- printk(KERN_ERR "ata: Compatibility mode ATA is not
supported on this platform, skipping.\n");
- rc = -EOPNOTSUPP;
- goto err_out;
- }
-#endif
}
/* alloc and init host */
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] [Patch 0/3] readahead statistics slimmed down
This patch set simplifies the statistics code of the adaptive readahead feature by using the proposed statistic infrastructure. Patches are against 2.6.21-rc7-mm2. [RFC] [Patch 1/3] readahead statistics slimmed down, statistics prereq [RFC] [Patch 2/3] readahead statistics slimmed down, adapt zfcp [RFC] [Patch 3/3] readahead statistics slimmed down Signed-off-by: Martin Peschke <[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/
