Re: How can I know which files a proccess is accessing?
Note that problems with lsof are generally fixed by recompiling it. It
doesn't take well to upgrades of the OS underneath it.
On 6/7/06, Michael Hall [EMAIL PROTECTED] wrote:
On Wed, Jun 07, 2006 at 08:20:03AM -0700, pete wright wrote:
On 6/6/06, Darren Pilgrim [EMAIL PROTECTED] wrote:
Eduardo Meyer wrote:
Hello,
I need to know which files under /var a proccess (httpd here) is
acessing. It is not logs because I have a different partition for
logs.
gstat tells me that slice ad0s1h (my /var) is 100% frequently, and in
fact with fstat I can see a number of httpd proccesses running
accesing that. But fstat only shows me inodes and the mount point.
I need to know which files the proccesses are acessing.
find(1) can match inodes. A quick example:
fstat | grep 'httpd.*/var ' | awk '{print $6}' | xargs -n 1 sudo
find
-x /var -inum | sort -u
/var/log/httpd-error.log
/var/run/accept.lock.#
/var/tmp/apr8530d5
/var/tmp/aprF2Zs0e
Thanks for the oneliner Darren, that's going in my scripts dir right now
;)
Yes, it does look handy, another new usage for 'find'.
Typically a 'grep ... | awk ...' can be combined, resulting in a small
improvement:
fstat | awk '/httpd.*\/var/ { print $6 }' | xargs ...
--
Why doesn't Buick rhyme with quick?
Mike Hall
San Juan Island, WA
System Admin - Rock Island Communications [EMAIL PROTECTED]
System Admin - riverside.org, ssdd.org [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dual Opteron system will not run SMP
On 6/7/06, Pete French [EMAIL PROTECTED] wrote: If just non-ACPI isnt sufficient, the other thing SAFE does is turn off disk DMA. I have an as-yet unreleased system that has this same type of issue, and the problem is that two PCI device ID's are not recognized, so maybe that will be your problem. So, I got around to booting the system without ACPI and there are quite a number of 'unknown' reports at boot, viz: unknown: PNP0c01 can't assign resources (memory) unknown: PNP0303 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0400 can't assign resources (port) pciconf -l gives me 5 devices without drivers attached, these being: [EMAIL PROTECTED]:7:2: class=0x0c0500 card=0x13101462 chip=0x746a1022 rev=0x02 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 SMBus 2.0 Controller' class= serial bus subclass = SMBus [EMAIL PROTECTED]:7:3: class=0x068000 card=0x13101462 chip=0x746b1022 rev=0x05 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 ACPI System Management Controller' class= bridge [EMAIL PROTECTED]:10:1:class=0x080010 card=0x13101462 chip=0x74511022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X IOAPIC' class= base peripheral subclass = interrupt controller [EMAIL PROTECTED]:11:1:class=0x080010 card=0x13101462 chip=0x74511022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X IOAPIC' class= base peripheral subclass = interrupt controller [EMAIL PROTECTED]:6:0: class=0x03 card=0x13101462 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Rage XL PCI' class= display subclass = VGA I am assuming that it's only the two interrup controller ones which are likely to be causing the problems - but other people are using 8111/8131 based systems fine. Also I note that other SMP systems I have uuse 'none' as the driver for these chips. Does this help shed any more light at all ? You are right about what the suspect devices are, having IOAPICs unrecognized seems like it could be a problem. When you say others are using such systems, do you mean they are using them with FreeBSD RELEASE? If you want info on the missing ID's try pciids.sourceforge.net, however figuring out what to do may require some work. In the easy cases you find a driver that is good enough but just doesnt have these new ID's in it, and a simple entry or two in a array will get you going. Course there is also going to be the case where its not that easy... Fraid I can't be too much help beyond that, hope it gets you headed in a direction you need anyway. Good luck, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf buggy on 6.1-STABLE?
Mark Morley wrote: Wondering if this rings any bells for anyone: Yes it does... I had been seeing similar issues for some time on a couple HP Proliant servers - saw it in 5.4 as well - but have been attributing this to driver related issues (the bge driver in particular, which has seen many changes, fixes and enhancements in relatively recent history). In trying to isolate that particular problem I had been applying kernel updates regularly, pf was disabled along with a few other things (also switched from using mpd/netgraph to openvpn/udp), and the problem vanished at some point in between. I cannot definitely name pf as being the culprit as no testing of this was done at the time to confirm it. I had assumed the bge driver changes were responsible for things now working as they should. In addition to the occasional connection failure, I've also seen established connections broken (ssh, http, mysql/ssl and pptp/gre). This was causing havoc with mysql replication over the link, which became very brittle, and required manual fixing (it would get stuck, unable to read the last event in its relay log whenever a disconnection occurred and had to be manually pushed onto the next - mysql 5.0.[3 - .11 or so]). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf buggy on 6.1-STABLE?
On Wed, Jun 07, 2006 at 04:25:37PM -0700, Mark Morley wrote: Disabling pf with pfctl -d allows 100% of all connections to work, and as soon as we enable it we see connection failures again. I've tried changing the pf rule set in different ways, with and without scrubbing, with and without queues, even to the point where I have a single rule that just allows everything. It doesn't seem to matter what the rules actually are, just whether or not pf is enabled. Was that single pass rule using 'keep state'? There is a default limit of 10,000 state entries (configurable with 'set limit states' in pf.conf). A state entry persists for several seconds even after a connection is closed, so quickly establishing 10,000 connections could easily hit that limit. Enable pf and load an empty ruleset (pfctl -e -Fa). Note the output of pfctl -si . Then repeat the test. Then run pfctl -si again, and compare the output with the previous one. Are any counters increasing? Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: Fatal trap 12: page fault while in kernel mode (current process = 4254 (perl5.8.8))
Hi,
I experienced lots of kernel panic after I installed openwebmail on my
mail server.
The environment is :
[Mail Server] = [Mail Spool Server]
nfs
Mail Server: 6.1-RELEASE (panic 3 times a day)
Mail Spool Server: 6.0-RELEASE
I also installed www/apache20, mail/postfix.
The mount options is rw, quota (Yes, I used quota)
I have tried to replace my kernel, but GENERIC and custom kernels panic, too.
Please give me some advice :)
==
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x34
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc050f162
stack pointer = 0x28:0xd12519b8
frame pointer = 0x28:0xd12519c4
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 = 4254 (perl5.8.8)
trap number = 12
panic: page fault
KDB: stack backtrace:
kdb_backtrace(100,c24b4600,28,d1251978,c) at kdb_backtrace+0x29
panic(c0620009,c06413f8,0,f,c24aea9b) at panic+0xa8
trap_fatal(d1251978,34,c24b4600,c2330ce4,c) at trap_fatal+0x2a6
trap_pfault(d1251978,0,34) at trap_pfault+0x1d3
trap(d1250008,d1250028,c2060028,c708afb8,c708afb8) at trap+0x2fd
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc050f162, esp = 0xd12519b8, ebp = 0xd12519c4 ---
vfs_vmio_release(c708afb8) at vfs_vmio_release+0x12
getnewbuf(0,0,8000,8000,c8000) at getnewbuf+0x2b0
getblk(c29b4770,19,0,8000,0) at getblk+0x35c
nfs_getcacheblk(19,0,8000,c24b4600,8000) at nfs_getcacheblk+0x81
nfs_bioread(c29b4770,d1251cbc,2f,c2353b00,d1251bcc) at nfs_bioread+0x983
nfs_read(d1251bf4) at nfs_read+0x33
VOP_READ_APV(c2084d20,d1251bf4) at VOP_READ_APV+0x38
vn_read(c224fea0,d1251cbc,c2353b00,0,c24b4600) at vn_read+0x196
dofileread(c24b4600,3,c224fea0,d1251cbc,) at dofileread+0x85
kern_readv(c24b4600,3,d1251cbc,9013000,1000) at kern_readv+0x36
read(c24b4600,d1251d04,3,27,202) at read+0x45
syscall(c05f003b,3b,3b,806c200,3) at syscall+0x2b7
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (3, FreeBSD ELF32, read), eip = 0x282637df, esp =
0xbfbfe28c, ebp = 0xbfbfe2c8 ---
Uptime: 14h32m59s
Dumping 255 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 255MB (65280 pages) 240 224 208 192 176 160 144 128 112 96
80 64 48 32 16
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc04c8cfd in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc04c8fc4 in panic (fmt=0xc0620009 %s) at
/usr/src/sys/kern/kern_shutdown.c:558
#3 0xc06028b6 in trap_fatal (frame=0xd1251978, eva=52) at
/usr/src/sys/i386/i386/trap.c:836
#4 0xc06025e7 in trap_pfault (frame=0xd1251978, usermode=0, eva=52)
at /usr/src/sys/i386/i386/trap.c:744
#5 0xc0602201 in trap (frame=
{tf_fs = -786104312, tf_es = -786104280, tf_ds = -1039794136,
tf_edi = -955732040, tf_esi = -955732040, tf_ebp = -786097724, tf_isp
= -786097756, tf_ebx = -955732040, tf_edx = 4, tf_ecx = -1035254272,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068437150, tf_cs =
32, tf_eflags = 590338, tf_esp = -955732040, tf_ss = -955732040}) at
/usr/src/sys/i386/i386/trap.c:434
#6 0xc05f1c5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc050f162 in vfs_vmio_release (bp=0xc708afb8) at atomic.h:146
#8 0xc050f974 in getnewbuf (slpflag=0, slptimeo=0, size=32768, maxsize=32768)
at /usr/src/sys/kern/vfs_bio.c:1779
#9 0xc0510eb0 in getblk (vp=0xc29b4770, blkno=25, size=32768,
slpflag=0, slptimeo=0, flags=0)
at /usr/src/sys/kern/vfs_bio.c:2486
#10 0xc206631d in ?? ()
#11 0xc29b4770 in ?? ()
#12 0x0019 in ?? ()
#13 0x in ?? ()
#14 0x8000 in ?? ()
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0xc7025860 in ?? ()
#20 0xc29b4830 in ?? ()
#21 0x in ?? ()
#22 0xc1e28400 in ?? ()
#23 0xd1251a94 in ?? ()
#24 0xc05106dc in incore (bo=0x19, blkno=140737488355328) at
/usr/src/sys/kern/vfs_bio.c:2141
#25 0xc20685ff in ?? ()
#26 0x0019 in ?? ()
#27 0x in ?? ()
#28 0x8000 in ?? ()
#29 0xc24b4600 in ?? ()
#30 0x8000 in ?? ()
#31 0x1dba5906 in ?? ()
#32 0x in ?? ()
#33 0x8853088c in ?? ()
#34 0x0019 in ?? ()
#35 0x in ?? ()
#36 0x004ba000 in ?? ()
#37 0x in ?? ()
#38 0x8000 in ?? ()
#39 0x in ?? ()
#40 0x000c8000 in ?? ()
#41 0x in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x005e in ?? ()
#47 0x8000 in ?? ()
#48 0x0018 in ?? ()
#49 0x in ?? ()
#50 0xc24295a0 in ?? ()
#51 0xc24b4600 in ?? ()
#52 0x in ?? ()
#53 0x8000 in ?? ()
#54 0xc22e58fc in ?? ()
#55 0xc0674d80 in vop_getattr_vp_offsets ()
#56 0xc29b4770 in ?? ()
#57 0xd1251b2c in ?? ()
#58 0xc2353b00 in ?? ()
#59 0xc24b4600 in ?? ()
#60 0xc24b4600 in ?? ()
#61
RE: pf buggy on 6.1-STABLE?
A test page that makes 10,000 rapid SQL connections which connected 100% of the time before, now will usually see anywhere from one or two failed connections to a dozen or so (per 10,000) Have you kept track of state table entries during this process with pfctl -si ? You may find that you need to increase set limit states From the default as a consequence Greg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reading process memory
David Nugent wrote: Tofik Suleymanov wrote: Thank you for brief and altogether extensive explanation of the case.The thing i wanted to do is to read let's say portions of memory where .bss and .data block of a running program reside. is that possible ? Yes. Debuggers offer this functionality, for example. man 2 ptrace David, looks like it is exactly what i need.I am going to dig more into ptrace. Thank you, Tofik Suleymanov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf buggy on 6.1-STABLE?
On Wed, Jun 07, 2006 at 04:25:37PM -0700, Mark Morley wrote: Hi folks, Wondering if this rings any bells for anyone: After upgrading a handful of web servers from FreeBSD 4.11 with ipfw to 6.1-STABLE with pf, customers started reporting that occasionally their server side scripts would fail to connect to the SQL servers (which are still 4.11 and are attached via a separate dedicated gigabit network). A test page that makes 10,000 rapid SQL connections which connected 100% of the time before, now will usually see anywhere from one or two failed connections to a dozen or so (per 10,000) After trying many other things first, we finally found that 'pf' seems to be the culprit. Disabling pf with pfctl -d allows 100% of all connections to work, and as soon as we enable it we see connection failures again. I've tried changing the pf rule set in different ways, with and without scrubbing, with and without queues, even to the point where I have a single rule that just allows everything. It doesn't seem to matter what the rules actually are, just whether or not pf is enabled. I recompiled the kernel with pf disabled and ipfw enabled, and it works fine with 100% successful connections. We have no funky compiler options or anything like that. Any thoughts? could you show us the followings: - pf.conf - kernel configuration file - uname -a next time please include technical information along with the textual description of your problem Bye, Gergely Czuczy mailto: [EMAIL PROTECTED] PGP: http://phoemix.harmless.hu/phoemix.pgp Weenies test. Geniuses solve problems that arise. signature.asc Description: Digital signature
RE: pf buggy on 6.1-STABLE?
Hi.
I'm not sure it is related to your case but... I have seen a situation
when application used for load-testing web server running on MS Windows
box failed establishing HTTP connections to the server . Investigation
identified that this is due to the fact that Windows relatively quickly
reuses source TCP port numbers for these outbound connections. I'm not
sure if Microsoft violates TCP standard with that or not. The fact is
that pf keeps closed entries in the state table for 90 second and it
still remembers old source port when Windows send SYN from it trying to
establish new connection. As result, pf considers that packet invalid
and drops it.
You can check pfctl -s info . In my case the state-mismatch counter was
increasing with for every falied connection.
In any case, output of that tool can be very useful to you - if you see
one of counters for dropped packet increasing, you will have an idea
why.
Regards,
Dmitry Andrianov
PS: my problem was solved adding following lines to pf.conf:
# set short timeout for TCP closed state because Windows tends to reuse
# the same outgoing port very quickly and pf starts refusing new
connections
# because of invalid state
# (This occurs when load testing DMZ server from LAN)
set timeout { tcp.closed 15 }
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Mark Morley
Sent: Thursday, June 08, 2006 3:26 AM
To: freebsd-pf@freebsd.org; freebsd-stable@freebsd.org
Subject: pf buggy on 6.1-STABLE?
Hi folks,
Wondering if this rings any bells for anyone:
After upgrading a handful of web servers from FreeBSD 4.11 with ipfw to
6.1-STABLE with pf, customers started reporting that occasionally their
server side scripts would fail to connect to the SQL servers (which are
still 4.11 and are attached via a separate dedicated gigabit network).
A test page that makes 10,000 rapid SQL connections which connected 100%
of the time before, now will usually see anywhere from one or two failed
connections to a dozen or so (per 10,000)
After trying many other things first, we finally found that 'pf' seems
to be the culprit.
Disabling pf with pfctl -d allows 100% of all connections to work, and
as soon as we enable it we see connection failures again.
I've tried changing the pf rule set in different ways, with and without
scrubbing, with and without queues, even to the point where I have a
single rule that just allows everything. It doesn't seem to matter what
the rules actually are, just whether or not pf is enabled.
I recompiled the kernel with pf disabled and ipfw enabled, and it works
fine with 100% successful connections. We have no funky compiler
options or anything like that.
Any thoughts?
Mark
--
Mark Morley
Owner / Administrator
Islandnet.com
___
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reading process memory
Diomidis Spinellis wrote: Tofik Suleymanov wrote: The only way you're going to be able to read another processes address space is in the kernel.Even a process running as root is not able to read another process's data. Incorrect; see this example: $ sed -e 's/this/that/' [1] 87345 $ /bin/su Password: # dd if=/proc/87345/mem conv=noerror 2 /dev/null | strings [...] @(#)compile.c 8.1 (Berkeley) 6/6/93 [...] RE error: %s RuneMagiNONE /this/that/ s/this/that/ s/this/that/ this that that I followed instructions in your email, but had no success of getting simmilar results. When trying to read from mem file of particular process i get error messages from dd: (many of this records populate the screen) 0 bytes transferred in 6.393733 secs (0 bytes/sec) dd: /proc/13150/mem: Bad address dd: /proc/13150/mem: Bad address 0+0 records in 0+0 records out 0 bytes transferred in 6.393795 secs (0 bytes/sec) while pid 13510 exists: paranoia# ps ax |grep 13150 13150 p1 T 0:00.00 sed -e s/this/that/g paranoia# man 5 procfs says: mem The complete virtual memory image of the process. Only those address which exist in the process can be accessed. Reads and writes to this file modify the process. Writes to the text seg- ment remain private to the process. map A map of the process' virtual memory. I wonder why i cannot just dd data from mem ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reading process memory
David Nugent wrote: Tofik Suleymanov wrote: Thank you for brief and altogether extensive explanation of the case.The thing i wanted to do is to read let's say portions of memory where .bss and .data block of a running program reside. is that possible ? Yes. Debuggers offer this functionality, for example. man 2 ptrace man 2 ptrace says: PT_READ_I, PT_READ_D These requests read a single int of data from the traced process's address space. Traditionally, ptrace() has allowed for machines with distinct address spaces for instruction and data, which is why there are two requests: conceptually, PT_READ_I reads from the instruction space and PT_READ_D reads from the data space. In the current FreeBSD implementation, these two requests are completely identical. The addr argument specifies the address (in the traced process's virtual address space) at which the read is to be done. This address does not have to meet any alignment constraints. The value read is returned as the return value from ptrace(). where do i get the addr argument ? how can i know which address do i need to start from ? Sincerely, Tofik Suleymanov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reading process memory
Tofik Suleymanov wrote: Diomidis Spinellis wrote: Tofik Suleymanov wrote: The only way you're going to be able to read another processes address space is in the kernel.Even a process running as root is not able to read another process's data. Incorrect; see this example: $ sed -e 's/this/that/' [1] 87345 $ /bin/su Password: # dd if=/proc/87345/mem conv=noerror 2 /dev/null | strings [...] @(#)compile.c 8.1 (Berkeley) 6/6/93 [...] RE error: %s RuneMagiNONE /this/that/ s/this/that/ s/this/that/ this that that I followed instructions in your email, but had no success of getting simmilar results. When trying to read from mem file of particular process i get error messages from dd: (many of this records populate the screen) 0 bytes transferred in 6.393733 secs (0 bytes/sec) dd: /proc/13150/mem: Bad address dd: /proc/13150/mem: Bad address 0+0 records in 0+0 records out 0 bytes transferred in 6.393795 secs (0 bytes/sec) while pid 13510 exists: paranoia# ps ax |grep 13150 13150 p1 T 0:00.00 sed -e s/this/that/g paranoia# man 5 procfs says: mem The complete virtual memory image of the process. Only those address which exist in the process can be accessed. Reads and writes to this file modify the process. Writes to the text seg- ment remain private to the process. map A map of the process' virtual memory. I wonder why i cannot just dd data from mem ? Not all areas of the process's memory are accessible. This is why I set the conv=noerr option to dd (rather than run strings directly on mem), and also redirected the dd's standard error output to /dev/null. Your root's shell (probably tcsh) failed to do that. (Tcsh doesn't offer a way to redirect just the error output). Run sh after the su command to have this facility at your disposal. Diomidis - http://www.spinellis.gr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reading process memory
Diomidis Spinellis wrote: Tofik Suleymanov wrote: Diomidis Spinellis wrote: Tofik Suleymanov wrote: The only way you're going to be able to read another processes address space is in the kernel.Even a process running as root is not able to read another process's data. Incorrect; see this example: $ sed -e 's/this/that/' [1] 87345 $ /bin/su Password: # dd if=/proc/87345/mem conv=noerror 2 /dev/null | strings [...] @(#)compile.c 8.1 (Berkeley) 6/6/93 [...] RE error: %s RuneMagiNONE /this/that/ s/this/that/ s/this/that/ this that that I followed instructions in your email, but had no success of getting simmilar results. When trying to read from mem file of particular process i get error messages from dd: (many of this records populate the screen) 0 bytes transferred in 6.393733 secs (0 bytes/sec) dd: /proc/13150/mem: Bad address dd: /proc/13150/mem: Bad address 0+0 records in 0+0 records out 0 bytes transferred in 6.393795 secs (0 bytes/sec) while pid 13510 exists: paranoia# ps ax |grep 13150 13150 p1 T 0:00.00 sed -e s/this/that/g paranoia# man 5 procfs says: mem The complete virtual memory image of the process. Only those address which exist in the process can be accessed. Reads and writes to this file modify the process. Writes to the text seg- ment remain private to the process. map A map of the process' virtual memory. I wonder why i cannot just dd data from mem ? Not all areas of the process's memory are accessible. This is why I set the conv=noerr option to dd (rather than run strings directly on mem), and also redirected the dd's standard error output to /dev/null. Your root's shell (probably tcsh) failed to do that. (Tcsh doesn't offer a way to redirect just the error output). Run sh after the su command to have this facility at your disposal. Diomidis - http://www.spinellis.gr Works. Thank you. Sincerely, Tofik Suleymanov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf buggy on 6.1-STABLE?
Mark Morley wrote: Hi folks, Wondering if this rings any bells for anyone: After upgrading a handful of web servers from FreeBSD 4.11 with ipfw to 6.1-STABLE with pf, customers started reporting that occasionally their server side scripts would fail to connect to the SQL servers (which are still 4.11 and are attached via a separate dedicated gigabit network). A test page that makes 10,000 rapid SQL connections which connected 100% of the time before, now will usually see anywhere from one or two failed connections to a dozen or so (per 10,000) After trying many other things first, we finally found that 'pf' seems to be the culprit. I've experienced the same. If you have a lot of concurrent connections going on it seems that every so often an connection will be blocked, even if it doesnt match any rule. In my case I experienced this with apache22 acting as a reverse proxy/virtual host. Symptoms: 1. Sudden burst of traffic to a specific virtual host. 2. After some time, normally 30 seconds one of the connection attempts is reset. 3. Apache immediately stops proxying for any subsequent connections and returning a 'too busy message'. The project this was related to got shelved so it hasn't bothered me again yet, but I didn't find any workaround. Disabling pf with pfctl -d allows 100% of all connections to work, and as soon as we enable it we see connection failures again. Snap. I've tried changing the pf rule set in different ways, with and without scrubbing, with and without queues, even to the point where I have a single rule that just allows everything. It doesn't seem to matter what the rules actually are, just whether or not pf is enabled. Same as me. I recompiled the kernel with pf disabled and ipfw enabled, and it works fine with 100% successful connections. We have no funky compiler options or anything like that. Any thoughts? Mark -- Mark Morley Owner / Administrator Islandnet.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Cheers, Dom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reading process memory
David Nugent wrote: Tofik Suleymanov wrote: Thank you for brief and altogether extensive explanation of the case.The thing i wanted to do is to read let's say portions of memory where .bss and .data block of a running program reside. is that possible ? Yes. Debuggers offer this functionality, for example. man 2 ptrace Everything is pretty clear from ptrace(2) manpage but where do i get addr argument ? The addr argument specifies the address (in the traced process's virtual address space) at which the read is to be done. This address does not have to meet any alignment constraints. ? Sincerely, Tofik Suleymanov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: Fatal trap 12: page fault while in kernel mode (current process = 4254 (perl5.8.8))
Hi,
I experienced lots of kernel panic after I installed openwebmail on my
mail server.
The environment is :
[Mail Server] = [Mail Spool Server]
nfs
Mail Server: 6.1-RELEASE (panic 3 times a day)
Mail Spool Server: 6.0-RELEASE
I also installed www/apache20, mail/postfix.
The mount options is rw, quota (Yes, I used quota)
I have tried to replace my kernel, but GENERIC and custom kernels panic, too.
Please give me some advice :)
==
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x34
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc050f162
stack pointer = 0x28:0xd12519b8
frame pointer = 0x28:0xd12519c4
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 = 4254 (perl5.8.8)
trap number = 12
panic: page fault
KDB: stack backtrace:
kdb_backtrace(100,c24b4600,28,d1251978,c) at kdb_backtrace+0x29
panic(c0620009,c06413f8,0,f,c24aea9b) at panic+0xa8
trap_fatal(d1251978,34,c24b4600,c2330ce4,c) at trap_fatal+0x2a6
trap_pfault(d1251978,0,34) at trap_pfault+0x1d3
trap(d1250008,d1250028,c2060028,c708afb8,c708afb8) at trap+0x2fd
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc050f162, esp = 0xd12519b8, ebp = 0xd12519c4 ---
vfs_vmio_release(c708afb8) at vfs_vmio_release+0x12
getnewbuf(0,0,8000,8000,c8000) at getnewbuf+0x2b0
getblk(c29b4770,19,0,8000,0) at getblk+0x35c
nfs_getcacheblk(19,0,8000,c24b4600,8000) at nfs_getcacheblk+0x81
nfs_bioread(c29b4770,d1251cbc,2f,c2353b00,d1251bcc) at nfs_bioread+0x983
nfs_read(d1251bf4) at nfs_read+0x33
VOP_READ_APV(c2084d20,d1251bf4) at VOP_READ_APV+0x38
vn_read(c224fea0,d1251cbc,c2353b00,0,c24b4600) at vn_read+0x196
dofileread(c24b4600,3,c224fea0,d1251cbc,) at dofileread+0x85
kern_readv(c24b4600,3,d1251cbc,9013000,1000) at kern_readv+0x36
read(c24b4600,d1251d04,3,27,202) at read+0x45
syscall(c05f003b,3b,3b,806c200,3) at syscall+0x2b7
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (3, FreeBSD ELF32, read), eip = 0x282637df, esp =
0xbfbfe28c, ebp = 0xbfbfe2c8 ---
Uptime: 14h32m59s
Dumping 255 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 255MB (65280 pages) 240 224 208 192 176 160 144 128 112 96
80 64 48 32 16
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc04c8cfd in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc04c8fc4 in panic (fmt=0xc0620009 %s) at
/usr/src/sys/kern/kern_shutdown.c:558
#3 0xc06028b6 in trap_fatal (frame=0xd1251978, eva=52) at
/usr/src/sys/i386/i386/trap.c:836
#4 0xc06025e7 in trap_pfault (frame=0xd1251978, usermode=0, eva=52)
at /usr/src/sys/i386/i386/trap.c:744
#5 0xc0602201 in trap (frame=
{tf_fs = -786104312, tf_es = -786104280, tf_ds = -1039794136,
tf_edi = -955732040, tf_esi = -955732040, tf_ebp = -786097724, tf_isp
= -786097756, tf_ebx = -955732040, tf_edx = 4, tf_ecx = -1035254272,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068437150, tf_cs =
32, tf_eflags = 590338, tf_esp = -955732040, tf_ss = -955732040}) at
/usr/src/sys/i386/i386/trap.c:434
#6 0xc05f1c5a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc050f162 in vfs_vmio_release (bp=0xc708afb8) at atomic.h:146
#8 0xc050f974 in getnewbuf (slpflag=0, slptimeo=0, size=32768, maxsize=32768)
at /usr/src/sys/kern/vfs_bio.c:1779
#9 0xc0510eb0 in getblk (vp=0xc29b4770, blkno=25, size=32768,
slpflag=0, slptimeo=0, flags=0)
at /usr/src/sys/kern/vfs_bio.c:2486
#10 0xc206631d in ?? ()
#11 0xc29b4770 in ?? ()
#12 0x0019 in ?? ()
#13 0x in ?? ()
#14 0x8000 in ?? ()
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0xc7025860 in ?? ()
#20 0xc29b4830 in ?? ()
#21 0x in ?? ()
#22 0xc1e28400 in ?? ()
#23 0xd1251a94 in ?? ()
#24 0xc05106dc in incore (bo=0x19, blkno=140737488355328) at
/usr/src/sys/kern/vfs_bio.c:2141
#25 0xc20685ff in ?? ()
#26 0x0019 in ?? ()
#27 0x in ?? ()
#28 0x8000 in ?? ()
#29 0xc24b4600 in ?? ()
#30 0x8000 in ?? ()
#31 0x1dba5906 in ?? ()
#32 0x in ?? ()
#33 0x8853088c in ?? ()
#34 0x0019 in ?? ()
#35 0x in ?? ()
#36 0x004ba000 in ?? ()
#37 0x in ?? ()
#38 0x8000 in ?? ()
#39 0x in ?? ()
#40 0x000c8000 in ?? ()
#41 0x in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x005e in ?? ()
#47 0x8000 in ?? ()
#48 0x0018 in ?? ()
#49 0x in ?? ()
#50 0xc24295a0 in ?? ()
#51 0xc24b4600 in ?? ()
#52 0x in ?? ()
#53 0x8000 in ?? ()
#54 0xc22e58fc in ?? ()
#55 0xc0674d80 in vop_getattr_vp_offsets ()
#56 0xc29b4770 in ?? ()
#57 0xd1251b2c in ?? ()
#58 0xc2353b00 in ?? ()
#59 0xc24b4600 in ?? ()
#60 0xc24b4600 in ?? ()
#61
Re: 6.1-R ? 6-Stable ? 5.5-R ?
Albert Shih [EMAIL PROTECTED] wrote: I've nfs server running 6-Stable (5 April 2006) with some trouble but ... well approx stable. But today he crash again (after ~1.5 mounth). There have been quite a lot of bug fixes (including NFS- related, IIRC) in the weeks before the release. Therefore I recommend that you update to RELENG_6_1. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I know which files a proccess is accessing?
It is worth mentioning that lsof is also extremely useful for finding inodes that have a link count of 0, i.e. files that have been deleted but are still open by a process. lsof +L1 will list them with their inode numbers and the PIDs of the processes that keep them open. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code (taken from comp.lang.awk FAQ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FYI: Panasonic Toughbook CF-R4 can suspend/resume
I confirmed 3rd generation CF-R4 (Panasonic Toughbook/
Let's Note series, 2006 Spring Model) can suspend/resume:-)
with following settings.
Add to /boot/loader.conf
- - - - - - - - - - - - - - - -
hint.apic.0.disabled=1
hint.psm.0.flags=0x2000
- - - - - - - - - - - - - - - -
And, mita-san ([EMAIL PROTECTED]) has CF-W4 (3rd
generation). It can suspend/resume:-), too. But Ume-san
(ume@) has CF-R4(1st generation), it cannot suspend/resume:-(.
Takahashi-san(nyan@) has CF-R3, same too:-(.
I read /usr/src/sys/i386/i386/io_apic.c, and I'm suprised
following code:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#define TODOprintf(%s: not implemented!\n, __func__)
static void
ioapic_suspend(struct intsrc *isrc)
{
TODO;
}
static void
ioapic_resume(struct intsrc *isrc)
{
ioapic_program_intpin((struct ioapic_intsrc *)isrc);
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Hum
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf buggy on 6.1-STABLE?
On 6/8/06, Dominic Marks [EMAIL PROTECTED] wrote: I've experienced the same. If you have a lot of concurrent connections going on it seems that every so often an connection will be blocked, even if it doesnt match any rule. In my case I experienced this with apache22 acting as a reverse proxy/virtual host. This sounds a lot like the port randomization problems discussed by Michael Silbersack in his BSDCan presentation. specifically, pages 12-14. http://www.silby.com/bsdcan06/silbersack_bsdcan06.pdf That shouldn't be an issue anymore, but I don't know when that was resolved. cheers, -Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf buggy on 6.1-STABLE?
Same issue here when using keep state. Specifically, it happened with PHP scripts accessing a remote MySQL database. I think it also happened with Qmail LDAP lookups. This happened even when I did not specify 'flags S/SA' 'pass quick' (non-stateful) fixed the problems but I wasn't satisfied with that for obvious reasons. Client reusing source port before state expired seems like a good explanation for this. I should test that. Kian On 6/8/06, Dominic Marks [EMAIL PROTECTED] wrote: Mark Morley wrote: Hi folks, Wondering if this rings any bells for anyone: After upgrading a handful of web servers from FreeBSD 4.11 with ipfw to 6.1-STABLE with pf, customers started reporting that occasionally their server side scripts would fail to connect to the SQL servers (which are still 4.11 and are attached via a separate dedicated gigabit network). A test page that makes 10,000 rapid SQL connections which connected 100% of the time before, now will usually see anywhere from one or two failed connections to a dozen or so (per 10,000) After trying many other things first, we finally found that 'pf' seems to be the culprit. I've experienced the same. If you have a lot of concurrent connections going on it seems that every so often an connection will be blocked, even if it doesnt match any rule. In my case I experienced this with apache22 acting as a reverse proxy/virtual host. Symptoms: 1. Sudden burst of traffic to a specific virtual host. 2. After some time, normally 30 seconds one of the connection attempts is reset. 3. Apache immediately stops proxying for any subsequent connections and returning a 'too busy message'. The project this was related to got shelved so it hasn't bothered me again yet, but I didn't find any workaround. Disabling pf with pfctl -d allows 100% of all connections to work, and as soon as we enable it we see connection failures again. Snap. I've tried changing the pf rule set in different ways, with and without scrubbing, with and without queues, even to the point where I have a single rule that just allows everything. It doesn't seem to matter what the rules actually are, just whether or not pf is enabled. Same as me. I recompiled the kernel with pf disabled and ipfw enabled, and it works fine with 100% successful connections. We have no funky compiler options or anything like that. Any thoughts? Mark -- Mark Morley Owner / Administrator Islandnet.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Cheers, Dom ___ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1-R ? 6-Stable ? 5.5-R ?
On Thu, 2006-06-08 at 12:46 +0200, Oliver Fromme wrote: There have been quite a lot of bug fixes (including NFS- related, IIRC) in the weeks before the release. Therefore I recommend that you update to RELENG_6_1. Did you mean RELENG_6, right? -- Massimo.run(); ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5 tinderbox] failure on alpha/alpha
TB --- 2006-06-08 20:34:26 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2006-06-08 20:34:26 - starting RELENG_5 tinderbox run for alpha/alpha TB --- 2006-06-08 20:34:26 - cleaning the object tree TB --- 2006-06-08 20:34:53 - checking out the source tree TB --- 2006-06-08 20:34:53 - cd /tinderbox/RELENG_5/alpha/alpha TB --- 2006-06-08 20:34:53 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2006-06-08 20:44:05 - building world (CFLAGS=-O -pipe) TB --- 2006-06-08 20:44:05 - cd /src TB --- 2006-06-08 20:44:05 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything TB --- 2006-06-08 21:30:50 - generating LINT kernel config TB --- 2006-06-08 21:30:50 - cd /src/sys/alpha/conf TB --- 2006-06-08 21:30:50 - /usr/bin/make -B LINT TB --- 2006-06-08 21:30:50 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2006-06-08 21:30:50 - cd /src TB --- 2006-06-08 21:30:50 - /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 8 21:30:50 UTC 2006 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] @ - /src/sys machine - /src/sys/alpha/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -s /obj/alpha/src/sys/LINT/opt_cam.h opt_cam.h ln -s /obj/alpha/src/sys/LINT/opt_ddb.h opt_ddb.h make: don't know how to make mpt_freebsd.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/alpha/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-06-08 21:32:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-06-08 21:32:20 - ERROR: failed to build lint kernel TB --- 2006-06-08 21:32:20 - tinderbox aborted TB --- 1.11 user 3.40 system 3473.77 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5 tinderbox] failure on amd64/amd64
TB --- 2006-06-08 21:32:20 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2006-06-08 21:32:20 - starting RELENG_5 tinderbox run for amd64/amd64 TB --- 2006-06-08 21:32:20 - cleaning the object tree TB --- 2006-06-08 21:32:48 - checking out the source tree TB --- 2006-06-08 21:32:48 - cd /tinderbox/RELENG_5/amd64/amd64 TB --- 2006-06-08 21:32:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2006-06-08 21:42:11 - building world (CFLAGS=-O -pipe) TB --- 2006-06-08 21:42:11 - cd /src TB --- 2006-06-08 21:42:11 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries TB --- 2006-06-08 22:51:08 - generating LINT kernel config TB --- 2006-06-08 22:51:08 - cd /src/sys/amd64/conf TB --- 2006-06-08 22:51:08 - /usr/bin/make -B LINT TB --- 2006-06-08 22:51:08 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2006-06-08 22:51:08 - cd /src TB --- 2006-06-08 22:51:08 - /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 8 22:51:08 UTC 2006 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] @ - /src/sys machine - /src/sys/amd64/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -s /obj/amd64/src/sys/LINT/opt_cam.h opt_cam.h ln -s /obj/amd64/src/sys/LINT/opt_ddb.h opt_ddb.h make: don't know how to make mpt_freebsd.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-06-08 22:52:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-06-08 22:52:50 - ERROR: failed to build lint kernel TB --- 2006-06-08 22:52:50 - tinderbox aborted TB --- 1.38 user 4.38 system 4829.62 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: pf buggy on 6.1-STABLE?
Kian Mohageri wrote: 'pass quick' (non-stateful) fixed the problems but I wasn't satisfied with that for obvious reasons. The 'quick' keyword does not make the rule non-stateful, it only aborts further evaluation of the specific packet. See http://www.openbsd.org/faq/pf/filter.html#quick for more information. /Daniel Eriksson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Keyboard not working at mountroot prompt; 6.1-R
Hi, today I noticed the keyboard is not working when I boot with a wrong entry for the root fs in /etc/fstab. The kernel loads ok, then announces that it is not able to mount the root fs, and prompts for a new root fs. At that point I can press whatever key I like, nothing is accepted; not even Ctl-Alt-Del. System is IBM T42P laptop, FreeBSD 6.1-Release. Is this known? I remember vaguely having read something about kbdmux problems some time ago. -- Regards, Georg. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reading process memory
Hello! On Wed, 7 Jun 2006, Tofik Suleymanov wrote: I believe that it is possible to read contents of the memory used/utilized by a process (assuming right privileges). Yes, procfs allows it to user with the process's UID (or root). First i've tried to do this through procfs by reading 'mem' property of the given process, but no success. Yes, process's virtual address space is accessible via /proc/PID/mem file, just don't forget that it's sparse. So you can't just 'hd mem', you should specify valid offset. /proc/PID/map will help you to do so: [EMAIL PROTECTED] cd /proc/curproc [EMAIL PROTECTED] cat map 0x8048000 0x80b 99 0 0xc68fc630 r-x 20 10 0x8004 COW NC vnode ... [EMAIL PROTECTED] dd if=mem bs=0x100 skip=0x80480 |hd|more 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00 |.ELF| 0010 02 00 03 00 01 00 00 00 24 6e 05 08 34 00 00 00 |$n..4...| 0020 e0 ac 06 00 00 00 00 00 34 00 20 00 05 00 28 00 |Ю╛..4. ...(.| P.S. I've once found the cause of the memory leak by examining virtual address space of my process and finding the repeated leaked pattern. Thanks, Tofik Suleymanov Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: [EMAIL PROTECTED] nic-hdl: LYNX-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pf buggy on 6.1-STABLE?
I'm aware. I meant that as pass quick (without any keep state) ;) Kian On 6/8/06, Daniel Eriksson [EMAIL PROTECTED] wrote: Kian Mohageri wrote: 'pass quick' (non-stateful) fixed the problems but I wasn't satisfied with that for obvious reasons. The 'quick' keyword does not make the rule non-stateful, it only aborts further evaluation of the specific packet. See http://www.openbsd.org/faq/pf/filter.html#quick for more information. /Daniel Eriksson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5 tinderbox] failure on i386/i386
TB --- 2006-06-08 22:52:50 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2006-06-08 22:52:50 - starting RELENG_5 tinderbox run for i386/i386 TB --- 2006-06-08 22:52:50 - cleaning the object tree TB --- 2006-06-08 22:53:15 - checking out the source tree TB --- 2006-06-08 22:53:15 - cd /tinderbox/RELENG_5/i386/i386 TB --- 2006-06-08 22:53:15 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2006-06-08 23:02:25 - building world (CFLAGS=-O -pipe) TB --- 2006-06-08 23:02:25 - cd /src TB --- 2006-06-08 23:02:25 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything TB --- 2006-06-08 23:49:36 - generating LINT kernel config TB --- 2006-06-08 23:49:36 - cd /src/sys/i386/conf TB --- 2006-06-08 23:49:36 - /usr/bin/make -B LINT TB --- 2006-06-08 23:49:36 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2006-06-08 23:49:36 - cd /src TB --- 2006-06-08 23:49:36 - /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 8 23:49:36 UTC 2006 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] @ - /src/sys machine - /src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -s /obj/src/sys/LINT/opt_cam.h opt_cam.h ln -s /obj/src/sys/LINT/opt_ddb.h opt_ddb.h make: don't know how to make mpt_freebsd.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-06-08 23:51:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-06-08 23:51:45 - ERROR: failed to build lint kernel TB --- 2006-06-08 23:51:45 - tinderbox aborted TB --- 1.10 user 3.65 system 3534.64 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [releng_5 tinderbox] failure on amd64/amd64
I'm assuming that this is just stale information for the Tinderbox. There is no mpt_freebsd.c defined in sys/conf/files any more. On 6/8/06, FreeBSD Tinderbox [EMAIL PROTECTED] wrote: TB --- 2006-06-08 21:32:20 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2006-06-08 21:32:20 - starting RELENG_5 tinderbox run for amd64/amd64 TB --- 2006-06-08 21:32:20 - cleaning the object tree TB --- 2006-06-08 21:32:48 - checking out the source tree TB --- 2006-06-08 21:32:48 - cd /tinderbox/RELENG_5/amd64/amd64 TB --- 2006-06-08 21:32:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2006-06-08 21:42:11 - building world (CFLAGS=-O -pipe) TB --- 2006-06-08 21:42:11 - cd /src TB --- 2006-06-08 21:42:11 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries TB --- 2006-06-08 22:51:08 - generating LINT kernel config TB --- 2006-06-08 22:51:08 - cd /src/sys/amd64/conf TB --- 2006-06-08 22:51:08 - /usr/bin/make -B LINT TB --- 2006-06-08 22:51:08 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2006-06-08 22:51:08 - cd /src TB --- 2006-06-08 22:51:08 - /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 8 22:51:08 UTC 2006 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] @ - /src/sys machine - /src/sys/amd64/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -s /obj/amd64/src/sys/LINT/opt_cam.h opt_cam.h ln -s /obj/amd64/src/sys/LINT/opt_ddb.h opt_ddb.h make: don't know how to make mpt_freebsd.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-06-08 22:52:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-06-08 22:52:50 - ERROR: failed to build lint kernel TB --- 2006-06-08 22:52:50 - tinderbox aborted TB --- 1.38 user 4.38 system 4829.62 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [releng_5 tinderbox] failure on amd64/amd64
Ah- never mind- my bad. On 6/8/06, Matthew Jacob [EMAIL PROTECTED] wrote: I'm assuming that this is just stale information for the Tinderbox. There is no mpt_freebsd.c defined in sys/conf/files any more. On 6/8/06, FreeBSD Tinderbox [EMAIL PROTECTED] wrote: TB --- 2006-06-08 21:32:20 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2006-06-08 21:32:20 - starting RELENG_5 tinderbox run for amd64/amd64 TB --- 2006-06-08 21:32:20 - cleaning the object tree TB --- 2006-06-08 21:32:48 - checking out the source tree TB --- 2006-06-08 21:32:48 - cd /tinderbox/RELENG_5/amd64/amd64 TB --- 2006-06-08 21:32:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2006-06-08 21:42:11 - building world (CFLAGS=-O -pipe) TB --- 2006-06-08 21:42:11 - cd /src TB --- 2006-06-08 21:42:11 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries TB --- 2006-06-08 22:51:08 - generating LINT kernel config TB --- 2006-06-08 22:51:08 - cd /src/sys/amd64/conf TB --- 2006-06-08 22:51:08 - /usr/bin/make -B LINT TB --- 2006-06-08 22:51:08 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2006-06-08 22:51:08 - cd /src TB --- 2006-06-08 22:51:08 - /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jun 8 22:51:08 UTC 2006 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] @ - /src/sys machine - /src/sys/amd64/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -s /obj/amd64/src/sys/LINT/opt_cam.h opt_cam.h ln -s /obj/amd64/src/sys/LINT/opt_ddb.h opt_ddb.h make: don't know how to make mpt_freebsd.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-06-08 22:52:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-06-08 22:52:50 - ERROR: failed to build lint kernel TB --- 2006-06-08 22:52:50 - tinderbox aborted TB --- 1.38 user 4.38 system 4829.62 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_5 tinderbox] failure on i386/pc98
TB --- 2006-06-08 23:51:45 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2006-06-08 23:51:45 - starting RELENG_5 tinderbox run for i386/pc98 TB --- 2006-06-08 23:51:45 - cleaning the object tree TB --- 2006-06-08 23:52:11 - checking out the source tree TB --- 2006-06-08 23:52:11 - cd /tinderbox/RELENG_5/i386/pc98 TB --- 2006-06-08 23:52:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2006-06-09 00:01:28 - building world (CFLAGS=-O -pipe) TB --- 2006-06-09 00:01:28 - cd /src TB --- 2006-06-09 00:01:28 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything TB --- 2006-06-09 00:48:29 - generating LINT kernel config TB --- 2006-06-09 00:48:29 - cd /src/sys/pc98/conf TB --- 2006-06-09 00:48:29 - /usr/bin/make -B LINT TB --- 2006-06-09 00:48:29 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2006-06-09 00:48:29 - cd /src TB --- 2006-06-09 00:48:29 - /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Jun 9 00:48:29 UTC 2006 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] @ - /src/sys machine - /src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -s /obj/pc98/src/sys/LINT/opt_cam.h opt_cam.h ln -s /obj/pc98/src/sys/LINT/opt_ddb.h opt_ddb.h make: don't know how to make mpt_freebsd.c. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-06-09 00:50:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-06-09 00:50:14 - ERROR: failed to build lint kernel TB --- 2006-06-09 00:50:14 - tinderbox aborted TB --- 1.16 user 3.66 system 3508.96 real ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
System reset trying to configure Sybase server (databases/sybase_ase)
Hello!
I installed the databases/sybase_ase port on the FreeBSD/amd64 system running
6.1-STABLE.
The install went fine, and trying to run the
su sybase
cd ${PREFIX}/sybase-ase
install/sybinit
progresses fine for some time, until the system resets :-( The last messages
out of it are:
[...]
Running task: boot the Sybase Server.
Task succeeded: boot the Sybase Server.
Running task: create the sybsystemprocs database.
sybsystemprocs database created.
Task succeeded: create the sybsystemprocs database.
Running task: install system stored procedures.
.
It does not try to make a kernel dump (dumpdev configured), it does not log
anything in the last second (log messages sent to another system). Just a
very quick system reset... And I saw it happen 4 times already -- in the same
place.
The Sybase binaries are 32-bit Linux, but they run as a non-privileged user
``sybase'' (created by the port).
How could it possibly be doing such damage? Thanks!
-mi
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
