use information from
the optional BSD disklabel.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be e
isn't more than that at this point, we plan to talk
about it at BSDcon03 and try to settle on our strategy for the entire
area, and if we manage that we'll communicate it of course.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since
el, which didn't have an
>entry in paths.h.
>
>Any objections against me committing the follwoing fixes to
>-current ?
Yes, please don't.
We should not revert to putting BSD labels on everything.
I'll find the root cause and fix that instead, it's probably
t devices for floppy disks which will have to be done with the
fdcontrol(8) utility instead.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice wha
A parameters at all.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
riting is only needed for marking the dump as "read", the same
effect could be had much cleaner by writing the signature of the dump
to a file in /var/ somewhere and not reading dumps already in that
file.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
0x3C
#define NS_BMCR 0x80
#define NS_BMSR0x84
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by in
In message <[EMAIL PROTECTED]>, Doug Barton writes:
>On Tue, 2 Sep 2003, Poul-Henning Kamp wrote:
>
>> Hmm, that was an unfortunate side effect.
>
>Heh, well, stuff happens. I think your idea of opening swap exclusive is
>probably a good one, but it will require some g
sinstall to modify drives in use,
then the answer is probably no.
For that job you want to use the correct tools: fdisk(8) and
bsdlabel(8) (tacitly assuming i386 here).
If you are talking about a problem during initial install of FreeBSD
you need to provide more details about it.
--
Poul-Henning
Giant.
I have had a similar issue a couple of places in the giant/no-giant
shims for GEOM. I found one convenient trick was to sleep with a
timeout instead. It's not beautiful but it works.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RF
e, and I guess the best strategy is
hunting down the devbuf thing by changing all users of M_DEVBUF until
something trips...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to mali
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp
writes:
>phk 2003/08/30 09:44:27 PDT
>
> FreeBSD src repository
>
> Modified files:
>sys/vm swap_pager.c
> Log:
> Add a close() method to a swapdev.
>
> Add a GEOM base
In message <[EMAIL PROTECTED]>, Doug Barton writes:
>Poul-Henning,
>
>Please don't forget to update src/share/examples/etc/make.conf
>accordingly.
Hmm, so this stuff is documented both in make.conf(5) and an examples
file ? Sounds like one place too many to me.
ructures subsequently.
You may want to set kern.geom.debugflags=N and see if that offers
any clues.
N |= 1 topology events
N |= 2 bio processing (ie: many lines for each I/O)
N |= 4 access processing (open/close)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[
y fix, please...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EM
rmine what values are optimal.
Any input you have in that respect are most welcome (send it to sam@ and phk@)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can ad
In message <[EMAIL PROTECTED]>, Jens Rehsack writes:
>I have 2 machines with P4P800-Deluxe with the 3C940. If phk@ could fix
>the swap-issue, so that I can reboot easily, I would test your patches,
>too.
"swap-issue" ?
--
Poul-Henning Kamp | UNIX since Zilog Z
the sleep interruptible
would break all sorts of standards)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can ade
tempted allocated which can contain
more entries.
You can adjust both the regular and the overflow table sizes with
compile time constants NDEVFSINO and NDEVFSOVERFLOW.
When more of the kernel has been de-Giantized, this code can be
revisited and these constants can probably be eliminated.
--
Po
>+.It Pa /dev/acd0
> .El
> .Sh AUTHORS
> .An Jean-Marc Zucconi
>
>
>
>
>--
>Craig Rodrigues
>http://crodrigues.org
>[EMAIL PROTECTED]
>___
>[EMAIL PROTECTED] mailing list
>http://lists.freebsd.org/m
In message <[EMAIL PROTECTED]>, David Malone writes:
>On Sat, Aug 16, 2003 at 10:18:43PM +0200, Poul-Henning Kamp wrote:
>> At one point we have to say "Well, the locks we have above are solid,
>> but we need to drop Giant below here" but if Witness sees a
>>
0
#define SIS_RXDMA_256BYTES 0x0070
-#define SIS_RXCFG256 \
- (SIS_RXCFG_DRAIN(64)|SIS_RXDMA_256BYTES)
+#define SIS_RXCFG128 \
+ (SIS_RXCFG_DRAIN(128)|SIS_RXDMA_128BYTES)
#define SIS_RXCFG64 \
(SIS_RXCFG_DRAIN(64)|SIS_RXDMA_64BYTES)
--
Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Robe
rt Watson writes:
>
>On Sat, 16 Aug 2003, Poul-Henning Kamp wrote:
>
>> >> The problem seems to be due to select() being called on the /dev/null
>> >> device, and it is holding the filedesc lock when it reaches
>>
fter it has been closed. I am not sure
how this is possible, the mountpoint should be long gone etc.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can ade
t;TSC" frequency 1595302164 Hz
>| $ sysctl -w kern.timecounter.hardware=i8254
>| Fixes the problem for me. I suspect you should set this in
>| /etc/sysctl.conf to enable it permanently.
>
>Thank you for your advice.
I've given timecounters "qualities" which sho
x27;t this effectively doom any attempt at getting rid af Giant
from below ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attri
h Disk Drive 2.05
+* Serial Number ST92163-2000
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, "General Flash Disk Drive",
+"*", "*"},
+ /*quirks*/ DA_Q_NO_SYNC_CACHE
+ }
#endif /* DA_OLD_QUIRKS */
};
In message <[EMAIL PROTECTED]>, MATOBA Hirozumi wri
tes:
>On condition of hw.acpi.cpu.performance_speed as 8,
>the clock works
You should not be using the TSC for timekeeping if you change the
frequency of it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMA
oking at
>it now and will probably be committing a fix.
Already committed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be ex
In message <[EMAIL PROTECTED]>, Eivind Olsen writes:
>--On 12. august 2003 21:26 +0200 Poul-Henning Kamp <[EMAIL PROTECTED]>
>wrote:
>> In message <[EMAIL PROTECTED]>, Eivind Olsen writes:
>>> Hello. Some of you might have seen my previous mailings regardi
Can you try to print out the bp->b_dev structure
if you still have the dump ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adeq
/etc.
*** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to
the temproot environment
critter#
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to m
I plan to remove the pca driver in about a week.
Protest only from actual users respected.
If you don't know what pca is or what it does, do not even send email.
Thank you!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
Fr
ather than take the detour over vnodes and specfs.
This will not happen in the first couple of weeks I suspect.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice wha
the disklabel, and you should be happy again.
We actually have a swapoff(8) these days.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be ex
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp
writes:
>phk 2003/08/13 00:21:54 PDT
>
> FreeBSD src repository
>
> Added files:
>tools/tools/ministat Makefile README chameleon iguana
> ministat.c
I just added this small tool
y wrong thing to
do, and it seems that vinum does not respect the D_NOGIANT
flag which GEOM recently started setting.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
In message <[EMAIL PROTECTED]>, Lukas Ertl writes:
>On Wed, 6 Aug 2003, Poul-Henning Kamp wrote:
>
>> In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>> >Hello Poul,
>> >
>> >Can you please look into problems reported on current@ li
ics.
> I changed the /etc/rc.conf
>start_vinum="YES" to NO and can start ok now.
What was the actual panic message ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never a
off
up to 2 interrupts per second.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
There is no way my work could cause reboots from the bootmgr or loader.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequate
lproc -- (already displayed)
Spin locks:
Locks which were never acquired:
rip
pseudofs_fileno
msq
semid
cd9660_ihash
msdosfs dehash
bpf interface lock
ACPI global lock
taskqueue
strategy
bounce pages lock
jumbo mutex
securelevel mutex lock
UUID generator mutex lock
umtx
phys_pager list
vm map sleep
bp2->bio_offset = (off_t)bp->bio_blkno << DEV_BSHIFT;
>402 KASSERT(bp2->bio_offset >= 0,
>403 ("Negative bio_offset (%jd) on bio %p",
>404 (intmax_t)bp2->bio_offset, bp));
>405 bp2->bio_length = (off_t)bp->bio
h Matt Jacob maintains.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
__
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp
writes:
>phk 2003/08/06 08:05:28 PDT
>
> FreeBSD src repository
>
> Modified files:
>sys/i386/i386tsc.c
>sys/i386/include clock.h
>sys/i386/isa clock.c
> Log:
> Don
ght have been
renamed or have multiple names.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be e
as being more beneficial to the project.
>Could you please give details (privately if you want, but I think this
>could be of interest to other people too).
See sys/fs/specfs/specfs_vnops.c, that is probably faster.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
PICKUP_GIANT();
+ /* PICKUP_GIANT(); */
} else
DEV_STRATEGY(bp);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to mali
;frame=0x0) at /usr/src/sys/kern/kern_fork.c:794
> td = (struct thread *) 0x0
> p = (struct proc *) 0xc6139d3c
>(kgdb) quit
>[EMAIL PROTECTED] crash]# exit
>
>Script done on Mon Aug 4 23:58:35 2003
>
>--
>Lukas Ertl eMail: [EMAIL PROTECTED]
syscall+0x273
Xint0x80_syscall() at 0xc032e23d = Xint0x80_syscall+0x1d
--- syscall (6), eip = 0x80b2edb, esp = 0xbfbff69c, ebp = 0xbfbff6a8 ---
Debugger("witness_lock")
Stopped at 0xc032cab4 = Debugger+0x54: xchgl %ebx,0xc0432164 = in_Debugger.0
db> cont
--
Poul-Henni
temadministrator Tel.: (+43 1) 4277-14073
>Vienna University Computer Center Fax.: (+43 1) 4277-9140
>University of Vienna http://mailbox.univie.ac.at/~le/
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TC
ion it appears in.)
>/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:270:
>warning: unused variable `c'
>*** Error code 1
What gives ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD commit
lem for you, the above is the workaround.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be
the disk has been labeled by previous
>versions and upgraded from source.
That sounds interesting. Can you send me the outout of:
diskinfo /dev/ad0*
sysctl -b kern.geom.confxml
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RF
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes:
>
>[I'm CC'ing current because this seems to have a significant negative
>impact on -current kernel stability, and we can use some more data,
>in particular on non-i386 SMP machines]
OK, thanks to a very qu
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes:
>
>[I'm CC'ing current because this seems to have a significant negative
>impact on -current kernel stability, and we can use some more data,
>in particular on non-i386 SMP machines]
I just committed a workar
bp2->bio_cmd = bp->bio_cmd;
bp2->bio_length = bp->bio_length;
@@ -304,6 +325,7 @@
bzero(&mymutex, sizeof mymutex);
mtx_init(&mymutex, "g_xdown", MTX_DEF, 0);
+ mtx_init(&gbiomutex, "gbio", MTX_DEF, 0);
for(;;)
date
sysctl kern.malloc
sysctl vm.zone
swapinfo
ps -axlw
and look out for anything which just gobbles up more and more
memory.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD sinc
ice is init'ed and attached but the
master key and lock sector is never written to the device. This
is the mode you want to use for paging devices.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4
will not get paged in. I often see the getty's for
the vty's and similar junk on my swap space.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD sin
ing vnode backed md(4) devices is sort of incestuous, and that may
be what happens here: For certain operations it is necessary to lock
all the way to the top of the filesystem, and this may be what results
in a deadlock for you now.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PRO
d MD(4) devices
(and vn(4) devices before that).
One way or another: It is _not_ a GBDE problem.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
with GBDE, I think it is the
usual "vnode backed md(4)" deadlock.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be exp
tee you that it is
_not_ gbde that holds references on vnodes. GBDE doesn't even know
what a vnode is.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
-1871,7 +1871,7 @@
return 0;
}
-static __inline__ int radeon_emit_vectors(
+static int radeon_emit_vectors(
drm_radeon_private_t *dev_priv,
drm_radeon_cmd_header_t header,
drm_radeon_cmd_buffer_t *cmdbuf )
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROT
ve seen RAM errors be reproducible to +/- 4 instructions
in the cc1 binary in the past.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explaine
jails.
So right now we havn't quite appointed a new maintainer for jails,
but we're very much aware that something needs to move, possibly
"us out of the way".
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeB
In message <[EMAIL PROTECTED]>, "Aaron Wohl" writes:
>I got a got this kernel panic:
>geom/geom_dev.c:("Negative bio_offset (%jd) on bio %p",
>
>Anyone seeing this also?
Please put DDB in your kernel and try to reproduce, then capture
traceback
true > /dev/da0
(for correct value of 0 obviously)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes:
>Andrew Kenneth Milton wrote:
>> +---[ Poul-Henning Kamp ]--
>> |
>> | I think we need somebody to reconsider how we configure our filesystems
>> | in the future, in order
t I suspect he is too busy to actively steer the issue too.
Of course, I can't resist a pun when it presents itself so
directly, so:
JAIL maintainer wanted.
(apply within)
:-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since R
In message <[EMAIL PROTECTED]>, Sean Kelly writes:
>On Tue, Jul 08, 2003 at 10:35:47PM +0200, Poul-Henning Kamp wrote:
>>
>> Can you try this patch ?
>
>...
>> diff -u -r1.28 geom_dump.c
>> --- geom_dump.c 11 Jun 2003 06:49:15 - 1.28
>> +
b, " %s\n", gp->name);
sbuf_printf(sb, " %d\n", gp->rank);
- if (gp->dumpconf != NULL) {
+ if (gp->flags & G_GEOM_WITHER)
+ sbuf_printf(sb, " \n");
+ else if (gp->dumpconf != NULL) {
rtition c may cause problems for standard system utilities
>
>FWIW, this drive contains an OpenBSD 2.7 installation. All partitioning
>was done by the OpenBSD installer.
Can you mail me the output of:
diskinfo -v da0
diskinfo -v da0s4
dd if=/dev/da0 cou
packet trace for you.
> http://people.freebsd.org/~hsu/tmp/explicitnewreno.diff
>and see if it affects your web-surfing experience.
If this is the patch you mailed me yesterday, I'm already running
with it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
as any effect on the problem you're seeing.
Pressuming that is the same patch you sent me in email yesterday:
I think it made a positive difference, but things still seem to
work better with newreno disabled.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
I'm sitting on a ISDN line right now, and I thought the newreno issues
had been solved, but by disabling newreno I get a distinctly better
web-surfing experience.
Is newreno working as designed right now, and if not, who is fixing it ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus
In message <[EMAIL PROTECTED]>, Christophe Zwecker writes:
>Hi
>
>I wonder if I can do a background check after mounting an crypted part
>or does the check have to be b4 ?
That should just work, a filesystem on GBDE is no different than any
other filesystem.
--
Poul-Henning
If you reinstalled libc with the previous version of ttyname.c your
sshd will likely get confused and refuse access.
Apologies...
Poul-Henning
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp
writes:
>phk 2003/06/21 01:16:12 PDT
>
> FreeBSD src repository
>
continue;
- (void)closedir(dp);
- return (buf);
- }
- (void)closedir(dp);
- return (NULL);
+ return(devname_r(sb.st_rdev, S_IFCHR, buf, sizeof(buf)));
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TC
ust one single file in a human+program parseable format, rather
than having to have one file per "gadget".
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since
devices, we have FSCK, UFS and NFS and
other filesystems to mount.
Somebody must be able to come up with some creative stuff here... ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
d with this code enabled, it is possible to go from userland to
device driver without touching Giant underway.
Comments and test-results are most welcome!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since
# remove the primary
mdconfig -d -u 10
# fsck it again
fsck_ffs /dev/md10.fox
# Remove the primary and only path
mdconfig -d -u 30
# See what's left (hopefully nothing)
ls -l /dev/md*
In message <[EMAIL PROTECTED]>, Poul
xc3419db0)
>
>This problem did not occur with a kernel from the previous day (June 14).
You hit a bad point in time, right between me botching things up and
me fixing it again.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
ere/sys/modules/netgraph.
*** Error code 1
Stop in /bang/somewhere/sys/modules.
*** Error code 1
Stop in /bang/somewhere/sys/i386/compile/LINT.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attr
>how can I back it up ?
That should have worked.
You need to grab hold of our UFS/FFS utility-wrangler: [EMAIL PROTECTED]
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attrib
I've done the deed, remember to update your ccdconfig(8) with your
kernel.
Poul-Henning
phk 2003/06/09 12:25:07 PDT
FreeBSD src repository
Modified files:
.UPDATING
sys/conf files
sbin/ccdconfig ccdconfig.c
Removed files:
s
RRENT/i386/i386/src/sys/geom/geom.h:175: previous
>declaration of `g_dev_print'
>*** Error code 1
This is a pretty amazing race, those two files were committed together...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeB
e that magicness throughout, but due to the absolute
diskoffset bogosity, we cannot dethaumagize it entirely yet.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attri
At least originally imgact_gzip.c was heavily a.out aware.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be expl
In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>On Thu, Jun 05, 2003 at 12:16:56PM +0200, Poul-Henning Kamp wrote:
>>
>> While testing my dads HP 880C printer, I found out that our USB printing
>> mangles printjobs.
>
>stable or current?
Where did I mail th
it prints
perfectly. If I send it via USB/ulpt there are corrupted bytes in
the job which mess up the printout in various ways.
I don't have time to hunt this down.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
10: Mon May 12 15:30:54 CEST 2003
>[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TURTLE i386
>
>Btw. Why isn't this default mounted together with devfs in /etc/rc.d ?
>Is it not yet stable enough ?
There is no reason not to, but there seems, on the other hand, to
not be enough reason to do
a ccd volume, in which case
you would do well in squirilling away a copy of the old ccdconfig(8)
binary along with your fall back kernel.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
ent this, aside from mounting a ufs partition
>with mknod-ed files over /dev/fd ?
mount fdescfs
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can ad
In message <[EMAIL PROTECTED]>, Paul Richards wr
ites:
>On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote:
>> I thought the point in KOBJ was that it was extensible so you could
>> KLD load stuff which added more methods ?
>
>Not exactly. It allows for dynamic bindin
x27;t change and therefore we know a-priori how many methods there can
>> be so we can pre-allocate an array.
I thought the point in KOBJ was that it was extensible so you could
KLD load stuff which added more methods ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTE
pilgrim:/usr/src# find . -name 'geom_ext*'
> pilgrim:/usr/src#
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
the other trees :-)
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
401 - 500 of 1791 matches
Mail list logo
