* Re: [stable] Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Greg KH @ 2006-04-05 18:52 UTC (permalink / raw)
To: Jon Smirl; +Cc: Sergey Vlasov, gregkh, linux-kernel, stable
In-Reply-To: <9e4733910604050830x2daf2ec1vd1fe16073b51de8c@mail.gmail.com>
On Wed, Apr 05, 2006 at 11:30:54AM -0400, Jon Smirl wrote:
>
> The one attribute per file model doesn't work well when the attributes
> need to be changed in a transaction. For example you want to change
> your display to 1024x768 16bit color. As you set the attributes one
> at a time the display has to change since there is not guarantee that
> you will complete the sequence. The framebuffer sysfs interface breaks
> the one attribute per file rule and uses strings for grouped
> attributes.
I suggest you use configfs instead for this. It allows this kind of
"grouped attributes".
good luck,
greg k-h
^ permalink raw reply
* Re: [Lhms-devel] [RFC 0/6] Swapless Page Migration V1: Overview
From: Lee Schermerhorn @ 2006-04-05 18:52 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-mm, lhms-devel, Hirokazu Takahashi, Marcelo Tosatti,
KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0604051032130.1768@schroedinger.engr.sgi.com>
On Wed, 2006-04-05 at 10:43 -0700, Christoph Lameter wrote:
> On Wed, 5 Apr 2006, Lee Schermerhorn wrote:
>
> > > We never allow a faulting in of the new page before migration is
> > > complete. The replacing of the swap ptes with real ptes was always done
> > > after migration was complete. Same thing here.
> >
> > Unless we're talking about different things [happens], my migrate-on-
> > fault patches do this. Pages are unmapped from ptes and left hanging in
> > the cache until some task touches them. Then the migration occurs, if
>
> Well you can only umap file backed pages. These are still working the same
> way. Anonymous pages can only be remapped in a different way not unmapped.
> "unmap" of anonymous pages in todays kernels really means remap to swap
> space.
My point exactly. And to get them to migrate on fault [which I want to
do], I need to unmap them and leave them that way until some task
touches them.
>
>
> If you put the anonymous pages on swap then you can still have the old
> behavior but then you would require swap space.
Or a migration cache that behaves like swap, but doesn't actually
reserve disk space.
Note: my traces show that the current [2.6.17-rc1] migration mechanism
only uses one swap entry at a time, per running instance of migration.
So, I don't think there is a hurry to eliminate this usage for "direct
migration". If we accept migrate on fault, then pages can lay around in
the swap cache for some time. That would motivate us to investigate a
solution that doesn't reserve swap.
> > In any case, I don't think we want to be walking reverse maps and other
> > task's pte's in one task's page fault path. Perhaps "migrate-on-fault"
> > and "auto-migration" are not going to go anywhere, but if they do, we'll
> > need something like the existing swap/migration cache behavior, where
> > the temporary ptes reference a single [reference counted] cache entry
> > that points at either the old or new page.
>
> No we certainly do not want to walk reverse maps in critical sections of
> the code.
>
> I think the opportunistic lazy migration that we were talking about before
> would be fine with this scheme. You just check the refcount during the
> fault and then migrate the page if this would establish the first
> mapcount.
The pages must exist in a cache with mapcount==0 at fault time [swap or
migration cache for anon pages] for this to work, right?
>
> Pushing pages into the migration cache from the scheduler in order to
> migrate them later when references are to be reestablished will no longer
> work.
:-(, I know...
>
> Would not swap be a more appropriate mechanism there? I mean the
> functionality that you want is almost exactly the same as swap. The
> checking of the mapcounts can then work the same way as opportunistic lazy
> migration.
Yes. We've discussed this before. Swap works just fine for this. My
current migrate-on-fault and auto-migration series does not change this.
The issue that we still need to work out [assuming these patches go
forward] is whether it's perferable to let such pages hang around in the
swap cache tying up swap device space that they never intend to use, or
to implement a pseudo-swap device like the migration cache to hold the
pte entries of unmapped anon pages. I put the migration cache work on
hold to work up the aforementioned patch series. I could do this,
because it works with swap. If you remove the use of swap in
try_to_unmap(), etc., my patches would either have to put it back or
ressurect the migration cache sooner than planned. As it stands,
migrate-on-fault is a relatively small change to the in-kernel migration
mechanism.
Lee
--
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: How should I handle binary file with GIT
From: Randal L. Schwartz @ 2006-04-05 18:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslor27n4.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> If we wanted to use the patch+diff (i.e. "format-patch,
Junio> send-email, and then am" workflow) to transfer new version of
Junio> binary files to a recipient, which I think is useful in some
Junio> projects, the sanest way to handle this is probably to add
Junio> Nico's delta, going from preimage to postimage, encoded for
Junio> safer transport, to our diff output.
This is what I was looking for, and thanks for confirming that at least within
a local respository, everything already works. Yeay.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [ANNOUNCE] udev 089 release
From: Kay Sievers @ 2006-04-05 18:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060403171123.GA24860@vrfy.org>
On Wed, Apr 05, 2006 at 12:25:34AM +0100, Scott James Remnant wrote:
> On Mon, 2006-04-03 at 19:11 +0200, Kay Sievers wrote:
>
> > Provide "udevtrigger" program to request events on coldplug. The
> > shell script is much too slow with thousends of devices.
> >
> How does this differ from our "udevplug" ? :)
It simply triggers events for all devices. And the logic to wait for
the queue to become empty is in a different tool.
> Would it be worth consolidating both into the same tool?
If you can convince me why we would want to filter out events on the
event generation side instead of doing that on the event handling side.
I'm not sure about the idea of controlling the module load order or the
other weird things that way, but you may may have good reasons I don't
see at the moment.
Kay
-------------------------------------------------------
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\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: FILE_FLAG_WRITE_THROUGH
From: Glynn Clements @ 2006-04-05 18:47 UTC (permalink / raw)
To: Steve Graegert; +Cc: linux-c-programming
In-Reply-To: <6a00c8d50604050036p127a1348hee9c6fa7ea67bed@mail.gmail.com>
Steve Graegert wrote:
> > > The O_DIRECT flag suggested by Steve is probably overkill. It requires
> > > that the buffer start address, buffer size and file offset are all
> > > multiples of the filesystem's block size, and only works on some
> > > filesystems.
> >
> > Although it works for a single file, how good is fsync() in this case?
>
> fsync(2) does not ensure that all data has actually been written to
> disk. The controller may indicate that all data is stable, but it
> does so even if it is still in its internal cache. From this point of
> view, fsync(2) is not a replacement for O_DIRECT.
If the drive doesn't accurately indicate whether data has been written
to the physical medium, that will affect everything, including
O_DIRECT. There have been cases of drives which indicate that data has
been written even when it's still in the cache, in order to improve
benchmark scores.
I don't believe that there's any difference between O_SYNC, O_DIRECT
or fsync() in terms of their interpretation of "written to the
hardware"; they all send a "flush" command to the drive and block
until the drive reports completion.
The advantage of O_DIRECT is that it won't displace existing blocks
from the kernel's buffer cache, which might be useful if you're
writing a lot of data and won't be reading it back in any time soon.
According to:
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B99794
that is more than what FILE_FLAG_WRITE_THROUGH does:
The FILE_FLAG_WRITE_THROUGH flag for CreateFile() causes any
writes made to that handle to be written directly to the file
without being buffered. The data is cached (stored in the disk
cache); however, it is still written directly to the file.
This method allows a read operation on that data to satisfy
the read request from cached data (if it's still there),
rather than having to do a file read to get the data. The
write call doesn't return until the data is written to the
file. This applies to remote writes as well--the network
redirector passes the FILE_FLAG_WRITE_THROUGH flag to the
server so that the server knows not to satisfy the write
request until the data is written to the file.
O_DIRECT appears closer to FILE_FLAG_NO_BUFFERING:
The FILE_FLAG_NO_BUFFERING takes this concept one step further
and eliminates all read-ahead file buffering and disk caching
as well, so that all reads are guaranteed to come from the
file and not from any system buffer or disk cache. When using
FILE_FLAG_NO_BUFFERING, disk reads and writes must be done on
sector boundaries, and buffer addresses must be aligned on
disk sector boundaries in memory.
IOW, FILE_FLAG_WRITE_THROUGH corresponds to O_SYNC while
FILE_FLAG_NO_BUFFERING corresponds to O_DIRECT.
--
Glynn Clements <glynn@gclements.plus.com>
^ permalink raw reply
* Re: [stable] Re: [PATCH] isd200: limit to BLK_DEV_IDE
From: Greg KH @ 2006-04-05 18:45 UTC (permalink / raw)
To: Beber
Cc: Bertrand Jacquin, gregkh, Randy.Dunlap, linux-kernel, torvalds,
stable
In-Reply-To: <4615f4910604050635v5af3dbc6w17849adb2fd64593@mail.gmail.com>
On Wed, Apr 05, 2006 at 03:35:38PM +0200, Beber wrote:
> On 3/31/06, Bertrand Jacquin <beber@gna.org> wrote:
> > Le Thu, 30 Mar 2006 14:35:26 -0800 (PST), "Randy.Dunlap" <rdunlap@xenotime.net> m'a avou?:
> >
> > > On Thu, 30 Mar 2006, Beber wrote:
> > >
> > > > On 3/28/06, Greg KH <gregkh@suse.de> wrote:
> > > > > We (the -stable team) are announcing the release of the 2.6.16.1 kernel.
> > > >
> > > > I still get this error :
> > > >
> > > > # make
> > > ...
> > > > drivers/built-in.o: In function `isd200_Initialization':
> > > > : undefined reference to `ide_fix_driveid'
> > > > make: *** [.tmp_vmlinux1] Error 1
> > >
> > > Was this reported earlier?
> >
> > Yes, it was, but ignored, so I repost it ;)
> >
> > > Please test the patch below.
> > > It works for me with your config and various others.
> >
> > It work here too.
> > Thanks
>
> I look on last GIT history and didn't find this applyed upstream. Will it be ?
No one has forwarded it to the stable group, so it's a bit hard to apply
it to the tree if that doesn't happen :)
thanks,
greg k-h
^ permalink raw reply
* Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
From: Dmitry Torokhov @ 2006-04-05 18:44 UTC (permalink / raw)
To: Rene Herman; +Cc: Greg KH, alsa-devel, linux-kernel, tiwai, Andrew Morton
In-Reply-To: <44340E12.9000202@keyaccess.nl>
On 4/5/06, Rene Herman <rene.herman@keyaccess.nl> wrote:
> Dmitry Torokhov wrote:
>
> >> Well, we could in fact hang an unregister off device->private_data as
> >> per attached example. Wouldn't be _excessively_ ugly. Still sucks
> >> though.
> >
> > Plus it broke all the drivers that create platform devices before
> > registering drivers or the ones simply not using private data.
>
> No, this was just a suggestion for an ALSA specific workaround. I was
> suggesting ALSA drivers could do this.
>
Yes, I am sorry - I misread the code snipped as if it was in driver
core, not in ALSA itself.
--
Dmitry
^ permalink raw reply
* Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
From: Dmitry Torokhov @ 2006-04-05 18:44 UTC (permalink / raw)
To: Rene Herman; +Cc: Greg KH, alsa-devel, linux-kernel, tiwai, Andrew Morton
In-Reply-To: <44340E12.9000202@keyaccess.nl>
On 4/5/06, Rene Herman <rene.herman@keyaccess.nl> wrote:
> Dmitry Torokhov wrote:
>
> >> Well, we could in fact hang an unregister off device->private_data as
> >> per attached example. Wouldn't be _excessively_ ugly. Still sucks
> >> though.
> >
> > Plus it broke all the drivers that create platform devices before
> > registering drivers or the ones simply not using private data.
>
> No, this was just a suggestion for an ALSA specific workaround. I was
> suggesting ALSA drivers could do this.
>
Yes, I am sorry - I misread the code snipped as if it was in driver
core, not in ALSA itself.
--
Dmitry
-------------------------------------------------------
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\x110944&bid$1720&dat\x121642
^ permalink raw reply
* Re: 2.6.17-rc1 perfmon2 new code base + libpfm available
From: William Cohen @ 2006-04-05 18:39 UTC (permalink / raw)
To: eranian; +Cc: perfmon, linux-ia64, linux-kernel, oprofile-list, perfctr-devel
In-Reply-To: <20060405154319.GD6232@frankl.hpl.hp.com>
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Stephane Eranian wrote:
> The new version of the library, libpfm, includes the following changes:
>
> - updated to match 2.6.17-rc1 new system call numbers
>
> - modified pfmlib.h to use 64-bit integer for generic PMC register
> (submitted by Kevin Corry from IBM)
Hi Stephane,
There isn't an perfmon_x86_64.h file anymore. Shouldn't the Makefile
eliminate that? The stock "make install" fails because that file doesn't
exist. I think the attached patch fixes this problem.
-Will
[-- Attachment #2: x86_64_merge.diff --]
[-- Type: text/x-patch, Size: 336 bytes --]
--- libpfm-3.2-060405/include/Makefile.orig 2006-04-05 14:09:32.000000000 -0400
+++ libpfm-3.2-060405/include/Makefile 2006-04-05 14:35:09.000000000 -0400
@@ -40,7 +40,6 @@
ifeq ($(CONFIG_PFMLIB_ARCH_X86_64),y)
HEADERS += perfmon/pfmlib_os_x86_64.h \
- perfmon/perfmon_x86_64.h \
perfmon/pfmlib_comp_x86_64.h
endif
^ permalink raw reply
* [lm-sensors] [Fwd: Sensor readings from Gigabyte I915P Duo
From: Przemysław Kulik @ 2006-04-05 18:40 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <1144101011.28472.17.camel@localhost>
Dnia 05-04-2006, ?ro o godzinie 09:39 +0200, Rudolf Marek napisa?(a):
> 2) We can do the bios disassembly to see what is on BIOS screen. Unfortunately
> this can take some time and I dont have one. You can check my homepage
> http://assembler.cz (BIos hacking) if you have some assembly skills.
Unfortunately I do not
> 3) Unload the it87, get acpi working, modprobe thermal, can you see the
> temperature with the command acpi -V
> If so I will need the cat /proc/apci/dsdt > dsdt.bin (put it somewhere online
> or send me in private please, mailing list is dropping binary attachs)
Nothing here...
1) Here's my config:
[*] ACPI Support
<M> AC Adapter
< > Battery
< > Button
<M> Video
< > Generic Hotkey (EXPERIMENTAL)
<M> Fan
<M> Processor
<M> Thermal Zone
< > ASUS/Medion Laptop Extras
< > IBM ThinkPad Laptop Extras
< > Toshiba Laptop Extras
(0) Disable ACPI for systems before Jan 1st this year
[ ] Debug Statements
[ ] Power Management Timer Support
< > ACPI0004,PNP0A05 and PNP0A06 Container Driver (EXPERIMENTAL)
2) before modprobing
# lsmod
Module Size Used by
hwmon_vid 3200 0
snd_pcm_oss 48800 0
snd_mixer_oss 17792 25 snd_pcm_oss
snd_seq_oss 34688 0
snd_seq_midi_event 6912 1 snd_seq_oss
snd_seq 51856 4 snd_seq_oss,snd_seq_midi_event
snd_seq_device 8076 2 snd_seq_oss,snd_seq
spca5xx 690832 0
8250_pnp 9344 0
8250 23412 1 8250_pnp
serial_core 19200 1 8250
snd_hda_intel 15120 26
snd_hda_codec 87808 1 snd_hda_intel
snd_pcm 81540 3 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd_timer 22404 2 snd_seq,snd_pcm
snd 49508 13
snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,snd_seq_device,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer
snd_page_alloc 9352 2 snd_hda_intel,snd_pcm
nvidia 3462748 22
# acpi -V
No support for device type: battery
No support for device type: thermal
No support for device type: ac_adapter
3) modprobing
# modprobe thermal
4) after modprobing
# lsmod
Module Size Used by
thermal 11656 0
processor 16244 1 thermal
hwmon_vid 3200 0
snd_pcm_oss 48800 0
snd_mixer_oss 17792 25 snd_pcm_oss
snd_seq_oss 34688 0
snd_seq_midi_event 6912 1 snd_seq_oss
snd_seq 51856 4 snd_seq_oss,snd_seq_midi_event
snd_seq_device 8076 2 snd_seq_oss,snd_seq
spca5xx 690832 0
8250_pnp 9344 0
8250 23412 1 8250_pnp
serial_core 19200 1 8250
snd_hda_intel 15120 26
snd_hda_codec 87808 1 snd_hda_intel
snd_pcm 81540 3 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd_timer 22404 2 snd_seq,snd_pcm
snd 49508 13
snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,snd_seq_device,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer
snd_page_alloc 9352 2 snd_hda_intel,snd_pcm
nvidia 3462748 22
# acpi -V
No support for device type: battery
No support for device type: thermal
No support for device type: ac_adapter
Sorry for rhis, but I'm a n00b when it comes to hardware sensors.
Przemek
^ permalink raw reply
* Re: 2.6.17-rc1 perfmon2 new code base + libpfm available
From: William Cohen @ 2006-04-05 18:39 UTC (permalink / raw)
To: eranian; +Cc: perfmon, linux-ia64, linux-kernel, oprofile-list, perfctr-devel
In-Reply-To: <20060405154319.GD6232@frankl.hpl.hp.com>
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Stephane Eranian wrote:
> The new version of the library, libpfm, includes the following changes:
>
> - updated to match 2.6.17-rc1 new system call numbers
>
> - modified pfmlib.h to use 64-bit integer for generic PMC register
> (submitted by Kevin Corry from IBM)
Hi Stephane,
There isn't an perfmon_x86_64.h file anymore. Shouldn't the Makefile
eliminate that? The stock "make install" fails because that file doesn't
exist. I think the attached patch fixes this problem.
-Will
[-- Attachment #2: x86_64_merge.diff --]
[-- Type: text/x-patch, Size: 336 bytes --]
--- libpfm-3.2-060405/include/Makefile.orig 2006-04-05 14:09:32.000000000 -0400
+++ libpfm-3.2-060405/include/Makefile 2006-04-05 14:35:09.000000000 -0400
@@ -40,7 +40,6 @@
ifeq ($(CONFIG_PFMLIB_ARCH_X86_64),y)
HEADERS += perfmon/pfmlib_os_x86_64.h \
- perfmon/perfmon_x86_64.h \
perfmon/pfmlib_comp_x86_64.h
endif
^ permalink raw reply
* [Xenomai-core] rt_task_delete(NULL) started crashing on SVN
From: Rodrigo Rosenfeld Rosas @ 2006-04-05 18:38 UTC (permalink / raw)
To: xenomai
Hi Philippe,
I'm not sure of the exact SVN revision the problem arised, but my program used
to work 2 weeks ago, I guess, that was the last time I have tested it...
Since some revision not before 2 weeks ago, rt_task_delete(NULL) was causing
my program to crash.
Please, could you see what is going on? Remember something that was changed in
rt_task_delete code or some path that could affect this call in this way?
Thanks in advance,
Rodrigo.
P.S: I tested on last SVN version today after a failure with the previous svn
version I had installed. Unfortunately, I do not remember which was the
previous revision, but I believe I've updated it yesterday. I think this
information will not help very much, so, if you cannot reproduce the bug, I
can try to write a minimal application where the bug appears.
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
^ permalink raw reply
* Re: [parisc-linux] IOGear Firewire+USB card causes unexpected irq 2
From: Chris Frost @ 2006-04-05 18:37 UTC (permalink / raw)
To: Helge Deller; +Cc: parisc-linux
In-Reply-To: <200604040805.33828.deller@gmx.de>
On Tue, Apr 04, 2006 at 08:05:33AM +0200, Helge Deller wrote:
> 01:0f.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00f2 (rev 01) (prog-if 10 [OHCI])
> says: Interrupt: pin A routed to IRQ 9
>
> Do you have CONFIG_EISA and/or CONFIG_ISA enabled ?
> If yes, try without...
Neither are enabled.
(But thanks for the suggestion.)
--
Chris Frost | <http://www.frostnet.net/chris/>
-------------+----------------------------------
Public PGP Key:
Email chris@frostnet.net with the subject "retrieve pgp key"
or visit <http://www.frostnet.net/chris/about/pgp_key.phtml>
^ permalink raw reply
* RE: RSS Limit implementation issue
From: Roger Heflin @ 2006-04-05 18:50 UTC (permalink / raw)
To: 'Bill Davidsen'; +Cc: 'linux mailing-list'
In-Reply-To: <4432C8E6.6010301@tmr.com>
> After thinking about this, I have the opinion that if an RSS
> limit is working it would be a hard limit. The alternative is
> a process which gets large and then when memory pressure
> increases the oversize process either causes a lot of
> swapping or worse yet ties up a lot of memory if swap rate is limited.
>
> There are many ways to tune Linux badly, adding one more will
> not add much to the pain if the default is off. The values
> available to a normal users might be limited to prevent the
> most obvious bad choices. Or a corresponding option could be
> provided to take corrective action for a process with RSS set
> (to any value) and swap rate high.
>
I think the mistake on VMS was that the defaults were horribly
low and where not changed when machines got more memory, there
may be some situations where an RSS limit is wanted, but
the kernel would need to be implementing it, the process has no
control over its RSS.
I can see even having a min RSS that a process won't get swapped
below being probably more useful, as certain interactive process
on either a server or a desktop might want to not be swapped out below
a certain level, even if other processes suffer. I would suspect
that I would set a min limit on certain applications that needed
decent response, and had got previously bad response to because
of swapping, though something in the kernel would need to deal
with a potential overcommitting of memory via this method, and
deal with the associated deadlock.
Roger
^ permalink raw reply
* Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
From: Rene Herman @ 2006-04-05 18:36 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Greg KH, alsa-devel, linux-kernel, tiwai, Andrew Morton
In-Reply-To: <200604042145.24685.dtor_core@ameritech.net>
Dmitry Torokhov wrote:
>> Well, we could in fact hang an unregister off device->private_data as
>> per attached example. Wouldn't be _excessively_ ugly. Still sucks
>> though.
>
> Plus it broke all the drivers that create platform devices before
> registering drivers or the ones simply not using private data.
No, this was just a suggestion for an ALSA specific workaround. I was
suggesting ALSA drivers could do this.
Rene.
^ permalink raw reply
* Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
From: Rene Herman @ 2006-04-05 18:36 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Greg KH, alsa-devel, linux-kernel, tiwai, Andrew Morton
In-Reply-To: <200604042145.24685.dtor_core@ameritech.net>
Dmitry Torokhov wrote:
>> Well, we could in fact hang an unregister off device->private_data as
>> per attached example. Wouldn't be _excessively_ ugly. Still sucks
>> though.
>
> Plus it broke all the drivers that create platform devices before
> registering drivers or the ones simply not using private data.
No, this was just a suggestion for an ALSA specific workaround. I was
suggesting ALSA drivers could do this.
Rene.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Junio C Hamano @ 2006-04-05 18:34 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86wte4rq3d.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> I think the issue is related to being able to cherry-pick and merge
> when binaries are involved. I've been worried about that myself.
> How well are binaries supported these days for all the operations
> we're taking for granted? When is a "diff" expected to be a real
> "diff" and not just "binary files differ"?
First of all, binary files are handled by cherry-pick and merge
without needing to involve "diff"+"patch" (which is not so
useful for binary files anyway). They use 3-way read-tree merge
which compares the object names and leave the index unmerged if
there are conflicting changes, so you should be able to sort it
out by running up to three "git-cat-file blob $sha1".
What involves "diff"+"patch" are rebases and processing mailed-in
patches as in the example by the original poster.
In our diff output, we record the blob object name of preimage
and postimage, along with filemode, on the "index" line.
git-apply does not do anything with it by default, but if:
- --binary flag is given,
- the postimage blob is already available locally, and,
- the file the patch is being applied to is the same as the
recorded preimage,
then the file is _replaced_ with the postimage.
This is good enough for git-rebase (which uses format-patch
piped to am) and is safe (we do not "apply delta" -- only
replace when the file "being patched" matches the recorded
preimage). It does not do any good for transferring a postimage
that the person who applies the patch does not yet have.
I think "applying delta" to a binary file is not very useful
thing to do. Depending on the nature of the file being patched,
it may produce a perfectly good result, but verifying if the
result makes sense by the end user and hand-fixing it if does
not, which can be done for text files, is near impossible for
binary files. "replace with postimage only when you are
applying to the same preimage" rule would be the only practical,
sane thing.
If we wanted to use the patch+diff (i.e. "format-patch,
send-email, and then am" workflow) to transfer new version of
binary files to a recipient, which I think is useful in some
projects, the sanest way to handle this is probably to add
Nico's delta, going from preimage to postimage, encoded for
safer transport, to our diff output. For safety and sanity, we
will not "apply" the patch unless the patched file exactly
matches the preimage that is recorded in the diff, and as long
as the recipient has the preimage, such a patch would be able to
reproduce the postimage and hopefully be smaller than
transferring the whole thing.
We've been trying to keep our diff output reversible (e.g. we
show what the filemode of the preimage is), so if we take the
above route, it probably should record deltas for both going
from preimage to postimage _and_ going the other way (unless
xdelta can be applied in-reverse, which I do not think is the
case).
Of course, to be _completely_ generic, you could include both
compressed then uuencoded preimage and postimage, and let the
recipient sort it out. An advantage of that approach is that
the applicability of such a "patch" improves as the tools to
apply it improve, after the patch was originally generated. I
however think that is only a theoretical advantage, not a very
practical one.
^ permalink raw reply
* [U-Boot-Users] [PATCH] objcopy for srec and bin files should be done on .o files
From: Wolfgang Denk @ 2006-04-05 18:33 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060405162645.GU27792@bork.org>
In message <20060405162645.GU27792@bork.org> you wrote:
>
> The Makefile rule for creating srec and bin files fails for me frequently.
Plewase explain what "fails for me means" (error message(s), used
toolchain and versions of the binutils, host environment etc.).
> I believe that we should be doing the ojbcopy on the .o files, not the ELF
> binary.
I disagree. I see no reason to change this yet. First I woul like to
at least understand which problem you are trying to fix.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I've seen it. It's rubbish." - Marvin the Paranoid Android
^ permalink raw reply
* Re: device model and character devices
From: Greg KH @ 2006-04-05 18:31 UTC (permalink / raw)
To: Artem B. Bityutskiy; +Cc: linux-kernel
In-Reply-To: <44337759.4040507@yandex.ru>
On Wed, Apr 05, 2006 at 11:52:57AM +0400, Artem B. Bityutskiy wrote:
> Greg KH wrote:
> >Because "struct device" generally is not related to a major:minor pair
> >at all. That is what a struct class_device is for. Lots of struct
> >device users have nothing to do with a char device, and some have
> >multiple char devices associated with a single struct device.
> Well, OK, but AFAIK, your long-term plan is to merge class_device and
> device, so in the long-term perspective it does not matter. And those
> who do not need a character device support may have a possibility to
> disable it.
Yes, that's my goal in the long term, and I have a patch availble that
starts to do that:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/device-class.patch
but we have a lot of work to get there.
And even then, a struct device will be separate from a char device. For
one example, the cdev structure is used by the kernel to look up the
device properly, which has nothing to do with struct device (or struct
class_device) at all at this time.
thanks,
greg k-h
^ permalink raw reply
* Re: BUG: soft lockup detected on CPU#0!
From: Christopher S. Aker @ 2006-04-05 18:32 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel
In-Reply-To: <19373d679e65ffe279bbb2bb4fd94700@cl.cam.ac.uk>
Keir Fraser wrote:
> Since it looks like a problem with the blkback kernel thread, it's worth
> doing:
> echo 1 >/sys/module/blkback/parameters/debug_lvl
>
> That may get some kernel tracing (at level KERN_DEBUG) from that thread
> and we can see if it's got into a bad looping state.
After an update and a reboot, and turning off soft lockup detection, I'm
still getting zombie domains. It also appears that after this happens,
no new block devices can be attached.
Here's a summary of the different debug outputs:
(after restarting Xend)
==> /var/log/xend.log <==
[2006-04-05 14:29:09 xend] DEBUG (XendDomain:197) Cannot recreate
information for dying domain 54. Xend will ignore this domain from now on.
[2006-04-05 14:29:09 xend] DEBUG (XendDomain:197) Cannot recreate
information for dying domain 73. Xend will ignore this domain from now on.
Apr 5 14:28:40 host56 kernel: xvd 73 fd:85: I/O pending, delaying exit
Apr 5 14:28:40 host56 kernel: xvd 73 fd:85: not connected (13 pending)
Apr 5 14:28:40 host56 kernel: xvd 73 fd:85: I/O pending, delaying exit
Apr 5 14:28:40 host56 kernel: xvd 73 fd:85: not connected (13 pending)
^-- these flood syslog
Apr 5 14:28:40 host56 kernel: ined (13 pe, delayed (13 pe, delayined
(13 , delayed (13 , delayied (13 , delayined (13 , delayed (13 pend,
delayed (13 , delayined (13 pe, delayined (13 pe, delayined (13 ,
delayed (13 pe, delayed (13 , delayined (13 , delayed (13 pendin,
delayined (13 p, delayined (13 pen, delayed (13 pe, delayined (13 ,
delayied (13 pe, delayed (13 , delayined (13 , delayed (13 pendin,
delayined (13 , delayined (13 pe, delayed (13 pe, delayined (13 ,
delayed (13 pe, delayed (13 , delayined (13 pe, delayined (13 pendin,
delayined (13 pe, delaying ed (13 pe, delayined (13 pe, delayined (13
pe, delayed (13 pe, delayed (13 , delayin, delayined (13 pending,
delayined (13 , delaying ed (13 pe, delayed (13 pe, delayined (13 ,
delayed (13 pe, delayed (13 , delayined (13 pe, delayed (13 pendin,
delayined (13 , delayined (13 pe, delayed (13 pe, delayined (13 ,
delayed (13 pe, delayed (13 , delayined (13 , delayied (13 pendin,
delayined (13 , delayined (13 pe, delayined (13 pe, delayed (13 pe,
delayed (13
Apr 5 14:28:40 host56 kernel: elayined (13 , delayed (13 pendin,
delayined (13 , delayined (13 pe, delayed (13 pe, delayined (13 pe,
delayed (13 pe, delayed (13 p, delayined (13 , delayed (13 pendin,
delayined (13 , delayined (13 pe, delayed (13 pe, delayined (13 ,
delayed (13 p, delayed (13 pe, delayined (13 pe, delayined (13 pend,
delayined (13 , delaying ed (13 peed (13 , delayined (13 , delayined (13
pe, delayed (13 pe, delayined (13 p, delayined (13 pend, delayined (13 ,
delayined (13 pe, delayined (13 pe, de, delayined (13 pe, delayed (13 ,
delayined (13 , delayed (13 pendin, delayined (13 , delayined (13 pen,
delayed (13 pe, delayined (13 , delayed (13 pe, delayed (13 , delayined
(13 , delayed (13 pendin, delayined (13 , delayined (13 pe, delayined
(13 pe, delayined (13 , delayed (13 pe, delayed (13 , delayined (13 ,
delayed (13 pendin, delayined (13 , delayined (13 pe, delayed (13 pe,
delayined (13 , delayined (13 pe, delayed (13 , delayined (13 p, delayed
(13 pend, delayed (13 , delayined (13 pe, dela
^-- these are flooding, but not quite as often.
This leaves Xen/Xend in an unstable condition, I'm thinking the only way
out is a reboot...
-Chris
^ permalink raw reply
* [LARTC] QoS - Ping problem
From: Nataniel Klug @ 2006-04-05 18:30 UTC (permalink / raw)
To: lartc
Hello all,
I have set my QoS solution and now I am facing a little problem...
When I ping to my server it has some lost packages:
Estatísticas do Ping para 172.30.0.1:
Pacotes: SENDED = 1029, RETURNED = 880, LOST = 149 (14% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 0ms, Máximo = 686ms, Média = 105ms
If I disable my QoS ping stats to be ok. I even have tryed to make a
filter for ICMP protocol (using u32 as it is writen into LARTC how-to)
but it did not work. How can I solve this problem?
------------------------------------------------------------------------
#!/bin/sh
#------
# Script de QoS Cyber Nett
#------
# Nataniel Klug
# suporte@cnett.com.br
#------
TC="/sbin/tc"
IPT="/usr/local/sbin/iptables"
$IPT -t mangle -X
$IPT -t mangle -F
DL="eth1"
#------
# Apagando regras antigas de QoS
#------
$TC qdisc del dev $DL root 2> /dev/null > /dev/null
$TC qdisc del dev $DL ingress 2> /dev/null > /dev/null
#------
# Regras para a placa eth1
#------
$TC qdisc add dev $DL root handle 1: htb default 50
CLASS="/sbin/tc class add dev $DL parent"
$CLASS 1: classid 1:1 htb rate 3072Kbit
$CLASS 1:1 classid 1:10 htb rate 1024Kbit ceil 1024Kbit
$CLASS 1:1 classid 1:20 htb rate 1536Kbit ceil 2560Kbit
$CLASS 1:1 classid 1:30 htb rate 512Kbit ceil 1024Kbit
$CLASS 1:1 classid 1:40 htb rate 512Kbit ceil 1024Kbit
$CLASS 1:1 classid 1:50 htb rate 512Kbit ceil 1024Kbit
QDISC="/sbin/tc qdisc add dev $DL parent"
$QDISC 1:10 handle 10: sfq perturb 10
$QDISC 1:20 handle 20: sfq perturb 10
$QDISC 1:30 handle 30: sfq perturb 10
$QDISC 1:40 handle 40: sfq perturb 10
$QDISC 1:50 handle 50: sfq perturb 10
FILTER="/sbin/tc filter add dev $DL parent 1:0 protocol ip prio 1 u32"
$FILTER match ip sport 22 0xffff flowid 1:10
$FILTER match ip sport 23 0xffff flowid 1:10
$FILTER match ip sport 2202 0xffff flowid 1:10
$FILTER match ip sport 80 0xffff flowid 1:20
$FILTER match ip sport 443 0xffff flowid 1:20
$FILTER match ip sport 3128 0xffff flowid 1:20
$FILTER match ip sport 53 0xffff flowid 1:30
$FILTER match ip sport 25 0xffff flowid 1:30
$FILTER match ip sport 110 0xffff flowid 1:30
$FILTER match ip sport 21 0xffff flowid 1:40
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [linux-lvm] pvmove to smaller PVs
From: Fredrik Tolf @ 2006-04-05 18:30 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <20060405180351.GY4197@agk.surrey.redhat.com>
On Wed, 2006-04-05 at 19:03 +0100, Alasdair G Kergon wrote:
> On Wed, Apr 05, 2006 at 07:58:19PM +0200, Fredrik Tolf wrote:
> > However, is there a "canonical" way to check where PEs have been
> > allocated inside PVs?
>
> lvs -o+devices
> gives start PEs in parentheses
Oh, cool. Thanks!
Fredrik Tolf
^ permalink raw reply
* Re: Dual Core on Linux questions
From: Bill Davidsen @ 2006-04-04 19:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Mattia Dongili, Alejandro Bonilla, linux-kernel
In-Reply-To: <442C4034.1060203@garzik.org>
Jeff Garzik wrote:
> Bill Davidsen wrote:
>> Jeff Garzik wrote:
>>> Pallipadi, Venkatesh wrote:
>>>>> From cpufreq perspective multiple things are possible in the way
>>>> processor will support the multi-core frequency changing. and most of
>>>> the things are handled at cpufreq inside kernel. I think there
>>>> should be
>>>> minima changes required in cpufreqd if any.
>>>> Options:
>>>
>>>
>>> 4) we power down a core.
>>>
>> Is this just for completeness of the set, something someone might do
>> someday, or does someone really have a hotplug core product?
>
> Not hotplug, just power it down.
>
Is that actually possible on any current hardware? I didn't see it in
any doc I have, but it's all "CPU specs for dummies." ;-)
^ permalink raw reply
* Re: RSS Limit implementation issue
From: Bill Davidsen @ 2006-04-04 19:28 UTC (permalink / raw)
To: Roger Heflin; +Cc: 'linux mailing-list'
In-Reply-To: <EXCHG2003g3Sv0YKpDS000000d0@EXCHG2003.microtech-ks.com>
Roger Heflin wrote:
>
>
>> A process has no control over its RSS size, only its virtual
>> size. I'm not sure you're clear on that, or just not saying
>> it clearly. Therefore the same process, say a largish perl
>> run, may be 175mB in vsize, and during the day have rss of
>> perhaps half that. At night, with next to no load on the
>> machine, the rss is 175mB because there is a bunch of free
>> memory available.
>>
>> If you want to make rss a hard limit the result should be
>> swapping, not failure to run. I'm not sure the limit in that
>> form is a good idea, and before someone reminds me, I do
>> remember liking it better a few years ago.
>
> working_set_size limits sucked on VMS. The OS would limit a process to
> its working set size and casue the entire machine to swap
> even though there was adequate free memory. I believe they
> had a normalworkingset size variable, and a maxworkingsetsize
> one indicated how much ram you could get on a memory limited
> system, the other indicated the most it would ever let you get even if
> there was plenty of free ram. The maxworkingsetsize caused
> a lot of issues, as the default appeared to be defined for
> much smaller systems that we were using at the time, and so
> were much too low, and cause unnecessary swapping. Part of the
> issue would be that the admin would need to know what he was
> doing to use the feature, and most don't.
>
> The argument from the admins at the time was that this limited
> the damage to other processes by preventing certain processes
> from getting too much memory, they ignored the fact that
> anything swapping (even only the one process) unnecessarly
> *KILLED* performance for the entire machine, since swapping
> is rather expensive on the os.
After thinking about this, I have the opinion that if an RSS limit is
working it would be a hard limit. The alternative is a process which
gets large and then when memory pressure increases the oversize process
either causes a lot of swapping or worse yet ties up a lot of memory if
swap rate is limited.
There are many ways to tune Linux badly, adding one more will not add
much to the pain if the default is off. The values available to a normal
users might be limited to prevent the most obvious bad choices. Or a
corresponding option could be provided to take corrective action for a
process with RSS set (to any value) and swap rate high.
^ permalink raw reply
* Re: [Qemu-devel] SPARC iommu mapping
From: Joerg Platte @ 2006-04-05 18:25 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <BAY104-F2926FE4988EEFCC93C59DFFFCB0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]
Am Mittwoch, 5. April 2006 19:36 schrieb Blue Swirl:
Hi!
> I don't have any better documentation either, I just coded against what
> Proll and Linux expect. But the theory of operation is simple. Much like
OK, I thought I was just too stupid to find good documentation :-)
> how the MMU translates CPU's virtual addresses to physical addresses for
> memory, IOMMU translates device virtual memory accesses to physical
> addresses. The VA to PA entries are found in a simple page table.
That's what I read from qemu's iommu functions.
> In the case of not finding a valid translation entry, IOMMU can't fault the
> device like normal MMU can easily fault the CPU. I don't know what should
> happen then, probably put the address to AFAR register and raise some
> interrupt, while the device (for example Ethernet controller) waiting for
> the data suffers in limbo. I think it would be strange for an OS to rely on
> this, so I guess it's a bug somewhere else. My guess for the valid bit is
> that it's used in a real IOMMU to select the entries that will be loaded to
> its internal translation buffer.
Maybe.
> The DMA controllers for both ESP and Lance are within the same page. This
> means that in Qemu, DMA controller register accesses for either of them go
> to just one of these. It just happens to work, but maybe this causes the
> problem. You could try to confirm this by enabling also DEBUG_LANCE and see
> if there is troublesome activity in the Lance direction near the bad
> accesses.
Hmmm, I don't use the network. Just disk access. But I'll check this.
> Can you provide a test case so that I could try it as well?
I'm using the two attached programs. writetest is used inside qemu to directly
write to /dev/sda (with "writetest /dev/sda"). readtest can then be used
outside qemu to check the written data ("readtest imagefile").
Additionally, I logged the translated virtual address as mentioned in my first
mail. The kernel is 2.6.13.
regards,
Jörg
[-- Attachment #2: readtest.c --]
[-- Type: text/x-csrc, Size: 671 bytes --]
#include <stdio.h>
int main(int argc, char**argv) {
FILE *fp;
unsigned char buffer[4];
unsigned int i,j;
unsigned int doprint=1;
unsigned int d=0;
if ((fp=fopen(argv[1], "r"))) {
for (i=0; i<10000000; i+=4) {
if (fread(&buffer, 4, 1, fp)!=1) {
printf("error writing at byte %d\n", i);
break;
}
d=0;
for(j=0;j<4; j++) {
if (buffer[3-j]!=((i>>(j*8))&0xff)) {
if (doprint) {
printf("data differs at address %08x\n", i);
}
d=1;
break;
}
}
if (d) {
doprint=0;
} else {
doprint=1;
}
}
fclose(fp);
}
}
[-- Attachment #3: writetest.c --]
[-- Type: text/x-csrc, Size: 289 bytes --]
#include <stdio.h>
int main(int argc, char**argv) {
FILE *fp;
unsigned int i;
if ((fp=fopen(argv[1], "w"))) {
for (i=0; i<10000000; i+=4) {
if (fwrite(&i, 4, 1, fp)!=1) {
printf("error writing at byte %d\n", i);
break;
}
}
fclose(fp);
}
}
^ 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.