Re: 8.0-BETA2 Available
On 18/07/09 1:29 PM, Ken Smith wrote: # freebsd-update upgrade -r 8.0-BETA2 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now FreeBSD 7 users who have /usr /var, etc on ZFS should not follow these instructions exactly. Rebooting into a new kernel with the old userland ZFS tools will result in the system not being able to mount the ZFS filesystems and therefore not being able to reboot. [1] Ari Maniatis [1] See my more detailed comment at the bottom here: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
8.0-BETA2 Available
The second of the BETA builds for the FreeBSD-8.0 release cycle is now
available. There are still a few things being finished up so a couple
more moderately large commits are coming but we seem to be making good
progress. The target date for the last of the things still being worked
on is BETA3. In the meantime we appreciate the feedback we have
received from people who have started testing and some of those problems
have been fixed as well.
As was the case with BETA1, BETA2 is still a little bit "rough around
the edges" and we still have various debugging tools enabled that cause
the system to perform worse than it will when those debugging tools get
disabled. We don't know of any issues that will "eat your data" or
anything like that so in that regard it's safe but we don't recommend it
for production use quite yet. If you notice problems you can report
them through the normal Gnats PR system or on the freebsd-current
mailing list. Sorry for not specifying that in the BETA1 announcement.
With the X.0 releases I make the announcements of how the release is
progressing on both freebsd-current and freebsd-stable because what's
being released is "about to become a stable branch" so some people who
only read freebsd-stable might be interested. But when it comes to
watching for discussions about the release the developer community tends
to pay more attention to the freebsd-current mailing list.
ISO images for all supported architectures are available on the FTP
sites, and a "memory stick" image is available for amd64/i386
architectures. For amd64/i386 architectures the DVD and memstick images
include the documentation packages this time but no other packages yet.
None of the other images included packages. The memstick image should
now work in "fixit" mode (livefs).
If you are using csup/cvsup methods to update an older system the branch
tag to use is still head (".").
The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases. Systems running 7.0-RELEASE,
7.1-RELEASE, 7.2-RELEASE, or 8.0-BETA2 can upgrade as follows:
# freebsd-update upgrade -r 8.0-BETA2
During this process, FreeBSD Update may ask the user to help by merging some
configuration files or by confirming that the automatically performed merging
was done correctly.
# freebsd-update install
The system must be rebooted with the newly installed kernel before continuing.
# shutdown -r now
After rebooting, freebsd-update needs to be run again to install the new
userland components:
# freebsd-update install
At this point, users of systems being upgraded from FreeBSD 7.x will be
prompted by freebsd-update to rebuild all third-party applications (e.g.,
ports installed from the ports tree) due to updates in system libraries. See
http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html
for mode details. After updating installed third-party applications (and
again, only if freebsd-update printed a message indicating that this was
necessary), run freebsd-update again so that it can delete the old (no longer
used) system libraries:
# freebsd-update install
Finally, reboot into 8.0-BETA2:
# shutdown -r now
MD5/SHA256 checksums for the image files:
MD5 (8.0-BETA2-amd64-bootonly.iso) = 7e389124bfa5c216324b12660664a41d
MD5 (8.0-BETA2-amd64-disc1.iso) = c5a8391ec3eda90e310590c6e9352e43
MD5 (8.0-BETA2-amd64-dvd1.iso) = c148d1eac8fbafce3dc26a5186a3c7c6
MD5 (8.0-BETA2-amd64-livefs.iso) = 24e2da8a58e8df86a1a72d3fd2aa95a1
MD5 (8.0-BETA2-amd64-memstick.img) = 06d466ba9cf5c3a22aee92586fa96d7f
MD5 (8.0-BETA2-i386-bootonly.iso) = 4279dec2239df09ec7b93e52f96e55bb
MD5 (8.0-BETA2-i386-disc1.iso) = 16173fee72aa8cdd7d39d8ce3238276c
MD5 (8.0-BETA2-i386-dvd1.iso) = 3a04d48154c702021e9abac271e9a700
MD5 (8.0-BETA2-i386-livefs.iso) = 6ca1813b3ac7cc9abe8f44c9875a50bf
MD5 (8.0-BETA2-i386-memstick.img) = 5db506264c4b2d60b902d63ebc49a317
MD5 (8.0-BETA2-ia64-bootonly.iso) = baac960edebc8a10131db8debe961168
MD5 (8.0-BETA2-ia64-disc1.iso) = 77ecfb115e4dbc5eaaad6d42e8e93bae
MD5 (8.0-BETA2-ia64-disc2.iso) = 77fe3b112b74858abc9586e5ac0c8355
MD5 (8.0-BETA2-ia64-disc3.iso) = ddc874a6e67d290a6af96221a025e90a
MD5 (8.0-BETA2-ia64-dvd1.iso) = ac85730dfabea642cf91471954f541dd
MD5 (8.0-BETA2-ia64-livefs.iso) = 5806ddd76a778bcde03e3c92f0005173
MD5 (8.0-BETA2-pc98-bootonly.iso) = b0c5c41251242483c2048b77dadc7a76
MD5 (8.0-BETA2-pc98-disc1.iso) = 49a0974e0abd5e63618ea99634313bbe
MD5 (8.0-BETA2-pc98-livefs.iso) = dddfdb2e0f6ffd0497f9ce9a00812c24
MD5 (8.0-BETA2-powerpc-bootonly.iso) = 2bd42f619809aedbd3ac6a5b1beeec6d
MD5 (8.0-BETA2-powerpc-disc1.iso) = 329c5d3082fe3479545018092d3a0850
MD5 (8.0-BETA2-powerpc-disc2.iso) = ba7d5337e9c1cc9c356372a7d7f4015d
MD5 (8.0-BETA2-powerpc-disc3.iso) = 46567950c6e6d969ec584637641e042c
MD5 (8.0-BETA2-sparc64-bootonly.iso) = 47bba49d0f4ea3c58163db9146c46d6c
MD5 (8.0-BETA2-sparc64-disc1.iso) = 93af6d6d1164276d83c3e8c67a904422
MD5 (8.0-BETA2-sparc6
Re: gstripe problem
On Fri, July 17, 2009 09:07, Nenhum_de_Nos wrote: > > On Fri, July 17, 2009 07:20, Ivan Voras wrote: >> Nenhum_de_Nos wrote: >>> hail, >>> >>> I have a problem with gstripe on today stable. I created this stripe >>> using a bit more old stable (two weeks tops) and it can't be read on >>> old >>> stable (from 30/12/2008). So I recreated in 8-BETA1 and I could mount >>> and see files. When I tried again on 30/12/2008 stable and todays, on >>> PII machine (i386): >> >> So your problem is that: >> >> a) you created a gstripe array on a recent STABLE (two weeks ago) and it >> was fine >> b) you tried to use it with an old STABLE (30.12.2008.) and it didn't >> work >> c) you tried to use it with today's STABLE and it didn't work >> d) it works with 8-BETA1 >> ? > > its quite this. the stripe just vanishes when I try to see it in any > stable. and if I create in stable, a reboot makes it go way :( > >> The only thing that comes to my mind is that during your tests you have >> changed the stripe size, making the file system data unusable (and >> unmountable). >> >>> [r...@xxx ~]# gstripe status >>> Name Status Components >>> stripe/stripe0 UP ad4s2 >>> ad6s2 >> >>> mount: /dev/stripe/stripe0 : Invalid argument >>> >>> on 8-BETA1 it works, but can't create stripe on it and use on this >>> stable box though. the stripe already has files ! so anything weird >>> could make me loose my data ... >> >> Are you saying you won't use 8-BETA1 because you fear there may be >> problems with it? If so, you shouldn't worry so much - 8-CURRENT is very >> stable. > > I know it is. 8-CURRENT is great really (I use it in other places). my > main concern is that this is a server with mail/dns/dhcp/apache/some other > services I forgot and changing to 8-BETA may need to recompile all things, > and need time I don't have right now ... > > can I just update and use all software compiled for 7.1-PRERELEASE ? > > thanks, > > matheus thins here just got weird. I did updated to 8-BETA2. same problem though. so I just thought it was problem when I create a stripe in amd64 machine and try to use it on i386. I then put the drives in the amd64 machine, and it did worked fine, after another gstripe create command. so I rebooted the amd64 machine to see if after reboot the stripe would be there. guess what ... nothing there ... I used gmirror and gstripe for about an year, no problem. couple of months ago I had a problem and had to change the pc (dead one). so all changed, using sil3114 sata pci card now and PII 300 MHz. now the disks behave like this. if anyone has any leads, I'm moving data from the disks now ... can test though. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can an app crash from a single TCP packet lost in transmission?
aka Chuck Swiger schrieb mit Datum Fri, 17 Jul 2009 13:49:10 -0700 in m2n.fbsd.stable: |On Jul 17, 2009, at 12:12 PM, Peter Much wrote: |[ ... ] |> One other thing did happen between 03:51 and 03:52 - the DSL |> internet connection did disconnect/reconnect and obtained a new |> IP adress. Afterwards, a script does flush and reload an ipfw table() |> with the new local adresses - and during this process one(!) packet |> of the database session was dropped. | |Well, there you go: having your IP change is certainly going to break |existing network connections; Uh, is that so? Maybe I wasnt clear enough: the failing database connection is a LOCALHOST-LOCALHOST connection - and it uses the (fixed) IP of one of the LAN interfaces, not the dynamic internet IP on the tun/PPP interface. Changing the IP on one interface while using another interface is, to all my knowledge, normal business. And even IF there were problem with that, then I would expect the connection to timeout and fail, I would NOT expect a memory leak to appear and drive the system out of swap within seconds. !I don't believe there is anything which |is going to move the existing connection state in a NAT translation |layer or whatever over to the new IP. Nay, that doesnt work. |Presumably you can obtain a |static IP and avoid such issues. I have a static internet IP on the machine, also, for HTTPS. I have lots of interfaces there. And I did run some tests in the meantime. The problem is in the PostgresQL library; it doesnt depend on a changed IP; - I only need to steal one packet out of the transmission, then the database client will grow to VSZ=1500GB and bigger. That's perfect reproduceable. The postgresQL is 8.2, rather old by now - but I really wonder that noone else did get into this during all the time. rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can an app crash from a single TCP packet lost in transmission?
On Jul 17, 2009, at 12:12 PM, Peter Much wrote: [ ... ] One other thing did happen between 03:51 and 03:52 - the DSL internet connection did disconnect/reconnect and obtained a new IP adress. Afterwards, a script does flush and reload an ipfw table() with the new local adresses - and during this process one(!) packet of the database session was dropped. Well, there you go: having your IP change is certainly going to break existing network connections; I don't believe there is anything which is going to move the existing connection state in a NAT translation layer or whatever over to the new IP. Presumably you can obtain a static IP and avoid such issues. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Can an app crash from a single TCP packet lost in transmission?
The first thing I noticed was that my nameserver had gone. I searched for the reason and found: >Jul 15 04:04:52 edge kernel: swap_pager_getswapspace(3): failed < ... hundreds more of these ... > >Jul 15 04:05:07 edge kernel: pid 47113 (named), uid 53, was killed: out of swap space That didn't make sense - the machine has enough swapspace. But since this did repeat every other night, I started logging ps output minutely. And so I found a postgres database backup going weird: 03:23 70 78433 78432 0 96 0 8220 4196 - R ??0:22.84 pg_dump -b < ... > 03:49 70 78433 78432 0 96 0 8220 4024 - R ?? 17:06.61 pg_dump -b 03:50 70 78433 78432 0 96 0 8220 4024 - R ?? 17:46.15 pg_dump -b 03:51 70 78433 78432 0 96 0 8220 4024 - R ?? 18:26.69 pg_dump -b 03:52 70 78433 78432 0 47 0 139292 57888 select S ?? 18:37.65 pg_dump -b 03:53 70 78433 78432 0 48 0 139292 57828 select S ?? 18:40.36 pg_dump -b 03:54 70 78433 78432 0 -20 0 401436 69092 swread DL?? 18:42.49 pg_dump -b 03:55 70 78433 78432 0 -20 0 401436 63232 swread DL?? 18:43.99 pg_dump -b That process starts with 8MB memory, and runs so for half an hour, then suddenly between 03:51 and 03:52 memory usage explodes. And in that night it did not run out of swap space - instead it gave an error message: >pg_dump: Error message from server: lost synchronization with server: > got message type "0", length 154143043 >pg_dump: The command was: COPY public.file (fileid, fileindex, jobid, > pathid, filenameid, markid, lstat, md5) TO stdout; But that database backup is at that time quite in the middle of dumping a db table containing lots of small records - there is no reason why a 154 MB "message" should be transferred between server and client while copying records of ~60 Bytes each. One other thing did happen between 03:51 and 03:52 - the DSL internet connection did disconnect/reconnect and obtained a new IP adress. Afterwards, a script does flush and reload an ipfw table() with the new local adresses - and during this process one(!) packet of the database session was dropped. I could verify that relation: every night when there were memory problems, few packets from the database backup were lost during the firewall reconfigure - in nights when no packets were lost, there were no memory problems. I will now change the firewall handling to get rid of that packet loss, but also, I need some refresh on how TCP works: I thought TCP would not be disturbed by a lost packet, but would automatically resend that packet until ACK received; and I thought this would happen below the application, so practically the application CANNOT go weird from a lost packet... Is there any reason why this would not be true on a localhost connection? rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [rfc] MFC 7.x bce(4) to 6.x
2009/7/17 pluknet :
> Hi.
>
> Is there a planned MFC of bce(4) changes between 6.4 and 7.2 to RELENG_6?
>
> We need this at work in order to support Broadcom BCM5709 in (post-)6.4.
>
> I could able to backport recent 7.x changes to 6.4.
> I'm not sure about MSI and/or TSO4 stability here since there are
> changes since 6.x in bce(4).
> What I did is checkout RELENG_7 bce sources plus small hackish patch
> to compile this on 6.x.
>
> # uname -a
> FreeBSD 6.4-RELEASE FreeBSD 6.4-RELEASE #0: Fri Jul 17 21:08:32 MSD
> 2009 root@:/usr/obj/usr/src/sys/SMP i386
>
> It seems to work good. I have a network access to the box now.
>
> after kldload if_bce:
> bce0: mem
> 0x9200-0x93ff
> irq 28 at device 0.0 on pci11
> miibus0: on bce0
> ukphy0: on miibus0
> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FD
> X, auto
> bce0: Ethernet address: 00:1a:64:e5:13:ec
> bce0: link state changed to DOWN
> bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (0x04060705);
> Flags
> ( MFW MSI )
> bce1: mem
> 0x9400-0x95ff
> irq 40 at device 0.1 on pci11
> miibus1: on bce1
> ukphy1: on miibus1
> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FD
> X, auto
> bce1: Ethernet address: 00:1a:64:e5:13:ee
> bce1: ASIC (0x
> bce1: link state changed to DOWN
> 57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (0x04060705); Flags( MFW MSI )
> bce0: link state changed to UP
> bce0: link state changed to DOWN
> bce0: link state changed to UP
Ah, yes. Forgot to show dmesg from 7.2 for comparison:
bce0: mem
0x9200-0x93ff irq 28 at device 0.0 on pci11
bce0: Reserved 0x200 bytes for rid 0x10 type 3 at 0x9200
bce0: attempting to allocate 1 MSI vectors (16 supported)
bce0: using IRQ 256 for MSI
miibus0: on bce0
bce0: bpf attached
bce0: Ethernet address: 00:1a:64:e5:13:ec
bce0: [MPSAFE]
bce0: [ITHREAD]
bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C
(0x04060705); Flags( MFW MSI )
bce1: mem
0x9400-0x95ff irq 40 at device 0.1 on pci11
bce1: Reserved 0x200 bytes for rid 0x10 type 3 at 0x9400
bce1: attempting to allocate 1 MSI vectors (16 supported)
bce1: using IRQ 257 for MSI
miibus1: on bce1
bce1: bpf attached
bce1: Ethernet address: 00:1a:64:e5:13:ee
bce1: [MPSAFE]
bce1: [ITHREAD]
bce1: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C
(0x04060705); Flags( MFW MSI )
bce0: link state changed to UP
>
> The patch (against if_bce.c,v 1.34.2.9):
>
> --- /home/pluknet/cvs-7/src/sys/dev/bce/if_bce.c Wed Jun 3 13:42:55
> 2009
> +++ bce/if_bce.c Fri Jul 17 15:26:00 2009
> @@ -54,6 +54,12 @@ __FBSDID("$FreeBSD: src/sys/dev/bce/if_b
> #include
> #include
>
> +/* From sys/mbuf.h */
> +#define CSUM_TSO 0x0020 /* will do TSO */
> +
> +/* From net/if.h */
> +#define IFCAP_TSO4 0x00100 /* can do TCP Segmentation Offload */
> +
> //
> /* BCE Debug Options
> */
> //
> @@ -1059,7 +1065,7 @@ bce_attach(device_t dev)
>
> /* Hookup IRQ last. */
> rc = bus_setup_intr(dev, sc->bce_res_irq, INTR_TYPE_NET | INTR_MPSAFE,
> - NULL, bce_intr, sc, &sc->bce_intrhand);
> + bce_intr, sc, &sc->bce_intrhand);
>
> if (rc) {
> BCE_PRINTF("%s(%d): Failed to setup IRQ!\n",
> @@ -6391,13 +6397,24 @@ bce_tx_encap(struct bce_softc *sc, struc
> bus_dma_segment_t segs[BCE_MAX_SEGMENTS];
> bus_dmamap_t map;
> struct tx_bd *txbd = NULL;
> +#if __FreeBSD_version <= 700022
> + struct m_tag *mtag;
> +#endif
> struct mbuf *m0;
> +#if __FreeBSD_version > 700022
> struct ether_vlan_header *eh;
> struct ip *ip;
> struct tcphdr *th;
> - u16 prod, chain_prod, etype, mss = 0, vlan_tag = 0, flags = 0;
> +#endif
> + u16 prod, chain_prod,
> +#if __FreeBSD_version > 700022
> + etype,
> +#endif
> + mss = 0, vlan_tag = 0, flags = 0;
> u32 prod_bseq;
> +#if __FreeBSD_version > 700022
> int hdr_len = 0, e_hlen = 0, ip_hlen = 0, tcp_hlen = 0, ip_len = 0;
> +#endif
>
> #ifdef BCE_DEBUG
> u16 debug_prod;
> @@ -6418,6 +6435,7 @@ bce_tx_encap(struct bce_softc *sc, struc
> flags |= TX_BD_FLAGS_IP_CKSUM;
> if (m0->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP))
> flags |= TX_BD_FLAGS_TCP_UDP_CKSUM;
> +#if __FreeBSD_version > 700022
> if (m0->m_pkthdr.csum_flags & CSUM_TSO) {
> /* For TSO the controller needs two pieces of info, */
> /* the MSS and the IP+TCP options length. */
> @@ -6481,14 +6499,23 @@ bce_tx_encap(struct bce_softc *sc, struc
> bce_tx_encap_skip_tso:
> DBRUN(sc->requested_tso_frame
[rfc] MFC 7.x bce(4) to 6.x
Hi.
Is there a planned MFC of bce(4) changes between 6.4 and 7.2 to RELENG_6?
We need this at work in order to support Broadcom BCM5709 in (post-)6.4.
I could able to backport recent 7.x changes to 6.4.
I'm not sure about MSI and/or TSO4 stability here since there are
changes since 6.x in bce(4).
What I did is checkout RELENG_7 bce sources plus small hackish patch
to compile this on 6.x.
# uname -a
FreeBSD 6.4-RELEASE FreeBSD 6.4-RELEASE #0: Fri Jul 17 21:08:32 MSD
2009 root@:/usr/obj/usr/src/sys/SMP i386
It seems to work good. I have a network access to the box now.
after kldload if_bce:
bce0: mem 0x9200-0x93ff
irq 28 at device 0.0 on pci11
miibus0: on bce0
ukphy0: on miibus0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FD
X, auto
bce0: Ethernet address: 00:1a:64:e5:13:ec
bce0: link state changed to DOWN
bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (0x04060705); Flags
( MFW MSI )
bce1: mem 0x9400-0x95ff
irq 40 at device 0.1 on pci11
miibus1: on bce1
ukphy1: on miibus1
ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FD
X, auto
bce1: Ethernet address: 00:1a:64:e5:13:ee
bce1: ASIC (0x
bce1: link state changed to DOWN
57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (0x04060705); Flags( MFW MSI )
bce0: link state changed to UP
bce0: link state changed to DOWN
bce0: link state changed to UP
The patch (against if_bce.c,v 1.34.2.9):
--- /home/pluknet/cvs-7/src/sys/dev/bce/if_bce.cWed Jun 3 13:42:55 2009
+++ bce/if_bce.cFri Jul 17 15:26:00 2009
@@ -54,6 +54,12 @@ __FBSDID("$FreeBSD: src/sys/dev/bce/if_b
#include
#include
+/* From sys/mbuf.h */
+#define CSUM_TSO 0x0020 /* will do TSO */
+
+/* From net/if.h */
+#define IFCAP_TSO4 0x00100 /* can do TCP Segmentation Offload */
+
//
/* BCE Debug Options*/
//
@@ -1059,7 +1065,7 @@ bce_attach(device_t dev)
/* Hookup IRQ last. */
rc = bus_setup_intr(dev, sc->bce_res_irq, INTR_TYPE_NET | INTR_MPSAFE,
- NULL, bce_intr, sc, &sc->bce_intrhand);
+ bce_intr, sc, &sc->bce_intrhand);
if (rc) {
BCE_PRINTF("%s(%d): Failed to setup IRQ!\n",
@@ -6391,13 +6397,24 @@ bce_tx_encap(struct bce_softc *sc, struc
bus_dma_segment_t segs[BCE_MAX_SEGMENTS];
bus_dmamap_t map;
struct tx_bd *txbd = NULL;
+#if __FreeBSD_version <= 700022
+ struct m_tag *mtag;
+#endif
struct mbuf *m0;
+#if __FreeBSD_version > 700022
struct ether_vlan_header *eh;
struct ip *ip;
struct tcphdr *th;
- u16 prod, chain_prod, etype, mss = 0, vlan_tag = 0, flags = 0;
+#endif
+ u16 prod, chain_prod,
+#if __FreeBSD_version > 700022
+ etype,
+#endif
+ mss = 0, vlan_tag = 0, flags = 0;
u32 prod_bseq;
+#if __FreeBSD_version > 700022
int hdr_len = 0, e_hlen = 0, ip_hlen = 0, tcp_hlen = 0, ip_len = 0;
+#endif
#ifdef BCE_DEBUG
u16 debug_prod;
@@ -6418,6 +6435,7 @@ bce_tx_encap(struct bce_softc *sc, struc
flags |= TX_BD_FLAGS_IP_CKSUM;
if (m0->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_UDP))
flags |= TX_BD_FLAGS_TCP_UDP_CKSUM;
+#if __FreeBSD_version > 700022
if (m0->m_pkthdr.csum_flags & CSUM_TSO) {
/* For TSO the controller needs two pieces of info, */
/* the MSS and the IP+TCP options length. */
@@ -6481,14 +6499,23 @@ bce_tx_encap(struct bce_softc *sc, struc
bce_tx_encap_skip_tso:
DBRUN(sc->requested_tso_frames++);
}
+#endif
}
/* Transfer any VLAN tags to the bd. */
+#if __FreeBSD_version > 700022
if (m0->m_flags & M_VLANTAG) {
flags |= TX_BD_FLAGS_VLAN_TAG;
vlan_tag = m0->m_pkthdr.ether_vtag;
}
+#else
+mtag = VLAN_OUTPUT_TAG(sc->bce_ifp, m0);
+if (mtag != NULL) {
+flags |= TX_BD_FLAGS_VLAN_TAG;
+vlan_tag = VLAN_TAG_VALUE(mtag);
+}
+#endif
/* Map the mbuf into DMAable memory. */
prod = sc->tx_prod;
chain_prod = TX_CHAIN_IDX(prod);
--
wbr,
pluknet
bce.7-down-to-6.patch
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gstripe problem
On Fri, July 17, 2009 07:20, Ivan Voras wrote: > Nenhum_de_Nos wrote: >> hail, >> >> I have a problem with gstripe on today stable. I created this stripe >> using a bit more old stable (two weeks tops) and it can't be read on old >> stable (from 30/12/2008). So I recreated in 8-BETA1 and I could mount >> and see files. When I tried again on 30/12/2008 stable and todays, on >> PII machine (i386): > > So your problem is that: > > a) you created a gstripe array on a recent STABLE (two weeks ago) and it > was fine > b) you tried to use it with an old STABLE (30.12.2008.) and it didn't work > c) you tried to use it with today's STABLE and it didn't work > d) it works with 8-BETA1 > ? its quite this. the stripe just vanishes when I try to see it in any stable. and if I create in stable, a reboot makes it go way :( > The only thing that comes to my mind is that during your tests you have > changed the stripe size, making the file system data unusable (and > unmountable). > >> [r...@xxx ~]# gstripe status >> Name Status Components >> stripe/stripe0 UP ad4s2 >> ad6s2 > >> mount: /dev/stripe/stripe0 : Invalid argument >> >> on 8-BETA1 it works, but can't create stripe on it and use on this >> stable box though. the stripe already has files ! so anything weird >> could make me loose my data ... > > Are you saying you won't use 8-BETA1 because you fear there may be > problems with it? If so, you shouldn't worry so much - 8-CURRENT is very > stable. I know it is. 8-CURRENT is great really (I use it in other places). my main concern is that this is a server with mail/dns/dhcp/apache/some other services I forgot and changing to 8-BETA may need to recompile all things, and need time I don't have right now ... can I just update and use all software compiled for 7.1-PRERELEASE ? thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gstripe problem
Nenhum_de_Nos wrote: hail, I have a problem with gstripe on today stable. I created this stripe using a bit more old stable (two weeks tops) and it can't be read on old stable (from 30/12/2008). So I recreated in 8-BETA1 and I could mount and see files. When I tried again on 30/12/2008 stable and todays, on PII machine (i386): So your problem is that: a) you created a gstripe array on a recent STABLE (two weeks ago) and it was fine b) you tried to use it with an old STABLE (30.12.2008.) and it didn't work c) you tried to use it with today's STABLE and it didn't work d) it works with 8-BETA1 ? The only thing that comes to my mind is that during your tests you have changed the stripe size, making the file system data unusable (and unmountable). [r...@xxx ~]# gstripe status Name Status Components stripe/stripe0 UP ad4s2 ad6s2 mount: /dev/stripe/stripe0 : Invalid argument on 8-BETA1 it works, but can't create stripe on it and use on this stable box though. the stripe already has files ! so anything weird could make me loose my data ... Are you saying you won't use 8-BETA1 because you fear there may be problems with it? If so, you shouldn't worry so much - 8-CURRENT is very stable. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
