[PATCH] SCSI: Delete unused header file.

[Robert P. J. Day]

  Delete apparently unused header file drivers/scsi/pci2000.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

diff --git a/drivers/scsi/pci2000.h b/drivers/scsi/pci2000.h
deleted file mode 100644
index 0ebd8ce..000
--- a/drivers/scsi/pci2000.h
+++ /dev/null
@@ -1,197 +0,0 @@
-/
- * Perceptive Solutions, Inc. PCI-2000 device driver for Linux.
- *
- * pci2000.h - Linux Host Driver for PCI-2000 IntelliCache SCSI Adapters
- *
- * Copyright (c) 1997-1999 Perceptive Solutions, Inc.
- * All Rights Reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that redistributions of source
- * code retain the above copyright notice and this comment without
- * modification.
- *
- * Technical updates and product information at:
- *  http://www.psidisk.com
- *
- * Please send questions, comments, bug reports to:
- *  [EMAIL PROTECTED] Technical Support
- *
- /
-#ifndef _PCI2000_H
-#define _PCI2000_H
-
-#include 
-
-#ifndefPSI_EIDE_SCSIOP
-#definePSI_EIDE_SCSIOP 1
-
-#defineLINUXVERSION(v,p,s)(((v)<<16) + ((p)<<8) + (s))
-
-//
-/* definition of standard data types   */
-//
-#defineCHARchar
-#defineUCHAR   unsigned char
-#defineSHORT   short
-#defineUSHORT  unsigned short
-#defineBOOLlong
-#defineLONGlong
-#defineULONG   unsigned long
-#defineVOIDvoid
-
-typedefCHAR*PCHAR;
-typedefUCHAR   *PUCHAR;
-typedefSHORT   *PSHORT;
-typedefUSHORT  *PUSHORT;
-typedefBOOL*PBOOL;
-typedefLONG*PLONG;
-typedefULONG   *PULONG;
-typedefVOID*PVOID;
-
-
-//
-/* Misc. macros
*/
-//
-#define ANY2SCSI(up, p)\
-((UCHAR *)up)[0] = (((ULONG)(p)) >> 8);\
-((UCHAR *)up)[1] = ((ULONG)(p));
-
-#define SCSI2LONG(up)  \
-( (((long)*(((UCHAR *)up))) << 16) \
-+ (((long)(((UCHAR *)up)[1])) << 8)\
-+ ((long)(((UCHAR *)up)[2])) )
-
-#define XANY2SCSI(up, p)   \
-((UCHAR *)up)[0] = ((long)(p)) >> 24;  \
-((UCHAR *)up)[1] = ((long)(p)) >> 16;  \
-((UCHAR *)up)[2] = ((long)(p)) >> 8;   \
-((UCHAR *)up)[3] = ((long)(p));
-
-#define XSCSI2LONG(up) \
-( (((long)(((UCHAR *)up)[0])) << 24)   \
-+ (((long)(((UCHAR *)up)[1])) << 16)   \
-+ (((long)(((UCHAR *)up)[2])) <<  8)   \
-+ ((long)(((UCHAR *)up)[3])) )
-
-//
-/* SCSI CDB operation codes*/
-//
-#define SCSIOP_TEST_UNIT_READY 0x00
-#define SCSIOP_REZERO_UNIT 0x01
-#define SCSIOP_REWIND  0x01
-#define SCSIOP_REQUEST_BLOCK_ADDR  0x02
-#define SCSIOP_REQUEST_SENSE   0x03
-#define SCSIOP_FORMAT_UNIT 0x04
-#define SCSIOP_READ_BLOCK_LIMITS   0x05
-#define SCSIOP_REASSIGN_BLOCKS 0x07
-#define SCSIOP_READ6   0x08
-#define SCSIOP_RECEIVE 0x08
-#define SCSIOP_WRITE6  0x0A
-#define SCSIOP_PRINT   0x0A
-#define SCSIOP_SEND0x0A
-#define SCSIOP_SEEK6   0x0B
-#define SCSIOP_TRACK_SELECT0x0B
-#define SCSIOP_SLEW_PRINT  0x0B
-#define SCSIOP_SEEK_BLOCK  0x0C
-#define SCSIOP_PARTITION   0x0D
-#define SCSIOP_READ_REVERSE0x0F
-#define SCSIOP_WRITE_FILEMARKS 0x10
-#define SCSIOP_FLUSH_BUFFER0x10
-#define SCSIOP_SPACE   0x11
-#define SCSIOP_INQUIRY 0x12
-#define SCSIOP_VERIFY6 0x13
-#define SCSIOP_RECOVER_BUF_DATA0x14
-#define SCSIOP_MODE_SELECT 0x15
-#define SCSIOP_RESERVE_UNIT0x16
-#define SCSIOP_RELEASE_UNIT0x17
-#define SCSIOP_COPY0x18
-#define SCSIOP_ERASE   0x19
-#define SCSIOP_MODE_SENSE  0x1A
-#define SCSIOP_START_STOP_UNIT 0x1B
-#define SCSIOP_STOP_PRINT  0x1B
-#define SCSIOP_LOAD_UNLOAD 0x1B
-#define SCSIOP_RECEIVE_DIAGNOSTIC  0x1C
-#define SCSIOP_SEND_DIAGNOSTIC 0x1D
-#define 

Re: Suspend to disk bug 2.6.21-rc2-git1

[Pavel Machek]

Hi!

> I'm not sure what version did exacly caused susped to disk problems but
> anyway, in 2.6.21-rc2-git1, suspend to disk breaks ACPI. ACPI events do not
> even emit ACPI interrupts. Suspend to ram works nicely.

Is 2.6.21-latest better?  There were many problems in suspend area,
hopefully they are slowly being fixed...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] LANMEDIA: Delete unused header file.

[Robert P. J. Day]

  Delete apparently unused header file
drivers/net/wan/lmc/lmc_media.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  not sure who maintainer is here.


diff --git a/drivers/net/wan/lmc/lmc_media.h b/drivers/net/wan/lmc/lmc_media.h
deleted file mode 100644
index ddcc004..000
--- a/drivers/net/wan/lmc/lmc_media.h
+++ /dev/null
@@ -1,65 +0,0 @@
-#ifndef _LMC_MEDIA_H_
-#define _LMC_MEDIA_H_
-
-lmc_media_t lmc_ds3_media = {
-  lmc_ds3_init,/* special media init stuff */
-  lmc_ds3_default, /* reset to default state */
-  lmc_ds3_set_status,  /* reset status to state provided */
-  lmc_dummy_set_1, /* set clock source */
-  lmc_dummy_set2_1,/* set line speed */
-  lmc_ds3_set_100ft,   /* set cable length */
-  lmc_ds3_set_scram,   /* set scrambler */
-  lmc_ds3_get_link_status, /* get link status */
-  lmc_dummy_set_1, /* set link status */
-  lmc_ds3_set_crc_length,  /* set CRC length */
-  lmc_dummy_set_1, /* set T1 or E1 circuit type */
-  lmc_ds3_watchdog
-};
-
-lmc_media_t lmc_hssi_media = {
-  lmc_hssi_init,   /* special media init stuff */
-  lmc_hssi_default,/* reset to default state */
-  lmc_hssi_set_status, /* reset status to state provided */
-  lmc_hssi_set_clock,  /* set clock source */
-  lmc_dummy_set2_1,/* set line speed */
-  lmc_dummy_set_1, /* set cable length */
-  lmc_dummy_set_1, /* set scrambler */
-  lmc_hssi_get_link_status,/* get link status */
-  lmc_hssi_set_link_status,/* set link status */
-  lmc_hssi_set_crc_length, /* set CRC length */
-  lmc_dummy_set_1, /* set T1 or E1 circuit type */
-  lmc_hssi_watchdog
-};
-
-lmc_media_t lmc_ssi_media = { lmc_ssi_init,/* special media init stuff */
-  lmc_ssi_default, /* reset to default state */
-  lmc_ssi_set_status,  /* reset status to state provided */
-  lmc_ssi_set_clock,   /* set clock source */
-  lmc_ssi_set_speed,   /* set line speed */
-  lmc_dummy_set_1, /* set cable length */
-  lmc_dummy_set_1, /* set scrambler */
-  lmc_ssi_get_link_status, /* get link status */
-  lmc_ssi_set_link_status, /* set link status */
-  lmc_ssi_set_crc_length,  /* set CRC length */
-  lmc_dummy_set_1, /* set T1 or E1 circuit type */
-  lmc_ssi_watchdog
-};
-
-lmc_media_t lmc_t1_media = {
-  lmc_t1_init, /* special media init stuff */
-  lmc_t1_default,  /* reset to default state */
-  lmc_t1_set_status,   /* reset status to state provided */
-  lmc_t1_set_clock,/* set clock source */
-  lmc_dummy_set2_1,/* set line speed */
-  lmc_dummy_set_1, /* set cable length */
-  lmc_dummy_set_1, /* set scrambler */
-  lmc_t1_get_link_status,  /* get link status */
-  lmc_dummy_set_1, /* set link status */
-  lmc_t1_set_crc_length,   /* set CRC length */
-  lmc_t1_set_circuit_type, /* set T1 or E1 circuit type */
-  lmc_t1_watchdog
-};
-
-
-#endif
-
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_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: [ck] Re: RSDL v0.28 for 2.6.20

[Willy Tarreau]

On Sat, Mar 10, 2007 at 04:56:57PM -0500, michael chang wrote:
> On 3/10/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> >BTW, Con, I think that you should base your work on 2.6.20.[23] and not
> >2.6.20 next time, due to this conflict. It will get wider adoption.
  ^^

> Maybe I'm naive, but I find this hard to understand -- 2.6.20.2 didn't
> exist when Con published his patch. (Con published it ~12 hours before
> the release of 2.6.20.2, from what I can tell.) How can he base his
> work on something that didn't yet exist? (And it applied cleanly to
> 2.6.20.1, the latest when he published it.)

You see the words I have underlined ? "next time". I know for sure he
published it before 2.6.20.2, but now that it is out, I suggested that
Con rebases his work on this version for new releases.

Regards,
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/

[PATCH] SYSKONNECT: Delete unused header file.

[Robert P. J. Day]

  Delete apparently unused header file drivers/net/skfp/h/lnkstat.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

diff --git a/drivers/net/skfp/h/lnkstat.h b/drivers/net/skfp/h/lnkstat.h
deleted file mode 100644
index c73dcd9..000
--- a/drivers/net/skfp/h/lnkstat.h
+++ /dev/null
@@ -1,84 +0,0 @@
-/**
- *
- * (C)Copyright 1998,1999 SysKonnect,
- * a business unit of Schneider & Koch & Co. Datensysteme GmbH.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * The information in this file is provided "AS IS" without warranty.
- *
- 
**/
-
-/*
- * Definition of the Error Log Structure
- * This structure will be copied into the Error Log buffer
- * during the NDIS General Request ReadErrorLog by the MAC Driver
- */
-
-struct s_error_log {
-
-   /*
-* place holder for token ring adapter error log (zeros)
-*/
-   u_char  reserved_0 ;/* byte 0 inside Error Log */
-   u_char  reserved_1 ;/* byte 1 */
-   u_char  reserved_2 ;/* byte 2 */
-   u_char  reserved_3 ;/* byte 3 */
-   u_char  reserved_4 ;/* byte 4 */
-   u_char  reserved_5 ;/* byte 5 */
-   u_char  reserved_6 ;/* byte 6 */
-   u_char  reserved_7 ;/* byte 7 */
-   u_char  reserved_8 ;/* byte 8 */
-   u_char  reserved_9 ;/* byte 9 */
-   u_char  reserved_10 ;   /* byte 10 */
-   u_char  reserved_11 ;   /* byte 11 */
-   u_char  reserved_12 ;   /* byte 12 */
-   u_char  reserved_13 ;   /* byte 13 */
-
-   /*
-* FDDI link statistics
-*/
-/*
- * smt error low
- */
-#define SMT_ERL_AEB(1<<15) /* A elast. buffer */
-#define SMT_ERL_BLC(1<<14) /* B link error condition */
-#define SMT_ERL_ALC(1<<13) /* A link error condition */
-#define SMT_ERL_NCC(1<<12) /* not copied condition */
-#define SMT_ERL_FEC(1<<11) /* frame error condition */
-
-/*
- * smt event low
- */
-#define SMT_EVL_NCE(1<<5)
-
-   u_short smt_error_low ; /* byte 14/15 */
-   u_short smt_error_high ;/* byte 16/17 */
-   u_short smt_event_low ; /* byte 18/19 */
-   u_short smt_event_high ;/* byte 20/21 */
-   u_short connection_policy_violation ;   /* byte 22/23 */
-   u_short port_event ;/* byte 24/25 */
-   u_short set_count_low ; /* byte 26/27 */
-   u_short set_count_high ;/* byte 28/29 */
-   u_short aci_id_code ;   /* byte 30/31 */
-   u_short purge_frame_counter ;   /* byte 32/33 */
-
-   /*
-* CMT and RMT state machines
-*/
-   u_short ecm_state ; /* byte 34/35 */
-   u_short pcm_a_state ;   /* byte 36/37 */
-   u_short pcm_b_state ;   /* byte 38/39 */
-   u_short cfm_state ; /* byte 40/41 */
-   u_short rmt_state ; /* byte 42/43 */
-
-   u_short not_used[30] ;  /* byte 44-103 */
-
-   u_short ucode_version_level ;   /* byte 104/105 */
-
-   u_short not_used_1 ;/* byte 106/107 */
-   u_short not_used_2 ;/* byte 108/109 */
-} ;
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_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: [2/6] 2.6.21-rc2: known regressions

[Pavel Machek]

Hi!

> > Ok. To be honest, you are the first reporter that seems to have read 
> > the documentation above, but not understood what to do.
> 
> thanks for the compliment ;-) _I_ very much know what to do (i mailed 
> the right person after all ;), but i dont really count and on the 6 

(Can we get the whitelist entries?)

> > i might consider reworking the documentation if there are more reports 
> > about problems with the procedure.
> 
> Probably tweaking the webpage doesnt help because people dont get there 
> - as the results plainly show it. Maybe some more automation would be 
> useful too, a tool that detects failed resume and tries all those 
> options that makes sense on that box or something? It's not like
> that 

Unfortunately, these tend to crash the box when you pass wrong
options, and I do not see easy way to test "can user see whats on
display" automatically.

Feel free to send patches, but I do not think it is easy/possible.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Remove unused header file.

[Robert P. J. Day]

  Remove apparently unused header file
drivers/net/chelsio/vsc8244_reg.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  not sure who the maintainer is here.

diff --git a/drivers/net/chelsio/vsc8244_reg.h 
b/drivers/net/chelsio/vsc8244_reg.h
deleted file mode 100644
index d3c1829..000
--- a/drivers/net/chelsio/vsc8244_reg.h
+++ /dev/null
@@ -1,172 +0,0 @@
-/* $Date: 2005/11/23 16:28:53 $ $RCSfile: vsc8244_reg.h,v $ $Revision: 1.1 $ */
-#ifndef CHELSIO_MV8E1XXX_H
-#define CHELSIO_MV8E1XXX_H
-
-#ifndef BMCR_SPEED1000
-# define BMCR_SPEED1000 0x40
-#endif
-
-#ifndef ADVERTISE_PAUSE
-# define ADVERTISE_PAUSE 0x400
-#endif
-#ifndef ADVERTISE_PAUSE_ASYM
-# define ADVERTISE_PAUSE_ASYM 0x800
-#endif
-
-/* Gigabit MII registers */
-#define MII_GBMR 1   /* 1000Base-T mode register */
-#define MII_GBCR 9   /* 1000Base-T control register */
-#define MII_GBSR 10  /* 1000Base-T status register */
-
-/* 1000Base-T control register fields */
-#define GBCR_ADV_1000HALF 0x100
-#define GBCR_ADV_1000FULL 0x200
-#define GBCR_PREFER_MASTER0x400
-#define GBCR_MANUAL_AS_MASTER 0x800
-#define GBCR_MANUAL_CONFIG_ENABLE 0x1000
-
-/* 1000Base-T status register fields */
-#define GBSR_LP_1000HALF  0x400
-#define GBSR_LP_1000FULL  0x800
-#define GBSR_REMOTE_OK0x1000
-#define GBSR_LOCAL_OK 0x2000
-#define GBSR_LOCAL_MASTER 0x4000
-#define GBSR_MASTER_FAULT 0x8000
-
-/* Vitesse PHY interrupt status bits. */
-#if 0
-#define VSC8244_INTR_JABBER  0x0001
-#define VSC8244_INTR_POLARITY_CHNG   0x0002
-#define VSC8244_INTR_ENG_DETECT_CHNG 0x0010
-#define VSC8244_INTR_DOWNSHIFT   0x0020
-#define VSC8244_INTR_MDI_XOVER_CHNG  0x0040
-#define VSC8244_INTR_FIFO_OVER_UNDER 0x0080
-#define VSC8244_INTR_FALSE_CARRIER   0x0100
-#define VSC8244_INTR_SYMBOL_ERROR0x0200
-#define VSC8244_INTR_LINK_CHNG   0x0400
-#define VSC8244_INTR_AUTONEG_DONE0x0800
-#define VSC8244_INTR_PAGE_RECV   0x1000
-#define VSC8244_INTR_DUPLEX_CHNG 0x2000
-#define VSC8244_INTR_SPEED_CHNG  0x4000
-#define VSC8244_INTR_AUTONEG_ERR 0x8000
-#else
-//#define VSC8244_INTR_JABBER  0x0001
-//#define VSC8244_INTR_POLARITY_CHNG   0x0002
-//#define VSC8244_INTR_BIT20x0004
-//#define VSC8244_INTR_BIT30x0008
-#define VSC8244_INTR_RX_ERR  0x0001
-#define VSC8244_INTR_MASTER_SLAVE0x0002
-#define VSC8244_INTR_CABLE_IMPAIRED  0x0004
-#define VSC8244_INTR_FALSE_CARRIER   0x0008
-//#define VSC8244_INTR_ENG_DETECT_CHNG 0x0010
-//#define VSC8244_INTR_DOWNSHIFT   0x0020
-//#define VSC8244_INTR_MDI_XOVER_CHNG  0x0040
-//#define VSC8244_INTR_FIFO_OVER_UNDER 0x0080
-#define VSC8244_INTR_BIT40x0010
-#define VSC8244_INTR_FIFO_RX 0x0020
-#define VSC8244_INTR_FIFO_OVER_UNDER 0x0040
-#define VSC8244_INTR_LOCK_LOST   0x0080
-//#define VSC8244_INTR_FALSE_CARRIER   0x0100
-//#define VSC8244_INTR_SYMBOL_ERROR0x0200
-//#define VSC8244_INTR_LINK_CHNG   0x0400
-//#define VSC8244_INTR_AUTONEG_DONE0x0800
-#define VSC8244_INTR_SYMBOL_ERROR0x0100
-#define VSC8244_INTR_ENG_DETECT_CHNG 0x0200
-#define VSC8244_INTR_AUTONEG_DONE0x0400
-#define VSC8244_INTR_AUTONEG_ERR 0x0800
-//#define VSC8244_INTR_PAGE_RECV   0x1000
-//#define VSC8244_INTR_DUPLEX_CHNG 0x2000
-//#define VSC8244_INTR_SPEED_CHNG  0x4000
-//#define VSC8244_INTR_AUTONEG_ERR 0x8000
-#define VSC8244_INTR_DUPLEX_CHNG 0x1000
-#define VSC8244_INTR_LINK_CHNG   0x2000
-#define VSC8244_INTR_SPEED_CHNG  0x4000
-#define VSC8244_INTR_STATUS  0x8000
-#endif
-
-
-/* Vitesse PHY specific registers. */
-#define VSC8244_SPECIFIC_CNTRL_REGISTER   16
-#define VSC8244_SPECIFIC_STATUS_REGISTER  0x1c
-#define VSC8244_INTERRUPT_ENABLE_REGISTER 0x19
-#define VSC8244_INTERRUPT_STATUS_REGISTER 0x1a
-#define VSC8244_EXT_PHY_SPECIFIC_CNTRL_REGISTER   20
-#define VSC8244_RECV_ERR_CNTR_REGISTER21
-#define VSC8244_RES_REGISTER  22
-#define VSC8244_GLOBAL_STATUS_REGISTER23
-#define VSC8244_LED_CONTROL_REGISTER  24
-#define VSC8244_MANUAL_LED_OVERRIDE_REGISTER  25
-#define VSC8244_EXT_PHY_SPECIFIC_CNTRL_2_REGISTER 26
-#define VSC8244_EXT_PHY_SPECIFIC_STATUS_REGISTER  27
-#define VSC8244_VIRTUAL_CABLE_TESTER_REGISTER 28
-#define VSC8244_EXTENDED_ADDR_REGISTER29
-#define VSC8244_EXTENDED_REGISTER 30
-
-/* PHY specific control register fields */
-#define S_PSCR_MDI_XOVER_MODE5
-#define M_PSCR_MDI_XOVER_MODE0x3
-#define V_PSCR_MDI_XOVER_MODE(x) ((x) << S_PSCR_MDI_XOVER_MODE)
-#define G_PSCR_MDI_XOVER_MODE(x) (((x) >> S_PSCR_MDI_XOVER_MODE) & 
M_PSCR_MDI_XOVER_MODE)
-
-/* Extended PHY specific control register fields */
-#define S_DOWNSHIFT_ENABLE 8
-#define V_DOWNSHIFT_ENABLE (1 << S_DOWNSHIFT_ENABLE)
-
-#define S_DOWNSHIFT_CNT9
-#define M_DOWNSHIFT_CNT0x7
-#define 

s2ram (was Re: [2/6] 2.6.21-rc2: known regressions)

[Pavel Machek]

Hi!

> > > Even if one doesn't use the fb console at all, radeonfb apparently 
> > > is still required on some ThinkPad models to work around BIOS bugs:
> > > 
> > > http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
> > 
> > 
> > s2ram should be able to work around this, it has parts from 
> > radeontool. (suspend.sf.net).
> 
> i'm wondering, do you have any idea how Windows handles the 
> suspend/resume quirks problem area? Do they "curse BIOS vendors and 

Windows actually have (kernel) graphics drivers that know how to
resume the video. If you boot save mode, they go w/o graphics drivers,
and have similar problems to us.

> btw., the s2ram database seems quite a bit spotty:
> 
>  $ ./s2ram -n
>  Machine is unknown.
>  This machine can be identified by:
>  sys_vendor   = "System manufacturer"
>  sys_product  = "System Product Name"
>  sys_version  = "System Version"
>  bios_version = "ASUS A8N-E ACPI BIOS Revision 1008"
> 
>  $ ./s2ram -n
>  Machine is unknown.
>  This machine can be identified by:
> sys_vendor   = "Hewlett-Packard "
> sys_product  = "compaq nx9030 (PG630ET#ABD)   "
> sys_version  = "Rev 1   "
> bios_version = "F.15"
>  See http://en.opensuse.org/S2ram for details.

Desktops are the problem; but that nx9030 should be reasonably easy to
add.

> even at the link above i didnt find any clear algorithm about how to 
> extend the quirks-list and the white-list - while i expect that most 
> people experience what i did: that s2ram doesnt know their boxes. 
> (otherwise they would not visit that URL at all i suspect)

Did you get options for s2ram that work on your systems? Mail them to
[EMAIL PROTECTED], and he'll extend the whitelist ;-). In the meantime,
just use -f 
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] I2O: Delete unused header file.

[Robert P. J. Day]

  Delete apparently unused header file.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

diff --git a/drivers/message/i2o/i2o_lan.h b/drivers/message/i2o/i2o_lan.h
deleted file mode 100644
index 6502b81..000
--- a/drivers/message/i2o/i2o_lan.h
+++ /dev/null
@@ -1,159 +0,0 @@
-/*
- * i2o_lan.h   I2O LAN Class definitions
- *
- *  I2O LAN CLASS OSM  May 26th 2000
- *
- *  (C) Copyright 1999, 2000   University of Helsinki,
- * Department of Computer Science
- *
- *  This code is still under development / test.
- *
- * Author: Auvo Häkkinen <[EMAIL PROTECTED]>
- * Juha Sievänen <[EMAIL PROTECTED]>
- * Taneli Vähäkangas <[EMAIL PROTECTED]>
- */
-
-#ifndef _I2O_LAN_H
-#define _I2O_LAN_H
-
-/* Default values for tunable parameters first */
-
-#define I2O_LAN_MAX_BUCKETS_OUT 96
-#define I2O_LAN_BUCKET_THRESH  18  /* 9 buckets in one message */
-#define I2O_LAN_RX_COPYBREAK   200
-#define I2O_LAN_TX_TIMEOUT (1*HZ)
-#define I2O_LAN_TX_BATCH_MODE  2   /* 2=automatic, 1=on, 0=off */
-#define I2O_LAN_EVENT_MASK 0   /* 0=None, 0xFFC2=All */
-
-/* LAN types */
-#define I2O_LAN_ETHERNET   0x0030
-#define I2O_LAN_100VG  0x0040
-#define I2O_LAN_TR 0x0050
-#define I2O_LAN_FDDI   0x0060
-#define I2O_LAN_FIBRE_CHANNEL  0x0070
-#define I2O_LAN_UNKNOWN0x
-
-/* Connector types */
-
-/* Ethernet */
-#define I2O_LAN_AUI(I2O_LAN_ETHERNET << 4) + 0x0001
-#define I2O_LAN_10BASE5(I2O_LAN_ETHERNET << 4) + 0x0002
-#define I2O_LAN_FIORL  (I2O_LAN_ETHERNET << 4) + 0x0003
-#define I2O_LAN_10BASE2(I2O_LAN_ETHERNET << 4) + 0x0004
-#define I2O_LAN_10BROAD36  (I2O_LAN_ETHERNET << 4) + 0x0005
-#define I2O_LAN_10BASE_T   (I2O_LAN_ETHERNET << 4) + 0x0006
-#define I2O_LAN_10BASE_FP  (I2O_LAN_ETHERNET << 4) + 0x0007
-#define I2O_LAN_10BASE_FB  (I2O_LAN_ETHERNET << 4) + 0x0008
-#define I2O_LAN_10BASE_FL  (I2O_LAN_ETHERNET << 4) + 0x0009
-#define I2O_LAN_100BASE_TX (I2O_LAN_ETHERNET << 4) + 0x000A
-#define I2O_LAN_100BASE_FX (I2O_LAN_ETHERNET << 4) + 0x000B
-#define I2O_LAN_100BASE_T4 (I2O_LAN_ETHERNET << 4) + 0x000C
-#define I2O_LAN_1000BASE_SX(I2O_LAN_ETHERNET << 4) + 0x000D
-#define I2O_LAN_1000BASE_LX(I2O_LAN_ETHERNET << 4) + 0x000E
-#define I2O_LAN_1000BASE_CX(I2O_LAN_ETHERNET << 4) + 0x000F
-#define I2O_LAN_1000BASE_T (I2O_LAN_ETHERNET << 4) + 0x0010
-
-/* AnyLAN */
-#define I2O_LAN_100VG_ETHERNET (I2O_LAN_100VG << 4) + 0x0001
-#define I2O_LAN_100VG_TR   (I2O_LAN_100VG << 4) + 0x0002
-
-/* Token Ring */
-#define I2O_LAN_4MBIT  (I2O_LAN_TR << 4) + 0x0001
-#define I2O_LAN_16MBIT (I2O_LAN_TR << 4) + 0x0002
-
-/* FDDI */
-#define I2O_LAN_125MBAUD   (I2O_LAN_FDDI << 4) + 0x0001
-
-/* Fibre Channel */
-#define I2O_LAN_POINT_POINT(I2O_LAN_FIBRE_CHANNEL << 4) + 0x0001
-#define I2O_LAN_ARB_LOOP   (I2O_LAN_FIBRE_CHANNEL << 4) + 0x0002
-#define I2O_LAN_PUBLIC_LOOP(I2O_LAN_FIBRE_CHANNEL << 4) + 0x0003
-#define I2O_LAN_FABRIC (I2O_LAN_FIBRE_CHANNEL << 4) + 0x0004
-
-#define I2O_LAN_EMULATION  0x0F00
-#define I2O_LAN_OTHER  0x0F01
-#define I2O_LAN_DEFAULT0x
-
-/* LAN class functions */
-
-#define LAN_PACKET_SEND0x3B
-#define LAN_SDU_SEND   0x3D
-#define LAN_RECEIVE_POST   0x3E
-#define LAN_RESET  0x35
-#define LAN_SUSPEND0x37
-
-/* LAN DetailedStatusCode defines */
-#define I2O_LAN_DSC_SUCCESS0x00
-#define I2O_LAN_DSC_DEVICE_FAILURE 0x01
-#define I2O_LAN_DSC_DESTINATION_NOT_FOUND  0x02
-#defineI2O_LAN_DSC_TRANSMIT_ERROR  0x03
-#define I2O_LAN_DSC_TRANSMIT_ABORTED   0x04
-#define I2O_LAN_DSC_RECEIVE_ERROR  0x05
-#define I2O_LAN_DSC_RECEIVE_ABORTED0x06
-#define I2O_LAN_DSC_DMA_ERROR  0x07
-#define I2O_LAN_DSC_BAD_PACKET_DETECTED0x08
-#define I2O_LAN_DSC_OUT_OF_MEMORY  0x09
-#define I2O_LAN_DSC_BUCKET_OVERRUN 0x0A
-#define I2O_LAN_DSC_IOP_INTERNAL_ERROR 0x0B
-#define I2O_LAN_DSC_CANCELED   0x0C
-#define I2O_LAN_DSC_INVALID_TRANSACTION_CONTEXT0x0D
-#define I2O_LAN_DSC_DEST_ADDRESS_DETECTED  0x0E
-#define I2O_LAN_DSC_DEST_ADDRESS_OMITTED   0x0F
-#define I2O_LAN_DSC_PARTIAL_PACKET_RETURNED0x10
-#define I2O_LAN_DSC_SUSPENDED  0x11
-
-struct i2o_packet_info {
-   u32 offset:24;
-   u32 flags:8;
-   u32 len:24;
-   u32 status:8;
-};
-
-struct i2o_bucket_descriptor {
-   u32 context;/* FIXME: 64bit support */
-   struct i2o_packet_info packet_info[1];
-};
-
-/* Event 

[PATCH] MPT FUSION: Delete unused header files.

[Robert P. J. Day]

  Delete apparently unused header files.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

 drivers/message/fusion/lsi/mpi_inb.h|  221 --
 drivers/message/fusion/lsi/mpi_log_fc.h |   89 
 2 files changed, 310 deletions(-)

diff --git a/drivers/message/fusion/lsi/mpi_inb.h 
b/drivers/message/fusion/lsi/mpi_inb.h
deleted file mode 100644
index ff16730..000
--- a/drivers/message/fusion/lsi/mpi_inb.h
+++ /dev/null
@@ -1,221 +0,0 @@
-/*
- *  Copyright (c) 2003-2004 LSI Logic Corporation.
- *
- *
- *   Name:  mpi_inb.h
- *  Title:  MPI Inband structures and definitions
- *  Creation Date:  September 30, 2003
- *
- *mpi_inb.h Version:  01.05.01
- *
- *  Version History
- *  ---
- *
- *  Date  Version   Description
- *      --
- *  05-11-04  01.03.01  Original release.
- *  08-19-04  01.05.01  Original release for MPI v1.5.
- *  --
- */
-
-#ifndef MPI_INB_H
-#define MPI_INB_H
-
-/**
-*
-*I n b a n dM e s s a g e s
-*
-***/
-
-
-//
-/* Inband Buffer Post Request   */
-//
-
-typedef struct _MSG_INBAND_BUFFER_POST_REQUEST
-{
-U8  Reserved1;  /* 00h */
-U8  BufferCount;/* 01h */
-U8  ChainOffset;/* 02h */
-U8  Function;   /* 03h */
-U16 Reserved2;  /* 04h */
-U8  Reserved3;  /* 06h */
-U8  MsgFlags;   /* 07h */
-U32 MsgContext; /* 08h */
-U32 Reserved4;  /* 0Ch */
-SGE_TRANS_SIMPLE_UNION  SGL;/* 10h */
-} MSG_INBAND_BUFFER_POST_REQUEST, MPI_POINTER 
PTR_MSG_INBAND_BUFFER_POST_REQUEST,
-  MpiInbandBufferPostRequest_t , MPI_POINTER pMpiInbandBufferPostRequest_t;
-
-
-typedef struct _WWN_FC_FORMAT
-{
-U64 NodeName;   /* 00h */
-U64 PortName;   /* 08h */
-} WWN_FC_FORMAT, MPI_POINTER PTR_WWN_FC_FORMAT,
-  WwnFcFormat_t, MPI_POINTER pWwnFcFormat_t;
-
-typedef struct _WWN_SAS_FORMAT
-{
-U64 WorldWideID;/* 00h */
-U32 Reserved1;  /* 08h */
-U32 Reserved2;  /* 0Ch */
-} WWN_SAS_FORMAT, MPI_POINTER PTR_WWN_SAS_FORMAT,
-  WwnSasFormat_t, MPI_POINTER pWwnSasFormat_t;
-
-typedef union _WWN_INBAND_FORMAT
-{
-WWN_FC_FORMAT   Fc;
-WWN_SAS_FORMAT  Sas;
-} WWN_INBAND_FORMAT, MPI_POINTER PTR_WWN_INBAND_FORMAT,
-  WwnInbandFormat, MPI_POINTER pWwnInbandFormat;
-
-
-/* Inband Buffer Post reply message */
-
-typedef struct _MSG_INBAND_BUFFER_POST_REPLY
-{
-U16 Reserved1;  /* 00h */
-U8  MsgLength;  /* 02h */
-U8  Function;   /* 03h */
-U16 Reserved2;  /* 04h */
-U8  Reserved3;  /* 06h */
-U8  MsgFlags;   /* 07h */
-U32 MsgContext; /* 08h */
-U16 Reserved4;  /* 0Ch */
-U16 IOCStatus;  /* 0Eh */
-U32 IOCLogInfo; /* 10h */
-U32 TransferLength; /* 14h */
-U32 TransactionContext; /* 18h */
-WWN_INBAND_FORMAT   Wwn;/* 1Ch */
-U32 IOCIdentifier[4];   /* 2Ch */
-} MSG_INBAND_BUFFER_POST_REPLY, MPI_POINTER PTR_MSG_INBAND_BUFFER_POST_REPLY,
-  MpiInbandBufferPostReply_t, MPI_POINTER pMpiInbandBufferPostReply_t;
-
-
-//
-/* Inband Send Request  */
-//
-
-typedef struct _MSG_INBAND_SEND_REQUEST
-{
-U16 Reserved1;  /* 00h */
-U8  ChainOffset;/* 02h */
-U8  Function;   /* 03h */
-U16 Reserved2;  /* 04h */
-U8  Reserved3;  /* 06h */
-U8  MsgFlags;   /* 07h */
-U32 MsgContext; /* 08h */
-U32 Reserved4;  /* 0Ch */
-WWN_INBAND_FORMAT   

Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

[Nicholas Miell]

On Sat, 2007-03-10 at 13:44 -0800, Linus Torvalds wrote:
> 
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> > 
> > That's what the sigevent structure is for -- to describe how events
> > should be signaled to userspace, whether by signal delivery, thread
> > creation, or queuing to event completion ports. If if you think
> > extending it would be bad, I can show you the line in POSIX where it
> > encourages the contrary.
> 
> I'm sorry, but by pointing to the POSIX timer stuff, you're just making 
> your argument weaker.
> 
> POSIX timers are a horrible crock and over-designed to be a union of 
> everything that has ever been done. Nasty. We had tons of bugs in the 
> original setup because they were so damn nasty.
> 

Care to elaborate on why they're a horrible crock?

And are the bugs fixed? If so, why replace them? They work now.

> I'd rather look at just about *anything* else for good design than from 
> some of the abortions that are posix-timers.
> 
>   Linus

-- 
Nicholas Miell <[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: [ck] Re: RSDL v0.28 for 2.6.20

[michael chang]

On 3/10/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:

BTW, Con, I think that you should base your work on 2.6.20.[23] and not
2.6.20 next time, due to this conflict. It will get wider adoption.


Maybe I'm naive, but I find this hard to understand -- 2.6.20.2 didn't
exist when Con published his patch. (Con published it ~12 hours before
the release of 2.6.20.2, from what I can tell.) How can he base his
work on something that didn't yet exist? (And it applied cleanly to
2.6.20.1, the latest when he published it.)

That said, being able to easily apply it to the latest stable kernel
would probably increase adoption, yes. I will agree with that much.

--
~Mike
- Just the crazy copy cat.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 00/20] 2.6.20-stable review

[Greg KH]

On Sat, Mar 10, 2007 at 04:43:57PM -0500, Chuck Ebbert wrote:
> Greg KH wrote:
> > On Fri, Mar 09, 2007 at 10:16:03PM -0800, Greg KH wrote:
> >> This is the start of the stable review cycle for the 2.6.20.3 release.
> > 
> > Oh, the rolled up patch is at:
> > kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.20.3-rc1.gz
> 
> You mean:
> 
> kernel.org/pub/linux/kernel/v2.6/incr/patch-2.6.20.3-rc1.gz
> 
> ?

Oops, I put it in the wrong directory, sorry about that.  I've now moved
it to the testing/ subdir.

thanks,

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

Re: [patch 00/20] 2.6.20-stable review

[Chuck Ebbert]

Greg KH wrote:
> On Fri, Mar 09, 2007 at 10:16:03PM -0800, Greg KH wrote:
>> This is the start of the stable review cycle for the 2.6.20.3 release.
> 
> Oh, the rolled up patch is at:
>   kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.20.3-rc1.gz

You mean:

kernel.org/pub/linux/kernel/v2.6/incr/patch-2.6.20.3-rc1.gz

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

Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

[Linus Torvalds]

On Sat, 10 Mar 2007, Nicholas Miell wrote:
> 
> That's what the sigevent structure is for -- to describe how events
> should be signaled to userspace, whether by signal delivery, thread
> creation, or queuing to event completion ports. If if you think
> extending it would be bad, I can show you the line in POSIX where it
> encourages the contrary.

I'm sorry, but by pointing to the POSIX timer stuff, you're just making 
your argument weaker.

POSIX timers are a horrible crock and over-designed to be a union of 
everything that has ever been done. Nasty. We had tons of bugs in the 
original setup because they were so damn nasty.

I'd rather look at just about *anything* else for good design than from 
some of the abortions that are posix-timers.

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

[PATCH] DRM: Delete unused header file.

[Robert P. J. Day]

  Delete apparently unused header file drivers/char/drm/via_mm.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

diff --git a/drivers/char/drm/via_mm.h b/drivers/char/drm/via_mm.h
deleted file mode 100644
index d57efda..000
--- a/drivers/char/drm/via_mm.h
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * Copyright 1998-2003 VIA Technologies, Inc. All Rights Reserved.
- * Copyright 2001-2003 S3 Graphics, Inc. All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sub license,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * VIA, S3 GRAPHICS, AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- */
-#ifndef _via_drm_mm_h_
-#define _via_drm_mm_h_
-
-typedef struct {
-   unsigned int context;
-   unsigned int size;
-   unsigned long offset;
-   unsigned long free;
-} drm_via_mm_t;
-
-typedef struct {
-   unsigned int size;
-   unsigned long handle;
-   void *virtual;
-} drm_via_dma_t;
-
-#endif
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_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: PROBLEM: "Make nenuconfig" does not save parameters.

[Jan Engelhardt]

On Mar 10 2007 22:27, Sam Ravnborg wrote:
>On Sat, Mar 10, 2007 at 07:23:41PM +0100, Jan Engelhardt wrote:
>> 
>> Whether the 'working config file path' should change when you do
>> 'Save as Alternate' or not, is a menuconfig axiom. Ask Sam Ravnborg
>> if you want it changed :-)
>
>Current behaviour is not logical but on the other hand I do not
>see a big need to make it so.
>It seems that people very seldom uses "save alternate" anyway.
>
>But patches are welcome.

^_^ The patch has already been posted, has not it?


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

[PATCH] Delete unused header file.

[Robert P. J. Day]

  Delete apparently unused header file drivers/char/digi.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  not sure who the proper maintainer is on this one.


diff --git a/drivers/char/digi.h b/drivers/char/digi.h
deleted file mode 100644
index 19df0e8..000
--- a/drivers/char/digi.h
+++ /dev/null
@@ -1,71 +0,0 @@
-/*  Definitions for DigiBoard ditty(1) command. */
-
-#if !defined(TIOCMODG)
-#defineTIOCMODG(('d'<<8) | 250)/* get modem 
ctrl state */
-#defineTIOCMODS(('d'<<8) | 251)/* set modem 
ctrl state */
-#endif
-
-#if !defined(TIOCMSET)
-#defineTIOCMSET(('d'<<8) | 252)/* set modem 
ctrl state */
-#defineTIOCMGET(('d'<<8) | 253)/* set modem 
ctrl state */
-#endif
-
-#if !defined(TIOCMBIC)
-#defineTIOCMBIC(('d'<<8) | 254)/* set modem 
ctrl state */
-#defineTIOCMBIS(('d'<<8) | 255)/* set modem 
ctrl state */
-#endif
-
-#if !defined(TIOCSDTR)
-#defineTIOCSDTR(('e'<<8) | 0)  /* set DTR  
*/
-#defineTIOCCDTR(('e'<<8) | 1)  /* clear DTR
*/
-#endif
-
-/
- * Ioctl command arguments for DIGI parameters.
- /
-#define DIGI_GETA  (('e'<<8) | 94) /* Read params  */
-
-#define DIGI_SETA  (('e'<<8) | 95) /* Set params   */
-#define DIGI_SETAW (('e'<<8) | 96) /* Drain & set params   */
-#define DIGI_SETAF (('e'<<8) | 97) /* Drain, flush & set params */
-
-#defineDIGI_GETFLOW(('e'<<8) | 99) /* Get startc/stopc 
flow */
-   /* control characters*/
-#defineDIGI_SETFLOW(('e'<<8) | 100)/* Set 
startc/stopc flow */
-   /* control characters*/
-#defineDIGI_GETAFLOW   (('e'<<8) | 101)/* Get Aux. 
startc/stopc */
-   /* flow control chars*/
-#defineDIGI_SETAFLOW   (('e'<<8) | 102)/* Set Aux. 
startc/stopc */
-   /* flow control chars*/
-
-struct digiflow_struct {
-   unsigned char   startc; /* flow cntl start char 
*/
-   unsigned char   stopc;  /* flow cntl stop char  
*/
-};
-
-typedef struct digiflow_struct digiflow_t;
-
-
-/
- * Values for digi_flags
- /
-#define DIGI_IXON  0x0001  /* Handle IXON in the FEP   */
-#define DIGI_FAST  0x0002  /* Fast baud rates  */
-#define RTSPACE0x0004  /* RTS input flow control   
*/
-#define CTSPACE0x0008  /* CTS output flow control  
*/
-#define DSRPACE0x0010  /* DSR output flow control  
*/
-#define DCDPACE0x0020  /* DCD output flow control  
*/
-#define DTRPACE0x0040  /* DTR input flow control   
*/
-#define DIGI_FORCEDCD  0x0100  /* Force carrier*/
-#defineDIGI_ALTPIN 0x0200  /* Alternate RJ-45 pin config   
*/
-#defineDIGI_AIXON  0x0400  /* Aux flow control in fep  
*/
-
-
-/
- * Structure used with ioctl commands for DIGI parameters.
- /
-struct digi_struct {
-   unsigned short  digi_flags; /* Flags (see above)*/
-};
-
-typedef struct digi_struct digi_t;

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_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/

[PATCH] USER-MODE LINUX: Delete unused header file.

[Robert P. J. Day]

  Delete the apparently unused header file
arch/um/kernel/tt/include/mode_kern-tt.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  this one i'm not so sure about as there is a header file named
"mode_kern_tt.h", and those names are uncomfortably similar.



diff --git a/arch/um/kernel/tt/include/mode_kern-tt.h 
b/arch/um/kernel/tt/include/mode_kern-tt.h
deleted file mode 100644
index 2a35b15..000
--- a/arch/um/kernel/tt/include/mode_kern-tt.h
+++ /dev/null
@@ -1,52 +0,0 @@
-/*
- * Copyright (C) 2002 Jeff Dike ([EMAIL PROTECTED])
- * Licensed under the GPL
- */
-
-#ifndef __TT_MODE_KERN_H__
-#define __TT_MODE_KERN_H__
-
-#include "linux/sched.h"
-#include "asm/page.h"
-#include "asm/ptrace.h"
-#include "asm/uaccess.h"
-
-extern void switch_to_tt(void *prev, void *next);
-extern void flush_thread_tt(void);
-extern void start_thread_tt(struct pt_regs *regs, unsigned long eip,
-  unsigned long esp);
-extern int copy_thread_tt(int nr, unsigned long clone_flags, unsigned long sp,
- unsigned long stack_top, struct task_struct *p,
- struct pt_regs *regs);
-extern void release_thread_tt(struct task_struct *task);
-extern void initial_thread_cb_tt(void (*proc)(void *), void *arg);
-extern void init_idle_tt(void);
-extern void flush_tlb_kernel_range_tt(unsigned long start, unsigned long end);
-extern void flush_tlb_kernel_vm_tt(void);
-extern void __flush_tlb_one_tt(unsigned long addr);
-extern void flush_tlb_range_tt(struct vm_area_struct *vma,
-  unsigned long start, unsigned long end);
-extern void flush_tlb_mm_tt(struct mm_struct *mm);
-extern void force_flush_all_tt(void);
-extern long execute_syscall_tt(void *r);
-extern void before_mem_tt(unsigned long brk_start);
-extern unsigned long set_task_sizes_tt(int arg, unsigned long *host_size_out,
-  unsigned long *task_size_out);
-extern int start_uml_tt(void);
-extern int external_pid_tt(struct task_struct *task);
-extern int thread_pid_tt(struct task_struct *task);
-
-#define kmem_end_tt (host_task_size - ABOVE_KMEM)
-
-#endif
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---
- * Local variables:
- * c-file-style: "linux"
- * End:
- */

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_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: PROBLEM: "Make nenuconfig" does not save parameters.

[Sam Ravnborg]

On Sat, Mar 10, 2007 at 07:23:41PM +0100, Jan Engelhardt wrote:
> 
> Whether the 'working config file path' should change when you do
> 'Save as Alternate' or not, is a menuconfig axiom. Ask Sam Ravnborg
> if you want it changed :-)

Current behaviour is not logical but on the other hand I do not
see a big need to make it so.
It seems that people very seldom uses "save alternate" anyway.

But patches are welcome.

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

[PATCH] PPC: Delete unused header file.

[Robert P. J. Day]

  Delete apparently unused header file arch/ppc/syslib/cpc710.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

diff --git a/arch/ppc/syslib/cpc710.h b/arch/ppc/syslib/cpc710.h
deleted file mode 100644
index 5299bf8..000
--- a/arch/ppc/syslib/cpc710.h
+++ /dev/null
@@ -1,81 +0,0 @@
-/*
- * Definitions for the IBM CPC710 PCI Host Bridge
- *
- * Author: Matt Porter <[EMAIL PROTECTED]>
- *
- * 2001 (c) MontaVista, Software, Inc.  This file is licensed under
- * the terms of the GNU General Public License version 2.  This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- */
-
-#ifndef __PPC_PLATFORMS_CPC710_H
-#define __PPC_PLATFORMS_CPC710_H
-
-/* General bridge and memory controller registers */
-#define PIDR   0xff08
-#defineCNFR0xff0c
-#defineRSTR0xff10
-#define UCTL   0xff001000
-#defineMPSR0xff001010
-#defineSIOC0xff001020
-#defineABCNTL  0xff001030
-#define SRST   0xff001040
-#defineERRC0xff001050
-#defineSESR0xff001060
-#defineSEAR0xff001070
-#defineSIOC1   0xff001090
-#definePGCHP   0xff001100
-#defineGPDIR   0xff001130
-#defineGPOUT   0xff001150
-#defineATAS0xff001160
-#defineAVDG0xff001170
-#defineMCCR0xff001200
-#defineMESR0xff001220
-#defineMEAR0xff001230
-#defineMCER0   0xff001300
-#defineMCER1   0xff001310
-#defineMCER2   0xff001320
-#defineMCER3   0xff001330
-#defineMCER4   0xff001340
-#defineMCER5   0xff001350
-#defineMCER6   0xff001360
-#defineMCER7   0xff001370
-
-/*
- * PCI32/64 configuration registers
- * Given as offsets from their
- * respective physical segment BAR
- */
-#define PIBAR  0x000f7800
-#define PMBAR  0x000f7810
-#define MSIZE  0x000f7f40
-#define IOSIZE 0x000f7f60
-#define SMBAR  0x000f7f80
-#define SIBAR  0x000f7fc0
-#define PSSIZE 0x000f8100
-#define PPSIZE 0x000f8110
-#define BARPS  0x000f8120
-#define BARPP  0x000f8130
-#define PSBAR  0x000f8140
-#define PPBAR  0x000f8150
-#define BPMDLK 0x000f8200  /* Bottom of Peripheral Memory Space */
-#define TPMDLK 0x000f8210  /* Top of Peripheral Memory Space */
-#define BIODLK 0x000f8220  /* Bottom of Peripheral I/O Space */
-#define TIODLK 0x000f8230  /* Top of Perioheral I/O Space */
-#define DLKCTRL0x000f8240  /* Deadlock control */
-#define DLKDEV 0x000f8250  /* Deadlock device */
-
-/* System standard configuration registers space */
-#defineDCR 0xff20
-#defineDID 0xff24
-#defineBAR 0xff200018
-
-/* Device specific configuration space */
-#definePCIENB  0xff201000
-
-/* Configuration space registers */
-#define CPC710_BUS_NUMBER  0x40
-#define CPC710_SUB_BUS_NUMBER  0x41
-
-#endif /* __PPC_PLATFORMS_CPC710_H */

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_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/

[PATCH] PPC: Delete unused header file.

[Robert P. J. Day]

  Delete apparently unused header file
arch/powerpc/platforms/83xx/mpc834x_itx.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.h 
b/arch/powerpc/platforms/83xx/mpc834x_itx.h
deleted file mode 100644
index 174ca4e..000
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * arch/powerpc/platforms/83xx/mpc834x_itx.h
- *
- * MPC834X ITX common board definitions
- *
- * Maintainer: Kumar Gala <[EMAIL PROTECTED]>
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- *
- */
-
-#ifndef __MACH_MPC83XX_ITX_H__
-#define __MACH_MPC83XX_ITX_H__
-
-#define PIRQA  MPC83xx_IRQ_EXT4
-#define PIRQB  MPC83xx_IRQ_EXT5
-#define PIRQC  MPC83xx_IRQ_EXT6
-#define PIRQD  MPC83xx_IRQ_EXT7
-
-#endif /* __MACH_MPC83XX_ITX_H__ */

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_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/

[PATCH] M68K: Delete unused header file.

[Robert P. J. Day]

  Delete the apparently unused header file arch/m68k/atari/atasound.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

diff --git a/arch/m68k/atari/atasound.h b/arch/m68k/atari/atasound.h
deleted file mode 100644
index 1362762..000
--- a/arch/m68k/atari/atasound.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * Minor numbers for the sound driver.
- *
- * Unfortunately Creative called the codec chip of SB as a DSP. For this
- * reason the /dev/dsp is reserved for digitized audio use. There is a
- * device for true DSP processors but it will be called something else.
- * In v3.0 it's /dev/sndproc but this could be a temporary solution.
- */
-
-#define SND_NDEVS  256 /* Number of supported devices */
-#define SND_DEV_CTL0   /* Control port /dev/mixer */
-#define SND_DEV_SEQ1   /* Sequencer output /dev/sequencer (FM
-  synthesizer and MIDI output) */
-#define SND_DEV_MIDIN  2   /* Raw midi access */
-#define SND_DEV_DSP3   /* Digitized voice /dev/dsp */
-#define SND_DEV_AUDIO  4   /* Sparc compatible /dev/audio */
-#define SND_DEV_DSP16  5   /* Like /dev/dsp but 16 bits/sample */
-#define SND_DEV_STATUS 6   /* /dev/sndstat */
-/* #7 not in use now. Was in 2.4. Free for use after v3.0. */
-#define SND_DEV_SEQ2   8   /* /dev/sequencer, level 2 interface */
-#define SND_DEV_SNDPROC 9  /* /dev/sndproc for programmable devices */
-#define SND_DEV_PSSSND_DEV_SNDPROC
-
-#define DSP_DEFAULT_SPEED  8000
-
-#define ON 1
-#define OFF0
-
-#define MAX_AUDIO_DEV  5
-#define MAX_MIXER_DEV  2
-#define MAX_SYNTH_DEV  3
-#define MAX_MIDI_DEV   6
-#define MAX_TIMER_DEV  3

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_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/

[PATCH] ARM: Remove unused header file.

[Robert P. J. Day]

  Delete the apparently unused header file
arch/arm/mach-s3c2410/bast.h.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

diff --git a/arch/arm/mach-s3c2410/bast.h b/arch/arm/mach-s3c2410/bast.h
deleted file mode 100644
index e985437..000
--- a/arch/arm/mach-s3c2410/bast.h
+++ /dev/null
@@ -1,2 +0,0 @@
-/* linux/arch/arm/mach-s3c2410/bast.h
-extern void bast_init_irq(void);
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_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: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

[Nicholas Miell]

On Sat, 2007-03-10 at 12:41 -0800, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> 
> > Try reading the timer_create man page.
> > 
> > In short, you're limited to a single clock, so you can't set timers
> > based on wall-clock time (subject to NTP correction), monotomic time
> > (not subject to NTP, will not ever go backwards or skip ticks), the
> > high-res versions of the previous two clocks, per-thread or per-process
> > CPU usage time, or any other clocks that may get introduced in the
> > future.
> 
> One timer per fd yes. So?

I never complained about one timer per fd (although, now that you
mention it, that would get a bit excessive if you have thousands of
outstanding timers).

> The real-time and monotonic selection can be added. 

IOW, the timerfd patch is not suitable for inclusion as-is. (While
you're at it, you should probably add a flags argument for future
expansion.)

> If you look at the posix timers code, that's a bunch of code over the real 
> meat of it, that is hrtimer.c. The timerfd interface goes straight to 
> that, without adding yet another meaning to the sigevent structure,

That's what the sigevent structure is for -- to describe how events
should be signaled to userspace, whether by signal delivery, thread
creation, or queuing to event completion ports. If if you think
extending it would be bad, I can show you the line in POSIX where it
encourages the contrary.

>  and 
> yet another case inside the posix timers trigger functions. That will be 
> as unstandard as timerfd is, and even more, since you cannot use that 
> interface and hope to be portable in any case.

If Linux were to do a wholesale theft of the Solaris interface (warts
and all), you'd be portable (and, now that I think of it, more
efficient).

Two major unixes using the same interface would probably make it a
shoe-in for the next POSIX, too. (c.f. openat(2) and friends)

> On top of that, handing over files to the posix timers will creates 
> problems with references kept around.
> The timerfd code is just a *really* thin layer (if you exclude the 
> includes, the structure definitions and the fd setup code, there's 
> basically *nothing*) over hrtimer.c and does not mess up with other kernel 
> code in any way, and offers the same functionalities. I'd like to keep it 
> that way.

-- 
Nicholas Miell <[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: 2.6.21-rc suspend regression: sysfs deadlock

[Alan Stern]

[For the start of this thread, see 
.]

On Wed, 7 Mar 2007, Linus Torvalds wrote:

> So you just pointed to *another* data structure that apparently violates 
> the "you MUST use refcounting" rule.
> 
> What is it with you people? It's really simple. Data structures must be 
> refcounted if you can reach them two different ways.
> 
> If you don't use refcounting, then you'd better make sure that the data 
> can be reached only one way (for example, by *not* exposing it for sysfs).
> 
> It really *is* that simple. Read the CodingStyle rules.

Linus's analysis is correct as far as it goes, but it misses some very 
important points.  The _real_ problem here, which nobody has pointed out 
so far, is not device removal or driver unloading.  It is driver 
unbinding -- with its consequent issue of access rights.

When a driver is unbound from a device, when should the driver stop trying 
to access that device?  The obvious answer is that it must stop before its 
release() method returns.  Otherwise the device might get bound to 
another driver and we would have both drivers trying to talk to it at the 
same time.

In other words, when a driver unbinds from a device, it loses its right to
access that device.  Same goes for any device-related data structures that
weren't created by the driver itself.  When you realize this, it becomes
obvious that the driver faces a synchronization problem.  All its entry
points must be synchronized with release(), to avoid races.

So there actually are two things a driver has to worry about:

The lifetime of its private data structures (which can be solved
using refcounts as Linus advocated);

The race between release() and other activities (which cannot
be solved by refcounts but needs a true synchronization technique,
such as a mutex).

No doubt some of this sounds familiar; the race between open() and
disconnect() for char device drivers is one we have faced many times and
not always solved perfectly.  Also note that this is a fundamental
problem, affecting many facilities in addition to sysfs.


One way to solve these problems is to put all the responsibility on the 
driver.  Make it refcount its data structures and use mutexes.  This is 
not very attractive for several reasons:

_Lots_ of drivers are affected.  Pretty much any driver which
registers a char device or a sysfs attribute file.

_Lots_ of code would need to be changed, adding considerable
bloat.  Every show()/store() method would need to acquire a mutex,
and many would need to be passed an additional argument, requiring
a change in the sysfs API.  (I can explain why in a follow-up 
email if anyone is interested.)

Most importantly, doing all the refcounting and mutual exclusion
correctly is quite hard.  It's amazingly easy to make mistakes
in these areas.  The chances of getting it right while changing
multiple functions in every single driver are infinitesimal.

Another approach is to put all the responsibility on the core subsystems
that handle driver registration.  They should enforce rigidly two
principles: "No driver callbacks occur after unregistration" and its
prerequisite, "Unregistration is mutually exclusive with driver
callbacks".  (This is exactly what Oliver's original patch did for sysfs.)

The number of core subsystems affected is much smaller than the
total number of drivers.  Sysfs, debugfs, the char device
subsystem, maybe a few others.

Drivers would no longer have to worry about doing their own
synchronization or refcounts.  It would be guaranteed that a
private data structure would never be accessed from sysfs after
device_remove_file() returned, so the structure could safely and
easily be deallocated as part of release().

At the expense of complicating a few central subsystems, we could simplify
a lot of drivers.  I think this is a worthwhile tradeoff.

It does have a small disadvantage; it means that an entry point would
deadlock if it tried to unregister itself.  (The example which started
this whole thread was sdev_store_delete() in the SCSI core.  Writing to
that attribute unregisters the device to which it belongs.)  Clearly the
actual unregistration would have to performed separately in a workqueue.  
I think the number of places where this occurs is pretty small.


It's true that this approach goes against the general philosophy used
elsewhere in the kernel.  Refcounting without synchronization is the
general rule.

However unbinding is a special case.  Normally with refcounting, it
doesn't matter when a driver tries to read or write a data structure.  So
long as the driver still holds a reference, the data will be there and the
access will be okay.

But not with unbinding!  After unbinding, the data will still be there but 
it 

Re: netconsole system freeze when cable unplugged

[Matt Mackall]

On Fri, Mar 09, 2007 at 09:42:43PM +0100, Francois Romieu wrote:
> Simon Arlott <[EMAIL PROTECTED]> :
> > When I unplug the cable the system just stops responding to anything, 
> > at all. No message is printed to the console when the cable is plugged 
> > back in.
> 
> rtl8139_interrupt (spin_lock(>lock))
> -> rtl8139_weird_interrupt
>-> rtl_check_media
>   -> mii_check_media (printk(KERN_INFO "%s: link down\n", ...))
>  [netpoll stuff here]
>  -> rtl8139_poll_controller
> -> rtl8139_interrupt
>*deadlock*

Probably the best thing that can be done here aside from moving
mii_check_media outside interrupt handling is to add
netpoll_plug/unplug(dev) methods that push work off to netpoll's queue
for drivers that have a netpoll recursion problem.

-- 
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: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

[Davide Libenzi]

On Sat, 10 Mar 2007, Nicholas Miell wrote:

> Try reading the timer_create man page.
> 
> In short, you're limited to a single clock, so you can't set timers
> based on wall-clock time (subject to NTP correction), monotomic time
> (not subject to NTP, will not ever go backwards or skip ticks), the
> high-res versions of the previous two clocks, per-thread or per-process
> CPU usage time, or any other clocks that may get introduced in the
> future.

One timer per fd yes. So?
The real-time and monotonic selection can be added. 
If you look at the posix timers code, that's a bunch of code over the real 
meat of it, that is hrtimer.c. The timerfd interface goes straight to 
that, without adding yet another meaning to the sigevent structure, and 
yet another case inside the posix timers trigger functions. That will be 
as unstandard as timerfd is, and even more, since you cannot use that 
interface and hope to be portable in any case.
On top of that, handing over files to the posix timers will creates 
problems with references kept around.
The timerfd code is just a *really* thin layer (if you exclude the 
includes, the structure definitions and the fd setup code, there's 
basically *nothing*) over hrtimer.c and does not mess up with other kernel 
code in any way, and offers the same functionalities. I'd like to keep it 
that way.



- Davide


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

Re: [PATCH] Use more gcc extensions in the Linux headers

[Trent Piepho]

On Fri, 9 Mar 2007, Linus Torvalds wrote:
> On Fri, 9 Mar 2007, Christoph Hellwig wrote:
> Well, since Rusty's macro was hoddible *anyway*, I don't think I'd apply
> it as-is. Breaking icc for something that ugly and not-very-important
> simply makes no sense.
>
> There are better ways to do this.
>
> For one, you could (and should!) abstract these kinds of things out,
> rather than put them in another macro that really does something totally
> different. Then, the macro could have become
>
>   #define ARRAY_SIZE (sizeof_expression + 0*error_if_not_array)

/* Error if X is a pointer, 0 otherwise */
#define ERROR_IF_POINTER(x) \
sizeof(int[-__builtin_types_compatible_p(typeof(x), typeof([0]))])

/* Warning (div by zero) if x is a pointer, 0 otherwise */
#define WARN_IF_POINTER(x) \
(0/!__builtin_types_compatible_p(typeof(x), typeof([0])))

The gcc docs say __builtin_types_compatible_p returns 1 or 0, so the !!
isn't necessary.  And my gcc at least returns 0 for sizeof(int[0]).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/2] NET: Multiple queue network device support

[Waskiewicz Jr, Peter P]

> -Original Message-
> From: Thomas Graf [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 09, 2007 6:35 PM
> To: Waskiewicz Jr, Peter P
> Cc: Kok, Auke-jan H; David Miller; Garzik, Jeff; 
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; 
> Brandeburg, Jesse; Kok, Auke; Ronciak, John
> Subject: Re: [PATCH 1/2] NET: Multiple queue network device support
> 
> * Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> 
> 2007-03-09 15:27
> > That's the entire point of this extra locking.  enqueue() 
> is going to 
> > put an skb into a band somewhere that maps to some queue, 
> and there is 
> > no way to guarantee the skb I retrieve from dequeue() is headed for 
> > the same queue.  Therefore, I need to unlock the queue 
> after I finish 
> > enqueuing, since having that lock makes little sense to dequeue().
> > dequeue() will then grab *a* lock on a queue; it may be the 
> same one 
> > we had during enqueue(), but it may not be.  And the 
> placement of the 
> > unlock of that queue is exactly where it happens in non-multiqueue, 
> > which is right before the hard_start_xmit().
> 
> The lock is already unlocked after dequeue, from your prio_dequeue():
> 
>if (netif_is_multiqueue(sch->dev)) {
>queue = q->band2queue[prio];
>if 
> (spin_trylock(>dev->egress_subqueue[queue].queue_lock)) {
>qdisc = q->queues[prio];
>skb = qdisc->dequeue(qdisc);
>if (skb) {
>sch->q.qlen--;
>skb->priority = prio;
>
> spin_unlock(>dev->egress_subqueue[queue].queue_lock);
>return skb;
>}
>
> spin_unlock(>dev->egress_subqueue[queue].queue_lock);
>}

Ok, now I see what's wrong.  Taking Dave M.'s recommendation to store
the queue mapping in the skb will let me unlock the queue when dequeue()
returns.  I'll fix this locking issue; thanks for the feedback and
persistent drilling into my thick head.

-PJ Waskiewicz
[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 v2] Bitbanging i2c bus driver using the GPIO API

[Jean Delvare]

Hi Haavard,

On Sat, 10 Mar 2007 14:13:28 +0100, Haavard Skinnemoen wrote:
> This is a very simple bitbanging i2c bus driver utilizing the new
> arch-neutral GPIO API. Useful for chips that don't have a built-in
> i2c controller, additional i2c busses, or testing purposes.
> 
> To use, include something similar to the following in the
> board-specific setup code:
> 
>   #include 
> 
>   static struct i2c_gpio_platform_data i2c_gpio_data = {
>   .sda_pin= GPIO_PIN_FOO,
>   .scl_pin= GPIO_PIN_BAR,
>   };
>   static struct platform_device i2c_gpio_device = {
>   .name   = "i2c-gpio",
>   .id = 0,
>   .dev= {
>   .platform_data  = _gpio_data,
>   },
>   };
> 
> Register this platform_device, set up the i2c pins as GPIO if
> required and you're ready to go.

I like the idea very much. Would this let us get rid of i2c-ixp2000?
i2c-ixp4xx? scx200_i2c? Other drivers?

>  drivers/i2c/busses/Kconfig|8 ++
>  drivers/i2c/busses/Makefile   |1 +
>  drivers/i2c/busses/i2c-gpio.c |  211 
> +
>  include/linux/i2c-gpio.h  |   30 ++
>  4 files changed, 250 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index fb19dbb..52f79d1 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -102,6 +102,14 @@ config I2C_ELEKTOR
> This support is also available as a module.  If so, the module 
> will be called i2c-elektor.
>  
> +config I2C_GPIO
> + tristate "GPIO-based bitbanging i2c driver"
> + depends on I2C && GENERIC_GPIO
> + select I2C_ALGOBIT
> + help
> +   This is a very simple bitbanging i2c driver utilizing the
> +   arch-neutral GPIO API to control the SCL and SDA lines.
> +
>  config I2C_HYDRA
>   tristate "CHRP Apple Hydra Mac I/O I2C interface"
>   depends on I2C && PCI && PPC_CHRP && EXPERIMENTAL
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 290b540..68f2b05 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111)   += i2c-amd8111.o
>  obj-$(CONFIG_I2C_AT91)   += i2c-at91.o
>  obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
>  obj-$(CONFIG_I2C_ELEKTOR)+= i2c-elektor.o
> +obj-$(CONFIG_I2C_GPIO)   += i2c-gpio.o
>  obj-$(CONFIG_I2C_HYDRA)  += i2c-hydra.o
>  obj-$(CONFIG_I2C_I801)   += i2c-i801.o
>  obj-$(CONFIG_I2C_I810)   += i2c-i810.o
> diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
> new file mode 100644
> index 000..423db0a
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-gpio.c
> @@ -0,0 +1,211 @@
> +/*
> + * Bitbanging i2c bus driver using the GPIO API
> + *
> + * Copyright (C) 2006 Atmel Corporation

I'm told we're in year 2007 ;)

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +/* Toggle SDA by changing the direction of the pin */
> +static void i2c_gpio_setsda_dir(void *data, int state)
> +{
> + struct i2c_gpio_platform_data *pdata = data;
> +
> + if (state)
> + gpio_direction_input(pdata->sda_pin);
> + else {
> + gpio_direction_output(pdata->sda_pin);
> + gpio_set_value(pdata->sda_pin, 0);
> + }
> +}
> +
> +/*
> + * Toggle SDA by changing the output value of the pin. This is only
> + * valid for pins configured as open drain (i.e. setting the value
> + * high effectively turns off the output driver.)
> + */
> +static void i2c_gpio_setsda_val(void *data, int state)
> +{
> + struct i2c_gpio_platform_data *pdata = data;
> +
> + gpio_set_value(pdata->sda_pin, state);
> +}
> +
> +/* Toggle SCL by changing the direction of the pin. */
> +static void i2c_gpio_setscl_dir(void *data, int state)
> +{
> + struct i2c_gpio_platform_data *pdata = data;
> +
> + if (state)
> + gpio_direction_input(pdata->scl_pin);
> + else {
> + gpio_direction_output(pdata->scl_pin);
> + gpio_set_value(pdata->scl_pin, 0);
> + }
> +}
> +
> +/*
> + * Toggle SCL by changing the output value of the pin. This is used
> + * for pins that are configured as open drain and for output-only
> + * pins. The latter case will break the i2c protocol, but it will
> + * often work in practice.
> + */
> +static void i2c_gpio_setscl_val(void *data, int state)
> +{
> + struct i2c_gpio_platform_data *pdata = data;
> +
> + gpio_set_value(pdata->scl_pin, state);
> +}
> +
> +int i2c_gpio_getsda(void *data)
> +{
> + struct i2c_gpio_platform_data *pdata = data;
> +
> + return gpio_get_value(pdata->sda_pin);
> +}


What value 

Re: [linux-usb-devel] 2.6.21-rc3-mm1

[Alan Stern]

On Sat, 10 Mar 2007, Mariusz Kozlowski wrote:

> Hello,
> 
> > > Right. Can't be 100% sure but without the patch it would have probably
> > > failed by now so I guess the patch is ok. Not sure how to make usb mouse
> > > plugging/unplugging process automatic ;-)
> > 
> > echo FOO >/sys/bus/usb/drivers/usbhid/unbind
> > 
> > to simulate an unplug (actually, to do an unbind), and
> > 
> > echo FOO >/sys/bus/usb/drivers/usbhid/unbind
>   ^^ bind I guess

Whoops, yes.  Cut & paste strikes again...

> > to do a bind, where FOO is the name of the USB mouse device link present
> > in the /sys/bus/usb/drivers/usbhid directory.
> 
> # ls -al /sys/bus/usb/drivers/usbhid
> total 0
> drwxr-xr-x 2 root root0 Mar 10 17:30 .
> drwxr-xr-x 8 root root0 Mar 10 17:14 ..
> lrwxrwxrwx 1 root root0 Mar 10 17:30 2-2:1.0 -> 
> ../../../../devices/pci:00/:00:0c.0/usb2/2-2/2-2:1.0
> --w--- 1 root root 4096 Mar 10 17:17 bind
> lrwxrwxrwx 1 root root0 Mar 10 17:17 module -> ../../../../module/usbhid
> --w--- 1 root root 4096 Mar 10 17:17 new_id
> --w--- 1 root root0 Mar 10 17:22 unbind
> 
> # echo "2-2:1.0" > /sys/bus/usb/drivers/usbhid/unbind
> bash: echo: write error: No such device
> 
> Any thoughts?

Another mistake on my part.  The correct command is

echo -n '2-2:1.0' >/sys/bus/usb/drivers/usbhid/unbind

Without the "-n", the system thinks that the newline character at the end 
of the line written by "echo" is part of the filename.

Alan Stern

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

Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

[Nicholas Miell]

On Fri, 2007-03-09 at 23:36 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
> 
> > On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
> > > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> > > > 
> > > > So extend the existing POSIX timer API to deliver expiry events via a
> > > > fd.
> > > 
> > > It'll be out of standard as timerfd is, w/out code savings. Look at the 
> > > code and tell me what could be saved. Prolly the ten lines of the timer 
> > > callback. Lines that you'll have to drop inside the current posix timer 
> > > layer. Better leave standards alone, especially like in this case, when 
> > > the savings are not there.
> > > 
> > 
> > OK, here's a more formal listing of my objections to the introduction of
> > timerfd in this form:
> > 
> > A) It is a new general-purpose ABI intended for wide-scale usage, and
> > thus must be maintained forever.
> 
> Yup
> 
> 
> > B) It is less functional than the existing ABIs -- modulo their
> > "delivery via signals only" limitation, which can be corrected (and has
> > been already in other operating systems).
> 
> Less functional? Please, do tell me ...
> 

Try reading the timer_create man page.

In short, you're limited to a single clock, so you can't set timers
based on wall-clock time (subject to NTP correction), monotomic time
(not subject to NTP, will not ever go backwards or skip ticks), the
high-res versions of the previous two clocks, per-thread or per-process
CPU usage time, or any other clocks that may get introduced in the
future.

In addition, you've introduced an entirely new incompatible API that
probably doesn't fit easily into existing software that already uses
POSIX timers.


> 
> > C) Being an entirely new creation that completely ignores past work in
> > this area, it has no hope of ever getting into POSIX.
> > 
> > which means
> > 
> > D) At some point in time, Linux is going to get the POSIX version (in
> > whatever form it takes), making this new ABI useless dead weight (see
> > point A).
> 
> Adding parameters/fields to a standard is going to create even more 
> confusion than a new *single* function. And the code to cross-link the 
> timerfd and the current posix timers is going to end up in being more 
> complex than the current one.
> 

Yes, but the standard explicitly allows you to do this. Furthermore, if
you work within the existing framework, you can lobby for the inclusion
of your API in the next version of POSIX.

Simplicity of the code is only a virtue if you don't have to do the
exact same thing again with a different interface later while keeping
the maintenance burden of the existing proprietary (and, thus,
unpopular) interface.

-- 
Nicholas Miell <[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/

[SOUND] ice1712: build fixes

[Ralf Baechle]

  CC [M]  sound/pci/ice1712/ice1712.o
sound/pci/ice1712/ice1712.c:290: error: snd_ice1712_mixer_digmix_route_ac97 
causes a section type conflict
sound/pci/ice1712/ice1712.c:1630: error: snd_ice1712_eeprom causes a section 
type conflict
sound/pci/ice1712/ice1712.c:1894: error: snd_ice1712_pro_internal_clock causes 
a section type conflict
sound/pci/ice1712/ice1712.c:1965: error: snd_ice1712_pro_internal_clock_default 
causes a section type conflict
sound/pci/ice1712/ice1712.c:2004: error: snd_ice1712_pro_rate_locking causes a 
section type conflict
sound/pci/ice1712/ice1712.c:2043: error: snd_ice1712_pro_rate_reset causes a 
section type conflict
sound/pci/ice1712/ice1712.c:2210: error: snd_ice1712_mixer_pro_analog_route 
causes a section type conflict
sound/pci/ice1712/ice1712.c:2218: error: snd_ice1712_mixer_pro_spdif_route 
causes a section type conflict
sound/pci/ice1712/ice1712.c:2260: error: snd_ice1712_mixer_pro_volume_rate 
causes a section type conflict
sound/pci/ice1712/ice1712.c:2293: error: snd_ice1712_mixer_pro_peak causes a 
section type conflict
sound/pci/ice1712/ice1712.c:1666: error: snd_ice1712_spdif_default causes a 
section type conflict
sound/pci/ice1712/ice1712.c:1717: error: snd_ice1712_spdif_maskc causes a 
section type conflict
sound/pci/ice1712/ice1712.c:1726: error: snd_ice1712_spdif_maskp causes a 
section type conflict
sound/pci/ice1712/ice1712.c:1753: error: snd_ice1712_spdif_stream causes a 
section type conflict

Gcc like its __devinitdata readable not const, it seems.  An alternative
fix would be to remove the __devinitdata attribute but that would result
in slight runtime bloat.

Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>

---

Take 2, the complete version of the patch.

diff --git a/sound/pci/ice1712/delta.c b/sound/pci/ice1712/delta.c
index 3eeb36c..af65980 100644
--- a/sound/pci/ice1712/delta.c
+++ b/sound/pci/ice1712/delta.c
@@ -416,7 +416,7 @@ static int 
snd_ice1712_delta1010lt_wordclock_status_get(struct snd_kcontrol *kco
return 0;
 }
 
-static const struct snd_kcontrol_new snd_ice1712_delta1010lt_wordclock_status 
__devinitdata =
+static struct snd_kcontrol_new snd_ice1712_delta1010lt_wordclock_status 
__devinitdata =
 {
.access =   (SNDRV_CTL_ELEM_ACCESS_READ),
.iface =SNDRV_CTL_ELEM_IFACE_MIXER,
@@ -429,7 +429,7 @@ static const struct snd_kcontrol_new 
snd_ice1712_delta1010lt_wordclock_status __
  * initialize the chips on M-Audio cards
  */
 
-static const struct snd_akm4xxx akm_audiophile __devinitdata = {
+static struct snd_akm4xxx akm_audiophile __devinitdata = {
.type = SND_AK4528,
.num_adcs = 2,
.num_dacs = 2,
@@ -438,7 +438,7 @@ static const struct snd_akm4xxx akm_audiophile 
__devinitdata = {
}
 };
 
-static const struct snd_ak4xxx_private akm_audiophile_priv __devinitdata = {
+static struct snd_ak4xxx_private akm_audiophile_priv __devinitdata = {
.caddr = 2,
.cif = 0,
.data_mask = ICE1712_DELTA_AP_DOUT,
@@ -450,7 +450,7 @@ static const struct snd_ak4xxx_private akm_audiophile_priv 
__devinitdata = {
.mask_flags = 0,
 };
 
-static const struct snd_akm4xxx akm_delta410 __devinitdata = {
+static struct snd_akm4xxx akm_delta410 __devinitdata = {
.type = SND_AK4529,
.num_adcs = 2,
.num_dacs = 8,
@@ -459,7 +459,7 @@ static const struct snd_akm4xxx akm_delta410 __devinitdata 
= {
}
 };
 
-static const struct snd_ak4xxx_private akm_delta410_priv __devinitdata = {
+static struct snd_ak4xxx_private akm_delta410_priv __devinitdata = {
.caddr = 0,
.cif = 0,
.data_mask = ICE1712_DELTA_AP_DOUT,
@@ -471,7 +471,7 @@ static const struct snd_ak4xxx_private akm_delta410_priv 
__devinitdata = {
.mask_flags = 0,
 };
 
-static const struct snd_akm4xxx akm_delta1010lt __devinitdata = {
+static struct snd_akm4xxx akm_delta1010lt __devinitdata = {
.type = SND_AK4524,
.num_adcs = 8,
.num_dacs = 8,
@@ -481,7 +481,7 @@ static const struct snd_akm4xxx akm_delta1010lt 
__devinitdata = {
}
 };
 
-static const struct snd_ak4xxx_private akm_delta1010lt_priv __devinitdata = {
+static struct snd_ak4xxx_private akm_delta1010lt_priv __devinitdata = {
.caddr = 2,
.cif = 0, /* the default level of the CIF pin from AK4524 */
.data_mask = ICE1712_DELTA_1010LT_DOUT,
@@ -493,7 +493,7 @@ static const struct snd_ak4xxx_private akm_delta1010lt_priv 
__devinitdata = {
.mask_flags = 0,
 };
 
-static const struct snd_akm4xxx akm_delta44 __devinitdata = {
+static struct snd_akm4xxx akm_delta44 __devinitdata = {
.type = SND_AK4524,
.num_adcs = 4,
.num_dacs = 4,
@@ -503,7 +503,7 @@ static const struct snd_akm4xxx akm_delta44 __devinitdata = 
{
}
 };
 
-static const struct snd_ak4xxx_private akm_delta44_priv __devinitdata = {
+static struct snd_ak4xxx_private akm_delta44_priv __devinitdata = {
.caddr = 2,
.cif = 0, /* the 

Re: PROBLEM: "Make nenuconfig" does not save parameters.

[Cyrill Gorcunov]

[Jan Engelhardt - Sat, Mar 10, 2007 at 08:04:38PM +0100]
| 
| On Mar 10 2007 21:50, Cyrill Gorcunov wrote:
| >
| >Actually, I always work with only .config file too... and the reason I
| >wrote you is Vladimir's mail... so either menuconfig does not work as
| >expected or users does not expect a such behaviour of menuconfig.
| 
| The latter. Though this behavior has been there since... I think since
| menuconfig came into existence. It goes way back to 2.4 and 2.2.
| 
| 
| Jan
| -- 
| 

Thanks for mail. The topic is closed :)

Cyrill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Add nForce MCP61 support to i2c-nforce2

[Jean Delvare]

Hi Petr,

On Sat, 10 Mar 2007 09:00:03 +0100, Petr Vandrovec wrote:
> Hello,
>   patch below adds support for nVidia's SMBus adapter present on Gateway's 
> GT5414E 
> motherboard (ECS's MCP61 PM-AM).  Patch is for current Linus's git tree.

We already have a patch doing exactly this in -mm:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/broken-out/jdelvare-i2c-i2c-nforce2-add-mcp61-mcp65-support.patch

> 00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
> Subsystem: Elitegroup Computer Systems Unknown device 2601
> Flags: 66MHz, fast devsel, IRQ 10
> I/O ports at fc00 [size=64]
> I/O ports at 1c00 [size=64]
> I/O ports at f400 [size=64]
> Capabilities: [44] Power Management version 2

BTW, note how the MCP61 has not 2 but 3 64-byte I/O areas declared. The
previous chips used BAR 4 and 5, this new one additionally uses BAR 0.
Without documentation it's hard to be sure this is a 3rd SMBus channel,
but it sure looks so. Maybe you'll want to hack the i2c-nforce2 driver
a bit to confirm or infirm this theory.

-- 
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [SOUND] ice1712: build fixes

[Ralf Baechle]

On Sat, Mar 10, 2007 at 07:26:41PM +, Ralf Baechle wrote:

Whops, please ignore this one, I send the wrong file.

  Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler)

[William Lee Irwin III]

William Lee Irwin III wrote:
>> Last I checked there were limits to runtime configurability centering
>> around only supporting a compiled-in set of scheduling drivers, unless
>> Peter's taken it the rest of the way without my noticing. It's unclear
>> what you have in mind in terms of dynamic extensibility. My only guess
>> would be pluggable scheduling policy/class support for individual
>> schedulers in addition to plugging the individual schedulers, except
>> I'm rather certain that Williams' code doesn't do anything with modules.

On Sat, Mar 10, 2007 at 07:47:11PM +0300, Al Boldi wrote:
> Correct, it doesn't, yet.  But do you think that PlugSched has the basic 
> infrastructure in place to support this, or would it require a complete 
> redesign/rewrite.

The piece I got done was just representing schedulers as driver-like
affairs (which, embarrassingly enough, needed lots of bugfixing), and
everyone's just been running with that and boot-time switching ever
since. Runtime switching (to module-loaded schedulers or otherwise)
needs a lot of hotplug-esque work. Scheduler class support, pluggable
or otherwise, needs per-scheduler abstracting things out along the same
lines as what was originally done for the overall schedulers
surrounding enqueueing and dequeueing so the scheduler itself only
plucks tasks out of and stuffs tasks into some sort of abstracted-out
queue or set of queues, though I did try to break things down at a low
enough level where they'd be plausible for more than just the one
driver (never distributed) I used to test the design. I dumped the
entire project long before ever getting to where modules entered the
picture, and have never touched modules otherwise, so I'm not entirely
sure what other issues would come up with those after the smoke clears
from runtime switching.

I don't plan on doing anything here myself, since the boot-time
switching etc. is likely already considered offensive enough.

The next time something comes up that bears a risk of positioning me
against the kernel's political winds, I'll just rm it or not write it
at all instead of leaving code around (or worse yet, passing it around)
to be taken up by others. It just leaves a lot of embarrassed explaining
to do when it resurfaces years later, or otherwise leaves a rather bad
taste in my mouth when NIH'd years later like other things not mentioned
here (VM code kept quiet similarly to plugsched) and everyone approves
so long as it didn't come from me.


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

[SOUND] ice1712: build fixes

[Ralf Baechle]

  CC [M]  sound/pci/ice1712/ice1712.o
sound/pci/ice1712/ice1712.c:290: error: snd_ice1712_mixer_digmix_route_ac97 
causes a section type conflict
sound/pci/ice1712/ice1712.c:1630: error: snd_ice1712_eeprom causes a section 
type conflict
sound/pci/ice1712/ice1712.c:1894: error: snd_ice1712_pro_internal_clock causes 
a section type conflict
sound/pci/ice1712/ice1712.c:1965: error: snd_ice1712_pro_internal_clock_default 
causes a section type conflict
sound/pci/ice1712/ice1712.c:2004: error: snd_ice1712_pro_rate_locking causes a 
section type conflict
sound/pci/ice1712/ice1712.c:2043: error: snd_ice1712_pro_rate_reset causes a 
section type conflict
sound/pci/ice1712/ice1712.c:2210: error: snd_ice1712_mixer_pro_analog_route 
causes a section type conflict
sound/pci/ice1712/ice1712.c:2218: error: snd_ice1712_mixer_pro_spdif_route 
causes a section type conflict
sound/pci/ice1712/ice1712.c:2260: error: snd_ice1712_mixer_pro_volume_rate 
causes a section type conflict
sound/pci/ice1712/ice1712.c:2293: error: snd_ice1712_mixer_pro_peak causes a 
section type conflict
sound/pci/ice1712/ice1712.c:1666: error: snd_ice1712_spdif_default causes a 
section type conflict
sound/pci/ice1712/ice1712.c:1717: error: snd_ice1712_spdif_maskc causes a 
section type conflict
sound/pci/ice1712/ice1712.c:1726: error: snd_ice1712_spdif_maskp causes a 
section type conflict
sound/pci/ice1712/ice1712.c:1753: error: snd_ice1712_spdif_stream causes a 
section type conflict

Gcc like its __devinitdata readable not const, it seems.  An alternative
fix would be to remove the __devinitdata attribute but that would result
in slight runtime bloat.

Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>

diff --git a/sound/pci/ice1712/delta.c b/sound/pci/ice1712/delta.c
index 3eeb36c..a48140b 100644
--- a/sound/pci/ice1712/delta.c
+++ b/sound/pci/ice1712/delta.c
@@ -735,7 +735,7 @@ static int __devinit snd_ice1712_delta_add_controls(struct 
snd_ice1712 *ice)
 
 
 /* entry point */
-const struct snd_ice1712_card_info snd_ice1712_delta_cards[] __devinitdata = {
+struct snd_ice1712_card_info snd_ice1712_delta_cards[] __devinitdata = {
{
.subvendor = ICE1712_SUBDEVICE_DELTA1010,
.name = "M Audio Delta 1010",
diff --git a/sound/pci/ice1712/delta.h b/sound/pci/ice1712/delta.h
index e65d669..746ebde 100644
--- a/sound/pci/ice1712/delta.h
+++ b/sound/pci/ice1712/delta.h
@@ -46,7 +46,7 @@
 #define ICE1712_SUBDEVICE_MEDIASTATION 0x694c0100
 
 /* entry point */
-extern const struct snd_ice1712_card_info snd_ice1712_delta_cards[];
+extern struct snd_ice1712_card_info snd_ice1712_delta_cards[];
 
 
 /*
diff --git a/sound/pci/ice1712/ews.c b/sound/pci/ice1712/ews.c
index 9b7ff30..467fd01 100644
--- a/sound/pci/ice1712/ews.c
+++ b/sound/pci/ice1712/ews.c
@@ -989,7 +989,7 @@ static int __devinit snd_ice1712_ews_add_controls(struct 
snd_ice1712 *ice)
 
 
 /* entry point */
-const struct snd_ice1712_card_info snd_ice1712_ews_cards[] __devinitdata = {
+struct snd_ice1712_card_info snd_ice1712_ews_cards[] __devinitdata = {
{
.subvendor = ICE1712_SUBDEVICE_EWX2496,
.name = "TerraTec EWX24/96",
diff --git a/sound/pci/ice1712/ews.h b/sound/pci/ice1712/ews.h
index df449b4..a12a0b0 100644
--- a/sound/pci/ice1712/ews.h
+++ b/sound/pci/ice1712/ews.h
@@ -40,7 +40,7 @@
 #define ICE1712_SUBDEVICE_PHASE88  0x3b155111
 
 /* entry point */
-extern const struct snd_ice1712_card_info snd_ice1712_ews_cards[];
+extern struct snd_ice1712_card_info snd_ice1712_ews_cards[];
 
 
 /* TerraTec EWX 24/96 configuration definitions */
diff --git a/sound/pci/ice1712/hoontech.c b/sound/pci/ice1712/hoontech.c
index df97313..8193450 100644
--- a/sound/pci/ice1712/hoontech.c
+++ b/sound/pci/ice1712/hoontech.c
@@ -298,7 +298,7 @@ static int __devinit snd_ice1712_ez8_init(struct 
snd_ice1712 *ice)
 
 
 /* entry point */
-const struct snd_ice1712_card_info snd_ice1712_hoontech_cards[] __devinitdata 
= {
+struct snd_ice1712_card_info snd_ice1712_hoontech_cards[] __devinitdata = {
{
.subvendor = ICE1712_SUBDEVICE_STDSP24,
.name = "Hoontech SoundTrack Audio DSP24",
diff --git a/sound/pci/ice1712/hoontech.h b/sound/pci/ice1712/hoontech.h
index b62d6e4..1ee538b 100644
--- a/sound/pci/ice1712/hoontech.h
+++ b/sound/pci/ice1712/hoontech.h
@@ -35,7 +35,7 @@
 #define ICE1712_SUBDEVICE_STDSP24_MEDIA7_1 0x16141217  /* Hoontech ST 
Audio DSP24 Media 7.1 */
 #define ICE1712_SUBDEVICE_EVENT_EZ80x00010001  /* A dummy id 
for EZ8 */
 
-extern const struct snd_ice1712_card_info snd_ice1712_hoontech_cards[];
+extern struct snd_ice1712_card_info snd_ice1712_hoontech_cards[];
 
 
 /* Hoontech SoundTrack Audio DSP 24 GPIO definitions */
diff --git a/sound/pci/ice1712/ice1712.c b/sound/pci/ice1712/ice1712.c
index 830a1bb..23d1419 100644
--- a/sound/pci/ice1712/ice1712.c
+++ b/sound/pci/ice1712/ice1712.c
@@ -287,7 +287,7 @@ static int snd_ice1712_digmix_route_ac97_put(struct 

Re: refcounting drivers' data structures used in sysfs buffers

[Alan Stern]

On Fri, 9 Mar 2007, Oliver Neukum wrote:

> Am Freitag, 9. März 2007 21:08 schrieb Alan Stern:
> > After some more thought, I basically agree with what Oliver wrote
> > originally.  sysfs_dirent is indeed the logical place to store the kref
> > pointer.  However it needs to be used during open and release, not during
> 
> OK.
> 
> > read, write, and poll.  Another point, which Oliver didn't think of, is
> > that the kref pointer needs to be passed to the driver as an argument in
> > the show() and store() method calls.
> 
> Why? What's wrong with simply calling kref_get/put?

It's the same old problem: the race between unbind and sysfs I/O.  What
good does holding a reference to the private data structure do if the
show/store method gets called after the driver has been unbound from the
device?  dev_get_drvdata() will no longer provide a valid pointer to the
private data, so the method will have no way to access it.  Hence the
method needs another argument.

(BTW, the sysfs core would actually need more than a kref.  It would also 
need a pointer to a release routine -- the kref contains only the atomic 
counter.  The more you think about it, the more complicated this approach 
becomes.)

> > Finally, there's added complexity in each driver which wants to use the 
> > new facility.  The module_exit routine will need to be smart enough to 
> > block until all the private data structures have been released.  
> > usb-storage does something like that now; it's kind of ugly (although it 
> > could be improved if appropriate support were added to the core kernel).
> 
> If we up the module count for every bound device, all device attributes
> should be gone before we ever get that far.

Not quite right.  However, since every open sysfs file holds a module
reference, if the driver's module_exit has been called then there can be
no open sysfs files, hence no private data still pinned.  Thus this isn't
a problem at all.


But never mind all the above.  I'm going to post another message on this
thread in which I argue that Oliver's original approach was a good one and
should not have been reverted.  The specific problem identified by Hugh
Dickins can be fixed in the way Dmitry first suggested, by doing the real
operation from a workqueue routine.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Bitbanging i2c bus driver using the GPIO API

[Jean Delvare]

On Fri, 9 Mar 2007 11:30:12 -0800, David Brownell wrote:
> > --- a/include/linux/i2c-id.h
> > +++ b/include/linux/i2c-id.h
> > @@ -194,6 +194,7 @@
> >  #define I2C_HW_B_EM28XX0x01001f /* em28xx video capture cards 
> > */
> >  #define I2C_HW_B_CX2341X   0x010020 /* Conexant CX2341X MPEG encoder cards 
> > */
> >  #define I2C_HW_B_INTELFB   0x010021 /* intel framebuffer driver */
> > +#define I2C_HW_B_GPIO  0x010022 /* Generic GPIO-based driver */
> 
> It'd be nice to completely abolish those IDs, starting by not
> adding new ones.  Especially, not adding unused ones!

I'm confident that we'll be able to get rid of the I2C device driver
IDs pretty soon thanks to your new i2c-core model, but I'm not sure if
we'll be able to get rid of I2C adapter drivers IDs that quickly. But I
agree with you, please let's not add new unused IDs.

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

[SOUND] hda_intel: build fix

[Ralf Baechle]

  CC [M]  sound/pci/hda/hda_intel.o
sound/pci/hda/hda_intel.c:1508: error: position_fix_list causes a section type 
conflict

Gcc like its __devinitdata readable not const, it seems.  An alternative
fix would be to remove the __devinitdata attribute but that would result
in slight runtime bloat.

Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index b9a8e23..63b6854 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1505,7 +1505,7 @@ static int azx_dev_free(struct snd_device *device)
 /*
  * white/black-listing for position_fix
  */
-static const struct snd_pci_quirk position_fix_list[] __devinitdata = {
+static struct snd_pci_quirk position_fix_list[] __devinitdata = {
SND_PCI_QUIRK(0x1028, 0x01cc, "Dell D820", POS_FIX_NONE),
{}
 };
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: RSDL v0.28 for 2.6.20

[Willy Tarreau]

On Sat, Mar 10, 2007 at 01:09:35PM -0500, Stephen Clark wrote:
> Con Kolivas wrote:
> 
> >Here is an update for RSDL to version 0.28
> >
> >Full patch:
> >http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-rsdl-0.28.patch
> >
> >Series:
> >http://ck.kolivas.org/patches/staircase-deadline/2.6.20/
> >
> >The patch to get you from 0.26 to 0.28:
> >http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26-0.28.patch
> >
> >A similar patch and directories will be made for 2.6.21-rc3 without 
> >further announcement
> >
> > 
> >
> doesn't apply against 2.6.20.2:
> 
> patch -p1 <~/2.6.20-sched-rsdl-0.28.patch --dry-run
> patching file include/linux/list.h
> patching file fs/proc/array.c
> patching file fs/pipe.c
> patching file include/linux/sched.h
> patching file include/asm-generic/bitops/sched.h
> patching file include/asm-s390/bitops.h
> patching file kernel/sched.c
> Hunk #41 FAILED at 3531.
> 1 out of 62 hunks FAILED -- saving rejects to file kernel/sched.c.rej
> patching file include/linux/init_task.h
> patching file Documentation/sched-design.txt

It is easier to apply 2.6.20.2 on top of 2.6.20+RSDL. The .2 patch
is a one-liner that you can easily fix by hand, and I'm not even
certain that it is still required :

--- ./kernel/sched.c.orig   2007-03-10 13:03:51 +0100
+++ ./kernel/sched.c2007-03-10 13:08:02 +0100
@@ -3544,7 +3544,7 @@
next = list_entry(queue->next, struct task_struct, run_list);
}
 
-   if (dependent_sleeper(cpu, rq, next))
+   if (rq->nr_running == 1 && dependent_sleeper(cpu, rq, next))
next = rq->idle;
 switch_tasks:
if (next == rq->idle)

BTW, Con, I think that you should base your work on 2.6.20.[23] and not
2.6.20 next time, due to this conflict. It will get wider adoption.

Regards,
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: PROBLEM: "Make nenuconfig" does not save parameters.

[Jan Engelhardt]

On Mar 10 2007 21:50, Cyrill Gorcunov wrote:
>
>Actually, I always work with only .config file too... and the reason I
>wrote you is Vladimir's mail... so either menuconfig does not work as
>expected or users does not expect a such behaviour of menuconfig.

The latter. Though this behavior has been there since... I think since
menuconfig came into existence. It goes way back to 2.4 and 2.2.


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

Re: PROBLEM: "Make nenuconfig" does not save parameters.

[Cyrill Gorcunov]

[Jan Engelhardt - Sat, Mar 10, 2007 at 07:23:41PM +0100]
| 
| On Mar 10 2007 20:50, Cyrill Gorcunov wrote:
| >
| >lets see to the following scenario:
| >
| > 1) I've taken a pure Linux kernel (no .config at all)
| > 2) I started menuconfig, made a few changes and saved the file
| > to .config1 as alternate
| > 3) Then I made some additional changes
| > 4) Then I'm getting out of menuconfig and of course "Save
| > configuration..?" question is raising. Ok, I'm selecting
| > "Yes" and as result new configuration will be written to the .config
| > file. All works as it should be...
| > 
| >...but as you mentoined in your message "perhaps all Office Suites do
| >the same" - no, Office do not the same.
| 
| 
|   1) I start a new document
|   2) add some text, "save as" it to config1.txt
|   3) make more text
|   4) choose File,Exit - prompts me to save
| 
| (perhaps not to .config, but instead config1.txt, but at least, it prompts

and there you hit the problem to the eye - when you're working
with text document you always know in *which* file you're now.
So if you've saved alternate config - _keep his name in mind_ -
that's what menuconfig tell us...

| me, and gives me the choice to go back into menuconfig and save it under a
| different name). So what I just wanted to make clear is that you don't
| lose any changes without explicitly saying Don't Save.
| 
| >The only question I have (and it could resolve all our problems) - what an
| >alternate config file is:
| >
| > - just a snapshot of a config tree at moment of its writting
| > - _working_ file to which configurator should write parameters
| >
| >your comments?
| 
| Whether the 'working config file path' should change when you do
| 'Save as Alternate' or not, is a menuconfig axiom. Ask Sam Ravnborg
| if you want it changed :-)
| 
| [ I see where you are going. I am not biased to either because I usually
|   only use it to save to .config. ]
| 
| 
| 
| Jan
| -- 
| 

Actually, I always work with only .config file too... and the reason I
wrote you is Vladimir's mail... so either menuconfig does not work as
expected or users does not expect a such behaviour of menuconfig.

Cyrill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] proc: maps protection

[Kees Cook]

On Fri, Mar 09, 2007 at 09:01:41PM -0800, Arjan van de Ven wrote:
> >I just don't know what it will break - we're changing things so that user A
> >cannot monitor user B's memory maps.  I feel that it's sure to break
> >various people's fancy custom system activity monitoring/logging setups,
> >and the sort of users who will be affected are, alas, the sort of people
> >who won't run a kernel with this change in it for another couple of years
> >yet.
> 
> except if they run RHEL or FC kernels, in which case they already have 
> that change

Right, this is a "gentler" version of just slapping 0400 perms on the 
maps files, which already has the same effect.  I think tightening this 
bit of security is worth some possible breakage.

> >Do we actually need to disable the whole interface?  If all you're
> >concerned about is the pathname then perhaps the knob could cause that
> >pathname to be replaced with "".  That'll cause things to
> >break less seriously and still allows somewhat useful info to be gathered.
> 
> the problem part is that you can see EXACLTY where glibc is loaded in 
> memory, which effectively defeats address space randomization for 
> local users

Right; and since the maps are loaded in a specific order, just dropping 
the filename isn't going to help in protecting the ASLR.  e.g. I can get 
apache's library list from its ELF, and it's very easy to line that up 
with the maps file even if the filenames are missing.

Here's another revision, with both the "can ptrace" and the global /proc 
knob; and I'll beg for defaulting the knob to "on".  :)

Signed-off-by: Kees Cook <[EMAIL PROTECTED]>

---
 fs/proc/base.c |3 +++
 fs/proc/internal.h |2 ++
 fs/proc/task_mmu.c |   16 +++-
 fs/proc/task_nommu.c   |6 ++
 include/linux/sysctl.h |1 +
 kernel/sysctl.c|9 +
 6 files changed, 36 insertions(+), 1 deletion(-)
---
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 1a979ea..9b6e731 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -123,6 +123,9 @@ struct pid_entry {
NULL, _info_file_operations,   \
{ .proc_read = _##OTYPE } )
 
+int maps_protect = 1;
+EXPORT_SYMBOL(maps_protect);
+
 static struct fs_struct *get_fs_struct(struct task_struct *task)
 {
struct fs_struct *fs;
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 987c773..596d925 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -31,6 +31,8 @@ do {  \
 extern int nommu_vma_show(struct seq_file *, struct vm_area_struct *);
 #endif
 
+extern int maps_protect;
+
 extern void create_seq_entry(char *name, mode_t mode, const struct 
file_operations *f);
 extern int proc_exe_link(struct inode *, struct dentry **, struct vfsmount **);
 extern int proc_tid_stat(struct task_struct *,  char *);
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 55ade0d..2e43c12 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -134,6 +134,9 @@ static int show_map_internal(struct seq_file *m, void *v, 
struct mem_size_stats
dev_t dev = 0;
int len;
 
+   if (maps_protect && !ptrace_may_attach(task))
+   return -EACCES;
+
if (file) {
struct inode *inode = vma->vm_file->f_path.dentry->d_inode;
dev = inode->i_sb->s_dev;
@@ -444,11 +447,22 @@ struct file_operations proc_maps_operations = {
 #ifdef CONFIG_NUMA
 extern int show_numa_map(struct seq_file *m, void *v);
 
+static int show_numa_map_checked(struct seq_file *m, void *v)
+{
+   struct proc_maps_private *priv = m->private;
+   struct task_struct *task = priv->task;
+
+   if (maps_protect && !ptrace_may_attach(task))
+   return -EACCES;
+   
+   return show_numa_map(m, v);
+}
+
 static struct seq_operations proc_pid_numa_maps_op = {
 .start  = m_start,
 .next   = m_next,
 .stop   = m_stop,
-.show   = show_numa_map
+.show   = show_numa_map_checked
 };
 
 static int numa_maps_open(struct inode *inode, struct file *file)
diff --git a/fs/proc/task_nommu.c b/fs/proc/task_nommu.c
index fcc5caf..fb36c6a 100644
--- a/fs/proc/task_nommu.c
+++ b/fs/proc/task_nommu.c
@@ -143,6 +143,12 @@ out:
 static int show_map(struct seq_file *m, void *_vml)
 {
struct vm_list_struct *vml = _vml;
+   struct proc_maps_private *priv = m->private;
+   struct task_struct *task = priv->task;
+   
+   if (maps_protect && !ptrace_may_attach(task))
+   return -EACCES;
+
return nommu_vma_show(m, vml->vma);
 }
 
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 81480e6..743d63d 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -160,6 +160,7 @@ enum
KERN_MAX_LOCK_DEPTH=74,
KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered */
+   

Re: PROBLEM: "Make nenuconfig" does not save parameters.

[Jan Engelhardt]

On Mar 10 2007 20:50, Cyrill Gorcunov wrote:
>
>lets see to the following scenario:
>
>   1) I've taken a pure Linux kernel (no .config at all)
>   2) I started menuconfig, made a few changes and saved the file
>   to .config1 as alternate
>   3) Then I made some additional changes
>   4) Then I'm getting out of menuconfig and of course "Save
>   configuration..?" question is raising. Ok, I'm selecting
>   "Yes" and as result new configuration will be written to the .config
>   file. All works as it should be...
>   
>...but as you mentoined in your message "perhaps all Office Suites do
>the same" - no, Office do not the same.


1) I start a new document
2) add some text, "save as" it to config1.txt
3) make more text
4) choose File,Exit - prompts me to save

(perhaps not to .config, but instead config1.txt, but at least, it prompts
me, and gives me the choice to go back into menuconfig and save it under a
different name). So what I just wanted to make clear is that you don't
lose any changes without explicitly saying Don't Save.

>The only question I have (and it could resolve all our problems) - what an
>alternate config file is:
>
>   - just a snapshot of a config tree at moment of its writting
>   - _working_ file to which configurator should write parameters
>
>your comments?

Whether the 'working config file path' should change when you do
'Save as Alternate' or not, is a menuconfig axiom. Ask Sam Ravnborg
if you want it changed :-)

[ I see where you are going. I am not biased to either because I usually
  only use it to save to .config. ]



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

Re: 2.6.21-rc3-mm1 RSDL results

[Mark Lord]

Con Kolivas wrote:

On Saturday 10 March 2007 05:07, Mark Lord wrote:

Mmm.. when it's good, it's *really* good.
My desktop feels snappier and all of that.

..

But when it's bad, it stinks.
Like when a "make -j2" kernel rebuild is happening in a background window


And that's bad. When you say "it stinks" is it more than 3 times slower? It 
should be precisely 3 times slower under that load (although low cpu using 
things like audio wont be affected by running 3 times slower). If it feels 
like much more than that much slower, there is a bug there somewhere.


Scrolling windows is incredibly jerkey, and very very sluggish
when images are involved (eg. a large web page in firefox).

As another reader suggested, how does it run with the compile 'niced'? How does 
it perform with make (without a -j number).


Yes, it behaves itself when the "make -j2" is nice'd.


This is on a Pentium-M 760 single-core, w/2GB SDRAM (notebook).


What HZ are you running? Are you running a Beryl desktop?


HZ==1000, NO_HZ, Kubunutu Dapper Drake distro, ATI X300 open-source X.org 
driver.

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

RSDL v0.28 for 2.6.20 -> backport to 2.6.18.8

[Fortier,Vincent [Montreal]]

Hi all,

> 
> Here is an update for RSDL to version 0.28
> 
> Full patch:
> http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-
> rsdl-0.28.patch
> 
> Series:
> http://ck.kolivas.org/patches/staircase-deadline/2.6.20/
> 
> The patch to get you from 0.26 to 0.28:
> http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-
> rsdl-0.26-0.28.patch
> 
> A similar patch and directories will be made for 2.6.21-rc3 
> without further announcement
> 

First of all, thanx Con for this nice piece of code.

I've been trying in the last few days to backport this new scheduler to
a 2.6.18 kernel.  After a lot of efforts I have finally been able to
compile and run a RSDL patched 2.6.18.8 kernel on a x86_64 arch and
actually my test PC booted 2-3 seconds faster with it compared to a
vanilla 2.6.18.8 kernel.

This patch includes a few other patches from 2.6.19+ kernel:

PATCH 1:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co
mmit;h=ece8a684c75df215320b4155944979e3f78c5c93

PATCH 2:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co
mmit;h=08c183f31bdbb709f177f6d3110d5f288ea33933

PATCH 3:
The patch to get you from 0.26 to 0.28:
http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26-
0.28.patch

There might also be other small pieces of code comming from a 2.6.19+
kernel.

Due to the project I'm currently working on, this will, in the next few
weeks, help me out comparing heavy loads on a Debian Sarge/Etch 32/64
platform.  Suggestions on benchmark tools would greatly be appreciated.

Duno if this will be helpfull for anybody but I tought it would be nice
to give it back to the lkml community.

- vin


sched-rsdl-0.26-backport-kernel-2.6.18.patch.gz
Description: sched-rsdl-0.26-backport-kernel-2.6.18.patch.gz

Re: RSDL v0.28 for 2.6.20

[Stephen Clark]

Con Kolivas wrote:


Here is an update for RSDL to version 0.28

Full patch:
http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-rsdl-0.28.patch

Series:
http://ck.kolivas.org/patches/staircase-deadline/2.6.20/

The patch to get you from 0.26 to 0.28:
http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26-0.28.patch

A similar patch and directories will be made for 2.6.21-rc3 without further 
announcement


 


doesn't apply against 2.6.20.2:

patch -p1 <~/2.6.20-sched-rsdl-0.28.patch --dry-run
patching file include/linux/list.h
patching file fs/proc/array.c
patching file fs/pipe.c
patching file include/linux/sched.h
patching file include/asm-generic/bitops/sched.h
patching file include/asm-s390/bitops.h
patching file kernel/sched.c
Hunk #41 FAILED at 3531.
1 out of 62 hunks FAILED -- saving rejects to file kernel/sched.c.rej
patching file include/linux/init_task.h
patching file Documentation/sched-design.txt

Steve
--

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)


"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PROBLEM: "Make nenuconfig" does not save parameters.

[Cyrill Gorcunov]

[Jan Engelhardt - Sat, Mar 10, 2007 at 05:50:56PM +0100]
| On Mar 10 2007 19:46, Vladimir wrote:
| >> On Mar 10 2007 19:06, Cyrill Gorcunov wrote:
| >> >[Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300]
| >> >| Here's the problem:
| >> >|   1. Unpack the kernel sources, run make menuconfig.
| >> >|   2. Mark the necessary options.
| >> >|   3. Pick "Save an alternate configuration file", enter a filename 
(e.g. /root/kernelcfg)
| >> >|   4. Pick "Exit".
| >> >| ->5. Configurator exits without saving. If type "make bzImage", it 
builtd all the default
| >> >options.
| >> 
| >> Well, you already saved explicitly and did not make any further 
| >> changes after that, so it won't ask again on exit (perhaps all Office 
| >> Suites do the same). In fact, if you do exactly that, menuconfig 
| >> assumes you do not intend to build a kernel (since you did not save 
| >> to .config).
| >
| >Hm Do i have to "Save an alternate configuration file" to ".config" 
| >manually? The configurator used to do that automatically when i pick 
| >"Exit". I think that was reasonable. Anyway, the patch Cyrill sent me 
| >works all right.
| 
| If you make some changes and do not call 'save an alternate config 
| file', it will ask you on exit.
| 
| If you make no changes at all, a .config won't get written - true. But 
| then, the defconfig will be used anyway.
| 
| All is fine.
| 
| 
| Jan

Jan

lets see to the following scenario:

1) I've taken a pure Linux kernel (no .config at all)
2) I started menuconfig, made a few changes and saved the file
to .config1 as alternate
3) Then I made some additional changes
4) Then I'm getting out of menuconfig and of course "Save
configuration..?" question is raising. Ok, I'm selecting
"Yes" and as result new configuration will be written to the .config
file. All works as it should be...

...but as you mentoined in your message "perhaps all Office Suites do
the same" - no, Office do not the same. The only question I have
(and it could resolve all our problems) - what an alternate config
file is:

- just a snapshot of a config tree at moment of its writting
- _working_ file to which configurator should write parameters

your comments?

P.S.

Excuse for poor eng. grammar

Cyrill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/9] signalfd/timerfd v1 - signalfd core ...

[Davide Libenzi]

On Sat, 10 Mar 2007, Oleg Nesterov wrote:

> Davide Libenzi wrote:
> >
> > +int signalfd_deliver(struct sighand_struct *sighand, int sig,
> > +struct siginfo *info)
> > +{
> > +   int nsig = 0;
> > +   struct list_head *pos;
> > +   struct signalfd_ctx *ctx;
> > +
> > +   list_for_each(pos, >sfdlist) {
> > +   ctx = list_entry(pos, struct signalfd_ctx, lnk);
> 
> list_for_each_entry()

Will do, thx!



> > +   /*
> > +* We use a negative signal value as a way to broadcast that the
> > +* sighand has been orphaned, so that we can notify all the
> > +* listeners about this. Remeber the ctx->sigmask is inverted,
> > +* so if the user is interested in a signal, that corresponding
> > +* bit will be zero.
> > +*/
> > +   if (sig < 0 || !sigismember(>sigmask, sig)) {
> > +   __wake_up_locked(>wqh,
> > +TASK_UNINTERRUPTIBLE | 
> > TASK_INTERRUPTIBLE);
> 
> wake_up_locked(>wqh)

Yeah, will do.



> > +   ctx->sighand = current->sighand;
> > +   atomic_inc(>sighand->count);
> 
> I personally don't like this. de_thread() was/is the source of numerous
> problems, and this patch adds yet another subtle dependency. The usage of
> "private" __cleanup_sighand() is not good per se, imho.

This we agree ...



> Also, this is not so flexible, we can't take S_ISUID into account. It seems
> logical to preserve ctx after a "normal" exec.

This, not really. I'm not sure we want to leak this out of an exec.



> > +   spin_lock_irq(>sighand->siglock);
> > +   ctx->sigmask = sigmask;
> > +   spin_unlock_irq(>sighand->siglock);
> > +   wake_up(>wqh);
> 
> Race with signalfd_read()->__add_wait_queue().

Ack.



> > +   if (sighand != ctx->tsk->sighand || ctx->tsk->signal == NULL ||
> 
> We don't need "ctx->tsk->signal == NULL". tsk->signal == NULL (when checked
> under ->siglock) implies tsk->sighand == NULL. This is covered by the first
> "sighand != ctx->tsk->sighand"  check.

Extra check, due to rely less on the exit_signal code.


> > +   __remove_wait_queue(>wqh, );
> > +   set_current_state(TASK_RUNNING);
> 
> We don't need mb() here.

Ack.


> > +void signal_fill_info(struct siginfo *dinfo, int sig, struct siginfo 
> > *sinfo)
> > +{
> > +   switch ((unsigned long) sinfo) {
> > +   case (unsigned long) SEND_SIG_NOINFO:
> > +   dinfo->si_signo = sig;
> > +   dinfo->si_errno = 0;
> > +   dinfo->si_code = SI_USER;
> > +   dinfo->si_pid = current->pid;
> > +   dinfo->si_uid = current->uid;
> > +   break;
> > +   case (unsigned long) SEND_SIG_PRIV:
> > +   dinfo->si_signo = sig;
> > +   dinfo->si_errno = 0;
> > +   dinfo->si_code = SI_KERNEL;
> > +   dinfo->si_pid = 0;
> > +   dinfo->si_uid = 0;
> > +   break;
> > +   default:
> > +   copy_siginfo(dinfo, sinfo);
> > +   }
> > +}
> 
> This change seems unneeded?

Yes, it leaked out from the version of signalfd that had its own queue.


> I'd suggest to remove signalfd_ctx->sighand. de_thread()/exit_signal() call
> 
>   signalfd_exit_task(struct sighand_struct *sighand)
>   {
>   list_for_each_entry_safe(ctx, sighand->sfdlist)
>   if (ctx->tsk == current) {
>   wake_up_locked(ctx->wqh);
>   list_del_init(ctx->lnk);
>   }
>   }
> 
> signalfd_read()/signalfd_poll use
> 
>   static struct sighand_struct *ctx_try_to_lock(struct signalfd_ctx *ctx, 
> flags)
>   {
>   struct sighand_struct *ret;
> 
>   rcu_read_lock();
>   ret = lock_task_sighand(ctx->task);
>   rcu_read_unlock();
> 
>   if (ret && list_empty(ctx->lnk)) {
>   unlock_task_sighand(ctx->task);
>   ret = NULL;
>   }
> 
>   return ret;
>   }
> 
> instead of "spin_lock_irq(ctx->sighand)" + "if (ctx->sighand != 
> ctx->tsk->sighand)".
> 
> Possible?
> 
> Note that signalfd_exit_task() is generic, could be used in another context,
> de_thread() can avoid the call if !suid.

I think it looks good to me. Will give it a spin today.



> How about CONFIG_SIGNALFD, btw?

Yes, I was already planning it.


> Davide, could you please cc me? I am not subscribed to lkml, noticed the new
> version by accident.

Will do, thx!



- Davide


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

Re: irda rmmod lockdep trace.

[Samuel Ortiz]

Hi Dave,

On Thu, Mar 08, 2007 at 05:54:36PM -0500, Dave Jones wrote:
> modprobe irda ; rmmod irda in 2.6.21rc3 gets me the spew below..
Well it seems that we call __irias_delete_object() from hashbin_delete(). Then
__irias_delete_object() calls itself hashbin_delete() again. We're trying to
get the lock recursively.
I'll try to fix that soon, thanks for the report.

Cheers,
Samuel.


>   Dave
> 
> NET: Registered protocol family 23
> NET: Unregistered protocol family 23
> 
> =
> [ INFO: possible recursive locking detected ]
> 2.6.20-1.2966.fc7 #1
> -
> rmmod/16712 is trying to acquire lock:
>  (>hb_spinlock){}, at: [] 
> hashbin_delete+0x29/0x94 [irda]
> 
> but task is already holding lock:
>  (>hb_spinlock){}, at: [] 
> hashbin_delete+0x29/0x94 [irda]
> 
> other info that might help us debug this:
> 1 lock held by rmmod/16712:
>  #0:  (>hb_spinlock){}, at: [] 
> hashbin_delete+0x29/0x94 [irda]
> 
> stack backtrace:
> 
> Call Trace:
>  [] __lock_acquire+0x151/0xbc4
>  [] :irda:__irias_delete_attrib+0x0/0x31
>  [] lock_acquire+0x4c/0x65
>  [] :irda:hashbin_delete+0x29/0x94
>  [] _spin_lock_irqsave+0x2c/0x3c
>  [] :irda:hashbin_delete+0x29/0x94
>  [] :irda:__irias_delete_object+0x0/0x39
>  [] :irda:__irias_delete_object+0x25/0x39
>  [] :irda:hashbin_delete+0x40/0x94
>  [] :irda:iriap_cleanup+0x36/0x38
>  [] :irda:irda_cleanup+0x29/0x3a
>  [] sys_delete_module+0x199/0x1ca
>  [] syscall_trace_enter+0x9a/0x9f
>  [] tracesys+0xdc/0xe1
> 
> 
> -- 
> http://www.codemonkey.org.uk

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

Re: 2.6.21-rc3-mm1 RSDL results

[James Cloos]

> "Con" == Con Kolivas <[EMAIL PROTECTED]> writes:

Con> It's sad that sched_yield is still in our graphics card drivers ...

I just did a recursive grep(1) on my mirror of the freedesktop git
repos for sched_yield.  This only checked the master branches as I
did not bother to script up something to clone each, check out all
branches in turn, and grep(1) each possibility.

The output is just:

:; grep -r sched_yield FDO/xorg
FDO/xorg/xserver/hw/kdrive/via/viadraw.c:   sched_yield();
FDO/xorg/driver/xf86-video-glint/src/pm2_video.c:if (sync) /* sched_yield? 
*/

Is there something else I should grep(1) for?  If not, it looks as
if sched_yield(2) has been evicted from the drivers.

-JimC
-- 
James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

BUG: Killing and reviving files with USB disks

[Marti Raudsepp]

Hello LKML,

BUG: Killing and reviving files with USB disks

This is a reproducible demonstration of the problem initially reported in my
previous e-mail, titled "PROBLEM: 'bio too big device' after moving to a USB
disk" (http://lkml.org/lkml/2007/3/7/657)

Given that my previous e-mail appears to have been ignored in its entirety,
it's probably a good idea to send in this reproducible demonstration of the
problem, with a more dramatic headline.

Summary:
01. Create LVM volume; initialize dm-crypt; initialize reiserfs; mount
02. Populate the disk with files; sync; flush caches
03. Confirm that the files are still readable and non-corrupt (sha1sum)
04. Migrate logical volume to USB disk; sync; flush caches
05. Confirm that ALL PREVIOUSLY VERIFIED FILES ARE CORRUPT, spewing I/O errors
06. Observe "bio too big device dm-0 (256 > 240)" messages in dmesg
07. Run reiserfsck to check for corruptions -- none.
08. Migrate logical volume back to SATA disk; sync; flush caches
09. Confirm that files are readable and non-corrupt again
10. Clean up


Meet the characters:
* /dev/sda: The protagonist, my old SATA disk.
* /dev/sda5: the LVM partition on the old disk.
* /dev/sdb: The antagonist, my new offending USB disk; whole disk is used as
   an LVM physical volume.
* /dev/primary: LVM volume group 'primary' consisting of /dev/sdb and
   /dev/sda5
* /dev/primary/punchbag: LVM volume 'punchbag' for demonstration purposes.
* /dev/mapper/crypt-punchbag: The dm-crypt "decrypted" loopback device.


And their accessories:
* Linux non 2.6.19-gentoo-r6 #1 Wed Feb 28 20:55:24 EET 2007 x86_64 AMD
 Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
* USB disk 120GB Western Digital, model 00UE-00KVT0 (according to udev),
 serial DEF10CD7F64C
* Older SATA disk 200GB Seagate 7200.7, model ST3200822AS
* Motherboard Asus A8N5X, nForce4 chipset
* Offending file system: reiserfs v3.6, mounted with noatime,barrier=flush
* dm-crypt using aes-256 with cbc-essiv:sha256; using assembly-optimized AES
 on x86_64 (CONFIG_CRYPTO_AES_X86_64)
* Test partition is 68 extents times 16MiB = 1088 MiB large (that's the
 largest I could allocate while remaining in one segment -- otherwise lvmove
 wouldn't move the partition back to /dev/sda5 after "defragmenting" it.)
* LVM utilities version: 2.02.17 (2006-12-14)
* LVM library version: 1.02.12 (2006-10-13)
* LVM driver version: 4.10.0
* cryptsetup-luks 1.0.4 (user space interface to dm-crypt)


Let the play begin:
[non]# pvdisplay /dev/sda5
 --- Physical volume ---
 PV Name   /dev/sda5
 VG Name   primary
 PV Size   145.83 GB / not usable 2.73 MB
 Allocatable   yes
 PE Size (KByte)   16384
 Total PE  9333
 Free PE   117
 Allocated PE  9216
 PV UUID   YdrDuL-jw5z-J0SA-EEKU-NOC4-6gGR-T90YCA

[non]# pvdisplay /dev/sdb
 --- Physical volume ---
 PV Name   /dev/sdb
 VG Name   primary
 PV Size   111.79 GB / not usable 9.46 MB
 Allocatable   yes
 PE Size (KByte)   16384
 Total PE  7154
 Free PE   7129
 Allocated PE  25
 PV UUID   nE8C5L-lfI1-VNgs-Q7ei-1Zz3-GeGT-UNhH4p

[non]# lvcreate -n punchbag --extents 68 primary /dev/sda5
 Logical volume "punchbag" created
[non]# lvs --segments -o +devices
 LV   VG  Attr   #Str Type   SSize   Devices
 [...]
 punchbag primary -wi-a-1 linear   1.06G /dev/sda5(0)
 [...]
[non]# cryptsetup luksFormat /dev/primary/punchbag -c
aes-cbc-essiv:sha256 -h sha1
 [...]
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.
[non]# cryptsetup luksOpen /dev/primary/punchbag crypt-punchbag
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
[non]# mkfs.reiserfs /dev/mapper/crypt-punchbag
 [...]
Guessing about desired format.. Kernel 2.6.19-gentoo-r6 is running.
Format 3.6 with standard journal
Count of blocks on the device: 343920
Number of blocks consumed by mkreiserfs formatting process: 8222
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: c1857208-5090-49dd-9163-9fb002d96a88
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
ALL DATA WILL BE LOST ON '/dev/mapper/crypt-punchbag'!
Continue (y/n):y

Initializing journal - 0%20%40%60%80%100%
Syncing..ok
 [...]

ReiserFS is successfully created on /dev/mapper/crypt-punchbag.
[non]# mkdir /mnt/punchbag
[non]# mount /dev/mapper/crypt-punchbag /mnt/punchbag -o noatime,barrier=flush
[non]# cp -r ~marti/mp3 /mnt/punchbag
 [... yes, these are legal mp3s ;)]
cp: writing `/mnt/punchbag/mp3/...': No space left on device
^C
[non]# sync
[non]# echo 3 > /proc/sys/vm/drop_caches
[non]# cd /mnt/punchbag/mp3/mr\ Epic\ -\ Sideways
[non]# sha1sum -c *.sha1
mr Epic - Sideways - 01. Down Low.flac: OK
mr Epic - Sideways - 02. Blue Days.flac: OK
mr Epic - 

Re: [PATCH 1/1] hotplug cpu: migrate a task within its cpuset

[Ingo Molnar]

* Nathan Lynch <[EMAIL PROTECTED]> wrote:

> > > + /* try to stay on the same cpuset */
> > > + if (dest_cpu == NR_CPUS) {
> > > + p->cpus_allowed = cpuset_cpus_allowed(p);
> > > + dest_cpu = any_online_cpu(p->cpus_allowed);
> > > + }
> > 
> > what's the practical effect of this - when moving the last CPU offline 
> > from a node you got jobs migrated to really alien nodes? Thus i think we 
> > should queue this up for v2.6.21 too, correct? It's a NOP on systems 
> > that do not set up cpusets, so it's low-risk.
> 
> See my earlier reply to this patch.  Calling cpuset_cpus_allowed 
> (which takes a mutex) here is a bug, since move_task_off_dead_cpu must 
> be called with interrupts disabled.

ouch. i only checked the !CONFIG_CPUSET case :-/ It's a really bad idea 
to have any locking there indeed. The name itself suggests some atomic 
action.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Use more gcc extensions in the Linux headers

[Jan Engelhardt]

On Mar 10 2007 16:18, Andreas Schwab wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> writes:
>
>> So in case they _ARE_ compatible, we get the compile error, as far as I
>> can see it. There's a ! too much in the !!_builtin line.
>

>The error case is when the types are compatible.  That means that
>the argument is in fact _not_ an array.

That one should go in as a comment for that macro.



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

Re: [PATCH][RSDL-mm 0/6] Rotating Staircase DeadLine scheduler for -mm

[Nicolas Mailhot]

Le dimanche 11 mars 2007 à 01:03 +1100, Con Kolivas a écrit :
> On Saturday 10 March 2007 22:49, Nicolas Mailhot wrote:
> > Oops
> >
> > ⇒ http://bugzilla.kernel.org/show_bug.cgi?id=8166
> 
> Thanks very much. I can't get your config to boot on qemu, but could you 
> please try this debugging patch? It's not a patch you can really run the 
> machine with but might find where the problem occurs. Specifically I'm 
> looking for the warning MISSING STATIC BIT in your case. 
> 
> http://ck.kolivas.org/patches/crap/sched-rsdl-0.28-stuff.patch

I attached a screenshot of the patched kernel boot

-- 
Nicolas Mailhot


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: PROBLEM: "Make nenuconfig" does not save parameters.

[Jan Engelhardt]

On Mar 10 2007 19:46, Vladimir wrote:
>> On Mar 10 2007 19:06, Cyrill Gorcunov wrote:
>> >[Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300]
>> >| Here's the problem:
>> >|   1. Unpack the kernel sources, run make menuconfig.
>> >|   2. Mark the necessary options.
>> >|   3. Pick "Save an alternate configuration file", enter a filename (e.g. 
>> >/root/kernelcfg)
>> >|   4. Pick "Exit".
>> >| ->5. Configurator exits without saving. If type "make bzImage", it builtd 
>> >all the default
>> >options.
>> 
>> Well, you already saved explicitly and did not make any further 
>> changes after that, so it won't ask again on exit (perhaps all Office 
>> Suites do the same). In fact, if you do exactly that, menuconfig 
>> assumes you do not intend to build a kernel (since you did not save 
>> to .config).
>
>Hm Do i have to "Save an alternate configuration file" to ".config" 
>manually? The configurator used to do that automatically when i pick 
>"Exit". I think that was reasonable. Anyway, the patch Cyrill sent me 
>works all right.

If you make some changes and do not call 'save an alternate config 
file', it will ask you on exit.

If you make no changes at all, a .config won't get written - true. But 
then, the defconfig will be used anyway.

All is fine.


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

Re: PROBLEM: "Make nenuconfig" does not save parameters.

[Jan Engelhardt]

On Mar 10 2007 19:35, Cyrill Gorcunov wrote:
>[Jan Engelhardt - Sat, Mar 10, 2007 at 05:26:03PM +0100]
>| On Mar 10 2007 19:06, Cyrill Gorcunov wrote:
>| >[Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300]
>| >| Here's the problem:
>| >|   1. Unpack the kernel sources, run make menuconfig.
>| >|   2. Mark the necessary options.
>| >|   3. Pick "Save an alternate configuration file", enter a filename (e.g. 
>/root/kernelcfg)
>| >|   4. Pick "Exit".
>| >| ->5. Configurator exits without saving. If type "make bzImage", it builtd 
>all the default options.
>| 
>| Well, you already saved explicitly and did not make any further changes
>| after that, so it won't ask again on exit (perhaps all Office Suites do
>| the same). In fact, if you do exactly that, menuconfig assumes you do not
>| intend to build a kernel (since you did not save to .config).
>
>Hi, Jan
>
>so you think that is a normal behaviour? I mean sould we leave all as
>it is?

Yes. If you want to save your current configuration to two files, save it
twice:

  Save an alternate configuration file -> /root/kernelcfg
  Save an alternate configuration file -> 



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

Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler)

[Al Boldi]

William Lee Irwin III wrote:
> William Lee Irwin III wrote:
> >> A useful exercise may also be enumerating
> >> your expectations and having those who actually work with the code
> >> describe how well those are actually met.
>
> On Sat, Mar 10, 2007 at 08:34:25AM +0300, Al Boldi wrote:
> > A runtime configurable framework that allows for dynamically extensible
> > schedulers.  PlugSched seems to be a good start.
>
> Last I checked there were limits to runtime configurability centering
> around only supporting a compiled-in set of scheduling drivers, unless
> Peter's taken it the rest of the way without my noticing. It's unclear
> what you have in mind in terms of dynamic extensibility. My only guess
> would be pluggable scheduling policy/class support for individual
> schedulers in addition to plugging the individual schedulers, except
> I'm rather certain that Williams' code doesn't do anything with modules.

Correct, it doesn't, yet.  But do you think that PlugSched has the basic 
infrastructure in place to support this, or would it require a complete 
redesign/rewrite.


Thanks!

--
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PROBLEM: "Make nenuconfig" does not save parameters.

[Cyrill Gorcunov]

[Jan Engelhardt - Sat, Mar 10, 2007 at 05:26:03PM +0100]
| 
| On Mar 10 2007 19:06, Cyrill Gorcunov wrote:
| >[Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300]
| >| Here's the problem:
| >|   1. Unpack the kernel sources, run make menuconfig.
| >|   2. Mark the necessary options.
| >|   3. Pick "Save an alternate configuration file", enter a filename (e.g. 
/root/kernelcfg)
| >|   4. Pick "Exit".
| >| ->5. Configurator exits without saving. If type "make bzImage", it builtd 
all the default options.
| 
| Well, you already saved explicitly and did not make any further changes
| after that, so it won't ask again on exit (perhaps all Office Suites do
| the same). In fact, if you do exactly that, menuconfig assumes you do not
| intend to build a kernel (since you did not save to .config).
| 
| 
| Jan
| -- 
| 

Hi, Jan

so you think that is a normal behaviour? I mean sould we leave all as
it is?

Cyrill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: question about periodic clocks

[Jeremy Fitzhardinge]

Thomas Gleixner wrote:
> Uuurg. That's ugly. clockevents expect a per CPU timer especially for
> dynamic ticks. If you cannot provide a per cpu timer, then you probably
> need to use the broadcast trick.
>   

Ah, apologies, I'm wrong about this.  I misread the Xen code; the timers
are per-vcpu, but as an implementation detail within the hypervisor it
keeps track of which real cpu is managing that timer.  But logically the
timers are per-vcpu.

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

Re: [PATCH] Fix sparc TIF_USEDFPU flag atomicity

[Mathieu Desnoyers]

* William Lee Irwin III ([EMAIL PROTECTED]) wrote:
> On Sat, 10 Mar 2007 00:26:46 -0800, William Lee Irwin III <[EMAIL PROTECTED]> 
> wrote:
> >> Oh dear. Could we bit a bit more idiomatic here? For instance,
> >> something like:
> 
> On Sat, Mar 10, 2007 at 12:29:44AM -0800, David Miller wrote:
> > Ok I pulled the sparc32 patch back out until there is some
> > consensus here :)
> 
> It's just a minor touch-up. If Mathieu is okay with it, I'd rather
> leave him as the author and just send along an Acked-by: with it.
> I'm not terribly attached to it, either. I just choked on my soda
> when I saw set_ti_thread_flag(task_thread_info(fpt), TI_USEDFPU)
> etc. go by. (Which reminds me, I really need to figure out how to
> consolidate the UP and SMP cases for all this.)
> 
> 
> -- wli

Hello,

William's implementation is indeed neater than mine. So the consensus
goes to his patch as far as I'm concerned.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] 2.6.21-rc3-mm1

[Mariusz Kozlowski]

Hello,

> > Right. Can't be 100% sure but without the patch it would have probably
> > failed by now so I guess the patch is ok. Not sure how to make usb mouse
> > plugging/unplugging process automatic ;-)
> 
>   echo FOO >/sys/bus/usb/drivers/usbhid/unbind
> 
> to simulate an unplug (actually, to do an unbind), and
> 
>   echo FOO >/sys/bus/usb/drivers/usbhid/unbind
  ^^ bind I guess

> to do a bind, where FOO is the name of the USB mouse device link present
> in the /sys/bus/usb/drivers/usbhid directory.

# ls -al /sys/bus/usb/drivers/usbhid
total 0
drwxr-xr-x 2 root root0 Mar 10 17:30 .
drwxr-xr-x 8 root root0 Mar 10 17:14 ..
lrwxrwxrwx 1 root root0 Mar 10 17:30 2-2:1.0 -> 
../../../../devices/pci:00/:00:0c.0/usb2/2-2/2-2:1.0
--w--- 1 root root 4096 Mar 10 17:17 bind
lrwxrwxrwx 1 root root0 Mar 10 17:17 module -> ../../../../module/usbhid
--w--- 1 root root 4096 Mar 10 17:17 new_id
--w--- 1 root root0 Mar 10 17:22 unbind

# echo "2-2:1.0" > /sys/bus/usb/drivers/usbhid/unbind
bash: echo: write error: No such device

Any thoughts?

Regards,

Mariusz Kozlowski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PROBLEM: "Make nenuconfig" does not save parameters.

[Jan Engelhardt]

On Mar 10 2007 19:06, Cyrill Gorcunov wrote:
>[Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300]
>| Here's the problem:
>|   1. Unpack the kernel sources, run make menuconfig.
>|   2. Mark the necessary options.
>|   3. Pick "Save an alternate configuration file", enter a filename (e.g. 
>/root/kernelcfg)
>|   4. Pick "Exit".
>| ->5. Configurator exits without saving. If type "make bzImage", it builtd 
>all the default options.

Well, you already saved explicitly and did not make any further changes
after that, so it won't ask again on exit (perhaps all Office Suites do
the same). In fact, if you do exactly that, menuconfig assumes you do not
intend to build a kernel (since you did not save to .config).


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

Re: How soon is soon? MCP55 NCQ support on Linux...

[Robert Hancock]

Zoltan Boszormenyi wrote:

Hi,

I have seen your message in LKML archive:
http://marc.theaimsgroup.com/?l=linux-kernel=116046278930988=2
It's dated 2006.10.10 and states that a patch
to support NCQ on MCP55/MCP61 under Linux
is coming "soon". Now it's five months later
and I would like to ask when will it be supported?
Especially when this seems to be the last NVidia chipset
that has NCQ but isn't supported under Linux.

Thanks in advance,
Zoltán Böszörményi


It's a good question, I haven't heard anything about this either. Even 
documentation to allow others to implement it would be useful, although 
there may be some kind of IP issues that prevent public release of the 
specs, as I assume has prevented this with the nForce4 ADMA controllers.


I'm not sure what the story is with MCP51 either.. apparently the 
Windows driver NCQ support for that chipset was late in coming but I 
think it does have it now too..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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: question about periodic clocks

[Thomas Gleixner]

On Sat, 2007-03-10 at 07:50 -0800, Jeremy Fitzhardinge wrote:
> Thomas Gleixner wrote:
> > Good point. I never thought about that and we set the period in the
> > clock event device itself. You are right, the clockevents layer should
> > hand over the period either with the set_mode call or seperately.
> > Probably with the set_mode call, as it is needed exactly there and we
> > don't want to have a "if (dev->mode == XXX)" check in set_next_event().
> >
> > I look into this.
> >
> So, in the meantime, the period is 1/HZ?

Yep.

> I also have a question about clockevent cpumasks.  I was using the lapic
> clockevent as a model, but as I understand it there's a lapic per CPU,
> which explains why it registers a clockevent per cpu with that cpu alone
> in the cpumask.
> 
> The Xen timer is a bit different; I guess more like hpet.  There's a
> single (virtual-)machine-wide timer, which is "owned" by the last cpu
> with programmed it; ie, that cpu is the one which gets the resulting
> event interrupt.  Does this mean I should register a single clockevent
> device with a cpumask of CPU_MASK_ALL?  Or should I constrain it to a
> single cpu?

Uuurg. That's ugly. clockevents expect a per CPU timer especially for
dynamic ticks. If you cannot provide a per cpu timer, then you probably
need to use the broadcast trick.

Register a primary clocksource (as PIT/HPET) and register per CPU dummy
clocksources with CLOCK_EVT_FEAT_DUMMY set - we use the same trick, when
the lapic timer is broken. The clockevents code then uses PIT/HPET as
the primary tick source and broadcasts the periodic tick to the other
CPUs. In that case the dyntick / highres features are disabled.

We did some experiments to support multiple CPUs with one timer for
hres/dyntick but it does not scale and it is so ugly that it is not
worth the trouble. It works for the lapic stops in C3 case, as we have a
well defined point (right before going into the deep power state) where
we can rearm the global clock event device. As we are idle at that point
anyway there is not much penalty, but I really dont want to do that in
an active system.

> There's a comment in hpet.c saying
> 
>* Start hpet with the boot cpu mask and make it
>* global after the IO_APIC has been initialized.
> 
> but I don't see any place where the hpet cpumask is updated.

I wanted to do that in the first place, but never bothered. In an UP
environment it does not matter. On a sane SMP box (where we do not have
the local APIC stops in C3 problem) the HPET (analogous PIT) is switched
off for ever. In the case of LAPIC stops in C3 the HPET(PIT) is used as
a broadcast fallback. That means before we go into C3 we arm the
HPET/PIT for the earliest to expire lapic event of all CPUs. In that
case it does not matter, whether HPET/PIT is pinned to CPU#0 or anything
else.

tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PROBLEM: "Make nenuconfig" does not save parameters.

[Cyrill Gorcunov]

[Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300]
| Here's the problem:
|   1. Unpack the kernel sources, run make menuconfig.
|   2. Mark the necessary options.
|   3. Pick "Save an alternate configuration file", enter a filename (e.g. 
/root/kernelcfg)
|   4. Pick "Exit".
| ->5. Configurator exits without saving. If type "make bzImage", it builtd all 
the default options.
| 
| And there's no ".config" file in kernel root directory, so i have to move 
there my "kernelcfg" and
| rename it.
| 
| If i just run "make menuconfig", then pick "Exit", then it asks "Save kernel 
configuration?".
| 
| This happens starting from kernel 2.6.20 till 2.6.20.2
| Slackware-current.
| PC: Athlon-XP 2000+, 256 MB RAM.
| Linux wolf 2.6.20.2 #1 SMP PREEMPT Sat Mar 10 15:41:42 MSK 2007 i686 athlon-4 
i386 GNU/Linux
| -- 
| Faith manages.
| -
| 

Hi, Vladimir

here is the patch to resolve your problem. Test it and write me the
results...

Cyrill

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 664fe29..98836b6 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -432,8 +432,7 @@ int conf_write(const char *name)
 use_timestamp ? "# " : "",
 use_timestamp ? ctime() : "");
 
-   if (!conf_get_changed())
-   sym_clear_all_valid();
+   sym_clear_all_valid();
 
menu = rootmenu.list;
while (menu) {
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 3f9a132..ea32df8 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -840,8 +840,11 @@ static void conf_save(void)
case 0:
if (!dialog_input_result[0])
return;
-   if (!conf_write(dialog_input_result))
+   res = conf_get_changed(); /* temporary used */
+   if (!conf_write(dialog_input_result)) {
+   sym_set_change_count(res);
return;
+   }
show_textbox(NULL, _("Can't create file!  Probably a 
nonexistent directory."), 5, 60);
break;
case 1:

Re: 2.6.21-rc3-mm1

[Paul E. McKenney]

On Fri, Mar 09, 2007 at 06:18:51PM -0800, Andrew Morton wrote:
> > On Thu, 08 Mar 2007 21:50:29 +0100 Michal Piotrowski <[EMAIL PROTECTED]> 
> > wrote:
> > Andrew Morton napisał(a):
> > > Temporarily at
> > > 
> > >   http://userweb.kernel.org/~akpm/2.6.21-rc3-mm1/
> > > 
> > > Will appear later at
> > > 
> > >   
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm1/
> > > 
> > 
> > cpu_hotplug (AutoTest) hangs at this
> > 
> > =
> > [ INFO: possible recursive locking detected ]
> > 2.6.21-rc3-mm1 #2
> > -
> > sh/7213 is trying to acquire lock:
> >  (sched_hotcpu_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
> > 
> > but task is already holding lock:
> >  (sched_hotcpu_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
> > 
> > other info that might help us debug this:
> > 4 locks held by sh/7213:
> >  #0:  (cpu_add_remove_lock){--..}, at: [] mutex_lock+0x1c/0x1f
> >  #1:  (sched_hotcpu_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
> >  #2:  (cache_chain_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
> >  #3:  (workqueue_mutex){--..}, at: [] mutex_lock+0x1c/0x1f
> 
> That's pretty useless, isn't it?  We need to know the mutex_lock() caller
> here.
> 
> > stack backtrace
> >  [] show_trace_log_lvl+0x1a/0x2f
> >  [] show_trace+0x12/0x14
> >  [] dump_stack+0x16/0x18
> >  [] __lock_acquire+0x1aa/0xceb
> >  [] lock_acquire+0x79/0x93
> >  [] __mutex_lock_slowpath+0x107/0x349
> >  [] mutex_lock+0x1c/0x1f
> >  [] sched_getaffinity+0x14/0x91
> >  [] __synchronize_sched+0x11/0x5f
> >  [] detach_destroy_domains+0x2c/0x30
> >  [] update_sched_domains+0x27/0x3a
> >  [] notifier_call_chain+0x2b/0x4a
> >  [] __raw_notifier_call_chain+0x19/0x1e
> >  [] _cpu_down+0x70/0x282
> >  [] cpu_down+0x26/0x38
> >  [] store_online+0x27/0x5a
> >  [] sysdev_store+0x20/0x25
> >  [] sysfs_write_file+0xc1/0xe9
> >  [] vfs_write+0xd1/0x15a
> >  [] sys_write+0x3d/0x72
> >  [] syscall_call+0x7/0xb
> > 
> > l *0xc033883a
> > 0xc033883a is in mutex_lock (/mnt/md0/devel/linux-mm/kernel/mutex.c:92).
> > 87  /*
> > 88   * The locking fastpath is the 1->0 transition from
> > 89   * 'unlocked' into 'locked' state.
> > 90   */
> > 91  __mutex_fastpath_lock(>count, __mutex_lock_slowpath);
> > 92  }
> > 93
> > 94  EXPORT_SYMBOL(mutex_lock);
> > 95
> > 96  static void fastcall noinline __sched
> > 
> > I didn't test other -mm's with this test.
> > 
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc3-mm1/console.log
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc3-mm1/mm-config
> 
> I can't immediately spot the bug.  Probably it's caused by rcu-preempt's
> changes to synchronize_sched(): that function now does a heap more than it
> used to, including taking sched_hotcpu_muex.
> 
> So, what to do about this.  Paul, I'm thinking that I should drop
> rcu-preempt for now - I don't think we ended up being able to identify any
> particular benefit which it brings to current mainline, and I suspect that
> things will become simpler if/when we start using the process freezer for
> CPU hotplug.

It certainly makes sense for Michal to try backing out rcu-preempt using
your broken-out list of patches.  If that makes the problem go away,
then I would certainly have a hard time arguing with you.  We are working
on getting measurements showing benefit of rcu-preempt, but aren't there
yet.

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

Re: kref refcounting breakage in mainline

[Mike Galbraith]

P.S.  forgot to include diagnostic log.  Kobject c0644890 is the source
of my woes.  Printk's come below WARN_ON(is_ipmi_si_kobj).  Post-tinker
log is huge, and probably not interesting.

[   30.397160] kobject ipmi_devintf: registering. parent: , set: module
[   30.404033] kobject_uevent_env
[   30.407098] fill_kobj_path: path = '/module/ipmi_devintf'
[   30.412524] BUG: at lib/kobject.c:448 kobject_get()
[   30.417402]  [] show_trace_log_lvl+0x1a/0x30
[   30.422564]  [] show_trace+0x12/0x14
[   30.427031]  [] dump_stack+0x16/0x18
[   30.431501]  [] kobject_get+0x66/0x87
[   30.436056]  [] kobject_shadow_add+0x10/0x1e8
[   30.441312]  [] kobject_add+0xa/0xc
[   30.445695]  [] kernel_param_sysfs_setup+0x4d/0x7f
[   30.451376]  [] param_sysfs_init+0x188/0x1c3
[   30.456538]  [] init+0x144/0x26c
[   30.460661]  [] kernel_thread_helper+0x7/0x1c
[   30.465907]  ===
[   30.469486] get: c18f65c0 count after get is 2
[   30.473927] kobject ipmi_si: registering. parent: , set: module
[   30.480372] kobject_uevent_env
[   30.483430] fill_kobj_path: path = '/module/ipmi_si'


..


[   73.266556] bus platform: add driver ipmi
[   73.278013] kobject ipmi: registering. parent: , set: drivers
[   73.291847] kobject_uevent_env
[   73.302358] fill_kobj_path: path = '/bus/platform/drivers/ipmi'
[   73.315943] ipmi message handler version 39.1
[   73.327839] ipmi device interface
[   73.338524] device class 'ipmi': registering
[   73.350158] subsystem ipmi: registering
[   73.361309] kobject ipmi: registering. parent: , set: class
[   73.374841] bus platform: add driver ipmi_si
[   73.386442] BUG: at lib/kobject.c:448 kobject_get()
[   73.398617]  [] show_trace_log_lvl+0x1a/0x30
[   73.411079]  [] show_trace+0x12/0x14
[   73.422780]  [] dump_stack+0x16/0x18
[   73.434324]  [] kobject_get+0x66/0x87
[   73.445860]  [] kobject_shadow_add+0x10/0x1e8
[   73.458088]  [] kobject_add+0xa/0xc
[   73.469286]  [] kobject_register+0x22/0xb3
[   73.480986]  [] bus_add_driver+0x77/0x1ae
[   73.492592]  [] driver_register+0x54/0x84
[   73.504101]  [] init_ipmi_si+0x4d/0x829
[   73.515335]  [] init+0x144/0x26c
[   73.525822]  [] kernel_thread_helper+0x7/0x1c
[   73.537452]  ===
[   73.547290] get: c064475c count after get is 2
[   73.557969] kobject ipmi_si: registering. parent: , set: drivers
[   73.570825] kobject_uevent_env
[   73.580011] fill_kobj_path: path = '/bus/platform/drivers/ipmi_si'
[   73.592622] BUG: at lib/kobject.c:242 kobject_register()
[   73.604312]  [] show_trace_log_lvl+0x1a/0x30
[   73.615822]  [] show_trace+0x12/0x14
[   73.626551]  [] dump_stack+0x16/0x18
[   73.637211]  [] kobject_register+0x79/0xb3
[   73.648325]  [] bus_add_driver+0x77/0x1ae
[   73.659297]  [] driver_register+0x54/0x84
[   73.670164]  [] init_ipmi_si+0x4d/0x829
[   73.680756]  [] init+0x144/0x26c
[   73.690699]  [] kernel_thread_helper+0x7/0x1c
[   73.701854]  ===
[   73.711295] register: c064475c count now is 2 error 0
[   73.722218] BUG: at lib/kobject.c:448 kobject_get()
[   73.732911]  [] show_trace_log_lvl+0x1a/0x30
[   73.743927]  [] show_trace+0x12/0x14
[   73.754112]  [] dump_stack+0x16/0x18
[   73.764253]  [] kobject_get+0x66/0x87
[   73.774532]  [] get_driver+0x11/0x18
[   73.784725]  [] driver_create_file+0xf/0x32
[   73.795559]  [] bus_add_driver+0x15a/0x1ae
[   73.806343]  [] driver_register+0x54/0x84
[   73.817055]  [] init_ipmi_si+0x4d/0x829
[   73.827595]  [] init+0x144/0x26c
[   73.837468]  [] kernel_thread_helper+0x7/0x1c
[   73.848544]  ===
[   73.857932] get: c064475c count after get is 3
[   73.868223] BUG: at lib/kobject.c:494 kobject_put()
[   73.878943]  [] show_trace_log_lvl+0x1a/0x30
[   73.890019]  [] show_trace+0x12/0x14
[   73.900239]  [] dump_stack+0x16/0x18
[   73.910294]  [] kobject_put+0x69/0x82
[   73.920304]  [] put_driver+0xb/0xd
[   73.929909]  [] driver_create_file+0x2b/0x32
[   73.940362]  [] bus_add_driver+0x15a/0x1ae
[   73.950686]  [] driver_register+0x54/0x84
[   73.960966]  [] init_ipmi_si+0x4d/0x829
[   73.971055]  [] init+0x144/0x26c
[   73.980478]  [] kernel_thread_helper+0x7/0x1c
[   73.991119]  ===
[   74.50] put: c064475c count before put is 3
[   74.010026] BUG: at lib/kobject.c:448 kobject_get()
[   74.020367]  [] show_trace_log_lvl+0x1a/0x30
[   74.031011]  [] show_trace+0x12/0x14
[   74.040867]  [] dump_stack+0x16/0x18
[   74.050602]  [] kobject_get+0x66/0x87
[   74.060353]  [] get_driver+0x11/0x18
[   74.070034]  [] driver_create_file+0xf/0x32
[   74.080418]  [] bus_add_driver+0x16c/0x1ae
[   74.090742]  [] driver_register+0x54/0x84
[   74.100979]  [] init_ipmi_si+0x4d/0x829
[   74.111041]  [] init+0x144/0x26c
[   74.120431]  [] kernel_thread_helper+0x7/0x1c
[   74.131047]  ===
[   74.139949] get: c064475c count after get is 3
[   74.149807] BUG: at lib/kobject.c:494 kobject_put()
[   74.160111]  [] show_trace_log_lvl+0x1a/0x30
[   74.170739]  [] 

Re: [linux-usb-devel] 2.6.21-rc3-mm1

[Alan Stern]

On Sat, 10 Mar 2007, Mariusz Kozlowski wrote:

> Right. Can't be 100% sure but without the patch it would have probably
> failed by now so I guess the patch is ok. Not sure how to make usb mouse
> plugging/unplugging process automatic ;-)

echo FOO >/sys/bus/usb/drivers/usbhid/unbind

to simulate an unplug (actually, to do an unbind), and

echo FOO >/sys/bus/usb/drivers/usbhid/unbind

to do a bind, where FOO is the name of the USB mouse device link present
in the /sys/bus/usb/drivers/usbhid directory.

Alan Stern

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

pciehp: Cannot get control of hotplug hardware

[Ryan Hope]

Ever since I started playing with suspend I started turning on PCI Hot
Plug support since then I have been seeing messages like whats
below from dmesg I'm not exactly sure how this actually impacts me
if it does at all. I just thought it didn't look exactly right so I
wanted to inquire about it. Does anyone know what is going on here?

-Ryan

pci_hotplug: PCI Hot Plug PCI Core version: 0.5
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
decode_hpp: Could not get hotplug parameters. Use defaults
pciehp: HPC vendor_id 8086 device_id 27d0 ss_vid 0 ss_did 0
Evaluate _OSC Set fails. Status = 0x0005
Evaluate _OSC Set fails. Status = 0x0005
pciehp: Cannot get control of hotplug hardware for pci :00:1c.0
pciehp: HPC vendor_id 8086 device_id 27d2 ss_vid 0 ss_did 0
Evaluate _OSC Set fails. Status = 0x0005
Evaluate _OSC Set fails. Status = 0x0005
pciehp: Cannot get control of hotplug hardware for pci :00:1c.1
pciehp: HPC vendor_id 8086 device_id 27d4 ss_vid 0 ss_did 0
Evaluate _OSC Set fails. Status = 0x0005
Evaluate _OSC Set fails. Status = 0x0005
pciehp: Cannot get control of hotplug hardware for pci :00:1c.2
pciehp: HPC vendor_id 8086 device_id 27d6 ss_vid 0 ss_did 0
Evaluate _OSC Set fails. Status = 0x0005
Evaluate _OSC Set fails. Status = 0x0005
pciehp: Cannot get control of hotplug hardware for pci :00:1c.3
pciehp: HPC vendor_id 8086 device_id 27e0 ss_vid 0 ss_did 0
Evaluate _OSC Set fails. Status = 0x0005
Evaluate _OSC Set fails. Status = 0x0005
pciehp: Cannot get control of hotplug hardware for pci :00:1c.4
pciehp: HPC vendor_id 8086 device_id 27e2 ss_vid 0 ss_did 0
Evaluate _OSC Set fails. Status = 0x0005
Evaluate _OSC Set fails. Status = 0x0005
pciehp: Cannot get control of hotplug hardware for pci :00:1c.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] hotplug cpu: migrate a task within its cpuset

[Nathan Lynch]

Hi-

Ingo Molnar wrote:
> 
> * Cliff Wickman <[EMAIL PROTECTED]> wrote:
> 
> > With this patch, migrate the task to:
> >  1) to any cpu on the same node as the disabled cpu, which is both online
> > and among that task's cpus_allowed
> >  2) to any online cpu within the task's cpuset
> >  3) to any cpu which is both online and among that task's cpus_allowed
> > 
> > Diffed against 2.6.21-rc3 (Andrew's current top of tree)
> 
> looks good to me.
> 
> Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
> 
> > +   /* try to stay on the same cpuset */
> > +   if (dest_cpu == NR_CPUS) {
> > +   p->cpus_allowed = cpuset_cpus_allowed(p);
> > +   dest_cpu = any_online_cpu(p->cpus_allowed);
> > +   }
> 
> what's the practical effect of this - when moving the last CPU offline 
> from a node you got jobs migrated to really alien nodes? Thus i think we 
> should queue this up for v2.6.21 too, correct? It's a NOP on systems 
> that do not set up cpusets, so it's low-risk.

See my earlier reply to this patch.  Calling cpuset_cpus_allowed
(which takes a mutex) here is a bug, since move_task_off_dead_cpu must
be called with interrupts disabled.


> btw., unrelated to your patch, there's this bit right after the code 
> above:
> 
> /* No more Mr. Nice Guy. */
> if (dest_cpu == NR_CPUS) {
> rq = task_rq_lock(p, );
> cpus_setall(p->cpus_allowed);
> dest_cpu = any_online_cpu(p->cpus_allowed);
> 
> out of consistency, shouldnt the cpus_setall() rather be:
> 
>   p->cpus_allowed = cpu_possible_map;
> 
> ? It shouldnt make any real difference but it looks more consistent.

The default value of cpus_allowed is CPU_MASK_ALL, I thought -- at
least that's what we set init's to early on.  Though, as you say, it
shouldn't make any difference.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/9] signalfd/timerfd v1 - signalfd core ...

[Oleg Nesterov]

Davide Libenzi wrote:
>
> +int signalfd_deliver(struct sighand_struct *sighand, int sig,
> +  struct siginfo *info)
> +{
> + int nsig = 0;
> + struct list_head *pos;
> + struct signalfd_ctx *ctx;
> +
> + list_for_each(pos, >sfdlist) {
> + ctx = list_entry(pos, struct signalfd_ctx, lnk);

list_for_each_entry()

> + /*
> +  * We use a negative signal value as a way to broadcast that the
> +  * sighand has been orphaned, so that we can notify all the
> +  * listeners about this. Remeber the ctx->sigmask is inverted,
> +  * so if the user is interested in a signal, that corresponding
> +  * bit will be zero.
> +  */
> + if (sig < 0 || !sigismember(>sigmask, sig)) {
> + __wake_up_locked(>wqh,
> +  TASK_UNINTERRUPTIBLE | 
> TASK_INTERRUPTIBLE);

wake_up_locked(>wqh)

> +asmlinkage long sys_signalfd(int ufd, sigset_t __user *user_mask, size_t 
> sizemask)
> +{
> [...snip...]
> + if (ufd == -1) {
> + error = -ENOMEM;
> + ctx = kmem_cache_alloc(signalfd_ctx_cachep, GFP_KERNEL);
> + if (!ctx)
> + goto err_exit;
> +
> + init_waitqueue_head(>wqh);
> + ctx->sigmask = sigmask;
> + ctx->tsk = current;
> + get_task_struct(current);
> +
> + /*
> +  * We also increment the sighand count to make sure
> +  * it doesn't go away from us in poll() when the task
> +  * exits (which can happen if the fd is passed to
> +  * another process with unix domain sockets.
> +  *
> +  * This also guarantees that an execve() will reallocate
> +  * the signal state, and thus avoids security concerns
> +  * with a untrusted process that passes off the signal
> +  * queue fd to another, and then does a suid execve.
> +  */
> + ctx->sighand = current->sighand;
> + atomic_inc(>sighand->count);

I personally don't like this. de_thread() was/is the source of numerous
problems, and this patch adds yet another subtle dependency. The usage of
"private" __cleanup_sighand() is not good per se, imho.

Also, this is not so flexible, we can't take S_ISUID into account. It seems
logical to preserve ctx after a "normal" exec.

I think, we don't need signalfd_ctx->sighand at all, please see below.

> + } else {
> + error = -EBADF;
> + file = fget(ufd);
> + if (!file)
> + goto err_exit;
> + ctx = file->private_data;
> + error = -EINVAL;
> + if (file->f_op != _fops) {
> + fput(file);
> + goto err_exit;
> + }
> + spin_lock_irq(>sighand->siglock);
> + ctx->sigmask = sigmask;
> + spin_unlock_irq(>sighand->siglock);
> + wake_up(>wqh);

Race with signalfd_read()->__add_wait_queue().

> +static unsigned int signalfd_poll(struct file *file, poll_table *wait)
> +{
> + struct signalfd_ctx *ctx = file->private_data;
> + struct sighand_struct *sighand = ctx->sighand;
> + unsigned int events = 0;
> + unsigned long flags;
> +
> + poll_wait(file, >wqh, wait);
> +
> + spin_lock_irqsave(>siglock, flags);
> + /*
> +  * Let the caller get a POLLIN in this case, ala socket recv() when
> +  * the peer disconnect. The check for the changed sighand must be
> +  * done before calling next_signal(), since if sighand changed, a call
> +  * to next_signal() would crash. It'd be possible to avoid grabbing a
> +  * lock by incrementing the tsk->signal count like we do with the
> +  * tsk->sighand, but the code in __exit_signal() assumes that the
> +  * tsk->signal can be freed only there, and this would require
> +  * some code restructuring that I'm living out at this time.
> +  */
> + if (sighand != ctx->tsk->sighand || ctx->tsk->signal == NULL ||

We don't need "ctx->tsk->signal == NULL". tsk->signal == NULL (when checked
under ->siglock) implies tsk->sighand == NULL. This is covered by the first
"sighand != ctx->tsk->sighand"  check.

> +static ssize_t signalfd_read(struct file *file, char *buf, size_t count,
> +  loff_t *ppos)
> +{
> [...snip...]
> + for (;;) {
> + if (sighand != ctx->tsk->sighand) {
> + /*
> +  * Let the caller read zero byte, ala socket 
> recv()
> +  * when the peer disconnect. This test must be 
> done
> +  * before doing a dequeue_signal(), because if 
> the
> +  * task's sighand changed, a dequeue_signal() 
> is going
> +  * to 

Re: question about periodic clocks

[Jeremy Fitzhardinge]

Thomas Gleixner wrote:
> Good point. I never thought about that and we set the period in the
> clock event device itself. You are right, the clockevents layer should
> hand over the period either with the set_mode call or seperately.
> Probably with the set_mode call, as it is needed exactly there and we
> don't want to have a "if (dev->mode == XXX)" check in set_next_event().
>
> I look into this.
>
>   

So, in the meantime, the period is 1/HZ?

I also have a question about clockevent cpumasks.  I was using the lapic
clockevent as a model, but as I understand it there's a lapic per CPU,
which explains why it registers a clockevent per cpu with that cpu alone
in the cpumask.

The Xen timer is a bit different; I guess more like hpet.  There's a
single (virtual-)machine-wide timer, which is "owned" by the last cpu
with programmed it; ie, that cpu is the one which gets the resulting
event interrupt.  Does this mean I should register a single clockevent
device with a cpumask of CPU_MASK_ALL?  Or should I constrain it to a
single cpu?

There's a comment in hpet.c saying

 * Start hpet with the boot cpu mask and make it
 * global after the IO_APIC has been initialized.

but I don't see any place where the hpet cpumask is updated.

Thanks,
J

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

Re: kref refcounting breakage in mainline

[Mike Galbraith]

On Wed, 2007-03-07 at 06:39 +0100, Mike Galbraith wrote:
> On Tue, 2007-03-06 at 13:04 -0800, Greg KH wrote:
> > On Tue, Mar 06, 2007 at 06:43:22AM +0100, Mike Galbraith wrote:
> > > On Mon, 2007-03-05 at 16:25 -0800, Greg KH wrote:
> > > 
> > > > Mike, I've reverted this patch, and I don't see any references leaking.
> > > > And, as your patch released the reference on the driver, and the
> > > > module_add_driver() call would not grab a reference to the driver, only
> > > > the module kobject, I don't see what you were trying to fix with this
> > > > patch.
> > > > 
> > > > Do you have a test case that this fixes?
> > > 
> > > What it fixed for me was the hard hang reported below.
> > > 
> > > http://lkml.org/lkml/2007/2/16/96
> > 
> > What specific module are you trying to unload that causes the hang?  I
> > think it might just be a problem with that module, and not with all
> > others.
> 
> It's ipmi_si that's hanging, waits for completion that never comes.
> 
> > So, I'm going to revert your patch and work to try to find the real
> > cause of this problem.
> 
> Yeah, my stab at it seems busted.  I'll take another poke at it to see
> if I can find out why (post 725522b5453dd680412f2b6463a988e4fd148757)
> I'm left with a reference.

Ok, stab #2.

My reference count woes stem from module_remove_driver() not removing
the link created in module_add_driver().  With the below, my box boots
fine.  Since I obviously know spit about driver layer glue, I'll just
call this one a diagnostic, and head for the hills :)

--- linux-2.6.20-rc3/kernel/module.c.org2007-03-10 15:16:47.0 
+0100
+++ linux-2.6.20-rc3/kernel/module.c2007-03-10 15:43:09.0 +0100
@@ -2411,14 +2411,28 @@ void module_remove_driver(struct device_
return;
 
sysfs_remove_link(>kobj, "module");
-   if (drv->owner && drv->owner->mkobj.drivers_dir) {
-   driver_name = make_driver_name(drv);
-   if (driver_name) {
-   sysfs_remove_link(drv->owner->mkobj.drivers_dir,
+   driver_name = make_driver_name(drv);
+   if (!driver_name)
+   return;
+   if (drv->owner && drv->owner->mkobj.drivers_dir)
+   sysfs_remove_link(drv->owner->mkobj.drivers_dir,
  driver_name);
-   kfree(driver_name);
-   }
+   else if (drv->mod_name) {
+   struct module_kobject *mk;
+   struct kobject *mkobj;
+
+   /* Lookup built-in module entry in /sys/modules */
+   mkobj = kset_find_obj(_subsys.kset, drv->mod_name);
+   if (!mkobj)
+   goto out_free;
+   mk = container_of(mkobj, struct module_kobject, kobj);
+   module_create_drivers_dir(mk);
+   sysfs_remove_link(mk->drivers_dir, driver_name);
+   /* Release reference taken via lookup */
+   kobject_put(mkobj);
}
+out_free:
+   kfree(driver_name);
 }
 EXPORT_SYMBOL(module_remove_driver);
 #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: libata-acpi: allow _GTF on SATA, but disable on PATA for now

[Alan Cox]

> Alan has been actively working on PATA ACPI, and we have been debugging 
> ACPI issues as well.  PLEASE coordinate with the maintainer, when 
> touching code outside of drivers/acpi!

ap->cbl is not a reliable way to tell SATA from PATA at the moment. We
need to fix the real crashes too - right now no non PCI controller
actually works at all (crash on boot) because of the ACPI crap.

Please drop this patch as it will cause regressions on systems that do
not need the extra methods. Instead merge the one that fixe the non PCI
crashes and we might get further.

> AFAICS this patch went in with zero appearance on LKML or another 
> related list, until submission.  This is /not/ how we do Linux development.

Agreed.

NAK the patch likewise.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.21-rc3-mm1

[Mariusz Kozlowski]

Hello,

> On Sat, 10 Mar 2007, Greg KH wrote:
> 
> > > hid_parse_report() is doing kmalloc(128k kbytes).  We canot sanely 
> > > support that and the code shold be rewritten to not do that.  A simple 
> > > though somewhat lame fix would be to switch to vmalloc().
> > > It's been this way for some time, so it's odd that the failures have 
> > > just popped up now.
> > Jiri is the person to ask about this now.  Jiri, any thoughts about
> > this?
> 
> I have just queued the patch below to HID tree for the next upstream 
> merge. Mariusz, I guess it solves your issue, right?

Right. Can't be 100% sure but without the patch it would have probably
failed by now so I guess the patch is ok. Not sure how to make usb mouse
plugging/unplugging process automatic ;-)

Thanks,

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

Re: [git patches] libata (and devres) fixes

[Fabio Comolli]

Maybe KERN_DEBUG instead of KERN_ERR?


On 3/10/07, Alan Cox <[EMAIL PROTECTED]> wrote:

> scsi1 : ata_piix
> ata2: port disabled. ignoring.
> ata2: reset failed, giving up<--- THIS IS NEW.
>
> However, I think it's just bogus as there is ata2 is disabled on this laptop.

This is expected behaviour and it is what every controller except the
PIIX has done for some time. I'm not sure its perfect but we could return
0 from the -ENOENT case in ata_eh_reset() if that is preferred.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] 2.6.21-rc2: known regressions

[Ingo Molnar]

* Stefan Seyfried <[EMAIL PROTECTED]> wrote:

> > btw., the s2ram database seems quite a bit spotty:
> > 
> >  $ ./s2ram -n
> >  Machine is unknown.
> >  This machine can be identified by:
> >  sys_vendor   = "System manufacturer"
> >  sys_product  = "System Product Name"
> >  sys_version  = "System Version"
> >  bios_version = "ASUS A8N-E ACPI BIOS Revision 1008"
> > 
> >  $ ./s2ram -n
> >  Machine is unknown.
> >  This machine can be identified by:
> > sys_vendor   = "Hewlett-Packard "
> > sys_product  = "compaq nx9030 (PG630ET#ABD)   "
> > sys_version  = "Rev 1   "
> > bios_version = "F.15"
> >  See http://en.opensuse.org/S2ram for details.
> > 
> > even at the link above i didnt find any clear algorithm about how to 
> > extend the quirks-list and the white-list - while i expect that most 
> > people experience what i did: that s2ram doesnt know their boxes. 
> > (otherwise they would not visit that URL at all i suspect)
> 
> Ok. To be honest, you are the first reporter that seems to have read 
> the documentation above, but not understood what to do.

thanks for the compliment ;-) _I_ very much know what to do (i mailed 
the right person after all ;), but i dont really count and on the 6 
systems i tried s2ram said on 5 that it's 'unknown', i assumed it could 
possibly be due to the visible lack of clear instructions on that 
webpage ;-)

> i might consider reworking the documentation if there are more reports 
> about problems with the procedure.

Probably tweaking the webpage doesnt help because people dont get there 
- as the results plainly show it. Maybe some more automation would be 
useful too, a tool that detects failed resume and tries all those 
options that makes sense on that box or something? It's not like that 
people dont _try_ suspend/resume on Linux, it's just that they find it 
doesnt work and there is no clear mortal-usable (end-user-) way of 
fixing it and submitting the result of that fixing.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Use more gcc extensions in the Linux headers

[Andreas Schwab]

Jan Engelhardt <[EMAIL PROTECTED]> writes:

> So in case they _ARE_ compatible, we get the compile error, as far as I
> can see it. There's a ! too much in the !!_builtin line.

The error case is when the types are compatible.  That means that the
argument is in fact _not_ an array.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: _proxy_pda still makes linking modules fail

[Adrian Bunk]

On Thu, Mar 08, 2007 at 01:57:59AM +0100, Marcin 'Qrczak' Kowalczyk wrote:
> This is linux-2.6.20.1 with lots of patches from PLD Linux (I believe
> the patches don't affect the issue), compiled with gcc-4.1.2 and
> binutils-2.17.50.0.12 on x86.
>...

Please test a plain 2.6.20 from ftp.kernel.org.
If it fails, please send your .config .

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

imm module issues

[Grozdan Nikolov]

Hi,

I've compiled the 2.6.20.2 kernel today (I took the SuSE HEAD kernel instead 
of the vanilla one) and I'm having issues with the "imm" module. I still use 
a ZIP drive here for small backups and the "imm" module worked flawless on 
kernel 2.6.18.8 but with kernel 2.6.20.2 I get error messages that the device 
is offline even if the device is switched on and has a ZIP disk inside of it.

This is what I get from "dmesg" (Sorry for posting this here if it's the wrong 
place, but I wasn't sure if I should report this to Novell's bugzilla because 
I'm using the SuSE head kernel which is not officially supported)

imm: Version 2.05 (for Linux 2.4.0)
imm: Found device at ID 6, Attempting to use EPP 32 bit
imm: Communication established at 0x378 with ID 6 using EPP 32 bit
scsi1 : Iomega VPI2 (imm) interface
scsi 1:0:6:0: Direct-Access IOMEGA   ZIP 250  L.58 PQ: 0 ANSI: 2
sd 1:0:6:0: scsi: Device offlined - not ready after error recovery
sd 1:0:6:0: rejecting I/O to offline device
sd 1:0:6:0: rejecting I/O to offline device
sd 1:0:6:0: rejecting I/O to offline device
sd 1:0:6:0: rejecting I/O to offline device
sda : READ CAPACITY failed.
sda : status=0, message=00, host=1, driver=00
sda : sense not available.
sd 1:0:6:0: rejecting I/O to offline device
sda: Write Protect is off
sda: Mode Sense: 00 00 00 00
sd 1:0:6:0: rejecting I/O to offline device
sda: asking for cache data failed
sda: assuming drive cache: write through
sd 1:0:6:0: Attached scsi removable disk sda
sd 1:0:6:0: Attached scsi generic sg0 type 0
-- 
go openSUSE go!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PROBLEM: "Make nenuconfig" does not save parameters.

[Cyrill Gorcunov]

[Vladimir - Sat, Mar 10, 2007 at 04:05:42PM +0300]
| Here's the problem:
|   1. Unpack the kernel sources, run make menuconfig.
|   2. Mark the necessary options.
|   3. Pick "Save an alternate configuration file", enter a filename (e.g. 
/root/kernelcfg)
|   4. Pick "Exit".
| ->5. Configurator exits without saving. If type "make bzImage", it builtd all 
the default options.
| 
| And there's no ".config" file in kernel root directory, so i have to move 
there my "kernelcfg" and
| rename it.
| 
| If i just run "make menuconfig", then pick "Exit", then it asks "Save kernel 
configuration?".
| 
| This happens starting from kernel 2.6.20 till 2.6.20.2
| Slackware-current.
| PC: Athlon-XP 2000+, 256 MB RAM.
| Linux wolf 2.6.20.2 #1 SMP PREEMPT Sat Mar 10 15:41:42 MSK 2007 i686 athlon-4 
i386 GNU/Linux
| -- 
| Faith manages.

Let us time to review... :)

Cyrill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Use attribute groups in struct device_type

[Kay Sievers]

On 3/10/07, Greg KH <[EMAIL PROTECTED]> wrote:

On Sat, Mar 10, 2007 at 02:12:04AM -0500, Dmitry Torokhov wrote:
> On Saturday 10 March 2007 01:55, Greg KH wrote:
> > On Fri, Mar 09, 2007 at 10:54:43PM -0800, Greg KH wrote:
> > > On Sat, Mar 10, 2007 at 01:37:34AM -0500, Dmitry Torokhov wrote:
> > > > Greg,
> > > >
> > > > Please consider applying the patch below. It switches struct device_type
> > > > to using attribute groups which os more flexible. I am using it in my
> > > > input class_device -> device conversion (which is 99% done btw).
> > >
> > > Argh, I never sent you my version of that, did I?  Very sorry about
> > > that, I was working on fixing up the device namespace issue first, which
> > > isn't done yet :(
> > >
> > > Anyway, my patch that did that is below, feel free to use it or not if
> > > you want.
> > >
> > > > I looked through -mm and the latest git and there does not seem to be
> > > > any users of struct device_type yet...
> > >
> > > Yes, the input patch below uses it and I have a block-device patch from
> > > Kay in my tree that Andrew doesn't pull from (as it's usually really
> > > messed up and I know to hide this kind of breakage from him...)
> >
> > Oops, that patch didn't use it, this follow-on patch from Kay uses them.
>
> Ok, so input portion in your tree does not use type->attrs so we don't
> have a conflict here. Unless my patch messes up Kay's blockdev patch
> badly I'd like you to accept it. Input uses 3 attribute groups and I
> don't want to open-code their creation/removal.

I'll take your patch and see if it messes up Kay's.  If it does, I'm
sure he will fix it up for me later :)


Sure, no problem. I like Dmitry's change.

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

[BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory

[Chris Rankin]

Hi,

It looks like 2.6.20.2 is still doing Bad Things in /sys.

Cheers,
Chris

BUG: unable to handle kernel paging request at virtual address 6b6b6d6b
 printing eip:
c01300ff
*pde = 
Oops: 0002 [#1]
PREEMPT SMP
Modules linked in: radeon drm pwc eeprom cpufreq_ondemand p4_clockmod 
speedstep_lib nfsd exportfs
ipv6 autofs4 nfs lockd sunrpc af_packet firmware_class binfmt_misc video 
thermal processor fan
button ac lp parport_pc parport nvram video1394 raw1394 eth1394 snd_usb_audio 
compat_ioctl32
videodev v4l2_common snd_usb_lib v4l1_compat sd_mod sg snd_emu10k1_synth 
snd_emux_synth
snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec 
ac97_bus snd_seq_dummy
ohci1394 snd_seq_oss snd_seq_midi_event ieee1394 snd_seq ehci_hcd sata_sil 
snd_pcm_oss
snd_mixer_oss libata snd_pcm uhci_hcd e1000 serio_raw scsi_mod snd_seq_device 
snd_timer
snd_page_alloc snd_util_mem snd_hwdep pcspkr psmouse snd soundcore e7xxx_edac 
edac_mc ide_cd cdrom
i2c_i801 i2c_core intel_agp agpgart usbcore ext3 jbd
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202   (2.6.20.2 #1)
EIP is at module_put+0x20/0x52
eax: 6b6b6d6b   ebx: 6b6b6b6b   ecx: 0001   edx: e7a01000
esi: edb7e4e4   edi: 6b6b6b6b   ebp: e79fd50c   esp: e7a01f58
ds: 007b   es: 007b   ss: 0068
Process udevd (pid: 9656, ti=e7a01000 task=f7a46030 task.ti=e7a01000)
Stack: eba628a0 c0183a1e 0010 ed570870 e7a641d0 c0151263  
   f7ff2208 ed570870 f745b678  ed570870 c014eda0 0003 0003
   f745b678 f745b6f8 c014fd99 0003 0007 0003 e7a01000 c0102bde
Call Trace:
 [] sysfs_release+0x2d/0x4c
 [] __fput+0x96/0x13c
 [] filp_close+0x51/0x58
 [] sys_close+0x70/0xa7
 [] sysenter_past_esp+0x5f/0x85
 [] __sched_text_start+0x613/0x971
 ===
Code: 00 89 f0 83 c4 0c 5b 5e 5f 5d c3 53 89 c3 85 c0 74 49 b8 01 00 00 00 e8 
77 49 fe ff e8 0f 5b
07 00 c1 e0 07 8d 84 18 80 01 00 00  08 83 3b 02 75 0b 8b 83 88 05 00 00 e8 
c1 45 fe ff b8 01
00
EIP: [] module_put+0x20/0x52 SS:ESP 0068:e7a01f58
 <6>note: udevd[9656] exited with preempt_count 1
BUG: scheduling while atomic: udevd/0x1001/9656
 [] __sched_text_start+0x56/0x971
 [] vsnprintf+0x44e/0x48c
 [] atomic_notifier_call_chain+0x40/0x46
 [] nmi_watchdog_tick+0x5e/0x1ee
 [] __wake_up_locked+0x1f/0x21
 [] __cond_resched+0x12/0x2c
 [] cond_resched+0x26/0x31
 [] unmap_vmas+0x3d3/0x4df
 [] exit_mmap+0x7e/0x10a
 [] mmput+0x1d/0x78
 [] do_exit+0x1b2/0x6d8
 [] sys_vm86+0x95/0x21d
 [] die+0x1f2/0x217
 [] do_page_fault+0x442/0x510
 [] do_page_fault+0x0/0x510
 [] error_code+0x7c/0x84
 [] module_put+0x20/0x52
 [] sysfs_release+0x2d/0x4c
 [] __fput+0x96/0x13c
 [] filp_close+0x51/0x58
 [] sys_close+0x70/0xa7
 [] sysenter_past_esp+0x5f/0x85
 [] __sched_text_start+0x613/0x971
 ===



___ 
What kind of emailer are you? Find out today - get a free analysis of your 
email personality. Take the quiz at the Yahoo! Mail Championship. 
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: netconsole system freeze when cable unplugged

[Simon Arlott]

On 10/03/07 13:38, Andi Kleen wrote:

Simon Arlott <[EMAIL PROTECTED]> writes:


On 09/03/07 20:42, Francois Romieu wrote:

Simon Arlott <[EMAIL PROTECTED]> :

When I unplug the cable the system just stops responding to
anything, at all. No message is printed to the console when the
cable is plugged back in.

rtl8139_interrupt (spin_lock(>lock))
-> rtl8139_weird_interrupt
   -> rtl_check_media
  -> mii_check_media (printk(KERN_INFO "%s: link down\n", ...))
 [netpoll stuff here]
 -> rtl8139_poll_controller
-> rtl8139_interrupt
   *deadlock*
See below for my random stuff of the day. Feel free to open a PR at
bugzilla.kernel.org if the issue does not go away.

The patch doesn't fix it, nothing changes. I'm not sure how this can
be debugged if printk won't work...


earlyprintk can be called directly (early_printk()) and should
work. It won't log over the network of course.


It also won't log over the serial console either :(
(but that's probably a good thing, it's slow enough to boot with tons 
of messages to the display because of netconsole and nfs).


rtl8139_interrupt
-> spin_lock(>lock)
-> rtl8139_weird_interrupt
  -> rtl_check_media
 -> mii_check_media
-> printk(KERN_INFO "%s: link down\n", ...)
   -> wite_msg
  -> local_irq_save
  -> netpoll_send_udp
 -> netpoll_send_skb
-> local_irq_save
-> dev->hard_start_xmit(..., ...)
rtl8139_start_xmit
-> spin_lock_irqsave
  *deadlock*

--
Simon Arlott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Use more gcc extensions in the Linux headers

[Jan Engelhardt]

On Mar 10 2007 16:19, Nigel Cunningham wrote:
>On Fri, 2007-03-09 at 23:03 -0500, [EMAIL PROTECTED] wrote:
>> On Sat, 10 Mar 2007 09:57:32 +1100, Rusty Russell said:
>> 
>> > +/* GCC is awesome. */
>> >  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0])   
>> >   \
>> >+ sizeof(typeof(int[1 - 2*!!__builtin_types_compatible_p(typeof(arr), \
>> > typeof([0]))]))*0)
>> 
>> -/* GCC is awesome. */
>> +/* GCC leaves me speechless. */
>
>A speechless Rusty would be horrible. That said, it would be nice if the
>comment was something more like the normal Rusty pearl of wisdom. I
>understand the first part, but have no idea was + sizeof(typeof(int[
>does...

IOCCC entry candidate.

Simple. !!__builtin_types_compatible_p, as it sounds, will return 1 if
both types are compatible. If they are, then '1-2*!!_builtin..' will
produce -1, then - surprisingly - sizeof(typeof(int[-1])) seems strange to
me and should throw the error.

If the types are not compatible, compat_p returns 0. !! will turn it into
0. 2* will turn it into 0. 1-0 is 1. sizeof(typeof(int[1])) is valid, and
*0 will compile it away.

So in case they _ARE_ compatible, we get the compile error, as far as I
can see it. There's a ! too much in the !!_builtin line. Now we know why
such patches are dangerous.

What's more, a test program does not even fail when the types are
incompatible. (Or it's also wrong):

#include 
struct foo {
int x, y, z;
};
struct bar {
const char *fol;
};
#define c(x, y)  \
sizeof(typeof(int[1 - \
 2*!!__builtin_types_compatible_p(typeof(x), typeof(y))]))
int main(void)
{
printf("%d\n", c(struct foo *, struct bar *));
printf("%d\n", c(int*, int*));
}

Both printf()s throw a compile time error.


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

Re: Where is Linux 2.6.20.2?

[Jan Engelhardt]

On Mar 10 2007 21:52, Tetsuo Handa wrote:

>Date: Sat, 10 Mar 2007 21:52:23 +0900
>From: Tetsuo Handa <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED], linux-kernel@vger.kernel.org
>Subject: Re: Where is Linux 2.6.20.2?
>
>Cong WANG wrote:
>> http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.2.tar.bz2
>> isn't it what you want?
>It's currently 404 (Not Found) error.
>
>http://www2.kernel.org/ page is still showing 2.6.20.1
>although it once showed 2.6.20.2 .

15:02 ichi:/dev/shm > l /lnk/lk/linux-2.6.20.2.tar.
linux-2.6.20.2.tar.bz2   linux-2.6.20.2.tar.gz.sign
linux-2.6.20.2.tar.bz2.sign  linux-2.6.20.2.tar.sign
linux-2.6.20.2.tar.gz
15:02 ichi:/dev/shm > l /lnk/lk/linux-2.6.20.2.tar.bz2
-rw-r--r-- 1 455 5200 43378711 Mar  9 20:08 /lnk/lk/linux-2.6.20.2.tar.bz2
15:02 ichi:/dev/shm > df -T `readlink -f /lnk/lk`
FilesystemType   1K-blocks  Used Available Use% Mounted on
134.76.10.1:/ftp/pub
   nfs   5044816000 3911586640 1048766112  79% /F

It is synced out to the world already.


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

Re: [2/6] 2.6.21-rc2: known regressions

[Johannes Stezenbach]

On Sat, Mar 10, 2007 at 12:43:01PM +0100, Stefan Seyfried wrote:
> On Sat, Mar 10, 2007 at 10:01:21AM +0100, Ingo Molnar wrote:
> > 
> > i'm wondering, do you have any idea how Windows handles the 
> > suspend/resume quirks problem area? Do they "curse BIOS vendors and 
> > maintain a large DB of DMI-driven exceptions", or do they perhaps have 
> > some fundamentally better approach than us? If it's the former, then we 
> > might as well try to bring more automatism (and more of your database) 
> > into the kernel itself.
> 
> I think that in windows, you simply install the "HP nx$FOOBAR intel graphics
> driver" on a nx$FOOBAR machine, and the "ASUS $FOOBAR ATI graphics driver"
> on an ASUS $FOOBAR machine etc. Those drivers are mostly stock intel/ATI/
> whoever drivers, but with the little bit of extra knowledge on how to wake
> up the graphics chip.

That's also what the thinkwiki page suggests. It says:

"Affected Operating Systems:
  * Linux, all flavours.
  * Windows, for some models as well (only when using non-IBM drivers).
  * FreeBSD (on the A22M)"


Johannes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][RSDL-mm 0/6] Rotating Staircase DeadLine scheduler for -mm

[Con Kolivas]

On Saturday 10 March 2007 22:49, Nicolas Mailhot wrote:
> Oops
>
> ⇒ http://bugzilla.kernel.org/show_bug.cgi?id=8166

Thanks very much. I can't get your config to boot on qemu, but could you 
please try this debugging patch? It's not a patch you can really run the 
machine with but might find where the problem occurs. Specifically I'm 
looking for the warning MISSING STATIC BIT in your case. 

http://ck.kolivas.org/patches/crap/sched-rsdl-0.28-stuff.patch

Thanks!

-- 
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.21-rc3-mm1

[Mariusz Kozlowski]

Hello,

iMac G3 build fails:
  
CC  drivers/macintosh/adbhid.o
drivers/macintosh/adbhid.c: In function 'adbhid_init':
drivers/macintosh/adbhid.c:1275: error: too many arguments to function 
'register_sysctl_table'
make[2]: *** [drivers/macintosh/adbhid.o] Blad 1
make[1]: *** [drivers/macintosh] Blad 2
make: *** [drivers] Blad 2

processor   : 0
cpu : 740/750
temperature : 43-45 C (uncalibrated)
clock   : 400MHz
revision: 2.2 (pvr 0008 0202)
bogomips: 796.67
machine : PowerMac2,1
motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh
detected as : 66 (iMac FireWire)
pmac flags  : 0005
L2 cache: 512K unified
memory  : 256MB
pmac-generation : NewWorld

Gnu C  4.1.2
Gnu make   3.81
binutils   2.17
util-linux 2.12r
mount  2.12r
module-init-tools  3.3-pre2
e2fsprogs  1.40-WIP
Linux C Library2.3.6
Dynamic linker (ldd)   2.3.6
Procps 3.2.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.97
Modules Loaded ipv6 af_packet tsdev eth1394 tulip crc32 ohci1394 
ieee1394 uninorth_agp agpgart dm_snapshot dm_mirror dm_mod snd_powermac 
snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss snd_seq_oss snd_seq_device 
snd_seq_midi_event snd_seq snd_timer snd soundcore ide_cd cdrom joydev evdev 
ext3 jbd mbcache usbhid uhci_hcd ohci_hcd usbcore ide_disk unix

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc3-mm1
# Sat Mar 10 13:01:06 2007
#
# CONFIG_PPC64 is not set
CONFIG_PPC32=y
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set

#
# Processor support
#
CONFIG_CLASSIC32=y
# CONFIG_PPC_82xx is not set
# CONFIG_PPC_83xx is not set
# CONFIG_PPC_85xx is not set
# CONFIG_PPC_86xx is not set
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_6xx=y
CONFIG_PPC_FPU=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
# CONFIG_SMP is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SWAP_PREFETCH=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
# CONFIG_IKCONFIG is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_CLASSIC_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_TRACE=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
CONFIG_PAGE_GROUP_BY_MOBILITY=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Process debugging support
#
CONFIG_UTRACE=y
CONFIG_PTRACE=y

#
# Block layer
#
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_EMBEDDED6xx is not set
# CONFIG_APUS is not set
CONFIG_PPC_CHRP=y
# CONFIG_PPC_MPC52xx is not set
# CONFIG_PPC_MPC5200 is not set
# CONFIG_PPC_EFIKA is not set
# CONFIG_PPC_LITE5200 is not set
CONFIG_PPC_PMAC=y
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
CONFIG_PPC_NATIVE=y
# CONFIG_UDBG_RTAS_CONSOLE is not set
CONFIG_PPC_RTAS=y
# CONFIG_RTAS_ERROR_LOGGING is not set
CONFIG_RTAS_PROC=y
# CONFIG_MMIO_NVRAM is not set
CONFIG_PPC_MPC106=y

[PATCH v2] Bitbanging i2c bus driver using the GPIO API

[Haavard Skinnemoen]

This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing purposes.

To use, include something similar to the following in the
board-specific setup code:

  #include 

  static struct i2c_gpio_platform_data i2c_gpio_data = {
.sda_pin= GPIO_PIN_FOO,
.scl_pin= GPIO_PIN_BAR,
  };
  static struct platform_device i2c_gpio_device = {
.name   = "i2c-gpio",
.id = 0,
.dev= {
.platform_data  = _gpio_data,
},
  };

Register this platform_device, set up the i2c pins as GPIO if
required and you're ready to go.

Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
---
This patch is different from the first patch in the following ways:
  * Handles pins set up as open drain (aka multidrive) by toggling
the output value instead of the direction
  * Handles output-only SCL pins the same way, and also does not
install a getscl() callback for such pins
  * Does not add anything to include/linux/i2c-ids.h
  * Sets the output value explicitly after changing the direction to
output.
  * Plugs a memory leak in remove() -- algo_data wasn't freed.
  * Prints out the pin IDs in decimal, with an extra note when clock
stretching isn't supported

This version has been compile-tested only. I'll give it a spin when I
get back to work on monday.

Dave, does this address your concerns?

Haavard   

 drivers/i2c/busses/Kconfig|8 ++
 drivers/i2c/busses/Makefile   |1 +
 drivers/i2c/busses/i2c-gpio.c |  211 +
 include/linux/i2c-gpio.h  |   30 ++
 4 files changed, 250 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fb19dbb..52f79d1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -102,6 +102,14 @@ config I2C_ELEKTOR
  This support is also available as a module.  If so, the module 
  will be called i2c-elektor.
 
+config I2C_GPIO
+   tristate "GPIO-based bitbanging i2c driver"
+   depends on I2C && GENERIC_GPIO
+   select I2C_ALGOBIT
+   help
+ This is a very simple bitbanging i2c driver utilizing the
+ arch-neutral GPIO API to control the SCL and SDA lines.
+
 config I2C_HYDRA
tristate "CHRP Apple Hydra Mac I/O I2C interface"
depends on I2C && PCI && PPC_CHRP && EXPERIMENTAL
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 290b540..68f2b05 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
 obj-$(CONFIG_I2C_AT91) += i2c-at91.o
 obj-$(CONFIG_I2C_AU1550)   += i2c-au1550.o
 obj-$(CONFIG_I2C_ELEKTOR)  += i2c-elektor.o
+obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
 obj-$(CONFIG_I2C_HYDRA)+= i2c-hydra.o
 obj-$(CONFIG_I2C_I801) += i2c-i801.o
 obj-$(CONFIG_I2C_I810) += i2c-i810.o
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
new file mode 100644
index 000..423db0a
--- /dev/null
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -0,0 +1,211 @@
+/*
+ * Bitbanging i2c bus driver using the GPIO API
+ *
+ * Copyright (C) 2006 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Toggle SDA by changing the direction of the pin */
+static void i2c_gpio_setsda_dir(void *data, int state)
+{
+   struct i2c_gpio_platform_data *pdata = data;
+
+   if (state)
+   gpio_direction_input(pdata->sda_pin);
+   else {
+   gpio_direction_output(pdata->sda_pin);
+   gpio_set_value(pdata->sda_pin, 0);
+   }
+}
+
+/*
+ * Toggle SDA by changing the output value of the pin. This is only
+ * valid for pins configured as open drain (i.e. setting the value
+ * high effectively turns off the output driver.)
+ */
+static void i2c_gpio_setsda_val(void *data, int state)
+{
+   struct i2c_gpio_platform_data *pdata = data;
+
+   gpio_set_value(pdata->sda_pin, state);
+}
+
+/* Toggle SCL by changing the direction of the pin. */
+static void i2c_gpio_setscl_dir(void *data, int state)
+{
+   struct i2c_gpio_platform_data *pdata = data;
+
+   if (state)
+   gpio_direction_input(pdata->scl_pin);
+   else {
+   gpio_direction_output(pdata->scl_pin);
+   gpio_set_value(pdata->scl_pin, 0);
+   }
+}
+
+/*
+ * Toggle SCL by changing the output value of the pin. This is used
+ * for pins that are configured as open drain and for output-only
+ * pins. The latter case will break the i2c protocol, but it will

PROBLEM: "Make nenuconfig" does not save parameters.

[Vladimir]

Here's the problem:
  1. Unpack the kernel sources, run make menuconfig.
  2. Mark the necessary options.
  3. Pick "Save an alternate configuration file", enter a filename (e.g. 
/root/kernelcfg)
  4. Pick "Exit".
->5. Configurator exits without saving. If type "make bzImage", it builtd all 
the default options.

And there's no ".config" file in kernel root directory, so i have to move there 
my "kernelcfg" and
rename it.

If i just run "make menuconfig", then pick "Exit", then it asks "Save kernel 
configuration?".

This happens starting from kernel 2.6.20 till 2.6.20.2
Slackware-current.
PC: Athlon-XP 2000+, 256 MB RAM.
Linux wolf 2.6.20.2 #1 SMP PREEMPT Sat Mar 10 15:41:42 MSK 2007 i686 athlon-4 
i386 GNU/Linux
-- 
Faith manages.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 8/9] Driver core: fix error by cleanup up symlinks properly

[Dmitriy Monakhov]

Greg Kroah-Hartman <[EMAIL PROTECTED]> writes:

> From: James Simmons <[EMAIL PROTECTED]>
>
> When a device fails to register the class symlinks where not cleaned up.
> This left a symlink in the /sys/class/"device"/ directory that pointed
> to no where. This caused the sysfs_follow_link Oops I reported earlier.
> This patch cleanups up the symlink. Please apply. Thank you.
>
> Signed-Off: James Simmons <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> ---
>  drivers/base/core.c |   31 ++-
>  1 files changed, 30 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index d04fd33..cf2a398 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -637,12 +637,41 @@ int device_add(struct device *dev)
>BUS_NOTIFY_DEL_DEVICE, dev);
>   device_remove_groups(dev);
>   GroupError:
> - device_remove_attrs(dev);
> + device_remove_attrs(dev);
>   AttrsError:
>   if (dev->devt_attr) {
>   device_remove_file(dev, dev->devt_attr);
>   kfree(dev->devt_attr);
>   }
> +
> + if (dev->class) {
> + sysfs_remove_link(>kobj, "subsystem");
> + /* If this is not a "fake" compatible device, remove the
> +  * symlink from the class to the device. */
> + if (dev->kobj.parent != >class->subsys.kset.kobj)
> + sysfs_remove_link(>class->subsys.kset.kobj,
> +   dev->bus_id);
> +#ifdef CONFIG_SYSFS_DEPRECATED
> + if (parent) {
> + char *class_name = make_class_name(dev->class->name,
> +>kobj);
> + if (class_name)
> + sysfs_remove_link(>parent->kobj,
> +   class_name);
> + kfree(class_name);
> + sysfs_remove_link(>kobj, "device");
> + }
> +#endif
> +
< block begin
> + down(>class->sem);
> + /* notify any interfaces that the device is now gone */
> + list_for_each_entry(class_intf, >class->interfaces, node)
> + if (class_intf->remove_dev)
> + class_intf->remove_dev(dev, class_intf);
> + /* remove the device from the class list */
> + list_del_init(>node);
> + up(>class->sem);
<< block end 
May be i've missed something, but i'm confuesd a litle bit.
For example if error happens while device_pm_add() we jump to label "PMError"
and code from block above will be executed (device will be remove from list),
but this device wasn't added to this list yet!
> + }
>   ueventattrError:
>   device_remove_file(dev, >uevent_attr);
>   attrError:
> -- 
> 1.5.0.1
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Where is Linux 2.6.20.2?

[Tetsuo Handa]

Cong WANG wrote:
> http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.2.tar.bz2
> isn't it what you want?
It's currently 404 (Not Found) error.

http://www2.kernel.org/ page is still showing 2.6.20.1
although it once showed 2.6.20.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.21-rc3-mm1

[Jiri Kosina]

On Sat, 10 Mar 2007, Greg KH wrote:

> > hid_parse_report() is doing kmalloc(128k kbytes).  We canot sanely 
> > support that and the code shold be rewritten to not do that.  A simple 
> > though somewhat lame fix would be to switch to vmalloc().
> > It's been this way for some time, so it's odd that the failures have 
> > just popped up now.
> Jiri is the person to ask about this now.  Jiri, any thoughts about
> this?

Hi,

I have just queued the patch below to HID tree for the next upstream 
merge. Mariusz, I guess it solves your issue, right?

I have already been talking with Vojtech some time ago that rewritting the 
hid parser so that it would use less memory (but probably slightly a bit 
more CPU) would be a good thing to do, and it's been sitting in my TODO 
list for quite some time already. It's really not a straightforward 
rewrite, so I would incline to use the vmalloc() solution until the parser 
code has been rewritten. The hid_parser structure in question is living 
for very short time anyway, so it shouldn't be that big issue.

Thanks.


From: Jiri Kosina <[EMAIL PROTECTED]>
Subject: [PATCH] HID: allocate hid_parser through vmalloc()

hid_parser is non-trivially large structure, so it should be allocated
using vmalloc() to avoid unsuccessful allocations when memory fragmentation
is too high.
This structue has a very short life, it's destroyed as soon as the report
descriptor has been completely parsed.

This should be considered a temporary solution, until the hid_parser is
rewritten to consume less memory during report descriptor parsing.

Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
---
 drivers/hid/hid-core.c |   16 +---
 1 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index f4ee1af..e5894a7 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -654,12 +655,13 @@ struct hid_device *hid_parse_report(__u8 *start, unsigned 
size)
memcpy(device->rdesc, start, size);
device->rsize = size;
 
-   if (!(parser = kzalloc(sizeof(struct hid_parser), GFP_KERNEL))) {
+   if (!(parser = vmalloc(sizeof(struct hid_parser {
kfree(device->rdesc);
kfree(device->collection);
kfree(device);
return NULL;
}
+   memset(parser, 0, sizeof(struct hid_parser));
parser->device = device;
 
end = start + size;
@@ -668,7 +670,7 @@ struct hid_device *hid_parse_report(__u8 *start, unsigned 
size)
if (item.format != HID_ITEM_FORMAT_SHORT) {
dbg("unexpected long global item");
hid_free_device(device);
-   kfree(parser);
+   vfree(parser);
return NULL;
}
 
@@ -676,7 +678,7 @@ struct hid_device *hid_parse_report(__u8 *start, unsigned 
size)
dbg("item %u %u %u %u parsing failed\n",
item.format, (unsigned)item.size, 
(unsigned)item.type, (unsigned)item.tag);
hid_free_device(device);
-   kfree(parser);
+   vfree(parser);
return NULL;
}
 
@@ -684,23 +686,23 @@ struct hid_device *hid_parse_report(__u8 *start, unsigned 
size)
if (parser->collection_stack_ptr) {
dbg("unbalanced collection at end of report 
description");
hid_free_device(device);
-   kfree(parser);
+   vfree(parser);
return NULL;
}
if (parser->local.delimiter_depth) {
dbg("unbalanced delimiter at end of report 
description");
hid_free_device(device);
-   kfree(parser);
+   vfree(parser);
return NULL;
}
-   kfree(parser);
+   vfree(parser);
return device;
}
}
 
dbg("item fetching failed at offset %d\n", (int)(end - start));
hid_free_device(device);
-   kfree(parser);
+   vfree(parser);
return NULL;
 }
 EXPORT_SYMBOL_GPL(hid_parse_report);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: netconsole system freeze when cable unplugged

[Andi Kleen]

Simon Arlott <[EMAIL PROTECTED]> writes:

> On 09/03/07 20:42, Francois Romieu wrote:
> > Simon Arlott <[EMAIL PROTECTED]> :
> >> When I unplug the cable the system just stops responding to
> >> anything, at all. No message is printed to the console when the
> >> cable is plugged back in.
> > rtl8139_interrupt (spin_lock(>lock))
> > -> rtl8139_weird_interrupt
> >-> rtl_check_media
> >   -> mii_check_media (printk(KERN_INFO "%s: link down\n", ...))
> >  [netpoll stuff here]
> >  -> rtl8139_poll_controller
> > -> rtl8139_interrupt
> >*deadlock*
> > See below for my random stuff of the day. Feel free to open a PR at
> > bugzilla.kernel.org if the issue does not go away.
> 
> The patch doesn't fix it, nothing changes. I'm not sure how this can
> be debugged if printk won't work...

earlyprintk can be called directly (early_printk()) and should
work. It won't log over the network of course.

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

Problem: cat < /dev/my_ttyS0 is not blocked

[Mockern]

Hi,

I have a problem with  cat < /dev/my_ttyS0 (see strace output below). cat 
function is not blocked. I don't understand why it is not stopped at read(0, __ 
 and terminated?
Thank you

-- 
execve("/bin/cat", ["cat"], [/* 12 vars */]) = 0
brk(0)  = 0x7d000
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or 
directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=5664, ...}) = 0
old_mmap(NULL, 5664, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)= 0
open("/lib/libm.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\250B\0\000"..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=480324, ...}) = 0
old_mmap(NULL, 506412, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002
mprotect(0x40093000, 35372, PROT_NONE)  = 0
old_mmap(0x40098000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x7) = 0x40098000
close(3)= 0
open("/lib/libcrypt.so.1", O_RDONLY)= 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260\10\0"..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=19940, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40019000
old_mmap(NULL, 211220, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4009c000
mprotect(0x400a1000, 190740, PROT_NONE) = 0
old_mmap(0x400a4000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) 
= 0x400a4000
old_mmap(0x400a9000, 157972, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x400a9000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\330p\1\000"..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1240024, ...}) = 0
old_mmap(NULL, 1257088, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400d
mprotect(0x401f5000, 56960, PROT_NONE)  = 0
old_mmap(0x401f8000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x12) = 0x401f8000
old_mmap(0x40201000, 7808, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x40201000
close(3)= 0
munmap(0x40017000, 5664)= 0
getuid32()  = 0
getgid32()  = 0
setgid32(0) = 0
setuid32(0) = 0
read(0, "", 8192)   = 0
io_submit(0, 0x40200164, 0 
Process 1653 detached
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/