* Re: [PATCH 3/5] allow cloning a repository "shallowly"
From: Junio C Hamano @ 2006-11-14 17:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611141145390.13772@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I understand "no need making it shallow", but I am not sure if a
>> non-NULL return from lookup_object() tells us that.
>
> You are probably right, how about has_sha1_file()?
>
>> I think register_shallow() can take commits that are already shallow()
>> so maybe we can remove this "if() continue"?
>
> Yes, it can, but that is not necessarily correct: since .git/shallow is
> constructed from the registered shallow commits, we would make a commit
> shallow which is really not shallow.
>
> So, how about
>
>> > + if (lookup_object(sha1) || has_sha1_file(sha1))
>> > + continue;
If I understand the code correctly, this loop is reading what
the other side thinks your shallows should be (based on your
earlier "deepen" request or if this is initial fetch based on
your depth). Even if we already have that object, if that
object _is_ shallow on our end, don't we need to keep it marked
as shallow? Will we get ancestors of this commit from the other
end (and "shallow" lines for some of them to properly cauterize
the chain)?
^ permalink raw reply
* Re: [PATCH] rewrite restore_fp_context/save_fp_context
From: Ralf Baechle @ 2006-11-14 17:46 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips
In-Reply-To: <20060829.225631.41630441.anemo@mba.ocn.ne.jp>
On Tue, Aug 29, 2006 at 10:56:31PM +0900, Atsushi Nemoto wrote:
> The setup_sigcontect()/restore_sigcontext() might sleep on
> put_user()/get_user() with preemption disabled (i.e. atomic context).
> Sleeping in atomic context is not allowed. This patch fixes this
> problem by rewriting restore_fp_context()/save_fp_context().
So with this patch applied the context will be copied around twice, first
save the fp registers to memory then copied from memory to userspace and
as the result the non-preemptible kernel will suffer from fixing the
preemptible ...
To me it looks like the real problem that setup_sigcontext and
restore_sigcontext need to disable preemption. And the reason for that
is probably that 87d54649f67d8ffe0a8d8176de8c210a6c4bb4a7 around 2.6.9
took the wrong. The better fix would probably have been to allow
at least some fp instructions from kernel mode. The sole reason for
the die_if_kernel() call is to tell people attempting to put FPU code
into the kernel that they're screwing up.
Ralf
^ permalink raw reply
* Re: [PATCH] appletouch: use canonical names instead of raw USB IDs
From: Stelian Pop @ 2006-11-14 17:45 UTC (permalink / raw)
To: Julien BLACHE; +Cc: linux-kernel, dmitry.torokhov
In-Reply-To: <871wo6q6y1.fsf@frigate.technologeek.org>
Le mardi 14 novembre 2006 à 18:22 +0100, Julien BLACHE a écrit :
> Hi,
>
> Small readability improvement for appletouch: use canonical names
> instead of raw USB IDs for some of the devices.
While you're at it, please update hid-core.c too for the FN_KEY quirks.
The same comments applies to your other patch which adds the new Geyser
IV ids. Those needs to be added to hid-core.c too.
Otherwise you have my
Acked-by: Stelian Pop <stelian@popies.net>
for the both patches.
Oh, and put your patch in the mail inline, it's easier to quote if
needed.
Stelian.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Re: Making a Diff
From: Bart Oldeman @ 2006-11-14 17:45 UTC (permalink / raw)
To: Alain M.; +Cc: dosEmu-list
In-Reply-To: <4559FAEE.1030407@pobox.com>
On 11/14/06, Alain M. <alainm@pobox.com> wrote:
>
> What is the standard command to generate e diff to submit to Dosemu? I
> have one directory called dosemu-org and one called dosemu-850...
diff -urN dosemu-org dosemu-850 > dosemu-850.diff
> I have a patch to install fonts for CP850 8x14, the original is from the
> debian project
> <http://packages.debian.org/stable/x11/xfonts-terminus-dos> so it is GPL
> and ok for Dosemu
>
> First question: in the etc/dosemu.alias, all lines look like this:
>
> vga10x20-ua -dosemu-vga-medium-r-normal--20-200-75-75-c-100-ibm-cp1125
>
> but the one I generated has different names:
>
> vga8x14-cp850 -xos4-Terminus-Bold-R-Normal--14-140-72-72-C-80-IBM-CP850
>
> Should I try to convert it? These are the names in the original
> Debian/Terminus project...
This is probably fine, dosemu-vga and xos4-Terminus don't matter. The
rest is just about a case difference and about the font size.
But I'd like to ask:
1. Why an 8x14 font? It seems a bit small, even smaller than the
standard 8x16. Is there also a problem with using bitmap fonts and the
FreeDOS mode/display/chcp technique?
2. It may be better to use unicode. The present SVN code supports
unicode fonts, you can even use the standard
$_X_font="-Misc-Fixed-Medium-R-SemiCondensed--13-120-75-75-C-60-ISO10646-1"
it's small but gives you all the characters you need.
Have a look at
http://www.inp.nsk.su/~bolkhov/files/fonts/univga/
as well.
Bart
^ permalink raw reply
* No Mails
From: Shailendra Tripathi @ 2006-11-14 17:32 UTC (permalink / raw)
To: xfs
In-Reply-To: <20061110011018.GP8394166@melbourne.sgi.com>
Not getting any mail on the mailing list. I am not sure if there is no
activity or I am not getting any mail.
I suspect the latter, how do I re-enable myself.
-shailendra
^ permalink raw reply
* Re: Missing features in git
From: Jakub Narebski @ 2006-11-14 17:45 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061114173657.GC5453@diana.vm.bytemark.co.uk>
Dnia wtorek 14. listopada 2006 18:36, Karl Hasselström napisał:
>
> For example, we could skip the "bisect" branch, since
> you aren't supposed to commit to that anyway.
Well, to have "branch" to which you could not commit, just put ref
outside refs/heads.
Another solution would be to be able to put non-head ref in HEAD,
but allow to commit only if the prefix is refs/heads/
--
Jakub Narebski
^ permalink raw reply
* Re: Perl
From: Lee Revell @ 2006-11-14 17:42 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded
In-Reply-To: <4559F7F9.4070008@grandegger.com>
On Tue, 2006-11-14 at 18:08 +0100, Wolfgang Grandegger wrote:
> Lee Revell wrote:
> > I've been trying to cross compile Perl for a PPC440 board and it just
> > isn't happening. Perl is probably the least amenable application to
> > cross compiling I've found.
> >
> > I tried the instructions in the Cross/ directory of the Perl distro but
> > they don't work - "sh Configure" fails on my target because it expects a
> > full C development environment, which won't fit.
> >
> > Is there any easy solution? Can someone send me a binary?
>
> Configure and make perl natively on your target platform. I have done it
> some time ago with the ELDK.
I don't think this is an option, the perl build has too many
dependencies.
Lee
^ permalink raw reply
* RE: Two dead-lock situation occurs on 32bit HVM SMP Windows
From: Li, Xin B @ 2006-11-14 17:42 UTC (permalink / raw)
To: Keir Fraser, Xin, Xiaohui, xen-devel
Cc: Mallick, Asit K, Tian, Kevin, Li, Susie, Nakajima, Jun, He, Qing
>
>On 14/11/06 17:33, "Li, Xin B" <xin.b.li@intel.com> wrote:
>
>> On x86_64 xen, we saw get_mfn_from_gpfn gets into the fault-and-fixup
>> path frequently when running 64bit windows guests with 1G
>RAM, and quite
>> a few of them are caused by gpfn > 0x100000, i.e. above 4G,
>so how about
>> aslo adding a gpfn range check into get_mfn_from_gpfn? And we can use
>> hvm_set_param to set the max gpfn # in xc_hvm_build.c.
>
>Any idea what it's trying to access? Presumably nothing is
>mapped up there
>so it just gets all-ones back from reads? I'm surprised it
>would be doing
>lots of accesses to totally unused memory space. That tends to
>be fairly
>slow even on native hardware.
>
that are from detecting if a guest page table page is no longer a page
table page, like in validate_gl4e.
-Xin
^ permalink raw reply
* Re: [PATCH 2/5] support fetching into a shallow repository
From: Junio C Hamano @ 2006-11-14 17:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611141140530.13772@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I think the "commit = p->item" part is trying to do a tail
>> recursion optimization, but this is a bit too clever to my
>> liking (at first I mistook that the code forgot to re-point p at
>> its parents list and incrementing cur_depth).
>
> I take it as a compliment ;-)
>
> Seriously again, would you like me to add a comment, or rather do away
> with the tail recursion optimization? It is not a huge optimization
> anyway. Maybe a cleverer way would be to use an object_array instead of a
> commit_list?
Leaving it as a compliment is just fine.
^ permalink raw reply
* RE: [PATCH] ia64 enable trap code on slot 1
From: Luck, Tony @ 2006-11-14 17:41 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <45592018.3040203@intel.com>
> I think a comment here in break.h would be useful ... noting that
> for JPROBE and KPROBE the low 12-bits are ignored.
I added a teeny comment ... so break.h diff looks like this. Ok?
diff --git a/include/asm-ia64/break.h b/include/asm-ia64/break.h
index 8167828..f034020 100644
--- a/include/asm-ia64/break.h
+++ b/include/asm-ia64/break.h
@@ -12,8 +12,8 @@ #define _ASM_IA64_BREAK_H
* OS-specific debug break numbers:
*/
#define __IA64_BREAK_KDB 0x80100
-#define __IA64_BREAK_KPROBE 0x80200
-#define __IA64_BREAK_JPROBE 0x80300
+#define __IA64_BREAK_KPROBE 0x81000 /* .. 0x81fff */
+#define __IA64_BREAK_JPROBE 0x82000
^ permalink raw reply related
* [lm-sensors] About fancontrol: I could not control the CPU fan
From: Yongkui Han @ 2006-11-14 17:40 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <2ca62ec0610301925i65568f5ar4449bfe2d9d5c406@mail.gmail.com>
Hi Rudolf,
Thank you very much for your instructions. I am busy these days. I will do
as you say later and let you know the results later.
Sorry for the late response. Thank you very much!
Yongkui
On 11/11/06, Rudolf Marek <r.marek at assembler.cz> wrote:
>
> Hi Yongkui
>
> > 0 1 2 3 4 5 6 7 8 9 a b c d e f
> > 0800: 00 00 00 00 38 f7 77 bf a0 00 00 00 00 00 00 00
> > 0810: 02 00 77 df ca 00 00 00 00 00 00 00 00 00 02 00
> > 0820: 00 00 00 81 81 81 81 80 01 01 80 80 80 80 00 80
> > 0830: 80 80 84 05 05 04 04 05 04 84 84 04 04 84 80 05
> > 0840: 05 05 04 05 04 05 04 81 80 00 00 f7 77 1d 08 57
> > 0850: 02 00 00 00 ff ff 10 7f f0 26 ff 00 00 00 00 00
>
> Is this dump done before you loaded the driver?
>
> Fan2 is set to fullspeed (bit 0 is 1)
> Fan1 is set to some speed 001000 -> 8/64 of duty cycle
>
>
> > So, the register 0x58 is f0, which is 11110000. But I am not sure
> > whether the Bit 0 is from left or right. I assume it is from right. So
> > Bit 0 to Bit 3 = 0, and Bit 4 to Bit 7 = 1.
>
> Bits are from right.
>
> > Accoring to Table 57 on page 118 of the manual, this means the Fout is
> > 15.625 kHz?
>
> Yes seems correct to me.Please write there 80/120Hz so:
>
> isaset -y -f 0x858 0xff
>
> Is there a change in pwmconfig curve?
>
> Regards
> Rudolf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061114/0a878d7e/attachment.html
^ permalink raw reply
* Re: Possibly OT: bdi2000 virtual memory on 2.6 kernel
From: Dan Malek @ 2006-11-14 17:39 UTC (permalink / raw)
To: robin.gilks; +Cc: ppc embedded list
In-Reply-To: <45593537.1010604@tait.co.nz>
On Nov 13, 2006, at 10:17 PM, Robin Gilks wrote:
> Debugging a 2.6.18 kernel on a powerpc target
Which processor, specifically?
What do your MMU XLAT and PTBASE configuration
lines look like?
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 1/1] security: introduce fs caps
From: Bill O'Donnell @ 2006-11-14 17:40 UTC (permalink / raw)
To: Chris Friedhoff
Cc: Serge E. Hallyn, linux-kernel, linux-security-module,
Stephen Smalley, James Morris, Chris Wright, Andrew Morton,
KaiGai Kohei, Alexey Dobriyan
In-Reply-To: <20061114182818.b342e7aa.chris@friedhoff.org>
On Tue, Nov 14, 2006 at 06:28:18PM +0100, Chris Friedhoff wrote:
| Attached the trace of
| $ su -c "strace -o /tmp/stracesetfcapsout -f setfcaps
| cap_net_raw=ep /bin/ping "
| Here its working.
| From where are the setfcaps/getfcaps tools? Bill, have you compiled
| them or are they from a package?
I compiled and installed them to /sbin (Kagai's userspace libcap tools),
using his Makefile.
|
| > $ uname -a
| > Linux certify 2.6.19-rc3 #3 SMP PREEMPT Mon Nov 13 14:40:54 CST 2006
| > ia64
| Its an 64 bit system, right? Which distro are you using?
Yes. Its an Itanium based SGI Altix, with a SuSE SLES-10 distro.
Bill
|
|
| Chris
|
|
| On Tue, 14 Nov 2006 09:23:07 -0600
| "Serge E. Hallyn" <serue@us.ibm.com> wrote:
|
| > Quoting Bill O'Donnell (billodo@sgi.com):
| > > 8102 execve("/sbin/setfcaps", ["setfcaps", "cap_net_raw=ep", "/bin/ping"], [/* 67 vars */]) = 0
| > > 8102 brk(0) = 0x6000000000004000
| > > 8102 uname({sys="Linux", node="certify", ...}) = 0
| > > 8102 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
| > > 8102 open("/etc/ld.so.cache", O_RDONLY) = 3
| > > 8102 fstat(3, {st_mode=S_IFREG|0644, st_size=111415, ...}) = 0
| > > 8102 mmap(NULL, 111415, PROT_READ, MAP_PRIVATE, 3, 0) = 0x200000000004c000
| > > 8102 close(3) = 0
| > > 8102 open("/lib/libcap.so.1", O_RDONLY) = 3
| > > 8102 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0\340\25"..., 832) = 832
| > > 8102 fstat(3, {st_mode=S_IFREG|0755, st_size=22672, ...}) = 0
| > > 8102 mmap(NULL, 85800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2000000000068000
| > > 8102 madvise(0x2000000000068000, 85800, MADV_SEQUENTIAL|0x1) = 0
| > > 8102 mprotect(0x2000000000070000, 49152, PROT_NONE) = 0
| > > 8102 mmap(0x200000000007c000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x200000000007c000
| > > 8102 close(3) = 0
| > > 8102 open("/lib/libc.so.6.1", O_RDONLY) = 3
| > > 8102 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0\3609\2"..., 832) = 832
| > > 8102 fstat(3, {st_mode=S_IFREG|0755, st_size=2590313, ...}) = 0
| > > 8102 mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2000000000080000
| > > 8102 mmap(NULL, 2416624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2000000000084000
| > > 8102 madvise(0x2000000000084000, 2416624, MADV_SEQUENTIAL|0x1) = 0
| > > 8102 mprotect(0x20000000002bc000, 49152, PROT_NONE) = 0
| > > 8102 mmap(0x20000000002c8000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x234000) = 0x20000000002c8000
| > > 8102 mmap(0x20000000002d0000, 8176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20000000002d0000
| > > 8102 close(3) = 0
| > > 8102 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x20000000002d4000
| > > 8102 mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x20000000002dc000
| > > 8102 munmap(0x200000000004c000, 111415) = 0
| > > 8102 brk(0) = 0x6000000000004000
| > > 8102 brk(0x6000000000028000) = 0x6000000000028000
| > > 8102 capget(0x19980330, 0, {0, 0, 0}) = -1 EINVAL (Invalid argument)
| >
| > I don't see why this capget is returning -EINVAL. In fact I don't see
| > why it happens at all - cap_inode_setxattr would check
| > capable(CAP_SYS_ADMIN), but setxattr hasn't been called yet. Looking at
| > both libcap and setfcaps.c, I don't see where the capget comes from.
| >
| > As for the -EINVAL, kernel/capability.c:sys_capget() returns -EINVAL if
| > the _LINUX_CAPABILITY_VERSION is wrong - you have 0x19980330 which is
| > correct - if pid < 0 - but you send in 0 - or if security_capget
| > returns -EINVAL, which cap_capget (and dummy_capget) don't do.
| >
| > Kaigai, do you have any ideas?
| >
| > thanks,
| > -serge
|
|
| --------------------
| Chris Friedhoff
| chris@friedhoff.org
--
Bill O'Donnell
SGI
651.683.3079
billodo@sgi.com
^ permalink raw reply
* Re: Two dead-lock situation occurs on 32bit HVM SMP Windows
From: Keir Fraser @ 2006-11-14 17:37 UTC (permalink / raw)
To: Li, Xin B, Xin, Xiaohui, xen-devel
Cc: Mallick, Asit K, Tian, Kevin, Li, Susie, Nakajima, Jun, He, Qing
In-Reply-To: <B30DA1341B0CFA4893EF8A36B40B5C5D679212@pdsmsx411.ccr.corp.intel.com>
On 14/11/06 17:33, "Li, Xin B" <xin.b.li@intel.com> wrote:
> On x86_64 xen, we saw get_mfn_from_gpfn gets into the fault-and-fixup
> path frequently when running 64bit windows guests with 1G RAM, and quite
> a few of them are caused by gpfn > 0x100000, i.e. above 4G, so how about
> aslo adding a gpfn range check into get_mfn_from_gpfn? And we can use
> hvm_set_param to set the max gpfn # in xc_hvm_build.c.
Any idea what it's trying to access? Presumably nothing is mapped up there
so it just gets all-ones back from reads? I'm surprised it would be doing
lots of accesses to totally unused memory space. That tends to be fairly
slow even on native hardware.
-- Keir
^ permalink raw reply
* Re: Missing features in git
From: Karl Hasselström @ 2006-11-14 17:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611141815.24236.jnareb@gmail.com>
On 2006-11-14 18:15:23 +0100, Jakub Narebski wrote:
> Karl Hasselström wrote:
> > On 2006-11-14 15:53:18 +0100, Jakub Narebski wrote:
>
> > > And what would happen if you want to checkout other branch?
> > > Where the ID in the HEAD would go to? HEAD just _has_ to be
> > > reference to _branch_.
> >
> > The id that used to be HEAD would not be saved anywhere. It would
> > still be reachable from your refs, presumably, just like before
> > you checked it out. (It would not be the case that you had made
> > commits on an unnamed branch that would now get lost, because the
> > tool would refuse to commit until you had created a name for the
> > branch.)
>
> If HEAD would contain an commit ID directly, then you shouldn't be
> able to commit at all.
I agree. You aren't on a branch, so you can't commit. (Of course,
creating a branch for the commit you're on is trivial: "git checkout
-b <branchname>".)
> Not very useful, it is.
Well, as long as you only want to visit the past, not change it, it
can be useful. For example, we could skip the "bisect" branch, since
you aren't supposed to commit to that anyway.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* RE: Two dead-lock situation occurs on 32bit HVM SMP Windows
From: Li, Xin B @ 2006-11-14 17:33 UTC (permalink / raw)
To: Keir Fraser, Xin, Xiaohui, xen-devel
Cc: Mallick, Asit K, Tian, Kevin, Li, Susie, Nakajima, Jun, He, Qing
>The PV drivers should not have been hitting the MMIO region with
>any regularity however. Is it the LAPIC and IOAPIC that are getting
> hit? It certainly makes sense to cover hot regions of the P2M table
> with valid mappings - we should not expect the fault-and-fixup
> path to be fast. A single extra pagetable with INVALID_MFN just
>below 4GB would I'm sure speed things up quite a bit!
Keir
On x86_64 xen, we saw get_mfn_from_gpfn gets into the fault-and-fixup
path frequently when running 64bit windows guests with 1G RAM, and quite
a few of them are caused by gpfn > 0x100000, i.e. above 4G, so how about
aslo adding a gpfn range check into get_mfn_from_gpfn? And we can use
hvm_set_param to set the max gpfn # in xc_hvm_build.c.
-Xin
^ permalink raw reply
* Re: CONFIG_NO_HZ: missed ticks, stall (keyb IRQ required) [2.6.18-rc4-mm1]
From: Andreas Mohr @ 2006-11-14 17:30 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: Len Brown, Ingo Molnar, Andreas Mohr, Thomas Gleixner,
linux-kernel, Van De Ven, Arjan
In-Reply-To: <EB12A50964762B4D8111D55B764A8454E0DBDE@scsmsx413.amr.corp.intel.com>
Hi,
On Tue, Nov 14, 2006 at 09:21:02AM -0800, Pallipadi, Venkatesh wrote:
> >I belive that Venki has looked at some of the HPET enumeration issues,
> >and maybe he has some suggestions. Is there an example system
> >on-hand where we know Windows works and Linux does not?
> >
>
> There are two things that can be happening when OS does not see HPET in
> ACPI.
> - BIOS did enable HPET in chipset and did not communicate it to OS.
> - BIOS did nothing to enable HPET in chipset.
I'm sure you've already seen
http://semthex.freeflux.net/blog/archive/2006/10/21/hpet-to-be-or-not-to-be.html
... or not?
Hmm, hopefully it's easy to research where to enable HPET
(if there is one at all!) on an el-cheapo VIA chipset...
Many thanks for your patch! (even though currently Intel-only)
Andreas Mohr
^ permalink raw reply
* Re: [PATCH 1/1] security: introduce fs caps
From: Chris Friedhoff @ 2006-11-14 17:28 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Bill O'Donnell, linux-kernel, linux-security-module,
Stephen Smalley, James Morris, Chris Wright, Andrew Morton,
KaiGai Kohei, Alexey Dobriyan
In-Reply-To: <20061114152307.GA7534@sergelap.austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3685 bytes --]
Attached the trace of
$ su -c "strace -o /tmp/stracesetfcapsout -f setfcaps
cap_net_raw=ep /bin/ping "
Here its working.
>From where are the setfcaps/getfcaps tools? Bill, have you compiled
them or are they from a package?
> $ uname -a
> Linux certify 2.6.19-rc3 #3 SMP PREEMPT Mon Nov 13 14:40:54 CST 2006
> ia64
Its an 64 bit system, right? Which distro are you using?
Chris
On Tue, 14 Nov 2006 09:23:07 -0600
"Serge E. Hallyn" <serue@us.ibm.com> wrote:
> Quoting Bill O'Donnell (billodo@sgi.com):
> > 8102 execve("/sbin/setfcaps", ["setfcaps", "cap_net_raw=ep", "/bin/ping"], [/* 67 vars */]) = 0
> > 8102 brk(0) = 0x6000000000004000
> > 8102 uname({sys="Linux", node="certify", ...}) = 0
> > 8102 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> > 8102 open("/etc/ld.so.cache", O_RDONLY) = 3
> > 8102 fstat(3, {st_mode=S_IFREG|0644, st_size=111415, ...}) = 0
> > 8102 mmap(NULL, 111415, PROT_READ, MAP_PRIVATE, 3, 0) = 0x200000000004c000
> > 8102 close(3) = 0
> > 8102 open("/lib/libcap.so.1", O_RDONLY) = 3
> > 8102 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0\340\25"..., 832) = 832
> > 8102 fstat(3, {st_mode=S_IFREG|0755, st_size=22672, ...}) = 0
> > 8102 mmap(NULL, 85800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2000000000068000
> > 8102 madvise(0x2000000000068000, 85800, MADV_SEQUENTIAL|0x1) = 0
> > 8102 mprotect(0x2000000000070000, 49152, PROT_NONE) = 0
> > 8102 mmap(0x200000000007c000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x200000000007c000
> > 8102 close(3) = 0
> > 8102 open("/lib/libc.so.6.1", O_RDONLY) = 3
> > 8102 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0002\0\1\0\0\0\3609\2"..., 832) = 832
> > 8102 fstat(3, {st_mode=S_IFREG|0755, st_size=2590313, ...}) = 0
> > 8102 mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2000000000080000
> > 8102 mmap(NULL, 2416624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2000000000084000
> > 8102 madvise(0x2000000000084000, 2416624, MADV_SEQUENTIAL|0x1) = 0
> > 8102 mprotect(0x20000000002bc000, 49152, PROT_NONE) = 0
> > 8102 mmap(0x20000000002c8000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x234000) = 0x20000000002c8000
> > 8102 mmap(0x20000000002d0000, 8176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20000000002d0000
> > 8102 close(3) = 0
> > 8102 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x20000000002d4000
> > 8102 mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x20000000002dc000
> > 8102 munmap(0x200000000004c000, 111415) = 0
> > 8102 brk(0) = 0x6000000000004000
> > 8102 brk(0x6000000000028000) = 0x6000000000028000
> > 8102 capget(0x19980330, 0, {0, 0, 0}) = -1 EINVAL (Invalid argument)
>
> I don't see why this capget is returning -EINVAL. In fact I don't see
> why it happens at all - cap_inode_setxattr would check
> capable(CAP_SYS_ADMIN), but setxattr hasn't been called yet. Looking at
> both libcap and setfcaps.c, I don't see where the capget comes from.
>
> As for the -EINVAL, kernel/capability.c:sys_capget() returns -EINVAL if
> the _LINUX_CAPABILITY_VERSION is wrong - you have 0x19980330 which is
> correct - if pid < 0 - but you send in 0 - or if security_capget
> returns -EINVAL, which cap_capget (and dummy_capget) don't do.
>
> Kaigai, do you have any ideas?
>
> thanks,
> -serge
--------------------
Chris Friedhoff
chris@friedhoff.org
[-- Attachment #2: stracesetfcapsout.gz --]
[-- Type: application/octet-stream, Size: 792 bytes --]
^ permalink raw reply
* Re: Allocation strategy - dynamic zone for small files
From: Matthew Wilcox @ 2006-11-14 17:27 UTC (permalink / raw)
To: Al Boldi; +Cc: Theodore Tso, linux-fsdevel
In-Reply-To: <200611141959.43417.a1426z@gawab.com>
On Tue, Nov 14, 2006 at 07:59:43PM +0300, Al Boldi wrote:
> Matthew Wilcox wrote:
> > On Tue, Nov 14, 2006 at 06:43:39PM +0300, Al Boldi wrote:
> > > An API would probably be in order.
> > >
> > > Performance due to non-redundancy.
> > >
> > > Or a desire to let people choose what they want.
> > >
> > > Think freedom...
> >
> > How about fewer "visionary statements" and more code?
>
> How about discussing the feasibility before sending any code?
Great idea. Discuss the feasibility, rather than responding with
platitudes to people telling you it's infeasible. Show examples, show
how it would help. Take the inetd.conf example. Look at the current
user-space parser. Show how a new implementation might work. Use
pseudocode where necessary; this doesn't have to compile, it has to
convince people that there's something worthwhile in doing this.
^ permalink raw reply
* [PATCH] appletouch: add Geyser IV support
From: Julien BLACHE @ 2006-11-14 17:25 UTC (permalink / raw)
To: linux-kernel; +Cc: dmitry.torokhov, stelian
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
Hi,
The new Core2 Duo MacBook Pro has a new keyboard+trackpad named
"Geyser IV".
According to the Info.plist in the OS X kext, it looks like the Geyser
IV trackpad is identical to the Geyser III trackpad: same IOClass
(AppleUSBGrIIITrackpad), same acceleration tables.
Signed-off-by: Julien BLACHE <jb@jblache.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: appletouch: add Geyser IV support --]
[-- Type: text/x-patch, Size: 1813 bytes --]
--- appletouch.c.orig 2006-11-14 18:19:07.319174145 +0100
+++ appletouch.c 2006-11-14 18:19:12.939494428 +0100
@@ -54,6 +54,14 @@
#define GEYSER3_ISO_PRODUCT_ID 0x0218
#define GEYSER3_JIS_PRODUCT_ID 0x0219
+/*
+ * Geyser IV: same as Geyser III according to Info.plist in AppleUSBTrackpad.kext
+ * -> same IOClass (AppleUSBGrIIITrackpad), same acceleration tables
+ */
+#define GEYSER4_ANSI_PRODUCT_ID 0x021A
+#define GEYSER4_ISO_PRODUCT_ID 0x021B
+#define GEYSER4_JIS_PRODUCT_ID 0x021C
+
#define ATP_DEVICE(prod) \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
USB_DEVICE_ID_MATCH_INT_CLASS | \
@@ -75,10 +83,16 @@
{ ATP_DEVICE(GEYSER_ISO_PRODUCT_ID) },
{ ATP_DEVICE(GEYSER_JIS_PRODUCT_ID) },
+ /* Core Duo MacBook & MacBook Pro */
{ ATP_DEVICE(GEYSER3_ANSI_PRODUCT_ID) },
{ ATP_DEVICE(GEYSER3_ISO_PRODUCT_ID) },
{ ATP_DEVICE(GEYSER3_JIS_PRODUCT_ID) },
+ /* Core2 Duo MacBook & MacBook Pro */
+ { ATP_DEVICE(GEYSER4_ANSI_PRODUCT_ID) },
+ { ATP_DEVICE(GEYSER4_ISO_PRODUCT_ID) },
+ { ATP_DEVICE(GEYSER4_JIS_PRODUCT_ID) },
+
/* Terminating entry */
{ }
};
@@ -115,7 +129,7 @@
*/
#define ATP_THRESHOLD 5
-/* MacBook Pro (Geyser 3) initialization constants */
+/* MacBook Pro (Geyser 3 & 4) initialization constants */
#define ATP_GEYSER3_MODE_READ_REQUEST_ID 1
#define ATP_GEYSER3_MODE_WRITE_REQUEST_ID 9
#define ATP_GEYSER3_MODE_REQUEST_VALUE 0x300
@@ -181,7 +195,10 @@
return (productId == GEYSER3_ANSI_PRODUCT_ID) ||
(productId == GEYSER3_ISO_PRODUCT_ID) ||
- (productId == GEYSER3_JIS_PRODUCT_ID);
+ (productId == GEYSER3_JIS_PRODUCT_ID) ||
+ (productId == GEYSER4_ANSI_PRODUCT_ID) ||
+ (productId == GEYSER4_ISO_PRODUCT_ID) ||
+ (productId == GEYSER4_JIS_PRODUCT_ID);
}
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
[-- Attachment #3: Type: text/plain, Size: 155 bytes --]
JB.
--
Julien BLACHE <http://www.jblache.org>
<jb@jblache.org> GPG KeyID 0xF5D65169
^ permalink raw reply
* [PATCH] set default video mode on PowerBook Wallstreet
From: Olaf Hering @ 2006-11-14 17:19 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev
finally add the third PowerBook Wallstreet 233MHz model to the list of
known display resolutions.
Without this change, a 640x480 video mode is used.
A workaround so far was to boot with 'video=atyfb:vmode:14'
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/video/aty/atyfb_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18/drivers/video/aty/atyfb_base.c
===================================================================
--- linux-2.6.18.orig/drivers/video/aty/atyfb_base.c
+++ linux-2.6.18/drivers/video/aty/atyfb_base.c
@@ -409,7 +409,7 @@ static struct {
{ PCI_CHIP_MACH64LB, "3D RAGE LT PRO (Mach64 LB, AGP)", 236, 75, 100, 135, ATI_CHIP_264LTPRO },
{ PCI_CHIP_MACH64LD, "3D RAGE LT PRO (Mach64 LD, AGP)", 230, 100, 100, 135, ATI_CHIP_264LTPRO },
{ PCI_CHIP_MACH64LI, "3D RAGE LT PRO (Mach64 LI, PCI)", 230, 100, 100, 135, ATI_CHIP_264LTPRO | M64F_G3_PB_1_1 | M64F_G3_PB_1024x768 },
- { PCI_CHIP_MACH64LP, "3D RAGE LT PRO (Mach64 LP, PCI)", 230, 100, 100, 135, ATI_CHIP_264LTPRO },
+ { PCI_CHIP_MACH64LP, "3D RAGE LT PRO (Mach64 LP, PCI)", 230, 100, 100, 135, ATI_CHIP_264LTPRO | M64F_G3_PB_1024x768 },
{ PCI_CHIP_MACH64LQ, "3D RAGE LT PRO (Mach64 LQ, PCI)", 230, 100, 100, 135, ATI_CHIP_264LTPRO },
{ PCI_CHIP_MACH64GM, "3D RAGE XL (Mach64 GM, AGP 2x)", 230, 83, 63, 135, ATI_CHIP_264XL },
^ permalink raw reply
* Re: READ SCSI cmd seems to fail on SATA optical devices...
From: Tejun Heo @ 2006-11-14 17:24 UTC (permalink / raw)
To: Mathieu Fluhr
Cc: Arjan van de Ven, Phillip Susi, jgarzik, linux-ide, linux-kernel
In-Reply-To: <1163519125.2998.8.camel@de-c-l-110.nero-de.internal>
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
Mathieu Fluhr wrote:
> On Mon, 2006-11-13 at 20:32 +0100, Arjan van de Ven wrote:
>> On Mon, 2006-11-13 at 19:56 +0100, Mathieu Fluhr wrote:
>>> On Mon, 2006-11-13 at 13:49 -0500, Phillip Susi wrote:
>>>> Mathieu Fluhr wrote:
>>>>> Hello,
>>>>>
>>>>> I recently tried to burn some datas on CDs and DVD using a SATA burner
>>>>> and the latest 2.6.18.2 kernel... using NeroLINUX. (It is controlling
>>>>> the device by sending SCSI commands over the 'sg' driver)
>>>>>
>>>> Please note that the sg interface is depreciated. It is now recommended
>>>> that you send the CCBs directly to the normal device, i.e. /dev/hdc.
>>> Of course for native IDE devices, we are using the /dev/hdXX device, but
>>> for SATA devices controlled by the libata, this is not possible ;)
>> for those there is /dev/scd0 etc...
>> (usually nicely symlinked to /dev/cdrom)
>
> Hummm as we are _writing_ to devices, I think that using /dev/sgXX with
> SG_IO is better no?
The recommended way is using SG_IO to /dev/srX (or /dev/scdX).
> ... and the problem is not in accessing the device itself (this is
> working like a charm) but understanding why a SCSI READ(10) cmd
> sometimes fails as a ATA-padded READ(10) cmd - as discribed in the Annex
> A of the MMC-5 spec - ALWAYS works.
> -> I would suspect somehow a synchronisation problem somehow in the
> translation of SCSI to ATA command...
Can you try the attached patch and see if anything changes?
--
tejun
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 828 bytes --]
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 2dc3264..fa82151 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -286,6 +286,7 @@ static int sg_io(struct file *file, requ
* fill in request structure
*/
rq->cmd_len = hdr->cmd_len;
+ memset(rq->cmd, 0, BLK_MAX_CDB);
memcpy(rq->cmd, cmd, hdr->cmd_len);
if (sizeof(rq->cmd) != hdr->cmd_len)
memset(rq->cmd + hdr->cmd_len, 0, sizeof(rq->cmd) - hdr->cmd_len);
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index d2c02df..080c2ed 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -410,6 +410,7 @@ int scsi_execute_async(struct scsi_devic
goto free_req;
req->cmd_len = cmd_len;
+ memset(req->cmd, 0, BLK_MAX_CDB);
memcpy(req->cmd, cmd, req->cmd_len);
req->sense = sioc->sense;
req->sense_len = 0;
^ permalink raw reply related
* Re: Generic Netlink Updates
From: Paul Moore @ 2006-11-14 17:23 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev
In-Reply-To: <20061114114628.033840590@lsx.localdomain>
Thomas Graf wrote:
> Various simplifications to the generic netlink interface partially
> based on suggestions by Paul Moore.
Acked-by: Paul Moore <paul.moore@hp.com>
These changes all look good to me.
--
paul moore
linux security @ hp
^ permalink raw reply
* RE: [PATCH 1/5 TAKE 2] xenoprof: split xen x86 xenoprof code
From: Santos, Jose Renato G @ 2006-11-14 17:23 UTC (permalink / raw)
To: Isaku Yamahata, xen-devel; +Cc: xen-ia64-devel
In-Reply-To: <20061114070144.9134.63623.sendpatchset@ls.local.valinux.co.jp>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
> Isaku Yamahata
> Sent: Monday, November 13, 2006 11:02 PM
> To: xen-devel@lists.xensource.com; Isaku Yamahata
> Cc: Isaku Yamahata; xen-ia64-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH 1/5 TAKE 2] xenoprof: split xen
> x86 xenoprof code
>
> # HG changeset patch
> # User yamahata@valinux.co.jp
> # Date 1163486059 -32400
> # Node ID 24e1dacab1545640701709be7742608de73063cc
> # Parent 45d6a5bc857817fb8f541b410920e59bf1417ac2
> move xenoprof code under xen/arch/x86/oprofile to xen/common
> without code changes excpet slight adjustment to compile.
> PATCHNAME: move_xen_x86_xenoprof_code_under_xen_common
>
> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
>
> diff -r 45d6a5bc8578 -r 24e1dacab154 xen/arch/x86/Rules.mk
> --- a/xen/arch/x86/Rules.mk Tue Nov 14 15:34:18 2006 +0900
> +++ b/xen/arch/x86/Rules.mk Tue Nov 14 15:34:19 2006 +0900
> @@ -3,6 +3,7 @@
<deleted>
> int xenoprofile_get_mode(struct vcpu *v, struct
> cpu_user_regs * const regs) { diff -r 45d6a5bc8578 -r
> 24e1dacab154 xen/common/Makefile
> --- a/xen/common/Makefile Tue Nov 14 15:34:18 2006 +0900
> +++ b/xen/common/Makefile Tue Nov 14 15:34:19 2006 +0900
> @@ -29,6 +29,7 @@ obj-y += xmalloc.o
Isaku,
This patch is corrupt. It does not apply cleanly. It has several missing
"newlines" such as for example the line above.
Could you please regenerate ?
I am not sure about the other patches, but it would help if you can make
sure they are all OK and resend.
Thanks
Renato
^ permalink raw reply
* [PATCH] appletouch: use canonical names instead of raw USB IDs
From: Julien BLACHE @ 2006-11-14 17:22 UTC (permalink / raw)
To: linux-kernel; +Cc: dmitry.torokhov, stelian
[-- Attachment #1: Type: text/plain, Size: 167 bytes --]
Hi,
Small readability improvement for appletouch: use canonical names
instead of raw USB IDs for some of the devices.
Signed-off-by: Julien BLACHE <jb@jblache.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: appletouch: use canonical names instead of raw USD IDs for some devices --]
[-- Type: text/x-patch, Size: 1461 bytes --]
--- appletouch.c.orig 2006-11-14 18:14:30.619405923 +0100
+++ appletouch.c 2006-11-14 18:18:14.612170544 +0100
@@ -38,14 +38,21 @@
#define APPLE_VENDOR_ID 0x05AC
/* These names come from Info.plist in AppleUSBTrackpad.kext */
-#define GEYSER_ANSI_PRODUCT_ID 0x0214
-#define GEYSER_ISO_PRODUCT_ID 0x0215
-#define GEYSER_JIS_PRODUCT_ID 0x0216
+#define FOUNTAIN_ANSI_PRODUCT_ID 0x020E
+#define FOUNTAIN_ISO_PRODUCT_ID 0x020F
+
+#define FOUNTAIN_TP_ONLY_PRODUCT_ID 0x030A
+
+#define GEYSER1_TP_ONLY_PRODUCT_ID 0x030B
+
+#define GEYSER_ANSI_PRODUCT_ID 0x0214
+#define GEYSER_ISO_PRODUCT_ID 0x0215
+#define GEYSER_JIS_PRODUCT_ID 0x0216
/* MacBook devices */
-#define GEYSER3_ANSI_PRODUCT_ID 0x0217
-#define GEYSER3_ISO_PRODUCT_ID 0x0218
-#define GEYSER3_JIS_PRODUCT_ID 0x0219
+#define GEYSER3_ANSI_PRODUCT_ID 0x0217
+#define GEYSER3_ISO_PRODUCT_ID 0x0218
+#define GEYSER3_JIS_PRODUCT_ID 0x0219
#define ATP_DEVICE(prod) \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
@@ -58,10 +65,10 @@
/* table of devices that work with this driver */
static struct usb_device_id atp_table [] = {
- { ATP_DEVICE(0x020E) },
- { ATP_DEVICE(0x020F) },
- { ATP_DEVICE(0x030A) },
- { ATP_DEVICE(0x030B) },
+ { ATP_DEVICE(FOUNTAIN_ANSI_PRODUCT_ID) },
+ { ATP_DEVICE(FOUNTAIN_ISO_PRODUCT_ID) },
+ { ATP_DEVICE(FOUNTAIN_TP_ONLY_PRODUCT_ID) },
+ { ATP_DEVICE(GEYSER1_TP_ONLY_PRODUCT_ID) },
/* PowerBooks Oct 2005 */
{ ATP_DEVICE(GEYSER_ANSI_PRODUCT_ID) },
[-- Attachment #3: Type: text/plain, Size: 155 bytes --]
JB.
--
Julien BLACHE <http://www.jblache.org>
<jb@jblache.org> GPG KeyID 0xF5D65169
^ 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.