Re: FreeBSD Linux emulation / arla 0.34.6
Chris [EMAIL PROTECTED] writes:
I have discovered a rather interesting bug with this combination,
and was wondering if anyone could point me in the right direction
to help me track it down.
The problem is that linux binaries which call getdirents on an afs
directory do not report the last directory entry:
/afs/whatever% /bin/ls -f
1 2 3 4
/afs/whatever% /compat/linux/bin/ls
1 2 3
The patch below for arla fixes the problem.
I believe that this might also be what is causing linux-netscape
to wedge the machine (with home directories on afs), although I'm
not positive.
This patch does fix the directory problem, but apparently not the
netscape wedging problem. Anyways, I have tracked it down I think,
but I'm not positive about the fix.
The problem appears to be xfs_readdir getting passed a directory
that contains an entry with dp-d_reclen zero--then it gets stuck
infinitely looping here.
Chris
*** xfs_vnodeops-bsd.c.old Tue Jan 30 16:58:04 2001
--- xfs_vnodeops-bsd.c Tue Jan 30 16:59:23 2001
***
*** 497,510
dp_end = (const struct dirent *) uio-uio_iov-iov_base;
for (dp_start = dp, ncookies = 0;
dp dp_end;
!dp = (const struct dirent *)((const char *) dp + dp-d_reclen))
ncookies++;
MALLOC(cookies, xfs_cookie_t *, ncookies * sizeof(xfs_cookie_t),
M_TEMP, M_WAITOK);
for (dp = dp_start, cookiep = cookies;
dp dp_end;
dp = (const struct dirent *)((const char *) dp + dp-d_reclen)) {
off += dp-d_reclen;
*cookiep++ = off;
}
--- 497,515
dp_end = (const struct dirent *) uio-uio_iov-iov_base;
for (dp_start = dp, ncookies = 0;
dp dp_end;
!dp = (const struct dirent *)((const char *) dp + dp-d_reclen)) {
ncookies++;
+ if (dp-d_reclen == 0)
+ break;
+ }
MALLOC(cookies, xfs_cookie_t *, ncookies * sizeof(xfs_cookie_t),
M_TEMP, M_WAITOK);
for (dp = dp_start, cookiep = cookies;
dp dp_end;
dp = (const struct dirent *)((const char *) dp + dp-d_reclen)) {
+ if (dp-d_reclen == 0)
+ break;
off += dp-d_reclen;
*cookiep++ = off;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Linux emulation / arla 0.34.6
The problem is that linux_getdents uses a little too small buffer, arla uses (before the patch) a directory-blocksize of 1024 bytes. This make every entry that have its end past a 512 bytes offset disapper when running under linux-emulation. Love That was quick. Really, I can't thank you enough for this.. This makes my life considerably easier. :) It seems kind of dangerous having these things hard coded--should the linux compatibility code be fixed? I notice that there is a #define DIRBLKSIZ 512/* XXX we used to use ufs's DIRBLKSIZ */ at sys/compat/linux/linux_file.c:425. It is not clear to me what this should be though. Anyways, thanks again, Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM issues..
On Thu, Dec 07, 2000 at 12:06:46AM +, Chris wrote: Hi, I have been writing a PAM module to do Kerberos 5 and AFS stuff, and have run across a couple of problems. Have you looked at ports/security/pam_krb5, by the way? This does Kerberos 5, but not AFS. IIRC, this module will authenticate you, but will not get you tickets. I think this was because the tickets are stored using pam_setcred(), hence my question. I haven't looked at it for a while though--its possible the situation has changed. Anyways, what I have written gets Kerb 5 tickets, converts them to v4, and then adds the token after setting up a PAG. Basically, what the mit aklog does, but it actually compiles and works with our kafs library. The next is pam_setcred(). I've noticed that this is not actually called from login/etc, so it doesn't do much good. Is this intentional? Not that it matters much, for anything other than compatibility with other modules. Patching login et. al. to call pam_setcred is trivial. The only reason I haven't done so yet is because pam_setcred is all but useless. :-) I'm enclosing a previous message that I sent to the FreeBSD PAM maintainer (ok well it went to jdp first and then later to markm) to explain more fully. None of us have had time to address it yet, and this appears to be a bug in Linux-PAM (which is the implementation we use). I figured it was something along these lines. :) I realize the pam_setcred is about useless, but it would be nice to have session support. Anyways, thanks for the pointer. Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IDE Questions
Is there anyone successfully using an IBM 75GXP with an Abit KT7-Raid motherboard? I am using stable from a couple days ago, and am having some problems getting it to work. If the disk is attached to the onboard IDE, the kernel spews a bunch of these ad2: UDMA ICRC WRITE ERROR blk# 1457759 retrying and then falls back to PIO mode, which is unacceptable. (ie. it transforms my Athlon 900 into a turd. For any moderate amount of disk activity, I get 100% CPU utilization, and it is very much non-interactive.) I have the proper cables, and have observed this on two seperate KT7 motherboards. Is the KT7 onboard IDE just busted? (I wouldn't be at all surprised, considering how horribly broken the BIOS boot ordering is, not to mention the soft power issues, etc. For a board that comes so highly recommended, I'm not terribly impressed.) When I attach the disk to the Highpoint 370 controller, the machine wedges after a short while. Is the support for this chipset in stable up to date? Also, are there any plans to merge the support for tagged queueing? Thanks, Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: diskless workstation
Mike Smith wrote: ok, once i compiled a kernel with options BOOTP things got better ;-) it worked several times, but now it boots ok, (pxe-dhcp-tftpboot-nfs) but after it re-configures the ethernet, the ethernet stops working! ponters anyone? You can't run dhclient (DHCP in any of the ifconfig lines in /etc/ rc.conf) if you have mounted / via NFS. If you're running -current or a very recent -stable, remove the 'BOOTP' options. The loader now passes all the DHCP information into the kernel. Then leave the interface configuration alone... Has this actually been merged to -stable yet? I can't find anything that actually reads the boot.nfsroot.* loader variables. Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Bridging problems.. (WaveLan related?)
I have been trying for over a week now to get bridging working, but without success. I have tried both 4.0 and current, but with no luck. Anyways, my setup is as follows.. On one end is a Lucent WavePoint attached to the outside world. (Some sort of switch I believe. I really don't understand the setup--they are using some sort of vlan stuff) I'm tempted to replace the WavePoint with a PC, but I don't have the hardware for that now. On my end, I have a box with a wi0 and fxp0--I was hoping to set it up to do transparent bridging. So far however, I can't get anything on this side of the bridge box to talk to the outside world. I can see all the network traffic from my box, however I can't talk through the bridge. Basically, any arp request that goes out, seems to disappear. If I run tcpdump on the wavelan interface, it shows the arp requests, but never any replies. I can see incoming arp requests for my box, and it seems to send the reply, only to be lost somewhere as well. Another interesting thing occurs from the bridge box itself. If I ping the network broadcast, only things on the wavelan side reply. This may be some irrelevant quirk, I'm not sure. Has anyone ever set up a box like this? Will it work with a WavePoint attached to a switch on the other side? I can't see why it shouldn't, but maybe I am missing something. Does the wavelan network need to be "ad-hoc" instead of BSS mode? All I know is this is becoming really irritating. (Not FreeBSD, but the fact that we don't have direct access to the network on the other side.) We have been trying to get this set up since May, and it has been a nightmare to deal with the politics and to debug it from one side. Ugh. Any theories/etc would be very welcome.. Thanks, Chris Csanady To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bridging problems.. (WaveLan related?)
It never fails.. I always post stuff just minutes too soon. Anyways, it seems that the problem is with the WaveLan network. In ad-hoc, or infrastructure mode, the card can only send frames with its own mac address as the source. Apparrently, the card needs to be set up as an access point (or something) to do bridging. Is there a way to do this in the current driver? If not, are there plans? Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IO APIC misdirecting irq (Re: SMP/interrupt problems..)
Sorry for the post to both lists--the original message probably belonged on freebsd-smp. Anyways, please follow up there only. I have tracked down the problem with the Megaraid controller in SMP, and it seems it is due to an irq being misrouted. While the controller thinks it is on irq 11, all the interrupts are actually going to apic irq 17. I have confirmed this by hardwiring amr0's interrupt to be irq 17--in which case it works perfectly. :) It is not clear to me whether the irq should or should not be routed to irq 17 though--only that it is what is happening with the current configuration. Does anyone know in particular how this should work? (Or better yet, have a fix? ;) It is kind of weird, because the amr0 controller is actually the same device as the pci-pci bridge, just a different function. So, I assume it is just on the host bus. In any case, even though the irq/int pin match in the mptable, the device (slot) does not. :\ I have included my dmesg, pciconf output, and mptable output. The device in question is the vendor=0x8086, dev=0x1960. Anyone have any ideas? Chris Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #14: Sat Oct 23 19:15:37 CDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/EUROPA Calibrating clock(s) ... TSC clock: 198655681 Hz, i8254 clock: 1193129 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium Pro (198.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00322000 - 0x07ff7fff, 130899968 bytes (31958 pages) avail memory = 126820352 (123848K bytes) Programming 24 pins in IOAPIC #0 SMP: CPU0 apic_initialize(): lint0: 0x0700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0 bios32: Found BIOS32 Service Directory header at 0xc00fd970 bios32: Entry = 0xfd980 (c00fd980) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xd9a1 pnpbios: Found PnP BIOS data at 0xc00fa170 pnpbios: Entry = f:a270 Rev = 1.0 Other BIOS signatures found: ACPI: Preloaded elf kernel "kernel" at 0xc0306000. Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff pci_open(1):mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=12378086) npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=12378086) pcib0: Host to PCI bridge on motherboard found- vendor=0x8086, dev=0x1237, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 Freeing (NOT implemented) redirected PCI irq 9. found- vendor=0x8086, dev=0x1229, revid=0x02 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=18 map[0]: type 1, range 32, base ffbae000, size 12 map[1]: type 1, range 32, base ff40, size 5 map[2]: type 1, range 32, base fef0, size 20 found- vendor=0x8086, dev=0x7000, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[4]: type 1, range 32, base ffa0, size 4 found- vendor=0x8086, dev=0x7020, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=d, irq=9 map[4]: type 1, range 32, base ff80, size 5 Freeing (NOT implemented) redirected PCI irq 11. found- vendor=0x9004, dev=0x8078, revid=0x00 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=17 map[0]: type 1, range 32, base f400, size 8 map[1]: type 1, range 32, base ffbaf000, size 12 Freeing (NOT implemented) redirected PCI irq 10. found- vendor=0x1000, dev=0x000f, revid=0x14 class=01-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=16 map[0]: type 1, range 32, base f800, size 8 map[1]: type 1, range 32, base
Re: SMP/interrupt problems..
Ugh, I forgot to attach said info. Chris - === MPTable, version 2.0.15 mptable: option requires an argument -- v usage: mptable [-dmesg] [-verbose] [-grope] [-help] friley-160-235# mptable -verbose === MPTable, version 2.0.15 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009f800 (638K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f MP FPS found in BIOS @ physical addr: 0x000f80f0 --- MP Floating Pointer Structure: location: BIOS physical address: 0x000f80f0 signature:'_MP_' length: 16 bytes version: 1.4 checksum: 0x10 mode: Virtual Wire --- MP Config Table Header: physical address: 0x000f8100 signature:'PCMP' base table length:260 version: 1.4 checksum: 0x52 OEM ID: 'INTEL ' Product ID: 'PR440FX ' OEM table pointer:0x OEM table size: 0 entry count: 24 local APIC address: 0xfec08000 extended table length:120 extended table checksum: 15 --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model StepFlags 0 0x11BSP, usable 6 1 9 0xfbff 12 0x11AP, usable 6 1 9 0xfbff -- Bus:Bus ID Type 0 PCI 1 PCI 18 ISA -- I/O APICs: APIC ID Version State Address 13 0x11usable 0xfec0 -- I/O Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# ExtINT active-hiedge 18 0 130 INT active-hiedge 18 1 131 INT active-hiedge 18 3 133 INT active-hiedge 18 4 134 INT active-hiedge 18 5 135 INT active-hiedge 18 6 136 INT active-hiedge 18 7 137 INT active-hiedge 18 8 138 INT active-hiedge 18 9 139 INT active-hiedge 1812 13 12 INT active-hiedge 1814 13 14 INT active-hiedge 1815 13 15 INT active-lo level0 19:A 13 19 INT active-lo level0 17:A 13 18 INT active-lo level0 9:A 13 17 INT active-lo level0 6:A 13 18 -- Local Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# ExtINT active-hiedge 18 02550 NMI active-hiedge0 0:A2551 --- MP Config Extended Table Entries: -- bus ID: 0 address type: memory address address base: 0xd4000 address range: 0x4000 -- bus ID: 0 address type: memory address address base: 0xd8000 address range: 0x4000 -- bus ID: 0 address type: memory address address base: 0xdc000 address range: 0x4000 -- bus ID: 0 address type: memory address address base: 0xa address range: 0x2 -- bus ID: 0 address type: memory address address base: 0x800 address range: 0xf800 -- bus ID: 0 address type: I/O address address base: 0x0 address range: 0x1 --- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional (built-in defaults will work in most cases): #optionsNCPU=2 # number of CPUs #optionsNBUS=3 # number of busses #optionsNAPIC=1 # number of IO APICs #options
SMP/interrupt problems..
I recently got an AMI Megaraid controller, and although it works perfectly with a single processor kernel, SMP is causing some problems. After doing a little debugging, it appears that the interrupts are possibly being lost. I'm wondering if this is somehow related to the APIC, and interrupt remapping that happens with SMP. I have included the output of mptable, and a verbose dmesg at the end. Also, LINT mentions some problems with MP tables not properly supporting bridged pci cards. Are there still issues with this? My motherboard (Intel pr440fx) is listed as one with "good" mptable support--at least by the linux kernel. :\ Is there a chance that this combination will simply not work? Any ideas at all on how to isolate the problem would be appreciated. I am at whits end wrt this problem. Thanks, Chris Csanady To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
"Alton, Matthew" wrote: I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of "The Design and Implementation of the 4.4BSD Operating System" still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? I don't know, but I came across this at SGI: http://oss.sgi.com/projects/xfs/ It looks as though they plan to release it under the GPL. :( Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port BSD VFS Rewrite
Alton, Matthew wrote: I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of The Design and Implementation of the 4.4BSD Operating System still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? I don't know, but I came across this at SGI: http://oss.sgi.com/projects/xfs/ It looks as though they plan to release it under the GPL. :( Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Serial Console Wierdness
Bill G. wrote: I got a serial console working on COM2, to which I have connected another FreeBSD box. I connect with 'cu' fine, but I'm running into a couple of problems which I haven't been able to find and answer for. o When I connect, when the machine is first turned on, I get disconnected twice during the boot up sequence (cu reports Got hangup signal) -- looks like when the sio1 device is probed, and also when getty runs. This happens when the serial chip gets reset, and the DCD line goes low for a moment. For most local serial connections, you really want to tie the DCD pin back to the DTR/DSR. If you use rj45 modular adapters, this is fairly easy. I find the following wiring to be rather convenient, as you have a single type of adapter, which can used for just about anything. If you use a crossed ethernet cable, you will get a null cable, otherwise it will be straight through. Signal DB25 DB9 RJ45Color ,--DCD 8 1 NC | TXD 2 3 1 Blue | RXD 3 2 3 Black +--DTR 20 4 NC | SG 7 5 7 Brown `--DSR 6 6 NC RTS 4 7 2 Orange CTS 5 8 6 Yellow Hope this is of some use.. Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
