Re: Ethernet driver on 2.6.22
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
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
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
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
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
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
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
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
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?
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
> 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
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
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
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()
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
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
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
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
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
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
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.
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
* 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
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
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
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
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
(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
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()
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()
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
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()
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
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
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...
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()
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
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
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()
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
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
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
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
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
> 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
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
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)
[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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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()
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
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
[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
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
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
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?
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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
* 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
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
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
* 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.
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
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
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
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
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 ?
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
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...
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 ===