Re: [PATCH 1/5] power: RFC: introduce a new power API

[Andres Salomon]

On Mon, 17 Dec 2007 08:51:23 +0300
Anton Vorontsov <[EMAIL PROTECTED]> wrote:

> Hello Andres, David,
> 
> Firstly, Andres, thank you for the efforts.
> 
> I quite foreseen what exactly you had in mind when we were
> discussing the idea. With patches it's indeed easier to show
> flaws of this approach.
> 
> 
> On Sun, Dec 16, 2007 at 09:36:24PM -0500, David Woodhouse wrote:
> > On Sun, 2007-12-16 at 21:24 -0500, Andres Salomon wrote:
> > > This API has the power_supply drivers device their own device_attribute
> > > list; I find this to be a lot more flexible and cleaner.  
> 
> I don't see how this is more flexible and cleaner. See below.
> 
> > > For example,
> > > rather than having a function with a huge switch statement (as 
> > > olpc_battery
> > > currently has), we have separate callback functions.
> 
> Is this an improvement? Look into ds2760_battery.c. I scared to
> imagine what it will look like after conversion.

Why?  It would not look bad after conversion.  Basically:

static ssize_t ds2760_battery_get_status(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct ds2760_device_info *di = to_ds2760_device_info(psy);
return power_supply_status_str(di->charge_status, buf);
}
static ssize_t ds2760_battery_get_voltage_now(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct ds2760_device_info *di = to_ds2760_device_info(psy);
ds2760_battery_read_status(di);
return sprintf(buf, "%d\n", di->voltage_uV);
}

...an so on.

If I wanted to get really clever, I could do:

#define DS2760_CALLBACK(name, fmt, var)   \
static ssize_t ds2760_battery_get_##name(struct device *dev,  \
struct device_attribute *attr, char *buf) \
{ \
struct ds2760_device_info *di = to_ds2760_device_info(psy); \
ds2760_battery_read_status(di);   \
return sprintf(buf, fmt, var);\
}

DS2760_CALLBACK(voltage_now, "%d\n", di->voltage_uV)
DS2760_CALLBACK(current_now, "%d\n", di->current_uA)

etc.. but, I'm not trying to compress lines of code, I'm trying
to ensure things are readable.

> 
> As for olpc's "huge switch statement", it could be split into
> functions _without_ drastic changes to PSY class. As the bonus,
> you will get _inlining_ of these functions by gcc, because
> there will be just single user of these functions. With
> "exported-via-pointers" functions you can't do that.
> 
> You have tons of similar functions with similar functionality, that
> only differs by the data source. That scheme was in the early PSY
> class I posted here this summer. And I turned it down, fortunately.
> 
> 
> On a bet, I can convert "huge switch statement" to nicely look switch
> statement. It will as nice as ds2760's.
> 
> The problem isn't in the PSY class.
> 

We're still going to be stuck with a huge switch statement.  Yes, it
wouldn't be *as* big, but ds2760_battery.c has a decently sized switch
statement, and olpc_battery.c has even more properties.

The huge switch statement is the least of my worries, though.  Getting
rid of it is just a bonus.


> > > We're not limited
> > > to drivers only being able to pass 'int' and 'char*'s in sysfs,
> 
> You're not limited to "int" and "char *". Anything more than that
> is unnecessary, so far.
> 

See below about the eeprom dump.  Originally, it was desired for this
to be a hex string; after that, binary.  Of course, once I actually
started adding device_attributes to olpc_battery.c, I started wondering;
why not just make *all* the properties device_attributes?  And, what if
I want to show something larger than a signed int?  What if I have a
value that I want to pad with 0's?


> > > we're
> > > not forced to keep a global string around in memory (as is again the
> > > case for olpc_battery's serial number code),
> 
> If battery chip can report strings, then you anyway must keep it in
> the memory. The question is when to allocate memory and when to free
> it. Side question is for how long to keep it.
> 
> Given that that string is small enough (dozen bytes), it's doesn't
> matter for how long we'll allocate it. So, in most cases it's easy
> to answer: allocate at probe, free at remove, so keep it for whole
> battery lifetime. (In contrast, adding tons of functions will waste
> _much more_ space than these dozen bytes!)
> 
> 
> IIRC this is the main difficulty you're facing with current properties
> approach. You've converted whole class to the something different..
> but you didn't show a single user of that change. Sorry, olpc still
> using hard-coded manufacturer string:
> 

Well, no, I was talking about the serial number string.  It's not
upstream yet, it's just in OLPC's repo.

http://dev.laptop.org/git?p=olpc-2.6;a=commitdiff;h=f9b4313060ab9047942707da6d3084f7792e714c

Note bat_serial, 17 bytes sitting around.  That's 

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 17, 2007 1:52 AM, Larry Finger <[EMAIL PROTECTED]> wrote:
>
> One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the 
> former always used a fixed
> rate; whereas mac80211 tries to adjust the bit rate according to the 
> transmission conditions.
> Perhaps it isn't working quite right in your case because of some peculiarity 
> of your AP. IIRC, you
> have an 802.11b AP. If so, you will get the same bit speed behavior for 
> mac80211 as for bcdm43xx by
> issuing a 'sudo iwconfig eth1 rate 11M' command.

I don't know what happened before, but after a reboot, I can't repeat
the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
didn't move the laptop, or the ap, the only thing I can think of that
might have changed is the noise level. FWIW, link quality is
consistently the same or better with b43.

Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and
quickly scales to 11 Mb/s, but I tried setting it manually anyway and
didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as
1 Mb/s and the download speed was the same with all three (around
30-40 kB/s).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] scripts/checkpatch.pl: add a check for the patch level (patch -p)

[Borislav Petkov]

Being bitten by this several times myself here's a quick hack for checking the 
patch
level of the diffs in a patch file. It works only when checkpatch.pl is called
from within the kernel tree.

---
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>

--
 scripts/checkpatch.pl |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 579f50f..b1329fc 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -653,6 +653,18 @@ sub CHK {
}
 }
 
+sub check_patchlevel {
+
+   my ($path) = @_;
+   $path =~ s![^/]*/!!;
+
+   if ($tree) {
+   if (!stat($path)) {
+   WARN("Check the patchlevel (hint: patch option -p)");
+   }
+   }
+}
+
 sub process {
my $filename = shift;
my @lines = @_;
@@ -713,10 +725,16 @@ sub process {
 #extract the filename as it passes
if ($line=~/^\+\+\+\s+(\S+)/) {
$realfile=$1;
+
+   if ($realfile) {
+   check_patchlevel($realfile);
+   }
+
$realfile =~ [EMAIL PROTECTED]/]*/@@;
$in_comment = 0;
next;
}
+
 #extract the line range in the file after the patch is applied
if ($line=~/[EMAIL PROTECTED]@ -\d+(?:,\d+)? \+(\d+)(,(\d+))? 
[EMAIL PROTECTED]@/) {
$is_patch = 1;

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

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Larry Finger]

[EMAIL PROTECTED] wrote:
> On Dec 15, 2007 7:38 AM,  <[EMAIL PROTECTED]> wrote:
>> I'll build latest wireless git without ipv6 late tonight.
> 
> Ok, built and tested, and it's actually faster! Although still not as
> fast as bcm43xx or softmac or whatever the problem is, I was getting a
> steady 200 kB/s (as opposed to 500 kB/s for bcm43xx with the same
> file/server). I'm not sure if it was the absence of ipv6 or the
> commits included in updating my git repository though. Either way, I'm
> fairly happy that I'm out of dial-up speed territory.
> 
> It'd be nice to be able to fully shake loose whatever is causing the
> speed drain - and I call it a drain since sometimes the connection
> starts out much faster, but slowly throttles down to whatever speed
> it'll stick at (used to be 40 kB/s, but now is 200 kB/s). It does seem
> to be like a cap or limit, as in if I download two files, each one
> will download at 100 kB/s.
> 
> If anyone can help I'd really appreciate it. I know that bcm43xx will
> someday be dropped, and when that day comes, it'd be nice if people
> with this hardware have at least similar performance with b43 (myself
> especially).

One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the 
former always used a fixed
rate; whereas mac80211 tries to adjust the bit rate according to the 
transmission conditions.
Perhaps it isn't working quite right in your case because of some peculiarity 
of your AP. IIRC, you
have an 802.11b AP. If so, you will get the same bit speed behavior for 
mac80211 as for bcdm43xx by
issuing a 'sudo iwconfig eth1 rate 11M' command.

Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/2] [RFC] Simple tamper-proof device filesystem.

[penguin-kernel]

Hello.

David Wagner wrote:
> If the attacker gets full administrator-level access on your machine,
> there are a gazillion ways the attacker can prevent other admins from
> logging on. This patch can't prevent that.  It sounds like this patch
> is trying to solve a fundamentally unsolveable problem.

Please be aware that I'm saying "if this filesystem is used with MAC".

Without MAC, an attacker who got root privilege can do whatever he/she want to 
do.
But with MAC, an attacker who got root privilege can't do whatever he/she want 
to do.
Only actions permitted by MAC's policy are permitted for the attacker who got 
root privilege.

I'm not saying that
"this filesystem can prevent attackers from mounting other filesystem over this 
filesystem",
nor "this filesystem can prevent attackers from executing /sbin/iptables or 
/usr/bin/passwd".
They are MAC's business.
What this filesystem can do is "guarantee filename and its attribute".

If MAC(such as SELinux, TOMOYO Linux) allows attackers to
"mount other filesystem over this filesystem", this filesystem is no longer 
tamper-proof.
But as long as MAC prevents attackers from mounting other filesystem over this 
filesystem,
this filesystem can remain tamper-proof.

Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.24-rc5-mm1: problems with cat /proc/kpageflags

[Andrew Morton]

On Sun, 16 Dec 2007 20:26:11 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:

> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Sun, 16 Dec 2007 20:11:49 -0600
> 
> > But as the function doesn't actually show up in your stack trace,
> > something else is probably wrong. So I'd also try commenting out
> > pieces of that function until it started working.
> 
> Some piece of state is being indirectly corrupted and this
> is showing up later in some unrelated operation.
> 
> Can someone send me this kpageflags patch under seperate
> cover?  I'll try figure out why it farts on sparc64.

hm, non trivial.  It's the third-from-last patch in:

maps4-add-proportional-set-size-accounting-in-smaps.patch
maps4-rework-task_size-macros.patch
maps4-rework-task_size-macros-mips-fix.patch
maps4-move-is_swap_pte.patch
maps4-introduce-a-generic-page-walker.patch
maps4-use-pagewalker-in-clear_refs-and-smaps.patch
maps4-simplify-interdependence-of-maps-and-smaps.patch
maps4-move-clear_refs-code-to-task_mmuc.patch
maps4-regroup-task_mmu-by-interface.patch
maps4-add-proc-pid-pagemap-interface.patch
maps4-add-proc-kpagecount-interface.patch
maps4-add-proc-kpageflags-interface.patch
maps4-make-page-monitoring-proc-file-optional.patch
maps4-make-page-monitoring-proc-file-optional-fix.patch

from
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/broken-out

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

Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c

[eric miao]

[ Updated according to Jean's suggestion, thanks ]

>From 5b4d907da17d57ec168643ebd847278e8d7267f9 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Sat, 15 Dec 2007 12:07:26 +0800
Subject: [PATCH] gpiolib: obsolete drivers/i2c/chips/pca9539.c and related files

for the following reasons:

1. there is currently no known users of this driver

2. the functionality of this driver is well supported with the recent
   proposed drivers/gpio/pca9539.c, using GPIO_LIB

Signed-off-by: eric miao <[EMAIL PROTECTED]>
Acked-by: Ben Gardner <[EMAIL PROTECTED]>
---
 Documentation/i2c/chips/pca9539 |   47 -
 drivers/i2c/chips/Kconfig   |   10 --
 drivers/i2c/chips/Makefile  |1 -
 drivers/i2c/chips/pca9539.c |  196 ---
 4 files changed, 0 insertions(+), 254 deletions(-)
 delete mode 100644 Documentation/i2c/chips/pca9539
 delete mode 100644 drivers/i2c/chips/pca9539.c

diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539
deleted file mode 100644
index c4fce6a..000
--- a/Documentation/i2c/chips/pca9539
+++ /dev/null
@@ -1,47 +0,0 @@
-Kernel driver pca9539
-=
-
-Supported chips:
-  * Philips PCA9539
-Prefix: 'pca9539'
-Addresses scanned: 0x74 - 0x77
-Datasheet:
-http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf
-
-Author: Ben Gardner <[EMAIL PROTECTED]>
-
-
-Description

-
-The Philips PCA9539 is a 16 bit low power I/O device.
-All 16 lines can be individually configured as an input or output.
-The input sense can also be inverted.
-The 16 lines are split between two bytes.
-
-
-Sysfs entries
--
-
-Each is a byte that maps to the 8 I/O bits.
-A '0' suffix is for bits 0-7, while '1' is for bits 8-15.
-
-input[01] - read the current value
-output[01]- sets the output value
-direction[01] - direction of each bit: 1=input, 0=output
-invert[01]- toggle the input bit sense
-
-input reads the actual state of the line and is always available.
-The direction defaults to input for all channels.
-
-
-General Remarks

-
-Note that each output, direction, and invert entry controls 8 lines.
-You should use the read, modify, write sequence.
-For example. to set output bit 0 of 1.
-  val=$(cat output0)
-  val=$(( $val | 1 ))
-  echo $val > output0
-
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 2e1c24f..a676f57 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -65,16 +65,6 @@ config SENSORS_PCF8574
  These devices are hard to detect and rarely found on mainstream
  hardware.  If unsure, say N.

-config SENSORS_PCA9539
-   tristate "Philips PCA9539 16-bit I/O port"
-   depends on EXPERIMENTAL
-   help
- If you say yes here you get support for the Philips PCA9539
- 16-bit I/O port.
-
- This driver can also be built as a module.  If so, the module
- will be called pca9539.
-
 config SENSORS_PCF8591
tristate "Philips PCF8591"
depends on EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index ca924e1..bc9e9ca 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -8,7 +8,6 @@ obj-$(CONFIG_DS1682)+= ds1682.o
 obj-$(CONFIG_SENSORS_EEPROM)   += eeprom.o
 obj-$(CONFIG_SENSORS_MAX6875)  += max6875.o
 obj-$(CONFIG_SENSORS_M41T00)   += m41t00.o
-obj-$(CONFIG_SENSORS_PCA9539)  += pca9539.o
 obj-$(CONFIG_SENSORS_PCF8574)  += pcf8574.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
 obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
diff --git a/drivers/i2c/chips/pca9539.c b/drivers/i2c/chips/pca9539.c
deleted file mode 100644
index f43c4e7..000
--- a/drivers/i2c/chips/pca9539.c
+++ /dev/null
@@ -1,196 +0,0 @@
-/*
-pca9539.c - 16-bit I/O port with interrupt and reset
-
-Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; version 2 of the License.
-*/
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/* Addresses to scan */
-static unsigned short normal_i2c[] = {0x74, 0x75, 0x76, 0x77, I2C_CLIENT_END};
-
-/* Insmod parameters */
-I2C_CLIENT_INSMOD_1(pca9539);
-
-enum pca9539_cmd
-{
-   PCA9539_INPUT_0 = 0,
-   PCA9539_INPUT_1 = 1,
-   PCA9539_OUTPUT_0= 2,
-   PCA9539_OUTPUT_1= 3,
-   PCA9539_INVERT_0= 4,
-   PCA9539_INVERT_1= 5,
-   PCA9539_DIRECTION_0 = 6,
-   PCA9539_DIRECTION_1 = 7,
-};
-
-static int pca9539_attach_adapter(struct i2c_adapter *adapter);
-static int pca9539_detect(struct i2c_adapter *adapter, int address, int kind);
-static int pca9539_detach_client(struct i2c_client *client);
-
-/* This is the driver that will be inserted */
-static struct 

Re: [PATCH 2.6.24-rc5-mm 2/3] gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander

[eric miao]

[updated according to David's suggestion to handle the error
of I2C transfer]

>From c9b78718488dadc702f40789bd532d1f1765d76e Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539
GPIO expander

This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.

Note: due to the inaccessibility of the generic IRQ code within modules,
this support is only available if the driver is built-in.

Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
 drivers/gpio/Kconfig   |   11 +++-
 drivers/gpio/pca9539.c |  185 
 2 files changed, 195 insertions(+), 1 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4b54f60..a4f89a6 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -17,7 +17,16 @@ config GPIO_PCA9539
  parts are made by NXP and TI.

  This driver can also be built as a module.  If so, the module
- will be called pca9539.
+ will be called pca9539.  Note: the Generic IRQ support for the
+ chip will only be available if the driver is built-in
+
+config GPIO_PCA9539_GENERIC_IRQ
+   bool "Generic IRQ support for PCA9539"
+   depends on GPIO_PCA9539=y && GENERIC_HARDIRQS
+   help
+ Say yes here to support the Generic IRQ for the PCA9539 on-chip
+ GPIO lines. Only pin-changed IRQs (IRQ_TYPE_EDGE_BOTH) are
+ supported in hardware.

 config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
index fc8bee4..10f9549 100644
--- a/drivers/gpio/pca9539.c
+++ b/drivers/gpio/pca9539.c
@@ -14,6 +14,9 @@

 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 

@@ -33,6 +36,22 @@ struct pca9539_chip {

struct i2c_client *client;
struct gpio_chip gpio_chip;
+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+   /*
+* Note: Generic IRQ is not accessible within module code, the IRQ
+* support will thus _only_ be available if the driver is built-in
+*/
+   int irq;/* IRQ for the chip itself */
+   int irq_start;  /* starting IRQ for the on-chip GPIO lines */
+
+   uint16_t irq_mask;
+   uint16_t irq_falling_edge;
+   uint16_t irq_rising_edge;
+   uint16_t last_input;
+
+   struct irq_chip irq_chip;
+   struct work_struct irq_work;
+#endif
 };

 static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
@@ -155,6 +174,158 @@ static int pca9539_init_gpio(struct pca9539_chip *chip)
return gpiochip_add(gc);
 }

+#ifdef CONFIG_GPIO_PCA9539_GENERIC_IRQ
+/* FIXME: change to schedule_delayed_work() here if reading out of
+ * registers does not reflect the actual pin levels
+ */
+
+static void pca9539_irq_work(struct work_struct *work)
+{
+   struct pca9539_chip *chip;
+   uint16_t input, mask, rising, falling;
+   int ret, i;
+
+   chip = container_of(work, struct pca9539_chip, irq_work);
+
+   ret = pca9539_read_reg(chip, PCA9539_INPUT, );
+   if (ret < 0)
+   return;
+
+   mask = (input ^ chip->last_input) & chip->irq_mask;
+   rising = (input & mask) & chip->irq_rising_edge;
+   falling = (~input & mask) & chip->irq_falling_edge;
+
+   irq_enter();
+
+   for (i = 0; i < NR_PCA9539_GPIOS; i++) {
+   if ((rising | falling) & (1u << i)) {
+   int irq = chip->irq_start + i;
+   struct irq_desc *desc;
+
+   desc = irq_desc + irq;
+   desc_handle_irq(irq, desc);
+   }
+   }
+
+   irq_exit();
+
+   chip->last_input = input;
+}
+
+static void fastcall
+pca9539_irq_demux(unsigned int irq, struct irq_desc *desc)
+{
+   struct pca9539_chip *chip = desc->handler_data;
+
+   desc->chip->mask(chip->irq);
+   desc->chip->ack(chip->irq);
+   schedule_work(>irq_work);
+   desc->chip->unmask(chip->irq);
+}
+
+static void pca9539_irq_mask(unsigned int irq)
+{
+   struct irq_desc *desc = irq_desc + irq;
+   struct pca9539_chip *chip = desc->chip_data;
+
+   chip->irq_mask &= ~(1u << (irq - chip->irq_start));
+}
+
+static void pca9539_irq_unmask(unsigned int irq)
+{
+   struct irq_desc *desc = irq_desc + irq;
+   struct pca9539_chip *chip = desc->chip_data;
+
+   chip->irq_mask |= 1u << (irq - chip->irq_start);
+}
+
+static void pca9539_irq_ack(unsigned int irq)
+{
+   /* unfortunately, we have to provide an empty irq_chip.ack even
+* if we do nothing here, Generic IRQ will complain otherwise
+*/
+}
+
+static int pca9539_irq_set_type(unsigned int irq, unsigned int type)
+{
+   struct irq_desc *desc = irq_desc + irq;
+   struct pca9539_chip *chip = desc->chip_data;
+   uint16_t mask = 1u << (irq - chip->irq_start);
+
+   if 

Re: [PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander

[eric miao]

[ forget about the previous patch, sorry for my carelessness not to
free the chip structure, below is the correct one ]

>From c4be69e8dad28dc75e80b393f9c60f740cca7047 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander

1. use 16-bit register access to simplify the logic, cache OUTPUT
   and DIRECTION registers for fast access

2. platform code is required to setup
   a) the numbering of GPIO for PCA9539 (base and number)
   c) pass "pca9539_platform_data" within "i2c_board_info"

Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).

Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
 drivers/gpio/Kconfig|   10 ++
 drivers/gpio/Makefile   |1 +
 drivers/gpio/pca9539.c  |  260 +++
 include/linux/i2c/pca9539.h |   18 +++
 4 files changed, 289 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpio/pca9539.c
 create mode 100644 include/linux/i2c/pca9539.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu "GPIO Expanders"

 comment "I2C GPIO expanders:"

+config GPIO_PCA9539
+   tristate "PCA9539 16-bit I/O port"
+   depends on I2C
+   help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module.  If so, the module
+ will be called pca9539.
+
 config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
 # gpio support: dedicated expander chips, etc

 obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
 obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..fc8bee4
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,260 @@
+/*
+ *  pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ *  Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ *  Copyright (C) 2007 Marvell International Ltd.
+ *
+ *  Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ *  users).
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define NR_PCA9539_GPIOS   16
+
+#define PCA9539_INPUT  0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION  6
+
+struct pca9539_chip {
+   unsigned gpio_start;
+   uint16_t reg_output;
+   uint16_t reg_direction;
+
+   struct i2c_client *client;
+   struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+   return i2c_smbus_write_word_data(chip->client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+   int ret;
+
+   ret = i2c_smbus_read_word_data(chip->client, reg);
+   if (ret < 0) {
+   dev_err(>client->dev, "failed reading register\n");
+   return ret;
+   }
+
+   *val = (uint16_t)ret;
+   return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+   struct pca9539_chip *chip;
+   uint16_t reg_val;
+   int ret;
+
+   chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+   reg_val = chip->reg_direction | (1u << off);
+   ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+   if (ret)
+   return -EIO;
+
+   chip->reg_direction = reg_val;
+   return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+   unsigned off, int val)
+{
+   struct pca9539_chip *chip;
+   uint16_t reg_val;
+   int ret;
+
+   chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+   /* set output level */
+   if (val)
+   reg_val = chip->reg_output | (1u << off);
+   else
+   reg_val = chip->reg_output & ~(1u << off);
+
+   ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+   if (ret)
+   return -EIO;
+
+   chip->reg_output = reg_val;
+
+   /* then direction */
+   reg_val = chip->reg_direction & ~(1u << off);
+   ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+   if (ret)
+   return -EIO;
+
+   chip->reg_direction = reg_val;
+   return 0;
+}
+
+static int pca9539_gpio_get_value(struct gpio_chip *gc, 

Re: [PATCH 2.6.24-rc5-mm 1/3] gpiolib: basic support for 16-bit PCA9539 GPIO expander

[eric miao]

[ Yup, it's an issue, patch updated as below:]

>From 8de0246423cbbd0c6bb03a20baf61d360930c350 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander

1. use 16-bit register access to simplify the logic, cache OUTPUT
   and DIRECTION registers for fast access

2. platform code is required to setup
   a) the numbering of GPIO for PCA9539 (base and number)
   c) pass "pca9539_platform_data" within "i2c_board_info"

Derived from drivers/i2c/chips/pca9539.c (which has no current known
users).

Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
 drivers/gpio/Kconfig|   10 ++
 drivers/gpio/Makefile   |1 +
 drivers/gpio/pca9539.c  |  254 +++
 include/linux/i2c/pca9539.h |   18 +++
 4 files changed, 283 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpio/pca9539.c
 create mode 100644 include/linux/i2c/pca9539.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index dd9e697..4b54f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -9,6 +9,16 @@ menu "GPIO Expanders"

 comment "I2C GPIO expanders:"

+config GPIO_PCA9539
+   tristate "PCA9539 16-bit I/O port"
+   depends on I2C
+   help
+ Say yes here to support the PCA9539 16-bit I/O port. These
+ parts are made by NXP and TI.
+
+ This driver can also be built as a module.  If so, the module
+ will be called pca9539.
+
 config GPIO_PCF857X
tristate "PCF857x, PCA857x, and PCA967x I2C GPIO expanders"
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 575bb57..d14fc1e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -1,4 +1,5 @@
 # gpio support: dedicated expander chips, etc

 obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
+obj-$(CONFIG_GPIO_PCA9539) += pca9539.o
 obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
diff --git a/drivers/gpio/pca9539.c b/drivers/gpio/pca9539.c
new file mode 100644
index 000..050a378
--- /dev/null
+++ b/drivers/gpio/pca9539.c
@@ -0,0 +1,254 @@
+/*
+ *  pca9539.c - 16-bit I/O port with interrupt and reset
+ *
+ *  Copyright (C) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ *  Copyright (C) 2007 Marvell International Ltd.
+ *
+ *  Derived from drivers/i2c/chips/pca9539.c (which has no current known
+ *  users).
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define NR_PCA9539_GPIOS   16
+
+#define PCA9539_INPUT  0
+#define PCA9539_OUTPUT 2
+#define PCA9539_INVERT 4
+#define PCA9539_DIRECTION  6
+
+struct pca9539_chip {
+   unsigned gpio_start;
+   uint16_t reg_output;
+   uint16_t reg_direction;
+
+   struct i2c_client *client;
+   struct gpio_chip gpio_chip;
+};
+
+static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
+{
+   return i2c_smbus_write_word_data(chip->client, reg, val);
+}
+
+static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
+{
+   int ret;
+
+   ret = i2c_smbus_read_word_data(chip->client, reg);
+   if (ret < 0) {
+   dev_err(>client->dev, "failed reading register\n");
+   return ret;
+   }
+
+   *val = (uint16_t)ret;
+   return 0;
+}
+
+static int pca9539_gpio_direction_input(struct gpio_chip *gc, unsigned off)
+{
+   struct pca9539_chip *chip;
+   uint16_t reg_val;
+   int ret;
+
+   chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+   reg_val = chip->reg_direction | (1u << off);
+   ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+   if (ret)
+   return -EIO;
+
+   chip->reg_direction = reg_val;
+   return 0;
+}
+
+static int pca9539_gpio_direction_output(struct gpio_chip *gc,
+   unsigned off, int val)
+{
+   struct pca9539_chip *chip;
+   uint16_t reg_val;
+   int ret;
+
+   chip = container_of(gc, struct pca9539_chip, gpio_chip);
+
+   /* set output level */
+   if (val)
+   reg_val = chip->reg_output | (1u << off);
+   else
+   reg_val = chip->reg_output & ~(1u << off);
+
+   ret = pca9539_write_reg(chip, PCA9539_OUTPUT, reg_val);
+   if (ret)
+   return -EIO;
+
+   chip->reg_output = reg_val;
+
+   /* then direction */
+   reg_val = chip->reg_direction & ~(1u << off);
+   ret = pca9539_write_reg(chip, PCA9539_DIRECTION, reg_val);
+   if (ret)
+   return -EIO;
+
+   chip->reg_direction = reg_val;
+   return 0;
+}
+
+static int pca9539_gpio_get_value(struct gpio_chip *gc, unsigned off)
+{
+   struct pca9539_chip *chip;
+   uint16_t 

Re: [PATCH 1/5] power: RFC: introduce a new power API

[Anton Vorontsov]

Hello Andres, David,

Firstly, Andres, thank you for the efforts.

I quite foreseen what exactly you had in mind when we were
discussing the idea. With patches it's indeed easier to show
flaws of this approach.


On Sun, Dec 16, 2007 at 09:36:24PM -0500, David Woodhouse wrote:
> On Sun, 2007-12-16 at 21:24 -0500, Andres Salomon wrote:
> > This API has the power_supply drivers device their own device_attribute
> > list; I find this to be a lot more flexible and cleaner.  

I don't see how this is more flexible and cleaner. See below.

> > For example,
> > rather than having a function with a huge switch statement (as olpc_battery
> > currently has), we have separate callback functions.

Is this an improvement? Look into ds2760_battery.c. I scared to
imagine what it will look like after conversion.

As for olpc's "huge switch statement", it could be split into
functions _without_ drastic changes to PSY class. As the bonus,
you will get _inlining_ of these functions by gcc, because
there will be just single user of these functions. With
"exported-via-pointers" functions you can't do that.

You have tons of similar functions with similar functionality, that
only differs by the data source. That scheme was in the early PSY
class I posted here this summer. And I turned it down, fortunately.


On a bet, I can convert "huge switch statement" to nicely look switch
statement. It will as nice as ds2760's.

The problem isn't in the PSY class.

> > We're not limited
> > to drivers only being able to pass 'int' and 'char*'s in sysfs,

You're not limited to "int" and "char *". Anything more than that
is unnecessary, so far.

> > we're
> > not forced to keep a global string around in memory (as is again the
> > case for olpc_battery's serial number code),

If battery chip can report strings, then you anyway must keep it in
the memory. The question is when to allocate memory and when to free
it. Side question is for how long to keep it.

Given that that string is small enough (dozen bytes), it's doesn't
matter for how long we'll allocate it. So, in most cases it's easy
to answer: allocate at probe, free at remove, so keep it for whole
battery lifetime. (In contrast, adding tons of functions will waste
_much more_ space than these dozen bytes!)


IIRC this is the main difficulty you're facing with current properties
approach. You've converted whole class to the something different..
but you didn't show a single user of that change. Sorry, olpc still
using hard-coded manufacturer string:

+static ssize_t olpc_bat_manufacturer(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   int ret;
+   uint8_t ec_byte;
+
+   ret = olpc_bat_get_status(_byte);
+   if (ret)
+   return ret;
+
+   ec_byte = BAT_ADDR_MFR_TYPE;
+   ret = olpc_ec_cmd(EC_BAT_EEPROM, _byte, 1, _byte, 1);
+   if (ret)
+   return ret;

+   switch (ec_byte >> 4) {
+   case 1:
+   strcpy(buf, "Gold Peak");
break;
+   case 2:
+   strcpy(buf, "BYD");
break;
+   default:
+   strcpy(buf, "Unknown");
break;
+   }
+
+   return ret;
+}

In other words: all these strings can and should be static. Why
spend cpu cycles on strcpy'ing things that can be not strcpy'ed?

I don't see S/N function. I'm sure it could be implemented easily
using today's properties approach.

> > we don't have ordering
> > restrictions w/ the return value being interpreted based upon where it's
> > located in the array... etc.  

What exact "restrictions" you're talking about? There are no
restrictions per se.

> > The other API seems to encourage driver
> > authors to get their custom sysfs knobs into the list of sysfs knobs, and
> > this one doesn't.

Yes, API is encouraging to add knobs, but not just any knobs. Only
ones that make sense as a property of a PSY (opposite to some kind
property of PSY driver itself). The count of such properties is
limited, physically.

I'm recalling question about raw data. No, PSY class isn't for raw
data you're getting from the firmware. Implement driver-specific
binary attribute, that will contain device-specific raw data.
Ideally, you should not export raw data at all (though, good idea
is to export them into the debugfs).

> > If there is interest in this API, I'll convert the rest of the power_supply
> > drivers over to it and resubmit patches.
> 
> Looks sane enough to me.

Heh..

> If Anton has no objections, I'll merge it.

Sorry, lots of objections.

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/2] [RFC] Simple tamper-proof device filesystem.

[David Newall]

Tetsuo Handa wrote:

If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...]


Bob can't do that.  Only root can.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.

[Aggrwal Poonam]

Thanks Stephen for your comments.
I have gone through them.
Shall incorporate them and repost the patch.

Sorry for late reply as I was on leave for the last week. 


With Regards
Poonam 
 
 

-Original Message-
From: Stephen Rothwell [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 11, 2007 5:49 AM
To: Aggrwal Poonam
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
[EMAIL PROTECTED]; Gala Kumar; [EMAIL PROTECTED]; Barkowski
Michael; Cutler Richard; Kalra Ashish
Subject: Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for
MPC8323ERDB.Also includes related QE changes.

On Mon, 10 Dec 2007 17:39:22 +0530 (IST) Poonam_Aggrwal-b10812
<[EMAIL PROTECTED]> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -149,22 +149,116 @@ EXPORT_SYMBOL(qe_issue_cmd);
>   */
>  static unsigned int brg_clk = 0;
>  
> -unsigned int get_brg_clk(void)
> +u32 get_brg_clk(enum qe_clock brgclk, enum qe_clock *brg_source)
>  {
> - struct device_node *qe;
> - if (brg_clk)
> - return brg_clk;
> + struct device_node *qe, *brg, *clocks;
> + enum qe_clock brg_src;
> + u32 brg_input_freq = 0;
> + u32 brg_num;
> + const unsigned int *prop;
>  
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> + *brg_source = 0;
> +
> + brg_num = brgclk - QE_BRG1;
> + brg = of_find_compatible_node(NULL, NULL, "fsl,cpm-brg");
> + if (brg) {
>   unsigned int size;
> - const u32 *prop = of_get_property(qe, "brg-frequency",
);
> - brg_clk = *prop;
> - of_node_put(qe);
> - };
> + prop = of_get_property(brg,
> + "fsl,brg-sources", );
> +
> + brg_src = *(prop + brg_num);

You should probably sanity check that prop is not NULL and points to
something large enough.

You don't use brg after here, so the "of_node_put(brg)" could go here to
save putting it in multiple places later.  Also, currently there are
paths through the following code that do not do the of_node_put(brg).

> + if (brg_src == 0) {
> + *brg_source = 0;
> + if (brg_clk > 0) {
> + of_node_put(brg);
> + return brg_clk;
> + }
> + qe = of_find_node_by_type(NULL, "qe");
> + if (qe) {
> + unsigned int size;
> + prop = of_get_property
> + (qe, "brg-frequency",
);
> + of_node_put(qe);
> + of_node_put(brg);
> + return *prop;

NULL check here (yes, I know that the old code didn't check).

> + }
> + } else {
> + *brg_source = brg_src + QE_CLK1 - 1;
> + clocks = of_find_compatible_node(NULL, NULL,
> +
"fsl,cpm-clocks");
> + prop = of_get_property(clocks,
> + "#clock-cells", );
> + /*
> +  * clock-cells = 1 only supported right now.
> +  */
> + if (*prop != 1)

Again check for NULL (and possibly size).

> + return 0;
> + prop = of_get_property(clocks,
> + "clock-frequency",
);
> +
> + brg_input_freq = *(prop+(brg_src - 1));

And again.

> + of_node_put(clocks);
> + of_node_put(brg);
> + return brg_input_freq;
> + }
> + }
>   return brg_clk;
>  }
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 1.0.0.0 DNS replies for many domain names (network)

[Amogh Hooshdar]

I fixed this by installing bind9 which has named server. After
installing bind9, I used the default configuration, which understands
DNS  type queries and uses the root name servers and other servers
for resolution.

On Dec 17, 2007 10:21 AM, Vaidyanathan Srinivasan
<[EMAIL PROTECTED]> wrote:
> * Amogh Hooshdar <[EMAIL PROTECTED]> [2007-12-14 17:20:17]:
>
> > I am having a strange problem with Debian Etch 4.0 (both 64-bit and
> > 32-bit) using 2.6.18 kernel. Most websites do not open with browser,
> > Pidgin and most other GUI applicatoins. but I am able to ping them
> > fine. I am also able to do nslookup properly. When I tried to
> > investigate it with Wireshark net sniffer, I observed the following.
> >
> > PROBLEM WITH 2.6.18
> > Say, I try to open www.google.com, browser sends DNS query for
> > www.google.com to my DNS server which is correctly configured in
> > resolv.conf. It replies with the correct IP address. www.google.com
> > redirects the browser to www.google.co.in. browser sends a DNS query
> > again for www.google.co.in and the DNS server replies with 1.0.0.0
> > which obviously is the wrong address.
>
> I had this problem on Debian 4.0 and it was due to bug in the DSL
> router.  I had DNS server set to 192.168.1.1 that is my DSL router
> that holds the real DNS IP and forwards the DNS lookup request.
>
> Once in a while the DNS proxy server will give out 1.0.0.0.  The
> solution I used was to find the real DNS server and fill it in
> resolv.conf  This avoids the DNS proxy on the router and then problem
> went away.
>
> https://bugs.launchpad.net/ubuntu/+bug/81057
>
> --Vaidy
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ecryptfs: fix fsx data corruption problems

[Eric Sandeen]

ecryptfs in 2.6.24-rc3 wasn't surviving fsx for me at all,
dying after 4 ops.  Generally, encountering problems with stale
data and improperly zeroed pages.  An extending truncate + write
for example would expose stale data.

With the changes below I got to a million ops and beyond with all
mmap ops disabled - mmap still needs work.  (A version of this
patch on a RHEL5 kernel ran for over 110 million fsx ops)

I added a few comments as well, to the best of my understanding
as I read through the code.

Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>

---


Index: linux-2.6.24-rc3/fs/ecryptfs/mmap.c
===
--- linux-2.6.24-rc3.orig/fs/ecryptfs/mmap.c
+++ linux-2.6.24-rc3/fs/ecryptfs/mmap.c
@@ -263,14 +263,13 @@ out:
return 0;
 }
 
+/* This function must zero any hole we create */
 static int ecryptfs_prepare_write(struct file *file, struct page *page,
  unsigned from, unsigned to)
 {
int rc = 0;
+   loff_t prev_page_end_size;
 
-   if (from == 0 && to == PAGE_CACHE_SIZE)
-   goto out;   /* If we are writing a full page, it will be
-  up to date. */
if (!PageUptodate(page)) {
rc = ecryptfs_read_lower_page_segment(page, page->index, 0,
  PAGE_CACHE_SIZE,
@@ -283,22 +282,32 @@ static int ecryptfs_prepare_write(struct
} else
SetPageUptodate(page);
}
-   if (page->index != 0) {
-   loff_t end_of_prev_pg_pos =
-   (((loff_t)page->index << PAGE_CACHE_SHIFT) - 1);
 
-   if (end_of_prev_pg_pos > i_size_read(page->mapping->host)) {
+   prev_page_end_size = ((loff_t)page->index << PAGE_CACHE_SHIFT);
+
+   /*
+* If creating a page or more of holes, zero them out via truncate.
+* Note, this will increase i_size.
+*/
+   if (page->index != 0) {
+   if (prev_page_end_size > i_size_read(page->mapping->host)) {
rc = ecryptfs_truncate(file->f_path.dentry,
-  end_of_prev_pg_pos);
+  prev_page_end_size);
if (rc) {
printk(KERN_ERR "Error on attempt to "
   "truncate to (higher) offset [%lld];"
-  " rc = [%d]\n", end_of_prev_pg_pos, rc);
+  " rc = [%d]\n", prev_page_end_size, rc);
goto out;
}
}
-   if (end_of_prev_pg_pos + 1 > i_size_read(page->mapping->host))
-   zero_user_page(page, 0, PAGE_CACHE_SIZE, KM_USER0);
+   }
+   /*
+* Writing to a new page, and creating a small hole from start of page?
+* Zero it out.
+*/
+   if ((i_size_read(page->mapping->host) == prev_page_end_size) &&
+   (from != 0)) {
+   zero_user_page(page, 0, PAGE_CACHE_SIZE, KM_USER0);
}
 out:
return rc;
Index: linux-2.6.24-rc3/fs/ecryptfs/read_write.c
===
--- linux-2.6.24-rc3.orig/fs/ecryptfs/read_write.c
+++ linux-2.6.24-rc3/fs/ecryptfs/read_write.c
@@ -124,6 +124,10 @@ int ecryptfs_write(struct file *ecryptfs
loff_t pos;
int rc = 0;
 
+   /*
+* if we are writing beyond current size, then start pos
+* at the current size - we'll fill in zeros from there.
+*/
if (offset > ecryptfs_file_size)
pos = ecryptfs_file_size;
else
@@ -137,6 +141,7 @@ int ecryptfs_write(struct file *ecryptfs
if (num_bytes > total_remaining_bytes)
num_bytes = total_remaining_bytes;
if (pos < offset) {
+   /* remaining zeros to write, up to destination offset */
size_t total_remaining_zeros = (offset - pos);
 
if (num_bytes > total_remaining_zeros)
@@ -167,17 +172,27 @@ int ecryptfs_write(struct file *ecryptfs
}
}
ecryptfs_page_virt = kmap_atomic(ecryptfs_page, KM_USER0);
+
+   /*
+* pos: where we're now writing, offset: where the request was
+* If current pos is before request, we are filling zeros
+* If we are at or beyond request, we are writing the *data*
+* If we're in a fresh page beyond eof, zero it in either case
+*/
+   if (pos < offset || !start_offset_in_page) {
+   /* We are extending past the previous end of the file.
+* Fill in zero values to the end of the page */
+   

/sys/block [was: [PATCH 007 of 7] md: Get name for block device in sysfs]

[Michael Tokarev]

Kay Sievers wrote:
> On Mon, 2007-12-17 at 09:43 +1100, Neil Brown wrote:
>> On Saturday December 15, [EMAIL PROTECTED] wrote:
>>> On Dec 14, 2007 7:26 AM, NeilBrown <[EMAIL PROTECTED]> wrote:
 Given an fd on a block device, returns a string like

 /block/sda/sda1

 which can be used to find related information in /sys.
>> 
>>> As pointed out to when you came up with the idea, we can't do this. A 
>>> devpath
>>> is a path to the device and will not necessarily start with "/block" for 
>>> block
>>> devices. It may start with "/devices" and can be much longer than
>>> BDEVNAME_SIZE*2  + 10.
>> When you say "will not necessarily" can I take that to mean that it
>> currently does, but it might (will) change??
> 
> It's in -mm. The devpath for all block devices, like for all other
> devices, will start with /devices/* if !SYSFS_DEPRECATED.

This is the second time I come across this (planned?) change, and for
the second time I can't understand it.

How to distinguish char devices from block devices in sysfs?
Is the only way to read a symlink `subsystem' in the device
directory?

For now, I've a shell code (used heavily in numerous places),
which looks like this:

  function makedev() {
...
case $DEVPATH in
  /block/*) TYPE=b ;;
  *) TYPE=c ;;
esac
...
mknod /dev/$DEV $TYPE $MAJOR $MINOR
  }

The only external process invocation in there is mknod, all
the rest is done using pure shell constructs.  Is it really
necessary to spawn another process just to read a symlink
now?  It will be almost 2 times slower

(Sure thing this may be rewritten in C, but using shell it's
MUCH easier to customize if necessary.)

Also, /sys/block/ directory is very easy to use currently, --
unlike other /sys/ stuff which is way too deep and often
placed in unknown/unexpected places (and /sys/class/ and
/sys/bus/ directories are changing all the time).

What's the benefit of moving things from /sys/block/ to
/sys/devices/ ?

Thanks.

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] lib: proportion: fix underflow in prop_norm_percpu()

[Jiang zhe]

On Fri, 2007-12-14 at 17:01 +0100, Peter Zijlstra wrote:
> Subject: lib: proportion: fix underflow in prop_norm_percpu()
> 
> Zhe Jiang noticed that its possible to underflow pl->events in
> prop_norm_percpu() when the value returned by percpu_counter_read() is less
> than the error on that read and the period delay > 1. In that case half might
> not trigger the batch increment and the value will be identical on the next
> iteration, causing the same half to be subtracted again and again.
> 
> Fix this by rewriting the division as a single subtraction instead of a
> subtraction loop and using percpu_counter_sum() when the value returned
> by percpu_counter_read() is smaller than the error.
> 
> The latter is still needed if we want pl->events to shrink properly in the
> error region.
> 
> Jiang, can I get a Reviewed-by from you? - if you agree that is :-)
> 
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> Cc: zhejiang <[EMAIL PROTECTED]>
> ---
>  lib/proportions.c |   36 +++-
>  1 file changed, 15 insertions(+), 21 deletions(-)
> 
> Index: linux-2.6/lib/proportions.c
> ===
> --- linux-2.6.orig/lib/proportions.c
> +++ linux-2.6/lib/proportions.c
> @@ -190,6 +190,8 @@ prop_adjust_shift(int *pl_shift, unsigne
>   * PERCPU
>   */
>  
> +#define PROP_BATCH (8*(1+ilog2(nr_cpu_ids)))
> +
>  int prop_local_init_percpu(struct prop_local_percpu *pl)
>  {
>   spin_lock_init(>lock);
> @@ -230,31 +232,23 @@ void prop_norm_percpu(struct prop_global
>  
>   spin_lock_irqsave(>lock, flags);
>   prop_adjust_shift(>shift, >period, pg->shift);
> +
>   /*
>* For each missed period, we half the local counter.
>* basically:
>*   pl->events >> (global_period - pl->period);
> -  *
> -  * but since the distributed nature of percpu counters make division
> -  * rather hard, use a regular subtraction loop. This is safe, because
> -  * the events will only every be incremented, hence the subtraction
> -  * can never result in a negative number.
>*/
> - while (pl->period != global_period) {
> - unsigned long val = percpu_counter_read(>events);
> - unsigned long half = (val + 1) >> 1;
> -
> - /*
> -  * Half of zero won't be much less, break out.
> -  * This limits the loop to shift iterations, even
> -  * if we missed a million.
> -  */
> - if (!val)
> - break;
> -
> - percpu_counter_add(>events, -half);
> - pl->period += period;
> - }
> + period = (global_period - pl->period) >> (pg->shift - 1);
> + if (period < BITS_PER_LONG) {
> + s64 val = percpu_counter_read(>events);
> +
> + if (val < (nr_cpu_ids * PROP_BATCH))
> + val = percpu_counter_sum(>events);
> +
> + __percpu_counter_add(>events, -val + (val >> period), 
> PROP_BATCH);
> + } else
> + percpu_counter_set(>events, 0);
> +
>   pl->period = global_period;
>   spin_unlock_irqrestore(>lock, flags);
>  }
> @@ -267,7 +261,7 @@ void __prop_inc_percpu(struct prop_descr
>   struct prop_global *pg = prop_get_global(pd);
>  
>   prop_norm_percpu(pg, pl);
> - percpu_counter_add(>events, 1);
> + __percpu_counter_add(>events, 1, PROP_BATCH);
>   percpu_counter_add(>events, 1);
>   prop_put_global(pd, pg);
>  }
> 

Reviewed-by: Jiang Zhe <[EMAIL PROTECTED]>

Thanks!



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

[PATCH] NET: ns83820.c remove fastcall macro

[Harvey Harrison]

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Dave, this is the remainder of the FASTCALL/fastcall removal
patch that is not already in your tree.
Generated against net-2.6.25.git

 drivers/net/ns83820.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ns83820.c b/drivers/net/ns83820.c
index 3652c6c..b42c05f 100644
--- a/drivers/net/ns83820.c
+++ b/drivers/net/ns83820.c
@@ -611,8 +611,7 @@ static inline int rx_refill(struct net_device *ndev, gfp_t 
gfp)
return i ? 0 : -ENOMEM;
 }
 
-static void rx_refill_atomic(struct net_device *ndev);
-static void fastcall rx_refill_atomic(struct net_device *ndev)
+static void rx_refill_atomic(struct net_device *ndev)
 {
rx_refill(ndev, GFP_ATOMIC);
 }
@@ -633,7 +632,7 @@ static inline void clear_rx_desc(struct ns83820 *dev, 
unsigned i)
build_rx_desc(dev, dev->rx_info.descs + (DESC_SIZE * i), 0, 0, 
CMDSTS_OWN, 0);
 }
 
-static void fastcall phy_intr(struct net_device *ndev)
+static void phy_intr(struct net_device *ndev)
 {
struct ns83820 *dev = PRIV(ndev);
static const char *speeds[] = { "10", "100", "1000", "1000(?)", "1000F" 
};
@@ -831,7 +830,7 @@ static void ns83820_cleanup_rx(struct ns83820 *dev)
}
 }
 
-static void fastcall ns83820_rx_kick(struct net_device *ndev)
+static void ns83820_rx_kick(struct net_device *ndev)
 {
struct ns83820 *dev = PRIV(ndev);
/*if (nr_rx_empty(dev) >= NR_RX_DESC/4)*/ {
@@ -852,7 +851,7 @@ static void fastcall ns83820_rx_kick(struct net_device 
*ndev)
 /* rx_irq
  *
  */
-static void fastcall rx_irq(struct net_device *ndev)
+static void rx_irq(struct net_device *ndev)
 {
struct ns83820 *dev = PRIV(ndev);
struct rx_info *info = >rx_info;
-- 
1.5.4.rc0.1083.gf568



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

Re: div64: Rework 64-bit type safety checks in do_div().

[Al Viro]

On Mon, Dec 17, 2007 at 12:20:19PM +0900, Paul Mundt wrote:
> (Adding Ingo to CC regarding kernel/lockdep_proc.c..)
 
> That seems to be an accurate asessment, yes. If do_div(s64, ...) is buggy
> behaviour, then the current check is fine, and the callsites should be
> corrected. Though if there's code in-tree that relies on s64 do_div, that 
> seems
> to be a more problematic issue.

It is a bug and the only existing callers that manage to work are those that
make sure that signed value is positive.  Still asking for trouble...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 1.0.0.0 DNS replies for many domain names (network)

[Vaidyanathan Srinivasan]

* Amogh Hooshdar <[EMAIL PROTECTED]> [2007-12-14 17:20:17]:

> I am having a strange problem with Debian Etch 4.0 (both 64-bit and
> 32-bit) using 2.6.18 kernel. Most websites do not open with browser,
> Pidgin and most other GUI applicatoins. but I am able to ping them
> fine. I am also able to do nslookup properly. When I tried to
> investigate it with Wireshark net sniffer, I observed the following.
> 
> PROBLEM WITH 2.6.18
> Say, I try to open www.google.com, browser sends DNS query for
> www.google.com to my DNS server which is correctly configured in
> resolv.conf. It replies with the correct IP address. www.google.com
> redirects the browser to www.google.co.in. browser sends a DNS query
> again for www.google.co.in and the DNS server replies with 1.0.0.0
> which obviously is the wrong address.

I had this problem on Debian 4.0 and it was due to bug in the DSL
router.  I had DNS server set to 192.168.1.1 that is my DSL router
that holds the real DNS IP and forwards the DNS lookup request.

Once in a while the DNS proxy server will give out 1.0.0.0.  The
solution I used was to find the real DNS server and fill it in
resolv.conf  This avoids the DNS proxy on the router and then problem
went away.

https://bugs.launchpad.net/ubuntu/+bug/81057

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

kconfig: Obey KCONFIG_ALLCONFIG choices with randconfig.

[Paul Mundt]

Currently when using KCONFIG_ALLCONFIG with randconfig the choice options
are clobbered. As recommended by Roman, this adds an is_new test to see
whether to select a new option or obey the existing one.

This is a resend of the earlier patch a couple of weeks ago, since there
was no reply. Original thread is at http://lkml.org/lkml/2007/11/28/94

It would be nice to have this for 2.6.24.

Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>

---

 scripts/kconfig/conf.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index a38787a..8d6f174 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -374,7 +374,8 @@ static int conf_choice(struct menu *menu)
continue;
break;
case set_random:
-   def = (random() % cnt) + 1;
+   if (is_new)
+   def = (random() % cnt) + 1;
case set_default:
case set_yes:
case set_mod:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [NET]: Remove FASTCALL/fastcall macros

[David Miller]

From: Harvey Harrison <[EMAIL PROTECTED]>
Date: Sun, 16 Dec 2007 20:16:25 -0800

> X86_32 was the last user of the FASTCALL/fastcall macros, now that it
> uses regparm(3) by default, these macros expand to nothing.
> 
> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
> ---
> Dave, this is a wrap-up of my patch in your net-2.6.25.git with
> the build breakage fix from Andrew Morton included.  This also
> chops the fastcall macro which is also now empty.

If only it applied:

[EMAIL PROTECTED]:~/src/GIT/net-2.6.25$ pcheck diff
+ git apply --check --whitespace=error-all diff
error: patch failed: drivers/net/ns83820.c:611
error: drivers/net/ns83820.c: patch does not apply
error: patch failed: include/net/bluetooth/rfcomm.h:252
error: include/net/bluetooth/rfcomm.h: patch does not apply
error: patch failed: include/net/sock.h:774
error: include/net/sock.h: patch does not apply
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-2.6.25 8/8] Remove unused IPV4TYPE macros

[David Miller]

From: Joe Perches <[EMAIL PROTECTED]>
Date: Sun, 16 Dec 2007 20:01:06 -0800

> On Sun, 2007-12-16 at 13:48 -0800, David Miller wrote:
> > From: Joe Perches <[EMAIL PROTECTED]>
> > Date: Thu, 13 Dec 2007 15:39:01 -0800
> > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> > Applied, thanks for doing this work Joe.
> 
> I broke the parisc build.  Bad Joe...
> 
> Here's the patch:
> 
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>

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

Re: 2.6.24-rc5-mm1: problems with cat /proc/kpageflags

[David Miller]

From: Matt Mackall <[EMAIL PROTECTED]>
Date: Sun, 16 Dec 2007 20:11:49 -0600

> But as the function doesn't actually show up in your stack trace,
> something else is probably wrong. So I'd also try commenting out
> pieces of that function until it started working.

Some piece of state is being indirectly corrupted and this
is showing up later in some unrelated operation.

Can someone send me this kpageflags patch under seperate
cover?  I'll try figure out why it farts on sparc64.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [NET]: Remove FASTCALL/fastcall macros

[Harvey Harrison]

X86_32 was the last user of the FASTCALL/fastcall macros, now that it
uses regparm(3) by default, these macros expand to nothing.

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Dave, this is a wrap-up of my patch in your net-2.6.25.git with
the build breakage fix from Andrew Morton included.  This also
chops the fastcall macro which is also now empty.

Original: 172f5efbe9150a82e8d5b0562bbe128492ac820e
Buildfix: 451ff1232b1ff3d32635ea4844ef0d1376460c21

 drivers/net/ns83820.c  |   12 
 include/net/bluetooth/rfcomm.h |4 ++--
 include/net/sock.h |4 ++--
 net/bluetooth/rfcomm/core.c|4 ++--
 net/core/dev.c |2 +-
 net/core/sock.c|4 ++--
 6 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ns83820.c b/drivers/net/ns83820.c
index ea71f6d..b42c05f 100644
--- a/drivers/net/ns83820.c
+++ b/drivers/net/ns83820.c
@@ -611,8 +611,7 @@ static inline int rx_refill(struct net_device *ndev, gfp_t 
gfp)
return i ? 0 : -ENOMEM;
 }
 
-static void FASTCALL(rx_refill_atomic(struct net_device *ndev));
-static void fastcall rx_refill_atomic(struct net_device *ndev)
+static void rx_refill_atomic(struct net_device *ndev)
 {
rx_refill(ndev, GFP_ATOMIC);
 }
@@ -633,8 +632,7 @@ static inline void clear_rx_desc(struct ns83820 *dev, 
unsigned i)
build_rx_desc(dev, dev->rx_info.descs + (DESC_SIZE * i), 0, 0, 
CMDSTS_OWN, 0);
 }
 
-static void FASTCALL(phy_intr(struct net_device *ndev));
-static void fastcall phy_intr(struct net_device *ndev)
+static void phy_intr(struct net_device *ndev)
 {
struct ns83820 *dev = PRIV(ndev);
static const char *speeds[] = { "10", "100", "1000", "1000(?)", "1000F" 
};
@@ -832,8 +830,7 @@ static void ns83820_cleanup_rx(struct ns83820 *dev)
}
 }
 
-static void FASTCALL(ns83820_rx_kick(struct net_device *ndev));
-static void fastcall ns83820_rx_kick(struct net_device *ndev)
+static void ns83820_rx_kick(struct net_device *ndev)
 {
struct ns83820 *dev = PRIV(ndev);
/*if (nr_rx_empty(dev) >= NR_RX_DESC/4)*/ {
@@ -854,8 +851,7 @@ static void fastcall ns83820_rx_kick(struct net_device 
*ndev)
 /* rx_irq
  *
  */
-static void FASTCALL(rx_irq(struct net_device *ndev));
-static void fastcall rx_irq(struct net_device *ndev)
+static void rx_irq(struct net_device *ndev)
 {
struct ns83820 *dev = PRIV(ndev);
struct rx_info *info = >rx_info;
diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
index 25aa575..98ec7a3 100644
--- a/include/net/bluetooth/rfcomm.h
+++ b/include/net/bluetooth/rfcomm.h
@@ -252,8 +252,8 @@ static inline void rfcomm_dlc_put(struct rfcomm_dlc *d)
rfcomm_dlc_free(d);
 }
 
-extern void FASTCALL(__rfcomm_dlc_throttle(struct rfcomm_dlc *d));
-extern void FASTCALL(__rfcomm_dlc_unthrottle(struct rfcomm_dlc *d));
+extern void __rfcomm_dlc_throttle(struct rfcomm_dlc *d);
+extern void __rfcomm_dlc_unthrottle(struct rfcomm_dlc *d);
 
 static inline void rfcomm_dlc_throttle(struct rfcomm_dlc *d)
 {
diff --git a/include/net/sock.h b/include/net/sock.h
index f415992..803d8f2 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -774,14 +774,14 @@ do {  
\
lockdep_init_map(&(sk)->sk_lock.dep_map, (name), (key), 0); \
 } while (0)
 
-extern void FASTCALL(lock_sock_nested(struct sock *sk, int subclass));
+extern void lock_sock_nested(struct sock *sk, int subclass);
 
 static inline void lock_sock(struct sock *sk)
 {
lock_sock_nested(sk, 0);
 }
 
-extern void FASTCALL(release_sock(struct sock *sk));
+extern void release_sock(struct sock *sk);
 
 /* BH context may only use the following locking interface. */
 #define bh_lock_sock(__sk) spin_lock(&((__sk)->sk_lock.slock))
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index d3e4e18..0c2c937 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -465,7 +465,7 @@ int rfcomm_dlc_send(struct rfcomm_dlc *d, struct sk_buff 
*skb)
return len;
 }
 
-void fastcall __rfcomm_dlc_throttle(struct rfcomm_dlc *d)
+void __rfcomm_dlc_throttle(struct rfcomm_dlc *d)
 {
BT_DBG("dlc %p state %ld", d, d->state);
 
@@ -476,7 +476,7 @@ void fastcall __rfcomm_dlc_throttle(struct rfcomm_dlc *d)
rfcomm_schedule(RFCOMM_SCHED_TX);
 }
 
-void fastcall __rfcomm_dlc_unthrottle(struct rfcomm_dlc *d)
+void __rfcomm_dlc_unthrottle(struct rfcomm_dlc *d)
 {
BT_DBG("dlc %p state %ld", d, d->state);
 
diff --git a/net/core/dev.c b/net/core/dev.c
index 06615df..d48c9cf 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2143,7 +2143,7 @@ static int process_backlog(struct napi_struct *napi, int 
quota)
  *
  * The entry's receive function will be scheduled to run
  */
-void fastcall __napi_schedule(struct napi_struct *n)
+void __napi_schedule(struct napi_struct *n)
 {
unsigned long flags;
 

Re: [PATCH] initrd: Fix virtual/physical mix-up in overwrite test

[Roman Zippel]

Hi,

On Sunday 16 December 2007, Geert Uytterhoeven wrote:

> --- a/init/main.c
> +++ b/init/main.c
> @@ -598,9 +598,9 @@ asmlinkage void __init start_kernel(void
>
>  #ifdef CONFIG_BLK_DEV_INITRD
>   if (initrd_start && !initrd_below_start_ok &&
> - initrd_start < min_low_pfn << PAGE_SHIFT) {
> + virt_to_pfn(initrd_start) < min_low_pfn) {
>   printk(KERN_CRIT "initrd overwritten (0x%08lx < 0x%08lx) - "
> - "disabling it.\n",initrd_start,min_low_pfn << PAGE_SHIFT);
> + "disabling it.\n", virt_to_pfn(initrd_start), min_low_pfn);
>   initrd_start = 0;
>   }
>  #endif

BTW this is some really old code, so another option might be to remove this 
check completely as the same check is already done via bootmem.

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: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

[H. Peter Anvin]

Rene Herman wrote:

On 17-12-07 03:05, H. Peter Anvin wrote:

Incidentally, I had the thought earlier today that port 0xf0 might be 
a suitable delay port.  It is used only by the 387-emulating-a-287 
hack for IRQ 13, which Linux doesn't use on 486+.


[EMAIL PROTECTED]:~/src/port80$ su -c ./port80
cycles: out 2400, in 2400
[EMAIL PROTECTED]:~/src/port80$ su -c ./portf0
cycles: out 2400, in 2400

(Duron 1300)

I suppose you mean using it instead of port 0x80 always and not just as 
an alternate port? For the latter 0xed is alright I guess...




FWIW, the criterion used in the kernel for when to use IRQ 13 is:

/*
 * External FPU? Set up irq13 if so, for
 * original braindamaged IBM FERR coupling.
 */
if (boot_cpu_data.hard_math && !cpu_has_fpu)
^^^
setup_irq(FPU_IRQ, _irq);

In that case we can't actually use port 0xF0 (it is, however, safe to 
use it during setup, specifically before we can take our first FPU 
exception.)


-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 net-2.6.25 8/8] Remove unused IPV4TYPE macros

[Joe Perches]

On Sun, 2007-12-16 at 13:48 -0800, David Miller wrote:
> From: Joe Perches <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 15:39:01 -0800
> > Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> Applied, thanks for doing this work Joe.

I broke the parisc build.  Bad Joe...

Here's the patch:

Signed-off-by: Joe Perches <[EMAIL PROTECTED]>

diff --git a/drivers/parisc/led.c b/drivers/parisc/led.c
index a6d6b24..703b85e 100644
--- a/drivers/parisc/led.c
+++ b/drivers/parisc/led.c
@@ -364,7 +364,7 @@ static __inline__ int led_get_net_activity(void)
struct in_device *in_dev = __in_dev_get_rcu(dev);
if (!in_dev || !in_dev->ifa_list)
continue;
-   if (LOOPBACK(in_dev->ifa_list->ifa_local))
+   if (ipv4_is_loopback(in_dev->ifa_list->ifa_local))
continue;
stats = dev->get_stats(dev);
rx_total += stats->rx_packets;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86: provide a DMI based port 0x80 I/O delay override.

[H. Peter Anvin]

Rene Herman wrote:

On 17-12-07 03:05, H. Peter Anvin wrote:

Incidentally, I had the thought earlier today that port 0xf0 might be 
a suitable delay port.  It is used only by the 387-emulating-a-287 
hack for IRQ 13, which Linux doesn't use on 486+.


[EMAIL PROTECTED]:~/src/port80$ su -c ./port80
cycles: out 2400, in 2400
[EMAIL PROTECTED]:~/src/port80$ su -c ./portf0
cycles: out 2400, in 2400

(Duron 1300)

I suppose you mean using it instead of port 0x80 always and not just as 
an alternate port? For the latter 0xed is alright I guess...




Well, we probably should leave the possibility in to use 0x80 -- for one 
thing, we need to use 0x80 on 386, and there is always the possibility 
that the switch will have different timing properties on some or all 
machines.


Note that this doesn't require that a machine actually implements port 
0xf0 for FERR/IGNNE, it just requires that they don't use it for 
something else.


I would be rather inclined to try using port 0xf0 by default as long as 
family > 3[*] (with fallback to port 0x80) at least experimentally (-mm).


We *might* even be able to use port 0xf0 unconditionally in the setup 
code, since we're not using the FPU there (the only FPU instructions in 
the setup code are there to detect the FPU.)


One thing: although I believe most actual implementations of port 0xf0 
implement it as a strobe alone (data is ignored), all documentation I've 
found, including "The Undocumented PC" specifically says "write 0x00 to 
this port."  This *could* mean there are platforms which use other 
values than 0x00 for other hacks.


-hpa


[*] The following statements are equivalent:
- family > 3.
- CR0.NE is settable.
- EFLAGS.AC is settable.

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

Re: div64: Rework 64-bit type safety checks in do_div().

[Paul Mundt]

(Adding Ingo to CC regarding kernel/lockdep_proc.c..)

On Sun, Dec 16, 2007 at 07:04:18PM -0800, Andrew Morton wrote:
> On Mon, 17 Dec 2007 10:48:05 +0900 Paul Mundt <[EMAIL PROTECTED]> wrote:
> > The options are to either 'fix' all callers of do_div() to make sure
> > they're using a uint64_t explicitly, or to update do_div() to make sure
> > that the value is 64-bits, regardless of specific type. Currently
> > everything that uses the generic do_div() causes a warning when using one
> > of 'u64', 'long long', etc. instead of 'uint64_t'.
> 
> u64 and uint64_t should be identical?
> 
Er, yes, that was supposed to be an 's64'. It only applies to sign
mismatch.

> > -/* The unnecessary pointer compare is there
> > - * to check for type safety (n must be 64bit)
> > - */
> > +/* The BUILD_BUG_ON() is there to check for type safety (n must be 64bit) 
> > */
> >  # define do_div(n,base) ({ \
> > uint32_t __base = (base);   \
> > uint32_t __rem; \
> > -   (void)(((typeof((n)) *)0) == ((uint64_t *)0));  \
> > +   BUILD_BUG_ON(sizeof(n) != sizeof(uint64_t));\
> > if (likely(((n) >> 32) == 0)) { \
> > __rem = (uint32_t)(n) % __base; \
> > (n) = (uint32_t)(n) / __base;   \
> 
> The mismatch which I've seen triggering a lot is doing do_div() on an s64
> when it expects a u64.
> 
> And I think that _is_ a bug, isn't it?  do_div(-10, 10) should return -1,
> but as the implementation will convert -10 to  number>, the return value will be wildly wrong?
> 
If it's supposed to be u64 only, then yes, the existing check should be
ok. There are a lot of places (time keeping code, lockdep, etc.) that
operate on signed values though, and from the comments in some places
this seems to be intentional (ie, kernel/lockdep_proc.c has this gem):

static void snprint_time(char *buf, size_t bufsiz, s64 nr)
{
unsigned long rem;

rem = do_div(nr, 1000); /* XXX: do_div_signed */
snprintf(buf, bufsiz, "%lld.%02d", (long long)nr, ((int)rem+5)/10);
}

> I'm thinking that the problem here is that x86's do_div(s64, ...) doesn't
> warn.  So people write wrong code and then the problems only crop up on
> architectures which use asm-generic/div64.h, which does warn?

That seems to be an accurate asessment, yes. If do_div(s64, ...) is buggy
behaviour, then the current check is fine, and the callsites should be
corrected. Though if there's code in-tree that relies on s64 do_div, that seems
to be a more problematic issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: div64: Rework 64-bit type safety checks in do_div().

[Andrew Morton]

On Mon, 17 Dec 2007 10:48:05 +0900 Paul Mundt <[EMAIL PROTECTED]> wrote:

> The current do_div() implementation has a bogus pointer compare to
> generate build warnings on mismatch on 32-bit, unfortunately this not
> only triggers for size mismatch, but also _any_ type mismatch, even on
> reasonable 64-bit values:
> 
> In file included from kernel/sched.c:869:
> kernel/sched_debug.c: In function 'nsec_high':
> kernel/sched_debug.c:38: warning: comparison of distinct pointer types lacks 
> a cast
> kernel/sched_debug.c:41: warning: comparison of distinct pointer types lacks 
> a cast
> kernel/sched_debug.c: In function 'nsec_low':
> kernel/sched_debug.c:51: warning: comparison of distinct pointer types lacks 
> a cast
> ...
> 
> The options are to either 'fix' all callers of do_div() to make sure
> they're using a uint64_t explicitly, or to update do_div() to make sure
> that the value is 64-bits, regardless of specific type. Currently
> everything that uses the generic do_div() causes a warning when using one
> of 'u64', 'long long', etc. instead of 'uint64_t'.

u64 and uint64_t should be identical?

> Half-assed empirical testing indicates that the number of false positives
> far outweighs any benefits of this type of checking:
> 
> $ git grep uint64_t | wc -l
> 947
> $ git grep u64 | wc -l
> 13942
> 
> In short, screw uint64_t and its fan club.

I don't get it.  Are u64 and uint64_t different on any arch?

> diff --git a/include/asm-generic/div64.h b/include/asm-generic/div64.h
> index a4a4937..63e7768 100644
> --- a/include/asm-generic/div64.h
> +++ b/include/asm-generic/div64.h
> @@ -19,6 +19,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #if BITS_PER_LONG == 64
>  
> @@ -39,13 +40,11 @@ static inline uint64_t div64_64(uint64_t dividend, 
> uint64_t divisor)
>  
>  extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
>  
> -/* The unnecessary pointer compare is there
> - * to check for type safety (n must be 64bit)
> - */
> +/* The BUILD_BUG_ON() is there to check for type safety (n must be 64bit) */
>  # define do_div(n,base) ({   \
>   uint32_t __base = (base);   \
>   uint32_t __rem; \
> - (void)(((typeof((n)) *)0) == ((uint64_t *)0));  \
> + BUILD_BUG_ON(sizeof(n) != sizeof(uint64_t));\
>   if (likely(((n) >> 32) == 0)) { \
>   __rem = (uint32_t)(n) % __base; \
>   (n) = (uint32_t)(n) / __base;   \

The mismatch which I've seen triggering a lot is doing do_div() on an s64
when it expects a u64.

And I think that _is_ a bug, isn't it?  do_div(-10, 10) should return -1,
but as the implementation will convert -10 to , the return value will be wildly wrong?

I'm thinking that the problem here is that x86's do_div(s64, ...) doesn't
warn.  So people write wrong code and then the problems only crop up on
architectures which use asm-generic/div64.h, which does warn?

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

init_timer_deferrable conversion

[Parag Warudkar]

In my quest to get the wake-ups from idle per second down to bare minimum, 
I noticed 3 places in the kernel that could benefit from 
using init_timer_deferrable() instead of init_timer() -


a) drivers/net/sky2.c - watchdog_timer. This was showing up high on 
Powertop's list of things that cause routine wakeups from idle. After 
converting to init_timer_deferrable() the wakeups went down and this one 
no longer shows up in powertop's list. 25% reduction.


b) kernel/time/clocksource.c - watchdog_timer - same story as sky2.c

c) net/core/neighbour.c - gc_timer - Most benefit from deferrable timer.

I am running a kernel with above changes and haven't noticed any immediate 
problems and the wakeups-from-idle have gone down from 5-7 to mere 1-2 per 
second.


Is there any reason not to make the above timers deferrable - corner 
cases, other side effects? If not then I will submit a patch.


Thanks

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

Re: Top kernel oopses/warnings this week

[Dave Jones]

On Sat, Dec 15, 2007 at 04:49:05PM +0100, Stefan Richter wrote:
 
 > Reports about tainted kernels have arguably less value.  It would be
 > good to hide such reports until a report of the same oops in an
 > untainted kernel was found.
 
I disagree with this.  It's useful to have a "we've seen this before,
and every time, it was tainted with xyz module" datapoint, especially
if no untainted copies of that oops turn up.

Dave

-- 
http://www.codemonkey.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] dio: falling through to buffered I/O when invalidationof a page fails

[Hisashi Hifumi]

At 04:15 07/12/15, Zach Brown wrote:
>
>> If anyone has a testcase - I can take a look at the problem again.
>
>I can try and throw something together..
>
>- z

I did a test by using fsstress.

I modified the dio write() of fsstress to check return value, and input
following command;

# fsstress -d /root/testdir/ -l 0 -n 1000 -p 1000 -z -f creat=1 -f write=1 
-f dwrite=1


I got EIO from dio write.


I encountered some PostgreSQL mailing list archive that mentioned about 
this issue.

http://groups.google.com/group/pgsql.hackers/browse_thread/thread/c7515ccd5ac1269c/dc2ddeac3fe0d8c1?lnk=raot=1

dio can be used in PostgreSQL to write transaction log(WAL). It is said 
that when dio is used,

EIO is returned under some workload.
 


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

[PATCH 3/3] ipc: Convert handmade 'min' to min().

[Richard Knutsson]

Convert handmade 'min' to min().

Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Dependent on 'msg->m_ts' being changed from int to size_t.


diff --git a/ipc/msg.c b/ipc/msg.c
index fdf3db5..74d0709 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -920,7 +920,7 @@ out_unlock:
if (IS_ERR(msg))
return PTR_ERR(msg);
 
-   msgsz = (msgsz > msg->m_ts) ? msg->m_ts : msgsz;
+   msgsz = min(msgsz, msg->m_ts);
*pmtype = msg->m_type;
if (store_msg(mtext, msg, msgsz))
msgsz = -EFAULT;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] ipc: Convert handmade 'max' to max().

[Richard Knutsson]

Convert handmade 'max' to max().

Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---

 msg.c |2 +-
 sem.c |2 +-
 shm.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)


diff --git a/ipc/msg.c b/ipc/msg.c
index fdf3db5..74d0709 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -473,7 +473,7 @@ asmlinkage long sys_msgctl(int msqid, int cmd, struct 
msqid_ds __user *buf)
up_read(_ids(ns).rw_mutex);
if (copy_to_user(buf, , sizeof(struct msginfo)))
return -EFAULT;
-   return (max_id < 0) ? 0 : max_id;
+   return max(max_id, 0);
}
case MSG_STAT:  /* msqid is an index rather than a msg queue id */
case IPC_STAT:
diff --git a/ipc/sem.c b/ipc/sem.c
index 35952c0..9ac00ac 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -641,7 +641,7 @@ static int semctl_nolock(struct ipc_namespace *ns, int 
semid, int semnum,
up_read(_ids(ns).rw_mutex);
if (copy_to_user (arg.__buf, , sizeof(struct seminfo))) 
return -EFAULT;
-   return (max_id < 0) ? 0: max_id;
+   return max(max_id, 0);
}
case SEM_STAT:
{
diff --git a/ipc/shm.c b/ipc/shm.c
index 3818fae..45e154a 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -704,7 +704,7 @@ asmlinkage long sys_shmctl (int shmid, int cmd, struct 
shmid_ds __user *buf)
goto out;
}
 
-   err = err < 0 ? 0 : err;
+   err = max(err, 0);
goto out;
}
case SHM_STAT:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] msg.h: Convert m_ts from int to size_t.

[Richard Knutsson]

Convert m_ts ("message text size") from int to size_t.

Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Remove some trailing spaces, since we are in the neighborhood.


diff --git a/include/linux/msg.h b/include/linux/msg.h
index 10a3d5a..7a61952 100644
--- a/include/linux/msg.h
+++ b/include/linux/msg.h
@@ -67,8 +67,8 @@ struct msginfo {
 /* one msg_msg structure for each message */
 struct msg_msg {
struct list_head m_list; 
-   long  m_type;  
-   int m_ts;   /* message text size */
+   long  m_type;
+   size_t m_ts;   /* message text size */
struct msg_msgseg* next;
void *security;
/* the actual message follows immediately */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] power: RFC: introduce a new power API

[David Woodhouse]

On Sun, 2007-12-16 at 21:24 -0500, Andres Salomon wrote:
> This API has the power_supply drivers device their own device_attribute
> list; I find this to be a lot more flexible and cleaner.  For example,
> rather than having a function with a huge switch statement (as olpc_battery
> currently has), we have separate callback functions.  We're not limited
> to drivers only being able to pass 'int' and 'char*'s in sysfs, we're
> not forced to keep a global string around in memory (as is again the
> case for olpc_battery's serial number code), we don't have ordering
> restrictions w/ the return value being interpreted based upon where it's
> located in the array... etc.  The other API seems to encourage driver
> authors to get their custom sysfs knobs into the list of sysfs knobs, and
> this one doesn't.
> 
> If there is interest in this API, I'll convert the rest of the power_supply
> drivers over to it and resubmit patches.

Looks sane enough to me. If Anton has no objections, I'll merge it.

> Ignore the psy->num_properties indentation below; that was done so patch #4
> wasn't stupidly large.

Interesting... but I suppose it makes sense.

-- 
dwmw2

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

[PATCH 5/5] power: convert power_supply static attribs to new API

[Andres Salomon]

This allows us to share the uevent callback code w/ the dynamic attrib
stuff.

Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
 drivers/power/power_supply_sysfs.c |   50 
 include/linux/power_supply.h   |9 ++
 2 files changed, 20 insertions(+), 39 deletions(-)

diff --git a/drivers/power/power_supply_sysfs.c 
b/drivers/power/power_supply_sysfs.c
index 9091c66..7e2c9de 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -26,17 +26,16 @@
  * (as a macro let's say).
  */
 
-static ssize_t power_supply_show_static_attrs(struct device *dev,
- struct device_attribute *attr,
- char *buf) {
-   static char *type_text[] = { "Battery", "UPS", "Mains", "USB" };
+static ssize_t power_supply_show_type(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
struct power_supply *psy = dev_get_drvdata(dev);
-
-   return sprintf(buf, "%s\n", type_text[psy->type]);
+   return power_supply_type_str(psy->type, buf);
 }
 
 static struct device_attribute power_supply_static_attrs[] = {
-   __ATTR(type, 0444, power_supply_show_static_attrs, NULL),
+   __ATTR(type, S_IRUGO, power_supply_show_type, NULL),
 };
 
 int power_supply_create_attrs(struct power_supply *psy)
@@ -187,9 +186,8 @@ static int add_uevent_arg_wrapper(struct power_supply *psy,
 int power_supply_uevent(struct device *dev, struct kobj_uevent_env *env)
 {
struct power_supply *psy = dev_get_drvdata(dev);
+   struct device_attribute *attr;
int ret = 0, j;
-   char *prop_buf;
-   char *attrname;
 
dev_dbg(dev, "uevent\n");
 
@@ -204,42 +202,18 @@ int power_supply_uevent(struct device *dev, struct 
kobj_uevent_env *env)
if (ret)
return ret;
 
-   prop_buf = (char *)get_zeroed_page(GFP_KERNEL);
-   if (!prop_buf)
-   return -ENOMEM;
-
for (j = 0; j < ARRAY_SIZE(power_supply_static_attrs); j++) {
-   struct device_attribute *attr;
-   char *line;
-
attr = _supply_static_attrs[j];
-
-   ret = power_supply_show_static_attrs(dev, attr, prop_buf);
+   ret = add_uevent_arg_wrapper(psy, attr, env);
if (ret < 0)
goto out;
-
-   line = strchr(prop_buf, '\n');
-   if (line)
-   *line = 0;
-
-   attrname = kstruprdup(attr->attr.name, GFP_KERNEL);
-   if (!attrname) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
-   dev_dbg(dev, "Static prop %s=%s\n", attrname, prop_buf);
-
-   ret = add_uevent_var(env, "POWER_SUPPLY_%s=%s", attrname, 
prop_buf);
-   kfree(attrname);
-   if (ret)
-   goto out;
}
+   dev_dbg(dev, "%zd static props\n", j);
 
for (j = 0; psy->props[j]; j++) {
-   struct device_attribute *attr = psy->props[j];
-
+   attr = psy->props[j];
ret = add_uevent_arg_wrapper(psy, attr, env);
+
/*
 * When a battery is absent, we expect -ENODEV.  Don't abort;
 * send the uevent with at least the PRESENT=0 property.
@@ -250,7 +224,5 @@ int power_supply_uevent(struct device *dev, struct 
kobj_uevent_env *env)
dev_dbg(dev, "%zd dynamic props\n", j);
 
 out:
-   free_page((unsigned long)prop_buf);
-
return ret;
 }
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index e4db02e..2fd6739 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -146,6 +146,15 @@ enum power_supply_type {
POWER_SUPPLY_TYPE_USB,
 };
 
+static inline ssize_t power_supply_type_str(int type, char *buf)
+{
+   static char *type_text[] = { "Battery", "UPS", "Mains", "USB" };
+
+   BUG_ON(type < POWER_SUPPLY_TYPE_BATTERY ||
+   type > POWER_SUPPLY_TYPE_USB);
+   return sprintf(buf, "%s\n", type_text[type]);
+}
+
 struct power_supply {
const char *name;
enum power_supply_type type;
-- 
1.5.3.5

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

[PATCH 3/5] power: convert olpc_battery to new API

[Andres Salomon]

Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
 drivers/power/olpc_battery.c |  413 +
 1 files changed, 252 insertions(+), 161 deletions(-)

diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
index af7a231..419aca2 100644
--- a/drivers/power/olpc_battery.c
+++ b/drivers/power/olpc_battery.c
@@ -50,216 +50,309 @@
  * Power
  */
 
-static int olpc_ac_get_prop(struct power_supply *psy,
-   enum power_supply_property psp,
-   union power_supply_propval *val)
+static ssize_t olpc_ac_is_online(struct device *dev,
+   struct device_attribute *attr, char *buf)
 {
-   int ret = 0;
+   int ret;
uint8_t status;
 
-   switch (psp) {
-   case POWER_SUPPLY_PROP_ONLINE:
-   ret = olpc_ec_cmd(EC_BAT_STATUS, NULL, 0, , 1);
-   if (ret)
-   return ret;
-
-   val->intval = !!(status & BAT_STAT_AC);
-   break;
-   default:
-   ret = -EINVAL;
-   break;
-   }
+   ret = olpc_ec_cmd(EC_BAT_STATUS, NULL, 0, , 1);
+   if (!ret)
+   sprintf(buf, "%d\n", !!(status & BAT_STAT_AC));
return ret;
 }
 
-static enum power_supply_property olpc_ac_props[] = {
-   POWER_SUPPLY_PROP_ONLINE,
+static struct device_attribute olpc_ac_props[] = {
+   POWER_SUPPLY_ONLINE(olpc_ac_is_online),
+   POWER_SUPPLY_END
 };
 
 static struct power_supply olpc_ac = {
.name = "olpc-ac",
.type = POWER_SUPPLY_TYPE_MAINS,
-   .properties = olpc_ac_props,
-   .num_properties = ARRAY_SIZE(olpc_ac_props),
-   .get_property = olpc_ac_get_prop,
+   .props = (struct device_attribute **) _ac_props,
 };
 
 /*
  * Battery properties
  */
-static int olpc_bat_get_property(struct power_supply *psy,
-enum power_supply_property psp,
-union power_supply_propval *val)
+static ssize_t olpc_bat_get_status(uint8_t *status)
 {
-   int ret = 0;
-   int16_t ec_word;
-   uint8_t ec_byte;
+   int ret;
 
-   ret = olpc_ec_cmd(EC_BAT_STATUS, NULL, 0, _byte, 1);
+   ret = olpc_ec_cmd(EC_BAT_STATUS, NULL, 0, status, 1);
if (ret)
return ret;
 
+   if (!(*status & BAT_STAT_PRESENT))
+   ret = -ENODEV;
+
/* Theoretically there's a race here -- the battery could be
   removed immediately after we check whether it's present, and
   then we query for some other property of the now-absent battery.
   It doesn't matter though -- the EC will return the last-known
   information, and it's as if we just ran that _little_ bit faster
   and managed to read it out before the battery went away. */
-   if (!(ec_byte & BAT_STAT_PRESENT) && psp != POWER_SUPPLY_PROP_PRESENT)
-   return -ENODEV;
-
-   switch (psp) {
-   case POWER_SUPPLY_PROP_STATUS:
-   if (olpc_platform_info.ecver > 0x44) {
-   if (ec_byte & BAT_STAT_CHARGING)
-   val->intval = POWER_SUPPLY_STATUS_CHARGING;
-   else if (ec_byte & BAT_STAT_DISCHARGING)
-   val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
-   else if (ec_byte & BAT_STAT_FULL)
-   val->intval = POWER_SUPPLY_STATUS_FULL;
-   else /* er,... */
-   val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
-   } else {
-   /* Older EC didn't report charge/discharge bits */
-   if (!(ec_byte & BAT_STAT_AC)) /* No AC means 
discharging */
-   val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
-   else if (ec_byte & BAT_STAT_FULL)
-   val->intval = POWER_SUPPLY_STATUS_FULL;
-   else /* Not _necessarily_ true but EC doesn't tell all 
yet */
-   val->intval = POWER_SUPPLY_STATUS_CHARGING;
-   break;
-   }
-   case POWER_SUPPLY_PROP_PRESENT:
-   val->intval = !!(ec_byte & BAT_STAT_PRESENT);
-   break;
 
-   case POWER_SUPPLY_PROP_HEALTH:
-   if (ec_byte & BAT_STAT_DESTROY)
-   val->intval = POWER_SUPPLY_HEALTH_DEAD;
-   else {
-   ret = olpc_ec_cmd(EC_BAT_ERRCODE, NULL, 0, _byte, 1);
-   if (ret)
-   return ret;
-
-   switch (ec_byte) {
-   case 0:
- 

[PATCH 4/5] power: drop support for old API

[Andres Salomon]

Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
 drivers/power/power_supply_core.c  |   17 +---
 drivers/power/power_supply_leds.c  |   30 ++-
 drivers/power/power_supply_sysfs.c |  158 +---
 include/linux/power_supply.h   |   47 ---
 4 files changed, 17 insertions(+), 235 deletions(-)

diff --git a/drivers/power/power_supply_core.c 
b/drivers/power/power_supply_core.c
index 09013e8..f5bf67b 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -57,8 +57,8 @@ void power_supply_changed(struct power_supply *psy)
 
 int power_supply_am_i_supplied(struct power_supply *psy)
 {
-   union power_supply_propval ret = {0,};
struct device *dev;
+   int ret;
 
down(_supply_class->sem);
list_for_each_entry(dev, _supply_class->devices, node) {
@@ -67,19 +67,12 @@ int power_supply_am_i_supplied(struct power_supply *psy)
 
for (i = 0; i < epsy->num_supplicants; i++) {
if (!strcmp(epsy->supplied_to[i], psy->name)) {
-   if (epsy->num_properties) {
-   if (epsy->get_property(epsy,
- POWER_SUPPLY_PROP_ONLINE, ))
-   continue;
-   } else {
-   /* new API */
struct device_attribute *attr;
attr = power_supply_find_attr(epsy, "online");
if (!attr || power_supply_attr_run(epsy, attr,
-   str_to_int, ))
+   str_to_int, ))
continue;
-   }
-   if (ret.intval)
+   if (ret)
goto out;
}
}
@@ -87,9 +80,9 @@ int power_supply_am_i_supplied(struct power_supply *psy)
 out:
up(_supply_class->sem);
 
-   dev_dbg(psy->dev, "%s %d\n", __FUNCTION__, ret.intval);
+   dev_dbg(psy->dev, "%s %d\n", __FUNCTION__, ret);
 
-   return ret.intval;
+   return ret;
 }
 
 int power_supply_register(struct device *parent, struct power_supply *psy)
diff --git a/drivers/power/power_supply_leds.c 
b/drivers/power/power_supply_leds.c
index 45539b7..b71c583 100644
--- a/drivers/power/power_supply_leds.c
+++ b/drivers/power/power_supply_leds.c
@@ -16,23 +16,16 @@
 
 static void power_supply_update_bat_leds(struct power_supply *psy)
 {
-   union power_supply_propval status;
struct device_attribute *attr;
+   int status;
 
-   if (psy->num_properties) {
-   if (psy->get_property(psy, POWER_SUPPLY_PROP_STATUS, ))
-   return;
-   } else {
-   /* new API */
attr = power_supply_find_attr(psy, "status");
-   if (!attr || power_supply_attr_run(psy, attr, str_to_int,
-   ))
+   if (!attr || power_supply_attr_run(psy, attr, str_to_int, ))
return;
-   }
 
-   dev_dbg(psy->dev, "%s %d\n", __FUNCTION__, status.intval);
+   dev_dbg(psy->dev, "%s %d\n", __FUNCTION__, status);
 
-   switch (status.intval) {
+   switch (status) {
case POWER_SUPPLY_STATUS_FULL:
led_trigger_event(psy->charging_full_trig, LED_FULL);
led_trigger_event(psy->charging_trig, LED_OFF);
@@ -110,23 +103,16 @@ static void power_supply_remove_bat_triggers(struct 
power_supply *psy)
 
 static void power_supply_update_gen_leds(struct power_supply *psy)
 {
-   union power_supply_propval online;
struct device_attribute *attr;
+   int online;
 
-   if (psy->num_properties) {
-   if (psy->get_property(psy, POWER_SUPPLY_PROP_ONLINE, ))
-   return;
-   } else {
-   /* new API */
attr = power_supply_find_attr(psy, "online");
-   if (!attr || power_supply_attr_run(psy, attr, str_to_int,
-   ))
+   if (!attr || power_supply_attr_run(psy, attr, str_to_int, ))
return;
-   }
 
-   dev_dbg(psy->dev, "%s %d\n", __FUNCTION__, online.intval);
+   dev_dbg(psy->dev, "%s %d\n", __FUNCTION__, online);
 
-   if (online.intval)
+   if (online)
led_trigger_event(psy->online_trig, LED_FULL);
else
led_trigger_event(psy->online_trig, LED_OFF);
diff --git a/drivers/power/power_supply_sysfs.c 
b/drivers/power/power_supply_sysfs.c
index 3e44d16..9091c66 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -26,93 +26,6 @@
  * (as a macro let's say).
  */
 
-#define POWER_SUPPLY_ATTR(_name)   \
-{  \
-   .attr = { .name 

Re: 2.6.24-rc5: tape drive not responding

[FUJITA Tomonori]

On Sun, 16 Dec 2007 20:05:51 -0500
"John Stoffel" <[EMAIL PROTECTED]> wrote:

> [  215.007701] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  215.008145] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  215.008678] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  215.009122] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  215.009598] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  215.010042] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  215.010516] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  215.010959] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  215.011403] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  215.011850] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> .
> .
> .
> [  232.954629] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  233.035902] scsi 3:0:3:0: DEVICE RESET operation started
> [  233.099514] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> .
> .
> .
> 
> These repeat for about 15 seconds or so.  They're really annoying and
> I'd love to see some sort of rate limiting put in here.  The messages
> and end with:
> .
> .
> .
> [  238.084175] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  238.165887] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  238.247157] scsi 3:0:3:0: DEVICE RESET operation timed-out.
> [  238.313892] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  238.395192] scsi 3:0:3:0: BUS RESET operation started
> [  238.455690] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
> [  238.539216] sym1: SCSI BUS reset detected.
> [  238.592552] sym1: SCSI BUS has been reset.
> [  238.641576] scsi 3:0:3:0: BUS RESET operation complete.
> [  248.700373]  target3:0:3: wide asynchronous
> [  248.752026]  target3:0:3: Wide Transfers Fail
> [  248.805220]  target3:0:3: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
> [  248.886729]  target3:0:3: Domain Validation skipping write tests
> [  248.958666]  target3:0:3: Ending Domain Validation
> [  252.264086] scsi 3:0:0:0: Attached scsi generic sg2 type 8
> [  252.331257] st 3:0:2:0: Attached scsi tape st0
> [  252.384549] st 3:0:2:0: st0: try direct i/o: yes (alignment 512 B)
> [  252.458875] st 3:0:2:0: Attached scsi generic sg3 type 1
> [  252.523963] st 3:0:3:0: Attached scsi tape st1
> [  252.577184] st 3:0:3:0: st1: try direct i/o: yes (alignment 512 B)
> [  252.651484] st 3:0:3:0: Attached scsi generic sg4 type 1
> 
> 
> I've also got an ATL P1000 SCSI tape library hooked up to this same
> controller and port, and I can manipulate it properly using the 'mtx'
> program pointed to the /dev/changer alias, which points to the correct
> /dev/sg# device.
> 
> Here's my /proc/scsi/scsi output, as you can see, I've got a bunch of
> devices on this system:
> 
> # cat /proc/scsi/scsi 
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
>   Vendor: COMPAQ   Model: HC01841729   Rev: 3208
>   Type:   Direct-AccessANSI  SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 01 Lun: 00
>   Vendor: COMPAQ   Model: BD018222CA   Rev: B016
>   Type:   Direct-AccessANSI  SCSI revision: 02
> Host: scsi3 Channel: 00 Id: 00 Lun: 00
>   Vendor: ATL  Model: P10006220051 Rev: 1.20
>   Type:   Medium Changer   ANSI  SCSI revision: 02
> Host: scsi3 Channel: 00 Id: 02 Lun: 00
>   Vendor: QUANTUM  Model: DLT7000  Rev: 2565
>   Type:   Sequential-AccessANSI  SCSI revision: 02
> Host: scsi3 Channel: 00 Id: 03 Lun: 00
>   Vendor: QUANTUM  Model: DLT7000  Rev: 2565
>   Type:   Sequential-AccessANSI  SCSI revision: 02
> Host: scsi4 Channel: 00 Id: 00 Lun: 00
>   Vendor: SAMSUNG  Model: CDRW/DVD SM-352B Rev: T806
>   Type:   CD-ROM   ANSI  SCSI revision: 05
> Host: scsi6 Channel: 00 Id: 00 Lun: 00
>   Vendor: ATA  Model: ST3320620AS  Rev: 3.AA
>   Type:   Direct-AccessANSI  SCSI revision: 05
> Host: scsi7 Channel: 00 Id: 00 Lun: 00
>   Vendor: ATA  Model: WDC WD3200AAKS-0 Rev: 12.0
>   Type:   Direct-AccessANSI  SCSI revision: 05
> Host: scsi10 Channel: 00 Id: 00 Lun: 00
>   Vendor: ATA  Model: WDC WD1200JB-00C Rev: 17.0
>   Type:   Direct-AccessANSI  SCSI revision: 05
> Host: scsi11 Channel: 00 Id: 00 Lun: 00
>   Vendor: ATA  Model: WDC WD1200JB-00E Rev: 15.0
>   Type:   Direct-AccessANSI  SCSI revision: 05
> Host: scsi12 Channel: 00 Id: 00 Lun: 00
>   Vendor: Generic  Model: STORAGE DEVICE   Rev: 0001
>   Type:   Direct-AccessANSI  SCSI revision: 00
> Host: scsi12 Channel: 00 Id: 00 Lun: 01
>   Vendor: Generic  Model: STORAGE DEVICE   Rev: 0001
>   Type:   Direct-AccessANSI  SCSI revision: 00
> 

[PATCH 2/5] power: convert pda_power to the new API

[Andres Salomon]

Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
 drivers/power/pda_power.c |   40 
 1 files changed, 16 insertions(+), 24 deletions(-)

diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
index c058f28..4012a2f 100644
--- a/drivers/power/pda_power.c
+++ b/drivers/power/pda_power.c
@@ -33,27 +33,23 @@ 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)
+static ssize_t pda_power_online(struct device *dev,
+   struct device_attribute *attr, char *buf)
 {
-   switch (psp) {
-   case POWER_SUPPLY_PROP_ONLINE:
-   if (psy->type == POWER_SUPPLY_TYPE_MAINS)
-   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;
+   struct power_supply *psy = dev_get_drvdata(dev);
+   int ret;
+
+   if (psy->type == POWER_SUPPLY_TYPE_MAINS)
+   ret = pdata->is_ac_online ? pdata->is_ac_online() : 0;
+   else
+   ret = pdata->is_usb_online ? pdata->is_usb_online() : 0;
+
+   return sprintf(buf, "%d\n", !!ret);
 }
 
-static enum power_supply_property pda_power_props[] = {
-   POWER_SUPPLY_PROP_ONLINE,
+static struct device_attribute pda_power_props[] = {
+   POWER_SUPPLY_ONLINE(pda_power_online),
+   POWER_SUPPLY_END
 };
 
 static char *pda_power_supplied_to[] = {
@@ -67,18 +63,14 @@ static struct power_supply pda_power_supplies[] = {
.type = POWER_SUPPLY_TYPE_MAINS,
.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,
+   .props = (struct device_attribute **) _power_props,
},
{
.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,
+   .props = (struct device_attribute **) _power_props,
},
 };
 
-- 
1.5.3.5

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

[PATCH 1/5] power: RFC: introduce a new power API

[Andres Salomon]

This API has the power_supply drivers device their own device_attribute
list; I find this to be a lot more flexible and cleaner.  For example,
rather than having a function with a huge switch statement (as olpc_battery
currently has), we have separate callback functions.  We're not limited
to drivers only being able to pass 'int' and 'char*'s in sysfs, we're
not forced to keep a global string around in memory (as is again the
case for olpc_battery's serial number code), we don't have ordering
restrictions w/ the return value being interpreted based upon where it's
located in the array... etc.  The other API seems to encourage driver
authors to get their custom sysfs knobs into the list of sysfs knobs, and
this one doesn't.

If there is interest in this API, I'll convert the rest of the power_supply
drivers over to it and resubmit patches.

Ignore the psy->num_properties indentation below; that was done so patch #4
wasn't stupidly large.

Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
 drivers/power/power_supply_core.c  |9 +++
 drivers/power/power_supply_leds.c  |   18 +
 drivers/power/power_supply_sysfs.c |  123 
 include/linux/power_supply.h   |   96 
 4 files changed, 246 insertions(+), 0 deletions(-)

diff --git a/drivers/power/power_supply_core.c 
b/drivers/power/power_supply_core.c
index a63b75c..09013e8 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -67,9 +67,18 @@ int power_supply_am_i_supplied(struct power_supply *psy)
 
for (i = 0; i < epsy->num_supplicants; i++) {
if (!strcmp(epsy->supplied_to[i], psy->name)) {
+   if (epsy->num_properties) {
if (epsy->get_property(epsy,
  POWER_SUPPLY_PROP_ONLINE, ))
continue;
+   } else {
+   /* new API */
+   struct device_attribute *attr;
+   attr = power_supply_find_attr(epsy, "online");
+   if (!attr || power_supply_attr_run(epsy, attr,
+   str_to_int, ))
+   continue;
+   }
if (ret.intval)
goto out;
}
diff --git a/drivers/power/power_supply_leds.c 
b/drivers/power/power_supply_leds.c
index 7f8f359..45539b7 100644
--- a/drivers/power/power_supply_leds.c
+++ b/drivers/power/power_supply_leds.c
@@ -17,9 +17,18 @@
 static void power_supply_update_bat_leds(struct power_supply *psy)
 {
union power_supply_propval status;
+   struct device_attribute *attr;
 
+   if (psy->num_properties) {
if (psy->get_property(psy, POWER_SUPPLY_PROP_STATUS, ))
return;
+   } else {
+   /* new API */
+   attr = power_supply_find_attr(psy, "status");
+   if (!attr || power_supply_attr_run(psy, attr, str_to_int,
+   ))
+   return;
+   }
 
dev_dbg(psy->dev, "%s %d\n", __FUNCTION__, status.intval);
 
@@ -102,9 +111,18 @@ static void power_supply_remove_bat_triggers(struct 
power_supply *psy)
 static void power_supply_update_gen_leds(struct power_supply *psy)
 {
union power_supply_propval online;
+   struct device_attribute *attr;
 
+   if (psy->num_properties) {
if (psy->get_property(psy, POWER_SUPPLY_PROP_ONLINE, ))
return;
+   } else {
+   /* new API */
+   attr = power_supply_find_attr(psy, "online");
+   if (!attr || power_supply_attr_run(psy, attr, str_to_int,
+   ))
+   return;
+   }
 
dev_dbg(psy->dev, "%s %d\n", __FUNCTION__, online.intval);
 
diff --git a/drivers/power/power_supply_sysfs.c 
b/drivers/power/power_supply_sysfs.c
index 8efedba..3e44d16 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -138,19 +138,34 @@ int power_supply_create_attrs(struct power_supply *psy)
goto statics_failed;
}
 
+   if (psy->num_properties) {
for (j = 0; j < psy->num_properties; j++) {
rc = device_create_file(psy->dev,
_supply_attrs[psy->properties[j]]);
if (rc)
goto dynamics_failed;
}
+   } else {
+   /* new API */
+   for (j = 0; psy->props[j]; j++) {
+   rc = device_create_file(psy->dev, psy->props[j]);
+   if (rc)
+   goto dynamics_failed;
+   }
+   }
 
goto succeed;
 
 dynamics_failed:
+   if (psy->num_properties) {
while (j--)

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

[Rene Herman]

On 17-12-07 03:05, H. Peter Anvin wrote:

Incidentally, I had the thought earlier today that port 0xf0 might be a 
suitable delay port.  It is used only by the 387-emulating-a-287 hack 
for IRQ 13, which Linux doesn't use on 486+.


[EMAIL PROTECTED]:~/src/port80$ su -c ./port80
cycles: out 2400, in 2400
[EMAIL PROTECTED]:~/src/port80$ su -c ./portf0
cycles: out 2400, in 2400

(Duron 1300)

I suppose you mean using it instead of port 0x80 always and not just as an 
alternate port? For the latter 0xed is alright I guess...



Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86: provide a DMI based port 0x80 I/O delay override.

[Rene Herman]

On 17-12-07 03:04, H. Peter Anvin wrote:


Rene Herman wrote:

On 17-12-07 00:12, David P. Reed wrote:


Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps 
test this to confirm that it works for you?



Will test it by tomorrow morning.


Might as well test the new version then. Ingo Molnar requested a few 
changes and this fixes a couple of problems as well.




As far as I can tell, the code still uses udelay() before calibration if 
io_delay=udelay?


Just so we're clear on that...


Yes. This patch is explicitly about the alternate port and not about udelay. 
 As discussed (and changelogged) the calibration is just one problem with 
PCI posting and possible SMP races the other ones. Ingo Molnar wanted it as 
a debugging thing already though.


Once we start discussing udelay() again I believe we should go with the 
simple per CPU-Family loops_per_jiffy initialization to fix that first 
problem (and I guess I could hack that in now) but then the bigger problem 
remains and will need a fair amount of testing at least and mostly on 
machines that are by now gathering dust in a few basements...


Rene


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

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 15, 2007 7:38 AM,  <[EMAIL PROTECTED]> wrote:
>
> I'll build latest wireless git without ipv6 late tonight.

Ok, built and tested, and it's actually faster! Although still not as
fast as bcm43xx or softmac or whatever the problem is, I was getting a
steady 200 kB/s (as opposed to 500 kB/s for bcm43xx with the same
file/server). I'm not sure if it was the absence of ipv6 or the
commits included in updating my git repository though. Either way, I'm
fairly happy that I'm out of dial-up speed territory.

It'd be nice to be able to fully shake loose whatever is causing the
speed drain - and I call it a drain since sometimes the connection
starts out much faster, but slowly throttles down to whatever speed
it'll stick at (used to be 40 kB/s, but now is 200 kB/s). It does seem
to be like a cap or limit, as in if I download two files, each one
will download at 100 kB/s.

If anyone can help I'd really appreciate it. I know that bcm43xx will
someday be dropped, and when that day comes, it'd be nice if people
with this hardware have at least similar performance with b43 (myself
especially).

Thanks again,
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/2] [RFC] Simple tamper-proof device filesystem.

[David Wagner]

Tetsuo Handa writes:
>When I attended at Security Stadium 2003 as a defense side,
>I was using devfs for /dev directory. The files in /dev directory
>were deleted by attckers and the administrator was unable to login.

If the attacker gets full administrator-level access on your machine,
there are a gazillion ways the attacker can prevent other admins from
logging on.  This patch can't prevent that.  It sounds like this patch
is trying to solve a fundamentally unsolveable problem.

A useful slogan: "Don't forbid what you cannot prevent."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 007 of 7] md: Get name for block device in sysfs

[Kay Sievers]

On Mon, 2007-12-17 at 09:43 +1100, Neil Brown wrote:
> On Saturday December 15, [EMAIL PROTECTED] wrote:
> > On Dec 14, 2007 7:26 AM, NeilBrown <[EMAIL PROTECTED]> wrote:
> > >
> > > Given an fd on a block device, returns a string like
> > >
> > > /block/sda/sda1
> > >
> > > which can be used to find related information in /sys.
> 
> > 
> > As pointed out to when you came up with the idea, we can't do this. A 
> > devpath
> > is a path to the device and will not necessarily start with "/block" for 
> > block
> > devices. It may start with "/devices" and can be much longer than
> > BDEVNAME_SIZE*2  + 10.
> 
> When you say "will not necessarily" can I take that to mean that it
> currently does, but it might (will) change??

It's in -mm. The devpath for all block devices, like for all other
devices, will start with /devices/* if !SYSFS_DEPRECATED.

> In that case can we have the patch as it stands and when the path to
> block devices in /sys changes, the ioctl can be changed at the same
> time to match?

No, you have to use kobject_get_path() to get the path to the object.
This will also handle devices where the name contains '/' which needs to
be translated to '!', which is broken in this patch.

> Or are you saying that as the kernel is today, some block devices
> appear under /devices/..., in which case could you please give an
> example?

We expect the next kernel to have it.

Btw: BLKGETNAME should probably be renamed to something which contains
DEVPATH, to make clear that it's a path to, and not the name of the
device.

Kay

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.24-rc5-mm1: problems with cat /proc/kpageflags

[Matt Mackall]

On Sun, Dec 16, 2007 at 08:10:10PM +0100, Mariusz Kozlowski wrote:
> > > Can you change line 710 of fs/proc/proc_misc.c to:
> > > 
> > >   ppage = NULL;
> > 
> > Sure.
> > 
> > > ..and see if it still breaks?
> > 
> > Yes it does - the same way as eariler. Box is locked, processes stuck in D 
> > state
> > and after a while "BUG: soft lockup - CPU#0 stuck for 11s!".
> 
> My mistake. I run cat /proc/kpageflags in the first place - so how
> could anything change :)
> 
> cat /proc/kpagecount on the other hand - with the change in line 710
> - locks the box. Sysrq works, changing consoles works, but there is
> no "BUG: soft lockup ..." message. After a while the box becomes
> totaly unresponsive - even caps lock doesn't work, no responses to
> ping.

Well I'm baffled. There's basically two things in that function that
do anything interesting: pfn_to_page and put_user. access_ok is
"return 1" on Sparc64. atomic_read is a simple read.

My usual approach at this point would be to litter it with printks and
see where its hanging.

But as the function doesn't actually show up in your stack trace,
something else is probably wrong. So I'd also try commenting out
pieces of that function until it started working.

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

Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails

[Shaohua Li]

On Sun, 2007-12-09 at 23:02 -0500, Mike Houston wrote:
> On Mon, 10 Dec 2007 10:31:27 +0800
> Shaohua Li <[EMAIL PROTECTED]> wrote:
> > This should exist in previous kernel (before we remove acpi
> > motherboard driver) too. Basically it's a broken BIOS. Could below
> > patch work around it?
> > 
> > Thanks,
> > Shaohua
> > 
> > Index: linux/drivers/pnp/system.c
> > ===
> > --- linux.orig/drivers/pnp/system.c 2007-12-10
> > 10:17:46.0 +0800 +++ linux/drivers/pnp/system.c
> 
> Thanks Shaohua, I tested this as well and it appears to have worked
> around the issue for me.
> 
> Now, in dmesg, I get:
> 
> system 00:01: ioport range 0x290-0x29f has been reserved
> (...)
> system 00:01: ioport range 0x290-0x294 could not be reserved
> 
> In /proc/ioports I see:
> 
> 0290-029f : pnp 00:01
>   0290-0297 : it87
> 0290-0297 : it87
Unfortunately this can't solve all such issues.

Adam & Bjorn,
Could we just reserve IO ports >= 0x1000 in pnp system driver? The
purpose of the driver is to avoid resource conflict with PCI device, and
PCI device can't user io port < 0x1000.

Thanks,
Shaohua

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86: provide a DMI based port 0x80 I/O delay override.

[H. Peter Anvin]

Rene Herman wrote:

On 16-12-07 16:22, Ingo Molnar wrote:

looks good to me. Could you please also provide three more controls 
that i suggested earlier:


 - a boot option enabling/disabling the udelay based code
 - a .config method of enabling/disabling the udelay based code
 - a sysctl to toggle it

if we want to clean this all up we'll need as many controls as possible.


This version does the boot and the .config option but not the sysctl. It 
makes for clumsy code and I don't believe it provides for much added 
value as soon as you have the boot option. I am moreover not completely 
confident about things such as paravirt liking the possibility of the 
native_io_delay being changed out from under them at unpredictable times.




Incidentally, I had the thought earlier today that port 0xf0 might be a 
suitable delay port.  It is used only by the 387-emulating-a-287 hack 
for IRQ 13, which Linux doesn't use on 486+.


-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] x86: provide a DMI based port 0x80 I/O delay override.

[H. Peter Anvin]

Rene Herman wrote:

On 17-12-07 00:12, David P. Reed wrote:


Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps 
test this to confirm that it works for you?



Will test it by tomorrow morning.


Might as well test the new version then. Ingo Molnar requested a few 
changes and this fixes a couple of problems as well.




As far as I can tell, the code still uses udelay() before calibration if 
io_delay=udelay?


Just so we're clear on that...

-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] lib: proportion: fix underflow in prop_norm_percpu()

[Jiang zhe]

On Fri, 2007-12-14 at 17:01 +0100, Peter Zijlstra wrote:
> Subject: lib: proportion: fix underflow in prop_norm_percpu()
> 
> Zhe Jiang noticed that its possible to underflow pl->events in
> prop_norm_percpu() when the value returned by percpu_counter_read() is less
> than the error on that read and the period delay > 1. In that case half might
> not trigger the batch increment and the value will be identical on the next
> iteration, causing the same half to be subtracted again and again.
> 
> Fix this by rewriting the division as a single subtraction instead of a
> subtraction loop and using percpu_counter_sum() when the value returned
> by percpu_counter_read() is smaller than the error.
> 
> The latter is still needed if we want pl->events to shrink properly in the
> error region.
> 
> Jiang, can I get a Reviewed-by from you? - if you agree that is :-)
> 
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> Cc: zhejiang <[EMAIL PROTECTED]>
> ---
>  lib/proportions.c |   36 +++-
>  1 file changed, 15 insertions(+), 21 deletions(-)
> 
> Index: linux-2.6/lib/proportions.c
> ===
> --- linux-2.6.orig/lib/proportions.c
> +++ linux-2.6/lib/proportions.c
> @@ -190,6 +190,8 @@ prop_adjust_shift(int *pl_shift, unsigne
>   * PERCPU
>   */
>  
> +#define PROP_BATCH (8*(1+ilog2(nr_cpu_ids)))
> +
>  int prop_local_init_percpu(struct prop_local_percpu *pl)
>  {
>   spin_lock_init(>lock);
> @@ -230,31 +232,23 @@ void prop_norm_percpu(struct prop_global
>  
>   spin_lock_irqsave(>lock, flags);
>   prop_adjust_shift(>shift, >period, pg->shift);
> +
>   /*
>* For each missed period, we half the local counter.
>* basically:
>*   pl->events >> (global_period - pl->period);
> -  *
> -  * but since the distributed nature of percpu counters make division
> -  * rather hard, use a regular subtraction loop. This is safe, because
> -  * the events will only every be incremented, hence the subtraction
> -  * can never result in a negative number.
>*/
> - while (pl->period != global_period) {
> - unsigned long val = percpu_counter_read(>events);
> - unsigned long half = (val + 1) >> 1;
> -
> - /*
> -  * Half of zero won't be much less, break out.
> -  * This limits the loop to shift iterations, even
> -  * if we missed a million.
> -  */
> - if (!val)
> - break;
> -
> - percpu_counter_add(>events, -half);
> - pl->period += period;
> - }
> + period = (global_period - pl->period) >> (pg->shift - 1);
> + if (period < BITS_PER_LONG) {
> + s64 val = percpu_counter_read(>events);
> +
> + if (val < (nr_cpu_ids * PROP_BATCH))
> + val = percpu_counter_sum(>events);
> +
> + __percpu_counter_add(>events, -val + (val >> period), 
> PROP_BATCH);
> + } else
> + percpu_counter_set(>events, 0);
> +
>   pl->period = global_period;
>   spin_unlock_irqrestore(>lock, flags);
>  }
> @@ -267,7 +261,7 @@ void __prop_inc_percpu(struct prop_descr
>   struct prop_global *pg = prop_get_global(pd);
>  
>   prop_norm_percpu(pg, pl);
> - percpu_counter_add(>events, 1);
> + __percpu_counter_add(>events, 1, PROP_BATCH);
>   percpu_counter_add(>events, 1);
>   prop_put_global(pd, pg);
>  }
> 

It's okay! Thanks!


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

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

[Rene Herman]

On 17-12-07 00:12, David P. Reed wrote:


Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps test 
this to confirm that it works for you?



Will test it by tomorrow morning.


Might as well test the new version then. Ingo Molnar requested a few changes 
and this fixes a couple of problems as well.


Rene.


commit 5001121e449040aa9cc021f69bfb191662c13004
Author: Rene Herman <[EMAIL PROTECTED]>
Date:   Sun Dec 16 13:36:39 2007 +0100

x86: provide a DMI based port 0x80 I/O delay override.

Certain (HP) laptops experience trouble from our port 0x80 I/O delay
writes. This patch provides for a DMI based switch to the "alternate
diagnostic port" 0xed (as used by some BIOSes as well) for these.

David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with "hwclock" use being a direct trigger.

Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist but that approach has
two problems.

First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but...

Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally some drivers may be racy on SMP without the bus
locking outb.

Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.

This also introduces a command-line parameter "io_delay" to override
the DMI based choice again:

io_delay=

where "standard" means using the standard port 0x80 and "alternate"
port 0xed.

At the request of Ingo Molnar this retains the udelay method as a
config (CONFIG_UDELAY_IO_DELAY) and command-line ("io_delay=udelay")
choice for testing purposes as well.

This does not change the io_delay() in the boot code which is using
the same port 0x80 I/O delay but those do not appear to be a problem
as David P. Reed reported the problem was already gone after using the
udelay version. He moreover reported that booting with "acpi=off" also
fixed things and seeing as how ACPI isn't touched until after this DMI
based I/O port switch I believe it's safe to leave the ones in the boot
code be.

The DMI strings from David's HP Pavilion dv9000z are in there already
and we need to get/verify the DMI info from other machines with the
problem, notably the HP Pavilion dv6000z.

This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.

Signed-off-by: Rene Herman <[EMAIL PROTECTED]>

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 33121d6..9dce154 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -785,6 +785,14 @@ and is between 256 and 4096 characters. It is defined in 
the file
for translation below 32 bit and if not available
then look in the higher range.
 
+   io_delay=   [X86-32,X86-64] I/O delay method
+   standard
+   Standard port 0x80 delay
+   alternate
+   Alternate port 0xed delay
+   udelay
+   Simple two microsecond delay
+
io7=[HW] IO7 for Marvel based alpha systems
See comment before marvel_specify_io7 in
arch/alpha/kernel/core_marvel.c.
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 761ca7b..40aba67 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -112,4 +112,13 @@ config IOMMU_LEAK
  Add a simple leak tracer to the IOMMU code. This is useful when you
  are debugging a buggy device driver that leaks IOMMU mappings.
 
+config UDELAY_IO_DELAY
+   bool "Delay I/O through udelay instead of outb"
+   depends on DEBUG_KERNEL
+   help
+ Make inb_p/outb_p use udelay() based delays by default. Please note
+ that udelay() does not have the same bus-level side-effects that
+ the normal outb based delay 

[PATCH 5/4] x86: local.h fix checkpatch warnings

[Harvey Harrison]

Mostly space after comma, one space after if.

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 include/asm-x86/local.h |   17 -
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/include/asm-x86/local.h b/include/asm-x86/local.h
index f5677e2..f852c62 100644
--- a/include/asm-x86/local.h
+++ b/include/asm-x86/local.h
@@ -7,15 +7,14 @@
 #include 
 #include 
 
-typedef struct
-{
+typedef struct {
atomic_long_t a;
 } local_t;
 
 #define LOCAL_INIT(i)  { ATOMIC_LONG_INIT(i) }
 
 #define local_read(l)  atomic_long_read(&(l)->a)
-#define local_set(l,i) atomic_long_set(&(l)->a, (i))
+#define local_set(l, i)atomic_long_set(&(l)->a, (i))
 
 static inline void local_inc(local_t *l)
 {
@@ -137,7 +136,7 @@ static inline long local_add_return(long i, local_t *l)
long __i;
 #ifdef CONFIG_M386
unsigned long flags;
-   if(unlikely(boot_cpu_data.x86 <= 3))
+   if (unlikely(boot_cpu_data.x86 <= 3))
goto no_xadd;
 #endif
/* Modern 486+ processor */
@@ -160,11 +159,11 @@ no_xadd: /* Legacy 386 processor */
 
 static inline long local_sub_return(long i, local_t *l)
 {
-   return local_add_return(-i,l);
+   return local_add_return(-i, l);
 }
 
-#define local_inc_return(l)  (local_add_return(1,l))
-#define local_dec_return(l)  (local_sub_return(1,l))
+#define local_inc_return(l)  (local_add_return(1, l))
+#define local_dec_return(l)  (local_sub_return(1, l))
 
 #define local_cmpxchg(l, o, n) \
(cmpxchg_local(&((l)->a.counter), (o), (n)))
@@ -202,8 +201,8 @@ static inline long local_sub_return(long i, local_t *l)
  */
 #define __local_inc(l) local_inc(l)
 #define __local_dec(l) local_dec(l)
-#define __local_add(i,l)   local_add((i),(l))
-#define __local_sub(i,l)   local_sub((i),(l))
+#define __local_add(i, l)  local_add((i), (l))
+#define __local_sub(i, l)  local_sub((i), (l))
 
 /* Use these for per-cpu local_t variables: on some archs they are
  * much more efficient than these naive implementations.  Note they take
-- 
1.5.4.rc0.1083.gf568

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86: provide a DMI based port 0x80 I/O delay override.

[H. Peter Anvin]

Rene Herman wrote:


Do you expect a BIOS update to be able to fix it? If so, I guess any DMI 
hack should take BIOS version into account.




Hard to know without knowing what it is.

-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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[Rene Herman]

On 16-12-07 22:43, H. Peter Anvin wrote:

Again, 24 is "right out".  25 is a "maybe", IMO.  Rene's fix could be an 
exception, since it is a DMI-keyed workaround for a specific machine and 
doesn't change behaviour in general.


I've not much opinion on the schedule as I've not the problem but yes, it's 
intended as the low risk option.


Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86: provide a DMI based port 0x80 I/O delay override.

[Rene Herman]

On 16-12-07 22:42, H. Peter Anvin wrote:

It probably comes down to which version is bigger (you probably also 
want to try uninlining.)


slow_down_io() sort of needs to stay inline due to the REALLY_SLOW_IO thing. 
That stuff could use a cleanup, but that would be a diferent patch.


Thanks for the heads up (also saw the SMBIOS update to this) but those 
don't seem to be a problem in fact. David Reed has been running with 
the simple udelay(2) version of this and reported no more hangs. He 
moreover reported no trouble after booting with "acpi=off" meaning 
that things seem to be fine pre-acpi which the boot code (and this 
io_delay_init) is. So I believe we get to ignore those.


Okay, so there is something inside ACPI which tickles this.  Which 
brings further credibility that it's activating a debugging hack, 
probably inside the SuperIO/system controller chip.


It would be interesting to know exactly which part of ACPI triggers 
this.  I bet it is a reference to system controller namespace.


Do you expect a BIOS update to be able to fix it? If so, I guess any DMI 
hack should take BIOS version into account.


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

div64: Rework 64-bit type safety checks in do_div().

[Paul Mundt]

The current do_div() implementation has a bogus pointer compare to
generate build warnings on mismatch on 32-bit, unfortunately this not
only triggers for size mismatch, but also _any_ type mismatch, even on
reasonable 64-bit values:

In file included from kernel/sched.c:869:
kernel/sched_debug.c: In function 'nsec_high':
kernel/sched_debug.c:38: warning: comparison of distinct pointer types lacks a 
cast
kernel/sched_debug.c:41: warning: comparison of distinct pointer types lacks a 
cast
kernel/sched_debug.c: In function 'nsec_low':
kernel/sched_debug.c:51: warning: comparison of distinct pointer types lacks a 
cast
...

The options are to either 'fix' all callers of do_div() to make sure
they're using a uint64_t explicitly, or to update do_div() to make sure
that the value is 64-bits, regardless of specific type. Currently
everything that uses the generic do_div() causes a warning when using one
of 'u64', 'long long', etc. instead of 'uint64_t'.

Half-assed empirical testing indicates that the number of false positives
far outweighs any benefits of this type of checking:

$ git grep uint64_t | wc -l
947
$ git grep u64 | wc -l
13942

In short, screw uint64_t and its fan club.

Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>

---

 include/asm-generic/div64.h |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/include/asm-generic/div64.h b/include/asm-generic/div64.h
index a4a4937..63e7768 100644
--- a/include/asm-generic/div64.h
+++ b/include/asm-generic/div64.h
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 
 #if BITS_PER_LONG == 64
 
@@ -39,13 +40,11 @@ static inline uint64_t div64_64(uint64_t dividend, uint64_t 
divisor)
 
 extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
 
-/* The unnecessary pointer compare is there
- * to check for type safety (n must be 64bit)
- */
+/* The BUILD_BUG_ON() is there to check for type safety (n must be 64bit) */
 # define do_div(n,base) ({ \
uint32_t __base = (base);   \
uint32_t __rem; \
-   (void)(((typeof((n)) *)0) == ((uint64_t *)0));  \
+   BUILD_BUG_ON(sizeof(n) != sizeof(uint64_t));\
if (likely(((n) >> 32) == 0)) { \
__rem = (uint32_t)(n) % __base; \
(n) = (uint32_t)(n) / __base;   \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

[Rene Herman]

On 16-12-07 16:22, Ingo Molnar wrote:

looks good to me. Could you please also provide three more controls that 
i suggested earlier:


 - a boot option enabling/disabling the udelay based code
 - a .config method of enabling/disabling the udelay based code
 - a sysctl to toggle it

if we want to clean this all up we'll need as many controls as possible.


This version does the boot and the .config option but not the sysctl. It 
makes for clumsy code and I don't believe it provides for much added value 
as soon as you have the boot option. I am moreover not completely confident 
about things such as paravirt liking the possibility of the native_io_delay 
being changed out from under them at unpredictable times.


So how is this? Also fixes a few problems with the previous version.

 Documentation/kernel-parameters.txt |8 ++
 arch/x86/Kconfig.debug  |9 +++
 arch/x86/boot/compressed/misc_32.c  |8 +-
 arch/x86/boot/compressed/misc_64.c  |8 +-
 arch/x86/kernel/Makefile_32 |2
 arch/x86/kernel/Makefile_64 |2
 arch/x86/kernel/io_delay.c  |  103 


 arch/x86/kernel/setup_32.c  |2
 arch/x86/kernel/setup_64.c  |2
 include/asm-x86/io_32.h |6 --
 include/asm-x86/io_64.h |   27 +
 11 files changed, 152 insertions(+), 25 deletions(-)

Rene.
commit 5001121e449040aa9cc021f69bfb191662c13004
Author: Rene Herman <[EMAIL PROTECTED]>
Date:   Sun Dec 16 13:36:39 2007 +0100

x86: provide a DMI based port 0x80 I/O delay override.

Certain (HP) laptops experience trouble from our port 0x80 I/O delay
writes. This patch provides for a DMI based switch to the "alternate
diagnostic port" 0xed (as used by some BIOSes as well) for these.

David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with "hwclock" use being a direct trigger.

Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist but that approach has
two problems.

First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but...

Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally some drivers may be racy on SMP without the bus
locking outb.

Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.

This also introduces a command-line parameter "io_delay" to override
the DMI based choice again:

io_delay=

where "standard" means using the standard port 0x80 and "alternate"
port 0xed.

At the request of Ingo Molnar this retains the udelay method as a
config (CONFIG_UDELAY_IO_DELAY) and command-line ("io_delay=udelay")
choice for testing purposes as well.

This does not change the io_delay() in the boot code which is using
the same port 0x80 I/O delay but those do not appear to be a problem
as David P. Reed reported the problem was already gone after using the
udelay version. He moreover reported that booting with "acpi=off" also
fixed things and seeing as how ACPI isn't touched until after this DMI
based I/O port switch I believe it's safe to leave the ones in the boot
code be.

The DMI strings from David's HP Pavilion dv9000z are in there already
and we need to get/verify the DMI info from other machines with the
problem, notably the HP Pavilion dv6000z.

This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.

Signed-off-by: Rene Herman <[EMAIL PROTECTED]>

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 33121d6..9dce154 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -785,6 +785,14 @@ and is between 256 and 4096 characters. It is defined in 
the file
for translation below 32 bit and if not available
then look in the higher range.
 
+   io_delay=   [X86-32,X86-64] I/O delay method
+   

Re: Strange Memory Corruption Problem with Core2Duo E6700, P965 Chipset MB and >=4GB RAM

[Matthias Schniedermeyer]

On 16.12.2007 02:39, Matthias Schniedermeyer wrote:
> Hi

It appears i found my culprit.  :-)

I have a ISDN-controller which is driven by the HFC-PCI-driver and it 
appears to not be 64bit-safe.

I will test more thorough after i have relocated the card to another 
computer.





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

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

[Dave Young]

On Dec 14, 2007 11:44 PM, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Fri, 14 Dec 2007, Dave Young wrote:
>
> > Hi,
> > The behaviour of my mp3 player (also act as usb-storage device) seems
> > changed from rc5 to rc5-mm1.
>
> This can't be considered a bug, right?

I'm not sure.

> It's just that the player
> changed from one slightly non-standard behavior to a different slightly
> non-standard behavior.
>
>
> > :
> > =
> > usb 1-7: new high speed USB device using ehci_hcd and address 7
> > usb 1-7: configuration #1 chosen from 1 choice
> > scsi4 : SCSI emulation for USB Mass Storage devices
> > usb-storage: device found at 7
> > usb-storage: waiting for device to settle before scanning
> > scsi 4:0:0:0: Direct-Access   Newman mp3   PQ: 0 ANSI: 
> > 0 CCS
> > sd 4:0:0:0: [sdb] 245248 512-byte hardware sectors (126 MB)
> > sd 4:0:0:0: [sdb] Write Protect is on
> > sd 4:0:0:0: [sdb] Mode Sense: 03 00 80 00
> > sd 4:0:0:0: [sdb] Assuming drive cache: write through
> > sd 4:0:0:0: [sdb] 245248 512-byte hardware sectors (126 MB)
> > sd 4:0:0:0: [sdb] Write Protect is on
> > sd 4:0:0:0: [sdb] Mode Sense: 03 00 80 00
> > sd 4:0:0:0: [sdb] Assuming drive cache: write through
> >  sdb: sdb1
> > sd 4:0:0:0: [sdb] Attached SCSI removable disk
> > sd 4:0:0:0: Attached scsi generic sg1 type 0
> > usb-storage: device scan complete
> >
> > ==
> > try mount it (or just blockdev --rereadpt), then write protect become off:
> > ==
> >
> > sd 4:0:0:0: [sdb] 245248 512-byte hardware sectors (126 MB)
> > sd 4:0:0:0: [sdb] Write Protect is off
> > sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
> > sd 4:0:0:0: [sdb] Assuming drive cache: write through
> > sd 4:0:0:0: [sdb] 245248 512-byte hardware sectors (126 MB)
> > sd 4:0:0:0: [sdb] Write Protect is off
> > sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
> > sd 4:0:0:0: [sdb] Assuming drive cache: write through
> >  sdb: sdb1
>
> This output won't appear if you simply mount the device.  So how do you
> know that mounting turns off write protect?

This can be observed by eye:
dmesg -> mount -> dmesg

>
> > But under rc5-mm1, after mount command being executed, it is just
> > mouted as read only partition without set the write-protect to off
> >
> > I tried "blockdev --rereadpt", it do set the write-protect to off as rc5 
> > kernel.
> >
> > Below is the output of dmesg under rc5-mm1
> > ==
> > usb 1-8: new high speed USB device using ehci_hcd and address 6
> > usb 1-8: configuration #1 chosen from 1 choice
> > scsi3 : SCSI emulation for USB Mass Storage devices
> > usb-storage: device found at 6
> > usb-storage: waiting for device to settle before scanning
> > scsi 3:0:0:0: Direct-Access   Newman mp3   PQ: 0 ANSI: 
> > 0 CCS
> > sd 3:0:0:0: [sdb] 245248 512-byte hardware sectors (126 MB)
> > sd 3:0:0:0: [sdb] Write Protect is on
> > sd 3:0:0:0: [sdb] Mode Sense: 03 00 80 00
> > sd 3:0:0:0: [sdb] Assuming drive cache: write through
> > sd 3:0:0:0: [sdb] 245248 512-byte hardware sectors (126 MB)
> > sd 3:0:0:0: [sdb] Write Protect is on
> > sd 3:0:0:0: [sdb] Mode Sense: 03 00 80 00
> > sd 3:0:0:0: [sdb] Assuming drive cache: write through
> >  sdb: sdb1
>
> This looks exactly the same as the output above (except for various
> port, device, and bus numbers).

Yes, but lacks the part of "'Write Protect if off'  and other lines".

>
> If you turn on CONFIG_USB_STORAGE_DEBUG for both kernels and compare
> the dmesg output for the mount command, that might highlight the
> difference.

Ok, I will test with do once have time, thanks.

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

Re: 2.6.24-rc5: tape drive not responding

[John Stoffel]

Hi,

This looks to be a regression between 2.6.23 and 2.6.24-rc5, I'll try
to bi-sect this and report more on it.  Basically, when I bootup, I
get a ton of errors in the dmesg log along the lines of:

[  215.007701] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  215.008145] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  215.008678] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  215.009122] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  215.009598] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  215.010042] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  215.010516] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  215.010959] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  215.011403] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  215.011850] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
.
.
.
[  232.954629] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  233.035902] scsi 3:0:3:0: DEVICE RESET operation started
[  233.099514] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
.
.
.

These repeat for about 15 seconds or so.  They're really annoying and
I'd love to see some sort of rate limiting put in here.  The messages
and end with:
.
.
.
[  238.084175] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  238.165887] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  238.247157] scsi 3:0:3:0: DEVICE RESET operation timed-out.
[  238.313892] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  238.395192] scsi 3:0:3:0: BUS RESET operation started
[  238.455690] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae
[  238.539216] sym1: SCSI BUS reset detected.
[  238.592552] sym1: SCSI BUS has been reset.
[  238.641576] scsi 3:0:3:0: BUS RESET operation complete.
[  248.700373]  target3:0:3: wide asynchronous
[  248.752026]  target3:0:3: Wide Transfers Fail
[  248.805220]  target3:0:3: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
[  248.886729]  target3:0:3: Domain Validation skipping write tests
[  248.958666]  target3:0:3: Ending Domain Validation
[  252.264086] scsi 3:0:0:0: Attached scsi generic sg2 type 8
[  252.331257] st 3:0:2:0: Attached scsi tape st0
[  252.384549] st 3:0:2:0: st0: try direct i/o: yes (alignment 512 B)
[  252.458875] st 3:0:2:0: Attached scsi generic sg3 type 1
[  252.523963] st 3:0:3:0: Attached scsi tape st1
[  252.577184] st 3:0:3:0: st1: try direct i/o: yes (alignment 512 B)
[  252.651484] st 3:0:3:0: Attached scsi generic sg4 type 1


I've also got an ATL P1000 SCSI tape library hooked up to this same
controller and port, and I can manipulate it properly using the 'mtx'
program pointed to the /dev/changer alias, which points to the correct
/dev/sg# device.

Here's my /proc/scsi/scsi output, as you can see, I've got a bunch of
devices on this system:

# cat /proc/scsi/scsi 
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: COMPAQ   Model: HC01841729   Rev: 3208
  Type:   Direct-AccessANSI  SCSI revision: 02
Host: scsi0 Channel: 00 Id: 01 Lun: 00
  Vendor: COMPAQ   Model: BD018222CA   Rev: B016
  Type:   Direct-AccessANSI  SCSI revision: 02
Host: scsi3 Channel: 00 Id: 00 Lun: 00
  Vendor: ATL  Model: P10006220051 Rev: 1.20
  Type:   Medium Changer   ANSI  SCSI revision: 02
Host: scsi3 Channel: 00 Id: 02 Lun: 00
  Vendor: QUANTUM  Model: DLT7000  Rev: 2565
  Type:   Sequential-AccessANSI  SCSI revision: 02
Host: scsi3 Channel: 00 Id: 03 Lun: 00
  Vendor: QUANTUM  Model: DLT7000  Rev: 2565
  Type:   Sequential-AccessANSI  SCSI revision: 02
Host: scsi4 Channel: 00 Id: 00 Lun: 00
  Vendor: SAMSUNG  Model: CDRW/DVD SM-352B Rev: T806
  Type:   CD-ROM   ANSI  SCSI revision: 05
Host: scsi6 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA  Model: ST3320620AS  Rev: 3.AA
  Type:   Direct-AccessANSI  SCSI revision: 05
Host: scsi7 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA  Model: WDC WD3200AAKS-0 Rev: 12.0
  Type:   Direct-AccessANSI  SCSI revision: 05
Host: scsi10 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA  Model: WDC WD1200JB-00C Rev: 17.0
  Type:   Direct-AccessANSI  SCSI revision: 05
Host: scsi11 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA  Model: WDC WD1200JB-00E Rev: 15.0
  Type:   Direct-AccessANSI  SCSI revision: 05
Host: scsi12 Channel: 00 Id: 00 Lun: 00
  Vendor: Generic  Model: STORAGE DEVICE   Rev: 0001
  Type:   Direct-AccessANSI  SCSI revision: 00
Host: scsi12 Channel: 00 Id: 00 Lun: 01
  Vendor: Generic  Model: STORAGE DEVICE   Rev: 0001
  Type:   Direct-AccessANSI  SCSI revision: 00
Host: scsi12 Channel: 00 Id: 00 Lun: 02
  Vendor: Generic  Model: 

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[Robert Hancock]

Ingo Molnar wrote:

* H. Peter Anvin <[EMAIL PROTECTED]> wrote:


Pavel Machek wrote:

this is also something for v2.6.24 merging.

As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.

No kidding!  We're talking about removing a hack that has been 
successful on thousands of pieces of hardware over 15 years because it 

 ^[*]

breaks ONE machine.


[*] "- none of which needs it anymore -"

there, fixed it for you ;-)

So lets keep this in perspective: this is a hack that only helps on a 
very low number of systems. (the PIT of one PII era chipset is known to 
be affected)


unfortunately this hack's side-effects are mis-used by an unknown number 
of drivers to mask PCI posting bugs. We want to figure out those bugs 
(safely and carefully) and we want to remove this hack from modern 
machines that dont need it. Doing anything else would be superstition.


Are there any such examples known of such drivers? It doesn't seem to 
make much sense.. PCI IO writes are not posted on any known system (the 
spec allows them to be posted in the host bus bridge, but if they were 
they could only be flushed by a read, not a write) and PCI MMIO writes 
are only guaranteed to flush by doing a read from that device, not by 
other random port accesses. I suppose using the _p versions of port 
accesses might happen to mask such problems on certain machines..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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/

[PATCH 4/4] x86: Unify local_{32|64}.h

[Harvey Harrison]

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 include/asm-x86/local.h|  148 ++-
 include/asm-x86/local_32.h |  150 
 include/asm-x86/local_64.h |  134 ---
 3 files changed, 144 insertions(+), 288 deletions(-)

diff --git a/include/asm-x86/local.h b/include/asm-x86/local.h
index 194565b..f5677e2 100644
--- a/include/asm-x86/local.h
+++ b/include/asm-x86/local.h
@@ -17,11 +17,151 @@ typedef struct
 #define local_read(l)  atomic_long_read(&(l)->a)
 #define local_set(l,i) atomic_long_set(&(l)->a, (i))
 
-#ifdef CONFIG_X86_32
-# include "local_32.h"
-#else
-# include "local_64.h"
+static inline void local_inc(local_t *l)
+{
+   __asm__ __volatile__(
+   _ASM_INC "%0"
+   :"+m" (l->a.counter));
+}
+
+static inline void local_dec(local_t *l)
+{
+   __asm__ __volatile__(
+   _ASM_DEC "%0"
+   :"+m" (l->a.counter));
+}
+
+static inline void local_add(long i, local_t *l)
+{
+   __asm__ __volatile__(
+   _ASM_ADD "%1,%0"
+   :"+m" (l->a.counter)
+   :"ir" (i));
+}
+
+static inline void local_sub(long i, local_t *l)
+{
+   __asm__ __volatile__(
+   _ASM_SUB "%1,%0"
+   :"+m" (l->a.counter)
+   :"ir" (i));
+}
+
+/**
+ * local_sub_and_test - subtract value from variable and test result
+ * @i: integer value to subtract
+ * @l: pointer to type local_t
+ *
+ * Atomically subtracts @i from @l and returns
+ * true if the result is zero, or false for all
+ * other cases.
+ */
+static inline int local_sub_and_test(long i, local_t *l)
+{
+   unsigned char c;
+
+   __asm__ __volatile__(
+   _ASM_SUB "%2,%0; sete %1"
+   :"+m" (l->a.counter), "=qm" (c)
+   :"ir" (i) : "memory");
+   return c;
+}
+
+/**
+ * local_dec_and_test - decrement and test
+ * @l: pointer to type local_t
+ *
+ * Atomically decrements @l by 1 and
+ * returns true if the result is 0, or false for all other
+ * cases.
+ */
+static inline int local_dec_and_test(local_t *l)
+{
+   unsigned char c;
+
+   __asm__ __volatile__(
+   _ASM_DEC "%0; sete %1"
+   :"+m" (l->a.counter), "=qm" (c)
+   : : "memory");
+   return c != 0;
+}
+
+/**
+ * local_inc_and_test - increment and test
+ * @l: pointer to type local_t
+ *
+ * Atomically increments @l by 1
+ * and returns true if the result is zero, or false for all
+ * other cases.
+ */
+static inline int local_inc_and_test(local_t *l)
+{
+   unsigned char c;
+
+   __asm__ __volatile__(
+   _ASM_INC "%0; sete %1"
+   :"+m" (l->a.counter), "=qm" (c)
+   : : "memory");
+   return c != 0;
+}
+
+/**
+ * local_add_negative - add and test if negative
+ * @i: integer value to add
+ * @l: pointer to type local_t
+ *
+ * Atomically adds @i to @l and returns true
+ * if the result is negative, or false when
+ * result is greater than or equal to zero.
+ */
+static inline int local_add_negative(long i, local_t *l)
+{
+   unsigned char c;
+
+   __asm__ __volatile__(
+   _ASM_ADD "%2,%0; sets %1"
+   :"+m" (l->a.counter), "=qm" (c)
+   :"ir" (i) : "memory");
+   return c;
+}
+
+/**
+ * local_add_return - add and return
+ * @i: integer value to add
+ * @l: pointer to type local_t
+ *
+ * Atomically adds @i to @l and returns @i + @l
+ */
+static inline long local_add_return(long i, local_t *l)
+{
+   long __i;
+#ifdef CONFIG_M386
+   unsigned long flags;
+   if(unlikely(boot_cpu_data.x86 <= 3))
+   goto no_xadd;
+#endif
+   /* Modern 486+ processor */
+   __i = i;
+   __asm__ __volatile__(
+   _ASM_XADD "%0, %1;"
+   :"+r" (i), "+m" (l->a.counter)
+   : : "memory");
+   return i + __i;
+
+#ifdef CONFIG_M386
+no_xadd: /* Legacy 386 processor */
+   local_irq_save(flags);
+   __i = local_read(l);
+   local_set(l, i + __i);
+   local_irq_restore(flags);
+   return i + __i;
 #endif
+}
+
+static inline long local_sub_return(long i, local_t *l)
+{
+   return local_add_return(-i,l);
+}
 
 #define local_inc_return(l)  (local_add_return(1,l))
 #define local_dec_return(l)  (local_sub_return(1,l))
diff --git a/include/asm-x86/local_32.h b/include/asm-x86/local_32.h
deleted file mode 100644
index 33fa3ee..000
--- a/include/asm-x86/local_32.h
+++ /dev/null
@@ -1,150 +0,0 @@
-#ifndef _ARCH_I386_LOCAL_H
-#define _ARCH_I386_LOCAL_H
-
-static inline void local_inc(local_t *l)
-{
-   __asm__ __volatile__(
-   _ASM_INC "%0"
-   :"+m" (l->a.counter));
-}
-
-static inline void local_dec(local_t *l)
-{
-   __asm__ __volatile__(
-   _ASM_DEC "%0"
-   :"+m" (l->a.counter));
-}
-
-static inline void local_add(long i, local_t *l)
-{
-   __asm__ 

[PATCH 2/4] x86: fix asm memory constraints in local_64.h

[Harvey Harrison]

Use the shorter +m form rather than =m and m.

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 include/asm-x86/local_64.h |   30 ++
 1 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/include/asm-x86/local_64.h b/include/asm-x86/local_64.h
index da61076..7808f53 100644
--- a/include/asm-x86/local_64.h
+++ b/include/asm-x86/local_64.h
@@ -5,32 +5,30 @@ static inline void local_inc(local_t *l)
 {
__asm__ __volatile__(
"incq %0"
-   :"=m" (l->a.counter)
-   :"m" (l->a.counter));
+   :"+m" (l->a.counter));
 }
 
 static inline void local_dec(local_t *l)
 {
__asm__ __volatile__(
"decq %0"
-   :"=m" (l->a.counter)
-   :"m" (l->a.counter));
+   :"+m" (l->a.counter));
 }
 
 static inline void local_add(long i, local_t *l)
 {
__asm__ __volatile__(
"addq %1,%0"
-   :"=m" (l->a.counter)
-   :"ir" (i), "m" (l->a.counter));
+   :"+m" (l->a.counter)
+   :"ir" (i));
 }
 
 static inline void local_sub(long i, local_t *l)
 {
__asm__ __volatile__(
"subq %1,%0"
-   :"=m" (l->a.counter)
-   :"ir" (i), "m" (l->a.counter));
+   :"+m" (l->a.counter)
+   :"ir" (i));
 }
 
 /**
@@ -48,8 +46,8 @@ static inline int local_sub_and_test(long i, local_t *l)
 
__asm__ __volatile__(
"subq %2,%0; sete %1"
-   :"=m" (l->a.counter), "=qm" (c)
-   :"ir" (i), "m" (l->a.counter) : "memory");
+   :"+m" (l->a.counter), "=qm" (c)
+   :"ir" (i) : "memory");
return c;
 }
 
@@ -67,8 +65,8 @@ static inline int local_dec_and_test(local_t *l)
 
__asm__ __volatile__(
"decq %0; sete %1"
-   :"=m" (l->a.counter), "=qm" (c)
-   :"m" (l->a.counter) : "memory");
+   :"+m" (l->a.counter), "=qm" (c)
+   : : "memory");
return c != 0;
 }
 
@@ -86,8 +84,8 @@ static inline int local_inc_and_test(local_t *l)
 
__asm__ __volatile__(
"incq %0; sete %1"
-   :"=m" (l->a.counter), "=qm" (c)
-   :"m" (l->a.counter) : "memory");
+   :"+m" (l->a.counter), "=qm" (c)
+   : : "memory");
return c != 0;
 }
 
@@ -106,8 +104,8 @@ static inline int local_add_negative(long i, local_t *l)
 
__asm__ __volatile__(
"addq %2,%0; sets %1"
-   :"=m" (l->a.counter), "=qm" (c)
-   :"ir" (i), "m" (l->a.counter) : "memory");
+   :"+m" (l->a.counter), "=qm" (c)
+   :"ir" (i) : "memory");
return c;
 }
 
-- 
1.5.4.rc0.1083.gf568


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

[PATCH 3/4] x86: Introduce asm helpers in local_{32|64}.h

[Harvey Harrison]

Handle the use of long on X86_32 and quad on X86_64

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
 include/asm-x86/asm.h  |   12 
 include/asm-x86/local.h|2 ++
 include/asm-x86/local_32.h |   18 +-
 include/asm-x86/local_64.h |   18 +-
 4 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/include/asm-x86/asm.h b/include/asm-x86/asm.h
index 8661ae7..1a6980a 100644
--- a/include/asm-x86/asm.h
+++ b/include/asm-x86/asm.h
@@ -8,6 +8,12 @@
 # define _ASM_ALIGN" .balign 4 "
 # define _ASM_MOV_UL   " movl "
 
+# define _ASM_INC  " incl "
+# define _ASM_DEC  " decl "
+# define _ASM_ADD  " addl "
+# define _ASM_SUB  " subl "
+# define _ASM_XADD " xaddl "
+
 #else
 /* 64 bits */
 
@@ -15,6 +21,12 @@
 # define _ASM_ALIGN" .balign 8 "
 # define _ASM_MOV_UL   " movq "
 
+# define _ASM_INC  " incq "
+# define _ASM_DEC  " decq "
+# define _ASM_ADD  " addq "
+# define _ASM_SUB  " subq "
+# define _ASM_XADD " xaddq "
+
 #endif /* CONFIG_X86_32 */
 
 #endif /* _ASM_X86_ASM_H */
diff --git a/include/asm-x86/local.h b/include/asm-x86/local.h
index 1e6b5af..194565b 100644
--- a/include/asm-x86/local.h
+++ b/include/asm-x86/local.h
@@ -2,8 +2,10 @@
 #define _ARCH_LOCAL_H
 
 #include 
+
 #include 
 #include 
+#include 
 
 typedef struct
 {
diff --git a/include/asm-x86/local_32.h b/include/asm-x86/local_32.h
index f3bc4d9..33fa3ee 100644
--- a/include/asm-x86/local_32.h
+++ b/include/asm-x86/local_32.h
@@ -4,21 +4,21 @@
 static inline void local_inc(local_t *l)
 {
__asm__ __volatile__(
-   "incl %0"
+   _ASM_INC "%0"
:"+m" (l->a.counter));
 }
 
 static inline void local_dec(local_t *l)
 {
__asm__ __volatile__(
-   "decl %0"
+   _ASM_DEC "%0"
:"+m" (l->a.counter));
 }
 
 static inline void local_add(long i, local_t *l)
 {
__asm__ __volatile__(
-   "addl %1,%0"
+   _ASM_ADD "%1,%0"
:"+m" (l->a.counter)
:"ir" (i));
 }
@@ -26,7 +26,7 @@ static inline void local_add(long i, local_t *l)
 static inline void local_sub(long i, local_t *l)
 {
__asm__ __volatile__(
-   "subl %1,%0"
+   _ASM_SUB "%1,%0"
:"+m" (l->a.counter)
:"ir" (i));
 }
@@ -45,7 +45,7 @@ static inline int local_sub_and_test(long i, local_t *l)
unsigned char c;
 
__asm__ __volatile__(
-   "subl %2,%0; sete %1"
+   _ASM_SUB "%2,%0; sete %1"
:"+m" (l->a.counter), "=qm" (c)
:"ir" (i) : "memory");
return c;
@@ -64,7 +64,7 @@ static inline int local_dec_and_test(local_t *l)
unsigned char c;
 
__asm__ __volatile__(
-   "decl %0; sete %1"
+   _ASM_DEC "%0; sete %1"
:"+m" (l->a.counter), "=qm" (c)
: : "memory");
return c != 0;
@@ -83,7 +83,7 @@ static inline int local_inc_and_test(local_t *l)
unsigned char c;
 
__asm__ __volatile__(
-   "incl %0; sete %1"
+   _ASM_INC "%0; sete %1"
:"+m" (l->a.counter), "=qm" (c)
: : "memory");
return c != 0;
@@ -103,7 +103,7 @@ static inline int local_add_negative(long i, local_t *l)
unsigned char c;
 
__asm__ __volatile__(
-   "addl %2,%0; sets %1"
+   _ASM_ADD "%2,%0; sets %1"
:"+m" (l->a.counter), "=qm" (c)
:"ir" (i) : "memory");
return c;
@@ -127,7 +127,7 @@ static inline long local_add_return(long i, local_t *l)
/* Modern 486+ processor */
__i = i;
__asm__ __volatile__(
-   "xaddl %0, %1;"
+   _ASM_XADD "%0, %1;"
:"+r" (i), "+m" (l->a.counter)
: : "memory");
return i + __i;
diff --git a/include/asm-x86/local_64.h b/include/asm-x86/local_64.h
index 7808f53..91983e2 100644
--- a/include/asm-x86/local_64.h
+++ b/include/asm-x86/local_64.h
@@ -4,21 +4,21 @@
 static inline void local_inc(local_t *l)
 {
__asm__ __volatile__(
-   "incq %0"
+   _ASM_INC "%0"
:"+m" (l->a.counter));
 }
 
 static inline void local_dec(local_t *l)
 {
__asm__ __volatile__(
-   "decq %0"
+   _ASM_DEC "%0"
:"+m" (l->a.counter));
 }
 
 static inline void local_add(long i, local_t *l)
 {
__asm__ __volatile__(
-   "addq %1,%0"
+   _ASM_ADD "%1,%0"
:"+m" (l->a.counter)
:"ir" (i));
 }
@@ -26,7 +26,7 @@ static inline void local_add(long i, local_t *l)
 static inline void local_sub(long i, local_t *l)
 {
__asm__ __volatile__(
-   "subq %1,%0"
+   _ASM_SUB "%1,%0"
:"+m" (l->a.counter)
:"ir" (i));
 }
@@ -45,7 +45,7 @@ 

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[Robert Hancock]

David P. Reed wrote:
PS: If I have time, I may try to build Rene's port 80 test for Windows 
and run it under WinXP on this machine (I still have a crappy little 
partition that boots it).   If it freezes the same way, it's almost 
certain a design "feature", and if it doesn't freeze, we might suspect 
that there is compensating logic in either Windows ACPI code or some way 
that windows "sets up" the machine.


You'd have to replace the iopl call to an equivalent one for Windows 
(seems like NtSetInformationProcess(ProcessUserModeIOPL) might do what 
you need).


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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/

[PATCH 1/4] x86: clean up local_{32|64}.h

[Harvey Harrison]

Common prefix from both files moved to local.h

Change __inline__ to inline

Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Ingo, this is the revised series with fixed asm incorporating
HPA's comments.

 include/asm-x86/local.h|   19 +--
 include/asm-x86/local_32.h |   34 ++
 include/asm-x86/local_64.h |   25 ++---
 3 files changed, 33 insertions(+), 45 deletions(-)

diff --git a/include/asm-x86/local.h b/include/asm-x86/local.h
index f416893..1e6b5af 100644
--- a/include/asm-x86/local.h
+++ b/include/asm-x86/local.h
@@ -1,10 +1,25 @@
+#ifndef _ARCH_LOCAL_H
+#define _ARCH_LOCAL_H
+
+#include 
+#include 
+#include 
+
+typedef struct
+{
+   atomic_long_t a;
+} local_t;
+
+#define LOCAL_INIT(i)  { ATOMIC_LONG_INIT(i) }
+
+#define local_read(l)  atomic_long_read(&(l)->a)
+#define local_set(l,i) atomic_long_set(&(l)->a, (i))
+
 #ifdef CONFIG_X86_32
 # include "local_32.h"
 #else
 # include "local_64.h"
 #endif
-#ifndef _ARCH_LOCAL_H
-#define _ARCH_LOCAL_H
 
 #define local_inc_return(l)  (local_add_return(1,l))
 #define local_dec_return(l)  (local_sub_return(1,l))
diff --git a/include/asm-x86/local_32.h b/include/asm-x86/local_32.h
index 10ec0cf..f3bc4d9 100644
--- a/include/asm-x86/local_32.h
+++ b/include/asm-x86/local_32.h
@@ -1,35 +1,21 @@
 #ifndef _ARCH_I386_LOCAL_H
 #define _ARCH_I386_LOCAL_H
 
-#include 
-#include 
-#include 
-
-typedef struct
-{
-   atomic_long_t a;
-} local_t;
-
-#define LOCAL_INIT(i)  { ATOMIC_LONG_INIT(i) }
-
-#define local_read(l)  atomic_long_read(&(l)->a)
-#define local_set(l,i) atomic_long_set(&(l)->a, (i))
-
-static __inline__ void local_inc(local_t *l)
+static inline void local_inc(local_t *l)
 {
__asm__ __volatile__(
"incl %0"
:"+m" (l->a.counter));
 }
 
-static __inline__ void local_dec(local_t *l)
+static inline void local_dec(local_t *l)
 {
__asm__ __volatile__(
"decl %0"
:"+m" (l->a.counter));
 }
 
-static __inline__ void local_add(long i, local_t *l)
+static inline void local_add(long i, local_t *l)
 {
__asm__ __volatile__(
"addl %1,%0"
@@ -37,7 +23,7 @@ static __inline__ void local_add(long i, local_t *l)
:"ir" (i));
 }
 
-static __inline__ void local_sub(long i, local_t *l)
+static inline void local_sub(long i, local_t *l)
 {
__asm__ __volatile__(
"subl %1,%0"
@@ -54,7 +40,7 @@ static __inline__ void local_sub(long i, local_t *l)
  * true if the result is zero, or false for all
  * other cases.
  */
-static __inline__ int local_sub_and_test(long i, local_t *l)
+static inline int local_sub_and_test(long i, local_t *l)
 {
unsigned char c;
 
@@ -73,7 +59,7 @@ static __inline__ int local_sub_and_test(long i, local_t *l)
  * returns true if the result is 0, or false for all other
  * cases.
  */
-static __inline__ int local_dec_and_test(local_t *l)
+static inline int local_dec_and_test(local_t *l)
 {
unsigned char c;
 
@@ -92,7 +78,7 @@ static __inline__ int local_dec_and_test(local_t *l)
  * and returns true if the result is zero, or false for all
  * other cases.
  */
-static __inline__ int local_inc_and_test(local_t *l)
+static inline int local_inc_and_test(local_t *l)
 {
unsigned char c;
 
@@ -112,7 +98,7 @@ static __inline__ int local_inc_and_test(local_t *l)
  * if the result is negative, or false when
  * result is greater than or equal to zero.
  */
-static __inline__ int local_add_negative(long i, local_t *l)
+static inline int local_add_negative(long i, local_t *l)
 {
unsigned char c;
 
@@ -130,7 +116,7 @@ static __inline__ int local_add_negative(long i, local_t *l)
  *
  * Atomically adds @i to @l and returns @i + @l
  */
-static __inline__ long local_add_return(long i, local_t *l)
+static inline long local_add_return(long i, local_t *l)
 {
long __i;
 #ifdef CONFIG_M386
@@ -156,7 +142,7 @@ no_xadd: /* Legacy 386 processor */
 #endif
 }
 
-static __inline__ long local_sub_return(long i, local_t *l)
+static inline long local_sub_return(long i, local_t *l)
 {
return local_add_return(-i,l);
 }
diff --git a/include/asm-x86/local_64.h b/include/asm-x86/local_64.h
index ae9a573..da61076 100644
--- a/include/asm-x86/local_64.h
+++ b/include/asm-x86/local_64.h
@@ -1,19 +1,6 @@
 #ifndef _ARCH_X8664_LOCAL_H
 #define _ARCH_X8664_LOCAL_H
 
-#include 
-#include 
-
-typedef struct
-{
-   atomic_long_t a;
-} local_t;
-
-#define LOCAL_INIT(i)  { ATOMIC_LONG_INIT(i) }
-
-#define local_read(l)  atomic_long_read(&(l)->a)
-#define local_set(l,i) atomic_long_set(&(l)->a, (i))
-
 static inline void local_inc(local_t *l)
 {
__asm__ __volatile__(
@@ -55,7 +42,7 @@ static inline void local_sub(long i, local_t *l)
  * true if the result is zero, or false for all
  * other cases.
  */
-static __inline__ int local_sub_and_test(long i, local_t *l)
+static inline int local_sub_and_test(long i, local_t *l)
 {

Re: [PATCH] umem nvram driver: clean up style

[Randy Dunlap]

On Mon, 17 Dec 2007 00:55:00 +0300 Alexey Dobriyan wrote:

> >  static void check_batteries(struct cardinfo *card);
> >  
> >  /*
> > 
> > ---   get_userbit
> > 
> > -*/
> > + *   get_userbit
> > + */
> 
> useless comments, they aren't becoming useful after prettifying, right. ;-)

OK, gone.

> >  static void dump_dmastat(struct cardinfo *card, unsigned int dmastat)
> >  {
> > dev_printk(KERN_DEBUG, >dev->dev, "DMAstat - ");
> > if (dmastat & DMASCR_ANY_ERR)
> > -   printk("ANY_ERR ");
> > +   printk(KERN_CONT "ANY_ERR ");
> > if (dmastat & DMASCR_MBE_ERR)
> > -   printk("MBE_ERR ");
> > +   printk(KERN_CONT "MBE_ERR ");
> > if (dmastat & DMASCR_PARITY_ERR_REP)
> > -   printk("PARITY_ERR_REP ");
> > +   printk(KERN_CONT "PARITY_ERR_REP ");
> > if (dmastat & DMASCR_PARITY_ERR_DET)
> > -   printk("PARITY_ERR_DET ");
> > +   printk(KERN_CONT "PARITY_ERR_DET ");
> > if (dmastat & DMASCR_SYSTEM_ERR_SIG)
> > -   printk("SYSTEM_ERR_SIG ");
> > +   printk(KERN_CONT "SYSTEM_ERR_SIG ");
> > if (dmastat & DMASCR_TARGET_ABT)
> > -   printk("TARGET_ABT ");
> > +   printk(KERN_CONT "TARGET_ABT ");
> > if (dmastat & DMASCR_MASTER_ABT)
> > -   printk("MASTER_ABT ");
> > +   printk(KERN_CONT "MASTER_ABT ");
> > if (dmastat & DMASCR_CHAIN_COMPLETE)
> > -   printk("CHAIN_COMPLETE ");
> > +   printk(KERN_CONT "CHAIN_COMPLETE ");
> > if (dmastat & DMASCR_DMA_COMPLETE)
> > -   printk("DMA_COMPLETE ");
> > +   printk(KERN_CONT "DMA_COMPLETE ");
> 
> KERN_NOISE, it's pretty hard to not notice transformation of
> bitmask to string representation, isn't it?

Was there a suggestion here?

> > @@ -889,7 +866,8 @@ static int __devinit mm_pci_probe(struct
> > return -ENODEV;
> >  
> > dev_printk(KERN_INFO, >dev,
> > -   "Micro Memory(tm) controller found (PCI Mem Module (Battery 
> > Backup))\n");
> > +   "Micro Memory(tm) controller found "
> > +   "(PCI Mem Module (Battery Backup))\n");
> 
> For the record, string splitting occasionaly makes grepping much more 
> annoying:
> grep. nothing? kernel in bugreport definitely spit it! [minute later]
> Oh, I need to grep for smaller strings.

Oh well, restored fwiw.  I don't mind a few source lines of 81 characters.

> > @@ -1030,18 +1011,18 @@ static int __devinit mm_pci_probe(struct
> > data = ~data;
> > data += 1;
> >  
> > -   if (request_irq(dev->irq, mm_interrupt, IRQF_SHARED, DRIVER_NAME, 
> > card)) {
> > +   if (request_irq(dev->irq, mm_interrupt, IRQF_SHARED, DRIVER_NAME,
> > +   card)) {
> 
> Oh, c'mon!

What's the big deal?  It's not like the grep argument.


> And my pet peeve with checkpatch.pl crap: why does it force me to _add_
> KERN_ markers when my patch changes code leaving printk intact, because
> the patch wasn't about printk at all?

It doesn't force you at all.  It suggests.

> Or more philosophically, why a tool which doesn't parse C compiler-style
> suddenly starts making suggestions on how C code should look like?

I look forward to better tools.
New patch below.

---

From: Randy Dunlap <[EMAIL PROTECTED]>

Cleanup umem driver: fix most checkpatch warnings, conform to kernel
coding style.

  linux-2.6.24-rc5-git3> checkpatch.pl-next  patches/block-umem-ckpatch.patch
  total: 0 errors, 5 warnings, 530 lines checked

All of these are line-length warnings.

Only change in generated object file is due to not initializing a
static global variable to 0.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 drivers/block/umem.c |  237 ++---
 1 file changed, 81 insertions(+), 156 deletions(-)

--- linux-2.6.24-rc5-git3.orig/drivers/block/umem.c
+++ linux-2.6.24-rc5-git3/drivers/block/umem.c
@@ -34,7 +34,7 @@
  *  - set initialised bit then.
  */
 
-//#define DEBUG /* uncomment if you want debugging info (pr_debug) */
+#undef DEBUG   /* #define DEBUG if you want debugging info (pr_debug) */
 #include 
 #include 
 #include 
@@ -143,17 +143,12 @@ static struct cardinfo cards[MM_MAXCARDS
 static struct block_device_operations mm_fops;
 static struct timer_list battery_timer;
 
-static int num_cards = 0;
+static int num_cards;
 
 static struct gendisk *mm_gendisk[MM_MAXCARDS];
 
 static void check_batteries(struct cardinfo *card);
 
-/*

---   get_userbit

-*/
 static int get_userbit(struct cardinfo *card, int bit)
 {
unsigned char led;
@@ -161,11 +156,7 @@ static int 

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

[Tetsuo Handa]

Hello.

Indan Zupancic wrote:
> What prevents them from mounting tmpfs on top of /dev, bypassing your fs?
Mandatory access control (MAC) prevents them from mounting tmpfs on top of /dev 
.
MAC mediates namespace manipulation requests such as mount()/umount().

> Also, if they have root there are plenty of ways to prevent an administrator
> from logging in, e.g. using iptables or changing the password.
MAC mediates execution of /sbin/iptables or /usr/bin/passwd .

So, use of this filesystem alone is meaningless because
attackers with root privileges can do what you are saying.
But use of this filesystem with MAC is still valid because
MAC can prevent attackers with root privileges from doing what you are saying.

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

Re: [PATCH 4/8] unify paravirt parts of system.h

[Rafael J. Wysocki]

On Monday, 17 of December 2007, Pavel Machek wrote:
> On Mon 2007-12-17 01:27:29, Rafael J. Wysocki wrote:
> > On Saturday, 15 of December 2007, Ingo Molnar wrote:
> > > 
> > > * Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > 
> > > > > Linux never uses that register. The only user is suspend 
> > > > > save/restore, but that' bogus because it wasn't ever initialized by 
> > > > > Linux in the first place. It could be probably all safely removed.
> > > > 
> > > > It probably is safe to remove... but we currently support '2.8.95 
> > > > kernel loads/resumes 2.6.24 image'... which would break if 2.8 uses 
> > > > cr8.
> > > > 
> > > > So please keep it if it is not a big problem.
> > > 
> > > hm, so __save_processor_state() is in essence an ABI? Could you please 
> > > also send a patch that documents this prominently, in the structure 
> > > itself?
> > 
> > Hmm, I'm not sure if it really is an ABI part.  It doesn't communicate 
> > anything
> > outside of the kernel in which it is defined.
> 
> Well, it is not "application binary interface", but it is
> "kernel-to-kernel binary interface"...

Hm, rather a kernel-to-itself interface. ;-)

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

Re: [RANDOM] Move two variables to read_mostly section to save memory

[Matt Mackall]

On Sun, Dec 16, 2007 at 07:38:14PM +0100, Eric Dumazet wrote:
> Adrian Bunk a ??crit :
> >On Sun, Dec 16, 2007 at 06:42:57PM +0100, Eric Dumazet wrote:
> >>Adrian Bunk a ??crit :
> >>...
> >>>And even more funny, with gcc 4.2 and CONFIG_CC_OPTIMIZE_FOR_SIZE=y your 
> >>>patch doesn't seem to make any space difference - are you using an older 
> >>>compiler or even worse CONFIG_CC_OPTIMIZE_FOR_SIZE=n for being able to 
> >>>see any space difference?
> >>>
> >>>In both cases your code uglification would be even more pointless...
> >>>
> >>I believe that CONFIG_SMP is uglification for you Adrian, but still I am 
> >>glad linux have it.
> >>
> >>If your CONFIG_SYSCTL=n is really that important for you, why dont you 
> >>define a new qualifier that can indeed mark some variables as :
> >>
> >>const if CONFIG_SYSCTL=n
> >>read_mostly if CONFIG_SYCTL=y
> >>
> >>This way you can keep compiler optimizations for your CONFIG_SYCTL=n, 
> >>while many people like me can still continue to optimize their kernel.
> >>
> >>Seeing so many sysctl already read_mostly in kernel, I wonder why you 
> >>NACK my patch, while it's easy to share your concerns with other people 
> >>and find a solution.
> >
> >You omitted an answer to my main important point...
> >
> >Let me ask it in a more simple way:
> >
> >Do you see any space difference at all with gcc 4.2 and 
> >CONFIG_CC_OPTIMIZE_FOR_SIZE=y ?
> >
> 
> 
> I am using gcc-4.2.1
> 
> CONFIG_CC_OPTIMIZE_FOR_SIZE=y makes no difference for me.
> 
> $ make defconfig
> $ egrep "OPTIMIZE_FOR_SIZE|CONFIG_SMP" .config
> CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> CONFIG_SMP=y
> $ make vmlinux
> $ nm -v vmlinux|grep -4 random_read_wakeup_thresh
> c057a02c d excluded_id_list
> c057a100 d zero_bdi
> c057a180 D random_table
> c057a300 d input_pool
> c057a400 d random_read_wakeup_thresh
> c057a404 d random_write_wakeup_thresh
>
> c057a480 d blocking_pool
> c057a580 d nonblocking_pool
> c057a680 d rekey_work
> 
> After my patch, I still gain 120 bytes.

Well there's really no point arguing about this. We've found the cause
of the hole (good), but moving other things around to magically fix it
is the wrong thing to do.

I'll queue a patch to remove the big ugly alignment.

Automatically detecting these sorts of holes in the kernel image would
be a useful thing to do. In a couple instances, I've spotted much
larger ones.

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

Re: Iomega ZIP-100 drive unsupported with jmicron JMB361 chip?

[Bill Davidsen]

trash can wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Success!
I downloaded kernel-2.6.24-0.81.rc4.git7.fc9.src.rpm from the Fedora
development tree. Went through "rpm dependecy hell" and solved all
dependencies by installing other fc9 rpms. I used
config-2.6.23.1-42.fc8 as my starting point. My
config-2.6.24-0.81.rc4.git7.local.fc8 is attached.

After compilation and installation of the kernel rpm, upon boot I could
see a device sdc4 being created, but boot failed with
"mount: missing mount point", some errors in mounting from setuproot and
switchroot.

I believe the problem was with the Red Hat/Fedora anaconda installer
and/or grub, and my multiboot machine setup. I had not been able to boot
updated fc8 kernel packages, only the originally installed kernel.
Note that my Fedora 7 and Fedora 8 distributions share no directories
(one exception) and all this work is taking place in the Fedora 8
distribution. The /boot partition IS shared among my distributions.
I found my /etc/fstab file had two "/" mount point entries. The last line
contained LABEL=/ and is a reference to my Fedora 7 root partition.
I deleted this line from fstab as I did not want to change the mount
point for this line to mount my Fedora 7 distribution on Fedora 8.
This kernel installation process was appending LABEL=/ to my kernel
line in grub.conf:
kernel /vmlinuz-2.6.24-0.81.rc4.git7.local.fc8 ro root=/dev/VGf800/LogVol00 
rhgb quiet LABEL=/

LABEL=/ was removed from the line.

I then needed to recreate my initrd image:
mkinitrd /boot/initrd-2.6.24-0.81.rc4.git7.local.fc8.img \
  2.6.24-0.81.rc4.git7.local.fc8

Finally I was able to boot (Zip disk inserted) to the local kernel and the
Zip drive works as expected.

# blkid
/dev/sdc4: SEC_TYPE="msdos" LABEL="ZIP-100" UUID="4910-1305" TYPE="vfat"

dmesg:
ata9.00: ATAPI: LITE-ON DVDRW SOHW-1693S, KS0B, max UDMA/66
ata9.01: ATAPI: IOMEGA  ZIP 100   ATAPI, 05.H, max MWDMA1, CDB intr
ata9.00: limited to UDMA/33 due to 40-wire cable
ata9.00: configured for UDMA/33
ata9.01: configured for MWDMA1
scsi 8:0:0:0: CD-ROMLITE-ON  DVDRW SOHW-1693S KS0B PQ: 0 ANSI: 5
scsi 8:0:1:0: Direct-Access IOMEGA   ZIP 100  05.H PQ: 0 ANSI: 5
sd 8:0:1:0: [sdc] 196608 512-byte hardware sectors (101 MB)
sd 8:0:1:0: [sdc] Write Protect is off
sd 8:0:1:0: [sdc] Mode Sense: 00 40 00 00
sd 8:0:1:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
sd 8:0:1:0: [sdc] 196608 512-byte hardware sectors (101 MB)
sd 8:0:1:0: [sdc] Write Protect is off
sd 8:0:1:0: [sdc] Mode Sense: 00 40 00 00
sd 8:0:1:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sdc: sdc4

My thanks to all the great people who solved this problem and those who 
patiently
responded to my queries.

- -RoyBoy626

I've been behing reading this list, I was going to say that I have 
always had best luck with those drives using the old idescsi driver, 
although I haven't used a kernel newer than... 2.6.18 or so on the old 
machines. Since you have a solution I won't suggest you try that with an 
old kernel ;-)


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 08/12] PAT 64b: coherent mmap and sysfs bin ioctl

[Paul Mackerras]

Greg KH writes:

> Ok, sorry, it wasn't blindingly obvious that this was for pci sysfs
> devices that are mmaped, that makes a bit more sense.
> 
> But I'd like to see what ioctl is wanted here first.

I believe the ioctl would be to set whether the mapping goes to I/O or
memory space, and whether write-combining is allowed.

So the alternative to the ioctl would be to have multiple files in
sysfs, one per combination of modes -- i.e., 4 files, or 3 if we
exclude the "I/O with write combining" mode, which would be
reasonable.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

[Pavel Machek]

On Mon 2007-12-17 00:03:01, Alan Cox wrote:
> On Sun, 16 Dec 2007 22:26:33 +0100
> Pavel Machek <[EMAIL PROTECTED]> wrote:
> 
> > On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
> > > 
> > > * Alan Cox <[EMAIL PROTECTED]> wrote:
> > > 
> > > > There is another reason we can't just do a dumb changeover - two 
> > > > actually
> > > > 
> > > > #1: Some drivers are using inb_p/outb_p in PCI cases which are going 
> > > > #to cause PCI posting changes. Most are probably just wrong in the 
> > > > #first place but they need hand checking
> > > 
> > > hm, any intelligent way to force PCI posting? I guess not.
> > > 
> > > here's a list of candidate drivers (match the out*_p() pattern and do 
> > > pci)
> > > 
> > > ./char/epca.c 
> > > ./char/sonypi.c
> > > ./scsi/megaraid.c
> > > ./ide/pci/serverworks.c
> > > ./ide/pci/cmd640.c
> > > ./input/mouse/pc110pad.c
> 
> You are missing some watchdogs at least ?

I snipped them, I only wanted to comment that pc110pad.c looks like
legitimate use of outb_p().
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH 4/8] unify paravirt parts of system.h

[Pavel Machek]

On Mon 2007-12-17 01:27:29, Rafael J. Wysocki wrote:
> On Saturday, 15 of December 2007, Ingo Molnar wrote:
> > 
> > * Pavel Machek <[EMAIL PROTECTED]> wrote:
> > 
> > > > Linux never uses that register. The only user is suspend 
> > > > save/restore, but that' bogus because it wasn't ever initialized by 
> > > > Linux in the first place. It could be probably all safely removed.
> > > 
> > > It probably is safe to remove... but we currently support '2.8.95 
> > > kernel loads/resumes 2.6.24 image'... which would break if 2.8 uses 
> > > cr8.
> > > 
> > > So please keep it if it is not a big problem.
> > 
> > hm, so __save_processor_state() is in essence an ABI? Could you please 
> > also send a patch that documents this prominently, in the structure 
> > itself?
> 
> Hmm, I'm not sure if it really is an ABI part.  It doesn't communicate 
> anything
> outside of the kernel in which it is defined.

Well, it is not "application binary interface", but it is
"kernel-to-kernel binary interface"...

> The problem is, though, that if kernel A is used for resuming kernel B, and
> kernel B doesn't save/restore everything it will need after the resume, then
> things will break if kernel A modifies that.  So, yes, we'll need to document
> that explicitly.

Agreed.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

[Alan Cox]

> /*
>  * We try to avoid enabling the hardware if it's not
>  * there, but we don't know how to test. But we do know
>  * that the PC110 is not a PCI system. So if we find any
>  * PCI devices in the machine, we don't have a PC110.
>  */

The pc110 pad device is ISA. Its an ISA bus 486 box

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

Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

[Alan Cox]

On Sun, 16 Dec 2007 22:26:33 +0100
Pavel Machek <[EMAIL PROTECTED]> wrote:

> On Fri 2007-12-14 15:33:28, Ingo Molnar wrote:
> > 
> > * Alan Cox <[EMAIL PROTECTED]> wrote:
> > 
> > > There is another reason we can't just do a dumb changeover - two 
> > > actually
> > > 
> > > #1: Some drivers are using inb_p/outb_p in PCI cases which are going 
> > > #to cause PCI posting changes. Most are probably just wrong in the 
> > > #first place but they need hand checking
> > 
> > hm, any intelligent way to force PCI posting? I guess not.
> > 
> > here's a list of candidate drivers (match the out*_p() pattern and do 
> > pci)
> > 
> > ./char/epca.c 
> > ./char/sonypi.c
> > ./scsi/megaraid.c
> > ./ide/pci/serverworks.c
> > ./ide/pci/cmd640.c
> > ./input/mouse/pc110pad.c

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

Re: [e2fsprogs PATCH] Userspace solution to time-based UUID without duplicates

[Theodore Tso]

On Sun, Dec 16, 2007 at 10:53:19PM +0100, Helge Deller wrote:
> 
> FYI, we are currently discussing and testing this proposed patch to e2fsprogs 
> off-list in Red Hat's bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=233471

Note that this bug is currently not publically visible.  (You need to
be various Red Hat Beta groups in order to view it)

In any case here's the latest version of the libuuid patch, in case
anyone would like to comment.  I believe this to be a more correct way
of solving this problem than the uuid kernel patch, since it does the
right thing even if time goes backwards across a reboot.  And, of
course, it doesn't consume one or two kilobytes of non-swappable
kernel memory.  In this version, the uuidd daemon is optional (it's
mainly useful if you are running some application that requires
hundreds or thousands of UUID's generated per second[1]), and if it's
installed, the libuuid library to start the setuid helper uuidd daemon
when it is needed, and after five minutes of inactivity, the uuidd
daemon will automatically exit, thus conserving memory.

[1] This is not a hypothetical example; it was such an enterprise
application that spawned the Sourceforge, Red Hat, and Novell bug
reports.

- Ted

commit 740837def7fc55ba6b0368f46a4b4abcaba0becd
Author: Theodore Ts'o <[EMAIL PROTECTED]>
Date:   Sun Dec 16 17:21:38 2007 -0500

Add uuidd daemon to prevent duplicate time-based UUID's

Also store the clock sequence information in a state file in
/var/lib/misc/uuid-clock so that if the time goes backwards the clock
sequence counter can get bumped.  This allows us to completely
correctly generate time-based (version 1) UUID's according to the
algorithm specified RFC 4122.

Addresses-Sourceforge-Bug: #1529672
Addresses-Red-Hat-Bugzilla: #233471

Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]>

diff --git a/aclocal.m4 b/aclocal.m4
index 3a4c2f3..fc3ed73 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -2600,3 +2600,52 @@ AC_DEFUN([gl_XSIZE],
   AC_REQUIRE([gl_SIZE_MAX])
   AC_CHECK_HEADERS(stdint.h)
 ])
+
+# from http://autoconf-archive.cryp.to/ax_tls.html
+#
+# This was licensed under the GPL with the following exception:
+#
+# As a special exception, the respective Autoconf Macro's copyright
+# owner gives unlimited permission to copy, distribute and modify the
+# configure scripts that are the output of Autoconf when processing
+# the Macro. You need not follow the terms of the GNU General Public
+# License when using or distributing such scripts, even though
+# portions of the text of the Macro appear in them. The GNU General
+# Public License (GPL) does govern all other use of the material that
+# constitutes the Autoconf Macro.
+#
+# This special exception to the GPL applies to versions of the
+# Autoconf Macro released by the Autoconf Macro Archive. When you make
+# and distribute a modified version of the Autoconf Macro, you may
+# extend this special exception to the GPL to apply to your modified
+# version as well.
+#
+AC_DEFUN([AX_TLS], [
+  AC_MSG_CHECKING(for thread local storage (TLS) class)
+  AC_CACHE_VAL(ac_cv_tls, [
+ax_tls_keywords="__thread __declspec(thread) none"
+for ax_tls_keyword in $ax_tls_keywords; do
+   case $ax_tls_keyword in
+  none) ac_cv_tls=none ; break ;;
+  *)
+ AC_TRY_COMPILE(
+[#include 
+ static void
+ foo(void) {
+ static ] $ax_tls_keyword [ int bar;
+ exit(1);
+ }],
+ [],
+ [ac_cv_tls=$ax_tls_keyword ; break],
+ ac_cv_tls=none
+ )
+  esac
+done
+])
+
+  if test "$ac_cv_tls" != "none"; then
+dnl AC_DEFINE([TLS], [], [If the compiler supports a TLS storage class 
define it to that here])
+AC_DEFINE_UNQUOTED([TLS], $ac_cv_tls, [If the compiler supports a TLS 
storage class define it to that here])
+  fi
+  AC_MSG_RESULT($ac_cv_tls)
+])
diff --git a/configure b/configure
index 5c8448a..244a509 100755
--- a/configure
+++ b/configure
@@ -11434,6 +11434,81 @@ done
 
 fi
 
+  { echo "$as_me:$LINENO: checking for thread local storage (TLS) class" >&5
+echo $ECHO_N "checking for thread local storage (TLS) class... $ECHO_C" >&6; }
+  if test "${ac_cv_tls+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+
+ax_tls_keywords="__thread __declspec(thread) none"
+for ax_tls_keyword in $ax_tls_keywords; do
+   case $ax_tls_keyword in
+  none) ac_cv_tls=none ; break ;;
+  *)
+ cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+#include 
+ static void
+ foo(void) {
+ static  $ax_tls_keyword  int bar;
+ exit(1);
+ }
+int
+main ()
+{
+

Re: [PATCH 4/4] x86: Final unification of local_{32|64}.h

[H. Peter Anvin]

Harvey Harrison wrote:


#define _ASM_INC " incl "

_ASM_INC "%0"


Not sure if you were just tossing a space on the end of my example,
but do you also put a leading space on the " incl " in addition to
the trailing space?



That is what I have, again, just to make mistakes harder.

-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 4/8] unify paravirt parts of system.h

[Rafael J. Wysocki]

On Saturday, 15 of December 2007, Ingo Molnar wrote:
> 
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
> 
> > > Linux never uses that register. The only user is suspend 
> > > save/restore, but that' bogus because it wasn't ever initialized by 
> > > Linux in the first place. It could be probably all safely removed.
> > 
> > It probably is safe to remove... but we currently support '2.8.95 
> > kernel loads/resumes 2.6.24 image'... which would break if 2.8 uses 
> > cr8.
> > 
> > So please keep it if it is not a big problem.
> 
> hm, so __save_processor_state() is in essence an ABI? Could you please 
> also send a patch that documents this prominently, in the structure 
> itself?

Hmm, I'm not sure if it really is an ABI part.  It doesn't communicate anything
outside of the kernel in which it is defined.

The problem is, though, that if kernel A is used for resuming kernel B, and
kernel B doesn't save/restore everything it will need after the resume, then
things will break if kernel A modifies that.  So, yes, we'll need to document
that explicitly.

Greetings,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/3] Add GD-Rom support to the SEGA Dreamcast

[Adrian McMenamin]

On Mon, 2007-12-17 at 06:59 +0900, Paul Mundt wrote:

> 
> While I realize that this is all undocumented and based entirely on
> reverse engineering, you should at least verify that that's precisely
> what is going on, and that this is not just a precaution for flushing
> posted writes. You can test that by removing the loop and doing a dummy
> read after your write (to the same register, rather than the entire ROM
> space). If it's a posting issue, then you will have to do your own
> read/write_reg routines that handle the flush.


I've looked at this some more and, from the various things on the web,
it seems SEGA introduced some sort of crude checksum security feature
which ctrl_outl(0x1f, GDROM_RESET_REG) appears to start. Unless it
is used then the GD Rom remains disabled.

After that, the hardware executes a checksum of the ROM to ensure that
you are actually booting from a Dreamcast.

Well, that is my interpretation of
http://www.ludd.ltu.se/~jlo/dc/bootROM.c and similar. Certainly any
other sort of read seems to keep the gdrom disabled.


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

Re: [PATCH 4/4] x86: Final unification of local_{32|64}.h

[Harvey Harrison]

On Sun, 2007-12-16 at 15:48 -0800, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> > 
> > Do you have a stylistic preference between these two options:
> > 
> > Option 1) Rely on CPP string constant concatenation
> > 
> > // possibly include trailing space here to avoid remembering
> > // leading space on the register names
> > # define _ASM_INC "incl" 
> > 
> > static inline void local_inc(local_t *l)
> > {
> > __asm__ __volatile__(
> > _ASM_INC " %0"
> > :"+m" (l->a.counter));
> > }
> > 
> 
> This is what I have used up to this point, except including the space in 
> the macro:
> 
> #define _ASM_INC " incl "
> 
>   _ASM_INC "%0"

Not sure if you were just tossing a space on the end of my example,
but do you also put a leading space on the " incl " in addition to
the trailing space?

Harvey

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

Re: shared memory

[Rafael Sisto]

thanks a lot!!


On Dec 16, 2007 7:30 PM, Luciano Rocha <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 16, 2007 at 05:01:17PM -0300, Rafael Sisto wrote:
> > Thank you for the quick answer, but It's a college project, and I must
> > share user level memory. I also must build my own system calls...
> > But I can look what is already done and make something similar. Do you
> > think shmget would do? Does it share user level memory?
>
> Yes. They both do, but the Posix one is based on a ramfs or tmpfs on
> /dev/shm and shared mmaps. I think analyzing the SysV version will be
> better for your needs.
>
> shmget: create the memory region
> shmat: attach the memory region to this process.
>
> --
>
> Luciano Rocha <[EMAIL PROTECTED]>
> Eurotux Informática, S.A. 
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] x86: Final unification of local_{32|64}.h

[H. Peter Anvin]

Harvey Harrison wrote:


Do you have a stylistic preference between these two options:

Option 1) Rely on CPP string constant concatenation

// possibly include trailing space here to avoid remembering
// leading space on the register names
# define _ASM_INC "incl" 


static inline void local_inc(local_t *l)
{
__asm__ __volatile__(
_ASM_INC " %0"
:"+m" (l->a.counter));
}



This is what I have used up to this point, except including the space in 
the macro:


#define _ASM_INC " incl "

_ASM_INC "%0"

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

Linux 2.4.35.5

[Willy Tarreau]

I've just released Linux 2.4.35.5.

It simply gets up to date with 2.4.36-rc1. One important thing to
keep in mind is that I explicitly disabled the possibility to build
with GCC 4.2 because several users (me included) encountered silent
mis-compilations.

So if you think that you have built your last version with 4.2, just
check if you can build this one. If you can, then you use a correct,
older GCC version. Otherwise, you'll have to install an old one for
the moment. Anyway, this update contains enough fixes for minor to
medium vulnerabilities to justify an upgrade.

Depending on the activity in the security area during the following
weeks, this version might be the last 2.4.35.X. So if you have not
yet tried 2.4.36-rc, it is time to do so.

The patch and changelog will appear soon at the following locations:
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/patch-2.4.35.5.bz2
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.35.5

Git repository:
   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-v2.4.35.y.git
  http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-v2.4.35.y.git

Git repository through the gitweb interface:
  http://git.kernel.org/?p=linux/kernel/git/stable/linux-v2.4.35.y.git

Regards,
Willy

---

Summary of changes from v2.4.35.4 to v2.4.35.5


Jonas Danielsson (1):
  net/ipv4/arp.c: Fix arp reply when sender ip 0

Krzysztof Strasburger (1):
  fix arch/i386/config.in to be able to boot on 386

Pete Zaitcev (1):
  usb: Move linux-usb-devel

Willy Tarreau (7):
  GCC >= 4.2 miscompiles the kernel
  fix build of ia32entry.S on x86_64
  vfs: coredumping fix
  isdn: avoid copying overly-long strings
  isdn: fix isdn_ioctl memory overrun vulnerability
  prevent SIGCONT from waking up a PTRACED process (CVE-2007-4774)
  Change VERSION to 2.4.35.5

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

Re: [stable] Linux 2.6.23.10

[Rafael J. Wysocki]

On Saturday, 15 of December 2007, Greg KH wrote:
> On Sat, Dec 15, 2007 at 03:55:40AM +0100, Rafael J. Wysocki wrote:
> > On Saturday, 15 of December 2007, Rafael J. Wysocki wrote:
> > > On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> > > > On 12/14/2007 08:52 PM, Rafael J. Wysocki wrote:
> > > > > On Saturday, 15 of December 2007, Chuck Ebbert wrote:
> > > > >> On 12/14/2007 02:49 PM, Greg Kroah-Hartman wrote:
> > > > >>>   Freezer: Fix APM emulation breakage
> > > > >> drivers/char/apm-emulation.c: In function 'apm_ioctl':
> > > > >> drivers/char/apm-emulation.c:370: error: implicit declaration of 
> > > > >> function 'wait_event_freezable'
> > > > >> make[2]: *** [drivers/char/apm-emulation.o] Error 1
> > > > >> make[1]: *** [drivers/char] Error 2
> > > > > 
> > > > > This is my fault, sorry.
> > > > > 
> > > > > I though the 2.6.24-rc fix would be suitable for 2.6.23.x, but that's 
> > > > > not the
> > > > > case.
> > > > > 
> > > > > Greg, please revert the "Freezer: Fix APM emulation breakage" patch, 
> > > > > I'll
> > > > > prepare a separate fix suitable for -stable.
> > > > > 
> > > > 
> > > > It works if you add the changes to freezer.h made in commit
> > > > e42837bcd35b75bb59ae5d3e62f87be1aeeb05c3
> > > 
> > > Yes, exactly, but a new patch is needed anyway.
> > > 
> > > Hmm, perhaps it's better to add a new patch on top of "Freezer: Fix APM
> > > emulation breakage"?  Would that be preferred?
> > 
> > For convenience, below is the patch that should fix the breakage when 
> > applied
> > on top of the "Freezer: Fix APM emulation breakage" patch.
> 
> Can you send me a whole new patch that works properly for the next
> 2.6.23-stable release?

Appended.

Thanks,
Rafael


---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>

The APM emulation is currently broken as a result of commit
831441862956fffa17b9801db37e6ea1650b0f69
"Freezer: make kernel threads nonfreezable by default"
that removed the PF_NOFREEZE annotations from apm_ioctl() without
adding the appropriate freezer hooks.  Fix it and remove the
unnecessary variable flags from apm_ioctl().

This problem has been fixed in the mainline by
commit cb43c54ca05c01533c45e4d3abfe8f99b7acf624
"Freezer: Fix APM emulation breakage".

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 drivers/char/apm-emulation.c |   15 ---
 include/linux/freezer.h  |   23 +++
 2 files changed, 31 insertions(+), 7 deletions(-)

Index: linux-2.6.23.y/include/linux/freezer.h
===
--- linux-2.6.23.y.orig/include/linux/freezer.h
+++ linux-2.6.23.y/include/linux/freezer.h
@@ -4,6 +4,7 @@
 #define FREEZER_H_INCLUDED
 
 #include 
+#include 
 
 #ifdef CONFIG_PM_SLEEP
 /*
@@ -126,6 +127,24 @@ static inline void set_freezable(void)
current->flags &= ~PF_NOFREEZE;
 }
 
+/*
+ * Freezer-friendly wrapper around wait_event_interruptible(), originally
+ * defined in 
+ */
+
+#define wait_event_freezable(wq, condition)\
+({ \
+   int __retval;   \
+   do {\
+   __retval = wait_event_interruptible(wq, \
+   (condition) || freezing(current));  \
+   if (__retval && !freezing(current)) \
+   break;  \
+   else if (!(condition))  \
+   __retval = -ERESTARTSYS;\
+   } while (try_to_freeze());  \
+   __retval;   \
+})
 #else /* !CONFIG_PM_SLEEP */
 static inline int frozen(struct task_struct *p) { return 0; }
 static inline int freezing(struct task_struct *p) { return 0; }
@@ -143,6 +162,10 @@ static inline void freezer_do_not_count(
 static inline void freezer_count(void) {}
 static inline int freezer_should_skip(struct task_struct *p) { return 0; }
 static inline void set_freezable(void) {}
+
+#define wait_event_freezable(wq, condition)\
+   wait_event_interruptible(wq, condition)
+
 #endif /* !CONFIG_PM_SLEEP */
 
 #endif /* FREEZER_H_INCLUDED */
Index: linux-2.6.23.y/drivers/char/apm-emulation.c
===
--- linux-2.6.23.y.orig/drivers/char/apm-emulation.c
+++ linux-2.6.23.y/drivers/char/apm-emulation.c
@@ -295,7 +295,6 @@ static int
 apm_ioctl(struct inode * inode, struct file *filp, u_int cmd, u_long arg)
 {
struct apm_user *as = filp->private_data;
-   unsigned long flags;
int err = -EINVAL;
 
if (!as->suser || !as->writer)
@@ -331,10 +330,16 @@ apm_ioctl(struct inode * inode, struct f
 

Re: [PATCH 4/4] x86: Final unification of local_{32|64}.h

[Harvey Harrison]

On Sun, 2007-12-16 at 14:48 -0800, H. Peter Anvin wrote:
> Ingo Molnar wrote:
> > * Harvey Harrison <[EMAIL PROTECTED]> wrote:
> > 
> >> No differences except for the defintion of local_add_return on X86_64. 
> >> The X86_32 version is just fine as it is protected with ifdef 
> >> CONFIG_M386 so use it directly.
> > 
> > thanks, i've applied your 4 patches to x86.git.
> > 
> > btw., now that we have a single unified file, it might make sense to fix 
> > these checkpatch complaints:
> > 
> >   total: 10 errors, 1 warnings, 257 lines checked
> > 
> > in case you are interested ;-)
> > 
> 
> Please pull them pending revision, they're broken (macros don't expand 
> inside strings...)
> 

Do you have a stylistic preference between these two options:

Option 1) Rely on CPP string constant concatenation

// possibly include trailing space here to avoid remembering
// leading space on the register names
# define _ASM_INC "incl" 

static inline void local_inc(local_t *l)
{
__asm__ __volatile__(
_ASM_INC " %0"
:"+m" (l->a.counter));
}

Option 2) Macro Expansion

# define _ASM_INC(r) \"incl\ ##r\"

static inline void local_inc(local_t *l)
{
__asm__ __volatile__(
_ASM_INC(%0);
:"+m" (l->a.counter));
}

Or some other suggestion.

Harvey



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

Linux 2.4.36-rc1

[Willy Tarreau]

I've just released Linux 2.4.36-rc1.

It fixes several vulnerabilities, some of them discovered in 2.6.
Among them, we find 2 ISDN overflows, one case of insufficient
permissions checking on core dumps, the ability for a process to
escape ptrace-based syscall policy checking, and the possibility
for a specially crafted ELF binary to bypass the recently added
restrictions on the minimum MMAP address.

Due to several reports of mis-compilations with GCC 4.2, I have
explicitly disabled its use with an explicit message.

I got one report from Krzysztof Strasburger of a good old 386 not
booting anymore due to a misplaced "HAS_TSC" in the config. His
fix made perfect sense and looked good, but please complain if you
notice a related problem on old hardware.

It was also not possible to build for ia32 on x86_64 due to a
recent vulnerability fix in which an update to the size of the
instruction was missing (cmpl -> cmpq).

I'm still planning on releasing 2.4.36 around the end of the year
(eg: last week-end), if nothing new is discovered since. If new
fixes are merged by that time, I may delay it a little bit to the
beginning of January.

Please test it, beat it and report any problems (build or bugs).

The patch and changelog will appear soon at the following locations:
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/testing/
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.36-rc1.bz2
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.36.log

Git repository:
   git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/linux-2.4.git
  http://www.kernel.org/pub/scm/linux/kernel/git/wtarreau/linux-2.4.git/

Git repository through the gitweb interface:
  http://git.kernel.org/?p=linux/kernel/git/wtarreau/linux-2.4.git

Thanks,
Willy

---

Summary of changes from v2.4.36-pre2 to v2.4.36-rc1


Jonas Danielsson (1):
  net/ipv4/arp.c: Fix arp reply when sender ip 0

Krzysztof Strasburger (1):
  fix arch/i386/config.in to be able to boot on 386

Pete Zaitcev (1):
  usb: Move linux-usb-devel

Willy Tarreau (8):
  GCC >= 4.2 miscompiles the kernel
  prevent do_brk() from allocating below mmap_min_addr
  fix build of ia32entry.S on x86_64
  vfs: coredumping fix
  isdn: avoid copying overly-long strings
  prevent SIGCONT from waking up a PTRACED process (CVE-2007-4774)
  isdn: fix isdn_ioctl memory overrun vulnerability
  Change VERSION to 2.4.36-rc1

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

Re: [PATCH 0/9] mmap read-around and readahead

[Linus Torvalds]

On Sun, 16 Dec 2007, Fengguang Wu wrote:
> 
> Here are the mmap read-around related patches initiated by Linus.
> They are for linux-2.6.24-rc4-mm1.  The one major new feature -
> auto detection and early readahead for mmap sequential reads - runs
> as expected on my desktop :-)

Just out of interest - did you check to see if it makes any difference to 
any IO patterns (or even timings)?

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

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[H. Peter Anvin]

Pavel Machek wrote:

Hi!

The process of safely making delicate changes here is beyond my 
responsibility as just a user - believe me, I'm not suggesting that a risky 
fix be put in .24.   I can patch my own kernels, and I can even share an 
unofficial patch with others for now, or suggest that Fedora and Ubuntu add 
it to their downstream.


May I make a small suggestion, though.   If the decision is a DMI-keyed 
switch from out-80 to udelay(2)  gets put in, perhaps there should also be 
a way for people to test their own configuration for the underlying problem 
made available as a script.   Though it is a "hack", all you need to freeze 
a problem system is to run a loop doing about 1000 "cat /dev/nvram > 
/dev/null"  commands.  If that leads to a freeze, one might ask to have the 
motherboard added to the DMI-key list.


Can you freeze it by catting /dev/rtc, too? That may be significant,
because that is readable for group audio (at least on some
systems)... which would smell like "small security hole" to me.
Pavel


Heck, on my system (Fedora 7), it's mode 644...

-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: howto get a melodic system beep?

[Jan Engelhardt]

On Dec 16 2007 23:37, Jan Engelhardt wrote:
>On Dec 16 2007 23:25, Harald Dunkel wrote:
>>
>> Hi folks,
>>
>> Is there a way to replace the system beep by something more
>> melodic?
>>
>> I remember some 10 years ago there was a patch for the kernel
>> to call an external "beep daemon" playing an audio file instead
>> (no kidding). But it never worked very well. Sometimes there
>> was a huge delay, and some programs were not very nice to the
>> system beep.
>>
>> My X-mas wish would be to get an improvement here.

In drivers/input/misc/pcspkr.c, pcspkr_event() in the SND_BELL case,
you could add a reroute so that SND_BELL events are passed to
userspace (think /dev/input/pcspkr). Delays are of course possible,
and it really depends on how the scheduler does its job (read: you
might want to renice your userspace part).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[Pavel Machek]

Hi!

> The process of safely making delicate changes here is beyond my 
> responsibility as just a user - believe me, I'm not suggesting that a risky 
> fix be put in .24.   I can patch my own kernels, and I can even share an 
> unofficial patch with others for now, or suggest that Fedora and Ubuntu add 
> it to their downstream.
>
> May I make a small suggestion, though.   If the decision is a DMI-keyed 
> switch from out-80 to udelay(2)  gets put in, perhaps there should also be 
> a way for people to test their own configuration for the underlying problem 
> made available as a script.   Though it is a "hack", all you need to freeze 
> a problem system is to run a loop doing about 1000 "cat /dev/nvram > 
> /dev/null"  commands.  If that leads to a freeze, one might ask to have the 
> motherboard added to the DMI-key list.

Can you freeze it by catting /dev/rtc, too? That may be significant,
because that is readable for group audio (at least on some
systems)... which would smell like "small security hole" to me.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/

sata_mv not working with a RocketRaid 2220

[Jean-Louis Dupond]

Hello,

I'm trying to get my HighPoint RocketRaid Controller working with the 
sata_mv drivers.

But something is not working correctly :(

Kernel version 2.6.23.11 (also tried 2.6.24-rc5 with same results)
Controller in lspci: Marvell Technology Group Ltd. MV88SX6081 8-port 
SATA II PCI-X Controller (rev 07)


  1.
 Dec 16 22:44:29 localhost kernel: sata_mv :05:08.0: Gen-II 32
 slots 8 ports SCSI mode IRQ via INTx
  2.
 Dec 16 22:44:29 localhost kernel: scsi4 : sata_mv
  3.
 Dec 16 22:44:29 localhost kernel: scsi5 : sata_mv
  4.
 Dec 16 22:44:29 localhost kernel: scsi6 : sata_mv
  5.
 Dec 16 22:44:29 localhost kernel: scsi7 : sata_mv
  6.
 Dec 16 22:44:29 localhost kernel: scsi8 : sata_mv
  7.
 Dec 16 22:44:29 localhost kernel: scsi9 : sata_mv
  8.
 Dec 16 22:44:29 localhost kernel: scsi10 : sata_mv
  9.
 Dec 16 22:44:29 localhost kernel: scsi11 : sata_mv
 10.
 Dec 16 22:44:29 localhost kernel: ata5: SATA max UDMA/133 cmd
 0x ctl 0xc20010122120 bmdma 0x
 irq 16
 11.
 Dec 16 22:44:29 localhost kernel: ata6: SATA max UDMA/133 cmd
 0x ctl 0xc20010124120 bmdma 0x
 irq 16
 12.
 Dec 16 22:44:29 localhost kernel: ata7: SATA max UDMA/133 cmd
 0x ctl 0xc20010126120 bmdma 0x
 irq 16
 13.
 Dec 16 22:44:29 localhost kernel: ata8: SATA max UDMA/133 cmd
 0x ctl 0xc20010128120 bmdma 0x
 irq 16
 14.
 Dec 16 22:44:29 localhost kernel: ata9: SATA max UDMA/133 cmd
 0x ctl 0xc20010132120 bmdma 0x
 irq 16
 15.
 Dec 16 22:44:29 localhost kernel: ata10: SATA max UDMA/133 cmd
 0x ctl 0xc20010134120 bmdma 0x
 irq 16
 16.
 Dec 16 22:44:29 localhost kernel: ata11: SATA max UDMA/133 cmd
 0x ctl 0xc20010136120 bmdma 0x
 irq 16
 17.
 Dec 16 22:44:29 localhost kernel: ata12: SATA max UDMA/133 cmd
 0x ctl 0xc20010138120 bmdma 0x
 irq 16
 18.
 Dec 16 22:44:29 localhost kernel: ata5: SATA link up 3.0 Gbps
 (SStatus 123 SControl 300)
 19.
 Dec 16 22:44:29 localhost kernel: ata5.00: ATA-7: SAMSUNG SP2504C,
 VT100-33, max UDMA7
 20.
 Dec 16 22:44:29 localhost kernel: ata5.00: 488397168 sectors,
 multi 0: LBA48 NCQ (depth 0/32)
 21.
 Dec 16 22:44:29 localhost kernel: ata5.00: configured for UDMA/133
 22.
 Dec 16 22:44:29 localhost kernel: ata6: SATA link up 3.0 Gbps
 (SStatus 123 SControl 300)
 23.
 Dec 16 22:44:29 localhost kernel: ata6.00: ATA-7: SAMSUNG SP2504C,
 VT100-33, max UDMA7
 24.
 Dec 16 22:44:29 localhost kernel: ata6.00: 488397168 sectors,
 multi 0: LBA48 NCQ (depth 0/32)
 25.
 Dec 16 22:44:29 localhost kernel: ata6.00: configured for UDMA/133
 26.
 Dec 16 22:44:29 localhost kernel: ata7: SATA link up 3.0 Gbps
 (SStatus 123 SControl 300)
 27.
 Dec 16 22:44:29 localhost kernel: ata7.00: ATA-7: SAMSUNG SP2504C,
 VT100-33, max UDMA7
 28.
 Dec 16 22:44:29 localhost kernel: ata7.00: 488397168 sectors,
 multi 0: LBA48 NCQ (depth 0/32)
 29.
 Dec 16 22:44:29 localhost kernel: ata7.00: configured for UDMA/133
 30.
 Dec 16 22:44:29 localhost kernel: ata8: SATA link up 3.0 Gbps
 (SStatus 123 SControl 300)
 31.
 Dec 16 22:44:29 localhost kernel: ata8.00: ATA-7: SAMSUNG SP2504C,
 VT100-33, max UDMA7
 32.
 Dec 16 22:44:29 localhost kernel: ata8.00: 488397168 sectors,
 multi 0: LBA48 NCQ (depth 0/32)
 33.
 Dec 16 22:44:29 localhost kernel: ata8.00: configured for UDMA/133
 34.
 Dec 16 22:44:29 localhost kernel: ata9: SATA link up 3.0 Gbps
 (SStatus 123 SControl 300)
 35.
 Dec 16 22:44:29 localhost kernel: ata9.00: ATA-7: SAMSUNG SP2504C,
 VT100-33, max UDMA7
 36.
 Dec 16 22:44:29 localhost kernel: ata9.00: 488397168 sectors,
 multi 0: LBA48 NCQ (depth 0/32)
 37.
 Dec 16 22:44:29 localhost kernel: ata9.00: configured for UDMA/133
 38.
 Dec 16 22:44:29 localhost kernel: ata10: SATA link down (SStatus 0
 SControl 300)
 39.
 Dec 16 22:44:29 localhost kernel: ata11: SATA link up 3.0 Gbps
 (SStatus 123 SControl 300)
 40.
 Dec 16 22:44:29 localhost kernel: ata11.00: ATA-7: SAMSUNG
 SP2504C, VT100-33, max UDMA7
 41.
 Dec 16 22:44:29 localhost kernel: ata11.00: 488397168 sectors,
 multi 0: LBA48 NCQ (depth 0/32)
 42.
 Dec 16 22:44:29 localhost kernel: ata11.00: configured for UDMA/133
 43.
 Dec 16 22:44:29 localhost kernel: ata12: SATA link down (SStatus 0
 SControl 300)
 44.
 Dec 16 22:44:29 localhost kernel: scsi 4:0:0:0: Direct-Access
 ATA  SAMSUNG SP2504C  VT10 PQ: 0 ANSI: 5

 45.
 Dec 16 22:44:29 localhost kernel: sd 4:0:0:0: [sdb] 488397168
 512-byte hardware sectors (250059 MB)
 46.
 Dec 16 22:44:29 localhost kernel: 

Re: sockets affected by IPsec always block (2.6.23)

[David Miller]

From: Bill Davidsen <[EMAIL PROTECTED]>
Date: Sun, 16 Dec 2007 17:47:24 -0500

> David Miller wrote:
> > From: Herbert Xu <[EMAIL PROTECTED]>
> > Date: Wed, 5 Dec 2007 11:12:32 +1100
> > 
> >> [INET]: Export non-blocking flags to proto connect call
> >>
> >> Previously we made connect(2) block on IPsec SA resolution.  This is
> >> good in general but not desirable for non-blocking sockets.
> >>
> >> To fix this properly we'd need to implement the larval IPsec dst stuff
> >> that we talked about.  For now let's just revert to the old behaviour
> >> on non-blocking sockets.
> >>
> >> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
> > 
> > We made an explicit decision not to do things this way.
> > 
> > Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl
> > setting, and this is across the board.  If xfrm_larval_drop is zero,
> > non-blocking semantics do not extend to IPSEC route resolution,
> > otherwise it does.
> > 
> > If he sets this sysctl to "1" as I detailed in my reply, he'll
> > get the behavior he wants.
> > 
> I think you for the hint, but I would hardly call this sentence 
> "detailed" in terms of being a cookbook solution to the problem.

I guess "echo '1' >/proc/sys/net/core/xfrm_larval_drop" is not
explicit enough?  What more would you like me to say?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86: provide a DMI based port 0x80 I/O delay override.

[David P. Reed]

Rene Herman wrote:
David: I've plugged in your DMI values in this. Could you perhaps test 
this to confirm that it works for you?



Will test it by tomorrow morning.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[David P. Reed]

The process of safely making delicate changes here is beyond my 
responsibility as just a user - believe me, I'm not suggesting that a 
risky fix be put in .24.   I can patch my own kernels, and I can even 
share an unofficial patch with others for now, or suggest that Fedora 
and Ubuntu add it to their downstream.


May I make a small suggestion, though.   If the decision is a DMI-keyed 
switch from out-80 to udelay(2)  gets put in, perhaps there should also 
be a way for people to test their own configuration for the underlying 
problem made available as a script.   Though it is a "hack", all you 
need to freeze a problem system is to run a loop doing about 1000 "cat 
/dev/nvram > /dev/null"  commands.  If that leads to a freeze, one might 
ask to have the motherboard added to the DMI-key list.


H. Peter Anvin wrote:

Ingo Molnar wrote:

* H. Peter Anvin <[EMAIL PROTECTED]> wrote:


Pavel Machek wrote:

this is also something for v2.6.24 merging.

As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.

No kidding!  We're talking about removing a hack that has been 
successful on thousands of pieces of hardware over 15 years because it 

 ^[*]

breaks ONE machine.


[*] "- none of which needs it anymore -"

there, fixed it for you ;-)

So lets keep this in perspective: this is a hack that only helps on a 
very low number of systems. (the PIT of one PII era chipset is known 
to be affected)


Yes, but the status quo has been *tested* on thousands of systems and 
is known to work.  Thus, changing it puts things into unknown 
territory, even if only a small number of machines actually need the 
current configuration.


Heck, there are only a small number of 386/486 machines still in 
operation and being actively updated.


unfortunately this hack's side-effects are mis-used by an unknown 
number of drivers to mask PCI posting bugs. We want to figure out 
those bugs (safely and carefully) and we want to remove this hack 
from modern machines that dont need it. Doing anything else would be 
superstition.


anyway, we likely wont be doing anything about this in .24.


Again, 24 is "right out".  25 is a "maybe", IMO.  Rene's fix could be 
an exception, since it is a DMI-keyed workaround for a specific 
machine and doesn't change behaviour in general.


-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: programs vanish with 2.6.22+

[Bill Davidsen]

Markus wrote:
Well, now some windows vanished, but no additional messages were 
produced by kernel. When somebody could tell what I exactly need to 
do... would be nice.
Or a hit, in what direction I should look. Because its really nasty to 
not being able to use a current kernel.


I already rebuild the whole system, as suggested by the gentoo-devs, 
without success.


I could also try to debug/strace/whatever the apps and wait for it to 
disappear.


Just talk to me, I am not able to do this on my own...

Try running under GNOME if you can, this sounds as if it may be an X 
problem.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/