On Fri, Jun 24, 2011 at 12:34 AM, Mark Kettenis
wrote:
>> From: David Gwynne
>> Date: Thu, 23 Jun 2011 23:04:27 +1000
>>
>> you dawe,
>>
>> you could point both chips at the same function...
>
> Which shows how badly the chosen name for that function really is.
>
> I did some digging into the iss
On Thu, Jun 23, 2011 at 07:44:52PM -0700, Matthew Dempsky wrote:
> On Thu, Jun 23, 2011 at 7:29 PM, Kenneth R Westerback
> wrote:
> > I use neither but know people claim to be using one or the other,
> > but mostly raid(4), a.k.a. raidframe.
>
> Then it sounds like the solution is to subtly break
On Thu, Jun 23, 2011 at 7:29 PM, Kenneth R Westerback
wrote:
> I use neither but know people claim to be using one or the other,
> but mostly raid(4), a.k.a. raidframe.
Then it sounds like the solution is to subtly break them so we can
smoke out these claimed users! ;)
> In particular until soft
[+misc@, for users not subscribed to tech@]
On Thu, Jun 23, 2011 at 4:39 PM, Matthew Dempsky wrote:
> What should be done about ccd(4) and raid(4)? They both seem
> superseded in functionality by softraid(4), which also has much more
> developer interest and active development.
>
> Are there any
On Thu, Jun 23, 2011 at 04:39:19PM -0700, Matthew Dempsky wrote:
> What should be done about ccd(4) and raid(4)? They both seem
> superseded in functionality by softraid(4), which also has much more
> developer interest and active development.
>
> Are there any users still using ccd(4) and/or rai
What should be done about ccd(4) and raid(4)? They both seem
superseded in functionality by softraid(4), which also has much more
developer interest and active development.
Are there any users still using ccd(4) and/or raid(4) and unable to
upgrade to softraid(4)? Will anyone be up a creek if cc
On Fri, Apr 15, 2011 at 05:15:02PM +0100, Owain Ainsworth wrote:
> audit callers of pmap_clear_reference() and
> pmap_page_protect(,,VM_PROT_NONE) just before uvm_pagedeactivate noting
> the fact that freshly deactivated pages have their reference cleared in
> uvm_pagedeactivate already.
>
> first
Index: imsg_init.3
===
RCS file: /srv/radon/data/vcs/cvs/openbsd/src/lib/libutil/imsg_init.3,v
retrieving revision 1.4
diff -u -p -r1.4 imsg_init.3
--- imsg_init.3 5 Mar 2011 15:05:39 - 1.4
+++ imsg_init.3 23 Jun 2011 21:51:5
Hi,
this fix (adapted for PCI_PRODUCT_INTEL_82801I_AHCI_3) works on my Dell Studio
1550:
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x03: msi, AHCI 1.2
Regards,
Holger
> Hi
>
> A similar patch also prevents the hang on my Toshiba NB200 (with
> PCI_PRODUCT_INTEL_82801GBM_AHCI):
>
On Thu, Jun 23, 2011 at 07:05:25PM +0100, Owain Ainsworth wrote:
> How about this now?
>
> I've got some more important uvm diffs on the way I but would like to
> get the small ones out of my tree.
ok.
> On Tue, May 31, 2011 at 12:09:35AM +0100, Owain Ainsworth wrote:
> > No functional change si
On Thu, Jun 23, 2011 at 07:04:57PM +0100, Owain Ainsworth wrote:
> How about this now?
>
> On Tue, May 31, 2011 at 12:06:15AM +0100, Owain Ainsworth wrote:
> > ok?
Ok.
> > diff --git uvm/uvm_fault.c uvm/uvm_fault.c
> > index 76f0708..76429dc 100644
> > --- uvm/uvm_fault.c
> > +++ uvm/uvm_fault.c
On Thu, Jun 23, 2011 at 07:04:39PM +0100, Owain Ainsworth wrote:
> How about this now?
>
> On Tue, May 31, 2011 at 12:03:49AM +0100, Owain Ainsworth wrote:
> > It will handle an empty list just fine (there is a potential small
> > optimisation in there to avoid grabbing the fpageqlock if no pages
On Thu, Jun 23, 2011 at 07:04:48PM +0100, Owain Ainsworth wrote:
> How about this now?
>
> On Tue, May 31, 2011 at 12:05:04AM +0100, Owain Ainsworth wrote:
> > These functions used to be big and complicated, now they are glorified
> > wrappers around pmemrange and don't really need their own file
We fixed the kernel and now it should be no longer needed to insert
special multicast routes to allow sending of the multicast messages.
So this removes this code from kroute.c
please test (especially ripd)
--
:wq Claudio
Index: usr.sbin/ldpd/kroute.c
On 06/23/11 14:10, Andreas Bartelt wrote:
> Hello,
>
> I've noticed that there's a difference in behavior between nc(1) and GNU
> netcat when they talk to some daemon via TCP.
>
> The commands in the following example are basically the same:
>
> GNU netcat:
> netcat host 1234 < infile
>
> nc(1)
How about this now?
I've got some more important uvm diffs on the way I but would like to
get the small ones out of my tree.
-0-
On Tue, May 31, 2011 at 12:09:35AM +0100, Owain Ainsworth wrote:
> No functional change since aobjs should never hit this path. However, I
> introduced this diff when
How about this now?
On Tue, May 31, 2011 at 12:03:49AM +0100, Owain Ainsworth wrote:
> It will handle an empty list just fine (there is a potential small
> optimisation in there to avoid grabbing the fpageqlock if no pages need
> freeing but that is another diff)
>
> ok?
>
> diff --git uvm/uvm_k
How about this now?
On Tue, May 31, 2011 at 12:05:04AM +0100, Owain Ainsworth wrote:
> These functions used to be big and complicated, now they are glorified
> wrappers around pmemrange and don't really need their own file.
> Discussed with ariane@ a while ago.
>
> ok?
>
>
> diff --git conf/fi
How about this now?
On Tue, May 31, 2011 at 12:06:15AM +0100, Owain Ainsworth wrote:
> ok?
>
> diff --git uvm/uvm_fault.c uvm/uvm_fault.c
> index 76f0708..76429dc 100644
> --- uvm/uvm_fault.c
> +++ uvm/uvm_fault.c
> @@ -1936,11 +1936,7 @@ uvmfault_lookup(struct uvm_faultinfo *ufi, boolean_t
> wr
Diff below cleans up ahc(4) to use scsi_link::bus instead of
(mis)using scsi_link::scsibus.
If you have an ahc(4) (particularly a dual-channel one), I'd
appreciate test reports + dmesg. (As long as your devices still show
up, then it's working.)
Index: pci/ahc_pci.c
Hi Theo,
On 06/23/11 18:30, Theo de Raadt wrote:
...
I've noticed that some daemons behave
differently because of this, i.e., they won't return any data although
they are still allowed to send data.
Yes, those daemons are broken. Their select/poll loops are unaware
that writeability and reada
> I've noticed that there's a difference in behavior between nc(1) and GNU
> netcat when they talk to some daemon via TCP.
Note there are 3 netcats.
There was the original non-free one by Hobbit; he did not want to free it
and the code was quite a mish-mash.
Then there was our rewrite, which is
THIS MESSAGE IS FROM OUR TECHNICAL SUPPORT TEAM This message is sent
automatically by the computer. If you are receiving this message it means
that your email address has been queued for deactivation; this was as a
result of a continuous error script (code:505)receiving from this email
address. Cli
> Date: Thu, 23 Jun 2011 15:13:19 +0100
> From: Tom
>
> Hi
>
> A similar patch also prevents the hang on my Toshiba NB200 (with
> PCI_PRODUCT_INTEL_82801GBM_AHCI):
Ok, that's ICH9, where the docs the the port multiplier capability bit
is "reserved", confirming my strong suspicion that ICH9 is a
> From: David Gwynne
> Date: Thu, 23 Jun 2011 23:04:27 +1000
>
> you dawe,
>
> you could point both chips at the same function...
Which shows how badly the chosen name for that function really is.
I did some digging into the issue. If you look at 3400 docs, you'll
see that description of the
On Jun 23, 2011 23:04, David Gwynne wrote:
> you dawe,
>
> you could point both chips at the same function...
>
> dlg
sure, or would you prefer a name like ahci_intel_3400_1_4_attach?
Because the behaviour of 3400_2 and 3400_3 isn't known.
Index: ahci.c
=
Hi
A similar patch also prevents the hang on my Toshiba NB200 (with
PCI_PRODUCT_INTEL_82801GBM_AHCI):
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.180
diff -u -r1.180 ahci.c
--- ahci.c 14 Jun 2
you dawe,
you could point both chips at the same function...
dlg
On 23/06/2011, at 10:50 PM, Dawe wrote:
> Hi,
> the intel_3400_4 has the same issue as the intel_3400_1, ahci(4)
> hangs for 30 seconds on boot and resume. See also PR6630.
>
> Index: ahci.c
> =
On Wed, Jun 22, 2011 at 09:32:06PM +0200, Ariane van der Steldt wrote:
> On Tue, Jun 21, 2011 at 09:00:49PM +0200, Ariane van der Steldt wrote:
> > Bus_dmamem_map has a bug in its error path, where it frees the wrong
> > memory in the wrong way.
>
> After some discussion on icb, the comments and t
Hi,
the intel_3400_4 has the same issue as the intel_3400_1, ahci(4)
hangs for 30 seconds on boot and resume. See also PR6630.
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.180
diff -u -p -r1.180 ahci
LOL, I found a very funny picture and wanna know your opinion. Do u think this
picture is funny? Check the funny picture here:
http://funnycaser.webs.com/funny.htm
Hello,
I've noticed that there's a difference in behavior between nc(1) and GNU
netcat when they talk to some daemon via TCP.
The commands in the following example are basically the same:
GNU netcat:
netcat host 1234 < infile
nc(1):
nc host 1234 < infile
nc(1) sends a FIN segment after all
Hi,
I prepared update package xkeyboard-config to the latest release 2.3.
Patch available on http://koba.devio.us/distfiles/xkeyboard-config-2.3.diff
Tested on amd64.
--
Alexandr Shadchin
On Wed, Jun 22, 2011 at 11:55:20PM -0400, Brad wrote:
> Some fixes for re(4) chipset identification..
>
> - Rename 8168 revision entries to 8168B to reflect proper naming. From
> FreeBSD
> - Change 8168C_SPIN2 rev string to differentiate from the first rev.
> - Change 8169SBL ident string to als
* Janjaap van Velthooven [2011-06-22 21:37]:
> Just a vague idea for the moment;
>
> How aboot some mechanism that can do number lookups by name for disks?
like... fstab?
b6c15508a519d7ae.d /backup/ftp ffs rw,softdep,nodev,nosuid,noexec,noatime,noauto
--
Henning Brauer, h...@bsws.de, henn...@
fdisk(8)
Index: cmd.c
===
RCS file: /cvs/src/sbin/fdisk/cmd.c,v
retrieving revision 1.45
diff -u -p -r1.45 cmd.c
--- cmd.c 2 Jul 2010 02:54:09 - 1.45
+++ cmd.c 23 Jun 2011 06:50:46 -
@@ -348,12 +348,7 @@ Xwrit
36 matches
Mail list logo
