SMP problem on E7500 chipset
Hi, I have some strange problem with FreeBSD 4.6 and SMP kernel on a dual CPU machine. The hardware is: Motherboard SUPER P4DP6, chipset Intel E7500 2 CPUs: Intel Xeon 2.2Ghz Adaptec AIC-7899W SCSI controller 2 Intel-82550 Ethernet controllers When I try to boot an SMP kernel, it tells me that 4 CPUs are found. Network operation slows down to hell, syslog is full of Jul 31 14:44:54 superjob /kernel: fxp0: device timeout Without SMP, everything runs fine. Syslog output regarding dmesg and kernel config are below. Regards, Eugene L. Vorokov Jul 31 14:40:12 superjob /kernel: FreeBSD 4.6-RELEASE #0: Wed Jul 31 14:35:07 MS D 2002 Jul 31 14:40:12 superjob /kernel: [EMAIL PROTECTED]:/usr/src/sys/compile/maxik Jul 31 14:40:12 superjob /kernel: Timecounter i8254 frequency 1193182 Hz Jul 31 14:40:12 superjob /kernel: CPU: Pentium 4 (2196.27-MHz 686-class CPU) Jul 31 14:40:12 superjob /kernel: Origin = GenuineIntel Id = 0xf24 Stepping = 4 Jul 31 14:40:12 superjob /kernel: Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE ,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2 ,SS,b28,ACC Jul 31 14:40:12 superjob /kernel: real memory = 2146959360 (2096640K bytes) Jul 31 14:40:12 superjob /kernel: avail memory = 2088005632 (2039068K bytes) Jul 31 14:40:12 superjob /kernel: Programming 24 pins in IOAPIC #0 Jul 31 14:40:12 superjob /kernel: IOAPIC #0 intpin 2 - irq 0 Jul 31 14:40:12 superjob /kernel: Programming 24 pins in IOAPIC #1 Jul 31 14:40:12 superjob /kernel: Programming 24 pins in IOAPIC #2 Jul 31 14:40:12 superjob /kernel: Programming 24 pins in IOAPIC #3 Jul 31 14:40:12 superjob /kernel: Programming 24 pins in IOAPIC #4 Jul 31 14:40:12 superjob /kernel: FreeBSD/SMP: Multiprocessor motherboard Jul 31 14:40:12 superjob /kernel: cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 Jul 31 14:40:12 superjob /kernel: cpu1 (AP): apic id: 6, version: 0x00050014, at 0xfee0 Jul 31 14:40:12 superjob /kernel: cpu2 (AP): apic id: 1, version: 0x00050014, at 0xfee0 Jul 31 14:40:12 superjob /kernel: cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 Jul 31 14:40:12 superjob /kernel: io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 Jul 31 14:40:12 superjob /kernel: io1 (APIC): apic id: 3, version: 0x00178020, at 0xfec8 Jul 31 14:40:12 superjob /kernel: io2 (APIC): apic id: 4, version: 0x00178020, at 0xfec80400 Jul 31 14:40:12 superjob /kernel: io3 (APIC): apic id: 5, version: 0x00178020, at 0xfec81000 Jul 31 14:40:12 superjob /kernel: io4 (APIC): apic id: 8, version: 0x00178020, at 0xfec81400 Jul 31 14:40:12 superjob /kernel: Preloaded elf kernel kernel at 0xc02f. ul 31 14:40:12 superjob /kernel: md0: Malloc disk Jul 31 14:40:12 superjob /kernel: Using $PIR table, 28 entries at 0xc00fde00 Jul 31 14:40:12 superjob /kernel: npx0: math processor on motherboard Jul 31 14:40:12 superjob /kernel: npx0: INT 16 interface Jul 31 14:40:12 superjob /kernel: pcib0: Host to PCI bridge on motherboard Jul 31 14:40:12 superjob /kernel: IOAPIC #0 intpin 16 - irq 2 Jul 31 14:40:12 superjob /kernel: IOAPIC #0 intpin 19 - irq 5 Jul 31 14:40:12 superjob /kernel: IOAPIC #0 intpin 18 - irq 10 Jul 31 14:40:12 superjob /kernel: pci0: PCI bus on pcib0 Jul 31 14:40:12 superjob /kernel: pci0: unknown card (vendor=0x8086, dev=0x254 1) at 0.1 Jul 31 14:40:12 superjob /kernel: pcib1: PCI to PCI bridge (vendor=8086 device= 2543) at device 2.0 on pci0 Jul 31 14:40:12 superjob /kernel: pci1: PCI bus on pcib1 Jul 31 14:40:12 superjob /kernel: pci1: unknown card (vendor=0x8086, dev=0x146 1) at 28.0 Jul 31 14:40:12 superjob /kernel: pcib2: PCI to PCI bridge (vendor=8086 device= 1460) at device 29.0 on pci1 Jul 31 14:40:12 superjob /kernel: IOAPIC #2 intpin 4 - irq 11 Jul 31 14:40:12 superjob /kernel: pci2: PCI bus on pcib2 Jul 31 14:40:12 superjob /kernel: pcib3: PCI to PCI bridge (vendor=8086 device= 0962) at device 2.0 on pci2 Jul 31 14:40:12 superjob /kernel: pci3: PCI bus on pcib3 ul 31 14:40:12 superjob /kernel: mly0: Mylex AcceleRAID 170 mem 0xfe20-0x fe201fff irq 11 at device 2.1 on pci2 Jul 31 14:40:12 superjob /kernel: mly0: AcceleRAID 170 , 1 channel, firmware 6. 00-7-00 (20001214), 128MB RAM Jul 31 14:40:12 superjob /kernel: pci1: unknown card (vendor=0x8086, dev=0x146 1) at 30.0 Jul 31 14:40:12 superjob /kernel: pcib4: PCI to PCI bridge (vendor=8086 device= 1460) at device 31.0 on pci1 Jul 31 14:40:12 superjob /kernel: pci4: PCI bus on pcib4 Jul 31 14:40:12 superjob /kernel: pcib5: PCI to PCI bridge (vendor=8086 device= 2545) at device 3.0 on pci0 Jul 31 14:40:12 superjob /kernel: pci5: PCI bus on pcib5 Jul 31 14:40:12 superjob /kernel: pci5: unknown card (vendor=0x8086, dev=0x146 1) at 28.0 Jul 31 14:40:12 superjob /kernel: pcib6: PCI to PCI bridge (vendor=8086 device= 1460) at device 29.0 on pci5 Jul 31 14:40:12 superjob /kernel: pci6: PCI bus on pcib6 Jul 31 14:40:12 superjob /kernel: pci5: unknown card (vendor=0x8086, dev=0x146 1) at 30.0 Jul 31
Re: allocating memory
On Wed, Jun 05, 2002 at 11:56:57PM -0500, Stephen Montgomery-Smith wrote: I have access to a rather large computer (3GB of RAM) and I would like to write a program to access most of this memory. I find that I am unable to malloc more than about 0.5 GB of memory, even if I do it in small increments. Now I am trying mmap, and this lets me get to about 2.5 GB of memory (again I ask for the memory in small increments). What is it that causes these limitations? The 0.5G memory limit is most probably caused my your datasize limit, which you can see by typing limits on the shell. malloc() increases process heap size using sbrk() syscall, and datasize limit holds maximum heap size that can be set for a process that way. mmap() with MAP_ANON doesn't use sbrk() and allocates memory from global heap, so this way you can get as much memory as possble, AFAIK. However, don't forget that some memory is used by or reserved for the kernel. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
quota output
Hi, I was setting up quotas on 20gb disk, and seen this: vel@bugz:/home/vel # quota -v for_all Disk quotas for user for_all (uid 1003): Filesystem usage quota limit grace files quota limit grace /usr13471298 01350 45321 0 0 It doesn't look very nice ... Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
C vs C++
Hello, I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Is it slower, does it produce less effective code, why is it like that, etc ... or please direct me to some articles where this can be explained. I apologize for the offtopic whenever it happens, but this issue really pisses me off now. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: THTTPD web server: problems with KQUEUE on FreeBSD 4.5-STABLE
I still wonder, whether this problem occurs because of how thttpd does things, or how FreeBSD implements kqueue stuff, however, I am not sure that I will have enough time to dig deep into this. Right now I'm pretty happy with the fact that I got thttpd working again, and those 200 0 messages are no longer in my logs. However, it is still an issue to worry about, I believe, and I will be a lot more happy if my experience helps either folks to find and fix some probable bugs (if any) in their excellent software. Hm, there is no such thing as kqread() I think. There are kqueue() and kevent(). You didn't show the piece of code that uses it, so it's hard to say what the problem is. I recommend you to read jlemon's paper at http://www.freebsd.org/~jlemon/kqueue.pdf to see how to you should work with kqueue() and kevent(). As for performance, I can confirm that kqueue() functions is better than select()/poll() at least in situations where we have to do non-blocking i/o on some large number of fd's (say, several thousands), and actually each time we see some activity only on small number of them (say, several hundred). That's how ircd usually works, and system load goes down significantly with kqueue() comparing to select(). Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: file name
I want to control for example open() syscall:
static int my_open(register struct proc *p, register struct open_args *ea)
{
[...]
}
Name of file to open is in ea-path, but this name can be: ./somefile
and i need a full path to it.
I faced that problem once. I used an ugly hack: simulation of __getcwd()
syscall. You need to allocate user memory via mmap() with MAP_ANON flag,
pass it to __getcwd(), then copy string to kernel using copyin() or like
that, and munmap() the memory. This is neither proper nor efficient way
to do that, but it's easy and it works. Note that in case of ./ or
several ../ in the file name you may need to do some extra processing
to get correct full path.
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Super Block
What does the SuperBlock actually do ? Why is the SuperBlock so critical ? Can anyone give me a *good* summary on the purpose of the Super Block ? And/Or any recommendations ? On FreeBSD, 'man fs' can help you I think. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: email
email áàçû ìîñêâû, ïèòåðà, ðîññèè è ïð. ðàññûëêà email ñîîáùåíèé. ÷òî áû óçíàòü ïîäðîáíåå, íàïèøèòå ïèñüìî íà [EMAIL PROTECTED] , óêàçàâ â òåìå ÇÀÏÐÎÑ (ñîîáùåíèÿ áåç ñëîâà ÇÀÏÐÎÑ - àâòîìàòè÷åñêè óäàëÿþòñÿ) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Can someone filter this spammer please ? It's email in russian encouraging you to buy some databases of russian companies' email addresses and such. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kld question
I made a kernel module that logs execve system calls by intercepting the execve syscall, log it and then execute the original syscall. This was pretty straightforward to do, and it works beautifully on STABLE, but on CURRENT it bombs on this line: uid = p-p_cred-pc_ucred-cr_uid; So, my question: how does one obtain the UID from the proc struct in CURRENT? Preferably in a way that will both work on CURRENT and STABLE. Before KSE changes went in, it was p-p_ucred-cr_uid, that's what I use in very similar module with kernel from about August 2001. Now it's probably changed again, but I don't cvsup for now, so I don't know exactly. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Motion for removal of xargs(1) from base system
My, is it April 1st already? How quickly time flies! December feels like it was just yesterday! - Jordan Ehe, as far as I can see some people even have taken it seriously :) This probably shows that when you have to read 300 emails/day, your attention slowly but constantly leaves you. :) I think the original author's point was to write some rant about recent removal of some frequently used (as he thinks) tools from the base system. At least I had fun reading it :) Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: offtopic: assembly
Fabio Miranda wrote: I want to understand Why each byte (8 bit of data and 1 bit of parity) has one bit of parity? To permit the hardware to catch single bit errors. ECC is a better version of this, which permits the hardware to correct single bit errors, and catch multiple bit errors. Well, AFAIK, ECC cat correct single bit errors and detect double bit errors. Everything else is problematic, it may or may not detect multiple bit errors, depending on conditions. Just my 2 cents. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re:
--_ABC1234567890DEF_ Content-Type: audio/x-wav; name=New_Napster_Site.MP3.pif Content-Transfer-Encoding: base64 Content-ID: EA4DMGBP9p You virus senders, please, do not send your viruses to this list. We all read mail under Unix and don't give a shit to these windows executables. It's just annoying, but doesn't give you anything. Thank you. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: buildworld breakage during make depend at usr.bin/kdump
David O'Brien [EMAIL PROTECTED] writes: because `echo' nicely removes \n's from env vars when it prints them. des@des ~% foo='bar quote baz' des@des ~% echo $foo bar baz des@des ~% /bin/echo $foo bar baz Uhmz ? bash-2.05# foo='bar baz' bash-2.05# echo $foo bar baz bash-2.05# /bin/echo $foo bar baz bash-2.05# set |grep foo foo=$'bar\nbaz' bash-2.05# Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
kernel threads
Hello, does FreeBSD currently have something similar to linux's kernel_thread() ? Or is it what KSE intends to implement ? Can I somehow run independent kernel thread, which will, for instance, check some flag that I set inside interrupt handler and do some job that can't be done in the interrupt ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
how to make 'for' understand two words as a single argument
Hello,
I have a script which is supposed to convert all filenames to lowercase
recursively from current directory. It looks like:
echo Processing files
for i in `ls |grep [A-Z]`; \
do mv $i `echo $i |tr [A-Z] [a-z]`; echo $i;\
done;
for i in `find . -name * -type d -maxdepth 1`;\
do if [ $i != . ]; then cd $i; echo Processing sub-dir $i; $0; cd ..; fi \
done;
It works fine unless some file or directory has a space in it's name.
It this case each word is interpreted as a separate argument by 'for'
and script doesn't find files.
I tried this:
for i in `ls |grep [A-Z] |awk '{printf(\%s\\n, $0);}'`; \
but it doesn't work either - I still get 'word1' and 'word2'
separately.
How am I supposed to get this working ?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: how to make 'for' understand two words as a single argument
Eugene L. Vorokov wrote: I have a script which is supposed to convert all filenames to lowercase recursively from current directory. It looks like: echo Processing files for i in `ls |grep [A-Z]`; \ do mv $i `echo $i |tr [A-Z] [a-z]`; echo $i;\ done; ls |grep [A-Z] | while read i; \ do mv $i `echo $i |tr [A-Z] [a-z]`; echo $i;\ done for i in `find . -name * -type d -maxdepth 1`;\ do if [ $i != . ]; then cd $i; echo Processing sub-dir $i; $0; cd ..; fi \ done; find . -name * -type d -maxdepth 1 | while read i; \ do if [ $i != . ]; then cd $i; echo Processing sub-dir $i; $0; cd ..; fi \ done This way it works fine, thanks ! Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel-loadable Root Kits
1) scan the sysent table and check syscalls pointers (generally, rootkits intercepts syscalls) This can get really hairy. To scan the syscall table, even if you are 'root' and directly access /dev/mem you will have to use some system calls to open(), read() and seek() into the /dev/mem device. But those syscalls might be the intercepted ones: ouch! Of course this is not to be done from userland program. You should write your own KLD module which will compare sysent[] values against standart system calls and list the differences. I don't really see how root kit can prevent such scan. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
corrupted 'w' output
Hello, I updated from -current yesterday, ran make world; make kernel KERNCONF=X and went to bed. When I rebooted with fresh kernel this morning, I noticed something strange: vel@bugz:/usr/src # w 3:47PM up 5:38, 4 users, load averages: 0.00, 0.11, 0.08 USER TTY FROM LOGIN@ IDLE WHAT vel p0 kg.infotecs.ru 10:11AM 2 ssh -l vel bsx.ru vel p1 kg.infotecs.ru 10:22AM - w vel p2 kg.infotecs.ru 12:13PM 1:55 \M-[\M-!\^D\b (tcsh) vel p3 kg.infotecs.ru 12:53PM 2 \M-[\M-!\^D\b (tcsh) This only happens for terminals that are in a shell, when something else is running, output isn't corrupted. I think someone reported similar problem with 'ps' output. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC request (was Re: symlink(2) [Was: Re: tcsh.cat])
I comitted a fix to -current two months ago. It's still in my -stable tree... if Jordan gives the O.K., I will MFC it to -stable. -Matt Erm, sorry, but what does MFC mean here ? I see this term used a lot and I can even guess what it stands for, but I may get it incorrectly ... Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
KLD subsystem improvement
Hello, I'm going to implement a small improvement to a KLD system. I want linker file not to be loaded at all when all modules inside it fail to load for some reasons. I think that would be logical behaviour. Does anyone think that such change would break something ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
problem with unloading device driver
Hello,
I have a module which adds new device. It does make_dev() and then simulates
mknod() syscall, so that /dev/name is always automatically created.
Also I have a daemon which reads from and writes to this device. The daemon
opens the device once and then holds it open. When my module unloads,
it simulates unlink() and then does detsroy_dev(). I just noticed that
when I unload my module, the first write() by daemon to the fd associated with
that device causes system to crash. Trace looks like this:
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc0177ed7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:330
#2 0xc01782f1 in panic (fmt=0xc0276af8 bwrite: buffer is not busy???) at
/usr/src/sys/kern/kern_shutdown.c:623
#3 0xc01a4a7b in bwrite (bp=0xc26b2390) at /usr/src/sys/kern/vfs_bio.c:672
#4 0xc01a5d08 in vfs_bio_awrite (bp=0xc26b2390) at /usr/src/sys/kern/vfs_bio.c:1538
#5 0xc01580ac in spec_fsync (ap=0xc7319cec) at /usr/src/sys/fs/specfs/spec_vnops.c:400
#6 0xc0157cb9 in spec_vnoperate (ap=0xc7319cec) at
/usr/src/sys/fs/specfs/spec_vnops.c:119
#7 0xc02161bc in ffs_sync (mp=0xc05ac000, waitfor=2, cred=0xc05b1d00, p=0xc02d3fa0)
at vnode_if.h:441
#8 0xc01b1677 in sync (p=0xc02d3fa0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:622
#9 0xc0177acb in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:239
#10 0xc01782f1 in panic (fmt=0xc0288ffe %s) at /usr/src/sys/kern/kern_shutdown.c:623
#11 0xc025337b in trap_fatal (frame=0xc7319dec, eva=12) at
/usr/src/sys/i386/i386/trap.c:936
#12 0xc02530c5 in trap_pfault (frame=0xc7319dec, usermode=0, eva=12) at
/usr/src/sys/i386/i386/trap.c:850
#13 0xc0252a44 in trap (frame={tf_fs = -953090024, tf_es = -953090032, tf_ds =
-1071972336, tf_edi = -953049344,
tf_esi = -952992672, tf_ebp = -953049500, tf_isp = -953049576, tf_ebx =
-1053283072, tf_edx = -953049456, tf_ecx = 7,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1072332928, tf_cs = 8,
tf_eflags = 66195, tf_esp = -1053283072,
tf_ss = -953049344}) at /usr/src/sys/i386/i386/trap.c:405
#14 0xc0157f80 in spec_write (ap=0xc7319e90) at /usr/src/sys/fs/specfs/spec_vnops.c:289
#15 0xc0157cb9 in spec_vnoperate (ap=0xc7319e90) at
/usr/src/sys/fs/specfs/spec_vnops.c:119
#16 0xc01b6f6b in vn_write (fp=0xc137f280, uio=0xc7319f00, cred=0xc1363800, flags=0,
p=0xc72a5540) at vnode_if.h:303
#17 0xc018fc18 in dofilewrite (p=0xc72a5540, fp=0xc137f280, fd=3, buf=0xbfbffbab,
nbyte=1, offset=-1, flags=0)
at /usr/src/sys/sys/file.h:162
#18 0xc018face in write (p=0xc72a5540, uap=0xc7319f80) at
/usr/src/sys/kern/sys_generic.c:334
#19 0xc02538a5 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi =
-1077937128, tf_esi = -1077937136,
tf_ebp = -1077937220, tf_isp = -953049132, tf_ebx = 1, tf_edx = 0, tf_ecx = 0,
tf_eax = 4, tf_trapno = 12, tf_err = 2,
tf_eip = 671760164, tf_cs = 31, tf_eflags = 663, tf_esp = -1077937280, tf_ss =
47}) at /usr/src/sys/i386/i386/trap.c:1123
#20 0xc024479d in syscall_with_err_pushed ()
#21 0x80486bd in ?? ()
(kgdb) frame 14
#14 0xc0157f80 in spec_write (ap=0xc7319e90) at /usr/src/sys/fs/specfs/spec_vnops.c:289
289 error = (*devsw(dev)-d_write) (dev, uio, ap-a_ioflag);
(kgdb) p *dev
$2 = {si_flags = 0, si_atime = {tv_sec = 998903778, tv_nsec = 2619315}, si_ctime =
{tv_sec = 998903780, tv_nsec = 22640918},
si_mtime = {tv_sec = 998903780, tv_nsec = 22640918}, si_udev = 8448, si_hash =
{le_next = 0xc02bcd38, le_prev = 0xc02bdca4},
si_hlist = {slh_first = 0xc7327c60}, si_children = {lh_first = 0x0}, si_siblings =
{le_next = 0x0, le_prev = 0x0},
si_parent = 0x0, si_snapshots = {tqh_first = 0x0, tqh_last = 0xc1382d3c},
si_copyonwrite = 0, si_inode = 0,
si_name = paudit\000\000\000\000\000\000\000\000\000, si_drv1 = 0x0, si_drv2 =
0x0, si_devsw = 0x0, si_iosize_max = 65536,
si_uid = 0, si_gid = 0, si_mode = 438, __si_u = {__si_tty = {__sit_tty = 0x0},
__si_disk = {__sid_disk = 0x0,
__sid_mountpoint = 0x0, __sid_bsize_phys = 0, __sid_bsize_best = 0}}}
si_devsw is 0 here, which seems to be a problem.
Is this a bug, or can I do something inside my module to prevent this
from happening ?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: problem with unloading device driver
Hello, I have a module which adds new device. It does make_dev() and then simulates mknod() syscall, so that /dev/name is always automatically created. Also I have a daemon which reads from and writes to this device. The daemon opens the device once and then holds it open. When my module unloads, it simulates unlink() and then does detsroy_dev(). I just noticed that when I unload my module, the first write() by daemon to the fd associated with that device causes system to crash. Is there really a reason you do not want to keep a persistent device entry in /dev? Aside from cluttering /dev - this is a problem solved in -current with a working devfs. True, -stable does not really have a devfs - the one that was in the tree was removed, because it was way less functional (and working) than the one in -current; still, why, really, should you be worried about one (or five) more device nodes in /dev? The point is that I do not want user to create device node in /dev manually; it's a production module, and the requirement is to have everything added automatically on load and not to have unconfigured entries when module is not loaded. Do you think it will stop crashing if I keep persistent device nodes in /dev ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: unknown PNP hardware
: I'm running -current as of an hour ago. I've gotten this since I've : been running 4.2-stable, any ideas on how I can find out what it : belongs to? : : unknown: PNP0303 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0401 can't assign resources : unknown: PNP0700 can't assign resources : unknown: PNP0f13 can't assign resources Don't worry about these. Warner Well, is there some good reason of printing those messages by default ? Wouldn't it be better to move this stuff to -v output ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
pam_rootok
Hello, would someone (Mark ?) finally remove this: pam_rootok: pam_sm_authenticate: Refused; not superuser I think it should be sent to the debug output, not a terminal. It's quite annoying ... Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
kill a process in kernel
Hello, what is the most proper and easy way to shutdown given process (not curproc) from kernel module ? Any advices regarding this are appreciated. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
It's kinda late in the process to be complaining about this, but I just noticed this myself... Why not just symlink csh to tcsh then ? vel@bugz:/sys/modules/paudit # ls -l /bin/*csh -r-xr-xr-x 2 root wheel 740996 Aug 23 23:19 /bin/csh -r-xr-xr-x 2 root wheel 740996 Aug 23 23:19 /bin/tcsh Is this really reasonable ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Re: Why is csh tcsh? This can be a bad thing...
On Fri, Aug 24, 2001 at 01:45:48PM +0400, Eugene L. Vorokov wrote: It's kinda late in the process to be complaining about this, but I just noticed this myself... Why not just symlink csh to tcsh then ? Because csh is hardlinked to tcsh instead. Oh well, I missed that. But I think symlink would do just the same, but it would be more obvious for user that csh is now the same thing as tcsh. Is there any situation where symlink would not do the job but hardlink would ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Getting filename from descriptor or vnode struct
Hi hackers,
I'm confronted to a problem when I try to hack getdirentries(2) in a kld
module :
To summarize, getdirentries() filled in a buffer a series of dirent struct,
and the 'd_name' field represents the filename (without the full path). I
must recover the full path because I've on disk a list of files to hide ...
The field 'fd' in getdirentries_args is the file descriptor of the
directory.. and I've discovered that the field 'p_fd' from struct proc is a
filedesc struct which contains a vnode struct representing the current
directory ('fd_cdir').
VOP_GETATTR() doesn't allow me to recover this..
If someone could help me, thanks in advance !
I think the best way would be to also hack open() and close(). You can have
some table where you store fd and full pathname of each opened directory.
You add an entry on open() and remove it on close(). Of course, open()
argument may be a path relative to current directory, so to get full path
you should simulate __getcwd() syscall; you must allocate userland buffer
for it with mmap() and then copyin() it (read my previous posting). Once
you have such table, you can find the path by fd in hacked getdirentries()
and see if you want to hide the file or not ...
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
IP address on bridge
Hello, I'm observing some strange problem when I have an IP address on one card on a bridge machine and want to telnet in. I have 4.2-RELEASE box with two network cards: Realtek 8139 (rl0) and 3Com 3C905B (xl0). rl0 is connected to the world, and xl0 to the intranet switch. FreeBSD handbook says that I'm allowed to assign an IP address to one of the two interfaces. Okay, so I assign the address to xl0. But I'm unable to access it from a machine on xl0 side. arp is found properly, and packets are sent, but somehow bridge machine just ignores those packets (tcpdump shows nothing). If I assign IP address to rl0 rather than xl0, it works for short time, then machine I telnet from says that arp of the bridge is moved to xl0 arp again, and packets get lost. ifconfig rl0 down/up and ping'ing the machine I telnet from (so it gets proper arp) heals, but for the short time again. When I swap network cables on those cards, so that xl0 looks to the world and rl0 to the intranet, then assigning IP address to rl0 works fine, I'm always able to telnet in from intranet side. Is it some bug in the xl0 driver ? Was it already fixed, and would upgrading to -current solve this problem ? Or is it me who misses something ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kernel stack size
In 5-0-KSE there is a single page that contains the stack and the PCB (which is about 660 bytes). We are also looking at adding code to set a hardware watchpoint between the stack and the PCB to catch overruns. Maybe I'm just dumb, but I still don't understand, what is the reason of keeping kernel stack size so small ? I understand there should be no need in huge stack, but why so damn small ? Would someone explain please ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SMBFS and NETSMB?
You can try the following in your kernel config: options NETSMB options NETSMBCRYPTO options LIBMCHAIN options ICONV I think it's options LIBICONV (or do both work ?). Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Doing file operations on syscalls handler
Hello hackers, I'm new on FreeBSD modules programming, and I've a little question... How can I do file operations (like open(), read()..) on a syscall handler of a syscall module ? In fact I've met the problem since my module must open a file which contains some informations for the hacked syscall (in this case, it's getdirentries()).. I've tried to malloc a open_args struct, filled-it and use [sys] open, but it doesn't work... Is there a way to call user syscalls ? Thanks you for your answer.. I don't have many informations on FreeBSD modules programming.. forgive-me ;) I think I should put this onto some webpage or something, as I had to post this several times already :). Guys, please please please search mailing list archives prior to asking. In most cases, when you need to read files from kernel modules, it means that you should rethink your problem and the way you go to solve it. I don't have much information about what you're trying to do, but according to what you say, you can pretty well have some userland program which will read the file and pass the information to your module (for instance, your module can create a device and your userland program can open() it and write() to it, or you can add new syscall, or whatever). This is how for instance ipfw and ipf work, modules theirselves don't read configuration files. Think about speed, too: imagine your system getting numerous getdirentries() syscalls in a short time - reading from the file each time would slow down your system a lot. However, there are some cases when you still need to read from a file from your module. For istance, I have a module which must read it's config file on startup itself, because it contains information about which programs are allowed to use it's device i/o interface later. In most circumstances it can be done, however I think it will not work when you are in the interrupt handler or other state where disk i/o isn't surely possible. If you intercept getdirentries(), I think it will pretty well work, but I can only say that my method works for me in MOD_LOAD event handler. Basicly, the problem is that all syscalls expect their arguments to be pointers to the userland memory and not kernel. As you probably know, these are totally separated. All syscalls use copyin() to copy arguments from userland, and this function makes sure that argument is located in userland, and returns error if it isn't. This is done like that to avoid userland programs passing kernel addresses to syscalls and thus manipulating kernel structures in a manner they never should. Thus, if you want to use syscalls from kernel, you must put arguments in the userland memory of current process and then pass them to the syscall handler. The least dangerous method of getting some piece of userland memory (as seems to me) is using mmap() (or, preferably, vm_mmap() directly) with fd == -1 and MAP_ANON flag. mmap() doesn't require anything to be in userland, you can build your own mmap_args as needed and call mmap(), passing curproc as the first argument. Don't forget that mmap() will only return error code; actuall address of memory allocated, if call was successful, is in the curproc-p_retval[0], which you should rather save before you do syscall and restore later. Once you have buffer allocated, you can copyout() your filename to it and pass that address to open() syscall, then allocate another buffer the same way, call read() on it, then use copyin() to transfer the buffer to kernel space. Do note that you must never use memory allocated by mmap() in the regular manner (C operations, string functions, etc); it may work, and will most probably work currently on i386 machines; but don't be fooled as I was at first, it's not supposed to work, because in general case kernelspace and userspace can have totally different address spaces, and access from one to another would require context switching. You can only use copyin(), copyout(), fubyte(), subyte() and other functions from that family; read manual pages. Of course, don't forget to call close() and munmap() once you're done. Do not try using processes other than curproc for mmap() allocation - it will not work. Avoid defining buffers in kernel as local variables of some functions - kernel stack is very small, and you will most likely end up with a double fault panic; use MALLOC() instead. And, as I always did before, I'll add that all this technology looks like a very ugly hack for me, it's really not a good example of what kernel module should do. Still it works for me. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
PFIL_HOOKS
Hello, why isn't PFIL_HOOKS kernel compile option listed in NOTES ? If it just was forgotten, please add it. One trying to compile in ipfilter will get confused I think. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[PATCH] pam_wheel fix
Hello, can anyone please commit this fix to pam_wheel authentication module. It fixed two problem I mentioned in my previous mail (currently for any non-root user PAM_IGNORE is returned, and in case of auth_as_self and debug options used together it logs strange things instead of username). The patch must be applied in src/lib/libpam/modules/pam_wheel/ Regards, Eugene --- pam_wheel_old.c Tue Aug 7 17:46:20 2001 +++ pam_wheel.c Tue Aug 7 17:48:04 2001 @@ -84,11 +84,14 @@ PAM_RETURN(retval); pwd = getpwnam(user); } + + if (!pwd) + PAM_RETURN(PAM_IGNORE); - PAM_LOG(Got user: %s, user); + PAM_LOG(Got user: %s, pwd-pw_name); /* Ignore if already uid 0 */ - if (pwd-pw_uid) + if (!pwd-pw_uid) PAM_RETURN(PAM_IGNORE); PAM_LOG(Not superuser);
libmp
Hello, I cvsup'ed 5.0-CURRENT yesterday, successfully compiled the kernel and tried to compile the rest. However, when doing make in the lib directory, it stops on libmp. The problem is that libmp uses include files from openssl/, and they are not present in my system, as I can see they don't come with freebsd. Of course I know how to install libssl, but is there any sense in using files that don't exist, so that user must install some third-party software to compile *distribution* component ? Or did my cvsup messed something up or am I missing something ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
pam_ssh
Hello, while trying to compile -current, I discovered some possible bug: when compiling libpam, it stops on libpam/modules/pam_ssh/pam_ssh.c, giving bunch of errors. The problem is that including security/pam_mod_misc.h seems wrong, it doesn't find it there. When I changed it to simple pam_mod_misc.h, everything compiled fine. Other modules refer to pam_mod_misc.h too, only pam_ssh.c for some strange reason refers to security/pam_mod_misc.h. If this really is a bug, would be good if someone would care ... Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libmp
Er... the OpenSSL sources *are* shipped with FreeBSD. Or at least they should be, if your CVSup is doing the right thing. Are you cvsup'ping the src-all collection, or the subcollections? There is no longer any need to *not* cvsup src-all, no matter if you are in an export-controlled environment or not - all the export restrictions on code included with FreeBSD have either expired, or (ISTR) been waived specifically for the FreeBSD distribution. So.. cvsup again, using the src-all collection, and see if you grab the src/crypto/openssl/ and src/secure/lib/openssl/ bits. Also, make sure that NOSECURE is NOT turned on in your make.conf. Hope that helps.. Hmm yes, it's there. But the snapshot I installed first doesn't have it (why ?). When I installed it manually prior to compiling libs, libmp compiles fine ... Btw, is there any guide of what is the proper order of compiling things after cvsup ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libmp
Hmm yes, it's there. But the snapshot I installed first doesn't have it (why ?). When I installed it manually prior to compiling libs, libmp compiles fine ... Btw, is there any guide of what is the proper order of compiling things after cvsup ? Yep, the src/UPDATING file. What do you mean, the snapshot did not have it? Did you really CVSup 5.0-current on a machine running an earlier version, or did you install from a pre-built 5.0-current snapshot? Or are you referring to the CVSup snapshot - in what sense did it not have it - there was no src/crypto/openssl/ directory, or there was no src/secure/lib/libcrypto/ directory, or the libcrypto Makefile did not install the OpenSSL header files files under /usr/obj/.../src/i386/usr/include/openssl? How exactly are you trying to compile things? What did you do after the CVSup run? And.. what version are you updating from? I first installed the snapshot 5.0-20010618-CURRENT. Then I installed cvsup and cvsup'ed src-all collection. When it was completed, I tried to recompile the kernel, but config was complaining that it's version doesn't match the kernel version, so I compiled and installed src/usr.sbin/config, then I configured and compiled kernel, it compiled fine. Then I rebooted and tried to compile the userland things. I was thinking that I must first install new include files, then compile and install libs and then executables. So I did make and make install in the src/include directory and tried to do the same in the src/lib, but it stopped on libmp. At that point I had no /usr/include/openssl directory at all, and no libs either. Then I tried to compile src/secure/lib, but make there couldn't be completed too, because libcypher, which is compiled first, also was complaining about openssl library. I tried to compile src/secure/lib/libssl, it compiled successfully, but still it did not properly install all nesessary include files to /usr/include/openssl (only a few were installed), so I had to manually copy src/secure/lib/libssl/openssl/* to /usr/include/openssl/, after which I was able to compile the rest in src/secure/lib, the rest in src/secure and then, finally, src/lib. I think the reason that my initial installation didn't have openssl could be that I just forgot to toggle the appropriate flag in the sysinstall, but still, IMHO this shouldn't make update process that tricky. Generally, I think Makefiles could be constructed to reflect those dependencies, no ? And, why make install in the src/secure/lib/openssl only does this (first line wrapped so that mailer won't be confused with too long line): vel@bugz:/usr/src/secure/lib/libssl # make install install -c -o root -g wheel -m 444 /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/ssl.h /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/ssl2.h /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/ssl23.h /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/ssl3.h /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/ssl_locl.h /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/../ssl/tls1.h /usr/include/openssl install -c -o root -g wheel -m 444 libssl.a /usr/lib install -c -o root -g wheel -m 444 libssl_p.a /usr/lib install -c -s -o root -g wheel -m 444 libssl.so.2 /usr/lib There a lot of other include files it should copy ... Or must I compile something else too before I can simply type make in the src/secure/lib which will work ? And if so, then again, why isn't Makefile there written to compile things in a proper order ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
pam_wheel
Hello,
pam_wheel authentication module seems to be broken in -current. Look at
this (from src/lib/libpam/modules/pam_wheel):
PAM_EXTERN int
pam_sm_authenticate(pam_handle_t * pamh, int flags, int argc, const char **argv)
{
struct options options;
struct passwd *pwd;
struct group *grp;
int retval;
const char *user;
char *use_group;
pam_std_option(options, other_options, argc, argv);
PAM_LOG(Options processed);
if (pam_test_option(options, PAM_OPT_AUTH_AS_SELF, NULL))
pwd = getpwnam(getlogin());
else {
retval = pam_get_user(pamh, user, NULL);
if (retval != PAM_SUCCESS)
PAM_RETURN(retval);
pwd = getpwnam(user);
}
PAM_LOG(Got user: %s, user);
/* Ignore if already uid 0 */
if (pwd-pw_uid)
PAM_RETURN(PAM_IGNORE);
PAM_LOG(Not superuser);
This piece obviously has at least two errors. First, if PAM_OPT_AUTH_AS_SELF
is true, then value of user is undefined. It should probably log
pwd-pw_name instead. Second, check for root must of course be reversed
and become if (!pwd-pw_uid).
The way it works now, it always returns PAM_IGNORE for all non-root users,
which causes in allowing su for anyone who knows root password.
Or am I missing something again ? 8=)
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: crash report
In message [EMAIL PROTECTED], Eugene L. Vorokov wr ites: fault virtual address = 0x60c0ff00 I missed the beginning of this thread, but this looks like a problem that was fixed just before 4.3-RELEASE. What version of FreeBSD are you running? It's 4.2-RELEASE. But I had similar problems with 4.3 I think, it was crashing even more frequently (maybe for another reason, I don't know, but panic messages looked the same), that's why I downgraded to 4.2. If that was fixed in 4.3, is there any chance to get the patch that would fix it for 4.2 ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: crash dump output
Can you compile a debug kernel please and repeat this? That way you will have debug symbols so that you can get more useful information out of gdb. You'll have to get a new crashdump with the debug kernel running however. Maybe it's offtopic a bit, but can you please give exact instructions of how to compile debug kernel ? My machine crashes sometimes too, I tried to compile debug kernel, but it seemed not so easy and I gave up due to lack of time. Or is there any URL with a good explanation ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: crash dump output
Maybe it's offtopic a bit, but can you please give exact instructions of how to compile debug kernel ? My machine crashes sometimes too, I tried to compile debug kernel, but it seemed not so easy and I gave up due to lack of time. Or is there any URL with a good explanation ? you just call config with '-g' option. and compile the kernel in normal way. The freebsd handbook discusses this in more detail. Hmm. It seems like I need spare swap device for crashdump ? What can I do if I have no room on disk for this ? Can normal swap device be used, and if yes, how to save core on panic ? I think swap device contents will be lost on the next reboot ... Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: crash dump output
you just call config with '-g' option. and compile the kernel in normal way. The freebsd handbook discusses this in more detail. Yet another issue, I have run config -g, then make depend, make and make install.debug. But my /kernel is still about 2mb long, which probably means it's not really debug kernel. However I see kernel.debug in the compile directory which is about 8mb long. Should I copy it manually to the / and boot this one ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
crash report
Hello,
here's my crash dump, something related to mbufs. If more information is
needed, tell me what to do, I'll provide it. This usually happens (but not
always) when someone is downloading something huge from ftp server on this
machine.
Regards,
Eugene
vel@bugz:/home/vel # uname -r
4.2-RELEASE
vel@bugz:/home/vel # gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd.
(kgdb) symbol-file /kernel.debug
Reading symbols from /kernel.debug...done.
(kgdb) exec-file /kernel
(kgdb) core-file /var/crash/vmcore.0
IdlePTD 3186688
initial pcb at 291a40
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x60c0ff00
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc015b230
stack pointer = 0x10:0xc0271908
frame pointer = 0x10:0xc0271924
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 = Idle
interrupt mask = net tty
panic: from debugger
panic: from debugger
Uptime: 3h11m4s
dumping to dev #ad/0x20001, offset 131072
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36
35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:469
469 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc014038b in boot (howto=260) at ../../kern/kern_shutdown.c:309
#2 0xc0140721 in panic (fmt=0xc02477d4 from debugger) at
../../kern/kern_shutdown.c:556
#3 0xc011d879 in db_panic (addr=-1072319952, have_addr=0, count=1, modif=0xc0271774
) at ../../ddb/db_command.c:433
#4 0xc011d819 in db_command (last_cmdp=0xc0272b38, cmd_table=0xc0272998,
aux_cmd_tablep=0xc028df30) at ../../ddb/db_command.c:333
#5 0xc011d8de in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc011f9eb in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#7 0xc022643a in kdb_trap (type=12, code=0, regs=0xc02718c8) at
../../i386/i386/db_interface.c:158
#8 0xc0234d0c in trap_fatal (frame=0xc02718c8, eva=1623260928) at
../../i386/i386/trap.c:946
#9 0xc02349e5 in trap_pfault (frame=0xc02718c8, usermode=0, eva=1623260928) at
../../i386/i386/trap.c:844
#10 0xc0234587 in trap (frame={tf_fs = -970522608, tf_es = -1061421040, tf_ds =
-970522608, tf_edi = -1067662336,
tf_esi = 6423552, tf_ebp = -1071179484, tf_isp = -1071179532, tf_ebx = 1, tf_edx
= 1623260928, tf_ecx = 949,
tf_eax = 6423552, tf_trapno = 12, tf_err = 0, tf_eip = -1072319952, tf_cs = 8,
tf_eflags = 66054, tf_esp = -970499232,
tf_ss = -971330368}) at ../../i386/i386/trap.c:443
#11 0xc015b230 in m_copym (m=0xc0627000, off0=7693, len=150, wait=1) at
../../kern/uipc_mbuf.c:621
#12 0xc019a521 in tcp_output (tp=0xc6275b60) at ../../netinet/tcp_output.c:590
#13 0xc0199719 in tcp_input (m=0xc059f100, off0=20, proto=6) at
../../netinet/tcp_input.c:2220
#14 0xc0194717 in ip_input (m=0xc059f100) at ../../netinet/ip_input.c:731
#15 0xc0194777 in ipintr () at ../../netinet/ip_input.c:759
#16 0xc02281e5 in swi_net_next ()
(kgdb) frame 11
#11 0xc015b230 in m_copym (m=0xc0627000, off0=7693, len=150, wait=1) at
../../kern/uipc_mbuf.c:621
621 n-m_pkthdr.len -= off0;
(kgdb) p n-m_pkthdr.len
There is no member named m_pkthdr.
(kgdb) p n
$1 = (struct mbuf *) 0x67063a
(kgdb) p off0
$2 = 7693
(kgdb) up
#12 0xc019a521 in tcp_output (tp=0xc6275b60) at ../../netinet/tcp_output.c:590
590 m-m_next = m_copy(so-so_snd.sb_mb, off, (int) len);
(kgdb) p so-so_snd.sb_mb
$3 = (struct mbuf *) 0xc0623c00
(kgdb) p off
$4 = 7693
(kgdb) p len
$5 = 1099
(kgdb) up
#13 0xc0199719 in tcp_input (m=0xc059f100, off0=20, proto=6) at
../../netinet/tcp_input.c:2220
2220(void) tcp_output(tp);
(kgdb) p tp
$6 = (struct tcpcb *) 0xc6275b60
(kgdb)
Re: ARP cache problems....
Things seem to work fine now, but I still get a lot of those:
Jul 26 00:43:48 test256m /kernel: arp: 192.168.1.4 is on sis0 but got
reply from 00:a0:cc:a0:d4:07 on sis1
Anybody know how to turn them off ?
Yes, I have this problem too. We use several interfaces with totally
different addresses connected to the same hub for testing purposes,
on a testing stand. It's more cheap than bulding truly different
networks. I think it isn't possible to just turn those log messages
off without kernel hacking, which is sad. Probably some sysctl var
would be good ...
Currently, the solution is to take /sys/netinet/if_ether.c, find this:
#ifndef BRIDGE /* the following is not an error when doing bridging */
if (rt-rt_ifp != ac-ac_if) {
log(LOG_ERR, arp: %s is on %s%d but got reply from %6D on
%s%d\n,
inet_ntoa(isaddr),
rt-rt_ifp-if_name, rt-rt_ifp-if_unit,
ea-arp_sha, :,
ac-ac_if.if_name, ac-ac_if.if_unit);
goto reply;
}
#endif
and just hack off this message.
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
Anybody know how to turn them off ? sysctl net.link.ether.inet.log_arp_wrong_iface ? vel@bugz:/home/vel # sysctl net.link.ether.inet.log_arp_wrong_iface sysctl: unknown oid 'net.link.ether.inet.log_arp_wrong_iface' Huh ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: calling kernel functions
Thank you very much for the help so far the functions open() and write() expect there arguments to be in user space and not kernel space, which is what I was doing wrong. My question is, how then would you go about opening and editing a file from the kernel? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message I think I've been posting this about 2 times already. Please search mailing list archive prior to asking next time. First of all, you rarely need to work with files directly in kernel. Do not do this just because it's cool to use kernel module for the tasks which can be done better with a user process. However, there are cases when it's really needed. If you aren't going to do it from interrupt routines or things like that, it's not that hard. The way I do it for myself is taking current process and simulating that this process is doing the syscall, and then stealing results. Note that this only works if the process has permission to read the file you need. It's not always safe; I think it wouldn't work if you try to do file i/o from a routine which is added to packet filtering chain or things like that. At least, I think it's safe to use this method when you're in MOD_LOAD or MOD_UNLOAD state, or when you add a syscall and some user program called it (but can't it read the file itself then and just pass a pointer to a buffer to your module ?) You can allocate userspace memory in the current process' address space using mmap() syscall with fd == -1 and MAP_ANON flag. curpoc variable (of type struct proc *) points to the current process, and you must pass it to mmap(). Do note that it returns error code only; actuall address of allocated memory (if call is successful) is located in the curproc-p_retval[0], which you should rather save before doing the syscall and restore later. Also note that you can't access such a memory with usual C operators, because in general case kernel and user process may have separate address spaces; you must rather use fubyte(), subyte(), copyin(), copyout() routines; try reading the manual about them. When you have some piece of userspace memory, you can copy filename into it (not directly, as mentioned above), and pass it to open() syscall. The same way you can use read(), write(), etc., passing allocated userspace buffers to them, and once call is completed, you can fetch the result from your buffer. Of course, don't forget close() and munmap() when you're done. And remember, it all is not really a proper way, but a very ugly hack. Still, in conditions I described it works. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: using syscalls in a module (stack problem ?)
I call this function with (curproc, PATH_MAX+1), and everything is fine when I have just a few local variables defined in the caller (it all works on MOD_LOAD only). However, if I have 2 buffers, 4096 bytes each, as local variables and then try to allocate userspace memory the same way, kernel crashes - sometimes inside mmap(), sometimes a bit later. Why could this happen ? Is it related to possible stack overflow ? Yes. The kernel stack is only two pages; you absolutely must not use large local variables in the kernel. I see. But I still can define them using static, right ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
using syscalls in a module (stack problem ?)
Hello,
using my ugly hack to do file i/o from a module, I discovered some
problem calling mmap() from a function with a lot of local buffers
defined. I have:
char * pizda_malloc(struct proc *p, int size)
{
struct mmap_args mem; int res; register_t save; char *buf;
save = p-p_retval[0];
mem.addr = NULL;
mem.len = size;
mem.prot = PROT_READ | PROT_WRITE;
mem.flags = MAP_ANON;
mem.fd = -1;
mem.pad = 0;
mem.pos = 0;
res = mmap(p, mem);
if (res)
{
p-p_retval[0] = save;
return NULL;
}
buf = (char *)p-p_retval[0];
p-p_retval[0] = save;
subyte(buf, 0);
return buf;
}
I call this function with (curproc, PATH_MAX+1), and everything is fine
when I have just a few local variables defined in the caller (it all
works on MOD_LOAD only). However, if I have 2 buffers, 4096 bytes each,
as local variables and then try to allocate userspace memory the same
way, kernel crashes - sometimes inside mmap(), sometimes a bit later.
Why could this happen ? Is it related to possible stack overflow ?
(Yes, I know I can use MALLOC instead of static buffers, but I love
to understand what happens ...)
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: KLD Programming
Yes. But it is not easy. Look at code vfs_vnops.c. You can let a user process open a file and then push the file descriptor into kernel via a special system call. Search the mailing list archive and you will find discussions on how to add a new system call. Well, if you aren't going to do intensive file i/o, this is possible (especially on MOD_LOAD) with a very ugly, but working hack: you can simulate that current process is doing the i/o. Take curproc, allocate some memory in it's address space using mmap() (or, preferably, vm_mmap()) with MAP_ANON flag for i/o buffer and then call open(), read(), etc, passing curproc and allocated buffer to them. Do note, however, that you generally can't access the buffer directly with C operators; you should rather use copyin()/copyout(), fubyte()/subyte() functions (see the manual page for them for details). Of course this is no brilliant solution, I'm currently looking for a better one, but this works for me so far for reading a config file on load. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
KLD parameters
Hello, it seems that I can't pass any parameters to a KLD module when I load it (i.e., some command line). Am I missing something, or if not, why is it like that, on purpose or just no one was willing to implement that ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
disabling reboot on kernel panic
Hello, maybe it's a bit offtopic, but still: how can I disable reboot on kernel panic in 15 seconds, so that it just hangs and I'm able to see what happened when I come ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DDB mp3's
diman wrote: Hi, folks. When I switch to DDB to check something or debug something usefull, mp3 player process (mpg123) hangs up and dissonate me. So guys how do you do in such a case? I'm shure that I'm not one having such a problem. ;-) Maybe someone has allready ported mp3's player to kernel, or even built it in DDB? What would be your suggestion? You are kidding, right? You do actually know how DDB works? I think you can overcome this by running FreeBSD you're debugging on vmware virtual machine (that is, just FreeBSD on FreeBSD under vmware). Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Some questions about kernel programming
Forgot to Cc: here: You can't call kernel strlen on a userland address, you must do something like this: How so ? It seems to work for me. For instance, I used userland address space buffer to simulate __getcwd() syscall on the current process (I was hacking open() syscall and log full path of the file to the syslog). I simulate mmap() with MAP_ANON and fd == -1 on that process, then I do __getcwd() to the buffer allocated, and then I'm very well able to call strlen() on that userland buffer, as well as other str* functions. So generally I think it works. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Some questions about kernel programming
/*
* return number of characters in a userland address string
* or -1 if an illegal access occurs.
*/
int
user_strlen(uaddr)
char *uaddr;
{
int ret;
ret = -1;
do {
ch = fubyte(uaddr);
ret++;
} while (ch != 0 ch != -1);
return (ch == -1 ? -1 : ret);
}
Then I don't get it. Won't this piece of code cycle forever fetching
first byte of the string again and again ? According to fetch(9)
fubyte() doesn't change uaddr, or am I missing something again ?
Am I allowed to do uaddr++ for userspace addresses in such a case ?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Some questions about kernel programming
ch = fubyte(uaddr); And one more question, does this mean that I can't use things x = *uaddr and *uaddr = x for userspace, but always have to use fubyte() and subyte () ? If so, what is the reason it was done like that ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
panic when returning error on MOD_LOAD
Hello, I'm pretty confused with the fact that kernel panics when my module's event handler returns something greater than zero on MOD_LOAD. I wanted module to refuse to load when it can't find it's config file, so I thought I can return error code and it will not be loaded, and behaviour of module_register_init() and other related functions after quick look seems to be intended to do just that. That look very ugly ... what could I do wrong ? What is the proper way of doing what I wanted ? And oh yes, it's 4.2 system. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: LIST_NEXT()
Hello,
I'm writing a kernel module, and it involves traversing the proc list searching for
the right structure,
however, when I use SLIST_NEXT(p, p_list) in the program, I get a warning when I
compile it:
warning: statement with mo effect
What am I doing wrong? I've read the manpages on queue and looked at the proc
structure.
Here's the code:
int
prfw_setflags(p, uap)
struct proc *p;
struct prfw_setflags_args *uap;
{
...
if (uap-id) {
while (uap-id != p-p_pid)
LIST_NEXT(p, p_list);
}
...
}
The proper way would be:
p = LIST_NEXT(p, p_list);
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: kernel panic when trying to use init's address space
On Thu, Jul 05, 2001 at 02:59:17PM +0200, Bernd Walter wrote: You are mmaping into the address space for the process you use the struct proc from. As long as it's this programm that is curproc everything is fine. Okay, I understand what the problem is. But what if I still want to simulate the syscall from the process which is not current ? Is it difficult to make kernel think that it's current process, how should it be done ? (Yes, I know this may look dumb, but still) Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
kernel panic when trying to use init's address space
Hello,
Some time ago I was asking about I/O in kernel mode when I don't have
struct proc to use syscalls. Actually I just wanted my kld to read it's
config file on load. Terry told me it's tricky, and I was thinking
about possible workarounds. I decided to try the following: look for
some process, get it's struct proc, allocate memory in it's address
space using mmap() syscall and then use open() and read() syscalls,
passing that struct proc to them. I first decided to look for init
process for this, since it always exists. So it looked like that:
struct proc *p; register_t save; char *buf;
struct mmap_args mem; int res;
for (p = allproc.lh_first;
p (strcmp(p-p_comm, init));
p = p-p_list.le_next);
if (!p)
return -1;
save = p-p_retval[0];
mem.addr = NULL;
mem.len = size;
mem.prot = PROT_READ | PROT_WRITE;
mem.flags = MAP_ANON;
mem.fd = -1;
mem.pad = 0;
mem.pos = 0;
res = mmap(p, mem);
if (res)
{
p-p_retval[0] = save;
return -1;
}
buf = (char *)p-p_retval[0];
p-p_retval[0] = save;
*buf = 0;
However at this point kernel panics with page fault. I really don't
understand why could it be ...
Of course, I've found another workaround. I recalled that kldload
program is still active when my module loads, so I started looking
for it instead of init. It works just fine, I'm able to allocate
memory, use it and finally read my config file. But I'm curious,
why doesn't it work with init ? What's so special in init from this
point of view ?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: TCP Problems in 4.3 ?
I use LPRng 3.6.20 and openssh on the 4.3 box, lpd-server is on a 4.1 box. Issuing 4-5 lpq's in a minute gives Connection timed out. First i thought it may be a problem with LPRng, but scp'ing large files doesnt work anymore, too. Even ssh hangs sometimes. I tried to disable the newreno stuff with sysctl, didnt change anything. Why i suspect a tcp problem? I had similar problems with 4.3, my ssh and telnet sessions were giving timeouts when they were inactive for about 2 hours (ofcourse this was not an autologout or something). The problem was fixed when I downgraded (for another reason) to 4.2. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
catching ip packets from module
Hello, can please someone enlighten me how can a module catch ip packets before they actually enter the stack, the way ipfw or ipf does ? I tried to look at the sources, but ipfw seems to do it some very specific way which is based on some in-kernel hacks to make it possible (ofcourse correct me if I'm wrong), and ipf does so many things at startup so I can't figure out which function does what :( I just want to add my handler so that all packets would be passed to it before entering the kernel ... Thanks for the information. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCP Problems in 4.3 ?
On Mon, Jul 02, 2001 at 03:53:53PM +0400, Eugene L. Vorokov wrote: I use LPRng 3.6.20 and openssh on the 4.3 box, lpd-server is on a 4.1 box. Issuing 4-5 lpq's in a minute gives Connection timed out. First i thought it may be a problem with LPRng, but scp'ing large files doesnt work anymore, too. Even ssh hangs sometimes. I tried to disable the newreno stuff with sysctl, didnt change anything. Why i suspect a tcp problem? I had similar problems with 4.3, my ssh and telnet sessions were giving timeouts when they were inactive for about 2 hours (ofcourse this was not an autologout or something). The problem was fixed when I downgraded (for another reason) to 4.2. Sure there isn't something in between which does a timeout after 2h? (default value for checkpoint firewall-1). I had the same problem and it was the fw-1. (Yes, I have set keepalive to on) No, there was only a FreeBSD 4.2 with options BRIDGE in between. And anyway, if firewall would be a problem, why this problem doesn't appear with 4.2 ... Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
allocating user space memory from kernel mode
Hello, is it possible to allocate and then maybe free memory in user space from kernel mode, if I have struct proc of the process that memory should belong to ? What is the easiest and safest method of doing this ? I have seen some example that uses obreak(), but that seems very tricky and suspicious ... I don't really understand what obreak() really does and how to use it ... Thanks for the information. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
accessing files from kld module
Hi, probably this question was asked here many times before, but I'm new to kernel mode hacks ... Is it somehow possible to access files from my kld module ? I have seen functions like printf(), MALLOC() for kernel mode, but nothing like open() ... using open() syscall directly seems impossible too because generally I don't have struct proc entry. I would be very thankful for any information regarding this issue. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
