Re: how to use iic(4)

[Milan Obuch]

On Tuesday 25 September 2007 06:13:10 John-Mark Gurney wrote:
> Ian Smith wrote this message on Sat, Sep 22, 2007 at 13:16 +1000:
> > This drew a blank in -questions.  I don't know where else to post it, so
> > I'm hoping someone here might be able to spare me a clue.
>
> You should probably have posted this question to -hackers instead..
> This is more low level hardware than networking...
>
...
>
> You need to have a device that connects between your i2c bus hardware
> and iicbb or iicbus...  I'm not familar w/ lpbb, but I have used
> /dev/iic? w/ some HD capture card drivers I've written, and they are
> created when the device driver probes them...  lpbb may need hints to
> get it to attach, or may need a properly functioning parallel port..
>
> > Also, iicbb(4) is said to be a master-only interface.  I can work with
> > that, but if anyone knows of any iicbus slave-mode code I'm all eyes ..
>
> That's even more complicated as you either need specialized hardware
> that will detect when your i2c address is on the bus, or you need to
> poll/interrupt on line changes, which could get a bit expensive...
>
> I have a command line iic program that I used to help debug my drivers..
> The tool lets you start and then read/write from the device, and then
> stop the bus...
>
> I haven't committed it yet, because a few other developers want it under
> tools, and I don't like it there, as no one knows about most of the
> tools under there...  Maybe if we had a man page that talked about the
> tools available there it'd be more attractive...

Could you post it somewhere? Web, maybe...

I was trying to write i2c driver for WRAP board, but failed. Now it's time to 
try again, maybe, (there is new generation WRAP board). It is definitely 
possible, there is an ACB driver in OpenBSD, but I did not gain knowledge to 
port it, the whole bus/driver infrastructure is too different...

Regards,
Milan

-- 
No need to mail me directly. Just reply to mailing list, please.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: fsck of large volume with small memory

[sam]

Frank Mayhar wrote:



hi, all
http://lists.freebsd.org/pipermail/freebsd-questions/2007-June/151686.html

my problem
# fsck /dev/aacd0s1f
** /dev/aacd0s1f (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes

  

You might also want to try ports/sysutils/ffsrecov2 before you run this
fsck.  It might allow you to recover data that would otherwise be lost.
(Like, say, if there are directories hidden beneath the corrupt inode.)
  

thx
but this partition is mounted, iam have access to this data

trouble in boot stage

/Vladimir Ermakov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: linuxolator problem on i386

[sam]

Pieter de Goeje wrote:

On Monday 24 September 2007, sam wrote:
  

# mount|grep linux
linprocfs on /usr/compat/linux/proc (linprocfs, local)
linsysfs on /usr/compat/linux/sys (linsysfs, local)

# pkg_info | grep linux
linux_base-fc6-6_3  Base set of packages needed in Linux mode (for
i386/amd64)

[private links to debug.log & ktrace.out]

please send me message after downloaded this files (for removing)

/Vladimir Ermakov

cross-posting:
http://lists.freebsd.org/pipermail/freebsd-emulation/2007-September/003960.
html

I haven't tried it on i386 yet, but I know that this works on amd64 with linux 
2.4 compat and linux_base-fc4 on FreeBSD 7.


- Pieter

  

yes, working
but, this trouble in kernel
new linux-software require linux 2.6

/Vladimir Ermakov

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: how to use iic(4)

[John-Mark Gurney]

Ian Smith wrote this message on Sat, Sep 22, 2007 at 13:16 +1000:
> This drew a blank in -questions.  I don't know where else to post it, so
> I'm hoping someone here might be able to spare me a clue.

You should probably have posted this question to -hackers instead..
This is more low level hardware than networking...

> We're building a small board with two AVR Tiny MCUs chatting to each
> other over an opto-isolated I2C-compatible bus, hopefully at 400kbps.
> 
> Hoping to use the iicbb(4) on lpbb(4) parallel port interface to talk
> with either of these MCUs for debugging, control and data acquisition.
> 
> iic(4) says:
>  ===
>  The iic character device driver provides generic i/o to any iicbus(4)
>  instance.  In order to control I2C devices, use /dev/iic? with the fol-
>  lowing ioctls:
> 
>  Ioctl Description
>  I2CSTART  send start condition to the specified device (with 7-bit
>address) on the bus
>  I2CSTOP   send stop condition to the bus
>  I2CRSTCARDreset the bus
> 
>  You may also use read/write routines, then I2C start/stop handshake is
>  managed by the iicbus system.
>  ===
> 
> Does the latter statement suggest that ordinary reads from or writes to
> /dev/iic? could be performed by redirection of say echo and read from a
> script?  Or is the device only accessible by ioctl from eg a C program?

No, as you need to select (via I2CSTART) the slave device you are talking
w/ before you do a read or a write...

> Secondly, how does /dev/iic? come to exist?  This 5.5-STABLE system
> seems to have all the requisite drivers, but there's no /dev/iic*:
> paqi% kldstat -v | egrep 'iic|lpbb'
> 29 iicbus/ic
> 30 iicbus/iic
> 31 bktr/iicbb
> 32 lpbb/iicbb
> 33 viapm/iicbb
> 34 pcf/iicbus
> 35 envctrl/iicbus
> 36 iicbb/iicbus
> 37 bti2c/iicbus
> 38 iicbus/iicsmb
> 86 iicsmb/smbus
>  121 0xc2456000 3000 lpbb.ko
> 247 ppbus/lpbb

You need to have a device that connects between your i2c bus hardware
and iicbb or iicbus...  I'm not familar w/ lpbb, but I have used
/dev/iic? w/ some HD capture card drivers I've written, and they are
created when the device driver probes them...  lpbb may need hints to
get it to attach, or may need a properly functioning parallel port..

> Also, iicbb(4) is said to be a master-only interface.  I can work with
> that, but if anyone knows of any iicbus slave-mode code I'm all eyes ..

That's even more complicated as you either need specialized hardware
that will detect when your i2c address is on the bus, or you need to
poll/interrupt on line changes, which could get a bit expensive...

I have a command line iic program that I used to help debug my drivers..
The tool lets you start and then read/write from the device, and then
stop the bus...

I haven't committed it yet, because a few other developers want it under
tools, and I don't like it there, as no one knows about most of the
tools under there...  Maybe if we had a man page that talked about the
tools available there it'd be more attractive...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: fsck of large volume with small memory

[Frank Mayhar]

On Mon, 2007-09-24 at 16:30 -0700, Don Lewis wrote:
> On 24 Sep, sam wrote:
> > hi, all
> > http://lists.freebsd.org/pipermail/freebsd-questions/2007-June/151686.html
> > 
> > my problem
> > # fsck /dev/aacd0s1f
> > ** /dev/aacd0s1f (NO WRITE)
> > ** Last Mounted on /usr
> > ** Phase 1 - Check Blocks and Sizes
> > fsck_ufs: cannot alloc 2378019004 bytes for inoinfo
> 
> I'd be willing to bet that one of the cylinder group blocks in your file
> system got corrupted.
>  
> > any solutions ?
> 
> The patch below should allow a manual fsck to run to completion. I'd
> recommend running "fsck -N" and capturing its output.  Then use the clri
> command (either standalone or in fsdb) to zero out the uninitialized
> inodes that are unmasked by setting cg_initediblk to its maximum
> possible value based on the file system parameters.
> 
> Expect major file system lossage ...

You might also want to try ports/sysutils/ffsrecov2 before you run this
fsck.  It might allow you to recover data that would otherwise be lost.
(Like, say, if there are directories hidden beneath the corrupt inode.)
-- 
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
http://www.exit.com/blog/frank/
http://www.zazzle.com/fmayhar*
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: fsck of large volume with small memory

[Don Lewis]

On 24 Sep, sam wrote:
> hi, all
> http://lists.freebsd.org/pipermail/freebsd-questions/2007-June/151686.html
> 
> my problem
> # fsck /dev/aacd0s1f
> ** /dev/aacd0s1f (NO WRITE)
> ** Last Mounted on /usr
> ** Phase 1 - Check Blocks and Sizes
> fsck_ufs: cannot alloc 2378019004 bytes for inoinfo

I'd be willing to bet that one of the cylinder group blocks in your file
system got corrupted.
 
> any solutions ?

The patch below should allow a manual fsck to run to completion. I'd
recommend running "fsck -N" and capturing its output.  Then use the clri
command (either standalone or in fsdb) to zero out the uninitialized
inodes that are unmasked by setting cg_initediblk to its maximum
possible value based on the file system parameters.

Expect major file system lossage ...

I think this patch could be better, but this should get you going ...

Index: sbin/fsck_ffs/pass1.c
===
RCS file: /home/ncvs/src/sbin/fsck_ffs/pass1.c,v
retrieving revision 1.43
diff -u -r1.43 pass1.c
--- sbin/fsck_ffs/pass1.c   8 Oct 2004 20:44:47 -   1.43
+++ sbin/fsck_ffs/pass1.c   24 Sep 2007 23:15:22 -
@@ -93,9 +93,29 @@
inumber = c * sblock.fs_ipg;
setinodebuf(inumber);
getblk(&cgblk, cgtod(&sblock, c), sblock.fs_cgsize);
-   if (sblock.fs_magic == FS_UFS2_MAGIC)
+   if (sblock.fs_magic == FS_UFS2_MAGIC) {
inosused = cgrp.cg_initediblk;
-   else
+if (inosused < 0 || inosused > sblock.fs_ipg) {
+   pfatal("CG %d: PREPOSTEROUS NUMBER OF INODES %d 
(cg_initediblk), ASSUMING %d (fs_ipg)\n",
+   c, inosused, sblock.fs_ipg);
+   /*
+* The cylinder group block is most likely
+* totally corrupted and will probably
+* fail the magic number check below as well.
+* Ignoring cg_initediblk and setting
+* inosused to sblock.fs_ipg will allow
+* a manual fsck to proceed further instead
+* of dying when it attempts to allocate
+* an insane amount of memory to store
+* the inode info for this cylinder group.
+* This may provide enough information
+* to allow the system administrator to
+* do a better job of patching the
+* filesystem with fsdb.
+*/
+   inosused = sblock.fs_ipg;
+   }
+   } else
inosused = sblock.fs_ipg;
if (got_siginfo) {
printf("%s: phase 1: cyl group %d of %d (%d%%)\n",

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Own Install CD with custom kernel

[Matthias Fechner]

Hello Ulrich,

* Ulrich Spoerlein <[EMAIL PROTECTED]> [23-09-07 17:19]:
> I'm using a Makefile to drive our release and package building and for
> the releases I'm using an install.cfg, which gets created on the fly,
> since the names of the kernels change now and then, here is the release
> target

thx a lot for your really great answer, but I have some more short
questions. :)
Do you copy the release target to the Makefile in
/usr/src/release/Makefile or do you execute from another place?


> rm -f ${TLR}/usr/src/release/.install.cfg
> [...]
> cd ${TRR}/R/ftp && find -d . | cpio --quiet -dumpl ${TFR}

hm, cannot found the variables TLR and TRR anywhere defined. Can you
please give me some more information how your buildprocess looks?

> And files/install.cfg contains the following

where should I store that file?
man release doesn't give here any information about it.

> So basically, sysinstall is intructed to not install any kernel, but
> after all distributions are extracted the following commands are run
> 
> command=/bin/sh -c "cd /dist/${RELEASE}/kernels && ./install.sh GENERIC"
> system
> command=/bin/sh -c "cd /dist/${RELEASE}/kernels && ./install.sh SMP"
> system

where can you say sysinstall that it should run such commands after
the installation?


Best regards,
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Intel D975XBX2 BTX halted

[Andrey V. Elsukov]

Hi, i have motherboard with integrated Marvell 88SE6141 controller. And i can't 
boot from any drives attached to this controller. This controller family is not 
yet 
supported. 

> After experiencing overheating problems, I purchased a new CPU and 
> motherboard 
> (Intel D975XBX2) which has a built in Raid controller Marvell 88SE61xx
> I connected my existing FreeBSD-STABLE SATA drive to port 0.
> Upon boot, I receive the following error:

--
WBR, Andrey V. Elsukov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel panic on PowerEdge 1950 under certain stress load

[Ivan Voras]

On 24/09/2007, Benjie Chen <[EMAIL PROTECTED]> wrote:
> Ivan and Kris,
>
> I will try to get a kernel trace -- it may not happen for awhile since I am
> not in the office and working remotely for awhile so it may not be easy to
> get a trace... but I will check.

It's fairly easy:

1) add lines like the following in rc.conf:
dumpdev="/dev/amrd0s1b"
dumpdir="/storage1/crashdumps"

(dumpdev is your swap partition, which must be larger than your RAM,
dumpdir is where the crash dumps will be saved, also needs to be
larger than RAM)

2) add these lines to sysctl.conf:

debug.debugger_on_panic=0
debug.trace_on_panic=1

(These will cause the panic message and backtrace to be automatically
recorded in the message buffer saved to the kernel crash dump. If not
told otherwise, the machine will then reboot and at the next boot
generate a crash dump in your dumpdir. When you get the kernel crash
dump, run "kgdb vmcore.0 /boot/kernel/kernel" as root and then you can
inspect the trace, core dump, etc. You don't need any special
knowledge of (k)gdb for this. The one useful command to you may be
"bt" - generate a backtrace).

> It looks like the problem reported by that link, and some of the links from
> there though...

I'm trying to solve that one with Craig Rodrigues. So far it's been
without success but we know where the problem is.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel panic on PowerEdge 1950 under certain stress load

[Ivan Voras]

On 24/09/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Ivan Voras wrote:

> > http://lists.freebsd.org/pipermail/freebsd-current/2007-September/076932.html
>
> Surely it cannot be since it involves a different function ;-)

:)

When all you have is a hammer...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel panic on PowerEdge 1950 under certain stress load

[Kris Kennaway]

Ivan Voras wrote:

Benjie Chen wrote:


Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin
 c066c7b4 T _mtx_lock_spin
 c066c85c T _mtx_unlock_sleep

So this could mean that independent stress tests will not result in 
panic if

there aren't enough concurrency to cause the problem.


When you get a kernelbacktrace, see if it's the same as the one 
mentioned here:
http://lists.freebsd.org/pipermail/freebsd-current/2007-September/076932.html 


Surely it cannot be since it involves a different function ;-)

Kris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: linuxolator problem on i386

[Pieter de Goeje]

On Monday 24 September 2007, sam wrote:
> Hi
>
> # su hlds -c "ktrace -i ./hlds_run -game cstrike +ip 0.0.0.0 +port 27015
> +map de_dust -debug"
> Auto detecting CPU
> Using Pentium II Optimised binary.
> Enabling debug mode
> Auto-restarting the server on crash
>
> Console initialized.
> scandir failed:/usr/home/hlds/1.6/./platform/SAVE
> Protocol version 47
> Exe version 1.1.2.5/Stdio (cstrike)
> Exe build: 20:02:49 Oct 24 2006 (3651)
> STEAM Auth Server
> couldn't exec language.cfg
> Server IP address 0.0.0.0:27015
> scandir failed:/usr/home/hlds/1.6/./platform/SAVE
> *** glibc detected *** ./hlds_i686: double free or corruption (!prev):
> 0x08da3738 ***
> === Backtrace: =
> /lib/libc.so.6[0x2811ac88]
> /lib/libc.so.6(cfree+0x90)[0x2811e230]
> /lib/libc.so.6(closedir+0x28)[0x2813ecf8]
> /lib/libc.so.6(scandir+0x14b)[0x2813f21b]
> /usr/home/hlds/1.6/filesystem_stdio_i386.so(findFileInDirCaseInsensitive__F
>PCc+0xe4)[0x28af41d8]
>
> /usr/home/hlds/1.6/filesystem_stdio_i386.so(FS_stat__17CFileSystem_StdioPCc
>P4stat+0x40)[0x28af861c]
>
> /usr/home/hlds/1.6/filesystem_stdio_i386.so(FastFindFileSize__15CBaseFileSy
>stemPCQ215CBaseFileSystem11CSearchPathPCc+0x17e)[0x28af572a]
>
> /usr/home/hlds/1.6/filesystem_stdio_i386.so(Size__15CBaseFileSystemPCc+0x5b
>)[0x28af557b]
>
> /usr/home/hlds/1.6/engine_i686.so(FS_FileSize+0x2a)[0x2828679e]
> === Memory map: 
> 08048000-08054000 r-xp 0003a000 00:00 1931338
> /usr/home/hlds/1.6/hlds_i686
> 08054000-0805b000 rw-p 0003a000 00:00 1931338
> /usr/home/hlds/1.6/hlds_i686
> 0805b000-0805e000 rw-p 00d6 00:00 0
> 0805e000-08dbb000 rwxp 00d6 00:00 0
> 28054000-2806d000 r-xp 0001e000 00:00 1719480
> /usr/compat/linux/lib/ld-2.5.so
> 2806d000-2806e000 r-xp 0001e000 00:00 1719480
> /usr/compat/linux/lib/ld-2.5.so
> 2806e000-2806f000 rw-p 2000 00:00 0
> 2806f000-2807 rwxp 2000 00:00 0
> 28071000-28073000 r-xp 4000 00:00 1719493
> /usr/compat/linux/lib/libdl-2.5.so
> 28073000-28074000 r-xp 4000 00:00 1719493
> /usr/compat/linux/lib/libdl-2.5.so
> 28074000-28075000 rwxp 4000 00:00 1719493
> /usr/compat/linux/lib/libdl-2.5.so
> 28075000-28076000 rwxp 1000 00:00 0
> 28076000-28088000 r-xp 0001e000 00:00 1719511
> /usr/compat/linux/lib/libpthread-2.5.so
> 28088000-28089000 r-xp 0001e000 00:00 1719511
> /usr/compat/linux/lib/libpthread-2.5.so
> 28089000-2808a000 rwxp 0001e000 00:00 1719511 /usr/compat/linuxAbort
> trap (core dumped)
> debug.cmds:1: Error in sourced command file:
> Previous frame inner to this frame (corrupt stack?)
> email debug.log to linux at valvesoftware.com
>  Wed Sep 12
> 20:27:04 SAMST 2007: Server restart in 10 seconds
> Wed Sep 12 20:27:06 SAMST 2007: Server Quit
> #
> ===
>
> # uname -a
> FreeBSD damask 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Sep 12 17:04:55
> SAMST 2007 root at cs.udmvt.ru
> :/usr/obj/usr/
>src/sys/CS2  i386
>
> # sysctl compat
> compat.linux.oss_version: 198144
> compat.linux.osrelease: 2.6.16
> compat.linux.osname: Linux
>
> # kldstat
> Id Refs AddressSize Name
> 1   14 0xc040 3e6ee0   kernel
> 21 0xc07e7000 69514acpi.ko
> 31 0xc3ddd000 7000 linprocfs.ko
> 42 0xc3de4000 21000linux.ko
> 51 0xc3e0e000 3000 linsysfs.ko
>
> # mount|grep linux
> linprocfs on /usr/compat/linux/proc (linprocfs, local)
> linsysfs on /usr/compat/linux/sys (linsysfs, local)
>
> # pkg_info | grep linux
> linux_base-fc6-6_3  Base set of packages needed in Linux mode (for
> i386/amd64)
>
> [private links to debug.log & ktrace.out]
>
> please send me message after downloaded this files (for removing)
>
> /Vladimir Ermakov
>
> cross-posting:
> http://lists.freebsd.org/pipermail/freebsd-emulation/2007-September/003960.
>html
I haven't tried it on i386 yet, but I know that this works on amd64 with linux 
2.4 compat and linux_base-fc4 on FreeBSD 7.

- Pieter
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Intel D975XBX2 BTX halted

[Kirby Kuehl]

After experiencing overheating problems, I purchased a new CPU and motherboard 
(Intel D975XBX2) which has a built in Raid controller Marvell 88SE61xx
I connected my existing FreeBSD-STABLE SATA drive to port 0.

Upon boot, I receive the following error:

int=000d err= efl=00030086 eip=1526
eax=0110 ebx= ecx= edx=95200110
esi=3684 edi=36ac ebp=4eac esp=4e9a
cs=cf00 ds=9b00 es=cf00 fs=9941 gs=9ac0 ss=9b00
sc:eip=2e 0f 01 16 8d 07 0f 20-c0 40 0f 22 c0 b8 08 00
8e e8 67 66 65 89 0a 0f-20 c0 48 0f 22 c0 66 58
ss:esp=10 01 00 00 c0 9a 20 95-00 00 ff ff 00 00 ac 36
84 36 d4 4e 6c 32 00 01-00 00 00 40 25 00 00 00
BTX halted

I have tried disabling the secondary SATA Controller, but it says no boot 
devices available.
I have tried configuring my ATA/IDE Mode as Native (the default) and Legacy.
I have tried configuring SATA as IDE, AHCI, and RAID
I have tried S.M.A.R.T both enabled and disabled.


Similar Posts:
http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/146146.html
http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/146252.html

Thanks in advance,

Kirby
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

fsck of large volume with small memory

[sam]

hi, all
http://lists.freebsd.org/pipermail/freebsd-questions/2007-June/151686.html

my problem
# fsck /dev/aacd0s1f
** /dev/aacd0s1f (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
fsck_ufs: cannot alloc 2378019004 bytes for inoinfo

# cat /boot/loader.conf
kern.maxdsiz="1073741824" # 1GB
kern.dfldsiz="1073741824" # 1GB
kern.maxssiz="134217728" # 128MB

# uname -rms
FreeBSD 6.2-STABLE amd64

# limits
Resource limits (current):
 cputime  infinity secs
 filesize infinity kB
 datasize  1048576 kB
 stacksize  131072 kB
 coredumpsize infinity kB
 memoryuseinfinity kB
 memorylocked infinity kB
 maxprocesses 5547
 openfiles   11095
 sbsize   infinity bytes
 vmemoryuse   infinity kB

# dmesg|less
Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 6.2-STABLE #4: Wed Sep 19 13:56:13 MSD 2007
   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STONE
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Opteron(tm) Processor 248 (2191.66-MHz K8-class CPU)
 Origin = "AuthenticAMD"  Id = 0xf5a  Stepping = 10
 
Features=0x78bfbff

 AMD Features=0xe0500800
real memory  = 2147418112 (2047 MB)
avail memory = 2066296832 (1970 MB)
ACPI APIC Table: 

any solutions ?

/Vladimir Ermakov


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel panic on PowerEdge 1950 under certain stress load

[Ivan Voras]

Benjie Chen wrote:


Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin
 c066c7b4 T _mtx_lock_spin
 c066c85c T _mtx_unlock_sleep

So this could mean that independent stress tests will not result in panic if
there aren't enough concurrency to cause the problem.


When you get a kernelbacktrace, see if it's the same as the one 
mentioned here:

http://lists.freebsd.org/pipermail/freebsd-current/2007-September/076932.html




signature.asc
Description: OpenPGP digital signature

Re: Kernel panic on PowerEdge 1950 under certain stress load

[Kris Kennaway]

Borja Marcos wrote:


On 24 Sep 2007, at 11:33, Kris Kennaway wrote:


Borja Marcos wrote:
I don't have the exact IP address involved, but we experienced 
consistent panics in two heavily loaded mail servers (same hardware 
models, Dell Powereedge) runnning Postfix and FreeBSD 6.2.
Suspecting an issue with the IP stack and smp I tried to set 
"debug.mpsafenet=0" and the problems are gone. Of course I've lost 
some performance, but the systems have been solid for some weeks so far.


What number is the PR with the details?


Sorry, I couldn't diagnose anything properly. When it happened the 
sysadmin didn't give me the panic details, and being production machines 
the main priority was to put them back into service as soon as possible.


Would it be a good idea to file a PR with such fuzzy information? I 
don't think so, that's why I didn't do it. Of course I can do it if 
someone thinks it's worth. But unfortunately I cannot get more precise 
details.


No it isn't.  You will need to do some more work to obtain this 
information, otherwise your bug will probably not be fixed. 
debug.mpsafenet=0 is no longer an option in 7.0, so you will have to 
deal with this sooner or later.


Kris

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel panic on PowerEdge 1950 under certain stress load

[Borja Marcos]

On 24 Sep 2007, at 11:33, Kris Kennaway wrote:


Borja Marcos wrote:
I don't have the exact IP address involved, but we experienced  
consistent panics in two heavily loaded mail servers (same  
hardware models, Dell Powereedge) runnning Postfix and FreeBSD 6.2.
Suspecting an issue with the IP stack and smp I tried to set  
"debug.mpsafenet=0" and the problems are gone. Of course I've lost  
some performance, but the systems have been solid for some weeks  
so far.


What number is the PR with the details?


Sorry, I couldn't diagnose anything properly. When it happened the  
sysadmin didn't give me the panic details, and being production  
machines the main priority was to put them back into service as soon  
as possible.


Would it be a good idea to file a PR with such fuzzy information? I  
don't think so, that's why I didn't do it. Of course I can do it if  
someone thinks it's worth. But unfortunately I cannot get more  
precise details.




Borja.


"The thing he realised about the windows was this: because they had  
been converted into openable windows after they had first been  
designed to be impregnable, they were, in fact, much less secure than  
if they had been designed as openable windows in the first place."

   Douglas Adams, "Mostly Harmless"



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel panic on PowerEdge 1950 under certain stress load

[Kris Kennaway]

Benjie Chen wrote:

Hi FreeBSD hackers and engineers,

I am experiencing a kernel panic that comes on when my new PowerEdge 1950
FreeBSD 6.2 setup is under a certain stress load. I've emailed a few people
on the list who have given me useful comments, some of which I am still
following up. But I wanted to send a general cry for help to see if there
are more knowledge out there about this problem.

FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver (PERC5i). 4GB
RAM. I am currently running i386, and not amd64, due to various reasons.

I've ran exhaustively memory tests, disk tests, and network tests and cannot
produce the kernel panic. I worked with Dell support to run memory test 1
DIMM at a time and cannot find any problem.  With 1 DIMM at a time, I could
still get the kernel panic under my work load.

My work load is heavily hitting a web site running on the machine and
requiring the web service to do MySQL requests. On the side, I am running a
bunch of scripts that mostly read from the MySQL database but also write to
it occasionally. Not memory intensive -- still have usually about 1GB free
memory, but fairly disk intensive. I don't get disk errors. Anywhere from
between 10 minutes to 4 or 5 hours into the test, I get the kernel panic.
Again, still no disk errors. I turned off soft-update, still happens.

Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin
 c066c7b4 T _mtx_lock_spin
 c066c85c T _mtx_unlock_sleep

So this could mean that independent stress tests will not result in panic if
there aren't enough concurrency to cause the problem.

There are a few other complaints about kernel panics at the same IP on the
web (google 0xc066c731)... I was wondering if anyone had dealt with this
before and if there are any work arounds?


The IP is meaningless, it changes each time you compile your kernel. 
Unfortunately even knowing that it is in that symbol is nearly 
meaningless, because it doesn't provide enough information (only that 
your panic involved a spin mutex somehow).  Please read the chapter on 
kernel debugging in the developers handbook and file a PR containing 
enough information for a developer to investigate the problem.


Kris

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel panic on PowerEdge 1950 under certain stress load

[Kris Kennaway]

Borja Marcos wrote:


On 22 Sep 2007, at 00:26, Benjie Chen wrote:


FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver (PERC5i). 4GB
RAM. I am currently running i386, and not amd64, due to various reasons.

Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin
 c066c7b4 T _mtx_lock_spin
 c066c85c T _mtx_unlock_sleep

So this could mean that independent stress tests will not result in 
panic if

there aren't enough concurrency to cause the problem.


I don't have the exact IP address involved, but we experienced 
consistent panics in two heavily loaded mail servers (same hardware 
models, Dell Powereedge) runnning Postfix and FreeBSD 6.2.


Suspecting an issue with the IP stack and smp I tried to set 
"debug.mpsafenet=0" and the problems are gone. Of course I've lost some 
performance, but the systems have been solid for some weeks so far.


What number is the PR with the details?

Kris

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

linuxolator problem on i386

[sam]

Hi

# su hlds -c "ktrace -i ./hlds_run -game cstrike +ip 0.0.0.0 +port 27015 
+map de_dust -debug"

Auto detecting CPU
Using Pentium II Optimised binary.
Enabling debug mode
Auto-restarting the server on crash

Console initialized.
scandir failed:/usr/home/hlds/1.6/./platform/SAVE
Protocol version 47
Exe version 1.1.2.5/Stdio (cstrike)
Exe build: 20:02:49 Oct 24 2006 (3651)
STEAM Auth Server
couldn't exec language.cfg
Server IP address 0.0.0.0:27015
scandir failed:/usr/home/hlds/1.6/./platform/SAVE
*** glibc detected *** ./hlds_i686: double free or corruption (!prev): 
0x08da3738 ***

=== Backtrace: =
/lib/libc.so.6[0x2811ac88]
/lib/libc.so.6(cfree+0x90)[0x2811e230]
/lib/libc.so.6(closedir+0x28)[0x2813ecf8]
/lib/libc.so.6(scandir+0x14b)[0x2813f21b]
/usr/home/hlds/1.6/filesystem_stdio_i386.so(findFileInDirCaseInsensitive__FPCc+0xe4)[0x28af41d8] 

/usr/home/hlds/1.6/filesystem_stdio_i386.so(FS_stat__17CFileSystem_StdioPCcP4stat+0x40)[0x28af861c] 

/usr/home/hlds/1.6/filesystem_stdio_i386.so(FastFindFileSize__15CBaseFileSystemPCQ215CBaseFileSystem11CSearchPathPCc+0x17e)[0x28af572a] 

/usr/home/hlds/1.6/filesystem_stdio_i386.so(Size__15CBaseFileSystemPCc+0x5b)[0x28af557b] 


/usr/home/hlds/1.6/engine_i686.so(FS_FileSize+0x2a)[0x2828679e]
=== Memory map: 
08048000-08054000 r-xp 0003a000 00:00 1931338 
/usr/home/hlds/1.6/hlds_i686
08054000-0805b000 rw-p 0003a000 00:00 1931338 
/usr/home/hlds/1.6/hlds_i686

0805b000-0805e000 rw-p 00d6 00:00 0
0805e000-08dbb000 rwxp 00d6 00:00 0
28054000-2806d000 r-xp 0001e000 00:00 1719480 
/usr/compat/linux/lib/ld-2.5.so
2806d000-2806e000 r-xp 0001e000 00:00 1719480 
/usr/compat/linux/lib/ld-2.5.so

2806e000-2806f000 rw-p 2000 00:00 0
2806f000-2807 rwxp 2000 00:00 0
28071000-28073000 r-xp 4000 00:00 1719493 
/usr/compat/linux/lib/libdl-2.5.so
28073000-28074000 r-xp 4000 00:00 1719493 
/usr/compat/linux/lib/libdl-2.5.so
28074000-28075000 rwxp 4000 00:00 1719493 
/usr/compat/linux/lib/libdl-2.5.so

28075000-28076000 rwxp 1000 00:00 0
28076000-28088000 r-xp 0001e000 00:00 1719511 
/usr/compat/linux/lib/libpthread-2.5.so
28088000-28089000 r-xp 0001e000 00:00 1719511 
/usr/compat/linux/lib/libpthread-2.5.so
28089000-2808a000 rwxp 0001e000 00:00 1719511 /usr/compat/linuxAbort 
trap (core dumped)

debug.cmds:1: Error in sourced command file:
Previous frame inner to this frame (corrupt stack?)
email debug.log to linux at valvesoftware.com 

Wed Sep 12 20:27:04 SAMST 2007: Server restart in 10 seconds
Wed Sep 12 20:27:06 SAMST 2007: Server Quit
#
===

# uname -a
FreeBSD damask 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Sep 12 17:04:55 
SAMST 2007 root at cs.udmvt.ru :/usr/obj/usr/src/sys/CS2  i386


# sysctl compat
compat.linux.oss_version: 198144
compat.linux.osrelease: 2.6.16
compat.linux.osname: Linux

# kldstat
Id Refs AddressSize Name
1   14 0xc040 3e6ee0   kernel
21 0xc07e7000 69514acpi.ko
31 0xc3ddd000 7000 linprocfs.ko
42 0xc3de4000 21000linux.ko
51 0xc3e0e000 3000 linsysfs.ko

# mount|grep linux
linprocfs on /usr/compat/linux/proc (linprocfs, local)
linsysfs on /usr/compat/linux/sys (linsysfs, local)

# pkg_info | grep linux
linux_base-fc6-6_3  Base set of packages needed in Linux mode (for 
i386/amd64)


[private links to debug.log & ktrace.out]

please send me message after downloaded this files (for removing)

/Vladimir Ermakov

cross-posting:
http://lists.freebsd.org/pipermail/freebsd-emulation/2007-September/003960.html


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Kernel panic on PowerEdge 1950 under certain stress load

[Borja Marcos]

On 22 Sep 2007, at 00:26, Benjie Chen wrote:

FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver  
(PERC5i). 4GB
RAM. I am currently running i386, and not amd64, due to various  
reasons.


Kernel panic is at 0xC066C731, which from nm shows it's in  
mtx_lock_spin

 c066c7b4 T _mtx_lock_spin
 c066c85c T _mtx_unlock_sleep

So this could mean that independent stress tests will not result in  
panic if

there aren't enough concurrency to cause the problem.


I don't have the exact IP address involved, but we experienced  
consistent panics in two heavily loaded mail servers (same hardware  
models, Dell Powereedge) runnning Postfix and FreeBSD 6.2.


Suspecting an issue with the IP stack and smp I tried to set  
"debug.mpsafenet=0" and the problems are gone. Of course I've lost  
some performance, but the systems have been solid for some weeks so far.






Borja.


"The thing he realised about the windows was this: because they had  
been converted into openable windows after they had first been  
designed to be impregnable, they were, in fact, much less secure than  
if they had been designed as openable windows in the first place."

   Douglas Adams, "Mostly Harmless"



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Serial console/remote install discussion

[Eugene Grosbein]

On Fri, Sep 21, 2007 at 09:19:17AM -0700, Jeremy Chadwick wrote:
> I'd like to open up a discussion regarding FreeBSD serial console and

> the aspect of installation via serial console.
> 
> There seem to be quite a few surprises in regards to installing (or even
> using!) FreeBSD this way.  I thought I'd mention some of them, in hopes
> that by bringing them to light we can work towards making the
> installation process easier, or at least more headless-friendly.
> 
> 1) Administrators are required to "build their own installation disks"
> (the Handbook goes over this with regards to floppy disks) if they want
> FreeBSD installs to support serial console.  Based on what I've read,
> the procedure is required because the stock installation disks lack a
> /boot.config that contains -h.
> 
> Has anyone ever proposed including a /boot.config on all the
> installation mediums that contains -P by default?  I don't know how
> reliable -P is, but I've used it for years on numerous servers (all
> different hardware) without any issues; others may have different
> experiences.

See also: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/58951

> Which brings me to the next item...
> 
> 2) FreeBSD's serial vs. VGA concept (keyword: versus) is disheartening.
> The whole "one or the other" concept is unrealistic in this day and age,
> and this was more or less admitted by the Dragonfly folks when they
> re-wrote whatever code to get simultaneous dual console (VGA+serial)
> working.

This seems to be wrong: FreeBSD has dual console support for quite long time.

Eugene Grosbein

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Kernel panic on PowerEdge 1950 under certain stress load

[Benjie Chen]

Hi FreeBSD hackers and engineers,

I am experiencing a kernel panic that comes on when my new PowerEdge 1950
FreeBSD 6.2 setup is under a certain stress load. I've emailed a few people
on the list who have given me useful comments, some of which I am still
following up. But I wanted to send a general cry for help to see if there
are more knowledge out there about this problem.

FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver (PERC5i). 4GB
RAM. I am currently running i386, and not amd64, due to various reasons.

I've ran exhaustively memory tests, disk tests, and network tests and cannot
produce the kernel panic. I worked with Dell support to run memory test 1
DIMM at a time and cannot find any problem.  With 1 DIMM at a time, I could
still get the kernel panic under my work load.

My work load is heavily hitting a web site running on the machine and
requiring the web service to do MySQL requests. On the side, I am running a
bunch of scripts that mostly read from the MySQL database but also write to
it occasionally. Not memory intensive -- still have usually about 1GB free
memory, but fairly disk intensive. I don't get disk errors. Anywhere from
between 10 minutes to 4 or 5 hours into the test, I get the kernel panic.
Again, still no disk errors. I turned off soft-update, still happens.

Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin
 c066c7b4 T _mtx_lock_spin
 c066c85c T _mtx_unlock_sleep

So this could mean that independent stress tests will not result in panic if
there aren't enough concurrency to cause the problem.

There are a few other complaints about kernel panics at the same IP on the
web (google 0xc066c731)... I was wondering if anyone had dealt with this
before and if there are any work arounds?

Thanks,
Benjie
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"