* Re: [PATCH] tcp: do not promote SPLICE_F_NONBLOCK to socket O_NONBLOCK
From: Octavian Purdila @ 2008-07-18 15:50 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev, linux-kernel, axboe
In-Reply-To: <20080718143219.GA905@2ka.mipt.ru>
> Why? There is clearly documented behaviour of the call, it works exactly
> like it is supposed to work - it tries to be non-blocking everywhere
> where it can, but not always, that's why there is a sentence which
> states that even with given flag call may block.
I think that it tries a bit too hard to be non-blocking in the TCP receive
implementation, and that is causing problems for some usecases.
And (sorry for saying this again - it will be the last time) to me it looks
like SPLICE_F_NONBLOCK is intended for the pipe only:
commit 29e350944fdc2dfca102500790d8ad6d6ff4f69d
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Sun Apr 2 12:46:35 2006 -0700
splice: add SPLICE_F_NONBLOCK flag
It doesn't make the splice itself necessarily nonblocking (because the
actual file descriptors that are spliced from/to may block unless they
have the O_NONBLOCK flag set), but it makes the splice pipe operations
nonblocking.
>
> If there are 20 packets in the queue it will get 16 and put them into
> another end (in the next call in your example). Where will it block?
>
It will take 17 because this is what the user requested. And when trying to
push the 17th on the pipe, it will block. I base this both on experiments and
on my understanding of the tcp splice receive implementation.
>
> I really do not think that there is any kind of problem with current
> behaviour, and thus there is no need to introduce additional flags
> and/or change existing behaviour, but I can understand you that existing
> approach does not met your expectation, so you are trying to change it.
> I've added Jens Axboe to copy list, who is responsible for splice
> design.
>
> Btw, you are also trying to change existing userspace API, which may be
> very much forbidden at this stage.
If people here will be telling me that for splice you must always use
non-blocking I/O since you can't get the blocking case to work reliably, than
I will accept that. After all, they know better :)
Thanks,
tavi
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Jochen Friedrich @ 2008-07-18 15:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Scott Wood
In-Reply-To: <C98DF5D7-0E3D-4FDA-A831-55CFD5F4590C@kernel.crashing.org>
Hi Kumar,
> but ports a-d are different on cpm1? I guess I'd like to see both
> patches to understand the commonality and differences.
Yes. Both patches are still in patchwork:
http://patchwork.ozlabs.org/linuxppc/patch?id=19045
http://patchwork.ozlabs.org/linuxppc/patch?id=19386
Thanks,
Jochen
^ permalink raw reply
* Re: Endless ACPI errors on Linus tree (5b664cb235)
From: Andi Kleen @ 2008-07-18 15:52 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Andi Kleen, LKML, Len Brown, robert.moore
In-Reply-To: <s5hr69rz57u.wl%tiwai@suse.de>
> I'll investigate a bit. Any hints are appreciated.
Don't know what causes it then. Could you please bisect?
To cut it short you might want to start with the ACPI merge
only (d442cc44c0db56e84ef6aa244a88427d2efe06cd) and first check if that
kernel didn't do it and the patch after it did
(4314652bb41df08ad65bd25176ba1dfd24b14a51)
Then you can bisect between the two relatively quickly.
Thanks,
-Andi
^ permalink raw reply
* [U-Boot-Users] [PATCH] Set up SD/MMC OCR as comment describes. i.e. 3.2-3.4v.
From: Adrian Filipi @ 2008-07-18 15:52 UTC (permalink / raw)
To: u-boot
Signed-off-by: Adrian Filipi <adrian.filipi@eurotech.com>
---
cpu/pxa/mmc.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpu/pxa/mmc.c b/cpu/pxa/mmc.c
index 2c86a01..3215b93 100644
--- a/cpu/pxa/mmc.c
+++ b/cpu/pxa/mmc.c
@@ -580,8 +580,8 @@ mmc_init(int verbose)
break;
}
- /* Select 3.2-3.3 and 3.3-3.4V */
- resp = mmc_cmd(SD_CMD_APP_SEND_OP_COND, 0x0020, 0,
+ /* Select 3.2-3.3V and 3.3-3.4V */
+ resp = mmc_cmd(SD_CMD_APP_SEND_OP_COND, 0x0030, 0x0000,
MMC_CMDAT_R3 | (retries < 2 ? 0
: MMC_CMDAT_INIT));
if (resp[0] & 0x80000000) {
--
1.5.6
^ permalink raw reply related
* Re: hang on "booting the kernel ...."
From: David Baird @ 2008-07-18 15:51 UTC (permalink / raw)
To: wsz_422; +Cc: linuxppc-embedded
In-Reply-To: <11945316.455961216349028828.JavaMail.coremail@bj126app95.126.com>
On Thu, Jul 17, 2008 at 8:43 PM, wsz_422 <wsz_422@126.com> wrote:
>
> Hello!
> When I boot the kerenl which was compiled by myself on the ML403,but
> it hang on "booting the kernel ",the prompt information is as follow:
> Linux
> uncompressing the kernel ....done
> Now booting the kernel
> and then there is nothing .
This problem comes up a lot. Try searching the archives for ML403 and
__log_buf.
^ permalink raw reply
* Re: [PATCH] intel_cacheinfo: fix use-after-free cache_kobject
From: Ingo Molnar @ 2008-07-18 15:51 UTC (permalink / raw)
To: Akinobu Mita; +Cc: linux-kernel, Thomas Gleixner, Ingo Molnar, H. Peter Anvin
In-Reply-To: <20080715080903.GA22068@localhost.localdomain>
* Akinobu Mita <akinobu.mita@gmail.com> wrote:
> This avoids calling kobject_uevent() with cache_kobject that has
> already been deallocated in an error path.
applied to tip/x86/urgent, thanks.
Ingo
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Petr Baudis @ 2008-07-18 15:49 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <320075ff0807180809x599aefafw2c7fe88fea2691d2@mail.gmail.com>
On Fri, Jul 18, 2008 at 04:09:40PM +0100, Nigel Magnay wrote:
> Hmm. Locally modifying my .gitmodules still feels bad because I don't
> like either of those tradeoffs (but I don't have any sensible
> suggestion yet).
>
> As a bit of background (as to why I'd dislike (a) and (b)), we had a
> team switch to git, and one of the really nice things is the ability
> to share stuff around and branch freely - but the flipside of that is
> that we tend to push to a central repo more rarely, so the advantages
> of an continuous integration server become less. What we did is to
> tell a centralised CI server the URLs of all the team's git
> repositories, and it would periodically pull from them, speculatively
> compile anything new, and run the big suite of tests - finishing up by
> emailling them a heads-up that a particular state in their repo is
> 'bad'.
>
> This was really popular as it was demonstrably better than anything we
> could do with svn, and best of all, it's pretty much transparent - as
> a user you don't have to do anything at all.
>
> I could do it now by hacking about with files; it'd just be nice to
> keep it transparent and make it a directly supported feature.
In that case you would need the "URL mappings", perhaps as a per-remote
attribute. That is, you could configure:
"When I am doing git pull fred, do git submodule update but
apply remote.fred.subrewrite sed script on each URL before
fetching the submodule."
Still, that feels quite hackish to me, and I'm not convinced that your
workflow cannot be adjusted so that users merge only the next-to-last
commit of a branch instead of the last one.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Kernel version : what about YYYY.MM.[01].x ?
From: Athanasius @ 2008-07-18 15:24 UTC (permalink / raw)
To: david, linux-kernel; +Cc: el es
In-Reply-To: <alpine.DEB.1.10.0807171558450.17859@asgard.lang.hm>
In reading this thread I've seen folk come up with some good
suggestions, and some bad ones. I think I can sum things up as follows:
1) Need to clearly designate
a) A fresh stable release
b) Also updates to that stable release, without getting confused
with any development releases.
c) A fresh development release/pre-release of next stable, without
getting confused with current stable releases.
2) The only real objection to the status quo seems to be "the 3rd number
is getting too big". This is highly subjective and not a good enough
reason by itself to change the scheme.
3) It would be nice for stable releases to encode when their initial
version was made. This gives extra information in the version number
without having to do a lookup. The problem with this is you don't know
when the next stable release will actually be. This means you can't
base your development version numbering on that, i.e. no simply
appending -rcX to something as you don't know what the something should
be.
But -rcX is just one way of doing it, all we really need is for it to
be clear if a version is part of development or part of a stable
release.
I therefore propose the form YYYY.MM.[sd].x
So, 2.6.26 would have been 2008.07.s.0
The first update to it would be 2008.07.s.1
The development code would continue now as 2008.07.d.0 and onwards
incrementing the last number as development progresses.
Some might object to the user of [sd] on grounds of easy sorting. In
which case just use 0 for stable and 1 for development. Yes, this means
going back to the odd/even designation we had pre-2.6, but as we also
stick to the relatively short development cycle it really doesn't
matter. Also with the base being YYYY.MM we'll only ever use 0 and 1
anyway.
So, YYYY.MM.[0|1].x gives us:
1) Clear indication of when this stable series started.
2) Clear indication of updates to that stable version.
3) Clear designation of the development versions started after
that stable release.
Note however what I said in my 2nd point. The only *real* objection to
the current scheme is 'big numbers', and that's subjective. I only find
it worth making a proposal due to the reasoning in my 3rd point, i.e. it
IS a good idea to encode *when* a stable release was made in its version
number. This not only allows someone to see how long the current
development cycle has been going (to within +/- 4 weeks), but also
allows a glance at all prior versions to show how quickly development
progresses on average between stable versions.
--
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
^ permalink raw reply
* Re: [refpolicy] Patch: Create non_security_file_type attribute
From: Christopher J. PeBenito @ 2008-07-18 15:49 UTC (permalink / raw)
To: jwcart2; +Cc: SELinux
In-Reply-To: <1216395738.26625.45.camel@moss-lions.epoch.ncsc.mil>
On Fri, 2008-07-18 at 11:42 -0400, James Carter wrote:
> On Fri, 2008-07-18 at 10:15 -0400, Christopher J. PeBenito wrote:
> > On Fri, 2008-06-27 at 14:55 -0400, James Carter wrote:
> > > This patch eliminates the expansion of the file_type attribute (due to
> > > the "-" set operation) for the *_non_security interfaces by creating a
> > > non_security_file_type attribute.
> > >
> > > On my system the resulting binary policy is almost 20% smaller. The
> > > difference is so large because there are over 1000 types labeled with
> > > the file_type attribute.
> >
> > I'm hesitant to attach non_security_file_type to the files_type
> > attribute, since its not clear to me that it makes conceptual sense.
>
> The primary goal here is a smaller binary policy. But it still makes
> sense conceptually to me because the security_file_type attribute is
> never used by itself as far as I can tell. It is always used as
> {file_type-security_file_type}.
>
> > In
> > fact a sediff of the policy reveals that auidtd_log_t gains
> > non_security_file_type while it already has security_file_type, which
> > results in rule additions with this patch added.
> That's not good. There are only a handful of types labeled with
> security_file_type, I don't know how I missed that. Sorry.
>
> The following line is the problem: files_mountpoint(auditd_log_t).
> So, a files_mountpoint_security interface would have to be created.
>
> It's not a big deal to me. If there is no interest in creating a
> non_security_file_type attribute, I won't pursue this any farther.
I think the binary policy size savings is a good enough reason to pursue
it. Brainstorming for a second, another way to address this problem
would be to change how checkpolicy handles negations. It could make a
new attribute with the resultant type set from the negation; however,
that might be bad for analysis since an attribute would magically appear
out of nowhere.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
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: Endless ACPI errors on Linus tree (5b664cb235)
From: Takashi Iwai @ 2008-07-18 15:48 UTC (permalink / raw)
To: Andi Kleen; +Cc: LKML, Len Brown, robert.moore, Jan Beulich
In-Reply-To: <s5hr69rz57u.wl%tiwai@suse.de>
At Fri, 18 Jul 2008 15:34:13 +0200,
I wrote:
>
> At Fri, 18 Jul 2008 15:15:25 +0200,
> I wrote:
> >
> > At Fri, 18 Jul 2008 13:35:48 +0200,
> > Andi Kleen wrote:
> > >
> > > Takashi Iwai <tiwai@suse.de> writes:
> > >
> > > > the boot with the latest Linus git tree fails on x86-64 due to the
> > > > endless kernel messages like below:
> > > >
> > > > ACPI Error (evpge-0710): No handler or method for GPE[10],
> > > > disabling event[20080609]
> > > >
> > > > It happens on today's tree and also on yesterday (33af79d12e).
> > > > The config is below.
> > >
> > > That was after the ACPI merge I assume?
> >
> > Yes.
> >
> > > Do you have a full boot log?
> >
> > Sorry, no. The kernel shows the error message (the number after GPE
> > constantly changing as 1x) endlessly, and couldn't boot up properly to
> > get a log.
> >
> > > Revert candidates to test would be e38e8a0743b0e996a8a3fbea8908fe75a84f02c7
> > > and c91d924e3af08d4f98eab6ebf81f2b8ce132448f (Bob, that were both
> > > changes from you for evgpe.c). Can you see if reverting
> > > those helps? If yes which?
> >
> > Will give it a spin.
>
> I reverting both, but it doesn't fix the problem.
>
> Another finding is that the boot reaches to the exec of init, at
> least. So I could get a sane state with init=/bin/sh. The message
> appears after the init script running udevd.
>
> Also, the machine could boot fine with the recent linux-next kernel,
> at least, 20080711-0714. (It failed for last couple of days, but it
> can be irrelevant.)
>
> I'll investigate a bit. Any hints are appreciated.
OK, found out the bad commit via bisect.
Reverting below fixes the boot problem.
commit 01a5bba576b9364b33f61f0cd9fa70c2cf5535e2
Author: Jan Beulich <jbeulich@novell.com>
Date: Wed Jul 16 23:27:08 2008 +0200
Fix FADT parsing
The (1.0 inherited) separate length fields in the FADT are byte granular.
Further, PM1a/b may have distinct lengths and live in distinct address spaces.
acpi_tb_convert_fadt() should account for all of these conditions.
Apart from these changes I'm puzzled by the fact that, not just for
acpi_gbl_xpm1{a,b}_enable, acpi_hw_low_level_{read,write}() get an explicit
size passed rather than using the size found in the passed GAS. What happens
on a platform that defines PM1{a,b} wider than 16 bits? Of course,
acpi_hw_low_level_{read,write}() at present are entirely un-prepared to deal
with sizes other than 8, 16, or 32, not to speak of a non-zero bit_offset or
access_width...
Takashi
^ permalink raw reply
* Re: [RFC] How to handle the rules engine for cgroups
From: Paul Menage @ 2008-07-18 15:46 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Vivek Goyal, linux kernel mailing list, Libcg Devel Mailing List,
Balbir Singh, Dhaval Giani, Peter Zijlstra, Kazunaga Ikeno,
Morton Andrew Morton
In-Reply-To: <20080718185226.f809281d.kamezawa.hiroyu@jp.fujitsu.com>
On Fri, Jul 18, 2008 at 2:52 AM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> For example, create a new file under memory cgroup
> ==
> /opt/memory_cgroup/group_A/notify_at_memory_reach_limit
> ==
> And a user watches the file by inotify.
> The kernel modify modified-time of notify_at_memory_reach_limit file and call
> fs/notify_user.c::notify_change() against this inode. He can catchthe event
> by inotify.
> (I think he can also catch removal of this file, etc...)
>
We've been doing something like this to handle OOMs in userspace, with
pretty good success. The approach that we used so far was a custom
control file tied to a wait queue, that gets woken when a cgroup
triggers OOM, but it's a bit hacky. I've been considering some kind of
more generic approach that could be reused by different subsystems for
other notifications, maybe using eventfd or maybe netlink.
inotify would be an option too, but that seems like it might be
forcing ourselves into filesystem semantics too much.
Paul
^ permalink raw reply
* xend, 8MB video memory and ballooning
From: Samuel Thibault @ 2008-07-18 15:47 UTC (permalink / raw)
To: xen-devel
Hello,
There's an issue when starting an HVM domain and quickly after, another
domain:
- xend asks the balloon driver to free enough memory for the HVM domain
plus 8MB for the video memory.
- before the HVM domain actually starts running (e.g. qemu long to
start), I start another domain, xend asks the balloon driver to free
enough memory for that other domain, but no more.
- the HVM domain eventually starts, the Cirrus VGA BIOS activates the
video LFB, and thus qemu tries to call populate physmap in order to
actually make use of the extra 8MB for the video memory.
Problem: the 8MB extra free memory has been swallowed by the other
domain...
(of course, my concern is about the device model stubdomain starting
right after the HVM domain, but I guess that may happen in other cases
too).
Samuel
^ permalink raw reply
* Re: [PATCH 00/06] uio: Various minor changes
From: Hans J. Koch @ 2008-07-18 15:46 UTC (permalink / raw)
To: Magnus Damm; +Cc: linux-kernel, hjk, gregkh, akpm
In-Reply-To: <20080718050402.16250.25213.sendpatchset@rx1.opensource.se>
On Fri, Jul 18, 2008 at 02:04:02PM +0900, Magnus Damm wrote:
> Hi everyone,
>
> Here comes a few UIO changes that I've had in my queue for a while.
Hi Magnus,
thanks a lot for your patches. I'll have a look at them ASAP, but it'll
take a few days. I'm busy moving to a new house ATM...
Greg, could you help reviewing these ?
Thanks,
Hans
>
> [PATCH 01/06] uio: Use struct_uio_mem instead of index
> [PATCH 02/06] uio: Pass struct uio_mem to mmap functions
> [PATCH 03/06] uio: Remove vma->vm_private_data from uio_find_mem()
> [PATCH 04/06] uio: Store struct uio_mem ptr in vma->vm_private_data
> [PATCH 05/06] uio: Remove redundant vma->vm_flags setup code
> [PATCH 06/06] uio: Support multiple UIO_MEM_LOGICAL/VIRTUAL pages
>
> Mostly small cleanups or performance improvements, except the last one
> which contains a fix for unsupported multi-page LOGICAL/VIRTUAL maps.
>
> Signed-off-by: Magnus Damm <damm@igel.co.jp>
> ---
>
> Documentation/DocBook/uio-howto.tmpl | 2
> drivers/uio/uio.c | 91 +++++++++++++++-------------------
> include/linux/uio_driver.h | 1
> 3 files changed, 44 insertions(+), 50 deletions(-)
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Kumar Gala @ 2008-07-18 15:46 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev list, Scott Wood
In-Reply-To: <4880B730.8050801@scram.de>
On Jul 18, 2008, at 10:30 AM, Jochen Friedrich wrote:
> Hi Kumar,
>
>> On Jun 18, 2008, at 12:08 PM, Laurent Pinchart wrote:
>>
>>> +#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
>>> +
>>> +struct cpm2_ioports {
>>> + u32 dir, par, sor, odr, dat;
>>> + u32 res[3];
>>> +};
>>> +
>>
>> is this really common for both CPM2 and 8xx? if so why the name?
>
> It is common to CPM2 and Port E of CPM1.
but ports a-d are different on cpm1? I guess I'd like to see both
patches to understand the commonality and differences.
- k
^ permalink raw reply
* Re: [PATCH 1/2] mtdpart: Avoid divide-by-zero on out-of-reach path
From: Atsushi Nemoto @ 2008-07-18 15:47 UTC (permalink / raw)
To: joern; +Cc: linux-mtd, akpm, dwmw2
In-Reply-To: <20080717145546.GB1712@logfs.org>
On Thu, 17 Jul 2008 16:55:46 +0200, Jörn Engel <joern@logfs.org> wrote:
> > Ping? Should I send your patchset with my fix?
>
> Yes, please do.
OK, I will do soon.
---
Atsushi Nemoto
^ permalink raw reply
* Re: e1000e "Detected Tx Unit Hang"
From: Stefan Roese @ 2008-07-18 15:44 UTC (permalink / raw)
To: Felix Radensky; +Cc: Brandeburg, Jesse, netdev
In-Reply-To: <4880B88A.6060201@embedded-sol.com>
Hi Felix,
On Friday 18 July 2008, Felix Radensky wrote:
> Are you sure your NFS root is mounted via e1000e ?
Yes!
> I cannot complete the
> boot
> with 2.6.26 release if e1000e is compiled into the kernel and on-board
> NICs disconnected.
> This is what I get:
## Flattened Device Tree blob at 00800000
Booting using the fdt blob at 0x800000
Loading Device Tree to 007fa000, end 007ff70f ... OK
debug: ignoring loglevel setting.
Using Canyonlands machine description
Linux version 2.6.26 (stefan@kubuntu) (gcc version 4.2.2) #2 Fri Jul 18 16:46:00 CEST
2008
Found legacy serial port 0 for /plb/opb/serial@ef600300
mem=4ef600300, taddr=4ef600300, irq=0, clk=7407407, speed=0
Found legacy serial port 1 for /plb/opb/serial@ef600400
mem=4ef600400, taddr=4ef600400, irq=0, clk=7407407, speed=0
Found legacy serial port 2 for /plb/opb/serial@ef600500
mem=4ef600500, taddr=4ef600500, irq=0, clk=7407407, speed=0
Found legacy serial port 3 for /plb/opb/serial@ef600600
mem=4ef600600, taddr=4ef600600, irq=0, clk=7407407, speed=0
Entering add_active_range(0, 0, 131072) 0 entries of 256 used
Top of RAM: 0x20000000, Total RAM: 0x20000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 131072
Normal 131072 -> 131072
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 131072
On node 0 totalpages: 131072
DMA zone: 1024 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 130048 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
Kernel command line: root=/dev/nfs rw nfsroot=10.0.0.152:/opt/eldk/ppc_4xxFP
ip=10.0.0.182:10.0.0.152:::canyonlands:eth0:off panic=1 console=ttyS0,115200
ignore_loglevel
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
UIC3 (32 IRQ sources) at DCR 0xf0
PID hash table entries: 2048 (order: 11, 8192 bytes)
time_init: decrementer frequency = 600.000007 MHz
time_init: processor frequency = 600.000007 MHz
clocksource: timebase mult[6aaaab] shift[22] registered
clockevent: decrementer mult[9999] shift[16] cpu[0]
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 516864k/524288k available (2404k kernel code, 7176k reserved, 100k data, 125k
bss, 140k init)
SLUB: Genslabs=10, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay loop... 1196.03 BogoMIPS (lpj=2392064)
Mount-cache hash table entries: 512
net_namespace: 192 bytes
NET: Registered protocol family 16
PCIE0: Checking link...
PCIE0: No device detected.
PCI host bridge /plb/pciex@d00000000 (primary) ranges:
MEM 0x0000000e00000000..0x0000000e7fffffff -> 0x0000000080000000
IO 0x0000000f80000000..0x0000000f8000ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCIE0: successfully set as root-complex
PCIE1: Checking link...
PCIE1: Device detected, waiting for link...
PCIE1: link is up !
PCI host bridge /plb/pciex@d20000000 (primary) ranges:
MEM 0x0000000e80000000..0x0000000effffffff -> 0x0000000080000000
IO 0x0000000f80010000..0x0000000f8001ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCIE1: successfully set as root-complex
PCI host bridge /plb/pci@c0ec00000 (primary) ranges:
MEM 0x0000000d80000000..0x0000000dffffffff -> 0x0000000080000000
IO 0x0000000c08000000..0x0000000c0800ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:40:00.0
PCI: Hiding 4xx host bridge resources 0001:80:00.0
PCI: Bridge: 0000:40:00.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0001:80:00.0
IO window: 0000-0fff
MEM window: 0x80000000-0x800fffff
PREFETCH window: 0x0000000080100000-0x00000000801fffff
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
IP route cache hash table entries: 16384 (order: 4, 65536 bytes)
TCP established hash table entries: 65536 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
NET: Registered protocol family 1
msgmni has been set to 1009
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4ef600300 (irq = 19) is a 16550A
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0x4ef600400 (irq = 20) is a 16550A
serial8250.0: ttyS2 at MMIO 0x4ef600500 (irq = 29) is a 16550A
serial8250.0: ttyS3 at MMIO 0x4ef600600 (irq = 21) is a 16550A
4ef600300.serial: ttyS0 at MMIO 0x4ef600300 (irq = 19) is a 16550A
4ef600400.serial: ttyS1 at MMIO 0x4ef600400 (irq = 20) is a 16550A
4ef600500.serial: ttyS2 at MMIO 0x4ef600500 (irq = 29) is a 16550A
4ef600600.serial: ttyS3 at MMIO 0x4ef600600 (irq = 21) is a 16550A
brd: module loaded
e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k2
e1000e: Copyright (c) 1999-2008 Intel Corporation.
e1000e 0001:81:00.0: enabling device (0006 -> 0007)
eth0: (PCI Express:2.5GB/s:Width x1) 00:1b:21:04:a3:47
eth0: Intel(R) PRO/1000 Network Connection
eth0: MAC: 1, PHY: 4, PBA No: d50854-003
PPC 4xx OCP EMAC driver, version 3.54
MAL v2 /plb/mcmal, 2 TX channels, 16 RX channels
ZMII /plb/opb/emac-zmii@ef600d00 initialized
RGMII /plb/opb/emac-rgmii@ef601500 initialized with MDIO support
TAH /plb/opb/emac-tah@ef601350 initialized
TAH /plb/opb/emac-tah@ef601450 initialized
/plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
eth1: EMAC-0 /plb/opb/ethernet@ef600e00, MAC 00:10:ec:00:f9:ed
eth1: found Generic MII PHY (0x00)
/plb/opb/emac-rgmii@ef601500: input 1 in RGMII mode
eth2: EMAC-1 /plb/opb/ethernet@ef600f00, MAC 00:10:ec:00:f9:ee
eth2: found Generic MII PHY (0x01)
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
IP-Config: Guessing netmask 255.0.0.0
IP-Config: Complete:
device=eth0, addr=10.0.0.182, mask=255.0.0.0, gw=255.255.255.255,
host=canyonlands, domain=, nis-domain=(none),
bootserver=10.0.0.152, rootserver=10.0.0.152, rootpath=
Looking up port of RPC 100003/2 on 10.0.0.152
eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Looking up port of RPC 100005/1 on 10.0.0.152
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 140k init
modprobe: FATAL: Could not load /lib/modules/2.6.26/modules.dep: No such file or
directory
modprobe: FATAL: Could not load /lib/modules/2.6.26/modules.dep: No such file or
directory
INIT: version 2.86 booting
Welcome to DENX Embedded Linux Environment
Press 'I' to enter interactive startup.
modprobe: FATAL: Could not load /lib/modules/2.6.26/modules.dep: No such file or
directory
modprobe: FATAL: Could not load /lib/modules/2.6.26/modules.dep: No such file or
directory
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Setting clock : Thu Jan 1 01:00:06 CET 1970 [ OK ]
Building the cache [ OK ]
Setting hostname canyonlands: [ OK ]
Mounting local filesystems: [ OK ]
Enabling /etc/fstab swaps: [ OK ]
INIT: Entering runlevel: 3
Entering non-interactive startup
FATAL: Could not load /lib/modules/2.6.26/modules.dep: No such file or directory
Bringing up loopback interface: [ OK ]
FATAL: Could not load /lib/modules/2.6.26/modules.dep: No such file or directory
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
Starting rpcbind: [ OK ]
Mounting NFS filesystems: [ OK ]
Mounting other filesystems: [ OK ]
Starting xinetd: [ OK ]
DENX ELDK version 4.2 build 2008-02-20
Linux 2.6.26 on a ppc
canyonlands login:
So it works for me. Only difference I can see is that I'm using 1000Mbps and you only
100. Is this also 2.6.26 release from kernel.org? Which PCIe slot are you using? I'm
using PCIe1.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH] Deferrable Timer
From: Dave Winchell @ 2008-07-18 15:44 UTC (permalink / raw)
To: Yu, Ke; +Cc: Tian, Kevin, xen-devel, Dave Winchell, Keir Fraser, Wei, Gang
In-Reply-To: <1104166E0B63A341805FDB977862AAD201BF4DEF@pdsmsx414.ccr.corp.intel.com>
Yu, Ke wrote:
>Yu, Ke wrote:
>
>
>>Dave,
>>
>>Glad to see there is deferrable timer application. Please go ahead
>>with that. And I will keep you updated if there is finding in my side.
>>
>>BTW, Could you please elaborate more on the
>>"guest-handles-missed-tick" case? Since there is no need to inject
>>missed tick to guest, which timer would be used as deferrable timer?
>>
>>
>
>Oh, I catch your points now, please ignore my previous question. You
>actually means that: since guest can handle the missed tick correcty, it
>is acceptable that the hpet/vpt timer is defered, so the hpet/vpt timer
>itself can be deferrable timer.
>
Yes.
> so is the
>"guest-does-not-handle-missed-ticks" case, since xen can handle that by
>inject missed tick respectively.
>
>
For the guest-does-not-handle-missed-ticks case we inject the correct number
of interrupts, i.e. N*period, N an integer, but we can delay a bit before
doing so. So I think we can use deferrable timers for both policies.
>If my understanding is correct, I would say your point is truly good, I
>expect this will reduce the timer count much especially when there is
>multiple HVMs.
>
>Best Regards
>Ke
>
>
>
>>Best Regards
>>Ke
>>
>>Dave Winchell wrote:
>>
>>
>>>Ke,
>>>
>>>One would think that hpet or vpt support for the
>>>guest-handles-missed-ticks policy would be a good application for a
>>>deferrable timer. If a deferrable timer were used, then the
>>>comparator (cmp) would have to be warped to a non-integer multiple
>>>of the period. This is because Linux reads the comparator register
>>>to estimate the delay since the interrupt was posted.
>>>I don't think warping like this will be a problem. At some point, I
>>>can test this.
>>>
>>>I think we could use the deferrable timer for the
>>>guest-does-not-handle-missed-ticks
>>>policy as well.
>>>
>>>Any investigation that you want to do in the platform timer area
>>>would be fine. Or I can do it, but that will probably be after I do
>>>the vpt.c/hpet.c integration work.
>>>
>>>thanks,
>>>Dave
>>>
>>>
>>>
>>>>Best Regards
>>>>Ke
>>>>
>>>>_______________________________________________
>>>>Xen-devel mailing list
>>>>Xen-devel@lists.xensource.com
>>>>http://lists.xensource.com/xen-devel
>>>>
>>>>
>>_______________________________________________
>>Xen-devel mailing list
>>Xen-devel@lists.xensource.com
>>http://lists.xensource.com/xen-devel
>>
>>
>
>
>
^ permalink raw reply
* [U-Boot-Users] [ ramdisk error ]
From: Wolfgang Denk @ 2008-07-18 15:43 UTC (permalink / raw)
To: u-boot
In-Reply-To: <000001c8e8db$1b0a7090$511f51b0$@com>
In message <000001c8e8db$1b0a7090$511f51b0$@com> you wrote:
>
> I am trying to boot my board based on SEQUOIA using a kernel and ramdisk.
>
> I know the kernel and ramdisk image are good, since I used the same images
> for SEQUOIA.
The kernel is probably good for the Sequoia board, but if you have
some other, custom hardware, you also need a custom port of Linux for
it, i. e. another Linux image.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"A little knowledge is a dangerous thing." - Doug Gwyn
^ permalink raw reply
* Re: [patch 00/17] Tracepoints v4 for linux-next
From: Masami Hiramatsu @ 2008-07-18 15:41 UTC (permalink / raw)
To: Mathieu Desnoyers; +Cc: akpm, Ingo Molnar, linux-kernel, Peter Zijlstra
In-Reply-To: <20080715222604.331269462@polymtl.ca>
Hi Mathieu,
As far as I can see, your patchset can be separated into
several series of patches. Would you think this series of
patches should be pushed at once, or could be pushed
individually?
I think it is hard to push all of them into kernel at once,
because it needs ACKs from several developers who maintain
traced subsystems.
So, I'd like to suggest you to separate series of patches,
and to push framework and instrumentation patches step by step.
What would you think about it?
Thank you,
Mathieu Desnoyers wrote:
> Hi,
>
> Here is the newest release of the Tracepoints, following the feedback from Peter
> Zijlstra. The main change is the creation of include/trace/ as a placeholder
> from tracepoint headers.
>
> The patchset applies over linux-next patch-v2.6.26-next-20080715 in this order :
>
> #This a separate RCU update upon which the tracepoints depend
> rcu-read-sched.patch
>
> tracepoints.patch
> tracepoints-documentation.patch
> tracepoints-samples.patch
>
> lttng-instrumentation-irq.patch
> lttng-instrumentation-scheduler.patch
> lttng-instrumentation-timer.patch
> lttng-instrumentation-kernel.patch
>
> lttng-instrumentation-filemap.patch
> lttng-instrumentation-swap.patch
> lttng-instrumentation-memory.patch
> lttng-instrumentation-page.patch
> lttng-instrumentation-hugetlb.patch
>
> lttng-instrumentation-net.patch
> lttng-instrumentation-ipv4.patch
> lttng-instrumentation-ipv6.patch
>
> ftrace-port-to-tracepoints.patch
>
> Mathieu
>
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
^ permalink raw reply
* Re: [refpolicy] Patch: Create non_security_file_type attribute
From: James Carter @ 2008-07-18 15:42 UTC (permalink / raw)
To: Christopher J. PeBenito; +Cc: SELinux
In-Reply-To: <1216390554.21191.147.camel@gorn>
On Fri, 2008-07-18 at 10:15 -0400, Christopher J. PeBenito wrote:
> On Fri, 2008-06-27 at 14:55 -0400, James Carter wrote:
> > This patch eliminates the expansion of the file_type attribute (due to
> > the "-" set operation) for the *_non_security interfaces by creating a
> > non_security_file_type attribute.
> >
> > On my system the resulting binary policy is almost 20% smaller. The
> > difference is so large because there are over 1000 types labeled with
> > the file_type attribute.
>
> I'm hesitant to attach non_security_file_type to the files_type
> attribute, since its not clear to me that it makes conceptual sense.
The primary goal here is a smaller binary policy. But it still makes
sense conceptually to me because the security_file_type attribute is
never used by itself as far as I can tell. It is always used as
{file_type-security_file_type}.
> In
> fact a sediff of the policy reveals that auidtd_log_t gains
> non_security_file_type while it already has security_file_type, which
> results in rule additions with this patch added.
That's not good. There are only a handful of types labeled with
security_file_type, I don't know how I missed that. Sorry.
The following line is the problem: files_mountpoint(auditd_log_t).
So, a files_mountpoint_security interface would have to be created.
It's not a big deal to me. If there is no interest in creating a
non_security_file_type attribute, I won't pursue this any farther.
Jim
>
> > files.if | 61 ++++++++++++++++++++++++++++++-------------------------------
> > files.te | 2 ++
> > 2 files changed, 32 insertions(+), 31 deletions(-)
> >
> > Index: policy/modules/kernel/files.if
> > ===================================================================
> > --- policy/modules/kernel/files.if (revision 2739)
> > +++ policy/modules/kernel/files.if (working copy)
> > @@ -32,10 +32,10 @@
> > #
> > interface(`files_type',`
> > gen_require(`
> > - attribute file_type;
> > + attribute file_type, non_security_file_type;
> > ')
> >
> > - typeattribute $1 file_type;
> > + typeattribute $1 file_type, non_security_file_type;
> > ')
> >
> > ########################################
> > @@ -217,11 +217,10 @@
> > #
> > interface(`files_security_file',`
> > gen_require(`
> > - attribute security_file_type;
> > + attribute file_type, security_file_type;
> > ')
> >
> > - files_type($1)
> > - typeattribute $1 security_file_type;
> > + typeattribute $1 file_type, security_file_type;
> > ')
> >
> > ########################################
> > @@ -316,10 +315,10 @@
> > #
> > interface(`files_list_non_security',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - list_dirs_pattern($1,{ file_type -security_file_type },{ file_type -security_file_type })
> > + list_dirs_pattern($1,non_security_file_type,non_security_file_type)
> > ')
> >
> > ########################################
> > @@ -335,10 +334,10 @@
> > #
> > interface(`files_dontaudit_list_non_security',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - dontaudit $1 { file_type -security_file_type }:dir list_dir_perms;
> > + dontaudit $1 non_security_file_type:dir list_dir_perms;
> > ')
> >
> > ########################################
> > @@ -354,11 +353,11 @@
> > #
> > interface(`files_mounton_non_security',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - allow $1 { file_type -security_file_type }:dir mounton;
> > - allow $1 { file_type -security_file_type }:file mounton;
> > + allow $1 non_security_file_type:dir mounton;
> > + allow $1 non_security_file_type:file mounton;
> > ')
> >
> > ########################################
> > @@ -373,10 +372,10 @@
> > #
> > interface(`files_write_non_security_dirs',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - allow $1 { file_type -security_file_type }:dir write;
> > + allow $1 non_security_file_type:dir write;
> > ')
> >
> > ########################################
> > @@ -430,10 +429,10 @@
> > #
> > interface(`files_dontaudit_getattr_non_security_files',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - dontaudit $1 { file_type -security_file_type }:file getattr;
> > + dontaudit $1 non_security_file_type:file getattr;
> > ')
> >
> > ########################################
> > @@ -498,11 +497,11 @@
> > #
> > interface(`files_read_non_security_files',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - read_files_pattern($1,{ file_type -security_file_type },{ file_type -security_file_type })
> > - read_lnk_files_pattern($1,{ file_type -security_file_type },{ file_type -security_file_type })
> > + read_files_pattern($1,non_security_file_type,non_security_file_type)
> > + read_lnk_files_pattern($1,non_security_file_type,non_security_file_type)
> > ')
> >
> > ########################################
> > @@ -648,10 +647,10 @@
> > #
> > interface(`files_dontaudit_getattr_non_security_symlinks',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - dontaudit $1 { file_type -security_file_type }:lnk_file getattr;
> > + dontaudit $1 non_security_file_type:lnk_file getattr;
> > ')
> >
> > ########################################
> > @@ -667,10 +666,10 @@
> > #
> > interface(`files_dontaudit_getattr_non_security_blk_files',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - dontaudit $1 { file_type -security_file_type }:blk_file getattr;
> > + dontaudit $1 non_security_file_type:blk_file getattr;
> > ')
> >
> > ########################################
> > @@ -686,10 +685,10 @@
> > #
> > interface(`files_dontaudit_getattr_non_security_chr_files',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - dontaudit $1 { file_type -security_file_type }:chr_file getattr;
> > + dontaudit $1 non_security_file_type:chr_file getattr;
> > ')
> >
> > ########################################
> > @@ -763,10 +762,10 @@
> > #
> > interface(`files_dontaudit_getattr_non_security_pipes',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - dontaudit $1 { file_type -security_file_type }:fifo_file getattr;
> > + dontaudit $1 non_security_file_type:fifo_file getattr;
> > ')
> >
> > ########################################
> > @@ -820,10 +819,10 @@
> > #
> > interface(`files_dontaudit_getattr_non_security_sockets',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - dontaudit $1 { file_type -security_file_type }:sock_file getattr;
> > + dontaudit $1 non_security_file_type:sock_file getattr;
> > ')
> >
> > ########################################
> > @@ -4763,8 +4762,8 @@
> > #
> > interface(`files_manage_non_security_dirs',`
> > gen_require(`
> > - attribute file_type, security_file_type;
> > + attribute non_security_file_type;
> > ')
> >
> > - allow $1 { file_type -security_file_type }:dir manage_dir_perms;
> > + allow $1 non_security_file_type:dir manage_dir_perms;
> > ')
> > Index: policy/modules/kernel/files.te
> > ===================================================================
> > --- policy/modules/kernel/files.te (revision 2739)
> > +++ policy/modules/kernel/files.te (working copy)
> > @@ -26,6 +26,8 @@
> > # sensitive security files whose accesses should
> > # not be dontaudited for uses
> > attribute security_file_type;
> > +# and its opposite
> > +attribute non_security_file_type;
> >
> > attribute tmpfile;
> > attribute tmpfsfile;
> >
--
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency
--
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
* [Cluster-devel] Cluster Project branch, master, updated. cluster-2.99.06-32-g9d2109d
From: teigland @ 2008-07-18 15:42 UTC (permalink / raw)
To: cluster-devel.redhat.com
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Cluster Project".
http://sources.redhat.com/git/gitweb.cgi?p=cluster.git;a=commitdiff;h=9d2109d1559a9bb9bb29a7178d084ab744bdc1a1
The branch, master has been updated
via 9d2109d1559a9bb9bb29a7178d084ab744bdc1a1 (commit)
from bbc505c95648f60e698c2eb19d0fc429bcc5bd80 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 9d2109d1559a9bb9bb29a7178d084ab744bdc1a1
Author: David Teigland <teigland@redhat.com>
Date: Fri Jul 18 10:34:00 2008 -0500
fenced: munge config option code
to match the code in other daemons.
Signed-off-by: David Teigland <teigland@redhat.com>
-----------------------------------------------------------------------
Summary of changes:
fence/fenced/config.c | 66 ++++++++++++++++++++++++++++-------------------
fence/fenced/config.h | 26 +++++++++++++++++++
fence/fenced/fd.h | 28 --------------------
fence/fenced/main.c | 48 ++++++++++++++---------------------
fence/fenced/recover.c | 17 ++++++------
5 files changed, 93 insertions(+), 92 deletions(-)
create mode 100644 fence/fenced/config.h
diff --git a/fence/fenced/config.c b/fence/fenced/config.c
index 3468459..046112f 100644
--- a/fence/fenced/config.c
+++ b/fence/fenced/config.c
@@ -1,8 +1,27 @@
#include "fd.h"
+#include "config.h"
#include "ccs.h"
static int ccs_handle;
+/* was a config value set on command line?, 0 or 1. */
+
+int optd_groupd_compat;
+int optd_clean_start;
+int optd_post_join_delay;
+int optd_post_fail_delay;
+int optd_override_time;
+int optd_override_path;
+
+/* actual config value from command line, cluster.conf, or default. */
+
+int cfgd_groupd_compat = DEFAULT_GROUPD_COMPAT;
+int cfgd_clean_start = DEFAULT_CLEAN_START;
+int cfgd_post_join_delay = DEFAULT_POST_JOIN_DELAY;
+int cfgd_post_fail_delay = DEFAULT_POST_FAIL_DELAY;
+int cfgd_override_time = DEFAULT_OVERRIDE_TIME;
+char *cfgd_override_path = DEFAULT_OVERRIDE_PATH;
+
int setup_ccs(void)
{
int i = 0, cd;
@@ -90,7 +109,7 @@ void read_ccs_int(char *path, int *config_val)
int read_ccs(struct fd *fd)
{
- char path[256];
+ char path[PATH_MAX];
char *str;
int error, i = 0, count = 0;
@@ -99,8 +118,8 @@ int read_ccs(struct fd *fd)
fence us. */
str = NULL;
- memset(path, 0, 256);
- snprintf(path, 256, OUR_NAME_PATH, our_name);
+ memset(path, 0, sizeof(path));
+ snprintf(path, sizeof(path), OUR_NAME_PATH, our_name);
error = ccs_get(ccs_handle, path, &str);
if (error || !str) {
@@ -111,44 +130,37 @@ int read_ccs(struct fd *fd)
if (str)
free(str);
- /* The comline config options are initially set to the defaults,
- then options are read from the command line to override the
- defaults, for options not set on command line, we look for
- values set in cluster.conf. */
-
- if (!comline.groupd_compat_opt)
- read_ccs_int(GROUPD_COMPAT_PATH, &comline.groupd_compat);
- if (!comline.clean_start_opt)
- read_ccs_int(CLEAN_START_PATH, &comline.clean_start);
- if (!comline.post_join_delay_opt)
- read_ccs_int(POST_JOIN_DELAY_PATH, &comline.post_join_delay);
- if (!comline.post_fail_delay_opt)
- read_ccs_int(POST_FAIL_DELAY_PATH, &comline.post_fail_delay);
- if (!comline.override_time_opt)
- read_ccs_int(OVERRIDE_TIME_PATH, &comline.override_time);
-
- if (!comline.override_path_opt) {
+ if (!optd_groupd_compat)
+ read_ccs_int(GROUPD_COMPAT_PATH, &cfgd_groupd_compat);
+ if (!optd_clean_start)
+ read_ccs_int(CLEAN_START_PATH, &cfgd_clean_start);
+ if (!optd_post_join_delay)
+ read_ccs_int(POST_JOIN_DELAY_PATH, &cfgd_post_join_delay);
+ if (!optd_post_fail_delay)
+ read_ccs_int(POST_FAIL_DELAY_PATH, &cfgd_post_fail_delay);
+ if (!optd_override_time)
+ read_ccs_int(OVERRIDE_TIME_PATH, &cfgd_override_time);
+
+ if (!optd_override_path) {
str = NULL;
- memset(path, 0, 256);
+ memset(path, 0, sizeof(path));
sprintf(path, OVERRIDE_PATH_PATH);
error = ccs_get(ccs_handle, path, &str);
- if (!error && str) {
- free(comline.override_path);
- comline.override_path = strdup(str);
- }
+ if (!error && str)
+ cfgd_override_path = strdup(str);
if (str)
free(str);
}
- if (comline.clean_start) {
+ if (cfgd_clean_start) {
log_debug("clean start, skipping initial nodes");
goto out;
}
for (i = 1; ; i++) {
str = NULL;
- memset(path, 0, 256);
+ memset(path, 0, sizeof(path));
sprintf(path, "/cluster/clusternodes/clusternode[%d]/@nodeid", i);
error = ccs_get(ccs_handle, path, &str);
diff --git a/fence/fenced/config.h b/fence/fenced/config.h
new file mode 100644
index 0000000..3d919ac
--- /dev/null
+++ b/fence/fenced/config.h
@@ -0,0 +1,26 @@
+#ifndef __CONFIG_DOT_H__
+#define __CONFIG_DOT_H__
+
+#define DEFAULT_GROUPD_COMPAT 1
+#define DEFAULT_CLEAN_START 0
+#define DEFAULT_POST_JOIN_DELAY 6
+#define DEFAULT_POST_FAIL_DELAY 0
+#define DEFAULT_OVERRIDE_TIME 3
+#define DEFAULT_OVERRIDE_PATH "/var/run/cluster/fenced_override"
+
+extern int optd_groupd_compat;
+extern int optd_clean_start;
+extern int optd_post_join_delay;
+extern int optd_post_fail_delay;
+extern int optd_override_time;
+extern int optd_override_path;
+
+extern int cfgd_groupd_compat;
+extern int cfgd_clean_start;
+extern int cfgd_post_join_delay;
+extern int cfgd_post_fail_delay;
+extern int cfgd_override_time;
+extern char *cfgd_override_path;
+
+#endif
+
diff --git a/fence/fenced/fd.h b/fence/fenced/fd.h
index 1e91894..e16da90 100644
--- a/fence/fenced/fd.h
+++ b/fence/fenced/fd.h
@@ -95,34 +95,6 @@ do { \
log_printf(lvl, fmt, ##args); \
} while (0)
-/* config option defaults */
-
-#define DEFAULT_GROUPD_COMPAT 1
-#define DEFAULT_CLEAN_START 0
-#define DEFAULT_POST_JOIN_DELAY 6
-#define DEFAULT_POST_FAIL_DELAY 0
-#define DEFAULT_OVERRIDE_TIME 3
-#define DEFAULT_OVERRIDE_PATH "/var/run/cluster/fenced_override"
-
-struct commandline
-{
- int groupd_compat;
- int clean_start;
- int post_join_delay;
- int post_fail_delay;
- int override_time;
- char *override_path;
-
- int8_t groupd_compat_opt;
- int8_t clean_start_opt;
- int8_t post_join_delay_opt;
- int8_t post_fail_delay_opt;
- int8_t override_time_opt;
- int8_t override_path_opt;
-};
-
-extern struct commandline comline;
-
#define FD_MSG_START 1
#define FD_MSG_VICTIM_DONE 2
#define FD_MSG_COMPLETE 3
diff --git a/fence/fenced/main.c b/fence/fenced/main.c
index bc7fb40..decae46 100644
--- a/fence/fenced/main.c
+++ b/fence/fenced/main.c
@@ -1,5 +1,6 @@
#include "fd.h"
-#include "pthread.h"
+#include "config.h"
+#include <pthread.h>
#include "copyright.cf"
#define LOCKFILE_NAME "/var/run/fenced.pid"
@@ -627,7 +628,7 @@ static void loop(void)
group_mode = GROUP_LIBCPG;
- if (comline.groupd_compat) {
+ if (cfgd_groupd_compat) {
rv = setup_groupd();
if (rv < 0)
goto out;
@@ -635,7 +636,7 @@ static void loop(void)
group_mode = GROUP_LIBGROUP;
- if (comline.groupd_compat == 2) {
+ if (cfgd_groupd_compat == 2) {
/* set_group_mode(); */
group_mode = GROUP_LIBGROUP;
}
@@ -683,7 +684,7 @@ static void loop(void)
break;
}
out:
- if (comline.groupd_compat)
+ if (cfgd_groupd_compat)
close_groupd();
close_logging();
close_ccs();
@@ -779,37 +780,35 @@ static void read_arguments(int argc, char **argv)
break;
case 'g':
- comline.groupd_compat = atoi(optarg);
- comline.groupd_compat_opt = 1;
+ optd_groupd_compat = 1;
+ cfgd_groupd_compat = atoi(optarg);
break;
case 'c':
- comline.clean_start = 1;
- comline.clean_start_opt = 1;
+ optd_clean_start = 1;
+ cfgd_clean_start = 1;
break;
case 'j':
- comline.post_join_delay = atoi(optarg);
- comline.post_join_delay_opt = 1;
+ optd_post_join_delay = 1;
+ cfgd_post_join_delay = atoi(optarg);
break;
case 'f':
- comline.post_fail_delay = atoi(optarg);
- comline.post_fail_delay_opt = 1;
+ optd_post_fail_delay = 1;
+ cfgd_post_fail_delay = atoi(optarg);
break;
case 'R':
- comline.override_time = atoi(optarg);
- if (comline.override_time < 3)
- comline.override_time = 3;
- comline.override_time_opt = 1;
+ optd_override_time = 1;
+ cfgd_override_time = atoi(optarg);
+ if (cfgd_override_time < 3)
+ cfgd_override_time = 3;
break;
case 'O':
- if (comline.override_path)
- free(comline.override_path);
- comline.override_path = strdup(optarg);
- comline.override_path_opt = 1;
+ optd_override_path = 1;
+ cfgd_override_path = strdup(optarg);
break;
case 'h':
@@ -857,14 +856,6 @@ int main(int argc, char **argv)
{
INIT_LIST_HEAD(&domains);
- memset(&comline, 0, sizeof(comline));
- comline.groupd_compat = DEFAULT_GROUPD_COMPAT;
- comline.clean_start = DEFAULT_CLEAN_START;
- comline.post_join_delay = DEFAULT_POST_JOIN_DELAY;
- comline.post_fail_delay = DEFAULT_POST_FAIL_DELAY;
- comline.override_time = DEFAULT_OVERRIDE_TIME;
- comline.override_path = strdup(DEFAULT_OVERRIDE_PATH);
-
init_logging();
read_arguments(argc, argv);
@@ -915,5 +906,4 @@ char dump_buf[FENCED_DUMP_SIZE];
int dump_point;
int dump_wrap;
int group_mode;
-struct commandline comline;
diff --git a/fence/fenced/recover.c b/fence/fenced/recover.c
index be82190..5b46f36 100644
--- a/fence/fenced/recover.c
+++ b/fence/fenced/recover.c
@@ -1,4 +1,5 @@
#include "fd.h"
+#include "config.h"
void free_node_list(struct list_head *head)
{
@@ -164,10 +165,10 @@ void delay_fencing(struct fd *fd, int node_join)
return;
if (node_join) {
- delay = comline.post_join_delay;
+ delay = cfgd_post_join_delay;
delay_type = "post_join_delay";
} else {
- delay = comline.post_fail_delay;
+ delay = cfgd_post_fail_delay;
delay_type = "post_fail_delay";
}
@@ -188,8 +189,8 @@ void delay_fencing(struct fd *fd, int node_join)
if (victim_count < last_count) {
gettimeofday(&start, NULL);
- if (delay > 0 && comline.post_join_delay > delay) {
- delay = comline.post_join_delay;
+ if (delay > 0 && cfgd_post_join_delay > delay) {
+ delay = cfgd_post_join_delay;
delay_type = "post_join_delay (modified)";
}
}
@@ -272,7 +273,7 @@ void fence_victims(struct fd *fd)
continue;
}
- if (!comline.override_path) {
+ if (!cfgd_override_path) {
query_unlock();
sleep(5);
query_lock();
@@ -281,16 +282,16 @@ void fence_victims(struct fd *fd)
query_unlock();
/* Check for manual intervention */
- override = open_override(comline.override_path);
+ override = open_override(cfgd_override_path);
if (check_override(override, node->name,
- comline.override_time) > 0) {
+ cfgd_override_time) > 0) {
log_level(LOG_WARNING, "fence \"%s\" overridden by "
"administrator intervention", node->name);
victim_done(fd, node->nodeid, VIC_DONE_OVERRIDE);
list_del(&node->list);
free(node);
}
- close_override(&override, comline.override_path);
+ close_override(&override, cfgd_override_path);
query_lock();
}
}
hooks/post-receive
--
Cluster Project
^ permalink raw reply related
* [U-Boot-Users] USB Uboot on OSK5912
From: Shivdas Gujare @ 2008-07-18 15:41 UTC (permalink / raw)
To: u-boot
Hi all,
I am working on getting USB-uboot working on OSK5912.
from linux USB gadget "device controller drivers" (i.e.
kernel/drivers/usb/gadget/) it looks like
USB core for omap1510 and OSK5912 is same..But not sure, please confirm
I done following steps.
1)make mrproper
2)make omap5912osk_config
3)go to include/configs/omap5912osk.h
and edit this file with following macros.
.
#define CONFIG_DOS_PARTITION 1
#define CONFIG_USB_OHCI 1
#define CONFIG_USB_OHCI_NEW 1
#define CFG_USB_OHCI_MAX_ROOT_PORTS 1
#define CFG_USB_OHCI_SLOT_NAME "osk5912"
#define CFG_USB_OHCI_REGS_BASE 0xfffba000
#define CONFIG_USB_STORAGE 1
#define CFG_USB_OHCI_BOARD_INIT 1
#define CFG_USB_OHCI_CPU_INIT 1
#define CONFIG_CMD_USB 1
4)after this, I am able to see USB command enabled on Uboot console.
but I am not able to see Mass-storage detected after inserting pendrive
and doing "usb start"
5) from docs/README.generic_usb_ohci, It looks like usb_board_init/stop and
usb_cpu_init/stop
functions are missing and needs to be implemented.
for above all, I am using omap1510 code. but I am not sure will this code
work or not?
also I am not sure, why "usb_board_init/stop and usb_cpu_init/stop" code is
not included in git for
enabling USB uboot on omap1510 or is I am missing any thing?
Please, needs help/confirmation that I can make USB-Uboot work on OSK5912.
Thanks for any help..
Thanks and Regards,
Shivdas Gujare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080718/039dda61/attachment.htm
^ permalink raw reply
* Re: [Bug #10724] ACPI: EC: GPE storm detected, disabling EC GPE
From: Alexey Starikovskiy @ 2008-07-18 15:40 UTC (permalink / raw)
To: Fabio Comolli
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Justin Mattock
In-Reply-To: <b637ec0b0807180217n3b16bcb9wce81161c2c539d7f@mail.gmail.com>
Fabio,
Please try http://bugzilla.kernel.org/attachment.cgi?id=16862 instead.
Same bug entry, last patch.
Regards,
Alex.
Fabio Comolli wrote:
> Hi.
> I also have this problem with 2.6.26 and when it happens I can notice
> that sometimes gnome-power-manager is slow to respond when I switch to
> AC from battery and viceversa. Also, sometimes the g-p-m icon
> disappears and I have to restart the process.
>
> I tried two days ago the patch
>
> http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
>
> and everything seems to work ok since then. Before that, the message
> showed up sometimes at boot time, sometimes minutes later, very
> reliably.
>
> This is with a two years old fairly standard HP laptop.
>
> Regards,
> Fabio
>
>
>
> On Sun, Jul 13, 2008 at 8:00 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.25. Please verify if it still should be listed.
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10724
>> Subject : ACPI: EC: GPE storm detected, disabling EC GPE
>> Submitter : Justin Mattock <justinmattock@gmail.com>
>> Date : 2008-05-16 6:17 (59 days old)
>> References : http://marc.info/?l=linux-kernel&m=121091875711824&w=4
>> http://lkml.org/lkml/2008/5/18/168
>> http://lkml.org/lkml/2008/5/25/195
>> Patch : http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
>> http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
^ permalink raw reply
* Re: [Bug #10724] ACPI: EC: GPE storm detected, disabling EC GPE
From: Alexey Starikovskiy @ 2008-07-18 15:40 UTC (permalink / raw)
To: Fabio Comolli
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Justin Mattock
In-Reply-To: <b637ec0b0807180217n3b16bcb9wce81161c2c539d7f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Fabio,
Please try http://bugzilla.kernel.org/attachment.cgi?id=16862 instead.
Same bug entry, last patch.
Regards,
Alex.
Fabio Comolli wrote:
> Hi.
> I also have this problem with 2.6.26 and when it happens I can notice
> that sometimes gnome-power-manager is slow to respond when I switch to
> AC from battery and viceversa. Also, sometimes the g-p-m icon
> disappears and I have to restart the process.
>
> I tried two days ago the patch
>
> http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
>
> and everything seems to work ok since then. Before that, the message
> showed up sometimes at boot time, sometimes minutes later, very
> reliably.
>
> This is with a two years old fairly standard HP laptop.
>
> Regards,
> Fabio
>
>
>
> On Sun, Jul 13, 2008 at 8:00 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.25. Please verify if it still should be listed.
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10724
>> Subject : ACPI: EC: GPE storm detected, disabling EC GPE
>> Submitter : Justin Mattock <justinmattock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date : 2008-05-16 6:17 (59 days old)
>> References : http://marc.info/?l=linux-kernel&m=121091875711824&w=4
>> http://lkml.org/lkml/2008/5/18/168
>> http://lkml.org/lkml/2008/5/25/195
>> Patch : http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
>> http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
^ permalink raw reply
* Re: [PATCH] ath5k: fix recursive locking in ath5k_beacon_update
From: Pavel Roskin @ 2008-07-18 15:39 UTC (permalink / raw)
To: Bob Copeland; +Cc: ath5k-devel, John W. Linville, linux-wireless
In-Reply-To: <20080718134345.M6916@bobcopeland.com>
On Fri, 2008-07-18 at 09:50 -0400, Bob Copeland wrote:
> Hi all,
>
> I found a lockdep error while playing with AP mode on ath5k. I think
> this is triggerable today in ad-hoc mode.
I think it's a perfect candidate for 2.6.27. If it can affect actual
functionality, it should go to 2.6.26.1.
--
Regards,
Pavel Roskin
^ 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.