Re: kernel panic when booting with USB CF reader
On Sat, Sep 28, 2002 at 07:20:08PM -0700, Lars Eggert wrote: > Hi, > > I'm seeing a kernel panic on -current (9/26) when booting with a SanDisk > ImageMate II USB comact flash reader plugged in. The panic occurs after > the kernel has loaded when the first rc.d scripts execute (dumpon, > vinum, etc). > > If I boot with the device disconnected, I can plug it in and unplug it > without problems later. > > Attached is a boot trace and a gdb backtrace. (gdb crashed on me, so I > couldn't get more information.) Here's the relevant info from the trace: > > SMP: AP CPU #1 Launched! > Mounting root from ufs:/dev/da0s1a > Entropy harvesting: interrupts ethernet point_to_point. > kernel dumps on /dev/da1s1b > vinum: loaded > umass0: BBB reset failed, STALLED > da2 at umass-sim0 bus 0 target 0 lun 0 > da2: Removable Direct Access SCSI-2 device > da2: 1.000MB/s transfers > da2: Attempt to query device size failed: NOT READY, Medium not present > (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da2:umass-sim0:0:0:0): SCSI Status: Check Condition > (da2:umass-sim0:0:0:0): NOT READY asc:3a,0 > (da2:umass-sim0:0:0:0): Medium not present > (da2:umass-sim0:0:0:0): Unretryable error > > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 1; lapic.id = 0200 > instruction pointer = 0x8:0xc0437608 > stack pointer = 0x10:0xeb484870 > frame pointer = 0x10:0xeb4848f8 > 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 = 67 (vinum) > kernel: type 18 trap, code=0 > Stopped at __qdivrem+0x38: divl%ecx,%eax I'm seeing the same with a SCSI mo drive. As a short term work around I inserted a media. src from 31th Aug did run and from 21th Sep does not. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is phk rewriting the kernel over the weekend?
In message <[EMAIL PROTECTED]>, walt writes: >I need some of whatever it is you're taking. Hehehehe :-) What happened was that I spent too much time on a stupid bug in the GEOM code, and decided that my life was too short for that. I've worked with FlexeLint in my earlier life and decided that even at my hourly rates, spending $1k on a good tool is good economy. After running it on various bits of my own code I decided to let it loose on LINT. And what can I say ? It finds bugs in our code! Some are stylistic, some are potential some are actual. As with all tools, one should not blindly apply the output. What makes this tool interesting compared to a normal lint, is a feature called "specific walk". As it goes, it tries to trace values and memory as best it can, and it will record which functions are called with which values from where. It will then reexamine those functions in the light of those possible paramter values and see if that looks sane. I'll agree with bruce that this is nothing people can't do themselves, but I think getting a program to do it may be faster and more reliable. Here is an example of what it finds (this is not to pick on anybody, it was just the first one I spotted now): During Specific Walk: File ../../../ufs/ufs/ufs_vnops.c line 1757: ufs_makeinode(!=0, ?, ?, ?) ../../../ufs/ufs/ufs_vnops.c 2384 Warning 429: Custodial pointer 'acl' (line 2265) has not been freed or returned This basically says that ufs_makeinode() was called from line 1757 and the first argument is know to be non-NULL, the others we know nothing about. Tracing through ufs_makeinode(), it knows that malloc allocates memory and tracks that "Custodial" pointer through the code and notices that we can return from ufs_makeinode() without having disposed of the pointer in some sensible way. As far as I can tell, that means that a FREE(acl, M_ACL) is missing in line 2384 and we have a really good and productive memory-leak if you create files/directories in directories which don't have an ACL. Now, $1k is not loose change, and a 5 concurrent user network license for the cluster would cost $3k, but maybe we should put that on the donations want list anyway ? Or is this foundation work ? Poul-Henning PS: Flexelint is distributed as "obfuscated K&R C source", which compiles on any and all system with a just moderately non-disgusting C compiler. -- 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
Re: current make depend: 'ar_args' has incomplete type help
i do it as your indication,but i get cpp core dump
- Original Message -
From: "Hanspeter Roth" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, September 28, 2002 8:57 PM
Subject: Re: current make depend: 'ar_args' has incomplete type help
> On Sep 27 at 22:56, wsk spoke:
>
> >
> > folks:
> > after succeed buildworld ,i custom mykernel and get the error messages
> > from make depend.
> [...]
> > In file included from ../../../sys/buf.h:271,
> > from ../../../i386/i386/genassym.c:46:
> > ../../../sys/proc.h:117: field `ar_args' has incomplete type
>
> I had the same. I tried to build and install the kernel first.
> Maybe, it's because you have an old compiler installed.
> Try installing world first.
>
> Alternatively you might try to patch proc.h.
>
> --- proc.h Fri Sep 27 22:09:29 2002
> +++ proc.h.orig Fri Sep 27 21:49:33 2002
> @@ -114,7 +114,7 @@
> struct pargs {
> u_int ar_ref; /* Reference count. */
> u_int ar_length; /* Length. */
> - u_char *ar_args; /* Arguments. */
> + u_char ar_args[]; /* Arguments. */
> };
>
> /*-
>
> -Hanspeter
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
N
'²æìr¸zǧvf¢Ú&j:+v¨· è® "¶§²æìr¸yúÞy» rêëz{bØ^nr¡ûazg¬±¨
Re: FireWire in 5.0?
It's in it's in /sys/dev/firewire. the test and control programs should move out of there when the authors are happy with them and go into usr.sbin or somewhere. On Sat, 28 Sep 2002, Lucky Green wrote: > I need to plan for some new servers by the end of the year. One of the > boxes will require support for FireWire IEEE 1394. While I don't expect > 5.0 to ship by November 20, I was wondering what the developers on this > list believe the odds are that the FireWire code will make it into a > stable 5.0 release by, say, January? > > I am aware that there is existing FireWire code, I am just wondering by > when you think the integration will likely be done. > > Thanks in advance, > --Lucky Green > > > 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: broken: tar -l (--one-file-system) flag
I'll look into this later. Thanks for reporting! -Maxim On Sun, Sep 29, 2002 at 02:07:57AM +, attila! wrote: > 5.0-CURRENT as of 1200 28 Sep 2002 > > tar flag > > -l (--one-file-system) > > is broken. tar crosses the mount boundary. > > NUTS --means I must go to single user or declare > specific directories for backup and hand enter the > mount points in the tree. > > -- > Sanity is the Playground for the Unimaginative > > > 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: Soundcard drivers
> > Is there still any development being done on the soundcard > drivers in > > FreeBSD? Especially regarding EMU10K2 support? > > Go to www.opensound.com/freebsd/. Their drivers should work > fine, even with more than two speakers, and they tend to > sound better than the stock FreeBSD drivers. The downside is > that after the free trial you have to pay for them, but if > you really like to listen to music, they're worth it. Doesn't support SMP. I have a multiprocessor. :/ > > I'm asking out of curiosity, because listening to radio > while being in > > FreeBSD is suboptimal :) > > Reading mail with Outlook Express's brain-damaged formatting > is suboptimal, too. :-P It's hard for me to get productive without a MP3 player or similar, that's why I'm still in Windows ;) -mg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sun Sep 29 03:14:12 PDT 2002 -- >>> Kernel build for GENERIC completed on Sun Sep 29 03:40:35 PDT 2002 -- >>> Kernel build for LINT started on Sun Sep 29 03:40:36 PDT 2002 -- ===> vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current make depend: 'ar_args' has incomplete type help
On Sep 29 at 15:48, suken woo spoke: > i do it as your indication,but i get cpp core dump Ok. I must admit I'm a current-newbie. Maybe I've done wrong assumptions. I think there are several approaches to a current system. 1. download the current installation floppies and install via ftp from scratch. I have no experience how long this would take. 2. download the developer-preview cds and install from scratch. I'm now about to download them. 3. upgrade from a 4.6.2-Release or 4-Stable. I first tried from 4.6.2-Release but I gave up. Then I tried from a 4-Stable. Then I realized that the version 3.2 of gcc might be required. (I got some compilation errors.) Then I tried buildworld/installworld. But I had several core-dumps. Even single `test -e' failed. I tried to patch several Makefiles. Finally I managed to installworld and installkernel. But then booting hung at apci.ko. Asking here on the current list I got no answers from the current-gurus. I'm about to doubt, that the latter attempt is supposed to work at all. Thus I'm trying another approach. I'm about to download the 5.0-DP1 images... (Maybe installing from floppy would take shorer...) -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current make depend: 'ar_args' has incomplete type help
On Sep 29 at 15:48, suken woo spoke: > i do it as your indication,but i get cpp core dump Is there enough free space on /tmp and /usr/obj? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current make depend: 'ar_args' has incomplete type help
On Sep 29 at 13:56, Hanspeter Roth spoke: >Asking here on the current list I got no answers from the >current-gurus. Sorry, this is not true... -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fatal trap 12
On Sep 29 at 12:25, Mitsuru IWASAKI spoke: > If you think this is caused by acpi.ko, just disable acpi.ko loading. > Please read thru loader(8) and device.hints(5). Yes, this is it. I've now disabled acpi and the boot process comes further. vga0: at port 0x3c0-0x3df iomem ... unknown: can't assign resources (port) unknown: can't assign resources (irq) ... Mounting root from ufs:/dev/ad0s3a Fatal trap 12: page fault while in kernal mode fault virtual address = ... ... current process = 1 (init) kernel: type 12 trap, code=0 Stopped at generic_bcopy+0x1a: repe movsl (%esi),%es:(%edi) db> Context switches not allowd in the debugger. db> The ad0s3x devices are the same as in 4.6: crw-r- 2 root operator 116, 0x00040002 Sep 28 19:44 ad0s3 crw-r- 2 root operator 116, 0x0004 Sep 28 19:44 ad0s3a crw-r- 2 root operator 116, 0x00040001 Sep 28 19:44 ad0s3b crw-r- 2 root operator 116, 0x00040002 Sep 28 19:44 ad0s3c ... What can I do with the Fatal trap 12? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is phk rewriting the kernel over the weekend?
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, walt writes: > >>I need some of whatever it is you're taking. > > > Hehehehe :-) > > I've worked with FlexeLint in my earlier life and decided that even > at my hourly rates, spending $1k on a good tool is good economy. A credible demonstration of increased productivity. This is good advertising for the FlexeLint people and they should gratefully donate your copy :-) I wonder if it could find the very annoying crashes in the X server. -- I'm sick of hearing about how big my Beziers are! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XFree86 crash, Bezier thing (was Re: Is phk rewriting the kernelover the weekend?)
Hey, On Sun, 2002-09-29 at 14:51, walt wrote: [snip] > > I wonder if it could find the very annoying crashes in the X server. > > -- > I'm sick of hearing about how big my Beziers are! I found this on the Xpert mailinglist: http://www.xfree86.org/pipermail/xpert/2002-June/018300.html Seems like this won't get fixed until XFree86 4.3.0, but the bug seems to be in the "Type1" font handler only. (a call to abort()) I have removed it from my XFree86 config now, and I'm hoping for no more Bezier crashes :) Mvh, Frode Nordahl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 crash, Bezier thing (was Re: Is phk rewriting the kernel over the weekend?)
I think it should be fixed in FreeBSD ports before 4.7, because it is really annoying when server crashes without any particular reason. Eric, what do you think about it? -Maxim On Sun, Sep 29, 2002 at 03:17:41PM +0200, Frode Nordahl wrote: > Hey, > > On Sun, 2002-09-29 at 14:51, walt wrote: > [snip] > > > > I wonder if it could find the very annoying crashes in the X server. > > > > -- > > I'm sick of hearing about how big my Beziers are! > > I found this on the Xpert mailinglist: > http://www.xfree86.org/pipermail/xpert/2002-June/018300.html > > Seems like this won't get fixed until XFree86 4.3.0, but the bug seems > to be in the "Type1" font handler only. (a call to abort()) > > I have removed it from my XFree86 config now, and I'm hoping for no more > Bezier crashes :) > > > Mvh, > Frode Nordahl > > > 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: broken: tar -l (--one-file-system) flag
On Sun, Sep 29, 2002 at 12:46:11PM +0300, Maxim Sobolev wrote: > I'll look into this later. Thanks for reporting! I can't reproduce it locally. Could you please provide more details about your setup? -Maxim > > -Maxim > > On Sun, Sep 29, 2002 at 02:07:57AM +, attila! wrote: > > 5.0-CURRENT as of 1200 28 Sep 2002 > > > > tar flag > > > > -l (--one-file-system) > > > > is broken. tar crosses the mount boundary. > > > > NUTS --means I must go to single user or declare > > specific directories for backup and hand enter the > > mount points in the tree. > > > > -- > > Sanity is the Playground for the Unimaginative > > > > > > 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 crash, Bezier thing (was Re: Is phk rewriting the kernelover the weekend?)
Does this bug effect -stable? It only showed up in -current recently. Isn't it a bigger chance that something on the FreeBSD side made this bug much more visible? On Sun, 29 Sep 2002, Maxim Sobolev wrote: > I think it should be fixed in FreeBSD ports before 4.7, because it > is really annoying when server crashes without any particular > reason. > > Eric, what do you think about it? > > -Maxim > > On Sun, Sep 29, 2002 at 03:17:41PM +0200, Frode Nordahl wrote: > > Hey, > > > > On Sun, 2002-09-29 at 14:51, walt wrote: > > [snip] > > > > > > I wonder if it could find the very annoying crashes in the X server. > > > > > > -- > > > I'm sick of hearing about how big my Beziers are! > > > > I found this on the Xpert mailinglist: > > http://www.xfree86.org/pipermail/xpert/2002-June/018300.html > > > > Seems like this won't get fixed until XFree86 4.3.0, but the bug seems > > to be in the "Type1" font handler only. (a call to abort()) > > > > I have removed it from my XFree86 config now, and I'm hoping for no more > > Bezier crashes :) > > > > > > Mvh, > > Frode Nordahl > > > > > > 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 > -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 crash, Bezier thing (was Re: Is phk rewriting thekernel over the weekend?)
On Sun, 2002-09-29 at 10:25, Wesley Morgan wrote: > Does this bug effect -stable? It only showed up in -current recently. > Isn't it a bigger chance that something on the FreeBSD side made this bug > much more visible? > > On Sun, 29 Sep 2002, Maxim Sobolev wrote: > > > I think it should be fixed in FreeBSD ports before 4.7, because it > > is really annoying when server crashes without any particular > > reason. > > > > Eric, what do you think about it? > > > > -Maxim >From what I had heard on the lists it was only a thing that happened when people upgraded kernels, and that it had stopped after some date of kernel. I hadn't experienced it, so I ignored it. I don't know about that link posted, I thought that was a mozilla bug that was supposed to be fixed. -- Eric Anholt <[EMAIL PROTECTED]> http://people.freebsd.org/~anholt/dri/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 crash, Bezier thing (was Re: Is phk rewriting thekernel over the weekend?)
On Sun, 2002-09-29 at 21:17, Eric Anholt wrote: > >From what I had heard on the lists it was only a thing that happened > when people upgraded kernels, and that it had stopped after some date of > kernel. I hadn't experienced it, so I ignored it. I don't know about > that link posted, I thought that was a mozilla bug that was supposed to > be fixed. It seems like the bug has been present in XFree86 all the time. But some thing has changed in CURRENT that tickles this bug. I started to experience this after I removed all ports and recompiled XFree86 with the new GCC 3.2.1. X also dies with signal 11 some times, so theres more to it than the Bezier bug. But if it is a CURRENT kernel or compiler issue, I don't understand why / how this should affect -STABLE / -RELEASE. I'll take a backup of my current X installation and do some tests and comparisons against the Aug 24 port build of XFree86. I'll have to find a sure way to reproduce the abort() and / or SIGSEGV failure first though. > -- > Eric Anholt <[EMAIL PROTECTED]> > http://people.freebsd.org/~anholt/dri/ > -- Mvh, Frode Nordahl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 crash, Bezier thing (was Re: Is phk rewriting the kernelover the weekend?)
Yes, i don't see any -stable systems bombing out. But it _always_ occurrs when typing. No matter what app... Sometimes in the linux opera, sometimes in the konq address bar. I dont think it ever happened when typing in an Xterm though. On 29 Sep 2002, Frode Nordahl wrote: > On Sun, 2002-09-29 at 21:17, Eric Anholt wrote: > > >From what I had heard on the lists it was only a thing that happened > > when people upgraded kernels, and that it had stopped after some date of > > kernel. I hadn't experienced it, so I ignored it. I don't know about > > that link posted, I thought that was a mozilla bug that was supposed to > > be fixed. > > It seems like the bug has been present in XFree86 all the time. But > some thing has changed in CURRENT that tickles this bug. > > I started to experience this after I removed all ports and recompiled > XFree86 with the new GCC 3.2.1. > > X also dies with signal 11 some times, so theres more to it than the > Bezier bug. > > But if it is a CURRENT kernel or compiler issue, I don't understand why > / how this should affect -STABLE / -RELEASE. > > I'll take a backup of my current X installation and do some tests and > comparisons against the Aug 24 port build of XFree86. > > I'll have to find a sure way to reproduce the abort() and / or SIGSEGV > failure first though. > > > -- > > Eric Anholt <[EMAIL PROTECTED]> > > http://people.freebsd.org/~anholt/dri/ > > > > -- > Mvh, > Frode Nordahl > -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: broken: tar -l (--one-file-system) flag
The "one filesystem" option means "do not traverse a mount point when enumerating the tree given by an argument." You specified .??* * which includes source dev proc and drv as well as user and usr once it started enumeraing the subdirs from source it did not trwverse any mountpoints... just as you asked... find is also doing what you asked... try: tar -l -ycv -b 200 -f /source/2929.1842.root.tbz . On Sun, 29 Sep 2002, attila! wrote: > > 1. world and kernel slice dated 28 Sep 2002 1200 GMT > > 3264 -r-xr-xr-x 1 root wheel 3327414 Sep 29 17:36 /boot/kernel/kernel > 496 -r-xr-xr-x 1 root wheel 499424 Sep 29 17:35 /usr/bin/tar > > 2. Tyan 2642 dual 1.2GHz Athlon w/ dual 160 MB/sec SCSI > > /dev/da0a 101141 72063 2098777%/ > /dev/da0e2078659 1593383 31898483%/usr > /dev/da0f2078659 1235883 67648465%/usr/local > /dev/da0g2086164 991494 9252%/user > /dev/da0h2088046 1 1921002 0%/drv/da0h > /dev/da1a 101141 60779 3227165%/drv/da1a > /dev/da1e2078659 74729 1837638 4%/drv/da1e > /dev/da1f2078659 169833 1742534 9%/drv/da1f > /dev/da1g2086164 1702723 21654889%/source > /dev/da1h2088046 1790550 13045393%/usr/ports > > 3. operation: > > cd / > tar -l -ycv -b 200 -f /source/2929.1842.root.tbz .??* * > or > tar --one-file-system -ycv -b 200 -f /source/2929.1842.root.tbz .??* * > > copied /dev /proc /source (2G partion mount point) which, > of course, makes it recursive --ouch! > > also > > cd /usr > tar --one-file-system -ycv -b 200 -f /source/2929.1842.usr.tbz .??* * > > transfered local, ports, and pkg which are all mounted > filesystems. > > So, before committing this to mail, I thought would try > the work around: > > find -x .??* * \! -type d -print >.tfile > tar --files-from .tfile -yc -b 200 -f /source/2929.1842.usr.tbz .??* * > > but, alas, 'find' has the same problem ... it crosses the > mount point to a different device. Makes me suspect there > is common code for the find in 'tar' with 'find'. > > If you need more info, or wish me to test it, please let > me know. If you're on the usual +3, it's still "today". > > best, > > Dr Daniel Flickinger > > > Sent: Sun, 29 Sep 2002 18:48:10 +0300 by Maxim > > + On Sun, Sep 29, 2002 at 12:46:11PM +0300, Maxim Sobolev wrote: > + > I'll look into this later. Thanks for reporting! > + > + I can't reproduce it locally. Could you please provide > + more details about your setup? > + > + -Maxim > > > 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
[PATCH] Workaround for bogus INT 12H BIOS service implementation
Hi, I've found that some recent machine's BIOS doesn't support INT 12H
(Get base memory size) BIOS service, instead they seems to support
SMAP (system memory map: INT 15H function e820H) for this purpose.
I already checked that there is no problems on Linux or Windows or
others, but FreeBSD won't boot at all.
I'll report bogus INT 12H BIOS service implementation to BIOS vendors
if I get chances. On the other hand, I think we need to have a
workaround in a safety way for this problem for newer machines.
Here is the patches. I'll commit them in a few days if no objection.
Thanks
Index: sys/boot/i386/boot2/boot2.c
===
RCS file: /home/ncvs/src/sys/boot/i386/boot2/boot2.c,v
retrieving revision 1.44
diff -u -r1.44 boot2.c
--- sys/boot/i386/boot2/boot2.c 1 Sep 2002 21:29:10 - 1.44
+++ sys/boot/i386/boot2/boot2.c 29 Sep 2002 21:16:19 -
@@ -231,7 +231,7 @@
dsk.slice = *(uint8_t *)PTOV(ARGS + 1) + 1;
bootinfo.bi_version = BOOTINFO_VERSION;
bootinfo.bi_size = sizeof(bootinfo);
-bootinfo.bi_basemem = memsize(MEM_BASE);
+bootinfo.bi_basemem = 0; /* XXX will be filled at loader or kernel */
bootinfo.bi_extmem = memsize(MEM_EXT);
bootinfo.bi_memsizes_valid++;
for (i = 0; i < N_BIOS_GEOM; i++)
Index: sys/boot/i386/loader/main.c
===
RCS file: /home/ncvs/src/sys/boot/i386/loader/main.c,v
retrieving revision 1.25
diff -u -r1.25 main.c
--- sys/boot/i386/loader/main.c 5 Nov 2001 19:03:01 - 1.25
+++ sys/boot/i386/loader/main.c 29 Sep 2002 21:01:51 -
@@ -129,6 +129,10 @@
if (devsw[i]->dv_init != NULL)
(devsw[i]->dv_init)();
printf("BIOS %dkB/%dkB available memory\n", bios_basemem / 1024, bios_extmem /
1024);
+if (initial_bootinfo != NULL) {
+ initial_bootinfo->bi_basemem = bios_basemem / 1024;
+ initial_bootinfo->bi_extmem = bios_extmem / 1024;
+}
/* detect ACPI for future reference */
biosacpi_detect();
Index: sys/i386/i386/machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.532
diff -u -r1.532 machdep.c
--- sys/i386/i386/machdep.c 7 Sep 2002 19:12:42 - 1.532
+++ sys/i386/i386/machdep.c 29 Sep 2002 21:15:26 -
@@ -1269,8 +1269,12 @@
/*
* Perform "base memory" related probes & setup
*/
- vm86_intcall(0x12, &vmf);
- basemem = vmf.vmf_ax;
+ if (bootinfo.bi_basemem != 0) {
+ basemem = bootinfo.bi_basemem;
+ } else {
+ vm86_intcall(0x12, &vmf);
+ basemem = vmf.vmf_ax;
+ }
if (basemem > 640) {
printf("Preposterous BIOS basemem of %uK, truncating to 640K\n",
basemem);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic: pipe buffer gone
I just got this on the bento cluster:
panic: pipe buffer gone
Backtrace:
[...]
#11 0xc0266170 in pipe_write (fp=0xc5188f00, uio=0xd917dc7c,
---Type to continue, or q to quit---
active_cred=0xc67cdc00, flags=0, td=0xc5d84c00)
at /local0/scratch/sys/kern/sys_pipe.c:1068
#12 0xc0262675 in dofilewrite (td=0xc5d84c00, fp=0xc5188f00, fd=0,
buf=0x80ce004, nbyte=0, offset=0, flags=0) at file.h:213
#13 0xc02624b9 in write (td=0xc5d84c00, uap=0xd917dd10)
at /local0/scratch/sys/kern/sys_generic.c:332
It's a bit mysterious because sys_pipe.c:1068 is panic("pipe buffer
overflowed")..but I have the core if anyone would like me to do some
debugging monkeywork.
Kris
msg43591/pgp0.pgp
Description: PGP signature
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sun Sep 29 15:17:37 PDT 2002 -- >>> Kernel build for GENERIC completed on Sun Sep 29 15:48:03 PDT 2002 -- >>> Kernel build for LINT started on Sun Sep 29 15:48:04 PDT 2002 -- ===> vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: broken: tar -l (--one-file-system) flag
On Sun, 29 Sep 2002, attila! wrote: > Yes, you are correct: the use of '.' rather than '*' > stops the recursion into separately mounted files > systems; thanx for the clarification! > > However, the manual syntax for tar is anything but clear > --typical of the last 25+ years of *nix manuals' arcane > definitions. Each argument is a separate start point from which a descent is made. (in the terms given by the 'find' man page). The -l option is applied separatly to each argument.. That's what I would expect viszlat! > > The definition for find may be technically correct, but > the statement still leaves the opening to interpret the > statement as the 'starting file'; the fact the starting > file is a mount point is irrelevant. To me, "starting > file" is the file system "level" at the point of start > and anything mounted to that level would not be > included --but, in this case, I am wrong. > > Both manual statements should be cleaned up and stated > in explicit terms. I've argued this point for 25 years > on many other fronts so I don't suppose it's going to > change... > > out! > > tar: > > -l > --one-file-system Stay in local filesystem when creating > an archive (do not cross mount points). > > find: > > -x Prevent find from descending into directories that have > a device number different than that of the file from which > the descent began. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 crash, Bezier thing
Wesley Morgan wrote: > Yes, i don't see any -stable systems bombing out. But it _always_ occurrs > when typing. No matter what app... I've seen in most often when starting X/gnome. Almost always happens when gnome-panel is just appearing on screen. No typing going on yet, naturally. If gnome-panel is using a TypeI font that might account for it. Oddly, though, usually if I just type startx a second time it all starts OK. Later it may crash with mozilla also, of course. I took TypeI out of my fonts-path and so far no more crashes, but it's been less than 24 hours, so still a bit early to crow. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sys/sys/proc.h 1.250 breaks devel/libgtop2 port
On Fri, 27 Sep 2002, Lars Eggert wrote:
> Joe Marcus Clarke wrote:
> > On Fri, 2002-09-27 at 21:54, Lars Eggert wrote:
> >
> >>Juli Mallett wrote:
> >>
> >>>* De: Lars Eggert <[EMAIL PROTECTED]> [ Data: 2002-09-27 ]
> >>> [ Subjecte: sys/sys/proc.h 1.250 breaks devel/libgtop2 port ]
> >>>
> commenting out p_kse in sys/sys/proc.h rev 1.250 broke the
> devel/libgtop2 port (which still uses that field in
> sysdeps/freebsd/proctime.c).
> >>>
> >>>FWIW this bit me too, and I just initialised the values to zero and wrote
> >>>myself a note to note it to gnome@, and then lost the note.
> >>
> >>That's the stopgap I settled on, too :-)
> >>
> >>Now the build hangs because of sys/vnode.h rev 1.208, which removed
> >>VT_UFS...
> >
> >
> > Yep, I have a fix for this, too. You can change the == to a call to
> > strcmp, and basically do a :
> >
> > strcmp("ufs", variable) == 0;
> >
> > Like I said, I'm on vacation, or I'd have the actual patch to give to
> > you.
>
> No problem, that workaround is easy enough to apply. Thanks!
>
> Lars
> --
> Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
It's not a workaround, it's an outright fix. vnode->v_tag is now const
char * and that's the proper way to check for a fs type FROM USER MODE
(just making sure people note that :)
To get an idea how this works, grep getnewvnode in the sys/fs/* sources.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Promise PDC20277 ATA RAID controller support
On Sat, 28 Sep 2002, Mitsuru IWASAKI wrote: > Hi, I got a new machine with Promise PDC20277 ATA RAID controller. > This controller isn't supported yet, so I wrote simple patches for it. > It's working now, so far so good :) > Soren, Could you review the patches and commit them if acceptable? I submitted the same change to Soren a month ago, when I got an Intel SE7500WV2 motherboard. Still no commit. Soren, do you need one of these for testing? > +case 0x7275105a: /* Promise PDC20277 controllers */ Here's the ID. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Workaround for bogus INT 12H BIOS service implementation
On Mon, 30 Sep 2002, Mitsuru IWASAKI wrote:
> Hi, I've found that some recent machine's BIOS doesn't support INT 12H
> (Get base memory size) BIOS service, instead they seems to support
> SMAP (system memory map: INT 15H function e820H) for this purpose.
> I already checked that there is no problems on Linux or Windows or
> others, but FreeBSD won't boot at all.
>
> I'll report bogus INT 12H BIOS service implementation to BIOS vendors
> if I get chances. On the other hand, I think we need to have a
> workaround in a safety way for this problem for newer machines.
>
> Here is the patches. I'll commit them in a few days if no objection.
> ...
> Index: sys/i386/i386/machdep.c
> ===
> RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
> retrieving revision 1.532
> diff -u -r1.532 machdep.c
> --- sys/i386/i386/machdep.c 7 Sep 2002 19:12:42 - 1.532
> +++ sys/i386/i386/machdep.c 29 Sep 2002 21:15:26 -
> @@ -1269,8 +1269,12 @@
> /*
>* Perform "base memory" related probes & setup
>*/
> - vm86_intcall(0x12, &vmf);
> - basemem = vmf.vmf_ax;
> + if (bootinfo.bi_basemem != 0) {
> + basemem = bootinfo.bi_basemem;
> + } else {
> + vm86_intcall(0x12, &vmf);
> + basemem = vmf.vmf_ax;
> + }
> if (basemem > 640) {
> printf("Preposterous BIOS basemem of %uK, truncating to 640K\n",
> basemem);
The kernel hasn't used bootinfo.bi_basemem for a long time and shouldn't
start using it again now. It already uses the 0x15/0xe820 call for
everything except basemem (except when the this call fails, it falls
back to 0x15/0xe801). Maybe the bug has something to do with the
kernel using the 0x12 call without checking whether the call succeeded.
When both the 0x15/0xe820 and the 0x15/0xe801 calls fail, the kernel
falls back to an 0x15/0x88 call for determining extmem ... except this
is ifdefed out and replaced by looking at the rtc values. Maybe the
unreliability of the 0x15/0x88 call has something to do with not
checking if the call succeeded.
The patch makes no difference for booting directly from boot2 ... except
memsize() in boot2 also fails to check for errors, so it returns garbage
values.
I think the basemem == 0 case should just work, so the systems with a
broken INT 0x12 should at worst lose 640K of memory, no matter whether
basemem is set to 0 because INT 0x12 fails or because it actually
returns 0.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: current make depend: 'ar_args' has incomplete type help
Hanspeter Roth wrote: > On Sep 29 at 15:48, suken woo spoke: > > > >>i do it as your indication,but i get cpp core dump >> >> > >Ok. I must admit I'm a current-newbie. >Maybe I've done wrong assumptions. >I think there are several approaches to a current system. > >1. download the current installation floppies and install via ftp > from scratch. I have no experience how long this would take. > >2. download the developer-preview cds and install from scratch. I'm > now about to download them. > >3. upgrade from a 4.6.2-Release or 4-Stable. I first tried from > 4.6.2-Release but I gave up. Then I tried from a 4-Stable. Then I > realized that the version 3.2 of gcc might be required. (I got > some compilation errors.) Then I tried buildworld/installworld. > But I had several core-dumps. Even single `test -e' failed. > I tried to patch several Makefiles. Finally I managed to > installworld and installkernel. But then booting hung at apci.ko. > Asking here on the current list I got no answers from the > current-gurus. > >I'm about to doubt, that the latter attempt is supposed to work at >all. >Thus I'm trying another approach. I'm about to download the 5.0-DP1 >images... >(Maybe installing from floppy would take shorer...) > >-Hanspeter > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > > > > thanks , i just wanna upgrade from FBSD4.x or 4.x-stable.and i would try it again later. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver broken?
Hello, Niels. On Sat, Sep 28, 2002 at 07:35:13PM +0200, Niels Chr. Bank-Pedersen wrote: > On Sat, Sep 28, 2002 at 05:55:02PM +0100, Mark Murray wrote: > > Hi > > > > I can't boot a kernel after my 22nd Sept one. The ATA disk controller > > does not probe at all, and no bootable disk is found by the kernel. > > > > The machine is a Toshiba Libretto 110CT. > > I'm seeing the same (sortof) on my Dual PIII machine - ATA as well as > ISA (PCI-ISA bridge), SCSI (sym) and NIC (fxp) has dissapeared recently. > I was suspecting the legacy(4) commits on the 23rd to be causing this. > Boot messages (before/after) attached. > Are you sure you are loading acpi.ko module synced with kernel? [...] -- Gennady To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Promise PDC20277 ATA RAID controller support
It seems Doug White wrote: > On Sat, 28 Sep 2002, Mitsuru IWASAKI wrote: > > > Hi, I got a new machine with Promise PDC20277 ATA RAID controller. > > This controller isn't supported yet, so I wrote simple patches for it. > > It's working now, so far so good :) > > Soren, Could you review the patches and commit them if acceptable? > > I submitted the same change to Soren a month ago, when I got an Intel > SE7500WV2 motherboard. Still no commit. I've just gotten the docs from promise, and commit is now pending.. > Soren, do you need one of these for testing? That would always be nice :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
amusing KSE ktrace.
It occured to me to day to look at several KSE threads running under ktrace.. Talk about confusing.. The key to understanding it is that the lines RET fork 0 are actually the upcalls when a thread blocks, and they will report to the userland scheduler all the RETs that occured since the last RET fork 0 In any case it sure is difficult to follow :-) (6 threads each printing one char and then sleeping) 17595 ksetest RET write 1 17595 ksetest CALL nanosleep(0x84b7fcc,0x84b7fc4) 17595 ksetest CALL nanosleep(0x84a6fcc,0x84a6fc4) 17595 ksetest CALL write(0x1,0xbfbffc17,0x1) 17595 ksetest GIO fd 1 wrote 1 byte "K" 17595 ksetest RET write 1 17595 ksetest CALL nanosleep(0x8275fcc,0x8275fc4) 17595 ksetest RET fork 0 17595 ksetest CALL nanosleep(0x8264fcc,0x8264fc4) 17595 ksetest RET fork 0 17595 ksetest CALL kse_yield 17595 ksetest CALL nanosleep(0xbfbffc10,0xbfbffc08) 17595 ksetest RET fork 0 17595 ksetest CALL kse_yield 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest CALL write(0x1,0x84b7fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte "." 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x84a6fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte "*" 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x8264fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte "+" 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x8275fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte "-" 17595 ksetest RET write 1 17595 ksetest CALL nanosleep(0x84b7fcc,0x84b7fc4) 17595 ksetest CALL nanosleep(0x84a6fcc,0x84a6fc4) 17595 ksetest CALL write(0x1,0xbfbffc17,0x1) 17595 ksetest GIO fd 1 wrote 1 byte "L" 17595 ksetest RET write 1 17595 ksetest CALL nanosleep(0x8264fcc,0x8264fc4) 17595 ksetest RET fork 0 17595 ksetest CALL nanosleep(0x8275fcc,0x8275fc4) 17595 ksetest RET fork 0 17595 ksetest CALL kse_yield 17595 ksetest CALL nanosleep(0xbfbffc10,0xbfbffc08) 17595 ksetest RET fork 0 17595 ksetest CALL kse_yield 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest CALL write(0x1,0x84b7fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte "." 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x84a6fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte "*" 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x8275fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte "-" 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x8264fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte "+" 17595 ksetest RET write 1 17595 ksetest CALL nanosleep(0x84b7fcc,0x84b7fc4) 17595 ksetest CALL nanosleep(0x84a6fcc,0x84a6fc4) 17595 ksetest CALL write(0x1,0xbfbffc17,0x1) 17595 ksetest GIO fd 1 wrote 1 byte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PATCH: various memory leaks.
I went through the FlexeLint output of the LINT kernel on i386 and
tried to examine all warnings about memoryleaks in central or
semi-central code.
I this patch I belive addresses the ones I think I could confirm,
in the following files:
cam/scsi/scsi_cd.c
cam/scsi/scsi_da.c
dev/ata/ata-all.c
fs/pseudofs/pseudofs_vncache.c
fs/umapfs/umap_vfsops.c
kern/kern_ktrace.c
kern/kern_linker.c
ufs/ufs/ufs_vnops.c
I would appreciate if the respective owners, authors, maintainers
etc would review and commit their own bits from this patch.
Thanks in advance!
Poul-Henning
Index: cam/scsi/scsi_cd.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_cd.c,v
retrieving revision 1.61
diff -u -r1.61 scsi_cd.c
--- cam/scsi/scsi_cd.c 28 Sep 2002 17:14:05 - 1.61
+++ cam/scsi/scsi_cd.c 30 Sep 2002 06:11:54 -
@@ -1463,6 +1463,7 @@
start_ccb->ccb_h.ccb_bp = NULL;
start_ccb->ccb_h.ccb_state = CD_CCB_PROBE;
xpt_action(start_ccb);
+ /* XXX missing free(rcap, M_TEMP) ??? */
break;
}
}
Index: cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.108
diff -u -r1.108 scsi_da.c
--- cam/scsi/scsi_da.c 20 Sep 2002 19:35:52 - 1.108
+++ cam/scsi/scsi_da.c 30 Sep 2002 06:13:35 -
@@ -1249,6 +1249,7 @@
start_ccb->ccb_h.ccb_bp = NULL;
start_ccb->ccb_h.ccb_state = DA_CCB_PROBE;
xpt_action(start_ccb);
+ /* XXX missing free(rcap, M_TEMP) ?? */
break;
}
}
Index: dev/ata/ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.154
diff -u -r1.154 ata-all.c
--- dev/ata/ata-all.c 12 Sep 2002 14:32:33 - 1.154
+++ dev/ata/ata-all.c 30 Sep 2002 06:19:11 -
@@ -454,8 +454,10 @@
if (iocmd->u.atapi.flags & ATAPI_CMD_WRITE) {
error = copyin(iocmd->u.atapi.data, buf, iocmd->u.atapi.count);
- if (error)
+ if (error) {
+ free(buf, M_ATA);
return error;
+ }
}
error = atapi_queue_cmd(atadev, iocmd->u.atapi.ccb,
buf, iocmd->u.atapi.count,
Index: fs/pseudofs/pseudofs_vncache.c
===
RCS file: /home/ncvs/src/sys/fs/pseudofs/pseudofs_vncache.c,v
retrieving revision 1.17
diff -u -r1.17 pseudofs_vncache.c
--- fs/pseudofs/pseudofs_vncache.c 14 Sep 2002 09:02:24 - 1.17
+++ fs/pseudofs/pseudofs_vncache.c 30 Sep 2002 06:23:59 -
@@ -136,8 +136,10 @@
if (++pfs_vncache_entries > pfs_vncache_maxentries)
pfs_vncache_maxentries = pfs_vncache_entries;
error = getnewvnode("pseudofs", mp, pfs_vnodeop_p, vpp);
- if (error)
+ if (error) {
+ FREE(pvd, M_PFSVNCACHE);
return (error);
+ }
pvd->pvd_pn = pn;
pvd->pvd_pid = pid;
(*vpp)->v_data = pvd;
Index: fs/umapfs/umap_vfsops.c
===
RCS file: /home/ncvs/src/sys/fs/umapfs/umap_vfsops.c,v
retrieving revision 1.46
diff -u -r1.46 umap_vfsops.c
--- fs/umapfs/umap_vfsops.c 4 Aug 2002 10:29:31 - 1.46
+++ fs/umapfs/umap_vfsops.c 30 Sep 2002 06:26:18 -
@@ -170,6 +170,8 @@
if (args.nentries > MAPFILEENTRIES || args.gnentries >
GMAPFILEENTRIES) {
vput(lowerrootvp);
+ free(amp, M_UMAPFSMNT);
+ /* XXX missing error = EINVAL ? */
return (error);
}
@@ -177,8 +179,10 @@
amp->info_gnentries = args.gnentries;
error = copyin(args.mapdata, (caddr_t)amp->info_mapdata,
2*sizeof(u_long)*args.nentries);
- if (error)
+ if (error) {
+ free(amp, M_UMAPFSMNT);
return (error);
+ }
#ifdef DEBUG
printf("umap_mount:nentries %d\n",args.nentries);
@@ -189,8 +193,10 @@
error = copyin(args.gmapdata, (caddr_t)amp->info_gmapdata,
2*sizeof(u_long)*args.gnentries);
- if (error)
+ if (error) {
+ free(amp, M_UMAPFSMNT);
return (error);
+ }
#ifdef DEBUG
printf("umap_mount:gnentries %d\n",args.gnentries);
Index: kern/kern_ktrace.c
===
RCS file: /home/ncvs/src/sys/kern/kern_ktrace.c,v
retrieving revision 1.77
diff -u -r1.77 kern_ktrace.c
--- kern/kern_ktrace.c 11 Sep 2002 21:00:56 - 1.77
+++ kern/kern_ktrace.c 30 Sep 2002 06:35:00 -
@@ -325,8 +325,11 @@
