Re: [kernel/f21] Make sure acpi brightness_switch is disabled (like forever in Fedora)
by Hans de Goede
Hi Josh,
On 07/28/2014 07:04 PM, Josh Boyer wrote:
> commit e6fe382d1d53d4cdf9b544729dc823d4eab0217c
> Author: Josh Boyer <jwboyer(a)fedoraproject.org>
> Date: Mon Jul 28 13:03:01 2014 -0400
>
> Make sure acpi brightness_switch is disabled (like forever in Fedora)
>
> Upstream reverted the change to turn the ACPI brightness_switch_enabled
> parameter off by default. Revert the revert so we go back to the state
> Fedora has traditionally been in.
Ack, I was planning on doing this myself but you beat me to it, thanks for
taking care of this.
Note that 3.17 will have this patch:
https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?...
Which fixes the 2 steps being taken for one keypress problem while
keeping the acpi brightness_switch behavior enabled, so that people who
have an acpi-video controlled backlight and a userspace which does not
do backlight control (e.g. windowmaker).
So for 3.17 we should IMHO drop the revert-revert and stick with
upstream behavior.
Alternatively we could apply that patch now instead of the revert-revert.
Regards,
Hans
8 years, 4 months
fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg
The other day I was running the stock fedora kernel on my ip
forwarding setup, to see what the performance was, and the performance
wasn't very good.
system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad
port 82580 adapters (12 ports). Traffic is bidirectional 64 byte
packets being forwarded and received on each port, basically port to
port routing. I am only using 12 flows currently.
The driver is igb, and I am using an affinity script that lines up
each pair of ports that are forwarding traffic into optimal
configurations for cache locality. I am also disabling
remote_node_defrag_ratio to stop cross node traffic.
With the fedora default kernel from F14 it appears that
CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if
I stop iptables service.
perf showed netfilter being prominent, and removing it gives me much
higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
good thing to be able to disable netfilter if you want to?
Jesse
8 years, 6 months
Trouble cross compiling for powerpc
by Paul Bolle
I'm having trouble cross compiling on an up-to-date x64_64 F20 machine.
make CROSS_COMPILE=powerpc64-linux-gnu- ARCH=powerpc drivers/dma/ppc4xx/adma.o
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CALL scripts/checksyscalls.sh
CC drivers/dma/ppc4xx/adma.o
{standard input}: Assembler messages:
{standard input}:4475: Error: junk at end of line: `1'
{standard input}:4616: Error: junk at end of line: `1'
{standard input}:4626: Error: junk at end of line: `1'
{standard input}:4649: Error: junk at end of line: `1'
make[1]: *** [drivers/dma/ppc4xx/adma.o] Error 1
make: *** [drivers/dma/ppc4xx/adma.o] Error 2
make CROSS_COMPILE=powerpc64-linux-gnu- ARCH=powerpc CFLAGS_adma.o="-S" drivers/dma/ppc4xx/adma.o
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CALL scripts/checksyscalls.sh
CC drivers/dma/ppc4xx/adma.o
sed -n -e "4475p; 4616p; 4626p; 4649p" drivers/dma/ppc4xx/adma.o
mfcr 10,1
mfcr 10,1
mfcr 10,1
mfcr 10,1
Anyone else seeing this? Is powerpc64-linux-gnu-gcc choking on the
assembler it generates itself, or am I doing something wrong?
Paul Bolle
8 years, 10 months
Enable Baytrail devices in kernel builds
by Bastien Nocera
Hey,
This driver, as discussed here:
http://article.gmane.org/gmane.linux.kernel.input/35190
got merged last year.
It's the driver for buttons integrated in Baytrail tablets, and should
make power and volume buttons work on those devices.
Furthermore, we should also enable the Baytrail SoC sound devices. There's a
number of config items for this.
You'll find both enablements in the ill-fated c72e049493b3f4f691a91722ae93f57a916d75b9 commit.
Cheers
8 years, 10 months
Uhhuh - Dazed and confused, but trying to continue :)
by poma
Salutem
This happened only on thaw from S4 aka hibernate.
What should be "strange power saving mode" these messages relate!?
[ 208.252986] Uhhuh. NMI received for unknown reason 3d on CPU 0.
[ 208.252991] Do you have a strange power saving mode enabled?
[ 208.252992] Dazed and confused, but trying to continue
3.18.3-200.fc21.x86_64
poma
8 years, 10 months
Enabling sun8i support in the Fedora kernels
by Hans de Goede
Hi,
I noticed that sun8i support is not enabled in the rawhide arm kernels,
sun8i / A23 is supported by upstream u-boot now, so it would be good
to also enable it in the Fedora kernels, then Fedora should just work
on A23 based devices.
Regards,
Hans
8 years, 10 months
Re: Radeon driver with FC20 latest kernel update
by poma
On 20.01.2015 15:46, Andrew R Paterson wrote:
> On Tuesday 20 January 2015 14:31:09 Andrew R Paterson wrote:
>> On Tuesday 20 January 2015 15:10:15 poma wrote:
>>> On 20.01.2015 14:44, Andrew R Paterson wrote:
>>>> On Tuesday 20 January 2015 14:31:32 poma wrote:
>>>>> On 20.01.2015 12:52, Andrew R Paterson wrote:
>>>>>> Hi,
>>>>>> I am running fedora 20 X86_64
>>>>>>
>>>>>> I have an Intel Processor:
>>>>>> Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz.
>>>>>>
>>>>>> I have an AMD radeon based GPU card :
>>>>>> Advanced Micro Devices, Inc. [AMD/ATI] RV535 [Radeon X1650 PRO]
>>>>>> (Secondary)
>>>>>> (rev 9e)
>>>>>>
>>>>>> I have two monitors :
>>>>>> ACER Technolgies – on DVI-0 (1920x1080)
>>>>>> Viewsonic Corporation on DVI-1 (1920x1200)
>>>>>>
>>>>>> They are (were!) driven by the radeon module :
>>>>>>
>>>>>> lsmod :-
>>>>>> .....
>>>>>> radeon 1496040 2
>>>>>> .....
>>>>>> i2c_algo_bit 13257 1 radeon
>>>>>> .....
>>>>>> drm_kms_helper 89555 1 radeon
>>>>>> ttm 80807 1 radeon
>>>>>> .....
>>>>>> drm 296901 5 ttm,drm_kms_helper,radeon
>>>>>>
>>>>>>
>>>>>> /var/log/messages shows:
>>>>>>
>>>>>> radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 -
>>>>>> 0x000000001FFFFFFF
>>>>>> (512M used)
>>>>>> radeon 0000:01:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
>>>>>> [drm] Detected VRAM RAM=512M, BAR=256M
>>>>>> [drm] RAM width 128bits DDR
>>>>>>
>>>>>> X server log shows:
>>>>>>
>>>>>> [ 88.037] (II) Loader magic: 0x80dd00
>>>>>> [ 88.037] (II) Module ABI versions:
>>>>>> [ 88.037] X.Org ANSI C Emulation: 0.4
>>>>>> [ 88.037] X.Org Video Driver: 14.1
>>>>>> [ 88.037] X.Org XInput driver : 19.2
>>>>>> [ 88.037] X.Org Server Extension : 7.0
>>>>>> [ 88.037] (II) xfree86: Adding drm device (/dev/dri/card0)
>>>>>> [ 88.040] (--) PCI:*(0:1:0:0) 1002:71c1:174b:0840 rev 158, Mem @
>>>>>> 0xd0000000/268435456, 0xfdaf0000/65536, I/O @ 0x0000ae00/256, BIOS @
>>>>>> 0x????????/131072
>>>>>> [ 88.040] (--) PCI: (0:1:0:1) 1002:71e1:174b:0841 rev 158, Mem @
>>>>>> 0xfdae0000/65536, BIOS @ 0x????????/65536
>>>>>> ....
>>>>>> ....
>>>>>> [ 88.058] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
>>>>>> [ 88.058] (II) FBDEV: driver for framebuffer: fbdev
>>>>>> [ 88.058] (II) VESA: driver for VESA chipsets: vesa
>>>>>> [ 88.058] (++) using VT number 1
>>>>>> .....
>>>>>> .....
>>>>>> [ 88.059] (II) [KMS] Kernel modesetting enabled.
>>>>>> [ 88.059] (WW) Falling back to old probe method for modesetting
>>>>>> [ 88.059] (WW) Falling back to old probe method for fbdev
>>>>>> [ 88.059] (II) Loading sub module "fbdevhw"
>>>>>> [ 88.059] (II) LoadModule: "fbdevhw"
>>>>>> [ 88.059] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
>>>>>> [ 88.060] (II) Module fbdevhw: vendor="X.Org Foundation"
>>>>>> [ 88.060] compiled for 1.14.4, module version = 0.0.2
>>>>>> [ 88.060] ABI class: X.Org Video Driver, version 14.1
>>>>>> [ 88.060] (WW) Falling back to old probe method for vesa
>>>>>> [ 88.060] (II) RADEON(0): Creating default Display subsection in
>>>>>> Screen
>>>>>> section
>>>>>> "Default Screen Section" for depth/fbbpp 24/32
>>>>>> [ 88.060] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
>>>>>> [ 88.060] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32
>>>>>> bpp
>>>>>> pixmaps)
>>>>>> [ 88.060] (==) RADEON(0): Default visual is TrueColor
>>>>>> [ 88.060] (==) RADEON(0): RGB weight 888
>>>>>> [ 88.060] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
>>>>>> [ 88.060] (--) RADEON(0): Chipset: "ATI Radeon X1650" (ChipID =
>>>>>> 0x71c1)
>>>>>> .....
>>>>>> ________________________________________________
>>>>>> All worked well up to kernel 3.17.7-200.fc20.x86_64.
>>>>>> ________________________________________________
>>>>>>
>>>>>> The recent update to kernel 3.17.8-200.fc20.x86_64
>>>>>> results in radeon.ko failing to load.
>>>>>>
>>>>>> /var/log/messages shows:
>>>>>>
>>>>>> [drm:radeon_init] *ERROR* No UMS support in radeon module!
>>>>>>
>>>>>> %modrpobe radeon gives same message.
>>>>>>
>>>>>> My monitors are then in low res mirorred mode (ugh!)
>>>>>>
>>>>>> X server log shows:
>>>>>> ....
>>>>>> [ 13345.844] (II) Loader magic: 0x80dd00
>>>>>> [ 13345.844] (II) Module ABI versions:
>>>>>> [ 13345.844] X.Org ANSI C Emulation: 0.4
>>>>>> [ 13345.844] X.Org Video Driver: 14.1
>>>>>> [ 13345.844] X.Org XInput driver : 19.2
>>>>>> [ 13345.844] X.Org Server Extension : 7.0
>>>>>> [ 13345.844] (II) xfree86: Adding drm device (/dev/dri/card0)
>>>>>> [ 13345.844] setversion 1.4 failed
>>>>>> [ 13345.848] (--) PCI:*(0:1:0:0) 1002:71c1:174b:0840 rev 158, Mem @
>>>>>> 0xd0000000/268435456, 0xfdaf0000/65536, I/O @ 0x0000ae00/256, BIOS @
>>>>>> 0x????????/131072
>>>>>> [ 13345.848] (--) PCI: (0:1:0:1) 1002:71e1:174b:0841 rev 158, Mem @
>>>>>> 0xfdae0000/65536, BIOS @ 0x????????/65536
>>>>>> .......
>>>>>>
>>>>>> I understand UMS is User ModeSetting – which according to a quick
>>>>>> browse
>>>>>> of
>>>>>> the source for the radeon module means CONFIG_DRM_RADEON_UMS is not
>>>>>> set.
>>>>>> Then I came across comments to the effect that this has been
>>>>>> deprecated
>>>>>> (a
>>>>>> mysterious word akin to legal-speak!) presumably replaced by KMS.
>>>>>>
>>>>>> Has anybody got any clues how I can get the radeon driver loading and
>>>>>> working again?
>>>>>> Or even if its a bug whether it will soon be fixed?
>>>>>>
>>>>>> Many Thanks
>>>>>>
>>>>>> Andy
>>>>>
>>>>> $ grep modeset /etc/modprobe.d/* /proc/cmdline
>>>>
>>>> Hi poma,
>>>>
>>>> grep modeset /etc/modprobe.d/* =
>>>> /etc/modprobe.d/radeon-kms.conf:options radeon modeset=0
>>>>
>>>> grep modeset /proc/cmdline =
>>>> nothing!
>>>>
>>>> Thanks
>>>
>>> # sed -i s/0/1/ /etc/modprobe.d/radeon-kms.conf
>>
>> Hi poma
>>
>> that did it thanks
>>
>> /etc/modprobe.d/radeon-kms.conf:options radeon modeset=1
>>
>> I mind you I still get the initial:
>> [drm:radeon_init] *ERROR* No UMS support in radeon module!
>> And the plymouth splash screen goes from one mode to another and ain't what
>> it used to be!) - but that doesn't matter. On loading, the kernel sorts
>> things out.
>>
>> A assume if I now reboot into the previous kernel, that wont work - I'll
>> just do it out of curiosity - but no probs - I'll now stick with
>> 3.17.8-200.fc20.x86_64.
>>
See whether this can smooth plymouth
# dracut -f --kver 3.17.8-300.fc21.x86_64
# reboot
>> Thanks
>> Andy
> rebooted into previous kernel - no probs!
> I assume thats because previous kernel supported both ums and kms????
> Regards
> Andy
>
What is supported with certain version you can ask Alex Deucher at
X.org ATI driver maintainers
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Don't see any Fedora announcement related to it at
https://admin.fedoraproject.org/updates/FEDORA-2015-0515/kernel-3.17.8-20...
8 years, 10 months
n_sectors mismatch - revalidation failed - resume S3
by poma
Salutem
I saw a couple of open and closed reports as this is resolved, however here it is,
only on resume from S3 aka suspend:
[ 126.580725] ata1.00: n_sectors mismatch 1953525168 != 1953516911
[ 126.580732] ata1.00: old n_sectors matches native, probably late HPA lock, will try to unlock HPA
[ 126.580737] ata1.00: revalidation failed (errno=-5)
with 'libata.ignore_hpa=1' doesn't appear.
3.18.3-200.fc21.x86_64
poma
Ref.
https://www.kernel.org/doc/Documentation/kernel-parameters.txt
libata.ignore_hpa= [LIBATA] Ignore HPA limit
libata.ignore_hpa=0 keep BIOS limits (default)
libata.ignore_hpa=1 ignore limits, using full disk
8 years, 10 months
