Linux 4.10-rc4 compile error

[Harald Arnesen]

I get the following compile error, which reverting commit
ff828729be446b86957f7c294068758231cd2183 fixes (and the resulting kernel
boots fine).

$ make
...
  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND  objtool
  CHK include/generated/compile.h
  CHK kernel/kheaders_data.tar.xz
  CC  drivers/iommu/intel/dmar.o
drivers/iommu/intel/dmar.c: In function 'vf_inherit_msi_domain':
drivers/iommu/intel/dmar.c:338:59: error: 'struct pci_dev' has no member
named 'physfn'; did you mean 'is_physfn'?
  338 |  dev_set_msi_domain(>dev,
dev_get_msi_domain(>physfn->dev));
  |   ^~
  |   is_physfn
make[3]: *** [scripts/Makefile.build:283: drivers/iommu/intel/dmar.o]
Error 1
make[2]: *** [scripts/Makefile.build:500: drivers/iommu/intel] Error 2
make[1]: *** [scripts/Makefile.build:500: drivers/iommu] Error 2
make: *** [Makefile:1799: drivers] Error 2

-- 
Hilsen Harald

Re: 5.9-rc7: BUG: kernel NULL pointer reference

[Harald Arnesen]

Linus Torvalds [28.09.2020 18:22]:

> On Mon, Sep 28, 2020 at 7:07 AM Harald Arnesen  wrote:
>>
>> I will try bisecting if no-one has a simple explanation.
> 
> There's a simple explanation, no need to bisect.
> 
> I'll push out the fix asap,

Everything is OK now.
Thanks!
-- 
Hilsen Harald

5.9-rc7: BUG: kernel NULL pointer reference

[Harald Arnesen]

I just tried 5.9-rc7, and got a blank screen wit just an unresponsive
mouse pointer and non-working keyboard when starting lightdm.

I could ssh to the machine, and saved the dmesg output. Attached.

5.9-rc6 works as it should.

I will try bisecting if no-one has a simple explanation.
-- 
Hilsen Harald

[0.00] microcode: microcode updated early to revision 0x2f, date = 
2019-02-17
[0.00] Linux version 5.9.0-rc7 (harald@catnip) (gcc (GCC) 10.2.0, GNU 
ld (GNU Binutils) 2.34) #9 SMP PREEMPT Mon Sep 28 12:31:22 CEST 2020
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-rc7 
root=UUID=f8a85ed1-6967-40ca-8731-44cf3a6b8ed6 ro loglevel=4 slub_debug=P 
page_poison=1 net.ifnames=0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x401f] reserved
[0.00] BIOS-e820: [mem 0x4020-0xd399] usable
[0.00] BIOS-e820: [mem 0xd39a-0xdaa9efff] reserved
[0.00] BIOS-e820: [mem 0xdaa9f000-0xdab9efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdab9f000-0xdabfefff] ACPI data
[0.00] BIOS-e820: [mem 0xdabff000-0xdf9f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffd2-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00041e5f] usable
[0.00] BIOS-e820: [mem 0x00041e60-0x00041fff] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.6 present.
[0.00] DMI: LENOVO 42433ZG/42433ZG, BIOS 8AET69WW (1.49 ) 06/14/2018
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 2392.296 MHz processor
[0.000587] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.000588] e820: remove [mem 0x000a-0x000f] usable
[0.000595] last_pfn = 0x41e600 max_arch_pfn = 0x4
[0.000598] MTRR default type: uncachable
[0.000599] MTRR fixed ranges enabled:
[0.000600]   0-9 write-back
[0.000601]   A-B uncachable
[0.000602]   C-F write-protect
[0.000602] MTRR variable ranges enabled:
[0.000604]   0 base 0FFC0 mask FFFC0 write-protect
[0.000605]   1 base 0 mask F8000 write-back
[0.000605]   2 base 08000 mask FC000 write-back
[0.000606]   3 base 0C000 mask FE000 write-back
[0.000607]   4 base 0DC00 mask FFC00 uncachable
[0.000608]   5 base 0DB00 mask FFF00 uncachable
[0.000608]   6 base 0DAC0 mask FFFC0 uncachable
[0.000609]   7 base 1 mask F write-back
[0.000610]   8 base 2 mask E write-back
[0.000611]   9 base 4 mask FE000 write-back
[0.001420] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.001545] last_pfn = 0xd39a0 max_arch_pfn = 0x4
[0.001553] reserving inaccessible SNB gfx pages
[0.002272] RAMDISK: [mem 0x369fb000-0x374f4fff]
[0.002280] ACPI: Early table checksum verification disabled
[0.002284] ACPI: RSDP 0x000F00E0 24 (v02 LENOVO)
[0.002288] ACPI: XSDT 0xDABFE120 AC (v01 LENOVO TP-8A
1490 PTEC 0002)
[0.002294] ACPI: FACP 0xDABE8000 F4 (v04 LENOVO TP-8A
1490 PTL  0002)
[0.002298] ACPI: DSDT 0xDABEB000 00E7FE (v01 LENOVO TP-8A
1490 INTL 20061109)
[0.002301] ACPI: FACS 0xDAB2D000 40
[0.002304] ACPI: FACS 0xDAB2D000 40
[

Re: [git pull] drm fixes for 5.9-rc4

[Harald Arnesen]

Linus Torvalds [08.09.2020 20:19]:

> On Fri, Sep 4, 2020 at 2:51 PM Harald Arnesen  wrote:
>>
>> Still doesn't work without the three reverts
>> (763fedd6a216, 9e0f9464e2ab, 7ac2d2536dfa)...
> 
> So this didn't make rc4, but it's in my tree now.
> 
> Harald, I'm assuming things work for you again now with the current
> git tree, but it is always good to double-check in case something else
> interacted with the reverts...

I can confirm that everything works as expected now.
Thanks to all!
-- 
Hilsen Harald

Re: [git pull] drm fixes for 5.9-rc4

[Harald Arnesen]

Linus Torvalds [04.09.2020 21:02]:

> On Thu, Sep 3, 2020 at 8:53 PM Dave Airlie  wrote:
>>
>> Not much going on this week, nouveau has a display hw bug workaround,
>> amdgpu has some PM fixes and CIK regression fixes, one single radeon
>> PLL fix, and a couple of i915 display fixes.
> 
> Any movement on the i915 relocation issue? I've only seen the one
> report for the 64-bit case, but clearly there was more going on than
> just the missing page table flush on 32-bit..

Still doesn't work without the three reverts
(763fedd6a216, 9e0f9464e2ab, 7ac2d2536dfa)...
-- 
Hilsen Harald

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

[Harald Arnesen]

Still (rc3) doesn't work without the three reverts.

I'm not sure how to proceed, I cannot capture any oops, and see nothing
obvious in any logs.
-- 
Hilsen Harald

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

[Harald Arnesen]

Dave Airlie [26.08.2020 22:47]:

> On Thu, 27 Aug 2020 at 06:44, Harald Arnesen  wrote:
>>
>> Linus Torvalds [26.08.2020 20:04]:
>>
>> > On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen  wrote:
>> >> Somehow related to lightdm or xfce4? However, it is a regression, since
>> >> kernel 5.8 works.
>> > Yeah, apparently there's something else wrong with the relocation changes 
>> > too.
>> >
>> > That said, does that patch at
>> >
>> >   https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
>> >
>> > change things at all? If there are two independent bugs, maybe
>> > applying that patch might at least give you an oops that gets saved in
>> > the logs?
>> >
>> > (it might be worth waiting a bit after the machine locks up in case
>> > the machine is alive enough so sync logs after a bit.. If ssh works,
>> > that's obviously better yet)
>>
>> No, doesn't help. And I was wrong, ssh does not work at all when the
>> display locks up.
> 
> Did you say what hw you had? is it the same hw as Pavel or different?
> 
> Dave.
> 

It's a Thinkpad T520.
Output from 'lspci' attached.

-- 
Hilsen Harald
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family 
DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series 
Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network 
Connection (Lewisville) (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family 
USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family 
High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI 
Express Root Port 1 (rev b4)
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI 
Express Root Port 2 (rev b4)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI 
Express Root Port 4 (rev b4)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI 
Express Root Port 5 (rev b4)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family 
USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset LPC Controller (rev 
04)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 
6 port Mobile SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus 
Controller (rev 04)
03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
0d:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 08)
0d:00.3 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller 
(rev 04)

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

[Harald Arnesen]

Linus Torvalds [26.08.2020 20:04]:

> On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen  wrote:
>> Somehow related to lightdm or xfce4? However, it is a regression, since
>> kernel 5.8 works.
> Yeah, apparently there's something else wrong with the relocation changes too.
> 
> That said, does that patch at
> 
>   https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
> 
> change things at all? If there are two independent bugs, maybe
> applying that patch might at least give you an oops that gets saved in
> the logs?
> 
> (it might be worth waiting a bit after the machine locks up in case
> the machine is alive enough so sync logs after a bit.. If ssh works,
> that's obviously better yet)

No, doesn't help. And I was wrong, ssh does not work at all when the
display locks up.
-- 
Hilsen Harald

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

[Harald Arnesen]

Harald Arnesen [26.08.2020 10:36]:

> I was wrong about ssh working. The whole machine locks up when X starts.
> 
> A strange thing, sometimes I can log in from lightdm before it locks up,
> sometimes I cannot even use the login screen. Timing related?
> 
> If I don't start X, console login seems to work fine, and I see nothing
> obvious in the logs or kernel messages.
> 
> I will try to start just a window manager with startx instead of going
> through lightdm.

Disabled lightdm, started DE or WM from .xinitrc:

xfce4-session: Machine locks up
enlightenment: Machine works

Somehow related to lightdm or xfce4? However, it is a regression, since
kernel 5.8 works.
-- 
Hilsen Harald

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

[Harald Arnesen]

Linus Torvalds [25.08.2020 20:19]:

> On Tue, Aug 25, 2020 at 9:32 AM Harald Arnesen  wrote:
>>
>> > For posterity, I'm told the fix is [1].
>> >
>> > [1] 
>> > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
>>
>> Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
>> freeezes. I can still ssh into the machine
>>
>> The three reverts (763fedd6a216, 7ac2d2536dfa and 9e0f9464e2ab) fixes
>> the bug for me.
> 
> Do you get any oops or other indication of what ends up going wrong?
> Since ssh works that should be fairly easy to see.
I was wrong about ssh working. The whole machine locks up when X starts.

A strange thing, sometimes I can log in from lightdm before it locks up,
sometimes I cannot even use the login screen. Timing related?

If I don't start X, console login seems to work fine, and I see nothing
obvious in the logs or kernel messages.

I will try to start just a window manager with startx instead of going
through lightdm.
-- 
Hilsen Harald

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

[Harald Arnesen]

Linus Torvalds [25.08.2020 20:19]:

>> Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
>> freeezes. I can still ssh into the machine
>>
>> The three reverts (763fedd6a216, 7ac2d2536dfa and 9e0f9464e2ab) fixes
>> the bug for me.
> Do you get any oops or other indication of what ends up going wrong?
> Since ssh works that should be fairly easy to see.

Away from the machine now, will check tomorrow morning (CET).
-- 
Hilsen Harald

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

[Harald Arnesen]

Jani Nikula [25.08.2020 11:55]:

> On Fri, 21 Aug 2020, Pavel Machek  wrote:
>> On Thu 2020-08-20 09:16:18, Linus Torvalds wrote:
>>> On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek  wrote:
>>> >
>>> > Yes, it seems they make things work. (Chris asked for new patch to be
>>> > tested, so I am switching to his kernel, but it survived longer than
>>> > it usually does.)
>>> 
>>> Ok, so at worst we know how to solve it, at best the reverts won't be
>>> needed because Chris' patch will fix the issue properly.
>>> 
>>> So I'll archive this thread, but remind me if this hasn't gotten
>>> sorted out in the later rc's.
>>
>> Yes, thank you, it seems we have a solution w/o the revert.
> 
> For posterity, I'm told the fix is [1].
> 
> BR,
> Jani.
> 
> 
> [1] https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/

Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
freeezes. I can still ssh into the machine

The three reverts (763fedd6a216, 7ac2d2536dfa and 9e0f9464e2ab) fixes
the bug for me.
-- 
Hilsen Harald

Re: gcc-10: kernel stack is corrupted and fails to boot

[Harald Arnesen]

Kalle Valo [13.05.2020 17:31]:

> Great, so it's not a problem due to my setup.

I see the same thing on two machines, using a self-compiled gcc 10.1.0.
Glad to hear it's not just me. Switched back to 9.3.0 for the time being.
-- 
Hilsen Harald

Re: BISECTED: Compile error on 5.4-rc1

[Harald Arnesen]

Masahiro Yamada [05.10.2019 15:17]:

> As for POSIX, I found this:
> 
> -->8
> Applications should note that the standard PATH to the shell cannot
> be assumed to be either /bin/sh or /usr/bin/sh, and should be determined
> by interrogation of the PATH returned by getconf PATH , ensuring that
> the returned pathname is an absolute pathname and not a shell built-in.
> -->8
> 
> https://pubs.opengroup.org/onlinepubs/009695399/utilities/sh.html

Okay. Then it's the Schilling/OpenSolaris shell that is the problem, not
that I use it anyway.
-- 
Hilsen Harald

Re: BISECTED: Compile error on 5.4-rc1

[Harald Arnesen]

Masahiro Yamada [05.10.2019 12:19]:

> CONFIG_SHELL previously fell back to 'sh' when bash is not installed,
> so I just kept it as it was.
> 
> If we had used the exact absolute path /bin/sh,
> it would have worked irrespective of the PATH environment.
> 
> But, there is a counter option like this:
> 
> 
> commit 16f8259ca77d04f95e5ca90be1b1894ed45816c0
> Author: Bjørn Forsman 
> Date:   Sun Nov 5 10:44:16 2017 +0100
> 
> kbuild: /bin/pwd -> pwd
> 
> Most places use pwd and rely on $PATH lookup. Moving the remaining
> absolute path /bin/pwd users over for consistency.
> 
> Also, a reason for doing /bin/pwd -> pwd instead of the other way around
> is because I believe build systems should make little assumptions on
> host filesystem layout. Case in point, we do this kind of patching
> already in NixOS.
> 
> Ref. commit 028568d84da3cfca49f5f846f01441d70451
> ("kbuild: revert $(realpath ...) to $(shell cd ... && /bin/pwd)").
> 
> Signed-off-by: Bjørn Forsman 
> Signed-off-by: Masahiro Yamada 
> 
> 
> 
> I cannot find a way to satisfy everybody.
> 

I'm totally fine with the way it is now, now that I know how it works.
However, doesn't Posix dictate that there is a /bin/sh?
-- 
Hilsen Harald

Re: BISECTED: Compile error on 5.4-rc1

[Harald Arnesen]

Harald Arnesen [05.10.2019 11:03]:

> Masahiro Yamada [05.10.2019 05:24]:
> 
>> I cannot reproduce it.
>> 
>> I tested bindeb-pkg for the latest Linus tree successfully.
> 
> Strange, I have now tried another machine running the same distro
> (Devuan Beowulf), and I get the same result there. Will check further.

I found out what was wrong.

Both machines have been used for dvd burning, and I have used Jörg
Schilling's cdrecord - and I had installed all of the "Schily Tools",
which unfortunately includes a shell command. Now, I had (by mistake)
/opt/schily/bin early in my path, and his OpenSolaris-derived shell
didn't work as expected.

Moving /opt/schily/bin to the end of the path fixes the problem.

But shouldn't it work even if "sh" is not equal to "/bin/sh"?
-- 
Hilsen Harald

Re: BISECTED: Compile error on 5.4-rc1

[Harald Arnesen]

Masahiro Yamada [05.10.2019 05:24]:

> I cannot reproduce it.
> 
> I tested bindeb-pkg for the latest Linus tree successfully.

Strange, I have now tried another machine running the same distro
(Devuan Beowulf), and I get the same result there. Will check further.
-- 
Hilsen Harald

BISECTED: Compile error on 5.4-rc1

[Harald Arnesen]

I just tried to compile kernel 5.4-rc1 on my ThinkPad, which runs Devuan
Beowulf. Got the following:

$ make bindeb-pkg
  UPD include/config/kernel.release
sh ./scripts/package/mkdebian
dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch)  -b -nc -uc
dpkg-buildpackage: info: source package linux-5.4.0-rc1-00014-gcc3a7bfe62b9
dpkg-buildpackage: info: source version 5.4.0-rc1-00014-gcc3a7bfe62b9-1
dpkg-buildpackage: info: source distribution beowulf
dpkg-buildpackage: info: source changed by Harald Arnesen

dpkg-architecture: warning: specified GNU system type x86_64-linux-gnu
does not match CC system type x86_64-pc-linux-gnu, try setting a correct
CC environment variable
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
dpkg-source: warning: can't parse dependency -n libelf-dev
dpkg-source: error: error occurred while parsing Build-Depends
dpkg-buildpackage: error: dpkg-source --before-build . subprocess
returned exit status 255
make[1]: *** [scripts/Makefile.package:83: bindeb-pkg] Error 255
make: *** [Makefile:1448: bindeb-pkg] Error 2


Bisecting gives me

858805b336be1cabb3d9033adaa3676574d12e37 is the first bad commit
commit 858805b336be1cabb3d9033adaa3676574d12e37
Author: Masahiro Yamada 
Date:   Sun Aug 25 22:28:37 2019 +0900
...

By reverting commit 858805b336be1cabb3d9033adaa3676574d12e37 I could
compile the kernel.
-- 
Hilsen Harald

Re: [REGRESSION 5.0.x] Windows XP broken on KVM

[Harald Arnesen]

Takashi Iwai [18.04.2019 09:38]:

> Hi,
> 
> we've got a regression report on the recent 5.0.x kernel, starting
> from 5.0.6, where Windows XP can't boot on KVM any longer.

Not for all configurations. I just checked with 5.0.8, and Windows XP
boots just fine on KVM.
-- 
Hilsen Harald

Re: [REGRESSION 5.0.x] Windows XP broken on KVM

[Harald Arnesen]

Greg Kroah-Hartman [18.04.2019 09:53]:

> On Thu, Apr 18, 2019 at 09:38:52AM +0200, Takashi Iwai wrote:
>> Hi,
>> 
>> we've got a regression report on the recent 5.0.x kernel, starting
>> from 5.0.6, where Windows XP can't boot on KVM any longer.
>> 
>> The culprit seems to be the patch
>>KVM: x86: update %rip after emulating IO
>> with the upstream commit 45def77ebf79e2e8942b89ed79294d97ce914fa0.
>> Reverting this alone fixed the problem.
>> 
>> The report is found at openSUSE bugzilla:
>>   https://bugzilla.suse.com/show_bug.cgi?id=1132694
>> 
>> Is there already a followup fix?  If not, we need to revert it from
>> stable, at least.
> 
> Is this also a problem in 5.1-rc5?

My previously installed Windows XP boots and runs fine in 5.1-rc5.
-- 
Hilsen Harald

Re: [BISECTED] KVM error with 5.0-rc

[Harald Arnesen]

Sean Christopherson [14.01.2019 19:33]:

> On Mon, Jan 14, 2019 at 06:04:27PM +0100, Harald Arnesen wrote:
>> Qemu with KVM acceleration fails with kernel 5.0-rc1 and 5.0-rc2.
>> It works fine with 4.20.

> Can you test the attached patch?  Found a bug when re-inspecting the
> guilty commit, the wrong VMCS field is being modifying when applying an
> errata to disable VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL.  Your CPU is
> listed as one of the models affected by the errata.  Compile tested only.

Yes, this patch fixes the error.

Feel free to add a "Tested-by: Harald Arnesen ".
-- 
Hilsen Harald

Re: [GIT PULL] arm64 fixes for 4.18-rc5

[Harald Arnesen]

Linus Torvalds [2018-07-13 20:51]:

> On Fri, Jul 13, 2018 at 6:13 AM Will Deacon  wrote:
>>
>> Catalin's out enjoying the sunshine, so I'm sending the fixes for a couple
>> of weeks (although there hopefully won't be any more!).
> 
> Never fear, I'm sure there won't be more than a couple of weeks of
> sunshine in the UK this summer.
> 
> That's what you were trying to say, right?
> 
> Linus

FYI: Northern Europe has been exceptionally warm this summer.
-- 
Hilsen Harald

Re: [GIT PULL] arm64 fixes for 4.18-rc5

[Harald Arnesen]

Linus Torvalds [2018-07-13 20:51]:

> On Fri, Jul 13, 2018 at 6:13 AM Will Deacon  wrote:
>>
>> Catalin's out enjoying the sunshine, so I'm sending the fixes for a couple
>> of weeks (although there hopefully won't be any more!).
> 
> Never fear, I'm sure there won't be more than a couple of weeks of
> sunshine in the UK this summer.
> 
> That's what you were trying to say, right?
> 
> Linus

FYI: Northern Europe has been exceptionally warm this summer.
-- 
Hilsen Harald

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Harald Arnesen]

Den 14/11/2016 11:59, skrev One Thousand Gnomes:


Is anyone actually still using DOSemu these days or are people all
using DOSbox ?

Alan


One thing lacking from DOSbox is TCP/IP networking.
--
Hilsen Harald

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Harald Arnesen]

Den 14/11/2016 11:59, skrev One Thousand Gnomes:


Is anyone actually still using DOSemu these days or are people all
using DOSbox ?

Alan


One thing lacking from DOSbox is TCP/IP networking.
--
Hilsen Harald

Re: Linux 4.5-rc2

[Harald Arnesen]

Gerd Hoffmann [2016-02-01 15:18]:

> n Mo, 2016-02-01 at 14:19 +0100, Harald Arnesen wrote:
>> I still get the blank screen than Bjørn Mork reported and bisected when
>> 4.5-rc1 was released.
>
> Fix[1] is already queued by Jani Nikula, I suspect it simply missed the
> boat because there was no drm-intel-fixes merge in -rc2.

Confirmed, this patch fixes the bug.
-- 
Hilsen Harald

Re: Linux 4.5-rc2

[Harald Arnesen]

I still get the blank screen than Bjørn Mork reported and bisected when
4.5-rc1 was released.

Reverting this commit fixes it:

HEAD is now at 39bfcd5235e0 drm/i915: more virtual south bridge detection
39bfcd5235e07e95ad3e70eab8e0b85db181de9e is the first bad commit
commit 39bfcd5235e07e95ad3e70eab8e0b85db181de9e
Author: Gerd Hoffmann 
Date:   Thu Nov 26 12:03:51 2015 +0100

drm/i915: more virtual south bridge detection

Commit "30c964a drm/i915: Detect virtual south bridge" detects and
handles the southbridge emulated by vmware esx.  Add the ich9 south
bridge emulated by 'qemu -M q35'.

Signed-off-by: Gerd Hoffmann 
Signed-off-by: Daniel Vetter 

:04 04 b59ceb519d517a00e41e575346505b9ebde06288
825eb4e5684952de0931312183d1cf163c43219a M  drivers
-- 
Hilsen Harald

Re: Linux 4.5-rc2

[Harald Arnesen]

I still get the blank screen than Bjørn Mork reported and bisected when
4.5-rc1 was released.

Reverting this commit fixes it:

HEAD is now at 39bfcd5235e0 drm/i915: more virtual south bridge detection
39bfcd5235e07e95ad3e70eab8e0b85db181de9e is the first bad commit
commit 39bfcd5235e07e95ad3e70eab8e0b85db181de9e
Author: Gerd Hoffmann 
Date:   Thu Nov 26 12:03:51 2015 +0100

drm/i915: more virtual south bridge detection

Commit "30c964a drm/i915: Detect virtual south bridge" detects and
handles the southbridge emulated by vmware esx.  Add the ich9 south
bridge emulated by 'qemu -M q35'.

Signed-off-by: Gerd Hoffmann 
Signed-off-by: Daniel Vetter 

:04 04 b59ceb519d517a00e41e575346505b9ebde06288
825eb4e5684952de0931312183d1cf163c43219a M  drivers
-- 
Hilsen Harald

Re: Linux 4.5-rc2

[Harald Arnesen]

Gerd Hoffmann [2016-02-01 15:18]:

> n Mo, 2016-02-01 at 14:19 +0100, Harald Arnesen wrote:
>> I still get the blank screen than Bjørn Mork reported and bisected when
>> 4.5-rc1 was released.
>
> Fix[1] is already queued by Jani Nikula, I suspect it simply missed the
> boat because there was no drm-intel-fixes merge in -rc2.

Confirmed, this patch fixes the bug.
-- 
Hilsen Harald

Re: Regression in v4.5-rc1, bisected to commit 39bfcd5235e0 ("drm/i915: more virtual south bridge detection")

[Harald Arnesen]

Bjørn Mork [2016-01-25 03:52]:

> I have confirmed tha reverting this commit on top of v4.5-rc1 fixes the
> problem.

Confirmed. Fixes the problem with my T500 also.
-- 
Hilsen Harald

Re: Regression in v4.5-rc1, bisected to commit 39bfcd5235e0 ("drm/i915: more virtual south bridge detection")

[Harald Arnesen]

Bjørn Mork [2016-01-25 03:52]:

> Hello,
> 
> my oldish Thinkpad X301 only wanted to show a blank screen in v4.5-rc1.

Same thing with my Thinkpad T500. I had just started bisecting, but will
try this revert first.
-- 
Hilsen Harald

Re: Regression in v4.5-rc1, bisected to commit 39bfcd5235e0 ("drm/i915: more virtual south bridge detection")

[Harald Arnesen]

Bjørn Mork [2016-01-25 03:52]:

> I have confirmed tha reverting this commit on top of v4.5-rc1 fixes the
> problem.

Confirmed. Fixes the problem with my T500 also.
-- 
Hilsen Harald

Re: Regression in v4.5-rc1, bisected to commit 39bfcd5235e0 ("drm/i915: more virtual south bridge detection")

[Harald Arnesen]

Bjørn Mork [2016-01-25 03:52]:

> Hello,
> 
> my oldish Thinkpad X301 only wanted to show a blank screen in v4.5-rc1.

Same thing with my Thinkpad T500. I had just started bisecting, but will
try this revert first.
-- 
Hilsen Harald

Re: [PATCH v2 1/1] fix a dead loop when in heavy low memory

[Harald Arnesen]

Greg KH [2015-12-26 19:12]:

> I need a "full" name here, not a "short" name, sorry, before I can do
> anything with this patch.

I don't know if that is the case here, but:

You know, of course, that there are societies in this world  where only
one name is used?
-- 
Hilsen Harald
--
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 v2 1/1] fix a dead loop when in heavy low memory

[Harald Arnesen]

Greg KH [2015-12-26 19:12]:

> I need a "full" name here, not a "short" name, sorry, before I can do
> anything with this patch.

I don't know if that is the case here, but:

You know, of course, that there are societies in this world  where only
one name is used?
-- 
Hilsen Harald
--
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: A new, fast and "unbreakable" encryption algorithm

[Harald Arnesen]

Ismail Kizir [2015-11-18 06:25]:

> Hello,
> 
> I've developed a new encryption algorithm, which dynamically changes
> the key according to plaintext and practically impossible to break. I
> also opened to public with MIT dual License.

"There are two kinds of cryptography in this world: cryptography that
will stop your kid sister from reading your files, and cryptography that
will stop major governments from reading your files."
- Bruce Scheier, Applied Cryptography
-- 
Hilsen Harald
--
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: A new, fast and "unbreakable" encryption algorithm

[Harald Arnesen]

Ismail Kizir [2015-11-18 06:25]:

> Hello,
> 
> I've developed a new encryption algorithm, which dynamically changes
> the key according to plaintext and practically impossible to break. I
> also opened to public with MIT dual License.

"There are two kinds of cryptography in this world: cryptography that
will stop your kid sister from reading your files, and cryptography that
will stop major governments from reading your files."
- Bruce Scheier, Applied Cryptography
-- 
Hilsen Harald
--
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: 4.2-rc2 regression: drm/i915

[Harald Arnesen]

Daniel Vetter [2015-07-14 09:46]:

> Can you please attach your Xorg.log?

Attached Xorg.log from both -rc1 and -rc2.
-- 
Hilsen Harald
[ 34371.696] 
X.Org X Server 1.17.2
Release Date: 2015-06-16
[ 34371.696] X Protocol Version 11, Revision 0
[ 34371.696] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[ 34371.696] Current Operating System: Linux oregano 4.2.0-rc1 #1 SMP PREEMPT 
Mon Jul 6 00:14:55 CEST 2015 x86_64
[ 34371.696] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-rc1 
root=UUID=34518a86-43db-4264-806e-f2e98c7edaf6 ro
[ 34371.696] Build Date: 01 July 2015  05:17:14PM
[ 34371.696] xorg-server 2:1.17.2-1 (http://www.debian.org/support) 
[ 34371.696] Current version of pixman: 0.32.6
[ 34371.696]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 34371.696] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 34371.696] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jul 14 16:06:17 
2015
[ 34371.697] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 34371.697] (==) No Layout section.  Using the first Screen section.
[ 34371.697] (==) No screen section available. Using defaults.
[ 34371.697] (**) |-->Screen "Default Screen Section" (0)
[ 34371.697] (**) |   |-->Monitor ""
[ 34371.697] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 34371.697] (==) Automatically adding devices
[ 34371.697] (==) Automatically enabling devices
[ 34371.697] (==) Automatically adding GPU devices
[ 34371.697] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 34371.697]Entry deleted from font path.
[ 34371.697] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 34371.697] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 34371.697] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 34371.697] (II) Loader magic: 0x55ac57b65d80
[ 34371.697] (II) Module ABI versions:
[ 34371.697]X.Org ANSI C Emulation: 0.4
[ 34371.697]X.Org Video Driver: 19.0
[ 34371.697]X.Org XInput driver : 21.0
[ 34371.697]X.Org Server Extension : 9.0
[ 34371.697] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 34371.699] (--) PCI:*(0:0:2:0) 8086:2a42:17aa:2114 rev 7, Mem @ 
0xf440/4194304, 0xd000/268435456, I/O @ 0x1800/8
[ 34371.699] (--) PCI: (0:0:2:1) 8086:2a43:17aa:2114 rev 7, Mem @ 
0xf420/1048576
[ 34371.699] (II) LoadModule: "glx"
[ 34371.699] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 34371.700] (II) Module glx: vendor="X.Org Foundation"
[ 34371.700]compiled for 1.17.2, module version = 1.0.0
[ 34371.700]ABI class: X.Org Server Extension, version 9.0
[ 34371.700] (==) AIGLX enabled
[ 34371.700] (==) Matched intel as autoconfigured driver 0
[ 34371.700] (==) Matched intel as autoconfigured driver 1
[ 34371.700] (==) Matched modesetting as autoconfigured driver 2
[ 34371.700] (==) Matched fbdev as autoconfigured driver 3
[ 34371.700] (==) Matched vesa as autoconfigured driver 4
[ 34371.700] (==) Assigned the driver to the xf86ConfigLayout
[ 34371.701] (II) LoadModule: "intel"
[ 34371.701] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[ 34371.701] (II) Module intel: vendor="X.Org Foundation"
[ 34371.701]compiled for 1.17.1, module version = 2.99.917
[ 34371.701]Module class: X.Org Video Driver
[ 34371.701]ABI class: X.Org Video Driver, version 19.0
[ 34371.701] (II) LoadModule: "modesetting"
[ 34371.701] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 34371.701] (II) Module modesetting: vendor="X.Org Foundation"
[ 34371.701]compiled for 1.17.2, module version = 1.17.2
[ 34371.701]Module class: X.Org Video Driver
[ 34371.701]ABI class: X.Org Video Driver, version 19.0
[ 34371.701] (II) LoadModule: "fbdev"
[ 34371.701] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 34371.701] (II) Module fbdev: vendor="X.Org Foundation"
[ 34371.701]compiled for 1.17.1, module version = 0.4.4
[ 34371.701]Module class: X.Org Video Driver
[ 34371.701]ABI class: X.Org Video Driver, version 19.0
[ 34371.701] (II) LoadModule: "vesa"
[ 34371.701] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[ 34371.701] (II) Module vesa: vendor="X.Org Foundation"
[ 34371.701]compiled for 1.17.1, module version = 2.3.3
[ 34371.701]Module class: X.Org Video Driver
[ 34371.701]ABI class: X.Org Video Driver, version 19.0
[ 34371.701] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:

Re: 4.2-rc2 regression: drm/i915

[Harald Arnesen]

Daniel Vetter [2015-07-14 09:46]:

 Can you please attach your Xorg.log?

Attached Xorg.log from both -rc1 and -rc2.
-- 
Hilsen Harald
[ 34371.696] 
X.Org X Server 1.17.2
Release Date: 2015-06-16
[ 34371.696] X Protocol Version 11, Revision 0
[ 34371.696] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[ 34371.696] Current Operating System: Linux oregano 4.2.0-rc1 #1 SMP PREEMPT 
Mon Jul 6 00:14:55 CEST 2015 x86_64
[ 34371.696] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-rc1 
root=UUID=34518a86-43db-4264-806e-f2e98c7edaf6 ro
[ 34371.696] Build Date: 01 July 2015  05:17:14PM
[ 34371.696] xorg-server 2:1.17.2-1 (http://www.debian.org/support) 
[ 34371.696] Current version of pixman: 0.32.6
[ 34371.696]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 34371.696] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 34371.696] (==) Log file: /var/log/Xorg.0.log, Time: Tue Jul 14 16:06:17 
2015
[ 34371.697] (==) Using system config directory /usr/share/X11/xorg.conf.d
[ 34371.697] (==) No Layout section.  Using the first Screen section.
[ 34371.697] (==) No screen section available. Using defaults.
[ 34371.697] (**) |--Screen Default Screen Section (0)
[ 34371.697] (**) |   |--Monitor default monitor
[ 34371.697] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[ 34371.697] (==) Automatically adding devices
[ 34371.697] (==) Automatically enabling devices
[ 34371.697] (==) Automatically adding GPU devices
[ 34371.697] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[ 34371.697]Entry deleted from font path.
[ 34371.697] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 34371.697] (==) ModulePath set to /usr/lib/xorg/modules
[ 34371.697] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 34371.697] (II) Loader magic: 0x55ac57b65d80
[ 34371.697] (II) Module ABI versions:
[ 34371.697]X.Org ANSI C Emulation: 0.4
[ 34371.697]X.Org Video Driver: 19.0
[ 34371.697]X.Org XInput driver : 21.0
[ 34371.697]X.Org Server Extension : 9.0
[ 34371.697] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 34371.699] (--) PCI:*(0:0:2:0) 8086:2a42:17aa:2114 rev 7, Mem @ 
0xf440/4194304, 0xd000/268435456, I/O @ 0x1800/8
[ 34371.699] (--) PCI: (0:0:2:1) 8086:2a43:17aa:2114 rev 7, Mem @ 
0xf420/1048576
[ 34371.699] (II) LoadModule: glx
[ 34371.699] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 34371.700] (II) Module glx: vendor=X.Org Foundation
[ 34371.700]compiled for 1.17.2, module version = 1.0.0
[ 34371.700]ABI class: X.Org Server Extension, version 9.0
[ 34371.700] (==) AIGLX enabled
[ 34371.700] (==) Matched intel as autoconfigured driver 0
[ 34371.700] (==) Matched intel as autoconfigured driver 1
[ 34371.700] (==) Matched modesetting as autoconfigured driver 2
[ 34371.700] (==) Matched fbdev as autoconfigured driver 3
[ 34371.700] (==) Matched vesa as autoconfigured driver 4
[ 34371.700] (==) Assigned the driver to the xf86ConfigLayout
[ 34371.701] (II) LoadModule: intel
[ 34371.701] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[ 34371.701] (II) Module intel: vendor=X.Org Foundation
[ 34371.701]compiled for 1.17.1, module version = 2.99.917
[ 34371.701]Module class: X.Org Video Driver
[ 34371.701]ABI class: X.Org Video Driver, version 19.0
[ 34371.701] (II) LoadModule: modesetting
[ 34371.701] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 34371.701] (II) Module modesetting: vendor=X.Org Foundation
[ 34371.701]compiled for 1.17.2, module version = 1.17.2
[ 34371.701]Module class: X.Org Video Driver
[ 34371.701]ABI class: X.Org Video Driver, version 19.0
[ 34371.701] (II) LoadModule: fbdev
[ 34371.701] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 34371.701] (II) Module fbdev: vendor=X.Org Foundation
[ 34371.701]compiled for 1.17.1, module version = 0.4.4
[ 34371.701]Module class: X.Org Video Driver
[ 34371.701]ABI class: X.Org Video Driver, version 19.0
[ 34371.701] (II) LoadModule: vesa
[ 34371.701] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[ 34371.701] (II) Module vesa: vendor=X.Org Foundation
[ 34371.701]compiled for 1.17.1, module version = 2.3.3
[ 34371.701]Module class: X.Org Video Driver
[ 34371.701]ABI class: X.Org Video Driver, version 19.0
[ 34371.701] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
i810, 

Re: Panic with latest git kernel

[Harald Arnesen]

Richard Weinberger [2014-01-26 16:00]:

> Your image shows that the kernel looses the init process because /init seems
> to be unable to exec switch_root.
> Find out what is going on in your initrd.
> 
> So far it has zero to do with the kernel itself.

Seems you are right. I just tried to compile a 3.13.0 kernel again
(which I did when i was released, and it worked then), and I got the
same panic.

Must be a Debian bug. I will pester them instead.
-- 
Hilsen Harald
--
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: Panic with latest git kernel

[Harald Arnesen]

Richard Weinberger [2014-01-26 14:36]:

>> $ cpio --list > kernel
>> kernel/x86
>> kernel/x86/microcode
>> kernel/x86/microcode/GenuineIntel.bin
>> 50 blocks
>> $

> Looks very strange.
> Add rdinit=/bin/sh to your commandline such that you get a shell within
> the initrd...

Okay, I did. On the non-working kernel/initrd, the working ditto, and
the Debian-provided files. And ls shows contents that seem sane.

None of the initrds have a switch_root in them, neither in /sbin or
anywhere else. They all have a /bin/pivot_root, which may be the same?
-- 
Hilsen Harald
--
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: Panic with latest git kernel

[Harald Arnesen]

Richard Weinberger [2014-01-26 14:36]:

>> $ cpio --list > > kernel
>> > kernel/x86
>> > kernel/x86/microcode
>> > kernel/x86/microcode/GenuineIntel.bin
>> > 50 blocks
>> > $
> Looks very strange.

The same with the Debian-provided kernel/initrd 3.12-1-amd64

> Add rdinit=/bin/sh to your commandline such that you get a shell within
> the initrd...

Will do.
-- 
Hilsen Harald
--
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: Panic with latest git kernel

[Harald Arnesen]

Richard Weinberger [2014-01-26 14:36]:

 $ cpio --list /boot/initrd.img-3.13.0-03477-gdf32e43
  kernel
  kernel/x86
  kernel/x86/microcode
  kernel/x86/microcode/GenuineIntel.bin
  50 blocks
  $
 Looks very strange.

The same with the Debian-provided kernel/initrd 3.12-1-amd64

 Add rdinit=/bin/sh to your commandline such that you get a shell within
 the initrd...

Will do.
-- 
Hilsen Harald
--
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: Panic with latest git kernel

[Harald Arnesen]

Richard Weinberger [2014-01-26 14:36]:

 $ cpio --list /boot/initrd.img-3.13.0-03477-gdf32e43
 kernel
 kernel/x86
 kernel/x86/microcode
 kernel/x86/microcode/GenuineIntel.bin
 50 blocks
 $

 Looks very strange.
 Add rdinit=/bin/sh to your commandline such that you get a shell within
 the initrd...

Okay, I did. On the non-working kernel/initrd, the working ditto, and
the Debian-provided files. And ls shows contents that seem sane.

None of the initrds have a switch_root in them, neither in /sbin or
anywhere else. They all have a /bin/pivot_root, which may be the same?
-- 
Hilsen Harald
--
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: Panic with latest git kernel

[Harald Arnesen]

Richard Weinberger [2014-01-26 16:00]:

 Your image shows that the kernel looses the init process because /init seems
 to be unable to exec switch_root.
 Find out what is going on in your initrd.
 
 So far it has zero to do with the kernel itself.

Seems you are right. I just tried to compile a 3.13.0 kernel again
(which I did when i was released, and it worked then), and I got the
same panic.

Must be a Debian bug. I will pester them instead.
-- 
Hilsen Harald
--
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] Remove unnecessarily gendered language

[Harald Arnesen]

One Thousand Gnomes [2013-12-05 17:54]:

>>> @@ -23,7 +24,7 @@ Quota netlink interface
>>>  When user exceeds a softlimit, runs out of grace time or reaches hardlimit,
>>>  quota subsystem traditionally printed a message to the controlling 
>>> terminal of
>>>  the process which caused the excess. This method has the disadvantage that
>>> -when user is using a graphical desktop he usually cannot see the message.
>>> +when user is using a graphical desktop they usually cannot see the
>>>  message.

> I would argue that "This method has the disadvantage that when user
> is using a graphical desktop he usually cannot see the message." 

How about:

"This method has the disadvantage that, when using a graphical desktop,
the user usually cannot see the message" - or something similar? Gender
neutral, and not _too_ cumbersome, aside from the "user...usually".
-- 
Hilsen Harald
--
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] Remove unnecessarily gendered language

[Harald Arnesen]

One Thousand Gnomes [2013-12-05 17:54]:

 @@ -23,7 +24,7 @@ Quota netlink interface
  When user exceeds a softlimit, runs out of grace time or reaches hardlimit,
  quota subsystem traditionally printed a message to the controlling 
 terminal of
  the process which caused the excess. This method has the disadvantage that
 -when user is using a graphical desktop he usually cannot see the message.
 +when user is using a graphical desktop they usually cannot see the
  message.

 I would argue that This method has the disadvantage that when user
 is using a graphical desktop he usually cannot see the message. 

How about:

This method has the disadvantage that, when using a graphical desktop,
the user usually cannot see the message - or something similar? Gender
neutral, and not _too_ cumbersome, aside from the user...usually.
-- 
Hilsen Harald
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Harald Arnesen]

I have the same problem on my Lenovo T500. I think the graphics card is
involved.

This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
nobody cared" during boot, not when I boot with the ATI card.

And /proc/interrupts are surely different with the two cards. Look at
the irq 16 line:

$ cat intel-interrupts.txt
   CPU0   CPU1
  0:  23658  22859   IO-APIC-edge  timer
  1:168177   IO-APIC-edge  i8042
  8:  1  0   IO-APIC-edge  rtc0
  9:329347   IO-APIC-fasteoi   acpi
 12:   3065   3166   IO-APIC-edge  i8042
 16:  49732  50269   IO-APIC-fasteoi   yenta, uhci_hcd:usb6
 17:  1  0   IO-APIC-fasteoi   firewire_ohci, uhci_hcd:usb7
 18:  0  0   IO-APIC-fasteoi   mmc0, uhci_hcd:usb8
 19:216204   IO-APIC-fasteoi   ehci_hcd:usb2
 20:  0  0   IO-APIC-fasteoi   uhci_hcd:usb3
 21:114103   IO-APIC-fasteoi   uhci_hcd:usb4
 22:  0  0   IO-APIC-fasteoi   uhci_hcd:usb5
 23:  9  9   IO-APIC-fasteoi   i801_smbus, ehci_hcd:usb1
 40:  0  0  DMAR_MSI-edge  dmar2
 41:  0  0  DMAR_MSI-edge  dmar0
 42:  0  0  DMAR_MSI-edge  dmar3
 43:  0  0   PCI-MSI-edge  PCIe PME
 44:  0  0   PCI-MSI-edge  PCIe PME
 45:  0  0   PCI-MSI-edge  PCIe PME
 46:  0  0   PCI-MSI-edge  PCIe PME
 47:  10023  10173   PCI-MSI-edge  ahci
 48: 10  8   PCI-MSI-edge  mei
 49: 22 30   PCI-MSI-edge  eth0
 50: 66 71   PCI-MSI-edge  i915
 51:   2508   2348   PCI-MSI-edge  iwlwifi
 52:168169   PCI-MSI-edge  snd_hda_intel
NMI: 17 17   Non-maskable interrupts
LOC:  27988  25243   Local timer interrupts
SPU:  0  0   Spurious interrupts
PMI: 17 17   Performance monitoring interrupts
IWI:  0  0   IRQ work interrupts
RTR:  0  0   APIC ICR read retries
RES:   4584   2746   Rescheduling interrupts
CAL:   6178   7492   Function call interrupts
TLB:702651   TLB shootdowns
TRM:  0  0   Thermal event interrupts
THR:  0  0   Threshold APIC interrupts
MCE:  0  0   Machine check exceptions
MCP:  1  1   Machine check polls
ERR:  0
MIS:  0

$ cat ati-interrupts.txt
   CPU0   CPU1
  0:  15488  15268   IO-APIC-edge  timer
  1:182189   IO-APIC-edge  i8042
  8:  1  0   IO-APIC-edge  rtc0
  9:328339   IO-APIC-fasteoi   acpi
 12:   2071   1997   IO-APIC-edge  i8042
 16: 55 47   IO-APIC-fasteoi   yenta, uhci_hcd:usb4
 17:  1  1   IO-APIC-fasteoi   firewire_ohci, uhci_hcd:usb5
 18:  0  0   IO-APIC-fasteoi   uhci_hcd:usb6, mmc0
 19:219202   IO-APIC-fasteoi   ehci_hcd:usb8
 20:  0  0   IO-APIC-fasteoi   uhci_hcd:usb1
 21:112104   IO-APIC-fasteoi   uhci_hcd:usb2
 22:  0  0   IO-APIC-fasteoi   uhci_hcd:usb3
 23: 10  8   IO-APIC-fasteoi   i801_smbus, ehci_hcd:usb7
 40:  0  0  DMAR_MSI-edge  dmar1
 41:  0  0  DMAR_MSI-edge  dmar0
 42:  0  0  DMAR_MSI-edge  dmar2
 43:  0  0   PCI-MSI-edge  PCIe PME
 44:  0  0   PCI-MSI-edge  PCIe PME
 45:  0  0   PCI-MSI-edge  PCIe PME
 46:  0  0   PCI-MSI-edge  PCIe PME
 47:  0  0   PCI-MSI-edge  PCIe PME
 48:   9733   9932   PCI-MSI-edge  ahci
 49:  9  9   PCI-MSI-edge  mei
 50:   2308   2196   PCI-MSI-edge  iwlwifi
 51: 15 35   PCI-MSI-edge  eth0
 52:818815   PCI-MSI-edge  radeon
 53:167167   PCI-MSI-edge  snd_hda_intel
NMI: 17 16   Non-maskable interrupts
LOC:  18139  34223   Local timer interrupts
SPU:  0  0   Spurious interrupts
PMI: 17 16   Performance monitoring interrupts
IWI:  0  0   IRQ work interrupts
RTR:  0  0   APIC ICR read retries
RES:   3788   3563   Rescheduling interrupts
CAL:   6303   5894   Function call interrupts
TLB:711711   TLB shootdowns
TRM:  0  0   Thermal event interrupts
THR:  0  0   Threshold APIC interrupts
MCE:  0  0   Machine check exceptions
MCP:  1  1   Machine check polls
ERR:  0
MIS:  0
-- 
Hilsen Harald
--
To unsubscribe 

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Harald Arnesen]

I have the same problem on my Lenovo T500. I think the graphics card is
involved.

This laptop has hybrid graphics - one Intel GMA 4500MHD and one ATI
Mobility Radeon HD 3650. When I boot with the Intel card, I get irq 16:
nobody cared during boot, not when I boot with the ATI card.

And /proc/interrupts are surely different with the two cards. Look at
the irq 16 line:

$ cat intel-interrupts.txt
   CPU0   CPU1
  0:  23658  22859   IO-APIC-edge  timer
  1:168177   IO-APIC-edge  i8042
  8:  1  0   IO-APIC-edge  rtc0
  9:329347   IO-APIC-fasteoi   acpi
 12:   3065   3166   IO-APIC-edge  i8042
 16:  49732  50269   IO-APIC-fasteoi   yenta, uhci_hcd:usb6
 17:  1  0   IO-APIC-fasteoi   firewire_ohci, uhci_hcd:usb7
 18:  0  0   IO-APIC-fasteoi   mmc0, uhci_hcd:usb8
 19:216204   IO-APIC-fasteoi   ehci_hcd:usb2
 20:  0  0   IO-APIC-fasteoi   uhci_hcd:usb3
 21:114103   IO-APIC-fasteoi   uhci_hcd:usb4
 22:  0  0   IO-APIC-fasteoi   uhci_hcd:usb5
 23:  9  9   IO-APIC-fasteoi   i801_smbus, ehci_hcd:usb1
 40:  0  0  DMAR_MSI-edge  dmar2
 41:  0  0  DMAR_MSI-edge  dmar0
 42:  0  0  DMAR_MSI-edge  dmar3
 43:  0  0   PCI-MSI-edge  PCIe PME
 44:  0  0   PCI-MSI-edge  PCIe PME
 45:  0  0   PCI-MSI-edge  PCIe PME
 46:  0  0   PCI-MSI-edge  PCIe PME
 47:  10023  10173   PCI-MSI-edge  ahci
 48: 10  8   PCI-MSI-edge  mei
 49: 22 30   PCI-MSI-edge  eth0
 50: 66 71   PCI-MSI-edge  i915
 51:   2508   2348   PCI-MSI-edge  iwlwifi
 52:168169   PCI-MSI-edge  snd_hda_intel
NMI: 17 17   Non-maskable interrupts
LOC:  27988  25243   Local timer interrupts
SPU:  0  0   Spurious interrupts
PMI: 17 17   Performance monitoring interrupts
IWI:  0  0   IRQ work interrupts
RTR:  0  0   APIC ICR read retries
RES:   4584   2746   Rescheduling interrupts
CAL:   6178   7492   Function call interrupts
TLB:702651   TLB shootdowns
TRM:  0  0   Thermal event interrupts
THR:  0  0   Threshold APIC interrupts
MCE:  0  0   Machine check exceptions
MCP:  1  1   Machine check polls
ERR:  0
MIS:  0

$ cat ati-interrupts.txt
   CPU0   CPU1
  0:  15488  15268   IO-APIC-edge  timer
  1:182189   IO-APIC-edge  i8042
  8:  1  0   IO-APIC-edge  rtc0
  9:328339   IO-APIC-fasteoi   acpi
 12:   2071   1997   IO-APIC-edge  i8042
 16: 55 47   IO-APIC-fasteoi   yenta, uhci_hcd:usb4
 17:  1  1   IO-APIC-fasteoi   firewire_ohci, uhci_hcd:usb5
 18:  0  0   IO-APIC-fasteoi   uhci_hcd:usb6, mmc0
 19:219202   IO-APIC-fasteoi   ehci_hcd:usb8
 20:  0  0   IO-APIC-fasteoi   uhci_hcd:usb1
 21:112104   IO-APIC-fasteoi   uhci_hcd:usb2
 22:  0  0   IO-APIC-fasteoi   uhci_hcd:usb3
 23: 10  8   IO-APIC-fasteoi   i801_smbus, ehci_hcd:usb7
 40:  0  0  DMAR_MSI-edge  dmar1
 41:  0  0  DMAR_MSI-edge  dmar0
 42:  0  0  DMAR_MSI-edge  dmar2
 43:  0  0   PCI-MSI-edge  PCIe PME
 44:  0  0   PCI-MSI-edge  PCIe PME
 45:  0  0   PCI-MSI-edge  PCIe PME
 46:  0  0   PCI-MSI-edge  PCIe PME
 47:  0  0   PCI-MSI-edge  PCIe PME
 48:   9733   9932   PCI-MSI-edge  ahci
 49:  9  9   PCI-MSI-edge  mei
 50:   2308   2196   PCI-MSI-edge  iwlwifi
 51: 15 35   PCI-MSI-edge  eth0
 52:818815   PCI-MSI-edge  radeon
 53:167167   PCI-MSI-edge  snd_hda_intel
NMI: 17 16   Non-maskable interrupts
LOC:  18139  34223   Local timer interrupts
SPU:  0  0   Spurious interrupts
PMI: 17 16   Performance monitoring interrupts
IWI:  0  0   IRQ work interrupts
RTR:  0  0   APIC ICR read retries
RES:   3788   3563   Rescheduling interrupts
CAL:   6303   5894   Function call interrupts
TLB:711711   TLB shootdowns
TRM:  0  0   Thermal event interrupts
THR:  0  0   Threshold APIC interrupts
MCE:  0  0   Machine check exceptions
MCP:  1  1   Machine check polls
ERR:  0
MIS:  0
-- 
Hilsen Harald
--
To unsubscribe from 

Re: [3.9-rc1] very poor interrupt responses

[Harald Arnesen]

Rafael J. Wysocki [2013-03-11 04:38]:

> On Friday, March 08, 2013 02:12:33 PM Shawn Starr wrote:
>> Hello folks,
>>
>> I am noticing since rc0 and now rc1, very poor interrupt handling. Keyboard 
>> response, mouse movements, display refreshing etc. General input/display 
>> sluggishness. Did something break IRQ handling somewhere? I need to validate 
>> if this happens with X not running also if it is i915 related somehow. The 
>> behavor is noticed in a console login however.
> 
> Please try to disable the intel_pstate driver by putting intel_pstate=disable
> into the kernel's command line and see if that helps (you may also try to
> compile the driver out).

I see the same problem on my Thinkpad T500, and I have
X86_INTEL_PSTATE=n in my config.
-- 
Hilsen Harald
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3.9-rc1] very poor interrupt responses

[Harald Arnesen]

Rafael J. Wysocki [2013-03-11 04:38]:

 On Friday, March 08, 2013 02:12:33 PM Shawn Starr wrote:
 Hello folks,

 I am noticing since rc0 and now rc1, very poor interrupt handling. Keyboard 
 response, mouse movements, display refreshing etc. General input/display 
 sluggishness. Did something break IRQ handling somewhere? I need to validate 
 if this happens with X not running also if it is i915 related somehow. The 
 behavor is noticed in a console login however.
 
 Please try to disable the intel_pstate driver by putting intel_pstate=disable
 into the kernel's command line and see if that helps (you may also try to
 compile the driver out).

I see the same problem on my Thinkpad T500, and I have
X86_INTEL_PSTATE=n in my config.
-- 
Hilsen Harald
--
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/

3.8.0-08664-gc41b381: Very jerky mouse pointer

[Harald Arnesen]

Today's git kernel has, for me, sort of solved the usb problems that
recently was reported. Not completely, though.

My Logitech wireless usb mouse is about useless - the pointer lags badly
when I move the mouse.

This is a Lenovo Thinkpad T500.
-- 
Hilsen Harald
--
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/

3.8.0-08664-gc41b381: Very jerky mouse pointer

[Harald Arnesen]

Today's git kernel has, for me, sort of solved the usb problems that
recently was reported. Not completely, though.

My Logitech wireless usb mouse is about useless - the pointer lags badly
when I move the mouse.

This is a Lenovo Thinkpad T500.
-- 
Hilsen Harald
--
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: Latest git oopses during boot

[Harald Arnesen]

On 2/7/08, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 7 Feb 2008, Harald Arnesen wrote:
> >
> > I'll try applying the patch to a freshly downloaded git-tree.
>
> Ok, good.
>
> > Shall I try another compiler? I have at least these two:
> >
> > gcc version 3.4.6 (Ubuntu 3.4.6-6ubuntu2)
> > gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
>
> I would suggest a patch mis-application problem first (or possibly even
> the patch itself being broken - I simply didn't look very closely at the
> patch, but it *looked* ok).
>
> If it's a compiler bug, it's a pretty big one, and quite frankly, I doubt
> it. Compiler bugs do happen, but they are pretty rare, and they tend to
> have more subtle effects than the one you see.
>
> However:
>
> > in addition to the self-compiled 4.2.3 I used for the tests.
>
> 4.2.3? Really? That's pretty damn recent, and so almost totally untested.
> That does make a compiler bug at least more likely.
>
> So yes, if you already have other compilers installed, you should try
> them. If it really is a compiler bug, it's a really bad one, and you would
> want to let the gcc people know.
>
> Still, I'd double-check that the
>
> asc_dvc_varp->overrun_buf = kzalloc(ASC_OVERRUN_BSIZE, GFP_KERNEL);
>
> line was added properly first. You should see it way after the point where
> it did
>
> asc_dvc_varp = >dvc_var.asc_dvc_var;
>
> to initialize it (and both statements should be inside a
>
> if (ASC_NARROW_BOARD(boardp)) {
>
> conditional - please check that the source code looks sane too).
>
> Linus

I just re-downloaded an re-patched and re-compiled (with gcc 4.2.3),
and now the kernel boots. I must have screwed up the previous
patching.

It now works, with Fujita's patch applied.
-- 
Hilsen Harald
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Latest git oopses during boot

[Harald Arnesen]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> On Thu, 7 Feb 2008, Harald Arnesen wrote:
>> >
>> > Can you do a
>> >
>> > make drivers/scsi/advansys.lst
>> >
>> > and see what it should be?
>> 
>> Anyway, here it is, as an attachment.
>
> Ok, I was wrong. The code really *does* compile to that insane
>
>   a3 14 00 00 00  mov%eax,0x14
>
> by your compiler.
>
> That's the
>
>   asc_dvc_varp->overrun_buf = kzalloc(ASC_OVERRUN_BSIZE, GFP_KERNEL);
>
> thing, and gcc seems to have decided that it can statically prove that 
> asc_dvc_varp is NULL.
>
> Quite frankly, I don't see that being true. But you have some patches in 
> your tree that I haven't followed, so.. Are you sure the patches applied 
> to the right spot? The patch I saw added that kzalloc() to the _end_ of 
> the function (long after asc_dvc_varp was initialized), maybe that one got 
> mis-applied?
>
> Or maybe your compiler version is simply totally broken.
>
>   Linus

I'll try applying the patch to a freshly downloaded git-tree.

Shall I try another compiler? I have at least these two:

gcc version 3.4.6 (Ubuntu 3.4.6-6ubuntu2)
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

in addition to the self-compiled 4.2.3 I used for the tests.
-- 
Hilsen Harald.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Latest git oopses during boot

[Harald Arnesen]

On 2/7/08, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> (cc's restored, and expanded a bit)

Ah, sorry, not used to gmail's web interface. Clicked the wrong button.

> > Seems to be the advansys driver, so I tried to remove it - and indeed,
> > the kernel now boots. So I guess it's either that driver or my ancient
> > Nikon Coolscan II that is the only thing attached to the board.
>
> Thanks.  I uploaded the oops picture to
> http://userweb.kernel.org/~akpm/oops.jpg
>
> > Cc to the Matthew Wilcox added.
>
> mm...  looks like all Matthew's changes were in 2.6.23.  And 2.6.23 worked
> OK, yes?

Both 2.6.23 and 2.6.24 are ok.

> The only recent changes to drivers/scsi/advansys.c are
>
> commit b80ca4f7ee36c26d300c5a8f429e73372d153379
> Author: FUJITA Tomonori <[EMAIL PROTECTED]>
> Date:   Sun Jan 13 15:46:13 2008 +0900
>
> [SCSI] replace sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE
>
> This replaces sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE in
> several LLDs. It's a preparation for the future changes to remove
> sense_buffer array in scsi_cmnd structure.
>
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
>
> :100644 100644 9dd3952... 492702b... M  drivers/scsi/advansys.c
>
> commit 747d016e7e25e216b31022fe2b012508d99fb682
> Author: Randy Dunlap <[EMAIL PROTECTED]>
> Date:   Mon Jan 14 00:55:18 2008 -0800
>
> advansys: fix section mismatch warning
>
> Fix section mismatch warning:
>
> WARNING: vmlinux.o(.exit.text+0x152a): Section mismatch: reference to 
> .init.
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> Cc: Matthew Wilcox <[EMAIL PROTECTED]>
> Cc: James Bottomley <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
>
> which seem fairly benign.
>
>
> gcc inlining is going to make it rather a lot of work to find out which
> statement has actually oopsed there.
-- 
Hilsen Harald
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Latest git oopses during boot

[Harald Arnesen]

On 2/7/08, Linus Torvalds [EMAIL PROTECTED] wrote:


 On Thu, 7 Feb 2008, Harald Arnesen wrote:
 
  I'll try applying the patch to a freshly downloaded git-tree.

 Ok, good.

  Shall I try another compiler? I have at least these two:
 
  gcc version 3.4.6 (Ubuntu 3.4.6-6ubuntu2)
  gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

 I would suggest a patch mis-application problem first (or possibly even
 the patch itself being broken - I simply didn't look very closely at the
 patch, but it *looked* ok).

 If it's a compiler bug, it's a pretty big one, and quite frankly, I doubt
 it. Compiler bugs do happen, but they are pretty rare, and they tend to
 have more subtle effects than the one you see.

 However:

  in addition to the self-compiled 4.2.3 I used for the tests.

 4.2.3? Really? That's pretty damn recent, and so almost totally untested.
 That does make a compiler bug at least more likely.

 So yes, if you already have other compilers installed, you should try
 them. If it really is a compiler bug, it's a really bad one, and you would
 want to let the gcc people know.

 Still, I'd double-check that the

 asc_dvc_varp-overrun_buf = kzalloc(ASC_OVERRUN_BSIZE, GFP_KERNEL);

 line was added properly first. You should see it way after the point where
 it did

 asc_dvc_varp = boardp-dvc_var.asc_dvc_var;

 to initialize it (and both statements should be inside a

 if (ASC_NARROW_BOARD(boardp)) {

 conditional - please check that the source code looks sane too).

 Linus

I just re-downloaded an re-patched and re-compiled (with gcc 4.2.3),
and now the kernel boots. I must have screwed up the previous
patching.

It now works, with Fujita's patch applied.
-- 
Hilsen Harald
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Userspace compiler support of "long long"

[Harald Arnesen]

Adrian Bunk <[EMAIL PROTECTED]> writes:

> Is there any userspace Linux compiler that does not support "long long"?
> If yes, is there any other way to tell that something is a
> 64bit int on 32bit architectures?

TenDRA C:

"test.c", line 6: Error:
  [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'.

-- 
Hilsen Harald.

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

Re: Userspace compiler support of long long

[Harald Arnesen]

Adrian Bunk [EMAIL PROTECTED] writes:

 Is there any userspace Linux compiler that does not support long long?
 If yes, is there any other way to tell that something is a
 64bit int on 32bit architectures?

TenDRA C:

test.c, line 6: Error:
  [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'.

-- 
Hilsen Harald.

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

Re: Linux Kernel include files

[Harald Arnesen]

[EMAIL PROTECTED] (Joerg Schilling) writes:

>> FYI, cdrtools also compile and link fine with Sun's C compiler.
>
> M, if you call "cdrecord -scanbus", what do you get?

I may have misunderstood your make system. I cd-ed into the cdrtools
directory, ran ./Gmake.linux clean (I had already compiled with GCC),
and then ./Gmake.linux CCOM=suncc. I didn't see any errors at the end of
the make output.

However, what confused me was that the cdrecord binary wasn't removed.
And scrolling back, I see several compile errors from Sun's C compiler.

Shouldn't "make clean" remove the executable files?
-- 
Hilsen Harald.

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

Re: Linux Kernel include files

[Harald Arnesen]

Harald Arnesen <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] (Joerg Schilling) writes:
>
>>> If I actually install smake, as J�rg recommends, the message becomes:
>>> smake: Can't find any source for 'CCOM_suncc'.
>>> smake: Couldn't make 'CCOM_suncc'.
>>
>> Well, I was in hope that a small typo (in special as the correct spelling is 
>> in 
>> the file README.compile) should not be a problem.
>>
>> You need to use CCOM=suncc 
>
> Then it (star, I haven't tried cdrtools yes) compiles and links fine.
> There must be something wrong with your Linux installation.

FYI, cdrtools also compile and link fine with Sun's C compiler.
-- 
Hilsen Harald.

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

Re: Linux Kernel include files

[Harald Arnesen]

[EMAIL PROTECTED] (Joerg Schilling) writes:

>> If I actually install smake, as J�rg recommends, the message becomes:
>> smake: Can't find any source for 'CCOM_suncc'.
>> smake: Couldn't make 'CCOM_suncc'.
>
> Well, I was in hope that a small typo (in special as the correct spelling is 
> in 
> the file README.compile) should not be a problem.
>
> You need to use CCOM=suncc 

Then it (star, I haven't tried cdrtools yes) compiles and links fine.
There must be something wrong with your Linux installation.
-- 
Hilsen Harald.

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

Re: Linux Kernel include files

[Harald Arnesen]

David Woodhouse <[EMAIL PROTECTED]> writes:

>> >  Can you be more specific about why this is a problem? Don't
>> > we mostly define those crappy types using arch-specific knowledge, as
>> > 'int', 'long', etc?
>> 
>> I recommend you to install Sun Studio and to try to compile star or cdrtools
>> using Sun Studio by calling "make CCOM_suncc".
>>
>> ftp://ftp.berlios.de/pub/star/alpha/
>> ftp://ftp.berlios.de/pub/cdrecord/alpha/
>> 
>> You may need to hand edit the file incs//{xconfig.h!rules.conf}
>> 
>> in order to enable the auto-disabled features.
>> 
>> In any case, self reading the error messages from Sun Studio helps more than
>> trying to discuss it.
>
> I have no interest in doing this for myself, and I suspect that if I
> tried it I'd find that Sun Studio doesn't exist for Linux/PowerPC
> anyway. Please just show the error messages.

Apart from the usual whining about GNU make, the error message is:
make: *** No rule to make target `CCOM_suncc'.  Stop.

If I actually install smake, as Jörg recommends, the message becomes:
smake: Can't find any source for 'CCOM_suncc'.
smake: Couldn't make 'CCOM_suncc'.
-- 
Hilsen Harald.

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

Re: Linux Kernel include files

[Harald Arnesen]

David Woodhouse [EMAIL PROTECTED] writes:

   Can you be more specific about why this is a problem? Don't
  we mostly define those crappy types using arch-specific knowledge, as
  'int', 'long', etc?
 
 I recommend you to install Sun Studio and to try to compile star or cdrtools
 using Sun Studio by calling make CCOM_suncc.

 ftp://ftp.berlios.de/pub/star/alpha/
 ftp://ftp.berlios.de/pub/cdrecord/alpha/
 
 You may need to hand edit the file incs/arch-dir/{xconfig.h!rules.conf}
 
 in order to enable the auto-disabled features.
 
 In any case, self reading the error messages from Sun Studio helps more than
 trying to discuss it.

 I have no interest in doing this for myself, and I suspect that if I
 tried it I'd find that Sun Studio doesn't exist for Linux/PowerPC
 anyway. Please just show the error messages.

Apart from the usual whining about GNU make, the error message is:
make: *** No rule to make target `CCOM_suncc'.  Stop.

If I actually install smake, as Jörg recommends, the message becomes:
smake: Can't find any source for 'CCOM_suncc'.
smake: Couldn't make 'CCOM_suncc'.
-- 
Hilsen Harald.

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

Re: Linux Kernel include files

[Harald Arnesen]

[EMAIL PROTECTED] (Joerg Schilling) writes:

 If I actually install smake, as J�rg recommends, the message becomes:
 smake: Can't find any source for 'CCOM_suncc'.
 smake: Couldn't make 'CCOM_suncc'.

 Well, I was in hope that a small typo (in special as the correct spelling is 
 in 
 the file README.compile) should not be a problem.

 You need to use CCOM=suncc 

Then it (star, I haven't tried cdrtools yes) compiles and links fine.
There must be something wrong with your Linux installation.
-- 
Hilsen Harald.

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

Re: Linux Kernel include files

[Harald Arnesen]

Harald Arnesen [EMAIL PROTECTED] writes:

 [EMAIL PROTECTED] (Joerg Schilling) writes:

 If I actually install smake, as J�rg recommends, the message becomes:
 smake: Can't find any source for 'CCOM_suncc'.
 smake: Couldn't make 'CCOM_suncc'.

 Well, I was in hope that a small typo (in special as the correct spelling is 
 in 
 the file README.compile) should not be a problem.

 You need to use CCOM=suncc 

 Then it (star, I haven't tried cdrtools yes) compiles and links fine.
 There must be something wrong with your Linux installation.

FYI, cdrtools also compile and link fine with Sun's C compiler.
-- 
Hilsen Harald.

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

Re: Linux Kernel include files

[Harald Arnesen]

[EMAIL PROTECTED] (Joerg Schilling) writes:

 FYI, cdrtools also compile and link fine with Sun's C compiler.

 M, if you call cdrecord -scanbus, what do you get?

I may have misunderstood your make system. I cd-ed into the cdrtools
directory, ran ./Gmake.linux clean (I had already compiled with GCC),
and then ./Gmake.linux CCOM=suncc. I didn't see any errors at the end of
the make output.

However, what confused me was that the cdrecord binary wasn't removed.
And scrolling back, I see several compile errors from Sun's C compiler.

Shouldn't make clean remove the executable files?
-- 
Hilsen Harald.

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

Re: How to compile linux 0.0.0.1?

[Harald Arnesen]

Leif Sawyer <[EMAIL PROTECTED]> writes:

> > Yeah, but then you have to find the buffalo and that gets 
> > hard.  (Actually Linus used a carabou, but those are even
> > harder to find...)
> 
> Well, I remember back to 0.12ish and the Caribou around here
> (Alaska) were plentiful then.  Ah, those were the days.

They are still plentiful in Norway, and I suspect they are in Finland
as well.

Harald.
-- 
Foreningen for engelsk ord deling kjemper for at sammen satte ord som
leke plass og kjøle skap skal skilles for aldri mer å se hver andre.
Foreningen føler at den langt på vei har lykkes i sitt pioner arbeid.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to compile linux 0.0.0.1?

[Harald Arnesen]

Leif Sawyer [EMAIL PROTECTED] writes:

  Yeah, but then you have to find the buffalo and that gets 
  hard.  (Actually Linus used a carabou, but those are even
  harder to find...)
 
 Well, I remember back to 0.12ish and the Caribou around here
 (Alaska) were plentiful then.  Ah, those were the days.

They are still plentiful in Norway, and I suspect they are in Finland
as well.

Harald.
-- 
Foreningen for engelsk ord deling kjemper for at sammen satte ord som
leke plass og kjle skap skal skilles for aldri mer  se hver andre.
Foreningen fler at den langt p vei har lykkes i sitt pioner arbeid.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: spelling of disc (disk) in /devfs

[Harald Arnesen]

"Richard B. Johnson" <[EMAIL PROTECTED]> writes:

> Webster says (but what did he know), that "disc" is an abbreviation
> for "discount", a variation of "disk", or a "phonograph record".

The "Oxford Advanced Learner's Dictionary of Current English"
(1995 edition) says that a disc is:

(also esp US disk)
1. a flat, thin, round object, eg a coin (he wears an identity disc
   around his neck)
2. a round surface that appears to be flat (the moon's disc)
3. = record (recordings on disc and cassette) see also compact disc
4. = disk 2
5. (anatomy) a layer of cartilage between the bones of the spine

> Disk is even more obscure, It relates to plowing and harrowing.
> However buried in the text is a reference to "round flat plate coated
> with a magnetic substance upon which data for a computer is stored"

And a disk is:

1. (esp US) disc
2. (computing) a circular plate on which data can be recorded in a
   form that can be used by a computer
-- 
Harald Arnesen, Apalløkkveien 23 A, N-0956 Oslo, Norway
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: spelling of disc (disk) in /devfs

[Harald Arnesen]

"Richard B. Johnson" [EMAIL PROTECTED] writes:

 Webster says (but what did he know), that "disc" is an abbreviation
 for "discount", a variation of "disk", or a "phonograph record".

The "Oxford Advanced Learner's Dictionary of Current English"
(1995 edition) says that a disc is:

(also esp US disk)
1. a flat, thin, round object, eg a coin (he wears an identity disc
   around his neck)
2. a round surface that appears to be flat (the moon's disc)
3. = record (recordings on disc and cassette) see also compact disc
4. = disk 2
5. (anatomy) a layer of cartilage between the bones of the spine

 Disk is even more obscure, It relates to plowing and harrowing.
 However buried in the text is a reference to "round flat plate coated
 with a magnetic substance upon which data for a computer is stored"

And a disk is:

1. (esp US) disc
2. (computing) a circular plate on which data can be recorded in a
   form that can be used by a computer
-- 
Harald Arnesen, Apallkkveien 23 A, N-0956 Oslo, Norway
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT?] Coding Style

[Harald Arnesen]

[EMAIL PROTECTED] (Kai Henningsen) writes:

> >   void ThisIsMyDumbassFunctionName
> >
> > if MUCH more difficult to read than
> >
> >   void this_is_my_clear_and_easy_function_name
> 
> I can certainly read the first easier than the second.

So I assume you don't approve of the new German spelling standard,
where nouns with capital letters are optional (don't know if it became
reality, I remember reading that Günther Grass was against it).

For a Norwegian, the second variant is much more readable.
-- 
Harald Arnesen, Apalløkkveien 23 A, N-0956 Oslo, Norway
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT?] Coding Style

[Harald Arnesen]

[EMAIL PROTECTED] (Kai Henningsen) writes:

void ThisIsMyDumbassFunctionName
 
  if MUCH more difficult to read than
 
void this_is_my_clear_and_easy_function_name
 
 I can certainly read the first easier than the second.

So I assume you don't approve of the new German spelling standard,
where nouns with capital letters are optional (don't know if it became
reality, I remember reading that Gnther Grass was against it).

For a Norwegian, the second variant is much more readable.
-- 
Harald Arnesen, Apallkkveien 23 A, N-0956 Oslo, Norway
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/