Re: Interrupt storm with MSI in combination with em1
2011/5/4 Jack Vogel jfvo...@gmail.com: This is the second report in a matter of a week perhaps about a problematic motherboard, I would like to know who makes them. Just for the record, the motherboard with which I had problems (I guess my problem is here referred) is VIA EPIA SN1. It's nothing new, and probably rarely used with additional PCIe cards, as this is embedded-like creature. Cheers, Wiktor Niesiobedzki ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: munmap cp [patch enclosed]
On Wed, Nov 12, 2003 at 08:18:05PM +0100, Dimitry Andric wrote:
On 2003-11-11 at 15:31:15 Wiktor Niesiobedzki wrote:
$ mkdir foo
$ cd foo
$ touch foo
$ cp foo foo2
cp: foo: Invalid argument
Anyway, cp (and possibly other tools which use munmap) will need to be
fixed. For now, I simply disabled the VM_AND_BUFFER_CACHE_SYNCHRONIZED
flag in the Makefile for cp, which simply disables the whole mmap'ing
stuff. I don't notice any difference without it...
I would still propose my one-line solution, to use mmap only when the file
size is greater than 0. As far as I looked into source tree, most usages of
munmap are in unsafe way - i.e. without checking the return value.
Is there someone willing to commit this trival change? For now, some number of
ports will refuse tu build/install.
Cheers,
Wiktor Niesiobedzki
PS. The acctual patch attached.
--- utils.c 2003/06/22 07:02:17 1.41
+++ utils.c 2003/11/11 14:32:17
@@ -133,7 +133,7 @@
* wins some CPU back.
*/
#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED
+ if (S_ISREG(fs-st_mode) fs-st_size = 8 * 1048576 fs-st_size 0) {
- if (S_ISREG(fs-st_mode) fs-st_size = 8 * 1048576) {
if ((p = mmap(NULL, (size_t)fs-st_size, PROT_READ,
MAP_SHARED, from_fd, (off_t)0)) == MAP_FAILED) {
warn(%s, entp-fts_path);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: unknown/reserved trap (trap number 30)
Hi,
Every time I try to do verbose boot my todays CURRENT panics with message:
panic: unknown/reserved trap
The normal boot process gives no error.
Panics occur durring GEOM setup. The other thing, is when I tried Oct 29'th
kernel, after boot -v (which succed) I got some new disks:
ad6s1da
ad6s1dd
And so on, which does not show up in normal boot process (regradless if this
if new kernel or from 29'th Oct)
Please let me know if there is any additional info I may provide.
Cheers,
Wiktor Niesiobdzki
The last lines of dmesg:
DUMMYNET initialized (011031)
IP Filter: v3.4.31 initialized. Default = pass all, Logging = enabled
lo0: bpf attached
ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin
ad0: setting PIO4 on VIA 8235 chip
GEOM: create disk ad0 dp=0xc2b37970
ad0: ST380011A/3.06 ATA-6 disk at ata0-mainstruction pointer =
0x8:0xc04d0a3d
stack pointer = 0x10:0xc0821b40
frame pointer = 0x10:0xc0821b44
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, IOPL = 0
current process = 0 (swapper)
trap number = 30
panic: unknown/reserved trap
And the backtrace:
panic: unknown/reserved trap
syncing disks, buffers remaining... 180 180 180 180 180 180 180 180 180 180
180 180 180 180 180 180 180 180 180 180
giving up on 147 buffers
Uptime: 21s
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from /boot/kernel/if_dc.ko...done.
Loaded symbols for /boot/kernel/if_dc.ko
Reading symbols from /boot/kernel/miibus.ko...done.
Loaded symbols for /boot/kernel/miibus.ko
Reading symbols from /boot/kernel/if_rl.ko...done.
Loaded symbols for /boot/kernel/if_rl.ko
Reading symbols from /boot/kernel/random.ko...done.
Loaded symbols for /boot/kernel/random.ko
Reading symbols from /boot/kernel/dummynet.ko...done.
Loaded symbols for /boot/kernel/dummynet.ko
Reading symbols from /boot/kernel/ipfw.ko...done.
Loaded symbols for /boot/kernel/ipfw.ko
#0 doadump () at /home/usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /home/usr/src/sys/kern/kern_shutdown.c:240
#1 0xc04c9470 in boot (howto=256) at
/home/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04c9858 in panic () at /home/usr/src/sys/kern/kern_shutdown.c:550
#3 0xc05e5092 in trap_fatal (frame=0xce564808, eva=0) at
/home/usr/src/sys/i386/i386/trap.c:823
#4 0xc05e4a62 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = 9600, tf_ebp =
-833206196, tf_isp = -833206220, tf_ebx = 1016, tf_edx = 1017, tf_ecx =
1021, tf_eax = 582, tf_trapno = 30, tf_err = 0, tf_eip = -1068692931,
tf_cs = 8, tf_eflags = 582, tf_esp = 9600, tf_ss = -833206136}) at
/home/usr/src/sys/i386/i386/trap.c:618
#5 0xc05d5b58 in calltrap () at {standard input}:94
#6 0xc05c10c0 in siocnputc (cd=0x0, c=50) at
/home/usr/src/sys/dev/sio/sio.c:3208
#7 0xc0503fda in cnputc (c=50) at /home/usr/src/sys/kern/tty_cons.c:571
#8 0xc04ec9fc in putchar (c=50, arg=0xce5649a4) at
/home/usr/src/sys/kern/subr_prf.c:348
#9 0xc04ed5f7 in kvprintf (fmt=---Can't read userspace from dump, or kernel
process---
) at /home/usr/src/sys/kern/subr_prf.c:760
#10 0xc04ec8e7 in printf (fmt=0x0) at /home/usr/src/sys/kern/subr_prf.c:299
#11 0xc04935fe in g_slice_config (gp=0xc2b49a80, idx=4, how=1,
offset=2147483648, length=21474836480, sectorsize=0, fmt=0x0) at
/home/usr/src/sys/geom/geom_slice.c:360
#12 0xc05cd252 in g_bsd_modify (gp=0xc2b49a80, label=0xc2b4d12c WEV\202) at
/home/usr/src/sys/geom/geom_bsd.c:159
#13 0xc05ce0b4 in g_bsd_taste (mp=0xc2b49a80, pp=0xce564c7c, flags=0) at
/home/usr/src/sys/geom/geom_bsd.c:568
#14 0xc049424d in g_new_provider_event (arg=0xc2b49e80, flag=0) at
/home/usr/src/sys/geom/geom_subr.c:344
#15 0xc04916f9 in one_event () at /home/usr/src/sys/geom/geom_event.c:182
#16 0xc04917c5 in g_run_events () at /home/usr/src/sys/geom/geom_event.c:202
#17 0xc04927e5 in g_event_procbody () at
/home/usr/src/sys/geom/geom_kern.c:134
#18 0xc04b1ed0 in fork_exit (callout=0xc04927c0 g_event_procbody, arg=0x0,
frame=0x0) at /home/usr/src/sys/kern/kern_fork.c:793
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
munmap cp
Hi,
The simple scenario:
$ mkdir foo
$ cd foo
$ touch foo
$ cp foo foo2
cp: foo: Invalid argument
The problem lies in:
src/bin/cp/utils.c:163
if (munmap(p, fs-st_size) 0) {
warn(%s, entp-fts_path);
rval = 1;
}
For the size 0, the munmap will return EINVAL. Returning now error leads us,
to think, that no file was copied.
My quick hack is to change the line 136:
if (S_ISREG(fs-st_mode) fs-st_size = 8 * 1048576) {
into:
if (S_ISREG(fs-st_mode) fs-st_size = 8 * 1048576 fs-st_size 0) {
Anyone feels like to look into it?
Cheers,
Wiktor Niesiobdzki
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP/STATUS: network locking
On Tue, Sep 16, 2003 at 09:29:07AM -0700, Sam Leffler wrote:
Please send me your kernel config and tell me again exactly what fails. I
will try to reproduce your problem.
Sam
After your yesterday/today commits, I got panic while doing netstat -an. On
the kernel from about two days ago, with manually added patches, the netstat
command render system unusable (with netstat process in LOCK state, or, in
other cases - (swi8: tty:sio clock) process in LOCK state). System has:
dc0: 3Com OfficeConnect 10/100B port 0xe400-0xe4ff mem 0xe900-0xe90003ff
irq 10 at device 18.0 on pci0
rl0: RealTek 8139 10/100BaseTX port 0xe800-0xe8ff mem 0xe9001000-0xe90010ff
irq 12 at device 19.0 on pci0
It acts as a home router to my DSL line (over PPPoE).
If there's any other information I may provide, please let me know.
Kernel config attached
Cheers,
Wiktor Niesiobdzki
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc018a11b
stack pointer = 0x10:0xcebaeae4
frame pointer = 0x10:0xcebaeaf8
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 = 2914 (sshd)
trap number = 12
panic: page fault
syncing disks, buffers remaining... 2236 2236
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc018a11b
stack pointer = 0x10:0xcd751c88
frame pointer = 0x10:0xcd751c9c
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 = 23 (irq12: rl0)
trap number = 12
panic: page fault
Uptime: 1h59m32s
Dumping 256 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0194ef0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc01952d8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc02a9e56 in trap_fatal (frame=0xcd751c48, eva=0) at
/usr/src/sys/i386/i386/trap.c:818
#4 0xc02a9493 in trap (frame=
{tf_fs = -1072037864, tf_es = 16, tf_ds = -847970288, tf_edi = 4, tf_esi = 16,
tf_ebp = -847962980, tf_isp = -847963020, tf_ebx = 0, tf_edx = -1070828335, tf_ecx =
-1030343792, tf_eax = 16, tf_trapno = 12, tf_err = 0, tf_eip = -1072127717, tf_cs = 8,
tf_eflags = 66195, tf_esp = 1242790725, tf_ss = 66572650}) at
/usr/src/sys/i386/i386/trap.c:251
#5 0xc02997a8 in calltrap () at {standard input}:102
#6 0xc018a559 in _mtx_lock_sleep (m=0x10, opts=0, file=0x0, line=0) at
/usr/src/sys/kern/kern_mutex.c:635
#7 0xc017f014 in ithread_loop (arg=0xc0eac600) at /usr/src/sys/kern/kern_intr.c:533
#8 0xc017dcc1 in fork_exit (callout=0xc017ee50 ithread_loop, arg=0x0, frame=0x0) at
/usr/src/sys/kern/kern_fork.c:796
(kgdb) fr 6
#6 0xc018a559 in _mtx_lock_sleep (m=0x10, opts=0, file=0x0, line=0) at
/usr/src/sys/kern/kern_mutex.c:635
635 propagate_priority(td);
(kgdb) l 635
630 * Save who we're blocked on.
631 */
632 td-td_blocked = m;
633 td-td_lockname = m-mtx_object.lo_name;
634 TD_SET_LOCK(td);
635 propagate_priority(td);
636
637 if (LOCK_LOG_TEST(m-mtx_object, opts))
638 CTR3(KTR_LOCK,
639 _mtx_lock_sleep: p %p blocked on [%p] %s, td, m,
(kgdb) fr 4
#4 0xc02a9493 in trap (frame=
{tf_fs = -1072037864, tf_es = 16, tf_ds = -847970288, tf_edi = 4, tf_esi = 16,
tf_ebp = -847962980, tf_isp = -847963020, tf_ebx = 0, tf_edx = -1070828335, tf_ecx =
-1030343792, tf_eax = 16, tf_trapno = 12, tf_err = 0, tf_eip = -1072127717, tf_cs = 8,
tf_eflags = 66195, tf_esp = 1242790725, tf_ss = 66572650}) at
/usr/src/sys/i386/i386/trap.c:251
251 trap_fatal(frame, eva);
(kgdb) p/x frame.tf_eip
$1 = 0xc018a11b
(kgdb) disass 0xc018a11b
Dump of assembler code for function propagate_priority:
0xc018a090 propagate_priority:push %ebp
0xc018a091 propagate_priority+1: mov%esp,%ebp
0xc018a093 propagate_priority+3: push %edi
0xc018a094 propagate_priority+4: push %esi
0xc018a095 propagate_priority+5: push %ebx
0xc018a096 propagate_priority+6: sub$0x8,%esp
0xc018a099 propagate_priority+9: mov0x8(%ebp),%ecx
0xc018a09c propagate_priority+12: movzbl 0xdd(%ecx),%esi
0xc018a0a3 propagate_priority+19: mov0x5c(%ecx),%ebx
0xc018a0a6 propagate_priority+22: lea0x0(%esi),%esi
0xc018a0a9 propagate_priority+25:
Re: HEADS UP! ATAng committed
On Sun, Aug 24, 2003 at 11:27:05AM +0200, Soren Schmidt wrote: ATAng has just been committed. You need to make world after this update as atacontrol etc needs to pick up the changes. After updating to ATAng my DVD drive isn't detected. I get following message: ata1-slave: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED Before it was: DVD-ROM LG DVD-ROM DRD-8120B at ata1-slave UDMA33 Is there anything I can do, to provide you more specific information, please contact me. Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: bremfree: removing a buffer not on a queue
Hi, I've got the following panic, when I ran out of space. My system is from about 17 Jun. It acts as a NFS and Samba server, but panic happend at night, when no activity on those daemons occurs. Write could happen through ssh (as I suppose). The filesystems are UFS1 and UFS2. The one, on which I suppose the write happend is UFS1. I do not have apropriate sources, so no debugging kernel version is available :/ Cheers, Wiktor Niesiobedzki $ uname -a FreeBSD portal 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Jun 18 02:39:29 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PORTAL i386 # gdb -k /boot/kernel/kernel vmcore.1 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd...(no debugging symbols found)... panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2f fault code = supervisor read, page not present instruction pointer = 0x8:0xc0238404 stack pointer = 0x10:0xccf56b5c frame pointer = 0x10:0xccf56b7c 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 = 3 (g_up) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue Uptime: 12d15h6m53s Dumping 256 MB ata1: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- Reading symbols from /boot/kernel/if_dc.ko...(no debugging symbols found)...done. Loaded symbols for /boot/kernel/if_dc.ko Reading symbols from /boot/kernel/miibus.ko...(no debugging symbols found)...done. Loaded symbols for /boot/kernel/miibus.ko Reading symbols from /boot/kernel/if_rl.ko...(no debugging symbols found)...done. Loaded symbols for /boot/kernel/if_rl.ko Reading symbols from /usr/obj/usr/src/sys/PORTAL/modules/usr/src/sys/modules/random/random.ko... (no debugging symbols found)...done. Loaded symbols for /usr/obj/usr/src/sys/PORTAL/modules/usr/src/sys/modules/random/random.ko Reading symbols from /usr/obj/usr/src/sys/PORTAL/modules/usr/src/sys/modules/dummynet/dummynet.ko... (no debugging symbols found)...done. Loaded symbols for /usr/obj/usr/src/sys/PORTAL/modules/usr/src/sys/modules/dummynet/dummynet.ko Reading symbols from /usr/obj/usr/src/sys/PORTAL/modules/usr/src/sys/modules/ipfw/ipfw.ko... (no debugging symbols found)...done. Loaded symbols for /usr/obj/usr/src/sys/PORTAL/modules/usr/src/sys/modules/ipfw/ipfw.ko Reading symbols from /usr/obj/usr/src/sys/PORTAL/modules/usr/src/sys/modules/nfsserver/nfsserver.ko... (no debugging symbols found)...done. Loaded symbols for /usr/obj/usr/src/sys/PORTAL/modules/usr/src/sys/modules/nfsserver/nfsserver.ko Reading symbols from /usr/obj/usr/src/sys/PORTAL/modules/usr/src/sys/modules/if_tun/if_tun.ko... (no debugging symbols found)...done. Loaded symbols for /usr/obj/usr/src/sys/PORTAL/modules/usr/src/sys/modules/if_tun/if_tun.ko Reading symbols from /boot/kernel/netgraph.ko...(no debugging symbols found)...done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_ether.ko...(no debugging symbols found)...done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/kernel/ng_pppoe.ko...(no debugging symbols found)...done. Loaded symbols for /boot/kernel/ng_pppoe.ko Reading symbols from /boot/kernel/ng_socket.ko...(no debugging symbols found)...done. Loaded symbols for /boot/kernel/ng_socket.ko #0 0xc019221b in doadump () (kgdb) bt #0 0xc019221b in doadump () #1 0xc019289d in boot () #2 0xc0192c59 in panic () #3 0xc01d8b50 in bremfreel () #4 0xc01d8a62 in bremfree () #5 0xc01dbf00 in getblk () #6 0xc01d8c22 in breadn () #7 0xc01d8bcc in bread () #8 0xc0229993 in ffs_update () #9 0xc023ee0f in ffs_fsync () #10 0xc023dd3f in ffs_sync () #11 0xc01f05eb in sync () #12 0xc01923bf in boot () #13 0xc0192c59 in panic () #14 0xc029db02 in trap_fatal () #15 0xc029d7e2 in trap_pfault () #16 0xc029d362 in trap () #17 0xc028db78 in calltrap () #18 0xc0238131 in softdep_disk_write_complete () #19 0xc01d93cb in vfs_backgroundwritedone () #20 0xc01dcf34 in bufdone () #21 0xc01dcec4 in bufdonebio () #22 0xc01dccdb in biodone () #23 0xc015cb2b in g_dev_done () #24 0xc01dccdb in biodone () #25 0xc015f420 in g_io_schedule_up () #26 0xc015f638 in g_up_procbody () #27 0xc017c5f0 in fork_exit () ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice bugs are fixed.
On Tue, Jun 17, 2003 at 03:51:32PM -0400, Jeff Roberson wrote: I am still not able to reproduce this. Can you update your sources? I commited some code just now that removed an external dependency from sched_nice(). This should make it more robust. With the new code, I'm also unable to reproduce the panic :) Thanks :) Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice bugs are fixed.
On Wed, Jun 18, 2003 at 02:43:43AM -0400, Jeff Roberson wrote: On Wed, 18 Jun 2003, Wiktor Niesiobedzki wrote: On Tue, Jun 17, 2003 at 03:51:32PM -0400, Jeff Roberson wrote: I am still not able to reproduce this. Can you update your sources? I commited some code just now that removed an external dependency from sched_nice(). This should make it more robust. With the new code, I'm also unable to reproduce the panic :) With LAZY_SWITCH enabled? Double checked - yes. No panic with LAZY_SWITCH. Wiktor ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice bugs are fixed.
On Tue, Jun 17, 2003 at 02:53:36AM -0400, Jeff Roberson wrote:
I'm seeing quite similar panic, when I do renice to lower (negative) value:
(Negative nice count.)
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc018b374 in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc018b6aa in panic () at ../../../kern/kern_shutdown.c:545
#3 0xc01926a3 in mi_switch () at ../../../kern/kern_synch.c:481
#4 0xc018b022 in boot (howto=256) at ../../../kern/kern_shutdown.c:312
#5 0xc018b6aa in panic () at ../../../kern/kern_shutdown.c:545
#6 0xc019dbe8 in kseq_nice_rem (kseq=0xc0312be0, nice=-10) at
../../../kern/sched_ule.c:324
#7 0xc019e2b5 in sched_nice (kg=0xfff6, nice=-20) at
../../../kern/sched_ule.c:809
#8 0xc0188eac in donice (td=0xc25fc850, p=0xc26c0790, n=-20) at
../../../kern/kern_resource.c:296
#9 0xc0188b43 in setpriority (td=0xc25fc850, uap=0xcdd65d14) at
../../../kern/kern_resource.c:205
#10 0xc0298b11 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 87, tf_esi = -10, tf_ebp =
-1077937064, tf_isp = -841589388, tf_ebx = -20, tf_edx = 0, tf_ecx = -1077937080,
tf_eax = 96, tf_trapno = 12, tf_err = 2, tf_eip = 671874691, tf_cs = 31, tf_eflags
= 659, tf_esp = -1077937108, tf_ss = 47}) at ../../../i386/i386/trap.c:1023
#11 0xc0288d9d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
The sources are from today. I also noticed, that 5.1-BETA (build around 9th of
May) is working correctly.
Also: I've noticed a strange behaviour - if I do nice -n -15 some_prog, it
will get a nice of -10, and similiar with any other nice values (it +5 from
what it suposed to be).
I shouldn't have spoke so soon. I am not able to reproduce this. Is it
on SMP or UP? Are you using either libthr or libkse? If you're not sure
what I'm talking about, you're using neither of them.
Machine is UP (Athlon XP 1600). Currently, I use libc_r.
Is there anything unusual about your environment? What are you using to
read the nice values?
My simple test, is to do following:
boot into single mode
nice -n -15 sleep 300
I use ps -l to get nice level.
renice -n -20 [pid of the sleep process] cause the panic.
Previously I was using CPUTYPE=athlon-xp to build the kernel, but after
switching to i686 the panic persists.
I'm attaching the full backtrace and result of call kseq_print(0).
Cheers,
Wiktor Niesiobedzki
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice bugs are fixed.
On Tue, Jun 17, 2003 at 03:51:32PM -0400, Jeff Roberson wrote: I am still not able to reproduce this. Can you update your sources? I commited some code just now that removed an external dependency from sched_nice(). This should make it more robust. Got it - its LAZY_SWITCH, without it - all is working fine, but when this option is set, I get panics. Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice bugs are fixed.
On Fri, Apr 11, 2003 at 04:40:17PM -0400, Jeff Roberson wrote:
On Fri, 11 Apr 2003, Steve Kargl wrote:
I started to recompile the kernel and while sitting here decided
to load linux-mozilla. The system rebooted before linux-mozilla
displayed a window. I'm not sure this ULE related.
Whoops. The system just panic after coming back up from
a linux-mozilla induce reboot. I've left the machine
at the db prompt.
Here's a hand transcribed backtrace.
panic: Negative nice count.
Stack backtrace
bactrace
panic
kseq_nice_rem
kseq_rem
sched_switchout
mi_switch
msleep
g_io_schedule_down
g_down_procbody
fork_exit
fork_trampoline
In ddb please type 'call kseq_print(0)' This is on UP right?
I'm seeing quite similar panic, when I do renice to lower (negative) value:
(Negative nice count.)
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc018b374 in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc018b6aa in panic () at ../../../kern/kern_shutdown.c:545
#3 0xc01926a3 in mi_switch () at ../../../kern/kern_synch.c:481
#4 0xc018b022 in boot (howto=256) at ../../../kern/kern_shutdown.c:312
#5 0xc018b6aa in panic () at ../../../kern/kern_shutdown.c:545
#6 0xc019dbe8 in kseq_nice_rem (kseq=0xc0312be0, nice=-10) at
../../../kern/sched_ule.c:324
#7 0xc019e2b5 in sched_nice (kg=0xfff6, nice=-20) at ../../../kern/sched_ule.c:809
#8 0xc0188eac in donice (td=0xc25fc850, p=0xc26c0790, n=-20) at
../../../kern/kern_resource.c:296
#9 0xc0188b43 in setpriority (td=0xc25fc850, uap=0xcdd65d14) at
../../../kern/kern_resource.c:205
#10 0xc0298b11 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 87, tf_esi = -10, tf_ebp =
-1077937064, tf_isp = -841589388, tf_ebx = -20, tf_edx = 0, tf_ecx = -1077937080,
tf_eax = 96, tf_trapno = 12, tf_err = 2, tf_eip = 671874691, tf_cs = 31, tf_eflags =
659, tf_esp = -1077937108, tf_ss = 47}) at ../../../i386/i386/trap.c:1023
#11 0xc0288d9d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
The sources are from today. I also noticed, that 5.1-BETA (build around 9th of
May) is working correctly.
Also: I've noticed a strange behaviour - if I do nice -n -15 some_prog, it
will get a nice of -10, and similiar with any other nice values (it +5 from
what it suposed to be).
Cheers,
Wiktor Niesiobedzki
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Wed, Jun 11, 2003 at 09:50:22PM -0700, Kris Kennaway wrote: On Wed, Jun 11, 2003 at 10:48:32PM -0600, Andrew Lankford wrote: Can you try backing out bsd.sys.mk to r1.26 and rebuild your world and kernel? Later versions of this file are causing strange problems with package builds. I was a little lazy and just backed out bsd.sys.mk to 1.26 as you suggested, rebuilt /usr/lib/ , /usr/include/, and ppp. My kernel is the same as last time. As a result, ppp's now up and running again. Thanks, that's actually more useful because it isolates the problem. It's probably something in ppp that is misbehaving with CSTD=c99. alloca(3) function is misbehaving in ppp (namely ether.c). Is this a compiler bug? Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serious ppp failure on 5.1
On Tue, Jun 10, 2003 at 10:48:31AM +0200, P. U. Kruppa wrote: ng_ether not found? could you try loading ng_ether manually and start ppp again? I tried kldload ng_ether.ko but it said it couldn't because this file already exists. Uli. I mentioned about this problem in my mail: [EMAIL PROTECTED] on Jun 9. The problem lies somewhere in alloca, I would suspect last commits to VM system by Alan Cox (I see no other candidates), but old binaries (compiled on older CURRENT) are working well when copied. So the problem lies in compiler??? Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Stack and alloca(3)
Hi hackers, After todays (Mon Jun 9 09:32:45) buildworld, ppp(8) stoped to service my PPPoE connection. After investigation I found, that the problem lies in lines 519-630 of ether.c. The problem is, that after memory is allocated with alloca(3), whatever is sprintf-ed to that frame, is lost. As a quick hack I changed the alloca with malloc(3) and ppp started to work correctly (I know, it is very nasty hack). I failed to tigger the bug in any of my test programs. Anyone is willing to help me to find the root cause of this bug? Note: world builded on 6 Jun was working correctly, so it is something in rather short timeframe. Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
IPFW/socheckuid() patch
Hi,
During my firewall configuration I noticed strange behaviour of ipfw option
uid.
ip_fw2.c:1513
#if __FreeBSD_version 500034
#define socheckuid(a,b) ((a)-so_cred-cr_uid == (b))
#endif
if (cmd-opcode == O_UID) {
match =
socheckuid(pcb-inp_socket,
(uid_t)((ipfw_insn_u32 *)cmd)-d[0]);
} else {
Whereas the /sys/kern/uipc_socket.c:1844
int
socheckuid(struct socket *so, uid_t uid)
{
if (so == NULL)
return (EPERM);
if (so-so_cred-cr_uid == uid)
return (0);
return (EPERM);
}
Definitions found in macro code and function are incompatible. Thus following
patch:
===
RCS file: /sys/kern/uipc_socket.c,v
retrieving revision 1.144
diff -u -r1.1 uipc_socket.c
--- uipc_socket.c 2003/02/17 22:37:58 1.144
+++ uipc_socket.c 2003/02/17 22:44:33
@@ -1848,6 +1848,6 @@
if (so == NULL)
return (EPERM);
if (so-so_cred-cr_uid == uid)
- return (0);
+ return (1);
return (EPERM);
}
Cheers,
Wiktor Niesiobędzki
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: IPFW/socheckuid() patch
On Mon, Feb 17, 2003 at 11:47:32PM +0100, Wiktor Niesiobedzki wrote:
[...]
There is an obvious mistake in patch (or change in ip_fw2.c should
be considered).
Cheers,
Wiktor Niesiobedzki
===
RCS file: sys/kern/uipc_socket.c,v
retrieving revision 1.144
diff -u -r1.144 sys/kern/uipc_socket.c
--- sys/kern/uipc_socket.c 2003/02/17 22:37:58 1.144
+++ sys/kern/uipc_socket.c 2003/02/17 22:56:41
@@ -1846,8 +1846,8 @@
{
if (so == NULL)
- return (EPERM);
- if (so-so_cred-cr_uid == uid)
return (0);
- return (EPERM);
+ if (so-so_cred-cr_uid == uid)
+ return (1);
+ return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI thermal panics ThinkPad 600X
On Sat, Feb 15, 2003 at 11:16:12PM +0200, Ruslan Ermilov wrote: Me being dumb. Forgot to comment out the apm disabled hint in /boot/device.hints. Still, scary things happen after resuming from zzz(8). ata1: resetting devices... forever. Did you happen to have: options AUTO_EOI_1 in your kernel configuration? Cheers, Wiktor Niesiobedzki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Required kernel config file change soon
On Sun, Jan 26, 2003 at 12:03:47AM -0500, Jeff Roberson wrote: I'm about to commit code that will make one of : options SCHED_4BSD or options SCHED_ULE As far as I see, SCHED_ULE scheduler doesn't take advantage of having more than 1 processor. During make -j 6 buildworld, and other process that consumes as much of computing power as he can, I get such output from top: CPU states: 36.0% user, 0.0% nice, 13.8% system, 2.5% interrupt, 47.7% idle Is it natural for this scheduler? Dmesg attached. Best regards, Wiktor Niesiobedzki Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #10: Mon Jan 27 08:06:28 CET 2003 root@portal:/usr/obj/usr/src/sys/PORTALSMP Preloaded elf kernel /boot/kernel/kernel at 0xc0439000. Preloaded elf module /boot/kernel/if_ed.ko at 0xc04390a8. Preloaded elf module /boot/kernel/miibus.ko at 0xc0439154. Preloaded elf module /boot/kernel/if_rl.ko at 0xc0439200. Preloaded elf module /boot/kernel/random.ko at 0xc04392ac. Preloaded elf module /boot/kernel/dummynet.ko at 0xc0439358. Preloaded elf module /boot/kernel/ipfw.ko at 0xc0439408. Preloaded elf module /boot/kernel/acpi.ko at 0xc04394b4. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (534.55-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 268369920 (255 MB) avail memory = 256094208 (244 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ABIT AWRDACPI on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 8 entries at 0xc00fd7e0 ACPI-0438: *** Error: Looking up [\\_PR_.CPU0] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed, AE_NOT_FOUND acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz ACPI-1287: *** Error: Method execution failed, AE_AML_UNINITIALIZED_LOCAL can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_UNINITIALIZED_LOCAL acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_tz0: thermal zone on acpi0 ACPI-0438: *** Error: Looking up [\\_PR_.CPU0] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed, AE_NOT_FOUND acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 19 - irq 2 IOAPIC #0 intpin 18 - irq 10 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 IOAPIC #0 intpin 16 - irq 11 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 7.2 (no driver attached) Timecounter PIIX frequency 3579545 Hz pci0: bridge, PCI-unknown at device 7.3 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0xc400-0xc4ff mem 0xdb40-0xdb4000ff irq 2 at device 9.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:02:44:45:6e:27 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xc800-0xc81f irq 10 at device 11.0 on pci0 ed0: address 52:54:05:f6:9c:6b, type NE2000 (16 bit) atapci1: HighPoint HPT366 ATA66 controller port 0xd400-0xd4ff,0xd000-0xd003,0xcc00-0xcc07 irq 10 at device 19.0 on pci0 ata2: at 0xcc00 on atapci1 atapci2: HighPoint HPT366 ATA66 controller port 0xe000-0xe0ff,0xdc00-0xdc03,0xd800-0xd807 irq 10 at device 19.1 on pci0 ata3: at 0xd800 on atapci2 fdc0: cannot reserve I/O port range (1 ports) sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: cannot reserve I/O port range (1 ports) pmtimer0 on isa0 orm0: Option ROMs at iomem 0xef000-0xe,0xc-0xc9fff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: cannot reserve I/O port range (6 ports) sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0
Dummynet messages
Hi,
sys/netinet/ip_dummynet.c:
975: if (q-avg = fs-max_th) { /* average queue = max threshold */
(...)
984:} else {
985:q-count = -1;
986: printf(- drop);
987:return 1 ;
989:}
is quite meaningless. Shouldn't be it at least DEB(printf(- drop)? Or
better drop - max_th exceeded?
Just a small proposition, I was quite confused, when I saw this message.
Best regards,
Wiktor Niesiobedzki
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: IPFW2 skipto + logging
On Tue, Jan 14, 2003 at 01:18:02PM +0300, Maxim Konovalov wrote: On 17:20+0100, Jan 13, 2003, Wiktor Niesiobedzki wrote: It seems, that now logging with skipto is working correctly (I get expected results), but funny thing, when there is no log rule, the skipto command won't work. Yes, my bad. Corrected patch: Now it's working correctly. Thanks. Wiktor Niesiobedzki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IPFW2 skipto + logging
On Sun, Jan 12, 2003 at 04:52:53PM +0300, Maxim Konovalov wrote: Hello, Please try a next patch: It seems, that now logging with skipto is working correctly (I get expected results), but funny thing, when there is no log rule, the skipto command won't work. Consider this results: portal# ipfw show 00100172 139364 skipto 400 log ip from 192.168.0.0/24 to 192.168.0.0/24 00101 0 0 skipto 400 log ip from 192.168.0.0/24 to 192.168.0.0/24 00102 0 0 skipto 400 log ip from 192.168.0.0/24 to 192.168.0.0/24 00400180 140052 allow ip from any to any 65535 0 0 deny ip from any to any and portal# ipfw show 00100186 140632 skipto 400 ip from 192.168.0.0/24 to 192.168.0.0/24 00101186 140632 skipto 400 ip from 192.168.0.0/24 to 192.168.0.0/24 00102186 140632 skipto 400 ip from 192.168.0.0/24 to 192.168.0.0/24 00103186 140632 skipto 400 ip from 192.168.0.0/24 to 192.168.0.0/24 00400192 141136 allow ip from any to any 65535 0 0 deny ip from any to any The second one, without logging is just not working now... Best regards, Wiktor Niesiobedzki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
IPFW2 skipto + logging
Hi, Rule of the format: ipfw add 100 skipto 400 log logamount 0 ip from 192.168.0.0/24 to 192.168.0.0/24 Will give this strange result: Nov 10 17:01:05 portal kernel: ipfw: 100 SkipTo 400 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 310 Pipe 2 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 320 Pipe 2 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 340 Pipe 3 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 340 Pipe 4 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 360 Pipe 4 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 380 Pipe 4 TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 Nov 10 17:01:05 portal kernel: ipfw: 800 Accept TCP 192.168.0.1:139 192.168.0.2:1170 out via ed0 So, clearly saying - will not work, the rule: ipfw add 100 skipto 400 ip from 192.168.0.0/24 to 192.168.0.0/24 is working correctly. Is there any problems with ACTION_PTR macro? Wiktor Niesiobedzki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
