Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hi,

On Sun, Dec 22, 2013 at 03:25:23AM +0100, Jochen Striepe wrote:
> Applies, compiles, and runs smoothly on top of 3.12.6. I'll send word
> if anything odd shows up.

Tested with various loads, everything nice and working so far.

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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hi,

On Sun, Dec 22, 2013 at 03:25:23AM +0100, Jochen Striepe wrote:
 Applies, compiles, and runs smoothly on top of 3.12.6. I'll send word
 if anything odd shows up.

Tested with various loads, everything nice and working so far.

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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hi!

On Mon, Dec 16, 2013 at 02:40:06PM -0800, Paul E. McKenney wrote:
> > > > > rcu: Kick CPU halfway to RCU CPU stall warning
[...]
> And you are quite right, there is a prerequisite commit.  I have attached
> both, please apply in numeric order.

Applies, compiles, and runs smoothly on top of 3.12.6. I'll send word
if anything odd shows up.

> Because patch.2 has not yet made it to mainline, it is not yet eligible
> for -stable.  I expect it to hit mainline in the 3.14 merge window,
> which will likely be coming up in a few weeks.

Ah, ok. Thanks for helping and informing!


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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hi!

On Mon, Dec 16, 2013 at 02:40:06PM -0800, Paul E. McKenney wrote:
 rcu: Kick CPU halfway to RCU CPU stall warning
[...]
 And you are quite right, there is a prerequisite commit.  I have attached
 both, please apply in numeric order.

Applies, compiles, and runs smoothly on top of 3.12.6. I'll send word
if anything odd shows up.

 Because patch.2 has not yet made it to mainline, it is not yet eligible
 for -stable.  I expect it to hit mainline in the 3.14 merge window,
 which will likely be coming up in a few weeks.

Ah, ok. Thanks for helping and informing!


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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hi again,

On Fri, Dec 06, 2013 at 06:54:41AM -0800, Paul E. McKenney wrote:
> On Fri, Dec 06, 2013 at 02:58:04PM +0100, Jochen Striepe wrote:
> > On Thu, Dec 05, 2013 at 04:26:14PM -0800, Paul E. McKenney wrote:
> > > Hmmm...  Does the following patch help?
> > [...]
> > > rcu: Kick CPU halfway to RCU CPU stall warning
> > 
> > The stall didn't appear at all since my last email, running 3.12.x
> > kernels since release. But I will test your patch later today. I assume
> > applying on top of 3.12.3 is correct?
> 
> 3.12.3 should take that patch just fine.

Sorry for the delay. On my copy of 3.12.3, the patch does not apply.
kernel/rcu/ does not exist, and the patch did not apply cleanly on
kernel/rcutree.c: record_gp_stall_check_time() is a little different
from what your patch expects, and I'm not that much into rcu work as
to understand the implications. :)

If you want me to go back to 3.12.0 I can do so, but as the issue
does not reproduce very well I doubt that would help very much.
Ideas? Is there a version of the patch for -stable, or does the
patch conflict with the work done there?

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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hi again,

On Fri, Dec 06, 2013 at 06:54:41AM -0800, Paul E. McKenney wrote:
 On Fri, Dec 06, 2013 at 02:58:04PM +0100, Jochen Striepe wrote:
  On Thu, Dec 05, 2013 at 04:26:14PM -0800, Paul E. McKenney wrote:
   Hmmm...  Does the following patch help?
  [...]
   rcu: Kick CPU halfway to RCU CPU stall warning
  
  The stall didn't appear at all since my last email, running 3.12.x
  kernels since release. But I will test your patch later today. I assume
  applying on top of 3.12.3 is correct?
 
 3.12.3 should take that patch just fine.

Sorry for the delay. On my copy of 3.12.3, the patch does not apply.
kernel/rcu/ does not exist, and the patch did not apply cleanly on
kernel/rcutree.c: record_gp_stall_check_time() is a little different
from what your patch expects, and I'm not that much into rcu work as
to understand the implications. :)

If you want me to go back to 3.12.0 I can do so, but as the issue
does not reproduce very well I doubt that would help very much.
Ideas? Is there a version of the patch for -stable, or does the
patch conflict with the work done there?

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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hi again,

On Thu, Dec 05, 2013 at 04:26:14PM -0800, Paul E. McKenney wrote:
> Hmmm...  Does the following patch help?
[...]
> rcu: Kick CPU halfway to RCU CPU stall warning

The stall didn't appear at all since my last email, running 3.12.x
kernels since release. But I will test your patch later today. I assume
applying on top of 3.12.3 is correct?

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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hi again,

On Thu, Dec 05, 2013 at 04:26:14PM -0800, Paul E. McKenney wrote:
 Hmmm...  Does the following patch help?
[...]
 rcu: Kick CPU halfway to RCU CPU stall warning

The stall didn't appear at all since my last email, running 3.12.x
kernels since release. But I will test your patch later today. I assume
applying on top of 3.12.3 is correct?

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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hello again,

On Sat, Sep 14, 2013 at 01:28:34PM +0200, Jochen Striepe wrote:
> On Mon, Sep 09, 2013 at 03:27:51PM -0700, Paul E. McKenney wrote:
> > rcu: Reject memory-order-induced stall-warning false positives
> 
> I run this patch on top of 3.10.11 vanilla since Wednesday, so far
> without any further stalls, on light to heavy loads. Works smooth
> as pie.

Hmm, perhaps it is not as easy as I thought. On exactly this machine
with exactly this kernel (3.10.11 vanilla with your patch from this
thread), some minutes ago another one came up. The system should have
been mostly idle at that moment. Dmesg appended ... do you need
anything else to have an educated guess? I waited 10 minutes after
the stall message (following your earlier advise), but no further
dmesg lines appeared after that.

Best greetings,
Jochen.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.10.11pm1 (root@sodom) (gcc version 4.7.3 (Debian 
4.7.3-4) ) #1 SMP Wed Sep 11 13:05:02 CEST 2013
[0.00] Disabled fast string operations
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e2000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7f64] usable
[0.00] BIOS-e820: [mem 0x7f65-0x7f65] reserved
[0.00] BIOS-e820: [mem 0x7f66-0x7f66dfff] ACPI data
[0.00] BIOS-e820: [mem 0x7f66e000-0x7f6a] ACPI NVS
[0.00] BIOS-e820: [mem 0x7f6b-0x7f6b] reserved
[0.00] BIOS-e820: [mem 0x7f6c8000-0x7f7f] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] SMBIOS 2.5 present.
[0.00] DMI: ASUSTeK Computer INC. 1201HA/1201HA, BIOS 021011/25/2009
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x7f650 max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-D uncachable
[0.00]   E-E write-through
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask 08000 write-back
[0.00]   1 base 07F70 mask 0FFF0 uncachable
[0.00]   2 base 07F80 mask 0FF80 uncachable
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at 
[c00ff780]
[0.00] initial memory mapped: [mem 0x-0x017f]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x3700-0x373f]
[0.00]  [mem 0x3700-0x373f] page 2M
[0.00] init_memory_mapping: [mem 0x3000-0x36ff]
[0.00]  [mem 0x3000-0x36ff] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x2fff]
[0.00]  [mem 0x0010-0x003f] page 4k
[0.00]  [mem 0x0040-0x2fff] page 2M
[0.00] init_memory_mapping: [mem 0x3740-0x377fdfff]
[0.00]  [mem 0x3740-0x377fdfff] page 4k
[0.00] BRK [0x0153e000, 0x0153efff] PGTABLE
[0.00] RAMDISK: [mem 0x37526000-0x37a8afff]
[0.00] Allocated new RAMDISK: [mem 0x36fc1000-0x3752564e]
[0.00] Move RAMDISK from [mem 0x37526000-0x37a8a64e] to [mem 
0x36fc1000-0x3752564e]
[0.00] ACPI: RSDP 000fbfd0 00024 (v02 ACPIAM)
[0.00] ACPI: XSDT 7f660100 00064 (v01 _ASUS_ Notebook 20091125 MSFT 
0097)
[0.00] ACPI: FACP 7f660290 000F4 (v04 112509 FACP1046 20091125 MSFT 
0097)
[0.00] ACPI: DSDT 7f660430 095E0 (v02  A1451 A1451000  INTL 
20060113)
[0.00] ACPI: FACS 7f66e000 00040
[0.00] ACPI: APIC 7f660390 0005C (v02 112509 APIC1046 20091125 MSFT 
0097)
[0.00] ACPI: MCFG 7f6603f0 0003C (v01 112509 OEMMCFG  20091125 MSFT 
0097)
[0.00] ACPI: OEMB 7f66e040 0012C (v01 112509 OEMB1046 20091125 MSFT 
0097)
[0.00] ACPI: HPET 7f669a10 00038 (v01 11250

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hello again,

On Sat, Sep 14, 2013 at 01:28:34PM +0200, Jochen Striepe wrote:
 On Mon, Sep 09, 2013 at 03:27:51PM -0700, Paul E. McKenney wrote:
  rcu: Reject memory-order-induced stall-warning false positives
 
 I run this patch on top of 3.10.11 vanilla since Wednesday, so far
 without any further stalls, on light to heavy loads. Works smooth
 as pie.

Hmm, perhaps it is not as easy as I thought. On exactly this machine
with exactly this kernel (3.10.11 vanilla with your patch from this
thread), some minutes ago another one came up. The system should have
been mostly idle at that moment. Dmesg appended ... do you need
anything else to have an educated guess? I waited 10 minutes after
the stall message (following your earlier advise), but no further
dmesg lines appeared after that.

Best greetings,
Jochen.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.10.11pm1 (root@sodom) (gcc version 4.7.3 (Debian 
4.7.3-4) ) #1 SMP Wed Sep 11 13:05:02 CEST 2013
[0.00] Disabled fast string operations
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e2000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7f64] usable
[0.00] BIOS-e820: [mem 0x7f65-0x7f65] reserved
[0.00] BIOS-e820: [mem 0x7f66-0x7f66dfff] ACPI data
[0.00] BIOS-e820: [mem 0x7f66e000-0x7f6a] ACPI NVS
[0.00] BIOS-e820: [mem 0x7f6b-0x7f6b] reserved
[0.00] BIOS-e820: [mem 0x7f6c8000-0x7f7f] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] SMBIOS 2.5 present.
[0.00] DMI: ASUSTeK Computer INC. 1201HA/1201HA, BIOS 021011/25/2009
[0.00] e820: update [mem 0x-0x0fff] usable == reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x7f650 max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-D uncachable
[0.00]   E-E write-through
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask 08000 write-back
[0.00]   1 base 07F70 mask 0FFF0 uncachable
[0.00]   2 base 07F80 mask 0FF80 uncachable
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at 
[c00ff780]
[0.00] initial memory mapped: [mem 0x-0x017f]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x3700-0x373f]
[0.00]  [mem 0x3700-0x373f] page 2M
[0.00] init_memory_mapping: [mem 0x3000-0x36ff]
[0.00]  [mem 0x3000-0x36ff] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x2fff]
[0.00]  [mem 0x0010-0x003f] page 4k
[0.00]  [mem 0x0040-0x2fff] page 2M
[0.00] init_memory_mapping: [mem 0x3740-0x377fdfff]
[0.00]  [mem 0x3740-0x377fdfff] page 4k
[0.00] BRK [0x0153e000, 0x0153efff] PGTABLE
[0.00] RAMDISK: [mem 0x37526000-0x37a8afff]
[0.00] Allocated new RAMDISK: [mem 0x36fc1000-0x3752564e]
[0.00] Move RAMDISK from [mem 0x37526000-0x37a8a64e] to [mem 
0x36fc1000-0x3752564e]
[0.00] ACPI: RSDP 000fbfd0 00024 (v02 ACPIAM)
[0.00] ACPI: XSDT 7f660100 00064 (v01 _ASUS_ Notebook 20091125 MSFT 
0097)
[0.00] ACPI: FACP 7f660290 000F4 (v04 112509 FACP1046 20091125 MSFT 
0097)
[0.00] ACPI: DSDT 7f660430 095E0 (v02  A1451 A1451000  INTL 
20060113)
[0.00] ACPI: FACS 7f66e000 00040
[0.00] ACPI: APIC 7f660390 0005C (v02 112509 APIC1046 20091125 MSFT 
0097)
[0.00] ACPI: MCFG 7f6603f0 0003C (v01 112509 OEMMCFG  20091125 MSFT 
0097)
[0.00] ACPI: OEMB 7f66e040 0012C (v01 112509 OEMB1046 20091125 MSFT 
0097)
[0.00] ACPI: HPET 7f669a10 00038 (v01 112509 OEMHPET  20091125 MSFT 
0097

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hello again,

On Mon, Sep 09, 2013 at 03:27:51PM -0700, Paul E. McKenney wrote:
> Several people helped track down another source of spurious stall
> warnings on large systems, please see below for the patch.
[...]
> 
> 
> rcu: Reject memory-order-induced stall-warning false positives

I run this patch on top of 3.10.11 vanilla since Wednesday, so far
without any further stalls, on light to heavy loads. Works smooth
as pie.

Tested-by: Jochen Striepe 


Have a nice weekend and a big thank you,
Jochen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hello again,

On Mon, Sep 09, 2013 at 03:27:51PM -0700, Paul E. McKenney wrote:
 Several people helped track down another source of spurious stall
 warnings on large systems, please see below for the patch.
[...]
 
 
 rcu: Reject memory-order-induced stall-warning false positives

I run this patch on top of 3.10.11 vanilla since Wednesday, so far
without any further stalls, on light to heavy loads. Works smooth
as pie.

Tested-by: Jochen Striepe joc...@tolot.escape.de


Have a nice weekend and a big thank you,
Jochen.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hello,

On Tue, Sep 10, 2013 at 10:54:53AM -0700, Paul E. McKenney wrote:
> Their stall was due to old-style creation of sysfs entries for memory.
> Yours might be having a similar issue with the creation of /dev entries,
> so it would be worth trying it.

OK, compiling 3.10.11 with your patch right now.

> One thing to try would be to insert delays into the code involved in
> creating the /dev entries.  These delays will need to be busy-waits
> rather than sleeps.

Uh, I will have a look. But I'm no kernel developer. :)


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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hello,

On Tue, Sep 10, 2013 at 10:54:53AM -0700, Paul E. McKenney wrote:
 Their stall was due to old-style creation of sysfs entries for memory.
 Yours might be having a similar issue with the creation of /dev entries,
 so it would be worth trying it.

OK, compiling 3.10.11 with your patch right now.

 One thing to try would be to insert delays into the code involved in
 creating the /dev entries.  These delays will need to be busy-waits
 rather than sleeps.

Uh, I will have a look. But I'm no kernel developer. :)


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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hello,

On Mon, Sep 09, 2013 at 03:27:51PM -0700, Paul E. McKenney wrote:
> On Mon, Sep 09, 2013 at 11:58:36PM +0200, Jochen Striepe wrote:
> > I just got this on 3.10.11 on the same machine. Could that be
> > related?
> 
> Several people helped track down another source of spurious stall
> warnings on large systems, please see below for the patch.
[...]
> This is quite rare, but apparently occurs deterministically
> on systems with about 6TB of memory.

Hmm. My system is an ASUS Eee PC netbook with a total of 2G memory.
The latest stall was just when booting, while /dev was to be filled
by udev (and taking a really long time on that). So I think this
patch should not help at my machine, right?

I tried to reproduce the stall, but without success. Is there anything
that could help reproducing?

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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hello,

On Mon, Sep 09, 2013 at 03:27:51PM -0700, Paul E. McKenney wrote:
 On Mon, Sep 09, 2013 at 11:58:36PM +0200, Jochen Striepe wrote:
  I just got this on 3.10.11 on the same machine. Could that be
  related?
 
 Several people helped track down another source of spurious stall
 warnings on large systems, please see below for the patch.
[...]
 This is quite rare, but apparently occurs deterministically
 on systems with about 6TB of memory.

Hmm. My system is an ASUS Eee PC netbook with a total of 2G memory.
The latest stall was just when booting, while /dev was to be filled
by udev (and taking a really long time on that). So I think this
patch should not help at my machine, right?

I tried to reproduce the stall, but without success. Is there anything
that could help reproducing?

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

Re: Proposed stable release changes

[Jochen Striepe]

Hello,

just speaking as a user, not a developer.

On Wed, Aug 21, 2013 at 09:37:13AM -0400, Steven Rostedt wrote:
> First I want to say that I 100% support the idea of waiting at least one
> -rc. Maybe even two.

I think so, too. But ...

> Really, most fixes are for regressions.
[...]
> If people are not rushing to update their kernel to stable every time a
> new stable is released then why are we rushing to get them out?

... people are very different. Many just update here and then, but
there are those who do update on most stable releases. Those are the
ones you get feedback and testing from, and I think you should encourage
them to update as soon as a new -stable kernel is released. Getting
regression fixes fast sounds like a good encouragement especially for
people interested in the -stable series. Keeping the number of
regressions low is the whole point of -stable, right?

> Maybe people are rushing, but I don't update my main machines every
> stable release because I can't always afford the down time it causes me
> to do so.

On my server/router and on my desktop machine it's the same, those are
for daily work. But I have a netbook for playing around. :)


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

Re: Proposed stable release changes

[Jochen Striepe]

Hello,

just speaking as a user, not a developer.

On Wed, Aug 21, 2013 at 09:37:13AM -0400, Steven Rostedt wrote:
 First I want to say that I 100% support the idea of waiting at least one
 -rc. Maybe even two.

I think so, too. But ...

 Really, most fixes are for regressions.
[...]
 If people are not rushing to update their kernel to stable every time a
 new stable is released then why are we rushing to get them out?

... people are very different. Many just update here and then, but
there are those who do update on most stable releases. Those are the
ones you get feedback and testing from, and I think you should encourage
them to update as soon as a new -stable kernel is released. Getting
regression fixes fast sounds like a good encouragement especially for
people interested in the -stable series. Keeping the number of
regressions low is the whole point of -stable, right?

 Maybe people are rushing, but I don't update my main machines every
 stable release because I can't always afford the down time it causes me
 to do so.

On my server/router and on my desktop machine it's the same, those are
for daily work. But I have a netbook for playing around. :)


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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hello,

On Sun, Aug 18, 2013 at 11:02:32AM -0700, Paul E. McKenney wrote:
> On Tue, Aug 13, 2013 at 12:32:03PM +0200, Jochen Striepe wrote:
> > just hit this one. Please tell me if you need any more information.
> 
> If you wait for a few minutes after the first stall warning message,
> do you get a second one with a much larger "t=" number?  That would help
> work out what part of the stack trace is responsible for the stall.

There was no more log lines other than backlight values changing for
about half an hour after that, and I switched off thereafter.
Unfortunately, I was not able to reproduce that behaviour since.

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

Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks

[Jochen Striepe]

Hello,

On Sun, Aug 18, 2013 at 11:02:32AM -0700, Paul E. McKenney wrote:
 On Tue, Aug 13, 2013 at 12:32:03PM +0200, Jochen Striepe wrote:
  just hit this one. Please tell me if you need any more information.
 
 If you wait for a few minutes after the first stall warning message,
 do you get a second one with a much larger t= number?  That would help
 work out what part of the stack trace is responsible for the stall.

There was no more log lines other than backlight values changing for
about half an hour after that, and I switched off thereafter.
Unfortunately, I was not able to reproduce that behaviour since.

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

Re: [ 00/19] 3.10.1-stable review

[Jochen Striepe]

Hello,

On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote:
> I would suspect that machines that allow unprivileged users would be
> running distro kernels, and not the latest release from Linus, and thus
> even a bug that "can allow an unprivileged user to crash the kernel" may
> still be able to sit around for a month before being submitted.
> 
> This wouldn't be the case if the bug was in older kernels that are being
> used.

On the one hand, you seem to want users with any kind of production
systems to use distro kernels. On the other hand, developers want
a broad testing base, with vanilla kernels (or better, rc) as early
as possible. You cannot get both at the same time, some kinds of bugs
just appear on production systems.

Users expect vanilla .0 releases usable as production systems, to
be updated (meaning, no new features, just stabilizing) with the
corresponding -stable series.

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

Re: [ 00/19] 3.10.1-stable review

[Jochen Striepe]

Hello,

On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote:
 I would suspect that machines that allow unprivileged users would be
 running distro kernels, and not the latest release from Linus, and thus
 even a bug that can allow an unprivileged user to crash the kernel may
 still be able to sit around for a month before being submitted.
 
 This wouldn't be the case if the bug was in older kernels that are being
 used.

On the one hand, you seem to want users with any kind of production
systems to use distro kernels. On the other hand, developers want
a broad testing base, with vanilla kernels (or better, rc) as early
as possible. You cannot get both at the same time, some kinds of bugs
just appear on production systems.

Users expect vanilla .0 releases usable as production systems, to
be updated (meaning, no new features, just stabilizing) with the
corresponding -stable series.

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

Re: Write is not atomic?

[Jochen Striepe]

Hello,

On Mon, Oct 15, 2012 at 11:36:15PM +0200, Juliusz Chroboczek wrote:
> The Linux manual page for write(2) says:
> 
> The adjustment of the file offset and the write operation are
> performed as an atomic step.

This seems out of context.

Over here write(2) reads:

  If the file was open(2)ed with O_APPEND, the file offset is first
  set to the end of the file before writing.  The adjustment of the
  file offset and the write operation are performed as an atomic
  step.

Sounds different, doesn't it?


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

Re: Write is not atomic?

[Jochen Striepe]

Hello,

On Mon, Oct 15, 2012 at 11:36:15PM +0200, Juliusz Chroboczek wrote:
 The Linux manual page for write(2) says:
 
 The adjustment of the file offset and the write operation are
 performed as an atomic step.

This seems out of context.

Over here write(2) reads:

  If the file was open(2)ed with O_APPEND, the file offset is first
  set to the end of the file before writing.  The adjustment of the
  file offset and the write operation are performed as an atomic
  step.

Sounds different, doesn't it?


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

Re: Drop support for x86-32

[Jochen Striepe]

Hi,

On Sat, Aug 25, 2012 at 07:22:21PM +0200, wbrana wrote:
> On 8/25/12, Jochen Striepe  wrote:
> > You demand stuff. You offer nothing. You don't listen to the arguments
> > people very patiently explain to you.
> I replied to (almost) all arguments.

You wrote unrelated stuff.
Enough of this for me. *plonk*

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

Re: Drop support for x86-32

[Jochen Striepe]

Hi,

On Sat, Aug 25, 2012 at 01:52:42PM +0200, wbrana wrote:
> On 8/25/12, Bernd Petrovitsch  wrote:
> >> Firefox and Chromium are large applications and can't be fixed by one
> >> user.
> >
> > There are already people there. I doubt they will reject help from
> > others 
> Only experienced Firefox/Chromium developer can help. Users aren't
> useful as it will require major changes.

Let me get this straight. You don't see yourself capable of helping to
improve kernel or userland.

You demand stuff. You offer nothing. You don't listen to the arguments
people very patiently explain to you.

Why should anyone consider your proposal?


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

Re: Drop support for x86-32

[Jochen Striepe]

Hi,

On Sat, Aug 25, 2012 at 01:52:42PM +0200, wbrana wrote:
 On 8/25/12, Bernd Petrovitsch be...@petrovitsch.priv.at wrote:
  Firefox and Chromium are large applications and can't be fixed by one
  user.
 
  There are already people there. I doubt they will reject help from
  others 
 Only experienced Firefox/Chromium developer can help. Users aren't
 useful as it will require major changes.

Let me get this straight. You don't see yourself capable of helping to
improve kernel or userland.

You demand stuff. You offer nothing. You don't listen to the arguments
people very patiently explain to you.

Why should anyone consider your proposal?


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

Re: Drop support for x86-32

[Jochen Striepe]

Hi,

On Sat, Aug 25, 2012 at 07:22:21PM +0200, wbrana wrote:
 On 8/25/12, Jochen Striepe joc...@tolot.escape.de wrote:
  You demand stuff. You offer nothing. You don't listen to the arguments
  people very patiently explain to you.
 I replied to (almost) all arguments.

You wrote unrelated stuff.
Enough of this for me. *plonk*

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

Re: [PATCH] fs: Introducing Lanyard Filesystem

[Jochen Striepe]

Hi again,

On Sun, Aug 19, 2012 at 05:33:52PM +0200, Dan Luedtke wrote:
> - What filesystem would you recommend to share that video file?

You pointed out you tried ext3, so I thought ext3 was available on your
target platforms. I'm sorry I don't understand your reasoning about its
shortcomings.


So long,
Jochen.

P.S.: lan...@librelist.com removed from Cc: since it is obviously a
  closed list, answering my previous email with a subscription
  confirmation request.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs: Introducing Lanyard Filesystem

[Jochen Striepe]

Hello,

On Sun, Aug 19, 2012 at 03:34:24PM +0200, Dan Luedtke wrote:
> tried using ext3, but the ownership information from my workstation
> (were the file was copied from) did not match the ones the RaspberryPI
> had, since I usually do not synchronize user profiles between
> workstations and embedded devices. There are workarounds, one might say,

You wrote a new fs just because you didn't bother to use the existing
ones as intended?

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

Re: [PATCH] fs: Introducing Lanyard Filesystem

[Jochen Striepe]

Hello,

On Sun, Aug 19, 2012 at 03:34:24PM +0200, Dan Luedtke wrote:
 tried using ext3, but the ownership information from my workstation
 (were the file was copied from) did not match the ones the RaspberryPI
 had, since I usually do not synchronize user profiles between
 workstations and embedded devices. There are workarounds, one might say,

You wrote a new fs just because you didn't bother to use the existing
ones as intended?

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

Re: [PATCH] fs: Introducing Lanyard Filesystem

[Jochen Striepe]

Hi again,

On Sun, Aug 19, 2012 at 05:33:52PM +0200, Dan Luedtke wrote:
 - What filesystem would you recommend to share that video file?

You pointed out you tried ext3, so I thought ext3 was available on your
target platforms. I'm sorry I don't understand your reasoning about its
shortcomings.


So long,
Jochen.

P.S.: lan...@librelist.com removed from Cc: since it is obviously a
  closed list, answering my previous email with a subscription
  confirmation request.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
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

[Jochen Striepe]

Hi,

On 03 Mar 2005, Andrew Morton wrote:
> 2.6.x is making good progress but there have been a handful of prominent
> regressions which seem to be making people think that the whole process is
> bust.  I don't believe that this has been proven yet.

Sorry -- what you (with the vision of a kernel developer) are seeing
here surely is interesting, but it's not the point:

The point is what the *users* think. Just in case it still hasn't been
made clear enough in this thread: If your user base gets the impression
the development process isn't reliable any longer, you won't get your
kernel tested as much as you want.

Please remember why this thread started. It was a proposal to get more
users testing the rc kernels. 


So I hope the latest proposal really helps making releases contain fewer
surprises.


Greetings,

Jochen.
-- 
All I want is a warm bed and a kind word and unlimited power.
 -- Ashleigh Brilliant
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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

[Jochen Striepe]

Hi,

On 02 Mar 2005, Randy.Dunlap wrote:
> Maybe I don't understand?  Is someone expecting distro
> quality/stability from kernel.org kernels?
> I don't, but maybe I'm one of those minorities.

How do you expect a broad user base testing your kernels if "stable"
kernel.org kernels aren't to be expected stable?


Just my 2p,

Jochen.
-- 
Please place all complaints in this box --> []


pgpAYrHeu2dGW.pgp
Description: PGP signature

Re: RFD: Kernel release numbering

[Jochen Striepe]

Hi,

On 03 Mar 2005, Martin Schlemmer wrote:
[Why don't the rc's get the testing they need?]
> The first few -rc's was tested by the more conservative users, but then
> things broken on them, and they went "what the hell?  Is this a -rc?",
> and got the currently standard "sorry for your issues, but 2.6 -rc's
> *might* be release ready or it might be a accident ready to happen.
> Please check LKML for when Linus says to slow down" reply.  And how many
> of your more conservative users will start to read LKML for that?
> 
> So now you are basically sitting with a situation where -rc's really do
> not get the coverage they should, and 'stable' 2.6.x versions are really
> not that stable, with lots of excuses being thrown around - its the
> distro's job to make a stable kernel - comes to mind.  And you know what
> - your conservative users (which this horkage is all about) actually
> heard that via a friend/whoever that reads LKML.  The outcome? - many of
> them probably do not even test 2.6.x kernels anymore, but wait for the
> distro, or try -ac/-ck kernels until they get an issue there (the sound
> issue with fedora that was mentioned comes to mind).

Or they go back to 2.4 kernels. I agree 100% -- this is exactly what I
see when I look around over here.

Many thanks for finding the right words for what I had in mind!


Greetings,

Jochen.
-- 
Technology is a word that describes something that doesn't work yet.
-- Douglas Adams


pgpVr5T2sk8xz.pgp
Description: PGP signature

Re: Kernel release numbering

[Jochen Striepe]

Hi,

On 03 Mar 2005, Massimo Cetra wrote:
> So, why moving from 2.6.14 to 2.6.15 when, in 2/4 weeks, i'll have a more
> stable 2.6.16 ? 
> Will users help testing an odd release to have a good even release ? Or will
> they consider an even release as important as a -RC release ?

 From my experience this won't work (at least it won't work as inten-
ded). I see a tendency of people going away from Linux-2.6, going back
to Linux-2.4, or even going to one of the free BSD's. They go away
because they have the feeling they cannot rely any longer on the stabi-
lity of the 2.6 kernel branch (there are other issues, but this one is
common with most people I talked).

What you really need to avoid this (as far as I can see) is a stable
Kernel branch that does not give you a huge surprise every time you do
a kernel upgrade. Some mediocre statement like "this one might be quite
ok" is not enough -- you need to declare that 2.6.EVEN is *stable*, that
it is ready for production use. When people give it a test, fix the bugs
they find, and release anew without adding any other "improvements". This
way the user gets the least surprises when doing the next update -- and
that is what gets you more users on 2.6: the users will feel they can
*rely* on the stable releases.

At least that's how it looks here. And yes, I *know* it's harder to do
development when you're stuck with maintaining a stable branch. It's
your choice.


Greetings,

Jochen.
-- 
I worry about my child and the Internet all the time, even though she's too
young to have logged on yet.  Here's what I worry about.  I worry that 10 or
15 years from now, she will come to me and say "Daddy, where were you when
they took freedom of the press away from the Internet?" -Mike Godwin


pgpE3bIu6zsam.pgp
Description: PGP signature

Re: RFD: Kernel release numbering

[Jochen Striepe]

Hi,

On 03 Mar 2005, Andrew Morton wrote:
 2.6.x is making good progress but there have been a handful of prominent
 regressions which seem to be making people think that the whole process is
 bust.  I don't believe that this has been proven yet.

Sorry -- what you (with the vision of a kernel developer) are seeing
here surely is interesting, but it's not the point:

The point is what the *users* think. Just in case it still hasn't been
made clear enough in this thread: If your user base gets the impression
the development process isn't reliable any longer, you won't get your
kernel tested as much as you want.

Please remember why this thread started. It was a proposal to get more
users testing the rc kernels. 


So I hope the latest proposal really helps making releases contain fewer
surprises.


Greetings,

Jochen.
-- 
All I want is a warm bed and a kind word and unlimited power.
 -- Ashleigh Brilliant
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Kernel release numbering

[Jochen Striepe]

Hi,

On 03 Mar 2005, Massimo Cetra wrote:
 So, why moving from 2.6.14 to 2.6.15 when, in 2/4 weeks, i'll have a more
 stable 2.6.16 ? 
 Will users help testing an odd release to have a good even release ? Or will
 they consider an even release as important as a -RC release ?

 From my experience this won't work (at least it won't work as inten-
ded). I see a tendency of people going away from Linux-2.6, going back
to Linux-2.4, or even going to one of the free BSD's. They go away
because they have the feeling they cannot rely any longer on the stabi-
lity of the 2.6 kernel branch (there are other issues, but this one is
common with most people I talked).

What you really need to avoid this (as far as I can see) is a stable
Kernel branch that does not give you a huge surprise every time you do
a kernel upgrade. Some mediocre statement like this one might be quite
ok is not enough -- you need to declare that 2.6.EVEN is *stable*, that
it is ready for production use. When people give it a test, fix the bugs
they find, and release anew without adding any other improvements. This
way the user gets the least surprises when doing the next update -- and
that is what gets you more users on 2.6: the users will feel they can
*rely* on the stable releases.

At least that's how it looks here. And yes, I *know* it's harder to do
development when you're stuck with maintaining a stable branch. It's
your choice.


Greetings,

Jochen.
-- 
I worry about my child and the Internet all the time, even though she's too
young to have logged on yet.  Here's what I worry about.  I worry that 10 or
15 years from now, she will come to me and say Daddy, where were you when
they took freedom of the press away from the Internet? -Mike Godwin


pgpE3bIu6zsam.pgp
Description: PGP signature

Re: RFD: Kernel release numbering

[Jochen Striepe]

Hi,

On 03 Mar 2005, Martin Schlemmer wrote:
[Why don't the rc's get the testing they need?]
 The first few -rc's was tested by the more conservative users, but then
 things broken on them, and they went what the hell?  Is this a -rc?,
 and got the currently standard sorry for your issues, but 2.6 -rc's
 *might* be release ready or it might be a accident ready to happen.
 Please check LKML for when Linus says to slow down reply.  And how many
 of your more conservative users will start to read LKML for that?
 
 So now you are basically sitting with a situation where -rc's really do
 not get the coverage they should, and 'stable' 2.6.x versions are really
 not that stable, with lots of excuses being thrown around - its the
 distro's job to make a stable kernel - comes to mind.  And you know what
 - your conservative users (which this horkage is all about) actually
 heard that via a friend/whoever that reads LKML.  The outcome? - many of
 them probably do not even test 2.6.x kernels anymore, but wait for the
 distro, or try -ac/-ck kernels until they get an issue there (the sound
 issue with fedora that was mentioned comes to mind).

Or they go back to 2.4 kernels. I agree 100% -- this is exactly what I
see when I look around over here.

Many thanks for finding the right words for what I had in mind!


Greetings,

Jochen.
-- 
Technology is a word that describes something that doesn't work yet.
-- Douglas Adams


pgpVr5T2sk8xz.pgp
Description: PGP signature

Re: RFD: Kernel release numbering

[Jochen Striepe]

Hi,

On 02 Mar 2005, Randy.Dunlap wrote:
 Maybe I don't understand?  Is someone expecting distro
 quality/stability from kernel.org kernels?
 I don't, but maybe I'm one of those minorities.

How do you expect a broad user base testing your kernels if stable
kernel.org kernels aren't to be expected stable?


Just my 2p,

Jochen.
-- 
Please place all complaints in this box -- []


pgpAYrHeu2dGW.pgp
Description: PGP signature

Re: Linux 2.2.20-pre4

[Jochen Striepe]

Hi again,

On 19 Jun 2001, Jochen Striepe <[EMAIL PROTECTED]> wrote:
> 
> Now it stops with

OK, this resolved to nothing (my mistake). Now it works fine. Until it
reaches

ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext 
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o 
ipc/ipc.o \
fs/filesystems.a \
net/network.a \
drivers/block/block.a drivers/char/char.o drivers/misc/misc.a 
drivers/net/net.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a drivers/pci/pci.a 
drivers/pnp/pnp.a drivers/video/video.a \
/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a 
/usr/src/linux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
drivers/scsi/scsi.a(aic7xxx.o): In function `aic7xxx_load_seeprom':
aic7xxx.o(.text+0x12a76): undefined reference to `memcpy'
make: *** [vmlinux] Error 1


HAND,

Jochen.

-- 
"Gosh that takes me back ... or forward.  That's the trouble with time
travel, you never can tell."
-- Dr. Who
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.2.20-pre4

[Jochen Striepe]

Hi,

On 19 Jun 2001, Alan Cox <[EMAIL PROTECTED]> wrote:
> 
> > sched.c:52: conflicting types for `xtime'
> > /usr/src/linux/include/linux/sched.h:509: previous declaration of `xtime'
> 
> Stick a volatile in the declaration. Thats a real bug it found

Um...

I made it

extern volatile struct timeval xtime;

Now it stops with

/usr/src/linux/include/linux/sched.h: At top level:
/usr/src/linux/include/linux/sched.h:509: warning: useless keyword or
type name in empty declaration
In file included from /usr/src/linux/include/linux/blkdev.h:6,
 from ksyms.c:15:
/usr/src/linux/include/linux/genhd.h: In function `ptype':
/usr/src/linux/include/linux/genhd.h:83: warning: deprecated use of
label at end of compound statement
ksyms.c: At top level:
ksyms.c:352: `xtime' undeclared here (not in a function)
ksyms.c:352: initializer element is not constant
ksyms.c:352: (near initialization for `__ksymtab_xtime.value')
make[2]: *** [ksyms.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.2.20pre4/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux-2.2.20pre4/kernel'
make: *** [_dir_kernel] Error 2


So long,

Jochen.

-- 
The number of UNIX installations has grown to 10, with more expected.
 - Dennis Ritchie and Ken Thompson, June 1972
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.2.20-pre4

[Jochen Striepe]

Hi,

On 19 Jun 2001, Alan Cox <[EMAIL PROTECTED]> wrote:
> 
> 2.2.20pre4

Just to keep you informed... (I think there was a saying that there was
interest in experiences with compiling the kernel with non-recommended
gcc's ...)

I tried the newly released gcc-3.0 compiling 2.2.20pre4 (yes, I _know_ it
is not recommended): 

/usr/src/linux/include/linux/signal.h: In function `siginitset':
/usr/src/linux/include/linux/signal.h:193: warning: deprecated use of label at end of 
compound statement
/usr/src/linux/include/linux/signal.h: In function `siginitsetinv':
/usr/src/linux/include/linux/signal.h:205: warning: deprecated use of label at end of 
compound statement
sched.c: At top level:
sched.c:52: conflicting types for `xtime'
/usr/src/linux/include/linux/sched.h:509: previous declaration of `xtime'
sched.c: In function `schedule':
sched.c:739: warning: deprecated use of label at end of compound statement
make[2]: *** [sched.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.2.20pre4/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux-2.2.20pre4/kernel'
make: *** [_dir_kernel] Error 2


$ sh /usr/src/linux/scripts/ver_linux 
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux tolot 2.4.6-pre3 #1 Wed Jun 13 09:55:57 CEST 2001 i586 unknown
 
Gnu C  3.0
Gnu make   3.79.1
binutils   2.11.1
util-linux 2.11f
mount  2.11f
modutils   2.4.6
e2fsprogs  1.21
PPP2.4.1
Linux C Library2.2.3
Dynamic linker (ldd)   2.2.3
Procps 2.0.7
Net-tools  1.60
Kbd1.06
Sh-utils   2.0.11
Modules Loaded nls_utf8 nls_iso8859-15 nls_iso8859-2
nls_iso8859-1 nls_cp852 nls_cp850 nls_cp437 floppy sr_mod sg isofs
ne2k-pci 8390 ide-cd cdrom adlib_card opl3 sb sb_lib uart401 sound
soundcore ppp_generic slhc lp parport serial


So long,

Jochen.

-- 
Cahn's Axiom:
When all else fails, read the instructions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.2.20-pre4

[Jochen Striepe]

Hi,

On 19 Jun 2001, Alan Cox [EMAIL PROTECTED] wrote:
 
 2.2.20pre4

Just to keep you informed... (I think there was a saying that there was
interest in experiences with compiling the kernel with non-recommended
gcc's ...)

I tried the newly released gcc-3.0 compiling 2.2.20pre4 (yes, I _know_ it
is not recommended): 

/usr/src/linux/include/linux/signal.h: In function `siginitset':
/usr/src/linux/include/linux/signal.h:193: warning: deprecated use of label at end of 
compound statement
/usr/src/linux/include/linux/signal.h: In function `siginitsetinv':
/usr/src/linux/include/linux/signal.h:205: warning: deprecated use of label at end of 
compound statement
sched.c: At top level:
sched.c:52: conflicting types for `xtime'
/usr/src/linux/include/linux/sched.h:509: previous declaration of `xtime'
sched.c: In function `schedule':
sched.c:739: warning: deprecated use of label at end of compound statement
make[2]: *** [sched.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.2.20pre4/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux-2.2.20pre4/kernel'
make: *** [_dir_kernel] Error 2


$ sh /usr/src/linux/scripts/ver_linux 
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux tolot 2.4.6-pre3 #1 Wed Jun 13 09:55:57 CEST 2001 i586 unknown
 
Gnu C  3.0
Gnu make   3.79.1
binutils   2.11.1
util-linux 2.11f
mount  2.11f
modutils   2.4.6
e2fsprogs  1.21
PPP2.4.1
Linux C Library2.2.3
Dynamic linker (ldd)   2.2.3
Procps 2.0.7
Net-tools  1.60
Kbd1.06
Sh-utils   2.0.11
Modules Loaded nls_utf8 nls_iso8859-15 nls_iso8859-2
nls_iso8859-1 nls_cp852 nls_cp850 nls_cp437 floppy sr_mod sg isofs
ne2k-pci 8390 ide-cd cdrom adlib_card opl3 sb sb_lib uart401 sound
soundcore ppp_generic slhc lp parport serial


So long,

Jochen.

-- 
Cahn's Axiom:
When all else fails, read the instructions.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.2.20-pre4

[Jochen Striepe]

Hi,

On 19 Jun 2001, Alan Cox [EMAIL PROTECTED] wrote:
 
  sched.c:52: conflicting types for `xtime'
  /usr/src/linux/include/linux/sched.h:509: previous declaration of `xtime'
 
 Stick a volatile in the declaration. Thats a real bug it found

Um...

I made it

extern volatile struct timeval xtime;

Now it stops with

/usr/src/linux/include/linux/sched.h: At top level:
/usr/src/linux/include/linux/sched.h:509: warning: useless keyword or
type name in empty declaration
In file included from /usr/src/linux/include/linux/blkdev.h:6,
 from ksyms.c:15:
/usr/src/linux/include/linux/genhd.h: In function `ptype':
/usr/src/linux/include/linux/genhd.h:83: warning: deprecated use of
label at end of compound statement
ksyms.c: At top level:
ksyms.c:352: `xtime' undeclared here (not in a function)
ksyms.c:352: initializer element is not constant
ksyms.c:352: (near initialization for `__ksymtab_xtime.value')
make[2]: *** [ksyms.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.2.20pre4/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux-2.2.20pre4/kernel'
make: *** [_dir_kernel] Error 2


So long,

Jochen.

-- 
The number of UNIX installations has grown to 10, with more expected.
 - Dennis Ritchie and Ken Thompson, June 1972
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.2.20-pre4

[Jochen Striepe]

Hi again,

On 19 Jun 2001, Jochen Striepe [EMAIL PROTECTED] wrote:
 
 Now it stops with

OK, this resolved to nothing (my mistake). Now it works fine. Until it
reaches

ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext 
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o 
ipc/ipc.o \
fs/filesystems.a \
net/network.a \
drivers/block/block.a drivers/char/char.o drivers/misc/misc.a 
drivers/net/net.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a drivers/pci/pci.a 
drivers/pnp/pnp.a drivers/video/video.a \
/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a 
/usr/src/linux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
drivers/scsi/scsi.a(aic7xxx.o): In function `aic7xxx_load_seeprom':
aic7xxx.o(.text+0x12a76): undefined reference to `memcpy'
make: *** [vmlinux] Error 1


HAND,

Jochen.

-- 
Gosh that takes me back ... or forward.  That's the trouble with time
travel, you never can tell.
-- Dr. Who
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

AVM Fritz! PCI v2.0

[Jochen Striepe]

Hello,

is there any Linux driver for the AVM Fritz! PCI v2.0 ISDN card
available? Using vanilla 2.2.19's HiSax driver doesn't seem to work,
and I found nothing at AVM's web page [1]. Did I miss someting?


Greetings from Germany,
and thanks in advance,

Jochen.

[1] http://www.avm.de/

-- 
To get something done, a committee should consist of no more than three
men, two of them absent.

 PGP signature

AVM Fritz! PCI v2.0

[Jochen Striepe]

Hello,

is there any Linux driver for the AVM Fritz! PCI v2.0 ISDN card
available? Using vanilla 2.2.19's HiSax driver doesn't seem to work,
and I found nothing at AVM's web page [1]. Did I miss someting?


Greetings from Germany,
and thanks in advance,

Jochen.

[1] http://www.avm.de/

-- 
To get something done, a committee should consist of no more than three
men, two of them absent.

 PGP signature

2.4.4-pre6 does not compile

[Jochen Striepe]

Hi,

2.4.4-pre6 actually is the 4th 2.4.4pre-Patch that does not compile
without further patching on my system. :-(


ld -m elf_i386 -T /usr/src/linux-2.4.4-pre6/arch/i386/vmlinux.lds -e stext 
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o 
ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o 
drivers/net/net.o drivers/media/media.o  drivers/ide/idedriver.o 
drivers/scsi/scsidrv.o drivers/scsi/aic7xxx/aic7xxx_drv.o drivers/cdrom/driver.o 
drivers/pci/driver.o drivers/video/video.o \
net/network.o \
/usr/src/linux-2.4.4-pre6/arch/i386/lib/lib.a 
/usr/src/linux-2.4.4-pre6/lib/lib.a /usr/src/linux-2.4.4-pre6/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
/usr/src/linux-2.4.4-pre6/lib/lib.a(rwsem.o): In function `__rwsem_do_wake':
rwsem.o(.text+0x30): undefined reference to `__builtin_expect'
rwsem.o(.text+0x73): undefined reference to `__builtin_expect'
make: *** [vmlinux] Error 1


Output from `grep -v ^$ .config | grep -v ^#`:

CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_MK6=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_GOBIOS=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_NAMES=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_1284=y
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETFILTER=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_SYN_COOKIES=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
CONFIG_BLK_DEV_SR=m
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=8
CONFIG_AIC7XXX_RESET_DELAY=5
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_PCI=y
CONFIG_NE2K_PCI=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_ISDN=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_PPP_BSDCOMP=m
CONFIG_ISDN_DRV_HISAX=m
CONFIG_HISAX_EURO=y
CONFIG_HISAX_FRITZPCI=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=m
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_MINIX_FS=m
CONFIG_NTFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_SOUND=m
CONFIG_SOUND_OSS=m
CONFIG_SOUND_TRACEINIT=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_ADLIB=m
CONFIG_SOUND_SB=m
CONFIG_SOUND_YM3812=m


Output from `sh scripts/ver_linux`:

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux tolot 2.4.4-pre5 #2 Fri Apr 20 08:32:13 CEST 2001 i586 unknown
 
Gnu C  2.95.3
Gnu make   3.79.1
binutils   2.11.90.0.5
util-linux 2.11b
mount  2.11b
modutils   2.4.5
e2fsprogs  1.19
pcmcia-cs  3.0.14
PPP2.4.1
isdn4k-utils   3.1pre1
Linux C Library2.1.3
ldd: version 1.9.9
Procps 2.0.7
Net-tools  1.60
Kbd0.99
Sh-utils   2.0.11
Modules Loaded nls_utf8 nls_iso8859-15 nls_iso8859-2 nls_iso8859-1 nls_cp852 
nls_cp850 nls_cp437 floppy sr_mod sg isofs ne2k-pci 8390 ide-cd cdrom adlib_card opl3 
sb sb_lib uart401 sound soundcore lp parport serial



TIA,

Jochen Striepe.

-- 
Never send a man where you can send a bullet.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.4.4-pre6 does not compile

[Jochen Striepe]

Hi,

2.4.4-pre6 actually is the 4th 2.4.4pre-Patch that does not compile
without further patching on my system. :-(


ld -m elf_i386 -T /usr/src/linux-2.4.4-pre6/arch/i386/vmlinux.lds -e stext 
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o 
ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o 
drivers/net/net.o drivers/media/media.o  drivers/ide/idedriver.o 
drivers/scsi/scsidrv.o drivers/scsi/aic7xxx/aic7xxx_drv.o drivers/cdrom/driver.o 
drivers/pci/driver.o drivers/video/video.o \
net/network.o \
/usr/src/linux-2.4.4-pre6/arch/i386/lib/lib.a 
/usr/src/linux-2.4.4-pre6/lib/lib.a /usr/src/linux-2.4.4-pre6/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
/usr/src/linux-2.4.4-pre6/lib/lib.a(rwsem.o): In function `__rwsem_do_wake':
rwsem.o(.text+0x30): undefined reference to `__builtin_expect'
rwsem.o(.text+0x73): undefined reference to `__builtin_expect'
make: *** [vmlinux] Error 1


Output from `grep -v ^$ .config | grep -v ^#`:

CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_MK6=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_GOBIOS=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_NAMES=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_1284=y
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETFILTER=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_SYN_COOKIES=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
CONFIG_BLK_DEV_SR=m
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=8
CONFIG_AIC7XXX_RESET_DELAY=5
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_PCI=y
CONFIG_NE2K_PCI=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_ISDN=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_PPP_BSDCOMP=m
CONFIG_ISDN_DRV_HISAX=m
CONFIG_HISAX_EURO=y
CONFIG_HISAX_FRITZPCI=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=m
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_MINIX_FS=m
CONFIG_NTFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_SOUND=m
CONFIG_SOUND_OSS=m
CONFIG_SOUND_TRACEINIT=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_ADLIB=m
CONFIG_SOUND_SB=m
CONFIG_SOUND_YM3812=m


Output from `sh scripts/ver_linux`:

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux tolot 2.4.4-pre5 #2 Fri Apr 20 08:32:13 CEST 2001 i586 unknown
 
Gnu C  2.95.3
Gnu make   3.79.1
binutils   2.11.90.0.5
util-linux 2.11b
mount  2.11b
modutils   2.4.5
e2fsprogs  1.19
pcmcia-cs  3.0.14
PPP2.4.1
isdn4k-utils   3.1pre1
Linux C Library2.1.3
ldd: version 1.9.9
Procps 2.0.7
Net-tools  1.60
Kbd0.99
Sh-utils   2.0.11
Modules Loaded nls_utf8 nls_iso8859-15 nls_iso8859-2 nls_iso8859-1 nls_cp852 
nls_cp850 nls_cp437 floppy sr_mod sg isofs ne2k-pci 8390 ide-cd cdrom adlib_card opl3 
sb sb_lib uart401 sound soundcore lp parport serial



TIA,

Jochen Striepe.

-- 
Never send a man where you can send a bullet.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Jochen Striepe]

Hi,

On 12 Apr 2001, Steven Cole <[EMAIL PROTECTED]> wrote:
> 
> Excuse me, but this seems to be something of a red herring.  I've got
> a crowd of Pentium-90 and 100 machines at work, and they get new kernels
> occasionally, but I haven't built a kernel using that class of machine
> in 5 years or so.  I build new kernels using a dual 733 PIII.  Just for
> "fun", I built a kernel using a uniprocessor 266 PII a few months ago, but
> I have much better things to do with my time.

I have an AMD K6/2-400. But I do know _many_ people who do own slower
Hardware, and run Linux on it. They do not want and cannot afford to buy
the newest shiny box. And, they have better things to do with their time
as well. Please note, I live in a country where people are not _poor_.
Just think of others some time, not only of yourself. 


So long,

Jochen Striepe.

-- 
"He was so narrow minded he could see through a keyhole with both
eyes ..."


 PGP signature

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Jochen Striepe]

Hi,

On 12 Apr 2001, Steven Cole [EMAIL PROTECTED] wrote:
 
 Excuse me, but this seems to be something of a red herring.  I've got
 a crowd of Pentium-90 and 100 machines at work, and they get new kernels
 occasionally, but I haven't built a kernel using that class of machine
 in 5 years or so.  I build new kernels using a dual 733 PIII.  Just for
 "fun", I built a kernel using a uniprocessor 266 PII a few months ago, but
 I have much better things to do with my time.

I have an AMD K6/2-400. But I do know _many_ people who do own slower
Hardware, and run Linux on it. They do not want and cannot afford to buy
the newest shiny box. And, they have better things to do with their time
as well. Please note, I live in a country where people are not _poor_.
Just think of others some time, not only of yourself. 


So long,

Jochen Striepe.

-- 
"He was so narrow minded he could see through a keyhole with both
eyes ..."


 PGP signature

Re: gcc-2.95.3

[Jochen Striepe]

Hi,

On 06 Apr 2001, Jeff Chua <[EMAIL PROTECTED]> wrote:
> 
> Does anybody have bad experience with gcc-2.95.3?
> 
> I'm using gcc-2.95.2 with linux 2.4.3 and have no problem with it.

I'm using gcc-2.95.3 for kernel compilation on latest 2.4.x since it's
out. Never had any Problem.


Linux tolot 2.4.3 #1 Fri Mar 30 09:35:17 CEST 2001 i586 unknown
 
Gnu C  2.95.3
Gnu make   3.79.1
binutils   2.11.90.0.4
util-linux 2.11b
modutils   2.4.5
e2fsprogs  1.19
pcmcia-cs  3.0.14
PPP2.4.0
isdn4k-utils   3.1pre1
Linux C Library2.1.3
ldd: version 1.9.9
Procps 2.0.7
Net-tools  1.59
Kbd0.99
Sh-utils   2.0.11
Modules Loaded nls_utf8 nls_iso8859-15 nls_iso8859-2
nls_iso8859-1 nls_cp852 nls_cp850 nls_cp437 floppy sr_mod sg isofs
ne2k-pci 8390 ide-cd cdrom adlib_card opl3 sb sb_lib uart401 sound
soundcore lp parport serial


Hth,

Jochen.

-- 
"I was gratified to be able to answer promptly, and I did. I said I
didn't know." -- Mark Twain

 PGP signature

Re: gcc-2.95.3

[Jochen Striepe]

Hi,

On 06 Apr 2001, Jeff Chua [EMAIL PROTECTED] wrote:
 
 Does anybody have bad experience with gcc-2.95.3?
 
 I'm using gcc-2.95.2 with linux 2.4.3 and have no problem with it.

I'm using gcc-2.95.3 for kernel compilation on latest 2.4.x since it's
out. Never had any Problem.


Linux tolot 2.4.3 #1 Fri Mar 30 09:35:17 CEST 2001 i586 unknown
 
Gnu C  2.95.3
Gnu make   3.79.1
binutils   2.11.90.0.4
util-linux 2.11b
modutils   2.4.5
e2fsprogs  1.19
pcmcia-cs  3.0.14
PPP2.4.0
isdn4k-utils   3.1pre1
Linux C Library2.1.3
ldd: version 1.9.9
Procps 2.0.7
Net-tools  1.59
Kbd0.99
Sh-utils   2.0.11
Modules Loaded nls_utf8 nls_iso8859-15 nls_iso8859-2
nls_iso8859-1 nls_cp852 nls_cp850 nls_cp437 floppy sr_mod sg isofs
ne2k-pci 8390 ide-cd cdrom adlib_card opl3 sb sb_lib uart401 sound
soundcore lp parport serial


Hth,

Jochen.

-- 
"I was gratified to be able to answer promptly, and I did. I said I
didn't know." -- Mark Twain

 PGP signature

Re: [PATCH] modify ver_linux to check e2fsprogs and more.

[Jochen Striepe]

Hi,

On 08 Feb 2001, Steven Cole <[EMAIL PROTECTED]> wrote:
> 
> But, there is an easy solution:
> [root@localhost scripts]# ifconfig --version
> net-tools 1.57
> ifconfig 1.40 (2000-05-21)
> 
> I replaced the old code for Net-tools with this:
> 
> ifconfig --version 2>&1 | grep tools | awk \
> 'NR==1{print "Net-tools ", $NF}'
> 
> That should work.  I hope.  Try it please.

This works great for me. Thanks!


Greetings from Germany,

Jochen Striepe.

-- 
"Gosh that takes me back ... or forward.  That's the trouble with time
travel, you never can tell."
-- Dr. Who


 PGP signature

Re: [PATCH] modify ver_linux to check e2fsprogs and more.

[Jochen Striepe]

Hi,

On 08 Feb 2001, Steven Cole <[EMAIL PROTECTED]> wrote:
> I have modified the scripts/ver_linux script to provide the following:
>
[...]
>
> hostname -V 2>&1 | awk 'NR==1{print "Net-tools ", $NF}'

*Please* consider modifying this. There might be a problem:


tolot:/root # hostname -V
tolot:/root # hostname
-V
tolot:/root # hostname --version
hostname (GNU sh-utils) 2.0.11
Written by Jim Meyering.

Copyright (C) 2000 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Greetings from Germany,

Jochen Striepe

-- 
The number of UNIX installations has grown to 10, with more expected.
 - Dennis Ritchie and Ken Thompson, June 1972


 PGP signature

Re: [PATCH] modify ver_linux to check e2fsprogs and more.

[Jochen Striepe]

Hi,

On 08 Feb 2001, Steven Cole [EMAIL PROTECTED] wrote:
 I have modified the scripts/ver_linux script to provide the following:

[...]

 hostname -V 21 | awk 'NR==1{print "Net-tools ", $NF}'

*Please* consider modifying this. There might be a problem:


tolot:/root # hostname -V
tolot:/root # hostname
-V
tolot:/root # hostname --version
hostname (GNU sh-utils) 2.0.11
Written by Jim Meyering.

Copyright (C) 2000 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Greetings from Germany,

Jochen Striepe

-- 
The number of UNIX installations has grown to 10, with more expected.
 - Dennis Ritchie and Ken Thompson, June 1972


 PGP signature

Re: [PATCH] modify ver_linux to check e2fsprogs and more.

[Jochen Striepe]

Hi,

On 08 Feb 2001, Steven Cole [EMAIL PROTECTED] wrote:
 
 But, there is an easy solution:
 [root@localhost scripts]# ifconfig --version
 net-tools 1.57
 ifconfig 1.40 (2000-05-21)
 
 I replaced the old code for Net-tools with this:
 
 ifconfig --version 21 | grep tools | awk \
 'NR==1{print "Net-tools ", $NF}'
 
 That should work.  I hope.  Try it please.

This works great for me. Thanks!


Greetings from Germany,

Jochen Striepe.

-- 
"Gosh that takes me back ... or forward.  That's the trouble with time
travel, you never can tell."
-- Dr. Who


 PGP signature

Re: 2.2.17 wont compile on AMD k6@-550

[Jochen Striepe]

Hi,

On 10 Nov 2000, root <[EMAIL PROTECTED]> wrote:
> 
> cc: Internal compiler error: program cc1 got fatal signal 11

http://www.bitwizard.nl/sig11/


Have fun,

Jochen.

-- 
FAQ zur Newsgroup at.linux:



 PGP signature

Re: 2.2.17 wont compile on AMD k6@-550

[Jochen Striepe]

Hi,

On 10 Nov 2000, root [EMAIL PROTECTED] wrote:
 
 cc: Internal compiler error: program cc1 got fatal signal 11

http://www.bitwizard.nl/sig11/


Have fun,

Jochen.

-- 
FAQ zur Newsgroup at.linux:
http://alfie.ist.org/LinuxFAQ/


 PGP signature