Change Compaq Array names to "HP Proliant Array Controllers" in KConfig

[Jeff V. Merkey]

Someone may wish to change the description of the Compaq Array 
Controllers under Block Devices to "HP" based controllers
for the HP appliances.  It's rather confusing and inaccurate since 
Compaq has not existed for several years now.  The controllers

come up and identify themselves as "HP Proliant" Controllers these days.

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

Change Compaq Array names to HP Proliant Array Controllers in KConfig

[Jeff V. Merkey]

Someone may wish to change the description of the Compaq Array 
Controllers under Block Devices to HP based controllers
for the HP appliances.  It's rather confusing and inaccurate since 
Compaq has not existed for several years now.  The controllers

come up and identify themselves as HP Proliant Controllers these days.

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

Preemption Broken: centrino_target busted under SMP on 2.6.20.4

[Jeff V. Merkey]

BUG: using smp_processor_id() in preemptible [0001] code: 
kondemand/0/2473

caller is centrino_target+0xfb/0x600
[<401e3646>] debug_smp_processor_id+0x9e/0xb0
[<40112afb>] centrino_target+0xfb/0x600
[<40112a00>] centrino_target+0x0/0x600
[<40305bd9>] __cpufreq_driver_target+0x5c/0x6b
[] do_dbs_timer+0x1bc/0x208 [cpufreq_ondemand]
[<40134a46>] run_workqueue+0x85/0x125
[<40374f7f>] _spin_lock_irqsave+0x18/0x66
[] do_dbs_timer+0x0/0x208 [cpufreq_ondemand]
[<401353fb>] worker_thread+0xf9/0x124
[<401213b9>] default_wake_function+0x0/0xc
[<40135302>] worker_thread+0x0/0x124
[<40137b37>] kthread+0xb0/0xd9
[<40137a87>] kthread+0x0/0xd9
[<40104b2f>] kernel_thread_helper+0x7/0x10
===

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

Preemption Broken: centrino_target busted under SMP on 2.6.20.4

[Jeff V. Merkey]

BUG: using smp_processor_id() in preemptible [0001] code: 
kondemand/0/2473

caller is centrino_target+0xfb/0x600
[401e3646] debug_smp_processor_id+0x9e/0xb0
[40112afb] centrino_target+0xfb/0x600
[40112a00] centrino_target+0x0/0x600
[40305bd9] __cpufreq_driver_target+0x5c/0x6b
[f897a537] do_dbs_timer+0x1bc/0x208 [cpufreq_ondemand]
[40134a46] run_workqueue+0x85/0x125
[40374f7f] _spin_lock_irqsave+0x18/0x66
[f897a37b] do_dbs_timer+0x0/0x208 [cpufreq_ondemand]
[401353fb] worker_thread+0xf9/0x124
[401213b9] default_wake_function+0x0/0xc
[40135302] worker_thread+0x0/0x124
[40137b37] kthread+0xb0/0xd9
[40137a87] kthread+0x0/0xd9
[40104b2f] kernel_thread_helper+0x7/0x10
===

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

Re: Latest e1000 7.3.20 driver busted with 2.6.20.4

[Jeff V. Merkey]

Kok, Auke wrote:


Jeff V. Merkey wrote:


Kok, Auke wrote:


Jeff V. Merkey wrote:


CC [M]  drivers/net/chelsio/mv88x201x.o
  CC [M]  drivers/net/chelsio/my3126.o
  LD [M]  drivers/net/chelsio/cxgb.o
  CC  drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro "INIT_WORK" 
passed 3 arguments, but takes just 2

ared (first use in this function)
drivers/net/e1000/e1000_main.c:1184: error: (Each undeclared 
identifier is reported only once
drivers/net/e1000/e1000_main.c:1184: error: for each function it 
appears in.)

make[3]: *** [drivers/net/e1000/e1000_main.o] Error 1
make[2]: *** [drivers/net/e1000] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2



this is hardly a thread for lkml as you're posting about out 
out-of-tree driver.  This issue has also been fixed in 7.4.35 which 
was released last week on e1000.sf.net. In the future, please post 
this stuff to [EMAIL PROTECTED] where we discuss the 
out-of-tree driver.


Cheers,

Auke

Thanks.  I'll download Intel's latest driver and test it.   I wasn't 
discussing the out of tree driver (why do you have a broken Linux out 
of tree driver, BTW?   If its for Linux, shouldn't it be updated here 
first) but the driver in 2.6.20.4 (which is missing support four 
additional chipsets). 



Our hardware release schedule is not aligned with kernel releases, and 
customers need to have a working (and tested) driver once the hardware 
is released. We try to get the updates into the kernel as fast as we 
can, but often meet resistance, as the two parties involved just have 
different interests.


Are you saying that the in-kernel driver in 2.6.20.4 is broken? That 
is bizarre, and should never happen. It compiles fine for me here...



It's missing support for some of the newer cards.  Your sales folks 
shipped us some newer hardware with the improved e1000, so I will have 
to adapt the newer drivers to 2.4.20.4.   Sounds like you are on top of 
it and things will sync up eventually.  :-)


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

Re: Latest e1000 7.3.20 driver busted with 2.6.20.4

[Jeff V. Merkey]

Kok, Auke wrote:


Jeff V. Merkey wrote:


CC [M]  drivers/net/chelsio/mv88x201x.o
  CC [M]  drivers/net/chelsio/my3126.o
  LD [M]  drivers/net/chelsio/cxgb.o
  CC  drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro "INIT_WORK" 
passed 3 arguments, but takes just 2

ared (first use in this function)
drivers/net/e1000/e1000_main.c:1184: error: (Each undeclared 
identifier is reported only once
drivers/net/e1000/e1000_main.c:1184: error: for each function it 
appears in.)

make[3]: *** [drivers/net/e1000/e1000_main.o] Error 1
make[2]: *** [drivers/net/e1000] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2



this is hardly a thread for lkml as you're posting about out 
out-of-tree driver.  This issue has also been fixed in 7.4.35 which 
was released last week on e1000.sf.net. In the future, please post 
this stuff to [EMAIL PROTECTED] where we discuss the 
out-of-tree driver.


Cheers,

Auke

Thanks.  I'll download Intel's latest driver and test it.   I wasn't 
discussing the out of tree driver (why do you have a broken Linux out of 
tree driver, BTW?   If its for Linux, shouldn't it be updated here 
first) but the driver in 2.6.20.4 (which is missing support four 
additional chipsets). 


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

Latest e1000 7.3.20 driver busted with 2.6.20.4

[Jeff V. Merkey]

CC [M]  drivers/net/chelsio/mv88x201x.o
 CC [M]  drivers/net/chelsio/my3126.o
 LD [M]  drivers/net/chelsio/cxgb.o
 CC  drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro "INIT_WORK" passed 
3 arguments, but takes just 2

ared (first use in this function)
drivers/net/e1000/e1000_main.c:1184: error: (Each undeclared identifier 
is reported only once
drivers/net/e1000/e1000_main.c:1184: error: for each function it appears 
in.)

make[3]: *** [drivers/net/e1000/e1000_main.o] Error 1
make[2]: *** [drivers/net/e1000] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2

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

Latest e1000 7.3.20 driver busted with 2.6.20.4

[Jeff V. Merkey]

CC [M]  drivers/net/chelsio/mv88x201x.o
 CC [M]  drivers/net/chelsio/my3126.o
 LD [M]  drivers/net/chelsio/cxgb.o
 CC  drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro INIT_WORK passed 
3 arguments, but takes just 2

ared (first use in this function)
drivers/net/e1000/e1000_main.c:1184: error: (Each undeclared identifier 
is reported only once
drivers/net/e1000/e1000_main.c:1184: error: for each function it appears 
in.)

make[3]: *** [drivers/net/e1000/e1000_main.o] Error 1
make[2]: *** [drivers/net/e1000] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2

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

Re: Latest e1000 7.3.20 driver busted with 2.6.20.4

[Jeff V. Merkey]

Kok, Auke wrote:


Jeff V. Merkey wrote:


CC [M]  drivers/net/chelsio/mv88x201x.o
  CC [M]  drivers/net/chelsio/my3126.o
  LD [M]  drivers/net/chelsio/cxgb.o
  CC  drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro INIT_WORK 
passed 3 arguments, but takes just 2

ared (first use in this function)
drivers/net/e1000/e1000_main.c:1184: error: (Each undeclared 
identifier is reported only once
drivers/net/e1000/e1000_main.c:1184: error: for each function it 
appears in.)

make[3]: *** [drivers/net/e1000/e1000_main.o] Error 1
make[2]: *** [drivers/net/e1000] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2



this is hardly a thread for lkml as you're posting about out 
out-of-tree driver.  This issue has also been fixed in 7.4.35 which 
was released last week on e1000.sf.net. In the future, please post 
this stuff to [EMAIL PROTECTED] where we discuss the 
out-of-tree driver.


Cheers,

Auke

Thanks.  I'll download Intel's latest driver and test it.   I wasn't 
discussing the out of tree driver (why do you have a broken Linux out of 
tree driver, BTW?   If its for Linux, shouldn't it be updated here 
first) but the driver in 2.6.20.4 (which is missing support four 
additional chipsets). 


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

Re: Latest e1000 7.3.20 driver busted with 2.6.20.4

[Jeff V. Merkey]

Kok, Auke wrote:


Jeff V. Merkey wrote:


Kok, Auke wrote:


Jeff V. Merkey wrote:


CC [M]  drivers/net/chelsio/mv88x201x.o
  CC [M]  drivers/net/chelsio/my3126.o
  LD [M]  drivers/net/chelsio/cxgb.o
  CC  drivers/net/e1000/e1000_main.o
drivers/net/e1000/e1000_main.c:1185:45: error: macro INIT_WORK 
passed 3 arguments, but takes just 2

ared (first use in this function)
drivers/net/e1000/e1000_main.c:1184: error: (Each undeclared 
identifier is reported only once
drivers/net/e1000/e1000_main.c:1184: error: for each function it 
appears in.)

make[3]: *** [drivers/net/e1000/e1000_main.o] Error 1
make[2]: *** [drivers/net/e1000] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2



this is hardly a thread for lkml as you're posting about out 
out-of-tree driver.  This issue has also been fixed in 7.4.35 which 
was released last week on e1000.sf.net. In the future, please post 
this stuff to [EMAIL PROTECTED] where we discuss the 
out-of-tree driver.


Cheers,

Auke

Thanks.  I'll download Intel's latest driver and test it.   I wasn't 
discussing the out of tree driver (why do you have a broken Linux out 
of tree driver, BTW?   If its for Linux, shouldn't it be updated here 
first) but the driver in 2.6.20.4 (which is missing support four 
additional chipsets). 



Our hardware release schedule is not aligned with kernel releases, and 
customers need to have a working (and tested) driver once the hardware 
is released. We try to get the updates into the kernel as fast as we 
can, but often meet resistance, as the two parties involved just have 
different interests.


Are you saying that the in-kernel driver in 2.6.20.4 is broken? That 
is bizarre, and should never happen. It compiles fine for me here...



It's missing support for some of the newer cards.  Your sales folks 
shipped us some newer hardware with the improved e1000, so I will have 
to adapt the newer drivers to 2.4.20.4.   Sounds like you are on top of 
it and things will sync up eventually.  :-)


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

Re: Conclusions from my investigation about ioapic programming

[Jeff V. Merkey]

Eric,

Please find attached the APIC code I used in Gadugi. It's code for plain 
vanilla APICs, but does just this. This code not only allows
interrupts to be migrated, but processors to be stopped and restarted on 
the fly without system interruption. You may find some useful

ideas in it.

Jeff
#include "stdarg.h"
#include "stdio.h"
#include "stdlib.h"
#include "ctype.h"
#include "string.h"
#include "kernel.h"
#include "keyboard.h"
#include "screen.h"
#include "types.h"
#include "os.h"
#include "mps.h"
#include "event.h"

#define MPS_VERBOSE 0

// MPS 1.0 standard tables

BYTE mps_default_table_1[] = {
'P','C','M','P', /* signature */
0,0, 1, 0, /* length, spec_rev, checksum */
0,0,0,0, 0,0,0,0, /* oem id string */
0,0,0,0, 0,0,0,0, 0,0,0,0, /* product id string */
0,0,0,0, /* oem table pointer */
0,0, 2+1+1+16+2,0, /* entry count */
0x00,0x00,0xe0,0xfe, /* address of local apic */
0,0,0,0, /* res. */

MP_ET_PROC, /* processor */
0, /* apic id == 0 */
1, /* apic type - 82489DX */
1, /* enable */
0,0,0,0, /* stepping, model, family, type */
0,0,0,0, /* feature flags - not used */
0,0,0,0, 0,0,0,0, /* res. */

MP_ET_PROC, /* processor */
1, /* apic id == 1 */
1, /* apic type - 82489DX */
1, /* enable */
0,0,0,0, /* stepping, model, family, type */
0,0,0,0, /* feature flags - not used */
0,0,0,0, 0,0,0,0, /* res. */

MP_ET_BUS, /* bus */
0, /* bus id */
'I','S','A',' ',
' ',' ',

MP_ET_IOAPIC, /* i/o apic */
2, /* apic id */
1, /* apic type - 82489DX (not used) */
1, /* enabled */
0x00,0x00,0xc0,0xfe, /* address of i/o apic */

MP_ET_I_INTR,3,0,0, /* PIC */
0,0,0xff,0, /* src(0,0) -> all i/o apics, line 0 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,1,2,1, /* src(0,1) -> i/o apic with id=2, line 1 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,2,2,1, /* src(0,2) -> i/o apic with id=2, line 2 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,3,2,3, /* src(0,3) -> i/o apic with id=2, line 3 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,4,2,4, /* src(0,4) -> i/o apic with id=2, line 4 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,5,2,5, /* src(0,5) -> i/o apic with id=2, line 5 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,6,2,6, /* src(0,6) -> i/o apic with id=2, line 6 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,7,2,7, /* src(0,7) -> i/o apic with id=2, line 7 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,8,2,8, /* src(0,8) -> i/o apic with id=2, line 8 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,9,2,9, /* src(0,9) -> i/o apic with id=2, line 9 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,10,2,10, /* src(0,10) -> i/o apic with id=2, line 10 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,11,2,11, /* src(0,11) -> i/o apic with id=2, line 11 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,12,2,12, /* src(0,12) -> i/o apic with id=2, line 12 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,13,2,12, /* src(0,13) -> i/o apic with id=2, line 13 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,14,2,14, /* src(0,14) -> i/o apic with id=2, line 14 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,15,2,15, /* src(0,15) -> i/o apic with id=2, line 15 */

MP_ET_L_INTR,3,0,0, /* PIC */
0,0,0xff,0, /* src(0,0) -> all local apics, line 0 */
MP_ET_L_INTR,1,0,0, /* NMI */
0,0,0xff,1, /* src(0,0) -> all local apics, line 1 */
};

BYTE mps_default_table_2[] = {
'P','C','M','P', /* signature */
0,0, 1, 0, /* length, spec_rev, checksum */
0,0,0,0, 0,0,0,0, /* oem id string */
0,0,0,0, 0,0,0,0, 0,0,0,0, /* product id string */
0,0,0,0, /* oem table pointer */
0,0, 2+1+1+14+2,0, /* entry count */
0x00,0x00,0xe0,0xfe, /* address of local apic */
0,0,0,0, /* res. */

MP_ET_PROC, /* processor */
0, /* apic id == 0 */
1, /* apic type - 82489DX */
1, /* enable */
0,0,0,0, /* stepping, model, family, type */
0,0,0,0, /* feature flags - not used */
0,0,0,0, 0,0,0,0, /* res. */

MP_ET_PROC, /* processor */
1, /* apic id == 1 */
1, /* apic type - 82489DX */
1, /* enable */
0,0,0,0, /* stepping, model, family, type */
0,0,0,0, /* feature flags - not used */
0,0,0,0, 0,0,0,0, /* res. */

MP_ET_BUS, /* bus */
0, /* bus id */
'E','I','S','A',
' ',' ',

MP_ET_IOAPIC, /* i/o apic */
2, /* apic id */
1, /* apic type - 82489DX (not used) */
1, /* enabled */
0x00,0x00,0xc0,0xfe, /* address of i/o apic */

MP_ET_I_INTR,3,0,0, /* PIC */
0,0,0xff,0, /* src(0,0) -> all i/o apics, line 0 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,1,2,1, /* src(0,1) -> i/o apic with id=2, line 1 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,3,2,3, /* src(0,3) -> i/o apic with id=2, line 3 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,4,2,4, /* src(0,4) -> i/o apic with id=2, line 4 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,5,2,5, /* src(0,5) -> i/o apic with id=2, line 5 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,6,2,6, /* src(0,6) -> i/o apic with id=2, line 6 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,7,2,7, /* src(0,7) -> i/o apic with id=2, line 7 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,8,2,8, /* src(0,8) -> i/o apic with id=2, line 8 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,9,2,9, /* src(0,9) -> i/o apic with id=2, line 9 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,10,2,10, /* src(0,10) -> i/o apic with id=2, line 10 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,11,2,11, /* src(0,11) -> i/o apic 

Re: Conclusions from my investigation about ioapic programming

[Jeff V. Merkey]

Here's the include file that goes with it.

Jeff

#include "types.h"
#include "emit.h"


#define _82489APIC_MASK 0x00F0
#define APIC_IO_REG 0x
#define APIC_IO_DATA 0x0004

// APIC registers are 128 bit aligned. accesses are offset * 4

#define APIC_TASKPRI (4 * 0x0008)
#define APIC_ID (4 * 0x0002)
#define APIC_VERS (4 * 0x0003)
#define APIC_LDEST (4 * 0x000D)
#define APIC_EOI (4 * 0x000B)
#define APIC_DESTFMT (4 * 0x000E)
#define APIC_SPUR (4 * 0x000F)
#define APIC_IRR0 (4 * 0x0020)
#define APIC_ICMD (4 * 0x0030)
#define APIC_ICMD2 (4 * 0x0031)
#define APIC_LVT_TIMER (4 * 0x0032)
#define APIC_LVT_I0 (4 * 0x0035)
#define APIC_LVT_I1 (4 * 0x0036)
#define APIC_ICOUNT (4 * 0x0038)
#define APIC_CCOUNT (4 * 0x0039)

// APIc command values

#define APIC_REG_ID 0x
#define APIC_REG_RDT 0x0010
#define APIC_REG_RDT2 0x0011
#define APIC_VALUE_MASK 0x0001
#define APIC_VALUE_TOALL 0x7FFF
#define APIC_LOGDEST(c) (0x4000 >> (c))
#define APIC_VALUE_IM_OFF 0x8000

#define APIC_VALUE_FIXED 0x
#define APIC_VALUE_LOPRI 0x0100
#define APIC_VALUE_NMI 0x0400

#define APIC_VALUE_RESET 0x0500
#define APIC_VALUE_STARTUP 0x0600
#define APIC_VALUE_EXTINT 0x0700
#define APIC_VALUE_PENDING 0x1000
#define APIC_VALUE_PDEST 0x
#define APIC_VALUE_LDEST 0x0800
#define APIC_VALUE_POLOW 0x2000
#define APIC_VALUE_POHIGH 0x
#define APIC_VALUE_ASSERT 0x4000
#define APIC_VALUE_DEASSERT 0x
#define APIC_VALUE_EDGE 0x
#define APIC_VALUE_LEVEL 0x8000
#define APIC_VALUE_XTOSELF 0x0004
#define APIC_VALUE_XTOALL 0x0008

// APIC timer init values

#define HERTZ 100
#define NANOSECOND_PULSE_RATE 90
#define APIC_CLKNUM ((10/NANOSECOND_PULSE_RATE)/HERTZ)
#define APIC_ID_MASK 0x0F00
#define APIC_ID_SHIFT 24
#define TIMER_VECTOR 0x0028

// IOAPIC interrupt delivery modes

#define DELIVERY_MODE_MASK 0x0700
#define DELIVER_FIXED 0x
#define DELIVER_LOW_PRIORITY 0x0100
#define DELIVER_SMI 0x0200
#define DELIVER_REMOTE_READ 0x0300
#define DELIVER_NMI 0x0400
#define DELIVER_INIT 0x0500
#define DELIVER_INIT_REASSERT_ALL 0x00088500
#define DELIVER_INIT_REASSERT_SELF 0x00048500
#define DELIVER_RESET_HOLD_ALL 0x0008C500
#define DELIVER_EXTINT 0x0700

// APIC addressing mode values

#define PHYSICAL_DESTINATION 0x
#define LOGICAL_DESTINATION 0x0800
#define DELIVERY_PENDING 0x1000
#define ACTIVE_LOW 0x2000
#define REMOTE_IRR 0x4000
#define LEVEL_TRIGGERED 0x8000
#define INTERRUPT_MASKED 0x0001
#define INTERRUPT_UNMASKED 0x
#define PERIODIC_TIMER 0x0002

#define TIMER_BASE_CLOCK 0x
#define TIMER_BASE_TMBASE 0x0004
#define TIMER_BASE_DIVIDER 0x0008

#define ICR_LEVEL_ASSERTED 0x4000
#define ICR_RR_STATUS_MASK 0x0003
#define ICR_RR_INVALID 0x
#define ICR_RR_IN_PROGRESS 0x0001
#define ICR_RR_VALID 0x0002
#define ICR_SHORTHAND_MASK 0x000C
#define ICR_USE_DEST_FIELD 0x
#define ICR_SELF 0x0004
#define ICR_ALL_INCL_SELF 0x0008
#define ICR_ALL_EXCL_SELF 0x000C

#define LU_DEST_FORMAT_MASK 0xF000
#define LU_DEST_FORMAT_FLAT 0x
#define LU_UNIT_ENABLED 0x0100

//
// 8259 PIC registers
//

#define MAX_PICS 3
#define PIC_0 0x20
#define PIC_1 0xA0
#define PIC_2 0x30
#define MASK_0 0x21
#define MASK_1 0xA1
#define MASK_2 0x31
#define PIC_EOI 0x20
#define MAX_INTS 64
#define CHAIN_LENGTH 16

//
// EISA polarity registers
//

#define EISA_POLARITY_REG 0x0C0E
#define PIC1_ELCR_PORT 0x04D0
#define PIC2_ELCR_PORT 0x04D1
#define ELCR_EDGE 0
#define ELCR_LEVEL 1

/* Definitions for Intel PC+MP Platform Specification */

/* Misc. */
#define EBDA_BASE 0x0009FC00 /* base of EBDA default location 639k */
#define EBDA_PTR 0x040E /* pointer to base of EBDA segment */
#define BMEM_PTR 0x0413 /* pointer to installed base memory in kbyte*/
#define CPQ_RESET_VECT 0x0467 /* reset vector location */

/* PC+MP Interrupt Mode Control Registers */

#define IMCR_ADDR 0x22
#define IMCR_DATA 0x23
#define CMOSCTL 0x8F /* CMOS warm-boot addr */
#define CMOSWARM 0x0A /* CMOS warm-boot flag */
#define CMOS_ADDR 0x70
#define CMOS_DATA 0x71

#define MP_IMCRP 0x80 /* IMCR present */
#define MP_IMCRA 0x0 /* IMCR absent */
#define MP_DEF_TYPE 6 /* default table to use */
#define MP_DEF_IMCR MP_IMCRA/* default IMCRP to use */

/* types of entries (stored in bytes[0]) */
#define MP_ET_PROC 0 /* processor */
#define MP_ET_BUS 1 /* bus */
#define MP_ET_IOAPIC 2 /* i/o apic */
#define MP_ET_I_INTR 3 /* interrupt assignment -> i/o apic */
#define MP_ET_L_INTR 4 /* interrupt assignment -> local apic */

/* flag values for intr */
#define MP_INTR_POVAL 1
#define MP_INTR_POLOW 2
#define MP_INTR_ELVAL 4
#define MP_INTR_ELLEVEL 8

#define MAX_BUSES 16
#define MAX_IOAPICS 16

struct pcmp_fptr { /* PC+MP floating pointer structure */
BYTE 

Re: Conclusions from my investigation about ioapic programming

[Jeff V. Merkey]

Eric W. Biederman wrote:




** Conclusions.

*IRQs must be reprogramed in interrupt context.

The result of this is investigation is that I am convinced we need
to perform the irq migration activities in interrupt context although
I am not convinced it is completely safe.  I suspect multiple irqs
firing closely enough to each other may hit the same issues as
migrating irqs from process context.  However the odds are on our
side, when we are in irq context.

 

In my older days of programmin 82489DX chipsets (which the AMD APIC 
versions resemble
the 82489DX more closely than intel's newer incarnations), you had to 
EOI the apic early if you
wanted to migrate interrupt assignments. I had to do the following steps 
to move an IRQ:


1. Mask the LOCAL APIC
2, EOI the interrupt
3. Leave the interrupt entry masked until the ISR completed.
4. Reprogram the interrupt.
5. Unmask as the ISR exits

In other words, EOI early in all cases to clear the local and IOAPIC state.

Jeff


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

Re: Conclusions from my investigation about ioapic programming

[Jeff V. Merkey]

Eric W. Biederman wrote:




** Conclusions.

*IRQs must be reprogramed in interrupt context.

The result of this is investigation is that I am convinced we need
to perform the irq migration activities in interrupt context although
I am not convinced it is completely safe.  I suspect multiple irqs
firing closely enough to each other may hit the same issues as
migrating irqs from process context.  However the odds are on our
side, when we are in irq context.

 

In my older days of programmin 82489DX chipsets (which the AMD APIC 
versions resemble
the 82489DX more closely than intel's newer incarnations), you had to 
EOI the apic early if you
wanted to migrate interrupt assignments. I had to do the following steps 
to move an IRQ:


1. Mask the LOCAL APIC
2, EOI the interrupt
3. Leave the interrupt entry masked until the ISR completed.
4. Reprogram the interrupt.
5. Unmask as the ISR exits

In other words, EOI early in all cases to clear the local and IOAPIC state.

Jeff


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

Re: Conclusions from my investigation about ioapic programming

[Jeff V. Merkey]

Here's the include file that goes with it.

Jeff

#include types.h
#include emit.h


#define _82489APIC_MASK 0x00F0
#define APIC_IO_REG 0x
#define APIC_IO_DATA 0x0004

// APIC registers are 128 bit aligned. accesses are offset * 4

#define APIC_TASKPRI (4 * 0x0008)
#define APIC_ID (4 * 0x0002)
#define APIC_VERS (4 * 0x0003)
#define APIC_LDEST (4 * 0x000D)
#define APIC_EOI (4 * 0x000B)
#define APIC_DESTFMT (4 * 0x000E)
#define APIC_SPUR (4 * 0x000F)
#define APIC_IRR0 (4 * 0x0020)
#define APIC_ICMD (4 * 0x0030)
#define APIC_ICMD2 (4 * 0x0031)
#define APIC_LVT_TIMER (4 * 0x0032)
#define APIC_LVT_I0 (4 * 0x0035)
#define APIC_LVT_I1 (4 * 0x0036)
#define APIC_ICOUNT (4 * 0x0038)
#define APIC_CCOUNT (4 * 0x0039)

// APIc command values

#define APIC_REG_ID 0x
#define APIC_REG_RDT 0x0010
#define APIC_REG_RDT2 0x0011
#define APIC_VALUE_MASK 0x0001
#define APIC_VALUE_TOALL 0x7FFF
#define APIC_LOGDEST(c) (0x4000  (c))
#define APIC_VALUE_IM_OFF 0x8000

#define APIC_VALUE_FIXED 0x
#define APIC_VALUE_LOPRI 0x0100
#define APIC_VALUE_NMI 0x0400

#define APIC_VALUE_RESET 0x0500
#define APIC_VALUE_STARTUP 0x0600
#define APIC_VALUE_EXTINT 0x0700
#define APIC_VALUE_PENDING 0x1000
#define APIC_VALUE_PDEST 0x
#define APIC_VALUE_LDEST 0x0800
#define APIC_VALUE_POLOW 0x2000
#define APIC_VALUE_POHIGH 0x
#define APIC_VALUE_ASSERT 0x4000
#define APIC_VALUE_DEASSERT 0x
#define APIC_VALUE_EDGE 0x
#define APIC_VALUE_LEVEL 0x8000
#define APIC_VALUE_XTOSELF 0x0004
#define APIC_VALUE_XTOALL 0x0008

// APIC timer init values

#define HERTZ 100
#define NANOSECOND_PULSE_RATE 90
#define APIC_CLKNUM ((10/NANOSECOND_PULSE_RATE)/HERTZ)
#define APIC_ID_MASK 0x0F00
#define APIC_ID_SHIFT 24
#define TIMER_VECTOR 0x0028

// IOAPIC interrupt delivery modes

#define DELIVERY_MODE_MASK 0x0700
#define DELIVER_FIXED 0x
#define DELIVER_LOW_PRIORITY 0x0100
#define DELIVER_SMI 0x0200
#define DELIVER_REMOTE_READ 0x0300
#define DELIVER_NMI 0x0400
#define DELIVER_INIT 0x0500
#define DELIVER_INIT_REASSERT_ALL 0x00088500
#define DELIVER_INIT_REASSERT_SELF 0x00048500
#define DELIVER_RESET_HOLD_ALL 0x0008C500
#define DELIVER_EXTINT 0x0700

// APIC addressing mode values

#define PHYSICAL_DESTINATION 0x
#define LOGICAL_DESTINATION 0x0800
#define DELIVERY_PENDING 0x1000
#define ACTIVE_LOW 0x2000
#define REMOTE_IRR 0x4000
#define LEVEL_TRIGGERED 0x8000
#define INTERRUPT_MASKED 0x0001
#define INTERRUPT_UNMASKED 0x
#define PERIODIC_TIMER 0x0002

#define TIMER_BASE_CLOCK 0x
#define TIMER_BASE_TMBASE 0x0004
#define TIMER_BASE_DIVIDER 0x0008

#define ICR_LEVEL_ASSERTED 0x4000
#define ICR_RR_STATUS_MASK 0x0003
#define ICR_RR_INVALID 0x
#define ICR_RR_IN_PROGRESS 0x0001
#define ICR_RR_VALID 0x0002
#define ICR_SHORTHAND_MASK 0x000C
#define ICR_USE_DEST_FIELD 0x
#define ICR_SELF 0x0004
#define ICR_ALL_INCL_SELF 0x0008
#define ICR_ALL_EXCL_SELF 0x000C

#define LU_DEST_FORMAT_MASK 0xF000
#define LU_DEST_FORMAT_FLAT 0x
#define LU_UNIT_ENABLED 0x0100

//
// 8259 PIC registers
//

#define MAX_PICS 3
#define PIC_0 0x20
#define PIC_1 0xA0
#define PIC_2 0x30
#define MASK_0 0x21
#define MASK_1 0xA1
#define MASK_2 0x31
#define PIC_EOI 0x20
#define MAX_INTS 64
#define CHAIN_LENGTH 16

//
// EISA polarity registers
//

#define EISA_POLARITY_REG 0x0C0E
#define PIC1_ELCR_PORT 0x04D0
#define PIC2_ELCR_PORT 0x04D1
#define ELCR_EDGE 0
#define ELCR_LEVEL 1

/* Definitions for Intel PC+MP Platform Specification */

/* Misc. */
#define EBDA_BASE 0x0009FC00 /* base of EBDA default location 639k */
#define EBDA_PTR 0x040E /* pointer to base of EBDA segment */
#define BMEM_PTR 0x0413 /* pointer to installed base memory in kbyte*/
#define CPQ_RESET_VECT 0x0467 /* reset vector location */

/* PC+MP Interrupt Mode Control Registers */

#define IMCR_ADDR 0x22
#define IMCR_DATA 0x23
#define CMOSCTL 0x8F /* CMOS warm-boot addr */
#define CMOSWARM 0x0A /* CMOS warm-boot flag */
#define CMOS_ADDR 0x70
#define CMOS_DATA 0x71

#define MP_IMCRP 0x80 /* IMCR present */
#define MP_IMCRA 0x0 /* IMCR absent */
#define MP_DEF_TYPE 6 /* default table to use */
#define MP_DEF_IMCR MP_IMCRA/* default IMCRP to use */

/* types of entries (stored in bytes[0]) */
#define MP_ET_PROC 0 /* processor */
#define MP_ET_BUS 1 /* bus */
#define MP_ET_IOAPIC 2 /* i/o apic */
#define MP_ET_I_INTR 3 /* interrupt assignment - i/o apic */
#define MP_ET_L_INTR 4 /* interrupt assignment - local apic */

/* flag values for intr */
#define MP_INTR_POVAL 1
#define MP_INTR_POLOW 2
#define MP_INTR_ELVAL 4
#define MP_INTR_ELLEVEL 8

#define MAX_BUSES 16
#define MAX_IOAPICS 16

struct pcmp_fptr { /* PC+MP floating pointer structure */
BYTE sig[4]; /* 

Re: Conclusions from my investigation about ioapic programming

[Jeff V. Merkey]

Eric,

Please find attached the APIC code I used in Gadugi. It's code for plain 
vanilla APICs, but does just this. This code not only allows
interrupts to be migrated, but processors to be stopped and restarted on 
the fly without system interruption. You may find some useful

ideas in it.

Jeff
#include stdarg.h
#include stdio.h
#include stdlib.h
#include ctype.h
#include string.h
#include kernel.h
#include keyboard.h
#include screen.h
#include types.h
#include os.h
#include mps.h
#include event.h

#define MPS_VERBOSE 0

// MPS 1.0 standard tables

BYTE mps_default_table_1[] = {
'P','C','M','P', /* signature */
0,0, 1, 0, /* length, spec_rev, checksum */
0,0,0,0, 0,0,0,0, /* oem id string */
0,0,0,0, 0,0,0,0, 0,0,0,0, /* product id string */
0,0,0,0, /* oem table pointer */
0,0, 2+1+1+16+2,0, /* entry count */
0x00,0x00,0xe0,0xfe, /* address of local apic */
0,0,0,0, /* res. */

MP_ET_PROC, /* processor */
0, /* apic id == 0 */
1, /* apic type - 82489DX */
1, /* enable */
0,0,0,0, /* stepping, model, family, type */
0,0,0,0, /* feature flags - not used */
0,0,0,0, 0,0,0,0, /* res. */

MP_ET_PROC, /* processor */
1, /* apic id == 1 */
1, /* apic type - 82489DX */
1, /* enable */
0,0,0,0, /* stepping, model, family, type */
0,0,0,0, /* feature flags - not used */
0,0,0,0, 0,0,0,0, /* res. */

MP_ET_BUS, /* bus */
0, /* bus id */
'I','S','A',' ',
' ',' ',

MP_ET_IOAPIC, /* i/o apic */
2, /* apic id */
1, /* apic type - 82489DX (not used) */
1, /* enabled */
0x00,0x00,0xc0,0xfe, /* address of i/o apic */

MP_ET_I_INTR,3,0,0, /* PIC */
0,0,0xff,0, /* src(0,0) - all i/o apics, line 0 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,1,2,1, /* src(0,1) - i/o apic with id=2, line 1 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,2,2,1, /* src(0,2) - i/o apic with id=2, line 2 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,3,2,3, /* src(0,3) - i/o apic with id=2, line 3 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,4,2,4, /* src(0,4) - i/o apic with id=2, line 4 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,5,2,5, /* src(0,5) - i/o apic with id=2, line 5 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,6,2,6, /* src(0,6) - i/o apic with id=2, line 6 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,7,2,7, /* src(0,7) - i/o apic with id=2, line 7 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,8,2,8, /* src(0,8) - i/o apic with id=2, line 8 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,9,2,9, /* src(0,9) - i/o apic with id=2, line 9 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,10,2,10, /* src(0,10) - i/o apic with id=2, line 10 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,11,2,11, /* src(0,11) - i/o apic with id=2, line 11 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,12,2,12, /* src(0,12) - i/o apic with id=2, line 12 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,13,2,12, /* src(0,13) - i/o apic with id=2, line 13 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,14,2,14, /* src(0,14) - i/o apic with id=2, line 14 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,15,2,15, /* src(0,15) - i/o apic with id=2, line 15 */

MP_ET_L_INTR,3,0,0, /* PIC */
0,0,0xff,0, /* src(0,0) - all local apics, line 0 */
MP_ET_L_INTR,1,0,0, /* NMI */
0,0,0xff,1, /* src(0,0) - all local apics, line 1 */
};

BYTE mps_default_table_2[] = {
'P','C','M','P', /* signature */
0,0, 1, 0, /* length, spec_rev, checksum */
0,0,0,0, 0,0,0,0, /* oem id string */
0,0,0,0, 0,0,0,0, 0,0,0,0, /* product id string */
0,0,0,0, /* oem table pointer */
0,0, 2+1+1+14+2,0, /* entry count */
0x00,0x00,0xe0,0xfe, /* address of local apic */
0,0,0,0, /* res. */

MP_ET_PROC, /* processor */
0, /* apic id == 0 */
1, /* apic type - 82489DX */
1, /* enable */
0,0,0,0, /* stepping, model, family, type */
0,0,0,0, /* feature flags - not used */
0,0,0,0, 0,0,0,0, /* res. */

MP_ET_PROC, /* processor */
1, /* apic id == 1 */
1, /* apic type - 82489DX */
1, /* enable */
0,0,0,0, /* stepping, model, family, type */
0,0,0,0, /* feature flags - not used */
0,0,0,0, 0,0,0,0, /* res. */

MP_ET_BUS, /* bus */
0, /* bus id */
'E','I','S','A',
' ',' ',

MP_ET_IOAPIC, /* i/o apic */
2, /* apic id */
1, /* apic type - 82489DX (not used) */
1, /* enabled */
0x00,0x00,0xc0,0xfe, /* address of i/o apic */

MP_ET_I_INTR,3,0,0, /* PIC */
0,0,0xff,0, /* src(0,0) - all i/o apics, line 0 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,1,2,1, /* src(0,1) - i/o apic with id=2, line 1 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,3,2,3, /* src(0,3) - i/o apic with id=2, line 3 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,4,2,4, /* src(0,4) - i/o apic with id=2, line 4 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,5,2,5, /* src(0,5) - i/o apic with id=2, line 5 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,6,2,6, /* src(0,6) - i/o apic with id=2, line 6 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,7,2,7, /* src(0,7) - i/o apic with id=2, line 7 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,8,2,8, /* src(0,8) - i/o apic with id=2, line 8 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,9,2,9, /* src(0,9) - i/o apic with id=2, line 9 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,10,2,10, /* src(0,10) - i/o apic with id=2, line 10 */
MP_ET_I_INTR,0,0,0, /* INTR */
0,11,2,11, /* src(0,11) - i/o apic with id=2, line 11 */
MP_ET_I_INTR,0,0,0, /* INTR */

Re: Free Linux Driver Development!

[Jeff V. Merkey]

Jeff Garzik wrote:


Great offer to folks for drivers, but it sends a mixed message.  OSDL 
should offer to host a page somewhere to coordinate all of this.


:-)

Jeff


Roland Dreier wrote:


Just look at the in-tree drivers: there are tons of them that don't
work on big-endian platforms, or have 64-bit problems, or have no SMP
support.  And that doesn't even count drivers that are so bitrotted
they won't even build any more.



The vast majority of these were submitted ages ago.  Standards for 
acceptance and maintenance have risen since the days of ISA drivers 
and floppy tape drives.


I think it's quite disingenuous to imply that a few bad apples are a 
representative sample.


Jeff


-
To unsubscribe from this list: send the line "unsubscribe 
linux-kernel" in

the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Free Linux Driver Development!

[Jeff V. Merkey]

Jeff Garzik wrote:


Great offer to folks for drivers, but it sends a mixed message.  OSDL 
should offer to host a page somewhere to coordinate all of this.


:-)

Jeff


Roland Dreier wrote:


Just look at the in-tree drivers: there are tons of them that don't
work on big-endian platforms, or have 64-bit problems, or have no SMP
support.  And that doesn't even count drivers that are so bitrotted
they won't even build any more.



The vast majority of these were submitted ages ago.  Standards for 
acceptance and maintenance have risen since the days of ISA drivers 
and floppy tape drives.


I think it's quite disingenuous to imply that a few bad apples are a 
representative sample.


Jeff


-
To unsubscribe from this list: send the line unsubscribe 
linux-kernel in

the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Lennart Sorensen wrote:


On Wed, Jan 10, 2007 at 06:29:28PM +0100, Prakash Punnoor wrote:
 


You can install the Intel Matrix driver after "adjusting" the inf file...
   



Hmm, I guess a good question is: Why should I have to edit the inf file?
Is it an issue of them making it only install if your hardware is
already set to ahci mode?  But how am I supposed to boot and install the
driver until I have the driver installed then.  Well I might try that
next time I go there.  




How stupid of intel.
 



No doubt part of the Wintel (intel + Microsoft) strategy to perpetually 
break non-windows platforms with new incompatible
hardware like the switch over from the e1000 MT adapters to e1000 GT 
which are not backward compatible with the older chipsets.


I still have not seen the GT adapter work correctly off windows.

Jeff

:-)

Jeff


--
Len Sorensen

 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Lennart Sorensen wrote:


On Wed, Jan 10, 2007 at 06:29:28PM +0100, Prakash Punnoor wrote:
 


You can install the Intel Matrix driver after adjusting the inf file...
   



Hmm, I guess a good question is: Why should I have to edit the inf file?
Is it an issue of them making it only install if your hardware is
already set to ahci mode?  But how am I supposed to boot and install the
driver until I have the driver installed then.  Well I might try that
next time I go there.  




How stupid of intel.
 



No doubt part of the Wintel (intel + Microsoft) strategy to perpetually 
break non-windows platforms with new incompatible
hardware like the switch over from the e1000 MT adapters to e1000 GT 
which are not backward compatible with the older chipsets.


I still have not seen the GT adapter work correctly off windows.

Jeff

:-)

Jeff


--
Len Sorensen

 



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Jeff Garzik wrote:


Jeff V. Merkey wrote:


Jeff Garzik wrote:


Jeff V. Merkey wrote:



I just finished pulling out a melted IDE flash drive out of a 
Shuttle motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the 
chassis.  I note that the 945 chipset in the shuttle PC had some 
serious
issues recognizing 2 x SATA devices and a IDE device 
concurrently.   Are there known problems with the Linux drivers

with these newer chipsets.

One other disturbing issue was the IDE flash drive was configured 
(and recognized) as /dev/hda during bootup, but when
it got to the root mountint, even with root=/dev/hda set, it still 
kept thinking the drive was at scsi (ATA) device (08,13)

and kept crashing with VFS cannot find root FS errors.




We have two sets of ATA drivers now, and Intel motherboards support 
bazillion annoying IDE modes, so you will need to provide more info 
than this.


Is the motherboard in combined mode?




Yes.  "Enhanced mode" is how it is listed in the BIOS.



Combined mode is a technical term.  Judging from your answers, you are 
not using combined mode.




native mode?  AHCI or RAID mode?



No RAID, just enhanced mode (SATA 3.0 + IDE)



Judging from your answers, you are not in AHCI mode.

Side note:  You should use AHCI if available.  Emulating a PATA 
interface for SATA devices is error prone [in the silicon].  AHCI is 
native SATA, "enhanced mode" is not.



AHCI It is.   


Jeff




The cannot-find-root-FS errors are definitely caused by driver 
and/or initrd misconfiguration.  The melted flash, I dunno, maybe 
you managed to get two drivers fighting over the same hardware.



No.  Seems related to the chipset problems.  If I say 
"root=/dev/hda2" I have better not be getting errors claiming device 
08:13 could not mount as root.  memory corruption?



If the kernel cannot mount the requested root= disk, it tries the 
default that is encoded into the vmlinuz image at build time, which is 
probably 08:13.



The melted flash seems power related (like pin 20 was live for some 
reason on a standard IDE).



Probably, otherwise we would have many more reports like this than 
just yours.


Jeff





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

Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Lennart Sorensen wrote:


On Tue, Jan 09, 2007 at 01:46:42PM -0700, Jeff V. Merkey wrote:
 

I just finished pulling out a melted IDE flash drive out of a Shuttle 
motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the chassis.  
I note that the 945 chipset in the shuttle PC had some serious
issues recognizing 2 x SATA devices and a IDE device concurrently.   Are 
there known problems with the Linux drivers

with these newer chipsets.
   



Had the drive ever been used in any other machine?  



Yes, on a SuperMicro X6DHE-G2 Xeon motherboard -- worked fine.


Had any ide device
ever been used in this machine before?  


Yes. external cabled CDROM Drive seems to work.

Jeff


It really sounds like a hardware
problem, since I can't think of anything software could do to make that
kind of current go through the flash drive.

I remember seeing the controller chip on a 730MB quantum scsi drive
start to glow red many years ago, just before the drive stopped
responding to the system (and I turned off the power).  Hardware does
fail.  It almost never has anything to do with software.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Jeff Garzik wrote:


Jeff V. Merkey wrote:



I just finished pulling out a melted IDE flash drive out of a Shuttle 
motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the 
chassis.  I note that the 945 chipset in the shuttle PC had some serious
issues recognizing 2 x SATA devices and a IDE device concurrently.   
Are there known problems with the Linux drivers

with these newer chipsets.

One other disturbing issue was the IDE flash drive was configured 
(and recognized) as /dev/hda during bootup, but when
it got to the root mountint, even with root=/dev/hda set, it still 
kept thinking the drive was at scsi (ATA) device (08,13)

and kept crashing with VFS cannot find root FS errors.



We have two sets of ATA drivers now, and Intel motherboards support 
bazillion annoying IDE modes, so you will need to provide more info 
than this.


Is the motherboard in combined mode?



Yes.  "Enhanced mode" is how it is listed in the BIOS.


native mode?  AHCI or RAID mode?


No RAID, just enhanced mode (SATA 3.0 + IDE)

What driver set did you pick?  



Standard build = standard IDE + Intel PIIX + SATA + Intel ICP

is drivers/ide built in, modular, or disabled?  is drivers/ata built 
in, modular, or disabled?


built in in all cases.



The cannot-find-root-FS errors are definitely caused by driver and/or 
initrd misconfiguration.  The melted flash, I dunno, maybe you managed 
to get two drivers fighting over the same hardware.


No.  Seems related to the chipset problems.  If I say "root=/dev/hda2" I 
have better not be getting errors claiming device 08:13 could not mount 
as root.  memory corruption?


The melted flash seems power related (like pin 20 was live for some 
reason on a standard IDE).


Jeff



Jeff






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

Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Auke Kok wrote:


Jeff V. Merkey wrote:


Jeff V. Merkey wrote:

root=/dev/hda2 is what was passed to the kernel from grub.

Jeff



I just finished pulling out a melted IDE flash drive out of a 
Shuttle motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the 
chassis.  I note that the 945 chipset in the shuttle PC had some 
serious
issues recognizing 2 x SATA devices and a IDE device concurrently.   
Are there known problems with the Linux drivers

with these newer chipsets.

One other disturbing issue was the IDE flash drive was configured 
(and recognized) as /dev/hda during bootup, but when
it got to the root mountint, even with root=/dev/hda set, it still 
kept thinking the drive was at scsi (ATA) device (08,13)

and kept crashing with VFS cannot find root FS errors.




it sounds like someone switched the BIOS IDE setting from 
ide-compatible/legacy to AHCI or similar, a not uncommon option in the 
sata controllers on those boards.


None of that would explain the melting of anything of course.



Would be if pin 20 were powered for some reason (which it should NOT 
be). 


Jeff



Cheers,

Auke
-
To unsubscribe from this list: send the line "unsubscribe 
linux-kernel" in

the body of a message 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: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Jeff V. Merkey wrote:

root=/dev/hda2 is what was passed to the kernel from grub.

Jeff



I just finished pulling out a melted IDE flash drive out of a Shuttle 
motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the 
chassis.  I note that the 945 chipset in the shuttle PC had some serious
issues recognizing 2 x SATA devices and a IDE device concurrently.   
Are there known problems with the Linux drivers

with these newer chipsets.

One other disturbing issue was the IDE flash drive was configured (and 
recognized) as /dev/hda during bootup, but when
it got to the root mountint, even with root=/dev/hda set, it still 
kept thinking the drive was at scsi (ATA) device (08,13)

and kept crashing with VFS cannot find root FS errors.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe 
linux-kernel" in

the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: NTFS deadlock on 2.6.18.6

[Jeff V. Merkey]

Sergey Vlasov wrote:

Yep.  


Hello!

I have encountered a deadlock in the NTFS filesystem on a
2.6.18.6-based kernel (x86_64, CONFIG_SMP set, but the machine has
only one CPU (Athlon64 3200+), no PREEMPT).

The kswapd0 and mklocatedb processes were apparently involved in the
deadlock:

kswapd0   D 810005dea304 0   163  7   164   162 (L-TLB)
81003fd6bcc8 0046 0020 021aaac0
000a 81003fe93820 81003fb157a0 027894893008
000308da 81003fe93a20 8100 810001641670
Call Trace:
[] __mutex_lock_slowpath+0x5d/0x98
[] .text.lock.mutex+0x5/0x14
DWARF2 unwinder stuck at .text.lock.mutex+0x5/0x14
Leftover inexact backtrace:
[] :ntfs:ntfs_put_inode+0x38/0x7a
[] iput+0x3b/0x84
[] :ntfs:ntfs_clear_big_inode+0x107/0x121
[] clear_inode+0xc5/0xf6
[] dispose_list+0x56/0xf6
[] shrink_icache_memory+0x1d4/0x203
[] shrink_slab+0xdc/0x154
[] kswapd+0x320/0x424
[] autoremove_wake_function+0x0/0x2e
[] keventd_create_kthread+0x0/0x61
[] kswapd+0x0/0x424
[] keventd_create_kthread+0x0/0x61
[] kthread+0xd4/0x107
[] child_rip+0xa/0x12
[] keventd_create_kthread+0x0/0x61
[] kthread+0x0/0x107
[] child_rip+0x0/0x12

mklocatedbD 810001e0d400 0  4586   4585 (NOTLB)
810021fd5c48 0082  
000a 81002728f7e0 8048b3c0 02789a2349cf
25c4 81002728f9e0 8100 
Call Trace:
[] __wait_on_freeing_inode+0x82/0xa0
[] find_inode+0x3d/0x6c
[] ifind+0x34/0x91
[] iget5_locked+0x6c/0x1a9
[] :ntfs:ntfs_attr_iget+0x5a/0x5eb
[] :ntfs:ntfs_readdir+0x3f1/0xce1
[] vfs_readdir+0x77/0xa9
[] sys_getdents+0x75/0xbd
[] system_call+0x7e/0x83
DWARF2 unwinder stuck at system_call+0x7e/0x83
Leftover inexact backtrace:

There were some other processes stuck in the D state, but that seems
to be just a result of the above deadlock:

linuxdcpp D 810001e0d400 0  4912   4910  4914  4911 (NOTLB)
8100283d1bf0 0082 81000181cf38 8100283d1b98
0007 81002ca0c0c0 8048b3c0 0279f4c0a091
00026b39 81002ca0c2c0  
Call Trace:
[] __mutex_lock_slowpath+0x5d/0x98
[] .text.lock.mutex+0x5/0x14
DWARF2 unwinder stuck at .text.lock.mutex+0x5/0x14
Leftover inexact backtrace:
[] shrink_icache_memory+0x40/0x203
[] shrink_slab+0xdc/0x154
[] try_to_free_pages+0x179/0x254
[] __alloc_pages+0x1a8/0x2a9
[] __do_page_cache_readahead+0x95/0x206
[] force_page_cache_readahead+0x5f/0x81
[] sys_madvise+0x2f7/0x3ec
[] system_call+0x7e/0x83

(apparently waiting for kswapd0 to release iprune_mutex; this path
does not seem to have any FS-related locking, but sys_madvise() has
taken ->mm->mmap_sem for write.)

Other linuxdcpp threads and several ps processes then were stuck
waiting on its ->mm->mmap_sem taken by sys_madvise() above.

So the deadlock seems to be between kswapd0 and mklocatedb.  Note that
vfs_readdir() invoked by mklocatedb has taken i_mutex for the
directory, and kswapd0 is waiting on some i_mutex...

I suspect the following scenario:

1) kswapd0 runs shrink_icache_memory() (and prune_icache(), which
   apparently was inlined there); prune_icache() notices that some
   attribute inode (probably the index bitmap) for the directory is
   unused, marks that attribute inode with I_FREEING and subsequently
   invokes dispose_list() to free marked inodes.

2) mklocatedb invokes sys_readdir() on the directory, which grabs
   i_mutex of the directory and proceeds to call the filesystem
   readdir method - ntfs_readdir(), which then finds that it needs
   the bitmap inode and invokes ntfs_attr_iget() to find it.
   ntfs_attr_iget() proceeds down to find_inode(), which notices that
   the inode has I_FREEING set and goes to __wait_on_freeing_inode().

3) kswapd0 proceeds to call clear_inode() on the attribute inode.
   ntfs_clear_big_inode() calls iput(VFS_I(ni->ext.base_ntfs_ino)) to
   put the base inode (the directory).

4) iput() calls ntfs_put_inode() for the directory.  At this point
   the directory by chance has exactly two references accounted for
   in ->i_count - one from the file descriptor open by mklocatedb,
   another from the attribute inode (which that iput() is dropping
   now), so ntfs_put_inode() goes to the path which releases
   ni->itype.index.bmp_ino - but it needs to grab ->i_mutex for the
   directory, and that mutex is held by mklocatedb.

5) Now kswapd0 is waiting for mklocatedb to release ->i_mutex for the
   directory, and mklocatedb is waiting for kswapd0 to finish freeing
   of the attribute inode - deadlock.

Seems that grabbing i_mutex in ntfs_put_inode() is not safe after all
(and lockdep cannot see this deadlock possibility, because one of
waits is __wait_on_freeing_inode - not a standard locking primitive).

 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

I just finished pulling out a melted IDE flash drive out of a Shuttle 
motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the chassis.  
I note that the 945 chipset in the shuttle PC had some serious
issues recognizing 2 x SATA devices and a IDE device concurrently.   Are 
there known problems with the Linux drivers

with these newer chipsets.

One other disturbing issue was the IDE flash drive was configured (and 
recognized) as /dev/hda during bootup, but when
it got to the root mountint, even with root=/dev/hda set, it still kept 
thinking the drive was at scsi (ATA) device (08,13)

and kept crashing with VFS cannot find root FS errors.

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

SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

I just finished pulling out a melted IDE flash drive out of a Shuttle 
motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the chassis.  
I note that the 945 chipset in the shuttle PC had some serious
issues recognizing 2 x SATA devices and a IDE device concurrently.   Are 
there known problems with the Linux drivers

with these newer chipsets.

One other disturbing issue was the IDE flash drive was configured (and 
recognized) as /dev/hda during bootup, but when
it got to the root mountint, even with root=/dev/hda set, it still kept 
thinking the drive was at scsi (ATA) device (08,13)

and kept crashing with VFS cannot find root FS errors.

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

Re: NTFS deadlock on 2.6.18.6

[Jeff V. Merkey]

Sergey Vlasov wrote:

Yep.  


Hello!

I have encountered a deadlock in the NTFS filesystem on a
2.6.18.6-based kernel (x86_64, CONFIG_SMP set, but the machine has
only one CPU (Athlon64 3200+), no PREEMPT).

The kswapd0 and mklocatedb processes were apparently involved in the
deadlock:

kswapd0   D 810005dea304 0   163  7   164   162 (L-TLB)
81003fd6bcc8 0046 0020 021aaac0
000a 81003fe93820 81003fb157a0 027894893008
000308da 81003fe93a20 8100 810001641670
Call Trace:
[8025e4cf] __mutex_lock_slowpath+0x5d/0x98
[8025e50f] .text.lock.mutex+0x5/0x14
DWARF2 unwinder stuck at .text.lock.mutex+0x5/0x14
Leftover inexact backtrace:
[881b58d2] :ntfs:ntfs_put_inode+0x38/0x7a
[80229987] iput+0x3b/0x84
[881b5a1b] :ntfs:ntfs_clear_big_inode+0x107/0x121
[802215f6] clear_inode+0xc5/0xf6
[8023362a] dispose_list+0x56/0xf6
[8022c47e] shrink_icache_memory+0x1d4/0x203
[8023de38] shrink_slab+0xdc/0x154
[802545e8] kswapd+0x320/0x424
[802921ca] autoremove_wake_function+0x0/0x2e
[80292007] keventd_create_kthread+0x0/0x61
[802542c8] kswapd+0x0/0x424
[80292007] keventd_create_kthread+0x0/0x61
[802312d8] kthread+0xd4/0x107
[80259d60] child_rip+0xa/0x12
[80292007] keventd_create_kthread+0x0/0x61
[80231204] kthread+0x0/0x107
[80259d56] child_rip+0x0/0x12

mklocatedbD 810001e0d400 0  4586   4585 (NOTLB)
810021fd5c48 0082  
000a 81002728f7e0 8048b3c0 02789a2349cf
25c4 81002728f9e0 8100 
Call Trace:
[8024d781] __wait_on_freeing_inode+0x82/0xa0
[8024be5e] find_inode+0x3d/0x6c
[80256b8c] ifind+0x34/0x91
[802cbe81] iget5_locked+0x6c/0x1a9
[881b3aea] :ntfs:ntfs_attr_iget+0x5a/0x5eb
[881ae308] :ntfs:ntfs_readdir+0x3f1/0xce1
[802339d9] vfs_readdir+0x77/0xa9
[80237247] sys_getdents+0x75/0xbd
[80258ed6] system_call+0x7e/0x83
DWARF2 unwinder stuck at system_call+0x7e/0x83
Leftover inexact backtrace:

There were some other processes stuck in the D state, but that seems
to be just a result of the above deadlock:

linuxdcpp D 810001e0d400 0  4912   4910  4914  4911 (NOTLB)
8100283d1bf0 0082 81000181cf38 8100283d1b98
0007 81002ca0c0c0 8048b3c0 0279f4c0a091
00026b39 81002ca0c2c0  
Call Trace:
[8025e4cf] __mutex_lock_slowpath+0x5d/0x98
[8025e50f] .text.lock.mutex+0x5/0x14
DWARF2 unwinder stuck at .text.lock.mutex+0x5/0x14
Leftover inexact backtrace:
[8022c2ea] shrink_icache_memory+0x40/0x203
[8023de38] shrink_slab+0xdc/0x154
[802b0e1c] try_to_free_pages+0x179/0x254
[8020df64] __alloc_pages+0x1a8/0x2a9
[80211077] __do_page_cache_readahead+0x95/0x206
[802af5a1] force_page_cache_readahead+0x5f/0x81
[802b1f06] sys_madvise+0x2f7/0x3ec
[80258ed6] system_call+0x7e/0x83

(apparently waiting for kswapd0 to release iprune_mutex; this path
does not seem to have any FS-related locking, but sys_madvise() has
taken -mm-mmap_sem for write.)

Other linuxdcpp threads and several ps processes then were stuck
waiting on its -mm-mmap_sem taken by sys_madvise() above.

So the deadlock seems to be between kswapd0 and mklocatedb.  Note that
vfs_readdir() invoked by mklocatedb has taken i_mutex for the
directory, and kswapd0 is waiting on some i_mutex...

I suspect the following scenario:

1) kswapd0 runs shrink_icache_memory() (and prune_icache(), which
   apparently was inlined there); prune_icache() notices that some
   attribute inode (probably the index bitmap) for the directory is
   unused, marks that attribute inode with I_FREEING and subsequently
   invokes dispose_list() to free marked inodes.

2) mklocatedb invokes sys_readdir() on the directory, which grabs
   i_mutex of the directory and proceeds to call the filesystem
   readdir method - ntfs_readdir(), which then finds that it needs
   the bitmap inode and invokes ntfs_attr_iget() to find it.
   ntfs_attr_iget() proceeds down to find_inode(), which notices that
   the inode has I_FREEING set and goes to __wait_on_freeing_inode().

3) kswapd0 proceeds to call clear_inode() on the attribute inode.
   ntfs_clear_big_inode() calls iput(VFS_I(ni-ext.base_ntfs_ino)) to
   put the base inode (the directory).

4) iput() calls ntfs_put_inode() for the directory.  At this point
   the directory by chance has exactly two references accounted for
   in -i_count - one from the file descriptor open by mklocatedb,
   another from the attribute inode (which that iput() is dropping
   now), so ntfs_put_inode() goes to the path which releases
   

Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Jeff V. Merkey wrote:

root=/dev/hda2 is what was passed to the kernel from grub.

Jeff



I just finished pulling out a melted IDE flash drive out of a Shuttle 
motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the 
chassis.  I note that the 945 chipset in the shuttle PC had some serious
issues recognizing 2 x SATA devices and a IDE device concurrently.   
Are there known problems with the Linux drivers

with these newer chipsets.

One other disturbing issue was the IDE flash drive was configured (and 
recognized) as /dev/hda during bootup, but when
it got to the root mountint, even with root=/dev/hda set, it still 
kept thinking the drive was at scsi (ATA) device (08,13)

and kept crashing with VFS cannot find root FS errors.

Jeff
-
To unsubscribe from this list: send the line unsubscribe 
linux-kernel in

the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Auke Kok wrote:


Jeff V. Merkey wrote:


Jeff V. Merkey wrote:

root=/dev/hda2 is what was passed to the kernel from grub.

Jeff



I just finished pulling out a melted IDE flash drive out of a 
Shuttle motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the 
chassis.  I note that the 945 chipset in the shuttle PC had some 
serious
issues recognizing 2 x SATA devices and a IDE device concurrently.   
Are there known problems with the Linux drivers

with these newer chipsets.

One other disturbing issue was the IDE flash drive was configured 
(and recognized) as /dev/hda during bootup, but when
it got to the root mountint, even with root=/dev/hda set, it still 
kept thinking the drive was at scsi (ATA) device (08,13)

and kept crashing with VFS cannot find root FS errors.




it sounds like someone switched the BIOS IDE setting from 
ide-compatible/legacy to AHCI or similar, a not uncommon option in the 
sata controllers on those boards.


None of that would explain the melting of anything of course.



Would be if pin 20 were powered for some reason (which it should NOT 
be). 


Jeff



Cheers,

Auke
-
To unsubscribe from this list: send the line unsubscribe 
linux-kernel in

the body of a message 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: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Jeff Garzik wrote:


Jeff V. Merkey wrote:



I just finished pulling out a melted IDE flash drive out of a Shuttle 
motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the 
chassis.  I note that the 945 chipset in the shuttle PC had some serious
issues recognizing 2 x SATA devices and a IDE device concurrently.   
Are there known problems with the Linux drivers

with these newer chipsets.

One other disturbing issue was the IDE flash drive was configured 
(and recognized) as /dev/hda during bootup, but when
it got to the root mountint, even with root=/dev/hda set, it still 
kept thinking the drive was at scsi (ATA) device (08,13)

and kept crashing with VFS cannot find root FS errors.



We have two sets of ATA drivers now, and Intel motherboards support 
bazillion annoying IDE modes, so you will need to provide more info 
than this.


Is the motherboard in combined mode?



Yes.  Enhanced mode is how it is listed in the BIOS.


native mode?  AHCI or RAID mode?


No RAID, just enhanced mode (SATA 3.0 + IDE)

What driver set did you pick?  



Standard build = standard IDE + Intel PIIX + SATA + Intel ICP

is drivers/ide built in, modular, or disabled?  is drivers/ata built 
in, modular, or disabled?


built in in all cases.



The cannot-find-root-FS errors are definitely caused by driver and/or 
initrd misconfiguration.  The melted flash, I dunno, maybe you managed 
to get two drivers fighting over the same hardware.


No.  Seems related to the chipset problems.  If I say root=/dev/hda2 I 
have better not be getting errors claiming device 08:13 could not mount 
as root.  memory corruption?


The melted flash seems power related (like pin 20 was live for some 
reason on a standard IDE).


Jeff



Jeff






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

Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Lennart Sorensen wrote:


On Tue, Jan 09, 2007 at 01:46:42PM -0700, Jeff V. Merkey wrote:
 

I just finished pulling out a melted IDE flash drive out of a Shuttle 
motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the chassis.  
I note that the 945 chipset in the shuttle PC had some serious
issues recognizing 2 x SATA devices and a IDE device concurrently.   Are 
there known problems with the Linux drivers

with these newer chipsets.
   



Had the drive ever been used in any other machine?  



Yes, on a SuperMicro X6DHE-G2 Xeon motherboard -- worked fine.


Had any ide device
ever been used in this machine before?  


Yes. external cabled CDROM Drive seems to work.

Jeff


It really sounds like a hardware
problem, since I can't think of anything software could do to make that
kind of current go through the flash drive.

I remember seeing the controller chip on a 730MB quantum scsi drive
start to glow red many years ago, just before the drive stopped
responding to the system (and I turned off the power).  Hardware does
fail.  It almost never has anything to do with software.

--
Len Sorensen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Jeff V. Merkey]

Jeff Garzik wrote:


Jeff V. Merkey wrote:


Jeff Garzik wrote:


Jeff V. Merkey wrote:



I just finished pulling out a melted IDE flash drive out of a 
Shuttle motherboard with the intel 945 chipset which claims to support

SATA and IDE drives concurrently under Linux 2.6.18.

The chip worked for about 30 seconds before liquifying in the 
chassis.  I note that the 945 chipset in the shuttle PC had some 
serious
issues recognizing 2 x SATA devices and a IDE device 
concurrently.   Are there known problems with the Linux drivers

with these newer chipsets.

One other disturbing issue was the IDE flash drive was configured 
(and recognized) as /dev/hda during bootup, but when
it got to the root mountint, even with root=/dev/hda set, it still 
kept thinking the drive was at scsi (ATA) device (08,13)

and kept crashing with VFS cannot find root FS errors.




We have two sets of ATA drivers now, and Intel motherboards support 
bazillion annoying IDE modes, so you will need to provide more info 
than this.


Is the motherboard in combined mode?




Yes.  Enhanced mode is how it is listed in the BIOS.



Combined mode is a technical term.  Judging from your answers, you are 
not using combined mode.




native mode?  AHCI or RAID mode?



No RAID, just enhanced mode (SATA 3.0 + IDE)



Judging from your answers, you are not in AHCI mode.

Side note:  You should use AHCI if available.  Emulating a PATA 
interface for SATA devices is error prone [in the silicon].  AHCI is 
native SATA, enhanced mode is not.



AHCI It is.   


Jeff




The cannot-find-root-FS errors are definitely caused by driver 
and/or initrd misconfiguration.  The melted flash, I dunno, maybe 
you managed to get two drivers fighting over the same hardware.



No.  Seems related to the chipset problems.  If I say 
root=/dev/hda2 I have better not be getting errors claiming device 
08:13 could not mount as root.  memory corruption?



If the kernel cannot mount the requested root= disk, it tries the 
default that is encoded into the vmlinuz image at build time, which is 
probably 08:13.



The melted flash seems power related (like pin 20 was live for some 
reason on a standard IDE).



Probably, otherwise we would have many more reports like this than 
just yours.


Jeff





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

Re: GPL only modules

[Jeff V. Merkey]

Linus Torvalds wrote:


On Mon, 18 Dec 2006, Alexandre Oliva wrote:
 


In other words, in the GPL, "Program" does NOT mean "binary". Never has.
 


Agreed.  So what?  How does this relate with the point above?

The binary is a Program, as much as the sources are a Program.  Both
forms are subject to copyright law and to the license, in spite of
http://www.fsfla.org/?q=en/node/128#1
   



Here's how it relates:
- if a program is not a "derived work" of the C library, then it's not 
  "the program" as defined by the GPLv2 AT ALL.


In other words, it doesn't matter ONE WHIT whether you use "ld --static" 
or "ld" or "mkisofs" - if the program isn't (by copyright law) derived 
from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY 
AFFECT THE RESULTING BINARY.


And I'm simply claiming that a binary doesn't become "derived from" by any 
action of linking.


Even if you link using "ld", even if it's static, the binary is not 
"derived from". It's an aggregate.


"Derivation" has nothing to do with "linking". Either it's derived or it 
is not, and "linking" simply doesn't matter. It doesn't matter whether 
it's static or dynamic. That's a detail that simply doesn't have anythign 
at all to do with "derivative work".


THAT is my point. 

Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, 
static linking aggregates the library with the other program in the same 
binary. There's no question about that. And that _does_ have meaning from 
a copyright law angle, since if you don't have permission to ship 
aggregate works under the license, then you can't ship said binary. It's 
just a non-issue in the specific case of the GPLv2.


In the presense of dynamic linking the binary isn't even an aggregate 
work.


THAT is the difference between static and dynamic. A simple command line 
flag to the linker shouldn't really reasonably be considered to change 
"derivation" status.


Either something is derived, or it's not. If it's derived, "ld", 
"mkisofs", "putting them close together" or "shipping them on totally 
separate CD's" doesn't matter. It's still derived.


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/

 


Yep. We love you linus, keep going.

Also, we are taking over SCO's office space after the first of the year, 
since they have no one left. We will try to get that annoying eyesore of 
a sign taken off the building as soon as possible. They moved to 
Holliday, UT (or are moving there at present).


:-)

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Eric W. Biederman wrote:


Things we can say without being hypocrites and without getting into
legal theory:

Kernel modules without source, or that don't have a GPL compatible
license are inconsiderate and rude.
 


??


Please don't be rude.
 


???

J


Eric

 



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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Eric W. Biederman wrote:


Things we can say without being hypocrites and without getting into
legal theory:

Kernel modules without source, or that don't have a GPL compatible
license are inconsiderate and rude.
 


??


Please don't be rude.
 


???

J


Eric

 



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

Re: GPL only modules

[Jeff V. Merkey]

Linus Torvalds wrote:


On Mon, 18 Dec 2006, Alexandre Oliva wrote:
 


In other words, in the GPL, Program does NOT mean binary. Never has.
 


Agreed.  So what?  How does this relate with the point above?

The binary is a Program, as much as the sources are a Program.  Both
forms are subject to copyright law and to the license, in spite of
http://www.fsfla.org/?q=en/node/128#1
   



Here's how it relates:
- if a program is not a derived work of the C library, then it's not 
  the program as defined by the GPLv2 AT ALL.


In other words, it doesn't matter ONE WHIT whether you use ld --static 
or ld or mkisofs - if the program isn't (by copyright law) derived 
from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY 
AFFECT THE RESULTING BINARY.


And I'm simply claiming that a binary doesn't become derived from by any 
action of linking.


Even if you link using ld, even if it's static, the binary is not 
derived from. It's an aggregate.


Derivation has nothing to do with linking. Either it's derived or it 
is not, and linking simply doesn't matter. It doesn't matter whether 
it's static or dynamic. That's a detail that simply doesn't have anythign 
at all to do with derivative work.


THAT is my point. 

Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, 
static linking aggregates the library with the other program in the same 
binary. There's no question about that. And that _does_ have meaning from 
a copyright law angle, since if you don't have permission to ship 
aggregate works under the license, then you can't ship said binary. It's 
just a non-issue in the specific case of the GPLv2.


In the presense of dynamic linking the binary isn't even an aggregate 
work.


THAT is the difference between static and dynamic. A simple command line 
flag to the linker shouldn't really reasonably be considered to change 
derivation status.


Either something is derived, or it's not. If it's derived, ld, 
mkisofs, putting them close together or shipping them on totally 
separate CD's doesn't matter. It's still derived.


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/

 


Yep. We love you linus, keep going.

Also, we are taking over SCO's office space after the first of the year, 
since they have no one left. We will try to get that annoying eyesore of 
a sign taken off the building as soon as possible. They moved to 
Holliday, UT (or are moving there at present).


:-)

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

Re: [ANNOUNCE] Open Source Protocol Reconstruction Project for Linux

[Jeff V. Merkey]

Jeff V. Merkey wrote:

Corrected URL.

http://sourceforge.net/projects/data-echo

Jeff



We have open sourced this project for our Linux based appliances and 
file systems.  Anyone from Linux
who wants to help port the program from Windows to Linux is welcome.  
The program supports
all native Linux forensics applications and formats.  The program 
reconsutructs web session and

email, and we are adding FTP, P2P, and other Linux kernel protocols.
Jeff

 


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

[ANNOUNCE] Open Source Protocol Reconstruction Project for Linux

[Jeff V. Merkey]

We have open sourced this project for our Linux based appliances and 
file systems.  Anyone from Linux
who wants to help port the program from Windows to Linux is welcome.  
The program supports
all native Linux forensics applications and formats.  The program 
reconsutructs web session and
email, and we are adding FTP, P2P, and other Linux kernel protocols. 


Jeff

LINDON, Utah, Dec. 15 /PRNewswire/ -- Solera Networks, Inc., the
technology leader in network packet record and playback appliances, today
announced that source code for DataEcho, a web session reconstruction
application, will be made available under the GNU General Public License.
The company has established a community website at
http://sourceforge.net/projects/data-echo. Source code and Windows
installers are available for download now.
   DataEcho reconstructs historical web browsing and email traffic from
captured network packets, for monitoring insider security threats and
policy compliance. It is a useful adjunct to network protocol analyzers
such as Sniffer(TM) or WireShark.
   



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

[ANNOUNCE] Open Source Protocol Reconstruction Project for Linux

[Jeff V. Merkey]

We have open sourced this project for our Linux based appliances and 
file systems.  Anyone from Linux
who wants to help port the program from Windows to Linux is welcome.  
The program supports
all native Linux forensics applications and formats.  The program 
reconsutructs web session and
email, and we are adding FTP, P2P, and other Linux kernel protocols. 


Jeff

LINDON, Utah, Dec. 15 /PRNewswire/ -- Solera Networks, Inc., the
technology leader in network packet record and playback appliances, today
announced that source code for DataEcho, a web session reconstruction
application, will be made available under the GNU General Public License.
The company has established a community website at
http://sourceforge.net/projects/data-echo. Source code and Windows
installers are available for download now.
   DataEcho reconstructs historical web browsing and email traffic from
captured network packets, for monitoring insider security threats and
policy compliance. It is a useful adjunct to network protocol analyzers
such as Sniffer(TM) or WireShark.
   



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

Re: [ANNOUNCE] Open Source Protocol Reconstruction Project for Linux

[Jeff V. Merkey]

Jeff V. Merkey wrote:

Corrected URL.

http://sourceforge.net/projects/data-echo

Jeff



We have open sourced this project for our Linux based appliances and 
file systems.  Anyone from Linux
who wants to help port the program from Windows to Linux is welcome.  
The program supports
all native Linux forensics applications and formats.  The program 
reconsutructs web session and

email, and we are adding FTP, P2P, and other Linux kernel protocols.
Jeff

 


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

execv() problems with busybox on 2.6.18

[Jeff V. Merkey]

/etc/init.d/rcS script execution fails with busybox on 2.6.18.  Seems 
ldlinux.so related.


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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

This whole effort is pointless.  This is the same kind of crap MICROSOFT 
DOES to create incompatibilities
DELIBERATELY.  The code is either FREE or its NOT FREE.If the code 
is FREE then let it be.  You can put whatever
you want in the code -- I will remove any such constructs, just like I 
remove them frm Red Hat's releases when they put

in the same kind of deliberate breakage for anti-competitive reasons.

You can go and yell at Novell too, since they do the SAME THING with 
their releases and mix their modules with Linux.


All someone has to do or say is.

"... I did not ever accept the GPL license with the FREE code I was 
given.  They said the code was FREE, and I took them

at their word. .."

FREE implies a transfer of ownsership and you also have to contend with 
the Doctrine of Estoppel.  i.e. if someone
has been using the code for over two years, and you have not brought a 
cause of action, you are BARRED from doing so
under the Doctrine of Estoppel and statute of limitations. 


Here's what that means so you can look it up:

http://en.wikigadugi.org/wiki/Estoppel

What Linus argued is that FREE means just that. 


Jeff


Scott Preece wrote:


On 12/14/06, Chris Wedgwood <[EMAIL PROTECTED]> wrote:


On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:

> Please don't use that name, it strikes me as much more confusing
> than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
> convey what it means, either.

Calling internal symbols _INTERNAL is confusing?



I think it's the combination of "INTERNAL" and "EXPORT" that seems
contradictory - "If it's internal, why are you exporting it?"

I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would make the
meaning clearer, but I don't really think the gain is worth the pain.
Anybody using kernel interfaces ought to be able to figure it out.



But those symbols aren't, they're about internal interfaces that might
change.



Folks who think this is likely to make a difference in court might
want to look at
 for a
litany of court cases that have rejected infringement claims where a
much sterner effort had been made to hide or block use of interfaces.
The article claims that courts have increasingly found that
interfacing your code to an existing work is not infringement,
regardless of what you have to work around to do it.

Of course, that's one author's reading of the case law and I'm sure
there are others who disagree, but it's something you'd want to keep
in mind in calculating the expected value of a suit...

scott
-
To unsubscribe from this list: send the line "unsubscribe 
linux-kernel" in

the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Linus Torvalds wrote:


On Thu, 14 Dec 2006, Jeff V. Merkey wrote:
 


Yeah, like that one.  WITH THE POLITICAL AGENDA CODE REMOVED.
   



No. That's really a purely technical thing.


 

I'm not certain I understand what you mean here. Nasty messages using 
the word "taint" is purely subjective.
(as is your opinion or anyone else's about the use of the word, 
including my opinion). Based upon the way the GPL is worded, "taint"
actually goes the other way in legal circles when corporate attorneys 
talk about using GPL code with non-GPL code.


i.e. "... If we use that linux code it will TAINT our development 
process and CONTAMINATE and POULLTE our proprietary
development efforts with GPL code and we do not know the IP sources of 
such code...".


You should change it to "non-GPL" rather than "tainted" since the use of 
this word is actionable and inaccruate of reality.
Free GPL code is what it is. The GPL is the only thing that "taints" IP. 
The use of the word is reversed. Also Linus, we do
open source and promote certain projects outside of the Linux Kernel -- 
and we fully support the GPL.


You can still do whatever you want, but people who support the resulting 
mess know that they shouldn't.



BULLSHIT. I diagree and you are talking out of both sides of your mouth.

:-)

Jeff


Linus

 



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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Martin J. Bligh wrote:


Jeff V. Merkey wrote:



Again, I agree with EVERY statement Linus made here. We operate 
exactly as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of 
affected kernel code
(albiet the code resembles what Linus describes as a "skeleton 
driver") and our proprietary
non derived code we sell with our appliances. 




Yeah, like this one?



Yeah, like that one.  WITH THE POLITICAL AGENDA CODE REMOVED.

Jeff





ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch 



@@ -1316,8 +1316,8 @@

mod->license_gplok = license_is_gpl_compatible(license);
if (!mod->license_gplok && !(tainted & 
TAINT_PROPRIETARY_MODULE)) {
-   printk(KERN_WARNING "%s: module license '%s' taints 
kernel.\n",

-  mod->name, license);
+// printk(KERN_WARNING "%s: module license '%s' taints 
kernel.\n",

+//mod->name, license);
add_taint(TAINT_PROPRIETARY_MODULE);
}
 }
@@ -1691,10 +1691,10 @@
/* Set up license info based on the info section */
set_license(mod, get_modinfo(sechdrs, infoindex, "license"));

-   if (strcmp(mod->name, "ndiswrapper") == 0)
-   add_taint(TAINT_PROPRIETARY_MODULE);
-   if (strcmp(mod->name, "driverloader") == 0)
-   add_taint(TAINT_PROPRIETARY_MODULE);
+// if (strcmp(mod->name, "ndiswrapper") == 0)
+// add_taint(TAINT_PROPRIETARY_MODULE);
+// if (strcmp(mod->name, "driverloader") == 0)
+// add_taint(TAINT_PROPRIETARY_MODULE);

/* Set up MODINFO_ATTR fields */
setup_modinfo(mod, sechdrs, infoindex);




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Again, I agree with EVERY statement Linus made here. We operate exactly 
as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of 
affected kernel code
(albiet the code resembles what Linus describes as a "skeleton driver") 
and our proprietary
non derived code we sell with our appliances. He is right, everyone else 
should just accept

it and get on with life or cry linus a river.

Jeff

Linus Torvalds wrote:


On Thu, 14 Dec 2006, David Woodhouse wrote:
 


But I would ask that they honour the licence on the code I release, and
perhaps more importantly on the code I import from other GPL sources.
   



This is a total non-argument, and it doesn't get any betetr by being 
mindlessly repeated over and over and over again.


The license on the code you released talked about "derived works".

Not "everything I want to".

If a module owner can argue successfully in a court of law that a binary 
driver isn't a derived work, then the GPL simply DOES NOT COVER IT!


In other words, people CAN "honor the license" and still not be required 
to put their code under the GPL.


And no, including one header file in order to compile against something 
does not automatically make something a "derived work". It may, or it may 
not. It really isn't up to you to decide whether it does (and notice how 
I'm not saying that it's up to _me_ either!).


For example, all the same people who clamor for free software get 
absolutely RABID about "fair use". Guess what "fair use" actually MEANS? 

Think about it for a moment. It expressly _limits_ the right of copyright 
authors to claim "derived work". So if you argue that anything that ever 
includes your header file (but none of your code) and compiles against it 
is a "derived work", then you are basically very close to arguing that 
"fair use" does not exist.


Do you really want to argue that "everything that has touched anything 
copyrighted AT ALL is a derived work"? Do you feel lucky, punk?


THAT is why I think this discussion is so hypocritical. Either you accept 
that "fair use" and copyrights aren't black-and-white, or you don't.


If you think this is a black-and-white "copyright owners have all the 
rights", then you're standing with the RIAA's and the MPAA's of the world.


Me, personally, I think the RIAA and the MPAA is a shithouse. They are 
immoral. But guess what? They are immoral exactly _because_ they think 
that they automatically own ALL the rights, just because they own the 
copyright.


That is what it boils down to: copyright doesn't really give you "absolute 
power". This is why I have been _consistently_ arguing that we're not 
about "black and white" or "good against evil". It simply isn't that 
simple.


I don't like binary modules. I refuse to support them, and if it turns out 
that the module was written using Linux code, and just for Linux, I htink 
that's a _clear_ copyright violation, and that binary module is obviously 
a license violation.


But if the module was written for other systems, and just ported to Linux, 
and not using our code, then it's very much debatable whether it's 
actually a "derived work". Interfaces don't make "derived works" per se. 

Now, is it something you could sue people over? Sure. I actually do 
believe that it's very possible that a judge _would_ consider such a 
module a derived work, and you can sue people. It probably depends on 
circumstances too. 


But don't you see the problem with a black-and-white technical measure?

Don't you see the problem with the DMCA and the DVD encryption? 

Those kinds of things REMOVE the "reasonable thought" from the equation, 
and turn a gradual process into a sharp "right or wrong" situation. AND 
THAT IS WRONG. We simply do not LIVE in a world that is black and white.


So if you think somebody violates your copyright, send them a C letter, 
and eventually take them to court. It's been done. Companies that mis-used 
the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing. 
I'm not arguing against that at all. What I'm arguing against is the 
"blind belief" that you or I have the right to tell people what to do, 
just because we own copyrights.


It's not a blind belief that I'm willing to subscribe to. Exactly because 
I have _seen_ what that blind belief results in - crap like the DMCA and 
the RIAA lawsuits.


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/

 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Need to enable caches in SMP ? (was Kernel 2.6 SMP very slow with ServerWorks LE Chipset)

[Jeff V. Merkey]

Alan wrote:

As per Alan's suggestion I decompressed the kernel source tree with the 
processes pegged to one CPU then the other, and as he predicted it took 
vastly longer on one CPU than the other, but I don't know what that 
implies, or how to fix it.
   




From the timing it sounds like one processor cache is disabled which is a

little peculiar to say the least.

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/

 


enable the L1 cache in the processor. BIOS settings, no doubt.

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

Re: Need to enable caches in SMP ? (was Kernel 2.6 SMP very slow with ServerWorks LE Chipset)

[Jeff V. Merkey]

Alan wrote:

As per Alan's suggestion I decompressed the kernel source tree with the 
processes pegged to one CPU then the other, and as he predicted it took 
vastly longer on one CPU than the other, but I don't know what that 
implies, or how to fix it.
   




From the timing it sounds like one processor cache is disabled which is a

little peculiar to say the least.

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/

 


enable the L1 cache in the processor. BIOS settings, no doubt.

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Again, I agree with EVERY statement Linus made here. We operate exactly 
as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of 
affected kernel code
(albiet the code resembles what Linus describes as a skeleton driver) 
and our proprietary
non derived code we sell with our appliances. He is right, everyone else 
should just accept

it and get on with life or cry linus a river.

Jeff

Linus Torvalds wrote:


On Thu, 14 Dec 2006, David Woodhouse wrote:
 


But I would ask that they honour the licence on the code I release, and
perhaps more importantly on the code I import from other GPL sources.
   



This is a total non-argument, and it doesn't get any betetr by being 
mindlessly repeated over and over and over again.


The license on the code you released talked about derived works.

Not everything I want to.

If a module owner can argue successfully in a court of law that a binary 
driver isn't a derived work, then the GPL simply DOES NOT COVER IT!


In other words, people CAN honor the license and still not be required 
to put their code under the GPL.


And no, including one header file in order to compile against something 
does not automatically make something a derived work. It may, or it may 
not. It really isn't up to you to decide whether it does (and notice how 
I'm not saying that it's up to _me_ either!).


For example, all the same people who clamor for free software get 
absolutely RABID about fair use. Guess what fair use actually MEANS? 

Think about it for a moment. It expressly _limits_ the right of copyright 
authors to claim derived work. So if you argue that anything that ever 
includes your header file (but none of your code) and compiles against it 
is a derived work, then you are basically very close to arguing that 
fair use does not exist.


Do you really want to argue that everything that has touched anything 
copyrighted AT ALL is a derived work? Do you feel lucky, punk?


THAT is why I think this discussion is so hypocritical. Either you accept 
that fair use and copyrights aren't black-and-white, or you don't.


If you think this is a black-and-white copyright owners have all the 
rights, then you're standing with the RIAA's and the MPAA's of the world.


Me, personally, I think the RIAA and the MPAA is a shithouse. They are 
immoral. But guess what? They are immoral exactly _because_ they think 
that they automatically own ALL the rights, just because they own the 
copyright.


That is what it boils down to: copyright doesn't really give you absolute 
power. This is why I have been _consistently_ arguing that we're not 
about black and white or good against evil. It simply isn't that 
simple.


I don't like binary modules. I refuse to support them, and if it turns out 
that the module was written using Linux code, and just for Linux, I htink 
that's a _clear_ copyright violation, and that binary module is obviously 
a license violation.


But if the module was written for other systems, and just ported to Linux, 
and not using our code, then it's very much debatable whether it's 
actually a derived work. Interfaces don't make derived works per se. 

Now, is it something you could sue people over? Sure. I actually do 
believe that it's very possible that a judge _would_ consider such a 
module a derived work, and you can sue people. It probably depends on 
circumstances too. 


But don't you see the problem with a black-and-white technical measure?

Don't you see the problem with the DMCA and the DVD encryption? 

Those kinds of things REMOVE the reasonable thought from the equation, 
and turn a gradual process into a sharp right or wrong situation. AND 
THAT IS WRONG. We simply do not LIVE in a world that is black and white.


So if you think somebody violates your copyright, send them a CD letter, 
and eventually take them to court. It's been done. Companies that mis-used 
the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing. 
I'm not arguing against that at all. What I'm arguing against is the 
blind belief that you or I have the right to tell people what to do, 
just because we own copyrights.


It's not a blind belief that I'm willing to subscribe to. Exactly because 
I have _seen_ what that blind belief results in - crap like the DMCA and 
the RIAA lawsuits.


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/

 



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Martin J. Bligh wrote:


Jeff V. Merkey wrote:



Again, I agree with EVERY statement Linus made here. We operate 
exactly as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of 
affected kernel code
(albiet the code resembles what Linus describes as a skeleton 
driver) and our proprietary
non derived code we sell with our appliances. 




Yeah, like this one?



Yeah, like that one.  WITH THE POLITICAL AGENDA CODE REMOVED.

Jeff





ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch 



@@ -1316,8 +1316,8 @@

mod-license_gplok = license_is_gpl_compatible(license);
if (!mod-license_gplok  !(tainted  
TAINT_PROPRIETARY_MODULE)) {
-   printk(KERN_WARNING %s: module license '%s' taints 
kernel.\n,

-  mod-name, license);
+// printk(KERN_WARNING %s: module license '%s' taints 
kernel.\n,

+//mod-name, license);
add_taint(TAINT_PROPRIETARY_MODULE);
}
 }
@@ -1691,10 +1691,10 @@
/* Set up license info based on the info section */
set_license(mod, get_modinfo(sechdrs, infoindex, license));

-   if (strcmp(mod-name, ndiswrapper) == 0)
-   add_taint(TAINT_PROPRIETARY_MODULE);
-   if (strcmp(mod-name, driverloader) == 0)
-   add_taint(TAINT_PROPRIETARY_MODULE);
+// if (strcmp(mod-name, ndiswrapper) == 0)
+// add_taint(TAINT_PROPRIETARY_MODULE);
+// if (strcmp(mod-name, driverloader) == 0)
+// add_taint(TAINT_PROPRIETARY_MODULE);

/* Set up MODINFO_ATTR fields */
setup_modinfo(mod, sechdrs, infoindex);




-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

Linus Torvalds wrote:


On Thu, 14 Dec 2006, Jeff V. Merkey wrote:
 


Yeah, like that one.  WITH THE POLITICAL AGENDA CODE REMOVED.
   



No. That's really a purely technical thing.


 

I'm not certain I understand what you mean here. Nasty messages using 
the word taint is purely subjective.
(as is your opinion or anyone else's about the use of the word, 
including my opinion). Based upon the way the GPL is worded, taint
actually goes the other way in legal circles when corporate attorneys 
talk about using GPL code with non-GPL code.


i.e. ... If we use that linux code it will TAINT our development 
process and CONTAMINATE and POULLTE our proprietary
development efforts with GPL code and we do not know the IP sources of 
such code


You should change it to non-GPL rather than tainted since the use of 
this word is actionable and inaccruate of reality.
Free GPL code is what it is. The GPL is the only thing that taints IP. 
The use of the word is reversed. Also Linus, we do
open source and promote certain projects outside of the Linux Kernel -- 
and we fully support the GPL.


You can still do whatever you want, but people who support the resulting 
mess know that they shouldn't.



BULLSHIT. I diagree and you are talking out of both sides of your mouth.

:-)

Jeff


Linus

 



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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

This whole effort is pointless.  This is the same kind of crap MICROSOFT 
DOES to create incompatibilities
DELIBERATELY.  The code is either FREE or its NOT FREE.If the code 
is FREE then let it be.  You can put whatever
you want in the code -- I will remove any such constructs, just like I 
remove them frm Red Hat's releases when they put

in the same kind of deliberate breakage for anti-competitive reasons.

You can go and yell at Novell too, since they do the SAME THING with 
their releases and mix their modules with Linux.


All someone has to do or say is.

... I did not ever accept the GPL license with the FREE code I was 
given.  They said the code was FREE, and I took them

at their word. ..

FREE implies a transfer of ownsership and you also have to contend with 
the Doctrine of Estoppel.  i.e. if someone
has been using the code for over two years, and you have not brought a 
cause of action, you are BARRED from doing so
under the Doctrine of Estoppel and statute of limitations. 


Here's what that means so you can look it up:

http://en.wikigadugi.org/wiki/Estoppel

What Linus argued is that FREE means just that. 


Jeff


Scott Preece wrote:


On 12/14/06, Chris Wedgwood [EMAIL PROTECTED] wrote:


On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:

 Please don't use that name, it strikes me as much more confusing
 than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
 convey what it means, either.

Calling internal symbols _INTERNAL is confusing?



I think it's the combination of INTERNAL and EXPORT that seems
contradictory - If it's internal, why are you exporting it?

I think EXPORT_SYMBOL_GPL_ONLY or ...ONLY UNDER_GPL would make the
meaning clearer, but I don't really think the gain is worth the pain.
Anybody using kernel interfaces ought to be able to figure it out.



But those symbols aren't, they're about internal interfaces that might
change.



Folks who think this is likely to make a difference in court might
want to look at
http:www.linuxworld.com/news/2006/120806-closed-modules2.html for a
litany of court cases that have rejected infringement claims where a
much sterner effort had been made to hide or block use of interfaces.
The article claims that courts have increasingly found that
interfacing your code to an existing work is not infringement,
regardless of what you have to work around to do it.

Of course, that's one author's reading of the case law and I'm sure
there are others who disagree, but it's something you'd want to keep
in mind in calculating the expected value of a suit...

scott
-
To unsubscribe from this list: send the line unsubscribe 
linux-kernel in

the body of a message 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/

execv() problems with busybox on 2.6.18

[Jeff V. Merkey]

/etc/init.d/rcS script execution fails with busybox on 2.6.18.  Seems 
ldlinux.so related.


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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)

[Jeff V. Merkey]

Phillip Susi wrote:

If your comment here was in reply to my general comment about resierfs 
stability and not the specific hibernation issue the OP was having, 
please edit the quote down to just that portion instead of quoting the 
entire message, including the quotes it was replying to.


I wonder what kernel version you are running.  Since you mention rpms, 
I will assume you are running redhat, and likely are using a rather 
old kernel.


The system I see these problems on is a Suse 10.0.  I STORE RPM's on a 
Reiser FS system on this server as an ftp server.  It's the server at 
ftp.soleranetworks.com.  I run 2.6.18 and 2.6.19 for our development at 
present for our appliances, we do not ship Suse.  Our appliances use 
RedHat ES4 and FC6.  We were testing Suse out as an FTP server -- its 
not very stable.  The Suse system with ReiserFS is running 2.6.13.


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

Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)

[Jeff V. Merkey]

Phillip Susi wrote:


Andrew Robinson wrote:


Now I am confused on what may be the cause of the corruption. Could it
have been just a ReiserFS problem (I will be using Ext3 or JSF on my
next rebuild I think after reading some reviews on the ReiserFS and
this recent experience).



I have been running reiser on  my home machine and a server at work 
for a year now without incident.  There were some bugs a few years 
back but it seems to be in good working order these days.



I'm not sure if it could be a SATA_NV driver problem, a hibernate
problem, or a ReiserFS problem or a combination of the above. For
hibernation, I had the resume2 kernel boot option set as /dev/sda1 (my
swap partition). I do not have suspend2 installed though, I have been
relying on its fallback settings to ususpend or sysfs (not sure which
one is actually executed).



Sounds like your hibernation corrupted the disk, but without more 
specifics, this is just educated guesswork.


No.  I still see corruption on Suse with Reiser FS.  It's always very 
subtle (like the last block of a file doesn;t get copied or gets
corrupted.   We have been running our ftp server on ReiserFS, and as 
soon as I can get it moved back to ext3, we are doing so.
We have had a lot of issues with corrupted RPM files and builds on 
ReiserFS.  If you can get the files copied to the
FS ok, they seem to stay that way.  moving a lot of data with recursive 
copies seems troublesome and some of the files

seem to get the ends clipped off of them.

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

Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)

[Jeff V. Merkey]

Phillip Susi wrote:


Andrew Robinson wrote:


Now I am confused on what may be the cause of the corruption. Could it
have been just a ReiserFS problem (I will be using Ext3 or JSF on my
next rebuild I think after reading some reviews on the ReiserFS and
this recent experience).



I have been running reiser on  my home machine and a server at work 
for a year now without incident.  There were some bugs a few years 
back but it seems to be in good working order these days.



I'm not sure if it could be a SATA_NV driver problem, a hibernate
problem, or a ReiserFS problem or a combination of the above. For
hibernation, I had the resume2 kernel boot option set as /dev/sda1 (my
swap partition). I do not have suspend2 installed though, I have been
relying on its fallback settings to ususpend or sysfs (not sure which
one is actually executed).



Sounds like your hibernation corrupted the disk, but without more 
specifics, this is just educated guesswork.


No.  I still see corruption on Suse with Reiser FS.  It's always very 
subtle (like the last block of a file doesn;t get copied or gets
corrupted.   We have been running our ftp server on ReiserFS, and as 
soon as I can get it moved back to ext3, we are doing so.
We have had a lot of issues with corrupted RPM files and builds on 
ReiserFS.  If you can get the files copied to the
FS ok, they seem to stay that way.  moving a lot of data with recursive 
copies seems troublesome and some of the files

seem to get the ends clipped off of them.

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

Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)

[Jeff V. Merkey]

Phillip Susi wrote:

If your comment here was in reply to my general comment about resierfs 
stability and not the specific hibernation issue the OP was having, 
please edit the quote down to just that portion instead of quoting the 
entire message, including the quotes it was replying to.


I wonder what kernel version you are running.  Since you mention rpms, 
I will assume you are running redhat, and likely are using a rather 
old kernel.


The system I see these problems on is a Suse 10.0.  I STORE RPM's on a 
Reiser FS system on this server as an ftp server.  It's the server at 
ftp.soleranetworks.com.  I run 2.6.18 and 2.6.19 for our development at 
present for our appliances, we do not ship Suse.  Our appliances use 
RedHat ES4 and FC6.  We were testing Suse out as an FTP server -- its 
not very stable.  The Suse system with ReiserFS is running 2.6.13.


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

[ANNOUNCE] DSFS File System Kernel Patches posted for kernel 2.6.18

[Jeff V. Merkey]

Patches against kernel 2.6.18 and support for Fedora Core 6 which 
contains the affected GPL portions of supporting code for the proprietary

DSFS Forensic File System have been posted to:

ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/

This release is posted  here in compliance with the GPL license 
regarding modifications to the linux kernel
core code sections.  This patch DOES NOT contain the DSFS file system 
code, but only contains those portions of
the Linux kernel which have been modified and are required to be 
released under the GPL.


Jeff V. Merkey
Chief Scientist
Solera Networks, Inc.


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

[ANNOUNCE] DSFS File System Kernel Patches posted for kernel 2.6.18

[Jeff V. Merkey]

Patches against kernel 2.6.18 and support for Fedora Core 6 which 
contains the affected GPL portions of supporting code for the proprietary

DSFS Forensic File System have been posted to:

ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/

This release is posted  here in compliance with the GPL license 
regarding modifications to the linux kernel
core code sections.  This patch DOES NOT contain the DSFS file system 
code, but only contains those portions of
the Linux kernel which have been modified and are required to be 
released under the GPL.


Jeff V. Merkey
Chief Scientist
Solera Networks, Inc.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: scst support for kernels above 2.6.15

[Jeff V. Merkey]

Vladislav Bolkhovitin wrote:

The code is not at sourceforge on your project site with these updates 
for 2.6.18. Where is the 2.6.18 version currently hosted?
   



It is there on http://sourceforge.net/projects/scst
(http://scst.sourceforge.net/). See 0.9.5 release version as well as
development code in the SVN.

Vlad

 

Released 12/01/2006 - now I know why I missed it there -- you just 
released it. :-)



P.S. I will post this to the scsi list in the future.
   



For scst only questions scst-devel on lists.sourceforge.net would be better.

 

Ok. Thanks for the prompt response. I will be testing your code today at 
4Gb. Let you know if it works.


:-)

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

Re: scst support for kernels above 2.6.15

[Jeff V. Merkey]

Vladislav Bolkhovitin wrote:


Jeff V. Merkey wrote:
 

I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18 
and above.  Is scst and target support for FC-AL going to
remain supported and/or merged at some point?   If so, what is planned 
for scst support for later kernels?
   



Jeff, I don't know why you ask here and not in scst-devel mailing list,
but SCST has beed updated to use scsi_execute_async() instead of
scsi_do_req() in 2.6.18+ for quite a while. Yes, scst is going to be
supported in the future.

Vlad
 

The code is not at sourceforge on your project site with these updates 
for 2.6.18. Where is the 2.6.18 version currently hosted?


P.S. I will post this to the scsi list in the future.

Thanks

Jeff

 


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

   




 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: scst support for kernels above 2.6.15

[Jeff V. Merkey]

Vladislav Bolkhovitin wrote:


Jeff V. Merkey wrote:
 

I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18 
and above.  Is scst and target support for FC-AL going to
remain supported and/or merged at some point?   If so, what is planned 
for scst support for later kernels?
   



Jeff, I don't know why you ask here and not in scst-devel mailing list,
but SCST has beed updated to use scsi_execute_async() instead of
scsi_do_req() in 2.6.18+ for quite a while. Yes, scst is going to be
supported in the future.

Vlad
 

The code is not at sourceforge on your project site with these updates 
for 2.6.18. Where is the 2.6.18 version currently hosted?


P.S. I will post this to the scsi list in the future.

Thanks

Jeff

 


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

   




 



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: scst support for kernels above 2.6.15

[Jeff V. Merkey]

Vladislav Bolkhovitin wrote:

The code is not at sourceforge on your project site with these updates 
for 2.6.18. Where is the 2.6.18 version currently hosted?
   



It is there on http://sourceforge.net/projects/scst
(http://scst.sourceforge.net/). See 0.9.5 release version as well as
development code in the SVN.

Vlad

 

Released 12/01/2006 - now I know why I missed it there -- you just 
released it. :-)



P.S. I will post this to the scsi list in the future.
   



For scst only questions scst-devel on lists.sourceforge.net would be better.

 

Ok. Thanks for the prompt response. I will be testing your code today at 
4Gb. Let you know if it works.


:-)

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

scst support for kernels above 2.6.15

[Jeff V. Merkey]

I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18 
and above.  Is scst and target support for FC-AL going to
remain supported and/or merged at some point?   If so, what is planned 
for scst support for later kernels?


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

scst support for kernels above 2.6.15

[Jeff V. Merkey]

I have noticed that scsi_do_req has apparently been obsoleted in 2.6.18 
and above.  Is scst and target support for FC-AL going to
remain supported and/or merged at some point?   If so, what is planned 
for scst support for later kernels?


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

2.6.18 X problems with ES4

[Jeff V. Merkey]

If the X server is started manually on 2.6.14 and above with "startx &" 
and if you hit the enter key in the detached session,

the desktop will stop responding to keyboard and mouse events.

It's easy to reproduce.  Set to run level 3 on an ES4, then start the X 
server manually
and hit enter in the session from which you started the gnome desktop, 
and the X server

will stop responding to events, application startup, etc.

It's easisest to reproduce on ES4.

Jeff

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

2.6.18 X problems with ES4

[Jeff V. Merkey]

If the X server is started manually on 2.6.14 and above with startx  
and if you hit the enter key in the detached session,

the desktop will stop responding to keyboard and mouse events.

It's easy to reproduce.  Set to run level 3 on an ES4, then start the X 
server manually
and hit enter in the session from which you started the gnome desktop, 
and the X server

will stop responding to events, application startup, etc.

It's easisest to reproduce on ES4.

Jeff

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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the linux
kernel) is copyrighted by me and others who actually wrote it.

Linus Torvalds


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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

[EMAIL PROTECTED] wrote:


On Wed, 31 Aug 2005 12:00:45 MDT, "Jeff V. Merkey" said:

 


There's also a more fundamental problem with the GPL language.  The GPL stated 
it
confers "RIGHT TO COPY".  This is not the same as "RIGHT TO GRANT
LICENSES TO DISTRIBUTE."  Under US copyright law, if you confer to any person
the "right to copy" in a license which states the software is FREE, you have in 
essense
affected a copyright transfer to each and every person who receives the 
code.
   



Bullshit.

17 USC 106(3) talks about transfer of ownership *of the item*, not of the
copyright itself (see 17 USC 202, which clarifies this).  So you can sell a
book - but that isn't transferring the copyright of the book.  There isn't any
actual transfer without a document that actually *SAYS* "transfer of copyright" 
-
see 17 USC 204 (a) (Note that there's whole companies in Utah, with actual
large legal teams, that seem unclear on the concept in 17 USC 204(a), so I'm
not surprised that you're confused on this as well).

 

I have responded all I am going to on this topic.  Further discussion 
will not be helpful.  The patches are provided
IAW the GPL.  Our proprietary application is just like the thousands of 
others provided on Linux, and it

does use or incorporate any GPL or Linux code.

I will not respond to any further discussion on this thread.  Thanks for 
the input.  Please feel free to read Linus
statements on kernel.org regarding the statements that applications that 
run on Linux and that use published

interfaces are unaffected by the GPL.

Thanks for your input.

Jeff

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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

Arjan van de Ven wrote:

The GPL terms that require GPL conversion of any code that runs on Linux 
is not supported by US Law. Many would
disagree, but that's OK. In short, it's just like any other proprietary 
app running on Linux. If it uses no Linux code (which

it does not), then the GPL does not apply to it .
   



except for section 2 which states that if parts are related (or at least
not independent, for example when they are designed to exclusively work
togethern), and one part is GPL, then both parts need to be, or you
should not distribute the GPL part. This is not "your other code becomes
gpl", it is "you can't distribute the GPL parts".
 



The key word here is "designed to EXCLUSIVELY work together" as opposed to
"INCLUSIVE".  DSFS is not exclusive to Linux nor is it designed to run 
exclusively

on Linux.

There's also a more fundamental problem with the GPL language.  The GPL 
stated it

confers "RIGHT TO COPY".  This is not the same as "RIGHT TO GRANT
LICENSES TO DISTRIBUTE."  Under US copyright law, if you confer to any 
person
the "right to copy" in a license which states the software is FREE, you 
have in essense
affected a copyright transfer to each and every person who receives the 
code. 
This is esspecially true since the GPL says that the software if "FREE". 


One could argue that the GPL requires reciprocal consdieration by requiring
conversion of ownsership of protected IP into a GPL licensing scheme, 
but this
violates several acts of Congress regarding anit-trust legislation.  
There is also
the argument of the doctrine of esstoppel.  This doctrine bascially says 
if you've
been using it for some period of time, and no one brings a claim, then 
it's become yours. 
Linux and GPL has also become an "essential facility" of the US 
Internet.  Under the Doctrine
of essential facility anything that by it's nature has become such an 
integrated part
of a class of activities affecting commerce, then the general public has 
a right to use it

without claims of IP infingement or licensing restrictions.

So, in short, the GPL language was and remains defective in this area.   
If someone takes
and uses GPL code which is claimed to be FREE, and runs proprietary 
applications on Linux,
particularly given Linus statements publically and those of others that 
Linux applications
are not affected, then those appplications, provided they use published 
interfaces, and
do not incorporate GPL code, are not subject to the GPL and it's terms.  
The modified
portions of Linux, are however, subject to the GPL, and they have been 
disclosed as required.


I do agree that the GPL has this language, but the balancing test in a 
Court of law would be whether
or not the program was designed to be "exclusively work together" based 
upon the plain language

of the license.

This is not the case here.  Folks may try to argue that the VFS 
interface in Linux is "exclusive", however,
it ais a public interface, just like an ethernet adapter is a public 
interface.  The real solution is to remove
the "right to copy" language from the GPL, and substitute, "right to 
grant sub-licenses to distribute", then

your arguments would be more solid in US District Court.

Jeff






 



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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

Rik van Riel wrote:


On Wed, 31 Aug 2005, Jeff V. Merkey wrote:

 

The Core File System code is a separate proprietary module and is not 
released under the GPL
   



Are you going to post an analysis on the legality of this
on merkeylaw.com ? ;)

 

I am very open to discussions of this. Please go ahead and argue the 
merits of GPL vs. proprietary code. DSFS is platform
neutral and will also run on Windows XP/2000/2003/Longhorn and Free BSD. 
It uses no kernel headers or kernel

files.

I have always taken the position that the GPL does not convert IP 
ownership. Since DSFS is hardware specific to
our platforms, I do not believe it entails any issues with the GPL, and 
it uses published exports from the Linux kernel.
The GPL also confers right to copy == copyright under US copyright laws. 
I don't believe that app vendors infringe
the GPL on Linux. This is just another app, and I have disclosed and 
published all GPL code affected.


The GPL terms that require GPL conversion of any code that runs on Linux 
is not supported by US Law. Many would
disagree, but that's OK. In short, it's just like any other proprietary 
app running on Linux. If it uses no Linux code (which

it does not), then the GPL does not apply to it .

Jeff




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

[ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

The Solera Networks DS File System kernel patches have been posted at 
ftp.soleranetworks.com

and can be downloaded via anonymous ftp access.

These patches are for the 2.4.29, and 2.6.9 kernels.  These patches 
includes all kernel changes
made to the Linux kernel and GPL code that allows multiple gigabit 
capture and stream to disk capability
These patches are being provided as required by the terms of the GNU 
Public License.  Also included
with this announcement are white papers which can be located at 
www.soleranetworks.com describing the

appliance features and characteristics of the DSFS file system.

The Core File System code is a separate proprietary module and is not 
released under the GPL and is
shipped on the Solera Networks DS 1U, 2U, and 3U appliances.  DS 
Appliances support gigabit ethernet

and 10Ge Ethernet via the Intel e1000/ixgb adapter drivers.

Current Capture rates sustained with a 2U appliance with DSFS on Linux 
2.6.X and 2.4.X kernels are:


975,000 pps @ 72 byte packets x 2 interfaces  = 120 MB/S stream to disk
445,000 pps @ 256   byte packets x 2 interfaces  = 226 MB/S stream to disk
208,000 pps @ 576   byte packets x 2 interfaces  = 240 MB/S stream to disk
119,000 pps @ 1024 byte packets x 2 interfaces  = 245 MB/S stream to disk
82,000   pps @ 1500 byte packets x 2 interfaces  = 247 MB/S stream to disk

Current Capture rates sustained with a 1U appliance with DSFS on Linux 
2.6.X and 2.4.X kernels are:


975,000 pps @ 72 byte packets x 1 interfaces  = 60 MB/S stream to disk
445,000 pps @ 256   byte packets x 1 interfaces  = 113 MB/S stream to disk
208,000 pps @ 576   byte packets x 1 interfaces  = 119 MB/S stream to disk
119,000 pps @ 1024 byte packets x 1 interfaces  = 122 MB/S stream to disk
82,000   pps @ 1500 byte packets x 1 interfaces  = 123 MB/S stream to disk

Current Capture rates sustained with a 3U appliance with dual disk 
controllers with DSFS on Linux 2.6.X and 2.4.X kernels are:


975,000 pps @ 72 byte packets x 3 interfaces  = 180 MB/S stream to disk
445,000 pps @ 256   byte packets x 3 interfaces  = 339 MB/S stream to disk
208,000 pps @ 576   byte packets x 3 interfaces  = 360 MB/S stream to disk
119,000 pps @ 1024 byte packets x 3 interfaces  = 365 MB/S stream to disk
82,000   pps @ 1500 byte packets x 3 interfaces  = 370 MB/S stream to disk

The DSFS file system supports over 300 open source applications with 
high peformance stream to disk network forensic
storage capability and also supports SPAN,  Optical Splitter, and 
Asymmetric Routed configurations.  DSFS performs
stream merging and also exposes the captured data as native LIBPCAP 
files and virtual network interfaces which
allow seamless integration with Snort, tEthereal, and hundreds of open 
source Network Forsensic and Network Management
tools on Linux and Windows.DSFS is the culmination of 2 years of 
intense development efforts by Solera Networks to create a
powerful platform infrastructure for the development of high performance 
network forensic open source applications on the Linux

Operating System.

DSFS is fully SMP enabled and supports Hyperthreaded architectures as 
well as native SMP.  


Jeff V. Merkey
Solera Networks
www.soleranetworks.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/

[ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

The Solera Networks DS File System kernel patches have been posted at 
ftp.soleranetworks.com

and can be downloaded via anonymous ftp access.

These patches are for the 2.4.29, and 2.6.9 kernels.  These patches 
includes all kernel changes
made to the Linux kernel and GPL code that allows multiple gigabit 
capture and stream to disk capability
These patches are being provided as required by the terms of the GNU 
Public License.  Also included
with this announcement are white papers which can be located at 
www.soleranetworks.com describing the

appliance features and characteristics of the DSFS file system.

The Core File System code is a separate proprietary module and is not 
released under the GPL and is
shipped on the Solera Networks DS 1U, 2U, and 3U appliances.  DS 
Appliances support gigabit ethernet

and 10Ge Ethernet via the Intel e1000/ixgb adapter drivers.

Current Capture rates sustained with a 2U appliance with DSFS on Linux 
2.6.X and 2.4.X kernels are:


975,000 pps @ 72 byte packets x 2 interfaces  = 120 MB/S stream to disk
445,000 pps @ 256   byte packets x 2 interfaces  = 226 MB/S stream to disk
208,000 pps @ 576   byte packets x 2 interfaces  = 240 MB/S stream to disk
119,000 pps @ 1024 byte packets x 2 interfaces  = 245 MB/S stream to disk
82,000   pps @ 1500 byte packets x 2 interfaces  = 247 MB/S stream to disk

Current Capture rates sustained with a 1U appliance with DSFS on Linux 
2.6.X and 2.4.X kernels are:


975,000 pps @ 72 byte packets x 1 interfaces  = 60 MB/S stream to disk
445,000 pps @ 256   byte packets x 1 interfaces  = 113 MB/S stream to disk
208,000 pps @ 576   byte packets x 1 interfaces  = 119 MB/S stream to disk
119,000 pps @ 1024 byte packets x 1 interfaces  = 122 MB/S stream to disk
82,000   pps @ 1500 byte packets x 1 interfaces  = 123 MB/S stream to disk

Current Capture rates sustained with a 3U appliance with dual disk 
controllers with DSFS on Linux 2.6.X and 2.4.X kernels are:


975,000 pps @ 72 byte packets x 3 interfaces  = 180 MB/S stream to disk
445,000 pps @ 256   byte packets x 3 interfaces  = 339 MB/S stream to disk
208,000 pps @ 576   byte packets x 3 interfaces  = 360 MB/S stream to disk
119,000 pps @ 1024 byte packets x 3 interfaces  = 365 MB/S stream to disk
82,000   pps @ 1500 byte packets x 3 interfaces  = 370 MB/S stream to disk

The DSFS file system supports over 300 open source applications with 
high peformance stream to disk network forensic
storage capability and also supports SPAN,  Optical Splitter, and 
Asymmetric Routed configurations.  DSFS performs
stream merging and also exposes the captured data as native LIBPCAP 
files and virtual network interfaces which
allow seamless integration with Snort, tEthereal, and hundreds of open 
source Network Forsensic and Network Management
tools on Linux and Windows.DSFS is the culmination of 2 years of 
intense development efforts by Solera Networks to create a
powerful platform infrastructure for the development of high performance 
network forensic open source applications on the Linux

Operating System.

DSFS is fully SMP enabled and supports Hyperthreaded architectures as 
well as native SMP.  


Jeff V. Merkey
Solera Networks
www.soleranetworks.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: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

Rik van Riel wrote:


On Wed, 31 Aug 2005, Jeff V. Merkey wrote:

 

The Core File System code is a separate proprietary module and is not 
released under the GPL
   



Are you going to post an analysis on the legality of this
on merkeylaw.com ? ;)

 

I am very open to discussions of this. Please go ahead and argue the 
merits of GPL vs. proprietary code. DSFS is platform
neutral and will also run on Windows XP/2000/2003/Longhorn and Free BSD. 
It uses no kernel headers or kernel

files.

I have always taken the position that the GPL does not convert IP 
ownership. Since DSFS is hardware specific to
our platforms, I do not believe it entails any issues with the GPL, and 
it uses published exports from the Linux kernel.
The GPL also confers right to copy == copyright under US copyright laws. 
I don't believe that app vendors infringe
the GPL on Linux. This is just another app, and I have disclosed and 
published all GPL code affected.


The GPL terms that require GPL conversion of any code that runs on Linux 
is not supported by US Law. Many would
disagree, but that's OK. In short, it's just like any other proprietary 
app running on Linux. If it uses no Linux code (which

it does not), then the GPL does not apply to it .

Jeff




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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

Arjan van de Ven wrote:

The GPL terms that require GPL conversion of any code that runs on Linux 
is not supported by US Law. Many would
disagree, but that's OK. In short, it's just like any other proprietary 
app running on Linux. If it uses no Linux code (which

it does not), then the GPL does not apply to it .
   



except for section 2 which states that if parts are related (or at least
not independent, for example when they are designed to exclusively work
togethern), and one part is GPL, then both parts need to be, or you
should not distribute the GPL part. This is not your other code becomes
gpl, it is you can't distribute the GPL parts.
 



The key word here is designed to EXCLUSIVELY work together as opposed to
INCLUSIVE.  DSFS is not exclusive to Linux nor is it designed to run 
exclusively

on Linux.

There's also a more fundamental problem with the GPL language.  The GPL 
stated it

confers RIGHT TO COPY.  This is not the same as RIGHT TO GRANT
LICENSES TO DISTRIBUTE.  Under US copyright law, if you confer to any 
person
the right to copy in a license which states the software is FREE, you 
have in essense
affected a copyright transfer to each and every person who receives the 
code. 
This is esspecially true since the GPL says that the software if FREE. 


One could argue that the GPL requires reciprocal consdieration by requiring
conversion of ownsership of protected IP into a GPL licensing scheme, 
but this
violates several acts of Congress regarding anit-trust legislation.  
There is also
the argument of the doctrine of esstoppel.  This doctrine bascially says 
if you've
been using it for some period of time, and no one brings a claim, then 
it's become yours. 
Linux and GPL has also become an essential facility of the US 
Internet.  Under the Doctrine
of essential facility anything that by it's nature has become such an 
integrated part
of a class of activities affecting commerce, then the general public has 
a right to use it

without claims of IP infingement or licensing restrictions.

So, in short, the GPL language was and remains defective in this area.   
If someone takes
and uses GPL code which is claimed to be FREE, and runs proprietary 
applications on Linux,
particularly given Linus statements publically and those of others that 
Linux applications
are not affected, then those appplications, provided they use published 
interfaces, and
do not incorporate GPL code, are not subject to the GPL and it's terms.  
The modified
portions of Linux, are however, subject to the GPL, and they have been 
disclosed as required.


I do agree that the GPL has this language, but the balancing test in a 
Court of law would be whether
or not the program was designed to be exclusively work together based 
upon the plain language

of the license.

This is not the case here.  Folks may try to argue that the VFS 
interface in Linux is exclusive, however,
it ais a public interface, just like an ethernet adapter is a public 
interface.  The real solution is to remove
the right to copy language from the GPL, and substitute, right to 
grant sub-licenses to distribute, then

your arguments would be more solid in US District Court.

Jeff






 



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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

[EMAIL PROTECTED] wrote:


On Wed, 31 Aug 2005 12:00:45 MDT, Jeff V. Merkey said:

 


There's also a more fundamental problem with the GPL language.  The GPL stated 
it
confers RIGHT TO COPY.  This is not the same as RIGHT TO GRANT
LICENSES TO DISTRIBUTE.  Under US copyright law, if you confer to any person
the right to copy in a license which states the software is FREE, you have in 
essense
affected a copyright transfer to each and every person who receives the 
code.
   



Bullshit.

17 USC 106(3) talks about transfer of ownership *of the item*, not of the
copyright itself (see 17 USC 202, which clarifies this).  So you can sell a
book - but that isn't transferring the copyright of the book.  There isn't any
actual transfer without a document that actually *SAYS* transfer of copyright 
-
see 17 USC 204 (a) (Note that there's whole companies in Utah, with actual
large legal teams, that seem unclear on the concept in 17 USC 204(a), so I'm
not surprised that you're confused on this as well).

 

I have responded all I am going to on this topic.  Further discussion 
will not be helpful.  The patches are provided
IAW the GPL.  Our proprietary application is just like the thousands of 
others provided on Linux, and it

does use or incorporate any GPL or Linux code.

I will not respond to any further discussion on this thread.  Thanks for 
the input.  Please feel free to read Linus
statements on kernel.org regarding the statements that applications that 
run on Linux and that use published

interfaces are unaffected by the GPL.

Thanks for your input.

Jeff

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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of derived work.
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the linux
kernel) is copyrighted by me and others who actually wrote it.

Linus Torvalds


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Fwd: United States Patent: 6,862,609]

[Jeff V. Merkey]

Trever L. Adams wrote:
On Thu, 2005-03-03 at 08:48 -0700, Jeff V. Merkey wrote:
 

Patent law in the US is based on section 113 of the United States 
Constitution, and patents
are not going away.  
   

Merkey aren't you supposed to be a lawyer? Unless you do some funky
concatenation of articles and sections you can't find a section 113 (and
probably not even then) in the Constitution.
It is Article 1 Section 8. It also says they shall have that power and
that the intent is to promote the advances of arts and sciences. It
doesn't say that patents are the methods to be used. It doesn't say 17
years (or the whole 70/life+75 crap for copyrights). I think many very
intelligent people have and will show that allowing patents on ideas
(software patents are only this) tend to destroy such advances.
Yeah, yeah, from time to time there is someone who seems to show that
they help... however, 90% of those seem to be backed by MS or SCO.
Interesting considering many people, including Bill Gates, said quite
differently in the past.
Trever
 

I was informed earlier in this thread the uspto restructured the 
regulations and section 113 was
out of their procedures regulations.

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

Re: [Fwd: United States Patent: 6,862,609]

[Jeff V. Merkey]

Bernd Petrovitsch wrote:
On Wed, 2005-03-02 at 21:28 -0700, Jeff V. Merkey wrote:
 

Gene Heskett wrote:
   

On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote:
 

Another Linux patent.
   

... and another - AFAICS obvious - trivial ("prior art") patent (but I'm
not fluent in patent quak, I'm just a simple systems engineer).
And one more reason to sent the European software patent directive
simply to hell, clarify in §52.2 to not patentability of "software"
discarding the word play of the patent attorneys and offices and get
into the head of the folks of the EPO (with whatever means are
necessary).
 

And that pretty much says it.  Assigned to the Canopy Group.  So SCO 
will have yet another lawsuit to threaten us with.  If they survive 
 

Apparently Canopy Group/SCO/... are not of the front of innovation since
"what is new on a RAID system in any way in 2005"?
 

the thrashing I've Been Moved will give them at the end of the day.
 

The way to fight the patents is for Linux developers to file their own 
and start putting down stakes.
   

Or simply drop the whole patent system as such. Apparently it is only
abused to make money of the inventions of others and for sure does not
help innovation as such in any way (it may help the lawyers, offices and
companies in that area - patent utilisation - to get rich but that area
has nothing to do with innovation).
	Bernd
 

Patent law in the US is based on section 113 of the United States 
Constitution, and patents
are not going away.  Live with guys.  The best way to win the patent 
wars is for people
who do Linux development to file their own patents and put some stakes 
in the ground.

You guys keep saying, "stop the patents" but this is insanity.  It's 
like all these big companies
used patents like swords and are hemming linux in, and Linux stands 
naked and defenseless.
You guys need to get your own swords and fight -- start filing patents 
-- go to this new law
center "Southern Poverty Law Center" they setup I read about and get 
these folks to start
filing patents on Linux code (before you disclose it that is) and 
protect yourselves.  Then
you have ammo to negotiate cross patent agreements with MS and these 
other companies
to create a balance of power.

Jeff

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

Re: [Fwd: United States Patent: 6,862,609]

[Jeff V. Merkey]

Why the hell would I want
to look at the link in kwrite?
 

Talk to the USPTO, they created these links from their website. BTW,
if you check
the verson of web server run on the uspto.gov server, you will
discover it is
Apache on IBM servers and IBM Linux. Ask them why IBM's sofware
outputs links this way.
   

Correction Jeff, you sent that link to the list, and IMNSHO, it was 
your job to see to it the mimetype was properly set.  It was not.

 

I used mozilla mail in Fedra Core 2 to send it -- ON LINUX.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fwd: United States Patent: 6,862,609]

[Jeff V. Merkey]

Why the hell would I want
to look at the link in kwrite?
 

Talk to the USPTO, they created these links from their website. BTW,
if you check
the verson of web server run on the uspto.gov server, you will
discover it is
Apache on IBM servers and IBM Linux. Ask them why IBM's sofware
outputs links this way.
   

Correction Jeff, you sent that link to the list, and IMNSHO, it was 
your job to see to it the mimetype was properly set.  It was not.

 

I used mozilla mail in Fedra Core 2 to send it -- ON LINUX.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fwd: United States Patent: 6,862,609]

[Jeff V. Merkey]

Bernd Petrovitsch wrote:
On Wed, 2005-03-02 at 21:28 -0700, Jeff V. Merkey wrote:
 

Gene Heskett wrote:
   

On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote:
 

Another Linux patent.
   

... and another - AFAICS obvious - trivial (prior art) patent (but I'm
not fluent in patent quak, I'm just a simple systems engineer).
And one more reason to sent the European software patent directive
simply to hell, clarify in §52.2 to not patentability of software
discarding the word play of the patent attorneys and offices and get
into the head of the folks of the EPO (with whatever means are
necessary).
 

And that pretty much says it.  Assigned to the Canopy Group.  So SCO 
will have yet another lawsuit to threaten us with.  If they survive 
 

Apparently Canopy Group/SCO/... are not of the front of innovation since
what is new on a RAID system in any way in 2005?
 

the thrashing I've Been Moved will give them at the end of the day.
 

The way to fight the patents is for Linux developers to file their own 
and start putting down stakes.
   

Or simply drop the whole patent system as such. Apparently it is only
abused to make money of the inventions of others and for sure does not
help innovation as such in any way (it may help the lawyers, offices and
companies in that area - patent utilisation - to get rich but that area
has nothing to do with innovation).
	Bernd
 

Patent law in the US is based on section 113 of the United States 
Constitution, and patents
are not going away.  Live with guys.  The best way to win the patent 
wars is for people
who do Linux development to file their own patents and put some stakes 
in the ground.

You guys keep saying, stop the patents but this is insanity.  It's 
like all these big companies
used patents like swords and are hemming linux in, and Linux stands 
naked and defenseless.
You guys need to get your own swords and fight -- start filing patents 
-- go to this new law
center Southern Poverty Law Center they setup I read about and get 
these folks to start
filing patents on Linux code (before you disclose it that is) and 
protect yourselves.  Then
you have ammo to negotiate cross patent agreements with MS and these 
other companies
to create a balance of power.

Jeff

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

Re: [Fwd: United States Patent: 6,862,609]

[Jeff V. Merkey]

Trever L. Adams wrote:
On Thu, 2005-03-03 at 08:48 -0700, Jeff V. Merkey wrote:
 

Patent law in the US is based on section 113 of the United States 
Constitution, and patents
are not going away.  
   

Merkey aren't you supposed to be a lawyer? Unless you do some funky
concatenation of articles and sections you can't find a section 113 (and
probably not even then) in the Constitution.
It is Article 1 Section 8. It also says they shall have that power and
that the intent is to promote the advances of arts and sciences. It
doesn't say that patents are the methods to be used. It doesn't say 17
years (or the whole 70/life+75 crap for copyrights). I think many very
intelligent people have and will show that allowing patents on ideas
(software patents are only this) tend to destroy such advances.
Yeah, yeah, from time to time there is someone who seems to show that
they help... however, 90% of those seem to be backed by MS or SCO.
Interesting considering many people, including Bill Gates, said quite
differently in the past.
Trever
 

I was informed earlier in this thread the uspto restructured the 
regulations and section 113 was
out of their procedures regulations.

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

Re: [Fwd: United States Patent: 6,862,609]

[Jeff V. Merkey]

Gene Heskett wrote:
On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote:
 

Another Linux patent.
   

And that pretty much says it.  Assigned to the Canopy Group.  So SCO 
will have yet another lawsuit to threaten us with.  If they survive 
the thrashing I've Been Moved will give them at the end of the day.
 

The way to fight the patents is for Linux developers to file their own 
and start
putting down stakes.

Too bad that you can figure out how to file a patent, but can't figure 
out how to setup an html link.  Why the hell would I want to look at 
the link in kwrite?

 

Talk to the USPTO, they created these links from their website. BTW, if 
you check
the verson of web server run on the uspto.gov server, you will discover 
it is
Apache on IBM servers and IBM Linux. Ask them why IBM's sofware outputs
links this way.

Jeff
Seems like a good question to me.
 

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

[Fwd: United States Patent: 6,862,609]

[Jeff V. Merkey]

Another Linux patent.

--- Begin Message ---
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2=HITOFF=1=/netahtml/search-bool.html=1=G=50=AND=ptxt=merkey.INZZ.=IN/merkey=IN/merkey 


--- End Message ---

Re: RFD: Kernel release numbering

[Jeff V. Merkey]

Zwane Mwaikambo wrote:
On Wed, 2 Mar 2005, Jeff V. Merkey wrote:
 

__Stable__ would be a good thing. The entire 2.6 development has been a 
disaster from a stability viewpoint. I have to maintain a huge tree of 
patches in order to ship appliance builds due to the lack of stability 
for 2.6. I think that the even number releases will take longer but it's 
worth the wait.
   

What form of instability are you referring to?
 

Where have you been? Read the bug reports and the types of bugs.
Jeff

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

Re: RFD: Kernel release numbering

[Jeff V. Merkey]

Randy.Dunlap wrote:
Jeff V. Merkey wrote:
__Stable__ would be a good thing. The entire 2.6 development has been 
a disaster from
a stability viewpoint. I have to maintain a huge tree of patches in 
order to ship appliance
builds due to the lack of stability for 2.6. I think that the even 
number releases will take longer but it's worth the wait.

Jeff

Linus's release cycle estimate might be optimistic.  :)
Yep, but at least he is addressing the issue and taking responsibility 
and showing good prudent leadership and some
reasonable and sound ideas to correct it. 

I'm seeing lots more bug reports recently than I care to see.  :(

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

Re: RFD: Kernel release numbering

[Jeff V. Merkey]

__Stable__ would be a good thing. The entire 2.6 development has been a 
disaster from
a stability viewpoint. I have to maintain a huge tree of patches in 
order to ship appliance
builds due to the lack of stability for 2.6. I think that the even 
number releases will take longer
but it's worth the wait.

Jeff
Linus Torvalds wrote:
This is an idea that has been brewing for some time: Andrew has mentioned
it a couple of times, I've talked to some people about it, and today Davem
sent a suggestion along similar lines to me for 2.6.12.
Namely that we could adopt the even/odd numbering scheme that we used to 
do on a minor number basis, and instead of dropping it entirely like we 
did, we could have just moved it to the release number, as an indication 
of what was the intent of the release.

The problem with major development trees like 2.4.x vs 2.5.x was that the 
release cycles were too long, and that people hated the back- and 
forward-porting. That said, it did serve a purpose - people kind of knew 
where they stood, even though we always ended up having to have big 
changes in the stable tree too, just to keep up with a changing landscape.

So the suggestion on the table would be to go back to even/odd, but do it 
at the "micro-level" of single releases, rather than make it a two- or 
three-year release cycle.

In this setup, all kernels would still be _stable_, in the sense that we
don't anticipate any real breakage (if we end up having to rip up so much
basic stuff that we have to break anything, we'd go back to the 2.7.x kind
of numbering scheme). So we should fear odd releases, but track them, to 
make sure that they are good (if you don't track them, and problems won't 
be fixed in the even version either)

But we'd basically have stricter concerns for an even release, and in
particular the plan would be that the diff files would alternate between
bigger ones (the 2.6.10->11 full diff was almost 5MB) and smaller ones (a
2.6.11->12 release would be a "stability only" thing, and hopefully the
diff file would be much smaller).
We'd still do the -rcX candidates as we go along in either case, so as a 
user you wouldn't even _need_ to know, but the numbering would be a rough 
guide to intentions. Ie I'd expect that distributions would always try to 
base their stuff off a 2.6. release.

It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x
kind of even/odd thing didn't _work_, the problems really were an issue of
too big granularity making it hard for user and developers alike. So I see
this as a tweak of the "let's drop the notion althogether for now"  
decision, and just modify it to "even/odd is meaningful at all levels".

In other words, we'd have an increasing level of instability with an odd 
release number, depending on how long-term the instability is.

- 2.6.: even at all levels, aim for having had minimally intrusive 
  patches leading up to it (timeframe: a week or two)

with the odd numbers going like:
- 2.6.: still a stable kernel, but accept bigger changes leading up 
  to it (timeframe: a month or two).
- 2..x: aim for big changes that may destabilize the kernel for 
  several releases (timeframe: a year or two)
- .x.x: Linus went crazy, broke absolutely _everything_, and rewrote
  the kernel to be a microkernel using a special message-passing version 
  of Visual Basic. (timeframe: "we expect that he will be released from 
  the mental institution in a decade or two").

The reason I put a shorter timeframe on the "all-even" kernel is because I
don't want developers to be too itchy and sitting on stuff for too long if
they did something slightly bigger. In theory, the longer the better
there, but in practice this release numbering is still nothing but a hint
of the _intent_ of the developers - it's still not a guarantee of "we
fixed all bugs", and anybody who expects that (and tries to avoid all odd 
release entirely) is just setting himself up for not testing - and thus 
bugs.

Comments?
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/
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: RFD: Kernel release numbering

[Jeff V. Merkey]

__Stable__ would be a good thing. The entire 2.6 development has been a 
disaster from
a stability viewpoint. I have to maintain a huge tree of patches in 
order to ship appliance
builds due to the lack of stability for 2.6. I think that the even 
number releases will take longer
but it's worth the wait.

Jeff
Linus Torvalds wrote:
This is an idea that has been brewing for some time: Andrew has mentioned
it a couple of times, I've talked to some people about it, and today Davem
sent a suggestion along similar lines to me for 2.6.12.
Namely that we could adopt the even/odd numbering scheme that we used to 
do on a minor number basis, and instead of dropping it entirely like we 
did, we could have just moved it to the release number, as an indication 
of what was the intent of the release.

The problem with major development trees like 2.4.x vs 2.5.x was that the 
release cycles were too long, and that people hated the back- and 
forward-porting. That said, it did serve a purpose - people kind of knew 
where they stood, even though we always ended up having to have big 
changes in the stable tree too, just to keep up with a changing landscape.

So the suggestion on the table would be to go back to even/odd, but do it 
at the micro-level of single releases, rather than make it a two- or 
three-year release cycle.

In this setup, all kernels would still be _stable_, in the sense that we
don't anticipate any real breakage (if we end up having to rip up so much
basic stuff that we have to break anything, we'd go back to the 2.7.x kind
of numbering scheme). So we should fear odd releases, but track them, to 
make sure that they are good (if you don't track them, and problems won't 
be fixed in the even version either)

But we'd basically have stricter concerns for an even release, and in
particular the plan would be that the diff files would alternate between
bigger ones (the 2.6.10-11 full diff was almost 5MB) and smaller ones (a
2.6.11-12 release would be a stability only thing, and hopefully the
diff file would be much smaller).
We'd still do the -rcX candidates as we go along in either case, so as a 
user you wouldn't even _need_ to know, but the numbering would be a rough 
guide to intentions. Ie I'd expect that distributions would always try to 
base their stuff off a 2.6.even release.

It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x
kind of even/odd thing didn't _work_, the problems really were an issue of
too big granularity making it hard for user and developers alike. So I see
this as a tweak of the let's drop the notion althogether for now  
decision, and just modify it to even/odd is meaningful at all levels.

In other words, we'd have an increasing level of instability with an odd 
release number, depending on how long-term the instability is.

- 2.6.even: even at all levels, aim for having had minimally intrusive 
  patches leading up to it (timeframe: a week or two)

with the odd numbers going like:
- 2.6.odd: still a stable kernel, but accept bigger changes leading up 
  to it (timeframe: a month or two).
- 2.odd.x: aim for big changes that may destabilize the kernel for 
  several releases (timeframe: a year or two)
- odd.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
  the kernel to be a microkernel using a special message-passing version 
  of Visual Basic. (timeframe: we expect that he will be released from 
  the mental institution in a decade or two).

The reason I put a shorter timeframe on the all-even kernel is because I
don't want developers to be too itchy and sitting on stuff for too long if
they did something slightly bigger. In theory, the longer the better
there, but in practice this release numbering is still nothing but a hint
of the _intent_ of the developers - it's still not a guarantee of we
fixed all bugs, and anybody who expects that (and tries to avoid all odd 
release entirely) is just setting himself up for not testing - and thus 
bugs.

Comments?
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/
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: RFD: Kernel release numbering

[Jeff V. Merkey]

Randy.Dunlap wrote:
Jeff V. Merkey wrote:
__Stable__ would be a good thing. The entire 2.6 development has been 
a disaster from
a stability viewpoint. I have to maintain a huge tree of patches in 
order to ship appliance
builds due to the lack of stability for 2.6. I think that the even 
number releases will take longer but it's worth the wait.

Jeff

Linus's release cycle estimate might be optimistic.  :)
Yep, but at least he is addressing the issue and taking responsibility 
and showing good prudent leadership and some
reasonable and sound ideas to correct it. 

I'm seeing lots more bug reports recently than I care to see.  :(

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

Re: RFD: Kernel release numbering

[Jeff V. Merkey]

Zwane Mwaikambo wrote:
On Wed, 2 Mar 2005, Jeff V. Merkey wrote:
 

__Stable__ would be a good thing. The entire 2.6 development has been a 
disaster from a stability viewpoint. I have to maintain a huge tree of 
patches in order to ship appliance builds due to the lack of stability 
for 2.6. I think that the even number releases will take longer but it's 
worth the wait.
   

What form of instability are you referring to?
 

Where have you been? Read the bug reports and the types of bugs.
Jeff

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

[Fwd: United States Patent: 6,862,609]

[Jeff V. Merkey]

Another Linux patent.

---BeginMessage---
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=/netahtml/search-bool.htmlr=1f=Gl=50co1=ANDd=ptxts1=merkey.INZZ.OS=IN/merkeyRS=IN/merkey 
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=/netahtml/search-bool.htmlr=1f=Gl=50co1=ANDd=ptxts1=merkey.INZZ.OS=IN/merkeyRS=IN/merkey

---End Message---

Re: [Fwd: United States Patent: 6,862,609]

[Jeff V. Merkey]

Gene Heskett wrote:
On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote:
 

Another Linux patent.
   

And that pretty much says it.  Assigned to the Canopy Group.  So SCO 
will have yet another lawsuit to threaten us with.  If they survive 
the thrashing I've Been Moved will give them at the end of the day.
 

The way to fight the patents is for Linux developers to file their own 
and start
putting down stakes.

Too bad that you can figure out how to file a patent, but can't figure 
out how to setup an html link.  Why the hell would I want to look at 
the link in kwrite?

 

Talk to the USPTO, they created these links from their website. BTW, if 
you check
the verson of web server run on the uspto.gov server, you will discover 
it is
Apache on IBM servers and IBM Linux. Ask them why IBM's sofware outputs
links this way.

Jeff
Seems like a good question to me.
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Uncle Sam Wants YOU!

[Jeff V. Merkey]

On Sun, Jul 01, 2001 at 04:50:44PM -0700, Ben Ford wrote:

Microsoft is like a mountain with their installed base.  Like it 
or not, no matter how loud the wind howls, the mountain cannot bow
to it.

:-)

Jeff



> Paul Mundt wrote:
> 
> >On Sun, Jul 01, 2001 at 01:35:24PM -0400, Adam Schrotenboer wrote:
> >
> >>So as a user you are free to not use M$ products.
> >>What if you are IT. Then you do not have a choice.
> >>
> >You always have a choice, work elsewhere. If you're in a position where you're
> >working with MS products, you were the one who made the decision to do so.
> >MS is not at fault, claiming so is childish.
> >
> 
> Name a single tech company anywhere in the world that doesn't have to 
> deal with microsoftisms.
> 
> [ . . . ]
> 
> >>When Win95 came out, I finally got to hate M$. Then I discovered Linux
> >>and now I have a great dislike for M$ and their products.
> >>
> >This makes absolutely no sense. You didn't have a problem with MS originally,
> >but as soon as Win95 came out you instantly hated them? A few issues with an
> >OS are hardly valid grounds for "hating" a company.
> >
> >Also, I don't see how once you discovered Linux your hatred for MS grew. This
> >also makes very little sense. If you were sitting there using MS products of
> >
> It makes perfect sense to me.  Take my family as an example.  My wife 
> used Windows because she didn't know anything else existed.  She crashed 
> and rebooted quite frequently and never knew there was an alternative. 
>  Then she met me and was rather astounded that I hadn't rebooted my 
> machine in months.  Now she hates Microsoft because she realizes what 
> bullshit she went through.
> 
> 
> [ . . . ]
> 
> >Oh please, next you'll be blaming world hunger on MS because third world
> >countries can't afford licenses of win2k.
> >
> 
> Well, when you realize that Bill Gates (not MS, just Bill Gates 
> personally) has enough money to give every person in the world $10 out 
> of his pocket, then you see this argument in a different light.
> 
> (Disclaimer:  This statistic was from 2 or 3 years ago.  I don't know 
> what the figures are now.)
> 
> -- 
> :__o
> :   -\<,
> :   0/ 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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: NWFS Submitted to Alan Cox

[Jeff V. Merkey]

On Sun, Jul 01, 2001 at 12:23:17PM -0700, Justin Guyett wrote:
> On Mon, 2 Jul 2001, Chris Wedgwood wrote:
> 
> > On Sun, Jul 01, 2001 at 01:50:00PM +0100, Alan Cox wrote:
> >
> > > I'm not a file sustem hacker, nor since I work for one vendor the
> > > appropriate owner for larg chunks of code in some people's eyes. I
> > > suspect the FSF is a much much better asignee for the code itself
> >
> > I assume the legal threats that Jeff has experience will follow the
> > code? Surely before anyone wishes to adopt such a thing they should
> > get legal advice about the situation?
> >
> > It would be shame to let potentially useful code be left to die for
> > fear of bully-tactics if their claims are unfounded.
> 
> presuming they are unfounded, given the history of attacks by Novell,
> perhaps the best move would be to turn it over to a company like compaq or
> ibm given a written contract that they will keep it open source.  



> Novell can't be that stupid.

Don't count on it.  I had completed a fully 64-bit OS in 1997 for IA64, 
four years before everyone else.  It's been sitting in an archive 
somewhere inside of Novell -- unused for no other reason than I 
wrote it.  I am waiting to see who would want it.  It's open to 
any takers.  Alan may be in a conflict of interest with Red Hat 
since Novell is an investor in them, so this I understand.  I'll 
wait and see who's interested.  I would not be surprised if 
someone from Novell asks to take it over.   

Jeff


> 
> 
> justin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: NWFS Submitted to Alan Cox

[Jeff V. Merkey]

On Sun, Jul 01, 2001 at 12:16:34AM -0400, Trever L. Adams wrote:
> > I am doing very well with my consulting projects, but to be honest, 
> > my family has sufferred horribly in the past four years fighting with
> > Novell every other week, and there's a very strong chance I will be 
> > moving shop to either New Mexico or Arizona, since they own the 
> > local courts here in Utah (all the judges are mormons in Utah Valley 
> > and pro-Novell).  
> 
> Once again, we have Mr. Merkey at it.  None of his problems can just be 
> his, or caused by Novell.  They can't just be because, at one time (no 
> longer though), Novell was THE economy for Utah Valley (Provo/Orem 
> area).  They can't be because he has little respect for aspects of 
> intellectual property (for those who believe in it or are under legal 
> systems that do).  The mormons cause them all.
> 
> Get real, move on, and get a life Mr. Merkey.
> 
> For the record, I believe you are in the wrong here.  I believe that 
> there are several non-mormon judges in the area (at least there were a 
> little over a year ago when I lived there).
> 
> Yes, I am wa off topic.  But lets keep it to the technology and the 
> law.  If the finger has to be pointed, point it where it belongs and 
> leave the predominant (60% tops) religion out of the picture.
> 
> Now back to your regularly schedule flame wars on different technology, 
> real discusion, and the real world.
> 
> Trever Adams
> 
> P.S. Sure, I am LDS (mormon).  I have a problem with the above because 
> our religion requires us to stand for truth and I believe Mr. Merkey 
> tends to misrepresent the religion.  I would have a problem with him 
> misrepresenting any religion (if I knew he was doing so... with many 
> religions I would likely not - still... it would be a problem).
> 
> P.P.S. Any flames or responses to this that want a response will reply 
> in private.  I will not continue this on the list.

Trevor,

I really think you guys should start using peyote in your temple rituals, 
you'd have a much better grasp on reality.  Most people do not believe
they are going to be gods when they die, which is what mormonisn 
teaches.  I guess a lot of mormoms think they already are, and act like 
it.

:-)

Jeff 




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

Re: NWFS Submitted to Alan Cox

[Jeff V. Merkey]

On Sun, Jul 01, 2001 at 01:50:00PM +0100, Alan Cox wrote:
> > There are several areas that need restructuring and work, and I am 
> > available to answer questions, and assist with technical consulting,
> 
> I'm not a file sustem hacker, nor since I work for one vendor the 
> appropriate owner for larg chunks of code in some people's eyes. I suspect
> the FSF is a much much better asignee for the code itself
> 
> Alan

I will get with you offline and discuss this possibility.

Jeff

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

Re: NWFS Submitted to Alan Cox

[Jeff V. Merkey]

On Sat, Jun 30, 2001 at 10:59:59PM -0500, Paul Fulghum wrote:
> 
> From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
> 
> > Novell has recently threatened to try to take my house and
> > assets if I post any more NWFS releases or MANOS.
> [snip]
> > They are wounded in the market ...
> 
> A quote for the lumbering lizards at Novell
> as they stumble torwards the tarpits:
> 
> These moments will be lost in time
> like tears in the rain...
> time to die.

I am watching the walls cave in on Provo and the view is great from 
Where I am sitting.  

:-)

Jeff

> 
> --
> Paul Fulghum
> [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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: NWFS Submitted to Alan Cox

[Jeff V. Merkey]

On Mon, Jul 02, 2001 at 02:54:18AM +1200, Chris Wedgwood wrote:
> On Sun, Jul 01, 2001 at 01:50:00PM +0100, Alan Cox wrote:
> 
> > I'm not a file sustem hacker, nor since I work for one vendor the
> > appropriate owner for larg chunks of code in some people's eyes. I
> > suspect the FSF is a much much better asignee for the code itself
> 
> I assume the legal threats that Jeff has experience will follow the
> code? Surely before anyone wishes to adopt such a thing they should
> get legal advice about the situation?
> 
> I would also expect if the FSF are not the assignee (the suggest that
> they be is a very good one), then whomever does adopt it might want to
> make sure they have some kind of legal representation available should
> they need it.
> 
> It would be shame to let potentially useful code be left to die for
> fear of bully-tactics if their claims are unfounded.
> 

Their power only extends to the borders of this state.  They have little 
ability to interfere wth someone in Swansea, Great Britian, or even 
Silicon Valley, California.   The problem I have is they can get the 
local courts here to do whatever they ask.  Not so other places.  I think
it's pretty safe so long as I am not the one releasing it.  

Jeff


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