it's usual for the SCSI HBA to assign a targetID for itself.
For real SCSI - ie, non-SAS - it's actually necessary; the protocols
used for initiators and targets to speak with one another require a
line for the initiator as well as for the target. But the host is
usually ID 7.
Perhaps
don't run these commands inside /dev. library functions like
opendisk() will look for a file-path of the given name before
trying other names. that tends to make them use the block
dev when you want the char dev. eg, compare the ktrace for
newfs raid1d when you are in/not in /dev.
.mrg.
disklabel has a 2TB limit. that's true on all netbsd platforms.
to partition disks (real or otherwise) greater than 2TB you'll need
to use gpt(8) style partitions.
.mrg.
That could easily just be a code bug.
Back some years ago, I had occasion to (for work) set up a RAID of
something like six or seven TB. The individual drives were well under
the 2T limit, but even so I had some 32-bit bugs to fix. It's possible
there's another one in the code path that
It's possible there were other fixes required elsewhere in the tree,
but I don't think so.
ah, i see. there are a few other changes that you might want to
pick up, though i see that the majority of my changes were to make
it handle 2TB components, though the component label should also
have
one data point:
How large a number? I have very little basis for more than wild
guessing here; I rarely use sparse files, and even more rarely use
files sparse enough to make a significant difference from a quota point
of view.
Furthermore, those few uses are generally administrative,
I've found that I have two files on with same name
on several of my systems:
-r-xr-xr-x 2 root wheel 9256 Feb 2 16:54 /usr/sbin/chown
MD5 (/usr/sbin/chown) = fce92081f7907b04f0063e2f17f7f4e6
9256 Feb 2 16:54 /usr/sbin/chown
above seems to work as expected
-r-xr-xr-x 1
2) integrate PMP support to the atabus layer and support attaching more
than 2 devices to atabus.
i like this idea better, glad you went that route.
So I went with 2). This requires one major change to the ata layer:
struct ata_channel's ch_drive[] can be as large as 15, so it's better to
hi brian,
this should now be fixed on the netbsd-5 branch.
.mrg.
buh...@lothlorien.nfbcal.org (Brian Buhrow) wrote:
Hello. I've just encountered a strange problem with
raidframe under NetBSD-5.1 that I can't immediately explain.
this machine has been runing a raid set since 2007. The raid
set was originally constructed under NetBSD-3.
options DDB
try removing this one.
.mrg.
But that also means that you cannot copy an encrypted image to
a disk with different geometry. Someone has decide wether that's
worthwhile. In that case you can either build a blocking/deblocking
layer into cgd (ugly) or define that larger blocks are split into
individually encrypted
- usbd_bus_methods{} gains a get_lock() to enable the
host controller to provide a lock for the USB code.
if the lock isn't provided, old-style protection is
(partially) applied.
It is better if the USB driver can select the lock, like in FreeBSD. Else
1024 seems to small for me. How about 2048 (if not 4096)? Please make
it a #define somewhere (perhaps lwp.h?). When would the MD code override
the value?
I just followed the pattern with maxproc. I will bump the limit, but I
think that putting in the header is a mistake because things
hi folks.
i think the usbmp branch is ready to merge into -current. i've
built a couple of i386/amd64 GENERIC kernels for people to test
in the next week or so. i've also tested on sparc64 and powerpc
but if anyone else would like a kernel please let me know (or
checkout the jmcneill-usbmp
Whatever I try to do at this point, writing of the disklabel fails
(which I sort of expect, considering the discrepancies in the disklabel
outputs).
cgd.c has:
--
/*
* XXX here we should probe the underlying device. If we
*
I want to introduce a new function to sys/devices.h:
bool device_is_attached(device_t parent, cfdata_t cf);
this doesn't seem to match what the function actually does, which
is answer the question does this parent bus have a child attached
with the same driver name as in cf-cf_name.
that
Thor Lancelot Simon t...@panix.com wrote:
So what? If the memory is wanted for something else, it will be
reclaimed. How does this differ from any other filesystem? In
fact, this memory seems to me more likely to be effectively reclaimed
than that holding other vnodes, because
documentation does not mention this, but it seems that shutting down
cleanly might involve a flush of some kind. (I see that
pmf_system_suspend() does flush disk caches specifically before the
suspend, which sidesteps the issue a little)
I think the idea is that by the time
After the change in revision 1.156 of src/sys/dev/scsipi/scsipi_base.c to
assert that the kernel lock is held in scsipi_lookup_periph(), my SBus-based
sparc64 crashed with:
panic: kernel diagnostic assertion KERNEL_LOCKED_P() failed: file
/usr/src/sys/dev/scsipi/scsipi_base.c, line 221
On Fri, Mar 09, 2012 at 02:49:43PM +, Julian Coleman wrote:
Hi,
After the change in revision 1.156 of src/sys/dev/scsipi/scsipi_base.c to
assert that the kernel lock is held in scsipi_lookup_periph(), my SBus-based
sparc64 crashed with:
panic: kernel diagnostic assertion
David Holland dholland-t...@netbsd.org wrote:
On Mon, Jan 16, 2012 at 10:28:57PM +0100, Manuel Bouyer wrote:
I consider lfs second-class citizen at this time and if forward
compat if broken for the lfs module on the branch it's probably not
a big deal).
I don't consider that
isn't this caused by uninitialised pointer accesses in sys_ktrace()?
if (KTROP(SCARG(uap, ops)) != KTROP_CLEAR) {
... code to init fp ...
}
error = ktrace_common(l, SCARG(uap, ops), SCARG(uap, facs),
SCARG(uap, pid), fp);
if (fp != NULL) {
ignore the previous:
either way fp is garbage on the stack at this point if not
KTROP_CLEAR. the uses in ktrace_common() won't fault, but the
fd_abort()s will (which is where we see the panic).
can people see if this works ok if fp is initialised to NULL?
(either at the top of the
i seem to recall that we found some missing close calls inside
raidframe that are now fixed in -current, and possibly pulled
upto netbsd-5 and probably not netbsd-4?
i think you do need a reboot, unfortunately.
.mrg.
On Fri, Dec 02, 2011 at 01:51:42AM +0900, Izumi Tsutsui wrote:
Anyway, currently our udl(4) doesn't require such allocation,
It's also a problem for radeondrm (no USB involved).
freebsd implemented a different fix for this, which i think involved
using the VM system directly and supporting
On reboot, the file systems were marked clean; but savecore tried to fetch
the dump I had aborted (I interrupted that).
Shouldn't the dump be marked valid only after it was fully done?
it's better to attempt to save a partial dump in the case that
the system hung half way thru the dumping.
Here's a proposal for a sysctl(7) knob to easily allow non-superusers to
set the CPU affinity of processes and threads they own:
security.secmodel.suser.usersetaffinity
(ressembles the one already existing to allow for user mounts)
Would it be acceptable to modify current
The current code seems to allow to change uvmexp.ncolors at
configure() - cpu_attach() - uvm_page_recolor(). I think changing
uvmexp.ncolors after uvm_init() is too late, and allocating such
fundamental data like page freelist buckets that late is best to
avoid.
How about:
- determine
On Mon, Sep 26, 2011 at 09:17:43PM +0300, Jukka Ruohonen wrote:
On Mon, Sep 26, 2011 at 05:51:13PM +, Christos Zoulas wrote:
Why advertise uint16_t, are we trying to save memory? I would just do
them uint32_t...
While few things are certain in computing, I don't think we
gpio(4) isn't in any release, right? you're almost certainly the
major user so far, i don't think there's much benefit to backwards
comapt code here.
.mrg.
What a boolean gives you is: simplicity and a bias towards performance
(which I think should be the priority on NetBSD generally). This is traded
for minor power consumption increase and possibly heat. Should be fine for
servers and most laptop users.
this is not fine for my laptop.
i tend
I've been wondering if it was possible to change the pty(4) internal
buffer size, as I noticed that ppp tunnels cannot use a larger frame
size. Because of this, it seems that the optimal MTU be 856, which is
so small that context switches become the bottleneck.
It would be nice to for
Subject says it all. Anyone objects?
Motivation behind:
- we already have strlen(3), so having strnlen(3) in kernel is somehow
natural.
- avoids things like [1] (there are probably other possible consumers in
kernel).
if it is in the kernel, it's strnlen(9) :-)
seems fine to me.
In article 20110829003259.913f014a...@mail.netbsd.org,
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
hi,
I'd like to apply the attached patch.
It implements two things:
- chroot(2)-ed process is given new kauth_cred_t with reference count
equal to 1.
can you find a way to
ยท Setting the process resource limits is not allowed.
Lowering should still be possible.
i'm not sure the point of this one, really. if this configuration
is desired, then set rlimit max == cur to whatever you want before
starting the chroot. ie, this can be done already with
I painstakingly got each PCI release to build, and that's what it took
for alpha. *shrug*
i really appreciate that you did all this work. it is the right way.
I can just let alpha break until somebody figures out why it wanted
machine/bus.h in userland to begin with.
i also think this is
FWIW, i much prefer using DDB_ONPANIC=2 than setting the enter command
to bt. unfortunately only options(4) meantions this, not sysctl(4)
or ddb(4).
.mrg.
On Wed, Jun 15, 2011 at 09:30:17PM +0200, Manuel Bouyer wrote:
I fear so, sadly. I think DIAGNOSTIC should be back in x86 GENERIC
kernels on HEAD (this can be switched off in release branches)
Contrary, I think every viable debug option (DIAGNOSTIC + LOCKDEBUG at
least) should be enabled
Unless anyone objects, I will merge rmind-uvmplock branch. The technical
objectives of the branch are described here:
[ .. ]
i will be very glad when this change is merged!
thanks for all your work on it.
.mrg.
Despite the level of System time, I was able to run a complete
build.sh -j48 release in less than 45 minutes. And afterwards, I
was able to build a complete new kernel in 44 seconds. (I guess
most all of the source directory was cached somewhere in that 32GB
of RAM!)
*Shrug* that's
i have a system where raidframe accesses are severely restricted
and present a 2-20x performance loss.
to followup on this:
the problem has disappeared from normal raidframe accesses even with
the same kernels that were previously not working great.
i've since had the disk i was using both
Anyone have ideas on why the INSTALL kernel works fine, but the
GENERIC kernel does not? They look to be the same to me in so far as the
INSTALL config includes the GENERIC config. I rebuilt the GENERIC kernel
to turn off MTRR support, as the INSTALL kernel does, but that
On Tue, Apr 26, 2011 at 08:00:04PM +1000, matthew green wrote:
hmm, i thought i had sent this for pullup. can you see if
dev/raidframe/rf_netbsdkintf.c 1.284 helps?
This helped, I could reattach the disk and reconstruct.
Unfortunably I had to go back to the 1y old kernel because recent
hi folks.
i have a system where raidframe accesses are severely restricted
and present a 2-20x performance loss.
after various tests i have confirmed the problem is in raidframe
itself and that appears to be a wakeup() that does not cause the
related ltsleep() to wakeup until the next tick.
Martin Husemann mar...@duskware.de writes:
What do you think? Better naming suggestion also welcome.
IMHO, root autoconfiguration should be limited to take effect only when
booted device is included in its components. Since the current behavior
is suprising and inconvinient (I
i believe before this patch is commited (if it is) *every* driver
you have changed needs to be tested on a system that needed the
change for the device to work, or at least a very good attempt
has been made to find the device. if you can't find users with
said devices, then i wouldn't hold back.
On Wed, Apr 06, 2011 at 02:07:18AM +0300, Vladimir Kirillov wrote:
Hello, tech-kern@!
I really wanted a show proc command to avoid looking up process
information by running ps with all flags and intensive scrolling.
The show proc output mostly combines the outputs of all switches
Here's the diff for ddb(4):
- reuse the common code for stack traces
(and rely on sizeof(long) in most cases)
- use db_read_* api to be usable from crash(8).
great. i love re-sharing code. i just have a few comments.
thanks for doing this, and for adm64 crash.
On Thu, Mar 31, 2011 at 03:53:22PM -0400, Thor Lancelot Simon wrote:
2) About 200 xfers/sec (about 3MB/sec worth) is still going on
to the SSD for much of the build process. It's all writes.
All build directories (obj, dest, tools, release) are on
a separate
:-) The trouble is large parts of the kernel are migrated to kmem
already and having too interfaces and two allocators is something that
needs cleanup. The malloc-type statistics would need a major overhaul
if they are the way to go, what I doubt, as the essentially make
malloc single
Ignoring the free page allocator which abuses pg-offset, is there any
reason we cannot fold pg-flags into pg-offset? The lower PAGE_SHIFT bits
of pg-offset are not used.
is this about making vm_page smaller? if so, and it works, i guess that
seems fine, but how many bits do you want to use?
On Sun, Apr 03, 2011 at 07:35:04PM +1000, matthew green wrote:
Ignoring the free page allocator which abuses pg-offset, is there any
reason we cannot fold pg-flags into pg-offset? The lower PAGE_SHIFT
bits
of pg-offset are not used.
is this about making vm_page smaller
On Sat, Mar 19, 2011 at 09:40:18AM +1100, matthew green wrote:
this seems reasonable to me. why don't you stick it in libutil?
As this is needed to get netatalk to build again on HEAD, I'd like
to commit this in the next few days.
this is what i'm talking about about using
this patch seems to fix my problem. i've moved the call to fix
the label into rf_reasonable_label() itself, right before the
valid return, and made the fix up also fix the partitionSizeHi.
greg, what do you think?
Looks good to me. Go for it.
oh, it isn't. supposed to use
this seems reasonable to me. why don't you stick it in libutil?
As this is needed to get netatalk to build again on HEAD, I'd like
to commit this in the next few days.
this is what i'm talking about about using a different name for
the new syscall that takes totally different arguments.
is
Agreed. So let's keep quotactl(2) ... it's fine and is working.
i'd rather use quotactl2() than the old name.
other ideas:
quotapropctl()
quotaprop()
and i'd be ok with quotapctl() as well.
I still don't understand what problem we're trying to fix. OK, by
The scheme sys/dev/bus/wsdisplay_bus.[ch] where bus
is pci, sbus, etc. is fine with me.
When trying to do that I uncovered a problem with doing it:
In sys/dev/pci/files.pci I can't do 'wsdisplay pci'
because 'wsdisplay' is defined in sys/dev/wscons/files.wscons.
So I will leave it
Benefits I've thought about:
- The kmem pools use pool_caches therefor scalability will be much
better as the old malloc has a single lock for all access, the pools
have one each with a per cpu cache layer.
- The old malloc only returns oversized allocations back to the kmem
layer but
i like this look of this much better than prior patches. thanks
for doing this properly.
i just have one minor suggestion. i don't see the point in the two
new files with one function proto and a 5 line function. can you
please move them into wsdisplay.c and wsdisplayvar.h? thanks.
.mrg.
On Tue, Jan 18, 2011 at 11:22:33AM +0100, Christoph Egger wrote:
i like this look of this much better than prior patches. thanks
for doing this properly.
i just have one minor suggestion. i don't see the point in the
two new files with one function proto and a 5 line
Hello NetBSD folks,
I just ran into this issue today (variable length unsigned long
used in chflags syscalls) on FreeBSD and I wasn't sure if anyone was
aware of the issue yet on NetBSD [1] . Just wanted to let you guys
know so that maybe the 3 major BSDs could get on the same page as
It would be nice if ELF kernel image holds modules_enabled value in
note section which allows LIBSA to tell whether the target kernel is
MODULAR or not.
modular kernels don't *have* to have modules loaded via the boot
loader. so what i think you're really after is a flag that says
we want to
hi.
my devbox just crashed with this:
panic: kernel diagnostic assertion pg == NULL || pg == PGO_DONTCARE failed:
file /usr/src/sys/miscfs/genfs/genfs_io.c, line 243
but i don't understand the KASSERT(). it seems that this sequence
of events will always trigger:
nfound =
FWIW, there *are* sparc implementations of the mutex vector
functions, but we had to disable them because of lossage we
we not able to (yet) track down. they mostly work, so may
be useful for at least reading.
.mrg.
- hppa seems to have a mutex implemented without cas. is it broken?
FWIW, the sparc implementation is only broken on SMP.
.mrg.
I'll merge this in a few days. I believe I've given enough reasonings
to back this design in various places.
do not do this.
this code has currently seen review that was less than favourable
and you have not given much consideration to the flaws. unless
this actual patch is given review and
hi folks.
the following patch let's me access both 512 byte and 4K
sector disks at the same time, as long as they are in
separate raids. the existing rf code assumes/enforces
this part, i just made it support other sets concurrently.
the main change is moving the parity bitmap to the sector
- AMAP_SHARED itself is a fine concept; it's used by shared memory.
sys/kern/sysv_shm.c:
452 error = uvm_map(vm-vm_map, attach_va, size, uobj, 0,
0,
453 UVM_MAPFLAG(prot, prot, UVM_INH_SHARE,
UVM_ADV_RANDOM, flags));
(Note UVM_INH_SHARE
- For highly tuned, XIP'ed systems, programs should be designed to
avoid .data, because they're COW'ed to page cache sooner or later.
why is this a problem?
if the data is needed, and it will be written to, then these pages
will be allocated (COW'd) eventually, and the same
- For highly tuned, XIP'ed systems, programs should be designed to
avoid .data, because they're COW'ed to page cache sooner or later.
why is this a problem?
if the data is needed, and it will be written to, then these pages
will be allocated (COW'd) eventually,
+if (c_label-version == RF_COMPONENT_LABEL_VERSION)
+c_label-partitionSizeHi =
+raidPtr-Disks[fcol].partitionSize 32;
All these tests should really be:
+ if (c_label-version RF_COMPONENT_LABEL_VERSION_1)
+ c_label-partitionSizeHi =
+
On Oct 22, 7:26am, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: [patch] - add support for 2TB raid devices
|
| +if (c_label-version == RF_COMPONENT_LABEL_VERSION)
| +c_label-partitionSizeHi =
| +raidPtr-Disks[fcol
hi folks.
i recently tried running raidframe on a pair of 3TB disks. when
attached via USB, the reported 4K sectors and were signifcantly
more work required to get going, but when attached directly to
the sata ports, they come up support 512 sector accesses.
with a lot of help from mlelstv@
...and I'm not convinced of this, primarily because (from a practical
point of view) X is unavoidable and unfixable, whereas modules are
neither.
actually, with DRM (and KMS) i believe we will be able to run the
X server as non-root.
.mrg.
I have 5.1_RC3/i386 running quite happily on a couple of slightly
older Dell PowerEdge r610's. I went to install it on a new R610 and
the system dies immediately
[...]
Intel 686-class, 2660Hz 0x20bc2
Fatal protection fault in supervisor mode
Stopped in pid 0.1(system) at
thanks for looking into this problem. we need a solution.
would device_lookup() and device_lookup_private() take a reference
on this count automatically? or maybe some new API that does it,
to avoid the need to audit every driver at once.
On Jan 6, 1:19am, matthew green wrote:
}
} would device_lookup() and device_lookup_private() take a reference
} on this count automatically? or maybe some new API that does it,
} to avoid the need to audit every driver at once.
What would release the reference in that case
hello,
netbsd crashs at Dell M710. You can have a look at the screeshot at
http://6bone.informatik.uni-leipzig.de/Dell-M710.bmp
Any Ideas what could be the problem?
can you type bt at the db prompt and show us the backtrace?
.mrg.
On Wed, Aug 11, 2010 at 11:49:10PM +0200, Jean-Yves Migeon wrote:
[..]
I will commit the attached patch on Saturday, unless someone objects.
[..]
Index: external/bsd/drm/dist/shared-core/radeon_cs.c
===
RCS file:
On Thu, 12 Aug 2010, Bernd Ernesti wrote:
if (dev_priv == NULL) {
DRM_ERROR(called with no initialization\n);
- DRM_SPINUNLOCK(dev_priv-cs.cs_mutex);
...
Hmm, you didn't mention why you are doing that in your initial mail.
Use of pointer after determining it's
On Mon, Aug 09, 2010 at 02:38:32AM -0400, Matthew Mondor wrote:
On Sun, 8 Aug 2010 17:23:23 -0700 (PDT)
Paul Goyette p...@whooppee.com wrote:
Should these be changed? Are there any adverse effects from having a
wmesg longer than 8 characters?
It seems to me that the exporter
According to the mutex(9) man page:
mutex_owned(mtx)
For adaptive mutexes, return non-zero if the current LWP holds
the mutex. ...
this is an incomplete reading of the manual page, and you can not
use mutex_owned() the way you are trying to (regardless of what
pooka
On Mon Aug 02 2010 at 16:30:03 +1000, matthew green wrote:
this is an incomplete reading of the manual page, and you can not
use mutex_owned() the way you are trying to (regardless of what
pooka posted.) you can't even using it in various forms of assertions
safely. from the man page
On Mon, 26 Jul 2010, matthew green wrote:
it seems to me the root problem is that module_mutex is held while
calling into the module startup routines.
thus, the right solution is to remove this requirement.
Yes, that's what is needed.
But it sounds a lot simpler than it is.
oh
On Thu, Jul 01, 2010 at 01:32:47AM +0200, Rhialto wrote:
On Wed 30 Jun 2010 at 08:57:44 -0700, Chuck Silvers wrote:
- the assembler apparently now uses a different opcode for reloading
%gs
than it used to, so the check for this instruction in INTRFASTEXIT
being the
At 1:03 Uhr +0900 26.6.2010, Izumi Tsutsui wrote:
The patch fixes the panic on my ss20 - an UP kernel makes it to multi-user,
and I can log in, and access the machine from the network. There's pppoe,
netatalk and samba breakage, but that may be due to version skew with the
netbsd-4
Somebody should fix the driver so that zshard() does not call
device_lookup_private(). It seems entirely unnecessary.
i don't see how without simply revert the change to convert to
using device_lookup_private().
the interrupt comes in and you have to look at all of the zs
devices on the
Somebody should fix the driver so that zshard() does not call
device_lookup_private(). It seems entirely unnecessary.
There is a dumb hack in sun3 derived zs driver.
All zs devices on sun machines have the same interrupt sources
so ancient zs drivers tried to reduce overhead on
It looks multiple interrupt handlers against the same interrupt level
are properly queued and handled in sparc/intr.c:ih_insert(), so
no need to prepare own queue in zs.c.
this patch must be tested on a system with both serial usage and
zskbd/zsms working, and if possible, on a system with
It looks multiple interrupt handlers against the same interrupt level
are properly queued and handled in sparc/intr.c:ih_insert(), so
no need to prepare own queue in zs.c.
this patch must be tested on a system with both serial usage and
zskbd/zsms working, and if possible, on a system
On Sat, Jun 05, 2010 at 01:02:12PM +1000, matthew green wrote:
- fix obreak() to honor RLIMIT_AS as well as RLIMIT_DATA.
this will affect native processes as well as linux ones,
but it seems appropriate.
if you're going to do this, you may as well just make RLIMIT_AS
- fix obreak() to honor RLIMIT_AS as well as RLIMIT_DATA.
this will affect native processes as well as linux ones,
but it seems appropriate.
if you're going to do this, you may as well just make RLIMIT_AS and
RLIMIT_DATA refer to the same thing (and make that RLIMIT_AS.)
when
I'm working on porting the OpenAFS client over to NetBSD 5.0.2. In
trying to compile the LKM for it, the files cpu.h and intr.h in
/usr/include/x86/ are included. These headers include additional
headers. The problem, however, is that a couple of the headers they
try to include are not in
what's PAT? could you add a comment to pat.c, explaining what this
code is for?
please make sure that pat_init() definition is in column 1 (aka KNF).
(not sure the point of pat.h, i'd just merge it it into cpu.h or
similar.)
.mrg.
FWIW, i just noticed this in subr_extent.c. gross, but what you want :-)
.mrg.
#include uvm/uvm_extern.h
#define KMEM_IS_RUNNING (kmem_map != NULL)
(2) what linux kernel version do we want to claim to be in uname?
it would be good for this to be at least as recent as the
kernel matching what we choose in (1). but it would good to avoid
going too wild with this, to keep the amount of new emul code
that's
In my tree, I've changed bus_space_tag_t from an integer type to a
pointer to a struct. Now, some debugging code in MI drivers will not
compile because it tries to printf bus_space_tag_t's using the format
%x.
I don't see the use of printing a bus_space_tag_t, so I am changing
On Sat, Apr 10, 2010 at 12:49:48PM +1000, matthew green wrote:
would you try this variant? it handles the case where MEXTMALLOC()
would fail to allocate external storage, and seems to work on my
iwn(4). i'll commit this if you confirm it works.
Is there any reason
On Fri April 9 2010 20:49:48 matthew green wrote:
would you try this variant? it handles the case where MEXTMALLOC()
would fail to allocate external storage, and seems to work on my
iwn(4). i'll commit this if you confirm it works.
I can confirm that the patch works
301 - 400 of 414 matches
Mail list logo
