Re: if_sis: performance tweaking

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 adequately be explained

Re: 3C940 / Asus P4P800 gigabit LAN driver

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 Zeus 3.20 [EMAIL PROTECTED

Re: mksnap_ffs, snapshot issues, again

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 adequately be explained by incompetence

Re: DEVFS related message

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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20

if_sis: performance tweaking

) +#define SIS_RXCFG128 \ + (SIS_RXCFG_DRAIN(128)|SIS_RXDMA_128BYTES) #define SIS_RXCFG64 \ (SIS_RXCFG_DRAIN(64)|SIS_RXDMA_64BYTES) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe

Re: LOR with filedesc structure and Giant

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 PICKUP_GIANT() as an acquisition of Giant, rather

Re: cdcontrol no longer needs 'c' partition?

any mail to [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 attribute to malice what can adequately be explained by incompetence

Re: LOR with filedesc structure and Giant

? -- 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. ___ [EMAIL PROTECTED

Re: clock works slowly when I change CPU speed

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 should solve this problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED

Re: Panic on my NFS server: Consumer with zero access count ing_dev_strategy

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 adequately be explained

Re: LOR with filedesc structure and Giant

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 PICKUP_GIANT() in spec_poll. Yeah, this is pretty much

Re: clock works slowly when I change CPU speed

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 [EMAIL PROTECTED] | TCP

Re: PQI 128MB USB flash drive mount problems

+*/ + {T_DIRECT, SIP_MEDIA_REMOVABLE, General Flash Disk Drive, +*, *}, + /*quirks*/ DA_Q_NO_SYNC_CACHE + } #endif /* DA_OLD_QUIRKS */ }; -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956

Re: Crash in g_dev_strategy / CURRENT as of yesterday.

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 adequately be explained by incompetence

Re: Crash in g_dev_strategy / CURRENT as of yesterday.

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 regarding crashes in g_dev_strategy under FreeBSD 5.1

Re: Bootstrap: Machine keeps booting ? (boot0/mbr) ?

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 explained by incompetence

Re: Crash in g_dev_strategy / CURRENT as of yesterday.

)bp-bio_bcount; (kgdb) Ohh, damn, I still have that stuff uncommitted. Will fix! -- 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

reproducible deadlock...

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 mutex lockmgr db -- Poul-Henning Kamp | UNIX

Re: HEADSUP: pca driver being retired.

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 by incompetence

Re: [HEADSDOWN] swap_pager.c calming down...

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@ list, the thread with subject Weird reboots from bootmgr or loader

Re: vinum lock panic at startup -current

, 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 to malice what can adequately

Re: [HEADSDOWN] swap_pager.c calming down...

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 adequately be explained by incompetence

How to do statistics on benchmarks (101)

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 to give people a simple way to check

Re: Weird reboots from bootmgr or loader

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 explained by incompetence

[HEADSDOWN] swap_pager.c calming down...

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 what can

HEADSUP: pca driver being retired.

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 FreeBSD

Re: vinum lock panic at startup -current

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 attribute to malice what can adequately be explained

mergemaster chokes on etc/sendmail

/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 malice what

Re: SAN disk with freebsd?

-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. ___ [EMAIL PROTECTED] mailing

Fix for bogus TSC timecounters.

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: Dont initialize a TSC timecounter until we know

Re: GEOM/vinum compatibility (was: vinum lock panic at startup-current)

(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] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never

Re: mdconfig feature request

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 explained by incompetence

Re: vinum problems with todays current

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 malice what can adequately be explained by incompetence

Re: panic every few hours, pmap related?

] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [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 attribute

Re: Bug in GEOM or in gstat?

http://mailbox.univie.ac.at/~le/ -- 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

locking problems with pipes ?

= 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-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP

Re: vfprintf() has a 4096-byte memory leak?

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 explained by incompetence

What is it about kern_ktr.c ?

/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 committer | BSD since 4.3-tahoe Never attribute to malice what can

Re: HEADSUP: UMA not reentrant / possible memory leak

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 quick response from JeffR this seems

Re: bsdlabel warnings

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 RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained

HEADSUP: UMA not reentrant / possible memory leak

; 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(;;) { g_bioq_lock(g_bio_run_down); -- Poul-Henning Kamp | UNIX since

Re: HEADSUP: UMA not reentrant / possible memory leak

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 workaround for this problem, until JeffR

Re: Highly loaded machine getting slower and slower

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 since 4.3-tahoe Never attribute to malice what can adequately

Re: Feasibility/Practicality of using GBDE to facilitate encryptedswap, md, /tmp, filesystems

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.3-tahoe Never attribute to malice what can

Re: Memory Mangement Problem in 5.1-RELEASE

. -- 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. ___ [EMAIL PROTECTED] mailing

Re: File system deadlock. GBDE(4) and/or MD(4) related.

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 adequately be explained by incompetence

Re: File system deadlock. GBDE(4) and/or MD(4) related.

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 explained by incompetence

Re: File system deadlock. GBDE(4) and/or MD(4) related.

. -- 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. ___ [EMAIL PROTECTED

Re: File system deadlock. GBDE(4) and/or MD(4) related.

: 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 PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never

Last inline offenders...

, drm_radeon_cmd_header_t header, drm_radeon_cmd_buffer_t *cmdbuf ) -- 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

Re: [-CURRENT tinderbox] failure on i386/i386

These false alarms are wearing a bit thin. Is there a problem with the tinderbox build machine perhaps? No, the failures are too systematic for that. Don't trust that, I've seen RAM errors be reproducible to +/- 4 instructions in the cc1 binary in the past. -- Poul-Henning Kamp | UNIX

Re: Negative bio_offset -current kernel panic

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 etc. (see handbook). -- Poul-Henning Kamp

Re: Jail Roadmap

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 FreeBSD committer | BSD since 4.3-tahoe Never

Re: Does newreno work as designed ?

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] | TCP/IP since RFC 956 FreeBSD committer

Re: Does newreno work as designed ?

/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] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe

Does newreno work as designed ?

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 3.20

Re: fsck background mode for gbde crypted disc?

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 Kamp | UNIX since

WARNING: ttyname(3)/sshd breakage fixed.

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 Modified files: lib/libc

Re: support for mounting md(4) based filesystem at boot [PATCHES]

gadget. -- 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. ___ [EMAIL

ttyname(3) review requested...

(NULL); + return(devname_r(sb.st_rdev, S_IFCHR, buf, sizeof(buf))); } -- 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

Re: support for mounting md(4) based filesystem at boot [PATCHES]

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 Never attribute to malice what can adequately

Re: GEOM_FOX

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-Henning Kamp w rites: phk 2003/06/18 02:29:28 PDT FreeBSD src repository Modified

Proof of concept patch for device rearrangement

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 4.3-tahoe Never

Re: panic: spec_specstrategy(0x3c41a000 != 0xc3419db0)

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 committer | BSD since 4.3-tahoe

kernel compile now depends on /usr/include ?

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 attribute to malice what can

HEADSUP(2): CCD GEOMified.

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:

Re: howto dump gbde partition ?

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 attribute to malice what can adequately be explained

Re: imgact_gzip.c

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 explained by incompetence

Re: geom_vol_ffs problems

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 attribute to malice what can adequately be explained by incompetence

Re: [-CURRENT tinderbox] failure on i386/i386

/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 FreeBSD committer | BSD since 4.3-tahoe

USB printing mangles printjob :-(

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 | BSD since 4.3

Re: USB printing mangles printjob :-(

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 this ? -current of course :-) If I find

Re: devfs and /dev/fd/3

produce both foo and Foo FreeBSD 5 with devfs, however, does not create a /dev/fd/3 upon opening filedescriptor 3 by the shell, so there's no device to write to... How can I fix or circumvent this, aside from mounting a ufs partition with mknod-ed files over /dev/fd ? mount fdescfs -- Poul-Henning

HEADSUP: ccd migration issue for some.

on 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

Re: devfs and /dev/fd/3

? 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 so either. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never

Re: VFS: C99 sparse format for struct vfsops

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 PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained

Re: VFS: C99 sparse format for struct vfsops

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 binding of methods that implement

Re: GEOM buildworld failure

/usr/src/lib/libgeom/geom_ctl.c /usr/src/lib/libgeom/geom_ctl.c:48:27: geom/geom_ext.h: No such file or directory mkdep: compile failed Doing a 'find' doesn't turn up the header file: pilgrim:/usr/src# find . -name 'geom_ext*' pilgrim:/usr/src# -- Poul-Henning

HEADSDOWN: You can take me out of your .procmailrc now.

:-) 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 by incompetence. ___ [EMAIL

Re: gbde Performance - 35Mb/s vs 5.2 MB/s

. I considered making the sectorsize a mandatory argument, but decided against it. Maybe I was wrong. -- 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

Re: Removing Sendmail

In message [EMAIL PROTECTED], Peter Schultz writes: I'm sorry for beating a dead horse. This is the best summary so far on this subject. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe

Re: Removing Sendmail

depends on it) and so on. The main stumblingblock is the shortage of brave souls willing to venture into make release and sysinstall. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never

Re: Removing Sendmail

/make.conf, but I could used increased visibility into what all them dang switches might do. -- 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

more robust handling of removable devices in GEOM.

This commit (hopefully) improves the situation when a media is removed quickly after it appeared. (A number of people have reported this with USB devices). There are still a couple of minor races. Poul-Henning In message [EMAIL PROTECTED], Poul-Henning Kamp writes: phk 2003/04/02 13

Re: sparc64 tinderbox failure

bus_Activate_resource.9. Stop *** Error code 2 This looks like a single bit memory error to me. Turn off bit 5 and a lowercase a turns into an uppercase A. Interesting. I saw the same thing here with last night's CVS. AOL twice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED

world@alpha børken in libatm

treated as errors *** Error code 1 /bang/src/lib/libatm/ip_checksum.c: In function `ip_checksum': /bang/src/lib/libatm/ip_checksum.c:80: warning: cast increases required alignmen t of target type *** Error code 1 *** Error code 1 *** Error code 1 -- Poul-Henning Kamp | UNIX since Zilog Zeus

Re: MAKEDEV(8) manpage

, right? Right. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED

Re: cvs commit: src/usr.sbin Makefile src/usr.sbin/gstat Makefile gstat.c

In message [EMAIL PROTECTED], Poul-Henning Kamp writes: phk 2003/03/20 12:48:41 PST Log: Add a rudimentary gstat(8) to the system. The GEOM/devstat statistics has very fine granularity and can be read with very high resolution if one wants to. This means that you can see exactly

Re: Clock running double time

In message [EMAIL PROTECTED], Kevin Oberman writes: kern.timecounter.hardware=TSC Can someone explain why TSC is preferred to i8254 (or why not)? Cheaper access better resolution. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956

Re: Clock running double time

In message [EMAIL PROTECTED], Wilko Bulte writes: On Tue, Mar 18, 2003 at 07:23:48PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Kevin Oberman writes: kern.timecounter.hardware=TSC Can someone explain why TSC is preferred to i8254 (or why not)? Cheaper access better

Re: mdconfig/mdmfs problems - kernel panic

devices with malloc backing must share the malloc-per-bucket-quota. The exact size of this quota varies, in particular with the amount of RAM in the system. The exact value can be determined with vmstat(8). -- Poul-Henning Kamp | UNIX since Zilog

Re: Anyone working on fsck?

), you might as well just stop right at the clean bit, and avoid the complexity. Optimizing fsck is a valid project, I just wish it would be somebody who would also finish the last 30% who would do it. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED

Re: Anyone working on fsck?

In message [EMAIL PROTECTED], Brad Knowles writes: At 10:39 PM +0100 2003/03/17, Poul-Henning Kamp wrote: Optimizing fsck is a valid project, I just wish it would be somebody who would also finish the last 30% who would do it. Just what are you saying? Is Julian Elischer

Re: Anyone working on fsck?

. In case anybody is in any doubt, I've heard you say this sort of thing about julian before. Please don't do it again. I'll stop as soon as KSE is finished, fair ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD

Re: panic on boot (devfs_find)

any trace of USB from your systems. USB does some ugly VOP_REVOKES which I am not happy about, and I would like to exclude them from the list of suspects. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3

Re: panic on boot (devfs_find)

In message [EMAIL PROTECTED], Krzysztof Parz yszek writes: On Sun, Mar 16, 2003 at 09:29:15AM +0100, Poul-Henning Kamp wrote: I don't think I'll stand a chance on this one until I can reproduce it on one of my machines :-( I'm not sure if that helps, but on my machine it it enough to take

Re: ENOMEM error diagnosis?

got hit by influenza and am only slowly making my way though the todo list. I'll try to get through your email this morning. ENOMEM in gbde is a tricky issue which I need to find a better solution for. What is there is at best a workaround it seems. -- Poul-Henning Kamp | UNIX since

Re: Why did INVARIANTS hide the geom bug?

In message [EMAIL PROTECTED], walt writes: If inclusion of INVARIANTS serves to disguise bugs in the kernel, I wonder if kernel committers should be using this option routinely? Please check into our current reality :-) Suggest you check what INVARIANTS actually do. -- Poul-Henning Kamp

Re: can't boot with twe anymore.

))-twed_drive-td_unit) # define TWE_BIO_SET_ERROR(bp, err)do { (bp)-bio_error = err; (bp)-bio_flags |= BIO_ERROR;} while(0) # define TWE_BIO_HAS_ERROR(bp) ((bp)-bio_flags BIO_ERROR) # define TWE_BIO_RESID(bp) (bp)-bio_resid -- Poul-Henning Kamp | UNIX since Zilog

Re: can't boot with twe anymore.

? */ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe

<    1   2   3   4   5   6   7   8   9   10   >