Re: unionfs and getcwd problem.
On Mon, 2002-03-25 at 18:28, BOUWSMA Beery wrote: The only obvious `problem' is when a non-r00t user attempts to access the union-mounted fs when the shadow directories have not yet been created, and `permission denied' is returned for all directories that exist below, but not in the unionfs fs. E.g.: Yes, it is because of feature of unionfs to create shadow directories with credentionals of proceses doing rise operation. And if process have no permissions to write into parent directory operation fail. I have thought about what is best to do in a case like this. At first, I was thinking that if a directory like this does not presently exist in the upper (unionfs) layer, then for the case of a read-only operation like `ls', simply fall through to display what is present in the lower layer. This, if it is possible (I have no idea; I'm no hacker), would avoid the ``hey, why can't I do a simple `ls'?!?'' type of question. May be you will be interested in -o union flag to any standart mount It works a bit different from special union FS. thanks, barry bouwsma -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
back trace of vm_object_reference bug
# 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.0
(kgdb) core-file vmcore.0
IdlePTD at phsyical address 0x004b1000
initial pcb at physical address 0x003f5ec0
panicstr: privileged instruction fault
panic messages:
---
Fatal trap 1: privileged instruction fault while in kernel mode
instruction pointer = 0x8:0xc6425c44
stack pointer = 0x10:0xc6425c30
frame pointer = 0x10:0xc6425c2c
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 = 113 (cp)
interrupt mask = none
trap number = 1
panic: privileged instruction fault
syncing disks... 112 105 102 101 101 101 100 100 100 100 100 100 100 100 100 100 100
100 100 100 100 100 100 100 100 100
giving up on 99 buffers
Uptime: 48s
dumping to dev #ad/0x20019, offset 100272
dump ata1: resetting devices .. done
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
---
#0 dumpsys () at ../../kern/kern_shutdown.c:474
474 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:474
#1 0xc01c1def in boot (howto=256) at ../../kern/kern_shutdown.c:313
#2 0xc01c21d0 in poweroff_wait (junk=0xc03a662c, howto=-1069915709)
at ../../kern/kern_shutdown.c:582
#3 0xc0339d02 in trap_fatal (frame=0xc6425bf0, eva=0)
at ../../i386/i386/trap.c:956
#4 0xc03396df in trap (frame={tf_fs = 671416336, tf_es = 393232,
tf_ds = -968753136, tf_edi = -968692448, tf_esi = -979969472,
tf_ebp = -968729556, tf_isp = -968729572, tf_ebx = 0,
tf_edx = -968740864, tf_ecx = 0, tf_eax = 14, tf_trapno = 1, tf_err = 0,
tf_eip = -968729532, tf_cs = 8, tf_eflags = 66194, tf_esp = -1070728004,
tf_ss = 0}) at ../../i386/i386/trap.c:618
#5 0xc6425c44 in ?? ()
#6 0xc02dfcbc in vm_object_reference (object=
Cannot access memory at address 0x1029a.
) at ../../vm/vm_object.c:256
Cannot access memory at address 0x10292.
(kgdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: kernel panic: vm_object_reference
On Wed, Mar 27, 2002 at 08:28:50AM +, Ceri wrote: Forcibly unmounting a file system that is in use will panic your system. It's not exactly a bug, it's just how it works. :) I don't agree. I know this is a little foolproof programming but I should return something like busy FS How would that be different from not forcing it ? That (or something similar) should be returned to the process accessing the unmounted fs, not the umount itself. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ports/36307: nmh port cuts off last part of sender domain
Scott Blachowicz [EMAIL PROTECTED] writes:
(freebsd-hackers, please see comment about sys/utsname.h / SYS_NMLN
below; you might ignore the nmh bug correspondence above.)
OK...it looks like there's this zotnet/mts/mts.c file with a LocalName()
function that calls various functions (uname(), gethostbyname(), ...) to get
the canonical hostname for a system. I've put some debug tracing in my copy
to figure out which calls are returning what. Also, I put some code in the
mts/smtp/smtp.c to dump everything written to the SMTP socket into a /tmp/
file. Those files should be attached to this message.
So, after building with this stuff, you do
env DEBUG_SMTP=1 comp
to send something. I just did that here and got this:
Heh, I've found the bug. Your debugging code put me on the correct
trail. nmh now spits out:
What now? s
LocalName() - got from uname(): reiher.informatik.uni-wuerzburg
LocalName() - returning: reiher.informatik.uni-wuerzburg
LocalName() - got from uname(): reiher.informatik.uni-wuerzburg
LocalName() - returning: reiher.informatik.uni-wuerzburg
smtp.c[138]: calling LocalName()
which made me look up uname(3) and write a little test program:
#include sys/utsname.h
#include stdio.h
int main()
{
struct utsname u;
if (-1 == (uname(u))) {
perror(uname failed);
return 1;
}
printf(sysname: %s\nnodename: %s\nrelease: %s\nmachine: %s\n,
u.sysname, u.nodename, u.release, u.version, u.machine);
return 0;
}
which prints:
$ ./a.out
sysname: FreeBSD
nodename: reiher.informatik.uni-wuerzburg
release: 4.5-STABLE
machine: FreeBSD 4.5-STABLE #0: Fri Mar
Note that not only the nodename is truncated but the machine
entry also. Which made me look into sys/utsname.h, suspecting
a small constant width for these struct entries, which actually
turns out to be the case:
#define SYS_NMLN32
...
charnodename[SYS_NMLN]; /* Name of this network node. */
...
Thus, if nmh calls uname(3) to get the name, everything longer than
31 characters is truncated.
This is both a problem in nmh aswell as FreeBSD; nmh shouldn't rely
on uname(3) for getting a full Internet hostname as nodename;
FreeBSD should raise SYS_NMLN to provide enough place for an Internet
hostname. For example, on Solaris 8, it is defined as:
#define _SYS_NMLN 257 /* 4.0 size of utsname elements */
/* Must be at least 257 to */
/* support Internet hostnames. */
On NetBSD (1.5.1) it is:
#define _SYS_NMLN 256
That's also the reason why the problem didn't show up on NetBSD
or Solaris.
My proposal:
Make nmh depend on sth. else than uname(3), and also push up
FreeBSD's SYS_NMLN (if not already done so in -CURRENT, haven't
checked.)
--mkb
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ports/36307: nmh port cuts off last part of sender domain
I wrote: printf(sysname: %s\nnodename: %s\nrelease: %s\nmachine: %s\n, u.sysname, u.nodename, u.release, u.version, u.machine); Actually here's an obvious bug in the quick test program, I just want to mention it, it doesn't effect anything in the rest of the mail, though. :) --mkb To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
problems with wine
Hi, I have a problem running a application with wine (native). Error message: 486 cpu or higher required. I have a amd k7. The linux version catches the cpu-type from /proc/cpuinfo. But Freebsd's /proc is diffrent from linux. So they set the values for cpu type fix ( i386 ). Which isn't a really good idea. From where can I take the cpu info to change this? ( I don't want to take /usr/compat/linux/proc/cpuinfo. ) thanks for your help, Tom To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[PATCH] src/examples/cvsup/README
[BCCed to -stable] Hi all, I was used to stable-supfile used to track -stable and standard-supfile used to track -current. Since april 2001 this is no more the case, and standard-supfile tracks the branch it was originally pulled from. I don't want to go into a bikeshed painting contest, but I have a suggested modification to src/examples/cvsup/README that at least explains to the unawary what has changed. Feel free to edit to taste. thanks Marco --- README.old Wed Mar 27 16:51:02 2002 +++ README Wed Mar 27 17:11:42 2002 -5,6 +5,17 with CVSup version 14.0 or later. For general information on CVSup itself, please see http://www.freebsd.org/handbook/cvsup.html +WARNING: There are two standard-supfile. Keep reading for details. + +Since april 2001, standard-supfile defaults to the branch from which +the file came. So if you pull down RELENG_4 it defaults to RELENG_4, +if you pull down -current it defaults to -current. + +An easy way to get the latest standard-supfile for the branch you are +interested in is to browse the CVS web interface at +http://www.freebsd.org/cgi/cvsweb.cgi/src/share/examples/cvsup/standard-supfile + + To maintain the sources for the FreeBSD-current release, use: standard-supfile Main source tree -14,6 +25,10 To maintain the sources for the FreeBSD-stable release, use: stable-supfile Main source tree + +or + +standard-supfile Main source tree To maintain a copy of the CVS repository containing all versions of FreeBSD, use:
Re: ports/36307: nmh port cuts off last part of sender domain
On Wed, Mar 27, 2002 at 03:44:32PM +0100, Matthias Buelow wrote: ... This is both a problem in nmh aswell as FreeBSD; nmh shouldn't rely on uname(3) for getting a full Internet hostname as nodename; FreeBSD should raise SYS_NMLN to provide enough place for an Internet hostname. ... My proposal: Make nmh depend on sth. else than uname(3), and also push up FreeBSD's SYS_NMLN (if not already done so in -CURRENT, haven't checked.) Well...I'll work on getting the nmh port modified to avoid uname(3). It's already conditionalized on a HAVE_UNAME define, so just turning that define off should take care of it. It looks like it'll use gethostname(3) instead and the calling code passes a BUFSIZ (1024) char buffer in...the gethostname(3) man page warns that it's limited to 256 chars, so that should do the trick, I think. Thanx, -- Scott Blachowicz To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: usb mass storage problems
Thomas Würfl wrote:
I fixed the problem. I added following lines to
/usr/src/sys/cam/scsi/scsi_da.c (FreeBSD-4.5RELEASE):
/* Below a list of quirks for USB devices supported by umass. */
/*
+ * Fujitsu Siemens Memorybird
+ */
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, Fujitsu, Memorybird, *},
+ /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
+ },
Maybe this is written in an unusual manner, but I'm an absolute newbie to
freebsd and C. Sorry
For reference, there's a more generalized approach to supporting these
devices that's been sitting in PR misc/32490
(http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/32490) for a while :-)Lars
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
smime.p7s
Description: S/MIME Cryptographic Signature
Adaptec NIC and Netfinity
Hello I am having some problems with an Adaptec 62044 network card (quad NIC), the first three interfaces initialize but then the last fails. I have compiled in the starfire driver with my kernel using the line: device sf # Adaptec AIC-6915 (``Starfire'') The hardware platform is on a IBM Netfinity 4000R. I have disabled any PnP options in the bios and have also disabled floppy and com ports. I am posting the output from the command dmesg and also the output of vmstat -I. Please CC:[EMAIL PROTECTED] with any info. Thanks, Dave Brancato interrupt total rate ata1 irq15 4 0 mux irq102589 1 mux irq3 1216 0 atkbd0 irq1 2325 1 clk irq0 145260 99 rtc irq8 185939127 Total 337333232 Copyright (c) 1992-2002 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 4.5-RELEASE #0: Mon Mar 25 06:40:31 CST 2002 root@:/usr/src/sys/compile/TAZ Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (645.66-MHz 686-class CPU) Origin = GenuineIntel Id = 0x681 Stepping = 1 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE, MCA,CM OV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 2147483648 (2097152K bytes) avail memory = 2088800256 (2039844K bytes) APIC_IO: MP table broken: 8259-APIC entry missing! Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 16 - irq 11 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 18 - irq 3 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 14, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc02e5000. Preloaded userconfig_script /boot/kernel.conf at 0xc02e509c. Pentium Pro MTRR support enabled md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443GX host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib2: Intel 82443GX (440 GX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib2 pci1: Chips Technologies 69000 SVGA controller at 0.0 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata1: at 0x170 irq 15 on atapci0 pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 Timecounter PIIX frequency 3579545 Hz 3 on pci0 ,0xfebff000-0xfebf irq 3 at device 17.0 on pci0 fxp0: Ethernet address 00:06:29:de:c2:fb inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ,0xfebfe000-0xfebfefff irq 10 at device 18.0 on pci0 fxp1: Ethernet address 00:06:29:de:c2:fa inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib3: DEC 21152 PCI-PCI bridge at device 20.0 on pci0 pci2: PCI bus on pcib3 0fff irq 10 at device 14.0 on pci2 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs pcib4: DEC 21154 PCI-PCI bridge at device 15.0 on pci2 pci3: PCI bus on pcib4 ff irq 11 at device 4.0 on pci3 sf0: Ethernet address: 00:00:d1:ee:08:a1 miibus2: MII bus on sf0 ukphy0: Generic IEEE 802.3u media interface on miibus2 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ff irq 10 at device 5.0 on pci3 sf1: Ethernet address: 00:00:d1:ee:08:a2 miibus3: MII bus on sf1 ukphy1: Generic IEEE 802.3u media interface on miibus3 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ff irq 3 at device 6.0 on pci3 sf2: Ethernet address: 00:00:d1:ee:08:a3 miibus4: MII bus on sf2 ukphy2: Generic IEEE 802.3u media interface on miibus4 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ff at device 7.0 on pci3 pci_cfgintr: can't route an interrupt to 3:7 INTA sf3: couldn't map interrupt device_probe_and_attach: sf3 attach returned 6 pcib1: Intel 82443GX host to AGP bridge on motherboard pci4: PCI bus on pcib1 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 IP Filter: v3.4.20 initialized. Default = pass all, Logging = enabled SMP: AP CPU #1 Launched! acd0: CDROM CRN-8241B at ata1-master using PIO4 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: IBM-PSG ST318275LW!# 0350 Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 17357MB (35548320 512 byte sectors: 255H
Re: problems with wine
Thomas Würfl([EMAIL PROTECTED])@2002.03.27 16:48:40 +: Hi, I have a problem running a application with wine (native). Error message: 486 cpu or higher required. I have a amd k7. The linux version catches the cpu-type from /proc/cpuinfo. But Freebsd's /proc is diffrent from linux. So they set the values for cpu type fix ( i386 ). Which isn't a really good idea. From where can I take the cpu info to change this? ( I don't want to take /usr/compat/linux/proc/cpuinfo. ) ahem, correct me if i'm wrong, but freebsd's /proc filesystem does not have any cpuinfo. if you run a command under the linuxulator, /proc gets mapped to /usr/compat/linux/proc, so the file you don't want to open already provides that info (to wine in this case). i don't know about your environment, but just for testing, how about taking the output of cpuinfo, put it to a text file, edit it the way you need it and generate /usr/compat/linux/proc as a symlink farm to the linuxprocfs with only the cpuinfo replaced by the edited text file. would this do any harm? cpuinfo is read-only AFAIK, so it might work :-) regards, /k -- If you meet somebody who tells you that he loves you more than anybody in the whole wide world, don't trust him. It means he experiments. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 10x msg33121/pgp0.pgp Description: PGP signature
Re: problems with wine
On Wed, 27 Mar 2002, Karsten W. Rohrbach wrote: Thomas Würfl([EMAIL PROTECTED])@2002.03.27 16:48:40 +: Hi, I have a problem running a application with wine (native). Error message: 486 cpu or higher required. I have a amd k7. The linux version catches the cpu-type from /proc/cpuinfo. But Freebsd's /proc is diffrent from linux. So they set the values for cpu type fix ( i386 ). Which isn't a really good idea. From where can I take the cpu info to change this? ( I don't want to take /usr/compat/linux/proc/cpuinfo. ) ahem, correct me if i'm wrong, but freebsd's /proc filesystem does not have any cpuinfo. if you run a command under the linuxulator, /proc gets mapped to /usr/compat/linux/proc, so the file you don't want to open already provides that info (to wine in this case). i don't know about your environment, but just for testing, how about taking the output of cpuinfo, put it to a text file, edit it the way you need it and generate /usr/compat/linux/proc as a symlink farm to the linuxprocfs with only the cpuinfo replaced by the edited text file. would this do any harm? cpuinfo is read-only AFAIK, so it might work :-) He said he was running native.. the cpu type is in `sysctl hw` The code shuold be altered on FreeBSD to look there. regards, /k -- If you meet somebody who tells you that he loves you more than anybody in the whole wide world, don't trust him. It means he experiments. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 10x To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: problems with wine
Julian Elischer([EMAIL PROTECTED])@2002.03.27 11:43:50 +: [...my dumbass workaround deleted...] He said he was running native.. the cpu type is in `sysctl hw` The code shuold be altered on FreeBSD to look there. oops, you're prefectly right. i skipped the (native) when reading the original mail. anyway, wine needs to be patched then, since hw.machine gives the platform which is i386 in case of x86, correct? btw, is this intended behaviour? i thought hw.machine_arch would be for that purpose. hw.machine_arch is set up in kern/kern_mib.c to i386 on pc hardware hw.machine is set up in i386/i386/identcpu.c to i386 anytime (on 4.3-stable, my currently active stable source i have immediate access to) wouldn't it make sense to set the SYSCTL_STRING on hw.machine to a gcc compatible (-mcpu or -march) value? this would make us happier in the future when gcc does not generate broken code in several scenarios anymore. does this make sense? /k -- Her figure described a set of parabolas that could cause cardiac arrest in a yak. --Woody Allen KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 10x msg33123/pgp0.pgp Description: PGP signature
uma and double free detection?
Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: problems with wine
Am Mittwoch, 27. März 2002 21:18 schrieben Sie: Julian Elischer([EMAIL PROTECTED])@2002.03.27 11:43:50 +: [...my dumbass workaround deleted...] He said he was running native.. the cpu type is in `sysctl hw` The code shuold be altered on FreeBSD to look there. oops, you're prefectly right. i skipped the (native) when reading the original mail. anyway, wine needs to be patched then, since hw.machine gives the platform which is i386 in case of x86, correct? btw, is this intended behaviour? i thought hw.machine_arch would be for that purpose. hw.machine_arch is set up in kern/kern_mib.c to i386 on pc hardware hw.machine is set up in i386/i386/identcpu.c to i386 anytime (on 4.3-stable, my currently active stable source i have immediate access to) wouldn't it make sense to set the SYSCTL_STRING on hw.machine to a gcc compatible (-mcpu or -march) value? this would make us happier in the future when gcc does not generate broken code in several scenarios anymore. does this make sense? /k Afaik 'hw.machine' is system architecture (i386=IA32). But in 'sysctl hw' is no _cpu_type_ like in linux-proc/cpuinfo. I'll have a look at the linuxulator source... ;-) Tom To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( THat's an INVARIANTS thing, even without UMA... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
* Terry Lambert [EMAIL PROTECTED] [020327 13:30] wrote: Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( THat's an INVARIANTS thing, even without UMA... /usr/src/sys/i386/conf % grep INVA BRIGHT options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structu All I got was a panic because uma seemed to get confused rather than catch the double free. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
Alfred Perlstein wrote: * Terry Lambert [EMAIL PROTECTED] [020327 13:30] wrote: Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( THat's an INVARIANTS thing, even without UMA... /usr/src/sys/i386/conf % grep INVA BRIGHT options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structu All I got was a panic because uma seemed to get confused rather than catch the double free. I got a similar untraceable panic because the ucred reference counter was overlayed with an invariants structure. Probably invariants is stomping something that is used as a marker into seeming validity. It's very tempting to require that invariants add their own crap to to the front of a structure, and then hide it, so that this is not possible. It was a real pain in the butt to track doewn the cred free problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: freebsd-hackers-digest V5 #429
Chad Kline [EMAIL PROTECTED] wrote:
* Olympus digital cameras (D-370)
*/
{T_DIRECT, SIP_MEDIA_REMOVABLE, OLYMPUS, D-*, *},
/*quirks*/ DA_Q_NO_6_BYTE
usbdevs -v reports:
Controller /dev/usb0:
addr 1: self powered, config 1, OHCI root hub(0x),
OPTi(0x), rev 0x0100 port 1
addr 2: self powered, config 1, C-1 Digital Camera(0x0102),
Olympus(0x07b4), rev 0x1015 port 2 powered
Two comments on the above quirk entry:
1. I'm pretty sure that the string comparisons are case-sensitive.
OLYMPUS does not match Olympus.
2. You appear to have a C-1 (etc.) camera, and so D-* will never match
C-1 Digital Camera. Try C-*, instead.
For USB hard disks, at least (which may also apply to cameras), you also
need to be running a pretty recent version of -STABLE; I'm pretty sure
that 4.5-RELEASE can't be used (which is what you're using). I know
that a -STABLE of around mid-February will *NOT* work (which is what
makes me think that -RELEASE also doesn't work), and one as of March 19
does (but might have problems with the new ATA code).
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
On Wed, 27 Mar 2002, Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( Oh! Thanks for pointing this out. Originally it could, but with the per cpu buckets it lost the ability to until the data was really freed. What I will do is disable per cpu buckets if INVARIANTS is on. The reason for this is that you have to lock the zone and look at the slabs to do double free detection. Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
On Wed, 27 Mar 2002, Alfred Perlstein wrote: * Terry Lambert [EMAIL PROTECTED] [020327 13:30] wrote: Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( THat's an INVARIANTS thing, even without UMA... /usr/src/sys/i386/conf % grep INVA BRIGHT options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structu All I got was a panic because uma seemed to get confused rather than catch the double free. Yikes, a panic? From a double free? Was this from malloc or zalloc? Are you sure there was no other memory corruption? Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: freebsd-hackers-digest V5 #429
1. I'm pretty sure that the string comparisons are case-sensitive. OLYMPUS does not match Olympus. I think he's right here. I have overseen this. For USB hard disks, at least (which may also apply to cameras), you also need to be running a pretty recent version of -STABLE; I'm pretty sure that 4.5-RELEASE can't be used (which is what you're using). I know that a -STABLE of around mid-February will *NOT* work (which is what makes me think that -RELEASE also doesn't work), and one as of March 19 does (but might have problems with the new ATA code). 4.5-RELEASE works also. (at least with me) See also patch from Lars Eggert for avoiding applying quirks for every unknow device: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/32490 Tom To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
Moin, moin!
%s wrote on %.3s, %lld Sep 1993
Anyway, when compiling this Linux program, which has lines
[ ... ]
linking fails...
Don't compile on Linux? 8-) 8-)
BINGO!!! Give that man a cigar. Once again it has been pointed out
to me that my messages are hopelessly unclear. Let me try again:
This program, originally written for Linux, needs a few small hacks
to get it to compile and/or work under FreeBSD. Once one slays the
obvious dragons, leaving the m{un}lockall() calls untouched, any
attempts to compile this program, originally written for Linux,
under FreeBSD (stable, for what it's worth) are doomed to failure
by the following:
[continue with the original ``undefined reference
to `munlockall' '' errors]
Is your code controlling a
nuclear reactor? No? Then it doesn't need the calls. 8-).
Well, no. But it is connected to a (wait, I need to hold the
punchline until it's appropriate)
I don't know the proper test off the top of my head, but I
know who would know, and I know a test that works for
m{un}lockall(), and both of those are better anyway.
Thanks! I'm all ears.
Unfortunately.
The person who would know would be Garrett A. Wollman; his
email is [EMAIL PROTECTED]. He would know because he's
been on the committes, and he's know because he wrote the
shm_open(3) library code... just like it says at the bottom
And best of all, from my occasional views into the Monastery,
he's sufficiently interested in the topic that if I were to
mention that this collection of k0deZ is intended to interface
a radio, erm, I mean blink -- RADIO -- /BLINK clock
timekeeping driver (emphasis on RADIO, that is RADIO), - look!!!
then perhaps it may grab his interest. Or not.^
The test that works for m{un}lockall() requires that you:
[...]
o The mlockall() function takes a flags argument that
is an inclusive OR of one of several manifest
constants.
So basically, if you test for the manifest constants before
making a call that uses them, then you are safe, e.g.:
#ifdef MCL_CURRENT
mlockall( MCL_CURRENT);
#endif
[...]
This should work everywhere, even on Linux, without having to
break down and ask the person who wrote the code from the POSIX
Unfortunately, while I'd love to tell you that it works just all
sorts of groovy and everything, I regret to say that in the
included file sys/mman.h one finds the following lines:
| #ifdef _P1003_1B_VISIBLE
| /*
| * Process memory locking
| */
| #define MCL_CURRENT 0x0001 /* Lock only current memory */
| #define MCL_FUTURE 0x0002 /* Lock all future memory as well */
|
| #endif /* _P1003_1B_VISIBLE */
Comparable to the lines around m{un}lockall() themselves.
And in spite of wrapping the calls in the program in question
with a test for this...
| /* lock all memory pages */
| #ifdef MCL_CURRENT /* is the mlockall() call available? */
| if (mlockall(MCL_CURRENT | MCL_FUTURE) !=0)
| syslog(LOG_INFO, error unable to lock memory pages);
| #else /* no, do without, but make note of it... */
| syslog(LOG_INFO, error unsupported memory pages lock call);
| #endif
again everything falls apart with the failure:
/usr/bin/gcc -s -o radioclkd radioclkd.o
radioclkd.o: In function `Catch':
radioclkd.o(.text+0xd73): undefined reference to `munlockall'
radioclkd.o: In function `main':
radioclkd.o(.text+0x11e3): undefined reference to `mlockall'
*** Error code 1
Alternately, you could send an email to Garrett.
This sounds like a good idea, since within the last week he has
made mention of the particular broadcast station around which this
code in question is based, but more importantly, because I wasn't
able to convert your suggestions into working code. Naturally, my
ugly brute force ``solution'' of an `#if 0' wrapper sort of messes
up things for Linux and Solaris...
But thanks for the ideas. As I said many moons ago, I know nothing.
ihr
barry bouwsma
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
loop-aes (porting)
Hi! I'm looking for people helping to port loop-aes (www.sourceforge.net/projects/loop-aes) under FreeBSD. It is a type of crypted fs just like CFS. But since i had many problems with CFS (unsolved prolbems, and there was no answers for it from the writer and either from the mailing list) i decided to port this really good stuff under FreeBSD. if you have time/energy, and have ideas (because I don't have any) where to start feel free to mail me. regards mininx ps: sorry for crossposting... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
incorrect information in ata(4)?
% uname -a narcissus% uname -a FreeBSD example.com 4.5-STABLE FreeBSD 4.5-STABLE #6: Mon Mar 18 12:08:59 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EXAMPLE i386 % man ata | grep -C atamodes To see the devices' current access modes, use the command line: sysctl hw.atamodes [...] % sysctl hw.atamodes sysctl: unknown oid 'hw.atamodes' -- Ben An art scene of delight I created this to be ... -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: incorrect information in ata(4)?
On Wed, 2002-03-27 at 19:24, void wrote: % sysctl hw.atamodes sysctl: unknown oid 'hw.atamodes' Interesting, perhaps you should submit a PR and post this to the -doc list. -- c'est la sel fantasie ici pour toujours Shu-yu Guo [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
* Jeff Roberson [EMAIL PROTECTED] [020327 14:16] wrote: On Wed, 27 Mar 2002, Alfred Perlstein wrote: Can uma diagnose double free's? It doesn't seem to be able to under a GENERIC config. :( Oh! Thanks for pointing this out. Originally it could, but with the per cpu buckets it lost the ability to until the data was really freed. What I will do is disable per cpu buckets if INVARIANTS is on. The reason for this is that you have to lock the zone and look at the slabs to do double free detection. That's really not a good idea, how is one supposed to debug problems with the per-cpu stuff if INVARIANTS disables them? Why don't you look at how the old malloc(9) did it, it will show you how to do it with minimum performance impact (i think). -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uma and double free detection?
On Wed, 27 Mar 2002, Alfred Perlstein wrote: Oh! Thanks for pointing this out. Originally it could, but with the per cpu buckets it lost the ability to until the data was really freed. What I will do is disable per cpu buckets if INVARIANTS is on. The reason for this is that you have to lock the zone and look at the slabs to do double free detection. That's really not a good idea, how is one supposed to debug problems with the per-cpu stuff if INVARIANTS disables them? Why don't you look at how the old malloc(9) did it, it will show you how to do it with minimum performance impact (i think). -Alfred Given the structure of UMA it is much more complicated than the original malloc. No matter how you do it you'll have to grab the zone lock to check for double frees. Which means that the per cpu free lists will have to be drained so that you know the item isn't already in one of those. Which means the operation can not really use the per cpu queues unless you just search them all without really retiring the memory. So I have two options. The first, which I already suggested, and which requires the least code, is to disable per cpu queues. You can have it excercise most of the code paths by just forcing all bucket allocation to fail. Or, the second approach, I can write a significant amount of new code in both the allocation and free routines that is only executed when invariants is on. It would effectively execute all of the code paths in the per cpu queues but you would have to lock the zone to verify an address and then lock each per cpu queue to make sure it does not reoccur. I favor the first solution because it has less risk. What you end up with is the ability to debug UMA or users of UMA, but not both at the same time. I think this is acceptable. Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: incorrect information in ata(4)?
On Wed, Mar 27, 2002 at 07:32:26PM -0500, Shu-yu Guo wrote: On Wed, 2002-03-27 at 19:24, void wrote: % sysctl hw.atamodes sysctl: unknown oid 'hw.atamodes' Interesting, perhaps you should submit a PR and post this to the -doc list. Good ideas, I will do that. -- Ben An art scene of delight I created this to be ... -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: incorrect information in ata(4)?
On Thu, 2002-03-28 at 12:42, void wrote: On Wed, Mar 27, 2002 at 07:32:26PM -0500, Shu-yu Guo wrote: On Wed, 2002-03-27 at 19:24, void wrote: % sysctl hw.atamodes sysctl: unknown oid 'hw.atamodes' Interesting, perhaps you should submit a PR and post this to the -doc list. Good ideas, I will do that. -- Ben An art scene of delight I created this to be ...-- Sun Ra I tried this too, and I get the same problem. So I was poking around sysctls for fun and found this: kern.osrevision: 199506 I'm just wondering what that is all about? Shouldn't it be like 200203? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Timezone changes
I've taken up the local cable TV network (optus, telstra) practice of using AEST and AEDT instead of just EST in Australia, so I edited /usr/src/share/zoneinfo/australasia to produce these timezones. # New South Wales # Rule NAMEFROMTO TYPEIN ON AT SAVE LETTER/S ... RuleAN 1996max - Mar lastSun 2:00s 0 S RuleAN 2000only- Aug lastSun 2:00s 1:00 - RuleAN 2001max - Oct lastSun 2:00s 1:00 D # Zone NAMEGMTOFF RULES FORMAT [UNTIL] Zone Australia/Sydney 10:04:52 - LMT 1895 Feb 10:00 Aus EST 1971 10:00 AN AE%sT After installing the new tz file: su-2.05a# date Thu Mar 28 13:23:09 AEDT 2002 Fast forward to a date after daylight savings time ends: su-2.05a# date 200207070707 Sun Jul 7 07:07:00 AEST 2002 Back to normal: su-2.05a# date 200203281324 Thu Mar 28 13:24:00 AEDT 2002 I'm wondering why this isn't the default behaviour, is it because it'll break things or what? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
BOUWSMA Beery wrote: Moin, moin! %s wrote on %.3s, %lld Sep 1993 Your mailer is misconfigured... o The mlockall() function takes a flags argument that is an inclusive OR of one of several manifest constants. So basically, if you test for the manifest constants before making a call that uses them, then you are safe, e.g.: [ ... ] /usr/bin/gcc -s -o radioclkd radioclkd.o radioclkd.o: In function `Catch': radioclkd.o(.text+0xd73): undefined reference to `munlockall' radioclkd.o: In function `main': radioclkd.o(.text+0x11e3): undefined reference to `mlockall' *** Error code 1 FreeBSD is broken. It defines the manifests in scope, but specifically avoids the generation of the system call stubs by include munlockall.o and mlockall.o in /usr/src2/lib/libc/alpha/sys/Makefile.inc and /usr/src2/lib/libc/i386/sys/Makefile.inc in the NOASM= list of objects. Most of these objects have wrappers that are defined in the directory /usr/src2/lib/libc/gen or elsewhere in .c files. Actually, the undefined reference, and the fact that there was a SYS_munlockall defined in /usr/include/sys/syscalls.h should have been enough to send you to the libc sources. In any case, there are two possible explanations: o Listing these object files in the NOASM= was a mistake. Fix it by removing them from the NOASM= lines. o Listing these object files in the NOASM= was a bungled attempt to remove these system calls from the namespace, because they were incompletely implemented, and the bungling was in not #if 0 outing the code and the manifest constants defined for the calls. Fix it by either completing the removal by changing the header files, OR Fix it by completing the implementation, and remove them from the NOASM= lines. In either case, my feature test code, though inelegant (as I said it was when I posted it), is correct. That leaves the FreeBSD code, and your code. You need to determine whether or not this was an error in the inclusion process for the calls, or an error in the exclusion process for the calls, befor you will know which is the right thing to do. Alternately, you could just implement the calls for FreeBSD, rather than leaving them stubbed out in the kernel, and then it's irrelevent what the intent was. Patches for implementing one of the options are welcome: o #if 0 out the manigfests and function prototypes, until the implementation is complete. o Remove the object files from the NOASM= list, so that the stubbed-out system calls are defined in libc, even though they are stubbed out. Note: This seems wrong to me o Finish the implementation of the stubbed out system calls, and remove the object files from the NOASM= list so that they are properly defined. Pretty trivial to do the first two. The last one is harder; I personally can't really see a lot of value in having the system calls int he first place, so I imagine if the code is going to get done, it will be done by someone who wants to use them. Say someone who wants this badly enough to feature-test for the calls in code they are writing, instead of ignoring them... ;^). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Fw: ? sysctl -a crashed the GENERIC kernel
- Original Message - From: Gautham Ganapathy [EMAIL PROTECTED] To: FreeBSD.org - Questions [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 27, 2002 9:06 AM Subject: ? sysctl -a crashed the GENERIC kernel Hi I installed FreeBSD 4.5 from the freebsdmall feb2002 cd. after installation, i ran sysctl -a and the kernel (GENERIC) crashed (accessing a non-existant page). i tried it a few more times it crashed consistently. it stopped after i recompiled the kernel. is this due to a problem in the default kernel ? i am running on an athlon thunderbird 850, asus a7v m/b, 256 mb ram the error was Fatal trap 12 : page fault while in kernel mode fault address= 0x6351ec0c fault code = supervisor read, page not found instruction pointer = 0x8:0xc022007c stack pointer= 0x10:0xede0ebf8 frame pointer= 0x10:0xcde0ee20 code segment = base 0x0, limit 0xff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 228 (sysctl) interrupt mask = trap number = 12 panic : page fault what is the stuff given in the second line of code segment mean (pres, def32, ...) ? regards gautham To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ? sysctl -a crashed the GENERIC kernel
In the last episode (Mar 28), Gautham Ganapathy said: Fatal trap 12 : page fault while in kernel mode fault address= 0x6351ec0c fault code = supervisor read, page not found Is this repeatable, or did it only happen once? Unexplained trap 12 panics or signal 11 coredumps are usually due to an excessively overclocked CPU, or bad RAM. Try dropping your CPU speed 5%. -- Dan Nelson [EMAIL PROTECTED] It is repeatable. I tried it around 5 times. System is not overclocked and i have never had problems with this RAM. besides, there are not problems with the recompiled kernel. also i saw a somewhat similar post in freebsd-questions shortly after mine with the same error. it was from Jean-Yves Avenard with the subject Problem with upgrading my FreeBSD 4.3 regards gautham To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ? sysctl -a crashed the GENERIC kernel
In the last episode (Mar 28), Gautham Ganapathy said: Fatal trap 12 : page fault while in kernel mode fault address= 0x6351ec0c fault code = supervisor read, page not found Is this repeatable, or did it only happen once? Unexplained trap 12 panics or signal 11 coredumps are usually due to an excessively overclocked CPU, or bad RAM. Try dropping your CPU speed 5%. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: incorrect information in ata(4)?
In message: [EMAIL PROTECTED] David Turnbull [EMAIL PROTECTED] writes: : I tried this too, and I get the same problem. : So I was poking around sysctls for fun and found this: : : kern.osrevision: 199506 : : I'm just wondering what that is all about? Shouldn't it be like 200203? This is the same as 4.4-lite I think. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
