* Re: cross automount issue
From: Ian Kent @ 2006-04-09 4:19 UTC (permalink / raw)
To: Joe Pruett; +Cc: autofs
In-Reply-To: <Pine.LNX.4.64.0604070923300.15746@q7.q7.com>
On Fri, 7 Apr 2006, Joe Pruett wrote:
> after sending it, i started wondering what the lock was there for. i wasn't
> sure if each automount daemon was multi-threaded or not. what mount locking
> are you referring to?
The lock was introduced to prevent corruption of /etc/mtab because the
locking in mount for this purpose didn't work.
There are patches for mount which I believe fix it.
Ian
^ permalink raw reply
* Re: bind mount not working as expected
From: Ian Kent @ 2006-04-09 4:24 UTC (permalink / raw)
To: Anthony M. Martinez; +Cc: autofs, Timo Felbinger
In-Reply-To: <20060406152922.GD10241@nmt.edu>
On Thu, 6 Apr 2006, Anthony M. Martinez wrote:
> As suggested, I am forwarding this question to the autofs mailing list,
> since my problem doesn't seem to be Timo's patch.
>
> On Fri, Mar 24, 2006 at 06:05:31PM +0100, Timo Felbinger wrote:
> > On Thu, Mar 23, 2006 at 09:57:15AM -0700, Pi (aka Anthony Martinez) wrote:
> > > > >
> > > > Is it correct that this is a "program" map which is to telling
> > > > automount to mount /fs/administratium/accounts/p/pi as /u/pi,
> > > > and this information is taken from an ldap entry containing the
> > > > attributes
> > > > uid: pi
> > > > tccRawHomeDir: /fs/administratium/accounts/p/pi
^
Where's the hostname on this !
tccRawHomeDir: :/fs/administratium/accounts/p/pi
^
Sun map escape might be needed?
Ian
^ permalink raw reply
* Astounding Mortgages for the USA!
From: Elinor Arellano @ 2006-04-09 5:28 UTC (permalink / raw)
To: linux-scsi
Homeowner
You have been pre-approved for a $455,843 Home Loan at a 3.76 Fixed Rate.
This offer is being extended to you unconditionally and your credit is in no way a factor.
To take Advantage of this Limited Time opportunity
All we ask is that you visit our Website and complete
The 1 minute post Approval Form
http://www5.h0ok.com/was.asp
Best Wishes,
Hannah Mayfield
^ permalink raw reply
* Redirecting packets based on source+destination ip's
From: clan @ 2006-04-09 4:34 UTC (permalink / raw)
To: netfilter
I have been trying to find a way with iptables to redirect a packet
created on a server to be sent to 1.1.1.1 instead of 2.2.2.2 but only if
the packet is coming from 3.3.3.3.
With the help of linuxquestions.org I have gotten to the point of using
DNAT where the packet redirects, but the determining factor is destination
address. Not source. Since this is a shared server(each user has a
different ip) it would be nice to only redirect certain ip's, but leave
the others alone.
In case I didn't make it understandable what I want to do here is what I
am trying to accomplish, I rent a server for running a battlefield 2
server. This is of course shared, so there are other battlefield
instances running next to mine albeit on different ip's. I want to run a
stats program that requires redirecting bf2web.gamespy.com to
212.77.171.103 so that when my server sends out stats they go to ABR
instead of EA. The usual way of doing this is with a hosts file, but that
effects all ip's on the server, and causes some pretty big problems with
the other servers on the machine.
Here is what the guy at linuxquestions.org gave me to work with
iptables -t nat -A PREROUTING -t nat -p tcp -d 1.1.1.1 --dport 80 -j DNAT
--to 2.2.2.2
To make it work I had to change PREROUTING to OUTPUT. So is there a way
for that to only effect certain source ip's?
Thank you so much, Fourthbean
^ permalink raw reply
* Re: [Qemu-devel] Absolute USB-HID device musings (was Re: VNC Terminal Server)
From: Anthony Liguori @ 2006-04-09 4:36 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443825D8.3080602@win4lin.com>
I was looking through the Xorg evdev driver and it doesn't appear to
support absolute coordinate reporting. evdev is how the USB mouse would
show up to userspace. A little googling confirmed it for me:
http://lists.freedesktop.org/archives/xorg/2005-September/010140.html
USB wacom still seems the most promising to me but I fear getting it to
work under Windows will be a pain.
Regards,
Anthony Liguori
Leonardo E. Reiter wrote:
> This is by no means a complete patch (do not apply it as it will break
> usb-hid.c), but it adjusts the report descriptor in usb-hid.c to
> provide position in 16-bits, and in absolute coordinates:
>
> Index: usb-hid.c
> ===================================================================
> RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v
> retrieving revision 1.1
> diff -a -u -r1.1 usb-hid.c
> --- usb-hid.c 5 Nov 2005 16:57:08 -0000 1.1
> +++ usb-hid.c 8 Apr 2006 20:56:02 -0000
> @@ -117,7 +117,7 @@
> 0x15, 0x00, 0x25, 0x01, 0x95, 0x03, 0x75, 0x01,
> 0x81, 0x02, 0x95, 0x01, 0x75, 0x05, 0x81, 0x01,
> 0x05, 0x01, 0x09, 0x30, 0x09, 0x31, 0x15, 0x81,
> - 0x25, 0x7F, 0x75, 0x08, 0x95, 0x02, 0x81, 0x06,
> + 0x25, 0x7F, 0x75, 0x16, 0x95, 0x02, 0x81, 0x02,
> 0xC0, 0xC0,
> };
>
> According to:
> http://72.14.203.104/search?q=cache:wVYUTwc33f8J:www.usb.org/developers/devclass_docs/HID1_11.pdf+usb+hid+specification+absolute+relative&hl=en&gl=us&ct=clnk&cd=1
>
>
> I'm still trying to figure out how the logical min/max apply if we are
> to report absolute (unsigned) positions in 16-bits. Obviously 8-bits
> is not enough for absolute coordinates. You could theoretically use
> only 12-bits per coordinate but that would make life difficult I
> think, and probably unnecessarily frugal in a software emulation.
>
> It's not clear to me [yet] how the scroll wheel comes into play, and
> whether or not it (the dz coordinate) can be kept relative for ease of
> implementation. Also the code would need to be changed to report
> coordinates in 16-bits rather than 8, and of course made to report
> absolute coordinates (like from sdl.c, etc.) Still it looks fairly
> easy to implement - the USB spec is pretty simple.
>
> So to reiterate, my patch does virtually nothing - in fact it will
> break usb-hid.c so please don't use it. I was just illustrating how
> to get it to report the device as providing 16-bit absolute
> coordinates instead of 8-bit relative ones. If anyone wants to chime
> in with more info, I'd be glad to make this a discussion. *If* using
> the USB HID device only, not any real USB devices, can be done without
> slowing down QEMU, then I think this is a great way to get a tablet
> emulated without having to deal with drivers on either side. Plus, in
> the long run, it probably means other neat stuff like being able to
> get away from ISA bus emulation, and also it's portable to other
> targets (for example, OS-X on PPC would talk to the USB HID device the
> same way theoretically), so it's likely the most portable and cleanest
> option.
>
> Regards,
>
> Leo Reiter
>
> Brad Campbell wrote:
>> Apparently USB HID supports absolute input devices natively. Given we
>> have a HID mouse driver of sorts in qemu I wonder if that is another
>> avenue perhaps ?
>>
>>
>
^ permalink raw reply
* Re: Overhead of Using a Stackable File System(Wrapfs)
From: UZAIR LAKHANI @ 2006-04-09 4:56 UTC (permalink / raw)
To: Avishay Traeger; +Cc: linux-fsdevel
In-Reply-To: <1144501472.13374.8.camel@ool-44c32f98.dyn.optonline.net>
--- Avishay Traeger <atraeger@cs.sunysb.edu> wrote:
> On Fri, 2006-04-07 at 23:48 -0700, UZAIR LAKHANI
> wrote:
> > Thanks for replying but consider this scenario.
> >
> > What Wrapfs code do is this
> >
> > user_request ---> vfs_request ---> wrapfs_request
> --->
> > actual_fs_request ---> storage
> >
> > Now consider this scenario in a network
> environment
> >
> > (client machine)
> > user_request ---> vfs_request ---> wrapfs_request
> --->
> >
> > Network ---> (server machine)actual_fs_request
> --->
> > storage
> >
> > The network here gets client requests and send
> them to
> > server and vice versa.
>
> The main benefit of stackable file systems is that
> you do not need to
> duplicate the functionality found in lower-level
> file systems. In your
> scenario, you do not use the lower-level file system
> at all, so you will
> need to implement all the functionality of a
> lower-level file system,
> plus deal with all the stackable file system code
> (which you will use
> but won't need). Using wrapfs in this case will
> give you no benefit,
> and will just make your life more difficult, and
> your code slower and
> more difficult to read. I recommend you just start
> from scratch.
>
Thanks again for replying. I am getting your point
that we don't have any lower filesystem on the client
side but can we not assume that we have a lower file
sytem on client side but that actually resides across
the network on server side. All then we have to do is
to pass the requsts for the lower file system on
client side to the lower file system on server side
using some communication mechanism.
Waiting for comments.
Thanks,
Uzair
> Avishay Traeger
> http://www.fsl.cs.sunysb.edu/~avishay/
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
From: Al Boldi @ 2006-04-09 5:04 UTC (permalink / raw)
To: Peter Williams; +Cc: linux-kernel
In-Reply-To: <44387855.30004@bigpond.net.au>
Peter Williams wrote:
> Al Boldi wrote:
> > This is especially visible in spa_no_frills, and spa_ws recovers from
> > this lockup somewhat and starts exhibiting this problem as a choking
> > behavior.
> >
> > Running '# top d.1 (then shift T)' on another vt shows this choking
> > behavior as the proc gets boosted.
>
> But anyway, based on the evidence, I think the problem is caused by the
> fact that the eatm tasks are running to completion in less than one time
> slice without sleeping and this means that they never have their
> priorities reassessed.
Yes.
> The reason that spa_ebs doesn't demonstrate the
> problem is that it uses a smaller time slice for the first time slice
> that a task gets. The reason that it does this is that it gives newly
> forked processes a fairly high priority and if they're left to run for a
> full 120 msecs at that high priority they can hose the system. Having a
> shorter first time slice gives the scheduler a chance to reassess the
> task's priority before it does much damage.
But how does this explain spa_no_frills setting promotion to max not having
this problem?
> The reason that the other schedulers don't have this strategy is that I
> didn't think that it was necessary. Obviously I was wrong and should
> extend it to the other schedulers. It's doubtful whether this will help
> a great deal with spa_no_frills as it is pure round robin and doesn't
> reassess priorities except when nice changes of the task changes
> policies.
Would it hurt to add it to spa_no_frills and let the children inherit it?
> This is one good reason not to use spa_no_frills on
> production systems.
spa_ebs is great, but rather bursty. Even setting max_ia_bonus=0 doesn't fix
that. Is there a way to smooth it like spa_no_frills?
> Perhaps you should consider creating a child
> scheduler on top of it that meets your needs?
Perhaps.
> Anyway, an alternative (and safer) way to reduce the effects of this
> problem (while your waiting for me to do the above change) is to reduce
> the size of the time slice. The only bad effects of doing this is that
> you'll do slightly worse (less than 1%) on kernbench.
Actually, setting timeslice to 5,50,100 gives me better performance on
kernbench. After closer inspection, I found 120ms a rather awkward
timeslice whereas 5,50, and 100 exhibited a smoother and faster response,
which may be machine dependent, thus the need for an autotuner.
Thanks!
--
Al
^ permalink raw reply
* Re: Accessing physical memory
From: dwh @ 2006-04-09 4:20 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200604082352.55490.antonio.dibacco@aruba.it>
Quoting Antonio Di Bacco <antonio.dibacco@aruba.it>:
> How can I access the physical memory? Can I MMAP for example /dev/mem? Is
> there a simpler way?
>
Hi Antonio,
What would you like to do? If you just want some arbitrary
page of memory, then look at the 'nopage' example in Rubini,
or ask me and I'll send you some code.
If you want a specific memory location, then you'll need
to claim and ioremap the memory, and again, I can give you
some code.
So, explain a little more and I can help.
Dave
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* [lm-sensors] hwmon/pc87360 as a platform driver
From: Juerg Haefliger @ 2006-04-09 5:24 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4436BE3B.7090306@gmail.com>
> The SHOW_SET_*_* constants are just a bit off-putting at first read,
> but I know what you mean, and I dont have a better idea.
> maybe SHOW_SETTNG_*_* ?
> or SHOW_CURR_*_*, thats confuse-able with the current reading
Well SHOW_SET_xxx_yyy is supposed to hint that the constant is used in
both the show_xxx and set_xxx callbacks. It's the best I could come up
with although I have to admit I didn't spend too much time thinking
about this....
>
> you can improve your printks :
>
> s/(printk\(KERN_DEBUG)/dev_dbg\(&pdev->dev/;
> s/(printk\(KERN_ERR)/dev_err\(&pdev->dev/
> s/(printk\(KERN_INFO)/dev_info\(&pdev->dev/
>
> at least where pdev has already been initd
Hmm... I thought I used printks only in places where pdev is not initialized.
>
> Ill try to read thru the enire patch this weekend sometime.
I certainly appreciate the review :-)
...juerg
^ permalink raw reply
* 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
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.