Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
On Fri, Jun 24, 2011 at 12:34 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: From: David Gwynne l...@animata.net 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 AHCI_REG_CAP registers says that the BIOS should set the BIOS should set the AHCI_REG_CAP_SPM bit (the port multiplier capability bit) to 0. The documented default value for this register has the bit set to 1 though. Also, the revision history mentions the removal of port multiplier functionality. I guess what's happened here is that Intel tried to support port multipliers, discovered that it didn't work properly and told BIOS developers to disable it. Unsurprisingly some BIOS developers didn't get the memo and left the bit in its default state. So it's obvious that all 3400/5-Series chipset AHCI variants are affected, and we should apply the same fix to all of them. I looked at other chipsets as well, and the documentation strongly suggests that the older (ICH) chipsets have the same issue. The specified default value has the bit turned on, but the bit is either undocumented or is documented as set to 0 by the BIOS. And even the new 6-series PCH seems to be affected. On the other hand Intel still claims that port multipliers are supported by some of the ICH10 variants. I'm really curious wether there are any machines where port multipliers work on the Intel AHCI controller ports. If not, perhaps we should blacklist all of the Intel chipsets. The only mentions I can see on Intel's website of port multipliers being supported are on overview pages for 3400 and ICH9, and when you look at the data sheets for those, the revision history says it was removed. For all the other chipsets I looked at, they don't mention it on the overview page and say port multipliers not supported in the data sheet. I'm not sure what to make of the default values for the AHCI capabilities register - several of the other bits don't seem to match up with the descriptions, even in cases where they haven't withdrawn support for a feature. So, I think we should blacklist at least 3400 and ICH9, since that's where the BIOS is likely to set things up wrong. I'll post a diff that does this shortly. Blacklisting all Intel devices seems a bit much, but on the other hand Intel doesn't seem at all interested in supporting port multipliers. Where are you seeing references to port multiplier support in ICH10? I don't think I've seen anything like that. Arguably, the chosen fix (the AHCI_F_IPMS_PROBE quirk) isn't quite right. It is clear that (some) Intel AHCI variants simply don't support port multipliers, so we should just skip the probe. On the other hand, as long as this quirk works, we don't need to introduce another one. The quirk was introduced for ATI SB600 and SB700 AHCIs where port multipliers do actually work, so I don't really like using it to fix devices where they don't. I just didn't realise that's what I was doing until now. thanks, -jonathan
Re: Future of ccd(4) and raid(4)?
On 2011-06-24 01.39, 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. Never used ccd(4) so can't comment on that, but RAIDframe (raid(4)) has a lot of functionality that is not yet implemented in softraid(4). It has (for good reason given that softraid(4) is in the works) received little developer attention and has a few bugs and other shortcomings. I've tried in the past to address those I've run up against, but I know there are probably more problems with it than is worth fixing (in particular I've had problems with very large disks and raid sets) so I have high hopes for softraid(4) in the future. 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 ccd(4)/raid(4) were removed? I for one will be up the worst of creeks if raid(4) was removed, that would force me to stay on 4.9 until softraid(4) have evolved enough (which I have no doubt will happen eventually), so please please don't remove raid(4) just yet. :-) My wish list for softraid(4) to enable me to say goodbye to RAIDframe is something like this (not exhaustive and in no particular order): - More complete RAID support overall, including - ability to tune stripe sizes - parity initialization / rebuilding, preferrably with background mode - Hot spare support - Better handling of stripe (disk) failures - Better handling of recovery from failed stripes (ability to hot plug a replacement disk and rebuild on the spot for example) - Full stripe writes for perfomance - Usable status reporting - Stripe on stripe (on stripe ...) support to be able to build RAID 0+1 and RAID50 sets, as well as crypto on raid (this may work now, haven't tried lately) - RAID6 support (way way back in priority though) - Bootable/rootable raid sets (I know this is close now) - More consistent sdn unit allocation (perhaps this is achievable with DUID, I haven't had time to explore that yet) - Probably other small features as well, that I'll probably think of the moment I've sent this mail off... Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny LC6fgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: Move uvm_pglist* to uvm_page.c
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.
Discussed with ariane@ a while ago.
ok?
OK.
diff --git conf/files conf/files
index 02da860..017e5f9 100644
--- conf/files
+++ conf/files
@@ -1007,7 +1007,6 @@ file uvm/uvm_object.c
file uvm/uvm_page.c
file uvm/uvm_pager.c
file uvm/uvm_pdaemon.c
-file uvm/uvm_pglist.c
file uvm/uvm_pmemrange.c
file uvm/uvm_stat.c
file uvm/uvm_swap.c
diff --git uvm/uvm_page.c uvm/uvm_page.c
index 10ef7d1..ed8e6d4 100644
--- uvm/uvm_page.c
+++ uvm/uvm_page.c
@@ -806,6 +806,81 @@ uvm_pagealloc_pg(struct vm_page *pg, struct uvm_object
*obj, voff_t off,
}
/*
+ * uvm_pglistalloc: allocate a list of pages
+ *
+ * = allocated pages are placed at the tail of rlist. rlist is
+ *assumed to be properly initialized by caller.
+ * = returns 0 on success or errno on failure
+ * = doesn't take into account clean non-busy pages on inactive list
+ * that could be used(?)
+ * = params:
+ * sizethe size of the allocation, rounded to page size.
+ * low the low address of the allowed allocation range.
+ * highthe high address of the allowed allocation range.
+ * alignment memory must be aligned to this power-of-two boundary.
+ * boundaryno segment in the allocation may cross this
+ * power-of-two boundary (relative to zero).
+ * = flags:
+ * UVM_PLA_NOWAIT fail if allocation fails
+ * UVM_PLA_WAITOK wait for memory to become avail
+ * UVM_PLA_ZEROreturn zeroed memory
+ */
+int
+uvm_pglistalloc(psize_t size, paddr_t low, paddr_t high, paddr_t alignment,
+paddr_t boundary, struct pglist *rlist, int nsegs, int flags)
+{
+ UVMHIST_FUNC(uvm_pglistalloc); UVMHIST_CALLED(pghist);
+
+ KASSERT((alignment (alignment - 1)) == 0);
+ KASSERT((boundary (boundary - 1)) == 0);
+ KASSERT(!(flags UVM_PLA_WAITOK) ^ !(flags UVM_PLA_NOWAIT));
+
+ if (size == 0)
+ return (EINVAL);
+
+ if ((high PAGE_MASK) != PAGE_MASK) {
+ printf(uvm_pglistalloc: Upper boundary 0x%lx
+ not on pagemask.\n, (unsigned long)high);
+ }
+
+ /*
+* Our allocations are always page granularity, so our alignment
+* must be, too.
+*/
+ if (alignment PAGE_SIZE)
+ alignment = PAGE_SIZE;
+
+ low = atop(roundup(low, alignment));
+ /*
+* high + 1 may result in overflow, in which case high becomes 0x0,
+* which is the 'don't care' value.
+* The only requirement in that case is that low is also 0x0, or the
+* lowhigh assert will fail.
+*/
+ high = atop(high + 1);
+ size = atop(round_page(size));
+ alignment = atop(alignment);
+ if (boundary PAGE_SIZE boundary != 0)
+ boundary = PAGE_SIZE;
+ boundary = atop(boundary);
+
+ return uvm_pmr_getpages(size, low, high, alignment, boundary, nsegs,
+ flags, rlist);
+}
+
+/*
+ * uvm_pglistfree: free a list of pages
+ *
+ * = pages should already be unmapped
+ */
+void
+uvm_pglistfree(struct pglist *list)
+{
+ UVMHIST_FUNC(uvm_pglistfree); UVMHIST_CALLED(pghist);
+ uvm_pmr_freepageq(list);
+}
+
+/*
* interface used by the buffer cache to allocate a buffer at a time.
* The pages are allocated wired in DMA accessible memory
*/
diff --git uvm/uvm_pglist.c uvm/uvm_pglist.c
deleted file mode 100644
index d29fb14..000
--- uvm/uvm_pglist.c
+++ /dev/null
@@ -1,136 +0,0 @@
-/* $OpenBSD$ */
-/* $NetBSD: uvm_pglist.c,v 1.13 2001/02/18 21:19:08 chs Exp $ */
-
-/*-
- * Copyright (c) 1997 The NetBSD Foundation, Inc.
- * All rights reserved.
- *
- * This code is derived from software contributed to The NetBSD Foundation
- * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
- * NASA Ames Research Center.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND
CONTRIBUTORS
- * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED
- * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
From: Jonathan Matthew Date: Fri, 24 Jun 2011 16:49:50 +1000 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 AHCI_REG_CAP registers says that the BIOS should set the BIOS should set the AHCI_REG_CAP_SPM bit (the port multiplier capability bit) to 0. The documented default value for this register has the bit set to 1 though. Also, the revision history mentions the removal of port multiplier functionality. I guess what's happened here is that Intel tried to support port multipliers, discovered that it didn't work properly and told BIOS developers to disable it. Unsurprisingly some BIOS developers didn't get the memo and left the bit in its default state. So it's obvious that all 3400/5-Series chipset AHCI variants are affected, and we should apply the same fix to all of them. I looked at other chipsets as well, and the documentation strongly suggests that the older (ICH) chipsets have the same issue. The specified default value has the bit turned on, but the bit is either undocumented or is documented as set to 0 by the BIOS. And even the new 6-series PCH seems to be affected. On the other hand Intel still claims that port multipliers are supported by some of the ICH10 variants. I'm really curious wether there are any machines where port multipliers work on the Intel AHCI controller ports. If not, perhaps we should blacklist all of the Intel chipsets. The only mentions I can see on Intel's website of port multipliers being supported are on overview pages for 3400 and ICH9, and when you look at the data sheets for those, the revision history says it was removed. For all the other chipsets I looked at, they don't mention it on the overview page and say port multipliers not supported in the data sheet. I'm not sure what to make of the default values for the AHCI capabilities register - several of the other bits don't seem to match up with the descriptions, even in cases where they haven't withdrawn support for a feature. But the default value, and the language describing the SPM bit really is very similar across ICH7, ICH8, ICH10, 3400/5-Series and C200/6-Series. For all these chipsets the datasheet says that the BIOS should set the bit to 0. That is no accident. It is the same piece of VHDL (or whatever Intel uses to design the logic) that's simply evolving a bit from generation to generation. But the port multiplier functionality stays non-functional. People have reported issues with ICH7, ICH9 and 3400. So really, all ICH and PCH variants are affected and we should quirk them all. So, I think we should blacklist at least 3400 and ICH9, since that's where the BIOS is likely to set things up wrong. I'll post a diff that does this shortly. Blacklisting all Intel devices seems a bit much, but on the other hand Intel doesn't seem at all interested in supporting port multipliers. Where are you seeing references to port multiplier support in ICH10? I don't think I've seen anything like that. The following page: http://www.intel.com/design/chipsets/matrixstorage_sb.htm mentions that the ICH10R, ICH9R and ICH9DO have port multiplier support. That's probably just the marketing people being out of touch tough, since at least for the ICH10R the data sheet explicitly says that port multipliers are not supported. Arguably, the chosen fix (the AHCI_F_IPMS_PROBE quirk) isn't quite right. It is clear that (some) Intel AHCI variants simply don't support port multipliers, so we should just skip the probe. On the other hand, as long as this quirk works, we don't need to introduce another one. The quirk was introduced for ATI SB600 and SB700 AHCIs where port multipliers do actually work, so I don't really like using it to fix devices where they don't. I just didn't realise that's what I was doing until now. Hmm, well, the SB600 databook says that port multipliers are supported on ASIC revision A13 and above. So I wonder if the workaround is only necessary for the older revisions whithout port multiplier support.
This week in healthy living + Like us to win a Whole Foods gift card!
If you have problems viewing this message,View the Web or Mobile Version https://www.magnetmail.net/actions/email_web_version.cfm?recipient_id=7382285 72message_id=1413942user_id=LEBHAR_CVERSION=TEXTgroup_id=658916jobid=586 6550 -- (http://www.omronwebstore.com/products/hellawellas=omrhellawebmacss) -- HellaWella for the week of June 23, 2011 Forward to a Friend (https://www.magnetmail.net/Actions/new_forward_message.cfm?message_id=141394 2FTFId=1112user_id=LEBHAR_Crecipient_id=738228572) Like Us of Facebook (http://www.facebook.com/LiveHellaWella?sk=app_160628063962200#!/LiveHellaWel la?sk=app_160628063962200 ) DEALS (http://www.hellawella.com/category/all/deals) 7 Get tested: Walgreens offers FREE HIV tests through June 24 (http://www.hellawella.com/get-a-life-saving-hiv-test-at-walgreens/482) Walgreens is getting a head start on HIV testing with FREE rapid oral HIV tests at select locations through June 24. One-in-5 Americans don't know their status. Be one of the other four. Read more to find a testing location near you. Read more ... (http://www.hellawella.com/get-a-life-saving-hiv-test-at-walgreens/482) PRIMP (http://www.hellawella.com/category/all/primp)7 Shedding some light on sun protection (http://www.hellawella.com/shedding-some-light-on-sun-protection/502) SPF. UVA. UVB. What does it all mean?! Protecting your skin from the sun's harmful rays can sometimes feel like a game of Scrabble. But HellaWella's here to help you make sense of it all with some tips from sun care experts. Read more ... (http://www.hellawella.com/shedding-some-light-on-sun-protection/502) HEALTH (http://www.hellawella.com/category/all/health) 7 A new maintenance program aims to give men a health tune-up they can relate to (http://www.hellawella.com/guys-give-your-bodies-a-tune-up/476) Men, if you know your mechanic better than your doctor, it might be a good idea to check out T-Talk Tune-Up, a new site from Men's Health Network and drug maker Abbott designed to help men care as much about their health maintenance as they do their cars. Also inside: the five health tests every man should know about. Read more ... (http://www.hellawella.com/guys-give-your-bodies-a-tune-up/476) SWEAT (http://www.hellawella.com/category/all/sweat) 7 For a total body workout, it's all about finding your stroke (http://www.hellawella.com/dive-into-exercise/459) Bust out those bathing suits and swimming trunks! Swimming is a great way to exercise, and here are some of HellaWella's tips to help you incorporate it into your fitness plan. Read more ... (http://www.hellawella.com/dive-into-exercise/459) DEALS (http://www.hellawella.com/category/all/deals) 7 Don't flake on protection, get 25% off on a hot new suncreen brand (http://www.hellawella.com/think-sunscreen-think-savings/422) Get smart about sun care and save with Thinksport and Thinkbaby Livestrong sunscreen products. Read more ... (http://www.hellawella.com/think-sunscreen-think-savings/422) (http://www.hellawella.com/fly-greener-skies/435) GREEN (http://www.hellawella.com/category/all/green) 7 Are the friendly skies finally getting green-friendly? (http://www.hellawella.com/fly-greener-skies/435) There are greener ways to travel than hopping on an airplane, but let's face it, sometimes a horse and buggy just won't cut it. Fortunately, several airlines have taken the challenge of going green to heart and are doing their part to make flying a more sustainable way to travel. Read more ... (http://www.hellawella.com/fly-greener-skies/435)
Re: [Update] xenocara/xkeyboard-config
On Thu, Jun 23, 2011 at 06:08:47PM +0600, Alexandr Shadchin wrote: 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 No problems here on amd64 with sun type 6. -- Cheers, Jasper Capable, generous men do not create victims, they nurture them.
Re: ahci.c: intel_3400_4 needs same flags as intel_3400_1 to avoid a 30 sec boot hang
On Fri, Jun 24, 2011 at 9:35 PM, Mark Kettenis mark.kette...@xs4all.nl
wrote:
From: Jonathan Matthew
Date: Fri, 24 Jun 2011 16:49:50 +1000
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 AHCI_REG_CAP registers says that the BIOS
should set the BIOS should set the AHCI_REG_CAP_SPM bit (the port
multiplier capability bit) to 0. The documented default value for
this register has the bit set to 1 though. Also, the revision history
mentions the removal of port multiplier functionality. I guess what's
happened here is that Intel tried to support port multipliers,
discovered that it didn't work properly and told BIOS developers to
disable it. Unsurprisingly some BIOS developers didn't get the memo
and left the bit in its default state. So it's obvious that all
3400/5-Series chipset AHCI variants are affected, and we should apply
the same fix to all of them.
I looked at other chipsets as well, and the documentation strongly
suggests that the older (ICH) chipsets have the same issue. The
specified default value has the bit turned on, but the bit is either
undocumented or is documented as set to 0 by the BIOS. And even the
new 6-series PCH seems to be affected. On the other hand Intel still
claims that port multipliers are supported by some of the ICH10
variants. I'm really curious wether there are any machines where port
multipliers work on the Intel AHCI controller ports. If not, perhaps
we should blacklist all of the Intel chipsets.
The only mentions I can see on Intel's website of port multipliers
being supported are on overview pages for 3400 and ICH9, and when you
look at the data sheets for those, the revision history says it was
removed. For all the other chipsets I looked at, they don't mention it
on the overview page and say port multipliers not supported in the
data sheet. I'm not sure what to make of the default values for the
AHCI capabilities register - several of the other bits don't seem to
match up with the descriptions, even in cases where they haven't
withdrawn support for a feature.
But the default value, and the language describing the SPM bit really
is very similar across ICH7, ICH8, ICH10, 3400/5-Series and
C200/6-Series. For all these chipsets the datasheet says that the
BIOS should set the bit to 0. That is no accident. It is the same
piece of VHDL (or whatever Intel uses to design the logic) that's
simply evolving a bit from generation to generation. But the port
multiplier functionality stays non-functional. People have reported
issues with ICH7, ICH9 and 3400. So really, all ICH and PCH variants
are affected and we should quirk them all.
Good point, I agree. Easier to list them all now rather than waiting
for people to report them one by one.
Arguably, the chosen fix (the AHCI_F_IPMS_PROBE quirk) isn't quite
right. It is clear that (some) Intel AHCI variants simply don't
support port multipliers, so we should just skip the probe. On the
other hand, as long as this quirk works, we don't need to introduce
another one.
The quirk was introduced for ATI SB600 and SB700 AHCIs where port
multipliers do actually work, so I don't really like using it to fix
devices where they don't. I just didn't realise that's what I was
doing until now.
Hmm, well, the SB600 databook says that port multipliers are supported
on ASIC revision A13 and above. So I wonder if the workaround is only
necessary for the older revisions whithout port multiplier support.
I'll have to check this on Monday when I can get at the machine, but
I'm pretty sure I've had a port multiplier working on an SB600 that
required this quirk.
untested diff follows.
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 2011 10:40:14 - 1.180
+++ ahci.c 24 Jun 2011 12:43:53 -
@@ -418,6 +418,7 @@
#define AHCI_F_NO_NCQ (10)
#define AHCI_F_IGN_FR (11)
#define AHCI_F_IPMS_PROBE (12) /* IPMS on failed PMP probe
*/
+#define AHCI_F_NO_PMP (13) /* ignore PMP capability */
u_int sc_ncmds;
@@ -456,7 +457,7 @@
struct pci_attach_args *);
intahci_amd_hudson2_attach(struct ahci_softc *,
struct pci_attach_args *);
-intahci_intel_3400_1_attach(struct ahci_softc *,
+intahci_intel_attach(struct ahci_softc *,
struct pci_attach_args *);
intahci_nvidia_mcp_attach(struct ahci_softc *,
struct pci_attach_args *);
@@ -480,8 +481,42 @@
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SBX00_SATA_6,
Re: Future of ccd(4) and raid(4)?
On Friday 24 June 2011, Matthew Dempsky wrote: On Thu, Jun 23, 2011 at 7:29 PM, Kenneth R Westerback kwesterb...@rogers.com 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 softraid can reliably be booted from, I think raid(4) will be useful to have. I don't think you can boot from raid(4) either though? grep -i raid /usr/src/sys/arch/sparc64/stand/bootblk/* No idea if it actually works or if you can on other architectures... -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand
Re: Fix running ldd against multiple shared objects
On Fri, Apr 8, 2011 at 6:17 PM, Matthew Dempsky matt...@dempsky.org wrote: Diff below fixes ldd /usr/lib/*.so.* so that it outputs more than just the first shared object's dependencies, like the behavior from ldd /usr/bin/*. The issue is that dlopen(f, RTLD_TRACE) calls exit() after it's done. I looked into changing this to properly cleanup and return, but figured it was easier to just fork first like we already do for exec()-based tracing. ok? Is anybody interested in getting this diff in? Thanks
Re: Future of ccd(4) and raid(4)?
Matthew Dempsky matt...@dempsky.org 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. Is softraid ready at all? I thought it was experimental, under construction, incomplete, don't-use-unless-you-want-to-contribute code. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Future of ccd(4) and raid(4)?
On Fri, Jun 24, 2011 at 03:38:48PM +, Christian Weisgerber wrote: Matthew Dempsky matt...@dempsky.org 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. Is softraid ready at all? I thought it was experimental, under construction, incomplete, don't-use-unless-you-want-to-contribute code. I'm pretty sure it left that state some time ago, in all fairness I'd sooner trust softraid for my data then ccd/raidframe. softraid needs some of the bells and whistles raidframe has as Benny already pointed out, but I think ccd(4) ought to go the way of the Dodo.
my friends
i know you will love this =)) www.elitewealthsecret.com thank me later blessings, Mike
Re: wol for xl(4)
On 06/22/2011 03:15 PM, Stefan Sperling wrote:
On Wed, Jun 22, 2011 at 11:43:27AM +, Thomas Gerlach wrote:
...crap! sorry, something went wrong here. :(
I'm not sure what you mean went wrong.
But in an effort to try to wrap this up, can you please try -current
with just this diff and report back if that works? Thanks!
Index: xl.c
===
RCS file: /cvs/src/sys/dev/ic/xl.c,v
retrieving revision 1.101
diff -u -p -r1.101 xl.c
--- xl.c 17 Apr 2011 20:52:43 - 1.101
+++ xl.c 22 Jun 2011 13:10:24 -
@@ -2373,9 +2373,13 @@ xl_stop(struct xl_softc *sc)
xl_freetxrx(sc);
#ifndef SMALL_KERNEL
- /* Call upper layer WOL power routine if WOL is enabled. */
- if ((sc-xl_flags XL_FLAG_WOL) sc-wol_power)
+ /* Re-enable RX and call upper layer WOL power routine
+ * if WOL is enabled. */
+ if ((sc-xl_flags XL_FLAG_WOL) sc-wol_power) {
+ CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_ENABLE);
+ xl_wait(sc);
sc-wol_power(sc-wol_power_arg);
+ }
#endif
}
hi
for now i managed to solve the problem by adding the following line to
/etc/rc.local:
ifconfig if wol
instead of using /etc/hostname.if to enable wol.
this successfully enables wol during startup, without any error messages
(assuming the patches from stefan are applied, of course).
cheers,
thomas
Re: Future of ccd(4) and raid(4)?
On Saturday 25 June 2011, Christian Weisgerber wrote: Matthew Dempsky matt...@dempsky.org 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. Is softraid ready at all? I thought it was experimental, under construction, incomplete, don't-use-unless-you-want-to-contribute code. The RAID 0, RAID 1 and crypto disciplines have been stable for the better part of the last two years (RAID 1 got rebuild and hotspare support about 2 years ago). The remaining disciplines (RAID 4, RAID 5, RAID 6, AOE) are certainly experimental and incomplete. -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand
Re: Future of ccd(4) and raid(4)?
On Friday 24 June 2011, Benny Lofgren wrote: On 2011-06-24 01.39, 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. Never used ccd(4) so can't comment on that, but RAIDframe (raid(4)) has a lot of functionality that is not yet implemented in softraid(4). It has (for good reason given that softraid(4) is in the works) received little developer attention and has a few bugs and other shortcomings. I've tried in the past to address those I've run up against, but I know there are probably more problems with it than is worth fixing (in particular I've had problems with very large disks and raid sets) so I have high hopes for softraid(4) in the future. 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 ccd(4)/raid(4) were removed? I for one will be up the worst of creeks if raid(4) was removed, that would force me to stay on 4.9 until softraid(4) have evolved enough (which I have no doubt will happen eventually), so please please don't remove raid(4) just yet. :-) My wish list for softraid(4) to enable me to say goodbye to RAIDframe is something like this (not exhaustive and in no particular order): - More complete RAID support overall, including - ability to tune stripe sizes Easily doable - not sure about the benefit since MAXPHYS should be close to optimal. - parity initialization / rebuilding, preferrably with background mode The RAID 4/5/6 disciplines are still lacking this (scrubbing), along with other things. - Hot spare support We've had that for almost 2 years. - Better handling of stripe (disk) failures Not sure what you're wanting here. - Better handling of recovery from failed stripes (ability to hot plug a replacement disk and rebuild on the spot for example) We've had that for almost 2 years as well. - Full stripe writes for perfomance Meaning? - Usable status reporting Are you talking about error messages, or bioctl(8) output? - Stripe on stripe (on stripe ...) support to be able to build RAID 0+1 and RAID50 sets, as well as crypto on raid (this may work now, haven't tried lately) This works, although is not officially supported at this stage. - RAID6 support (way way back in priority though) - Bootable/rootable raid sets (I know this is close now) - More consistent sdn unit allocation (perhaps this is achievable with DUID, I haven't had time to explore that yet) sd(4) unit allocation will always be inconsistent and unpredicatable - DUIDs will let you avoid this entirely. - Probably other small features as well, that I'll probably think of the moment I've sent this mail off... Regards, /Benny -- Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone. -- Ayn Rand
Re: nc(1), GNU netcat and FIN segments after all data has been sent
On 06/23/11 21:05, Christopher Zimmermann wrote: ... Maybe you can force nc(1) not to send a FIN segment by using something like this: cat infile - |nc host 1234 This works. Thanks!
Re: sdn allocation and umass(4)
On 06/24/11 18:46, Joel Sing wrote: On Friday 24 June 2011, Benny Lofgren wrote: - More consistent sdn unit allocation (perhaps this is achievable with DUID, I haven't had time to explore that yet) sd(4) unit allocation will always be inconsistent and unpredicatable - DUIDs will let you avoid this entirely. By the way, is there a way to mount umass(4) devices without looking at dmesg for the number of the sdn device?
Re: sdn allocation and umass(4)
* Christopher Zimmermann madro...@zakweb.de [110624 21:24]: On 06/24/11 18:46, Joel Sing wrote: On Friday 24 June 2011, Benny Lofgren wrote: - More consistent sdn unit allocation (perhaps this is achievable with DUID, I haven't had time to explore that yet) sd(4) unit allocation will always be inconsistent and unpredicatable - DUIDs will let you avoid this entirely. By the way, is there a way to mount umass(4) devices without looking at dmesg for the number of the sdn device? hotplugd(8) -- Alexander Polakov | plhk.ru
Re: sdn allocation and umass(4)
On 06/24/11 19:40, Alexander Polakov wrote: * Christopher Zimmermann madro...@zakweb.de [110624 21:24]: On 06/24/11 18:46, Joel Sing wrote: On Friday 24 June 2011, Benny Lofgren wrote: - More consistent sdn unit allocation (perhaps this is achievable with DUID, I haven't had time to explore that yet) sd(4) unit allocation will always be inconsistent and unpredicatable - DUIDs will let you avoid this entirely. By the way, is there a way to mount umass(4) devices without looking at dmesg for the number of the sdn device? hotplugd(8) That's not what I thought about, but even better - hotplugd the BSD way. Just great :) Thanks!
Re: sdn allocation and umass(4)
On Fri, Jun 24, 2011 at 08:34:15PM +0200, Christopher Zimmermann wrote: By the way, is there a way to mount umass(4) devices without looking at dmesg for the number of the sdn device? hotplugd(8) That's not what I thought about, but even better - hotplugd the BSD way. If you just need the disknames without looking at the dmesg output, just use sysctl hw.disknames ;-) Ciao, Kili
Re: counting zero-length matches in sed(1)
On Sat, Jun 18, 2011 at 08:16:05PM -0600, Ingo Schwarze wrote:
When a regular expression has zero-length matches in a string,
both sed(1) global replacement (/g) and replacement of numbered
instances (e.g. /2) are broken. This is not even limited to sed -E.
Both Otto's patch and my own refactoring patch on misc@ only address
global replacement and leave numbered instances broken.
Already now, code in the three parts of the switch statement
is rather repetitive, and by fixing the numbered instances case,
code duplication would become much worse. Thus, i propose
the following full rewrite of the whole switch statement.
This is a bit scary because...
Well, sed(1) is not exactly the tool we want to break.
Hence, a test suite is included.
Both my patch and GNU sed(1) pass the test suite.
Our -current sed fails 43 of these tests, quite a few of them
in spectacular ways, like
$ echo | sed 's/$/x/2' # expect
x
$ echo aaa | sed 's/a*/x/2' # expect aaa
aaax
$ echo abc | sed -E 's/a|$/x/g' # expect xbcx
x
$ echo abc | sed -E 's/()/x/2'# expect axbc
xabc
$ echo abc | sed -E 's/()/x/42' # expect abc
xabc
One common source of confusion on misc@ was that Perl allows
empty matches right after other matches, like in:
$ perl -Mstrict -we '$_ = abc; s/b|()/x/g; print $_\n;'
xaxxcx
$ perl -Mstrict -we '$_ = a; s/^|a|$/x/g; print $_\n;'
xxx
I consider that broken behaviour in Perl. For example, think about
the case of a =~ /^|a/. The branch /^/ matches at 0, length 0.
The branch /a/ matches at 0, length 1. So by greediness, the latter
ought to prevail. But then, we have already consumed the character,
and there is no way to get a second match. Hence,
$ echo abc | sed -E 's/b|()/x/g'
xaxcx
$ echo a | sed -E 's/^|a|$/x/g'
x
Comments?
Ingo
Couple of comments;
- re_off is no longer used.
- slen is unsigned. We need to be 100% sure it cannot wrap. ATM I'm
not completely convinced the empty match case is safe. If you look at
the FreeBSD code, it appears the case match[0].rm_eo == slen can
happen, and in that case slen will wrap. They fixed it by making slen
a signed type (regoff_t). See rev 1.30 and 1.31 in their tree.
When I run the regress test suite from FreeBSD (in
src/tools/regression/usr.bin/sed) I see a couple of failures with our
sed. I did not have time yet to look if these failures have anything
with this diff and if we should incoorporate them.
-Otto
Index: usr.bin/sed/process.c
===
RCS file: /cvs/src/usr.bin/sed/process.c,v
retrieving revision 1.15
diff -u -p -r1.15 process.c
--- usr.bin/sed/process.c 27 Oct 2009 23:59:43 - 1.15
+++ usr.bin/sed/process.c 19 Jun 2011 01:47:19 -
@@ -333,60 +333,47 @@ substitute(struct s_command *cp)
n = cp-u.s-n;
lastempty = 1;
- switch (n) {
- case 0: /* Global */
- do {
- if (lastempty || match[0].rm_so != match[0].rm_eo) {
- /* Locate start of replaced string. */
- re_off = match[0].rm_so;
- /* Copy leading retained string. */
- cspace(SS, s, re_off, APPEND);
- /* Add in regular expression. */
- regsub(SS, s, cp-u.s-new);
- }
+ do {
+ /* Copy the leading retained string. */
+ if (n = 1 match[0].rm_so)
+ cspace(SS, s, match[0].rm_so, APPEND);
- /* Move past this match. */
- if (match[0].rm_so != match[0].rm_eo) {
- s += match[0].rm_eo;
- slen -= match[0].rm_eo;
- lastempty = 0;
+ /* Skip zero-length matches right after other matches. */
+ if (lastempty || match[0].rm_so ||
+ match[0].rm_so != match[0].rm_eo) {
+ if (n = 1) {
+ /* Want this match: append replacement. */
+ regsub(SS, s, cp-u.s-new);
+ if (n == 1)
+ n = -1;
} else {
- if (match[0].rm_so == 0)
- cspace(SS, s, match[0].rm_so + 1,
- APPEND);
- else
- cspace(SS, s + match[0].rm_so, 1,
- APPEND);
- s += match[0].rm_so + 1;
- slen -= match[0].rm_so + 1;
- lastempty = 1;
+ /* Want a later match: append
Re: Future of ccd(4) and raid(4)?
On 2011-06-24 18.46, Joel Sing wrote: On Friday 24 June 2011, Benny Lofgren wrote: On 2011-06-24 01.39, 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. Never used ccd(4) so can't comment on that, but RAIDframe (raid(4)) has a lot of functionality that is not yet implemented in softraid(4). It has (for good reason given that softraid(4) is in the works) received little developer attention and has a few bugs and other shortcomings. I've tried in the past to address those I've run up against, but I know there are probably more problems with it than is worth fixing (in particular I've had problems with very large disks and raid sets) so I have high hopes for softraid(4) in the future. 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 ccd(4)/raid(4) were removed? I for one will be up the worst of creeks if raid(4) was removed, that would force me to stay on 4.9 until softraid(4) have evolved enough (which I have no doubt will happen eventually), so please please don't remove raid(4) just yet. :-) My wish list for softraid(4) to enable me to say goodbye to RAIDframe is something like this (not exhaustive and in no particular order): - More complete RAID support overall, including - ability to tune stripe sizes Easily doable - not sure about the benefit since MAXPHYS should be close to optimal. I'm not sure either, but concerning RAIDframe different use cases could definitely be made to perform better or worse depending on how you tuned the stripes, with regard to overall speed, memory (stripe buffer) usage and so on. Perhaps it isn't an issue with softraid. - parity initialization / rebuilding, preferrably with background mode The RAID 4/5/6 disciplines are still lacking this (scrubbing), along with other things. That's the main reason I still use RAIDframe, to be able to make very large RAID5 volumes. For mirroring I use softraid, even without the ability to boot from the mirror. When that comes online I'll be even happier. :-) - Hot spare support We've had that for almost 2 years. I must admit that I haven't read the source, but I see no indication in the man pages of hot spare support for either of the disciplines? - Better handling of stripe (disk) failures Not sure what you're wanting here. Maybe it's depending on the underlying hardware and/or their drivers, but whenever I have a disk failure on a system it often deadlocks or misbehaves in some other way. I'm on vacation and can't specify this in more detail, but the next time it happens I'll trace it down more thorough (unfortunately these are production systems, so most often they need to be back up again asap, so there's little opportunity to debug). Also, when a hot spare is defined for a raid set, it would be great if it would be possible to automatically kick off a rebuild to that device when an array is degraded. (Perhaps it is, but I can't find it in the man pages.) - Better handling of recovery from failed stripes (ability to hot plug a replacement disk and rebuild on the spot for example) We've had that for almost 2 years as well. Great! Is that the -R option to bioctl you're referring to? - Full stripe writes for perfomance Meaning? In a RAID5 environment, a full stripe write is an optimization to avoid the read data + read parity + update data + update parity cycle normally necessary for each data block write, when there is enough data buffered for writing to span an entire stripe. In that case, given a stripe width of n, only n+1 writes of n data blocks are necessary, compared to 2n reads + 2n writes in the partial stripe write case. (The other kind of RAID5 write optimization that makes sense is of course to use a dedicated RAID controller with battery backed up buffer cache, which can achieve a similar effect on a block by block basis, only updating the parity block when it feels like it.) - Usable status reporting Are you talking about error messages, or bioctl(8) output? Both, I think. :-) I can elaborate more on that when I'm back in town and behind the wheel of my systems again. - Stripe on stripe (on stripe ...) support to be able to build RAID 0+1 and RAID50 sets, as well as crypto on raid (this may work now, haven't tried lately) This works, although is not officially supported at this stage. Cool! - More consistent sdn unit allocation (perhaps this is achievable with DUID, I haven't had time to explore that yet) sd(4) unit allocation will always be inconsistent and unpredicatable - DUIDs will let you avoid this entirely. Great. I'll look into that as well. Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny LC6fgren/ mobile: +46 70 718 11 90 /
