Re: UUID in fstab.
On Monday, August 26, 2013 12:06:21 am varanasi sainath wrote: Thanks John, I have tried as you suggested using a Live CD and yes the partitions uuid's are present in gptid .. I found the UUID's in /dev/gptid - how do I determine which uid corresponds to which partition (ufs or swap or boot) (I used glabel status and after some trial and error I found them) edited the fstab accordingly and everything is working now .. The other way would be to examine the kern.geom.confxml output directly as I think you can probably use that to map between them. Is there a way to have both the /dev/XXXpYY and /dev/gptid/uuid present in /dev/ Not currently. freebsd-geom@ is probably the best place to ask that question. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: UUID in fstab.
On Wednesday, August 21, 2013 4:38:00 pm varanasi sainath wrote: Thanks for the support. I want to use the uuid's found using sysctl -a in fstab. /dev/gptid/ has only uuid for boot partition. You probably have the other GPT paritions already mounted via another name which removes the names in /dev/gptid. Try booting an install CD or USB stick such that you use an alternate root fs and don't mount any of the partitions on your drive. Then you should be able to see the entries in /dev/gptid and update your fstab appropriately. If you console access you could also try to update your fstab to use /dev/gptid/uid directly instead of /dev/XXXpYY and reboot. If it works I believe the /dev/XXXpYY names will now be gone from /dev and the /dev/gptid names present instead. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Kernel Panic - Unix socket communication in kernel module
On Monday, July 29, 2013 3:31:49 am varanasi sainath wrote: Hello, I am writing a kernel module in which I am trying to connect to a UNIX socket (UNIX domain sockets use the file system as their address name space). Kernel module (loadable) acts as a client and User mode program acts as server, I have loaded the module using kldload and communication between user and kernel module works fine, when I try to load the kernel module from loader.conf - auto load the kernel module at boot up leads to kernel panic as the file system is not ready and kern_connect fails. How to notify kernel module that File system is ready? (any specific event flags) Is there any specific location for Unix domain socket files? (currently created it under /root/soc/socket ) Using MODULE_DEPEND Can I make the module dependent of file system? You can register a hook for the 'mountroot' EVENTHANDLER event which will fire after / is mounted. (You could compare rootvnode against NULL during module startup to determine if you should defer your work to the EVENTHANDLER vs doing it right away.) If you need to wait for all local filesystems to be mounted, then you will need to have some userland utility poke your module via a sysctl/ioctl/etc. after the filesystems are mounted (you could use a custom rc.d script for this). -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Failed to allocate receive buffer problem
On Wednesday, June 12, 2013 3:06:26 am Alex Liptsin wrote: Hi. I have a problem that when running a ping (or any other traffic) over IPoIB port, Traffic fails after some time. At destination server DMESG I see that errors: Jun 11 14:42:11 h-qa-033 kernel: ib1: failed to allocate receive buffer 253 Jun 11 14:42:12 h-qa-033 kernel: ib1: failed to allocate receive buffer 254 Jun 11 14:42:13 h-qa-033 kernel: ib1: failed to allocate receive buffer 255 Jun 11 14:42:14 h-qa-033 kernel: ib1: failed to allocate receive buffer 0 Jun 11 14:42:15 h-qa-033 kernel: ib1: failed to allocate receive buffer 1 Jun 11 14:42:16 h-qa-033 kernel: ib1: failed to allocate receive buffer 2 Jun 11 14:42:17 h-qa-033 kernel: ib1: failed to allocate receive buffer 3 Jun 11 14:42:18 h-qa-033 kernel: ib1: failed to allocate receive buffer 4 Jun 11 14:42:19 h-qa-033 kernel: ib1: failed to allocate receive buffer 5 Jun 11 14:42:20 h-qa-033 kernel: ib1: failed to allocate receive buffer 6 Jun 11 14:42:21 h-qa-033 kernel: ib1: failed to allocate receive buffer 7 I work with FreeBSD 9.1. Is it a bug or some configuration issues? Do you see memory allocation errors in netstat -m? Specifically this line: 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) If so, it may be that the IPoIB layer has an mbuf leak. The rest of netstat - m might be useful here as you can see if any of the zones are full. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How to compile ipoib module manually?
On Tuesday, June 04, 2013 5:18:46 am Alex Liptsin wrote: I commented on that lines, because I want to compile and load that modules manually. I had succeed to compile and load mlx4, mlx4ib and mlxen from /sys/modules: [root@h-qa-033 mlxen]# kldstat Id Refs AddressSize Name 1 14 0x8020 13acbd8 kernel 21 0x81612000 21e5 if_mos.ko 33 0x81615000 124ebmlx4.ko 41 0x81628000 e225 mlx4ib.ko 51 0x81637000 ec60 mlxen.ko The problem is that IPOIB module is missing in /sys/modules. 1. Where can I find it? 2. How can I compile ipoib support? You will have to create one. You should be able to use the existing module Makefiles as a guide. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: How to switch Datgram/Connected mtu modes?
On Sunday, May 26, 2013 7:43:29 am Alex Liptsin wrote: Hello. I work with FreeBSD 9.1 and Mellanox devices. How can I configure MTU in connected mode on FreeBSD 9.1? In Linux to enable connected mode for interface ib0, I enter: echo connected /sys/class/net/ib0/mode Switching between CM and UD mode can be done in run time: echo datagram /sys/class/net/ib0/mode sets the mode of ib0 to UD echo connected /sys/class/net/ib0/mode sets the mode ib0 to CM There is no such directories at FreeBSD. Wat shall I do? Have you tried looking for dev.ib.0 sysctls? It looks like the OFED bits in FreeBSD map Linux sysfs entries to sysctl nodes, but I don't have a box with IB handy to see what it looks like at runtime. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: building custom kernel on -current: unknown option COMPAT_LINUX
On Saturday, February 09, 2013 10:01:25 pm ill...@gmail.com wrote: On 9 February 2013 20:26, Anton Shterenlikht me...@bristol.ac.uk wrote: I removed COMPAT_LINUX, and only left options COMPAT_43 options COMPAT_LINUX32 From /usr/src/sys/amd64/conf/NOTES (9.1-RELEASE): # Enable Linux ABI emulation #XXX#optionsCOMPAT_LINUX # Enable 32-bit Linux ABI emulation (requires COMPAT_43 and COMPAT_FREEBSD32) options COMPAT_LINUX32 I think I first ran up against this when I moved to 9.0 some time ago, but yes, amd64 uses a different kernel config option than i386 for linux compat. I tend to leave it as a module load it if I perchance need it. This also allows rebuilding reloading the modules without a reboot, should it need it. The modules seems to build fine without having to fiddle about with kernel config jiggerypokey. COMPAT_LINUX will work on amd64 eventually and will be used for 64-bit Linux binaries (COMPAT_LINUX32 is to run Linux/i386 binaries on FreeBSD/amd64). -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Wednesday, May 30, 2012 3:56:02 pm Mark Felder wrote: On Wed, 30 May 2012 12:17:07 -0500, John Baldwin j...@freebsd.org wrote: Humm, can you test it with 2 CPUs? We primarily only run with 1 CPU. We have seen it crash on multiple CPU VMs. Also, Dane Foster appeared to have been using multiple CPUs in his video transcoding VMs. Unfortunately I can't give you more information at the moment. I'm working with Dane to compile easy to follow steps that recreate this failure. I have not been successful in getting this to crash on demand in my environment, but Dane has so we're trying to recreate his. Ok. It would be really helpful if we could get a crashdump, though I realize that may not be doable. Otherwise, full DDB ps output from a hang would be a good start. Primarily I would want to see what the system is doing and why it isn't running the threads on the run queue. It might also be useful to add KTR_SCHED tracing so we can get the output of that via 'show ktr' from DDB when it hangs. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thursday, May 31, 2012 11:11:11 am Mark Felder wrote: So when this hang happens, there never is a real panic. It just sits in a state which I describe as like being in a deadlock. How would I go about getting a crashdump if it never panics? Is it possible to do the dump over a network or something because I don't believe it can write through the controller at all. You can break into ddb and run 'call doadump'. It should use polled IO, so there is a slight chance of it working. Also, thank you for the KTR_SCHED tip. This is the type of info I was looking for. Unfortunately I've only ever seen this crash once on a kernel with debugging enabled. The machine which is currently prepared to do this work used to crash a few times a week and now it has 70 days uptime... however, it is an example of a machine with mpt0 and em0 sharing an IRQ so I might be able to trigger it using Dane's method. $ vmstat -i interrupt total rate irq1: atkbd0 392 0 irq6: fdc0 9 0 irq14: ata0 34 0 irq18: em0 mpt0 1189748491218 cpu0: timer 2174263198400 Total 3364012124619 I'm doing my best to get you guys the info you need, but this is one heck of a Heisenbug... Thanks. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thursday, May 24, 2012 9:47:46 am Mark Felder wrote: On Wed, 23 May 2012 17:30:40 -0500, Adrian Chadd adr...@freebsd.org wrote: Hi, can you please, -please- file a PR? And place all of the above information in it so we don't lose it? I'd be glad to post a PR and assist in helping to get it permanently fixed. I certainly don't want this data to get lost and honestly our business uses FreeBSD on VMWare so much that we really need a permanent fix as much as anyone else :-) The reason I've hesitated to post a PR so far is that I didn't have any truly useful or concrete evidence of where the problem lies. After Dane Foster contacted me and told me he could recreate the crash on demand with his workload it was easier to narrow things down. The suggestion that it was an interrupts issue (by possibly Bjoern Zeeb?) and Dane's discovery that his crashes ceased when em0 and mpt0 share an IRQ, but em0 is completely unused was starting to prove there is some strong evidence here in favor of the interrupts issue. Dane, what's the status on your end? Has your fix still been successful? Is it also stable if you simply set hint.mpt.0.msi_enable=1 ? Hmm, so the set of ps output you have from DDB shows a lot of runnable processes and swi6 (Giant taskq) as the only running thread (all consistent with your hang). (And that is from your Ctrl-Alt-Esc) Do you only have one CPU in this VM? If not, do you know which threads the other CPUs were running (e.g. do you have ps7.png, etc.)? -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: MFP recommendations
On Thursday, August 11, 2011 5:51:36 am Jon Theil Nielsen wrote: 2011/8/10 Jon Theil Nielsen jonth...@gmail.com Hi list, I want to buy another printer to use mainly with Windows. Even though I have no good feelings about those devises, that claims to be able to do everything I need. Even though, I need a better scanner with ADF and duplex printing (it need to be able to connect wirelessly to my Windows stations). So my question is if I can find such a thing, that I can connect to my FreeBSD server too. And if you can recommend a specific model. I have been looking at a lot of models, but I can't figure out if any of them would be able to work through FreeBSD, cups etc. Examples: HP Officejet Pro 8500A (CM755A) HP Photosmart Premium Fax e-All-in-One (CQ521B) Canon PIXMA MX885 Epson... Brother... In the first place, I may have to connect it via USB or ehternet. If it could be connected by my wireless adapter (Linksys WUSB600N), it would be nice Best regards, Jon Theil Nielsen Since my main goal is to be able to print over the network via my FreeBSD station, I could put in another way: Can I expect that printers known to be supported by HPLIP ( http://hplipopensource.com/hplip-web/supported_devices/index.html) actually work in FreeBSD? And would one of the HP models by a safe choice? Yes, anything that works with hplip (which is in ports) will work great with cups in KDE, OpenOffice, etc. I currently use some MFC OfficeJet thinigie at home with hplip. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: 8.1-RELEASE hangs on reboot
On Tuesday, November 30, 2010 8:23:19 pm Ondřej Majerech wrote: Hello, my 8.1-R system has just started hanging on reboot. Specifically after I svn up'd my source and updated from 8.1-R-p1 to -p2. Some kind of hang occurs on every reboot attempt. Usually it hangs at the Rebooting... message, but sometimes the thing just locks up before it even syncs disks. shutdown -p now seems to shutdown the system successfully each time. So I booted into single-user mode, executed reboot and during the Syncing disks I pressed Ctrl-Alt-Escape to break into the debugger. There I single-stepped with the s command until the thing simply stopped doing anything. (Even if I pressed NumLock, the LED on the keyboard wouldn't turn off.) The screen content at the moment of hang is (dutifully typed over as the thing is dead and I don't have a serial cable): [thread pid 12 tid 100017 ] Stopped at sckbdevent+0x5f: call _mtx_unlock_flags db [thread pid 12 tid 100017 ] Stopped at _mtx_unlock_flags: pushq %rbp db [thread pid 12 tid 100017 ] Stopped at _mtx_unlock_flags+0x1: movq %rsp,%rbp db [thread pid 12 tid 100017 ] Stopped at _mtx_unloock_flags+0x4: subq $0x20,%rsp db [thread pid 12 tid 100017 ] Stopped at _mtx_unlock_flags+0x8: movq %rbx,(%rsp) db [thread pid 12 tid 100017 ] Stopped at _mtx_unlock_flags+0xc: movq %r12,0x8(%rsp) db [thread pid 12 pid 100017 ] Stopped at _mtx_unlock_flags+0x11: movq %rdi,%rbx db [thread pid 12 pid 100017 ] Stopped at _mtx_unlock_flags+0x14: movq %r13,0x10(%rsp) db E Including that E at the end. No good ideas here, though I think we just turned off PSL_T by accident so it ran for a while before hanging after this. 'E' must be the start of a message on the console. As I said, it's 8.1-RELEASE-p2; it's on AMD64. I'm using custom kernel which only differs from GENERIC by addition of the debugging options: options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC I tried rebooting with ACPI disabled, but the thing paniced on boot with panic: Duplicate free of item 0xff00025e from zone 0xff00bfdcc2a0(1024) cpuid = 0 KDB: enter: panic [thread pid 0 tid 10 ] Stopped at kdb_enter+0x3d: movq $0, 0x6b2d20(%rip) db bt Tracing pid 0 tid 10 td 0x80c63fc0 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b uma_dbg_free() at uma_dbg_free+0x171 uma_zfree_arg() at uma_zfree_arg+0x68 free() at free+0xcd device_set_driver() at device_set_driver+0x7c device_attach() at device_attach+0x19b bus_generic_attach() at bus_generic_attach+0x1a pci_attach() at pci_attach+0xf1 The free() should be the free to free the softc but that implies it had a previous driver and softc. Maybe add some debug info to devclass_set_driver() to print out the previous driver's name (and maybe the value of the pointer) before free'ing the softc. You could use gdb on the kernel.debug and the pointer value to figure out exactly which driver was the previous one and look to see if it's probe routine does something funky with the softc pointer. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: msk0 interface stops working when downloading
On Tuesday, November 23, 2010 6:25:06 pm Andrew Moran wrote: Hey guys, After banging my head against this for a few hours, I've decided to ask for help. I installed FreeBSD 8.1 amd64 on a Shuttle J1 4100 system (tech specs here http://us.shuttle.com/J1_4100.aspx). I installed from DVD and the install went fine. I notice when I pkg_add -r anything, the network stops responding. Some details: 1) I can reproduce it 100% by downloading a large file. low traffic like the SSH connection does not trigger it. I think it's being triggered by traffic above a certain rate. 2) I can recover by restarting the network interfaces (/etc/rc.d/netif stop; /etc/rc.d/netif start) 3) I see no errors in dmesg or /var/log/messages. Nothing at all. 4) I've tried the following in /etc/sysctl.conf: net.inet.tcp.tso=0 net.inet.tcp.inflight.enable=0 and in /boot/loader.conf: hw.pci.enable_msix=0 hw.pci.enable_msi=0 hw.bce.tso_enable=0 But the problem persists. The interface is identified as: mskc0: Marvell Yukon 88E8057 Gigabit Ethernet port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 17 at device 0.0 on pci2 msk0: Marvell Technology Group Ltd. Yukon Ultra 2 Id 0xba Rev 0x00 on mskc0 msk0: Ethernet address: 80:ee:73:01:60:7d miibus0: MII bus on msk0 e1000phy0: Marvell 88E1149 Gigabit PHY PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mskc0: [ITHREAD] When I've seen this on my netbook I did a tcpdump on another machien on the same hub and found that my msk0 device was spewing an endless stream of pause frames. I've only had this problem with a gigE switch, it works fine for me on a 10/100 switch. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: LSI 9211 driver
On Monday, November 15, 2010 12:03:35 pm Gergely CZUCZY wrote: Hello, I'd like to ask when can we expect a driver for the LSI 9211 hardware? That is, the following device: non...@pci0:4:0:0: class=0x010700 card=0x30501000 chip=0x00721000 rev=0x02 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' class = mass storage subclass = SAS I've tried to add the cardID to the mfi(4) and mpt(4) drivers, but the most I could get, is a failed initalization. If any devs supposed to add properly the device to any of the drivers, I should be able to arrange access to this device for the time of the development. Please be so kind to reply to any known developers of these drivers, if they might not read these mailing lists, in order to get a working driver for this card (been seen google hits on many missing the support for this driver). Drivers for linux and solars are availabe on LSI.com, but not for fbsd. Thank you very much in advance. Did you try the mps(4) driver from HEAD? -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: random FreeBSD panics
On Sunday 28 March 2010 4:28:29 am Masoom Shaikh wrote: Hello List, I was a happy FreeBSD user, just before I installed FreeBSD8.0-RC1. Since then, system randomly just freezes, and there is no option other than hard boot. I guessed this will get solved in 8.0-RELEASE, but it was not :( Many times I get vmcore files, not always. I have dumpdev set to AUTO in my rc.conf. Almost every time it just fsck's the file-system on reboot. I have not lost any files though. This is a Dell Inspiron 1525 Laptop with 1GB ram, Intel Core2 Duo T5500 with ATI Radeon X1400 card. The installation in question is KDE4 from ports, with radeon/ati driver. I felt the problem is with wpi driver, then suspected dri driver of X. Then I observed system freezes even if none of this is installed. e.g. if it is under some load, like building a port and simultaneously fetching something over network it hangs, and hangs hard. This persuaded me to think something is wrong in kernel scheduling itself. May be it is lost in some deadlock, etc... Thus last weekend I thought I would see how immediate previous version i.e. FreeBSD-7.3-RELEASE would behave. I reinstalled FreeBSD7.1 from iso images, svn up'ed FreeBSD7.3 source, did the normal buildworld, buildkernel, installkernel, installworld cycle. Unfortunatly this kernel is naughty as well ;-), it also freezes with same stubbornness. But difference is this time I happen to catch something interesting. It panics on NMI, fatal trap 19 while in kernel mode. Loaded the vmcore file in kgdb and got the backtrace. I obtained vmcore files on two occasions. I have attached both the back traces. This error most likely suggests hardware error in RAM, but Windox7 and XP boot just fine and never caused any errors. Yes, and note that the chipset has set a register to indicate a RAM parity error as well, so it is not a random NMI. Have you checked your BIOS' event log? You may also want to try running with machine checks enabled (hw.mca.enabled=1 in loader.conf, but it would have to be on very recent 7/8- stable) to see if you get machine checks for ECC errors. OTOH, if you do not have ECC memory then this will probably not help. To verify if I have errors in my RAM I let run sysutils/memtest86+ overnight, to double verify I also executed Windows Memory Diagnostic test for four times. None of them reported errors. Can anyone here suggest any solution. You can still have bad RAM even if those do not fail. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update(8) under sparc64? Why is it not available?
On Friday 26 March 2010 11:00:28 am Colin Percival wrote: I think the best approach towards having FreeBSD Update support for sparc64 is to get release cross-building working; that way we would be able to use amd64 hardware, which I think we can safely assume will continue to be available in ever-increasing speeds. Err, release cross-building does work AFAIK. ru@ worked on it many years ago. Have you tried it and run into problems? -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: random FreeBSD panics
On Monday 29 March 2010 1:30:38 pm Jeremy Chadwick wrote: On Mon, Mar 29, 2010 at 05:01:02PM +, Masoom Shaikh wrote: On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras ivo...@freebsd.org wrote: On 28 March 2010 16:42, Masoom Shaikh masoom.sha...@gmail.com wrote: lets assume if this is h/w problem, then how can other OSes overcome this ? is there a way to make FreeBSD ignore this as well, let it result in reasonable performance penalty. Very probably, if only we could detect where the problem is. Try adding options PRINTF_BUFR_SIZE=128 to the kernel this option is already there The key word in Ivan's phrase is less mangled. Neither use of or increasing PRINTF_BUFR_SIZE solves the problem of interspersed console output. I've been ranting/raving about this problem for years now; it truly looks like a mutex lock issue (or lack of such lock), but I've been told numerous times that isn't the case. To developers: what incentives would help get this issue well-needed attention? This problem makes kernel debugging, panic analysis, and other console-oriented viewing basically impossible. I was recently going to look at it. The somewhat drastic approach I was going to take was to add a simple serializing lock around trap_fatal() and a few other places that do similar block prints (e.g. mca_log()). One of the issues with fixing this in printf itself is that you'd want probably want to serialize complete lines of text on a per-thread basis. You would want to be able to accumulate this line of text across multiple calls to printf (think of it as line-buffering ala stdio). However, some folks may be nervous about printf not printing things immediately. The other issue is that lots of code assumes it can call printf from anywhere and everywhere. Mostly this just means that if you add locking and line- buffering to printf(9) you have to be very careful to make sure it works in odd places. Probably a lot of this could be solved by deferring things like trap_fatal() until panic() has already been called (which is bde's preferred solution I think). -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD NFS client goes into infinite retry loop
On Tuesday 23 March 2010 7:03:06 pm Rick Macklem wrote: On Tue, 23 Mar 2010, John Baldwin wrote: Ah, I had read that patch as being a temporary testing hack. If you think that would be a good approach in general that would be ok with me. Well, it kinda was. I wasn't betting on it fixing the problem, but since it does... I think just mapping VFS_FHTOVP() errors to ESTALE is ok. Do you think I should ask pjd@ about it or just go ahead with a commit? Go ahead and fix it I think. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD NFS client goes into infinite retry loop
On Monday 22 March 2010 7:53:23 pm Rick Macklem wrote: That I have no idea on. Maybe Rick can chime in? I'm actually not sure why we would want to treat a FHTOVP failure as anything but an ESTALE error in the NFS server to be honest. As far as I know, only if the underlying file system somehow has a situation where the file handle can't be translated at that point in time, but could be able to later. I have no idea if any file system is like that and I don't such a file system would be an appropriate choice for an NFS server, even if such a beast exists. (Even then, although FreeBSD's client assumes EIO might recover on a retry, that isn't specified in any RFC, as far as I know.) That's why I proposed a patch that simply translates all VFS_FHTOVP() errors to ESTALE in the NFS server. (It seems simpler than chasing down cases in all the underlying file systems?) Ah, I had read that patch as being a temporary testing hack. If you think that would be a good approach in general that would be ok with me. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD NFS client goes into infinite retry loop
On Friday 19 March 2010 11:27:13 pm Rick Macklem wrote: On Fri, 19 Mar 2010, Steve Polyack wrote: [good stuff snipped] This makes sense. According to wireshark, the server is indeed transmitting Status: NFS3ERR_IO (5). Perhaps this should be STALE instead; it sounds more correct than marking it a general IO error. Also, the NFS server is serving its share off of a ZFS filesystem, if it makes any difference. I suppose ZFS could be talking to the NFS server threads with some mismatched language, but I doubt it. Ok, now I think we're making progress. If VFS_FHTOVP() doesn't return ESTALE when the file no longer exists, the NFS server returns whatever error it has returned. So, either VFS_FHTOVP() succeeds after the file has been deleted, which would be a problem that needs to be fixed within ZFS OR ZFS returns an error other than ESTALE when it doesn't exist. Try the following patch on the server (which just makes any error returned by VFS_FHTOVP() into ESTALE) and see if that helps. --- nfsserver/nfs_srvsubs.c.sav 2010-03-19 22:06:43.0 -0400 +++ nfsserver/nfs_srvsubs.c 2010-03-19 22:07:22.0 -0400 @@ -1127,6 +1127,8 @@ } } error = VFS_FHTOVP(mp, fhp-fh_fid, vpp); + if (error != 0) + error = ESTALE; vfs_unbusy(mp); if (error) goto out; Please let me know if the patch helps, rick I can confirm that ZFS's FHTOVP() method never returns ESTALE. Perhaps this patch would fix it? It changes zfs_fhtovp() to return ESTALE if the generation count doesn't match. If this doesn't help, you can try changing some of the other return cases in this function to ESTALE (many use EINVAL) until you find the one that matches this condition. Index: zfs_vfsops.c === --- zfs_vfsops.c(revision 205334) +++ zfs_vfsops.c(working copy) @@ -1256,7 +1256,7 @@ dprintf(znode gen (%u) != fid gen (%u)\n, zp_gen, fid_gen); VN_RELE(ZTOV(zp)); ZFS_EXIT(zfsvfs); - return (EINVAL); + return (ESTALE); } *vpp = ZTOV(zp); -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD NFS client goes into infinite retry loop
On Monday 22 March 2010 11:47:43 am Steve Polyack wrote:
On 03/22/10 10:52, Steve Polyack wrote:
On 3/19/2010 11:27 PM, Rick Macklem wrote:
On Fri, 19 Mar 2010, Steve Polyack wrote:
[good stuff snipped]
This makes sense. According to wireshark, the server is indeed
transmitting Status: NFS3ERR_IO (5). Perhaps this should be STALE
instead; it sounds more correct than marking it a general IO error.
Also, the NFS server is serving its share off of a ZFS filesystem,
if it makes any difference. I suppose ZFS could be talking to the
NFS server threads with some mismatched language, but I doubt it.
Ok, now I think we're making progress. If VFS_FHTOVP() doesn't return
ESTALE when the file no longer exists, the NFS server returns whatever
error it has returned.
So, either VFS_FHTOVP() succeeds after the file has been deleted, which
would be a problem that needs to be fixed within ZFS
OR
ZFS returns an error other than ESTALE when it doesn't exist.
Try the following patch on the server (which just makes any error
returned by VFS_FHTOVP() into ESTALE) and see if that helps.
--- nfsserver/nfs_srvsubs.c.sav2010-03-19 22:06:43.0 -0400
+++ nfsserver/nfs_srvsubs.c2010-03-19 22:07:22.0 -0400
@@ -1127,6 +1127,8 @@
}
}
error = VFS_FHTOVP(mp, fhp-fh_fid, vpp);
+if (error != 0)
+error = ESTALE;
vfs_unbusy(mp);
if (error)
goto out;
Please let me know if the patch helps, rick
The patch seems to fix the bad behavior. Running with the patch, I
see the following output from my patch (return code of nfs_doio from
within nfsiod):
nfssvc_iod: iod 0 nfs_doio returned errno: 70
Furthermore, when inspecting the transaction with Wireshark, after
deleting the file on the NFS server it looks like there is only a
single error. This time there it is a reply to a V3 Lookup call that
contains a status of NFS3ERR_NOENT (2) coming from the NFS server.
The client also does not repeatedly try to complete the failed request.
Any suggestions on the next step here? Based on what you said it
looks like ZFS is falsely reporting an IO error to VFS instead of
ESTALE / NOENT. I tried looking around zfs_fhtovp() and only saw
returns of EINVAL, but I'm not even sure I'm looking in the right place.
Further on down the rabbit hole... here's the piece in zfs_fhtovp()
where it's kicking out EINVAL instead of ESTALE - the following patch
corrects the behavior, but of course also suggests further digging
within the zfs_zget() function to ensure that _it_ is returning the
correct thing and whether or not it needs to be handled there or within
zfs_fhtovp().
---
src-orig/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
2010-03-22 11:41:21.0 -0400
+++ src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
2010-03-22 16:25:21.0 -0400
@@ -1246,7 +1246,7 @@
dprintf(getting %llu [%u mask %llx]\n, object, fid_gen, gen_mask);
if (err = zfs_zget(zfsvfs, object, zp)) {
ZFS_EXIT(zfsvfs);
-return (err);
+return (ESTALE);
}
zp_gen = zp-z_phys-zp_gen gen_mask;
if (zp_gen == 0)
So the odd thing here is that ffs_fhtovp() doesn't return ESTALE if VFS_VGET()
(which calls ffs_vget()) fails, it only returns ESTALE if the generation count
doesn't matter.
--
John Baldwin
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD NFS client goes into infinite retry loop
On Monday 22 March 2010 12:44:04 pm Steve Polyack wrote:
On 03/22/10 12:00, John Baldwin wrote:
On Monday 22 March 2010 11:47:43 am Steve Polyack wrote:
On 03/22/10 10:52, Steve Polyack wrote:
On 3/19/2010 11:27 PM, Rick Macklem wrote:
On Fri, 19 Mar 2010, Steve Polyack wrote:
[good stuff snipped]
This makes sense. According to wireshark, the server is indeed
transmitting Status: NFS3ERR_IO (5). Perhaps this should be STALE
instead; it sounds more correct than marking it a general IO error.
Also, the NFS server is serving its share off of a ZFS filesystem,
if it makes any difference. I suppose ZFS could be talking to the
NFS server threads with some mismatched language, but I doubt it.
Ok, now I think we're making progress. If VFS_FHTOVP() doesn't return
ESTALE when the file no longer exists, the NFS server returns whatever
error it has returned.
So, either VFS_FHTOVP() succeeds after the file has been deleted, which
would be a problem that needs to be fixed within ZFS
OR
ZFS returns an error other than ESTALE when it doesn't exist.
Try the following patch on the server (which just makes any error
returned by VFS_FHTOVP() into ESTALE) and see if that helps.
--- nfsserver/nfs_srvsubs.c.sav2010-03-19 22:06:43.0 -0400
+++ nfsserver/nfs_srvsubs.c2010-03-19 22:07:22.0 -0400
@@ -1127,6 +1127,8 @@
}
}
error = VFS_FHTOVP(mp,fhp-fh_fid, vpp);
+if (error != 0)
+error = ESTALE;
vfs_unbusy(mp);
if (error)
goto out;
Please let me know if the patch helps, rick
The patch seems to fix the bad behavior. Running with the patch, I
see the following output from my patch (return code of nfs_doio from
within nfsiod):
nfssvc_iod: iod 0 nfs_doio returned errno: 70
Furthermore, when inspecting the transaction with Wireshark, after
deleting the file on the NFS server it looks like there is only a
single error. This time there it is a reply to a V3 Lookup call that
contains a status of NFS3ERR_NOENT (2) coming from the NFS server.
The client also does not repeatedly try to complete the failed request.
Any suggestions on the next step here? Based on what you said it
looks like ZFS is falsely reporting an IO error to VFS instead of
ESTALE / NOENT. I tried looking around zfs_fhtovp() and only saw
returns of EINVAL, but I'm not even sure I'm looking in the right place.
Further on down the rabbit hole... here's the piece in zfs_fhtovp()
where it's kicking out EINVAL instead of ESTALE - the following patch
corrects the behavior, but of course also suggests further digging
within the zfs_zget() function to ensure that _it_ is returning the
correct thing and whether or not it needs to be handled there or within
zfs_fhtovp().
---
src-orig/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
2010-03-22 11:41:21.0 -0400
+++ src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
2010-03-22 16:25:21.0 -0400
@@ -1246,7 +1246,7 @@
dprintf(getting %llu [%u mask %llx]\n, object, fid_gen,
gen_mask);
if (err = zfs_zget(zfsvfs, object,zp)) {
ZFS_EXIT(zfsvfs);
-return (err);
+return (ESTALE);
}
zp_gen = zp-z_phys-zp_gen gen_mask;
if (zp_gen == 0)
So the odd thing here is that ffs_fhtovp() doesn't return ESTALE if
VFS_VGET()
(which calls ffs_vget()) fails, it only returns ESTALE if the generation
count
doesn't matter.
It looks like it also returns ESTALE when the inode is invalid (
ROOTINO || max inodes?) - would an unlinked file in FFS referenced at
a later time report an invalid inode?
But back to your point, zfs_zget() seems to be failing and returning the
EINVAL before zfs_fhtovp() even has a chance to set and check zp_gen.
I'm trying to get some more details through the use of gratuitous
dprintf()'s, but they don't seem to be making it to any logs or the
console even with vfs.zfs.debug=1 set. Any pointers on how to get these
dprintf() calls working?
That I have no idea on. Maybe Rick can chime in? I'm actually not sure why
we would want to treat a FHTOVP failure as anything but an ESTALE error in the
NFS server to be honest.
--
John Baldwin
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD NFS client goes into infinite retry loop
On Friday 19 March 2010 7:34:23 am Steve Polyack wrote: Hi, we use a FreeBSD 8-STABLE (from shortly after release) system as an NFS server to provide user home directories which get mounted across a few machines (all 6.3-RELEASE). For the past few weeks we have been running into problems where one particular client will go into an infinite loop where it is repeatedly trying to write data which causes the NFS server to return reply ok 40 write ERROR: Input/output error PRE: POST:. This retry loop can cause between 20mbps and 500mbps of constant traffic on our network, depending on the size of the data associated with the failed write. We spent some time on the issue and determined that something on one of the clients is deleting a file as it is being written to by another NFS client. We were able to enable the NFS lockmgr and use lockf(1) to fix most of these conditions, and the frequency of this problem has dropped from once a night to once a week. However, it's still a problem and we can't necessarily force all of our users to play nice and use lockf/flock. Has anyone seen this before? No errors are being logged on the NFS server itself, but the Server Ret-Failed counter begins to increase rapidly whenever a client gets stuck in this infinite retry loop: Server Ret-Failed 224768961 I have a feeling that using NFS in such a matter may simply be prone to such problems, but what confuses me is why the NFS client system is infinitely retrying the write operation and causing itself so much grief. Yes, your feeling is correct. This sort of race is inherent to NFS if you do not use some sort of locking protocol to resolve the race. The infinite retries sound like a client-side issue. Have you been able to try a newer OS version on a client to see if it still causes the same behavior? -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Automated kernel crash reporting system
On Thursday 04 March 2010 8:50:56 am sean connolly wrote: Hi Dan, Automatic reporting would end up being a mess given that panics can be caused by hardware problems. Having an autoreport check if memtest was run before it reports, or having it only run with -CURRENTmight be useful. That's not quite true. Many hardware failure-type panics look the same (a machine check exception panic, an NMI due to a hardware error (this has a unique panic message), or panics in pmap_remove*() on x86 cover the vast majority of them). My previous employer actually did track panics using a script like crashinfo, and I was able to categorize known panics by looking for signatures in stack backtraces or other panic messages. From: jhell jh...@dataix.net To: Dan Naumov dan.nau...@gmail.com Cc: FreeBSD Hackers freebsd-hack...@freebsd.org; freebsd- questi...@freebsd.org Sent: Thu, March 4, 2010 8:06:50 AM Subject: Re: Automated kernel crash reporting system On Thu, 4 Mar 2010 07:09, dan.naumov@ wrote: Hello I noticed the following on the FreeBSD website: http://www.freebsd.org/projects/ideas/ideas.html#p-autoreport Has there been any progress/work done on the automated kernel crash reporting system? The current ways of enabling and gathering the information required by developers for investigating panics and similar issues are unintuitive and user-hostile to say the least and anything to automate the process would be a very welcome addition. - Sincerely, Dan Naumov Hi Dan, I am assuming that the output of crashinfo_enable=YES is not what you are talking about is it ? are you aware of it ? The info contained in the crashinfo.txt.N is pretty informative for developers, maybe your talking about another way of submitting it ? Regards, -- jhell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: 8.0 on new hardware and a few errors, should I be worried?
On Saturday 27 February 2010 8:28:48 pm Dan Naumov wrote: Hello I've very recently finished installing 8.0-RELEASE on some new hardware and I noticed a few error messages that make me a bit uneasy. This is a snip from my dmesg: -- acpi0: SMCI on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bf60 (3) failed -- What do these mean and should I worry about it? The full DMESG can be viewed here: http://jago.pp.fi/temp/dmesg.txt You can ignore them. FreeBSD creates two psuedo-devices on x86 called apic0 and ram0. Their sole job is to reserve the memory ranges used by APIC devices and system RAM to prevent those address ranges being reused by anything else (such as PCI BARs). Many systems also reserve those ranges as a system resource via ACPI (or PnPBIOS for the non-ACPI case). What is happening is that the ACPI system resource driver isn't able to reserve these ranges because they are already claimed by apic0 and ram0. The important point is that some device claims them. It doesn't really matter which one does. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: booting off GPT partitions
On Thursday 28 January 2010 7:26:24 am Dimitry Andric wrote: On 2010-01-28 13:06, Robert Noland wrote: John or Marcel can correct me, but I don't think that this is an issue. The bootstrap is located in the pmbr in sector 0 and the GPT headers and tables are in sectors 1 - 34. The bootstrap code knows how to read the GPT tables and can deal with 2 tb lba's. Ah yes, I see it now. It uses EDD packets with the BIOS int 13 interface, which apparently have a 64-bit LBA. This should support up to 8 ZiB with 512-byte sectors... OTOH, I have no idea how well most BIOSes actually implement this. Since many OSes simply don't support anything over 2^32 sectors, I would not be amazed to find much BIOSes out there that behave the same. Or am I too paranoid now? :) It should work fine. The GPT boot code was originally written specifically to supporting booting from RAID volumes 2TB. I've tested it on mfi(4) volumes that large (though I didn't verify the individual LBAs of all the various bits read in by the bootstrap and loader were). I know that other folks ran into bugs until the ZFS GPT boot code was all made 64-bit clean and that they have since booted 2TB ZFS volumes ok. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: booting off GPT partitions
On Wednesday 27 January 2010 11:45:36 am Dan Naumov wrote: Hey I was under the impression that everyone and their dog is using GPT partitioning in FreeBSD these days, including for boot drives and that I was just being unlucky with my current NAS motherboard (Intel D945GCLF2) having supposedly shaky support for GPT boot. But right now I am having an email exchange with Supermicro support (whom I contacted since I am pondering their X7SPA-H board for a new system), who are telling me that booting off GPT requires UEFI BIOS, which is supposedly a very new thing and that for example NONE of their current motherboards have support for this. Am I misunderstanding something or is the Supermicro support tech misguided? GPT was defined along with EFI, so many folks assume that you have to use EFI to boot a GPT-labelled disk. However, FreeBSD has its own BIOS-based bootstrap that can handle GPT-labelled disks. I doubt the SuperMicro tech is familiar with that case. I thought I heard that some folks had added GPT support to grub as well. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: GPT Support on Freebsd
On Wednesday 29 October 2008 06:20:15 pm Franck wrote: 2008/10/29 John Baldwin [EMAIL PROTECTED]: On Wednesday 29 October 2008 05:39:27 pm Franck wrote: Hi, Thank you for help. I provide you the maximum information about my partitions. Before, I watch the kernel configuration. When I fetch the kernel sources, I can see 2 differents configuration files : DEFAULTS and GENERIC. and the line : options GEOM_PART_GPT is present only in GENERIC. If I use my knowledge in linux systems, I would say that my actual kernel was compiled with the DEFAULTS conf, which doesn't enable the support of GPT for GEOM. Maybe I'm wrong, my knew kernel is compiling... The install kernel from the CD is GENERIC. So only if you've built a custom I apologize, I didn't watch in the handbook for this kernel would you not have GPT support. It seems that the kernel does find the GPT table, but gets confused by it. Can you get the output of 'fdisk ad0' and 'gpt show ad0'? fdisk ad0 : *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=387621 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=387621 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 409639 (200 Meg), flag 0 beg: cyl 1023/ head 254/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 175 (0xaf),(HFS+) start 409640, size 37486592 (18304 Meg), flag 0 beg: cyl 1023/ head 254/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 131 (0x83),(Linux native) start 37897335, size 401625 (196 Meg), flag 80 (active) beg: cyl 1023/ head 254/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 38298960, size 38908800 (18998 Meg), flag 0 beg: cyl 107/ head 0/ sector 1; end: cyl 818/ head 15/ sector 63 Ok, so it's not a PMBR. My understanding is that a GPT requires the MBR to be a PMBR (only one partition in the 4th slot with a special type of 0xee that covers the whole disk). What this box is doing is trying to make the MBR match the first 4 partitions in the GPT. I'm not sure if you will be able to get FreeBSD's GPT stuff to recognize that reliably. Marcel (cc'd) might have some ideas. If you can get FreeBSD's GPT support to handle this disk it will mean that you will have to use only GPT device names (so /dev/ad0p4a instead of /dev/ad0s4a). You will also need to make sure the GPT partition for FreeBSD has the right UUID since your partition contains a BSD label. [EMAIL PROTECTED] ~]$ sudo gpt show ad0 gpt show: unable to open device 'ad0': Operation not permitted Normally with GPT you don't put a BSD label inside a GPT partition, so you wouldn't have /dev/ad0p4a, but instead would use a separate GPT partition for each filesystem/swap/etc. The fstab from my laptop (not a macbook) looks like this: # DeviceMountpoint FStype Options Dump Pass# /dev/ad0p3 noneswapsw 0 0 /dev/ad0p2 / ufs rw 1 1 /dev/ad0p5 /tmpufs rw 2 2 /dev/ad0p6 /usrufs rw 2 2 /dev/ad0p4 /varufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 Are you booting using boot camp or parallels or some such? Yes, I think It's the problem. Actually I have a Leopard Mac OS X System. And it seems to automatically switch on the bootcamp feature when I tried to install pcbsd. That's weird because I haven't any problems to see the gpt table when I boot from a ubuntu cd for example. If I well remember, I was obliged to install pcbsd in one of the four first parititions. I'll reboot on the pcbsd cd to see if I can access to all the partitions. I realize that's must be efi/refit/bootcamp which mess up all. And I don't how to fix that. Thank you, Franck On Freebsd : [EMAIL PROTECTED] /usr/home/Dante]$ ls /dev/|grep ^ad ad0 ad0s2 ad0s3 ad0s4 ad0s4a ad0s4b ad0s4c my dmesg : http://pastebin.com/m7b5f130e On Gentoo : [EMAIL PROTECTED]:~ % LANG=C sudo parted /dev/sda GNU Parted 1.8.8 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: ATA ST9200420ASG (scsi) Disk /dev/sda: 200GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End
Re: GPT Support on Freebsd
On Wednesday 29 October 2008 07:42:18 am Lowell Gilbert wrote: Franck Royer [EMAIL PROTECTED] writes: Can I oblige pcbsd to look the gpt table instead of the msdos one ? How can I access to my fifth partition ? John Baldwin (jhb) has been working on GPT support, but it's still reported to be a work in progress. It works as far as recognizing disks over 16TB. It also gets picked up by the geom framework. I'm not sure about booting, although there are tantalizing hints in the manual pages. GPT booting works just fine on 6.x and later. Using the gpt(8) utility you basically do: # gpt create foo0 # gpt boot foo0 The second command creates a special boot partition in /dev/foo0p1. You can then add partitions: # gpt add -t ufs other params like size if needed foo0 # newfs /dev/foo0p2 gpart(8) in HEAD works similarly. The one thing lacking is that sysinstall/libdisk doesn't handle GPT, so there isn't a nice way to do it during installation. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT Support on Freebsd
On Wednesday 29 October 2008 11:52:19 am Franck Royer wrote: John Baldwin a écrit : On Wednesday 29 October 2008 07:42:18 am Lowell Gilbert wrote: Franck Royer [EMAIL PROTECTED] writes: Can I oblige pcbsd to look the gpt table instead of the msdos one ? How can I access to my fifth partition ? John Baldwin (jhb) has been working on GPT support, but it's still reported to be a work in progress. It works as far as recognizing disks over 16TB. It also gets picked up by the geom framework. I'm not sure about booting, although there are tantalizing hints in the manual pages. GPT booting works just fine on 6.x and later. Using the gpt(8) utility you basically do: # gpt create foo0 # gpt boot foo0 The second command creates a special boot partition in /dev/foo0p1. You can then add partitions: # gpt add -t ufs other params like size if needed foo0 # newfs /dev/foo0p2 gpart(8) in HEAD works similarly. The one thing lacking is that sysinstall/libdisk doesn't handle GPT, so there isn't a nice way to do it during installation. Ok thank you. But actually, it's not what I'm looking for. I use freebsd on a macbook. On this macbook, I already have a gpt, refit, mac os x and some linux partitions. The problem is freebsd, which doesn't recognize partitions after the fourth one (but my gentoo linux see them). Then, I suppose freebsd use the mbr partition table (synchronized from the gpt one using refit) to populate the /dev, but partitions after the fourth, which are those I want to use, are only indexed in the gpt. Finally, I want to force freebsd to use the gpt on my hard drive to allow it to see others partitions. I don't want to destroy my actual gpt, maybe one day, but no right now. Tell me if my english is too bad to be understood. I just want to precise that I use pcvbsd 7.0, so the kernel configuration might be different than the freebsd generic one. What device entries do you see in /dev? -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault while in kernel mode
On Monday 20 October 2008 08:52:07 pm Robert Fitzpatrick wrote: On Mon, 2008-10-20 at 13:45 -0400, John Baldwin wrote: i386 cannot address more than 4GB unless the kernel is built with PAE mode enabled. This isn't enabled in GENERIC for many (justified) reasons. If you have more than 4GB, you should be using amd64, so you made the right decision there. If you aren't using kernel modules, then PAE should work fine. You can make kernel modules work with PAE as well, but that takes more work. Thanks for the help, I am missing AMD Features for this CPU in dmesg, so it looks like the CPU does not support amd64. I tried to build my own kernel with PAE option and getting the following error... /usr/src/sys/dev/advansys/advansys.c: In function 'adv_action': /usr/src/sys/dev/advansys/advansys.c:259: warning: cast from pointer to integer of different size *** Error code 1 Any idea what I can do for this error? Some drivers don't work with PAE (see all the 'nodevice' lines in /sys/i386/conf/PAE). You'll need to purge those drivers from your config. If you are using the hardware those drivers support, then you can't use PAE. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault while in kernel mode
On Tuesday 21 October 2008 02:47:11 pm Jeremy Chadwick wrote: On Tue, Oct 21, 2008 at 02:35:22PM -0400, Robert Fitzpatrick wrote: On Tue, 2008-10-21 at 12:03 -0400, John Baldwin wrote: Some drivers don't work with PAE (see all the 'nodevice' lines in /sys/i386/conf/PAE). You'll need to purge those drivers from your config. If you are using the hardware those drivers support, then you can't use PAE. Thanks for the help. Excuse the ignorance, I'm more a programmer than system guy. How do I purge a driver, or know which driver to look for, from the config and know what the driver supports? Do you mean, in this case, remove 'nodevice adv' from the PAE file? If so, I don't know what that supports :/ Yeah, I don't think anyone's really explaining this very well to you, so I'll try a different approach: Certain FreeBSD drivers do not work in PAE mode. The drivers which don't work are listed in the /sys/i386/conf/PAE file. They're prefixed by the word nodevice, which tells the kernel config reader DO NOT build this device, because it won't work. You will need to take the nodevice lines from /sys/i386/conf/PAE and put them into your kernel config file. (There are alternative methods such as using include directives and so on, but I'm trying to keep this explanation simple.) Make sense now? :-) Alternatively, you could just remove the 'device adv' line from your kernel config rather than adding lots of 'nodevice' lines at the bottom. You can usually do 'man 4 driver name' to see what devices it supports. In this case, adv(4) supports mostly ancient Advansys SCSI host adapters. The manpage has a full list of the various model numbers, etc. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault while in kernel mode
On Tuesday 21 October 2008 03:22:28 pm Robert Fitzpatrick wrote: On Tue, 2008-10-21 at 15:09 -0400, John Baldwin wrote: Alternatively, you could just remove the 'device adv' line from your kernel config rather than adding lots of 'nodevice' lines at the bottom. You can usually do 'man 4 driver name' to see what devices it supports. In this case, adv(4) supports mostly ancient Advansys SCSI host adapters. The manpage has a full list of the various model numbers, etc. Yes, that is what I thought. Right now, I am just commenting them out, now I know what people mean when they say they are running a trimmed/clean kernel. I did see one potential issue... # USB support device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device ehci# EHCI PCI-USB interface (USB 2.0) device usb # USB Bus (required) I see all of these with nodevice lines in the PAE file. Although I have USB ports, I don't use them, but I was concerned by the 'required' on the last one, is it OK to remove? Also, would I then need to disable USB in the BIOS to avoid errors? Actually, USB is ok with PAE. I recently updated the PAE configs to not disable PAE and at work we've run PAE kernels with USB enabled for a few years now on 6.x w/o any problems. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault while in kernel mode
On Monday 20 October 2008 12:32:37 pm Jeremy Chadwick wrote: Forgot to mention I added memory to this server as well, took it from 2GB it was using under 5.4-RELEASE up to 6GB filling all slots, that is why I wanted to load amd64. I reduced down to 4GB and now am able to install 7.0-RELEASE i386. Does this mean that I may have a hardware issue or can FreeBSD produce the page fault I was getting when using over 4GB with i386? i386 cannot address more than 4GB unless the kernel is built with PAE mode enabled. This isn't enabled in GENERIC for many (justified) reasons. If you have more than 4GB, you should be using amd64, so you made the right decision there. If you aren't using kernel modules, then PAE should work fine. You can make kernel modules work with PAE as well, but that takes more work. I would love to figure out this BTX halted issue instead...any ideas on that? Boot loader problems are difficult to figure out/debug for reasons which should be obvious. I'm CC'ing John Baldwin here, who has experience with BTX. He might be able to shed some light on this. You will get a BTX fault in 7.0 if your CPU does not support 64-bit long mode (i.e., amd64). You can check to see if your CPU does support it by looking in the 'AMD features' line of 'dmesg' from an i386 kernel and seeing if you have a 'LM' feature. If you don't, your CPU only supports i386. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7 and ESXi
On Tuesday 14 October 2008 08:20:22 am [EMAIL PROTECTED] wrote: Jeremy, On Mon, 13 Oct 2008, Jeremy Chadwick wrote: |On Tue, Oct 14, 2008 at 02:44:13AM -0300, [EMAIL PROTECTED] wrote: | On Mon, 13 Oct 2008, Jeremy Chadwick wrote: | | |On Tue, Oct 14, 2008 at 02:04:07AM -0300, [EMAIL PROTECTED] wrote: | | Jeremy, | | | | On Mon, 13 Oct 2008, Jeremy Chadwick wrote: | | | | |On Tue, Oct 14, 2008 at 12:54:26AM -0300, [EMAIL PROTECTED] wrote: | | | I'm facing some problems trying to install a FreeBSD | | | 7.0-RELEASE-amd64, on a Dell PE 2950III, dual Xeon Quad core, 8GB RAM. | | | After (FBSD) boot menu count down, it shows a dump of the CPU | | | registers and a message: BTX Halted. No matter what is changed in VM | | | setup. | | | | | |Can you please download the 7.1-BETA2 ISO and try it instead? There | | |have been changes to the FreeBSD boot loader between 7.0-RELEASE and | | |7.1-BETA2 which may improve things for you. The 7.1-BETA2 ISOs are | | |available here: | | | | The same behavior with 7.1-BETA2. | | | |I'm not sure what to do at this point, or what to tell you, since the | |kernel can't even load. | | | |Are you installing this off of CD, and is the CD drive hooked up to | |the PC via ATA/SATA (rather than USB or something else)? | |It's a bit more complicated, since, for some reason the Vmware | client is unable to boot the VM from CD on the host server. It's | booting an ISO image on the client machine. |I already read something saying that it's a known issue of the | ESXi. |Without the virtulization layer, the amd64 CD boots without | problems in this machine. | |Ah, so the truth comes out... :-) | |Have you brought this fact up with the VMware folks? They're quite a |nice bunch, I wouldn't be surprised if they provided a hotfix for you |for this problem. This will be my next step. I sent here first, once it's a boot loader problem, specific to 64bits version of Fbsd. I thought someone could faced the same and came with a howto to workaround. Thank you anyway. :-) It sounds like vmware is not emulating 64-bit CPUs, but only 32-bit CPUs. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel profiling: spinlock_exit consumes 36% CPU time.
On Wednesday 08 October 2008 03:51:48 am 邱剑 wrote: Many thanks for the information. Could we say that interrupt handlers consumed ~36% execution time? Is this number too high? Is it possible that we abuse the use of critical sections in kernel? I think whether or not it is high depends on the workload. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel profiling: spinlock_exit consumes 36% CPU time.
On Tuesday 07 October 2008 07:44:00 am 邱剑 wrote: Hi, folks, I did kernel profiling when a single thread client sends UDP packets to a single thread server on the same machine. In the output kernel profile, the first few kernel functions that consumes the most CPU time are listed below: granularity: each sample hit covers 16 byte(s) for 0.01% of 25.68 seconds % cumulative self self total time seconds secondscalls ms/call ms/call name 42.4 10.8810.880 100.00% __mcount [1] 36.1 20.14 9.26 17937541 0.00 0.00 spinlock_exit [4] 4.2 21.22 1.08 3145728 0.00 0.00 in_cksum_skip [40] 1.8 21.68 0.45 7351987 0.00 0.00 generic_copyin [43] 1.1 21.96 0.29 3146028 0.00 0.00 generic_copyout [48] 1.0 22.21 0.24 2108904 0.00 0.00 Xint0x80_syscall [3] 0.8 22.42 0.21 6292131 0.00 0.00 uma_zalloc_arg [46] 0.8 22.62 0.20 1048576 0.00 0.00 soreceive_generic [9] It is very strange that spinlock_exit consumes over 36% CPU time while it seems a very simple function. It's because the intr_restore() re-enables interrupts and the resulting time spent executing the handlers for any pending interrupts are attributed to spinlock_exit(). -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: irq19 interrupt storm?
On Wednesday 17 September 2008 05:17:27 pm John Baldwin wrote: On Wednesday 17 September 2008 11:00:24 am Scott Gasch wrote: You're right: atapci1, atapci2, fwohci0 and uhci4 are all sharing the same irq (19) while irqs 20, 21, 22 at least seem completely unused. Here's a dumb question: how do I fix it? I tried setting plug and play OS in the BIOS and then using device.hints to push different devices to different irqs. But every time I tried a new hint it seemed to be ignored. I was trying stuff like: set hint.atapci.1.irq=20 set hint ata.4.irq=20 (ata4 is a channel on atapci1) set hint fwhco.0.irq=20 etc... I also tried to move the dc driver to a new irq as a test. This was also seemingly ignored. I then tried turning plug and play OS off in the BIOS but I don't see anywhere to set the IRQs of the onboard SATA controllers via the menus. I'm looking for a BIOS upgrade now... any other advice? Unfortunately you can't really move PCI IRQs around. You can read about more of the gritty details here: http://people.freebsd.org/~jhb/papers/bsdcan/2007/ You might be able to shuffle some IRQs around using 'hw.pciX.Y.INTA.irq' tunables. Gah, wrong tunables. These devices are on PCI link devices, so you'd need to do something like 'hw.pci.LNKA.irq' (where LNKA is the name of the link device in the ACPI namespace). Verbose boot messages (boot -v) can tell you which link device you PCI devices are using. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: irq19 interrupt storm?
On Wednesday 17 September 2008 11:00:24 am Scott Gasch wrote: You're right: atapci1, atapci2, fwohci0 and uhci4 are all sharing the same irq (19) while irqs 20, 21, 22 at least seem completely unused. Here's a dumb question: how do I fix it? I tried setting plug and play OS in the BIOS and then using device.hints to push different devices to different irqs. But every time I tried a new hint it seemed to be ignored. I was trying stuff like: set hint.atapci.1.irq=20 set hint ata.4.irq=20 (ata4 is a channel on atapci1) set hint fwhco.0.irq=20 etc... I also tried to move the dc driver to a new irq as a test. This was also seemingly ignored. I then tried turning plug and play OS off in the BIOS but I don't see anywhere to set the IRQs of the onboard SATA controllers via the menus. I'm looking for a BIOS upgrade now... any other advice? Unfortunately you can't really move PCI IRQs around. You can read about more of the gritty details here: http://people.freebsd.org/~jhb/papers/bsdcan/2007/ You might be able to shuffle some IRQs around using 'hw.pciX.Y.INTA.irq' tunables. Probably you have a device driver whose interrupt handler isn't handling some condition. I would suspect ata as it's interrupt handler is rather simplistic with no chipset-specific hooks, and I've seen several reports of interrupt storms with ata(4) recently. Thx, Scott On Tue, Sep 16, 2008 at 7:12 AM, Gary Jennejohn [EMAIL PROTECTED]wrote: On Mon, 15 Sep 2008 22:57:38 -0700 Scott Gasch [EMAIL PROTECTED] wrote: Hi, I'm running freebsd 7.0-RELEASE-p4 on a 4-core amd64 box. Nearly 100% of 1 cpu is constantly being used handling irq19: uhci4 interrupts. This seems to happen both with and without any USB devices plugged in: vmstat -i interrupt total rate irq1: atkbd0 5 0 irq6: fdc0 1 0 irq17: mskc0 dc0 1180547 18 irq18: skc0 uhci2* 163250699 2512 irq19: uhci4++ 3187989508 49072 I think the ++ here indicates that two or more devices are sharing this interrupt. Try doing grep irq.*19 /var/run/dmesg.boot to see which ones. One of these devices could be the culprit. --- Gary Jennejohn ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to [EMAIL PROTECTED] -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding device to FreeBSD 6.3-STABLE
On Friday 01 August 2008 12:13:41 pm John Nielsen wrote: On Friday 01 August 2008, Jack Raats wrote: I would like to add the zyd device to FreeBSD. The zyd driver allready is in FreeBSD 7.0. Which steps do I have to take to add the zyd device to FreeBSD? Sorry, what are you asking? What version of FreeBSD are you using and what do you need help doing? From the subject line, I imagine Jack is using 6.3-STABLE and wants to backport the driver from 7.0 to 6.3. Backporting most drivers from 7.0 to 6.x isn't a big deal (can generally just copy over and compile). However, zyd(4) is a wireless driver and the net80211 wireless networking stack is quite different in 6.x vs 7.0, so that is where it would be complicated to backport the driver. I'm not intimately familiar with net80211 in either branch, so I'm unsure how much work the backport would be. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to suspend/wake-up a FreeBSD machine?
On Friday 04 January 2008 03:13:20 am Ian Smith wrote: On Fri, 4 Jan 2008, Norberto Meijome wrote: On Sun, 30 Dec 2007 11:51:41 +0100 Henrik Brix Andersen [EMAIL PROTECTED] wrote: That depends largely on the hardware - on e.g. ThinkPads you need to press the 'Fn' button to wake up the laptop after sleep. hmm i think it's not so much the Fn key, u need to do anything that triggers an ACPI event in the BIOS - like opening the lid , or pressing Fn. I *think* 'thinkVantage' blue btn should work too. On my T23 I have suspend/wake on lid switch off (in BIOS), preferring to have to use the Fn key to wake. No other keys do that on mine including the ThinkPad key, so then called. While consulting 'sysctl hw.acpi' about that I see: hw.acpi.lid_switch_state: NONE which I assume reflects my don't-do-that BIOS setting. No, that's the FreeBSD default. And confirming: # sysctl hw.acpi.lid_switch_state=1 # (or =0) hw.acpi.lid_switch_state: NONE sysctl: hw.acpi.lid_switch_state: Invalid argument This is because this sysctl is not an on/off, but it takes an Sx state to suspend to when you close the lid. So if you set this to S1 it will try to enter S1 when you close the lid, etc. For example: sysctl hw.acpi.lid_switch_state=S3 Would make it enter S3 when you closed the lid. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found
On Wednesday 13 June 2007 06:32:42 pm Jin Guojun wrote: Umm, the amount of physical memory has no bearing on how the virtual address space for userland is laid out. Do you know what virtual memory is and how it works? Your first e-mail seems to contradict this paragraph as in your first e-mail you noted that the physical memory doesn't matter, the solution was to not raise MAXDSIZ higher than 1GB and that is consistent with running out of virtual address space due to MAXDSIZ reserving too much address space for malloc(). No quite clear on this. Does this mean that the MAXDSIZ cannot exceeed 1GB regardless how many physical memory (say 16 GB) is installed? Then, this is definitiely a software bug. Then, somewhere the following checking is needed: #if (MAXDSIZ 1024 * 1024 * 1024) #undef MAXDSIZ #define MAXDSIZ (1024 * 1024 * 1024) #endif It depends on the app. Some apps you can crank the malloc space up a whole lot. Also, if you are running FreeBSD/amd64 and running a 32-bit binary under freebsd32 emulation, then it has 4GB of VA space rather than 3GB, so you can give it more MAXDSIZ. It's really up to the user to only use a maxdsiz that works. You can also adjust the hard limit before exec'ing a process that needs a smaller dsize and leave MAXDSIZ larger for other processes. Since it is dependent on things the compiler can't know about at the build time of the kernel, we just let the user set it to whatever and if they set it too high things break until they lower it. You can even set this at boot time via 'kern.maxdsiz' tunable in the loader w/o needing to recompile. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found
On Tuesday 12 June 2007 09:20:02 pm Jin Guojun wrote: John Baldwin wrote: On Saturday 09 June 2007 08:53:18 pm Jin Guojun [VFFS] wrote: I believe that this is a memory sub-system bug somewhere because anything equal to or below 1G options MAXDSIZ=(1024*1024*1024) will work regardless how many memory is installed in the system. I doubt this could be a hardware related issue although is memory size related. Finally find cause but no idea why -- in kernel configuration, following line causes the problem: options MAXDSIZ=(2097152U*1024) Can anyone explain why this can cause /libexec/ld-elf.so.1 not seen for some program? This is setting aside 2GB for malloc which leaves only 1GB for all of mmap and stack. You probably don't have enough address space to map your binary. This does not quite explain the problem. First of all, the MAXDSIZ is the maximum size for users to set their own datasize limit by 'limit' utility. If user do not set a high limit for datasize, it should not be a problem. UTSL. By default proc0 gets a hard limit (lim_max vs lim_cur) of MAXDSIZ, and the max limit is what the ELF image activator in the kernel uses when figuring out where to mmap the runtime linker: /* * We load the dynamic linker where a userland call * to mmap(0, ...) would put it. The rationale behind this * calculation is that it leaves room for the heap to grow to * its maximum allowed size. */ addr = round_page((vm_offset_t)imgp-proc-p_vmspace-vm_daddr + lim_max(imgp-proc, RLIMIT_DATA)); The second aspect also counters this assumption, for machines that have less than or equal to 1 GB memory, and setting the MAXDISZ = the maximum memory size will not cause such problem. For example, if the physical memory size is 512 MB, and setting MAXDSIZ=(512*1024*1024) will not cause this problem. Or if the physical memory is 1GB, setting MAXDSIZ=(1024*1024*1024) will not cause the problem either. Umm, the amount of physical memory has no bearing on how the virtual address space for userland is laid out. Do you know what virtual memory is and how it works? Your first e-mail seems to contradict this paragraph as in your first e-mail you noted that the physical memory doesn't matter, the solution was to not raise MAXDSIZ higher than 1GB and that is consistent with running out of virtual address space due to MAXDSIZ reserving too much address space for malloc(). -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what causes error -- ELF interpreter /libexec/ld-elf.so.1 not found
On Saturday 09 June 2007 08:53:18 pm Jin Guojun [VFFS] wrote: I believe that this is a memory sub-system bug somewhere because anything equal to or below 1G options MAXDSIZ=(1024*1024*1024) will work regardless how many memory is installed in the system. I doubt this could be a hardware related issue although is memory size related. Finally find cause but no idea why -- in kernel configuration, following line causes the problem: options MAXDSIZ=(2097152U*1024) Can anyone explain why this can cause /libexec/ld-elf.so.1 not seen for some program? This is setting aside 2GB for malloc which leaves only 1GB for all of mmap and stack. You probably don't have enough address space to map your binary. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM / FreeBSD Install problem
On Thursday 19 April 2007 03:11:32 pm Dag-Erling Smørgrav wrote: Mark Tinguely [EMAIL PROTECTED] writes: I suggested that in email too, but looking closer, I think the MAXCPU needs to be increased because the cpu number uses the apic_id. Or could that be changed with a logical CPU to APIC ID lookup? Isn't the APIC IDs programmable? not that I am suggesting that, I can think of headaches of all the places (like interrupt tables) where it needs to be changed, not to mention the worry that the lower APIC IDs were assigned to IOAPICs. I don't know, you'd have to ask jhb@ about the details. APIC IDs are not programmable (well, they are on I/O APICs, but not local APICs). However, I am working on patches to support all valid APIC IDs for both mptable and MADT. Bumping up NLAPICS as a temporary workaround should suffice for now. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM / FreeBSD Install problem
On Monday 23 April 2007 02:51:19 pm Mark Tinguely wrote: John Baldwin [EMAIL PROTECTED] says: APIC IDs are not programmable (well, they are on I/O APICs, but not local=20 APICs). However, I am working on patches to support all valid APIC IDs for= =20 both mptable and MADT. Bumping up NLAPICS as a temporary workaround should= =20 suffice for now. =2D-=20 John Baldwin IMO, the quick solution also requires that MAX_APICID in [amd64/amd64 | i386/i386]/local_apic.c needs to be changed because lapic_create() checks if the passed apic_id MAX_APICID. Also in [amd64/amd64 | i386/i386]/mp_machdep.c checks in cpu_add() if the passed apic_id = MAXCPU. There are a couple other checks in mp_machdep.c before converting to use the cpu_apic_ids[] array. I was curious, and wrote up a patch file with the potential minor changes for -current at http://www.casselton.com/~tinguely/acpicid.patch . I saw one more change needed to use on FreeBSD 6.2-RELEASE. What I have so far is somewhat similar, but goes ahead and allows the full range of APIC IDs while trying to still honor MAXCPU correctly. I haven't ported it to i386 yet, nor compiled it yet, much less booted it. :) I hope to at least get it booted on amd64 today. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal trap 30: reserved (unknown) fault while in kernel mode
On Sunday 17 December 2006 23:17, Ma wrote: I'm using the newest FreeBSD 6.2-PRERELEASE on our web server (compiled at last friday, 06-12-15). But it always crashes these days. The following information displayed on the screen with system crashed. Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xc0b9bed1 stack pointer = 0x28:0xdc95fcd8 frame pointer = 0x28:0xdc95fcd8 code segment= base 0x0, limit oxf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflag = interrupt enabled, IOPL = 0 current process = 10 (idle: cpu1) trap number = 30 panic: reserved (unknown) fault cpuid = 1 uptime: 3m52s ahc0: WARNING no command for scb 79 (cmdcmplt) QOUTPOS = 235 You need to put 'ddb' in your kernel and run 'show lapic' and 'show apic' and provide a verbose dmesg. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LSI SAS adapter
[ cc's trimmed ] On Monday 09 October 2006 11:12, [EMAIL PROTECTED] wrote: Can anyone verify that the LSI0100 PCI-X SAS RAID card will work with 6.X-STABLE? The mfi driver says it supports LSI SAS MegaRAID, but this isn't in the MegaRAID family (only does RAID 0 and 1, and I only need 1). All experiences appreciated...please reply directly as I am not subscribed. The mpt(4) driver supports several of the LSI SAS HBA's (the ones that use the MPT/Fusion interface/firmware/whatever). I don't know if it specifically supports that adapter though as I can't find references to that specific adapter. If you had the PCI device ID that would be very helpful. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting problem
On Tuesday 27 June 2006 14:07, Winston wrote: I tried to boot via a serial console, so I modified/added the following config files: --- /boot/loader.conf: boot_multicons=YES boot_serial=YES console=comconsole --- /boot.config # wyt: added -Dh --- Changed /etc/ttys: ttyd0 /usr/libexec/getty std.9600 dialup off secure to ttyd0 /usr/libexec/getty std.9600 xterm on secure However, I got the following messages while booting: /boot.config: # FreeBSD/i386 boot Default: 0:ad(0,a)boot boot: I think I prob. made a mistake by putting a line of comment #wyt: added at the beginning of /boot.conf and the boot loader doesn't like it. But if I specify /boot/kernel/kernel after the line boot: I got a bunch of reg dumps and finally: BTX halted The kernel was booting fine before I make the changes. I now have the chicken and egg problem: I need to get rid of the line of comment in boot.conf for it to boot, but I can't access it without booting into it. Any hint? Use /boot/loader rather than /boot/kernel/kernel at the boot2 prompt. -- John Baldwin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get SIIG PCI serial card to work
On Friday 17 March 2006 03:40 am, Clayton Scott Kern wrote: on 03-16-2006, John Baldwin wrote: On Thursday 16 March 2006 05:24 pm, Clayton Scott Kern wrote: on 03-16-2006, John Baldwin wrote: Ok, can you get a dmesg from a boot with your custom kernel with puc in it and the output from kldstat -v with that kernel booted? Here's the info you requested. When not loading the puc module in /boot/loader.conf, the puc device isn't found, though pciconf -lv shows the device. I added the output of pciconf -lv at the end. Output of dmesg Copyright (c) 1992-2005 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 6.0-RELEASE-p5 #0: Sat Mar 11 12:12:08 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC This kernel doesn't have 'device puc' in it. If it did, it would have the 'pci/puc' and 'puc/sio' modules listed in the kldstat -v output. Make sure you have built a custom kernel with 'device puc' enabled, installed it, and are booting from it. Output of kldstat -v Id Refs AddressSize Name 1 11 0xc040 63072c kernel Contains modules: Id Name 26 xpt 27 probe 28 cam ... No puc this list tells me 'device puc' isn't in this kernel. :) Thank you for all your help. I thought I had built and installed the new kernel. This time I did both and now dmesg shows: puc0: Oxford Semiconductor OX16PCI954 UARTs port 0x9000-0x901f,0x9400-0x941f mem 0xe30 04000-0xe3004fff,0xe300-0xe3000fff irq 16 at device 8.0 on pci0 sio1: Oxford Semiconductor OX16PCI954 UARTs on puc0 sio1: type 16550A sio1: unable to activate interrupt in fast mode - using normal mode sio2: Oxford Semiconductor OX16PCI954 UARTs on puc0 sio2: type 16550A sio2: unable to activate interrupt in fast mode - using normal mode sio3: Oxford Semiconductor OX16PCI954 UARTs on puc0 sio3: type 16550A sio3: unable to activate interrupt in fast mode - using normal mode sio4: Oxford Semiconductor OX16PCI954 UARTs on puc0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode and kldstat -v | fgrep puc yields: 174 pccard/puc 175 pci/puc 176 cardbus/puc 187 puc/sio 337 puc/ppc Now when I run tip using sio1 - sio4 (aliases for /dev/cuad1-4), I get a message saying connected, but when I press enter, instead of getting my firewall's menu, I get nothing. I rebooted the system into Windoze and it works fine using TerraTerm Pro. You might need to play with stty to do things like -clocal or -crtscts to get it to work. stty -a /dev/cuad1 will tell you what the current settings are (IIRC). Also, what speed are you using in TerraTerm? 9600? Note that with cu you can specify the speed directly (e.g. cu -l /dev/cuad1 -s 115200). -- John Baldwin [EMAIL PROTECTED] http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get SIIG PCI serial card to work
On Thursday 16 March 2006 13:41, Clayton Scott Kern wrote: First, I added _device puc_ to my kernel config file and built and installed the new kernel. That should have given you a puc0 device, did it not? When that didn't work, I added _puc_load=YES_ to /boot/loader and now the card shows up as puc0, but no sioX. sio0 is used by the onboard serial port and is being used with an APC SmartUPS 700. This won't work as the puc module doesn't include sio_puc (the version of the sio driver that attaches to puc devices). Yes, this is somewhat lame as it means the puc module is basically useless. I'm not sure if this has been made better since 6.0. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get SIIG PCI serial card to work
On Thursday 16 March 2006 15:33, Clayton Scott Kern wrote: on 03-16-2006, John Baldwin wrote: On Thursday 16 March 2006 13:41, Clayton Scott Kern wrote: First, I added _device puc_ to my kernel config file and built and installed the new kernel. That should have given you a puc0 device, did it not? No it didn't. Ok, can you get a dmesg from a boot with your custom kernel with puc in it and the output from kldstat -v with that kernel booted? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get SIIG PCI serial card to work
On Thursday 16 March 2006 05:24 pm, Clayton Scott Kern wrote: on 03-16-2006, John Baldwin wrote: Ok, can you get a dmesg from a boot with your custom kernel with puc in it and the output from kldstat -v with that kernel booted? Here's the info you requested. When not loading the puc module in /boot/loader.conf, the puc device isn't found, though pciconf -lv shows the device. I added the output of pciconf -lv at the end. Output of dmesg Copyright (c) 1992-2005 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 6.0-RELEASE-p5 #0: Sat Mar 11 12:12:08 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC This kernel doesn't have 'device puc' in it. If it did, it would have the 'pci/puc' and 'puc/sio' modules listed in the kldstat -v output. Make sure you have built a custom kernel with 'device puc' enabled, installed it, and are booting from it. Output of kldstat -v Id Refs AddressSize Name 1 11 0xc040 63072c kernel Contains modules: Id Name 26 xpt 27 probe 28 cam ... No puc this list tells me 'device puc' isn't in this kernel. :) -- John Baldwin [EMAIL PROTECTED] http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rsh fails: [WAS] pvm connection problems
On Wednesday 30 November 2005 08:30 am, Vittorio De Martino wrote: Context: 2 pentium 4 boxes; freebsd 5.4 6.0 I detected that remote login via rsh doesn't work in my boxes: e.g. # rsh uffbsd uffbsd.myd.prv: Connection refused even though I've defined the trusted hosts on each box both in $HOME/.rhosts and in /etc/hosts.equiv. I've also uncommented the shell lines in /etc/inetd.conf to no avail. What should I do to enable the (mistrusted) rsh connection? Vittorio Do you have inetd enabled (inetd_enable=YES in /etc/rc.conf) and is it running? -- John Baldwin [EMAIL PROTECTED] http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bash scripting -- Usage of arrays
On Tuesday 29 November 2005 04:09 pm, Jayesh Jayan wrote: Hi, Today I was trying to script using arrays in FreeBSD 5.4 but it doesn't work. Below is a sample script which I used. ** #!/bin/bash array=( zero one two three four); echo Elements in array0: [EMAIL PROTECTED] ** It works fine on RedHat server. Below is the output. # sh array.sh Elements in array0: zero one two three four Below is the out put from the FreeBSD server using the same code. -bash-2.05b# sh aa.sh aa.sh: 3: Syntax error: word unexpected (expecting )) Please guide me on how to use arrays on freebsd too. sh != bash You can either install bash from ports, or you can write your scripts in sh without using bash extensions. For example, with sh you can do things like: array=zero one to three four for x in $array; do echo $x done However, you can't easily get the count of items. You could maybe do something like: set $array echo $# items but that's somewhat hackish. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bash scripting -- Usage of arrays
On Tuesday 29 November 2005 04:49 pm, Jayesh Jayan wrote: Hi John, I already have bash installed from ports. It is bash 2.05b. Then use 'bash foo.sh' :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HTT/SMP Dual Xeon systems unstable
On Friday 10 December 2004 09:32 am, [EMAIL PROTECTED] wrote: Hi, I'm sorry for typing this mail for the third time, I'm not sure if the other mails did reach the list. The domain I was using to send emails has just expired. Please cc me, as I'm not subscribed to the list with this email. I have a Dual Xeon 2.4 and a Dual Xeon 2.8 servers running with HyperThreading, ACPI, and SMP enabled. The 2.8 server won't stand for more than 5 days without crashing, and the 2.4 server was up 30 days crashed, now was up 12 days, and crashed. I didn't have a debugging kernel, I'll be building one when the datacenter reboots the server. I also don't have any panic messages.. I have, however, a few questions: - machdep.cpu_idle_hlt - I've seen a lot on google about this sysctl, but still don't fully understand it. What does this sysctl really changes? - HyperThreading - Do I really have a performance increase with HTT turned on? I've heard it can penalize performance because the scheduler isn't optimized for logical CPUs. Does having HTT enabled impacts the stability of the system? - ACPI - I'll be disabling ACPI along with HTT to see if the server doesn't crash for awhile. Is ACPI on 5.3-STABLE (around November 1st, it was pre-release) still a problem? Last but not the least, my 5.3-STABLE version is from a few days before the release. Since I had created a few jails by then, I didn't upgrade the system to use the -RELEASE. Was there any last-standing problem a few days before the release that could be causing my instability problems? Please share some common dual processor system knowledge, perhaps I'm missing something really obvious and making these servers unstable. There is a problem in the kernel that causes with 3 or more processors (including logical CPUs from HTT). Disabling HTT in the BIOS is probably your best bet as it will get you down to 2 CPUs which should work much better. HTT also isn't but so useful anyways for most workloads. The instability problems have just been fixed in HEAD and will hopefully be MFC'd for 5.4 btw. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2.1 kernel w/ SMP under high load = panic
On Sunday 01 August 2004 09:08 am, Hugo Silva wrote: I am running a Dual Xeon 2.8ghz w/ SMP, SCHED_ULE on FreeBSD 5.2.1-RELEASE-p9. Whenever I load the server a bit more (let [EMAIL PROTECTED] run, compile stuff in multiple jails, etc), it will simple go offline. I confirmed with the datacenter and it is indeed a panic, but the datacenter didn't give me the panic message. I know for *sure* it's because of the high loads. Hmm, we'd really need the panic message to even start debugging it. I need to sort this out, this is a powerful server being cut because of FreeBSD/SMP, and I know there is a kernel option to prevent the panic, I read about it ages ago on a forum. But I can't locate it. That user said if he disabled SMP, panics would stop. But another user suggested adding a kernel option (which I simply don't remember), and panics stopped, even with SMP. I tried KVA_PAGES=512, but it only caused another panic, this time as soon as the system started up.. syncing disks, buffers remaining... panic: pmap_invalidate_range: interrupts disabled cpuid = 0; boot() called on cpu#0 uptime: 9s Unfortunately, I'd really need the backtrace to see how to fix this panic. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Set boot loader to boot off CD manually
On 09-Dec-2003 Daniel Goepp wrote: Hi all, I was banging my head against the wall too long yesterday, so I have broken down, and have to ask. Any help on this matter is greatly appreciated. Here is what I'm trying to do. I have two computers, both running 4.8, clean, minimal installs. They have two serial cables connected to each other to act as serial consoles, and -Dh has been added to /boot.config, along with ttys having been updated. The console bit works great. What I want to be able to do, is completely rebuild one of the machines remotely. So I log into one, serial over to the other, and reboot it. Then, when the loader comes up, I stop it, and break to the ok prompt. I unload the kernel that was starting to load, and at this point, want to boot off CD, to rebuild the system, as though I had gone into the BIOS, and set the CD as the first boot device. However, I don't have remote access to the BIOS, so I can't do this. The BIOS does not provide a way to talk to the CD to read files off of it unless you boot from it. So, no, you can't boot from the hard drive and read files off the CD from the loader. However, you can copy the kernel and mfsroot off of the CD and stick them in /boot/new/kernel and /boot/new/mfsroot.gz and then manually load the new kernel and mfsroot from the hard disk's loader to get into the installer. I.e. something like: ok unload all ok load /boot/new/kernel ok load -t mfs_root /boot/new/mfsroot ok boot -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PIII SMP
On 31-Jul-2003 Terry Lambert wrote: It wasn't clear to me at the time whether the discussion was geared toward having both APIC and xAPIC support, or only xAPIC support. Both, the xAPIC is mostly backwards compatible. The extension of the ID field just uses bits that are reserved (and hard-wired to 0) on the older APICs. Thus, if one uses 0xFF to address all CPU's (the only real difference), then it will work on both types of APICs. I'm not happy with my Circa 1996 dual P90 box. It's not inconceivable that non-xAPIC processors might get deprecated in the rush to more than 16 CPU's, like my ASUS dual P90 box seems to have been. The P90 breakage isn't related to any APIC changes AFAICT. Do you have any more details of the exact breakage on the P90? I've forgotten the details. :( Also, the recent change to make SSE instructions the build default also bit me on one of my machines without SSE support. Humm, is this in the kernel? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PIII SMP
On 29-Jul-2003 Terry Lambert wrote: [EMAIL PROTECTED] wrote: dear list, buying two PIII for a dual system ... what do i have to pay attention to (besides the requirements of the M/B)? aka ... are all PIII SMP capable? You want the stepping to be the same. You may not be happy with P III's. I'm not sure if the SMP code has been changed to handle only the xAPIC now, or not; there was a discussion a little while back about supporting more than 16 CPUs in a machine, which would require this change. Adding support for xAPICs isn't going to break P3 machines. Less FUD please. One of my test machines is a dual ppro 200 and although I haven't booted it in a while it ran current just fine the last time I tried. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Safely removing USB hard drive
On 09-Jun-2003 Brandon S. Allbery KF8NH wrote: On Mon, 2003-06-09 at 02:36, Remington L. wrote: I have a USB keychain storage device. I can get it working fine but I cant figure out how to properly disconnect it. In windows I can detach the drive and the LED on the USB keychain goes off. Can this be accomplished in FBSD 5.1? Or is unmounting and simply removing it safe? Simply unmounting it should be good enough. camcontrol stop will probably do what you want (*after* unmounting it). or 'camcontrol eject'. eject is what I use to disconnect my firewire iPod for example. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: intalling from cds
On 31-Jan-2003 Kirk R Wythers wrote: I ran into a strange issue while trying to do a cd install from the 5.0-RELEASE cds. After booting from the cd, the install skips the kernel configuration menue completely (I've never seen that before), then jumps right into sysinsall. I select 'standard install', and I see the folloing: The USERCONFIG stuff isn't around anymore in 5.0. afd0 da0 da1 adf0 is a zip250 drive on this box. Why is that showing up here? If I choose to use the entire disk on da0 and da1 (no dual boot concerns), and install the 'standard mbr' on the da0, I seem to be stuck going back to the 'choose the drive' afd0 da0 da1 menue without getting to the the disklable editor What am I doing wrong? thanks Use Tab to move down to 'Ok' after you have finished using fdisk on your drives and then hit Enter to continue. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: USB Keychain storage
On 23-Oct-2002 Chip Marshall wrote: On October 22, 2002, Pookie sent me the following: I have a USB keychain storage device(on umass2) I frequently use. I can mount/use it within freebsd. But when im done I want to be able to just unplug it and go, except the little green light on the device is still on, how do I turn this off? I don't know of any way to do this in FreeBSD. As long as it's unmounted though, it shouldn't be doing anything, so it should be safe to just remove it from the chain. You can try doing a 'camcontrol eject da2' and see if that works. That works for my iPod with the firewire support in current. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: i-buddie
On 09-Oct-2002 Guido Van Hoecke wrote: i4o beke wrote: Hi Guido. I've seen your question on freebsd-mobile, without answer. I'd like to buy i-buddie, 3c or 4. So your problems with setup are really interesting for me. Is your sis network card working? Is it possible to run XWin on i-buddie? Thank you for your answer. I am afraid I have had no luck with freebsd. My sis900 network card is recognized but fails with a 'MII without any PHY!', and 3 more devices are showing up as unknown: That I can't help you with, sorry. pci0 2.7 is a sis7012 audio driver Sound isn't configured in teh default kernel. Try doing a 'kldload snd_driver' and seeing if pcm0 attaches to it. pci0 5.0 is a conexant 56k modem Probably a win modem. There are some ports that might work with this. pci0 7.0 ia a VIA OHCI Compliant IEEE1394 host controller This is firewire. Only supported in -current. Further more, XF86 as available in freebsd 4.6.2-RELEASE #0 does not recognize my lcd panel, so I can't run a desktop environment. Sometimes X has to be futzed with to work right. I had to add bogus horizontal and vertical refresh rates for X to work right on my laptop. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
