Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On 10/29/21 00:47, Tomoaki AOKI wrote: But possibly we need to delete current smbfs code from base and switch to ports (sysutils/*?) if it require some code having incompatible license for base. I normally favour ports over things in base. In this case, however, as I said before, I needed it several times in emergency while booting the install key as live media. If it's a port, it won't be there. Perhaps my use case is rare. Also, probably there are other tools that can do this. OTOH having a port is not in any way worse as having a broken piece of base. bye av.
Re: Strange behavior after running under high load
On 3/28/21 4:39 PM, Stefan Esser wrote: After a period of high load, my now idle system needs 4 to 10 seconds to run any trivial command - even after 20 minutes of no load ... High CPU load or high disk load? ZFS? Snapshots? 12.x? 13.x? I've seen something similar: after a high load period, system crawled so much that services were not answering in a reasonable time (e.g. mail would fail with "no such mailbox"!). Even rebooting didn't fix it, until I deleted some autosnapshots. top or other tools would show no disk activity, although the disks were working as mad. Not sure it's the same case you experienced, though. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT, usr/src on git, howto "mergemaster"?
On 1/4/21 7:18 PM, Warner Losh wrote: mergemaster has been on its way out since well before the switch to git. It's been disfavored for at least a decade I first heard about this today. While I don't have any opinion on this, shouldn't any reference to it in the instructions in /usr/src/UPDATING be changed? They way I read that file is that mergemaster is still the official way to go. bye & Thanks av. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Shutdown errors and timeout
On 11/13/20 11:35 AM, Johan Hendriks wrote: Just my 2c... The vritual machine seems to fail stopping something and gives a timeout after 90 sec. I've seen this on many (physical) boxes and I solved by increasing shutdown timeout. Sometimes 90s is just too little (especially, but not only, if you have VMs running). E.g. I have rcshutdown_timeout="600" in /etc/rc.conf and kern.init_shutdown_timeout=900 in /etc/sysctl.conf. On the bare metal machine i see the following. Writing entropy file: . Writing early boot entropy file: . cannot unmount '/var/run': umount failed cannot unmount '/var/log': umount failed cannot unmount '/var': umount failed cannot unmount '/usr/home': umount failed cannot unmount '/usr': umount failed cannot unmount '/': umount failed Probably a process is still running and that's why those filesystems cannot be (unforcibly) unmounted. Logs can help identify which process it is. Perhaps putting rc_debug="YES" in /etc/rc.conf can be useful. bye av. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Which AMD CPUs are supported -- temperature
On 2020-02-12 23:17, Chris wrote: # dmidecode -t4 | grep AMD Manufacturer: AMD Version: AMD Athlon(tm) II X4 630 Processor # sysctl -a | grep tempe dev.cpu.3.temperature: 33.5C dev.cpu.2.temperature: 33.5C dev.cpu.1.temperature: 33.5C dev.cpu.0.temperature: 33.5C Also works here: > cat /var/run/dmesg.boot > ... > CPU: AMD Phenom(tm) II X4 965 Processor (3415.38-MHz K8-class CPU) > sysctl -a|grep temp > dev.cpu.3.temperature: 43.6C > dev.cpu.2.temperature: 43.6C > dev.cpu.1.temperature: 43.6C > dev.cpu.0.temperature: 43.6C # # # BROKEN # dmidecode -t4 | grep AMD Manufacturer: AuthenticAMD Version: AMD Athlon(tm) X4 860K Quad Core Processor # sysctl -a | grep tempe dev.cpu.3.temperature: 13.1C dev.cpu.2.temperature: 13.1C dev.cpu.1.temperature: 13.1C dev.cpu.0.temperature: 13.1C All but one is in the same class. But one in that same class doesn't work. The FX class also works fine. I'm puzzled... :( This reminds me of my first Ryzen 2: 11.3 would not get the temperature right, but 12.1 did. If I understand correctly, AMD just gives a temperature reading in the same way on all CPUs, but different models require different adjustment to that value (with some offset and/or other calculations); see /usr/src/sys/dev/amdtemp/amdtemp.c. Perhaps this CPU needs a formula which FreeBSD's driver does not have? Of course this is a wild guess, as I have not access to the specs. bye av. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UFS panics
On 10/27/18 5:34 PM, Leandro wrote: I just wanted to confirm if panics on UFS were expected if the file system had errors This is no official answer, but yes, basing on my nearly 20 years of experience with UFS, I've come to expect them. Several times after some boxes of mine crashed, they kept crashing every day or every few days. Only solution is to reboot in single user mode, fsck the filesystems (notice, not "fsck -p") and restart. I guess softupdates let something bad slip through and won't fix it at reboot. Just my 2c. bye av. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: testing early microcode loading
On 9/10/18 8:26 PM, Mark Johnston wrote: Hi, Support for boot-time loading of Intel microcode updates has landed in the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. Thanks for your work. Altough I cannot test it yet, I appreciate it. Just one question: what about AMD? Is support for this brand coming in the future? Is it impossible for some reason? bye & Thanks av. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Deadlocks / hangs in ZFS
On 05/22/18 10:17, Alexander Leidinger wrote: Hi, does someone else experience deadlocks / hangs in ZFS? Yes, in conjunction with Poudriere, probably when it builds/activates jails. Not sure this is the same problem you are seeing. bye av. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How to find CPU microcode version ?
On 02/18/18 11:41, Kurt Jaeger wrote: Reboot of the box and waiting a few hours and the problem re-occured. Doesn't the work of microcode_update vanish after a reboot? Unless of course you set up rc.conf to repeat it at every start... bye av. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Opteron 6100-series "Magny-Cours"
On 03/25/17 19:02, Andriy Gapon wrote: Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with FreeBSD? Will an equivalent Athlon do or is this Opteron specific? What would that Athlon be? bye av. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
wi driver reads wrong first 8 bytes when in monitor mode in data packets
If I am not wrong, it seems that the wi driver, when in monitor mode, will skip
8 bytes of data input (filling it in with random values).
We notice in if_wi.c:
case 7:
switch (rx_frame-wi_whdr.i_fc[0] IEEE80211_FC0_TYPE_MASK) {
case IEEE80211_FC0_TYPE_DATA:
hdrlen = WI_DATA_HDRLEN;
data is then read according to the hdrlen offset.
if (wi_read_bap(sc, fid, hdrlen, mtod(m, caddr_t) + hdrlen,
datlen + 2) == 0) {
in if_wavelan_ieee.h:
#define WI_DATA_HDRLEN 0x44
#define WI_MGMT_HDRLEN 0x3C
#define WI_CTL_HDRLEN 0x3C
we notice that data frames seem to have an 8 byte header extra
we then notice
/*
* all data packets have a snap (sub-network access protocol) header that
* isn't entirely definied, but added for ethernet compatibility.
*/
struct wi_snap_frame {
u_int16_t wi_dat[3];
u_int16_t wi_type;
};
(it is 8 bytes)
It seems like if the llc/snap is treated as a 802.11 header per se and not act
ual data. (Maybe this was the mentality of the developers).
Under normal circumstances this is ok, since many people do not care about sna
p/llc when in monitor mode. Infact, the ip header will be just fine.
However when auditing wep, those 8 bytes are crucial (since the first 3+1 bytes
contain IV information) and the first few bytes of cyphertext are normally used
in known plaintext attacks. Infact, bsd-airtools will probably not work at all.
I am running:
FreeBSD tribal.sorbonet.org 5.2-BETA FreeBSD 5.2-BETA #5: Wed Nov 26 05:24:11 GM
T 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SORBO i386
A very basic patch which seems to works is:
if_wavelan_ieee.h.diff:
** CUT
*** if_wavelan_ieee.h.orig Wed Nov 26 06:00:58 2003
--- if_wavelan_ieee.h Wed Nov 26 05:08:08 2003
***
*** 466,472
u_int8_twi_src_addr[6];
u_int16_t wi_len;
};
! #define WI_DATA_HDRLEN0x44
#define WI_MGMT_HDRLEN0x3C
#define WI_CTL_HDRLEN 0x3C
--- 466,472
u_int8_twi_src_addr[6];
u_int16_t wi_len;
};
! #define WI_DATA_HDRLEN0x3C
#define WI_MGMT_HDRLEN0x3C
#define WI_CTL_HDRLEN 0x3C
** CUT
Andrea Bittau
[EMAIL PROTECTED]
http://www.darkircop.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR message from crashdump?
Hi, I tried researching this one but couldn't find an answer in the FM... When I get panics, I end up in DDB; then I just type `call doadump' and reboot. When I load such a dump in gdb -k, I usually get the panic message, like this: This GDB was configured as i386-undermydesk-freebsd... panic: vm_page_dirty: page is free! panic messages: --- panic: vm_page_dirty: page is free! Dumping 191 MB 16 32 48 64 80 96 112 128 144 160 176 --- Reading symbols from /boot/kernel/if_wi.ko...done. Loaded symbols for /boot/kernel/if_wi.ko ... This is not happening with a LOR, i.e. I only get: This GDB was configured as i386-undermydesk-freebsd... panic messages: --- --- Reading symbols from /boot/kernel/if_wi.ko...done. Loaded symbols for /boot/kernel/if_wi.ko ... Is this normal or my fault? Is there a way to retrieve the LOR message? I thought it was a new one, but didn't write it down, so now I have a useless crashdump... :( Bye, Andrea -- One world, one web, one program -- Microsoft promotional ad Ein Volk, ein Reich, ein Fuehrer -- Adolf Hitler ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: vm_page_dirty: page is free!
Hi,
my laptop just paniced with this message. I looked in the archives
but didn't find it. Here it is in case it's interesting; I don't
know if any more details are needed.
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc04604b5 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xcc3b284c à¸jÀ)
at ../../../ddb/db_command.c:548
#2 0xc0460202 in db_command (last_cmdp=0xc06aaf80, cmd_table=0x0,
aux_cmd_tablep=0xc067df24,
aux_cmd_tablep_end=0xc067df28) at ../../../ddb/db_command.c:346
#3 0xc0460345 in db_command_loop () at ../../../ddb/db_command.c:472
#4 0xc0463345 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73
#5 0xc060eedc in kdb_trap (type=3, code=0, regs=0xcc3b29a0)
at ../../../i386/i386/db_interface.c:171
#6 0xc06223ea in trap (frame=
{tf_fs = 24, tf_es = -868548592, tf_ds = -103920, tf_edi = 1, tf_esi =
-1066974976, tf_ebp
= -868537876, tf_isp = -868537908, tf_ebx = 0, tf_edx = 0, tf_ecx = -1066357025,
tf_eax = 18, tf_tr
apno = 3, tf_err = 0, tf_eip = -1067388524, tf_cs = 8, tf_eflags = 658, tf_esp =
-1066962079, tf_ss
= -1067035201}) at ../../../i386/i386/trap.c:580
#7 0xc0610898 in calltrap () at {standard input}:94
#8 0xc04ff055 in panic (fmt=0xc0674100 vm_page_dirty: page is free!)
at ../../../kern/kern_shutdown.c:534
#9 0xc05d62dc in vm_page_dirty (m=0x0) at ../../../vm/vm_page.c:446
#10 0xc061e6ac in pmap_remove_pte (pmap=0xc070ede0, ptq=0x0, va=3394740224)
at ../../../i386/i386/pmap.c:1595
#11 0xc061e86c in pmap_remove (pmap=0xc070ede0, sva=3394740224, eva=3394809856)
at ../../../i386/i386/pmap.c:1696
#12 0xc05cf454 in vm_map_delete (map=0xc0c250b0, start=3233960112, end=3394809856)
at ../../../vm/vm_map.c:
#13 0xc05cc00f in kmem_free_wakeup (map=0xc0c250b0, addr=3394740224, size=0)
at ../../../vm/vm_kern.c:506
#14 0xc04e5ddd in kern_execve (td=0xc23fd3c0, fname=---Can't read userspace from dump,
or kernel pro
cess---
) at ../../../kern/kern_exec.c:632
#15 0xc04e5f70 in execve (td=0x0, uap=0x0) at ../../../kern/kern_exec.c:695
#16 0xc0622d50 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 0, tf_ebp = 0, tf_isp
= 0, tf_ebx =
0, tf_edx = 0, tf_ecx = 0, tf_eax = 0, tf_trapno = 0, tf_err = 0, tf_eip = 671453648,
tf_cs = 31, tf
_eflags = 514, tf_esp = -1077940676, tf_ss = 47}) at ../../../i386/i386/trap.c:1010
Bye,
Andrea
--
The computer revolution is over. The computers won.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ip_output panics on recent -CURRENT
On Mon, Nov 03, 2003 at 01:38:56PM -0800, Sam Leffler wrote: The problem appears to be caused by someone reclaming routing table entries while they are in use. This would likely be a reference counting problem. You didn't provide any information about system kernel config or hardware config. Both are important. Aye, I'm quite aware of that; I just wanted to probe whether you knew about it and whether more debugging on my part was necessary. Problem is, I'm tracking down some more problems at the moment, so time for FreeBSD activity is a bit scarce. I'll do what I can. You don't indicate when last sunday is; is that 11/02? Did you get my recent commit to in_rmx.c that was last night and fixed a reference counting problem (but which would probably not affect you)? Are you running with WITNESS and INVARIANT? If not, do so. Have you tried to identify something that makes the panic happen? (e.g. ping as opposed to using ssh, as opposed to NFS over UDP, etc.) Have you tried setting debug.mpsafenet=0? Sources where from 11/02 indeed, I'm attaching my kernel config. Relevant hardware is 1xPIII 192MB RAM, one ep (not used at time of panic) one wi. I'm not sure at all about in_rmx.c, but very possibly no (you didn't say when last night is ;-) joking, I saw in_rmx.c 1.48). Panics happened when I only had background traffic going on - which for my laptop means ntpd, the occasional fetchmail, postfix on localhost - not much more. Again, I'll try to restrict. I see now WITNESS and INVARIANT were off - oops, I forgot turning them off at times when -CURRENT was more stable to do performance tests. I'll get back to you when I have time to update to recent sources and get more data points. Bye, Andrea -- One world, one web, one program -- Microsoft promotional ad Ein Volk, ein Reich, ein Fuehrer -- Adolf Hitler ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ip_output panics on recent -CURRENT
Hi,
after updating my laptop to last sunday sources, it panics very often with
one of two panics. Sam, any chance you might know what's up?
Note that both panics seem (to my untrained eye at least) to be related
to spammed route entry structures. The second one in particular looks
suspicious, with all those null arguments...
Enjoy,
Andrea
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x68
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04d8ad2
stack pointer = 0x10:0xcb4a0a24
frame pointer = 0x10:0xcb4a0a50
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 466 (ntpd)
Dumping 191 MB
16 32 48 64 80 96 112 128 144 160 176
---
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc044ada5 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xcb4a0850
\2005hÀ\f)
at /usr/src/sys/ddb/db_command.c:548
#2 0xc044aaf2 in db_command (last_cmdp=0xc0682c20, cmd_table=0x0,
aux_cmd_tablep=0xc0659ef0,
aux_cmd_tablep_end=0xc0659ef4) at /usr/src/sys/ddb/db_command.c:346
#3 0xc044ac35 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#4 0xc044dc55 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#5 0xc060336c in kdb_trap (type=12, code=0, regs=0xcb4a09e4)
at /usr/src/sys/i386/i386/db_interface.c:171
#6 0xc0614ec6 in trap_fatal (frame=0xcb4a09e4, eva=0) at
/usr/src/sys/i386/i386/trap.c:818
#7 0xc0614513 in trap (frame=
{tf_fs = -884342760, tf_es = -1067450352, tf_ds = -1055719408, tf_edi =
-1036451332, tf_esi =
1036561520, tf_ebp = -884340144, tf_isp = -884340208, tf_ebx = -1055714416, tf_edx =
2, tf_ecx = 0,
tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1068660014, tf_cs = 8, tf_eflags =
66118, tf_esp
= 47, tf_ss = -1077936960}) at /usr/src/sys/i386/i386/trap.c:252
#8 0xc0604d18 in calltrap () at {standard input}:102
#9 0xc0575416 in ip_output (m0=0xc1131390, opt=0xc2375390, ro=0xc23901fc, flags=32,
imo=0x0,
inp=0xc23901c0) at /usr/src/sys/netinet/ip_output.c:266
#10 0xc0584726 in udp_output (inp=0xc23901c0, m=0xc1139500, addr=0xc29be7d0,
control=0x20,
td=0xc1131390) at /usr/src/sys/netinet/udp_usrreq.c:847
#11 0xc05853d1 in udp_send (so=0x0, flags=0, m=0xc1139500, addr=0x0, control=0x0,
td=0x0)
at /usr/src/sys/netinet/udp_usrreq.c:1043
#12 0xc0522d9d in sosend (so=0xc238e880, addr=0xc29be7d0, uio=0xcb4a0c38,
top=0xc1139500,
control=0x0, flags=0, td=0xc1131390) at /usr/src/sys/kern/uipc_socket.c:715
#13 0xc05276dc in kern_sendit (td=0xc1131390, s=6, mp=0xcb4a0cb0, flags=0, control=0x0)
at /usr/src/sys/kern/uipc_syscalls.c:722
#14 0xc05274fe in sendit (td=0x0, s=0, mp=0xcb4a0cb0, flags=0)
at /usr/src/sys/kern/uipc_syscalls.c:662
#15 0xc05278cb in sendto (td=0x0, uap=0x0) at /usr/src/sys/kern/uipc_syscalls.c:783
#16 0xc0615280 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134746472, tf_esi = 134741744,
tf_ebp = -1077938
072, tf_isp = -884339340, tf_ebx = -1, tf_edx = 134732640, tf_ecx = 672656864, tf_eax
= 133, tf_trap
no = 22, tf_err = 2, tf_eip = 672158495, tf_cs = 31, tf_eflags = 663, tf_esp =
-1077938116, tf_ss =
47}) at /usr/src/sys/i386/i386/trap.c:1012
#17 0xc0604d6d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
(kgdb) list /usr/src/sys/netinet/ip_output.c:266
261 * cache with IPv6.
262 */
263 if (ro-ro_rt ((ro-ro_rt-rt_flags RTF_UP) == 0 ||
264 dst-sin_family != AF_INET ||
265 dst-sin_addr.s_addr != pkt_dst.s_addr)) {
266 RTFREE(ro-ro_rt);
267 ro-ro_rt = (struct rtentry *)0;
268 }
269 if (ro-ro_rt == 0) {
270 bzero(dst, sizeof(*dst));
(kgdb) print *ro
$1 = {ro_rt = 0xc2375300, ro_dst = {sa_len = 16 '\020', sa_family = 2 '\002',
sa_data = \0\0Õ\\\005R\0\0\0\0\0\0\0}}
(kgdb) print *ro-ro_rt
$2 = {rt_nodes = {{rn_mklist = 0xc2375370, rn_parent = 0xc23753c0, rn_bit = 876,
rn_bmask = 112 'p', rn_flags = 194 'Â', rn_u = {rn_leaf = {
rn_Key = 0xc232cdb0 ,¤fÀ\232ËdÀ\232ËdÀ, rn_Mask = 0x0, rn_Dupedkey =
0x14}, rn_node = {
rn_Off = -1036857936, rn_L = 0x0, rn_R = 0x14}}}, {rn_mklist = 0x3,
rn_parent = 0x3,
rn_bit = 63, rn_bmask = 0 '\0', can not access 0x, invalid address
()
can not access 0x, invalid address ()
can not access 0x, invalid address ()
can not access 0x, invalid address ()
can not access 0x, invalid address ()
can not access 0x, invalid address ()
rn_flags = 0 '\0', rn_u = {rn_leaf = {
rn_Key = 0x Address 0x
Re: Fixing -pthreads (Re: ports and -current)
On Wed, Sep 24, 2003 at 05:03:28PM +0100, Ian Dowse wrote: Just to throw one further approach out on the table, below is a patch that makes gcc read from a file to determine what library to associate with the -pthread flag. It's a hack of course, and probably neither correct or optimal. If you want to make -pthread mean libkse, create an /etc/pthread.libs that looks like: Kudos to you! That's the general direction of my thoughts, but I had no idea where to look in gcc's guts... And I agree, maybe it's not the best option, but we should at least consider it. Bye, Andrea -- Failure is not an option. It comes bundled with your Microsoft product. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
[cc trimmed] Hi Daniel, On Tue, Sep 23, 2003 at 04:13:11PM -0400, Daniel Eischen wrote: However, I'd also suggest making it easy for people to set '-pthread' to give whatever pthreads library they think is the most sensible default for their installation. You can't make it variable. I followed the whole thread and probably I'm being dense, but I still can't get this point. Note that I'm not taking position one way or the other, just asking. Why is that so? Isn't it possible to have -pthread: - do nothing when linking libraries - use libmap.conf(5) (possibly integrated by whatever env magic we want to add to allow this to be temporarily overridden) to decide what to link with. Bye, Andrea -- Press every key to continue. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3COM ep0 pccard device broken in current.
On Fri, Jul 04, 2003 at 03:26:07PM +0100, Mark Murray wrote: There were two changes. One is in pccbb.c that makes things a MPSAFE interrupt. You could revert to version 1.175 of pccbb.c. I'll play with that in a few hours when I get home. [...] Revision 1.115 / (download) - annotate - [select for diffs], Thu Jun 26 13:27:44 2003 UTC (7 days, 23 hours ago) by mux Changes since 1.114: +5 -7 lines I played with this, but without playing with the pccbb.c stuff. I'll give it a go tonight. Mark, I used to see the same issue you are seeing starting from the time the change to pccbb.c went in, but mux's fix to if_ep.c solved it all for me. However, it's always possible that yours is a slightly different problem, so I'd be interested to hear what you are doing exacly so that I could try and repeat it. Bye, Andrea -- Loose bits sink chips. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2365] Re: Updated ec-burst.diff patch
On Tue, Jul 01, 2003 at 10:25:36AM -0700, Nate Lawson wrote: Would you please turn on hw.acpi.verbose=1 in loader.conf? It should explain the cause of those errors. Also, I would like the output of dmesg | egrep acpi_ec0\|EC\ Wait. I tested your patch on my IBM Thinkpad 570E and didn't see any difference. I was surprised by that, but hey, what do I know. Then I did a dmesg | egrep acpi_ec0\|EC\ Wait, and got no output at all. Turns out I have no acpi_ec0. Should I worry about that? Will I miss anything because of that? My laptop is working correctly in most ways, including thermal zone, profile transition when plugging and unplugging the power cord, and power states (in particular S4BIOS). Bye, Andrea -- The dark ages were caused by the Y1K problem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2302] s4bios
On Tue, Jun 03, 2003 at 05:32:05PM +0200, Mark Santcroos wrote: Is there anyone that has succesfully used acpiconf -s 4? I'm very interested in your reports. If you haven't tried yet, but are willing to help me, please report me your findings. Works for me - although it does some weird things. First, is the acpi_printcpu() normal, something I did, or is it triggered by some BIOS bug^Wfeature? Second, on resume the screen isn't refreshed, instead, the BIOS screen with the progress bar is shown. Switching consoles doesn't help, starting and quitting X does give me back my screen. Also, the network card loses its IP address and dhclient doesn't seem to get a new one, I didn't investigate further, see below if interested. Third, the suspend led keeps blinking but this is a very, very minor detail. ;-) Bye, Andrea Thinkpad 570E hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: S1 hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 0 hw.acpi.s4bios: 1 hw.acpi.verbose: 1 [suspend] ep0: detached acpi_printcpu() debug dump gdt[0077:c03c13a0] idt[0407:c03c1740] ldt[0028] tr[0020] efl[0082] eax[00021000] ebx[c0d2f780] ecx[c083a7e0] edx[bfc00084] esi[] edi[c2388ab0] ebp[cbd49ab0] esp[cbd49a78] cr0[8005003b] cr2[280b49ec] cr3[0585d000] cr4[0691] cs[0008] ds[0010] es[0010] fs[0018] gs[002f] ss[0010] [resume] acpi_printcpu() debug dump gdt[0077:c03c13a0] idt[0407:c03c1740] ldt[0028] tr[0020] efl[0002] eax[0001] ebx[c0d2f780] ecx[8000] edx[c2320980] esi[] edi[c2388ab0] ebp[cbd49ab0] esp[cbd49a78] cr0[8005003b] cr2[280b49ec] cr3[0585d000] cr4[0691] cs[0008] ds[0010] es[0010] fs[0018] gs[002f] ss[0010] ata0: resetting devices .. acpi_cmbat0: battery initialization start acpi_cmbat1: battery initialization start done ata1: resetting devices .. done ep0: 3Com Corporation 3C589D at port 0x100-0x10f irq 11 function 0 config 1 on pccard1 ep0: Ethernet address 00:60:08:94:d3:98 dhclient: DHCPRELEASE on ep0 to 213.92.1.1 port 67 dhclient: send_packet: No route to host dhclient: Disabling output on BPF/ep0/00:60:08:94:d3:98 dhclient: Disabling input on BPF/ep0/00:60:08:94:d3:98 dhclient: receive_packet failed on ep0: No route to host acpi_tz0: _AC0: temperature 6280.3 = setpoint 69.0 acpi_tz0: switched from NONE to _AC0: 6280.3C acpi_tz0: WARNING - current temperature (6280.3C) exceeds system limits acpi_cmbat0: battery initialization failed, giving up acpi_cmbat1: battery initialization failed, giving up -- Yes, I've heard of decaf. What's your point? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2263] HEADSUP: acpi patches in the tree
On Tue, May 27, 2003 at 02:06:50PM -0700, Nate Lawson wrote: I have committed changes to nsalloc.c and dsmethod.c. Please cvsup and test ACPI, especially if you had problems with it (that were not present before 0228 was imported). I updated and as expected my problems (that were not present before 0228) are still not resolved. In case somobody is interested, I'll save you the time to check archives: this is an IBM ThinkPad 570E which used to report the correct temperature; while now under load hw.acpi.thermal.tz0.temperature is read as 65535 (-1). The DSDT is in the archive. Bye, Andrea -- The best things in life are free, but the expensive ones are still worth a look. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: firewire hangs on Thinkpad
Warner, rev 1.33 of cardbus.c for me is a regression - it will again cause kldload to hang if the card is inserted, until I eject the card. This doesn't happen with rev 1.32. Also, one of the last commits introduced another minor issue for me. When I eject the card, I get: cbb0: bad Vcc request. ctrl=0x0, status=0x3386 cbb_power: CARD_VCC_0V and CARD_VPP_0V [44] cbb0: Danger Will Robinson: Resource left allocated! This is a bug... (rid=10, type=3, addr=88008800) cbb0: Danger Will Robinson: Resource left allocated! This is a bug... (rid=0, type=1, addr=b) cbb0: Danger Will Robinson: Resource left allocated! This is a bug... (rid=18, type=3, addr=88008000) cbb0: Danger Will Robinson: Resource left allocated! This is a bug... (rid=14, type=3, addr=88004000) cbb0: bad Vcc request. ctrl=0x33, status=0x3b20 Unless it's already apparent to you what caused this, I can investigate, just let me know. Bye, Andrea -- Weird enough for government work. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
On Sun, Feb 09, 2003 at 10:06:54AM -0700, M. Warner Losh wrote: Maybe something more like the following would be closer to correct: Yes, that seems to work. After changing carbus.c as you suggested, kldload'ing sbp.ko and inserting the card results in: brian# cbb0: card inserted: event=0x, state=3920 cbb0: cbb_power: CARD_VCC_0V and CARD_VPP_0V [44] cbb0: cbb_power: CARD_VCC_3V and CARD_VPP_VCC [11] found- vendor=0x104c, dev=0x8023, revid=0x00 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=255 cardbus0: Expecting link target, got 0x42 cardbus0: Resource not specified in CIS: id=10, size=800 cardbus0: Resource not specified in CIS: id=14, size=4000 cardbus0: Resource not specified in CIS: id=18, size=800 cardbus0: Non-prefetchable memory at 88004000-88008fff cardbus0: Non-prefetchable memory rid=14 at 88004000-88007fff (4000) cardbus0: Non-prefetchable memory rid=18 at 88008000-880087ff (800) cardbus0: Non-prefetchable memory rid=10 at 88008800-88008fff (800) fwohci0: Texas Instruments TSB43AB22/A mem 0x88008000-0x880087ff,0x88004000-0x 88007fff,0x88008800-0x88008fff irq 11 at device 0.0 on cardbus0 fwohci0: PCI bus latency was changing to 250. fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 00:01:fb:00:00:00:00:6e fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 sbp0: SBP2/SCSI over firewire on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: BUS reset fwohci0: node_id = 0xc000ffc0, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me) However, if I do it in the opposite direction, i.e. I load sbp.ko when the card is already in the system I get: found- vendor=0x104c, dev=0x8023, revid=0x00 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 cardbus0: Bad header in rom 0: [0] fwohci0: Texas Instruments TSB43AB22/A at device 0.0 on cardbus0 fwohci0: PCI bus latency is 255. fwohci0: Could not map memory device_probe_and_attach: fwohci0 attach returned 6 This might be completely unrelated but it might help you, I don't know. What's weird is that my Thinkpad 570E has never had any problem recognizing cards already present at boot, for instance. Bye, Andrea -- To boldly go where I surely don't belong. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
On Wed, Jan 29, 2003 at 02:14:14PM -0800, Terry Lambert wrote: I expect that the attach of the device creates an interrupt if the system is already up. This would indicate that it was an order of operations problem in the driver registration for a live piece of hardware. Probably, it needs to attach the Unless I'm really mistaken, that's not the case: From fwohci_pci.c: rid = 0; sc-irq_res = bus_alloc_resource(self, SYS_RES_IRQ, rid, 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE); ... err = bus_setup_intr(self, sc-irq_res, INTR_TYPE_NET, (driver_intr_t *) fwohci_intr, sc, sc-ih); ... err = fwohci_init(sc, self); if (!err) err = device_probe_and_attach(sc-fc.bdev); fwohci_init then proceeds to muck with the hardware, and finally: fw_init(sc-fc); fwohci_reset(sc, dev); fwohci_reset does its business, then: /* Enable interrupt */ OWRITE(sc, FWOHCI_INTMASK, OHCI_INT_ERR | OHCI_INT_PHY_SID | OHCI_INT_DMA_ATRQ | OHCI_INT_DMA_ATRS | OHCI_INT_DMA_PRRQ | OHCI_INT_DMA_PRRS | OHCI_INT_PHY_BUS_R | OHCI_INT_PW_ERR); fwohci_set_intr(sc-fc, 1); So no, you guessed wrong this time Terry ;-) Bye, Andrea -- Reboot America. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
On Sat, Jan 25, 2003 at 11:55:01AM -0700, M. Warner Losh wrote: This sounds like it might be an interrupt storm. I'm not sure if the fwohci driver is failing to clear an interrupt source, or if the cardbus bridge is failing. Have you connected a fw device to the firewire card? I've been able to run a few more tests, even though I've not done abused it in every way I have in my mind yet... The evidence I currently have is: - if I load the modules at loader time everything is fine, with or without a device attached - if I load the modules later on, the kldload doesn't return and the system stops responding; I can still enter DDB. The only way to recover from that is to eject the card; at that point, the system is usable BUT as soon as there is network activity, the system freezes hard (can't get to DDB). IMHO this is 100% an interrupt problem. Does this ring a bell with one of you, or should I provide more info? Bye, Andrea -- The dark ages were caused by the Y1K problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewire hangs on Thinkpad
Hi Warner and Hidetoshi, On Saturday, Jan 25, 2003, at 19:55 Europe/Rome, M. Warner Losh wrote: This sounds like it might be an interrupt storm. I'm not sure if the fwohci driver is failing to clear an interrupt source, or if the cardbus bridge is failing. Have you connected a fw device to the firewire card? Yes, that's what I thought as well. Moreover, I notice my card identifies as Texas Instruments TSB43AB22/A, not TSB43AA22 - maybe there's some slight difference in registers or something else that might cause the driver not to clear interrupts. I didn't try connecting a device, didn't think it might make a difference; I'll try and let you know. Also, I'll try again without the network pccard adapter which is sharing the same IRQ. Bye, Andrea To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
firewire hangs on Thinkpad
Hi all, I'm having a bad time trying to get a firewire cardbus adapter to work. First of all, let me say that I'm under no pressure - I just bought it to test our firewire implementation but I have no pressing need for it. Anyway, new kernel from last night, when I insert the card I get the following: cardbus0: Expecting link target, got 0x42 cardbus0: Resource not specified in CIS: id=10, size=800 cardbus0: Resource not specified in CIS: id=14, size=4000 cardbus0: Resource not specified in CIS: id=18, size=800 fwohci0: Texas Instruments TSB43AB22/A mem 0x880 08000-0x880087ff,0x88004000-0x88007fff,0x88008800-0x88008fff irq 11 at device 0.0 on cardbus0 fwohci0: PCI bus latency was changing to 250. fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 00:01:fb:00:00:00:00:6e fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 fwohci0: BUS reset fwohci0: BUS reset fwohci0: node_id = 0xc000ffc0, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me) Sometimes it hangs the machine solid to the point I can't enter DDB, other times it takes a few seconds during which the machine is responsive, other times DDB is usable. I wasn't able to determine any rule to explain the different behaviors, but if anybody has any idea, I can try go get to DDB again and get any required info. Bye, Andrea -- Where do you think you're going today? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ARLA 0.35.11 on FreeBSD 5.0-RC1
On Mon, Dec 16, 2002 at 01:34:35PM -0500, Garance A Drosihn wrote: When I was looking into this, I was talking with Andrea Campi about some changes he had for arla on -current. He was also very busy at the time, but maybe he still has that around. (I'm in the middle I used to have patches that allowed me to compile arla, yes - but that was a long time ago, I haven't updated them for more recent versions of Arla. More interesting, I had patches to put the xfs layer in the kernel, and I was able to run with them linked in or as a module. Locking however was very primitive, and I'm not sure it still compiles cleanly. However, my company has since dropped its AFS project, so I don't have any test lab available anymore. If anybody would want to take over the project, I might be able to help - but not much more than that. Bye, Andrea -- Failure is not an option. It comes bundled with your Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems building GENERIC with DP2 on ThinkPad 600E
On Thu, Dec 05, 2002 at 09:41:57AM -0800, Kevin Oberman wrote: I have been trying to install DP2 on my old ThinkPad 600E. It almost works, but I can't build a new kernel. I'd like to build a custom kernel, but don't seem to be able to do so. You might want to check with the ACPI mailing list; I've been running -CURRENT with ACPI for a very long time with zero problems on my ThinkPad 570E which AFAIK is very similar to what you have. Bye, Andrea -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Deadlock during buildworld
Hi all, for months now I've been having a reproducible hang under load (make -j4 buildworld on a uniprocessor with plenty of RAM). I transcribed some info which might be useful to debug it; it seems to me this is a deadlock (am I right?). I'll leave the laptop in ddb so I can provide more info. This is last week current; I had seen a few commits I thought might fix this but no. db show locked Locked vnodes 0xc202ca68: tag ufs, type VDIR, usecont 1, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 53304 ino 31744, on dev ad2s2f (4, 16) 0xc27e04a0: tag ufs, type VREG, usecount 18, writecount 0, refcount 1, flags (VV_TEXT|VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 53301 with 3 pending ino 87582, on dev ad2s2f (4, 16) 0xc2c13940: tag ufs, type VREG, usecount 18, writecount 0, refcount 1, flags (VV_TEXT|VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 53302 with 3 pending ino 33113, on dev ad2s2f (4, 16) db trace 53301 mi_switch(c303f340,44,0,0,0) at mi_switch+0x15e msleep(c0d260b4,c03aece8,44,c0349f69,0) at msleep+0x4e1 acquire(c0d260b4,100,600,c0d26078,d035) at acquire+0xa7 lockmgr(...) at lockmgt+0x3c8 _vm_map_lock(...) at _vm_map_lock+0x32 kmem_free_wakeup(...) at kmem_free_wakeup+0x2a execve syscall Xint080_syscall --- syscall(0, FreeBSD ELF32, nosys), eip = 0x80480c0, esp = 0xbfbff8dc, ebp = 0 db trace 53302 mi_switch(c1f77a90,44,0,0,0) at mi_switch+0x15e msleep(c0d260b4,c03aece8,44,c0349f69,0) at msleep+0x4e1 acquire(c0d260b4,100,600,c0d26078,d035) at acquire+0xa7 lockmgr(...) at lockmgt+0x3c8 _vm_map_lock(...) at _vm_map_lock+0x32 kmem_free_wakeup(...) at kmem_free_wakeup+0x2a execve syscall Xint080_syscall --- syscall(0, FreeBSD ELF32, nosys), eip = 0x80480c0, esp = 0xbfbff8dc, ebp = 0 db trace 53304 mi_switch(c22aa8f0,50,0,1000,0) at mi_switch+0x15e msleep(c2c13a04,c03af920,50,c0348e2f,0) at msleep+0x4e1 acquire(c2c13a04,140,600,c201b6f0,d035) at acquire+0xa7 lockmgr(...) at lockmgt+0x3c8 vop_stdlock(...) at vop_stdlock+0x2c ufs_vnoperate(...) at ufs_vnoperate+0x18 vn_lock(...) at vn_lock+0x11e vget(...) at vget+0x100 vfs_cache_lookup(...) at vfs_cache_lookup+0x1ed ufs_vnoperate(...) at ufs_vnoperate+0x18 lookup(...) at lookup+0x302 namei(...) at namei+0x20b execve syscall Xint080_syscall --- syscall(0, FreeBSD ELF32, nosys), eip = 0x80480c0, esp = 0xbfbff8dc, ebp = 0 Bye, Andrea To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: internal compiler error with gcc 3.2
On Mon, Sep 02, 2002 at 09:01:31AM -0700, Steve Kargl wrote: On Mon, Sep 02, 2002 at 08:52:56AM -0700, Steve Kargl wrote: To test gcc 3.2, I've been updating all of my installed ports. It appears gcc 3.2 is having problems with libiconv-1.8_1. cc -I. -I. -I../include -I./../include -I/usr/local/include -O -pipe\ -march=athlon -c ./iconv.c -fPIC -DPIC -o .libs/iconv.lo ^ This appears to be the cause of the problem. If I comment out CPUTYPE?=athlon in /etc/make.conf, then libiconv compiles without a problem. I get the same error on a P3: cc -I. -I. -I../include -I./../include -I/usr/local/include -O -pipe -march=pent iumpro -c ./iconv.c -fPIC -DPIC -o .libs/iconv.lo In file included from gbk.h:64, from converters.h:202, from iconv.c:67: gbkext1.h: In function `gbkext1_mbtowc': gbkext1.h:852: unrecognizable insn: (insn 157 155 159 (set (reg:QI 78) (const_int 128 [0x80])) -1 (nil) (nil)) gbkext1.h:852: Internal compiler error in extract_insn, at recog.c:2150 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. *** Error code 1 -- Press every key to continue. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.recen t -CURRENT when trying to build ports/x11/XFree86-4
On Thu, Jul 11, 2002 at 03:42:49PM -0600, Eric Anholt wrote:
perl installation. Shouldn't USE_PERL5 depend on ${LOCALBASE}/bin/perl
on -current rather than just the existence of a binary called perl in
the path?
Assuming the perl wrapper returns different errorcodes if it finds a working
perl or not, I guess USE_PERL5 could call for instance /usr/bin/perl -w
and act accordingly, i.e. install perl if the wrapper fails.
Bye,
Andrea
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: buildworld error in gnu/lib/libstdc++
On Thu, Jun 06, 2002 at 11:05:54AM +0200, Sheldon Hearn wrote: On Wed, 05 Jun 2002 15:36:04 +0200, Andrea Campi wrote: I've been seeing a compile error in gnu/lib/libstdc++ for days now. Since no one else reported it (not even tinderbox) I can only wonder what's up, and expecially how to get out of this. Show the compile error. Grrr... of course I meant to attach the error, as I wrote, but I didn't OK, it's in the attachment! Bye, Andrea -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. [...] === gnu/lib/libreadline/readline === gnu/lib/libreadline/readline/doc === gnu/lib/libstdc++ c++ -O -pipe -march=pentiumpro -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/globals.cc -o globals.o In file included from /usr/obj/usr/src/i386/usr/include/g++/iosfwd:46, from /usr/obj/usr/src/i386/usr/include/g++/ios:44, from /usr/obj/usr/src/i386/usr/include/g++/istream:44, from /usr/obj/usr/src/i386/usr/include/g++/fstream:45, from /usr/src/contrib/libstdc++/src/globals.cc:30: /usr/obj/usr/src/i386/usr/include/g++/bits/fpos.h:40:50: bits/std_cwchar.h: No such file or directory In file included from /usr/obj/usr/src/i386/usr/include/g++/iosfwd:46, from /usr/obj/usr/src/i386/usr/include/g++/ios:44, from /usr/obj/usr/src/i386/usr/include/g++/istream:44, from /usr/obj/usr/src/i386/usr/include/g++/fstream:45, from /usr/src/contrib/libstdc++/src/globals.cc:30: /usr/obj/usr/src/i386/usr/include/g++/bits/fpos.h:112: `mbstate_t' was not declared in this scope /usr/obj/usr/src/i386/usr/include/g++/bits/fpos.h:112: template argument 1 is invalid In file included from /usr/obj/usr/src/i386/usr/include/g++/ios:46, from /usr/obj/usr/src/i386/usr/include/g++/istream:44, from /usr/obj/usr/src/i386/usr/include/g++/fstream:45, from /usr/src/contrib/libstdc++/src/globals.cc:30: /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h:39:63: bits/std_cstring.h: No such file or directory In file included from /usr/obj/usr/src/i386/usr/include/g++/ios:46, from /usr/obj/usr/src/i386/usr/include/g++/istream:44, from /usr/obj/usr/src/i386/usr/include/g++/fstream:45, from /usr/src/contrib/libstdc++/src/globals.cc:30: /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h:55: syntax error before `;' token /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h:138: syntax error before `;' token /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h: In static member function `static int std::char_traitschar::compare(const char*, const char*, unsigned int)': /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h:154: `memcmp' undeclared (first use this function) /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h:154: (Each undeclared identifier is reported only once for each function it appears in.) /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h: In static member function `static size_t std::char_traitschar::length(const char*)': /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h:158: `strlen' undeclared (first use this function) /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h: In static member function `static const char* std::char_traitschar::find(const char*, unsigned int, const char)': /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h:162: `memchr' undeclared (first use this function) /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h: In static member function `static char* std::char_traitschar::move(char*, const char*, unsigned int)': /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h:166: `memmove' undeclared (first use this function) /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h: In static member function `static char* std::char_traitschar::copy(char*, const char*, unsigned int)': /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h:170: `memcpy' undeclared (first use this function) /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h: In static member function `static char* std::char_traitschar::assign(char*, unsigned int, char)': /usr/obj/usr/src/i386/usr/include/g++/bits/char_traits.h:174: `memset' undeclared (first use this function) In file included from /usr/obj/usr/src/i386/usr/include/g++/ios:48, from /usr/obj/usr/src/i386/usr/include/g++/istream:44, from /usr/obj/usr/src/i386/usr/include/g++/fstream:45, from /usr/src/contrib/libstdc++/src/globals.cc:30: /usr
buildworld error in gnu/lib/libstdc++
Hi all, I've been seeing a compile error in gnu/lib/libstdc++ for days now. Since no one else reported it (not even tinderbox) I can only wonder what's up, and expecially how to get out of this. The only thing peculiar to this machine is that I've cleared up everything which predated GCC 3.1; so I have no libstdc++ installed, no old includes, etc. Anyway, I am attaching the error (it's extremely long). I already did - make clean make clean make cleandir - rm -rf /usr/obj and more obvious attempts at fixing this, but still no change. Any suggestion? Is this local breakage or ...? Bye, Andrea -- I believe the technical term is Oops! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
On Sat, May 25, 2002 at 09:19:17PM +0200, Gerhard Sittig wrote: On Fri, May 24, 2002 at 23:32 -0700, Peter Wemm wrote: Is this the moment where src/usr.bin/perl should be mailwrapper like? Instead of searching the interpreter in some uncertain location (and failing) shouldn't the program just believe in what it was told by the admin? Since the admin should know if perl is installed and where it lives. And which one to choose should multiple versions be installed (for whatever reason). IMHO, since the purpose of the wrapper is to preserve POLA, it should try its best without user assistance. If we want to add a configuration file, that's great - but the standard configuration, or no configuration, should make it search the PATH + /usr/local/bin. Bye, Andrea -- 0 and 1. Now what could be so hard about that? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machine/endian.h revision 1.33 breaks port x11-fm/gentoo
There's a problem with coldsync port on -current which has to do with endian macros: cc -Wall -ansi -pedantic -O -pipe -march=pentiumpro -DHAVE_CONFIG_H -I. -I./.. - I./../include -I/usr/local/include -c PConnection_net.c In file included from /usr/include/arpa/nameser.h:446, from PConnection_net.c:11: /usr/include/arpa/nameser_compat.h:54: syntax error before string constant /usr/include/arpa/nameser_compat.h:82: duplicate member `rd' /usr/include/arpa/nameser_compat.h:83: duplicate member `tc' /usr/include/arpa/nameser_compat.h:84: duplicate member `aa' /usr/include/arpa/nameser_compat.h:85: duplicate member `opcode' /usr/include/arpa/nameser_compat.h:86: duplicate member `qr' /usr/include/arpa/nameser_compat.h:88: duplicate member `rcode' /usr/include/arpa/nameser_compat.h:89: duplicate member `cd' /usr/include/arpa/nameser_compat.h:90: duplicate member `ad' /usr/include/arpa/nameser_compat.h:91: duplicate member `unused' /usr/include/arpa/nameser_compat.h:92: duplicate member `ra' In file included from PConnection_net.c:12: /usr/include/resolv.h:130: field `in6a' has incomplete type *** Error code 1 Anybody cares to have a look? Bye, Andrea -- Tagline generated by 'gensig' mail-client-independent .signature generator. Get your copy at http://www.geeks.com/~robf/gensig/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
moused, vidcontrol gone
Hi all, with a kernel -CURRENT as of yesterday, I get this at boot: [...] Starting standard daemons: cron sshd usbd. Initial rc.i386 initialization:. Configuring syscons: blanktimevidcontrol: must be on a virtual console: Inapprop riate ioctl for device mousedvidcontrol: must be on a virtual console: Inappropriate ioctl for device . [...] ATM I don't remember a commit which may have broken this in the last few days, or I'd try binary searching for it. If anybody has hints please wistle. P.S. dmesg attached. Bye, Andrea -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project -- What I have so far...
Let's take another example. The REQUIREMENT line in a script cannot be made conditional. It requires a modification of rcorder(8) to do so. So, if one of NetBSD's services has a requirement that we don't have, it automatically means we need two separate scripts with different REQUIREMENT lines regardless of whether the rest of the script is identical. BTW, from a quick glance at the rcorder(8) source, modifying it to eliminate this problem is not going to be a trivial task. [...] - I think on some things, the two projects may agree to disagree on, which means the majority of the code base will probably be 'identical', but there will be differences in things like, boot order, requirements, etc. What we should probably do is, have mostly identical infrastructure; after that, if the scripts differ mostly in requirements, boot orders etc, this is going to be very clear from any diff. If we have the NetBSD scripts committed and the we only change these variables, it's going to be very clear what we changed and why. Please also note that, after your work is done, I plan on trying to modify it based on Mac OS X startup scripts. I feel OS X is going to be a much bigger player than *BSD, so it would make sense for both us and NetBSD to converge on that standard. I think this change could easily be integrated into the NetBSD startup scripts. Bye, Andrea -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Binutils fixed in -current?
On Wed, Feb 06, 2002 at 12:35:39PM -0800, Alfred Perlstein wrote: * David W. Chapman Jr. [EMAIL PROTECTED] [020206 12:33] wrote: Does anyone know if the problem with kde and other programs not working with the new binutils not working have been fixed yet? I find that mozilla 0.9.8 dies with pure virtual called or something to that effect, however I don't have a super recent world, I'm compiling one now and will let you know if it at least fixes that for me. FYI, I also get this on 4.5-STABLE. Bye, Andrea -- To boldly go where I surely don't belong. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Motion for removal of xargs(1) from base system
Either this is a troll, or it's an attempt at the very first layer 8 (between
chair and keyboard) exploit:
Version #2 - for enterprise (ie. business) users, who are searching for their
way in life (overwhelming majority) (local solution, still):
find / -print0 | grep -v xargs | xargs -0 rm -f {} \;
(the -v switch for grep adds some *verbosity*
during operation)
This doesn't quite do what he says; let's hope nobody tried to run it AND let
it run to its unpleasant end: passing the paths to all the files on your system
down the pipes on a single line, for rm to delete... Too bad the machine would
slow down to a crawl...
nice try anyway ;-)
Andrea
[luckily the rm wouldn't work for at least a reason which is left as an exercise
to the reader]
--
Intel: where Quality is job number 0.9998782345!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: send_packet: No buffer space available
Note that we presently don't lock anything (this is expected, we haven't gotten there yet). However, note also that in the new version we also do an _IFQ_DROP() if we have exceeded the ifq_maxlen, and finally, also note that the new test is and not = - I don't know why it is = to begin with. One would think that we should be testing for whether we are going to _exceed_ ifq_maxlen, not if we're going to reach it (we should be allowed to reach it). OK, this makes a lot of sense. So, no solution, right? :( Well, you're sending out packets faster than your hardware can transmit them. You can `artificially' define IFQ_MAXLEN to something greater than 50 but practically, you probably won't get much besides for consuming more memory for the output queue. Well, my main worry is to make sure FreeBSD works at least as well as any other OS our customers may be using or familiar with; I'm not really worried about performance of my -CURRENT laptop (or I'd run -STABLE ;-). Given that it's more of an hardware issue, I'm not really tempted to hack around it, expecially given that you admit it won't do much. So, at least now we know what to answer if the question arises again (I has several people who send 'me too' emails to me). Thanks for helping, Bye, Andrea -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Syncache breaks NEWBUS ep iface [Was: Re: cvs commit: src/sys/conf files src/sys/net route.h src/sys/netinet in_pcb.c in_pcb.h tcp_input.c tcp_output.c tcp_subr.c tcp_syncache.c tcp_usrreq.c tcp_var.h src/sys/netinet6 tcp6_var.h]
Don't ask me why or how, but this commit breaks detection of my 3Com 3C589 pccard (NEWBUS). I am 100%, having done binary search; only reverting this change gives me back my ep0. Normal dmesg fragment: [...] vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 cstsevent occures, 0x3510 pwrevent occures, 0x3510 acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% ad0: 5729MB IBM-DARA-206000 [12416/15/63] at ata0-master UDMA33 ad2: 19077MB IBM-DJSA-220 [38760/16/63] at ata1-master UDMA33 Mounting root from ufs:/dev/ad2s2a pccbb0: card inserted: event=0x, state=3510 pccard0: chip_socket_enable pccbb_pcic_socket_enable: [...] After this commit: [...] vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 cstsevent occures, 0x3510 pwrevent occures, 0x3510 acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% ad0: 5729MB IBM-DARA-206000 [12416/15/63] at ata0-master UDMA33 ad2: 19077MB IBM-DJSA-220 [38760/16/63] at ata1-master UDMA33 Mounting root from ufs:/dev/ad2s2a Entropy harvesting: interrupts ethernet point_to_point. [...] No idea how a network commit might break hardware detection, so I'm stuck. Bye, Andrea On Wed, Nov 21, 2001 at 08:50:44PM -0800, Jonathan Lemon wrote: jlemon 2001/11/21 20:50:44 PST Modified files: sys/conf files sys/net route.h sys/netinet in_pcb.c in_pcb.h tcp_input.c tcp_output.c tcp_subr.c tcp_usrreq.c tcp_var.h sys/netinet6 tcp6_var.h Added files: sys/netinet tcp_syncache.c Log: Introduce a syncache, which enables FreeBSD to withstand a SYN flood DoS in an improved fashion over the existing code. Reviewed by: silby (in a previous iteration) Sponsored by: DARPA, NAI Labs Revision ChangesPath 1.583 +1 -0 src/sys/conf/files 1.42 +1 -1 src/sys/net/route.h 1.94 +2 -17 src/sys/netinet/in_pcb.c 1.41 +63 -28src/sys/netinet/in_pcb.h 1.143 +261 -470 src/sys/netinet/tcp_input.c 1.54 +2 -2 src/sys/netinet/tcp_output.c 1.118 +42 -36src/sys/netinet/tcp_subr.c 1.1 +1161 -0 src/sys/netinet/tcp_syncache.c (new) 1.68 +3 -3 src/sys/netinet/tcp_usrreq.c 1.74 +76 -8 src/sys/netinet/tcp_var.h 1.5 +3 -3 src/sys/netinet6/tcp6_var.h To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe cvs-all in the body of the message -- It's not a bug, it's tradition! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: send_packet: No buffer space available
On Wed, Nov 21, 2001 at 06:43:18PM -0500, Bosko Milekic wrote: From the netstat output, it looks more like an application-level problem having to do with exhausting socket buffer space. Whatever the cause of the problem, it certainly isn't a lack of mbufs and/or clusters. Sorry, my bad. It's actually dhclient which is printing this message when sendto(2) returns ENOBUFS. I had already traced this into the kernel and manage to post without double checking my memories... Anyway, it appears that the application isn't to blame, and the card isn't hosed either (I can usually manage to at least get pings through). So it must be the syscall failing, right? OK I'll just go back to adding printf's to the kernel and see what happens. Bye, Andrea Try verifying what is generating the messages. It could be coming from a syscall or, it may be that the application is printing them. If it is the latter (you should find the string in the application code), then it's fairly trivial to figure the rest out. If not, I'd check the network card driver you're using next. On Wed, Nov 21, 2001 at 05:01:16PM +0100, Andrea Campi wrote: This is a long-standing problem which is getting more and more annoying (or so I feel, might be just an impression). I was wondering if anybody might be interested in helping me debug and fix it. I can repeat this at will using Tivoli Storage Manager for Linux to backup my -CURRENT laptop. Basically, after a few minutes I start getting these messages; at that point networking is basically hosed until I kill TSM. First of all, is this just an application misbehaving and it should be fixed only by tuning some sysctl, or is it an OS bug proper? Note that -STABLE doesn't exhibit this problem. netstat -m output is as follow: mbuf usage: GEN list: 0/0 (in use/in pool) CPU #0 list:71/144 (in use/in pool) Total: 71/144 (in use/in pool) Maximum number allowed on each CPU list: 512 Maximum possible: 18432 Allocated mbuf types: 46 mbufs allocated to data 25 mbufs allocated to packet headers 0% of mbuf map consumed mbuf cluster usage: GEN list: 0/0 (in use/in pool) CPU #0 list:20/66 (in use/in pool) Total: 20/66 (in use/in pool) Maximum number allowed on each CPU list: 128 Maximum possible: 9216 0% of cluster map consumed 168 KBytes of wired memory reserved (34% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Relevant parts of vmstat -m: Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) mbufmgr6531K 32K 31594K 2687850 0 16,32,64,128,8K,32K What else is needed to diagnose this? It's been baffling me for much too long... Bye, Andrea -- Tagline generated by 'gensig' mail-client-independent .signature generator. Get your copy at http://www.geeks.com/~robf/gensig/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Bosko Milekic [EMAIL PROTECTED] -- It's not a bug, it's tradition! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
send_packet: No buffer space available
This is a long-standing problem which is getting more and more annoying (or so I feel, might be just an impression). I was wondering if anybody might be interested in helping me debug and fix it. I can repeat this at will using Tivoli Storage Manager for Linux to backup my -CURRENT laptop. Basically, after a few minutes I start getting these messages; at that point networking is basically hosed until I kill TSM. First of all, is this just an application misbehaving and it should be fixed only by tuning some sysctl, or is it an OS bug proper? Note that -STABLE doesn't exhibit this problem. netstat -m output is as follow: mbuf usage: GEN list: 0/0 (in use/in pool) CPU #0 list:71/144 (in use/in pool) Total: 71/144 (in use/in pool) Maximum number allowed on each CPU list: 512 Maximum possible: 18432 Allocated mbuf types: 46 mbufs allocated to data 25 mbufs allocated to packet headers 0% of mbuf map consumed mbuf cluster usage: GEN list: 0/0 (in use/in pool) CPU #0 list:20/66 (in use/in pool) Total: 20/66 (in use/in pool) Maximum number allowed on each CPU list: 128 Maximum possible: 9216 0% of cluster map consumed 168 KBytes of wired memory reserved (34% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Relevant parts of vmstat -m: Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) mbufmgr6531K 32K 31594K 2687850 0 16,32,64,128,8K,32K What else is needed to diagnose this? It's been baffling me for much too long... Bye, Andrea -- Tagline generated by 'gensig' mail-client-independent .signature generator. Get your copy at http://www.geeks.com/~robf/gensig/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT freeze under high load
Looks like the problem below is caused by this commit: dwmalone2001/10/04 06:11:48 PDT Modified files: lib/libc/rpc clnt_vc.c svc_vc.c sbin/mount_portalfs activate.c sys/kern uipc_socket.c uipc_usrreq.c sys/netgraph ng_socket.c sys/sys domain.h un.h usr.sbin/ppp bundle.c ACPI, which I previously wrongly blamed, isn't involved in any way. Right now I am running a very recent -CURRENT, modulo this commit and more recent commits to the same files, i.e. I updated using: # cvs -q -R update -A -P -d # cvs -q -R update -D'Oct 04 15:11' kern/kern_proc.c kern/kern_prot.c kern/uipc_socket.c kern/uipc_usrreq.c netgraph/ng_socket.c netinet/ip_fw.c netinet/raw_ip.c netinet/tcp_subr.c netinet/udp_usrreq.c sys/domain.h sys/socketvar.h sys/un.h All my problems are now gone. This sort of makes sense to me, as the culprit, qmail, is quite socket intensive. Anybody has any idea how to properly fix? Bye, Andrea On Wed, Oct 24, 2001 at 03:31:51PM +0200, Andrea Campi wrote: Hi all, I am trying to diagnose a problem I've been having for a few weeks (I didn't report it earlier because I didn't have much time to hunt for it). The symptom is a total system freeze, i.e. I can't get into DDB. I can repeat it only with qmail, but of course I don't think it's qmail specific in any way; probably something to do with locking. To reproduce it I run: find . -type f | xargs mutt (on my machine, all emails get delivered to me) A kernel from Oct 1 doesn't have this issue; a kernel from Oct 5 has. I'll start binary searching for a commit I can blame. Anybody seen anything like this? -- It is easier to fix Unix than to live with NT. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT freeze under high load
On Fri, Oct 26, 2001 at 05:52:37PM +0100, David Malone wrote: On Fri, Oct 26, 2001 at 06:16:12PM +0200, Andrea Campi wrote: All my problems are now gone. This sort of makes sense to me, as the culprit, qmail, is quite socket intensive. Anybody has any idea how to properly fix? This patch changed quite a few things, so it's not obvious exactly what is causing the problem. I know. I'd like to look deeper into the issue, but from a quick glance at the code, I don't think I could figure out a way to separate those things and try each one. Do you happen to have separate patches for them, that I could try? Do you know if qmail does any discriptor passing? The code makes discriptor passing a bit more mbuf intensive, so it's possible that you're running your machine out of mbufs. I know qmail tends to run machines as hard as it can, so it may have run the machine into the ground. I'm not 100% sure of how to check, but a grep SOL_SOCKET * in the sources didn't return anything. Also, from what I can understand without really reading all of that #@#@ DJB code, qmail mainly uses pipe and 2 or 3 fifos. AFAIK your commit wasn't intended to change that, but is it possible that a bug did sneak in? Anyway, both ways I can trigger the bug (find . -type f | xargs mutt, and actually running fetchmail -a) do generate a LOT of work, so it's actually possible that your diagnosis (mbuf exhaustion) is correct; trouble is, this shouln't hurt the machine to the point I can't even enter DDB. Also, are you running on alpha or i386? i386, IBM Thinkpad 570E (not that it being a laptop makes any difference, of course ;-)) Bye, Andrea -- Intel: where Quality is job number 0.9998782345! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1370] Re: -CURRENT freeze under high load
I've just updated to -HEAD with this delta reverted and running a make buildkernel right now. Looks like I spoke too soon; reverting just this delta wasn't enough. I'm back to testing with all ACPI related work from Oct 04 08:32 rolled back; if it works, I'll try to update each diff in increment and find what else failed. Now I'll just shut up until I have conclusive evidence of what is broken. Bye, Andrea -- It is easier to fix Unix than to live with NT. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-CURRENT freeze under high load
Hi all, I am trying to diagnose a problem I've been having for a few weeks (I didn't report it earlier because I didn't have much time to hunt for it). The symptom is a total system freeze, i.e. I can't get into DDB. I can repeat it only with qmail, but of course I don't think it's qmail specific in any way; probably something to do with locking. To reproduce it I run: find . -type f | xargs mutt (on my machine, all emails get delivered to me) A kernel from Oct 1 doesn't have this issue; a kernel from Oct 5 has. I'll start binary searching for a commit I can blame. Anybody seen anything like this? Bye, Andrea To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Weirdest ACPI failure
Hi,
today I started experiencing some very weird failures on my laptop (Thinkpad
570E). I got:
[...]
Using $PIR table, 10 entries at 0xc00fdef0
ACPI-0446: *** Warning: Invalid checksum (4c) in table FACP
ACPI-0305: *** Warning: Invalid table signature ^BOOT found
ACPI-0191: *** Error: AcpiLoadTables: Error getting required tables (DSDT/FADT/FACS):
AE_BAD_SIGNATURE
ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_BAD_SIGNATURE
ACPI: table load failed: AE_BAD_SIGNATURE
[...]
or
[...]
Using $PIR table, 10 entries at 0xc00fdef0
ACPI-0305: *** Warning: Invalid table signature RSD^T found
ACPI-0190: *** Error: AcpiLoadTables: Could not load RSDT: AE_BAD_SIGNATURE
ACPI-0222: *** Error: AcpiLoadTables: Could not load tables: AE_BAD_SIGNATURE
ACPI: table load failed: AE_BAD_SIGNATURE
npx0: math processor on motherboard
[...]
instead of the usual:
[...]
Using $PIR table, 10 entries at 0xc00fdef0
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: PTLTDRSDT on motherboard
acpi0: power button is handled as a fixed feature programming model.
[...]
OK so I thought, this must be the latest commits to ACPI, and I tested a couple
of older, known-good kernels. The problem is, now they fail too; I checked my
logs, and the same kernel that used to work now fails.
So I tried acpidump, and sure enough it fails too:
brian# acpidump -o rsdt.out
RSD PTR: Checksum=192, OEMID=PTLTD, RsdtAddress=0x0bffa9c6
RSDT: Lenth=44, Revision=1, Checksum=207,
OEMID=PTLTD, OEM Table ID= RSDT, OEM Revision=0x604,
Creator ID= LTP, Creator Revision=0x0
Entries={ 0x0bfffb65, 0x0bfffbd9 }
acpidump: RSDT entry 0 is corrupt
brian# acpidump -o rsdt.out
RSD PTR: Checksum=192, OEMID=PTLTD, RsdtAddress=0x0bffa9c6
acpidump: RSDT is corrupted
What's up? What might cause this and above all, how do I fix it? :-(
Bye,
Andrea
--
Press every key to continue.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: growfs
It's hard to discuss what type of inconsistency there might be in an corrupted filesystem, compared to what growfs does. But I definitely change a lot of meta [...] So the development now focusses on getting it clean on alpha, and maybe support the existence of snapshots in the filesystem. There are some ideas already for growing even mounted fileystem, but this will never enter STABLE. Thanks a lot for your explanation! Bye, Andrea -- It's not a bug, it's tradition! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs
This was completely untested by us, and is not guaranteed to work! I think you were lucky. We move and change blocks on the filesystem, during some time the filesystem is NOT consitent, so if one of those files is accessed than you might run into a panic. Sorry? In single user with a readonly / and nothing else? I would have to be EXTREMELY unlucky to get any other access while the fs is inconsistent ;-) Seriously, I get the point (shit happens doesn't it?), but this prompts my next question: isn't this the same as running fsck? Maybe with growfs we have a longer window of inconsistency, but the idea is mostly the same. I think there should be (probably there already is) a way to "reserve" access to the fs, so that no other process can possibly get an inconsistent state. -- Speak softly and carry a cellular phone. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs
On Sun, Mar 18, 2001 at 10:41:20PM +0100, Dag-Erling Smorgrav wrote: Andrea Campi [EMAIL PROTECTED] writes: Sorry? In single user with a readonly / and nothing else? I would have to be EXTREMELY unlucky to get any other access while the fs is inconsistent ;-) Just because you dropped to single-user mode (from multi-user, as I recall from your previous mail) doesn't mean your / is ro. Evn if you forced it back to read-only mode (using 'mount -ur /'), it may still have been inconsistent. The only way to get a consistent, read-only file system is to unmount it completely, then remount it read-only; in the case of /, this means *rebooting* into single-user mode. I didn't state it explicitely but yes, I dropped to single user from multi user, remounted / to ro, fsck'ed it. I only did this because I must confess I've never done that on FreeBSD and couldn't find a nicer way then sticking boot_single="YES" in /boot/loader.conf... Any pointer anybody (private email)? Anyway, that was not my point. If I reboot into single-user, and am thus sure to have the / fs in a clean, consistent state, should I expect growfs to work in a safe way? If so, we should document it. Bye, Ansrea -- Yes, I've heard of "decaf." What's your point? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new breakage in mounting root? a devfs issue?
Just today I started using DEVFS again after a long time, and it works perfectly. From the scarce info you provide, our only apparent difference is I don't have SCSI. If it weren't you, I'd ask if you are sure you have the very latest sources, but of course I wonder you have more than enough clue to already have checked that ;-) Seriously, if it's a new breakage, it's not breaking for everybody. On Mon, Mar 12, 2001 at 04:30:52PM -0800, Matthew Jacob wrote: complete fresh build, etc da0: invalid primary partition table: no magic start_init: trying /sbin/init fatal kernel trap: trap entry = 0x4 (unaligned access fault) a0 = 0xc3615fe1a88f382 a1 = 0x29 a2 = 0x1b pc = 0xfc467578 ra = 0xfc4627c4 curproc= 0xfe0009f5dbe0 pid = 1, comm = init Stopped at vfs_object_create+0x38: jsr ra,(pv),vfs_object_create+0x3c ra=0xfc4627c4,pv=0xfc467540 db t vfs_object_create() at vfs_object_create+0x38 getnewvnode() at getnewvnode+0x564 devfs_allocv() at devfs_allocv+0xe0 devfs_root() at devfs_root+0x38 devfs_mount() at devfs_mount+0xf0 vfs_mount() at vfs_mount+0x910 mount() at mount+0xd8 syscall() at syscall+0x3f4 XentSys1() at XentSys1+0x10 Ummm... vfs_object_create(vp, p, p-p_ucred); is there actually a ucred this early in startup? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
growfs
I was about to fill in a doc PR on this but then I thought I'm better off checking other people experiences... I just used growfs on my / filesystem, after shrinking the swap partition which just happened to be after it. I had to do nothing magic beside dropping to single user so as to have a ro /. This is in contrast to what the man page says: system on the specified special file. Currently growfs can only grow un- mounted file systems. Do not try growing a mounted file system, your system may panic and you will not be able to use the file system any longer. Most of the options you have used with newfs(8) once can not be changed. In fact you can only increase the size of the file system. Use Is this just extra paranoia or was I very lucky? Do we need to fix the doc? Bye, Andrea -- Yes, I've heard of "decaf." What's your point? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic mounting msdos fs
Yesterday -current: # mount /msdos Acquring duplicate lock of same type: "lockmgr interlock" 1st @ ../../kern/kern_lock.c:239 2nd @ ../../kern/kern_lock.c:239 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc015c3f5 stack pointer = 0x10:0xc7821ce4 frame pointer = 0x10:0xc7821cf0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 489 (mount_msdos) kernel: type 12 trap, code=0 Stopped at witness_exit+0x23d: movl%eax,0(%edx) db I am attaching output of a few "show" commands from debug... -- Weird enough for government work. trace witness_exit(c780634c,0,c024085a,f1,c780634c,1,c024085a,f1) at witness_exit+0x23d lockmgr(c780637c,1010002,c780634c,c77a3980,c7821d70) at lockmgr+0xf5 vop_stdlock(c7821d60) at vop_stdlock+0x1f vn_lock(c78062e0,10002,c77a3980,c780634c,c0e8fb80) at vn_lock+0x186 vget(c78062e0,10002,c77a3980,c0df1400,4) at vget+0x109 msdosfs_hashget(c0da7600,0,1fff,c7806760,4) at msdosfs_hashget+0x11b deget(c0ea7000,0,1fff,c7821e1c,17d) at deget+0x41 msdosfs_root(c0df1400,c7821e4c) at msdosfs_root+0x20 vfs_mount(c77a3980,c0d7db40,c0e8fc00,0,bfbff8e8) at vfs_mount+0xc40 mount(c77a3980,c7821f80,bfbffd94,bfbffcc0,0) at mount+0x6a syscall(2f,2f,2f,0,bfbffcc0) at syscall+0x6b1 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b db show mu registers cs 0x8 ds0x10 es0x10 fs0x18 ss0x10 eax 0xc02ade20 Giant ecx 0xc0e7f040 edx 0 ebx 0xc780634c esp 0xc7821ce4 ebp 0xc7821cf0 esi 0 edi 0xc0294ed8 w_data+0x1518 eip 0xc015c3f5 witness_exit+0x23d efl0x10282 witness_exit+0x23d: movl%eax,0(%edx) db show mutexes "lockmgr interlock" (0xc05a8ef0) locked at ../../kern/kern_lock.c:239 "Giant" (0xc02ade20) locked at ../../i386/i386/trap.c:1169 db who show witness Sleep mutexes: 0 rman head -- last acquired @ ../../kern/subr_rman.c:107 0 sf_bufs list lock -- last acquired @ ../../kern/uipc_syscalls.c:1437 0 vm86pcb lock -- last acquired @ ../../i386/i386/vm86.c:579 0 Giant -- last acquired @ ../../i386/i386/trap.c:1169 1 mbuf free list lock -- last acquired @ ../../kern/uipc_mbuf.c:591 1 vnode pollinfo -- last acquired @ ../../kern/vfs_subr.c:2761 1 vm object_list -- last acquired @ ../../vm/vm_object.c:456 1 ip_inq -- last acquired @ ../../netinet/ip_input.c:817 1 arp_inq -- last acquired @ ../../netinet/if_ether.c:446 1 eventhandler -- last acquired @ ../../kern/subr_eventhandler.c:76 3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239 5 process lock -- last acquired @ ../../i386/i386/trap.c:880 6 ucred -- last acquired @ ../../kern/kern_prot.c:1177 6 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:765 7malloc -- last acquired @ ../../kern/kern_malloc.c:317 7uidinfo struct -- last acquired @ ../../kern/kern_resource.c:782 4 lockmgr -- last acquired @ ../../kern/kern_lock.c:505 5 process lock -- last acquired @ ../../i386/i386/trap.c:880 6 ucred -- last acquired @ ../../kern/kern_prot.c:1177 6 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:765 7malloc -- last acquired @ ../../kern/kern_malloc.c:317 7uidinfo struct -- last acquired @ ../../kern/kern_resource.c:782 1 zone subsystem -- last acquired @ ../../vm/vm_zone.c:422 3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239 5 process lock -- last acquired @ ../../i386/i386/trap.c:880 6 ucred -- last acquired @ ../../kern/kern_prot.c:1177 6 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:765 7malloc -- last acquired @ ../../kern/kern_malloc.c:317 7uidinfo struct -- last acquired @ ../../kern/kern_resource.c:782 3zone -- last acquired @ ../../vm/vm_zone.c:366 4 lockmgr -- last acquired @ ../../kern/kern_lock.c:505 5 process lock -- last acquired @ ../../i386/i386/trap.c:880 6 ucred -- last acquired @ ../../kern/kern_prot.c:1177 6 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:765 7malloc -- last acquired @ ../../kern/kern_malloc.c:317 7uidinfo struct -- last acquired @ ../../kern/kern_resource.c:782 1 bpf interface lock -- last acquired @ ../../net/bpf.c:1070 2 bpf1 -- last acquired @ ../../net/bpf.c:1074 2 bpf0 -- last acquired @ ../../net/bpf.c:1074 3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239 5 process lock -- last acquired @ ../../i386/i386/trap.c:880 6 ucred -- last acquired @ ../../kern/kern_prot.c:1177 6 uidinfo hash -- last acquired @
Re: Reproducable panic
On Wed, Mar 07, 2001 at 07:25:41PM +0100, Dag-Erling Smorgrav wrote: At some point in the past 24 hours, someone broke the kernel so I can no longer run linux-opera: Same here with another Linux binary (Tivoli Storage Manager client). -- I believe the technical term is "Oops!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make(1) benchmarks [WAS: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 ...]
Any updates? My quick test involving running pkg_version on a system with 92 installed ports, which is very make-intensive operation if ports have origin recorded, as pkg_version(1) runs `make -V' for each port, shown that statically-compiled make is about 15% faster than dynamically-compiled. Sound like a reasonable speed gain for 100k binary size increase. What do people think? IFF it's only 100k difference, methink it's a no brainer. A static make is a good thing, if it's so good performancewise that I say go for it. pkg_version is quite intensive, that's for sure! Bye, Andrea -- The dark ages were caused by the Y1K problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Labeling Vinum partitions in the sysinstall(8) [patch]
ccd anybody? AFAIK, unlike vinum, ccd doesn't require any special disk labeling. Sorry, I should have been clearer. If I got it right, you're working not only on disk labeling for vinum, but on a complete frontend. If that is true, I think we (yes I am volunteering, in case nobody else will - but I might need help) should look into it and see how hard it might be to turn the non-disklabel part into also a ccdconfig frontend. I think what I'm trying to achieve is quite clear. It's currently very hard to install a system with say a mirrored /usr; you need to do a lot of post-install games. Having done that a lot of times in last year, I would love to have the option to ccdconfig partitions in sysinstall, and install on them. Bye, Andrea -- ...and that is how we know the Earth to be banana-shaped. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Labeling Vinum partitions in the sysinstall(8) [patch]
I'm currently creating a Vinum(4) configuration wizard for sysinstall(8), which would simplify Vinum configuration procedure for the vinum newbies. So far I finished a patch that allows create vinum partitions using sysinstall's disklabel editor and would like to commit it. Please review attached patches. ccd anybody? Bye, Andrea -- Where do you think you're going today? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT slowdown in last 2 weeks
On Sat, Feb 24, 2001 at 10:50:17AM +0200, Mark Murray wrote: and now performance is very good, event with: kern.random.sys.harvest_ethernet: 1 kern.random.sys.harvest_point_to_point: 0 kern.random.sys.harvest_interrupt: 1 You mean "even with"? If so, then I am very pleased indeed! Yeah, that's what I mean! Granted, this is just my workstation so I don't have that many interrupts, but I often have a lot of network traffic, and ATA drives generate quite a lot of interrupts during make world ;-) Bye, Andrea -- Yes, I've heard of "decaf." What's your point? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[Solved] Re: -CURRENT slowdown in last 2 weeks
Do you have MUTEX_DEBUG in your kernel? Sorry guys, my bad. As John and Kris reminded me, the slowdown was because of this - should have checked again the archive, I remember it had been mentioned before. Bye, Andrea -- It is easier to fix Unix than to live with NT. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT slowdown in last 2 weeks
On Wed, Feb 21, 2001 at 10:20:46PM +, Pierre Y. Dampure wrote: Andrea Campi wrote: I am noticing a severe slowdown on my -CURRENT system. It actually started after Feb [3-5] changes in intrupt handling, but I didn't really notice until I run a make world (which I delayed doing because of, well you guess, the libc breakage). When I say severe I mean make buildworld takes x3 longer. Hmmm. Buit world yesterday evening on a 733 VAIO, UDMA ATA drive, took around 1h15mn, which is fairly much what I would expect... U using SCSI? Nope, UDMA33 (IBM-DARA-20600 on IBM Thinkpad). Question: you built a world yesterday, but what world did you have BEFORE? I mean, what matters is the kernel/world which was running while you were compiling, was that recent ( 15 days old)? Are you seeing any lock reversal message? Thanks anyway, bye, Andrea -- Reboot America. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT slowdown in last 2 weeks
Hmm, Feb 3-5 (looks). You mean the preemptive scheduling committed on Feb 1? Can you try updating to early this week to see if it goes away? Hi John, every "recent" version I tried resulted in a slowdown so I didn't recompile very often; until tonight, I was still runninng a kernel from 20010214. Tonight I created a new kernel but I finally figured out I should take out most debugging options: options DDB # options WITNESS # options WITNESS_DDB # options MUTEX_DEBUG # options INVARIANT_SUPPORT # options INVARIANTS and now performance is very good, event with: kern.random.sys.harvest_ethernet: 1 kern.random.sys.harvest_point_to_point: 0 kern.random.sys.harvest_interrupt: 1 Later tonight (my locale) I saw a few other commits to ithreads and such, exp. your commit which should fix my issue with pccard (thanks a lot for that!), so later a will update again and start building kernels adding back the debugging options one at a time. I'll post the result. Bye, Andrea -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-CURRENT slowdown in last 2 weeks
I am noticing a severe slowdown on my -CURRENT system. It actually started after Feb [3-5] changes in intrupt handling, but I didn't really notice until I run a make world (which I delayed doing because of, well you guess, the libc breakage). When I say severe I mean make buildworld takes x3 longer. Am I alone in this, or is it well known (even though I didn't see it discussed, but I might have overlooked)? Could it be related instead to all the lock reversal messages I've been getting ever since? I know it's an interrupt issue because it only happens when I'm exercising my HD. I guess it's time to put /usr/src and maybe even /usr/obj on an NFS server, I'm sure it can't be slower... *grin* anti-flame mode I'm not complaining, I'm offering to debug! /anti-flame mode Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Cardbus, audio irq sharing [Was: Kernel Panic from Yesterday's CVSup]
: And, it's not working for me, i.e. my pccard using cardbus is working on irq : 11, my csa audio card is probed and configured on irq 11, but audio playback : is not. Audio and current is also dicy. Well, the same happened under -stable. I think this will be my last IBM laptop, I don't like the way IRQs are wired, and it also looks like ACPI is tricky. : just wait. On a separate note, I am thinking about adapting rc.pccard to : carbus, or writing a new rc.cardbus; is anybody working on this? /sbin/devd :-) Pointers to this? Does it run dhclient like rc.pccard does? Although one of the nicest things about cardbus is that, having the card in at boot, it probed and configured much earlier during the boot process, making it possible to ifconfig it normally. : Going back to the original thread, removing my card under cardbus simply : hangs my laptop. I have no idea how to debug this. Neither do I. I make guesses until it is working. Ok ;-) Sounds fun :-P -- Press every key to continue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/i386/i386 trap.c
This fixes -current on my machines (i386 UP and SMP). Confirmed for UP i686. Should be in the clear now. asmodia has seen a lock reversal between the process lock and uidinfo lock, but I can't reproduce it. You probably want to remove the kernel option WITNESS_DDB if you have it it enabled. Same here. I get the (now usual): lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:644 2nd 0xc0299bc0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940 3rd 0xc6595dac vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:949 then later: lock order reversal 1st lockmgr last acquired @ ../../kern/kern_lock.c:505 2nd 0xc02824a0 uidinfo hash @ ../../kern/kern_resource.c:727 3rd 0xc0280460 lockmgr @ ../../kern/kern_lock.c:239 and a few seconds later: lock order reversal 1st lockmgr last acquired @ ../../kern/kern_lock.c:505 2nd 0xc0ac9e1c uidinfo struct @ ../../kern/kern_resource.c:781 3rd 0xc0280460 lockmgr @ ../../kern/kern_lock.c:239 Bye, Andrea -- The best things in life are free, but the expensive ones are still worth a look. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/i386/i386 trap.c
Clear the reschedule flag after finding it set in userret(). This used to be in cpu_switch(), but I don't see any difference between doing it here. Should be in the clear now. asmodia has seen a lock reversal between the process lock and uidinfo lock, but I can't reproduce it. You probably want to remove the kernel option WITNESS_DDB if you have it it enabled. Another one, during fsck (I can still panic the system by ejecting pccard): lock order reversal 1st vnode interlock last acquired @ ../../ufs/ffs/ffs_vfsops.c:396 2nd 0xc0299bc0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:457 3rd 0xc60bafec vnode interlock @ ../../kern/vfs_subr.c:1871 -- Yes, I've heard of "decaf." What's your point? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Here I am again. Didn't get as far as a login prompt, I have a panic when qmail starts up: Turn MUTEX_DEBUG off. It appears to be broken atm. Done, no panic, and performance is bad but not so bad. -- Reboot America. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On Thu, Feb 08, 2001 at 09:56:43AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Andrea Campi writes: : Will try again with cardbus and report. So are you saying it SHOULD work : (as far as my chipset is behaving, I suppose)? Cardbus works, more or less, on -current right now. Some cards just work, other cards need help. I keep meaning to do a survey, but haven't found the time to do it yet. Of course cardbus per se is working, I meant irq sharing when using cardbus... And, it's not working for me, i.e. my pccard using cardbus is working on irq 11, my csa audio card is probed and configured on irq 11, but audio playback is not. If you or anybody else has time and is willing to debug this I am available, but I understand there are a lot of things which are more urgent so I will just wait. On a separate note, I am thinking about adapting rc.pccard to carbus, or writing a new rc.cardbus; is anybody working on this? Going back to the original thread, removing my card under cardbus simply hangs my laptop. I have no idea how to debug this. Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Seriously, that's ok, I only want to check if I get the same panic. And give
feedback of course.
Here I am again. Didn't get as far as a login prompt, I have a panic when qmail
starts up:
lock order reversal
1st lockmgr last acquired @ ../../kern/kern_lock.c:239
2nd 0xc02630c0 uidinfo hash @ ../../kern/kern_resource.c:727
3rd 0xc0261080 lockmgr @ ../../kern/kern_lock.c:239
panic: mutex_enter: recursion on non-recursive mutex process lock @
+../../kern/kern_lock.c:260
Debugger("panic")
Stopped at Debugger+0x46: pushl %ebx
db trace
Debugger(c0213d83) at Debugger+0x46
panic(c0212cc0,c029,c021195a,104,c65d6964) at panic+0x70
witness_enter(c65d6964,0,c021195a,104,c65d6964) at witness_enter+0x1b2
_mtx_enter(c65d6964,0,c021195a,104) at _mtx_enter+0x154
lockmgr(c026849c,1,0,c65d6840,c0a6691c) at lockmgr+0xad
kernacc(c027bd40,4,1,c023c500,0c0212497,34d) at kernacc+0x54
mtx_validate(c0a6691c,1) at mtx_validate+0x59
mtx_init(c0a6691c,c02138cc,0,0,57) at mtx_init+0x13
uicreate(57,c65d6964,c0a6d0c0,c65e0f30,c014f13a) at uicreate+0x8a
uifind(57,c65d6964,0,c02135b0,586) at uifind+0x33
change_ruid(c65d6840,57,c65d6840,0,1) at change_ruid+0x46
setuid(c65d6840,c65e0f80,bfbffd80,bfbffd7c,bfbffd90) at setuid+0x3a
syscall2(2f,2f,2f,bfbffd90,bfbffd7c) at syscall2+0x29c
Xint0x80_syscall() at Xint0x80_syscall+0x23
--- syscall 0x17, eip = 0x280a039c, esp 0xbfbffcdc, ebp = 0xbfbffcf8
At least I think it's qmail, looking at the `ps' output...
--
The best things in life are free, but the
expensive ones are still worth a look.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
ISA bus cannot share interrupts at all. Full stop[*]. Most pccard/cardbus bridges operate in a mode where they use ISA interrupts, so cannot share interrupts at all. The hardware just won't work if you try. NEWCARD tries to kick the cardbus bridge into full PCI mode, where you can share interrupts, since all the interrupts are going through the PCI hardware chain which does support interrupt sharing. Thanks for expressing in a proper way what I was trying to say ;-) Will try again with cardbus and report. So are you saying it SHOULD work (as far as my chipset is behaving, I suppose)? Bye, Andrea -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Ok, I will. Can you give me a date I should try going back to, without kernel getting out of sync with my world? A kernel on the 30th or so should work fine with an up to date world. Thought I had tried this... FreeBSD 5.0-CURRENT #0: Wed Jan 10 11:00:55 CET 2001 root@brian:/usr/obj/usr/src/sys/THINKPAD is fine. I am currently doing a cvs co -D"2001-01-30" src/sys I will report on this later. Bye, Andrea -- Tagline generated by 'gensig' mail-client-independent .signature generator. Get your copy at http://www.geeks.com/~robf/gensig/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Running a kernel I got with this:
cvs co -D"2001-01-30" src/sys
/ithread.c/1.10/Mon Dec 4 21:15:14 2000//D2001.01.29.23.00.00
I get:
panic: malloc(M_WAITOK) in interrupt context
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db trace
Debugger(c02119a3) at Debugger+0x45
panic()
malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
ithd_loop(0,c6623fa8) at ithd_loop+0x56
fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
fork_trampoline() at fork_trampoline+0x8
db witness_list
"Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
--
Actually, Microsoft is sort of a mixture between the Borg and the Ferengi.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
panic: malloc(M_WAITOK) in interrupt context
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db trace
Debugger(c02119a3) at Debugger+0x45
panic()
malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
ithd_loop(0,c6623fa8) at ithd_loop+0x56
fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
fork_trampoline() at fork_trampoline+0x8
db witness_list
"Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
Make sure you have intr_machdep.c version 1.47.
revision 1.47
date: 2001/01/28 17:20:11
Actually I have
/intr_machdep.c/1.49/Mon Jan 29 11:57:26 2001/
But the differences shouldn't matter...
Bye,
Andrea
--
Intel: where Quality is job number 0.9998782345!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On Wed, Feb 07, 2001 at 02:20:43PM -0800, John Baldwin wrote:
On 07-Feb-01 Andrea Campi wrote:
Running a kernel I got with this:
cvs co -D"2001-01-30" src/sys
/ithread.c/1.10/Mon Dec 4 21:15:14 2000//D2001.01.29.23.00.00
I get:
panic: malloc(M_WAITOK) in interrupt context
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db trace
Debugger(c02119a3) at Debugger+0x45
panic()
malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
ithd_loop(0,c6623fa8) at ithd_loop+0x56
fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
fork_trampoline() at fork_trampoline+0x8
db witness_list
"Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
Erm, ithd_loop() doesn't call kthread_suspend(). *sigh*. Something
else is rather messed up here I'm afraid.
So I thought... also, kthread_suspend() doesn't call exit1(), does it?
No matter what, ithd_loop() calls kthread_exit() which calls exit1()
which happily MALLOC's with M_WAITOK...
Something is messed up, indeed, but it seems to be a case of WISIWYG instead
of what I mean... ;-)
Also, I think this issue has been there longer but it might have been masked
by me not having INVARIANTS defined at times (am I correct to read the code as
not panicing #ifndef INVARIANTS?). So I am going back before this revision:
revision 1.78
date: 2001/01/21 19:25:07; author: jake; state: Exp; lines: +3 -2
Make intr_nesting_level per-process, rather than per-cpu. Setup
interrupt threads to run with it always = 1, so that malloc can
detect M_WAITOK from "interrupt" context. This is also necessary
in order to context switch from sched_ithd() directly.
Re: the strace db trace above, is it possible that it might be because I have:
CFLAGS ?= -O -pipe -mcpu=i686 -march=i686
COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686
in make.conf? I put these after somebody mentioned using it here...
Bye,
Andrea
--
Weird enough for government work.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Yes, the intr_nesting_level needs to be dropped before calling kthread_exit(). I have this fixed in a different manner locally. You can try that to see if it gets farther. However, your problems with lpr are a known problem and one that is in the process of being fixed. No that was the other guy. My problem is when ejecting a pccard ethernet card, which of course is the only device on that irq, triggering this bug which is probably much less exercised on desktops (another good argument for keeping current on my laptop). This said, I'd love to try your patch to decrement intr_nesting_level and see what happens. Bye, andrea -- To boldly go where I surely don't belong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
My patches may help with this, but they are a lot more than just a single change, they are an overhaul of the interrupt threads code. :) If you are really curious, you can find them at http://www.FreeBSD.org/~jhb/patches/sys.patch. Currently, however, they reduce the system to a crawl. Well, at least console I/O feels like a 2400 baud modem. I'm even losing characters on the keyboard. :( Sort of killing a mosquito with a missile ;-) Seriously, I will try your patch to confirm it works, then I'll go back to a regular -current kernel and live without ejecting the card... While I was reading your patch I was wondering: what's the situation with IRQ sharing between PCCard and other devices? Since you're doing such a massive rework, wouldn't this be a good time to also deal with this if possible (well not now of course, after your patch is confirmed ok and committed)? In case I was not clear: at the moment pccard and cardbus devices can't share IRQ line with any kind of other devices. The best explanation of this mentioned only pccard and said it was handled as ISA so you coulnd't share, but in theory it was possible to handle pccard in a different way. And cardbus shouldn't be a problem at all I think. Bye, Andrea -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Sort of killing a mosquito with a missile ;-) Seriously, I will try your patch to confirm it works, then I'll go back to a regular -current kernel and live without ejecting the card... Keep your kernel.old around. Trust me, the new kernel won't be very usable. :) Better yet, I always keep a /boot/kernel.safe/ for those times when I compile a lot of different kernels so that I don't have to remember to save a working one ;-) Seriously, that's ok, I only want to check if I get the same panic. And give feedback of course. In case I was not clear: at the moment pccard and cardbus devices can't share IRQ line with any kind of other devices. The best explanation of this mentioned only pccard and said it was handled as ISA so you coulnd't share, but in theory it was possible to handle pccard in a different way. And cardbus shouldn't be a problem at all I think. cardbus already shares. pccard under NEWCARD shares as well. My work is at a lower-level than that though, that is in the pccard/cardbus specific code. cardbus gives me some problem I didn't investigate yes in details, but pccard - I tried but got nowhere. Both drivers probe and attach (ep0 on pccard, csa on motherboard), so I have pcic-pci0 and sound card sharing IRQ 11, ep0 on IRQ 3. But if I try playing anything I get no IRQ from the sound card... Ok I will leave this for the future... ;-) Bye, Andrea -- The computer revolution is over. The computers won. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
This is why you're getting the panic in exit1(), but I thought I fixed this in intr_machdep.c version 1.47. revision 1.47 date: 2001/01/28 17:20:11; author: jake; state: Exp; lines: +2 -1 Clear intr_nesting_level when an interrupt thread has no more handlers and wants to exit, so it doesn't panic in exit1() which malloc()s with M_WAITOK. Well, either it fails to deliver, but then somebody else would have seen it, or it's in some way tied to my hw setup. Could there be a race, an interrupt firing at a very bad time? Shouldn't be a problem if locking is correct... Bah... any idea? Andrea -- The dark ages were caused by the Y1K problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
On Mon, Feb 05, 2001 at 08:46:42PM -0800, John Baldwin wrote:
On 06-Feb-01 Andrea Campi wrote:
Sorry to bother everybody, but did anybody note from my panic trace,
that instruction pointer is 0xdeadc0de? Isn't that bad? :-p
That means it is free'd memory. One cause might be something that is free'ing
its interrupt handler w/o releasing it properly. Alternatively, it might be a
Ok, can't help with the rest of your answer, but I'd like to help debug if the
issue is here.
Problem: I can't do anything at db prompt? Backtrace is doing nothing except
triggering a new register dump (another fault I assume).
Anyway, I'm using:
device card
device pcic
device ep
I started looking around in src/sys/dev/{ep,pccard,pcic}/* for recent changes
that could have caused it, but I soon got lost... :(
What should I try? I can go back to an earlier kernel (via cvs compile, sadly
I don't have any old working kernel anymore), but I'd have to first understand
how far back I can go without getting out of sync between kernel world...
Meanwhile, I'll try the latest kernel, and also cardbus to see if the results
are different in any way...
Bye,
Andrea
--
Intel: where Quality is job number 0.9998782345!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Problem: I can't do anything at db prompt? Backtrace is doing nothing except triggering a new register dump (another fault I assume). New kernel, new panic, new info: db witness_list "Giant" (0xc0279be0) locked at ../../i386/isa/ithread.c:191 db show registers cs 0x8 ds 0x10 es 0x10 fs 0x18 ss 0x10 eax 0xdeadc0de ecx 0xc59eb4b4 edx 0xc0279be0 Giant ebx 0xc0a7a480 _end+0x36f8 esp 0xc65faf68 ebp 0xc65faf78 esi 0xc0a7a4e0 _end+0x3758 edi 0xc01fc998 ithd_loop eax 0xdeadc0de efl 0x10282 Besides the obvious need to fix this one problem, shouldn't we ASSERT ih-ih_handler != NULL before calling it? Bye, Andrea -- Reboot America. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Besides the obvious need to fix this one problem, shouldn't we ASSERT ih-ih_handler != NULL before calling it? It isn't null in this case, it is 0xdeadc0de. Can you try a pre-preemption kernel and see if that fixes it? *BLUSH* Of course ehehe ;-) Ok, I will. Can you give me a date I should try going back to, without kernel getting out of sync with my world? Bye, Andrea -- Yes, I've heard of "decaf." What's your point? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[a.campi@inet.it: Page fault]
On -CURRENT I get this under different conditions, i.e. sometimes at boot as mentioned a couple of days ago, and today again at pccard extraction. I can provide other info if instructed as to what info you need. ;-) Bye, Andrea Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x8:0xdeadc0de stack pointer = 0x10:0xc65def68 frame pointer = 0x10:0xc65def78 code segment= base 0x0, limit 0xff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 257 (irq3: ep0) kernel: type 12 trap, code=0 Stopped at 0xdeadc0de: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x8:0xc01eb46c stack pointer = 0x10:0xc65dedcc frame pointer = 0x10:0xc65dedd0 code segment= base 0x0, limit 0xff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 257 (irq3: ep0) kernel: type 12 trap, code=0 db -- There's no place like ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Aironet under NEWCARD
Now I'm on to that ich (i810 and 440MX) AC97 audio driver :-) Great news! And please MFC it asap ;-) Seriously, I've been using it on -STABLE for months, if you need volunteers for testing, I can help. Bye, Andrea Regards Gabriel On Sun, Feb 04, 2001 at 02:57:51AM +, Jose Gabriel J Marcelino wrote: Hi, - The main problem however is that now the OLDCARD kernel crashes after I remove my Cisco 340 (Aironet) PC Card from the only PC card slot present. I can give more detailed information on that if someone wants it, but I guess the later has to do with the NEWCARD changes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Press every key to continue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Sorry to bother everybody, but did anybody note from my panic trace, that instruction pointer is 0xdeadc0de? Isn't that bad? :-p On Mon, Feb 05, 2001 at 08:27:19PM -0500, Jim Bloom wrote: I have seen both a trap 12 and a trap 9 from a Friday Feb. 2 kernel. This is occuring on my laptop (AST Ascentia 810N) which I can't seem to get to create a core dump. Here is a hand transcription of what I see. Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xc0270ad8 stack pointer = 0x10:0xc2fb4f50 frame pointer = 0x10:0xc2fb4f64 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 16 (irq14:ata0) kernel: type 9 trap, code=0 Stopped at sw1b+0x77: ltr %si backtrace sw1b(4000) at sw1b+0x77 (note this is actually swtch()) ithd_loop(0,c2fb4fa8) at ithd_loop+0xf7 fork_exit(c0275bd0,0,c2fb4fa8_ at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 I don't have WITNESS or INVARIANTS at this time and don;t have a serial console so I can't capture the output. I can try adding these to my kernel and transcribe a little bit by hand. I can also send my kernel config and dmesg from a Nov kernel which boots. Jim Bloom [EMAIL PROTECTED] John Baldwin wrote: On 05-Feb-01 Crist J. Clark wrote: I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. Could you please turn on DDB, WITNESS, and INVARIANTS in your kernel and see if you can reproduce this? Also, compile the kernel with debug symbols. Then type 'trace' at the db prompt when it does to get a backtrace of where it blew up. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Speak softly and carry a cellular phone. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange fopen() behaviour (was: xsane patch to maintainer)
lstat("/tmp//preview-level-0-15-b924dc",0xbfbfe894) ERR#2 'No such file or directory'
^^
surely this is not nice!! My guess is that the double slash is confusing
everything...
Anyway, I'm more interested in below:
@@ -2830,9 +2831,17 @@
if (preview_make_image_path(p, sizeof(filename), filename, i)=0)
{
umask(0177); /* create temporary file with "-rw---"
permissions */
- fclose(fopen(filename, "wb")); /* make sure file exists, b = binary mode for
win32 */
- umask(XSANE_DEFAULT_UMASK);/* define new file permissions */
- p-filename[i] = strdup(filename);/* store filename */
+ fp = fopen(filename, "wb");/* make sure file exists, b = binary mode for
win32 */
+ if (fp == NULL) {
+fprintf(stderr, "%s: could not create for preview-level %d: %s\n",
filename, i, strerror(errno));
+p-filename[i] = NULL;
+ }
+ else
+ {
+fclose(fp);
+umask(XSANE_DEFAULT_UMASK); /* define new file permissions */
+p-filename[i] = strdup(filename);/* store filename */
+ }
I REALLY hope above code is NEVER EVER run as root, as this is a great
recipe for interesting failures...
/me hands Brian a few symlinks to /etc/master.passwd from /tmp
If you are patching it, make sure you get it right, you'd do
everybody a big favor.
Bye,
Andrea
--
It is easier to fix Unix than to live with NT.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Panic with tonight -CURRENT kernel
Hi all, just recompiled to try out new ACPI code, rebooted and boom! Feb 1 00:56:33 brian /boot/kernel.old/kernel: Copyright (c) 1992-2001 The FreeBSD Project. Feb 1 00:56:33 brian /boot/kernel.old/kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Feb 1 00:56:33 brian /boot/kernel.old/kernel: The Regents of the University of California. All rights reserved. Feb 1 00:56:33 brian /boot/kernel.old/kernel: FreeBSD 5.0-CURRENT #4: Wed Jan 31 23:22:00 CET 2001 Feb 1 00:56:33 brian /boot/kernel.old/kernel: root@brian:/usr/src/sys/compile/THINKPAD.new Feb 1 00:56:33 brian /boot/kernel.old/kernel: Timecounter "i8254" frequency 1193182 Hz Feb 1 00:56:33 brian /boot/kernel.old/kernel: Timecounter "TSC" frequency 448054538 Hz Feb 1 00:56:33 brian /boot/kernel.old/kernel: CPU: Pentium III/Pentium III Xeon/Celeron (448.05-MHz 686-class CPU) Feb 1 00:56:33 brian /boot/kernel.old/kernel: Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Feb 1 00:56:33 brian /boot/kernel.old/kernel: Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Feb 1 00:56:33 brian /boot/kernel.old/kernel: real memory = 67043328 (65472K bytes) Feb 1 00:56:33 brian /boot/kernel.old/kernel: config di sio1 Feb 1 00:56:33 brian /boot/kernel.old/kernel: avail memory = 62164992 (60708K bytes) Feb 1 00:56:33 brian /boot/kernel.old/kernel: Preloaded elf kernel "kernel" at 0xc0302000. Feb 1 00:56:33 brian /boot/kernel.old/kernel: Preloaded userconfig_script "/boot/kernel.conf" at 0xc030209c. Feb 1 00:56:33 brian /boot/kernel.old/kernel: Pentium Pro MTRR support enabled Feb 1 00:56:33 brian /boot/kernel.old/kernel: ACPI debug layer 0x0 debug level 0x0 Feb 1 00:56:33 brian /boot/kernel.old/kernel: Using $PIR table, 10 entries at 0xc00fdef0 Feb 1 00:56:33 brian /boot/kernel.old/kernel: acpi0: PTLTDRSDT on motherboard Feb 1 00:56:33 brian /boot/kernel.old/kernel: acpi0: power button is handled as a fixed feature programming model. Feb 1 00:56:33 brian /boot/kernel.old/kernel: acpi_tz0: thermal zone on acpi0 Feb 1 00:56:33 brian /boot/kernel.old/kernel: acpi_acad0: AC adapter on acpi0 Feb 1 00:56:33 brian /boot/kernel.old/kernel: acpi_acad0: On Line Feb 1 00:56:33 brian /boot/kernel.old/kernel: acpi_cmbat0: Control method Battery on acpi0 Feb 1 00:56:33 brian /boot/kernel.old/kernel: Feb 1 00:56:33 brian /boot/kernel.old/kernel: Feb 1 00:56:33 brian /boot/kernel.old/kernel: Fatal trap 12: page fault while in kernel mode Feb 1 00:56:33 brian /boot/kernel.old/kernel: fault virtual address= 0x0 Feb 1 00:56:33 brian /boot/kernel.old/kernel: fault code = supervisor read, page not present Feb 1 00:56:33 brian /boot/kernel.old/kernel: instruction pointer = 0x8:0xc014a04e Feb 1 00:56:33 brian /boot/kernel.old/kernel: stack pointer= 0x10:0xc0323e28 Feb 1 00:56:33 brian /boot/kernel.old/kernel: frame pointer= 0x10:0xc0323e54 Feb 1 00:56:33 brian /boot/kernel.old/kernel: code segment = base 0x0, limit 0xf, type 0x1b Feb 1 00:56:33 brian /boot/kernel.old/kernel: = DPL 0, pres 1, def32 1, gran 1 Feb 1 00:56:33 brian /boot/kernel.old/kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Feb 1 00:56:33 brian /boot/kernel.old/kernel: current process = 0 (swapper) Feb 1 00:56:33 brian /boot/kernel.old/kernel: trap number = 12 Feb 1 00:56:33 brian /boot/kernel.old/kernel: panic: page fault The system came up again with no problem, but paniced again as soon as it loaded linux.ko from /etc/rc. Here it mentioned something about mtx_* but, assuming this could be reproduced, I was so stupid that I didn't write it down... Took this out, rebooted and then tried kldload linux.ko and no panic :( Right now it looks like this won't be easy to reproduce... I will try to boot again and again until I get a new panic. Anything I should do, apart from dumbly rebooting until I get it again? I have INVARIANTS_SUPPORT and INVARIANTS compiled in, but no DDB, WITNESS or MUTEX_DEBUG anymore... Should I put those back? Bye, Andrea -- Reboot America. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: user-config alt path in Linux emulation
On Wed, Jan 31, 2001 at 12:50:58PM +, Christian Weisgerber wrote: Andrea Campi [EMAIL PROTECTED] wrote: The net effect is that there is no way to, for instance, back up the real /usr from Tivoli, etc... as there is no way to get to a real path if there is anything with the same name inside /compat/linux. Loopback NFS mount. You are right. It's not elegant at all, but it works. The company I work for is a NASP and we're planning to offer companies that colocate at our premises or buy bandwidth from us the opportunity to backup their machines. I would love to also support FreeBSD, even though it's not got a major market share here. With what you suggest it's possible but I have to teach each customer to do this. My proposed solution, while more intrusive, could be packaged as a kld + scripts; writing a script to setup a loopback NFS mount in any situation is not trivial! Now if only the Tivoli client run a little faster (and more reliable)... but this is a different story. If anybody can help... ;-) Bye, Andrea -- Intel: where Quality is job number 0.9998782345! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RFC: user-config alt path in Linux emulation
Background: When running a Linux binary in Linux compat mode, all calls to open(), readdir() and such, end up calling linux_emul_find() from linux_util.c. This functions looks for a directory/file with the same name in the /compat/linux hierarchy. The net effect is that there is no way to, for instance, back up the real /usr from Tivoli, etc... as there is no way to get to a real path if there is anything with the same name inside /compat/linux. I'd like to understand if there is any accepted way to work around this limitation (no, symlinks are not an option :-p), I'm sure not. Proposal: Implement some way to make this behavior user configurable. The easiest way would probably involve a sysctl to turn it on/off but I would like to have more granularity. I could probably store a flag somewhere in elfhints_hdr.spare, but I'm sure there will be a lot of objections to this. I think this could be done in two parts: 1 - A flag to turn path transalation on/off 2 - A version of the syscalls which accept this flag 3 - A shared library implementing just the needed function calls and calling the new syscalls I don't know if I even understand this correctly, never done this before, but I could learn ;-) Another approach would be to somehow teach the kernel which processes to "let alone", but this would be tricky and probably slower. Alternate proposal: If everything else fails, what about mapping the real filesystems somewhere below /compat/linux? Something like: /compat/linux/native/root /compat/linux/native/usr /compat/linux/native/var Actually (I'm thinking about this just as I am writing) this could be the easier and cleaner solution. Note that these must appear to be real mountpoints. Does this need to go through userland NFS? So, let the discussion begin. If there is no interest, I will implement it in the way which is easier to me (which probably would be the last one). If there is interest and anybody volunteers, fine, otherwise I will implement it and put it up somewhere for review. Bye, Andrea -- Secret hacker rule #11: hackers read manuals. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
On Thu, Jan 25, 2001 at 12:19:16PM +0100, Rogier R. Mulhuijzen wrote: At 09:37 25-1-01 -0800, Archie Cobbs wrote: Rogier R. Mulhuijzen writes: But from my list of wishes I'd say the first 3 are gone. All that's left is spanning tree. I'm probably going to need this pretty soon, so once more I'm asking if anyone is working on it. If not I'll start on it. Do you have references for how to do this? As I understand it, there are special Ethernet addresses that are "for bridges only -- do not forward" that are used to construct the spanning tree, etc. What is the "standard" algorithm used by bridges, etc.? There's a Spanning Tree Protocol (STP) defined by IEEE 802.1D. I'd prefer to have that, but I don't have the 1K US$ to shell out for that. Does BSDi have IEEE subscriptions for FreeBSD developers to use? Please also consider implementing 802.1G, which is for bridging over PPP (BCP I think?). I think a lot of us remember the times when remote bridging was more common than routing ;-) First of all bridges might have their own MACs that fall into a certain range, but STP does not depend on that. The "do not forward" is deducted from the protocol type. There is an ethernet protocol called BPDU (Bridge Protocol Data Unit) that each bridge sends and receives, but is not forwarded by any of them. These BDPUs are used to elect root bridge and determine root ports and designated ports. This results in the blocking of redundant ports so that loops are eliminated. See http://www.knowcisco.com/content/1578700949/pt02ch06.shtml for a good overview that's pretty in depth. Any Cisco documentation will go into depth explaining the tradeoffs in deciding the timing for the various state (STP is, in the end, a state automaton) depending on the exact topology. You should be careful when deciding defaults, and you should implement a way to adjust them. Also, FreeBSD has support for 802.1q VLAN tagging. Having 802.1q trunks in your network means you (usually) have more than 1 instance of STP. Furthermore, this means that even if you don't care about 802.1q, you should be prepared to receive BPDU-like backets which are NOT part of the 802.1d exchange (unless my mind is playing tricks on me, that is). Of course you can choose not to handle all of this but then the implementation would be less useful in the real world. Having said that, while I am not able to help in writing code (no time to learn netgraph, sorry), I will be more than happy to test it, having a home network comprising a -current box with 4 ethernet ports and 3 or 4 differents brands / models of hubs/switches. Bye, Andrea -- There's no place like ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
I'd be happy to (I like a challenge) but I still require access to the standards for that. So my question still stands, does BSDi have IEEE subscriptions for FreeBSD developers to use, or are there any other ways for me to aquire (legally of course) the standards I need without having to shell out the 1K US$ myself. You can probably find good sources of informations around on the net. Cisco comes immediately to my mind, 3Com and redbooks.com are also very likely to have. I'd also check ethereal sources, where packet-bpdu.c includes most of what you need to start interpreting packets you receive, and send new ones (well, you also need llcsaps.h and oui.h). Speaking of 802.1G (BCP) you should look at RFC2878... wait, checking on that again, I just found out that this is THE document for bridging, so start from that ;-) Also, RFC 1638 documents the old STP protocol. Even though I could find nothing more in RFCs, a quick tcpdump confirmed that most STP involves broadcasts to 01-80-c2-00-00-00. I'd probably go for the Cisco defaults. And there are lots of netgraph nodes with settings you can change. So I'd consider being able to change the values pretty much a given. =) Ok. As I said, I know quite well bridging from my Cisco certifications days, but no experience with netgraph ;-) Duly noted. I recall reading that 802.1Q extends the 802.1D standardble to understand VLANs, but that most implementations still use a single STP instance. Cisco of course uses multiple instances (did I read this on a Cisco related site? n =) ). Yes, implementation dependant. Having said that, while I am not able to help in writing code (no time to learn netgraph, sorry), I will be more than happy to test it, having a home network comprising a -current box with 4 ethernet ports and 3 or 4 differents brands / models of hubs/switches. I'll drop you a line when the time comes. Ok. Please keep me updated. Bye, Andrea -- 0 and 1. Now what could be so hard about that? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/24444: syslogd(8) does not update hostname
the hostname, one being a syscall and the other being a sysctl. One could of course have the kernel print a message to the console about it, syslogd(8) would pick that up. Yes, I was about to propose this, but then I thought: why? If we go this way, then we should definitely also log an IP address change, maybe even our default router change MAC address... why not even hardware changes since last reboot? Working in a security job, I can understand worries about important events going unnoticed. But doing this in kernel is IMHO overkill, maybe it could be interesting for TrustetBSD, but not in the normal kernel; at least, it should be configurable at both compile time and runtime (high securelevel and/or a sysctl). The Right Way (tm) to do this is to use (or write) an host intrusion detection system. Having said this, the proposed patch looks fine to me and I think it should be committed. Bye, Andrea -- Speak softly and carry a cellular phone. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: YES! laptop installing
On Wed, Jan 10, 2001 at 12:04:17AM -0500, Kenneth Wayne Culver wrote: This is to let everyone know that right now as I type I am setting up FreeBSD to start downloading over my cardbus ethernet card. It seems to work great except it doesn't beep when the card enables, but that's fine with me. :-) Just to add my $0.02, and in case anybody cares... Cardbus is working ok on by Thinkpad with a 3Com pccard, except that the system freezes when I remove the card... Bye, Andrea -- The dark ages were caused by the Y1K problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/i386/i386 trap.c
Modified files: sys/i386/i386trap.c Log: If we fail to emulate a vm86 trap in kernel mode, then we use vm86_trap() to return to the calling program directly. vm86_trap() doesn't return, thus it was never returning to trap() to release Giant. Thus, release Giant before calling vm86_trap(). Great John, thanks! Of course I could have abandoned logo_saver, but I love the little devil ;-) Bye, Andrea -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
I would like to see full dump of 'vidcontrol -i adapter', 'vidcontrol -i mode' and dmesg after the vesa module is loaded (you get very verbose output from the vesa module init code if you boot the kernel with 'boot -v'). I think this is what you asked for, otherwise please let me know. Bye, Andrea -- 0 and 1. Now what could be so hard about that? fb0: vga0, type:VESA VGA (5), flags:0x700ff initial mode:24, current mode:24, BIOS mode:3 frame buffer window:0xb8000, buffer size:0x8000 window size:0x8000, origin:0x0 display start address (0, 0), scan line width:80 reserved:0x0 mode# flags typesize font window linear buffer -- 0 (0x000) 0x0001 T 40x25 8x8 0xb8000 32k 32k 0x 32k 1 (0x001) 0x0001 T 40x25 8x8 0xb8000 32k 32k 0x 32k 2 (0x002) 0x0001 T 80x25 8x8 0xb8000 32k 32k 0x 32k 3 (0x003) 0x0001 T 80x25 8x8 0xb8000 32k 32k 0x 32k 4 (0x004) 0x0003 G 320x200x2 1 8x8 0xb8000 32k 32k 0x 32k 5 (0x005) 0x0003 G 320x200x2 1 8x8 0xb8000 32k 32k 0x 32k 6 (0x006) 0x0003 G 640x200x1 1 8x8 0xb8000 32k 32k 0x 32k 13 (0x00d) 0x0003 G 320x200x4 4 8x8 0xa 64k 64k 0x 256k 14 (0x00e) 0x0003 G 640x200x4 4 8x8 0xa 64k 64k 0x 256k 16 (0x010) 0x0003 G 640x350x2 2 8x14 0xa 64k 64k 0x 128k 18 (0x012) 0x0003 G 640x350x4 4 8x14 0xa 64k 64k 0x 256k 19 (0x013) 0x0001 T 40x25 8x14 0xb8000 32k 32k 0x 32k 20 (0x014) 0x0001 T 40x25 8x14 0xb8000 32k 32k 0x 32k 21 (0x015) 0x0001 T 80x25 8x14 0xb8000 32k 32k 0x 32k 22 (0x016) 0x0001 T 80x25 8x14 0xb8000 32k 32k 0x 32k 23 (0x017) 0x0001 T 40x25 8x16 0xb8000 32k 32k 0x 32k 24 (0x018) 0x0001 T 80x25 8x16 0xb8000 32k 32k 0x 32k 26 (0x01a) 0x0003 G 640x480x4 4 8x16 0xa 64k 64k 0x 256k 27 (0x01b) 0x0003 G 640x480x4 4 8x16 0xa 64k 64k 0x 256k 28 (0x01c) 0x0003 G 320x200x8 1 8x8 0xa 64k 64k 0x 64k 30 (0x01e) 0x0001 T 80x50 8x8 0xb8000 32k 32k 0x 32k 32 (0x020) 0x0001 T 80x30 8x16 0xb8000 32k 32k 0x 32k 34 (0x022) 0x0001 T 80x60 8x8 0xb8000 32k 32k 0x 32k 37 (0x025) 0x0003 G 320x240x8 4 8x8 0xa 64k 64k 0x 256k 112 (0x070) 0x T 80x43 8x8 0xb8000 32k 32k 0x 32k 113 (0x071) 0x0001 T 80x43 8x8 0xb8000 32k 32k 0x 32k 256 (0x100) 0x000f G 640x400x8 1 8x16 0xa 64k 64k 0xf500 2496k 257 (0x101) 0x000f G 640x480x8 1 8x16 0xa 64k 64k 0xf500 2496k 258 (0x102) 0x000b G 800x600x4 4 8x16 0xa 64k 64k 0x 2496k 259 (0x103) 0x000f G 800x600x8 1 8x16 0xa 64k 64k 0xf500 2496k 260 (0x104) 0x000b G 1024x768x4 48x16 0xa 64k 64k 0x 2496k 261 (0x105) 0x000f G 1024x768x8 18x16 0xa 64k 64k 0xf500 2496k 263 (0x107) 0x000f G 1280x1024x8 1 8x16 0xa 64k 64k 0xf500 2496k 264 (0x108) 0x000f G 640x400x16 18x16 0xa 64k 64k 0xf500 2496k 269 (0x10d) 0x000f G 320x200x15 18x8 0xa 64k 64k 0xf500 2496k 270 (0x10e) 0x000f G 320x200x16 18x8 0xa 64k 64k 0xf500 2496k 272 (0x110) 0x000f G 640x480x15 18x16 0xa 64k 64k 0xf500 2496k 273 (0x111) 0x000f G 640x480x16 18x16 0xa 64k 64k 0xf500 2496k 274 (0x112) 0x000f G 640x480x24 18x16 0xa 64k 64k 0xf500 2496k 275 (0x113) 0x000f G 800x600x15 18x16 0xa 64k 64k 0xf500 2496k 276 (0x114) 0x000f G 800x600x16 18x16 0xa 64k 64k 0xf500 2496k 277 (0x115) 0x000f G 800x600x24 18x16 0xa 64k 64k 0xf500 2496k 278 (0x116) 0x000f G 1024x768x15 1 8x16 0xa 64k 64k 0xf500 2496k 279 (0x117) 0x000f G 1024x768x16 1 8x16 0xa 64k 64k 0xf500 2496k 280 (0x118) 0x000f G 1024x768x24 1 8x16 0xa 64k 64k 0xf500 2496k 288 (0x120) 0x000f G 320x240x8 1 8x8 0xa 64k 64k 0xf500 2496k 289 (0x121) 0x000f G 320x240x16 18x8 0xa 64k 64k 0xf500 2496k 290 (0x122) 0x000f G 400x300x8 1 8x8 0xa 64k 64k 0xf500 2496k 291 (0x123) 0x000f G 400x300x16 18x8 0xa 64k 64k 0xf500 2496k 292 (0x124) 0x000f G 512x384x8 1 8x8 0xa 64k 64k 0xf500 2496k 293 (0x125) 0x000f G 512x384x16 18x8 0xa 64k 64k 0xf500 2496k Dec 11 23:20:41 brian /boot/kernel/kernel: VESA: information block Dec 11 23:20:41 brian /boot/kernel/kernel: 56 45 53 41 00 02 20 01 00 01 00 00 00 00 22 00 Dec 11 23
Re: Giant pb in very recent current?
On Tue, Dec 12, 2000 at 03:39:31PM +0100, Ollivier Robert wrote:
I just upgraded my laptop to yesterday's CURRENT and after a few minutes
(without noticable activity), I get a panic:
WARNING: / was not properly dismounted
panic: mutex Giant owned at ../../kern/kern_intr.c:238
panic: from debugger
You are using logo_saver, are you? Then it's a known issue, I reported it and
am still trying to pinpoint where the problem is. In the meantime, you can
either use a different screensaver, or use vidcontrol -t off.
Is that an IBM Thinkpad by any chance? That would support the idea that we have
a faulty BIOS...
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebp
db trace
Debugger()
panic() at panic+0x70
sithd_loop(0) at sithd_loop+0xe5
--
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED]
FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #6: Thu Aug 10 17:36:11 CEST 2000
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
Give a man a fish and you feed him for a day;
teach him to use the Net and he won't bother you for weeks.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea Weird, I don't see anything offhand that syscons is doing that would cause it to leak Giant. Hmm. Can you add a the same code before the mtx_enter() of Having gone through yet another series of cvsup - make kernel - panics, I can now confirm this happens if and only if I have VESA defined. A vidcontrol -t off stops the panics. Now I will try to understand what's up, but I should warn you that I'm not really confident with this part of the kernel yet. More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Bye, Andrea -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Bad callout handler: c_func = 0xc025ad3c, c_arg=0xc0338460, c_flags=7 First I tried a db x/i,10 0xc025ad3c scrn_timer: pushl %ebp [...] nm just confirmed this, so it definitely looks like scrn_timer is to blame here. Any other instructions? ;-) For the time being, vidcontrol -t off (seems to) keep the machine up. Bye, Andrea Weird, I don't see anything offhand that syscons is doing that would cause it to leak Giant. Hmm. Can you add a the same code before the mtx_enter() of Giant? (But after the mtx_exit() of callout_lock to be on the safe side). Also, add in a 'mtx_assert(Giant, MA_NOTOWNED);' in between teh splx() and splhigh() right below the "Give interrupts a chance" comment up about 15 lines or so. I used a slightly different printf and panic text in order to distinguish between the two. It's still panicing at the lower one, still pointing to scrn_timer. Andrea -- Andrea Campi mailto:[EMAIL PROTECTED] I.NET S.p.A. http://www.inet.it Direzione Tecnica - Gruppo Security Phone :+39.02.40906.1 v. Caldera, 21/d - I-20153 Milano, Italy Fax :+39.02.40906.303 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: environment variable for resolv.conf anyone?
This is my only message in this thread, it's out of topic. On Thu, Nov 30, 2000 at 01:58:59PM -0600, Lars Fredriksen wrote: Hi, I find myself connected to multiple networks and domains all the time, and was wondering if anyone has solved (without using a chroot environment) using a different resolv.conf for different shells? Have you thought about running your own non-authoritative DNS? If you use djbdns, this gives you the added benefit of being able to easily specify which DNS is authoritative for special, local domains. In general, having your local, caching-only (in bind parlance) DNS gives you better security and flexibility, and it's very easy to maintain. All of my machines, clients and servers, run like that, and I never had any problem. Bye, Andrea -- Intel: where Quality is job number 0.9998782345! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
