Re: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?

[Giovanni Trematerra]

On Wed, Mar 10, 2010 at 11:07 PM, Tom Couch  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

[Andrew Thompson]

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

[Li, Qing]

> 
> 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?

[Ulrich Spörlein]

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

[Michael Butler]

-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

[Nathan Whitehorn]

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

[Hajimu UMEMOTO]

Hi,

> On Thu, 11 Mar 2010 08:50:05 -0600
> Nathan Whitehorn  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

[Sean C. Farley]

On Fri, 12 Mar 2010, Hajimu UMEMOTO wrote:


Hi,


On Thu, 11 Mar 2010 08:50:05 -0600
Nathan Whitehorn  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?

[Dag-Erling Smørgrav]

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?

[Svein Skogen (Listmail Account)]

-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

[Anton Shterenlikht]

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

[Mike Jakubik]

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

[David Wolfskill]

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=0xbfebfbff
  Features2=0x659d
  AMD Features=0x2010
  TSC: P-state invariant
real memory  = 2147483648 (2048 MB)
avail memory = 2086187008 (1989 MB)
ACPI APIC Table: 
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  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
ioapic2  irqs 48-71 on motherboard
kbd1 at kbdmux0
acpi0:  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:  on acpi0
cpu1:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pci0:  at device 0.1 (no driver attached)
pci0:  at device 1.0 (no driver attached)
pcib1:  irq 16 at device 2.0 on pci0
pci1:  on pcib1
pcib2:  at device 0.0 on pci1
pci2:  on pcib2
aac0:  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:  on aac0
aacp1:  on aac0
pcib3:  at device 0.2 on pci1
pci3:  on pcib3
em0:  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:  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:  irq 16 at device 4.0 on pci0
pci4:  on pcib4
pcib5:  irq 16 at device 6.0 on pci0
pci5:  on pcib5
uhci0:  port 0x1400-0x141f irq 16 at 
device 29.0 on pci0
uhci0: [ITHREAD]
usbus0:  on uhci0
uhci1:  port 0x1420-0x143f irq 19 at 
device 29.1 on pci0
uhci1: [ITHREAD]
usbus1:  on uhci1
uhci2:  port 0x1440-0x145f irq 18 at 
device 29.2 on pci0
uhci2: [ITHREAD]
usbus2:  on uhci2
uhci3:  port 0x1460-0x147f irq 16 at 
device 29.3 on pci0
uhci3: [ITHREAD]
usbus3:  on uhci3
ehci0:  mem 0xd8001000-0xd80013ff 
irq 23 at device 29.7 on pci0
ehci0: [ITHREAD]
usbus4: EHCI version 1.0
usbus4:  on ehci0
pcib6:  at device 30.0 on pci0
pci6:  on pcib6
vgapci0:  port 0x3000-0x30ff mem 
0xd900-0xd9ff,0xd830-0xd8300fff irq 17 at device 1.0 on pci6
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x

Re: hang in rpccon from interrupting NFS operations (Re: pointyhat panic)

[Rick Macklem]

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

[Weongyo Jeong]

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

[Scot Hetzel]

On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
 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

[Garrett Cooper]

On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel  wrote:
> On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
>  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

[M. Warner Losh]

In message: <7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com>
Garrett Cooper  writes:
: On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel  wrote:
: > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
: >  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

[Justin Hibbits]

On Thu, Mar 11, 2010 at 9:24 PM, M. Warner Losh  wrote:

> In message: <7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com>
>Garrett Cooper  writes:
> : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel  wrote:
> : > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
> : >  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

[Randall Stewart]

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

[Randall Stewart]

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 
 #include 
@@ -102,6 +103,10 @@
 #include 
 #include 
 #endif /* IPSEC */
+#ifdef SCTP
+#include 
+#include 
+#endif
 
 #include 
 #include 
@@ -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

--
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

[Scott Long]

On Mar 11, 2010, at 6:14 PM, Scot Hetzel wrote:
> On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
>  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

[Garrett Cooper]

On Thu, Mar 11, 2010 at 6:24 PM, M. Warner Losh  wrote:
> In message: <7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com>
>            Garrett Cooper  writes:
> : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel  wrote:
> : > On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik
> : >  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"