Re: Change in loader or kernel: won't boot with kfreebsd in grub2
On Sun, Aug 25, 2013 at 03:35:06PM -0700, Thomas Mueller wrote: On Sat, Aug 24, 2013 at 08:53:31PM -0700, Thomas Mueller wrote: Some updates: I could see what happens if I try to boot the FreeBSD boot partition on the hard drive using the Super Grub Disk with chainloader. If that works, it would boot FreeBSD 9.0-BETA1, but I would see if it works. That failed (invalid signature). You probably need to chainload a freebsd-boot partition, _if_ you want to chainload at all. I was trying to chainload the freebsd-boot partition! But grub2 didn't like it. Hmm I guess it doesn't know about that partition type yet then... I could also try kfreebsd /boot/kernel/kernel That failed to boot the proper partition, went to the debugger (db), whereupon all I could type was reboot. You didn't get a mountroot prompt? If you did you can try typing a question mark and return, that should list possible partitions to mount root from. If you didn't, or you don't want to do this manually you need to set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0p1 from grub2, or wherever your root partition is. I remember pressing a key, but then the system rushed past the mountroot prompt into the debugger prompt. If you pressed return w/o typing anything I guess that's what will happen... Now can I safely install boot into the partition to be booted, as I did with NetBSD on USB stick? gpart -p /boot/boot -i 3 That would be for /dev/ada0p3, but I am afraid of damaging something. That would need to be on a freebsd-boot partition, and you want /boot/gptboot not /boot/boot. I believe bsdlabel can be used to install boot code to a partition, but believe that is not for GPT. Indeed. I could try bsdlabel on a giant floppy image as I used installboot on a giant floppy image for NetBSD. Uhm, why not just get grub2 kfreebsd booting working? Best, Juergen ___ 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: Change in loader or kernel: won't boot with kfreebsd in grub2
On Sat, Aug 24, 2013 at 08:53:31PM -0700, Thomas Mueller wrote: Some updates: I could see what happens if I try to boot the FreeBSD boot partition on the hard drive using the Super Grub Disk with chainloader. If that works, it would boot FreeBSD 9.0-BETA1, but I would see if it works. That failed (invalid signature). You probably need to chainload a freebsd-boot partition, _if_ you want to chainload at all. I could also try kfreebsd /boot/kernel/kernel That failed to boot the proper partition, went to the debugger (db), whereupon all I could type was reboot. You didn't get a mountroot prompt? If you did you can try typing a question mark and return, that should list possible partitions to mount root from. If you didn't, or you don't want to do this manually you need to set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0p1 from grub2, or wherever your root partition is. Now can I safely install boot into the partition to be booted, as I did with NetBSD on USB stick? gpart -p /boot/boot -i 3 That would be for /dev/ada0p3, but I am afraid of damaging something. That would need to be on a freebsd-boot partition, and you want /boot/gptboot not /boot/boot. Tom HTH, Juergen ___ 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: Change in loader or kernel: won't boot with kfreebsd in grub2
On Thu, Aug 22, 2013 at 02:41:06AM +, Thomas Mueller wrote: Not sure about a physical cd but booting an iso should be possible using either memdisk from grub2 like in the posting I linked, http://ubuntuforums.org/showthread.php?t=1549847page=13p=10818457#post10818457 _or_ also using grub2's own loopback command like described here: http://michael-prokop.at/blog/2009/05/25/boot-an-iso-via-grub2/ (but btw the super grub disk iso should also boot directly when dd'd to an usb key, not only when burned to a cd/dvd.) It could only be that the partition table on your disk is somehow messed up/has leftover data from a previous install that confused loader and might confuse grub2 too so that it doesn't find the FreeBSD install... I also wonder how or if one can boot a FreeBSD partition from GRUB2 or syslinux. That's what super grub disk's autodetection should now detect correctly, if you want to write a grub.cfg entry manually (or type it live from a grub2 rescue shell) an example is also here: http://forums.freebsd.org/showthread.php?p=85122#post85122 but note as I said before if you want to boot a 9.1+ kernel directly w/o loader you need a grub 2.00 version that has the patch mentioned here: (that's now in debian and in FreeBSD ports but might not be in other grub2 versions floating around) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699002 Tom HTH, :) Juergen I tried to boot the FreeBSD partition directly from Super Grub2 Disk with chainloader +1, but was not successful. Well that just run loader which seems to have issues on your box as you said. (or does on mbr at least) I think some FreeBSD boot code is in a small boot partition such as I have on the USB-stick installations, installed with gpart. ...so if this is gpt you may need to chainload that partition in fact, yes. I wonder if linux16 memdisk from grub2 is the same as KERNEL memdisk in syslinux: was planning to try it on FreeDOS 1.1 installation fd11src.iso . They both boot memdisk so kind of similar, yes. I also have a memdisk in the latest syslinux installed from FreeBSD ports. Once FreeBSD boots from the USB stick, it accesses the GPT partitions OK as far as I can tell. Ok so only loader has difficulties... As I said try the latest super grub disk iso, that might still be able to see the partition and if yes boot the kernel directly from there w/o loader. I could even check with a USB-stick installation of NetBSD, though NetBSD is much less stable than FreeBSD on my modern hardware. I was even thinking of making a giant floppy image, not to write to an actual disk, but to boot via grub2 or possibly grub4dos. If you already use grub2 then it only needs the mentioned patch (and be able to see your FreeBSD partition), then it should be able to boot the kernel directly w/o loader as I said. I would copy /boot but not including the modules to another directory, apply makefs, mdconfig, mount this image, and bsdlabel. I did something like that with NetBSD 5.1_STABLE i386, and it worked with grub4dos. I would of course have to interrupt the boot to be able to specify the root file system, as I did with NetBSD, or maybe put into loader.conf . map --mem --heads=16 --sectors-per-track=63 (hd0,2)/boot2/nbffs51c.img (fd0) map --hook rootnoverify (fd0) chainloader (fd0)+1 boot and hit the spacebar in time to get the boot menu, so I coulld type boot netbsd -a to specify the root file system, or I could boot any other kernel present in the 40 MB floppy image. Grub4dos, being born from DOS, requires setting a (fictitious here) disk geometry. ..so all that sounds superfluous. Tom HTH, :) Juergen ___ 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: Change in loader or kernel: won't boot with kfreebsd in grub2
On Tue, Aug 20, 2013 at 02:54:44PM -0700, Thomas Mueller wrote: This is what /cdrom/isolinux/isolinux.cfg shows for Super Grub2 Disk entry: LABEL grubdisk MENU LABEL SGD: Super Grub2 Disk kernel memdisk append initrd=/bootdisk/grubdisk.img floppy raw This is from the latest SysRescCD beta. Now I wonder how or if one can access a CD or DVD from GRUB2. GRUB2 has (hd0) (hd1) (fd0) but no (cd) or (cd0). Not sure about a physical cd but booting an iso should be possible using either memdisk from grub2 like in the posting I linked, http://ubuntuforums.org/showthread.php?t=1549847page=13p=10818457#post10818457 _or_ also using grub2's own loopback command like described here: http://michael-prokop.at/blog/2009/05/25/boot-an-iso-via-grub2/ (but btw the super grub disk iso should also boot directly when dd'd to an usb key, not only when burned to a cd/dvd.) It could only be that the partition table on your disk is somehow messed up/has leftover data from a previous install that confused loader and might confuse grub2 too so that it doesn't find the FreeBSD install... I also wonder how or if one can boot a FreeBSD partition from GRUB2 or syslinux. That's what super grub disk's autodetection should now detect correctly, if you want to write a grub.cfg entry manually (or type it live from a grub2 rescue shell) an example is also here: http://forums.freebsd.org/showthread.php?p=85122#post85122 but note as I said before if you want to boot a 9.1+ kernel directly w/o loader you need a grub 2.00 version that has the patch mentioned here: (that's now in debian and in FreeBSD ports but might not be in other grub2 versions floating around) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699002 Tom HTH, :) Juergen ___ 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: Change in loader or kernel: won't boot with kfreebsd in grub2
On Tue, Aug 20, 2013 at 01:59:27AM +, Thomas Mueller wrote: ..so you probably never saw my post about the updated super grub disk iso: http://lists.freebsd.org/pipermail/freebsd-stable/2013-August/074711.html I.e. they fixed the kfreebsd misspelling and the grub 2.00 bug that prevented it from booting a 9.1+ kernel directly, so the autodetection now has better chances of working. (They even added loader to the autodetection so you can also `e'dit that entry and change loader to loaderae to test this.) HTH, :) Juergen I remember that message you refer to but thought the bug was not fixed yet in Super Grub Disk. How would I make it into something like a giant floppy image that can be booted from syslinux or isolinux like the Super Grub Disk on the System Rescue CD? According to http://www.syslinux.org/wiki/index.php/MEMDISK and http://ubuntuforums.org/showthread.php?t=1549847page=13p=10818457#post10818457 it should be something like: # Boot super grub2 disk from iso image LABEL super grub2 disk hybrid_2.00s1-beta6.iso LINUX memdisk INITRD super_grub2_disk_hybrid_2.00s1-beta6.iso APPEND iso bigraw (but I haven't tested this.) I could also try something by building grub2 from FreeBSD ports, don't know just what booting images I can create. I think grub-mkrescue(1) is for creating grub isos... (comes with grub2.) Tom HTH, :) Juergen ___ 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: Change in loader or kernel: won't boot with kfreebsd in grub2
[sending this from hub since bellsouth.net doesn't seem to like my `normal' mailserver...] On Mon, Aug 19, 2013 at 07:30:16PM +, Thomas Mueller wrote: I can repeat (again) what uname -a shows: FreeBSD amelia2 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #17 r254196: Sun Aug 11 00:36:49 UTC 2013 root@amelia2:/usr/obj/usr/src/sys/SANDY amd64 Hello, can you try to install this loader? http://people.freebsd.org/~ae/loader WBR, Andrey V. Elsukov I just downloaded it, saving as loaderae, using your email username and initials as a suffix. I assume loader works under a different name? I can use kfreebsd/loaderae instead of kfreebsd /boot/loader, and loaderae will be preserved over the next update from source. Then I will want to test the new /boot/loader which might possibly work right with kfreebsd. Or maybe I will have a newer kfreebsd. ..so you probably never saw my post about the updated super grub disk iso: http://lists.freebsd.org/pipermail/freebsd-stable/2013-August/074711.html I.e. they fixed the kfreebsd misspelling and the grub 2.00 bug that prevented it from booting a 9.1+ kernel directly, so the autodetection now has better chances of working. (They even added loader to the autodetection so you can also `e'dit that entry and change loader to loaderae to test this.) HTH, :) Juergen ___ 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: Change in loader or kernel: won't boot with kfreebsd in grub2
On Mon, Aug 12, 2013 at 03:39:45PM +, Thomas Mueller wrote: Hmm I just tested super_grub2_disk_hybrid_2.00s1-beta5.iso from http://www.supergrubdisk.org/category/download/supergrub2diskdownload/ if it can boot FreeBSD-9.2-RC1-amd64-memstick.img in qemu and I had to fix kfreebsd spelled as freebsd and kfreebsd_loadenv spelled as frebsd_loadenv, replace /boot/kernel/kernel with /boot/loader, and I in the loader I then had to set currdev=disk1a (shown by lsdev) and load /boot/kernel/kernel. qemu was started like this: qemu-system-x86_64 -cdrom super_grub2_disk_hybrid_2.00s1-beta5.iso -hda FreeBSD-9.2-RC1-amd64-memstick.img -m 512 -boot d -monitor stdio Letting super_grub2_disk_hybrid_2.00s1-beta5.iso boot the kernel directly via kfreebsd /boot/kernel/kernel fails tho because of a this bug in the vanilla grub 2.00 code: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699002 (The fix for that bug now is in our sysutils/grub2 port as well as in debian's grub 2.00 but apparently not yet in the super grub disk isos.) So maybe your problem is that loader needs currdev set at least in this case and in your old 9.0 installation it didn't? HTH, :) Juergen I still wonder why Super Grub Disk kfreebsd worked until recently. I figure something must have changed in FreeBSD loader or kernel structure since the Super Grub Disk didn't change in that time. For currdev, apparently the big hard drive is just recognized as one big drive with no reference to partitions (lsdev). Hmm that sounds like a problem and would explain why loader cannot boot that install, when it doesn't find the partition... Maybe this is another case of confusion caused by leftover partition table data? In that case you probably can fix this by backing up what you want to keep from that disk, dd'ing /dev/zero over beginning and end of it and then reinstalling everything... (What does gpart show say about that disk now when run from a booted system and also from the 9.2 live system?) I could try building grub2 from ports on both the hard-drive installation and the USB-stick amd64 installation, see what possibilities are then available. FreeBSD gpart can create a boot partition, but then the question is how to boot that when there is more than one OS partition. I can't simply put the FreeBSD boot partition at the start of the hard drive as I did with the USB sticks. I had a FreeDOS installation with syslinux on a USB stick that went bad (the USB stick hardware). That would permit me to have various boot images including grub4dos and Super Grub Disk to boot with syslinux without booting into FreeDOS. I'd re-create that, but the FreeDOS installer has proven tricky. I talked to the super grub disk people yesterday and they want to prepare an updated iso using debian's grub 2.00 (that has the kfreebsd = 9.1 kernel fix), and with the FreeBSD templates fixed also, _maybe_ that would then help you as well... Good luck, :) Juergen ___ 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: Change in loader or kernel: won't boot with kfreebsd in grub2
On Mon, Aug 12, 2013 at 09:05:11PM +0200, Juergen Lock wrote: On Mon, Aug 12, 2013 at 03:39:45PM +, Thomas Mueller wrote: Hmm I just tested super_grub2_disk_hybrid_2.00s1-beta5.iso from http://www.supergrubdisk.org/category/download/supergrub2diskdownload/ if it can boot FreeBSD-9.2-RC1-amd64-memstick.img in qemu and I had to fix kfreebsd spelled as freebsd and kfreebsd_loadenv spelled as frebsd_loadenv, replace /boot/kernel/kernel with /boot/loader, and I in the loader I then had to set currdev=disk1a (shown by lsdev) and load /boot/kernel/kernel. qemu was started like this: qemu-system-x86_64 -cdrom super_grub2_disk_hybrid_2.00s1-beta5.iso -hda FreeBSD-9.2-RC1-amd64-memstick.img -m 512 -boot d -monitor stdio Letting super_grub2_disk_hybrid_2.00s1-beta5.iso boot the kernel directly via kfreebsd /boot/kernel/kernel fails tho because of a this bug in the vanilla grub 2.00 code: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699002 (The fix for that bug now is in our sysutils/grub2 port as well as in debian's grub 2.00 but apparently not yet in the super grub disk isos.) So maybe your problem is that loader needs currdev set at least in this case and in your old 9.0 installation it didn't? HTH, :) Juergen I still wonder why Super Grub Disk kfreebsd worked until recently. I figure something must have changed in FreeBSD loader or kernel structure since the Super Grub Disk didn't change in that time. For currdev, apparently the big hard drive is just recognized as one big drive with no reference to partitions (lsdev). Hmm that sounds like a problem and would explain why loader cannot boot that install, when it doesn't find the partition... Maybe this is another case of confusion caused by leftover partition table data? In that case you probably can fix this by backing up what you want to keep from that disk, dd'ing /dev/zero over beginning and end of it and then reinstalling everything... (What does gpart show say about that disk now when run from a booted system and also from the 9.2 live system?) I could try building grub2 from ports on both the hard-drive installation and the USB-stick amd64 installation, see what possibilities are then available. FreeBSD gpart can create a boot partition, but then the question is how to boot that when there is more than one OS partition. I can't simply put the FreeBSD boot partition at the start of the hard drive as I did with the USB sticks. I had a FreeDOS installation with syslinux on a USB stick that went bad (the USB stick hardware). That would permit me to have various boot images including grub4dos and Super Grub Disk to boot with syslinux without booting into FreeDOS. I'd re-create that, but the FreeDOS installer has proven tricky. I talked to the super grub disk people yesterday and they want to prepare an updated iso using debian's grub 2.00 (that has the kfreebsd = 9.1 kernel fix), and with the FreeBSD templates fixed also, _maybe_ that would then help you as well... New super grub disk iso is ready: https://forja.cenatic.es/frs/?group_id=204 https://forja.cenatic.es/frs/download.php/file/1587/super_grub2_disk_hybrid_2.00s1-beta6.iso https://forja.cenatic.es/frs/download.php/file/1586/super_grub2_disk_hybrid_2.00s1-beta6.iso.md5 Homepage: http://www.supergrubdisk.org/ Maybe you are lucky and this version works for you already... HTH, :) Juergen ___ 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: Change in loader or kernel: won't boot with kfreebsd in grub2
On Sun, Aug 11, 2013 at 05:31:10PM +, Thomas Mueller wrote: Has there been a change in loader or kernel format recently? Through FreeBSD 9.1 postrelease, I was able to boot with grub2 (Super Grub Disk) on the System Rescue CD (sysresccd.org) by set root=(hd0,gpt3) insmod ufs2 kfreebsd /boot/loader boot but that no longer works. That was the method suggested in $PORTSDIR/sysutils/grub2/pkg-message I just source-upgraded from 9.2-BETA2 to what is now called 9.2-PRERELEASE uname -a shows FreeBSD amelia2 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #17 r254196: Sun Aug 11 00:36:49 UTC 2013 root@amelia2:/usr/obj/usr/src/sys/SANDY amd64 Fortunately, I also installed to a USB stick, GPT-partitioned with the first partition being freebsd-boot, so I boot with that, and to get the hard-drive installation, escape to loader prompt and type set boot_askname and then ufs:/dev/ada0p3 at the mountroot prompt. I want to use the hard drive for more than one OS: FreeBSD and Linux. For forensic, testing purposes, I tested and was able to boot the old 9.0-BETA1 installation by set root=(hd0,gpt9) insmod ufs2 kfreebsd /boot/loader boot which is why I think there was possibly a change in loader or kernel format. I was worried that my Western Digital Caviar Green 3 TB hard drive was starting to go bad, but now it looks like maybe a change in FreeBSD loader or kernel format. Hmm I just tested super_grub2_disk_hybrid_2.00s1-beta5.iso from http://www.supergrubdisk.org/category/download/supergrub2diskdownload/ if it can boot FreeBSD-9.2-RC1-amd64-memstick.img in qemu and I had to fix kfreebsd spelled as freebsd and kfreebsd_loadenv spelled as frebsd_loadenv, replace /boot/kernel/kernel with /boot/loader, and I in the loader I then had to set currdev=disk1a (shown by lsdev) and load /boot/kernel/kernel. qemu was started like this: qemu-system-x86_64 -cdrom super_grub2_disk_hybrid_2.00s1-beta5.iso -hda FreeBSD-9.2-RC1-amd64-memstick.img -m 512 -boot d -monitor stdio Letting super_grub2_disk_hybrid_2.00s1-beta5.iso boot the kernel directly via kfreebsd /boot/kernel/kernel fails tho because of a this bug in the vanilla grub 2.00 code: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699002 (The fix for that bug now is in our sysutils/grub2 port as well as in debian's grub 2.00 but apparently not yet in the super grub disk isos.) So maybe your problem is that loader needs currdev set at least in this case and in your old 9.0 installation it didn't? HTH, :) Juergen ___ 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: VIDIOC_ENUM_FRAMESIZES in linux_ioctl.c
On Sun, Jan 13, 2013 at 06:11:13PM +0200, Markiyan Kushnir wrote: Hi, Any reason why LINUX_VIDIOC_ENUM_FRAMESIZES, LINUX_VIDIOC_ENUM_FRAMEINTERVALS, LINUX_VIDIOC_ENCODER_CMD, and LINUX_VIDIOC_TRY_ENCODER_CMD in compat/linux/linux_ioctl.c have been put under #ifdef VIDIOC_ENUM_FRAMESIZES (looks like it's been there since rev. 221426, when the v4l2 support was introduced) ? I've just hit an issue with the current Skypes in the ports tree (both 2.1.0.81 and 2.2.0.35) trying to call at least the LINUX_VIDIOC_ENUM_FRAMESIZES ioctl, so I re-built linux.ko with -DVIDIOC_ENUM_FRAMESIZES and found no visible issues on my desktop so far beyond that my skype started to send video. If there is some reason, it would be good to let people know why these ioctls are turned off by default. IIRC netchild's concern was that these were not in Linux 2.6.16 that our Linuxolator defaults to emulating, so I put them under #ifdef. Did you find that skype video doesn't work without them? Back when I tested it it didn't seem to make a difference... (Tho I never could get skype 2.2.0.35 to work with video, I think because it tries to use inotify() which we don't emulate.) HTH, Juergen ___ 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
Fix for grub 2.00/bzr kfreebsd to boot 9.1 kernels
Hi! I'm in the process of testing 9.1 on the laptop where I use grub2 because I had to put bsd in an `extended' slice, and I found out grub2 won't boot the 9.1 kernel. Asked on #grub where phcoder found the fix after I made him a test iso using grub-mkrescue: http://paste.debian.net/180121/ Applied that to grub 2.00 from here: http://ftp.gnu.org/gnu/grub/grub-2.00.tar.xz (built on a Linux debian slice with checkinstall), and that got the 9.1 kernel booting. So maybe the sysutils/grub2 maintainer (Cc'd) wants to update the port to 2.00 and add the patch in files/? :) (It's still at 1.98 currently where the patch doesn't apply.) The kfreebsd way to boot this affects is the same as in this earlier post: http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-March/011828.html (i.e. this is not chainloading bsd's loader but grub loading the kernel and klds itself. I think this way to boot was originally added by the debian kfreebsd guys, hence the command kfreebsd...) HTH, Juergen ___ 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: Fix for grub 2.00/bzr kfreebsd to boot 9.1 kernels
On Sat, Jul 21, 2012 at 02:21:49PM -0700, Doug Barton wrote: [ Removed -current, not relevant to 9.x ] On 07/21/2012 11:58, Juergen Lock wrote: Hi! I'm in the process of testing 9.1 on the laptop where I use grub2 because I had to put bsd in an `extended' slice, and I found out grub2 won't boot the 9.1 kernel. Nothing will boot FreeBSD on an extended slice, I'm surprised it even installed. I don't remember how I installed 9.0 back then, maybe it was manually, but yes grub boots it just fine, and with the fix also after updating to RELENG_9. zsh enceladus% uname -a FreeBSD enceladus.kn-bremen.de 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Fri Jul 20 21:28:23 CEST 2012 n...@enceladus.kn-bremen.de:/usr/obj/d3t/d3t/home/nox/src91/src/sys/ENCELADUS amd64 zsh enceladus% df -k Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/ada0s7a 8245660 6150304 143570481%/ [...] Cheers, Juergen ___ 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: Fix for grub 2.00/bzr kfreebsd to boot 9.1 kernels
On Sat, Jul 21, 2012 at 01:40:10PM -0700, Rick wrote: Hi Juergen, Hi! My email address has changed so don't be alarmed if your CC bounces. :) Ah yeah I just saw the bounce. :) An update of grub2 is long overdue, so I'll work on that right now. Cool, thanx! Juergen ___ 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: Fix for grub 2.00/bzr kfreebsd to boot 9.1 kernels
On Sat, Jul 21, 2012 at 06:44:06PM -0700, Doug Barton wrote: On 07/21/2012 17:21, Juergen Lock wrote: On Sat, Jul 21, 2012 at 02:21:49PM -0700, Doug Barton wrote: [ Removed -current, not relevant to 9.x ] On 07/21/2012 11:58, Juergen Lock wrote: Hi! I'm in the process of testing 9.1 on the laptop where I use grub2 because I had to put bsd in an `extended' slice, and I found out grub2 won't boot the 9.1 kernel. Nothing will boot FreeBSD on an extended slice, I'm surprised it even installed. I don't remember how I installed 9.0 back then, maybe it was manually, but yes grub boots it just fine, and with the fix also after updating to RELENG_9. zsh enceladus% uname -a FreeBSD enceladus.kn-bremen.de 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Fri Jul 20 21:28:23 CEST 2012 n...@enceladus.kn-bremen.de:/usr/obj/d3t/d3t/home/nox/src91/src/sys/ENCELADUS amd64 zsh enceladus% df -k Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/ada0s7a 8245660 6150304 143570481%/ [...] Well I'm happy to be proven wrong. Do you have one big partition, or were you able to partition it? And do you have more than one FreeBSD installed? I have /usr too as well as /altroot and /altroot/usr where I tested head (and data partitions on a 3 TB esata disk that I have to remember to power down before booting Windows 7 or it messes up the gpt header on that disk...) Cheers, Juergen ___ 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: Cannot get flashplugin to work
In article op.wf3wn8m734t2sn@tech304 you write: On Mon, 18 Jun 2012 10:25:10 -0500, Michael Gass mg...@csbsju.edu wrote: Cannot get the linux flashplugin to work on either firefox or chrome. 9-STABLE here without issues. Can you post: /etc/rc.conf /etc/fstab output of `kldstat` output of `mount` output of `uname -a` In addition try running nspluginwrapper as user instead of as root, I think /usr/local/lib/browser_plugins has been dropped from the search path of some(?) browsers in the meantime. HTH, :) Juergen ___ 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
geom vs. removable disks/cards (was: Re: random problem with 8.3 from yesterday)
In article 1330126840.7317.60.ca...@revolution.hippie.lan you write: On Sat, 2012-02-25 at 00:39 +0200, Andriy Gapon wrote: on 24/02/2012 18:23 Ian Lepore said the following: I've always suspected something in the geom layer isn't noticing that a CF or SD card in the reader got removed/inserted/reformatted, and un-/re-plugging the whole reader (making the cam layer destroy and recreate the devices) makes geom aware of the change. This is a fact, actually. Nothing in GEOM layer (and below it) notices a silent card change, since most hardware doesn't have any notification for the change and FreeBSD disk stack doesn't do any polling for changes. If the hardware did have change notification, is there a mechanism that would communicate that to geom? That's a precursor question to my real question: is there a way to manually kick geom when necessary? If the api exists but there's no userland app to make the needed calls, I'll write some code -- just point me at a manpage or header file. scsi has a mechanism called unit attention to report things like media changes, not sure usb devices use that tho since the host can only poll them... Anyway, the usual workaround is to force a geom retaste by opening the device for writing without actually writing anything, e.g.: # : /dev/da0 Btw this can't be Erich's problem I'd say since he said he's plugging in a thumbdrive not a card into a reader (and also writing /dev/zero to it) so geom _should_ already taste it. (Unless the write fails since the thumbdrive is too slow initializing or something like that...) HTH, Juergen ___ 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: v4l2 8-stable MFC: testers needed
On Wed, Jun 08, 2011 at 04:38:22PM +0200, Alexander Leidinger wrote: Quoting Alexander Leidinger alexan...@leidinger.net (from Wed, 08 Jun 2011 14:01:10 +0200): at http://www.Leidinger.net/test/v4l2-stable8.diff I have the v4l2 code I want to commit to 8-stable. Can someone please compile it, test it and give feedback? It looks like svn does not take added files into account, so everyone who wants to give it a try should take linux_videodev2.h and linux_videodev2_compat.h from -current. Looking good... skype at least works. :) Thanx, Juergen ___ 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: Panic from linux emulation (flashplugin)
In article op.vq9kcoyl34t2sn@tech304 you write: I'm sending this to both stable and emulation lists, but I'm not subscribed to the emulation list so please cc: me there. Hi guys, I'm told this is known but I can't find any information. I'm running the checkout for RELENG_8_2 from Thursday and the issue I'm having on my amd64 Desktop is that every time I play a flash video (my only real use of linux emulation) it causes a kernel panic. This happens in Opera, Firefox, and Chromium. Another user in Freenode's ##freebsd said he is experiencing this too. I've seen nothing mentioned on the freebsd-emulation mailing list. Any thoughts? Well it works for me, just tested with native ff, linux ff and linux opera... (other than youtube seems to be overloaded at this time, videos pause a lot.) Thanks, Mark Relevant info: 10:56:08 skeletor:~ uname -a FreeBSD skeletor.feld.me 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Thu Feb 17 13:03:46 CST 2011 r...@mwi1.coffeenet.org:/usr/obj/usr/src/sys/GENERIC amd64 10:57:11 skeletor:~ sudo kldstat Password: Id Refs AddressSize Name 1 53 0x8010 c9fe20 kernel 21 0x80da 24d98snd_hda.ko 34 0x80dc5000 75668sound.ko 41 0x80e3b000 13b98snd_uaudio.ko 51 0x80e4f000 f080 aio.ko 61 0x80e5f000 ffb0 ahci.ko 71 0x80e6f000 52d8 atapicam.ko 81 0x80e75000 d08de0 nvidia.ko 93 0x81b7e000 42558linux.ko 103 0x81bc1000 45ed0vboxdrv.ko 111 0x81e22000 3ee0 linprocfs.ko 122 0x81e26000 28ae vboxnetflt.ko 132 0x81e29000 8d44 netgraph.ko 141 0x81e32000 1532 ng_ether.ko 151 0x81e34000 d0c vboxnetadp.ko 161 0x81e35000 a1c pflog.ko 171 0x81e36000 2bd81pf.ko 181 0x81e62000 a8ea fuse.ko I was running linux-f10-flashplugin10 10.2r152 I see you use the nvidia blob (I use radeon with xorg drivers), did you rebuild the nvidia driver port after upgrading to 8.2? Or maybe this has something to do with the vdpau support that was added to flash with the last update and that others reported as possibly not working properly on FreeBSD... If you did rebuild nvidia try mv.ing /compat/linux/usr/lib/libvdpau.so.1 away temporarily and see if that fixes the panics, if yes its probably an nvidia issue. And even if not I guess you need to collect a backtrace or at least a textdump of the panic, see here about how to get a dump: http://www.freebsd.org/doc/en/books/developers-handbook/book.html#KERNELDEBUG-OBTAIN If the dumping/savecore/crashinfo script worked you should get a new /var/crash/core.txt.X file with the backtrace (among other things) after the next boot. Good luck, :) Juergen ___ 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: Panic from linux emulation (flashplugin)
On Mon, Feb 21, 2011 at 02:48:19PM -0600, Mark Felder wrote: On Mon, 21 Feb 2011 13:24:25 -0600, Juergen Lock n...@jelal.kn-bremen.de wrote: I see you use the nvidia blob (I use radeon with xorg drivers), did you rebuild the nvidia driver port after upgrading to 8.2? Or maybe this has something to do with the vdpau support that was added to flash with the last update and that others reported as possibly not working properly on FreeBSD... Aha! This is probably it! I just upgraded my workstation at work to 8.2 (also nvidia) and I am not having the crash but I also don't have that newer flash version that includes vdpau support. I will downgrade the flash version at home and report back. So on the box that got the panic the nvidia driver port was rebuilt after the src/kernel upgrade? It would possibly also be wise to contact the maintainer and have him mark the port as BROKEN or conflicting or something if you're running nvidia so people don't run into this issue. The maintainer is emulation@... :) But yes if its confirmed and can't be fixed we should probably patch the flash binary to stop it from trying to load libvdpau (like by patching the filename to something nonexisting?) Juergen ___ 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: new umass panic on 7-stable built today
On Wed, Jul 14, 2010 at 08:49:10PM +0400, pluknet wrote: On 20 July 2009 01:52, Juergen Lock n...@jelal.kn-bremen.de wrote: Hi! So I wanted to use an usb key on this freshly updated 7-stable box, and got a panic just after plugging it in: :( zsh triton# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.9 ... umass0: OCZ Technology ATV, class 0/0, rev 2.00/11.00, addr 2 on uhub5 umass0:1:0:-1: Attached to scbus1 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x290 fault code = supervisor read data, page not present instruction pointer = 0x8:0x804d67d4 stack pointer = 0x10:0xff8085487da0 frame pointer = 0x10:0xff8085487de0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 38 (usb5) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x2b3 trap_pfault() at trap_pfault+0x294 trap() at trap+0x312 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x804d67d4, rsp = 0xff8085487da0, rbp = 0xff8085487de0 --- usb_transfer_complete() at usb_transfer_complete+0x1d4 bus_dmamap_load() at bus_dmamap_load+0x314 usbd_transfer() at usbd_transfer+0xee usbd_do_request_flags_pipe() at usbd_do_request_flags_pipe+0x8f usbd_do_request_flags() at usbd_do_request_flags+0x25 usbd_get_string_desc() at usbd_get_string_desc+0x9b usbd_get_string() at usbd_get_string+0x83 uhub_child_pnpinfo_str() at uhub_child_pnpinfo_str+0xd9 devaddq() at devaddq+0xd5 device_attach() at device_attach+0x13a usbd_new_device() at usbd_new_device+0x821 uhub_explore() at uhub_explore+0x1bd usb_discover() at usb_discover+0x38 usb_event_thread() at usb_event_thread+0x8a fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8085488d30, rbp = 0 --- Uptime: 1m1s Physical memory: 8176 MB Dumping 4605 MB: 4590 4574 4558 4542 4526 4510 4494 4478 4462 4446 4430 4414 4398 4382 4366 4350 4334 4318 4302 4286 4270 4254 4238 4222 4206 4190 4174 4158 4142 4126 4110 4094 4078 4062 4046 4030 4014 3998 3982 3966 3950 3934 3918 3902 3886 3870 3854 3838 3822 3806 3790 3774 3758 3742 3726 3710 3694 3678 3662 3646 3630 3614 3598 3582 3566 3550 3534 3518 3502 3486 3470 3454 3438 3422 3406 3390 3374 3358 3342 3326 3310 3294 3278 3262 3246 3230 3214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270 2254 2238 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kernel/umass.ko.symbols...done. done. Loaded symbols for /boot/kernel/umass.ko #0 doadump () at pcpu.h:195 195 __asm __volatile(movq %%gs:0,%0 : =r (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x80567248 in boot (howto=260) at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:418 #2 0x805676ac in panic (fmt=Variable fmt is not available. ) at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:574 #3 0x8082f953 in trap_fatal (frame=0xc, eva=Variable eva is not available. ) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:756 #4 0x8082fd34 in trap_pfault (frame=0xff8085487cf0, usermode=0) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:672 #5 0x808306e2 in trap (frame=0xff8085487cf0) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:443 #6 0x80819cce in calltrap () at /usr/home/nox/src72s2/src/sys/amd64/amd64/exception.S:218 #7 0x804d67d4 in usb_transfer_complete (xfer=0xff00046b1000) at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:949 #8 0x80815bf4 in bus_dmamap_load (dmat=0xff0004499880, map=0xff000478ec00, buf=0xff8085487fe0, buflen=0
Re: Pack of CAM improvements
In article 4b55d9d4.1000...@freebsd.org you write: Hi. Hi! I've made a patch, that should solve set of problems of CAM ATA and CAM generally. I would like to ask for testing and feedback. What patch does: - It unifies bus reset/probe sequence. Whenever bus attached at boot or later, CAM will automatically reset and scan it. It allows to remove duplicate code from many drivers. - Any bus, attached before CAM completed it's boot-time initialization, will equally join to the process, delaying boot if needed. - New kern.cam.boot_delay loader tunable should help controllers that are still unable to register their buses in time (such as slow USB/ PCCard/ CardBus devices). - To allow synchronization between different CAM levels, concept of requests priorities was extended. Priorities now split between several run levels. Device can be freezed at specified level, allowing higher priority requests to pass. For example, no payload requests allowed, until PMP driver enable port. ATA XPT negotiate transfer parameters, periph driver configure caching and so on. - Frozen requests are no more counted by request allocation scheduler. It fixes deadlocks, when frozen low priority payload requests occupying slots, required by higher levels to manage theit execution. - Two last changes were holding proper ATA reinitialization and error recovery implementation. Now it is done: SATA controllers and Port Multipliers now implement automatic hot-plug and should correctly recover from timeouts and bus resets. Patch can be found here: http://people.freebsd.org/~mav/cam-ata.20100119.patch Feedback as always welcome. Ok, applied this to stable/8, and the good news is the box still seems to run (using ahci(4) on an sb700 controller and siis(4) on a SiI3132 pcie card, altho atm there's only an optical drive on that one.) But what this still doesn't fix is the broken `test unit ready' command on ada devices, which also makes things like `cdrecord -scanbus' hang the bus. :( (A few days ago I also got a hang after wanting to try out xfburn, I suspect for the same reason...) Here is my earlier report: http://docs.freebsd.org/cgi/mid.cgi?20090817163144.GA2991 Oh and I also still use this patch to scsi_cd.c to be able to read discs that fail the `read toc' command, like bluray (data) discs. PR s here: http://www.freebsd.org/cgi/query-pr.cgi?pr=138789 Index: src/sys/cam/scsi/scsi_cd.c === RCS file: /home/scvs/src/sys/cam/scsi/scsi_cd.c,v retrieving revision 1.107.2.6 diff -u -p -u -r1.107.2.6 scsi_cd.c --- src/sys/cam/scsi/scsi_cd.c 25 Dec 2009 08:06:35 - 1.107.2.6 +++ src/sys/cam/scsi/scsi_cd.c 23 Jan 2010 13:29:19 - @@ -2874,11 +2874,17 @@ cdcheckmedia(struct cam_periph *periph) } softc-flags |= CD_FLAG_VALID_TOC; + +bailout: softc-disk-d_sectorsize = softc-params.blksize; softc-disk-d_mediasize = (off_t)softc-params.blksize * softc-params.disksize; +/* if bailout: + * is here read requests will fail when the toc cant be read although + * CD_FLAG_VALID_MEDIA is set. + */ /* * We unconditionally (re)set the blocksize each time the ___ 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: PUC Serial I/O problem - copy of gnats-filed bug report (as discussed previously)
Hi! In article 4b150d60.5050...@denninger.net you write: -=-=-=-=-=- Jeremy Chadwick wrote: On Sat, Nov 28, 2009 at 09:43:25PM -0600, Karl Denninger wrote: Karl Denninger wrote: Jeremy Chadwick wrote: On Fri, Nov 27, 2009 at 12:54:17PM -0600, Karl Denninger wrote: For what its worth, USB-based serial adapters also fail in the same way, but faster (they have NEVER been reliable in this regard, and this hasn't improved) There must be a regression of some kind, given that some FreeBSD developers have stated in the past that FTDI-based USB serial adapters work great: http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041615.html Original thread: http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041610.html I don't know where works great has come from. Certainly not my experience in heavy use. For non-modem-control heavy use, it works ok. I use an 8-port fanout on 7.x to drive process control and it's stable. However, for heavy modem use (e.g. Hylafax) it has NEVER been stable - although in 8.x it won't even manage to send ONE 10-page fax most of the time, where under 7.x it would randomly fail in that use. Then again the puc() driver based serial I/O was completely stable under 7.x and now, with the new architecture it will get one or two jobs through it before it blows up. -- Karl FYI I downgraded back to 7.2-STABLE (it was a bit hairy but I got it to work after a small amount of screwing around) via sources and again the machine and those serial ports are 100% stable with the old driver infrastructure. The uart() infrastructure in 8.x has to be considered broken and unusable for modems at this point folks. I recognize that nobody flagged it until just before the release (I hadn't tried it until RC2, and thus didn't know) but this is a literal dagger in the heart of anyone who needs to put an actual modem on an 8.x box using the common cards out there, and I assume it will bite just as hard for things like a dial-in console as it will for a fax server. Karl, I agree with you in this regard. However, I'm not sure what to recommend to you with regards to getting this issue the proper attention it needs. I fully agree with the Severity (serious) and Priority (high) of the PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/140947 Ed Schouten appears to be giving this attention, but I'd recommend that Email communication include mar...@freebsd.org, just in case it turns out that puc(4) needs some changes. I'm certain Ed will do his best to assist tracking this one down. :-) Added the suggested forward address to the list. just in case :) Yeah, this is pretty serious. It looks to me, at first blush, like an interrupt is being dropped on occasion and there is no watchdog timer in the driver code to catch it and unwedge the state machine. That's not supposed to be possible (dropped interrupts) on PCI (and PCI/Express) cards unless something is dramatically wrong in the code somewhere. It just occured to me that this might be related to a bug I fixed in qemu's serial hw emulation, http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=2d6ee8e7e17227d5eb8c6e9a054dd88d5b37c5ae which also caused tx irqs to get lost and which the old sio(4) driver had no problem with, only output on uart(4) then hung as a result. On that occasion I also learned that there is a priority list for irqs, for example rx irqs take precedence over tx ones, so maybe that explains why some irqs can get lost during `heavy use'? (And which the old driver recovered from I guess by checking status registers at least in the tx path too in addition to just accounting for irqs.) HTH, Juergen ___ 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: 8.0-RC1 panic attaching ppc
In article 4ac0f173.10...@cs.rice.edu you write: Daniel O'Connor wrote: On Sun, 27 Sep 2009, Alan Cox wrote: Ok, now I can explain what is happening. The kernel is using 1GB pages to implement the direct map. Unfortunately, pmap_extract() doesn't know how to handle a 1GB page mapping. pmap_kextract() only works by an accident of its different implementation. In other words, it should not be relied upon to work either. Please revert whatever patch John gave you and try the attached patch. It simply disables the use of 1GB page mapping by the direct map. Your patch fixes (works around?) the problem. Thanks. I've committed the patch. Yes, it's a work around. Fortunately(?), on my test machine, I don't see any measurable effect from disabling the use of 1GB pages by the direct map. Btw I had reported the same issue back in June already, http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008709.html and yes your patch fixes it for me too. Thanx! (And of the other two issues mentioned in the next posting, http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008711.html the tdq_notify trap appears to be solved, but the ata issue was never fixed, I had to work around it by putting the affected optical drive on a pcie sata card driven by siis(4).) Cheers, Juergen ___ 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: status of flash9/flash10 support in RELENG_7 ?
In article 20090725013500.gc62...@onelab2.iet.unipi.it you write: Does anyone know what is the status of flash9 or flash10 in RELENG_7 ? Following the thread of a couple of months ago, i tried to: - remove all linux-* ports - set the following in /etc/make.conf OVERRIDE_LINUX_BASE_PORT=f8 OVERRIDE_LINUX_NONBASE_PORTS=f8 - set the following in /etc/sysctl.conf compat.linux.osrelease=2.6.16 - set the following in /etc/fstab linproc /usr/compat/linux/proc linprocfs rw 0 0 - reinstall linux_base-f8-8_11 - reinstall linux-flashplugin-10.0r22 (which in turn brings in the relevant linux-f8-* ports) - also install nspluginwrapper and create a firefox plugin - upgrade firefox to firefox-3.5,1 (native), just in case - run firefox with limit stacksize 4megabytes (or variants) as recommended to avoid npviewer growing/not dying This was done on 3 different machines (one laptop with a centrino, 2 desktops with AMD X2 dual core running in i386 mode) with mixed [in]success. On one machine thing started working well, but on the other two they did not (the various packages were of course slightly disaligned) and while trying to replicate the configuration i also broke the good one without figuring out why. Symptoms are that on certain sites or actions (e.g. switch to full screen on youtube videos) i get firefox freezing like this 22381 luigi 13 960 82580K 57484K ucond 1 0:00 0.20% firefox-bin 22413 luigi 1 970 72920K 33448K futex 1 0:00 0.20% npviewer.bin 22414 luigi 1 970 72920K 33448K futex 1 0:00 0.20% npviewer.bin and recovering control (but no video) after 10+seconds I also get a lot of the following weak_unref warnings with various addresses (firefox-bin:22381): GLib-GObject-WARNING **: IA__g_object_weak_unref: couldn't find weak ref 0x297ba9f0(0x2a10d110) (but not sure how related is this, because it happens even without a flash plugin). I have also tried flash9 instead of flash10, o fc10 instead of fc8, all with similar results. Is there a recipe for a working flas9 or flash10 operation ? Hmm. All I can say is I'm not sure I can even remember flash hanging since I lowered the stack limit using this nspluginwrapper patch: http://docs.freebsd.org/cgi/mid.cgi?20090630184146.GA39346 (btw still no words from the nspluginwrappper port maintainer about this, or I missed them? Cc'd again...) _When_ flash hung, I usually got it back to running by doing `killall npviewer.bin' and optionally quitting ff and doing `rm /tmp/_org_wrapper_NSPlugins_libflashplayer.so*' and then restarting the browser. (If you don't do that, remaining npviewer.bin processes might interfere with later ff sessions making flash appear more broken than it really is...) HTH, Juergen ___ 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
new umass panic on 7-stable built today
Hi! So I wanted to use an usb key on this freshly updated 7-stable box, and got a panic just after plugging it in: :( zsh triton# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.9 ... umass0: OCZ Technology ATV, class 0/0, rev 2.00/11.00, addr 2 on uhub5 umass0:1:0:-1: Attached to scbus1 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x290 fault code = supervisor read data, page not present instruction pointer = 0x8:0x804d67d4 stack pointer = 0x10:0xff8085487da0 frame pointer = 0x10:0xff8085487de0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 38 (usb5) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x2b3 trap_pfault() at trap_pfault+0x294 trap() at trap+0x312 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x804d67d4, rsp = 0xff8085487da0, rbp = 0xff8085487de0 --- usb_transfer_complete() at usb_transfer_complete+0x1d4 bus_dmamap_load() at bus_dmamap_load+0x314 usbd_transfer() at usbd_transfer+0xee usbd_do_request_flags_pipe() at usbd_do_request_flags_pipe+0x8f usbd_do_request_flags() at usbd_do_request_flags+0x25 usbd_get_string_desc() at usbd_get_string_desc+0x9b usbd_get_string() at usbd_get_string+0x83 uhub_child_pnpinfo_str() at uhub_child_pnpinfo_str+0xd9 devaddq() at devaddq+0xd5 device_attach() at device_attach+0x13a usbd_new_device() at usbd_new_device+0x821 uhub_explore() at uhub_explore+0x1bd usb_discover() at usb_discover+0x38 usb_event_thread() at usb_event_thread+0x8a fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8085488d30, rbp = 0 --- Uptime: 1m1s Physical memory: 8176 MB Dumping 4605 MB: 4590 4574 4558 4542 4526 4510 4494 4478 4462 4446 4430 4414 4398 4382 4366 4350 4334 4318 4302 4286 4270 4254 4238 4222 4206 4190 4174 4158 4142 4126 4110 4094 4078 4062 4046 4030 4014 3998 3982 3966 3950 3934 3918 3902 3886 3870 3854 3838 3822 3806 3790 3774 3758 3742 3726 3710 3694 3678 3662 3646 3630 3614 3598 3582 3566 3550 3534 3518 3502 3486 3470 3454 3438 3422 3406 3390 3374 3358 3342 3326 3310 3294 3278 3262 3246 3230 3214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270 2254 2238 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kernel/umass.ko.symbols...done. done. Loaded symbols for /boot/kernel/umass.ko #0 doadump () at pcpu.h:195 195 __asm __volatile(movq %%gs:0,%0 : =r (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x80567248 in boot (howto=260) at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:418 #2 0x805676ac in panic (fmt=Variable fmt is not available. ) at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:574 #3 0x8082f953 in trap_fatal (frame=0xc, eva=Variable eva is not available. ) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:756 #4 0x8082fd34 in trap_pfault (frame=0xff8085487cf0, usermode=0) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:672 #5 0x808306e2 in trap (frame=0xff8085487cf0) at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:443 #6 0x80819cce in calltrap () at /usr/home/nox/src72s2/src/sys/amd64/amd64/exception.S:218 #7 0x804d67d4 in usb_transfer_complete (xfer=0xff00046b1000) at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:949 #8 0x80815bf4 in bus_dmamap_load (dmat=0xff0004499880, map=0xff000478ec00, buf=0xff8085487fe0, buflen=0, callback=0x804d68b0 usbd_start_transfer, callback_arg=0xff00046b1000, flags=0) at /usr/home/nox/src72s2/src/sys/amd64/amd64/busdma_machdep.c:738 #9 0x804d6f2e in usbd_transfer (xfer=0xff00046b1000) at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:312 #10
linprocfs patch for RELENG_6_4 (to make flash9 work), please test!
Hi! I've updated the patch I've tested on 6.3 for 6.4 (only offsets differ), if anyone can test it I can file a PR so it hopefully :) can be committed: http://people.freebsd.org/~nox/linprocfs-6.4.patch (same patch for 6.3: http://people.freebsd.org/~nox/linprocfs-6.3.patch ) The original posting with the patch for RELENG_7 that I used is here: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-October/005331.html You probably want the updated libflashsupport.so from in there too, its at http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20081001/3194e994/libflashsupport.so - as mentioned there you want to copy it to /compat/linux/usr/lib after installing the flash9 and nspluginwrapper ports. Oh and you still need to comment out the IGNORE line in the flash9 port's Makefile too. There's also a cpuset/*affinity patch for RELENG_7 posted here, http://docs.freebsd.org/cgi/mid.cgi?20081002071321.GA61530 6 doesn't have this code, so if the 6.4 linprocfs patch doesn't work for you on an SMP box please also test with SMP disabled. (Tho if you have SMP you probably should be running 7 anyway. :) Thanx, Juergen PS: don't forget to mount linprocfs to /compat/linux/proc after updating it :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dtrace: processing aborted: Abort due to systemic unresponsiveness (dtrace_gethrtime()?) - and kgdb
On Wed, Sep 17, 2008 at 10:41:07PM +0200, I wrote: Hi! I got curious in dtrace, and after mr's sys/amd64/amd64/trap.c commit (r183050, thanx! :) I was able to build a kernel that could kldload dtraceall on 7-stable amd64, but trying even simple things like dtrace -n tick-1sec only runs for a short time, or not at all, ending with $subject: # dtrace -n tick-1sec dtrace: description 'tick-1sec' matched 1 probe dtrace: buffer size lowered to 2m CPU IDFUNCTION:NAME 1 32125 :tick-1sec dtrace: processing aborted: Abort due to systemic unresponsiveness # dtrace -n tick-1sec dtrace: description 'tick-1sec' matched 1 probe dtrace: buffer size lowered to 2m dtrace: processing aborted: Abort due to systemic unresponsiveness # Looking around on the net I find that this is probably related to dtrace_gethrtime() (this box is SMP), which I see defined in sys/amd64/amd64/tsc.c, but also in sys/cddl/dev/dtrace/amd64/dtrace_subr.c, and in sys/cddl/dev/dtrace/i386/dtrace_subr.c, but nowhere under sys/i386. The versions in sys/cddl/dev/dtrace take cpu-dependent tsc offsets into account which the one in sys/amd64/amd64/tsc.c doesn't, is there any particular reason this version is used? Also I don't see it in HEAD... I since found out two things: a) the version of dtrace_gethrtime() in sys/amd64/amd64/tsc.c is indeed not needed, and b) removing it still didn't fix my problem, stopping powerd then did, even with the original kernel. Doh! :) Anyway, I'm still pretty sure the #ifdef KDTRACE_HOOKS code in sys/amd64/amd64/tsc.c can go, the version of dtrace_gethrtime() in sys/cddl/dev/dtrace/amd64/dtrace_subr.c looks more correct at least... Thanx, Juergen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
dtrace: processing aborted: Abort due to systemic unresponsiveness (dtrace_gethrtime()?) - and kgdb
Hi! I got curious in dtrace, and after mr's sys/amd64/amd64/trap.c commit (r183050, thanx! :) I was able to build a kernel that could kldload dtraceall on 7-stable amd64, but trying even simple things like dtrace -n tick-1sec only runs for a short time, or not at all, ending with $subject: # dtrace -n tick-1sec dtrace: description 'tick-1sec' matched 1 probe dtrace: buffer size lowered to 2m CPU IDFUNCTION:NAME 1 32125 :tick-1sec dtrace: processing aborted: Abort due to systemic unresponsiveness # dtrace -n tick-1sec dtrace: description 'tick-1sec' matched 1 probe dtrace: buffer size lowered to 2m dtrace: processing aborted: Abort due to systemic unresponsiveness # Looking around on the net I find that this is probably related to dtrace_gethrtime() (this box is SMP), which I see defined in sys/amd64/amd64/tsc.c, but also in sys/cddl/dev/dtrace/amd64/dtrace_subr.c, and in sys/cddl/dev/dtrace/i386/dtrace_subr.c, but nowhere under sys/i386. The versions in sys/cddl/dev/dtrace take cpu-dependent tsc offsets into account which the one in sys/amd64/amd64/tsc.c doesn't, is there any particular reason this version is used? Also I don't see it in HEAD... Wondering, Juergen PS: I also found out that kgdb doesn't seem to like dtrace bits in the kernel, backtraces look like from a kernel without debug symbols, even if I don't use dtrace or even kldload it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kqemu support: not compiled
In article [EMAIL PROTECTED] you write: On Tue, 13 May 2008 00:18:32 EDT bazzoola [EMAIL PROTECTED] wrote: On May 12, 2008, at 10:20 PM, Bakul Shah wrote: I just cant get kqemu to work on my AMD64 SMP! echo kqemu_enable=YES /etc/rc.conf /usr/local/etc/rc.d/kqemu start This should probably be described in pkg-message. I looked at the rc script and all it does is kldload aio and kqemu. I already have them loaded by default. You didn't provide information so I had to guess. This still does not help me with my problem. I press Ctrl + Alt + 2 then I type info kqemu I get kqemu support: not compiled Are you running qemu? It is an i386 emulator and won't use kqemu on amd64. You need to run qemu-system-x86_64. I know, this is a bit confusing. I just added notes about these two things to the pkg-message(s)... Juergen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with umass (with USB tape and Amanda)
In article [EMAIL PROTECTED] you write: Hello everybody, Hi! I have just had a panic on 6.2 amd64 box with ehci connected USB DDS4 tape drive while it was for the first time being accessed with Amanda. I have previously successfully tested it with tar. I have a kernel crash dump with the following information: panic: trying to sleep while sleeping is prohibited cpuid = 0 KDB: stack backtrace: panic() at panic+0x250 sleepq_add() at sleepq_add+0x225 msleep() at msleep+0x132 bwait() at bwait+0x55 swap_pager_putpages() at swap_pager_putpages+0x45c vm_pageout_flush() at vm_pageout_flush+0x13b vm_contig_launder_page() at vm_contig_launder_page+0xdc vm_page_alloc_contig() at vm_page_alloc_contig+0x321 contigmalloc() at contigmalloc+0x5f7 bus_dmamem_alloc() at bus_dmamem_alloc+0x80 usb_block_allocmem() at usb_block_allocmem+0x118 ... This looks like the known problem of bus_dmamem_alloc sleeping when it shouldn't (its being called with BUS_DMA_NOWAIT), which has hit me with usb before. Workarounds: 1. add more RAM (this seems to be triggered by page shortage/fragmentation) 2. reboot before you use the device 3. try the HPS usb stack, it may have worked around this issue: http://www.turbocat.net/~hselasky/usb4bsd/ (I hope this is still the right url, I haven't used the stack in a while.) HTH, Juergen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
devfs weirdness with kqemu
I got a report of this on irc: # kldload kqemu $ ls -l /dev/kqemu* ls: /dev/kqemu*: No such file or directory $ ls -l /dev/kqemu crw-rw 1 root wheel 220, 0 Apr 7 15:54 /dev/kqemu $ ls -l /dev/kqemu* crw-rw 1 root wheel 220, 0 Apr 7 15:54 /dev/kqemu0 crw-rw 1 root wheel 220, 1 Apr 7 15:54 /dev/kqemu1 Is this something the kld is doing wrong (/usr/ports/emulators/kqemu-kmod) or is it a devfs problem? The report I got was for 6.0, but it also happens for me on RELENG_5. This is nothing serious (kqemu works), but it certainly can be confusing for users... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cdboot troubles; 6.0 kernel hanging
On Thu, Dec 22, 2005 at 10:55:58PM +0100, Juergen Lock wrote: On Wed, Dec 21, 2005 at 11:15:30PM +0100, Juergen Lock wrote: I have this box that apparently no longer likes FreeBSD's cdboot, it prints something about BOOT/LOADER and then just reboots. Any ideas how to debug something like that? The box already has FreeBSD installed (5.3 with some patches), and i tried copying the 6.0 kernel from disc1 and loading it manually at the loader prompt. It hangs after printing (boot -v): GEOM: new disk ad0 GEOM: new disk ad4 ad0 is on oboard pata (the board is a via kt400), ad4 is a single disk on a Promise Fasttrack tx2200 sata controller. I guess i could try to build a 6.0 kernel with ddb, but what would i be looking for then to find out why its hanging? [...] Nevermind, 6.0 boots now... (pilot error :) Leaving only the problem of the rebooting cdboot... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cdboot troubles; 6.0 kernel hanging
On Wed, Dec 21, 2005 at 11:15:30PM +0100, Juergen Lock wrote: I have this box that apparently no longer likes FreeBSD's cdboot, it prints something about BOOT/LOADER and then just reboots. Any ideas how to debug something like that? The box already has FreeBSD installed (5.3 with some patches), and i tried copying the 6.0 kernel from disc1 and loading it manually at the loader prompt. It hangs after printing (boot -v): GEOM: new disk ad0 GEOM: new disk ad4 ad0 is on oboard pata (the board is a via kt400), ad4 is a single disk on a Promise Fasttrack tx2200 sata controller. I guess i could try to build a 6.0 kernel with ddb, but what would i be looking for then to find out why its hanging? [...] I have now done that, here is a boot -v and ddb `ps' and `show thread' log of the hanging RELENG_6_0 GENERIC with ddb, does that tell anyone anything? (i dunno if the `call boot' crash at the end is important, probably not.) I need help... Oh, would it help if i retried this with a -current kernel? (I don't want to actually put -current on this box because it is my router and i want it to be stable, i just wanted to upgrade it to 6.0...) snip- OK boot -v -s /boot/kernel/acpi.ko text=0x3fbfc data=0x1c04+0x112c syms=[0x4+0x72f0+0x4+0x97c7] KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=0009a000 SMAP type=02 base=000f len=0001 SMAP type=02 base=fec0 len=1000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base= len=0001 SMAP type=02 base=0009a000 len=6000 SMAP type=01 base=0010 len=1fef SMAP type=03 base=1fff3000 len=d000 SMAP type=04 base=1fff len=3000 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-p1 #1: Thu Dec 22 21:47:15 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/home/nox/src6/src/sys/GENERICDB Preloaded elf kernel /boot/kernel/kernel.60db at 0xc0a98000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0a9825c. link_elf: symbol ioapic_enable_mixed_mode undefined KLD file acpi.ko - could not finalize loading MP Configuration Table version 1.1 found at 0xc00f1400 APIC: Using the MPTable enumerator. MPTable: OEM0 PROD Calibrating clock(s) ... i8254 clock: 1193267 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2075028490 Hz CPU: AMD Athlon(tm) XP 2600+ (2075.03-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x681 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536805376 (511 MB) Physical memory chunk(s): 0x1000 - 0x00099fff, 626688 bytes (153 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c25000 - 0x1f6b7fff, 514404352 bytes (125587 pages) avail memory = 516055040 (492 MB) bios32: Found BIOS32 Service Directory header at 0xc00faf00 bios32: Entry = 0xfb370 (c00fb370) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb3a0 pnpbios: Bad PnP BIOS data checksum Other BIOS signatures found: ioapic0: Assuming intbase of 0 ioapic0: Routing external 8259A's - intpin 0 ioapic0: intpin 0 - ExtINT (edge, high) ioapic0: intpin 1 - ISA IRQ 1 (edge, high) ioapic0: intpin 2 - ISA IRQ 2 (edge, high) ioapic0: intpin 3 - ISA IRQ 3 (edge, high) ioapic0: intpin 4 - ISA IRQ 4 (edge, high) ioapic0: intpin 5 - ISA IRQ 5 (edge, high) ioapic0: intpin 6 - ISA IRQ 6 (edge, high) ioapic0: intpin 7 - ISA IRQ 7 (edge, high) ioapic0: intpin 8 - ISA IRQ 8 (edge, high) ioapic0: intpin 9 - ISA IRQ 9 (edge, high) ioapic0: intpin 10 - ISA IRQ 10 (edge, high) ioapic0: intpin 11 - ISA IRQ 11 (edge, high) ioapic0: intpin 12 - ISA IRQ 12 (edge, high) ioapic0: intpin 13 - ISA IRQ 13 (edge, high) ioapic0: intpin 14 - ISA IRQ 14 (edge, high) ioapic0: intpin 15 - ISA IRQ 15 (edge, high) ioapic0: intpin 16 - PCI IRQ 16 (level, low) ioapic0: intpin 17 - PCI IRQ 17 (level, low) ioapic0: intpin 18 - PCI IRQ 18 (level, low) ioapic0: intpin 19 - PCI IRQ 19 (level, low) ioapic0: intpin 20 - PCI IRQ 20 (level, low) ioapic0: intpin 21 - PCI IRQ 21 (level, low) ioapic0: intpin 22 - PCI IRQ 22 (level, low) ioapic0: intpin 23 - PCI IRQ 23 (level, low) ioapic0: intpin 16 bus ISA ioapic0: Routing IRQ 10
cdboot troubles; 6.0 kernel hanging
I have this box that apparently no longer likes FreeBSD's cdboot, it prints something about BOOT/LOADER and then just reboots. Any ideas how to debug something like that? The box already has FreeBSD installed (5.3 with some patches), and i tried copying the 6.0 kernel from disc1 and loading it manually at the loader prompt. It hangs after printing (boot -v): GEOM: new disk ad0 GEOM: new disk ad4 ad0 is on oboard pata (the board is a via kt400), ad4 is a single disk on a Promise Fasttrack tx2200 sata controller. I guess i could try to build a 6.0 kernel with ddb, but what would i be looking for then to find out why its hanging? I'll append 5.3's boot -v dmesg. (btw i see a lot more of the ata4-master: stat=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 lines with the 6.0 kernel than with 5.3...) Thanx, Juergen ---snip penalty: 480 480 530 5480 5480 5480 5480 5480 50480 50480100480 pcib0: slot 9 INTA routed to irq 11 via \\_SB_.PCI0.LNKB found- vendor=0x105a, dev=0x3571, revid=0x02 bus=0, slot=9, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=1 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x12 (4500 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D3 current D0 map[10]: type 1, range 32, base e812, size 17, enabled map[14]: type 1, range 32, base e814, size 17, enabled map[18]: type 4, range 32, base a800, size 6, enabled pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.LNKC) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKA (references 12, priority 257160): interrupts: 10 51112 7 6 4 315 14 1 penalty: 960 1010 1080 5960 5960 5960 5960 5960 50960 50960100960 \\_SB_.PCI0.LNKC (references 12, priority 257160): interrupts: 10 51112 7 6 4 315 14 1 penalty: 960 1010 1080 5960 5960 5960 5960 5960 50960 50960100960 \\_SB_.PCI0.LNKD (references 12, priority 257160): interrupts: 10 51112 7 6 4 315 14 1 penalty: 960 1010 1080 5960 5960 5960 5960 5960 50960 50960100960 pcib0: slot 10 INTA routed to irq 10 via \\_SB_.PCI0.LNKC found- vendor=0x8086, dev=0x1076, revid=0x00 bus=0, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 4, range 32, base ac00, size 8, enabled map[14]: type 1, range 32, base e8181000, size 8, enabled map[18]: type 1, range 32, base e8182000, size 12, enabled pcib0: matched entry for 0.11.INTA (src \\_SB_.PCI0.LNKD) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKA (references 12, priority 263050): interrupts: 5111012 7 6 4 315 14 1 penalty: 1490 1560 1560 6440 6440 6440 6440 6440 51440 51440101440 \\_SB_.PCI0.LNKD (references 12, priority 263050): interrupts: 5111012 7 6 4 315 14 1 penalty: 1490 1560 1560 6440 6440 6440 6440 6440 51440 51440101440 pcib0: slot 11 INTA routed to irq 11 via \\_SB_.PCI0.LNKD found- vendor=0x1000, dev=0x000f, revid=0x26 bus=0, slot=11, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x11 (4250 ns), maxlat=0x40 (16000 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 pci0:12:0: Transition from D2 to D0 map[10]: type 4, range 32, base b000, size 6, enabled pcib0: matched entry for 0.12.INTA (src \\_SB_.PCI0.LNKA) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKA (references 12, priority 268941): interrupts: 5101112 7 6 4 315 14 1 penalty: 1970 2040 2160 6920 6920 6920 6920 6920 51920 51920101920 pcib0: slot 12 INTA routed to irq 10 via \\_SB_.PCI0.LNKA found- vendor=0x1274, dev=0x1371, revid=0x08 bus=0, slot=12, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0105, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=10 powerspec 1 supports D0 D2 D3 current D0 map[20]: type 4, range 32, base b400, size 5,
if_sk no PHY found, next iteration
Thanks for the info on your http://sources.zabbadoz.net/freebsd/if_sk.html page. Here is a dmesg snippet of another sk problem (Asus A8V deluxe, 5.4-R amd64): skc0: Marvell Gigabit Ethernet port 0xa000-0xa0ff mem 0xfba0-0xfba03fff irq 17 at device 10.0 on pci0 skc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfba0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: bpf attached sk0: Ethernet address: 00:11:d8:a9:d5:6d skc0: no PHY found! device_attach: sk0 attach returned 6 skc0: [MPSAFE] Under TODO you have `unkown rev. 0x9 for Yukon Lite', seems this is it? Btw i also installed xp on the box and for that i had to fetch the latest driver off the marvell.com site too (yk51x86.sys), the one distributed by Asus didnt work. (nice, eh?) Linux's sk98lin driver (2.6.11 kernel) seems to have no problems tho. Any patches/info welcome... Juergen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speaking of 3.4...
In article [EMAIL PROTECTED] you write: -current (all the latest greatest experimental). -stable (all the latest gretest "Stable" stuff). -missioncritical (conservative release, once a year or so - only bug fixes after release). Actually, the -missioncritical branch is sort of provided for now as a function of -previousstable. There are plenty of people still running 2.2.x, for example, and you even still occasionally see commits to the 2.2.x branch. Hmm 2.2.x... Have all the Y2K fixes been merged back there? Wondering... -- Juergen Lock [EMAIL PROTECTED] (remove dot foo from address to reply) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: easyboot far into disk
On Sun, Nov 07, 1999 at 11:57:26AM -0800, Mike Smith wrote: Rootdev ought to work, actually. But if you get it wrong, the loader will fall back to using currdev. Hmm then thats strange. I first tried rootdev, which didn't work, and then later currdev, which did work, and i believe i used the same value both times! Or was rootdev fixed only recently, the boot floppies i had lying around and tested this on weren't the latest... I thought rootdev was fixed a long time back. If it's not, please tell me and I'll fix it again. 8) How long back? Guess i have to try a more recent version... (Maybe this should be added to the FAQ as a method of last resort when the BIOS boot code can't see above cyl 1024?) From what I've been hearing from people lately, in most cases it's 8GB that's the new sound barrier, Yea, probably true with later boards. (anyone know if there's a real technical reason for that, or just again short-sightedness of the BIOS writers? I mean first 32M if i remember right, then 512M, then 2G, now 8G... shouldn't everyone know by now that disks are getting bigger all the time?) It's a limitation of the c/h/s interface and the practical translations available. Over 8GB we finally have to use LBA mode; the problem there is that there's still too much legacy hardware out there that will break if we default to it. It breaks? It doesn't just return an error so you can fall back to the old interface? Or is the problem that there's just not enough space in boot0 for both versions? Regards, -- Juergen Lock [EMAIL PROTECTED] (remove dot foo from address to reply) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
