[patch 13/20] libata: add ATI SB700 device IDs to AHCI driver
-stable review patch. If anyone has any objections, please let us know.
--
From: su henry <[EMAIL PROTECTED]>
The SATA controller device ID is different according to
the onchip SATA type set in the system BIOS:
Device Device ID
SATA in IDE mode 0x4390
SATA in AHCI mode 0x4391
SATA in non-raid5 driver 0x4392
SATA in raid5 driver 0x4393
Although the device ID is different, they use the same AHCI driver
.The attached file is the patch for adding these device
IDs for ATI SB700.
Signed-off-by: su henry <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/ata/ahci.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -399,7 +399,10 @@ static const struct pci_device_id ahci_p
/* ATI */
{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 */
- { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb600 }, /* ATI SB700 */
+ { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb600 }, /* ATI SB700 IDE */
+ { PCI_VDEVICE(ATI, 0x4391), board_ahci_sb600 }, /* ATI SB700 AHCI */
+ { PCI_VDEVICE(ATI, 0x4392), board_ahci_sb600 }, /* ATI SB700 nraid5 */
+ { PCI_VDEVICE(ATI, 0x4393), board_ahci_sb600 }, /* ATI SB700 raid5 */
/* VIA */
{ PCI_VDEVICE(VIA, 0x3349), board_ahci_vt8251 }, /* VIA VT8251 */
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 12/20] forcedeth: fix random hang in forcedeth driver when using netconsole
-stable review patch. If anyone has any objections, please let us know. -- From: Timo Jantunen <[EMAIL PROTECTED]> If the forcedeth driver receives too much work in an interrupt, it assumes it has a broken hardware with stuck IRQ. It works around the problem by disabling interrupts on the nic but makes a printk while holding device spinlog - which isn't smart thing to do if you have netconsole on the same nic. This patch moves the printk's out of the spinlock protected area. Without this patch the machine hangs hard. With this patch everything still works even when there is significant increase on CPU usage while using the nic. Signed-off-by: Timo Jantunen <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/net/forcedeth.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/drivers/net/forcedeth.c +++ b/drivers/net/forcedeth.c @@ -3067,8 +3067,8 @@ static irqreturn_t nv_nic_irq(int foo, v np->nic_poll_irq = np->irqmask; mod_timer(&np->nic_poll, jiffies + POLL_WAIT); } - printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq.\n", dev->name, i); spin_unlock(&np->lock); + printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq.\n", dev->name, i); break; } @@ -3185,8 +3185,8 @@ static irqreturn_t nv_nic_irq_optimized( np->nic_poll_irq = np->irqmask; mod_timer(&np->nic_poll, jiffies + POLL_WAIT); } - printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq.\n", dev->name, i); spin_unlock(&np->lock); + printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq.\n", dev->name, i); break; } @@ -3232,8 +3232,8 @@ static irqreturn_t nv_nic_irq_tx(int foo np->nic_poll_irq |= NVREG_IRQ_TX_ALL; mod_timer(&np->nic_poll, jiffies + POLL_WAIT); } - printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_tx.\n", dev->name, i); spin_unlock_irqrestore(&np->lock, flags); + printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_tx.\n", dev->name, i); break; } @@ -3347,8 +3347,8 @@ static irqreturn_t nv_nic_irq_rx(int foo np->nic_poll_irq |= NVREG_IRQ_RX_ALL; mod_timer(&np->nic_poll, jiffies + POLL_WAIT); } - printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_rx.\n", dev->name, i); spin_unlock_irqrestore(&np->lock, flags); + printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_rx.\n", dev->name, i); break; } } @@ -3420,8 +3420,8 @@ static irqreturn_t nv_nic_irq_other(int np->nic_poll_irq |= NVREG_IRQ_OTHER; mod_timer(&np->nic_poll, jiffies + POLL_WAIT); } - printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_other.\n", dev->name, i); spin_unlock_irqrestore(&np->lock, flags); + printk(KERN_DEBUG "%s: too many iterations (%d) in nv_nic_irq_other.\n", dev->name, i); break; } -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 07/20] revert "x86, serial: convert legacy COM ports to platform devices"
-stable review patch. If anyone has any objections, please let us know.
--
From: Andrew Morton <[EMAIL PROTECTED]>
Revert 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26. It broke S??bastien Dugu??'s
machine and Jeff said (persuasively)
This seems like it will break decades-long-working stuff, in favor of
breaking new ground in our favorite area, "trusting the BIOS."
It's just not worth it for serial ports, IMO. Serial ports are something
that just shouldn't break at this late stage in the game. My new Intel
platform boxes don't even have serial ports, so I question the value of
messing with serial port probing even more... because... just wait a year,
and your box won't have a serial port either! :)
I certainly don't object to the use of platform devices (or isa_driver),
but the probe change seems questionable. That's sorta analagous to
rewriting the floppy driver probe routine. Sure you could do it... but why
risk all that damage and go through debugging all over again?
It seems clear from this report that we cannot, should not, trust BIOS for
something (a) so simple and (b) that has been working for over a decade.
Much discussion ensued and we've decided to have another go at all of this.
Cc: S??bastien Dugu?? <[EMAIL PROTECTED]>
Cc: Bjorn Helgaas <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Cc: Adam Belay <[EMAIL PROTECTED]>
Cc: Matthew Garrett <[EMAIL PROTECTED]>
Cc: Russell King <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
Cc: Michal Piotrowski <[EMAIL PROTECTED]>
Cc: Sascha Sommer <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |5 --
arch/i386/kernel/Makefile |1
arch/i386/kernel/legacy_serial.c| 67
arch/x86_64/kernel/Makefile |2 -
drivers/serial/Kconfig | 14 ++-
include/asm-i386/serial.h | 16
include/asm-x86_64/serial.h | 16
7 files changed, 37 insertions(+), 84 deletions(-)
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -850,11 +850,6 @@ and is between 256 and 4096 characters.
lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip
Format: addr:,irq:
- legacy_serial.force [HW,IA-32,X86-64]
- Probe for COM ports at legacy addresses even
- if PNPBIOS or ACPI should describe them. This
- is for working around firmware defects.
-
llsc*= [IA64] See function print_params() in
arch/ia64/sn/kernel/llsc4.c.
--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -35,7 +35,6 @@ obj-y += sysenter.o vsyscall.o
obj-$(CONFIG_ACPI_SRAT)+= srat.o
obj-$(CONFIG_EFI) += efi.o efi_stub.o
obj-$(CONFIG_DOUBLEFAULT) += doublefault.o
-obj-$(CONFIG_SERIAL_8250) += legacy_serial.o
obj-$(CONFIG_VM86) += vm86.o
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
obj-$(CONFIG_HPET_TIMER) += hpet.o
--- a/arch/i386/kernel/legacy_serial.c
+++ /dev/null
@@ -1,67 +0,0 @@
-/*
- * Legacy COM port devices for x86 platforms without PNPBIOS or ACPI.
- * Data taken from include/asm-i386/serial.h.
- *
- * (c) Copyright 2007 Hewlett-Packard Development Company, L.P.
- * Bjorn Helgaas <[EMAIL PROTECTED]>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include
-#include
-#include
-#include
-
-/* Standard COM flags (except for COM4, because of the 8514 problem) */
-#ifdef CONFIG_SERIAL_DETECT_IRQ
-#define COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_AUTO_IRQ)
-#define COM4_FLAGS (UPF_BOOT_AUTOCONF | UPF_AUTO_IRQ)
-#else
-#define COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
-#define COM4_FLAGS UPF_BOOT_AUTOCONF
-#endif
-
-#define PORT(_base,_irq,_flags)\
- { \
- .iobase = _base,\
- .irq= _irq, \
- .uartclk= 1843200, \
- .iotype = UPIO_PORT,\
- .flags = _flags, \
- }
-
-static struct plat_serial8250_port x86_com_data[] = {
- PORT(0x3F8, 4, COM_FLAGS),
- PORT(0x2F8, 3, COM_FLAGS),
- PORT(0x3E8, 4, COM_FLAGS),
- PORT(0x2E8, 3, COM4_FLAGS),
- { },
-};
-
-static struct platform_device x86_com_device = {
- .name = "serial8250",
- .id = PLAT82
[patch 11/20] r8169: avoid needless NAPI poll scheduling
-stable review patch. If anyone has any objections, please let us know.
--
From: Francois Romieu <[EMAIL PROTECTED]>
Theory : though needless, it should not have hurt.
Practice: it does not play nice with DEBUG_SHIRQ + LOCKDEP + UP
(see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D242572).
The patch makes sense in itself but I should dig why it has an effect
on #242572 (assuming that NAPI do not change in a near future).
Patch in mainline as 313b0305b5a1e7e0fb39383befbf79558ce68a9c.
Backported to 2.6.22-stable by Thomas M=FCller.
Signed-off-by: Thomas M=FCller <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/r8169.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2649,14 +2649,16 @@ rtl8169_interrupt(int irq, void *dev_ins
rtl8169_check_link_status(dev, tp, ioaddr);
#ifdef CONFIG_R8169_NAPI
- RTL_W16(IntrMask, rtl8169_intr_mask & ~rtl8169_napi_event);
- tp->intr_mask = ~rtl8169_napi_event;
-
- if (likely(netif_rx_schedule_prep(dev)))
- __netif_rx_schedule(dev);
- else if (netif_msg_intr(tp)) {
- printk(KERN_INFO "%s: interrupt %04x taken in poll\n",
- dev->name, status);
+ if (status & rtl8169_napi_event) {
+ RTL_W16(IntrMask, rtl8169_intr_mask &
~rtl8169_napi_event);
+ tp->intr_mask = ~rtl8169_napi_event;
+
+ if (likely(netif_rx_schedule_prep(dev)))
+ __netif_rx_schedule(dev);
+ else if (netif_msg_intr(tp)) {
+ printk(KERN_INFO "%s: interrupt %04x in poll\n",
+ dev->name, status);
+ }
}
break;
#else
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10/20] AVR32: Fix atomic_add_unless() and atomic_sub_unless()
-stable review patch. If anyone has any objections, please let us know. -- From: Haavard Skinnemoen <[EMAIL PROTECTED]> These functions depend on "result" being initalized to 0, but "result" is not included as an input constraint to the inline assembly block following its initialization, only as an output constraint. Thus gcc thinks it doesn't need to initialize it, so result ends up undefined if the "unless" condition is true. This fixes an oops in sunrpc where the faulty atomics caused rpciod_up() to not start the workqueue as it should. Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- include/asm-avr32/atomic.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/include/asm-avr32/atomic.h +++ b/include/asm-avr32/atomic.h @@ -101,7 +101,7 @@ static inline int atomic_sub_unless(atom " mov %1, 1\n" "1:" : "=&r"(tmp), "=&r"(result), "=o"(v->counter) - : "m"(v->counter), "rKs21"(a), "rKs21"(u) + : "m"(v->counter), "rKs21"(a), "rKs21"(u), "1"(result) : "cc", "memory"); return result; @@ -137,7 +137,7 @@ static inline int atomic_add_unless(atom " mov %1, 1\n" "1:" : "=&r"(tmp), "=&r"(result), "=o"(v->counter) - : "m"(v->counter), "r"(a), "ir"(u) + : "m"(v->counter), "r"(a), "ir"(u), "1"(result) : "cc", "memory"); } -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 08/20] ACPICA: Fixed possible corruption of global GPE list
-stable review patch. If anyone has any objections, please let us know.
--
From: Bob Moore <[EMAIL PROTECTED]>
ACPICA: Fixed possible corruption of global GPE list
Fixed a problem in acpi_ev_delete_gpe_xrupt where the global interrupt
list could be corrupted if the interrupt being removed was at
the head of the list. Reported by Linn Crosetto.
Signed-off-by: Bob Moore <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/acpi/events/evgpeblk.c |4
1 file changed, 4 insertions(+)
--- a/drivers/acpi/events/evgpeblk.c
+++ b/drivers/acpi/events/evgpeblk.c
@@ -586,6 +586,10 @@ acpi_ev_delete_gpe_xrupt(struct acpi_gpe
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
if (gpe_xrupt->previous) {
gpe_xrupt->previous->next = gpe_xrupt->next;
+ } else {
+ /* No previous, update list head */
+
+ acpi_gbl_gpe_xrupt_list_head = gpe_xrupt->next;
}
if (gpe_xrupt->next) {
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 09/20] ACPICA: Clear reserved fields for incoming ACPI 1.0 FADTs
-stable review patch. If anyone has any objections, please let us know.
--
From: Bob Moore <[EMAIL PROTECTED]>
ACPICA: Clear reserved fields for incoming ACPI 1.0 FADTs
Fixed a problem with the internal FADT conversion where ACPI 1.0
FADTs that contained invalid non-zero values in reserved fields
could cause later failures because these fields have meaning in
later revisions of the FADT. For incoming ACPI 1.0 FADTs, these
fields are now always zeroed. (Preferred_PM_Profile, PSTATE_CNT,
CST_CNT, IAPC_BOOT_FLAGS.)
Signed-off-by: Bob Moore <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/acpi/tables/tbfadt.c | 44 +--
1 file changed, 26 insertions(+), 18 deletions(-)
--- a/drivers/acpi/tables/tbfadt.c
+++ b/drivers/acpi/tables/tbfadt.c
@@ -211,14 +211,17 @@ void acpi_tb_parse_fadt(acpi_native_uint
* DESCRIPTION: Get a local copy of the FADT and convert it to a common format.
* Performs validation on some important FADT fields.
*
+ * NOTE:We create a local copy of the FADT regardless of the version.
+ *
**/
void acpi_tb_create_local_fadt(struct acpi_table_header *table, u32 length)
{
/*
-* Check if the FADT is larger than what we know about (ACPI 2.0
version).
-* Truncate the table, but make some noise.
+* Check if the FADT is larger than the largest table that we expect
+* (the ACPI 2.0/3.0 version). If so, truncate the table, and issue
+* a warning.
*/
if (length > sizeof(struct acpi_table_fadt)) {
ACPI_WARNING((AE_INFO,
@@ -227,10 +230,12 @@ void acpi_tb_create_local_fadt(struct ac
sizeof(struct acpi_table_fadt)));
}
- /* Copy the entire FADT locally. Zero first for tb_convert_fadt */
+ /* Clear the entire local FADT */
ACPI_MEMSET(&acpi_gbl_FADT, 0, sizeof(struct acpi_table_fadt));
+ /* Copy the original FADT, up to sizeof (struct acpi_table_fadt) */
+
ACPI_MEMCPY(&acpi_gbl_FADT, table,
ACPI_MIN(length, sizeof(struct acpi_table_fadt)));
@@ -251,7 +256,7 @@ void acpi_tb_create_local_fadt(struct ac
* RETURN: None
*
* DESCRIPTION: Converts all versions of the FADT to a common internal format.
- * -> Expand all 32-bit addresses to 64-bit.
+ * Expand all 32-bit addresses to 64-bit.
*
* NOTE:acpi_gbl_FADT must be of size (struct acpi_table_fadt),
* and must contain a copy of the actual FADT.
@@ -292,8 +297,23 @@ static void acpi_tb_convert_fadt(void)
}
/*
-* Expand the 32-bit V1.0 addresses to the 64-bit "X" generic address
-* structures as necessary.
+* For ACPI 1.0 FADTs (revision 1 or 2), ensure that reserved fields
which
+* should be zero are indeed zero. This will workaround BIOSs that
+* inadvertently place values in these fields.
+*
+* The ACPI 1.0 reserved fields that will be zeroed are the bytes
located at
+* offset 45, 55, 95, and the word located at offset 109, 110.
+*/
+ if (acpi_gbl_FADT.header.revision < 3) {
+ acpi_gbl_FADT.preferred_profile = 0;
+ acpi_gbl_FADT.pstate_control = 0;
+ acpi_gbl_FADT.cst_control = 0;
+ acpi_gbl_FADT.boot_flags = 0;
+ }
+
+ /*
+* Expand the ACPI 1.0 32-bit V1.0 addresses to the ACPI 2.0 64-bit "X"
+* generic address structures as necessary.
*/
for (i = 0; i < ACPI_FADT_INFO_ENTRIES; i++) {
target =
@@ -349,18 +369,6 @@ static void acpi_tb_convert_fadt(void)
acpi_gbl_FADT.xpm1a_event_block.space_id;
}
-
- /*
-* For ACPI 1.0 FADTs, ensure that reserved fields (which should be
zero)
-* are indeed zero. This will workaround BIOSs that inadvertently placed
-* values in these fields.
-*/
- if (acpi_gbl_FADT.header.revision < 3) {
- acpi_gbl_FADT.preferred_profile = 0;
- acpi_gbl_FADT.pstate_control = 0;
- acpi_gbl_FADT.cst_control = 0;
- acpi_gbl_FADT.boot_flags = 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/
[patch 05/20] sky2: check for more work before leaving NAPI
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Backport of commit 5c11ce700f77fada15b6264417d72462da4bbb1c
This patch avoids generating another IRQ if more packets
arrive while in the NAPI poll routine. Before marking device as
finished, it rechecks that the status ring is empty.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/sky2.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -2428,8 +2428,7 @@ static void sky2_err_intr(struct sky2_hw
static int sky2_poll(struct net_device *dev0, int *budget)
{
struct sky2_hw *hw = ((struct sky2_port *) netdev_priv(dev0))->hw;
- int work_limit = min(dev0->quota, *budget);
- int work_done = 0;
+ int work_done;
u32 status = sky2_read32(hw, B0_Y2_SP_EISR);
if (unlikely(status & Y2_IS_ERROR))
@@ -2441,25 +2440,25 @@ static int sky2_poll(struct net_device *
if (status & Y2_IS_IRQ_PHY2)
sky2_phy_intr(hw, 1);
- work_done = sky2_status_intr(hw, work_limit);
- if (work_done < work_limit) {
- /* Bug/Errata workaround?
-* Need to kick the TX irq moderation timer.
-*/
- if (sky2_read8(hw, STAT_TX_TIMER_CTRL) == TIM_START) {
- sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_STOP);
- sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_START);
- }
- netif_rx_complete(dev0);
+ work_done = sky2_status_intr(hw, min(dev0->quota, *budget));
+ *budget -= work_done;
+ dev0->quota -= work_done;
- /* end of interrupt, re-enables also acts as I/O
synchronization */
- sky2_read32(hw, B0_Y2_SP_LISR);
- return 0;
- } else {
- *budget -= work_done;
- dev0->quota -= work_done;
+ /* More work? */
+ if (hw->st_idx != sky2_read16(hw, STAT_PUT_IDX))
return 1;
+
+ /* Bug/Errata workaround?
+* Need to kick the TX irq moderation timer.
+*/
+ if (sky2_read8(hw, STAT_TX_TIMER_CTRL) == TIM_START) {
+ sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_STOP);
+ sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_START);
}
+ netif_rx_complete(dev0);
+
+ sky2_read32(hw, B0_Y2_SP_LISR);
+ return 0;
}
static irqreturn_t sky2_intr(int irq, void *dev_id)
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 06/20] sky2: check drop truncated packets
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Backport of commit 71749531f2d1954137a1a77422ef4ff29eb102dd
If packet larger than MTU is received, the driver uses hardware to
truncate the packet. Use the status registers to catch/drop them.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/sky2.c |8
1 file changed, 8 insertions(+)
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -2065,6 +2065,9 @@ static struct sk_buff *sky2_receive(stru
if (!(status & GMR_FS_RX_OK))
goto resubmit;
+ if (status >> 16 != length)
+ goto len_mismatch;
+
if (length < copybreak)
skb = receive_copy(sky2, re, length);
else
@@ -2074,6 +2077,11 @@ resubmit:
return skb;
+len_mismatch:
+ /* Truncation of overlength packets
+ causes PHY length to not match MAC length */
+ ++sky2->net_stats.rx_length_errors;
+
error:
++sky2->net_stats.rx_errors;
if (status & GMR_FS_RX_FF_OV) {
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 04/20] sky2: carrier management
-stable review patch. If anyone has any objections, please let us know. -- From: Stephen Hemminger <[EMAIL PROTECTED]> backport of commit 55d7b4e6ed6ad3ec5e5e30b3b4515a0a6a53e344 Make sky2 handle carrier similar to other drivers, eliminate some possible races in carrier state transistions. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/net/sky2.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -1234,6 +1234,8 @@ static int sky2_up(struct net_device *de if (netif_msg_ifup(sky2)) printk(KERN_INFO PFX "%s: enabling interface\n", dev->name); + netif_carrier_off(dev); + /* must be power of 2 */ sky2->tx_le = pci_alloc_consistent(hw->pdev, TX_RING_SIZE * @@ -1573,7 +1575,6 @@ static int sky2_down(struct net_device * /* Stop more packets from being queued */ netif_stop_queue(dev); - netif_carrier_off(dev); /* Disable port IRQ */ imask = sky2_read32(hw, B0_IMSK); @@ -1625,6 +1626,8 @@ static int sky2_down(struct net_device * sky2_phy_power(hw, port, 0); + netif_carrier_off(dev); + /* turn off LED's */ sky2_write16(hw, B0_Y2LED, LED_STAT_OFF); @@ -1689,7 +1692,6 @@ static void sky2_link_up(struct sky2_por gm_phy_write(hw, port, PHY_MARV_INT_MASK, PHY_M_DEF_MSK); netif_carrier_on(sky2->netdev); - netif_wake_queue(sky2->netdev); /* Turn on link LED */ sky2_write8(hw, SK_REG(port, LNK_LED_REG), @@ -1741,7 +1743,6 @@ static void sky2_link_down(struct sky2_p gma_write16(hw, port, GM_GP_CTRL, reg); netif_carrier_off(sky2->netdev); - netif_stop_queue(sky2->netdev); /* Turn on link LED */ sky2_write8(hw, SK_REG(port, LNK_LED_REG), LINKLED_OFF); @@ -3493,10 +3494,6 @@ static __devinit struct net_device *sky2 memcpy_fromio(dev->dev_addr, hw->regs + B2_MAC_1 + port * 8, ETH_ALEN); memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len); - /* device is off until link detection */ - netif_carrier_off(dev); - netif_stop_queue(dev); - return dev; } -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 20 Aug 2007, David Brownell wrote: > > Try disabling USB_SUSPEND ... the rather aggressive powersave > mechanism (autosuspend defaulting to always ON) has made lots > of trouble. I think that default will change... It's already disabled - so that's not it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 03/20] sky2: restore workarounds for lost interrupts
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Backport of commit c59697e06058fc2361da8cefcfa3de85ac107582
This patch restores a couple of workarounds from 2.6.16:
* restart transmit moderation timer in case it expires during IRQ routine
* default to having 10 HZ watchdog timer.
At this point it more important not to hang than to worry about the
power cost.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/sky2.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -96,7 +96,7 @@ static int disable_msi = 0;
module_param(disable_msi, int, 0);
MODULE_PARM_DESC(disable_msi, "Disable Message Signaled Interrupt (MSI)");
-static int idle_timeout = 0;
+static int idle_timeout = 100;
module_param(idle_timeout, int, 0);
MODULE_PARM_DESC(idle_timeout, "Watchdog timer for lost interrupts (ms)");
@@ -2442,6 +2442,13 @@ static int sky2_poll(struct net_device *
work_done = sky2_status_intr(hw, work_limit);
if (work_done < work_limit) {
+ /* Bug/Errata workaround?
+* Need to kick the TX irq moderation timer.
+*/
+ if (sky2_read8(hw, STAT_TX_TIMER_CTRL) == TIM_START) {
+ sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_STOP);
+ sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_START);
+ }
netif_rx_complete(dev0);
/* end of interrupt, re-enables also acts as I/O
synchronization */
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 02/20] hwmon: (smsc47m1) restore missing name attribute
-stable review patch. If anyone has any objections, please let us know.
--
From: Jean Delvare <[EMAIL PROTECTED]>
The smsc47m1 driver no longer creates the name attribute used by
libsensors to identify chip types. It was lost during the conversion
to a platform driver. I was fooled by the fact that we do have a
group with all attributes, but only to delete them all at once. The
group is not used to create the attributes, so we have to explicitly
create the name attribute.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/hwmon/smsc47m1.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/hwmon/smsc47m1.c
+++ b/drivers/hwmon/smsc47m1.c
@@ -585,6 +585,8 @@ static int __devinit smsc47m1_probe(stru
if ((err = device_create_file(dev, &dev_attr_alarms)))
goto error_remove_files;
+ if ((err = device_create_file(dev, &dev_attr_name)))
+ goto error_remove_files;
data->class_dev = hwmon_device_register(dev);
if (IS_ERR(data->class_dev)) {
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 01/20] hwmon: fix w83781d temp sensor type setting
-stable review patch. If anyone has any objections, please let us know. -- From: "Mark M. Hoffman" <[EMAIL PROTECTED]> Commit 348753379a7704087603dad403603e825422fd9a introduced a regression that caused temp2 and temp3 sensor type settings to be written to temp1 instead. The result is that temp sensor readings could be way off. Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/hwmon/w83781d.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/hwmon/w83781d.c +++ b/drivers/hwmon/w83781d.c @@ -740,9 +740,9 @@ store_sensor(struct device *dev, struct static SENSOR_DEVICE_ATTR(temp1_type, S_IRUGO | S_IWUSR, show_sensor, store_sensor, 0); static SENSOR_DEVICE_ATTR(temp2_type, S_IRUGO | S_IWUSR, - show_sensor, store_sensor, 0); + show_sensor, store_sensor, 1); static SENSOR_DEVICE_ATTR(temp3_type, S_IRUGO | S_IWUSR, - show_sensor, store_sensor, 0); + show_sensor, store_sensor, 2); /* I2C devices get this name attribute automatically, but for ISA devices we must create it by ourselves. */ -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 00/20] 2.6.22-stable review
This is the start of the stable review cycle for the 2.6.22.5 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by August 23 00:00:00 UTC 2007. Anything received after that time might be too late. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 20 Aug 2007, Arjan van de Ven wrote:
>
> On Mon, 2007-08-20 at 23:26 -0700, Linus Torvalds wrote:
> >
> > On Mon, 20 Aug 2007, Arjan van de Ven wrote:
> > >
> > > untested patch to add this to cpufreq; this is probably a good idea in
> > > general even if using the latency framework doesn't end up being used
> > > for fixing this regression...
> > >
> > >
> > > --- linux-2.6.23-rc2/drivers/cpufreq/cpufreq.c.org2007-08-20
> > > 22:58:32.0 -0700
> > > +++ linux-2.6.23-rc2/drivers/cpufreq/cpufreq.c2007-08-20
> > > 23:02:21.0 -0700
> > > @@ -1604,6 +1604,12 @@ static int __cpufreq_set_policy(struct c
> > > if (ret)
> > > goto error_out;
> > >
> > > +
> > > + if (system_latency_constraint() < policy->cpuinfo.transition_latency) {
> >
> > That looks broken. "system_latency_constraint()" is in us, but
> > transition_latency is in ns, afaik.
> >
> > But adding a "/ 1000" to turn the ns into us, and it migth even work.
>
>
> eh woops yes indeed.
> Shows me for not testing; I'll do that tomorrow when I'm more awake
Side note: I think we migth want to also have some way of telling the user
*why* we're not doing frequency changes. Maybe as simple as a rate-limited
printk() or something.
Otherwise, we'll easily be in a situation where some poor sod ends up
running constantly at lowest frequency, and no way of even seeing why.
Which sounds like a debugging nightmare.
If the kernel spits out the occasional warning about the latency
violation, at least we get notified about there being potential problems.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] why was MODALIAS removed from usb kernel events? [u]
Am Montag, 20. August 2007 schrieb Alan Stern: > I could, but I don't know whether any of this would be accepted for > 2.6.22.stable. It might not be too late to get into 2.6.23... even without it is a first step. I hope it gets accepted into both, as 2.6.22 broke kernel<->user space interfaces and those should never change (or only after a long time with announcement, time for switching to a new one etc). Thanks for your work! Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How Linux /proc filesystem convert a fd to the actual pathname?
Thanks! That perfectly answered my question. -x On 8/21/07, Kevin Hao <[EMAIL PROTECTED]> wrote: > > I am curious how Linux convert an fd to the pathname? Does it > > recursively walk back from current dentry to the root? > Using d_path. > > Can someone point me to the right place in the kernel where this > > functionality is implemented? > may be the function you want. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Monday 20 August 2007, Linus Torvalds wrote: > > On Mon, 20 Aug 2007, Linus Torvalds wrote: > > > > Ok. But in the meantime, I really think we should just revert the code > > that causes a known regression. > > Side note: one reason I'm interested in this is that my mac mini (now used > by the kids) has had a very flaky USB mouse lately. Is it related? I have > no idea, and probably not, but as a result I'm very interested in any USB > regressions. There's *something* rotten with that mouse, and while it > could be the mouse itself going bad, I think it started happening only > after updating that machine to 2.6.23-rc1. Try disabling USB_SUSPEND ... the rather aggressive powersave mechanism (autosuspend defaulting to always ON) has made lots of trouble. I think that default will change... - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 2007-08-20 at 23:26 -0700, Linus Torvalds wrote:
>
> On Mon, 20 Aug 2007, Arjan van de Ven wrote:
> >
> > untested patch to add this to cpufreq; this is probably a good idea in
> > general even if using the latency framework doesn't end up being used
> > for fixing this regression...
> >
> >
> > --- linux-2.6.23-rc2/drivers/cpufreq/cpufreq.c.org 2007-08-20
> > 22:58:32.0 -0700
> > +++ linux-2.6.23-rc2/drivers/cpufreq/cpufreq.c 2007-08-20
> > 23:02:21.0 -0700
> > @@ -1604,6 +1604,12 @@ static int __cpufreq_set_policy(struct c
> > if (ret)
> > goto error_out;
> >
> > +
> > + if (system_latency_constraint() < policy->cpuinfo.transition_latency) {
>
> That looks broken. "system_latency_constraint()" is in us, but
> transition_latency is in ns, afaik.
>
> But adding a "/ 1000" to turn the ns into us, and it migth even work.
eh woops yes indeed.
Shows me for not testing; I'll do that tomorrow when I'm more awake
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via
http://www.linuxfirmwarekit.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: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 2007-08-20 at 23:25 -0700, Linus Torvalds wrote: > Do we actually have the latency information for these things? Especially > since I assume a number of people use the specialized direct-hw-access > cpufreq drivers.. > > I realize that we *have* "transition_latency" at the cpufreq layer, and it > is supposed to be in ns, but I wonder how likely it is to bear any > relationship to reality, considering that I don't think it's really used > for anything.. (yeah, it affects the heuristics, but I don't think it has > any _hard_ meaning, so I'd worry that it's not necessarily something that > people have tried to make accurate). trusting the bios to be accurate for all machines is generally a ... well... it's like trusting politicians in election week. But it's sort of the best we got; at the same time, what are the odds that the time is more than an order of magnitude off? if the latency of the cpu is so large that the requirement ehci puts in is orders of magnitude more strict, a bit inaccurate data from the bios doesn't matter all that much. And worst case we make a table with quirks somehow (probably on cpu vendor/model I suppose) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.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/
Bad pte = e900b50d, process = ???
Dear all, I suddenly got flodded with Bad pte = e900b50d, process = ???, vm_flags = 100173, vaddr = bfc87ee2 [] vm_normal_page+0x3e/0x53 [] follow_page+0x90/0x147 [] get_user_pages+0x20f/0x261 [] access_process_vm+0x7e/0x163 [] vma_merge+0x171/0x17f [] proc_pid_cmdline+0x57/0xe7 [] proc_info_read+0x4a/0x9c [] proc_info_read+0x0/0x9c [] vfs_read+0xa6/0x128 [] sys_read+0x41/0x67 [] syscall_call+0x7/0xb === until the machine become unresponsive... Has anyone seen this before/what are the reasons for this ? This is on kernel 2.6.22.1... Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 20 Aug 2007, Arjan van de Ven wrote:
>
> untested patch to add this to cpufreq; this is probably a good idea in
> general even if using the latency framework doesn't end up being used
> for fixing this regression...
>
>
> --- linux-2.6.23-rc2/drivers/cpufreq/cpufreq.c.org2007-08-20
> 22:58:32.0 -0700
> +++ linux-2.6.23-rc2/drivers/cpufreq/cpufreq.c2007-08-20
> 23:02:21.0 -0700
> @@ -1604,6 +1604,12 @@ static int __cpufreq_set_policy(struct c
> if (ret)
> goto error_out;
>
> +
> + if (system_latency_constraint() < policy->cpuinfo.transition_latency) {
That looks broken. "system_latency_constraint()" is in us, but
transition_latency is in ns, afaik.
But adding a "/ 1000" to turn the ns into us, and it migth even work.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 20 Aug 2007, Arjan van de Ven wrote: > > > > So it might be much better if we instead re-introduced that kind of "DMA > > latency requirement", and letting different subsystems react to that as > > they may. > > wait we HAVE that infrastructure .. see kernel/latency.c ... Heh. Just shows how wellknown that interface is - it seems like it's only used by the ipw2100 driver and "pcm_native". But yes, that looks like the right thing. > and the C-state code will honor it. CPUFREQ doesn't honor it yet but > that's easy to add.. (this assumes the ACPI BIOS informs us correctly > about the cpu behavior, but that's the best we can do obviously unless > you want a table inside the kernel keyed off vendor/model/stepping) Do we actually have the latency information for these things? Especially since I assume a number of people use the specialized direct-hw-access cpufreq drivers.. I realize that we *have* "transition_latency" at the cpufreq layer, and it is supposed to be in ns, but I wonder how likely it is to bear any relationship to reality, considering that I don't think it's really used for anything.. (yeah, it affects the heuristics, but I don't think it has any _hard_ meaning, so I'd worry that it's not necessarily something that people have tried to make accurate). But I dunno. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 2007-08-20 at 22:51 -0700, Arjan van de Ven wrote:
> and the C-state code will honor it. CPUFREQ doesn't honor it yet but
> that's easy to add..
untested patch to add this to cpufreq; this is probably a good idea in
general even if using the latency framework doesn't end up being used
for fixing this regression...
--- linux-2.6.23-rc2/drivers/cpufreq/cpufreq.c.org 2007-08-20
22:58:32.0 -0700
+++ linux-2.6.23-rc2/drivers/cpufreq/cpufreq.c 2007-08-20 23:02:21.0
-0700
@@ -1604,6 +1604,12 @@ static int __cpufreq_set_policy(struct c
if (ret)
goto error_out;
+
+ if (system_latency_constraint() < policy->cpuinfo.transition_latency) {
+ ret = -EINVAL;
+ goto error_out;
+ }
+
/* notification of the new policy */
blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
CPUFREQ_NOTIFY, policy);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] tty_io.c: don't use flush_scheduled_work()
On Thu, Aug 16, 2007 at 02:53:50PM +0300, Dan Aloni wrote: > On Sun, Jul 01, 2007 at 07:37:49PM +0400, Oleg Nesterov wrote: > > I don't know how to test this patch, the ack/nack from maintainer is wanted. > > > > flush_scheduled_work() is evil and should be avoided. Change tty_set_ldisc() > > and release_dev() to use cancel_delayed_work_sync/cancel_work_sync. > > > > I am not sure we really need to call do_tty_hangup() when cancel_work_sync() > > returns true, but this matches the current behaviour. > > I also noticed this problem recently with 2.6.22, on a 2-CPU box where there > was one SCHED_RR userspace process stuck in a busy loop. The box was > completely IMHO, it was rather a busy sleep. > responsive but had this annoyance where all tty closings were stuck in > flush_scheduled_work(). It's especially noticable when you ssh to the machine > and then try to log out. > > A temporary workaround was to give just the workqueue events/* threads a > SCHED_FIFO static priority of 99, but I have kept that small patch to > myself (figured it's just too nasty). It looks like there was something more than this one SCHED_RR: probably some high priority task(s) could have preempted workqueue thread, delaying run_workqueues. Then it should be an interesting test for this new, 2.6.23 scheduler. Regards, Jarek P. PS: sorry for so delayed responsing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uncached page allocator
> Blame intel ;) > > > Any other ideas and suggestions? > > Without knowing exactly what you are doing: > > - Copies to uncached memory are very expensive on an x86 processor > (so it might be faster not to write and flush) > - Its not clear from your description how intelligent your transfer > system is. It is still possible to change the transfer system, but it should be intelligent enough or possible to make it more intelligent.. I also realise I need PAT + write combining but I believe this problem is othogonal... > > I'd expect for example that the process was something like > > Parse pending commands until either > 1. Queue empties > 2. A time target passes > > For each command we need to shove a pixmap over add it > to the buffer to transfer > > Do a single CLFLUSH and maybe IPI > > Fire up the command queue > > Keep the buffers hanging around until there is memory pressure > if we may reuse that pixmap > > Can you clarify that ? So at the moment a pixmap maps directly to a kernel buffer object which is a bunch of pages that get faulted in on the CPU or allocated when the buffer is to be used by the GPU. So when a pixmap is created a buffer object is created, when a pixmap is destroyed a buffer object is destroyed. Perhaps I can cache a bunch of buffer objects in userspace for re-use as pixmaps but I'm not really sure that will scale too well. When X wishes the GPU to access a buffer (pixmap), it calls into the kernel with a single ioctl with a list of all buffers the GPU is going to access along with a buffer containing the command to do the access, now at the moment, when each of those buffers is bound into the GART for the first time the system does a change_page_attr for each page and calls the global flush[1]. Now if a buffer is bound into the GART and gets accessed from the CPU later again (software fallback) we have the choice of taking it back out of the GART and letting the nopfn call fault back in the pages uncached or we can flush the tlb and bring them back in cached. We are hoping to avoid software fallbacks on the hardware platforms we want to work on as much as possible. Finally when a buffer is destroyed, the pages are released back to the system, so of course the pages are set back to cached and we need another tlb/cache flush per pixmap buffer destructor. So you can see why some sort of uncached+writecombined page cache would be useful, I could just allocate a bunch of pages at startup as uncached+writecombined, and allocate pixmaps from them and when I bind/free the pixmap I don't need the flush at all, now I'd really like this to be part of the VM so that under memory pressure it can just take the pages I've got in my cache back and after flushing turn them back into cached pages, the other option is for the DRM to do this on its own and penalise the whole system. [1]. (this is one inefficiency in that if multiple buffers are being bound in for the first time it'll flush for each of them, I'm trying to get rid of this inefficiency but I may need to tweak the order of things as at the moment, it crashes hard if I tried to leave the cache/tlb flush until later.) Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uncached page allocator
> > Write-combining access seems the correct thing here, followed by a > wmb(). Uncached writing would be horrendously slow. > > [snip] > > So after all that I'd like to have some sort of uncached page list I > > can allocate pages from > > This is exactly what Intel's PAT mechanism exists for - just mark the > desired access type (index) on the pages you've been allocated. > > It's documented in the Intel Architecture Software Design manuals, but > Linux's support is lacking in certain areas [discussions on LKML], > which a number of developers have been trying to move forward. > > Quite a few significant graphics/HPC etc vendors are forced to use it > without this complete support, so it would be good to get this > additional impetus involved... I'm hoping to pick up the PAT cause at some point soon this stuff is definitely required to get any use out of modern graphics hardware. It is slightly orthogonal to the issue I mentioned in that I still have the problem of allocating uncached memory without the flushing overheads associated with making pages cached/uncached constantly.. Dave. > > Daniel > -- > Daniel J Blueman > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How Linux /proc filesystem convert a fd to the actual pathname?
> I am curious how Linux convert an fd to the pathname? Does it > recursively walk back from current dentry to the root? Using d_path. > Can someone point me to the right place in the kernel where this > functionality is implemented? do_proc_readlink may be the function you want. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 20 Aug 2007, Linus Torvalds wrote: > > Ok. But in the meantime, I really think we should just revert the code > that causes a known regression. Side note: one reason I'm interested in this is that my mac mini (now used by the kids) has had a very flaky USB mouse lately. Is it related? I have no idea, and probably not, but as a result I'm very interested in any USB regressions. There's *something* rotten with that mouse, and while it could be the mouse itself going bad, I think it started happening only after updating that machine to 2.6.23-rc1. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
> Have we done that? Yes. We actually had a "no-hlt" kernel command line
> flag that literally disabled halting the CPU, because it apparently caused
> problems for some floppy disk setups (and yes, the main reasonable
> explanation was some bad DMA interaction, we never figured it out).
>
> So it might be much better if we instead re-introduced that kind of "DMA
> latency requirement", and letting different subsystems react to that as
> they may.
wait we HAVE that infrastructure .. see kernel/latency.c ...
> It really can affect more than just cpufreq - I would not be in the
> *least* surprised if C3 latencies and other things can cause these things
> too! But even within cpufreq, it's quite likely to hit certain situations
> more than others.
and kernel/latency.c was designed EXACTLY for that reason. All the USB
layer has to do is to announce it's latency requirement like this:
/*
* Some broadcom chips are buggy and can't take more than 5 usec as DMA
* latency; inform the rest of kernel of this.
*/
if (weird_broadcom_chip())
set_acceptable_latency("ehci", 5);
and the C-state code will honor it. CPUFREQ doesn't honor it yet but
that's easy to add.. (this assumes the ACPI BIOS informs us correctly
about the cpu behavior, but that's the best we can do obviously unless
you want a table inside the kernel keyed off vendor/model/stepping)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via
http://www.linuxfirmwarekit.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: [PATCH 0/24] make atomic_read() behave consistently across all architectures
On Mon, 20 Aug 2007, Chris Snook wrote: > > What about barrier removal? With consistent semantics we could optimize a > fair amount of code. Whether or not that constitutes "premature" optimization > is open to debate, but there's no question we could reduce our register wiping > in some places. Why do people think that barriers are expensive? They really aren't. Especially the regular compiler barrier is basically zero cost. Any reasonable compiler will just flush the stuff it holds in registers that isn't already automatic local variables, and for regular kernel code, that tends to basically be nothing at all. Ie a "barrier()" is likely _cheaper_ than the code generation downside from using "volatile". Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Fix mainline filesystems to handle ATTR_KILL_ bits correctly
Jeff Layton wrote:
This should fix all of the filesystems in the mainline kernels to handle
ATTR_KILL_SUID and ATTR_KILL_SGID correctly. For most of them, this is
just a matter of making sure that they call generic_attrkill early in
the setattr inode op.
Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/xfs_iops.c |5 -
--- a/fs/xfs/linux-2.6/xfs_iops.c
+++ b/fs/xfs/linux-2.6/xfs_iops.c
@@ -651,12 +651,15 @@ xfs_vn_setattr(
struct iattr*attr)
{
struct inode*inode = dentry->d_inode;
- unsigned intia_valid = attr->ia_valid;
+ unsigned intia_valid;
bhv_vnode_t *vp = vn_from_inode(inode);
bhv_vattr_t vattr = { 0 };
int flags = 0;
int error;
+ generic_attrkill(inode->i_mode, attr);
+ ia_valid = attr->ia_valid;
+
if (ia_valid & ATTR_UID) {
vattr.va_mask |= XFS_AT_UID;
vattr.va_uid = attr->ia_uid;
Looks reasonable to me for XFS.
Acked-by: Tim Shimmin <[EMAIL PROTECTED]>
So before, this clearing would happen directly in notify_change()
and now this won't happen until notify_change() calls i_op->setattr
which for a particular fs it can call generic_attrkill() to do it.
So I guess for the cases where i_op->setattr is called outside of
via notify_change, we don't normally have ATTR_KILL_SUID/SGID
set so that nothing will happen there?
I guess just wondering the effect with having the code on all
setattr's. (I'm not familiar with the code path)
--Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] PCI: disable MSI on RX790
RX790 can't do MSI like its predecessors. Disable MSI on RX790. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- Okay, another one from ATI which can't do MSI. 2.6.23 material. drivers/pci/quirks.c|1 + include/linux/pci_ids.h |1 + 2 files changed, 2 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 67e375d..d8a2e44 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1651,6 +1651,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT1 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RD580, quirk_disable_all_msi); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RX790, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS690, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3351, quirk_disable_all_msi); diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index dc79fea..5acfeb7 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -361,6 +361,7 @@ #define PCI_DEVICE_ID_ATI_RS400_200 0x5a33 #define PCI_DEVICE_ID_ATI_RS480 0x5950 #define PCI_DEVICE_ID_ATI_RD5800x5952 +#define PCI_DEVICE_ID_ATI_RX7900x5957 #define PCI_DEVICE_ID_ATI_RS6900x7910 /* ATI IXP Chipset */ #define PCI_DEVICE_ID_ATI_IXP200_IDE 0x4349 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How Linux /proc filesystem convert a fd to the actual pathname?
>In the Linux proc filesystem, /proc/[pid]/fd is a link to the >actually the actual pathname of the opened file. > >I am curious how Linux convert an fd to the pathname? Does it >recursively walk back from current dentry to the root? AFAICS the fd has a pointer to the vma of the file (don't ask me why), which in turn has a 'struct file' pointer, which in turn has the required 'struct dentry' in it. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 20 Aug 2007, David Brownell wrote: > On Monday 20 August 2007, Linus Torvalds wrote: > > > > Fair enough. However, it still seems particularly idiotic to > > - penalize everybody > > - mix up two totally unrelated areas (cpufreq and USB) for a bug that is > >extremely rare and could be handled differently. > > Yes on #1, but on #2 ... frequency transitions are a common place > for systems to want to hiccup. I disagree - it's extremely rare. We've probably had more *software* problems with cpufreq than we've had real hardware problems (ie all the locking for cpufreq has been pretty painful). It's also something that probably depends a lot on the particular CPU. Some CPU's have very short PLL relocking, and continue running while the voltage is changed. Others seem to stop for much longer times. This is not somethign that the USB layer should stick its fingers in - because quite frankly, it really doesn't have a clue. > Maybe less so on PCs, but it's hard to say that re-clocking an I/O or > memory bus shouldn't affect the peripherals using it for "realtime" > (deadlines) I/O !! Normally the memory bus isn't reclocked (it's *possible* to do, but it's complex and can be quite fragile). I think the issue was just that the CPU itself was reclocked, and had long latencies for probing the cache. Not unlike a sleep state: there can be long DMA latencies just from the CPU being in S1! So adding this special case for CPU frequency is not at all unlike adding a special case saying that the CPU cannot go into "halt" state, because the DMA latency is too high. Have we done that? Yes. We actually had a "no-hlt" kernel command line flag that literally disabled halting the CPU, because it apparently caused problems for some floppy disk setups (and yes, the main reasonable explanation was some bad DMA interaction, we never figured it out). So it might be much better if we instead re-introduced that kind of "DMA latency requirement", and letting different subsystems react to that as they may. It really can affect more than just cpufreq - I would not be in the *least* surprised if C3 latencies and other things can cause these things too! But even within cpufreq, it's quite likely to hit certain situations more than others. (Of course, if C3 latencies are high on a MB that has known DMA latency issues, you'd hope that the BIOS has simply disabled C3 entirely in the ACPI tables) > transitions if the Broadcom chipset (or maybe it's just specific > boards?) finds itself in the awkward configuration ... penalizing > only the people we know could have trouble. Yes, that would be more acceptable, I think. It is also quite likely that this is not a generic cpufreq issue, but one that happens with just a certain class of CPU's - ie some particular CPU that is just slower than others at re-clocking. Just disabling things blindly on cpufreq events, when what it actually wants to do is say "I need low DMA latency", and then the cpu-freq layer (which can know about these things) may decide internally that it knows that a particular setup is not able to have low-latency DMA durign frequency relocking. On other - saner - CPU's, the frequency relock may take a fraction of the time, and the CPU is running perfectly the whole time - and it would _not_ be affected. > > As far as I know, split transactions aren't required anyway, they are just > > a performance optimization. > > Nope. Linus, this is at least the second or third time you've > been wrong -- sorry. But I wish you were right, since they're > such a PITA to cope with. ;) > > Split transactions are how the full and low speed devices bridge > to high speed busses. Think of the TT hub as a speed converter, > buffering data and then retransmitting it at the other (slower or > faster) speed. Some systems don't even have a full/low speed host > adapter ... they just have a high speed root hub and rely on some > external TT hubs (maybe on a mainboard) to handle the rest. Ok. But in the meantime, I really think we should just revert the code that causes a known regression. Because, quite frankly, you may not like VIA, but in the bigger picture, VIA has been a hell of a lot better than Broadcom. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH take #6] [libata] libata driver for bf548 on chip ATAPI controller.
Fix all issues pointed out in Jeff's email. Acked-by: Alan Cox <[EMAIL PROTECTED]> Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]> --- drivers/ata/Kconfig | 16 drivers/ata/Makefile |1 drivers/ata/pata_bf54x.c | 1627 +++ 3 files changed, 1644 insertions(+) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index b4a8d60..72df596 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -583,4 +588,20 @@ config PATA_SCC If unsure, say N. +config PATA_BF54X + tristate "Blackfin 54x ATAPI support" + depends on BF542 || BF548 || BF549 + help + This option enables support for the built-in ATAPI controller on + Blackfin 54x family chips. + + If unsure, say N. + +config PATA_BF54X_DMA + bool "DMA mode" + depends on PATA_BF54X + default y + help + Enable DMA mode for Blackfin ATAPI controller. + endif # ATA diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index 8149c68..c2ecba5 100644 --- a/drivers/ata/Makefile +++ b/drivers/ata/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_PATA_SIS)+= pata_sis.o obj-$(CONFIG_PATA_TRIFLEX) += pata_triflex.o obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o obj-$(CONFIG_PATA_SCC) += pata_scc.o +obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o obj-$(CONFIG_PATA_PLATFORM)+= pata_platform.o obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o # Should be last but one libata driver diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c new file mode 100644 index 000..747549e --- /dev/null +++ b/drivers/ata/pata_bf54x.c @@ -0,0 +1,1627 @@ +/* + * File: drivers/ata/pata_bf54x.c + * Author: Sonic Zhang <[EMAIL PROTECTED]> + * + * Created: + * Description: PATA Driver for blackfin 54x + * + * Modified: + * Copyright 2007 Analog Devices Inc. + * + * Bugs: Enter bugs at http://blackfin.uclinux.org/ + * + * 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, see the file COPYING, or write + * to the Free Software Foundation, Inc., + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRV_NAME "pata-bf54x" +#define DRV_VERSION"0.9" + +#define ATA_REG_CTRL 0x0E +#define ATA_REG_ALTSTATUS ATA_REG_CTRL + +/* These are the offset of the controller's registers */ +#define ATAPI_OFFSET_CONTROL 0x00 +#define ATAPI_OFFSET_STATUS0x04 +#define ATAPI_OFFSET_DEV_ADDR 0x08 +#define ATAPI_OFFSET_DEV_TXBUF 0x0c +#define ATAPI_OFFSET_DEV_RXBUF 0x10 +#define ATAPI_OFFSET_INT_MASK 0x14 +#define ATAPI_OFFSET_INT_STATUS0x18 +#define ATAPI_OFFSET_XFER_LEN 0x1c +#define ATAPI_OFFSET_LINE_STATUS 0x20 +#define ATAPI_OFFSET_SM_STATE 0x24 +#define ATAPI_OFFSET_TERMINATE 0x28 +#define ATAPI_OFFSET_PIO_TFRCNT0x2c +#define ATAPI_OFFSET_DMA_TFRCNT0x30 +#define ATAPI_OFFSET_UMAIN_TFRCNT 0x34 +#define ATAPI_OFFSET_UDMAOUT_TFRCNT0x38 +#define ATAPI_OFFSET_REG_TIM_0 0x40 +#define ATAPI_OFFSET_PIO_TIM_0 0x44 +#define ATAPI_OFFSET_PIO_TIM_1 0x48 +#define ATAPI_OFFSET_MULTI_TIM_0 0x50 +#define ATAPI_OFFSET_MULTI_TIM_1 0x54 +#define ATAPI_OFFSET_MULTI_TIM_2 0x58 +#define ATAPI_OFFSET_ULTRA_TIM_0 0x60 +#define ATAPI_OFFSET_ULTRA_TIM_1 0x64 +#define ATAPI_OFFSET_ULTRA_TIM_2 0x68 +#define ATAPI_OFFSET_ULTRA_TIM_3 0x6c + + +#define ATAPI_GET_CONTROL(base)\ + bfin_read16(base + ATAPI_OFFSET_CONTROL) +#define ATAPI_SET_CONTROL(base, val)\ + bfin_write16(base + ATAPI_OFFSET_CONTROL, val) +#define ATAPI_GET_STATUS(base)\ + bfin_read16(base + ATAPI_OFFSET_STATUS) +#define ATAPI_GET_DEV_ADDR(base)\ + bfin_read16(base + ATAPI_OFFSET_DEV_ADDR) +#define ATAPI_SET_DEV_ADDR(base, val)\ + bfin_write16(base + ATAPI_OFFSET_DEV_ADDR, val) +#define ATAPI_GET_DEV_TXBUF(base)\ + bfin_read16(base + ATAPI_OFFSET_DEV_TXBUF) +#define ATAPI_SET_DEV_TXBUF(base, val)\ + bfin_write16(base + ATAPI_OFFSET_DEV_TXBUF, val) +#define ATAPI_GET_DEV_RXBUF(base)\ + bfin_read16(base + ATAPI_OFFSET_DEV_R
Re: [PATCH][bugzilla #8679] therm_throt.c: Fix section mismatch
On Mon, 20 Aug 2007 22:03:28 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > register_hotcpu_notifier() is cunning. If CONFIG_HOTPLUG_CPU=y, we need > the notifier block and the function to which it points to be in .data and > in .text. If CONFIG_HOTPLUG_CPU=n, we don't need them to be present at all. > > So what we can do is to just leave the notifier block in .data and the > function in .text and then the compiler/linker will notice that nothing > references them and they will be omitted at build time. As long as the notifier block and the function are static. I don't think the toolchain is smart enough to remove them if they have global scope, but I didn't check 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][bugzilla #8679] therm_throt.c: Fix section mismatch
On Tue, 21 Aug 2007 10:07:31 +0530 (IST) Satyam Sharma <[EMAIL PROTECTED]>
wrote:
>
> WARNING: arch/i386/kernel/built-in.o(.data+0x2148): Section mismatch:
> reference
> to .init.text: (between 'thermal_throttle_cpu_notifier' and 'mtrr_mutex')
>
> comes because struct notifier_block thermal_throttle_cpu_notifier in
> arch/i386/kernel/cpu/mcheck/therm_throt.c goes in .data section but
> the notifier callback function itself has been marked __cpuinit which
> becomes __init == .init.text when HOTPLUG_CPU=n. The warning is bogus
> because the callback will never be called out if HOTPLUG_CPU=n in the
> first place (as one can see from kernel/cpu.c, the cpu_chain itself
> is __cpuinitdata :-)
>
> So, let's mark thermal_throttle_cpu_notifier as __cpuinitdata to fix
> the section mismatch warning.
>
> Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
>
> ---
>
> [The other section mismatch mentioned in bugzilla #8679 is already fixed.]
>
> arch/i386/kernel/cpu/mcheck/therm_throt.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/i386/kernel/cpu/mcheck/therm_throt.c
> b/arch/i386/kernel/cpu/mcheck/therm_throt.c
> index 1203dc5..494d320 100644
> --- a/arch/i386/kernel/cpu/mcheck/therm_throt.c
> +++ b/arch/i386/kernel/cpu/mcheck/therm_throt.c
> @@ -152,7 +152,7 @@ static __cpuinit int thermal_throttle_cpu_callback(struct
> notifier_block *nfb,
> return NOTIFY_OK;
> }
>
> -static struct notifier_block thermal_throttle_cpu_notifier =
> +static struct notifier_block thermal_throttle_cpu_notifier __cpuinitdata =
> {
> .notifier_call = thermal_throttle_cpu_callback,
> };
okay... However we're not being very consistent here.
register_hotcpu_notifier() is cunning. If CONFIG_HOTPLUG_CPU=y, we need
the notifier block and the function to which it points to be in .data and
in .text. If CONFIG_HOTPLUG_CPU=n, we don't need them to be present at all.
So what we can do is to just leave the notifier block in .data and the
function in .text and then the compiler/linker will notice that nothing
references them and they will be omitted at build time.
So basically, the register_hotcpu_notifier() implementation (in league with
the compiler) is taking the place of the manual notations.
Note that because this works at compile time, it is also effective within
modules. I'm not sure that we discard the unneeded sections from within
modules? (I forget).
So... what to do? I guess for consistency one could hunt down all the
register_hotcpu_notifier() sites and remove all the __initfoo tags from all of
them. But that makes register_hotcpu_notifier() inconsistent from
everything else, so there's an argument that we should make all these
things __cpuinit and __cpuinitdata for consistency rather than relying upon
register_hotcpu_notifier()'s magical properties as a special case. Dunno.
There are a few things to clear up here...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] x86_64 EFI runtime service support
On Mon, 2007-08-20 at 20:54 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >
> > I think the "next" field can be u32 instead of u64. Because the linked
> > list of struct setup_data is prepared by bootloader, which can control
> > the memory location.
> >
>
> That's making some pretty serious assumptions on future boot loaders and
> environments.
I think this assumption is reasonable. The range of u32 is big enough
for a boot protocol. Do we need to convert that to u128, when 128-bit
machine emerges?
I think there is another possible scheme. An array with variable length
element instead of a linked list can be used too. The type of element is
as follow:
struct setup_data {
u32 type;
u32 len;
u8 data[0];
};
The next element is at (char *)&setup_data + len. The boot information
will be held in a block of memory. This makes initial memory mapping of
kernel more easily. And the memory location of boot information may need
to be kept in a limited range too.
> > As for the magic number in zero page, do you think it should be used
> > only by 16-bit kernel setup code?
>
> Absolutely not.
If a old boot loader (not aware of magic number) is used to load the new
kernel image. The old boot loader will set the magic number to zero.
Does this mean that the new kernel image can not be booted by the old
boot loader.
Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Monday 20 August 2007, Linus Torvalds wrote: > > On Mon, 20 Aug 2007, David Brownell wrote: > > > > MMF basically means the "Transaction Translating" (TT) hub had data > > for the host, but the host didn't collect it in time ... so that some > > data was lost. > > > > Unfortunately, that's the type of fault that's especially hard to > > recover from. > > Fair enough. However, it still seems particularly idiotic to > - penalize everybody > - mix up two totally unrelated areas (cpufreq and USB) for a bug that is >extremely rare and could be handled differently. Yes on #1, but on #2 ... frequency transitions are a common place for systems to want to hiccup. Maybe less so on PCs, but it's hard to say that re-clocking an I/O or memory bus shouldn't affect the peripherals using it for "realtime" (deadlines) I/O !! My more complete response suggested maybe just vetoing cpufreq transitions if the Broadcom chipset (or maybe it's just specific boards?) finds itself in the awkward configuration ... penalizing only the people we know could have trouble. > For example, if it really ends up being practically impossible to recover > from split transaction errors, I would still suggest reverting that horrid > commit, and then just black-listing the known-broken EHCI controllers and > simply not *do* any split transactions on them. That way there's no > complexity. > > As far as I know, split transactions aren't required anyway, they are just > a performance optimization. Nope. Linus, this is at least the second or third time you've been wrong -- sorry. But I wish you were right, since they're such a PITA to cope with. ;) Split transactions are how the full and low speed devices bridge to high speed busses. Think of the TT hub as a speed converter, buffering data and then retransmitting it at the other (slower or faster) speed. Some systems don't even have a full/low speed host adapter ... they just have a high speed root hub and rely on some external TT hubs (maybe on a mainboard) to handle the rest. > Basically, we not only know that the commit has caused problems, it's > fundamentally ugly, fragile, and not very maintainable, and the whole > reason for doing it is pretty dubious. > > Why not just admit that certain hardware is broken (and the vendor isn't > worth even bothering to be polite with, since they try to screw us every > chance they get) and cannot reliably do split transactions? Problem > solved, no real downside, and nobody will even *notice*. Well, I suggested an alternate fix that I hope Stuart will look at. I think it achieves your goals (only impacting Broadcom systems). - Dave > > Linus > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22.4
diff --git a/Makefile b/Makefile
index bc2d377..f2a62ee 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 22
-EXTRAVERSION = .3
+EXTRAVERSION = .4
NAME = Holy Dancing Manatees, Batman!
# *DOCUMENTATION*
diff --git a/fs/exec.c b/fs/exec.c
index f20561f..9a93770 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -890,9 +890,12 @@ int flush_old_exec(struct linux_binprm * bprm)
*/
current->mm->task_size = TASK_SIZE;
- if (bprm->e_uid != current->euid || bprm->e_gid != current->egid ||
- file_permission(bprm->file, MAY_READ) ||
- (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP)) {
+ if (bprm->e_uid != current->euid || bprm->e_gid != current->egid) {
+ suid_keys(current);
+ current->mm->dumpable = suid_dumpable;
+ current->pdeath_signal = 0;
+ } else if (file_permission(bprm->file, MAY_READ) ||
+ (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP)) {
suid_keys(current);
current->mm->dumpable = suid_dumpable;
}
@@ -983,8 +986,10 @@ void compute_creds(struct linux_binprm *bprm)
{
int unsafe;
- if (bprm->e_uid != current->uid)
+ if (bprm->e_uid != current->uid) {
suid_keys(current);
+ current->pdeath_signal = 0;
+ }
exec_keys(current);
task_lock(current);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.22.4
We (the -stable team) are announcing the release of the 2.6.22.4 kernel. It contains one security fix and all users of the 2.6.22 series are encouraged to upgrade to it. I'll also be replying to this message with a copy of the patch between 2.6.22.3 and 2.6.22.4 The updated 2.6.22.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=summary thanks, greg k-h Makefile |2 +- fs/exec.c | 13 + 2 files changed, 10 insertions(+), 5 deletions(-) Summary of changes from v2.6.22.3 to v2.6.22.4 == Greg Kroah-Hartman (1): Linux 2.6.22.4 Marcel Holtmann (1): Reset current->pdeath_signal on SUID binary execution (CVE-2007-3848) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] alsa: replace calls to sys_* with filp_open and vfs_read
This patch replaces calls to sys_* with filp_open and vfs_read. And since this
is the last driver in the kernel that uses sys_{read,close}, it kills the
exports as well. sys_open is left exported for sparc64 only.
Cc: Takashi Iwai <[EMAIL PROTECTED]>
Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
fs/open.c |4 +-
fs/read_write.c |1 -
sound/isa/wavefront/wavefront_synth.c | 47 +++-
3 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/fs/open.c b/fs/open.c
index 1d9e5e9..dc121ce 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -1056,7 +1056,9 @@ asmlinkage long sys_open(const char __user *filename, int
flags, int mode)
prevent_tail_call(ret);
return ret;
}
+#ifdef CONFIG_SPARC64
EXPORT_SYMBOL_GPL(sys_open);
+#endif
asmlinkage long sys_openat(int dfd, const char __user *filename, int flags,
int mode)
@@ -1148,8 +1150,6 @@ out_unlock:
return -EBADF;
}
-EXPORT_SYMBOL(sys_close);
-
/*
* This routine simulates a hangup on the tty, to arrange that users
* are given clean terminals at login time.
diff --git a/fs/read_write.c b/fs/read_write.c
index 507ddff..d913d1e 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -370,7 +370,6 @@ asmlinkage ssize_t sys_read(unsigned int fd, char __user *
buf, size_t count)
return ret;
}
-EXPORT_SYMBOL_GPL(sys_read);
asmlinkage ssize_t sys_write(unsigned int fd, const char __user * buf, size_t
count)
{
diff --git a/sound/isa/wavefront/wavefront_synth.c
b/sound/isa/wavefront/wavefront_synth.c
index bacc51c..40eefa2 100644
--- a/sound/isa/wavefront/wavefront_synth.c
+++ b/sound/isa/wavefront/wavefront_synth.c
@@ -1941,8 +1941,6 @@ wavefront_reset_to_cleanliness (snd_wavefront_t *dev)
#include
#include
#include
-#include
-#include
#include
@@ -1953,10 +1951,10 @@ wavefront_download_firmware (snd_wavefront_t *dev, char
*path)
unsigned char section[WF_SECTION_MAX];
signed char section_length; /* yes, just a char; max value is
WF_SECTION_MAX */
int section_cnt_downloaded = 0;
- int fd;
- int c;
- int i;
- mm_segment_t fs;
+ int c, i, ret = 0;
+ mm_segment_t fs = get_fs();
+ struct file *filp;
+ loff_t pos;
/* This tries to be a bit cleverer than the stuff Alan Cox did for
the generic sound firmware, in that it actually knows
@@ -1968,20 +1966,20 @@ wavefront_download_firmware (snd_wavefront_t *dev, char
*path)
42 bytes (well, WF_SECTION_MAX) long.
*/
- fs = get_fs();
- set_fs (get_ds());
+ set_fs(get_ds());
- if ((fd = sys_open ((char __user *) path, 0, 0)) < 0) {
- snd_printk ("Unable to load \"%s\".\n",
- path);
+ filp = filp_open(path, 0, 0);
+ if (IS_ERR(filp)) {
+ snd_printk("Unable to load \"%s\".\n", path);
return 1;
}
while (1) {
int x;
- if ((x = sys_read (fd, (char __user *) §ion_length, sizeof
(section_length))) !=
- sizeof (section_length)) {
+ pos = filp->f_pos;
+ x = vfs_read(filp, (char __user *) §ion_length,
sizeof(section_length), &pos);
+ if (x != sizeof(section_length)) {
snd_printk ("firmware read error.\n");
goto failure;
}
@@ -1996,9 +1994,10 @@ wavefront_download_firmware (snd_wavefront_t *dev, char
*path)
goto failure;
}
- if (sys_read (fd, (char __user *) section, section_length) !=
section_length) {
- snd_printk ("firmware section "
- "read error.\n");
+ pos = filp->f_pos;
+ x = vfs_read(filp, (char __user *) section, section_length,
&pos);
+ if (x != section_length) {
+ snd_printk ("firmware section read error.\n");
goto failure;
}
@@ -2034,19 +2033,17 @@ wavefront_download_firmware (snd_wavefront_t *dev, char
*path)
}
}
+ goto success;
- sys_close (fd);
- set_fs (fs);
- return 0;
-
- failure:
- sys_close (fd);
- set_fs (fs);
+failure:
+ ret = 1;
snd_printk ("firmware download failed!!!\n");
- return 1;
+success:
+ filp_close(filp, current->files);
+ set_fs (fs);
+ return ret;
}
-
static int __devinit
wavefront_do_reset (snd_wavefront_t *dev)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
[ GRR sorry for the premature "SEND" ... mouspads-r-evil ] On Monday 20 August 2007, Linus Torvalds wrote: > > On Mon, 20 Aug 2007, David Brownell wrote: > > > On Monday 13 August 2007, Michal Piotrowski wrote: > > > Subject     : EHCI Regression in 2.6.23-rc2 > > > References    : http://lkml.org/lkml/2007/8/10/81 > > > Last known good : ? > > > Submitter    : Daniel Exner <[EMAIL PROTECTED]> > > > Caused-By    : [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > >          commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 > > > Handled-By    : ? > > > Status      : unknown > > > > Fixed I believe by Stuart's patch: > > > > http://marc.info/?l=linux-usb-devel&m=118765934722610&w=2 > > Quite frankly, I'd personally prefer to just revert commit > 196705c9bbc03540429b0f7cf9ee35c2f928a534 entirely instead. > > The whole dependency on cpufreq seems totally bogus. Would it not be a lot > more natural to handle the *result* of the problem (ie the MMF errors by > broken EHCI controllers?) rather than add totally insane workarounds for > this case to try to hide them in the first place? MMF basically means the "Transaction Translating" (TT) Hub had data for the host, but the host didn't collect it in time ... so that some data was lost. In this context, it's only for periodic transfers, meaning interrupt (for HID keyboards, mice, etc) or isochronous (mostly audio or video, but sometimes ATM). Unfortunately, that's the type of fault that's especially hard to recover from. Plus, very few of the upper layer drivers have even a minor clue about fault recovery strategies during I/O ... it's not supposed to happen for interrupt transfers, one hopes the drivers will at least die gracefully. With ISO, faults are expected (since it's "best effort" delivery, time-priority). On the plus side, MMF errors have been vanishingly rare until this cpufreq interaction came up ... which of course implies the downside that those "handle the result" code paths are all but untested. > There can be *other* delays in reading memory that have nothing to do with > cpu frequency shifting, and everything to do with exteme situations on the > bus. If the stupid EHCI controller has some tight latency issues, that's a > generic problem. There could be such problems, yes. But in practice, I don't know that we've ever seen them. (There's a first time for everthing, yes. I *just* fetched a webpage where an image got overwritten about half way through fetching it. Top half was today's, bottom half was tomorrow's, update 12 midnight EST. Strangest looking JPG ever! ;) > That commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 just exemplifies what > is wrong with USB, but it does so by adding incredibly ugly code. I'd > rather not add even *more* ugly code - especially not for a case where we > then seem to blame the wrong party (ie a VIA controller that didn't need > the ugly code in the first place). > > Serverworks/Broadcom makes totally crap chips (not just in USB) and then > doesn't even document their buggy crap hardware. That's pretty much how I feel about VIA's USB stuff: buggy crap that I actively steer people away from. And that's why it doesn't seem odd to me to add even more workarounds for VIA-only bugs. > But that is NOT a reason > for then making the kernel have buggy crap software in it. I don't think we always have the option not to cope with broken hardware. We may have some options about *how* we cope with it though ... > So really - is there any reason why we just don't say "Broadcom chips > suck, and get MMF errors under normal circumstances because they are > crap". And from *that*, the obvious solution would seem to not be to > penalize everybody else, but to just say that "We will try to recover from > MMF errors gracefully by retrying the transaction". Hmm? Well, see above about why retrying wouldn't work well. Data lost, and not recoverable ... although if the events are only USB keyboards/mice, then the user might be able to recover. (Stuart?) Alternatively, if Broadcom then just veto cpufreq changes whenever there are USB interrupt transfers active. (We *can* veto changes in notifiers, yes?) - Dave > > Linus > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][bugzilla #8679] therm_throt.c: Fix section mismatch
WARNING: arch/i386/kernel/built-in.o(.data+0x2148): Section mismatch: reference
to .init.text: (between 'thermal_throttle_cpu_notifier' and 'mtrr_mutex')
comes because struct notifier_block thermal_throttle_cpu_notifier in
arch/i386/kernel/cpu/mcheck/therm_throt.c goes in .data section but
the notifier callback function itself has been marked __cpuinit which
becomes __init == .init.text when HOTPLUG_CPU=n. The warning is bogus
because the callback will never be called out if HOTPLUG_CPU=n in the
first place (as one can see from kernel/cpu.c, the cpu_chain itself
is __cpuinitdata :-)
So, let's mark thermal_throttle_cpu_notifier as __cpuinitdata to fix
the section mismatch warning.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
[The other section mismatch mentioned in bugzilla #8679 is already fixed.]
arch/i386/kernel/cpu/mcheck/therm_throt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/i386/kernel/cpu/mcheck/therm_throt.c
b/arch/i386/kernel/cpu/mcheck/therm_throt.c
index 1203dc5..494d320 100644
--- a/arch/i386/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/i386/kernel/cpu/mcheck/therm_throt.c
@@ -152,7 +152,7 @@ static __cpuinit int thermal_throttle_cpu_callback(struct
notifier_block *nfb,
return NOTIFY_OK;
}
-static struct notifier_block thermal_throttle_cpu_notifier =
+static struct notifier_block thermal_throttle_cpu_notifier __cpuinitdata =
{
.notifier_call = thermal_throttle_cpu_callback,
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCPportsfrom the host TCP port space.
> -Original Message- > From: Patrick Geoffray [mailto:[EMAIL PROTECTED] > Sent: Monday, August 20, 2007 1:34 PM > To: Felix Marti > Cc: Evgeniy Polyakov; David Miller; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED] > Subject: Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate > PS_TCPportsfrom the host TCP port space. > > Felix Marti wrote: > > Yes, the app will take the cache hits when accessing the data. > However, > > the fact remains that if there is a copy in the receive path, you > > require and additional 3x memory BW (which is very significant at > these > > high rates and most likely the bottleneck for most current > systems)... > > and somebody always has to take the cache miss be it the copy_to_user > or > > the app. > > The cache miss is going to cost you half the memory bandwidth of a full > copy. If the data is already in cache, then the copy is cheaper. > > However, removing the copy removes the kernel from the picture on the > receive side, so you lose demultiplexing, asynchronism, security, > accounting, flow-control, swapping, etc. If it's ok with you to not use > the kernel stack, then why expect to fit in the existing infrastructure > anyway ? Many of the things you're referring to are moved to the offload adapter but from an ease of use point of view, it would be great if the user could still collect stats the same way, i.e. netstat reports the 4-tuple in use and other network stats. In addition, security features and packet scheduling could be integrated so that the user configures them the same way as the network stack. > > > Yes, RDMA support is there... but we could make it better and easier > to > > What do you need from the kernel for RDMA support beyond HW drivers ? A > fast way to pin and translate user memory (ie registration). That is > pretty much the sandbox that David referred to. > > Eventually, it would be useful to be able to track the VM space to > implement a registration cache instead of using ugly hacks in user- > space > to hijack malloc, but this is completely independent from the net > stack. > > > use. We have a problem today with port sharing and there was a > proposal > > The port spaces are either totally separate and there is no issue, or > completely identical and you should then run your connection manager in > user-space or fix your middlewares. When running on an iWarp device (and hence on top of TCP) I believe that the port space should shared and i.e. netstat reports the 4-tuple in use. > > > and not for technical reasons. I believe this email threads shows in > > detail how RDMA (a network technology) is treated as bastard child by > > the network folks, well at least by one of them. > > I don't think it's fair. This thread actually show how pushy some RDMA > folks are about not acknowledging that the current infrastructure is > here for a reason, and about mistaking zero-copy and RDMA. Zero-copy and RDMA are not the same but in the context of this discussion I referred to RDMA as a superset (zero-copy is implied). > > This is a similar argument than the TOE discussion, and it was > definitively a good decision to not mess up the Linux stack with TOEs. > > Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/11] Kprobes - declare kprobe_mutex static
On Mon, Aug 20, 2007 at 04:19:06PM -0400, Mathieu Desnoyers wrote: > Since it will not be used by other kernel objects, it makes sense to declare > it > static. > > Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> Acked-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > --- > kernel/kprobes.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-2.6-lttng/kernel/kprobes.c > === > --- linux-2.6-lttng.orig/kernel/kprobes.c 2007-08-19 09:09:15.0 > -0400 > +++ linux-2.6-lttng/kernel/kprobes.c 2007-08-19 17:18:07.0 -0400 > @@ -68,7 +68,7 @@ static struct hlist_head kretprobe_inst_ > /* NOTE: change this value only with kprobe_mutex held */ > static bool kprobe_enabled; > > -DEFINE_MUTEX(kprobe_mutex); /* Protects kprobe_table */ > +static DEFINE_MUTEX(kprobe_mutex); /* Protects kprobe_table */ > DEFINE_SPINLOCK(kretprobe_lock); /* Protects kretprobe_inst_table */ > static DEFINE_PER_CPU(struct kprobe *, kprobe_instance) = NULL; > > > -- > Mathieu Desnoyers > Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 20 Aug 2007, David Brownell wrote: > > MMF basically means the "Transaction Translating" (TT) hub had data > for the host, but the host didn't collect it in time ... so that some > data was lost. > > Unfortunately, that's the type of fault that's especially hard to > recover from. Fair enough. However, it still seems particularly idiotic to - penalize everybody - mix up two totally unrelated areas (cpufreq and USB) for a bug that is extremely rare and could be handled differently. For example, if it really ends up being practically impossible to recover from split transaction errors, I would still suggest reverting that horrid commit, and then just black-listing the known-broken EHCI controllers and simply not *do* any split transactions on them. That way there's no complexity. As far as I know, split transactions aren't required anyway, they are just a performance optimization. Basically, we not only know that the commit has caused problems, it's fundamentally ugly, fragile, and not very maintainable, and the whole reason for doing it is pretty dubious. Why not just admit that certain hardware is broken (and the vendor isn't worth even bothering to be polite with, since they try to screw us every chance they get) and cannot reliably do split transactions? Problem solved, no real downside, and nobody will even *notice*. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 02/11] Kprobes - use a mutex to protect the instruction pages list.
On Mon, Aug 20, 2007 at 04:19:04PM -0400, Mathieu Desnoyers wrote:
> Protect the instruction pages list by a specific insn pages mutex, called in
> get_insn_slot() and free_insn_slot(). It makes sure that architectures that
> does
> not need to call arch_remove_kprobe() does not take an unneeded kprobes mutex.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Acked-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
Thanks Mathieu.
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> ---
> kernel/kprobes.c | 27 +--
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> Index: linux-2.6-lttng/kernel/kprobes.c
> ===
> --- linux-2.6-lttng.orig/kernel/kprobes.c 2007-07-14 15:47:19.0
> -0400
> +++ linux-2.6-lttng/kernel/kprobes.c 2007-07-14 15:48:51.0 -0400
> @@ -101,6 +101,10 @@ enum kprobe_slot_state {
> SLOT_USED = 2,
> };
>
> +/*
> + * Protects the kprobe_insn_pages list. Can nest into kprobe_mutex.
> + */
> +static DEFINE_MUTEX(kprobe_insn_mutex);
> static struct hlist_head kprobe_insn_pages;
> static int kprobe_garbage_slots;
> static int collect_garbage_slots(void);
> @@ -137,7 +141,9 @@ kprobe_opcode_t __kprobes *get_insn_slot
> {
> struct kprobe_insn_page *kip;
> struct hlist_node *pos;
> + kprobe_opcode_t *ret;
>
> + mutex_lock(&kprobe_insn_mutex);
> retry:
> hlist_for_each_entry(kip, pos, &kprobe_insn_pages, hlist) {
> if (kip->nused < INSNS_PER_PAGE) {
> @@ -146,7 +152,8 @@ kprobe_opcode_t __kprobes *get_insn_slot
> if (kip->slot_used[i] == SLOT_CLEAN) {
> kip->slot_used[i] = SLOT_USED;
> kip->nused++;
> - return kip->insns + (i * MAX_INSN_SIZE);
> + ret = kip->insns + (i * MAX_INSN_SIZE);
> + goto end;
> }
> }
> /* Surprise! No unused slots. Fix kip->nused. */
> @@ -160,8 +167,10 @@ kprobe_opcode_t __kprobes *get_insn_slot
> }
> /* All out of space. Need to allocate a new page. Use slot 0. */
> kip = kmalloc(sizeof(struct kprobe_insn_page), GFP_KERNEL);
> - if (!kip)
> - return NULL;
> + if (!kip) {
> + ret = NULL;
> + goto end;
> + }
>
> /*
>* Use module_alloc so this page is within +/- 2GB of where the
> @@ -171,7 +180,8 @@ kprobe_opcode_t __kprobes *get_insn_slot
> kip->insns = module_alloc(PAGE_SIZE);
> if (!kip->insns) {
> kfree(kip);
> - return NULL;
> + ret = NULL;
> + goto end;
> }
> INIT_HLIST_NODE(&kip->hlist);
> hlist_add_head(&kip->hlist, &kprobe_insn_pages);
> @@ -179,7 +189,10 @@ kprobe_opcode_t __kprobes *get_insn_slot
> kip->slot_used[0] = SLOT_USED;
> kip->nused = 1;
> kip->ngarbage = 0;
> - return kip->insns;
> + ret = kip->insns;
> +end:
> + mutex_unlock(&kprobe_insn_mutex);
> + return ret;
> }
>
> /* Return 1 if all garbages are collected, otherwise 0. */
> @@ -213,7 +226,7 @@ static int __kprobes collect_garbage_slo
> struct kprobe_insn_page *kip;
> struct hlist_node *pos, *next;
>
> - /* Ensure no-one is preepmted on the garbages */
> + /* Ensure no-one is preempted on the garbages */
> if (check_safety() != 0)
> return -EAGAIN;
>
> @@ -237,6 +250,7 @@ void __kprobes free_insn_slot(kprobe_opc
> struct kprobe_insn_page *kip;
> struct hlist_node *pos;
>
> + mutex_lock(&kprobe_insn_mutex);
> hlist_for_each_entry(kip, pos, &kprobe_insn_pages, hlist) {
> if (kip->insns <= slot &&
> slot < kip->insns + (INSNS_PER_PAGE * MAX_INSN_SIZE)) {
> @@ -253,6 +267,7 @@ void __kprobes free_insn_slot(kprobe_opc
>
> if (dirty && ++kprobe_garbage_slots > INSNS_PER_PAGE)
> collect_garbage_slots();
> + mutex_unlock(&kprobe_insn_mutex);
> }
> #endif
>
>
> --
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 03/11] Kprobes - do not use kprobes mutex in arch code
On Mon, Aug 20, 2007 at 04:19:05PM -0400, Mathieu Desnoyers wrote:
> Remove the kprobes mutex from kprobes.h, since it does not belong there. Also
> remove all use of this mutex in the architecture specific code, replacing it
> by
> a proper mutex lock/unlock in the architecture agnostic code.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Acked-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> ---
> arch/i386/kernel/kprobes.c|2 --
> arch/ia64/kernel/kprobes.c|2 --
> arch/powerpc/kernel/kprobes.c |2 --
> arch/s390/kernel/kprobes.c|2 --
> arch/x86_64/kernel/kprobes.c |2 --
> include/linux/kprobes.h |2 --
> kernel/kprobes.c |2 ++
> 7 files changed, 2 insertions(+), 12 deletions(-)
>
> Index: linux-2.6-lttng/include/linux/kprobes.h
> ===
> --- linux-2.6-lttng.orig/include/linux/kprobes.h 2007-08-07
> 15:28:05.0 -0400
> +++ linux-2.6-lttng/include/linux/kprobes.h 2007-08-07 15:28:22.0
> -0400
> @@ -35,7 +35,6 @@
> #include
> #include
> #include
> -#include
>
> #ifdef CONFIG_KPROBES
> #include
> @@ -177,7 +176,6 @@ static inline void kretprobe_assert(stru
> }
>
> extern spinlock_t kretprobe_lock;
> -extern struct mutex kprobe_mutex;
> extern int arch_prepare_kprobe(struct kprobe *p);
> extern void arch_arm_kprobe(struct kprobe *p);
> extern void arch_disarm_kprobe(struct kprobe *p);
> Index: linux-2.6-lttng/arch/i386/kernel/kprobes.c
> ===
> --- linux-2.6-lttng.orig/arch/i386/kernel/kprobes.c 2007-08-07
> 15:28:05.0 -0400
> +++ linux-2.6-lttng/arch/i386/kernel/kprobes.c2007-08-07
> 15:28:22.0 -0400
> @@ -180,9 +180,7 @@ void __kprobes arch_disarm_kprobe(struct
>
> void __kprobes arch_remove_kprobe(struct kprobe *p)
> {
> - mutex_lock(&kprobe_mutex);
> free_insn_slot(p->ainsn.insn, (p->ainsn.boostable == 1));
> - mutex_unlock(&kprobe_mutex);
> }
>
> static void __kprobes save_previous_kprobe(struct kprobe_ctlblk *kcb)
> Index: linux-2.6-lttng/kernel/kprobes.c
> ===
> --- linux-2.6-lttng.orig/kernel/kprobes.c 2007-08-07 15:28:22.0
> -0400
> +++ linux-2.6-lttng/kernel/kprobes.c 2007-08-07 15:28:22.0 -0400
> @@ -656,7 +656,9 @@ valid_p:
> list_del_rcu(&p->list);
> kfree(old_p);
> }
> + mutex_lock(&kprobe_mutex);
> arch_remove_kprobe(p);
> + mutex_unlock(&kprobe_mutex);
> } else {
> mutex_lock(&kprobe_mutex);
> if (p->break_handler)
> Index: linux-2.6-lttng/arch/ia64/kernel/kprobes.c
> ===
> --- linux-2.6-lttng.orig/arch/ia64/kernel/kprobes.c 2007-08-07
> 15:28:05.0 -0400
> +++ linux-2.6-lttng/arch/ia64/kernel/kprobes.c2007-08-07
> 15:28:22.0 -0400
> @@ -565,9 +565,7 @@ void __kprobes arch_disarm_kprobe(struct
>
> void __kprobes arch_remove_kprobe(struct kprobe *p)
> {
> - mutex_lock(&kprobe_mutex);
> free_insn_slot(p->ainsn.insn, 0);
> - mutex_unlock(&kprobe_mutex);
> }
> /*
> * We are resuming execution after a single step fault, so the pt_regs
> Index: linux-2.6-lttng/arch/powerpc/kernel/kprobes.c
> ===
> --- linux-2.6-lttng.orig/arch/powerpc/kernel/kprobes.c2007-08-07
> 15:28:05.0 -0400
> +++ linux-2.6-lttng/arch/powerpc/kernel/kprobes.c 2007-08-07
> 15:28:22.0 -0400
> @@ -86,9 +86,7 @@ void __kprobes arch_disarm_kprobe(struct
>
> void __kprobes arch_remove_kprobe(struct kprobe *p)
> {
> - mutex_lock(&kprobe_mutex);
> free_insn_slot(p->ainsn.insn, 0);
> - mutex_unlock(&kprobe_mutex);
> }
>
> static void __kprobes prepare_singlestep(struct kprobe *p, struct pt_regs
> *regs)
> Index: linux-2.6-lttng/arch/s390/kernel/kprobes.c
> ===
> --- linux-2.6-lttng.orig/arch/s390/kernel/kprobes.c 2007-08-07
> 15:28:05.0 -0400
> +++ linux-2.6-lttng/arch/s390/kernel/kprobes.c2007-08-07
> 15:28:22.0 -0400
> @@ -218,9 +218,7 @@ void __kprobes arch_disarm_kprobe(struct
>
> void __kprobes arch_remove_kprobe(struct kprobe *p)
> {
> - mutex_lock(&kprobe_mutex);
> free_insn_slot(p->ainsn.insn, 0);
> - mutex_unlock(&kprobe_mutex);
> }
>
> static void __kprobes prepare_singlestep(struct kprobe *p, struct pt_regs
> *regs)
> Index: linux-2.6-lttng/arch/x86_64/kernel/kprobes.c
> ===
> --- linux-2.6-lttng.orig/arch/x86_64/kernel/kprobes.c
Re: resume from ram much slower
> Starting 1-2 weeks ago I have very long resume from > ram times. It takes more than 1 min to resume. Do you see any difference with "pnpacpi=off"? thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: posix timer: slab error 'double free'
Hi everyone:
A posix timer race condition is found in current kernel source tree.
Jeremy has actually
reported the same problem.
I write a simple stress test program for posix timer subsystem, to
reproduce the problem in the lastest mainline kernel.
My test program creates 200 threads, and each thread does the following job:
while (1) {
timer_create()
timer_settime()
sleep a while
timer_delete()
}
Please see my test program in the attachemnt "posix_timer_test.c". You
can compile my test program via the following command line:
gcc -static -o posix_timer_test.c posix_timer_test.c -lrt -lpthread
For my testing environment, you can refer to the three attachment files:
"dmesg.txt", "cpuinfo.txt", "config.txt"
In the pristine Linux-2.6.23-rc3, we get the following oops message:
slab error in cache_alloc_debugcheck_after(): cache `sigqueue': double
free, or memory outside object was overwritten
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __slab_error+0x26/0x28
[] cache_alloc_debugcheck_after+0x134/0x204
[] kmem_cache_alloc+0x5a/0xac
[] __sigqueue_alloc+0x25/0x62
[] sigqueue_alloc+0x15/0x1f
[] sys_timer_create+0x3d/0x2d8
[] syscall_call+0x7/0xb
===
dcdcd000: redzone 1:0xd84156c5635688c0, redzone 2:0xd84156c5635688c0
slab error in verify_redzone_free(): cache `sigqueue': double free detected
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __slab_error+0x26/0x28
[] cache_free_debugcheck+0x1d9/0x298
[] kmem_cache_free+0x66/0xb5
[] __sigqueue_free+0x2f/0x32
[] __dequeue_signal+0xdc/0x174
[] dequeue_signal+0xbb/0x149
[] sys_rt_sigtimedwait+0x7f/0x240
[] syscall_call+0x7/0xb
===
dd7f7000: redzone 1:0x9f911029d74e35b, redzone 2:0x9f911029d74e35b.
BUG: unable to handle kernel paging request at virtual address dd7f7f6c
printing eip:
c012abdb
*pde = 00075067
*pte = 1d7f7000
Oops: 0002 [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010086 (2.6.23-rc3-g2a677896 #1)
EIP is at posix_timer_event+0x14/0xa0
eax: ebx: dcc1e900 ecx: 0020 edx: 0003
esi: dcc1e938 edi: dd7f7f6c ebp: dff5fe50 esp: dff5fe48
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process swapper (pid: 0, ti=dff5e000 task=dff4eac0 task.ti=dff5e000)
Stack: c012b1a7 dcc1e900 dff5fe7c c012b1e0 0001 c140ef50 dcc1e938
0002
0217 dcc1e908 c012b1a7 dcc1e938 c140ef50 dff5febc c012e3a5
dcc1e95c e32a8edd ef84ee03 2e028890 00f1 c140ef20
0001
Call Trace:
[] show_trace_log_lvl+0x1a/0x30
[] show_stack_log_lvl+0xa5/0xca
[] show_registers+0x21b/0x391
[] die+0x121/0x25e
[] do_page_fault+0x354/0x627
[] error_code+0x72/0x78
[] posix_timer_fn+0x39/0x94
[] hrtimer_run_queues+0x150/0x181
[] run_timer_softirq+0x1d/0x1a9
[] __do_softirq+0x71/0xe0
[] do_softirq+0x3f/0x41
[] irq_exit+0x48/0x4a
[] smp_apic_timer_interrupt+0x5d/0x89
[] apic_timer_interrupt+0x28/0x30
[] cpu_idle+0x67/0x90
[] start_secondary+0x157/0x15e
[<>] _stext+0x3fefff50/0x19
===
Code: 89 44 24 04 c7 04 24 bc 53 33 c0 e8 85 05 ff ff 83 c4 08 5e 5f 5d
c3 55 89 e5 57 53 89 c3 31 c0 b9 20 00 00 00 8b 7b 34 83 c7 0c ab
8b 43 34 89 50 24 8b 53 34 8b 43 28 89 42 0c 8b 43 34 c7
EIP: [] posix_timer_event+0x14/0xa0 SS:ESP 0068:dff5fe48
Kernel panic - not syncing: Fatal exception in interrupt
And I also apply the four patches from Oleg Nesterov from lkml:
http://lkm.org/lkml/2007/8/12/193
http://lkm.org/lkml/2007/8/12/194
http://lkm.org/lkml/2007/8/12/195
http://lkm.org/lkml/2007/8/12/196
After about ten hours, the kernel still panic. Here is its oops message:
slab error in verify_redzone_free(): cache `sigqueue': double free detected
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __slab_error+0x26/0x28
[] cache_free_debugcheck+0x1d9/0x298
[] kmem_cache_free+0x66/0xb5
[] __sigqueue_free+0x2f/0x32
[] __dequeue_signal+0xdc/0x174
[] dequeue_signal+0x25/0x156
[] sys_rt_sigtimedwait+0x7f/0x240
[] syscall_call+0x7/0xb
===
df839000: redzone 1:0x9f911029d74e35b, redzone 2:0x9f911029d74e35b.
BUG: unable to handle kernel paging request at virtual address df839f68
printing eip:
c0124af3
*pde = 0007e067
*pte = 1f839000
Oops: [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.23-rc3-g2a677896-dirty #2)
EIP is at sigqueue_free+0x7/0x6f
eax: df839f60 ebx: df839f60 ecx: df3b edx:
esi: dd3c7120 edi: 0213 ebp: df3b1e24 esp: df3b1e1c
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process posix_timer_tes (pid: 1110, ti=df3b task=dd77dac0
task.ti=df3b)
Stack: 0213 dd3c7120 df3b1e34 c012a8c2 dd3c7120 dd3c7128 df3b1e50
c012a9ce
df755e48 df755e88 dd77df9c dd77dac0 df3b1e9c c011dab0
dd77df5c df3b1e8c c012
Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Monday 20 August 2007, Linus Torvalds wrote: > > On Mon, 20 Aug 2007, David Brownell wrote: > > > On Monday 13 August 2007, Michal Piotrowski wrote: > > > Subject     : EHCI Regression in 2.6.23-rc2 > > > References    : http://lkml.org/lkml/2007/8/10/81 > > > Last known good : ? > > > Submitter    : Daniel Exner <[EMAIL PROTECTED]> > > > Caused-By    : [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > >          commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 > > > Handled-By    : ? > > > Status      : unknown > > > > Fixed I believe by Stuart's patch: > > > > http://marc.info/?l=linux-usb-devel&m=118765934722610&w=2 > > Quite frankly, I'd personally prefer to just revert commit > 196705c9bbc03540429b0f7cf9ee35c2f928a534 entirely instead. > > The whole dependency on cpufreq seems totally bogus. Would it not be a lot > more natural to handle the *result* of the problem (ie the MMF errors by > broken EHCI controllers?) rather than add totally insane workarounds for > this case to try to hide them in the first place? MMF basically means the "Transaction Translating" (TT) hub had data for the host, but the host didn't collect it in time ... so that some data was lost. Unfortunately, that's the type of fault that's especially hard to recover from. Plus, very few of the upper layer drivers have even a minor clue about fault recovery strategies. And I don't trust the current hcd/usbcore code that tries to clean up after MMF. On the plus side, MMF errors have been vanishingly rare until this cpufreq interaction came up ... which of course implies the downside that those "handle the result" code paths are all but untested. > There can be *other* delays in reading memory that have nothing to do with > cpu frequency shifting, and everything to do with exteme situations on the > bus. If the stupid EHCI controller has some tight latency issues, that's a > generic problem. There could be such problems, yes. But in practice, I don't know that we've ever seen them. (There's a first time for everthing, yes. I *just* fetched a webpage where an image got overwritten about > That commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 just exemplifies what > is wrong with USB, but it does so by adding incredibly ugly code. I'd > rather not add even *more* ugly code - especially not for a case where we > then seem to blame the wrong party (ie a VIA controller that didn't need > the ugly code in the first place). > > Serverworks/Broadcom makes totally crap chips (not just in USB) and then > doesn't even document their buggy crap hardware. But that is NOT a reason > for then making the kernel have buggy crap software in it. > > So really - is there any reason why we just don't say "Broadcom chips > suck, and get MMF errors under normal circumstances because they are > crap". And from *that*, the obvious solution would seem to not be to > penalize everybody else, but to just say that "We will try to recover from > MMF errors gracefully by retrying the transaction". Hmm? > > Linus > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] x86_64 EFI runtime service support
Huang, Ying wrote: > > I think the "next" field can be u32 instead of u64. Because the linked > list of struct setup_data is prepared by bootloader, which can control > the memory location. > That's making some pretty serious assumptions on future boot loaders and environments. > Previously, I think the "zero page" is not external formally, so we can > ignore the user. But it is used by some bootloaders. So your proposal > may be better, especially for these bootloaders. > > I think something others need to be done: > > - Increase the version number of standard boot protocol. > - Add the contents of zero page into standard boot protocol document as > a optional part for 32-bit entry (and 64-bit entry?). Probably, yes. > As for the magic number in zero page, do you think it should be used > only by 16-bit kernel setup code? Absolutely not. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Send exit code through for taskstats.ac_exitcode
Jonathan Lim wrote: > taskstats.ac_exitcode is assigned to task_struct.exit_code in bacct_add_tsk() > through the following kernel function calls: > > do_exit() > taskstats_exit_send() > fill_pid() > bacct_add_tsk() > > The problem is that in do_exit(), task_struct.exit_code is set to 'code' > only after taskstats_exit_send() has been called. So we need to send 'code' > through to bacct_add_tsk(). > Hi, Jonathan, The patches look like a step in the right direction, I would suggest an alternate implementation Why can't we assign tsk->exit_code to code earlier? Can we not move up the assignment to before taskstats_exit()? Wouldn't that be much simpler? -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How Linux /proc filesystem convert a fd to the actual pathname?
Hi, In the Linux proc filesystem, /proc/[pid]/fd is a link to the actually the actual pathname of the opened file. I am curious how Linux convert an fd to the pathname? Does it recursively walk back from current dentry to the root? Can someone point me to the right place in the kernel where this functionality is implemented? Many thanks in advance! -x - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scripts/get_maintainer.pl
Find maintainer info for a patch or a file
Changes since last submission: (in for a penny...)
Might as well do them all.
Added --status - Print the status information
Added --subsystem - Print the subsystem title
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
new file mode 100755
index 000..d503467
--- /dev/null
+++ b/scripts/get_maintainer.pl
@@ -0,0 +1,468 @@
+#!/usr/bin/perl -w
+# (c) 2007, Joe Perches <[EMAIL PROTECTED]>
+# created from checkpatch.pl
+#
+# Print selected MAINTAINERS information for
+# the files modified in a patch or for a file
+#
+# usage: perl scripts/get_maintainers.pl [OPTIONS]
+#perl scripts/get_maintainers.pl [OPTIONS] -f
+#
+# Licensed under the terms of the GNU GPL License version 2
+
+use strict;
+
+my $P = $0;
+my $V = '0.12';
+
+use Getopt::Long qw(:config no_auto_abbrev);
+
+my $lk_path = "./";
+my $email = 1;
+my $email_usename = 1;
+my $email_maintainer = 1;
+my $email_list = 1;
+my $email_subscriber_list = 0;
+my $email_git = 1;
+my $email_git_penguin_chiefs = 0;
+my $output_multiline = 1;
+my $output_separator = ", ";
+my $scm = 0;
+my $web = 0;
+my $subsystem = 0;
+my $status = 0;
+my $onefile = 0;
+
+my $exit = 0;
+
+my @penguin_chief = ();
+push(@penguin_chief,"Linus Torvalds:[EMAIL PROTECTED]");
+push(@penguin_chief,"Andrew Morton:[EMAIL PROTECTED]");
+
+my @penguin_chief_names = ();
+foreach my $chief (@penguin_chief) {
+if ($chief =~ m/^(.*):(.*)/) {
+ my $chief_name = $1;
+ my $chief_addr = $2;
+ push(@penguin_chief_names, $chief_name);
+}
+}
+my $penguin_chiefs = "\(" . join("|",@penguin_chief_names) . "\)";
+
+if (!GetOptions(
+ 'email!' => \$email,
+ 'git!' => \$email_git,
+ 'git-chief-penguins!' => \$email_git_penguin_chiefs,
+ 'm!' => \$email_maintainer,
+ 'n!' => \$email_usename,
+ 'l!' => \$email_list,
+ 's!' => \$email_subscriber_list,
+ 'multiline!' => \$output_multiline,
+ 'separator=s' => \$output_separator,
+ 'subsystem!' => \$subsystem,
+ 'status!' => \$status,
+ 'scm!' => \$scm,
+ 'web!' => \$web,
+ 'f' => \$onefile,
+ )) {
+usage();
+die "$P: invalid argument\n";
+}
+
+my $infile = $ARGV[0];
+
+if ($#ARGV < 0) {
+usage();
+die "$P: argument missing: patchfile or -f file please\n";
+}
+
+my $selections = $email + $scm + $status + $subsystem + $web;
+if ($selections == 0 || $selections > 1) {
+usage();
+die "$P: Please select one of email, scm, status, subsystem or web\n";
+}
+
+if ($email && ($email_maintainer + $email_list + $email_subscriber_list
+ + $email_git + $email_git_penguin_chiefs) == 0) {
+usage();
+die "$P: Please select at least 1 email option\n";
+}
+
+if (!top_of_kernel_tree($lk_path)) {
+die "$P: The current directory does not appear to be "
+ . "a linux kernel source tree.\n";
+}
+
+## Read MAINTAINERS for type/value pairs
+
+my @typevalue = ();
+open(MAINT, "<${lk_path}MAINTAINERS") || die "$P: Can't open MAINTAINERS\n";
+while () {
+my $line = $_;
+
+if ($line =~ m/^(\C):\s*(.*)/) {
+ my $type = $1;
+ my $value = $2;
+
+ ##Filename pattern matching
+ if ($type eq "F" || $type eq "X") {
+ $value =~ [EMAIL PROTECTED]@[EMAIL PROTECTED]; ##Convert . to
\.
+ $value =~ s/\*/\.\*/g; ##Convert * to .*
+ }
+ push(@typevalue, "$type:$value");
+} elsif (!/^(\s)*$/) {
+ $line =~ s/\n$//g;
+ push(@typevalue, $line);
+}
+}
+close(MAINT);
+
+## use the filename on the command line or find the filenames in the patchfile
+
+my @files = ();
+
+if ($onefile) {
+if (!(-f $infile)) {
+ die "$P: file '${infile}' not found\n";
+}
+push(@files, $infile);
+} else {
+open(PATCH, "<$infile") or die "$P: Can't open ${infile}\n";
+while () {
+ if (m/^\+\+\+\s+(\S+)/) {
+ my $file = $1;
+ $file =~ [EMAIL PROTECTED]/]*/@@;
+ $file =~ [EMAIL PROTECTED]@@;
+ push(@files, $file);
+ }
+}
+close(PATCH);
+my $file_cnt = @files;
+if ($file_cnt == 0) {
+ die "$P: file '${infile}' doesn't appear to be a patch. "
+ . "Add -f to options?\n";
+}
+@files = sort_and_uniq(@files);
+}
+
+my @email_to = ();
+my @scm = ();
+my @web = ();
+my @subsystem = ();
+my @status = ();
+
+# Find responsible parties
+
+foreach my $file (@files) {
+my $exclude = 0;
+
+#Git
+
+if ($email_git_penguin_chiefs) {
+ foreach my $chief (@penguin_chief) {
+ if ($chief =~ m/^(.*):(.*)/) {
+ my $chief_name = $1;
+ my $chief_addr = $2;
+ if ($email_usename) {
+ push(@email_to, format_email($chief_name, $chief_addr));
+
Re: gitstat 0.1: kernel development statistics / monitoring system
jungseung lee wrote: > We are pleased to announce the release of gitstat 0.1. > > Gitstat is a GPL'd, web-based git statistics/monitoring system. I have added information about gitstat to git wiki: http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#gitstat Please check if the information provided there is correct. You can shorten it. -- Jakub Narebski Warsaw, Poland ShadeHawk on #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/
[PATCH] Send exit code through for taskstats.ac_exitcode
taskstats.ac_exitcode is assigned to task_struct.exit_code in bacct_add_tsk()
through the following kernel function calls:
do_exit()
taskstats_exit_send()
fill_pid()
bacct_add_tsk()
The problem is that in do_exit(), task_struct.exit_code is set to 'code'
only after taskstats_exit_send() has been called. So we need to send 'code'
through to bacct_add_tsk().
Diff'd against: linux/kernel/git/stable/linux-2.6.22.y.git
Signed-off-by: Jonathan Lim <[EMAIL PROTECTED]>
--- a/kernel/exit.c 2007-08-20 16:37:55.0 -0700
+++ b/kernel/exit.c 2007-08-20 16:37:55.0 -0700
@@ -941,7 +941,7 @@ fastcall NORET_TYPE void do_exit(long co
if (unlikely(tsk->audit_context))
audit_free(tsk);
- taskstats_exit(tsk, group_dead);
+ taskstats_exit(code, tsk, group_dead);
exit_mm(tsk);
--- a/kernel/taskstats.c2007-08-20 16:37:55.0 -0700
+++ b/kernel/taskstats.c2007-08-20 16:37:55.0 -0700
@@ -168,7 +168,7 @@ static void send_cpu_listeners(struct sk
up_write(&listeners->sem);
}
-static int fill_pid(pid_t pid, struct task_struct *tsk,
+static int fill_pid(long exitcode, pid_t pid, struct task_struct *tsk,
struct taskstats *stats)
{
int rc = 0;
@@ -196,7 +196,7 @@ static int fill_pid(pid_t pid, struct ta
/* fill in basic acct fields */
stats->version = TASKSTATS_VERSION;
- bacct_add_tsk(stats, tsk);
+ bacct_add_tsk(exitcode, stats, tsk);
/* fill in extended acct fields */
xacct_add_tsk(stats, tsk);
@@ -452,7 +452,7 @@ ret:
}
/* Send pid data out on exit */
-void taskstats_exit(struct task_struct *tsk, int group_dead)
+void taskstats_exit(long exitcode, struct task_struct *tsk, int group_dead)
{
int rc;
struct listener_list *listeners;
@@ -490,7 +490,7 @@ void taskstats_exit(struct task_struct *
if (!stats)
goto err;
- rc = fill_pid(tsk->pid, tsk, stats);
+ rc = fill_pid(exitcode, tsk->pid, tsk, stats);
if (rc < 0)
goto err;
--- a/kernel/tsacct.c 2007-08-20 16:37:55.0 -0700
+++ b/kernel/tsacct.c 2007-08-20 16:37:55.0 -0700
@@ -25,7 +25,7 @@
/*
* fill in basic accounting fields
*/
-void bacct_add_tsk(struct taskstats *stats, struct task_struct *tsk)
+void bacct_add_tsk(long exitcode, struct taskstats *stats, struct task_struct
*tsk)
{
struct timespec uptime, ts;
s64 ac_etime;
@@ -41,7 +41,7 @@ void bacct_add_tsk(struct taskstats *sta
stats->ac_etime = ac_etime;
stats->ac_btime = xtime.tv_sec - ts.tv_sec;
if (thread_group_leader(tsk)) {
- stats->ac_exitcode = tsk->exit_code;
+ stats->ac_exitcode = exitcode;
if (tsk->flags & PF_FORKNOEXEC)
stats->ac_flag |= AFORK;
}
--- a/include/linux/taskstats_kern.h2007-08-20 18:13:11.0 -0700
+++ b/include/linux/taskstats_kern.h2007-08-20 18:16:12.0 -0700
@@ -26,10 +26,10 @@ static inline void taskstats_tgid_free(s
kmem_cache_free(taskstats_cache, sig->stats);
}
-extern void taskstats_exit(struct task_struct *, int group_dead);
+extern void taskstats_exit(long exitcode, struct task_struct *, int
group_dead);
extern void taskstats_init_early(void);
#else
-static inline void taskstats_exit(struct task_struct *tsk, int group_dead)
+static inline void taskstats_exit(long exitcode, struct task_struct *tsk, int
group_dead)
{}
static inline void taskstats_tgid_init(struct signal_struct *sig)
{}
--- a/include/linux/tsacct_kern.h 2007-08-20 18:13:11.0 -0700
+++ b/include/linux/tsacct_kern.h 2007-08-20 18:17:55.0 -0700
@@ -10,9 +10,9 @@
#include
#ifdef CONFIG_TASKSTATS
-extern void bacct_add_tsk(struct taskstats *stats, struct task_struct *tsk);
+extern void bacct_add_tsk(long exitcode, struct taskstats *stats, struct
task_struct *tsk);
#else
-static inline void bacct_add_tsk(struct taskstats *stats, struct task_struct
*tsk)
+static inline void bacct_add_tsk(long exitcode, struct taskstats *stats,
struct task_struct *tsk)
{}
#endif /* CONFIG_TASKSTATS */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Mon, 20 Aug 2007, David Brownell wrote: > On Monday 13 August 2007, Michal Piotrowski wrote: > > Subject     : EHCI Regression in 2.6.23-rc2 > > References    : http://lkml.org/lkml/2007/8/10/81 > > Last known good : ? > > Submitter    : Daniel Exner <[EMAIL PROTECTED]> > > Caused-By    : [EMAIL PROTECTED] <[EMAIL PROTECTED]> > >          commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 > > Handled-By    : ? > > Status      : unknown > > Fixed I believe by Stuart's patch: > > http://marc.info/?l=linux-usb-devel&m=118765934722610&w=2 Quite frankly, I'd personally prefer to just revert commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 entirely instead. The whole dependency on cpufreq seems totally bogus. Would it not be a lot more natural to handle the *result* of the problem (ie the MMF errors by broken EHCI controllers?) rather than add totally insane workarounds for this case to try to hide them in the first place? There can be *other* delays in reading memory that have nothing to do with cpu frequency shifting, and everything to do with exteme situations on the bus. If the stupid EHCI controller has some tight latency issues, that's a generic problem. That commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 just exemplifies what is wrong with USB, but it does so by adding incredibly ugly code. I'd rather not add even *more* ugly code - especially not for a case where we then seem to blame the wrong party (ie a VIA controller that didn't need the ugly code in the first place). Serverworks/Broadcom makes totally crap chips (not just in USB) and then doesn't even document their buggy crap hardware. But that is NOT a reason for then making the kernel have buggy crap software in it. So really - is there any reason why we just don't say "Broadcom chips suck, and get MMF errors under normal circumstances because they are crap". And from *that*, the obvious solution would seem to not be to penalize everybody else, but to just say that "We will try to recover from MMF errors gracefully by retrying the transaction". Hmm? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS hang + umount -f: better behaviour requested.
Robin Lee Powell digitalkingdom.org> writes: > > Though I agree that it would be nice if we could convince all > > subsequent requests to a server to fail EIO instead of just the > > currently active ones. I'm not sure that just changing "umount > > -f" is the right interface though Maybe if all the server > > handles appeared in sysfs and have an attribute which you could > > set to cause all requests to fail... > > I have no opinion on interface details, I simply know that on > Solaris, "umount -f" Just Works, and I would love to have similar > behaviour on Linux. > > -Robin > What you are looing is revoke()/frevokeat(); which will yank the file right from under the descriptor. Its currently in -mm. Of course "mount" will still need to iterate over each open file on the mount and revoke 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/
Re: [PATCH 0/3] x86_64 EFI runtime service support
On Mon, 2007-08-20 at 10:12 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >>
> >> I propose that, in addition to the aforementioned version number and
> >> magic fields, we add a pointer, which should be the last pointer added
> >> that doesn't point into I/O space or reserved memory (i.e. memory that
> >> is off limit anyway for the operating system.)
> >>
> >> This pointer should point to a linked list of suggested form:
> >>
> >> struct setup_data {
> >>u64 next;
> >>u32 type;
> >>u32 len;
> >>u8 data[];
> >> };
> >>
I think the "next" field can be u32 instead of u64. Because the linked
list of struct setup_data is prepared by bootloader, which can control
the memory location.
To facilitate the kernel early mapping, I think the memory location of
"linked list" should be kept to a predefined range (in the real mode
memory area?).
> > So, we need not define a new boot protocol, just extend the standard
> > boot protocol. The version number and magic need not to be added to
> > "zero page". But, at the same time, the bootloader on EFI, LinuxBIOS and
> > kexec must be changed accordingly.
> >
>
> I think this is too radical of a change to be practical. Instead, I
> propose the following:
>
> - "struct boot_params" (the zeropage) is kept as a legacy interface.
> %esi will continue to point to it on entry to the 32-bit entrypoint
> (presumably that is %rsi on entry to a 64-bit entrypoint?)
>
> - We add a magic number and a pointer chain to the zeropage. The
> presence of the magic number indicates that:
>
> - Any unused fields in the zeropage is zero;
> - The pointer chain is valid (unless zero);
> - The old "HD info" fields (and possibly the EDD fields)
> can be recycled.
Previously, I think the "zero page" is not external formally, so we can
ignore the user. But it is used by some bootloaders. So your proposal
may be better, especially for these bootloaders.
I think something others need to be done:
- Increase the version number of standard boot protocol.
- Add the contents of zero page into standard boot protocol document as
a optional part for 32-bit entry (and 64-bit entry?).
- Make 32-bit (64-bit?) boot protocol formal in standard boot protocol
document.
> What a post-upgrade kernel should do upon encountering an old structure
> (sans magic) is to zero out any fields that wasn't present in the legacy
> structure definition, including the pointer chain, then it can use it as-is.
As for the magic number in zero page, do you think it should be used
only by 16-bit kernel setup code?
> We should avoid adding fields to the zero_page after that, unless
> necessary for backwards compatibility reasons. In general, new data
> items should be added as pointer capabilities.
Yes.
> Compare this to the legacy PCI header vs. PCI capabilities.
Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-usb-devel] [4/4] 2.6.23-rc3: known regressions
On Monday 13 August 2007, Michal Piotrowski wrote: > Subject     : EHCI Regression in 2.6.23-rc2 > References    : http://lkml.org/lkml/2007/8/10/81 > Last known good : ? > Submitter    : Daniel Exner <[EMAIL PROTECTED]> > Caused-By    : [EMAIL PROTECTED] <[EMAIL PROTECTED]> >          commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 > Handled-By    : ? > Status      : unknown Fixed I believe by Stuart's patch: http://marc.info/?l=linux-usb-devel&m=118765934722610&w=2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 002 of 6] Introduce rq_for_each_segment replacing rq_for_each_bio
Hi Geert,
On Mon, 20 Aug 2007, Geert Uytterhoeven wrote:
> On Sat, 18 Aug 2007, Satyam Sharma wrote:
> > On Sat, 18 Aug 2007, Jan Engelhardt wrote:
> > > On Aug 18 2007 20:07, Satyam Sharma wrote:
> > > >On Fri, 17 Aug 2007, Geert Uytterhoeven wrote:
> > > >> On Thu, 16 Aug 2007, NeilBrown wrote:
> > > >> [...]
> > > >> > dev_dbg(&dev->sbd.core,
> > > >> > "%s:%u: bio %u: %u segs %u sectors from %lu\n",
^^^
> > > >> > -__func__, __LINE__, i, bio_segments(bio),
> > > >> > -bio_sectors(bio), sector);
> > > >> > -bio_for_each_segment(bvec, bio, j) {
> > > >> > +__func__, __LINE__, i, bio_segments(iter.bio),
> > > >> > +bio_sectors(iter.bio),
> > > >> > +(unsigned long)iter.bio->bi_sector);
^^^ ^
> > > >> Superfluous cast: PS3 is 64-bit only, and casts are evil.
> > >
> > > bi_sector is sector_t. The cast is ok, because printf will warn, and
> > > rightfully
> > > so since sector_t may just change its shape underneath.
> >
> > Oh yeah, that's why the _cast_ _is_ needed in the first place, by the way.
> > I was mentioning why the cast itself should be (unsigned long long) otoh.
>
> On 64-bit platforms, sector_t (which is either u64 or unsigned long, depending
> on CONFIG_LBD) is unsigned long, so there's no need for a cast. Hence there's
> no compiler warning to be silenced by adding the cast.
This is turning rather funny :-)
* Why the printk() conversion specifier must be "%llu"?
When reusing parts of this code (such as this debug message) for another
32-bit driver (we certainly seem to care about this, as per your reply),
the largest size of sector_t can be "unsigned long long", thereby causing
truncated output, and the following warning:
warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 2 has
type ‘sector_t’
Therefore, let us not depend on the fact that this driver is being used
only for 64-bit platforms as of now (especially since this is in drivers/
and not in arch/) and rather make the printk() specifier as "%llu".
[ Sadly, I had to repeat most of my previous mail, which Jan Engelhardt
appears to have snipped. ]
* Why we require an explicit (unsigned long long) cast?
Having made the above change (and say we don't have an explicit cast
there), that line now becomes:
printk("... %llu\n", ..., iter.bio->bi_sector);
Now if we build this code with CONFIG_LBD=n, sector_t becomes just an
"unsigned long" (whereas printk specifier is the larger "%llu") thereby
causing:
warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument
2 has type ‘sector_t’
Therefore, let us shut this up with an explicit (unsigned long long) cast,
as is done in most other existing code in the kernel where we want to get
bi_sector printed out, which would correctly convert the value to the
larger integer type (even negative ones, due to sign-extension) and print
it out.
> On the other hand, adding a cast may hide bugs:
> - cast to unsigned long long: When sector_t is changed to an even larger
> type, it will be silently truncated as well.
IMHO, this is not a valid enough reason, given the above (BTW if/when that
happens, we'll have to update the printk conversion specifer as well).
Personally, I'd say code that assumes "sizeof(unsigned long long) ==
sizeof(unsigned long)", and also that assumes "sizeof(unsigned long) ==
sizeof(sector_t)" -- both assumptions _are_ made by the above code --
is not good taste, even if both may be true for PS3 platform. So unless
we decide "nobody except that platform would ever build this driver
anyway", I'd suggest to make the printk specifier as "%llu" and use an
explicit (unsigned long long) cast. Therefore (on top of this series):
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
diff -ruNp a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
--- a/drivers/block/ps3disk.c 2007-08-21 06:52:34.0 +0530
+++ b/drivers/block/ps3disk.c 2007-08-21 06:56:07.0 +0530
@@ -100,10 +100,10 @@ static void ps3disk_scatter_gather(struc
rq_for_each_segment(bvec, req, iter) {
unsigned long flags;
dev_dbg(&dev->sbd.core,
- "%s:%u: bio %u: %u segs %u sectors from %lu\n",
+ "%s:%u: bio %u: %u segs %u sectors from %llu\n",
__func__, __LINE__, i, bio_segments(iter.bio),
bio_sectors(iter.bio),
- (unsigned long)iter.bio->bi_sector);
+ (unsigned long long)iter.bio->bi_sector);
size = bvec->bv_len;
buf = bvec_kmap_irq(bvec, flags);
@@ -142,8 +142,9 @@ static int ps3disk_submit_request_sg(str
start_sector = req->sector * priv->blocking_factor;
Re: [accounting regression since rc1] scheduler updates
Ingo Molnar <[EMAIL PROTECTED]> writes: You should just be using idle notifiers instead instead of adding more and more custom hooks (like NOHZ has already) x86-64 still has them and there is a old patch around to add them to i386. -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: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.
[TSO / LRO discussion snipped -- it's not the main point so no sense spending energy arguing about it] > Just be realistic and accept that RDMA is a point in time solution, > and like any other such technology takes flexibility away from users. > > Horizontal scaling of cpus up to huge arity cores, network devices > using large numbers of transmit and receive queues and classification > based queue selection, are all going to work to make things like RDMA > even more irrelevant than they already are. To me there is a real fundamental difference between RDMA and traditional SOCK_STREAM / SOCK_DATAGRAM networking, namely that messages can carry the address where they're supposed to be delivered (what the IETF calls "direct data placement"). And on top of that you can build one-sided operations aka put/get aka RDMA. And direct data placement really does give you a factor of two at least, because otherwise you're stuck receiving the data in one buffer, looking at some of the data at least, and then figuring out where to copy it. And memory bandwidth is if anything becoming more valuable; maybe LRO + header splitting + page remapping tricks can get you somewhere but as NCPUS grows then it seems the TLB shootdown cost of page flipping is only going to get worse. Don't get too hung up on the fact that current iWARP (RDMA over IP) implementations are using TCP offload -- to me that is just a side effect of doing enough processing on the NIC side of the PCI bus to be able to do direct data placement. InfiniBand with competely different transport, link and physical layers is one way to implement RDMA without TCP offload and I'm sure there will be others -- eg Intel's IOAT stuff could probably evolve to the point where you could implement iWARP with software TCP and the data placement offloaded to some DMA engine. - 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: [RFC 7/7] Switch of PF_MEMALLOC during writeout
> Right. I am not sure exactly how to handle that. There is also the issue > of the writes being deferred. I thought maybe of using pdflush to writeout > the pages? Maybe increase priority of the pdflush so that it runs > immediately when notified. Shrink_page_list would gather the dirty pages > in pvecs and then forward to a pdflush. That may make the whole thing much > cleaner. Not sure anything complicated is needed. You could just add another process flag and set PF_MEMALLOC on the first recursion? -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: unable to handle kernel NULL pointer dereference - linux-2.6.22
Hello,
after running a few instances of bittorent-curses on 2.6.22 - 2.6.22.3 it
takes about 15min to 2hrs for my System to hang. 2.6.21.7 is definately fine,
2.6.21 probably (ran for 4hrs without hanging).
If I'm lucky the Oops below makes it to my syslog (unfortunately SysRq-{p,s,i}
doesn't work when it hangs, neither can I ssh into it):
Aug 18 19:47:41 draco kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address
Aug 18 19:47:41 draco kernel: printing eip:
Aug 18 19:47:41 draco kernel: c038fcba
Aug 18 19:47:41 draco kernel: *pdpt = 33830001
Aug 18 19:47:41 draco kernel: *pde =
Aug 18 19:47:41 draco kernel: Oops: 0002 [#1]
Aug 18 19:47:41 draco kernel: SMP
Aug 18 19:47:41 draco kernel: Modules linked in: snd_hda_intel snd_emu10k1
cls_u32 sch_sfq sch_htb snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
snd_pcm_oss snd_mixer_oss rfcomm hidp l2cap nfsd exportfs lockd sunrpc
coretemp hwmon eeprom snd_rawmidi snd_ac97_codec hci_usb ac97_bus
snd_seq_device snd_util_mem snd_pcm bluetooth snd_hwdep snd_timer snd
snd_page_alloc i2c_i801 emu10k1_gp gameport i2c_core sg
Aug 18 19:47:41 draco kernel: CPU:0
Aug 18 19:47:41 draco kernel: EIP:0060:[]Not tainted VLI
Aug 18 19:47:41 draco kernel: EFLAGS: 00210202 (2.6.22.2poison #14)
Aug 18 19:47:41 draco kernel: EIP is at tcp_sendmsg+0x40a/0xb70
Aug 18 19:47:41 draco kernel: eax: ebx: ec5b807c ecx: c04b43a0
edx: ec5b807c
Aug 18 19:47:41 draco kernel: esi: ec5b8000 edi: 0100 ebp: ec524180
esp: f3a11d30
Aug 18 19:47:41 draco kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss:
0068
Aug 18 19:47:41 draco kernel: Process bittorrent-curs (pid: 3974, ti=f3a1
task=f3a0e000 task.ti=f3a1)
Aug 18 19:47:41 draco kernel: Stack: ebe562f5 000b
f3a11d94 ec5b807c
Aug 18 19:47:41 draco kernel:0001 00100100 f3a11f40
0040 0200 0200 04b6
Aug 18 19:47:41 draco kernel:08604707 00200200 f3e5c798 eeaa4b40
f3a0e000 01f5 00100100
Aug 18 19:47:41 draco kernel: Call Trace:
Aug 18 19:47:41 draco kernel: [] inet_sendmsg+0x37/0x70
Aug 18 19:47:41 draco kernel: [] sock_sendmsg+0xbf/0xf0
Aug 18 19:47:41 draco kernel: [] autoremove_wake_function+0x0/0x50
Aug 18 19:47:41 draco kernel: [] default_wake_function+0x0/0x10
Aug 18 19:47:41 draco last message repeated 3 times
Aug 18 19:47:41 draco kernel: [] find_extend_vma+0x1d/0x70
Aug 18 19:47:41 draco kernel: [] sys_sendto+0x12f/0x180
Aug 18 19:47:41 draco kernel: [] futex_wake+0xac/0xd0
Aug 18 19:47:41 draco kernel: [] do_futex+0x6bd/0xbd0
Aug 18 19:47:41 draco kernel: [] sys_send+0x33/0x40
Aug 18 19:47:41 draco kernel: [] sys_socketcall+0x142/0x280
Aug 18 19:47:41 draco kernel: [] copy_to_user+0x30/0x60
Aug 18 19:47:41 draco kernel: [] syscall_call+0x7/0xb
Aug 18 19:47:41 draco kernel: ===
Aug 18 19:47:41 draco kernel: Code: 85 fb 06 00 00 80 ca 10 8b 83 94 00 00 00
88 53 68 f0 81 00 00 00 01 00 8b 44 24 18 ff 40 08 8b 54 24 18 8b 42 04 89 13
89 43 04 <89> 18 89 5a 04 8b 8e 2c 01 00 00 85 c9 0f 84 19 06 00 00 8b 83
Aug 18 19:47:41 draco kernel: EIP: [] tcp_sendmsg+0x40a/0xb70 SS:ESP
0068:f3a11d30
Aug 18 19:47:51 draco kernel:
Aug 18 19:47:51 draco kernel: Pid: 3812, comm:X
Aug 18 19:47:51 draco kernel: EIP: 0060:[] CPU: 0
Aug 18 19:47:51 draco kernel: EIP is at __get_free_pages+0x22/0x40
Aug 18 19:47:51 draco kernel: EFLAGS: 3246Not tainted
(2.6.22.2poison #14)
Aug 18 19:47:51 draco kernel: EAX: 00d0 EBX: 00d0 ECX: c0496b40 EDX:
Aug 18 19:47:51 draco kernel: ESI: EDI: f5ba1be4 EBP: f49a4d80 DS:
007b ES: 007b FS: 00d8
Aug 18 19:47:51 draco kernel: CR0: 8005003b CR2: b7384000 CR3: 37165000 CR4:
06f0
Aug 18 19:47:51 draco kernel: [] __pollwait+0xa6/0x100
Aug 18 19:47:51 draco kernel: [] unix_poll+0x17/0xa0
Aug 18 19:47:51 draco kernel: [] sock_poll+0xc/0x10
Aug 18 19:47:51 draco kernel: [] do_select+0x25c/0x490
Aug 18 19:47:51 draco kernel: [] __pollwait+0x0/0x100
Aug 18 19:47:51 draco kernel: [] default_wake_function+0x0/0x10
Aug 18 19:47:51 draco last message repeated 19 times
Aug 18 19:47:51 draco kernel: [] core_sys_select+0x1c8/0x2f0
Aug 18 19:47:51 draco kernel: [] do_readv_writev+0x120/0x190
Aug 18 19:47:51 draco kernel: [] sock_aio_write+0x0/0x110
Aug 18 19:47:51 draco kernel: [] sys_select+0x4d/0x1b0
Aug 18 19:47:51 draco kernel: [] vfs_writev+0x3c/0x50
Aug 18 19:47:51 draco kernel: [] sys_writev+0x47/0x80
Aug 18 19:47:51 draco kernel: [] syscall_call+0x7/0xb
Aug 18 19:47:51 draco kernel: ===
---
It's also attached together with one from a tainted 2.6.22.3
The error is reproducable for me by running 4 bittorent instances and wating.
2.6.22 lives no longer than 2hrs, so when bisecting I assumed it was good
after 4hrs ... so I may as well have taken a wrong turn. Result here:
00ed8e3dd
[PATCH] Console keyboard events and accessibility
Some external modules like Speakup need to use the PC keyboard to control
them and also need to get keyboard feedback (caps lock status, etc.)
This adds a keyboard notifier that such modules can use to get the keyboard
events and possibly eat them, at several stages:
- keycodes: even before translation into keysym.
- unbound keycodes: when no keysym is bound.
- unicode: when the keycode would get translated into a unicode character.
- keysym: when the keycode would get translated into a keysym.
- post_keysym: after the keysym got interpreted, so as to see the result
(caps lock, etc.)
This also provides access to k_handler so as to permit simulation of
keypresses.
Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]>
---
Hi,
Some blind people use a kernel engine called Speakup which uses hardware
synthesis to speak what gets displayed on the screen. They use the
PC keyboard to control this engine (start/stop, accelerate, ...) and
also need to get keyboard feedback (to make sure to know what they are
typing, the caps lock status, etc.)
Up to now, the way it was done was very ugly. Below is a patch to add a
notifier list for permitting a far better implementation, see ChangeLog
above for details.
You may wonder why this can't be done at the input layer. The problem
is that what people want to monitor is the console keyboard, i.e. all
input keyboards that got attached to the console, and with the currently
active keymap (i.e. keysyms, not only keycodes).
Samuel
diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index 2ce0af1..55646de 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
extern void ctrl_alt_del(void);
@@ -80,7 +81,8 @@
typedef void (k_handler_fn)(struct vc_data *vc, unsigned char value,
char up_flag);
static k_handler_fn K_HANDLERS;
-static k_handler_fn *k_handler[16] = { K_HANDLERS };
+k_handler_fn *k_handler[16] = { K_HANDLERS };
+EXPORT_SYMBOL(k_handler);
#define FN_HANDLERS\
fn_null,fn_enter, fn_show_ptregs, fn_show_mem,\
@@ -159,6 +161,23 @@
static int sysrq_alt;
/*
+ * Notifier list for console keyboard events
+ */
+static ATOMIC_NOTIFIER_HEAD(keyboard_notifier_list);
+
+int register_keyboard_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(&keyboard_notifier_list, nb);
+}
+EXPORT_SYMBOL(register_keyboard_notifier);
+
+int unregister_keyboard_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_unregister(&keyboard_notifier_list, nb);
+}
+EXPORT_SYMBOL(unregister_keyboard_notifier);
+
+/*
* Translation of scancodes to keycodes. We set them on only the first
* keyboard in the list that accepts the scancode and keycode.
* Explanation for not choosing the first attached keyboard anymore:
@@ -1119,6 +1138,7 @@
unsigned char type, raw_mode;
struct tty_struct *tty;
int shift_final;
+ struct keyboard_notifier_param param = { .vc = vc, .value = keycode,
.down = down };
tty = vc->vc_tty;
@@ -1206,10 +1226,11 @@
return;
}
- shift_final = (shift_state | kbd->slockstate) ^ kbd->lockstate;
+ param.shift = shift_final = (shift_state | kbd->slockstate) ^
kbd->lockstate;
key_map = key_maps[shift_final];
- if (!key_map) {
+ if (atomic_notifier_call_chain(&keyboard_notifier_list, KBD_KEYCODE,
¶m) == NOTIFY_STOP || !key_map) {
+ atomic_notifier_call_chain(&keyboard_notifier_list,
KBD_UNBOUND_KEYCODE, ¶m);
compute_shiftstate();
kbd->slockstate = 0;
return;
@@ -1226,6 +1247,9 @@
type = KTYP(keysym);
if (type < 0xf0) {
+ param.value = keysym;
+ if (atomic_notifier_call_chain(&keyboard_notifier_list,
KBD_UNICODE, ¶m) == NOTIFY_STOP)
+ return;
if (down && !raw_mode)
to_utf8(vc, keysym);
return;
@@ -1233,9 +1257,6 @@
type -= 0xf0;
- if (raw_mode && type != KT_SPEC && type != KT_SHIFT)
- return;
-
if (type == KT_LETTER) {
type = KT_LATIN;
if (vc_kbd_led(kbd, VC_CAPSLOCK)) {
@@ -1244,9 +1265,18 @@
keysym = key_map[keycode];
}
}
+ param.value = keysym;
+
+ if (atomic_notifier_call_chain(&keyboard_notifier_list, KBD_KEYSYM,
¶m) == NOTIFY_STOP)
+ return;
+
+ if (raw_mode && type != KT_SPEC && type != KT_SHIFT)
+ return;
(*k_handler[type])(vc, keysym & 0xff, !down);
+ atomic_notifier_call_chain(&keyboard_notifier_list, KBD_POST_KEYSYM,
¶m);
+
if (type != KT_SLOCK)
kbd->slockstate = 0;
}
diff --git a/include/linux/keyboard.h b/include/linux/keyboard.h
--- a/include/linux/keyboard.h
+++ b/inc
[PATCH] dio: zero struct dio with kzalloc instead of manually
This patch uses kzalloc to zero all of struct dio rather than manually trying
to track which fields we rely on being zero. It passed aio+dio stress testing
and some bug regression testing on ext3.
This patch was introduced by Linus in the conversation that lead up to Badari's
minimal fix to manually zero .map_bh.b_state in commit:
6a648fa72161d1f6468dabd96c5d3c0db04f598a
It makes the code a bit smaller. Maybe a couple fewer cachelines to
load, if we're lucky:
textdata bss dec hex filename
3285925 568506 1304616 5159047 4eb887 vmlinux
3285797 568506 1304616 5158919 4eb807 vmlinux.patched
I was unable to measure a stable difference in the number of cpu cycles spent
in blockdev_direct_IO() when pushing aio+dio 256K reads at ~340MB/s.
So the resulting intent of the patch isn't a performance gain but to
avoid exposing ourselves to the risk of finding another field like
.map_bh.b_state where we rely on zeroing but don't enforce it in the
code.
Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
---
fs/direct-io.c | 18 +-
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/fs/direct-io.c b/fs/direct-io.c
index 1d0bdf0..be86702 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -958,36 +958,22 @@ direct_io_worker(int rw, struct kiocb *iocb, struct inode
*inode,
ssize_t ret2;
size_t bytes;
- dio->bio = NULL;
dio->inode = inode;
dio->rw = rw;
dio->blkbits = blkbits;
dio->blkfactor = inode->i_blkbits - blkbits;
- dio->start_zero_done = 0;
- dio->size = 0;
dio->block_in_file = offset >> blkbits;
- dio->blocks_available = 0;
- dio->cur_page = NULL;
- dio->boundary = 0;
- dio->reap_counter = 0;
dio->get_block = get_block;
dio->end_io = end_io;
- dio->map_bh.b_private = NULL;
- dio->map_bh.b_state = 0;
dio->final_block_in_bio = -1;
dio->next_block_for_io = -1;
- dio->page_errors = 0;
- dio->io_error = 0;
- dio->result = 0;
dio->iocb = iocb;
dio->i_size = i_size_read(inode);
spin_lock_init(&dio->bio_lock);
dio->refcount = 1;
- dio->bio_list = NULL;
- dio->waiter = NULL;
/*
* In case of non-aligned buffers, we may need 2 more
@@ -995,8 +981,6 @@ direct_io_worker(int rw, struct kiocb *iocb, struct inode
*inode,
*/
if (unlikely(dio->blkfactor))
dio->pages_in_io = 2;
- else
- dio->pages_in_io = 0;
for (seg = 0; seg < nr_segs; seg++) {
user_addr = (unsigned long)iov[seg].iov_base;
@@ -1194,7 +1178,7 @@ __blockdev_direct_IO(int rw, struct kiocb *iocb, struct
inode *inode,
}
}
- dio = kmalloc(sizeof(*dio), GFP_KERNEL);
+ dio = kzalloc(sizeof(*dio), GFP_KERNEL);
retval = -ENOMEM;
if (!dio)
goto out;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code
On Mon, 2007-08-20 at 16:27 -0400, Mathieu Desnoyers wrote:
> The marker activation functions sits in kernel/marker.c. A hash table is used
> to keep track of the registered probes and armed markers, so the markers
> within
> a newly loaded module that should be active can be activated at module load
> time.
Hi Mathieu!
Just reading through this patch, a couple of comments:
> +/* To be used for string format validity checking with gcc */
> +static inline void __mark_check_format(const char *fmt, ...)
> + __attribute__ ((format (printf, 1, 2)));
> +static inline void __mark_check_format(const char *fmt, ...) { }
If you place the __attribute__() before the function name, you can do
this in the definition.
> ===
> --- linux-2.6-lttng.orig/kernel/module.c 2007-08-10 19:44:18.0
> -0400
> +++ linux-2.6-lttng/kernel/module.c 2007-08-10 23:54:38.0 -0400
> @@ -1980,6 +1986,10 @@ static struct module *load_module(void _
> sechdrs[immediateindex].sh_size /
> sizeof(*mod->immediate);
> }
> #endif
> + if (markersindex)
> + sechdrs[markersindex].sh_flags |= SHF_ALLOC;
> + if (markersstringsindex)
> + sechdrs[markersstringsindex].sh_flags |= SHF_ALLOC;
>
Perhaps I'm missing something, but I don't see why these sections
wouldn't be SHF_ALLOC already.
> mod->unused_syms = (void *)sechdrs[unusedindex].sh_addr;
> if (unusedcrcindex)
> @@ -2021,6 +2031,13 @@ static struct module *load_module(void _
> if (err < 0)
> goto cleanup;
> }
> +#ifdef CONFIG_MARKERS
> + if (markersindex) {
> + mod->markers = (void *)sechdrs[markersindex].sh_addr;
> + mod->num_markers =
> + sechdrs[markersindex].sh_size / sizeof(*mod->markers);
> + }
> +#endif
Because of the wonders of ELF, section 0 has sh_addr and sh_size 0. So
the if (markersindex) is unnecessary here.
> +/*
> + * Get marker if the marker is present in the marker hash table.
> + * Must be called with markers_mutex held.
> + * Returns NULL if not present.
> + */
> +static struct marker_entry *_get_marker(const char *name)
You seem to really enjoy underscores, yet I'm having trouble
understanding why this would have an underscore in it.
> +{
> + struct hlist_head *head;
> + struct hlist_node *node;
> + struct marker_entry *e;
> + size_t len = strlen(name) + 1;
> + u32 hash = jhash(name, len-1, 0);
> +
> + head = &marker_table[hash & ((1 << MARKER_HASH_BITS)-1)];
> + hlist_for_each_entry(e, node, head, hlist) {
> + if (!strcmp(name, e->name))
> + return e;
> + }
> + return NULL;
> +}
OK, don't understand the strlen, len, len-1 dance here?
> +/*
> + * Updates the probe callback corresponding to a range of markers.
> + * Must be called with markers_mutex held.
> + */
> +static void _marker_update_probe_range(
And yet:
> +void module_marker_update(struct module *mod)
> +{
> + if (!mod->taints)
> + _marker_update_probe_range(mod->markers,
> + mod->markers+mod->num_markers, NULL, NULL);
> +}
This doesn't hold the markers_mutex.
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/9] Use NOMEMALLOC reclaim to allow reclaim if PF_MEMALLOC is set
On Mon, Aug 20, 2007 at 11:14:08PM +0200, Peter Zijlstra wrote: > On Mon, 2007-08-20 at 13:27 -0700, Christoph Lameter wrote: > > On Mon, 20 Aug 2007, Peter Zijlstra wrote: > > > > > > Plus the same issue can happen today. Writes are usually not completed > > > > during reclaim. If the writes are sufficiently deferred then you have > > > > the > > > > same issue now. > > > > > > Once we have initiated (disk) writeout we do not need more memory to > > > complete it, all we need to do is wait for the completion interrupt. > > > > We cannot reclaim the page as long as the I/O is not complete. If you > > have too many anonymous pages and the rest of memory is dirty then you can > > get into OOM scenarios even without this patch. > > As long as the reserve is large enough to completely initialize writeout > of a single page we can make progress. Once writeout is initialized the > completion interrupt is guaranteed to happen (assuming working > hardware). Although interestingly, we are not guaranteed to have enough memory to completely initialise writeout of a single page. The buffer layer doesn't require disk blocks to be allocated at page dirty-time. Allocating disk blocks can require complex filesystem operations and readin of buffer cache pages. The buffer_head structures themselves may not even be present and must be allocated :P In _practice_, this isn't such a problem because we have dirty limits, and we're almost guaranteed to have some clean pages to be reclaimed. In this same way, networked filesystems are not a problem in practice. However network swap, because there is no dirty limits on swap, can actually see the deadlock problems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] 10-dots braille keyboards
Hi,
Some braille keyboards have 10 dots, so extend the Input braille keys
definitions.
Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]>
diff --git a/include/linux/input.h b/include/linux/input.h
index e02c6a6..17df5a7 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -552,6 +552,8 @@ struct input_absinfo {
#define KEY_BRL_DOT6 0x1f6
#define KEY_BRL_DOT7 0x1f7
#define KEY_BRL_DOT8 0x1f8
+#define KEY_BRL_DOT9 0x1f9
+#define KEY_BRL_DOT10 0x1fa
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTINGKEY_MUTE
diff --git a/include/linux/keyboard.h b/include/linux/keyboard.h
index de76843..7ddbc30 100644
--- a/include/linux/keyboard.h
+++ b/include/linux/keyboard.h
@@ -437,8 +437,10 @@ extern unsigned short plain_map[NR_KEYS];
#define K_BRL_DOT6 K(KT_BRL, 6)
#define K_BRL_DOT7 K(KT_BRL, 7)
#define K_BRL_DOT8 K(KT_BRL, 8)
+#define K_BRL_DOT9 K(KT_BRL, 9)
+#define K_BRL_DOT10 K(KT_BRL, 10)
-#define NR_BRL 9
+#define NR_BRL 11
#define MAX_DIACR 256
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kconfig: add *_silentdefconfig feature for config targets
Being able to run 'silentoldconfig' with an existing .config has been
immensely useful, especially for automated builds. If the kernel code
changes in an incompatible manner without the associated .config being
updated, the build will fail and call attention to the need for an update.
AFAICT, there is nothing similar when using *_defconfig; one must copy
a .config manually, and then run silentoldconfig. Simply running the
associated _defconfig will quietly update the config (which may silently
drop config options). This patch adds a *_silentdefconfig target, with
semantics similar to silentoldconfig. It will take the defconfig from
arch/$(ARCH)/configs/$x_defconfig, check for changes, and if there are
none, write out a .config. If there have been changes and stdin is
valid, it will prompt for updates. If there have been changes and
stdin is not valid, it will bail out with an error.
A few things to note:
- Using getopt() in scripts/kconfig/conf.c would likely simplify things,
but that's a much larger patch. Is there a reason we don't use it?
- To make it truly silent, I had to change conf_write() to accept an
additional arg. The alternative is to not have conf_write spit out
any information when it writes a file. Personally, I don't see the need
for it to spit out information, but I figured I'd take the more cautious
route. If folks don't care, I can update this patch to remove it.
- We seem to switch between using _() and not using it for strings; I'm
assuming that we don't actually care about i18n in conf.c, and that the
_() stuff was just copied from elsewhere. If that's not the case, I
can update the patch to wrap strings properly.
Comments/suggestions/critique welcome.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
Makefile|2 ++
scripts/kconfig/Makefile|3 +++
scripts/kconfig/conf.c | 40 +---
scripts/kconfig/confdata.c |9 +
scripts/kconfig/gconf.c |4 ++--
scripts/kconfig/lkc_proto.h |2 +-
scripts/kconfig/mconf.c |4 ++--
scripts/kconfig/qconf.cc|6 +++---
8 files changed, 51 insertions(+), 19 deletions(-)
diff --git a/Makefile b/Makefile
index 91759a6..d4b35f7 100644
--- a/Makefile
+++ b/Makefile
@@ -1164,6 +1164,8 @@ help:
@$(if $(boards), \
$(foreach b, $(boards), \
printf " %-24s - Build for %s\\n" $(b) $(subst
_defconfig,,$(b));) \
+ $(foreach b, $(boards), \
+ printf " %-24s - Quiet build for %s\\n" $(subst
_defconfig,_silentdefconfig,$(b)) $(subst _defconfig,,$(b));) \
echo '')
@echo ' make V=0|1 [targets] 0 => quiet build (default), 1 => verbose
build'
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 8986a48..44845bd 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -67,6 +67,9 @@ endif
%_defconfig: $(obj)/conf
$(Q)$< -D arch/$(ARCH)/configs/$@ arch/$(ARCH)/Kconfig
+%_silentdefconfig: $(obj)/conf
+ $(Q)$< -S arch/$(ARCH)/configs/$(subst _silentdefconfig,_defconfig,$@)
arch/$(ARCH)/Kconfig
+
# Help text used by make help
help:
@echo ' config - Update current config utilising a
line-oriented program'
diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 8be6a42..fecf5f8 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -22,6 +22,7 @@ enum {
ask_new,
ask_silent,
set_default,
+ set_silentdefault,
set_yes,
set_mod,
set_no,
@@ -64,10 +65,11 @@ static void strip(char *str)
static void check_stdin(void)
{
- if (!valid_stdin && input_mode == ask_silent) {
+ if (!valid_stdin && (input_mode == ask_silent ||
+ input_mode == set_silentdefault)) {
printf(_("aborted!\n\n"));
printf(_("Console input/output is redirected. "));
- printf(_("Run 'make oldconfig' to update configuration.\n\n"));
+ printf(_("Configuration file needs to be updated.\n\n"));
exit(1);
}
}
@@ -102,6 +104,7 @@ static void conf_askvalue(struct symbol *sym, const char
*def)
break;
case ask_new:
case ask_silent:
+ case set_silentdefault:
if (sym_has_value(sym)) {
printf("%s\n", def);
return;
@@ -349,6 +352,7 @@ static int conf_choice(struct menu *menu)
switch (input_mode) {
case ask_new:
case ask_silent:
+ case set_silentdefault:
if (!is_new) {
cnt = def;
printf("%d\n", cnt);
@@ -420,7 +424,9 @@ static void conf(struct menu *menu)
switch (prop->type) {
case P_MENU:
- if (
Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)
On Mon, Aug 20, 2007 at 12:15:01PM -0700, Christoph Lameter wrote: > On Mon, 20 Aug 2007, Peter Zijlstra wrote: > > > > > <> What Christoph is proposing is doing recursive reclaim and not > > > > initiating writeout. This will only work _IFF_ there are clean pages > > > > about. Which in the general case need not be true (memory might be > > > > packed with anonymous pages - consider an MPI cluster doing computation > > > > stuff). So this gets us a workload dependant solution - which IMHO is > > > > bad! > > > > > > Although you will quite likely have at least a couple of MB worth of > > > clean program text. The important part of recursive reclaim is that it > > > doesn't so easily allow reclaim to blow all memory reserves (including > > > interrupt context). Sure you still have theoretical deadlocks, but if > > > I understand correctly, they are going to be lessened. I would be > > > really interested to see if even just these recursive reclaim patches > > > eliminate the problem in practice. > > > > were we much bothered by the buffered write deadlock? - why accept a > > known deadlock if a solid solution is quite attainable? > > Buffered write deadlock? How does that exactly occur? Memory allocation in > the writeout path while we hold locks? Different topic. Peter was talking about the write(2) write deadlock where we take a page fault while holding a page lock (which leads to lock inversion, taking the lock twice etc.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)
On Mon, Aug 20, 2007 at 05:51:34AM +0200, Peter Zijlstra wrote: > On Thu, 2007-08-16 at 05:29 +0200, Nick Piggin wrote: > > Well perhaps it doesn't work for networked swap, because dirty accounting > > doesn't work the same way with anonymous memory... but for _filesystems_, > > right? > > > > I mean, it intuitively seems like a good idea to terminate the recursive > > allocation problem with an attempt to reclaim clean pages rather than > > immediately let them have-at our memory reserve that is used for other > > things as well. > > I'm concerned about the worst case scenarios, and those don't change. > The proposed changes can be seen as an optimisation of various things, > but they do not change the fundamental issues. No, although it sounded like you didn't see any use in these patches. Which be true if you're just looking at solving the theoretical deadlocks, but I just think they might be worth looking at to practically solve some of them and just give better reclaim behaviour in general (but in saying that I'm not excluding your patches). > > Well yeah I think you simply have to reserve a minimum amount of memory in > > order to reclaim a page, and I don't see any other way to do it other than > > what you describe to be _technically_ deadlock free. > > Right, and I guess I have to go at it again, this time ensuring not to > touch the fast-path nor sacrificing anything NUMA for simplicity in the > reclaim path. > > (I think its a good thing to be technically deadlock free - and if your > work on the fault path rewrite and buffered write rework shows anything > it is that you seem to agree with this) I do of course. There is one thing to have a real lock deadlock in some core path, and another to have this memory deadlock in a known-to-be-dodgy configuration (Linus said last year that he didn't want to go out of our way to support this, right?)... But if you can solve it without impacting fastpaths etc. then I don't see any objection to it. > > But firstly, you don't _want_ to start dropping packets when you hit a tough > > patch in reclaim -- even if you are strictly deadlock free. And secondly, > > I think recursive reclaim could reduce the deadlocks in practice which is > > not a bad thing as your patches aren't merged. > > Non of the people who have actually used these patches seem to object to > the dropping packets thing. Nor do I see that as a real problem, > networks are assumed lossy - also if you really need that traffic for a > RT app that also runs on the machine you need networked swap on (odd > combination but hey, it should be possible) then I can make that work as > well with a little bit more effort. I don't mean for correctness, but for throughput. If you're doing a lot of network operations right near the memory limit, then it could be possible that these deadlock paths get triggered relatively often. With Christoph's patches, I think it would tend to be less. > > How are your deadlock patches going anyway? AFAIK they are mostly a network > > issue and I haven't been keeping up with them for a while. > > They really do rely on some VM interaction too, network does not have > enough information to break out of the deadlock on its own. The thing I don't much like about your patches is the addition of more of these global reserve type things in the allocators. They kind of suck (not your code, just the concept of them in general -- ie. including the PF_MEMALLOC reserve). I'd like to eventually reach a model where reclaimable memory from a given subsystem is always backed by enough resources to be able to reclaim it. What stopped you from going that route with the network subsystem? (too much churn, or something fundamental?) > > Although you will quite likely have at least a couple of MB worth of > > clean program text. The important part of recursive reclaim is that it > > doesn't so easily allow reclaim to blow all memory reserves (including > > interrupt context). Sure you still have theoretical deadlocks, but if > > I understand correctly, they are going to be lessened. I would be > > really interested to see if even just these recursive reclaim patches > > eliminate the problem in practice. > > were we much bothered by the buffered write deadlock? - why accept a > known deadlock if a solid solution is quite attainable? As a general statement, I agree of course ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/24] make atomic_read() behave consistently across all architectures
On Tue, Aug 21, 2007 at 01:02:01AM +0200, Segher Boessenkool wrote: > >>And no, RMW on MMIO isn't "problematic" at all, either. > >> > >>An RMW op is a read op, a modify op, and a write op, all rolled > >>into one opcode. But three actual operations. > > > >Maybe for some CPUs, but not all. ARM for instance can't use the > >load exclusive and store exclusive instructions to MMIO space. > > Sure, your CPU doesn't have RMW instructions -- how to emulate > those if you don't have them is a totally different thing. I thought that ARM's load exclusive and store exclusive instructions were its equivalent of LL and SC, which RISC machines typically use to build atomic sequences of instructions -- and which normally cannot be applied to MMIO space. 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/
Re: [patch 2/2] Sort module list by pointer address to get coherent sleepable seq_file iterators
On Mon, 2007-08-20 at 16:26 -0400, Mathieu Desnoyers wrote: > plain text document attachment (module.c-sort-module-list.patch) > A race that appears both in /proc/modules and in kallsyms: if, between the > seq file reads, the process is put to sleep and at this moment a module is > or removed from the module list, the listing will skip an amount of > modules/symbols corresponding to the amount of elements present in the > unloaded > module, but at the current position in the list if the iteration is located > after the removed module. > > The cleanest way I found to deal with this problem is to sort the module list. > We can then keep the old struct module * as the old iterator, knowing the it > may > be removed between the seq file reads, but we only use it as "get next". If it > is not present in the module list, the next pointer will be used. > > By doing this, removing a given module will now only fuzz the output related > to > this specific module, not any random module anymore. Since modprobe uses > /proc/modules, it might be important to make sure multiple concurrent running > modprobes won't interfere with each other. You've reduced, but not eliminated, the problem. A new module inserted is quite likely to reuse the same address. I don't have a real problem with this patch, but I'm wondering if the problem is theoretical or demonstrated. Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scripts/get_maintainer.pl
Find maintainer info for a patch or a file
Changes since last submission:
Added -f to search for the maintainer for a specific file
Added --scm - Print the S: information
Added --web - Print the W: information
Added die message "git not found. Add --nogit to options"
Changed git log tracking interval from last 6 months to last 12 months
Removed --tree lk_source option
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
new file mode 100755
index 000..abfa212
--- /dev/null
+++ b/scripts/get_maintainer.pl
@@ -0,0 +1,424 @@
+#!/usr/bin/perl -w
+# (c) 2007, Joe Perches <[EMAIL PROTECTED]>
+# created from checkpatch.pl
+#
+# Print selected MAINTAINERS information for
+# the files modified in a patch or for a file
+#
+# usage: perl scripts/get_maintainers.pl [OPTIONS]
+#perl scripts/get_maintainers.pl [OPTIONS] -f
+#
+# Licensed under the terms of the GNU GPL License version 2
+
+use strict;
+
+my $P = $0;
+my $V = '0.10';
+
+use Getopt::Long qw(:config no_auto_abbrev);
+
+my $lk_path = "./";
+my $email_usename = 1;
+my $email_maintainer = 1;
+my $email_list = 1;
+my $email_subscriber_list = 0;
+my $email_git = 1;
+my $email_git_penguin_chiefs = 0;
+my $output_multiline = 1;
+my $output_separator = ", ";
+my $email = 0;
+my $scm = 0;
+my $web = 0;
+my $file = 0;
+
+my @penguin_chief = ();
+push(@penguin_chief,"Linus Torvalds:[EMAIL PROTECTED]");
+push(@penguin_chief,"Andrew Morton:[EMAIL PROTECTED]");
+
+my @penguin_chief_names = ();
+foreach my $chief (@penguin_chief) {
+if ($chief =~ m/^(.*):(.*)/) {
+ my $chief_name = $1;
+ my $chief_addr = $2;
+ push(@penguin_chief_names, $chief_name);
+}
+}
+my $penguin_chiefs = "\(" . join("|",@penguin_chief_names) . "\)";
+
+GetOptions(
+ 'git!' => \$email_git,
+ 'git-chief-penguins!' => \$email_git_penguin_chiefs,
+ 'm!' => \$email_maintainer,
+ 'n!' => \$email_usename,
+ 'l!' => \$email_list,
+ 's!' => \$email_subscriber_list,
+ 'multiline!' => \$output_multiline,
+ 'separator=s' => \$output_separator,
+ 'scm!' => \$scm,
+ 'web!' => \$web,
+ 'f' => \$file,
+ ) or exit;
+
+my $exit = 0;
+
+if ($#ARGV < 0) {
+usage();
+die "$P: argument missing: patch file or -f file please";
+}
+
+$email = ($email_maintainer || $email_list || $email_subscriber_list
+ || $email_git ||$email_git_penguin_chiefs);
+
+my $selections = $email + $scm + $web;
+if ( $selections == 0 || $selections > 1) {
+usage();
+die "$P: Please select one of email categories, scm, or web\n";
+}
+
+if (!top_of_kernel_tree("./")) {
+die "$P: The current directory does not appear to be "
+ . "a linux kernel source tree.\n";
+}
+
+## Read MAINTAINERS for type/value pairs
+
+my @typevalue = ();
+open(MAINT, "<${lk_path}MAINTAINERS") || die "$P: Can't open
${lk_path}MAINTAINERS\n";
+while () {
+if (m/^(\C):\s*(.*)/) {
+ my $type = $1;
+ my $value = $2;
+
+ ##Filename pattern matching
+ if ($type eq "F" || $type eq "X") {
+ $value =~ [EMAIL PROTECTED]@[EMAIL PROTECTED]; ##Convert . to
\.
+ $value =~ s/\*/\.\*/g; ##Convert * to .*
+ }
+ push(@typevalue, "$type:$value");
+} elsif (!/^(\s)*$/) {
+ push(@typevalue, $_);
+}
+}
+close(MAINT);
+
+## use the filename on the command line or find the filenames in the patchfile
+
+my @files = ();
+
+if ($file) {
+if (!(-f $ARGV[0])) {
+ die "$P: file '${ARGV[0]}' not found\n";
+}
+push(@files, $ARGV[0]);
+} else {
+open(PATCH, "<$ARGV[0]") or die "$P: Can't open ${ARGV[0]}\n";
+while () {
+ if (m/^\+\+\+\s+(\S+)/) {
+ my $file = $1;
+ $file =~ [EMAIL PROTECTED]/]*/@@;
+ $file =~ [EMAIL PROTECTED]@@;
+ push(@files, $file);
+ }
+}
+close(PATCH);
+}
+
[EMAIL PROTECTED] = sort_and_uniq(@files);
+
+# Find responsible parties
+
+my @email_to = ();
+my @scm = ();
+my @web = ();
+
+foreach my $file (@files) {
+my $exclude = 0;
+
+#Git
+
+if ($email_git_penguin_chiefs) {
+ foreach my $chief (@penguin_chief) {
+ if ($chief =~ m/^(.*):(.*)/) {
+ my $chief_name = $1;
+ my $chief_addr = $2;
+ if ($email_usename) {
+ push(@email_to, format_email($chief_name, $chief_addr));
+ } else {
+ push(@email_to, $chief_addr);
+ }
+ }
+ }
+}
+
+if ($email_git) {
+ recent_git_signoffs($file);
+}
+
+#Do not match excluded file patterns
+
+foreach my $line (@typevalue) {
+ if ($line =~ m/^(\C):(.*)/) {
+ my $type = $1;
+ my $value = $2;
+ if ($type eq 'X') {
+ if (file_match_pattern($file, $value)) {
+ $exclude = 1;
+ }
+ }
+
[patch 21/23] Add cmpxchg_local to sparc64 (update)
Add cmpxchg_local to sparc64
Use cmpxchg_u32 and cmpxchg_u64 for cmpxchg_local and cmpxchg64_local. For other
type sizes, use the new generic cmpxchg_local (disables interrupt).
Change:
* Julian Calaby ([EMAIL PROTECTED]) wrote:
> Shouldn't #includes go at the start of the file?
>
Since the header depends on local_irqsave/local_irqrestore, it must be
included after their declaration.
Actually, being below the
#include should be enough, and on sparc64 it is
included at the beginning of system.h.
So it makes sense to move it up for sparc64.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
---
include/asm-sparc64/system.h | 25 +
1 file changed, 25 insertions(+)
Index: linux-2.6-lttng/include/asm-sparc64/system.h
===
--- linux-2.6-lttng.orig/include/asm-sparc64/system.h 2007-08-20
17:40:57.0 -0400
+++ linux-2.6-lttng/include/asm-sparc64/system.h2007-08-20
19:42:32.0 -0400
@@ -9,6 +9,7 @@
#ifndef __ASSEMBLY__
#include
+#include
/*
* Sparc (general) CPU types
@@ -314,6 +315,30 @@ __cmpxchg(volatile void *ptr, unsigned l
(unsigned long)_n_, sizeof(*(ptr))); \
})
+/*
+ * cmpxchg_local and cmpxchg64_local are atomic wrt current CPU. Always make
+ * them available.
+ */
+
+static inline unsigned long __cmpxchg_local(volatile void *ptr,
+ unsigned long old,
+ unsigned long new, int size)
+{
+ switch (size) {
+ case 4:
+ case 8: return __cmpxchg(ptr, old, new, size);
+ default:
+ return __cmpxchg_local_generic(ptr, old, new, size);
+ }
+
+ return old;
+}
+
+#define cmpxchg_local(ptr,o,n) \
+ (__typeof__(*(ptr)))__cmpxchg_local((ptr), (unsigned long)(o), \
+(unsigned long)(n), sizeof(*(ptr)))
+#define cmpxchg64_local(ptr,o,n) cmpxchg_local((ptr), (o), (n))
+
#endif /* !(__ASSEMBLY__) */
#define arch_align_stack(x) (x)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 21/23] Add cmpxchg_local to sparc64
On 8/21/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Tue, 21 Aug 2007, Julian Calaby wrote: > > > >}) > > > > > > +#include > > > > Shouldn't #includes go at the start of the file? > > Most of the timee but there are exceptions. As with most things =) However, in the context of this patch, is having the #include here correct or not? Thanks, -- Julian Calaby Email: [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 21/23] Add cmpxchg_local to sparc64
On Tue, 21 Aug 2007, Julian Calaby wrote: > >}) > > > > +#include > > Shouldn't #includes go at the start of the file? Most of the timee but there are exceptions. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 21/23] Add cmpxchg_local to sparc64
On 8/21/07, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > Use cmpxchg_u32 and cmpxchg_u64 for cmpxchg_local and cmpxchg64_local. For > other > type sizes, use the new generic cmpxchg_local (disables interrupt). > > Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > --- > include/asm-sparc64/system.h | 26 ++ > 1 file changed, 26 insertions(+) > > Index: linux-2.6-lttng/include/asm-sparc64/system.h > === > --- linux-2.6-lttng.orig/include/asm-sparc64/system.h 2007-08-07 > 14:31:51.0 -0400 > +++ linux-2.6-lttng/include/asm-sparc64/system.h2007-08-07 > 15:13:05.0 -0400 > @@ -314,6 +314,32 @@ __cmpxchg(volatile void *ptr, unsigned l > (unsigned long)_n_, sizeof(*(ptr))); \ >}) > > +#include Shouldn't #includes go at the start of the file? -- Julian Calaby Email: [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: NFS hang + umount -f: better behaviour requested.
On Tue, Aug 21, 2007 at 09:27:06AM +1000, Neil Brown wrote: > On Monday August 20, [EMAIL PROTECTED] wrote: > > (cc's to me appreciated) > > > > It would be really, really nice if "umount -f" against a hung > > NFS mount actually worked on Linux. As much as I hate Solaris, > > I consider it the gold standard in this case: If I say "umount > > -f /mount/that/is/hung" it just goes away, immediately, and > > anything still trying to use it dies (with EIO, I'm told). > > Have you tried "umount -l"? How far is that from your > requirements? I actually talked about that further down. The short version: quite far. The long version: It leaves a bunch of hung processes, with no real way for me to determine which processes are hung on the now-non-existent mount, and (at least with autofs) it leaves /etc/mtab in an inconsistent state, so I had to edit it to restart autofs. Only a mild improvement on rebooting, says I. Also, it took a really long time (minutes) to return. > Alternately: >mount --move /problem/path /somewhere/else >umount -f /somewhere/else >umount -l /somewhere/else > > might be a little closer to what you want. I don't think that would solve the problem: the umount -f would still hang and eventually return busy, fuser would still hang, and umount -l would still leave inconsistent crap lying around. > Though I agree that it would be nice if we could convince all > subsequent requests to a server to fail EIO instead of just the > currently active ones. I'm not sure that just changing "umount > -f" is the right interface though Maybe if all the server > handles appeared in sysfs and have an attribute which you could > set to cause all requests to fail... I have no opinion on interface details, I simply know that on Solaris, "umount -f" Just Works, and I would love to have similar behaviour on Linux. -Robin -- http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ Reason #237 To Learn Lojban: "Homonyms: Their Grate!" Proud Supporter of the Singularity Institute - http://singinst.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: [PATCH 0/4] Virtual Machine Time Accounting
On Mon, 2007-08-20 at 09:13 -0700, Jeremy Fitzhardinge wrote: > Laurent Vivier wrote: > > functionnalities: > > > > - allow to measure time spent by a CPU in a virtual CPU. > > - allow to display in /proc/state this value by CPU > > - allow to display in /proc//state this value by process > > - allow KVM to use these 3 previous functionnalities > > > > So, currently time spent in a kvm guest is accumulated as qemu-kvm > usertime, right? Given that qemu knows when its running in qemu vs > guest context, couldn't it provide the breakdown between user and guest > time (ditto lguest)? No, unfortunately it's accumulated as system time. 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: NFS hang + umount -f: better behaviour requested.
On Monday August 20, [EMAIL PROTECTED] wrote: > (cc's to me appreciated) > > It would be really, really nice if "umount -f" against a hung NFS > mount actually worked on Linux. As much as I hate Solaris, I > consider it the gold standard in this case: If I say > "umount -f /mount/that/is/hung" it just goes away, immediately, and > anything still trying to use it dies (with EIO, I'm told). Have you tried "umount -l"? How far is that from your requirements? Alternately: mount --move /problem/path /somewhere/else umount -f /somewhere/else umount -l /somewhere/else might be a little closer to what you want. Though I agree that it would be nice if we could convince all subsequent requests to a server to fail EIO instead of just the currently active ones. I'm not sure that just changing "umount -f" is the right interface though Maybe if all the server handles appeared in sysfs and have an attribute which you could set to cause all requests to fail... NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 -mm] IOAT: fix for UP use of cpu_physical_id()
>-Original Message- >From: H. Peter Anvin [mailto:[EMAIL PROTECTED] >Sent: Monday, August 20, 2007 3:27 PM >To: Nelson, Shannon >Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; >[EMAIL PROTECTED]; [EMAIL PROTECTED]; Luck, Tony >Subject: Re: [PATCH -mm] IOAT: fix for UP use of cpu_physical_id() > >Shannon Nelson wrote: >> Make sure we can use cpu_physical_id() even when compiled for >> uni-processor. >> >> diff --git a/drivers/dma/ioat_dca.c b/drivers/dma/ioat_dca.c >> index c3a500b..b1af49c 100644 >> --- a/drivers/dma/ioat_dca.c >> +++ b/drivers/dma/ioat_dca.c >> @@ -25,6 +25,14 @@ >> #include >> #include >> #include >> + >> +// either a kernel change is needed, or we need something >like this in kernel >> +#ifndef CONFIG_SMP >> +#include >> +#undef cpu_physical_id >> +#define cpu_physical_id(cpu) (cpuid_ebx(1) >> 24) >> +#endif >> + > >This value should probably be cached. Executing cpuid to get a static >value seems like a bad idea. Yeah, this whole cpu_physical_id() gizmo needs to be fixed so it is actually usable for non-SMP configurations. Unfortunately, I'm not the guy to do it. sln -- == Mr. Shannon Nelson LAN Access Division, Intel Corp. [EMAIL PROTECTED]I don't speak for Intel (503) 712-7659Parents can't afford to be squeamish. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc3-hrt2: tasklets replaced by workqueues?
I wrote: > I've got a driver bug filed against 2.6.23-rc3-hrt2 with an oops beneath > run_workqueue. It looks a lot like another bug in mainline with a panic > beneath run_timer_softirq. Does -hrt replace tasklets by workqueues? > > http://bugzilla.kernel.org/show_bug.cgi?id=8906 > http://bugzilla.kernel.org/show_bug.cgi?id=8646 Never mind. These are different bugs. -- 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: [RFC 7/7] Switch of PF_MEMALLOC during writeout
On Mon, 21 Aug 2007, Andi Kleen wrote: > Christoph Lameter <[EMAIL PROTECTED]> writes: > > > Switch off PF_MEMALLOC during both direct and kswapd reclaim. > > > > This works because we are not holding any locks at that point because > > reclaim is essentially complete. The write occurs when the memory on > > the zones is at the high water mark so it is unlikely that writeout > > will get into trouble. If so then reclaim can be called recursively to > > reclaim more pages. > > What would stop multiple recursions in extreme low memory cases? Seems > risky to me and risking stack overflow. Perhaps define another flag to catch > that? Right. I am not sure exactly how to handle that. There is also the issue of the writes being deferred. I thought maybe of using pdflush to writeout the pages? Maybe increase priority of the pdflush so that it runs immediately when notified. Shrink_page_list would gather the dirty pages in pvecs and then forward to a pdflush. That may make the whole thing much cleaner. Opinions? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [accounting regression since rc1] scheduler updates
Ingo Molnar writes: > We seem to agree wrt. sched_clock()'s behavior while the virtual CPU is > busy: sched_clock() very much wants to track virtual time. (real time is > pretty much meaningless and coupling sched_clock() to real time would > make the virtual machine's behavior dependent on the host's load, which > breaks the "seemless virtualization to inside observers" common-sense > requirement of virtual-CPU scheduling.) OK, that would imply that virtualized powerpc machines want to use the PURR register for sched_clock(). The PURR basically counts time that this virtual CPU (SMT thread) spends dispatching instructions, so it excludes both the time taken by the hypervisor and the time (dispatch cycles) taken by the other thread. > For sched_clock()'s behavior while the virtual CPU is idle: my current > idea for that is the patch below (a loosely analoguous problem exists > with nohz/dynticks): it makes sched_clock() valid across idle periods > too and uses wall-clock time for that. The straightforward thing is just to use the PURR all the time, even during idle. What that means is this: * If the other thread is active then sched_clock() will continue to advance at a slow rate during idle (reflecting the fact that the active thread is getting almost all of the dispatch cycles). * If the other thread is idle and the partition is a "shared processor" partition then sched_clock() not advance since in that case we idle in the hypervisor. * If the other thread is idle and the partition is a "dedicated processor" partition then sched_clock() will advance at half speed on both threads, since the two threads each get half of the dispatch cycles. It sounds like this behaviour should be OK - do you agree? > If a virtual CPU is idle then i think the "real = steal, virtual = 0" > way of thinking about idle looks a bit unnatural to me - wouldnt it be > better to think in terms of "steal = 0, virtual = real" ? Basically a Stolen time while the virtual CPU is idle gets (or at least, used to get :) accounted as idle time. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [POWERPC] Fix for assembler -g
Roland McGrath writes: > Hmm. Check the V=1 make output to see that the lparmap.c really got the -g0. > The log says it didn't. Oops! It looks like the patch that got committed is > the one that sets CFLAGS_lparmap.s, but really it needs to set > CFLAGS_lparmap.o instead (go kbuild). Did I post the wrong one? (It's only > one letter different.) Sorry about that! (I committed the right one to > Fedora, which you'd think would help Dave, but no.) Stephen Rothwell has posted a patch which makes this all moot by eliminating the #include of the .s file. I'm going to put that in my tree shortly. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
And no, RMW on MMIO isn't "problematic" at all, either. An RMW op is a read op, a modify op, and a write op, all rolled into one opcode. But three actual operations. Maybe for some CPUs, but not all. ARM for instance can't use the load exclusive and store exclusive instructions to MMIO space. Sure, your CPU doesn't have RMW instructions -- how to emulate those if you don't have them is a totally different thing. Segher - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Macbook bug after suspend to disk
I'm using 2.6.22.1 on my macbook (32bits). I had got this trace a few hours after a suspend to disk. I never got this kind of trace without suspend. I will try to reproduce with 2.6.22.3. Here is the trace : Aug 20 14:14:23 cocoduo kernel: kernel BUG at mm/slab.c:2980! Aug 20 14:14:23 cocoduo kernel: invalid opcode: [#1] Aug 20 14:14:23 cocoduo kernel: SMP Aug 20 14:14:23 cocoduo kernel: Modules linked in: wlan_tkip wlan_ccmp usbkbd ath_pci button nfs lockd nfs_acl sunrpc ac battery cpufreq_ondemand cpufreq_powersave i915 drm binfmt_misc hci_usb rfcomm l2cap bluetooth ppdev lp parport ipv6 dm_snapshot dm_mirror dm_mod cpufreq_userspace acpi_cpufreq freq_table firewire_sbp2 loop joydev usbmouse appletouch snd_hda_intel tsdev sky2 rtc_cmos rtc_core intelfb i2c_i801 wlan_scan_sta iTCO_wdt snd_pcm snd_timer snd soundcore rtc_lib i2c_algo_bit ath_rate_sample intel_agp agpgart i2c_core snd_page_alloc wlan ath_hal(P) evdev ext3 jbd mbcache usbhid hid sd_mod ide_cd cdrom ata_piix ata_generic libata scsi_mod piix firewire_ohci firewire_core crc_itu_t ehci_hcd generic ide_core uhci_hcd usbcore thermal processor fan Aug 20 14:14:23 cocoduo kernel: CPU:0 Aug 20 14:14:23 cocoduo kernel: EIP:0060:[]Tainted: P VLI Aug 20 14:14:23 cocoduo kernel: EFLAGS: 00210092 (2.6.22-1-686 #1) Aug 20 14:14:23 cocoduo kernel: EIP is at cache_alloc_refill+0xe9/0x451 Aug 20 14:14:23 cocoduo kernel: eax: 007f ebx: c20bf800 ecx: df9e8d40 edx: Aug 20 14:14:23 cocoduo kernel: esi: db91c000 edi: 0010 ebp: dfff1600 esp: eecdddbc Aug 20 14:14:23 cocoduo kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Aug 20 14:14:23 cocoduo kernel: Process hald (pid: 5167, ti=eecdc000 task=ef3a8a50 task.ti=eecdc000) Aug 20 14:14:23 cocoduo kernel: Stack: 00d0 df9e8d40 df9e0c00 c0152f3b 0044 Aug 20 14:14:23 cocoduo kernel:00d0 c0327ff4 ef3a8a50 00a4 df9e8d40 00200202 c210ac24 Aug 20 14:14:23 cocoduo kernel:c0167553 00a4 0001 00a4 c02017f4 0004 c210ac00 Aug 20 14:14:23 cocoduo kernel: Call Trace: Aug 20 14:14:23 cocoduo kernel: [] __alloc_pages+0x52/0x294 Aug 20 14:14:23 cocoduo kernel: [] kmem_cache_zalloc+0x42/0x79 Aug 20 14:14:23 cocoduo kernel: [] acpi_ps_alloc_op+0x5d/0x9e Aug 20 14:14:23 cocoduo kernel: [] acpi_ps_parse_loop+0x6f6/0x737 Aug 20 14:14:23 cocoduo kernel: [] acpi_ps_parse_aml+0x60/0x237 Aug 20 14:14:23 cocoduo kernel: [] acpi_ds_init_aml_walk+0xb4/0xfe Aug 20 14:14:23 cocoduo kernel: [] acpi_ps_execute_method+0x11b/0x1bb Aug 20 14:14:23 cocoduo kernel: [] acpi_ns_evaluate+0x99/0xf0 Aug 20 14:14:23 cocoduo kernel: [] acpi_evaluate_object+0x139/0x1dc Aug 20 14:14:23 cocoduo kernel: [] acpi_evaluate_integer+0x80/0xb3 Aug 20 14:14:23 cocoduo kernel: [] acpi_ac_get_state+0x26/0x61 [ac] Aug 20 14:14:23 cocoduo kernel: [] vma_link+0x54/0xc9 Aug 20 14:14:23 cocoduo kernel: [] acpi_ac_seq_show+0x12/0x4e [ac] Aug 20 14:14:23 cocoduo kernel: [] seq_read+0xe7/0x274 Aug 20 14:14:23 cocoduo kernel: [] seq_read+0x0/0x274 Aug 20 14:14:23 cocoduo kernel: [] vfs_read+0xa6/0x128 Aug 20 14:14:23 cocoduo kernel: [] sys_read+0x41/0x67 Aug 20 14:14:23 cocoduo kernel: [] sysenter_past_esp+0x6b/0xa1 Aug 20 14:14:23 cocoduo kernel: === Aug 20 14:14:23 cocoduo kernel: Code: 00 00 00 8b 75 00 39 ee 75 15 8b 75 10 8d 45 10 c7 45 34 01 00 00 00 39 c6 0f 84 9c 00 00 00 8b 4c 24 0c 8b 41 38 39 46 10 72 34 <0f> 0b eb fe 8b 44 24 10 8b 5e 14 8b 08 8b 44 24 0c 8b 50 2c 8b Aug 20 14:14:23 cocoduo kernel: EIP: [] cache_alloc_refill+0xe9/0x451 SS:ESP 0068:eecdddbc -- Lionel Landwerlin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 14/14] Convert from class_device to device for ISDN capi
--
Content-Disposition: inline; filename=isdn-capi.patch
Convert from class_device to device for drivers/isdn/capi. This is
part of the work to eliminate struct class_device.
---
drivers/isdn/capi/capi.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/isdn/capi/capi.c
+++ b/drivers/isdn/capi/capi.c
@@ -1544,11 +1544,11 @@ static int __init capi_init(void)
return PTR_ERR(capi_class);
}
- class_device_create(capi_class, NULL, MKDEV(capi_major, 0), NULL,
"capi");
+ device_create(capi_class, NULL, MKDEV(capi_major, 0), "capi");
#ifdef CONFIG_ISDN_CAPI_MIDDLEWARE
if (capinc_tty_init() < 0) {
- class_device_destroy(capi_class, MKDEV(capi_major, 0));
+ device_destroy(capi_class, MKDEV(capi_major, 0));
class_destroy(capi_class);
unregister_chrdev(capi_major, "capi20");
return -ENOMEM;
@@ -1576,7 +1576,7 @@ static void __exit capi_exit(void)
{
proc_exit();
- class_device_destroy(capi_class, MKDEV(capi_major, 0));
+ device_destroy(capi_class, MKDEV(capi_major, 0));
class_destroy(capi_class);
unregister_chrdev(capi_major, "capi20");
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
NFS hang + umount -f: better behaviour requested.
(cc's to me appreciated)
It would be really, really nice if "umount -f" against a hung NFS
mount actually worked on Linux. As much as I hate Solaris, I
consider it the gold standard in this case: If I say
"umount -f /mount/that/is/hung" it just goes away, immediately, and
anything still trying to use it dies (with EIO, I'm told).
If I know the NFS server is down, that really is the correct
behaviour. I very much want this behaviour, and am willing to
bribe/pay for it, although my resources are limited.
Unless you're interested in details of my tests, stop here.
I'm bringing this up again (I know it's been mentioned here before)
because I had been told that NFS support had gotten better in Linux
recently, so I have been (for my $dayjob) testing the behaviour of
NFS (autofs NFS, specifically) under Linux with hard,intr and using
iptables to simulate a hang. fuser hangs, as far as I can tell
indefinately, as does lsof. umount -f returns after a long time with
"busy", umount -l works after a long time but leaves the system in a
very unfortunate state such that I have to kill things by hand and
manually edit /etc/mtab to get autofs to work again.
The "correct solution" to this situation according to
http://nfs.sourceforge.net/ is cycles of "kill processes" and
"umount -f". This has two problems: 1. It sucks. 2. If fuser
and lsof both hand (and they do: fuser has been on
"stat("/home/rpowell/"," for > 30 minutes now), I have no way to
pick which processes to kill.
I've read every man page I could find, and the only nfs option that
semes even vaguely helpful is "soft", but everything that mentions
"soft" also says to never use it.
This is the single worst aspect of adminning a Linux system that I,
as a carreer sysadmin, have to deal with. In fact, it's really the
only one I even dislike. At my current work place, we've lost
multiple person-days to this issue, having to go around and reboot
every Linux box that was hanging off a down NFS server.
I know many other admins who also really want Solaris style
"umount -f"; I'm sure if I passed the hat I could get a decent
bounty together for this feature; let me know if you're interested.
Thanks.
-Robin
--
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
Reason #237 To Learn Lojban: "Homonyms: Their Grate!"
Proud Supporter of the Singularity Institute - http://singinst.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: SLUB bug on sparc64
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Mon, 20 Aug 2007 11:34:52 -0700 (PDT) > On Fri, 17 Aug 2007, David Miller wrote: > > > When I force SLUB debugging on sparc64, it barfs on early bootup while > > making the sysfs nodes. Removing the BUG()'s on the sysfs error > > returns, and adding some tracing I captured the log below. > > > > BTW, I would recommending removing the BUG() calls, they serve only to > > force someone hitting them to edit them out and reboot which is > > absolutely pointless :-) This code can also often run before the > > console is first enabled, making analysis of the error return that > > much harder if it BUG()'s instead of trying to continue. > > Not sure what BUG's you are talking about. The two BUG_ON()'s on "err" as returned from sysfs_slab_alias() and sysfs_slab_add(). > Does this patch fix it? Yep, it does, thanks a lot! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 12/14] Convert from class_device to device for TI flash media
--
Content-Disposition: inline; filename=misc.patch
Convert from class_device to device for drivers/misc/tifm. This is
part of the work to eliminate struct class_device.
---
drivers/misc/tifm_7xx1.c |4 ++--
drivers/misc/tifm_core.c | 24
include/linux/tifm.h |2 +-
3 files changed, 15 insertions(+), 15 deletions(-)
--- a/drivers/misc/tifm_core.c
+++ b/drivers/misc/tifm_core.c
@@ -165,16 +165,16 @@ static struct bus_type tifm_bus_type = {
.resume= tifm_device_resume
};
-static void tifm_free(struct class_device *cdev)
+static void tifm_free(struct device *dev)
{
- struct tifm_adapter *fm = container_of(cdev, struct tifm_adapter, cdev);
+ struct tifm_adapter *fm = container_of(dev, struct tifm_adapter, dev);
kfree(fm);
}
static struct class tifm_adapter_class = {
.name= "tifm_adapter",
- .release = tifm_free
+ .dev_release = tifm_free
};
struct tifm_adapter *tifm_alloc_adapter(unsigned int num_sockets,
@@ -185,9 +185,9 @@ struct tifm_adapter *tifm_alloc_adapter(
fm = kzalloc(sizeof(struct tifm_adapter)
+ sizeof(struct tifm_dev*) * num_sockets, GFP_KERNEL);
if (fm) {
- fm->cdev.class = &tifm_adapter_class;
- fm->cdev.dev = dev;
- class_device_initialize(&fm->cdev);
+ fm->dev.class = &tifm_adapter_class;
+ fm->dev.parent = dev;
+ device_initialize(&fm->dev);
spin_lock_init(&fm->lock);
fm->num_sockets = num_sockets;
}
@@ -208,8 +208,8 @@ int tifm_add_adapter(struct tifm_adapter
if (rc)
return rc;
- snprintf(fm->cdev.class_id, BUS_ID_SIZE, "tifm%u", fm->id);
- rc = class_device_add(&fm->cdev);
+ snprintf(fm->dev.bus_id, BUS_ID_SIZE, "tifm%u", fm->id);
+ rc = device_add(&fm->dev);
if (rc) {
spin_lock(&tifm_adapter_lock);
idr_remove(&tifm_adapter_idr, fm->id);
@@ -233,13 +233,13 @@ void tifm_remove_adapter(struct tifm_ada
spin_lock(&tifm_adapter_lock);
idr_remove(&tifm_adapter_idr, fm->id);
spin_unlock(&tifm_adapter_lock);
- class_device_del(&fm->cdev);
+ device_del(&fm->dev);
}
EXPORT_SYMBOL(tifm_remove_adapter);
void tifm_free_adapter(struct tifm_adapter *fm)
{
- class_device_put(&fm->cdev);
+ put_device(&fm->dev);
}
EXPORT_SYMBOL(tifm_free_adapter);
@@ -266,9 +266,9 @@ struct tifm_dev *tifm_alloc_device(struc
sock->card_event = tifm_dummy_event;
sock->data_event = tifm_dummy_event;
- sock->dev.parent = fm->cdev.dev;
+ sock->dev.parent = fm->dev.parent;
sock->dev.bus = &tifm_bus_type;
- sock->dev.dma_mask = fm->cdev.dev->dma_mask;
+ sock->dev.dma_mask = fm->dev.parent->dma_mask;
sock->dev.release = tifm_free_device;
snprintf(sock->dev.bus_id, BUS_ID_SIZE,
--- a/include/linux/tifm.h
+++ b/include/linux/tifm.h
@@ -120,7 +120,7 @@ struct tifm_adapter {
struct completion *finish_me;
struct work_struct media_switcher;
- struct class_device cdev;
+ struct device dev;
void(*eject)(struct tifm_adapter *fm,
struct tifm_dev *sock);
--- a/drivers/misc/tifm_7xx1.c
+++ b/drivers/misc/tifm_7xx1.c
@@ -149,7 +149,7 @@ static void tifm_7xx1_switch_media(struc
socket_change_set = fm->socket_change_set;
fm->socket_change_set = 0;
- dev_dbg(fm->cdev.dev, "checking media set %x\n",
+ dev_dbg(fm->dev.parent, "checking media set %x\n",
socket_change_set);
if (!socket_change_set) {
@@ -164,7 +164,7 @@ static void tifm_7xx1_switch_media(struc
if (sock) {
printk(KERN_INFO
"%s : demand removing card from socket %u:%u\n",
- fm->cdev.class_id, fm->id, cnt);
+ fm->dev.bus_id, fm->id, cnt);
fm->sockets[cnt] = NULL;
sock_addr = sock->addr;
spin_unlock_irqrestore(&fm->lock, flags);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 13/14] Convert from class_device to device for UCB1x00
--
Content-Disposition: inline; filename=mfd.patch
Convert from class_device to device for drivers/mfd/ucb1x00. This is
part of the work to eliminate struct class_device.
---
drivers/mfd/ucb1x00-assabet.c | 17 +
drivers/mfd/ucb1x00-core.c| 14 +++---
drivers/mfd/ucb1x00.h |4 ++--
3 files changed, 18 insertions(+), 17 deletions(-)
--- a/drivers/mfd/ucb1x00-assabet.c
+++ b/drivers/mfd/ucb1x00-assabet.c
@@ -20,7 +20,8 @@
#include "ucb1x00.h"
#define UCB1X00_ATTR(name,input)\
-static ssize_t name##_show(struct class_device *dev, char *buf)\
+static ssize_t name##_show(struct device *dev, struct device_attribute *attr,
+ char *buf) \
{ \
struct ucb1x00 *ucb = classdev_to_ucb1x00(dev); \
int val;\
@@ -29,7 +30,7 @@ static ssize_t name##_show(struct class_
ucb1x00_adc_disable(ucb); \
return sprintf(buf, "%d\n", val); \
} \
-static CLASS_DEVICE_ATTR(name,0444,name##_show,NULL)
+static DEVICE_ATTR(name,0444,name##_show,NULL)
UCB1X00_ATTR(vbatt, UCB_ADC_INP_AD1);
UCB1X00_ATTR(vcharger, UCB_ADC_INP_AD0);
@@ -37,17 +38,17 @@ UCB1X00_ATTR(batt_temp, UCB_ADC_INP_AD2)
static int ucb1x00_assabet_add(struct ucb1x00_dev *dev)
{
- class_device_create_file(&dev->ucb->cdev, &class_device_attr_vbatt);
- class_device_create_file(&dev->ucb->cdev, &class_device_attr_vcharger);
- class_device_create_file(&dev->ucb->cdev, &class_device_attr_batt_temp);
+ device_create_file(&dev->ucb->dev, &device_attr_vbatt);
+ device_create_file(&dev->ucb->dev, &device_attr_vcharger);
+ device_create_file(&dev->ucb->dev, &device_attr_batt_temp);
return 0;
}
static void ucb1x00_assabet_remove(struct ucb1x00_dev *dev)
{
- class_device_remove_file(&dev->ucb->cdev, &class_device_attr_batt_temp);
- class_device_remove_file(&dev->ucb->cdev, &class_device_attr_vcharger);
- class_device_remove_file(&dev->ucb->cdev, &class_device_attr_vbatt);
+ device_remove_file(&dev->ucb->cdev, &device_attr_batt_temp);
+ device_remove_file(&dev->ucb->cdev, &device_attr_vcharger);
+ device_remove_file(&dev->ucb->cdev, &device_attr_vbatt);
}
static struct ucb1x00_driver ucb1x00_assabet_driver = {
--- a/drivers/mfd/ucb1x00-core.c
+++ b/drivers/mfd/ucb1x00-core.c
@@ -458,7 +458,7 @@ static int ucb1x00_detect_irq(struct ucb
return probe_irq_off(mask);
}
-static void ucb1x00_release(struct class_device *dev)
+static void ucb1x00_release(struct device *dev)
{
struct ucb1x00 *ucb = classdev_to_ucb1x00(dev);
kfree(ucb);
@@ -466,7 +466,7 @@ static void ucb1x00_release(struct class
static struct class ucb1x00_class = {
.name = "ucb1x00",
- .release= ucb1x00_release,
+ .dev_release= ucb1x00_release,
};
static int ucb1x00_probe(struct mcp *mcp)
@@ -490,9 +490,9 @@ static int ucb1x00_probe(struct mcp *mcp
goto err_disable;
- ucb->cdev.class = &ucb1x00_class;
- ucb->cdev.dev = &mcp->attached_device;
- strlcpy(ucb->cdev.class_id, "ucb1x00", sizeof(ucb->cdev.class_id));
+ ucb->dev.class = &ucb1x00_class;
+ ucb->dev.parent = &mcp->attached_device;
+ strlcpy(ucb->dev.bus_id, "ucb1x00", sizeof(ucb->dev.bus_id));
spin_lock_init(&ucb->lock);
spin_lock_init(&ucb->io_lock);
@@ -517,7 +517,7 @@ static int ucb1x00_probe(struct mcp *mcp
mcp_set_drvdata(mcp, ucb);
- ret = class_device_register(&ucb->cdev);
+ ret = device_register(&ucb->dev);
if (ret)
goto err_irq;
@@ -554,7 +554,7 @@ static void ucb1x00_remove(struct mcp *m
mutex_unlock(&ucb1x00_mutex);
free_irq(ucb->irq, ucb);
- class_device_unregister(&ucb->cdev);
+ device_unregister(&ucb->dev);
}
int ucb1x00_register_driver(struct ucb1x00_driver *drv)
--- a/drivers/mfd/ucb1x00.h
+++ b/drivers/mfd/ucb1x00.h
@@ -120,7 +120,7 @@ struct ucb1x00 {
u16 irq_fal_enbl;
u16 irq_ris_enbl;
struct ucb1x00_irq irq_handler[16];
- struct class_device cdev;
+ struct device dev;
struct list_headnode;
struct list_headdevs;
};
@@ -144,7 +144,7 @@ struct ucb1x00_driver {
int (*resume)(struct ucb1x00_dev *dev);
};
-#define classdev_to_ucb1x00(cd)container_of(cd, struct ucb1x00, cdev)
+#define classdev_to_ucb1x00(cd)container_of(cd, struct ucb1x00, dev)
int ucb1x00_register_driver(struct ucb1x00_driver *);
void ucb1x00_unregister_driver(struct ucb1x00_driver *);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
[patch 10/14] Convert from class_device to device for USB core
--
Content-Disposition: inline; filename=usb-core.patch
Convert from class_device to device for drivers/ide/usb/core. Greg, not
sure if you're looking for a patch for this. Kay mentioned maybe it was to
be superceded by a diff mechanism. Free free to drop if so.
---
drivers/usb/core/hcd.c | 12 ++--
include/linux/usb.h|2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -739,15 +739,15 @@ static int usb_register_bus(struct usb_b
return -E2BIG;
}
- bus->class_dev = class_device_create(usb_host_class, NULL, MKDEV(0,0),
-bus->controller, "usb_host%d",
busnum);
- if (IS_ERR(bus->class_dev)) {
+ bus->dev = device_create(usb_host_class, bus->controller, MKDEV(0,0),
+"usb_host%d", busnum);
+ if (IS_ERR(bus->dev)) {
clear_bit(busnum, busmap.busmap);
mutex_unlock(&usb_bus_list_lock);
- return PTR_ERR(bus->class_dev);
+ return PTR_ERR(bus->dev);
}
- class_set_devdata(bus->class_dev, bus);
+ dev_set_drvdata(bus->dev, bus);
/* Add it to the local list of buses */
list_add (&bus->bus_list, &usb_bus_list);
@@ -784,7 +784,7 @@ static void usb_deregister_bus (struct u
clear_bit (bus->busnum, busmap.busmap);
- class_device_unregister(bus->class_dev);
+ device_unregister(bus->dev);
}
/**
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -314,7 +314,7 @@ struct usb_bus {
#ifdef CONFIG_USB_DEVICEFS
struct dentry *usbfs_dentry;/* usbfs dentry entry for the bus */
#endif
- struct class_device *class_dev; /* class device for this bus */
+ struct device *dev; /* device for this bus */
#if defined(CONFIG_USB_MON)
struct mon_bus *mon_bus;/* non-null when associated */
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
