* Re: [parisc-linux] Strange newest LAB msg?
From: Grant Grundler @ 2006-04-01 7:02 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Parisc List
In-Reply-To: <20060331155448.GP13590@parisc-linux.org>
On Fri, Mar 31, 2006 at 08:54:48AM -0700, Matthew Wilcox wrote:
>
> Just so nobody else has to scratch their head looking at two
> almost-identical dumps, the message Joel means is
>
> > Mar 31 11:45:39 patst006 kernel: allocation failed: out of vmalloc space - use
> > vmalloc=<size> to increase size.
Ah - thanks. I saw that but wasn't sure it was the cause of discussion.
> Either we're leaking vmalloc space, we allocate too much of it, or we
> need to drastically increase it the amount of it we have available.
It's odd that vmalloc fails so early in the boot sequence.
At least the last 10 (of 14) PCI busses fail with the
"allocation failed" message.
Could this somehow be related to the IOREMAP changes?
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
From: Nathan Scott @ 2006-04-01 6:50 UTC (permalink / raw)
To: Andi Kleen
Cc: cmm, Andrew Morton, Takashi Sato, Laurent Vivier, linux-kernel,
ext2-devel, linux-fsdevel
In-Reply-To: <p73r74i91sr.fsf@verdi.suse.de>
Hi Andi,
On Fri, Mar 31, 2006 at 03:33:24PM +0200, Andi Kleen wrote:
> Mingming Cao <cmm@us.ibm.com> writes:
> > > Have you done tests _near_ 8TB with a 32-bit machine, even without these
> > > patches?
> > No I haven't. The >8TB right now is attached to a 64 bit machine, but we
> > should able to move it to a 32 bit machine.
>
> If you use XFS or JFS as backing fs you can use a holey loop device
> to simulate it. When I tried this last time JFS worked better for me.
> XFS doesn't seem to like that many extents as will be created by
> mkfs.ext2.
Mainline has this issue resolved now (very recently, post-.16).
This (loopback on a local file) technique will get you up to 16TB
for 32 bit platforms, where you hit the unsigned long page->index
limit (but sounds like thats fine for the testing you're doing).
A related technique we've used in the past in testing XFS on large
devices (we've successfully tested in petabyte ranges using this,
on 64 bit systems of course) is to write a tool that modifies the
values in the ondisk data structures managing the "lower" areas of
the device to say "all the space here is used", which then forces
new allocations to be done in the "higher" parts of the device
address space. Testing then follows this recipe: mkfs-on-loop,
then run the tool, then mount, then run the usual test suites ...
perhaps thats useful here too (I dunno if the ext2/3 format lends
itself to that or not).
cheers.
--
Nathan
^ permalink raw reply
* Re: [Bluez-users] Fwd: l2ping problem about "Can't connect: Host is down"
From: Albert Huang @ 2006-04-01 6:42 UTC (permalink / raw)
To: bluez-users
In-Reply-To: <f64f4e8a0603291723r2f529303md34d79a52a8f2f2e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3932 bytes --]
try it with hcidump -X -V and post the dump.
-albert
On 3/29/06, zhu yong <zhuyong0003@gmail.com> wrote:
>
>
>
> ---------- Forwarded message ----------
> From: zhu yong <zhuyong0003@gmail.com>
> Date: Mar 29, 2006 10:36 PM
> Subject: l2ping problem about "Can't connect: Host is down"
> To: bluez-users@lists.sourceforge.net
>
> Hi everyone,
>
> I am working with two bluetooth USB dongles. I use bluez-utils-2.25
> and bluez-libs-2.25 packet. I use redhat9.0 with linux kernel 2.4.20,
> I am not familier with kernel update, so I don't use bluez patch to
> 2.4.20.
> They are connected to the same host. However I cannot l2ping one from
> the other.
> info as follows:
> [root@localhost root]# l2ping -i 00:11:67:20:7e:33 00:11:67:1a:a7:0f
> Can't connect: Host is down
>
> And it looks like they are configured:
> [root@localhost root]# hciconfig -a hci0
> hci0: Type: USB
> BD Address: 00:11:67:1A:A7:0F ACL MTU: 678:8 SCO MTU: 48:10
> UP RUNNING PSCAN ISCAN INQUIRY
> RX bytes:1038 acl:0 sco:0 events:38 errors:0
> TX bytes:923 acl:0 sco:0 commands:38 errors:0
> Features: 0xbf 0xfe 0x8d 0x78 0x08 0x18 0x00 0x00
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: RSWITCH HOLD SNIFF PARK
> Link mode: SLAVE ACCEPT
> Name: 'BlueZ (0)'
> Class: 0x3e0100
> Service Classes: Networking, Rendering, Capturing
> Device Class: Computer, Uncategorized
> HCI Ver: 1.2 (0x2) HCI Rev: 0x1fe LMP Ver: 1.2 (0x2) LMP Subver:
> 0x1fe
> Manufacturer: Integrated System Solution Corp. (57)
>
> [root@localhost root]# hciconfig -a hci1
> hci1: Type: USB
> BD Address: 00:11:67:20:7E:33 ACL MTU: 678:8 SCO MTU: 48:10
> UP RUNNING PSCAN ISCAN
> RX bytes:724 acl:0 sco:0 events:58 errors:0
> TX bytes:1075 acl:0 sco:0 commands:49 errors:0
> Features: 0xbf 0xfe 0x8d 0x78 0x08 0x18 0x00 0x00
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: RSWITCH HOLD SNIFF PARK
> Link mode: SLAVE ACCEPT
> Name: 'BlueZ (1)'
> Class: 0x3e0100
> Service Classes: Networking, Rendering, Capturing
> Device Class: Computer, Uncategorized
> HCI Ver: 1.2 (0x2) HCI Rev: 0x1f4 LMP Ver: 1.2 (0x2) LMP Subver:
> 0x1f4
> Manufacturer: Integrated System Solution Corp. (57)
>
> load module as follows:
> [root@localhost bluez-utils-2.25]# lsmod
> Module Size Used by Not tainted
> l2cap 19276 1
> hci_usb 8920 2
> bluez 40132 11 [l2cap hci_usb]
> nls_iso8859-1 3516 1 (autoclean)
> nls_cp437 5116 1 (autoclean)
> vfat 13004 1 (autoclean)
> fat 38808 0 (autoclean) [vfat]
> ide-cd 35708 0 (autoclean)
> cdrom 33728 0 (autoclean) [ide-cd]
> parport_pc 19076 1 (autoclean)
> lp 8996 0 (autoclean)
> parport 37056 1 (autoclean) [parport_pc lp]
> autofs 13268 0 (autoclean) (unused)
> sis900 16812 1
> ipt_REJECT 3928 6 (autoclean)
> iptable_filter 2412 1 (autoclean)
> ip_tables 15096 2 [ipt_REJECT iptable_filter]
> microcode 4668 0 (autoclean)
> keybdev 2944 0 (unused)
> mousedev 5492 1
> hid 22148 0 (unused)
> input 5856 0 [keybdev mousedev hid]
> ehci-hcd 19976 0 (unused)
> usb-ohci 21480 0 (unused)
> usbcore 78784 1 [hci_usb hid ehci-hcd usb-ohci]
> [root@localhost bluez-utils-2.25]#
>
> Can anyone figure out what"s wrong?
>
> Thanks in advance,
> yong Zhu
>
[-- Attachment #2: Type: text/html, Size: 8102 bytes --]
^ permalink raw reply
* Re: Moving to BK
From: Randy.Dunlap @ 2006-04-01 6:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: davem, pasky, junio, linux-kernel, git
In-Reply-To: <Pine.LNX.4.64.0603312030060.27203@g5.osdl.org>
On Fri, 31 Mar 2006 20:30:40 -0800 (PST) Linus Torvalds wrote:
>
>
> On Fri, 31 Mar 2006, David S. Miller wrote:
> >
> > April 1st is upon us again.
>
> I really like the new slashdot look. "OMG!!! Ponies!!!"
Goes with the sandals and pony tails.
> I hope they keep it after Apr 1st.
---
~Randy
^ permalink raw reply
* Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
From: Miklos Szeredi @ 2006-04-01 6:39 UTC (permalink / raw)
To: trond.myklebust; +Cc: akpm, linux-fsdevel, linux-kernel
In-Reply-To: <1143865851.8116.30.camel@lade.trondhjem.org>
> OK. I see what you mean now. Do you agree with the following analysis?
>
> 1) We need 2 extra locks for the case where we
> upgrade/downgrade, a single existing lock and end up splitting
> it.
>
> 2) We need to use 1 extra lock in the case where we unlock and
> split a single existing lock.
>
> 3) We also need to use 1 extra lock in the case where there is
> no existing lock that is contiguous with the region to lock.
4) Also 1 extra lock needed if there's an existing lock that is
contiguous/overlapping with the new region but it's a different
type, and no existing locks are completely covered
> In all other cases, we resort to modifying existing locks instead of
> using new_fl/new_fl2.
>
> In cases (1) and (2) we do need to modify the existing lock. Since this
> is only done after we've set up the extra locks, we're safe.
And 4.
> Could I still suggest a couple of modifications to your patch? Firstly,
> we only need to test for 'added' once.
Like this?
+ /*
+ * The above code only modifies existing locks in case of
+ * merging or replacing. If new lock(s) need to be inserted
+ * all modifications are done bellow this, so it's safe yet to
+ * bail out.
+ */
+ error = -ENOLCK; /* "no luck" */
+ if (right && left == right && !new_fl2)
+ goto out;
+
error = 0;
if (!added) {
if (request->fl_type == F_UNLCK)
goto out;
+
+ if (!new_fl) {
+ error -ENOLCK;
+ goto out;
+ }
locks_copy_lock(new_fl, request);
locks_insert_lock(before, new_fl);
new_fl = NULL;
> Secondly, in cases (2) and (3), we can still complete the lock
> despite one of new_fl/new_fl2 failing to be allocated.
I think it's highly unlikely that one of the allocations would succeed
and the other fail. If the machine is OOM, then it will very likely
fail all allocations.
But even if that would happen it's not worth it to add more
complexity, just to squeeze the last drop out of the available memory
for file locking purposes.
Miklos
^ permalink raw reply
* Re: kernel panic
From: Samuel Díaz García @ 2006-04-01 6:21 UTC (permalink / raw)
To: Samuel Díaz García; +Cc: netfilter
In-Reply-To: <442CB08F.9000406@arcoscom.com>
Any idea at least?
Samuel Díaz García escribió:
> Iptables 1.3.5
> kernel 2.6.15.6
>
> Any help?
>
> Mar 30 00:31:01 fraile kernel: [17181150.312000] ip_nat_pptp version 3.0
> unloaded
> Mar 30 00:31:01 fraile kernel: [17181150.492000] ctnetlink:
> unregistering from nfnetlink.
> Mar 30 00:31:01 fraile kernel: [17181150.524000] ip_conntrack_pptp
> version 3.1 unloaded
> Mar 30 00:31:01 fraile kernel: [17181150.688000] ctnetlink v0.90:
> registering with nfnetlink.
> Mar 30 00:31:01 fraile kernel: [17181150.688000] Unable to handle kernel
> paging request at virtual address e0c76e54
> Mar 30 00:31:01 fraile kernel: [17181150.688000] printing eip:
> Mar 30 00:31:01 fraile kernel: [17181150.688000] c012a309
> Mar 30 00:31:01 fraile kernel: [17181150.688000] *pde = 1c9ac067
> Mar 30 00:31:01 fraile kernel: [17181150.688000] Oops: 0000 [#1]
> Mar 30 00:31:01 fraile kernel: [17181150.688000] Modules linked in:
> ip_conntrack_netlink ip_conntrack_netbios_ns ip_conntrack_irc
> ip_conntrack_h323 ip_conntrack_ftp ip_conntrack_amanda ipt_ipp2p
> parport_pc lp parport ipt_mac ipt_connlimit iptable_filter
> ipt_MASQUERADE iptable_nat ip_nat ipt_layer7 ipt_state ipt_MARK ipt_mark
> ipt_CONNMARK ip_conntrack nfnetlink ipt_comment iptable_mangle ip_tables
> police autofs4 it87 hwmon_vid hwmon eeprom i2c_isa bluetooth sunrpc
> dm_mod video thermal processor fan container button battery ac ohci_hcd
> shpchp i2c_sis630 i2c_sis96x i2c_core snd_intel8x0 snd_ac97_codec
> snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
> snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore
> snd_page_alloc sis900 8139too 3c59x mii floppy ext3 jbd aacraid sd_mod
> scsi_mod
> Mar 30 00:31:01 fraile kernel: [17181150.688000] CPU: 0
> Mar 30 00:31:01 fraile kernel: [17181150.688000] EIP:
> 0060:[<c012a309>] Tainted: GF VLI
> Mar 30 00:31:01 fraile kernel: [17181150.688000] EFLAGS: 00010282
> (2.6.15.6-ArcosCom)
> Mar 30 00:31:01 fraile kernel: [17181150.688000] EIP is at
> notifier_chain_register+0x19/0x50
> Mar 30 00:31:01 fraile kernel: [17181150.688000] eax: e0c76e4c ebx:
> e0c114c0 ecx: ffffffff edx: 00000000
> Mar 30 00:31:01 fraile kernel: [17181150.688000] esi: e0c40e4c edi:
> 0805e218 ebp: d174e000 esp: d174ff8c
> Mar 30 00:31:02 fraile kernel: [17181150.688000] ds: 007b es: 007b ss:
> 0068
> Mar 30 00:31:02 fraile kernel: [17181150.688000] Process modprobe (pid:
> 4432, threadinfo=d174e000 task=d363f570)
> Mar 30 00:31:02 fraile kernel: [17181150.688000] Stack: 00000000
> 0805e1f8 e0c2a05c e0c3f4c4 e0c2a0db e0c40f00 c0138a87 b7e9c008
> Mar 30 00:31:02 fraile kernel: [17181150.688000] 0805e1f8
> b7e9c008 0805e1f8 c0103055 b7e9c008 00034380 0805e1f8 0805e1f8
> Mar 30 00:31:02 fraile kernel: [17181150.688000] 0805e218
> bfd130b8 ffffffda 0000007b 0000007b 00000080 ffffe410 00000073
> Mar 30 00:31:02 fraile kernel: [17181150.688000] Call Trace:
> Mar 30 00:31:02 fraile kernel: [17181150.688000] [<e0c2a05c>]
> ctnetlink_init+0x5c/0xdb [ip_conntrack_netlink]
> Mar 30 00:31:02 fraile kernel: [17181150.688000] [<c0138a87>]
> sys_init_module+0xc7/0x1d0
> Mar 30 00:31:02 fraile kernel: [17181150.688000] [<c0103055>]
> syscall_call+0x7/0xb
> Mar 30 00:31:03 fraile kernel: [17181150.688000] Code: 00 e8 5c 54 24 00
> b8 fe fd ff ff c3 90 90 90 90 90 90 56 89 d6 53 89 c3 b8 18 3c 3d c0 e8
> 70 6b 24 00 8b 03 85 c0 74 1a 8b 56 08 <3b> 50 08 7f 12 89 f6 8d 58 04
> 8b 40 04 85 c0 74 06 39 50 08 7d
> Mar 30 00:31:03 fraile kernel: [17181150.688000] ip_conntrack_pptp
> version 3.1 loaded
> Mar 30 00:31:03 fraile kernel: [17181150.840000] ip_nat_pptp version 3.0
> loaded
> Mar 30 00:31:30 fraile kernel: [17181179.176000] ip_nat_pptp version 3.0
> unloaded
> Mar 30 00:31:30 fraile kernel: [17181179.388000] ip_conntrack_pptp
> version 3.1 unloaded
> Mar 30 00:31:30 fraile kernel: [17181179.556000] ip_conntrack_pptp
> version 3.1 loaded
>
>
--
Samuel Díaz García
^ permalink raw reply
* You can save up to 70% on Cialis Jamie
From: Orval @ 2006-04-01 7:16 UTC (permalink / raw)
To: linux-ppp
What we are referring to of course is the wonderful "blue pill" for erection difficulties everyone is talking about. We
not only carry it, but we do at 1.56 cents each.
Take a peek at:
http://defendantokuvu0bib2tbgo6ht66hbo6o.forwardsba.com/
Enjoy!
Sincerely,
Orval
Customer Service Team
freeboot you franklin me, champlain . invasive you adirondack me, arrack . cavort you turbojet me, aylesbury midscale denote scotch .
twiddle you dowel me, gladys . brazil you tomb me, neuroanotomy . backstop you damask me, hull libertarian . falstaff you eric me, raze crocus arrogant alienate .
http://defendantokuvu0bib2tbgo6ht66hbo6o.forwardsba.com/stereo
^ permalink raw reply
* Re: iptables: Unknown error 4294967295
From: Samuel Díaz García @ 2006-04-01 6:21 UTC (permalink / raw)
To: Samuel Díaz García; +Cc: netfilter
In-Reply-To: <442CAEC6.2040808@arcoscom.com>
Any idea at least?
Samuel Díaz García escribió:
> With:
> iptables 1.3.5
> linux 2.6.16.1 and 2.6.16-git8
> today's pom-ng
>
> I'm having problems with some matches:
> connlimit
> ipp2p 0.8.1_rc1
>
> When compiling, I can see many "signed//unsigned comparision warnings"
> (don't remember exactly the warning).
>
> In dmesg I see things as:
>
> Mar 31 05:18:04 fraile kernel: [17180340.932000] ip_tables: connlimit
> match: invalid size 0 != 16
> Mar 31 05:54:00 fraile kernel: [17182487.628000] ip_tables: ipp2p match:
> invalid size 0 != 8
> Mar 31 05:54:00 fraile kernel: [17182487.668000] ip_tables: layer7
> match: invalid size 0 != 8452
>
> Any help/patch/suggestion?
>
> Thanks
>
--
Samuel Díaz García
^ permalink raw reply
* Re: [patch 1/1] pc-speaker: add SND_SILENT
From: Vojtech Pavlik @ 2006-04-01 6:11 UTC (permalink / raw)
To: Edgar Toernig
Cc: Bodo Eggert, Joseph Fannin, Stas Sergeev, dtor_core, Linux kernel
In-Reply-To: <20060331230635.4a11e618.froese@gmx.de>
On Fri, Mar 31, 2006 at 11:06:35PM +0200, Edgar Toernig wrote:
> Vojtech Pavlik wrote:
> >
> > On Fri, Mar 31, 2006 at 01:07:34AM +0200, Edgar Toernig wrote:
> > >
> > > Latency is no problem. I'm using a userspace daemon to emulate
> > > the console beeper for about 6 months now and it work's very well.
> > >
> > > The daemon listens on /dev/input/eventX and when receiving a
> >
> > It needs to use /dev/input/uinput, not eventX. SND_TONE events are not
> > sent to the event devices.
>
> Well, I get them - stock 2.6.16.
Oh, yes, you're right. But still, this will only work if a speaker
device is present, so uinput is the right way to do it.
> > > Latency isn't noticable and memory footprint is small.
> >
> > It needs to have the sample ready in memory and not swapped out. Then
> > the latency will be OK, but if it needs to read it in from the disk, it
> > may be very noticeable.
>
> Yeah, if one ever cares one could mlock the samples, or (as I do) run
> without swap. Fixing the 'air' latency of 3ms/m is harder though *g*
--
Vojtech Pavlik
Director SuSE Labs
^ permalink raw reply
* Re: cannot get clean 2.4.20 kernel to compile
From: Willy Tarreau @ 2006-04-01 6:04 UTC (permalink / raw)
To: George P Nychis; +Cc: Robert Hancock, linux-kernel
In-Reply-To: <60485.128.237.233.65.1143825987.squirrel@128.237.233.65>
On Fri, Mar 31, 2006 at 12:26:27PM -0500, George P Nychis wrote:
> I see...
>
> here is my gcc version:
> gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
>
> Is it too new?
I think so. Either try with 2.95 or upgrade your kernel to 2.4.32.
Cheers,
Willy
>
> Thanks!
> George
>
>
> > George P Nychis wrote:
> >> Hi,
> >>
> >> I have downloaded the 2.4.20 kernel from ftp.kernel.org, have checked
> >> its sign, and no matter what I try I cannot get it to compile.
> >>
> >> I do a make mrproper, I then do make dep which is fine, but then i try
> >> "make bzImage modules modules_install", selecting all the defaults, and
> >> get an SMP header error: http://rafb.net/paste/results/QzIq7v86.html
> >>
> >> I then disable SMP support and get:
> >> http://rafb.net/paste/results/muYA9t12.html
> >>
> >> I even tried using my config from the 2.4.32 kernel which works
> >> perfectly fine, and I also get the sched errors.
> >
> > What gcc version? Some old kernels might not be buildable with newer
> > compilers.
> >
> > -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from
> > hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/
> >
> >
> >
>
>
> --
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" 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.tux.org/lkml/
^ permalink raw reply
* Re: fsck.reiser4 segfaults
From: Joachim Feise @ 2006-04-01 6:02 UTC (permalink / raw)
To: Michael Weissenbacher; +Cc: reiserfs-list
In-Reply-To: <442D8F45.7090403@dermichi.com>
Michael Weissenbacher wrote on 03/31/06 12:21:
> Hi,
>> reiserfsprogs and libaal are both 1.0.5. I'll give you the dmesg
>> output tommorow - I need to get a livecd with reiser4 patches - its
>> more difficult than I initially thought ;)
> I'm using RIPLinux, which has reiser4 support.
> http://www.tux.org/pub/people/kent-robotti/looplinux/rip/
Thanks for that info. I was looking for a boot disk with reiser4 for some time.
-Joe
^ permalink raw reply
* Undelivered Mail Returned to Sender
From: Mail Delivery System @ 2006-04-01 6:02 UTC (permalink / raw)
To: nfs
[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 634 bytes --]
This is the Postfix program at host maccarony.ntp.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The Postfix program
<asrg-rmx@lists.ntp.isc.org> (expanded from <asrg-rmx@ntp.org>): host
mail.ntp.isc.org[204.152.184.126] said: 550 5.1.1
<asrg-rmx@lists.ntp.isc.org>: Recipient address rejected: User unknown in
local recipient table (in reply to RCPT TO command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 518 bytes --]
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 5058 bytes --]
[-- Attachment #3.1.1: Type: text/plain, Size: 1486 bytes --]
Spam detection software, running on the system "maccarony.ntp.org", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
https://www.eecis.udel.edu/service/ for details.
Content preview: Important textfile! [...]
Content analysis details: (9.5 points, 4.1 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.1 X_PRIORITY_HIGH Sent with 'X-Priority' set to high
0.6 NO_REAL_NAME From: does not include a real name
0.9 MSGID_FROM_MTA_ID Message-Id for external message added locally
3.1 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
[81.119.17.227 listed in sbl-xbl.spamhaus.org]
1.2 RCVD_IN_SORBS_WEB RBL: SORBS: sender is a abuseable web server
[81.119.17.227 listed in dnsbl.sorbs.net]
1.4 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE
2.2 PRIORITY_NO_NAME Message has priority, but no user agent name
The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam. If you wish to view
it, it may be safer to save it to a file and open it with an editor.
[-- Attachment #3.1.2: Type: message/rfc822, Size: 2071 bytes --]
[-- Attachment #3.1.2.1.1: Type: text/plain, Size: 21 bytes --]
Important textfile!
[-- Attachment #3.1.2.1.2: Textfile_zip.DEFANGED-1688 --]
[-- Type: application/DEFANGED-1688, Size: 810 bytes --]
^ permalink raw reply
* turion MT32 insmod powernow-k8 failed.
From: drangon @ 2006-04-01 6:00 UTC (permalink / raw)
To: linux-kernel
Hi, I have a notebook with turion MT32, there is something wrong with
powernow-k8 module,
Apr 1 13:49:34 localhost kernel: powernow-k8: Found 1 AMD Athlon 64 /
Opteron processors (version 1.60.1)
Apr 1 13:49:34 localhost kernel: register performance failed: bad ACPI data
Apr 1 13:49:34 localhost kernel: found PSB header at 0xffff8100000fcd40
Apr 1 13:49:34 localhost kernel: table vers: 0x14
Apr 1 13:49:34 localhost kernel: flags: 0x0
Apr 1 13:49:34 localhost kernel: voltage stabilization time: 5(*20us)
Apr 1 13:49:34 localhost kernel: flags2: 0xe
Apr 1 13:49:34 localhost kernel: ramp voltage offset: 2
Apr 1 13:49:34 localhost kernel: isochronous relief time: 3
Apr 1 13:49:34 localhost kernel: maximum voltage step: 0 - 0x1
Apr 1 13:49:34 localhost kernel: numpst: 0x1
Apr 1 13:49:34 localhost kernel: plllocktime: 0x2 (units 1us)
Apr 1 13:49:34 localhost kernel: maxfid: 0xa
Apr 1 13:49:34 localhost kernel: maxvid: 0x16
Apr 1 13:49:34 localhost kernel: numpstates: 0x3
Apr 1 13:49:34 localhost kernel: zjg : 0 -- fid 0, vid 22
Apr 1 13:49:34 localhost kernel: zjg : 1 -- fid 8, vid 12
Apr 1 13:49:34 localhost kernel: zjg : 2 -- fid 10, vid 10
Apr 1 13:49:34 localhost kernel: powernow-k8: BIOS error: maxvid
exceeded with pstate 0, (vid 22, rvo 2, max 22))
[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.16-git19-zjg #3 Sat Apr 1 12:55:05 CST
2006 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 36
model name : AMD Turion(tm) 64 Mobile Technology MT-32
stepping : 2
cpu MHz : 1800.100
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm
bogomips : 3603.62
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
any suggestion ??
thank you!
^ permalink raw reply
* Re: Avoid excessive time spend on concurrent slab shrinking
From: Nathan Scott @ 2006-04-01 5:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: Christoph Lameter, nickpiggin, linux-mm, dgc
In-Reply-To: <20060331172518.40a5b03d.akpm@osdl.org>
On Fri, Mar 31, 2006 at 05:25:18PM -0800, Andrew Morton wrote:
> Christoph Lameter <clameter@sgi.com> wrote:
> ...
> It appears that we're being busy in xfs_iextract(), but it would be sad if
> the problem was really lock contention in xfs_iextract(), and we just
> happened to catch it when it was running.
>
> Or maybe xfs_iextract is just slow. So this is one thing we need to get to
> the bottom of (profiles might tell us).
I assume (profiles would be good to prove it) we are spending
time walking the hash bucket list there Christoph (while we're
holding the ch_lock spinlock on the hash bucket)? [CC'ing Dave
Chinner for any further comment, he's been looking at the chash
list for unrelated reasons recently..]
> Assuming that there's nothing we can do to improve the XFS situation, our
> options appear to be, in order of preference:
>
> a) move some/all of dispose_list() outside iprune_mutex.
>
> b) make iprune_mutex an rwlock, take it for reading around
> dispose_list(), for writing elsewhere.
>
> c) go back to single-threading shrink_slab (or just shrink_icache_memory())
>
> For this one we'd need to understand which observations prompted Nick
> to make shrinker_rwsem an rwsem?
>
> We also need to understand why this has become worse. Perhaps xfs_iextract
> got slower (cc's Nathan). Do you have any idea whenabout in kernel history
> this started happening?
Nothings changed in xfs_iextract for many years. Its quite possible
the simple hash with linked list buckets is no longer an effective
choice of algorithm here for the inode cluster hash... or perhaps the
hash table is too small... or... but anyway, I would not expect any
difference between kernel versions here (esp. the two vendor kernel
versions Christoph will be comparing - they'll be behaving exactly
the same way in this regard from XFS's POV as the code in question is
identical).
Its also quite possible some other performance bottleneck was moved
out of the way, and lock contention on the chashlist lock is now the
next biggest thing in line..
If its useful for experimenting, Christoph, you can easily tweak the
cluster hash size manually by dinking with xfs_iget.c::xfs_chash_init.
cheers.
--
Nathan
--
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
* Windows XP - very low price
From: Brian Cooper @ 2006-04-01 4:44 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
75% Off for All New Software. Microsoft, Adobe, Macromedia, Corel!
A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX
$149.95 Adobe Creative Suite Premium (5 CD)
$69.95 Quark Xpress 6 Passport Multilanguage
For full list of products go:
http://www.soft-for-us.com
Special offers:
$89.95 Windows XP Pro + Office XP Pro
$95.95 Adobe Photoshop 8.0 + Adobe Acrobat 6.0 Professional
$109.95 Dreamweaver MX 2004 + Flash MX 2004
__________________
To change, go here
[-- Attachment #2: Type: text/html, Size: 1345 bytes --]
^ permalink raw reply
* [lm-sensors] 2.6.16-rc5: unreasonable temperature reported by
From: Harald Dunkel @ 2006-04-01 5:44 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <44144A01.2050207@t-online.de>
Hi Jean,
Jean Delvare wrote:
>
> You'll have to search the available technical documentation for your
> system and/or ask Aopen for information. There's nothing we can do as
> long as we don't know what chip we are dealing with.
>
:
>
> I was about to say "No idea about this one", as it has very few
> registers and no noticeable patterns, but that "19 34" at 0x5d reminds
> me of the Fintek signature in my F71805F Super-I/O chip. Can you please
> search your motherboard for a Fintek chip, presumably small?
>
I found a small chip close to the socket for an additional fan.
16 pins. AFAICS it says F75387SG, but it was very hard to read
even with a looking glass. Esp. the "S" looks suspicious.
Using "fintek F75387SG" I found this on Google:
http://www.fintek.com.tw/files/productfiles/F75387_025P%20datasheet.pdf
BTW, my PC is an Aopen MZ915-M .
Hope this helps. Regards
Harri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060401/41d5029f/signature.bin
^ permalink raw reply
* Re: Default remote branch for local branch
From: Jakub Narebski @ 2006-04-01 5:38 UTC (permalink / raw)
To: git
In-Reply-To: <1143856098.3555.48.camel@dv>
Pavel Roskin wrote:
> I'm sorry, reading this mailing list is beyond my capabilities, so
> certain overlaps with other postings may be expected, unless I'm
> suggesting something totally off-base :-)
You might want to read "Efficient cloning" thread where
--use-separate-remote and --reference options were introduced:
http://marc.theaimsgroup.com/?l=git&m=114280442802681&w=2
http://www.gelato.unsw.edu.au/archives/git/0603/18113.html
http://thread.gmane.org/gmane.comp.version-control.git/17724
and which had discussion on similar subjects (somewhere).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: addendum: was Re: recovering data on a failed raid-0 installation
From: Mike Hardy @ 2006-04-01 5:27 UTC (permalink / raw)
To: Technomage, linux-raid
In-Reply-To: <200603312156.26176.technomage-hawke@cox.net>
Well, honestly I'm not really sure. I've never done this as I only use
the redundant raid levels, and when they're gone, things are a complete
hash and there's no hope. In fact, with raid-0 (striping, right? not
linear/append?) I believe you are in the same boat. Each large file will
have half its contents on the disk that died. So really, there's very
little hope.
Anyway, I'll try to give you pointers to what I would try anyway, with
as much detail as I can.
First, you just need to get the raid device up. It sounds like you are
actually already doing that, but who knows. If you have one drive but
not the other, you could make a sparse file that is the same size as the
disk you lost. I know this is possible, but haven't done it so you'll
have to see for yourself - I think there are examples in linux-raid
archives in reference to testing very large raid arrays. Loopback mount
the file as a device (losetup is he command to use here) and now you
have a "virtual" device of the same size as the drive you lost.
Recreate the raid array using the drive you have, and the new "virtual"
drive in place of the one you lost. It's probably best to do this with
non-persistent superblocks and just generally as read-only as possible
for data preservation on the drive you have.
So now you have a raid array.
For the filesystem, well, I don't know. That's a mess. I assume it's
possible to mount the filesystem with some degree of force (probably a
literally -force argument) as well as read-only. You may need to point
at a different superblock, who knows?
You just want to get the filesystem to mount somehow, any way you need
to, but hopefully in a read-only mode.
I would not even attempt to fsck it.
At this point, you have a mostly busted filesystem on a fairly broken
raid setup, but it might be possible to pull some data out of it, who
knows? You could pull what looks like data but is instead garbage to
though - if you don't have md5sums of the files you get (if you get any)
it'll be hard to tell without checking them all.
Honestly, that's as much as I can think of.
I know I'm just repeating myself when I say this, but raid is no
replacement for backups. They have different purposes, and backups are
no less necessary. I was sorry to hear you didn't have any, because that
probably seals the coffin on your data.
With regard to people recommending you get a pro. In this field (data
recovery) there are software guys (most of the people on this list) that
can do a lot while the platters are spinning and there are hardware guys
(the pros I think most people are talking about). They have physical
tools that can get data out of platters that wouldn't spin otherwise.
There's nothing the folks on the list can do really other than recommend
seeing someone (or shipping the drive to) one of those dudes. When you
get the replacement drive back from them with your data on it, then
we're back in software land and you may have half a chance.
That said, it sounded like you had already tried to fsck the filesystem
on this thing, so you may have hashed the remaining drive. It's hard to
say. Truly bleak though...
-Mike
Technomage wrote:
> mike.
>
> given the problem, I have a request.
>
>
> On Friday 31 March 2006 15:55, Mike Hardy wrote:
>
>>I can't imagine how to coax a filesystem to work when it's missing half
>>it's contents, but maybe a combination of forcing a start on the raid
>>and read-only FS mounts could make it hobble along.
>
>
> we will test any well laid out plan.
>
> lay out for us (from beginning to end) all the steps required, in your test.
> do not be afraid to detail the obvious. it is better that we be in good
> communication than to be working on assumptions. it will save you a lot of
> frustration trying to correct for our assumptions, if there are none.
>
> tmh
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: addendum: was Re: recovering data on a failed raid-0 installation
From: Technomage @ 2006-04-01 4:56 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <442DB358.1010402@h3c.com>
mike.
given the problem, I have a request.
On Friday 31 March 2006 15:55, Mike Hardy wrote:
>
> I can't imagine how to coax a filesystem to work when it's missing half
> it's contents, but maybe a combination of forcing a start on the raid
> and read-only FS mounts could make it hobble along.
we will test any well laid out plan.
lay out for us (from beginning to end) all the steps required, in your test.
do not be afraid to detail the obvious. it is better that we be in good
communication than to be working on assumptions. it will save you a lot of
frustration trying to correct for our assumptions, if there are none.
tmh
^ permalink raw reply
* cell compile fixes.
From: Dave Jones @ 2006-04-01 4:53 UTC (permalink / raw)
To: Linux Kernel
Missing include for __NR_syscalls, and missing sys_splice() that
causes build-time failure due to compile-time bounds check on spu_syscall_table.
Signed-off-by: Dave Jones <davej@redhat.com>
--- linux-2.6.16.noarch/arch/powerpc/platforms/cell/spufs/run.c~ 2006-03-30 15:48:17.000000000 -0500
+++ linux-2.6.16.noarch/arch/powerpc/platforms/cell/spufs/run.c 2006-03-30 15:48:25.000000000 -0500
@@ -2,6 +2,7 @@
#include <linux/ptrace.h>
#include <asm/spu.h>
+#include <asm/unistd.h>
#include "spufs.h"
--- linux-2.6.16.noarch/arch/powerpc/platforms/cell/spu_callbacks.c~ 2006-03-31 21:53:04.000000000 -0500
+++ linux-2.6.16.noarch/arch/powerpc/platforms/cell/spu_callbacks.c 2006-03-31 21:53:43.000000000 -0500
@@ -316,6 +316,7 @@ void *spu_syscall_table[] = {
[__NR_pselect6] sys_ni_syscall, /* sys_pselect */
[__NR_ppoll] sys_ni_syscall, /* sys_ppoll */
[__NR_unshare] sys_unshare,
+ [__NR_splice] sys_splice,
};
long spu_sys_callback(struct spu_syscall_block *s)
^ permalink raw reply
* [U-Boot-Users] Re: [Skyeye-developer] U-Boot on simulated at91rm9200/ep7312 boards (skyeye)
From: Rohit @ 2006-04-01 4:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <5d0d0e310603310952j76df9e6as24c3163a5007d650@mail.gmail.com>
On 3/31/06, Vijairaj <vijairaj.r@gmail.com> wrote:
>
>
> Please let me know if you are successful in booting the linux kernel.
> I have not looked in to it for a long time now, but I would love to
> hear of any developments.
>
Am presently away from work machine so can't tell you the exact lines but on
expanding the kernel it says something like the kernel machine ID is
different 0x000000fb whilst the mach ID expected is 0x0...106.
I suppose its because i am using the vmlinux image (from the skyeye suite)
which is generic i.e. for
at91rm9200 board while u-boot compiled is for AT91rm9200DK.
I shall try to compile the image and run on monday. In case if you have the
image please can you share the initrd and/or kernel image.
Best Regards,
rohit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060401/d9a4a5c0/attachment.htm
^ permalink raw reply
* Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
From: Trond Myklebust @ 2006-04-01 4:30 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: akpm, linux-fsdevel, linux-kernel
In-Reply-To: <E1FPPZK-0005qJ-00@dorka.pomaz.szeredi.hu>
[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]
On Fri, 2006-03-31 at 21:46 +0200, Miklos Szeredi wrote:
> > > In the first case no new locks are needed. In the second, no locks
> > > are modified prior to the check.
> >
> > Consider something like
> >
> > fcntl(SETLK, 0, 100)
> > fcntl(SETLK, 0, 100)
> > fcntl(SETLK, 0, 100)
>
> Huh? What is the type of lock in each case.
>
> But anyway your example is no good. If the new lock completely covers
> the previous one, then the old lock will simply be adjusted and no new
> lock is inserted.
Slip of the mailer. It posted when I wanted to cancel the mail (I had to
step out for an errand)...
OK. I see what you mean now. Do you agree with the following analysis?
1) We need 2 extra locks for the case where we
upgrade/downgrade, a single existing lock and end up splitting
it.
2) We need to use 1 extra lock in the case where we unlock and
split a single existing lock.
3) We also need to use 1 extra lock in the case where there is
no existing lock that is contiguous with the region to lock.
In all other cases, we resort to modifying existing locks instead of
using new_fl/new_fl2.
In cases (1) and (2) we do need to modify the existing lock. Since this
is only done after we've set up the extra locks, we're safe.
Could I still suggest a couple of modifications to your patch? Firstly,
we only need to test for 'added' once. Secondly, in cases (2) and (3),
we can still complete the lock despite one of new_fl/new_fl2 failing to
be allocated.
Cheers,
Trond
[-- Attachment #2: optimise_lock.dif --]
[-- Type: text/plain, Size: 1418 bytes --]
VFS,locks: locks: don't unnecessarily fail posix lock operations
---
fs/locks.c | 27 ++++++++++++++++++++-------
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 6ba3756..973c1d9 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -839,10 +839,6 @@ static int __posix_lock_file_conf(struct
if (request->fl_flags & FL_ACCESS)
goto out;
- error = -ENOLCK; /* "no luck" */
- if (!(new_fl && new_fl2))
- goto out;
-
/*
* We've allocated the new locks in advance, so there are no
* errors possible (and no blocking operations) from here on.
@@ -943,9 +939,25 @@ static int __posix_lock_file_conf(struct
before = &fl->fl_next;
}
- error = 0;
- if (!added) {
- if (request->fl_type == F_UNLCK)
+ if (request->fl_type == F_UNLCK) {
+ if (!added)
+ goto out;
+ if (!new_fl2 && right && left == right) {
+ new_fl2 = new_fl;
+ error = -ENOLCK;
+ if (!new_fl2)
+ goto out;
+ new_fl = NULL;
+ }
+ } else if (!added) {
+ error = -ENOLCK;
+ if (!new_fl) {
+ new_fl = new_fl2;
+ if (!new_fl)
+ goto out;
+ new_fl2 = NULL;
+ }
+ if (!new_fl2 && right && left == right)
goto out;
locks_copy_lock(new_fl, request);
locks_insert_lock(before, new_fl);
@@ -968,6 +980,7 @@ static int __posix_lock_file_conf(struct
left->fl_end = request->fl_start - 1;
locks_wake_up_blocks(left);
}
+ error = 0;
out:
unlock_kernel();
/*
^ permalink raw reply related
* Re: Moving to BK
From: Linus Torvalds @ 2006-04-01 4:30 UTC (permalink / raw)
To: David S. Miller; +Cc: pasky, junio, linux-kernel, git
In-Reply-To: <20060331.191416.108058500.davem@davemloft.net>
On Fri, 31 Mar 2006, David S. Miller wrote:
>
> April 1st is upon us again.
I really like the new slashdot look. "OMG!!! Ponies!!!"
I hope they keep it after Apr 1st.
Linus
^ permalink raw reply
* Re: ip_conntrack_ftp and non-standard ports
From: ludi @ 2006-04-01 4:28 UTC (permalink / raw)
To: netfilter
In-Reply-To: <9151ac2a0603301310q19746224yb8d43d26f31a31f6@mail.gmail.com>
I was also told to edit the source of module.
On 3/31/06, Filip Sneppe <filip.sneppe@gmail.com> wrote:
> On 3/30/06, Brian Capouch <brianc@palaver.net> wrote:
> > I hope this isn't a FAQ. I've looked around and googled around, and so
> > far, it seems from what I've found that such a thing can be done. What
> > I don't know is just how to tell iptables to do it.
> >
> This is done when loading the ip_conntrack_ftp and ip_nat_ftp kernel modules,
> eg.
>
> modprobe ip_conntracl_ftp ports=21,2021,3021
> modprobe ip_nat_ftp ports=21,2021,3021
>
> (see "modinfo ip_conntrack_ftp")
>
> > I hope someone might provide a pointer.
> >
> Hope this helps...
>
> Regards,
> Filip
>
>
^ permalink raw reply
* [KJ][Patch] fix kbuild warnings in savagefb.o
From: Darren Jenkins\ @ 2006-04-01 4:28 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]
G'day list
There are a few kbuild warnings in drivers/video/savage/
WARNING: drivers/video/savage/savagefb.o - Section mismatch: reference
to .init.data:savagefb_devices from .data between 'savagefb_driver' (at
offset 0x38) and 'savagefb_ops'
This one is the same false positive for the pci device id as before.
WARNING: drivers/video/savage/savagefb.o - Section mismatch: reference
to .init.text: from .exit.text after 'savagefb_remove' (at offset 0x6e)
WARNING: drivers/video/savage/savagefb.o - Section mismatch: reference
to .init.text: from .exit.text after 'savagefb_remove' (at offset 0x66)
These two are caused by savagefb_remove() which is marked __devexit
calling savage_unmap_mmio() and savage_unmap_video() which are marked as
__devinit.
WARNING: drivers/video/savage/savagefb.o - Section mismatch: reference
to .init.text: from .text between 'savagefb_resume' (at offset 0x232b)
and 'savage4_gpio_getscl'
This one is caused by savagefb_resume() which is un-annotated calling
savage_init_hw() which is marked as __devinit.
The patch below removes the __devinit annotations in all three cases.
Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
--- linux-2.6.16-git13/drivers/video/savage/savagefb_driver.c.orig 2006-04-01 14:12:39.000000000 +1100
+++ linux-2.6.16-git13/drivers/video/savage/savagefb_driver.c 2006-04-01 14:41:24.000000000 +1100
@@ -1545,7 +1545,7 @@ static int __devinit savage_map_mmio (st
return 0;
}
-static void __devinit savage_unmap_mmio (struct fb_info *info)
+static void savage_unmap_mmio (struct fb_info *info)
{
struct savagefb_par *par = info->par;
DBG ("savage_unmap_mmio");
@@ -1597,7 +1597,7 @@ static int __devinit savage_map_video (s
return 0;
}
-static void __devinit savage_unmap_video (struct fb_info *info)
+static void savage_unmap_video (struct fb_info *info)
{
struct savagefb_par *par = info->par;
@@ -1614,7 +1614,7 @@ static void __devinit savage_unmap_video
}
}
-static int __devinit savage_init_hw (struct savagefb_par *par)
+static int savage_init_hw (struct savagefb_par *par)
{
unsigned char config1, m, n, n1, n2, sr8, cr3f, cr66 = 0, tmp;
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ 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.