objtool segfault in 5.10 kernels with binutils-2.36.1

[Ken Moffat]

Hi,

in 5.10 kernels up to and including 5.10.15 when trying to build the
kernel for an x86_64 skylake using binutils-2.36.1, gcc-10.2 and
glibic-2.33 I get a segfault in objtool if the orc unwinder is
enabled.

This has already been fixed in 5.11 by ''objtool: Fix seg fault with
Clang non-section symbols'
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=44f6a7c0755d8dd453c70557e11687bb080a6f21

So can this be added to 5.10 stable, please ?

Please CC me as I am no-longer subscribed.

ĸen

Re: Recommended driver for current AMD processors

[Ken Moffat]

Hi Paul,

On Fri, 7 Dec 2018 at 15:32, Paul Menzel  wrote:
>
> Dear Linux folks,
>
>
> What driver is recommended for current AMD Ryzen based processors
> like *AMD Ryzen 5 PRO 1500 Quad-Core Processor* or *AMD EPYC 7601
> 32-Core Processor*?
>
> Only from the acpi-cpufreq Kconfig description, I assume, that that
> driver should be used.
>
> > config X86_ACPI_CPUFREQ
> > tristate "ACPI Processor P-States driver"
> > depends on ACPI_PROCESSOR
> > help
> >   This driver adds a CPUFreq driver which utilizes the ACPI
> >   Processor Performance States.
> >   This driver also supports Intel Enhanced Speedstep and newer
> >   AMD CPUs.
> >
> >   To compile this driver as a module, choose M here: the
> >   module will be called acpi-cpufreq.
> >
> >   For details, take a look at .
> >
> >   If in doubt, say N.
>
> Would a “native” driver like Intel’s P state driver also give better
> results? Do you know if AMD is working on something like that?
>
>
>
> Kind regards,
>
> Paul
>

As a mere user, I bought a ryzen 3 1300X earlier this year, and was
annoyed about how the frequencies changed when a single-threaded
compile moved to a different core (unlike e.g. a haswell where
frequencies barely vary).

I have a meter which can report the current power consumption
for the system (computer, monitor, network switch, kvm switch), and
using that to keep an eye on the range of reported wattages when idle,
compiling with -j1 and compiling with -j4, I eventually formed the
impression that the ondemand governor was marginally better than
the performance governor, and that omitting cpufreq did not appear to
increase the poer consumption.

But that is just one set of observations.  I agree that using less
power and getting faster compiles would be nice, so if something is
available I'll be keen to try it.

ĸen

Re: Recommended driver for current AMD processors

[Ken Moffat]

Hi Paul,

On Fri, 7 Dec 2018 at 15:32, Paul Menzel  wrote:
>
> Dear Linux folks,
>
>
> What driver is recommended for current AMD Ryzen based processors
> like *AMD Ryzen 5 PRO 1500 Quad-Core Processor* or *AMD EPYC 7601
> 32-Core Processor*?
>
> Only from the acpi-cpufreq Kconfig description, I assume, that that
> driver should be used.
>
> > config X86_ACPI_CPUFREQ
> > tristate "ACPI Processor P-States driver"
> > depends on ACPI_PROCESSOR
> > help
> >   This driver adds a CPUFreq driver which utilizes the ACPI
> >   Processor Performance States.
> >   This driver also supports Intel Enhanced Speedstep and newer
> >   AMD CPUs.
> >
> >   To compile this driver as a module, choose M here: the
> >   module will be called acpi-cpufreq.
> >
> >   For details, take a look at .
> >
> >   If in doubt, say N.
>
> Would a “native” driver like Intel’s P state driver also give better
> results? Do you know if AMD is working on something like that?
>
>
>
> Kind regards,
>
> Paul
>

As a mere user, I bought a ryzen 3 1300X earlier this year, and was
annoyed about how the frequencies changed when a single-threaded
compile moved to a different core (unlike e.g. a haswell where
frequencies barely vary).

I have a meter which can report the current power consumption
for the system (computer, monitor, network switch, kvm switch), and
using that to keep an eye on the range of reported wattages when idle,
compiling with -j1 and compiling with -j4, I eventually formed the
impression that the ondemand governor was marginally better than
the performance governor, and that omitting cpufreq did not appear to
increase the poer consumption.

But that is just one set of observations.  I agree that using less
power and getting faster compiles would be nice, so if something is
available I'll be keen to try it.

ĸen

Re: [Ksummit-discuss] bug-introducing patches

[Ken Moffat]

On 8 May 2018 at 21:29, Sasha Levin  wrote:

>
> This is interesting. We have a group of power users who are testing out
> -rc releases, who are usually happy to test out a fast moving target and
> provide helpful reports back. We also have a group who run a -stable
> kernel (-stable build/distro/android/etc) who want to avoid having to
> report bugs to us.
>
> What we don't have is a group of people who use Linus's actual releases
> (not the -rc stuff, but the actual point releases). Power users will
> move on to the next kernel, and -stable folks won't touch that release
> until there's a corresponding -stable.

I resent that assumption :)

As a 'prosumer' in this context, I try to test an early -rc (usually
not until -rc2, sometimes not until later, depending on what I see on
this list), and then intermittently I spread the testing to more of my
desktop machines using later -rc versions. Once linus releases .0 I
hope to move my current systems to that in the next few days. But as
always, other things (sometimes real life, sometimes just new changes
in userspace) intervene.

After that, I will pick up Greg's latest if I build a new system
before the next kernel release, or if I become aware of something
critical (for my usage) in it.  And then probably 4 or 5 weeks after
linus's release I will start the next cycle of testing -rc verisons.

So no, I rarely test Greg's current stable version, but there _is_ a
period of some weeks where I run .0 kernels.

ĸen


>
> Even rawhide, like Josh mentioned, will just fill back with the merge
> window commits after the release of an older kernel.
>
> So the problem I'm seeing is that since a merge window is open only once
> every 2-3 months people will sometimes try to push poorly tested code
> just to make that merge window. Additionally, as later -rc releases
> start showing up people will again merge poorly tested fixes just to
> make it in time for that release.
>
> For both cases, people will push poorly tested code in the kernel just
> because they want to make it in time for a kernel release that no one
> will actually use.
>
> What if, instead, Linus doesn't actually ever release a point release?
> We can make the merge window open more often, and since there's no
> actual release, people won't rush to push fixes in later -rc cycles.
>
> We take away the incentive to push poorly tested code. Maintainers still
> free to commit anything they'd like, but there's no reason to commit
> code they're not confident of just to make it to a random release no one
> will use.
>
> Merge window will happen more often, so there's no real reason to rush
> things in a particular window, and since -stable releases every week
> there's no rush to push a fix in since the next release is just a week
> away.

Re: [Ksummit-discuss] bug-introducing patches

[Ken Moffat]

On 8 May 2018 at 21:29, Sasha Levin  wrote:

>
> This is interesting. We have a group of power users who are testing out
> -rc releases, who are usually happy to test out a fast moving target and
> provide helpful reports back. We also have a group who run a -stable
> kernel (-stable build/distro/android/etc) who want to avoid having to
> report bugs to us.
>
> What we don't have is a group of people who use Linus's actual releases
> (not the -rc stuff, but the actual point releases). Power users will
> move on to the next kernel, and -stable folks won't touch that release
> until there's a corresponding -stable.

I resent that assumption :)

As a 'prosumer' in this context, I try to test an early -rc (usually
not until -rc2, sometimes not until later, depending on what I see on
this list), and then intermittently I spread the testing to more of my
desktop machines using later -rc versions. Once linus releases .0 I
hope to move my current systems to that in the next few days. But as
always, other things (sometimes real life, sometimes just new changes
in userspace) intervene.

After that, I will pick up Greg's latest if I build a new system
before the next kernel release, or if I become aware of something
critical (for my usage) in it.  And then probably 4 or 5 weeks after
linus's release I will start the next cycle of testing -rc verisons.

So no, I rarely test Greg's current stable version, but there _is_ a
period of some weeks where I run .0 kernels.

ĸen


>
> Even rawhide, like Josh mentioned, will just fill back with the merge
> window commits after the release of an older kernel.
>
> So the problem I'm seeing is that since a merge window is open only once
> every 2-3 months people will sometimes try to push poorly tested code
> just to make that merge window. Additionally, as later -rc releases
> start showing up people will again merge poorly tested fixes just to
> make it in time for that release.
>
> For both cases, people will push poorly tested code in the kernel just
> because they want to make it in time for a kernel release that no one
> will actually use.
>
> What if, instead, Linus doesn't actually ever release a point release?
> We can make the merge window open more often, and since there's no
> actual release, people won't rush to push fixes in later -rc cycles.
>
> We take away the incentive to push poorly tested code. Maintainers still
> free to commit anything they'd like, but there's no reason to commit
> code they're not confident of just to make it to a random release no one
> will use.
>
> Merge window will happen more often, so there's no real reason to rush
> things in a particular window, and since -stable releases every week
> there's no rush to push a fix in since the next release is just a week
> away.

Makefile race in 4.9-rc3 (generated/autoksyms.h: No such file or directory)

[Ken Moffat]

I just tried to build 4.9 (rc3) for the first time (x86_64, i7 haswell)
 After making my choices in make oldconfig, make -j8 failed in
less than 2 sec.

   CC  scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  HOSTCC  scripts/sortextable
  CC  scripts/mod/devicetable-offsets.s
In file included from ./include/linux/linkage.h:6:0,
 from ./include/linux/kernel.h:6,
 from ./include/asm-generic/bug.h:13,
 from ./arch/x86/include/asm/bug.h:35,
 from ./include/linux/bug.h:4,
 from ./include/linux/jump_label.h:170,
 from ./arch/x86/include/asm/string_64.h:5,
 from ./arch/x86/include/asm/string.h:4,
 from ./include/linux/string.h:18,
 from ./include/uapi/linux/uuid.h:21,
 from ./include/linux/uuid.h:19,
 from ./include/linux/mod_devicetable.h:12,
 from scripts/mod/devicetable-offsets.c:2:
./include/linux/export.h:81:33: fatal error: generated/autoksyms.h: No
such file or directory
 #include 
 ^
compilation terminated.
make[2]: *** [scripts/Makefile.build:154:
scripts/mod/devicetable-offsets.s] Error 1
make[1]: *** [scripts/Makefile.build:475: scripts/mod] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:559: scripts] Error 2
make: *** Waiting for unfinished jobs

I then ran make clean and gave it another try, again using -j8.
This time i t worked, so I guess there is a race in a Makefile.

ĸen

Makefile race in 4.9-rc3 (generated/autoksyms.h: No such file or directory)

[Ken Moffat]

I just tried to build 4.9 (rc3) for the first time (x86_64, i7 haswell)
 After making my choices in make oldconfig, make -j8 failed in
less than 2 sec.

   CC  scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  HOSTCC  scripts/sortextable
  CC  scripts/mod/devicetable-offsets.s
In file included from ./include/linux/linkage.h:6:0,
 from ./include/linux/kernel.h:6,
 from ./include/asm-generic/bug.h:13,
 from ./arch/x86/include/asm/bug.h:35,
 from ./include/linux/bug.h:4,
 from ./include/linux/jump_label.h:170,
 from ./arch/x86/include/asm/string_64.h:5,
 from ./arch/x86/include/asm/string.h:4,
 from ./include/linux/string.h:18,
 from ./include/uapi/linux/uuid.h:21,
 from ./include/linux/uuid.h:19,
 from ./include/linux/mod_devicetable.h:12,
 from scripts/mod/devicetable-offsets.c:2:
./include/linux/export.h:81:33: fatal error: generated/autoksyms.h: No
such file or directory
 #include 
 ^
compilation terminated.
make[2]: *** [scripts/Makefile.build:154:
scripts/mod/devicetable-offsets.s] Error 1
make[1]: *** [scripts/Makefile.build:475: scripts/mod] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:559: scripts] Error 2
make: *** Waiting for unfinished jobs

I then ran make clean and gave it another try, again using -j8.
This time i t worked, so I guess there is a race in a Makefile.

ĸen

Re: [PATCH] documentation: ntb.txt correct grammar "however"

[Ken Moffat]

On Sat, Jun 04, 2016 at 03:34:01PM -0400, Justin Keller wrote:
> Correct the grammar around the word however. 
> 
> Signed-off-by: Justin Keller 
> 
> --- 
> 
> index 1d9bbab..5d43510 100644
> --- a/Documentation/ntb.txt
> +++ b/Documentation/ntb.txt
> @@ -35,7 +35,7 @@ establishes a logical link to the peer, and creates queue 
> pairs to exchange
>  messages and data.  The NTB Netdev then creates an ethernet device using a
>  Transport queue pair.  Network data is copied between socket buffers and the
>  Transport queue pair buffer.  The Transport client may be used for other 
> things
> -besides Netdev, however no other applications have yet been written.
> +besides Netdev; however, no other applications have yet been written.
>  
>  ### NTB Ping Pong Test Client (ntb\_pingpong)

As a user of British English, the original looks fine.  Your change,
however, looks odd - a semi-colon seems out of place.  If you
replaced it by a full-stop it would look acceptable to me - but not
in any sense better than what is there at the moment.

ĸen
-- 
I had to walk fifteen miles to school, barefoot in the snow.  Uphill both ways.

Re: [PATCH] documentation: ntb.txt correct grammar "however"

[Ken Moffat]

On Sat, Jun 04, 2016 at 03:34:01PM -0400, Justin Keller wrote:
> Correct the grammar around the word however. 
> 
> Signed-off-by: Justin Keller 
> 
> --- 
> 
> index 1d9bbab..5d43510 100644
> --- a/Documentation/ntb.txt
> +++ b/Documentation/ntb.txt
> @@ -35,7 +35,7 @@ establishes a logical link to the peer, and creates queue 
> pairs to exchange
>  messages and data.  The NTB Netdev then creates an ethernet device using a
>  Transport queue pair.  Network data is copied between socket buffers and the
>  Transport queue pair buffer.  The Transport client may be used for other 
> things
> -besides Netdev, however no other applications have yet been written.
> +besides Netdev; however, no other applications have yet been written.
>  
>  ### NTB Ping Pong Test Client (ntb\_pingpong)

As a user of British English, the original looks fine.  Your change,
however, looks odd - a semi-colon seems out of place.  If you
replaced it by a full-stop it would look acceptable to me - but not
in any sense better than what is there at the moment.

ĸen
-- 
I had to walk fifteen miles to school, barefoot in the snow.  Uphill both ways.

Re: script relative shebang

[Ken Moffat]

On Thu, Jun 02, 2016 at 01:04:46AM +0100, Boris Rybalkin wrote:
> Sorry for insisting, but I would like to explore potential solutions
> for fixing the root problem (missing relative shebang),
> I know there are ways to workaround that, but I would like to make
> sure the proper fix is not possible.
> I understood that it is too late to introduce additional keywords
> after #! as existing systems expect fs path there, OK.
> But what about changing #! itself, is it possible to introduce another
> special sequence like #? to denote a relative mode:
> 
> #?python/bin/python
> 
If you are able to get that accepted, it will only work on linux
systems running such recent kernels.  For your own systems, you can
of course do whatever you wish.  But for public availability you
will then need to wait several years until your target linux users
can be expected to have moved to a suitable kernel (presumably the
*next* long-term stable kernel after the change is accepted : I
guess that version is perhaps the best part of a year away even if
your change got accepted into 4.8, and then you need your users'
distros to move to it).

To me, that doesn't seem worth the trouble (to you) of coding it,
getting it reviewed and eventually accepted, and then fixing up
whatever problems arise after it gets into linux-next [ problems
will always appear, even if the new code turns out not to be the
cause ].

And first, you have to persuade somebody influential that this is a
good thing to do, particularly when people have suggested
alternative approaches.  I don't count, but at the moment I've not
seen any good reasons why the kernel should be changed to support
this.

But it's your time, and your itch to scratch.

ĸen
-- 
I had to walk fifteen miles to school, barefoot in the snow.  Uphill both ways.

Re: script relative shebang

[Ken Moffat]

On Thu, Jun 02, 2016 at 01:04:46AM +0100, Boris Rybalkin wrote:
> Sorry for insisting, but I would like to explore potential solutions
> for fixing the root problem (missing relative shebang),
> I know there are ways to workaround that, but I would like to make
> sure the proper fix is not possible.
> I understood that it is too late to introduce additional keywords
> after #! as existing systems expect fs path there, OK.
> But what about changing #! itself, is it possible to introduce another
> special sequence like #? to denote a relative mode:
> 
> #?python/bin/python
> 
If you are able to get that accepted, it will only work on linux
systems running such recent kernels.  For your own systems, you can
of course do whatever you wish.  But for public availability you
will then need to wait several years until your target linux users
can be expected to have moved to a suitable kernel (presumably the
*next* long-term stable kernel after the change is accepted : I
guess that version is perhaps the best part of a year away even if
your change got accepted into 4.8, and then you need your users'
distros to move to it).

To me, that doesn't seem worth the trouble (to you) of coding it,
getting it reviewed and eventually accepted, and then fixing up
whatever problems arise after it gets into linux-next [ problems
will always appear, even if the new code turns out not to be the
cause ].

And first, you have to persuade somebody influential that this is a
good thing to do, particularly when people have suggested
alternative approaches.  I don't count, but at the moment I've not
seen any good reasons why the kernel should be changed to support
this.

But it's your time, and your itch to scratch.

ĸen
-- 
I had to walk fifteen miles to school, barefoot in the snow.  Uphill both ways.

Re: [drm:radeon_dp_link_train] *ERROR* clock recovery failed -bisected

[Ken Moffat]

On Fri, Mar 04, 2016 at 12:44:01AM +, Deucher, Alexander wrote:
> 
> The attached radeon patch should fix it.  I accidently dropped the special 
> handling for NUTMEG DP to VGA bridge chips.
> 
> > This mobo does not have a DP connector.
> > 
> 
> The VGA port uses a DP to VGA bridge chip.
> 
> Alex
> 

Thanks, I was not expecting such a quick response.

The radeon patch does fix it.  If you wish, you can add

Tested-by: Ken Moffat <zarniwh...@ntlworld.com>

ĸen
-- 
This email was written using 100% recycled letters.

Re: [drm:radeon_dp_link_train] *ERROR* clock recovery failed -bisected

[Ken Moffat]

On Fri, Mar 04, 2016 at 12:44:01AM +, Deucher, Alexander wrote:
> 
> The attached radeon patch should fix it.  I accidently dropped the special 
> handling for NUTMEG DP to VGA bridge chips.
> 
> > This mobo does not have a DP connector.
> > 
> 
> The VGA port uses a DP to VGA bridge chip.
> 
> Alex
> 

Thanks, I was not expecting such a quick response.

The radeon patch does fix it.  If you wish, you can add

Tested-by: Ken Moffat 

ĸen
-- 
This email was written using 100% recycled letters.

[drm:radeon_dp_link_train] *ERROR* clock recovery failed -bisected

[Ken Moffat]

On Thu, Mar 03, 2016 at 02:38:11AM +, Ken Moffat wrote:
> One of my machines is an A10 Kaveri desktop, with a good old VGA
> connection to the monitor.  I've only just started trying to boot
> any 4.5 kernel on it, but with 4.5.0-rc6 and now linus's tree from a
> few hours ago (4.5.0-rc6-00018-gf983cd3) I get a blank screen, with
> no video signal, as soon as it tries to switch to a framebuffer.
> 
> Comparing the logs, the first bad attempt had a couple of new error
> messages, everything else in the logs looked normal -
> 
> Mar  1 19:31:10 deluxe kernel: [2.543163] fbcon: radeondrmfb (fb0) is 
> primary device
> Mar  1 19:31:10 deluxe kernel: [2.654179] [drm:radeon_dp_link_train] 
> *ERROR* clock recovery reached max voltage
> Mar  1 19:31:10 deluxe kernel: [2.654181] [drm:radeon_dp_link_train] 
> *ERROR* clock recovery failed
> Mar  1 19:31:10 deluxe kernel: [2.677142] Console: switching to colour 
> frame buffer device 200x56
> Mar  1 19:31:10 deluxe kernel: [2.680435] radeon :00:01.0: fb0: 
> radeondrmfb frame buffer device
> 
Bisection pointed to

092c96a8ab9d1bd60ada2ed385cc364ce084180e is the first bad commit
commit 092c96a8ab9d1bd60ada2ed385cc364ce084180e
Author: Alex Deucher <alexander.deuc...@amd.com>
Date:   Thu Dec 17 10:23:34 2015 -0500

drm/radeon: fix dp link rate selection (v2)

Need to properly handle the max link rate in the dpcd.
This prevents some cases where 5.4 Ghz is selected when
it shouldn't be.

v2: simplify logic, add array bounds check

Reviewed-by: Tom St Denis <tom.stde...@amd.com>
Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>

I have now reverted that commit from that version of linus's tree and
the machine everything is back to normal.

This mobo does not have a DP connector.

lspci reports the graphics part is

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Kaveri [Radeon R7 Graphics] (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Kaveri [Radeon R7 Graphics]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
 DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0
ExtTag+ RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, 
OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, 
OBFF Disabled
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: fee0f00c  Data: 4172
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 
Len=010 
Capabilities: [270 v1] #19
Capabilities: [2b0 v1] Address Translation Service (ATS)
ATSCap: Invalidate Queue Depth: 00
ATSCtl: Enable-, Smallest Translation Unit: 00
Capabilities: [2c0 v1] Page Request Interface (PRI)
PRICtl: Enable- Reset-
PRISta: RF- UPRGI- Stopped+
Page Request Capacity: 0020, Page Request Allocation: 

Capabilities: [2d0 v1] Process Address Space ID (PASID)
PASIDCap: Exec- Priv-, Max PASID Width: 10
PASIDCtl: Enable- Exec- Priv-
Kernel driver in use: radeon

I've attached my config.  Please let me know if there is anything I
can do to help fix this.

ĸen
-- 
This email was written using 100% recycled letters.
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.5.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGOR

[drm:radeon_dp_link_train] *ERROR* clock recovery failed -bisected

[Ken Moffat]

On Thu, Mar 03, 2016 at 02:38:11AM +, Ken Moffat wrote:
> One of my machines is an A10 Kaveri desktop, with a good old VGA
> connection to the monitor.  I've only just started trying to boot
> any 4.5 kernel on it, but with 4.5.0-rc6 and now linus's tree from a
> few hours ago (4.5.0-rc6-00018-gf983cd3) I get a blank screen, with
> no video signal, as soon as it tries to switch to a framebuffer.
> 
> Comparing the logs, the first bad attempt had a couple of new error
> messages, everything else in the logs looked normal -
> 
> Mar  1 19:31:10 deluxe kernel: [2.543163] fbcon: radeondrmfb (fb0) is 
> primary device
> Mar  1 19:31:10 deluxe kernel: [2.654179] [drm:radeon_dp_link_train] 
> *ERROR* clock recovery reached max voltage
> Mar  1 19:31:10 deluxe kernel: [2.654181] [drm:radeon_dp_link_train] 
> *ERROR* clock recovery failed
> Mar  1 19:31:10 deluxe kernel: [2.677142] Console: switching to colour 
> frame buffer device 200x56
> Mar  1 19:31:10 deluxe kernel: [2.680435] radeon :00:01.0: fb0: 
> radeondrmfb frame buffer device
> 
Bisection pointed to

092c96a8ab9d1bd60ada2ed385cc364ce084180e is the first bad commit
commit 092c96a8ab9d1bd60ada2ed385cc364ce084180e
Author: Alex Deucher 
Date:   Thu Dec 17 10:23:34 2015 -0500

drm/radeon: fix dp link rate selection (v2)

Need to properly handle the max link rate in the dpcd.
This prevents some cases where 5.4 Ghz is selected when
it shouldn't be.

v2: simplify logic, add array bounds check

Reviewed-by: Tom St Denis 
Signed-off-by: Alex Deucher 

I have now reverted that commit from that version of linus's tree and
the machine everything is back to normal.

This mobo does not have a DP connector.

lspci reports the graphics part is

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Kaveri [Radeon R7 Graphics] (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Kaveri [Radeon R7 Graphics]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
 DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0
ExtTag+ RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, 
OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, 
OBFF Disabled
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: fee0f00c  Data: 4172
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 
Len=010 
Capabilities: [270 v1] #19
Capabilities: [2b0 v1] Address Translation Service (ATS)
ATSCap: Invalidate Queue Depth: 00
ATSCtl: Enable-, Smallest Translation Unit: 00
Capabilities: [2c0 v1] Page Request Interface (PRI)
PRICtl: Enable- Reset-
PRISta: RF- UPRGI- Stopped+
Page Request Capacity: 0020, Page Request Allocation: 

Capabilities: [2d0 v1] Process Address Space ID (PASID)
PASIDCap: Exec- Priv-, Max PASID Width: 10
PASIDCtl: Enable- Exec- Priv-
Kernel driver in use: radeon

I've attached my config.  Please let me know if there is anything I
can do to help fix this.

ĸen
-- 
This email was written using 100% recycled letters.
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.5.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_L

[drm:radeon_dp_link_train] *ERROR* clock recovery failed

[Ken Moffat]

One of my machines is an A10 Kaveri desktop, with a good old VGA
connection to the monitor.  I've only just started trying to boot
any 4.5 kernel on it, but with 4.5.0-rc6 and now linus's tree from a
few hours ago (4.5.0-rc6-00018-gf983cd3) I get a blank screen, with
no video signal, as soon as it tries to switch to a framebuffer.

Comparing the logs, the first bad attempt had a couple of new error
messages, everything else in the logs looked normal -

Mar  1 19:31:10 deluxe kernel: [2.543163] fbcon: radeondrmfb (fb0) is 
primary device
Mar  1 19:31:10 deluxe kernel: [2.654179] [drm:radeon_dp_link_train] 
*ERROR* clock recovery reached max voltage
Mar  1 19:31:10 deluxe kernel: [2.654181] [drm:radeon_dp_link_train] 
*ERROR* clock recovery failed
Mar  1 19:31:10 deluxe kernel: [2.677142] Console: switching to colour 
frame buffer device 200x56
Mar  1 19:31:10 deluxe kernel: [2.680435] radeon :00:01.0: fb0: 
radeondrmfb frame buffer device

Any suggestions where to start looking, please ?

ĸen
-- 
This email was written using 100% recycled letters.

[drm:radeon_dp_link_train] *ERROR* clock recovery failed

[Ken Moffat]

One of my machines is an A10 Kaveri desktop, with a good old VGA
connection to the monitor.  I've only just started trying to boot
any 4.5 kernel on it, but with 4.5.0-rc6 and now linus's tree from a
few hours ago (4.5.0-rc6-00018-gf983cd3) I get a blank screen, with
no video signal, as soon as it tries to switch to a framebuffer.

Comparing the logs, the first bad attempt had a couple of new error
messages, everything else in the logs looked normal -

Mar  1 19:31:10 deluxe kernel: [2.543163] fbcon: radeondrmfb (fb0) is 
primary device
Mar  1 19:31:10 deluxe kernel: [2.654179] [drm:radeon_dp_link_train] 
*ERROR* clock recovery reached max voltage
Mar  1 19:31:10 deluxe kernel: [2.654181] [drm:radeon_dp_link_train] 
*ERROR* clock recovery failed
Mar  1 19:31:10 deluxe kernel: [2.677142] Console: switching to colour 
frame buffer device 200x56
Mar  1 19:31:10 deluxe kernel: [2.680435] radeon :00:01.0: fb0: 
radeondrmfb frame buffer device

Any suggestions where to start looking, please ?

ĸen
-- 
This email was written using 100% recycled letters.

Re: fs/udf and udftools

[Ken Moffat]

On Wed, Feb 10, 2016 at 05:56:16PM -0800, Randy Dunlap wrote:
> [add Jan Kara]
> 
> On 02/10/16 13:29, Steve Kenton wrote:
> > Is anyone maintaining these or am I about to volunteer for another job?
> 
> CUrrent MAINTAINERS file says:
> 
> UDF FILESYSTEM
> M:Jan Kara 
> S:Maintained
> F:Documentation/filesystems/udf.txt
> F:fs/udf/
> 
> and that Doc. file says:
> 
> For the latest version and toolset see:
>   http://linux-udf.sourceforge.net/
> 
A bit of googling for udftools suggests that gentoo are maintaining
their build, debian have patches for gcc-4 and gcc-5 among others,
Fedora have their own patches, and Arch have some patches (which
might be the same as some of hte others, I did not look).

Looks like the normal "possibly abandonned, but still useful to some
people" software, where distros keep it building.

There may also be others.

Links -

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udftools/ChangeLog?view=markup

https://launchpad.net/debian/+source/udftools/+changelog

http://pkgs.fedoraproject.org/cgit/rpms/udftools.git/tree/

https://aur.archlinux.org/packages/udftools/

> 
> > I'm having to dig into fs/udf and udftools/mkudffs as part of a project I'm 
> > working on.
> > It looks like both have been lacking in personal TLC for quite a while. The 
> > changes to
> > fs/udf seem to be tree wide VFS work but not updates to things like write 
> > support and
> > udftools seems to have been frozen for >10  years. Both ~work but I'd like 
> > to fix an
> > oops I'm getting in udftools and work on adding fallocate() support to 
> > fs/udf and then
> > feed it back to the community rather than let the changes bit rot locally.
> > 
> > Where to go from here? I've been reading LKML on marc: for years, mainly to 
> > see what Linus,
> > Al and a variable group of other people say/do but I've never done more 
> > than tinker with
> > the kernel locally. I'm using git for the project mentioned above but again 
> > am not an
> > expert but willing to learn. I'm not currently subscribed so please cc me 
> > if you could.
> > 
> > smk
> > 
> 
> 
> -- 
> ~Randy

-- 
This email was written using 100% recycled letters.

Re: fs/udf and udftools

[Ken Moffat]

On Wed, Feb 10, 2016 at 05:56:16PM -0800, Randy Dunlap wrote:
> [add Jan Kara]
> 
> On 02/10/16 13:29, Steve Kenton wrote:
> > Is anyone maintaining these or am I about to volunteer for another job?
> 
> CUrrent MAINTAINERS file says:
> 
> UDF FILESYSTEM
> M:Jan Kara 
> S:Maintained
> F:Documentation/filesystems/udf.txt
> F:fs/udf/
> 
> and that Doc. file says:
> 
> For the latest version and toolset see:
>   http://linux-udf.sourceforge.net/
> 
A bit of googling for udftools suggests that gentoo are maintaining
their build, debian have patches for gcc-4 and gcc-5 among others,
Fedora have their own patches, and Arch have some patches (which
might be the same as some of hte others, I did not look).

Looks like the normal "possibly abandonned, but still useful to some
people" software, where distros keep it building.

There may also be others.

Links -

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udftools/ChangeLog?view=markup

https://launchpad.net/debian/+source/udftools/+changelog

http://pkgs.fedoraproject.org/cgit/rpms/udftools.git/tree/

https://aur.archlinux.org/packages/udftools/

> 
> > I'm having to dig into fs/udf and udftools/mkudffs as part of a project I'm 
> > working on.
> > It looks like both have been lacking in personal TLC for quite a while. The 
> > changes to
> > fs/udf seem to be tree wide VFS work but not updates to things like write 
> > support and
> > udftools seems to have been frozen for >10  years. Both ~work but I'd like 
> > to fix an
> > oops I'm getting in udftools and work on adding fallocate() support to 
> > fs/udf and then
> > feed it back to the community rather than let the changes bit rot locally.
> > 
> > Where to go from here? I've been reading LKML on marc: for years, mainly to 
> > see what Linus,
> > Al and a variable group of other people say/do but I've never done more 
> > than tinker with
> > the kernel locally. I'm using git for the project mentioned above but again 
> > am not an
> > expert but willing to learn. I'm not currently subscribed so please cc me 
> > if you could.
> > 
> > smk
> > 
> 
> 
> -- 
> ~Randy

-- 
This email was written using 100% recycled letters.

Re: Freezing system after kernel 3.2

[Ken Moffat]

On Mon, Feb 08, 2016 at 07:08:09PM +0100, Karsten Malcher wrote:
> Hello,
> 
> i am sorry, but is it possible that a kernel bug for a special chipset is 
> alive since kernel 3.2?
> 
On uncommon hardware, anything is possible.  I don't actually know
if that hardware is "uncommon", only that I do not have it.

> I have a backup PC with an Asrock ALiveXFire eSATA2 R3.0 mainboard with CPU 
> AMD64 X2 6000+.
> Before this mainboard runs very stable with Debian wheezy and kernel 3.2.0.
> Now i tried to update to Jessie with kernel 3.16 and the board is crashing 
> within 1-5 minutes after boot!
> 
> There is no clear error, mostly the system is just suddenly freezing without 
> any message or log.
> Sometimes i get a kernel panic like "fatal exception in interrupt", but the 
> boot parameter "pc=nomsi" has no effect.
> 
> I can rule out hardware problems, because the memtest can run for many hours 
> finding nothing.

LOL.  I have a phenom x4 : from time to time (fairly frequently) it
loses its lunch during compiles if I use make -j4.  On less-frequent
occasions it does the same even with make -j1.  And always
memtest86+-5.01 is happy [ well, if I use the "run all CPUs [F2]
option it locks up, but it does that on at least two other mobos
too: one of those is an intel SandyBridge so that issue is not
AMD-specific ].

> Additionally i can boot Knoppix 6.7 with kernel 3.0.4 and it is running 
> stable.
> But when i boot Knoppix 7.2 with kernel 3.9.6 the system is freezing!
> Aditionally i tried out kernel 4.3.0 in Debian but it does not help. Any 
> newer kernel freezes.
> 
> I am sure that newer kernel have a problem with this special mainboard 
> hardware.
> 

If nobody else has better suggestions, I think you will have to
build upstream kernels to find when it broke.  I suggest that you
begin with standard 3.2.latest (just in case you turned out to rely
on something in the debian kernel but not upstream).  Then try
3.9.latest : if that runs ok, continue with 3.16.latest.  If not,
try e.g. 3.4.latest.  The aim is to first find which minor release
broke, and then which update in that series broke it.  What you
*might* need to do is also try .0 versions of each of these.

I am suggesting that you bisect this.  Bisection is usually a pain,
so I suggest that you first find a working version, and then work
through the next stable release of that version to find which commit
broke it.  I suspect I might have phrased my suggestions badly, but
even 3.9 is so long ago that most of us have forgotten about it [ my
last box running a 3.10 LTS kernel was a ppc64, and I have not
booted that for about 2 years ].

Good Luck, and I hope you get a better suggestion.

ĸen
-- 
This email was written using 100% recycled letters.

Re: Freezing system after kernel 3.2

[Ken Moffat]

On Mon, Feb 08, 2016 at 07:08:09PM +0100, Karsten Malcher wrote:
> Hello,
> 
> i am sorry, but is it possible that a kernel bug for a special chipset is 
> alive since kernel 3.2?
> 
On uncommon hardware, anything is possible.  I don't actually know
if that hardware is "uncommon", only that I do not have it.

> I have a backup PC with an Asrock ALiveXFire eSATA2 R3.0 mainboard with CPU 
> AMD64 X2 6000+.
> Before this mainboard runs very stable with Debian wheezy and kernel 3.2.0.
> Now i tried to update to Jessie with kernel 3.16 and the board is crashing 
> within 1-5 minutes after boot!
> 
> There is no clear error, mostly the system is just suddenly freezing without 
> any message or log.
> Sometimes i get a kernel panic like "fatal exception in interrupt", but the 
> boot parameter "pc=nomsi" has no effect.
> 
> I can rule out hardware problems, because the memtest can run for many hours 
> finding nothing.

LOL.  I have a phenom x4 : from time to time (fairly frequently) it
loses its lunch during compiles if I use make -j4.  On less-frequent
occasions it does the same even with make -j1.  And always
memtest86+-5.01 is happy [ well, if I use the "run all CPUs [F2]
option it locks up, but it does that on at least two other mobos
too: one of those is an intel SandyBridge so that issue is not
AMD-specific ].

> Additionally i can boot Knoppix 6.7 with kernel 3.0.4 and it is running 
> stable.
> But when i boot Knoppix 7.2 with kernel 3.9.6 the system is freezing!
> Aditionally i tried out kernel 4.3.0 in Debian but it does not help. Any 
> newer kernel freezes.
> 
> I am sure that newer kernel have a problem with this special mainboard 
> hardware.
> 

If nobody else has better suggestions, I think you will have to
build upstream kernels to find when it broke.  I suggest that you
begin with standard 3.2.latest (just in case you turned out to rely
on something in the debian kernel but not upstream).  Then try
3.9.latest : if that runs ok, continue with 3.16.latest.  If not,
try e.g. 3.4.latest.  The aim is to first find which minor release
broke, and then which update in that series broke it.  What you
*might* need to do is also try .0 versions of each of these.

I am suggesting that you bisect this.  Bisection is usually a pain,
so I suggest that you first find a working version, and then work
through the next stable release of that version to find which commit
broke it.  I suspect I might have phrased my suggestions badly, but
even 3.9 is so long ago that most of us have forgotten about it [ my
last box running a 3.10 LTS kernel was a ppc64, and I have not
booted that for about 2 years ].

Good Luck, and I hope you get a better suggestion.

ĸen
-- 
This email was written using 100% recycled letters.

Re: [PATCH 0/9] Fix checkpatch errors

[Ken Moffat]

On Sun, Dec 13, 2015 at 07:26:04PM +0100, Frederik wrote:
> On Sun, 13. Dec 19:15, Nicolai Stange wrote:
> > Frederik  writes:
> > 
> > W/o your series applied (so line numbering might be slightly
> > different), checkpatch.pl says:
> > 
> >   ERROR: trailing whitespace
> >   #270: FILE: -:270:
> >   +^I * This do { } while() loop will get ALL chars out of Rx FIFO $
> > 
> > AFAICS, your patch [7/9] ("drivers: tty: 68328serial.c: remove trailing
> > whitespaces") doesn't fix this one.
> > 
> > In good old regexp tradition, the '$' sign denotes the end of line. So,
> > there is a single space after "FIFO" and before the end of line.
> > 
> > If you happen to be Emacs users, consider trying out whitespace-mode.
> > If not, try to find another way to make your editor visualize whitespace
> > somehow.
> 
> Oh right I see. We will fix that and resend.
> 
> Thank you!
If you are using vim, I have the following in my .vimrc.  It was
originally posted here many years ago.  Seems to work on all my x86
boxes, but AFAIR it didn't work on a ppc, so might not work on other
architectures.

"for redundant whitespace, from Jeremy Kerr via Olof Johanson
highlight RedundantWhitespace ctermbg=red guibg=red
match RedundantWhitespace /\s\+$\| \+\ze\t/

HTH

ĸen
-- 
This email was written using 100% recycled letters.
--
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 0/9] Fix checkpatch errors

[Ken Moffat]

On Sun, Dec 13, 2015 at 07:26:04PM +0100, Frederik wrote:
> On Sun, 13. Dec 19:15, Nicolai Stange wrote:
> > Frederik  writes:
> > 
> > W/o your series applied (so line numbering might be slightly
> > different), checkpatch.pl says:
> > 
> >   ERROR: trailing whitespace
> >   #270: FILE: -:270:
> >   +^I * This do { } while() loop will get ALL chars out of Rx FIFO $
> > 
> > AFAICS, your patch [7/9] ("drivers: tty: 68328serial.c: remove trailing
> > whitespaces") doesn't fix this one.
> > 
> > In good old regexp tradition, the '$' sign denotes the end of line. So,
> > there is a single space after "FIFO" and before the end of line.
> > 
> > If you happen to be Emacs users, consider trying out whitespace-mode.
> > If not, try to find another way to make your editor visualize whitespace
> > somehow.
> 
> Oh right I see. We will fix that and resend.
> 
> Thank you!
If you are using vim, I have the following in my .vimrc.  It was
originally posted here many years ago.  Seems to work on all my x86
boxes, but AFAIR it didn't work on a ppc, so might not work on other
architectures.

"for redundant whitespace, from Jeremy Kerr via Olof Johanson
highlight RedundantWhitespace ctermbg=red guibg=red
match RedundantWhitespace /\s\+$\| \+\ze\t/

HTH

ĸen
-- 
This email was written using 100% recycled letters.
--
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: Linux 4.4-rc1

[Ken Moffat]

On Sun, Nov 15, 2015 at 05:24:37PM -0800, Linus Torvalds wrote:
> So it's Sunday, two weeks has passed, and so 4.4-rc1 is out there and
> the merge window is closed.
> 
[...]
> 
> Go out and test.
> 
> Linus
> 
After what I picked up during the 4.3 cycle, I tried using 'xzcat |
git apply -' but I got the following (after messages about spaces
before tabs) :

error: cannot apply binary patch to
'drivers/staging/ft1000/ft1000-pcmcia/ft1000.img' without full index
line
error: drivers/staging/ft1000/ft1000-pcmcia/ft1000.img: patch does
not apply
error: cannot apply binary patch to
'drivers/staging/ft1000/ft1000-usb/ft3000.img' without full index
line
error: drivers/staging/ft1000/ft1000-usb/ft3000.img: patch does not
apply

That is with git-2.6.3.

Interestingly, using 'xzcat | patch -p1' seems to apply fine, or at
least it doesn't seem to report any errors, and I have no particular
interest in ft1000 so I'll go with that.

It boots ok on this machine (AMD K10, with my current config), but
that doesn't say a lot, so I'll shut up.

ĸen
-- 
This email was written using 100% recycled letters.
--
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: Linux 4.4-rc1

[Ken Moffat]

On Sun, Nov 15, 2015 at 05:24:37PM -0800, Linus Torvalds wrote:
> So it's Sunday, two weeks has passed, and so 4.4-rc1 is out there and
> the merge window is closed.
> 
[...]
> 
> Go out and test.
> 
> Linus
> 
After what I picked up during the 4.3 cycle, I tried using 'xzcat |
git apply -' but I got the following (after messages about spaces
before tabs) :

error: cannot apply binary patch to
'drivers/staging/ft1000/ft1000-pcmcia/ft1000.img' without full index
line
error: drivers/staging/ft1000/ft1000-pcmcia/ft1000.img: patch does
not apply
error: cannot apply binary patch to
'drivers/staging/ft1000/ft1000-usb/ft3000.img' without full index
line
error: drivers/staging/ft1000/ft1000-usb/ft3000.img: patch does not
apply

That is with git-2.6.3.

Interestingly, using 'xzcat | patch -p1' seems to apply fine, or at
least it doesn't seem to report any errors, and I have no particular
interest in ft1000 so I'll go with that.

It boots ok on this machine (AMD K10, with my current config), but
that doesn't say a lot, so I'll shut up.

ĸen
-- 
This email was written using 100% recycled letters.
--
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: Please remove commit 6609b638353c99c5736e05abd17197f1cb776e0e as it makes me feel miserable

[Ken Moffat]

On Sun, Sep 13, 2015 at 08:06:02PM -0300, Diego Viola wrote:
> Hello,
> 
> Can someone please remove this commit from the repo:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/README?id=6609b638353c99c5736e05abd17197f1cb776e0e
> 
> I made a huge grammar mistake in my commit message that I can't
> forget, it makes me feel terrible and I can't stop thinking about it.
> 
> Please rewrite the history for the README or whatever, but just make
> this commit go away.
> 
> It should have been spelled as:
> 
> "README: GTK+ is an acronym"
> 
> or
> 
> "README: GTK+ is an initialism"
> 
> But saying "a acronym" is just wrong.
> 
> Thanks and sorry about this mistake, English isn't my native language. :-(
> 
> Diego

If it is any consolation, almost everybody makes mistakes in commit
messages.  I certainly do, but fortunately many of mine will never
be public.  As a native English speaker, 'a acronym' is perfectly
understandable (but 'an initialism' is slightly odd).  But once it
is committed and made public, it is done.

The content of your change is correct.  Thanks for fixing it.  In
future, perhaps do what I try to do - for commit messages themselves,
review before the next commit, and if necessary git commit --amend.
For email subjects, try to review before sending (I fail on both of
these).

What's done is done, and the kernel *is* better for your
contribution.  It is said that in the early days of the kernel there
was a war between those who could spell and those who could not.
Please, don't worry about grammar - as long as the text can be
understood, there is no problem.

ĸen
-- 
Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
  aka "The hedgehog song"

--
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: Please remove commit 6609b638353c99c5736e05abd17197f1cb776e0e as it makes me feel miserable

[Ken Moffat]

On Sun, Sep 13, 2015 at 08:06:02PM -0300, Diego Viola wrote:
> Hello,
> 
> Can someone please remove this commit from the repo:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/README?id=6609b638353c99c5736e05abd17197f1cb776e0e
> 
> I made a huge grammar mistake in my commit message that I can't
> forget, it makes me feel terrible and I can't stop thinking about it.
> 
> Please rewrite the history for the README or whatever, but just make
> this commit go away.
> 
> It should have been spelled as:
> 
> "README: GTK+ is an acronym"
> 
> or
> 
> "README: GTK+ is an initialism"
> 
> But saying "a acronym" is just wrong.
> 
> Thanks and sorry about this mistake, English isn't my native language. :-(
> 
> Diego

If it is any consolation, almost everybody makes mistakes in commit
messages.  I certainly do, but fortunately many of mine will never
be public.  As a native English speaker, 'a acronym' is perfectly
understandable (but 'an initialism' is slightly odd).  But once it
is committed and made public, it is done.

The content of your change is correct.  Thanks for fixing it.  In
future, perhaps do what I try to do - for commit messages themselves,
review before the next commit, and if necessary git commit --amend.
For email subjects, try to review before sending (I fail on both of
these).

What's done is done, and the kernel *is* better for your
contribution.  It is said that in the early days of the kernel there
was a war between those who could spell and those who could not.
Please, don't worry about grammar - as long as the text can be
understood, there is no problem.

ĸen
-- 
Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
  aka "The hedgehog song"

--
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: Lockups with 4.2-rc kernels and qemu

[Ken Moffat]

On Thu, Aug 27, 2015 at 05:52:58PM +0100, Ken Moffat wrote:
> On Thu, Aug 27, 2015 at 12:59:14PM +0100, Ken Moffat wrote:
> > On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote:
> > > (Cc'ing qemu-devel, please keep me in the Cc).
> > > 
> > > TL;DR - qemu locks up my machine when I use 4.2-rc kernels.
> > > 
> > Previous mail, or at least the copy to qemu, archived at
> > https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html
> > 
> > I started bisecting, but it is going to be a slow business - kernels
> > which seem to be ok after e.g. 3 hours can still lock the box.  I
> > left it running overnight, and this morning it was still up - but
> > firefox could no longer connect externally.  I eventually tracked
> > that to my logs taking the space.  But one reason the logs had
> > become so big was the following (found from this morning's restart):
> > 
> > Aug 27 09:50:28 ac4tv kernel: [  124.279813] BUG: scheduling while
> > atomic: qemu-system-x86/1789/0x0002
> > Aug 27 09:50:28 ac4tv kernel: [  124.279819] Modules linked in:
> > psmouse i2c_piix4 asus_atk0110 microcode k10temp
> > Aug 27 09:50:28 ac4tv kernel: [  124.279828] Preemption disabled
> > at:[] kvm_vcpu_ioctl+0x7c/0x580
> 
> This is definitely a *different* bug - I just tried the next kernel,
> and started to get these messages (almost 100,000 lines of them in
> the next 4 minutes) : if that had been happening a couple of weeks
> ago, I would have noticed ;-)
> 
> But, the end result is that I cannot attempt to bisect the lockups,
> this scheduling while atomic business is preventing me looking for a
> good kernel.
> 
> Has anybody had success qith qemu on an x86_64 host running a 4.2-rc
> kernel ?  Looks as if I'll have to give up, and hope that the main
> problem doe not spread to 4.1.
> 
What will (hopefully) be my last comment on this - I went back to
4.1.3 on the host, and after a couple of hours it locked up.  Maybe
in the past I have jsut been lucky.  I think in future I'll probably
stick to native builds., it seems to be less painful.

ĸen
-- 
Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
  aka "The hedgehog song"
--
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: Lockups with 4.2-rc kernels and qemu

[Ken Moffat]

On Thu, Aug 27, 2015 at 12:59:14PM +0100, Ken Moffat wrote:
> On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote:
> > (Cc'ing qemu-devel, please keep me in the Cc).
> > 
> > TL;DR - qemu locks up my machine when I use 4.2-rc kernels.
> > 
> Previous mail, or at least the copy to qemu, archived at
> https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html
> 
> I started bisecting, but it is going to be a slow business - kernels
> which seem to be ok after e.g. 3 hours can still lock the box.  I
> left it running overnight, and this morning it was still up - but
> firefox could no longer connect externally.  I eventually tracked
> that to my logs taking the space.  But one reason the logs had
> become so big was the following (found from this morning's restart):
> 
> Aug 27 09:50:28 ac4tv kernel: [  124.279813] BUG: scheduling while
> atomic: qemu-system-x86/1789/0x0002
> Aug 27 09:50:28 ac4tv kernel: [  124.279819] Modules linked in:
> psmouse i2c_piix4 asus_atk0110 microcode k10temp
> Aug 27 09:50:28 ac4tv kernel: [  124.279828] Preemption disabled
> at:[] kvm_vcpu_ioctl+0x7c/0x580

This is definitely a *different* bug - I just tried the next kernel,
and started to get these messages (almost 100,000 lines of them in
the next 4 minutes) : if that had been happening a couple of weeks
ago, I would have noticed ;-)

But, the end result is that I cannot attempt to bisect the lockups,
this scheduling while atomic business is preventing me looking for a
good kernel.

Has anybody had success qith qemu on an x86_64 host running a 4.2-rc
kernel ?  Looks as if I'll have to give up, and hope that the main
problem doe not spread to 4.1.

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.
--
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: Lockups with 4.2-rc kernels and qemu

[Ken Moffat]

On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote:
> (Cc'ing qemu-devel, please keep me in the Cc).
> 
> TL;DR - qemu locks up my machine when I use 4.2-rc kernels.
> 
Previous mail, or at least the copy to qemu, archived at
https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html

I started bisecting, but it is going to be a slow business - kernels
which seem to be ok after e.g. 3 hours can still lock the box.  I
left it running overnight, and this morning it was still up - but
firefox could no longer connect externally.  I eventually tracked
that to my logs taking the space.  But one reason the logs had
become so big was the following (found from this morning's restart):

Aug 27 09:50:28 ac4tv kernel: [  124.279813] BUG: scheduling while
atomic: qemu-system-x86/1789/0x0002
Aug 27 09:50:28 ac4tv kernel: [  124.279819] Modules linked in:
psmouse i2c_piix4 asus_atk0110 microcode k10temp
Aug 27 09:50:28 ac4tv kernel: [  124.279828] Preemption disabled
at:[] kvm_vcpu_ioctl+0x7c/0x580
Aug 27 09:50:28 ac4tv kernel: [  124.279839] 
Aug 27 09:50:28 ac4tv kernel: [  124.279842] CPU: 2 PID: 1789 Comm:
qemu-system-x86 Not tainted 4.1.0-10762-g8c7febe #4
Aug 27 09:50:28 ac4tv kernel: [  124.279843] Hardware name: System
manufacturer System Product Name/M5A78L-M LX V2, BIOS 0601
11/30/2011
Aug 27 09:50:28 ac4tv kernel: [  124.279845]  88021fd14880
88020718fc38 8178316e 8002
Aug 27 09:50:28 ac4tv kernel: [  124.279847]  00014880
88020718fc48 810b93d7 88020718fca8
Aug 27 09:50:28 ac4tv kernel: [  124.279849]  8178607c
88021fc14880 880215ebc100 88020718fc78
Aug 27 09:50:28 ac4tv kernel: [  124.279851] Call Trace:
Aug 27 09:50:28 ac4tv kernel: [  124.279855]  []
dump_stack+0x4f/0x7b
Aug 27 09:50:28 ac4tv kernel: [  124.279859]  []
__schedule_bug+0x57/0xa0
Aug 27 09:50:28 ac4tv kernel: [  124.279861]  []
__schedule+0x67c/0x9d0
Aug 27 09:50:28 ac4tv kernel: [  124.279864]  [] ?
_raw_write_unlock_irqrestore+0x18/0x40
Aug 27 09:50:28 ac4tv kernel: [  124.279865]  []
schedule+0x41/0x90
Aug 27 09:50:28 ac4tv kernel: [  124.279867]  []
schedule_preempt_disabled+0x18/0x30
Aug 27 09:50:28 ac4tv kernel: [  124.279869]  []
__mutex_lock_slowpath+0x10d/0x340
Aug 27 09:50:28 ac4tv kernel: [  124.279871]  []
mutex_lock+0x16/0x30
Aug 27 09:50:28 ac4tv kernel: [  124.279874]  []
static_key_slow_inc+0x42/0xc0
Aug 27 09:50:28 ac4tv kernel: [  124.279875]  []
preempt_notifier_register+0x1d/0x60
Aug 27 09:50:28 ac4tv kernel: [  124.279881]  []
vcpu_load+0x4d/0x90
Aug 27 09:50:28 ac4tv kernel: [  124.279887]  []
kvm_vcpu_ioctl+0x7c/0x580
Aug 27 09:50:28 ac4tv kernel: [  124.279892]  [] ?
_raw_write_unlock_irq+0x17/0x40
Aug 27 09:50:28 ac4tv kernel: [  124.279898]  []
do_vfs_ioctl+0x295/0x480
Aug 27 09:50:28 ac4tv kernel: [  124.279905]  [] ?
__fget+0x79/0xb0
Aug 27 09:50:28 ac4tv kernel: [  124.279910]  []
SyS_ioctl+0x4c/0x90
Aug 27 09:50:28 ac4tv kernel: [  124.279914]  [] ?
context_tracking_user_enter+0x13/0x20
Aug 27 09:50:28 ac4tv kernel: [  124.279917]  [] ?
syscall_trace_leave+0xa5/0x140
Aug 27 09:50:28 ac4tv kernel: [  124.279919]  []
entry_SYSCALL_64_fastpath+0x12/0x6a
Aug 27 09:50:28 ac4tv kernel: [  124.477786] kvm: zapping shadow
pages for mmio generation wraparound
Aug 27 09:50:31 ac4tv kernel: [  127.177303] BUG: scheduling while
atomic: qemu-system-x86/1788/0x0002
Aug 27 09:50:31 ac4tv kernel: [  127.177309] Modules linked in:
Aug 27 09:50:31 ac4tv kernel: [  127.177317] BUG: scheduling while
atomic: qemu-system-x86/1790/0x0002
Aug 27 09:50:31 ac4tv kernel: [  127.177318]  psmouse i2c_piix4
asus_atk0110 microcode k10temp
Aug 27 09:50:31 ac4tv kernel: [  127.177332] Preemption disabled at:
Aug 27 09:50:31 ac4tv kernel: [  127.177334] Modules linked in:
psmouse i2c_piix4 asus_atk0110 microcode k10temp
Aug 27 09:50:31 ac4tv kernel: [  127.177341] Preemption disabled
at:[] kvm_vcpu_ioctl+0x7c/0x580
 etc, etc.

I have not _noticed_ these messages on -rc8, but for the moment I am
inclined to treat them as another sign of the same problem.  Which
means a fresh bisection.  

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.
--
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: Lockups with 4.2-rc kernels and qemu

[Ken Moffat]

On Thu, Aug 27, 2015 at 12:59:14PM +0100, Ken Moffat wrote:
 On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote:
  (Cc'ing qemu-devel, please keep me in the Cc).
  
  TL;DR - qemu locks up my machine when I use 4.2-rc kernels.
  
 Previous mail, or at least the copy to qemu, archived at
 https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html
 
 I started bisecting, but it is going to be a slow business - kernels
 which seem to be ok after e.g. 3 hours can still lock the box.  I
 left it running overnight, and this morning it was still up - but
 firefox could no longer connect externally.  I eventually tracked
 that to my logs taking the space.  But one reason the logs had
 become so big was the following (found from this morning's restart):
 
 Aug 27 09:50:28 ac4tv kernel: [  124.279813] BUG: scheduling while
 atomic: qemu-system-x86/1789/0x0002
 Aug 27 09:50:28 ac4tv kernel: [  124.279819] Modules linked in:
 psmouse i2c_piix4 asus_atk0110 microcode k10temp
 Aug 27 09:50:28 ac4tv kernel: [  124.279828] Preemption disabled
 at:[8100787c] kvm_vcpu_ioctl+0x7c/0x580

This is definitely a *different* bug - I just tried the next kernel,
and started to get these messages (almost 100,000 lines of them in
the next 4 minutes) : if that had been happening a couple of weeks
ago, I would have noticed ;-)

But, the end result is that I cannot attempt to bisect the lockups,
this scheduling while atomic business is preventing me looking for a
good kernel.

Has anybody had success qith qemu on an x86_64 host running a 4.2-rc
kernel ?  Looks as if I'll have to give up, and hope that the main
problem doe not spread to 4.1.

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.
--
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: Lockups with 4.2-rc kernels and qemu

[Ken Moffat]

On Thu, Aug 27, 2015 at 05:52:58PM +0100, Ken Moffat wrote:
 On Thu, Aug 27, 2015 at 12:59:14PM +0100, Ken Moffat wrote:
  On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote:
   (Cc'ing qemu-devel, please keep me in the Cc).
   
   TL;DR - qemu locks up my machine when I use 4.2-rc kernels.
   
  Previous mail, or at least the copy to qemu, archived at
  https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html
  
  I started bisecting, but it is going to be a slow business - kernels
  which seem to be ok after e.g. 3 hours can still lock the box.  I
  left it running overnight, and this morning it was still up - but
  firefox could no longer connect externally.  I eventually tracked
  that to my logs taking the space.  But one reason the logs had
  become so big was the following (found from this morning's restart):
  
  Aug 27 09:50:28 ac4tv kernel: [  124.279813] BUG: scheduling while
  atomic: qemu-system-x86/1789/0x0002
  Aug 27 09:50:28 ac4tv kernel: [  124.279819] Modules linked in:
  psmouse i2c_piix4 asus_atk0110 microcode k10temp
  Aug 27 09:50:28 ac4tv kernel: [  124.279828] Preemption disabled
  at:[8100787c] kvm_vcpu_ioctl+0x7c/0x580
 
 This is definitely a *different* bug - I just tried the next kernel,
 and started to get these messages (almost 100,000 lines of them in
 the next 4 minutes) : if that had been happening a couple of weeks
 ago, I would have noticed ;-)
 
 But, the end result is that I cannot attempt to bisect the lockups,
 this scheduling while atomic business is preventing me looking for a
 good kernel.
 
 Has anybody had success qith qemu on an x86_64 host running a 4.2-rc
 kernel ?  Looks as if I'll have to give up, and hope that the main
 problem doe not spread to 4.1.
 
What will (hopefully) be my last comment on this - I went back to
4.1.3 on the host, and after a couple of hours it locked up.  Maybe
in the past I have jsut been lucky.  I think in future I'll probably
stick to native builds., it seems to be less painful.

ĸen
-- 
Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
  aka The hedgehog song
--
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: Lockups with 4.2-rc kernels and qemu

[Ken Moffat]

On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote:
 (Cc'ing qemu-devel, please keep me in the Cc).
 
 TL;DR - qemu locks up my machine when I use 4.2-rc kernels.
 
Previous mail, or at least the copy to qemu, archived at
https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html

I started bisecting, but it is going to be a slow business - kernels
which seem to be ok after e.g. 3 hours can still lock the box.  I
left it running overnight, and this morning it was still up - but
firefox could no longer connect externally.  I eventually tracked
that to my logs taking the space.  But one reason the logs had
become so big was the following (found from this morning's restart):

Aug 27 09:50:28 ac4tv kernel: [  124.279813] BUG: scheduling while
atomic: qemu-system-x86/1789/0x0002
Aug 27 09:50:28 ac4tv kernel: [  124.279819] Modules linked in:
psmouse i2c_piix4 asus_atk0110 microcode k10temp
Aug 27 09:50:28 ac4tv kernel: [  124.279828] Preemption disabled
at:[8100787c] kvm_vcpu_ioctl+0x7c/0x580
Aug 27 09:50:28 ac4tv kernel: [  124.279839] 
Aug 27 09:50:28 ac4tv kernel: [  124.279842] CPU: 2 PID: 1789 Comm:
qemu-system-x86 Not tainted 4.1.0-10762-g8c7febe #4
Aug 27 09:50:28 ac4tv kernel: [  124.279843] Hardware name: System
manufacturer System Product Name/M5A78L-M LX V2, BIOS 0601
11/30/2011
Aug 27 09:50:28 ac4tv kernel: [  124.279845]  88021fd14880
88020718fc38 8178316e 8002
Aug 27 09:50:28 ac4tv kernel: [  124.279847]  00014880
88020718fc48 810b93d7 88020718fca8
Aug 27 09:50:28 ac4tv kernel: [  124.279849]  8178607c
88021fc14880 880215ebc100 88020718fc78
Aug 27 09:50:28 ac4tv kernel: [  124.279851] Call Trace:
Aug 27 09:50:28 ac4tv kernel: [  124.279855]  [8178316e]
dump_stack+0x4f/0x7b
Aug 27 09:50:28 ac4tv kernel: [  124.279859]  [810b93d7]
__schedule_bug+0x57/0xa0
Aug 27 09:50:28 ac4tv kernel: [  124.279861]  [8178607c]
__schedule+0x67c/0x9d0
Aug 27 09:50:28 ac4tv kernel: [  124.279864]  [8178b008] ?
_raw_write_unlock_irqrestore+0x18/0x40
Aug 27 09:50:28 ac4tv kernel: [  124.279865]  [817864b1]
schedule+0x41/0x90
Aug 27 09:50:28 ac4tv kernel: [  124.279867]  [81786888]
schedule_preempt_disabled+0x18/0x30
Aug 27 09:50:28 ac4tv kernel: [  124.279869]  [81788f9d]
__mutex_lock_slowpath+0x10d/0x340
Aug 27 09:50:28 ac4tv kernel: [  124.279871]  [817891e6]
mutex_lock+0x16/0x30
Aug 27 09:50:28 ac4tv kernel: [  124.279874]  [8115c4c2]
static_key_slow_inc+0x42/0xc0
Aug 27 09:50:28 ac4tv kernel: [  124.279875]  [810b92dd]
preempt_notifier_register+0x1d/0x60
Aug 27 09:50:28 ac4tv kernel: [  124.279881]  [8100774d]
vcpu_load+0x4d/0x90
Aug 27 09:50:28 ac4tv kernel: [  124.279887]  [8100787c]
kvm_vcpu_ioctl+0x7c/0x580
Aug 27 09:50:28 ac4tv kernel: [  124.279892]  [8178af77] ?
_raw_write_unlock_irq+0x17/0x40
Aug 27 09:50:28 ac4tv kernel: [  124.279898]  [811bb445]
do_vfs_ioctl+0x295/0x480
Aug 27 09:50:28 ac4tv kernel: [  124.279905]  [811c5189] ?
__fget+0x79/0xb0
Aug 27 09:50:28 ac4tv kernel: [  124.279910]  [811bb67c]
SyS_ioctl+0x4c/0x90
Aug 27 09:50:28 ac4tv kernel: [  124.279914]  [8115cf23] ?
context_tracking_user_enter+0x13/0x20
Aug 27 09:50:28 ac4tv kernel: [  124.279917]  [8105c055] ?
syscall_trace_leave+0xa5/0x140
Aug 27 09:50:28 ac4tv kernel: [  124.279919]  [8178b657]
entry_SYSCALL_64_fastpath+0x12/0x6a
Aug 27 09:50:28 ac4tv kernel: [  124.477786] kvm: zapping shadow
pages for mmio generation wraparound
Aug 27 09:50:31 ac4tv kernel: [  127.177303] BUG: scheduling while
atomic: qemu-system-x86/1788/0x0002
Aug 27 09:50:31 ac4tv kernel: [  127.177309] Modules linked in:
Aug 27 09:50:31 ac4tv kernel: [  127.177317] BUG: scheduling while
atomic: qemu-system-x86/1790/0x0002
Aug 27 09:50:31 ac4tv kernel: [  127.177318]  psmouse i2c_piix4
asus_atk0110 microcode k10temp
Aug 27 09:50:31 ac4tv kernel: [  127.177332] Preemption disabled at:
Aug 27 09:50:31 ac4tv kernel: [  127.177334] Modules linked in:
psmouse i2c_piix4 asus_atk0110 microcode k10temp
Aug 27 09:50:31 ac4tv kernel: [  127.177341] Preemption disabled
at:[8100787c] kvm_vcpu_ioctl+0x7c/0x580
 etc, etc.

I have not _noticed_ these messages on -rc8, but for the moment I am
inclined to treat them as another sign of the same problem.  Which
means a fresh bisection.  sigh/

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.
--
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/

Lockups with 4.2-rc kernels and qemu

[Ken Moffat]

(Cc'ing qemu-devel, please keep me in the Cc).

TL;DR - qemu locks up my machine when I use 4.2-rc kernels.

I only use qemu from time to time, mostly to test changes to my own
scripts, or new package versions, in beyond.linuxfromscratch.org.  A
few days ago I came back to that, building an LFS system from the
beginning of this month and then using that to try out my changes.
In the beginning I built a 4.2-rc5 kernel and booted that system in
qemu-2.4.0.

I had several lockups along the way from a minimal system to the end
of my attempts to build a full desktop, and in fact I dropped back
to a 4.1 kernel and qemu-2.3.0 before I completed the build.  Mostly,
the qemu system appeared to have been idle when the box locked up, or
else idle apart from xscreensaver, but on one occasion it ran through
several steps to build Xorg protocol header packages - I write a
'stamp' file so that I can resume after a failure, and several of
these were created, but empty (instead of a small amount of version,
time, space data) and it later turned out that nothing had been
installed for those packages.

In all cases I have nothing relevant in either the guest or the host
logs.  On one or two occasions I got the flashing keyboard LEDs.

After the initial problems I ran memtest86+ for 10 hours without any
errors.

In the end, I dropped back to a 4.1 kernel and also qemu-2.3.0
because my concern was to finish the build.  I was thinking -
erroneously, of course - that this was a qemu problem.  Gradually, I
moved to 4.2-rc kernels and things appeared to be ok.  But today I
installed 4.2-rc8 and thought about trying to create a test-case to
see if the kernel+qemu combination is probably ok.  I decided to
start qemu, login, run startx [ xscreensaver will be invoked,
otherwise userspace is idle ], and leave it for 3 hours - lockups
varied in how long they took to appear, but all were in 2 hours or
less.  So, I left -rc8 and qemu-2.3.0, and when I returned to it
after about 3 and a quarter hours the box had locked up.

The machine is an AMD phenom (not always the most reliable, I had to
drop caches today to get it to reliably build -rc8 with make -j 4
but otherwise it seems to have not needed that in the past month).
I'll attach the kernel config.

I compiled qemu-2.3.0 with:

sed -i '/resource/ i#include ' \
  fsdev/virtfs-proxy-helper.c

./configure --prefix=/usr \
--sysconfdir=/etc \
--docdir=/usr/share/doc/qemu-2.3.0 \
--target-list=x86_64-softmmu \
--audio-drv-list=alsa

and I use a wrapper script for qemu which tells me that what I am
actually running is:

qemu-system-x86_64 -enable-kvm -hda svn20150803-32-desk2.img -hdb
svn-logging-tools.img  -m 2G -usb -usbdevice tablet -show-cursor
-display sdl  -cpu kvm32 -monitor stdio -smp 4 -vga std

That was for building a new system, later runs only use a -hda
image.  And all of the uses have been for i686 guests.

The host (and the initial guest used to build the new system) is
gcc-5.1.0, the newly built guests 5.2.0; binutils 2.25 / 2.25.1;
glibc 2.21 throughout.

Because I need to leave the system running for up to 3 hours to get
an idea if a particular kernel is ok, I don't think this problem
lends itself to bisection.

Any suggestions, please ?

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.2.0-rc8 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y

Lockups with 4.2-rc kernels and qemu

[Ken Moffat]

(Cc'ing qemu-devel, please keep me in the Cc).

TL;DR - qemu locks up my machine when I use 4.2-rc kernels.

I only use qemu from time to time, mostly to test changes to my own
scripts, or new package versions, in beyond.linuxfromscratch.org.  A
few days ago I came back to that, building an LFS system from the
beginning of this month and then using that to try out my changes.
In the beginning I built a 4.2-rc5 kernel and booted that system in
qemu-2.4.0.

I had several lockups along the way from a minimal system to the end
of my attempts to build a full desktop, and in fact I dropped back
to a 4.1 kernel and qemu-2.3.0 before I completed the build.  Mostly,
the qemu system appeared to have been idle when the box locked up, or
else idle apart from xscreensaver, but on one occasion it ran through
several steps to build Xorg protocol header packages - I write a
'stamp' file so that I can resume after a failure, and several of
these were created, but empty (instead of a small amount of version,
time, space data) and it later turned out that nothing had been
installed for those packages.

In all cases I have nothing relevant in either the guest or the host
logs.  On one or two occasions I got the flashing keyboard LEDs.

After the initial problems I ran memtest86+ for 10 hours without any
errors.

In the end, I dropped back to a 4.1 kernel and also qemu-2.3.0
because my concern was to finish the build.  I was thinking -
erroneously, of course - that this was a qemu problem.  Gradually, I
moved to 4.2-rc kernels and things appeared to be ok.  But today I
installed 4.2-rc8 and thought about trying to create a test-case to
see if the kernel+qemu combination is probably ok.  I decided to
start qemu, login, run startx [ xscreensaver will be invoked,
otherwise userspace is idle ], and leave it for 3 hours - lockups
varied in how long they took to appear, but all were in 2 hours or
less.  So, I left -rc8 and qemu-2.3.0, and when I returned to it
after about 3 and a quarter hours the box had locked up.

The machine is an AMD phenom (not always the most reliable, I had to
drop caches today to get it to reliably build -rc8 with make -j 4
but otherwise it seems to have not needed that in the past month).
I'll attach the kernel config.

I compiled qemu-2.3.0 with:

sed -i '/resource/ i#include sys/xattr.h' \
  fsdev/virtfs-proxy-helper.c

./configure --prefix=/usr \
--sysconfdir=/etc \
--docdir=/usr/share/doc/qemu-2.3.0 \
--target-list=x86_64-softmmu \
--audio-drv-list=alsa

and I use a wrapper script for qemu which tells me that what I am
actually running is:

qemu-system-x86_64 -enable-kvm -hda svn20150803-32-desk2.img -hdb
svn-logging-tools.img  -m 2G -usb -usbdevice tablet -show-cursor
-display sdl  -cpu kvm32 -monitor stdio -smp 4 -vga std

That was for building a new system, later runs only use a -hda
image.  And all of the uses have been for i686 guests.

The host (and the initial guest used to build the new system) is
gcc-5.1.0, the newly built guests 5.2.0; binutils 2.25 / 2.25.1;
glibc 2.21 throughout.

Because I need to leave the system running for up to 3 hours to get
an idea if a particular kernel is ok, I don't think this problem
lends itself to bisection.

Any suggestions, please ?

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.2.0-rc8 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y

Re: [PATCH] scripts: Extract kernel headers for out of tree modules build

[Ken Moffat]

On Wed, Aug 19, 2015 at 09:50:36AM +0300, Daniel Baluta wrote:
> scripts/package/builddeb already creates a linux-keader .deb
> package, but we need this feature also for non-Debian distros
> (e.g. Android or LFS).
> 
> Signed-off-by: Daniel Baluta 

In general, LFS does not need this - but obviously we give you the
freedom to change whatever you do ("your system, your rules").

In particular, we assume that you will build on the machine where
the kernel will run, and also that you may need to rebuild the kernel
several times (for additional .config choices) depending on what
parts of BLFS you build.  And we do not provide a package manager.
So I submit that we are the people least likely to need this.

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.
--
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] scripts: Extract kernel headers for out of tree modules build

[Ken Moffat]

On Wed, Aug 19, 2015 at 09:50:36AM +0300, Daniel Baluta wrote:
 scripts/package/builddeb already creates a linux-keader .deb
 package, but we need this feature also for non-Debian distros
 (e.g. Android or LFS).
 
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com

In general, LFS does not need this - but obviously we give you the
freedom to change whatever you do (your system, your rules).

In particular, we assume that you will build on the machine where
the kernel will run, and also that you may need to rebuild the kernel
several times (for additional .config choices) depending on what
parts of BLFS you build.  And we do not provide a package manager.
So I submit that we are the people least likely to need this.

ĸen
-- 
This one goes up to eleven: but only on a clear day, with the wind in
the right direction.
--
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: CONFIG_NO_HZ_FULL restricts cpu usage to the equivalent of one in 4.2

[Ken Moffat]

On Wed, Jul 15, 2015 at 12:05:05PM -0700, Andy Lutomirski wrote:
> 
> Before going nuts bisecting, it could be worth running perf record -a -g -e
> cycles (or perhaps -e task-clock instead of -e cycles).  It could also be
> worth manually sampling /proc/PID/stack a few times for a process that isn't
> making as much progress as it should.
> 
> --Andy

I think Frederic has already spotted the problem - in the early
bisects, everything was building on CPU 0.  But thanks for the
suggestion.

ĸen
-- 
This one goes up to eleven!
--
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: CONFIG_NO_HZ_FULL restricts cpu usage to the equivalent of one in 4.2

[Ken Moffat]

On Wed, Jul 15, 2015 at 09:11:46PM +0200, Frederic Weisbecker wrote:
> 2015-07-15 18:27 GMT+02:00 Ken Moffat :
> >
> > The config differences follow.  Perhaps it is actually one of the
> > subsequent choices that is the problem.  And I guess it could still
> > be a gcc-5.1 issue.
> >
> > --- config-4.2-initial  2015-07-15 16:25:12.548005751 +0100
> > +++ config-4.2-speed-ok 2015-07-15 17:00:50.919998703 +0100
> > @@ -104,11 +104,8 @@
> >  CONFIG_TICK_ONESHOT=y
> >  CONFIG_NO_HZ_COMMON=y
> >  # CONFIG_HZ_PERIODIC is not set
> > -# CONFIG_NO_HZ_IDLE is not set
> > -CONFIG_NO_HZ_FULL=y
> > -CONFIG_NO_HZ_FULL_ALL=y
> 
> You had CONFIG_NO_HZ_FULL_ALL enabled? Because that would indeed
> produce that effect since it isolates all CPUs but 0 off sched
> domains.
> 
> Which means that basically only CPU 0 runs user tasks unless you
> forces these otherwise.

Thanks.  I'll put it down to a bad .config choice, although it was
fine on early 4.1.  While I was starting to bisect, I noticed that
on the A10 everything was happening on CPU 0 - not sure if that was
happening on the original box, but for the moment it sounds likely.

ĸen
-- 
This one goes up to eleven!
--
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/

CONFIG_NO_HZ_FULL restricts cpu usage to the equivalent of one in 4.2

[Ken Moffat]

New title, I originally posted this last night but I've now made
a little progress in identifying what changed.  Previous thread was
labelled for AMD Phenom, but it is more general.  CC'ing Jeff
because he replied to the original, I guess he probably won't be
interested after this.

Yesterday was the first day I had done any real compiling with
4.2-rc.  I started out using -rc1, and make -j4 on a recent LFS/BLFS
system (gcc-5.1.0, make-4.1, etc).  I wanted to start trying to
build kde5, and I expected a lot of issues.  What I did not expect
was that qt5 would build as if I was using -j1.

Examination eventually identified that with 4.2-rc1 and 4.2-rc2,
make ran the number of jobs I had specified, but the total of the
CPU percentages ('top' from procps-ng-3.3.10) maxed out at 100%.  On
4.1 kernels the percentage with -j4 maxes out at 400% (my machine
has 4 cores).  I suspected either an unfortunate choice in 'make
oldconfig', or something specific to an AMD Phenom / gcc-5.1.

Today I have tried make -j4 on two other machines with 4.2-rc
kernels [ building the current git stable release ].  On my i3
SandyBridge everything was fine, CPU usage approached 400%.  On my
AMD A10-7850K I have the same problem as on the phenom.  Not
surprising, I began by using the Phenom config when I got the A10,
then adapted it to suit, whereas the i3 has much less memory so I
haven't made many changes since I got it.

Comparing the configs for the i3 and the A10, the first thing which
looked as if it might be relevant was the _CPU_ACCOUNTING choices.
Those on the A10 seem to be driven from CONFIG_NO_HZ_FULL so I began
by changing that to CONFIG_NO_HZ_IDLE.  Payday ;-)  make -j4 now
approaches 400% CPU usage.

The config differences follow.  Perhaps it is actually one of the
subsequent choices that is the problem.  And I guess it could still
be a gcc-5.1 issue.

--- config-4.2-initial  2015-07-15 16:25:12.548005751 +0100
+++ config-4.2-speed-ok 2015-07-15 17:00:50.919998703 +0100
@@ -104,11 +104,8 @@
 CONFIG_TICK_ONESHOT=y
 CONFIG_NO_HZ_COMMON=y
 # CONFIG_HZ_PERIODIC is not set
-# CONFIG_NO_HZ_IDLE is not set
-CONFIG_NO_HZ_FULL=y
-CONFIG_NO_HZ_FULL_ALL=y
-CONFIG_NO_HZ_FULL_SYSIDLE=y
-CONFIG_NO_HZ_FULL_SYSIDLE_SMALL=4
+CONFIG_NO_HZ_IDLE=y
+# CONFIG_NO_HZ_FULL is not set
 # CONFIG_NO_HZ is not set
 CONFIG_HIGH_RES_TIMERS=y
 
@@ -116,7 +113,9 @@
 # CPU/Task time and stats accounting
 #
 CONFIG_VIRT_CPU_ACCOUNTING=y
+# CONFIG_TICK_CPU_ACCOUNTING is not set
 CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
+# CONFIG_IRQ_TIME_ACCOUNTING is not set
 # CONFIG_BSD_PROCESS_ACCT is not set
 CONFIG_TASKSTATS=y
 CONFIG_TASK_DELAY_ACCT=y
@@ -131,7 +130,6 @@
 # CONFIG_TASKS_RCU is not set
 CONFIG_RCU_STALL_COMMON=y
 CONFIG_CONTEXT_TRACKING=y
-CONFIG_RCU_USER_QS=y
 CONFIG_CONTEXT_TRACKING_FORCE=y
 # CONFIG_TREE_RCU_TRACE is not set
 CONFIG_RCU_NOCB_CPU=y

Anyway, I'll start a bisection.  But it might take me a few days,
this is not a convenient time (somehow, kernel issues which need
bisection always come at a bad time for me).

ĸen
-- 
This one goes up to eleven!
--
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: make -jN (n>1) ineffective in 4.2.0-rc on AMD Phenom

[Ken Moffat]

On Tue, Jul 14, 2015 at 09:23:31PM -0500, Jeff Epler wrote:
> GNU Make 4.1 has a problem that causes it to be unable to use the
> desired level of parallelism.  Two people have reported that reverting a
> commit which changes from fork to vfork "fixes" it. (i'm one of them,
> unfortunately posting as anonymous in the tracker).
> 
> Hoewver, if you are also seeing the linux kernel version as relevant to
> producing the problem, that's quite interesting, and the underlying
> cause may be different.  We reproduced the problem on a range of older
> kernels, from 3.2 to 3.18.
> 
> http://savannah.gnu.org/bugs/?44555
> 
> Jeff

Thanks, but I think this is a different problem, I was probably not
clear : I specify make -j4 and make does indeed run 4 jobs, but it
is only getting the equivalent of 1 CPU instead of 4.  It is
running 4 jobs, but on the equivalent of 1  processor (so this takes
much longer than -j1).

The reason I think it is a different problem is that I upgraded to
make-4.1 in November and everything has been fine until now.

With 'top' from procps-ng-3.3.10 the display can show how active
each CPU is (indeed, I think that is the default) - on earlier
versions of 'top' I think that the output was very different.

ĸen
-- 
This one goes up to eleven!
--
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: CONFIG_NO_HZ_FULL restricts cpu usage to the equivalent of one in 4.2

[Ken Moffat]

On Wed, Jul 15, 2015 at 09:11:46PM +0200, Frederic Weisbecker wrote:
 2015-07-15 18:27 GMT+02:00 Ken Moffat zarniwh...@ntlworld.com:
 
  The config differences follow.  Perhaps it is actually one of the
  subsequent choices that is the problem.  And I guess it could still
  be a gcc-5.1 issue.
 
  --- config-4.2-initial  2015-07-15 16:25:12.548005751 +0100
  +++ config-4.2-speed-ok 2015-07-15 17:00:50.919998703 +0100
  @@ -104,11 +104,8 @@
   CONFIG_TICK_ONESHOT=y
   CONFIG_NO_HZ_COMMON=y
   # CONFIG_HZ_PERIODIC is not set
  -# CONFIG_NO_HZ_IDLE is not set
  -CONFIG_NO_HZ_FULL=y
  -CONFIG_NO_HZ_FULL_ALL=y
 
 You had CONFIG_NO_HZ_FULL_ALL enabled? Because that would indeed
 produce that effect since it isolates all CPUs but 0 off sched
 domains.
 
 Which means that basically only CPU 0 runs user tasks unless you
 forces these otherwise.

Thanks.  I'll put it down to a bad .config choice, although it was
fine on early 4.1.  While I was starting to bisect, I noticed that
on the A10 everything was happening on CPU 0 - not sure if that was
happening on the original box, but for the moment it sounds likely.

ĸen
-- 
This one goes up to eleven!
--
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: CONFIG_NO_HZ_FULL restricts cpu usage to the equivalent of one in 4.2

[Ken Moffat]

On Wed, Jul 15, 2015 at 12:05:05PM -0700, Andy Lutomirski wrote:
 
 Before going nuts bisecting, it could be worth running perf record -a -g -e
 cycles (or perhaps -e task-clock instead of -e cycles).  It could also be
 worth manually sampling /proc/PID/stack a few times for a process that isn't
 making as much progress as it should.
 
 --Andy

I think Frederic has already spotted the problem - in the early
bisects, everything was building on CPU 0.  But thanks for the
suggestion.

ĸen
-- 
This one goes up to eleven!
--
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: make -jN (n1) ineffective in 4.2.0-rc on AMD Phenom

[Ken Moffat]

On Tue, Jul 14, 2015 at 09:23:31PM -0500, Jeff Epler wrote:
 GNU Make 4.1 has a problem that causes it to be unable to use the
 desired level of parallelism.  Two people have reported that reverting a
 commit which changes from fork to vfork fixes it. (i'm one of them,
 unfortunately posting as anonymous in the tracker).
 
 Hoewver, if you are also seeing the linux kernel version as relevant to
 producing the problem, that's quite interesting, and the underlying
 cause may be different.  We reproduced the problem on a range of older
 kernels, from 3.2 to 3.18.
 
 http://savannah.gnu.org/bugs/?44555
 
 Jeff

Thanks, but I think this is a different problem, I was probably not
clear : I specify make -j4 and make does indeed run 4 jobs, but it
is only getting the equivalent of 1 CPU instead of 4.  It is
running 4 jobs, but on the equivalent of 1  processor (so this takes
much longer than -j1).

The reason I think it is a different problem is that I upgraded to
make-4.1 in November and everything has been fine until now.

With 'top' from procps-ng-3.3.10 the display can show how active
each CPU is (indeed, I think that is the default) - on earlier
versions of 'top' I think that the output was very different.

ĸen
-- 
This one goes up to eleven!
--
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/

CONFIG_NO_HZ_FULL restricts cpu usage to the equivalent of one in 4.2

[Ken Moffat]

New title, I originally posted this last night but I've now made
a little progress in identifying what changed.  Previous thread was
labelled for AMD Phenom, but it is more general.  CC'ing Jeff
because he replied to the original, I guess he probably won't be
interested after this.

Yesterday was the first day I had done any real compiling with
4.2-rc.  I started out using -rc1, and make -j4 on a recent LFS/BLFS
system (gcc-5.1.0, make-4.1, etc).  I wanted to start trying to
build kde5, and I expected a lot of issues.  What I did not expect
was that qt5 would build as if I was using -j1.

Examination eventually identified that with 4.2-rc1 and 4.2-rc2,
make ran the number of jobs I had specified, but the total of the
CPU percentages ('top' from procps-ng-3.3.10) maxed out at 100%.  On
4.1 kernels the percentage with -j4 maxes out at 400% (my machine
has 4 cores).  I suspected either an unfortunate choice in 'make
oldconfig', or something specific to an AMD Phenom / gcc-5.1.

Today I have tried make -j4 on two other machines with 4.2-rc
kernels [ building the current git stable release ].  On my i3
SandyBridge everything was fine, CPU usage approached 400%.  On my
AMD A10-7850K I have the same problem as on the phenom.  Not
surprising, I began by using the Phenom config when I got the A10,
then adapted it to suit, whereas the i3 has much less memory so I
haven't made many changes since I got it.

Comparing the configs for the i3 and the A10, the first thing which
looked as if it might be relevant was the _CPU_ACCOUNTING choices.
Those on the A10 seem to be driven from CONFIG_NO_HZ_FULL so I began
by changing that to CONFIG_NO_HZ_IDLE.  Payday ;-)  make -j4 now
approaches 400% CPU usage.

The config differences follow.  Perhaps it is actually one of the
subsequent choices that is the problem.  And I guess it could still
be a gcc-5.1 issue.

--- config-4.2-initial  2015-07-15 16:25:12.548005751 +0100
+++ config-4.2-speed-ok 2015-07-15 17:00:50.919998703 +0100
@@ -104,11 +104,8 @@
 CONFIG_TICK_ONESHOT=y
 CONFIG_NO_HZ_COMMON=y
 # CONFIG_HZ_PERIODIC is not set
-# CONFIG_NO_HZ_IDLE is not set
-CONFIG_NO_HZ_FULL=y
-CONFIG_NO_HZ_FULL_ALL=y
-CONFIG_NO_HZ_FULL_SYSIDLE=y
-CONFIG_NO_HZ_FULL_SYSIDLE_SMALL=4
+CONFIG_NO_HZ_IDLE=y
+# CONFIG_NO_HZ_FULL is not set
 # CONFIG_NO_HZ is not set
 CONFIG_HIGH_RES_TIMERS=y
 
@@ -116,7 +113,9 @@
 # CPU/Task time and stats accounting
 #
 CONFIG_VIRT_CPU_ACCOUNTING=y
+# CONFIG_TICK_CPU_ACCOUNTING is not set
 CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
+# CONFIG_IRQ_TIME_ACCOUNTING is not set
 # CONFIG_BSD_PROCESS_ACCT is not set
 CONFIG_TASKSTATS=y
 CONFIG_TASK_DELAY_ACCT=y
@@ -131,7 +130,6 @@
 # CONFIG_TASKS_RCU is not set
 CONFIG_RCU_STALL_COMMON=y
 CONFIG_CONTEXT_TRACKING=y
-CONFIG_RCU_USER_QS=y
 CONFIG_CONTEXT_TRACKING_FORCE=y
 # CONFIG_TREE_RCU_TRACE is not set
 CONFIG_RCU_NOCB_CPU=y

Anyway, I'll start a bisection.  But it might take me a few days,
this is not a convenient time (somehow, kernel issues which need
bisection always come at a bad time for me).

ĸen
-- 
This one goes up to eleven!
--
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: make -jN (n>1) ineffective in 4.2.0-rc on AMD Phenom

[Ken Moffat]

On Wed, Jul 15, 2015 at 12:39:20AM +0100, Ken Moffat wrote:
> 
> At that stage I assumed I must have somehow buggered up the 4.2
> config - if everybody was hitting this sort of slowdown, somebody
> would surely have noticed.  So, I downloaded 4.2.0-rc2 and built
> that from 4.1.1, taking care to think about each configure option
> (but nothing jumped out as likely to be relevant).  Booted that, but
> the problem continues.
> 
In fact, I built it from 4.1.0 as the diff of the two configs shows.

ĸen
-- 
This one goes up to eleven!
--
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/

make -jN (n>1) ineffective in 4.2.0-rc on AMD Phenom

[Ken Moffat]

One of my machines is an AMD Phenom.  I wanted to explore building
some new (to me) userspace, and this machine had a system which was
both recent enough (last month's LFS/BLFS) and with enough space to
make it seem like a good place to do it.

I finally got round to trying to build qt-5 (5.5.0), running
4.2.0-rc1.  For the minor packages before qt I had been building one
or two at a time, and leaving the machine.  I'm using MAKEFLAGS of
'-j4 -O'.  For qt I was a bit surprised to see that the system only
appeared to be using one CPU whenever I checked it (looking at the
taskbar cpu window in icewm), but I assumed that I was probably
looking at inopportune times (i.e. waiting for some dependency to
complete).  That build eventually failed in the qtwebengine part
(known problem with gcc-5.1, a patch for gcc is available), but only
after six and a quarter hours.

At that point I suspected that something might be wrong in my
scripts, but I eventually confirmed that my MAKEFLAGS were indeed
being picked up.  Then I fired up 'top' (procps-ng-3.3.10) and saw
that CPU usage was indeed maxing out at 100% (instead of the
expected 400%).

Back to 4.1.0, started the qt build - during the (long) configure
step the CPU total was between 100% and 115% (Xorg, 3 rxvt-unicode
terms, one vim session, one buildscript, and top) and then it
approached 400% as soon as 'make' started.

At that stage I assumed I must have somehow buggered up the 4.2
config - if everybody was hitting this sort of slowdown, somebody
would surely have noticed.  So, I downloaded 4.2.0-rc2 and built
that from 4.1.1, taking care to think about each configure option
(but nothing jumped out as likely to be relevant).  Booted that, but
the problem continues.

If I build _any_ package using MAKEFLAGS of '-j4 -O' it still only
gets the equivalent of one CPU.  Even a manual 'make -j4' (to ensure
it isn't a script problem). I haven't been building much since
I installed 4.2-rc1, not sure if the problem is specific to this
config / this system.

The machine is an AMD Phenom(tm) II X4 965 Processor and gcc is
5.1.0.  I'll attach my config, and also a diff from the good 4.1.0
config in case it is something obvious.  Meanwhile, I'll go back to
4.1 to contine my attempt to test the new userspace packages.  I
suppose that I can bisect it if I have to, but at the moment this is
not a good time.

ĸen
-- 
This one goes up to eleven!
(for this case, "goes up to one" would be better ;-)
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.2.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y

Re: make -jN (n1) ineffective in 4.2.0-rc on AMD Phenom

[Ken Moffat]

On Wed, Jul 15, 2015 at 12:39:20AM +0100, Ken Moffat wrote:
 
 At that stage I assumed I must have somehow buggered up the 4.2
 config - if everybody was hitting this sort of slowdown, somebody
 would surely have noticed.  So, I downloaded 4.2.0-rc2 and built
 that from 4.1.1, taking care to think about each configure option
 (but nothing jumped out as likely to be relevant).  Booted that, but
 the problem continues.
 
In fact, I built it from 4.1.0 as the diff of the two configs shows.

ĸen
-- 
This one goes up to eleven!
--
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/

make -jN (n1) ineffective in 4.2.0-rc on AMD Phenom

[Ken Moffat]

One of my machines is an AMD Phenom.  I wanted to explore building
some new (to me) userspace, and this machine had a system which was
both recent enough (last month's LFS/BLFS) and with enough space to
make it seem like a good place to do it.

I finally got round to trying to build qt-5 (5.5.0), running
4.2.0-rc1.  For the minor packages before qt I had been building one
or two at a time, and leaving the machine.  I'm using MAKEFLAGS of
'-j4 -O'.  For qt I was a bit surprised to see that the system only
appeared to be using one CPU whenever I checked it (looking at the
taskbar cpu window in icewm), but I assumed that I was probably
looking at inopportune times (i.e. waiting for some dependency to
complete).  That build eventually failed in the qtwebengine part
(known problem with gcc-5.1, a patch for gcc is available), but only
after six and a quarter hours.

At that point I suspected that something might be wrong in my
scripts, but I eventually confirmed that my MAKEFLAGS were indeed
being picked up.  Then I fired up 'top' (procps-ng-3.3.10) and saw
that CPU usage was indeed maxing out at 100% (instead of the
expected 400%).

Back to 4.1.0, started the qt build - during the (long) configure
step the CPU total was between 100% and 115% (Xorg, 3 rxvt-unicode
terms, one vim session, one buildscript, and top) and then it
approached 400% as soon as 'make' started.

At that stage I assumed I must have somehow buggered up the 4.2
config - if everybody was hitting this sort of slowdown, somebody
would surely have noticed.  So, I downloaded 4.2.0-rc2 and built
that from 4.1.1, taking care to think about each configure option
(but nothing jumped out as likely to be relevant).  Booted that, but
the problem continues.

If I build _any_ package using MAKEFLAGS of '-j4 -O' it still only
gets the equivalent of one CPU.  Even a manual 'make -j4' (to ensure
it isn't a script problem). I haven't been building much since
I installed 4.2-rc1, not sure if the problem is specific to this
config / this system.

The machine is an AMD Phenom(tm) II X4 965 Processor and gcc is
5.1.0.  I'll attach my config, and also a diff from the good 4.1.0
config in case it is something obvious.  Meanwhile, I'll go back to
4.1 to contine my attempt to test the new userspace packages.  I
suppose that I can bisect it if I have to, but at the moment this is
not a good time.

ĸen
-- 
This one goes up to eleven!
(for this case, goes up to one would be better ;-)
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.2.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME=(none)
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y

Re: Lost network connectivity in 4.0.x

[Ken Moffat]

On Thu, May 28, 2015 at 03:41:49PM +0100, Ken Moffat wrote:
> On Wed, May 27, 2015 at 10:53:00PM -0700, Cong Wang wrote:
> > (Please always Cc netdev for networking bugs.)
> > 
Sorry, didn't spot that.  But anyway
> 
> > For example:
> > 
> > 1) What is your network setup? iptables? routes? etc.
> > 
> I'm using iptables.  Ah, yes - it started dropping packets around
> the time I last had a problem:
> 
> May 27 00:48:26 ac4tv dhclient: DHCPREQUEST on eth0 to 192.168.7.254
> port 67
> May 27 00:48:27 ac4tv dhclient: DHCPACK from 192.168.7.254
> May 27 00:48:27 ac4tv dhclient: bound to 192.168.7.152 -- renewal in
> 1787 seconds.
> 
>  That address came from my router, and I had been getting the same
> address for an hour, tbut then the dropped packet messages start
> appearing - they are for a different address, one that would have
> been offered by my server:
> 
Now that I've had time to think about this and look a bit more
deeply, I can see that at one point I got a lease from my server,
but then after a random length of time the client tried to renew and
got a lease from the router.  Some time after that, it failed
because iptables rejected the nfs packets because they were "not for
me".

So, not a kernel problem, and the reason I'm (now) seeing this on
4.0+ kernels is that I have not recently booted a system with an old
(3.19 or earlier) kernel and kept it running for a long time.

Thanks again, sorry to waste everybody's bandwidth.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Lost network connectivity in 4.0.x

[Ken Moffat]

On Wed, May 27, 2015 at 10:53:00PM -0700, Cong Wang wrote:
> (Please always Cc netdev for networking bugs.)
> 
> On Sat, May 23, 2015 at 8:29 PM, Ken Moffat  wrote:
> > On Sun, May 24, 2015 at 03:43:52AM +0100, Ken Moffat wrote:
> >> Anybody else suffering frm lost network connectivity in 4.0.x
> >> kernels ?  A couple of times this week, vim on an nfs-3 mount hung
> >> and I had to reboot.  Both of those occasions were on an AMD desktop
> >> with the r8169 driver, running 4.0.3.  I thought it might be
> >> specific to that machine.  For the last two or three days I've been
> >> using an intel, and about 10 minutes ago it suffered the same problem
> >> while running 4.0.4.  Using ping from another term showed that it
> >> had no connectivity to the server on my local network.
> >>
> >> This is a bit hard to diagnose - nothing in the logs.
> >>
> > I forgot to add that this is with the released gcc-5.1 : I keep
> > forgetting that some people use old compilers ;-)
> >
> 
> Is there any way you can help to narrow down the problem?
> 

Thanks for the reply.  The problem is continuing to show up, but
irregularly and often only after the machine has been booted for a
long time (with s2ram, but I don't think I've used s2ram on every
occasion).

> For example:
> 
> 1) What is your network setup? iptables? routes? etc.
> 
I'm using iptables.  Ah, yes - it started dropping packets around
the time I last had a problem:

May 27 00:48:26 ac4tv dhclient: DHCPREQUEST on eth0 to 192.168.7.254
port 67
May 27 00:48:27 ac4tv dhclient: DHCPACK from 192.168.7.254
May 27 00:48:27 ac4tv dhclient: bound to 192.168.7.152 -- renewal in
1787 seconds.

 That address came from my router, and I had been getting the same
address for an hour, tbut then the dropped packet messages start
appearing - they are for a different address, one that would have
been offered by my server:

May 27 00:53:16 ac4tv kernel: [31922.316798] IPTABLES Packet
Dropped: IN=eth0 OUT= MAC=c8:60:00:97:07:35:bc:ae:c5:57:70:c5:08:00
SRC=192.168.7.11 DST=192.168.7.121 LEN=60 TOS=0x00 PREC=0x00 TTL=64
ID=0 DF PROTO=TCP SPT=2049 DPT=1005 WINDOW=28960 RES=0x00 ACK SYN
URGP=0 
May 27 00:53:17 ac4tv kernel: [31923.316612] IPTABLES Packet
Dropped: IN=eth0 OUT= MAC=c8:60:00:97:07:35:bc:ae:c5:57:70:c5:08:00
SRC=192.168.7.11 DST=192.168.7.121 LEN=60 TOS=0x00 PREC=0x00 TTL=64
ID=0 DF PROTO=TCP SPT=2049 DPT=1005 WINDOW=28960 RES=0x00 ACK SYN
URGP=0 

and those continued until I forced a reboot.

> 2) Can you check the stats to see if there is any error?
>   `ip -s -s li show`, `ethtool -S `
> 

I don't have ethtool installed, and that ip command appears ok at
the moment:

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes  packets  errors  dropped overrun mcast   
3964   66   0   0   0   0   
RX errors: length   crc frame   fifomissed
   00   0   0   0   
TX: bytes  packets  errors  dropped carrier collsns 
3964   66   0   0   0   0   
TX errors: aborted  fifo   window heartbeat transns
   00   0   0   0   
2: eth0:  mtu 1500 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 1000
link/ether c8:60:00:97:07:35 brd ff:ff:ff:ff:ff:ff
RX: bytes  packets  errors  dropped overrun mcast   
224661061  277642   0   0   0   0   
RX errors: length   crc frame   fifomissed
   00   0   0   0   
TX: bytes  packets  errors  dropped carrier collsns 
278152429  370438   0   0   0   0   
TX errors: aborted  fifo   window heartbeat transns
   00   0   0   6   

> 3) Do a bisect?
> 
> Thanks!

That doesn't seem very practical when the machine is ok for a couple
of days at a time.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Lost network connectivity in 4.0.x

[Ken Moffat]

On Wed, May 27, 2015 at 10:53:00PM -0700, Cong Wang wrote:
 (Please always Cc netdev for networking bugs.)
 
 On Sat, May 23, 2015 at 8:29 PM, Ken Moffat zarniwh...@ntlworld.com wrote:
  On Sun, May 24, 2015 at 03:43:52AM +0100, Ken Moffat wrote:
  Anybody else suffering frm lost network connectivity in 4.0.x
  kernels ?  A couple of times this week, vim on an nfs-3 mount hung
  and I had to reboot.  Both of those occasions were on an AMD desktop
  with the r8169 driver, running 4.0.3.  I thought it might be
  specific to that machine.  For the last two or three days I've been
  using an intel, and about 10 minutes ago it suffered the same problem
  while running 4.0.4.  Using ping from another term showed that it
  had no connectivity to the server on my local network.
 
  This is a bit hard to diagnose - nothing in the logs.
 
  I forgot to add that this is with the released gcc-5.1 : I keep
  forgetting that some people use old compilers ;-)
 
 
 Is there any way you can help to narrow down the problem?
 

Thanks for the reply.  The problem is continuing to show up, but
irregularly and often only after the machine has been booted for a
long time (with s2ram, but I don't think I've used s2ram on every
occasion).

 For example:
 
 1) What is your network setup? iptables? routes? etc.
 
I'm using iptables.  Ah, yes - it started dropping packets around
the time I last had a problem:

May 27 00:48:26 ac4tv dhclient: DHCPREQUEST on eth0 to 192.168.7.254
port 67
May 27 00:48:27 ac4tv dhclient: DHCPACK from 192.168.7.254
May 27 00:48:27 ac4tv dhclient: bound to 192.168.7.152 -- renewal in
1787 seconds.

 That address came from my router, and I had been getting the same
address for an hour, tbut then the dropped packet messages start
appearing - they are for a different address, one that would have
been offered by my server:

May 27 00:53:16 ac4tv kernel: [31922.316798] IPTABLES Packet
Dropped: IN=eth0 OUT= MAC=c8:60:00:97:07:35:bc:ae:c5:57:70:c5:08:00
SRC=192.168.7.11 DST=192.168.7.121 LEN=60 TOS=0x00 PREC=0x00 TTL=64
ID=0 DF PROTO=TCP SPT=2049 DPT=1005 WINDOW=28960 RES=0x00 ACK SYN
URGP=0 
May 27 00:53:17 ac4tv kernel: [31923.316612] IPTABLES Packet
Dropped: IN=eth0 OUT= MAC=c8:60:00:97:07:35:bc:ae:c5:57:70:c5:08:00
SRC=192.168.7.11 DST=192.168.7.121 LEN=60 TOS=0x00 PREC=0x00 TTL=64
ID=0 DF PROTO=TCP SPT=2049 DPT=1005 WINDOW=28960 RES=0x00 ACK SYN
URGP=0 

and those continued until I forced a reboot.

 2) Can you check the stats to see if there is any error?
   `ip -s -s li show`, `ethtool -S DEV`
 

I don't have ethtool installed, and that ip command appears ok at
the moment:

1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes  packets  errors  dropped overrun mcast   
3964   66   0   0   0   0   
RX errors: length   crc frame   fifomissed
   00   0   0   0   
TX: bytes  packets  errors  dropped carrier collsns 
3964   66   0   0   0   0   
TX errors: aborted  fifo   window heartbeat transns
   00   0   0   0   
2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 1000
link/ether c8:60:00:97:07:35 brd ff:ff:ff:ff:ff:ff
RX: bytes  packets  errors  dropped overrun mcast   
224661061  277642   0   0   0   0   
RX errors: length   crc frame   fifomissed
   00   0   0   0   
TX: bytes  packets  errors  dropped carrier collsns 
278152429  370438   0   0   0   0   
TX errors: aborted  fifo   window heartbeat transns
   00   0   0   6   

 3) Do a bisect?
 
 Thanks!

That doesn't seem very practical when the machine is ok for a couple
of days at a time.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Lost network connectivity in 4.0.x

[Ken Moffat]

On Thu, May 28, 2015 at 03:41:49PM +0100, Ken Moffat wrote:
 On Wed, May 27, 2015 at 10:53:00PM -0700, Cong Wang wrote:
  (Please always Cc netdev for networking bugs.)
  
Sorry, didn't spot that.  But anyway
 
  For example:
  
  1) What is your network setup? iptables? routes? etc.
  
 I'm using iptables.  Ah, yes - it started dropping packets around
 the time I last had a problem:
 
 May 27 00:48:26 ac4tv dhclient: DHCPREQUEST on eth0 to 192.168.7.254
 port 67
 May 27 00:48:27 ac4tv dhclient: DHCPACK from 192.168.7.254
 May 27 00:48:27 ac4tv dhclient: bound to 192.168.7.152 -- renewal in
 1787 seconds.
 
  That address came from my router, and I had been getting the same
 address for an hour, tbut then the dropped packet messages start
 appearing - they are for a different address, one that would have
 been offered by my server:
 
Now that I've had time to think about this and look a bit more
deeply, I can see that at one point I got a lease from my server,
but then after a random length of time the client tried to renew and
got a lease from the router.  Some time after that, it failed
because iptables rejected the nfs packets because they were not for
me.

So, not a kernel problem, and the reason I'm (now) seeing this on
4.0+ kernels is that I have not recently booted a system with an old
(3.19 or earlier) kernel and kept it running for a long time.

Thanks again, sorry to waste everybody's bandwidth.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Lost network connectivity in 4.0.x

[Ken Moffat]

On Sun, May 24, 2015 at 03:43:52AM +0100, Ken Moffat wrote:
> Anybody else suffering frm lost network connectivity in 4.0.x
> kernels ?  A couple of times this week, vim on an nfs-3 mount hung
> and I had to reboot.  Both of those occasions were on an AMD desktop
> with the r8169 driver, running 4.0.3.  I thought it might be
> specific to that machine.  For the last two or three days I've been
> using an intel, and about 10 minutes ago it suffered the same problem
> while running 4.0.4.  Using ping from another term showed that it
> had no connectivity to the server on my local network.
> 
> This is a bit hard to diagnose - nothing in the logs.
> 
I forgot to add that this is with the released gcc-5.1 : I keep
forgetting that some people use old compilers ;-)

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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/

Lost network connectivity in 4.0.x

[Ken Moffat]

Anybody else suffering frm lost network connectivity in 4.0.x
kernels ?  A couple of times this week, vim on an nfs-3 mount hung
and I had to reboot.  Both of those occasions were on an AMD desktop
with the r8169 driver, running 4.0.3.  I thought it might be
specific to that machine.  For the last two or three days I've been
using an intel, and about 10 minutes ago it suffered the same problem
while running 4.0.4.  Using ping from another term showed that it
had no connectivity to the server on my local network.

This is a bit hard to diagnose - nothing in the logs.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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/

Lost network connectivity in 4.0.x

[Ken Moffat]

Anybody else suffering frm lost network connectivity in 4.0.x
kernels ?  A couple of times this week, vim on an nfs-3 mount hung
and I had to reboot.  Both of those occasions were on an AMD desktop
with the r8169 driver, running 4.0.3.  I thought it might be
specific to that machine.  For the last two or three days I've been
using an intel, and about 10 minutes ago it suffered the same problem
while running 4.0.4.  Using ping from another term showed that it
had no connectivity to the server on my local network.

This is a bit hard to diagnose - nothing in the logs.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Lost network connectivity in 4.0.x

[Ken Moffat]

On Sun, May 24, 2015 at 03:43:52AM +0100, Ken Moffat wrote:
 Anybody else suffering frm lost network connectivity in 4.0.x
 kernels ?  A couple of times this week, vim on an nfs-3 mount hung
 and I had to reboot.  Both of those occasions were on an AMD desktop
 with the r8169 driver, running 4.0.3.  I thought it might be
 specific to that machine.  For the last two or three days I've been
 using an intel, and about 10 minutes ago it suffered the same problem
 while running 4.0.4.  Using ping from another term showed that it
 had no connectivity to the server on my local network.
 
 This is a bit hard to diagnose - nothing in the logs.
 
I forgot to add that this is with the released gcc-5.1 : I keep
forgetting that some people use old compilers ;-)

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: how to have the kernel do udev's job and autoload the right modules ?

[Ken Moffat]

On Wed, May 06, 2015 at 06:09:39PM +0100, linuxcbon linuxcbon wrote:
> On Wed, May 6, 2015 at 5:55 PM, Ken Moffat  wrote:
> > I suggest that you take the time to look at eudev and mdev, and
> > think about how you can use the facilities they offer.
> I was wishing the kernel would offer some minimal support for
> network, sound and full screen video for my hw :(.
> But it seems I need to load modules to achieve this. And to load modules,
>  it needs some kind of "hotplug" called udev or mdev.
> 
Because it is something that _can_ be done in userspace, so it is
done there.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: how to have the kernel do udev's job and autoload the right modules ?

[Ken Moffat]

On Wed, May 06, 2015 at 01:54:27AM +0100, linuxcbon linuxcbon wrote:
> On Tue, May 5, 2015 at 11:26 PM, Ken Moffat  wrote:
> > I don't think you have ever given any context about what you are
> > trying to do.  It looks to me as if there are two alternatives:
> (...)
> I am trying to write a minimal rc.sysinit
> Only the udev part is missing , because the kernel doesn't
> know how to modprobe many modules by itself.
> (Without udev, I can boot up to desktop, but sound , network and
>  full screen video are missing.)
> 
> > 1. You are building for a particular machine.
> > 2. You are building a distro.
> > ĸen
> (...)
> I need it to work for any hardware, (well normal pc), so answer 2.
> I need udev to detect and modprobe which modules are needed.
> 
> linuxcbon

So, your earlier comment that only two different network drivers and
two sound drivers are needed will turn out to be incorrect when you
have access to more hardware.

And when that happens, you will discover that there are all sorts of
things which differ - since you asked on the kernel list, I will
mention KMS for the video, of which we have at least three variants
on x86 hardware.

I suggest that you take the time to look at eudev and mdev, and
think about how you can use the facilities they offer.

Alternatively, get over your dislike of modprobe and write some
scripts - perhaps using lspci as well as reading /sys - to work out
what hardware is present.

If you have not compiled all of the necesary disk drivers into the
kernel, you are likely to find that some (older) machines will not
be able to access their disk(s).  But we all learn best when we try
things out, so I wish you an enjoyable learning experience!

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: how to have the kernel do udev's job and autoload the right modules ?

[Ken Moffat]

On Wed, May 06, 2015 at 06:09:39PM +0100, linuxcbon linuxcbon wrote:
 On Wed, May 6, 2015 at 5:55 PM, Ken Moffat zarniwh...@ntlworld.com wrote:
  I suggest that you take the time to look at eudev and mdev, and
  think about how you can use the facilities they offer.
 I was wishing the kernel would offer some minimal support for
 network, sound and full screen video for my hw :(.
 But it seems I need to load modules to achieve this. And to load modules,
  it needs some kind of hotplug called udev or mdev.
 
Because it is something that _can_ be done in userspace, so it is
done there.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: how to have the kernel do udev's job and autoload the right modules ?

[Ken Moffat]

On Wed, May 06, 2015 at 01:54:27AM +0100, linuxcbon linuxcbon wrote:
 On Tue, May 5, 2015 at 11:26 PM, Ken Moffat zarniwh...@ntlworld.com wrote:
  I don't think you have ever given any context about what you are
  trying to do.  It looks to me as if there are two alternatives:
 (...)
 I am trying to write a minimal rc.sysinit
 Only the udev part is missing , because the kernel doesn't
 know how to modprobe many modules by itself.
 (Without udev, I can boot up to desktop, but sound , network and
  full screen video are missing.)
 
  1. You are building for a particular machine.
  2. You are building a distro.
  ĸen
 (...)
 I need it to work for any hardware, (well normal pc), so answer 2.
 I need udev to detect and modprobe which modules are needed.
 
 linuxcbon

So, your earlier comment that only two different network drivers and
two sound drivers are needed will turn out to be incorrect when you
have access to more hardware.

And when that happens, you will discover that there are all sorts of
things which differ - since you asked on the kernel list, I will
mention KMS for the video, of which we have at least three variants
on x86 hardware.

I suggest that you take the time to look at eudev and mdev, and
think about how you can use the facilities they offer.

Alternatively, get over your dislike of modprobe and write some
scripts - perhaps using lspci as well as reading /sys - to work out
what hardware is present.

If you have not compiled all of the necesary disk drivers into the
kernel, you are likely to find that some (older) machines will not
be able to access their disk(s).  But we all learn best when we try
things out, so I wish you an enjoyable learning experience!

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: how to have the kernel do udev's job and autoload the right modules ?

[Ken Moffat]

On Tue, May 05, 2015 at 06:08:01PM +, linux cbon wrote:
> On Mon, May 4, 2015 at 11:24 PM, Richard Weinberger  wrote:
> > You can build in the needed modules or just use udev...
> 
> Sorry , but I don't want a monolithic or a huge kernel with many modules 
> inside.
> I want a minimal and modular kernel which only loads the needed modules.
> If I understand, there are 2 choices left :
> 1/ the kernel without modules has a minimal builtin support for my
> network (RTL8111/8168B)
> and my sound (RS780 and SBx00) ... but it doesn't seem the case.

I don't think you have ever given any context about what you are
trying to do.  It looks to me as if there are two alternatives:

1. You are building for a particular machine.  Either build
everything into the kernel, or use an initscript to load the modules.
For an x86 machine, the only reason to use modules in this situation
(apart from giving them a compile-test in the kernel) would be to
save memory, e.g. by not loading sound in runlevel 1.  Using modules
seems to offer minimal benefits in that situation.

2. You are building a distro.  For most distros, the need to support
as many users as possible is important.  Limiting the network to
juut 2 modules, and the same with audio, does not seem to make any
sense.  So, if this is a distro, the target is a tiny number of
machines, and you got lucky in only having two different network
drivers and two sound drivers.

If this is a "one build will run on all my own machines" system, you
could identify the particular machine in an initscript (check `uname
-n`) and modprobe the required modules.  Or, you could perhaps build
both these options into a monolithic kernel.  You said you don't
want a huge kernel, but you appear to be saying that only two things
differ.  Personally, I think that using a *specific* .config for each
of my machines is the way to go.  But then, I happily use eudev
(with some of my own initscripts, e.g. to control cpufreq).

>From your comment, I assume you have already removed all the config
options you do not use - if so, you are doing better than I am.  My
point here is that, at least on a machine from the last few years,
you probably have enough RAM that wasting a little of it by building
too much into your kernel is not a significant problem.

...
> I don't add modprobes in my sysinit, because I find it's a dirty
> workaround, it's manual,
> it works only for one kind of hardware and not for another etc.

If you think modprobe is a dirty workaround (really?) but you want
to use a semi-generic kernel without a udev variant, you don't seem
to leave yourself a lot of space to do things on a desktop machine.

What is so dirty about modprobe ?  Make a list of your hardware, per
machine (by this stage I'm fairly sure you want to use one kernel for
both, or all, your machines) and write a simple shell script to work
out which machine it is running on, and load the correct modules.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: how to have the kernel do udev's job and autoload the right modules ?

[Ken Moffat]

On Tue, May 05, 2015 at 06:08:01PM +, linux cbon wrote:
 On Mon, May 4, 2015 at 11:24 PM, Richard Weinberger rich...@nod.at wrote:
  You can build in the needed modules or just use udev...
 
 Sorry , but I don't want a monolithic or a huge kernel with many modules 
 inside.
 I want a minimal and modular kernel which only loads the needed modules.
 If I understand, there are 2 choices left :
 1/ the kernel without modules has a minimal builtin support for my
 network (RTL8111/8168B)
 and my sound (RS780 and SBx00) ... but it doesn't seem the case.

I don't think you have ever given any context about what you are
trying to do.  It looks to me as if there are two alternatives:

1. You are building for a particular machine.  Either build
everything into the kernel, or use an initscript to load the modules.
For an x86 machine, the only reason to use modules in this situation
(apart from giving them a compile-test in the kernel) would be to
save memory, e.g. by not loading sound in runlevel 1.  Using modules
seems to offer minimal benefits in that situation.

2. You are building a distro.  For most distros, the need to support
as many users as possible is important.  Limiting the network to
juut 2 modules, and the same with audio, does not seem to make any
sense.  So, if this is a distro, the target is a tiny number of
machines, and you got lucky in only having two different network
drivers and two sound drivers.

If this is a one build will run on all my own machines system, you
could identify the particular machine in an initscript (check `uname
-n`) and modprobe the required modules.  Or, you could perhaps build
both these options into a monolithic kernel.  You said you don't
want a huge kernel, but you appear to be saying that only two things
differ.  Personally, I think that using a *specific* .config for each
of my machines is the way to go.  But then, I happily use eudev
(with some of my own initscripts, e.g. to control cpufreq).

From your comment, I assume you have already removed all the config
options you do not use - if so, you are doing better than I am.  My
point here is that, at least on a machine from the last few years,
you probably have enough RAM that wasting a little of it by building
too much into your kernel is not a significant problem.

...
 I don't add modprobes in my sysinit, because I find it's a dirty
 workaround, it's manual,
 it works only for one kind of hardware and not for another etc.

If you think modprobe is a dirty workaround (really?) but you want
to use a semi-generic kernel without a udev variant, you don't seem
to leave yourself a lot of space to do things on a desktop machine.

What is so dirty about modprobe ?  Make a list of your hardware, per
machine (by this stage I'm fairly sure you want to use one kernel for
both, or all, your machines) and write a simple shell script to work
out which machine it is running on, and load the correct modules.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: boot loader

[Ken Moffat]

On Tue, Apr 28, 2015 at 08:44:34PM -0300, Thiago Farina wrote:
> On Tue, Apr 28, 2015 at 6:49 PM, Richard Weinberger
>  wrote:
> > On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina  wrote:
> >> Hi,
> >>
> >> Does the kernel include a simple boot loader like FreeBSD does?
> >
> > Why don't you figure yourself?
> >
> I think it doesn't. I just wanted someone to confirm my thought.
> 
Does the FreeBSD kernel really include a boot loader ?  Surely the
loader is what reads the kernel into memory and then hands control
to it.

If you look at FreeBSD as a whole, it has a boot loader for
whichever architecture it was built for.  But linux is only the
kernel - different distros (in this context, android could be
regarded as a distro) and most importantly different
architectures or platforms all do different things - in my
fairly-limited experience I've used grub, lilo, uboot, yaboot -
there are many others.

But please remember that asking general questions not related to
kernel development on this list is generally regarded as off-topic.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: boot loader

[Ken Moffat]

On Tue, Apr 28, 2015 at 08:44:34PM -0300, Thiago Farina wrote:
 On Tue, Apr 28, 2015 at 6:49 PM, Richard Weinberger
 richard.weinber...@gmail.com wrote:
  On Tue, Apr 28, 2015 at 5:12 PM, Thiago Farina tfrans...@gmail.com wrote:
  Hi,
 
  Does the kernel include a simple boot loader like FreeBSD does?
 
  Why don't you figure yourself?
 
 I think it doesn't. I just wanted someone to confirm my thought.
 
Does the FreeBSD kernel really include a boot loader ?  Surely the
loader is what reads the kernel into memory and then hands control
to it.

If you look at FreeBSD as a whole, it has a boot loader for
whichever architecture it was built for.  But linux is only the
kernel - different distros (in this context, android could be
regarded as a distro) and most importantly different
architectures or platforms all do different things - in my
fairly-limited experience I've used grub, lilo, uboot, yaboot -
there are many others.

But please remember that asking general questions not related to
kernel development on this list is generally regarded as off-topic.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Qemu e1000 broken in -rc1 and -rc2 : bisected

[Ken Moffat]

On Mon, Mar 09, 2015 at 11:14:20AM +0800, Chen, Tiejun wrote:
> On 2015/3/7 3:27, Ken Moffat wrote:
> >On Fri, Mar 06, 2015 at 12:02:40AM +0000, Ken Moffat wrote:
> >>  I have a very recent qemu i686 image, using a 3.19.0 kernel and
> >>dhclient, which works fine if the host is running a 3.19.0 kernel,
> >>but breaks when the host runs 4.0.0-rc1 or -rc2.
> >>
> >>  On those, dhclient does not get an address, so I have no network.
> >>There is a message
> >>e1000 :00:03.0 eth0: Reset adaptor
> >>
> >>  Before I start trying to bisect this, has anybody already seen, or
> >>fixed, it ?
> >>
> >  Bisected.
> >b4eef9b36db461ca44832226fbca614db58c0c33 is the first bad commit
> >commit b4eef9b36db461ca44832226fbca614db58c0c33
> >Author: Tiejun Chen 
> >Date:   Mon Dec 22 10:32:57 2014 +0100
> >
> > kvm: x86: vmx: NULL out hwapic_isr_update() in case of
> >!enable_apicv
> >
[...]
> 
> Did you try Linux 4.0-rc3? That includes one relevant fix,
> 
> KVM: SVM: fix interrupt injection (apic->isr_count always 0)
> 
> Thanks
> Tiejun

 I've now tried -rc3, and the problem has gone.  Thanks.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Qemu e1000 broken in -rc1 and -rc2 : bisected

[Ken Moffat]

On Mon, Mar 09, 2015 at 11:14:20AM +0800, Chen, Tiejun wrote:
 On 2015/3/7 3:27, Ken Moffat wrote:
 On Fri, Mar 06, 2015 at 12:02:40AM +, Ken Moffat wrote:
   I have a very recent qemu i686 image, using a 3.19.0 kernel and
 dhclient, which works fine if the host is running a 3.19.0 kernel,
 but breaks when the host runs 4.0.0-rc1 or -rc2.
 
   On those, dhclient does not get an address, so I have no network.
 There is a message
 e1000 :00:03.0 eth0: Reset adaptor
 
   Before I start trying to bisect this, has anybody already seen, or
 fixed, it ?
 
   Bisected.
 b4eef9b36db461ca44832226fbca614db58c0c33 is the first bad commit
 commit b4eef9b36db461ca44832226fbca614db58c0c33
 Author: Tiejun Chen tiejun.c...@intel.com
 Date:   Mon Dec 22 10:32:57 2014 +0100
 
  kvm: x86: vmx: NULL out hwapic_isr_update() in case of
 !enable_apicv
 
[...]
 
 Did you try Linux 4.0-rc3? That includes one relevant fix,
 
 KVM: SVM: fix interrupt injection (apic-isr_count always 0)
 
 Thanks
 Tiejun

 I've now tried -rc3, and the problem has gone.  Thanks.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Qemu e1000 broken in -rc1 and -rc2 : bisected

[Ken Moffat]

On Fri, Mar 06, 2015 at 12:02:40AM +, Ken Moffat wrote:
>  I have a very recent qemu i686 image, using a 3.19.0 kernel and
> dhclient, which works fine if the host is running a 3.19.0 kernel,
> but breaks when the host runs 4.0.0-rc1 or -rc2.
> 
>  On those, dhclient does not get an address, so I have no network.
> There is a message
> e1000 :00:03.0 eth0: Reset adaptor
> 
>  Before I start trying to bisect this, has anybody already seen, or
> fixed, it ?
> 
 Bisected.
b4eef9b36db461ca44832226fbca614db58c0c33 is the first bad commit
commit b4eef9b36db461ca44832226fbca614db58c0c33
Author: Tiejun Chen 
Date:   Mon Dec 22 10:32:57 2014 +0100

kvm: x86: vmx: NULL out hwapic_isr_update() in case of
!enable_apicv

In most cases calling hwapic_isr_update(), we always check if
kvm_apic_vid_enabled() == 1, but actually,
kvm_apic_vid_enabled()
-> kvm_x86_ops->vm_has_apicv()
-> vmx_vm_has_apicv() or '0' in svm case
-> return enable_apicv && irqchip_in_kernel(kvm)

So its a little cost to recall vmx_vm_has_apicv() inside
hwapic_isr_update(), here just NULL out hwapic_isr_update() in
case of !enable_apicv inside hardware_setup() then make all
related stuffs follow this. Note we don't check this under that
condition of irqchip_in_kernel() since we should make sure
definitely any caller don't work  without in-kernel irqchip.

Signed-off-by: Tiejun Chen 
Signed-off-by: Paolo Bonzini 

 I have reverted this from -rc2 (big offsets, 209 and 357 lines) and
everything is working again.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Qemu e1000 broken in -rc1 and -rc2 : bisected

[Ken Moffat]

On Fri, Mar 06, 2015 at 12:02:40AM +, Ken Moffat wrote:
  I have a very recent qemu i686 image, using a 3.19.0 kernel and
 dhclient, which works fine if the host is running a 3.19.0 kernel,
 but breaks when the host runs 4.0.0-rc1 or -rc2.
 
  On those, dhclient does not get an address, so I have no network.
 There is a message
 e1000 :00:03.0 eth0: Reset adaptor
 
  Before I start trying to bisect this, has anybody already seen, or
 fixed, it ?
 
 Bisected.
b4eef9b36db461ca44832226fbca614db58c0c33 is the first bad commit
commit b4eef9b36db461ca44832226fbca614db58c0c33
Author: Tiejun Chen tiejun.c...@intel.com
Date:   Mon Dec 22 10:32:57 2014 +0100

kvm: x86: vmx: NULL out hwapic_isr_update() in case of
!enable_apicv

In most cases calling hwapic_isr_update(), we always check if
kvm_apic_vid_enabled() == 1, but actually,
kvm_apic_vid_enabled()
- kvm_x86_ops-vm_has_apicv()
- vmx_vm_has_apicv() or '0' in svm case
- return enable_apicv  irqchip_in_kernel(kvm)

So its a little cost to recall vmx_vm_has_apicv() inside
hwapic_isr_update(), here just NULL out hwapic_isr_update() in
case of !enable_apicv inside hardware_setup() then make all
related stuffs follow this. Note we don't check this under that
condition of irqchip_in_kernel() since we should make sure
definitely any caller don't work  without in-kernel irqchip.

Signed-off-by: Tiejun Chen tiejun.c...@intel.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com

 I have reverted this from -rc2 (big offsets, 209 and 357 lines) and
everything is working again.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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/

Qemu e1000 broken in -rc1 and -rc2

[Ken Moffat]

 I have a very recent qemu i686 image, using a 3.19.0 kernel and
dhclient, which works fine if the host is running a 3.19.0 kernel,
but breaks when the host runs 4.0.0-rc1 or -rc2.

 On those, dhclient does not get an address, so I have no network.
There is a message
e1000 :00:03.0 eth0: Reset adaptor

 Before I start trying to bisect this, has anybody already seen, or
fixed, it ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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/

Qemu e1000 broken in -rc1 and -rc2

[Ken Moffat]

 I have a very recent qemu i686 image, using a 3.19.0 kernel and
dhclient, which works fine if the host is running a 3.19.0 kernel,
but breaks when the host runs 4.0.0-rc1 or -rc2.

 On those, dhclient does not get an address, so I have no network.
There is a message
e1000 :00:03.0 eth0: Reset adaptor

 Before I start trying to bisect this, has anybody already seen, or
fixed, it ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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] Update version number references in README

[Ken Moffat]

On Sun, Mar 01, 2015 at 10:01:16PM +0800, Yaowei Bai wrote:
> As we have moved to 4.x, it should be reflected in README.
> 

 Not something I can affect, but just a couple of comments on what
looks like a useful, but unadventurous, change :

1. Firing patches at the list, without copying them to a maintainer,
often means that they are ignored.  Perhaps this should be sent to
the trivial maintainer (unless the documentation maintainer thinks
this is within his area - I have not looked to see if anybody admits
to maintaining this).

2. Perhaps you should also mention .xz variants ?  Actually, on a
version of tar from the last few years, tar -xf
linux-4.X.tar.{gz,bz,xz} "just works".  But I'm sure that some people
who deliberately test on antique userspace (and perhaps people who
do not use gnu tar) might take a different view on that.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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] Update version number references in README

[Ken Moffat]

On Sun, Mar 01, 2015 at 10:01:16PM +0800, Yaowei Bai wrote:
 As we have moved to 4.x, it should be reflected in README.
 

 Not something I can affect, but just a couple of comments on what
looks like a useful, but unadventurous, change :

1. Firing patches at the list, without copying them to a maintainer,
often means that they are ignored.  Perhaps this should be sent to
the trivial maintainer (unless the documentation maintainer thinks
this is within his area - I have not looked to see if anybody admits
to maintaining this).

2. Perhaps you should also mention .xz variants ?  Actually, on a
version of tar from the last few years, tar -xf
linux-4.X.tar.{gz,bz,xz} just works.  But I'm sure that some people
who deliberately test on antique userspace (and perhaps people who
do not use gnu tar) might take a different view on that.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: sock puppets (Re: (Song) ** SystemD)

[Ken Moffat]

On Sun, Oct 05, 2014 at 09:15:11PM +, Gregory Smith wrote:
> Just because you disagree with something does not make it a troll.
> Just because someone continued to post to a mailing list which he
> was unrightly banned from (because systemd negativity is a no-no
> for some), does not mean the message is for trolling.
> 
> Trying to suck up or find common ground with the systemd people
> will fail.
> 
> Rambling Proposal pt 1 of 2. Unix-like Fork. "Indelible Linux/Crystalline 
> Linux"
> youtu.be/N18rNxe3Z-o
> 
> Rambling Proposal pt 2 of 2. Unix-like Fork. "Indelible Linux/Crystalline 
> Linux"
> youtu.be/TG1uqwNzlnk
> 
> 
> On 10/5/14, Joel Rees  wrote:
> > On Sun, Oct 5, 2014 at 7:54 PM, Chuck Ebbert 
> > wrote:
> >> On Sun, 5 Oct 2014 10:29:24 +
> >> Gregory Smith  wrote:
> >> [...]
> >
> > Chuck, Al, anyone else paying attention to "Gregory" or "Tom Collins"
> > or whatever he's calling himself -- I'll repeat what I posted to
> > debian-user, but this is quite apparently a sockpuppet, either
> > engaging in recreational trolling, or trying very hard to make it
> > impossible to discuss systemd with any semblance of rationally.
> >

 Not everybody on lkml likes systemd (I certainly don't), but I
think almost everyone will agree with Joel, and many will agree with
Al.

 For those of us trying to follow what is going on _in_the_kernel_,
this list is already noisy enough.  My 'killfile' just gained a new
entry.

ĸen (hoping that somebody will go ahead with 'Boot Init Through
Computer Hardware')
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: sock puppets (Re: (Song) ** SystemD)

[Ken Moffat]

On Sun, Oct 05, 2014 at 09:15:11PM +, Gregory Smith wrote:
 Just because you disagree with something does not make it a troll.
 Just because someone continued to post to a mailing list which he
 was unrightly banned from (because systemd negativity is a no-no
 for some), does not mean the message is for trolling.
 
 Trying to suck up or find common ground with the systemd people
 will fail.
 
 Rambling Proposal pt 1 of 2. Unix-like Fork. Indelible Linux/Crystalline 
 Linux
 youtu.be/N18rNxe3Z-o
 
 Rambling Proposal pt 2 of 2. Unix-like Fork. Indelible Linux/Crystalline 
 Linux
 youtu.be/TG1uqwNzlnk
 
 
 On 10/5/14, Joel Rees joel.r...@gmail.com wrote:
  On Sun, Oct 5, 2014 at 7:54 PM, Chuck Ebbert cebbert.l...@gmail.com
  wrote:
  On Sun, 5 Oct 2014 10:29:24 +
  Gregory Smith gregorysmith19...@gmail.com wrote:
  [...]
 
  Chuck, Al, anyone else paying attention to Gregory or Tom Collins
  or whatever he's calling himself -- I'll repeat what I posted to
  debian-user, but this is quite apparently a sockpuppet, either
  engaging in recreational trolling, or trying very hard to make it
  impossible to discuss systemd with any semblance of rationally.
 

 Not everybody on lkml likes systemd (I certainly don't), but I
think almost everyone will agree with Joel, and many will agree with
Al.

 For those of us trying to follow what is going on _in_the_kernel_,
this list is already noisy enough.  My 'killfile' just gained a new
entry.

ĸen (hoping that somebody will go ahead with 'Boot Init Through
Computer Hardware')
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: CONFIG_UEVENT_HELPER default

[Ken Moffat]

On Tue, Jun 24, 2014 at 11:35:09PM +0100, Ken Moffat wrote:
> On Tue, Jun 24, 2014 at 12:55:26PM -0700, Andy Lutomirski wrote:
> > On 06/24/2014 11:33 AM, Greg KH wrote:
> > > On Tue, Jun 24, 2014 at 11:30:05AM -0700, Michael Marineau wrote:
> > >> On Jun 24, 2014 11:23 AM, "Alan Stern"  wrote:
> > >>>
[ snipping most of this ]
> (i.) I got the option with 'make oldconfig' and, after reading the
> help, made a decision.  But, in the absence of other problems, and
> if the help text is correct, it looks as if a kernel built after
> accepting the default 'Y' here with recent userspace might grind to
> a halt after "successfully" booting?  That sounds slightly better
> than "fails to boot", but only slightly.  Maybe the problem needs
> a lot of modules, or is it something like "it will hang for a minute,
> then boot" ?
> 
> (ii.) I understand that people continue to use ancient userspace,
> and for that the 'Y' option is needed.  Using ancient userspace is
> a worthwhile thing for _somebody_ to try.  But where is the line
> between "you need to enable this" and "enabling this might be a
> really bad idea" ?  Maybe a specific version of udev ?
> 
 Now that I have managed to boot -rc3, with the default 'Y' on a
recent system (linuxfromscratch from May), it appears to work fine.

 So, the text implies that bad things might happen, but so far I have
not seen them.  I'll stop caring.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: rtl_nic firmware error in 3.16

[Ken Moffat]

On Thu, Jun 26, 2014 at 03:17:23AM +0100, Ken Moffat wrote:
> Hi,
> 
>  I'm getting 15 lines of the following in -rc2
> 
> /bin/sh: firmware/rtl_nic/rtl8168e-3.fw.gen.S: No such file or directory
> 
> followed by
> firmware/Makefile:185: recipe for target 
> 'firmware/rtl_nic/rtl8168e-3.fw.gen.S' failed
> make[1]: *** [firmware/rtl_nic/rtl8168e-3.fw.gen.S] Error 1
> 
>  I've now tried bisecting this twice, from v3.15 to v3.16-rc2 but
> each time the only bad version was v3.16-rc2 itself which is clearly
> not true.
> 
>  The relevant part of my .config is probably in here:
> 
> #
> # Generic Driver Options
> #
> CONFIG_UEVENT_HELPER=y
> CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> # CONFIG_STANDALONE is not set
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FW_LOADER=y
> # CONFIG_FIRMWARE_IN_KERNEL is not set
> CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin radeon/RS780_pfp.bin 
> radeon/RS780_me.bin rtl_nic/rtl8168e-3.fw"
> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
> CONFIG_FW_LOADER_USER_HELPER=y
> # CONFIG_DEBUG_DRIVER is not set
> # CONFIG_DEBUG_DEVRES is not set
> # CONFIG_SYS_HYPERVISOR is not set
> # CONFIG_GENERIC_CPU_DEVICES is not set
> CONFIG_GENERIC_CPU_AUTOPROBE=y
> CONFIG_DMA_SHARED_BUFFER=y
> 
> and the external firmware is in /lib/firmware :
> 
> ken@ac4tv ~ $ls -l /lib/firmware/rtl_nic/
> total 4
> -rw-r--r-- 1 root root 2804 Feb 18 18:03 rtl8168e-3.fw
> 
>  So I assume something is erroneously trying to recreate it.
> 
>  For the second run, I tried using 'make clean' on each build, and
> then after a while I changed to 'make mrproper'.  Perhaps I should
> have used 'mrproper' from the start (never needed it before, and it
> does normally slow things down when you approach the guilty commit).
> 
>  I have now pulled the -rc1 tarball and confirmed that the problem
> is present there, but this is doing my head in, so I thought I would
> ask if anyone else is hitting this ?
> 
> ĸen

 Update, just in case anybody cares.

 I still saw it on -rc3, an attempt to build using what was in linus'
tree the last time I pulled it (a bit after rc2) showed it once, and
bisecting between 3.15-rc8 and 3.16-rc1 with 'make mrproper' on each
build again blamed the version I labelled as bad, i.e. -rc1.

 So, I dropped it from my config for -rc3 to see if it would boot
without this.  It does, and shows no sign of wanting the firmware.

 Weird. I'm _fairly_ sure that an older kernel (some time after I
first put this box together) complained that this firmware was
missing (but appeared to still work), which is why I first added it.

 But since -rc3 is happy without this firmware, I don't have a
problem.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: rtl_nic firmware error in 3.16

[Ken Moffat]

On Thu, Jun 26, 2014 at 03:17:23AM +0100, Ken Moffat wrote:
 Hi,
 
  I'm getting 15 lines of the following in -rc2
 
 /bin/sh: firmware/rtl_nic/rtl8168e-3.fw.gen.S: No such file or directory
 
 followed by
 firmware/Makefile:185: recipe for target 
 'firmware/rtl_nic/rtl8168e-3.fw.gen.S' failed
 make[1]: *** [firmware/rtl_nic/rtl8168e-3.fw.gen.S] Error 1
 
  I've now tried bisecting this twice, from v3.15 to v3.16-rc2 but
 each time the only bad version was v3.16-rc2 itself which is clearly
 not true.
 
  The relevant part of my .config is probably in here:
 
 #
 # Generic Driver Options
 #
 CONFIG_UEVENT_HELPER=y
 CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 CONFIG_FW_LOADER=y
 # CONFIG_FIRMWARE_IN_KERNEL is not set
 CONFIG_EXTRA_FIRMWARE=radeon/R600_rlc.bin radeon/RS780_pfp.bin 
 radeon/RS780_me.bin rtl_nic/rtl8168e-3.fw
 CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware
 CONFIG_FW_LOADER_USER_HELPER=y
 # CONFIG_DEBUG_DRIVER is not set
 # CONFIG_DEBUG_DEVRES is not set
 # CONFIG_SYS_HYPERVISOR is not set
 # CONFIG_GENERIC_CPU_DEVICES is not set
 CONFIG_GENERIC_CPU_AUTOPROBE=y
 CONFIG_DMA_SHARED_BUFFER=y
 
 and the external firmware is in /lib/firmware :
 
 ken@ac4tv ~ $ls -l /lib/firmware/rtl_nic/
 total 4
 -rw-r--r-- 1 root root 2804 Feb 18 18:03 rtl8168e-3.fw
 
  So I assume something is erroneously trying to recreate it.
 
  For the second run, I tried using 'make clean' on each build, and
 then after a while I changed to 'make mrproper'.  Perhaps I should
 have used 'mrproper' from the start (never needed it before, and it
 does normally slow things down when you approach the guilty commit).
 
  I have now pulled the -rc1 tarball and confirmed that the problem
 is present there, but this is doing my head in, so I thought I would
 ask if anyone else is hitting this ?
 
 ĸen

 Update, just in case anybody cares.

 I still saw it on -rc3, an attempt to build using what was in linus'
tree the last time I pulled it (a bit after rc2) showed it once, and
bisecting between 3.15-rc8 and 3.16-rc1 with 'make mrproper' on each
build again blamed the version I labelled as bad, i.e. -rc1.

 So, I dropped it from my config for -rc3 to see if it would boot
without this.  It does, and shows no sign of wanting the firmware.

 Weird. I'm _fairly_ sure that an older kernel (some time after I
first put this box together) complained that this firmware was
missing (but appeared to still work), which is why I first added it.

 But since -rc3 is happy without this firmware, I don't have a
problem.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: CONFIG_UEVENT_HELPER default

[Ken Moffat]

On Tue, Jun 24, 2014 at 11:35:09PM +0100, Ken Moffat wrote:
 On Tue, Jun 24, 2014 at 12:55:26PM -0700, Andy Lutomirski wrote:
  On 06/24/2014 11:33 AM, Greg KH wrote:
   On Tue, Jun 24, 2014 at 11:30:05AM -0700, Michael Marineau wrote:
   On Jun 24, 2014 11:23 AM, Alan Stern st...@rowland.harvard.edu wrote:
  
[ snipping most of this ]
 (i.) I got the option with 'make oldconfig' and, after reading the
 help, made a decision.  But, in the absence of other problems, and
 if the help text is correct, it looks as if a kernel built after
 accepting the default 'Y' here with recent userspace might grind to
 a halt after successfully booting?  That sounds slightly better
 than fails to boot, but only slightly.  Maybe the problem needs
 a lot of modules, or is it something like it will hang for a minute,
 then boot ?
 
 (ii.) I understand that people continue to use ancient userspace,
 and for that the 'Y' option is needed.  Using ancient userspace is
 a worthwhile thing for _somebody_ to try.  But where is the line
 between you need to enable this and enabling this might be a
 really bad idea ?  Maybe a specific version of udev ?
 
 Now that I have managed to boot -rc3, with the default 'Y' on a
recent system (linuxfromscratch from May), it appears to work fine.

 So, the text implies that bad things might happen, but so far I have
not seen them.  I'll stop caring.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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/

rtl_nic firmware error in 3.16

[Ken Moffat]

Hi,

 I'm getting 15 lines of the following in -rc2

/bin/sh: firmware/rtl_nic/rtl8168e-3.fw.gen.S: No such file or directory

followed by
firmware/Makefile:185: recipe for target 'firmware/rtl_nic/rtl8168e-3.fw.gen.S' 
failed
make[1]: *** [firmware/rtl_nic/rtl8168e-3.fw.gen.S] Error 1

 I've now tried bisecting this twice, from v3.15 to v3.16-rc2 but
each time the only bad version was v3.16-rc2 itself which is clearly
not true.

 The relevant part of my .config is probably in here:

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin radeon/RS780_pfp.bin 
radeon/RS780_me.bin rtl_nic/rtl8168e-3.fw"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_DMA_SHARED_BUFFER=y

and the external firmware is in /lib/firmware :

ken@ac4tv ~ $ls -l /lib/firmware/rtl_nic/
total 4
-rw-r--r-- 1 root root 2804 Feb 18 18:03 rtl8168e-3.fw

 So I assume something is erroneously trying to recreate it.

 For the second run, I tried using 'make clean' on each build, and
then after a while I changed to 'make mrproper'.  Perhaps I should
have used 'mrproper' from the start (never needed it before, and it
does normally slow things down when you approach the guilty commit).

 I have now pulled the -rc1 tarball and confirmed that the problem
is present there, but this is doing my head in, so I thought I would
ask if anyone else is hitting this ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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/

rtl_nic firmware error in 3.16

[Ken Moffat]

Hi,

 I'm getting 15 lines of the following in -rc2

/bin/sh: firmware/rtl_nic/rtl8168e-3.fw.gen.S: No such file or directory

followed by
firmware/Makefile:185: recipe for target 'firmware/rtl_nic/rtl8168e-3.fw.gen.S' 
failed
make[1]: *** [firmware/rtl_nic/rtl8168e-3.fw.gen.S] Error 1

 I've now tried bisecting this twice, from v3.15 to v3.16-rc2 but
each time the only bad version was v3.16-rc2 itself which is clearly
not true.

 The relevant part of my .config is probably in here:

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER=y
CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=radeon/R600_rlc.bin radeon/RS780_pfp.bin 
radeon/RS780_me.bin rtl_nic/rtl8168e-3.fw
CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_DMA_SHARED_BUFFER=y

and the external firmware is in /lib/firmware :

ken@ac4tv ~ $ls -l /lib/firmware/rtl_nic/
total 4
-rw-r--r-- 1 root root 2804 Feb 18 18:03 rtl8168e-3.fw

 So I assume something is erroneously trying to recreate it.

 For the second run, I tried using 'make clean' on each build, and
then after a while I changed to 'make mrproper'.  Perhaps I should
have used 'mrproper' from the start (never needed it before, and it
does normally slow things down when you approach the guilty commit).

 I have now pulled the -rc1 tarball and confirmed that the problem
is present there, but this is doing my head in, so I thought I would
ask if anyone else is hitting this ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: CONFIG_UEVENT_HELPER default

[Ken Moffat]

On Tue, Jun 24, 2014 at 12:55:26PM -0700, Andy Lutomirski wrote:
> On 06/24/2014 11:33 AM, Greg KH wrote:
> > On Tue, Jun 24, 2014 at 11:30:05AM -0700, Michael Marineau wrote:
> >> On Jun 24, 2014 11:23 AM, "Alan Stern"  wrote:
> >>>
> >>> Michael and Greg:
> >>>
> >>> The help text for CONFIG_UEVENT_HELPER says (among other things):
> >>>
> >>>   This should not be used today, because usual systems create
> >>>   many events at bootup or device discovery in a very short time
> >>>   frame.
> >>>
> >>> If it shouldn't be used, why does it default to 'y'?
> >>>
> >>> Alan Stern
> >>>
> >>
> >> To introduce the option but not change the default behavior. (yet?) I don't
> >> really have an opinion one way or the other, I just defaulted to being
> >> conservative.
> > 
> > Yes, being conservative is good as turning this off with older systems
> > (like the pathological Fedora 3 system that some kernel developers still
> > use for testing), would result in a non-booting box.  So if you know
> > that your system is "new enough", it's safe to turn off, but if you have
> > a doubt, leave it on to be safe.
> 
> As far as I know, there's no real requirement that a defconfig kernel be
> able to boot old userspace.  We want an oldconfig kernel to be able to
> boot old userspace, but changing the default won't affect that.
> 
> For example, a defconfig kernel won't boot opensuse 9.
> 
> --Andy

 I noticed this help message yesterday, and decided that I
almost-certainly did NOT want it (that system is about 6 weeks old,
with then-current releases of everything).  But I was not able to
complete the kernel build because of other problems (possibly
related to gcc-4.9.1) and I have other things to do at the moment.
All of which means that I can not, for the moment, review what will
happen if I let this option get enabled.

 Two things about this default concern me:

(i.) I got the option with 'make oldconfig' and, after reading the
help, made a decision.  But, in the absence of other problems, and
if the help text is correct, it looks as if a kernel built after
accepting the default 'Y' here with recent userspace might grind to
a halt after "successfully" booting?  That sounds slightly better
than "fails to boot", but only slightly.  Maybe the problem needs
a lot of modules, or is it something like "it will hang for a minute,
then boot" ?

(ii.) I understand that people continue to use ancient userspace,
and for that the 'Y' option is needed.  Using ancient userspace is
a worthwhile thing for _somebody_ to try.  But where is the line
between "you need to enable this" and "enabling this might be a
really bad idea" ?  Maybe a specific version of udev ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: CONFIG_UEVENT_HELPER default

[Ken Moffat]

On Tue, Jun 24, 2014 at 12:55:26PM -0700, Andy Lutomirski wrote:
 On 06/24/2014 11:33 AM, Greg KH wrote:
  On Tue, Jun 24, 2014 at 11:30:05AM -0700, Michael Marineau wrote:
  On Jun 24, 2014 11:23 AM, Alan Stern st...@rowland.harvard.edu wrote:
 
  Michael and Greg:
 
  The help text for CONFIG_UEVENT_HELPER says (among other things):
 
This should not be used today, because usual systems create
many events at bootup or device discovery in a very short time
frame.
 
  If it shouldn't be used, why does it default to 'y'?
 
  Alan Stern
 
 
  To introduce the option but not change the default behavior. (yet?) I don't
  really have an opinion one way or the other, I just defaulted to being
  conservative.
  
  Yes, being conservative is good as turning this off with older systems
  (like the pathological Fedora 3 system that some kernel developers still
  use for testing), would result in a non-booting box.  So if you know
  that your system is new enough, it's safe to turn off, but if you have
  a doubt, leave it on to be safe.
 
 As far as I know, there's no real requirement that a defconfig kernel be
 able to boot old userspace.  We want an oldconfig kernel to be able to
 boot old userspace, but changing the default won't affect that.
 
 For example, a defconfig kernel won't boot opensuse 9.
 
 --Andy

 I noticed this help message yesterday, and decided that I
almost-certainly did NOT want it (that system is about 6 weeks old,
with then-current releases of everything).  But I was not able to
complete the kernel build because of other problems (possibly
related to gcc-4.9.1) and I have other things to do at the moment.
All of which means that I can not, for the moment, review what will
happen if I let this option get enabled.

 Two things about this default concern me:

(i.) I got the option with 'make oldconfig' and, after reading the
help, made a decision.  But, in the absence of other problems, and
if the help text is correct, it looks as if a kernel built after
accepting the default 'Y' here with recent userspace might grind to
a halt after successfully booting?  That sounds slightly better
than fails to boot, but only slightly.  Maybe the problem needs
a lot of modules, or is it something like it will hang for a minute,
then boot ?

(ii.) I understand that people continue to use ancient userspace,
and for that the 'Y' option is needed.  Using ancient userspace is
a worthwhile thing for _somebody_ to try.  But where is the line
between you need to enable this and enabling this might be a
really bad idea ?  Maybe a specific version of udev ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: relative objtree change broke tar builds?

[Ken Moffat]

On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
> 
> The idea is that one should be able to compare as much as possible
> between the build of /usr/src/linux- built in
> /usr/src/linux-/build and /usr/src/linux- built in
> /usr/src/linux-/build.

Michal,

 Now that you have sent a pull request to Linus, and therefore
addressed the main problem, may I dare to question your example ?

 I only started building kernels in (approximately) spring 2000, so I
am sure that I am missing a lot of history.  But /usr/src/linux*
smells of "tradition" in the Scots sense of "whit ma faither telt me
that his faither telt him" ("what my father told me that his father
told him" in english).  I am sure that /usr/src/linux might have been
an expectation in the distant past, but it tends to bring along the
assumption that kernels are _built_ by that dangerous guy called
'root'.

 Some of us (me included) often build things as root, but it has
many risks and people ought not to be led to believe it is
necessarily the correct way to do things.  Over the past 14 years I
have built kernels in ~/ as well as in other user-writable
directories and I am puzzled about why the idea of /usr/src/linux*
continues to exist.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: relative objtree change broke tar builds?

[Ken Moffat]

On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
 
 The idea is that one should be able to compare as much as possible
 between the build of /usr/src/linux-version_a built in
 /usr/src/linux-version_a/build and /usr/src/linux-version_b built in
 /usr/src/linux-version_b/build.

Michal,

 Now that you have sent a pull request to Linus, and therefore
addressed the main problem, may I dare to question your example ?

 I only started building kernels in (approximately) spring 2000, so I
am sure that I am missing a lot of history.  But /usr/src/linux*
smells of tradition in the Scots sense of whit ma faither telt me
that his faither telt him (what my father told me that his father
told him in english).  I am sure that /usr/src/linux might have been
an expectation in the distant past, but it tends to bring along the
assumption that kernels are _built_ by that dangerous guy called
'root'.

 Some of us (me included) often build things as root, but it has
many risks and people ought not to be led to believe it is
necessarily the correct way to do things.  Over the past 14 years I
have built kernels in ~/ as well as in other user-writable
directories and I am puzzled about why the idea of /usr/src/linux*
continues to exist.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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 RFC 1/2] MAINTAINERS: Add "R:" designated-reviewers tag

[Ken Moffat]

On Mon, Jun 02, 2014 at 05:12:05PM -0700, Joe Perches wrote:
> 
> "Tested-by:" tags would be more helpful if the test
> cases that were used were somehow sent along with the
> signature.
> 
 To me, that seems either a perverse, or else a bureaucratic,
interpretation of what should go where.

 Tested-by is usually used for a fix of some problem, often a
regression.  A good commit message will explain the problem.  I have
recently offered this tag in two cases - in the first case it did
not boot without the fix, in the second it did not wake up from
suspend.  In each case, only one of my boxes was affected.  Do you
think I should have insisted that some of my lspci -V information
was appended to the commit (they both affected the radeon code) if
my tag was going to be added ?

 This is _often_ not like userspace programs where you can write a
testsuite to exercise the corner cases.  Kernel problems can be
tied up with intricate details of the hardware, or equally they
might happen only for certain usage, and for those it might not be
at all obvious what is "special" about the affected usage.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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 RFC 1/2] MAINTAINERS: Add R: designated-reviewers tag

[Ken Moffat]

On Mon, Jun 02, 2014 at 05:12:05PM -0700, Joe Perches wrote:
 
 Tested-by: tags would be more helpful if the test
 cases that were used were somehow sent along with the
 signature.
 
 To me, that seems either a perverse, or else a bureaucratic,
interpretation of what should go where.

 Tested-by is usually used for a fix of some problem, often a
regression.  A good commit message will explain the problem.  I have
recently offered this tag in two cases - in the first case it did
not boot without the fix, in the second it did not wake up from
suspend.  In each case, only one of my boxes was affected.  Do you
think I should have insisted that some of my lspci -V information
was appended to the commit (they both affected the radeon code) if
my tag was going to be added ?

 This is _often_ not like userspace programs where you can write a
testsuite to exercise the corner cases.  Kernel problems can be
tied up with intricate details of the hardware, or equally they
might happen only for certain usage, and for those it might not be
at all obvious what is special about the affected usage.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Licensing & copyright of kernel .config files (defconfig, *config)

[Ken Moffat]

On Sun, Jun 01, 2014 at 01:43:01AM +, Robin H. Johnson wrote:
> (Please CC me on replies, not subscribed to LKML)
> 
> Hi,
> 
> Somewhat of an odd question, but none of the files in question seem to
> have a copyright header on them...
> 
> For a kernel .config file, either from one of the defconfig or any other
> *config option that automates the answer:
> 1. What license does the file fall under?
> 2. Who are the copyright holders?
> 
> Naively, since the defconfigs are bundled with the kernel, that could
> fall under GPLv2-only implicitly, but lacking any explicit copyright
> headers makes this interesting (arch/*/configs/* contain lots of files,
> no copyright headers on them).
> 

 I am not a lawyer, but surely _many_ of the kernel files do not
contain any explicit copyright information ?

> If I manually write the names of some configuration options to a new
> .config file, at that point I logically am the only author and have
> copyright of it. My editor slaps a default license on it of BSD-2.
> Thereafter I run olddefconfig, and now it's a combined work of the
> kernel's defconfig and my manual settings. If GPL-2 was inherited from
> the kernel tree, this is now a combined BSD-GPL2 work, or is it? The
> kernel config tools did consider my file as input, possibly overrode the
> settings if they didn't work with others, and re-output everything.
> 

 Why does your editor put a default license on anything ?  In some
cases, it is bound to be wrong.  For example, if you were to ever
submit a kernel patch, in the kernel the license would be GPL-2
although, if you created a new file, you could also license that as
BSD-2 if it was not a derivative of existing kernel code.
Similarly, if you ever create a patch for any other project which
does not use a BSD license, then your patch will have uncertain
status.

 If I was being awkward, I would suggest that the config would not
be useful until you had run it through "make oldconfig" or similar,
and that therefore the kernel license of GPL-2 applies.

> If the files are to be marked with a copyright header, who is the holder
> of it that it should be attributed to?
> 

 Iff the work is copyrightable (I do not have an opinion on that),
surely the license only matters if you breach it ? ;-)  If you
distribute a compiled kernel with the source, and all of that source
is GPL-2, then I assume you are in the clear.  For "extras" which
include binaries without source, my understanding is that you would
always be vulnerable to kernel copyright holders.  So, I suspect
that the attribution of a config file is not particularly important.

> Alternatively, is this a case where the work is not copyrightable, and
> the files should have a notice to that effect?
> 
> Background:
> Gentoo has a bunch of "stock" kernel configurations for release
> engineering, our initramfs tool (genkernel), and other endeavors over
> the years. These projects claim BSD, GPL2, LGPL2 on various pieces, and
> I don't think they can all be correct. I'm working on getting them into
> one place, because some of them have been getting stale, but the
> differing licenses raised a red flag to me.
> 

 To the extent that GPL-2 can include LGPL-2 and BSD, I suggest that
you label them all as GPL-2.  That is the licence of the kernel, and
for practical reasons it will not change (this was discussed when
somebody asked about GPL-3 : even if the main copyright holders
wanted to make the change (and many do not), some copyright holders
are no longer contactable).  You might be able to dual-license some
of these distro files, but I have no idea if that would be appropriate.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Licensing copyright of kernel .config files (defconfig, *config)

[Ken Moffat]

On Sun, Jun 01, 2014 at 01:43:01AM +, Robin H. Johnson wrote:
 (Please CC me on replies, not subscribed to LKML)
 
 Hi,
 
 Somewhat of an odd question, but none of the files in question seem to
 have a copyright header on them...
 
 For a kernel .config file, either from one of the defconfig or any other
 *config option that automates the answer:
 1. What license does the file fall under?
 2. Who are the copyright holders?
 
 Naively, since the defconfigs are bundled with the kernel, that could
 fall under GPLv2-only implicitly, but lacking any explicit copyright
 headers makes this interesting (arch/*/configs/* contain lots of files,
 no copyright headers on them).
 

 I am not a lawyer, but surely _many_ of the kernel files do not
contain any explicit copyright information ?

 If I manually write the names of some configuration options to a new
 .config file, at that point I logically am the only author and have
 copyright of it. My editor slaps a default license on it of BSD-2.
 Thereafter I run olddefconfig, and now it's a combined work of the
 kernel's defconfig and my manual settings. If GPL-2 was inherited from
 the kernel tree, this is now a combined BSD-GPL2 work, or is it? The
 kernel config tools did consider my file as input, possibly overrode the
 settings if they didn't work with others, and re-output everything.
 

 Why does your editor put a default license on anything ?  In some
cases, it is bound to be wrong.  For example, if you were to ever
submit a kernel patch, in the kernel the license would be GPL-2
although, if you created a new file, you could also license that as
BSD-2 if it was not a derivative of existing kernel code.
Similarly, if you ever create a patch for any other project which
does not use a BSD license, then your patch will have uncertain
status.

 If I was being awkward, I would suggest that the config would not
be useful until you had run it through make oldconfig or similar,
and that therefore the kernel license of GPL-2 applies.

 If the files are to be marked with a copyright header, who is the holder
 of it that it should be attributed to?
 

 Iff the work is copyrightable (I do not have an opinion on that),
surely the license only matters if you breach it ? ;-)  If you
distribute a compiled kernel with the source, and all of that source
is GPL-2, then I assume you are in the clear.  For extras which
include binaries without source, my understanding is that you would
always be vulnerable to kernel copyright holders.  So, I suspect
that the attribution of a config file is not particularly important.

 Alternatively, is this a case where the work is not copyrightable, and
 the files should have a notice to that effect?
 
 Background:
 Gentoo has a bunch of stock kernel configurations for release
 engineering, our initramfs tool (genkernel), and other endeavors over
 the years. These projects claim BSD, GPL2, LGPL2 on various pieces, and
 I don't think they can all be correct. I'm working on getting them into
 one place, because some of them have been getting stale, but the
 differing licenses raised a red flag to me.
 

 To the extent that GPL-2 can include LGPL-2 and BSD, I suggest that
you label them all as GPL-2.  That is the licence of the kernel, and
for practical reasons it will not change (this was discussed when
somebody asked about GPL-3 : even if the main copyright holders
wanted to make the change (and many do not), some copyright holders
are no longer contactable).  You might be able to dual-license some
of these distro files, but I have no idea if that would be appropriate.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Resume from suspend broken in 3.15. (bisected)

[Ken Moffat]

On Thu, May 29, 2014 at 10:57:20PM +0200, Daniel Vetter wrote:
> On Thu, May 29, 2014 at 10:47 PM, Alex Deucher  wrote:
> > On Thu, May 29, 2014 at 2:03 AM, Dan Carpenter  
> > wrote:
> >> On Wed, May 28, 2014 at 08:26:53PM -0400, Alex Deucher wrote:
> >>> On Wed, May 28, 2014 at 7:49 PM, Ken Moffat  
> >>> wrote:
> >>> > On Wed, May 28, 2014 at 06:25:21PM +0100, Ken Moffat wrote:
> >>> >> Hi Daniel,
> >>> >>
> >>> >
> >>> >  [ correcting details, confirming that reverting this does fix the
> >>> > problem, adding Cc:s ]
> >>> >
> >>> >>  I've only started full testing of 3.15 on one of my machines now
> >>> >> that -rc7 has been released (this one had two issues in the radeon
> >>> >> code, second was fixed in rc7).  Unfortunately, suspend to RAM
> >>> >> (pm-suspend), or rather the wake-up, is broken on this box [ my
> >>> >> other two boxes are fine in rc7 ].
> >>> >>
> >>> >> Bisection identified one of your commits -
> >>> >>
> >>> >> commit 25f397a429dfa43f22c278d0119a60a343aa568f
> >>> >> Author: Daniel Vetter 
> >>> >> Date:   Fri Jul 19 18:57:11 2013 +0200
> >>> >>
> >>> >> drm/crtc-helper: explicit DPMS on after modeset
> >>> >>
> >>> >> Atm the crtc helper implementation of set_config has really
> >>> >> inconsisten semantics: If just an fb update is good enough, dpms 
> >>> >> state
> >>> >> will be left as-is, but if we do a full modeset we force 
> >>> >> everything to
> >>> >> dpms on.
> >>> >>
> >>> >> This change has already been applied to the i915 modeset code in
> >>> >>
> >>> >> ('git show' stops at that point)
> >>> >
> >>> >  update : I've no idea what was going on there, nor for the problem
> >>> > with attempting to revert it.  I've now gone back into git,
> >>> > extracted the full commit to a file with 'git show', and then used
> >>> > git apply -R to revert it from 3.15-rc7.  That version wakes up from
> >>> > suspend to RAM, 3.15-rc7 itself did not.
> >>> >
> >>> >  Maybe I was still in git log when I thought I was on the command
> >>> > line.  Anyway, snipping git's view of my failed attempt to revert
> >>> > it, and adding Dan and Alex who were CC'd on the commit.
> >>> >
> >>>
> >>> Duplicate of:
> >>> https://bugzilla.kernel.org/show_bug.cgi?id=74751
> >>> and also reported here:
> >>> https://lkml.org/lkml/2014/5/2/388
> >>> Unless there is a good reason to keep the commit, I'd say let's just 
> >>> revert it.
> >>>
> >>
> >> Yes.  Let's revert it.
> >
> > The actual bad commit is 177cf92de4aa97ec1435987e91696ed8b5023130, but
> > for some reason git bisect always comes up with
> > 25f397a429dfa43f22c278d0119a60a343aa568f which has been in the tree
> > for almost a year now.  I don't know why.
> 
> Quick patch which is worth a shot before we revert 177cf.
> -Daniel
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index c2edb2d14030..cf5d299cc623 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1534,11 +1534,6 @@ int radeon_resume_kms(struct drm_device *dev, bool 
> resume, bool fbcon)
>  
>   radeon_restore_bios_scratch_regs(rdev);
>  
> - if (fbcon) {
> - radeon_fbdev_set_suspend(rdev, 0);
> - console_unlock();
> - }
> -
>   /* init dig PHYs, disp eng pll */
>   if (rdev->is_atom_bios) {
>   radeon_atom_encoder_init(rdev);
> @@ -1563,6 +1558,12 @@ int radeon_resume_kms(struct drm_device *dev, bool 
> resume, bool fbcon)
>   }
>  
>   drm_kms_helper_poll_enable(dev);
> +
> + if (fbcon) {
> + radeon_fbdev_set_suspend(rdev, 0);
> + console_unlock();
> + }
> +
>   return 0;
>  }
>  
 Thanks, Daniel.

 That works for me (with -rc7) on my A4 Trinity (Radeon HD7480D).  I
also tested it on my other radeon (RS780L - Radeon 3000) and saw no
problems in suspend-resume.  If useful, you can add my tested-by.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Resume from suspend broken in 3.15. (bisected)

[Ken Moffat]

On Thu, May 29, 2014 at 10:57:20PM +0200, Daniel Vetter wrote:
 On Thu, May 29, 2014 at 10:47 PM, Alex Deucher alexdeuc...@gmail.com wrote:
  On Thu, May 29, 2014 at 2:03 AM, Dan Carpenter dan.carpen...@oracle.com 
  wrote:
  On Wed, May 28, 2014 at 08:26:53PM -0400, Alex Deucher wrote:
  On Wed, May 28, 2014 at 7:49 PM, Ken Moffat zarniwh...@ntlworld.com 
  wrote:
   On Wed, May 28, 2014 at 06:25:21PM +0100, Ken Moffat wrote:
   Hi Daniel,
  
  
[ correcting details, confirming that reverting this does fix the
   problem, adding Cc:s ]
  
I've only started full testing of 3.15 on one of my machines now
   that -rc7 has been released (this one had two issues in the radeon
   code, second was fixed in rc7).  Unfortunately, suspend to RAM
   (pm-suspend), or rather the wake-up, is broken on this box [ my
   other two boxes are fine in rc7 ].
  
   Bisection identified one of your commits -
  
   commit 25f397a429dfa43f22c278d0119a60a343aa568f
   Author: Daniel Vetter daniel.vet...@ffwll.ch
   Date:   Fri Jul 19 18:57:11 2013 +0200
  
   drm/crtc-helper: explicit DPMS on after modeset
  
   Atm the crtc helper implementation of set_config has really
   inconsisten semantics: If just an fb update is good enough, dpms 
   state
   will be left as-is, but if we do a full modeset we force 
   everything to
   dpms on.
  
   This change has already been applied to the i915 modeset code in
  
   ('git show' stops at that point)
  
update : I've no idea what was going on there, nor for the problem
   with attempting to revert it.  I've now gone back into git,
   extracted the full commit to a file with 'git show', and then used
   git apply -R to revert it from 3.15-rc7.  That version wakes up from
   suspend to RAM, 3.15-rc7 itself did not.
  
Maybe I was still in git log when I thought I was on the command
   line.  Anyway, snipping git's view of my failed attempt to revert
   it, and adding Dan and Alex who were CC'd on the commit.
  
 
  Duplicate of:
  https://bugzilla.kernel.org/show_bug.cgi?id=74751
  and also reported here:
  https://lkml.org/lkml/2014/5/2/388
  Unless there is a good reason to keep the commit, I'd say let's just 
  revert it.
 
 
  Yes.  Let's revert it.
 
  The actual bad commit is 177cf92de4aa97ec1435987e91696ed8b5023130, but
  for some reason git bisect always comes up with
  25f397a429dfa43f22c278d0119a60a343aa568f which has been in the tree
  for almost a year now.  I don't know why.
 
 Quick patch which is worth a shot before we revert 177cf.
 -Daniel
 
 diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
 b/drivers/gpu/drm/radeon/radeon_device.c
 index c2edb2d14030..cf5d299cc623 100644
 --- a/drivers/gpu/drm/radeon/radeon_device.c
 +++ b/drivers/gpu/drm/radeon/radeon_device.c
 @@ -1534,11 +1534,6 @@ int radeon_resume_kms(struct drm_device *dev, bool 
 resume, bool fbcon)
  
   radeon_restore_bios_scratch_regs(rdev);
  
 - if (fbcon) {
 - radeon_fbdev_set_suspend(rdev, 0);
 - console_unlock();
 - }
 -
   /* init dig PHYs, disp eng pll */
   if (rdev-is_atom_bios) {
   radeon_atom_encoder_init(rdev);
 @@ -1563,6 +1558,12 @@ int radeon_resume_kms(struct drm_device *dev, bool 
 resume, bool fbcon)
   }
  
   drm_kms_helper_poll_enable(dev);
 +
 + if (fbcon) {
 + radeon_fbdev_set_suspend(rdev, 0);
 + console_unlock();
 + }
 +
   return 0;
  }
  
 Thanks, Daniel.

 That works for me (with -rc7) on my A4 Trinity (Radeon HD7480D).  I
also tested it on my other radeon (RS780L - Radeon 3000) and saw no
problems in suspend-resume.  If useful, you can add my tested-by.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Resume from suspend broken in 3.15. (bisected)

[Ken Moffat]

On Wed, May 28, 2014 at 06:25:21PM +0100, Ken Moffat wrote:
> Hi Daniel,
> 

 [ correcting details, confirming that reverting this does fix the
problem, adding Cc:s ]

>  I've only started full testing of 3.15 on one of my machines now
> that -rc7 has been released (this one had two issues in the radeon
> code, second was fixed in rc7).  Unfortunately, suspend to RAM
> (pm-suspend), or rather the wake-up, is broken on this box [ my
> other two boxes are fine in rc7 ].
> 
> Bisection identified one of your commits -
> 
> commit 25f397a429dfa43f22c278d0119a60a343aa568f
> Author: Daniel Vetter 
> Date:   Fri Jul 19 18:57:11 2013 +0200
> 
> drm/crtc-helper: explicit DPMS on after modeset
> 
> Atm the crtc helper implementation of set_config has really
> inconsisten semantics: If just an fb update is good enough, dpms state
> will be left as-is, but if we do a full modeset we force everything to
> dpms on.
> 
> This change has already been applied to the i915 modeset code in
> 
> ('git show' stops at that point)

 update : I've no idea what was going on there, nor for the problem
with attempting to revert it.  I've now gone back into git,
extracted the full commit to a file with 'git show', and then used
git apply -R to revert it from 3.15-rc7.  That version wakes up from
suspend to RAM, 3.15-rc7 itself did not.

 Maybe I was still in git log when I thought I was on the command
line.  Anyway, snipping git's view of my failed attempt to revert
it, and adding Dan and Alex who were CC'd on the commit.

> 
>  The processor is an AMD A4 APU.  The symptoms after this commit are
> that pm-suspend works (I invoke it from my keyboard's sleep key),
> i.e. the power LED on the case goes out and the monitor goes black
> and reports no signal.  When I press a key to resume, the power LED
> comes on but the screen stays black.  Magic-SysRQ does not work and
> I have to use the case switch to reboot.  That results in filesystem
> errors which fsck fixes and warns about (probably, just a sign of
> unclean shutdown).
> 
>  The only thing in the log are a couple of messages from EXT4 at the
> end of putting the box to sleep -
> May 28 16:19:02 bluesbreaker kernel: [   39.440859] EXT4-fs (sda10): 
> re-mounted. Opts: commit=0
> May 28 16:19:02 bluesbreaker kernel: [   39.592318] EXT4-fs (sda13): 
> re-mounted. Opts: commit=0
> May 28 16:20:05 bluesbreaker syslogd 1.5.0: restart.
> 
>  What can I do to help debug this ?
> 
ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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/

Resume from suspend broken in 3.15. (bisected)

[Ken Moffat]

Hi Daniel,

 I've only started full testing of 3.15 on one of my machines now
that -rc7 has been released (this one had two issues in the radeon
code, second was fixed in rc7).  Unfortunately, suspend to RAM
(pm-suspend), or rather the wake-up, is broken on this box [ my
other two boxes are fine in rc7 ].

Bisection identified one of your commits -

commit 25f397a429dfa43f22c278d0119a60a343aa568f
Author: Daniel Vetter 
Date:   Fri Jul 19 18:57:11 2013 +0200

drm/crtc-helper: explicit DPMS on after modeset

Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.

This change has already been applied to the i915 modeset code in

('git show' stops at that point)


 I have attempted to revert this commit from Linus' current tree,
but git considered that there was a conflict, and I did not know how
to address it, so I aborted.  The conflict is :

<<< HEAD

if (connector->dpms != DRM_MODE_DPMS_ON) {
DRM_DEBUG_KMS("connector dpms not on, 
full mode switch\n");
mode_changed = true;
}

===
>>> parent of 25f397a429df... drm/crtc-helper: explicit DPMS on
>>> after modeset
break;
}
}


 The processor is an AMD A4 APU.  The symptoms after this commit are
that pm-suspend works (I invoke it from my keyboard's sleep key),
i.e. the power LED on the case goes out and the monitor goes black
and reports no signal.  When I press a key to resume, the power LED
comes on but the screen stays black.  Magic-SysRQ does not work and
I have to use the case switch to reboot.  That results in filesystem
errors which fsck fixes and warns about (probably, just a sign of
unclean shutdown).

 The only thing in the log are a couple of messages from EXT4 at the
end of putting the box to sleep -
May 28 16:19:02 bluesbreaker kernel: [   39.440859] EXT4-fs (sda10): 
re-mounted. Opts: commit=0
May 28 16:19:02 bluesbreaker kernel: [   39.592318] EXT4-fs (sda13): 
re-mounted. Opts: commit=0
May 28 16:20:05 bluesbreaker syslogd 1.5.0: restart.

 What can I do to help debug this ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Resume from suspend broken in 3.15. (bisected)

[Ken Moffat]

On Wed, May 28, 2014 at 06:25:21PM +0100, Ken Moffat wrote:
 Hi Daniel,
 

 [ correcting details, confirming that reverting this does fix the
problem, adding Cc:s ]

  I've only started full testing of 3.15 on one of my machines now
 that -rc7 has been released (this one had two issues in the radeon
 code, second was fixed in rc7).  Unfortunately, suspend to RAM
 (pm-suspend), or rather the wake-up, is broken on this box [ my
 other two boxes are fine in rc7 ].
 
 Bisection identified one of your commits -
 
 commit 25f397a429dfa43f22c278d0119a60a343aa568f
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Fri Jul 19 18:57:11 2013 +0200
 
 drm/crtc-helper: explicit DPMS on after modeset
 
 Atm the crtc helper implementation of set_config has really
 inconsisten semantics: If just an fb update is good enough, dpms state
 will be left as-is, but if we do a full modeset we force everything to
 dpms on.
 
 This change has already been applied to the i915 modeset code in
 
 ('git show' stops at that point)

 update : I've no idea what was going on there, nor for the problem
with attempting to revert it.  I've now gone back into git,
extracted the full commit to a file with 'git show', and then used
git apply -R to revert it from 3.15-rc7.  That version wakes up from
suspend to RAM, 3.15-rc7 itself did not.

 Maybe I was still in git log when I thought I was on the command
line.  Anyway, snipping git's view of my failed attempt to revert
it, and adding Dan and Alex who were CC'd on the commit.

 
  The processor is an AMD A4 APU.  The symptoms after this commit are
 that pm-suspend works (I invoke it from my keyboard's sleep key),
 i.e. the power LED on the case goes out and the monitor goes black
 and reports no signal.  When I press a key to resume, the power LED
 comes on but the screen stays black.  Magic-SysRQ does not work and
 I have to use the case switch to reboot.  That results in filesystem
 errors which fsck fixes and warns about (probably, just a sign of
 unclean shutdown).
 
  The only thing in the log are a couple of messages from EXT4 at the
 end of putting the box to sleep -
 May 28 16:19:02 bluesbreaker kernel: [   39.440859] EXT4-fs (sda10): 
 re-mounted. Opts: commit=0
 May 28 16:19:02 bluesbreaker kernel: [   39.592318] EXT4-fs (sda13): 
 re-mounted. Opts: commit=0
 May 28 16:20:05 bluesbreaker syslogd 1.5.0: restart.
 
  What can I do to help debug this ?
 
ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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/

Resume from suspend broken in 3.15. (bisected)

[Ken Moffat]

Hi Daniel,

 I've only started full testing of 3.15 on one of my machines now
that -rc7 has been released (this one had two issues in the radeon
code, second was fixed in rc7).  Unfortunately, suspend to RAM
(pm-suspend), or rather the wake-up, is broken on this box [ my
other two boxes are fine in rc7 ].

Bisection identified one of your commits -

commit 25f397a429dfa43f22c278d0119a60a343aa568f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Fri Jul 19 18:57:11 2013 +0200

drm/crtc-helper: explicit DPMS on after modeset

Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.

This change has already been applied to the i915 modeset code in

('git show' stops at that point)


 I have attempted to revert this commit from Linus' current tree,
but git considered that there was a conflict, and I did not know how
to address it, so I aborted.  The conflict is :

 HEAD

if (connector-dpms != DRM_MODE_DPMS_ON) {
DRM_DEBUG_KMS(connector dpms not on, 
full mode switch\n);
mode_changed = true;
}

===
 parent of 25f397a429df... drm/crtc-helper: explicit DPMS on
 after modeset
break;
}
}


 The processor is an AMD A4 APU.  The symptoms after this commit are
that pm-suspend works (I invoke it from my keyboard's sleep key),
i.e. the power LED on the case goes out and the monitor goes black
and reports no signal.  When I press a key to resume, the power LED
comes on but the screen stays black.  Magic-SysRQ does not work and
I have to use the case switch to reboot.  That results in filesystem
errors which fsck fixes and warns about (probably, just a sign of
unclean shutdown).

 The only thing in the log are a couple of messages from EXT4 at the
end of putting the box to sleep -
May 28 16:19:02 bluesbreaker kernel: [   39.440859] EXT4-fs (sda10): 
re-mounted. Opts: commit=0
May 28 16:19:02 bluesbreaker kernel: [   39.592318] EXT4-fs (sda13): 
re-mounted. Opts: commit=0
May 28 16:20:05 bluesbreaker syslogd 1.5.0: restart.

 What can I do to help debug this ?

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
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: Bug? Older 32 bit program (CivCTP) no longer works under 64 bit kernel

[Ken Moffat]

On Thu, May 15, 2014 at 08:24:05PM -0500, David Hagood wrote:
> I have an old native Linux 32 bit copy of Civilization: Call to Power. It
> used to work under a 64 bit environment back in the 3.0.x days. However,
> under recent versions (>3.5) it no longer runs - it complains that it cannot
> find certain files in the directory. The exact same code will run just fine
> under a 32 bit version of 3.11. I have a Pentium II as well as the Core 2
> Duo, both running Ubuntu 14.04, same version of the kernel other than one is
> 32 bit and one is 64 bit. I've copied the files over from the 32 bit
> machine, where it runs, to the 64 bit machine, where it does not. I've even
> gone so far as to copy all the system 32 bit libraries into the CivCTP
> directory, and forced the program to use them (including using the
> ld-linux.so loader from that directory) - so in theory it's all the same
> user space libraries running - the only difference that I can see is that
> one kernel is 64 bit and one is 32 bit.
> 
> Running strace on the program shows that the directories being searched for
> game assets are corrupted:
> 
> 16218 stat64("/home/wowbaggr/CivCTP/ctdata/englisish/uidata/keymap.txt",
> 
> 
> Note the "englisish" rather than "english".
> 
> I'm looking for any suggestions on where to look for what might cause such
> an issue - what can I do to start tracking this down.

 I've no ideas about what part of the kernel is causing this, so
I'll just offer you some thoughts on how to track it down.  At a
guess, you will have to run 'git bisect' to nail which change broke
this (or alternatively which change exposed a latent problem).

 Bisection is fairly well covered on google, for example it finds
http://landley.net/writing/git-bisect-howto.html

 The corrupt filename looks (to me, with no experience) like
something which might be in the filesystem area.  It probably isn't,
but I don't recall anything at all like this, so I'd better ask - are
you using an uncommon filesystem for this data ?  This looks like
such a grievous fault that I would expect someone to have noticed it
between 3.5.0 and now.

 And, have you tried any recent kernels (e.g. 3.14.4) to confirm
that the problem still exists ?  If it turns out that somebody
already fixed it, that would save you a lot of effort.

 You will need a network connection to clone linus' tree, and some
space for it.  And git, of course.  To bisect, you should build in
the git tree, AND set CONFIG_LOCALVERSION_AUTO - in
 General setup
  [ ] Automatically append version information to the version

so that the kernel version, and the version in /lib/modules, will
add -X-g information to each non-release install - that
is useful when you are bisecting, so that each set of modules is
kept separate.  See e.g.
http://yarchive.net/comp/linux/CONFIG_LOCALVERSION_AUTO.html

 It might speed this up if you can minimise the kernel config
(distros tend to build the whole kitchen sink as modules) - the
fewer unnecessary things you build, the less time it takes.

 Does it work on 3.4.0 ?  I know 3.4 is supported, and therefore
there are continuing releases with backported fixes, but for
bisection it is easiest to start testing with .0 releases.  If it
doesn't work there (I'm unclear if 3.5 was the earliest post-3.0
kernel that you tried), find which was the last .0 kernel where it
worked.  You can then label that version as "good", e.g.
 git bisect good v3.4 [ or whichever version - without the .0 ].

 Once you are certain which .0 version was the last which worked,
the next can be marked as bad, e.g. v3.5 - and then you bisect.

 Do not be surprised if the kernel identifies itself as an earlier
version than the last good one - see Linus's post referenced at
yarchive.net above.  And good luck, bisection is usually tedious.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
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: Bug? Older 32 bit program (CivCTP) no longer works under 64 bit kernel

[Ken Moffat]

On Thu, May 15, 2014 at 08:24:05PM -0500, David Hagood wrote:
 I have an old native Linux 32 bit copy of Civilization: Call to Power. It
 used to work under a 64 bit environment back in the 3.0.x days. However,
 under recent versions (3.5) it no longer runs - it complains that it cannot
 find certain files in the directory. The exact same code will run just fine
 under a 32 bit version of 3.11. I have a Pentium II as well as the Core 2
 Duo, both running Ubuntu 14.04, same version of the kernel other than one is
 32 bit and one is 64 bit. I've copied the files over from the 32 bit
 machine, where it runs, to the 64 bit machine, where it does not. I've even
 gone so far as to copy all the system 32 bit libraries into the CivCTP
 directory, and forced the program to use them (including using the
 ld-linux.so loader from that directory) - so in theory it's all the same
 user space libraries running - the only difference that I can see is that
 one kernel is 64 bit and one is 32 bit.
 
 Running strace on the program shows that the directories being searched for
 game assets are corrupted:
 
 16218 stat64(/home/wowbaggr/CivCTP/ctdata/englisish/uidata/keymap.txt,
 unfinished ...
 
 Note the englisish rather than english.
 
 I'm looking for any suggestions on where to look for what might cause such
 an issue - what can I do to start tracking this down.

 I've no ideas about what part of the kernel is causing this, so
I'll just offer you some thoughts on how to track it down.  At a
guess, you will have to run 'git bisect' to nail which change broke
this (or alternatively which change exposed a latent problem).

 Bisection is fairly well covered on google, for example it finds
http://landley.net/writing/git-bisect-howto.html

 The corrupt filename looks (to me, with no experience) like
something which might be in the filesystem area.  It probably isn't,
but I don't recall anything at all like this, so I'd better ask - are
you using an uncommon filesystem for this data ?  This looks like
such a grievous fault that I would expect someone to have noticed it
between 3.5.0 and now.

 And, have you tried any recent kernels (e.g. 3.14.4) to confirm
that the problem still exists ?  If it turns out that somebody
already fixed it, that would save you a lot of effort.

 You will need a network connection to clone linus' tree, and some
space for it.  And git, of course.  To bisect, you should build in
the git tree, AND set CONFIG_LOCALVERSION_AUTO - in
 General setup
  [ ] Automatically append version information to the version

so that the kernel version, and the version in /lib/modules, will
add -X-g information to each non-release install - that
is useful when you are bisecting, so that each set of modules is
kept separate.  See e.g.
http://yarchive.net/comp/linux/CONFIG_LOCALVERSION_AUTO.html

 It might speed this up if you can minimise the kernel config
(distros tend to build the whole kitchen sink as modules) - the
fewer unnecessary things you build, the less time it takes.

 Does it work on 3.4.0 ?  I know 3.4 is supported, and therefore
there are continuing releases with backported fixes, but for
bisection it is easiest to start testing with .0 releases.  If it
doesn't work there (I'm unclear if 3.5 was the earliest post-3.0
kernel that you tried), find which was the last .0 kernel where it
worked.  You can then label that version as good, e.g.
 git bisect good v3.4 [ or whichever version - without the .0 ].

 Once you are certain which .0 version was the last which worked,
the next can be marked as bad, e.g. v3.5 - and then you bisect.

 Do not be surprised if the kernel identifies itself as an earlier
version than the last good one - see Linus's post referenced at
yarchive.net above.  And good luck, bisection is usually tedious.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
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: More breakage on HD7480D [ Aruba ]

[Ken Moffat]

On Tue, May 13, 2014 at 01:22:57PM +0200, Christian König wrote:
> Please try the attached patch it should fix your problem.
> 
> Thanks allot for this bug report, that was just a stupid typo in the
> original patch which would probably went unnoticed for years otherwise.
> 
> Christian.
> 

 Thanks, works like a charm.  If it adds any utility, feel free to
add

Tested-by: Ken Moffat 

ĸen

> Am 12.05.2014 18:32, schrieb Ken Moffat:
> >On Mon, May 12, 2014 at 09:32:54AM +0200, Christian König wrote:
> >>Hi Ken,
> >>
> >>*sigh* did I already mentioned that I hate PLLs? As soon as you fix
> >>something another use case immediately starts to break.
> >>
> >>Please provide dmesg output created with drm.debug=0xe with and without the
> >>patch breaking it.
> >>
> >>Thanks in advance,
> >>Christian.
> >>
> >  The reverted version is from linus's tree after -rc5 with the patch
> >reverted, I assume the version -00010-gc9a25d0fc393 will NOT match
> >any public tree because I used git revert in a local branch.  That
> >one works fine.
> >
> >  The bad version is from a random kernel which showed the problem
> >while I was bisecting, in this case rc2-00086.  I first tried
> >booting vanilla rc5, but for some reason my blind attempt to login
> >and run 'dmesg >dmesg.bad' failed.
> >
> >  Thanks.  Sorry you are having to deal with PLLs.
> >
> >ĸen
> 

> >From 8b5c70b48d73b533f0003639cdb68bcffe7c1293 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Christian=20K=C3=B6nig?= 
> Date: Tue, 13 May 2014 12:50:54 +0200
> Subject: [PATCH] drm/radeon: fix typo in finding PLL params
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Otherwise the limit is raised to high.
> 
> Signed-off-by: Christian K??nig 
> ---
>  drivers/gpu/drm/radeon/radeon_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 408b6ac..f00dbbf 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -999,7 +999,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>  
>   /* avoid high jitter with small fractional dividers */
>   if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV && (fb_div % 10)) {
> - fb_div_min = max(fb_div_min, (9 - (fb_div % 10)) * 20 + 60);
> + fb_div_min = max(fb_div_min, (9 - (fb_div % 10)) * 20 + 50);
>   if (fb_div < fb_div_min) {
>   unsigned tmp = DIV_ROUND_UP(fb_div_min, fb_div);
>   fb_div *= tmp;
> -- 
> 1.9.1
> 


-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
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: More breakage on HD7480D [ Aruba ]

[Ken Moffat]

On Tue, May 13, 2014 at 01:22:57PM +0200, Christian König wrote:
 Please try the attached patch it should fix your problem.
 
 Thanks allot for this bug report, that was just a stupid typo in the
 original patch which would probably went unnoticed for years otherwise.
 
 Christian.
 

 Thanks, works like a charm.  If it adds any utility, feel free to
add

Tested-by: Ken Moffat zarniwh...@ntlworld.com

ĸen

 Am 12.05.2014 18:32, schrieb Ken Moffat:
 On Mon, May 12, 2014 at 09:32:54AM +0200, Christian König wrote:
 Hi Ken,
 
 *sigh* did I already mentioned that I hate PLLs? As soon as you fix
 something another use case immediately starts to break.
 
 Please provide dmesg output created with drm.debug=0xe with and without the
 patch breaking it.
 
 Thanks in advance,
 Christian.
 
   The reverted version is from linus's tree after -rc5 with the patch
 reverted, I assume the version -00010-gc9a25d0fc393 will NOT match
 any public tree because I used git revert in a local branch.  That
 one works fine.
 
   The bad version is from a random kernel which showed the problem
 while I was bisecting, in this case rc2-00086.  I first tried
 booting vanilla rc5, but for some reason my blind attempt to login
 and run 'dmesg dmesg.bad' failed.
 
   Thanks.  Sorry you are having to deal with PLLs.
 
 ĸen
 

 From 8b5c70b48d73b533f0003639cdb68bcffe7c1293 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?Christian=20K=C3=B6nig?= christian.koe...@amd.com
 Date: Tue, 13 May 2014 12:50:54 +0200
 Subject: [PATCH] drm/radeon: fix typo in finding PLL params
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
 
 Otherwise the limit is raised to high.
 
 Signed-off-by: Christian K??nig christian.koe...@amd.com
 ---
  drivers/gpu/drm/radeon/radeon_display.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
 b/drivers/gpu/drm/radeon/radeon_display.c
 index 408b6ac..f00dbbf 100644
 --- a/drivers/gpu/drm/radeon/radeon_display.c
 +++ b/drivers/gpu/drm/radeon/radeon_display.c
 @@ -999,7 +999,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
  
   /* avoid high jitter with small fractional dividers */
   if (pll-flags  RADEON_PLL_USE_FRAC_FB_DIV  (fb_div % 10)) {
 - fb_div_min = max(fb_div_min, (9 - (fb_div % 10)) * 20 + 60);
 + fb_div_min = max(fb_div_min, (9 - (fb_div % 10)) * 20 + 50);
   if (fb_div  fb_div_min) {
   unsigned tmp = DIV_ROUND_UP(fb_div_min, fb_div);
   fb_div *= tmp;
 -- 
 1.9.1
 


-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
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: More breakage on HD7480D [ Aruba ]

[Ken Moffat]

On Mon, May 12, 2014 at 01:34:06AM +0100, Ken Moffat wrote:

 /me swears at myself for failing to copy to lkml.

> Hi Christian, Alex -
> 
>  my A4 Trinity (Radeon HD7480D) was working fine by -rc3.  But now
> that I've tested it in -rc5 it is again broken (the screen goes
> blank when KMS starts).  Bisection blames:
> 
> 3b333c55485fef0089ae7398906599d000df195e is the first bad commit
> commit 3b333c55485fef0089ae7398906599d000df195e
> Author: Christian König 
> Date:   Thu Apr 24 18:39:59 2014 +0200
> 
> drm/radeon: avoid high jitter with small frac divs
> 
> Signed-off-by: Christian König 
> 
>  Reverting that from current HEAD [
> 
> commit 7e338c9991ecee9c2ac7a4cee2c2e11ecb563d02
> Merge: 9cf22e80df77 aa07c713ecfc
> Author: Linus Torvalds 
> Date:   Sun May 11 18:06:13 2014 +0900
> 
> Merge branch 'for-3.15' of git://linux-nfs.org/~bfields/linux
> 
> Pull nfsd fixes from Bruce Fields.
> 
> ]
> makes it again boot.
> 
>  Note to Alex - 3.15 has been an "interesting" cycle - you fixed my
> earlier problem, despite my non-response, and thanks again for that.
> After that, my other radeon broke after -rc2 (I retested it after
> rc4 and found that although rc4 was broken, HEAD was fixed, so
> thanks also for that.  Then I retested this one for -rc5.  It seems
> that my boxes always break when I don't have time to test new
> releases :-(
> 
> ĸen
> -- 
> das eine Mal als Tragödie, dieses Mal als Farce

-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
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/