Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! > > > User has triggered resume > > > run wakeup.S > > wakeup.S runs in real mode. Why can't it just call the VBIOS at > C000:0003 to reset the hardware before setting the mode? We already try to do that, but it hangs on 70% of machines. See Documentation/power/video.txt. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! > Reseting a video card from suspend is essentially the same problem as > reseting secondary video cards on boot. The same code can address both > problems. Well, it is made more tricky by the fact that you are running during resume -- hard to debug. Ideally you want to have video so you can debug resume of ethernet, disk, etc... But you don't have video :-(. But I agree, same code should be used. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote: > > Vojtech Pavlik <[EMAIL PROTECTED]> writes: > > > > > On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote: > > > > > > > * Removes the xres/yres scaling so that you get the same speed in the > > > > X and Y directions even if your screen is not square. > > > > > > The old code assumed that both the pad and the screen are 4:3, not > > > square. It was wrong still. > > > alps.c currently contains: > > > > psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); > > input_set_abs_params(>dev, ABS_X, 0, 1023, 0, 0); > > input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0); > > input_set_abs_params(>dev, ABS_PRESSURE, 0, 127, 0, 0); > > > > Maybe it should set the ABS_Y max value to 767 in that case. > > Yes, and no. It could have been 1023, if it was 3:4 in size, but not in > maximum values. See the real values below, though, it seems the > resolution in X and Y is indeed the same. ... > My ALPS gives values: > > X: 90-1019 > Y: 100-749 > Pressure: 0,34-108 I get similar values: X: 40 - 984 Y: 97 - 732 Z: 0, 19 - 127 > So 0-1024, 0-768, 0-127 are probably the maximum theoretical ranges, and > the rest are likely the mechanical mounting limitations of the notebook > (the ridge around the pad is not rectangular). -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] PPC/PPC64: Introduce CPU_HAS_FEATURE() macro
Hi,
It's getting pretty old to have see and type cur_cpu_spec->cpu_features
& CPU_FTR_, when a shorter and less TLA-ridden macro is more
readable.
This also takes care of the differences between PPC and PPC64 cpu
features for the common code; most places in PPC could be replaced with
the macro as well.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
linux-2.5-olof/arch/ppc/kernel/ppc_htab.c|8 +++---
linux-2.5-olof/arch/ppc/kernel/setup.c |4 +--
linux-2.5-olof/arch/ppc/kernel/temp.c|2 -
linux-2.5-olof/arch/ppc/mm/mmu_decl.h|2 -
linux-2.5-olof/arch/ppc/mm/ppc_mmu.c |4 +--
linux-2.5-olof/arch/ppc/platforms/pmac_cpufreq.c |2 -
linux-2.5-olof/arch/ppc/platforms/pmac_setup.c |2 -
linux-2.5-olof/arch/ppc/platforms/pmac_smp.c |4 +--
linux-2.5-olof/arch/ppc/platforms/sandpoint.c|6 ++---
linux-2.5-olof/arch/ppc64/kernel/align.c |2 -
linux-2.5-olof/arch/ppc64/kernel/iSeries_setup.c |2 -
linux-2.5-olof/arch/ppc64/kernel/pSeries_lpar.c |2 -
linux-2.5-olof/arch/ppc64/kernel/process.c |4 +--
linux-2.5-olof/arch/ppc64/kernel/setup.c |6 ++---
linux-2.5-olof/arch/ppc64/kernel/smp.c |2 -
linux-2.5-olof/arch/ppc64/kernel/sysfs.c | 22 +--
linux-2.5-olof/arch/ppc64/mm/hash_native.c | 14 ++--
linux-2.5-olof/arch/ppc64/mm/hash_utils.c|2 -
linux-2.5-olof/arch/ppc64/mm/hugetlbpage.c |2 -
linux-2.5-olof/arch/ppc64/mm/init.c | 10
linux-2.5-olof/arch/ppc64/mm/slb.c |4 +--
linux-2.5-olof/arch/ppc64/mm/stab.c |2 -
linux-2.5-olof/arch/ppc64/oprofile/op_model_power4.c |2 -
linux-2.5-olof/arch/ppc64/oprofile/op_model_rs64.c |2 -
linux-2.5-olof/arch/ppc64/xmon/xmon.c|8 +++---
linux-2.5-olof/drivers/macintosh/via-pmu.c |2 -
linux-2.5-olof/drivers/md/raid6altivec.uc|2 -
linux-2.5-olof/include/asm-ppc/cputable.h|2 +
linux-2.5-olof/include/asm-ppc64/cacheflush.h|2 -
linux-2.5-olof/include/asm-ppc64/cputable.h |2 +
linux-2.5-olof/include/asm-ppc64/mmu_context.h |4 +--
linux-2.5-olof/include/asm-ppc64/page.h |2 -
32 files changed, 70 insertions(+), 66 deletions(-)
diff -puN include/asm-ppc64/cputable.h~cpu-has-feature
include/asm-ppc64/cputable.h
--- linux-2.5/include/asm-ppc64/cputable.h~cpu-has-feature 2005-02-04
00:33:25.0 -0600
+++ linux-2.5-olof/include/asm-ppc64/cputable.h 2005-02-04 00:33:26.0
-0600
@@ -66,6 +66,8 @@ struct cpu_spec {
extern struct cpu_spec cpu_specs[];
extern struct cpu_spec *cur_cpu_spec;
+#define CPU_HAS_FEATURE(x) (cur_cpu_spec->cpu_features & CPU_FTR_##x)
+
/* firmware feature bitmask values */
#define FIRMWARE_MAX_FEATURES 63
diff -puN arch/ppc64/kernel/align.c~cpu-has-feature arch/ppc64/kernel/align.c
--- linux-2.5/arch/ppc64/kernel/align.c~cpu-has-feature 2005-02-04
00:33:25.0 -0600
+++ linux-2.5-olof/arch/ppc64/kernel/align.c2005-02-04 00:33:26.0
-0600
@@ -238,7 +238,7 @@ fix_alignment(struct pt_regs *regs)
dsisr = regs->dsisr;
- if (cur_cpu_spec->cpu_features & CPU_FTR_NODSISRALIGN) {
+ if (CPU_HAS_FEATURE(NODSISRALIGN)) {
unsigned int real_instr;
if (__get_user(real_instr, (unsigned int __user *)regs->nip))
return 0;
diff -puN arch/ppc64/kernel/iSeries_setup.c~cpu-has-feature
arch/ppc64/kernel/iSeries_setup.c
--- linux-2.5/arch/ppc64/kernel/iSeries_setup.c~cpu-has-feature 2005-02-04
00:33:25.0 -0600
+++ linux-2.5-olof/arch/ppc64/kernel/iSeries_setup.c2005-02-04
00:33:26.0 -0600
@@ -267,7 +267,7 @@ unsigned long iSeries_process_mainstore_
unsigned long i;
unsigned long mem_blocks = 0;
- if (cur_cpu_spec->cpu_features & CPU_FTR_SLB)
+ if (CPU_HAS_FEATURE(SLB))
mem_blocks = iSeries_process_Regatta_mainstore_vpd(mb_array,
max_entries);
else
diff -puN arch/ppc64/kernel/idle.c~cpu-has-feature arch/ppc64/kernel/idle.c
diff -puN arch/ppc64/kernel/process.c~cpu-has-feature
arch/ppc64/kernel/process.c
--- linux-2.5/arch/ppc64/kernel/process.c~cpu-has-feature 2005-02-04
00:33:26.0 -0600
+++ linux-2.5-olof/arch/ppc64/kernel/process.c 2005-02-04 00:33:26.0
-0600
@@ -388,12 +388,12 @@ copy_thread(int nr, unsigned long clone_
kregs = (struct pt_regs *) sp;
sp -= STACK_FRAME_OVERHEAD;
p->thread.ksp = sp;
- if (cur_cpu_spec->cpu_features & CPU_FTR_SLB) {
+ if (CPU_HAS_FEATURE(SLB)) {
unsigned long sp_vsid = get_kernel_vsid(sp);
sp_vsid <<= SLB_VSID_SHIFT;
Re: [PATCH 2.6.11-rc2 12/14] ide_pci: Merges piix.h into piix.c
12_ide_pci_piix_merge.patch
Merges ide/pci/piix.h into piix.c.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-idepci-export/drivers/ide/pci/piix.c
===
--- linux-idepci-export.orig/drivers/ide/pci/piix.c 2005-02-04
16:07:36.404440170 +0900
+++ linux-idepci-export/drivers/ide/pci/piix.c 2005-02-04 16:08:26.627260629
+0900
@@ -103,8 +103,6 @@
#include
-#include "piix.h"
-
static int no_piix_dma;
/**
@@ -530,6 +528,56 @@ static void __devinit init_hwif_piix(ide
hwif->drives[0].autodma = hwif->autodma;
}
+/*
+ * Table of the various PIIX capability blocks
+ */
+
+#define DECLARE_PIIX_DEV(name_str) \
+ { \
+ .name = name_str, \
+ .init_chipset = init_chipset_piix,\
+ .init_hwif = init_hwif_piix, \
+ .channels = 2,\
+ .autodma= AUTODMA, \
+ .enablebits = {{0x41,0x80,0x80}, {0x43,0x80,0x80}}, \
+ .bootable = ON_BOARD, \
+ }
+
+static ide_pci_device_t piix_pci_info[] __devinitdata = {
+ /* 0 */ DECLARE_PIIX_DEV("PIIXa"),
+ /* 1 */ DECLARE_PIIX_DEV("PIIXb"),
+
+ { /* 2 */
+ .name = "MPIIX",
+ .init_hwif = init_hwif_piix,
+ .channels = 2,
+ .autodma= NODMA,
+ .enablebits = {{0x6D,0x80,0x80}, {0x6F,0x80,0x80}},
+ .bootable = ON_BOARD,
+ },
+
+ /* 3 */ DECLARE_PIIX_DEV("PIIX3"),
+ /* 4 */ DECLARE_PIIX_DEV("PIIX4"),
+ /* 5 */ DECLARE_PIIX_DEV("ICH0"),
+ /* 6 */ DECLARE_PIIX_DEV("PIIX4"),
+ /* 7 */ DECLARE_PIIX_DEV("ICH"),
+ /* 8 */ DECLARE_PIIX_DEV("PIIX4"),
+ /* 9 */ DECLARE_PIIX_DEV("PIIX4"),
+ /* 10 */ DECLARE_PIIX_DEV("ICH2"),
+ /* 11 */ DECLARE_PIIX_DEV("ICH2M"),
+ /* 12 */ DECLARE_PIIX_DEV("ICH3M"),
+ /* 13 */ DECLARE_PIIX_DEV("ICH3"),
+ /* 14 */ DECLARE_PIIX_DEV("ICH4"),
+ /* 15 */ DECLARE_PIIX_DEV("ICH5"),
+ /* 16 */ DECLARE_PIIX_DEV("C-ICH"),
+ /* 17 */ DECLARE_PIIX_DEV("ICH4"),
+ /* 18 */ DECLARE_PIIX_DEV("ICH5-SATA"),
+ /* 19 */ DECLARE_PIIX_DEV("ICH5"),
+ /* 20 */ DECLARE_PIIX_DEV("ICH6"),
+ /* 21 */ DECLARE_PIIX_DEV("ICH7"),
+ /* 22 */ DECLARE_PIIX_DEV("ICH4"),
+};
+
/**
* piix_init_one - called when a PIIX is found
* @dev: the piix device
Index: linux-idepci-export/drivers/ide/pci/piix.h
===
--- linux-idepci-export.orig/drivers/ide/pci/piix.h 2005-02-04
16:07:36.404440170 +0900
+++ /dev/null 1970-01-01 00:00:00.0 +
@@ -1,62 +0,0 @@
-#ifndef PIIX_H
-#define PIIX_H
-
-#include
-#include
-#include
-
-static unsigned int __devinit init_chipset_piix(struct pci_dev *, const char
*);
-static void init_hwif_piix(ide_hwif_t *);
-
-#define DECLARE_PIIX_DEV(name_str) \
- { \
- .name = name_str, \
- .init_chipset = init_chipset_piix,\
- .init_hwif = init_hwif_piix, \
- .channels = 2,\
- .autodma= AUTODMA, \
- .enablebits = {{0x41,0x80,0x80}, {0x43,0x80,0x80}}, \
- .bootable = ON_BOARD, \
- }
-
-/*
- * Table of the various PIIX capability blocks
- *
- */
-
-static ide_pci_device_t piix_pci_info[] __devinitdata = {
- /* 0 */ DECLARE_PIIX_DEV("PIIXa"),
- /* 1 */ DECLARE_PIIX_DEV("PIIXb"),
-
- { /* 2 */
- .name = "MPIIX",
- .init_hwif = init_hwif_piix,
- .channels = 2,
- .autodma= NODMA,
- .enablebits = {{0x6D,0x80,0x80}, {0x6F,0x80,0x80}},
- .bootable = ON_BOARD,
- },
-
- /* 3 */ DECLARE_PIIX_DEV("PIIX3"),
- /* 4 */ DECLARE_PIIX_DEV("PIIX4"),
- /* 5 */ DECLARE_PIIX_DEV("ICH0"),
- /* 6 */ DECLARE_PIIX_DEV("PIIX4"),
- /* 7 */ DECLARE_PIIX_DEV("ICH"),
- /* 8 */ DECLARE_PIIX_DEV("PIIX4"),
- /* 9 */ DECLARE_PIIX_DEV("PIIX4"),
- /* 10 */ DECLARE_PIIX_DEV("ICH2"),
- /* 11 */ DECLARE_PIIX_DEV("ICH2M"),
- /* 12 */ DECLARE_PIIX_DEV("ICH3M"),
- /* 13 */ DECLARE_PIIX_DEV("ICH3"),
- /* 14 */ DECLARE_PIIX_DEV("ICH4"),
- /* 15 */ DECLARE_PIIX_DEV("ICH5"),
- /* 16 */ DECLARE_PIIX_DEV("C-ICH"),
- /* 17 */ DECLARE_PIIX_DEV("ICH4"),
- /* 18 */ DECLARE_PIIX_DEV("ICH5-SATA"),
- /* 19 */ DECLARE_PIIX_DEV("ICH5"),
- /* 20 */ DECLARE_PIIX_DEV("ICH6"),
-
Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Fri, 04 Feb 2005 13:51:55 +1100, Nigel Cunningham <[EMAIL PROTECTED]> wrote: > > User has triggered resume > > run wakeup.S wakeup.S runs in real mode. Why can't it just call the VBIOS at C000:0003 to reset the hardware before setting the mode? -- Jon Smirl [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 2.6.11-rc2 09/14] ide_pci: Merges pdc202xx_new.h into pdc202xx_new.c
09_ide_pci_pdc202xx_new_merge.patch
Merges ide/pci/pdc202xx_new.h into pdc202xx_new.c.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-idepci-export/drivers/ide/pci/pdc202xx_new.c
===
--- linux-idepci-export.orig/drivers/ide/pci/pdc202xx_new.c 2005-02-04
16:07:36.612406299 +0900
+++ linux-idepci-export/drivers/ide/pci/pdc202xx_new.c 2005-02-04
16:08:25.989364519 +0900
@@ -37,10 +37,46 @@
#include
#endif
-#include "pdc202xx_new.h"
-
#define PDC202_DEBUG_CABLE 0
+const static char *pdc_quirk_drives[] = {
+ "QUANTUM FIREBALLlct08 08",
+ "QUANTUM FIREBALLP KA6.4",
+ "QUANTUM FIREBALLP KA9.1",
+ "QUANTUM FIREBALLP LM20.4",
+ "QUANTUM FIREBALLP KX13.6",
+ "QUANTUM FIREBALLP KX20.5",
+ "QUANTUM FIREBALLP KX27.3",
+ "QUANTUM FIREBALLP LM20.5",
+ NULL
+};
+
+#define set_2regs(a, b)\
+ do {\
+ hwif->OUTB((a + adj), indexreg);\
+ hwif->OUTB(b, datareg); \
+ } while(0)
+
+#define set_ultra(a, b, c) \
+ do {\
+ set_2regs(0x10,(a));\
+ set_2regs(0x11,(b));\
+ set_2regs(0x12,(c));\
+ } while(0)
+
+#define set_ata2(a, b) \
+ do {\
+ set_2regs(0x0e,(a));\
+ set_2regs(0x0f,(b));\
+ } while(0)
+
+#define set_pio(a, b, c) \
+ do {\
+ set_2regs(0x0c,(a));\
+ set_2regs(0x0d,(b));\
+ set_2regs(0x13,(c));\
+ } while(0)
+
static u8 pdcnew_ratemask (ide_drive_t *drive)
{
u8 mode;
@@ -360,6 +396,72 @@ static int __devinit init_setup_pdc20276
return ide_setup_pci_device(dev, d);
}
+static ide_pci_device_t pdcnew_chipsets[] __devinitdata = {
+ { /* 0 */
+ .name = "PDC20268",
+ .init_setup = init_setup_pdcnew,
+ .init_chipset = init_chipset_pdcnew,
+ .init_hwif = init_hwif_pdc202new,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = OFF_BOARD,
+ },{ /* 1 */
+ .name = "PDC20269",
+ .init_setup = init_setup_pdcnew,
+ .init_chipset = init_chipset_pdcnew,
+ .init_hwif = init_hwif_pdc202new,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = OFF_BOARD,
+ },{ /* 2 */
+ .name = "PDC20270",
+ .init_setup = init_setup_pdc20270,
+ .init_chipset = init_chipset_pdcnew,
+ .init_hwif = init_hwif_pdc202new,
+ .channels = 2,
+ .autodma= AUTODMA,
+#ifndef CONFIG_PDC202XX_FORCE
+ .enablebits = {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
+#endif
+ .bootable = OFF_BOARD,
+ },{ /* 3 */
+ .name = "PDC20271",
+ .init_setup = init_setup_pdcnew,
+ .init_chipset = init_chipset_pdcnew,
+ .init_hwif = init_hwif_pdc202new,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = OFF_BOARD,
+ },{ /* 4 */
+ .name = "PDC20275",
+ .init_setup = init_setup_pdcnew,
+ .init_chipset = init_chipset_pdcnew,
+ .init_hwif = init_hwif_pdc202new,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = OFF_BOARD,
+ },{ /* 5 */
+ .name = "PDC20276",
+ .init_setup = init_setup_pdc20276,
+ .init_chipset = init_chipset_pdcnew,
+ .init_hwif = init_hwif_pdc202new,
+ .channels = 2,
+ .autodma= AUTODMA,
+#ifndef CONFIG_PDC202XX_FORCE
+ .enablebits = {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
+#endif
+ .bootable = OFF_BOARD,
+ },{ /* 6 */
+ .name = "PDC20277",
+ .init_setup = init_setup_pdcnew,
+ .init_chipset = init_chipset_pdcnew,
+ .init_hwif = init_hwif_pdc202new,
+ .channels = 2,
+ .autodma= AUTODMA,
+
Re: [PATCH 2.6.11-rc2 14/14] ide_pci: Merges serverworks.h into serverworks.c
14_ide_pci_serverworks_merge.patch
Merges ide/pci/serverworks.h into serverworks.c.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-idepci-export/drivers/ide/pci/serverworks.c
===
--- linux-idepci-export.orig/drivers/ide/pci/serverworks.c 2005-02-04
16:07:36.271461827 +0900
+++ linux-idepci-export/drivers/ide/pci/serverworks.c 2005-02-04
16:08:27.019196797 +0900
@@ -39,7 +39,20 @@
#include
-#include "serverworks.h"
+#undef SVWKS_DEBUG_DRIVE_INFO
+
+#define SVWKS_CSB5_REVISION_NEW0x92 /* min PCI_REVISION_ID for UDMA5
(A2.0) */
+#define SVWKS_CSB6_REVISION0xa0 /* min PCI_REVISION_ID for UDMA4 (A1.0) */
+
+/* Seagate Barracuda ATA IV Family drives in UDMA mode 5
+ * can overrun their FIFOs when used with the CSB5 */
+static const char *svwks_bad_ata100[] = {
+ "ST320011A",
+ "ST340016A",
+ "ST360021A",
+ "ST380021A",
+ NULL
+};
static u8 svwks_revision = 0;
static struct pci_dev *isa_dev;
@@ -582,6 +595,48 @@ static int __init init_setup_csb6 (struc
return ide_setup_pci_device(dev, d);
}
+/*
+ * Table of the various serverworks capability blocks
+ */
+
+static ide_pci_device_t serverworks_chipsets[] __devinitdata = {
+ { /* 0 */
+ .name = "SvrWks OSB4",
+ .init_setup = init_setup_svwks,
+ .init_chipset = init_chipset_svwks,
+ .init_hwif = init_hwif_svwks,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 1 */
+ .name = "SvrWks CSB5",
+ .init_setup = init_setup_svwks,
+ .init_chipset = init_chipset_svwks,
+ .init_hwif = init_hwif_svwks,
+ .init_dma = init_dma_svwks,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 2 */
+ .name = "SvrWks CSB6",
+ .init_setup = init_setup_csb6,
+ .init_chipset = init_chipset_svwks,
+ .init_hwif = init_hwif_svwks,
+ .init_dma = init_dma_svwks,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 3 */
+ .name = "SvrWks CSB6",
+ .init_setup = init_setup_csb6,
+ .init_chipset = init_chipset_svwks,
+ .init_hwif = init_hwif_svwks,
+ .init_dma = init_dma_svwks,
+ .channels = 1,/* 2 */
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ }
+};
/**
* svwks_init_one - called when a OSB/CSB is found
Index: linux-idepci-export/drivers/ide/pci/serverworks.h
===
--- linux-idepci-export.orig/drivers/ide/pci/serverworks.h 2005-02-04
16:08:26.831227410 +0900
+++ /dev/null 1970-01-01 00:00:00.0 +
@@ -1,67 +0,0 @@
-
-#ifndef SERVERWORKS_H
-#define SERVERWORKS_H
-
-#include
-#include
-#include
-
-#define SVWKS_CSB5_REVISION_NEW0x92 /* min PCI_REVISION_ID for UDMA5
(A2.0) */
-#define SVWKS_CSB6_REVISION0xa0 /* min PCI_REVISION_ID for UDMA4 (A1.0) */
-
-/* Seagate Barracuda ATA IV Family drives in UDMA mode 5
- * can overrun their FIFOs when used with the CSB5 */
-static const char *svwks_bad_ata100[] = {
- "ST320011A",
- "ST340016A",
- "ST360021A",
- "ST380021A",
- NULL
-};
-
-static int init_setup_svwks(struct pci_dev *, ide_pci_device_t *);
-static int init_setup_csb6(struct pci_dev *, ide_pci_device_t *);
-static unsigned int init_chipset_svwks(struct pci_dev *, const char *);
-static void init_hwif_svwks(ide_hwif_t *);
-static void init_dma_svwks(ide_hwif_t *, unsigned long);
-
-static ide_pci_device_t serverworks_chipsets[] __devinitdata = {
- { /* 0 */
- .name = "SvrWks OSB4",
- .init_setup = init_setup_svwks,
- .init_chipset = init_chipset_svwks,
- .init_hwif = init_hwif_svwks,
- .channels = 2,
- .autodma= AUTODMA,
- .bootable = ON_BOARD,
- },{ /* 1 */
- .name = "SvrWks CSB5",
- .init_setup = init_setup_svwks,
- .init_chipset = init_chipset_svwks,
- .init_hwif = init_hwif_svwks,
- .init_dma = init_dma_svwks,
- .channels = 2,
- .autodma= AUTODMA,
- .bootable = ON_BOARD,
- },{ /* 2 */
- .name = "SvrWks CSB6",
-
Re: [PATCH 2.6.11-rc2 06/14] ide_pci: Merges hpt366.h into hpt366.c
06_ide_pci_hpt366_merge.patch
Merges ide/pci/hpt366.h into hpt366.c.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-idepci-export/drivers/ide/pci/hpt366.c
===
--- linux-idepci-export.orig/drivers/ide/pci/hpt366.c 2005-02-04
16:07:36.820372428 +0900
+++ linux-idepci-export/drivers/ide/pci/hpt366.c2005-02-04
16:08:25.366465966 +0900
@@ -70,7 +70,414 @@
#include
#include
-#include "hpt366.h"
+/* various tuning parameters */
+#define HPT_RESET_STATE_ENGINE
+#undef HPT_DELAY_INTERRUPT
+#undef HPT_SERIALIZE_IO
+
+static const char *quirk_drives[] = {
+ "QUANTUM FIREBALLlct08 08",
+ "QUANTUM FIREBALLP KA6.4",
+ "QUANTUM FIREBALLP LM20.4",
+ "QUANTUM FIREBALLP LM20.5",
+NULL
+};
+
+static const char *bad_ata100_5[] = {
+ "IBM-DTLA-307075",
+ "IBM-DTLA-307060",
+ "IBM-DTLA-307045",
+ "IBM-DTLA-307030",
+ "IBM-DTLA-307020",
+ "IBM-DTLA-307015",
+ "IBM-DTLA-305040",
+ "IBM-DTLA-305030",
+ "IBM-DTLA-305020",
+ "IC35L010AVER07-0",
+ "IC35L020AVER07-0",
+ "IC35L030AVER07-0",
+ "IC35L040AVER07-0",
+ "IC35L060AVER07-0",
+ "WDC AC310200R",
+ NULL
+};
+
+static const char *bad_ata66_4[] = {
+ "IBM-DTLA-307075",
+ "IBM-DTLA-307060",
+ "IBM-DTLA-307045",
+ "IBM-DTLA-307030",
+ "IBM-DTLA-307020",
+ "IBM-DTLA-307015",
+ "IBM-DTLA-305040",
+ "IBM-DTLA-305030",
+ "IBM-DTLA-305020",
+ "IC35L010AVER07-0",
+ "IC35L020AVER07-0",
+ "IC35L030AVER07-0",
+ "IC35L040AVER07-0",
+ "IC35L060AVER07-0",
+ "WDC AC310200R",
+ NULL
+};
+
+static const char *bad_ata66_3[] = {
+ "WDC AC310200R",
+ NULL
+};
+
+static const char *bad_ata33[] = {
+ "Maxtor 92720U8", "Maxtor 92040U6", "Maxtor 91360U4", "Maxtor 91020U3",
"Maxtor 90845U3", "Maxtor 90650U2",
+ "Maxtor 91360D8", "Maxtor 91190D7", "Maxtor 91020D6", "Maxtor 90845D5",
"Maxtor 90680D4", "Maxtor 90510D3", "Maxtor 90340D2",
+ "Maxtor 91152D8", "Maxtor 91008D7", "Maxtor 90845D6", "Maxtor 90840D6",
"Maxtor 90720D5", "Maxtor 90648D5", "Maxtor 90576D4",
+ "Maxtor 90510D4",
+ "Maxtor 90432D3", "Maxtor 90288D2", "Maxtor 90256D2",
+ "Maxtor 91000D8", "Maxtor 90910D8", "Maxtor 90875D7", "Maxtor 90840D7",
"Maxtor 90750D6", "Maxtor 90625D5", "Maxtor 90500D4",
+ "Maxtor 91728D8", "Maxtor 91512D7", "Maxtor 91303D6", "Maxtor 91080D5",
"Maxtor 90845D4", "Maxtor 90680D4", "Maxtor 90648D3", "Maxtor 90432D2",
+ NULL
+};
+
+struct chipset_bus_clock_list_entry {
+ bytexfer_speed;
+ unsigned intchipset_settings;
+};
+
+/* key for bus clock timings
+ * bit
+ * 0:3data_high_time. inactive time of DIOW_/DIOR_ for PIO and MW
+ *DMA. cycles = value + 1
+ * 4:8data_low_time. active time of DIOW_/DIOR_ for PIO and MW
+ *DMA. cycles = value + 1
+ * 9:12 cmd_high_time. inactive time of DIOW_/DIOR_ during task file
+ *register access.
+ * 13:17 cmd_low_time. active time of DIOW_/DIOR_ during task file
+ *register access.
+ * 18:21 udma_cycle_time. clock freq and clock cycles for UDMA xfer.
+ *during task file register access.
+ * 22:24 pre_high_time. time to initialize 1st cycle for PIO and MW DMA
+ *xfer.
+ * 25:27 cmd_pre_high_time. time to initialize 1st PIO cycle for task
+ *register access.
+ * 28 UDMA enable
+ * 29 DMA enable
+ * 30 PIO_MST enable. if set, the chip is in bus master mode during
+ *PIO.
+ * 31 FIFO enable.
+ */
+static struct chipset_bus_clock_list_entry forty_base_hpt366[] = {
+ { XFER_UDMA_4,0x900fd943 },
+ { XFER_UDMA_3,0x900ad943 },
+ { XFER_UDMA_2,0x900bd943 },
+ { XFER_UDMA_1,0x9008d943 },
+ { XFER_UDMA_0,0x9008d943 },
+
+ { XFER_MW_DMA_2, 0xa008d943 },
+ { XFER_MW_DMA_1, 0xa010d955 },
+ { XFER_MW_DMA_0, 0xa010d9fc },
+
+ { XFER_PIO_4, 0xc008d963 },
+ { XFER_PIO_3, 0xc010d974 },
+ { XFER_PIO_2, 0xc010d997 },
+ { XFER_PIO_1, 0xc010d9c7 },
+ { XFER_PIO_0, 0xc018d9d9 },
+ { 0, 0x0120d9d9 }
+};
+
+static struct chipset_bus_clock_list_entry thirty_three_base_hpt366[] = {
+ { XFER_UDMA_4,0x90c9a731 },
+ { XFER_UDMA_3,0x90cfa731 },
+ { XFER_UDMA_2,0x90caa731 },
+ { XFER_UDMA_1,0x90cba731 },
+ { XFER_UDMA_0,0x90c8a731 },
+
+ { XFER_MW_DMA_2, 0xa0c8a731 },
+ { XFER_MW_DMA_1, 0xa0c8a732 }, /* 0xa0c8a733 */
+ { XFER_MW_DMA_0, 0xa0c8a797 },
+
+ {
Re: [PATCH 2.6.11-rc2 11/14] ide_pci: Merges pdc202xx_old.h into pdc202xx_old.c
11_ide_pci_pdc202xx_old_merge.patch
Merges ide/pci/pdc202xx_old.h into pdc202xx_old.c.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-idepci-export/drivers/ide/pci/pdc202xx_old.c
===
--- linux-idepci-export.orig/drivers/ide/pci/pdc202xx_old.c 2005-02-04
16:08:26.197330649 +0900
+++ linux-idepci-export/drivers/ide/pci/pdc202xx_old.c 2005-02-04
16:08:26.404296941 +0900
@@ -46,9 +46,60 @@
#include
#include
-#include "pdc202xx_old.h"
+#define PDC202_DEBUG_CABLE 0
+#define PDC202XX_DEBUG_DRIVE_INFO 0
-#define PDC202_DEBUG_CABLE 0
+static const char *pdc_quirk_drives[] = {
+ "QUANTUM FIREBALLlct08 08",
+ "QUANTUM FIREBALLP KA6.4",
+ "QUANTUM FIREBALLP KA9.1",
+ "QUANTUM FIREBALLP LM20.4",
+ "QUANTUM FIREBALLP KX13.6",
+ "QUANTUM FIREBALLP KX20.5",
+ "QUANTUM FIREBALLP KX27.3",
+ "QUANTUM FIREBALLP LM20.5",
+ NULL
+};
+
+/* A Register */
+#defineSYNC_ERRDY_EN 0xC0
+
+#defineSYNC_IN 0x80/* control bit, different for master
vs. slave drives */
+#defineERRDY_EN0x40/* control bit, different for master
vs. slave drives */
+#defineIORDY_EN0x20/* PIO: IOREADY */
+#definePREFETCH_EN 0x10/* PIO: PREFETCH */
+
+#definePA3 0x08/* PIO"A" timing */
+#definePA2 0x04/* PIO"A" timing */
+#definePA1 0x02/* PIO"A" timing */
+#definePA0 0x01/* PIO"A" timing */
+
+/* B Register */
+
+#defineMB2 0x80/* DMA"B" timing */
+#defineMB1 0x40/* DMA"B" timing */
+#defineMB0 0x20/* DMA"B" timing */
+
+#definePB4 0x10/* PIO_FORCE 1:0 */
+
+#definePB3 0x08/* PIO"B" timing */ /* PIO flow
Control mode */
+#definePB2 0x04/* PIO"B" timing */ /* PIO 4 */
+#definePB1 0x02/* PIO"B" timing */ /* PIO 3 half */
+#definePB0 0x01/* PIO"B" timing */ /* PIO 3 other
half */
+
+/* C Register */
+#defineIORDYp_NO_SPEED 0x4F
+#defineSPEED_DIS 0x0F
+
+#defineDMARQp 0x80
+#defineIORDYp 0x40
+#defineDMAR_EN 0x20
+#defineDMAW_EN 0x10
+
+#defineMC3 0x08/* DMA"C" timing */
+#defineMC2 0x04/* DMA"C" timing */
+#defineMC1 0x02/* DMA"C" timing */
+#defineMC0 0x01/* DMA"C" timing */
#if 0
unsigned long bibma = pci_resource_start(dev, 4);
@@ -726,6 +777,77 @@ static int __devinit init_setup_pdc202xx
return ide_setup_pci_device(dev, d);
}
+static ide_pci_device_t pdc202xx_chipsets[] __devinitdata = {
+ { /* 0 */
+ .name = "PDC20246",
+ .init_setup = init_setup_pdc202ata4,
+ .init_chipset = init_chipset_pdc202xx,
+ .init_hwif = init_hwif_pdc202xx,
+ .init_dma = init_dma_pdc202xx,
+ .channels = 2,
+ .autodma= AUTODMA,
+#ifndef CONFIG_PDC202XX_FORCE
+ .enablebits = {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
+#endif
+ .bootable = OFF_BOARD,
+ .extra = 16,
+ },{ /* 1 */
+ .name = "PDC20262",
+ .init_setup = init_setup_pdc202ata4,
+ .init_chipset = init_chipset_pdc202xx,
+ .init_hwif = init_hwif_pdc202xx,
+ .init_dma = init_dma_pdc202xx,
+ .channels = 2,
+ .autodma= AUTODMA,
+#ifndef CONFIG_PDC202XX_FORCE
+ .enablebits = {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
+#endif
+ .bootable = OFF_BOARD,
+ .extra = 48,
+ .flags = IDEPCI_FLAG_FORCE_PDC,
+ },{ /* 2 */
+ .name = "PDC20263",
+ .init_setup = init_setup_pdc202ata4,
+ .init_chipset = init_chipset_pdc202xx,
+ .init_hwif = init_hwif_pdc202xx,
+ .init_dma = init_dma_pdc202xx,
+ .channels = 2,
+ .autodma= AUTODMA,
+#ifndef CONFIG_PDC202XX_FORCE
+ .enablebits = {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
+#endif
+ .bootable = OFF_BOARD,
+ .extra = 48,
+ },{ /* 3 */
+ .name = "PDC20265",
+ .init_setup = init_setup_pdc20265,
+ .init_chipset = init_chipset_pdc202xx,
+ .init_hwif = init_hwif_pdc202xx,
+ .init_dma = init_dma_pdc202xx,
+
Re: [PATCH 2.6.11-rc2 03/14] ide_pci: Merges cmd64x.h into cmd64x.c
03_ide_pci_cmd64x_merge.patch
Merges ide/pci/cmd64x.h into cmd64x.c.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-idepci-export/drivers/ide/pci/cmd64x.c
===
--- linux-idepci-export.orig/drivers/ide/pci/cmd64x.c 2005-02-04
16:07:37.029338395 +0900
+++ linux-idepci-export/drivers/ide/pci/cmd64x.c2005-02-04
16:08:24.687576532 +0900
@@ -25,7 +25,56 @@
#include
-#include "cmd64x.h"
+#define DISPLAY_CMD64X_TIMINGS
+
+#define CMD_DEBUG 0
+
+#if CMD_DEBUG
+#define cmdprintk(x...)printk(x)
+#else
+#define cmdprintk(x...)
+#endif
+
+/*
+ * CMD64x specific registers definition.
+ */
+#define CFR0x50
+#define CFR_INTR_CH0 0x02
+#define CNTRL 0x51
+#define CNTRL_DIS_RA0 0x40
+#define CNTRL_DIS_RA10x80
+#define CNTRL_ENA_2ND 0x08
+
+#defineCMDTIM 0x52
+#defineARTTIM0 0x53
+#defineDRWTIM0 0x54
+#define ARTTIM10x55
+#define DRWTIM10x56
+#define ARTTIM23 0x57
+#define ARTTIM23_DIS_RA2 0x04
+#define ARTTIM23_DIS_RA3 0x08
+#define ARTTIM23_INTR_CH10x10
+#define ARTTIM20x57
+#define ARTTIM30x57
+#define DRWTIM23 0x58
+#define DRWTIM20x58
+#define BRST 0x59
+#define DRWTIM30x5b
+
+#define BMIDECR0 0x70
+#define MRDMODE0x71
+#define MRDMODE_INTR_CH0 0x04
+#define MRDMODE_INTR_CH1 0x08
+#define MRDMODE_BLK_CH0 0x10
+#define MRDMODE_BLK_CH1 0x20
+#define BMIDESR0 0x72
+#define UDIDETCR0 0x73
+#define DTPR0 0x74
+#define BMIDECR1 0x78
+#define BMIDECSR 0x79
+#define BMIDESR1 0x7A
+#define UDIDETCR1 0x7B
+#define DTPR1 0x7C
#if defined(DISPLAY_CMD64X_TIMINGS) && defined(CONFIG_PROC_FS)
#include
@@ -707,6 +756,39 @@ static void __devinit init_hwif_cmd64x(i
hwif->drives[1].autodma = hwif->autodma;
}
+static ide_pci_device_t cmd64x_chipsets[] __devinitdata = {
+ { /* 0 */
+ .name = "CMD643",
+ .init_chipset = init_chipset_cmd64x,
+ .init_hwif = init_hwif_cmd64x,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 1 */
+ .name = "CMD646",
+ .init_chipset = init_chipset_cmd64x,
+ .init_hwif = init_hwif_cmd64x,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .enablebits = {{0x00,0x00,0x00}, {0x51,0x80,0x80}},
+ .bootable = ON_BOARD,
+ },{ /* 2 */
+ .name = "CMD648",
+ .init_chipset = init_chipset_cmd64x,
+ .init_hwif = init_hwif_cmd64x,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{
+ .name = "CMD649",
+ .init_chipset = init_chipset_cmd64x,
+ .init_hwif = init_hwif_cmd64x,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ }
+};
+
static int __devinit cmd64x_init_one(struct pci_dev *dev, const struct
pci_device_id *id)
{
return ide_setup_pci_device(dev, _chipsets[id->driver_data]);
Index: linux-idepci-export/drivers/ide/pci/cmd64x.h
===
--- linux-idepci-export.orig/drivers/ide/pci/cmd64x.h 2005-02-04
16:07:37.029338395 +0900
+++ /dev/null 1970-01-01 00:00:00.0 +
@@ -1,95 +0,0 @@
-#ifndef CMD64X_H
-#define CMD64X_H
-
-#include
-#include
-#include
-
-#define DISPLAY_CMD64X_TIMINGS
-
-#define CMD_DEBUG 0
-
-#if CMD_DEBUG
-#define cmdprintk(x...)printk(x)
-#else
-#define cmdprintk(x...)
-#endif
-
-/*
- * CMD64x specific registers definition.
- */
-#define CFR0x50
-#define CFR_INTR_CH0 0x02
-#define CNTRL 0x51
-#define CNTRL_DIS_RA0 0x40
-#define CNTRL_DIS_RA10x80
-#define CNTRL_ENA_2ND 0x08
-
-#defineCMDTIM 0x52
-#defineARTTIM0 0x53
-#defineDRWTIM0 0x54
-#define ARTTIM10x55
-#define DRWTIM10x56
-#define ARTTIM23 0x57
-#define ARTTIM23_DIS_RA2 0x04
-#define ARTTIM23_DIS_RA3 0x08
-#define ARTTIM23_INTR_CH10x10
-#define ARTTIM20x57
-#define ARTTIM30x57
-#define DRWTIM23 0x58
-#define DRWTIM20x58
-#define BRST 0x59
-#define DRWTIM30x5b
-
-#define BMIDECR0 0x70
-#define MRDMODE0x71
-#define
Re: [PATCH 2.6.11-rc2 05/14] ide_pci: Merges generic.h into generic.c
05_ide_pci_generic_merge.patch
Merges ide/pci/generic.h into generic.c.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-idepci-export/drivers/ide/pci/generic.c
===
--- linux-idepci-export.orig/drivers/ide/pci/generic.c 2005-02-04
16:07:36.891360866 +0900
+++ linux-idepci-export/drivers/ide/pci/generic.c 2005-02-04
16:08:25.160499511 +0900
@@ -39,8 +39,6 @@
#include
-#include "generic.h"
-
static unsigned int __devinit init_chipset_generic (struct pci_dev *dev, const
char *name)
{
return 0;
@@ -83,6 +81,115 @@ static void __devinit init_hwif_generic
return 0;
#endif
+static ide_pci_device_t generic_chipsets[] __devinitdata = {
+ { /* 0 */
+ .name = "NS87410",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .enablebits = {{0x43,0x08,0x08}, {0x47,0x08,0x08}},
+ .bootable = ON_BOARD,
+},{/* 1 */
+ .name = "SAMURAI",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 2 */
+ .name = "HT6565",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 3 */
+ .name = "UM8673F",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= NODMA,
+ .bootable = ON_BOARD,
+ },{ /* 4 */
+ .name = "UM8886A",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= NODMA,
+ .bootable = ON_BOARD,
+ },{ /* 5 */
+ .name = "UM8886BF",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= NODMA,
+ .bootable = ON_BOARD,
+ },{ /* 6 */
+ .name = "HINT_IDE",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 7 */
+ .name = "VIA_IDE",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= NOAUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 8 */
+ .name = "OPTI621V",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= NOAUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 9 */
+ .name = "VIA8237SATA",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = OFF_BOARD,
+ },{ /* 10 */
+ .name = "Piccolo0102",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= NOAUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 11 */
+ .name = "Piccolo0103",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= NOAUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 12 */
+ .name = "Piccolo0105",
+ .init_chipset = init_chipset_generic,
+ .init_hwif = init_hwif_generic,
+ .channels = 2,
+ .autodma= NOAUTODMA,
+ .bootable = ON_BOARD,
+ }
+};
+
+#if 0
+static ide_pci_device_t unknown_chipset[] __devinitdata = {
+ { /* 0 */
+ .name = "PCI_IDE",
+ .init_chipset = init_chipset_generic,
+
Re: [PATCH 2.6.11-rc2 02/14] ide_pci: Merges aec62xx.h into aec62xx.c
02_ide_pci_aec62xx_merge.patch
Merges ide/pci/aec62xx.h into aec62xx.c.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-idepci-export/drivers/ide/pci/aec62xx.c
===
--- linux-idepci-export.orig/drivers/ide/pci/aec62xx.c 2005-02-04
16:08:23.966693938 +0900
+++ linux-idepci-export/drivers/ide/pci/aec62xx.c 2005-02-04
16:08:24.332634340 +0900
@@ -16,7 +16,54 @@
#include
-#include "aec62xx.h"
+struct chipset_bus_clock_list_entry {
+ bytexfer_speed;
+ bytechipset_settings;
+ byteultra_settings;
+};
+
+static struct chipset_bus_clock_list_entry aec6xxx_33_base [] = {
+ { XFER_UDMA_6,0x31, 0x07},
+ { XFER_UDMA_5,0x31, 0x06},
+ { XFER_UDMA_4,0x31, 0x05},
+ { XFER_UDMA_3,0x31, 0x04},
+ { XFER_UDMA_2,0x31, 0x03},
+ { XFER_UDMA_1,0x31, 0x02},
+ { XFER_UDMA_0,0x31, 0x01},
+
+ { XFER_MW_DMA_2, 0x31, 0x00},
+ { XFER_MW_DMA_1, 0x31, 0x00},
+ { XFER_MW_DMA_0, 0x0a, 0x00},
+ { XFER_PIO_4, 0x31, 0x00},
+ { XFER_PIO_3, 0x33, 0x00},
+ { XFER_PIO_2, 0x08, 0x00},
+ { XFER_PIO_1, 0x0a, 0x00},
+ { XFER_PIO_0, 0x00, 0x00},
+ { 0, 0x00, 0x00}
+};
+
+static struct chipset_bus_clock_list_entry aec6xxx_34_base [] = {
+ { XFER_UDMA_6,0x41, 0x06},
+ { XFER_UDMA_5,0x41, 0x05},
+ { XFER_UDMA_4,0x41, 0x04},
+ { XFER_UDMA_3,0x41, 0x03},
+ { XFER_UDMA_2,0x41, 0x02},
+ { XFER_UDMA_1,0x41, 0x01},
+ { XFER_UDMA_0,0x41, 0x01},
+
+ { XFER_MW_DMA_2, 0x41, 0x00},
+ { XFER_MW_DMA_1, 0x42, 0x00},
+ { XFER_MW_DMA_0, 0x7a, 0x00},
+ { XFER_PIO_4, 0x41, 0x00},
+ { XFER_PIO_3, 0x43, 0x00},
+ { XFER_PIO_2, 0x78, 0x00},
+ { XFER_PIO_1, 0x7a, 0x00},
+ { XFER_PIO_0, 0x70, 0x00},
+ { 0, 0x00, 0x00}
+};
+
+#define BUSCLOCK(D)\
+ ((struct chipset_bus_clock_list_entry *) pci_get_drvdata((D)))
#if 0
if (dev->device == PCI_DEVICE_ID_ARTOP_ATP850UF) {
@@ -344,6 +391,58 @@ static int __devinit init_setup_aec6x80(
return ide_setup_pci_device(dev, d);
}
+static ide_pci_device_t aec62xx_chipsets[] __devinitdata = {
+ { /* 0 */
+ .name = "AEC6210",
+ .init_setup = init_setup_aec62xx,
+ .init_chipset = init_chipset_aec62xx,
+ .init_hwif = init_hwif_aec62xx,
+ .init_dma = init_dma_aec62xx,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .enablebits = {{0x4a,0x02,0x02}, {0x4a,0x04,0x04}},
+ .bootable = OFF_BOARD,
+ },{ /* 1 */
+ .name = "AEC6260",
+ .init_setup = init_setup_aec62xx,
+ .init_chipset = init_chipset_aec62xx,
+ .init_hwif = init_hwif_aec62xx,
+ .init_dma = init_dma_aec62xx,
+ .channels = 2,
+ .autodma= NOAUTODMA,
+ .bootable = OFF_BOARD,
+ },{ /* 2 */
+ .name = "AEC6260R",
+ .init_setup = init_setup_aec62xx,
+ .init_chipset = init_chipset_aec62xx,
+ .init_hwif = init_hwif_aec62xx,
+ .init_dma = init_dma_aec62xx,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .enablebits = {{0x4a,0x02,0x02}, {0x4a,0x04,0x04}},
+ .bootable = NEVER_BOARD,
+ },{ /* 3 */
+ .name = "AEC6X80",
+ .init_setup = init_setup_aec6x80,
+ .init_chipset = init_chipset_aec62xx,
+ .init_hwif = init_hwif_aec62xx,
+ .init_dma = init_dma_aec62xx,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = OFF_BOARD,
+ },{ /* 4 */
+ .name = "AEC6X80R",
+ .init_setup = init_setup_aec6x80,
+ .init_chipset = init_chipset_aec62xx,
+ .init_hwif = init_hwif_aec62xx,
+ .init_dma = init_dma_aec62xx,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .enablebits = {{0x4a,0x02,0x02},
[PATCH 2.6.11-rc2] ide_pci: cleanup ide pci drivers and merges .h files into .c files
Hello, Bartlomiej. These patches are the split versions of 05_ide_merge_pci_driver_hc. I removed crappy/unused macros from aec62xx, pdc202xx_old and serverworks drivers in respective *_cleanup patches and merged .h into .c files in *_merge patches. [ Start of patch descriptions ] 01_ide_pci_aec62xx_cleanup.patch : Remove lousy macros from aec62xx. Removes SPLIT_BYTE, MAKE_WORD and BUSCLOCK macros which are just better off directly coded from ide/pci/aec62xx driver. 02_ide_pci_aec62xx_merge.patch : Merges aec62xx.h into aec62xx.c Merges ide/pci/aec62xx.h into aec62xx.c. 03_ide_pci_cmd64x_merge.patch : Merges cmd64x.h into cmd64x.c Merges ide/pci/cmd64x.h into cmd64x.c. 04_ide_pci_cy82c693_merge.patch : Merges cy82c693.h into cy82c693.c Merges ide/pci/cy82c693.h into cy82c693.c. 05_ide_pci_generic_merge.patch : Merges generic.h into generic.c Merges ide/pci/generic.h into generic.c. 06_ide_pci_hpt366_merge.patch : Merges hpt366.h into hpt366.c Merges ide/pci/hpt366.h into hpt366.c. 07_ide_pci_it8172_merge.patch : Merges it8172.h into it8172.c Merges ide/pci/it8172.h into it8172.c. 08_ide_pci_opti621_merge.patch : Merges opti621.h into opti621.c Merges ide/pci/opti621.h into opti621.c. 09_ide_pci_pdc202xx_new_merge.patch : Merges pdc202xx_new.h into pdc202xx_new.c Merges ide/pci/pdc202xx_new.h into pdc202xx_new.c. 10_ide_pci_pdc202xx_old_cleanup.patch : Removes SPLIT_BYTE macro from pdc202xx_old Removes SPLIT_BYTE macro from ide/pci/pdc202xx_old driver. 11_ide_pci_pdc202xx_old_merge.patch : Merges pdc202xx_old.h into pdc202xx_old.c Merges ide/pci/pdc202xx_old.h into pdc202xx_old.c. 12_ide_pci_piix_merge.patch : Merges piix.h into piix.c Merges ide/pci/piix.h into piix.c. 13_ide_pci_serverworks_cleanup.patch : Removes unused SVWKS_DEBUG_DRIVE_INFO Removes unused SVWKS_DEBUG_DRIVE_INFO from ide/pci/serverworks driver. 14_ide_pci_serverworks_merge.patch : Merges serverworks.h into serverworks.c Merges ide/pci/serverworks.h into serverworks.c. [ End of patch descriptions ] Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3] IBM Trackpoint support
On Friday 04 February 2005 01:35, Vojtech Pavlik wrote:
> On Thu, Feb 03, 2005 at 07:34:16PM -0500, Dmitry Torokhov wrote:
> > On Thursday 03 February 2005 17:43, Stephen Evanchik wrote:
> > > Vojtech,
> > >
> > > Here is a patch that exposes the IBM TrackPoint's extended properties
> > > as well as scroll wheel emulation.
> > >
> > >
> >
> > Hi,
> >
> > Very nice although I have a couple of comments.
> >
> > > /*
> > > + * Try to initialize the IBM TrackPoint
> > > + */
> > > + if (max_proto > PSMOUSE_PS2 && trackpoint_init(psmouse) == 0) {
> > > + psmouse->vendor = "IBM";
> > > + psmouse->name = "TrackPoint";
> > > +
> > > + return PSMOUSE_PS2;
> >
> > Why PSMOUSE_PS2? Reconnect will surely not like it.
>
> Indeed. IIRC this patch killed wheel mouse detection in ubuntu.
>
We may need yet another psmouse_reset after unsuccessful test.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote: > Vojtech Pavlik <[EMAIL PROTECTED]> writes: > > > On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote: > > > > > * Removes the xres/yres scaling so that you get the same speed in the > > > X and Y directions even if your screen is not square. > > > > The old code assumed that both the pad and the screen are 4:3, not > > square. It was wrong still. > alps.c currently contains: > > psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); > input_set_abs_params(>dev, ABS_X, 0, 1023, 0, 0); > input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0); > input_set_abs_params(>dev, ABS_PRESSURE, 0, 127, 0, 0); > > Maybe it should set the ABS_Y max value to 767 in that case. Yes, and no. It could have been 1023, if it was 3:4 in size, but not in maximum values. See the real values below, though, it seems the resolution in X and Y is indeed the same. > --- linux/drivers/input/mouse/alps.c~ 2005-01-12 22:02:19.0 +0100 > +++ linux/drivers/input/mouse/alps.c 2005-02-04 07:38:12.203436768 +0100 > @@ -394,7 +394,7 @@ > > psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); > input_set_abs_params(>dev, ABS_X, 0, 1023, 0, 0); > - input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0); > + input_set_abs_params(>dev, ABS_Y, 0, 767, 0, 0); > input_set_abs_params(>dev, ABS_PRESSURE, 0, 127, 0, 0); > > psmouse->dev.keybit[LONG(BTN_TOUCH)] |= BIT(BTN_TOUCH); My ALPS gives values: X: 90-1019 Y: 100-749 Pressure: 0,34-108 So 0-1024, 0-768, 0-127 are probably the maximum theoretical ranges, and the rest are likely the mechanical mounting limitations of the notebook (the ridge around the pad is not rectangular). -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3] IBM Trackpoint support
On Fri, Feb 04, 2005 at 01:52:39AM -0500, Dmitry Torokhov wrote:
> On Friday 04 February 2005 01:35, Vojtech Pavlik wrote:
> > On Thu, Feb 03, 2005 at 07:34:16PM -0500, Dmitry Torokhov wrote:
> > > On Thursday 03 February 2005 17:43, Stephen Evanchik wrote:
> > > > Vojtech,
> > > >
> > > > Here is a patch that exposes the IBM TrackPoint's extended properties
> > > > as well as scroll wheel emulation.
> > > >
> > > >
> > >
> > > Hi,
> > >
> > > Very nice although I have a couple of comments.
> > >
> > > > /*
> > > > + * Try to initialize the IBM TrackPoint
> > > > + */
> > > > + if (max_proto > PSMOUSE_PS2 && trackpoint_init(psmouse) == 0) {
> > > > + psmouse->vendor = "IBM";
> > > > + psmouse->name = "TrackPoint";
> > > > +
> > > > + return PSMOUSE_PS2;
> > >
> > > Why PSMOUSE_PS2? Reconnect will surely not like it.
> >
> > Indeed. IIRC this patch killed wheel mouse detection in ubuntu.
> >
>
> We may need yet another psmouse_reset after unsuccessful test.
We probably should do one after every test for isolation. It's not that
big a problem now that we do the probing from a thread.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: A scrub daemon (prezeroing)
On Fri, 4 Feb 2005, Nick Piggin wrote: > If you have got to the stage of doing "real world" tests, I'd be > interested to see results of tests that best highlight the improvements. I am trying to figure out which tests to use right now. > I imagine many general purpose server things wouldn't be helped much, > because they'll typically have little free memory, and will be > continually working and turning things over. These things are helped because zapping memory is very fast. Continual turning things over results in zapping of large memory areas once in awhile which even speeds up (a sparsely accessing) benchmark. Read my earlier posts on the subject. There is of course an issue if the system is continuously low on memory. In that case the buddy allocator may not generate large enough orders of free pages to make it worth to zap them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3] IBM Trackpoint support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vojtech Pavlik wrote:
| On Thu, Feb 03, 2005 at 07:34:16PM -0500, Dmitry Torokhov wrote:
|
|>On Thursday 03 February 2005 17:43, Stephen Evanchik wrote:
|>
|>>Vojtech,
|>>
|>>Here is a patch that exposes the IBM TrackPoint's extended properties
|>>as well as scroll wheel emulation.
|>>
|>>
|>
|>Hi,
|>
|>Very nice although I have a couple of comments.
|>
|>
|>> /*
|>>+ * Try to initialize the IBM TrackPoint
|>>+ */
|>>+ if (max_proto > PSMOUSE_PS2 && trackpoint_init(psmouse) == 0) {
|>>+ psmouse->vendor = "IBM";
|>>+ psmouse->name = "TrackPoint";
|>>+
|>>+ return PSMOUSE_PS2;
|>
|>Why PSMOUSE_PS2? Reconnect will surely not like it.
|
|
| Indeed. IIRC this patch killed wheel mouse detection in ubuntu.
|
That's correct. I had to revert it unfortunatly and i am dealing to
give it another shot if you want to get it tested again
before inclusion in the main tree, but it has to happen no later than
next week since we are very close to feature freeze for the next release.
Regards,
Fabio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQgMaXlA6oBJjVJ+OAQKn7A//ULwd9zWcnqgmY0+uacKYT9LYa2hcIBuu
P9i08D/GpTGSglJ0iLBKM6eHw1eKLMwC1snVQ99TyCVMIicEBnNgcF31McEui/Q7
ZJug1Twndb0pUAc/erKUzdqLmQTIPax1eJLLCEmw81UWA0sW2PW52DZ26/4jqSFz
qpNYpvkT8h4X5Gc4l8j/erMYasN4jglcdjDKzfj6NMsVqWC5VJN5W863KPyM2dmf
BN9Mx8jDSzO6PgfquhKJa/6pUV7OODko6PwnJFkWC3SR03x8SjX7EKKDpkYW8OnX
RZGq2Tkmv5B2lme4v9e+O5+UPRzBuahxyknZw9WOcRBUeMpzAAXrIL6cDsWb9ZAd
ZCbIp3MS2be+hIY3hElbHiMN6+XLmr41u5PHGoxBOg8t4UPPTij7/ym3w4iB9Fbu
JIjEDsUfSVjzMZ0+tLGFl+2CtwrrBtmvGnuzLEzJxbwRWlzirIBj5VxAyLUVfXUB
TT0tAeDcopHqki3kFifiXUJ9XKPocwgznosZpISfNdJLB4+kw6S0/XamsbzZBJzr
K1Me547OABE8d/vc4dR7nDKqw4quZk6qThK7wqziiz6mGlBC28gLkfyxfGvVj/Uv
6uaE7RNOvRQYQNUFMMt6BH7vogCp7GsqrMfiiNc72SaxN8Gp4g2cH8v7xpUXcrJ0
mc6TtaGNagQ=
=AVn/
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: A scrub daemon (prezeroing)
On Thu, 2005-02-03 at 22:26 -0800, Christoph Lameter wrote: > On Fri, 4 Feb 2005, Paul Mackerras wrote: > > > As has my scepticism about pre-zeroing actually providing any benefit > > on ppc64. Nevertheless, the only definitive answer is to actually > > measure the performance both ways. > > Of course. The optimization depends on the type of load. If you use a > benchmark that writes to all pages in a page then you will see no benefit > at all. For a kernel compile you will see a slight benefit. For processing > of a sparse matrix (page tables are one example) a significant benefit can > be obtained. If you have got to the stage of doing "real world" tests, I'd be interested to see results of tests that best highlight the improvements. I imagine many general purpose server things wouldn't be helped much, because they'll typically have little free memory, and will be continually working and turning things over. A kernel compile on a newly booted system? Well that is a valid test. It is great that performance doesn't *decrease* in that case :P Of course HPC things may be a different story. It would be good to see your gross improvement on typical types of workloads that can best leverage this - and not just initial ramp up phases while memory is being faulted in, but the the full run time. Thanks, Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote: > > > * Removes the xres/yres scaling so that you get the same speed in the > > X and Y directions even if your screen is not square. > > The old code assumed that both the pad and the screen are 4:3, not > square. It was wrong still. alps.c currently contains: psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); input_set_abs_params(>dev, ABS_X, 0, 1023, 0, 0); input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0); input_set_abs_params(>dev, ABS_PRESSURE, 0, 127, 0, 0); Maybe it should set the ABS_Y max value to 767 in that case. --- linux/drivers/input/mouse/alps.c~ 2005-01-12 22:02:19.0 +0100 +++ linux/drivers/input/mouse/alps.c2005-02-04 07:38:12.203436768 +0100 @@ -394,7 +394,7 @@ psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); input_set_abs_params(>dev, ABS_X, 0, 1023, 0, 0); - input_set_abs_params(>dev, ABS_Y, 0, 1023, 0, 0); + input_set_abs_params(>dev, ABS_Y, 0, 767, 0, 0); input_set_abs_params(>dev, ABS_PRESSURE, 0, 127, 0, 0); psmouse->dev.keybit[LONG(BTN_TOUCH)] |= BIT(BTN_TOUCH); -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3] IBM Trackpoint support
On Thu, Feb 03, 2005 at 07:34:16PM -0500, Dmitry Torokhov wrote:
> On Thursday 03 February 2005 17:43, Stephen Evanchik wrote:
> > Vojtech,
> >
> > Here is a patch that exposes the IBM TrackPoint's extended properties
> > as well as scroll wheel emulation.
> >
> >
>
> Hi,
>
> Very nice although I have a couple of comments.
>
> > /*
> > + * Try to initialize the IBM TrackPoint
> > + */
> > + if (max_proto > PSMOUSE_PS2 && trackpoint_init(psmouse) == 0) {
> > + psmouse->vendor = "IBM";
> > + psmouse->name = "TrackPoint";
> > +
> > + return PSMOUSE_PS2;
>
> Why PSMOUSE_PS2? Reconnect will surely not like it.
Indeed. IIRC this patch killed wheel mouse detection in ubuntu.
>
> > +int tp_sens = TP_DEF_SENS;
> > +module_param_named(sens, tp_sens, uint, 0);
> > +MODULE_PARM_DESC(sens, "Sensitivity");
>
> > +int tp_mb_scroll = TP_DEF_MB_SCROLL;
> > +module_param_named(mb_scroll, tp_mb_scroll, uint, 0);
> > +MODULE_PARM_DESC(mb_scroll, "Scroll with middle button");
>
> All of this should be handled via sysfs dynamically, we don't need any
> more pmouse module parameters.
Exactly.
> > +remove_proc_entry("neg_inertia", tp_dir);
> > +remove_proc_entry("speed", tp_dir);
> > +remove_proc_entry("sensitivity", tp_dir);
> > +remove_proc_entry("trackpoint", NULL);
> > +}
>
> No new proc stuff please (it will be visible from sysfs when you redo the
> module parameters).
... automatically, even ...
> > +
> > + tp->scrolling = 0;
> > + tp->mb_was_down = 0;
> > + }
> > +else if(tp->scrolling) {
> > +
> > + /* Vertical scrolling */
> > + diff = (int) ((packet[0] << 3) & 0x100) - (int) packet[2];
> > +if( diff < -2 ) {
> > + input_report_rel(>dev, REL_WHEEL, 1);
> > + }
> > + else if(diff > 2) {
> > + input_report_rel(>dev, REL_WHEEL, -1);
> > + }
> > +
> > +/* Horizontal scrolling */
> > +diff = (int) packet[1] - (int) ((packet[0] << 4) & 0x100);
> > +if( diff < -2) {
> > +input_report_rel(>dev, REL_HWHEEL, 1);
> > +}
> > +else if( diff > 2) {
> > +input_report_rel(>dev, REL_HWHEEL, -1);
> > +}
> > +
> > + packet[1] &= 0x00;
> > + packet[2] &= 0x00;
> > + }
>
> Looks like whitespace damage (tabs vs spaces) plus it should be "} else {"
> on one line.
What a shame that this thing doesn't have a raw mode where it'd report
the pressure ...
> > +int trackpoint_reconnect(struct psmouse *psmouse)
> > +{
> > + unsigned char toggle;
> > + struct trackpoint_data *tp = psmouse->private;
> > +
> > + /* Push the config to the device */
> > +
>
> I'd like to verify that it still recognized as trackpoint - suspends often
> play tricks on PS/2 devices.
>
> > +
> > + printk("IBM TrackPoint firmware: 0x%02X\n", param[1]);
>
> KERN_INFO?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Dynamic tick, version 050127-1
On Thu, 3 Feb 2005, Tony Lindgren wrote: > > > > It could also be that the reprogamming of PIT timer does not work on > > > > your machine. I chopped off the udelays there... Can you try > > > > something like this: > > > > > > I added the udelays, but behaviour did not change. > > > > Yeah, and if the first patch was working better, that means the PIT > > interrupts work. I'll do another version of the patch where PIT > > interrupts work again without local APIC needed, let's see what > > happens with that. I see in the patch that you're reprogramming the PIT for a periodic mode (2) but using dyn_tick->skip as the period. Is this intentional? I thought you wanted a oneshot for that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: page fault scalability patch V16 [3/4]: Drop page_table_lock in handle_mm_fault
On Wed, 2005-02-02 at 14:09 +1100, Nick Piggin wrote: > On Tue, 2005-02-01 at 18:49 -0800, Christoph Lameter wrote: > > On Wed, 2 Feb 2005, Nick Piggin wrote: > > I mean we could just speculatively copy, risk copying crap and > > discard that later when we find that the pte has changed. This would > > simplify the function: > > > > I think this may be the better approach. Anyone else? > Not to say it is perfect either. Normal semantics say not to touch a page if it is not somehow pinned. So this may cause problems in corner cases (DEBUG_PAGEALLOC comes to mind... hopefully nothing else). But I think a plain read of the page when it isn't pinned is less yucky than writing into the non-pinned struct page. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A scrub daemon (prezeroing)
On Fri, 4 Feb 2005, Paul Mackerras wrote: > The dcbz instruction on the G5 (PPC970) establishes the new cache line > in the L2 cache and doesn't disturb the L1 cache (except to invalidate > the line in the L1 data cache if it is present there). The L2 cache > is 512kB and 8-way set associative (LRU). So zeroing a page is > unlikely to disturb the cache lines that the page fault handler is > using. Then, when the page fault handler returns to the user program, > any cache lines that the program wants to touch are available in 12 > cycles (L2 hit latency) instead of 200 - 300 (memory access latency). If the program does not use these cache lines then you have wasted time in the page fault handler allocating and handling them. That is what prezeroing does for you. > > cpu caches) is extraordinarily fast and the zeroing of large portions of > > memory is so too. That is why the impact of scrubd is negligible since > > its extremely fast. > > But that also disturbs cache lines that may well otherwise be useful. Yes but its a short burst that only occurs very infrequestly and it takes advantage of all the optimizations that modern memory subsystems have for linear accesses. And if hardware exists that can offload that from the cpu then the cpu caches are only minimally affected. > As has my scepticism about pre-zeroing actually providing any benefit > on ppc64. Nevertheless, the only definitive answer is to actually > measure the performance both ways. Of course. The optimization depends on the type of load. If you use a benchmark that writes to all pages in a page then you will see no benefit at all. For a kernel compile you will see a slight benefit. For processing of a sparse matrix (page tables are one example) a significant benefit can be obtained. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad problems with 2.6.11-rc2
On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote:
> Vojtech Pavlik <[EMAIL PROTECTED]> writes:
>
> > On Wed, Feb 02, 2005 at 11:58:05PM +0100, Peter Osterlund wrote:
> >
> > > In practice I don't think it will make any significant difference. What
> > > the code should do depends on what you want to happen if you move the
> > > mouse pointer 1/2 pixel with one finger stroke, then move it another 1/2
> > > pixel with a second stroke. The patch I posted will move the pointer one
> > > pixel in this case and your code will move it 0 pixels. (The X driver does
> > > not reset the fractions, but that doesn't of course mean that it's the
> > > only right thing to do.)
> > >
> > > > Also, I think the extra unary minus is uncoth.
> > >
> > > The code was written like that to emphasize the fact that X and Y use the
> > > same formula, with the only difference that the kernel Y axis is mirrored
> > > compared to the touchpad Y axis.
> > >
> > > It didn't make any difference for the generated assembly code though,
> > > using gcc 3.4.2 from Fedora Core 3.
> > >
> > > > + enum { FRACTION_DENOM = 100 };
> > >
> > > The enum is much nicer than my #define.
> >
> > OK. I like this patch, too. Can you guys send me a final version
> > incorporating the changes of you both for inclusion in the input tree?
>
> Here it is, with the suggestions from Pete and Dmitry included. The
> patch does the following:
>
> * Compensates for the lack of floating point arithmetic by keeping
> track of remainders from the integer divisions.
This was likely the main cause of the slow motion problems.
> * Removes the xres/yres scaling so that you get the same speed in the
> X and Y directions even if your screen is not square.
The old code assumed that both the pad and the screen are 4:3, not
square. It was wrong still.
> * Sets scale factors to make the speed for synaptics and alps equal to
> each other and equal to the synaptics speed from 2.6.10.
>
> Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
OK. I'll add it to my tree today.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] Re: kdump on non-boot cpu
Hi, > The reason I was asking and assuming you had a 32bit kernel is that > you were quoting pieces of arch/i386/kernel/crash.c instead of > arch/x86_64/kernel/crash.c Using "arch/i386/kernel/crash.c" is just for explanation how we avoid the hang. (I found x86_64 kdump is not supported in 2.6.11-rc2-mm1 :-)) The attached log is a log of running mkdump (it supports x86_64). not kdump. The basic procedure before jumping new kernel is almost same as kdump. So I inform this infromation to you since I think it may be helpfull for kdump development. > Ok. Thanks. This is a legitimate bug. And it is probably the reason > I even care about the non-SMP interrupt case some days. The problem > is that the kernel just assumes interrupts are setup in non-APIC mode > when it starts booting, and quite possibly only the bootstrap cpu can > see those interrupts. > > So I believe the fix needs to be to enable apics before we calibrate > the delay timer. I'm not certain off the top of my head what that > patch will look like but it should not be fundamentally hard. > With that code in place we also don't need to do any APIC shutdown > as the kernel knows enough to completely setup the apics. I see. Thank you for your explanation. Thanks. -- Itsuro ODA <[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: e1000, sshd, and the infamous "Corrupted MAC on input"
Hi, On Thu, Feb 03, 2005 at 11:16:37PM -0500, Ethan Weinstein wrote: (...) > Excellent tip, thanks. I was able to reprodce the problem several times > using this technique with nc, however the problem was intermittent (as > nasty problems like this often are). I used a 1.3G gzipped tarball and > experienced several botched transfers along with a few good ones. To > be fair, I also switched back to 100Fdx and repeated; I didn't get a > single failure at this speed over 25 or so runs. > > The results of two cmp's are here: > > http://www.stinkfoot.org/e1000tests.out > > What next? I would disable rx/tx checksums on the cards to ensure that's not a bug in this part. Because one reason to see what you encounter would be that some frames are corrupted at gigabit speed (possibly on one of the cards themselves), and they don't correctly compute the checksum on the receive side, or they ignore when it's bad. IIRC, you can do this with ethtool : # ethtool -K rx off tx off Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.10 dies when X uses G550
> The logs with secondary radeon used to end like this: > (II) LoadModule: "int10" > (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a > (II) RADEON(0): initializing int10 > (**) RADEON(0): Option "InitPrimary" "on" > (II) Truncating PCI BIOS Length to 53248 > > The logs for secondary G550 ends like this, with or without int10 > (--) MGA(0): Pseudo-DMA transfer window at 0xF300 > (==) MGA(0): BIOS at 0xC > (WW) MGA(0): Video BIOS info block not detected! > (II) MGA(0): MGABios.RamdacType = 0x0 > (==) MGA(0): Write-combining range (0xf000,0x200) > (--) MGA(0): VideoRAM: 2048 kByte > (II) Loading sub module "ddc" > (II) LoadModule: "ddc" > (II) Reloading /usr/X11R6/lib/modules/libddc.a > (II) Loading sub module "i2c" > (II) LoadModule: "i2c" > (II) Loading /usr/X11R6/lib/modules/libi2c.a > (II) Module i2c: vendor="The XFree86 Project" > compiled for 4.3.0.1, module version = 1.2.0 > ABI class: XFree86 Video Driver, version 0.6 > (==) MGA(0): Write-combining range (0xf000,0x20) > (II) MGA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x > (II) MGA(0): I2C bus "DDC" initialized. > (II) MGA(0): I2C device "DDC:ddc2" registered at address 0xA0. > (II) MGA(0): I2C device "DDC:ddc2" removed. > (II) MGA(0): I2C Monitor info: (nil) > (II) MGA(0): end of I2C Monitor info > > The video bios is apparently not detected at all, and therefore not run. > > The kernel doesn't actually hang, only X gets stuck. sysrq+T > dumped stack traces for all tasks except the xserver. For X, > there was only one line identifying the xserver process and the fact > that it was Running. No stack dump. I managed to kill all tasks > and have init proceeding into init 2. > > So I wonder - is Debians X 4.3.0.1 buggy, or the kernel? > The fact remains that the newer kernels locks up while trying to use the > secondary radeon, while it actually works with 2.6.8.1. I've had some luck in reproducing this, however I've had to retask my test machine to find some hangs in my real life application (can run for 5 or 6 days without crashing :-), so I might get back to looking for this at some stage but when is anybodys guess, all I did was take a Radeon AGP card, and a PCI SiS crappy card and ran X on 2.6.10 and it hung 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: Has anyone dumped udev for devfs?
Kevin Fries wrote: > Any ETA on when udev is going to be ready for prime time? And, any > clue why Fedora insists on relying on a program that does not f*(&%ing > work > > I am trying to get a Microtek X12 USL scanner attached, and udev fails > to mount it, every time. Has anyone tried uninstalling udev and > reinstalling devfs to stop all these damn usb failures? > > If so, any hints on how not to make your system unstable? > > TIA > Kevin Fries I haven't gone back to devfs, but I feel your pain. udev+hal worked fine for a couple months, until hald started intermittently locking up. Now I can't go 2 days without a reboot, because hald so often goes into "uninterruptible sleep" and is totally unkillable. I've upgraded udev, hal, and my kernel a bunch of times, but nothing has fixed this. And it's not a single piece of hardware; sometimes it's USB, sometimes Firewire, sometimes a CDROM, that causes hald to take a nap, permanently. -Anthony DiSante http://nodivisions.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A scrub daemon (prezeroing)
Christoph Lameter writes: > You need to think about this in a different way. Prezeroing only makes > sense if it can avoid using cache lines that the zeroing in the > hot paths would have to use since it touches all cachelines on > the page (the ppc instruction is certainly nice and avoids a cacheline > read but it still uses a cacheline!). The zeroing in itself (within the The dcbz instruction on the G5 (PPC970) establishes the new cache line in the L2 cache and doesn't disturb the L1 cache (except to invalidate the line in the L1 data cache if it is present there). The L2 cache is 512kB and 8-way set associative (LRU). So zeroing a page is unlikely to disturb the cache lines that the page fault handler is using. Then, when the page fault handler returns to the user program, any cache lines that the program wants to touch are available in 12 cycles (L2 hit latency) instead of 200 - 300 (memory access latency). > cpu caches) is extraordinarily fast and the zeroing of large portions of > memory is so too. That is why the impact of scrubd is negligible since > its extremely fast. But that also disturbs cache lines that may well otherwise be useful. > The point is to save activating cachelines not the time zeroing in itself > takes. This only works if only parts of the page are needed immediately > after the page fault. All of that has been documented in earlier posts on > the subject. As has my scepticism about pre-zeroing actually providing any benefit on ppc64. Nevertheless, the only definitive answer is to actually measure the performance both ways. 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] Dynamic tick, version 050127-1
* Tony Lindgren <[EMAIL PROTECTED]> [050203 15:07]:
> * Pavel Machek <[EMAIL PROTECTED]> [050203 02:57]:
> > Hi!
> >
> > > > > > > > I used your config advices from second mail, still it does not
> > > > > > > > work as
> > > > > > > > expected: system gets "too sleepy". Like it takes a nap during
> > > > > > > > boot
> > > > > > > > after "dyn-tick: Maximum ticks to skip limited to 1339", and
> > > > > > > > key is
> > > > > > > > needed to make it continue boot. Then cursor stops blinking and
> > > > > > > > machine is hung at random intervals during use, key is enough
> > > > > > > > to awake
> > > > > > > > it.
> > > > > > >
> > > > > > > Hmmm, that sounds like the local APIC does not wake up the PIT
> > > > > > > interrupt properly after sleep. Hitting the keys causes the timer
> > > > > > > interrupt to get called, and that explains why it keeps running.
> > > > > > > But
> > > > > > > the timer ticks are not happening as they should for some reason.
> > > > > > > This should not happen (tm)...
> > > > > >
> > > > > > :-). Any ideas how to debug it? Previous version of patch seemed to
> > > > > > work better...
> > > > >
> > > > > I don't think it's HPET timer, or CONFIG_SMP. It also looks like your
> > > > > local APIC timer is working.
> > > >
> > > > I turned off CONFIG_PREEMPT, but nothing changed :-(.
> > >
> > > What about reprogramming the timers in time.c after the sleep? Do
> > > you to dyn_tick->skip = 1; part in dyn_tick_timer_interrupt?
> >
> > Yes, when I enabled debugging, dbg_dyn_tick_irq() was reached and
> > produced lot of noise to syslog. After I done nothing for a while,
> > machine would just sit there and wait, not doing anything. When it was
> > hung, dbg_dyn_timer_tick was not reached.
>
> OK. Function dbg_dyn_timer_tick only printks if the sleep was less
> than expected and the system woke to a non-timer interrupt. But when
> idling, it should still printk something occasionally.
>
> > > It could also be that the reprogamming of PIT timer does not work on
> > > your machine. I chopped off the udelays there... Can you try
> > > something like this:
> >
> > I added the udelays, but behaviour did not change.
>
> Yeah, and if the first patch was working better, that means the PIT
> interrupts work. I'll do another version of the patch where PIT
> interrupts work again without local APIC needed, let's see what
> happens with that.
I think something broke TSC timer after the first patch, but I could
not figure out yet what. So the bad combo might be local APIC + TSC.
At least I'm seeing similar problems with local APIC + TSC timer.
Attached is a slightly improved patch, but the patch does not fix
the TSC problem. It just fixes compile without local APIC, and
booting SMP kernel on uniprocessor machine.
Currently the suggested combo is local APIC + ACPI PM timer...
And if that works, changing the I8042_POLL_PERIOD from HZ/20 in
drivers/input/serio/i8042.h to something like HZ increases the
sleep interval quite a bit. I think I had lots of polling also in
CONFIG_NETFILTER, but I haven't verified that.
Regards,
Tonydiff -Nru a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig 2005-02-03 21:11:01 -08:00
+++ b/arch/i386/Kconfig 2005-02-03 21:11:01 -08:00
@@ -452,6 +452,16 @@
bool "Provide RTC interrupt"
depends on HPET_TIMER && RTC=y
+config NO_IDLE_HZ
+ bool "Dynamic Tick Timer - Skip timer ticks during idle"
+ help
+ This option enables support for skipping timer ticks when the
+ processor is idle. During system load, timer is continuous.
+ This option saves power, as it allows the system to stay in
+ idle mode longer. Currently supported timers are ACPI PM
+ timer, local APIC timer, and TSC timer. HPET timer is currently
+ not supported.
+
config SMP
bool "Symmetric multi-processing support"
---help---
diff -Nru a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
--- a/arch/i386/kernel/apic.c 2005-02-03 21:11:01 -08:00
+++ b/arch/i386/kernel/apic.c 2005-02-03 21:11:01 -08:00
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -795,8 +796,12 @@
if (!smp_found_config && detect_init_APIC()) {
apic_phys = (unsigned long) alloc_bootmem_pages(PAGE_SIZE);
apic_phys = __pa(apic_phys);
- } else
+ } else {
apic_phys = mp_lapic_addr;
+#ifdef CONFIG_NO_IDLE_HZ
+ dyn_tick->state |= DYN_TICK_USE_APIC;
+#endif
+ }
set_fixmap_nocache(FIX_APIC_BASE, apic_phys);
printk(KERN_DEBUG "mapped APIC to %08lx (%08lx)\n", APIC_BASE,
@@ -909,6 +914,8 @@
#define APIC_DIVISOR 16
+static u32 apic_timer_val;
+
void __setup_APIC_LVTT(unsigned int clocks)
{
unsigned int lvtt_value, tmp_value, ver;
@@ -927,7 +934,15 @@
& ~(APIC_TDR_DIV_1 | APIC_TDR_DIV_TMBASE))
|
Re: e1000, sshd, and the infamous "Corrupted MAC on input"
On Thu, Feb 03, 2005 at 11:16:37PM -0500, Ethan Weinstein wrote:
> Matt Mackall wrote:
> >On Wed, Feb 02, 2005 at 10:44:14PM -0500, Ethan Weinstein wrote:
> ...
> >>Finally, I used a crossover cable between the two boxes, which resulted
> >>in the same error from sshd again.
> >
> >
> >Well ssh isn't an especially good test as it's hard to debug.
> >
> >Try transferring large compressed files via netcat and comparing the
> >results. eg:
> >
> >host1# nc -l -p 2000 > foo.bz2
> >
> >host2# nc host1 2000 < foo.bz2
> >
> >If the md5sums differ, follow up with a cmp -bl to see what changed.
> >
> >Then we can look at the failure patterns and determine if there's some
> >data or alignment dependence.
> >
>
> Excellent tip, thanks. I was able to reprodce the problem several times
> using this technique with nc, however the problem was intermittent (as
> nasty problems like this often are). I used a 1.3G gzipped tarball and
> experienced several botched transfers along with a few good ones. To
> be fair, I also switched back to 100Fdx and repeated; I didn't get a
> single failure at this speed over 25 or so runs.
>
> The results of two cmp's are here:
>
> http://www.stinkfoot.org/e1000tests.out
>
> What next?
Ok, reproduceable without ssh makes narrowing this down much easier.
Are you seeing errors on the interface? No would indicate problems
post CRC checking on the receive side. Do errors happen in both
directions? If not, it may be CPU speed-related or specific to a given
NIC - swap them if they're not onboard.
The next test is to send patterns. Try sending yourself a gigabyte of:
#include
int main(void)
{
int i;
for (i = 0; i < 0x1000; i++) {
fwrite(, 4, 1, stdout);
}
}
If there's some sort of partial DMA transfer going on, this should
make it evident.
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Reseting a video card from suspend is essentially the same problem as reseting secondary video cards on boot. The same code can address both problems. Some things to consider 1) With multiple video cards you have to ensure only a single VGA gets enabled. Running video reset on a card is going to turn on it's VGA emulation. So you have to ensure that VGA emulation on other cards is disabled first. 2) I add the 'rom' parameter in sysfs so that you can get to the rom contents from a user space app. It's there to support running video reset code. "echo 1 >rom" to see the contents, it is not enabled by default. 3) The user space reset programs have to be serialized because of the rule about only a single VGA at a time. Calling vm86 from kernel mode is not a good idea. Doing this in user space lets you have two reset programs, vm86 and emu86 for non-x86 machines. A starting place for a user space reset program: ftp://ftp.scitechsoft.com/devel/obsolete/x86emu/x86emu-0.8.tar.gz This thread talks about the VGA routing code: http://lkml.org/lkml/2005/1/17/347 -- Jon Smirl [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: DVD-RW writes but doesn't read
Just a few days ago I installed a brand new OEM AOpen DUW1608/ARR. At
times while mounting DVDs the drive would lose files between ls's, or
get I/O errors while ls'ing. I also noticed the same errors you posted
below. I might have stumbled across a solution to this problem. In my
BIOS I changed all of the AUTO's in the CD/DVD drive properties and set
them to CD/DVD (drive type), PIO-4 (PIO MODE), and DMA-4 (DMA MODE).
This change had an apparent effect which no longer produces such reading
errors, at least from the 4 reading tests (2 DVD and 2 CD). The 2 DVD
reads were done with vobcopy, and the CD tests were done with cdrdao,
and md5sum (checking the Ubuntu files with the CD with the provided
md5sum.txt, from within the CD, in the DVD drive).
Hope it works.
On Wednesday 22 December 2004 00:33, you wrote:
> Hi Jens et al
>
> I have a laptop DVD-RW that is working fine when burning but has endless
> streams of errors with any kernel I try when trying to read anything
> (cd/dvd audio/video/data).
>
> hdc: command error: status=0x51 { DriveReady SeekComplete Error }
> hdc: command error: error=0x50
> ide: failed opcode was 100
> end_request: I/O error, dev hdc, sector 571832
> Buffer I/O error on device hdc, logical block 71479
>
> If I'm persistent I can read the data off the drive but I'll probably
> kill the drive in the process. It doesn't matter what iosched I use but I
> use cfq by default. I've tried disabling dma and so on without
success. Any
> ideas?
>
> Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.10 dies when X uses G550
This appears to me to be a problem with the drivers in the X server. DRM isn't active yet so I don't think the problem is there. There may have been a kernel change that caused BIOS reset to stop working. X does nasty things to the PCI bus from user space and there are many ways that X and the kernel could interfere with each other. Maybe some one that owns a PCI video card and a Matrox G550 can step through this in a debugger and see what is happening. You can look at the contents in of the video BIOS ROMs in recent kernels. Go into sys and find your video card. echo 1 >rom. That will enable the rom access code. You can then hexdump the ROM contents. This is a small program for running a reset on video cards. It will reset all of your cards. You might want to try running it. If it hangs it will be easier to debug than an X server. ftp://ftp.scitechsoft.com/devel/obsolete/x86emu/x86emu-0.8.tar.gz I added the X server dev list on the CC. On Fri, 4 Feb 2005 04:43:04 +0100, Helge Hafting <[EMAIL PROTECTED]> wrote: > On Sun, Jan 30, 2005 at 12:05:27PM -0500, Jon Smirl wrote: > > On Sun, 30 Jan 2005 17:32:41 +0100, Helge Hafting > > <[EMAIL PROTECTED]> wrote: > > > Yes, it is a PCI radeon. And the machine has an AGP slot > > > too, which is used by a matrox G550. This AGP card was not > > > used in the test, (other than being the VGA console). > > > Note that there is no crash if I don't compile > > > AGP support, so the crash is related to AGP somehow even though > > > AGP is not supposed to be used in this case. > > > > Can you set the PCI card to be primary in your BIOS or remove the AGP > > card, and then see if it works? It could be that X's video reset code > > for secondary PCI cards is broken. > > > I tried this. I already reported that X came up on the radeon. > I could not run X on the G550, now that it was "secondary", > but the crash was different from the radeon crash. > > The logs with secondary radeon used to end like this: > (II) LoadModule: "int10" > (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a > (II) RADEON(0): initializing int10 > (**) RADEON(0): Option "InitPrimary" "on" > (II) Truncating PCI BIOS Length to 53248 > > The logs for secondary G550 ends like this, with or without int10 > (--) MGA(0): Pseudo-DMA transfer window at 0xF300 > (==) MGA(0): BIOS at 0xC > (WW) MGA(0): Video BIOS info block not detected! > (II) MGA(0): MGABios.RamdacType = 0x0 > (==) MGA(0): Write-combining range (0xf000,0x200) > (--) MGA(0): VideoRAM: 2048 kByte > (II) Loading sub module "ddc" > (II) LoadModule: "ddc" > (II) Reloading /usr/X11R6/lib/modules/libddc.a > (II) Loading sub module "i2c" > (II) LoadModule: "i2c" > (II) Loading /usr/X11R6/lib/modules/libi2c.a > (II) Module i2c: vendor="The XFree86 Project" > compiled for 4.3.0.1, module version = 1.2.0 > ABI class: XFree86 Video Driver, version 0.6 > (==) MGA(0): Write-combining range (0xf000,0x20) > (II) MGA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x > (II) MGA(0): I2C bus "DDC" initialized. > (II) MGA(0): I2C device "DDC:ddc2" registered at address 0xA0. > (II) MGA(0): I2C device "DDC:ddc2" removed. > (II) MGA(0): I2C Monitor info: (nil) > (II) MGA(0): end of I2C Monitor info > > The video bios is apparently not detected at all, and therefore not run. > > The kernel doesn't actually hang, only X gets stuck. sysrq+T > dumped stack traces for all tasks except the xserver. For X, > there was only one line identifying the xserver process and the fact > that it was Running. No stack dump. I managed to kill all tasks > and have init proceeding into init 2. > > So I wonder - is Debians X 4.3.0.1 buggy, or the kernel? > The fact remains that the newer kernels locks up while trying to use the > secondary radeon, while it actually works with 2.6.8.1. > > Well, actually 2.6.8.1 is a bit unstable once 3D stuff starts on the > radeon - but it is only the radeon xserver that locks up in an > infinite loop after a while. Other processes remain responsive. > > Helge Hafting > -- Jon Smirl [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 2.6.11-rc2 26/29] ide: map ide_cmd_ioctl() to ide_taskfile_ioctl()
On Wed, 2 Feb 2005 12:10:37 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> > 26_ide_taskfile_cmd_ioctl.patch
> >
> > ide_cmd_ioctl() converted to use ide_taskfile_ioctl(). This
> > is the last user of REQ_DRIVE_CMD.
ide_cmd_ioctl() needs to map to taskfile transport not ide_taskfile_ioctl()
> Index: linux-ide-export/drivers/ide/ide-iops.c
> ===
> --- linux-ide-export.orig/drivers/ide/ide-iops.c2005-02-02
> 10:28:04.466320918 +0900
> +++ linux-ide-export/drivers/ide/ide-iops.c 2005-02-02 10:28:07.406843817
> +0900
> @@ -648,11 +648,11 @@ u8 eighty_ninty_three (ide_drive_t *driv
>
> EXPORT_SYMBOL(eighty_ninty_three);
>
> -int ide_ata66_check (ide_drive_t *drive, ide_task_t *args)
> +int ide_ata66_check (ide_drive_t *drive, task_ioreg_t *regs)
nitpick: int ide_ata66_check()
> {
> - if ((args->tfRegister[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
> - (args->tfRegister[IDE_SECTOR_OFFSET] > XFER_UDMA_2) &&
> - (args->tfRegister[IDE_FEATURE_OFFSET] == SETFEATURES_XFER)) {
> + if ((regs[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
> + (regs[IDE_SECTOR_OFFSET] > XFER_UDMA_2) &&
> + (regs[IDE_FEATURE_OFFSET] == SETFEATURES_XFER)) {
nitpick: please drop brackets
> #ifndef CONFIG_IDEDMA_IVB
> if ((drive->id->hw_config & 0x6000) == 0) {
> #else /* !CONFIG_IDEDMA_IVB */
> @@ -678,11 +678,11 @@ int ide_ata66_check (ide_drive_t *drive,
> * 1 : Safe to update drive->id DMA registers.
> * 0 : OOPs not allowed.
> */
> -int set_transfer (ide_drive_t *drive, ide_task_t *args)
> +int set_transfer (ide_drive_t *drive, task_ioreg_t *regs)
nitpick: int set_transfer()
> {
> - if ((args->tfRegister[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
> - (args->tfRegister[IDE_SECTOR_OFFSET] >= XFER_SW_DMA_0) &&
> - (args->tfRegister[IDE_FEATURE_OFFSET] == SETFEATURES_XFER) &&
> + if ((regs[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
> + (regs[IDE_SECTOR_OFFSET] >= XFER_SW_DMA_0) &&
> + (regs[IDE_FEATURE_OFFSET] == SETFEATURES_XFER) &&
nitpick: brackets
> (drive->id->dma_ultra ||
> drive->id->dma_mword ||
> drive->id->dma_1word))
> Index: linux-ide-export/drivers/ide/ide-taskfile.c
> ===
> --- linux-ide-export.orig/drivers/ide/ide-taskfile.c2005-02-02
> 10:28:06.751950074 +0900
> +++ linux-ide-export/drivers/ide/ide-taskfile.c 2005-02-02 10:28:07.407843655
> +0900
> @@ -704,78 +704,90 @@ abort:
> return err;
> }
>
> -int ide_wait_cmd (ide_drive_t *drive, u8 cmd, u8 nsect, u8 feature, u8
> sectors, u8 *buf)
> -{
> - struct request rq;
> - u8 buffer[4];
> -
> - if (!buf)
> - buf = buffer;
> - memset(buf, 0, 4 + SECTOR_WORDS * 4 * sectors);
> - ide_init_drive_cmd();
> - rq.buffer = buf;
> - *buf++ = cmd;
> - *buf++ = nsect;
> - *buf++ = feature;
> - *buf++ = sectors;
> - return ide_do_drive_cmd(drive, , ide_wait);
> -}
> -
> -/*
> - * FIXME : this needs to map into at taskfile. <[EMAIL PROTECTED]>
> - */
> int ide_cmd_ioctl (ide_drive_t *drive, unsigned int cmd, unsigned long arg)
> {
> - int err = 0;
> - u8 args[4], *argbuf = args;
> + u8 args[4];
> + ide_task_request_t *task_req;
> + task_ioreg_t *io_ports;
> u8 xfer_rate = 0;
> - int argsize = 4;
> - ide_task_t tfargs;
> + mm_segment_t orig_fs;
> + int in_size, ret;
>
> - if (NULL == (void *) arg) {
> + if ((void *)arg == NULL) {
> struct request rq;
> ide_init_drive_cmd();
> + rq.flags = REQ_DRIVE_TASKFILE;
> return ide_do_drive_cmd(drive, , ide_wait);
> }
>
> if (copy_from_user(args, (void __user *)arg, 4))
> return -EFAULT;
>
> - memset(, 0, sizeof(ide_task_t));
> - tfargs.tfRegister[IDE_FEATURE_OFFSET] = args[2];
> - tfargs.tfRegister[IDE_NSECTOR_OFFSET] = args[3];
> - tfargs.tfRegister[IDE_SECTOR_OFFSET] = args[1];
> - tfargs.tfRegister[IDE_LCYL_OFFSET]= 0x00;
> - tfargs.tfRegister[IDE_HCYL_OFFSET]= 0x00;
> - tfargs.tfRegister[IDE_SELECT_OFFSET] = 0x00;
> - tfargs.tfRegister[IDE_COMMAND_OFFSET] = args[0];
> -
> - if (args[3]) {
> - argsize = 4 + (SECTOR_WORDS * 4 * args[3]);
> - argbuf = kmalloc(argsize, GFP_KERNEL);
> - if (argbuf == NULL)
> - return -ENOMEM;
> - memcpy(argbuf, args, 4);
> + in_size = 4 * SECTOR_WORDS * args[3];
> +
> + task_req = kmalloc(sizeof(*task_req) + in_size, GFP_KERNEL);
> + if (task_req == NULL)
> + return -ENOMEM;
> +
> + memset(task_req, 0, sizeof(*task_req) + in_size);
> +
> +
slowdown with 2.6.10 when using NFS client
This is with the fedora kernel 2.6.10-1.760_FC3smp I've reproduced this on 2 SMP systems with different NFS servers and several Fedora 2.6.10 kernels. I could not reproduce the problem with a non-SMP kernel or a 2.4 kernel. I have not tried with a pre 2.6.10 kernel. I think some others have seen similar things in this old thread: http://lkml.org/lkml/2005/1/17/201 Running john the ripper (dictionary password cracker) from an NFS mounted directory causes the system to become very sluggish. Copying the same directory to local disk and running john from there, the system runs smoothly. In an NFS mounted dir I start "vmstat 1", then start "./john -restore", and then kill john after a few seconds. vmstat output follows. sy cpu time looks interesting to me. procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 0 0 0 1828124 28636 142444008017 27972 2 2 93 3 0 0 0 1828124 28636 14244400 0 0 111554 0 0 100 0 0 0 0 1828124 28636 14244400 0 0 100516 0 0 100 0 0 0 0 1828124 28636 14244400 0 0 111946 0 0 100 0 0 0 0 1828124 28636 14244400 0 0 102732 0 0 100 0 0 0 0 1827996 28644 14243600 036 110740 0 0 100 0 0 1 0 1827996 28644 14243600 0 4 101326 0 0 100 0 0 0 0 1828060 28644 14243600 0 0 111957 0 0 100 0 0 0 0 1828060 28644 14243600 0 0 104242 0 0 100 0 0 0 0 1827932 28644 14243600 0 0 110947 0 0 100 0 0 0 0 1827932 28644 14243600 0 0 102948 0 0 100 0 0 1 0 1827932 28652 14242800 016 110640 0 0 100 0 0 0 0 1827932 28652 14242800 0 0 100620 0 0 100 0 2 0 0 1822804 28652 14294800 0 0 2080 296 9 9 82 0 2 0 0 1822804 28652 14294800 0 0 100610 25 0 75 0 1 0 0 1822804 28652 14294800 0 0 107530 25 23 51 0 1 0 0 1822804 28652 14294800 0 0 103728 25 23 52 0 2 0 0 1822804 28652 14294800 0 0 106125 25 14 61 0 1 0 0 1822812 28660 14294000 024 105025 25 32 43 0 2 0 0 1822812 28660 14294000 0 0 103317 25 18 57 0 2 0 0 1822812 28660 14294000 0 0 107832 25 17 59 0 1 0 0 1822748 28660 14294000 0 0 110540 25 16 59 0 3 0 0 1822748 28660 14294000 0 0 126317 25 52 23 0 1 0 0 1822684 28660 14294000 0 0 130341 25 21 54 0 2 0 0 1822684 28660 14294000 0 0 116515 25 25 50 0 2 0 0 1822684 28660 14294000 0 0 124026 25 6 69 0 0 0 0 1826964 28668 14293200 020 124279 7 12 80 0 0 0 0 1826964 28668 14293200 0 0 101422 0 0 100 0 0 0 0 1826964 28668 14293200 0 0 110842 0 0 100 0 If I then copy the same directory to local disk (/tmp) and do the same thing, system has no slowdown, vmstat looks like: procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 0 0 0 1809692 28812 159688006517 28162 2 2 93 3 0 0 0 1809692 28812 15968800 0 0 110736 0 0 100 0 0 0 0 1809692 28820 15968000 076 101120 0 0 99 1 0 0 0 1809692 28820 15968000 0 0 111360 0 0 100 0 0 0 0 1809756 28820 15968000 0 0 101832 0 0 100 0 0 0 0 1809756 28820 15968000 0 0 40 0 0 100 0 0 0 0 1809756 28820 15968000 0 0 100618 0 0 100 0 0 1 0 1809756 28824 15967600 016 110540 0 0 100 0 0 0 0 1809756 28828 15967200 0 8 101722 0 0 100 0 0 0 0 1809756 28828 15967200 0 0 110430 0 0 100 0 0 0 0 1809756 28828 15967200 0 0 100714 0 0 100 0 0 0 0 1809756 28828 15967200 0 0 110430 0 0 100 0 0 1 0 1809628 28832 15966800 020 101027 0 0 100 0 0 0 0 1809628 28836 15966400 0 100 114361 0 0 100 0 0 0 0 1809628 28836 15966400 0 0 101835 0 0 100 0 0 0 0 1809628 28836 15966400 0 0 112568 0 0 99 0 0 1 0 1808860 28836 15966400 0 8 101536 2 0 98 0 1 0 0 1805404 28852 15964800 056 111456 23 0 75 2 1
Re: [PATCH 2.6.11-rc3] IBM Trackpoint support
On Thu, 3 Feb 2005 22:52:44 -0500, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > OK, I have read the code once again, and saw that you have special > handling within PS/2 protocol based on model constant. Please set > psmouse type to PSMOUSE_TRACKPOINT instead of model and provide full > protocol handler, like ALPS, Synaptics and Logitech do. Trackpoint > is different and complex enough to warrant it. Thanks, I've made all the changes suggested and I'll incorporate this too. I'll send a new patch at the end of the weekend when I get back. Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e1000, sshd, and the infamous "Corrupted MAC on input"
Matt Mackall wrote: On Wed, Feb 02, 2005 at 10:44:14PM -0500, Ethan Weinstein wrote: ... Finally, I used a crossover cable between the two boxes, which resulted in the same error from sshd again. Well ssh isn't an especially good test as it's hard to debug. Try transferring large compressed files via netcat and comparing the results. eg: host1# nc -l -p 2000 > foo.bz2 host2# nc host1 2000 < foo.bz2 If the md5sums differ, follow up with a cmp -bl to see what changed. Then we can look at the failure patterns and determine if there's some data or alignment dependence. Excellent tip, thanks. I was able to reprodce the problem several times using this technique with nc, however the problem was intermittent (as nasty problems like this often are). I used a 1.3G gzipped tarball and experienced several botched transfers along with a few good ones. To be fair, I also switched back to 100Fdx and repeated; I didn't get a single failure at this speed over 25 or so runs. The results of two cmp's are here: http://www.stinkfoot.org/e1000tests.out What next? -Ethan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3] IBM Trackpoint support
On Thursday 03 February 2005 19:34, Dmitry Torokhov wrote:
> On Thursday 03 February 2005 17:43, Stephen Evanchik wrote:
> > Vojtech,
> >
> > Here is a patch that exposes the IBM TrackPoint's extended properties
> > as well as scroll wheel emulation.
> >
> >
>
> Hi,
>
> Very nice although I have a couple of comments.
>
> > /*
> > + * Try to initialize the IBM TrackPoint
> > + */
> > + if (max_proto > PSMOUSE_PS2 && trackpoint_init(psmouse) == 0) {
> > + psmouse->vendor = "IBM";
> > + psmouse->name = "TrackPoint";
> > +
> > + return PSMOUSE_PS2;
>
> Why PSMOUSE_PS2? Reconnect will surely not like it.
>
OK, I have read the code once again, and saw that you have special
handling within PS/2 protocol based on model constant. Please set
psmouse type to PSMOUSE_TRACKPOINT instead of model and provide full
protocol handler, like ALPS, Synaptics and Logitech do. Trackpoint
is different and complex enough to warrant it.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.10 dies when X uses G550
On Sun, Jan 30, 2005 at 12:05:27PM -0500, Jon Smirl wrote: > On Sun, 30 Jan 2005 17:32:41 +0100, Helge Hafting > <[EMAIL PROTECTED]> wrote: > > Yes, it is a PCI radeon. And the machine has an AGP slot > > too, which is used by a matrox G550. This AGP card was not > > used in the test, (other than being the VGA console). > > Note that there is no crash if I don't compile > > AGP support, so the crash is related to AGP somehow even though > > AGP is not supposed to be used in this case. > > Can you set the PCI card to be primary in your BIOS or remove the AGP > card, and then see if it works? It could be that X's video reset code > for secondary PCI cards is broken. > I tried this. I already reported that X came up on the radeon. I could not run X on the G550, now that it was "secondary", but the crash was different from the radeon crash. The logs with secondary radeon used to end like this: (II) LoadModule: "int10" (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a (II) RADEON(0): initializing int10 (**) RADEON(0): Option "InitPrimary" "on" (II) Truncating PCI BIOS Length to 53248 The logs for secondary G550 ends like this, with or without int10 (--) MGA(0): Pseudo-DMA transfer window at 0xF300 (==) MGA(0): BIOS at 0xC (WW) MGA(0): Video BIOS info block not detected! (II) MGA(0): MGABios.RamdacType = 0x0 (==) MGA(0): Write-combining range (0xf000,0x200) (--) MGA(0): VideoRAM: 2048 kByte (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Reloading /usr/X11R6/lib/modules/libddc.a (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Loading /usr/X11R6/lib/modules/libi2c.a (II) Module i2c: vendor="The XFree86 Project" compiled for 4.3.0.1, module version = 1.2.0 ABI class: XFree86 Video Driver, version 0.6 (==) MGA(0): Write-combining range (0xf000,0x20) (II) MGA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x (II) MGA(0): I2C bus "DDC" initialized. (II) MGA(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) MGA(0): I2C device "DDC:ddc2" removed. (II) MGA(0): I2C Monitor info: (nil) (II) MGA(0): end of I2C Monitor info The video bios is apparently not detected at all, and therefore not run. The kernel doesn't actually hang, only X gets stuck. sysrq+T dumped stack traces for all tasks except the xserver. For X, there was only one line identifying the xserver process and the fact that it was Running. No stack dump. I managed to kill all tasks and have init proceeding into init 2. So I wonder - is Debians X 4.3.0.1 buggy, or the kernel? The fact remains that the newer kernels locks up while trying to use the secondary radeon, while it actually works with 2.6.8.1. Well, actually 2.6.8.1 is a bit unstable once 3D stuff starts on the radeon - but it is only the radeon xserver that locks up in an infinite loop after a while. Other processes remain responsive. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/9] drive->nice1 fix
It is drive's property independent of the driver being used so move
drive->nice1 setup from ide_register_subdriver() to probe_hwif() in
ide-probe.c. As a result changing a driver which controls the drive
no longer affects this flag.
diff -Nru a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
--- a/drivers/ide/ide-probe.c 2005-02-04 03:30:55 +01:00
+++ b/drivers/ide/ide-probe.c 2005-02-04 03:30:55 +01:00
@@ -862,6 +862,13 @@
drive->autotune == IDE_TUNE_AUTO)
/* auto-tune PIO mode */
hwif->tuneproc(drive, 255);
+
+ if (drive->autotune != IDE_TUNE_DEFAULT &&
+ drive->autotune != IDE_TUNE_AUTO)
+ continue;
+
+ drive->nice1 = 1;
+
/*
* MAJOR HACK BARF :-/
*
@@ -871,9 +878,7 @@
* Move here to prevent module loading clashing.
*/
// drive->autodma = hwif->autodma;
- if ((hwif->ide_dma_check) &&
- ((drive->autotune == IDE_TUNE_DEFAULT) ||
- (drive->autotune == IDE_TUNE_AUTO))) {
+ if (hwif->ide_dma_check) {
/*
* Force DMAing for the beginning of the check.
* Some chipsets appear to do interesting
diff -Nru a/drivers/ide/ide.c b/drivers/ide/ide.c
--- a/drivers/ide/ide.c 2005-02-04 03:30:55 +01:00
+++ b/drivers/ide/ide.c 2005-02-04 03:30:55 +01:00
@@ -2033,7 +2033,6 @@
(drive->autotune == IDE_TUNE_AUTO)) {
/* DMA timings and setup moved to ide-probe.c */
drive->dsc_overlap = (drive->next != drive &&
driver->supports_dsc_overlap);
- drive->nice1 = 1;
}
#ifdef CONFIG_PROC_FS
if (drive->driver != _driver)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: fix pci_remove_legacy_files() crash
Hi,
The legacy_io which is the member of pci_bus struct might be
NULL. It should be checked.
This patch checks 'b->legacy_io', NULL or not.
Signed-off-by: MUNEDA Takahiro <[EMAIL PROTECTED]>
---
probe.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff -Npur a/drivers/pci/probe.c b/drivers/pci/probe.c
--- a/drivers/pci/probe.c 2005-01-31 13:31:27.0 +0900
+++ b/drivers/pci/probe.c 2005-02-03 11:21:51.0 +0900
@@ -64,9 +64,11 @@ static void pci_create_legacy_files(stru
void pci_remove_legacy_files(struct pci_bus *b)
{
- class_device_remove_bin_file(>class_dev, b->legacy_io);
- class_device_remove_bin_file(>class_dev, b->legacy_mem);
- kfree(b->legacy_io); /* both are allocated here */
+ if (b->legacy_io) {
+ class_device_remove_bin_file(>class_dev, b->legacy_io);
+ class_device_remove_bin_file(>class_dev, b->legacy_mem);
+ kfree(b->legacy_io); /* both are allocated here */
+ }
}
#else /* !HAVE_PCI_LEGACY */
static inline void pci_create_legacy_files(struct pci_bus *bus) { return; }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 8/9] kill ide-default
* add ide_drives list to list devices without a driver
* add __ide_add_setting() and use it for adding no auto remove entries
* kill ide-default pseudo-driver
diff -Nru a/drivers/ide/Makefile b/drivers/ide/Makefile
--- a/drivers/ide/Makefile 2005-02-04 03:32:17 +01:00
+++ b/drivers/ide/Makefile 2005-02-04 03:32:17 +01:00
@@ -13,8 +13,7 @@
obj-$(CONFIG_BLK_DEV_IDE) += pci/
-ide-core-y += ide.o ide-default.o ide-io.o ide-iops.o ide-lib.o ide-probe.o \
- ide-taskfile.o
+ide-core-y += ide.o ide-io.o ide-iops.o ide-lib.o ide-probe.o ide-taskfile.o
ide-core-$(CONFIG_BLK_DEV_CMD640) += pci/cmd640.o
diff -Nru a/drivers/ide/ide-default.c b/drivers/ide/ide-default.c
--- a/drivers/ide/ide-default.c 2005-02-04 03:32:17 +01:00
+++ /dev/null Wed Dec 31 16:00:00 196900
@@ -1,76 +0,0 @@
-/*
- * ide-default - Driver for unbound ide devices
- *
- * This provides a clean way to bind a device to default operations
- * by having an actual driver class that rather than special casing
- * "no driver" all over the IDE code
- *
- * Copyright (C) 2003, Red Hat <[EMAIL PROTECTED]>
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-
-#define IDEDEFAULT_VERSION "0.9.newide"
-/*
- * Driver initialization.
- */
-
-static int idedefault_attach(ide_drive_t *drive);
-
-static ide_startstop_t idedefault_do_request(ide_drive_t *drive, struct
request *rq, sector_t block)
-{
- ide_end_request(drive, 0, 0);
- return ide_stopped;
-}
-
-/*
- * IDE subdriver functions, registered with ide.c
- */
-
-ide_driver_t idedefault_driver = {
- .name = "ide-default",
- .version= IDEDEFAULT_VERSION,
- .attach = idedefault_attach,
- .cleanup= ide_unregister_subdriver,
- .do_request = idedefault_do_request,
- .end_request= ide_end_request,
- .error = __ide_error,
- .abort = __ide_abort,
- .drives = LIST_HEAD_INIT(idedefault_driver.drives)
-};
-
-static int idedefault_attach (ide_drive_t *drive)
-{
- if (ide_register_subdriver(drive, _driver)) {
- printk(KERN_ERR "ide-default: %s: Failed to register the "
- "driver with ide.c\n", drive->name);
- return 1;
- }
-
- return 0;
-}
-
-MODULE_DESCRIPTION("IDE Default Driver");
-
-MODULE_LICENSE("GPL");
diff -Nru a/drivers/ide/ide-proc.c b/drivers/ide/ide-proc.c
--- a/drivers/ide/ide-proc.c2005-02-04 03:32:17 +01:00
+++ b/drivers/ide/ide-proc.c2005-02-04 03:32:17 +01:00
@@ -107,8 +107,6 @@
if (drive) {
unsigned short *val = (unsigned short *) page;
- BUG_ON(!drive->driver);
-
err = taskfile_lib_get_identify(drive, page);
if (!err) {
char *out = ((char *)page) + (SECTOR_WORDS * 4);
@@ -312,8 +310,11 @@
ide_driver_t*driver = drive->driver;
int len;
- len = sprintf(page, "%s version %s\n",
- driver->name, driver->version);
+ if (driver) {
+ len = sprintf(page, "%s version %s\n",
+ driver->name, driver->version);
+ } else
+ len = sprintf(page, "ide-default version 0.9.newide\n");
PROC_IDE_READ_RETURN(page,start,off,count,eof,len);
}
diff -Nru a/drivers/ide/ide.c b/drivers/ide/ide.c
--- a/drivers/ide/ide.c 2005-02-04 03:32:17 +01:00
+++ b/drivers/ide/ide.c 2005-02-04 03:32:17 +01:00
@@ -196,7 +196,7 @@
EXPORT_SYMBOL(ide_hwifs);
-extern ide_driver_t idedefault_driver;
+static struct list_head ide_drives = LIST_HEAD_INIT(ide_drives);
/*
* Do not even *think* about calling this!
@@ -245,7 +245,6 @@
drive->max_failures = IDE_DEFAULT_MAX_FAILURES;
drive->using_dma= 0;
drive->is_flash = 0;
- drive->driver = _driver;
drive->vdma = 0;
INIT_LIST_HEAD(>list);
sema_init(>gendev_rel_sem, 0);
@@ -917,7 +916,7 @@
DECLARE_MUTEX(ide_setting_sem);
/**
- * ide_add_setting - add an ide setting option
+ * __ide_add_setting - add an ide setting option
* @drive: drive to use
* @name: setting name
* @rw: true if the function is read write
@@ -930,6 +929,7 @@
* @div_factor: divison scale
* @data: private data field
* @set: setting
+ * @auto_remove: setting auto removal flag
*
* Removes the setting named from the device if it is present.
* The function takes the settings_lock to protect against
@@
Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi.
On Fri, 2005-02-04 at 13:35, Carl-Daniel Hailfinger wrote:
> Can we use call_usermodehelper at this early resume stage (before any
> video access)? Calling vm86 directly is probably not going to fly
> because we want to be shielded from any misbehaviour in the bios code
> and it may be necessary to kill the process running the bios code.
>
> Cases in point: My bios will cause the POSTing application to segfault.
> Others have reported the POSTing application just hangs, but the
> important things are done before the hang, so killing it after maybe
> 5 seconds would be ok.
Yuck!
> Rough outline how to do that without adding tons of code:
> We need a call_usermodehelper_from_ram_with_timeout for that.
>
> Kernel: Userspace:
> User wants to enter S3
> init_mutex_locked(s3_sem)
> call_usermodehelper("vesaposter")
> vesaposter calls LRMI_init
> vesaposter mlocks all its memory
> vesaposter calls into kernel
> and down(s3_sem)
> suspend vesafb
>
> User has triggered resume
> run wakeup.S
> thaw essential threads
> set a timer of 5 seconds
> up(s3_sem)
> thaw and schedule vesaposter
> wait for timer or vesaposter termination
> vesaposter returns from kernel
> vesaposter posts video card
> vesaposter terminates
> resume vesafb
> continue resume
>
> Problems with that approach:
> - vesaposter has to be locked in memory to avoid disk accesses
That's no biggie.
> - vesafb has to refrain from touching video until after POST
Which is why I think we should do the post asap (as you have). What is
counted as an essential thread?
> - the vesaposter thread has to be the first unfrozen and
> scheduled and completed thread. Only after that we can resume
> vesafb and other threads
All other threads will be frozen, and we don't have scheduler hooks that
will hang up our new kiddie, so we should be right there.
> - the locking will be tricky
But also simplified by the fact that everything else is frozen.
> Advantages:
> - the problems all seem to be solvable easily
> - security and stability are similar to the current userspace code
> - we can use vesafb on such machines
> - the kernel code won't be much more than two dozen lines
> - the userspace POSTing code can be upgraded without the need
> for kernel updates (no policy in the kernel)
>
> What do you think?
Show us some code :>
Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 9/9] convert device drivers to driver-model
* add ide_bus_match() and export ide_bus_type
* split ide_remove_driver_from_hwgroup() out of ide_unregister()
* move device cleanup from ide_unregister() to drive_release_dev()
* convert ide_driver_t->name to driver->name
* convert ide_driver_t->{attach,cleanup} to driver->{probe,remove}
* remove ide_driver_t->busy as ide_bus_type->subsys.rwsem
protects against concurrent ->{probe,remove} calls
* make ide_{un}register_driver() void as it cannot fail now
* use driver_{un}register() directly, remove ide_{un}register_driver()
* use device_register() instead of ata_attach(), remove ata_attach()
* add proc_print_driver() and ide_drivers_show(), remove ide_drivers_op
* fix ide_replace_subdriver() and move it to ide-proc.c
* remove ide_driver_t->drives, ide_drives and drives_lock
* remove ide_driver_t->drivers, drivers and drivers_lock
* remove ide_drive_t->driver and DRIVER() macro
diff -Nru a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
--- a/drivers/ide/ide-cd.c 2005-02-04 03:32:30 +01:00
+++ b/drivers/ide/ide-cd.c 2005-02-04 03:32:30 +01:00
@@ -3255,16 +3255,12 @@
return capacity * sectors_per_frame;
}
-static
-int ide_cdrom_cleanup(ide_drive_t *drive)
+static int ide_cd_remove(struct device *dev)
{
+ ide_drive_t *drive = to_ide_device(dev);
struct cdrom_info *info = drive->driver_data;
- if (ide_unregister_subdriver(drive)) {
- printk(KERN_ERR "%s: %s: failed to ide_unregister_subdriver\n",
- __FUNCTION__, drive->name);
- return 1;
- }
+ ide_unregister_subdriver(drive, info->driver);
del_gendisk(info->disk);
@@ -3297,7 +3293,7 @@
kfree(info);
}
-static int ide_cdrom_attach (ide_drive_t *drive);
+static int ide_cd_probe(struct device *);
#ifdef CONFIG_PROC_FS
static int proc_idecd_read_capacity
@@ -3320,19 +3316,20 @@
static ide_driver_t ide_cdrom_driver = {
.owner = THIS_MODULE,
- .name = "ide-cdrom",
+ .gen_driver = {
+ .name = "ide-cdrom",
+ .bus= _bus_type,
+ .probe = ide_cd_probe,
+ .remove = ide_cd_remove,
+ },
.version= IDECD_VERSION,
.media = ide_cdrom,
- .busy = 0,
.supports_dsc_overlap = 1,
- .cleanup= ide_cdrom_cleanup,
.do_request = ide_do_rw_cdrom,
.end_request= ide_end_request,
.error = __ide_error,
.abort = __ide_abort,
.proc = idecd_proc,
- .attach = ide_cdrom_attach,
- .drives = LIST_HEAD_INIT(ide_cdrom_driver.drives),
};
static int idecd_open(struct inode * inode, struct file * file)
@@ -3418,8 +3415,9 @@
module_param(ignore, charp, 0400);
MODULE_DESCRIPTION("ATAPI CD-ROM Driver");
-static int ide_cdrom_attach (ide_drive_t *drive)
+static int ide_cd_probe(struct device *dev)
{
+ ide_drive_t *drive = to_ide_device(dev);
struct cdrom_info *info;
struct gendisk *g;
struct request_sense sense;
@@ -3453,11 +3451,8 @@
ide_init_disk(g, drive);
- if (ide_register_subdriver(drive, _cdrom_driver)) {
- printk(KERN_ERR "%s: Failed to register the driver with
ide.c\n",
- drive->name);
- goto out_put_disk;
- }
+ ide_register_subdriver(drive, _cdrom_driver);
+
memset(info, 0, sizeof (struct cdrom_info));
kref_init(>kref);
@@ -3470,7 +3465,6 @@
drive->driver_data = info;
- DRIVER(drive)->busy++;
g->minors = 1;
snprintf(g->devfs_name, sizeof(g->devfs_name),
"%s/cd", drive->devfs_name);
@@ -3478,8 +3472,7 @@
g->flags = GENHD_FL_CD | GENHD_FL_REMOVABLE;
if (ide_cdrom_setup(drive)) {
struct cdrom_device_info *devinfo = >devinfo;
- DRIVER(drive)->busy--;
- ide_unregister_subdriver(drive);
+ ide_unregister_subdriver(drive, _cdrom_driver);
if (info->buffer != NULL)
kfree(info->buffer);
if (info->toc != NULL)
@@ -3492,7 +3485,6 @@
drive->driver_data = NULL;
goto failed;
}
- DRIVER(drive)->busy--;
cdrom_read_toc(drive, );
g->fops = _ops;
@@ -3500,8 +3492,6 @@
add_disk(g);
return 0;
-out_put_disk:
- put_disk(g);
out_free_cd:
kfree(info);
failed:
@@ -3510,13 +3500,12 @@
static void __exit ide_cdrom_exit(void)
{
- ide_unregister_driver(_cdrom_driver);
+ driver_unregister(_cdrom_driver.gen_driver);
}
static int ide_cdrom_init(void)
{
- ide_register_driver(_cdrom_driver);
- return 0;
+ return
Re: [PATCH] s390: qeth network driver
Linux Kernel Mailing List wrote: ChangeSet 1.2072, 2005/02/03 17:04:37-08:00, [EMAIL PROTECTED] [PATCH] s390: qeth network driver From: Steffen Thoss <[EMAIL PROTECTED]> From: Frank Pavlic <[EMAIL PROTECTED]> qeth network driver changes: - Improve performance by omitting svs. - Use function callback mechanism to set layer 2 parameters when getting a reply for a Layer 2 command. - dev->hard_header must not be NULL when fake_ll is no set since IPv6 and Layer2 needs the default function set by network stack. - ping6 works now when running in layer 2 mode. - Save original dev->hard_header to restore it when the user doesn't want to use fake_ll anymore. - Fake ethernet header in outgoing packets. This currently works only if qeth is compiled without ipv6 support. - Add more debug information in case of failures in qeth_set_offline. - Using fake_ll with HiperSockets devices results in misaligned ip packets and thus no traffic over HiperSockets. - Start qeth_remove_device only after the qeth recovery completed. Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> It would be nice if this stuff was CC'd to the network, and network driver maintainers. Two immediate concerns I have are, * saving and restoring dev->hard_header is more than a little bit of a hack * overall, I'm not so sure IPv6 support should be conditionalized on anything but CONFIG_IPV6. Though S/390 and qeth are certainly unusual cases, none of the other net drivers in the kernel require a special config option to enable IPv6 support. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 7/9] get driver from rq->rq_disk->private_data
* add ide_driver_t * to device drivers objects
* set it to point at driver's ide_driver_t
* store address of this entry in disk->private_data
* fix ide_{cd,disk,floppy,tape,scsi}_g accordingly
* use rq->rq_disk->private_data instead of drive->driver
to obtain driver (this allows us to kill ide-default)
diff -Nru a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
--- a/drivers/ide/ide-cd.c 2005-02-04 03:31:58 +01:00
+++ b/drivers/ide/ide-cd.c 2005-02-04 03:31:58 +01:00
@@ -328,7 +328,8 @@
#define to_ide_cd(obj) container_of(obj, struct cdrom_info, kref)
-#define ide_cd_g(disk) ((disk)->private_data)
+#define ide_cd_g(disk) \
+ container_of((disk)->private_data, struct cdrom_info, driver)
static struct cdrom_info *ide_cd_get(struct gendisk *disk)
{
@@ -3462,8 +3463,11 @@
kref_init(>kref);
info->drive = drive;
+ info->driver = _cdrom_driver;
info->disk = g;
+ g->private_data = >driver;
+
drive->driver_data = info;
DRIVER(drive)->busy++;
@@ -3492,7 +3496,6 @@
cdrom_read_toc(drive, );
g->fops = _ops;
- g->private_data = info;
g->flags |= GENHD_FL_REMOVABLE;
add_disk(g);
return 0;
diff -Nru a/drivers/ide/ide-cd.h b/drivers/ide/ide-cd.h
--- a/drivers/ide/ide-cd.h 2005-02-04 03:31:58 +01:00
+++ b/drivers/ide/ide-cd.h 2005-02-04 03:31:58 +01:00
@@ -461,6 +461,7 @@
/* Extra per-device info for cdrom drives. */
struct cdrom_info {
ide_drive_t *drive;
+ ide_driver_t*driver;
struct gendisk *disk;
struct kref kref;
diff -Nru a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
--- a/drivers/ide/ide-disk.c2005-02-04 03:31:58 +01:00
+++ b/drivers/ide/ide-disk.c2005-02-04 03:31:58 +01:00
@@ -73,6 +73,7 @@
struct ide_disk_obj {
ide_drive_t *drive;
+ ide_driver_t*driver;
struct gendisk *disk;
struct kref kref;
};
@@ -81,7 +82,8 @@
#define to_ide_disk(obj) container_of(obj, struct ide_disk_obj, kref)
-#define ide_disk_g(disk) ((disk)->private_data)
+#define ide_disk_g(disk) \
+ container_of((disk)->private_data, struct ide_disk_obj, driver)
static struct ide_disk_obj *ide_disk_get(struct gendisk *disk)
{
@@ -1179,8 +1181,11 @@
kref_init(>kref);
idkp->drive = drive;
+ idkp->driver = _driver;
idkp->disk = g;
+ g->private_data = >driver;
+
drive->driver_data = idkp;
DRIVER(drive)->busy++;
@@ -1198,7 +1203,6 @@
g->flags = drive->removable ? GENHD_FL_REMOVABLE : 0;
set_capacity(g, idedisk_capacity(drive));
g->fops = _ops;
- g->private_data = idkp;
add_disk(g);
return 0;
diff -Nru a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
--- a/drivers/ide/ide-dma.c 2005-02-04 03:31:58 +01:00
+++ b/drivers/ide/ide-dma.c 2005-02-04 03:31:58 +01:00
@@ -175,8 +175,10 @@
if (OK_STAT(stat,DRIVE_READY,drive->bad_wstat|DRQ_STAT)) {
if (!dma_stat) {
struct request *rq = HWGROUP(drive)->rq;
+ ide_driver_t *drv;
- DRIVER(drive)->end_request(drive, 1, rq->nr_sectors);
+ drv = *(ide_driver_t **)rq->rq_disk->private_data;;
+ drv->end_request(drive, 1, rq->nr_sectors);
return ide_stopped;
}
printk(KERN_ERR "%s: dma_intr: bad DMA status (dma_stat=%x)\n",
diff -Nru a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
--- a/drivers/ide/ide-floppy.c 2005-02-04 03:31:58 +01:00
+++ b/drivers/ide/ide-floppy.c 2005-02-04 03:31:58 +01:00
@@ -276,6 +276,7 @@
*/
typedef struct ide_floppy_obj {
ide_drive_t *drive;
+ ide_driver_t*driver;
struct gendisk *disk;
struct kref kref;
@@ -520,7 +521,8 @@
#define to_ide_floppy(obj) container_of(obj, struct ide_floppy_obj, kref)
-#define ide_floppy_g(disk) ((disk)->private_data)
+#define ide_floppy_g(disk) \
+ container_of((disk)->private_data, struct ide_floppy_obj, driver)
static struct ide_floppy_obj *ide_floppy_get(struct gendisk *disk)
{
@@ -2160,8 +2162,11 @@
kref_init(>kref);
floppy->drive = drive;
+ floppy->driver = _driver;
floppy->disk = g;
+ g->private_data = >driver;
+
drive->driver_data = floppy;
DRIVER(drive)->busy++;
@@ -2172,7 +2177,6 @@
strcpy(g->devfs_name, drive->devfs_name);
g->flags = drive->removable ? GENHD_FL_REMOVABLE : 0;
g->fops = _ops;
- g->private_data = floppy;
drive->attach = 1;
add_disk(g);
return 0;
diff -Nru a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
--- a/drivers/ide/ide-io.c 2005-02-04 03:31:58 +01:00
+++ b/drivers/ide/ide-io.c 2005-02-04 03:31:58 +01:00
@@ -539,6 +539,17 @@
}
}
+static void ide_kill_rq(ide_drive_t *drive, struct request *rq)
+{
+ if
[patch 6/9] kill ide_drive_t->disk
* move ->disk from ide_drive_t to driver specific objects
* make drivers allocate struct gendisk and setup rq->rq_disk
(there is no need to do this for REQ_DRIVE_TASKFILE requests)
* add ide_init_disk() helper and kill alloc_disks() in ide-probe.c
* kill no longer needed ide_open() and ide_fops[] in ide.c
diff -Nru a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
--- a/drivers/ide/ide-cd.c 2005-02-04 03:31:46 +01:00
+++ b/drivers/ide/ide-cd.c 2005-02-04 03:31:46 +01:00
@@ -556,10 +556,13 @@
/*
* Initialize a ide-cd packet command request
*/
-static void cdrom_prepare_request(struct request *rq)
+static void cdrom_prepare_request(ide_drive_t *drive, struct request *rq)
{
+ struct cdrom_info *cd = drive->driver_data;
+
ide_init_drive_cmd(rq);
rq->flags = REQ_PC;
+ rq->rq_disk = cd->disk;
}
static void cdrom_queue_request_sense(ide_drive_t *drive, void *sense,
@@ -572,7 +575,7 @@
sense = >sense_data;
/* stuff the sense request in front of our current request */
- cdrom_prepare_request(rq);
+ cdrom_prepare_request(drive, rq);
rq->data = sense;
rq->cmd[0] = GPCMD_REQUEST_SENSE;
@@ -1856,7 +1859,7 @@
static ide_startstop_t cdrom_start_write(ide_drive_t *drive, struct request
*rq)
{
struct cdrom_info *info = drive->driver_data;
- struct gendisk *g = drive->disk;
+ struct gendisk *g = info->disk;
unsigned short sectors_per_frame = queue_hardsect_size(drive->queue) >>
SECTOR_BITS;
/*
@@ -2048,7 +2051,7 @@
struct cdrom_info *info = drive->driver_data;
struct cdrom_device_info *cdi = >devinfo;
- cdrom_prepare_request();
+ cdrom_prepare_request(drive, );
req.sense = sense;
req.cmd[0] = GPCMD_TEST_UNIT_READY;
@@ -2080,7 +2083,7 @@
if (CDROM_CONFIG_FLAGS(drive)->no_doorlock) {
stat = 0;
} else {
- cdrom_prepare_request();
+ cdrom_prepare_request(drive, );
req.sense = sense;
req.cmd[0] = GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL;
req.cmd[4] = lockflag ? 1 : 0;
@@ -2124,7 +2127,7 @@
if (CDROM_STATE_FLAGS(drive)->door_locked && ejectflag)
return 0;
- cdrom_prepare_request();
+ cdrom_prepare_request(drive, );
/* only tell drive to close tray if open, if it can do that */
if (ejectflag && !CDROM_CONFIG_FLAGS(drive)->close_tray)
@@ -2148,7 +2151,7 @@
int stat;
struct request req;
- cdrom_prepare_request();
+ cdrom_prepare_request(drive, );
req.sense = sense;
req.cmd[0] = GPCMD_READ_CDVD_CAPACITY;
@@ -2171,7 +2174,7 @@
{
struct request req;
- cdrom_prepare_request();
+ cdrom_prepare_request(drive, );
req.sense = sense;
req.data = buf;
@@ -2228,7 +2231,7 @@
if (stat)
toc->capacity = 0x1f;
- set_capacity(drive->disk, toc->capacity * sectors_per_frame);
+ set_capacity(info->disk, toc->capacity * sectors_per_frame);
blk_queue_hardsect_size(drive->queue,
sectors_per_frame << SECTOR_BITS);
@@ -2348,7 +2351,7 @@
stat = cdrom_get_last_written(cdi, _written);
if (!stat && (last_written > toc->capacity)) {
toc->capacity = last_written;
- set_capacity(drive->disk, toc->capacity * sectors_per_frame);
+ set_capacity(info->disk, toc->capacity * sectors_per_frame);
}
/* Remember that we've read this stuff. */
@@ -2363,7 +2366,7 @@
{
struct request req;
- cdrom_prepare_request();
+ cdrom_prepare_request(drive, );
req.sense = sense;
req.data = buf;
@@ -2383,7 +2386,7 @@
struct request_sense *sense)
{
struct request req;
- cdrom_prepare_request();
+ cdrom_prepare_request(drive, );
req.sense = sense;
if (speed == 0)
@@ -2413,7 +2416,7 @@
struct request_sense sense;
struct request req;
- cdrom_prepare_request();
+ cdrom_prepare_request(drive, );
req.sense =
req.cmd[0] = GPCMD_PLAY_AUDIO_MSF;
@@ -2463,7 +2466,7 @@
/* here we queue the commands from the uniform CD-ROM
layer. the packet must be complete, as we do not
touch it at all. */
- cdrom_prepare_request();
+ cdrom_prepare_request(drive, );
memcpy(req.cmd, cgc->cmd, CDROM_PACKET_SIZE);
if (cgc->sense)
memset(cgc->sense, 0, sizeof(struct request_sense));
@@ -2613,7 +2616,7 @@
struct request req;
int ret;
- cdrom_prepare_request();
+ cdrom_prepare_request(drive, );
req.flags = REQ_SPECIAL | REQ_QUIET;
ret = ide_do_drive_cmd(drive, , ide_wait);
@@ -2857,7 +2860,7 @@
if (!CDROM_CONFIG_FLAGS(drive)->mo_drive)
devinfo->mask |=
[patch 4/9] destroy_proc_ide_device() cleanup
When this function is called device is already unbinded from a
driver so there are no driver /proc entries to remove.
diff -Nru a/drivers/ide/ide-proc.c b/drivers/ide/ide-proc.c
--- a/drivers/ide/ide-proc.c2005-02-04 03:31:24 +01:00
+++ b/drivers/ide/ide-proc.c2005-02-04 03:31:24 +01:00
@@ -421,10 +421,7 @@
static void destroy_proc_ide_device(ide_hwif_t *hwif, ide_drive_t *drive)
{
- ide_driver_t *driver = drive->driver;
-
if (drive->proc) {
- ide_remove_proc_entries(drive->proc, driver->proc);
ide_remove_proc_entries(drive->proc, generic_drive_entries);
remove_proc_entry(drive->name, proc_ide_root);
remove_proc_entry(drive->name, hwif->proc);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 5/9] add ide_{un}register_region()
Add ide_{un}register_region() and fix ide-{tape,scsi}.c to register
block device number ranges. In ata_probe() only probe for modules.
Behavior is unchanged because:
* if driver is already loaded and attached to drive ata_probe()
is not called et all
* if driver is loaded by ata_probe() it will register new number range
for a drive and this range will be found by kobj_lookup()
If this is not clear please read http://lwn.net/Articles/25711/
and see drivers/base/map.c.
This patch makes it possible to move drive->disk allocation from
ide-probe.c to device drivers.
diff -Nru a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
--- a/drivers/ide/ide-probe.c 2005-02-04 03:31:35 +01:00
+++ b/drivers/ide/ide-probe.c 2005-02-04 03:31:35 +01:00
@@ -1214,8 +1214,6 @@
return 0;
}
-extern ide_driver_t idedefault_driver;
-
static struct kobject *ata_probe(dev_t dev, int *part, void *data)
{
ide_hwif_t *hwif = data;
@@ -1223,23 +1221,52 @@
ide_drive_t *drive = >drives[unit];
if (!drive->present)
return NULL;
- if (drive->driver == _driver) {
- if (drive->media == ide_disk)
- (void) request_module("ide-disk");
- if (drive->scsi)
- (void) request_module("ide-scsi");
- if (drive->media == ide_cdrom || drive->media == ide_optical)
- (void) request_module("ide-cd");
- if (drive->media == ide_tape)
- (void) request_module("ide-tape");
- if (drive->media == ide_floppy)
- (void) request_module("ide-floppy");
- }
- if (drive->driver == _driver)
- return NULL;
+
+ if (drive->media == ide_disk)
+ request_module("ide-disk");
+ if (drive->scsi)
+ request_module("ide-scsi");
+ if (drive->media == ide_cdrom || drive->media == ide_optical)
+ request_module("ide-cd");
+ if (drive->media == ide_tape)
+ request_module("ide-tape");
+ if (drive->media == ide_floppy)
+ request_module("ide-floppy");
+
+ return NULL;
+}
+
+static struct kobject *exact_match(dev_t dev, int *part, void *data)
+{
+ struct gendisk *p = data;
*part &= (1 << PARTN_BITS) - 1;
- return get_disk(drive->disk);
+ return >kobj;
}
+
+static int exact_lock(dev_t dev, void *data)
+{
+ struct gendisk *p = data;
+
+ if (!get_disk(p))
+ return -1;
+ return 0;
+}
+
+void ide_register_region(struct gendisk *disk)
+{
+ blk_register_region(MKDEV(disk->major, disk->first_minor),
+ disk->minors, NULL, exact_match, exact_lock, disk);
+}
+
+EXPORT_SYMBOL_GPL(ide_register_region);
+
+void ide_unregister_region(struct gendisk *disk)
+{
+ blk_unregister_region(MKDEV(disk->major, disk->first_minor),
+ disk->minors);
+}
+
+EXPORT_SYMBOL_GPL(ide_unregister_region);
static int alloc_disks(ide_hwif_t *hwif)
{
diff -Nru a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
--- a/drivers/ide/ide-tape.c2005-02-04 03:31:35 +01:00
+++ b/drivers/ide/ide-tape.c2005-02-04 03:31:35 +01:00
@@ -4680,6 +4680,8 @@
DRIVER(drive)->busy = 0;
(void) ide_unregister_subdriver(drive);
+ ide_unregister_region(drive->disk);
+
ide_tape_put(tape);
return 0;
@@ -4871,6 +4873,7 @@
g->number = devfs_register_tape(drive->devfs_name);
g->fops = _block_ops;
g->private_data = tape;
+ ide_register_region(g);
return 0;
failed:
diff -Nru a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
--- a/drivers/scsi/ide-scsi.c 2005-02-04 03:31:35 +01:00
+++ b/drivers/scsi/ide-scsi.c 2005-02-04 03:31:35 +01:00
@@ -723,6 +723,8 @@
if (ide_unregister_subdriver(drive))
return 1;
+ ide_unregister_region(g);
+
/* FIXME: drive->driver_data shouldn't be used */
drive->driver_data = NULL;
/* FIXME: add driver's private struct gendisk */
@@ -1122,12 +1124,14 @@
idescsi_setup (drive, idescsi);
g->fops = _ops;
g->private_data = idescsi;
+ ide_register_region(g);
err = scsi_add_host(host, >gendev);
if (!err) {
scsi_scan_host(host);
return 0;
}
/* fall through on error */
+ ide_unregister_region(g);
ide_unregister_subdriver(drive);
}
diff -Nru a/include/linux/ide.h b/include/linux/ide.h
--- a/include/linux/ide.h 2005-02-04 03:31:35 +01:00
+++ b/include/linux/ide.h 2005-02-04 03:31:35 +01:00
@@ -1456,6 +1456,9 @@
extern void ide_hwif_release_regions(ide_hwif_t* hwif);
extern void ide_unregister (unsigned int index);
+void ide_register_region(struct gendisk *);
+void
[patch 3/9] drive->dsc_overlap fix
drive->dsc_overlap is supported only by ide-{cd,tape} drivers.
Add missing clearing of ->dsc_overlap to ide_{cd,tape}_release()
and move ->dsc_overlap setup from ide_register_subdriver() to
ide_cdrom_setup() (ide-tape enables it unconditionally).
diff -Nru a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
--- a/drivers/ide/ide-cd.c 2005-02-04 03:31:14 +01:00
+++ b/drivers/ide/ide-cd.c 2005-02-04 03:31:14 +01:00
@@ -3219,6 +3219,9 @@
*/
blk_queue_hardsect_size(drive->queue, CD_FRAMESIZE);
+ if (drive->autotune == IDE_TUNE_DEFAULT ||
+ drive->autotune == IDE_TUNE_AUTO)
+ drive->dsc_overlap = (drive->next != drive);
#if 0
drive->dsc_overlap = (HWIF(drive)->no_dsc) ? 0 : 1;
if (HWIF(drive)->no_dsc) {
@@ -3282,6 +3285,7 @@
if (devinfo->handle == drive && unregister_cdrom(devinfo))
printk(KERN_ERR "%s: %s failed to unregister device from the
cdrom "
"driver.\n", __FUNCTION__, drive->name);
+ drive->dsc_overlap = 0;
drive->driver_data = NULL;
blk_queue_prep_rq(drive->queue, NULL);
g->private_data = NULL;
diff -Nru a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
--- a/drivers/ide/ide-tape.c2005-02-04 03:31:14 +01:00
+++ b/drivers/ide/ide-tape.c2005-02-04 03:31:14 +01:00
@@ -4691,6 +4691,7 @@
ide_drive_t *drive = tape->drive;
struct gendisk *g = drive->disk;
+ drive->dsc_overlap = 0;
drive->driver_data = NULL;
devfs_remove("%s/mt", drive->devfs_name);
devfs_remove("%s/mtn", drive->devfs_name);
diff -Nru a/drivers/ide/ide.c b/drivers/ide/ide.c
--- a/drivers/ide/ide.c 2005-02-04 03:31:14 +01:00
+++ b/drivers/ide/ide.c 2005-02-04 03:31:14 +01:00
@@ -2029,11 +2029,6 @@
list_add_tail(>list, >drives);
spin_unlock(_lock);
// printk(KERN_INFO "%s: attached %s driver.\n", drive->name,
driver->name);
- if ((drive->autotune == IDE_TUNE_DEFAULT) ||
- (drive->autotune == IDE_TUNE_AUTO)) {
- /* DMA timings and setup moved to ide-probe.c */
- drive->dsc_overlap = (drive->next != drive &&
driver->supports_dsc_overlap);
- }
#ifdef CONFIG_PROC_FS
if (drive->driver != _driver)
ide_add_proc_entries(drive->proc, driver->proc, drive);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/9] ide-tape: fix character device ->open() vs ->cleanup() race
Similar to the same race but for the block device.
* store pointer to struct ide_tape_obj in idetape_chrdevs[]
* rename idetape_chrdevs[] to idetape_devs[] and kill idetape_chrdev_t
* add ide_tape_chrdev_get() for getting reference to the tape
* store tape pointer in file->private_data and fix all users of it
* fix idetape_chrdev_{open,release}() to get/put reference to the tape
diff -Nru a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
--- a/drivers/ide/ide-tape.c2005-02-04 03:30:44 +01:00
+++ b/drivers/ide/ide-tape.c2005-02-04 03:30:44 +01:00
@@ -1122,15 +1122,6 @@
#defineIDETAPE_ERROR_EOD 103
/*
- * idetape_chrdev_t provides the link between out character device
- * interface and our block device interface and the corresponding
- * ide_drive_t structure.
- */
-typedef struct {
- ide_drive_t *drive;
-} idetape_chrdev_t;
-
-/*
* The following is used to format the general configuration word of
* the ATAPI IDENTIFY DEVICE command.
*/
@@ -1286,7 +1277,21 @@
* The variables below are used for the character device interface.
* Additional state variables are defined in our ide_drive_t structure.
*/
-static idetape_chrdev_t idetape_chrdevs[MAX_HWIFS * MAX_DRIVES];
+static struct ide_tape_obj * idetape_devs[MAX_HWIFS * MAX_DRIVES];
+
+#define ide_tape_f(file) ((file)->private_data)
+
+static struct ide_tape_obj *ide_tape_chrdev_get(unsigned int i)
+{
+ struct ide_tape_obj *tape = NULL;
+
+ down(_ref_sem);
+ tape = idetape_devs[i];
+ if (tape)
+ kref_get(>kref);
+ up(_ref_sem);
+ return tape;
+}
/*
* Function declarations
@@ -3697,8 +3702,8 @@
static ssize_t idetape_chrdev_read (struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
- ide_drive_t *drive = file->private_data;
- idetape_tape_t *tape = drive->driver_data;
+ struct ide_tape_obj *tape = ide_tape_f(file);
+ ide_drive_t *drive = tape->drive;
ssize_t bytes_read,temp, actually_read = 0, rc;
#if IDETAPE_DEBUG_LOG
@@ -3756,8 +3761,8 @@
static ssize_t idetape_chrdev_write (struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
- ide_drive_t *drive = file->private_data;
- idetape_tape_t *tape = drive->driver_data;
+ struct ide_tape_obj *tape = ide_tape_f(file);
+ ide_drive_t *drive = tape->drive;
ssize_t retval, actually_written = 0;
/* The drive is write protected. */
@@ -4059,8 +4064,8 @@
*/
static int idetape_chrdev_ioctl (struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
- ide_drive_t *drive = file->private_data;
- idetape_tape_t *tape = drive->driver_data;
+ struct ide_tape_obj *tape = ide_tape_f(file);
+ ide_drive_t *drive = tape->drive;
struct mtop mtop;
struct mtget mtget;
struct mtpos mtpos;
@@ -4131,17 +4136,24 @@
if (i >= MAX_HWIFS * MAX_DRIVES)
return -ENXIO;
- drive = idetape_chrdevs[i].drive;
- tape = drive->driver_data;
- filp->private_data = drive;
- if (test_and_set_bit(IDETAPE_BUSY, >flags))
- return -EBUSY;
+ if (!(tape = ide_tape_chrdev_get(i)))
+ return -ENXIO;
+
+ drive = tape->drive;
+
+ filp->private_data = tape;
+
+ if (test_and_set_bit(IDETAPE_BUSY, >flags)) {
+ retval = -EBUSY;
+ goto out_put_tape;
+ }
+
retval = idetape_wait_ready(drive, 60 * HZ);
if (retval) {
clear_bit(IDETAPE_BUSY, >flags);
printk(KERN_ERR "ide-tape: %s: drive not ready\n", tape->name);
- return retval;
+ goto out_put_tape;
}
idetape_read_position(drive);
@@ -4165,7 +4177,8 @@
if ((filp->f_flags & O_ACCMODE) == O_WRONLY ||
(filp->f_flags & O_ACCMODE) == O_RDWR) {
clear_bit(IDETAPE_BUSY, >flags);
- return -EROFS;
+ retval = -EROFS;
+ goto out_put_tape;
}
}
@@ -4183,6 +4196,10 @@
idetape_restart_speed_control(drive);
tape->restart_speed_control_req = 0;
return 0;
+
+out_put_tape:
+ ide_tape_put(tape);
+ return retval;
}
static void idetape_write_release (ide_drive_t *drive, unsigned int minor)
@@ -4206,8 +4223,8 @@
*/
static int idetape_chrdev_release (struct inode *inode, struct file *filp)
{
- ide_drive_t *drive = filp->private_data;
- idetape_tape_t *tape;
+ struct ide_tape_obj *tape = ide_tape_f(filp);
+ ide_drive_t *drive = tape->drive;
idetape_pc_t pc;
unsigned int minor = iminor(inode);
@@ -4241,6 +4258,7 @@
}
}
clear_bit(IDETAPE_BUSY, >flags);
+ ide_tape_put(tape);
Re: [Fastboot] Re: kdump on non-boot cpu
Itsuro Oda <[EMAIL PROTECTED]> writes: > Hi, > > On 03 Feb 2005 02:58:02 -0700 > [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > > Itsuro Oda <[EMAIL PROTECTED]> writes: > > > > > Hi, > > > > > > This is not for kdump but an experience of our project(mkdump). > > > The dump kernel(not SMP config) boot hangs if machine_kexec() > > > excutes on non-boot CPU on x86_64 platform. > > > > ?? x86_64 is Opteron cpu, amd64, Intel cpu? > > Are the kernels running in 32bit or 64bit mode. I'm guessing > > SMP Opterons running in 32bit mode. > > SMP Opterons running in 64bit mode. (The normal kernel is SMP configed. > The dump kernel is not SMP configed.) The reason I was asking and assuming you had a 32bit kernel is that you were quoting pieces of arch/i386/kernel/crash.c instead of arch/x86_64/kernel/crash.c While the functionality can easily be transfered I didn't think any one had done that yet. > > Anyway one thing I want to do is actually drop the apic shutdown > > code altogether in this code path. > > It sounds nice. (if available) All that has to happen is to drop the x86-crash_shutdown-apic-shutdown.patch from Andrews tree. That patch just added the handful of lines that disabled the apics. Once I get a test case that someone can boot a kernel without disabling apics I will ask Andrew to drop the above mentioned patch. > > My best hunch is that your UP kernel is not getting interrupts. > > yes. It seems the timer interrupts is not comming up. > > > Any chance on getting a serial console boot log? > > > attached. both success case and unsuccess case. Thanks. > > I suspect it can be made to work if you compile your UP > > kernel with IOAPIC support. I do know the table parsers > > no longer complain about the configuration. > > with IOAPIC support. the config is attached. Ok. Thanks. This is a legitimate bug. And it is probably the reason I even care about the non-SMP interrupt case some days. The problem is that the kernel just assumes interrupts are setup in non-APIC mode when it starts booting, and quite possibly only the bootstrap cpu can see those interrupts. So I believe the fix needs to be to enable apics before we calibrate the delay timer. I'm not certain off the top of my head what that patch will look like but it should not be fundamentally hard. With that code in place we also don't need to do any APIC shutdown as the kernel knows enough to completely setup the apics. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] arp_queue: serializing unlink + kfree_skb
On Fri, 4 Feb 2005 10:50:44 +1100 Herbert Xu <[EMAIL PROTECTED]> wrote: > So the problem isn't as big as I thought which is good. sk_buff > is only in trouble because of the atomic_read optimisation which > really needs a memory barrier. > > However, instead of adding a memory barrier which makes the optimisation > less useful, let's just get rid of the atomic_read. See my other email, the atomic_read() should function just fine. If we see the count dropped to "1", whoever set it to "1" made sure that all outstanding memory operations (including things like __skb_unlink()) are globally visible before the atomic_dec_and_test() which put the thing to "1" from "2". (and we did use atomic_dec_and_test() since the refcount was not "1") Example, assuming skb->users is "2": cpu 0 cpu 1 __skb_unlink() kfree_skb() kfree_skb() If cpu 0 sees the count at "1", it will always see the __skb_unlink() as well. Either my logic is flawed (very possible, I am a pinhead) or something is amiss in the PPC atomic ops. I describe all of this more explicitly in my other email. I'm actually going through all the sparc64 chip manuals to make sure I have things correct in that implementation :-))) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
> OK that was the note I was about to send, but like I stated, it isn't a
> problem now that the timer interrupt is back to a hard interrupt. I just
> showing this to you so you can see the real problem. Maybe I'm missing
> something, and maybe I'm not. I'll try to write up something that shows
> the problem with the timer interrupt as a thread.
Well, I wrote something up and I found a test case that locks the
machine (on 2.6.11-rc2-V0.7.37-03). I've only tried this on
2.6.10-rc3-mm1, where it works. I don't have anymore time to look into
this today, so I haven't tried it on vanilla 2.6.11-rc2.
The attached file was going to be something that shows what happens when
you have two processes with a higher priority than the timer interrupt.
But unfortunately it locked up 36-03. I tried it on 37-03 too, and it
locked it up as well. But if I modify this program a little, it runs
fine on both.
Here's the case: I have two processes waiting on a semaphore to go to
zero. Once it does, they both run spin loops, where one sleeps, and the
other just spins for a duration. The parent of these processes, set
their priorities very high and then zeros the semaphore.
Here's the problem: If I raise the priorities of the processes before
zeroing the semaphore, the machine hangs. If I zero the semaphore
before raising the priorities, the program runs fine.
You would think that if the problem happened the other way around, it
could be just that one of the high priority spinners is starving
everything else. But the problem occurs if the spinners are SLEEPING!
Attached is the code that locks up the machine. I'd look into it but
I've already done my 16 hours today ;-)
-- Steve
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define __USE_GNU
#include
static int int_spinner (int i);
static int spinner (int i);
typedef int (*callfunc_t)(int);
#define NR_PROCS 2
pid_t pids[NR_PROCS];
callfunc_t dofunc[NR_PROCS] = {
int_spinner,
spinner,
};
key_t key;
int semid = -1;
int shmid = -1;
int *flags;
pid_t timer_pid;
int timer_prio;
void cleanup(void)
{
int i;
for (i=0; i < NR_PROCS; i++) {
if (pids[0])
kill(pids[i],SIGKILL);
}
if (semid >= 0)
semctl(semid, 0, IPC_RMID);
if (shmid >= 0)
shmctl(shmid, IPC_RMID, NULL);
}
void double_to_tv(double d, struct timeval *tv)
{
tv->tv_sec = (int)d;
tv->tv_usec = (int) ((d - (double)tv->tv_sec) * 100.0);
printf ("sec:%d usecs:%d\n",(int)tv->tv_sec,(int)tv->tv_usec);
}
void catchall(int sig)
{
cleanup();
psignal(sig,"Caught: ");
exit(-1);
}
static int compare_timeval(const struct timeval *a, const struct timeval *b)
{
return (a->tv_sec > b->tv_sec) ? 1 :
(a->tv_sec < b->tv_sec) ? -1:
(a->tv_usec > b->tv_usec) ? 1:
(a->tv_usec < b->tv_usec) ? -1:
0;
}
static void add_timeval(const struct timeval *a, const struct timeval *b, struct timeval *c)
{
c->tv_usec = a->tv_usec + b->tv_usec;
c->tv_sec = a->tv_sec + b->tv_sec;
while (c->tv_usec > 100) {
c->tv_usec -= 100;
c->tv_sec++;
}
}
static void sub_timeval(const struct timeval *a, const struct timeval *b, struct timeval *c)
{
c->tv_usec = a->tv_usec - b->tv_usec;
c->tv_sec = a->tv_sec - b->tv_sec;
while (c->tv_usec < 0) {
c->tv_usec += 100;
c->tv_sec--;
}
}
static int int_spinner(int i)
{
struct sembuf sops;
int semid;
struct timeval starttv;
struct timeval endtv;
struct timeval tv;
struct timeval lasttv;
struct timeval nexttv;
time_t t;
char timebuf[30];
unsigned long long starttsc, nowtsc;
memset(,0,sizeof(sops));
if ((semid = semget(key,1,0)) < 0) {
perror("semget");
return -1;
}
if ((shmid = shmget(key,30,0600)) < 0) {
perror("shmget");
return -1;
}
if ((flags = shmat(shmid, NULL, 0)) == (void*)-1) {
perror("shmat");
return -1;
}
printf("int_spinner %d grabbing waiting on sem\n",i);
if (semop(semid, , 1) < 0) {
perror("semop");
return -1;
}
printf("int_spinner %d got semaphore\n",i);
if (gettimeofday(,NULL) < 0) {
perror("gettimeofday");
return -1;
}
endtv.tv_sec = 10;
endtv.tv_usec = 0;
add_timeval(,,);
t = time(NULL);
ctime_r(,timebuf);
timebuf[strlen(timebuf)-1] = 0;
printf("spinner %d starting loop (%s)\n",i,timebuf);
lasttv = starttv;
nexttv = starttv;
nexttv.tv_sec += 3;
printf("A sleeping\n");
(*flags)++;
sleep(1);
printf("A a wake\n");
asm ("rdtsc" : "=A"(starttsc));
do {
asm ("rdtsc" : "=A"(nowtsc));
if (nowtsc - starttsc > 70ULL) {
printf("spinner %d now - start > 70\n",i);
break;
}
if (gettimeofday(,NULL) < 0) {
perror("gettimeofday (in loop)");
return -1;
}
if (compare_timeval(,) > 0) {
printf("A sleeping\n");
(*flags)++;
sleep(1);
printf("A a wake\n");
nexttv.tv_sec += 3;
}
sub_timeval(,,);
lasttv = tv;
} while(compare_timeval(,) > 0);
t = time(NULL);
ctime_r(,timebuf);
timebuf[strlen(timebuf)-1] = 0;
printf("spinner %d ended
[patch 0/9] convert IDE device drivers to driver model
Hi, Patches are against ide-dev-2.6 tree. #1-8 are IDE fixes/changes needed #9 is the actual conversion Bartlomiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi!
Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2005-02-04 at 09:54, Pavel Machek wrote:
>
>>Hi!
>>
>>
>Are you able to use framebuffer(radeonfb,1024x768) with this
>configuration or do you need to use plain vga-console for it to work?
No.
For a working framebuffer console you would have to perform the steps
my script does *before* the kernel tries to access the framebuffer
console after resume. Since this is not yet possible, you're out of
luck. If
- the vbestate utility was a kernel module or
>>>
>>>OK, I managed to track this down further.
>>>"vbetool post" should be equivalent to "acpi_sleep=s3_bios", but there
>>>are some differences. For me, that's easy to explain: "vbetool post"
>>>segfaults because it wants to access parts of the video bios which
>>>are no longer available. "acpi_sleep=s3_bios" suffers from the same
>>>problem, but it runs in real mode and can't recover :-(
>>>
>>>To alleviate that problem, the kernel could run the video bios in
>>>vm86 mode (like vbetool does by using lrmi). This would simplify
>>>the asm wakeup code and make video POST more reliable.
>>>
>>>Pavel, what do you think?
>>
>>Well, calling BIOS using vm86 is going to be quite a lot of code. If
>>it is self-contained and not too huge, it is probably okay. It should
>>help with quite a lot of cards, but who knows...
>>
>>Yes, it is probably worth trying.
>
> I'd love to see it too. Pavel, even if you don't want to merge it for a
> while, we can always incorporate it in the Suspend2 patches so it gets
> some testing. I know I'd try it on my i830 based Omnibook.
Can we use call_usermodehelper at this early resume stage (before any
video access)? Calling vm86 directly is probably not going to fly
because we want to be shielded from any misbehaviour in the bios code
and it may be necessary to kill the process running the bios code.
Cases in point: My bios will cause the POSTing application to segfault.
Others have reported the POSTing application just hangs, but the
important things are done before the hang, so killing it after maybe
5 seconds would be ok.
Rough outline how to do that without adding tons of code:
We need a call_usermodehelper_from_ram_with_timeout for that.
Kernel: Userspace:
User wants to enter S3
init_mutex_locked(s3_sem)
call_usermodehelper("vesaposter")
vesaposter calls LRMI_init
vesaposter mlocks all its memory
vesaposter calls into kernel
and down(s3_sem)
suspend vesafb
User has triggered resume
run wakeup.S
thaw essential threads
set a timer of 5 seconds
up(s3_sem)
thaw and schedule vesaposter
wait for timer or vesaposter termination
vesaposter returns from kernel
vesaposter posts video card
vesaposter terminates
resume vesafb
continue resume
Problems with that approach:
- vesaposter has to be locked in memory to avoid disk accesses
- vesafb has to refrain from touching video until after POST
- the vesaposter thread has to be the first unfrozen and
scheduled and completed thread. Only after that we can resume
vesafb and other threads
- the locking will be tricky
Advantages:
- the problems all seem to be solvable easily
- security and stability are similar to the current userspace code
- we can use vesafb on such machines
- the kernel code won't be much more than two dozen lines
- the userspace POSTing code can be upgraded without the need
for kernel updates (no policy in the kernel)
What do you think?
Regards,
Carl-Daniel
--
http://www.hailfinger.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] invalidate range of pages after direct IO write
Zach Brown <[EMAIL PROTECTED]> wrote:
>
> > I'll make that change and plop the patch into -mm, but we need to think
> > about the infinite-loop problem..
>
> I can try hacking together that macro and auditing pagevec_lookup()
> callers..
I'd be inclined to hold off on the macro until we actually get the
open-coded stuff right.. Sometimes the page lookup loops take an end+1
argument and sometimes they take an inclusive `end'. I think. That might
make it a bit messy.
How's this look?
- Don't look up more pages than we're going to use
- Don't test page->index until we've locked the page
- Check for the cursor wrapping at the end of the mapping.
--- 25/mm/truncate.c~invalidate-range-of-pages-after-direct-io-write-fix
2005-02-03 18:20:22.0 -0800
+++ 25-akpm/mm/truncate.c 2005-02-03 18:28:24.627796400 -0800
@@ -264,18 +264,14 @@ int invalidate_inode_pages2_range(struct
pagevec_init(, 0);
next = start;
while (next <= end &&
- !ret && pagevec_lookup(, mapping, next, PAGEVEC_SIZE)) {
+ !ret && pagevec_lookup(, mapping, next,
+ min(end - next, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
for (i = 0; !ret && i < pagevec_count(); i++) {
struct page *page = pvec.pages[i];
int was_dirty;
- if (page->index > end) {
- next = page->index;
- break;
- }
-
lock_page(page);
- if (page->mapping != mapping) { /* truncate race? */
+ if (page->mapping != mapping || page->index > end) {
unlock_page(page);
continue;
}
@@ -311,6 +307,8 @@ int invalidate_inode_pages2_range(struct
}
pagevec_release();
cond_resched();
+ if (next == 0)
+ break; /* The pgoff_t wrapped */
}
return ret;
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 26/29] ide: map ide_cmd_ioctl() to ide_taskfile_ioctl()
On Fri, 04 Feb 2005 11:11:57 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Wed, 2 Feb 2005 12:10:37 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> >
> >>>26_ide_taskfile_cmd_ioctl.patch
> >>>
> >>> ide_cmd_ioctl() converted to use ide_taskfile_ioctl(). This
> >>> is the last user of REQ_DRIVE_CMD.
> >
> >
> > ide_cmd_ioctl() needs to map to taskfile transport not ide_taskfile_ioctl()
> >
> >
> >>Index: linux-ide-export/drivers/ide/ide-iops.c
> >>===
> >>--- linux-ide-export.orig/drivers/ide/ide-iops.c2005-02-02
> >>10:28:04.466320918 +0900
> >>+++ linux-ide-export/drivers/ide/ide-iops.c 2005-02-02
> >>10:28:07.406843817 +0900
> >>@@ -648,11 +648,11 @@ u8 eighty_ninty_three (ide_drive_t *driv
> >>
> >> EXPORT_SYMBOL(eighty_ninty_three);
> >>
> >>-int ide_ata66_check (ide_drive_t *drive, ide_task_t *args)
> >>+int ide_ata66_check (ide_drive_t *drive, task_ioreg_t *regs)
> >
> >
> > nitpick: int ide_ata66_check()
> >
>
> meaning...?
silly minor nitpick - please drop extra space while at it:
int ide_ata66_check(ide_drive_t *drive, task_ioreg_t *regs)
> >
> >> {
> >>- if ((args->tfRegister[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
> >>- (args->tfRegister[IDE_SECTOR_OFFSET] > XFER_UDMA_2) &&
> >>- (args->tfRegister[IDE_FEATURE_OFFSET] == SETFEATURES_XFER)) {
> >>+ if ((regs[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
> >>+ (regs[IDE_SECTOR_OFFSET] > XFER_UDMA_2) &&
> >>+ (regs[IDE_FEATURE_OFFSET] == SETFEATURES_XFER)) {
> >
> >
> > nitpick: please drop brackets
> >
>
> Parenthese?
doh, yes
> >
> >> #ifndef CONFIG_IDEDMA_IVB
> >>if ((drive->id->hw_config & 0x6000) == 0) {
> >> #else /* !CONFIG_IDEDMA_IVB */
> >>@@ -678,11 +678,11 @@ int ide_ata66_check (ide_drive_t *drive,
> >> * 1 : Safe to update drive->id DMA registers.
> >> * 0 : OOPs not allowed.
> >> */
> >>-int set_transfer (ide_drive_t *drive, ide_task_t *args)
> >>+int set_transfer (ide_drive_t *drive, task_ioreg_t *regs)
> >
> >
> > nitpick: int set_transfer()
> >
>
> ??
extra space
> >
> >> {
> >>- if ((args->tfRegister[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
> >>- (args->tfRegister[IDE_SECTOR_OFFSET] >= XFER_SW_DMA_0) &&
> >>- (args->tfRegister[IDE_FEATURE_OFFSET] == SETFEATURES_XFER) &&
> >>+ if ((regs[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
> >>+ (regs[IDE_SECTOR_OFFSET] >= XFER_SW_DMA_0) &&
> >>+ (regs[IDE_FEATURE_OFFSET] == SETFEATURES_XFER) &&
> >
> >
> > nitpick: brackets
> >
>
> Parentheses?
yep
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: A scrub daemon (prezeroing)
On Fri, 4 Feb 2005, Paul Mackerras wrote: > On my G5 it takes ~200 cycles to zero a whole page. In other words it > takes about the same time to zero a page as to bring in a single cache > line from memory. (PPC has an instruction to establish a whole cache > line of zeroes in modified state without reading anything from > memory.) > > Thus I can't see how prezeroing can ever be a win on ppc64. You need to think about this in a different way. Prezeroing only makes sense if it can avoid using cache lines that the zeroing in the hot paths would have to use since it touches all cachelines on the page (the ppc instruction is certainly nice and avoids a cacheline read but it still uses a cacheline!). The zeroing in itself (within the cpu caches) is extraordinarily fast and the zeroing of large portions of memory is so too. That is why the impact of scrubd is negligible since its extremely fast. The point is to save activating cachelines not the time zeroing in itself takes. This only works if only parts of the page are needed immediately after the page fault. All of that has been documented in earlier posts on the subject. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Hi, On Fri, 04 Feb 2005 08:18:56 +0900 Itsuro Oda <[EMAIL PROTECTED]> wrote: > > > > 5) dump kernel: export all valid physical memory (and saved register > > >information) to the user. (as /dev/oldmem /proc/vmcore ?) > > > > Or in user space, by just mmaping /dev/mem. That is part of the > > current conversation. The only real point for putting that code in > > the kernel (besides momentum) is it is a cheap way to get the exact > > data structures of the kernel you are using. But since: > > (a) it does not look like any primary kernel data structures need to > > be examined. > > (b) even simple compile options like SMP/NOSMP are enough to change > > the layout of the data structures. > > I think there is a pretty good case for moving all of the work to > > user space. But you still need a kernel that loads and > > runs in the reserved area. > > > I don't make sense. what do you mean ? > "I don't make sense." should be "It does not make sense." sorry. I'm not familiar with English. -- Itsuro ODA <[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 2.6.11-rc2 25/29] ide: convert REQ_DRIVE_CMD to REQ_DRIVE_TASKFILE
Hello, Bartlomiej Zolnierkiewicz wrote: On Wed, 2 Feb 2005 12:15:59 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: 25_ide_taskfile_cmd.patch All in-kernel REQ_DRIVE_CMD users except for ide_cmd_ioctl() converted to use REQ_DRIVE_TASKFILE. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Index: linux-ide-export/drivers/ide/ide-disk.c === --- linux-ide-export.orig/drivers/ide/ide-disk.c2005-02-02 10:28:06.527986413 +0900 +++ linux-ide-export/drivers/ide/ide-disk.c 2005-02-02 10:28:07.204876587 +0900 @@ -750,7 +750,7 @@ static int set_multcount(ide_drive_t *dr if (drive->special.b.set_multmode) return -EBUSY; ide_init_drive_cmd (); - rq.flags = REQ_DRIVE_CMD; + rq.flags = REQ_DRIVE_TASKFILE; Please instead fix ide_init_drive_cmd() to set REQ_DRIVE_TASKFILE and add set REQ_DRIVE_CMD only in ide_cmd_ioctl(). This is done in patch #28. If you don't like the ordering of the patches, I can change the orders but I don't think that improves anything. This order is as good as the other order. drive->mult_req = arg; drive->special.b.set_multmode = 1; (void) ide_do_drive_cmd (drive, , ide_wait); Index: linux-ide-export/drivers/ide/ide.c === --- linux-ide-export.orig/drivers/ide/ide.c 2005-02-02 10:27:14.652402828 +0900 +++ linux-ide-export/drivers/ide/ide.c 2005-02-02 10:28:07.205876425 +0900 @@ -1255,6 +1255,7 @@ static int set_pio_mode (ide_drive_t *dr if (drive->special.b.set_tune) return -EBUSY; ide_init_drive_cmd(); + rq.flags = REQ_DRIVE_TASKFILE; drive->tune_req = (u8) arg; drive->special.b.set_tune = 1; (void) ide_do_drive_cmd(drive, , ide_wait); Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 26/29] ide: map ide_cmd_ioctl() to ide_taskfile_ioctl()
Bartlomiej Zolnierkiewicz wrote:
On Wed, 2 Feb 2005 12:10:37 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
26_ide_taskfile_cmd_ioctl.patch
ide_cmd_ioctl() converted to use ide_taskfile_ioctl(). This
is the last user of REQ_DRIVE_CMD.
ide_cmd_ioctl() needs to map to taskfile transport not ide_taskfile_ioctl()
Index: linux-ide-export/drivers/ide/ide-iops.c
===
--- linux-ide-export.orig/drivers/ide/ide-iops.c2005-02-02
10:28:04.466320918 +0900
+++ linux-ide-export/drivers/ide/ide-iops.c 2005-02-02 10:28:07.406843817
+0900
@@ -648,11 +648,11 @@ u8 eighty_ninty_three (ide_drive_t *driv
EXPORT_SYMBOL(eighty_ninty_three);
-int ide_ata66_check (ide_drive_t *drive, ide_task_t *args)
+int ide_ata66_check (ide_drive_t *drive, task_ioreg_t *regs)
nitpick: int ide_ata66_check()
meaning...?
{
- if ((args->tfRegister[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
- (args->tfRegister[IDE_SECTOR_OFFSET] > XFER_UDMA_2) &&
- (args->tfRegister[IDE_FEATURE_OFFSET] == SETFEATURES_XFER)) {
+ if ((regs[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
+ (regs[IDE_SECTOR_OFFSET] > XFER_UDMA_2) &&
+ (regs[IDE_FEATURE_OFFSET] == SETFEATURES_XFER)) {
nitpick: please drop brackets
Parenthese?
#ifndef CONFIG_IDEDMA_IVB
if ((drive->id->hw_config & 0x6000) == 0) {
#else /* !CONFIG_IDEDMA_IVB */
@@ -678,11 +678,11 @@ int ide_ata66_check (ide_drive_t *drive,
* 1 : Safe to update drive->id DMA registers.
* 0 : OOPs not allowed.
*/
-int set_transfer (ide_drive_t *drive, ide_task_t *args)
+int set_transfer (ide_drive_t *drive, task_ioreg_t *regs)
nitpick: int set_transfer()
??
{
- if ((args->tfRegister[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
- (args->tfRegister[IDE_SECTOR_OFFSET] >= XFER_SW_DMA_0) &&
- (args->tfRegister[IDE_FEATURE_OFFSET] == SETFEATURES_XFER) &&
+ if ((regs[IDE_COMMAND_OFFSET] == WIN_SETFEATURES) &&
+ (regs[IDE_SECTOR_OFFSET] >= XFER_SW_DMA_0) &&
+ (regs[IDE_FEATURE_OFFSET] == SETFEATURES_XFER) &&
nitpick: brackets
Parentheses?
(drive->id->dma_ultra ||
drive->id->dma_mword ||
drive->id->dma_1word))
Index: linux-ide-export/drivers/ide/ide-taskfile.c
===
--- linux-ide-export.orig/drivers/ide/ide-taskfile.c2005-02-02
10:28:06.751950074 +0900
+++ linux-ide-export/drivers/ide/ide-taskfile.c 2005-02-02 10:28:07.407843655
+0900
@@ -704,78 +704,90 @@ abort:
return err;
}
-int ide_wait_cmd (ide_drive_t *drive, u8 cmd, u8 nsect, u8 feature, u8
sectors, u8 *buf)
-{
- struct request rq;
- u8 buffer[4];
-
- if (!buf)
- buf = buffer;
- memset(buf, 0, 4 + SECTOR_WORDS * 4 * sectors);
- ide_init_drive_cmd();
- rq.buffer = buf;
- *buf++ = cmd;
- *buf++ = nsect;
- *buf++ = feature;
- *buf++ = sectors;
- return ide_do_drive_cmd(drive, , ide_wait);
-}
-
-/*
- * FIXME : this needs to map into at taskfile. <[EMAIL PROTECTED]>
- */
int ide_cmd_ioctl (ide_drive_t *drive, unsigned int cmd, unsigned long arg)
{
- int err = 0;
- u8 args[4], *argbuf = args;
+ u8 args[4];
+ ide_task_request_t *task_req;
+ task_ioreg_t *io_ports;
u8 xfer_rate = 0;
- int argsize = 4;
- ide_task_t tfargs;
+ mm_segment_t orig_fs;
+ int in_size, ret;
- if (NULL == (void *) arg) {
+ if ((void *)arg == NULL) {
struct request rq;
ide_init_drive_cmd();
+ rq.flags = REQ_DRIVE_TASKFILE;
return ide_do_drive_cmd(drive, , ide_wait);
}
if (copy_from_user(args, (void __user *)arg, 4))
return -EFAULT;
- memset(, 0, sizeof(ide_task_t));
- tfargs.tfRegister[IDE_FEATURE_OFFSET] = args[2];
- tfargs.tfRegister[IDE_NSECTOR_OFFSET] = args[3];
- tfargs.tfRegister[IDE_SECTOR_OFFSET] = args[1];
- tfargs.tfRegister[IDE_LCYL_OFFSET]= 0x00;
- tfargs.tfRegister[IDE_HCYL_OFFSET]= 0x00;
- tfargs.tfRegister[IDE_SELECT_OFFSET] = 0x00;
- tfargs.tfRegister[IDE_COMMAND_OFFSET] = args[0];
-
- if (args[3]) {
- argsize = 4 + (SECTOR_WORDS * 4 * args[3]);
- argbuf = kmalloc(argsize, GFP_KERNEL);
- if (argbuf == NULL)
- return -ENOMEM;
- memcpy(argbuf, args, 4);
+ in_size = 4 * SECTOR_WORDS * args[3];
+
+ task_req = kmalloc(sizeof(*task_req) + in_size, GFP_KERNEL);
+ if (task_req == NULL)
+ return -ENOMEM;
+
+ memset(task_req, 0, sizeof(*task_req) + in_size);
+
+ task_req->out_flags.b.status_command= 1;
+ task_req->out_flags.b.sector= 1;
+ task_req->out_flags.b.error_feature = 1;
+ task_req->out_flags.b.nsector = 1;
+
+
Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Itsuro Oda <[EMAIL PROTECTED]> writes: > Hi, > > On 02 Feb 2005 07:45:11 -0700 > [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > > > > And the feedback begins :) > > > > Itsuro Oda <[EMAIL PROTECTED]> writes: > > > > > Hi, > > > > > > I don't like calling crash_kexec() directly in (ex.) panic(). > > > It should be call_dump_hook() (or something like this). > > > > > > I think the necessary modifications of the kernel is only: > > > - insert the hooks that calls a dump function when crash occur > > crash_kexec() > > > - binding interface that binds a dump function to the hook > > > (like register_dump_hook()) > > sys_kexec_load(...); > > For example there are pepole who want to execute a built in kernel > debugger when the system is crashed. or there are pepole who > believe the diskdump is the best dump tool :-) > > So I think a sort of hook is better than calling crash_kexec > directly. (May I make a patch ?) The prevalent feeling I have heard from kernel developers and and my personal feeling as well is that after a kernel has called panic you can't trust it. Which means anything running in the kernel itself is suspect. The crash_kexec() hooks enables everything that does not get linked into the kernel. So I don't feel a hook in the panic path is necessary nor do I feel that it is wise, especially with no in-kernel users. Plus the worst part about a hook in the panic path is that it is inherently racy. Keeping the crash_kexec() code from blocking or being racy has been a challenge. And I still think that entire code path needs a review and some more code tweaks to remove races. If someone else wants a hook in the panic path they can add their own hook, and make their own case for why it is needed. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
On Thu, 03 Feb 2005 21:47:11 +0100, Ingo Molnar wrote: > > * Con Kolivas <[EMAIL PROTECTED]> wrote: > >> >* real inter-process handoff. i am thinking of something like >> >sched_yield(), but it would take a TID as the target >> >of the yield. this would avoid all the crap we have to >> >go through to drive the graph of clients with FIFO's and >> >write(2) and poll(2). Futexes might be a usable >> >approximation in 2.6 (we are supporting 2.4, so we can't >> >use them all the time) >> >> yield_to(tid) should not be too hard to implement. Ingo? What do you >> think? > > i dont really like it - it's really the wrong interface to use. Would it be nice to create scheduling domains, so the processes in a domain have priority relative to each other. The second highest priority FIFO task could actually be a scheduling sub-domain (which appears to be a child process of task A). In that scheduling sub-domain would be all the real-time tasks that A manages the scheduling of. It gets to set their relative priorities and sched class. Task A could then make the first FIFO client be at the top of that domain, with the second task to run being at the next priority, etc. Then Task A blocks waiting for a watchdog timer so it can keep an eye on things. This way yield_to would actually be almost a special case of a pre-configurable sequence of operations which can have FIFO parts, RR parts, and OTHER parts. Task A could also put one of its own threads in the sub-domain to be able to change its state at a certain point in the sequence rather than a certain time. This could be extended to allow init to own a sub-domain for each user that it could manage to allow users to each have real-time operations, and daemons with high priorities relative to that user's other tasks, but without interfering with other users (or giving root an automatic advantage). It could make accounting easier, and allow users to get total priority equal to the amount of money they pay. I know this could be a lot of work, but is it sound in principle? How would you do better than RR between users with domains at the same priority though... That I'm not sure of. IE, it might be good to switch back to any domain that has a recently woken task more frequently but for less time then extend the time and decrease the frequency as the time since waking increases. That way users tasks could respond quickly to events without ever being able to cause or suffer from starvation. Unfortunately, O(1) behaviour would be a must, and that scheme could be particularly hard to implement in O(1) :) Is it useful, too much work, over-engineered, logically impossible? -- Tristan Wibberley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange problem with sensors: 0 RPMs ?
On 2005.02.04, J.A. Magallon wrote: > Hi all... > > I have a dual Xeon box. I got tired of the noise of the Intel boxed > fans and bought a couple of Swiftech 'hedegehogs' and two ThemalTake > fans. > Board is an Asus PCDL and sensors chip is a w83627hf (heavily modified by > Asus, I suppose, because it has 5! fan sensors). With the Intel fans, > I got both rpm measures OK. With the new fans, the CPU0 fan insists > it is stopped at 0 RPM. And I see it spinning. It is correctly plugged > and the Xeon temperature stays nicely at 32º C. > And the more strange thing is that the hardware monitor in the BIOS > tells me it is spinning at about 2500 RPM !!! And the own BIOS says > at boot that my CPU FAN IS STOPPED. > Sorry for the noise. Some google results I have not found before and fanN_div did the trick. Thanks. -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.10-jam7 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #3 pgpgx5MzbxPs7.pgp Description: PGP signature
Re: [PATCH] arp_queue: serializing unlink + kfree_skb
On Thu, Feb 03, 2005 at 05:23:57PM -0800, David S. Miller wrote:
>
> You're absolutely right. Ok, so we do need to change kfree_skb().
> I believe even with the memory barrier, the atomic_read() optimization
> is still worth it. atomic ops on sparc64 take a minimum of 40 some odd
> cycles on UltraSPARC-III and later, whereas the memory barrier will
> take up a single cycle most of the time.
OK, here is the patch to do that. Let's get rid of kfree_skb_fast
while we're at it since it's no longer used.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
= include/linux/skbuff.h 1.59 vs edited =
--- 1.59/include/linux/skbuff.h 2005-01-11 07:23:55 +11:00
+++ edited/include/linux/skbuff.h 2005-02-04 12:46:15 +11:00
@@ -353,15 +353,11 @@
*/
static inline void kfree_skb(struct sk_buff *skb)
{
- if (atomic_read(>users) == 1 || atomic_dec_and_test(>users))
- __kfree_skb(skb);
-}
-
-/* Use this if you didn't touch the skb state [for fast switching] */
-static inline void kfree_skb_fast(struct sk_buff *skb)
-{
- if (atomic_read(>users) == 1 || atomic_dec_and_test(>users))
- kfree_skbmem(skb);
+ if (likely(atomic_read(>users) == 1))
+ smp_rmb();
+ else if (likely(!atomic_dec_and_test(>users)))
+ return;
+ __kfree_skb(skb);
}
/**
Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
On Tue, 2005-02-01 at 21:14 +0100, Ingo Molnar wrote: > i have released the -V0.7.37-02 Real-Time Preemption patch, which can be > downloaded from the usual place: > > http://redhat.com/~mingo/realtime-preempt/ > > the big change in the patch is increased architecture support: most > notable i've merged the MIPS patch from Manish Lachwani. Also, the x64 > port should be working again. (To make architecture merges easier in the > future the timer interrupt is not threaded anymore - if this shows > latency problems then we'll try to solve it on other ways.) Ingo, I was just about to send you a note about why the timer interrupt as a thread was a problem, but you changed it here, so it really isn't anymore. But since your reason is for architecture, and not for this reason, I'm posting it anyway. Here was what I was about to send: I was wondering why the timer interrupt is a thread, because this can cause some unexpected results. Say if you have two high priority processes A and B. A is higher than B and both are higher than the timer interrupt (I'm on x86 so it's IRQ0) B is doing lots of busy work, and A does a little then sleeps a little. This is what is happening. Once A sleeps, B goes off doing lots of busy work, and A doesn't wake up until B is done, although A had a timeout, that it missed. What's going on is that the jiffies are not incrementing. After the first time that IRQ 0 goes goes off, the interrupt is disabled. So we don't get any more interrupts for the timer, and B gets to run as much as it wants leaving A in the dust. So my question to you is why even bother having the timer interrupt as thread. Maybe make a tasklet or something to do more of it's work, but let the interrupt go off as much as it wants. Otherwise, you can have the problem mentioned above. If the fix to this is to either change the timer interrupt to either NODELAY or just have the processes lower in priority than the timer, then what's the point to having the timer as a thread? OK that was the note I was about to send, but like I stated, it isn't a problem now that the timer interrupt is back to a hard interrupt. I just showing this to you so you can see the real problem. Maybe I'm missing something, and maybe I'm not. I'll try to write up something that shows the problem with the timer interrupt as a thread. Thanks, -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 05/29] ide: merge pci driver .h's into .c's
On Wed, 2 Feb 2005 11:47:12 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > 05_ide_merge_pci_driver_hc.patch > > > > Merges drivers/ide/pci/*.h files into their corresponding *.c > > files. Rationales are > > 1. There's no reason to separate pci drivers into header and > > body. No header file is shared and they're simple enough. > > 2. struct pde_pci_device_t *_chipsets[] are _defined_ in the > > header files. That isn't the custom and there's no good > > reason to do differently in these drivers. > > 3. Tracking changelogs shows that the bugs fixed by 00 and 01 > > are introduced during mass-updating ide pci drivers by > > forgetting to update *.h files. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Please kill crap in these .h files before mering them with .c files, also split this patch on per driver changes. crap example looks like this: ;) > +#ifndef SPLIT_BYTE > +#define SPLIT_BYTE(B,H,L) ((H)=(B>>4), (L)=(B-((B>>4)<<4))) > +#endif > +#ifndef MAKE_WORD > +#define MAKE_WORD(W,HB,LB) ((W)=((HB<<8)+LB)) > +#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/
Re: [PATCH 2.6.11-rc2 22/29] ide: convert REQ_DRIVE_TASK to REQ_DRIVE_TASKFILE
On Fri, 04 Feb 2005 09:54:23 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello again, Bartlomiej.
>
> Bartlomiej Zolnierkiewicz wrote:
> > On Wed, 2 Feb 2005 12:07:27 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> >
> >>>22_ide_taskfile_flush.patch
> >>>
> >>> All REQ_DRIVE_TASK users except ide_task_ioctl() converted
> >>> to use REQ_DRIVE_TASKFILE.
> >>> 1. idedisk_issue_flush() converted to use REQ_DRIVE_TASKFILE.
> >>> This and the changes in ide_get_error_location() remove a
> >>> possible race condition between ide_get_error_location()
> >>> and other requests.
> >
> >
> > What race condition?
>
> The old ide_get_error_location() acceses hardware registers after the
> flush request is finished, so the registers could have been crobbered by
> other on-going or finished requests.
yep, you are right
> >>@@ -80,7 +62,8 @@ static void ide_fill_flush_cmd(ide_drive
> >> static struct request *ide_queue_flush_cmd(ide_drive_t *drive,
> >> struct request *rq, int post)
> >> {
> >>- struct request *flush_rq = (drive)->wrq;
> >>+ struct request *flush_rq = (drive)->flush_rq;
> >>+ ide_task_t *args = (drive)->flush_args;
> >
> >
> > please don't use HWGROUP() macro,
> > just use drive->hwif->hwgroup directly
> >
>
> I think I'll leave the code like above here and make another patch which
> removes all uses of HWGROUP() and HWGROUP() itself. What do you think
> about that?
I prefer gradual changes because IMHO such global find'n'replace
changes have high noise ratio and are bad for maintainability
(also most of the code it would touch need some other fixes anyway).
> >>@@ -930,6 +930,39 @@ typedef ide_startstop_t (ide_pre_handler
> >> typedef ide_startstop_t (ide_handler_t)(ide_drive_t *);
> >> typedef int (ide_expiry_t)(ide_drive_t *);
> >>
> >>+typedef struct ide_task_s {
> >>+/*
> >>+ * struct hd_drive_task_hdrtf;
> >>+ * task_struct_t tf;
> >>+ * struct hd_drive_hob_hdr hobf;
> >>+ * hob_struct_thobf;
> >>+ */
> >>+ task_ioreg_ttfRegister[8];
> >>+ task_ioreg_thobRegister[8];
> >>+ ide_reg_valid_t tf_out_flags;
> >>+ ide_reg_valid_t tf_in_flags;
> >>+ int data_phase;
> >>+ int command_type;
> >>+ ide_pre_handler_t *prehandler;
> >>+ ide_handler_t *handler;
> >>+ struct request *rq;/* copy of request */
> >>+ void*special; /* valid_t generally */
> >>+} ide_task_t;
> >
> >
> > please don't move this around,
> > adding struct ide_task_s; should do the trick
> >
>
> No, I added ide_task_t flush_args to hwgroup_t not a pointer to
> ide_task_t, so the definition of ide_task_t has to come before the
> definition of hwgroup_t.
OK
> >
> >>+typedef struct pkt_task_s {
> >>+/*
> >>+ * struct hd_drive_task_hdrpktf;
> >>+ * task_struct_t pktf;
> >>+ * u8 pkcdb[12];
> >>+ */
> >>+ task_ioreg_ttfRegister[8];
> >>+ int data_phase;
> >>+ int command_type;
> >>+ ide_handler_t *handler;
> >>+ struct request *rq;/* copy of request */
> >>+ void*special;
> >>+} pkt_task_t;
> >
> >
> > there is no need to move pkt_task_t around
> > (moreover no code uses it currently)
> >
>
> And it seemd kind of lonely after ide_task_t moved upward. :-) How
> about modifying this patch such that it moves only the ide_task_t and
> adding another patch to kill pkt_task_t?
sounds good
> >
> >> typedef struct hwgroup_s {
> >>/* irq handler, if active */
> >>ide_startstop_t (*handler)(ide_drive_t *);
> >>@@ -955,8 +988,12 @@ typedef struct hwgroup_s {
> >>struct request *rq;
> >>/* failsafe timer */
> >>struct timer_list timer;
> >>- /* local copy of current write rq */
> >>- struct request wrq;
> >>+ /* rq used for flushing */
> >>+ struct request flush_rq;
> >>+ /* task used for flushing */
> >>+ ide_task_t flush_args;
> >>+ /* real_rq for flushing */
> >>+ struct request *flush_real_rq;
> >>/* timeout value during long polls */
> >>unsigned long poll_timeout;
> >>/* queried upon timeouts */
> >>@@ -1203,7 +1240,7 @@ extern void ide_init_drive_cmd (struct r
> >> /*
> >> * this function returns error location sector offset in case of a write
> >> error
> >> */
> >>-extern u64 ide_get_error_location(ide_drive_t *, char *);
> >>+extern u64 ide_get_error_location(ide_drive_t *, ide_task_t *);
> >
> >
> > extern is not needed
> >
>
> Yeah, it isn't needed. I was trying to be conformant with other
> declarations in the file.
Re: [Patch] invalidate range of pages after direct IO write
Andrew Morton wrote: > Note that the same optimisation should be made in the call to > unmap_mapping_range() in generic_file_direct_IO(). Currently we try and > unmap the whole file, even if we're only writing a single byte. Given that > you're now calculating iov_length() in there we might as well use that > number a few lines further up in that function. Indeed. I can throw that together. I also have a patch that introduces filemap_write_and_wait_range() and calls it from the read bit of __blockdev_direct_IO(). It didn't change the cheesy fsx load I was using and then I got distracted. I can try harder. > Reading the code, I'm unable to convince myself that it won't go into an > infinite loop if it finds a page at page->index = -1. But I didn't try > very hard ;) I'm unconvinced as well. I got the pattern from truncate_inode_pages_range() and it seems to have a related problem when end is something that page_index can never be greater than. It just starts over. I wonder if we should add some mapping_for_each_range() (less ridiculous names welcome :)) macro that handles this crap for the caller who just works with page pointers. We could introduce some iterator struct that the caller would put on the stack and pass in to hold state, something like the 'n' in list_for_each_safe(). It looks like a few pagevec_lookup() callers could use this. > Minor note on this: > > return invalidate_inode_pages2_range(mapping, 0, ~0UL); > > I just use `-1' there. Roger. I was just mimicking invalidate_inode_pages(). > I'll make that change and plop the patch into -mm, but we need to think > about the infinite-loop problem.. I can try hacking together that macro and auditing pagevec_lookup() callers.. - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.4] Wireless Extension v17
Hi Marcelo, This patch adds Wireless Extensions v17 to kernel 2.4.X. This patch is the same as what went into 2.6.10-rc1, except for the minor differences between 2.4.X and 2.6.X. This was tested on 2.4.29. The main reason of this patch is wireless driver outside the kernel tree. Some of them already support WE-17 (HostAP, Prism54), so having this patch in 2.4.X will allow then simplify their code. The changelog : * - Add flags to frequency -> auto/fixed * - Document (struct iw_quality *)->updated, add new flags (INVALID) * - Wireless Event capability in struct iw_range * - Add support for relative TxPower (yick !) * - Change the way we get to spy_data method for added safety and hostap * - Remove spy #ifdef, they are always on -> cleaner code * - Allow any size GET request if user specifies length > max * - Start migrating get_wireless_stats to struct iw_handler_def * Based on patch from Pavel Roskin <[EMAIL PROTECTED]> : * - Fix kernel data leak to user space in private handler handling Have fun... Jean diff -u -p linux/include/linux/netdevice.we16.h linux/include/linux/netdevice.h --- linux/include/linux/netdevice.we16.h2005-02-03 14:54:56.0 -0800 +++ linux/include/linux/netdevice.h 2005-02-03 15:43:30.0 -0800 @@ -295,7 +295,9 @@ struct net_device /* List of functions to handle Wireless Extensions (instead of ioctl). * See for details. Jean II */ - struct iw_handler_def * wireless_handlers; + const struct iw_handler_def * wireless_handlers; + /* Instance data managed by the core of Wireless Extensions. */ + struct iw_public_data * wireless_data; struct ethtool_ops *ethtool_ops; diff -u -p linux/include/linux/wireless.we16.h linux/include/linux/wireless.h --- linux/include/linux/wireless.we16.h 2005-02-03 14:55:04.0 -0800 +++ linux/include/linux/wireless.h 2005-02-03 15:44:48.0 -0800 @@ -1,10 +1,10 @@ /* * This file define a set of standard wireless extensions * - * Version : 16 2.4.03 + * Version : 17 21.6.04 * * Authors : Jean Tourrilhes - HPL - <[EMAIL PROTECTED]> - * Copyright (c) 1997-2002 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. */ #ifndef _LINUX_WIRELESS_H @@ -47,12 +47,12 @@ * # include/net/iw_handler.h * * Note as well that /proc/net/wireless implementation has now moved in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Wireless Events (2002 -> onward) : * * Events are defined at the end of this file, and implemented in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Other comments : * -- @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 16 +#define WIRELESS_EXT 17 /* * Changes : @@ -175,6 +175,13 @@ * - Remove IW_MAX_GET_SPY because conflict with enhanced spy support * - Add SIOCSIWTHRSPY/SIOCGIWTHRSPY and "struct iw_thrspy" * - Add IW_ENCODE_TEMP and iw_range->encoding_login_index + * + * V16 to V17 + * -- + * - Add flags to frequency -> auto/fixed + * - Document (struct iw_quality *)->updated, add new flags (INVALID) + * - Wireless Event capability in struct iw_range + * - Add support for relative TxPower (yick !) */ / CONSTANTS / @@ -251,7 +258,7 @@ /* DEV PRIVATE IOCTL LIST */ -/* These 16 ioctl are wireless device private. +/* These 32 ioctl are wireless device private, for 16 commands. * Each driver is free to use them for whatever purpose it chooses, * however the driver *must* export the description of those ioctls * with SIOCGIWPRIV and *must* use arguments as defined below. @@ -266,8 +273,8 @@ * We now have 32 commands, so a bit more space ;-). * Also, all 'odd' commands are only usable by root and don't return the * content of ifr/iwr to user (but you are not obliged to use the set/get - * convention, just use every other two command). - * And I repeat : you are not obliged to use them with iwspy, but you + * convention, just use every other two command). More details in iwpriv.c. + * And I repeat : you are not forced to use them with iwpriv, but you * must be compliant with it. */ @@ -352,6 +359,18 @@ #define IW_MODE_SECOND 5 /* Secondary master/repeater (backup) */ #define IW_MODE_MONITOR6 /* Passive monitor (listen only) */ +/* Statistics flags (bitmask in updated) */ +#define IW_QUAL_QUAL_UPDATED 0x1 /* Value was updated since last read */ +#define IW_QUAL_LEVEL_UPDATED 0x2 +#define
Re: 2.6.10: kswapd spins like crazy
Nick Piggin <[EMAIL PROTECTED]> wrote: > > Oh, attached should be a minimal fix if you would like to try it out. > > > ... > --- linux-2.6/mm/vmscan.c~vmscan-minfix 2005-02-04 11:52:37.0 > +1100 > +++ linux-2.6-npiggin/mm/vmscan.c 2005-02-04 11:53:32.0 +1100 > @@ -575,6 +575,7 @@ static void shrink_cache(struct zone *zo > nr_taken++; > } > zone->nr_inactive -= nr_taken; > + zone->pages_scanned += nr_scan; > spin_unlock_irq(>lru_lock); > > if (nr_taken == 0) > Any theories as to why these pages aren't being activated and aren't being reclaimed? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 25/29] ide: convert REQ_DRIVE_CMD to REQ_DRIVE_TASKFILE
On Fri, 04 Feb 2005 10:06:29 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > Hello, > > Bartlomiej Zolnierkiewicz wrote: > > On Wed, 2 Feb 2005 12:15:59 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > > > >>>25_ide_taskfile_cmd.patch > >>> > >>> All in-kernel REQ_DRIVE_CMD users except for ide_cmd_ioctl() > >>> converted to use REQ_DRIVE_TASKFILE. > >> > >>Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > >> > >>Index: linux-ide-export/drivers/ide/ide-disk.c > >>=== > >>--- linux-ide-export.orig/drivers/ide/ide-disk.c2005-02-02 > >>10:28:06.527986413 +0900 > >>+++ linux-ide-export/drivers/ide/ide-disk.c 2005-02-02 > >>10:28:07.204876587 +0900 > >>@@ -750,7 +750,7 @@ static int set_multcount(ide_drive_t *dr > >>if (drive->special.b.set_multmode) > >>return -EBUSY; > >>ide_init_drive_cmd (); > >>- rq.flags = REQ_DRIVE_CMD; > >>+ rq.flags = REQ_DRIVE_TASKFILE; > > > > > > Please instead fix ide_init_drive_cmd() to set REQ_DRIVE_TASKFILE > > and add set REQ_DRIVE_CMD only in ide_cmd_ioctl(). > > > > This is done in patch #28. If you don't like the ordering of the > patches, I can change the orders but I don't think that improves > anything. This order is as good as the other order. Actually no - if you change this then patch #28 becomes NOP. So please do it, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 29/29] ide: make data_phase explicit in NO_DATA cases
On Fri, 04 Feb 2005 09:59:22 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Wed, 2 Feb 2005 12:12:38 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> >
> >>>29_ide_explicit_TASKFILE_NO_DATA.patch
> >>>
> >>> Make data_phase explicit in NO_DATA cases.
> >>
> >>Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> >>
> >>Index: linux-ide-export/drivers/ide/ide-disk.c
> >>===
> >>--- linux-ide-export.orig/drivers/ide/ide-disk.c2005-02-02
> >>10:28:07.852771465 +0900
> >>+++ linux-ide-export/drivers/ide/ide-disk.c 2005-02-02
> >>10:28:08.121727827 +0900
> >>@@ -300,6 +300,7 @@ static unsigned long idedisk_read_native
> >>args.tfRegister[IDE_SELECT_OFFSET] = 0x40;
> >>args.tfRegister[IDE_COMMAND_OFFSET] = WIN_READ_NATIVE_MAX;
> >>args.command_type = IDE_DRIVE_TASK_NO_DATA;
> >>+ args.data_phase = TASKFILE_NO_DATA;
> >>args.handler= _no_data_intr;
> >
> >
> > Could you add small helper to ide.h for doing this?
> >
> > static inline void ide_prep_no_data_cmd(ide_task_t *task)
> > {
> > task->command_type = IDE_DRIVE_TASK_NO_DATA;
> > task->data_phase = TASKFILE_NO_DATA;
> > task->handler= _no_data_intr;
> > }
>
> I am thinking about removing task->handler initialization. Such that it
> defaults to task_no_data_intr if data_phase == TASKFILE_NO_DATA and so
> on for all other data_phases. Currently, the same information is
> specified repeatedly. What do you think?
Please do 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/
[UPDATE PATCH]: include/jiffies: fix usecs_to_jiffies()/jiffies_to_usecs() math
On Thu, Feb 03, 2005 at 10:48:05AM -0800, Nishanth Aravamudan wrote:
> On Thu, Feb 03, 2005 at 10:07:15AM -0600, Makhlis, Lev wrote:
> > Nishanth Aravamudan <[EMAIL PROTECTED]> wrote:
> >
> > > +static inline unsigned long usecs_to_jiffies(const unsigned int u)
> > > +{
> > > + if (u > jiffies_to_usecs(MAX_JIFFY_OFFSET))
> > > + return MAX_JIFFY_OFFSET;
> > > +#if HZ <= 1000 && !(1000 % HZ)
> > > + return (u + (100 / HZ) - 1000) / (100 / HZ);
> > > +#elif HZ > 1000 && !(HZ % 1000)
> > > + return u * (HZ / 100);
> > > +#else
> > > + return (u * HZ + 99) / 100;
> > > +#endif
> > > +}
> >
> > Shouldn't this use 100 instead of 1000 everywhere?
> > It returns 0 if HZ=1.
>
> Thanks for your feedback!
>
> I believe you are correct... Thanks for catching this! This ends up also
> being a
> problem for jiffies_to_usecs() actually, as it improperly converts certain
> values as it is coded. The attached patch, which overrides the previous one
> seems to be more correct. Andrew, if you would prefer an incremental patch,
> please let me know.
>
> Description: Add a usecs_to_jiffies() function. With the potential for
> dynamic HZ
As was kindly pointed out to me, usecs_to_jiffies() has already exists! :) The
currently included patch is for 2.6.11-rc3 and fixes the math in that version.
Thanks,
Nish
Description: Fixes the math of both jiffies_to_usecs() and usecs_to_jiffies()
which improperly assume the same rounding point -- 1,000 -- as
jiffies_to_msecs()
and msecs_to_jiffies(), when in fact it should be 1,000,000. Furthermore, the
actual math of both functions is actually wrong and will lead to more than just
rounding errors.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
--- 2.6.11-rc3-kj-v/include/linux/jiffies.h 2005-02-03 17:05:13.0
-0800
+++ 2.6.11-rc3-kj/include/linux/jiffies.h 2005-02-03 17:01:48.0
-0800
@@ -265,10 +265,10 @@ static inline unsigned int jiffies_to_ms
static inline unsigned int jiffies_to_usecs(const unsigned long j)
{
-#if HZ <= 1000 && !(1000 % HZ)
+#if HZ <= 100 && !(100 % HZ)
return (100 / HZ) * j;
-#elif HZ > 1000 && !(HZ % 1000)
- return (j*1000 + (HZ - 1000))/(HZ / 1000);
+#elif HZ > 100 && !(HZ % 100)
+ return (j + (HZ / 100) - 1)/(HZ / 100);
#else
return (j * 100) / HZ;
#endif
@@ -291,9 +291,9 @@ static inline unsigned long usecs_to_jif
{
if (u > jiffies_to_usecs(MAX_JIFFY_OFFSET))
return MAX_JIFFY_OFFSET;
-#if HZ <= 1000 && !(1000 % HZ)
- return (u + (100 / HZ) - 1000) / (100 / HZ);
-#elif HZ > 1000 && !(HZ % 1000)
+#if HZ <= 100 && !(100 % HZ)
+ return (u + (100 / HZ) - 1) / (100 / HZ);
+#elif HZ > 100 && !(HZ % 100)
return u * (HZ / 100);
#else
return (u * HZ + 99) / 100;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] arp_queue: serializing unlink + kfree_skb
On Fri, 4 Feb 2005 12:20:53 +1100 Herbert Xu <[EMAIL PROTECTED]> wrote: > This is true if CPU 0 reads the count before reading skb->list. > Without a memory barrier, atomic_read and reading skb->list can > be reordered. Put it another way, reading skb->list could return > a cached value that was read from the main memory prior to the > atomic_read. > > So in order for CPU 0 to always see an up-to-date value of skb->list, > it needs to do an smp_rmb() between the atomic_read and reading > skb->list. You're absolutely right. Ok, so we do need to change kfree_skb(). I believe even with the memory barrier, the atomic_read() optimization is still worth it. atomic ops on sparc64 take a minimum of 40 some odd cycles on UltraSPARC-III and later, whereas the memory barrier will take up a single cycle most of the time. So it'll look something like: if (atomic_read(>users) == 1) smb_rmb(); else if (!atomic_dec_and_test(>users)) return; __kfree_skb(skb); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Strange problem with sensors: 0 RPMs ?
Hi all... I have a dual Xeon box. I got tired of the noise of the Intel boxed fans and bought a couple of Swiftech 'hedegehogs' and two ThemalTake fans. Board is an Asus PCDL and sensors chip is a w83627hf (heavily modified by Asus, I suppose, because it has 5! fan sensors). With the Intel fans, I got both rpm measures OK. With the new fans, the CPU0 fan insists it is stopped at 0 RPM. And I see it spinning. It is correctly plugged and the Xeon temperature stays nicely at 32º C. And the more strange thing is that the hardware monitor in the BIOS tells me it is spinning at about 2500 RPM !!! And the own BIOS says at boot that my CPU FAN IS STOPPED. Any idea ? Apart from the BIOS POST message, the problem related to kernel is: why bios monitor gives 2500 and sensors 0 ? TIA Ah, as a collateral damage, I also have one other fan connected to SYS_FAN1, for which lm_sensors never gave me an speed, always 0. :( What a mess... -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.10-jam7 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #3 pgpWvw8bxozeo.pgp Description: PGP signature
Re: 2.6.10: kswapd spins like crazy
Andrew Morton wrote: Nick Piggin <[EMAIL PROTECTED]> wrote: Oh, attached should be a minimal fix if you would like to try it out. ... --- linux-2.6/mm/vmscan.c~vmscan-minfix 2005-02-04 11:52:37.0 +1100 +++ linux-2.6-npiggin/mm/vmscan.c 2005-02-04 11:53:32.0 +1100 @@ -575,6 +575,7 @@ static void shrink_cache(struct zone *zo nr_taken++; } zone->nr_inactive -= nr_taken; + zone->pages_scanned += nr_scan; spin_unlock_irq(>lru_lock); if (nr_taken == 0) Any theories as to why these pages aren't being activated and aren't being reclaimed? No none yet, which is what we should get to the bottom of. I must be overlooking something, but the only ways I can see should be due to transient conditions like page locked or under writeback. laptop_mode? Terje, what is /proc/sys/vm/laptop_mode set to? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] arp_queue: serializing unlink + kfree_skb
On Thu, Feb 03, 2005 at 04:49:22PM -0800, David S. Miller wrote:
>
> If we see the count dropped to "1", whoever set it to "1" made
> sure that all outstanding memory operations (including things
> like __skb_unlink()) are globally visible before the
> atomic_dec_and_test() which put the thing to "1" from "2".
> (and we did use atomic_dec_and_test() since the refcount was
> not "1") Example, assuming skb->users is "2":
>
> cpu 0 cpu 1
> __skb_unlink()
> kfree_skb()
> kfree_skb()
>
> If cpu 0 sees the count at "1", it will always see the
> __skb_unlink() as well.
This is true if CPU 0 reads the count before reading skb->list.
Without a memory barrier, atomic_read and reading skb->list can
be reordered. Put it another way, reading skb->list could return
a cached value that was read from the main memory prior to the
atomic_read.
So in order for CPU 0 to always see an up-to-date value of skb->list,
it needs to do an smp_rmb() between the atomic_read and reading
skb->list.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.11-rc3 x86-64 compile err on suse 9.1
CC arch/x86_64/kernel/asm-offsets.s arch/x86_64/kernel/asm-offsets.c: In function `main': arch/x86_64/kernel/asm-offsets.c:65: error: invalid application of `sizeof' to an incomplete type arch/x86_64/kernel/asm-offsets.c:66: error: dereferencing pointer to incomplete type arch/x86_64/kernel/asm-offsets.c:67: error: dereferencing pointer to incomplete type make[1]: *** [arch/x86_64/kernel/asm-offsets.s] Error 1 make: *** [arch/x86_64/kernel/asm-offsets.s] Error 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: 2.6.10: kswapd spins like crazy
Nick Piggin wrote: Hmm, your DMA zone has no active pages, and pages_scanned (which triggers all_unreclaimable) is only incremented when scanning the active list. But I wonder, if the pages can't be freed, why aren't they being put on the active list? Oh, attached should be a minimal fix if you would like to try it out. --- linux-2.6-npiggin/mm/vmscan.c |1 + 1 files changed, 1 insertion(+) diff -puN mm/vmscan.c~vmscan-minfix mm/vmscan.c --- linux-2.6/mm/vmscan.c~vmscan-minfix 2005-02-04 11:52:37.0 +1100 +++ linux-2.6-npiggin/mm/vmscan.c 2005-02-04 11:53:32.0 +1100 @@ -575,6 +575,7 @@ static void shrink_cache(struct zone *zo nr_taken++; } zone->nr_inactive -= nr_taken; + zone->pages_scanned += nr_scan; spin_unlock_irq(>lru_lock); if (nr_taken == 0) _
Re: [PATCH 2.6.11-rc2 22/29] ide: convert REQ_DRIVE_TASK to REQ_DRIVE_TASKFILE
Hello again, Bartlomiej.
Bartlomiej Zolnierkiewicz wrote:
On Wed, 2 Feb 2005 12:07:27 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
22_ide_taskfile_flush.patch
All REQ_DRIVE_TASK users except ide_task_ioctl() converted
to use REQ_DRIVE_TASKFILE.
1. idedisk_issue_flush() converted to use REQ_DRIVE_TASKFILE.
This and the changes in ide_get_error_location() remove a
possible race condition between ide_get_error_location()
and other requests.
What race condition?
The old ide_get_error_location() acceses hardware registers after the
flush request is finished, so the registers could have been crobbered by
other on-going or finished requests.
2. ide_queue_flush_cmd() converted to use REQ_DRIVE_TASKFILE.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-ide-export/drivers/ide/ide-disk.c
===
--- linux-ide-export.orig/drivers/ide/ide-disk.c2005-02-02
10:28:06.272027942 +0900
+++ linux-ide-export/drivers/ide/ide-disk.c 2005-02-02 10:28:06.527986413
+0900
@@ -705,24 +705,26 @@ static int idedisk_issue_flush(request_q
{
ide_drive_t *drive = q->queuedata;
struct request *rq;
+ ide_task_t args;
int ret;
if (!drive->wcache)
return 0;
- rq = blk_get_request(q, WRITE, __GFP_WAIT);
-
- memset(rq->cmd, 0, sizeof(rq->cmd));
+ memset(, 0, sizeof(args));
if (ide_id_has_flush_cache_ext(drive->id) &&
(drive->capacity64 >= (1UL << 28)))
- rq->cmd[0] = WIN_FLUSH_CACHE_EXT;
+ args.tfRegister[IDE_COMMAND_OFFSET] = WIN_FLUSH_CACHE_EXT;
else
- rq->cmd[0] = WIN_FLUSH_CACHE;
+ args.tfRegister[IDE_COMMAND_OFFSET] = WIN_FLUSH_CACHE;
+ args.command_type = IDE_DRIVE_TASK_NO_DATA;
.data_phase is missed
Yeah, it was kind of intentional as all other functions which do
IDE_DRIVE_TASK_NO_DATA don't initialize args.data_phase explicitly.
patch #29 makes this change for all such cases including this one.
+ args.handler = task_no_data_intr;
Please compare the code above to the code you've added to
ide_queue_flush_cmd() - it is identical. It would be nice to add
some helper for doing this i.e. ide_init_flush_cmd().
Sure.
- rq->flags |= REQ_DRIVE_TASK | REQ_SOFTBARRIER;
- rq->buffer = rq->cmd;
+ rq = blk_get_request(q, WRITE, __GFP_WAIT);
+ rq->flags |= REQ_DRIVE_TASKFILE | REQ_SOFTBARRIER;
+ rq->special =
ret = blk_execute_rq(q, disk, rq);
@@ -730,8 +732,9 @@ static int idedisk_issue_flush(request_q
* if we failed and caller wants error offset, get it
*/
if (ret && error_sector)
- *error_sector = ide_get_error_location(drive, rq->cmd);
+ *error_sector = ide_get_error_location(drive, );
+ rq->special = NULL; /* just in case */
blk_put_request(rq);
return ret;
}
Index: linux-ide-export/drivers/ide/ide-io.c
===
--- linux-ide-export.orig/drivers/ide/ide-io.c 2005-02-02 10:28:06.273027780
+0900
+++ linux-ide-export/drivers/ide/ide-io.c 2005-02-02 10:28:06.528986250
+0900
@@ -55,24 +55,6 @@
#include
#include
-static void ide_fill_flush_cmd(ide_drive_t *drive, struct request *rq)
-{
- char *buf = rq->cmd;
-
- /*
-* reuse cdb space for ata command
-*/
- memset(buf, 0, sizeof(rq->cmd));
-
- rq->flags |= REQ_DRIVE_TASK | REQ_STARTED;
- rq->buffer = buf;
- rq->buffer[0] = WIN_FLUSH_CACHE;
-
- if (ide_id_has_flush_cache_ext(drive->id) &&
- (drive->capacity64 >= (1UL << 28)))
- rq->buffer[0] = WIN_FLUSH_CACHE_EXT;
-}
-
/*
* preempt pending requests, and store this cache flush for immediate
* execution
@@ -80,7 +62,8 @@ static void ide_fill_flush_cmd(ide_drive
static struct request *ide_queue_flush_cmd(ide_drive_t *drive,
struct request *rq, int post)
{
- struct request *flush_rq = (drive)->wrq;
+ struct request *flush_rq = (drive)->flush_rq;
+ ide_task_t *args = (drive)->flush_args;
please don't use HWGROUP() macro,
just use drive->hwif->hwgroup directly
I think I'll leave the code like above here and make another patch which
removes all uses of HWGROUP() and HWGROUP() itself. What do you think
about that?
/*
* write cache disabled, clear the barrier bit and treat it like
@@ -92,10 +75,22 @@ static struct request *ide_queue_flush_c
}
ide_init_drive_cmd(flush_rq);
- ide_fill_flush_cmd(drive, flush_rq);
-
- flush_rq->special = rq;
+ flush_rq->flags = REQ_DRIVE_TASKFILE | REQ_STARTED;
flush_rq->nr_sectors = rq->nr_sectors;
+ flush_rq->special = args;
+ HWGROUP(drive)->flush_real_rq = rq;
ditto
+ memset(args, 0, sizeof(*args));
+
+ if
Re: [PATCH 2.6.11-rc2 29/29] ide: make data_phase explicit in NO_DATA cases
Bartlomiej Zolnierkiewicz wrote:
On Wed, 2 Feb 2005 12:12:38 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
29_ide_explicit_TASKFILE_NO_DATA.patch
Make data_phase explicit in NO_DATA cases.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-ide-export/drivers/ide/ide-disk.c
===
--- linux-ide-export.orig/drivers/ide/ide-disk.c2005-02-02
10:28:07.852771465 +0900
+++ linux-ide-export/drivers/ide/ide-disk.c 2005-02-02 10:28:08.121727827
+0900
@@ -300,6 +300,7 @@ static unsigned long idedisk_read_native
args.tfRegister[IDE_SELECT_OFFSET] = 0x40;
args.tfRegister[IDE_COMMAND_OFFSET] = WIN_READ_NATIVE_MAX;
args.command_type = IDE_DRIVE_TASK_NO_DATA;
+ args.data_phase = TASKFILE_NO_DATA;
args.handler= _no_data_intr;
Could you add small helper to ide.h for doing this?
static inline void ide_prep_no_data_cmd(ide_task_t *task)
{
task->command_type = IDE_DRIVE_TASK_NO_DATA;
task->data_phase = TASKFILE_NO_DATA;
task->handler= _no_data_intr;
}
I am thinking about removing task->handler initialization. Such that it
defaults to task_no_data_intr if data_phase == TASKFILE_NO_DATA and so
on for all other data_phases. Currently, the same information is
specified repeatedly. What do you think?
Also please move this patch earlier in the series
so I can merge it quickly.
Thanks.
Sure.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.4] SIOCSIFNAME wildcard support
Hi Marcelo,
This patch adds wildcard support for the SIOCSIFNAME ioctl,
like what was done in 2.6.1. SIOCSIFNAME allow a user space tool to
change network interface names (such as nameif, ifrename, or ip link),
this patch allow those tools to specify a pattern, such as "eth%d" or
"wlan%d", and the kernel use the lowest available slot.
The reason I'm sending you this patch is that I've got some
2.4.X users who requested the feature...
This patch was initially done for 2.4.23, and I rediffed and
retested with 2.4.29. It's somewhat different from the patch Stephen
and me added to 2.6.1, because the netdev init code is different and
also this patch is more conservative.
Have fun...
Jean
-
diff -u -p linux/net/core/dev.j1.c linux/net/core/dev.c
--- linux/net/core/dev.j1.c Wed Dec 3 14:29:21 2003
+++ linux/net/core/dev.cWed Dec 3 18:55:27 2003
@@ -2179,10 +2179,26 @@ static int dev_ifsioc(struct ifreq *ifr,
case SIOCSIFNAME:
if (dev->flags_UP)
return -EBUSY;
- if (__dev_get_by_name(ifr->ifr_newname))
- return -EEXIST;
- memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ);
- dev->name[IFNAMSIZ-1] = 0;
+ /* Check if name contains a wildcard */
+ if (strchr(ifr->ifr_newname, '%')) {
+ char format[IFNAMSIZ + 1];
+ int ret;
+ memcpy(format, ifr->ifr_newname, IFNAMSIZ);
+ format[IFNAMSIZ-1] = 0;
+ /* Find a free name based on format.
+* dev_alloc_name() replaces "%d" with at max
+* 2 digits, so no name overflow. - Jean II */
+ ret = dev_alloc_name(dev, format);
+ if (ret < 0)
+ return ret;
+ /* Copy the new name back to caller. */
+ strncpy(ifr->ifr_newname, dev->name, IFNAMSIZ);
+ } else {
+ if (__dev_get_by_name(ifr->ifr_newname))
+ return -EEXIST;
+ memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ);
+ dev->name[IFNAMSIZ-1] = 0;
+ }
notifier_call_chain(_chain, NETDEV_CHANGENAME,
dev);
return 0;
@@ -2315,6 +2331,7 @@ int dev_ioctl(unsigned int cmd, void *ar
* - return a value
*/
+ case SIOCSIFNAME:
case SIOCGMIIPHY:
case SIOCGMIIREG:
if (!capable(CAP_NET_ADMIN))
@@ -2350,7 +2367,6 @@ int dev_ioctl(unsigned int cmd, void *ar
case SIOCDELMULTI:
case SIOCSIFHWBROADCAST:
case SIOCSIFTXQLEN:
- case SIOCSIFNAME:
case SIOCSMIIREG:
case SIOCBONDENSLAVE:
case SIOCBONDRELEASE:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] arp_queue: serializing unlink + kfree_skb
On Thu, 3 Feb 2005 22:12:24 +1100 Herbert Xu <[EMAIL PROTECTED]> wrote: > This paradigm is repeated throughout the kernel. I bet the > same race can be found in a lot of those places. So we really > need to sit down and audit them one by one or else come up with > a magical solution apart from disabling SMP :) Ok. I'm commenting now considering Anton's atomic_t rules. Anton, please read down below, I think there is a hole in the PPC memory barriers used for atomic ops on SMP. I don't see what changes are needed anywhere given those rules. Olaf says the problem shows up on PPC SMP system, and since Anton knows the proper rules we hopefully can safely assume he implemented them correctly on PPC :-) I thought for a moment that the atomic_read() might be an issue, and I'd really hate to kill that optimization. But I can't see how it is. Let us restate Olaf's original guess as to the problematic sequence of events: cpu 0 cpu 1 skb_get(skb) unlock(neigh) lock(neigh) __skb_unlink(skb) kfree_skb(sb) kfree_skb(skb) First, __skb_unlink(skb) does an unlocked queue unlink, and these memory operations may have their visibility freely reordered by the processor. However, cpu 1 will see the refcount at 2, so it will execute: atomic_dec_and_test(>users) which has the implicit memory barriers, as Anton stated. This means that the cpu will make the __skb_unlink(skb) results visible globally before the decrement. Now the kfree_skb() on cpu 0 executes, the atomic_read() sees it at 1, we do the __kfree_skb() and since the __skb_unlink() has been made visible before the decrement on the count to "1" the BUG() should not trigger in __kfree_skb(). This all assumes, again, that PPC implements these things properly. Let's take a look (Anton, start reading here). My understanding of PPC memory barriers, wrt. the physical memory coherency domain, is as follows: sync! All previous read/write execute before all subsequent read/write lwsync ! All previous reads execute before all subsequent read/write eieio ! All previous writes execute before all subsequent read/write isync ! All previous memory operations and instructions execute and ! reach global visibility before any subsequent instructions execute What guarentees does isync really make about "read" reordering around the atomic increment? Any descrepencies here would account for the case Olaf observed. All the atomic ops returning values on PPC do this on SMP: eieio atomic_op() isync At a minimum, it seems that the eieio is not strong enough a memory barrier. It is defined to order previous writes against future memory operations, but we also need to strictly order previous reads as well don't we? Also, if my understanding of isync is not correct, that could have implications as well. I guess for performance reasons, ppc doesn't use "sync" both before and after the atomic ops requiring ordering. But I suspect that might be what is actually needed for proper conformity to the atomic_t memory ordering rules. Anton? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: move-accounting-function-calls-out-of-critical-vm-code-paths.patch
On Thu, 3 Feb 2005, Andrew Morton wrote: > Well your patch certainly cleans things up in there and would be a good > thing to have as long as we can be sure that it doesn't break the > accounting in some subtle way. I think it also fits well with the other accounting data which is only statistically probed at clock ticks. > Which implies that we need to see some additional accounting code, so we > can verify that the base accumulation infrastructure is doing the expected > thing. As well as an ack from the interested parties. Does anyone know > what's happening with all the new accounting initiatives? I'm seeing no > activity at all. Well, I'm here :), but I'm concentrating on making a GNU acct release happen. Anyways, as I'm not involved with memory accounting yet, I guess I should leave it to CSA and ELSA people to comment. 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/
Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Itsuro Oda <[EMAIL PROTECTED]> writes: > Hi, > > On 03 Feb 2005 02:00:51 -0700 > [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > > > 5) dump kernel: export all valid physical memory (and saved register > > >information) to the user. (as /dev/oldmem /proc/vmcore ?) > > > > Or in user space, by just mmaping /dev/mem. That is part of the > > current conversation. The only real point for putting that code in > > the kernel (besides momentum) is it is a cheap way to get the exact > > data structures of the kernel you are using. But since: > > (a) it does not look like any primary kernel data structures need to > > be examined. > > (b) even simple compile options like SMP/NOSMP are enough to change > > the layout of the data structures. > > I think there is a pretty good case for moving all of the work to > > user space. But you still need a kernel that loads and > > runs in the reserved area. > > > I don't make sense. what do you mean ? > > What we want to do when the system is crashed is storing the whole > physical memory (and saved register information for x86 arch) to > some place (ex. a disk partition) for later analysis. > So the basic requirments to the dump kernel is that: > * supply a method to access whole (valid) physical memory. > * supply a method to access the saved register information. > > Does the kdump meet this requirment ? Yes, the discussion in this area is what is the best way to implement this requirement. How much should be in the kernel and how much should be in user space. At the moment things are broken but should be fixed shortly. So what has been implemented are /dev/oldmem which provides access to the old memory. And /proc/vmcore which provides both the old memory and the register information. > (I am not interesting to /proc/vmcore. Constructing the vmcore > image is area of analysis tools. not kernel's task.) There is a fine line there, as a simple ELF core dump has just enough information to describe discontiguous memory, and to have an out of band channel for register information. Adding anything extra like virtual addresses that match the kernel should be left for the crash dump analysis tools. In code that is currently in the mainstream kernel /dev/mem can mmap any area of memory that is not used by the kernel as ram. So what I believe we will end up is that /sbin/kexec (user space) will prepare an ELF header (data) that describes the memory regions and details where to find the kernels register information. The address of that ELF header will be passed to the crash dump capture kernel and user space combination. The something (probably a user space program reading /dev/mem) will look at the ELF header and save the already prepared ELF core dump to disk. Possibly doing little things like merging the MAX_NR_CPUS note segments into one so it actually conforms to the ELF spec. This thread started as the design discussion before finishing that part of the implementation. The proof of concept implementations have happened. We have all seen this kind of functionality implemented. Now is the time to come up with a good solid design that can be maintained and merged into the mainline kernel and distros. So thank you for ask questions, it means we have a better chance of getting a solid design and a design that those people who care about this functionality can use. And with a little luck we can all wind up on agreeing on the general principles. You came in a little late to this conversation so a lot of details have been settled, but if you have a good argument for doing something another way we can certainly look at that. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] fix an error in /proc/slabinfo print
There is an obvious error in the header of /proc/slabinfo Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]> --- linux-2.6.11-rc3/mm/slab.c 2005-02-03 13:29:33.0 +0800 +++ linux-2.6.11-rc3-fix/mm/slab.c 2005-02-03 13:32:42.318821400 +0800 @@ -2860,7 +2860,7 @@ static void *s_start(struct seq_file *m, seq_puts(m, "slabinfo - version: 2.1\n"); #endif seq_puts(m, "# name "); - seq_puts(m, " : tunables "); + seq_puts(m, " : tunables "); seq_puts(m, " : slabdata "); #if STATS seq_puts(m, " : globalstat " - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] fix syscallN() macro errno value checking for i386
Followup to: <[EMAIL PROTECTED]>
By author:jerome lacoste <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> what about something along?
>
> #define EKEYNEXT130 /* key counter */
>
> and
>
> if ((unsigned long)(res) >= (unsigned long)(-EKEYNEXT)) {
>
What you really need is EMAX.
-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 2.6.11-rc3] IBM Trackpoint support
On Thursday 03 February 2005 17:43, Stephen Evanchik wrote:
> Vojtech,
>
> Here is a patch that exposes the IBM TrackPoint's extended properties
> as well as scroll wheel emulation.
>
>
Hi,
Very nice although I have a couple of comments.
> /*
> + * Try to initialize the IBM TrackPoint
> + */
> + if (max_proto > PSMOUSE_PS2 && trackpoint_init(psmouse) == 0) {
> + psmouse->vendor = "IBM";
> + psmouse->name = "TrackPoint";
> +
> + return PSMOUSE_PS2;
Why PSMOUSE_PS2? Reconnect will surely not like it.
> +int tp_sens = TP_DEF_SENS;
> +module_param_named(sens, tp_sens, uint, 0);
> +MODULE_PARM_DESC(sens, "Sensitivity");
> +int tp_mb_scroll = TP_DEF_MB_SCROLL;
> +module_param_named(mb_scroll, tp_mb_scroll, uint, 0);
> +MODULE_PARM_DESC(mb_scroll, "Scroll with middle button");
All of this should be handled via sysfs dynamically, we don't need any
more pmouse module parameters.
> +__obsolete_setup("pts=");
> +__obsolete_setup("backup=");
> +__obsolete_setup("draghyst=");
What are these? They can't be obsolete as the module has never been part
of the vanilla kernel.
> +
> +/*
> + * Device IO: read, write and toggle bit
> + */
> +static void trackpoint_command(struct ps2dev *ps2dev, unsigned char cmd)
> +{
> + ps2_command(ps2dev, NULL, MAKE_PS2_CMD(0, 0, TP_COMMAND));
> + ps2_command(ps2dev, NULL, MAKE_PS2_CMD(0, 0, cmd));
> +}
> +
Error checking would be nice.
> +
> +#ifdef CONFIG_PROC_FS
...
> +{
> +remove_proc_entry("scroll_delay", tp_dir);
> +remove_proc_entry("scroll", tp_dir);
> +remove_proc_entry("transparent", tp_dir);
> +remove_proc_entry("ext_dev", tp_dir);
> +remove_proc_entry("mb", tp_dir);
> +remove_proc_entry("skip_back", tp_dir);
> +remove_proc_entry("ptson", tp_dir);
> +remove_proc_entry("jenks_curv", tp_dir);
> +remove_proc_entry("z_time", tp_dir);
> +remove_proc_entry("up_thresh", tp_dir);
> +remove_proc_entry("thresh", tp_dir);
> +remove_proc_entry("min_drag", tp_dir);
> +remove_proc_entry("drag_hyst", tp_dir);
> +remove_proc_entry("backup", tp_dir);
> +remove_proc_entry("neg_inertia", tp_dir);
> +remove_proc_entry("speed", tp_dir);
> +remove_proc_entry("sensitivity", tp_dir);
> +remove_proc_entry("trackpoint", NULL);
> +}
No new proc stuff please (it will be visible from sysfs when you redo the
module parameters).
> +
> + tp->scrolling = 0;
> + tp->mb_was_down = 0;
> + }
> +else if(tp->scrolling) {
> +
> + /* Vertical scrolling */
> + diff = (int) ((packet[0] << 3) & 0x100) - (int) packet[2];
> +if( diff < -2 ) {
> + input_report_rel(>dev, REL_WHEEL, 1);
> + }
> + else if(diff > 2) {
> + input_report_rel(>dev, REL_WHEEL, -1);
> + }
> +
> +/* Horizontal scrolling */
> +diff = (int) packet[1] - (int) ((packet[0] << 4) & 0x100);
> +if( diff < -2) {
> +input_report_rel(>dev, REL_HWHEEL, 1);
> +}
> +else if( diff > 2) {
> +input_report_rel(>dev, REL_HWHEEL, -1);
> +}
> +
> + packet[1] &= 0x00;
> + packet[2] &= 0x00;
> + }
Looks like whitespace damage (tabs vs spaces) plus it should be "} else {"
on one line.
> +int trackpoint_reconnect(struct psmouse *psmouse)
> +{
> + unsigned char toggle;
> + struct trackpoint_data *tp = psmouse->private;
> +
> + /* Push the config to the device */
> +
I'd like to verify that it still recognized as trackpoint - suspends often
play tricks on PS/2 devices.
> +
> + printk("IBM TrackPoint firmware: 0x%02X\n", param[1]);
KERN_INFO?
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
* Ingo Molnar ([EMAIL PROTECTED]) wrote: > i believe RT-LSM provides a way to solve this cleanly: you can make your > audio app setguid-audio (note: NOT setuid), and make the audio group > have CAP_SYS_NICE-equivalent privilege via the RT-LSM, and then you > could have a finegrained per-app way of enabling SCHED_FIFO scheduling, > without giving _users_ the blanket permission to SCHED_FIFO. Ok? > > this way if jackd (or a client) gets run by _any_ user, all jackd > processes will be part of the audio group and can do SCHED_FIFO - but > users are not automatically trusted with SCHED_FIFO. > > you are currently using RT-LSM to enable a user to do SCHED_FIFO, right? > I think the above mechanism is more secure and more finegrained than > that. No, rt-lsm is actually gid based. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 21/29] ide: Merge do_rw_taskfile() and flagged_taskfile().
Hello, Bartlomiej Zolnierkiewicz wrote: On Wed, 2 Feb 2005 12:06:03 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: 21_ide_do_taskfile.patch Merged do_rw_taskfile() and flagged_taskfile() into do_taskfile(). During the merge, the following changes took place. 1. flagged taskfile now honors HOB feature register. (do_rw_taskfile() did write to HOB feature.) 2. No do_rw_taskfile() HIHI check on select register. Except for the DEV bit, all bits are honored. 3. Uses taskfile->data_phase to determine if dma trasfer is requested. (do_rw_taskfile() directly switched on taskfile->command for all dma commands) Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> do_rw_taskfile() is going to be used by fs requests once __ide_do_rw_disk() is converted to taskfile transport. I don't think that do_rw_taskfile() and flagged_taskfile() merge is a good thing as it adds unnecessary overhead for hot path (fs requests). Yeah, I also thought about that, but here are reasons why I still think merging is better. 1. The added overhead is small. It's just a dozen more if's per every disk io. I don't think it will make any noticeable difference. 2. If hot path optimization is needed, it can be easily done inside one do_taskfile() function with one or two more if's. 3. Currently, do_rw_taskfile() isn't used by __ide_do_rw_disk(). We can think about optimization when actually converting it to use taskfile transport. And IMHO, if hot path optimization is needed, leaving hot path optimization where it is now (inside __ide_do_rw_disk()) is better than moving it to separate taskfile function (do_rw_taskfile()). -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Race condition in ptrace
Bodo Stroesser wrote:
Working with the new UML skas0 mode on my Xeon HT host, sporadically I saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment
register,
that had the wrong contents.
This again is caused by a problem in the host linux: A ptraced child
going to
stop and having woken up its parent, will save some of its registers (on
i386
they are fs, gs and the fp-registers) very late in switch_to. The parent is
granted access to child's registers as soon, as the child is removed from
the runqueue. Thus, in rare cases, the parent might access child's register
savearea before the registers really are saved.
This problem might also be the reason for problems with floatpoint on UML,
that were reported some time ago.
I've written a test program, that reproduces the problem on my 2.6.9
vanilla
host quite quick. Using SuSE kernel 2.6.5-7.97-smp, I can't reproduce the
problem, although the relevant parts seem to be unchanged. Maybe not
related
changes modify the timing?
I also created a patch, that fixes the problem on my 2.6.9 host. This
probably
isn't a sane patch, but is enough to demonstrate, where I think, the bug
is.
Both files are attached.
Bodo
--- a/include/linux/sched.h 2005-02-02 22:15:51.0 +0100
+++ b/include/linux/sched.h 2005-02-02 22:22:54.0 +0100
@@ -584,6 +584,7 @@ struct task_struct {
struct mempolicy *mempolicy;
short il_next; /* could be shared with used_math */
#endif
+ volatile long saving;
};
static inline pid_t process_group(struct task_struct *tsk)
--- a/kernel/sched.c 2005-02-02 21:32:51.0 +0100
+++ b/kernel/sched.c 2005-02-02 22:12:14.0 +0100
@@ -2689,8 +2689,10 @@ need_resched:
if (unlikely((prev->state & TASK_INTERRUPTIBLE) &&
unlikely(signal_pending(prev
prev->state = TASK_RUNNING;
- else
+ else {
+ prev->saving = 1;
deactivate_task(prev, rq);
+ }
}
cpu = smp_processor_id();
--- a/kernel/ptrace.c 2005-02-02 22:12:33.0 +0100
+++ b/kernel/ptrace.c 2005-02-02 22:20:46.0 +0100
@@ -96,6 +96,7 @@ int ptrace_check_attach(struct task_stru
if (!ret && !kill) {
wait_task_inactive(child);
+ while ( child->saving ) ;
}
/* All systems go.. */
--- a/arch/i386/kernel/process.c 2005-02-02 22:18:29.0 +0100
+++ b/arch/i386/kernel/process.c 2005-02-02 22:19:22.0 +0100
@@ -577,6 +577,9 @@ struct task_struct fastcall * __switch_t
asm volatile("movl %%fs,%0":"=m" (*(int *)>fs));
asm volatile("movl %%gs,%0":"=m" (*(int *)>gs));
+ wmb();
+ prev_p->saving=0;
+
/*
* Restore %fs and %gs if needed.
*/
I don't see how this could help because AFAIKS, child->saving is only
set and cleared while the runqueue is locked. And the same runqueue lock
is taken by wait_task_inactive.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Hi, On 02 Feb 2005 07:45:11 -0700 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > And the feedback begins :) > > Itsuro Oda <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I don't like calling crash_kexec() directly in (ex.) panic(). > > It should be call_dump_hook() (or something like this). > > > > I think the necessary modifications of the kernel is only: > > - insert the hooks that calls a dump function when crash occur > crash_kexec() > > - binding interface that binds a dump function to the hook > > (like register_dump_hook()) > sys_kexec_load(...); For example there are pepole who want to execute a built in kernel debugger when the system is crashed. or there are pepole who believe the diskdump is the best dump tool :-) So I think a sort of hook is better than calling crash_kexec directly. (May I make a patch ?) Thanks. -- Itsuro ODA <[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] invalidate range of pages after direct IO write
Zach Brown <[EMAIL PROTECTED]> wrote: > > After a direct IO write only invalidate the pages that the write intersected. > invalidate_inode_pages2_range(mapping, pgoff start, pgoff end) is added and > called from generic_file_direct_IO(). This doesn't break some subtle > agreement > with some other part of the code, does it? It should be OK. Note that the same optimisation should be made in the call to unmap_mapping_range() in generic_file_direct_IO(). Currently we try and unmap the whole file, even if we're only writing a single byte. Given that you're now calculating iov_length() in there we might as well use that number a few lines further up in that function. Note that invalidate_inode_pages[_range2] also does the unmapping thing - in the direct-io case we don't expect that path th ever trigger: the only way we'll find mapped pages here is if someone raced and faulted a page back in. Reading the code, I'm unable to convince myself that it won't go into an infinite loop if it finds a page at page->index = -1. But I didn't try very hard ;) Minor note on this: return invalidate_inode_pages2_range(mapping, 0, ~0UL); I just use `-1' there. We don't _know_ that pgoff_t is an unsigned long. Some smarty may come along one day and make it unsigned long long, in which case the code will break. Using -1 here just works everywhere. I'll make that change and plop the patch into -mm, but we need to think about the infinite-loop problem.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.10: kswapd spins like crazy
Terje FÃberg wrote: Terje FÃberg <[EMAIL PROTECTED]> skrev: The kernel is compiling right now, but I cannot reboot this machine until six or seven o'clock tonight (CET). I will report then. Well, well, I rebooted the same kernel, now with MAGIC-SYSRQ enabled. At first the kswapd-effect wouldn't show up, but now the image is much clearer than before. kswapd eats constantly 95% cpu time while the system is "idle". The System is quite sluggish. Switching between applications needs ages. After Eclipse has been active for a few minutes, I it lasts 45 seconds until enough of Mozilla is swapped back in, and Mozilla has redrawn its window. Complete info including SysRq-Meminfo is attached. Thanks very much, this is a good help. galileo:~# cat /proc/vmstat > pre ; sleep 10 ; cat /proc/vmstat > post galileo:~# cat pre ... pgscan_kswapd_high 0 pgscan_kswapd_normal 2504667 pgscan_kswapd_dma 615532032 ... galileo:~# cat post ... pgscan_kswapd_high 0 pgscan_kswapd_normal 2504667 pgscan_kswapd_dma 649881006 ... So we can see it is trying to scan the DMA zone. galileo:~# dmesg [...] SysRq : Show Memory Mem-info: DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 HighMem per-cpu: empty Free pages:7872kB (0kB HighMem) Active:48698 inactive:86241 dirty:0 writeback:0 unstable:0 free:1968 slab:4509 mapped:50560 pagetables:1717 DMA free:80kB min:80kB low:100kB high:120kB active:0kB inactive:11716kB present:16384kB pages_scanned:123 all_unreclaimable? no protections[]: 0 0 0 This is the reason why: DMA only has 80K free, and kswapd won't stop until either 120K is free, or all_unreclaimable gets switched on. Now clearly all_unreclaimable should be getting set if nothing can be reclaimed (although it is possible that non pagecache allocating and freeing can mess it up, that's unlikely). Hmm, your DMA zone has no active pages, and pages_scanned (which triggers all_unreclaimable) is only incremented when scanning the active list. But I wonder, if the pages can't be freed, why aren't they being put on the active list? Nick PS. let's not release 2.6.11 just yet :\ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][I2C] Marvell mv64xxx i2c driver
Alexey Dobriyan wrote: On Thursday 03 February 2005 21:12, Mark A. Greer wrote: + mv64xxx_i2c_fsm(drv_data, status); It can set drv_data->rc to -ENODEV or -EIO. In both cases ->action goes to MV64XXX_I2C_ACTION_SEND_STOP and mv64xxx_i2c_do_action() will writel() something. Is it correct to _not_ check ->rc here? I think so. It still needs to go into do_action even when rc != 0 (in which case it'll do a STOP condition). Ok. Thanks for the explanation. Agree, ->rc should be left as is. Okay. --- a/include/linux/i2c-id.h +++ b/include/linux/i2c-id.h + /* 0x17 - USB */ + /* 0x18 - Virtual buses */ +#define I2C_ALGO_MV64XXX 0x19 /* Marvell mv64xxx i2c ctlr */ While I searched for typos and you're fixing them, au1550 owned 0x17. 2.6.11-rc3 says: #define I2C_ALGO_AU1550 0x17 /* Au1550 PSC algorithm */ So, I'd remove first two comments. I added the comments b/c of this email from Jean Delvare, http://www.uwsg.iu.edu/hypermail/linux/kernel/0501.3/0977.html. The relevant part being: "0x17 is reserved within the legacy i2c project for an USB algorithm, and 0x18 for virtual busses. Could you please use 0x19 instead, so as to avoid future collisions?" It looks like I2C_ALGO_AU1550 was just added so my guess is Jean is correct and I2C_ALGO_AU1550 should be made 0x1a (or I move mine back one). Would someone confirm that 0x17 is used by legacy i2c stuffs? I don't really know where to look. If so, I can easily make a patch moving it back. Oh, and the last note: current sparse and gcc 4 don't produce any warnings. Cool! Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
