Re: Fix Emulex oce driver in CURRENT
Hi,
I found other problems in the oce driver during some experiments with
netmap in emulation mode.
In details:
- missing locking:
- in some functions there are write accesses on the wq struct (tx queue
descriptor)
without acquire LOCK on the queue, particularly in oce_wq_handler() that is
invoked
in the interrupt routine. For this reason there may be race conditions.
- tx cleanup:
- in oce_if_deactivate() the wq queues are drained but some still pending
mbufs are not freed.
For this reason, I added the oce_tx_clean() that releases any pending mbufs.
I also tried experimenting with iperf3 using the same Borja environment and
I don't have panic.
Can you try this patch? Do you still have the panic?
Cheers,
Stefano Garzarella
diff --git a/sys/dev/oce/oce_if.c b/sys/dev/oce/oce_if.c
index af57491..33b35b4 100644
--- a/sys/dev/oce/oce_if.c
+++ b/sys/dev/oce/oce_if.c
@@ -142,6 +142,7 @@ static int oce_tx(POCE_SOFTC sc, struct mbuf **mpp,
int wq_index);
static void oce_tx_restart(POCE_SOFTC sc, struct oce_wq *wq);
static void oce_tx_complete(struct oce_wq *wq, uint32_t wqe_idx,
uint32_t status);
+static void oce_tx_clean(POCE_SOFTC sc);
static int oce_multiq_transmit(struct ifnet *ifp, struct mbuf *m,
struct oce_wq *wq);
@@ -585,8 +586,10 @@ oce_multiq_flush(struct ifnet *ifp)
int i = 0;
for (i = 0; i sc-nwqs; i++) {
+ LOCK(sc-wq[i]-tx_lock);
while ((m = buf_ring_dequeue_sc(sc-wq[i]-br)) != NULL)
m_freem(m);
+ UNLOCK(sc-wq[i]-tx_lock);
}
if_qflush(ifp);
}
@@ -1052,6 +1055,19 @@ oce_tx_complete(struct oce_wq *wq, uint32_t wqe_idx,
uint32_t status)
}
}
+static void
+oce_tx_clean(POCE_SOFTC sc) {
+ int i = 0;
+ struct oce_wq *wq;
+
+ for_all_wq_queues(sc, wq, i) {
+ LOCK(wq-tx_lock);
+ while (wq-pkt_desc_tail != wq-pkt_desc_head) {
+ oce_tx_complete(wq, 0, 0);
+ }
+ UNLOCK(wq-tx_lock);
+ }
+}
static void
oce_tx_restart(POCE_SOFTC sc, struct oce_wq *wq)
@@ -1213,6 +1229,8 @@ oce_wq_handler(void *arg)
struct oce_nic_tx_cqe *cqe;
int num_cqes = 0;
+ LOCK(wq-tx_lock);
+
bus_dmamap_sync(cq-ring-dma.tag,
cq-ring-dma.map, BUS_DMASYNC_POSTWRITE);
cqe = RING_GET_CONSUMER_ITEM_VA(cq-ring, struct oce_nic_tx_cqe);
@@ -1237,6 +1255,8 @@ oce_wq_handler(void *arg)
if (num_cqes)
oce_arm_cq(sc, cq-cq_id, num_cqes, FALSE);
+ UNLOCK(wq-tx_lock);
+
return 0;
}
@@ -2087,6 +2107,9 @@ oce_if_deactivate(POCE_SOFTC sc)
/* Delete RX queue in card with flush param */
oce_stop_rx(sc);
+ /* Flush the mbufs that are still in TX queues */
+ oce_tx_clean(sc);
+
/* Invalidate any pending cq and eq entries*/
for_all_evnt_queues(sc, eq, i)
oce_drain_eq(eq);
diff --git a/sys/dev/oce/oce_queue.c b/sys/dev/oce/oce_queue.c
index 308c16d..161011b 100644
--- a/sys/dev/oce/oce_queue.c
+++ b/sys/dev/oce/oce_queue.c
@@ -969,7 +969,9 @@ oce_start_rq(struct oce_rq *rq)
int
oce_start_wq(struct oce_wq *wq)
{
+ LOCK(wq-tx_lock); /* XXX: maybe not necessary */
oce_arm_cq(wq-parent, wq-cq-cq_id, 0, TRUE);
+ UNLOCK(wq-tx_lock);
return 0;
}
@@ -1076,6 +1078,8 @@ oce_drain_wq_cq(struct oce_wq *wq)
struct oce_nic_tx_cqe *cqe;
int num_cqes = 0;
+ LOCK(wq-tx_lock); /* XXX: maybe not necessary */
+
bus_dmamap_sync(cq-ring-dma.tag, cq-ring-dma.map,
BUS_DMASYNC_POSTWRITE);
@@ -1093,6 +1097,7 @@ oce_drain_wq_cq(struct oce_wq *wq)
oce_arm_cq(sc, cq-cq_id, num_cqes, FALSE);
+ UNLOCK(wq-tx_lock);
}
2014-07-07 13:57 GMT+02:00 Borja Marcos bor...@sarenet.es:
On Jul 7, 2014, at 1:23 PM, Luigi Rizzo wrote:
On Mon, Jul 7, 2014 at 1:03 PM, Borja Marcos bor...@sarenet.es wrote:
we'll try to investigate, can you tell us more about the environment you
use ?
(FreeBSD version, card model (PCI id perhaps), iperf3 invocation line,
interface configuration etc.)
The main differences between 10.0.747.0 and the code in head (after
our fix) is the use
of drbr_enqueue/dequeue versus the peek/putback in the transmit routine.
Both drivers still have issues when the link flaps because the
transmit queue is not cleaned
up properly (unlike what happens in the linux driver and all FreeBSD
drivers for different
hardware), so it might well be that you are seeing some side effect of
that or other
problem which manifests itself differently depending on the environment.
'instant panic' by itself does not tell us anything about what could
be the problem you experience (and we do not see it with either driver).
The environment details are here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183391
The way I produce an instant panic is:
1) Connect to another machine (cross connect cable)
2) iperf3 -s on the other machine
(The other machine is different, it has an ix card)
3) iperf3 -t 30 -P 4 -c 10.0.0.1 -N
In less than 30 seconds, panic.
mierda dumped core - see /var/crash/vmcore.0
Mon Jul 7 13:06:44 CEST 2014
FreeBSD mierda 10.0-STABLE FreeBSD 10.0-STABLE #2: Mon Jul 7 11:41:45
CEST 2014
Re: libdevattr
On 7/15/14, Bruno Lauzé brunola...@msn.com wrote: I was looking at dragonfly and why they have libdevattr and we don'tI really think having udev compatible api would open the door to a lot of software, imho.I feel it wouldn't be so complicated to port dragonfly kern_udev, libprop and libdevattr from dragonfly bsd. Am i missing a point or is this in contradiction witch any of freebsd objectives? Let me know your thoughts... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org In FreeBSD exists similar utility like udev, the so called devd. In github is there a project, which would improve the compatibility or completely change the udev like brain-damage. https://github.com/freebsd/libdevq Other problem with udev is, that moving so fast, and every time changed their API, and udev's future are not clear, possibly merged with systemd. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
On Jul 15, 2014, at 10:22 AM, Stefano Garzarella wrote: Hi, I found other problems in the oce driver during some experiments with netmap in emulation mode. What about driver version 10.0.747.0? At least in my configuration it works perfectly, no crashes despite keeping it running for several days at full bandwidth. I have a server about to go into production. Should this patch work on 10-STABLE? Borja. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
I used the oce driver in CURRENT. I think that this patch in combination with the previous one should work in 10-STABLE. I have only tested if it works with CURRENT, but now I try if it works with 10-STABLE and I'll send you some feedback. Cheers, Stefano 2014-07-15 10:28 GMT+02:00 Borja Marcos bor...@sarenet.es: On Jul 15, 2014, at 10:22 AM, Stefano Garzarella wrote: Hi, I found other problems in the oce driver during some experiments with netmap in emulation mode. What about driver version 10.0.747.0? At least in my configuration it works perfectly, no crashes despite keeping it running for several days at full bandwidth. I have a server about to go into production. Should this patch work on 10-STABLE? Borja. -- Stefano Garzarella ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote: I used the oce driver in CURRENT. I think that this patch in combination with the previous one should work in 10-STABLE. I have only tested if it works with CURRENT, but now I try if it works with 10-STABLE and I'll send you some feedback. I can still try. Will get back to you soon. Cheers, Borja. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote: I used the oce driver in CURRENT. I think that this patch in combination with the previous one should work in 10-STABLE. I have only tested if it works with CURRENT, but now I try if it works with 10-STABLE and I'll send you some feedback. Hmmm. The patch seems to be broken. I have tried to apply it renaming the a/usr/src... to oce_if.c.old and oce_if.c, etc, and patch complains: Patching file oce_if.c using Plan A... patch: malformed patch at line 6: int wq_index); Was it broken by the email client formatting? Or am I being especially clumsy today? ;) Borja. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
I think there is some problem with the email formatting. I send you a file with both patches. Cheers, Stefano 2014-07-15 11:12 GMT+02:00 Borja Marcos bor...@sarenet.es: On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote: I used the oce driver in CURRENT. I think that this patch in combination with the previous one should work in 10-STABLE. I have only tested if it works with CURRENT, but now I try if it works with 10-STABLE and I'll send you some feedback. Hmmm. The patch seems to be broken. I have tried to apply it renaming the a/usr/src... to oce_if.c.old and oce_if.c, etc, and patch complains: Patching file oce_if.c using Plan A... patch: malformed patch at line 6: int wq_index); Was it broken by the email client formatting? Or am I being especially clumsy today? ;) Borja. -- Stefano Garzarella oce_fix_STABLE10.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
bsd.sys.mk [-Wno-uninitialized]
On 07/05/14 15:10, David Chisnall wrote: On 5 Jul 2014, at 14:07, Dimitry Andric d...@freebsd.org wrote: Interestingly, -Wno-uninitialized has been in bsd.sys.mk since r76861, and the accompanying comment (XXX Delete -Wuninitialized by default for now -- the compiler doesn't always get it right) has never been changed. :-) It is probably time to re-enable that warning after 13 years, at least. It probably only wants enabling for clang. GCC (at least, GCC 4.2.1) performs this analysis based on analyses run by the optimisers and so the warnings are dependent on optimisation level. David Hi, Is someone working on this? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Add support for changing the flow ID of TCP connections
On 07/09/14 18:31, Navdeep Parhar wrote: On Wed, Jul 09, 2014 at 04:36:53PM +0200, Hans Petter Selasky wrote: On 07/08/14 21:17, Navdeep Parhar wrote: ... I think we need to design this to be as generic as possible. I have quite a bit of code that does this stuff but I haven't pushed it upstream or even offered it for review (yet). Hi, When will the non hardware related patches be available for review? I understand there are multiple ways to reach the same goal, and I think it would be great if we could agree on a common API for applications. Here is the kernel side of the patch: http://people.freebsd.org/~np/flow_pacing_kern.diff The registration parameters and the throttling parameters are probably cxgbe-centric, because that's what it was written for. We'll need to tidy up those structs certainly. And I'd like to add pps constraints to the throttling parameters (all it does is bandwidth right now). Hi Navdeep, After reviewing your patch, we've concluded that we can't use your flow-ID API's AS-IS for the mlxen hardware. We are working on a new patch proposal after the feedback received here, and will probably post something in August, hence now it is vacation time and not all people are available. Also we are worried that the m_tags cause un-needed overhead, that it invokes malloc for every pkt header duplication on transmit. As to give you some clues: One of FreeBSD's targets is firewalls and routers. We think that a flow ID / hardware queue feature should also be usable by the firewall, and not only limited to TCP/UDP. That means you can create queues for multiple connections which then get rate limited as a firewall rule. Right now our main target is not the firewall, but we see that by minor modifications of the APIs, this feature becomes very easy to implement. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
I just tried to run iperf3 with this patch and STABLE-10 and it seems to work. Do you have a panic? Cheers, Stefano 2014-07-15 11:19 GMT+02:00 Stefano Garzarella stefanogarzare...@gmail.com: I think there is some problem with the email formatting. I send you a file with both patches. Cheers, Stefano 2014-07-15 11:12 GMT+02:00 Borja Marcos bor...@sarenet.es: On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote: I used the oce driver in CURRENT. I think that this patch in combination with the previous one should work in 10-STABLE. I have only tested if it works with CURRENT, but now I try if it works with 10-STABLE and I'll send you some feedback. Hmmm. The patch seems to be broken. I have tried to apply it renaming the a/usr/src... to oce_if.c.old and oce_if.c, etc, and patch complains: Patching file oce_if.c using Plan A... patch: malformed patch at line 6: int wq_index); Was it broken by the email client formatting? Or am I being especially clumsy today? ;) Borja. -- Stefano Garzarella -- Stefano Garzarella ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
On Jul 15, 2014, at 11:45 AM, Stefano Garzarella wrote: I just tried to run iperf3 with this patch and STABLE-10 and it seems to work. Do you have a panic? Still compiling :) Anyway, you didn't suffer panics before, right? Borja. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
2014-07-15 11:46 GMT+02:00 Borja Marcos bor...@sarenet.es: On Jul 15, 2014, at 11:45 AM, Stefano Garzarella wrote: I just tried to run iperf3 with this patch and STABLE-10 and it seems to work. Do you have a panic? Still compiling :) Anyway, you didn't suffer panics before, right? Right, I didn't suffer panics with iperf3, but with netmap in emulation mode I had a lot of panics before this patch. Stefano Borja. -- Stefano Garzarella ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
On Jul 15, 2014, at 11:45 AM, Stefano Garzarella wrote: I just tried to run iperf3 with this patch and STABLE-10 and it seems to work. Do you have a panic? So far, so good. I've ran a couple of iperf3 tests (60 seconds, trying both directions) and it doesn't crash. Without the fixes I obtained a panic quite reliably, in less than 30 seconds. Still trying. But the bugs you mentioned (lack of locking and deallocating, etc) seem to be consistent with the kind of failures I saw and their apparent randomness. So, asking for spiritual counsel now. Would you use this driver in a production environment instead of the 747 version downloaded from Emulex? I think the latter is giving slightly better performance but, anyway, I disable LRO and TSO because I see a horrible impact on NFS performance. Cheers, Borja. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
2014-07-15 12:00 GMT+02:00 Borja Marcos bor...@sarenet.es: On Jul 15, 2014, at 11:45 AM, Stefano Garzarella wrote: I just tried to run iperf3 with this patch and STABLE-10 and it seems to work. Do you have a panic? So far, so good. I've ran a couple of iperf3 tests (60 seconds, trying both directions) and it doesn't crash. Without the fixes I obtained a panic quite reliably, in less than 30 seconds. Still trying. But the bugs you mentioned (lack of locking and deallocating, etc) seem to be consistent with the kind of failures I saw and their apparent randomness. Well. So, asking for spiritual counsel now. Would you use this driver in a production environment instead of the 747 version downloaded from Emulex? I think the latter is giving slightly better performance but, anyway, I disable LRO and TSO because I see a horrible impact on NFS performance. I made a diff between the two versions (CURRENT and 747) and I saw that the main difference is in the management of buf_ring through drbr API. In the CURRENT driver they use a new function drbr_peek() instead of drbr_dequeue() and I think this is better. However, even in the 747 version seems to have the problem of the lack of locking. Cheers, Stefano Cheers, Borja. -- Stefano Garzarella ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fix Emulex oce driver in CURRENT
On Jul 15, 2014, at 1:36 PM, Stefano Garzarella wrote: So, asking for spiritual counsel now. Would you use this driver in a production environment instead of the 747 version downloaded from Emulex? I think the latter is giving slightly better performance but, anyway, I disable LRO and TSO because I see a horrible impact on NFS performance. I made a diff between the two versions (CURRENT and 747) and I saw that the main difference is in the management of buf_ring through drbr API. In the CURRENT driver they use a new function drbr_peek() instead of drbr_dequeue() and I think this is better. However, even in the 747 version seems to have the problem of the lack of locking. Well, definitely you saved my cake! So it was still a tickling time bomb. Thank you very much! Borja. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Demangling issues with libcxxrt.so.1 on v9.2
Hello everybody,
It seems there are problems with demandling some kinds of names with
libcxxrt.so.1 on FreeBSD 9.2 (I didn't test other versions yet).
This program:
---
#include stdio.h
#include stdlib.h
extern C char* __cxa_demangle(const char* mangled_name,
char* buf, size_t* n, int* status);
void test(const char *mangled) {
int status = 0;
char *DemangledName = __cxa_demangle(mangled, NULL, NULL, status);
printf(%s: status %d, mangled, status);
if(status == 0)
printf(; demangled: '%s', DemangledName);
free(DemangledName);
printf(\n);
}
int main(void) {
test(_Z9NullDerefPi);
test(_ZL9NullDerefPi);
test(_ZN8DeepFreeILi0EE4freeEPc);
test(_ZN8DeepFreeILi13EE4freeEPc);
test(_ZN8DeepFreeILi36EE4freeEPc);
return 0;
}
---
outputs:
---
_Z9NullDerefPi: status 0; demangled: 'NullDeref(int*)'
_ZL9NullDerefPi: status -2
_ZN8DeepFreeILi0EE4freeEPc: status 0; demangled: 'DeepFree0E::free(char*)'
_ZN8DeepFreeILi13EE4freeEPc: status 0; demangled:
'DeepFree13E::free(char*)'
_ZN8DeepFreeILi36EE4freeEPc: status 0; demangled:
'DeepFree36E::free(char*)'
---
Note that it fails to demangle the local name in the 2nd line and adds
extra 'E' character in DeepFree...Es.
The case with the local name is not critical, but the case with
DeepFree...E prevents LLVM's address sanitizer tests from passing on
FreeBSD so the question is: is there a chance the defect will be
resolved any time soon or should I try to prepare a fix to speed up the
process?
Thanks a lot.
--
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Demangling issues with libcxxrt.so.1 on v9.2
Hi Ivan,
The demangler in libcxxrt is taken from the elftoolchain project. Kai Wang
(added to cc:) was interested in improving it, but I doubt any fixes will be
merged to 9.x any time soon.
David
On 15 Jul 2014, at 14:11, Ivan A. Kosarev i...@ivan-labs.com wrote:
Hello everybody,
It seems there are problems with demandling some kinds of names with
libcxxrt.so.1 on FreeBSD 9.2 (I didn't test other versions yet).
This program:
---
#include stdio.h
#include stdlib.h
extern C char* __cxa_demangle(const char* mangled_name,
char* buf, size_t* n, int* status);
void test(const char *mangled) {
int status = 0;
char *DemangledName = __cxa_demangle(mangled, NULL, NULL, status);
printf(%s: status %d, mangled, status);
if(status == 0)
printf(; demangled: '%s', DemangledName);
free(DemangledName);
printf(\n);
}
int main(void) {
test(_Z9NullDerefPi);
test(_ZL9NullDerefPi);
test(_ZN8DeepFreeILi0EE4freeEPc);
test(_ZN8DeepFreeILi13EE4freeEPc);
test(_ZN8DeepFreeILi36EE4freeEPc);
return 0;
}
---
outputs:
---
_Z9NullDerefPi: status 0; demangled: 'NullDeref(int*)'
_ZL9NullDerefPi: status -2
_ZN8DeepFreeILi0EE4freeEPc: status 0; demangled: 'DeepFree0E::free(char*)'
_ZN8DeepFreeILi13EE4freeEPc: status 0; demangled: 'DeepFree13E::free(char*)'
_ZN8DeepFreeILi36EE4freeEPc: status 0; demangled: 'DeepFree36E::free(char*)'
---
Note that it fails to demangle the local name in the 2nd line and adds extra
'E' character in DeepFree...Es.
The case with the local name is not critical, but the case with
DeepFree...E prevents LLVM's address sanitizer tests from passing on
FreeBSD so the question is: is there a chance the defect will be resolved any
time soon or should I try to prepare a fix to speed up the process?
Thanks a lot.
--
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: page fault (on 10.0-RELEASE-p7)
Info at http://slexy.org/raw/s21qACK3qQ. On the 1st boot after the panic, the crash dump failed due to insufficient amount of space on /. Then I removed some files, restarted the system, and the dump was redone. Is it correct to assume that the dump was not damaged? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsd.sys.mk [-Wno-uninitialized]
[-stable to bcc; keeping -current] On Tue, 15 Jul 2014, Hans Petter Selasky wrote: On 07/05/14 15:10, David Chisnall wrote: On 5 Jul 2014, at 14:07, Dimitry Andric d...@freebsd.org wrote: Interestingly, -Wno-uninitialized has been in bsd.sys.mk since r76861, and the accompanying comment (XXX Delete -Wuninitialized by default for now -- the compiler doesn't always get it right) has never been changed. :-) It is probably time to re-enable that warning after 13 years, at least. It probably only wants enabling for clang. GCC (at least, GCC 4.2.1) performs this analysis based on analyses run by the optimisers and so the warnings are dependent on optimisation level. David Hi, Is someone working on this? I was going to chime in and claim that I had seen false positives from -Wuninitialized even from recent clang, but upon consulting my build logs, it seems that the false positives are actually from -Wconditional-uninitialized. Is that known to be less reliable? -Ben ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Boot loader too large
On Friday, July 11, 2014 6:50:43 pm Matthew D. Fuller wrote: On Fri, Jul 11, 2014 at 03:38:56PM -0700 I heard the voice of Nathan Whitehorn, and lo! it spake thus: I don't honestly remember where that number came from. It's at line 72 of usr.sbin/bsdinstall/partedit/partedit_x86.c. If 128 works better, I'm happy to change it, but it would be nice to know what the actual bounds here are before putting in a new arbitrary number. src/sys/boot/i386/pmbr/pmbr.s says - next_boot:. incl (%si). . . # Next LBA . . adcl $0,4(%si) . . mov %es,%ax.. . # Adjust segment for next . . addw $SECSIZE/16,%ax. . # sector . . cmp $0x9000,%ax.. . # Don't load past 0x9, . . jae err_big.. . # 545k should be enough for . . mov %ax,%es.. . # any boot code. :) - (err_big being printing the Boot loader too large message). Though 0x9 is actually 576k, not 545, but presumably there's some other adjustment lopping off bits somewhere; that's 62 sectors diff. The boot code is not loaded at offset 0, it is loaded at offset 0x7c00 (the same address the BIOS loads boot loaders): .set LOAD,0x7c00# Load address ... # # We found a boot partition. Load it into RAM starting at 0x7c00. # movw %bx,%di# Save partition pointer in %di leaw PART_START_LBA(%di),%si movw $LOAD/16,%bx Regardless, I settled on 512k for my boot partitions (after finding the above error when I previously decided it's a few dozen k, I'll just set aside a meg to be safe and then discovered the whole not-booting thing that caused. 512k should be fine even if it is a bit excessive. Also, larger partitions might actually increase boot time, but perhaps not noticably. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sparc64
TB --- 2014-07-15 21:39:21 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-15 21:39:21 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-15 21:39:21 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2014-07-15 21:39:21 - cleaning the object tree TB --- 2014-07-15 21:39:21 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-15 21:39:24 - At svn revision 268669 TB --- 2014-07-15 21:39:25 - building world TB --- 2014-07-15 21:39:25 - CROSS_BUILD_TESTING=YES TB --- 2014-07-15 21:39:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-15 21:39:25 - MAKESYSPATH=/src/share/mk TB --- 2014-07-15 21:39:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-15 21:39:25 - SRCCONF=/dev/null TB --- 2014-07-15 21:39:25 - TARGET=sparc64 TB --- 2014-07-15 21:39:25 - TARGET_ARCH=sparc64 TB --- 2014-07-15 21:39:25 - TZ=UTC TB --- 2014-07-15 21:39:25 - __MAKE_CONF=/dev/null TB --- 2014-07-15 21:39:25 - cd /src TB --- 2014-07-15 21:39:25 - /usr/bin/make -B buildworld Building an up-to-date bmake(1) World build started on Tue Jul 15 21:39:32 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/mkdep/mkdep.1 mkdep.1.gz === usr.bin/mkesdb (all) cc -O2 -pipe -I/src/usr.bin/mkesdb -I/src/usr.bin/mkesdb/../mkesdb -I/src/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c lex.c cc -O2 -pipe -I/src/usr.bin/mkesdb -I/src/usr.bin/mkesdb/../mkesdb -I/src/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c yacc.c cc -O2 -pipe -I/src/usr.bin/mkesdb -I/src/usr.bin/mkesdb/../mkesdb -I/src/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -L/obj/sparc64.sparc64/src/usr.bin/mkesdb/../../lib/libc -o mkesdb lex.o yacc.o gzip -cn /src/usr.bin/mkesdb/mkesdb.1 mkesdb.1.gz === usr.bin/mkfifo (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/mkfifo/mkfifo.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o mkfifo mkfifo.o gzip -cn /src/usr.bin/mkfifo/mkfifo.1 mkfifo.1.gz === usr.bin/mkimg (all) cc -O2 -pipe -DSPARSE_WRITE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/mkimg/format.c cc -O2 -pipe -DSPARSE_WRITE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/mkimg/image.c cc -O2 -pipe
[head tinderbox] failure on powerpc/powerpc
TB --- 2014-07-15 20:02:10 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-15 20:02:10 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-15 20:02:10 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2014-07-15 20:02:10 - cleaning the object tree TB --- 2014-07-15 20:02:10 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-15 20:02:13 - At svn revision 268669 TB --- 2014-07-15 20:02:14 - building world TB --- 2014-07-15 20:02:14 - CROSS_BUILD_TESTING=YES TB --- 2014-07-15 20:02:14 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-15 20:02:14 - MAKESYSPATH=/src/share/mk TB --- 2014-07-15 20:02:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-15 20:02:14 - SRCCONF=/dev/null TB --- 2014-07-15 20:02:14 - TARGET=powerpc TB --- 2014-07-15 20:02:14 - TARGET_ARCH=powerpc TB --- 2014-07-15 20:02:14 - TZ=UTC TB --- 2014-07-15 20:02:14 - __MAKE_CONF=/dev/null TB --- 2014-07-15 20:02:14 - cd /src TB --- 2014-07-15 20:02:14 - /usr/bin/make -B buildworld Building an up-to-date bmake(1) World build started on Tue Jul 15 20:02:21 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/mkdep/mkdep.1 mkdep.1.gz === usr.bin/mkesdb (all) cc -O2 -pipe -I/src/usr.bin/mkesdb -I/src/usr.bin/mkesdb/../mkesdb -I/src/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c lex.c cc -O2 -pipe -I/src/usr.bin/mkesdb -I/src/usr.bin/mkesdb/../mkesdb -I/src/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c yacc.c cc -O2 -pipe -I/src/usr.bin/mkesdb -I/src/usr.bin/mkesdb/../mkesdb -I/src/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -L/obj/powerpc.powerpc/src/usr.bin/mkesdb/../../lib/libc -o mkesdb lex.o yacc.o gzip -cn /src/usr.bin/mkesdb/mkesdb.1 mkesdb.1.gz === usr.bin/mkfifo (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/mkfifo/mkfifo.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o mkfifo mkfifo.o gzip -cn /src/usr.bin/mkfifo/mkfifo.1 mkfifo.1.gz === usr.bin/mkimg (all) cc -O2 -pipe -DSPARSE_WRITE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/mkimg/format.c cc -O2 -pipe -DSPARSE_WRITE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/mkimg/image.c cc -O2 -pipe
[head tinderbox] failure on powerpc64/powerpc
TB --- 2014-07-15 21:33:25 - tinderbox 2.22 running on freebsd-current.sentex.ca TB --- 2014-07-15 21:33:25 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-07-15 21:33:25 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2014-07-15 21:33:25 - cleaning the object tree TB --- 2014-07-15 21:33:25 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-07-15 21:33:56 - At svn revision 268669 TB --- 2014-07-15 21:33:57 - building world TB --- 2014-07-15 21:33:57 - CROSS_BUILD_TESTING=YES TB --- 2014-07-15 21:33:57 - MAKEOBJDIRPREFIX=/obj TB --- 2014-07-15 21:33:57 - MAKESYSPATH=/src/share/mk TB --- 2014-07-15 21:33:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-07-15 21:33:57 - SRCCONF=/dev/null TB --- 2014-07-15 21:33:57 - TARGET=powerpc TB --- 2014-07-15 21:33:57 - TARGET_ARCH=powerpc64 TB --- 2014-07-15 21:33:57 - TZ=UTC TB --- 2014-07-15 21:33:57 - __MAKE_CONF=/dev/null TB --- 2014-07-15 21:33:57 - cd /src TB --- 2014-07-15 21:33:57 - /usr/bin/make -B buildworld Building an up-to-date bmake(1) World build started on Tue Jul 15 21:34:05 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.bin/mkdep/mkdep.1 mkdep.1.gz === usr.bin/mkesdb (all) cc -O2 -pipe -I/src/usr.bin/mkesdb -I/src/usr.bin/mkesdb/../mkesdb -I/src/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c lex.c cc -O2 -pipe -I/src/usr.bin/mkesdb -I/src/usr.bin/mkesdb/../mkesdb -I/src/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c yacc.c cc -O2 -pipe -I/src/usr.bin/mkesdb -I/src/usr.bin/mkesdb/../mkesdb -I/src/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -L/obj/powerpc.powerpc64/src/usr.bin/mkesdb/../../lib/libc -o mkesdb lex.o yacc.o gzip -cn /src/usr.bin/mkesdb/mkesdb.1 mkesdb.1.gz === usr.bin/mkfifo (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/mkfifo/mkfifo.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o mkfifo mkfifo.o gzip -cn /src/usr.bin/mkfifo/mkfifo.1 mkfifo.1.gz === usr.bin/mkimg (all) cc -O2 -pipe -DSPARSE_WRITE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/mkimg/format.c cc -O2 -pipe -DSPARSE_WRITE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/mkimg/image.c cc -O2
