Re: [BUG] 2.6.23-rc5 panics
On Wed, 5 Sep 2007, Roland Dreier wrote: > FWIW, I was running 2.6.23-rc5 on my laptop (along with iwlwifi-0.1.14 > for wireless) and I saw the same symptom: panic (blinking capslock) > while in X. I saw one panic out of maybe 12 hours of uptime over a > few reboots. The same system is quite stable with the stock Ubuntu > 2.6.22 kernel. > > My laptop is a Thinkpad X60s (core duo) so quite a different system. > > I'm traveling at the moment so I probably won't be able to gather much > debugging info until next week. -rc5 users should apply commit 5c127c58ae9bf196d787815b1bd6b0aec5aee816 (or else just move to latest -git). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] disable PCIE 'Enable No Snoop' bit by default
PCIE 'Enable No Snoop' bit is set by default per PCIE spec, but OS
assumes PCI DMA is snooped, which is legacy PCI device does. Enabling no
snoop might cause potential DMA issues. This patch disables it, if a
driver can work with no snoop, we can provide a helper to enable it.
I didn't see any real breaks, but did see some devices with the bit enabled
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux/drivers/pci/probe.c
===
--- linux.orig/drivers/pci/probe.c 2007-09-06 13:18:07.0 +0800
+++ linux/drivers/pci/probe.c 2007-09-06 13:21:30.0 +0800
@@ -694,6 +694,19 @@ static void pci_read_irq(struct pci_dev
#define LEGACY_IO_RESOURCE (IORESOURCE_IO | IORESOURCE_PCI_FIXED)
+static void pcie_setup_device(struct pci_dev *dev)
+{
+ u16 reg16;
+ int pos;
+
+ pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
+ if (pos) {
+ pci_read_config_word(dev, pos + PCI_EXP_DEVCTL, );
+ reg16 &= ~PCI_EXP_DEVCTL_NOSNOOP_EN;
+ pci_write_config_word(dev, pos + PCI_EXP_DEVCTL, reg16);
+ }
+}
+
/**
* pci_setup_device - fill in class and map information of a device
* @dev: the device structure to fill
@@ -795,6 +808,7 @@ static int pci_setup_device(struct pci_d
dev->class = PCI_CLASS_NOT_DEFINED;
}
+ pcie_setup_device(dev);
/* We found a fine healthy device, go go go... */
return 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: [PATCH] Fix preemptible lazy mode bug
>I agree. The patch is a nop. I just got overly paranoid. The whole >thing is just very prone to bugs. So do we need a patch for .23 or not? >; it does > seem perfectly acceptable though for the mm code to use kmap or vmap > (not kmap_atomic) internally somewhere in the pagetable code. i386 does it all the time for highmem pagetables in fact. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23-rc5 panics
FWIW, I was running 2.6.23-rc5 on my laptop (along with iwlwifi-0.1.14 for wireless) and I saw the same symptom: panic (blinking capslock) while in X. I saw one panic out of maybe 12 hours of uptime over a few reboots. The same system is quite stable with the stock Ubuntu 2.6.22 kernel. My laptop is a Thinkpad X60s (core duo) so quite a different system. I'm traveling at the moment so I probably won't be able to gather much debugging info until next week. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [pre-2.6.23 REGRESSION] 2.6.23-rc3-git1 crash/stuck on VIA CN700 system
> This kernel boots up OK. Looking at the preprocessed C code the I assume you tested it a few times to make sure it really was the problem? Perhaps reenable it also once again and see if it hangs again just to be sure. > So what can we do about the clflush on this CPU? I'll just remove that CLFLUSH statement. It was just supposed to be an optimization, but is not strictly needed. The only thing that worries me is that CLFLUSH might be broken in more ways on those VIA CPUs and we also use it in other places. Of course it would be possible to remove it from the kernel capabilities but we can't really stop user space using it. We don't know how many VIA CPU models are affected by this problem. Dave, didn't you have Centaur contacts that could be asked? It seems like CLFLUSH causes kernel hangs -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.6.23-rc5 panics
This may be the most worthless bug report ever filed, but maybe someone else is seeing this that can shed some light on the matter. Everything was rock-solid with -rc3, but I've had two panics with -rc5 in as many days. The first occurred within five minutes of booting. The second was after nearly 48 hours of uptime. Nothing is getting written to syslog, and the second panic happened while X11 was active, so I didn't even get so much as a stack dump on the console -- just the flashing keyboard leds that signaled entry into "brick emulation" mode :-(. System is a k6-III/450 w/SCSI drives (AIC7XXX) and a Netgear FA311 NIC. At this point, I have no idea what's triggering the panics. Doesn't seem related to load that I can tell... -- Bob Tracy | "They couldn't hit an elephant at this dist- " [EMAIL PROTECTED] | - Last words of Union General John Sedgwick, | Battle of Spotsylvania Court House, U.S. Civil War - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: recent nfs change causes autofs regression
On Wed, 2007-09-05 at 16:50 +0100, Trond Myklebust wrote: > On Wed, 2007-09-05 at 16:37 +0100, David Howells wrote: > > Ian Kent <[EMAIL PROTECTED]> wrote: > > > > > But what about mounting with different protocol, tcp vs udp for example. > > > > I was referring specifically to the R/O / R/W variants of the same mount. > > Any > > flag variation that varies the way the NFS client talks to the NFS server > > must > > either result in a new superblock or be ignored. > > > > David > > We currently ignore remount requests that attempt to change the NFS > mount parameters. This is not new behaviour, BTW: it has always been the > case, and nobody has ever requested it. Yes, I only mentioned it because I'm aware it. I've not payed much attention to it because there haven't been any complaints so far and it's been a long time. Ian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: scheduling while atomic: ifconfig/0x00000002/4170
Hi, > On 02/09/07, Florian Lohoff <[EMAIL PROTECTED]> wrote: > > > > Hi, > > with current git i got this when "ifconfig eth1" down. eth1 had a mac > > address which looked really like an eth1394 ethernet although the module > > was not loaded. Something is really broken in 2.6.23-currentgit. I always > > get the -currentgit would be -rc5 right? > > sysfs rename issues which are discussed to be an udev issue. Then i see > > a eth1394 mac address on an interface which typically shouldn exist > > (udev should rename the wireless to eth1) and when issueing an > > ifconfig eth1 down i get a > > > > BUG: scheduling while atomic: ifconfig/0x0002/4170 Is this reproducible? Also, please send your .config. BTW the calltrace below shows that eth1 was the wireless interface when you tried to "down" it. > > On the next boot i see the eth1394 mac address on the wireless interface > > wmaster0_rename whereas eth1 is active (the wireless) and has the correct > > ip address. I don't think the "scheduling while atomic" bug you saw is related to the other problem you're seeing ... these are probably a bunch of all different issues, but I'm not sure if eth1394 is involved at all. > > I dont get it - this all looks really messed up. udev is > > debian sid 114-2. True, messed up it indeed is. > > eth0 Link encap:Ethernet HWaddr 00:17:42:13:45:8C > > UP BROADCAST MULTICAST MTU:1500 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:1000 > > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > Interrupt:19 > > > > eth1 Link encap:Ethernet HWaddr 00:18:DE:63:F0:B3 > > inet addr:195.71.97.208 Bcast:195.71.97.223 Mask:255.255.255.224 > > inet6 addr: fe80::218:deff:fe63:f0b3/64 Scope:Link > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:2079 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:2220 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:1000 > > RX bytes:508959 (497.0 KiB) TX bytes:261123 (255.0 KiB) > > > > wmaster0_ Link encap:UNSPEC HWaddr > > 00-18-DE-63-F0-B3-30-3A-00-00-00-00-00-00-00-00 > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:1000 > > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > > > > > [ 14.300736] VFS: Mounted root (ext3 filesystem) readonly. > > [ 14.300902] Freeing unused kernel memory: 216k freed > > [ 17.618804] irda_init() > > [ 17.618817] NET: Registered protocol family 23 > > [ 17.636399] ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) > > -> IRQ 19 > > [ 17.636588] PCI: Setting latency timer of device :02:00.0 to 64 > > [ 17.636619] sky2 :02:00.0: v1.17 addr 0xf000 irq 19 Yukon-EC > > Ultra (0xb4) rev 2 > > [ 17.648081] parport_pc 00:0c: reported by Plug and Play ACPI > > [ 17.648206] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP] > > [ 17.653652] sky2 eth0: addr 00:17:42:13:45:8c > > [ 17.680848] input: Video Bus as /class/input/input6 > > [ 17.680961] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: > > no) > > [ 17.757019] usbcore: registered new interface driver usbfs > > [ 17.757139] usbcore: registered new interface driver hub > > [ 17.757264] usbcore: registered new device driver usb > > [ 17.824819] Yenta: CardBus bridge found at :08:03.0 [10cf:131e] > > [ 17.824941] Yenta O2: res at 0x94/0xD4: 00/ea > > [ 17.825034] Yenta O2: enabling read prefetch/write burst > > [ 17.828363] hda: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, > > UDMA(33) > > [ 17.828838] Uniform CD-ROM driver Revision: 3.20 > > [ 17.891481] USB Universal Host Controller Interface driver v3.0 > > [ 17.891650] ACPI: PCI Interrupt :00:1d.0[A] -> GSI 23 (level, low) > > -> IRQ 22 > > [ 17.891840] PCI: Setting latency timer of device :00:1d.0 to 64 > > [ 17.891844] uhci_hcd :00:1d.0: UHCI Host Controller > > [ 17.892155] uhci_hcd :00:1d.0: new USB bus registered, assigned bus > > number 1 > > [ 17.892327] uhci_hcd :00:1d.0: irq 22, io base 0x1820 > > [ 17.892571] usb usb1: configuration #1 chosen from 1 choice > > [ 17.892689] hub 1-0:1.0: USB hub found > > [ 17.892784] hub 1-0:1.0: 2 ports detected > > [ 17.924265] found SMC SuperIO Chip (devid=0x7a rev=00 base=0x002e): > > LPC47N227 > > [ 17.924390] smsc_superio_flat(): fir: 0x6e8, sir: 0x2e8, dma: 03, irq: > > 3, mode: 0x0e > > [ 17.924526] smsc_ircc_present: can't get sir_base of 0x2e8 > > [ 17.954918] Yenta: ISA IRQ mask 0x0c38, PCI irq 19 > > [ 17.955009] Socket status: 3006 > > [ 17.955094] Yenta: Raising subordinate bus#
Re: [PATCH][RFC] pte notifiers -- support for external page tables
On Wed, 2007-09-05 at 22:32 +0300, Avi Kivity wrote: > [resend due to bad alias expansion resulting in some recipients > being bogus] > > Some hardware and software systems maintain page tables outside the normal > Linux page tables, which reference userspace memory. This includes > Infiniband, other RDMA-capable devices, and kvm (with a pending patch). > > Because these systems maintain external page tables (and external tlbs), > Linux cannot demand page this memory and it must be locked. For kvm at > least, this is a significant reduction in functionality. > > This sample patch adds a new mechanism, pte notifiers, that allows drivers > to register an interest in a changes to ptes. Whenever Linux changes a > pte, it will call a notifier to allow the driver to adjust the external > page table and flush its tlb. > > Note that only one notifier is implemented, ->clear(), but others should be > similar. > > pte notifiers are different from paravirt_ops: they extend the normal > page tables rather than replace them; and they provide high-level > information > such as the vma and the virtual address for the driver to use. Looks great. So for kvm, all guest pages will be vma mapped? There are lock issues in kvm between kvm lock and page lock. Will shadow page table be still stored in page->private? If yes, the page->private must be cleaned before add_to_swap. Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.23-rc4-mm1] m32r: serial: remove M32R_SIO_SHARE_IRQS
Remove an unused symbol M32R_SIO_SHARE_IRQS from
drivers/serial/m32r_sio.h.
Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]>
Cc: "Robert P. J. Day" <[EMAIL PROTECTED]>
---
drivers/serial/m32r_sio.c |2 +-
drivers/serial/m32r_sio.h |6 --
2 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
index 6e09c8b..348ee2c 100644
--- a/drivers/serial/m32r_sio.c
+++ b/drivers/serial/m32r_sio.c
@@ -539,7 +539,7 @@ static void serial_do_unlink(struct irq_info *i, struct
uart_sio_port *up)
static int serial_link_irq_chain(struct uart_sio_port *up)
{
struct irq_info *i = irq_lists + up->port.irq;
- int ret, irq_flags = up->port.flags & UPF_SHARE_IRQ ? IRQF_SHARED : 0;
+ int ret, irq_flags = 0;
spin_lock_irq(>lock);
diff --git a/drivers/serial/m32r_sio.h b/drivers/serial/m32r_sio.h
index 849f1b2..e9b7e11 100644
--- a/drivers/serial/m32r_sio.h
+++ b/drivers/serial/m32r_sio.h
@@ -46,9 +46,3 @@ struct old_serial_port {
#define PROBE_ANY (~0)
#define HIGH_BITS_OFFSET ((sizeof(long)-sizeof(int))*8)
-
-#ifdef CONFIG_SERIAL_SIO_SHARE_IRQ
-#define M32R_SIO_SHARE_IRQS 1
-#else
-#define M32R_SIO_SHARE_IRQS 0
-#endif
--
1.5.2.4
--
Hirokazu Takata <[EMAIL PROTECTED]>
Linux/M32R Project: http://www.linux-m32r.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/
Re: [ANNOUNCE/RFC] Really Fair Scheduler
Am Montag, den 03.09.2007, 04:58 +0200 schrieb Roman Zippel: > Hi, > > On Sun, 2 Sep 2007, Ingo Molnar wrote: > > > > Did you even try to understand what I wrote? I didn't say that it's a > > > "common problem", it's a conceptual problem. The rounding has been > > > improved lately, so it's not as easy to trigger with some simple busy > > > loops. > > > > As i mentioned it in my first reply to you i really welcome your changes > > and your interest in the Linux scheduler, but i'm still somewhat > > surprised why you focus on rounding so much (and why you attack CFS's > > math implementation so vehemently and IMO so unfairly) - and we had this > > discussion before in the "CFS review" thread that you started. > > The rounding is insofar a problem as it makes it very difficult to produce > a correct mathematical model of CFS, which can be used to verify the > working of code. > With the recent rounding changes they have indeed little effect in the > short term, especially as the error is distributed equally to the task, so > every task gets relatively the same time, the error still exists > nonetheless and adds up over time (although with the rounding changes it > doesn't grow into one direction anymore). So, its like i roll a dice repeatedly and subtract 3.5 every time? Even in the long run the the result should be close to zero. > The problem is now the limiting, > which you can't remove as long as the error exists. Part of this problem > is that CFS doesn't really maintain a balanced sum of the available > runtime, i.e. the sum of all updated wait_runtime values of all active > tasks should be zero. This means under complex loads it's possible to hit > the wait_runtime limits and the overflow/underflow time is lost in the > calculation and this value can be easily in the millisecond range. > To be honest I have no idea how real this problem in the praxis is right > now, quite possibly people will only see it as a small glitch and in most > cases they won't even notice. So, given the above example, if the result of the dice rolls ever exceeds +/- 1,000,000 i´ll get some ugly timing glitches? As the number of dice rolls grows towards infinity the chance of remaining within this boundary goes steadily towards 0%. What does this equate to in the real world? Weeks, month, years, milennia? > Previously it had been rather easy to > trigger these problems due to the rounding problems. The main problem for > me here is now that with any substantial change in CFS I'm running risk of > making this worse and noticable again somehow. For example CFS relies on > the 64bit math to have enough resolution so that the errors aren't > noticable. > That's why I needed a mathematical model I can work with and with it for > example I can easily downscale the math to 32bit and I know exactly the > limits within it will work correctly. If i understand the problem correctly these errors occur due to the fact that delta-values are used instead of recalculating the "fair" process time every "dice" roll? Somehow the dead simple solution would seem to "reset" or "reinitialise" the "dice" roll every million rolls or so. Or, to put this into context again, figure out how large the accumulated error would have to be to be noticable. Then figure out how long it would take for such an error occur in the real world and just reinitialise the damn thing. Should´nt be too complicated stochastics. Greetings, Syren - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] m32r: Please pull m32r kernel updates for 2.6.23-rc5
Hello, Linus, The following is a series of patches to update m32r architecure support for 2.6.23-rc5: - Rearrange platform support codes and move them to arch/m32r/platforms/ - Move config files to arch/m32r/config/ - Simplify and cleanup ei_handler routine of arch/m32r/kernel/entry.S Please pull from the "for-linus" branch of git://www.linux-m32r.org/git/takata/linux-2.6_dev.git Thease patches have tested after 2.6.23-rc3-mm1. Thanks, -- Takata Hirokazu Takata (12): m32r: Move defconfig files to arch/m32r/configs/ m32r: Update defconfig files for 2.6.23-rc1 m32r: Add defconfig file for the usrv platform. m32r: Rearrange platform-dependent codes m32r: Move dot.gdbinit files m32r: Define symbols to unify platform-dependent ICU checks m32r: Simplify ei_handler code m32r: Exit ei_handler directly for no IRQ case or IPI operations m32r: Cosmetic updates of arch/m32r/kernel/entry.S m32r: Separate syscall table from entry.S m32r: build fix of entry.S m32r: Rename STI/CLI macros -- commit 7071b2914a540b43dfcad17f6892a8c115799d50 Author: Hirokazu Takata <[EMAIL PROTECTED]> Date: Mon Aug 20 20:53:50 2007 +0900 m32r: Rename STI/CLI macros The names of STI and CLI macros were derived from i386 arch historically, but their name are incomprehensible. So, for easy to understand, rename these macros to ENABLE_INTERRUPTS and DISABLE_INTERRUPTS, respectively. Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]> commit 33205613cd603fa4d80bb81464e60b909b7047e1 Author: Hirokazu Takata <[EMAIL PROTECTED]> Date: Tue Aug 21 12:04:29 2007 +0900 m32r: build fix of entry.S This patch fixes the following compile error: <-- snip --> ... AS arch/m32r/kernel/entry.o /home/bunk/linux/kernel-2.6/linux-2.6.23-rc3-mm1/arch/m32r/kernel/entry.S: Assembler messages: /home/bunk/linux/kernel-2.6/linux-2.6.23-rc3-mm1/arch/m32r/kernel/entry.S:358: Error: bad instruction `addi r0,#(0)+(64))+(32))+(32)))' make[2]: *** [arch/m32r/kernel/entry.o] Error 1 <-- snip --> Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]> Cc: Adrian Bunk <[EMAIL PROTECTED]> commit 9990b48a403fa465b4ff600cd8a7b5108d1bc135 Author: Hirokazu Takata <[EMAIL PROTECTED]> Date: Mon Aug 20 09:12:46 2007 +0900 m32r: Separate syscall table from entry.S - Separate sys_call_table from arch/m32r/kernel/entry.S and move it to arch/m32r/kernel/system_call.S. - Change sys_call_table section from .data to .rodata. Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]> commit de2232edb8d82aca938570eb6f136e2d70a26418 Author: Hirokazu Takata <[EMAIL PROTECTED]> Date: Sat Aug 18 00:10:18 2007 +0900 m32r: Cosmetic updates of arch/m32r/kernel/entry.S - Remove unused symbols *_MASK - Change indentation of comments, etc. Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]> commit abd0a782359717ded8f663bc5b8e5e9e3cc4f5e7 Author: Hirokazu Takata <[EMAIL PROTECTED]> Date: Fri Aug 17 23:40:37 2007 +0900 m32r: Exit ei_handler directly for no IRQ case or IPI operations If no IRQ request is found in the IRQ check of ei_handler, we can exit directly by jumping "restore_all", instead of via "ret_from_intr". This modification is also likely effective for IPI operations, because scheduler call never happen at the exit of IPIs. Signed-off-by: Hitoshi Yamamoto <[EMAIL PROTECTED]> Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]> commit 5171b100511513bc52875055f7d900fc3f7c922b Author: Hirokazu Takata <[EMAIL PROTECTED]> Date: Fri Aug 17 18:11:37 2007 +0900 m32r: Simplify ei_handler code Simplify and clean up messy ei_handler code in arch/m32r/kernel/entry.S. - Remove ifdef's for CONFIG_CHIP_* configulations. - Rearrange the M32700 workaround code. - Remove the messy platform-dependent interrupt check routines and consolidate them to common INT0/INT1/INT2 check routines for all platforms with cascaded interrupt controllers. Signed-off-by: Hitoshi Yamamoto <[EMAIL PROTECTED]> Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]> commit e070fb743d9d13d9757e633d1bdd1f9c20b2d792 Author: Hirokazu Takata <[EMAIL PROTECTED]> Date: Fri Aug 17 17:22:15 2007 +0900 m32r: Define symbols to unify platform-dependent ICU checks On some m32r platforms, cascaded ICUs are used. This patch is required to simplify ei_handler and consolidate platform- dependent ICU check routines. platform ICU/INT1 ICU/INT0 ICU/INT2 -- m32104uto - - m32700uto o o opsput o o o usrvo - - (others)- - - Signed-off-by: Hitoshi Yamamoto <[EMAIL
Re: ICH Intel PATA short cable override...
Alan Cox wrote: On Tue, 4 Sep 2007 13:37:22 +0100 "Daniel J Blueman" <[EMAIL PROTECTED]> wrote: We see that in ata_piix.c, there is a whitelist for (laptop) Intel ICH controllers with short cables, tied to specific vendor subsystem IDs. Since my mini-ITX Ibase MI910F has the subsystem IDs specified as Intel [1], this is unusable. I can't find another existing mechanism to add short cable information, to allow UDMA/66 for my on-board CF socket. DMI is the other approach (if your box has sane responses to the dmidecode command we can do this). No, something more flexible is needed here. For example, I have a Mini-ITX server here, which I personally have equipped with a 3" 40W IDE cable that connects to a notebook drive. The system currently uses UDMA just fine with the IDE drivers, but I have not been able to convert it to use the (stock) libata drivers because of this silly lack of end-user control. We really need an override for this -- embedded folks would also apprecaate one. Ditto for selecting transfer modes. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [AGPGART] intel_agp: fix stolen mem range on G33
On 2007.09.05 08:19:37 +, Randy Dunlap wrote:
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
Thanks Randy. Here's updated patch with typo and tab style
fixed. I misused x style.
Subject: [PATCH] [AGPGART] intel_agp: fix stolen mem range on G33
G33 GTT stolen memory is below graphics data
stolen memory and be seperate, so don't subtract
it in stolen mem counting.
Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
---
drivers/char/agp/intel-agp.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 2c9ca2c..581f922 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -506,6 +506,11 @@ static void intel_i830_init_gtt_entries(void)
break;
}
} else {
+ /* G33's GTT stolen memory is separate from gfx data
+* stolen memory.
+*/
+ if (IS_G33)
+ size = 0;
switch (gmch_ctrl & I830_GMCH_GMS_MASK) {
case I855_GMCH_GMS_STOLEN_1M:
gtt_entries = MB(1) - KB(size);
--
1.5.2.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] prevent kswapd from freeing excessive amounts of lowmem
> On Wed, 05 Sep 2007 19:01:25 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote: > The current VM can get itself into trouble fairly easily on systems > with a small ZONE_HIGHMEM, which is common on i686 computers with > 1GB of memory. > > On one side, page_alloc() will allocate down to zone->pages_low, > while on the other side, kswapd() and balance_pgdat() will try > to free memory from every zone, until every zone has more free > pages than zone->pages_high. > > Highmem can be filled up to zone->pages_low with page tables, > ramfs, vmalloc allocations and other unswappable things quite > easily and without many bad side effects, since we still have > a huge ZONE_NORMAL to do future allocations from. > > However, as long as the number of free pages in the highmem > zone is below zone->pages_high, kswapd will continue swapping > things out from ZONE_NORMAL, too! crap. I guess suitably-fashioned mlock could do the same thing. > Sami Farin managed to get his system into a stage where kswapd > had freed about 700MB of low memory and was still "going strong". > > The attached patch will make kswapd stop paging out data from > zones when there is more than enough memory free. hm. Did highmem's all_unreclaimable get set? If so perhaps we could use that in some way. > We do go above > zone->pages_high in order to keep pressure between zones equal > in normal circumstances, but the patch should prevent the kind > of excesses that made Sami's computer totally unusable. > > Please merge this into -mm. > > Signed-off-by: Rik van Riel <[EMAIL PROTECTED]> > > > [linux-2.6-excessive-pageout.patch text/x-patch (715B)] > --- linux-2.6.22.noarch/mm/vmscan.c.excessive 2007-09-05 12:19:49.0 > -0400 > +++ linux-2.6.22.noarch/mm/vmscan.c 2007-09-05 12:21:40.0 -0400 > @@ -1371,7 +1371,13 @@ loop_again: > temp_priority[i] = priority; > sc.nr_scanned = 0; > note_zone_scanning_priority(zone, priority); > - nr_reclaimed += shrink_zone(priority, zone, ); > + /* > + * We put equal pressure on every zone, unless one > + * zone has way too many pages free already. > + */ > + if (!zone_watermark_ok(zone, order, 8*zone->pages_high, > + end_zone, 0)) > + nr_reclaimed += shrink_zone(priority, zone, > ); > reclaim_state->reclaimed_slab = 0; > nr_slab = shrink_slab(sc.nr_scanned, GFP_KERNEL, > lru_pages); I guess for a very small upper zone and a very large lower zone this could still put the scan balancing out of whack, fixable by a smarter version of "8*zone->pages_high" but it doesn't seem very likely that this will affect things much. Why doesn't direct reclaim need similar treatment? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regressions w.r.t. suspend behaviour in recent kernel versions
> On Thu, 06 Sep 2007 00:51:50 +0200 Felix Homann <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > >> On Fri, 24 Aug 2007 14:42:55 +0200 Felix Homann <[EMAIL PROTECTED]> wrote: > > > > Nearly two weeks, zero replies. > > Thanks for caring :-) > > > > >> Aug 9 00:22:13 jawaka kernel: EXT3-fs: mounted filesystem with ordered > >> data mode. > >> Aug 9 00:22:13 jawaka kernel: WARNING: at kernel/irq/resend.c:70 > >> check_irq_resend() > > > > I expect that got fixed in later kernels. > > Yes, I've just tried 2.6.23-rc5-git1 and the warning has gone! > > > >> Without the nolapic option the kernel will panic when trying to suspend > >> to disk. > > > > A *large* number of people need noapic or nolapic to get Linux to work. > > Even better, on 2.6.23-rc5-git1 I don't need nolapic anymore! > damn, we break so much stuff that now we're breaking our old bugs too! > > >> Here are the last lines of the kernel output: > >> > >> EIP: [ lapic_nmi_suspend+0x1d/0x30 ss:ESP 0068:c1ae3ec8 > >> Kernel panic - not syncing: Attempted to kill init! > > > > Are you able to provide us with more information about this bug? > > If you're still interested in more more information now that the bug has > apparently been solved "en passant" I can take a photograph tomorrow. > Please, let me know. No thanks, let's just move on.. > >> With more recent kernels the system will hang with > >> "Suspending console(s)". > > > > My Vaio reliably hangs at the same place with 2.6.23-rc4. I'll bisect that > > next week sometime. Hopefully the result of that effort will fix your bug. > > Please test Linus's tree regularly and don't let us release 2.6.23 until > > it is fixed. > > Great! > > > >> 3. Even with the 2.6.18 kernel sound won't work after suspending to ram. > >> I don't know when this started, but I know that this has not been an > >> issue in the past. > > > > Please provide full details in a separate bug report. Send that report to > > myself, linux-kernel@vger.kernel.org, Jaroslav Kysela <[EMAIL PROTECTED]> > > and > > Takashi Iwai <[EMAIL PROTECTED]> > > I'll do that in the next couple of days. > Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Fix (improve) deadlock condition on module removal netfilter socket option removal
On Thu, 2007-09-06 at 08:41 +1000, Rusty Russell wrote:
> On Wed, 2007-09-05 at 16:26 -0400, Jon Masters wrote:
> > On Tue, 2007-09-04 at 16:30 -0400, Neil Horman wrote:
> >
> > > 2nd of two patches. This patch enhances modprobe to operate like rmmod
> > > in non-blocking mode. It also adds a -w option to allow for explicit
> > > blocking
> > > operation.
> >
> > As I suspected, this patch isn't in the tree. I am going to commit it
> > now because it makes sense. I'm also going to sort out moving things to
> > kernel.org this afternoon while I'm at it - I don't want to confuse
> > people with kerneltools.org any more now I've got a kernel.org acc.
>
> 1) You don't want to hand the "wait" flag (ie ~O_NONBLOCK) to
> sub-rmmods,
>
> 2) You need to do something about this code if wait is specified:
>
> if (usecount != 0) {
> if (!ignore_inuse)
> error("Module %s is in use.\n", name);
> goto remove_rest;
> }
Goodness, I suck. I'll get it fixed properly.
Jon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: tbench regression - Why process scheduler has impact on tbench and why small per-cpu slab (SLUB) cache creates the scenario?
On Wed, 2007-09-05 at 03:45 -0700, Christoph Lameter wrote: > On Wed, 5 Sep 2007, Zhang, Yanmin wrote: > > > > > However, the approach treats the slabs in the same policy. Could we > > > > implement a per-slab specific approach like direct b)? > > > > > > I am not sure what you mean by same policy. Same configuration for all > > > slabs? > > Yes. > > Ok. I could add the ability to specify parameters for some slabs. Thanks. That will be more flexible. > > > > Would it be possible to try the two other approaches that I suggested? I > > > think both of those may also solve the issue. Try booting with > > > slab_max_order=0 > > 1) I tried slab_max_order=0 and the regression becomes 12.5%. It's still > > not good. > > > > 2) I apllied patch > > slub-direct-pass-through-of-page-size-or-higher-kmalloc.patch to kernel > > 2.6.23-rc4. The new testing result is much better, only 1% less than > > 2.6.22. I retested 2.6.22 and booted kernel with "slub_max_order=3 slub_min_objects=8". The result is about 8.7% better than without booting parameters. So all with booting parameter "slub_max_order=3 slub_min_objects=8", 2.6.22 is about 5.8% better than 2.6.23-rc4. I suspect process scheduler is responsible for the 5.8% regressions. > > Ok. That seems to indicate that we should improve the alloc path in the > page allocator. The page allocator performance needs to be competitive on > page sized allocations. The problem will be largely going away when we > merge the pass through patch in 2.6.24. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI: Unable to reserve mem region problem
On Wed, 05 Sep 2007 10:32:38 -0400 "Karl Bellve" <[EMAIL PROTECTED]> wrote: > > Please CC any response. Thanks. > > I am having an issue with a Supermicro h8dce motherboard and failure to > recognize a 5th SATA drive after upgrading to Fedora 7. Can you send me an lspci -vvxxx so that I can look into this. Might be a few days with the kernel summit but it should give a clue and may be linked to ADMA mode - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ICH Intel PATA short cable override...
On Tue, 4 Sep 2007 13:37:22 +0100 "Daniel J Blueman" <[EMAIL PROTECTED]> wrote: > We see that in ata_piix.c, there is a whitelist for (laptop) Intel ICH > controllers with short cables, tied to specific vendor subsystem IDs. > Since my mini-ITX Ibase MI910F has the subsystem IDs specified as > Intel [1], this is unusable. > > I can't find another existing mechanism to add short cable > information, to allow UDMA/66 for my on-board CF socket. DMI is the other approach (if your box has sane responses to the dmidecode command we can do this). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] pata_it821x: fix lost interrupt with atapi devices
/from the media. */ > > + if (qc->nbytes < 2048) > > + return -EOPNOTSUPP; > > + > >/* No ATAPI DMA in smart mode */ > >if (itdev->smart) > >return -EOPNOTSUPP; > > > > This looks like a gross hack. Aren't you supposed to inspect > the command instead and whitelist the ones you know are OK, > like pata_pdc2027x.c and sata_promise.c do? It does seem to be about transfer size in the IT821x case not commands. It may be to do with how we issue ATAPI command transfer sizes from high up (patch went to Jeff) but for now this is definitely the right approach Reviewed-by: Alan Cox <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Fix (improve) deadlock condition on module removal netfilter socket option removal
On Wed, Sep 05, 2007 at 05:39:11PM -0400, Jon Masters wrote: > On Wed, 2007-09-05 at 15:27 -0400, Neil Horman wrote: > > > Now, I suppose its possible that I've not been looking at the right source > > tree > > when doing my work. I've based my modprobe patch on this git tree: > > http://git.kernel.org/?p=linux/kernel/git/kyle/module-init-tools.git;a=summary > > If theres a newer one, if you could please point it out to me, I'd > > appreciate > > it. If the functional equivalent of my second patch is already in there, > > then > > we just need my first patch to be good to go. > > Neil, please test: > > http://www.kernel.org/pub/linux/kernel/people/jcm/module-init-tools/module-init-tools-3.3-pre12.tar.bz2 > > Jon. > I'll test it first thing in the AM. Thanks! Neil -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Fix preemptible lazy mode bug
On Thu, 2007-09-06 at 06:37 +1000, Rusty Russell wrote: > On Thu, 2007-08-23 at 22:46 -0700, Zachary Amsden wrote: > > I recently sent off a fix for lazy vmalloc faults which can happen under > > paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a > > bit on fixing this. I neglected to notice that since the new call to > > flush the MMU update queue is called from the page fault handler, it can > > be pre-empted. Both VMI and Xen use per-cpu variables to track lazy > > mode state, as all previous calls to set, disable, or flush lazy mode > > happened from a non-preemptable state. > > Hi Zach, > > I don't think this patch does anything. The flush is because we want > the just-completed "set_pte" to have immediate effect, so if preempt is > enabled we're already screwed because we can be moved between set_pte > and the arch_flush_lazy_mmu_mode() call. > > Now, where's the problem caller? By my reading or rc4, vmalloc faults > are fixed up before enabling interrupts. I agree. The patch is a nop. I just got overly paranoid. The whole thing is just very prone to bugs. So let's go over it carefully: 1) Lazy mode can't be entered unless preempt is disabled 2) Flushes are needed in two known cases: kmap_atomic and vmalloc sync 3) kmap_atomic can only be used when preempt is disabled 4) vmalloc sync happens under protection of interrupts disabled Good logically. What can break this logic? #1 is defined by us #2 is our currently believed complete list of flush scenarios #3 is impossible to change by design #4 seems very unlikely to change anytime soon Seeing #2 appears weak, let us elaborate: A) Lazy mode is used in a couple of controlled paths for user page table updates which requires no immediately updated mapping; further, they are protected under spinlocks, thus never preempted B) Thus only kernel mapping updates require explicit flushes C) Any interrupt / fault during lazy mode can only use kmap_atomic or a set_pmd to sync a vmalloc region, thus proving my point by circular logic (for interrupt / fault cases). D) Or better, other kernel mapping changes (kmap, the pageattr code, boot_ioremap, vmap, vm86 mark_screen_rdonly) are not usable by interrupt / fault handlers, thus proving C by exclusion. So I'm fairly certain there is no further issues with interrupt handlers or faults, where update semantics are heavily constrained. What of the actual lazy mode code itself doing kernel remapping? Most of these are clearly bogus (pageattr, boot_ioremap, vm86 stuff) for the mm code to use inside a spinlock protected lazy mode region; it does seem perfectly acceptable though for the mm code to use kmap or vmap (not kmap_atomic) internally somewhere in the pagetable code. We can exclude the trivial lazy mode regions (zeromap, unmap, and remap). Easily by inspection. The PTE copy routine gets deep enough that not all paths are immediately obvious, though, we should keep it in mind for bug checking. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Revised timerfd() interface
On Thu, 6 Sep 2007, Michael Kerrisk wrote:
> Hi Davide,
>
> > > > > > > As I think about this more, I see more problems with
> > > > > > > your argument. timerfd needs the ability to get and
> > > > > > > get-while-setting just as much as the earlier APIs.
> > > > > > > Consider a library that creates a timerfd file descriptor that
> > > > > > > is handed off to an application: that library may want
> > > > > > > to modify the timer settings without having to create a
> > > > > > > new file descriptor (the app mey not be able to be told about
> > > > > > > the new fd). Your argument just doesn't hold, AFAICS.
> > > > > >
> > > > > > Such hypotethical library, in case it really wanted to offer such
> > > > > > functionality, could simply return an handle instead of the raw
> > > > > > fd, and take care of all that stuff in userspace.
> > > > >
> > > > > Did I miss something? Is it not the case that as soon as the
> > > > > library returns a handle, rather than an fd, then the whole
> > > > > advantage of timerfd() (being able to select/poll/epoll on
> > > > > the timer as well as other fds) is lost?
> > > >
> > > > Why? The handle would simply be a little struct where the timerfd fd
> > > > is
> > > > stored, and a XXX_getfd() would return it.
> > > > So my point is, I doubt such functionalities are really needed, and I
> > > > also argue that the kernel is the best place for such wrapper code
> > > > to go.
> > >
> > > So what happens if one thread (via the library) wants modify
> > > a timer's settings at the same timer as another thread is
> > > select()ing on it? The first thread can't do this by creating
> > > a new timerfd timer, since it wants to affect the select()
> > > in the other thread?
> >
> > It can be done w/out any problems. The select thread will be notified
> > whenever the new timer setting expires.
>
> We are going in circles here. I think you are missing my point.
> Consider the following
>
> [[
> Thread A: calls library function which creates a timerfd file
> descriptor.
>
> Thread B: calls select() on the timerfd file descriptor.
>
> Thread A: calls library function which wants to:
>a) modify timer settings, and retrieve copy of current timer
> settings, and later
>b) restore old timer settings.
> ]]
>
> This seems a quite reasonable use-case to me, and the existing
> interface simply can't support it.
"Quite reasonable"? :)
I honestly doubt it, but anyway. Modulo error checking:
struct tfd {
int fd, clockid;
struct itimerspec ts;
};
struct tfd *tfd_create(int clockid, int flags, const struct itimerspec *ts) {
struct tfd *th;
th = malloc(sizeof(*th));
th->clockid = clockid;
th->ts = *ts;
th->fd = timerfd(-1, clockid, flags, ts);
return th;
}
void tfd_close(struct tfd *th) {
close(th->fd);
free(th);
}
int tfd_getfd(const struct tfd *th) {
return th->fd;
}
int tfd_gettime(const struct tfd *th, int *clockid, struct itimerspec *ts) {
*clockid = th->clockid;
*ts = th->ts;
return 0;
}
int tfd_settime(struct tfd *th, int clockid, int flags,
const struct itimerspec *ts) {
th->fd = timerfd(th->fd, clockid, flags, ts);
th->clockid = clockid;
th->ts = *ts;
return 0;
}
Wrap the get/set with a mutex in case you plan to shoot yourself in a foot
by doing get/set from multiple threads ;)
So, once again:
- I sincerly doubt the above is common usage/design patters for timerfds
* timerfds are not a common global resource, ala signals, that requires
get+set+restore pattern - you can have many of them set to different
times
- Those IMO *very* special use cases can be handled in userspace with few
lines of code, *if* really needed
- 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/
use of asm/prom.h
Hi all,
I noticed in the ALSA tree:
-- sound/sparc/dbri.c --
index 12d11fc..e96023f 100644
@@ -66,6 +66,7 @@
#include
#include
+#include
#include
#include
(I don't mean to pick on this particular example, it is just what was in
front of me.)
Could people please consider using linux/{of,of_device,of_platform}.h
instead of asm/prom.h now that these exist. Using asm/prom.h only works
now because it includes the above files, but that may (will?) change
eventually.
Most includes of asm/prom.h are there to get access to the routines and
data structures associated with the Open Firmware device tree, and these
are now all available from the above files instead.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgprN6GWeqXW0.pgp
Description: PGP signature
NetApp sues Sun regarding ZFS
Folks, The official announcement. http://www.netapp.com/news/press/news_rel_20070905 Dave Hitz's blog about it. http://blogs.netapp.com/dave/ bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Why do so many machines need "noapic"?
Some systems lock up without the noapic option. I found one that will freeze while trying to set up the timer interrupt. Passing 'nolapic' makes it freeze just after: Setting up timer through ExtINT... works Sometimes it will boot up and then freeze during the startup scripts. Passing the noapic option fixes all that, but it then gets 1000 spurious interrupts per second on IRQ7 (which only shows ehci using it.) Kernel version is 2.6.22. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel crashes inside MV643xx driver
On Wed, 5 Sep 2007, Dale Farnsworth wrote: > On Wed, Sep 05, 2007 at 08:24:52AM -0700, Andrew Morton wrote: > > > On Mon, 20 Aug 2007 14:38:57 +0800 gshan <[EMAIL PROTECTED]> wrote: > > > Hi All, > > > > > > After I started the NFS server, it crashed: > > > > > > <3>Badness in local_bh_enable at > > > /home/cli4/sandbox/main/TelicaRoot/components/mvlinux/cge/devkit/lsp/7xx/linux/kernel/softirq.c:195 > > > Badness in local_bh_enable at > > > /home/cli4/sandbox/main/TelicaRoot/components/mvlinux/cge/devkit/lsp/7xx/linux/kernel/softirq.c:195 > > > Call trace: > > > [c0005340] check_bug_trap+0xbc/0x11c > > > [c0005604] ProgramCheckException+0x264/0x2bc > > > [c0004ac4] ret_from_except_full+0x0/0x4c > > > [c0022ae4] local_bh_enable+0x18/0x80 > > > [c024648c] skb_copy_bits+0x168/0x3b8 > > > [c024db44] __skb_linearize+0x90/0x150 > > > [c020e8a4] mv643xx_eth_start_xmit+0x4c0/0x5bc > > > [c025c934] qdisc_restart+0xac/0x2bc > > > [c024de9c] dev_queue_xmit+0x298/0x34c > > > [c0269814] ip_finish_output+0x140/0x2b8 > > > [c026a3ac] ip_fragment+0x3cc/0x6e0 > > > [c026bac8] ip_push_pending_frames+0x3dc/0x46c > > > [c0289ec4] udp_push_pending_frames+0x10c/0x1cc > > > [c028a7c4] udp_sendpage+0x104/0x188 > > > [c0292fc8] inet_sendpage+0x90/0xb8 > > > > > > I searched the webs and found the similar problems: > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg05199.html > > > http://oss.sgi.com/archives/netdev/2005-09/msg00025.html > > > > > > Who knew there are fixes for the problem? > > > > Well that got a tremendous response, didn't it? I thought of replying to this post when I saw it couple weeks back, but didn't because (1) that's an ancient kernel and (2) the first link that was mentioned up there in the original post itself pointed to a patch to solve it (which I verified was since applied to mainline too). > > What do you mean by "crashed"? The above is a warning and the system > > should have survived. > > > > Which kernel version is being used? > > That is the key question. From the pathnames, I suspect that gshan is > using a MontaVista version. I'm still (especially) interested, since > MontaVista pays me. > > BTW, I never received the original message on netdev or linux-kernel. > Hmm. Thanks to Andrew for replying. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stardom SATA HSM violation
Andrew Morton wrote: .. Hey, we just found something which doesn't crash my Vaio! sony:/home/akpm/hdparm-7.7> 0 ./hdparm --drq-hsm-error /dev/sda /dev/sda: triggering "stuck DRQ" host state machine error do_drq_hsm_error: Success ata status=0x58 ata error=0x00 ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata3.00: cmd ec/00:00:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0 res 58/00:01:00:00:00/00:00:00:00:00/40 Emask 0x2 (HSM violation) ata3: soft resetting port ata3.00: configured for UDMA/100 ata3: EH complete sd 2:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB) sd 2:0:0:0: [sda] Write Protect is off sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA How dull. (ata_piix) :) On my two very similar notebooks, it crashes libata when a PATA drive is used behind a Marvell converter chip, but not when a SATA drive is used directly. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] prevent kswapd from freeing excessive amounts of lowmem
The current VM can get itself into trouble fairly easily on systems with a small ZONE_HIGHMEM, which is common on i686 computers with 1GB of memory. On one side, page_alloc() will allocate down to zone->pages_low, while on the other side, kswapd() and balance_pgdat() will try to free memory from every zone, until every zone has more free pages than zone->pages_high. Highmem can be filled up to zone->pages_low with page tables, ramfs, vmalloc allocations and other unswappable things quite easily and without many bad side effects, since we still have a huge ZONE_NORMAL to do future allocations from. However, as long as the number of free pages in the highmem zone is below zone->pages_high, kswapd will continue swapping things out from ZONE_NORMAL, too! Sami Farin managed to get his system into a stage where kswapd had freed about 700MB of low memory and was still "going strong". The attached patch will make kswapd stop paging out data from zones when there is more than enough memory free. We do go above zone->pages_high in order to keep pressure between zones equal in normal circumstances, but the patch should prevent the kind of excesses that made Sami's computer totally unusable. Please merge this into -mm. Signed-off-by: Rik van Riel <[EMAIL PROTECTED]> --- linux-2.6.22.noarch/mm/vmscan.c.excessive 2007-09-05 12:19:49.0 -0400 +++ linux-2.6.22.noarch/mm/vmscan.c 2007-09-05 12:21:40.0 -0400 @@ -1371,7 +1371,13 @@ loop_again: temp_priority[i] = priority; sc.nr_scanned = 0; note_zone_scanning_priority(zone, priority); - nr_reclaimed += shrink_zone(priority, zone, ); + /* + * We put equal pressure on every zone, unless one + * zone has way too many pages free already. + */ + if (!zone_watermark_ok(zone, order, 8*zone->pages_high, + end_zone, 0)) +nr_reclaimed += shrink_zone(priority, zone, ); reclaim_state->reclaimed_slab = 0; nr_slab = shrink_slab(sc.nr_scanned, GFP_KERNEL, lru_pages);
[PATCH 5/7 RESEND] cxgb3 - CQ context operations time out too soon.
From: Divy Le Ray <[EMAIL PROTECTED]>
Currently, the driver only tries up to 5 times (5us) to get the results
of a CQ context operation. Testing has shown the chip can take as much
as 50us to return the response on SG_CONTEXT_CMD operations. So we up
the retry count to 100 to cover high loads.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/t3_hw.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index bff1d02..0583293 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -1870,6 +1870,8 @@ void t3_port_intr_clear(struct adapter *adapter, int idx)
phy->ops->intr_clear(phy);
}
+#define SG_CONTEXT_CMD_ATTEMPTS 100
+
/**
* t3_sge_write_context - write an SGE context
* @adapter: the adapter
@@ -1889,7 +1891,7 @@ static int t3_sge_write_context(struct adapter *adapter,
unsigned int id,
t3_write_reg(adapter, A_SG_CONTEXT_CMD,
V_CONTEXT_CMD_OPCODE(1) | type | V_CONTEXT(id));
return t3_wait_op_done(adapter, A_SG_CONTEXT_CMD, F_CONTEXT_CMD_BUSY,
- 0, 5, 1);
+ 0, SG_CONTEXT_CMD_ATTEMPTS, 1);
}
/**
@@ -2075,7 +2077,7 @@ int t3_sge_enable_ecntxt(struct adapter *adapter,
unsigned int id, int enable)
t3_write_reg(adapter, A_SG_CONTEXT_CMD,
V_CONTEXT_CMD_OPCODE(1) | F_EGRESS | V_CONTEXT(id));
return t3_wait_op_done(adapter, A_SG_CONTEXT_CMD, F_CONTEXT_CMD_BUSY,
- 0, 5, 1);
+ 0, SG_CONTEXT_CMD_ATTEMPTS, 1);
}
/**
@@ -2099,7 +2101,7 @@ int t3_sge_disable_fl(struct adapter *adapter, unsigned
int id)
t3_write_reg(adapter, A_SG_CONTEXT_CMD,
V_CONTEXT_CMD_OPCODE(1) | F_FREELIST | V_CONTEXT(id));
return t3_wait_op_done(adapter, A_SG_CONTEXT_CMD, F_CONTEXT_CMD_BUSY,
- 0, 5, 1);
+ 0, SG_CONTEXT_CMD_ATTEMPTS, 1);
}
/**
@@ -2123,7 +2125,7 @@ int t3_sge_disable_rspcntxt(struct adapter *adapter,
unsigned int id)
t3_write_reg(adapter, A_SG_CONTEXT_CMD,
V_CONTEXT_CMD_OPCODE(1) | F_RESPONSEQ | V_CONTEXT(id));
return t3_wait_op_done(adapter, A_SG_CONTEXT_CMD, F_CONTEXT_CMD_BUSY,
- 0, 5, 1);
+ 0, SG_CONTEXT_CMD_ATTEMPTS, 1);
}
/**
@@ -2147,7 +2149,7 @@ int t3_sge_disable_cqcntxt(struct adapter *adapter,
unsigned int id)
t3_write_reg(adapter, A_SG_CONTEXT_CMD,
V_CONTEXT_CMD_OPCODE(1) | F_CQ | V_CONTEXT(id));
return t3_wait_op_done(adapter, A_SG_CONTEXT_CMD, F_CONTEXT_CMD_BUSY,
- 0, 5, 1);
+ 0, SG_CONTEXT_CMD_ATTEMPTS, 1);
}
/**
@@ -2172,7 +2174,7 @@ int t3_sge_cqcntxt_op(struct adapter *adapter, unsigned
int id, unsigned int op,
t3_write_reg(adapter, A_SG_CONTEXT_CMD, V_CONTEXT_CMD_OPCODE(op) |
V_CONTEXT(id) | F_CQ);
if (t3_wait_op_done_val(adapter, A_SG_CONTEXT_CMD, F_CONTEXT_CMD_BUSY,
- 0, 5, 1, ))
+ 0, SG_CONTEXT_CMD_ATTEMPTS, 1, ))
return -EIO;
if (op >= 2 && op < 7) {
@@ -2182,7 +2184,8 @@ int t3_sge_cqcntxt_op(struct adapter *adapter, unsigned
int id, unsigned int op,
t3_write_reg(adapter, A_SG_CONTEXT_CMD,
V_CONTEXT_CMD_OPCODE(0) | F_CQ | V_CONTEXT(id));
if (t3_wait_op_done(adapter, A_SG_CONTEXT_CMD,
- F_CONTEXT_CMD_BUSY, 0, 5, 1))
+ F_CONTEXT_CMD_BUSY, 0,
+ SG_CONTEXT_CMD_ATTEMPTS, 1))
return -EIO;
return G_CQ_INDEX(t3_read_reg(adapter, A_SG_CONTEXT_DATA0));
}
@@ -2208,7 +2211,7 @@ static int t3_sge_read_context(unsigned int type, struct
adapter *adapter,
t3_write_reg(adapter, A_SG_CONTEXT_CMD,
V_CONTEXT_CMD_OPCODE(0) | type | V_CONTEXT(id));
if (t3_wait_op_done(adapter, A_SG_CONTEXT_CMD, F_CONTEXT_CMD_BUSY, 0,
- 5, 1))
+ SG_CONTEXT_CMD_ATTEMPTS, 1))
return -EIO;
data[0] = t3_read_reg(adapter, A_SG_CONTEXT_DATA0);
data[1] = t3_read_reg(adapter, A_SG_CONTEXT_DATA1);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sk98lin for 2.6.23-rc1
On Wed, 05 Sep 2007 17:04:59 -0400 Kyle Rose <[EMAIL PROTECTED]> wrote: > > > However, it really DOES lock up under load. I even > > tried 2.6.23-rc4 and the absolute latest version of > > the > > driver and it still locks up, as in > > > Yich. I'm glad I'm still using sk98lin on my unmanned colo box. > > Kyle > Great for you, when I was testing sk98lin crashed my machine on overnight stress run. My intuition is that there is a bug in sk98lin on Yukon EC-U chips (those without ram buffer) and a hardware problem on Yukon XL chips (those with ram buffer) and the sky2 driver doesn't have workaround for getting the ram buffer stuck (yet). I don't like putting workarounds in for problems I can't reproduce. After KS, I'll rerun more stress tests on all the chip flavors and see if the hang is reproducible. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 7/7] cxgb3 - Update engine microcode version
From: Divy Le Ray <[EMAIL PROTECTED]>
The new microcode engine version is set to 1.1.0
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index d3f276c..3e5b0db 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -127,8 +127,8 @@ enum { /* adapter
interrupt-maintained statistics */
enum {
TP_VERSION_MAJOR= 1,
- TP_VERSION_MINOR= 0,
- TP_VERSION_MICRO= 44
+ TP_VERSION_MINOR= 1,
+ TP_VERSION_MICRO= 0
};
#define S_TP_VERSION_MAJOR 16
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7 RESEND] cxgb3 - Set the CQ_ERR bit in CQ contexts.
From: Divy Le Ray <[EMAIL PROTECTED]> The cxgb3 driver is incorrectly configuring the HW CQ context for CQ's that use overflow-avoidance. Namely the RDMA control CQ. This results in a bad DMA from the device to bus address 0. The solution is to set the CQ_ERR bit in the context for these types of CQs. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/sge_defs.h |4 drivers/net/cxgb3/t3_hw.c|3 ++- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/net/cxgb3/sge_defs.h b/drivers/net/cxgb3/sge_defs.h index 514869e..29b6c80 100644 --- a/drivers/net/cxgb3/sge_defs.h +++ b/drivers/net/cxgb3/sge_defs.h @@ -106,6 +106,10 @@ #define V_CQ_GEN(x) ((x) << S_CQ_GEN) #define F_CQ_GENV_CQ_GEN(1U) +#define S_CQ_ERR30 +#define V_CQ_ERR(x) ((x) << S_CQ_ERR) +#define F_CQ_ERRV_CQ_ERR(1U) + #define S_CQ_OVERFLOW_MODE31 #define V_CQ_OVERFLOW_MODE(x) ((x) << S_CQ_OVERFLOW_MODE) #define F_CQ_OVERFLOW_MODEV_CQ_OVERFLOW_MODE(1U) diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c index cdcfc13..bff1d02 100644 --- a/drivers/net/cxgb3/t3_hw.c +++ b/drivers/net/cxgb3/t3_hw.c @@ -2046,7 +2046,8 @@ int t3_sge_init_cqcntxt(struct adapter *adapter, unsigned int id, u64 base_addr, base_addr >>= 32; t3_write_reg(adapter, A_SG_CONTEXT_DATA2, V_CQ_BASE_HI((u32) base_addr) | V_CQ_RSPQ(rspq) | -V_CQ_GEN(1) | V_CQ_OVERFLOW_MODE(ovfl_mode)); +V_CQ_GEN(1) | V_CQ_OVERFLOW_MODE(ovfl_mode) | +V_CQ_ERR(ovfl_mode)); t3_write_reg(adapter, A_SG_CONTEXT_DATA3, V_CQ_CREDITS(credits) | V_CQ_CREDIT_THRES(credit_thres)); return t3_sge_write_context(adapter, id, F_CQ); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] cxgb3 - Add T3C rev
From: Divy Le Ray <[EMAIL PROTECTED]>
add driver recognition for T3C rev board.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |1 +
drivers/net/cxgb3/cxgb3_main.c |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index 7e9e43d..d3f276c 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -438,6 +438,7 @@ enum { /* chip
revisions */
T3_REV_A = 0,
T3_REV_B = 2,
T3_REV_B2 = 3,
+ T3_REV_C = 4,
};
struct trace_params {
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index ae9c213..9d360eb 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -768,6 +768,9 @@ static inline char t3rev2char(struct adapter *adapter)
case T3_REV_B2:
rev = 'b';
break;
+ case T3_REV_C:
+ rev = 'c';
+ break;
}
return rev;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/7 RESEND] cxgb3 - remove false positive in xgmac workaround
From: Divy Le Ray <[EMAIL PROTECTED]>
Qualify toggling of xgmac tx enable with not getting pause frames,
we might not make forward progress because the peer is sending
lots of pause frames.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |1 +
drivers/net/cxgb3/xgmac.c |4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index ada5e4b..7e9e43d 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -513,6 +513,7 @@ struct cmac {
u64 rx_mcnt;
unsigned int toggle_cnt;
unsigned int txen;
+ u64 rx_pause;
struct mac_stats stats;
};
diff --git a/drivers/net/cxgb3/xgmac.c b/drivers/net/cxgb3/xgmac.c
index 1d1c391..ff9e9dc 100644
--- a/drivers/net/cxgb3/xgmac.c
+++ b/drivers/net/cxgb3/xgmac.c
@@ -452,6 +452,7 @@ int t3_mac_enable(struct cmac *mac, int which)
A_XGM_TX_SPI4_SOP_EOP_CNT +
oft)));
mac->rx_mcnt = s->rx_frames;
+ mac->rx_pause = s->rx_pause;
mac->rx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
A_XGM_RX_SPI4_SOP_EOP_CNT +
oft)));
@@ -504,7 +505,7 @@ int t3b2_mac_watchdog_task(struct cmac *mac)
tx_xcnt = 1;/* By default tx_xcnt is making progress */
tx_tcnt = mac->tx_tcnt; /* If tx_mcnt is progressing ignore tx_tcnt */
rx_xcnt = 1;/* By default rx_xcnt is making progress */
- if (tx_mcnt == mac->tx_mcnt) {
+ if (tx_mcnt == mac->tx_mcnt && mac->rx_pause == s->rx_pause) {
tx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
A_XGM_TX_SPI4_SOP_EOP_CNT +
mac->offset)));
@@ -560,6 +561,7 @@ out:
mac->tx_mcnt = s->tx_frames;
mac->rx_xcnt = rx_xcnt;
mac->rx_mcnt = s->rx_frames;
+ mac->rx_pause = s->rx_pause;
if (status == 1) {
t3_write_reg(adap, A_XGM_TX_CTRL + mac->offset, 0);
t3_read_reg(adap, A_XGM_TX_CTRL + mac->offset); /* flush */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/7 RESEND] cxgb3 - log and clear PEX errors
From: Divy Le Ray <[EMAIL PROTECTED]>
Clear pciE PEX errors late at module load time.
Log details when PEX errors occur.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/t3_hw.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 2b49b96..cdcfc13 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -1358,6 +1358,10 @@ static void pcie_intr_handler(struct adapter *adapter)
{0}
};
+ if (t3_read_reg(adapter, A_PCIE_INT_CAUSE) & F_PEXERR)
+ CH_ALERT(adapter, "PEX error code 0x%x\n",
+t3_read_reg(adapter, A_PCIE_PEX_ERR));
+
if (t3_handle_intr_status(adapter, A_PCIE_INT_CAUSE, PCIE_INTR_MASK,
pcie_intr_info, adapter->irq_stats))
t3_fatal_err(adapter);
@@ -1809,6 +1813,8 @@ void t3_intr_clear(struct adapter *adapter)
for (i = 0; i < ARRAY_SIZE(cause_reg_addr); ++i)
t3_write_reg(adapter, cause_reg_addr[i], 0x);
+ if (is_pcie(adapter))
+ t3_write_reg(adapter, A_PCIE_PEX_ERR, 0x);
t3_write_reg(adapter, A_PL_INT_CAUSE0, 0x);
t3_read_reg(adapter, A_PL_INT_CAUSE0); /* flush */
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/7 RESEND] cxgb3 - Firmware update
From: Divy Le Ray <[EMAIL PROTECTED]>
Update firmware version.
Allow the driver to be up and running with older FW image
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |2 +-
drivers/net/cxgb3/cxgb3_main.c |9 +
drivers/net/cxgb3/t3_hw.c | 20 +++-
drivers/net/cxgb3/version.h|2 +-
4 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index 510e93f..ada5e4b 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -690,7 +690,7 @@ int t3_read_flash(struct adapter *adapter, unsigned int
addr,
unsigned int nwords, u32 *data, int byte_oriented);
int t3_load_fw(struct adapter *adapter, const u8 * fw_data, unsigned int size);
int t3_get_fw_version(struct adapter *adapter, u32 *vers);
-int t3_check_fw_version(struct adapter *adapter);
+int t3_check_fw_version(struct adapter *adapter, int *must_load);
int t3_init_hw(struct adapter *adapter, u32 fw_params);
void mac_prep(struct cmac *mac, struct adapter *adapter, int index);
void early_hw_init(struct adapter *adapter, const struct adapter_info *ai);
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index eabb841..ae9c213 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -832,11 +832,12 @@ static int cxgb_up(struct adapter *adap)
int must_load;
if (!(adap->flags & FULL_INIT_DONE)) {
- err = t3_check_fw_version(adap);
- if (err == -EINVAL)
+ err = t3_check_fw_version(adap, _load);
+ if (err == -EINVAL) {
err = upgrade_fw(adap);
- if (err)
- goto out;
+ if (err && must_load)
+ goto out;
+ }
err = t3_check_tpsram_version(adap, _load);
if (err == -EINVAL) {
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index e958bbe..2b49b96 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -960,16 +960,18 @@ int t3_get_fw_version(struct adapter *adapter, u32 *vers)
/**
* t3_check_fw_version - check if the FW is compatible with this driver
* @adapter: the adapter
- *
+ * @must_load: set to 1 if loading a new FW image is required
+
* Checks if an adapter's FW is compatible with the driver. Returns 0
* if the versions are compatible, a negative error otherwise.
*/
-int t3_check_fw_version(struct adapter *adapter)
+int t3_check_fw_version(struct adapter *adapter, int *must_load)
{
int ret;
u32 vers;
unsigned int type, major, minor;
+ *must_load = 1;
ret = t3_get_fw_version(adapter, );
if (ret)
return ret;
@@ -982,9 +984,17 @@ int t3_check_fw_version(struct adapter *adapter)
minor == FW_VERSION_MINOR)
return 0;
- CH_ERR(adapter, "found wrong FW version(%u.%u), "
- "driver needs version %u.%u\n", major, minor,
- FW_VERSION_MAJOR, FW_VERSION_MINOR);
+ if (major != FW_VERSION_MAJOR)
+ CH_ERR(adapter, "found wrong FW version(%u.%u), "
+ "driver needs version %u.%u\n", major, minor,
+ FW_VERSION_MAJOR, FW_VERSION_MINOR);
+ else {
+ *must_load = 0;
+ CH_WARN(adapter, "found wrong FW minor version(%u.%u), "
+ "driver compiled for version %u.%u\n", major, minor,
+ FW_VERSION_MAJOR, FW_VERSION_MINOR);
+ }
+
return -EINVAL;
}
diff --git a/drivers/net/cxgb3/version.h b/drivers/net/cxgb3/version.h
index eb508bf..ef1c633 100644
--- a/drivers/net/cxgb3/version.h
+++ b/drivers/net/cxgb3/version.h
@@ -39,6 +39,6 @@
/* Firmware version */
#define FW_VERSION_MAJOR 4
-#define FW_VERSION_MINOR 3
+#define FW_VERSION_MINOR 6
#define FW_VERSION_MICRO 0
#endif /* __CHELSIO_VERSION_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 9/11] cxgb3 - engine microcode update
> > I think 9-14 still need to be incorporated. I don't see them in your > upstream branch, and they aren't in linus' tree either. I am not the blocker here. Sorry for the delay - again. I'm resubmitting these patches against net#upstream. Cheers, Divy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regressions w.r.t. suspend behaviour in recent kernel versions
Andrew Morton wrote: On Fri, 24 Aug 2007 14:42:55 +0200 Felix Homann <[EMAIL PROTECTED]> wrote: Nearly two weeks, zero replies. Thanks for caring :-) Aug 9 00:22:13 jawaka kernel: EXT3-fs: mounted filesystem with ordered data mode. Aug 9 00:22:13 jawaka kernel: WARNING: at kernel/irq/resend.c:70 check_irq_resend() I expect that got fixed in later kernels. Yes, I've just tried 2.6.23-rc5-git1 and the warning has gone! Without the nolapic option the kernel will panic when trying to suspend to disk. A *large* number of people need noapic or nolapic to get Linux to work. Even better, on 2.6.23-rc5-git1 I don't need nolapic anymore! Here are the last lines of the kernel output: EIP: [ lapic_nmi_suspend+0x1d/0x30 ss:ESP 0068:c1ae3ec8 Kernel panic - not syncing: Attempted to kill init! Are you able to provide us with more information about this bug? If you're still interested in more more information now that the bug has apparently been solved "en passant" I can take a photograph tomorrow. Please, let me know. With more recent kernels the system will hang with "Suspending console(s)". My Vaio reliably hangs at the same place with 2.6.23-rc4. I'll bisect that next week sometime. Hopefully the result of that effort will fix your bug. Please test Linus's tree regularly and don't let us release 2.6.23 until it is fixed. Great! 3. Even with the 2.6.18 kernel sound won't work after suspending to ram. I don't know when this started, but I know that this has not been an issue in the past. Please provide full details in a separate bug report. Send that report to myself, linux-kernel@vger.kernel.org, Jaroslav Kysela <[EMAIL PROTECTED]> and Takashi Iwai <[EMAIL PROTECTED]> I'll do that in the next couple of days. Thanks again, Felix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fast path efficiency (Re: [rfc][patch] dynamic data structure switching)
* Sun, 2 Sep 2007 20:36:19 +0200
>
I see, that in many places all pre-checks are done in negative form
with resulting return or jump out. In this case, if function was called,
what likely() path is?
> +static void resize_pid_hash(void)
> +{
> + unsigned int old_shift, new_shift;
> +
> + if (system_state != SYSTEM_RUNNING)
> + return;
> +
> + old_shift = cur_pid_hash->shift;
> + new_shift = ilog2(nr_pids * 2 - 1);
> + if (new_shift == old_shift)
> + return;
> +
> + if (!mutex_trylock(_pidhash.resize_mutex))
> + return;
that one or this?
==
if (system_state == SYSTEM_RUNNING) {
old_shift = cur_pid_hash->shift;
new_shift = ilog2(nr_pids * 2 - 1);
if (new_shift != old_shift &&
mutex_trylock(_pidhash.resize_mutex)) {
==
> + old_shift = cur_pid_hash->shift;
> + new_shift = ilog2(nr_pids * 2 - 1);
/* hope this repetition is needed by design */
...
> + mutex_unlock(_pidhash.resize_mutex);
}
What is more efficient in general sense,
as opposed to s,3,2,1,0 Optimized?
> + if (new_shift != old_shift) {
> + struct pid_hash *ph, *ret;
> + unsigned int idx = ph_cur_idx ^ 1;
> + ph = _hashes[idx];
> + if (!init_pid_hash(ph, new_shift)) {
> + ph_cur_idx = idx;
> +
> + ret = dyn_data_replace(_pidhash, dd_transfer_pids,
> ph);
> + BUG_ON(ret == ph);
> + BUG_ON(ret != _hashes[idx ^ 1]);
> + /* XXX: kfree(ret->table) */
> + ret->shift = -1;
> + ret->table = NULL;
> + }
> + }
> + mutex_unlock(_pidhash.resize_mutex);
> +}
> +
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revised timerfd() interface
Hi Davide, > > > > > > As I think about this more, I see more problems with > > > > > > your argument. timerfd needs the ability to get and > > > > > > get-while-setting just as much as the earlier APIs. > > > > > > Consider a library that creates a timerfd file descriptor that > > > > > > is handed off to an application: that library may want > > > > > > to modify the timer settings without having to create a > > > > > > new file descriptor (the app mey not be able to be told about > > > > > > the new fd). Your argument just doesn't hold, AFAICS. > > > > > > > > > > Such hypotethical library, in case it really wanted to offer such > > > > > functionality, could simply return an handle instead of the raw > > > > > fd, and take care of all that stuff in userspace. > > > > > > > > Did I miss something? Is it not the case that as soon as the > > > > library returns a handle, rather than an fd, then the whole > > > > advantage of timerfd() (being able to select/poll/epoll on > > > > the timer as well as other fds) is lost? > > > > > > Why? The handle would simply be a little struct where the timerfd fd > > > is > > > stored, and a XXX_getfd() would return it. > > > So my point is, I doubt such functionalities are really needed, and I > > > also argue that the kernel is the best place for such wrapper code > > > to go. > > > > So what happens if one thread (via the library) wants modify > > a timer's settings at the same timer as another thread is > > select()ing on it? The first thread can't do this by creating > > a new timerfd timer, since it wants to affect the select() > > in the other thread? > > It can be done w/out any problems. The select thread will be notified > whenever the new timer setting expires. We are going in circles here. I think you are missing my point. Consider the following [[ Thread A: calls library function which creates a timerfd file descriptor. Thread B: calls select() on the timerfd file descriptor. Thread A: calls library function which wants to: a) modify timer settings, and retrieve copy of current timer settings, and later b) restore old timer settings. ]] This seems a quite reasonable use-case to me, and the existing interface simply can't support it. Cheers, Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages , read the HOWTOHELP file and grep the source files for 'FIXME'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.6.22: what IS the VM doing?
Sami Farin wrote: On Wed, Sep 05, 2007 at 12:24:26 -0400, Rik van Riel wrote: ... *shrug* The attached patch should make sure kswapd does not free an excessive number of pages in zone_normal just because the pages in zone_highmem are difficult to free. It does give kswapd a large margin to continue putting equal pressure on all zones in normal situations. Sami, could you try out this patch to see if it helps your situation? Thanks, Rik. bzImage is ready, I probably reboot inside one month for a reason or other 8-) The more I look at the bug, the more I see that it is probably not very easy to reproduce on demand. I have, however, a full explanation on why it happens and why the patch should fix it, so I will submit it for inclusion in -mm. Sami, thank you for the detailed bug report. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On 9/5/07, Andreas Herrmann <[EMAIL PROTECTED]> wrote: > On Wed, Sep 05, 2007 at 01:05:25PM +0200, Arne Georg Gleditsch wrote: > > "H. Peter Anvin" <[EMAIL PROTECTED]> writes: > > > You're missing the point. How will the PCI bus transactions be > > > different when using MMCONFIG versus your extended CF8 version? > > > > Conceivably this is useful if the IO hub does not support MMCONFIG > > accesses. The AMD 8111 does not, as far as I can see. At least I > > have an Opteron system where MMCONFIG is not supported, and I assume > > it's because the 8111 doesn't provide it. I don't know if this is > > going to be a realistic scenario for Barcelona systems. mmconfig is set in NB ( in new CPU), Do we still need to set mmconfig in SB like mcp55? YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Fix (improve) deadlock condition on module removal netfilter socket option removal
On Wed, 2007-09-05 at 16:26 -0400, Jon Masters wrote:
> On Tue, 2007-09-04 at 16:30 -0400, Neil Horman wrote:
>
> > 2nd of two patches. This patch enhances modprobe to operate like rmmod
> > in non-blocking mode. It also adds a -w option to allow for explicit
> > blocking
> > operation.
>
> As I suspected, this patch isn't in the tree. I am going to commit it
> now because it makes sense. I'm also going to sort out moving things to
> kernel.org this afternoon while I'm at it - I don't want to confuse
> people with kerneltools.org any more now I've got a kernel.org acc.
1) You don't want to hand the "wait" flag (ie ~O_NONBLOCK) to
sub-rmmods,
2) You need to do something about this code if wait is specified:
if (usecount != 0) {
if (!ignore_inuse)
error("Module %s is in use.\n", name);
goto remove_rest;
}
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: 2.4.35.1 and panic at boot with arch=c3 and gcc-4.x
On Thu, 6 Sep 2007, Willy Tarreau wrote: > > I finally tracked the problem down to a dirty trick used to prevent > do_test_wp_bit() from being inlined (Axel, you identified the right > file). Unfortunately, this trick does not work anymore when gcc-4.x > is used without -fno-unit-at-a-time, so let's use the correct method > instead. > > > -/* Put this after the callers, so that it cannot be inlined */ > -static int do_test_wp_bit(unsigned long vaddr) Ick, that was horrible indeed! > I really hope that this trick is not used anywhere else! Me too ... funnily enough, 2.6.23-rc5 still has that wrong comment in it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.35.1 and panic at boot with arch=c3 and gcc-4.x
Axel, Richard,
you both reported a very similar problem to me (panic at boot on VIA c3
with 2.4.35.1 when built with gcc-4.1). I could reproduce the problem
with your configs here and compare the code with your working builds.
I finally tracked the problem down to a dirty trick used to prevent
do_test_wp_bit() from being inlined (Axel, you identified the right
file). Unfortunately, this trick does not work anymore when gcc-4.x
is used without -fno-unit-at-a-time, so let's use the correct method
instead. I really hope that this trick is not used anywhere else!
The following patch fixes the issue for me. Could you please give it a
try before I merge it?
Thanks in advance,
Willy
--
>From 6ede67f873403d7e19fc0099952badd1db73ed66 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <[EMAIL PROTECTED]>
Date: Wed, 5 Sep 2007 23:39:11 +0200
Subject: [PATCH] i386: do_test_wp_bit() must not be inlined
do_test_wp_bit() has a comment stating that it must not be inlined.
Unfortunately, the trick to prevent it from being inlined is not
reliable under gcc 4.x.
The simple fix consists in specifying the noinline attribute.
Tested and confirmed to produce the correct code for gcc versions
2.95.3, 3.3.6, 3.4.6, 4.0.2, 4.1.1 and 4.2.1.
Special thanks to Axel Reinhold and Richard Kojedzinszky for their
continuous feedback when trying to solve this issue.
Signed-off-by: Willy Tarreau <[EMAIL PROTECTED]>
---
arch/i386/mm/init.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/i386/mm/init.c b/arch/i386/mm/init.c
index 0dc1751..2d81117 100644
--- a/arch/i386/mm/init.c
+++ b/arch/i386/mm/init.c
@@ -381,7 +381,7 @@ void __init paging_init(void)
* This function cannot be __init, since exceptions don't work in that
* section.
*/
-static int do_test_wp_bit(unsigned long vaddr);
+static int __attribute__((noinline)) do_test_wp_bit(unsigned long vaddr);
void __init test_wp_bit(void)
{
@@ -561,8 +561,8 @@ void __init mem_init(void)
}
-/* Put this after the callers, so that it cannot be inlined */
-static int do_test_wp_bit(unsigned long vaddr)
+/* This function must not be inlined */
+static int __attribute__((noinline)) do_test_wp_bit(unsigned long vaddr)
{
char tmp_reg;
int flag;
--
1.5.2.5
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 10:34:38PM +0200, Oleg Verych wrote: > On Wed, Sep 05, 2007 at 07:46:11PM +0100, Denys Vlasenko wrote: > > On Wednesday 05 September 2007 16:53, Oleg Verych wrote: > > > * Wed, 5 Sep 2007 14:43:21 +0100 > > > * User-Agent: KMail/1.9.1 > > > > > > > > Build system: section garbage collection for vmlinux > > > > > > Maybe this is just a test suit to get finish with `make XYZ static`? > > > > They are vaguely connected in a sense that unused function which is > > not marked static doesn't generate gcc warning, but will be discarded > > by --gc-sections. "make XYZ static" also tends to find them - you make > > function static, you recompile the file, and gcc informs you that > > the function is not used at all! > > > > This happened to me when I did aic7xxx patches. > > > > You may yse --print-gc-sections to see the list of discarded sections. > > Anyway, this is gccism/binutilizm. That about other possible/future > options? The kernel requires GNU gcc and GNU binutils, and if you want to use other tools for building the kernel they have to be sufficiently compatible. > Give me example, please, why function must be non static if not used. s/not used/not used in this kernel configuration/ > If usage requires kconfig tuning, then this is a better way to go, than > to adopt yet another GNU/Luxury. The alternative would be to use an unmaintainable amount of #ifdef's. 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: Hang in 2.6.23-rc5
On Wed, 5 Sep 2007, Jean Delvare wrote: > > On Mon, Sep 03, 2007 at 04:15:01AM +0530, Satyam Sharma wrote: > > > That's my impression as well. That's way too core/busy a codepath to have > > > a bug in. As I said earlier, almost anybody testing -rc5 is sure to hit > > > this within a few hours (probably less) > [...] > > (Satyam's estimation that everybody would hit the bug within an hour ... within a *few* hours, not "an" :-) > doesn't match my experience, I had "only" 2 freezes in 60 hours or so.) ~10 people bothered to report this on LKML -- and there could easily have been others who didn't, and simply switched to -rc4. And then many more might've hit it, foudn this thread immediately (like you did), and hence didn't report again ... so I still pretty much stand by what I'd said :-) But in any case as you said it's fixed already so no bother. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 RFC 8/8] RCU: Make RCU priority boosting consume less power
Work in progress, not for inclusion.
This patch modified the RCU priority booster to explicitly sleep when
there are no RCU readers in need of priority boosting. This should be
a power-consumption improvement over the one-second polling cycle in
the underlying RCU priority-boosting patch.
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
include/linux/rcupreempt.h | 15 ++
kernel/rcupreempt.c| 102 -
2 files changed, 115 insertions(+), 2 deletions(-)
diff -urpNa -X dontdiff linux-2.6.22-G-boosttorture/include/linux/rcupreempt.h
linux-2.6.22-H-boostsleep/include/linux/rcupreempt.h
--- linux-2.6.22-G-boosttorture/include/linux/rcupreempt.h 2007-08-24
11:24:59.0 -0700
+++ linux-2.6.22-H-boostsleep/include/linux/rcupreempt.h2007-08-24
18:12:41.0 -0700
@@ -60,6 +60,21 @@ enum rcu_boost_state {
#define N_RCU_BOOST_STATE (RCU_BOOST_INVALID + 1)
+/*
+ * RCU-booster state with respect to sleeping. The RCU booster
+ * sleeps when no task has recently been seen sleeping in an RCU
+ * read-side critical section, and is awakened when a new sleeper
+ * appears.
+ */
+enum rcu_booster_state {
+ RCU_BOOSTER_ACTIVE = 0, /* RCU booster actively scanning. */
+ RCU_BOOSTER_DROWSY = 1, /* RCU booster is considering sleeping. */
+ RCU_BOOSTER_SLEEPING = 2, /* RCU booster is asleep. */
+ RCU_BOOSTER_INVALID = 3, /* For bogus state sightings. */
+};
+
+#define N_RCU_BOOSTER_STATE (RCU_BOOSTER_INVALID + 1)
+
#endif /* #ifdef CONFIG_PREEMPT_RCU_BOOST */
#define call_rcu_bh(head, rcu) call_rcu(head, rcu)
diff -urpNa -X dontdiff linux-2.6.22-G-boosttorture/kernel/rcupreempt.c
linux-2.6.22-H-boostsleep/kernel/rcupreempt.c
--- linux-2.6.22-G-boosttorture/kernel/rcupreempt.c 2007-08-27
15:42:57.0 -0700
+++ linux-2.6.22-H-boostsleep/kernel/rcupreempt.c 2007-08-27
15:42:37.0 -0700
@@ -108,6 +108,7 @@ struct rcu_boost_dat {
unsigned long rbs_unboosted;
#ifdef CONFIG_PREEMPT_RCU_BOOST_STATS
unsigned long rbs_stats[N_RCU_BOOST_DAT_EVENTS][N_RCU_BOOST_STATE];
+ unsigned long rbs_qw_stats[N_RCU_BOOSTER_STATE];
#endif /* #ifdef CONFIG_PREEMPT_RCU_BOOST_STATS */
};
#define RCU_BOOST_ELEMENTS 4
@@ -115,6 +116,10 @@ struct rcu_boost_dat {
static int rcu_boost_idx = -1; /* invalid value for early RCU use. */
static DEFINE_PER_CPU(struct rcu_boost_dat, rcu_boost_dat[RCU_BOOST_ELEMENTS]);
static struct task_struct *rcu_boost_task;
+static DEFINE_SPINLOCK(rcu_boost_quiesce_lock);
+static enum rcu_booster_state rcu_booster_quiesce_state = RCU_BOOSTER_ACTIVE;
+static unsigned long rbs_qs_stats[2][N_RCU_BOOSTER_STATE];
+wait_queue_head_t rcu_booster_quiesce_wq;
#ifdef CONFIG_PREEMPT_RCU_BOOST_STATS
@@ -171,6 +176,15 @@ static char *rcu_boost_state_error[] = {
"? ?", /* unlock */
};
+/* Labels for RCU booster state printout. */
+
+static char *rcu_booster_state_label[] = {
+ "Active",
+ "Drowsy",
+ "Sleeping",
+ "???",
+};
+
/*
* Print out RCU booster task statistics at the specified interval.
*/
@@ -221,6 +235,14 @@ static void rcu_boost_dat_stat_print(voi
cpu)[i].rbs_stats[event][state];
}
}
+ for (state = 0; state < N_RCU_BOOSTER_STATE; state++) {
+ sum.rbs_qw_stats[state] = 0;
+ for_each_possible_cpu(cpu)
+ for (i = 0; i < RCU_BOOST_ELEMENTS; i++)
+ sum.rbs_qw_stats[state] +=
+ per_cpu(rcu_boost_dat,
+ cpu)[i].rbs_qw_stats[state];
+ }
/* Print them out! */
@@ -240,6 +262,24 @@ static void rcu_boost_dat_stat_print(voi
rcu_boost_state_event[event], buf);
}
+ printk(KERN_INFO "RCU booster state: %s\n",
+ rcu_booster_quiesce_state >= 0 &&
+ rcu_booster_quiesce_state < N_RCU_BOOSTER_STATE
+ ? rcu_booster_state_label[rcu_booster_quiesce_state]
+ : "???");
+ i = 0;
+ for (state = 0; state < N_RCU_BOOSTER_STATE; state++)
+ i += sprintf([i], " %ld", rbs_qs_stats[0][state]);
+ printk(KERN_INFO "No tasks found: %s\n", buf);
+ i = 0;
+ for (state = 0; state < N_RCU_BOOSTER_STATE; state++)
+ i += sprintf([i], " %ld", rbs_qs_stats[1][state]);
+ printk(KERN_INFO "Tasks found: %s\n", buf);
+ i = 0;
+ for (state = 0; state < N_RCU_BOOSTER_STATE; state++)
+ i += sprintf([i], " %ld", sum.rbs_qw_stats[state]);
+ printk(KERN_INFO "Awaken opportunities: %s\n", buf);
+
/* Go away and don't come back for awhile. */
lastprint = xtime.tv_sec;
@@ -293,6 +333,8 @@ static void init_rcu_boost_early(void)
for (j = 0; j <
Re: [PATCH 0/2] Fix (improve) deadlock condition on module removal netfilter socket option removal
On Wed, 2007-09-05 at 15:27 -0400, Neil Horman wrote: > Now, I suppose its possible that I've not been looking at the right source > tree > when doing my work. I've based my modprobe patch on this git tree: > http://git.kernel.org/?p=linux/kernel/git/kyle/module-init-tools.git;a=summary > If theres a newer one, if you could please point it out to me, I'd appreciate > it. If the functional equivalent of my second patch is already in there, then > we just need my first patch to be good to go. Neil, please test: http://www.kernel.org/pub/linux/kernel/people/jcm/module-init-tools/module-init-tools-3.3-pre12.tar.bz2 Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc4-mm1 - git-alsa.patch breaks audio on Dell Latitude D820
At Wed, 05 Sep 2007 17:16:49 -0400,
[EMAIL PROTECTED] wrote:
>
> On Wed, 05 Sep 2007 22:27:35 +0200, Takashi Iwai said:
>
> > BTW, there are 10 different models to test for Dell with STAC9200
> > (dell-d2[1-3] and dell-m2[1-7], see
>
> modprobe snd_hda_intel model=dell-m23
>
> was the magic incantation. I'm sure that every user who trips over this
> is going to call it a regression, since the -rc3-mm1 module was able to
> get it right without hints. ;)
Well, it's indeed a regression. There seems to be mistakes in the pin
configuration orders.
Could you try the patch below (without model option)?
thanks,
Takashi
diff -r 3a300e020eca pci/hda/patch_sigmatel.c
--- a/pci/hda/patch_sigmatel.c Wed Sep 05 19:14:38 2007 +0200
+++ b/pci/hda/patch_sigmatel.c Wed Sep 05 23:37:25 2007 +0200
@@ -563,8 +563,8 @@ static unsigned int ref9200_pin_configs[
102801E8
*/
static unsigned int dell9200_d21_pin_configs[8] = {
- 0x41f0, 0x41f1, 0x01a19021, 0x90100140,
- 0x01813122, 0x02214030, 0x01014010, 0x02a19020,
+ 0x41f0, 0x41f1, 0x02214030, 0x01014010,
+ 0x02a19020, 0x01a19021, 0x90100140, 0x01813122,
};
/*
@@ -573,8 +573,8 @@ static unsigned int dell9200_d21_pin_con
102801C1
*/
static unsigned int dell9200_d22_pin_configs[8] = {
- 0x41f0, 0x41f1, 0x02a19021, 0x90100140,
- 0x41f2, 0x0221401f, 0x01014010, 0x01813020,
+ 0x41f0, 0x41f1, 0x0221401f, 0x01014010,
+ 0x01813020, 0x02a19021, 0x90100140, 0x41f2,
};
/*
@@ -587,8 +587,8 @@ static unsigned int dell9200_d22_pin_con
102801E3
*/
static unsigned int dell9200_d23_pin_configs[8] = {
- 0x41f0, 0x41f1, 0x01a19021, 0x90100140,
- 0x41f2, 0x0221401f, 0x01014010, 0x01813020,
+ 0x41f0, 0x41f1, 0x0221401f, 0x01014010,
+ 0x01813020, 0x01a19021, 0x90100140, 0x41f2,
};
@@ -598,8 +598,8 @@ static unsigned int dell9200_d23_pin_con
102801D8 (Dell Inspiron 640m)
*/
static unsigned int dell9200_m21_pin_configs[8] = {
- 0x40c003fa, 0x03441340, 0x03a11020, 0x401003fc,
- 0x403003fd, 0x0321121f, 0x0321121f, 0x408003fb,
+ 0x40c003fa, 0x03441340, 0x0321121f, 0x90170310,
+ 0x408003fb, 0x03a11020, 0x401003fc, 0x403003fd,
};
/*
@@ -611,8 +611,8 @@ static unsigned int dell9200_m21_pin_con
102801D6
*/
static unsigned int dell9200_m22_pin_configs[8] = {
- 0x40c003fa, 0x0144131f, 0x03A11020, 0x401003fb,
- 0x40f000fc, 0x0321121f, 0x90170310, 0x90a70321,
+ 0x40c003fa, 0x0144131f, 0x0321121f, 0x90170310,
+ 0x90a70321, 0x03a11020, 0x401003fb, 0x40f000fc,
};
/*
@@ -633,8 +633,8 @@ static unsigned int dell9200_m23_pin_con
102801D3
*/
static unsigned int dell9200_m24_pin_configs[8] = {
- 0x40c003fa, 0x404003fb, 0x03a11020, 0x401003fd,
- 0x403003fe, 0x0321121f, 0x90170310, 0x408003fc,
+ 0x40c003fa, 0x404003fb, 0x0321121f, 0x90170310,
+ 0x408003fc, 0x03a11020, 0x401003fd, 0x403003fe,
};
/*
@@ -644,8 +644,8 @@ static unsigned int dell9200_m24_pin_con
102801EF
*/
static unsigned int dell9200_m25_pin_configs[8] = {
- 0x40c003fa, 0x01441340, 0x04a11020, 0x401003fc,
- 0x403003fd, 0x0421121f, 0x90170310, 0x408003fb,
+ 0x40c003fa, 0x01441340, 0x0421121f, 0x90170310,
+ 0x408003fb, 0x04a11020, 0x401003fc, 0x403003fd,
};
/*
@@ -654,8 +654,8 @@ static unsigned int dell9200_m25_pin_con
102801F6
*/
static unsigned int dell9200_m26_pin_configs[8] = {
- 0x40c003fa, 0x404003fb, 0x04a11020, 0x401003fd,
- 0x403003fe, 0x0421121f, 0x90170310, 0x408003fc,
+ 0x40c003fa, 0x404003fb, 0x0421121f, 0x90170310,
+ 0x408003fc, 0x04a11020, 0x401003fd, 0x403003fe,
};
/*
@@ -663,8 +663,8 @@ static unsigned int dell9200_m26_pin_con
102801CD (Dell Inspiron E1705/9400)
*/
static unsigned int dell9200_m27_pin_configs[8] = {
- 0x40c003fa, 0x01441340, 0x04a11020, 0x90170310,
- 0x40f003fc, 0x0421121f, 0x90170310, 0x408003fb,
+ 0x40c003fa, 0x01441340, 0x0421121f, 0x90170310,
+ 0x90170310, 0x04a11020, 0x90170310, 0x40f003fc,
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 RFC 7/8] RCU: rcutorture testing for RCU priority boosting
Work in progress, not for inclusion. Still uses xtime because this
patch is still against 2.6.22.
This patch modifies rcutorture to also torture RCU priority boosting.
The torturing involves forcing RCU read-side critical sections (already
performed as part of the torturing of RCU) to run for extremely long
time periods, increasing the probability of their being preempted and
thus needing priority boosting. The fact that rcutorture's "nreaders"
module parameter defaults to twice the number of CPUs helps ensure lots
of the needed preemption.
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
rcutorture.c | 91 +--
1 file changed, 77 insertions(+), 14 deletions(-)
diff -urpNa -X dontdiff linux-2.6.22-f-boost/kernel/rcutorture.c
linux-2.6.22-g-boosttorture/kernel/rcutorture.c
--- linux-2.6.22-f-boost/kernel/rcutorture.c2007-07-08 16:32:17.0
-0700
+++ linux-2.6.22-g-boosttorture/kernel/rcutorture.c 2007-08-22
16:18:32.0 -0700
@@ -58,6 +58,7 @@ static int stat_interval; /* Interval be
static int verbose;/* Print more debug info. */
static int test_no_idle_hz;/* Test RCU's support for tickless idle CPUs. */
static int shuffle_interval = 5; /* Interval between shuffles (in sec)*/
+static int preempt_torture;/* Realtime task preempts torture readers. */
static char *torture_type = "rcu"; /* What RCU implementation to torture. */
module_param(nreaders, int, 0444);
@@ -72,6 +73,8 @@ module_param(test_no_idle_hz, bool, 0444
MODULE_PARM_DESC(test_no_idle_hz, "Test support for tickless idle CPUs");
module_param(shuffle_interval, int, 0444);
MODULE_PARM_DESC(shuffle_interval, "Number of seconds between shuffles");
+module_param(preempt_torture, bool, 0444);
+MODULE_PARM_DESC(preempt_torture, "Enable realtime preemption torture");
module_param(torture_type, charp, 0444);
MODULE_PARM_DESC(torture_type, "Type of RCU to torture (rcu, rcu_bh, srcu)");
@@ -194,6 +197,8 @@ struct rcu_torture_ops {
int (*completed)(void);
void (*deferredfree)(struct rcu_torture *p);
void (*sync)(void);
+ long (*preemptstart)(void);
+ void (*preemptend)(void);
int (*stats)(char *page);
char *name;
};
@@ -258,16 +263,75 @@ static void rcu_torture_deferred_free(st
call_rcu(>rtort_rcu, rcu_torture_cb);
}
+static struct task_struct *rcu_preeempt_task;
+static unsigned long rcu_torture_preempt_errors;
+
+static int rcu_torture_preempt(void *arg)
+{
+ int completedstart;
+ int err;
+ time_t gcstart;
+ struct sched_param sp;
+
+ sp.sched_priority = MAX_RT_PRIO - 1;
+ err = sched_setscheduler(current, SCHED_RR, );
+ if (err != 0)
+ printk(KERN_ALERT "rcu_torture_preempt() priority err: %d\n",
+ err);
+ current->flags |= PF_NOFREEZE;
+
+ do {
+ completedstart = rcu_torture_completed();
+ gcstart = xtime.tv_sec;
+ while ((xtime.tv_sec - gcstart < 10) &&
+ (rcu_torture_completed() == completedstart))
+ cond_resched();
+ if (rcu_torture_completed() == completedstart)
+ rcu_torture_preempt_errors++;
+ schedule_timeout_interruptible(HZ);
+ } while (!kthread_should_stop());
+ return 0;
+}
+
+static long rcu_preempt_start(void)
+{
+ long retval = 0;
+
+ rcu_preeempt_task = kthread_run(rcu_torture_preempt, NULL,
+ "rcu_torture_preempt");
+ if (IS_ERR(rcu_preeempt_task)) {
+ VERBOSE_PRINTK_ERRSTRING("Failed to create preempter");
+ retval = PTR_ERR(rcu_preeempt_task);
+ rcu_preeempt_task = NULL;
+ }
+ return retval;
+}
+
+static void rcu_preempt_end(void)
+{
+ if (rcu_preeempt_task != NULL) {
+ VERBOSE_PRINTK_STRING("Stopping rcu_preempt task");
+ kthread_stop(rcu_preeempt_task);
+ }
+ rcu_preeempt_task = NULL;
+}
+
+static int rcu_preempt_stats(char *page)
+{
+ return sprintf(page,
+ "Preemption stalls: %lu\n", rcu_torture_preempt_errors);
+}
+
static struct rcu_torture_ops rcu_ops = {
- .init = NULL,
- .cleanup = NULL,
.readlock = rcu_torture_read_lock,
.readdelay = rcu_read_delay,
.readunlock = rcu_torture_read_unlock,
.completed = rcu_torture_completed,
.deferredfree = rcu_torture_deferred_free,
.sync = synchronize_rcu,
- .stats = NULL,
+ .preemptstart = rcu_preempt_start,
+ .preemptend = rcu_preempt_end,
+ .stats = rcu_preempt_stats,
.name = "rcu"
};
@@ -299,14 +363,12 @@ static void rcu_sync_torture_init(void)
static struct rcu_torture_ops rcu_sync_ops = {
.init = rcu_sync_torture_init,
- .cleanup = NULL,
.readlock =
[PATCH RFC 6/8] RCU priority boosting for preemptible RCU
Work in progress, not for inclusion.
RCU priority boosting is needed when running a workload that might include
CPU-bound user tasks running at realtime priorities with preemptible RCU.
In this situation, RCU priority boosting is needed to avoid OOM.
Please note that because Classic RCU does not permit RCU read-side
critical sections to be preempted, there is no need to boost the priority
of Classic RCU readers. Boosting the priority of a running process
does not make it run any faster, at least not on any hardware that I am
aware of. ;-)
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
include/linux/init_task.h | 13
include/linux/rcupdate.h | 17 +
include/linux/rcupreempt.h | 20 +
include/linux/sched.h | 24 +
init/main.c|1
kernel/Kconfig.preempt | 14 -
kernel/fork.c |6
kernel/rcupreempt.c| 608 ++---
kernel/rtmutex.c |7
kernel/sched.c |5
lib/Kconfig.debug | 34 ++
11 files changed, 703 insertions(+), 46 deletions(-)
diff -urpNa -X dontdiff linux-2.6.22-E-hotplug/include/linux/init_task.h
linux-2.6.22-F-boostrcu/include/linux/init_task.h
--- linux-2.6.22-E-hotplug/include/linux/init_task.h2007-07-08
16:32:17.0 -0700
+++ linux-2.6.22-F-boostrcu/include/linux/init_task.h 2007-08-31
14:09:02.0 -0700
@@ -87,6 +87,17 @@ extern struct nsproxy init_nsproxy;
.signalfd_list = LIST_HEAD_INIT(sighand.signalfd_list),\
}
+#ifdef CONFIG_PREEMPT_RCU_BOOST
+#define INIT_RCU_BOOST_PRIO .rcu_prio = MAX_PRIO,
+#define INIT_PREEMPT_RCU_BOOST(tsk)\
+ .rcub_rbdp = NULL, \
+ .rcub_state = RCU_BOOST_IDLE, \
+ .rcub_entry = LIST_HEAD_INIT(tsk.rcub_entry),
+#else /* #ifdef CONFIG_PREEMPT_RCU_BOOST */
+#define INIT_RCU_BOOST_PRIO
+#define INIT_PREEMPT_RCU_BOOST(tsk)
+#endif /* #else #ifdef CONFIG_PREEMPT_RCU_BOOST */
+
extern struct group_info init_groups;
#define INIT_STRUCT_PID { \
@@ -125,6 +136,7 @@ extern struct group_info init_groups;
.prio = MAX_PRIO-20, \
.static_prio= MAX_PRIO-20, \
.normal_prio= MAX_PRIO-20, \
+ INIT_RCU_BOOST_PRIO \
.policy = SCHED_NORMAL, \
.cpus_allowed = CPU_MASK_ALL, \
.mm = NULL, \
@@ -169,6 +181,7 @@ extern struct group_info init_groups;
}, \
INIT_TRACE_IRQFLAGS \
INIT_LOCKDEP\
+ INIT_PREEMPT_RCU_BOOST(tsk) \
}
diff -urpNa -X dontdiff linux-2.6.22-E-hotplug/include/linux/rcupdate.h
linux-2.6.22-F-boostrcu/include/linux/rcupdate.h
--- linux-2.6.22-E-hotplug/include/linux/rcupdate.h 2007-08-24
11:03:22.0 -0700
+++ linux-2.6.22-F-boostrcu/include/linux/rcupdate.h2007-08-24
17:04:14.0 -0700
@@ -252,5 +252,22 @@ static inline void rcu_qsctr_inc(int cpu
per_cpu(rcu_data_passed_quiesc, cpu) = 1;
}
+#ifdef CONFIG_PREEMPT_RCU_BOOST
+extern void init_rcu_boost_late(void);
+extern void __rcu_preempt_boost(void);
+#define rcu_preempt_boost() /* cpp to avoid #include hell. */ \
+ do { \
+ if (unlikely(current->rcu_read_lock_nesting > 0)) \
+ __rcu_preempt_boost(); \
+ } while (0)
+#else /* #ifdef CONFIG_PREEMPT_RCU_BOOST */
+static inline void init_rcu_boost_late(void)
+{
+}
+static inline void rcu_preempt_boost(void)
+{
+}
+#endif /* #else #ifdef CONFIG_PREEMPT_RCU_BOOST */
+
#endif /* __KERNEL__ */
#endif /* __LINUX_RCUPDATE_H */
diff -urpNa -X dontdiff linux-2.6.22-E-hotplug/include/linux/rcupreempt.h
linux-2.6.22-F-boostrcu/include/linux/rcupreempt.h
--- linux-2.6.22-E-hotplug/include/linux/rcupreempt.h 2007-08-24
11:20:32.0 -0700
+++ linux-2.6.22-F-boostrcu/include/linux/rcupreempt.h 2007-08-24
11:24:59.0 -0700
@@ -42,6 +42,26 @@
#include
#include
+#ifdef CONFIG_PREEMPT_RCU_BOOST
+/*
+ * Task state with respect to being RCU-boosted. This state is changed
+ * by the task itself in response to the following three events:
+ * 1. Preemption (or block on lock) while in RCU read-side critical section.
+ * 2. Outermost rcu_read_unlock() for blocked RCU read-side critical section.
+ *
+ * The RCU-boost task also updates the state when boosting priority.
+ */
+enum rcu_boost_state {
+ RCU_BOOST_IDLE = 0,/* Not yet blocked if
[PATCH RFC 5/8] RCU: CPU hotplug support for preemptible RCU
Work in progress, not for inclusion.
This patch allows preemptible RCU to tolerate CPU-hotplug operations.
It accomplishes this by maintaining a local copy of a map of online
CPUs, which it accesses under its own lock.
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
include/linux/rcuclassic.h |2
include/linux/rcupreempt.h |2
kernel/rcuclassic.c|8 +++
kernel/rcupreempt.c| 93 +++--
4 files changed, 100 insertions(+), 5 deletions(-)
diff -urpNa -X dontdiff linux-2.6.22-d-schedclassic/include/linux/rcuclassic.h
linux-2.6.22-e-hotplugcpu/include/linux/rcuclassic.h
--- linux-2.6.22-d-schedclassic/include/linux/rcuclassic.h 2007-08-22
15:38:22.0 -0700
+++ linux-2.6.22-e-hotplugcpu/include/linux/rcuclassic.h2007-08-22
15:55:39.0 -0700
@@ -143,6 +143,8 @@ extern int rcu_needs_cpu(int cpu);
#define rcu_check_callbacks_rt(cpu, user)
#define rcu_init_rt()
#define rcu_needs_cpu_rt(cpu) 0
+#define rcu_offline_cpu_rt(cpu)
+#define rcu_online_cpu_rt(cpu)
#define rcu_pending_rt(cpu) 0
#define rcu_process_callbacks_rt(unused)
diff -urpNa -X dontdiff linux-2.6.22-d-schedclassic/include/linux/rcupreempt.h
linux-2.6.22-e-hotplugcpu/include/linux/rcupreempt.h
--- linux-2.6.22-d-schedclassic/include/linux/rcupreempt.h 2007-08-22
15:38:22.0 -0700
+++ linux-2.6.22-e-hotplugcpu/include/linux/rcupreempt.h2007-08-22
15:55:39.0 -0700
@@ -59,6 +59,8 @@ extern void rcu_advance_callbacks_rt(int
extern void rcu_check_callbacks_rt(int cpu, int user);
extern void rcu_init_rt(void);
extern int rcu_needs_cpu_rt(int cpu);
+extern void rcu_offline_cpu_rt(int cpu);
+extern void rcu_online_cpu_rt(int cpu);
extern int rcu_pending_rt(int cpu);
struct softirq_action;
extern void rcu_process_callbacks_rt(struct softirq_action *unused);
diff -urpNa -X dontdiff linux-2.6.22-d-schedclassic/kernel/rcuclassic.c
linux-2.6.22-e-hotplugcpu/kernel/rcuclassic.c
--- linux-2.6.22-d-schedclassic/kernel/rcuclassic.c 2007-08-22
15:51:22.0 -0700
+++ linux-2.6.22-e-hotplugcpu/kernel/rcuclassic.c 2007-08-22
15:55:39.0 -0700
@@ -414,14 +414,19 @@ static void __rcu_offline_cpu(struct rcu
static void rcu_offline_cpu(int cpu)
{
struct rcu_data *this_rdp = _cpu_var(rcu_data);
+#ifdef CONFIG_CLASSIC_RCU
struct rcu_data *this_bh_rdp = _cpu_var(rcu_bh_data);
+#endif /* #ifdef CONFIG_CLASSIC_RCU */
__rcu_offline_cpu(this_rdp, _ctrlblk,
_cpu(rcu_data, cpu));
+#ifdef CONFIG_CLASSIC_RCU
__rcu_offline_cpu(this_bh_rdp, _bh_ctrlblk,
_cpu(rcu_bh_data, cpu));
- put_cpu_var(rcu_data);
put_cpu_var(rcu_bh_data);
+#endif /* #ifdef CONFIG_CLASSIC_RCU */
+ put_cpu_var(rcu_data);
+ rcu_offline_cpu_rt(cpu);
}
#else
@@ -571,6 +576,7 @@ static void __devinit rcu_online_cpu(int
rdp->passed_quiesc = _cpu(rcu_data_passed_quiesc, cpu);
rcu_init_percpu_data(cpu, _bh_ctrlblk, bh_rdp);
bh_rdp->passed_quiesc = _cpu(rcu_data_bh_passed_quiesc, cpu);
+ rcu_online_cpu_rt(cpu);
}
static int __cpuinit rcu_cpu_notify(struct notifier_block *self,
diff -urpNa -X dontdiff linux-2.6.22-d-schedclassic/kernel/rcupreempt.c
linux-2.6.22-e-hotplugcpu/kernel/rcupreempt.c
--- linux-2.6.22-d-schedclassic/kernel/rcupreempt.c 2007-08-22
15:45:28.0 -0700
+++ linux-2.6.22-e-hotplugcpu/kernel/rcupreempt.c 2007-08-22
15:56:22.0 -0700
@@ -125,6 +125,8 @@ enum rcu_mb_flag_values {
};
static DEFINE_PER_CPU(enum rcu_mb_flag_values, rcu_mb_flag) = rcu_mb_done;
+static cpumask_t rcu_cpu_online_map = CPU_MASK_NONE;
+
/*
* Macro that prevents the compiler from reordering accesses, but does
* absolutely -nothing- to prevent CPUs from reordering. This is used
@@ -404,7 +406,7 @@ rcu_try_flip_idle(void)
/* Now ask each CPU for acknowledgement of the flip. */
- for_each_possible_cpu(cpu)
+ for_each_cpu_mask(cpu, rcu_cpu_online_map)
per_cpu(rcu_flip_flag, cpu) = rcu_flipped;
return 1;
@@ -420,7 +422,7 @@ rcu_try_flip_waitack(void)
int cpu;
RCU_TRACE_ME(rcupreempt_trace_try_flip_a1);
- for_each_possible_cpu(cpu)
+ for_each_cpu_mask(cpu, rcu_cpu_online_map)
if (per_cpu(rcu_flip_flag, cpu) != rcu_flip_seen) {
RCU_TRACE_ME(rcupreempt_trace_try_flip_ae1);
return 0;
@@ -462,7 +464,7 @@ rcu_try_flip_waitzero(void)
/* Call for a memory barrier from each CPU. */
- for_each_possible_cpu(cpu)
+ for_each_cpu_mask(cpu, rcu_cpu_online_map)
per_cpu(rcu_mb_flag, cpu) = rcu_mb_needed;
RCU_TRACE_ME(rcupreempt_trace_try_flip_z2);
@@ -480,7 +482,7 @@ rcu_try_flip_waitmb(void)
int cpu;
RCU_TRACE_ME(rcupreempt_trace_try_flip_m1);
-
[PATCH RFC 4/8] RCU: synchronize_sched() workaround for CPU hotplug
Work in progress, not for inclusion.
The combination of CPU hotplug and PREEMPT_RCU has resulted in deadlocks
due to the migration-based implementation of synchronize_sched() in -rt.
This experimental patch maps synchronize_sched() back onto Classic RCU,
eliminating the migration, thus hopefully also eliminating the deadlocks.
It is not clear that this is a good long-term approach, but it will at
least permit people doing CPU hotplug in -rt kernels additional wiggle
room in their design and implementation.
The basic approach is to cause the -rt kernel to incorporate rcuclassic.c
as well as rcupreempt.c, but to #ifdef out the conflicting portions of
rcuclassic.c so that only the code needed to implement synchronize_sched()
remains in a PREEMPT_RT build. Invocations of grace-period detection from
the scheduling-clock interrupt go to rcuclassic.c, which then invokes
the corresponding functions in rcupreempt.c (with _rt suffix added to
keep the linker happy). Also applies the RCU_SOFTIRQ to classic RCU.
The bulk of this patch just moves code around, but likely increases
scheduling-clock latency.
If this patch does turn out to be the right approach, the #ifdefs in
kernel/rcuclassic.c might be dealt with. ;-) At current writing,
Gautham Shenoy's most recent CPU-hotplug fixes seem likely to obsolete
this patch (which would be a very good thing indeed!).
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]> (for RCU_SOFTIRQ)
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
include/linux/rcuclassic.h | 79 +
include/linux/rcupdate.h | 30 --
include/linux/rcupreempt.h | 27 ++--
kernel/Makefile|2
kernel/rcuclassic.c| 95 -
kernel/rcupdate.c | 22 --
kernel/rcupreempt.c| 50 +--
7 files changed, 158 insertions(+), 147 deletions(-)
diff -urpNa -X dontdiff linux-2.6.22-c-preemptrcu/include/linux/rcuclassic.h
linux-2.6.22-d-schedclassic/include/linux/rcuclassic.h
--- linux-2.6.22-c-preemptrcu/include/linux/rcuclassic.h2007-08-22
15:21:06.0 -0700
+++ linux-2.6.22-d-schedclassic/include/linux/rcuclassic.h 2007-08-22
17:49:35.0 -0700
@@ -42,80 +42,19 @@
#include
#include
-
-/* Global control variables for rcupdate callback mechanism. */
-struct rcu_ctrlblk {
- longcur;/* Current batch number. */
- longcompleted; /* Number of the last completed batch */
- int next_pending; /* Is the next batch already waiting? */
-
- int signaled;
-
- spinlock_t lockcacheline_internodealigned_in_smp;
- cpumask_t cpumask; /* CPUs that need to switch in order*/
-/* for current batch to proceed.*/
-} cacheline_internodealigned_in_smp;
-
-/* Is batch a before batch b ? */
-static inline int rcu_batch_before(long a, long b)
-{
- return (a - b) < 0;
-}
-
-/* Is batch a after batch b ? */
-static inline int rcu_batch_after(long a, long b)
-{
- return (a - b) > 0;
-}
+DECLARE_PER_CPU(int, rcu_data_bh_passed_quiesc);
/*
- * Per-CPU data for Read-Copy UPdate.
- * nxtlist - new callbacks are added here
- * curlist - current batch for which quiescent cycle started if any
- */
-struct rcu_data {
- /* 1) quiescent state handling : */
- longquiescbatch; /* Batch # for grace period */
- int passed_quiesc; /* User-mode/idle loop etc. */
- int qs_pending; /* core waits for quiesc state */
-
- /* 2) batch handling */
- longbatch; /* Batch # for current RCU batch */
- struct rcu_head *nxtlist;
- struct rcu_head **nxttail;
- longqlen;/* # of queued callbacks */
- struct rcu_head *curlist;
- struct rcu_head **curtail;
- struct rcu_head *donelist;
- struct rcu_head **donetail;
- longblimit; /* Upper limit on a processed batch */
- int cpu;
- struct rcu_head barrier;
-};
-
-DECLARE_PER_CPU(struct rcu_data, rcu_data);
-DECLARE_PER_CPU(struct rcu_data, rcu_bh_data);
-
-/*
- * Increment the quiescent state counter.
+ * Increment the bottom-half quiescent state counter.
* The counter is a bit degenerated: We do not need to know
* how many quiescent states passed, just if there was at least
* one since the start of the grace period. Thus just a flag.
*/
-static inline void rcu_qsctr_inc(int cpu)
-{
- struct rcu_data *rdp = _cpu(rcu_data, cpu);
- rdp->passed_quiesc = 1;
-}
static inline void rcu_bh_qsctr_inc(int cpu)
{
- struct rcu_data *rdp = _cpu(rcu_bh_data, cpu);
- rdp->passed_quiesc = 1;
+ per_cpu(rcu_data_bh_passed_quiesc, cpu) = 1;
}
-extern int rcu_pending(int cpu);
-extern int
[PATCH RFC 3/8] RCU: Preemptible RCU
Work in progress, not for inclusion.
This patch implements a new version of RCU which allows its read-side
critical sections to be preempted. It uses a set of counter pairs
to keep track of the read-side critical sections and flips them
when all tasks exit read-side critical section. The details
of this implementation can be found in this paper -
http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf
This patch was developed as a part of the -rt kernel development and
meant to provide better latencies when read-side critical sections of
RCU don't disable preemption. As a consequence of keeping track of RCU
readers, the readers have a slight overhead (optimizations in the paper).
This implementation co-exists with the "classic" RCU implementations
and can be switched to at compiler.
Also includes RCU tracing summarized in debugfs and RCU_SOFTIRQ for
the preemptible variant of RCU.
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]> (for RCU_SOFTIRQ)
Signed-off-by: Paul McKenney <[EMAIL PROTECTED]>
---
include/linux/interrupt.h|1
include/linux/rcuclassic.h |2
include/linux/rcupdate.h |7
include/linux/rcupreempt.h | 78 +++
include/linux/rcupreempt_trace.h | 100 +
include/linux/sched.h|5
kernel/Kconfig.preempt | 38 +
kernel/Makefile |7
kernel/fork.c|4
kernel/rcupreempt.c | 767 +++
kernel/rcupreempt_trace.c| 330
11 files changed, 1336 insertions(+), 3 deletions(-)
diff -urpNa -X dontdiff linux-2.6.22-b-fixbarriers/include/linux/interrupt.h
linux-2.6.22-c-preemptrcu/include/linux/interrupt.h
--- linux-2.6.22-b-fixbarriers/include/linux/interrupt.h2007-07-08
16:32:17.0 -0700
+++ linux-2.6.22-c-preemptrcu/include/linux/interrupt.h 2007-08-22
15:21:06.0 -0700
@@ -269,6 +269,7 @@ enum
#ifdef CONFIG_HIGH_RES_TIMERS
HRTIMER_SOFTIRQ,
#endif
+ RCU_SOFTIRQ,/* Preferable RCU should always be the last softirq */
};
/* softirq mask and active fields moved to irq_cpustat_t in
diff -urpNa -X dontdiff linux-2.6.22-b-fixbarriers/include/linux/rcuclassic.h
linux-2.6.22-c-preemptrcu/include/linux/rcuclassic.h
--- linux-2.6.22-b-fixbarriers/include/linux/rcuclassic.h 2007-08-22
14:42:23.0 -0700
+++ linux-2.6.22-c-preemptrcu/include/linux/rcuclassic.h2007-08-22
15:21:06.0 -0700
@@ -142,8 +142,6 @@ extern int rcu_needs_cpu(int cpu);
extern void __rcu_init(void);
extern void rcu_check_callbacks(int cpu, int user);
extern void rcu_restart_cpu(int cpu);
-extern long rcu_batches_completed(void);
-extern long rcu_batches_completed_bh(void);
#endif /* __KERNEL__ */
#endif /* __LINUX_RCUCLASSIC_H */
diff -urpNa -X dontdiff linux-2.6.22-b-fixbarriers/include/linux/rcupdate.h
linux-2.6.22-c-preemptrcu/include/linux/rcupdate.h
--- linux-2.6.22-b-fixbarriers/include/linux/rcupdate.h 2007-07-19
14:02:36.0 -0700
+++ linux-2.6.22-c-preemptrcu/include/linux/rcupdate.h 2007-08-22
15:21:06.0 -0700
@@ -52,7 +52,11 @@ struct rcu_head {
void (*func)(struct rcu_head *head);
};
+#ifdef CONFIG_CLASSIC_RCU
#include
+#else /* #ifdef CONFIG_CLASSIC_RCU */
+#include
+#endif /* #else #ifdef CONFIG_CLASSIC_RCU */
#define RCU_HEAD_INIT { .next = NULL, .func = NULL }
#define RCU_HEAD(head) struct rcu_head head = RCU_HEAD_INIT
@@ -218,10 +222,13 @@ extern void FASTCALL(call_rcu_bh(struct
/* Exported common interfaces */
extern void synchronize_rcu(void);
extern void rcu_barrier(void);
+extern long rcu_batches_completed(void);
+extern long rcu_batches_completed_bh(void);
/* Internal to kernel */
extern void rcu_init(void);
extern void rcu_check_callbacks(int cpu, int user);
+extern int rcu_needs_cpu(int cpu);
#endif /* __KERNEL__ */
#endif /* __LINUX_RCUPDATE_H */
diff -urpNa -X dontdiff linux-2.6.22-b-fixbarriers/include/linux/rcupreempt.h
linux-2.6.22-c-preemptrcu/include/linux/rcupreempt.h
--- linux-2.6.22-b-fixbarriers/include/linux/rcupreempt.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.22-c-preemptrcu/include/linux/rcupreempt.h2007-08-22
15:21:06.0 -0700
@@ -0,0 +1,78 @@
+/*
+ * Read-Copy Update mechanism for mutual exclusion (RT implementation)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General
[PATCH RFC 2/8] RCU: Fix barriers
Work in progress, not for inclusion. Fix rcu_barrier() to work properly in preemptive kernel environment. Also, the ordering of callback must be preserved while moving callbacks to another CPU during CPU hotplug. Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]> Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]> --- rcuclassic.c |2 +- rcupdate.c | 10 ++ 2 files changed, 11 insertions(+), 1 deletion(-) diff -urpNa -X dontdiff linux-2.6.22-a-splitclassic/kernel/rcuclassic.c linux-2.6.22-b-fixbarriers/kernel/rcuclassic.c --- linux-2.6.22-a-splitclassic/kernel/rcuclassic.c 2007-07-19 15:03:51.0 -0700 +++ linux-2.6.22-b-fixbarriers/kernel/rcuclassic.c 2007-07-19 17:10:46.0 -0700 @@ -349,9 +349,9 @@ static void __rcu_offline_cpu(struct rcu if (rcp->cur != rcp->completed) cpu_quiet(rdp->cpu, rcp); spin_unlock_bh(>lock); + rcu_move_batch(this_rdp, rdp->donelist, rdp->donetail); rcu_move_batch(this_rdp, rdp->curlist, rdp->curtail); rcu_move_batch(this_rdp, rdp->nxtlist, rdp->nxttail); - rcu_move_batch(this_rdp, rdp->donelist, rdp->donetail); } static void rcu_offline_cpu(int cpu) diff -urpNa -X dontdiff linux-2.6.22-a-splitclassic/kernel/rcupdate.c linux-2.6.22-b-fixbarriers/kernel/rcupdate.c --- linux-2.6.22-a-splitclassic/kernel/rcupdate.c 2007-07-19 14:19:03.0 -0700 +++ linux-2.6.22-b-fixbarriers/kernel/rcupdate.c2007-07-19 17:13:31.0 -0700 @@ -115,7 +115,17 @@ void rcu_barrier(void) mutex_lock(_barrier_mutex); init_completion(_barrier_completion); atomic_set(_barrier_cpu_count, 0); + /* +* The queueing of callbacks in all CPUs must be atomic with +* respect to RCU, otherwise one CPU may queue a callback, +* wait for a grace period, decrement barrier count and call +* complete(), while other CPUs have not yet queued anything. +* So, we need to make sure that grace periods cannot complete +* until all the callbacks are queued. +*/ + rcu_read_lock(); on_each_cpu(rcu_barrier_func, NULL, 0, 1); + rcu_read_unlock(); wait_for_completion(_barrier_completion); mutex_unlock(_barrier_mutex); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 RFC 1/8] RCU: Split API to permit multiple RCU implementations
Work in progress, not for inclusion.
This patch re-organizes the RCU code to enable multiple implementations
of RCU. Users of RCU continues to include rcupdate.h and the
RCU interfaces remain the same. This is in preparation for
subsequently merging the preemptible RCU implementation.
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
include/linux/rcuclassic.h | 149 +++
include/linux/rcupdate.h | 151 +++-
kernel/Makefile|2
kernel/rcuclassic.c| 558
kernel/rcupdate.c | 561 ++---
5 files changed, 779 insertions(+), 642 deletions(-)
diff -urpNa -X dontdiff linux-2.6.22/include/linux/rcuclassic.h
linux-2.6.22-a-splitclassic/include/linux/rcuclassic.h
--- linux-2.6.22/include/linux/rcuclassic.h 1969-12-31 16:00:00.0
-0800
+++ linux-2.6.22-a-splitclassic/include/linux/rcuclassic.h 2007-08-22
14:42:23.0 -0700
@@ -0,0 +1,149 @@
+/*
+ * Read-Copy Update mechanism for mutual exclusion (classic version)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright IBM Corporation, 2001
+ *
+ * Author: Dipankar Sarma <[EMAIL PROTECTED]>
+ *
+ * Based on the original work by Paul McKenney <[EMAIL PROTECTED]>
+ * and inputs from Rusty Russell, Andrea Arcangeli and Andi Kleen.
+ * Papers:
+ * http://www.rdrop.com/users/paulmck/paper/rclockpdcsproof.pdf
+ * http://lse.sourceforge.net/locking/rclock_OLS.2001.05.01c.sc.pdf (OLS2001)
+ *
+ * For detailed explanation of Read-Copy Update mechanism see -
+ * Documentation/RCU
+ *
+ */
+
+#ifndef __LINUX_RCUCLASSIC_H
+#define __LINUX_RCUCLASSIC_H
+
+#ifdef __KERNEL__
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+/* Global control variables for rcupdate callback mechanism. */
+struct rcu_ctrlblk {
+ longcur;/* Current batch number. */
+ longcompleted; /* Number of the last completed batch */
+ int next_pending; /* Is the next batch already waiting? */
+
+ int signaled;
+
+ spinlock_t lockcacheline_internodealigned_in_smp;
+ cpumask_t cpumask; /* CPUs that need to switch in order*/
+/* for current batch to proceed.*/
+} cacheline_internodealigned_in_smp;
+
+/* Is batch a before batch b ? */
+static inline int rcu_batch_before(long a, long b)
+{
+ return (a - b) < 0;
+}
+
+/* Is batch a after batch b ? */
+static inline int rcu_batch_after(long a, long b)
+{
+ return (a - b) > 0;
+}
+
+/*
+ * Per-CPU data for Read-Copy UPdate.
+ * nxtlist - new callbacks are added here
+ * curlist - current batch for which quiescent cycle started if any
+ */
+struct rcu_data {
+ /* 1) quiescent state handling : */
+ longquiescbatch; /* Batch # for grace period */
+ int passed_quiesc; /* User-mode/idle loop etc. */
+ int qs_pending; /* core waits for quiesc state */
+
+ /* 2) batch handling */
+ longbatch; /* Batch # for current RCU batch */
+ struct rcu_head *nxtlist;
+ struct rcu_head **nxttail;
+ longqlen;/* # of queued callbacks */
+ struct rcu_head *curlist;
+ struct rcu_head **curtail;
+ struct rcu_head *donelist;
+ struct rcu_head **donetail;
+ longblimit; /* Upper limit on a processed batch */
+ int cpu;
+ struct rcu_head barrier;
+};
+
+DECLARE_PER_CPU(struct rcu_data, rcu_data);
+DECLARE_PER_CPU(struct rcu_data, rcu_bh_data);
+
+/*
+ * Increment the quiescent state counter.
+ * The counter is a bit degenerated: We do not need to know
+ * how many quiescent states passed, just if there was at least
+ * one since the start of the grace period. Thus just a flag.
+ */
+static inline void rcu_qsctr_inc(int cpu)
+{
+ struct rcu_data *rdp = _cpu(rcu_data, cpu);
+ rdp->passed_quiesc = 1;
+}
+static inline void rcu_bh_qsctr_inc(int cpu)
+{
+ struct rcu_data *rdp = _cpu(rcu_bh_data, cpu);
+ rdp->passed_quiesc = 1;
+}
+
+extern int
Re: sk98lin for 2.6.23-rc1
> However, it really DOES lock up under load. I even > tried 2.6.23-rc4 and the absolute latest version of > the > driver and it still locks up, as in > Yich. I'm glad I'm still using sk98lin on my unmanned colo box. Kyle - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 RFC 0/8] RCU: Preemptible RCU
Work in progress, still not for inclusion. This is a respin of the following prior postings: http://lkml.org/lkml/2007/8/7/276 (the four initial preemptible RCU patches) http://lkml.org/lkml/2007/8/17/262 (hotplug CPU for preemptible RCU) http://lkml.org/lkml/2007/8/22/348 (RCU priority boosting) http://lkml.org/lkml/2007/8/22/373 (rcutorture for RCU priority boosting) This release adds an additional patch that makes the RCU priority booster more friendly to power-savings measures by causing the booster task to sleep if there is no cause to believe that priority boosting will be required in the near future. An additional fixup and documentation patch is forthcoming. And of course, the whole thing will be rebased to a more recent version of Linux. These patches take prior feedback into account, including the bit about running checkpatch.pl. ;-) Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] knfsd: Validate filehandle type in fsid_source
From: Neil Brown <[EMAIL PROTECTED]> fsid_source decided where to get the 'fsid' number to return for a GETATTR based on the type of filehandle. It can be from the device, from the fsid, or from the UUID. It is possible for the filehandle to be inconsistent with the export information, so make sure the export information actually has the info implied by the value returned by fsid_source. Signed-off-by: Neil Brown <[EMAIL PROTECTED]> Cc: "Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> Signed-off-by: "J. Bruce Fields" <[EMAIL PROTECTED]> --- fs/nfsd/nfsfh.c | 20 +++- 1 files changed, 15 insertions(+), 5 deletions(-) diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c index 0eb464a..7011d62 100644 --- a/fs/nfsd/nfsfh.c +++ b/fs/nfsd/nfsfh.c @@ -566,13 +566,23 @@ enum fsid_source fsid_source(struct svc_fh *fhp) case FSID_DEV: case FSID_ENCODE_DEV: case FSID_MAJOR_MINOR: - return FSIDSOURCE_DEV; + if (fhp->fh_export->ex_dentry->d_inode->i_sb->s_type->fs_flags + & FS_REQUIRES_DEV) + return FSIDSOURCE_DEV; + break; case FSID_NUM: - return FSIDSOURCE_FSID; - default: if (fhp->fh_export->ex_flags & NFSEXP_FSID) return FSIDSOURCE_FSID; - else - return FSIDSOURCE_UUID; + break; + default: + break; } + /* either a UUID type filehandle, or the filehandle doesn't +* match the export. +*/ + if (fhp->fh_export->ex_flags & NFSEXP_FSID) + return FSIDSOURCE_FSID; + if (fhp->fh_export->ex_uuid) + return FSIDSOURCE_UUID; + return FSIDSOURCE_DEV; } -- 1.5.3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] knfsd: Fixed problem with NFS exporting directories which are mounted on.
From: Neil Brown <[EMAIL PROTECTED]>
Recent changes in NFSd cause a directory which is mounted-on
to not appear properly when the filesystem containing it is exported.
*exp_get* not returns -ENOENT rather than NULL and when
commit 5d3dbbeaf56d0365ac6b5c0a0da0bd31cc4781e1
removed the NULL checks, it didn't add a check for -ENOENT.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
---
fs/nfsd/vfs.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index a0c2b25..7867151 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -115,7 +115,8 @@ nfsd_cross_mnt(struct svc_rqst *rqstp, struct dentry **dpp,
exp2 = rqst_exp_get_by_name(rqstp, mnt, mounts);
if (IS_ERR(exp2)) {
- err = PTR_ERR(exp2);
+ if (PTR_ERR(exp2) != -ENOENT)
+ err = PTR_ERR(exp2);
dput(mounts);
mntput(mnt);
goto out;
--
1.5.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
nfsd patches for 2.6.23
We've got two nfsd patches that fix a regression and a possible oops, so both should probably go in before the 2.6.23 release. Patches will follow, but they're also available from "for-linus" at: ssh://linux-nfs.org/~bfields/exports/linux.git for-linus --b. Neil Brown (2): knfsd: Fixed problem with NFS exporting directories which are mounted on. knfsd: Validate filehandle type in fsid_source fs/nfsd/nfsfh.c | 20 +++- fs/nfsd/vfs.c |3 ++- 2 files changed, 17 insertions(+), 6 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-rc4-mm1 - git-alsa.patch breaks audio on Dell Latitude D820
On Wed, 05 Sep 2007 22:27:35 +0200, Takashi Iwai said: > BTW, there are 10 different models to test for Dell with STAC9200 > (dell-d2[1-3] and dell-m2[1-7], see modprobe snd_hda_intel model=dell-m23 was the magic incantation. I'm sure that every user who trips over this is going to call it a regression, since the -rc3-mm1 module was able to get it right without hints. ;) pgpW2z6YZ9A2A.pgp Description: PGP signature
[Patch] Add support for PCMCIA card Sierra WIreless AC850
Hi,
This patch adds support for Sierra Wireless AC850 which has the same Ids
as the AC710/750 but has a different firmware.
PS: Please CC answer as I've not subscribed to the list.
BR,
--
Eric Leblond <[EMAIL PROTECTED]>
INL SARL
Signed-off-by: Eric Leblond <[EMAIL PROTECTED]>
---
drivers/serial/serial_cs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/serial_cs.c b/drivers/serial/serial_cs.c
index a0ea435..f0e9ba6 100644
--- a/drivers/serial/serial_cs.c
+++ b/drivers/serial/serial_cs.c
@@ -911,6 +911,7 @@ static struct pcmcia_device_id serial_ids[] = {
PCMCIA_MFC_DEVICE_CIS_MANF_CARD(1, 0x0175, 0x, "DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_MANF_CARD(1, 0x0101, 0x0035, "3CXEM556.cis"),
PCMCIA_MFC_DEVICE_CIS_MANF_CARD(1, 0x0101, 0x003d, "3CXEM556.cis"),
+ PCMCIA_DEVICE_CIS_PROD_ID12("Sierra Wireless", "AC850", 0xd85f6206,
0x42a2c018, "SW_8xx_SER.cis"), /* Sierra Wireless AC850 3G Network Adapter R1
*/
PCMCIA_DEVICE_CIS_MANF_CARD(0x0192, 0x0710, "SW_7xx_SER.cis"), /*
Sierra Wireless AC710/AC750 GPRS Network Adapter R1 */
PCMCIA_DEVICE_CIS_MANF_CARD(0x0192, 0xa555, "SW_555_SER.cis"), /*
Sierra Aircard 555 CDMA 1xrtt Modem -- pre update */
PCMCIA_DEVICE_CIS_MANF_CARD(0x013f, 0xa555, "SW_555_SER.cis"), /*
Sierra Aircard 555 CDMA 1xrtt Modem -- post update */
--
1.4.4.4
signature.asc
Description: Ceci est une partie de message numériquement signée
Linux 2.6.23-rc5-git1-krf1 (known regressions fixes)
Hi, There are a few patches for regressions that was not merged yet. Subject : 8250 claims non existing device blocking IO port References : http://lkml.org/lkml/2007/8/18/20 Last known good : ? Submitter : Andrey Borzenkov <[EMAIL PROTECTED]> Caused-By : ? Handled-By : Bjorn Helgaas <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/8/21/291 Status : patch available Subject : Oops while modprobing phy fixed module References : http://lkml.org/lkml/2007/7/14/63 Last known good : ? Submitter : Gabriel C <[EMAIL PROTECTED]> Caused-By : ? Handled-By : Satyam Sharma <[EMAIL PROTECTED]> Vitaly Bordug <[EMAIL PROTECTED]> Patch1 : http://lkml.org/lkml/2007/7/18/506 Status : patch available Subject : NFSv3 server error in LOOKUP after READDIRPLUS Call References : http://bugzilla.kernel.org/show_bug.cgi?id=8966 Last known good : ? Submitter : Peter Kovar <[EMAIL PROTECTED]> Caused-By : ? Handled-By : Neil Brown <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=12689 Status : patch available Subject : linux-2.6.23-rc4 ppc build failure References : http://lkml.org/lkml/2007/8/29/154 Last known good : ? Submitter : Bret Towe <[EMAIL PROTECTED]> Caused-By : ? Handled-By : Tony Breeds <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/8/31/1 Status : patch was suggested Subject : Unable to access memory card reader anymore References : http://bugzilla.kernel.org/show_bug.cgi?id=8885 Last known good : ? Submitter : Christian Casteyde <[EMAIL PROTECTED]> Caused-By : ? Handled-By : Alan Stern <[EMAIL PROTECTED]> Patch : http://bugzilla.kernel.org/attachment.cgi?id=12438 Status : patch available Subject : error: implicit declaration of function 'cfi_interleave' References : http://lkml.org/lkml/2007/8/6/272 Last known good : ? Submitter : Ingo Molnar <[EMAIL PROTECTED]> Caused-By : ? Handled-By : David Woodhouse <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/8/9/586 Status : patch available http://www.stardust.webpages.pl/files/patches/krf/2.6.23-rc5-git1/ Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Fix (improve) deadlock condition on module removal netfilter socket option removal
On Thu, 2007-09-06 at 06:51 +1000, Rusty Russell wrote: > On Wed, 2007-09-05 at 15:27 -0400, Neil Horman wrote: > > On Thu, Sep 06, 2007 at 03:41:37AM +1000, Rusty Russell wrote: > > > You have this backwards: O_NONBLOCK is the default. That seems to be > > > what everyone wants, although I implemented 'rmmod -w' because it seemed > > > like a good option. > > > > > Thats really the point I'm trying to make. O_NONBLOCK should be the > > default, > > but it isn't in the case of modprobe. > > Ouch, you're right! I've applied, tagged, and updated http://www.kernel.org/pub/linux/kernel/people/jcm/module-init-tools/devel/module-init-tools.git I also moved the remaining files over from kerneltools.org. Will update tarballs later...FWIW, there are a couple of outstanding patches to libify module-init-tools that I'm still looking at before pushing. Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Fix (improve) deadlock condition on module removal netfilter socket option removal
On Wed, 2007-09-05 at 15:27 -0400, Neil Horman wrote: > On Thu, Sep 06, 2007 at 03:41:37AM +1000, Rusty Russell wrote: > > You have this backwards: O_NONBLOCK is the default. That seems to be > > what everyone wants, although I implemented 'rmmod -w' because it seemed > > like a good option. > > > Thats really the point I'm trying to make. O_NONBLOCK should be the default, > but it isn't in the case of modprobe. Ouch, you're right! And that's been around for a *long* time. From the original 0.9.2 version (Dec 9th 2002). ChangeLog says: Jim Radford <[EMAIL PROTECTED]>'s modprobe -r implementation. The userspace check still stops most cases of removing used modules. On the bright side, this one bug has probably done more to deprecate module removal than any thing else, by making it unreliable... Good catch! 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 3/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 07:40:15PM +0100, Denys Vlasenko wrote: > On Wednesday 05 September 2007 14:55, Denys Vlasenko wrote: > > Part 3: > > > > Makefile: > > init/Kconfig: > > add config DISCARD_UNUSED_SECTIONS with appropriate > > big scary warning. It enables gcc and ld options > > for section garbage collection. > > At it typically happens, last-minute "obviously correct" change was a mistake. > > This doesn't work as intended: > > LDFLAGS_vmlinux += $(call ld-option, --gc-sections) > > With the above line, --gc-sections doesn't get added, > and vmlinux is not garbage collected. Did you find out why it does not work? > > It must be > > LDFLAGS_vmlinux += --gc-sections Doing a normal kernel build will link vmlinux three or four times. If we introduce --gc-sections we should add a preparational link of vmlinux where we use --gc-sections and skip it for the rest of the links assuming that --gc-sections takes some time for ld to do. I have already tried to introduce such a preparatioanl link of vmlinux - patch attached. I skipped this patch because suprisingly it was no win for a kernelbuild. ld seems not to be more effective using a prelinked vmlinux.o compared to several .o files. I know ths prelinked vmlinux.o does not include the init stuff but that is so little that it is not interesting for your patch. Sam diff --git a/Makefile b/Makefile index 350dedb..2cc0fd7 100644 --- a/Makefile +++ b/Makefile @@ -592,7 +592,7 @@ libs-y := $(libs-y1) $(libs-y2) # +-< $(vmlinux-init) # | +--< init/version.o + more # | -# +--< $(vmlinux-main) +# +--< vmlinux.o # |+--< driver/built-in.o mm/built-in.o + more # | # +-< kallsyms.o (see description in CONFIG_KALLSYMS section) @@ -608,17 +608,16 @@ libs-y:= $(libs-y1) $(libs-y2) vmlinux-init := $(head-y) $(init-y) vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) -vmlinux-all := $(vmlinux-init) $(vmlinux-main) vmlinux-lds := arch/$(ARCH)/kernel/vmlinux.lds -export KBUILD_VMLINUX_OBJS := $(vmlinux-all) +export KBUILD_VMLINUX_OBJS := $(vmlinux-init) vmlinux.o # Rule to link vmlinux - also used during CONFIG_KALLSYMS # May be overridden by arch/$(ARCH)/Makefile quiet_cmd_vmlinux__ ?= LD $@ cmd_vmlinux__ ?= $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \ -T $(vmlinux-lds) $(vmlinux-init) \ - --start-group $(vmlinux-main) --end-group \ - $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) vmlinux.o FORCE ,$^) + --start-group vmlinux.o --end-group\ + $(filter-out $(vmlinux-lds) $(vmlinux-init) vmlinux.o FORCE ,$^) # Generate new vmlinux version quiet_cmd_vmlinux_version = GEN .version @@ -718,13 +717,13 @@ quiet_cmd_kallsyms = KSYM$@ $(call cmd,kallsyms) # .tmp_vmlinux1 must be complete except kallsyms, so update vmlinux version -.tmp_vmlinux1: $(vmlinux-lds) $(vmlinux-all) FORCE +.tmp_vmlinux1: $(vmlinux-lds) $(vmlinux-init) vmlinux.o FORCE $(call if_changed_rule,ksym_ld) -.tmp_vmlinux2: $(vmlinux-lds) $(vmlinux-all) .tmp_kallsyms1.o FORCE +.tmp_vmlinux2: $(vmlinux-lds) $(vmlinux-init) vmlinux.o .tmp_kallsyms1.o FORCE $(call if_changed,vmlinux__) -.tmp_vmlinux3: $(vmlinux-lds) $(vmlinux-all) .tmp_kallsyms2.o FORCE +.tmp_vmlinux3: $(vmlinux-lds) $(vmlinux-init) vmlinux.o .tmp_kallsyms2.o FORCE $(call if_changed,vmlinux__) # Needs to visit scripts/ before $(KALLSYMS) can be used. @@ -742,31 +741,22 @@ debug_kallsyms: .tmp_map$(last_kallsyms) endif # ifdef CONFIG_KALLSYMS -# Do modpost on a prelinked vmlinux. The finally linked vmlinux has -# relevant sections renamed as per the linker script. -quiet_cmd_vmlinux-modpost = LD $@ - cmd_vmlinux-modpost = $(LD) $(LDFLAGS) -r -o $@ \ -$(vmlinux-init) --start-group $(vmlinux-main) --end-group \ -$(filter-out $(vmlinux-init) $(vmlinux-main) $(vmlinux-lds) FORCE ,$^) -define rule_vmlinux-modpost - : - +$(call cmd,vmlinux-modpost) - $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost $@ - $(Q)echo 'cmd_$@ := $(cmd_vmlinux-modpost)' > $(dot-target).cmd -endef +# Link the kernel except init parts - for use in subsequent links +quiet_cmd_vmlinux-main = LD $@ + cmd_vmlinux-main = $(LD) $(LDFLAGS) -r -o $@ \ +--start-group $(filter-out FORCE, $^) --end-group + +vmlinux.o: $(vmlinux-main) FORCE + $(call if_changed,vmlinux-main) # vmlinux image - including updated kernel symbols -vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) $(kallsyms.o) vmlinux.o FORCE +vmlinux: $(vmlinux-lds) $(vmlinux-init) $(kallsyms.o) vmlinux.o FORCE ifdef CONFIG_HEADERS_CHECK $(Q)$(MAKE) -f $(srctree)/Makefile headers_check endif - $(call vmlinux-modpost) $(call if_changed_rule,vmlinux__) $(Q)rm -f .old_version -vmlinux.o: $(vmlinux-lds)
Re: [PATCH][RFC]: pte notifiers -- support for external page tables
[resend due to broken cc list in my original post] Jack Steiner wrote: On Wed, Sep 05, 2007 at 07:38:48PM +0300, Avi Kivity wrote: Some hardware and software systems maintain page tables outside the normal Linux page tables, which reference userspace memory. This includes Infiniband, other RDMA-capable devices, and kvm (with a pending patch). I like it. We have 2 special devices with external TLBs that can take advantage of this. One suggestion - at least for what we need. Can the notifier be registered against the mm_struct instead of (or in addition to) the vma? Yes. It's a lot simpler since this way we don't have to support vma creation/splitting/merging/destruction. There's a tiny performance hit for kvm, but it isn't worth the bother. Will implement for v2 of this patch. -- Any sufficiently difficult bug is indistinguishable from a feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.23-rc4 ppc build failure
On Friday 31 August 2007, Tony Breeds wrote: > On Thu, Aug 30, 2007 at 02:56:50PM -0700, Bret Towe wrote: > > On 8/29/07, Bret Towe <[EMAIL PROTECTED]> wrote: > > > while trying to build a fresh kernel for my mini after upgrading from > > > gutsy > > > (and forgetting to save my .config) I hit the below build error > > > 2.6.23-rc3 I did work under feisty but that is with a different .config > > > so not sure if that makes any difference or not > > > I've not bisected cause it takes so long on this computer... > > > attached is the config I'm working off now > > So how did you generate the new .config? Did you start with a defconfig > of some sort and then alter to personal taste? The problem might be related with switching CONFIG_IDE to use menuconfig. > I ask because if we have other users our there that have working system > with BLK_DEV_IDE=m it'd be nice to have make oldconfig fix them. If > it's just a matter of not letting people get into that state then > something like the patch below will probably help. Unlikely that there are working BLK_DEV_IDE=m setups - these missing symbols (pmac_ide_get_base and friends) have never been exported (IIRC). > Ensure that BLK_DEV_IDE is built-in befoer allowing BLK_DEV_IDE_PMAC to > be selected. > > Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> applied with s/befoer/before/ as spotted by Bret > --- > > drivers/ide/Kconfig |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig > index e049f65..e55be26 100644 > --- a/drivers/ide/Kconfig > +++ b/drivers/ide/Kconfig > @@ -780,7 +780,7 @@ endif > > config BLK_DEV_IDE_PMAC > bool "Builtin PowerMac IDE support" > - depends on PPC_PMAC && IDE=y > + depends on PPC_PMAC && IDE=y && BLK_DEV_IDE=y > help > This driver provides support for the built-in IDE controller on > most of the recent Apple Power Macintoshes and PowerBooks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Override 80-wire cable detection for Toshiba S1800-814 (resend)
On Friday 31 August 2007, Daniel Exner wrote: > Hi! > > Please CC me, as I'm currently not subscribed to this list, thx. applied but please inline patches instead of attaching them next time (makes it much easier to review/apply them) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Clock trouble retest results with 2.6.23-rc4-mm1 (was: 2.6.23-rc3-mm1)
Am 25.08.2007 05:30 schrieb Andrew Morton: > On Sat, 25 Aug 2007 02:47:59 +0200 Tilman Schmidt <[EMAIL PROTECTED]> wrote: - on console early during boot, also in SuSE's /var/log/boot.msg: your system time is not correct: Wed Jul 13 13:15:31 UTC 1910 setting system time to: Tue Jul 24 00:00:00 UTC 2007 With 2.6.23-rc4-mm1 this doesn't happen anymore, so whatever it was seems to be fixed. >> --- /tmp/bootmsg-2.6.23-rc3 2007-08-25 02:25:54.0 +0200 >> +++ /tmp/bootmsg-2.6.23-rc3-mm1 2007-08-25 02:26:08.0 +0200 [...] >> <6>..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 >> -<6>checking TSC synchronization [CPU#0 -> CPU#1]: passed. >> +<6>checking TSC synchronization [CPU#0 -> CPU#1]: >> +<4>Measured 32 cycles TSC warp between CPUs, turning off TSC clock. >> +<4>Marking TSC unstable due to: check_tsc_sync_source failed. This still happens identically with 2.6.23-rc4-mm1. Mainline kernels like my TSC, -mm kernels don't. >> -<7>hpet_resources: 0xfed0 is busy >> +<4>hpet_acpi_add: no address or irqs in _CRS > > oh boy 2.6.23-rc4-mm1 reverts to mainline behaviour here. (ie. "busy" instead of "no address or irqs") Dunno if that's good or bad. >> +<4>thermal: Unknown symbol acpi_processor_set_thermal_limit > > I think there are acpi fixes in Len's latest tree which will fix this. Gone in 2.6.23-rc4-mm1. HTH Tilman -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [PATCH] Fix preemptible lazy mode bug
On Thu, 2007-08-23 at 22:46 -0700, Zachary Amsden wrote: > I recently sent off a fix for lazy vmalloc faults which can happen under > paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a > bit on fixing this. I neglected to notice that since the new call to > flush the MMU update queue is called from the page fault handler, it can > be pre-empted. Both VMI and Xen use per-cpu variables to track lazy > mode state, as all previous calls to set, disable, or flush lazy mode > happened from a non-preemptable state. Hi Zach, I don't think this patch does anything. The flush is because we want the just-completed "set_pte" to have immediate effect, so if preempt is enabled we're already screwed because we can be moved between set_pte and the arch_flush_lazy_mmu_mode() call. Now, where's the problem caller? By my reading or rc4, vmalloc faults are fixed up before enabling interrupts. Confused, 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: 2.4.35.1 md problem
On Wed, Sep 05, 2007 at 03:45:45PM +0200, Beschorner Daniel wrote: > I got a strange problem after I updated from 2.4.34.4 to 2.4.35.1: > > The kernel raid autodetection assembles my 2 raid-1 arrays, but mdstat > shows "0 blocks" for each md. > So the filesystem check complains about no valid superblock, but the > arrays seem to run fine. > After raidstop/raidstart the blocks are displayed correctly and all is > fine. > But this is no solution, because the root fs is raid. > > Could it be a compiler issue, I assume there is no change in raid since > 2.4.34?!? > > I use GCC 4.1.2 and no LVM. Also, I forgot one important thing: could you please send me your .config ? Thanks in advance, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc4-mm1 - git-alsa.patch breaks audio on Dell Latitude D820
At Wed, 05 Sep 2007 22:11:20 +0200, I wrote: > > At Wed, 05 Sep 2007 15:46:34 -0400, > [EMAIL PROTECTED] wrote: > > > > On Fri, 31 Aug 2007 21:58:22 PDT, Andrew Morton said: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ > > > > git-alsa.patch breaks audio on my laptop, worked fine in -rc3-mm1. Almost > > certainly bustification in the Intel HDA rewrite. > > > > Symptoms: alsamixer finds the chipset, can adjust the volumes and > > mute/unmute, > > and /usr/bin/play is able to write a .wav to the ALSA device without > > complaint. > > However, no sound actually comes out. Very "lights are on but nobody is > > home". > > > > Dell Latitude D820, lspci reports: > > > > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > > Definition Audio Controller (rev 01) > > and alsamixer reports finding a "SigmaTel STAC9200" > > > > % grep HDA_ .config > > CONFIG_SND_HDA_INTEL=y > > # CONFIG_SND_HDA_HWDEP is not set > > CONFIG_SND_HDA_CODEC_REALTEK=y > > CONFIG_SND_HDA_CODEC_ANALOG=y > > CONFIG_SND_HDA_CODEC_SIGMATEL=y > > # CONFIG_SND_HDA_CODEC_VIA is not set > > # CONFIG_SND_HDA_CODEC_ATIHDMI is not set > > # CONFIG_SND_HDA_CODEC_CONEXANT is not set > > # CONFIG_SND_HDA_CODEC_CMEDIA is not set > > # CONFIG_SND_HDA_CODEC_SI3054 is not set > > CONFIG_SND_HDA_GENERIC=y > > # CONFIG_SND_HDA_POWER_SAVE is not set > > > > dmesg under -rc4-mm1: > > Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 > > 09:12:58 2007 UTC). > > ACPI: PCI Interrupt :00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21 > > hda_intel: position_fix set to 1 for device 1028:01cc > > ALSA device list: > > #0: HDA Intel at 0xefffc000 irq 506 > > > > dmesg under -rc3-mm1: > > > > Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 > > 09:12:58 2007 UTC). > > ACPI: PCI Interrupt :00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21 > > hda_intel: position_fix set to 1 for device 1028:01cc > > ALSA device list: > > #0: HDA Intel at 0xefffc000 irq 506 > > > > (Yes, they look the same to me, too...) > > > > I'd provide more info, if I had a clue what else to add... > > First, check /proc/asound/card0/codec#* whether STAC9200 is identified > properly? If yes, check the mixer contents (at best, run > "alsactl -f somefile store"), see whether "Master Playback Volume" is > raised, "Master Playback Switch" unmuted, "Front..." raised/unmuted, > and "PCM ..." raised/unmuted, etc. > > If this still doesn't work, try to give model=ref option to > snd-hda-intel. BTW, there are 10 different models to test for Dell with STAC9200 (dell-d2[1-3] and dell-m2[1-7], see Documentation/sound/alsa/ALSA-Configuration.txt), so I recommend to build it as a module so that you can save the boot time :) Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Fix (improve) deadlock condition on module removal netfilter socket option removal
On Tue, 2007-09-04 at 16:30 -0400, Neil Horman wrote: > 2nd of two patches. This patch enhances modprobe to operate like rmmod > in non-blocking mode. It also adds a -w option to allow for explicit blocking > operation. As I suspected, this patch isn't in the tree. I am going to commit it now because it makes sense. I'm also going to sort out moving things to kernel.org this afternoon while I'm at it - I don't want to confuse people with kerneltools.org any more now I've got a kernel.org acc. Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [PATCH][RFC] pte notifiers -- support for external page tables
Rusty Russell wrote: On Wed, 2007-09-05 at 22:32 +0300, Avi Kivity wrote: [resend due to bad alias expansion resulting in some recipients being bogus] Some hardware and software systems maintain page tables outside the normal Linux page tables, which reference userspace memory. This includes Infiniband, other RDMA-capable devices, and kvm (with a pending patch). And lguest. I can't tell until I've actually implemented it, but I think it will seriously reduce the need for page pinning which is why only root can currently launch guests. Ah yes, lguest. My concern is locking: this is called with the page lock held, and I guess we have to bump the guest out if it's currently running. This will complicate kvm's locking too. We usually take kvm->lock to do mmu ops, but that is now a mutex. -- Any sufficiently difficult bug is indistinguishable from a feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Fix (improve) deadlock condition on module removal netfilter socket option removal
On Wed, 2007-09-05 at 15:27 -0400, Neil Horman wrote: > Now, I suppose its possible that I've not been looking at the right source > tree > when doing my work. I've based my modprobe patch on this git tree: > http://git.kernel.org/?p=linux/kernel/git/kyle/module-init-tools.git;a=summary > If theres a newer one, if you could please point it out to me, I'd appreciate > it. If the functional equivalent of my second patch is already in there, then > we just need my first patch to be good to go. Ah, you want http://www.kerneltools.org/ - there's info on current trees and versions there. I am in the process of moving to kernel.org. I will check the patch situation right now anyway, leave it with me. Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc4-mm1 - git-alsa.patch breaks audio on Dell Latitude D820
At Wed, 05 Sep 2007 15:54:55 -0400, [EMAIL PROTECTED] wrote: > > On Wed, 05 Sep 2007 15:46:34 EDT, [EMAIL PROTECTED] said: > > > > % grep HDA_ .config > > CONFIG_SND_HDA_INTEL=y > > # CONFIG_SND_HDA_HWDEP is not set > > CONFIG_SND_HDA_CODEC_REALTEK=y > > CONFIG_SND_HDA_CODEC_ANALOG=y > > CONFIG_SND_HDA_CODEC_SIGMATEL=y > > # CONFIG_SND_HDA_CODEC_VIA is not set > > # CONFIG_SND_HDA_CODEC_ATIHDMI is not set > > # CONFIG_SND_HDA_CODEC_CONEXANT is not set > > # CONFIG_SND_HDA_CODEC_CMEDIA is not set > > # CONFIG_SND_HDA_CODEC_SI3054 is not set > > CONFIG_SND_HDA_GENERIC=y > > # CONFIG_SND_HDA_POWER_SAVE is not set > > For the record, REALTEK and ANALOG got set to Y in my bisect build because of > the infamous "defaults to Y" syndrome - after I saw Sigmatel go by I wised up > and started saying N, but forgot to clean up the first two. Those two are > disabled in the live -rc4-mm1 .config, and it has the same issue. The "default Y" is the correct behavior in this case. These configs are just splits from a single config, corresponding to all Y. Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 07:46:11PM +0100, Denys Vlasenko wrote: > On Wednesday 05 September 2007 16:53, Oleg Verych wrote: > > * Wed, 5 Sep 2007 14:43:21 +0100 > > * User-Agent: KMail/1.9.1 > > > > > > Build system: section garbage collection for vmlinux > > > > Maybe this is just a test suit to get finish with `make XYZ static`? > > They are vaguely connected in a sense that unused function which is > not marked static doesn't generate gcc warning, but will be discarded > by --gc-sections. "make XYZ static" also tends to find them - you make > function static, you recompile the file, and gcc informs you that > the function is not used at all! > > This happened to me when I did aic7xxx patches. > > You may yse --print-gc-sections to see the list of discarded sections. Anyway, this is gccism/binutilizm. That about other possible/future options? Give me example, please, why function must be non static if not used. If usage requires kconfig tuning, then this is a better way to go, than to adopt yet another GNU/Luxury. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sleep problems with kernels >= 2.6.21 on powerpc
On 5 Sep, Andrew Morton wrote:
>> On Wed, 05 Sep 2007 19:47:42 +0200 Stefan Richter <[EMAIL PROTECTED]> wrote:
>> >>> Trying to free already-free IRQ 40
>> >>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>> >>> firewire_ohci: pci_set_power_state failed with
>> >>> -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]()
>> >>> returns -22
...
>> The old ohci1394.c used to ignore pci_set_power_state's return value.
>> In the pre 2.6.19-rc1 commit ea6104c22468239083857fa07425c312b1ecb424, I
>> added a fail-on-error. This was toned down to a printk-on-err by pre
>> 2.6.19-rc4 commit 346f5c7ee7fa4ebee0e4c96415a7e59716bfa1d0.
>
> OK.
>
>> This was because of Benjamin Herrenschmidt's regression report:
>> http://lkml.org/lkml/2006/10/24/13
>
> It's not clear _why_ pci_set_power_state() is failing.
The only -22 error path in pci_set_power_state is this:
/* Validate current state:
* Can enter D0 from any state, but if we can only go deeper
* to sleep if we're already in a low power state
*/
if (state != PCI_D0 && dev->current_state > state) {
printk(KERN_ERR "%s(): %s: state=%d, current state=%d\n",
__FUNCTION__, pci_name(dev), state, dev->current_state);
return -EINVAL;
} [...else...]
(There seems to be one "if" too many in the comment.)
dev->current_state was PCI_UNKNOWN, and this is not properly handled by
pci_set_power_state. Some checks later, there is
switch (dev->current_state) {
case PCI_D0:
case PCI_D1:
case PCI_D2:
pmcsr &= ~PCI_PM_CTRL_STATE_MASK;
pmcsr |= state;
break;
case PCI_UNKNOWN: /* Boot-up */
if ((pmcsr & PCI_PM_CTRL_STATE_MASK) == PCI_D3hot
&& !(pmcsr & PCI_PM_CTRL_NO_SOFT_RESET))
need_restore = 1;
/* Fall-through: force to D0 */
default:
pmcsr = 0;
break;
}
But the PCI_UNKNOWN branch will never be reached because of the if ()
clause quoted above.
Also, this FireWire controller here surely had left the boot-up phase
already long ago when the reporter tried to suspend the machine.
--
Stefan Richter
-=-=-=== =--= --=-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] docproc: style & typo cleanups
On Tue, Sep 04, 2007 at 09:23:22PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> - fix typos/spellos in docproc.c and Makefile
> - add a little whitespace {while, switch} (coding style)
> - use NULL instead of 0 for pointer testing
>
Looks good - thanks.
I will apply it when I'm back at my dev machine.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [PATCH][RFC] pte notifiers -- support for external page tables
On Wed, 2007-09-05 at 22:32 +0300, Avi Kivity wrote: > [resend due to bad alias expansion resulting in some recipients > being bogus] > > Some hardware and software systems maintain page tables outside the normal > Linux page tables, which reference userspace memory. This includes > Infiniband, other RDMA-capable devices, and kvm (with a pending patch). And lguest. I can't tell until I've actually implemented it, but I think it will seriously reduce the need for page pinning which is why only root can currently launch guests. My concern is locking: this is called with the page lock held, and I guess we have to bump the guest out if it's currently running. (Oh, and this means lguest needs to do a reverse mapping somehow, but I'll come up with something). 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] Fix preemptible lazy mode bug
Rusty Russell wrote:
> On Tue, 2007-09-04 at 14:42 +0100, Jeremy Fitzhardinge wrote:
>
>> Rusty Russell wrote:
>>
>>> static inline void arch_flush_lazy_mmu_mode(void)
>>> {
>>> - PVOP_VCALL1(set_lazy_mode, PARAVIRT_LAZY_FLUSH);
>>> + if (unlikely(__get_cpu_var(paravirt_lazy_mode) == PARAVIRT_LAZY_MMU))
>>> + arch_leave_lazy_mmu_mode();
>>> }
>>>
>>>
>> This changes the semantics a bit; previously "flush" would flush
>> anything pending but leave us in lazy mode. This just drops lazymode
>> altogether?
>>
>> I guess if we assume that flushing is a rare event then its OK, but I
>> think the name's a bit misleading. How does it differ from plain
>> arch_leave_lazy_mmu_mode()?
>>
>
> Whether it's likely or unlikely to be in lazy mode, basically. But
> you're right, this should be folded, since we don't want to "leave" lazy
> mode twice.
>
Hm, I think there's still a problem here. In the current code, you can
legitimately flush lazy mode with preemption enabled (ie, there's no
lazy mode currently active), but it's always a bug to enable/disable
lazy mode with preemption enabled. Certainly enabling lazy mode with
preemption enabled is always a bug, but you could make disable
preempt-safe (and the bug checking should be in the common code).
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc4-mm1 - git-alsa.patch breaks audio on Dell Latitude D820
At Wed, 05 Sep 2007 15:46:34 -0400, [EMAIL PROTECTED] wrote: > > On Fri, 31 Aug 2007 21:58:22 PDT, Andrew Morton said: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ > > git-alsa.patch breaks audio on my laptop, worked fine in -rc3-mm1. Almost > certainly bustification in the Intel HDA rewrite. > > Symptoms: alsamixer finds the chipset, can adjust the volumes and > mute/unmute, > and /usr/bin/play is able to write a .wav to the ALSA device without > complaint. > However, no sound actually comes out. Very "lights are on but nobody is > home". > > Dell Latitude D820, lspci reports: > > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition > Audio Controller (rev 01) > and alsamixer reports finding a "SigmaTel STAC9200" > > % grep HDA_ .config > CONFIG_SND_HDA_INTEL=y > # CONFIG_SND_HDA_HWDEP is not set > CONFIG_SND_HDA_CODEC_REALTEK=y > CONFIG_SND_HDA_CODEC_ANALOG=y > CONFIG_SND_HDA_CODEC_SIGMATEL=y > # CONFIG_SND_HDA_CODEC_VIA is not set > # CONFIG_SND_HDA_CODEC_ATIHDMI is not set > # CONFIG_SND_HDA_CODEC_CONEXANT is not set > # CONFIG_SND_HDA_CODEC_CMEDIA is not set > # CONFIG_SND_HDA_CODEC_SI3054 is not set > CONFIG_SND_HDA_GENERIC=y > # CONFIG_SND_HDA_POWER_SAVE is not set > > dmesg under -rc4-mm1: > Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 > 2007 UTC). > ACPI: PCI Interrupt :00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21 > hda_intel: position_fix set to 1 for device 1028:01cc > ALSA device list: > #0: HDA Intel at 0xefffc000 irq 506 > > dmesg under -rc3-mm1: > > Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 > 2007 UTC). > ACPI: PCI Interrupt :00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21 > hda_intel: position_fix set to 1 for device 1028:01cc > ALSA device list: > #0: HDA Intel at 0xefffc000 irq 506 > > (Yes, they look the same to me, too...) > > I'd provide more info, if I had a clue what else to add... First, check /proc/asound/card0/codec#* whether STAC9200 is identified properly? If yes, check the mixer contents (at best, run "alsactl -f somefile store"), see whether "Master Playback Volume" is raised, "Master Playback Switch" unmuted, "Front..." raised/unmuted, and "PCM ..." raised/unmuted, etc. If this still doesn't work, try to give model=ref option to snd-hda-intel. If it still not OK, please try bi-sect of git.kernel.org/perex/alsa.git mm branch... Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: building a specific in-tree module is currently a bit broken
On Wed, Sep 05, 2007 at 11:43:15AM +0200, Jan Engelhardt wrote:
>
> On Sep 5 2007 11:37, Michal Piotrowski wrote:
> >
> >Hi,
> >
> >[Adding K{build,config} wizards to CC]
> >
> >On 05/09/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> >>
> >> $ make distclean
> >> $ make defconfig
> >> $ make menuconfig (select visor.ko to be built a module)
> >> $ make drivers/usb/serial/visor.ko
>
> Beep. Need 'make scripts prepare' between menuconfig and visor.
Nope - kbuild does this for you.
See following lines from top-level Makefile:
%.ko: prepare scripts FORCE
$(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
$(build)=$(build-dir) $(@:.ko=.o)
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
But as pointed out it fails to create MODVERDIR.
I had one take on it some time ago and do not recall why I failed
to fix it. Should be trivial.
But this is a small issue that has been there for a long time
and is not -rc material. I will try to have it fixed for
next merge window.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: building a specific in-tree module is currently a bit broken
On Wed, Sep 05, 2007 at 11:43:15AM +0200, Jan Engelhardt wrote: > > Also note that visor will not have any symvers until you have > a Module.symvers (which, ironically, is created at the end of "make vmlinux") Yeaa - it is hard to create it before we have vmlinux. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 02:47:00PM +0100, Denys Vlasenko wrote: > On Wednesday 05 September 2007 14:43, Denys Vlasenko wrote: > > These patches fix section names and add > > CONFIG_DISCARD_UNUSED_SECTIONS. It is not enabled > > unconditionally because only newest binutils have > > ld --gc-sections which is stable enough for kernel use. > > IOW: this is an experimental feature for now. > > Part 1: fix section names over entire source (all arches). > > Patch is big and boring global s/.text.lock/.text_lock/ > type thing. The normal naming scheme seems to be: ..text so in your example it would be: .lock.text See the naming og init and exit sections (that was renamed during 2.5 to be compatible with -ffunction-sections). Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revised timerfd() interface
On Wed, 5 Sep 2007, Michael Kerrisk wrote: > Hi Davide, > > > > > > As I think about this more, I see more problems with > > > > > your argument. timerfd needs the ability to get and > > > > > get-while-setting just as much as the earlier APIs. > > > > > Consider a library that creates a timerfd file descriptor that > > > > > is handed off to an application: that library may want > > > > > to modify the timer settings without having to create a > > > > > new file descriptor (the app mey not be able to be told about > > > > > the new fd). Your argument just doesn't hold, AFAICS. > > > > > > > > Such hypotethical library, in case it really wanted to offer such > > > > functionality, could simply return an handle instead of the raw fd, > > > > and take care of all that stuff in userspace. > > > > > > Did I miss something? Is it not the case that as soon as the > > > library returns a handle, rather than an fd, then the whole > > > advantage of timerfd() (being able to select/poll/epoll on > > > the timer as well as other fds) is lost? > > > > Why? The handle would simply be a little struct where the timerfd fd is > > stored, and a XXX_getfd() would return it. > > So my point is, I doubt such functionalities are really needed, and I > > also argue that the kernel is the best place for such wrapper code > > to go. > > So what happens if one thread (via the library) wants modify > a timer's settings at the same timer as another thread is > select()ing on it? The first thread can't do this by creating > a new timerfd timer, since it wants to affect the select() > in the other thread? It can be done w/out any problems. The select thread will be notified whenever the new timer setting expires. - 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 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 20:49 +0100, Denys Vlasenko wrote: > What does "it" stand for in this sentence? "it" is your patches, and I think we got to bottom of it .. "it" (i.e. your patches) don't actually work with modules, which is what you originally contended .. > My patch was tested to work in my limited testing, > but it is very conservative. > > I can't talk for Marcelo, but his patch probably worked too, > it just didn't guarantee that you can install kernel, and > then compile and load external module. Wel, it will compile, > but maybe will fail to load. At least you should modify your Kconfig changes so that you don't allow people to select your new option unless they have CONFIG_MODULES off.. 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: 2.6.23-rc4-mm1 - git-alsa.patch breaks audio on Dell Latitude D820
On Wed, 05 Sep 2007 15:46:34 EDT, [EMAIL PROTECTED] said: > > % grep HDA_ .config > CONFIG_SND_HDA_INTEL=y > # CONFIG_SND_HDA_HWDEP is not set > CONFIG_SND_HDA_CODEC_REALTEK=y > CONFIG_SND_HDA_CODEC_ANALOG=y > CONFIG_SND_HDA_CODEC_SIGMATEL=y > # CONFIG_SND_HDA_CODEC_VIA is not set > # CONFIG_SND_HDA_CODEC_ATIHDMI is not set > # CONFIG_SND_HDA_CODEC_CONEXANT is not set > # CONFIG_SND_HDA_CODEC_CMEDIA is not set > # CONFIG_SND_HDA_CODEC_SI3054 is not set > CONFIG_SND_HDA_GENERIC=y > # CONFIG_SND_HDA_POWER_SAVE is not set For the record, REALTEK and ANALOG got set to Y in my bisect build because of the infamous "defaults to Y" syndrome - after I saw Sigmatel go by I wised up and started saying N, but forgot to clean up the first two. Those two are disabled in the live -rc4-mm1 .config, and it has the same issue. pgpJjMCv8SxzM.pgp Description: PGP signature
Re: modinfo question
Justin Piszcz wrote: Is there anyway to get/see what parameters were passed to a kernel module? Running modinfo -p will show the defaults, but for example, st, the scsi tape driver, is there a way to see what it is currently using? I know in dmesg it shows this when you load it initially (but if say dmesg has been cleared or the buffer was filled up)? /sys/module/$MODULENAME/parameters/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 20:07, Daniel Walker wrote: > On Wed, 2007-09-05 at 20:14 +0100, Denys Vlasenko wrote: > > On Wednesday 05 September 2007 19:38, Daniel Walker wrote: > > > > > You version doesn't work with CONFIG_MODULES right? > > > > > > > > It works with CONFIG_MODULES. > > > > > > Really? Take a look at this version, > > > > > > http://lkml.org/lkml/2006/6/4/169 > > > > > > Marcello had to implement a two pass build to add back symbol used in > > > modules which got removed from the main kernel.. You don't appear to do > > > that. Marcelo also claims better size reduction than you. > > > > This will discard EXPORT_SYMBOLs potentially used by > > out-of-tree modules. > > Right, so it doesn't work with modules.. What does "it" stand for in this sentence? My patch was tested to work in my limited testing, but it is very conservative. I can't talk for Marcelo, but his patch probably worked too, it just didn't guarantee that you can install kernel, and then compile and load external module. Wel, it will compile, but maybe will fail to load. It sounds like *in-tree modules* were loading just fine for Marcelo. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nfs4 hang regression
On 9/5/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Wed, 22 Aug 2007 15:41:18 -0700 "Bret Towe" <[EMAIL PROTECTED]> wrote:
>
> More than two weeks, you've bisected it and there's no sign of any action?
>
> I don't see this on Michal's list so perhaps it already got fixed in a
> different
> thread. Have you tested current mainline?
It's been fixed, this thread was never replied to since I replied to
another thread
someone else started that was the same issue
Thanks for keeping watch tho :)
> > as of commit 3d39c691ff486142dd9aaeac12f553f4476b7a62
> > I got a hang on my clients after something around 26 minutes of uptime
> > the keyboard would stop accepting input
> > mouse would work still, plugging in a spare usb keyboard made no difference
> > another couple odd bits is shutting down would hang, below is a trace
> > of that hang
> > also if your logged into that machine via ssh when you log out it would hang
> > and would require a force terminate
> >
> > I'm seeing this on 2 machines 1 a g4 mac mini and 2 a athlon64
> > both have a home directory mounted via nfs4
> > reverting the commit above found via bisecting on both machines allows me
> > to use the computers for several hours with no issues
> >
> > and here is the trace from the athlon64 taken during its hang on shutdown
> > as you can tell from the dates in the trace ive been a bit busy and just
> > now got around to sending this email
> > I'm surprised tho I hadn't seen anyone hitting it
> > let me know what else is needed I'll do what I can and get it out quickly
> >
> > Aug 12 17:06:35 ghoststar kernel: [ 4791.801262] SysRq : Show State
> > Aug 12 17:06:35 ghoststar kernel: [ 4791.801325] task
> > PC stack pid father
> > Aug 12 17:06:35 ghoststar kernel: [ 4791.801327] init S
> > 0 1 0
> > Aug 12 17:06:35 ghoststar kernel: [ 4791.801331] 81003ff879b8
> > 0086 0008 81003ff84000
>
> I really wish that hadn't been wordwrapped.
>
> As a random stab-in-the-dark, does this help?
>
> --- a/fs/nfs/nfs4renewd.c~a
> +++ a/fs/nfs/nfs4renewd.c
> @@ -133,9 +133,7 @@ nfs4_renewd_prepare_shutdown(struct nfs_
> void
> nfs4_kill_renewd(struct nfs_client *clp)
> {
> - down_read(>cl_sem);
> cancel_delayed_work_sync(>cl_renewd);
> - up_read(>cl_sem);
> }
>
> /*
> _
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Sleep problems with kernels >= 2.6.21 on powerpc
> On Wed, 05 Sep 2007 19:47:42 +0200 Stefan Richter <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > >>> Trying to free already-free IRQ 40 > >>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5 > >>> firewire_ohci: pci_set_power_state failed with > >>> -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() > >>> returns -22 > > > > I grepped the whole tree for firewire_ohci and came up blank. What is it? > > drivers/firewire/fw-ohci.c -> fw-ohci.o -> firewire-ohci.o -> > firewire-ohci.ko argh. It's not the first time that the module system's weird replace-dash-with-underscore thing has fooled me. > > But yes, a failed pci_set_power_state() will hurt. Perhaps this is > > a result of some recently-added return-value checking fix but as I > > cannot find the dang code I cannot tell. > > The old ohci1394.c used to ignore pci_set_power_state's return value. > In the pre 2.6.19-rc1 commit ea6104c22468239083857fa07425c312b1ecb424, I > added a fail-on-error. This was toned down to a printk-on-err by pre > 2.6.19-rc4 commit 346f5c7ee7fa4ebee0e4c96415a7e59716bfa1d0. OK. > This was because of Benjamin Herrenschmidt's regression report: > http://lkml.org/lkml/2006/10/24/13 It's not clear _why_ pci_set_power_state() is failing. > A trivial post -rc1 compatible fix is coming in a minute. neato, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 12:24:04PM -0700, Daniel Walker wrote: > On Wed, 2007-09-05 at 21:31 +0200, Adrian Bunk wrote: > > On Wed, Sep 05, 2007 at 08:14:12PM +0100, Denys Vlasenko wrote: > > > On Wednesday 05 September 2007 19:38, Daniel Walker wrote: > > > > > > You version doesn't work with CONFIG_MODULES right? > > > > > > > > > > It works with CONFIG_MODULES. > > > > > > > > Really? Take a look at this version, > > > > > > > > http://lkml.org/lkml/2006/6/4/169 > > > > > > > > Marcello had to implement a two pass build to add back symbol used in > > > > modules which got removed from the main kernel.. You don't appear to do > > > > that. Marcelo also claims better size reduction than you. > > > > > > This will discard EXPORT_SYMBOLs potentially used by > > > out-of-tree modules. > > > > > > I also saw ~10% size reductions, but then at run-time test modules > > > failed to load, they didn't find needed symbols. > > > > > > OTOH if I know that I am not going to be using such modules, > > > then this can be done. Will require another CONFIG_xxx, though. > > > > One point to keep in mind is that the space penalty of CONFIG_MODULES=y > > is so big that CONFIG_MODULES=n is actually the most interesting case > > for small systems that really need small kernels. > > Marcelo's version actual deals with the CONFIG_MODULES=y penalty , which > is interesting to me .. It removes symbols added for CONFIG_MODULES > which actually aren't used .. So CONFIG_MODULES=y is just as interesting > as without (to me at least..). There's still stuff like kernel/module.c or the additional space each used EXPORT_SYMBOL takes that make CONFIG_MODULES=n kernels smaller. But it depends on the use case: If you are aiming for the smallest possible runtime memory usage CONFIG_MODULES=n is the best choice, while for some applications where the bzimage (or similar) size is for some reason limited but the size of the modules doesn't matter the approach you mention might be the best. > Daniel 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/
2.6.23-rc4-mm1 - git-alsa.patch breaks audio on Dell Latitude D820
On Fri, 31 Aug 2007 21:58:22 PDT, Andrew Morton said: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ git-alsa.patch breaks audio on my laptop, worked fine in -rc3-mm1. Almost certainly bustification in the Intel HDA rewrite. Symptoms: alsamixer finds the chipset, can adjust the volumes and mute/unmute, and /usr/bin/play is able to write a .wav to the ALSA device without complaint. However, no sound actually comes out. Very "lights are on but nobody is home". Dell Latitude D820, lspci reports: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) and alsamixer reports finding a "SigmaTel STAC9200" % grep HDA_ .config CONFIG_SND_HDA_INTEL=y # CONFIG_SND_HDA_HWDEP is not set CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y # CONFIG_SND_HDA_CODEC_VIA is not set # CONFIG_SND_HDA_CODEC_ATIHDMI is not set # CONFIG_SND_HDA_CODEC_CONEXANT is not set # CONFIG_SND_HDA_CODEC_CMEDIA is not set # CONFIG_SND_HDA_CODEC_SI3054 is not set CONFIG_SND_HDA_GENERIC=y # CONFIG_SND_HDA_POWER_SAVE is not set dmesg under -rc4-mm1: Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC). ACPI: PCI Interrupt :00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21 hda_intel: position_fix set to 1 for device 1028:01cc ALSA device list: #0: HDA Intel at 0xefffc000 irq 506 dmesg under -rc3-mm1: Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC). ACPI: PCI Interrupt :00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21 hda_intel: position_fix set to 1 for device 1028:01cc ALSA device list: #0: HDA Intel at 0xefffc000 irq 506 (Yes, they look the same to me, too...) I'd provide more info, if I had a clue what else to add... pgp1WplRCncLB.pgp Description: PGP signature
Re: sk98lin for 2.6.23-rc1
--- Stephen Hemminger <[EMAIL PROTECTED]> wrote: > On Sun, 29 Jul 2007 21:01:30 -0600 > Rob Sims <[EMAIL PROTECTED]> wrote: > > > On Thu, Jul 26, 2007 at 06:57:01PM +0200, Adrian > Bunk wrote: > > > On Thu, Jul 26, 2007 at 11:16:36AM -0400, Kyle > Rose wrote: > > > > >From > http://www.krose.org/~krose/computing.html: > > > > > > > > Since the sky2 driver continues to suck ass > (which is a technical > > > > description for "it hangs all the time under > load, at least on my > > > > hardware" :-) ), I've fixed the sk98lin driver > to compile for > > > > linux-2.6.23-rc1. Those who continue to have > problems with sky2 can > > > > still use 2.6.23-rc1, simply by doing the > following: > > > >... > > > > Personally, I'd like to see sk98lin remain in > the kernel proper until > > > > sky2 goes at least 6 months without reported > problems. The fact that I > > > > am not the only one still seeing issues is a > clear indication that sky2 > > > > (even with the recent patches in 2.6.23-rc1) > is not yet ready to replace > > > > sk98lin. > > > >... > > > > > > This sounds good in theory. > > > > > > The practical problem with this approach is that > there are always many > > > people who use the old driver when the new > driver doesn't work for them > > > instead of reporting their problems with the new > driver. > > > > > > For these people a new driver will often suck > when the old driver gets > > > removed, but after the removal of the old driver > they are finally forced > > > to report their bugs resulting in a better new > driver for everyone. > > > > > > The sky2 driver is since nearly 2 years in the > kernel and Stephen is > > > usually quite good at handling bugs. > > > > The driver still (2.6.20/sky2 1.13) hangs for me > (more rarely than in > > the past), and cycling the module generally fixes > the issues. I have > > supplied all the information that Stephen has > asked for, but still no > > resolution. I am not complaining about the lack > of a fix, but don't > > assume that all it takes to get sky2 working is > adequate bug reports. I > > have been and remain willing to test and assist > debug, but after several > > dropped threads, I feel like the desire or ability > to fix this issue > > isn't there (and remote debug of an intermittent > hardware issue IS > > hard), and I didn't want to be a nuisance to > someone that has no > > obligation to me to address the issue in the first > place. > > > > Stability has improved, it's just not there yet. > > > > I'll switch to 1.16 soon, and respond to Stephen's > request on netdev for > > current issues. > > -- > > Rob > > The only known outstanding problems on 2.62.22.6 of > sky2 are: > * problems with fibre PHY based systems > * suspend/resume issues, missing multicast > reinitalization, etc. > The previous stability problems have been addressed. I pretty much agree with everything said, including the part about the sky2 people working hard on it. I have noticed several bugs fixed recently in the driver source. However, it really DOES lock up under load. I even tried 2.6.23-rc4 and the absolute latest version of the driver and it still locks up, as in eth1: hw csum failure. Call Trace: [] __skb_checksum_complete_head+0x43/0x56 [] __skb_checksum_complete+0xc/0x11 [] tcp_v4_rcv+0x14e/0x801 [] ip_local_deliver+0xca/0x14c [] ip_rcv+0x46c/0x4ae [] :sky2:sky2_poll+0x72b/0x9c7 [] update_wall_time+0x28c/0x39b [] net_rx_action+0xa8/0x166 [] do_timer+0x10/0xab [] __do_softirq+0x55/0xc4 [] call_softirq+0x1c/0x28 [] do_softirq+0x2c/0x7d [] do_IRQ+0x13e/0x15f [] mwait_idle+0x0/0x48 [] ret_from_intr+0x0/0xa [] udp_poll+0x0/0xfb [] mwait_idle+0x42/0x48 [] cpu_idle+0xbd/0xe0 [] start_kernel+0x2ac/0x2b8 [] _sinittext+0x140/0x144 As far as I can tell, this bug has been with the sky2 driver all the way back to the Beforetime. Based on it happening with various versions of the driver back to 2.6.18 that I have tried, plus some googling on it. So while I bug reporting point is a good one, it would be nice to have a reliable driver in the kernel until the sky2 one is better. The alternative is to use the vendor driver, which less than optimal. -J Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
