Linux 4.10-rc4 compile error
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(&pdev->dev, dev_get_msi_domain(&pdev->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
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
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 [0.002306
Re: [git pull] drm fixes for 5.9-rc4
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
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
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
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
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 [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
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
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
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
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
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
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 [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
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
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
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
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
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
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
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
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
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: Regression in v4.5-rc1, bisected to commit 39bfcd5235e0 ("drm/i915: more virtual south bridge detection")
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")
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
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
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&GPL 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
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: Panic with latest git kernel
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
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
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: [PATCH] Remove unnecessarily gendered language
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)
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 fro
Re: [3.9-rc1] very poor interrupt responses
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
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
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: Latest git oopses during boot
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
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: Userspace compiler support of "long long"
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
[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 <[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
[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
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: How to compile linux 0.0.0.1?
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: spelling of disc (disk) in /devfs
"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: [OT?] Coding Style
[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/