Re: IPv6 default route. Can't see the wood for the trees.
On 08/27/12 18:49, John Hawkes-Reed wrote: BSD-box (9.1-PRE) is acting as default router/NAT gateway for local LAN. IP4 works. IP6 rig, per the setup on tunnelbroker.net, appears to work on the BSD box. However, while LAN clients (XP, OSX) manage to acquire addresses with the right prefix, the autoconfigured default route is a link-local address. Some bits of the internet think that's ok. Other bits don't. Bits of the internet does not see anything about whether your default gateway is link-local or not and do not care. The default gateway on the box that I'm writing this from is link-local and IPv6 works quite nicely. Trying to ping6/traceroute6 out to (say) Google works on the BSD box, but not on the clients. Do I need to be running a routing daemon, or is there some ip6 handwaving I'm missing? If you are running pf or another firewall, you should have rules that allow traffic to pass through. rc.conf: (I'm not convinced that obfuscating the addresses is worth the confusion) ipv6_gateway_enable=YES ip6addrctl_verbose=YES rtadvd_enable=YES rtadvd_interfaces=rl0 ipv6_cpe_wanif=pcn0 ipv6_defaultrouter=2001:470:1f0a:b5a::1 gif_interfaces=gif0 gifconfig_gif0=192.168.1.100 216.66.80.30 ifconfig_gif0_ipv6=inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 prefixlen 128 ifconfig_pcn0_ipv6=inet6 2001:470:1f0b:b5a::4 prefixlen 64 ifconfig_rl0_ipv6=inet6 2001:470:1f0b:b5a::3 prefixlen 64 -accept_rtadv It looks like you are trying to use the /64 used for your tunnel on the inside network. That's probably what causes the problem. You should use the Routed /64 on the inside. If you need more than one /64, you can request a /48. I'm not exactly sure what ipv6_cpe_wanif does, but I have never needed it and I run a setup similar to what you describe. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPv6 default route. Can't see the wood for the trees.
On 08/27/12 21:03, John Hawkes-Reed wrote: On 27/08/2012 19:06, Christian Laursen wrote: On 08/27/12 18:49, John Hawkes-Reed wrote: rc.conf: (I'm not convinced that obfuscating the addresses is worth the confusion) ipv6_gateway_enable=YES ip6addrctl_verbose=YES rtadvd_enable=YES rtadvd_interfaces=rl0 ipv6_cpe_wanif=pcn0 ipv6_defaultrouter=2001:470:1f0a:b5a::1 gif_interfaces=gif0 gifconfig_gif0=192.168.1.100 216.66.80.30 ifconfig_gif0_ipv6=inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 prefixlen 128 ifconfig_pcn0_ipv6=inet6 2001:470:1f0b:b5a::4 prefixlen 64 ifconfig_rl0_ipv6=inet6 2001:470:1f0b:b5a::3 prefixlen 64 -accept_rtadv It looks like you are trying to use the /64 used for your tunnel on the inside network. That's probably what causes the problem. You should use the Routed /64 on the inside. If you need more than one /64, you can request a /48. I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B: Sorry, my bad. Are pcn0 and rl0 both connected to internal networks? Having the same /64 configured on both is probably bad. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.0 - GPT boot problems?
On 03/24/12 17:26, Torfinn Ingolfsen wrote: Hi, I just installed FreeBSD 9.0-release / amd64 on a new machine (Acer Aspire X1470). I installed from a usb memory stick (the default amd64 image), which I booted by pressing F12 and selecting it from the boot menu on the machine. I installed on a SSD (which replaced the hard drive originally in the machine), using the default scheme for 9.0 (GPT). The installation was painless (many thanks to all who made it that way), but when I try to boot the machine from the SSD afterwards, I just get this message from the BIOS: ERROR: No boot disk has been detected or the disk has failed. I tried selecting the SSD from the boot menu (via F12) instead (it shows up as EFI: M4-CT128M4SSD2), but got the same message. I upgraded the BIOS from version P01-A3 to version P01-A4 (the newest available), still no dice. It sounds a bit like the BIOS thinks that since the disk uses GPT you want to EFI boot. As far as I know the default bootcode in the PMBR is meant for old style BIOS booting. Is it possible to disable EFI in your BIOS? If that is the case, that's probably the easiest solution. I'm unsure of the current state of EFI boot in FreeBSD but a little bit of searching did not look promising. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
A script that modifies /etc/fstab to mount devices via glabel
Hi there, I wrote a script that modifies fstab so that UFS filesystems are mounted via their UFS IDs and swap partitions are labeled with glabel in order to access them that way. It works for me on at least FreeBSD 7.2 and 8.0. Use at your own risk. For swap devices it is neccesary to label the device in order to recognize it later and that requires that swap is turned off briefly. The script requires perl to run. The script is here: http://borderworlds.dk/utils/fstab-glabel.pl Feel free to use it if you find it useful. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
/boot/loader broken in 7.1
After I upgraded one of my machines from FreeBSD 7.0 to 7.1, I am experiencing a problem with the loader. It stops with these messages: Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0: can't load 'kernel' I have taken a screenshot (Yes, with my camera): http://borderworlds.dk/~xi/loader.jpg I notice the follwoing at the top of the screen: skip_newline\ not found When looking through the forth code I see a function named skip_newlines. Does this perhaps indicate that some string handling goes wrong somewhere? Anyway, using /boot/loader.old from 7.0 works perfectly. I have not seen this issue on any of the other 10+ machines that I have upgraded to 7.1. I am ready to provide more info on request if neccesary. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Is FreeBSD a suitable choice for a MacBook?
Eirik Wixøe Svela [EMAIL PROTECTED] writes: I have an Apple MacBook with an Intel Core 2 Duo processor (November 2007 edition, cf. the Wikipedia article for specifications), and I have been considering switching to one of the free UNIX clones for some time now. I understand that Ubuntu GNU/Linux is supposed to work well on this kind of machine, but I would rather use some variant of BSD if that is a viable alternative. I have a MacBook running FreeBSD. IIRC I bought it in January 2008 so it's probably the same model as yours. I would therefore like to ask you whether anyone here has any experience with FreeBSD, either 7.0-RELEASE or any other version, that they would like to share so I might know what to expect if I choose to go through with this. I have some time on my hands the next couple of weeks, so I am prepared to spend some days tweaking things to work if it is worth the effort, but if it isn't, I might as well take Ubuntu for a spin or do a clean install of Mac OS X. I have made a few notes here: http://borderworlds.dk/notes/freebsd-macbook.html I just used boot camp and did a pretty standard install. I would recommend installing a 7.1-BETA release to have the wired ethernet working from the beginning. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.1-PRERELEASE freezes (IPFW related)
Jeremy Chadwick [EMAIL PROTECTED] writes: On Fri, Sep 26, 2008 at 06:21:01PM +0200, Christian Laursen wrote: I decided to give 7.1-PRERELEASE a try on one of my machines to find out if there might be any problems I should be aware of. I quickly ran into problems. After a while the system freezes completely. It seems to be somehow related to the load of the machine as it doesn't seem to happen when it is idle. I built a kernel with software watchdog enabled and enabled watchdog which had the nice effect of turning the freeze into a panic. Hopefully that will be of some help. [snip] A couple generic things, although I think jhb@ might be able to figure out what's going on here: 1) Is this machine running the latest BIOS available? 2) Are you running powerd(8) on this box? 3) Does disabling ACPI (it's a menu option when booting) help? 4) Does removing device cpufreq help? I tried without ACPI right after writing the previous mail without any luck. However I tried turning off various stuff and found the cause of the problem. When I tried running without my ipfw rules the crashes went away. I then immediately suspected the rules using uid matching and those were indeed responsible. I am now back to running with everything I usually have running on this machine (my primary desktop) but without the ipfw uid rules and the machine is rock stable. I have been running with debug.mpsafenet=0 most likely because I have been using ipfw uid matching. Has RELENG_7 had significant changes in this area? Since I don't need these rules anymore I have just removed them. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
7.1-PRERELEASE freezes
Hello, I decided to give 7.1-PRERELEASE a try on one of my machines to find out if there might be any problems I should be aware of. I quickly ran into problems. After a while the system freezes completely. It seems to be somehow related to the load of the machine as it doesn't seem to happen when it is idle. I built a kernel with software watchdog enabled and enabled watchdog which had the nice effect of turning the freeze into a panic. Hopefully that will be of some help. I first encountered the problem using SCHED_ULE and then tried if SCHED_4BSD made any difference. But the freeze happens with either scheduler. I have disabled xorg and the nvidia driver but that doesn't help either. I can cut down on various other stuff too, but first I hope that someone here have a more educated guess about what could be the cause of the freezes. I have placed the backtraces from the most recent crashes as well as the demsg output from the most recent boot at this URL: http://borderworlds.dk/~xi/7.1-PRERELEASE.freeze.txt My kernel config is also included. As far as I can tell the two backtraces are identical and look like this: #0 doadump () at pcpu.h:196 #1 0xc05abd03 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05abeff in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0570d18 in hardclock (usermode=0, pc=3231434181) at /usr/src/sys/kern/kern_clock.c:642 #4 0xc07d194f in clkintr (frame=0xe38e1c68) at /usr/src/sys/i386/isa/clock.c:164 #5 0xc07c0465 in intr_execute_handlers (isrc=0xc0866700, frame=0xe38e1c68) at /usr/src/sys/i386/i386/intr_machdep.c:366 #6 0xc07d0fa8 in atpic_handle_intr (vector=0, frame=0xe38e1c68) at /usr/src/sys/i386/isa/atpic.c:596 #7 0xc07bbf41 in Xatpic_intr0 () at atpic_vector.s:62 #8 0xc09bc5c5 in acpi_cpu_c1 () at /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_machdep.c:550 #9 0xc09b54f4 in acpi_cpu_idle () at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_cpu.c:945 #10 0xc07c35b6 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1183 #11 0xc05c9275 in sched_idletd (dummy=0x0) at /usr/src/sys/kern/sched_4bsd.c:1429 #12 0xc05895d6 in fork_exit (callout=0xc05c9260 sched_idletd, arg=0x0, frame=0xe38e1d38) at /usr/src/sys/kern/kern_fork.c:804 #13 0xc07bbf10 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 I can provide more information as needed. Any help will be greatly appreciated. Thanks. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: machine hangs on occasion - correlated with ssh break-in attempts
Mikhail Teterin [EMAIL PROTECTED] writes: A machine I manage remotely for a friend comes under a distributed ssh break-in attack every once in a while. Annoyed (and alarmed) by the messages like: Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 I wrote an awk-script, which adds a block of the attacking IP-address to the ipfw-rules after three such invalid user attempts with: ipfw add 550 deny ip from ip I don't know if it will make your problem go away, but using ipfw tables for this seems to be a better idea than creating a new rule for every IP address. So you just need one rule: ipfw add 550 deny ip from table(1) And then when you want to add an IP address to the table: ipfw table 1 add ip You can add ranges too using the CIDR notation. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: busybox and small scripting languages on FreeBSD ?
Luigi Rizzo [EMAIL PROTECTED] writes: Also, what would you suggest as a small scripting language to be used in this kind of platform for implementing CGI scripts (and preferably able to use sockets/select) ? Take a look at lua. It should have a pretty small footprint looks pretty easy to use - either standalone or embedded in you own programs. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Documentation: Installing FreeBSD 7.0 via serial console and PXE
Jeremy Chadwick [EMAIL PROTECTED] writes: I believe the options you're referring to are LOADER_TFTP_SUPPORT and LOADER_NFS_SUPPORT. Even if you define LOADER_NFS_SUPPORT=no, loader(8) will still resort to using NFS. I've confirmed this on a couple occasions by defining PXE_DEBUG=1 and looking at the output. NFS, from what I can tell, is needed regardless because TFTP offers no way (AFAIK) of handling directory structures. This is speculation on my part, but the confirmation that there's no way to do a pure TFTP-based install has been verified. I have installed FreeBSD via PXE a lot of times and managed to avoid using NFS every single time. Very brief notes about how to do it is included on this page: http://borderworlds.dk/writings/freebsd_on_toshiba_portege_r100.html -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ggated not working on 6.2-PRERELEASE
I have CC'ed pjd too as this concerns ggate and I saw another thread that looked like the same problem. Kazuaki ODA [EMAIL PROTECTED] writes: ggated is not working on 6.2-PRERELEASE. For example, run the following commands: [snip] ggated: Error while receiving hdr packet: Resource temporarily unavailable. ggated: Exiting. I am experiencing this too. I tried to find what broke ggated, and finally found that it works fine when I backout sys/kern/uipc_socket2.c rev. 1.147.2.7. I will try to reproduce that here. I don't know why the changes break ggated, but I hope that ggated will work on 6.2-RELEASE. As far as I can tell, src/sbin/ggate/ggated/ggated.c line 634 calls g_gate_recv, which in turn calls recv(2) on src/sbin/ggate/shared/ggate.c line 254. recv is called with the MSG_WAITALL flag and receives an EAGAIN error. Is that supposed to happen? If it is, ggated should probably handle it. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ggated not working on 6.2-PRERELEASE
Christian Laursen [EMAIL PROTECTED] writes: Kazuaki ODA [EMAIL PROTECTED] writes: I tried to find what broke ggated, and finally found that it works fine when I backout sys/kern/uipc_socket2.c rev. 1.147.2.7. I will try to reproduce that here. I can confirm that it works for me too with the above mentioned change backed out. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal and Softupdates
Ivan Voras [EMAIL PROTECTED] writes: - todays desktop drives can lie about writing data. SoftUpdates relies on some assumptions about when the data is physically written to media, and those are not always valid today I think journaling relies on the same assumptions. However, with journaling you can have filesystem corruption and not know about it. With fsck, bg or not, at least you will know. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal and Softupdates
Ivan Voras [EMAIL PROTECTED] writes: Christian Laursen wrote: Ivan Voras [EMAIL PROTECTED] writes: - todays desktop drives can lie about writing data. SoftUpdates relies on some assumptions about when the data is physically written to media, and those are not always valid today I think journaling relies on the same assumptions. Doesn't it rely less since a journal is written sequentially, but SU expects ordering of many writes to different parts of the file system to be persistent and in sequence? Journaling also needs writes to be done in the correct order. You don't want to write the real update to the filesystem before you have made sure that it has been committed to the journal. If that can happen you are no better off than without the journal. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal and Softupdates
Ivan Voras [EMAIL PROTECTED] writes: Christian Laursen wrote: However, with journaling you can have filesystem corruption and not know about it. With fsck, bg or not, at least you will know. Also, I'm interested about this - what kind of silent corruption? The same kind that can generally come from on-drive caches? Yes, as well as corruption resulting from bugs in the kernel code. The point is that you will never know because you never check your filesystems. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gjournal and Softupdates
Ivan Voras [EMAIL PROTECTED] writes: Christian Laursen wrote: Journaling also needs writes to be done in the correct order. You don't want to write the real update to the filesystem before you have made sure Ok, but journal is (or should be) protected by checksumming or some kind of record markers, so invalid entries are not replayed. That is not the issue. Recognizing valid journal entries should be easy enough. Consider the following sequence of events: 1. Data A is written to the journal 2. The journal is flushed to disk 3. Data A is written to the filesystem Now consider what happens if the disk is reordering writes: 1. Data A is partially written to the journal 2. Data A is partially written to the filesystem 3. The system crashes You now have an invalid journal entry for data A which will not be replayed and some unkown amount of the data is already written to the filesysten possibly leaving it in an inconsistent state. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: background fsck can be dangerous!
Steven Hartland [EMAIL PROTECTED] writes: /me looks forward to a journaling FS The FS is the one area that really lets FreeBSD down in my opinion. Wish I had 1. the time and 2. the knowledge to help out with dev in the area but unfortunately I have neither :( Remember that if you are having trouble with softupdates and background fsck reporting inconsistencies, journalling will just give you silent filesystem corruption instead. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: background fsck can be dangerous!
Matthias Buelow [EMAIL PROTECTED] writes: Christian Laursen [EMAIL PROTECTED] writes: Remember that if you are having trouble with softupdates and background fsck reporting inconsistencies, journalling will just give you silent filesystem corruption instead. What makes you believe so? Assuming the inconsistencies are not caused by bugs in softupdates the only thing that will cause it is hardware that does not live up to the requirements, e.g. ata drives with write caching enabled. Journalling has the same requirements to the hardware. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII official patches for releng_5
Søren Schmidt [EMAIL PROTECTED] writes: I've just uploaded the latest ATA mkIII patches for releng_5 (and releng_5_4 for that matter). Seems to work fine on my laptop running 5.4-RC2. Suspend/resume doesn't work, but it didn't do that either with the code in RELENG_5_4. It seems to fail in a slightly different way now though. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-PRERELEASE pccard problem
Doug White [EMAIL PROTECTED] writes: On Tue, 5 Apr 2005, Christian Laursen wrote: Doug White [EMAIL PROTECTED] writes: On Sat, 2 Apr 2005, Christian Laursen wrote: After upgrading to 5.4-PRERELEASE as of yesterday, I now have a problem with my wireless card that has worked fine before. I now suspect that my wireless card might be going bad. Could a faulty card cause a panic like that? Certainly could if it is causing random memory corruption. It now seems that the card is not faulty. I tried another card and got the same panic. :( -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-PRERELEASE pccard problem
Doug White [EMAIL PROTECTED] writes: On Sun, 3 Apr 2005, Christian Laursen wrote: Anyway, I tried blowing away /usr/obj, cvsupping to RELENG_5_4, built world and kernel and installed both. And it still panics with the exact same stack trace. :( Old kernel module somewhere? I dont think so. The only modules I can find on the machine are located under /boot/kernel, /boot/kernel.old and /usr/obj. Besides, neither pccard nor if_wi are loaded from modules but built into the kernel. To further comlicate matters the card works some of the time but I have been unable to find a pattern suggesting what could cause the problem. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-PRERELEASE pccard problem
Doug White [EMAIL PROTECTED] writes: On Sat, 2 Apr 2005, Christian Laursen wrote: After upgrading to 5.4-PRERELEASE as of yesterday, I now have a problem with my wireless card that has worked fine before. I now suspect that my wireless card might be going bad. Could a faulty card cause a panic like that? -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-PRERELEASE pccard problem
Alex Burke [EMAIL PROTECTED] writes: Just a small point - I am not sure if RELENG_5_4 exists yet, I think that is only created after RELENG_5 is branched to create FreeBSD 5.4-RELEASE. It exists all right. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-PRERELEASE usb audio problem
Khairil Yusof [EMAIL PROTECTED] writes: On Sat, 2005-04-02 at 21:13 +0200, Christian Laursen wrote: When I plug in my Logitech USB headset I get the following: uaudio0: Logitech Logitech USB Headset, rev 1.10/1.13, addr 2 uaudio_add_selector: NOT IMPLEMENTED uaudio0: audio rev 1.00 pcm1: USB Audio on uaudio0 pcm1: chn_init(pcm1:play:0) failed: err = 19 pcm1: pcm_chn_create(ua_chan, 1, 0xc1974780) failed uhid0: Logitech Logitech USB Headset, rev 1.10/1.13, addr 2, iclass 1/1 Julian Elischer, posted a fix on freebsd-current@ some time ago. [snip] This works for my Sony SRS-T10PC USB speakers. If it fixes it for other usb audio devices, I think this fix should be committed. It doesn't seem to make any difference. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-PRERELEASE pccard problem
Doug White [EMAIL PROTECTED] writes: On Sat, 2 Apr 2005, Christian Laursen wrote: After upgrading to 5.4-PRERELEASE as of yesterday, I now have a problem with my wireless card that has worked fine before. When I insert it I get an instant panic like this: [snip] This makes no sense. What version of src/sys/dev/pccard/pccard.c do you have? __FBSDID($FreeBSD: src/sys/dev/pccard/pccard.c,v 1.93.2.2 2005/02/03 00:30:02 imp Exp $); Line 381 is a comparison in RELENG_5: 381 if (matches ent-pp_cis[0] 382 (vendorstr == NULL || 383 strcmp(ent-pp_cis[0], vendorstr) != 0)) 384 matches = 0; pccard.c does not call any of the radix functions. I agree it does look pretty weird. I'd suggest blowing away your kernel source and obj dir and rebuilding your kernel + modules from scratch. This looks like you have a mismatched module somewhere, or memory corruption, or worse. Be sure to follow the instructions in UPDATING explaining how to track -STABLE and build the world and kernel correctly. I always use follow the buildworld, buildkernel, installkernel, installworld, mergemaster routine when updating things. Anyway, I tried blowing away /usr/obj, cvsupping to RELENG_5_4, built world and kernel and installed both. And it still panics with the exact same stack trace. :( -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5.4-PRERELEASE pccard problem
0 fdc0: floppy drive controller port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: floppy drive controller port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xc-0xcbfff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 299942864 Hz quality 800 Timecounters tick every 10.000 msec IPv6 packet filtering initialized, default to accept, logging limited to 100 packets/entry ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to accept, logging limited to 100 packets/entry by default ad0: 28615MB FUJITSU MHT2030AT/009B [58140/16/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s1a Please let me know what I can do to help solve this problem. Thank you. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5.4-PRERELEASE usb audio problem
When I plug in my Logitech USB headset I get the following: uaudio0: Logitech Logitech USB Headset, rev 1.10/1.13, addr 2 uaudio_add_selector: NOT IMPLEMENTED uaudio0: audio rev 1.00 pcm1: USB Audio on uaudio0 pcm1: chn_init(pcm1:play:0) failed: err = 19 pcm1: pcm_chn_create(ua_chan, 1, 0xc1974780) failed uhid0: Logitech Logitech USB Headset, rev 1.10/1.13, addr 2, iclass 1/1 With 5.3 and earlier it used to at least work for playback but now it seems to be completely broken. I saw a lot of commits to uaudio, including recording support. Does something need to be merged from -CURRENT for it to work properly? Thank you. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
MFC of src/bin/rmdir/rmdir.c
We are starting to migrate stuff to FreeBSD 5 and one of my shell scripts broke because rmdir -p doesn't work in 5.3. It would be really nice to have the fix from CURRENT merged to RELENG_5 and possibly even RELENG_5_3 if possible. Thanks. -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet related panic in 5.3-RELEASE-p1
Gleb Smirnoff [EMAIL PROTECTED] writes: is it easy to reproduce it? Can you set debug.mpsafenet=0 and try to reproduce it? It looks like debug.mpsafenet=0 make the crashes happen more frequently. I now managed to get a crashdump. kernel.debug and vmcore.1 are in the tarball available here: http://hoegaarden.pil.dk/~cfsl/ns3-crashdump.tar.bz2 -- Christian Laursen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet related panic in 5.3-RELEASE-p1
Gleb Smirnoff [EMAIL PROTECTED] writes:
On Wed, Dec 15, 2004 at 09:03:28AM +0100, Christian Laursen wrote:
C We are experiencing a panic about once a day that seems related to
C dummynet.
[snip]
C I have put the kernel configuration at at
http://hoegaarden.pil.dk/~cfsl/NS3
C and the boot output at http://hoegaarden.pil.dk/~cfsl/ns3-dmesg.
C
C Thanks in adavnce for any help solving this.
Can you save crashdump?
I now managed to get a crashdump.
This is the backtrace from there:
ns3# kgdb kernel.debug /var/crash/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
doadump () at pcpu.h:159
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc042d88e in db_fncall (dummy1=0, dummy2=0, dummy3=57, dummy4=0xc74db99c
йMÇ\200%) at /usr/src/sys/ddb/db_command.c:531
#2 0xc042d69c in db_command (last_cmdp=0xc0672564, cmd_table=0x0,
aux_cmd_tablep=0xc06440fc, aux_cmd_tablep_end=0xc0644100) at
/usr/src/sys/ddb/db_command.c:349
#3 0xc042d764 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
#4 0xc042f2d9 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221
#5 0xc04bd382 in kdb_trap (type=12, code=0, tf=0xc74dbb2c) at
/usr/src/sys/kern/subr_kdb.c:418
#6 0xc060d011 in trap_fatal (frame=0xc74dbb2c, eva=12) at
/usr/src/sys/i386/i386/trap.c:804
#7 0xc060cd97 in trap_pfault (frame=0xc74dbb2c, usermode=0, eva=12) at
/usr/src/sys/i386/i386/trap.c:727
#8 0xc060c995 in trap (frame=
{tf_fs = -1061945320, tf_es = 16, tf_ds = -951255024, tf_edi =
-1052997804, tf_esi = 1460, tf_ebp = -951207024, tf_isp = -951207080, tf_ebx =
-1052997888, tf_edx = 0, tf_ecx = -1055588338, tf_eax = 0, tf_trapno = 12,
tf_err = -951255040, tf_eip = -1068659825, tf_cs = 8, tf_eflags = 66054, tf_esp
= 0, tf_ss = -1067603120}) at /usr/src/sys/i386/i386/trap.c:417
#9 0xc05ff70a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#10 0xc0b40018 in ?? ()
#11 0x0010 in ?? ()
#12 0xc74d0010 in ?? ()
#13 0xc13c8754 in ?? ()
#14 0x05b4 in ?? ()
#15 0xc74dbb90 in ?? ()
#16 0xc74dbb58 in ?? ()
#17 0xc13c8700 in ?? ()
#18 0x in ?? ()
#19 0xc115000e in ?? ()
#20 0x in ?? ()
#21 0x000c in ?? ()
#22 0xc74d in ?? ()
#23 0xc04d8b8f in m_copym (m=0x0, off0=1500, len=1480, wait=1) at
/usr/src/sys/kern/uipc_mbuf.c:373
#24 0xc05305c4 in ip_fragment (ip=0xc115000e, m_frag=0xc74dbc48,
mtu=-1052997888, if_hwassist_flags=0, sw_csum=1) at
/usr/src/sys/netinet/ip_output.c:965
#25 0xc0530270 in ip_output (m=0xc0cbfe00, opt=0xc115000e, ro=0xc74dbc14,
flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:794
#26 0xc05246b1 in transmit_event (pipe=0xc0bc9c00) at
/usr/src/sys/netinet/ip_dummynet.c:454
#27 0xc05249c4 in ready_event (q=0xc0c60900) at
/usr/src/sys/netinet/ip_dummynet.c:614
#28 0xc0524f37 in dummynet (unused=0x0) at
/usr/src/sys/netinet/ip_dummynet.c:769
#29 0xc04b229b in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:259
#30 0xc0491945 in ithread_loop (arg=0xc0ac3580) at
/usr/src/sys/kern/kern_intr.c:547
#31 0xc0490ac5 in fork_exit (callout=0xc04917f0 ithread_loop, arg=0xc0ac3580,
frame=0xc74dbd48) at /usr/src/sys/kern/kern_fork.c:811
#32 0xc05ff76c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209
--
Christian Laursen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Dummynet related panic in 5.3-RELEASE-p1
We are experiencing a panic about once a day that seems related to dummynet. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc04d8b8f stack pointer = 0x10:0xc74dbb6c frame pointer = 0x10:0xc74dbb90 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 27 (swi5: clock sio) [thread 100021] Stopped at m_copym+0x2f: cmpl%esi,0xc(%edx) db trace m_copym(0,3ffc,3fe8,1,14) at m_copym+0x2f ip_fragment(c0ccf80e,c74dbc48,4000,0,1) at ip_fragment+0x214 ip_output(c0cbac00,0,c74dbc14,0,0,0) at ip_output+0x6e8 transmit_event(c0bcda00) at transmit_event+0xa9 ready_event(c0d14300) at ready_event+0x150 dummynet(0) at dummynet+0xeb softclock(0) at softclock+0x217 ithread_loop(c0ac3580,c74dbd48) at ithread_loop+0x155 fork_exit(c04917f0,c0ac3580,c74dbd48) at fork_exit+0x75 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc74dbd7c, ebp = 0 --- I have put the kernel configuration at at http://hoegaarden.pil.dk/~cfsl/NS3 and the boot output at http://hoegaarden.pil.dk/~cfsl/ns3-dmesg. Thanks in adavnce for any help solving this. -- Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet related panic in 5.3-RELEASE-p1
Gleb Smirnoff [EMAIL PROTECTED] writes: On Wed, Dec 15, 2004 at 09:03:28AM +0100, Christian Laursen wrote: C We are experiencing a panic about once a day that seems related to C dummynet. C C Fatal trap 12: page fault while in kernel mode Can you save crashdump? I hope KDB_UNATTENDED will give me that the next time it panics. Furthermore I'll boot the machine on a debug kernel and hopefully get a trace with line numbers now that KDB_TRACE is in the kernel configuration too. I'll get back as soon as I get more info out of it. -- Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How do I know the 'bogomips' of my system ?
Brossin Pierrick [EMAIL PROTECTED] writes: Under Linux it was easy to find it.. /proc Under FreeBSD I can't find it.. There's no such thing in FreeBSD. The value itself is useless for anything but the internals of the linux kernel. -- Best regards Christian Laursen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
