Re: the future of sun4v
Marius Strobl wrote: On Fri, Aug 22, 2008 at 01:44:25PM +0200, Kris Kennaway wrote: Peter Jeremy wrote: [Replies re-directed to freebsd-sun4v] On 2008-Aug-21 14:42:55 -0700, Kip Macy [EMAIL PROTECTED] wrote: I believe that there is a general expectation by freebsd users and developers that unsupported code should not be in CVS. Although sun4v is a very interesting platform for developers doing SMP work, I simply do not have the time or energy to maintain it. If someone else would like to step up and try his hand I would be supportive of his efforts. In the likely event that no one steps forward by the time that 7.1 is released I will ask that it be moved to the Attic. Since there are no other current SPARC CPUs that FreeBSD can run on (the US-II has been obsolete for about 6 years and FreeBSD won't run on any more recent sun4u chips), that will also remove the justification for maintaining a SPARC64 port. I don't have the knowledge or available time to maintain the sun4v port by myself but would be happy to be part of a team doing so. One impediment I have is that I don't have a T-1 or T-2 system that I can dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but since FreeBSD doesn't support either the virtual disk or virtual network, actually getting FreeBSD running there presents somewhat of a challenge. There are two t1000 systems in the freebsd.org cluster that are available for people to work on. Rink Springer has also expressed interest in this. Perhaps Kip can explain some more about what things he looked at, but the most serious bugs might be in pmap or perhaps trap handling. Operationally, things like buildworld -jN die quickly with random signals, kernel traps, etc. Kris P.S. It looks like marius has made progress on US III but sun4u is still an architectural dead end. Well, let's see what architecture the upcoming Rock CPUs are; judging their feature list they appear to be a continuation of the Fujitsu sun4u line rather than a successor of UST1/2 :) That's inaccurate. Rock is meant to be very compatible with sun4v, although I don't know if uname will say sun4v or something else...but you will need a bug-free sun4v operating system to run them (which is to say that various bugs in the solaris sun4v support needed to get fixed rather than left...) The critical issue for freebsd (and any operating system for that matter) on rock is how well does the kernel scale to a system with that many concurrent threads? Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem compiling RELENG_6
My apologies I forgot to do a cvs commit of sbin/ipf in addition to contrib/ipfilter and sys/contrib/ipfilter. I've just done a commit that should fix this. Cheers, Darren Jeremy Chadwick wrote: On Sun, Nov 18, 2007 at 01:03:28PM -0300, Daniel Molina Wegener wrote: I've downloaded the RELENG_6 through csup. While compiling the source with make buildworld I get the next error: -8--8--8--8--8- === sbin/ipf/libipf (depend) make: don't know how to make extras.c. Stop *** Error code 2 -8--8--8--8--8- Same problem with genmask.c, getline.c, hexdump.c and other files. This probably should've gone to freebsd-stable instead. A recent commit from the IPFilter author may have induced this; I can't check for you because the webserver on www.freebsd.org (where cvsweb lives) is presently irritated in some way. Anyways, see Darren's mail below: From: Darren Reed [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 18 Nov 2007 03:06:09 -0800 Subject: RELENG_6 IPFilter MFC I've just completed an MFC of IPFIilter in the FreeBSD 6 branch (RELENG_6) from HEAD. This brings the code used for IPFilter in FreeBSD into sync on each of HEAD, RELENG_6 and RELENG_7. Hopefully I can close one or two bug reports now ;) If you encounter any problems, please let me know. Cheers, Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Question about cvsup...
Nearly every time I run cvsup from the command line (as root), I see large amounts of output like this for every file: SetAttrs src/contrib/amd/fsinfo/wr_fstab.c,v Is cvsup actually doing anything? Have I done something wrong in my config? (I run in with cvsup -l lockfile -g -L 1 ncvs-supfile) Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Look like IPFilter problem
Please file a PR. Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Experiences with 7.0-CURRENT and vmware.
I'm using FreeBSD 7.0-CURRENT under vmware and there are a few issues. First, time. hint.hw.acpi.disabled=1 This appears to make _no_ difference to time keeping on FreeBSD 7 and nor does it seem to have any impact on ACPI being loaded. Do I need to recompile a new kernel without it or is there a new way to disable ACPI? I should add that FreeBSD 6, with the same setting, is no better and that I need to run ntpdate every 5-10 minutes via crontab in order to keep good time (timekeeping is *really* bad.) In one instance, i was watching zpool iostat 1 and it appeared like the rows were muching up at a rate of 2 a second for a minute or so. How do I disable TSC timekeeping? (NetBSD has this disabled by default in their kernels.) Or is there somethign else I must do? Second, networking. Prior to FreeBSD-7, the driver to use inside vmware workstation was lnc. It has worked and contiues to work great. No problemo. FreeBSD-7 uses the em driver. To put it simply, it sucks in comparison. When things really get bad I start seeing em0: watchdog timeout messages on the console. I looked and I don't see a lnc driver anywhere. Is there another alternative (le?) driver that I can use in place of em, if so, how? Apart from these two issues (which are very central ones :-(), I'm using FreeBSD in a 64bit vmware workstation environment quick successfully and ZFS is quite happy with all the kva :-) ZFS and zpools are working just as I expect, even if a bit slower due to vmware but I'm not cranking out benchmarks here. Oh, and how do I fix ssh/rsh to do passwordless sessions? I'm trying to setup cron jobs to automate various tasks but there's this small hurdle called a password prompt that I can't seem to get rid of :-/ Cheers, Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Experiences with 7.0-CURRENT and vmware.
On Thu, May 10, 2007 at 01:28:16PM +0100, Robert Watson wrote: On Thu, 10 May 2007, Darren Reed wrote: I'm using FreeBSD 7.0-CURRENT under vmware and there are a few issues. Redirecting to [EMAIL PROTECTED] First, time. hint.hw.acpi.disabled=1 This appears to make _no_ difference to time keeping on FreeBSD 7 and nor does it seem to have any impact on ACPI being loaded. Do I need to recompile a new kernel without it or is there a new way to disable ACPI? Have you tried hint.acpi.0.disabled=1 instead? This is what appears in acpi(4), and is what is used in various existing boot loader bits when I grep around. In another reply it was hint.apic.0.disabled=1. My current loader.conf: vm.kmem_size=536870912 vm.kmem_size_max=536870912 unset acpi_load hint.acpi.0.disabled=1 hint.apci.0.disabled=1 hint.acpi.0.disabled=1 hint.apci.0.disabled=1 vfs.zfs.arc_max=402653184 Booting with this gives me: kernel: Timecounter ACPI-safe frequency 3579545 Hz quality 1000 and ACPI enabled. I should add that FreeBSD 6, with the same setting, is no better and that I need to run ntpdate every 5-10 minutes via crontab in order to keep good time (timekeeping is *really* bad.) In one instance, i was watching zpool iostat 1 and it appeared like the rows were muching up at a rate of 2 a second for a minute or so. How do I disable TSC timekeeping? (NetBSD has this disabled by default in their kernels.) Or is there somethign else I must do? kern.timecounter.hardware: ACPI-fast kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) I believe you can simply set kern.timecounter.hardware=APCI-fast and it will do what you expect. An interesting question is why it selects what is arguably the wrong one; a post to current@ might help resolve that. Hmm. # sysctl kern.timecounter.hardware=ACPI-fast kern.timecounter.hardware: ACPI-safe sysctl: kern.timecounter.hardware: Invalid argument Or is this a loader.conf setting? Second, networking. Prior to FreeBSD-7, the driver to use inside vmware workstation was lnc. It has worked and contiues to work great. No problemo. FreeBSD-7 uses the em driver. To put it simply, it sucks in comparison. When things really get bad I start seeing em0: watchdog timeout messages on the console. I looked and I don't see a lnc driver anywhere. Is there another alternative (le?) driver that I can use in place of em, if so, how? Has VMware changed what network hardware they emulate, and/or does VMware offer options about what virtual hardware to expose? I don't believe so. It still probes as pcn under NetBSD. The if_em driver is for Intel ethernet cards; historically VMware has exposed a Lance ethernet device supported by the lnc(4) device driver; now that driver has indeed been replaced with le(4). Right. I believe it still is lance, but somehow em is showing up. But if if_em is probing, it suggests a VMware change rather than a FreeBSD change, which you may be able to revert by telling it to expose a Lance-style device as opposed to an Intel device. There's no way to choose the type of card vmware emulates. Generally speaking, this would be a discouraged configuration, but you will probably need to frob two settings: first, PermitEmptyPasswords in sshd_config, and second, force non-PAM validation by setting UsePAM to false. Instead of doing this, I would advise instead setting up an SSH key for the account, and not set a passphrase on the SSH key. This doesn't require any changing of the global sshd configuration and should offer most of the same benefits. btw, there are instances where you can be promopted 6 times for a password when logging in with ssh, 3 times with Password: prompt and another three with [EMAIL PROTECTED]'s password: promopt. Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH for review: ipfilter changes in rc.*
In some email I received from Arjan de Vet, sie wrote: Darren Reed wrote: In some email I received from Arjan de Vet, sie wrote: I wrote similar patches (see http://home.iae.nl/users/devet/freebsd/) trying to fix more or less the same bugs/problems. Maybe it's a good idea if Giorgos and I together come up with 1 'big' ipfilter /etc/rc.* and rc.conf.5 patch which includes the best parts of both our patches? That sounds like a good plan. OK, updated patches for stable and current are available from: http://home.iae.nl/users/devet/freebsd/ I include the README here: [...] How is this progressing ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipfilter changes in rc.network (was: Re: cvs commit: src/etc rc.network)
In some email I received from Giorgos Keramidas, sie wrote: On Tue, Oct 23, 2001 at 07:45:11PM +0200, Gerhard Sittig wrote: I get the feeling this - inappropriate - setting of a _program variable is due to my misguided suggestion in PR conf/20202 which verbatimly made it into the FreeBSD start scripts. If it doesn't fit the usual rules feel free to correct it! :) After all I was a newbee to FreeBSD then (and still I'm not a guru or seasoned hacker:) as well as I understand Darren to do his daytime job with SunOS / Solaris and since he might need some hints on how his software fits even better into FreeBSD. I guess he will happily accept patches improving a wrong approach. Maybe there's need for the following parts: - ipfilter_program - ipfilter_prerules_flags - ipfilter_rules - ipfilter_postrules_flags ? The current situation comes from the fact that I wanted to have a single variable with the rules file only - to check for its existance (if such an additional constraints check matters). Done. I tested on my -current (compiled on Oct 22) the patch you can find at http://labs.gr/~charon/patches/diff.04.ipf-rc-U It is functionally equivalent to our current rc.network behavior, but it uses the variables you proposed, and it moves all the flags out of all the XXX_program variables. How many of the patches at http://labs.gr/~charon/patches/ should go into FreeBSD-current ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: User-defined bit in sysctl flags ?
In some email I received from Alfred Perlstein, sie wrote: * Darren Reed [EMAIL PROTECTED] [010416 13:37] wrote: What do people think about having a range of bits in oid_kind that are not used by FreeBSD but are only to be used by ``private'' sysctl handlers? e.g. #define CTLFLAG_PRIVATE 0x0000 Do I need elaborate any further ? I think a half-paragraph explaining what this does would help. :) I'm assuming this allows someone to have thier own private numbered mib in the sysctl tree, my question is why are you using hardcoded numbers rather than names? Uh, no. The idea is so you can do this: #define SYSCTL_IPF(parent, nbr, name, access, ptr, val, descr) \ SYSCTL_OID(parent, nbr, name, CTLTYPE_INT|access, \ ptr, val, sysctl_ipf_int, "I", descr); SYSCTL_IPF(_net_inet_ipf, OID_AUTO, fr_tcpidletimeout, CTLFLAG_RW|CTL_PRIV, fr_tcpidletimeout, 0, ""); and have CTL_PRIV be a bit which sysctl_ipf_int understands and not have to worry about the value of CTL_PRIV ever being afflicted with double-use by a FreeBSD flag because CTL_PRIV is part of CTLFLAG_PRIVATE. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
User-defined bit in sysctl flags ?
What do people think about having a range of bits in oid_kind that are not used by FreeBSD but are only to be used by ``private'' sysctl handlers? e.g. #define CTLFLAG_PRIVATE 0x0000 Do I need elaborate any further ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
inetsw, struct protosw and struct ipprotosw
Just looking in /sys/netinet and I see this:
(freefall:~/src/sys/netinet) grep 'inetsw' *.c | grep protosw
in_proto.c:struct ipprotosw inetsw[] = {
in_proto.c: (struct protosw *)inetsw,
in_proto.c: (struct protosw *)inetsw[sizeof(inetsw)/sizeof(inetsw[0])], 0,
ip_fil.c:extern struct protosw inetsw[];
ip_icmp.c:externstruct protosw inetsw[];
ip_input.c:extern struct ipprotosw inetsw[];
ip_mroute.c:extern struct protosw inetsw[];
ip_output.c:extern struct protosw inetsw[];
To me this looks like a recipe for disaster.
Why is there "struct ipprotosw inetsw" and "struct protosw inetsw" ?
Does this really mean that someone wanted to change "struct protosw"
and instead made up "struct ipprotosw" and are trying to squeeze that
somehow into "protosw" ?
Ideally I should be able to put inetsw into a header file and extern it,
but with this, I don't see how that would make sense...
Darren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
COMPAT_43 and kernel compiles.
Is it meant to be possible to compile a kernel *without* COMPAT_43 ? Has anyone else tried this recently ? For me, it seems to break the compile in (at least) kern_sig.c Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: COMPAT_43 and kernel compiles.
In some mail from John Baldwin, sie said: Darren Reed wrote: Is it meant to be possible to compile a kernel *without* COMPAT_43 ? Has anyone else tried this recently ? For me, it seems to break the compile in (at least) kern_sig.c From /sys/i386/conf/NOTES: # # Implement system calls compatible with 4.3BSD and older versions of # FreeBSD. You probably do NOT want to remove this as much current code # still relies on the 4.3 emulation. # options COMPAT_43 If it is to not be an option, then it should be deprecated as an option and all of that removed. FWIW, I tested NetBSD-current without this option and it compiles cleanly (not that I used it). Seems like someone needs to make a decision one way or the other about COMPAT_43 and FreeBSD. Usually when testing a kernel compile, GENERIC is the kernel to test. If your changes are intrusive enough, you might also want to make sure that LINT builds ok. The LINT config file is generated from NOTES by typing 'make LINT' in /sys/i386/conf/. I was going for a small kernel config, hoping that it'd be quick to build, not take up lots of space, etc, so only put in what I thought was necessary. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw drop packets based on SYN TTL
Hi, I need to drop packets using ipfw based on the value of TTL and the value of TTL on a 2.2.8-stable system. It seems ipfw does not support this, what options do I have? If you use IP Filter, this should "just work". You won't have to upgrade your system to FreeBSD 4.x/5.x either. I still use FreeBSD 2.2.X with current versions of IP Filter with no trouble. The syntax would be: block in ttl 1 proto tcp all flags S/S to block all TCP packets with the SYN bit set and a TTL of 1. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Breaking kernel compiles.
In an attempt to do the right thing, I checked out sys and config'd a kernel and went to compile (on builder, as it were)... cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing -prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -no stdinc -I- -I. -I../.. -I/usr/include -D_KERNEL -include opt_global.h -elf -mp referred-stack-boundary=2 ../../kern/kern_sig.c ../../kern/kern_sig.c:359: warning: function declaration isn't a prototype ../../kern/kern_sig.c: In function `osigaction': ../../kern/kern_sig.c:367: dereferencing pointer to incomplete type ../../kern/kern_sig.c:367: dereferencing pointer to incomplete type ../../kern/kern_sig.c:369: dereferencing pointer to incomplete type ../../kern/kern_sig.c:370: dereferencing pointer to incomplete type ../../kern/kern_sig.c:372: dereferencing pointer to incomplete type ../../kern/kern_sig.c:379: dereferencing pointer to incomplete type ../../kern/kern_sig.c:384: dereferencing pointer to incomplete type ../../kern/kern_sig.c: At top level: ../../kern/kern_sig.c:532: warning: function declaration isn't a prototype ../../kern/kern_sig.c: In function `osigprocmask': ../../kern/kern_sig.c:538: dereferencing pointer to incomplete type ../../kern/kern_sig.c:539: dereferencing pointer to incomplete type ../../kern/kern_sig.c: At top level: ../../kern/kern_sig.c:567: warning: function declaration isn't a prototype ../../kern/kern_sig.c:721: warning: function declaration isn't a prototype ../../kern/kern_sig.c: In function `osigsuspend': ../../kern/kern_sig.c:729: dereferencing pointer to incomplete type Did I do something wrong or are kernel compiles breaking not really that irregular ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
options INET6 vs opt_inet.h
So, it would appear that in /sys/conf/options, we have the following: INETopt_inet.h INET6 opt_inet6.h Which might seem all nice and dandy - except that config will not generate "opt_inet6.h" with "#undef INET6" if "option INET6" is not present and so you cannot inlcude "opt_inet6.h" to determine if INET6 is defined. There are two possible fixes here - which are not necessarily mutually exclusive of each other: 1. make config generate opt_inet6.h anyway 2. put INET6 in opt_inet.h I believe that (2) is quite reasonable but (1) should happen anyway. Comments ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
protosw or ipprotosw - code mess in netinet
Looking through /sys/netinet, it would appear that sometimes inetsw[]
is "struct protosw" and others "struct ipprotosw". Which is it meant
to be ? If ipprotosw is the same as protosw, why does ipprotosw exist ?
e.g.
in_proto.c:struct ipprotosw inetsw[] = {
in_proto.c: (struct protosw *)inetsw,
in_proto.c: (struct protosw *)inetsw[sizeof(inetsw)/sizeof(inetsw[0])], 0,
ip_mroute.c:extern struct protosw inetsw[];
ip_output.c:extern struct protosw inetsw[];
Darren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD-4.0 PCMCIA broken ?
In some mail from Warner Losh, sie said:
In message [EMAIL PROTECTED] Darren Reed writes:
: Does FreeBSD-4.0 support IRQ sharing ? Or rather, does pccardd support
: configuring devices in such a manner ?
No. I've never had good luck getting it to work at all.
: pcic0: Intel i82365 at port 0x3e0 iomem 0xd irq 10 on isa0
: pcic0: management irq 11
That's the problem. I think I've committed a fix that pays more
attention to the environment variables that set this. When you try to
use the same IRQ (in this case 10) between the bridge manager and the
actual cards, bad things can happen.
Which file(s) do I need to update here ?
: I've also got a 3Com 3CCM156B (modem) which pccardd shows as ""("")
Is this a cardbus card?
Yes.
: when I insert it, never mind that it fails to notice any pcmcia
: events after popping it out and then puttint it back in.
:
: It would also appear that pccardd fails to notice the 3c589D at boot
: time if the 3CCM156B is inserted.
Odd.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD-4.0 PCMCIA broken ?
In some mail from Warner Losh, sie said:
In message [EMAIL PROTECTED] Darren Reed writes:
: In some mail from Warner Losh, sie said:
:
: In message [EMAIL PROTECTED] Darren Reed writes:
: : Does FreeBSD-4.0 support IRQ sharing ? Or rather, does pccardd support
: : configuring devices in such a manner ?
:
: No. I've never had good luck getting it to work at all.
:
: : pcic0: Intel i82365 at port 0x3e0 iomem 0xd irq 10 on isa0
: : pcic0: management irq 11
:
: That's the problem. I think I've committed a fix that pays more
: attention to the environment variables that set this. When you try to
: use the same IRQ (in this case 10) between the bridge manager and the
: actual cards, bad things can happen.
:
: Which file(s) do I need to update here ?
You set the irq for the management IRQ in the kernel config file. You
should set it to 11. It defaults to 10. You'll also want to delete
the machdep.pccard.pcic_irq line from your /boot/loader.conf for now.
Also, you may want to try this in polling mode, in which case you'll
want to remove the irq XX clause from the config file. That will free
up one more IRQ if you need it.
The "machdep.." line wasn't there, but was commented out in
/boot/defaults/loader.conf (so I left that was it was).
Hmmm, I changed the "pcic" irq to 11, but still get:
pcic-pci0: ... irq 10 ...
pcic-pci1: ... irq 10 ...
pcic0: management irq 11
No go. I also commented out the USB device lines (uhci0 was also at irq 10)
in the kernel config file and what do I get ?
pccardd[45]: No card in database for "3COM"("3CCM156 B")
ep0: 3Com Etherlink III 3C589 at port 0x240-0x24f irq 10 slot 1 on pccard1
ep0: Ethernet address 00:10:4b:ed:e6:eb
ep0: supplying EUI64 00:10:4b:ff:fe:ed:e6:eb
hang
ctrl-alt-esc shows more lines than fit on the screen, but the path is:
(off the screen bits)
pccard_beep_select
BUS_SETUP_INTR
bus_generic_setup_intr
BUS_SETUP_INTR
bus_setup_intr
ep_isa_match_id
DEVICE_ATTACH
device_probe_and_attach
pccard_alloc_slot
pccard_event
spec_vnoperate
...
If that is freezing because there is no speaker device (I copied my
config from GENERIC which has no sound driver configured), then config
should not allow this sort of configuration bogon. I'm trying to
configure some sound devices with varying levels of success.
Darren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD-4.0 PCMCIA broken ?
Does FreeBSD-4.0 support IRQ sharing ? Or rather, does pccardd support
configuring devices in such a manner ?
I suspect that part of my problem with getting my 3c589D to work under
4.0 is related to this. (It has so far refused to work). For example,
under NetBSD:
...
pciide0: primary channel interrupting at irq 14
pciide0: secondary channel interrupting at irq 15
uhci0: interrupting at irq 10
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
pckbc0: using irq 1 for kbd slot
pckbc0: using irq 12 for aux slot
sb0 at isa0 port 0x220-0x237 irq 5 drq 1: dsp v3.01
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
cbb0: interrupting at irq 10
cbb1: interrupting at irq 10
...
- three different devices use irq 10 (this includes ep0, which is
at pcmcia1/cardslot1/cbb1). If I try to put it at IRQ 10 with
"device ep0 at isa? ... irq 10", it fails. If I try to make it
go to another IRQ, it fails.
If I look at dmesg from FreeBSD (sorry, cut-n-paste doesn't work
across an air gap) I see:
ata0: irq 14
ata1: irq 15
uhci0: irq 10 on pci0
pcic-pci0: irq 10 at device 10.0 on pci0
pcic-pci1: irq 10 at device 10.1 on pci0
fdc0: irq 6
atkbd0: irq 1
psm0: rq 12
pcic0: Intel i82365 at port 0x3e0 iomem 0xd irq 10 on isa0
pcic0: management irq 11
sio0 .. irq 4 ...
sio1 .. irq 3 ...
I've also got a 3Com 3CCM156B (modem) which pccardd shows as ""("")
when I insert it, never mind that it fails to notice any pcmcia
events after popping it out and then puttint it back in.
It would also appear that pccardd fails to notice the 3c589D at boot
time if the 3CCM156B is inserted.
Darren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
post 4.0...adoption of pfil(9) from NetBSD ?
I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6, to see what's required for IP-Filter (hoping for a clean interface) and the response is "sigh". The old ipfw mechanism needs to be abandoned, IMHO. For those that aren't aware, pfil(9) in NetBSD used to provide two lists for filtering IP packets going in.out. It now provides input and output filtering for both IPv4 and IPv6 with the list heads and other meta data stored in protosw, making it possible to further expand to develop UDP/TCP, etc, specific filters at some later time. The only hurdle I can see for FreeBSD is a missing "forward" list, but that's only a minor issue. The advantage to using pfil(9) from NetBSD (unless someone feels the distinct need to roll their own code to do something the same) is it provides a clean interface rather than requiring people to patch things like ip6_input.c, etc. Bringing pfil(9) into FreeBSD is most definately a post FreeBSD-4.0 exercise. Comments ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: post 4.0...adoption of pfil(9) from NetBSD ?
In some mail from Luigi Rizzo, sie said: I was just having a quick peek at how ipfw works in FreeBSD-4 for IPv6, to see what's required for IP-Filter (hoping for a clean interface) and the response is "sigh". The old ipfw mechanism needs to be abandoned, IMHO. can you comment a bit more ? I am a bit unclear on what exactly is thay you don't find appropriate in ipfw etc. The problem is that the in kernel support for ipfw/ipfilter is *specific* to each. There is no mechanism for 3rd party people to add their own without making the same ugly hacks as already exists unless they choose to use the ipfw/ipfilter hook instead. i.e. each time we want to filter a new protocol we need to hack the various functions for a filter specific hook rather than using a generic filter/calling mechanism. If you have an URL for a pfil(9) manpage i would appreciate it. See below for man page from 1.4. Some comments: The issue of one vs. multiple lists (per direction, interface, protocol, you name it) has been discussed some time ago. For sure multiple lists are a (minor, given that we can start the ipfw lists with a few of "skipto") performance improvement over a single one, at the possible price of having some duplication in writing filters and even defining how many lists are appropriate. To me, this outlines how bad the current system for ipfw support has become. Need something ? Just hack the appropriate part of the kernel. There's no real design in the infrastructure for ipfw. Sort of what Linux was like before they redesigned their firewalling, etc, interfaces using netfilter. I must point out that whilst pfil(9) as found in NetBSD does not provide enough support for the various FreeBSDisms to be put in as it is, I think it can be expanded upon, whilst still supporting the same interface, to meet FreeBSD's needs. Darren PFIL(9) NetBSD Kernel Manual PFIL(9) NAME pfil, pfil_hook_get, pfil_add_hook, pfil_remove_hook - packet filter in- terface SYNOPSIS #include sys/param.h #include sys/mbuf.h #include net/if.h #include net/pfil.h struct packet_filter_hook * pfil_hook_get(int); void pfil_add_hook(int (*func)(), int flags); void pfil_remove_hook(int (*func)(), int flags); DESCRIPTION The pfil interface allows a function to be called on every incoming or outgoing packets. The hooks for these are embedded in the ip_input() and ip_output() routines. The pfil_hook_get() function returns the first member of a particular hook, either the in or out list. The pfil_add_hook() function takes a function of the form below as it's first argument, and the flags for which lists to add the function to. The pos- sible values for these flags are some combination of PFIL_IN and PFIL_OUT. The pfil_remove_hook() removes a hook from the specified lists. The func argument is a function with the following prototype. func(void *data, int hlen, struct ifnet *net, int dir, struct mbuf **m) The data describes the packet. Currently, this may only be a pointer to a ip structure. The net and m arguments describe the network interface and the mbuf holding data for this packet. The dir is the direction; 0 for incoming packets and 1 for outgoing packets. if the function returns non-zero, this signals an error and no further processing of this packet is performed. The function should set errno to indicate the nature of the error. It is the hook's responsibiliy to free the chain if the pack- et is being dropped. The pfil interface is enabled in the kernel via the PFIL_HOOKS option. RETURN VALUES If successful pfil_hook_get() returns the first member of the packet fil- ter list, pfil_add_hook() and pfil_remove_hook() are expected to always succeed. HISTORY The pfil interface first appeared in NetBSD 1.3. The pfil input and out- put lists were originally implemented as sys/queue.h LIST structures; however this was changed in NetBSD 1.4 to TAILQ struc- tures. This change was to allow the input and output filters to be pro- cessed in reverse order, to allow the same path to be taken, in or out of the kernel. BUGS The current pfil implementation will need changes to suit a threaded ker- nel model. SEE ALSO bpf(4) NetBSD 1.4 August 4, 1996 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: post 4.0...adoption of pfil(9) from NetBSD ?
In some mail from Luigi Rizzo, sie said: The issue of one vs. multiple lists (per direction, interface, protocol, you name it) has been discussed some time ago. For sure multiple lists are a (minor, given that we can start the ipfw lists with a few of "skipto") performance improvement over a single one, at the possible price of having some duplication in writing filters and even defining how many lists are appropriate. To me, this outlines how bad the current system for ipfw support has become. Need something ? Just hack the appropriate part of the kernel. There's no real design in the infrastructure for hmmm... this criticism, which i partly share, seems unrelated to the single vs. multiple list issue. I agree with you that having a protocol-independent interface for the firewall would be nicer, but then you should also remember that things like divert, forward, tee and possibly also NAT can only be defined as hacks, and as such i am not very optimistic that one can find common mechanisms for calling the filter unless one tolerates some duplication of work. NAT can easily be implemented as a `filter'. I suspect all of the others you mention (divert/forward/tee) also can be. IP Filter has, for years, supported a "tee-like" feature where it will send a duplicate of a packet out another interface. It may even do "forward" but not "divert"...I don't follow ipfw features very closely O:-) Example: when the filter forwards a packet to somewhere else, you might have to change the route info associated with the packet. When the filter duplicates or steals a packet, the things to do depend a lot on what the rest of the standard function does. Changing routing information is not a problem. For starters, with inbound packets, there is none. E.g ip_input.c, the handling of diverted packets is scattered all around. I don;t know how easy would it be to pack all of this in one place, before or after the proto_input routine. "divert" is just a mess :-) [...] My second comment is on the usefulness of a unified filter. ipfw is clearly IPv4 centric, ip6fw is IP6 centric, and maybe there is no ipxfilter. Just because ipfw/ip6fw are only associated with a single protocol does not mean they can't use a generic interface in place of one specific to them. I think it is short sighted to assume that whatever is there now will be there in X years time or that nobody will want to use their own whatever. By building a generic framework (not that of a unified filer), you support multiple filters out of the box and each can work without any special changes to the kernel. Why ? because the authors of the 2/3 different filters know enough about their protocol but not enough about the others. Now we can work on each one separately, and at a much higher rate than we could achieve by having a single monolitic filter which people would be scared to touch fearing to break support of some of the other protocols (or, more likely, people would end up adding features to just one of the protos leaving the other ones unchanged). So, in my opinion a merging effort would be a threat to improvement (and the same applies to having to maintain portable software... i guess you know the problem very well with ipfilter!) I'm not saying merge anything. But in the case of ipfilter, easier to merge ipv6 in than create a whole new 'ipfilter6'. Of course there are some common functionalities such as (to speak of a couple with which i am very familiar) traffic shaping, or keeping state. But the common infrastructure (a scheduler in the former case) is very very easy to share, while i see much more difficulty in maintaining a single unified filter for all protocols. That depends on how you view and design it, doesn't it ? In so far as IP is concerned, the only significant difference is address size. If you look at how linux's iptables works, there are separate modules for each of ip, tcp, udp, icmp, etc. A packet is filtered by calling the appropriate filter routine for that protocol. In comparison to ipfw which does all its port checking, etc, in `one place'. The idea with pfil(9) as it is in NetBSD now is to allow a filter module to register if it wants to filter inbound (or outbound or both) packets for a given protocol. e.g. I could write a small anti DDoS thing and filter inbound IPv4 packets only and not need to make any changes to the standard kernel source. Using this approach, ipfw would register for in/fwd/out ipv4 packets and ip6fw would register for in/fwd/out ipv6 packets. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: post 4.0...adoption of pfil(9) from NetBSD ?
In some mail from Luigi Rizzo, sie said: Changing routing information is not a problem. For starters, with inbound packets, there is none. for outbound there is, and one of the biggest problems i had with dummynet (as an example) was that some code passed around route structures held in the stack, so you couldn't just keep a reference and reuse it later. Bad engineering you can say, and i agree, but fixing this requires fixing the source, not just defining a filter interface. mmm, fixing the source. If you look at how linux's iptables works, there are separate modules for each of ip, tcp, udp, icmp, etc. A packet is filtered by calling the appropriate filter routine for that protocol. In comparison to ipfw which does all its port checking, etc, in `one place'. but layer boundaries are just on paper, in reality especially a firewall looks all over the headers (and maybe in even more places). When you filter TCP, you still look at the IP addresses. In ipfw, you can even look at the UID of the associated PCB. So ? By registering filters per protocol at different layers, you have a problem: suppose your rules are the following (in ipfw style, first match wins): 1: deny ip from A to any 2: allow tcp from any 23 to any when you get a TCP packet, when do you invoke the filter, in tcp_input() or in ip_input() ? You should probably do the call at the highest possible level in the stack (TCP in this case), but then you should duplicate rule 1 in the TCP chain or you are in trouble. Urgh, I see you're not familiar with theirs either. The filtering is invoked from IP (just like ipfw) but rather than do "if tcp then check ports and flags", it does "call per-protocol check". Maybe I'm just not explaining this clearly... Furthermore you need hooks in all protocol at all levels, and you depend on upper-level protocols to be implemented properly or filtering fails -- e.g. if the protocol PGM (to name another one i am working on) forgets to call the filter, then all PGM packet will skip the IP check. Huh ? I think you're not understanding what I'm saying. What we have now in ipfw is a bit more messy (as you do a lot of work trying to classify packets) but at least understanding the ruleset is rather easy, and the places in the kernel where the match is done are more limited. I wouldn't call it "limited" :) There are more ipfw hooks required than ipfilter hooks for basically the same job :-) You would do well to download a linux kernel and see what they do, as well as looking at how NetBSD now handles it. My descriptions have been heavily modified to be concise and are not doing either OS justice. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3c589d w/ freebsd 3.3 works badly.
In some mail from Matthew N. Dodd, sie said: On Mon, 6 Dec 1999, Darren Reed wrote: How reliable should the ep0 driver be with 3c389d pcmcia cards ? It gets detected by pccardd without any problems and a driver is attached to it, but I'm not getting much in the way of performance from it with "link2" selected for UTP (doesn't work with "media 10baset/utp"). It's being used in conjunction with cardbus on a gateway solo 9100. I suspect that it isn't getting interrupted properly, although nothing is telling me what IRQ is being given to it. I'm still trying to track down a watchdog timeout problem with if_ep. FWIW, I get 800kb/s transfer rates with NetBSD-current Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3c589d w/ freebsd 3.3 works badly.
In some mail from Warner Losh, sie said: In message [EMAIL PROTECTED] Darren Reed writes: : How reliable should the ep0 driver be with 3c389d pcmcia cards ? I had no problems using 3.3 and my 3C589D, but I've only done minor stuff with that. I've done most of my work on -current, however. The most likely problem is that you're using the wrong IRQ for the card. You'll want to check /etc/rc.conf to make sure that you are using the /etc/pccard.conf file. Also, you'll want to make sure that the irq line is correct. Did all of that. When ejecting the card it says "freeing IRQ 10" (or words to that effect), which is the IRQ I used with it under Windows and NetBSD. How much can I specify on the "config" lines in pccard.conf ? Can I `wire down' irq's, iomem and iobuf in the "?" part of the line ? Darren p.s. is the not printing of the IRQ being allocated at bootup a bug ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
3c589d w/ freebsd 3.3 works badly.
How reliable should the ep0 driver be with 3c389d pcmcia cards ? It gets detected by pccardd without any problems and a driver is attached to it, but I'm not getting much in the way of performance from it with "link2" selected for UTP (doesn't work with "media 10baset/utp"). It's being used in conjunction with cardbus on a gateway solo 9100. I suspect that it isn't getting interrupted properly, although nothing is telling me what IRQ is being given to it. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ejecting card with 3.3 causes hang ?
ejecting a modem pcmcia card caused 3.3 to do the following: /kernel: sio2 unload,gone /kernel: Return IRQ=11 /kernel: Card removed, slot 1 /kernel: Card inserted, slot 0 and then it was frozen. Will there be a 3.4 with things like this fixed ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ahc (2940UW) driver in 3.3
Some time ago I reported corruption using 2.2.8 with an DDRS-39130 connected to a 2940UW. I've done some testing today with 3.3, on a totally different box, with a brand new scsi cable (never before used). Still I see corruption. It's not in the same place every time. My test involves dd'ing /dev/zero to create a 300MB file and then outputting that file in hex, looking for non-zero bytes. What surprised me was it even passed a couple of times. Before I go blaming the drive, can anyone categorically confirm that parity is enabled and enforced in the FreeBSD driver for the 7880 ? For example, has anyone actually seen evidence that it handles parity errors ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations
In some mail from Stas Kisel, sie said: From: Darren Reed [EMAIL PROTECTED] The problem with this is the BSD TCP/IP implementation ACK's (or at least attempts to ACK) data as soon as it is received and it is a big no-no to discard queued data that has already been ACK'd. Probably it is not self-evident why we HAVE to drop this connection. It is evil connection. Good applications do read data from their sockets, and evil ones do not. And ever if it is good, but silly or busy application, good clients do not send so much data that application can not process it. Am I wrong, there are any examples? So what if someone manages to crash a program due to a DOS attack ? An easy one that comes to mind is syslogd. It's often stuck in disk-wait and can easily be targetted with a large number of packets. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations
In some mail from Karl Pielorz, sie said: Darren Reed wrote: It is evil connection. Good applications do read data from their sockets, and evil ones do not. And ever if it is good, but silly or busy application, good clients do not send so much data that application can not process it. Am I wrong, there are any examples? So what if someone manages to crash a program due to a DOS attack ? An easy one that comes to mind is syslogd. It's often stuck in disk-wait and can easily be targetted with a large number of packets. Isn't syslog UDP? - i.e. no ACK? - you could argue (to a point) that this might even be by design? :) (with regard to if syslog is in diskwait, and over burdened with traffic, data gets dropped). This, could be construed as a DoS (in fact it probably is)... sorry, syslogd doesn't suffer from the same problems that klogd on lamix does (i.e its all datagrams). my mistake. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations
In some mail from Stas Kisel, sie said: From: Darren Reed ava...@coombs.anu.edu.au The problem with this is the BSD TCP/IP implementation ACK's (or at least attempts to ACK) data as soon as it is received and it is a big no-no to discard queued data that has already been ACK'd. Probably it is not self-evident why we HAVE to drop this connection. It is evil connection. Good applications do read data from their sockets, and evil ones do not. And ever if it is good, but silly or busy application, good clients do not send so much data that application can not process it. Am I wrong, there are any examples? So what if someone manages to crash a program due to a DOS attack ? An easy one that comes to mind is syslogd. It's often stuck in disk-wait and can easily be targetted with a large number of packets. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf shortage situations
In some mail from Karl Pielorz, sie said: Darren Reed wrote: It is evil connection. Good applications do read data from their sockets, and evil ones do not. And ever if it is good, but silly or busy application, good clients do not send so much data that application can not process it. Am I wrong, there are any examples? So what if someone manages to crash a program due to a DOS attack ? An easy one that comes to mind is syslogd. It's often stuck in disk-wait and can easily be targetted with a large number of packets. Isn't syslog UDP? - i.e. no ACK? - you could argue (to a point) that this might even be by design? :) (with regard to if syslog is in diskwait, and over burdened with traffic, data gets dropped). This, could be construed as a DoS (in fact it probably is)... sorry, syslogd doesn't suffer from the same problems that klogd on lamix does (i.e its all datagrams). my mistake. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
2.2.8 - can't mount root
Is there a way to get FreeBSD 2.2.8 to ask you for the root device rather than have it attempt to mount and fail ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
2.2.8 - can't mount root
Is there a way to get FreeBSD 2.2.8 to ask you for the root device rather than have it attempt to mount and fail ? Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 2.2.8 - can't mount root
In some mail from Doug, sie said: Darren Reed wrote: Is there a way to get FreeBSD 2.2.8 to ask you for the root device rather than have it attempt to mount and fail ? The 3.x branch is a lot smarter about this, but I agree that it would be nice in those situations where it still can't find it to stop and ask rather than just panic(). Does FreeBSD yet have a kernel boot -a option where it asks things like where is the root partition, what filesystem type is it, etc ? Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Introduction
In some email I received from Nicolai Petri, sie wrote: On Fri, 18 Jun 1999, Brian Fundakowski Feldman wrote: On Fri, 18 Jun 1999, Ruslan Ermilov wrote: Let's join our efforts in this area! IPFW code is very ugly... Which is basically due to it being hacked on for years without a cleanup. Now's the time (between major versions) to do this, I think. How's this: let's organize a small group to bounce ideas off eachother, first of all (I'm forwarding this to hackers to perhaps elicit a response of more people.) We should get ideas on what people think is wrong with the current implementation, what new features should be added, and where we should rearchitect. What about support for protocol verification ?? (Example : Blocking of malformed ftp commands.) Surely you jest... Wich layer would it be logically to implement this in ? 5 and above. Is a userland proxy the only way ? With a 100% reliability, yes. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: firewalling (Was Re: Introduction)
In some email I received from Brian Fundakowski Feldman, sie wrote: How do you feel about (after getting it fixed in -CURRENT) helping with converting ipfw(8) to just a front-end to ipf? I think it's worth discussing whether it's actually worth it to rewrite IPFW or just work on improving ipfilter. (discussion moved to -hackers) I imagine they might be fighting words to some ;) As I see it, if you added hooks for divert to ipfilter in FreeBSD and maybe added the rule number bits (I *know* there are going to be people who'd just die without it) then I can't see why you'd need ipfw. I imagine that would be a hell of a lot less work than bringing the features of ipfilter into ipfw. It'd also be one of those steps forward in compatibility between the various BSDs... Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: more on the pcmcia saga.
In some mail from Wes Peters, sie said: [...] PC-Card Intel 82365 (5 mem 2 I/O windows) pcic: controller irq 3 ^^ Initializing PC-card drivers: sio Why does it list sio here ? I don't see where sio is actually used with PCMCIA here...why doesn't it list ed0 too ? (Is this a bug ?) changing root device to wd0s2a Card inserted, slot 1 PC-Card Intel 82365 (5 mem 2 I/O windows) pcic: controller irq 5 ^^ Card inserted, slot 3 ed0: address 00:80:c8:8c:01:58, type NE2000 (16 bit) Does this imply that IRQ's 3 5 are for use by the respective slots ? Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: more on the pcmcia saga.
[...] PC-Card Intel 82365 (5 mem 2 I/O windows) pcic: controller irq 3 ^^ Initializing PC-card drivers: sio changing root device to wd0s2a Card inserted, slot 1 PC-Card Intel 82365 (5 mem 2 I/O windows) pcic: controller irq 5 ^^ Card inserted, slot 3 ed0: address 00:80:c8:8c:01:58, type NE2000 (16 bit) Well, when I see two pcic: .. irq X lines, pccardd comes back with this error: pccard[]: driver allocation failed for 3Com Corporation I also (now) get: PC-Card Cirrus Logic PD672X (...) pcic: controller irq 5 Initializing PC-card drivers: ep DEVFS: ready to run Card inserted, slot 3 (is this good or bad ?). I have a sio and ep lines empty in the kernel config: device sio2 device ep0 This time, however, I got: PC-Card Cirrus Logic PD672X (...) pcic: controller irq 9 Card inserted, slot 3 now where it got slot 3 from, I have no fucking idea. What's more, there is only *1* card inserted! Does _anyone_ know how to make this PCMCIA crap work or is it just like the lottery ? Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
adding pcmcia cards
Having finally got pccardd to configure the card, it doesn't seem to get the correct IRQ, nor does it deal well with the card being ejected whilst in use (freezes the box). Neither is pccardd started by default, which seems strange if you have a /etc/pccardd.conf file. Anyway, I've also got a 3CCM156B card here, the config entry in pccard.conf is as follows: io 0x400-0x4ff irq 9 13 memory 0xd4000 96k card 3COM 3CCM156 B config 0x21 sio2 ? insert echo 3Com PCMCIA 56K Modem inserted remove echo 3Com PCMCIA 56K Modem removed but whenever I load it in, I get: pccard[]: resource allocation failure for 3COM I've defined sio0 sio1 in the kernel config (both get probed and used, one is serial, the other is FIR) as well as this option: options EXTRA_SIO=2 I've checked that an IRQ is free by inserting and removing ep0 which informs me that IRQ9 gets returned but to no avail. What next ? Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
how to configure sound on laptop ?
well, I've nutted out how rc.conf is meant to work and try to avoid freezing 3.1 by popping out the 3c589d at the wrong time but when it gets configured, the performance sucks (UTP so -link0, -link1). It feels like a misconfiguration as I can see packets coming out of it but none are being received. If I leave a ping running long enough, I might see some packets get returned, with a time of anywhere between 1 and 12 seconds. FWIW, it gets allocated IRQ9, but under Win98, it gets IRQ5... The next `problem' is that I lose an IRQ like this: PC-Card Cirrus Logic PD672X (5 mem 2 I/O windows_ pcic: controller irq 5 Under Win98, the two CardBus controller chips each share IRQ 10 (they're described as Cirrus Logic PD6832's or pci1013,1110) and that chip doesn't get its own IRQ. And finally, I'm attempting to configure the sound chips. Win98 reports them as: OPL3-SAx WDM DMA 0,1 IRQ 11 IO 220-22f, 530-537, 388-38f, 310-31f, 370-371 Anyone want to have a stab at what the correct way to configure FreeBSD for that mess is ? :-) I currently have: controller snd0 device mss0 at isa? port 0x530 irq 11 drq 1 device opl0 at isa? port 0x388 device mpu0 at isa? port 0x310 irq 6 drq 0 However, upon booting, this gives the following: mss0 at 0x530 irq 11 drq 1 on isa [IRQ Conflit?]snd0: MS Sound System0 (CS4231) opl0 at 0x388 on isa snd0: Yamaha OPL3 FM mpu0 at 0x310 irq 6 drq 0 on isa mpu0 not attached due to irq conflict with fdc0 at 6 Where to from there ? Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
more on the pcmcia saga.
It appears that having pccardd enabled in /etc/defaults/rc.conf causes it to be started very early with the end result of the pcic controller also allocating irq9 (in a separate pair of messages). i.e. this appears early on: PC-Card Cirrus Logic PD672X (5 mem 2 I/O windows) pcic: controller irq 5 just before Initializing PC-card drivers: fdc - fdc ?! - and then later, whilst fsck'ing or whatever, I saw this: PC-Card Cirrus Logic PD672X (5 mem 2 I/O windows) pcic: controller irq 9 What's going on here ? Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 3c589d and FreeBSD 3.1
In some mail from Warner Losh, sie said: In message 199905250224.maa11...@cheops.anu.edu.au Darren Reed writes: : pccardd[198]: fatal error: no PC-CARD slots What does dmesg say? Is pcic0 detected? If so, how many slots did it say it had? Do you have controller card and device pcic in your config file (see LINT for details)? So far, I've just used GENERIC and I've since installed NetBSD 1.4 over FreeBSD which detected it as: pcic0 at isa0 port 0x3e0-0x3e1 iomem 0xd-0xd3fff irq 9 pcico: controller 0 (Cirrus PD672X) has sockets A and B They're attached to a cardbus-pci bridge pair of chips that are defined as vendor=1013, device=1110, rev 0xc1 Does the GENERC (or whatever kernel gets installed for 3.1 by default) have pcic devices in it ? Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 3c589d and FreeBSD 3.1
In some mail from Warner Losh, sie said: In message 199905250629.qaa14...@cheops.anu.edu.au Darren Reed writes: : Does the GENERC (or whatever kernel gets installed for 3.1 by default) : have pcic devices in it ? No. It doesn't. :-( I tried to build a kernel with it in, although I don't know if I got the config correct, but I got a panic when it booted, toward the end of the configuration process: panic: biodone: zero vnode ref count it did, however, correctly identify the PCMCIA chips and the card. Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
the invisible 3c589d 3.1
Further to this, I did manage to get a kernel compiled and running (dependency checking when compiling without DIAGNOSTIC defined and using LINT as a starting point is not good - lots 'of DEBUG things get left without any warning!). Output: ... pcic0: Cirrus Logic PD6832 CardBus Adapter rev 0xc1 int a irq 10 on pci0.10.0 pcic0: Cirrus Logic PD6832 CardBus Adapter rev 0xc1 int a irq 10 on pci0.10.1 Probing for PnP devices: Probing for devices on the ISA bus: ... PC-Card Cirrus Logic PD672X (5 mem 2 I/O windows) pcic: controller irq 3 Initializing PC-card drivers: ed DEVFS: ready to run Card inserted, slot 0 Card inserted, slot 1 Well, I don't believe that the pcic controller is at irq 3 (or is it ?!). When I start up pccardd, I get these messages: No card in database for 3COM(3CCM156 B)) No card in database for () The first is, I presume, the modem card (this gets reported as com3 on NetBSD), the second, I guess is my 3c589d! What now ?! Who ever heard of invisible PCMCIA cards ?! Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Darren Reed memorial ?
In some mail from Mike Smith, sie said: I tried to build a kernel with it in, although I don't know if I got the config correct, but I got a panic when it booted, toward the end of the configuration process: panic: biodone: zero vnode ref count Darren, I don't know what you've done to your machine, but you get the weirdest and most unhappy-sounding problems I've ever seen. I think we need a Darren Reed memorial something to commemorate this, as well as your perseverence for not simply giving up and going home. Put this one down to changing a config file and make depend not being as complete as rm -rf. Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
3c589d and FreeBSD 3.1
Back when I was running 2.2.8 (and on a different laptop), I used zp0 with the 3c589D although it sucked with people recommending using ed0. Does that recommendation hold true for 3.1 ? FWIW, I've tried to boot a kernel with both ed0 zp0 edit'd with boot -c but neither seem to be able to probe the card at the same `address' that Windows98 sees it at (IO 0x1020, IRQ 11). Any hints/tips on how to make it work ? Darren p.s. whoever broke boot -c options saving should be shot! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 3c589d and FreeBSD 3.1
In some mail from Wes Peters, sie said: Darren Reed wrote: Back when I was running 2.2.8 (and on a different laptop), I used zp0 with the 3c589D although it sucked with people recommending using ed0. Does that recommendation hold true for 3.1 ? FWIW, I've tried to boot a kernel with both ed0 zp0 edit'd with boot -c but neither seem to be able to probe the card at the same `address' that Windows98 sees it at (IO 0x1020, IRQ 11). Any hints/tips on how to make it work ? Have you tried using pccardd? It works just fine for me. I compiled the ISC DHCP client seperately, since the port was marked broken in 3.1, but I see it's been fixed in 3.2. I had to add the following section to /etc/pccard.conf for my PCMCIA ethernet card: # Wes's D-Link card (works with BeOS) card D-Link DE-660 config 0x20 ed0 11 insert echo D-Link ethernet card inserted insert /etc/pccard_ether ed0 remove echo D-Link ethernet card removed remove /sbin/ifconfig ed0 delete There is a configuration for the 589D already in /etc/pccard.conf.sample, so you should have an easy time of it. Heh. See below. [...] Email me if you need any help. pccardd[198]: fatal error: no PC-CARD slots sigh Darren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
