* Re: AHCI suspend support
From: Dominic ES. Ijichi @ 2006-04-09 14:35 UTC (permalink / raw)
To: linux-ide
we're still waiting for pata disk on sata controller suspend support pretty please! last i heard randy dunlap was going to have a go but he's gone very quiet.
dom
----- Bastian Blank <waldi@debian.org> wrote:
> Hi Jeff
>
> Do you know what the current state of suspend support in the AHCI
> driver
> is? There was a patch from Hannes Reinecke some weeks ago.
>
> Bastian
>
> --
> But Captain -- the engines can't take this much longer!
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFH] Exploration of an alternative diff_delta() algorithm
From: Peter Eriksen @ 2006-04-09 14:31 UTC (permalink / raw)
To: git
Greetings Gitlings,
I've been trying to implement an alternative algorithm
for diff_delta(). I'm getting close to something that
works, but now I'm stuck! I think it has something to
do with pack-objects.c, but I'm not sure. Here's the
first test that fails:
*** t5500-fetch-pack.sh ***
* FAIL 1: 1st pull
git-fetch-pack -v .. B A > log.txt 2>&1
* FAIL 2: fsck
git-fsck-objects --full > fsck.txt 2>&1
* FAIL 3: new object count after 1st pull
test 33 = 0
* FAIL 4: minimal count
test 33 = 0
* FAIL 5: repack && prune-packed in client
(git-repack && git-prune-packed)2>>log.txt
* ok 5: 2nd pull
* ok 6: fsck
* FAIL 7: new object count after 2nd pull
test 192 = 198
* FAIL 8: minimal count
test 192 = 198
* FAIL 9: repack && prune-packed in client
(git-repack && git-prune-packed)2>>log.txt
* ok 9: 3rd pull
* ok 10: fsck
* FAIL 11: new object count after 3rd pull
test 3 = 228
* FAIL 12: minimal count
test 3 = 30
* failed 8 among 12 test(s)
I've been looking all around the current diff_delta(), and I
can't see, what I'm missing. Any ideas? The file is meant to
replace the current diff-delta.c.
Peter
----->8--diff-delta.c----->8----
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include "delta.h"
#define BASE 257
#define PREFIX_SIZE 3
#define SIZE 10
#define HASH_TABLE_SIZE (1<<SIZE)
#define DELTA_SIZE (1024 * 1024)
unsigned int init_hash(unsigned char* data) {
return data[0]*BASE*BASE + data[1]*BASE + data[2];
}
unsigned int hash(unsigned char* data, unsigned int hash) {
return (hash - data[-1]*BASE*BASE)*BASE + data[2];
}
#define GR_PRIME 0x9e370001
#define HASH(v) ((v * GR_PRIME) >> (32 - SIZE))
struct entry {
char file;
char* offset;
};
void flush(struct entry* table) {
memset(table, 0, HASH_TABLE_SIZE * sizeof(struct entry));
}
int same_prefixes(char* data1, char* data2) {
return !memcmp(data1, data2, PREFIX_SIZE);
}
void encode_add(char* out, int* outpos, char* version_start, char* version_copy) {
unsigned int size = version_copy - version_start;
if (!size) return;
int pos = *outpos;
while(size > 127) {
out[pos++] = 127;
memcpy(out + pos, version_start, 127);
pos += 127;
version_start += 127;
size -= 127;
}
out[pos++] = size;
memcpy(out + pos, version_start, size);
pos += size;
*outpos = pos;
}
void encode_copy(char* out, int* outpos, int offset, int size) {
int pos = (*outpos) + 1;
int i = 0x80;
if (offset & 0xff) { out[pos++] = offset; i |= 0x01; }
offset >>= 8;
if (offset & 0xff) { out[pos++] = offset; i |= 0x02; }
offset >>= 8;
if (offset & 0xff) { out[pos++] = offset; i |= 0x04; }
offset >>= 8;
if (offset & 0xff) { out[pos++] = offset; i |= 0x08; }
if (size & 0xff) { out[pos++] = size; i |= 0x10; }
size >>= 8;
if (size & 0xff) { out[pos++] = size; i |= 0x20; }
out[*outpos] = i;
*outpos = pos;
}
void encode_size(char* out, int* outpos, unsigned long size) {
int pos = *outpos;
out[pos] = size;
size >>= 7;
while (size) {
out[pos++] |= 0x80;
out[pos] = size;
size >>= 7;
}
*outpos = ++pos;
}
void *diff_delta(void *from_buf, unsigned long from_size,
void *to_buf, unsigned long to_size,
unsigned long *delta_size,
unsigned long max_size) {
int index;
int l;
char* base = from_buf;
char* version = to_buf;
unsigned long base_size = from_size;
unsigned long version_size = to_size;
char* base_copy = base;
char* version_copy = version;
struct entry* table = calloc(HASH_TABLE_SIZE, sizeof(struct entry));
//int delta_alloc = DELTA_SIZE;
char* delta = malloc(DELTA_SIZE);
int deltapos = 0;
char* base_top = base + base_size;
char* version_top = version + version_size;
encode_size(delta, &deltapos, base_size);
encode_size(delta, &deltapos, version_size);
char* base_offset = base;
char* version_offset = version;
unsigned int base_hash = init_hash(base);
unsigned int version_hash = init_hash(version);
char* version_start = version;
while(base_offset + PREFIX_SIZE < base_top &&
version_offset + PREFIX_SIZE < version_top) {
// step2:
index = HASH(base_hash);
switch (table[index].file) {
case '\0': {
table[index].file = 'b';
table[index].offset = base_offset;
break;
}
case 'v': {
if (same_prefixes(base_offset, table[index].offset)) {
base_copy = base_offset;
version_copy = table[index].offset;
goto step3;
} else break;
}
case 'b': break;
default: printf("AAAAAARGH 2b\n");
}
index = HASH(version_hash);
switch (table[index].file) {
case '\0': {
table[index].file = 'v';
table[index].offset = version_offset;
break;
}
case 'b': {
if (same_prefixes(table[index].offset, version_offset)) {
base_copy = table[index].offset;
version_copy = version_offset;
goto step3;
} else break;
}
case 'v': break;
default: printf("AAAAAARGH 2v\n");
}
base_offset++;
version_offset++;
base_hash = hash(base_offset, base_hash);
version_hash = hash(version_offset, version_hash);
continue; // goto step2;
step3:
l = 0;
while(base_copy[l] == version_copy[l]) l++;
base_offset = base_copy + l;
version_offset = version_copy + l;
/*
// Make sure we don't run out of delta buffer when encoding.
if((delta_alloc - deltapos) <
(version_start - version_copy) + 1 + 8 + (PREFIX_SIZE + 1)) {
delta_alloc = delta_alloc * 3 / 2;
delta = (char*) realloc(delta, delta_alloc);
}
*/
if(max_size && deltapos > max_size) {
free(delta);
free(table);
return NULL;
}
// step4:
encode_add(delta, &deltapos, version_start, version_copy);
encode_copy(delta, &deltapos, base_copy - base, l);
// step5:
flush(table);
version_start = version_offset;
base_hash = init_hash(base_offset);
version_hash = init_hash(version_offset);
} // goto step2;
encode_add(delta, &deltapos, version_start, version + version_size);
*delta_size = deltapos;
free(table);
return delta;
}
^ permalink raw reply
* Socket udev events (noobie)
From: Sting Zax @ 2006-04-09 14:27 UTC (permalink / raw)
To: linux-hotplug
Hello,
I saw that in udev.c , when getting socket events
(name_loop->name is "socket:"), than
we call pass_env_to_socket and not runn the program is
in all other cases , where the program name is in
fact name_loop->name (by calling run_program).
My question is : which are the eventes which their name
is "socket:"?
regards,
Sting
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [PATCH] Unaligned accesses in the ethernet bridge
From: Adrian Bunk @ 2006-04-09 14:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Peter Chubb, linux-kernel, netdev
In-Reply-To: <20060407165711.1df5b52e@dxpl.pdx.osdl.net>
On Fri, Apr 07, 2006 at 04:57:11PM -0700, Stephen Hemminger wrote:
> On Thu, 6 Apr 2006 22:37:08 +0200
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > On Thu, Mar 23, 2006 at 01:06:02PM +1100, Peter Chubb wrote:
> > >
> > > I see lots of
> > > kernel unaligned access to 0xa0000001009dbb6f, ip=0xa000000100811591
> > > kernel unaligned access to 0xa0000001009dbb6b, ip=0xa0000001008115c1
> > > kernel unaligned access to 0xa0000001009dbb6d, ip=0xa0000001008115f1
> > > messages in my logs on IA64 when using the ethernet bridge with 2.6.16.
> > >
> > >
> > > Appended is a patch to fix them.
> >
> >
> > I see this patch already made it into 2.6.17-rc1.
> >
> > It seems to be a candidate for 2.6.16.3, too?
> > If yes, please submit it to stable@kernel.org.
>
> The code that caused this was new in 2.6.17
Ah sorry, Peter's "when using the ethernet bridge with 2.6.16" confused
me.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* [patch] support HP Compaq Presario B2800 laptop with AD1986A codec
From: Coywolf Qi Hunt @ 2006-04-09 14:22 UTC (permalink / raw)
To: tiwai; +Cc: linux-kernel, alsa-devel, akpm
This adds the support for HP Compaq Presario B2800 laptop with AD1986A codec.
Signed-off-by: Coywolf Qi Hunt <qiyong@freeforge.net>
---
diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c
index 2bfe37e..921118f 100644
--- a/sound/pci/hda/patch_analog.c
+++ b/sound/pci/hda/patch_analog.c
@@ -801,6 +801,8 @@ static struct hda_board_config ad1986a_c
.config = AD1986A_LAPTOP_EAPD }, /* Samsung R65-T2300 Charis */
{ .pci_subvendor = 0x1043, .pci_subdevice = 0x1213,
.config = AD1986A_LAPTOP_EAPD }, /* ASUS A6J */
+ { .pci_subvendor = 0x103c, .pci_subdevice = 0x30af,
+ .config = AD1986A_LAPTOP_EAPD }, /* HP Compaq Presario B2800 */
{}
};
^ permalink raw reply related
* [patch] support HP Compaq Presario B2800 laptop with AD1986A codec
From: Coywolf Qi Hunt @ 2006-04-09 14:22 UTC (permalink / raw)
To: tiwai; +Cc: linux-kernel, alsa-devel, akpm
This adds the support for HP Compaq Presario B2800 laptop with AD1986A codec.
Signed-off-by: Coywolf Qi Hunt <qiyong@freeforge.net>
---
diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c
index 2bfe37e..921118f 100644
--- a/sound/pci/hda/patch_analog.c
+++ b/sound/pci/hda/patch_analog.c
@@ -801,6 +801,8 @@ static struct hda_board_config ad1986a_c
.config = AD1986A_LAPTOP_EAPD }, /* Samsung R65-T2300 Charis */
{ .pci_subvendor = 0x1043, .pci_subdevice = 0x1213,
.config = AD1986A_LAPTOP_EAPD }, /* ASUS A6J */
+ { .pci_subvendor = 0x103c, .pci_subdevice = 0x30af,
+ .config = AD1986A_LAPTOP_EAPD }, /* HP Compaq Presario B2800 */
{}
};
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply related
* [ALSA - driver 0001703]: NVidia CK804 - Realtek ALC850 rev 0 - passthrough not working
From: bugtrack @ 2006-04-09 14:22 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1703>
======================================================================
Reported By: alsarealist
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1703
Category: PCI - intel8x0
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: self burned
Kernel Version:
======================================================================
Date Submitted: 01-03-2006 18:42 CET
Last Modified: 04-09-2006 16:22 CEST
======================================================================
Summary: NVidia CK804 - Realtek ALC850 rev 0 - passthrough
not working
Description:
Pass-through with xine is not working.
PCM Stereo downmix works fine
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio
Controller (rev a2)
gcc (GCC) 4.0.2
alsa version 1.0.11rc2
Linux 2.6.15
======================================================================
----------------------------------------------------------------------
alsarealist - 04-09-06 14:31
----------------------------------------------------------------------
Giving up frustrated - DTS, Dolby 5.1 seems not to be possible. Stay an
stereo.
Closing case.
----------------------------------------------------------------------
rlrevell - 04-09-06 16:22
----------------------------------------------------------------------
You have to use a stereo .wav file for this, a 6 channel one won't work.
SPDIF only supports 2 channels unless the signal is AC3 encoded.
% aplay -Dplug:spdif somefile.wav
Issue History
Date Modified Username Field Change
======================================================================
01-03-06 18:42 alsarealist New Issue
01-03-06 18:42 alsarealist Distribution => self burned
01-03-06 19:05 rlrevell Note Added: 0007403
01-04-06 01:45 alsarealist Note Added: 0007409
01-04-06 17:11 tiwai Note Added: 0007436
01-04-06 17:32 alsarealist File Added: asound.state
01-04-06 17:33 alsarealist Note Added: 0007443
01-04-06 17:38 alsarealist File Added: proc-asound
01-04-06 17:42 alsarealist Note Added: 0007447
01-04-06 23:11 alsarealist Note Added: 0007459
01-05-06 20:00 tiwai Note Added: 0007477
01-06-06 01:03 alsarealist Note Added: 0007486
04-09-06 14:31 alsarealist Note Added: 0009179
04-09-06 16:22 rlrevell Note Added: 0009180
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: A failed-disk-how-to anywhere?
From: Brad Campbell @ 2006-04-09 14:19 UTC (permalink / raw)
To: Martin Stender; +Cc: linux-raid
In-Reply-To: <C1F5413C-E9AB-4331-A901-1FBB645719DF@stender.com>
Martin Stender wrote:
> Hi there!
>
> I have two identical disks sitting on a Promise dual channel IDE
> controller. I guess both disks are primary's then.
>
> One of the disks have failed, so I bought a new disk, took out the
> failed disk, and put in the new one.
> That might seem a little naive, and apparently it was, since the system
> won't boot up now.
> It boots fine, when only the old, healthy disk is connected.
>
> By the way, all three partitions are raided - including /boot ...
>
> Anyway, I have removed the old disk from the Raid with:
> #mdadm /dev/mdo --remove /dev/hde1
> #mdadm /dev/md1 --remove /dev/hde2
> #mdadm /dev/md2 --remove /dev/hde3
>
> - but the the problem persists.
>
> I can't seem to find a decent 'How-To' - so how it this supposed to be
> done?
A little more info would be helpful. How does the machine boot? How are your other disks configured?
Are you booting off the Promise board or on-board controller (making assumptions given your promise
appears to contain hde, I'm assuming hd[abcd] are on board somewhere..)
I'm going to take a wild stab in the dark now..
My initial thought would be you have hde and hdg in a raid-1 and nothing on the on-board
controllers. hde has failed and when you removed it your controller tried the 1st disk it could find
(hdg) to boot of.. Bingo.. away we go.
You plug a new shiny disk into hde and now the controller tries to boot off that, except it's blank
and therefore a no-go.
I'd either try and force the controller to boot off hdg (which might be a controller bios option) or
swap hde & hdg.. then it might boot and let you create your partitions on hdg and then add it back
into the mirror.
How close did I get ?
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
^ permalink raw reply
* Re: [RFC] Hypercalls from HVM guests
From: Keir Fraser @ 2006-04-09 14:09 UTC (permalink / raw)
To: Nakajima, Jun; +Cc: Steve Ofsthun, xen-devel
In-Reply-To: <7F740D512C7C1046AB53446D37200173078AF219@scsmsx402.amr.corp.intel.com>
On 9 Apr 2006, at 14:56, Nakajima, Jun wrote:
> This is a different question, and I think detecting a virtual device
> (i.e. virtual block device, NIC) or chipset would be a cleaner way at
> this point. And that would be proper for the patch that Steve mentioned
> (we wrote it). The fact that it's running on a hypervisor does not
> necessarily guarantee presence of such virtual devices (in fact they
> don't exist today ;-).
>
> If we really need to tell if we are running on a hypervisor at a very
> early point or even in user-mode, I think CPUID with "an unused index"
> would be the simplest, but so far I haven't seen any usage models that
> really require that. If we want to add virtualization hints for
> processor architectures (e.g. MMU) in guests, it would be needed.
Executing hypercalls via an indirection page as we do for
paravirtualised guests is an attractive idea. That would require more
than just 'are we AMD or Intel' and it would be nice to have that
future-proofing level of indirection in the initial implementation. We
could do that via the PCI device too (e.g., use a BAR) though that
doesn't seem so clean to me.
-- Keir
^ permalink raw reply
* Re: [parisc-linux] Re: + parisc-add-ptr-compatpatch.patch added to -mm tree
From: Carlos O'Donell @ 2006-04-09 14:09 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Kyle McMartin, Andrew Morton, parisc-linux
In-Reply-To: <20060409053716.GA18611@elte.hu>
On 4/9/06, Ingo Molnar <mingo@elte.hu> wrote:
> > Due to a complete lack of useful atomic operations on parisc, the way
> > I envisioned implementing the routines was serializing all futex ops
> > on a kernel spinlock. Since it's a userspace address, we couldn't use
> > an atomic hash unless we found the physical address behind it, so just
> > one spinlock would do... Of course, I'm probably missing something
> > critical here, though.
>
> if userspace doesnt do atomic ops then the solution should be relatively
> easy: make glibc always call into the kernel, and then the kernel-level
> futex.h ops can be implemented in a lockless manner (i.e. not even a
> spinlock is needed) and you'll get (pretty scalable) futex
> functionality. The in-kernel futex hash-bucket spinlocks take care of
> locking.
HPPA has a light-weight kernel syscall that does
atomic-compare-and-swap, and indeed this is what we use for our NPTL
implementation. We can use that *or* call into the kernel for
arbitration. The atomic-compare-and-swap also uses a hash-bucket of
spinlocks on SMP systems. We hash on a virtual address so it scales
nicely. Not forever though. Some analysis to see which is faster
should be done. I think we will always win with the light-weight
syscall.
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* [PATCH] fbdev: Use logo with depth of 4 or less for static pseudocolor
From: Antonino A. Daplas @ 2006-04-09 14:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Fbdev development list
Since the visual STATIC_PSEUDOCOLOR has a read-only colormap, use logos
with 16 colors only since these logos use the console palette. This has
a higher likelihood that the logo will display correctly.
Signed-of-by: Antonino Daplas <adaplas@pol.net>
---
drivers/video/fbmem.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 944855b..8d8eadb 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -435,6 +435,11 @@ int fb_prepare_logo(struct fb_info *info
depth = info->var.green.length;
}
+ if (info->fix.visual == FB_VISUAL_STATIC_PSEUDOCOLOR) {
+ /* assume console colormap */
+ depth = 4;
+ }
+
if (depth >= 8) {
switch (info->fix.visual) {
case FB_VISUAL_TRUECOLOR:
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply related
* [PATCH] vesafb: Fix incorrect logo colors in x86_64
From: Antonino A. Daplas @ 2006-04-09 14:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Fbdev development list
Bugzilla Bug 6299:
A pixel size of 8 bits produces wrong logo colors in x86_64.
The driver has 2 methods for setting the color map, using the protected mode
interface provided by the video BIOS and directly writing to the VGA
registers. The former is not supported in x86_64 and the latter is enabled
only in i386.
Fix by enabling the latter method in x86_64 only if supported by the BIOS.
If both methods are unsupported, change the visual of vesafb to
STATIC_PSEUDOCOLOR.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
---
arch/i386/boot/video.S | 5 +++++
arch/x86_64/boot/video.S | 5 +++++
drivers/video/vesafb.c | 27 +++++++++++++++++++++------
include/linux/screen_info.h | 3 ++-
4 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/arch/i386/boot/video.S b/arch/i386/boot/video.S
index 0000a26..c9343c3 100644
--- a/arch/i386/boot/video.S
+++ b/arch/i386/boot/video.S
@@ -97,6 +97,7 @@
#define PARAM_VESAPM_OFF 0x30
#define PARAM_LFB_PAGES 0x32
#define PARAM_VESA_ATTRIB 0x34
+#define PARAM_CAPABILITIES 0x36
/* Define DO_STORE according to CONFIG_VIDEO_RETAIN */
#ifdef CONFIG_VIDEO_RETAIN
@@ -233,6 +234,10 @@ mopar_gr:
movw 18(%di), %ax
movl %eax, %fs:(PARAM_LFB_SIZE)
+# store mode capabilities
+ movl 10(%di), %eax
+ movl %eax, %fs:(PARAM_CAPABILITIES)
+
# switching the DAC to 8-bit is for <= 8 bpp only
movw %fs:(PARAM_LFB_DEPTH), %ax
cmpw $8, %ax
diff --git a/arch/x86_64/boot/video.S b/arch/x86_64/boot/video.S
index 0587477..32327bb 100644
--- a/arch/x86_64/boot/video.S
+++ b/arch/x86_64/boot/video.S
@@ -97,6 +97,7 @@
#define PARAM_VESAPM_OFF 0x30
#define PARAM_LFB_PAGES 0x32
#define PARAM_VESA_ATTRIB 0x34
+#define PARAM_CAPABILITIES 0x36
/* Define DO_STORE according to CONFIG_VIDEO_RETAIN */
#ifdef CONFIG_VIDEO_RETAIN
@@ -233,6 +234,10 @@ mopar_gr:
movw 18(%di), %ax
movl %eax, %fs:(PARAM_LFB_SIZE)
+# store mode capabilities
+ movl 10(%di), %eax
+ movl %eax, %fs:(PARAM_CAPABILITIES)
+
# switching the DAC to 8-bit is for <= 8 bpp only
movw %fs:(PARAM_LFB_DEPTH), %ax
cmpw $8, %ax
diff --git a/drivers/video/vesafb.c b/drivers/video/vesafb.c
index 8982e54..b0b9acf 100644
--- a/drivers/video/vesafb.c
+++ b/drivers/video/vesafb.c
@@ -57,7 +57,7 @@ static unsigned short *pmi_base = NULL
static void (*pmi_start)(void);
static void (*pmi_pal)(void);
static int depth;
-
+static int vga_compat;
/* --------------------------------------------------------------------- */
static int vesafb_pan_display(struct fb_var_screeninfo *var,
@@ -83,9 +83,10 @@ static int vesafb_pan_display(struct fb_
static void vesa_setpalette(int regno, unsigned red, unsigned green,
unsigned blue)
{
+ int shift = 16 - depth;
+
#ifdef __i386__
struct { u_char blue, green, red, pad; } entry;
- int shift = 16 - depth;
if (pmi_setpal) {
entry.red = red >> shift;
@@ -101,14 +102,20 @@ static void vesa_setpalette(int regno, u
"d" (regno), /* EDX */
"D" (&entry), /* EDI */
"S" (&pmi_pal)); /* ESI */
- } else {
- /* without protected mode interface, try VGA registers... */
+ return;
+ }
+#endif
+
+/*
+ * without protected mode interface and if VGA compatible,
+ * try VGA registers...
+ */
+ if (vga_compat) {
outb_p(regno, dac_reg);
outb_p(red >> shift, dac_val);
outb_p(green >> shift, dac_val);
outb_p(blue >> shift, dac_val);
}
-#endif
}
static int vesafb_setcolreg(unsigned regno, unsigned red, unsigned green,
@@ -214,6 +221,7 @@ static int __init vesafb_probe(struct pl
if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB)
return -ENODEV;
+ vga_compat = (screen_info.capabilities & 2) ? 0 : 1;
vesafb_fix.smem_start = screen_info.lfb_base;
vesafb_defined.bits_per_pixel = screen_info.lfb_depth;
if (15 == vesafb_defined.bits_per_pixel)
@@ -318,6 +326,12 @@ static int __init vesafb_probe(struct pl
}
}
+ if (vesafb_defined.bits_per_pixel == 8 && !pmi_setpal && !vga_compat) {
+ printk(KERN_WARNING "vesafb: hardware palette is unchangeable,\n"
+ " colors may be incorrect\n");
+ vesafb_fix.visual = FB_VISUAL_STATIC_PSEUDOCOLOR;
+ }
+
vesafb_defined.xres_virtual = vesafb_defined.xres;
vesafb_defined.yres_virtual = vesafb_fix.smem_len / vesafb_fix.line_length;
if (ypan && vesafb_defined.yres_virtual > vesafb_defined.yres) {
@@ -354,7 +368,8 @@ static int __init vesafb_probe(struct pl
printk(KERN_INFO "vesafb: %s: "
"size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
(vesafb_defined.bits_per_pixel > 8) ?
- "Truecolor" : "Pseudocolor",
+ "Truecolor" : (vga_compat || pmi_setpal) ?
+ "Pseudocolor" : "Static Pseudocolor",
screen_info.rsvd_size,
screen_info.red_size,
screen_info.green_size,
diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h
index 6336987..2925e66 100644
--- a/include/linux/screen_info.h
+++ b/include/linux/screen_info.h
@@ -41,7 +41,8 @@ struct screen_info {
u16 vesapm_off; /* 0x30 */
u16 pages; /* 0x32 */
u16 vesa_attributes; /* 0x34 */
- /* 0x36 -- 0x3f reserved for future expansion */
+ u32 capabilities; /* 0x36 */
+ /* 0x3a -- 0x3f reserved for future expansion */
};
extern struct screen_info screen_info;
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply related
* [PATCH] Re: "apm: set display: Interface not engaged" is back on armada laptops [Was: APM Screen Blanking fix]
From: Samuel Thibault @ 2006-04-09 13:57 UTC (permalink / raw)
To: torvalds; +Cc: jordan.crouse, linux-kernel
In-Reply-To: <20060325134625.GA4593@bouh.residence.ens-lyon.fr>
Hi,
Samuel Thibault, le Sat 25 Mar 2006 14:46:25 +0100, a écrit :
> Part of a fix for APM Screen Blanking in
> arch/i386/kernel/apm.c:apm_console_blank() from Jordan Crouse was:
>
> - if (error == APM_NOT_ENGAGED) {
> + if (error == APM_NOT_ENGAGED && state != APM_STATE_READY) {
>
> for "Prevent[ing] the error message from printing out twice."
>
> However, this puts the "apm: set display: Interface not engaged"
> error back on armada laptops (which was the original need for this if
> statement).
Here is a fix:
Fix the "apm: set display: Interface not engaged" error on Armada
laptops again.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
diff --git a/arch/i386/kernel/apm.c b/arch/i386/kernel/apm.c
index da30a37..df0e174 100644
--- a/arch/i386/kernel/apm.c
+++ b/arch/i386/kernel/apm.c
@@ -1079,7 +1079,7 @@ static int apm_console_blank(int blank)
break;
}
- if (error == APM_NOT_ENGAGED && state != APM_STATE_READY) {
+ if (error == APM_NOT_ENGAGED) {
static int tried;
int eng_error;
if (tried++ == 0) {
^ permalink raw reply related
* RE: [RFC] Hypercalls from HVM guests
From: Nakajima, Jun @ 2006-04-09 13:56 UTC (permalink / raw)
To: Keir Fraser; +Cc: Steve Ofsthun, xen-devel
Keir Fraser wrote:
> On 9 Apr 2006, at 00:33, Nakajima, Jun wrote:
>
>> If eax is set to a value outside the recognized range of CPUID
>> currently defined, CPUID does not necessarily return all zero's on
>> Intel. It's "Reserved" (Information returned for highest basic
>> information leaf). Also "an unused index" can have conflicts in the
>> future.
>>
>> If we just need to tell on which CPU the current HVM guest is
>> running, I think "GeunineIntel" or "AuthenticAMD" is the best
>> because it's been used by native systems as well.
>
> Then how do you tell whether you are running on a hypervisor without
> executing some instruction that might fault? We would like to avoid
> requiring that.
This is a different question, and I think detecting a virtual device
(i.e. virtual block device, NIC) or chipset would be a cleaner way at
this point. And that would be proper for the patch that Steve mentioned
(we wrote it). The fact that it's running on a hypervisor does not
necessarily guarantee presence of such virtual devices (in fact they
don't exist today ;-).
If we really need to tell if we are running on a hypervisor at a very
early point or even in user-mode, I think CPUID with "an unused index"
would be the simplest, but so far I haven't seen any usage models that
really require that. If we want to add virtualization hints for
processor architectures (e.g. MMU) in guests, it would be needed.
>
> There is quite a lot of CPUID and MSR address space, and a random
> return value for CPUID when running natively is practically-speaking
> fine if we're looking for a 128-bit signature.
Many bits are already reserved for the future capabilities in CPUID, and
MSR is CPU _model_ specific by definition, i.e. not architecturally
clean. But my point is that we should specify "reserved for
virtualization" or something in the H/W manual rather than inventing an
ad hoc one (when we don't really need). BTW, I think virtualization
hints (nop on the native, hypercall on a hypervisor) would be very
useful for performance optimizations.
>
> The only other option I think would be a BIOS table, probably below
> 1MB. I prefer the CPUID/MSR method.
>
> -- Keir
Jun
---
Intel Open Source Technology Center
^ permalink raw reply
* Re: NATed packets only enter the default routing table
From: Jeroen Elebaut @ 2006-04-09 13:56 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20060408194058.71fa3e09.mailinglists@lucassen.org>
Hi,
i had a similar problem with our setup. The problem is i think that the
routing decision on the linux box is made before the address in the packet is
changed back to 1.2.3.3. So it doesn't use the source policy routing entry. I
solved this by using the connmark module from iptables and then do routing
based on the mark. The following should work in your setup:
iptables -t mangle -I PREROUTING -m conntrack --ctstate ESTABLISHED,RELATED -j
CONNMARK --restore-mark
iptables -t mangle -I PREROUTING -i eth1 -m conntrack --ctstate NEW -j
CONNMARK --set-mark 1
ip rule add fwmark 1 lookup eth1_up
This will route everything that entered via eth1 back via eth1.
Greetings,
jeroen
^ permalink raw reply
* A failed-disk-how-to anywhere?
From: Martin Stender @ 2006-04-09 13:53 UTC (permalink / raw)
To: linux-raid
Hi there!
I have two identical disks sitting on a Promise dual channel IDE
controller. I guess both disks are primary's then.
One of the disks have failed, so I bought a new disk, took out the
failed disk, and put in the new one.
That might seem a little naive, and apparently it was, since the
system won't boot up now.
It boots fine, when only the old, healthy disk is connected.
By the way, all three partitions are raided - including /boot ...
Anyway, I have removed the old disk from the Raid with:
#mdadm /dev/mdo --remove /dev/hde1
#mdadm /dev/md1 --remove /dev/hde2
#mdadm /dev/md2 --remove /dev/hde3
- but the the problem persists.
I can't seem to find a decent 'How-To' - so how it this supposed to
be done?
Thanks in advance!
Martin
^ permalink raw reply
* Re: [Qemu-devel] qemu exec.c
From: Paul Brook @ 2006-04-09 13:51 UTC (permalink / raw)
To: qemu-devel, a_mulyadi
In-Reply-To: <200604092046.23092.a_mulyadi@softhome.net>
> > Modified files:
> > . : exec.c
> >
> > Log message:
> > Fix breakpoint TLB invalidation.
>
> Does this fix do the same thing like Andre pech's gdb fix?
Yes, it also fixes that problem.
Paul
^ permalink raw reply
* Re: [Qemu-devel] qemu exec.c
From: Mulyadi Santosa @ 2006-04-09 13:46 UTC (permalink / raw)
To: qemu-devel, Paul Brook
In-Reply-To: <E1FSH1U-00006o-C1@savannah.gnu.org>
Hi Paul...
> CVSROOT: /sources/qemu
> Module name: qemu
> Branch:
> Changes by: Paul Brook <pbrook@savannah.gnu.org> 06/04/08 17:14:56
>
> Modified files:
> . : exec.c
>
> Log message:
> Fix breakpoint TLB invalidation.
Does this fix do the same thing like Andre pech's gdb fix?
regards
Mulyadi
^ permalink raw reply
* [PATCH] Improve the git-diff-tree -c/-cc documentation
From: Petr Baudis @ 2006-04-09 13:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslonaxq6.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Apr 09, 2006 at 11:45:37AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@ucw.cz> writes:
>
> > Now, the -c option documentation says:
> >
> > It shows the differences from each of the parents to the merge
> > result simultaneously, instead of showing pairwise diff between
> > a parent and the result one at a time, which '-m' option output
> > does.
> >
> > This sounds as exactly what I want. Well, the only problem is that the
> > same diff command as above with -c option added produces no diff at all,
> > just the header and commit messages. Did I misunderstand the -c
> > description and does it do something different?
>
> The --combined diff option is to show merges more sensibly than
> plain -m option. Now, the definition of "sensible" is to say
> that a merge is not interesting if it takes a version from one
> of the parents. The paths whose results do not match any of the
> parents' version are deemed interesting and are shown.
>
> I think you could tweak and give an option to intersect_paths()
> in combine-diff.c, so that paths that match one of the parents
> are also included in the output. I haven't thought about it too
> much, but my gut feeling is it would not be very involved
> change.
Aha, thanks! I actually think this is more sensible to do, so now I'm
only pondering if in cg-log -f it is more useful to show the list of
files changed relative to the first parent or the files which were
subjected to a content merge...
---
This tries to clarify the -c/-cc documentation and clean up the style and
grammar.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-diff-tree.txt | 25 ++++++++++++++++---------
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 9153e4c..d7e529b 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -60,7 +60,8 @@ separated with a single space are given.
-m::
By default, "git-diff-tree --stdin" does not show
differences for merge commits. With this flag, it shows
- differences to that commit from all of its parents.
+ differences to that commit from all of its parents. See
+ also '-c'.
-s::
By default, "git-diff-tree --stdin" shows differences,
@@ -81,19 +82,25 @@ separated with a single space are given.
git-diff-tree outputs a line with the commit ID when
applicable. This flag suppressed the commit ID output.
--c,--cc::
- These flags change the way a merge commit is displayed
+-c::
+ This flag changes the way a merge commit is displayed
(which means it is useful only when the command is given
one <tree-ish>, or '--stdin'). It shows the differences
- from each of the parents to the merge result
- simultaneously, instead of showing pairwise diff between
- a parent and the result one at a time, which '-m' option
- output does. '--cc' further compresses the output by
- omiting hunks that show differences from only one
+ from each of the parents to the merge result simultaneously
+ instead of showing pairwise diff between a parent and the
+ result one at a time (which is what the '-m' option does).
+ Furthermore, it lists only files which were modified
+ in both parents.
+
+-cc::
+ This flag changes the way a merge commit patch is displayed,
+ in a similar way to the '-c' option. It implies the '-c'
+ and '-p' options and further compresses the patch output
+ by omitting hunks that show differences from only one
parent, or show the same change from all but one parent
for an Octopus merge. When this optimization makes all
hunks disappear, the commit itself and the commit log
- message is not shown, just like any other "empty diff" cases.
+ message is not shown, just like in any other "empty diff" case.
--always::
Show the commit itself and the commit log message even
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply related
* Re: [LARTC] Trying to do some very simple ingress limiting, no success
From: Andy Furniss @ 2006-04-09 13:42 UTC (permalink / raw)
To: lartc
In-Reply-To: <1144579998.5694.18.camel@localhost.localdomain>
Erik Slagter wrote:
>
> Found it and deselected it. Now making new kernel...
>
> The "old" policer is marked as "obsolete", so I guess it will go away.
>
> What am I supposed to replace it with, then?
There may be a way in the future to get netfilter state with an
ematch/meta data (I don't know the detail Thomas Graf has mentioned it).
> For IMQ I need to patch the kernel (feasible) and the netfilter tools
> (not feasible :-() I just learned.
I didn't know there is a problrm with IMQ + netfilter.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [RFC] Source format change for drawing functions
From: Antonino A. Daplas @ 2006-04-09 13:29 UTC (permalink / raw)
To: Linux Fbdev development list
Hi people,
Currently, the drawing functions of the framebuffer devices accepts either an
index to the pseudo_palette (truecolor, directcolor) or an index to the
clut (the rest of the visuals) as the source color. It has distinct
advantages in that the upper layer (fbcon) need not convert the console colors
to framebuffer format, and makes writing to the framebuffer quite fast.
However, it has certain disadvantages:
- we are restricted to 16 colors only, or with hacks, 256, as in the logo
drawing code
- most drivers need to keep a pseudo_palette which rightly belongs to fbcon,
not the drivers
- the drawing functions are basically useless outside fbcon/fbdev
Therefore, I'm proposing that we change the source format so we can take
advantage of the full range of colors offered by a particular visual while
keeping clients (mainly fbcon) free from the hassle of color conversion.
To implement this:
1. Separate fb_setcolreg() into two functions:
a. fb_setcolreg() - writes the color components to the hardware clut
b. fb_get_pixel() - returns a u32 value which is the raw framebuffer format
given red, green, blue, and transparency components. The returned value
can be directly written to the framebuffer. Basically, this is the part of
the fb_setcolreg() function that writes entries to the pseudo_palette, but
it returns the value instead.
Doing the above should be very simple. In pseudocode, from:
static int xxxfb_setcolreg(...)
{
write_to_dac()
pseudo_palette(regno) = red | green | blue | transp;
return 0;
}
to
static int xxxfb_setcolreg(...)
{
write_to_dac()
return 0;
}
static u32 xxxfb_get_pixel(...)
u32 pixel = red | green | blue | transp;
return pixel;
}
2. For drivers that implements fb_get_pixel(), the pseudo_palette will become
unused, thus there is no need to allocate memory for this. (fbcon will
instead maintain the pseudo_palette. And once all drivers are converted we
can remove the pointer from struct fb_info.)
3. Convert drawing functions to accept source format in ARGB8888
Truecolor. Drawing functions will use fb_get_pixel() to convert ARGB8888
into a value which can be directly written to the framebuffer or fed to the
accelerator engine.
The advantage of doing this is that the drawing functions become usable
outside of fbdev/fbcon. It also makes displaying an image to the
framebuffer easy. As long as the bitmap is in ARGB8888 (or monochrome),
this can be fed to the driver and it should display properly regardless of
the current visual.
The disadvantage is we do on-the-fly format conversions, so fbcon will slow
down a litte. Not very noticeable except for the speed freaks.
If speed is of the essence, we can instead use source in raw
framebuffer format. This will be very fast, but this will require that
clients know how to do the conversion. fbcon can use fb_get_pixel() to do
the conversion, so it won't be a problem.
I have a working implementation in my private tree using ARGB8888 as the
source format with several commonly used drivers already converted and
working. There won't be breakage for drivers that do not implement
fb_get_pixel() as the code that uses the index to the pseudo_palette is still
in place.
Comments? I may send this to akpm for testing unless there are violent
objections.
Tony
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: RT task scheduling
From: Ingo Molnar @ 2006-04-09 13:16 UTC (permalink / raw)
To: Darren Hart
Cc: linux-kernel, Thomas Gleixner, Stultz, John, Peter Williams,
Siddha, Suresh B, Nick Piggin
In-Reply-To: <200604052025.05679.darren@dvhart.com>
* Darren Hart <darren@dvhart.com> wrote:
> My last mail specifically addresses preempt-rt, but I'd like to know
> people's thoughts regarding this issue in the mainline kernel. Please
> see my previous post "realtime-preempt scheduling - rt_overload
> behavior" for a testcase that produces unpredictable scheduling
> results.
thanks for the testcase! It indeed triggered a bug in the -rt tree's
"RT-overload" balancing feature. The nature of the bug made it trigger
much less likely on 2-way boxes (where i do most of my -rt testing),
probably that's why it didnt get discovered before. I've uploaded the
-rt14 tree with this bug fixed - does it fix the failures for you?
Ingo
^ permalink raw reply
* Re: [LARTC] Trying to do some very simple ingress limiting, no success
From: Erik Slagter @ 2006-04-09 13:09 UTC (permalink / raw)
To: lartc
In-Reply-To: <1144579998.5694.18.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 2230 bytes --]
On Sun, 2006-04-09 at 14:00 +0100, Andy Furniss wrote:
> Erik Slagter wrote:
> > Hi,
> >
> > I am trying to do some simple ingress limiting based on fwmark. I know
> > the ability and sense to do INGRESS limiting is ehm... limited ;-) but
> > still I want to try it.
> >
> > I tried several things.
> >
> > === 1 ===
> >
> > tcq ingress handle ffff:
> > tcf parent ffff: protocol ip prio 1 handle 1 fw police rate 12mbit burst 10k drop
> > tcf parent ffff: protocol ip prio 1 handle 2 fw police rate 10mbit burst 10k drop
> > tcf parent ffff: protocol ip prio 1 handle 3 fw police rate 1mbit burst 10k drop
> >
> > This installs OK, but the filters are never called. The netfilter stats
> > show the marks are set though. To make sure it's not just the tc stats
> > output that's borked, I changed the bw limits to a rediculous low value,
> > and indeed, no effect at all.
> >
> There are two policers now the old one will work as you want but you
> need to change your kernel config. Unselect packet action and you should
> be able to choose a different policer.
Found it and deselected it. Now making new kernel...
The "old" policer is marked as "obsolete", so I guess it will go away.
What am I supposed to replace it with, then?
> Or you could try using tc filters instead of netfilter - I don't know if
> it will be possible for what you want as I can't see the rules that mark.
It's probably possible, but I already have quite a large set of
netfilter rules. I don't want to make the whole thing even more
complicated by also adding lots of tc stuff, I'd rather have the
tc/iproute things as simple as possible.
> This has never worked if you want a queue on ingress you need to use IMQ
> (in the case that you need netfilter PREROUTING marks) or IFB (kernel >=
> 2.6.16) but this will hook before netfilter - so no marks.
For IMQ I need to patch the kernel (feasible) and the netfilter tools
(not feasible :-() I just learned.
And you're just telling me I cannot use IFB. Bummer. Anyway, if there is
any simple (!) way to implement what I am searching for, I am happy.
I will try your "old policer version" suggestion asap.
Thanks for your help.
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2771 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [2.6 patch] drivers/isdn/capi/capiutil.c: unexport capi_message2str
From: Karsten Keil @ 2006-04-09 13:07 UTC (permalink / raw)
To: Adrian Bunk; +Cc: isdn4linux, linux-kernel
In-Reply-To: <20060407211736.GO7118@stusta.de>
On Fri, Apr 07, 2006 at 11:17:36PM +0200, Adrian Bunk wrote:
> This patch removes an unused EXPORT_SYMBOL.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.17-rc1-mm1-full/drivers/isdn/capi/capiutil.c.old 2006-04-07 10:47:30.000000000 +0200
> +++ linux-2.6.17-rc1-mm1-full/drivers/isdn/capi/capiutil.c 2006-04-07 10:47:37.000000000 +0200
> @@ -855,5 +855,4 @@
> EXPORT_SYMBOL(capi_cmsg_header);
> EXPORT_SYMBOL(capi_cmd2str);
> EXPORT_SYMBOL(capi_cmsg2str);
> -EXPORT_SYMBOL(capi_message2str);
> EXPORT_SYMBOL(capi_info2str);
>
Yes it is currently unused, but part of the CAPI driver SDK for supporting
debug messages in capi drivers, so I would tend to let it exported, if here
are not strong arguments against exporting it.
--
Karsten Keil
SuSE Labs
ISDN development
^ permalink raw reply
* Re: [LARTC] Trying to do some very simple ingress limiting, no success
From: Andy Furniss @ 2006-04-09 13:00 UTC (permalink / raw)
To: lartc
In-Reply-To: <1144579998.5694.18.camel@localhost.localdomain>
Erik Slagter wrote:
> Hi,
>
> I am trying to do some simple ingress limiting based on fwmark. I know
> the ability and sense to do INGRESS limiting is ehm... limited ;-) but
> still I want to try it.
>
> I tried several things.
>
> == 1 =>
> tcq ingress handle ffff:
> tcf parent ffff: protocol ip prio 1 handle 1 fw police rate 12mbit burst 10k drop
> tcf parent ffff: protocol ip prio 1 handle 2 fw police rate 10mbit burst 10k drop
> tcf parent ffff: protocol ip prio 1 handle 3 fw police rate 1mbit burst 10k drop
>
> This installs OK, but the filters are never called. The netfilter stats
> show the marks are set though. To make sure it's not just the tc stats
> output that's borked, I changed the bw limits to a rediculous low value,
> and indeed, no effect at all.
>
There are two policers now the old one will work as you want but you
need to change your kernel config. Unselect packet action and you should
be able to choose a different policer.
Or you could try using tc filters instead of netfilter - I don't know if
it will be possible for what you want as I can't see the rules that mark.
> == 2 =>
> tcq ingress handle ffff:
> tcq parent ffff: handle 10 htb
> tcc parent ffff: htb rate 12mbit
> tcc parent ffff: htb rate 10mbit
> tcc parent ffff: htb rate 1mbit
> tcf parent ffff: protocol ip prio 1 fw
>
> I tricked tc into attaching a htb to the root qdisc. This gives no errors
> but also doesn't seem to do anything. If you use tc show qdisc|filter|class
> the qdisc,filters and classes are not even shown, so I guess it's borked
> (tc should have given an error that it won't work).
>
> ====
This has never worked if you want a queue on ingress you need to use IMQ
(in the case that you need netfilter PREROUTING marks) or IFB (kernel >=
2.6.16) but this will hook before netfilter - so no marks.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.