search for: ffff0000

...39: init completed in 274us nouveau 0000:02:00.0: DRM: MM: using M2MF for buffer copies nouveau 0000:02:00.0: disp: supervisor 00000010 000002a0 nouveau 0000:02:00.0: disp: Core: @@ -405,7 +405,7 @@ [drm:drm_setup_crtcs [drm_kms_helper]] desired mode 1280x1024 set on crtc 34 (0,0) nouveau: DRM:ffff0000:0000003d: init running... nouveau: DRM:ffff0000:0000003d: init children... -nouveau: DRM:ffff0000:0000003d: init completed in 71us +nouveau: DRM:ffff0000:0000003d: init completed in 68us nouveau: DRM:ffff0000:0000003d: init running... nouveau: DRM:ffff0000:0000003d: init children... nouveau: DR...

Hello, I've just been hit by this old bug which is still present in 4.14: https://bugs.freedesktop.org/show_bug.cgi?id=80675 On MCP79 (ION), when stolen memory is set to 32MB in BIOS, console is blank but X11 works. When the stolen memory is increased to 64MB, console works fine. Bisected it to this: 4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit commit

...but the filter is not active. If I run "tc filter show dev eth0" I get: filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 *flowid 1:20 match 00160000/ffff0000 at 20 filter parent 1: protocol ip pref 100 u32 fh 800::801 order 2049 key ht 800 bkt 0 *flowid 1:11 match 00160000/ffff0000 at 20 I don''t know what''s the meaning of the "*" before flowid is. Because if I add a filter with tc tool i get this extra info not and this fi...

...eth0" command, then the output is like below : filter parent 1: protocol ip pref 1 u32 filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:2 (rule hit 21553629 success 37907) match 00160000/ffff0000 at 20 (success 37907 ) ... My question is : 1. What is "fh 800:" and "fh 800::800" mean ? 2. How I change the value "800" in "fh 800::800" ? I''m guessing this is default value and I need to change that because my filter rule can be more than 0xff...

Hello, it seems, that filtering on nexthdr (TCP/UDP) content, especially src or dst port, is not working. The following has no effect on 2.4.16 or older (even 2.2) kernels: # tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match tcp dst 3128 0xffff police rate 40kbit burst 10k drop flowid :1 Even if # tc filter ls dev eth0 parent ffff: filter protocol ip pref 50 u32 filter protocol

Hello. I have a linux server connected to a gigabit lan, and though that lan to a 768kbps/768kbps DSL modem. I''m trying to shape my webserver running on port 80/443 down to 512kbps, while leaving all other ports alone. The current configuration script that I''m using is as follows: tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 99 tc class add dev

...00000 -> 00100500 > > -nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 00001e00 > > +nouveau 0000:02:00.0: disp: 086c: 00000000 -> 00100a00 > > +nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 0000e800 > > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 > > nouveau 0000:02:00.0: disp: 0878: 00000000 > > nouveau 0000:02:00.0: disp: 0880: 05000000 > > > > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in > > 64MB case. Why? > > > > I get blank screen even with 64MB with video...

...t; is as shown below: ~ # tc filter show dev eth1 filter parent 1: protocol ip pref 2 u32 filter parent 1: protocol ip pref 2 u32 fh ffe: ht divisor 256 filter parent 1: protocol ip pref 2 u32 fh ffe:3e:800 order 2048 key ht ffe bkt 3e flowid 1:13e match 000bcd59/ffffffff at -12 match 123e0000/ffff0000 at -8 filter parent 1: protocol ip pref 2 u32 fh ffe:40:800 order 2048 key ht ffe bkt 40 flowid 1:140 match 000bcd59/ffffffff at -12 match 12400000/ffff0000 at -8 filter parent 1: protocol ip pref 2 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 2 u32 fh 800::800 order 2048 key ht 8...

...; > -nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 00001e00 >>> > +nouveau 0000:02:00.0: disp: 086c: 00000000 -> 00100a00 >>> > +nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 0000e800 >>> > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 >>> > nouveau 0000:02:00.0: disp: 0878: 00000000 >>> > nouveau 0000:02:00.0: disp: 0880: 05000000 >>> > >>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in >>> > 64MB case. Why? >>> > >&g...

...; > -nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 00001e00 >>> > +nouveau 0000:02:00.0: disp: 086c: 00000000 -> 00100a00 >>> > +nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 0000e800 >>> > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 >>> > nouveau 0000:02:00.0: disp: 0878: 00000000 >>> > nouveau 0000:02:00.0: disp: 0880: 05000000 >>> > >>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in >>> > 64MB case. Why? >>> > >&g...

...0 htb rate 64kbit ceil 64kbit prio 0 tc class add dev $d parent 1:2 classid 1:12 htb rate 1024mbit ceil 1024mbit prio 0 done Http Filter ( looks for (Source)Port 80 on Offset 20 in the Ip Packet (Httpserver Answer) ): tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match u32 0x500000 0xffff0000 at 20 classid 1:10 This Filter is working and the http download on the Firewall Side is resticted to 64 kbit as you can see below. tc -s filter show dev eth0 : filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 filter parent 1: protocol ip...

...: disp: 086c: 00000000 -> 00100500 > -nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 00001e00 > +nouveau 0000:02:00.0: disp: 086c: 00000000 -> 00100a00 > +nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 0000e800 > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 > nouveau 0000:02:00.0: disp: 0878: 00000000 > nouveau 0000:02:00.0: disp: 0880: 05000000 > > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in 64MB > case. Why? > > I get blank screen even with 64MB with video=1280x1024-8 kernel parameter. >...

...0500 >> > -nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 00001e00 >> > +nouveau 0000:02:00.0: disp: 086c: 00000000 -> 00100a00 >> > +nouveau 0000:02:00.0: disp: 0870: 0000e900 -> 0000e800 >> > nouveau 0000:02:00.0: disp: 0874: 00000000 -> ffff0000 >> > nouveau 0000:02:00.0: disp: 0878: 00000000 >> > nouveau 0000:02:00.0: disp: 0880: 05000000 >> > >> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in >> > 64MB case. Why? >> > >> > I get blank scre...

...<TAbort- <MAbort- >SERR- <PERR- Latency: 32 (2500ns min, 2500ns max), Cache Line Size 08 Interrupt: pin A routed to IRQ 169 Region 0: I/O ports at bc00 [size=128] Region 1: Memory at febff400 (32-bit, non-prefetchable) [size=512] Expansion ROM at ffff0000 [disabled] [size=64K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable+ DSel=0 DScale=2 PME- TIA -- Eduardo Grosclaude Universidad Nacional del Comahue Neuquen, A...

...: protocol ip pref 10 u32 fh 3:1:800 order 2048 key ht 3 bkt 1 link 4: match 0a010100/ffffff00 at 16 hash mask 000000ff at 16 filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 link 3: match 0a010000/ffff0000 at 16 hash mask 0000ff00 at 16 -- When dealing with a slow pipe, never underestimate the throughput of the postal system. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

...-p 0001f000 08:03 6076 /usr/lib/ld-2.17.so Apr 25 05:13:16 z9m9z dovecot: dict: Error: bee46000-bee67000 rw-p 00000000 00:00 0 [stack] Apr 25 05:13:16 z9m9z dovecot: dict: Error: beec5000-beec6000 r-xp 00000000 00:00 0 [sigpage] Apr 25 05:13:16 z9m9z dovecot: dict: Error: ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors] Which go away if I setenforce 0. :( myservice_policy.te has: module myservice_policy 1.0; require { type dovecot_t; type mysqld_etc_t; type mysqld_t; class unix_stream_socket connectto; class file { getattr open read...

I''ve seen a recent report claiming that it works: http://linux-bsd-sharing.blogspot.pt/2012/10/howto-xen-413-windows-8-hvm-domu-with.html However, in my case, with a slightly different HW configuration the story is totally different. :-（ My config: HW: I7-3770 + AsRock H77M-ITX board Dom0: Debian Wheezy stock xen (v4.1.3) + Debian stock kernel (3.2.x / 3.6.x) 64 bit version. Note that

...run: [32767.14] pri=-64 flags=0 cpu=14 (XEN) CPU[15] sort=498, sibling=00000000,00000000,00000000,0000c000, core=00000000,00000000,00000000,0000ffff (XEN) run: [32767.15] pri=-64 flags=0 cpu=15 (XEN) CPU[16] sort=495, sibling=00000000,00000000,00000000,00030000, core=00000000,00000000,00000000,ffff0000 (XEN) run: [32767.16] pri=-64 flags=0 cpu=16 (XEN) CPU[17] sort=496, sibling=00000000,00000000,00000000,00030000, core=00000000,00000000,00000000,ffff0000 (XEN) run: [32767.17] pri=-64 flags=0 cpu=17 (XEN) CPU[18] sort=805, sibling=00000000,00000000,00000000,000c0000, core=00000000,00000000,000...

...2798 I have almost 3000 items in FORWARD chain in mangle table. Now I am switching to IPMARK target which can mangle packets automaticaly based on their src or dst address. IP address is converted to hex (ex. 10.11.12.13->0a0b0c0d), then 16 less importants bits are left (by and operation with $ffff0000- so it is 0c0d) and then I can OR with some number. I use class 192.168.0.0/16 for clients and I can''t change that. So I want to create tree like this: --------------- 1:0 ----------- / | \ 1:0c0d 1:xxxx...

Le mardi 25 avril 2017 ? 11:07 +0200, Robert Moskowitz a ?crit : > > On 04/25/2017 10:58 AM, Laurent Wandrebeck wrote: > > Le mardi 25 avril 2017 ? 10:39 +0200, Robert Moskowitz a ?crit : > >> Thanks Laurent. You obviously know a LOT more about SELinux than I. I > >> pretty much just use commands and not build policies. So I need some > >> more