Re: Release Engineering Status Report
On Tue, 16 Sep 2003, Scott Long wrote: :Bruce Evans wrote: : On Tue, 16 Sep 2003, Maxim Konovalov wrote: : : :PAE MFC brought an incredible instability to stable branch. It :affects 100% of our user community especially when we issued several :SAs since PAE commit. They often can't switch to RELENG_4_x security :branches because even RELENG_4_8 misses several critical non-security :fixes. : : : I merged PAE into my version of -current a bit at a time and didn't : notice any problems (with PAE not actually configured) despite having : some large logical inconsistencies from not having all of it. Most : of the global changes had no effect since they just changed the names : of some typedefs without changing the underlying types in the !PAE : case. So I suspect that any instabilities in RELENG_4 in the !PAE : case are indirectly related to PAE and/or localized and thus easy to : find and fix. : : Bruce : : :Agreed. PAE was merged into -stable in three steps. Backing out the :third step and leaving the first two steps removes the instability. :Unfortunately, it was the third step that also was the most complex. :In any case, we have 2 weeks to find the resolution before the decision :must be made on keeping or tossing PAE. Since PAE is a *highly* :sought after feature, it would be doing a disservice to our user base :to remove it without putting in some effort to fix it. : I fully agree with the last statement here. One reason my current employer left FreeBSD 4.x and went to linux for our embedded system was due to the lack of PAE support. We were planning to implement the extensions ourself, but, unfortunately, we in engineering were affected by time and money issues. Scott, keep up the good work. Cheers, Andrew -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libthr and 1:1 threading.
On Wed, 2 Apr 2003, Peter Wemm wrote: :Terry Lambert wrote: : : KSE mailing list, starting Monday or so: : ] We still haven't heard from jeff with regard to the process : ] signal mask removal. : :We can add new mailing lists really easily now - it takes about 20-30 seconds. :Would it be worth adding a freebsd-threads and/or freebsd-kse type list :where it is a bit higher profile? : :Cheers, :-Peter :-- I would like this. I seem to remember a mail awhile back stating that there was a 'secret' list going on for thread discussion. Since this is a big part of -CURRENT (and has been, duh), it's sorta scary to have it be hidden. Did I miss a message regarding how to sign up for this? -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ethernet (xl) will not transmit or receive
-ATA66 cable or device :ad0: 13031MB FUJITSU MPE3136AT [26476/16/63] at ata0-master UDMA33 :ad2: 13029MB Maxtor 91366U4 [26473/16/63] at ata1-master UDMA33 :acd0: CDROM SONY CD-ROM CDU4821 at ata1-slave UDMA33 :Mounting root from ufs:/dev/ad0s1a :cd0 at ata1 bus 0 target 1 lun 0 :cd0: SONY CD-ROM CDU4821 S0.M Removable CD-ROM SCSI-0 device :cd0: 33.000MB/s transfers :cd0: Attempt to query device size failed: NOT READY, Medium not present : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet (xl) will not transmit or receive
On Thu, 20 Feb 2003, Nick H. wrote: :I am absolutely sure, as its on a completely fresh system. : :ipf: IP Filter: v3.4.29 (336) :Kernel: IP Filter: v3.4.29 Maxime, FWIW, my troubles were with the 5.0-RELEASE boot floppies (booted off them to install -RELEASE on my blazing speed demon dual ppro 200). Cheers, Andrew : : : :- Original Message - :From: Maxime Henrion [EMAIL PROTECTED] :To: Nick H. -- Technical Support Engineer [EMAIL PROTECTED] :Cc: [EMAIL PROTECTED] :Sent: Thursday, February 20, 2003 3:11 PM :Subject: Re: Ethernet (xl) will not transmit or receive : : :: Nick H. -- Technical Support Engineer wrote: :: Ive run into the exact same problem on about 8 machines now, all running :: different network cards. The network will just simply not work if I :have :: IPFILTER built into the kernel. On some of the machines, I started :getting :: No route to host. This has happened on the following network cards: :: :: 3COM 3C905C :: 3COM 3C450 *yes, 450* :: Linksys LNE100TX v4 :: Linksys LNE100TX v5 :: NETGEAR Fast 100 :: Intel Pro 10/100+ :: Intel Pro 10/100/1000 (gigabit over copper) :: :: Im going to assume that since it's not on a specific card, it's not :: something with the drivers for that card. The only thing I could do was :: deinstall IPFILTER. I tried wiping the ARP tables (showed incomplete :arp :: entries for all hosts) and even redoing the routing table. The only :thing :: that I could get that would fix it was removing ipfiter. I have another :: 5.0-CURRENT machine (FreeBSD 5.0-CURRENT #2: Wed Jan 29 17:55:34 CST :2003 :: root@edge:/usr/obj/usr/src/sys/edge i386) that is NOT having this :problem. :: It's something done fairly recently that has caused this. Im going to :go :: through and see if I cant find some differences between the source for :that :: version and this one: 5.0-CURRENT #1: Wed Feb 19 10:28:49 GMT 2003 :: root@ender:/usr/obj/usr/src/sys/ender i386 :: :: The second one (last one I gave uname for) is the most recent to have :the :: problems. As you can see, it's source from earlier this week. There's :no :: errors on dmesg nor are there any errors anywhere. It just seems that :if :: IPFILTER is enabled, the network devices are completely inoperable. I :know :: you're going to ask how I have the rules setup, and I have tried many :: variations. The first I tried is a DEFAULT_BLOCK using a working :ruleset :: from a 4.7-R-p3 machine. After that failed, I tried doing a default :allow, :: and it still did it. The only feasible way to get the machine online :with :: that source is to rip out IPFILTER. Anyone having similiar issues? :: :: Any comments/suggestions would be more than welcome, as having boxes on :the :: network with no firewall is just asking for trouble ;) :: :: Are you sure the ipfilter version of your kernel is in sync with your :: userland ipfilter utility? ipf -V will show you both versions. :: :: Cheers, :: Maxime :: :: 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 : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usbd patch (MAXUSBDEV no more)
On Thu, 13 Feb 2003, Adam Migus wrote: :This patch makes usbd track a dynamic number of devices using a list :instead of the static array of 4 devices. It's implemented as a list :but it's very easy to change. Does this list want a lock to protect it? I am unfamiliar with usb locking at the moment, so ignore if stupid. Cheers, Andrew -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Upgrading from 5.0-RELEASE to -CURRENT on sparc64
I have a u60 (mp) and installed 5.0-RELEASE with the miniinst iso. I am trying to buildworld, but am receiving: work/arrwrk/src/contrib/gcc/config/elfos.h:323:1: warning: TARGET_ASM_NAMED_SECTION redefined In file included from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/tconfig.h:15, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /work/arrwrk/src/contrib/gcc/cp/spew.c:26: /work/arrwrk/src/contrib/gcc/config/sparc/sysv4.h:172:1: warning: this is the location of the previous definition In file included from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/tconfig.h:11, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /work/arrwrk/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parse.y:34, from /work/arrwrk/src/contrib/gcc/cp/spew.c:34: /work/arrwrk/src/contrib/gcc/config/elfos.h:437:1: warning: TYPE_OPERAND_FMT redefined In file included from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/tconfig.h:15, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /work/arrwrk/src/contrib/gcc/cp/spew.c:26: /work/arrwrk/src/contrib/gcc/config/sparc/sysv4.h:96:1: warning: this is the location of the previous definition In file included from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/tconfig.h:11, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /work/arrwrk/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parse.y:34, from /work/arrwrk/src/contrib/gcc/cp/spew.c:34: /work/arrwrk/src/contrib/gcc/config/elfos.h:594:1: warning: STRING_ASM_OP redefined In file included from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/tconfig.h:15, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /work/arrwrk/src/contrib/gcc/cp/spew.c:26: /work/arrwrk/src/contrib/gcc/config/sparc/sysv4.h:87:1: warning: this is the location of the previous definition In file included from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/tconfig.h:12, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /work/obj/work/arrwrk/src/sparc64/work/arrwrk/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /work/arrwrk/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parse.y:34, from /work/arrwrk/src/contrib/gcc/cp/spew.c:34: /work/arrwrk/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:61:25: attempt to use poisoned malloc /work/arrwrk/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:62:25: attempt to use poisoned calloc /work/arrwrk/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:63:25: attempt to use poisoned realloc /work/arrwrk/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:64:25: attempt to use poisoned strdup mkdep: compile failed *** Error code 1 Stop in /work/arrwrk/src/gnu/usr.bin/cc/cc1plus. *** Error code 1 Stop in /work/arrwrk/src/gnu/usr.bin/cc. *** Error code 1 Stop in /work/arrwrk/src. *** Error code 1 Stop in /work/arrwrk/src. *** Error code 1 Stop in /work/arrwrk/src. ... I did not script(1) this so I dont have a further backtrace (so to speak). I can produce one if requested. Anyone have any thoughts? Or am I being a fool linking /usr/obj - /work/obj and building world in /work/arrwrk/src/ ? Thanks for any help. Cheers, andrew -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
On Tue, 10 Sep 2002, Dag-Erling Smorgrav wrote: :cc1: warnings being treated as errors :/local0/scratch/des/src/sys/dev/cardbus/cardbus.c: In function `cardbus_driver_added': :/local0/scratch/des/src/sys/dev/cardbus/cardbus.c:319: warning: unused variable :`cardattached' :*** Error code 1 I just committed a fix for this, JFYI. Cheers, -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic at boot in ffs_valloc
:I cvsup'd and built world+kernel a few hours ago and was happy to see :KDE working again, but I got a spontaneous reboot while trying to track :down a segfault in a mozilla build component. I boot -v'ed and as :soon as the login prompt came up I hit a panic. I'm guessing the :backgorund fsck had something to do with it. I'll hand-copy the trace :here; any debugging info needed while my box is stuck at the debugger, :lemme know: I don't have the output to show people since I was trying to reproduce but couldnt, but i got essentially the same panic, but it came only from a syscall to open() that called ufs_create() - ufs_makeinode - ffs_valloc() - panic. I can try and reproduce (tho, mine occured when just running cscope) and get a dump. Cheers, Andrew :FreeBSD/i386 (foo) (ttyv0) : :login: mode = 041777, inum = 12871, fs = /usr :panic: ffs_valloc: dup alloc :cpuid = 0; lapic.id = :Debugger(panic) :Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 :db trace :Debugger(c02d9eda) at Debugger+0x46 :panic(c02e9a21,c02e9a00,43ff,3247,c41c58d4) at panic+0xd6 :ffs_valloc(c4284100,8100,c159a180,d6afd6f0) at ffs_valloc+0x141 :ufs_makeinode(8100,c4284100,d6afda20,d6afda34) at ufs_makeinode+0x58 :ufs_create(d6afd94c,d6afda68,c0248a68,d6afd94c,c0346b78) at ufs_create+0x26 :ufs_vnoperate(d6afd94c) at ufs_vnoperate+0x13 :ffs_snapshot(c41b7600,80b2ba0,d6afda94,c41db700,c0346bf0) at :ffs_snapshot+0x2a0 :ffs_mount(c41b7600,c4421200,bfbffcc0,d6afdbf8,c159f300) at ffs_mount+0x48 :vfs_mount(c159f300,c41b2eb0,c4421200,1211000,bfbffcc0) at ffs_mount+0x6dc :mount(c159f300,d6afdd14,4,1,202) at mount+0x6a :syscall(2f,2f,2f,0,bfbffde0) at syscall+0x23c :syscall_with_err_pushed() at syscall_with_err_pushed+0x1b :--- syscall (21, FreeBSD ELF, mount), eip = 0x80549d7, esp = 0xbfbffbdc, :ebp = 0xbfbffd48 --- :db : :-- :Anthony Jenkins :http://www.mindspring.com/~abjenkins/ : : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: interesting: problem with nm?
On Thu, 27 Jun 2002, Szilveszter Adam wrote: :On Thu, Jun 27, 2002 at 08:05:21PM +0200, Christian Brueffer wrote: : On Thu, Jun 27, 2002 at 10:28:00AM -0700, Matthew Dillon wrote: : It would be great if you guys could re-test with the pmap fix : (/usr/src/sys/i386/i386/pmap.c r1.326). I believe that the pmap : bug was to blame for all of these issues but I need verification before : I have the comfort level necessary to do the MFC I intended to do. : : -Matt : Matthew Dillon : [EMAIL PROTECTED] : : : : Everything works great with the fix. : :Which exposes another interesting problem. : :If I issue 'nm -v', it says: : :/usr/libexec/elf/nm: a.out: No such file or directory : :This system was last upgraded tonight, so has code from around 26th in :the userland. Kernel has been upgraded to code from this evening. : :Does anybody else see this? I have a userland from a week and a half ago (or so? :-/) with last night's kernel (with the pmap.c fix) and do not experience this issue. Cheers, -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA/MTX ..last thing stopping KSE M-III
On Mon, 24 Jun 2002, Julian Elischer wrote: : :I am seeing the following error messages: : :../../../vm/uma_core.c:1331: could sleep with process lock locked from :../../../kern/kern_proc.c:258 : :Though the system is really quite stable now. : :anyone understand well what this message is trying to say? : You're holding PROC_LOCK(), obtained at kern_proc line 258, over a function call that could block (I assume malloc(9) with M_WAITOK). The fix is to change the locking to properly not hold the lock over the possible sleep situation. Cheers, -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new zero copy sockets patches available
:Alfred Perlstein wrote: : * Kenneth D. Merry [EMAIL PROTECTED] [020517 23:31] wrote: : The problem here is that the mutex needs to be initialized before I can : acquire it, and there's going to be a race between checking to see : whether it has been initialized and actually initializing it. : : ... : Suggestions? : : *slaps forhead* : : Probably a SYSINIT? mutex(9) and sx(9) describe two macros for this purpose. -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: latest kernel busted
On Mon, 1 Apr 2002, M. Warner Losh wrote: :=== umodem :cc -O -pipe -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes :-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi :-DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g :-mpreferred-stack-boundary=2 -Wall -Wredundant-decls -Wnested-externs :-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual :-fformat-extensions -ansi -c :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:840: syntax error :before `uio' :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c: In function :`umodemread': someone forgot a struct before the ``uio *uio'' :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:841: number of :arguments doesn't match prototype :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:156: prototype :declaration :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:845: `dev' undeclared :(first use in this function) :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:845: (Each undeclared :identifier is reported only once :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:845: for each :function it appears in.) :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:852: `uio' undeclared :(first use in this function) :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:852: `flag' :undeclared (first use in this function) :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c: At top level: :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:1089: conflicting :types for `umodem_set_line_coding' :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:188: previous :declaration of `umodem_set_line_coding' :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c: In function :`umodem_set_line_coding': :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:1097: incompatible :type for argument 1 of `bcmp' :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:1109: incompatible :type for argument 3 of `usbd_do_request' :/dell/imp/FreeBSD/src/sys/modules/umodem/../../dev/usb/umodem.c:1116: invalid type :argument of `unary *' :*** Error code 1 : :Ideas? : :Warner : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Some info on the kgmon(8) manual page (regarding current) needed
On Wed, 27 Mar 2002, Hiten Pandya wrote: :Hi all, : :According to -current, isnt the kernel file located /boot/kernel? : :How come the kgmon(8) is still refering to /kernel? Is this a bug or I :am unaware of something? :) If it is a bug, than I probably someone can :commit the change in behalf of me.. :) Generate diffs -- send-pr. : :Thanks, : :-- :Hiten Pandya :http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD) :http://www.FreeBSD.org - The Power to Serve : :Public Key: http://www.pittgoth.com/~hiten/pubkey.asc :--- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 --- : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Some info on the kgmon(8) manual page (regarding current) needed
On Wed, 27 Mar 2002, Hiten Pandya wrote: : Generate diffs -- send-pr. : :Does this apply to all the manual pages in -CURRENT? where /kernel :should be /boot/kernel/kernel? If this is the case, then I can just :send one or two big PRs which have the patches. : :What are your suggestions? :) This discussion should probably take place within the context of bug reporting system; please submit a pr and we can discuss there. : :Thanks, : :-- :Hiten Pandya :http://jfs4bsd.sf.net - JFS for FreeBSD (JFS4BSD) :http://www.FreeBSD.org - The Power to Serve : :Public Key: http://www.pittgoth.com/~hiten/pubkey.asc :--- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 --- : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCcard whine issued during halt -p processing
On Sat, 23 Mar 2002, M. Warner Losh wrote: :I wouldn't worry about the messages. They are debugging printfs that :should really be beind boot verbose or something similar. Are there enough debug printfs that would warrant a sysctl tunable for debug messages? Andrew : :Thanks for the info, however. : :Warner : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCcard whine issued during halt -p processing
On Sat, 23 Mar 2002, Andrew R. Reiter wrote: :On Sat, 23 Mar 2002, M. Warner Losh wrote: : ::I wouldn't worry about the messages. They are debugging printfs that ::should really be beind boot verbose or something similar. : :Are there enough debug printfs that would warrant a sysctl tunable for :debug messages? Erm, ignore this question; just cscope'd bootverbose and realized I didn't read the second sentence of your message. Andrew -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
On Wed, 20 Feb 2002, George V. Neville-Neil wrote: :I'm not in the core of the SMP stuff (the closest I'll get is the :networking stuff) but I wonder if there is: Doesn't this belong on [EMAIL PROTECTED] so that SMP people could answer? : :1) A work list of things that need to be done. : :2) If that list is easy to read/update. : :Has anyone considered a Wiki to do this kind of coordination? We used :TWiki at my last employer to decent effect. Check out www.twiki.org. : :Later, :George : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fatal trap 12 on kernel from sometime Nov. 30.
cvsup -- this was fixed sometime within the last 24hours. On Sat, 1 Dec 2001, Edwin Culp wrote: :With my kernel and with a Generic kernel, I am getting a Fatal trap 12 :when trying to access the network. :The first thing that happens on the network seems to cause the panic. : The following was an error with a :generic kernel. I'm typing it so there could be mistakes. : :Fatal trap 12: page fault while in kernel mode :fault virtual address= 0x0 :fault code= supervisor read, page not present :instruction pointer = 0x8:0xc0289ad4 :stack pointer = 0x10:0xdbef5b58 :frame pointer = 0x10:0xdbef5ba4 :code segment = base 0x0, limit 0xf, type 0x1b := DPL 0, pres 1, def32 1, gran 1 :processor eflags = interrupt enabled, resume, IOPL = 0 :current process = 11 (swi1: net) :kernel: type 12 trap, code=0 :Stopped atip_output+0x118: cmpl$0,0(%eax) : :db Context switches not allowed in the debugger. :db : :The debugger is open but I don't know what I'm looking for. Any help :will be appreciated. : :Thanks, : :ed : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fatal trap 12 on kernel from sometime Nov. 30.
Edwin,
The following is the current fix in place:
Index: ip_output.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.142
retrieving revision 1.143
diff -u -r1.142 -r1.143
--- ip_output.c 4 Nov 2001 22:56:25 - 1.142
+++ ip_output.c 1 Dec 2001 13:48:16 - 1.143
@@ -31,7 +31,7 @@
* SUCH DAMAGE.
*
* @(#)ip_output.c 8.3 (Berkeley) 1/21/94
- * $FreeBSD: src/sys/netinet/ip_output.c,v 1.142 2001/11/04 22:56:25
luigi Exp
$
+ * $FreeBSD: src/sys/netinet/ip_output.c,v 1.143 2001/12/01 13:48:16 ru
Exp $
*/
#define _IP_VHL
@@ -123,11 +123,11 @@
struct mbuf *m = m0;
int hlen = sizeof (struct ip);
int len, off, error = 0;
+ struct route iproute;
struct sockaddr_in *dst;
struct in_ifaddr *ia;
int isbroadcast, sw_csum;
#ifdef IPSEC
- struct route iproute;
struct socket *so = NULL;
struct secpolicy *sp = NULL;
#endif
@@ -188,9 +188,6 @@
#ifdef DIAGNOSTIC
if ((m-m_flags M_PKTHDR) == 0)
panic(ip_output no HDR);
- if (!ro)
- panic(ip_output no route, proto = %d,
- mtod(m, struct ip *)-ip_p);
#endif
if (opt) {
m = ip_insertoptions(m, opt, len);
@@ -213,6 +210,11 @@
hlen = IP_VHL_HL(ip-ip_vhl) 2;
}
+ /* Route packet. */
+ if (ro == NULL) {
+ ro = iproute;
+ bzero(ro, sizeof(*ro));
+ }
dst = (struct sockaddr_in *)ro-ro_dst;
/*
* If there is a cached route,
Index: ip_mroute.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_mroute.c,v
retrieving revision 1.68
retrieving revision 1.69
diff -u -r1.68 -r1.69
--- ip_mroute.c 29 Oct 2001 02:19:19 - 1.68
+++ ip_mroute.c 1 Dec 2001 13:48:16 - 1.69
@@ -9,7 +9,7 @@
* Modified by Bill Fenner, PARC, April 1995
*
* MROUTING Revision: 3.5
- * $FreeBSD: src/sys/netinet/ip_mroute.c,v 1.68 2001/10/29 02:19:19
dillon Exp
$
+ * $FreeBSD: src/sys/netinet/ip_mroute.c,v 1.69 2001/12/01 13:48:16 ru
Exp $
*/
#include opt_mrouting.h
@@ -1867,7 +1867,6 @@
{
struct ip_moptions imo;
int error;
-static struct route ro;
int s = splnet();
if (vifp-v_flags VIFF_TUNNEL) {
@@ -1886,7 +1885,7 @@
* should get rejected because they appear to come from
* the loopback interface, thus preventing looping.
*/
- error = ip_output(m, (struct mbuf *)0, ro,
+ error = ip_output(m, (struct mbuf *)0, NULL,
IP_FORWARDING, imo);
if (mrtdebug DEBUG_XMIT)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libfetch kqueue patch
As from OpenBSD (in shorter form): fd_set *fds = calloc(howmany(fd+1, NFDBITS), sizeof(fd_mask)); FD_SET(fd, fds); select(fd+1, fds...); As for being portable, the only thing I've seen that is nice and neat is libevent from Niels Provos, but I think some people had issues with the way it handled kqueue support. On Mon, 26 Nov 2001, David Malone wrote: :On Mon, Nov 26, 2001 at 03:04:56PM -0500, Andrew R. Reiter wrote: : Agreed, or people could code with select in a nice manner and dynamically : allocate the fd_set arrays. : :Is there a portable way to allocate dynamically sized fd_sets? It :could easily be one of those things that you're not supposed to :know how it works inside. : : David. : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: weird -current gdb/gcc(?) problem
On Thu, 1 Nov 2001, Maksim Yevmenkin wrote: :inet_addr() :__inet_aton() :inet_addr() :__inet_aton() : I've had similar issues. I just sent in a pr yesterday where the recursive call was to sigprocmask() -- this happened when I managed to core sysinstall and when I managed to core cvs remotely. ugh. Andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Call for testers: LDT - MD Proc
Hi,
The attached patch is to sys/i386/* code. It's basically 50%, albeit the
easy 50%, of the Junior Kernel Hacker task from jhb last month. I
finished it and tested awhile ago (~1 month) but my current box died. My
current box is still dead, so I've yet to test it any further, but Peter
Wemm and jhb both looked at it and said it looked ok and to get people
to test it.
The attached patch is for current from 9/19/01 -- Yes, Im sorry, this
sucks. I have a 4.3 release CD here so Im going to have to use that to
rebuild a box back to current (FTP installs with 4.4 floppies have really
sucked). If you're willing to test and don't mind this patch, thanks. If
you are willing to test and want a newer patch, let me know and I'll get
you one tonight or tomorrow.
Btw, the patch is also located at
http://www.watson.org/~arr/fbsd-patches/ldt-2-mdproc.diff
Cheers,
Andrew
*-.
| Andrew R. Reiter
| [EMAIL PROTECTED]
| It requires a very unusual mind
| to undertake the analysis of the obvious -- A.N. Whitehead
--- include/pcb.h.orig Wed Sep 19 02:07:48 2001
+++ include/pcb.h Wed Sep 19 02:08:37 2001
@@ -61,7 +61,6 @@
int pcb_dr6;
int pcb_dr7;
- struct pcb_ldt *pcb_ldt; /* per process (user) LDT */
union savefpu pcb_save;
u_char pcb_flags;
#defineFP_SOFTFP 0x01/* process using software fltng pnt emulator
*/
--- include/pcb_ext.h.orig Wed Sep 19 02:07:54 2001
+++ include/pcb_ext.h Wed Sep 19 02:10:37 2001
@@ -43,20 +43,9 @@
struct vm86_kernel ext_vm86; /* vm86 area */
};
-struct pcb_ldt {
- caddr_t ldt_base;
- int ldt_len;
- int ldt_refcnt;
- u_long ldt_active;
- struct segment_descriptor ldt_sd;
-};
-
#ifdef _KERNEL
int i386_extend_pcb __P((struct thread *));
-void set_user_ldt __P((struct pcb *));
-struct pcb_ldt *user_ldt_alloc __P((struct pcb *, int));
-void user_ldt_free __P((struct pcb *));
#endif
--- include/proc.h.orig Wed Sep 19 02:07:59 2001
+++ include/proc.h Wed Sep 19 03:28:55 2001
@@ -38,6 +38,15 @@
#define_MACHINE_PROC_H_
#include machine/globals.h
+#include machine/segments.h
+
+struct proc_ldt {
+caddr_t ldt_base;
+int ldt_len;
+int ldt_refcnt;
+u_long ldt_active;
+struct segment_descriptor ldt_sd;
+};
/*
* Machine-dependent part of the proc structure for i386.
@@ -46,6 +55,15 @@
};
struct mdproc {
+ struct proc_ldt *md_ldt;/* per-process ldt */
};
+
+#ifdef _KERNEL
+
+void set_user_ldt __P((struct mdproc *));
+struct proc_ldt *user_ldt_alloc __P((struct mdproc *, int));
+void user_ldt_free __P((struct thread *));
+
+#endif /* _KERNEL */
#endif /* !_MACHINE_PROC_H_ */
--- i386/genassym.c.origWed Sep 19 02:16:34 2001
+++ i386/genassym.c Wed Sep 19 13:03:45 2001
@@ -63,6 +63,7 @@
#include vm/pmap.h
#include vm/vm_map.h
#include sys/user.h
+#include sys/proc.h
#include net/if.h
#include netinet/in.h
#include nfs/nfsproto.h
@@ -76,6 +77,7 @@
#include machine/sigframe.h
#include machine/globaldata.h
#include machine/vm86.h
+#include machine/proc.h
ASSYM(P_VMSPACE, offsetof(struct proc, p_vmspace));
ASSYM(VM_PMAP, offsetof(struct vmspace, vm_pmap));
@@ -92,6 +94,9 @@
ASSYM(TD_PROC, offsetof(struct thread, td_proc));
ASSYM(TD_INTR_NESTING_LEVEL, offsetof(struct thread, td_intr_nesting_level));
+ASSYM(P_MD, offsetof(struct proc, p_md));
+ASSYM(MD_LDT, offsetof(struct mdproc, md_ldt));
+
ASSYM(KE_FLAGS, offsetof(struct kse, ke_flags));
ASSYM(KEF_ASTPENDING, KEF_ASTPENDING);
@@ -126,7 +131,6 @@
ASSYM(PCB_EIP, offsetof(struct pcb, pcb_eip));
ASSYM(TSS_ESP0, offsetof(struct i386tss, tss_esp0));
-ASSYM(PCB_USERLDT, offsetof(struct pcb, pcb_ldt));
ASSYM(PCB_GS, offsetof(struct pcb, pcb_gs));
ASSYM(PCB_DR0, offsetof(struct pcb, pcb_dr0));
ASSYM(PCB_DR1, offsetof(struct pcb, pcb_dr1));
--- i386/machdep.c.orig Wed Sep 19 02:16:39 2001
+++ i386/machdep.c Wed Sep 19 04:57:31 2001
@@ -103,6 +103,7 @@
#include machine/md_var.h
#include machine/pc/bios.h
#include machine/pcb_ext.h /* pcb.h included via sys/user.h */
+#include machine/proc.h
#include machine/globals.h
#ifdef PERFMON
#include machine/perfmon.h
@@ -880,8 +881,8 @@
struct trapframe *regs = td-td_frame;
struct pcb *pcb = td-td_pcb;
- if (pcb-pcb_ldt)
- user_ldt_free(pcb);
+ if (td-td_proc-p_md.md_ldt)
+ user_ldt_free(td);
bzero((char *)regs, sizeof(struct trapframe));
regs-tf_eip = entry;
--- i386/swtch.s.orig Wed Sep 19 02:16:14 2001
+++ i386/swtch.sThu Sep 20 03:51:55 2001
@@ -246,7 +246,8 @@
/* XXX FIXME: we should be restoring the local APIC TPR
