* RE: [Qemu-devel] Unified device model
From: Stanislav Shwartsman @ 2006-04-09 6:26 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060408191219.GB16963@jbrown.mylinuxbox.org>
Hi again,
>>It is not a secret that all open source emulators (QEMU, Bochs, Xen) use
>>the same emulated devices and mostly copy-paste their emulation one from
>>another.
>While from my understanding Xen uses qemu's hardware emulation for it's VT
>support, this is not really true otherwise.
>The devices emulated by qemu and bochs are quite similar, but the code
>looks completely different (appears to be a ground-up rewrite).
I am talking about the device models only. Inside CPU emulation QEMU, Bochs
and Xen are completely different, but they use the same devices for full
system emulation and they most likely want to move forward together. The
devices system of QEMU and Bochs become outdate, it is required to add ACPI
compliance and emulate new modern ACPI compatible devices, currently
emulated i440FX already not so represent the real life and most of the
modern OSes already have no support for it.
>> I don't know who originally wrote the device models but now Bochs and
>> QEMU maintain two similar implementations of the same devices.
>> If one of the teams fixes the implementation or add functionality,
>> another team mostly copy-paste the changes to their model.
>I don't know how well Bochs and qemu keep in touch with each other. I've
>never seen a Bochs developer announce themselves here, though.
So may we should ;)
At least I see the code changes from Bochs migrating to QEMU and vise versa
when I am looking into the code.
>>Xen project forked from QEMU and want to stay in touch with Bochs and QEMU
>>device models and contribute the changes to make the model better.
>Not true. Xen is completely independent. Unless you are refering to the
>hardware emulation - which I believe is qemu's stuff.
I know that it is completely independent project. But their device models
could be called separate project Xen-HWEMU and it is fork from QEMU.
>>I am wondering about making unified device models architecture for open
>>source simulators.
>>The device models will be used in QEMU, Bochs, Xen and other open source
>>simulators which would use the device models.
>I would support this idea, if it was possible.
Why not ?
You always could consider to add simple modules C++ to QEMU or build C++
device -> C device interface bridge ...
I don't know all the possibilities, but I am sure there are more.
>>I know about two professional teams working in simulation which would like
>>to use these device models in their simulator and
>>could enrich the device library with new devices device interfaces, for
>>example with AGP and 3D graphics.
>>Bochs is already in middle of definition of new true pluginable devices
>>architecture.
>This is welcome news.
Currently we are thinking about making user-plugin PCI devices and when
later user-plugin for any device. The C++ hierarchy for now might be:
bx_devmodel_c - bx_pcidev_c - bx_user_pcidev_c
The plans are to take one of the Bochs PCI devices and convert it into
user-level plugin which should not be compiled with Bochs and even not known
at compile time, but loaded at runtime if selected in runtime config file.
When any other device models could be added, even with closed-sources and
commercial licenses.
>The primary reason given for not making a plugin API for qemu hardware
>emulationis that qemu isn't stable enough - the code changes too often to
>support a stable API.
>Still, it might be easier to add support for plugins based on an external
>API, rather than trying to keep a qemu plugin API consistent.
Ok, I didn't knew that QEMU is so unstable. But at least there are several
trivial requirements from plugin architecture which you could mention here
and I am still not thought about it. I know, basically I am writing the
definition in my idle time and Volker supporting me. But it is not enough
...
Thanks,
Stanislav
^ permalink raw reply
* RE: [Qemu-devel] Unified device model
From: Stanislav Shwartsman @ 2006-04-09 6:29 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44380E9B.5040906@win4lin.com>
Currently Bochs plugins APCI already begins with such C-language bindings.
But inside the device is C++ based and derives from Bochs device model. It
has the same log writer and debugging interface as any other Bochs module
but nothing more.
Could you look into the Bochs devices code and plugin code, I think you
could say how much it is compatible fro QEMU and if there is something that
we should consider to change ...
Stanislav
-----Original Message-----
From: qemu-devel-bounces+stl=fidonet.org.il@nongnu.org
[mailto:qemu-devel-bounces+stl=fidonet.org.il@nongnu.org] On Behalf Of
Leonardo E. Reiter
Sent: Saturday, April 08, 2006 9:27 PM
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Unified device model
Well, not completely impossible, but it would require some really ugly
"glue" code. And, the glue would have to happen outside of QEMU (i.e.
like in the BOCHS code), to keep C++ out of QEMU.
To have a truly portable API, it should definitely have C language
"bindings". I'm sure this could be added to the BOCHS implementation
somehow if this is important.
- Leo Reiter
Johannes Schindelin wrote:
> IIRC bochs does it in C++. Which makes it rather impossible to share code
> :-(
>
> Ciao,
> Dscho
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
^ permalink raw reply
* Re: + git-klibc-mktemp-fix.patch added to -mm tree
From: Herbert Xu @ 2006-04-09 5:33 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Sam Ravnborg, linux-kernel, akpm, mm-commits
In-Reply-To: <44381C9A.3050502@zytor.com>
On Sat, Apr 08, 2006 at 01:27:06PM -0700, H. Peter Anvin wrote:
>
> Herbert: can the code be restructured with appropriate casts so that
> signed/unsigned is factored out of mksyntax? As it currently stands,
> it's not cross-compile-safe, which is unacceptable.
Sure, I'll send you a patch to convert it to always use unsigned char.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [parisc-linux] Re: + parisc-add-ptr-compatpatch.patch added to -mm tree
From: Ingo Molnar @ 2006-04-09 5:37 UTC (permalink / raw)
To: Kyle McMartin; +Cc: Andrew Morton, parisc-linux
In-Reply-To: <20060409001100.GD30539@quicksilver.road.mcmartin.ca>
* Kyle McMartin <kyle@mcmartin.ca> wrote:
> [Sorry about how long it has taken to get to this... I bounced it to
> parisc-linux too, so hopefully someone else can comment as well.]
>
> On Wed, Feb 22, 2006 at 10:13:56AM +0100, Ingo Molnar wrote:
> > There's only one complication i can imagine on PARISC: truly atomic
> > futex_atomic_cmpxchg_inuser() is not possible in any sane way because
> > any spinlock based cmpxchg exposes itself to userspace locking up the
> > kernel - no good. [We could in theory do something about it by imposing
> > some sort of deadline on the maximum time the spinning-on-userspace-lock
> > can take - but i dont think it's worth the trouble.]
> >
>
> Due to a complete lack of useful atomic operations on parisc, the way
> I envisioned implementing the routines was serializing all futex ops
> on a kernel spinlock. Since it's a userspace address, we couldn't use
> an atomic hash unless we found the physical address behind it, so just
> one spinlock would do... Of course, I'm probably missing something
> critical here, though.
if userspace doesnt do atomic ops then the solution should be relatively
easy: make glibc always call into the kernel, and then the kernel-level
futex.h ops can be implemented in a lockless manner (i.e. not even a
spinlock is needed) and you'll get (pretty scalable) futex
functionality. The in-kernel futex hash-bucket spinlocks take care of
locking.
Ingo
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* [lm-sensors] i2c-i801 and i2c-i810 can't see 82845G
From: Andrew @ 2006-04-09 5:42 UTC (permalink / raw)
To: lm-sensors
Hi All,
I'm trying to get sensors working on a motherboard I have (see details
below)
I have run sensors-detect (see output further below) - and it says that
I have a i801 chipset, but when I run sensors I get this output:
"No sensors found!"
I am running a 2.6.16.2 kernel on a debian x86 machine.
Kind Regards,
Andrew.
(lspci gives this output)
0000:00:00.0 Host bridge: Intel Corp. 82845G/GL[Brookdale-G]/GE/PE DRAM
Controller/Host-Hub Interface (rev 01)
Subsystem: Intel Corp. 82845G/GL[Brookdale-G]/GE/PE DRAM
Controller/Host-Hub Interface
Flags: bus master, fast devsel, latency 0
Memory at d0000000 (32-bit, prefetchable) [size\x128M]
Capabilities: [e4] #09 [0105]
(sensors-detect gives this output):
This program will help you determine which I2C/SMBus modules you need to
load to use lm_sensors most effectively. You need to have i2c and
lm_sensors installed before running this program.
Also, you need to be `root', or at least have access to the /dev/i2c-*
files, for most things.
If you have patched your kernel and have some drivers built in, you can
safely answer NO if asked to load some modules. In this case, things may
seem a bit confusing, but they will still work.
It is generally safe and recommended to accept the default answers to all
questions, unless you know what you're doing.
We can start with probing for (PCI) I2C or SMBus adapters.
You do not need any special privileges for this.
Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-i801' for device 00:1f.3: Intel 82801DB ICH4
Probe succesfully concluded.
We will now try to load each adapter module in turn.
Module `i2c-i801' already loaded.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.
To continue, we need module `i2c-dev' to be loaded.
If it is built-in into your kernel, you can safely skip this.
i2c-dev is already loaded.
We are now going to do the adapter probings. Some adapters may hang halfway
through; we can't really help that. Also, some chips will be double
detected;
we choose the one with the highest confidence value in that case.
If you found that the adapter hung after probing a certain address, you can
specify that address to remain unprobed. That often
includes address 0x69 (clock chip).
Next adapter: SMBus I801 adapter at 5000
Do you want to scan it? (YES/no/selectively):
Client found at address 0x08
Client found at address 0x30
Client found at address 0x31
Client found at address 0x44
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Client found at address 0x50
Probing for `SPD EEPROM'... Success!
(confidence 8, driver `eeprom')
Probing for `DDC monitor'... Failed!
Probing for `Maxim MAX6900'... Failed!
Client found at address 0x51
Probing for `SPD EEPROM'... Success!
(confidence 8, driver `eeprom')
Client found at address 0x69
Some chips are also accessible through the ISA bus. ISA probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.
Do you want to scan the ISA bus? (YES/no): Probing for `National
Semiconductor LM78'
Trying address 0x0290... Failed!
Probing for `National Semiconductor LM78-J'
Trying address 0x0290... Failed!
Probing for `National Semiconductor LM79'
Trying address 0x0290... Failed!
Probing for `Winbond W83781D'
Trying address 0x0290... Failed!
Probing for `Winbond W83782D'
Trying address 0x0290... Failed!
Probing for `Winbond W83627HF'
Trying address 0x0290... Failed!
Probing for `Winbond W83627EHF'
Trying address 0x0290... Failed!
Probing for `Winbond W83697HF'
Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
Trying general detect... Failed!
Probing for `ITE IT8712F'
Trying address 0x0290... Success!
(confidence 8, driver `it87')
Probing for `ITE IT8705F / SiS 950'
Trying address 0x0290... Failed!
Probing for `IPMI BMC KCS'
Trying address 0x0ca0... Failed!
Probing for `IPMI BMC SMIC'
Trying address 0x0ca8... Failed!
Some Super I/O chips may also contain sensors. Super I/O probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for `ITE 8702F Super IO Sensors'
Success... found at address 0x0290
Probing for `ITE 8705F Super IO Sensors'
Failed! (0x8702)
Probing for `ITE 8712F Super IO Sensors'
Failed! (0x8702)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
Failed! (skipping family)
Probing for `Winbond W83627EHF Super IO Sensors'
Failed! (skipping family)
Do you want to scan for secondary Super I/O sensors? (YES/no):
Probing for `ITE 8702F Super IO Sensors'
Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
Failed! (skipping family)
Probing for `Winbond W83627EHF Super IO Sensors'
Failed! (skipping family)
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `eeprom' (should be inserted):
Detects correctly:
* Bus `SMBus I801 adapter at 5000'
Busdriver `i2c-i801', I2C address 0x50
Chip `SPD EEPROM' (confidence: 8)
* Bus `SMBus I801 adapter at 5000'
Busdriver `i2c-i801', I2C address 0x51
Chip `SPD EEPROM' (confidence: 8)
Driver `it87' (may not be inserted):
Misdetects:
* ISA bus address 0x0290 (Busdriver `i2c-isa')
Chip `ITE IT8712F' (confidence: 8)
Driver `to-be-written' (should be inserted):
Detects correctly:
* ISA bus address 0x0290 (Busdriver `i2c-isa')
Chip `ITE 8702F Super IO Sensors' (confidence: 9)
I will now generate the commands needed to load the I2C modules.
Sometimes, a chip is available both through the ISA bus and an I2C bus.
ISA bus access is faster, but you need to load an additional driver module
for it. If you have the choice, do you want to use the ISA bus or the
I2C/SMBus (ISA/smbus)?
To make the sensors modules behave correctly, add these lines to
/etc/modules:
#----cut here----
# I2C adapter drivers
i2c-i801
i2c-isa
# I2C chip drivers
eeprom
# no driver for ITE 8702F Super IO Sensors yet
#----cut here----
^ permalink raw reply
* Re: [PATCH 2.6.16] Shared interrupts sometimes lost
From: Neil Brown @ 2006-04-09 6:02 UTC (permalink / raw)
To: Lee Revell; +Cc: linux-kernel
In-Reply-To: <1144513897.22490.154.camel@mindpipe>
On Saturday April 8, rlrevell@joe-job.com wrote:
> On Sat, 2006-04-08 at 14:10 +1000, Neil Brown wrote:
> >
> > To explain what I think is happening, let me start with a very simple
> > case. A number of PCI devices (this one included) have a number of
> > events which can trigger an interrupt. The events which are current
> > are presented as bits in a register, and are ORed together (and
> > possibly masked by another register) to make the IRQ line.
> > When 1's are written to any bits in this register, it acknowledges
> > the event and clears the bit.
> > A typical code fragment is
> > events = read_register(INTERRUPTS);
> > write_register(INTERRUPTS, events);
> > ... handle each 1 bits in events ....
> >
>
> Isn't a more typical IRQ handler:
>
> while (events = read_register(INTERRUPTS) != 0) {
> ...handle each bit in events and ACK it...
> }
Maybe... I admit that I generalised from 2 examples: rt2500 and yenta.
However I don't think it makes a big difference to the problem with
shared interrupts (assuming my analysis is right).
The loop isn't really necessary if you are sure that unserviced
interrupts will be re-asserted (as level-triggered interrupts would
be) (though it may still help performance) and the loop isn't
sufficient if you need to be sure that all events get services (as
there may be more in the shared-chain).
Thanks,
NeilBrown
^ permalink raw reply
* Re: [RFC][PATCH 1/5] uts namespaces: Implement utsname namespaces
From: Andi Kleen @ 2006-04-09 6:00 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: linux-kernel
In-Reply-To: <20060408202840.GB26403@sergelap.austin.ibm.com>
On Saturday 08 April 2006 22:28, Serge E. Hallyn wrote:
> This is something we've been discussing - whether to use a single
> "container" structure pointing to all the namespaces, or put everything
> into the task_struct. Using container structs means more cache misses
> and refcounting issues, but keeps task_struct smaller as you point out.
The more cache misses argument seems bogus to me. If you consider
the case of a lot of processes with lots of shared name spaces
the overall foot print should be in fact considerable less.
> The consensus so far has been to start putting things into task_struct
> and move if needed. At least the performance numbers show that so far
> there is no impact.
Performance is not the only consider consideration here. Overall
memory consumption is important too.
Sure for a single namespace like utsname it won't make much difference,
but it likely will if you have 10-20 of these things.
>
> iirc container patches have been sent before. Should those be resent,
> then, and perhaps this patchset rebased on those?
I think so.
-Andi
^ permalink raw reply
* Re: kernel vs user power management
From: Andi Kleen @ 2006-04-09 6:07 UTC (permalink / raw)
To: Brown, Len; +Cc: Holger Macht, thoenig, linux-acpi, linux-laptop, jacob.shin
In-Reply-To: <CFF307C98FEABE47A452B27C06B85BB622B275@hdsmsx411.amr.corp.intel.com>
On Sunday 09 April 2006 05:06, Brown, Len wrote:
> >Furthermore, we had some problems on multiprocessor systems in the past
> >(about 1/2 year ago) with the ondemand governor. After some time the
> >system was running (even some hours or even days) the machine locked up
> >hard. Thus, we set the userspace governor by default on those systems
> >where we never experienced such problems. At the moment I did
> >only get one similar report where the root cause is not clear.
>
> It is important that this failure be root caused and this
> doubt be put behind us. Got a bug URL?
IIRC that was a powernow-k8 problem - should be fixed now.
> I don't know if the amd-specific drivers would work or not.
> Last I heard their latency was too high, but maybe they've
> fixed that.
I don't think so.
> I think you'll need to keep the userspace backup scheme for systems
> which have switching latency too high to load and run ondemand.
That would be pretty much all AMD systems at least.
But it's ugly - it would be better if ondemand worked on those too.
Anyways not your problem I guess, Len.
> >If so, I fully agree with you. But I do not set a specific
> >policy in the powersave code explicitely for that feature.
> >If the policy information
> >will go into the kernel, I will use and set this one, of course.
>
> okay, great.
> Yes, the kernel folks have known for years that this has to be done.
> Hopefully progress will be made soon...
I'm hoping the kernel will be able to put USB mouses to sleep
soon at least.
-Andi
^ permalink raw reply
* [lm-sensors] nForce 430 SMBus
From: Rudolf Marek @ 2006-04-09 6:44 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <74ee72ca0604071607l1c1063b2iad93659df1bfe3fa@mail.gmail.com>
Mark Rages wrote:
> Ok, here it is.
Bad luck, due to sensors on ISA there is even no smbus definition
it seems. But hey you found it out anyway ;)
Regards
Rudolf
^ permalink raw reply
* iptables setting problem
From: Dexter @ 2006-04-09 6:48 UTC (permalink / raw)
To: netfilter
Dear Sir,
I encounter the problem of setting the iptables.
I manually set eth0 210.21.47.32 netmask 255.255.255.0 gateway
210.21.47.1 and eth1 192.168.1.1 netmask 255.255.255.0
and setting of Lan computer is 192.168.1.2 255.255.255.0 192.168.1.1
from the computer in Lan I can ping both the address of eth0 and eth1,
but I can not ping the default gateway that ISP assigned to me.
I did the following:
iptables -A FORWARD -i eth1 -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward
but didn't work, then I did follow:
iptables -t nat -A PREROUTING -d $210.21.47.32/24 -i eth0 -j DNAT
--to-destination 192.168.1.0
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT
--to-source $210.21.47.32
but still didn't work. something wring with my setting. Thanks.
Best Regards,
Dexter Co
^ permalink raw reply
* Re: SDIO Drivers?
From: Marcel Holtmann @ 2006-04-09 6:55 UTC (permalink / raw)
To: Pierre Ossman; +Cc: Ram, linux-kernel
In-Reply-To: <443628F3.9050107@drzeus.cx>
Hi Pierre,
> > 3) Is it a generic driver ?. (Same for a set of devices) or
> > different for each device?
> > Suppose i want to run an SDIO WLAN Card?. will the
> > manufacturer support it or
> > an will a Generic Driver "drive" it?
for WiFi this is unlikely, but for Bluetooth there exists an open
standard on how to access Bluetooth cards. So the easiest way might be
to use a Bluetooth SDIO device to build the driver model.
> > 6) Are there any sample/Open Source SDIO drivers available in Linux
> > Kernel or else where?.If, not when can one expect/is anyone working on
> > it currently?.
>
> There are a lot of people interested, but I haven't seen anyone working
> on it yet.
This includes me and I finally have a SDHCI capable laptop and one of
the Bluetooth SDIO cards. However my time is so limited at the moment,
that I haven't looked at it.
Regards
Marcel
^ permalink raw reply
* [lm-sensors] Intel Corporation 82801G (ICH7 Family)
From: Jean Delvare @ 2006-04-09 6:55 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20060409002329.46268.qmail@web36810.mail.mud.yahoo.com>
Hi Mathew,
When starting a new discussion topic on a mailing list, please don't
use the "Reply" function of your e-mail client, else it makes it hard
for anyone with a threading e-mail client to follow what's going on.
See the mailing list archive [1] for an example of how bad it looks
like: you seem to be going on with an existing topic, while your post
is not related at all!
[1] http://lists.lm-sensors.org/pipermail/lm-sensors/2006-April/thread.html
Instead, please start a new discussion thread, using "Compose" or
"New", whatever your own e-mail client names it. Do that now and I'll
help you with your problem.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 2.6.17-rc1-mm1 0/6] Migrate-on-fault - Overview
From: Andi Kleen @ 2006-04-09 7:01 UTC (permalink / raw)
To: Lee Schermerhorn; +Cc: linux-mm
In-Reply-To: <1144441108.5198.36.camel@localhost.localdomain>
On Friday 07 April 2006 22:18, Lee Schermerhorn wrote:
> This is a reposting of the migrate-on-fault series, against
> the 2.6.17-rc1-mm1 tree. I would love to get some feedback on
> these patches--especially regarding criteria for getting them
> into the mm tree for wider testing.
The biggest criteria would be some numbers that it actually
helps for something and doesn't break performance in other workloads.
For me it seems rather risky.
-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Linux 2.6.17-rc1: /sbin/iptables does not find kernel netfilter
From: Ville Herva @ 2006-04-09 7:43 UTC (permalink / raw)
To: Patrick McHardy; +Cc: linux-kernel, netfilter, davem
In-Reply-To: <44388908.6070602@trash.net>
On Sun, Apr 09, 2006 at 06:09:44AM +0200, you [Patrick McHardy] wrote:
> Ville Herva wrote:
> > I upgraded from 2.6.15-rc7 to 2.6.17-rc1. rc1 seems nice other than that
> > iptables stopped working:
> >
> > failed iptables v1.3.5: can't initialize iptables table filter: iptables
> > who? (do you need to insmod?)
> > Perhaps iptables or your kernel needs to be upgraded.
> >
> > iptables is compiled in the kernel, not a module:
> > CONFIG_NETFILTER=y
> >
> > I can even do "modprobe iptable_nat" successfully (iptable_nat is module),
> > but iptables refuses to work. iptables is of version iptables-1.3.5-1.2.
> >
> > The kernel config is copied with make oldconfig from 2.6.15-rc7 (which
> > worked), not much else has changed. I just booted back to 2.6.15-rc7 and
> > verified it works. Any ideas?
>
> Most likely you didn't enable the new xtables options. Please post your
> full config.
The full .config is here
http://www.iki.fi/v/tmp/2.6.17-rc1.config
I indeed do not have xfilter enabled (I was unaware that such thing had been
introduced :):
--8<-----------------------------------------------------------------------
...
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NETFILTER_XTABLES is not set
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=m
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_NETBIOS_NS is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_PPTP is not set
# CONFIG_IP_NF_H323 is not set
# CONFIG_IP_NF_QUEUE is not set
...
--8<-----------------------------------------------------------------------
I'll try building a new kernel with CONFIG_NETFILTER_XTABLES enabled and
report back. Thanks!
-- v --
v@iki.fi
^ permalink raw reply
* Re: Masquerading problems - XenU 3.0 on x86_64
From: Keir Fraser @ 2006-04-09 7:46 UTC (permalink / raw)
To: Jim Pick; +Cc: xen-devel Devel
In-Reply-To: <44384EDA.2080106@jimpick.com>
On 9 Apr 2006, at 01:01, Jim Pick wrote:
> I'm trying to migrate my Xen sessions installed on 32-bit Xen 2.0
> server to a 64-bit Xen 3.0 server.
>
> On the Xen 2.0 server (32-bit), I built a DomU kernel with
> masquerading, and I use that to do NAT for some private networks
> running on the same box.
>
> When I tried to do it with Xen 3.0 (64-bit), I couldn't get it to
> work. I had to build a custom DomU kernel (from xen-3.0-testing.hg,
> 2.6.16, 2 days ago) in order to include the netfilter/iptables code.
> ICMP works. TCP doesn't. Non-masquerading traffic is OK. I had the
> same problems with the 2.6.12 kernel from Xen 3.0.1.
>
> I captured some of the traffic, and ethereal is showing that the
> masqueraded traffic being output has bad TCP checksums.
>
> I'm going to have to do some debugging to try to figure out what's
> going wrong.
>
> Has anybody else encountered this? Also, if it's already been fixed
> somewhere, I'd love to know. Any Netfilter debugging tips would also
> be appreciated.
Turn off tx checksum offload in your domU's using ethtool. We had fixed
some forms of NAT with our checksum offload, but maybe not for your
type of setup.
-- Keir
^ permalink raw reply
* Re: Maximum number of DomUs? (x86_64)
From: Keir Fraser @ 2006-04-09 7:48 UTC (permalink / raw)
To: Florian Kirstein; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <20060409033726.A9073@web.ray.net>
On 9 Apr 2006, at 02:37, Florian Kirstein wrote:
> So I wonder, which structure could run out of memory there? Is this a
> known
> limitation? Didn't find much about the maximum number of DomUs
> in the list archives... The Dom0 is running a CentOS4 x86_64 and I
> don't
> even need a DomU image to reach this limit, network and diskless DomUs
> just running into an "no root filesystem" panic being "preserve"d after
> the crash have the same effect.
Xen's own private heap is fixed size (16MB) and that's used to allocate
a certain amount of per-domain state. This restriction could be lifted
on x86/64 but it's not particularly a priority right now.
-- Keir
^ permalink raw reply
* Re: [RFC] Hypercalls from HVM guests
From: Keir Fraser @ 2006-04-09 7:56 UTC (permalink / raw)
To: Nakajima, Jun; +Cc: Steve Ofsthun, xen-devel
In-Reply-To: <7F740D512C7C1046AB53446D37200173078AF163@scsmsx402.amr.corp.intel.com>
On 9 Apr 2006, at 00:33, Nakajima, Jun wrote:
> If eax is set to a value outside the recognized range of CPUID
> currently
> defined, CPUID does not necessarily return all zero's on Intel. It's
> "Reserved" (Information returned for highest basic information leaf).
> Also "an unused index" can have conflicts in the future.
>
> If we just need to tell on which CPU the current HVM guest is running,
> I
> think "GeunineIntel" or "AuthenticAMD" is the best because it's been
> used by native systems as well.
Then how do you tell whether you are running on a hypervisor without
executing some instruction that might fault? We would like to avoid
requiring that.
There is quite a lot of CPUID and MSR address space, and a random
return value for CPUID when running natively is practically-speaking
fine if we're looking for a 128-bit signature.
The only other option I think would be a BIOS table, probably below
1MB. I prefer the CPUID/MSR method.
-- Keir
^ permalink raw reply
* [lm-sensors] i2c-i801 and i2c-i810 can't see 82845G
From: Jean Delvare @ 2006-04-09 7:58 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <44389EC6.4060402@donehue.net>
Hi Andrew,
> I'm trying to get sensors working on a motherboard I have (see details
> below)
>
> I have run sensors-detect (see output further below) - and it says that
> I have a i801 chipset, but when I run sensors I get this output:
> "No sensors found!"
>
> I am running a 2.6.16.2 kernel on a debian x86 machine.
> (...)
> (lspci gives this output)
> 0000:00:00.0 Host bridge: Intel Corp. 82845G/GL[Brookdale-G]/GE/PE DRAM
> Controller/Host-Hub Interface (rev 01)
> Subsystem: Intel Corp. 82845G/GL[Brookdale-G]/GE/PE DRAM
> Controller/Host-Hub Interface
> Flags: bus master, fast devsel, latency 0
> Memory at d0000000 (32-bit, prefetchable) [size\x128M]
> Capabilities: [e4] #09 [0105]
This isn't the device with the SMBus interface. Look for an entry with
type "SMBus", e.g.:
00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 01)
Subsystem: Sony Corporation VAIO PCG-GR214EP/GR214MP/GR215MP/GR314MP/GR315MP
Flags: medium devsel, IRQ 255
I/O ports at 1880 [size2]
> Probing for PCI bus adapters...
> Use driver `i2c-i801' for device 00:1f.3: Intel 82801DB ICH4
> Probe succesfully concluded.
>
> We will now try to load each adapter module in turn.
> Module `i2c-i801' already loaded.
> (...)
> Next adapter: SMBus I801 adapter at 5000
> Do you want to scan it? (YES/no/selectively):
> Client found at address 0x08
> Client found at address 0x30
> Client found at address 0x31
> Client found at address 0x44
> Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
> Client found at address 0x50
> Probing for `SPD EEPROM'... Success!
> (confidence 8, driver `eeprom')
> Probing for `DDC monitor'... Failed!
> Probing for `Maxim MAX6900'... Failed!
> Client found at address 0x51
> Probing for `SPD EEPROM'... Success!
> (confidence 8, driver `eeprom')
> Client found at address 0x69
This means that your SMBus adapter was properly detected by the
i2c-i801 driver, but you only have SPD EEPROMs (memory module
information) available on this bus.
As for the i2c-i810 driver, you need lm_sensors 2.10.0 or later for
sensors-detect to find it. With earlier version, you must load it
manually before running sensors-detect if you want it to be probed.
However, this only makes sense if you are actually using the integrated
graphics chip and not an additional graphics adapter. Even then, the
chances that any hardware monitoring device is found on this bus are
very thin, all you'll see there is most certainly an information EEPROM
about the connected display if it supports DDC.
> Probing for `ITE 8702F Super IO Sensors'
> Success... found at address 0x0290
This is your hardware monitoring chip. It's not a dedicated chip on the
SMBus, instead the hardware monitoring features are integrated into
your ITE Super-I/O chip.
Unfortunately, we don't have a driver for this chip at the moment. A
datasheet is available, so writing a driver is possible, however, this
takes time and we don't have much. I could find two previous requests
here:
http://lists.lm-sensors.org/pipermail/lm-sensors/2003-August/003765.html
http://secure.netroedge.com/~lm78/readticket.cgi?ticket\x1828
I've updated our "new drivers" page to mention all three requests.
According to my earlier investigation, the IT8702F chip only supports
fan speed monitoring and control (5 channels) and VID input, so it's
not a complete hardware monitoring chip (no voltages, no temperatures.)
The good side is that the driver should be relatively simple to write,
if anyone wants to take a chance.
You may try ACPI for the temperature (modprobe thermal, acpi -V).
--
Jean Delvare
^ permalink raw reply
* Re: How to create independent branches
From: Peter Baumann @ 2006-04-09 8:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <e18vcv$rhf$1@sea.gmane.org>
On Sat, Apr 08, 2006 at 08:28:58PM +0200, Jakub Narebski wrote:
> Peter Baumann wrote:
>
> > Another question. I'd like to create a totaly independent branch (like
> > the "todo" branch in git). Is there a more user friendly way than doing
> >
> > git-checkout -b todo
> > rm .git/refs/heads/todo
> > rm .git/index
> > rm <all_files_in_your_workdir>
> >
> > ... hack hack hack ...
> > git-commit -a
>
> Wouldn't it be better and more natural to go back to first commit? >
If I go back to the first commit, I'll get the following:
first
/ \
/ \
master todo
That's not what I want, because in the near future I want to merge
master and todo, but in my case, todo consists of only of one file (lets
call it file_a), and the master branch has severeal files (file_{a..z}).
If I go back to first, I have to delete all files file_{b..z}.
Further file_a from todo and file_a from master are not equal, the share
just the same name. But in the near future, they will be merged
together, so they are equal.
If I go with the above branching, I'll _think_ (I may be wrong, please
correct me if I am) I get a merge conflict or worse, all my other files
file_a{b..z} are merged as "deleted", wich is wrong.
> Or even empty repository state at the beginning, and branch there?
This isn't possible because the repository already exists and I don't
know how to go back to the empty repository state. Even
git-init-db
git branch todo master
didn't work.
> Or make separate repository?
Ok. You got it. In fact, the todo branch alread exists as a seperate
repository and I'd like to integrate this in my master repository for
easier handling (diff etc.)
To import todo as a subproject doesn't seem right, because it's not
something really independent in the view of the master repo and I'am
going to merge todo _into_ master in the near future.
Any further suggestions?
-Peter
^ permalink raw reply
* [ALSA - utils 0002012]: aplay.c has incorrect syntax in error message
From: bugtrack @ 2006-04-09 8:14 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2012>
======================================================================
Reported By: jaime
Assigned To:
======================================================================
Project: ALSA - utils
Issue ID: 2012
Category: aplay/arecord
Reproducibility: always
Severity: minor
Priority: normal
Status: new
======================================================================
Date Submitted: 04-09-2006 10:14 CEST
Last Modified: 04-09-2006 10:14 CEST
======================================================================
Summary: aplay.c has incorrect syntax in error message
Description:
aplay.c line 920:
fprintf(stderr, _(" please, try the plug plugin (-Dplug:%s)\n"),
snd_pcm_name(handle));
This outputs:
"please, try the plug plugin (-Dplug:hw:0,0)"
Using the recommended syntax returns:
ALSA lib conf.c:3824:(parse_args) Unknown parameter 1
ALSA lib conf.c:3946:(snd_config_expand) Parse arguments error: No such
file or directory
ALSA lib pcm.c:2099:(snd_pcm_open_noupdate) Unknown PCM plug:hw:0,0
aplay: main:544: audio open error: No such file or directory
The syntax should be:
-Dplughw:0,0
(without the colon after the word "plug")
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
04-09-06 10:14 jaime New Issue
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [PATCH] read_mapping_page for address space
From: Pekka Enberg @ 2006-04-09 8:18 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, linux-fsdevel
From: Pekka Enberg <penberg@cs.helsinki.fi>
This patch adds read_mapping_page function which is the used for
callers that pass mapping->a_ops->readpage as the filler for
read_cache_page. This removes some duplication from filesystem
code.
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
fs/afs/dir.c | 4 +---
fs/afs/mntpt.c | 11 ++---------
fs/cramfs/inode.c | 4 +---
fs/ext2/dir.c | 3 +--
fs/freevxfs/vxfs_subr.c | 3 +--
fs/hfs/bnode.c | 2 +-
fs/hfs/btree.c | 2 +-
fs/hfsplus/bitmap.c | 15 +++++++--------
fs/hfsplus/bnode.c | 2 +-
fs/hfsplus/btree.c | 2 +-
fs/jfs/jfs_metapage.c | 5 ++---
fs/minix/dir.c | 3 +--
fs/namei.c | 3 +--
fs/ntfs/aops.h | 3 +--
fs/ntfs/attrib.c | 6 ++----
fs/ntfs/file.c | 3 +--
fs/ocfs2/symlink.c | 3 +--
fs/partitions/check.c | 4 ++--
fs/reiserfs/xattr.c | 3 +--
fs/sysv/dir.c | 3 +--
include/linux/pagemap.h | 7 +++++++
mm/swapfile.c | 3 +--
22 files changed, 38 insertions(+), 56 deletions(-)
caac39476851978a912f8837aa5fd5e92fa2213f
diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index a6dff6a..2fc9987 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -185,9 +185,7 @@ static struct page *afs_dir_get_page(str
_enter("{%lu},%lu", dir->i_ino, index);
- page = read_cache_page(dir->i_mapping,index,
- (filler_t *) dir->i_mapping->a_ops->readpage,
- NULL);
+ page = read_mapping_page(dir->i_mapping, index, NULL);
if (!IS_ERR(page)) {
wait_on_page_locked(page);
kmap(page);
diff --git a/fs/afs/mntpt.c b/fs/afs/mntpt.c
index 4e6eeb5..b5cf9e1 100644
--- a/fs/afs/mntpt.c
+++ b/fs/afs/mntpt.c
@@ -63,7 +63,6 @@ unsigned long afs_mntpt_expiry_timeout =
int afs_mntpt_check_symlink(struct afs_vnode *vnode)
{
struct page *page;
- filler_t *filler;
size_t size;
char *buf;
int ret;
@@ -71,10 +70,7 @@ int afs_mntpt_check_symlink(struct afs_v
_enter("{%u,%u}", vnode->fid.vnode, vnode->fid.unique);
/* read the contents of the symlink into the pagecache */
- filler = (filler_t *) AFS_VNODE_TO_I(vnode)->i_mapping->a_ops->readpage;
-
- page = read_cache_page(AFS_VNODE_TO_I(vnode)->i_mapping, 0,
- filler, NULL);
+ page = read_mapping_page(AFS_VNODE_TO_I(vnode)->i_mapping, 0, NULL);
if (IS_ERR(page)) {
ret = PTR_ERR(page);
goto out;
@@ -160,7 +156,6 @@ static struct vfsmount *afs_mntpt_do_aut
struct page *page = NULL;
size_t size;
char *buf, *devname = NULL, *options = NULL;
- filler_t *filler;
int ret;
kenter("{%s}", mntpt->d_name.name);
@@ -182,9 +177,7 @@ static struct vfsmount *afs_mntpt_do_aut
goto error;
/* read the contents of the AFS special symlink */
- filler = (filler_t *)mntpt->d_inode->i_mapping->a_ops->readpage;
-
- page = read_cache_page(mntpt->d_inode->i_mapping, 0, filler, NULL);
+ page = read_mapping_page(mntpt->d_inode->i_mapping, 0, NULL);
if (IS_ERR(page)) {
ret = PTR_ERR(page);
goto error;
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 9efcc3a..ccd3f96 100644
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -181,9 +181,7 @@ static void *cramfs_read(struct super_bl
struct page *page = NULL;
if (blocknr + i < devsize) {
- page = read_cache_page(mapping, blocknr + i,
- (filler_t *)mapping->a_ops->readpage,
- NULL);
+ page = read_mapping_page(mapping, blocknr + i, NULL);
/* synchronous error? */
if (IS_ERR(page))
page = NULL;
diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index d672aa9..3c1c9aa 100644
--- a/fs/ext2/dir.c
+++ b/fs/ext2/dir.c
@@ -159,8 +159,7 @@ fail:
static struct page * ext2_get_page(struct inode *dir, unsigned long n)
{
struct address_space *mapping = dir->i_mapping;
- struct page *page = read_cache_page(mapping, n,
- (filler_t*)mapping->a_ops->readpage, NULL);
+ struct page *page = read_mapping_page(mapping, n, NULL);
if (!IS_ERR(page)) {
wait_on_page_locked(page);
kmap(page);
diff --git a/fs/freevxfs/vxfs_subr.c b/fs/freevxfs/vxfs_subr.c
index 50aae77..c1be118 100644
--- a/fs/freevxfs/vxfs_subr.c
+++ b/fs/freevxfs/vxfs_subr.c
@@ -71,8 +71,7 @@ vxfs_get_page(struct address_space *mapp
{
struct page * pp;
- pp = read_cache_page(mapping, n,
- (filler_t*)mapping->a_ops->readpage, NULL);
+ pp = read_mapping_page(mapping, n, NULL);
if (!IS_ERR(pp)) {
wait_on_page_locked(pp);
diff --git a/fs/hfs/bnode.c b/fs/hfs/bnode.c
index 1e44dcf..13231dd 100644
--- a/fs/hfs/bnode.c
+++ b/fs/hfs/bnode.c
@@ -280,7 +280,7 @@ static struct hfs_bnode *__hfs_bnode_cre
block = off >> PAGE_CACHE_SHIFT;
node->page_offset = off & ~PAGE_CACHE_MASK;
for (i = 0; i < tree->pages_per_bnode; i++) {
- page = read_cache_page(mapping, block++, (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, block++, NULL);
if (IS_ERR(page))
goto fail;
if (PageError(page)) {
diff --git a/fs/hfs/btree.c b/fs/hfs/btree.c
index d20131c..4003579 100644
--- a/fs/hfs/btree.c
+++ b/fs/hfs/btree.c
@@ -59,7 +59,7 @@ struct hfs_btree *hfs_btree_open(struct
unlock_new_inode(tree->inode);
mapping = tree->inode->i_mapping;
- page = read_cache_page(mapping, 0, (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, 0, NULL);
if (IS_ERR(page))
goto free_tree;
diff --git a/fs/hfsplus/bitmap.c b/fs/hfsplus/bitmap.c
index 9fb5163..d128a25 100644
--- a/fs/hfsplus/bitmap.c
+++ b/fs/hfsplus/bitmap.c
@@ -31,8 +31,7 @@ int hfsplus_block_allocate(struct super_
dprint(DBG_BITMAP, "block_allocate: %u,%u,%u\n", size, offset, len);
mutex_lock(&HFSPLUS_SB(sb).alloc_file->i_mutex);
mapping = HFSPLUS_SB(sb).alloc_file->i_mapping;
- page = read_cache_page(mapping, offset / PAGE_CACHE_BITS,
- (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, offset / PAGE_CACHE_BITS, NULL);
pptr = kmap(page);
curr = pptr + (offset & (PAGE_CACHE_BITS - 1)) / 32;
i = offset % 32;
@@ -72,8 +71,8 @@ int hfsplus_block_allocate(struct super_
offset += PAGE_CACHE_BITS;
if (offset >= size)
break;
- page = read_cache_page(mapping, offset / PAGE_CACHE_BITS,
- (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, offset / PAGE_CACHE_BITS,
+ NULL);
curr = pptr = kmap(page);
if ((size ^ offset) / PAGE_CACHE_BITS)
end = pptr + PAGE_CACHE_BITS / 32;
@@ -119,8 +118,8 @@ found:
set_page_dirty(page);
kunmap(page);
offset += PAGE_CACHE_BITS;
- page = read_cache_page(mapping, offset / PAGE_CACHE_BITS,
- (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, offset / PAGE_CACHE_BITS,
+ NULL);
pptr = kmap(page);
curr = pptr;
end = pptr + PAGE_CACHE_BITS / 32;
@@ -167,7 +166,7 @@ int hfsplus_block_free(struct super_bloc
mutex_lock(&HFSPLUS_SB(sb).alloc_file->i_mutex);
mapping = HFSPLUS_SB(sb).alloc_file->i_mapping;
pnr = offset / PAGE_CACHE_BITS;
- page = read_cache_page(mapping, pnr, (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, pnr, NULL);
pptr = kmap(page);
curr = pptr + (offset & (PAGE_CACHE_BITS - 1)) / 32;
end = pptr + PAGE_CACHE_BITS / 32;
@@ -199,7 +198,7 @@ int hfsplus_block_free(struct super_bloc
break;
set_page_dirty(page);
kunmap(page);
- page = read_cache_page(mapping, ++pnr, (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, ++pnr, NULL);
pptr = kmap(page);
curr = pptr;
end = pptr + PAGE_CACHE_BITS / 32;
diff --git a/fs/hfsplus/bnode.c b/fs/hfsplus/bnode.c
index 746abc9..77bf434 100644
--- a/fs/hfsplus/bnode.c
+++ b/fs/hfsplus/bnode.c
@@ -440,7 +440,7 @@ static struct hfs_bnode *__hfs_bnode_cre
block = off >> PAGE_CACHE_SHIFT;
node->page_offset = off & ~PAGE_CACHE_MASK;
for (i = 0; i < tree->pages_per_bnode; block++, i++) {
- page = read_cache_page(mapping, block, (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, block, NULL);
if (IS_ERR(page))
goto fail;
if (PageError(page)) {
diff --git a/fs/hfsplus/btree.c b/fs/hfsplus/btree.c
index effa899..cfc852f 100644
--- a/fs/hfsplus/btree.c
+++ b/fs/hfsplus/btree.c
@@ -38,7 +38,7 @@ struct hfs_btree *hfs_btree_open(struct
goto free_tree;
mapping = tree->inode->i_mapping;
- page = read_cache_page(mapping, 0, (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, 0, NULL);
if (IS_ERR(page))
goto free_tree;
diff --git a/fs/jfs/jfs_metapage.c b/fs/jfs/jfs_metapage.c
index f28696f..e5cc762 100644
--- a/fs/jfs/jfs_metapage.c
+++ b/fs/jfs/jfs_metapage.c
@@ -642,10 +642,9 @@ struct metapage *__get_metapage(struct i
}
SetPageUptodate(page);
} else {
- page = read_cache_page(mapping, page_index,
- (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, page_index, NULL);
if (IS_ERR(page) || !PageUptodate(page)) {
- jfs_err("read_cache_page failed!");
+ jfs_err("read_mapping_page failed!");
return NULL;
}
lock_page(page);
diff --git a/fs/minix/dir.c b/fs/minix/dir.c
index 69224d1..2b0a389 100644
--- a/fs/minix/dir.c
+++ b/fs/minix/dir.c
@@ -60,8 +60,7 @@ static int dir_commit_chunk(struct page
static struct page * dir_get_page(struct inode *dir, unsigned long n)
{
struct address_space *mapping = dir->i_mapping;
- struct page *page = read_cache_page(mapping, n,
- (filler_t*)mapping->a_ops->readpage, NULL);
+ struct page *page = read_mapping_page(mapping, n, NULL);
if (!IS_ERR(page)) {
wait_on_page_locked(page);
kmap(page);
diff --git a/fs/namei.c b/fs/namei.c
index 96723ae..71f48fa 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2576,8 +2576,7 @@ static char *page_getlink(struct dentry
{
struct page * page;
struct address_space *mapping = dentry->d_inode->i_mapping;
- page = read_cache_page(mapping, 0, (filler_t *)mapping->a_ops->readpage,
- NULL);
+ page = read_mapping_page(mapping, 0, NULL);
if (IS_ERR(page))
goto sync_fail;
wait_on_page_locked(page);
diff --git a/fs/ntfs/aops.h b/fs/ntfs/aops.h
index 3b74e66..325ce26 100644
--- a/fs/ntfs/aops.h
+++ b/fs/ntfs/aops.h
@@ -86,8 +86,7 @@ static inline void ntfs_unmap_page(struc
static inline struct page *ntfs_map_page(struct address_space *mapping,
unsigned long index)
{
- struct page *page = read_cache_page(mapping, index,
- (filler_t*)mapping->a_ops->readpage, NULL);
+ struct page *page = read_mapping_page(mapping, index, NULL);
if (!IS_ERR(page)) {
wait_on_page_locked(page);
diff --git a/fs/ntfs/attrib.c b/fs/ntfs/attrib.c
index 1663f5c..6708e1d 100644
--- a/fs/ntfs/attrib.c
+++ b/fs/ntfs/attrib.c
@@ -2529,8 +2529,7 @@ int ntfs_attr_set(ntfs_inode *ni, const
end >>= PAGE_CACHE_SHIFT;
/* If there is a first partial page, need to do it the slow way. */
if (start_ofs) {
- page = read_cache_page(mapping, idx,
- (filler_t*)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, idx, NULL);
if (IS_ERR(page)) {
ntfs_error(vol->sb, "Failed to read first partial "
"page (sync error, index 0x%lx).", idx);
@@ -2600,8 +2599,7 @@ int ntfs_attr_set(ntfs_inode *ni, const
}
/* If there is a last partial page, need to do it the slow way. */
if (end_ofs) {
- page = read_cache_page(mapping, idx,
- (filler_t*)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, idx, NULL);
if (IS_ERR(page)) {
ntfs_error(vol->sb, "Failed to read last partial page "
"(sync error, index 0x%lx).", idx);
diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c
index c63a83e..05a2d83 100644
--- a/fs/ntfs/file.c
+++ b/fs/ntfs/file.c
@@ -231,8 +231,7 @@ do_non_resident_extend:
* Read the page. If the page is not present, this will zero
* the uninitialized regions for us.
*/
- page = read_cache_page(mapping, index,
- (filler_t*)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, index, NULL);
if (IS_ERR(page)) {
err = PTR_ERR(page);
goto init_err_out;
diff --git a/fs/ocfs2/symlink.c b/fs/ocfs2/symlink.c
index f6986bd..0c8a129 100644
--- a/fs/ocfs2/symlink.c
+++ b/fs/ocfs2/symlink.c
@@ -64,8 +64,7 @@ static char *ocfs2_page_getlink(struct d
{
struct page * page;
struct address_space *mapping = dentry->d_inode->i_mapping;
- page = read_cache_page(mapping, 0,
- (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, 0, NULL);
if (IS_ERR(page))
goto sync_fail;
wait_on_page_locked(page);
diff --git a/fs/partitions/check.c b/fs/partitions/check.c
index af0cb4b..31b923c 100644
--- a/fs/partitions/check.c
+++ b/fs/partitions/check.c
@@ -469,8 +469,8 @@ unsigned char *read_dev_sector(struct bl
struct address_space *mapping = bdev->bd_inode->i_mapping;
struct page *page;
- page = read_cache_page(mapping, (pgoff_t)(n >> (PAGE_CACHE_SHIFT-9)),
- (filler_t *)mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, (pgoff_t)(n >> (PAGE_CACHE_SHIFT-9)),
+ NULL);
if (!IS_ERR(page)) {
wait_on_page_locked(page);
if (!PageUptodate(page))
diff --git a/fs/reiserfs/xattr.c b/fs/reiserfs/xattr.c
index ffb79c4..39fedaa 100644
--- a/fs/reiserfs/xattr.c
+++ b/fs/reiserfs/xattr.c
@@ -452,8 +452,7 @@ static struct page *reiserfs_get_page(st
/* We can deadlock if we try to free dentries,
and an unlink/rmdir has just occured - GFP_NOFS avoids this */
mapping_set_gfp_mask(mapping, GFP_NOFS);
- page = read_cache_page(mapping, n,
- (filler_t *) mapping->a_ops->readpage, NULL);
+ page = read_mapping_page(mapping, n, NULL);
if (!IS_ERR(page)) {
wait_on_page_locked(page);
kmap(page);
diff --git a/fs/sysv/dir.c b/fs/sysv/dir.c
index d707434..f2bef96 100644
--- a/fs/sysv/dir.c
+++ b/fs/sysv/dir.c
@@ -53,8 +53,7 @@ static int dir_commit_chunk(struct page
static struct page * dir_get_page(struct inode *dir, unsigned long n)
{
struct address_space *mapping = dir->i_mapping;
- struct page *page = read_cache_page(mapping, n,
- (filler_t*)mapping->a_ops->readpage, NULL);
+ struct page *page = read_mapping_page(mapping, n, NULL);
if (!IS_ERR(page)) {
wait_on_page_locked(page);
kmap(page);
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 9539efd..7815154 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -97,6 +97,13 @@ extern struct page * read_cache_page(str
extern int read_cache_pages(struct address_space *mapping,
struct list_head *pages, filler_t *filler, void *data);
+static inline struct page *read_mapping_page(struct address_space *mapping,
+ unsigned long index, void *data)
+{
+ filler_t *filler = (filler_t *) mapping->a_ops->readpage;
+ return read_cache_page(mapping, index, filler, data);
+}
+
int add_to_page_cache(struct page *page, struct address_space *mapping,
unsigned long index, gfp_t gfp_mask);
int add_to_page_cache_lru(struct page *page, struct address_space *mapping,
diff --git a/mm/swapfile.c b/mm/swapfile.c
index e5fd538..b01b827 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1504,8 +1504,7 @@ asmlinkage long sys_swapon(const char __
error = -EINVAL;
goto bad_swap;
}
- page = read_cache_page(mapping, 0,
- (filler_t *)mapping->a_ops->readpage, swap_file);
+ page = read_mapping_page(mapping, 0, swap_file);
if (IS_ERR(page)) {
error = PTR_ERR(page);
goto bad_swap;
--
1.2.4
^ permalink raw reply related
* Re: How to create independent branches
From: Peter Baumann @ 2006-04-09 8:22 UTC (permalink / raw)
To: git
In-Reply-To: <20060409081105.GA4798@xp.machine.de>
On Sun, Apr 09, 2006 at 10:11:05AM +0200, Peter Baumann wrote:
> On Sat, Apr 08, 2006 at 08:28:58PM +0200, Jakub Narebski wrote:
> > Peter Baumann wrote:
> >
> > > Another question. I'd like to create a totaly independent branch (like
> > > the "todo" branch in git). Is there a more user friendly way than doing
> > >
> > > git-checkout -b todo
> > > rm .git/refs/heads/todo
> > > rm .git/index
> > > rm <all_files_in_your_workdir>
> > >
> > > ... hack hack hack ...
> > > git-commit -a
> >
> > Wouldn't it be better and more natural to go back to first commit? >
>
> If I go back to the first commit, I'll get the following:
>
> first
> / \
> / \
> master todo
>
> That's not what I want, because in the near future I want to merge
> master and todo, but in my case, todo consists of only of one file (lets
> call it file_a), and the master branch has severeal files (file_{a..z}).
> If I go back to first, I have to delete all files file_{b..z}.
> Further file_a from todo and file_a from master are not equal, the share
> just the same name. But in the near future, they will be merged
> together, so they are equal.
>
> If I go with the above branching, I'll _think_ (I may be wrong, please
> correct me if I am) I get a merge conflict or worse, all my other files
> file_a{b..z} are merged as "deleted", wich is wrong.
>
> > Or even empty repository state at the beginning, and branch there?
>
> This isn't possible because the repository already exists and I don't
> know how to go back to the empty repository state. Even
>
> git-init-db
> git branch todo master
>
> didn't work.
>
> > Or make separate repository?
>
> Ok. You got it. In fact, the todo branch alread exists as a seperate
> repository and I'd like to integrate this in my master repository for
> easier handling (diff etc.)
>
> To import todo as a subproject doesn't seem right, because it's not
> something really independent in the view of the master repo and I'am
> going to merge todo _into_ master in the near future.
>
> Any further suggestions?
>
Just in case nobody noticed, that's why I asked for exporting the whole repo
with git-format-patch in the first place, because I'd like to import the
patches with git-am in the totally independent branch.
Peter
^ permalink raw reply
* Profiling support in testing?
From: David Carr @ 2006-04-09 8:32 UTC (permalink / raw)
To: xen-devel
I've been working with the xenoprof patches from
http://xenoprof.sourceforge.net/ but I've recently seen references to
profiling support in the testing tree. What is the status of the
internal Xen profiling code and which one should I be using?
Thanks,
David Carr
^ permalink raw reply
* [Qemu-devel] [resend] i386 emulation on PowerPC host
From: Lyonel Vincent @ 2006-04-09 8:49 UTC (permalink / raw)
To: qemu-devel
Hi all,
Having noticed very wierd behaviour of some operations under an x86
Qemu guest running on a PowerPC (32 bits), I have compiled the
following test program under Linux/i386:
#include <stdio.h>
#include <math.h>
void main()
{
float x = exp(1)*exp(1);
float y = exp(2);
printf("%f = %f\n", x, y);
}
When run under native i386 Linux, this program displays:
$ ./mathtest
7.389056 = 7.389056
as expected
but with a CVS snapshot (as of 2006-03-23) of Qemu, one gets:
$ ./mathtest
7.389056 = -inf
[that's the same binary running under Linux/i386 inside Qemu on a
PowerPC host]
I also have other strange symptoms like cp sometimes complaining about
memory exhaustion but I haven't been able to reproduce those yet...
Does anybody have an idea of what the problem could be and how I could
help to fix that?
cheers,
Lyonel.
^ permalink raw reply
* [Xenomai-help] Re: Problems using Xenoscope
From: Bernhard Walle @ 2006-04-09 9:00 UTC (permalink / raw)
To: xenomai
In-Reply-To: <443826D4.9070507@domain.hid>
Hello,
Philippe Gerum <rpm@xenomai.org> [2006-04-08]:
> Bernhard Walle wrote:
> > Hello,
> >
> > I have problems using Xenoscope (Xenomai 2.1.0, Xenosim 2.1). The
> > simulation works, i.e. text messages are printed on the console. I use
> > the example from
> > http://www.mail-archive.com/xenomai@xenomai.org.
> >
> > The problem is that the traces dialog is empty, there are also no items
> > in the tree, only
> >
> > - System
> > -RT/Interfaces
> >
>
> It's not a bug, it's just that the tracer and some other interface
> objects are still missing.
Just wondering at
http://www.linux-automation.de/konferenz/papers/Jan_Kiszka_UNI-HANNOVER_RTAI/RTAI-fusion.pdf
I can see more functionality? Is this because this is RTAI Fusion 0.9
and I'm trying Xenomai 2.1?
Regards,
Bernhard
^ 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.