Re: ELF interpreter /co not found
The above message is what I get after upgrading from an August 7 to an August 17 world/kernel and trying to run linux-netscape47-communicator. Prior world/kernel combination worked okay, there have been no changes to the kernel configuration (which I can provide if required). Hey, I noticed the same. I thought it was me, because I started using the linux.ko module instead of compiling it into the kernel with COMPAT_LINUX. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Disabling harmful keys (was: Re: PATCH: syscons.c sysctl for PC-Reboo Keys)
I posted the following message in the stable ML the other day, but got no response. So, I will post it here again. Please follow the thread PATCH: syscons.c sysctl for PC-Reboo Keys in the stable ML for background information on this subject. Kazu As we have seen so many people expressing so many opinions on this subject, I shall summarize the current status of disabling special keys, such as Ctl-Alt-Del, and propose a compromise. 1. Current status In addition to the Reboot key, we have some other harmful or dangerous keys. Keys considered harmful: Reboot, Panic, Debugger, Halt, Power Down Suspend and Stand-by keys may also be considered harmful? In our default keymaps in /usr/share/syscons/keymaps, we have Suspend, Reboot and Debugger keys in almost all keymaps. Halt, and Panic keys are defined in some keymaps. (I wonder how do we come to have this much differences in the keymaps. I thought they were at some point made to have common special key definitions...) Power Down and Stand-by keys are not defined in any. For controlling the behavior of those keys, we have the following. Kernel options: SC_DISABLE_REBOOT (for Reboot, Halt, Power Down keys) SC_DISABLE_DDBKEY (for Debugger key) Sysctl variable: machdep.enable_panic_key (for Panic key) We also have the following kernel option to disable loading of key maps. KBD_DISABLE_KEYMAP_LOAD 2. Proposition In order to not have too many kernel options and sysctl variables to control individual keys, I shall propose the following compromise. - - One kernel option to permanently disable all harmful keys. SC_DISABLE_HARMFUL_KEYS - - One sysctl variable to enable/disable individual harmful keys. machdep.disable_harmful_keys This is a bitmap in which you set a bit to disable corresponding harmful key. bit 0: Reboot bit 1: Halt bit 2: Power Down bit 3: Debugger bit 4: Panic The initial value is 0; all keys are enabled. This sysctl variable has no effect if SC_DISABLE_HARMFUL_KEYS is defined. I wouldn't like to make this sysctl variable tunable, as anyone at the boot loader prompt will be able to change it if it's tunable. If it remains a regular sysctl variable, only the root can modify it. 3. Notes Both the kernel option and the sysctl variable can be modifiable only by the root. We should remember that neither of the kernel option and the sysctl variable will be able to prevent the user from hitting the reset button on your system :-) (Oh, yes, you need to update /etc/ttys so that all ttys to be insecure, otherwise your inquisitive user can become root without the root password by hitting the reset switch and booting into the single-user mode... Yes, you know that :-) As for keymaps, KBD_DISALBE_KEYMAP_LOAD should be sufficient. I don't find it a good idea to add any other options or something else, as I think that it is the behavior of the key that matters, rather than its presence in the keymap. There was suggestion that we shall automatically disable all harmful keys if securelevel has been raised. I don't know if it is desirable. Someone may also argue that there should be a way to make these keys take effect only if the keys are hit by the root. I think it's difficult to implement this scheme. When a key is hit, we don't know, at that point, to which process the key stroke will be directed, and which process will eventually eat it... Comments? Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Disabling harmful keys (was: Re: PATCH: syscons.c sysctl for PC-Reboo Keys)
* Kazutaka YOKOTA [EMAIL PROTECTED] [010818 03:02] wrote: I posted the following message in the stable ML the other day, but got no response. So, I will post it here again. Please follow the thread PATCH: syscons.c sysctl for PC-Reboo Keys in the stable ML for background information on this subject. I really like this, however I think that the sysctl section is a bit too complicated, even though it's somewhat gross it would make sense to have: machdep.enable_harmful_keys where the user can choose to assign 0xff to enable all, or leave it at zero to leave them all disabled. In fact if you're up to the work, you could make several sysctl_proc nodes for each 'harmful' key such that it updates the bitmask 'machdep.enable_harmful_keys' when set. kern.console.keymap.enable_reboot kern.console.keymap.enable_ddb etc. Oh, why put it under 'machdep'? It may be machine dependant which keys are used however the result is them same, hence the 'kern.console' or maybe even just a new sysctl subtree 'console'? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Disabling harmful keys (was: Re: PATCH: syscons.c sysctl for PC-Reboo Keys)
I really like this, however I think that the sysctl section is a bit too complicated, even though it's somewhat gross it would make sense to have: machdep.enable_harmful_keys where the user can choose to assign 0xff to enable all, or leave it at zero to leave them all disabled. In fact if you're up to the work, you could make several sysctl_proc nodes for each 'harmful' key such that it updates the bitmask 'machdep.enable_harmful_keys' when set. kern.console.keymap.enable_reboot kern.console.keymap.enable_ddb My intention was that we shall not have too many sysctl variables and kernel options. In order to present friendly interface to this sysctl variable, we can have a variable in /etc/rc.conf, disable_harmful_keys=reboot halt powerdown panic (or enable_harmful_keys=debug) and a script in /etc/rc.syscons to process it. We can also add new options to kbdcontrol. kbdcontrol -E debug kbdcontrol -D reboot -D halt -D powerdown -D panic (or kbdcontrol -D reboot halt powerdown panic) etc. Oh, why put it under 'machdep'? It may be machine dependant which keys are used however the result is them same, hence the 'kern.console' or maybe even just a new sysctl subtree 'console'? I thought device driver related variables are under `machdep', aren't they? Also note that they key actions are for syscons, not for pcvt. Oh, well. Looking at `sysclt -a' now, we don't appear to be following strict rules... I like kern.console. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: psmintr: out of sync (was: Re: FreeBSD's aggressive keyboard probe/attach)
Anyway, I am now considering the following experiment. - We make the psm driver count the number of the out-of-sync errors. - When the error is detected for the first time, the psm driver will throw few data bytes (up to entire packet size) and see if it can get back to sync. - If the error still persists, the psm driver disable/enable the mouse and see if it works. - If the error still persists and the count goes up to N (10 or 20?), the psm driver reset and reinitialize the mouse. The counter is reset to zero. Too complicated? Kazu Ok, here is an experimental patch. It tries to implement the above scheme. http://people.freebsd.org/~yokota/psm-out-of-sync.diff.gz It also discards an incomplete data packet when the interval between two consequtive bytes are longer than pre-defined timeout (2 seconds in this patch). The last byte which arrived late will be regarded as the first byte of a new packet. This is louie's idea. Watch out for the followin messages: psmintr: delay too long; resetting byte count psmintr: out of sync (%04x != %04x) psmintr: discard a byte (%d) psmintr: re-enable the mouse psmintr: reset the mouse Please test if you are suffering from the out-of-sync errors! Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
is 'suspend' broken in CURRENT?
I have sony vaio z505hs. I have latest cvs-tree. suspend worked 1-2 weeks ago but now when I want to resume from suspend-mode I see the same screen I saw before suspend but keyboard doesn't work and harddisk doesn't spin. -- bye Juriy Goloveshkin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Fri, 17 Aug 2001, David O'Brien wrote:
On Wed, Aug 15, 2001 at 12:40:19PM +1000, Bruce Evans wrote:
On Tue, 14 Aug 2001, Ruslan Ermilov wrote:
On Tue, Aug 14, 2001 at 08:55:56AM -0700, David O'Brien wrote:
From a correctness stand point, building the .mgc files at install time
is the correct thing to do... or maybe we should do both -- doing the
[re]creation of the .mgc files at install time in the cross-[arch-]build
case.
Not both.
Which do you prefer? The CC_HOST way, the build-tools way, or the at
install time way?
build-tools.
+build-tools: mkmagic
+
+mkmagic: apprentice.c print-hacked.c
+ ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
+ -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
This should use CFLAGS if possible, and should use LDFLAGS, something
like:
${CC} -DCOMPILE_ONLY {CFLAGS} ${LDFLAGS} -o ${.TARGET} ${.ALLSRC}
The include path in CFLAGS is wrong for this:
-I/FBSD/5.x/usr.bin/file -I/FBSD/5.x/usr.bin/file/../../contrib/file
-I/usr/obj/FBSD/5.x/i386/usr/include
namely pointing into /usr/obj.
The extra directory seems to be a bug elsewhere. bsd.lib.mk and
bsd.prog.mk add -I${DESTDIR}/usr/include to CFLAGS if DESTDIR is set.
This is the wrong place to add it, but /usr/src/Makefile.inc1 relies
on this for the WMAKEENV (world) stage. Makefile.inc1 also sets DESTDIR
for the BMAKEENV (bootstrap-tool) and XMAKEENV (cross-tools) stages.
I think this breaks these stages if NOCLEAN is set (if NOCLEAN is not
set, then the extra include dir is cleaned early, and it remains
unpopulated until the WMAKEENV stage). I think this is not broken for
the TMAKEENV (build-tools) stage unless DESTDIR is set externally
(and NOCLEAN is set). You saw the extra include dir for the `file'
build-tool because you set DESTDIR externally.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic: ffs_blkfree: freeing free block / + UDMA ICRC error with ad0
Hi,
-current as of Aug 16, ~2pm CEST:
---snip---
IdlePTD 4812800
initial pcb at 305f60
panicstr: bremfree: bp 0xc69e0748 not locked
panic messages:
---
panic: ffs_blkfree: freeing free block
panic: from debugger
[...]
#0 dumpsys () at ../../../kern/kern_shutdown.c:479
#1 0xc01baf11 in boot (howto=260) at ../../../kern/kern_shutdown.c:322
#2 0xc01bb32a in panic (fmt=0xc02ba51e bremfree: bp %p not locked)
at ../../../kern/kern_shutdown.c:601
#3 0xc01ed20e in bremfree (bp=0xc69e0748) at ../../../kern/vfs_bio.c:479
#4 0xc01eeb7a in getnewbuf (slpflag=0, slptimeo=0, size=8192, maxsize=8192)
at ../../../kern/vfs_bio.c:1632
#5 0xc01ef8d1 in getblk (vp=0xd063eec0, blkno=64, size=8192, slpflag=0,
slptimeo=0) at ../../../kern/vfs_bio.c:2244
#6 0xc01ed2ef in breadn (vp=0xd063eec0, blkno=64, size=8192, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0xc049ae10)
at ../../../kern/vfs_bio.c:537
#7 0xc01ed2b4 in bread (vp=0xd063eec0, blkno=64, size=8192, cred=0x0,
bpp=0xc049ae10) at ../../../kern/vfs_bio.c:519
#8 0xc0228650 in ffs_update (vp=0xd063eda0, waitfor=0)
at ../../../ufs/ffs/ffs_inode.c:101
#9 0xc023601f in ffs_fsync (ap=0xc049ae8c) at ../../../ufs/ffs/ffs_vnops.c:292
#10 0xc0233f9f in ffs_sync (mp=0xc1870400, waitfor=2, cred=0xc0e61d00,
p=0xc0337000) at vnode_if.h:441
#11 0xc01fc2e1 in sync (p=0xc0337000, uap=0x0)
at ../../../kern/vfs_syscalls.c:620
#12 0xc01baa37 in boot (howto=256) at ../../../kern/kern_shutdown.c:231
#13 0xc01bb32a in panic (fmt=0xc02cfc5e %s)
at ../../../kern/kern_shutdown.c:601
#14 0xc0276c90 in trap_fatal (frame=0xc049afa8, eva=794529)
at ../../../i386/i386/trap.c:935
#15 0xc02769c9 in trap_pfault (frame=0xc049afa8, usermode=0, eva=794529)
at ../../../i386/i386/trap.c:849
#16 0xc027615c in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 3557,
tf_esi = 20371, tf_ebp = 24, tf_isp = -1068912684, tf_ebx = 8,
tf_edx = 145, tf_ecx = 3, tf_eax = 1544, tf_trapno = 12, tf_err = 4,
tf_eip = 8097, tf_cs = 49152, tf_eflags = 721410, tf_esp = 4030,
tf_ss = 0}) at ../../../i386/i386/trap.c:408
#17 0x1fa1 in ?? ()
Cannot access memory at address 0x18.
---snip---
Transcript of the console message:
---snip---
ad0s2e: UDMA ICRC error: reading fsbn 61053200 of 27057504-27057535
(ad0s2e bn 61053200; cn 4037 tn 218 sn 26) retrying
dev = ad0s2e, block = 6885944, fs = /big
panic: ffs_blkfree: freeing free block
---snip---
This happened after issuing a shutdown -h now, after the
waiting 60 seconds message, before the display of the uptime.
My sysctl.conf:
---snip---
vfs.vmiodirenable=1
net.inet.tcp.slowstart_flightsize=3
---snip---
My dmesg:
---snip---
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #21: Thu Aug 16 16:01:53 CEST 2001
[EMAIL PROTECTED]:/big/usr/src/sys/i386/compile/WORK
Timecounter i8254 frequency 1193182 Hz
Timecounter TSC frequency 801838143 Hz
CPU: AMD Duron(tm) Processor (801.84-MHz 686-class CPU)
Origin = AuthenticAMD Id = 0x631 Stepping = 1
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
AMD Features=0xc044b18,AMIE,DSP,3DNow!
real memory = 268369920 (262080K bytes)
avail memory = 256524288 (250512K bytes)
Preloaded elf kernel kernel at 0xc0478000.
Preloaded elf module cd9660.ko at 0xc04780a8.
Preloaded elf module msdosfs.ko at 0xc0478148.
Preloaded elf module ntfs.ko at 0xc04781e8.
Preloaded elf module procfs.ko at 0xc0478284.
Preloaded elf module linux.ko at 0xc0478324.
Preloaded elf module miibus.ko at 0xc04783c4.
Preloaded elf module if_xl.ko at 0xc0478464.
Preloaded elf module snd_pcm.ko at 0xc0478504.
Preloaded elf module snd_es137x.ko at 0xc04785a4.
Preloaded elf module snd_via82c686.ko at 0xc0478648.
Preloaded elf module usb.ko at 0xc04786f0.
Preloaded elf module agp.ko at 0xc047878c.
Preloaded elf module accf_data.ko at 0xc0478828.
Preloaded elf module accf_http.ko at 0xc04788cc.
Preloaded elf module random.ko at 0xc0478970.
Preloaded elf module atspeaker.ko at 0xc0478a10.
Preloaded elf module joy.ko at 0xc0478ab4.
Pentium Pro MTRR support enabled
VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc0319f17 (1000117)
VESA: 3dfx Interactive, Inc.
Using $PIR table, 9 entries at 0xc00fdd00
acpi0: BIOSTA AWRDACPI on motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0
acpi_cpu0: CPU on acpi0
acpi_button0: Power Button on acpi0
acpi_button1: Sleep Button on acpi0
acpi_pcib0: Host-PCI bridge on acpi0
pci0: PCI bus on acpi_pcib0
agp0: VIA Generic host to PCI bridge mem 0xd000-0xd3ff at device 0.0 on pci0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: display, VGA at 0.0 (no driver attached)
isab0:
Re: no new snapshot onftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/
Hi Makoto, the 5.0-current snapshots on current.jp.freebsd.org are not updated since 3-Aug-2001. What happens? -Wolfram wosch What happens? Is -current now so unstable that we cannot make a wosch snapshot anymore? current.jp.FreeBSD.org is for you until current.freebsd.org is back again; it's not a *mirror*, but has almost same features. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
block device required
Now, this may be the wrong way to do it: # mount -oro -t msdos /dev/ugen0 /mnt But the error message is certainly misleading. Especially, since the are no block devices in -current any more :) msdosfs: /dev/ugen0: Block device required -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NEWCARD support for aironet driver an(4) (kern/24854)
On Fri, Aug 17, 2001 at 01:11:03AM -0700, Sam Habash wrote: Any good reason why the the patch in this PR hasn't yet been committed to the tree? Can you clearify exactly what the problem is under newcard? Or is it just not supporting the newcard interface? I'm using my aironet (340) card under newcard without any problems. Of course, I'm running a patched newcard which fixes the reinsertion problem. (available at http://people.freebsd.org/~jon/newcard.patch.3) I'll get that committed when I get it mostly style(9) complient. Incidentally, does anyone know of a place which sells the LMC352 (pccard version of the 350 without built in antenna) in units of one at a reasonable price? I'm using the LMC342 right now and could almost kill for the increased power. But all the online stores I've seen either don't carry them or sells them in packs of 20... -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
microuptime() went backwards
Should I worry about this: [...] Aug 18 11:11:51 aldan /boot/mi/kernel: calcru: negative time of -1781452130 usec for pid 352 (setiathome) Aug 18 11:17:10 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 - 442731.165931) Aug 18 11:17:10 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 - 442731.166366) Aug 18 11:17:11 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 - 442732.324086) Aug 18 11:17:11 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 - 442732.324293) Aug 18 11:17:12 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 - 442732.814924) Aug 18 11:17:13 aldan /boot/mi/kernel: calcru: negative time of -1498577479 usec for pid 352 (setiathome) ? Thanks, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: block device required
On Sat, Aug 18, 2001 at 11:02:04AM -0400, Mikhail Teterin wrote: Now, this may be the wrong way to do it: # mount -oro -t msdos /dev/ugen0 /mnt But the error message is certainly misleading. Especially, since the are no block devices in -current any more :) msdosfs: /dev/ugen0: Block device required ugen is a generic usb device and not a disk. What you need is umass. Nevertheless the error message is wrong as there a no block devices anymore. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: no new snapshotonftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/
wosch the 5.0-current snapshots on current.jp.freebsd.org are not updated wosch since 3-Aug-2001. What happens? Really? lrwxr-xr-x 1 root ftp 27 Aug 10 17:19 5-LATEST - 5.0-CURRENT-20010810-JPSNAP The last successfully finished release should be Aug/10/2001. Current 5-current release is broken, since KerberosIV-enabled src/gnu/usr.bin/cvs is broken as follows: cc -O -pipe -I/usr/src/gnu/usr.bin/cvs/cvs -I/usr/src/gnu/usr.bin/cvs/cvs/../lib -DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/diff -DHAVE_KERBEROS -DHAVE_KRB_GET_ERR_TEXT -DENCRYPTION-c /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c: In function `start_tcp_server': /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: `client_sai' undeclared (first use in this function) /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: (Each undeclared identifier is reported only once /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: for each function it appears in.) /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4151: warning: passing arg 6 of `krb_sendauth' discards qualifiers from pointer target type *** Error code 1 Sorry I don't know how to fix. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: is 'suspend' broken in CURRENT?
I have sony vaio z505hs. I have latest cvs-tree. suspend worked 1-2 weeks ago but now when I want to resume from suspend-mode I see the same screen I saw before suspend but keyboard doesn't work and harddisk doesn't spin. FYI: I see this on my z505(ls??) running 4.3-STABLE from a few months ago. Not only does the keyboard/mouse freeze, the whole machine is generally locked up and unpingable. brad To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: block device required
On 18 Aug, Bernd Walter wrote: On Sat, Aug 18, 2001 at 11:02:04AM -0400, Mikhail Teterin wrote: Now, this may be the wrong way to do it: # mount -oro -t msdos /dev/ugen0 /mnt But the error message is certainly misleading. Especially, since the are no block devices in -current any more :) msdosfs: /dev/ugen0: Block device required ugen is a generic usb device and not a disk What you need is umass . Yes, I figured that by now. For some reason, the umass0 was NOT created, when I attached this Flash Card Reader, even after manually kldloaded umass.ko -- only the ugen0 (and .[123]). But that's a different story. Nevertheless the error message is wrong as there are no block devices anymore. Yes, that was my point :) -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: help! su(1) is still broken
There is a recen-ish fix that may sort this out. Re-sup and build again... M I cvsupped earlier in the week (august 9th) for the first time in about 3 weeks. The pam changes seem to have broken su on my machine. I'm using the default pam.conf (via mergemaster), so I would assume that it should work. I can't seem to tweak it into behaving. I searched the list, but moving libpam to /compat/lib didn't work for me. The best clue so far is the contents of my security log (I turned on debugging). pam_wheel seems to be working, but pam_unix blows in completely: Aug 16 12:06:07 su: pam_unix: pam_sm_authenticate: Options processed Aug 16 12:06:07 su: pam_unix: pam_sm_authenticate: Got user: toor Aug 16 12:06:07 su: pam_unix: pam_sm_authenticate: Doing real authentication Aug 16 12:06:10 pam_unix: pam_sm_authenticate: Got password Aug 16 12:06:10 su: pam_unix: pam_sm_authenticate: Encrypted passwords are: **NuIxEpaVQeE * Aug 16 12:06:10 su: pam_unix: pam_sm_authenticate: returning PAM_AUTH_ERR I trimmed the lines a little. The thing that makes no sense here is that I'm using md5 passwords. When I login as toor on the console, pam_unix does the right thing. So perhaps it some sort of bizarre crypto problem. I really don't know where to go next, or what to zap and re-build, so any suggestions would be greatly appreciated. -- Robert Sexton, [EMAIL PROTECTED] No one told me that it could not be done, and so I did it. - Jack Kloepfer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: block device required
On Sat, Aug 18, 2001 at 11:02:04AM -0400, Mikhail Teterin wrote: Now, this may be the wrong way to do it: # mount -oro -t msdos /dev/ugen0 /mnt But the error message is certainly misleading. Especially, since the are no block devices in -current any more :) msdosfs: /dev/ugen0: Block device required This is caused by the kernel returning ENOTBLK, which I think still makes sense in the kernel. It's possible that the errno should be translated to a different string though... David. ./fs/hpfs/hpfs_vfsops.c:err = ENOTBLK; ./fs/ntfs/ntfs_vfsops.c:err = ENOTBLK; ./i386/ibcs2/ibcs2_errno.c: IBCS2_ENOTBLK, /* 15 */ ./kern/vfs_aio.c: if (error == ENOTBLK) ./kern/vfs_subr.c: *errp = ENOTBLK; ./kern/vfs_subr.c: *errp = ENOTBLK; ./compat/svr4/svr4_sysvec.c:SVR4_ENOTBLK, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: block device required
On Sat, 18 Aug 2001, David Malone wrote: On Sat, Aug 18, 2001 at 11:02:04AM -0400, Mikhail Teterin wrote: Now, this may be the wrong way to do it: # mount -oro -t msdos /dev/ugen0 /mnt But the error message is certainly misleading. Especially, since the are no block devices in -current any more :) msdosfs: /dev/ugen0: Block device required This is caused by the kernel returning ENOTBLK, which I think still makes sense in the kernel. It's possible that the errno should be translated to a different string though... David. ./fs/hpfs/hpfs_vfsops.c:err = ENOTBLK; ./fs/ntfs/ntfs_vfsops.c:err = ENOTBLK; ./i386/ibcs2/ibcs2_errno.c: IBCS2_ENOTBLK, /* 15 */ ./kern/vfs_aio.c: if (error == ENOTBLK) ./kern/vfs_subr.c: *errp = ENOTBLK; ./kern/vfs_subr.c: *errp = ENOTBLK; ./compat/svr4/svr4_sysvec.c:SVR4_ENOTBLK, Just because there is no 'block' device representation in /dev doesn't mean that there aren't block devices. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: block device required
msdosfs: /dev/ugen0: Block device required This is caused by the kernel returning ENOTBLK, which I think still makes sense in the kernel. It's possible that the errno should be translated to a different string though... Just because there is no 'block' device representation in /dev doesn't mean that there aren't block devices. Indeed - that's why I said ENOTBLK makes sense in the kernel. Since someone got rid of the classic Not a typewriter message for ENOTTY, maybe we should change the message for ENOTBLK to Inappropriate device for operation. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
devfs
If I'm using devfs on -current, can I erase the contents of my /dev before devfs is mounted to save space? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs
In message [EMAIL PROTECTED], David W. Chapman Jr. writes: If I'm using devfs on -current, can I erase the contents of my /dev before devfs is mounted to save space? Yes, the easiest way is: boot singleuser mount -o rw / mv /dev /dev_ mkdir /dev chmod 755 /dev reboot ... rm -rf /dev_ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs
On Sat, 18 Aug 2001, David W. Chapman Jr. wrote: If I'm using devfs on -current, can I erase the contents of my /dev before devfs is mounted to save space? You could, but that would be, well, it'd really be a Darwin award winner. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs
Ohh, I think doing this unwise. You should always leave yourself something in /dev... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Mailing list problem because of DNS
I'm getting an error when attempting to send to [EMAIL PROTECTED] from an address that used to work. Has anything changed recently on the mailing list server? Thanks, -a - Transcript of session follows - ... while talking to hub.freebsd.org.: RCPT To:[EMAIL PROTECTED] 450 Client host rejected: cannot find your hostname, [216.12.228.198] [EMAIL PROTECTED]... Deferred: 450 Client host rejected: cannot find your hostname, [216.12.228.198] Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: where can i find info on supported MB chipsets
Subj. I can browse through code (and i do so), looking for chip IDs and comparing them with chipset ones, but it's sometimes difficult, because not all chip IDs in chipsets are know to me. So maybe driver developers know more than i do? I want to buy VIA Apollo KT266 based MD for Athlon, but as i understand it is unsupported right now. So i think that supported chipsets info will be usefull. Chipsets are supported by default, unless they are so stupid and broken that they actually require software support. Note that it's been a very, very long time since we met a chipset that actually required driver support. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X in free(): error: recursive call.
On Sun, Jul 29, 2001 at 10:29:40PM +0800, some SMTP stream spewed forth: I am running -CURRENT as of 2001/01/31 12:00, more or less uneventfully for the last six months on a Dell 5000e. The one problem is that X occasionally dies without coredump or cleanup with the error 'X in free(): error: recursive call.'. This usually (but not always) happens while using Mozilla with heavy window creation/deletion and heavy (dialup) network activity. This has happened under several recent versions of Mozilla, two different versions of fvwm2, with and without session managers, and with both X 4.0.3 and 4.1.0. *ding* So I'm not alone on this. I experienced this a while back running XF86 HEAD from cvs. The developers tracked it down to a signal handler calling malloc/free through the 3-button emulation code. You could be experiencing something completely different, but they fixed my particular version of this problem in cvs a couple months ago (I believe). When experiencing the crash, I would be heavily clicking, opening/moving/hiding/showing windows. It took me a while to identify the problem, because it happens infrequently, unpredicably, and leaves the video drivers in an unusable state (forcing a blind reboot). I tried linking /etc/malloc.conf to 'A' to get a coredump from X, but that doesn't work. I found a very short discussion of a related problem in the -CURRENT mail archives from the beginning of January, but there wasn't any apparent resolution of the problem. This was discussed on the XFree86 lists, which you probably weren't reading, being using a release. I'd like to get advice on which of the following courses of action to take: 1. Isolate and fix the problem. I would need some help here. You /could/ fire up a copy of gdb on the server binary, but I believe there are some messes with the modules XFree86 uses. (Don't take my word for this, I know largely nothing about debugging X.) 2. Downgrade to -STABLE. The reason I was running -CURRENT originally was for ACPI support, but Dell has since released an APM-enabled BIOS for the 5000e, so -CURRENT is no longer a requirement. This seems very much *not* a FreeBSD problem. 3. Upgrade to current -CURRENT. I don't know if this is such a good idea judging from mailing list traffic. Same as above, NAFP. 4. Hang in with the status quo for another couple months until 5.0 is released, install that, and start back at #1 if that doesn't work. Yet again, NAFP. Any advice, comments, or suggestions warmly appreciated. Can you run a CVS version of XFree86? I believe this was repaired in one of the more-recent (most-, possibly) 4.x releases. Thanks. -Michael Robinson G'luck, cheers. Daniel M. Kurry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X in free(): error: recursive call.
On Tue, Jul 31, 2001 at 09:13:29AM +0200, some SMTP stream spewed forth: Hello, I was running in the same problem early this year. Probably you have found my mails in the archive. Unfortunately I was not able solve the problem. I am running now 3.3.6 on my laptop (which furtunately supports the graphics chips that my laptop has). Just as a datapoint: My understanding of the problem is that it is really a problem of XFree (as opposed to FreeBSD) There seems to be a situation where malloc is called within a signal handler. It was explained to me that malloc cannot be recursively called. Therefore, if a signal interrupts Xfree when it is in the libc *alloc-functions, this can crash the server. Indeed. It was a Big Fat Mess inside the 3-button emulation code. libc is innocent, I tell you, innocent! ;-) The following trace shows this scenario: #0 0x2820a9e8 in kill () from /usr/lib/libc.so.5 #1 0x2825bb3d in abort () from /usr/lib/libc.so.5 #2 0x2825a682 in isatty () from /usr/lib/libc.so.5 #3 0x2825a6b0 in isatty () from /usr/lib/libc.so.5 #4 0x2825b6a6 in malloc () from /usr/lib/libc.so.5 #5 0x80d19ff in Xalloc (amount=16) at utils.c:1225 #6 0x80cc30c in TimerSet (timer=0x0, flags=0, millis=50, func=0x8788ef0, arg=0x88a0b00) at WaitFor.c:744 #7 0x87890fa in ?? () #8 0x878927d in ?? () #9 0x8788bf0 in ?? () #10 0x807da23 in xf86SigioReadInput (fd=7, closure=0x88a0b00) at xf86Events.c:1039 #11 0x8093d48 in xf86SIGIO (sig=23) at sigio.c:99 ^^^ This is the Big Red Truck that I missed during my debugging. #12 0xbfbfffac in ?? () #13 0x2825b1b0 in isatty () from /usr/lib/libc.so.5 #14 0x2825b901 in realloc () from /usr/lib/libc.so.5 #15 0x80d1b18 in Xrealloc (ptr=0x8eb3000, amount=4096) at utils.c:1322 #16 0x80ceef4 in StandardReadRequestFromClient (client=0x8a0d100) at io.c:403 #17 0x80ac00c in Dispatch () at dispatch.c:438 #18 0x80bc395 in main (argc=3, argv=0xbfbffdc0, envp=0xbfbffdd0) at main.c:439 #19 0x806b31d in _start () My understanding is that the problem is with XFree using malloc in a signal-handler. Indeed, see above. Strange enough, my system at home (with a Matrox G400-Card and Xfree86-4.1.0) does not show this symptom. Indeed, again, I believe it was fixed before that release was, er, released. This is also fixed in cvs. XFree86, is zarking cool. You would enjoy the upgrade. Michael Daniel M. Kurry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CFR: lseek() POSIXed patch
Updated variant:
--- vfs_syscalls.c.old Sat Aug 11 02:14:18 2001
+++ vfs_syscalls.c Sun Aug 19 05:01:32 2001
@@ -1614,29 +1614,44 @@
register struct filedesc *fdp = p-p_fd;
register struct file *fp;
struct vattr vattr;
- int error;
+ struct vnode *vp;
+ off_t offset;
+ int error, noneg;
if ((u_int)SCARG(uap, fd) = fdp-fd_nfiles ||
(fp = fdp-fd_ofiles[SCARG(uap, fd)]) == NULL)
return (EBADF);
if (fp-f_type != DTYPE_VNODE)
return (ESPIPE);
+ vp = (struct vnode *)fp-f_data;
+ noneg = (vp-v_type != VCHR);
+ offset = SCARG(uap, offset);
switch (SCARG(uap, whence)) {
case L_INCR:
- fp-f_offset += SCARG(uap, offset);
+ if (noneg
+ ((offset 0 fp-f_offset OFF_MAX - offset) ||
+(offset 0 fp-f_offset OFF_MIN - offset)))
+ return (EOVERFLOW);
+ offset += fp-f_offset;
break;
case L_XTND:
- error=VOP_GETATTR((struct vnode *)fp-f_data, vattr, cred, p);
+ error = VOP_GETATTR(vp, vattr, cred, p);
if (error)
return (error);
- fp-f_offset = SCARG(uap, offset) + vattr.va_size;
+ if (noneg
+ ((offset 0 vattr.va_size OFF_MAX - offset) ||
+(offset 0 vattr.va_size OFF_MIN - offset)))
+ return (EOVERFLOW);
+ offset += vattr.va_size;
break;
case L_SET:
- fp-f_offset = SCARG(uap, offset);
break;
default:
return (EINVAL);
}
+ if (noneg offset 0)
+ return (EINVAL);
+ fp-f_offset = offset;
*(off_t *)(p-p_retval) = fp-f_offset;
return (0);
}
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: no new snapshot onftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/
On 2001-08-19 00:48:19 +0900, Makoto MATSUSHITA wrote:
wosch the 5.0-current snapshots on current.jp.freebsd.org are not updated
wosch since 3-Aug-2001. What happens?
Really?
Sorry, my fault.
lrwxr-xr-x 1 root ftp 27 Aug 10 17:19 5-LATEST - 5.0-CURRENT-20010810-JPSNAP
The last successfully finished release should be Aug/10/2001.
Right.
Current 5-current release is broken, since KerberosIV-enabled
src/gnu/usr.bin/cvs is broken as follows:
Nevertheless, current sucks. No successfully builds since 9 days ;-{{
-Wolfram
cc -O -pipe -I/usr/src/gnu/usr.bin/cvs/cvs -I/usr/src/gnu/usr.bin/cvs/cvs/../lib
-DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src
-I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib
-I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/diff -DHAVE_KERBEROS
-DHAVE_KRB_GET_ERR_TEXT -DENCRYPTION-c
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c: In function
`start_tcp_server':
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: `client_sai'
undeclared (first use in this function)
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: (Each
undeclared identifier is reported only once
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: for each
function it appears in.)
/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4151: warning:
passing arg 6 of `krb_sendauth' discards qualifiers from pointer target type
*** Error code 1
Sorry I don't know how to fix.
-- -
Makoto `MAR' MATSUSHITA
--
Wolfram Schneider [EMAIL PROTECTED] http://wolfram.schneider.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic: ffs_blkfree: freeing free block / + UDMA ICRC error with ad0
On Saturday, 18 August 2001 at 14:56:10 +0200, Alexander Leidinger wrote:
Hi,
-current as of Aug 16, ~2pm CEST:
I don't see a freeing free block in the stack trace. What is
missing from the trace below? Does the trace belong to the panic
message?
The trace shows two panics: the first looks like a page fault kernel
mode, though the backtrace address looks user mode. The second panic
is a bremfree: bp not locked in the subsequent sync. That one may
be related to some SMP stuff that has been done recently. It would be
interesting to look at the return address from the trap: the code
space ID is 0xc000, which I don't recognize. What process was
running?
---snip---
IdlePTD 4812800
initial pcb at 305f60
panicstr: bremfree: bp 0xc69e0748 not locked
panic messages:
---
panic: ffs_blkfree: freeing free block
panic: from debugger
[...]
#0 dumpsys () at ../../../kern/kern_shutdown.c:479
#1 0xc01baf11 in boot (howto=260) at ../../../kern/kern_shutdown.c:322
#2 0xc01bb32a in panic (fmt=0xc02ba51e bremfree: bp %p not locked)
at ../../../kern/kern_shutdown.c:601
#3 0xc01ed20e in bremfree (bp=0xc69e0748) at ../../../kern/vfs_bio.c:479
#4 0xc01eeb7a in getnewbuf (slpflag=0, slptimeo=0, size=8192, maxsize=8192)
at ../../../kern/vfs_bio.c:1632
#5 0xc01ef8d1 in getblk (vp=0xd063eec0, blkno=64, size=8192, slpflag=0,
slptimeo=0) at ../../../kern/vfs_bio.c:2244
#6 0xc01ed2ef in breadn (vp=0xd063eec0, blkno=64, size=8192, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0xc049ae10)
at ../../../kern/vfs_bio.c:537
#7 0xc01ed2b4 in bread (vp=0xd063eec0, blkno=64, size=8192, cred=0x0,
bpp=0xc049ae10) at ../../../kern/vfs_bio.c:519
#8 0xc0228650 in ffs_update (vp=0xd063eda0, waitfor=0)
at ../../../ufs/ffs/ffs_inode.c:101
#9 0xc023601f in ffs_fsync (ap=0xc049ae8c) at ../../../ufs/ffs/ffs_vnops.c:292
#10 0xc0233f9f in ffs_sync (mp=0xc1870400, waitfor=2, cred=0xc0e61d00,
p=0xc0337000) at vnode_if.h:441
#11 0xc01fc2e1 in sync (p=0xc0337000, uap=0x0)
at ../../../kern/vfs_syscalls.c:620
#12 0xc01baa37 in boot (howto=256) at ../../../kern/kern_shutdown.c:231
#13 0xc01bb32a in panic (fmt=0xc02cfc5e %s)
at ../../../kern/kern_shutdown.c:601
#14 0xc0276c90 in trap_fatal (frame=0xc049afa8, eva=794529)
at ../../../i386/i386/trap.c:935
#15 0xc02769c9 in trap_pfault (frame=0xc049afa8, usermode=0, eva=794529)
at ../../../i386/i386/trap.c:849
#16 0xc027615c in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 3557,
tf_esi = 20371, tf_ebp = 24, tf_isp = -1068912684, tf_ebx = 8,
tf_edx = 145, tf_ecx = 3, tf_eax = 1544, tf_trapno = 12, tf_err = 4,
tf_eip = 8097, tf_cs = 49152, tf_eflags = 721410, tf_esp = 4030,
tf_ss = 0}) at ../../../i386/i386/trap.c:408
#17 0x1fa1 in ?? ()
Cannot access memory at address 0x18.
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
On Wed, Aug 15, 2001 at 07:01:46PM +0200, some SMTP stream spewed forth: One gets the first DMA buffer full, then the process hangs... Due to the lack of replies, I'll go ahead. I am seeing sound breakage also. My card is a Creative Labs SoundBlaster Live!. xmms will play a short (less than a second) spurt of audio and then stop responding. mpg123 will not play (any audio to the speakers) at all. I ran a buildworld today which apparently broke it. That puts the breakage between today and sometime less than 2 months ago. (I really cannot be more specific.) Suggestions gladly welcomed. -Søren Daniel M. Kurry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
In servalan.mailinglist.fbsd-current Daniel M. Kurry writes: On Wed, Aug 15, 2001 at 07:01:46PM +0200, some SMTP stream spewed forth: One gets the first DMA buffer full, then the process hangs... Due to the lack of replies, I'll go ahead. I am seeing sound breakage also. My card is a Creative Labs SoundBlaster Live!. xmms will play a short (less than a second) spurt of audio and then stop responding. mpg123 will not play (any audio to the speakers) at all. I ran a buildworld today which apparently broke it. That puts the breakage between today and sometime less than 2 months ago. (I really cannot be more specific.) I'm seeing much the same thing, on an SMP box with onboard sbc0 (Vibra16X) sound chip. Attempting to play sound with madplay gets about 2 seconds of sound and then silence, with the madplay process in an unkillable kernel wait. Oddly enough, the sbc0 interrupt thread continues to occasionally gather a tick of CPU time, but apparently not enough to do anything useful. I'm busy doing binary-search on the CVS tree, checking out source from different times and seeing if I can localize the commit that broke it. My current results are that a kernel built from source as of 2001/08/10 00:00 CDT (i.e. 2001/08/09 22:00:00 PDT) works, one built from source as of 2001/08/10 15:52 PDT does not, so the bug is somewhere in between there. I'm now trying to narrow this down further, to a specific commit somewhere in that region. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Userbase of -current
From: Tom Fischer [EMAIL PROTECTED] Subject: Re: Userbase of -current Date: Mon, Jul 23, 2001 at 07:19:25PM +0200 Add a data point for me using -current on my laptop in order to take advantage of cardbus support (thanks Warner!). We really should have those Slashdot people run a poll or sth :P Count me too. 5 runs nicely on my aging Pentium box at home. It's still very nice to be able to check the documentation parts of the tree against the latest -CURRENT sources. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Userbase of -current
On Wed, 1 Aug 2001, Giorgos Keramidas wrote: From: Tom Fischer [EMAIL PROTECTED] Subject: Re: Userbase of -current Date: Mon, Jul 23, 2001 at 07:19:25PM +0200 Add a data point for me using -current on my laptop in order to take advantage of cardbus support (thanks Warner!). We really should have those Slashdot people run a poll or sth :P Count me too. 5 runs nicely on my aging Pentium box at home. It's still very nice to be able to check the documentation parts of the tree against the latest -CURRENT sources. Speaking about -current and laptops, I know Warner mentioned the 3COM 3CXFEM656C working in -current but what's the proper way to install FreeBSD on a IBM ThinkPad 770Z with that NIC/Modem combo since the floppy disks don't seem to show the card on a 6162001 snapshot from current.FreeBSD.ORG. I was thinking about making a CD of the snapshot but is there a bootable ISO available? Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kde22 current
I don't know if this helps, I tried gdb'ing through the lt-meinproc.core that is produced when trying to compile kde22 and got this. I'm not a programmer so hopefully someone can point me in the right direction on this. It appears to only be an issue on -current and new version of -current. warning: Can't set a watchpoint on a core file. warning: Can't set a watchpoint on a core file. Program received signal SIGSEGV, Segmentation fault. 0x28857740 in QCString::resize () from /usr/X11R6/lib/libqt2.so.4 -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
This is pretty wierd... I'm running -current as of 7am this morning, and am listening to Black in Black in XMMS at this moment. SB-Live! Value, I am running SMP. Richard Todd wrote: In servalan.mailinglist.fbsd-current Daniel M. Kurry writes: On Wed, Aug 15, 2001 at 07:01:46PM +0200, some SMTP stream spewed forth: One gets the first DMA buffer full, then the process hangs... Due to the lack of replies, I'll go ahead. I am seeing sound breakage also. My card is a Creative Labs SoundBlaster Live!. xmms will play a short (less than a second) spurt of audio and then stop responding. mpg123 will not play (any audio to the speakers) at all. I ran a buildworld today which apparently broke it. That puts the breakage between today and sometime less than 2 months ago. (I really cannot be more specific.) I'm seeing much the same thing, on an SMP box with onboard sbc0 (Vibra16X) sound chip. Attempting to play sound with madplay gets about 2 seconds of sound and then silence, with the madplay process in an unkillable kernel wait. Oddly enough, the sbc0 interrupt thread continues to occasionally gather a tick of CPU time, but apparently not enough to do anything useful. I'm busy doing binary-search on the CVS tree, checking out source from different times and seeing if I can localize the commit that broke it. My current results are that a kernel built from source as of 2001/08/10 00:00 CDT (i.e. 2001/08/09 22:00:00 PDT) works, one built from source as of 2001/08/10 15:52 PDT does not, so the bug is somewhere in between there. I'm now trying to narrow this down further, to a specific commit somewhere in that region. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
On Sat, 18 Aug 2001 21:10:40 -0500, Daniel M . Kurry wrote: On Wed, Aug 15, 2001 at 07:01:46PM +0200, some SMTP stream spewed forth: One gets the first DMA buffer full, then the process hangs... Due to the lack of replies, I'll go ahead. I am seeing sound breakage also. My card is a Creative Labs SoundBlaster Live!. xmms will play a short (less than a second) spurt of audio and then stop responding. mpg123 will not play (any audio to the speakers) at all. I ran a buildworld today which apparently broke it. That puts the breakage between today and sometime less than 2 months ago. (I really cannot be more specific.) Suggestions gladly welcomed. -Søren The same is here (OPL3-SA driver on Toshiba Satellite Pro 445CDX notebook). I found that after reverting the following deltas (jhb's 10 August commit) sound starts working again: src/sys/i386/i386/sys_machdep.c,v 1.60 src/sys/i386/i386/trap.c,v 1.198 src/sys/i386/include/cpu.h,v 1.63 src/sys/i386/isa/ipl.s,v 1.51 src/sys/i386/isa/npx.c,v 1.108 src/sys/kern/kern_clock.c,v 1.128 src/sys/kern/kern_intr.c,v 1.61 src/sys/kern/kern_lock.c,v 1.47 src/sys/kern/kern_synch.c,v 1.155 src/sys/kern/kern_timeout.c,v 1.69 src/sys/kern/subr_prof.c,v 1.47 src/sys/kern/subr_smp.c,v 1.157 src/sys/kern/subr_trap.c,v 1.197 src/sys/kern/subr_witness.c,v 1.82 src/sys/posix4/ksched.c,v 1.14 src/sys/sys/callout.h,v 1.21 src/sys/sys/proc.h,v 1.174 src/sys/sys/resourcevar.h,v 1.23 Please fix. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
