* [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
* [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] 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
* 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
* 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: 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
* [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
* [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
* [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
* 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
* 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
* [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
* 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
* Re: Socket udev events (noobie)
From: Kay Sievers @ 2006-04-09 14:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <3a0f1c620604090727u14cff44au47a61c7191a553da@mail.gmail.com>
On Sun, Apr 09, 2006 at 05:27:21PM +0300, Sting Zax wrote:
> 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:"?
These are not special events, these are RUN keys with the prefix
"socket:" plus the name of an abstract namespace socket where the
event is passed to instead of forking a program.
Udevmonitor is connected like this:
RUN+="socket:/org/kernel/udev/monitor"
It listens on the socket with the specified name.
Kay
-------------------------------------------------------
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\x110944&bid$1720&dat\x121642
_______________________________________________
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
* [Qemu-devel] qemu/target-arm translate.c
From: Paul Brook @ 2006-04-09 14:38 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Paul Brook <pbrook@savannah.gnu.org> 06/04/09 14:38:57
Modified files:
target-arm : translate.c
Log message:
Thumb prefetch abort fix.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/target-arm/translate.c.diff?tr1=1.40&tr2=1.41&r1=text&r2=text
^ permalink raw reply
* Re: [Bridge] [PATCH] fix 802.3ad multicast
From: Vlad Drukker @ 2006-04-09 14:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: bridge
In-Reply-To: <20060407165928.022d4ad8@dxpl.pdx.osdl.net>
On Fri, 2006-04-07 at 16:59 -0700, Stephen Hemminger wrote:
> On Thu, 06 Apr 2006 19:15:06 +0300
> Vlad Drukker <vlad@storewiz.com> wrote:
>
> > Hi Stephen,
> >
> > there was a bug in bridging bonds.
> > multicast packets needed for 802.3ad netif_carrier_ok() were dropped.
> > attached patch works for me.
> >
> > Cheers,
> > Vlad.
> >
> >
> >
>
> Making a bonding specific hack like this seems wrong. The
> port could also be disabled during shutdown (for RCU removal),
> and in that case we need to drop the packet.
>
> There must be a better solution.
>
you probably right,
skb_bond() looks like a proper place for this, because
netif_receive_skb() needs to call ETH_P_SLOW hadler instead of
hadle_bridge hook.
the fix is moving to linux-net .
^ permalink raw reply
* Re: Linux 2.6.17-rc1: /sbin/iptables does not find kernel netfilter
From: Ville Herva @ 2006-04-09 14:44 UTC (permalink / raw)
To: Patrick McHardy; +Cc: linux-kernel, netfilter, davem
In-Reply-To: <20060409074313.GZ15954@vianova.fi>
On Sun, Apr 09, 2006 at 10:43:13AM +0300, you [Ville Herva] wrote:
> >
> > Most likely you didn't enable the new xtables options. Please post your
> > full config.
>
> The full .config is here
> http://www.iki.fi/v/tmp/2.6.17-rc1.config
Now "iptables -L" works, but I still get
> iptables -A INPUT -p tcp -d 0.0.0.0/0 --dport http -m state --state NEW,ESTABLISHED -j ACCEPT
iptables: Unknown error 4294967295
from about half of the iptables rules.
My current config is here:
http://www.iki.fi/v/tmp/2.6.17-rc1.config.new
The following modules are loaded:
iptable_nat 6948 1
ip_nat 14860 1 iptable_nat
ip_conntrack 43188 2 iptable_nat,ip_nat
ipt_REJECT 4704 0
iptable_filter 2784 0
and
CONFIG_NETFILTER=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_IP_NF_IPTABLES=y
are compiled in statically.
I just realized
# CONFIG_NETFILTER_XT_MATCH_STATE is not set
should probably be set. I'm building a new kernel now...
-- v --
v@iki.fi
^ permalink raw reply
* Re: Linux 2.6.17-rc1: /sbin/iptables does not find kernel netfilter
From: Ville Herva @ 2006-04-09 14:45 UTC (permalink / raw)
To: Patrick McHardy; +Cc: linux-kernel, netfilter, davem
In-Reply-To: <20060409144416.GO1686@vianova.fi>
On Sun, Apr 09, 2006 at 05:44:16PM +0300, you [Ville Herva] wrote:
> I just realized
> # CONFIG_NETFILTER_XT_MATCH_STATE is not set
> should probably be set. I'm building a new kernel now...
Ok, that seems to do it.
Thanks for the help, and sorry for the noise. I hope not too many people hit
the same glitch while upgrading...
-- v --
v@iki.fi
^ permalink raw reply
* Re: md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11
From: Luca Berra @ 2006-04-09 14:46 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <4438FFA9.4030907@debruin.org>
On Sun, Apr 09, 2006 at 02:35:53PM +0200, Marc L. de Bruin wrote:
>Hi,
>
>(I just subscribed, sorry if this is a dupe. I did try to match the
>subject from the archives, but couldn't find any...)
>
>I ran into trouble after upgrading a Debian Sarge system from 2.6.11 to
>2.6.15. To be more precise, it turned out that md/mdadm seems to not
>function properly during the boot process of 2.6.15.
>
>My /etc/mdadm/mdadm.conf contains this:
>
> >>>---[mdadm.conf]---
>DEVICE /dev/hdi1 /dev/hdg1 /dev/hdc1
>ARRAY /dev/md1 level=raid5 num-devices=3
>UUID=09c58ab6:f706e37b:504cf890:1a597046
>devices=/dev/hdi1,/dev/hdg1,/dev/hdc1
>
>DEVICE /dev/hdg2 /dev/hdc2
>ARRAY /dev/md2 level=raid1 num-devices=2
>UUID=86210844:6abbf533:dc82f982:fe417066 devices=/dev/hdg2,/dev/hdc2
>
>DEVICE /dev/hda2 /dev/hdb2
>ARRAY /dev/md0 level=raid1 num-devices=2
>UUID=da619c37:6c072dc8:52e45423:f4a58b7c devices=/dev/hda2,/dev/hdb2
>
>DEVICE /dev/hda1 /dev/hdb1
>ARRAY /dev/md4 level=raid1 num-devices=2
>UUID=bfc30f9b:d2c21677:c4ae5f90:b2bddb75 devices=/dev/hda1,/dev/hdb1
>
>DEVICE /dev/hdc3 /dev/hdg3
>ARRAY /dev/md3 level=raid1 num-devices=2
>UUID=fced78ce:54f00a78:8662e7eb:2ad01d0b devices=/dev/hdc3,/dev/hdg3
> >>>---[/mdadm.conf]---
replace all
DEVICE .....
lines
with a single
DEVICE partitions
remove all the device=... part from the array lines.
L.
^ permalink raw reply
* Re: md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11
From: dean gaudet @ 2006-04-09 14:47 UTC (permalink / raw)
To: Marc L. de Bruin; +Cc: linux-raid
In-Reply-To: <4438FFA9.4030907@debruin.org>
On Sun, 9 Apr 2006, Marc L. de Bruin wrote:
...
> Okay, just pressing Control-D continues the boot process and AFAIK the root
> filesystemen actually isn't corrupt. Running e2fsck returns no errors and
> booting 2.6.11 works just fine, but I have no clue why it picked the wrong
> partitions to build md[01234].
>
> What could have happened here?
i didn't know sarge had 2.6.11 or 2.6.15 packages... but i'm going to
assume you've installed one of initramfs-tools or yaird in order to use
the unstable 2.6.11 or 2.6.15 packages... so my comments might not apply.
initramfs-tools generates an "mdrun /dev" which starts all the raids it
can find... but does not include the mdadm.conf in the initrd so i'm not
sure it will necessarily start them in the right minor devices. try doing
an "mdadm --examine /dev/xxx" on some of your partitions to see if the
"preferred minor" is what you expect it to be...
if the preferred minors are wrong there's some mdadm incantation to update
them... see the man page.
or switch to yaird (you'll have to install yaird and purge
initramfs-tools) and dpkg-reconfigure your kernel packages to cause the
initrds to be rebuilt. yaird starts only the raid required for the root
filesystem, and specifies the correct minor for it. then later after the
initrd /etc/init.d/mdadm-raid will start the rest of your raids using your
mdadm.conf.
-dean
^ permalink raw reply
* [-mm patch] drivers/pci/hotplug/acpiphp_glue.c: make a function static
From: Adrian Bunk @ 2006-04-09 14:50 UTC (permalink / raw)
To: Andrew Morton, MUNEDA Takahiro, Greg Kroah-Hartman
Cc: linux-kernel, linux-pci
In-Reply-To: <20060408031405.5e5131da.akpm@osdl.org>
On Sat, Apr 08, 2006 at 03:14:05AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc1-mm1:
>...
> +gregkh-pci-acpiphp-configure-_prt-v3.patch
>...
> PCI tree updates
>...
This patch makes the needlessly global acpiphp_bus_trim() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-rc1-mm2-full/drivers/pci/hotplug/acpiphp_glue.c.old 2006-04-09 16:13:00.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/drivers/pci/hotplug/acpiphp_glue.c 2006-04-09 16:13:13.000000000 +0200
@@ -928,7 +928,7 @@
* @handle: handle to acpi namespace
*
*/
-int acpiphp_bus_trim(acpi_handle handle)
+static int acpiphp_bus_trim(acpi_handle handle)
{
struct acpi_device *device;
int retval;
^ permalink raw reply
* [Xenomai-core] latency -t 1 crashes on SMP.
From: Gilles Chanteperdrix @ 2006-04-09 14:52 UTC (permalink / raw)
To: xenomai
I tried latency -t 1 on an SMP machines, and observed a very
reproducible crash. Most of the time, the machine locks up
completely. The rest of the time, I get :
Xenomai: suspending kernel thread e7559044 ('timerbench') at 0xb01051f2 after ex
ception #14
And the system remains runnable, but 0xb01051f2 is not a valid kernel
module text address.
The lock up does not seem to be detected by any Xenomai or Linux
debug or watchdog. Only enabling the NMI watchdog seems to
systematically produce the exception 14 instead of the lockup.
I ve tried to put a printk at the beginning of timer_task_proc outer
loop. It get printed once when getting the exception 14, and twice when
getting the lock up.
Any idea where to look ?
--
Gilles Chanteperdrix.
^ permalink raw reply
* Re: [Qemu-devel] Unified device model
From: Jim C. Brown @ 2006-04-09 14:55 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <200604091138.31242.paul@codesourcery.com>
On Sun, Apr 09, 2006 at 11:38:28AM +0100, Paul Brook wrote:
> I think to be acceptable to qemu (and probably also for Xen) the devices would
> have to be written in C. C++ is more pain that it's worth in this context.
> Of course there's no reason why we couldn't use the subset of C that's also
> valid C++. You could also write C++ wrappers round the interface for bochs to
> use.
>
Same here.
> I'm not a fan of binary plugins (for the same reasons I'm don't like binary
> kernel modules), and don't think there's any real need to them.
A binary plugin API and a source plugin API (one that requires each driver
device to be recompiled for each of the platforms (Xen, qemu, bochs, etc.)
would probably be equally hard to design and maintain.
With a binary plugin API you at least win out.
> I can't see
> any good reasons why open source devices would need to be broken out into a
> separate shared library.
>
I think the case was already made for this.
Xen's hardware emulation, while based on qemu's, is already ahead in several
aspects. A separate library would make it more convenient for these changes
to be shared back with qemu. Or with E/OS.
This is actually a completely separate issue from a unified device driver API
(as qemu could support the API, but only in source code form, or could require
that drivers be linked in statically, etc) and should be recognized as such.
> If you do want to accommodate proprietary binary plugins then C++ is a really
> bad idea. The C++/libstdc++ ABI simply isn't stable enough to make this a
> realistic option.
Considering that the ABI does not guarantee compatibility between versions, I
am inclined to agree.
No reason the drivers themselves can't be done in C++, but the API itself
should be pure C.
>
> Paul
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
^ permalink raw reply
* [-mm patch] drivers/char/drm/drm_memory.c: possible cleanups
From: Adrian Bunk @ 2006-04-09 14:58 UTC (permalink / raw)
To: Andrew Morton, airlied; +Cc: linux-kernel, dri-devel
In-Reply-To: <20060408031405.5e5131da.akpm@osdl.org>
On Sat, Apr 08, 2006 at 03:14:05AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc1-mm1:
>...
> git-drm.patch
>...
> git trees
>...
This patch contains the following possible cleanups plus the changes
caused by them:
- #if 0 the following unused global function:
- drm_ioremap_nocache()
- make the following needlessly global functions static:
- agp_remap()
- drm_lookup_map()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/char/drm/drmP.h | 4 ++--
drivers/char/drm/drm_memory.c | 25 +++++++++++++++++++++----
drivers/char/drm/drm_memory.h | 24 ------------------------
drivers/char/drm/drm_memory_debug.h | 2 ++
4 files changed, 25 insertions(+), 30 deletions(-)
--- linux-2.6.17-rc1-mm2-full/drivers/char/drm/drmP.h.old 2006-04-09 16:18:20.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/drivers/char/drm/drmP.h 2006-04-09 16:18:38.000000000 +0200
@@ -815,8 +815,6 @@
extern void *drm_realloc(void *oldpt, size_t oldsize, size_t size, int area);
extern void *drm_ioremap(unsigned long offset, unsigned long size,
drm_device_t * dev);
-extern void *drm_ioremap_nocache(unsigned long offset, unsigned long size,
- drm_device_t * dev);
extern void drm_ioremapfree(void *pt, unsigned long size, drm_device_t * dev);
extern DRM_AGP_MEM *drm_alloc_agp(drm_device_t * dev, int pages, u32 type);
@@ -1022,11 +1020,13 @@
map->handle = drm_ioremap(map->offset, map->size, dev);
}
+#if 0
static __inline__ void drm_core_ioremap_nocache(struct drm_map *map,
struct drm_device *dev)
{
map->handle = drm_ioremap_nocache(map->offset, map->size, dev);
}
+#endif /* 0 */
static __inline__ void drm_core_ioremapfree(struct drm_map *map,
struct drm_device *dev)
--- linux-2.6.17-rc1-mm2-full/drivers/char/drm/drm_memory.h.old 2006-04-09 16:15:53.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/drivers/char/drm/drm_memory.h 2006-04-09 16:21:28.000000000 +0200
@@ -57,15 +57,6 @@
# endif
#endif
-/*
- * Find the drm_map that covers the range [offset, offset+size).
- */
-drm_map_t *drm_lookup_map(unsigned long offset,
- unsigned long size, drm_device_t * dev);
-
-void *agp_remap(unsigned long offset, unsigned long size,
- drm_device_t * dev);
-
static inline unsigned long drm_follow_page(void *vaddr)
{
pgd_t *pgd = pgd_offset_k((unsigned long)vaddr);
@@ -77,18 +68,6 @@
#else /* __OS_HAS_AGP */
-static inline drm_map_t *drm_lookup_map(unsigned long offset,
- unsigned long size, drm_device_t * dev)
-{
- return NULL;
-}
-
-static inline void *agp_remap(unsigned long offset, unsigned long size,
- drm_device_t * dev)
-{
- return NULL;
-}
-
static inline unsigned long drm_follow_page(void *vaddr)
{
return 0;
@@ -99,8 +78,5 @@
void *drm_ioremap(unsigned long offset, unsigned long size,
drm_device_t * dev);
-void *drm_ioremap_nocache(unsigned long offset,
- unsigned long size, drm_device_t * dev);
-
void drm_ioremapfree(void *pt, unsigned long size,
drm_device_t * dev);
--- linux-2.6.17-rc1-mm2-full/drivers/char/drm/drm_memory_debug.h.old 2006-04-09 16:19:31.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/drivers/char/drm/drm_memory_debug.h 2006-04-09 16:19:44.000000000 +0200
@@ -229,6 +229,7 @@
return pt;
}
+#if 0
void *drm_ioremap_nocache (unsigned long offset, unsigned long size,
drm_device_t * dev) {
void *pt;
@@ -251,6 +252,7 @@
spin_unlock(&drm_mem_lock);
return pt;
}
+#endif /* 0 */
void drm_ioremapfree (void *pt, unsigned long size, drm_device_t * dev) {
int alloc_count;
--- linux-2.6.17-rc1-mm2-full/drivers/char/drm/drm_memory.c.old 2006-04-09 16:16:14.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/drivers/char/drm/drm_memory.c 2006-04-09 16:21:24.000000000 +0200
@@ -83,8 +83,8 @@
/*
* Find the drm_map that covers the range [offset, offset+size).
*/
-drm_map_t *drm_lookup_map(unsigned long offset,
- unsigned long size, drm_device_t * dev)
+static drm_map_t *drm_lookup_map(unsigned long offset,
+ unsigned long size, drm_device_t * dev)
{
struct list_head *list;
drm_map_list_t *r_list;
@@ -102,8 +102,8 @@
return NULL;
}
-void *agp_remap(unsigned long offset, unsigned long size,
- drm_device_t * dev)
+static void *agp_remap(unsigned long offset, unsigned long size,
+ drm_device_t * dev)
{
unsigned long *phys_addr_map, i, num_pages =
PAGE_ALIGN(size) / PAGE_SIZE;
@@ -168,6 +168,21 @@
{
return drm_agp_unbind_memory(handle);
}
+
+#else /* __OS_HAS_AGP */
+
+static inline drm_map_t *drm_lookup_map(unsigned long offset,
+ unsigned long size, drm_device_t * dev)
+{
+ return NULL;
+}
+
+static inline void *agp_remap(unsigned long offset, unsigned long size,
+ drm_device_t * dev)
+{
+ return NULL;
+}
+
#endif /* agp */
void *drm_ioremap(unsigned long offset, unsigned long size,
@@ -183,6 +198,7 @@
}
EXPORT_SYMBOL(drm_ioremap);
+#if 0
void *drm_ioremap_nocache(unsigned long offset,
unsigned long size, drm_device_t * dev)
{
@@ -194,6 +210,7 @@
}
return ioremap_nocache(offset, size);
}
+#endif /* 0 */
void drm_ioremapfree(void *pt, unsigned long size,
drm_device_t * dev)
^ permalink raw reply
* Re: [2.6 patch] drivers/isdn/capi/capiutil.c: unexport capi_message2str
From: Arjan van de Ven @ 2006-04-09 15:02 UTC (permalink / raw)
To: Karsten Keil; +Cc: Adrian Bunk, isdn4linux, linux-kernel
In-Reply-To: <20060409130730.GA27948@pingi.kke.suse.de>
On Sun, 2006-04-09 at 15:07 +0200, Karsten Keil wrote:
> 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.
every export takes space in the binary kernel. There's some 900 of these
unused ones, totalling to about 100Kb of unused bloat.
^ 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.