[patch 0/9] x86, xsave: xsave/xrstor support - Kernel

This is a discussion on [patch 0/9] x86, xsave: xsave/xrstor support - Kernel ; > Kernel was enabling watchdog, with out the userspace having the > heartbeat daemon.... Watchdog are normally only armed when someone opens the device first. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 33 of 33

Thread: [patch 0/9] x86, xsave: xsave/xrstor support

  1. Re: [patch 0/9] x86, xsave: xsave/xrstor support

    > Kernel was enabling watchdog, with out the userspace having the
    > heartbeat daemon....


    Watchdog are normally only armed when someone opens the device
    first.

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

  2. Re: [patch 0/9] x86, xsave: xsave/xrstor support

    On Thu, Jul 31, 2008 at 03:19:24PM -0700, Suresh Siddha wrote:
    > On Thu, Jul 31, 2008 at 03:14:35PM -0700, Andi Kleen wrote:
    > > > Kernel was enabling watchdog, with out the userspace having the
    > > > heartbeat daemon....

    > >
    > > Watchdog are normally only armed when someone opens the device
    > > first.

    >
    > But thats not what I see with for ex with, w83627hf_wdt.c
    >
    > Its done at the module_init time. (while I thought it should be
    > really done when some user level app opens the device, probably
    > its poorly written to take care if the kernel panics before starting userland.
    > but kernel can even die before the watchdog driver load aswell ;-)


    Ok that watchdog driver is just broken then. Putting the watchdog maintainer
    into cc.

    -Andi
    >

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

  3. Re: [patch 0/9] x86, xsave: xsave/xrstor support



    On Thu, 31 Jul 2008, Suresh Siddha wrote:
    > On Thu, Jul 31, 2008 at 03:14:35PM -0700, Andi Kleen wrote:
    > > > Kernel was enabling watchdog, with out the userspace having the
    > > > heartbeat daemon....

    > >
    > > Watchdog are normally only armed when someone opens the device
    > > first.

    >
    > But thats not what I see with for ex with, w83627hf_wdt.c
    >
    > Its done at the module_init time. (while I thought it should be
    > really done when some user level app opens the device, probably
    > its poorly written to take care if the kernel panics before starting userland.
    > but kernel can even die before the watchdog driver load aswell ;-)


    Yeah, that's a _really_ broken watchdog timer driver. There's no way that
    it's correct to start the watchdog at init time, at least when compiled
    in.

    It also looks to me like it's not even probing for the hardware - it's
    just assuming it's there. That's scary. Am I missing something?

    It really shouldn't be activated until it's opened. And it really
    shouldn't just write to ports randomly without checking that they make
    sense...

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

  4. Re: [patch 0/9] x86, xsave: xsave/xrstor support


    * Linus Torvalds wrote:

    > > But thats not what I see with for ex with, w83627hf_wdt.c
    > >
    > > Its done at the module_init time. (while I thought it should be
    > > really done when some user level app opens the device, probably its
    > > poorly written to take care if the kernel panics before starting
    > > userland. but kernel can even die before the watchdog driver load
    > > aswell ;-)

    >
    > Yeah, that's a _really_ broken watchdog timer driver. There's no way
    > that it's correct to start the watchdog at init time, at least when
    > compiled in.
    >
    > It also looks to me like it's not even probing for the hardware - it's
    > just assuming it's there. That's scary. Am I missing something?
    >
    > It really shouldn't be activated until it's opened. And it really
    > shouldn't just write to ports randomly without checking that they make
    > sense...


    there are a handful of old ISA-ish drivers that can crash randconfig
    kernels in various ways. [indefinite lockups, crashes, stomped-over
    hardware, non-working keyboard, etc.]

    I mapped most of them out via many months of trial-and-error - but it
    would still be nice to have some separate config option to disable the
    known ones. CONFIG_ALLOW_NON_GENERIC or something like that - which i
    would unset in the randconfig runs.

    ( They are not CONFIG_BROKEN per se, because often it's hardware that
    cannot be probed in any reliable way - the driver just assumes it's
    there. )

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

  5. Re: [patch 0/9] x86, xsave: xsave/xrstor support

    > But thats not what I see with for ex with, w83627hf_wdt.c
    >
    > Its done at the module_init time. (while I thought it should be
    > really done when some user level app opens the device, probably
    > its poorly written to take care if the kernel panics before starting userland.
    > but kernel can even die before the watchdog driver load aswell ;-)


    Various watchdogs fail to conform in assorted differing ways. Wim did
    some patches to build a common watchdog library and I sent him a rework
    of it a while ago. Once that is adopted this should all get cleaned up.
    Right now Wim is a bit busy however.

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

  6. Re: [patch 0/9] x86, xsave: xsave/xrstor support

    On 01-08-08 00:50, Ingo Molnar wrote:

    > there are a handful of old ISA-ish drivers that can crash randconfig
    > kernels in various ways. [indefinite lockups, crashes, stomped-over
    > hardware, non-working keyboard, etc.]
    >
    > I mapped most of them out via many months of trial-and-error - but it
    > would still be nice to have some separate config option to disable the
    > known ones. CONFIG_ALLOW_NON_GENERIC or something like that - which i
    > would unset in the randconfig runs.
    >
    > ( They are not CONFIG_BROKEN per se, because often it's hardware that
    > cannot be probed in any reliable way - the driver just assumes it's
    > there. )


    If you have a list, I might be able to do something about some of them.

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

  7. Re: [patch 0/9] x86, xsave: xsave/xrstor support


    * Rene Herman wrote:

    > On 01-08-08 00:50, Ingo Molnar wrote:
    >
    >> there are a handful of old ISA-ish drivers that can crash randconfig
    >> kernels in various ways. [indefinite lockups, crashes, stomped-over
    >> hardware, non-working keyboard, etc.]
    >>
    >> I mapped most of them out via many months of trial-and-error - but it
    >> would still be nice to have some separate config option to disable the
    >> known ones. CONFIG_ALLOW_NON_GENERIC or something like that - which i
    >> would unset in the randconfig runs.
    >>
    >> ( They are not CONFIG_BROKEN per se, because often it's hardware that
    >> cannot be probed in any reliable way - the driver just assumes it's
    >> there. )

    >
    > If you have a list, I might be able to do something about some of
    > them.


    find attached below a newer version of the original list i published
    half a year ago:

    http://people.redhat.com/mingo/auto-...onfig-qa.patch

    these are just pragmatic local hacks to get things going. (There are
    more per machine quirks as well.)

    i have not used a BROKEN annotation because CONFIG_BROKEN is
    impractical: it just kills code altogether, indiscriminately. There's no
    way for users to enable CONFIG_BROKEN in the upstream kernel - nothing
    selects it and it's not an interactive option either.

    So by all means if we mark a driver or a kernel feature as
    CONFIG_BROKEN, it's killed altogether for all practical purposes.

    What we'd need is some more gradual approach: for example a way to mark
    "drivers that are not expected to boot on a whitebox PC", without
    removing them altogether via a CONFIG_BROKEN dependency - often it's
    hardware that cannot be probed safely.

    Ingo

    ------------------>
    Index: linux/security/smack/Kconfig
    ================================================== =================
    --- linux.orig/security/smack/Kconfig
    +++ linux/security/smack/Kconfig
    @@ -1,6 +1,9 @@
    config SECURITY_SMACK
    bool "Simplified Mandatory Access Control Kernel Support"
    depends on NETLABEL && SECURITY_NETWORK
    + # breaks networking (TCP connections)
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT
    default n
    help
    This selects the Simplified Mandatory Access Control Kernel.
    Index: linux/drivers/block/Kconfig
    ================================================== =================
    --- linux.orig/drivers/block/Kconfig
    +++ linux/drivers/block/Kconfig
    @@ -71,6 +71,11 @@ config BLK_DEV_XD
    config PARIDE
    tristate "Parallel port IDE device support"
    depends on PARPORT_PC
    +
    + # the probe can hang during bootup on non-PARIDE boxes
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if PARIDE = y
    +
    ---help---
    There are many external CD-ROM and disk devices that connect through
    your computer's parallel port. Most of them are actually IDE devices
    Index: linux/drivers/i2c/busses/Kconfig
    ================================================== =================
    --- linux.orig/drivers/i2c/busses/Kconfig
    +++ linux/drivers/i2c/busses/Kconfig
    @@ -610,6 +610,11 @@ config I2C_ELEKTOR
    config I2C_PCA_ISA
    tristate "PCA9564 on an ISA bus"
    depends on ISA
    +
    + # takes away IRQ10 on venus and thus breaks e1000
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT
    +
    select I2C_ALGOPCA
    default n
    help
    Index: linux/drivers/ide/Kconfig
    ================================================== =================
    --- linux.orig/drivers/ide/Kconfig
    +++ linux/drivers/ide/Kconfig
    @@ -9,6 +9,11 @@ config HAVE_IDE
    menuconfig IDE
    tristate "ATA/ATAPI/MFM/RLL support"
    depends on HAVE_IDE
    +
    + # my test box expects /dev/sda, not /dev/hda
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if IDE = y
    +
    depends on BLOCK
    ---help---
    If you say Y here, your kernel will be able to manage low cost mass
    Index: linux/drivers/isdn/icn/Kconfig
    ================================================== =================
    --- linux.orig/drivers/isdn/icn/Kconfig
    +++ linux/drivers/isdn/icn/Kconfig
    @@ -4,6 +4,11 @@
    config ISDN_DRV_ICN
    tristate "ICN 2B and 4B support"
    depends on ISA
    +
    + # crashed on venus, see config-Sun_May_25_11_00_41_CEST_2008.bad
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT
    +
    help
    This enables support for two kinds of ISDN-cards made by a German
    company called ICN. 2B is the standard version for a single ISDN
    Index: linux/drivers/media/video/Kconfig
    ================================================== =================
    --- linux.orig/drivers/media/video/Kconfig
    +++ linux/drivers/media/video/Kconfig
    @@ -481,6 +481,9 @@ config VIDEO_SAA6588
    config VIDEO_PMS
    tristate "Mediavision Pro Movie Studio Video For Linux"
    depends on ISA && VIDEO_V4L1
    + # hung on bootup on mars, see config-Wed_Jun__4_14_33_56_CEST_2008.bad
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT
    help
    Say Y if you have such a thing.

    Index: linux/drivers/mtd/Kconfig
    ================================================== =================
    --- linux.orig/drivers/mtd/Kconfig
    +++ linux/drivers/mtd/Kconfig
    @@ -1,6 +1,11 @@
    menuconfig MTD
    tristate "Memory Technology Device (MTD) support"
    depends on HAS_IOMEM
    +
    + # dangerous to enable - sometimes hangs on probe
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if MTD = y
    +
    help
    Memory Technology Devices are flash, RAM and similar chips, often
    used for solid state file systems on embedded devices. This option
    Index: linux/drivers/net/appletalk/Kconfig
    ================================================== =================
    --- linux.orig/drivers/net/appletalk/Kconfig
    +++ linux/drivers/net/appletalk/Kconfig
    @@ -52,6 +52,11 @@ config LTPC
    config COPS
    tristate "COPS LocalTalk PC support"
    depends on DEV_APPLETALK && (ISA || EISA)
    + #
    + # Can hang
    + #
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if COPS = y
    help
    This allows you to use COPS AppleTalk cards to connect to LocalTalk
    networks. You also need version 1.3.3 or later of the netatalk
    Index: linux/drivers/scsi/Kconfig
    ================================================== =================
    --- linux.orig/drivers/scsi/Kconfig
    +++ linux/drivers/scsi/Kconfig
    @@ -1520,6 +1520,11 @@ config SCSI_NSP32
    config SCSI_DEBUG
    tristate "SCSI debugging host simulator"
    depends on SCSI
    +
    + # this creates a fake /dev/sda which confuses the bzImage bootup
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if SCSI_DEBUG = y
    +
    help
    This is a host adapter simulator that can simulate multiple hosts
    each with multiple dummy SCSI devices (disks). It defaults to one
    Index: linux/drivers/video/Kconfig
    ================================================== =================
    --- linux.orig/drivers/video/Kconfig
    +++ linux/drivers/video/Kconfig
    @@ -236,6 +236,11 @@ comment "Frame buffer hardware drivers"

    config FB_CIRRUS
    tristate "Cirrus Logic support"
    +
    + # can hang on a box without this hardware
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if FB_CIRRUS = y
    +
    depends on FB && (ZORRO || PCI)
    select FB_CFB_FILLRECT
    select FB_CFB_COPYAREA
    @@ -546,6 +551,11 @@ config FB_CT65550

    config FB_ASILIANT
    bool "Asiliant (Chips) 69000 display support"
    +
    + # can hang on a box without this hardware
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if FB_ASILIANT = y
    +
    depends on (FB = y) && PCI
    select FB_CFB_FILLRECT
    select FB_CFB_COPYAREA
    @@ -564,6 +574,11 @@ config FB_IMSTT

    config FB_VGA16
    tristate "VGA 16-color graphics support"
    +
    + # can hang on a box without this hardware
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if FB_VGA16 = y
    +
    depends on FB && (X86 || PPC)
    select FB_CFB_FILLRECT
    select FB_CFB_COPYAREA
    @@ -674,6 +689,11 @@ config FB_UVESA

    config FB_VESA
    bool "VESA VGA graphics support"
    +
    + # can hang on a box without this hardware
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if FB_VESA = y
    +
    depends on (FB = y) && X86
    select FB_CFB_FILLRECT
    select FB_CFB_COPYAREA
    @@ -1299,6 +1319,11 @@ config FB_MATROX_MULTIHEAD

    config FB_RADEON
    tristate "ATI Radeon display support"
    +
    + # can hang on a box without this hardware
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if FB_RADEON = y
    +
    depends on FB && PCI
    select FB_BACKLIGHT if FB_RADEON_BACKLIGHT
    select FB_MODE_HELPERS
    @@ -1581,6 +1606,11 @@ config FB_VT8623

    config FB_CYBLA
    tristate "Cyberblade/i1 support"
    +
    + # can hang on a box without this hardware
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if FB_CYBLA = y
    +
    depends on FB && PCI && X86_32 && !64BIT
    select FB_CFB_IMAGEBLIT
    select VIDEO_SELECT
    @@ -2006,6 +2036,11 @@ config FB_SH7760

    config FB_VIRTUAL
    tristate "Virtual Frame Buffer support (ONLY FOR TESTING!)"
    +
    + # can hang on a box without this hardware
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if FB_VIRTUAL = y
    +
    depends on FB
    select FB_SYS_FILLRECT
    select FB_SYS_COPYAREA
    Index: linux/drivers/video/console/Kconfig
    ================================================== =================
    --- linux.orig/drivers/video/console/Kconfig
    +++ linux/drivers/video/console/Kconfig
    @@ -61,6 +61,11 @@ config VIDEO_SELECT

    config MDA_CONSOLE
    depends on !M68K && !PARISC && ISA
    +
    + # can hang on a box without this hardware
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if MDA_CONSOLE = y
    +
    tristate "MDA text console (dual-headed) (EXPERIMENTAL)"
    ---help---
    Say Y here if you have an old MDA or monochrome Hercules graphics
    @@ -113,6 +118,10 @@ config DUMMY_CONSOLE_ROWS

    config FRAMEBUFFER_CONSOLE
    tristate "Framebuffer Console support"
    +
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if FRAMEBUFFER_CONSOLE = y
    +
    depends on FB
    select CRC32
    help
    Index: linux/drivers/watchdog/Kconfig
    ================================================== =================
    --- linux.orig/drivers/watchdog/Kconfig
    +++ linux/drivers/watchdog/Kconfig
    @@ -324,6 +324,12 @@ config SC520_WDT
    config EUROTECH_WDT
    tristate "Eurotech CPU-1220/1410 Watchdog Timer"
    depends on X86
    +
    + # this ISA driver puts itself on IRQ10 - if IRQ10 happens to
    + # trigger then that will cause a watchdog-initiated reboot
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if EUROTECH_WDT = y
    +
    help
    Enable support for the watchdog timer on the Eurotech CPU-1220 and
    CPU-1410 cards. These are PC/104 SBCs. Spec sheets and product
    @@ -830,6 +836,11 @@ config MIXCOMWD
    config WDT
    tristate "WDT Watchdog timer"
    depends on ISA
    +
    + # this ISA driver sits on IRQ11 by default - blocking forcedeth
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT if WDT = y
    +
    ---help---
    If you have a WDT500P or WDT501P watchdog board, say Y here,
    otherwise N. It is not possible to probe for this board, which means
    Index: linux/fs/Kconfig
    ================================================== =================
    --- linux.orig/fs/Kconfig
    +++ linux/fs/Kconfig
    @@ -1636,6 +1636,11 @@ config NFS_V4
    config ROOT_NFS
    bool "Root file system on NFS"
    depends on NFS_FS=y && IP_PNP
    +
    + # hangs a non-root-NFS box during bootup
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT
    +
    help
    If you want your system to mount its root file system via NFS,
    choose Y here. This is common practice for managing systems
    Index: linux/security/Kconfig
    ================================================== =================
    --- linux.orig/security/Kconfig
    +++ linux/security/Kconfig
    @@ -85,6 +85,11 @@ config SECURITY_FILE_CAPABILITIES
    config SECURITY_ROOTPLUG
    bool "Root Plug Support"
    depends on USB=y && SECURITY
    +
    + # fails with hard-to-debug "could not find init" boot failure
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT
    +
    help
    This is a sample LSM module that should only be used as such.
    It prevents any programs running with egid == 0 if a specific
    Index: linux/security/selinux/Kconfig
    ================================================== =================
    --- linux.orig/security/selinux/Kconfig
    +++ linux/security/selinux/Kconfig
    @@ -100,6 +100,11 @@ config SECURITY_SELINUX_CHECKREQPROT_VAL
    config SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT
    bool "NSA SELinux enable new secmark network controls by default"
    depends on SECURITY_SELINUX
    +
    + # old system booted up with this cannot ssh out
    + depends on BROKEN_BOOT_ALLOWED
    + select BROKEN_BOOT
    +
    default n
    help
    This option determines whether the new secmark-based network
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [patch 0/9] x86, xsave: xsave/xrstor support

    On 01-08-08 11:51, Ingo Molnar wrote:

    > find attached below a newer version of the original list i published
    > half a year ago:
    >
    > http://people.redhat.com/mingo/auto-...onfig-qa.patch
    >
    > these are just pragmatic local hacks to get things going. (There are
    > more per machine quirks as well.)
    >
    > i have not used a BROKEN annotation because CONFIG_BROKEN is
    > impractical: it just kills code altogether, indiscriminately. There's no
    > way for users to enable CONFIG_BROKEN in the upstream kernel - nothing
    > selects it and it's not an interactive option either.
    >
    > So by all means if we mark a driver or a kernel feature as
    > CONFIG_BROKEN, it's killed altogether for all practical purposes.
    >
    > What we'd need is some more gradual approach: for example a way to mark
    > "drivers that are not expected to boot on a whitebox PC", without
    > removing them altogether via a CONFIG_BROKEN dependency - often it's
    > hardware that cannot be probed safely.


    For real ISA at the least, the best fix I feel is just not go grabbing
    resources without anything (ie, ISAPnP) or anyone (ie, the user) telling
    us that's where the hardware's at.

    For example, for the first real ISA driver in the list:

    > Index: linux/drivers/i2c/busses/Kconfig
    > ================================================== =================
    > --- linux.orig/drivers/i2c/busses/Kconfig
    > +++ linux/drivers/i2c/busses/Kconfig
    > @@ -610,6 +610,11 @@ config I2C_ELEKTOR
    > config I2C_PCA_ISA
    > tristate "PCA9564 on an ISA bus"
    > depends on ISA
    > +
    > + # takes away IRQ10 on venus and thus breaks e1000
    > + depends on BROKEN_BOOT_ALLOWED
    > + select BROKEN_BOOT
    > +


    The attached would be my preffered approach to this.

    (to avoid an IRQ 0 discussion -- the middle hunk is unrelated, just
    makes it consistent with the rest of the file)

    (and this uses the isa_bus match() method as intended; the idea of the
    isa_bus is to make it look at least somewhat like a sane bus such as PCI
    which includes only failing a load if there's no way a later bind could
    conceivably succeed. somewhat debatable merit sometimes, but such is the
    device model, and it's actually fairly nice once you get used to it for
    quickly switching drivers for a single piece of hardware)

    A user of this hardware is a one-time

    $ echo options i2c-pca-isa base=0x330 irq=10 >> /etc/modprobe.conf

    away from the old behaviour. Given the hackish nature of all this kind
    of hardware these days its users tend to not mind. In fact, what with
    getting old hardware to play nice with modern systems, I myself at least
    very much welcome having to be explicit about these things.

    (and just saw the CC list on this thing while adding Wolfram. ouch. will
    be dropping all from any followups...)

    Rene.

    From 58f25a608b827426bf5c110795dd7e917e9cc568 Mon Sep 17 00:00:00 2001
    From: Rene Herman
    Date: Fri, 1 Aug 2008 15:35:31 +0200
    Subject: [PATCH] i2c: don't autograb i2c-pca-isa

    Grabbing resources without anything telling us we should can break
    randconfig builds by keeping them busy. Insist that when hardware
    is not capable of telling us, the user does.

    Signed-off-by: Rene Herman
    ---
    drivers/i2c/busses/i2c-pca-isa.c | 20 +++++++++++++++++---
    1 files changed, 17 insertions(+), 3 deletions(-)

    diff --git a/drivers/i2c/busses/i2c-pca-isa.c b/drivers/i2c/busses/i2c-pca-isa.c
    index a119784..2579169 100644
    --- a/drivers/i2c/busses/i2c-pca-isa.c
    +++ b/drivers/i2c/busses/i2c-pca-isa.c
    @@ -36,8 +36,8 @@
    #define DRIVER "i2c-pca-isa"
    #define IO_SIZE 4

    -static unsigned long base = 0x330;
    -static int irq = 10;
    +static unsigned long base;
    +static int irq = -1;

    /* Data sheet recommends 59kHz for 100kHz operation due to variation
    * in the actual clock rate */
    @@ -107,6 +107,19 @@ static struct i2c_adapter pca_isa_ops = {
    .timeout = 100,
    };

    +static int __devinit pca_isa_match(struct device *dev, unsigned int id)
    +{
    + int match = base != 0;
    +
    + if (match) {
    + if (irq == -1)
    + dev_warn(dev, "using poling mode (specify irq)\n");
    + } else
    + dev_err(dev, "please specify base\n");
    +
    + return match;
    +}
    +
    static int __devinit pca_isa_probe(struct device *dev, unsigned int id)
    {
    init_waitqueue_head(&pca_wait);
    @@ -153,7 +166,7 @@ static int __devexit pca_isa_remove(struct device *dev, unsigned int id)
    {
    i2c_del_adapter(&pca_isa_ops);

    - if (irq > 0) {
    + if (irq > -1) {
    disable_irq(irq);
    free_irq(irq, &pca_isa_ops);
    }
    @@ -163,6 +176,7 @@ static int __devexit pca_isa_remove(struct device *dev, unsigned int id)
    }

    static struct isa_driver pca_isa_driver = {
    + .match = pca_isa_match,
    .probe = pca_isa_probe,
    .remove = __devexit_p(pca_isa_remove),
    .driver = {
    --
    1.5.5



  9. Re: [patch 0/9] x86, xsave: xsave/xrstor support

    On Fri, Aug 01, 2008 at 04:27:53PM +0200, Rene Herman wrote:
    > On 01-08-08 11:51, Ingo Molnar wrote:
    >
    > >find attached below a newer version of the original list i published
    > >half a year ago:
    > >
    > > http://people.redhat.com/mingo/auto-...onfig-qa.patch
    > >
    > >these are just pragmatic local hacks to get things going. (There are
    > >more per machine quirks as well.)
    > >
    > >i have not used a BROKEN annotation because CONFIG_BROKEN is
    > >impractical: it just kills code altogether, indiscriminately. There's no
    > >way for users to enable CONFIG_BROKEN in the upstream kernel - nothing
    > >selects it and it's not an interactive option either.
    > >
    > >So by all means if we mark a driver or a kernel feature as
    > >CONFIG_BROKEN, it's killed altogether for all practical purposes.
    > >
    > >What we'd need is some more gradual approach: for example a way to mark
    > >"drivers that are not expected to boot on a whitebox PC", without
    > >removing them altogether via a CONFIG_BROKEN dependency - often it's
    > >hardware that cannot be probed safely.

    >
    > For real ISA at the least, the best fix I feel is just not go grabbing
    > resources without anything (ie, ISAPnP) or anyone (ie, the user) telling


    Really old systems don't have isapnp. Neither have smbus devices.

    > us that's where the hardware's at.


    That would mean the users on these systems would need to add tons
    of obscure command line options.

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

  10. Re: [patch 0/9] x86, xsave: xsave/xrstor support

    On 01-08-08 16:49, Andi Kleen wrote:

    >> For real ISA at the least, the best fix I feel is just not go grabbing
    >> resources without anything (ie, ISAPnP) or anyone (ie, the user) telling

    >
    > Really old systems don't have isapnp. Neither have smbus devices.
    >
    >> us that's where the hardware's at.

    >
    > That would mean the users on these systems would need to add tons
    > of obscure command line options.


    No, it means users on those 1% of systems that are using drivers that
    break the other 99% would have to for those one or two drivers that do.

    And as said, we don't care.

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

  11. Re: [patch 0/9] x86, xsave: xsave/xrstor support

    On Fri, Aug 01, 2008 at 05:19:17PM +0200, Rene Herman wrote:
    > On 01-08-08 16:49, Andi Kleen wrote:
    >
    > >>For real ISA at the least, the best fix I feel is just not go grabbing
    > >>resources without anything (ie, ISAPnP) or anyone (ie, the user) telling

    > >
    > >Really old systems don't have isapnp. Neither have smbus devices.
    > >
    > >>us that's where the hardware's at.

    > >
    > >That would mean the users on these systems would need to add tons
    > >of obscure command line options.

    >
    > No, it means users on those 1% of systems that are using drivers that
    > break the other 99% would have to for those one or two drivers that do.
    >
    > And as said, we don't care.


    Not sure who "we" is in this context.

    Especially dropping easy support for all smbus devices (which are often like
    this) would seem quite wrong to me. And for real ISA devices there tends to
    be a surprisingly large user base left for those.

    The config option Ingo proposed is a good idea though.

    Or they can just use 64bit which never defines CONFIG_ISA, but of course
    still has to support all the similar smbus drivers.
    -Andi

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

  12. Re: [patch 0/9] x86, xsave: xsave/xrstor support

    On 01-08-08 17:44, Andi Kleen wrote:
    > On Fri, Aug 01, 2008 at 05:19:17PM +0200, Rene Herman wrote:
    >> On 01-08-08 16:49, Andi Kleen wrote:
    >>
    >>>> For real ISA at the least, the best fix I feel is just not go grabbing
    >>>> resources without anything (ie, ISAPnP) or anyone (ie, the user) telling
    >>> Really old systems don't have isapnp. Neither have smbus devices.
    >>>
    >>>> us that's where the hardware's at.
    >>> That would mean the users on these systems would need to add tons
    >>> of obscure command line options.

    >> No, it means users on those 1% of systems that are using drivers that
    >> break the other 99% would have to for those one or two drivers that do.
    >>
    >> And as said, we don't care.

    >
    > Not sure who "we" is in this context.


    We, the old crap hardware users the drivers for which break sensible
    systems by default.

    Really, look at the patch I posted -- it's a patch to make passing in a
    base (and irq if you want one) to i2c-pca-isa needed. Right now, the
    thing just grabs those resources and breaks the boot on systems that
    don't have it as per Ingo's testing.

    On plain technical grounds mucking with resources you don't own is bad
    (on those old systems, 0x330 might even be a NE2000 which gets confused
    really quickly) and even more importantly; let's take a wild guess and
    assume that that specific ISA driver has, oh let's say, less than 3
    users in the world all of whom wouldn't care one bit about sticking in
    an options line in their modprobe.conf.

    There is no reason drivers like that should be allowed to break all the
    _other_ systems instead of making those users do that. Not a single one.

    > Especially dropping easy support for all smbus devices (which are often like
    > this) would seem quite wrong to me. And for real ISA devices there tends to
    > be a surprisingly large user base left for those.


    Fortunately, smbus devices tend to not grab IRQs and go poking around
    the general I/O space willy-nilly (they go poking around the smbus I/O
    space willy-nilly). Note again, this specific case is a _bus_ driver for
    a bus on an ISA card.

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

  13. Re: [patch 0/9] x86, xsave: xsave/xrstor support


    * Ingo Molnar wrote:

    > > Anyhow, with watchdog removed, it works just fine. (both xsave and
    > > non-xsave kernels)

    >
    > Great, thanks. I've re-integrated tip/x86/xsave into x86/master and
    > have pushed out the result.


    FYI, small tip/x86/xsave build fixlet below - user-space exposed
    interfaces need to use __u64 not u64.

    Ingo

    -------------->
    From 26d809af6397ce5c37f5c44d89734d19cce1ad25 Mon Sep 17 00:00:00 2001
    From: Ingo Molnar
    Date: Wed, 13 Aug 2008 12:46:26 +0200
    Subject: [PATCH] x86: fix xsave build error
    MIME-Version: 1.0
    Content-Type: text/plain; charset=utf-8
    Content-Transfer-Encoding: 8bit

    fix this build failure with certain glibc versions:

    In file included from /usr/include/bits/sigcontext.h:28,
    from /usr/include/signal.h:333,
    from Documentation/accounting/getdelays.c:24:
    /home/mingo/tip/usr/include/asm/sigcontext.h:191: error: expected specifier-qualifier-list before ‘u64’

    Signed-off-by: Ingo Molnar
    ---
    include/asm-x86/sigcontext.h | 6 +++---
    1 files changed, 3 insertions(+), 3 deletions(-)

    diff --git a/include/asm-x86/sigcontext.h b/include/asm-x86/sigcontext.h
    index 899fe2f..ee813f4 100644
    --- a/include/asm-x86/sigcontext.h
    +++ b/include/asm-x86/sigcontext.h
    @@ -264,9 +264,9 @@ struct sigcontext {
    #endif /* !__i386__ */

    struct _xsave_hdr {
    - u64 xstate_bv;
    - u64 reserved1[2];
    - u64 reserved2[5];
    + __u64 xstate_bv;
    + __u64 reserved1[2];
    + __u64 reserved2[5];
    };

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

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2