Re: Ethernet driver on 2.6.22

2007-09-24 Thread Randy Dunlap
On Tue, 25 Sep 2007 12:37:32 +1000 hce wrote:

> On 9/25/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > On Tue, 25 Sep 2007 08:39:07 +1000 hce wrote:
> >
> > > On 9/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > > On Mon, 24 Sep 2007 12:40:07 +1000 hce wrote:
> > > >
> > > > > Thanks Randy.
> > > > >
> > > > > On 9/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > > > > On Mon, 24 Sep 2007 08:52:36 +1000 hce wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I am upgrading from kernel 2.6.11 to 2.6.22 on ARM S3C2400A and 
> > > > > > > found
> > > > > > > a following issue on 2.6.22.
> > > > > > >
> > > > > > > On 2.6.11, I selected CONFIG_ISA,  CONFIG_NET_PCI and 
> > > > > > > CONFIG_CS89X0 to
> > > > > > > build  CS8900A Ethernet driver to kernel, it was running perfect.
> > > > > > >
> > > > > > > But on 2.6.22, I made the same configuration for CS8900A, the 
> > > > > > > cs89x0.o
> > > > > > > could not be compiled in to the kernel (or as a module when I 
> > > > > > > tried to
> > > > > > > CONFIG_CS89X0=m) unless I commented out depends statement in
> > > > > > > drivers/net/Kconfig. I double checked all three are CONFIG_ISA=y,
> > > > > > > CONFIG_NET_PCI=y and CONFIG_CS89X0=y. Any explanation please, was 
> > > > > > > I
> > > > > > > missing something here?
> > > > > >
> > > > > > I didn't look in 2.6.11 Kconfig files, but in 2.6.22, this driver is
> > > > > > limited to 3 specific boards:
> > > > > >
> > > > > > config CS89x0
> > > > > > tristate "CS89x0 support"
> > > > > > depends on NET_PCI && (ISA || MACH_IXDP2351 || 
> > > > > > ARCH_IXDP2X01 || ARCH_PNX010X)
> > > > >
> > > > > The Kconfig for CS89x0 in 2.6.11 is exactly the same as 2.6.22.
> > > > >
> > > > > > Does ARM S3C2400A qualify as any of those?  (MACH_... or ARCH_...)
> > > > >
> > > > > I can run CS89x0 for ARM S3C2400 in 2.6.11, at least I can say yes,
> > > > > the ARM S3C2400A qualifies those in 2.6.11, I don't know the 2.6.22
> > > > > and I hope someone knows 2.6.22 well can answer it.
> > > > >
> > > > > > (latter: ARCH_PNX010X is not used anywhere else AFAICT)
> > > > >
> > > > > Yes, but you only need to enable ISA and NET_PCI to use CS89x0.
> > > >
> > > > Right.
> > > >
> > > > I don't have any problem building CS89x0 for X86_32:
> > > > make defconfig then enable ISA (what!?!?  why not in defconfig?)
> > > > and then enable CS89x0.
> > >
> > > I don't have my embedded system here, I'll try when I get there. But,
> > > let me clarify it, did you mean to type "make defconfig" on linux
> > > (kernel) directory, and enable ISA, NET_PCI and CS89x0 from the
> > > prompt?
> > >
> > > My procedure was to edit .config to enable ISA, NET_PCI and CS89x0
> > > from vim, then type "make menuconfig" and "make oldconfig" (The same
> > > procedure I did in 2.6.11 which works fine). Does that make things
> > > differently?
> >
> > You should do "make oldconfig" immediately after editing the .config
> > file (AFAIK).  Or the "make menuconfig" might run the oldconfig
> > changes for you.
> 
> Sorry, I was not clear. The procedure was actually I type "make
> ARCH=arm menuconfig" first, then I could not find the CONFIG_ISA,
> CONFIG_NET_SPI and CONFIG_CS89x0 on config screen, this is still
> puzzles me why could "make menuconfig" displays all possible
> configurations on 2.6.22? Could you please explain?

Probably not.

> Because I was not able to add CONFIG_ISA, CONFIG_NET_SPI and
   NET_PCI
> CONFIG_CS89x0 from "make menuconfig", I used vim to manually added
> those and then "make oldconfig".
> 
> > Then I would just double-check the final .config file
> > to make sure that it contains what you expect it to contain.
> 
> Yes, I did double-check with the .config file, all three are =y.

After you ran "make oldconfig" ?


I don't know much about ARM configs.  You should probably be asking
about this on some linux-arm mailing list.

However, I did
  make ARCH=arm s3c2410_defconfig
and that particular board config enables ISA.  Then if I enabled
NET_PCI, I can also enable CS89x0.

The default ARM config (if there is one) doesn't seem to enable ISA.


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


Re: What's in linux-2.6-block.git for 2.6.24

2007-09-24 Thread Torsten Kaiser
On 9/24/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> I will keep on using 2.6.23-rc7-mm1 and post again, if the error shows up 
> again.

On the next boot it did show up again, so 2.6.23-rc7-mm1 still has the bug.

[   33.81] md1: bitmap initialized from disk: read 10/10 pages, set 0 bits
[   33.81] created bitmap (145 pages) for device md1
[   63.91] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[   63.91] ata1.00: cmd 61/08:00:09:d6:42/00:00:25:00:00/40 tag 0
cdb 0x0 data 4096 out
[   63.91]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[   63.91] ata1.00: status: {DRDY }
[   63.91] ata1: hard resetting link
[   66.21] ata1: softreset failed (port not ready)
[   66.21] ata1: reset failed (errno=-5), retrying in 8 secs
[   73.91] ata1: hard resetting link
[   76.21] ata1: softreset failed (port not ready)
[   76.21] ata1: reset failed (errno=-5), retrying in 8 secs
[   83.91] ata1: hard resetting link
[   86.21] ata1: softreset failed (port not ready)
[   86.21] ata1: reset failed (errno=-5), retrying in 33 secs
[  118.91] ata1: limiting SATA link speed to 1.5 Gbps
[  118.91] ata1: hard resetting link
[  121.21] ata1: softreset failed (port not ready)
[  121.21] ata1: reset failed, giving up
[  121.21] ata1.00: disabled
[  121.21] ata1: EH complete
[  121.21] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
[  121.21] end_request: I/O error, dev sda, sector 625137161
[  121.21] md: super_written gets error=-5, uptodate=0
[  121.21] raid5: Disk failure on sda2, disabling device.
Operation continuing on 2 devices

After that there are many more error like this in the log:
[  135.76] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
[  135.76] end_request: I/O error, dev sda, sector 19551113
[  135.76] Buffer I/O error on device sda2, logical block 1
or:
[  135.76] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
[  135.76] end_request: I/O error, dev sda, sector 19551105

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


[git pull] Input updates for 2.6.23-rc8

2007-09-24 Thread Dmitry Torokhov
Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. There is only one patch
that fixes regression in appletouch driver introduced in previous
release.

Thomas Rohwer (1):
  Input: appletouch - fix idle reset logic

 drivers/input/mouse/appletouch.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

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


Re: 2.6.23-rc6-mm1

2007-09-24 Thread Greg KH
On Sat, Sep 22, 2007 at 02:51:54PM +0530, Satyam Sharma wrote:
> Hi Greg,
> 
> 
> On Tue, 18 Sep 2007, Greg KH wrote:
> > 
> > On Tue, Sep 18, 2007 at 03:04:48PM +0530, Satyam Sharma wrote:
> > > 
> > > But wait ... isn't that a statically-allocated kobject, which were
> > > supposed to be "naughty" in the first place?
> > 
> > Yes it is, if you want to dynamically create it, please do.
> 
> Sorry for being late to reply, but do you still want such a patch (i.e.
> convert static to dynamic allocation)?

Yes, I'll gladly take such patches.

> I read elsewhere on this thread that you'd merge Kamalesh's patch and
> fix it up to also use kobject_name() yourself. But it's a small/trivial
> driver, so I think just converting it to dynamic allocation right now
> itself (when we've noticed it already) is probably better (?)

Sure that would be great to have.

> [ BTW I don't see the fix in your git trees or quilt queue. So I'll
>   make a patch on top of 2.6.23-rc6-mm1 itself. ]

I'm behind in updating my patch queue, sorry, other things came up :(

thanks,

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


Re: [patch 6/7] Linux Kernel Markers - Documentation

2007-09-24 Thread Randy Dunlap

Mathieu Desnoyers wrote:

* Randy Dunlap ([EMAIL PROTECTED]) wrote:

On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:


* Randy Dunlap ([EMAIL PROTECTED]) wrote:

On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:


Christoph Hellwig wrote:

On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:

I think that samples are perfectly fine for documentation and
that the trace example is a good example.  I think that most people
who need something like that would need to customize it for their
specific needs anyway.

We don't seem to be making progress...

Time to bring in a Tie-Breaker :)

Yes.  Is anyone else interested?   :(


I guess that's everyone (except those who are sleeping).

Let's not hold up progress.  Just use samples/ for code.
Would you already have the 


Makefile
samples/Kconfig
samples/Makefile

core code handy per chance ? (and probably Kconfig sourcing in every
arch ?)

Yes.  Here it is.  I'm working on add kprobes to it, but you
can go ahead with markers also.




Hi Randy,

I got everything working and I'm thinking about posting all this stuff
soon. Do you think your patch (having renamed Kbuild to Makefile) is
ready to post ?


Yes, AFAIK it is.  Do you want me to resend it or do you want to
make it patch M/N in your patches?

--
~Randy
Phaedrus says that Quality is about caring.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] New kernel-message logging API

2007-09-24 Thread Vegard Nossum
On 9/23/07, Miguel Ojeda <[EMAIL PROTECTED]> wrote:
> Nice. I would suggest having some kind of standard way to show the
> information on the screen/dmesg. I mean, instead of having plain lines
> being written to the log, having something very short like:

Thanks for the idea. Is this something you want to (manually) insert
in each printk, or would it be passed like a parameter? For the
subsystem part, it might be possible to #define a subsystem name at
the beginning of each file and have printing functions automatically
use this. But otherwise, I think the usefulness of this is perhaps a
little low compared to the effort needed (ie. for this to be useful,
each and every printk of the kernel would need to be changed). Also
notice, even in your examples, that most subsystems/drivers already
prefix their messages to identify the source. Perhaps a better effort
spent would be to go through the ones that are missing this "source"
prefix and fix them?

Vegard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sata_nv,ahci: add the ahci legacy mode support to sata_nv

2007-09-24 Thread Peer Chen
Add the ahci controller legacy mode support to sata_nv.
Move the DIDs of legacy mode from ahci.c to sata_nv.c

The patch base on kernel 2.6.23-rc8

Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
diff -uprN -X linux-2.6.23-rc8-vanilla/Documentation/dontdiff 
linux-2.6.23-rc8-vanilla/drivers/ata/ahci.c linux-2.6.23-rc8/drivers/ata/ahci.c
--- linux-2.6.23-rc8-vanilla/drivers/ata/ahci.c 2007-09-25 11:53:40.0 
-0400
+++ linux-2.6.23-rc8/drivers/ata/ahci.c 2007-09-25 11:53:25.0 -0400
@@ -434,14 +434,6 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(NVIDIA, 0x044d), board_ahci },/* MCP65 */
{ PCI_VDEVICE(NVIDIA, 0x044e), board_ahci },/* MCP65 */
{ PCI_VDEVICE(NVIDIA, 0x044f), board_ahci },/* MCP65 */
-   { PCI_VDEVICE(NVIDIA, 0x045c), board_ahci },/* MCP65 */
-   { PCI_VDEVICE(NVIDIA, 0x045d), board_ahci },/* MCP65 */
-   { PCI_VDEVICE(NVIDIA, 0x045e), board_ahci },/* MCP65 */
-   { PCI_VDEVICE(NVIDIA, 0x045f), board_ahci },/* MCP65 */
-   { PCI_VDEVICE(NVIDIA, 0x0550), board_ahci },/* MCP67 */
-   { PCI_VDEVICE(NVIDIA, 0x0551), board_ahci },/* MCP67 */
-   { PCI_VDEVICE(NVIDIA, 0x0552), board_ahci },/* MCP67 */
-   { PCI_VDEVICE(NVIDIA, 0x0553), board_ahci },/* MCP67 */
{ PCI_VDEVICE(NVIDIA, 0x0554), board_ahci },/* MCP67 */
{ PCI_VDEVICE(NVIDIA, 0x0555), board_ahci },/* MCP67 */
{ PCI_VDEVICE(NVIDIA, 0x0556), board_ahci },/* MCP67 */
@@ -450,10 +442,6 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(NVIDIA, 0x0559), board_ahci },/* MCP67 */
{ PCI_VDEVICE(NVIDIA, 0x055a), board_ahci },/* MCP67 */
{ PCI_VDEVICE(NVIDIA, 0x055b), board_ahci },/* MCP67 */
-   { PCI_VDEVICE(NVIDIA, 0x07f0), board_ahci },/* MCP73 */
-   { PCI_VDEVICE(NVIDIA, 0x07f1), board_ahci },/* MCP73 */
-   { PCI_VDEVICE(NVIDIA, 0x07f2), board_ahci },/* MCP73 */
-   { PCI_VDEVICE(NVIDIA, 0x07f3), board_ahci },/* MCP73 */
{ PCI_VDEVICE(NVIDIA, 0x07f4), board_ahci },/* MCP73 */
{ PCI_VDEVICE(NVIDIA, 0x07f5), board_ahci },/* MCP73 */
{ PCI_VDEVICE(NVIDIA, 0x07f6), board_ahci },/* MCP73 */
@@ -462,10 +450,6 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(NVIDIA, 0x07f9), board_ahci },/* MCP73 */
{ PCI_VDEVICE(NVIDIA, 0x07fa), board_ahci },/* MCP73 */
{ PCI_VDEVICE(NVIDIA, 0x07fb), board_ahci },/* MCP73 */
-   { PCI_VDEVICE(NVIDIA, 0x0ad0), board_ahci },/* MCP77 */
-   { PCI_VDEVICE(NVIDIA, 0x0ad1), board_ahci },/* MCP77 */
-   { PCI_VDEVICE(NVIDIA, 0x0ad2), board_ahci },/* MCP77 */
-   { PCI_VDEVICE(NVIDIA, 0x0ad3), board_ahci },/* MCP77 */
{ PCI_VDEVICE(NVIDIA, 0x0ad4), board_ahci },/* MCP77 */
{ PCI_VDEVICE(NVIDIA, 0x0ad5), board_ahci },/* MCP77 */
{ PCI_VDEVICE(NVIDIA, 0x0ad6), board_ahci },/* MCP77 */
diff -uprN -X linux-2.6.23-rc8-vanilla/Documentation/dontdiff 
linux-2.6.23-rc8-vanilla/drivers/ata/sata_nv.c 
linux-2.6.23-rc8/drivers/ata/sata_nv.c
--- linux-2.6.23-rc8-vanilla/drivers/ata/sata_nv.c  2007-09-25 
11:31:03.0 -0400
+++ linux-2.6.23-rc8/drivers/ata/sata_nv.c  2007-09-25 11:19:48.0 
-0400
@@ -266,6 +266,7 @@ static void nv_adma_tf_read(struct ata_p
 enum nv_host_type
 {
GENERIC,
+   AHCI_LEG,
NFORCE2,
NFORCE3 = NFORCE2,  /* NF2 == NF3 as far as sata_nv is concerned */
CK804,
@@ -287,6 +288,29 @@ static const struct pci_device_id nv_pci
{ PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA), GENERIC 
},
{ PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2), GENERIC 
},
{ PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3), GENERIC 
},
+   { PCI_VDEVICE(NVIDIA, 0x45c), AHCI_LEG },   /* MCP65 */
+   { PCI_VDEVICE(NVIDIA, 0x45d), AHCI_LEG },   /* MCP65 */
+   { PCI_VDEVICE(NVIDIA, 0x45e), AHCI_LEG },   /* MCP65 */
+   { PCI_VDEVICE(NVIDIA, 0x45f), AHCI_LEG },   /* MCP65 */
+   { PCI_VDEVICE(NVIDIA, 0x550), AHCI_LEG },   /* MCP67 */
+   { PCI_VDEVICE(NVIDIA, 0x551), AHCI_LEG },   /* MCP67 */
+   { PCI_VDEVICE(NVIDIA, 0x552), AHCI_LEG },   /* MCP67 */
+   { PCI_VDEVICE(NVIDIA, 0x553), AHCI_LEG },   /* MCP67 */
+   { PCI_VDEVICE(NVIDIA, 0x7f0), AHCI_LEG },   /* MCP73 */
+   { PCI_VDEVICE(NVIDIA, 0x7f1), AHCI_LEG },   /* MCP73 */
+   { PCI_VDEVICE(NVIDIA, 0x7f2), AHCI_LEG },   /* MCP73 */
+   { PCI_VDEVICE(NVIDIA, 0x7f3), AHCI_LEG },   /* MCP73 */
+   { PCI_VDEVICE(NVIDIA, 0xad0), 

Re: [PATCH] leds: add missing header

2007-09-24 Thread Pierre Ossman
On Tue, 25 Sep 2007 00:09:12 +0100
Richard Purdie <[EMAIL PROTECTED]> wrote:

> On Sun, 2007-09-23 at 08:14 +0200, Pierre Ossman wrote:
> > rwlocks are used in the structures so make sure the right header
> > is included.
> > 
> > Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
> 
> I think something similar was already committed in revision
> df96efd73b81b8bc2d23b3d8b6025cce3d43db6c.
> 

Indeed. I guess sometimes the solution to your problems is just a pull
away. ;)

-- 
 -- Pierre Ossman

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


[git patches] net driver fixes

2007-09-24 Thread Jeff Garzik

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
upstream-linus

to receive the following updates:

 drivers/net/pcmcia/3c589_cs.c |2 +-
 drivers/net/r8169.c   |   14 +-
 drivers/net/sky2.c|   37 -
 drivers/net/sky2.h|2 +-
 4 files changed, 39 insertions(+), 16 deletions(-)

Edward Hsu (1):
  r8169: correct phy parameters for the 8110SC

Francois Romieu (1):
  r8169: workaround against ignored TxPoll writes (8168)

Jeff Garzik (1):
  Revert "drivers/net/pcmcia/3c589_cs: fix port configuration switcheroo"

Stephen Hemminger (2):
  sky2: FE+ Phy initialization
  sky2: be more selective about FIFO watchdog

diff --git a/drivers/net/pcmcia/3c589_cs.c b/drivers/net/pcmcia/3c589_cs.c
index c06cae3..503f268 100644
--- a/drivers/net/pcmcia/3c589_cs.c
+++ b/drivers/net/pcmcia/3c589_cs.c
@@ -116,7 +116,7 @@ struct el3_private {
 spinlock_t lock;
 };
 
-static const char *if_names[] = { "auto", "10base2", "10baseT", "AUI" };
+static const char *if_names[] = { "auto", "10baseT", "10base2", "AUI" };
 
 /**/
 
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b85ab4a..c921ec3 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1228,7 +1228,10 @@ static void rtl8169_hw_phy_config(struct net_device *dev)
return;
}
 
-   /* phy config for RTL8169s mac_version C chip */
+   if ((tp->mac_version != RTL_GIGA_MAC_VER_02) &&
+   (tp->mac_version != RTL_GIGA_MAC_VER_03))
+   return;
+
mdio_write(ioaddr, 31, 0x0001); //w 31 2 0 1
mdio_write(ioaddr, 21, 0x1000); //w 21 15 0 1000
mdio_write(ioaddr, 24, 0x65c7); //w 24 15 0 65c7
@@ -2567,6 +2570,15 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
(TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
netif_wake_queue(dev);
}
+   /*
+* 8168 hack: TxPoll requests are lost when the Tx packets are
+* too close. Let's kick an extra TxPoll request when a burst
+* of start_xmit activity is detected (if it is not detected,
+* it is slow enough). -- FR
+*/
+   smp_rmb();
+   if (tp->cur_tx != dirty_tx)
+   RTL_W8(TxPoll, NPQ);
}
 }
 
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index eaffe55..0792031 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -338,6 +338,16 @@ static void sky2_phy_init(struct sky2_hw *hw, unsigned 
port)
if (!(hw->flags & SKY2_HW_GIGABIT)) {
/* enable automatic crossover */
ctrl |= PHY_M_PC_MDI_XMODE(PHY_M_PC_ENA_AUTO) >> 1;
+
+   if (hw->chip_id == CHIP_ID_YUKON_FE_P &&
+   hw->chip_rev == CHIP_REV_YU_FE2_A0) {
+   u16 spec;
+
+   /* Enable Class A driver for FE+ A0 */
+   spec = gm_phy_read(hw, port, 
PHY_MARV_FE_SPEC_2);
+   spec |= PHY_M_FESC_SEL_CL_A;
+   gm_phy_write(hw, port, PHY_MARV_FE_SPEC_2, 
spec);
+   }
} else {
/* disable energy detect */
ctrl &= ~PHY_M_PC_EN_DET_MSK;
@@ -816,7 +826,8 @@ static void sky2_mac_init(struct sky2_hw *hw, unsigned port)
sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_CLR);
sky2_write16(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_OPER_ON);
 
-   if (!(hw->flags & SKY2_HW_RAMBUFFER)) {
+   /* On chips without ram buffer, pause is controled by MAC level */
+   if (sky2_read8(hw, B2_E_0) == 0) {
sky2_write8(hw, SK_REG(port, RX_GMF_LP_THR), 768/8);
sky2_write8(hw, SK_REG(port, RX_GMF_UP_THR), 1024/8);
 
@@ -1271,7 +1282,7 @@ static int sky2_up(struct net_device *dev)
struct sky2_port *sky2 = netdev_priv(dev);
struct sky2_hw *hw = sky2->hw;
unsigned port = sky2->port;
-   u32 imask;
+   u32 imask, ramsize;
int cap, err = -ENOMEM;
struct net_device *otherdev = hw->dev[sky2->port^1];
 
@@ -1326,13 +1337,12 @@ static int sky2_up(struct net_device *dev)
 
sky2_mac_init(hw, port);
 
-   if (hw->flags & SKY2_HW_RAMBUFFER) {
-   /* Register is number of 4K blocks on internal RAM buffer. */
-   u32 ramsize = sky2_read8(hw, B2_E_0) * 4;
+   /* Register is number of 4K blocks on internal RAM buffer. */
+   ramsize = sky2_read8(hw, B2_E_0) * 4;
+   if (ramsize > 0) {
u32 rxspace;
 
-   printk(KERN_DEBUG PFX "%s: ram buffer %dK\n", 

lib-y vs EXPORT_SYMBOL: who wins?

2007-09-24 Thread Rusty Russell
Various files under lib/ are linked into a .a so they only get linked if
needed.  But many of these functions are also EXPORT_SYMBOL()ed.

This doesn't really make sense: if it's exported it really needs to be
present.  Certain configurations can hit this (lguest uses kasprintf,
and can be a module).

We could do something hacky and try to figure out if any modules need
the symbols, which screws modules built later, but is no worse than a
CONFIG_-based solution.

Or to we just move all the exported functions out of the .a?

Cheers,
Rusty.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] New kernel-message logging API

2007-09-24 Thread linux
> I don't know. Compare the following two lines:
> 
> printk(KERN_INFO "Message.\n");
> kprint_info("Message.");
> 
> By dropping the lengthy macro (it's not like it's going to change
> while we're running anyway, so why not make it a part of the function
> name?) and the final newline, we actually end up with a net decrease
> in line length.

Agreed.  In fact, you may want to write a header that implements the
kprint_ functions in terms of printk for out-of-core driver writers to
incorporate into their code bases, so they can  upgrade their API while
maintaining backward compatibility.  (If it were me, I'd also give it
a very permissive license, like outright public domain, to encourage use.)

> I thought it would be nice to have something that looks familiar,
> since that would ease an eventual transition. klog is a valid
> alternative, but isn't kp a bit cryptic?

Well, in context:
kp_info("Message.");

Even the "kp_" prefix is actually pretty unnecessary.  It's "info"
and a human-readable string that make it recognizable as a log message.

Another reason to keep it short is just that it's going to get typed a LOT.

Anyway, just MHO.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/3] Virtualization config cleanup: Select CONFIG_PARAVIRT when required

2007-09-24 Thread Rusty Russell
On Tue, 2007-09-25 at 06:26 +0200, Adrian Bunk wrote:
> On Tue, Sep 25, 2007 at 02:20:03PM +1000, Rusty Russell wrote:
> > On Tue, 2007-09-25 at 06:05 +0200, Adrian Bunk wrote:
> > > depends on !(X86_VISWS || X86_VOYAGER)
> > 
> > Hmm, if A selects B and B depends on C, does A not depend on C?
> 
> No.

OK, here 'tis:
===
Normalize config options for guest support

1) Group all the "guest OS" support options together, under a PARAVIRT_GUEST
   menu.
2) Make those options select CONFIG_PARAVIRT, as suggested by Andi.
3) Make kconfig help titles consistent.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
 arch/i386/Kconfig |   33 -
 arch/i386/xen/Kconfig |1 +
 2 files changed, 21 insertions(+), 13 deletions(-)

diff -r de6df17c6477 arch/i386/Kconfig
--- a/arch/i386/Kconfig Tue Sep 25 14:41:39 2007 +1000
+++ b/arch/i386/Kconfig Tue Sep 25 14:41:39 2007 +1000
@@ -215,27 +215,45 @@ endchoice
 endchoice
 
 config PARAVIRT
-   bool "Paravirtualization support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL
+   bool
depends on !(X86_VISWS || X86_VOYAGER)
help
- Paravirtualization is a way of running multiple instances of
- Linux on the same machine, under a hypervisor.  This option
- changes the kernel so it can modify itself when it is run
- under a hypervisor, improving performance significantly.
- However, when run without a hypervisor the kernel is
- theoretically slower.  If in doubt, say N.
+ This changes the kernel so it can modify itself when it is run
+ under a hypervisor, potentially improving performance significantly
+ over full virtualization.  However, when run without a hypervisor
+ the kernel is theoretically slower and slightly larger.
+
+menuconfig PARAVIRT_GUEST
+   bool "Paravirtualized guest support"
+   help
+ Say Y here to get to see options related to running Linux under
+ various hypervisors.  This option alone does not add any kernel code.
+
+ If you say N, all options in this submenu will be skipped and 
disabled.
+
+if PARAVIRT_GUEST
 
 source "arch/i386/xen/Kconfig"
 
 config VMI
-   bool "VMI Paravirt-ops support"
-   depends on PARAVIRT
+   bool "VMI Guest support"
+   select PARAVIRT
+   depends on !(X86_VISWS || X86_VOYAGER)
help
  VMI provides a paravirtualized interface to the VMware ESX server
  (it could be used by other hypervisors in theory too, but is not
  at the moment), by linking the kernel to a GPL-ed ROM module
  provided by the hypervisor.
+
+config LGUEST_GUEST
+   bool "Lguest guest support"
+   select PARAVIRT
+   depends on !X86_PAE
+   help
+ Lguest is a tiny in-kernel hypervisor.  Selecting this will
+ allow your kernel to boot under lguest.  This option will increase
+ your kernel size by about 6k.  If in doubt, say N.
+endif
 
 config ACPI_SRAT
bool
diff -r de6df17c6477 arch/i386/xen/Kconfig
--- a/arch/i386/xen/Kconfig Tue Sep 25 14:41:39 2007 +1000
+++ b/arch/i386/xen/Kconfig Tue Sep 25 14:42:41 2007 +1000
@@ -3,8 +3,9 @@
 #
 
 config XEN
-   bool "Enable support for Xen hypervisor"
-   depends on PARAVIRT && X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES
+   bool "Xen guest support"
+   select PARAVIRT
+   depends on X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES && 
!(X86_VISWS || X86_VOYAGER)
help
  This is the Linux Xen port.  Enabling this will allow the
  kernel to boot in a paravirtualized environment under the
diff -r de6df17c6477 drivers/lguest/Kconfig
--- a/drivers/lguest/KconfigTue Sep 25 14:41:39 2007 +1000
+++ b/drivers/lguest/KconfigTue Sep 25 14:41:39 2007 +1000
@@ -1,7 +1,6 @@ config LGUEST
 config LGUEST
tristate "Linux hypervisor example code"
-   depends on X86 && PARAVIRT && EXPERIMENTAL && !X86_PAE && FUTEX
-   select LGUEST_GUEST
+   depends on X86 && EXPERIMENTAL && !X86_PAE && FUTEX && !(X86_VISWS || 
X86_VOYAGER)
select HVC_DRIVER
---help---
  This is a very simple module which allows you to run


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Patches for tiny 386 kernels, again. Linux kernel 2.6.22.7

2007-09-24 Thread Andrey Panin
On 267, 09 24, 2007 at 03:09:17PM -0400, Dave Jones wrote:
> On Mon, Sep 24, 2007 at 01:51:17AM -0700, Jonathan Campbell wrote:
> 
> 
>  > +#if defined(__i386__) && defined(CONFIG_DMI)
>  >dmi_check_system(acpi_dmi_table);
>  >  #endif
>  >  
>  > +#ifdef CONFIG_DMI
>  >dmi_scan_machine();
>  > +#endif
>  >  
>  > +#ifdef CONFIG_DMI
>  >/* Check and install the TSC clocksource */
>  >dmi_check_system(bad_tsc_dmi_table);
>  > +#endif
>  >  
>  > +#ifdef CONFIG_DMI
>  >dmi_check_system(acpi_osl_dmi_table);
>  > +#endif
>  
> Instead of adding all these ifdefs, we could just define
> add something along the lines of..
> 
> #ifndef CONFIG_DMI
> #define dmi_check_system do {} while (0)
> #endif
> 
> in some header, which hides the uglies away from the code
> whilst having the same net effect.

Let take a look at linux/dmi.h:

#ifdef CONFIG_DMI

extern int dmi_check_system(struct dmi_system_id *list);
extern char * dmi_get_system_info(int field);
extern struct dmi_device * dmi_find_device(int type, const char *name,
struct dmi_device *from);
extern void dmi_scan_machine(void);
extern int dmi_get_year(int field);
extern int dmi_name_in_vendors(char *str);

#else

static inline int dmi_check_system(struct dmi_system_id *list) { return 0; }
static inline char * dmi_get_system_info(int field) { return NULL; }
static inline struct dmi_device * dmi_find_device(int type, const char *name,
struct dmi_device *from) { return NULL; }
static inline int dmi_get_year(int year) { return 0; }
static inline int dmi_name_in_vendors(char *s) { return 0; }

#endif

-- 
Andrey Panin| Linux and UNIX system administrator
[EMAIL PROTECTED]   | PGP key: wwwkeys.pgp.net


signature.asc
Description: Digital signature


Re: [PATCH] Delay creation of khcvd thread

2007-09-24 Thread Stephen Rothwell
Hi Rusty,

On Tue, 25 Sep 2007 14:27:41 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> HVC console is also used by iSeries, so add that to HVC_DRIVER help.
> 
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
> 
> diff -r 85d39cbbd21c drivers/char/Kconfig
> --- a/drivers/char/KconfigTue Sep 25 14:23:07 2007 +1000
> +++ b/drivers/char/KconfigTue Sep 25 14:26:01 2007 +1000
> @@ -569,7 +569,7 @@ config HVC_DRIVER
>   bool
>   help
> Generic "hypervisor virtual console" infrastructure for various
> -   hypervisors (pSeries, Xen, lguest).
> +   hypervisors (pSeries, iSeries, Xen, lguest).
> It will automatically be selected if one of the back-end console 
> drivers
> is selected.

Acked-by: Stephen Rothwell <[EMAIL PROTECTED]>

;-)
-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgp2Rp8ENXv8U.pgp
Description: PGP signature


Re: [PATCH 1/4] module: implement module_inhibit_unload()

2007-09-24 Thread Rusty Russell
On Tue, 2007-09-25 at 12:36 +0900, Tejun Heo wrote:
> Rusty Russell wrote:
> > As stated you cannot protect arbitrary code this way, as you are trying
> > to do.  I do not think you've broken any of the current code, but I
> > cannot tell.  You're certainly going to surprise unsuspecting future
> > authors.
> 
> Can you elaborate a bit?  Why can't it protect the code?

Because you don't know what that code does.  After all, it's assumed
that module code doesn't get called after exit and you're deliberately
violating that assumption.

> > Can you really not figure out the module owner of the sysfs entry to inc
> > its use count during this procedure?  (__module_get()).
> 
> I can but I don't think it's worth the effort.  It will involve passing
> @owner parameter down through kobject to sysfs but the path is pretty
> obscure and thus difficult to test.

Have you tested that *this* path works?  Let's take your first change as
an example:

+   mutex_lock(>reg_mutex);
+   __ccwgroup_remove_symlinks(gdev);
+   device_unregister(dev);
+   mutex_unlock(>reg_mutex);

Now, are you sure that calling cleanup_ccwgroup just after
device_unregister() works?

static void __exit
cleanup_ccwgroup (void)
{
bus_unregister (_bus_type);
}

> I think it's too much work for the
> users of the API and it will be easy to pass the wrong @owner and go
> unnoticed.

But your shortcut insists that all module authors be aware that
functions can be running after exit() is called.  That's a recipe for
instability and disaster.

Rusty.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Delay creation of khcvd thread

2007-09-24 Thread Rusty Russell
On Tue, 2007-09-25 at 14:04 +1000, Stephen Rothwell wrote:
> On Tue, 25 Sep 2007 13:46:24 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote:
> >
> > hvc_console used to only be for Power aka pSeries: now lguest and Xen
> 
> Also legacy iSeries :-)

OK, how's this:
---
HVC console is also used by iSeries, so add that to HVC_DRIVER help.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>

diff -r 85d39cbbd21c drivers/char/Kconfig
--- a/drivers/char/Kconfig  Tue Sep 25 14:23:07 2007 +1000
+++ b/drivers/char/Kconfig  Tue Sep 25 14:26:01 2007 +1000
@@ -569,7 +569,7 @@ config HVC_DRIVER
bool
help
  Generic "hypervisor virtual console" infrastructure for various
- hypervisors (pSeries, Xen, lguest).
+ hypervisors (pSeries, iSeries, Xen, lguest).
  It will automatically be selected if one of the back-end console 
drivers
  is selected.
 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/3] Virtualization config cleanup: Select CONFIG_PARAVIRT when required

2007-09-24 Thread Adrian Bunk
On Tue, Sep 25, 2007 at 02:20:03PM +1000, Rusty Russell wrote:
> On Tue, 2007-09-25 at 06:05 +0200, Adrian Bunk wrote:
> > depends on !(X86_VISWS || X86_VOYAGER)
> 
> Hmm, if A selects B and B depends on C, does A not depend on C?

No.

> If not, I'll patch this...
> 
> Thanks,
> Rusty.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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


Re: [PATCH 1/3] Virtualization config cleanup: Select CONFIG_PARAVIRT when required

2007-09-24 Thread Rusty Russell
On Tue, 2007-09-25 at 06:05 +0200, Adrian Bunk wrote:
> depends on !(X86_VISWS || X86_VOYAGER)

Hmm, if A selects B and B depends on C, does A not depend on C?

If not, I'll patch this...

Thanks,
Rusty.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Virtualization config cleanup: The real patch 1/3

2007-09-24 Thread Rusty Russell
OK, I screwed up and sent the old 1/3.  This was supposed to be 1/3, and
there is no 3.  I'm stupid.

Be nice to get acks from Jeremy and Zach as it's their original
penmanship.

Cheers,
Rusty.
---
Normalize config options for guest support

1) Group all the "guest OS" support options together, under a PARAVIRT_GUEST
   menu.
2) Make those options select CONFIG_PARAVIRT, as suggested by Andi.
3) Make kconfig help titles consistent.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
 arch/i386/Kconfig |   33 -
 arch/i386/xen/Kconfig |1 +
 2 files changed, 21 insertions(+), 13 deletions(-)

diff -r 1c1fc74a471c arch/i386/Kconfig
--- a/arch/i386/Kconfig Tue Sep 25 14:05:39 2007 +1000
+++ b/arch/i386/Kconfig Tue Sep 25 14:06:19 2007 +1000
@@ -215,27 +215,44 @@ endchoice
 endchoice
 
 config PARAVIRT
-   bool "Paravirtualization support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL
+   bool
depends on !(X86_VISWS || X86_VOYAGER)
help
- Paravirtualization is a way of running multiple instances of
- Linux on the same machine, under a hypervisor.  This option
- changes the kernel so it can modify itself when it is run
- under a hypervisor, improving performance significantly.
- However, when run without a hypervisor the kernel is
- theoretically slower.  If in doubt, say N.
+ This changes the kernel so it can modify itself when it is run
+ under a hypervisor, potentially improving performance significantly
+ over full virtualization.  However, when run without a hypervisor
+ the kernel is theoretically slower and slightly larger.
+
+menuconfig PARAVIRT_GUEST
+   bool "Paravirtualized guest support"
+   help
+ Say Y here to get to see options related to running Linux under
+ various hypervisors.  This option alone does not add any kernel code.
+
+ If you say N, all options in this submenu will be skipped and 
disabled.
+
+if PARAVIRT_GUEST
 
 source "arch/i386/xen/Kconfig"
 
 config VMI
-   bool "VMI Paravirt-ops support"
-   depends on PARAVIRT
+   bool "VMI Guest support"
+   select PARAVIRT
help
  VMI provides a paravirtualized interface to the VMware ESX server
  (it could be used by other hypervisors in theory too, but is not
  at the moment), by linking the kernel to a GPL-ed ROM module
  provided by the hypervisor.
+
+config LGUEST_GUEST
+   bool "Lguest guest support"
+   select PARAVIRT
+   depends on !X86_PAE
+   help
+ Lguest is a tiny in-kernel hypervisor.  Selecting this will
+ allow your kernel to boot under lguest.  This option will increase
+ your kernel size by about 6k.  If in doubt, say N.
+endif
 
 config ACPI_SRAT
bool
diff -r 1c1fc74a471c arch/i386/xen/Kconfig
--- a/arch/i386/xen/Kconfig Tue Sep 25 14:05:39 2007 +1000
+++ b/arch/i386/xen/Kconfig Tue Sep 25 14:06:19 2007 +1000
@@ -3,8 +3,9 @@
 #
 
 config XEN
-   bool "Enable support for Xen hypervisor"
-   depends on PARAVIRT && X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES
+   bool "Xen guest support"
+   select PARAVIRT
+   depends on X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES
help
  This is the Linux Xen port.  Enabling this will allow the
  kernel to boot in a paravirtualized environment under the
diff -r 1c1fc74a471c drivers/lguest/Kconfig
--- a/drivers/lguest/KconfigTue Sep 25 14:05:39 2007 +1000
+++ b/drivers/lguest/KconfigTue Sep 25 14:05:39 2007 +1000
@@ -1,23 +1,18 @@ config LGUEST
 config LGUEST
tristate "Linux hypervisor example code"
-   depends on X86 && PARAVIRT && EXPERIMENTAL && !X86_PAE && FUTEX
-   select LGUEST_GUEST
+   depends on X86 && EXPERIMENTAL && !X86_PAE && FUTEX
select HVC_DRIVER
---help---
- This is a very simple module which allows you to run
- multiple instances of the same Linux kernel, using the
+ This is a very simple module called lg.ko which allows you to run
+ multiple instances of the Linux kernel, using the
  "lguest" command found in the Documentation/lguest directory.
  Note that "lguest" is pronounced to rhyme with "fell quest",
  not "rustyvisor".  See Documentation/lguest/lguest.txt.
 
+ Usually you would also turn on "Lguest guest support", to create a
+ kernel which can also boot under lguest.
+
  If unsure, say N.  If curious, say M.  If masochistic, say Y.
-
-config LGUEST_GUEST
-   bool
-   help
- The guest needs code built-in, even if the host has lguest
- support as a module.  The drivers are tiny, so we build them
- in too.
 
 config LGUEST_NET
tristate




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

Re: [PATCH 1/2] bnx2: factor out gzip unpacker

2007-09-24 Thread Kyle Moffett

On Sep 24, 2007, at 13:32:23, Lennart Sorensen wrote:

On Fri, Sep 21, 2007 at 11:37:52PM +0100, Denys Vlasenko wrote:

But I compile net/* into bzImage. I like netbooting :)


Isn't it possible to netboot with an initramfs image?  I am pretty  
sure I have seen some systems do exactly that.


Yeah, I've got Debian boxes that have never *not* netbooted (one Dell  
Op^?^?Craptiplex box whose BIOS and ACPI sucks so bad it can't even  
load GRUB/LILO, although Windows somehow works fine).  So they boot  
PXELinux using the PXE boot ROM on the NICs and it loads both a  
kernel and an initramfs into memory.  Kernel is stock Debian and  
hardly has enough built-in to spit at you, let alone find network/ 
disks, but it manages to load everything it needs off the  
automagically-generated initramfs.


Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Remove broken netfilter binary sysctls from bridging code

2007-09-24 Thread Patrick McHardy
Stephen Hemminger wrote:
> On Mon, 24 Sep 2007 18:55:38 +0200
> Patrick McHardy <[EMAIL PROTECTED]> wrote:
> 
>>Eric W. Biederman wrote:
>>
>>>A really good fix would be to remove the binary side and then to
>>>modify brnf_sysctl_call_tables to allocate a temporary ctl_table and
>>>integer on the stack and only set ctl->data after we have normalized
>>>the written value.  But since in practice nothing cares about
>>>the race a better fix probably isn't worth it.
>>
>>
>>I seem to be missing something, the entire brnf_sysctl_call_tables
>>thing looks purely cosmetic to me, wouldn't it be better to simply
>>remove it?
> 
> 
> I agree, removing seems like a better option.  But probably need to go
> through a 3-6mo warning period, since sysctl's are technically an API.


I meant removing brnf_sysctl_call_tables function, not the sysctls
themselves, all it does is change values != 0 to 1. Or did you
actually mean that something in userspace might depend on reading
back the value 1 after writing a value != 0?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [37/50] Fix inet_diag OOPS.

2007-09-24 Thread Patrick McHardy
Dan Merillat wrote:
> On 9/24/07, Greg KH <[EMAIL PROTECTED]> wrote:
> 
>>netlink_run_queue() doesn't handle multiple processes processing the
>>queue concurrently. Serialize queue processing in inet_diag to fix
>>a oops in netlink_rcv_skb caused by netlink_run_queue passing a
>>NULL for the skb.
> 
> 
> I just got this one on 2.6.23-RC1, looks the same to me but posting
> the oops anyway to doublecheck.
> 
> [1015205.245269] RIP: 0010:[]  [] 
> netlink_run_queue+0xb2/0x104
> ...
> [1015205.245315] Call Trace:
> [1015205.245323]  [] :inet_diag:inet_diag_rcv+0x24/0x2f


Yes, this is the same oops. Its fixed in the current -rc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6/7] Linux Kernel Markers - Documentation

2007-09-24 Thread Mathieu Desnoyers
* Randy Dunlap ([EMAIL PROTECTED]) wrote:
> On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:
> 
> > * Randy Dunlap ([EMAIL PROTECTED]) wrote:
> > > On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
> > > 
> > > > Christoph Hellwig wrote:
> > > > > On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:
> > > > >> I think that samples are perfectly fine for documentation and
> > > > >> that the trace example is a good example.  I think that most people
> > > > >> who need something like that would need to customize it for their
> > > > >> specific needs anyway.
> > > > >>
> > > > >> We don't seem to be making progress...
> > > > > 
> > > > > Time to bring in a Tie-Breaker :)
> > > > 
> > > > Yes.  Is anyone else interested?   :(
> > > 
> > > 
> > > I guess that's everyone (except those who are sleeping).
> > > 
> > > Let's not hold up progress.  Just use samples/ for code.
> > 
> > Would you already have the 
> > 
> > Makefile
> > samples/Kconfig
> > samples/Makefile
> > 
> > core code handy per chance ? (and probably Kconfig sourcing in every
> > arch ?)
> 
> Yes.  Here it is.  I'm working on add kprobes to it, but you
> can go ahead with markers also.
> 
> 

Hi Randy,

I got everything working and I'm thinking about posting all this stuff
soon. Do you think your patch (having renamed Kbuild to Makefile) is
ready to post ?

Mathieu

> 
> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Begin infrastructure for kernel code samples in the samples/ directory.
> Add its Kconfig and Kbuild files.
> Source its Kconfig file in all arch/ Kconfigs.
> 
> 
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> ---
>  Makefile   |   10 +++---
>  arch/alpha/Kconfig |2 ++
>  arch/arm/Kconfig   |2 ++
>  arch/avr32/Kconfig |2 ++
>  arch/blackfin/Kconfig  |2 ++
>  arch/cris/Kconfig  |2 ++
>  arch/frv/Kconfig   |2 ++
>  arch/h8300/Kconfig |2 ++
>  arch/i386/Kconfig  |2 ++
>  arch/ia64/Kconfig  |2 ++
>  arch/m32r/Kconfig  |2 ++
>  arch/m68k/Kconfig  |2 ++
>  arch/m68knommu/Kconfig |2 ++
>  arch/mips/Kconfig  |2 ++
>  arch/parisc/Kconfig|2 ++
>  arch/powerpc/Kconfig   |2 ++
>  arch/ppc/Kconfig   |2 ++
>  arch/s390/Kconfig  |2 ++
>  arch/sh/Kconfig|2 ++
>  arch/sh64/Kconfig  |2 ++
>  arch/sparc/Kconfig |2 ++
>  arch/sparc64/Kconfig   |2 ++
>  arch/um/Kconfig|2 ++
>  arch/v850/Kconfig  |2 ++
>  arch/x86_64/Kconfig|2 ++
>  arch/xtensa/Kconfig|3 ++-
>  samples/Kbuild |2 ++
>  samples/Kconfig|   11 +++
>  28 files changed, 70 insertions(+), 4 deletions(-)
> 
> --- linux-2.6.23-rc7.orig/Makefile
> +++ linux-2.6.23-rc7/Makefile
> @@ -436,6 +436,7 @@ drivers-y := drivers/ sound/
>  net-y:= net/
>  libs-y   := lib/
>  core-y   := usr/
> +samples-y:= samples/
>  endif # KBUILD_EXTMOD
>  
>  ifeq ($(dot-config),1)
> @@ -564,10 +565,12 @@ core-y  += kernel/ mm/ fs/ ipc/ security
>  
>  vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
>$(core-y) $(core-m) $(drivers-y) $(drivers-m) \
> -  $(net-y) $(net-m) $(libs-y) $(libs-m)))
> +  $(net-y) $(net-m) $(libs-y) $(libs-m)) \
> +  $(samples-y) $(samples-m))
> +
>  
>  vmlinux-alldirs  := $(sort $(vmlinux-dirs) $(patsubst %/,%,$(filter %/, \
> -  $(init-n) $(init-) \
> +  $(init-n) $(init-) $(samples-n) $(samples-) \
>$(core-n) $(core-) $(drivers-n) $(drivers-) \
>$(net-n)  $(net-)  $(libs-n)$(libs-
>  
> @@ -578,6 +581,7 @@ net-y := $(patsubst %/, %/built-in.o, $
>  libs-y1  := $(patsubst %/, %/lib.a, $(libs-y))
>  libs-y2  := $(patsubst %/, %/built-in.o, $(libs-y))
>  libs-y   := $(libs-y1) $(libs-y2)
> +samples-y:= $(patsubst %/, %/built-in.o, $(samples-y))
>  
>  # Build vmlinux
>  # ---
> @@ -607,7 +611,7 @@ libs-y:= $(libs-y1) $(libs-y2)
>  # System.map is generated to document addresses of all kernel symbols
>  
>  vmlinux-init := $(head-y) $(init-y)
> -vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
> +vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) $(samples-y)
>  vmlinux-all  := $(vmlinux-init) $(vmlinux-main)
>  vmlinux-lds  := arch/$(ARCH)/kernel/vmlinux.lds
>  export KBUILD_VMLINUX_OBJS := $(vmlinux-all)
> --- /dev/null
> +++ linux-2.6.23-rc7/samples/Kbuild
> @@ -0,0 +1,2 @@
> +# Makefile for Linux samples code
> +
> --- /dev/null
> +++ linux-2.6.23-rc7/samples/Kconfig
> @@ -0,0 +1,11 @@
> +# samples/Kconfig
> +
> +menuconfig SAMPLES
> + bool "Sample kernel code"
> + help
> +   You can build and test sample kernel code here.
> +
> +if SAMPLES
> +
> 

Re: [PATCH 1/3] Virtualization config cleanup: Select CONFIG_PARAVIRT when required

2007-09-24 Thread Adrian Bunk
On Tue, Sep 25, 2007 at 01:58:08PM +1000, Rusty Russell wrote:
> (Unless there are complaints, I'll push this as part of the lguest
> patches for 2.6.24, since there are lguest config changes there too).
> 
> Andi points out that PARAVIRT is an option best selected when needed.
> 
> We introduce PARAVIRT_GUEST for the menu itself, and select PARAVIRT
> if the user turns on anything which needs it.
> 
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
> ---
>  arch/i386/Kconfig |   33 -
>  arch/i386/xen/Kconfig |1 +
>  2 files changed, 21 insertions(+), 13 deletions(-)
> 
> ===
> --- a/arch/i386/Kconfig
> +++ b/arch/i386/Kconfig
> @@ -214,24 +214,30 @@ config X86_ES7000
>  
>  endchoice
>  
> -menuconfig PARAVIRT
> +config PARAVIRT
> + bool
> + depends on !(X86_VISWS || X86_VOYAGER)
> + help
> +   This changes the kernel so it can modify itself when it is run
> +   under a hypervisor, potentially improving performance significantly
> +   over full virtualization.  However, when run without a hypervisor
> +   the kernel is theoretically slower and slightly larger.
> +
> +menuconfig PARAVIRT_GUEST
> - bool "Paravirtualized guest support (EXPERIMENTAL)"
> - depends on EXPERIMENTAL
> + bool "Paravirtualized guest support"
> - depends on !(X86_VISWS || X86_VOYAGER)
> - help
> -   Paravirtualization is a way of running multiple instances of
> -   Linux on the same machine, under a hypervisor.  This option
> -   changes the kernel so it can modify itself when it is run
> -   under a hypervisor, improving performance significantly.
> -   However, when run without a hypervisor the kernel is
> -   theoretically slower.  If in doubt, say N.
> -
> -if PARAVIRT
> + help
> +   Say Y here to get to see options related to running Linux under
> +   various hypervisors.  This option alone does not add any kernel code.
> +
> +   If you say N, all options in this submenu will be skipped and 
> disabled.
> +
> +if PARAVIRT_GUEST
>  
>  source "arch/i386/xen/Kconfig"
>  
>  config VMI
>   bool "VMI Guest support"
> + select PARAVIRT


depends on !(X86_VISWS || X86_VOYAGER)

>   help
> VMI provides a paravirtualized interface to the VMware ESX server
> (it could be used by other hypervisors in theory too, but is not
> @@ -239,6 +246,7 @@ config VMI
>  
>  config LGUEST_GUEST
>   bool "Lguest guest support"
> + select PARAVIRT
>   depends on !X86_PAE


depends on !(X86_VISWS || X86_VOYAGER)

>   help
> Lguest is a tiny in-kernel hypervisor.  Selecting this will
> ===
> --- a/arch/i386/xen/Kconfig
> +++ b/arch/i386/xen/Kconfig
> @@ -4,6 +4,7 @@
>  
>  config XEN
>   bool "Xen guest support"
> + select PARAVIRT
>   depends on X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES

depends on !(X86_VISWS || X86_VOYAGER)

>   help
> This is the Linux Xen port.  Enabling this will allow the

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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


Re: [PATCH] Delay creation of khcvd thread

2007-09-24 Thread Stephen Rothwell
On Tue, 25 Sep 2007 13:46:24 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> hvc_console used to only be for Power aka pSeries: now lguest and Xen

Also legacy iSeries :-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpA4NL0uuHIp.pgp
Description: PGP signature


[PATCH 2/3] Virtualization config cleanup: move lgeust under virtualization menu

2007-09-24 Thread Rusty Russell
Move lguest under the virtualization menu.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
 drivers/Kconfig |2 --
 drivers/kvm/Kconfig |6 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

===
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -87,6 +87,4 @@ source "drivers/kvm/Kconfig"
 source "drivers/kvm/Kconfig"
 
 source "drivers/uio/Kconfig"
-
-source "drivers/lguest/Kconfig"
 endmenu
===
--- a/drivers/kvm/Kconfig
+++ b/drivers/kvm/Kconfig
@@ -45,4 +36,8 @@ config KVM_AMD
  Provides support for KVM on AMD processors equipped with the AMD-V
  (SVM) extensions.
 
-endif # VIRTUALIZATION
+# OK, it's a little counter-intuitive to do this, but it puts it neatly under
+# the virtualization menu.
+source drivers/lguest/Kconfig
+
+endif # VIRTUALIZATION



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] powerpc: ptrace CHECK_FULL_REGS

2007-09-24 Thread Benjamin Herrenschmidt

On Mon, 2007-09-24 at 17:59 -0700, Roland McGrath wrote:
> > Yup, I think I ditched most of them.. for some reason I decided it
> > couldn't happen, but maybe I'm wrong ?
> 
> Well, it's a BUG_ON.  It's supposed to be for something that "can't happen".
> That's why it's a sanity check, not a wild assertion. ;-)
> 
> The 2/2 patch is an example of a bug that CHECK_FULL_REGS catches.
> In the status quo, using PTRACE_PEEKUSR in a bug case crashes while using
> PTRACE_GETREGS in the same place might get bogus data.  (In the actual bug
> thus found, the data is not bogus and only the bit that FULL_REGS checks is.)

Fair enough.

Ben.


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


[PATCH 1/3] Virtualization config cleanup: Select CONFIG_PARAVIRT when required

2007-09-24 Thread Rusty Russell
(Unless there are complaints, I'll push this as part of the lguest
patches for 2.6.24, since there are lguest config changes there too).

Andi points out that PARAVIRT is an option best selected when needed.

We introduce PARAVIRT_GUEST for the menu itself, and select PARAVIRT
if the user turns on anything which needs it.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
 arch/i386/Kconfig |   33 -
 arch/i386/xen/Kconfig |1 +
 2 files changed, 21 insertions(+), 13 deletions(-)

===
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -214,24 +214,30 @@ config X86_ES7000
 
 endchoice
 
-menuconfig PARAVIRT
+config PARAVIRT
+   bool
+   depends on !(X86_VISWS || X86_VOYAGER)
+   help
+ This changes the kernel so it can modify itself when it is run
+ under a hypervisor, potentially improving performance significantly
+ over full virtualization.  However, when run without a hypervisor
+ the kernel is theoretically slower and slightly larger.
+
+menuconfig PARAVIRT_GUEST
-   bool "Paravirtualized guest support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL
+   bool "Paravirtualized guest support"
-   depends on !(X86_VISWS || X86_VOYAGER)
-   help
- Paravirtualization is a way of running multiple instances of
- Linux on the same machine, under a hypervisor.  This option
- changes the kernel so it can modify itself when it is run
- under a hypervisor, improving performance significantly.
- However, when run without a hypervisor the kernel is
- theoretically slower.  If in doubt, say N.
-
-if PARAVIRT
+   help
+ Say Y here to get to see options related to running Linux under
+ various hypervisors.  This option alone does not add any kernel code.
+
+ If you say N, all options in this submenu will be skipped and 
disabled.
+
+if PARAVIRT_GUEST
 
 source "arch/i386/xen/Kconfig"
 
 config VMI
bool "VMI Guest support"
+   select PARAVIRT
help
  VMI provides a paravirtualized interface to the VMware ESX server
  (it could be used by other hypervisors in theory too, but is not
@@ -239,6 +246,7 @@ config VMI
 
 config LGUEST_GUEST
bool "Lguest guest support"
+   select PARAVIRT
depends on !X86_PAE
help
  Lguest is a tiny in-kernel hypervisor.  Selecting this will
===
--- a/arch/i386/xen/Kconfig
+++ b/arch/i386/xen/Kconfig
@@ -4,6 +4,7 @@
 
 config XEN
bool "Xen guest support"
+   select PARAVIRT
depends on X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES
help
  This is the Linux Xen port.  Enabling this will allow the


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

2007-09-24 Thread Rusty Russell
This changes hvc_init() to be called only when someone actually uses
the hvc_console driver.  Dave Jones complained when profiling bootup.

hvc_console used to only be for Power aka pSeries: now lguest and Xen
both want it built-in in case the kernel is a guest under one of
those, even though usually it will be a native boot.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
 drivers/char/Kconfig   |8 ++---
 drivers/char/hvc_console.c |   66 ++--
 2 files changed, 49 insertions(+), 25 deletions(-)

===
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -568,10 +568,10 @@ config HVC_DRIVER
 config HVC_DRIVER
bool
help
- Users of pSeries machines that want to utilize the hvc console 
front-end
- module for their backend console driver should select this option.
+ Generic "hypervisor virtual console" infrastructure for various
+ hypervisors (pSeries, Xen, lguest).
  It will automatically be selected if one of the back-end console 
drivers
  is selected.
 
 
 config HVC_CONSOLE
===
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -68,6 +68,8 @@ static struct task_struct *hvc_task;
 
 /* Picks up late kicks after list walk but before schedule() */
 static int hvc_kicked;
+
+static int hvc_init(void);
 
 #ifdef CONFIG_MAGIC_SYSRQ
 static int sysrq_pressed;
@@ -754,6 +756,13 @@ struct hvc_struct __devinit *hvc_alloc(u
struct hvc_struct *hp;
int i;
 
+   /* We wait until a driver actually comes along */
+   if (!hvc_driver) {
+   int err = hvc_init();
+   if (err)
+   return ERR_PTR(err);
+   }
+
hp = kmalloc(ALIGN(sizeof(*hp), sizeof(long)) + outbuf_size,
GFP_KERNEL);
if (!hp)
@@ -829,16 +838,18 @@ int __devexit hvc_remove(struct hvc_stru
return 0;
 }
 
-/* Driver initialization.  Follow console initialization.  This is where the 
TTY
- * interfaces start to become available. */
-static int __init hvc_init(void)
+/* Driver initialization: called as soon as someone uses hvc_alloc(). */
+static int hvc_init(void)
 {
struct tty_driver *drv;
+   int err;
 
/* We need more than hvc_count adapters due to hotplug additions. */
drv = alloc_tty_driver(HVC_ALLOC_TTY_ADAPTERS);
-   if (!drv)
-   return -ENOMEM;
+   if (!drv) {
+   err = -ENOMEM;
+   goto out;
+   }
 
drv->owner = THIS_MODULE;
drv->driver_name = "hvc";
@@ -854,30 +865,43 @@ static int __init hvc_init(void)
 * added later. */
hvc_task = kthread_run(khvcd, NULL, "khvcd");
if (IS_ERR(hvc_task)) {
-   panic("Couldn't create kthread for console.\n");
-   put_tty_driver(drv);
-   return -EIO;
-   }
-
-   if (tty_register_driver(drv))
-   panic("Couldn't register hvc console driver\n");
-
+   printk(KERN_ERR "Couldn't create kthread for console.\n");
+   err = PTR_ERR(hvc_task);
+   goto put_tty;
+   }
+
+   err = tty_register_driver(drv);
+   if (err) {
+   printk(KERN_ERR "Couldn't register hvc console driver\n");
+   goto stop_thread;
+   }
+
+   /* FIXME: This mb() seems completely random.  Remove it. */
mb();
hvc_driver = drv;
return 0;
-}
-module_init(hvc_init);
+
+put_tty:
+   put_tty_driver(hvc_driver);
+stop_thread:
+   kthread_stop(hvc_task);
+   hvc_task = NULL;
+out:
+   return err;
+}
 
 /* This isn't particularly necessary due to this being a console driver
  * but it is nice to be thorough.
  */
 static void __exit hvc_exit(void)
 {
-   kthread_stop(hvc_task);
-
-   tty_unregister_driver(hvc_driver);
-   /* return tty_struct instances allocated in hvc_init(). */
-   put_tty_driver(hvc_driver);
-   unregister_console(_con_driver);
+   if (hvc_driver) {
+   kthread_stop(hvc_task);
+
+   tty_unregister_driver(hvc_driver);
+   /* return tty_struct instances allocated in hvc_init(). */
+   put_tty_driver(hvc_driver);
+   unregister_console(_con_driver);
+   }
 }
 module_exit(hvc_exit);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/4] module: implement module_inhibit_unload()

2007-09-24 Thread Tejun Heo
Rusty Russell wrote:
> As stated you cannot protect arbitrary code this way, as you are trying
> to do.  I do not think you've broken any of the current code, but I
> cannot tell.  You're certainly going to surprise unsuspecting future
> authors.

Can you elaborate a bit?  Why can't it protect the code?

> Can you really not figure out the module owner of the sysfs entry to inc
> its use count during this procedure?  (__module_get()).

I can but I don't think it's worth the effort.  It will involve passing
@owner parameter down through kobject to sysfs but the path is pretty
obscure and thus difficult to test.  I think it's too much work for the
users of the API and it will be easy to pass the wrong @owner and go
unnoticed.

Thanks.

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


Re: [PATCH 1/4] module: implement module_inhibit_unload()

2007-09-24 Thread Rusty Russell
On Tue, 2007-09-25 at 11:39 +0900, Tejun Heo wrote:
> Rusty Russell wrote:
> >>> I really wonder if an explicit "kill_this_attribute()" is a better way
> >>> to go than this...
> >> I think this sort of temporary unload blocking would be useful for other
> >> cases like this.
> > 
> > I hope not: this doesn't work in general.  Calling into a module after
> > ->exit has called assumes that the exit function doesn't free up or
> > overwrite stuff the other functions need.
> 
> Right, the sole purpose the unload inhibition is to hold onto the 'code'
> section from going away.  The rest of object lifetime management should
> be implemented using separate mechanisms anyway.  I was talking about
> similar cases where the 'code' should be protected for a short time.

As stated you cannot protect arbitrary code this way, as you are trying
to do.  I do not think you've broken any of the current code, but I
cannot tell.  You're certainly going to surprise unsuspecting future
authors.

Can you really not figure out the module owner of the sysfs entry to inc
its use count during this procedure?  (__module_get()).

Rusty.

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


Re: Re: [PATCH] ahci: Add MCP79 support to AHCI driver

2007-09-24 Thread Peer Chen
Yes,they all belong to AHCI controllers, 4 of them use ahci class code and 
others use RAID class code.

--   
Peer Chen
2007-09-25

-
·¢¼þÈË£ºSergei Shtylyov
·¢ËÍÈÕÆÚ£º2007-09-24 20:53:44
ÊÕ¼þÈË£ºPeer Chen
³­ËÍ£ºAlan Cox; linux-kernel; linux-ide; akpm; jeff
Ö÷Ì⣺Re: [PATCH] ahci: Add MCP79 support to AHCI driver

Hello.

Peer Chen wrote:

> Code change, remove some Device IDs.

> Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
> ---
> --- linux-2.6.23-rc7/drivers/ata/ahci.c.orig  2007-09-20 11:01:55.0 
> -0400
> +++ linux-2.6.23-rc7/drivers/ata/ahci.c   2007-09-24 10:08:03.0 
> -0400
> @@ -472,6 +472,14 @@ static const struct pci_device_id ahci_p
>   { PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci },/* MCP77 */
>   { PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci },/* MCP77 */
>   { PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci },/* MCP77 */
> + { PCI_VDEVICE(NVIDIA, 0x0ab8), board_ahci },/* MCP79 */
> + { PCI_VDEVICE(NVIDIA, 0x0ab9), board_ahci },/* MCP79 */
> + { PCI_VDEVICE(NVIDIA, 0x0aba), board_ahci },/* MCP79 */
> + { PCI_VDEVICE(NVIDIA, 0x0abb), board_ahci },/* MCP79 */
> + { PCI_VDEVICE(NVIDIA, 0x0abc), board_ahci },/* MCP79 */
> + { PCI_VDEVICE(NVIDIA, 0x0abd), board_ahci },/* MCP79 */
> + { PCI_VDEVICE(NVIDIA, 0x0abe), board_ahci },/* MCP79 */
> + { PCI_VDEVICE(NVIDIA, 0x0abf), board_ahci },/* MCP79 */

I wonder whether all of those 8 IDs belong to AHCI controllers...

MBR, Sergei

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/4] module: implement module_inhibit_unload()

2007-09-24 Thread Tejun Heo
Rusty Russell wrote:
>>> I really wonder if an explicit "kill_this_attribute()" is a better way
>>> to go than this...
>> I think this sort of temporary unload blocking would be useful for other
>> cases like this.
> 
> I hope not: this doesn't work in general.  Calling into a module after
> ->exit has called assumes that the exit function doesn't free up or
> overwrite stuff the other functions need.

Right, the sole purpose the unload inhibition is to hold onto the 'code'
section from going away.  The rest of object lifetime management should
be implemented using separate mechanisms anyway.  I was talking about
similar cases where the 'code' should be protected for a short time.

Thanks.

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


Re: Ethernet driver on 2.6.22

2007-09-24 Thread hce
On 9/25/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Tue, 25 Sep 2007 08:39:07 +1000 hce wrote:
>
> > On 9/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > On Mon, 24 Sep 2007 12:40:07 +1000 hce wrote:
> > >
> > > > Thanks Randy.
> > > >
> > > > On 9/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > > > On Mon, 24 Sep 2007 08:52:36 +1000 hce wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am upgrading from kernel 2.6.11 to 2.6.22 on ARM S3C2400A and 
> > > > > > found
> > > > > > a following issue on 2.6.22.
> > > > > >
> > > > > > On 2.6.11, I selected CONFIG_ISA,  CONFIG_NET_PCI and CONFIG_CS89X0 
> > > > > > to
> > > > > > build  CS8900A Ethernet driver to kernel, it was running perfect.
> > > > > >
> > > > > > But on 2.6.22, I made the same configuration for CS8900A, the 
> > > > > > cs89x0.o
> > > > > > could not be compiled in to the kernel (or as a module when I tried 
> > > > > > to
> > > > > > CONFIG_CS89X0=m) unless I commented out depends statement in
> > > > > > drivers/net/Kconfig. I double checked all three are CONFIG_ISA=y,
> > > > > > CONFIG_NET_PCI=y and CONFIG_CS89X0=y. Any explanation please, was I
> > > > > > missing something here?
> > > > >
> > > > > I didn't look in 2.6.11 Kconfig files, but in 2.6.22, this driver is
> > > > > limited to 3 specific boards:
> > > > >
> > > > > config CS89x0
> > > > > tristate "CS89x0 support"
> > > > > depends on NET_PCI && (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 
> > > > > || ARCH_PNX010X)
> > > >
> > > > The Kconfig for CS89x0 in 2.6.11 is exactly the same as 2.6.22.
> > > >
> > > > > Does ARM S3C2400A qualify as any of those?  (MACH_... or ARCH_...)
> > > >
> > > > I can run CS89x0 for ARM S3C2400 in 2.6.11, at least I can say yes,
> > > > the ARM S3C2400A qualifies those in 2.6.11, I don't know the 2.6.22
> > > > and I hope someone knows 2.6.22 well can answer it.
> > > >
> > > > > (latter: ARCH_PNX010X is not used anywhere else AFAICT)
> > > >
> > > > Yes, but you only need to enable ISA and NET_PCI to use CS89x0.
> > >
> > > Right.
> > >
> > > I don't have any problem building CS89x0 for X86_32:
> > > make defconfig then enable ISA (what!?!?  why not in defconfig?)
> > > and then enable CS89x0.
> >
> > I don't have my embedded system here, I'll try when I get there. But,
> > let me clarify it, did you mean to type "make defconfig" on linux
> > (kernel) directory, and enable ISA, NET_PCI and CS89x0 from the
> > prompt?
> >
> > My procedure was to edit .config to enable ISA, NET_PCI and CS89x0
> > from vim, then type "make menuconfig" and "make oldconfig" (The same
> > procedure I did in 2.6.11 which works fine). Does that make things
> > differently?
>
> You should do "make oldconfig" immediately after editing the .config
> file (AFAIK).  Or the "make menuconfig" might run the oldconfig
> changes for you.

Sorry, I was not clear. The procedure was actually I type "make
ARCH=arm menuconfig" first, then I could not find the CONFIG_ISA,
CONFIG_NET_SPI and CONFIG_CS89x0 on config screen, this is still
puzzles me why could "make menuconfig" displays all possible
configurations on 2.6.22? Could you please explain?

Because I was not able to add CONFIG_ISA, CONFIG_NET_SPI and
CONFIG_CS89x0 from "make menuconfig", I used vim to manually added
those and then "make oldconfig".

> Then I would just double-check the final .config file
> to make sure that it contains what you expect it to contain.

Yes, I did double-check with the .config file, all three are =y.

Thanks Randy.

Regards,

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


Re: kswapd high CPU usage with no swap

2007-09-24 Thread Rik van Riel
On Tue, 25 Sep 2007 02:13:42 +0200
Jan Kundrát <[EMAIL PROTECTED]> wrote:

> Hi folks,
> I use a 2.6.22-gentoo-r2 SMP kernel with fglrx 8.40.4 [1],
> tp_smapi-0.32 and ipw3945-1.2.0 on a Thinkpad T60 with dual core
> Intel Core CPU. My root filesystem is XFS stored on an internal SATA
> disk, and I have 1GB of RAM and no swap.
> 
> After several suspend to RAM/resume cycles, the X interface got pretty
> slow today. Looking at the top output, I see that one core was
> completely busy in the "wa" state and according to `ps auxww`, the
> kswapd0 process was in uninterruptable deep sleep.
> 
> I don't use any swap because my applications rarely need more memory
> than I have in my system and using 1GB of swap yielded poor
> performance when it was actually accessed. I know I can tweak VM's
> preferences, but I simply don't feel the need to use swap when I have
> "plenty" of memory.

How much memory did you have in "cached" when you looked
with top (and no swap enabled) ?

If the amount of "cached" memory is very low, it could mean
that your shared libraries are being pushed out of memory,
instead of the kernel swapping out some page that belongs to
only one process.

As for kswapd getting into uninterruptible sleep state, it
will do that all by itself sometimes, without even having
any disk IO going on... that code looks a little suspect,
I will look into it.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: lockdep wierdness...

2007-09-24 Thread Steven Rostedt
On Mon, Sep 24, 2007 at 06:07:38PM -0400, Trond Myklebust wrote:
> I'm seeing lockdep warning about a potential lock inversion between
> >mmap_sem and >i_mutex in NFS (see attachment).
> 
> Unfortunately the basis for the warning appears to be the behaviour in
> ext3(???). AFAICS there is no way for NFS to share an inode->i_mutex
> with ext3. What to do?

Actually this can probably happen just on NFS alone.

> 
> Trond

> ===
> [ INFO: possible circular locking dependency detected ]
> 2.6.23-rc7-g8809e921 #1
> ---
> beagle-build-in/24375 is trying to acquire lock:
>  (>mmap_sem){}, at: [] do_page_fault+0x17d/0x591
> 
> but task is already holding lock:
>  (>i_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #1 (>i_mutex){--..}:
>[] __lock_acquire+0x9f3/0xba6
>[] lock_acquire+0x5f/0x78
>[] __mutex_lock_slowpath+0xe5/0x27a
>[] mutex_lock+0x1c/0x1f
>[] nfs_revalidate_mapping+0x64/0x9c [nfs]
>[] nfs_file_mmap+0x46/0x75 [nfs]
>[] mmap_region+0x1ea/0x3b8
>[] do_mmap_pgoff+0x27b/0x2da
>[] sys_mmap2+0x9b/0xb5
>[] sysenter_past_esp+0x5f/0x99
>[] 0x
> 
> -> #0 (>mmap_sem){}:
>[] __lock_acquire+0x8df/0xba6
>[] lock_acquire+0x5f/0x78
>[] down_read+0x3a/0x4c
>[] do_page_fault+0x17d/0x591
>[] error_code+0x72/0x78
>[] call_filldir+0xac/0xc3 [ext3]
>[] ext3_readdir+0x217/0x5e5 [ext3]
>[] vfs_readdir+0x67/0x93
>[] sys_getdents+0x5f/0x9d
>[] sysenter_past_esp+0x5f/0x99
>[] 0x

The circular lock seems to be this:

#1:

  sys_mmap2:  down_write(>mmap_sem);
  nfs_revalidate_mapping: mutex_lock(>i_mutex);


#0:

  vfs_readdir: mutex_lock(>i_mutex);
   - during the readdir (filldir64), we take a user fault (missing page?)
and call do_page_fault -
  do_page_fault:   down_read(>mmap_sem);


So it does indeed look like a circular locking. Now the question is, "is
this a bug?".  Looking like the inode of #1 must be a file or something
else that you can mmap and the inode of #0 seems it must be a directory.
I would say "no".

Now if you can readdir on a file or mmap a directory, then this could be
an issue.

Otherwise, I'd love to see someone teach lockdep about this issue! ;-)

-- Steve


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


Re: [PATCH 1/4] module: implement module_inhibit_unload()

2007-09-24 Thread Rusty Russell
On Tue, 2007-09-25 at 10:40 +0900, Tejun Heo wrote:
> Rusty Russell wrote:
> > My concern is that you're dropping the module mutex around ->exit now.
> > I don't *think* this should matter, but it's worth considering.
> 
> We always did that.  Before the patch the code segment looked like the
> following.

Hi Tejun,

Thanks, misread patch.

> > I really wonder if an explicit "kill_this_attribute()" is a better way
> > to go than this...
> 
> I think this sort of temporary unload blocking would be useful for other
> cases like this.

I hope not: this doesn't work in general.  Calling into a module after
->exit has called assumes that the exit function doesn't free up or
overwrite stuff the other functions need.

Cheers,
Rusty.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/5] Add fair-user scheduler

2007-09-24 Thread Srivatsa Vaddagiri
On Tue, Sep 25, 2007 at 01:39:39AM +0200, roel wrote:
> > +static int
> > +root_user_share_read_proc(char *page, char **start, off_t off, int count,
> > +int *eof, void *data)
> > +{
> > +   int len;
> > +
> > +   len = sprintf(page, "%d\n", init_task_grp_load);
> > +
> > +   return len;
> > +}
> 
> or use this oneliner:
> 
>   return sprintf(page, "%d\n", init_task_grp_load);

Looks good. Will fix this in a follow-on.patch.

Thanks!

-- 
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] New kernel-message logging API

2007-09-24 Thread Rob Landley
On Monday 24 September 2007 7:10:32 pm Joe Perches wrote:
> On Mon, 2007-09-24 at 18:51 -0500, Rob Landley wrote:
> > > An added pass between gcc preprocessor and compiler could compact
> > > or compress the format string without modifying the conversion
> > > specifications so __attribute__ ((format (printf)) would still work.
> >
> > This does not address my problem.  Spitting out a proprietary hash code
> > instead of a human readable message is not a solution for my use case.
>
> What is your problem Rob?

The single largest space savings in the existing -tiny patches comes from 
removing printk() calls and strings.  I would like to be able to selectively 
do this based on severity level, which is information most existing printk() 
calls already have.  I proposed a minimal change to how printk() works, 
allowing the compiler to remove unused code that wouldn't be below the 
displayed level of printk() anyway in the deployed product so wouldn't 
actually lose any output.

The kernel image is usually already compressed in flash and decompressed to 
dram during boot.  (Not always, sometimes it's run directly out of flash, but 
there's often a speed penalty for doing this, you have to set it up 
specially, and dram is cheaper than flash anyway.)  This means recompressing 
it doesn't help save flash.

If you want to save dram, have printk and associated strings be a function in 
a module that's demand loaded and unloaded again after each call.  Then you 
can foist compression off on userspace, and we're already used to modules 
having to match a given kernel version exactly.  Why come up with new 
infrastructure?

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/4] module: implement module_inhibit_unload()

2007-09-24 Thread Tejun Heo
Rusty Russell wrote:
> On Tue, 2007-09-25 at 08:18 +0900, Tejun Heo wrote:
>>> Given your description of this tool as a "sledgehammer," might it not be
>>> easier to just take and hold module_mutex for the duration of the unload
>>> block?
>> That would be easier but...
>>
>> * It would serialize users of the sledgehammer.
>> * It would block loading modules (which is often more important than
>> unloading them) when things go south.
> 
> My concern is that you're dropping the module mutex around ->exit now.
> I don't *think* this should matter, but it's worth considering.

We always did that.  Before the patch the code segment looked like the
following.

/* Final destruction now noone is using it. */
if (mod->exit != NULL) {
mutex_unlock(_mutex);
mod->exit();
mutex_lock(_mutex);
}   

> I really wonder if an explicit "kill_this_attribute()" is a better way
> to go than this...

I think this sort of temporary unload blocking would be useful for other
cases like this.

Thanks.

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


Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot

2007-09-24 Thread Jeff Garzik

Berck E. Nash wrote:

Greetings,

I get a few million of these on boot-- the system never actually boots.
Works fine in 2.6.23-rc7.

[   50.456012] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[   50.462484] ata2.00: irq_stat 0x4001
[   50.466441] ata2.00: cmd e5/00:00:00:00:00/00:00:00:00:00/a0 tag 0
cdb 0x0 data 0
[   50.466442]  res 51/04:00:01:01:80/00:00:00:00:00/a0 Emask
0x1 (device error)
[   50.481914] ata2.00: status: {DRDY ERR }
[   50.485876] ata2.00: error: {ABRT }
[   50.489533] ata2.00: configured for UDMA/133
[   50.493839] ata2: EH complete

I've attached the entire dmesg and lspci.


Are you "git-friendly"?  A few quick kernel compiles and reboots would 
help us narrow down the problem, given that it's a reproducible regression.


The first step would be to clone the "upstream" branch of 
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git


and see if the problem is reproducible there.  If yes, then you have 
narrowed down the problem to something my ATA devel tree has introduced 
into -mm.


Once the blame has been squared fixed upon me :) you can use git-bisect 
to locate the precise change that broke your setup.


Info at http://kerneltrap.org/node/11753 or 
http://www.kernel.org/pub/software/scm/git/docs/v1.3.3/howto/isolate-bugs-with-bisect.txt

or "man git-bisect"

Jeff


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


Re: [patch 6/7] Linux Kernel Markers - Documentation

2007-09-24 Thread Steven Rostedt
On Mon, Sep 24, 2007 at 06:50:44PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 24, 2007 at 12:49:56PM -0400, Mathieu Desnoyers wrote:
> > Here is some documentation explaining what is/how to use the Linux
> > Kernel Markers.
> 
> As mentioned in the tracing infrastructure thread I don't think
> putting code into Documentation is a good idea.  Either of you really
> should start a sample/ toplevel directory for this kind of stuff
> including a Kconfig menu etc to be able to build these samples as
> part of an allmodconfig.
>

 looking at Documentation/lguest/

 Oh wait, nothing to see here. Move along please.

 ;-)

 -- Steve



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


Re: [RFC] New kernel-message logging API

2007-09-24 Thread Rob Landley
On Monday 24 September 2007 3:37:55 pm Vegard Nossum wrote:
> On 9/24/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-09-24 at 18:43 +0200, Vegard Nossum wrote:
> > > Storing the format-string separately allows us to hash THAT instead of
> > > the formatted (ie. console output) message. Since this will never
> > > change from message to message, it can be looked up in a table or
> > > whatever and allow user-space to do translations without for example
> > > regular expressions.
> >
> > That hash will change with each linux version given the
> > inevitable spelling fixes, message reformatting and such.
>
> But we can keep the old ones too. That shouldn't be much of a problem.
> I mean, it probably wouldn't rely on a hash alone. The format string
> itself can be compared with the translation database.

I point out that the thread started with a comment about how to _reduce_ 
bloat.

Just sayin'.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.22.6 user-mode linux: use address instead of value as argument in os_free_irq_by_cb

2007-09-24 Thread lepton
I added dump_stack and some printk in host kernel. The following is what 
I got when sys_reboot in host kernel is called, the first line is 
printing the process state and ptrace state and pid of the calling
process. the following is the call path.

Sep 22 14:25:49 pc kernel: linux Rptrace:  pid:3698
Sep 22 14:25:49 pc kernel:  [] kernel_halt+0x8/0x24
Sep 22 14:25:49 pc kernel:  [] sys_reboot+0x14c/0x1c7
Sep 22 14:25:49 pc kernel:  [] recalc_sigpending+0xb/0x1d
Sep 22 14:25:49 pc kernel:  [] dequeue_signal+0x9d/0x11b
Sep 22 14:25:49 pc kernel:  []
get_signal_to_deliver+0xe1/0x389
Sep 22 14:25:49 pc kernel:  [] do_notify_resume+0x84/0x5f1
Sep 22 14:25:49 pc kernel:  [] ptrace_notify+0x6f/0x8d
Sep 22 14:25:49 pc kernel:  [] syscall_call+0x7/0xb
Sep 22 14:25:49 pc kernel:  ===
Sep 22 14:25:50 pc kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache
Sep 22 14:25:50 pc kernel: sd 1:0:0:0: [sda] Stopping disk
Sep 22 14:25:51 pc kernel: System halted.

On Mon, Sep 24, 2007 at 01:02:20PM -0400, Jeff Dike wrote:
> I would say that you shouldn't be running UMLs as root.  However, a
> sys_reboot shouldn't escape being ptraced either.  This is a bug, but
> I don't see any connection between it and ptrace missing a final
> system call.
> 
>   Jeff
> 
> -- 
> Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/2] powerpc: ptrace CHECK_FULL_REGS

2007-09-24 Thread Roland McGrath
> Yup, I think I ditched most of them.. for some reason I decided it
> couldn't happen, but maybe I'm wrong ?

Well, it's a BUG_ON.  It's supposed to be for something that "can't happen".
That's why it's a sanity check, not a wild assertion. ;-)

The 2/2 patch is an example of a bug that CHECK_FULL_REGS catches.
In the status quo, using PTRACE_PEEKUSR in a bug case crashes while using
PTRACE_GETREGS in the same place might get bogus data.  (In the actual bug
thus found, the data is not bogus and only the bit that FULL_REGS checks is.)


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


Missing PCIe interface in lspci

2007-09-24 Thread Larry Finger
In the process of advising a user on getting a BCM4311 wireless device to work 
with bcm43xx rather
than ndiswrapper, the device stopped appearing in an lspci output. The 'lspci 
-vn' output
for this device before this failure was:

03:00.0 0280: 14e4:4311 (rev 01)
Subsystem: 103c:1363
Flags: fast devsel, IRQ 21
Memory at b800 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 2
Capabilities: [58] Message Signalled Interrupts: Mask- 64bit-
Queue=0/0 Enable-
Capabilities: [d0] Express Legacy Endpoint IRQ 0

Fortunately, the "customer" has two identical machines. Swapping the wireless 
cards showed that both
BCM4311s work in the other computer, but neither works in the problem machine. 
Kernel Version
2.6.22.4-65.fc7 is used on both.

Doing a line-by-line comparison of the dmesg outputs, the only thing that 
stands out is that the line

Allocate Port Service[:00:03.0:pcie03]

is missing on the faulty computer. This is the bridge that should connect to 
the device in question.

The BIOS has been reset and reflashed without helping the problem.

Is there anything other than some failure on the motherboard that would lead to 
this situation? Is
there anything that we can try? The BIOS in this machine doesn't have many 
options.


Thanks,

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/


Linux 2.6.23-rc8

2007-09-24 Thread Linus Torvalds

Ok, I think I'm getting close to releasing a real 2.6.23. Things seem to 
have calmed down, and I think Thomas Gleixner may have found the 
suspend/resume regression that has dogged us for a while, so I'm feeling 
happy about things.

Of course, me feeling happy is usually immediately followed by some nasty 
person finding new problems, but I'll just ignore that and enjoy the 
feeling anyway, however fleeting it may be.

The shortlog really is pretty short, and I'm appending the diffstat at the 
end too in case anybody cares, but basically it's just a number of fairly 
small but real fixes, with some support for a few new chips to the sky2 
network driver..

In fact, much of the diffstat is some documentation updates and that sky2 
update. The rest tends to be a few lines, as you can tell..

Linus

---
Alan Cox (2):
  libata: Update the blacklist with a few more devices
  libata-sff: Fix documentation

Alexey Kuznetsov (1):
  [PKT_SCHED]: Fix 'SFQ qdisc crashes with limit of 2 packets'

Alexey Starikovskiy (1):
  ACPI: suspend: consolidate handling of Sx states.

Andi Kleen (1):
  x86_64: Zero extend all registers after ptrace in 32bit entry path.

Avi Kivity (1):
  KVM: Fix virtualization menu help text

Brice Goglin (1):
  myri10ge: Add support for PCI device id 9

Christoph Hellwig (1):
  [XFS] fix valid but harmless sparse warning

Dan Williams (3):
  async_tx: usage documentation and developer notes (v2)
  async_tx: fix dma_wait_for_async_tx
  raid5: fix 2 bugs in ops_complete_biofill

Davide Libenzi (1):
  signalfd simplification

Domen Puncer (1):
  phy: export phy_mii_ioctl

Eric Leblond (1):
  [NETFILTER]: nfnetlink_log: fix sending of multipart messages

Eric Sandeen (1):
  [XFS] fix filestreams on 32-bit boxes

Frans Pop (1):
  ACPI: suspend: consolidate handling of Sx states addendum

H. Peter Anvin (2):
  [x86 setup] Present the canonical video mode number to the kernel
  [acpi] Correct the decoding of video mode numbers in wakeup.S

Herbert Valerio Riedel (1):
  [ARM] 4569/1: ep93xx_gpio_irq_type(): fix spurious enumeration offset for 
FGPIO handling

Herbert Xu (4):
  [PPP] pppoe: Fix double-free on skb after transmit failure
  [PPP] L2TP: Disallow non-UDP datagram sockets
  [PPP] L2TP: Fix skb handling in pppol2tp_recv_core
  [PPP] L2TP: Fix skb handling in pppol2tp_xmit

Jack Morgenstein (1):
  IB/mlx4: Fix data corruption triggered by wrong headroom marking order

Linus Torvalds (3):
  Fix CRLF line endings in Documentation/input/iforce-protocol.txt
  Revert "x86_64: Quicklist support for x86_64"
  Linux 2.6.23-rc8

Maik Broemme (1):
  ACPI: video: remove dmesg spam

Mark Fasheh (3):
  ocfs2: Allow smaller allocations during large writes
  ocfs2: Fix pos/len passed to ocfs2_write_cluster
  ocfs2: Don't double set write parameters

Michael Chan (1):
  [BNX2]: Add PHY workaround for 5709 A1.

Patrick McHardy (1):
  [NETFILTER]: MAINTAINERS update

Paul Bolle (1):
  [x86 setup] Fix typo in arch/i386/boot/header.S

Ralf Baechle (3):
  [MIPS] BCM1480: Export zbbus_mhz.
  [MIPS] BCM1480: include .
  [MIPS] SMTC: Make ack_bad_irq() safe with no IM backstop.

Rui Sousa (1):
  [ARM] 4568/1: fix l2x0 cache invalidate handling of unaligned addresses

Stefan Richter (1):
  ieee1394: ohci1394: fix initialization if built non-modular

Stephen Hemminger (7):
  sky2: fix VLAN receive processing (resend)
  sky2: ethtool speed report bug
  sky2: reorganize chip revision features
  sky2: fe+ chip support
  sky2: receive FIFO checking
  sky2: version 1.18
  missing null termination in power supply uevent

Sunil Mushran (1):
  ocfs2: Pack vote message and response structures

Takashi Iwai (1):
  Convert snd-page-alloc proc file to use seq_file

Thomas Gleixner (2):
  ACPI: disable lower idle C-states across suspend/resume
  clockevents: remove the suspend/resume workaround^Wthinko

Wolfgang Walter (1):
  rpc: fix garbage in printk in svc_tcp_accept()

Zhang Rui (1):
  ACPI: video: _DOS=0 by default to prevent hotkey hang

henry su (1):
  [libata] ahci: add ATI SB800 PCI IDs

---
 Documentation/crypto/async-tx-api.txt   |  219 +
 Documentation/input/iforce-protocol.txt |  508 +++---
 MAINTAINERS |6 +-
 Makefile|2 +-
 arch/arm/mach-ep93xx/core.c |2 +-
 arch/arm/mm/cache-l2x0.c|   12 +-
 arch/i386/boot/header.S |2 +-
 arch/i386/boot/video.c  |   14 +-
 arch/i386/kernel/acpi/wakeup.S  |   41 +--
 arch/mips/kernel/i8259.c|5 +-
 arch/mips/kernel/irq-msc01.c|   10 +-
 arch/mips/kernel/irq.c  |   10 +-
 arch/mips/kernel/smtc.c |5 +-
 

Re: Xen kernel 2.6.23-rc7 bug at xen_mc_flush (arch/i386/xen/multicalls.c:68)

2007-09-24 Thread Jeremy Fitzhardinge
[EMAIL PROTECTED] wrote:
> Using kernel 2.6.23-rc7 as xen domU client system I observe a kernel bug
> which occurs reproducibly when calling a shell from midnight commander F2
> context menu or with testcase given below  (However most other programs seem
> to
> be well behaved and do not trigger this bug). - A kernel compiled with debug
> info gives:
>   

Hm, it just seems that its trying to unpin an mm on the error path of
execve, and so it hasn't been pinned.  The simplest way to reproduce is:

$ echo foo > foo
$ chmod +x foo
$ ./foo

Anyway, try this patch.

J

---
 arch/i386/xen/mmu.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

===
--- a/arch/i386/xen/mmu.c
+++ b/arch/i386/xen/mmu.c
@@ -558,6 +558,9 @@ void xen_exit_mmap(struct mm_struct *mm)
put_cpu();
 
spin_lock(>page_table_lock);
-   xen_pgd_unpin(mm->pgd);
+
+   /* pgd may not be pinned in the error exit path of execve */
+   if (PagePinned(virt_to_page(mm->pgd)))
+   xen_pgd_unpin(mm->pgd);
spin_unlock(>page_table_lock);
 }


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


Re: [PATCH 1/2] powerpc: ptrace CHECK_FULL_REGS

2007-09-24 Thread Benjamin Herrenschmidt

On Mon, 2007-09-24 at 16:50 -0700, Roland McGrath wrote:
> This restores the CHECK_FULL_REGS sanity check to every place that can
> access the nonvolatile GPRs for ptrace.  This is already done for
> native-bitwidth PTRACE_PEEKUSR, but was omitted for many other cases
> (32-bit ptrace, PTRACE_GETREGS, etc.); I think there may have been more
> uniform checks before that were lost in the recent cleanup of GETREGS et al.

Yup, I think I ditched most of them.. for some reason I decided it
couldn't happen, but maybe I'm wrong ?

Cheers,
Ben.

> Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
> ---
>  arch/powerpc/kernel/ptrace.c   |4 
>  arch/powerpc/kernel/ptrace32.c |8 
>  2 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index 8a177bd..40d34b3 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -331,6 +331,7 @@ static long arch_ptrace_old(struct task_struct *child, 
> long request, long addr,
>   unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
>   unsigned long __user *tmp = (unsigned long __user *)addr;
>  
> + CHECK_FULL_REGS(child->thread.regs);
>   for (i = 0; i < 32; i++) {
>   ret = put_user(*reg, tmp);
>   if (ret)
> @@ -346,6 +347,7 @@ static long arch_ptrace_old(struct task_struct *child, 
> long request, long addr,
>   unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
>   unsigned long __user *tmp = (unsigned long __user *)addr;
>  
> + CHECK_FULL_REGS(child->thread.regs);
>   for (i = 0; i < 32; i++) {
>   ret = get_user(*reg, tmp);
>   if (ret)
> @@ -517,6 +519,7 @@ long arch_ptrace(struct task_struct *child, long request, 
> long addr, long data)
>   ret = -EIO;
>   break;
>   }
> + CHECK_FULL_REGS(child->thread.regs);
>   ret = 0;
>   for (ui = 0; ui < PT_REGS_COUNT; ui ++) {
>   ret |= __put_user(ptrace_get_reg(child, ui),
> @@ -537,6 +540,7 @@ long arch_ptrace(struct task_struct *child, long request, 
> long addr, long data)
>   ret = -EIO;
>   break;
>   }
> + CHECK_FULL_REGS(child->thread.regs);
>   ret = 0;
>   for (ui = 0; ui < PT_REGS_COUNT; ui ++) {
>   ret = __get_user(tmp, (unsigned long __user *) data);
> diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
> index 9e6baea..6b86960 100644
> --- a/arch/powerpc/kernel/ptrace32.c
> +++ b/arch/powerpc/kernel/ptrace32.c
> @@ -53,6 +53,7 @@ static long compat_ptrace_old(struct task_struct *child, 
> long request,
>   unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
>   unsigned int __user *tmp = (unsigned int __user *)addr;
>  
> + CHECK_FULL_REGS(child->thread.regs);
>   for (i = 0; i < 32; i++) {
>   ret = put_user(*reg, tmp);
>   if (ret)
> @@ -68,6 +69,7 @@ static long compat_ptrace_old(struct task_struct *child, 
> long request,
>   unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
>   unsigned int __user *tmp = (unsigned int __user *)addr;
>  
> + CHECK_FULL_REGS(child->thread.regs);
>   for (i = 0; i < 32; i++) {
>   ret = get_user(*reg, tmp);
>   if (ret)
> @@ -164,6 +166,7 @@ long compat_sys_ptrace(int request, int pid, unsigned 
> long addr,
>   if ((addr & 3) || (index > PT_FPSCR32))
>   break;
>  
> + CHECK_FULL_REGS(child->thread.regs);
>   if (index < PT_FPR0) {
>   tmp = ptrace_get_reg(child, index);
>   } else {
> @@ -210,6 +213,7 @@ long compat_sys_ptrace(int request, int pid, unsigned 
> long addr,
>   if ((addr & 3) || numReg > PT_FPSCR)
>   break;
>  
> + CHECK_FULL_REGS(child->thread.regs);
>   if (numReg >= PT_FPR0) {
>   flush_fp_to_thread(child);
>   tmp = ((unsigned long int *)child->thread.fpr)[numReg - 
> PT_FPR0];
> @@ -270,6 +274,7 @@ long compat_sys_ptrace(int request, int pid, unsigned 
> long addr,
>   if ((addr & 3) || (index > PT_FPSCR32))
>   break;
>  
> + CHECK_FULL_REGS(child->thread.regs);
>   if (index < PT_FPR0) {
>   ret = ptrace_put_reg(child, index, data);
>   } else {
> @@ -307,6 +312,7 @@ long compat_sys_ptrace(int request, int pid, unsigned 
> long addr,
>*/
>   if ((addr & 3) || (numReg > PT_FPSCR))
>   

Re: [PATCH 2/2] powerpc: FULL_REGS on exec

2007-09-24 Thread Benjamin Herrenschmidt

On Mon, 2007-09-24 at 16:52 -0700, Roland McGrath wrote:
> When PTRACE_O_TRACEEXEC is used, a ptrace call to fetch the registers at
> the PTRACE_EVENT_EXEC stop (PTRACE_PEEKUSR) will oops in CHECK_FULL_REGS.
> With recent versions, "gdb --args /bin/sh -c 'exec /bin/true'" and "run" at
> the (gdb) prompt is sufficient to produce this.  I also have written an
> isolated test case, see 
> https://bugzilla.redhat.com/show_bug.cgi?id=301791#c15.
> 
> This change fixes the problem by clearing the low bit of pt_regs.trap in
> start_thread so that FULL_REGS is true again.  This is correct since all of
> the GPRs that "full" refers to are cleared in start_thread.

Looks good, nice catch.

> Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

> ---
>  arch/powerpc/kernel/process.c |7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index e477c9d..fd799d2 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -605,6 +605,13 @@ void start_thread(struct pt_regs *regs, unsigned long 
> start, unsigned long sp)
>   regs->ccr = 0;
>   regs->gpr[1] = sp;
>  
> + /*
> +  * We have just cleared all the nonvolatile GPRs, so make
> +  * FULL_REGS(regs) return true.  This is necessary to allow
> +  * ptrace to examine the thread immediately after exec.
> +  */
> + regs->trap &= ~1UL;
> +
>  #ifdef CONFIG_PPC32
>   regs->mq = 0;
>   regs->nip = start;
> ___
> Linuxppc-dev mailing list
> [EMAIL PROTECTED]
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/1] x86: Convert cpuinfo_x86 array to a per_cpu array v3

2007-09-24 Thread Dave Jones
On Tue, Sep 25, 2007 at 02:20:01AM +0200, roel wrote:
 
 > >  > >   if ((c->x86_vendor != X86_VENDOR_AMD) || (c->x86 != 5) ||
 > >  > >   ((c->x86_model != 12) && (c->x86_model != 13)))
 > >  > 
 > >  > while we're at it, we could change this to
 > >  > 
 > >  > if (!(c->x86_vendor == X86_VENDOR_AMD && c->x86 == 5 &&
 > >  > (c->x86_model == 12 || c->x86_model == 13)))
 > > 
 > > For what purpose?  There's nothing wrong with the code as it stands,
 > > and inverting the tests means we'd have to move a bunch of
 > > code inside the if arm instead of just returning -ENODEV.
 > 
 > It's not inverting the test, so you don't need to move code. It evaluates 
 > the same, only the combined negation is moved to the front. I suggested it
 > to increase clarity, it results in the same assembly language.

I don't see it as being particularly more readable after this change.
In fact, the reverse, as my previous comment implied, I missed the
initial !
Given this code works fine, and there's no discernable gain from
changing it, I'm not particularly enthusiastic about this modification.

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: 2.6.23-rc6: hanging ext3 dbench tests

2007-09-24 Thread Badari Pulavarty
On Mon, 2007-09-24 at 13:04 -0700, Linus Torvalds wrote:
> 
> On Mon, 24 Sep 2007, Badari Pulavarty wrote:
> > 
> > Whats happening on my machine is ..
> > 
> > dbench forks of 4 children and sends them a signal to start the work.
> > 3 out of 4 children gets the signal and does the work. One of the child
> > never gets the signal so, it waits forever in pause(). So, parent waits
> > for a longtime to kill it.
> 
> Since this *seems* to have nothing to do with the filesystem, and since it 
> *seems* to have been introduced between -rc3 and -rc4, I did
> 
>   gitk v2.6.23-rc3..v2.6.23-rc4 -- kernel/
> 
> to see what has changed. One of the commits was signal-related, and that 
> one doesn't look like it could possibly matter.
> 
> The rest were scheduler-related, which doesn't surprise me. In fact, even 
> before I looked, my reaction to your bug report was "That sounds like an 
> application race condition".
> 
> Applications shouldn't use "pause()" for waiting for a signal. It's a 
> fundamentally racy interface - the signal could have happened just 
> *before* calling pause. So it's almost always a bug to use pause(), and 
> any users should be fixed to use "sigsuspend()" instead, which can 
> atomically (and correctly) pause for a signal while the process has masked 
> it outside of the system call.
> 
> Now, I took a look at the dbench sources, and I have to say that the race 
> looks *very* unlikely (there's quite a small window in which it does
> 
>   children[i].status = getpid();
>   ** race window here **
>   pause();
> 
> and it would require *just* the right timing so that the parent doesn't 
> end up doing the "sleep(1)" (which would make the window even less likely 
> to be hit), but there does seem to be a race condition there. And it 
> *could* be that you just happen to hit it on your hw setup.
> 
> So before you do anything else, does this patch (TOTALLY UNTESTED! DONE 
> ENTIRELY LOOKING AT THE SOURCE! IT MAY RAPE ALL YOUR PETS, AND CALL YOU 
> BAD NAMES!) make any difference?
> 
> (patch against unmodified dbench-2.0)
> 
>   Linus
> 
> ---
> diff --git a/dbench.c b/dbench.c
> index ccf5624..4be5712 100644
> --- a/dbench.c
> +++ b/dbench.c
> @@ -91,10 +91,15 @@ static double create_procs(int nprocs, void (*fn)(struct 
> child_struct * ))
>  
>   for (i=0;i   if (fork() == 0) {
> + sigset_t old, blocked;
> +
> + sigemptyset();
> + sigaddset(, SIGCONT);
> + sigprocmask(SIG_BLOCK, , );
>   setbuffer(stdout, NULL, 0);
>   nb_setup([i]);
>   children[i].status = getpid();
> - pause();
> + sigsuspend();
>   fn([i]);
>   _exit(0);
>   }

With the modified dbench, I couldn't reproduce the problem so far.
I will let it run through the night (just to be sure). 

For now, we can treat it as a tool/App issue :)

Thanks,
Badari

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


kswapd high CPU usage with no swap

2007-09-24 Thread Jan Kundrát
Hi folks,
I use a 2.6.22-gentoo-r2 SMP kernel with fglrx 8.40.4 [1], tp_smapi-0.32
and ipw3945-1.2.0 on a Thinkpad T60 with dual core Intel Core CPU. My
root filesystem is XFS stored on an internal SATA disk, and I have 1GB
of RAM and no swap.

After several suspend to RAM/resume cycles, the X interface got pretty
slow today. Looking at the top output, I see that one core was
completely busy in the "wa" state and according to `ps auxww`, the
kswapd0 process was in uninterruptable deep sleep.

I don't use any swap because my applications rarely need more memory
than I have in my system and using 1GB of swap yielded poor performance
when it was actually accessed. I know I can tweak VM's preferences, but
I simply don't feel the need to use swap when I have "plenty" of memory.

That said, I've googled a thread [2] which recommends using at least a
small swap because VM somehow performs better with it.

So I created a small (12MB) swap on a physical partition on the same
SATA disk and swapon-ed it. The swap got full immediately but the load
didn't get lower. After that, I've turned it off again, adjusted its
size to be about 1GB and enabled it again. Several tens of seconds
later, swap usage was at approximately 350MB and RAM usage at about
60MB. There was no unusual activity at the background (no intensive
cronned jobs, no locate, nothing, just an idle KDE session with bunch of
idling applications). Touching the swappiness value (0, 10, 40, 60 and
100) didn't change anything on the fact that switching from one
application to another was slow, and even moving a mouse cursor
(USB-attached mouse) in X was delayed and not smooth.

Could you please provide a hint about what might cause such problems,
what am I doing wrong and how can I avoid it? If there are any details
like kernel config that are relevant here, I'll happily provide them.
I'd also appreciate if you keep me on the CC as I'm not subscribed to
this list. If this is not an appropriate place to ask, please accept my
apologies.

[1] I'm aware of the fact that fglrx is a binary closed source and that
the kernel is tainted by its usage. Unfortunately no other driver
besides VESA supports my VGA card.
[2] http://www.redhat.com/archives/nahant-list/2006-March/msg00033.html

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth



signature.asc
Description: OpenPGP digital signature


Re: [PATCH 1/1] x86: Convert cpuinfo_x86 array to a per_cpu array v3

2007-09-24 Thread roel
Dave Jones wrote:
>   to add a single line reply>

Ok, sorry, I don't know these rules

> On Tue, Sep 25, 2007 at 12:01:56AM +0200, roel wrote:
> 
>  > > --- a/arch/i386/kernel/cpu/cpufreq/powernow-k6.c
>  > > +++ b/arch/i386/kernel/cpu/cpufreq/powernow-k6.c
>  > > @@ -215,7 +215,7 @@ static struct cpufreq_driver powernow_k6
>  > >   */
>  > >  static int __init powernow_k6_init(void)
>  > >  {
>  > > -struct cpuinfo_x86  *c = cpu_data;
>  > > +struct cpuinfo_x86 *c = _data(0);
>  > >  
>  > >  if ((c->x86_vendor != X86_VENDOR_AMD) || (c->x86 != 5) ||
>  > >  ((c->x86_model != 12) && (c->x86_model != 13)))
>  > 
>  > while we're at it, we could change this to
>  > 
>  >if (!(c->x86_vendor == X86_VENDOR_AMD && c->x86 == 5 &&
>  >(c->x86_model == 12 || c->x86_model == 13)))
> 
> For what purpose?  There's nothing wrong with the code as it stands,
> and inverting the tests means we'd have to move a bunch of
> code inside the if arm instead of just returning -ENODEV.

It's not inverting the test, so you don't need to move code. It evaluates 
the same, only the combined negation is moved to the front. I suggested it
to increase clarity, it results in the same assembly language.

Roel

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


Re: [git] CFS-devel, latest code

2007-09-24 Thread Daniel Walker
On Mon, 2007-09-24 at 23:45 +0200, Ingo Molnar wrote:
> Lots of scheduler updates in the past few days, done by many people. 
> Most importantly, the SMP latency problems reported and debugged by
> Mike 
> Galbraith should be fixed for good now. 

Does this have anything to do with idle balancing ? I noticed some
fairly large latencies in that code in 2.6.23-rc's ..

Daniel

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


Re: [RFC] New kernel-message logging API

2007-09-24 Thread Joe Perches
On Mon, 2007-09-24 at 18:51 -0500, Rob Landley wrote:
> > An added pass between gcc preprocessor and compiler could compact
> > or compress the format string without modifying the conversion
> > specifications so __attribute__ ((format (printf)) would still work.
> This does not address my problem.  Spitting out a proprietary hash code 
> instead of a human readable message is not a solution for my use case.

What is your problem Rob?

I think message numbers are difficult to produce from format strings.
I think kernel version/file/func/line is enough to identify messages
for normal use but not too useful for embedded.

I think losslessly compressing, not hashing, the format string
would be useful.  The format string would be expanded by printk.
The kernel size would be smaller and more easily fit in minimal RAM.
Losslessly compressing the format strings probably won't reduce
flash image size.

cheers, Joe

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


Re: x86_64: potential critical issue with quicklists and page table pages

2007-09-24 Thread Benjamin Herrenschmidt

On Mon, 2007-09-24 at 14:42 -0700, Christoph Lameter wrote:
> On Tue, 25 Sep 2007, Benjamin Herrenschmidt wrote:
> 
> > I'd suggest just reverting the patch for now (well, I see from the
> > commit list that you did just that) and I'll try to come up with
> > something better.
> 
> That would be great. Note that the reversal of the x86_64 quicklist 
> support patch does not address the issue that is (as pointed out by 
> Siddha) in core code and not in x86_64 arch dode. The fix that I posted 
> fixes the core issue.
> 
> > Christoph, I'd be happy if you didn't start butchering mmu_gather just
> > right now since I'm doing just that and it will collide all over the
> > place :-) Or if you want something specific done, please throw
> > ideas/patches at me and I'll integrate that in my serie.
> 
> Any "butchering" was done for 2.6.22. 2.6.23 only added arch support for 
> x86_64 since Andi forgot to merge it for .22. I'd be glad if you could 
> look into this and make quicklists interoperate nicely withh mmu gather.

I'll try, I'll let you know. Give me a few days to finish catching up
with backlog of things before i get back to it though.

Cheers,
Ben.


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


Re: [patch 1/2] Enable link power management for ata drivers

2007-09-24 Thread roel
Davide Libenzi wrote:
> On Tue, 25 Sep 2007, roel wrote:
> 
>>> +   if (!(ap->flags & ATA_FLAG_IPM) || !ata_dev_enabled(dev)) {
>>  if (!((ap->flags & ATA_FLAG_IPM) && ata_dev_enabled(dev))) {
> 
> int foo(int i, int j) {
> 
> return !(i & 8) || !j;
> }
> 
> int moo(int i, int j) {
> 
> return !((i & 8) && j);
> }
> 
> 
> gcc -O2 -S:
> 
> 
> .globl foo
> .type   foo, @function
> foo:
> shrl$3, %edi
> xorl$1, %edi
> testl   %esi, %esi
> sete%al
> orl %eax, %edi
> andl$1, %edi
> movl%edi, %eax
> ret
> .globl moo
> .type   moo, @function
> moo:
> shrl$3, %edi
> xorl$1, %edi
> testl   %esi, %esi
> sete%al
> orl %eax, %edi
> andl$1, %edi
> movl%edi, %eax
> ret

Indeed, no difference, except for the eye. 

do you not consider it an improvement or do you not want to change it?
or
don't you consider it an improvement and want to change it?

Never mind. Disregard if you please.

> - Davide

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


Re: [patch 1/2] Enable link power management for ata drivers

2007-09-24 Thread Jeff Garzik

Kristen Carlson Accardi wrote:

On Tue, 25 Sep 2007 01:12:32 +0200
roel <[EMAIL PROTECTED]> wrote:


 #define ata_id_cdb_intr(id)(((id)[0] & 0x60) == 0x20)
+#define ata_id_has_hipm(id)\
+   ( (((id)[76] != 0x) && ((id)[76] != 0x)) && \
+ ((id)[76] & (1 << 9)) )

^
|
are you sure this
should be 76?


Yes.


we can also change the first statement a bit:
(!(((id)[76] == 0x) || ((id)[76] == 0x)) && \



+#define ata_id_has_dipm(id)\
+   ( (((id)[76] != 0x) && ((id)[76] != 0x)) && \

and:
(!(((id)[76] == 0x) || ((id)[76] == 0x)) && \


I feel this is equivalent functionality and not as readable.


Poke around for Alan Cox's cleanup of this area of linux/ata.h.

It converts several macros to inline functions (encouraged), and also 
illustrates a nice, clean way of testing an ID word's validity. 
[obviously the final implementation varies, depending on that ID word's 
history]


Alan or Andrew, got a copy somewhere?  My feeble search skills don't 
seem to turn it up at the moment, even though I had a copy in my hands 
quite recently.


Jeff


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


[PATCH 2/2] powerpc: FULL_REGS on exec

2007-09-24 Thread Roland McGrath

When PTRACE_O_TRACEEXEC is used, a ptrace call to fetch the registers at
the PTRACE_EVENT_EXEC stop (PTRACE_PEEKUSR) will oops in CHECK_FULL_REGS.
With recent versions, "gdb --args /bin/sh -c 'exec /bin/true'" and "run" at
the (gdb) prompt is sufficient to produce this.  I also have written an
isolated test case, see https://bugzilla.redhat.com/show_bug.cgi?id=301791#c15.

This change fixes the problem by clearing the low bit of pt_regs.trap in
start_thread so that FULL_REGS is true again.  This is correct since all of
the GPRs that "full" refers to are cleared in start_thread.

Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
 arch/powerpc/kernel/process.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index e477c9d..fd799d2 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -605,6 +605,13 @@ void start_thread(struct pt_regs *regs, unsigned long 
start, unsigned long sp)
regs->ccr = 0;
regs->gpr[1] = sp;
 
+   /*
+* We have just cleared all the nonvolatile GPRs, so make
+* FULL_REGS(regs) return true.  This is necessary to allow
+* ptrace to examine the thread immediately after exec.
+*/
+   regs->trap &= ~1UL;
+
 #ifdef CONFIG_PPC32
regs->mq = 0;
regs->nip = start;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC] New kernel-message logging API

2007-09-24 Thread Rob Landley
On Monday 24 September 2007 10:19:16 am Joe Perches wrote:
> On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote:
> > Together with the idea of not allowing multiple lines in the kprint_xxx
> > functions, that would go with our approach having message numbers to
> > identify a message.
>
> How does this equate/give message numbers?

I actively want to avoid giving message numbers.  My interest is in 
selectively removing messages from the kernel to shrink the binary size (and 
NOT make it up in either a larger userspace utility to translate them, or 
else magic proprietary numbers you can only diagnose if you pay my support 
staff).

> An added pass between gcc preprocessor and compiler could compact
> or compress the format string without modifying the conversion
> specifications so __attribute__ ((format (printf)) would still work.

This does not address my problem.  Spitting out a proprietary hash code 
instead of a human readable message is not a solution for my use case.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] powerpc: ptrace CHECK_FULL_REGS

2007-09-24 Thread Roland McGrath

This restores the CHECK_FULL_REGS sanity check to every place that can
access the nonvolatile GPRs for ptrace.  This is already done for
native-bitwidth PTRACE_PEEKUSR, but was omitted for many other cases
(32-bit ptrace, PTRACE_GETREGS, etc.); I think there may have been more
uniform checks before that were lost in the recent cleanup of GETREGS et al.

Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
 arch/powerpc/kernel/ptrace.c   |4 
 arch/powerpc/kernel/ptrace32.c |8 
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 8a177bd..40d34b3 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -331,6 +331,7 @@ static long arch_ptrace_old(struct task_struct *child, long 
request, long addr,
unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
unsigned long __user *tmp = (unsigned long __user *)addr;
 
+   CHECK_FULL_REGS(child->thread.regs);
for (i = 0; i < 32; i++) {
ret = put_user(*reg, tmp);
if (ret)
@@ -346,6 +347,7 @@ static long arch_ptrace_old(struct task_struct *child, long 
request, long addr,
unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
unsigned long __user *tmp = (unsigned long __user *)addr;
 
+   CHECK_FULL_REGS(child->thread.regs);
for (i = 0; i < 32; i++) {
ret = get_user(*reg, tmp);
if (ret)
@@ -517,6 +519,7 @@ long arch_ptrace(struct task_struct *child, long request, 
long addr, long data)
ret = -EIO;
break;
}
+   CHECK_FULL_REGS(child->thread.regs);
ret = 0;
for (ui = 0; ui < PT_REGS_COUNT; ui ++) {
ret |= __put_user(ptrace_get_reg(child, ui),
@@ -537,6 +540,7 @@ long arch_ptrace(struct task_struct *child, long request, 
long addr, long data)
ret = -EIO;
break;
}
+   CHECK_FULL_REGS(child->thread.regs);
ret = 0;
for (ui = 0; ui < PT_REGS_COUNT; ui ++) {
ret = __get_user(tmp, (unsigned long __user *) data);
diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
index 9e6baea..6b86960 100644
--- a/arch/powerpc/kernel/ptrace32.c
+++ b/arch/powerpc/kernel/ptrace32.c
@@ -53,6 +53,7 @@ static long compat_ptrace_old(struct task_struct *child, long 
request,
unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
unsigned int __user *tmp = (unsigned int __user *)addr;
 
+   CHECK_FULL_REGS(child->thread.regs);
for (i = 0; i < 32; i++) {
ret = put_user(*reg, tmp);
if (ret)
@@ -68,6 +69,7 @@ static long compat_ptrace_old(struct task_struct *child, long 
request,
unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
unsigned int __user *tmp = (unsigned int __user *)addr;
 
+   CHECK_FULL_REGS(child->thread.regs);
for (i = 0; i < 32; i++) {
ret = get_user(*reg, tmp);
if (ret)
@@ -164,6 +166,7 @@ long compat_sys_ptrace(int request, int pid, unsigned long 
addr,
if ((addr & 3) || (index > PT_FPSCR32))
break;
 
+   CHECK_FULL_REGS(child->thread.regs);
if (index < PT_FPR0) {
tmp = ptrace_get_reg(child, index);
} else {
@@ -210,6 +213,7 @@ long compat_sys_ptrace(int request, int pid, unsigned long 
addr,
if ((addr & 3) || numReg > PT_FPSCR)
break;
 
+   CHECK_FULL_REGS(child->thread.regs);
if (numReg >= PT_FPR0) {
flush_fp_to_thread(child);
tmp = ((unsigned long int *)child->thread.fpr)[numReg - 
PT_FPR0];
@@ -270,6 +274,7 @@ long compat_sys_ptrace(int request, int pid, unsigned long 
addr,
if ((addr & 3) || (index > PT_FPSCR32))
break;
 
+   CHECK_FULL_REGS(child->thread.regs);
if (index < PT_FPR0) {
ret = ptrace_put_reg(child, index, data);
} else {
@@ -307,6 +312,7 @@ long compat_sys_ptrace(int request, int pid, unsigned long 
addr,
 */
if ((addr & 3) || (numReg > PT_FPSCR))
break;
+   CHECK_FULL_REGS(child->thread.regs);
if (numReg < PT_FPR0) {
unsigned long freg = ptrace_get_reg(child, numReg);
if (index % 2)
@@ -342,6 +348,7 @@ long compat_sys_ptrace(int request, 

Re: [PATCH 1/1] x86: Convert cpuinfo_x86 array to a per_cpu array v3

2007-09-24 Thread Dave Jones


On Tue, Sep 25, 2007 at 12:01:56AM +0200, roel wrote:

 > > --- a/arch/i386/kernel/cpu/cpufreq/powernow-k6.c
 > > +++ b/arch/i386/kernel/cpu/cpufreq/powernow-k6.c
 > > @@ -215,7 +215,7 @@ static struct cpufreq_driver powernow_k6
 > >   */
 > >  static int __init powernow_k6_init(void)
 > >  {
 > > -  struct cpuinfo_x86  *c = cpu_data;
 > > +  struct cpuinfo_x86 *c = _data(0);
 > >  
 > >if ((c->x86_vendor != X86_VENDOR_AMD) || (c->x86 != 5) ||
 > >((c->x86_model != 12) && (c->x86_model != 13)))
 > 
 > while we're at it, we could change this to
 > 
 >  if (!(c->x86_vendor == X86_VENDOR_AMD && c->x86 == 5 &&
 >  (c->x86_model == 12 || c->x86_model == 13)))

For what purpose?  There's nothing wrong with the code as it stands,
and inverting the tests means we'd have to move a bunch of
code inside the if arm instead of just returning -ENODEV.

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 1/2] Enable link power management for ata drivers

2007-09-24 Thread Kristen Carlson Accardi
On Tue, 25 Sep 2007 01:12:32 +0200
roel <[EMAIL PROTECTED]> wrote:

> >  #define ata_id_cdb_intr(id)(((id)[0] & 0x60) == 0x20)
> > +#define ata_id_has_hipm(id)\
> > +   ( (((id)[76] != 0x) && ((id)[76] != 0x)) && \
> > + ((id)[76] & (1 << 9)) )
>   ^
>   |
> are you sure this
> should be 76?

Yes.

> 
> we can also change the first statement a bit:
>   (!(((id)[76] == 0x) || ((id)[76] == 0x)) && \
> 
> 
> > +#define ata_id_has_dipm(id)\
> > +   ( (((id)[76] != 0x) && ((id)[76] != 0x)) && \
> 
> and:
>   (!(((id)[76] == 0x) || ((id)[76] == 0x)) && \

I feel this is equivalent functionality and not as readable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/4] module: implement module_inhibit_unload()

2007-09-24 Thread Rusty Russell
On Tue, 2007-09-25 at 08:18 +0900, Tejun Heo wrote:
> > Given your description of this tool as a "sledgehammer," might it not be
> > easier to just take and hold module_mutex for the duration of the unload
> > block?
> 
> That would be easier but...
> 
> * It would serialize users of the sledgehammer.
> * It would block loading modules (which is often more important than
> unloading them) when things go south.

My concern is that you're dropping the module mutex around ->exit now.
I don't *think* this should matter, but it's worth considering.

I really wonder if an explicit "kill_this_attribute()" is a better way
to go than this...

Rusty.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/5] Add fair-user scheduler

2007-09-24 Thread roel
Srivatsa Vaddagiri wrote:
> Enable user-id based fair group scheduling. This is usefull for anyone
> who wants to test the group scheduler w/o having to enable
> CONFIG_CGROUPS.
> 
> A separate scheduling group (i.e struct task_grp) is automatically created 
> for 
> every new user added to the system. Upon uid change for a task, it is made to 
> move to the corresponding scheduling group.
> 
> A /proc tunable (/proc/root_user_share) is also provided to tune root
> user's quota of cpu bandwidth.
> 
> Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
> Signed-off-by : Dhaval Giani <[EMAIL PROTECTED]>
> 
> 
> ---
>  include/linux/sched.h |4 +++
>  init/Kconfig  |   13 
>  kernel/sched.c|9 
>  kernel/sched_debug.c  |   52 
> ++
>  kernel/user.c |   43 +
>  5 files changed, 121 insertions(+)
> 
> Index: linux-2.6.23-rc6/include/linux/sched.h
> ===
> --- linux-2.6.23-rc6.orig/include/linux/sched.h
> +++ linux-2.6.23-rc6/include/linux/sched.h
> @@ -596,6 +596,10 @@ struct user_struct {
>   /* Hash table maintenance information */
>   struct hlist_node uidhash_node;
>   uid_t uid;
> +
> +#ifdef CONFIG_FAIR_USER_SCHED
> + struct task_grp *tg;
> +#endif
>  };
>  
>  extern struct user_struct *find_user(uid_t);
> Index: linux-2.6.23-rc6/init/Kconfig
> ===
> --- linux-2.6.23-rc6.orig/init/Kconfig
> +++ linux-2.6.23-rc6/init/Kconfig
> @@ -289,6 +289,19 @@ config FAIR_GROUP_SCHED
> This feature lets cpu scheduler recognize task groups and control cpu
> bandwidth allocation to such task groups.
>  
> +choice
> + depends on FAIR_GROUP_SCHED
> + prompt "Basis for grouping tasks"
> + default FAIR_USER_SCHED
> +
> + config FAIR_USER_SCHED
> + bool "user id"
> + help
> +   This option will choose userid as the basis for grouping
> +   tasks, thus providing equal cpu bandwidth to each user.
> +
> +endchoice
> +
>  config SYSFS_DEPRECATED
>   bool "Create deprecated sysfs files"
>   default y
> Index: linux-2.6.23-rc6/kernel/sched.c
> ===
> --- linux-2.6.23-rc6.orig/kernel/sched.c
> +++ linux-2.6.23-rc6/kernel/sched.c
> @@ -199,7 +199,12 @@ struct task_grp init_task_grp =  {
>   .cfs_rq = init_cfs_rq_p,
>};
>  
> +#ifdef CONFIG_FAIR_USER_SCHED
> +#define INIT_TASK_GRP_LOAD   2*NICE_0_LOAD
> +#else
>  #define INIT_TASK_GRP_LOAD   NICE_0_LOAD
> +#endif
> +
>  static int init_task_grp_load = INIT_TASK_GRP_LOAD;
>  
>  /* return group to which a task belongs */
> @@ -207,7 +212,11 @@ static inline struct task_grp *task_grp(
>  {
>   struct task_grp *tg;
>  
> +#ifdef CONFIG_FAIR_USER_SCHED
> + tg = p->user->tg;
> +#else
>   tg  = _task_grp;
> +#endif
>  
>   return tg;
>  }
> Index: linux-2.6.23-rc6/kernel/sched_debug.c
> ===
> --- linux-2.6.23-rc6.orig/kernel/sched_debug.c
> +++ linux-2.6.23-rc6/kernel/sched_debug.c
> @@ -214,6 +214,49 @@ static void sysrq_sched_debug_show(void)
>   sched_debug_show(NULL, NULL);
>  }
>  
> +#ifdef CONFIG_FAIR_USER_SCHED
> +
> +static DEFINE_MUTEX(root_user_share_mutex);
> +
> +static int
> +root_user_share_read_proc(char *page, char **start, off_t off, int count,
> +  int *eof, void *data)
> +{
> + int len;
> +
> + len = sprintf(page, "%d\n", init_task_grp_load);
> +
> + return len;
> +}

or use this oneliner:

return sprintf(page, "%d\n", init_task_grp_load);

> +
> +static int
> +root_user_share_write_proc(struct file *file, const char __user *buffer,
> +  unsigned long count, void *data)
> +{
> + unsigned long shares;
> + char kbuf[sizeof(unsigned long)+1];
> + int rc = 0;
> +
> + if (copy_from_user(kbuf, buffer, sizeof(kbuf)))
> + return -EFAULT;
> +
> + shares = simple_strtoul(kbuf, NULL, 0);
> +
> + if (!shares)
> + shares = NICE_0_LOAD;
> +
> + mutex_lock(_user_share_mutex);
> +
> + init_task_grp_load = shares;
> + rc = sched_group_set_shares(_task_grp, shares);
> +
> + mutex_unlock(_user_share_mutex);
> +
> + return (rc < 0 ? rc : count);
> +}
> +
> +#endif   /* CONFIG_FAIR_USER_SCHED */
> +
>  static int sched_debug_open(struct inode *inode, struct file *filp)
>  {
>   return single_open(filp, sched_debug_show, NULL);
> @@ -236,6 +279,15 @@ static int __init init_sched_debug_procf
>  
>   pe->proc_fops = _debug_fops;
>  
> +#ifdef CONFIG_FAIR_USER_SCHED
> + pe = create_proc_entry("root_user_share", 0644, NULL);
> + if (!pe)
> + return 

Re: [patch 1/2] Enable link power management for ata drivers

2007-09-24 Thread Davide Libenzi
On Tue, 25 Sep 2007, roel wrote:

> > +   if (!(ap->flags & ATA_FLAG_IPM) || !ata_dev_enabled(dev)) {
> 
>   if (!((ap->flags & ATA_FLAG_IPM) && ata_dev_enabled(dev))) {

int foo(int i, int j) {

return !(i & 8) || !j;
}

int moo(int i, int j) {

return !((i & 8) && j);
}


gcc -O2 -S:


.globl foo
.type   foo, @function
foo:
shrl$3, %edi
xorl$1, %edi
testl   %esi, %esi
sete%al
orl %eax, %edi
andl$1, %edi
movl%edi, %eax
ret
.globl moo
.type   moo, @function
moo:
shrl$3, %edi
xorl$1, %edi
testl   %esi, %esi
sete%al
orl %eax, %edi
andl$1, %edi
movl%edi, %eax
ret



- Davide


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


[patch] ata: libata: add per device private data

2007-09-24 Thread Kristen Carlson Accardi
Allow host controllers to store private data per device.

Signed-off-by:  Kristen Carlson Accardi <[EMAIL PROTECTED]>

---
 include/linux/libata.h |3 +++
 1 file changed, 3 insertions(+)

Index: libata-dev/include/linux/libata.h
===
--- libata-dev.orig/include/linux/libata.h  2007-09-24 16:13:33.0 
-0700
+++ libata-dev/include/linux/libata.h   2007-09-24 16:15:24.0 -0700
@@ -474,6 +474,9 @@ struct ata_device {
/* error history */
struct ata_eringering;
int spdn_cnt;
+
+   /* controller driver per device private data */
+   void*private_data;
 };
 
 /* Offset into struct ata_device.  Fields above it are maintained
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/4] module: implement module_inhibit_unload()

2007-09-24 Thread Tejun Heo
Jonathan Corbet wrote:
> Hi, Tejun,
> 
> I was just looking over these changes...
> 
>> +/* Don't proceed till inhibition is lifted. */
>> +add_wait_queue(_unload_wait, );
>> +set_current_state(TASK_UNINTERRUPTIBLE);
>> +if (atomic_read(_unload_inhibit_cnt))
>> +schedule();
>> +__set_current_state(TASK_RUNNING);
>> +remove_wait_queue(_unload_wait, );
>> +
>> +mutex_lock(_mutex);
> 
> Maybe I'm missing something, but this looks racy to me.  There's no
> check after schedule() to see if module_unload_inhibit_cnt is really
> zero, and nothing to keep somebody else from slipping in and raising it
> again afterward.

The unloading can proceed once module_unload_inhibit_cnt reaches zero.
An unloading thread only has to care about inhibition put in effect
before unloading has started, so there's no need to check again.

> Given your description of this tool as a "sledgehammer," might it not be
> easier to just take and hold module_mutex for the duration of the unload
> block?

That would be easier but...

* It would serialize users of the sledgehammer.
* It would block loading modules (which is often more important than
unloading them) when things go south.

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


Re: [PATCH 24/25] r/o bind mounts: track number of mount writers

2007-09-24 Thread Andrew Morton
On Mon, 24 Sep 2007 16:05:37 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:

> On Mon, 2007-09-24 at 15:25 -0700, Andrew Morton wrote:
> > hm.  I saw that warning on my 2-way.  It has CONFIG_NR_CPUS=8 so perhaps
> > the kernel has decided that this machine can possibly have eight CPUs.
> > 
> > It's an old super-micro board, doesn't have ACPI.
> 
> Well, it's looking like we only set cpu_possible_map from data we find
> in the MP table, which makes sense.  The only question is how your
> system gets more than ~8 possible cpus.  Do you have the .config handy?
> 

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


Re: 2.6.23-rc7-mm1: build error with CONFIG_KEXEC=y and CONFIG_NOHIGHMEM=y

2007-09-24 Thread Randy Dunlap
[adding kexec m-l]

On Mon, 24 Sep 2007 22:10:36 +0200 Laurent Riffard wrote:

> Le 24.09.2007 11:17, Andrew Morton a écrit :
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/
> > 
> 
> I've got this compilation when CONFIG_KEXEC=y and CCONFIG_NOHIGHMEM=y:
> 
> linux-2.6-mm$ LANG=C make 
>   CHK include/linux/version.h
>   CHK include/linux/utsrelease.h
>   CALLscripts/checksyscalls.sh
>   CHK include/linux/compile.h
>   CC  arch/i386/kernel/setup.o
> arch/i386/kernel/setup.c: In function 'reserve_crashkernel':
> arch/i386/kernel/setup.c:391: error: 'highend_pfn' undeclared (first use in 
> this function)
> arch/i386/kernel/setup.c:391: error: (Each undeclared identifier is reported 
> only once
> arch/i386/kernel/setup.c:391: error: for each function it appears in.)
> arch/i386/kernel/setup.c:391: error: 'highstart_pfn' undeclared (first use in 
> this function)
> make[1]: *** [arch/i386/kernel/setup.o] Error 1
> make: *** [arch/i386/kernel] Error 2
> 
> 
> .config attached.
> ~~
> laurent
> 


---
~Randy
Phaedrus says that Quality is about caring.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Enable link power management for ata drivers

2007-09-24 Thread roel
Kristen Carlson Accardi wrote:
> Device Initiated Power Management, which is defined
> in SATA 2.5 can be enabled for disks which support it.
> This patch enables DIPM when the user sets the link
> power management policy to "min_power".
> 
> Additionally, libata drivers can define a function 
> (enable_pm) that will perform hardware specific actions to 
> enable whatever power management policy the user set up 
> for Host Initiated Power management (HIPM).
> This power management policy will be activated after all 
> disks have been enumerated and intialized.  Drivers should 
> also define disable_pm, which will turn off link power 
> management, but not change link power management policy.
> 
> Signed-off-by:  Kristen Carlson Accardi <[EMAIL PROTECTED]>
> ---
>  Documentation/scsi/link_power_management_policy.txt |   19 +
>  drivers/ata/libata-core.c   |  194 
> +++-
>  drivers/ata/libata-eh.c |5 
>  drivers/ata/libata-scsi.c   |   83 
>  include/linux/ata.h |7 
>  include/linux/libata.h  |   25 ++
>  6 files changed, 322 insertions(+), 11 deletions(-)
> 
> Index: libata-dev/drivers/ata/libata-scsi.c
> ===
> --- libata-dev.orig/drivers/ata/libata-scsi.c 2007-09-24 13:43:10.0 
> -0700
> +++ libata-dev/drivers/ata/libata-scsi.c  2007-09-24 13:46:22.0 
> -0700
> @@ -110,6 +110,78 @@ static struct scsi_transport_template at
>  };
>  
>  
> +static const struct {
> + enum link_pmvalue;
> + char*name;
> +} link_pm_policy[] = {
> + { NOT_AVAILABLE, "max_performance" },
> + { MIN_POWER, "min_power" },
> + { MAX_PERFORMANCE, "max_performance" },
> + { MEDIUM_POWER, "medium_power" },
> +};
> +
> +const char *ata_scsi_link_pm_policy(enum link_pm policy)
> +{
> + int i;
> + char *name = NULL;
> +
> + for (i = 0; i < ARRAY_SIZE(link_pm_policy); i++) {
> + if (link_pm_policy[i].value == policy) {
> + name = link_pm_policy[i].name;
> + break;
> + }
> + }
> + return name;
> +}
> +
> +static ssize_t store_link_pm_policy(struct class_device *class_dev,
> + const char *buf, size_t count)
> +{
> + struct Scsi_Host *shost = class_to_shost(class_dev);
> + struct ata_port *ap = ata_shost_to_port(shost);
> + enum link_pm policy = 0;
> + int i;
> +
> + /*
> +  * we are skipping array location 0 on purpose - this
> +  * is because a value of NOT_AVAILABLE is displayed
> +  * to the user as max_performance, but when the user
> +  * writes "max_performance", they actually want the
> +  * value to match MAX_PERFORMANCE.
> +  */
> + for (i = 1; i < ARRAY_SIZE(link_pm_policy); i++) {
> + const int len = strlen(link_pm_policy[i].name);
> + if (strncmp(link_pm_policy[i].name, buf, len) == 0 &&
> +buf[len] == '\n') {
> + policy = link_pm_policy[i].value;
> + break;
> + }
> + }
> + if (!policy)
> + return -EINVAL;
> +
> + if (ata_scsi_set_link_pm_policy(ap, policy))
> + return -EINVAL;
> + return count;
> +}
> +
> +static ssize_t
> +show_link_pm_policy(struct class_device *class_dev, char *buf)
> +{
> + struct Scsi_Host *shost = class_to_shost(class_dev);
> + struct ata_port *ap = ata_shost_to_port(shost);
> + const char *policy =
> + ata_scsi_link_pm_policy(ap->pm_policy);
> +
> + if (!policy)
> + return -EINVAL;
> +
> + return snprintf(buf, 23, "%s\n", policy);
> +}
> +CLASS_DEVICE_ATTR(link_power_management_policy, S_IRUGO | S_IWUSR,
> + show_link_pm_policy, store_link_pm_policy);
> +EXPORT_SYMBOL_GPL(class_device_attr_link_power_management_policy);
> +
>  static void ata_scsi_invalid_field(struct scsi_cmnd *cmd,
>  void (*done)(struct scsi_cmnd *))
>  {
> @@ -3041,6 +3113,17 @@ void ata_scsi_simulate(struct ata_device
>   }
>  }
>  
> +int ata_scsi_set_link_pm_policy(struct ata_port *ap,
> + enum link_pm policy)
> +{
> + ap->pm_policy = policy;
> + ap->link.eh_info.action |= ATA_EHI_LPM;
> + ap->link.eh_info.flags |= ATA_EHI_NO_AUTOPSY;
> + ata_port_schedule_eh(ap);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(ata_scsi_set_link_pm_policy);
> +
>  int ata_scsi_add_hosts(struct ata_host *host, struct scsi_host_template *sht)
>  {
>   int i, rc;
> Index: libata-dev/include/linux/libata.h
> ===
> --- libata-dev.orig/include/linux/libata.h2007-09-24 13:43:10.0 
> -0700
> +++ libata-dev/include/linux/libata.h 2007-09-24 13:47:57.0 -0700
> @@ -140,6 +140,8 @@ enum {
>   

Re: [PATCH] leds: add missing header

2007-09-24 Thread Richard Purdie
On Sun, 2007-09-23 at 08:14 +0200, Pierre Ossman wrote:
> rwlocks are used in the structures so make sure the right header
> is included.
> 
> Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>

I think something similar was already committed in revision
df96efd73b81b8bc2d23b3d8b6025cce3d43db6c.

Cheers,

Richard


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


Re: [PATCH 24/25] r/o bind mounts: track number of mount writers

2007-09-24 Thread Dave Hansen
On Mon, 2007-09-24 at 15:25 -0700, Andrew Morton wrote:
> hm.  I saw that warning on my 2-way.  It has CONFIG_NR_CPUS=8 so perhaps
> the kernel has decided that this machine can possibly have eight CPUs.
> 
> It's an old super-micro board, doesn't have ACPI.

Well, it's looking like we only set cpu_possible_map from data we find
in the MP table, which makes sense.  The only question is how your
system gets more than ~8 possible cpus.  Do you have the .config handy?

-- 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: Mask Issue?

2007-09-24 Thread Chris Holvenstot

On Mon, 2007-09-24 at 16:39 +0100, Mel Gorman wrote:
> On (19/09/07 17:57), Chris Holvenstot didst pronounce:
> > Still being a little new at this I am not sure if this is an issue at
> > all or not but I noted that while building the 2.6.23-rc6-git8 kernel
> > this afternoon I received the following error message: 
> > 
> > Building modules, stage 2.
> >   MODPOST 1670 modules
> > WARNING: Can't handle masks in drivers/mtd/nand/cafe_nand:0
> > 
> > I have been building each of the kernels in the 2.6.23-rc series and had
> > not noted this message before.  I apologize if this is a non-issue.
> > 
> 
> I noticed this in a -mm recently and never got around to kicking it
> properly because I suspected it was a compiler issue. What version
> of gcc and binutils are you using?
> 
> David Woodhouse added to cc in case this is a known problem.
> 

Mel - 

Thank you for the response.  I was a little unsure if this was to
trivial to report.  

In any case to answer your question I use version 4.1.2 of GCC and the
binutils package shows as 2.17.20070103cvs-0ubuntu2

Chris



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


Re: [Linux-fbdev-devel] [RFC] driving a LCD panel via I2C

2007-09-24 Thread Richard Purdie
On Mon, 2007-09-24 at 12:34 +0200, Haavard Skinnemoen wrote: 
> On Mon, 24 Sep 2007 10:58:08 +0200 (CEST)
> "Rodolfo Giometti" <[EMAIL PROTECTED]> wrote:
> > I have an LCD panel on a custom PXA27x based board and it must be
> > turned on/off by some special commands via a GPIO throught a I2C chip.
> > 
> > I'd like some suggestion about I can easily manage this situation.
> 
> I have a similar panel in the sense that it needs a bunch of SPI
> commands to get started. I implemented a LCD driver
> (drivers/video/backlight) for it so that it is automatically turned
> on/off at bootup/shutdown, and can be manually turned on/off
> through /sys/class/lcd/ltv350qv/power. AFAIK the driver is currently
> sitting in the backlight tree scheduled for inclusion in 2.6.24.

It is, its queued as
http://git.o-hand.com/?p=linux-rpurdie-backlight;a=commitdiff;h=c962fe18c64ae9139028ee674ab3c380449ce052

Its also worth noting that corgi-bl.c has a variant (akita) that uses a
gpio over an I2C IO expander for the backlight control. The code paths
are a little convoluted since other gpios are used by other drivers. The
base driver is in arch/arm/mach-pxa/akita-ioexp.c, the set_intensity
function is in arch/arm/mach-pxa/corgi_lcd.c and the base backlight
device in arch/arm/mach-pxa/spitz.c. I will be moving the set_intensity
to spitz.c to make things a little clearer.

Also, I'm in the process of turning corgi-bl.c into a generic backlight
driver which might help you, see:

http://git.o-hand.com/?p=linux-rpurdie-backlight;a=commitdiff;h=c74f241bf53bf5251c7c10f65041c20979f6c694

Now, the GPIO framework could help too (it didn't exist when I wrote
akita-ioexp)...

Regards,

Richard

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


Re: 2.6.23-rc7-mm1: build error with CONFIG_KEXEC=y and CONFIG_NOHIGHMEM=y

2007-09-24 Thread Laurent Riffard
Le 24.09.2007 11:17, Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/
> 

I've got this compilation when CONFIG_KEXEC=y and CCONFIG_NOHIGHMEM=y:

linux-2.6-mm$ LANG=C make 
  CHK include/linux/version.h
  CHK include/linux/utsrelease.h
  CALLscripts/checksyscalls.sh
  CHK include/linux/compile.h
  CC  arch/i386/kernel/setup.o
arch/i386/kernel/setup.c: In function 'reserve_crashkernel':
arch/i386/kernel/setup.c:391: error: 'highend_pfn' undeclared (first use in 
this function)
arch/i386/kernel/setup.c:391: error: (Each undeclared identifier is reported 
only once
arch/i386/kernel/setup.c:391: error: for each function it appears in.)
arch/i386/kernel/setup.c:391: error: 'highstart_pfn' undeclared (first use in 
this function)
make[1]: *** [arch/i386/kernel/setup.o] Error 1
make: *** [arch/i386/kernel] Error 2


.config attached.
~~
laurent
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc7-mm1
# Mon Sep 24 20:25:04 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_PROC_KPAGEMAP=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MCORE2 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_HPET_TIMER=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is 

Re: sys_chroot+sys_fchdir Fix

2007-09-24 Thread Serge E. Hallyn
Quoting David Newall ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
>> No reason for any new parameters to pivot_root.  Just clone your mounts
>> namespace first.
>>
>>  unshare(CLONE_NEWNS);
>>  chdir(new_dir);
>>  pivot_root(new_dir, oldroot);
>>
>> Since pivot_root actually fiddles with the vfsmnts, this is really the
>> only way to go about having it "work with just one process".
>
> I think the point is that, whereas we'd like to be able to pivot the root 
> for a single process, in practice this causes startup issues to which the 
> easy solution is to pivot the whole system.  At least that's my reading of 
> the man page.
>
> It might be tidy if pivot_root could be used (instead of a hack based on a 
> chroot bug), but it'd still be unportable.

Oh.  Yes, true, it is unportable.

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


Re: sys_chroot+sys_fchdir Fix

2007-09-24 Thread Serge E. Hallyn
Quoting David Newall ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
>> No reason for any new parameters to pivot_root.  Just clone your mounts
>> namespace first.
>>
>>  unshare(CLONE_NEWNS);
>>  chdir(new_dir);
>>  pivot_root(new_dir, oldroot);
>>
>> Since pivot_root actually fiddles with the vfsmnts, this is really the
>> only way to go about having it "work with just one process".
>
> I think the point is that, whereas we'd like to be able to pivot the root 
> for a single process, in practice this causes startup issues to which the 
> easy solution is to pivot the whole system.  At least that's my reading of 
> the man page.
>
> It might be tidy if pivot_root could be used (instead of a hack based on a 
> chroot bug), but it'd still be unportable.

It can.

Please re-read my previous msg.

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/4] new timerfd API v2 - new timerfd API

2007-09-24 Thread roel
Davide Libenzi wrote:
> This is the new timerfd API as it is implemented by the following patch:
> 
> int timerfd_create(int clockid);
> int timerfd_settime(int ufd, int flags,
>   const struct itimerspec *utmr,
>   struct itimerspec *otmr);
> int timerfd_gettime(int ufd, struct itimerspec *otmr);
> 
> The timerfd_create() API creates an un-programmed timerfd fd. The "clockid"
> parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
> The timerfd_settime() API give new settings by the timerfd fd, by optionally
> retrieving the previous expiration time (in case the "otmr" parameter is not 
> NULL).
> The time value specified in "utmr" is absolute, if the TFD_TIMER_ABSTIME bit
> is set in the "flags" parameter. Otherwise it's a relative time.
> The timerfd_gettime() API returns the next expiration time of the timer, or 
> {0, 0}
> if the timerfd has not been set yet.
> Like the previous timerfd API implementation, read(2) and poll(2) are 
> supported
> (with the same interface).
> Here's a simple test program I used to exercise the new timerfd APIs:
> 
> http://www.xmailserver.org/timerfd-test2.c
> 
> 
> 
> Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
> 
> 
> - Davide
> 
> 
> ---
>  fs/compat.c  |   32 ++-
>  fs/timerfd.c |  197 
> ++-
>  include/linux/compat.h   |7 +
>  include/linux/syscalls.h |7 +
>  4 files changed, 164 insertions(+), 79 deletions(-)
> 
> Index: linux-2.6.mod/fs/timerfd.c
> ===
> --- linux-2.6.mod.orig/fs/timerfd.c   2007-09-24 12:26:19.0 -0700
> +++ linux-2.6.mod/fs/timerfd.c2007-09-24 12:31:22.0 -0700
> @@ -25,13 +25,15 @@
>   struct hrtimer tmr;
>   ktime_t tintv;
>   wait_queue_head_t wqh;
> + u64 ticks;
>   int expired;
> + int clockid;
>  };
>  
>  /*
>   * This gets called when the timer event triggers. We set the "expired"
>   * flag, but we do not re-arm the timer (in case it's necessary,
> - * tintv.tv64 != 0) until the timer is read.
> + * tintv.tv64 != 0) until the timer is accessed.
>   */
>  static enum hrtimer_restart timerfd_tmrproc(struct hrtimer *htmr)
>  {
> @@ -40,13 +42,14 @@
>  
>   spin_lock_irqsave(>wqh.lock, flags);
>   ctx->expired = 1;
> + ctx->ticks++;
>   wake_up_locked(>wqh);
>   spin_unlock_irqrestore(>wqh.lock, flags);
>  
>   return HRTIMER_NORESTART;
>  }
>  
> -static void timerfd_setup(struct timerfd_ctx *ctx, int clockid, int flags,
> +static void timerfd_setup(struct timerfd_ctx *ctx, int flags,
> const struct itimerspec *ktmr)
>  {
>   enum hrtimer_mode htmode;
> @@ -57,8 +60,9 @@
>  
>   texp = timespec_to_ktime(ktmr->it_value);
>   ctx->expired = 0;
> + ctx->ticks = 0;
>   ctx->tintv = timespec_to_ktime(ktmr->it_interval);
> - hrtimer_init(>tmr, clockid, htmode);
> + hrtimer_init(>tmr, ctx->clockid, htmode);
>   ctx->tmr.expires = texp;
>   ctx->tmr.function = timerfd_tmrproc;
>   if (texp.tv64 != 0)
> @@ -83,7 +87,7 @@
>   poll_wait(file, >wqh, wait);
>  
>   spin_lock_irqsave(>wqh.lock, flags);
> - if (ctx->expired)
> + if (ctx->ticks)
>   events |= POLLIN;
>   spin_unlock_irqrestore(>wqh.lock, flags);
>  
> @@ -102,11 +106,11 @@
>   return -EINVAL;
>   spin_lock_irq(>wqh.lock);
>   res = -EAGAIN;
> - if (!ctx->expired && !(file->f_flags & O_NONBLOCK)) {
> + if (!ctx->ticks && !(file->f_flags & O_NONBLOCK)) {
>   __add_wait_queue(>wqh, );
>   for (res = 0;;) {
>   set_current_state(TASK_INTERRUPTIBLE);
> - if (ctx->expired) {
> + if (ctx->ticks) {
>   res = 0;
>   break;
>   }
> @@ -121,22 +125,21 @@
>   __remove_wait_queue(>wqh, );
>   __set_current_state(TASK_RUNNING);
>   }
> - if (ctx->expired) {
> - ctx->expired = 0;
> - if (ctx->tintv.tv64 != 0) {
> + if (ctx->ticks) {
> + ticks = ctx->ticks;
> + if (ctx->expired && ctx->tintv.tv64) {
>   /*
>* If tintv.tv64 != 0, this is a periodic timer that
>* needs to be re-armed. We avoid doing it in the timer
>* callback to avoid DoS attacks specifying a very
>* short timer period.
>*/
> - ticks = (u64)
> - hrtimer_forward(>tmr,
> - hrtimer_cb_get_time(>tmr),
> - ctx->tintv);
> + ticks += (u64) hrtimer_forward_now(>tmr,
> +ctx->tintv) - 1;
> 

Re: [PATCH/RFC] samples/: move kprobes sources to samples

2007-09-24 Thread Mathieu Desnoyers
* Randy Dunlap ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> >* Randy Dunlap ([EMAIL PROTECTED]) wrote:
> >>This is RFC patch 2/2.
> >>Patch 1/2 introduces the samples/ infrastructure:
> >>  http://lkml.org/lkml/2007/9/24/397
> >>
> >
> >Hi Randy,
> >
> >I got this when building my markers (which looks alike your kprobes):
> >
> >ld: samples/built-in.o: No such file: No such file or directory
> >make: *** [.tmp_vmlinux1] Error 1
> >
> >And the Makefile from samples does not seem to be executed. And why is
> >there a Kbuild file in your first patch ?
> 
> samples/Kbuild should be renamed to samples/Makefile.
> Sorry about that.
> 
> I made the kprobes files build only as modules.
> You are probably attempting to build markers built-in, not as
> modules?  That needs some makefile foo, I think.  Sam??
> 
> 

Ok, fixed.. Was due either to Kbuild being there (?!?) and/or the fact
that I used += markers instead of += markers/.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Ethernet driver on 2.6.22

2007-09-24 Thread Randy Dunlap
On Tue, 25 Sep 2007 08:39:07 +1000 hce wrote:

> On 9/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > On Mon, 24 Sep 2007 12:40:07 +1000 hce wrote:
> >
> > > Thanks Randy.
> > >
> > > On 9/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > > On Mon, 24 Sep 2007 08:52:36 +1000 hce wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I am upgrading from kernel 2.6.11 to 2.6.22 on ARM S3C2400A and found
> > > > > a following issue on 2.6.22.
> > > > >
> > > > > On 2.6.11, I selected CONFIG_ISA,  CONFIG_NET_PCI and CONFIG_CS89X0 to
> > > > > build  CS8900A Ethernet driver to kernel, it was running perfect.
> > > > >
> > > > > But on 2.6.22, I made the same configuration for CS8900A, the cs89x0.o
> > > > > could not be compiled in to the kernel (or as a module when I tried to
> > > > > CONFIG_CS89X0=m) unless I commented out depends statement in
> > > > > drivers/net/Kconfig. I double checked all three are CONFIG_ISA=y,
> > > > > CONFIG_NET_PCI=y and CONFIG_CS89X0=y. Any explanation please, was I
> > > > > missing something here?
> > > >
> > > > I didn't look in 2.6.11 Kconfig files, but in 2.6.22, this driver is
> > > > limited to 3 specific boards:
> > > >
> > > > config CS89x0
> > > > tristate "CS89x0 support"
> > > > depends on NET_PCI && (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 || 
> > > > ARCH_PNX010X)
> > >
> > > The Kconfig for CS89x0 in 2.6.11 is exactly the same as 2.6.22.
> > >
> > > > Does ARM S3C2400A qualify as any of those?  (MACH_... or ARCH_...)
> > >
> > > I can run CS89x0 for ARM S3C2400 in 2.6.11, at least I can say yes,
> > > the ARM S3C2400A qualifies those in 2.6.11, I don't know the 2.6.22
> > > and I hope someone knows 2.6.22 well can answer it.
> > >
> > > > (latter: ARCH_PNX010X is not used anywhere else AFAICT)
> > >
> > > Yes, but you only need to enable ISA and NET_PCI to use CS89x0.
> >
> > Right.
> >
> > I don't have any problem building CS89x0 for X86_32:
> > make defconfig then enable ISA (what!?!?  why not in defconfig?)
> > and then enable CS89x0.
> 
> I don't have my embedded system here, I'll try when I get there. But,
> let me clarify it, did you mean to type "make defconfig" on linux
> (kernel) directory, and enable ISA, NET_PCI and CS89x0 from the
> prompt?
> 
> My procedure was to edit .config to enable ISA, NET_PCI and CS89x0
> from vim, then type "make menuconfig" and "make oldconfig" (The same
> procedure I did in 2.6.11 which works fine). Does that make things
> differently?

You should do "make oldconfig" immediately after editing the .config
file (AFAIK).  Or the "make menuconfig" might run the oldconfig
changes for you.

Then I would just double-check the final .config file
to make sure that it contains what you expect it to contain.

> > Please send your .config file.
> 
> I'll, but I don't have the system right now.

OK.

---
~Randy
Phaedrus says that Quality is about caring.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6/11] eCryptfs: Update metadata read/write functions

2007-09-24 Thread Michael Halcrow
On Wed, Sep 19, 2007 at 10:48:17PM -0700, Andrew Morton wrote:
> On Mon, 17 Sep 2007 16:48:44 -0500 Michael Halcrow <[EMAIL PROTECTED]> wrote:
> > +   if ((rc = ecryptfs_write_lower(ecryptfs_dentry->d_inode,
> 
> checkpatch missed the assignment-in-an-if here.

Fix an assignment-in-an-if.

Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 4bf1a95..b3795f6 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1306,8 +1306,9 @@ ecryptfs_write_metadata_to_contents(struct 
ecryptfs_crypt_stat *crypt_stat,
int header_pages;
int rc;
 
-   if ((rc = ecryptfs_write_lower(ecryptfs_dentry->d_inode, page_virt,
-  0, PAGE_CACHE_SIZE))) {
+   rc = ecryptfs_write_lower(ecryptfs_dentry->d_inode, page_virt,
+ 0, PAGE_CACHE_SIZE);
+   if (rc) {
printk(KERN_ERR "%s: Error attempting to write header "
   "information to lower file; rc = [%d]\n", __FUNCTION__,
   rc);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Ethernet driver on 2.6.22

2007-09-24 Thread hce
On 9/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Sep 2007 12:40:07 +1000 hce wrote:
>
> > Thanks Randy.
> >
> > On 9/24/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > On Mon, 24 Sep 2007 08:52:36 +1000 hce wrote:
> > >
> > > > Hi,
> > > >
> > > > I am upgrading from kernel 2.6.11 to 2.6.22 on ARM S3C2400A and found
> > > > a following issue on 2.6.22.
> > > >
> > > > On 2.6.11, I selected CONFIG_ISA,  CONFIG_NET_PCI and CONFIG_CS89X0 to
> > > > build  CS8900A Ethernet driver to kernel, it was running perfect.
> > > >
> > > > But on 2.6.22, I made the same configuration for CS8900A, the cs89x0.o
> > > > could not be compiled in to the kernel (or as a module when I tried to
> > > > CONFIG_CS89X0=m) unless I commented out depends statement in
> > > > drivers/net/Kconfig. I double checked all three are CONFIG_ISA=y,
> > > > CONFIG_NET_PCI=y and CONFIG_CS89X0=y. Any explanation please, was I
> > > > missing something here?
> > >
> > > I didn't look in 2.6.11 Kconfig files, but in 2.6.22, this driver is
> > > limited to 3 specific boards:
> > >
> > > config CS89x0
> > > tristate "CS89x0 support"
> > > depends on NET_PCI && (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 || 
> > > ARCH_PNX010X)
> >
> > The Kconfig for CS89x0 in 2.6.11 is exactly the same as 2.6.22.
> >
> > > Does ARM S3C2400A qualify as any of those?  (MACH_... or ARCH_...)
> >
> > I can run CS89x0 for ARM S3C2400 in 2.6.11, at least I can say yes,
> > the ARM S3C2400A qualifies those in 2.6.11, I don't know the 2.6.22
> > and I hope someone knows 2.6.22 well can answer it.
> >
> > > (latter: ARCH_PNX010X is not used anywhere else AFAICT)
> >
> > Yes, but you only need to enable ISA and NET_PCI to use CS89x0.
>
> Right.
>
> I don't have any problem building CS89x0 for X86_32:
> make defconfig then enable ISA (what!?!?  why not in defconfig?)
> and then enable CS89x0.

I don't have my embedded system here, I'll try when I get there. But,
let me clarify it, did you mean to type "make defconfig" on linux
(kernel) directory, and enable ISA, NET_PCI and CS89x0 from the
prompt?

My procedure was to edit .config to enable ISA, NET_PCI and CS89x0
from vim, then type "make menuconfig" and "make oldconfig" (The same
procedure I did in 2.6.11 which works fine). Does that make things
differently?

> Please send your .config file.

I'll, but I don't have the system right now.

Thanks Randy.


> ---
> ~Randy
> Phaedrus says that Quality is about caring.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH/RFC] samples/: move kprobes sources to samples

2007-09-24 Thread Randy Dunlap
On Tue, 25 Sep 2007 00:24:00 +0200 roel wrote:

> I could only point to three nitpicks 

Yes, hopefully the kprobes people will chime in here sometime and
merge those as well, or just ack them and I can change the code.

Thanks.

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


Re: [PATCH/RFC] samples/: move kprobes sources to samples

2007-09-24 Thread Randy Dunlap

Mathieu Desnoyers wrote:

* Randy Dunlap ([EMAIL PROTECTED]) wrote:

This is RFC patch 2/2.
Patch 1/2 introduces the samples/ infrastructure:
  http://lkml.org/lkml/2007/9/24/397



Hi Randy,

I got this when building my markers (which looks alike your kprobes):

ld: samples/built-in.o: No such file: No such file or directory
make: *** [.tmp_vmlinux1] Error 1

And the Makefile from samples does not seem to be executed. And why is
there a Kbuild file in your first patch ?


samples/Kbuild should be renamed to samples/Makefile.
Sorry about that.

I made the kprobes files build only as modules.
You are probably attempting to build markers built-in, not as
modules?  That needs some makefile foo, I think.  Sam??


--
~Randy
Phaedrus says that Quality is about caring.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 24/25] r/o bind mounts: track number of mount writers

2007-09-24 Thread Andrew Morton
On Mon, 24 Sep 2007 15:06:42 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:

> On Sun, 2007-09-23 at 23:17 -0700, Andrew Morton wrote:
> > It look like a false positive to me, but really, for a patchset of this
> > complexity and maturity I cannot fathom how it could have escaped any
> > lockdep testing.
> 
> I test with lockdep all the time.  The problem was that lockdep doesn't
> complain until you have 8 nested locks, and I only tested on a 4-cpu
> system.
> 
> I lowered the lockdep nesting limit to 3, and got the warning on my
> machine.
> 

hm.  I saw that warning on my 2-way.  It has CONFIG_NR_CPUS=8 so perhaps
the kernel has decided that this machine can possibly have eight CPUs.

It's an old super-micro board, doesn't have ACPI.

OEM ID: INTELProduct ID: 440BXAPIC at: 0xFEE0
Processor #0 6:8 APIC version 17
Processor #1 6:8 APIC version 17
I/O APIC #2 Version 17 at 0xFEC0.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 2

...

Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1707.03 BogoMIPS (lpj=3414067)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff     
  
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383fbff   0040  
  
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to e000.
Checking 'hlt' instruction... OK.
lockdep: not fixing up alternatives.
CPU0: Intel Pentium III (Coppermine) stepping 03
lockdep: not fixing up alternatives.
Booting processor 1/1 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 1704.02 BogoMIPS (lpj=3408054)
CPU: After generic identify, caps: 0383fbff     
  
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383fbff   0040  
  
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Pentium III (Coppermine) stepping 03
Total of 2 processors activated (3411.06 BogoMIPS).
ExtINT not setup in hardware but reported by MP table
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0
APIC timer registered as dummy, due to nmi_watchdog=1!
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs


One would think that the kernel would work out that eight CPUs ain't
possible on such a machine.  But we don't seem to print out any info which
allows me to confirm that this is really what the kernel did.


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


Re: [PATCH/RFC] samples/: move kprobes sources to samples

2007-09-24 Thread roel
I could only point to three nitpicks 

Randy Dunlap wrote:
> This is RFC patch 2/2.
> Patch 1/2 introduces the samples/ infrastructure:
>   http://lkml.org/lkml/2007/9/24/397
> 
> 
> ---
> 
> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Move kprobes source files from Documentation/kprobes.txt to
> samples/kprobes/ and add them to the build system.
> 
> Fix sparse warnings in all 3 kprobes samples source files.
> 
> Although kprobe-example.c is x86-specific, make it build on any
> platform by surrounding some code in ifdef/endif blocks.
> 
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> ---
>  Documentation/kprobes.txt   |  214 
> 
>  samples/Kconfig |5 
>  samples/Makefile|3 
>  samples/kprobes/Makefile|5 
>  samples/kprobes/jprobe_example.c|   65 ++
>  samples/kprobes/kprobe_example.c|   79 +
>  samples/kprobes/kretprobe-example.c |   60 ++
>  7 files changed, 222 insertions(+), 209 deletions(-)
> 
> --- /dev/null
> +++ linux-2.6.23-rc7/samples/kprobes/Makefile
> @@ -0,0 +1,5 @@
> +# builds the kprobes example kernel modules;
> +# then to use one (as root):  insmod 
> +
> +obj-$(CONFIG_SAMPLE_KPROBES) += kprobe_example.o jprobe_example.o \
> + kretprobe-example.o
> --- linux-2.6.23-rc7.orig/samples/Kconfig
> +++ linux-2.6.23-rc7/samples/Kconfig
> @@ -7,5 +7,10 @@ menuconfig SAMPLES
>  
>  if SAMPLES
>  
> +config SAMPLE_KPROBES
> + tristate "Build kprobes examples -- loadable modules only"
> + depends on KPROBES && m
> + help
> +   This builds several kprobes example modules.
>  
>  endif # SAMPLES
> --- /dev/null
> +++ linux-2.6.23-rc7/samples/kprobes/jprobe_example.c
> @@ -0,0 +1,65 @@
> +/*jprobe-example.c */
> +/*
> + * Here's a sample kernel module showing the use of jprobes to dump
> + * the arguments of do_fork().
> + *
> + * Build and insert the kernel module as done in the kprobe example.
> + * You will see the trace data in /var/log/messages and on the
> + * console whenever do_fork() is invoked to create a new process.
> + * (Some messages may be suppressed if syslogd is configured to
> + * eliminate duplicate messages.)
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Jumper probe for do_fork.
> + * Mirror principle enables access to arguments of the probed routine
> + * from the probe handler.
> + */
> +
> +/* Proxy routine having the same arguments as actual do_fork() routine */
> +static long jdo_fork(unsigned long clone_flags, unsigned long stack_start,
> +   struct pt_regs *regs, unsigned long stack_size,
> +   int __user * parent_tidptr, int __user * child_tidptr)
> +{
> + printk("jprobe: clone_flags=0x%lx, stack_size=0x%lx, regs=0x%p\n",
> +clone_flags, stack_size, regs);
> + /* Always end with a call to jprobe_return(). */
> + jprobe_return();
> + /*NOTREACHED*/
> + return 0;
> +}
> +
> +static struct jprobe my_jprobe = {
> + .entry = jdo_fork
> +};
> +
> +static int __init jprobe_init(void)
> +{
> + int ret;
> + my_jprobe.kp.symbol_name = "do_fork";
> +
> + if ((ret = register_jprobe(_jprobe)) <0) {

or do:
ret = register_jprobe(_jprobe);
if (ret < 0) {

> + printk("register_jprobe failed, returned %d\n", ret);
> + return -1;
> + }
> + printk("Planted jprobe at %p, handler addr %p\n",
> +my_jprobe.kp.addr, my_jprobe.entry);
> + return 0;
> +}
> +
> +static void __exit jprobe_exit(void)
> +{
> + unregister_jprobe(_jprobe);
> + printk("jprobe unregistered\n");
> +}
> +
> +module_init(jprobe_init)
> +module_exit(jprobe_exit)
> +MODULE_LICENSE("GPL");
> --- /dev/null
> +++ linux-2.6.23-rc7/samples/kprobes/kprobe_example.c
> @@ -0,0 +1,79 @@
> +/*kprobe_example.c*/
> +/*
> + * NOTE: This example is x86-specific.
> + * Here's a sample kernel module showing the use of kprobes to dump a
> + * stack trace and selected i386 registers when do_fork() is called.
> + *
> + * You will see the trace data in /var/log/messages and on the console
> + * whenever do_fork() is invoked to create a new process.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*For each probe you need to allocate a kprobe structure*/
> +static struct kprobe kp;
> +
> +/*kprobe pre_handler: called just before the probed instruction is executed*/
> +static int handler_pre(struct kprobe *p, struct pt_regs *regs)
> +{
> +#ifdef CONFIG_X86_32
> + printk("pre_handler: p->addr=0x%p, eip=%lx, eflags=0x%lx\n",
> + p->addr, regs->eip, regs->eflags);
> +#endif
> +#ifdef CONFIG_X86_64
> + printk("pre_handler: p->addr=0x%p, rip=%lx, eflags=0x%lx\n",
> + p->addr, regs->rip, regs->eflags);
> +#endif
> + dump_stack();
> + return 0;
> +}
> +
> +/*kprobe post_handler: called after the probed instruction is 

Re: 2.6.23-rc7-mm1: panic in scheduler

2007-09-24 Thread Ingo Molnar

* Lee Schermerhorn <[EMAIL PROTECTED]> wrote:

> Taking a quick look at [__]{en|de|queue_entity() and the functions 
> they call, I see something suspicious in set_leftmost() in 
> sched_fair.c:
> 
> static inline void
> set_leftmost(struct cfs_rq *cfs_rq, struct rb_node *leftmost)
> {
> struct sched_entity *se;
> 
> cfs_rq->rb_leftmost = leftmost;
> if (leftmost)
> se = rb_entry(leftmost, struct sched_entity, run_node);
> }
> 
> Missing code?  corrupt patch?

could you pull this git tree ontop of a -rc7 (or later) upstream tree:

  git-pull 
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git

does the solve the crash?

the above set_leftmost() code used to be larger and now indeed those 
bits are mostly dead code. I've queued up a clean-up patch for that - 
see the patch below. It should not impact correctness though, so if you 
can still trigger the crash with the latest sched-devel.git tree we'd 
like to know about it.

Ingo

--->
Subject: sched: remove set_leftmost()
From: Ingo Molnar <[EMAIL PROTECTED]>

Lee Schermerhorn noticed that set_leftmost() contains dead code,
remove this.

Reported-by: Lee Schermerhorn <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 kernel/sched_fair.c |   14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

Index: linux/kernel/sched_fair.c
===
--- linux.orig/kernel/sched_fair.c
+++ linux/kernel/sched_fair.c
@@ -124,16 +124,6 @@ max_vruntime(u64 min_vruntime, u64 vrunt
return min_vruntime;
 }
 
-static inline void
-set_leftmost(struct cfs_rq *cfs_rq, struct rb_node *leftmost)
-{
-   struct sched_entity *se;
-
-   cfs_rq->rb_leftmost = leftmost;
-   if (leftmost)
-   se = rb_entry(leftmost, struct sched_entity, run_node);
-}
-
 static inline s64
 entity_key(struct cfs_rq *cfs_rq, struct sched_entity *se)
 {
@@ -175,7 +165,7 @@ __enqueue_entity(struct cfs_rq *cfs_rq, 
 * used):
 */
if (leftmost)
-   set_leftmost(cfs_rq, >run_node);
+   cfs_rq->rb_leftmost = >run_node;
 
rb_link_node(>run_node, parent, link);
rb_insert_color(>run_node, _rq->tasks_timeline);
@@ -185,7 +175,7 @@ static void
 __dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
 {
if (cfs_rq->rb_leftmost == >run_node)
-   set_leftmost(cfs_rq, rb_next(>run_node));
+   cfs_rq->rb_leftmost = rb_next(>run_node);
 
rb_erase(>run_node, _rq->tasks_timeline);
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.6.16.54-rc1

2007-09-24 Thread Adrian Bunk
Location:
ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/

git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git

RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss


Changes since 2.6.16.53:

Adrian Bunk (1):
  Linux 2.6.16.54-rc1

Alexander Shmelev (1):
  [SPARC32]: Fix bug in sparc optimized memset.

David S. Miller (1):
  [MATH-EMU]: Fix underflow exception reporting.

Ilpo Järvinen (1):
  TCP: Fix TCP handling of SACK in bidirectional flows

James Bottomley (1):
  [MCA] fix bus matching

Konstantin Sharlaimov (2):
  [PPP]: Fix osize too small errors when decoding mppe.
  [PPP]: Fix output buffer size in ppp_decompress_frame().

Mark Fortescue (1):
  [SPARC32]: Fix rounding errors in ndelay/udelay implementation.

Neil Brown (16):
  md: Add '4' to the list of levels for which bitmaps are supported
  md: Don't clear bits in bitmap when writing to one device fails during 
recovery
  md/bitmap: fix online removal of file-backed bitmaps
  md/bitmap: cleaner separation of page attribute handlers in md/bitmap
  md/bitmap: use set_bit etc for bitmap page attributes
  md/bitmap: remove unnecessary page reference manipulations from md/bitmap 
code
  md/bitmap: remove dead code from md/bitmap
  md/bitmap: tidy up i_writecount handling in md/bitmap
  md: Allow re-add to work on array without bitmaps
  md: fix resync speed calculation for restarted resyncs
  md: fix a plug/unplug race in raid5
  md: fix some small races in bitmap plugging in raid5
  md: allow SET_BITMAP_FILE to work on 64bit kernel with 32bit userspace
  md: assorted md and raid1 one-liners
  md: fix a few problems with the interface (sysfs and ioctl) to md
  md: avoid possible BUG_ON in md bitmap handling


 Makefile  |2 
 arch/sparc/kernel/entry.S |   14 ++-
 arch/sparc/lib/memset.S   |2 
 drivers/mca/mca-bus.c |2 
 drivers/md/bitmap.c   |  126 +-
 drivers/md/md.c   |  107 +++--
 drivers/md/raid1.c|   20 
 drivers/md/raid5.c|   46 +++---
 drivers/net/ppp_generic.c |   15 +++
 include/asm-sparc/sfp-machine.h   |6 +
 include/asm-sparc64/sfp-machine.h |2 
 include/linux/compat_ioctl.h  |2 
 include/linux/raid/bitmap.h   |3 
 include/linux/raid/md_k.h |3 
 include/math-emu/op-common.h  |5 -
 include/math-emu/soft-fp.h|7 +
 net/ipv4/tcp_input.c  |5 -
 17 files changed, 226 insertions(+), 141 deletions(-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.23-rc7-mm1

2007-09-24 Thread Kamalesh Babulal
Hi Andrew,

The drivers/net/pasemi_mac seems to be broken and build fails with

CC [M] drivers/net/pasemi_mac.o
drivers/net/pasemi_mac.c: In function ‘pasemi_mac_probe’:
drivers/net/pasemi_mac.c:1153: error: conflicting types for ‘mac’
drivers/net/pasemi_mac.c:1151: error: previous declaration of ‘mac’ was here
drivers/net/pasemi_mac.c:1170: error: incompatible types in assignment
drivers/net/pasemi_mac.c:1172: error: request for member ‘pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1173: error: request for member ‘netdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1175: error: request for member ‘napi’ in
something not a structure or union
drivers/net/pasemi_mac.c:1180: error: request for member ‘dma_txch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1181: error: request for member ‘dma_rxch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1187: error: request for member ‘dma_if’ in
something not a structure or union
drivers/net/pasemi_mac.c:1189: error: request for member ‘dma_if’ in
something not a structure or union
drivers/net/pasemi_mac.c:1194: error: request for member ‘type’ in
something not a structure or union
drivers/net/pasemi_mac.c:1197: error: request for member ‘type’ in
something not a structure or union
drivers/net/pasemi_mac.c:1205: warning: passing argument 1 of
‘pasemi_get_mac_addr’ from incompatible pointer type
drivers/net/pasemi_mac.c:1205: error: request for member ‘mac_addr’ in
something not a structure or union
drivers/net/pasemi_mac.c:1209: error: request for member ‘mac_addr’ in
something not a structure or union
drivers/net/pasemi_mac.c:1209: error: request for member ‘mac_addr’ in
something not a structure or union
drivers/net/pasemi_mac.c:1216: warning: passing argument 1 of
‘pasemi_mac_map_regs’ from incompatible pointer type
drivers/net/pasemi_mac.c:1220: error: request for member ‘rx_status’ in
something not a structure or union
drivers/net/pasemi_mac.c:1220: error: request for member ‘dma_rxch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1221: error: request for member ‘tx_status’ in
something not a structure or union
drivers/net/pasemi_mac.c:1221: error: request for member ‘dma_txch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1223: error: request for member ‘msg_enable’ in
something not a structure or union
drivers/net/pasemi_mac.c:1226: error: request for member ‘msg_enable’ in
something not a structure or union
drivers/net/pasemi_mac.c:1231: error: request for member ‘pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1231: error: request for member ‘pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1237: error: request for member ‘type’ in
something not a structure or union
drivers/net/pasemi_mac.c:1238: error: request for member ‘dma_if’ in
something not a structure or union
drivers/net/pasemi_mac.c:1238: error: request for member ‘dma_txch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1238: error: request for member ‘dma_rxch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1244: error: request for member ‘iob_pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1245: error: request for member ‘iob_pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1246: error: request for member ‘dma_pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1247: error: request for member ‘dma_pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1248: error: request for member ‘dma_regs’ in
something not a structure or union
drivers/net/pasemi_mac.c:1249: error: request for member ‘dma_regs’ in
something not a structure or union
drivers/net/pasemi_mac.c:1250: error: request for member ‘iob_regs’ in
something not a structure or union
drivers/net/pasemi_mac.c:1251: error: request for member ‘iob_regs’ in
something not a structure or union
drivers/net/pasemi_mac.c:1252: error: request for member ‘regs’ in
something not a structure or union
drivers/net/pasemi_mac.c:1253: error: request for member ‘regs’ in
something not a structure or union
make[2]: *** [drivers/net/pasemi_mac.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2

In the function
static int __devinit
pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{

struct pasemi_mac *mac;
int err;
DECLARE_MAC_BUF(mac);

introduction of mac as var [18] triggers the build failure, so in the
below patch
renaming mac as mac_buf is done, because it is used to print the mac
address using
the newly introduced print_mac function.

Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]>
---

--- linux-2.6.23-rc7/drivers/net/pasemi_mac.c   2007-09-25 03:27:45.0 
+0530
+++ linux-2.6.23-rc7/drivers/net/~pasemi_mac.c  2007-09-25 03:27:27.0 
+0530
@@ -1150,7 +1150,7 @@ pasemi_mac_probe(struct pci_dev *pdev, c
struct net_device *dev;

Re: [PATCH/RFC] samples/: move kprobes sources to samples

2007-09-24 Thread Mathieu Desnoyers
* Randy Dunlap ([EMAIL PROTECTED]) wrote:
> 
> This is RFC patch 2/2.
> Patch 1/2 introduces the samples/ infrastructure:
>   http://lkml.org/lkml/2007/9/24/397
> 

Hi Randy,

I got this when building my markers (which looks alike your kprobes):

ld: samples/built-in.o: No such file: No such file or directory
make: *** [.tmp_vmlinux1] Error 1

And the Makefile from samples does not seem to be executed. And why is
there a Kbuild file in your first patch ?

Mathieu

> 
> ---
> 
> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Move kprobes source files from Documentation/kprobes.txt to
> samples/kprobes/ and add them to the build system.
> 
> Fix sparse warnings in all 3 kprobes samples source files.
> 
> Although kprobe-example.c is x86-specific, make it build on any
> platform by surrounding some code in ifdef/endif blocks.
> 
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> ---
>  Documentation/kprobes.txt   |  214 
> 
>  samples/Kconfig |5 
>  samples/Makefile|3 
>  samples/kprobes/Makefile|5 
>  samples/kprobes/jprobe_example.c|   65 ++
>  samples/kprobes/kprobe_example.c|   79 +
>  samples/kprobes/kretprobe-example.c |   60 ++
>  7 files changed, 222 insertions(+), 209 deletions(-)
> 
> --- /dev/null
> +++ linux-2.6.23-rc7/samples/kprobes/Makefile
> @@ -0,0 +1,5 @@
> +# builds the kprobes example kernel modules;
> +# then to use one (as root):  insmod 
> +
> +obj-$(CONFIG_SAMPLE_KPROBES) += kprobe_example.o jprobe_example.o \
> + kretprobe-example.o
> --- linux-2.6.23-rc7.orig/samples/Kconfig
> +++ linux-2.6.23-rc7/samples/Kconfig
> @@ -7,5 +7,10 @@ menuconfig SAMPLES
>  
>  if SAMPLES
>  
> +config SAMPLE_KPROBES
> + tristate "Build kprobes examples -- loadable modules only"
> + depends on KPROBES && m
> + help
> +   This builds several kprobes example modules.
>  
>  endif # SAMPLES
> --- /dev/null
> +++ linux-2.6.23-rc7/samples/kprobes/jprobe_example.c
> @@ -0,0 +1,65 @@
> +/*jprobe-example.c */
> +/*
> + * Here's a sample kernel module showing the use of jprobes to dump
> + * the arguments of do_fork().
> + *
> + * Build and insert the kernel module as done in the kprobe example.
> + * You will see the trace data in /var/log/messages and on the
> + * console whenever do_fork() is invoked to create a new process.
> + * (Some messages may be suppressed if syslogd is configured to
> + * eliminate duplicate messages.)
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Jumper probe for do_fork.
> + * Mirror principle enables access to arguments of the probed routine
> + * from the probe handler.
> + */
> +
> +/* Proxy routine having the same arguments as actual do_fork() routine */
> +static long jdo_fork(unsigned long clone_flags, unsigned long stack_start,
> +   struct pt_regs *regs, unsigned long stack_size,
> +   int __user * parent_tidptr, int __user * child_tidptr)
> +{
> + printk("jprobe: clone_flags=0x%lx, stack_size=0x%lx, regs=0x%p\n",
> +clone_flags, stack_size, regs);
> + /* Always end with a call to jprobe_return(). */
> + jprobe_return();
> + /*NOTREACHED*/
> + return 0;
> +}
> +
> +static struct jprobe my_jprobe = {
> + .entry = jdo_fork
> +};
> +
> +static int __init jprobe_init(void)
> +{
> + int ret;
> + my_jprobe.kp.symbol_name = "do_fork";
> +
> + if ((ret = register_jprobe(_jprobe)) <0) {
> + printk("register_jprobe failed, returned %d\n", ret);
> + return -1;
> + }
> + printk("Planted jprobe at %p, handler addr %p\n",
> +my_jprobe.kp.addr, my_jprobe.entry);
> + return 0;
> +}
> +
> +static void __exit jprobe_exit(void)
> +{
> + unregister_jprobe(_jprobe);
> + printk("jprobe unregistered\n");
> +}
> +
> +module_init(jprobe_init)
> +module_exit(jprobe_exit)
> +MODULE_LICENSE("GPL");
> --- /dev/null
> +++ linux-2.6.23-rc7/samples/kprobes/kprobe_example.c
> @@ -0,0 +1,79 @@
> +/*kprobe_example.c*/
> +/*
> + * NOTE: This example is x86-specific.
> + * Here's a sample kernel module showing the use of kprobes to dump a
> + * stack trace and selected i386 registers when do_fork() is called.
> + *
> + * You will see the trace data in /var/log/messages and on the console
> + * whenever do_fork() is invoked to create a new process.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*For each probe you need to allocate a kprobe structure*/
> +static struct kprobe kp;
> +
> +/*kprobe pre_handler: called just before the probed instruction is executed*/
> +static int handler_pre(struct kprobe *p, struct pt_regs *regs)
> +{
> +#ifdef CONFIG_X86_32
> + printk("pre_handler: p->addr=0x%p, eip=%lx, eflags=0x%lx\n",
> + p->addr, regs->eip, regs->eflags);
> +#endif
> +#ifdef CONFIG_X86_64
> + 

[patch 2/2] Enable Aggressive Link Power management for AHCI controllers.

2007-09-24 Thread Kristen Carlson Accardi
This patch will set the correct bits to turn on Aggressive
Link Power Management (ALPM) for the ahci driver.  This
will cause the controller and disk to negotiate a lower
power state for the link when there is no activity (see
the AHCI 1.x spec for details).  This feature is mutually
exclusive with Hot Plug, so when ALPM is enabled, Hot Plug
is disabled.  ALPM will be enabled by default, but it is
settable via the scsi host syfs interface.  Possible 
settings for this feature are:

Setting Effect
--
min_power   ALPM is enabled, and link set to enter 
lowest power state (SLUMBER) when idle
Hot plug not allowed.

max_performance ALPM is disabled, Hot Plug is allowed

medium_powerALPM is enabled, and link set to enter
second lowest power state (PARTIAL) when
idle.  Hot plug not allowed.

Signed-off-by:  Kristen Carlson Accardi <[EMAIL PROTECTED]>

---
 drivers/ata/ahci.c |  154 -
 1 file changed, 153 insertions(+), 1 deletion(-)

Index: libata-dev/drivers/ata/ahci.c
===
--- libata-dev.orig/drivers/ata/ahci.c  2007-09-24 13:43:10.0 -0700
+++ libata-dev/drivers/ata/ahci.c   2007-09-24 13:48:59.0 -0700
@@ -48,6 +48,9 @@
 #define DRV_NAME   "ahci"
 #define DRV_VERSION"2.3"
 
+static int ahci_enable_alpm(struct ata_port *ap,
+   enum link_pm policy);
+static int ahci_disable_alpm(struct ata_port *ap);
 
 enum {
AHCI_PCI_BAR= 5,
@@ -97,6 +100,7 @@ enum {
/* HOST_CAP bits */
HOST_CAP_SSC= (1 << 14), /* Slumber capable */
HOST_CAP_CLO= (1 << 24), /* Command List Override support */
+   HOST_CAP_ALPM   = (1 << 26), /* Aggressive Link PM support */
HOST_CAP_SSS= (1 << 27), /* Staggered Spin-up */
HOST_CAP_SNTF   = (1 << 29), /* SNotification register */
HOST_CAP_NCQ= (1 << 30), /* Native Command Queueing */
@@ -152,6 +156,8 @@ enum {
  PORT_IRQ_PIOS_FIS | PORT_IRQ_D2H_REG_FIS,
 
/* PORT_CMD bits */
+   PORT_CMD_ASP= (1 << 27), /* Aggressive Slumber/Partial */
+   PORT_CMD_ALPE   = (1 << 26), /* Aggressive Link PM enable */
PORT_CMD_ATAPI  = (1 << 24), /* Device is ATAPI */
PORT_CMD_LIST_ON= (1 << 15), /* cmd list DMA engine running */
PORT_CMD_FIS_ON = (1 << 14), /* FIS DMA engine running */
@@ -177,7 +183,7 @@ enum {
 
AHCI_FLAG_COMMON= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
  ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
- ATA_FLAG_ACPI_SATA,
+ ATA_FLAG_ACPI_SATA | ATA_FLAG_IPM,
AHCI_LFLAG_COMMON   = ATA_LFLAG_SKIP_D2H_BSY,
 };
 
@@ -242,6 +248,11 @@ static int ahci_pci_device_suspend(struc
 static int ahci_pci_device_resume(struct pci_dev *pdev);
 #endif
 
+static struct class_device_attribute *ahci_shost_attrs[] = {
+   _device_attr_link_power_management_policy,
+   NULL
+};
+
 static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
.name   = DRV_NAME,
@@ -259,6 +270,7 @@ static struct scsi_host_template ahci_sh
.slave_configure= ata_scsi_slave_config,
.slave_destroy  = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+   .shost_attrs= ahci_shost_attrs,
 };
 
 static const struct ata_port_operations ahci_ops = {
@@ -286,6 +298,8 @@ static const struct ata_port_operations 
.port_suspend   = ahci_port_suspend,
.port_resume= ahci_port_resume,
 #endif
+   .enable_pm  = ahci_enable_alpm,
+   .disable_pm = ahci_disable_alpm,
 
.port_start = ahci_port_start,
.port_stop  = ahci_port_stop,
@@ -767,6 +781,130 @@ static void ahci_power_up(struct ata_por
writel(cmd | PORT_CMD_ICC_ACTIVE, port_mmio + PORT_CMD);
 }
 
+static int ahci_disable_alpm(struct ata_port *ap)
+{
+   void __iomem *port_mmio = ahci_port_base(ap);
+   u32 cmd;
+   struct ahci_port_priv *pp = ap->private_data;
+
+   /* IPM bits should be disabled by libata-core */
+   /* get the existing command bits */
+   cmd = readl(port_mmio + PORT_CMD);
+
+   /* disable ALPM and ASP */
+   cmd &= ~PORT_CMD_ASP;
+   cmd &= ~PORT_CMD_ALPE;
+
+   /* force the interface back to active */
+   cmd |= PORT_CMD_ICC_ACTIVE;
+
+   /* write out new cmd value */
+   writel(cmd, port_mmio + PORT_CMD);
+   cmd = readl(port_mmio + PORT_CMD);
+
+   /* wait 10ms to be sure we've come out 

Re: [-mm Patch] net/bluetooth/hidp/core.c: Make hidp_setup_input() return int

2007-09-24 Thread Marcel Holtmann
Hi Wang,

> This patch:
> - makes hidp_setup_input() return int to indicate errors;
> - checks its return value to handle errors.
> 
> And this time it is against -rc7-mm1 tree.
> 
> Thanks to roel and Marcel Holtmann for comments.
> 
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>

Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>

Regards

Marcel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] Enable link power management for ata drivers

2007-09-24 Thread Kristen Carlson Accardi
Device Initiated Power Management, which is defined
in SATA 2.5 can be enabled for disks which support it.
This patch enables DIPM when the user sets the link
power management policy to "min_power".

Additionally, libata drivers can define a function 
(enable_pm) that will perform hardware specific actions to 
enable whatever power management policy the user set up 
for Host Initiated Power management (HIPM).
This power management policy will be activated after all 
disks have been enumerated and intialized.  Drivers should 
also define disable_pm, which will turn off link power 
management, but not change link power management policy.

Signed-off-by:  Kristen Carlson Accardi <[EMAIL PROTECTED]>
---
 Documentation/scsi/link_power_management_policy.txt |   19 +
 drivers/ata/libata-core.c   |  194 +++-
 drivers/ata/libata-eh.c |5 
 drivers/ata/libata-scsi.c   |   83 
 include/linux/ata.h |7 
 include/linux/libata.h  |   25 ++
 6 files changed, 322 insertions(+), 11 deletions(-)

Index: libata-dev/drivers/ata/libata-scsi.c
===
--- libata-dev.orig/drivers/ata/libata-scsi.c   2007-09-24 13:43:10.0 
-0700
+++ libata-dev/drivers/ata/libata-scsi.c2007-09-24 13:46:22.0 
-0700
@@ -110,6 +110,78 @@ static struct scsi_transport_template at
 };
 
 
+static const struct {
+   enum link_pmvalue;
+   char*name;
+} link_pm_policy[] = {
+   { NOT_AVAILABLE, "max_performance" },
+   { MIN_POWER, "min_power" },
+   { MAX_PERFORMANCE, "max_performance" },
+   { MEDIUM_POWER, "medium_power" },
+};
+
+const char *ata_scsi_link_pm_policy(enum link_pm policy)
+{
+   int i;
+   char *name = NULL;
+
+   for (i = 0; i < ARRAY_SIZE(link_pm_policy); i++) {
+   if (link_pm_policy[i].value == policy) {
+   name = link_pm_policy[i].name;
+   break;
+   }
+   }
+   return name;
+}
+
+static ssize_t store_link_pm_policy(struct class_device *class_dev,
+   const char *buf, size_t count)
+{
+   struct Scsi_Host *shost = class_to_shost(class_dev);
+   struct ata_port *ap = ata_shost_to_port(shost);
+   enum link_pm policy = 0;
+   int i;
+
+   /*
+* we are skipping array location 0 on purpose - this
+* is because a value of NOT_AVAILABLE is displayed
+* to the user as max_performance, but when the user
+* writes "max_performance", they actually want the
+* value to match MAX_PERFORMANCE.
+*/
+   for (i = 1; i < ARRAY_SIZE(link_pm_policy); i++) {
+   const int len = strlen(link_pm_policy[i].name);
+   if (strncmp(link_pm_policy[i].name, buf, len) == 0 &&
+  buf[len] == '\n') {
+   policy = link_pm_policy[i].value;
+   break;
+   }
+   }
+   if (!policy)
+   return -EINVAL;
+
+   if (ata_scsi_set_link_pm_policy(ap, policy))
+   return -EINVAL;
+   return count;
+}
+
+static ssize_t
+show_link_pm_policy(struct class_device *class_dev, char *buf)
+{
+   struct Scsi_Host *shost = class_to_shost(class_dev);
+   struct ata_port *ap = ata_shost_to_port(shost);
+   const char *policy =
+   ata_scsi_link_pm_policy(ap->pm_policy);
+
+   if (!policy)
+   return -EINVAL;
+
+   return snprintf(buf, 23, "%s\n", policy);
+}
+CLASS_DEVICE_ATTR(link_power_management_policy, S_IRUGO | S_IWUSR,
+   show_link_pm_policy, store_link_pm_policy);
+EXPORT_SYMBOL_GPL(class_device_attr_link_power_management_policy);
+
 static void ata_scsi_invalid_field(struct scsi_cmnd *cmd,
   void (*done)(struct scsi_cmnd *))
 {
@@ -3041,6 +3113,17 @@ void ata_scsi_simulate(struct ata_device
}
 }
 
+int ata_scsi_set_link_pm_policy(struct ata_port *ap,
+   enum link_pm policy)
+{
+   ap->pm_policy = policy;
+   ap->link.eh_info.action |= ATA_EHI_LPM;
+   ap->link.eh_info.flags |= ATA_EHI_NO_AUTOPSY;
+   ata_port_schedule_eh(ap);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(ata_scsi_set_link_pm_policy);
+
 int ata_scsi_add_hosts(struct ata_host *host, struct scsi_host_template *sht)
 {
int i, rc;
Index: libata-dev/include/linux/libata.h
===
--- libata-dev.orig/include/linux/libata.h  2007-09-24 13:43:10.0 
-0700
+++ libata-dev/include/linux/libata.h   2007-09-24 13:47:57.0 -0700
@@ -140,6 +140,8 @@ enum {
ATA_DFLAG_ACPI_PENDING  = (1 << 5), /* ACPI resume action pending */
ATA_DFLAG_ACPI_FAILED   = (1 << 6), /* ACPI on devcfg has failed */
ATA_DFLAG_AN= (1 << 7), /* 

[patch 0/2] SATA Link Power Management patches

2007-09-24 Thread Kristen Carlson Accardi
Here's a set of patches which implement link power management for SATA. 
We had talked at kernel summit of moving sysfs interface for setting
the link power management policy to the block layer, but after a 
lot of consideration, I think this doesn't make sense.  Mainly because
I feel for SATA the link power management policy should be associated
with the controller, not with the device. So, we continue to use
the shost_attrs array in the scsi host template to create a sysfs
interface that is associated with the scsi_host class. 

These patches have changed since the last version.  The patches have
been refreshed to use the new ata_link structures.  Additionally, I've
separated out DIPM enabling and put it into libata-core, because DIPM
can be used by any SATA disk that is attached to a controller which
allows DIPM, although in this implementation the driver will need
to explicitly set a flag which would indicate to the core that it
is OK to set DIPM.  This is because all interface power state changes
can cause Phy Ready interrupts, and the driver will need to know
to ignore them. DIPM will only be enabled for the min_power link
power management policy value.  This is because many disks are not
clever enough to know that if a controller naks their request for
a SLUMBER transition, they should retry for PARTIAL - instead they
will just give up all together.

With these patches, measured on my X60 with a Watts Up Pro meter,
in the base station after all powertop suggestions have been applied,  
I see a savings of approximately .7-.8 W in min_power mode, and
.5 W in medium_power mode.  For the best power/performance tradeoff,
it's recommended that you use the "medium_power" setting, although
min_power can be used of course when you absolutely need to save
every 10th of a watt and don't care about the additional performance
loss.

Please give them a try.
Thanks,
Kristen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/11] eCryptfs: read_write.c routines

2007-09-24 Thread Michael Halcrow
On Wed, Sep 19, 2007 at 10:38:50PM -0700, Andrew Morton wrote:
> > +   offset = (page_for_lower->index << PAGE_CACHE_SHIFT) + offset_in_page;
> 
> bug.  You need to cast page.index to loff_t before shifting.
> 
> I'd fix it on the spot, but this would be a good time to review the
> whole patchset and perhaps the whole fs for this easy-to-do,
> hard-to-find bug.

Update data types and add casts in order to avoid potential overflow
issues.

Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 5d27cf9..4bf1a95 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -149,7 +149,7 @@ out:
  * ecryptfs_derive_iv
  * @iv: destination for the derived iv vale
  * @crypt_stat: Pointer to crypt_stat struct for the current inode
- * @offset: Offset of the page whose's iv we are to derive
+ * @offset: Offset of the extent whose IV we are to derive
  *
  * Generate the initialization vector from the given root IV and page
  * offset.
@@ -157,7 +157,7 @@ out:
  * Returns zero on success; non-zero on error.
  */
 static int ecryptfs_derive_iv(char *iv, struct ecryptfs_crypt_stat *crypt_stat,
- pgoff_t offset)
+ loff_t offset)
 {
int rc = 0;
char dst[MD5_DIGEST_SIZE];
@@ -173,7 +173,7 @@ static int ecryptfs_derive_iv(char *iv, struct 
ecryptfs_crypt_stat *crypt_stat,
 * hashing business. -Halcrow */
memcpy(src, crypt_stat->root_iv, crypt_stat->iv_bytes);
memset((src + crypt_stat->iv_bytes), 0, 16);
-   snprintf((src + crypt_stat->iv_bytes), 16, "%ld", offset);
+   snprintf((src + crypt_stat->iv_bytes), 16, "%lld", offset);
if (unlikely(ecryptfs_verbosity > 0)) {
ecryptfs_printk(KERN_DEBUG, "source:\n");
ecryptfs_dump_hex(src, (crypt_stat->iv_bytes + 16));
@@ -384,11 +384,11 @@ static int ecryptfs_encrypt_extent(struct page 
*enc_extent_page,
   struct page *page,
   unsigned long extent_offset)
 {
-   unsigned long extent_base;
+   loff_t extent_base;
char extent_iv[ECRYPTFS_MAX_IV_BYTES];
int rc;
 
-   extent_base = (page->index
+   extent_base = (((loff_t)page->index)
   * (PAGE_CACHE_SIZE / crypt_stat->extent_size));
rc = ecryptfs_derive_iv(extent_iv, crypt_stat,
(extent_base + extent_offset));
@@ -492,8 +492,9 @@ int ecryptfs_encrypt_page(struct page *page)
goto out;
}
ecryptfs_lower_offset_for_extent(
-   , ((page->index * (PAGE_CACHE_SIZE
- / crypt_stat->extent_size))
+   , loff_t)page->index)
+  * (PAGE_CACHE_SIZE
+ / crypt_stat->extent_size))
  + extent_offset), crypt_stat);
rc = ecryptfs_write_lower(ecryptfs_inode, enc_extent_virt,
  offset, crypt_stat->extent_size);
@@ -515,11 +516,11 @@ static int ecryptfs_decrypt_extent(struct page *page,
   struct page *enc_extent_page,
   unsigned long extent_offset)
 {
-   unsigned long extent_base;
+   loff_t extent_base;
char extent_iv[ECRYPTFS_MAX_IV_BYTES];
int rc;
 
-   extent_base = (page->index
+   extent_base = (((loff_t)page->index)
   * (PAGE_CACHE_SIZE / crypt_stat->extent_size));
rc = ecryptfs_derive_iv(extent_iv, crypt_stat,
(extent_base + extent_offset));
@@ -1320,7 +1321,7 @@ ecryptfs_write_metadata_to_contents(struct 
ecryptfs_crypt_stat *crypt_stat,
while (current_header_page < header_pages) {
loff_t offset;
 
-   offset = (current_header_page << PAGE_CACHE_SHIFT);
+   offset = (((loff_t)current_header_page) << PAGE_CACHE_SHIFT);
if ((rc = ecryptfs_write_lower(ecryptfs_dentry->d_inode,
   page_virt, offset,
   PAGE_CACHE_SIZE))) {
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index c6a8a33..4eb09c1 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -127,7 +127,8 @@ ecryptfs_copy_up_encrypted_with_header(struct page *page,
int rc = 0;
 
while (extent_num_in_page < num_extents_per_page) {
-   loff_t view_extent_num = ((page->index * num_extents_per_page)
+   loff_t view_extent_num = loff_t)page->index)
+  * num_extents_per_page)
  + extent_num_in_page);
 
if (view_extent_num < crypt_stat->num_header_extents_at_front) {
@@ -418,7 +419,7 @@ 

i386: Fix null interrupt handler (ignore_int) message ?

2007-09-24 Thread Ahmed S. Darwish
Hi all,

I'm getting little confused by some ignore_int (null interrupt handler) code in
head.S. Code notifies the user about the unknown raised interrupt by below
string:

int_msg:
.asciz "Unknown interrupt or fault at EIP %p %p %p\n"

and prints it using below code path:

ignore_int:
pushl %eax; pushl %ecx; pushl %edx; pushl %es; pushl %ds
[...]
pushl 16(%esp); pushl 24(%esp); 
pushl 32(%esp); pushl 40(%esp); 
pushl $int_msg
[...]
call printk

** But here's the state of stack before calling printk:

 ???<-- 40(%esp) 
 ???<-- 36(%esp)
 --> (Automatically pushed by the processor)
 %eflags<-- 32(%esp)
 %cs<-- 28(%esp)
 %eip   <-- 24(%esp)
 error-code <-- 20(%esp)
 --> (Pushed by first lines of ignore_int)
 %eax   <-- 16(%esp)
 %ecx   <-- 12(%esp)
 %edx   <-- 8(%esp)
 %es<-- 4(%esp)
 %ds<-- %esp  

Does 40(%esp) hold a meaningfule value here ?. Also why passing 4 arguments 
after
the string to prinkt while the string only has 3 conversion specifications 
(i.e.,
3 * %p) ?.

Best regards,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 24/25] r/o bind mounts: track number of mount writers

2007-09-24 Thread Dave Hansen
On Sun, 2007-09-23 at 23:17 -0700, Andrew Morton wrote:
> It look like a false positive to me, but really, for a patchset of this
> complexity and maturity I cannot fathom how it could have escaped any
> lockdep testing.

I test with lockdep all the time.  The problem was that lockdep doesn't
complain until you have 8 nested locks, and I only tested on a 4-cpu
system.

I lowered the lockdep nesting limit to 3, and got the warning on my
machine.

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


lockdep wierdness...

2007-09-24 Thread Trond Myklebust
I'm seeing lockdep warning about a potential lock inversion between
>mmap_sem and >i_mutex in NFS (see attachment).

Unfortunately the basis for the warning appears to be the behaviour in
ext3(???). AFAICS there is no way for NFS to share an inode->i_mutex
with ext3. What to do?

Trond
===
[ INFO: possible circular locking dependency detected ]
2.6.23-rc7-g8809e921 #1
---
beagle-build-in/24375 is trying to acquire lock:
 (>mmap_sem){}, at: [] do_page_fault+0x17d/0x591

but task is already holding lock:
 (>i_mutex){--..}, at: [] mutex_lock+0x1c/0x1f

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (>i_mutex){--..}:
   [] __lock_acquire+0x9f3/0xba6
   [] lock_acquire+0x5f/0x78
   [] __mutex_lock_slowpath+0xe5/0x27a
   [] mutex_lock+0x1c/0x1f
   [] nfs_revalidate_mapping+0x64/0x9c [nfs]
   [] nfs_file_mmap+0x46/0x75 [nfs]
   [] mmap_region+0x1ea/0x3b8
   [] do_mmap_pgoff+0x27b/0x2da
   [] sys_mmap2+0x9b/0xb5
   [] sysenter_past_esp+0x5f/0x99
   [] 0x

-> #0 (>mmap_sem){}:
   [] __lock_acquire+0x8df/0xba6
   [] lock_acquire+0x5f/0x78
   [] down_read+0x3a/0x4c
   [] do_page_fault+0x17d/0x591
   [] error_code+0x72/0x78
   [] call_filldir+0xac/0xc3 [ext3]
   [] ext3_readdir+0x217/0x5e5 [ext3]
   [] vfs_readdir+0x67/0x93
   [] sys_getdents+0x5f/0x9d
   [] sysenter_past_esp+0x5f/0x99
   [] 0x

other info that might help us debug this:

1 lock held by beagle-build-in/24375:
 #0:  (>i_mutex){--..}, at: [] mutex_lock+0x1c/0x1f

stack backtrace:
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_trace+0x12/0x14
 [] dump_stack+0x16/0x18
 [] print_circular_bug_tail+0x5f/0x68
 [] __lock_acquire+0x8df/0xba6
 [] lock_acquire+0x5f/0x78
 [] down_read+0x3a/0x4c
 [] do_page_fault+0x17d/0x591
 [] error_code+0x72/0x78
 [] call_filldir+0xac/0xc3 [ext3]
 [] ext3_readdir+0x217/0x5e5 [ext3]
 [] vfs_readdir+0x67/0x93
 [] sys_getdents+0x5f/0x9d
 [] sysenter_past_esp+0x5f/0x99
 ===


  1   2   3   4   5   6   7   8   9   10   >