do we still need ufs/ffs/ffs_softdep_stub.c ?
Hi, just got the following panic with today's -current sources and an oldish config file (one not having options SOFTUPDATES): panic: softdep_slowdown called Debugger(panic) Stopped at Debugger+0x45: xchgl %ebx,0xc05fa740 db trace Debugger(c026141c) at Debugger+0x45 panic(c026ecc1,c66e1b94,c01ff565,c1cda000,0) at panic+0x7c softdep_slowdown(c1cda000,0,0,,2) at softdep_slowdown+0xd ffs_truncate(c1cda000,0,0,c00,0) at ffs_truncate+0x81 ufs_inactive(c66e1bfc,c66e1c24,c01b2c10,c66e1bfc,c0280780) at ufs_inactive+0x91 ufs_vnoperate(c66e1bfc) at ufs_vnoperate+0x13 vput(c1cda000,c1cc636c,c66e1c90,ffdf,c1c92000) at vput+0xd0 unlink(c081db40,c66e1d14,1,3,246) at unlink+0x18a syscall(2f,2f,2f,8254000,bfbffdc8) at syscall+0x231 Xint0x80_syscall() at Xint0x80_syscall+0x1d and in trying to track down the problem i noticed the following: grep ffs_softdep conf/* conf/files:ufs/ffs/ffs_softdep.coptional softupdates ffs conf/files:ufs/ffs/ffs_softdep_stub.c optional ffs so the question is, do we still need ffs_softdep_stub.c ? In any case, getting an explicit panic does not really sound right... cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: do we still need ufs/ffs/ffs_softdep_stub.c ?
In message [EMAIL PROTECTED], Luigi Rizzo writes:
Hi,
just got the following panic with today's -current sources and
an oldish config file (one not having options SOFTUPDATES):
panic(c026ecc1,c66e1b94,c01ff565,c1cda000,0) at panic+0x7c
softdep_slowdown(c1cda000,0,0,,2) at softdep_slowdown+0xd
ffs_truncate(c1cda000,0,0,c00,0) at ffs_truncate+0x81
so the question is, do we still need ffs_softdep_stub.c ? In any
case, getting an explicit panic does not really sound right...
The bug is in ffs_truncate() - it should not be calling softdep
functions on non-softdep filesystems. The panic is there to catch
exactly this kind of bug.
I think the following patch should fix it.
Ian
Index: ffs_inode.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/ufs/ffs/ffs_inode.c,v
retrieving revision 1.81
diff -u -r1.81 ffs_inode.c
--- ffs_inode.c 19 Jul 2002 07:29:38 - 1.81
+++ ffs_inode.c 3 Aug 2002 11:05:43 -
@@ -173,7 +173,7 @@
* soft updates below.
*/
needextclean = 0;
- softdepslowdown = softdep_slowdown(ovp);
+ softdepslowdown = DOINGSOFTDEP(ovp) softdep_slowdown(ovp);
extblocks = 0;
datablocks = DIP(oip, i_blocks);
if (fs-fs_magic == FS_UFS2_MAGIC oip-i_din2-di_extsize 0) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: make: don't know how to make bsd.README. Stop
On Sat, 2002-08-03 at 00:45, karl agee wrote: ok...its crashing here, now.I've deleted the /usr/src/gnu directory and re-cvsuped it, but it still_crashes: Re-cvsup and try it again. I got that Thursday, but Friday it worked. Well, the system locked at loading the fxp driver, but it compiled and installed. -- Remember: the only difference between being the champ and the chump is u. signature.asc Description: This is a digitally signed message part
Re: Comments on Release Building for -current
Andrew Kolchoogin [EMAIL PROTECTED] writes: David, On Fri, Aug 02, 2002 at 12:39:55AM -0700, David O'Brien wrote: The rest of the GCC using world can use -O2 on their code. We are the only ones that have so much trouble with it. It is probably due to our bugs, not GCC's. sorry, but some time ago I read here that gcc -O2 breaks our printf() in libc. I haven't find any assembler code in /usr/src/lib/libc/stdio/vfprintf.c, as such, if some C compiler can't handle VALID and STANDARDS-COMPLIANT C code, this compiler is broken. Isn't it? Indeed, all of FreeBSD users could help to catch such a bug in gcc optimizer code. :) If someone could find the small segment of code where the optimizer screws up, and write a small program to demonstrate the problem, we would have a good chance of it getting fixed. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About 5.0 and Nvidia drivers
On 2002-08-03 12:14 +, Alp ATICI wrote: [snip] And what's the latest about the Nvidia drivers? It's mentioned that Nvidia has plans to produce the drivers for FreeBSD. I'd be happy to know what's going on in that issue too. We know about as much as you do. Waiting for NVIDIA, once again. I'll fire off a mail to some of our contacts and ask, but I'm pretty sure it'll be more of the same we usually get. -- Munish Chopra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About 5.0 and Nvidia drivers
On Sat, 3 Aug 2002, Alp ATICI wrote: And what's the latest about the Nvidia drivers? It's mentioned that Nvidia has plans to produce the drivers for FreeBSD. I'd be happy to know what's going on in that issue too. Any day now. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rc.d/bootparams patch
Hi Gordon,
This patch seems to make bootparamd work on my machine.
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
--- /usr/src/etc/rc.d/bootparamsFri Jun 14 00:14:36 2002
+++ bootparams Sat Aug 3 10:24:44 2002
@@ -11,8 +11,8 @@
. /etc/rc.subr
name=bootparamd
-rcvar=$name
-command=/usr/sbin/rpc.${name}
+rcvar=`set_rcvar`
+command=/usr/sbin/${name}
required_files=/etc/bootparams
load_rc_config $name
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
[no subject]
FreeBSD,BeOS,Linux|Cisco Network Academy BSD User = 050834 | Linux User = 280168 The Power to the Serve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problem booting current on VAIO R505ES
I got around the lack of IRQ on pcic1 by means of a trick involving hw sets in loader.conf (thanks to the mobile contributors); now it won't mount root. I know what the problem is but not why; the loader brings the kernel in fine, and probes work fine; I'd presume if the partition were too high this would be where the failure would lie. However, the layout is (LBA): The data for partition 1 is: sysid 7,(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 63, size 33543657 (16378 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 33543720, size 8177085 (3992 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 41720805, size 8177085 (3992 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 49897890, size 28242270 (13790 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 --- %disklabel -r ad0s2 # /dev/ad0s2c: type: ESDI disk: ad0s2 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 509 sectors/unit: 8177085 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 104857604.2BSD 2048 1638489 # (Cyl.0 - 65*) b: 1048576 2097152 swap# (Cyl. 130*- 195*) c: 81770850unused0 0 # (Cyl.0 - 508) e: 1048576 10485764.2BSD 2048 1638489 # (Cyl. 65*- 130*) f: 5031357 31457284.2BSD 2048 1638489 # (Cyl. 195*- 508*) %disklabel -r ad0s3 # /dev/ad0s3c: type: ESDI disk: ad0s3 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 509 sectors/unit: 8177085 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 104857604.2BSD 2048 1638489 # (Cyl.0 - 65*) b: 1048576 2097152 swap# (Cyl. 130*- 195*) c: 81770850unused0 0 # (Cyl.0 - 508) e: 1048576 10485764.2BSD 2048 1638489 # (Cyl. 65*- 130*) f: 5031357 31457284.2BSD 2048 1638489 # (Cyl. 195*- 508*) - Note that slice 2 begins JUST below a power of 2 (33554432), and boots fine. Slice 2 has stable on it, slice 3 current, slice 4 == /d and contains home dirs etc. Yes I know, I could make slice 1 smaller. However, I don't know an NTFS version of partition magic. Sony's reinstaller does allow me to make the partition smaller and I suspect I'll have to do this, with a complete reinstall of everything. However, especially on a new system where I might have to deal with the warranty, I like to leave the windoze system alone :-( Now, why is there a mount-root problem at 16mb where the bios limit should end up at 8mb. The bad line is at 2**25? Note that stable (once it is up) gets to all the slices just fine (that is how I've been installing, cross-compiling from -stable). -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About 5.0 and Nvidia drivers
Le Saturday 03 August 2002 22:09, Matthew N. Dodd a écrit : On Sat, 3 Aug 2002, Alp ATICI wrote: And what's the latest about the Nvidia drivers? It's mentioned that Nvidia has plans to produce the drivers for FreeBSD. I'd be happy to know what's going on in that issue too. Any day now. wow ! what will this driver know to do ? (any URL to begin RTFMing ?) TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About 5.0 and Nvidia drivers
On Sat, 3 Aug 2002, Thierry Herbelot wrote: Le Saturday 03 August 2002 22:09, Matthew N. Dodd a écrit : On Sat, 3 Aug 2002, Alp ATICI wrote: And what's the latest about the Nvidia drivers? It's mentioned that Nvidia has plans to produce the drivers for FreeBSD. I'd be happy to know what's going on in that issue too. Any day now. wow ! what will this driver know to do ? (any URL to begin RTFMing ?) Sorry, this has been the status for months now. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: free: address 0xc1802270(0xc1802000) has not been allocated.
Hello.
I've encountered this panic with kernel from source as of 2002.07.30.00.00.00 .
I've seen this panic message in Julian's message in July
[EMAIL PROTECTED],
but he said in another mail that it was a pilot error. I've searched the list
archive and PR, but found none similar to this.
The backtrace is attached. I was about to start racoon under supervise,
but I doubt it's reproducible only by starting racoon.
Regards.
Script started on Sun Aug 4 05:55:36 2002
$ gdb -k /usr/obj/kernel/kernel.debug vmcore.5
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bdwrite: buffer is not busy
panic messages:
---
panic: free: address 0xc1802270(0xc1802000) has not been allocated.
syncing disks... panic: bdwrite: buffer is not busy
Uptime: 11h31m12s
Dumping 63 MB
ata0: resetting devices ..
ata0: mask=03 ostat0=50 ostat2=00
ad0: ATAPI 00 00
ata0-slave: ATAPI 00 00
ata0: mask=03 stat0=50 stat1=00
ad0: ATA 01 a5
ata0: devices=01
ad0: success setting PIO4 on generic chip
done
16 32 48
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc0195038 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc019526b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc01d2f9d in bdwrite (bp=0x104) at /usr/src/sys/kern/vfs_bio.c:947
#4 0xc026c7c8 in ffs_update (vp=0xc137c948, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:125
#5 0xc02814e2 in ffs_fsync (ap=0xc7b93a48)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:272
#6 0xc027ea98 in ffs_sync (mp=0xc1288800, waitfor=2, cred=0xc09ecd80,
td=0xc0335580) at vnode_if.h:463
#7 0xc01e4d28 in sync (td=0xc0335580, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:127
#8 0xc0194c2c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254
#9 0xc019526b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#10 0xc018898e in free (addr=0xc1802270, type=0xc0336c80)
at /usr/src/sys/kern/kern_malloc.c:226
#11 0xc018e139 in pargs_free (pa=0x0) at /usr/src/sys/kern/kern_proc.c:1125
#12 0xc018e286 in pargs_drop (pa=0xc1802270)
at /usr/src/sys/kern/kern_proc.c:1148
#13 0xc018e4a7 in sysctl_kern_proc_args (oidp=0xc033a000, arg1=0xc7b93ca8,
arg2=1, req=0xc7b93bfc) at /usr/src/sys/kern/kern_proc.c:1191
#14 0xc019e966 in sysctl_root (oidp=0x0, arg1=0xc1802270, arg2=-944161796,
req=0xc1802270) at /usr/src/sys/kern/kern_sysctl.c:1143
#15 0xc019ec3d in userland_sysctl (td=0x0, name=0xc7b93c9c, namelen=4,
---Type return to continue, or q return to quit---
old=0xc1802270, oldlenp=0xc1802270, inkernel=0, new=0xc7b93bfc, newlen=0,
retval=0xc7b93c94) at /usr/src/sys/kern/kern_sysctl.c:1241
#16 0xc019ea6d in __sysctl (td=0x0, uap=0xc7b93d10)
at /usr/src/sys/kern/kern_sysctl.c:1180
#17 0xc02d536d in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134541312, tf_esi = -1077939844,
tf_ebp = -1077939896, tf_isp = -944161420, tf_ebx = 672297404, tf_edx = -1077939840,
tf_ecx = 4, tf_eax = 202, tf_trapno = 22, tf_err = 2, tf_eip = 671861531, tf_cs = 31,
tf_eflags = 663, tf_esp = -1077939940, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#18 0xc02c62cd in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) frame 12
#12 0xc018e286 in pargs_drop (pa=0xc1802270)
at /usr/src/sys/kern/kern_proc.c:1148
1148pargs_free(pa);
(kgdb) print pa
$1 = (struct pargs *) 0xc1802270
(kgdb) down
#11 0xc018e139 in pargs_free (pa=0x0) at /usr/src/sys/kern/kern_proc.c:1125
1125FREE(pa, M_PARGS);
(kgdb) list
1120
1121void
1122pargs_free(struct pargs *pa)
1123{
1124
1125FREE(pa, M_PARGS);
1126}
1127
1128void
1129pargs_hold(struct pargs *pa)
(kgdb) up
#12 0xc018e286 in pargs_drop (pa=0xc1802270)
at /usr/src/sys/kern/kern_proc.c:1148
1148pargs_free(pa);
(kgdb) print *pa
$2 = {ar_ref = 0, ar_length = 3246400112, ar_args = 0xc1802278 }
Re: Problem booting current on VAIO R505ES
Pete Carah wrote: I got around the lack of IRQ on pcic1 by means of a trick involving hw sets in loader.conf (thanks to the mobile contributors); now it won't mount root. I know what the problem is but not why; the loader brings the kernel in fine, and probes work fine; I'd presume if the partition were too high this would be where the failure would lie. However, the layout is (LBA): Doesn't matter. The problem is in the Sony BIOS. I have a PCG-XG29, and a friend has a PCG-XG28, both of which are a precursor to the 505 you have. Specifically, it's an INT 13 implementation limitation. Yes I know, I could make slice 1 smaller. However, I don't know an NTFS version of partition magic. Sony's reinstaller does allow me to make the partition smaller and I suspect I'll have to do this, with a complete reinstall of everything. However, especially on a new system where I might have to deal with the warranty, I like to leave the windoze system alone :-( Partition Magic 7.x supports resizing NTFS partitions. Be aware that you will need to create a minimal (~33M -- God, when did that become minimal?!?) Windows FAT32 partititon, pretending that you are going to install a bootable OS on it, so that the Partition Magic Boot Easy program can locate its files, since the first stage boot loader is not capable of reading non FAT based parititions for loading copies of bootstraps or icons. Search the FreeBSD archives; I wrote up an extensive description of how you have to configure this. Now, why is there a mount-root problem at 16mb where the bios limit should end up at 8mb. The bad line is at 2**25? You mean GB. And -- again -- it's because of the Sony BIOS. Note that stable (once it is up) gets to all the slices just fine (that is how I've been installing, cross-compiling from -stable). Yes; that's how it works. Protected mode drivers don't use the BIOS to access the disk, so they can get anywhere on it. It's because of the Sony BIOS. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About 5.0 and Nvidia drivers
On Sat, 3 Aug 2002, Erik Greenwald wrote: ugh, sounds like the lip-service I was getting. I'll look into that :/ No, they're working on it, and actually have GL running in the lab. I'm starting to ponder the legality and challenge involved in reverse engineering the card and building a driver from scratch... maybe something that works with X the X way (dri/drm) You're a funny guy. You'd be better off working with ATI or the PowerVR people. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
