* Changing size of window/fonts
From: John R. Sowden @ 2006-03-28 1:34 UTC (permalink / raw)
To: linux-msdos
When I change the size of a dosemu window, the font stretches, but the font
quality takes a major dive. The when I cant to rturn the window to the size
which uses the good font, I cant find it.
1) Is there a command that returns the window the the original default size
with the quality font?
2) Can I install multiple "quality fonts" an select window size in increments,
utilizing the quality fonts?
tia,
--
John R. Sowden
AMERICAN SENTRY SYSTEMS, INC.
Residential & Commercial Alarm Service
UL Listed Central Station
Serving the San Francisco Bay Area Since 1967
mail@americansentry.net
www.americansentry.net
^ permalink raw reply
* Re: 64-bit failsafe callback
From: Jan Beulich @ 2006-03-28 1:30 UTC (permalink / raw)
To: Keir.Fraser; +Cc: xen-devel
>The reload into %gs is indeed bogus -- it should instead
>HYPERVISOR_set_segment_base(SEGBASE_GS_USER_SEL, gs).
... and then perhaps also for %fs (though I see there is no
hypercall for that, so this is going to be more complicated,
given that this happens in an assembly file), and perhaps
avoiding the two loads altogether if the selectors are zero
and their present values are also zero, to prevent trampling
on any base values in effect.
Jan
^ permalink raw reply
* Re: hda-intel woes
From: Lee Revell @ 2006-03-28 1:28 UTC (permalink / raw)
To: Kyle Moffett
Cc: Jeff V. Merkey, Friedrich Göpel, LKML Kernel, alsa-user,
Takashi Iwai
In-Reply-To: <69495D2A-5488-428E-970F-EA4DD8CB4C05@mac.com>
On Mon, 2006-03-27 at 20:22 -0500, Kyle Moffett wrote:
> Friedrich Göpel wrote:
> > This same message was sent to the alsa mailinglist 3 weeks ago, but
> > it still seems to be waiting on being moderated, so I'm resending
> > this here.
>
> Hi! Unfortunately messages tend to get lost on occasion due to the
> sheer volume of email. Sometimes you may have to resend a couple
> times to get a response. It also helps if you add relevant CC's from
> the MAINTAINERS file (added to this message). You can also file a
> bug report on the ALSA bug tracker, I think the ALSA people tend to
> be fairly good about keeping up with that; sometimes more so than the
> mailing list.
First, try ALSA CVS - many hda-intel bugs have been fixed since
1.0.11-rc3.
Lee
^ permalink raw reply
* Re: 2.6.16-rt10 crash on ppc
From: Nick Piggin @ 2006-03-28 1:21 UTC (permalink / raw)
To: emin ak; +Cc: linux-kernel, Ingo Molnar
In-Reply-To: <2cf1ee820603271231l69187925j3150098097c7ca15@mail.gmail.com>
emin ak wrote:
>Dear all,
>Today I have tried Ingo Molnar's patch-2.6.16-rt10 on a ppc (PQ3 MPC8540ADS)
>For testing purpose I have enabled packet routing and send ethernet
>packets over the system with a network test equipment. under light
>load on ethernet, the system is working fine, but under heavy load,
>firstly console freezes, then the message below prints on the console
>again and again. The system without patch is working fine on light or
>heavy loads. What can be the problem, is there a bug or am i doing
>something wrong?
>Thanks alot..
>here is the console output
>--------------------------console output-----
>softirq-net-rx/: page allocation failure. order:0, mode:0x20
>Call Trace:
>[C04E3DB0] [C000A60C] show_stack+0x50/0x188 (unreliable)
>[C04E3DE0] [C004C3EC] __alloc_pages+0x1c8/0x2a4
>[C04E3E30] [C0063C90] cache_alloc_refill+0x35c/0x57c
>[C04E3E80] [C0063FA4] __kmalloc+0xf4/0xfc
>[C04E3EB0] [C012D460] __alloc_skb+0x58/0x118
>[C04E3ED0] [C011AF20] gfar_new_skb+0x40/0xd4
>[C04E3EF0] [C011D320] gfar_clean_rx_ring+0x25c/0x634
>[C04E3F30] [C011D72C] gfar_poll+0x34/0x140
>[C04E3F50] [C013364C] net_rx_action+0x94/0x188
>[C04E3F80] [C0026730] ksoftirqd+0x104/0x1b4
>[C04E3FC0] [C003779C] kthread+0xf8/0x100
>[C04E3FF0] [C0004DB8] kernel_thread+0x44/0x60
>Mem-info:
>DMA per-cpu:
>cpu 0 hot: high 90, batch 15 used:0
>cpu 0 cold: high 30, batch 7 used:0
>DMA32 per-cpu: empty
>Normal per-cpu: empty
>HighMem per-cpu: empty
>Free pages: 768kB (0kB HighMem)
>Active:1650 inactive:2036 dirty:0 writeback:0 unstable:0 free:192
>slab:60106 mapped:764 pagetables:29
>DMA free:768kB min:2048kB low:2560kB high:3072kB active:6600kB
>inactive:8144kB present:262144kB pages_scanned:0 all_unreclaimab
>le? no
>lowmem_reserve[]: 0 0 0 0
>
You have plenty of memory that should be reclaimable (active+inactive,
though
some may be mlocked or otherwise unreclaimable).
What it looks like is that the page reclaim is not able to take place,
because
all your allocations are coming from interrupt context.
Normally what will happen is that kswapd will be woken up, and ksoftirqd
will
start throttling (soft) interrupts and kswapd will be allowed to get a
chance
to run. With the -rt kernel, I guess if your network irq has a higher
priority
than kswapd, it could prevent it from running completely. (I could be wrong
here).
You might try increasing /proc/sys/vm/min_free_kbytes, or failing that,
increase
the priority of kswapd to something comparable to or greater than your
network
interrupt.
I'm not very familiar with the -rt tree, but possibly what should be
happening,
if interrupts are executed in process context and allowed to schedule,
is that
their memory allocations should also be allowed to reclaim memory.
OTOH, I guess for a deterministic realtime system, you need to allocate
fixed
minimum amounts of memory for each element of the system so you never
run out
like this.
--
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: HZ != 1000 causes problem with serial device shown by git-bisect
From: Lee Revell @ 2006-03-28 1:27 UTC (permalink / raw)
To: Greg Lee; +Cc: linux-kernel, rmk+kernel
In-Reply-To: <0e6601c651f8$9d253b40$a100a8c0@casabyte.com>
On Mon, 2006-03-27 at 18:46 -0500, Greg Lee wrote:
> I have also tried a number of other kernels and the problem exists all
> the way to 2.6.15.6
> but is fixed in 2.6.16, so I am going to git-bisect 2.6.15.6 to
> 2.6.16, but I thought I
> would get this message out now in case someone has an inkling of what
> the problem is.
If it's fixed in 2.6.16, what's the problem? It's not as if we can go
back and fix those old kernels...
Lee
^ permalink raw reply
* Re: [PATCH] Add ALL_LDFLAGS to the git target.
From: Junio C Hamano @ 2006-03-28 1:25 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <13226.1143508524@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> For some reason, I need ALL_LDFLAGS in the git target only on
> AIX.
I wonder what the dependency is, since ALL_LDFLAGS is not
modified on AIX, but you are right. That is the only binary
that does not link with ALL_LDFLAGS which can include whatever
user passes via LDFLAGS.
> Once it builds, only one test "fails" on AIX 5.1 with
> 1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
> odd tool problem in the tester + my setup and not a real bug.
Curious and would appreciate more details.
^ permalink raw reply
* Re: hda-intel woes
From: Kyle Moffett @ 2006-03-28 1:22 UTC (permalink / raw)
To: Jeff V. Merkey
Cc: Friedrich Göpel, LKML Kernel, alsa-user, Lee Revell,
Takashi Iwai
In-Reply-To: <4428872E.3020308@wolfmountaingroup.com>
On Mar 27, 2006, at 19:45:34, Jeff V. Merkey wrote:
> Visit www.redhat.com. Purchase a support contract for customer
> service, fastest way to get help.
First of all, Jeff, no need to be rude, he asked a reasonable
question and provided all the pertinent useful info. You also
committed the grievous mailing-list etiquette violation of top-
posting. A more polite and useful response is as follows:
Friedrich Göpel wrote:
> This same message was sent to the alsa mailinglist 3 weeks ago, but
> it still seems to be waiting on being moderated, so I'm resending
> this here.
Hi! Unfortunately messages tend to get lost on occasion due to the
sheer volume of email. Sometimes you may have to resend a couple
times to get a response. It also helps if you add relevant CC's from
the MAINTAINERS file (added to this message). You can also file a
bug report on the ALSA bug tracker, I think the ALSA people tend to
be fairly good about keeping up with that; sometimes more so than the
mailing list.
Cheers,
Kyle Moffett
Remainder copied verbatim for those added to the CC:
> Hi,
>
> I tried installing linux on my sister's new acer extensa 6700
> laptop. I tried Fedora FC4, FC5 test 3 and now Gentoo with various
> kernel and alsa versions (specifically 1.0.10 and 1.0.11-rc3 and
> whatever is in fedora before and after a full update). Also I set
> up a friends vaio laptop also with an intel hd audio chip, which is
> working peachy. I also tried model=basic/hp/fujitsu just in case.
>
> Just to preempt the question: I did unmute and raise the mixer levels.
>
> Anyways the damn thing is not to be convinced to produce a single
> sound.
>
> In light of this I suppose Acer did something nasty to that chip.
>
> I'm attatching here the relevant part of lspci -vv in hopes of
> somebody being either able to point out a fix or tell me if it's
> going to be supported sometime soon.
>
> I could pose as a genuea pig if neccessary. Also if there is any
> further information I should gather just tell me.
>
> Otherwise it's back to windows for my sister I guess.
>
> PS. I'm not subscribed to the list so please CC me. Thanks.
>
> 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
> Family) High Definition Audio Controller (rev 04)
> Subsystem: Acer Incorporated [ALI] Unknown device 008f
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Interrupt: pin A routed to IRQ 177
> Region 0: Memory at d000c000 (64-bit, non-prefetchable)
> [size=16K]
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0
> +,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [60] Message Signalled Interrupts: 64bit+
> Queue=0/0 Enable-
> Address: 0000000000000000 Data: 0000
> Capabilities: [70] Express Unknown type IRQ 0
> Device: Supported: MaxPayload 128 bytes, PhantFunc
> 0, ExtTag-
> Device: Latency L0s <64ns, L1 <1us
> Device: Errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
> Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
> Link: Supported Speed unknown, Width x0, ASPM
> unknown, Port 0
> Link: Latency L0s <64ns, L1 <1us
> Link: ASPM Disabled CommClk- ExtSynch-
> Link: Speed unknown, Width x0
> Capabilities: [100] Virtual Channel
> Capabilities: [130] Unknown (5)
^ permalink raw reply
* Re: 2.6.16-mm1 leaks in dvb playback
From: Andrew Morton @ 2006-03-28 1:23 UTC (permalink / raw)
To: adrian; +Cc: linux-kernel
In-Reply-To: <20060326211514.GA19287@wyvern.smop.co.uk>
Adrian Bridgett <adrian@smop.co.uk> wrote:
>
> I've had this problem for a little while (probably since 2.6.14/15
> era) but I've only recently spent some time to figure out what's been
> going wrong.
>
> There is a patch in the -mm series which causes leaks in both
> sock_inode_cache and dentry_cache for me during DVB playback (thanks
> to slabtop).
>
> 2.6.16 is fine (no leakage), 2.6.16-mm1 has this problem (~ 2MB/s in
> each cache).
Do you mean that the problem has been present in -mm kernels since the
2.6.14/15 timeframe, and not in mainline?
> I'm using dvbstream and sending the output to /dev/null, dvb modules
> loaded are dvb_usb_vp7045, dvb_usb, dvb_core, dvb_pll. It's an EHCI USB
> device running on a Dell D600 latitude.
>
> turning on some debugging and looking at /proc/slab_allocators and
> /proc/page_owners shows that the most prevalent page owners are:
>
> (5363 out of 5631)
> Page allocated via order 0, mask 0xd0
> [0xc0161079] poison_obj+41
> [0xc0162355] cache_alloc_refill+981
> [0xc0161889] cache_alloc_debugcheck_after+169
> [0xc01d5169] vsnprintf+857
> [0xc0247eec] lock_sock+204
> [0xc0244999] sock_alloc_inode+25
> [0xc0161f73] kmem_cache_alloc+131
> [0xc027a4b4] inet_csk_accept+436
>
> (1989 out of 2734)
> Page allocated via order 0, mask 0xd0
> [0xc0162355] cache_alloc_refill+981
> [0xc0161079] poison_obj+41
> [0xc0161079] poison_obj+41
> [0xc01d5169] vsnprintf+857
> [0xc0182341] d_alloc+33
> [0xc0161f73] kmem_cache_alloc+131
> [0xc0182341] d_alloc+33
> [0xc02461e0] sock_attach_fd+96
>
Strange. Are you sure that they really leak? Doing
echo 3 > /proc/sys/vm/drop_caches
doesn't make them go away?
^ permalink raw reply
* Re: regular swsusp flamewar
From: Harald Arnesen @ 2006-03-28 1:18 UTC (permalink / raw)
To: Nigel Cunningham
Cc: Pavel Machek, Mark Lord, Rafael J. Wysocki,
Linux Kernel Mailing List, Andrew Morton
In-Reply-To: <200603280936.31365.ncunningham@cyclades.com>
Nigel Cunningham <ncunningham@cyclades.com> writes:
> Hello.
>
> I'm not playing that game again.
>
> Instead I'm letting you know that I'm building a git tree at the moment, and
> hope to start posting patches from it shortly and seeking to merge Suspend2.
> A few weeks ago I lacked the motivation to do it, but that has since changed.
>
> If you want to provide useful, technical comments on how I can do things
> better, I'll be happy to accept and apply them. If on the other hand you
> attempt to start another flamewar, I'll just seek to exercise my self control
> and let those comments fall to the floor.
_Please_ continue, Nigel! We (at least I) need a working suspend, and it
would be a great benefit to have it in the vanilla kernel.
--
Hilsen Harald.
^ permalink raw reply
* Re: regular swsusp flamewar
From: Harald Arnesen @ 2006-03-28 1:16 UTC (permalink / raw)
To: Pavel Machek
Cc: Nigel Cunningham, Mark Lord, Rafael J. Wysocki,
Linux Kernel Mailing List, Andrew Morton
In-Reply-To: <20060327231557.GB2439@elf.ucw.cz>
Pavel Machek <pavel@suse.cz> writes:
>> You know that I disagree that doing suspend in userspace is the
>> right
>
> You know "disagreeing" with subsystem maintainer (and everyone else
> for that matter) is not exactly helpful in getting patches merged. You
> are free to believe whatever you want, but if you disagree on
> something as fundamental as "do not put unneccessary code to kernel"
> with me, it should be no surprise that I "disagree" with your patches
> (*).
>
>> approach, and you know that current uswsusp can't do everything Suspend2 does
>> without further substantial modification. Please stop painting me as the bad
>> guy because I won't roll over and play dead for you. Please also
>> stop
>
> I'm not trying to paint you as a bad guy. But Mark said you are trying
> to help, and in that context I'd read it as "trying to help mainline
> development". And you are not doing that, you are developing your own
> suspend2 branch, that has nothing to do with mainline. I think we can
> agree on that one...
The main point for me is that suspend2 works, while mainline supspend
does not ("works": it takes less time to suspend/resume than to
shutdown/reboot).
I haven't tried uswsusp yet. Why try another out-of-kernel suspend when
suspend2 works perfectly?
--
Hilsen Harald.
^ permalink raw reply
* [PATCH] Add ALL_LDFLAGS to the git target.
From: Jason Riedy @ 2006-03-28 1:15 UTC (permalink / raw)
To: git
In-Reply-To: <7v64lzo1j7.fsf@assigned-by-dhcp.cox.net>
For some reason, I need ALL_LDFLAGS in the git target only on
AIX. Once it builds, only one test "fails" on AIX 5.1 with
1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
odd tool problem in the tester + my setup and not a real bug.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
diff --git a/Makefile b/Makefile
index 4edb383..d945546 100644
--- a/Makefile
+++ b/Makefile
@@ -455,7 +455,8 @@ strip: $(PROGRAMS) git$X
git$X: git.c common-cmds.h $(LIB_FILE)
$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
- $(ALL_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE) $(LIBS)
+ $(ALL_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE) \
+ $(ALL_LDFLAGS) $(LIBS)
common-cmds.h: Documentation/git-*.txt
./generate-cmdlist.sh > $@
^ permalink raw reply related
* Re: [PATCH] MTD: m25p80: fix printk format warning
From: Josh Boyer @ 2006-03-28 1:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: dwmw2, Randy.Dunlap, linux-mtd, linux-kernel
In-Reply-To: <20060327162053.5d84ae59.akpm@osdl.org>
On 3/27/06, Andrew Morton <akpm@osdl.org> wrote:
> "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
> >
> > Fix printk format warning:
> > drivers/mtd/devices/m25p80.c:189: warning: format '%zd' expects type 'signed size_t', but argument 6 has type 'u_int32_t'
>
> Thanks, this is already fixed in one of the oft-sent, oft-ignored MTD
> patches in -mm.
They aren't ignored by everyone. And I believe the maintainers are
planning on syncing in 2.6.17.
I try to at least Ack patches that look sane to me, but my opinion
doesn't count all that much.
josh
^ permalink raw reply
* [ALSA - driver 0001969]: /acore/hwdep.o Error 1
From: bugtrack @ 2006-03-28 1:10 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1969>
======================================================================
Reported By: shadowfox
Assigned To: perex
======================================================================
Project: ALSA - driver
Issue ID: 1969
Category: 0_compilation problem_!!!
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Distribution: Mandriva 2006
Kernel Version: 2.6.16
======================================================================
Date Submitted: 03-28-2006 03:10 CEST
Last Modified: 03-28-2006 03:10 CEST
======================================================================
Summary: /acore/hwdep.o Error 1
Description:
make[4]: *** [/usr/local/src/alsa/alsa-driver-1.0.10/acore/hwdep.o] Error
1
make[3]: *** [/usr/local/src/alsa/alsa-driver-1.0.10/acore] Error 2
make[2]: *** [_module_/usr/local/src/alsa/alsa-driver-1.0.10] Error 2
make[1]: *** [modules] Error 2
make: *** [compile] Error 2
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
03-28-06 03:10 shadowfox New Issue
03-28-06 03:10 shadowfox File Added: error.log
03-28-06 03:10 shadowfox Distribution => Mandriva 2006
03-28-06 03:10 shadowfox Kernel Version => 2.6.16
======================================================================
-------------------------------------------------------
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: Compaq V2000 Fan Control
From: Matthew Garrett @ 2006-03-28 1:04 UTC (permalink / raw)
To: Bonilla, Alejandro; +Cc: linux-acpi
In-Reply-To: <1143506477.6550.9.camel@ubuntu.americas.hpqcorp.net>
On Mon, Mar 27, 2006 at 06:41:17PM -0600, Bonilla, Alejandro wrote:
> I know I don't have it. Is there a way to debug this and see if it could
> occur or if it just could be that it needs a tweak? Or is definitely not
> going to work?
Your laptop doesn't expose the fan as an ACPI object. As a result,
there's no way to control it through the standard ACPI interfaces.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: John Rigby @ 2006-03-28 1:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060328000703.GA95672@server.idefix.loc>
[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]
try make lite5200_defconfig instead of copying it to .config
or make oldconfig after copying ti to .config
On 3/27/06, Matthias Fechner <idefix@fechner.net> wrote:
>
> Hi,
>
> I installed today ELDK 4.0 for the LITE5200 board (icecube).
> ./install -d /usr/local/eldk ppc_6xx
>
> After compiling u-boot and playing a little bit with it, i tried to
> compile the kernel 2.6.
>
> For this I used the git repository.
> I copied the file arch/ppc/configs/lite5200_defconfig to .config, and
> tried the following one:
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
>
> But i got a failure with the following error message:
> CC arch/ppc/syslib/bestcomm/bestcomm.o
> arch/ppc/syslib/bestcomm/bestcomm.c: In function 'mpc52xx_sdma_probe':
> arch/ppc/syslib/bestcomm/bestcomm.c:269: warning: implicit declaration of
> function 'to_platform_device'
> arch/ppc/syslib/bestcomm/bestcomm.c:269: warning: initialization makes
> pointer from integer without a cast
> arch/ppc/syslib/bestcomm/bestcomm.c:278: warning: implicit declaration of
> function 'platform_get_resource'
> arch/ppc/syslib/bestcomm/bestcomm.c:278: warning: assignment makes pointer
> from integer without a cast
> arch/ppc/syslib/bestcomm/bestcomm.c:279: warning: assignment makes pointer
> from integer without a cast
> arch/ppc/syslib/bestcomm/bestcomm.c: At top level:
> arch/ppc/syslib/bestcomm/bestcomm.c:367: error: 'platform_bus_type'
> undeclared here (not in a function)
> make[2]: *** [arch/ppc/syslib/bestcomm/bestcomm.o] Fehler 1
> make[1]: *** [arch/ppc/syslib/bestcomm] Fehler 2
> make: *** [arch/ppc/syslib] Fehler 2
>
> What is wrong here, I think i did an error on any step...
>
> Thx for help!
>
> Best regards,
> Matthias
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2356 bytes --]
^ permalink raw reply
* Re: [RFC, PATCH 5/24] i386 Vmi code patching
From: Chuck Ebbert @ 2006-03-28 0:52 UTC (permalink / raw)
To: Andi Kleen
Cc: virtualization, Zachary Amsden, linux-kernel, Xen-devel,
Dan Hecht, Chris Wright
In-Reply-To: <200603222115.46926.ak@suse.de>
On Wed, 22 Mar 2006 21:15:44 +0100, Andi Kleen wrote:
> On Monday 13 March 2006 19:02, Zachary Amsden wrote:
> > The VMI ROM detection and code patching mechanism is illustrated in
> > setup.c. There ROM is a binary block published by the hypervisor, and
> > and there are certainly implications of this. ROMs certainly have a
> > history of being proprietary, very differently licensed pieces of
> > software, and mostly under non-free licenses. Before jumping to the
> > conclusion that this is a bad thing, let us consider more carefully
> > why hiding the interface layer to the hypervisor is actually a good
> > thing.
>
> How about you fix all these issues you describe here first
> and then submit it again?
>
> The disassembly stuff indeed doesn't look like something
> that belongs in the kernel.
I think they put the disassembler in there as a joke. ;)
It's not necessary for fixing up the call site, anyway. Something like
this should work, assuming there is always a call in every vmi
translation.
/* Now, measure and emit the vmi translation sequence */
#define vmi_translation_start \
.pushsection .vmi.translation,"ax"; \
781:;
#define vmi_translation_finish \
- 782:; \
+ 783:; \
.popsection;
#define vmi_translation_begin 781b
-#define vmi_translation_end 782b
+#define vmi_call_location 782b
+#define vmi_translation_end 783b
#define vmi_translation_len (vmi_translation_end - vmi_translation_begin)
+#define vmi_call_offset (vmi_call_location - vmi_translation_begin)
#define vmi_call(name) \
- call .+5+name
+ 782: call .+5+name
#define vmi_annotate(name) \
.pushsection .vmi.annotation,"a"; \
.align 4; \
.long name; \
.long vmi_padded_begin; \
.long vmi_translation_begin; \
.byte vmi_padded_len; \
.byte vmi_translation_len; \
.byte vmi_pad_total; \
- .byte 0; \
+ .byte vmi_call_offset; \
.popsection;
struct vmi_annotation {
unsigned long vmi_call;
unsigned char *nativeEIP;
unsigned char *translationEIP;
unsigned char native_size;
unsigned char translation_size;
char nop_size;
- unsigned char pad;
+ unsigned char call_offset;
};
static void fixup_translation(struct vmi_annotation *a)
{
unsigned char *c, *start, *end;
int left;
memcpy(a->nativeEIP, a->translationEIP, a->translation_size);
+ patch_call_site(a, a->nativeEIP + a->call_offset);
- start = a->nativeEIP;
- end = a->nativeEIP + a->translation_size;
-
- for (c = start; c < end;) {
- switch(*c) {
- case MNEM_CALL_NEAR:
- patch_call_site(a, c);
- c+=5;
- break;
-
- case MNEM_PUSH_I:
- c+=5;
- break;
-
- case MNEM_PUSH_IB:
- c+=2;
- break;
-
- case MNEM_PUSH_EAX:
- case MNEM_PUSH_ECX:
- case MNEM_PUSH_EDX:
- case MNEM_PUSH_EBX:
- case MNEM_PUSH_EBP:
- case MNEM_PUSH_ESI:
- case MNEM_PUSH_EDI:
- c+=1;
- break;
-
- case MNEM_LEA:
- BUG_ON(*(c+1) != 0x64); /* [--][--]+disp8, %esp */
- BUG_ON(*(c+2) != 0x24); /* none + %esp */
- c+=4;
- break;
-
- default:
- /*
- * Don't printk - it may acquire spinlocks with
- * partially completed VMI translations, causing
- * nuclear meltdown of the core.
- */
- BUG();
- return;
- }
- }
--
Chuck
"Penguins don't come from next door, they come from the Antarctic!"
^ permalink raw reply
* Re: [RFC][PATCH] extending the libsepol API
From: Ivan Gyurdiev @ 2006-03-28 0:53 UTC (permalink / raw)
To: Kevin Carr; +Cc: sds, selinux, 'Selinux-Dev'
In-Reply-To: <200603221555.k2MFtoNq001984@gotham.columbia.tresys.com>
> In the current implementation there is an issue of who owns the memory in a
> key. The key_create() functions just copy the pointer and not the contents
> of the string, so a key 'object' can live longer than the string used to
> create it and thus is easily misused by users of the library.
Yes, that was probably a design mistake... anyway, the keys are
record-specific, so I'm not sure it's necessary to follow the same
pattern for future keys [ except maybe for consistency ].
> Additionally,
> we thought the memory and programming overhead involved in creating, and
> destroying the keys was undesirable and not necessary. For example when we
> start iterating over all the types in all the rules of the policy, using
> keys can get expensive.
>
A key is used to locate data. Iteration does not involve locating data [
at least the current implementation loops over all the data in order ],
so no keys are used anywhere. There is overhead involved in converting
from base representation to an opaque record, and that's the price for
encapsulation / policy independence. You can probably get rid of the
overhead while keeping encapsulation [ with smarter record
implementation]... but independence of the record from policy seems to
require copying/expanding the data.
I think the existing records would best stay independent from policy,
esp. if they'll be serialized to go over the wire for the policy server.
New records could work differently...
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: Patch question (Hyper-Threading support)
From: Elizeu Santos-Neto @ 2006-03-28 0:52 UTC (permalink / raw)
To: xen-devel
In-Reply-To: <20060324191540.1306291c.tfreeman@mcs.anl.gov>
Hi all,
Well, based on some quick inspections on the that I checked out from
the mercurial repository this afternoon, it seems that the HT support
has been already implemented. :-)
Thus, here is a suggestion, it would be nice to make more details
available about who is doing what and in which phase of development
things are, this information could avoid duplicated efforts.
Thanks,
Eli
On Fri, 2006-03-24 at 19:15 -0600, Tim Freeman wrote:
> On Fri, 24 Mar 2006 13:30:18 -0600
> Elizeu Santos-Neto <elizeu@cs.uchicago.edu> wrote:
>
> >
> > Hi community,
> >
> > I've been working on modifying Xen and the Xen-Linux kernel to make
> > vCPU better represent Hyper-Threading physical CPUs, as I mentioned in a
> > previous post.
> >
> > http://lists.xensource.com/archives/html/xen-devel/2006-01/msg00853.html
> >
> > I produced some performance measurements and patches that might be
> > useful for some Hyper-Threading friendly workloads running on Xen. I'll
> > make the performance measurement report available soon.
> >
> > Basically, the modified files were:
> >
> > xen/common/domain.c
> > xen/common/sched_bvt.c
> > xen/common/sched_sedf.c
> > xen/common/schedule.c
> > xen/include/public/vcpu.h
> > xen/include/xen/sched.h
> > xen/arch/x86/smpboot.c
> >
> > How should I proceed to send the patch?
>
>
> There is a guide here:
>
> http://wiki.xensource.com/xenwiki/SubmittingXenPatches
>
> For examples, see:
>
> http://lists.xensource.com/archives/html/xen-devel/
>
> Also see these guidelines:
>
> http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
> http://linux.yyz.us/patch-format.html
>
> I would think replying to your patch email with the performance measurement
> report would help keep them together for people.
>
> Tim
>
>
>
^ permalink raw reply
* [lm-sensors] [PATCH 2.6.16-mm1 3/3] rtc: add support for m41t81
From: Andrew Morton @ 2006-03-28 0:51 UTC (permalink / raw)
To: Mark A. Greer; +Cc: mgreer, lm-sensors, r.marek, khali, linux-kernel
In-Reply-To: <20060328002625.GE21077@mag.az.mvista.com>
"Mark A. Greer" <mgreer at mvista.com> wrote:
>
> Resend...
> ---
>
> drivers/i2c/chips/m41t00.c | 294 ++++++++++++++++++++++++++++++++++-----------
> include/linux/m41t00.h | 50 +++++++
Not sure what to make of this. It has no changelog, it doesn't apply on
top of your previous three patches:
rtc-m41t00-driver-should-use-workqueue-instead-of-tasklet.patch
rtc-m41t00-driver-cleanup.patch
rtc-add-support-for-m41t81-m41t85-chips-to-m41t00-driver.patch
and it doesn't apply when used to replace
rtc-add-support-for-m41t81-m41t85-chips-to-m41t00-driver.patch.
An incremental patch against the three above patches would be ideal...
^ permalink raw reply
* 2.6.16-git4: kernel BUG at block/ll_rw_blk.c:3497
From: Mark Lord @ 2006-03-28 0:51 UTC (permalink / raw)
To: Linux Kernel
This popped up during heavy RAID5 testing today (2.6.16-git4).
The SATA drives are being run by a modified sata_mv that I'm testing,
and it seems to be behaving now, except for the BUG below:
Cheers
------------[ cut here ]------------
kernel BUG at block/ll_rw_blk.c:3497!
invalid opcode: 0000 [#1]
PREEMPT SMP
Modules linked in: sata_mv libata raid5 xor snd_pcm_oss snd_pcm snd_timer
snd_page_alloc snd_mixer_oss snd soundcore edd pl2303 usbserial usblp usbhid
evdev joydev sg sr_mod ide_cd cdrom af_packet ohci_hcd sworks_agp agpgart e100
mii i2c_piix4 i2c_core usbcore sd_mod dm_mod scsi_mod
CPU: 1
EIP: 0060:[<b0209e76>] Not tainted VLI
EFLAGS: 00010246 (2.6.16-git4 #1)
EIP is at put_io_context+0x66/0x80
eax: 00000000 ebx: b1ac096c ecx: e3ced12c edx: ef25b798
esi: ed72a570 edi: ed72aa20 ebp: 00000000 esp: d2619f78
ds: 007b es: 007b ss: 0068
Process cat (pid: 16399, threadinfo=d2618000 task=ed72a570)
Stack: <0>b19acba0 b0124ea5 00000004 d2619fbc d2619fbc b035c26b 00000001 00000000
e043b660 d2618000 00000000 b0125097 00000000 3abf1f04 3abf1f04 d2618000
b0102e1b 00000000 00000000 00000000 3abf1f04 3abf1f04 aff1e8d8 000000fc
Call Trace:
[<b0124ea5>] do_exit+0x295/0x410
[<b0125097>] do_group_exit+0x37/0xa0
[<b0102e1b>] sysenter_past_esp+0x54/0x75
Code: 75 22 b8 00 e0 ff ff 21 e0 ff 48 14 8b 40 08 a8 08 75 24 89 da 5b a1 44 b8
46 b0 e9 65 6a f5 ff ff d2 eb d0 90 ff d2 eb d9 5b c3 <0f> 0b a9 0d 2c ac 36 b0
89 f6 eb 9b e8 79 f2 12 00 eb d5 8d b4
<1>Fixing recursive fault but reboot is needed!
... later on ...
Unable to handle kernel paging request at virtual address 00100104
printing eip:
b0212078
*pde = 00000000
Oops: 0002 [#2]
PREEMPT SMP
Modules linked in: sata_mv libata raid5 xor snd_pcm_oss snd_pcm snd_timer
snd_page_alloc snd_mixer_oss snd soundcore edd pl2303 usbserial usblp usbhid
evdev joydev sg sr_mod ide_cd cdrom af_packet ohci_hcd sworks_agp agpgart e100
mii i2c_piix4 i2c_core usbcore sd_mod dm_mod scsi_mod
CPU: 1
EIP: 0060:[<b0212078>] Not tainted VLI
EFLAGS: 00010206 (2.6.16-git4 #1)
EIP is at cfq_get_io_context+0xd8/0x1a0
eax: 00100100 ebx: ef25b7e4 ecx: efce7a80 edx: 00200200
esi: ef25b208 edi: e3ced000 ebp: b1ac0480 esp: efd01a08
ds: 007b es: 007b ss: 0068
Process kswapd0 (pid: 64, threadinfo=efd00000 task=efcb5590)
Stack: <0>00000010 b03a9508 efcb5590 e3ced000 00000000 b02129c4 00011200 00000000
b01464aa 00000001 ef25b76c cbf9e094 ee47e7fc b03a9508 ee47e7fc 00000001
ee47e80c b020526c 00000010 cbf9e094 ee47e7fc b0208277 00000010 00000001
Call Trace:
[<b02129c4>] cfq_set_request+0x54/0x1f0
[<b01464aa>] mempool_alloc+0x2a/0xe0
[<b020526c>] elv_set_request+0x3c/0x50
[<b0208277>] get_request+0x247/0x2b0
[<b02082fb>] get_request_wait+0x1b/0x120
[<b0208f4d>] __make_request+0x9d/0x420
[<f0ba08f5>] xor_block+0xc5/0xe0 [xor]
[<b0209437>] generic_make_request+0xe7/0x160
[<f0baee96>] handle_stripe+0x12c6/0x1470 [raid5]
[<f0bacc79>] raid5_build_block+0x29/0x90 [raid5]
[<f0bac3f5>] init_stripe+0x125/0x150 [raid5]
[<f0baf67f>] make_request+0x28f/0x300 [raid5]
[<b01366c0>] autoremove_wake_function+0x0/0x50
[<b01366c0>] autoremove_wake_function+0x0/0x50
[<b0209437>] generic_make_request+0xe7/0x160
[<b01604ba>] cache_alloc_refill+0x1da/0x240
[<b0209500>] submit_bio+0x50/0xe0
[<b0168f29>] bio_alloc_bioset+0x89/0x170
[<b01687ce>] submit_bh+0x13e/0x190
[<b0166cb4>] __block_write_full_page+0x204/0x370
[<b01c09f0>] ext2_get_block+0x0/0x370
[<b01685f9>] block_write_full_page+0xe9/0x100
[<b01c09f0>] ext2_get_block+0x0/0x370
[<b014c0f1>] pageout+0xc1/0x140
[<b014c1fe>] remove_mapping+0x8e/0xb0
[<b014c411>] shrink_list+0x1f1/0x410
[<b014b075>] __pagevec_release+0x15/0x20
[<b014cd6d>] refill_inactive_zone+0x39d/0x420
[<b014c7a3>] shrink_cache+0xb3/0x2e0
[<b014bdf9>] shrink_slab+0x99/0x1e0
[<b0149475>] throttle_vm_writeout+0x35/0x70
[<b014ce94>] shrink_zone+0xa4/0xd0
[<b014d39f>] balance_pgdat+0x28f/0x3e0
[<b014d5cd>] kswapd+0xdd/0x130
[<b01366c0>] autoremove_wake_function+0x0/0x50
[<b0102d52>] ret_from_fork+0x6/0x14
[<b01366c0>] autoremove_wake_function+0x0/0x50
[<b014d4f0>] kswapd+0x0/0x130
[<b01011fd>] kernel_thread_helper+0x5/0x18
Code: e8 93 3a b0 89 4a 04 89 97 2c 01 00 00 e8 41 8a 12 00 89 de 89 f0 5a 5b 5e
5f 5d c3 b8 e8 93 3a b0 e8 7d 87 12 00 8b 53 04 8b 03 <89> 50 04 89 02 b8 e8 93
3a b0 c7 03 00 01 10 00 c7 43 04 00 02
<6>note: kswapd0[64] exited with preempt_count 1
Unable to handle kernel paging request at virtual address 00100100
printing eip:
b0211ac9
*pde = 00000000
Oops: 0000 [#3]
PREEMPT SMP
Modules linked in: sata_mv libata raid5 xor snd_pcm_oss snd_pcm snd_timer
snd_page_alloc snd_mixer_oss snd soundcore edd pl2303 usbserial usblp usbhid
evdev joydev sg sr_mod ide_cd cdrom af_packet ohci_hcd sworks_agp agpgart e100
mii i2c_piix4 i2c_core usbcore sd_mod dm_mod scsi_mod
CPU: 1
EIP: 0060:[<b0211ac9>] Not tainted VLI
EFLAGS: 00010096 (2.6.16-git4 #1)
EIP is at cfq_exit_io_context+0x29/0x50
eax: ef25b7e4 ebx: 00100100 ecx: ef25b540 edx: ef25b48c
esi: ef25b208 edi: 00000286 ebp: 0000000b esp: efd018f4
ds: 007b es: 007b ss: 0068
Process kswapd0 (pid: 64, threadinfo=efd00000 task=efcb5590)
Stack: <0>efd00000 00000292 b1ac0480 b0209f16 b19acba0 efcb5590 efcb5a40 b0124ea5
b035d520 efcb5734 00000040 00000001 00000001 efd00000 00000000 ffffffff
0000000b b01041b3 b037494a b035c2cd 00000002 00000002 00000202 efd019d4
Call Trace:
[<b0209f16>] exit_io_context+0x86/0xa0
[<b0124ea5>] do_exit+0x295/0x410
[<b01041b3>] die+0x193/0x1a0
[<b01185e0>] do_page_fault+0x0/0x527
[<b01185e0>] do_page_fault+0x0/0x527
[<b0118973>] do_page_fault+0x393/0x527
[<b01185e0>] do_page_fault+0x0/0x527
[<b010399b>] error_code+0x4f/0x54
[<b0212078>] cfq_get_io_context+0xd8/0x1a0
[<b02129c4>] cfq_set_request+0x54/0x1f0
[<b01464aa>] mempool_alloc+0x2a/0xe0
[<b020526c>] elv_set_request+0x3c/0x50
[<b0208277>] get_request+0x247/0x2b0
[<b02082fb>] get_request_wait+0x1b/0x120
[<b0208f4d>] __make_request+0x9d/0x420
[<f0ba08f5>] xor_block+0xc5/0xe0 [xor]
[<b0209437>] generic_make_request+0xe7/0x160
[<f0baee96>] handle_stripe+0x12c6/0x1470 [raid5]
[<f0bacc79>] raid5_build_block+0x29/0x90 [raid5]
[<f0bac3f5>] init_stripe+0x125/0x150 [raid5]
[<f0baf67f>] make_request+0x28f/0x300 [raid5]
[<b01366c0>] autoremove_wake_function+0x0/0x50
[<b01366c0>] autoremove_wake_function+0x0/0x50
[<b0209437>] generic_make_request+0xe7/0x160
[<b01604ba>] cache_alloc_refill+0x1da/0x240
[<b0209500>] submit_bio+0x50/0xe0
[<b0168f29>] bio_alloc_bioset+0x89/0x170
[<b01687ce>] submit_bh+0x13e/0x190
[<b0166cb4>] __block_write_full_page+0x204/0x370
[<b01c09f0>] ext2_get_block+0x0/0x370
[<b01685f9>] block_write_full_page+0xe9/0x100
[<b01c09f0>] ext2_get_block+0x0/0x370
[<b014c0f1>] pageout+0xc1/0x140
[<b014c1fe>] remove_mapping+0x8e/0xb0
[<b014c411>] shrink_list+0x1f1/0x410
[<b014b075>] __pagevec_release+0x15/0x20
[<b014cd6d>] refill_inactive_zone+0x39d/0x420
[<b014c7a3>] shrink_cache+0xb3/0x2e0
[<b014bdf9>] shrink_slab+0x99/0x1e0
[<b0149475>] throttle_vm_writeout+0x35/0x70
[<b014ce94>] shrink_zone+0xa4/0xd0
[<b014d39f>] balance_pgdat+0x28f/0x3e0
[<b014d5cd>] kswapd+0xdd/0x130
[<b01366c0>] autoremove_wake_function+0x0/0x50
[<b0102d52>] ret_from_fork+0x6/0x14
[<b01366c0>] autoremove_wake_function+0x0/0x50
[<b014d4f0>] kswapd+0x0/0x130
[<b01011fd>] kernel_thread_helper+0x5/0x18
Code: 00 00 57 56 89 c6 53 9c 5f fa b8 e8 93 3a b0 e8 3e 8d 12 00 8b 1e 8b 03 0f
18 00 90 39 f3 74 15 89 f6 89 d8 e8 b9 fe ff ff 8b 1b <8b> 03 0f 18 00 90 39 f3
75 ed 89 f0 e8 a6 fe ff ff b8 e8 93 3a
<1>Fixing recursive fault but reboot is needed!
^ permalink raw reply
* Re: [PATCH 2.6.16-mm1 3/3] rtc: add support for m41t81 & m41t85 chips to m41t00 driver
From: Andrew Morton @ 2006-03-28 0:51 UTC (permalink / raw)
To: Mark A. Greer; +Cc: mgreer, lm-sensors, r.marek, khali, linux-kernel
In-Reply-To: <20060328002625.GE21077@mag.az.mvista.com>
"Mark A. Greer" <mgreer@mvista.com> wrote:
>
> Resend...
> ---
>
> drivers/i2c/chips/m41t00.c | 294 ++++++++++++++++++++++++++++++++++-----------
> include/linux/m41t00.h | 50 +++++++
Not sure what to make of this. It has no changelog, it doesn't apply on
top of your previous three patches:
rtc-m41t00-driver-should-use-workqueue-instead-of-tasklet.patch
rtc-m41t00-driver-cleanup.patch
rtc-add-support-for-m41t81-m41t85-chips-to-m41t00-driver.patch
and it doesn't apply when used to replace
rtc-add-support-for-m41t81-m41t85-chips-to-m41t00-driver.patch.
An incremental patch against the three above patches would be ideal...
^ permalink raw reply
* Re: [RFC][PATCH] extending the libsepol API
From: Ivan Gyurdiev @ 2006-03-28 0:42 UTC (permalink / raw)
To: Kevin Carr; +Cc: sds, selinux, SELinux-dev
In-Reply-To: <200603231923.k2NJNMNq014574@gotham.columbia.tresys.com>
>>> Also iterators can be used consistently across the
>>> entire API and every usage is the same as far as the user is concerned.
>>>
So, that's essentially an "Iterable" interface that you want to create,
which is implemented by all records.
I like OOP ideas, and inheritance/interfaces... otoh I don't like void*
and casting from it.
I think OOP ideas help when you want to put multiple object types in the
same framework - is this necessary here?
I don't think it increases readability otherwise.
By the way, this argument extends to the dbase interface in libsemanage.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [PATCH] loop.c to use write ops for fs requiring special locking
From: Andrew Morton @ 2006-03-28 0:44 UTC (permalink / raw)
To: Robert S Peterson; +Cc: aia21, linux-fsdevel
In-Reply-To: <1143496322.10856.22.camel@technetium.msp.redhat.com>
Robert S Peterson <rpeterso@redhat.com> wrote:
>
> Use normal write file operations rather than AOPS prepare_write and
> commit_write when the backing filesystem requires special locking.
>
> ..
>
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -44,6 +44,11 @@
> * backing filesystem.
> * Anton Altaparmakov, 16 Feb 2005
> *
> + * Extension of Anton's idea: Use normal write file operations rather than
> + * prepare_write and commit_write when the backing filesystem requires
> + * special locking.
> + * Robert Peterson <rpeterso@redhat.com>, 01 Mar 2006
> + *
The preferred convention is not to put changelogs into .c files. The
revision control system is where such info is kept.
> * Still To Fix:
> * - Advisory locking is ignored here.
> * - Should use an own CAP_* category instead of CAP_SYS_ADMIN
> @@ -74,6 +79,7 @@
> #include <linux/completion.h>
> #include <linux/highmem.h>
> #include <linux/gfp.h>
> +#include <linux/mount.h>
>
> #include <asm/uaccess.h>
>
> @@ -791,7 +797,8 @@ static int loop_set_fd(struct loop_devic
> */
> if (!file->f_op->sendfile)
> goto out_putf;
> - if (aops->prepare_write && aops->commit_write)
> + if (!(file->f_vfsmnt->mnt_sb->s_type->fs_flags & FS_AOPS_NEED_LOCKING) &&
> + aops->prepare_write && aops->commit_write)
> lo_flags |= LO_FLAGS_USE_AOPS;
> if (!(lo_flags & LO_FLAGS_USE_AOPS) && !file->f_op->write)
> lo_flags |= LO_FLAGS_READ_ONLY;
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 9d96749..3def72e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -88,6 +88,7 @@ extern int dir_notify_enable;
> /* public flags for file_system_type */
> #define FS_REQUIRES_DEV 1
> #define FS_BINARY_MOUNTDATA 2
> +#define FS_AOPS_NEED_LOCKING 4 /* Filesystem aops have special locking needs */
> #define FS_REVAL_DOT 16384 /* Check the paths ".", ".." for staleness */
> #define FS_ODD_RENAME 32768 /* Temporary stuff; will go away as soon
> * as nfs_rename() will be cleaned up
FS_AOPS_NEED_LOCKING is too poorly defined. "locking" of what?? All that
should be defined with some precision and documented at least in the
changelog and preferably in a code comment above the FS_AOPS_NEED_LOCKING
definition site. And the name "FS_AOPS_NEED_LOCKING" itself is very vague.
Plus we have no in-kernel users of this new flag from which to glean some
understanding of what it means, so the documentation requirements become
higher.
I don't think the fact that the filesystem does or doesn't use locking is
relevant to this patch. Why not call the thing FS_LOOP_USE_READ_WRITE?
AFter all, that's what it does.
I assume this new flag is needed for some out-of-tree filesystem? If so,
the changelog should have described which one, and why it needs this flag,
and how it will be using it, etc.
I'm not averse to putting some tweaks into core kernel to support
out-of-tree GPL code - if it's of significant benefit to the owners of that
code (like: our code will now run when loaded into unmodified vendor
kernels) and has a minor impact on the kernel.org tree, then why not? But
it does need to be a good change, and one which is carefully and completely
described, please.
^ permalink raw reply
* RE: Compaq V2000 Fan Control
From: Bonilla, Alejandro @ 2006-03-28 0:41 UTC (permalink / raw)
To: Karasyov, Konstantin A; +Cc: linux-acpi
In-Reply-To: <E124AAE027DA384D8B919F93E4D8C7080182A5C2@mssmsx402nb>
On Mon, 2006-03-27 at 16:25 +0400, Karasyov, Konstantin A wrote:
> Hi,
>
> >cat /proc/acpi/thermal_zone/THR1/trip_points
> >critical (S5): 95 C
> >passive: 88 C: tc1=2 tc2=3 tsp=50 devices=0xdf64a940
>
> This means, that you don't have fan control (i.e. active cooling)
> through ACPI functionality - only passive cooling (i.e. decreasing
> frequency, using throttling) is possible for this thermal zone. So, in
> this string
I know I don't have it. Is there a way to debug this and see if it could
occur or if it just could be that it needs a tweak? Or is definitely not
going to work?
.Alejandro
>
> >echo 100:0:50:80:70:50 > /proc/acpi/thermal_zone/THR1/trip_points
>
> the only meaningful values are the first and the third (but at least 5
> trip points are required -
> <critical>:<hot>:<passive>:<active0>:<active1>)
>
>
> Regards.
> Konstantin.
>
> >-----Original Message-----
> >From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> >owner@vger.kernel.org] On Behalf Of Bonilla, Alejandro
> >Sent: Friday, March 24, 2006 11:28 PM
> >To: linux-acpi@vger.kernel.org
> >Subject: Compaq V2000 Fan Control
> >
> >Hi,
> >
> >I'm trying to make my Compaq laptop give me control over the fan using
> >ACPI, but this ain't working. I have to be honest. I don't know much
> >about debugging acpi or about tools that will tell me much more.
> >
> >Here is what I try:
> >
> >echo 100:0:50:80:70:50 > /proc/acpi/thermal_zone/THR1/trip_points
> >
> >If I set the critical to a value lower than what it is now, it will
> halt
> >the PC, which is good. (100)
> >
> >If I set the passive to 50, nothing occurs. The Fan is not kicked if
> the
> >temp is higher, like 60c.
> >
> >I was told the last value is the one that triggers the Fan. Still, it
> >just won't work for me.
> >
> >This is the value that comes up on boot:
> >cat /proc/acpi/thermal_zone/THR1/trip_points
> >critical (S5): 95 C
> >passive: 88 C: tc1=2 tc2=3 tsp=50 devices=0xdf64a940
> >
> >If I set the critical value to something really low, the Fan will kick
> >in at it's full power and will try to cool down the PC, but that is
> >while it's already halting.
> >
> >Anyone has a clue for me?
> >
> >Thanks,
> >.Alejandro
> >
> >
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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: RE: Re: "xm list" causing "OverflowError:int exceedsXML-RPC limits"
From: Puthiyaparambil, Aravindh @ 2006-03-28 0:35 UTC (permalink / raw)
To: Anthony Liguori, xen-devel
Anthony,
> http://www.cs.utexas.edu/users/aliguori/xend-xmlrpc-large-ints.diff
Thanks for the patch. It fixed the issue.
>
> It should solve your problem. Your machine has more than 2G of memory
> right?
Yes, my machine has more than 2GB of RAM. Strangely I did not see this
on one of my Dell x86_64 box, which has 4GB of RAM. I only saw this
issue on the ES7000 which has 64GB of RAM.
Aravindh
^ 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.