* Re: [Qemu-devel] VNC terminal server?
From: Mark Williamson @ 2006-04-08 18:38 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082003380.7783@wbgn013.biozentrum.uni-wuerzburg.de>
> On Sat, 8 Apr 2006, Samuel Hunt wrote:
> > It occurs to me that this program would make an excellent basis for a VNC
> > terminal server.
>
> Yeah, something like that has been done already:
> http://libvncserver.sourceforge.net/qemu/qemu-rfb13.patch.gz
>
> There is a notable update since rfb12 (which is a bit out of date
> _cough_): Nis Jorgensen has sent a patch to support scroll mice.
>
> IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse
> support is rather flakey: You have to disable mouse acceleration of the
> guest OS.
>
> I had that cunning plan to write a virtual Wacom tablet, but I just don't
> find the time.
The Xen copy of pckbd.c includes a patch to emulate a Summagraphics tablet, in
order to fix this problem. This is probably reusable for QEmu itself.
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Leonardo E. Reiter @ 2006-04-08 18:37 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082003380.7783@wbgn013.biozentrum.uni-wuerzburg.de>
Hi Dscho,
this virtual Wacom tablet you refer to... is there a [free or built-in]
Windows 2000/XP driver associated with it that supports either no
acceleration and/or absolute positioning? If so, perhaps I can look at
implementing it in QEMU in my "spare" time ;) Do you have a link to
documentation and/or drivers? If the guest OS can't be easily told to
not do any acceleration and/or use absolute cursor positioning rather
than relative moves, it's not that helpful to have a new type of input
device. I suspect a tablet driver can be easily configured this way
since design people who probably use these devices want perfect
precision between pointer and screen - otherwise they'd probably just
use a mouse/trackball. But you can never be sure how Microsoft (or
Wacom) decided to implement the Windows version of the driver.
The mouse sync solution we have in Win4Lin Pro is okay, but it's a bit
slow and I'd like to do something much cleaner. Of course if I do the
wacom tablet implementation, it will be open source and part of QEMU itself.
Thanks!
- Leo Reiter
Johannes Schindelin wrote:
> I had that cunning plan to write a virtual Wacom tablet, but I just don't
> find the time.
>
> 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
^ permalink raw reply
* [Xenomai-help] Problems using Xenoscope
From: Bernhard Walle @ 2006-04-08 18:29 UTC (permalink / raw)
To: xenomai
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
Debugging with GDB seems to work. I used 6.4 and 5.3. I use Debian
GNU/Linux 3.1 with gcc 3.x.
Regards,
Bernhard
--
Wenn schnell schwimmen besser ist als schnell denken, hätten wir auch
Fische bleiben können.
-- Albert Wendt
^ permalink raw reply
* Re: How to create independent branches
From: Jakub Narebski @ 2006-04-08 18:28 UTC (permalink / raw)
To: git
In-Reply-To: <20060408180244.GA4807@xp.machine.de>
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, or even
empty repository state at the beginning, and branch there? Or make separate
repository?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Page Migration: Make do_swap_page redo the fault
From: Christoph Lameter @ 2006-04-08 18:25 UTC (permalink / raw)
To: Hugh Dickins; +Cc: akpm, linux-mm
In-Reply-To: <Pine.LNX.4.64.0604081312200.14441@blonde.wat.veritas.com>
On Sat, 8 Apr 2006, Hugh Dickins wrote:
> > do_swap_page may interpret an invalid swap entry without this patch
> > because we do not reload the pte if we are looping back. The page
> > migration code may already have reused the swap entry referenced by our
> > local swp_entry.
>
> Wouldn't you better just remove that !PageSwapCache "Page migration has
> occured" block? Isn't that case already dealt with by the old !pte_same
> check below it?
Right. Since we now replace the swap ptes with ptes pointing to pages
before unlocking the page this is no longer necessary (if the ptes
contents are checked later). That of course means that remove_from_swap()
must always succeed.
Hmmm..,. There are still two other checks for !PageSwapCache after
obtaining a page lock in shmem_getpage() and in try_to_unuse().
However, both are getting to the page via the swap maps. So we need to
keep those.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c 2006-04-02 21:55:26.000000000 -0700
+++ linux-2.6/mm/memory.c 2006-04-08 11:08:33.000000000 -0700
@@ -1903,12 +1903,6 @@ again:
mark_page_accessed(page);
lock_page(page);
- if (!PageSwapCache(page)) {
- /* Page migration has occured */
- unlock_page(page);
- page_cache_release(page);
- goto again;
- }
/*
* Back out if somebody else already faulted in this pte.
--
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: [Qemu-devel] VNC terminal server?
From: Johannes Schindelin @ 2006-04-08 18:24 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <BAY107-F16FFCE76C42327C842AE508ACE0@phx.gbl>
Hi,
On Sat, 8 Apr 2006, Samuel Hunt wrote:
> It occurs to me that this program would make an excellent basis for a VNC
> terminal server.
Yeah, something like that has been done already:
http://libvncserver.sourceforge.net/qemu/qemu-rfb13.patch.gz
There is a notable update since rfb12 (which is a bit out of date
_cough_): Nis Jorgensen has sent a patch to support scroll mice.
IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse
support is rather flakey: You have to disable mouse acceleration of the
guest OS.
I had that cunning plan to write a virtual Wacom tablet, but I just don't
find the time.
Ciao,
Dscho
^ permalink raw reply
* Debian Sarge Install??
From: Hal MacArgle @ 2006-04-08 18:13 UTC (permalink / raw)
To: linux-newbie
Debian Sarge; two single layer DVD set bought on eBay.. Packed well
with very nice printed labels and both mounted and read easily with
two separate machines and DVD devices; a HP DVD-300i and Plextor
PK-708A, both relatively new and not overworked..
Tried installing, twice, on a Cyrix III/600mHz CPU; 256mB SDRAM; 8gB
freshly partitioned HD and a c.2000 BIOS.. Both trys stalled on
DVD#1, so I used the distributions "Check the CDRoms Integrity"
program and both failed at different points in the run.. Thought;
must be bad burns???
Not wanting to complain if there is another reason I tried on another
machine: Duron 1.3gHz CPU; 512mB SDRAM; freshly partitioned 12gB on a
40gB HD, this one with the Plextor PK-708A device and c.2000 BIOS...
DVD#1 passed the Integrity run but #2 failed at around 90% of the
checksum run... So no install that machine either.. I got to thinking
that I didn't want to complain to the vendor if the problem was a
single file that I would never need anyway, but how to work around
this; if possible??
Could it be that all files must be perfect to install Debian Sarge??
The vendor charged only pennies above what the blanks cost so can I
really complain?? Are single layer DVD's that critical with data??
TIA...
--
Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Brad Campbell @ 2006-04-08 18:12 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <BAY107-F16FFCE76C42327C842AE508ACE0@phx.gbl>
Samuel Hunt wrote:
> It occurs to me that this program would make an excellent basis for a
> VNC terminal server.
>
>
> What I'm basically after is something that I can have several clients
> connect into one server, and the server does all the work and just
> outputs the screen and stuff over the network and recieves the input
> over the network.
>
> VNC does all the I/O that's needed, would it be possible to set Qemu up
> though so it works with VNC as the I/O and simply sits on something like
> Linux as a server, starting a new instance every time another client
> connects?
If you use the vnc patch you kinda get a large part of this already. Major issue is still mouse
synch, but to be honest if you turn of all acceleration in the guest it stays pretty well synced up
now as it is.
I use it all the time on my server to host a win2k session when I need to access windows only
stuff.. Coupled with kqemu it makes for a pretty quick combination.
I *suspect* this is sort of how win4lin terminal server works, though they use funky additions to
keep the mouse sync rock solid and other groovy bits to make life really easy to manage.
I've been meaning to try and get my hands on an eval version to try it out.. as <plug here> the
desktop version makes life dead easy for almost anyone to just install and go. (like it used to with
the old win9x version)
Currently I run gentoo, freebsd-6 and win2k sessions on my server.. they just sit there idle until I
connect to them with vnc.. works a treat.
(server is debian)
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
^ permalink raw reply
* How to create independent branches
From: Peter Baumann @ 2006-04-08 18:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vr749i48s.fsf@assigned-by-dhcp.cox.net>
On Fri, Apr 07, 2006 at 12:18:27PM -0700, Junio C Hamano wrote:
> Peter Baumann <peter.baumann@gmail.com> writes:
>
> > How can I get the inital commit as a patch?
>
> format-patch is designed to get a patch to send to upstream, and
> does not handle the root commit. In your two revisions
> repository, you could do something like this:
>
> $ git diff-tree -p --root master~1
>
> Or more in general:
>
> $ git rev-list master |
> git diff-tree --stdin --root --pretty=fuller -p
>
> BTW, I've been meaning to add --pretty=patch to give
> format-patch compatible output to diff-tree, but haven't got
> around to actually do it. Another thing I've been meaning to do
> is "git log --diff" which is more or less "git whatchanged".
>
Ok. That did it.
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
I looked all over the docs, but can't find anything obvious.
-Peter
^ permalink raw reply
* NATed packets only enter the default routing table
From: richard lucassen @ 2006-04-08 17:40 UTC (permalink / raw)
To: netfilter
(copy from lartc mailinglist)
I set up this config:
+------+
-+ ISP1 +--+
+------+ | +-------+
+--+ linux |
+------+ | +-------+
-+ ISP2 +--+
+------+
No problem. Standard setup with two ISP's. Both routed subnets. Default
gateway is ISP1. No magic here.
Now I put a server behind the Linux box. I want the server to be
reachable on an /extra/ IP in the routed subnet of ISP2.
+------+
-+ ISP1 +--+
+------+ | +-------+ +-----------------+
+--+ linux +--+ server 10.0.0.2 |
+------+ | +-------+ +-----------------+
-+ ISP2 +--+
+------+
router ISP2: 1.2.3.1/24
dev ISP2: eth1
Linux box eth1: 1.2.3.2/24
external ip ISP2 for server 10.0.0.2: 1.2.3.3
arp -s 1.2.3.3 aa:bb:cc:dd:ee:ff pub
ip route add 1.2.3.3 via 10.0.0.2
iptables -t nat -A PREROUTING -i eth1 -d 1.2.3.3 -j DNAT --to 10.0.0.2
When pinging 1.2.3.3, the packets get in through eth1 (ok), but the
replies are following the default routing table through eth0 (wrong)
Even a
ip rule add from 1.2.3.3 lookup table_eth1
doesn't change this behaviour. It is working ok when I add the address
1.2.3.3 directly to eth1 (without NAT):
ip a a 1.2.3.3 dev eth1
Why is this?
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
^ permalink raw reply
* Data about Apple iPod, Mac, Powerbook, iBook needed
From: Stefan Richter @ 2006-04-08 17:36 UTC (permalink / raw)
To: linux1394-user; +Cc: linux-kernel
Hi all,
a number of Apple iPods have buggy firmware which report a wrong disk
size when plugged in. This may lead to I/O errors, making the iPod
inaccessible under Linux. I have been told this happens especially if
the kernel is configured for EFI partition support.
The USB storage driver already contains a workaround for several iPod
models. We need to add the same to the FireWire storage driver (sbp2).
Alas we cannot use the same model IDs like usb-storage to detect whether
a disk is actually an iPod. In particular, sbp2 must be able to
distinguish between iPods and Apple Macs or Powerbooks or iBooks which
are attached to a Linux box in "target disk mode".
Therefore I need help from people who have a FireWire iPod and a Linux
box with FireWire port:
1. Please plug it in via FireWire and report the output of
$ cat /sys/bus/ieee1394/devices/000a27*-0/model_id
and of
$ dmesg | grep "hdwr sectors"
2. If it is an USB/FireWire combo iPod, please also plug it in
via USB and report the output of
$ dmesg | grep "hdwr sectors"
I would also like to know the model of iPod (i.e. generation of iPod)
and the version of the Linux kernel.
I also need help from people who have an Apple Mac or Powerbook or iBook
and a Linux box with FireWire port:
A. On the Linux box, unload the sbp2 driver:
# modprobe -r sbp2
Reload it with the following parameter:
# modprobe sbp2 force_inquiry_hack=1
Also make sure that ohci1394 is loaded. (Check with lsmod. Some
rare host adapters need pcilynx instead oh ohci1394.)
B. Reboot the Apple and hold the "t" key. This boots the Mac into
"target disk mode", i.e. lets it expose its built-in HDD as a
FireWire disk. The "t" key can be released when a big FireWire
symbol is shown on the screen.
C. Connect the Mac and the Linux box via FireWire. The sbp2 driver
should now log in into the Mac, which will be shown in the kernel
log as well as in /proc/scsi/scsi. Please report the output of
$ dmesg | grep firmware_revision
D. The Mac can be unplugged and normally rebooted after this.
Thanks in advance to everyone who takes the time to collect these data.
--
Stefan Richter
-=====-=-==- -=-- -=---
http://arcgraph.de/sr/
^ permalink raw reply
* Re: SuSE 10.0 and it's RPM 4.1.1??
From: Hal MacArgle @ 2006-04-08 17:36 UTC (permalink / raw)
To: Ray Olszewski; +Cc: linux-newbie
In-Reply-To: <4436D44F.8010700@comarre.com>
On 04-07, Ray Olszewski wrote:
> Hal -- I was hoping you'd get feedback from some RPM user who could
> answer your questions directly. As you may recall, I'm exclusively a
> Debian user these days. But I think I may be able to help with some of
> your confusion. And since I gather that Edgar's off-list reply didn't
> cover everything you were looking for, I'll give it a try below.
My original query has been answered by others are well as
this message.. Completely.. I have another one that deserves a
separate post but, meanwhile, will annotate this thread, clipping
much..
> >>>First off, I didn't know what V3 DSA meant,
>
> This is probably a digial signature of some sort,intended to prevent
> package spoofing. About a year ago, Debian added digital authentication
> to its package sites, and as a result, I routinely have to override it
> when installing or upgrading packages from unofficial Debian archives.
> Since you say you were trying to install a package that is not part of
> the offifial distro you were working with, you most likely ran into
> something similar that the RPMers are doing now.
The "crackers" have ruined the INet as I used to know it..
Firewalls and filters really don't work, perfectly.. My 50-100
unwanted messages a day are more easily given the big "D" from Mutt,
IMHO... Safer?? My ISP runs Spam Assassin and I hate to think how
many it might be without it... <grin>
> >>Not sure on this but I believe that SuSE uses a different package system
> >>which is not compatable with Red Hat's.
That seems to be the case unless for very simple code.. Which
and what dependencies seem to be the biggest problem..
> Quick history lesson: Pretty much all distros that are still around
> derive from one of three origins:
>
> 1. Slackware really has no modern descendents, but it is the oldest
> branch that's still active. I believe it still uses .tgz packages
> natively. In a sense, I suppose it (or its anscestors, SLS, Yggdrasil,
> and perhaps others I've forgotten) spawned everything else, but Red Hat
> and Debian diverged so fundamentally from Slackware et al. ... for
> example, abandoning its BSD-style init structure for a SysV structure
> .. that it's hard to see them as derived from Slackware, even beyond
> the difference in package managers.
I keep "coming back" to Slackware and it's a fact that
Patrick is conservative especially since he's battling a serious
illness.. His cause is much strengthened by the existence of
www.linuxpackages.net that contains many, many binary compiles of so
many programs for each Slackware version all in .tgz format... Maybe
when you're not "first" you try harder??
> That said, the fact that two distros use the same package manager does
> NOT mean their packages are interchangeable. All distros have their own
> quirks, in areas like distro-specific kernel patches, slight variation
> in "what goes where" conventions (like /bin vs /usr/bin), customized
> init scripts, vert distinctive installers, and probably more. Package
> naming is not standardized either, so a package from one distro might
> fail to find in a different distro a file it depends on because the
> package name for the file is different.
I now know what others have experienced..
> These days, all good distros cross support one another's package
> managers, either directly or using a "translator" application like
> alien. But resolving dependencies remains messy.
For sure and "alien" is a new one on me to tuck into my grey
cells.. With programs running into millions of lines of code; I think
it works pretty well, bottom line..
> Editors come and go, and I've never found one I like as much as
> VirtualDub, a freeware editor that is Windows only. There are several
> around though ... the term you want to search on is "non-linear editor".
> The Debian-Sid package archive currently lists a gstreamer plugin, kino,
> and pitivi. There are probably others not in Debian.
Since moving video is so complicated; trying each and every
one in turn has to be counter-productive.. I learn as I go... I
fetched Virtual Dub and the author very savvy but I don't want to run
any M$ stuff if I can help it..
> "Streaming" is a pretty open-ended term, so I'm not exactly sure what
> you want to achieve (getting video streams from the Internet? attaching
> a host to your TV set and having it play video stored on a server
> elsewhere on your LAN? multicasting a video stream across your LAN so
> several locations in your home show the same show? putting a DVD in one
> host and having it play back on another? something else?). Be more
> specific here and I'll be happy to give you whatever more advice I can
> (I've been using my Linux server as a TiVo-like backend for several
> years now, but I don't have any significant experience with files
> downloaded from streaming sites on the Internet).
My desires are relatively simple these days: Fetch an
analogue, or view a "movie" from a VHS or DVD player; creat a file
that can be viewed again at a later date; convert this file to a
suite of files that can, in turn, burn a DVD playable on a standard
ubiquitous stand alone DVD player.. Plus, do some simple edits to the
files somewhere, that escapes me at present. I've been able to do
this with much help from you and Chuck so am, now, trying to increase
the quality of the end product, and, in the process, learn more about
digital video.. I need no INet exposure except for downloading
occasional files, especially since we're really rural telco lines so
slow speed thruput is a norm.. I do have a machine in town that can
connect to an ADSL line but for downloads only; bringing the files
home via sneaker net..
> Usually, if you need to install a package from the upstream provider,
> rather than the distro itself, the provider will be fairly specific
> about what distro/version a particular .rpm (or .deb) is designed to
> work with. At least that's my experience with upstream .deb packages.
I've noticed this __trend__ these days but I can't get over
the fact that we used to suffer with dumb terminal/main frames and
celebrated when we were able to get our "work" into our own
building... Plus, IMHO, the longer we are connected the bigger the
cracker profile.. Just an opinion of course. <grin>
> If the upstream provider doesn't have a package that matches your
> distro, you typically have to install from source or from a .tgz (and
> fix any real dependency issues by hand). Again, not really a newbie task
> (yeah, I know you are no more a newbie than I am, Hal, but this *is* a
> beginners' list).
Ray, I've noticed that what I know this week is less than
what I knew last week.. With computers anyway... <BG> Another,
separate subject, post follows; I hope I haven't outlived any
welcomes..
--
Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1 (2.4.29)
.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* [Qemu-devel] qemu exec.c
From: Paul Brook @ 2006-04-08 17:36 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Paul Brook <pbrook@savannah.gnu.org> 06/04/08 17:36:21
Modified files:
. : exec.c
Log message:
Fix typo in previous patch.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/exec.c.diff?tr1=1.75&tr2=1.76&r1=text&r2=text
^ permalink raw reply
* Re: [LARTC] source routing does not work with extra ip addresses
From: richard lucassen @ 2006-04-08 17:33 UTC (permalink / raw)
To: lartc
In-Reply-To: <20060408123017.4a108613.mailinglists@lucassen.org>
On Sat, 8 Apr 2006 11:07:00 -0500
"Martin A. Brown" <martin-lartc@wonderfrog.net> wrote:
> : Now I put a server behind the Linux box. I want the server to be
> : reachable on an /extra/ IP in the routed subnet of ISP2.
>
> Does server have one or two IP addresses? Best solution? Use two
> IP addresses on server.
Hmmm, one for ISP1 and one for ISP2? That would be a nice idea to
workaround this problem :-)
> : When pinging 1.2.3.3, the packets get in through eth1 (ok), but the
> : replies are following the default route through eth0 (wrong)
>
> The problem is routing. Return packets from your server are handled
> in the main routing table. There isn't yet an RPDB entry directing
> traffic from 10.0.0.2 to use table_eth1. Your RPDB entry looks like
> this:
>
> : ip rule add from 1.2.3.3 lookup table_eth1
>
> Try changing this (or adding another rule):
>
> ip rule add from 10.0.0.2 lookup table_eth1
Nope. I already tried that, but no way.
> instead. Now, your server should have Internet access strictly on
> the link handled by ISP2.
No. The packets are returned through ISP1.
> If you would like to handle inbound traffic on both links, then add
> a secondary IP address to your server, and enter another DNAT rule
> which specifies another NAT mapping for the secondary IP.
That's a very nice idea, but packets keep on entering the wrong table
(default), I think it's a bug somewhere in the kernel.
It only works when the ip is direct on the external interface of the
Linuxbox, but as soon as 1 tcp port is translated, the return packets
for that translated port get into the wrong (default) table.
Even when using fw marks it doesn't work. I mark all packets coming
from the servers second ip address with '1' and a simple
ip ru a fwmark 1 table t_eth1
should do the job. But no way. Packets keep on getting out through ISP1
(t_eth0).
This is the real test:
10.0.2.1 is the server, 10.0.2.3 is its second ip.
10.0.2.1 = external 10.1.3.100
10.0.2.3 = external 192.168.201.3
# ip r s
192.168.201.3 via 10.0.2.3 dev eth2
10.1.3.100 via 10.0.2.1 dev eth2
10.0.2.0/24 dev eth2 proto kernel scope link src 10.0.2.2
192.168.201.0/24 dev eth1 proto kernel scope link src 192.168.201.2
10.1.3.0/24 dev eth0 proto kernel scope link src 10.1.3.101
default via 10.1.3.1 dev eth0
# ip ru s
0: from all lookup local
32762: from all fwmark 0x1 lookup t_eth1
32764: from 192.168.201.2 lookup t_eth1
32765: from 10.1.3.101 lookup t_eth0
32766: from all lookup main
32767: from all lookup default
# ip r s t t_eth0
10.0.2.0/24 dev eth2 scope link
10.1.3.0/24 dev eth0 scope link src 10.1.3.101
127.0.0.0/8 dev lo scope link
default via 10.1.3.1 dev eth0
# ip r s t t_eth1
10.0.2.0/24 dev eth2 scope link
192.168.201.0/24 dev eth1 scope link src 192.168.201.2
127.0.0.0/8 dev lo scope link
default via 192.168.201.1 dev eth1
Any hints are welcome...
btw: iproute2-ss06011, kernel 2.6.16.2, iptables 1.3.5
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: Matti Aarnio @ 2006-04-08 17:30 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: linux list
In-Reply-To: <44379AB8.6050808@superbug.co.uk>
On Sat, Apr 08, 2006 at 12:12:56PM +0100, James Courtier-Dutton wrote:
> Hi,
>
> I have had an idea for a black box flight recorder type feature for
> Linux. Before I try to implement it, I just wish to ask here if anyone
> has already tried it, and whether the idea works or not.
>
> Description for feature:
> Stamp the dmesg output on RAM somewhere, so that after a reset (reset
> button pressed, not power off), the RAM can be read and details of
> oopses etc. can be read.
The idea of dmesg buffer comes to Linux from SunOS 4.x series
on hardware, where system boot code explicitely left aside memory
space which was not _cleared_ during boot (it was parity-regenerated,
though). The command to display that ring-buffer content was (no
surprise there?) "dmesg".
I do wish so many things from PC hardware, but it has stayed so b***y
inferior to real computers forever. Lattest AMD CPUs have nice
features making them almost as good as IBM S/370 from early 1970es,
but still BIOSes are rather primitive things keeping things back.
( IOMMUs are things that have been invented since, and are definitely
a good thing. Otherwise it has been faster and more capacitious
processing and memory at cheaper system cost... )
Like others have noted, display card memory spaces have been used
for this kind of "survives over reset" uses -- I do also know some
embedded boot codes that created similar ring buffers for similar
reasons. They don't generally survive over power-cycling, of course.
> The main advantage of something like this would be for newer
> motherboards that are around now that don't have a serial port.
>
> If no one has tried this, I will spend some time testing.
>
> James
/Matti Aarnio
^ permalink raw reply
* Re: [PATCH rc1-mm] de_thread: fix deadlockable process addition
From: Oleg Nesterov @ 2006-04-08 21:23 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20060408211308.GA1845@oleg>
On 04/09, Oleg Nesterov wrote:
>
> proc_task_readdir:
>
> first_tid() returns old_leader
>
> next_tid() returns new_leader
>
> de_thread:
> old_leader->group_leader = new_leader;
>
>
> next_rid() returns old_leader again,
> because it is not thread_group_leader()
> anymore
I think something like this for next_tid() is sufficient:
- if (thread_group_leader(pos))
+ if (pos->pid == pos->tgid)
We can also do the same change in first_tgid().
Oleg.
^ permalink raw reply
* Re: [PATCH] xdiff/xdiffi.c: fix warnings about possibly uninitialized variables
From: Davide Libenzi @ 2006-04-08 17:18 UTC (permalink / raw)
To: Marco Roeland; +Cc: git
In-Reply-To: <20060408152720.GA11125@fiberbit.xs4all.nl>
On Sat, 8 Apr 2006, Marco Roeland wrote:
> Compiling this module gave the following warnings (some double dutch!):
>
> xdiff/xdiffi.c: In functie 'xdl_recs_cmp':
> xdiff/xdiffi.c:298: let op: 'spl.i1' may be used uninitialized in this function
> xdiff/xdiffi.c:298: let op: 'spl.i2' may be used uninitialized in this function
> xdiff/xdiffi.c:219: let op: 'fbest1' may be used uninitialized in this function
> xdiff/xdiffi.c:219: let op: 'bbest1' may be used uninitialized in this function
>
> A superficial tracking of their usage, without deeper knowledge about the
> algorithm, indeed confirms that there are code paths on which these
> variables will be used uninitialized. In practice these code paths might never
> be reached, but then these fixes will not change the algorithm. If these
> code paths are ever reached we now at least have a predictable outcome. And
> should the very small performance impact of these initializations be
> noticeable, then they should at least be replaced by comments why certain
> code paths will never be reached.
These paths are never reached because of the way data is prepared before
and passed to the function. Unfortunately the compiler cannot know this.
Using them as -1 or XDL_LINE_MAX won't help either, since those are out of
domain values. You can leave it there and the algo won't suffer, or you
can relax a little the warning level when building the file.
- Davide
^ permalink raw reply
* Re: kernel vs user power management
From: Holger Macht @ 2006-04-08 17:18 UTC (permalink / raw)
To: Brown, Len; +Cc: thoenig, linux-acpi, linux-laptop, Andi Kleen
In-Reply-To: <CFF307C98FEABE47A452B27C06B85BB622B194@hdsmsx411.amr.corp.intel.com>
On Sat 08. Apr - 02:42:12, Brown, Len wrote:
> Timo, Holger,
> Andi pointed me to your FOSDEM Linux Power Management presentation:
>
> http://en.opensuse.org/FOSDEM2006
>
> http://files.opensuse.org/opensuse/en/b/b5/One_step_opendesign.pdf
>
> And I'm glad to see you working on Linux Power Management.
>
> But I'm a little concerned that user-space and the kernel are
> a little out of sync on a few things.
>
> I'm happy to see that the userspace p-state governor
> is no longer enabled by default on SuSE systems.
> While it was passable on servers with steady-state
> workloads, it was very bad for laptops where the
> machine spends a lot of time idle, but has short
> bursts of processing need which userspace could
> not detect. These laptops would spend virtually
> all their time in Pn when using the userspace governor.
To be honest, this observation suprises me a little bit. We did some
measurements with userspace agains ondemand governor some time ago and did
not notice any big differences in the results between them. Well, these
tests are about 1 1/2 years ago, though, and there went some changes into
the kernel until now ;-)
Nevertheless, we adjust the sampling rate in any case and currently set it
to 333 milliseconds (that's configurable). We noticed if we use the
default ondemand setting, the ondemand governor increases the frequency
too often although there is not much to do which is also not helpful. But
333 milliseconds is maybe a bit too high, it's taken because of historical
reasons. This value _was_ the default interval of our main event loop. I
think I will lower it a bit.
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. So I stick to the
ondemand governor in any case in newer releases. And such lockups are
really hard to reproduce and to debug.
Another argument was that speedstep_ich was not yet ready for ondemand
which it is now IIRC.
>
> The next step is to delete the userspace governor
> as a valid governor selection entirely. If somebody
> really wants manual control, they can still set the
> limits within which "ondemand" will stay.
In current code, I always try to use the ondemand governor at first and if
that fails we automatically switch to the userspace implementation at
runtime. This way has the advantage that we always get a working cpu
frequency scaling support.. But it also has one big disadvantage, we do
not get reports about not working ondemand governor so maybe we simply did
not notice the improvements in this area. For our stable releases, I will
keep the current inplementation. For the unstable one, I will disable the
autoswitching code and if it still works good then for a few month, I will
remove the userspace implementation completely. It should not hurt to let
the code in for some time and remove the visible configuration option,
just to have fallback under strange circumstances. Would this be ok with
you?
> I'm happy to see that clock throttling is not enabled by
> default in recent SuSE release, at least on my laptop
> which supports P-states.
>
> I'd like to see no option to enable clock-throttling on
> systems that support real p-states.
Yes, this is reasonable, indeen. Will do that. With p-states in this
context, you mean cpufreq here?
>
> It is useful only for workloads which have an infinite
> amount of non-idle computing which you don't care how
> slow it computes. For the vast majority of workloads
> it just slows down the machine and delays the processor
> from getting into idle where it can save a non-linear
> amount of power. Further, there exist today systems which
> will consume MORE power in deep C-states when throttled
> vs. when not throttled.
>
> The other major topic is the user/kernel interface
> for power management policy. there needs to be in-kernel
> state for this, else the device drivers will have no low-latency
> way to get the answer to the simple policy question of how they should
> optimize for performance vs power at any given instant when they
> recognize their device is idle.. this state should be controlled
> by user space, but I think it is most practical for it to
> be kernel resident.
I'm not sure if I completely understand what you mean here. Do you mean
the so called "runtime device power management"?
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.
>
> thanks,
> -Len
Regards,
Holger
^ permalink raw reply
* Re: [patch] represent-dirty__centisecs-as-jiffies-internally.patch comment fix
From: Bart Samwel @ 2006-04-08 17:16 UTC (permalink / raw)
To: Coywolf Qi Hunt; +Cc: linux-kernel, Andrew Morton
In-Reply-To: <2cd57c900604080310l454eec24m7298e01001f132af@mail.gmail.com>
Coywolf Qi Hunt wrote:
> 2006/3/25, akpm@osdl.org <akpm@osdl.org>:
>
>> From: Bart Samwel <bart@samwel.tk>
>>
>> Make that the internal values for:
>>
>> /proc/sys/vm/dirty_writeback_centisecs
>> /proc/sys/vm/dirty_expire_centisecs
>>
>> are stored as jiffies instead of centiseconds. Let the sysctl interface do
>> the conversions with full precision using clock_t_to_jiffies, instead of
>> doing overflow-sensitive on-the-fly conversions every time the values are
>> used.
>
>> diff -puN mm/page-writeback.c~represent-dirty__centisecs-as-jiffies-internally mm/page-writeback.c
>> --- devel/mm/page-writeback.c~represent-dirty__centisecs-as-jiffies-internally 2006-03-24 03:00:41.000000000 -0800
>> +++ devel-akpm/mm/page-writeback.c 2006-03-24 03:00:41.000000000 -0800
>> @@ -75,12 +75,12 @@ int vm_dirty_ratio = 40;
>> * The interval between `kupdate'-style writebacks, in centiseconds
>> * (hundredths of a second)
>
> Bart,
>
> You forgot to fix the comments. The attached patch fixes them.
Thanks, well spotted. I think the other patch already went into Linus'
tree, I guess this should go in there as well?
Cheers,
Bart
^ permalink raw reply
* Re: [PATCH rc1-mm] de_thread: fix deadlockable process addition
From: Oleg Nesterov @ 2006-04-08 21:13 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <m1r748jbju.fsf@ebiederm.dsl.xmission.com>
On 04/08, Eric W. Biederman wrote:
> Oleg Nesterov <oleg@tv-sign.ru> writes:
>
> > This change can confuse next_tid(), but this is minor.
> > I don't see other problems.
>
> next_tid?
proc_task_readdir:
first_tid() returns old_leader
next_tid() returns new_leader
de_thread:
old_leader->group_leader = new_leader;
next_rid() returns old_leader again,
because it is not thread_group_leader()
anymore
> This means your patch doesn't go far enough. We should be
> able to kill all of the parent list manipulation in
> de_thread. Doing reduces the places that assign
> real_parent to just fork and exit.
Yes!
I think I understand why we had the reason to reparent 'leader'
in the past. We used to set leader->exit_state = EXIT_ZOMBIE,
so without reparenting current's parent could have a bogus do_wait()
result if this do_wait() happens before release_task(leader).
Now we set leader->exit_state = EXIT_DEAD, which means this task
is not visible to do_wait().
Oleg.
^ permalink raw reply
* [Qemu-devel] qemu exec.c
From: Paul Brook @ 2006-04-08 17:14 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Paul Brook <pbrook@savannah.gnu.org> 06/04/08 17:14:56
Modified files:
. : exec.c
Log message:
Fix breakpoint TLB invalidation.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/exec.c.diff?tr1=1.74&tr2=1.75&r1=text&r2=text
^ permalink raw reply
* Re: 40% IDE performance regression going from FC3 to FC5 with same kernel
From: Alessandro Suardi @ 2006-04-08 17:07 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Linux Kernel
In-Reply-To: <1144514167.2989.10.camel@laptopd505.fenrus.org>
On 4/8/06, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 2006-04-08 at 18:27 +0200, Alessandro Suardi wrote:
> > On 4/8/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > >
> > > > Just for the record - no, even rebuilding same kernel with same GCC
> > > > (3.4.4) under FC5, disk performance is much slower than FC3 -
> > > > according to hdparm _and_ dd tests.
> > >
> > > what happens if you kill hald and other inotify using animals?
> >
> > Thanks Arjan for looking into this.
> >
> > Stopping hald brings hdparm from 18.5MB/s to 20MB/s, which is
> > indeed a noticeable improvement, though still far from the FC3
> > performance. I'm unsure what else can be stopped however
> > from this process list:
> >
> > 274 ? S<s 0:00 /sbin/udevd -d
>
>
> try killing that one next; it may or may not help but it's sure worth a
> try (esp given the success of the first kill :)
killing udevd doesn't bring any improvement - still at 20MB/s.
Do you want me to file a FC5 bugzilla entry with the current info
or do you think there is something else that can be discussed
on lkml ?
Thanks,
--alessandro
"Dreamer ? Each one of us is a dreamer. We just push it down deep because
we are repeatedly told that we are not allowed to dream in real life"
(Reinhold Ziegler)
^ permalink raw reply
* Annuncio
From: EsseGi @ 2006-04-08 17:03 UTC (permalink / raw)
Gentile utente,
ho letto il suo annuncio e con la presente le chiedo l'autorizzazione per presentarvi questa mia eccezionale attivitа di guadagno.
Si tratta di un metodo poco impegnativo e che nel tempo dа degli interessanti profitti.
Guadagni senza investire nulla
Questa volta non dovrete spendere neanche 1centesimo!!! Basta solo
usare questo link
http://www.monthlypayday.com//index.php?id=4336
e registrarsi con un nome utente e pass personale (con cui accederete al sito),
mettere il vostro indirizzo di account PayPal (l'e-mail con> cui siete
registrati su www.paypal.it (se non lo siete ancora registratevi,
и gratuito) attraverso cui ricevete i pagamenti!
Ora seguite questi passaggi molto semplici qui sotto:
1. Registratevi cliccando su queso link:
http://www.monthlypayday.com//index.php?id=4336
e cliccate su join free che si trova in alto a sinistra..
2. Inserite username e pass personali con cui accederete al vostro
account.
3. Copiate il vostro link personale nella sezione "Refferral info"
e cercatein qualsiasi modo (dipende dalle vostre abilitа) di far registrare
+ utenti possibili con il vostro link!
Descrizione dei pagamenti:
ogni membro che riuscite a far registrare vi farа guadagnare 20$!!!
IL BELLO DI QUESTO SISTEMA E? CHE NON PAGHERETE NULLA SIA PER L'ISCRIZIONE
E SIA SE NON RIUSCIRETE A FAR REGISTRARE NESSUNO! UN UNICA COSA AVVIENE
SOLO QUANDO AVRETE FATTO REGISTRARE I PRIMI 3 MEMBRI: DA QUI IN POI OGNI MESE
PUNTUALMENTE ANCHE SE NON FATE REGISTRARE + NESSUNO GUADAGNERETE SEMPRE 60$!
PERO' 1 VOLTA AL MESE IL SITO TRATTIENE SOLAMENTE 20$ DAL GUADAGNO
(non vitoglie nulla!!!), ANCHE SE I VOSTRI MEMBRI REGISTRATI SIANO 500!
Questa mail non и spam in quanto il suo indirizzo e-mail и presente in siti pubblicamente consultabili (legge 675/96)
Il Vs. indirizzo di posta elettronica non й stato in alcun modo conservato ne trattato.
Il presente messaggio non sarа ripetuto con ulteriori invii.
^ permalink raw reply
* Re: [PATCH] Fix mm regression bug: nommu use compound page in slab allocator
From: Pekka Enberg @ 2006-04-08 16:55 UTC (permalink / raw)
To: Luke Yang; +Cc: Nick Piggin, Andrew Morton, linux-kernel
In-Reply-To: <489ecd0c0603301811u3c8b6ac3lbe03a93a92bebf44@mail.gmail.com>
Hi Luke,
On 3/31/06, Luke Yang <luke.adi@gmail.com> wrote:
> The earlier patch to consolidate mmu and nommu page allocation
> and refcounting by using compound pages for nommu allocations
> had a bug: kmalloc slabs who's pages were initially allocated
> by a non-__GFP_COMP allocator could be passed into mm/nommu.c
> kmalloc allocations which really wanted __GFP_COMP underlying
> pages. Fix that by having nommu pass __GFP_COMP to all higher order
> slab allocations.
Any reason we are not doing this for CONFIG_MMU as well? We could then
fix the slab callers to not pass __GFP_COMP at all which seems broken
anyway.
Pekka
> Signed-off-by: Luke Yang <luke.adi@gmail.com>
> Acked-by: Nick Piggin <npiggin@suse.de>
>
> slab.c | 4 ++++
> 1 files changed, 4 insertions(+)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 4cbf8bb..388a6a9 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -1454,7 +1454,11 @@ static void *kmem_getpages(struct kmem_c
> int i;
>
> flags |= cachep->gfpflags;
> +#ifdef CONFIG_MMU
> page = alloc_pages_node(nodeid, flags, cachep->gfporder);
> +#else
> + page = alloc_pages_node(nodeid, (flags | __GFP_COMP), cachep->gfporder);
> +#endif
> if (!page)
> return NULL;
> addr = page_address(page);
^ permalink raw reply
* Re: [BUG] 2.6.16.2 (like olders) fails to suspend audio device
From: Patrizio Bassi @ 2006-04-08 16:53 UTC (permalink / raw)
To: Lee Revell; +Cc: Kernel,, alsa-devel
In-Reply-To: <1144513623.22490.150.camel@mindpipe>
Lee Revell ha scritto:
> It would help if you cc'ed the right list (added)
>
> On Sat, 2006-04-08 at 15:31 +0200, Patrizio Bassi wrote:
>
>> I've already posted same bug some weeks ago.
>>
>> this is just a reminder and to confirm bug is still there.
>>
>> 00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
>>
>> Alsa driver: 1370
>>
>> 1) if builtin in kernel, on resume it doesn't work any more.
>> 2) if built as module on resume it works with no need to remove/readd
>> module.
>>
>> in both situations dmesg shows:
>>
>> pnp: Failed to activate device 00:0b.
>>
>>
>> Stopping tasks: ===========================================|
>> Shrinking memory... done (39214 pages freed)
>> pnp: Device 00:0c disabled.
>> pnp: Device 00:08 disabled.
>> swsusp: Need to copy 13752 pages
>> ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 5 (level, low)
>> -> IRQ 5
>> ACPI: PCI Interrupt 0000:00:0a.1[B] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:0a.2[C] -> Link [LNKA] -> GSI 11 (level,
>> low) -> IRQ 11
>> usb usb1: root hub lost power or was reset
>> ehci_hcd 0000:00:0a.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
>> ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level,
>> low) -> IRQ 10
>> pnp: Device 00:08 activated.
>> pnp: Failed to activate device 00:0b.
>> pnp: Device 00:0c activated.
>> Restarting tasks... done
>> agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0.
>> agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode
>> agpgart: Putting AGP V2 device at 0000:01:00.0 into 2x mode
>>
>> lspci
>> 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
>> bridge (rev 03)
>> 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP
>> bridge (rev 03)
>> 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
>> 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
>> 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
>> 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
>> 00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
>> (rev 74)
>> 00:0a.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>> Controller (rev 50)
>> 00:0a.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>> Controller (rev 50)
>> 00:0a.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
>> 00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
>> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF/SG AGP
>>
>>
>> dmesg says 00:08 and 00:0c are activated..but i've no idea which devices
>> they are, lspci -vv shows nothing about that.
>>
>> Ready to give more infos and test patches.
>>
>> Patrizio Bassi
>>
>>
>
you're right, sorry, but, having the strange devices in dmesg let me
think that's a problem
in suspend too.
^ 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.