Re: How to add a new bootdevice to the new boot code ???
It seems Robert Nordier wrote: If the problem is the bootblocks, why not send a message to Robert Nordier, or if it's loader, to Mike Smith or Daniel Sobral? And say, This is what I want to do, what are we going to do about it? or something similar? OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. As the bootcode is now this wont work. If its as simple as me adding the pair 30 ad somewhere, I'm satisfied, if not, I'm dissapointed :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: So here I am with our new boot code and a new device, how the @$ am I supposed to boot from that with the glory new boot blocks, forth and what have we ??? The glory new boot blocks rely on the good old BIOS to boot. Anything else is a chickenegg problem. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic occurred: vm_fault
The fault seems to be reproducable.
mount /cdrom
find /cdrom -type f -exec cat \{\} /dev/null \; -ls
and pop it goes. Same stack trace. We could do a try-this-game this weekend (up
to
then I'm covered in work) if that would be helpfull.
Let me know what information you need.
Nick
On Tue, 16 Mar 1999, Nick Hibma wrote:
In case someone who is interested in the following panic:
Occurred under a lightly loaded system that was not doing anything apart
from reading a CD (dd if=/dev/cd0c of=/dev/null bs=512).
Kernel current as of yesterday.
No core file is available unfortunately.
panic: vm_fault: fault on nofault entry, addr: c35c6000
(blabla about debugger)
show registers
cs 0x8
ds 0x10
es 0x10
ss 0x10
eax 0x12
ecx 0xc00b8f00
edx 0xc024d1a4 db_lengths+0x11c
ebx 0xc0248255
__set_sysctl_set_sym_sysctl__vm_swap_async_max+0x1d9
esp 0xc6f23ca8
ebp 0xc6f23cb0
esi 0x100
edi 0xc35c6000
eip 0xc020f993 Debugger+0x37
efl 0x256
trace
panic
vm_fault
trap_pfault
trap
calltrap()
--- trap
slow_copyout
spec_read
ufsspec_read
ufs_vnoperatespec
vn_read
read
syscall
Xint0x80syscall
--
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
--
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. I'd be inclined to handle this outside the boot code, by treating the passed in major# as describing the device rather than specifying the driver. The point about the boot code is it is deliberately intended to be usable when completely out of sync with any actual kernel it is booting. (I expect to be able to use 2.0 bootblocks with 4.0, and also that loader will be able to boot a 2.0 kernel.) I assume at some stage that some stage the new driver will take over completely, and the older driver will disappear. Before that, as people grow accustomed to thinking ad rather than wd, it will probably make sense for the boot code to accept (say) 0:ad(0,a)boot/loader rather than 0:wd(0,a)boot/loader However, I'd *still* expect it to pass a major# of 0 rather than 30. Why? Because a 2.0 kernel knows only 0. And if a 5.0 kernel knows only 30, it is -- at least -- in a position to know what 0 meant, and simply substitute one for the other (under the influence of a kernel configuration option, if necessary). As an example of the kind of reasoning that goes into the above, consider the case of booting from CD-ROM. If the boot image used is that of a floppy, the major# used is 2; if the boot image uses is that of a hard disk (quite probably a old 20M MFM 615x4x17 hard disk), the major# used is 0. So in both cases, the major# doesn't relate to what was booted from, and may not even describe the underlying technology correctly. As the bootcode is now this wont work. If its as simple as me adding the pair 30 ad somewhere, I'm satisfied, if not, I'm dissapointed :) -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Robert Nordier wrote: Søren Schmidt wrote: OK, easy enough, this is what I want to do: Boot from an ata disk on major# 30, device name ad, plain and simple. I'd be inclined to handle this outside the boot code, by treating the passed in major# as describing the device rather than specifying the driver. The point about the boot code is it is deliberately intended to be usable when completely out of sync with any actual kernel it is booting. (I expect to be able to use 2.0 bootblocks with 4.0, and also that loader will be able to boot a 2.0 kernel.) I assume at some stage that some stage the new driver will take over completely, and the older driver will disappear. Before that, as people grow accustomed to thinking ad rather than wd, it will Not likely, as long as we need support for MFM/RLL/ESDI disk, wd.c will stay around. probably make sense for the boot code to accept (say) 0:ad(0,a)boot/loader rather than 0:wd(0,a)boot/loader That would be nice, could I please have that ?? However, I'd *still* expect it to pass a major# of 0 rather than 30. Why? Because a 2.0 kernel knows only 0. And if a 5.0 kernel knows only 30, it is -- at least -- in a position to know what 0 meant, and simply substitute one for the other (under the influence of a kernel configuration option, if necessary). Hmm, wd should give 0 and ad should give 30, no AI please :) I've tried fooling the driver to just use the 0 number, but mount blows up, complaing that mounted root is different from specified root... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
disk quota overriding
Hi!
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Dmitry.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Hi
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Haven't tested this, but are you sure it fills the filesystem up -
all a hard link is, is a file with the same inode as the
original file (correct me if I'm wrong) - therefore it
doesn't actually use any space other than that required
to store the file entry.
--
Regards,
Jay Tribick netad...@fastnet.co.uk
[| Network Admin | FastNet International | http://fast.net.uk/ |]
[| Finger netad...@fastnet.co.uk for contact info PGP PubKey |]
[| +44 (0)1273 T: 677633 F: 621631 e: netad...@fast.net.uk |]
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Are you aware that, due to nature of hardlinks the only extra space is
same that for an empty file? Due to this, how many empty files do you
think it takes to eat the whole space of / ?
I'm I loosing something?
Regards.
En un mensaje anterior, Dmitry Valdov escribió:
Hi!
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Fernando P. Schapachnik
Administracion de la red
VIA Net Works Argentina SA
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Jay Tribick wrote:
Date: Wed, 17 Mar 1999 11:49:32 +
From: Jay Tribick netad...@fastnet.co.uk
To: Dmitry Valdov d...@dv.ru
Cc: freebsd-current@FreeBSD.ORG, freebsd-secur...@freebsd.org
Subject: Re: disk quota overriding
Hi
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Haven't tested this, but are you sure it fills the filesystem up -
all a hard link is, is a file with the same inode as the
original file (correct me if I'm wrong) - therefore it
doesn't actually use any space other than that required
to store the file entry.
^
Yes. But /tmp dir is under root filesystem. So *directory* size of /tmp can be
grown up to free space on /. Which will result 0 bytes free on / :) All
available space will be used to store directory entries.
Dmitry.
PS. Sorry for my english.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Fernando Schapachnik wrote:
Date: Wed, 17 Mar 1999 08:50:50 -0300 (GMT)
From: Fernando Schapachnik fps...@ns1.sminter.com.ar
To: Dmitry Valdov d...@dv.ru
Cc: freebsd-current@FreeBSD.ORG, freebsd-secur...@freebsd.org
Subject: Re: disk quota overriding
Are you aware that, due to nature of hardlinks the only extra space is
same that for an empty file? Due to this, how many empty files do you
think it takes to eat the whole space of / ?
No. Many empty files can be controlled by INODE QUOTAS.
Hard links can't.
But I can create as many hard links as I need to eat up the whole space of
/...
I'm I loosing something?
Regards.
En un mensaje anterior, Dmitry Valdov escribiС:
Hi!
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Fernando P. Schapachnik
Administracion de la red
VIA Net Works Argentina SA
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? Not if I can help it :) It could be done by slamming a translation layer ontop of the existing wd driver or of cause on top of the new I'm doing, but all it adds is overhead, both performance wise and codesize wise. There is nothing that prohibits having both of cause, but it is not a priority for me to add more complexity into the picture before everything else is done. If not, can we PLEASE rename SCSI disks back to ``sd''? No objections from me. But why, it will only confuse users once again... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? Agreed. I see no justification for the sd - da change if the ATA disks won't (eventually) be included. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
On Wed, Mar 17, 1999 at 12:51:12PM +1030, Greg Lehey wrote: # On Tuesday, 16 March 1999 at 22:36:38 +0300, Mikhail A. Sokolov wrote: # Hello, # # we're experiencing repeated 4.0-C (as of today, something around 12:00 # GMT, 1999-03-16) ufs_dirbad() panics, which are the # following (below), which usually occur when squid is running. The box # doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. # Squid's spool is hardware (IFT3102) RAID1, 2x9gb (i.e. 4 disks): # /var/crash# gdb -k kernel.1 vmcore.1 # IdlePTD 2682880 # initial pcb at 21c7b8 # panicstr: ufs_dirbad: bad dir # panic messages: # --- # panic: ufs_dirbad: bad dir # # Have you looked at the directory? Theoretically this could be a # really mangled directory structure. Yes, of course. Those swap catalogues which are not to be touched by squid are turned into it's swapfiles, sometimes there's an error of 'bad file descriptor' and such. As I said in reply to Julian, I've newfs'ed these spools plenty times, - errors are repeated and, besides, lookalike. That's a glitch in FFS somewhere, I assume: I've had similiar panics on another squid with exactly the very same hardware/software configuration, besides the fact the OS there was 3.[01]-S. Similiar panics, different scsi disks, tryed not to use the mentioned IFT RAID - no difference. I.e. I could've agreed with that this could be really doomed directory, but no, it's not that way, squid's allocating objects in memory, when it reaches the limit it'd swap it to the spool (as per LRU and such rules) and then, after it dies, I find that ~1 recursive swap file (2 disksx9gb, 256 catalogues of 16 subdirs each in 8 and 6 cache_dirs as applicable to two spools) in each of the subdirs (second level cache) has died, - has been automagically converted to contain some crap [by FFS?]. What could help is that squid is configured to use poll(), doesn't use threads, doesn't do async (i.e. as squid undestands it, it's an option there) operations. Mounts on the FS's are noatime, but that ain't is the culprit, ain't they? # Greg # -- # See complete headers for address, home page and phone numbers # finger g...@lemis.com for PGP public key -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Crash while newfs'ing innocent vinum volume on fresh system.
Hello !
Before of all I want to make sure that you understand the conditions
here:
I have reinstalled fresh 3.1-RELEASE to the machine in question,
before swapped out two memory DIMM's to the single new 32MB one, just
to be sure it's not some kind of memory error. Installation went
fine, the developer type of installation with full sources but no
games, heh.
Then I downloaded your newest archive for vinum installation:
vinum-4.0-CURRENT.tar.gz from ftp.nanyang-computer.com/pub/vinum/.
It's marked as March 14. Packed it off over the /usr/src and done
compilations in module section and control program section. I also
done make cleandir; make clean in the appropriate directories
several times just to be sure. Compilations went fine and the module
and control program are in the right places with right dates showing
these are newer ones.
Copied the same kernel configuration file as usual to the right place
from backup. Made some minor changes to kernel configuration, removed
DMA support for ata disks, I don't trust the support very much yet.
Made new debug kernel, copied to /var/crash, stripped the original
with -g and installed. Reboot.
Machine goes up, multiuser mode. Right after reboot there are no
modules in loaded. Executed vinum create stripe.conf, ok. Executed
vinum init, vinum debug 96, vinum saveconfig, vinum printconfig
blabla. All is ok yet.
Newfs -n1 -d0 -v /dev/vinum/rsvol two lines newfs output and
crash:
Script started on Wed Mar 17 13:24:45 1999
sh-2.02# gdb -k kernel.gdb vmcore.0
GDB is free software and you are welcome to 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.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 2760704
initial pcb at 23af94
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xdeadc0e6
fault code = supervisor read, page not present
instruction pointer = 0x8:0xf0a4bc34
stack pointer = 0x10:0xf3db8da8
frame pointer = 0x10:0xf3db8db8
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 = 259 (newfs)
interrupt mask =
panic: from debugger
panic: from debugger
dumping to dev 20001, offset 65536
dump 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) add-symbol-file /modules/vinum.ko 0x5ba8+
A syntax error in expression, near `'.
(kgdb) add-symbol-file /modules/vinum.ko 0x5ba8
add symbol table from file /modules/vinum.ko at text_addr = 0x5ba8?
(y or n) y
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:285
#1 0xf01324b5 in panic (fmt=0xf020e0cc from debugger)
at ../../kern/kern_shutdown.c:446
#2 0xf01188fd in db_panic (addr=-257639372, have_addr=0, count=-1,
modif=0xf3db8c2c ) at ../../ddb/db_command.c:432
#3 0xf011889d in db_command (last_cmdp=0xf0227e7c, cmd_table=0xf0227cdc,
aux_cmd_tablep=0xf0238c80) at ../../ddb/db_command.c:332
#4 0xf0118962 in db_command_loop () at ../../ddb/db_command.c:454
#5 0xf011acb3 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#6 0xf01e1056 in kdb_trap (type=12, code=0, regs=0xf3db8d6c)
at ../../i386/i386/db_interface.c:157
#7 0xf01eb47c in trap_fatal (frame=0xf3db8d6c, eva=3735929062)
at ../../i386/i386/trap.c:937
#8 0xf01eb15b in trap_pfault (frame=0xf3db8d6c, usermode=0, eva=3735929062)
at ../../i386/i386/trap.c:835
#9 0xf01eadba in trap (frame={tf_es = -203751408, tf_ds = -203751408,
tf_edi = -559038242, tf_esi = -2147483648, tf_ebp = -203715144,
tf_isp = -203715180, tf_ebx = -258066920, tf_edx = 16384, tf_ecx = 14,
tf_eax = -16162, tf_trapno = 12, tf_err = 0, tf_eip = -257639372,
tf_cs = 8, tf_eflags = 66182, tf_esp = -257699840, tf_ss = -245981592})
at ../../i386/i386/trap.c:437
#10 0xf0a4bc34 in ?? ()
#11 0xf0a4bae1 in ?? ()
#12 0xf0a4b8b6 in ?? ()
---Type return to continue, or q return to quit---
#13 0xf012ffec in physio (strategy=0xf0a4b808 swbuf+8322816, bp=0x0,
dev=23296, rw=0, minp=0xf01300dc minphys, uio=0xf3db8f34)
at ../../kern/kern_physio.c:113
#14 0xf0a4c97c in ?? ()
#15 0xf0162f2f in spec_write (ap=0xf3db8ef8)
at ../../miscfs/specfs/spec_vnops.c:355
#16 0xf01c3b18 in ufsspec_write (ap=0xf3db8ef8)
at ../../ufs/ufs/ufs_vnops.c:1840
#17 0xf01c408d in ufs_vnoperatespec (ap=0xf3db8ef8)
at ../../ufs/ufs/ufs_vnops.c:2312
#18 0xf015d3b7 in vn_write (fp=0xf0a3ca80, uio=0xf3db8f34, cred=0xf0a39f80)
at vnode_if.h:331
#19 0xf013cf46 in write (p=0xf3d71b20, uap=0xf3db8f84)
at ../../kern/sys_generic.c:270
#20 0xf01eb68b
Re: repeated ffs_blkfreepan...@demos.su, 4.0-C
On Wed, Mar 17, 1999 at 12:54:40PM +1030, Greg Lehey wrote:
# On Tuesday, 16 March 1999 at 22:41:22 +0300, Mikhail A. Sokolov wrote:
# Hello,
# the box is the same as in previous mail of mine which described ufs_dirbad()
# panics on 4.0-C. Panics are reproducable (run squid 2.1-pl2 with some
# 30 requests/second).
#
# These two crashes both tend to suggest a file system structure problem
# which fsck doesn't detect. What's the vp in the ffs_truncate frame?
Couldn't help agreeing more ;) See previous answer, though.
# How does it compare to the *vpp in the ufs_lookup frame of the
# previous dump?
Unfortunately, at the moment I have to admit I have been able to afford
keeping the dumps, let's wait the next time. Then again, whilst I am typing
this (below). I tend to be somewhat amazed that the frame 8 is usually the
same for many different panics this box experiences (little summary: this is
probably to be named the most panicing FreeBSD box in the world, 140 panics in
a month, all the hardware has been swapped to the same, but new (i.e. reproduced
the same configuration from spare new parts), panics were either already
announced by other peple, like, Matthew Jacob's reports, or fixed after
many other different reports, like, Matthew Dillon's work brought much more
stability to the beast, no more 'lockmgr: locking against myself' and
'vm_page*' of many kinds. Then again, this box is an experimental and was
brought to 4.0-C to check if it could survive with it, since it couldn't when
it was 3.1-S)
var/crash# gdb -k *3
initial pcb at 21c7b8
panicstr: ffs_valloc: dup alloc
panic messages:
---
panic: ffs_valloc: dup alloc
syncing disks... 147 75 2 done
(da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0
(da1:ahc1:0:1:0): Invalid command operation code
(da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0
(da2:ahc1:0:2:0): Invalid command operation code
(da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0
(da3:ahc1:0:3:0): Invalid command operation code
Btw, Kenneth, I know this is harmless, but didn't Justing's (Gibbs) explicitely
forbid the sync cache to be so verbose or I confuse wanted with the done
things?;)
dumping to dev 20401, offset 821524
dump 256 ...
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xc013b4b9 in panic (fmt=0xc01fdf01 ffs_valloc: dup alloc)
at ../../kern/kern_shutdown.c:448
#2 0xc01b4e84 in ffs_valloc (pvp=0xce418ac0, mode=33188, cred=0xc1fab580,
vpp=0xce264cd0) at ../../ufs/ffs/ffs_alloc.c:604
#3 0xc01c21cd in ufs_makeinode (mode=33188, dvp=0xce418ac0, vpp=0xce264f14,
cnp=0xce264f28) at ../../ufs/ufs/ufs_vnops.c:2097
#4 0xc01bf9de in ufs_create (ap=0xce264e30) at ../../ufs/ufs/ufs_vnops.c:179
#5 0xc01c23a1 in ufs_vnoperate (ap=0xce264e30)
at ../../ufs/ufs/ufs_vnops.c:2309
#6 0xc01631c7 in vn_open (ndp=0xce264f04, fmode=1550, cmode=420)
at vnode_if.h:83
#7 0xc015fee9 in open (p=0xcce8b860, uap=0xce264f94)
at ../../kern/vfs_syscalls.c:928
#8 0xc01e769f in syscall (frame={tf_es = 47, tf_ds = -1078067153,
tf_edi = 1549, tf_esi = 247619088, tf_ebp = -1078010952,
tf_isp = -836349980, tf_ebx = 134788528, tf_edx = 219774816, tf_ecx = 0,
tf_eax = 5, tf_trapno = 22, tf_err = 2, tf_eip = 672227132, tf_cs = 31,
tf_eflags = 534, tf_esp = -1078010980, tf_ss = 47})
at ../../i386/i386/trap.c:1101
#9 0xc01de9fc in Xint0x80_syscall ()
#10 0x808ae54 in ?? ()
#11 0x808b3c2 in ?? ()
#12 0x8084c1f in ?? ()
#13 0x8067e87 in ?? ()
#14 0x805c06a in ?? ()
#15 0x8071f7f in ?? ()
#16 0x804a1b1 in ?? ()
(kgdb)
#
# Greg
# --
# See complete headers for address, home page and phone numbers
# finger g...@lemis.com for PGP public key
--
-mishania
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Hi!
I think that there is only one way to fix it - it's to disable making
*hard*links to directory with mode 1777.
On Wed, 17 Mar 1999, Dmitry Valdov wrote:
Date: Wed, 17 Mar 1999 14:42:46 +0300 (MSK)
From: Dmitry Valdov d...@dv.ru
To: freebsd-current@freebsd.org, freebsd-secur...@freebsd.org
Subject: disk quota overriding
Hi!
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Dmitry.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Crash while newfs'ing innocent vinum volume on fresh system.
I don't know what frames 10-12 are supposed to be, but I can give you the short answer on why it crashed: you have INVARIANTS on (good!), so free()ing stuffs memory with 0xdeadc0de. Whatever frame 10 was doing tried to dereference previously freed memory. Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I asked Soren just this kind of question, and he declined to answer. I doan geddit... On Wed, 17 Mar 1999, David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I assume at some stage that some stage the new driver will take over completely, and the older driver will disappear. Before that, as people grow accustomed to thinking ad rather than wd, it will Not likely, as long as we need support for MFM/RLL/ESDI disk, wd.c will stay around. probably make sense for the boot code to accept (say) 0:ad(0,a)boot/loader rather than 0:wd(0,a)boot/loader That would be nice, could I please have that ?? OK, I'll add it to the bootblocks. Incidentally, while I'm in there and thinking about it, I'd quite like to fix the boot code to boot from LS-120 drives at the same time. So if anyone has one of these, and wouldn't mind spending some time running a few bits of test code, I'd appreciate it. However, I'd *still* expect it to pass a major# of 0 rather than 30. Why? Because a 2.0 kernel knows only 0. And if a 5.0 kernel knows only 30, it is -- at least -- in a position to know what 0 meant, and simply substitute one for the other (under the influence of a kernel configuration option, if necessary). Hmm, wd should give 0 and ad should give 30, no AI please :) I wasn't actually thinking at all along the lines of smart code at all: #ifdef FORCE_FOO if (foo == 0) foo = 30; #endif The administrator or operator is still entirely in control; the only difference is in what part of the code the control is exercised. AFAICS, adopting the separate wd and ad route entails the following: Update your bootblocks. Add a /boot.config statement like 0:ad(0,a) to make use of the driver the default. Failure to boot if you inadvertently specify wd out of habit, or if you specify ad when booting an earlier system. So we're introducing three points with good potential for failure. In contrast, the kernel configuration route requires commenting or uncommenting a single statement. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ERRATA NOTICE: FreeBSD 3.1-RELEASE
** ** THIS IS AN AUTOMATIC ERRATA UPDATE FOR FREEBSD 3.1-RELEASE ** ** You can retrieve the complete ERRATA from: ftp://ftp.freebsd.org/pub/FreeBSD/3.1-RELEASE/ERRATA.TXT The last update was sent: Sat Mar 13 03:20:55 1999 This update is sent: Wed Mar 17 06:00:48 1999 -- SYSTEM ERRATA INFORMATION: o DOS installation fails when you actually follow the instructions to install stuff under C:\FREEBSD\BIN\... and so on. Fix: The instructions are correct but the code was wrong in 3.1-RELEASE, sysinstall looking instead directly under C:\ (e.g. C:\BIN\...) or under C:\RELEASES\ (C:\RELEASES\BIN\... and so on). Fixed in 3.1-STABLE. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Matthew Jacob wrote: I asked Soren just this kind of question, and he declined to answer. I doan geddit... WHAT ?? I replied with this: #From sos Wed Mar 17 08:51:14 1999 #Subject: Re: How to add a new bootdevice to the new boot code ??? #In-Reply-To: pine.lnx.4.04.9903161510480.12815-100...@feral-gw from Matthew Jacob at Mar 16, 1999 3:11: 1 pm #To: mja...@feral.com #Date: Wed, 17 Mar 1999 08:51:14 +0100 (CET) # #It seems Matthew Jacob wrote: # #Is this a rant or a request for information? # #I could be both :), but basically I want to know what should be #done to have it boot from a new major#, in this case 30 the #new ata driver. But from a look at the code it seems that this #might be alot more work than it should be Geddit now ?? At least try to read to the end of your mailbox, before accusing me for ignorance, thankyou! -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Robert Nordier wrote: OK, I'll add it to the bootblocks. Incidentally, while I'm in there and thinking about it, I'd quite like to fix the boot code to boot from LS-120 drives at the same time. So if anyone has one of these, and wouldn't mind spending some time running a few bits of test code, I'd appreciate it. I have a ZIP if that can help you ?? However, I'd *still* expect it to pass a major# of 0 rather than 30. Why? Because a 2.0 kernel knows only 0. And if a 5.0 kernel knows only 30, it is -- at least -- in a position to know what 0 meant, and simply substitute one for the other (under the influence of a kernel configuration option, if necessary). Hmm, wd should give 0 and ad should give 30, no AI please :) I wasn't actually thinking at all along the lines of smart code at all: #ifdef FORCE_FOO if (foo == 0) foo = 30; #endif Well, that breaks somewhere else, as the mount code is clever enough to look at the name of the driver in this case ad which doesn't match the specified #0 ie wd. I kindof tried this by having my driver put itself in both the wd ad majors in the table, but that doesn't work, because the mount stuff gets confused on the root name somehow, and fails to mount root because the names dont match... AFAICS, adopting the separate wd and ad route entails the following: Update your bootblocks. Add a /boot.config statement like 0:ad(0,a) to make use of the driver the default. Failure to boot if you inadvertently specify wd out of habit, or if you specify ad when booting an earlier system. So we're introducing three points with good potential for failure. Well, what else can we do as long as we potentially need both drivers in the kernel. I'm pretty sure that if I kill of wd.c et all, there will be screams of bloody murder again... been there done that :) In contrast, the kernel configuration route requires commenting or uncommenting a single statement. But that doesn't work, at least as the mount code behaves now. At any rate, any solution that makes it possible to boot with a new driver without me having to call it wd something all over the place is acceptable to me... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: disk quota overriding
-Original Message- From: Dmitry Valdov [SMTP:d...@dv.ru] Sent: Wednesday, March 17, 1999 1:37 PM To: freebsd-current@freebsd.org; freebsd-secur...@freebsd.org Subject: Re: disk quota overriding Hi! I think that there is only one way to fix it - it's to disable making *hard*links to directory with mode 1777. [ML] But only if the quotas have been turned on. BTW, has chown been fixed to the ludicrous SysV semantics that the root and owner can chown a file? If so, the latter has to be disabled in presence of quotas on the volume--otherwise: touch big_file chmod 777 big_file chown root:wheel big_file cat /dev/zero big_file This joke used to work on HPUX 10.something which kept the owner-may-chown semantics even in presence of quotas. It was not funny. (I don't know whether HP has fixed that). /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
=I think that there is only one way to fix it - it's to disable making =*hard*links to directory with mode 1777. Would not it be easier and more practical to make those directories belong to, say, nobody? And make sure nobody's quota is small enough? = Because /tmp directory usually owned by root that why quotas has no effect. = *Directory* size of /tmp can be grown up to available space on / filesystem. -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: disk quota overriding
On Wed, 17 Mar 1999, Ladavac Marino wrote: Date: Wed, 17 Mar 1999 14:37:32 +0100 From: Ladavac Marino mlada...@metropolitan.at To: 'Dmitry Valdov' d...@dv.ru, freebsd-current@freebsd.org, freebsd-secur...@freebsd.org Subject: RE: disk quota overriding -Original Message- From: Dmitry Valdov [SMTP:d...@dv.ru] Sent: Wednesday, March 17, 1999 1:37 PM To: freebsd-current@freebsd.org; freebsd-secur...@freebsd.org Subject:Re: disk quota overriding Hi! I think that there is only one way to fix it - it's to disable making *hard*links to directory with mode 1777. [ML] But only if the quotas have been turned on. Sure. What Core Team thinks about it? Dmitry. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
I think you are missing the point. We will not chuck the old wd* driver until people have crashed all MFM, RLL, ESDI and !ATA IDE drives. So we WANT to be able to tell the difference... Poul-Henning In message pine.lnx.4.04.9903170447220.17718-100...@feral-gw, Matthew Jacob w rites: I asked Soren just this kind of question, and he declined to answer. I doan geddit... On Wed, 17 Mar 1999, David O'Brien wrote: Boot from an ata disk on major# 30, device name ad, plain and simple. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
In message 97a8ca5bf490d211a94ff6c2e55d097...@s-lmh-wi-900.corpnet.at, La davac Marino wrote: } BTW, has chown been fixed to the ludicrous SysV semantics that } the root and owner can chown a file? If so, the latter has to be } disabled in presence of quotas on the volume--otherwise: } } touch big_file } chmod 777 big_file } chown root:wheel big_file } cat /dev/zero big_file } } This joke used to work on HPUX 10.something which kept the } owner-may-chown semantics even in presence of quotas. It was not funny. } (I don't know whether HP has fixed that). Under HP-UX 9.x, the behavior you describe was the default, and it was changable by altering a kernel config parameter and relinking the kernel. The same tunable is available under 10.x, but I'm less certain what the default behavior is there. Whether quotas are enabled or not does not affect the behavior, only the kernel tunable parameter. -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Jon Hamilton wrote: } touch big_file } chmod 777 big_file } chown root:wheel big_file } cat /dev/zero big_file } This joke used to work on HPUX 10.something which kept the } owner-may-chown semantics even in presence of quotas. It was not funny. } (I don't know whether HP has fixed that). Under HP-UX 9.x, the behavior you describe was the default, and it was changable by altering a kernel config parameter and relinking the kernel. The same tunable is available under 10.x, but I'm less certain what the default behavior is there. Whether quotas are enabled or not does not affect the behavior, only the kernel tunable parameter. We all know that there are oodles of security problems associated with file giveaways. As I recall, all the texts I have ever read on the subject say that unless there is a very good reason to allow giveaways, they should be disabled. -Michael To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Dmitry Valdov wrote:
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
I've always thought that /tmp should be its own filesystem
anyways and I generally make it so. Avoids all sorts of nasties.
It seems silly to mix up the most vital system files on the same
filesystem as the most volitile, damage-prone directory (/tmp). Its
better to newfs /tmp regularly.
As far as the other issue, the ability to fill up any
public 777 directory even with quotas, perhaps the quota system
should look at the 1000 bit and do something special with it.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
: :I.e. I could've agreed with that this could be really doomed directory, but no, :it's not that way, squid's allocating objects in memory, when it reaches the :limit it'd swap it to the spool (as per LRU and such rules) and then, after :it dies, I find that ~1 recursive swap file (2 disksx9gb, 256 catalogues of :16 subdirs each in 8 and 6 cache_dirs as applicable to two spools) in each :of the subdirs (second level cache) has died, - has been automagically converted :to contain some crap [by FFS?]. : :What could help is that squid is configured to use poll(), doesn't use threads, :doesn't do async (i.e. as squid undestands it, it's an option there) operations. :Mounts on the FS's are noatime, but that ain't is the culprit, ain't they? : :-- :-mishania It kinda sounds like you have two overlapping partitions. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
nope /dev/da1e 17235735 7414244 844263347%/mnt/arc /dev/da2e 8617355 1724705 689265020%/mnt/spool1 /dev/da3e 8617355 1723638 689371720%/mnt/spool2 On Wed, Mar 17, 1999 at 08:29:54AM -0800, Matthew Dillon wrote: # : # :What could help is that squid is configured to use poll(), doesn't use threads, # :doesn't do async (i.e. as squid undestands it, it's an option there) operations. # :Mounts on the FS's are noatime, but that ain't is the culprit, ain't they? # : # :-- # :-mishania # # It kinda sounds like you have two overlapping partitions. # # -Matt # Matthew Dillon # dil...@backplane.com -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Incidentally, while I'm in there and thinking about it, I'd quite
like to fix the boot code to boot from LS-120 drives at the same
time. So if anyone has one of these, and wouldn't mind spending
some time running a few bits of test code, I'd appreciate it.
I have a ZIP if that can help you ??
Thanks. AFAIK, the essential difference is that the LS-120 needs
to be treated (in the boot code) like a floppy, whereas the ZIP
should be treated like a hard disk. But we need to accommodate
both, so I'd be glad if you'd test the changes, once I've done
them.
#ifdef FORCE_FOO
if (foo == 0)
foo = 30;
#endif
Well, that breaks somewhere else, as the mount code is clever enough
to look at the name of the driver in this case ad which doesn't
match the specified #0 ie wd.
I kindof tried this by having my driver put itself in both the
wd ad majors in the table, but that doesn't work, because the mount
stuff gets confused on the root name somehow, and fails to mount
root because the names dont match...
The arguments passed from the boot code to the kernel are
howto, bootdev, res1, res2, res3, bootinfop
where
howto is an int containing RB_* bitflags (sys/reboot.h) which
represent the boot options like -c, -v, etc.
bootdev is an int put together using the MAKEBOOTDEV macro
(sys/reboot.h) from the major#, unit#, slice#, and partition#
of the boot device.
res1 through res3 are reserved/ignored.
bootinfop is a pointer to a bootinfo structure
(machine/bootinfo.h) which contains an assortments of parameters,
but none relating directly to the boot device driver (bi_bios_dev
is for /boot/loader's benefit).
So the *only* relevant info passed by the boot code is the major#.
And if we force a change in the major# (for the sake of discussion,
in the section of src/sys/i386/i386/locore.s that already has
compatibility code for dealing with legacy bootblocks -- though
I'm not saying that is the best place for it), we've done all we
*can* do in the boot code, within the framework as it exists.
So whether we add {da, 30} to a lookup table in boot2, or use the
FORCE_FOO approach, the results will be identical.
At any rate, any solution that makes it possible to boot with
a new driver without me having to call it wd something all
over the place is acceptable to me...
Anyway, I take a look at both approaches, probably later today,
and send you some diffs, hopefully relating to each way of doing
things.
--
Robert Nordier
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Fernando Schapachnik wrote: Are you aware that, due to nature of hardlinks the only extra space is same that for an empty file? Due to this, how many empty files do you think it takes to eat the whole space of / ? They take *less* space than an empty file, just the directory entry. You can see how muchh by looking at the size of the '.' grow when you add one. An empty file still takes an inode, as an 'ls -li [filename]' will show. Now a small amount of anything multiplied by a large number can amount to something. If you have a small root, I can see where you could overwhelm it. It will also take longer and longer to ann the links and lookups in /tmp will take forever. Dmitry Valdov wrote: Because /tmp directory usually owned by root that why quotas has no effect. *Directory* size of /tmp can be grown up to available space on / filesystem. My favorite way is a /tmp filesystem. It solves stability problems unrelated to quotas as well. Same goes for /home if you have real users on your system (not just a server) - Jy@ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Dmitry Valdov wrote: I think that there is only one way to fix it - it's to disable making *hard*links to directory with mode 1777. I'm wondering: are you concerned this is possible, or that you really have a user doing it? I have kicked users off the system for less when they have trounced the machine for others. This is beginning to sound like more of the hard/symlink eruptions last week... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
On Wed, 17 Mar 1999, Robert Nordier wrote: Incidentally, while I'm in there and thinking about it, I'd quite like to fix the boot code to boot from LS-120 drives at the same time. So if anyone has one of these, and wouldn't mind spending some time running a few bits of test code, I'd appreciate it. I can do that when I'm back in Poland (i.e. after Cebit). Andrzej Bialecki // ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Dmitry Valdov wrote: Hi! I think that there is only one way to fix it - it's to disable making *hard*links to directory with mode 1777. *IF* you are using quotas. Otherwise, it could break things for people. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
Jay Tribick wrote:
There is a way to overflow / filesystem even is quota is enabled.
Just make many hard links (for example /bin/sh) to /tmp/
for ($q=0;$q10;$q++){
system (ln /bin/sh /tmp/ln$q);
}
Because /tmp directory usually owned by root that why quotas has no effect.
*Directory* size of /tmp can be grown up to available space on / filesystem.
Any way to fix it?
Haven't tested this, but are you sure it fills the filesystem up -
all a hard link is, is a file with the same inode as the
original file (correct me if I'm wrong) - therefore it
doesn't actually use any space other than that required
to store the file entry.
You missed the dirty trick... :-) It's the size of +/tmp+ that fills
/. The *directory* size. Because it has to *store* all these
links...
--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org
What happened?
It moved, sir!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: Well, that breaks somewhere else, as the mount code is clever enough to look at the name of the driver in this case ad which doesn't match the specified #0 ie wd. I kindof tried this by having my driver put itself in both the wd ad majors in the table, but that doesn't work, because the mount stuff gets confused on the root name somehow, and fails to mount root because the names dont match... I know you most certainly could not possibly have forgotten that, but it's the kind of thing that just *must* be mentioned... /etc/fstab? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Poul-Henning Kamp wrote: I think you are missing the point. We will not chuck the old wd* driver until people have crashed all MFM, RLL, ESDI and !ATA IDE drives. So we WANT to be able to tell the difference... The point here is just naming. Right now, we have: wd0, ... ad0, ... da0, ... People are asking for: wd0, ... da0, ... Ie, join ad and da namespaces. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Andrzej Bialecki wrote: On Wed, 17 Mar 1999, Robert Nordier wrote: Incidentally, while I'm in there and thinking about it, I'd quite like to fix the boot code to boot from LS-120 drives at the same time. So if anyone has one of these, and wouldn't mind spending some time running a few bits of test code, I'd appreciate it. I can do that when I'm back in Poland (i.e. after Cebit). Andrzej Bialecki Thanks! I'll take you up on that. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
sth...@nethelp.no wrote: Amen. Does this mean ata disks won't come under CAM/da ? If not, can we PLEASE rename SCSI disks back to ``sd''? Agreed. I see no justification for the sd - da change if the ATA disks won't (eventually) be included. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
In message 36eff0f0.9c57e...@newsguy.com, Daniel C. Sobral writes: Poul-Henning Kamp wrote: I think you are missing the point. We will not chuck the old wd* driver until people have crashed all MFM, RLL, ESDI and !ATA IDE drives. So we WANT to be able to tell the difference... The point here is just naming. Right now, we have: wd0, ... ad0, ... da0, ... People are asking for: wd0, ... da0, ... Ie, join ad and da namespaces. If you want to join anything, go directly to disk%d instead. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems Daniel C. Sobral wrote: Søren Schmidt wrote: Well, that breaks somewhere else, as the mount code is clever enough to look at the name of the driver in this case ad which doesn't match the specified #0 ie wd. I kindof tried this by having my driver put itself in both the wd ad majors in the table, but that doesn't work, because the mount stuff gets confused on the root name somehow, and fails to mount root because the names dont match... I know you most certainly could not possibly have forgotten that, but it's the kind of thing that just *must* be mentioned... /etc/fstab? Nope thats not it, been there too :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
We all know that there are oodles of security problems associated with file giveaways. As I recall, all the texts I have ever read on the subject say that unless there is a very good reason to allow giveaways, they should be disabled. You can play games with quotas anyway, because you are alowd to make hard links to files you don't own. I was considering writing some code to restrict the ability to make hardlinks to files to root and the file's owner. I guess it could either be a global sysctl or a per filesystem mount option. Would there be any interest in this it I put it together? Should it be a mount option or a sysctl? Would anyone consider commiting it if I did write it? David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: It seems Daniel C. Sobral wrote: Søren Schmidt wrote: Well, that breaks somewhere else, as the mount code is clever enough to look at the name of the driver in this case ad which doesn't match the specified #0 ie wd. I kindof tried this by having my driver put itself in both the wd ad majors in the table, but that doesn't work, because the mount stuff gets confused on the root name somehow, and fails to mount root because the names dont match... I know you most certainly could not possibly have forgotten that, but it's the kind of thing that just *must* be mentioned... /etc/fstab? Nope thats not it, been there too :) Ok, I have a clue... bootdev can be different from rootdev. I don't know where this makes a difference, but it makes... :-) Meanwhile, edit sys/boot/i386/libi386/biosdisk.c and change WDMAJOR to 30. If that doesn't help, the problem must be elsewhere. Also, make sure you don't have any root_disk_unit or num_ide_disks set. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
People are asking for: wd0, ... da0, ... Ie, join ad and da namespaces. If you want to join anything, go directly to disk%d instead. But that is not the deal that was presented to us when we had to endure the gratuitous sd-da name change. The whole justification was a single device name for disks (and what ever else is direct access). -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
In message 19990317113918.b39...@relay.nuxi.com, David O'Brien writes: People are asking for: wd0, ... da0, ... Ie, join ad and da namespaces. If you want to join anything, go directly to disk%d instead. But that is not the deal that was presented to us when we had to endure the gratuitous sd-da name change. The whole justification was a single device name for disks (and what ever else is direct access). The fact that Justin promised that ATA ***Could*** use CAM, didn't seem to imply to me that it would, unless somebody wrote code for it. That didn't happen. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: disk quota overriding
On Wed, 17 Mar 1999, Ladavac Marino wrote: chown root:wheel big_file AFAIK, only root can 'give ownership away' on most modern Unix'. Later, -Mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
On Wed, 17 Mar 1999 11:39:18 -0800, David O'Brien obr...@nuxi.com said: But that is not the deal that was presented to us when we had to endure the gratuitous sd-da name change. The whole justification was a single device name for disks (and what ever else is direct access). No, that was not the justification for the name change. The justification (Justinfication?) was that in SCSI terminology, these things -- not all of which are disks -- are called ``direct access'' devices. Similarly, `sa' is ``sequential access''. ATAPI had nothing whatsoever to do with it. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
It seems David O'Brien wrote: People are asking for: wd0, ... da0, ... Ie, join ad and da namespaces. If you want to join anything, go directly to disk%d instead. But that is not the deal that was presented to us when we had to endure the gratuitous sd-da name change. The whole justification was a single device name for disks (and what ever else is direct access). Yes on the SCSI busses, nothing more nothing less Direct Access is the SCSI term for, among others, disks... It was _mentioned_ that ATAPI devices was semilar to SCSI devices and that it _could_ be done through CAM, there was NO promise or anything back when, and there still isn't. ATA disks which this is about, is pretty far way from the CAM/SCSI world, but again a translation layer could be added inbetween. But given the situation that most ATA/ATAPI systems are used in, I belive that our user base will be more interested in max performance instead.. So the sd - da etc namechange has nothing to do with what I'm about to do. I simply ask for the support for booting from any BDEV, and that has not been dealt with in the new boot stuff. Thats what I'm complaining about, dont tell me it wasn't done because all disk like device should be named da, thats too naive to be belived :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Daniel C. Sobral wrote: Søren Schmidt wrote: I know you most certainly could not possibly have forgotten that, but it's the kind of thing that just *must* be mentioned... /etc/fstab? Nope thats not it, been there too :) Ok, I have a clue... bootdev can be different from rootdev. I don't know where this makes a difference, but it makes... :-) In loader, you can have a default device (currdev), but load from a different device (loaddev) and pass a third device to the kernel (rootdev). In the simple case of booting from ad0, all the default settings would be correct, though. Also, make sure you don't have any root_disk_unit or num_ide_disks set. A num_ide_disks setting is used only where the major# indicates a SCSI device, so it wouldn't affect things. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
No, that was not the justification for the name change. The justification (Justinfication?) was that in SCSI terminology, these things -- not all of which are disks -- are called ``direct access'' devices. Similarly, `sa' is ``sequential access''. Then why do we still have ``cd''? Isn't a CDROM a direct access device? Last time I used my, I didn't have to read sector 1 before reading sector 9893. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
spontaneous reboot during `mt erase`
I am running: FreeBSD argus 4.0-CURRENT FreeBSD 4.0-CURRENT #2: Sun Mar 14 18:20:15 CST 1999 jbry...@argus:/usr/src/sys/compile/ARGUS i386 I popped in a 60m tape and did an mt erase. After a couple of minutes, I had a spontaneous reboot. I also noticed that things had really slowed down right before the reboot [3 second delay to toggle the NumLock light]. I didn't catchy the exact time, but am willing to bet that I was in the middle of a popclient run when it happened, as my mailbox was corrupted, and I had to edit the /var/mail spoolfile, and re-get my mail which had the same message on the isp server [meaning that the transfer of the message never finished]. I am running softupdates. Oh yeah, I was running Netscape at the time, but the slowdown was definitely caused by the `mt erase`. This is about all the info I have at the moment. jim -- All opinions expressed are mine, if you| I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered! - #1, The Prisoner -- Inet: jbry...@tfs.netAX.25: kc5...@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ERRATA NOTICE: FreeBSD 3.1-RELEASE
At 6:00 am -0700 17/3/99, freebsd-errata-upd...@roguetrader.com wrote: ** ** THIS IS AN AUTOMATIC ERRATA UPDATE FOR FREEBSD 3.1-RELEASE ** ** [etc] Er, why is this sent to -current? I would have thought this is -announce material. -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Crash while newfs'ing innocent vinum volume on fresh system.
On Wednesday, 17 March 1999 at 14:21:07 +0200, Vallo Kallaste wrote: Newfs -n1 -d0 -v /dev/vinum/rsvol two lines newfs output and crash: Script started on Wed Mar 17 13:24:45 1999 sh-2.02# gdb -k kernel.gdb vmcore.0 GDB is free software and you are welcome to 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. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... IdlePTD 2760704 initial pcb at 23af94 panicstr: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode Since I was looking at these dumps, I find it rather superfluous to copy -CURRENT on this message. I'll take a look and see what's going on. I'm particularly puzzled about the missing stack frames; did you remove the .gdbinit file? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, Jon Hamilton wrote: :Under HP-UX 9.x, the behavior you describe was the default, and it :was changable by altering a kernel config parameter and relinking the :kernel. The same tunable is available under 10.x, but I'm less certain :what the default behavior is there. Whether quotas are enabled or not :does not affect the behavior, only the kernel tunable parameter. This is still the default in 10.20. At least, all of the machines around here are that way. It has some uses on test and lab type machines, as it makes some tasks not have to involve root. As default behavior for a production machine, it is damn silly. David Scheidt : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
According to Mikhail A. Sokolov: nope /dev/da1e17235735 7414244 844263347%/mnt/arc /dev/da2e 8617355 1724705 689265020%/mnt/spool1 /dev/da3e 8617355 1723638 689371720%/mnt/spool2 disklabel output is what you want to send us, df is not enough :-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
According to David E . O'Brien: If not, can we PLEASE rename SCSI disks back to ``sd''? I'm tempted to agree. Many people I know who are upgrading to 3.* are somewhat pissed off by the renaming, even if it is in the release notes. They don't see any good reason for it... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: disk quota overriding
On Wed, 17 Mar 1999, James Wyatt wrote: Now a small amount of anything multiplied by a large number can amount to something. If you have a small root, I can see where you could overwhelm it. It will also take longer and longer to ann the links and lookups in /tmp will take forever. On any machine which allows general users to log in, I strongly recommend making separate file systems for /, /usr, /tmp, and /home, plus any other areas you expect to grow large. Keeping / and /usr separate prevents people from playing ln tricks to gain root access. Keeping /tmp separate helps prevent /tmp from breaking your system when it fills up (note that I say when and not if). Keeping the users on a separate partition helps keep them under control because you can do things like mount the partition with the nosuid attribute. The only time I ever create a machine with a single large partition is when I am creating a dedicated server machine that will only allow logins from trusted staff members. -- David H. Brierley d...@galaxia.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic occurred: vm_fault
:The fault seems to be reproducable.
:
: mount /cdrom
: find /cdrom -type f -exec cat \{\} /dev/null \; -ls
:
:and pop it goes. Same stack trace. We could do a try-this-game this weekend
(up to
:then I'm covered in work) if that would be helpfull.
:
:Let me know what information you need.
:
:Nick
Doesn't happen to me, but I'll try a couple more CD's.
-Matt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Ollivier Robert wrote... According to David E . O'Brien: If not, can we PLEASE rename SCSI disks back to ``sd''? I'm tempted to agree. Many people I know who are upgrading to 3.* are somewhat pissed off by the renaming, even if it is in the release notes. They don't see any good reason for it... Do we have to go over this again and again? It'll be worse if we change back. And it's not like anyone had to upgrade their fstab -- all of the sd devices still work, since the major number is the same. So there's not a lot of room for complaint here. (Yeah, I'm sure someone will start squawking about it right about now.) So, just let it rest. There are lots of more pressing things to worry about. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: vfs_busy: unexpected lock failure
:On Tue, Mar 16, 1999 at 12:52:32PM -0800, Matthew Dillon wrote: : A.. And if you make those AMD mounts normal nfs mounts it doesn't : fry? If so, then we have a bug in AMD somewhere. : :I tried the cp several times again on a regular NFS mount, to make :sure, and no, it doesn't seem to panic. So yes, that seems to be :AMD-related. Can't it be in the vfs layer though? :-- :Pierre Beyssac p...@enst.fr It's probably AMD. I'm not really up on how AMD works... hasn't someone done some work on it recently to fix other breakages? Maybe they could look at this panic. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
On Wed, 17 Mar 1999, S?ren Schmidt wrote: It seems Robert Nordier wrote: OK, I'll add it to the bootblocks. Incidentally, while I'm in there and thinking about it, I'd quite like to fix the boot code to boot from LS-120 drives at the same time. So if anyone has one of these, and wouldn't mind spending some time running a few bits of test code, I'd appreciate it. I have a ZIP if that can help you ?? However, I'd *still* expect it to pass a major# of 0 rather than 30. Why? Because a 2.0 kernel knows only 0. And if a 5.0 kernel knows only 30, it is -- at least -- in a position to know what 0 meant, and simply substitute one for the other (under the influence of a kernel configuration option, if necessary). Hmm, wd should give 0 and ad should give 30, no AI please :) I wasn't actually thinking at all along the lines of smart code at all: #ifdef FORCE_FOO if (foo == 0) foo = 30; #endif Well, that breaks somewhere else, as the mount code is clever enough to look at the name of the driver in this case ad which doesn't match the specified #0 ie wd. I kindof tried this by having my driver put itself in both the wd ad majors in the table, but that doesn't work, because the mount stuff gets confused on the root name somehow, and fails to mount root because the names dont match... AFAICS, adopting the separate wd and ad route entails the following: Update your bootblocks. Add a /boot.config statement like 0:ad(0,a) to make use of the driver the default. Failure to boot if you inadvertently specify wd out of habit, or if you specify ad when booting an earlier system. So we're introducing three points with good potential for failure. Well, what else can we do as long as we potentially need both drivers in the kernel. I'm pretty sure that if I kill of wd.c et all, there will be screams of bloody murder again... been there done that :) Well, since the new ATA doesn't work with my LS-120 yet nor support DMA... ;) I want to see the LS-120 working, so where would I send it to if you were to work on its driver? :) In contrast, the kernel configuration route requires commenting or uncommenting a single statement. But that doesn't work, at least as the mount code behaves now. At any rate, any solution that makes it possible to boot with a new driver without me having to call it wd something all over the place is acceptable to me... -S?ren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic occurred: vm_fault
:: mount /cdrom
:: find /cdrom -type f -exec cat \{\} /dev/null \; -ls
::
::and pop it goes. Same stack trace. We could do a try-this-game this weekend
(up to
::then I'm covered in work) if that would be helpfull.
::
::Let me know what information you need.
::
::Nick
:
:Doesn't happen to me, but I'll try a couple more CD's.
:
: -Matt
Ok, I got a panic:
mount /cdrom
find /cdrom -type f -exec cat \{\} /dev/null \; -ls
This is with -current.
Will the ATAPI driver writer please step forward :-)
panic: vm_fault: fault on nofault entry, addr: c1d41000
db trace
Debugger...
panic
vm_fault
trap_pfault
trap
calltrap
--- trap
atapi_io
atapi_intr
wdintr(1,8000,10,10,0)
Xresume15()
--- interrupt
default_halt()
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Help! (was: Crash while newfs'ing innocent vinum volume on fresh system.)
On Wednesday, 17 March 1999 at 14:21:07 +0200, Vallo Kallaste wrote:
I have reinstalled fresh 3.1-RELEASE to the machine in question,
before swapped out two memory DIMM's to the single new 32MB one, just
to be sure it's not some kind of memory error.
This is definitely not a memory error. I wish I knew what it was,
though. In my last message I said it wasn't appropriate to copy
-CURRENT, but maybe it is: I just can't figure out how this is
happening.
Then I downloaded your newest archive for vinum installation:
vinum-4.0-CURRENT.tar.gz...
Copied the same kernel configuration file as usual to the right place
from backup. Made some minor changes to kernel configuration, removed
DMA support for ata disks, I don't trust the support very much yet.
Made new debug kernel, copied to /var/crash, stripped the original
with -g and installed. Reboot.
For just testing Vinum, you don't need to build a kernel.
Newfs -n1 -d0 -v /dev/vinum/rsvol two lines newfs output and
crash:
Script started on Wed Mar 17 13:24:45 1999
sh-2.02# gdb -k kernel.gdb vmcore.0
(kgdb) add-symbol-file /modules/vinum.ko 0x5ba8+
A syntax error in expression, near `'.
You shouldn't need to do this any more. The .gdbinit file I put in
this directory did it for you. When removing dumps, don't remove the
.gdbinit.
#9 0xf01eadba in trap (frame={tf_es = -203751408, tf_ds = -203751408,
tf_edi = -559038242, tf_esi = -2147483648, tf_ebp = -203715144,
tf_isp = -203715180, tf_ebx = -258066920, tf_edx = 16384, tf_ecx = 14,
tf_eax = -16162, tf_trapno = 12, tf_err = 0, tf_eip = -257639372,
tf_cs = 8, tf_eflags = 66182, tf_esp = -257699840, tf_ss = -245981592})
at ../../i386/i386/trap.c:437
#10 0xf0a4bc34 in ?? ()
#11 0xf0a4bae1 in ?? ()
#12 0xf0a4b8b6 in ?? ()
#13 0xf012ffec in physio (strategy=0xf0a4b808 swbuf+8322816, bp=0x0,
dev=23296, rw=0, minp=0xf01300dc minphys, uio=0xf3db8f34)
at ../../kern/kern_physio.c:113
#14 0xf0a4c97c in ?? ()
#15 0xf0162f2f in spec_write (ap=0xf3db8ef8)
at ../../miscfs/specfs/spec_vnops.c:355
These are the critical frames. With syumbols, they read:
#9 0xf01eadba in trap (frame={tf_es = -203751408, tf_ds = -203751408, tf_edi =
-559038242, tf_esi = -2147483648,
tf_ebp = -203715144, tf_isp = -203715180, tf_ebx = -258066920, tf_edx =
16384, tf_ecx = 14, tf_eax = -16162,
tf_trapno = 12, tf_err = 0, tf_eip = -257639372, tf_cs = 8, tf_eflags =
66182, tf_esp = -257699840,
tf_ss = -245981592}) at ../../i386/i386/trap.c:437
#10 0xf0a4bc34 in launch_requests (rq=0xf0a3cb00, reviveok=0)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:370
#11 0xf0a4bae1 in vinumstart (bp=0xf1569e68, reviveok=0)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:300
#12 0xf0a4b8b6 in vinumstrategy (bp=0xf1569e68) at
/usr/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:151
#13 0xf012ffec in physio (strategy=0xf0a4b808 vinumstrategy, bp=0x0,
dev=23296, rw=0, minp=0xf01300dc minphys,
uio=0xf3db8f34) at ../../kern/kern_physio.c:113
#14 0xf0a4c97c in vinumwrite (dev=23296, uio=0xf3db8f34, ioflag=1)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumrequest.c:995
#15 0xf0162f2f in spec_write (ap=0xf3db8ef8) at
../../miscfs/specfs/spec_vnops.c:355
This is a problem I've seen before, but it completely baffles me. The
request passed to launch_requests (frame 10) has been deallocated.
Some of the debug code I put in caught it:
(kgdb) p freeinfo[7]
$2 = {
time = {
tv_sec = 921669613,
tv_usec = 289712
},
seq = 24,
size = 36,
line = 174,
address = 0xf0a3cb00
ÞÀÞh\235\ðÞÀÞÀÈ£ðÞÀÞÞÀÞÞÀÞÞÀÞÞÀÞÞÀÞÞÀÞÞÀÞÞÀÞÞÀÞÞÀÞÞÀÞ,
file = vinuminterrupt.c
}
This was called from freerq, which frees the complete request. freerq
is called from only four places: one on completion of the request
(which in this case is just about to be started), one if the request
is aborted (which also sets bp-b_error, which is not set here), once
in a read context (which is not applicable here: it's a write), and
once just before the call to launch_requests in frame 11:
292 if ((status REQUEST_RECOVERED)/* can't
satisfy it */
293 ||(bp-b_flags B_DONE)) { /* XXX
shouldn't get this without bad status */
294 if (status == REQUEST_DOWN) { /* not
enough subdisks */
295 bp-b_error = EIO; /* I/O
error */
296 bp-b_flags |= B_ERROR;
297 }
298 if ((bp-b_flags B_DONE) == 0)
299 biodone(bp);
300 freerq(rq);
301 return -1;
302 }
303 return launch_requests(rq, reviveok); /* now
start the requests if we can */
[the line numbers are off by 3, but the code here is unchanged]. If
we go through this code, we will also return.
Re: How to add a new bootdevice to the new boot code ???
And it's not like anyone had to upgrade their fstab -- all of the sd devices still work, since the major number is the same. So there's not a lot of room for complaint here. Only if sysinstall goes back to creating the /dev/sd* devices and matching fstab w/``sd''. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic occurred: vm_fault
On Wed, 17 Mar 1999, Matthew Dillon wrote:
: mount /cdrom
: find /cdrom -type f -exec cat \{\} /dev/null \; -ls
:
:and pop it goes. Same stack trace. We could do a try-this-game this weekend
(up to
:then I'm covered in work) if that would be helpfull.
:
:Let me know what information you need.
:
:Nick
Doesn't happen to me, but I'll try a couple more CD's.
This panicked my machine with the first CD I tried it on - I can help with the
testing if required. It was my Windows95 CD which caused it. Hmm :-)
Kris
-
(ASP) Microsoft Corporation (MSFT) announced today that the release of its
productivity suite, Office 2000, will be delayed until the first quarter
of 1901.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
David O'Brien wrote... And it's not like anyone had to upgrade their fstab -- all of the sd devices still work, since the major number is the same. So there's not a lot of room for complaint here. Only if sysinstall goes back to creating the /dev/sd* devices and matching fstab w/``sd''. What does that have to do anything? If sysinstall is doing the work, the user doesn't have to. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
