Re: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
On Wed, Mar 10, 2010 at 11:07 PM, Tom Couch tom.couch.stor...@gmail.com wrote: Hi FreeBSD-current, I am available to maintain the twa driver, now that I am on this list. Let me know how I can help, Hi Tom, That's a good news to hear! You could take a look at GNATS database where problems are reported by the users and find out if there are any PRs open for twa driver. http://www.freebsd.org/cgi/query-pr-summary.cgi?query Many users post problem report to the list too, so stay tuned! Nonetheless you can post patches if you discover some bugs or if you'd like to improve the driver code. -- Gianni ___ 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: [head tinderbox] failure on powerpc/powerpc
On Wed, Mar 10, 2010 at 10:48:27PM -0800, Garrett Cooper wrote:
Weongyo, et all,
On Wed, Mar 10, 2010 at 10:29 PM, FreeBSD Tinderbox
/src/sys/modules/siba_bwn/../../dev/siba/siba_core.c:2035: error: request
for member 'sd_bus' in something not a structure or union
*** Error code 1
Stop in /src/sys/modules/siba_bwn.
*** Error code 1
Stop in /src/sys/modules.
*** Error code 1
Stop in /obj/powerpc/src/sys/LINT.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2010-03-11 06:29:31 - WARNING: /usr/bin/make returned exit code ?1
TB --- 2010-03-11 06:29:31 - ERROR: failed to build lint kernel
TB --- 2010-03-11 06:29:31 - 3629.47 user 614.12 system 4685.83 real
Could someone please try this patch to see whether or not it fixes
the void* deref issue? I don't think it's style(9) correct, but it
might resolve the issue.
Thanks,
-Garrett
Index: siba_core.c
===
--- siba_core.c (revision 204996)
+++ siba_core.c (working copy)
@@ -2032,9 +2032,9 @@
siba_dma_translation(device_t dev)
{
- KASSERT(device_get_ivars(dev)-sd_bus-siba_type == SIBA_TYPE_PCI,
- (unsupported bustype %d\n,
- device_get_ivars(dev)-sd_bus-siba_type));
+ KASSERT(((struct siba_softc *)
device_get_ivars(dev))-sd_bus-siba_type ==
+ SIBA_TYPE_PCI, (unsupported bustype %d\n,
+ ((struct siba_softc*) device_get_ivars(dev))-sd_bus-siba_type));
It was all getting a bit unwieldy, I committed a more simple fix in
r205003.
___
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: Error 127.0.0.1: no route to host
Without the route.h patch, I can't ping 127.0.0.1 or the local or remote address of the OpenVPN tunnel (on tap0). In fact, you can't even build OpenVPN from ports as it'll fail its self-test. Please see my previous clarification email on the what and the why about the route.h.diff patch. I spent some time looking into the issue and found the problem is the if_tap interface turns out to be one of those interfaces that claims to be of IFT_ETHER type, but does not touch the if_link_state variable. With the route.h patch, I can ping all local addresses but not the far end of the tunnel. Please try the new patch at http://people.freebsd.org/~qingli/ecmp-tap.diff Let me know how it works out for you. -- Qing P.S. You really just need the 2-line fix in the if_tap.c file. route.h is slightly touch to be (ifp) instead of just ifp in the macro. ___ 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: A tool for remapping bad sectors in CURRENT?
On Mon, 08.03.2010 at 13:09:19 +0200, Eugene Dzhurinsky wrote: On Mon, Mar 08, 2010 at 12:52:43PM +0200, Eugene Dzhurinsky wrote: dd if=/dev/ad4 of=/dev/null skip=222342559 bs=512 count=1 dd: /dev/ad4: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 2.351940 secs (0 bytes/sec) dd if=/dev/zero of=/dev/ad4 seek=222342559 bs=512 count=1 dd: /dev/ad4: Operation not permitted Should I do it in single mode? sysctl kern.geom.debugflags=0x10 Did the trick, I was able to write directly to the sector, and now it seems to work well. No remaps recorded thus, but no errors so far. It's too late now, but you really should have gone with something like # recoverdisk /dev/ad4 /dev/ad4 this will re-write all blocks on the disk, it may fail at reading block 222342559, but there's a chance that the disk error correction gets it right after a couple of times. Regards, Uli ___ 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: Error 127.0.0.1: no route to host
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/10 05:52, Li, Qing wrote: I spent some time looking into the issue and found the problem is the if_tap interface turns out to be one of those interfaces that claims to be of IFT_ETHER type, but does not touch the if_link_state variable. [ .. ] Please try the new patch at http://people.freebsd.org/~qingli/ecmp-tap.diff Let me know how it works out for you. This solves all the noted issues - thanks! imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuY/BAACgkQQv9rrgRC1JLoxACeLApgw4GJzTpukzV4AHzp9ffm 4XwAn1GbXEojETUiXgAze7hIfgNcJSDF =5iWa -END PGP SIGNATURE- ___ 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
HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
As a result of importing 32-bit compatibility support for non-x86 64-bit platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 in revision 205014, so all kernel configurations including this option must be modified accordingly. -Nathan ___ 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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
Hi,
On Thu, 11 Mar 2010 08:50:05 -0600
Nathan Whitehorn nwhiteh...@freebsd.org said:
nwhitehorn As a result of importing 32-bit compatibility support for non-x86
64-bit
nwhitehorn platforms, the kernel options COMPAT_IA32 has been renamed
nwhitehorn COMPAT_FREEBSD32 in revision 205014, so all kernel configurations
nwhitehorn including this option must be modified accordingly.
Doesn't this mean we cannot have FreeBSD version 32? :)
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Fri, 12 Mar 2010, Hajimu UMEMOTO wrote: Hi, On Thu, 11 Mar 2010 08:50:05 -0600 Nathan Whitehorn nwhiteh...@freebsd.org said: nwhitehorn As a result of importing 32-bit compatibility support for non-x86 64-bit nwhitehorn platforms, the kernel options COMPAT_IA32 has been renamed nwhitehorn COMPAT_FREEBSD32 in revision 205014, so all kernel configurations nwhitehorn including this option must be modified accordingly. Doesn't this mean we cannot have FreeBSD version 32? :) Think like the U.S. government and push the problem off to the great*N-grandchildren. ;) Sean -- s...@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
Re: A tool for remapping bad sectors in CURRENT?
Miroslav Lachman 000.f...@quip.cz writes: Yes, rewriting by dd or any other way works for reallocating or clearing pending sectors counter, but in server environment In a server environment, you'd be a fool not to have some sort of redundancy set up. I need to know the affected file, as it can be for example database file and then it is a big problem! Rewriting the sector inside InnoDB ib_data file can cause DB crash, data loss etc. How is that different from *not* rewriting the sector? If there's a bad sector somewhere in your data, your database is still going to crash. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: A tool for remapping bad sectors in CURRENT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.03.2010 16:21, Dag-Erling Smørgrav wrote: Miroslav Lachman 000.f...@quip.cz writes: Yes, rewriting by dd or any other way works for reallocating or clearing pending sectors counter, but in server environment In a server environment, you'd be a fool not to have some sort of redundancy set up. I need to know the affected file, as it can be for example database file and then it is a big problem! Rewriting the sector inside InnoDB ib_data file can cause DB crash, data loss etc. How is that different from *not* rewriting the sector? If there's a bad sector somewhere in your data, your database is still going to crash. Only if he hasn't listened to your first advice and set it up on a non-redundant IO solution. If he's set it up on proper hardware, he'll just get a friendly mail about replacing said disk next time he's in the serverroom with a new fresh hostpare. //Svein - -- - +---+--- /\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE - +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - Picture Gallery: https://gallery.stillbilde.net/v/svein/ - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuZCyQACgkQODUnwSLUlKS2ngCgqF+bE4SqHC39lYAoMpQG1Ysb IzcAoLusP1O4LV0CDoq3GSXjV3YGDLDk =Ljac -END PGP SIGNATURE- ___ 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: Error 127.0.0.1: no route to host
On Thu, Mar 11, 2010 at 09:20:00AM -0500, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/10 05:52, Li, Qing wrote: I spent some time looking into the issue and found the problem is the if_tap interface turns out to be one of those interfaces that claims to be of IFT_ETHER type, but does not touch the if_link_state variable. [ .. ] Please try the new patch at http://people.freebsd.org/~qingli/ecmp-tap.diff Let me know how it works out for you. This solves all the noted issues - thanks! same here many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: As a result of importing 32-bit compatibility support for non-x86 64-bit platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 in revision 205014, so all kernel configurations including this option must be modified accordingly. That sounds a bit confusing, compatibility with FreeBSD 3.2? ___ 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
SMP deadlock during multi-user mode transition after r204866
My build machine (dmesg attached) is a dual CPU, single-core box; my laptop is a single CPU, single-core box. I track head on each daily; while the build machine has been locking up during the transition to multi-user mode since Tuesday (when I had built CURRENT at r204909; previous was r204866, on Monday) -- and it boots to single-user mode OK -- the laptop has not exhibited the problem. This build machine was deployed fairly recently, and since a GENERIC kernel had been working OK, I had left it that way (so that's the kernel config). I have a more customized config I had used on its predecessor; I'm pretty sure I had that set up with DDB assorted other goodies to try to get something useful out of a misbehaviing system, and am willing to set that up (but probably won't have time for several hours, at least, as I need to give a presentation at a work meeting). One of the more peculiar symptoms is that after such a lock-up, I power-cycle the machine, then boot to single-user mode, at which point I typically start with fsck -p However, since Tuesday, that attempt yields: Enter full pathname of shell or RETURN for /bin/sh: # fsck -p /dev/aacd0s4a: LINK COUNT DIR I=2 OWNER=root MODE=40755 /dev/aacd0s4a: SIZE=1024 MTIME=Mar 11 08:30 2010 COUNT 26 SHOULD BE 27 /dev/aacd0s4a: LINK COUNT INCREASING /dev/aacd0s4a: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. # My circumvention of choice at the moment is: # fsck -y / fsck -p as it appears that the root file system is the only one thus affected. Is this sufficently well understood already that I should stop disturbing folks who are trying to fix it? Would it be usful for me to configure a kernel that supports DDB provide a backtrace (and maybe additional stuff)? To clarify, it appears that something after r204866 but no later than r204909 has caused the observed problem. Thanks. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #92: Mon Mar 8 06:14:22 PST 2010 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.54-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x659dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR AMD Features=0x2010NX,LM TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2086187008 (1989 MB) ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard kbd1 at kbdmux0 acpi0: PTLTD RSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pci0: base peripheral at device 1.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 aac0: Adaptec SCSI RAID 2200S mem 0xdc00-0xdfff irq 24 at device 1.0 on pci2 aac0: Enable Raw I/O aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 2200S, aac driver 2.1.9-1 aacp0: SCSI Passthrough Bus on aac0 aacp1: SCSI Passthrough Bus on aac0 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em0: Intel(R) PRO/1000 Network Connection 6.9.25 port 0x2000-0x203f mem 0xd820-0xd821 irq 54 at device 2.0 on pci3 em0: [FILTER] em0: Ethernet address: 00:30:48:2d:32:6a em1: Intel(R) PRO/1000 Network Connection 6.9.25 port 0x2040-0x207f mem 0xd822-0xd823 irq 55 at device 2.1 on pci3 em1: [FILTER] em1: Ethernet address: 00:30:48:2d:32:6b pcib4: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 16 at device 6.0 on pci0 pci5: ACPI PCI bus on pcib5 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0x1400-0x141f irq 16 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: Intel
Re: hang in rpccon from interrupting NFS operations (Re: pointyhat panic)
On Wed, 10 Mar 2010, Adrenalin wrote: I'll put my heart into the teeth and will try to go for the stable. You can just apply this one patch to your 8.0 kernel, there is no need to go to stable/8 (at least for this fix). This is kind of critical I guess, I think it should really go to the release. It's the first time I got into a such a nasty bug with freebsd. It wasn't identified until the release was headed out the door, so it couldn't make it in, but will be in 8.1. rick ___ 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: [head tinderbox] failure on powerpc/powerpc
On Thu, Mar 11, 2010 at 09:10:35PM +1300, Andrew Thompson wrote:
On Wed, Mar 10, 2010 at 10:48:27PM -0800, Garrett Cooper wrote:
Weongyo, et all,
On Wed, Mar 10, 2010 at 10:29 PM, FreeBSD Tinderbox
/src/sys/modules/siba_bwn/../../dev/siba/siba_core.c:2035: error: request
for member 'sd_bus' in something not a structure or union
*** Error code 1
Stop in /src/sys/modules/siba_bwn.
*** Error code 1
Stop in /src/sys/modules.
*** Error code 1
Stop in /obj/powerpc/src/sys/LINT.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2010-03-11 06:29:31 - WARNING: /usr/bin/make returned exit code ?1
TB --- 2010-03-11 06:29:31 - ERROR: failed to build lint kernel
TB --- 2010-03-11 06:29:31 - 3629.47 user 614.12 system 4685.83 real
Could someone please try this patch to see whether or not it fixes
the void* deref issue? I don't think it's style(9) correct, but it
might resolve the issue.
Thanks,
-Garrett
Index: siba_core.c
===
--- siba_core.c (revision 204996)
+++ siba_core.c (working copy)
@@ -2032,9 +2032,9 @@
siba_dma_translation(device_t dev)
{
- KASSERT(device_get_ivars(dev)-sd_bus-siba_type == SIBA_TYPE_PCI,
- (unsupported bustype %d\n,
-device_get_ivars(dev)-sd_bus-siba_type));
+ KASSERT(((struct siba_softc *)
device_get_ivars(dev))-sd_bus-siba_type ==
+ SIBA_TYPE_PCI, (unsupported bustype %d\n,
+ ((struct siba_softc*) device_get_ivars(dev))-sd_bus-siba_type));
It was all getting a bit unwieldy, I committed a more simple fix in
r205003.
Thank you for fix and sorry for break build.
regards,
Weongyo Jeong
___
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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik mike.jaku...@intertainservices.com wrote: On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: As a result of importing 32-bit compatibility support for non-x86 64-bit platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 in revision 205014, so all kernel configurations including this option must be modified accordingly. That sounds a bit confusing, compatibility with FreeBSD 3.2? I agree that the name COMPAT_FREEBSD32 is confusing, does it mean compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. Scot ___ 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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel swhet...@gmail.com wrote: On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik mike.jaku...@intertainservices.com wrote: On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: As a result of importing 32-bit compatibility support for non-x86 64-bit platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 in revision 205014, so all kernel configurations including this option must be modified accordingly. That sounds a bit confusing, compatibility with FreeBSD 3.2? I agree that the name COMPAT_FREEBSD32 is confusing, does it mean compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. Agreed. Is it possible to change the name again because it really hasn't gotten much traction yet? Thanks, -Garrett ___ 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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
In message: 7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com Garrett Cooper yanef...@gmail.com writes: : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel swhet...@gmail.com wrote: : On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik : mike.jaku...@intertainservices.com wrote: : On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: : : As a result of importing 32-bit compatibility support for non-x86 64-bit : platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 : in revision 205014, so all kernel configurations including this option must : be modified accordingly. : : : That sounds a bit confusing, compatibility with FreeBSD 3.2? : : I agree that the name COMPAT_FREEBSD32 is confusing, does it mean : compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. : : A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. : : Agreed. Is it possible to change the name again because it really : hasn't gotten much traction yet? What does the name matter, really? This will be documented, and mirrors the kernel source compat/freebsd32. Put another way: if everybody that's going to comment on the name would instead fix one bug from the PR database with the time they spend commenting on it, would FreeBSD be better or worse off than spending dozens of hours arguing over COMPAT_X32 vs COMPAT_Y32 vs COMPAT_FLYING_MONKEYS? Warner ___ 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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Thu, Mar 11, 2010 at 9:24 PM, M. Warner Losh i...@bsdimp.com wrote: In message: 7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com Garrett Cooper yanef...@gmail.com writes: : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel swhet...@gmail.com wrote: : On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik : mike.jaku...@intertainservices.com wrote: : On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: : : As a result of importing 32-bit compatibility support for non-x86 64-bit : platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 : in revision 205014, so all kernel configurations including this option must : be modified accordingly. : : : That sounds a bit confusing, compatibility with FreeBSD 3.2? : : I agree that the name COMPAT_FREEBSD32 is confusing, does it mean : compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. : : A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. : : Agreed. Is it possible to change the name again because it really : hasn't gotten much traction yet? What does the name matter, really? This will be documented, and mirrors the kernel source compat/freebsd32. Put another way: if everybody that's going to comment on the name would instead fix one bug from the PR database with the time they spend commenting on it, would FreeBSD be better or worse off than spending dozens of hours arguing over COMPAT_X32 vs COMPAT_Y32 vs COMPAT_FLYING_MONKEYS? Warner Just for that, I nominate Nathan rename the option to COMPAT_FLYING_MONKEYS32. ___ 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
sctp ipv6 csum issue
Nigel:
Here is a patch for your issue I think.
Its off of a head machine but I think it should apply. If not
let me know.
See if this does not fix the issue.
Thanks
R
Index: ip6_output.c
===
--- ip6_output.c(revision 205059)
+++ ip6_output.c(working copy)
@@ -208,6 +208,9 @@
struct route_in6 *ro_pmtu = NULL;
int hdrsplit = 0;
int needipsec = 0;
+#ifdef SCTP
+ int sw_csum;
+#endif
#ifdef IPSEC
struct ipsec_output_state state;
struct ip6_rthdr *rh = NULL;
@@ -829,6 +832,10 @@
}
m-m_pkthdr.csum_flags |=
CSUM_IP_CHECKED | CSUM_IP_VALID;
+#ifdef SCTP
+ if (m-m_pkthdr.csum_flags CSUM_SCTP)
+ m-m_pkthdr.csum_flags |= CSUM_SCTP_VALID;
+#endif
error = netisr_queue(NETISR_IPV6, m);
goto done;
} else
@@ -857,6 +864,13 @@
* 4: if dontfrag == 1 alwaysfrag == 1
* error, as we cannot handle this conflicting request
*/
+#ifdef SCTP
+ sw_csum = m-m_pkthdr.csum_flags ~ifp-if_hwassist;
+ if (sw_csum CSUM_SCTP) {
+ sctp_delayed_cksum(m);
+ sw_csum = ~CSUM_SCTP;
+ }
+#endif
tlen = m-m_pkthdr.len;
if (opt (opt-ip6po_flags IP6PO_DONTFRAG))
--
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)
___
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: sctp ipv6 csum issue
Opps:
I was a little to quick, .. that one won't work.. but I
think this one will (need to have the right magic header
goo :-D)
Try this please (this one will build and actually do something :-D)
R
Index: ip6_output.c
===
--- ip6_output.c(revision 205059)
+++ ip6_output.c(working copy)
@@ -66,6 +66,7 @@
#include opt_inet.h
#include opt_inet6.h
#include opt_ipsec.h
+#include opt_sctp.h
#include sys/param.h
#include sys/kernel.h
@@ -102,6 +103,10 @@
#include netipsec/key.h
#include netinet6/ip6_ipsec.h
#endif /* IPSEC */
+#ifdef SCTP
+#include netinet/sctp.h
+#include netinet/sctp_crc32.h
+#endif
#include netinet6/ip6protosw.h
#include netinet6/scope6_var.h
@@ -208,6 +213,9 @@
struct route_in6 *ro_pmtu = NULL;
int hdrsplit = 0;
int needipsec = 0;
+#ifdef SCTP
+ int sw_csum;
+#endif
#ifdef IPSEC
struct ipsec_output_state state;
struct ip6_rthdr *rh = NULL;
@@ -829,6 +837,10 @@
}
m-m_pkthdr.csum_flags |=
CSUM_IP_CHECKED | CSUM_IP_VALID;
+#ifdef SCTP
+ if (m-m_pkthdr.csum_flags CSUM_SCTP)
+ m-m_pkthdr.csum_flags |= CSUM_SCTP_VALID;
+#endif
error = netisr_queue(NETISR_IPV6, m);
goto done;
} else
@@ -857,6 +869,13 @@
* 4: if dontfrag == 1 alwaysfrag == 1
* error, as we cannot handle this conflicting request
*/
+#ifdef SCTP
+ sw_csum = m-m_pkthdr.csum_flags ~ifp-if_hwassist;
+ if (sw_csum CSUM_SCTP) {
+ sctp_delayed_cksum(m);
+ sw_csum = ~CSUM_SCTP;
+ }
+#endif
tlen = m-m_pkthdr.len;
if (opt (opt-ip6po_flags IP6PO_DONTFRAG))
On Mar 12, 2010, at 11:47 AM, Randall Stewart wrote:
Nigel:
Here is a patch for your issue I think.
Its off of a head machine but I think it should apply. If not
let me know.
See if this does not fix the issue.
Thanks
R
patch.ip6_output.txt
--
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)
___
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
--
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)
___
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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Mar 11, 2010, at 6:14 PM, Scot Hetzel wrote: On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik mike.jaku...@intertainservices.com wrote: On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: As a result of importing 32-bit compatibility support for non-x86 64-bit platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 in revision 205014, so all kernel configurations including this option must be modified accordingly. That sounds a bit confusing, compatibility with FreeBSD 3.2? I agree that the name COMPAT_FREEBSD32 is confusing, does it mean compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. Seriously, this is being debated? FreeBSD 3.2? Is this a joke? I caught the humor in the first couple of replies, but you sound serious. Wow. Scott ___ 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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Thu, Mar 11, 2010 at 6:24 PM, M. Warner Losh i...@bsdimp.com wrote: In message: 7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com Garrett Cooper yanef...@gmail.com writes: : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel swhet...@gmail.com wrote: : On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik : mike.jaku...@intertainservices.com wrote: : On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: : : As a result of importing 32-bit compatibility support for non-x86 64-bit : platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 : in revision 205014, so all kernel configurations including this option must : be modified accordingly. : : : That sounds a bit confusing, compatibility with FreeBSD 3.2? : : I agree that the name COMPAT_FREEBSD32 is confusing, does it mean : compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. : : A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. : : Agreed. Is it possible to change the name again because it really : hasn't gotten much traction yet? What does the name matter, really? This will be documented, and mirrors the kernel source compat/freebsd32. Put another way: if everybody that's going to comment on the name would instead fix one bug from the PR database with the time they spend commenting on it, would FreeBSD be better or worse off than spending dozens of hours arguing over COMPAT_X32 vs COMPAT_Y32 vs COMPAT_FLYING_MONKEYS? I can haz PR review then? Here's an easy one :)... http://www.freebsd.org/cgi/query-pr.cgi?pr=144644 Thanks, -Garrett ___ 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
