Re: 3CXFE575CT-JP with NEWCARD doesn't work
Hi, I build kernel with NEWCARD from source cvsup'ed today. Following patch is still needed for my machine card. Without this, the card appear as /boot/kernel/kernel: xl0: Ethernet address: 00:00:00:00:00:00 and the card does not work. Best regards, -- Yoichi NAKAYAMA At Wed, 5 Sep 2001 11:47:30 -0400, Jonathan Chen wrote: On Mon, Sep 03, 2001 at 08:26:16PM +0900, Yoichi NAKAYAMA wrote: I just cvsup'ed and buildkernel with NEWCARD. Then my note book doesn't recognize MAC address of the card(3CXFE575CT-JP) following are concerning log for new kernel and old kernel(cvsup'ed 2-3 weeks ago) This looks like it could have been caused by my moving the default io range around. The IO port assigned to your card could be in conflict with something else. Try the following patch, which reverts to the old range. It would be really nice if the pci bus code could just do these assignments automagically... Index: pccbb.c === RCS file: /export/ncvs/src/sys/dev/pccbb/pccbb.c,v retrieving revision 1.24 diff -u -r1.24 pccbb.c --- pccbb.c 2001/08/27 11:23:05 1.24 +++ pccbb.c 2001/09/05 15:44:45 @@ -1243,8 +1243,8 @@ start = end = tmp; break; case SYS_RES_IOPORT: - if (start = 0x1000) - start = 0x1000; + if (start = 0x3000) + start = 0x3000; if (end start) end = start; break; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI/PSM/PCCARD Woes
I have a Dell Latitude C Family Model:PPX laptop. I recently upgraded from 4.4 to 5.0 so I could use the 32-bit Xircom ethernet adapter I had. I cvsup'd rebuilt world and kernel yesterday and these are the problems I am having. 1. If I let the acpi module load I don't have a /dev/psm* entry for the mouse. I believe it complains about an inability to assign an IRQ. 2. I was using a 16-bit Linksys adapter while I was running on 4.4 this adapter no longer works. It seems to recognize it and I can assign an address to it but it was unable to actually route any traffic. This is the message I get /boot/kernel/kernel : arplookup xxx.xxx.xxx.xxx failed: host is not on local network /boot/kernel/kernel : arpresolve : can't allocate llinfo for xxx.xxx.xxx.xxxrt I have no idea on this one. Attatched is my kernel config file, a dmesg with the acpi module loaded and boot -v specifed in the loader, as well as a dmesg without the acpi and boot -v on the loader. If I can provide any more info I'll be happy to. Eric Liedtke Copyright (c) 1992-2001 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 5.0-CURRENT #1: Wed Nov 14 10:58:55 CST 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROADKILL Preloaded elf kernel /boot/kernel/kernel at 0xc0418000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04180b4. Calibrating clock(s) ... TSC clock: 498437744 Hz, i8254 clock: 1193111 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter TSC frequency 498471552 Hz CPU: Pentium III/Pentium III Xeon/Celeron (498.47-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 134152192 (131008K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0043f000 - 0x07fe7fff, 129667072 bytes (31657 pages) avail memory = 126287872 (123328K bytes) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xc0ce pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: lock order reversal 1st 0xc03633e0 allproc @ ../../../kern/kern_fork.c:343 2nd 0xc0326730 pool mutex @ ../../../kern/kern_sx.c:329 lock order reversal 1st 0xc0363360 proctree @ ../../../kern/kern_fork.c:573 2nd 0xc03266d0 pool mutex @ ../../../kern/kern_sx.c:329 lock order reversal 1st 0xc0325a00 fork list @ ../../../kern/kern_fork.c:646 2nd 0xc03271e0 pool mutex @ ../../../kern/kern_sx.c:204 random: entropy source mem: memory I/O Pentium Pro MTRR support enabled null: null device, zero device Math emulator present pci_open(1):mode 1 addr port (0x0cf8) is 0x8008 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) Using $PIR table, 6 entries at 0xc00fbd70 npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL CPi R on motherboard Timecounter ACPI frequency 3579545 Hz can't fetch resources for \\_SB_.MB1_ - AE_AML_OPERAND_TYPE can't fetch resources for \\_SB_.PCI0 - AE_AML_OPERAND_TYPE can't fetch resources for \\_SB_.PCI0.PX40.FDC0 - AE_AML_OPERAND_TYPE can't fetch resources for \\_SB_.PCI0.PX40.UAR1 - AE_AML_OPERAND_TYPE can't fetch resources for \\_SB_.PCI0.PX40.ECP_ - AE_AML_OPERAND_TYPE acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu: CLK_VAL field overflows P_CNT register acpi_cpu: CLK_VAL field overlaps THT_EN bit acpi_tz0: thermal zone on acpi0 acpi_acad0: AC adapter on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_cmbat1: Control method Battery on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 acpi_pcib0: Host-PCI bridge on acpi0 pci0: physical bus=0 map[10]: type 3, range 32, base f400, size 26, enabled found- vendor=0x8086, dev=0x7190, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 found- vendor=0x8086, dev=0x7191, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 found- vendor=0x104c, dev=0xac1c, revid=0x01 bus=0, slot=3, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 found- vendor=0x104c, dev=0xac1c, revid=0x01 bus=0, slot=3, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 found- vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=7, func=0
Re: make installworld failure in usr.bin/tip
Mark, Poul-Henning, So, what was the concensus? Should we fix this in Makefile, or just put this as an UPDATING entry and have users manually remove the old UUCP stuff? On Sat, Nov 03, 2001 at 05:07:01PM +0100, Poul-Henning Kamp wrote: === usr.bin/tip install -c -s -o root -g wheel -m 555 tip /flat/syv/usr/bin /flat/syv/usr/bin/cu - /flat/syv/usr/bin/tip ln: /flat/syv/usr/bin/cu: Operation not permitted *** Error code 1 flat# ls -l /flat/syv/usr/bin/cu -r-sr-sr-x 1 uucp dialer 124384 Oct 21 13:04 /flat/syv/usr/bin/cu flat# /flat/src/usr.bin/tip flat# cvs log Makefile | less [...] total revisions: 10;selected revisions: 10 description: revision 1.7 date: 2001/10/30 21:22:08; author: markm; state: Exp; lines: +1 -1 Make the dirty, rotten hack failsafe and quiet if cu(1) does not exist. I'm sure there is a connection somewhere... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subscribe
subscribe freebsd-current Thanks, Jonathan - Jonathan Donaldson Technical Marketing Engineer Cisco Systems - Enterprise Solutions Engineering 7025 Kit Creek Rd RTP, NC 27709 Office: 919-392-9922 Cell: 919-523-5037 Pager: 800-365-4578 eMail: [EMAIL PROTECTED] ePage: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
test
testing... I think I posted a note yesterday and I still don't see it, so I'm trying again Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
test
testing... Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ibcs
what is the status of ibcs in -current ? I'm subscribed to the list now but only have been for a few days if this is a faq. Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: test
On Friday 16 November 2001 07:09, Brian K. White wrote: testing... Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---] ++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani kindly use [EMAIL PROTECTED] for this sort of thing. -- Gary Jennejohn [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX issue, and general report on SMP issues...
It's not the BIOS failing it... The BTX bootstrap loader V 1.00 detects the keyboard, and refuses to proceed without it. Chris Dempsey wrote: Try changing the BIOS options regarding failing on all errors. After changing my Tyan Thunder K7 to not fail on keyboard failures, it was able to boot fine. Also, if you intend to use a USB keyboard permanently, you may wish to comment out atkbdc from your kernel configuration file. This will make it easier to set up kbdcontrol with the USB keyboard. Let me know if you have further questions. Chris Dempsey jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali, 1995 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX issue, and general report on SMP issues...
On 16-Nov-01 Jim Bryant wrote: It's not the BIOS failing it... The BTX bootstrap loader V 1.00 detects the keyboard, and refuses to proceed without it. Err, no. BTX cares zero, zilch, nada about keyboards. Can you please provide the error message you get? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX issue, and general report on SMP issues...
It's not the BIOS failing it... The BTX bootstrap loader V 1.00 detects the keyboard, and refuses to proceed without it. The BTX loader does not detect or care about the keyboard at all. You have another problem, and you need to supply more details before we can be of any more assistance. In particular, refuses to proceed without it does not give us any useful information at all about the actual symptoms. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
re-entrancy and the IP stack.
For work related erasons I've been in the IP stack
(basically just IP actually) recently. It's obvious
that there are re-entrancy problems there.
Here are two examples..
Routed packets:
a packet that is routed, uses a single static 'route' entry...
(In ip_input.c)
Right next to it is a sockaddr_in that is used by outgoing
icmp packets.
static struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET };
struct route ipforward_rt;
Obviously there cannot be more than one packet being routed
at a time, and no more than one ICMP packet being generated
at a time.
As another example, the ipfw code uses a couple of static
variables too, in the 'fwd' code amongst other places..
What is needed is obviously a 'per packet' storage location
for those things, defined in a per protocol family manner.
Luigi has already tried this scheme by defining a
dummynet specific mbuf type that can be prepended to the
front of packets. What I suggest is to extend this
to defining a MT_PROTOSTORAGE. (or similar) mbuf type
that generic networking code is educated to ignore,
and that protocols can use to pass packet-specific state
information from one place to another.
The netgraph code already has a simialr mechanism, in that
data is always (optionally) accompanied by a metadata
structure, the format of which is predefined in such a way
that allows extensibility and transparency.
What I would like to do is to combine these two methods:
i.e. use the extensible format, embedded in a specially marked
mbuf, prepended onto the packets (or post-pended?).
The format of the data within the mbuf should have the
following characteristics:
1/ It should identify the interface that defines that data,
(so that modules can identify their own metadata/information)
2/ It should define in a standard way, its size.
3/ Metadata from several modules should be capable of being added
to a packet at the same time, either by adding more mbufs or
by adding more self-identifying data to an already existing mbuf.
4/ Registered modules should be called to disarm their metadata
if the packet is deleted.. Metadata should be able to indicate
if it needs to be disarmed or can be just freed.
An example for data needed in IP packets:
[sizeof(struct route)][IP-ID][Forwarding Route ID][struct route]
[sizeof(struct sockaddr_in)][IP_ID][Dest-addr ID][struct sockaddr_in]
[sizeof(struct sockaddr_in)][IP_ID][Fwd-destaddr ID][struct
sockaddr_in]
These would be packed in a MT_PROTOSTORAGE mbuf
and prepended to packets being routeds or forwarded, (or whatever)
so that each packet would carry with it whatever information was needed
to be handled correctly. It could also (for example) be handed
to a 3rd party module (e.g. a firewall) which
could queue the packet (or similar) and not have to
worry about losing 'hidden' state being held elsewhere.
Any comments? (obviously we'd have to educate code to
skip or ignore these packets if they didn't have any use for them.)
But we are going to need to do something like this to make
some of the code re-entrant eventually!
Julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
Julian Elischer wrote: [..] What is needed is obviously a 'per packet' storage location for those things, defined in a per protocol family manner. Luigi has already tried this scheme by defining a dummynet specific mbuf type that can be prepended to the front of packets. What I suggest is to extend this to defining a MT_PROTOSTORAGE. (or similar) mbuf type that generic networking code is educated to ignore, and that protocols can use to pass packet-specific state information from one place to another. Uhh.. no thanks. Whatever you do, do *NOT* abuse the mbuf system for this. We went to a lot of trouble (well, Garrett specifically) to rid the stacks of this obscenity. Do *NOT* generalize it and undo it. MT_DUMMYNET must die, not be propagated elsewhere. If you want to have some general storage mechnaism, do *not* use mbufs for it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: As another example, the ipfw code uses a couple of static variables too, in the 'fwd' code amongst other places.. What is needed is obviously a 'per packet' storage location for those things, defined in a per protocol family manner. Luigi has already tried this scheme by defining a dummynet specific mbuf type that can be prepended to the front of packets. What I suggest is to extend this to defining a MT_PROTOSTORAGE. (or similar) mbuf type that generic networking code is educated to ignore, and that protocols can use to pass packet-specific state information from one place to another. Um, no please. MT_DUMMYNET is a bad hack that should be removed (and which I've partly done in one of my trees). I would rather not perpetuate this, it causes more problems than it is worth. I believe that Garrett went in a while back and removed all the abuses of mbuf (used to store sockaddrs and the like), and this would appear to be a step backward. I don't disagree that there are many static variables that need to be cleaned up, but I don't believe that this is the right approach. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
struct pkthdr already has a field (struct mbuf *aux) which i think is used to store info per-packet state by ipsec, at least according to the comment (my dummynet hack predated this, i would have used this field if it had been available at the time). So this field could be used to access the metadata. Unfortunately i suspect that making a truly extensible format is going to kill performance, because each module would have to hunt its own metadata in the chain. I'd rather go with specific fields in the pkthdr pointing/storing specific info (if you think of it, this is what the pkthdr is. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
On Fri, Nov 16, 2001 at 04:02:51PM -0800, Peter Wemm wrote: it. MT_DUMMYNET must die, not be propagated elsewhere. i agree! cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
* Peter Wemm [EMAIL PROTECTED] [06 18:02] wrote: Julian Elischer wrote: [..] What is needed is obviously a 'per packet' storage location for those things, defined in a per protocol family manner. Luigi has already tried this scheme by defining a dummynet specific mbuf type that can be prepended to the front of packets. What I suggest is to extend this to defining a MT_PROTOSTORAGE. (or similar) mbuf type that generic networking code is educated to ignore, and that protocols can use to pass packet-specific state information from one place to another. Uhh.. no thanks. Whatever you do, do *NOT* abuse the mbuf system for this. We went to a lot of trouble (well, Garrett specifically) to rid the stacks of this obscenity. Do *NOT* generalize it and undo it. MT_DUMMYNET must die, not be propagated elsewhere. If you want to have some general storage mechnaism, do *not* use mbufs for it. *cough* kthread_setspecific() *cough* kthread_getspecific() *cough* or just fix the code to pass this around as an extra paramter. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
On Fri, 16 Nov 2001, Jonathan Lemon wrote: In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: As another example, the ipfw code uses a couple of static variables too, in the 'fwd' code amongst other places.. What is needed is obviously a 'per packet' storage location for those things, defined in a per protocol family manner. Luigi has already tried this scheme by defining a dummynet specific mbuf type that can be prepended to the front of packets. What I suggest is to extend this to defining a MT_PROTOSTORAGE. (or similar) mbuf type that generic networking code is educated to ignore, and that protocols can use to pass packet-specific state information from one place to another. Um, no please. MT_DUMMYNET is a bad hack that should be removed (and which I've partly done in one of my trees). I would rather not perpetuate this, it causes more problems than it is worth. I believe that Garrett went in a while back and removed all the abuses of mbuf (used to store sockaddrs and the like), and this would appear to be a step backward. I don't disagree that there are many static variables that need to be cleaned up, but I don't believe that this is the right approach. sure, but how about some suggestions then? personally Holding static things in mbufs is an abuse, and even things that are dynamic but can be better passed as an argument. Maybe just some extra arguments can cover it.. but that's not very extensible, and you can't queue arguments. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
* Julian Elischer [EMAIL PROTECTED] [06 18:20] wrote: On Fri, 16 Nov 2001, Jonathan Lemon wrote: Um, no please. MT_DUMMYNET is a bad hack that should be removed (and which I've partly done in one of my trees). I would rather not perpetuate this, it causes more problems than it is worth. I believe that Garrett went in a while back and removed all the abuses of mbuf (used to store sockaddrs and the like), and this would appear to be a step backward. I don't disagree that there are many static variables that need to be cleaned up, but I don't believe that this is the right approach. sure, but how about some suggestions then? personally Holding static things in mbufs is an abuse, and even things that are dynamic but can be better passed as an argument. Maybe just some extra arguments can cover it.. but that's not very extensible, and you can't queue arguments. Ah, but you can't queue static variable either. :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
On Fri, 16 Nov 2001, Luigi Rizzo wrote: On Fri, Nov 16, 2001 at 04:02:51PM -0800, Peter Wemm wrote: it. MT_DUMMYNET must die, not be propagated elsewhere. i agree! cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message so far there hasn't been a lot of suggestion as to how the goal can be achieved however.. things it should be: 1/ flexible 2/ queueable 3/ transparent to 3rd party code that doesn't know about it. i.e. if I have metadata with a packet that is passed to a packet filter, that decides that it should be queued (like dummynet), I want the dequeued packet to still have that metadata with it. If I give it to an encryption module, and get it back I don't want the encryption module to have deleted the metadata. We do this in netgraph successfully, where we can store packet priority data (for example) to ensure that housekeeping packets overtake data packets in frame relay. (if you don't do this the fram relay exchange will shot down the link when it gets busy and the housekeeping packets are delayed). We also include data to do with throughput limits and clasification after it has passed though a classifier node. You can't do these things unless you have per-packet information. The idea of the (struct mbuf * m_aux) field is fine by me but that is still using an mbuf, which some people seem to be against.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
so far there hasn't been a lot of suggestion as to how the goal can be achieved however.. i actually suggested one i.e. have explicit pointers to metadata area(s) in the pkthdr. I think you forget the most fundamental feature which is performance. This is way more important than flexibility i think. things it should be: 1/ flexible 2/ queueable 3/ transparent to 3rd party code that doesn't know about it. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
On Fri, 16 Nov 2001 16:13:41 -0800 (PST), Julian Elischer [EMAIL PROTECTED] said: (and anyhow Garrett got rid of the 'static' uses of mbufs, not 'travelling' 'per packet' uses..) Only because I did not have the time or stomach then to introduce `struct packet' everywhere. All of the queueing and metadata crap should be pulled out of mbufs and put into a higher-level object. It's OK if the higher-level object HAS_A(mbuf), but not IS_A(mbuf). This is A Lot Of Work, but would seriously clean up the code in a number of areas. As a general rule, though, reentrancy was not a particular concern of the original design -- that's why there are queues and soft ISRs all over the place -- because you would blow the kernel stack long before that became an issue. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
building cvsup from ports
Hello all, Sounds like a silly place to post this but...here goes. I'm getting errors compiling cvsup from ports. The ports tree installed is the default coming with the 11/12/01 snapshot. I want would use CVS, but I don't know how (and yet I call my self a computer science student). It complains about nfs/nfs.h not existing (I checked, it doesn't). This is the first thing I have built from ports except X in -current, so all of the dependencies besides X were built with this port during make install. I remeber seeing this post on stable a while ago, but can't find the message for the life or me. The error is appended for amusment to those individuals who understand such things. regards, Galen Sampson # cd /usr/ports/net/cvsup # make install To build this port without X11 (and without the GUI), define WITHOUT_X11. === Extracting for cvsup-16.1e Checksum OK for cvsup-snap-16.1e.tar.gz. === cvsup-16.1e depends on file: /usr/local/lib/m3/FreeBSD4/libm3formsvbt.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3formsvbt.so.7 in /usr/ports/lang/pm3-forms === Extracting for pm3-forms-1.1.15 No MD5 checksum file. === pm3-forms-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3vbtkit.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3vbtkit.so.7 in /usr/ports/lang/pm3-gui === Extracting for pm3-gui-1.1.15 No MD5 checksum file. === pm3-gui-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3tcp.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3tcp.so.7 in /usr/ports/lang/pm3-net === Extracting for pm3-net-1.1.15 No MD5 checksum file. === pm3-net-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3.so.7 in /usr/ports/lang/pm3-base === Installing for pm3-base-1.1.15 cd boot-FreeBSD4/m3core/FreeBSD4; gmake -f make.boot CC=cc CFLAGS=-O -pipe AS=as ASFLAGS= AR=ar ARFLAGS=rv RANLIB=touch EXTRALIBS=-lm LDFLAGS= gmake[1]: Entering directory `/usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4' cc -O -pipe-c -o RTHeapDepC.o RTHeapDepC.c RTHeapDepC.c:101: nfs/nfs.h: No such file or directory RTHeapDepC.c: In function `mount': RTHeapDepC.c:719: dereferencing pointer to incomplete type RTHeapDepC.c:719: dereferencing pointer to incomplete type RTHeapDepC.c:720: dereferencing pointer to incomplete type RTHeapDepC.c:720: dereferencing pointer to incomplete type RTHeapDepC.c:721: dereferencing pointer to incomplete type RTHeapDepC.c:721: dereferencing pointer to incomplete type gmake[1]: *** [RTHeapDepC.o] Error 1 gmake[1]: Leaving directory `/usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4' gmake: *** [boot] Error 2 *** Error code 2 Stop in /usr/ports/lang/pm3-base. *** Error code 1 Stop in /usr/ports/lang/pm3-base. *** Error code 1 Stop in /usr/ports/lang/pm3-base. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. __ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
ok, so how would you envision it? example? Adding fields to the pkthdr? (and flags to say what they are used for). A pointer to route, (maybe the route in ip_forward() can be dynamically allocated on the stack, I'm not sure yet) A pointer to a sockaddr, with a flag to say if it's for 'fwd' use or 'xmit' use. (but they may both be needed together).. can we guarantee that these will be freed correctly when the mbuf is freed? On Fri, 16 Nov 2001, Luigi Rizzo wrote: so far there hasn't been a lot of suggestion as to how the goal can be achieved however.. i actually suggested one i.e. have explicit pointers to metadata area(s) in the pkthdr. I think you forget the most fundamental feature which is performance. This is way more important than flexibility i think. things it should be: 1/ flexible 2/ queueable 3/ transparent to 3rd party code that doesn't know about it. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
On Fri, 16 Nov 2001, Garrett Wollman wrote: On Fri, 16 Nov 2001 16:13:41 -0800 (PST), Julian Elischer [EMAIL PROTECTED] said: (and anyhow Garrett got rid of the 'static' uses of mbufs, not 'travelling' 'per packet' uses..) Only because I did not have the time or stomach then to introduce `struct packet' everywhere. All of the queueing and metadata crap should be pulled out of mbufs and put into a higher-level object. It's OK if the higher-level object HAS_A(mbuf), but not IS_A(mbuf). In netgraph, (in -current) we have a packet structure that has links for A) mbufs for the data, and B) optinal metadata. I'd be happy with a HAS_A(mbuf), as long as I have SOMEWHERE, to stash the metadata. This is A Lot Of Work, but would seriously clean up the code in a number of areas. I'm not afraid of the work, but there needs to be a roadmap first. As a general rule, though, reentrancy was not a particular concern of the original design -- that's why there are queues and soft ISRs all over the place -- because you would blow the kernel stack long before that became an issue. True, but times change and we have to cross that bridge soon.. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: re-entrancy and the IP stack.
On Fri, 16 Nov 2001, Luigi Rizzo wrote: so far there hasn't been a lot of suggestion as to how the goal can be achieved however.. i actually suggested one i.e. have explicit pointers to metadata area(s) in the pkthdr. I think you forget the most fundamental feature which is performance. This is way more important than flexibility i think. Which is the reason that this problem exists.. no-one ever thinks that people will want to do things different to what they want to do at the time they write it.. Flexibility is I think much more important than you suggest. Wouldn't it have made it easier for you if there had been a flexible method to pass such information available? The m_aux field sounds right to me. Alternatively, the ability to define a separate data area in an M_HDR mbuf.. (There's a lot of wasted space there in M_EXT packets.) [normal header][pkthdr][METADATA][normal_data] The metadata would be there regardless of whether the M_EXT flag was set or not. things it should be: 1/ flexible I.e Don't screw over Luigi's NEXT project, Dummynet2. 2/ queueable I want to let dummynet2 do queuing of packets and keep my 'class' information with each packet. 3/ transparent to 3rd party code that doesn't know about it. I don't want My module to have to know about the stuff Dummynet2 is storing with the packet, and I don't want dummynet2 to need to know what I have stashed in there.. 4/ Self-descriptive: If I free a packet, I shouldn't produce a leak of some other items somewhere else. (they should describe how they should be freed!) cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Need a Home Loan? Let Us Help!
Title: Free Rate Quote Refinance Your Current Mortgage While Rates Are LOW!! HOME EQUITY LOANS *** JUMBO LOANS *** HOME IMPROVEMENT LOANS *** DEBT CONSOLIDATION LOANS *** REFINANCE LOANS *** ALL ARE AVAILABLE TO YOU *** RATES AS LOW AS 3.95% Mortgage Rates Are So Low! You Can Save Thousands Of Dollars By Taking Advantage Now! WE ARE AN ASSOCIATION OF MORTGAGE BROKERS AND LENDERS WITH THE BEST RATES AND THE LOWEST COSTS! Wehave thousands of loan programs through hundreds of lenders! You can choose from"Adjustable Rate Mortgages as low as 3.95% and"Fixed Rate Mortgages as low as 5.75% all with the lowest costs in the Nation!* YOU CAN BUY DOWN YOUR INTEREST RATE TO AS LOW AS YOU CAN AFFORD! *All rates are based on qualification! Click here for your "FREE RATE QUOTE"! CLICK ON LOANS BELOW FOR YOUR FREE APPLICATION! Purchase Loans - Thousands of programs for First Mortgages!Refinance Loans - Reduce your monthly payments and Get Cash Back! Second Mortgages - We can help you get from 90% up to 125% of your homes value! (ratios vary by state) Debt Consolidation - Combine all your bills into One Low Monthly Payment!First Time Home Buyers - We can help you buy with Low Money Down, and even Get Cash Back! *All rates are based on qualification! We have programs for EVERY credit situation!Click here for your FREE RATE QUOTE! This message is being sent to you in compliance withBill S. 1618 Title III passed by the 105th US Congress, which states that this letter can not be considered spam as long as we include (1) Valid Contact Information and (2)a way to be removed from any further transmissions at no cost to you by submitting a request to be removed. . Click Here to Send a Remove Request. We honor all remove email address requestsimmediately.
Re: re-entrancy and the IP stack.
In my MAC tree, I add an additional:
struct mbuf *aux; /* extra data buffer; ipsec/others */
+ struct mac label; /* label of data in packet */
};
As we move towards more generalized access control, it would similarly be
nice to have a place to 'hang' additional labeling information for network
transmission objects (packets, control messages, whatever). One of my
primary concerns for such as system, and one of the reasons I haven't
seriously contemplated implementing it, is how to maintain performance.
In a non-SMPng world, it's already an issue, but once you throw in
fine-grained locking/etc, you begin to worry about locking and referencing
counting for these objects. Ideally, I think such as 'hooking' mechanism
would be extremely flexible and transparent, but as you point out,
performance is (and will continue to be) a primary concern in this code.
It might be interesting to do some experimentation with various schemes
for adding this extensibility. I've done a little bit of work to look at
run-time vs. compile-time extensibility for the network stack. For
example, I'm interested in the idea that the TCP/IP IPv4 implementation be
pluggable via a kernel module. Adding such dynamicism would necessarily
introduce locking/atomicity concerns during registration and removal. I'd
like for it to be the case that if you link the module in at compile time
(or before the kernel goes live during the boot), you'd maintain current
native speed, but that if you dynamically load it, you accept the
additional cost.
One way to do this might be to have an optimized dynamically compiled
structure (maybe derived from linker sets) either when the kernel is
compiled or linked, for fast path processing. When there is a fast path
miss, then the kernel falls back to a slower dynamic path. E.g.,
const struct ipproto *ipprotolist[] = {, , , ... NULL};
struct mtx ipprotolist_extensions_lock;
struct ipproto *ipprotolist_extensions[];
Fast path hits would not require use of the mutex, but slow path would;
dynamically introduced protocols would by definition be on the slow path,
but if compiled in, would be attached to the fast path.
Likewise, you could imagine mbuf extensibility working the same way:
depending on how to consuming feature is loaded, it is provided a
lock-free/fast extension capability, and if it is dynamically loaded, the
slower alternative is selected. This would allow many locking costs to be
avoided in the network code for optimized environment, but still allow the
necessarily expensive extensibility.
Just a thought.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Fri, 16 Nov 2001, Luigi Rizzo wrote:
so far there hasn't been a lot of suggestion as to how the goal can be
achieved however..
i actually suggested one i.e. have explicit pointers
to metadata area(s) in the pkthdr. I think you forget the
most fundamental feature which is performance.
This is way more important than flexibility i think.
things it should be:
1/ flexible
2/ queueable
3/ transparent to 3rd party code that doesn't know about it.
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
