acpi_perf error
Hi all! I've seen this error some 300 times at the beginning of boot process. System goes up and works with no issue. It is nforce3 250 with amd64, 6.0 os. Using sysctl, I've found the line: dev.acpi_perf.0.%driver: acpi_perf In bios acpi apic is turned off, due to acpi errors from 5.4 era. Kernel includes cpufreq and powerd is in rc.conf. Is there any known command for sysctl to change "driver"? Or should I put apic back? Would be nice to have temperature reading on this mobo to compare cpufreq effect. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.0 Release - Pentium install panic and some questions
Hi, we are having a number of issues with 6.0-Release. Our setup: We have ~40 machines in a development test environment, ranging from P5/150Mhz/32M ram/IDE, PII Celerons, P3, P4, single and dual processor setups. Issue 1: Can't install on a Pentium P5 class machine: The install panics when installing the base stuff. No useful messages are displayed accept the "panic: page fault" and rebooting in 15 seconds. The machines are 10 year old DEC Pentiums, 32 to 64M ram, IDE disks, etc. We have four of these in our test environment and appear to install and run FreeBSD-5.4 fine. Issue 2: phys_avail[] array too small in i386/machdep.c P5 boxes ?? We have something which we call a Remote Network Appliance (RNA), which is basically a boot floppy with lots of stuff squeezed on it. The RNA uses a cut down kernel config (ie. no kernel source modifications), various other inhouse programs (eg. init/inetd/telnetd replacements), built into a 1Mbyte MD root. We have no problems using everything up until a 5.4-stable kernel but have various problems with 6.0-release. When using 6.0, we get the following messages: Overlapping or non-montonic memory region, ignoring second region ... Too many holes in the physical address space, giving up ... Fatel trap 12: page fault while in kernel mode ... panic Did a bit of searching and found that in Dragonfly phys_avail[] in i386/machdep.c has been bumped up because it is too small. Looking at 6.0 machdep.c, looks like new dcons stuff has been added to it, and it blocks out some physical memory to use. Not sure if that has anything to do with it. From my understanding, phys_avail[10] gives you room for four physical available address ranges (ie. 4 * start/end pair entries and null terminated). I bumped the number up to 12 (ie. gives me five address ranges) and we are off and going. 6.0 now boots on all our Pentium machines, but... on 5.4-stable we got: physical memory: 67108864 avail memory:56156160 on 6.0 with phys_avail[12] we got: physical memory: 67108864 avail memory:63299584 more available memory for some reason ! Hmmm. On most of our machines, when booting in verbose mode, the 5.4 kernel reports three phys_avail segments, but the Pentium boxes report four. On the patched 6.0, the Pentiums report five segments. Unfortunately, the machine panics on Pentium machines when stress testing it (ie. by making it run out of memory). On 5.4-stable it would just kill user processes, under 6.0 it kills a few processes but quickly panics with a page not present error. At least 6.0 now boots and runs on a Pentium, whereas the standard install panics. I can't get a dump of the RNA floppy panic because it has no swap or disk to write to, and there isn't enough room on the floppy to build a kernel with debugging stuff. So, my question is... is it OK to bump phys_avail from 10 to 12 ?? or do we just ditch the Pentium as a supported platform ? Dragonfly have bumped it to 22, giving 10 segments. The only other change we do is compile the kernel and world with -Os and -funit-at-a-time to reduce the resulting binary sizes. fyi, A copy of the floppy image is at: http://www.statseeker.com/downloads/lanstat_fbsd60.bin It also contains our realtime Statistical LAN Analyser. Instructions are at http://www.statseeker.com/download1.html The following is the RNA kernel config: hints "./device.hints" machine i386 cpu I586_CPU cpu I686_CPU ident RNA_KERNEL options SCHED_ULE options INET options FFS options MD_ROOT options MD_ROOT_SIZE=1024 options COMPAT_FREEBSD4 options HZ=1000 options CLK_USE_I8254_CALIBRATION options VM_KMEM_SIZE_SCALE options NO_SWAPPING options INIT_PATH="/rna-init" device apm device pci device vga device fdc device md device mem nodeviceio device atkbdc device atkbd device pty device sc options MAXCONS=2 options SC_HISTORY_SIZE=500 options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)" options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)" options SC_KERNEL_CONS_ATTR="(FG_YELLOW|BG_BLACK)" options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)" options SC_NO_CUTPASTE options SC_NO_FONT_LOADING options SC_NO_SYSMOUSE options DEVICE_POLLING device de device em device ixgb device txp device miibus device bfe device bge device dc device fxp device lge device nge device pcn device re device sf device sis device sk device ste device ti device tl device tx device vge device vr device wb device xl device loo
Re: CF card and /dev filesystem entries
On Sun, 20 Nov 2005 21:04:59 + Brian Candler <[EMAIL PROTECTED]> wrote: > On Wed, Nov 16, 2005 at 05:57:12PM +0100, Roland Smith wrote: > > > However, when I insert a CF card with normal partioning I > > > need /dev/da0s1, and this is not present in the /dev filesystem > > > because the partition table has not been read. > > > > > The only way I can see to *force* the superblock to be read is to > > > attempt to mount the whole device as if it were unpartitioned. > > > This is sufficient to cause the /dev/da0s1 entry to appear in > > > the /dev filesystem. > > > > > At this point, everything works as expected. > > > > > > My question is: is there an easier or more direct way to cause > > > the partition table of the CF card to be read and the /dev > > > filesystem to update? > > > > Try 'camcontrol rescan all' (as root). > > No joy. > > [EMAIL PROTECTED] brian# ls /dev/da0* > /dev/da0 > [EMAIL PROTECTED] brian# camcontrol rescan all > Re-scan of bus 0 was successful > Re-scan of bus 1 was successful > Re-scan of bus 2 was successful > Re-scan of bus 3 was successful > [EMAIL PROTECTED] brian# ls /dev/da0* > /dev/da0 > > Another suggestion was: > > > I think devfs is updated when a descriptor on the device > > which was opended for writing is closed. But you don't > > actually have to write anything. That means, the following > > command should do it: > > > > # dd if=/dev/null of=/dev/da0 count=0 > > Now, that does the job: > > [EMAIL PROTECTED] brian# dd if=/dev/null of=/dev/da0 count=0 > 0+0 records in > 0+0 records out > 0 bytes transferred in 0.28 secs (0 bytes/sec) > [EMAIL PROTECTED] brian# ls -l /dev/da0* > crw-r- 1 root operator0, 107 Nov 20 21:00 /dev/da0 > crw-r- 1 root operator0, 115 Nov 20 21:00 /dev/da0s1 > [EMAIL PROTECTED] brian# > > However, I'm not sure I actually *like* opening my CF card in such a > way that I would be likely to overwrite the partition table if I hit > a wrong key... > > Regards, > > Brian. > I am not sure if this is any different but when placing or changing a card in my card reader I run " cat /dev/null > /dev/daX" before mounting. I have cards of different sizes and it would fail to mount a different size card without doing the above first. Good Luck Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ad1: req=0xc2998000 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !!
Hi. I have an error after upgrade to FreeBSD 6.0-RELEASE in time of booting: ad1: req=0xc2998000 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! swap_pager: indefinite bufobj: 0 blkno: 3 size: 4096 then it's just halt. But not everytime, sometime it's booting without any problems and i don't know why.. Here is additional information: == # uname -a FreeBSD spirit 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Fri Nov 11 17:00:05 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/s rc/sys/SPIRIT i386 # atacontrol list ATA channel 0: Master: no device present Slave: ad1 http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.13 2005/04/02 16:37:58 scottl Exp $ machine i386 #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident SPIRIT # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=15000# Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic# I/O APIC options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN #=== POLLING support == options HZ=2000 options DEVICE_POLLING #=== PF support === device pf #PF OpenBSD packet-filter firewall device pflog #logging support interface for PF # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device ahd # AHA39
Re: CF card and /dev filesystem entries
On Wed, Nov 16, 2005 at 05:57:12PM +0100, Roland Smith wrote: > > However, when I insert a CF card with normal partioning I need /dev/da0s1, > > and this is not present in the /dev filesystem because the partition table > > has not been read. > > > The only way I can see to *force* the superblock to be read is to attempt to > > mount the whole device as if it were unpartitioned. This is sufficient to > > cause the /dev/da0s1 entry to appear in the /dev filesystem. > > > At this point, everything works as expected. > > > > My question is: is there an easier or more direct way to cause the partition > > table of the CF card to be read and the /dev filesystem to update? > > Try 'camcontrol rescan all' (as root). No joy. [EMAIL PROTECTED] brian# ls /dev/da0* /dev/da0 [EMAIL PROTECTED] brian# camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful [EMAIL PROTECTED] brian# ls /dev/da0* /dev/da0 Another suggestion was: > I think devfs is updated when a descriptor on the device > which was opended for writing is closed. But you don't > actually have to write anything. That means, the following > command should do it: > > # dd if=/dev/null of=/dev/da0 count=0 Now, that does the job: [EMAIL PROTECTED] brian# dd if=/dev/null of=/dev/da0 count=0 0+0 records in 0+0 records out 0 bytes transferred in 0.28 secs (0 bytes/sec) [EMAIL PROTECTED] brian# ls -l /dev/da0* crw-r- 1 root operator0, 107 Nov 20 21:00 /dev/da0 crw-r- 1 root operator0, 115 Nov 20 21:00 /dev/da0s1 [EMAIL PROTECTED] brian# However, I'm not sure I actually *like* opening my CF card in such a way that I would be likely to overwrite the partition table if I hit a wrong key... Regards, Brian. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Centralized building
On Sun, Nov 20, 2005 at 10:14:37AM +0100, Eirik ?verby wrote: > > On Nov 20, 2005, at 09:50 , Eirik ?verby wrote: > > > > >On Nov 19, 2005, at 19:43 , Joseph Koshy wrote: > > > >>>AFAICT cross-compiling amd64 on a i386 machine isn't supported > >>>yet. I ran into a similar problem when I upgraded an i386 > >>>machine to amd64. I thought I could just set CPUTYPE=athlon-64 > >>>and buildworld would do the right thing. Apparently not. > >> > >>Bootstrapping a single machine is supported: > >> > >># make buildworld TARGET_ARCH=new-arch > >> > >>plus a few other steps. (See build(7)). > >> > >>There have been a couple of postings on the mailing lists > >>on this topic in the recent past. I've taken a stab at > >>describing how to cross-bootstrap too: > >> > >>http://edoofus.blogspot.com/2005/10/cross-building-freebsd.html > >> > >>The OP wanted to do a 'buildworld TARGET_ARCH=foo' on one > >>machine and then an 'installworld' on a different set of > >>machines. > > > >Yes, and he still wonders if this is supposed to be doable or not. > >I think the culprit is (partly) the fact that every architecture is > >built into its own subdirectory in /usr/obj, EXCEPT the > >architecture the build is running on. The same goes for the install > >part, and if the build and install architectures differ, it cannot > >ever work. Setting MAKEOBJDIRPREFIX on the target host makes the > >install start, but it fails after a couple of minutes with the "dd: > >not found" error. > >(I do notice that there is a /usr/obj/usr directory created also > >when cross-building; I'm assuming this contains the build bootstrap > >tools). > > Follow-up. If I enter src/sys and do a "make install", the dd step > works perfectly - however it stops later when trying to install > cdboot. I am assuming this is due to missing options or wrong target > for make, but - from all I can tell - shows a weakness in the build/ > install system. Or maybe not... > > Anyone?? > We don't support build host != install host, in a strict sense. But as Joseph pointed out, we do support NFS installs to different architectures. The build host != install host is supported only if a number of conditions are met, most noticeable are that they should be running the same OS version and the same (or compatible) CPU, and of course the same set of options (/etc/make.conf, etc.) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp1ZvisVBXjL.pgp Description: PGP signature
Re: cmbat related ACPI change between 6.0-release and Nov 10th -stable sources is making Dell laptops to hang
On 11/20/05, Pierre-Luc Drouin <[EMAIL PROTECTED]> wrote: > Hi, > > Since I upgraded from 6.0-release to 6.0-stable on Nov 10th, my laptop > hangs for about 1-2 seconds everytime a battery monitoring tool asks for > the cmbat battery status. My laptop is a Dell Precision M70 and shares > its motherboard with many other Dell laptops. I can reproduce the > problem by running "acpiconf -i loop" or "sysctl hw.acpi.battery.life". > The problem did not exist with 6.0-release, so it has been caused by > some code change between -release and Nov 10th sources. Disabling cmbat > with debug.acpi.disabled avoids the laptop to hang. Does someone know > what change to cmbat related stuff could be causing this problem? I've seen these too, I was running klaptopd. > > Thank you! > > Pierre-Luc Drouin > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cmbat related ACPI change between 6.0-release and Nov 10th -stable sources is making Dell laptops to hang
Hi, Since I upgraded from 6.0-release to 6.0-stable on Nov 10th, my laptop hangs for about 1-2 seconds everytime a battery monitoring tool asks for the cmbat battery status. My laptop is a Dell Precision M70 and shares its motherboard with many other Dell laptops. I can reproduce the problem by running "acpiconf -i loop" or "sysctl hw.acpi.battery.life". The problem did not exist with 6.0-release, so it has been caused by some code change between -release and Nov 10th sources. Disabling cmbat with debug.acpi.disabled avoids the laptop to hang. Does someone know what change to cmbat related stuff could be causing this problem? Thank you! Pierre-Luc Drouin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
is removable_interfaces still used?
Hello, I'm running 6.0-STABLE and see that the option removable_interfaces is not used in any config script. /etc# grep -r removable_interfaces * defaults/rc.conf:removable_interfaces=""# Removable network interfaces for /etc/pccard_ether. What is is the use of it now? I can't find any use of pccard_ifconfig also. But there is no reference of the removal of these settings in UPDATING. Where can I find the latest docs for the best way to config a pccard network card? Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD-6 usb/scanner-access-rights
On Sun, Nov 20, 2005 at 07:26:38PM +0100, Holger Kipp wrote: > > Doesn't matter that you get "UNKNOWN". It _will_ work with sane without > > access to /dev/usb*. It does here. > > This is an Epson Perfection 1260. Don't ask what the 'Perfection' stands > for. Anyway, this is in fact a Plustek, so I have to add the following > to /usr/local/etc/sane.d/plustek.conf: > -[usb] > +[usb] 0x04B8 0x011D > +device /dev/uscanner0 My Epson Perfection 1650 only needs the last line in epson.conf to work with the xsane gimp plug-in. No vendor or device IDs necessary. I don't use scanimage. Try copying plustek.conf to epson.conf, and adding "epson" to dll.conf. The permissions on the uscanner device are 660 for root:usb. The /dev/usb devices are 660 for root:operator. My user-id is not in the operator group. Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpv61ZBfa5PW.pgp Description: PGP signature
Re: inconsistent arp(8) mac address output using if_bridge
On Sun, Nov 20, 2005 at 07:50:44PM +0200, Niki Denev wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > I have a small machine setup to act as simple network gateway. > I have one wireless and one wired interfaces without IP configuration > on them, and they are added as if_bridge(4) members. > When i issue arp -na command on the machine i get this: > > ? (10.10.10.240) at 0.14.a5.1a.dc.73 on bridge0 > ? (10.10.10.241) at 4.4b.80.80.80.3 on bridge0 > ? (10.10.10.246) at 0.a0.cc.62.99.c3 on bridge0 This has been fixed up already, you can update your source and recompile usr.sbin/arp HEAD: r1.59 RELENG_6: r1.58.2.1 cheers, Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD-6 usb/scanner-access-rights
On Sun, Nov 20, 2005 at 06:47:54PM +0100, Roland Smith wrote: > On Sun, Nov 20, 2005 at 05:37:36PM +0100, Holger Kipp wrote: > > Dear Roland, > > > > Is there an easy way to name the devices a user might > > > > be allowed to access rw, without compromising the system? > > > > I don't want to give operator group to these users, > > > > and I don't want to blindly allow access to some > > > > da- or pass-devices where I cannot determine the order > > > > of numbering easily. > > ah, I had the entry > > "add path 'uscanner*' mode 0660 group usb" > > missing in the devfs.rules-file > > but this still does not help... > > > > uscanner0 is here: > > uscanner0: EPSON EPSON Scanner, rev 1.10/1.00, addr 2 > > > > sane-find-scanner has the following to say: > > found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 > > Doesn't matter that you get "UNKNOWN". It _will_ work with sane without > access to /dev/usb*. It does here. This is an Epson Perfection 1260. Don't ask what the 'Perfection' stands for. Anyway, this is in fact a Plustek, so I have to add the following to /usr/local/etc/sane.d/plustek.conf: -[usb] +[usb] 0x04B8 0x011D +device /dev/uscanner0 I need vendor and product id to get this working. Without getting this info, eg scanimage -L will complain that it couldn't find a scanner, etc. only with /dev/usb* set to root:usb, I will get %scanimage -L device `plustek:/dev/uscanner0' is a Epson Perfection 1260/Photo USB flatbed scanner Regards, Holger Kipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD unstable on Dell 1750 using SMP?
Strange indeed. On a 1750 with bge's: 475 mbufs in use 501/25600 mbuf clusters in use (current/max) 0/3/6656 sfbufs in use (current/peak/max) 1120 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 100 calls to protocol drain routines On a 2850 (hardware identical to an 1850): $ netstat -m 4294966848 mbufs in use 565/25600 mbuf clusters in use (current/max) 0/67/6656 sfbufs in use (current/peak/max) 1018 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 16449 requests for I/O initiated by sendfile 589 calls to protocol drain routines Both experience the "auto reboot" feature. The mbufs on the 2850 look like a counter (signed/unsigned) bug, maybe even just in the printing. Other than that I'm having a hard time interpreting these results. Regards Rutger Bevaart On Nov 20, 2005, at 5:07 PM, Gino Ruopolo wrote: Hello Rutger, I red your post but I'm unable to reply on the list 'cause of some firewall settings. I'm having the same problems with various Dell1850 and Fbsd 5.4 Last week I noticed the following: #netstat -m 4294899289 mbufs in use!?!?!??!!? 4294940375/25600 mbuf clusters in use (current/max) !?!?!?!??! 0/9/6656 sfbufs in use (current/peak/max) 4123460 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 34 requests for I/O initiated by sendfile 2533 calls to protocol drain routines Here is the output of the same command on a different server with fxp0 ethernet driver, also FBSD 5.4 and doing the same work: #netstat -m 194 mbufs in use 171/25600 mbuf clusters in use (current/max) 0/4/6656 sfbufs in use (current/peak/max) 390 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines So I've tried putting an old pci ethernet 10/100 using fxp driver on a Dell1850 suffering the "self-reboot" problem. I'm getting 5 days of uptime without a single reboot ... What about a problem with the em driver? Regards, gino _ Parla con i tuoi amici che hanno MSN Hotmail in tempo reale! E' gratis. http://www.imagine-msn.com/messenger/default.aspx?locale=it-IT ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: inconsistent arp(8) mac address output using if_bridge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Niki Denev wrote: > Hello, > > I have a small machine setup to act as simple network gateway. > I have one wireless and one wired interfaces without IP configuration > on them, and they are added as if_bridge(4) members. > When i issue arp -na command on the machine i get this: > > ? (10.10.10.240) at 0.14.a5.1a.dc.73 on bridge0 > ? (10.10.10.241) at 4.4b.80.80.80.3 on bridge0 > ? (10.10.10.246) at 0.a0.cc.62.99.c3 on bridge0 > ? (10.10.10.253) at 0.5.4e.4f.7b.eb on bridge0 > ? (172.16.1.1) at 00:30:48:83:93:e9 on ep0 [ethernet] > ? (172.16.37.9) at 00:0f:b0:01:30:c0 on ep0 [ethernet] > > While the mac addresses appear to be correct, maybe > this should be fixed to be consistent with the default > mac address output? > > --niki Sorry, forgot the mention the os version : FreeBSD gimli 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 - --niki -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDgLlYHNAJ/fLbfrkRAnM8AJ0WbFS29X9F3FTah1S3Rnb/P7BZOgCeNeTr at9AxPhl6kvnVV7XBFY3lns= =Tgdb -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
inconsistent arp(8) mac address output using if_bridge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have a small machine setup to act as simple network gateway. I have one wireless and one wired interfaces without IP configuration on them, and they are added as if_bridge(4) members. When i issue arp -na command on the machine i get this: ? (10.10.10.240) at 0.14.a5.1a.dc.73 on bridge0 ? (10.10.10.241) at 4.4b.80.80.80.3 on bridge0 ? (10.10.10.246) at 0.a0.cc.62.99.c3 on bridge0 ? (10.10.10.253) at 0.5.4e.4f.7b.eb on bridge0 ? (172.16.1.1) at 00:30:48:83:93:e9 on ep0 [ethernet] ? (172.16.37.9) at 00:0f:b0:01:30:c0 on ep0 [ethernet] While the mac addresses appear to be correct, maybe this should be fixed to be consistent with the default mac address output? - --niki -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDgLd0HNAJ/fLbfrkRAt37AKDJ5P9PC1tf6VCyBDv83KwjNTqirwCgvhoW noztCOr2cpcaEqEjiBLAclc= =7DFZ -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD-6 usb/scanner-access-rights
On Sun, Nov 20, 2005 at 05:37:36PM +0100, Holger Kipp wrote: > Dear Roland, > > thank you very much for your answer. > > On Sun, Nov 20, 2005 at 03:04:22PM +0100, Roland Smith wrote: > > On Sun, Nov 20, 2005 at 02:16:24PM +0100, Holger Kipp wrote: > > > > > > Is there an easy way to name the devices a user might > > > be allowed to access rw, without compromising the system? > > > I don't want to give operator group to these users, > > > and I don't want to blindly allow access to some > > > da- or pass-devices where I cannot determine the order > > > of numbering easily. > > > > One thing you could do is make the groups usb and cdrom and make them > > the groups owning the relevant devices, e.g. by putting the following in > > /etc/devfs.rules: > > > > add path 'da*s*' mode 0660 group usb > > add path 'uscanner*' mode 0660 group usb > > ah, I had the entry > "add path 'uscanner*' mode 0660 group usb" > missing in the devfs.rules-file > but this still does not help... > > uscanner0 is here: > > uscanner0: EPSON EPSON Scanner, rev 1.10/1.00, addr 2 > > > sane-find-scanner has the following to say: > found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 Doesn't matter that you get "UNKNOWN". It _will_ work with sane without access to /dev/usb*. It does here. > Yes, but there is a problem with numbering of pass-devices: > > with card-reader attached during boot, I have: > at scbus0 target 0 lun 0 (da0,pass0) > at scbus0 target 0 lun 1 (da1,pass1) > at scbus0 target 0 lun 2 (da2,pass2) > at scbus0 target 0 lun 3 (da3,pass3) >at scbus2 target 0 lun 0 (pass4,cd0) >at scbus2 target 1 lun 0 (pass5,cd1) > > attaching card-reader afterwards gives different numbering: > after boot: > katrin# camcontrol devlist >at scbus1 target 0 lun 0 (cd1,pass1) >at scbus1 target 1 lun 0 (cd0,pass0) > after attaching cardreader: > katrin# camcontrol devlist >at scbus1 target 0 lun 0 (cd1,pass1) >at scbus1 target 1 lun 0 (cd0,pass0) > at scbus4 target 0 lun 0 (da0,pass2) > at scbus4 target 0 lun 1 (da1,pass3) > at scbus4 target 0 lun 2 (da2,pass4) > at scbus4 target 0 lun 3 (da3,pass5) > > so allowing access to cd0/cd1 and corresponding pass0 and pass1 will > break if computer is booted with usb-cardreader attached. not good. It was an example. I don't have many usb devices, so it works for me. :-) > > If that is not fine-grained enough, maybe ACLs might help. See setfacl(1). > > so we currently have: > > - rights needed not only for the device itself, but also for the bus > and or control devices (pass, usb, xpt0) Yes, but ACL give fine-grained access control. And no matter how you look at it, you _have_ to trust the person whom you give access to the pass devices. It's in the FreeBSD architecture. > - dynamic numbering (pass). > > I agree that usb is a nightmare and should never have happened. :-) For disc devices, you could use GEOM_LABEL. That'll give you consistent /dev/label/ names. Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpr0N6RwiSpt.pgp Description: PGP signature
Re: FBSD-6 usb/scanner-access-rights
Dear Roland, thank you very much for your answer. On Sun, Nov 20, 2005 at 03:04:22PM +0100, Roland Smith wrote: > On Sun, Nov 20, 2005 at 02:16:24PM +0100, Holger Kipp wrote: > > > > Is there an easy way to name the devices a user might > > be allowed to access rw, without compromising the system? > > I don't want to give operator group to these users, > > and I don't want to blindly allow access to some > > da- or pass-devices where I cannot determine the order > > of numbering easily. > > One thing you could do is make the groups usb and cdrom and make them > the groups owning the relevant devices, e.g. by putting the following in > /etc/devfs.rules: > > add path 'da*s*' mode 0660 group usb > add path 'uscanner*' mode 0660 group usb ah, I had the entry "add path 'uscanner*' mode 0660 group usb" missing in the devfs.rules-file but this still does not help... uscanner0 is here: uscanner0: EPSON EPSON Scanner, rev 1.10/1.00, addr 2 sane-find-scanner has the following to say: found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 only if I also issue # chown root:usb /dev/usb0 # chown root:usb /dev/usb1 # chown root:usb /dev/usb2 it will return found USB scanner (vendor=0x04b8, product=0x011d) at /dev/uscanner0 this is not good either, because attaching the scanner to a different device means I have to change this for all /dev/usb*, effectively allowing read/write to all usb devices. I wonder why I have to allow access to all devices from 0 to 2. Attaching to a different hub(*): uscanner0: at uhub2 port 2 (addr 2) disconnected uscanner0: detached uscanner0: EPSON EPSON Scanner, rev 1.10/1.00, addr 2 -> I also have to chgrp usb /dev/usb3 so all /dev/usb up to the corresponding /dev/usb where the scanner is attached are needed. Strange! (*) detaching gives: uscanner0: at uhub3 port 1 (addr 2) disconnected uscanner0: detached > The ownership for the CD-ROM devices should be set in /etc/devfs.conf: > > # Give members of group cdrom access to the CD/DVD-ROM and DVD+RW via the > # SCSI interface > own xpt0root:cdrom > permxpt00660 > > own cd0 root:cdrom > permcd0 0660 > linkcd0 cdrom > linkcd0 dvd > > own pass0 root:cdrom > permpass0 0660 > > own cd1 root:cdrom > permcd1 0660 > > own pass1 root:cdrom > permpass1 0660 > > The user that must be able to use the CD-ROMs and scanner must be a > member of the appropriate group. > Yes, but there is a problem with numbering of pass-devices: with card-reader attached during boot, I have: at scbus0 target 0 lun 0 (da0,pass0) at scbus0 target 0 lun 1 (da1,pass1) at scbus0 target 0 lun 2 (da2,pass2) at scbus0 target 0 lun 3 (da3,pass3) at scbus2 target 0 lun 0 (pass4,cd0) at scbus2 target 1 lun 0 (pass5,cd1) attaching card-reader afterwards gives different numbering: after boot: katrin# camcontrol devlist at scbus1 target 0 lun 0 (cd1,pass1) at scbus1 target 1 lun 0 (cd0,pass0) after attaching cardreader: katrin# camcontrol devlist at scbus1 target 0 lun 0 (cd1,pass1) at scbus1 target 1 lun 0 (cd0,pass0) at scbus4 target 0 lun 0 (da0,pass2) at scbus4 target 0 lun 1 (da1,pass3) at scbus4 target 0 lun 2 (da2,pass4) at scbus4 target 0 lun 3 (da3,pass5) so allowing access to cd0/cd1 and corresponding pass0 and pass1 will break if computer is booted with usb-cardreader attached. not good. And: allowing specific users access to xpt might also not be a very good idea according to the man-page: Since the xpt driver allows direct access to the CAM subsystem, system administrators should exercise caution when granting access to this driver. If used improperly, this driver can allow userland applications to crash a machine or cause data loss. > If that is not fine-grained enough, maybe ACLs might help. See setfacl(1). so we currently have: - rights needed not only for the device itself, but also for the bus and or control devices (pass, usb, xpt0) - dynamic numbering (pass). I agree that usb is a nightmare and should never have happened. Regards, Holger Kipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD-6 usb/scanner-access-rights
On Sun, Nov 20, 2005 at 02:16:24PM +0100, Holger Kipp wrote: > > Is there an easy way to name the devices a user might > be allowed to access rw, without compromising the system? > I don't want to give operator group to these users, > and I don't want to blindly allow access to some > da- or pass-devices where I cannot determine the order > of numbering easily. One thing you could do is make the groups usb and cdrom and make them the groups owning the relevant devices, e.g. by putting the following in /etc/devfs.rules: add path 'da*s*' mode 0660 group usb add path 'uscanner*' mode 0660 group usb The ownership for the CD-ROM devices should be set in /etc/devfs.conf: # Give members of group cdrom access to the CD/DVD-ROM and DVD+RW via the # SCSI interface own xpt0root:cdrom permxpt00660 own cd0 root:cdrom permcd0 0660 linkcd0 cdrom linkcd0 dvd own pass0 root:cdrom permpass0 0660 own cd1 root:cdrom permcd1 0660 own pass1 root:cdrom permpass1 0660 The user that must be able to use the CD-ROMs and scanner must be a member of the appropriate group. If that is not fine-grained enough, maybe ACLs might help. See setfacl(1). Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpx5NlZ2BPe3.pgp Description: PGP signature
Re : Re: building gnome2 on freebsd6-stable
thanks for replying.
No, I actually did not have gnome installed, as I'm running fluxbox but may be
I had some sub-gnome ports installed that I didn't notice and that are
responsible for the build failure.
May be I should uninstall all *gnome* ports and restart.
Best regards,
Didier
- Message d'origine -
De: Paul Root <[EMAIL PROTECTED]>
Date: Samedi, Novembre 19, 2005 11:26 pm
Objet: Re: building gnome2 on freebsd6-stable
> Did you have gnome in before and you started to
> try to build it?
>
> Go to http://www.freebsd.org/gnome. There is an
> upgrade script there. I used it partially, it got
> me about half way. Turned out that I had an ethernet
> speed/duplex issue much of the time, and was having
> trouble downloading.
>
> After a day of manually downloading (ftp worked, fetch,
> which is used by the script had trouble) and restarting the
> script, I gave up on it and used portmanager. That worked
> better, but still had a couple of issues.
>
> About this time, I got the duplex issue fixed on the switch,
> and then went back to /usr/ports/x11/gnome2 and from there
> everything worked.
>
> The problem is that you'll get out of order with dependancies
> if you just start in /usr/ports/x11/gnome2.
>
>
> I'm having one problem with gnome 2.12. The screensaver won't
> start up. It complains about not being able to contact the
> messagebus. Any help here?
>
>
>
> Didier Wiroth wrote:
> > ***
> > This message has been scanned by the InterScan for CSC-SSM and
> found to be free of known security risks.
> > ***
> >
> >
> > hi,
> >
> > I tried to build gnome2 on freebsd6 stable.
> >
> > It fails when it tries to compile gnomeapllets2, here is the output:
> > --START SNIP-
> > 12.1/drivemount/help'
> > if ! test -d es/; then mkdir es/; fi
> > if test -f "C/drivemount.xml"; then d="../"; else d=".././"; fi; \
> > (cd es/ && \
> > `which xml2po` -e -p \
> > ${d}es/es.po \
> > ${d}C/drivemount.xml > drivemount.xml.tmp && \
> > cp drivemount.xml.tmp drivemount.xml && rm -f
> drivemount.xml.tmp)> Traceback (most recent call last):
> > File "/usr/X11R6/bin/xml2po", line 34, in ?
> > import libxml2
> > File "/usr/local/lib/python2.4/site-packages/libxml2.py", line
> 1, in ?
> > import libxml2mod
> > ImportError: /usr/local/lib/python2.4/site-
> packages/libxml2mod.so: Undefined symbol "xmlParseURIRaw"
> > gmake[3]: *** [es/drivemount.xml] Error 1
> > gmake[3]: Leaving directory
> `/usr/ports/x11/gnomeapplets2/work/gnome-applets-
> 2.12.1/drivemount/help'> gmake[2]: *** [all-recursive] Error 1
> > gmake[2]: Leaving directory
> `/usr/ports/x11/gnomeapplets2/work/gnome-applets-2.12.1/drivemount'
> > gmake[1]: *** [all-recursive] Error 1
> > gmake[1]: Leaving directory
> `/usr/ports/x11/gnomeapplets2/work/gnome-applets-2.12.1'
> > gmake: *** [all] Error 2
> > *** Error code 2
> >
> > Stop in /usr/ports/x11/gnomeapplets2.
> > *** Error code 1
> >
> > Stop in /usr/ports/x11/gnome2.
> > -STOP SNIP--
> >
> > What can I do to solve the problem?
> >
> > thanks a lot
> > didier
> >
> > ___
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-
> [EMAIL PROTECTED]"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FBSD-6 usb/scanner-access-rights
Hello, I am slightly unsatisfied with user rights management, especially with usb-devices, but also with access to cd/dvd-burners for the following reason: I'd like to be able to allow access to burners that are accessed as scsi-devices (via atapicam) for some users, but for that to work it is not sufficient to allow access via cd0/cd1, but I also have to allow the corresponding pass-devices. For usb-scanner it is even worse. If I allow access to uscanner0, this does not work unless I also allow the corresponding /dev/usb-device. umass is also accessed as da-device and also therefore needs some da-devices to be allowed rw-access for 'ordinary' users. I don't relly like to allow direct access to the related devices (da, pass - especially if the system is using scsi-disks). Is there an easy way to name the devices a user might be allowed to access rw, without compromising the system? I don't want to give operator group to these users, and I don't want to blindly allow access to some da- or pass-devices where I cannot determine the order of numbering easily. I hope this does not sound ignorant. Pointers to helpful information are also welcome :-) Regards, Holger Kipp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "message too long" when sending broadcasts
On Sun, 20 Nov 2005, Michael Voucko wrote:
Berkeley-derived kernels do not allow a broadcast datagram to be
fragmented. If the size of an IP datagram that is being sent to a
broadcast address exceeds the outgoing interface MTU, EMSGSIZE is
returned (pp. 233?234 of TCPv2). This is a policy decision that has
existed since 4.2BSD. There is nothing that prevents a kernel from
fragmenting a broadcast datagram, but the feeling is that broadcasting
puts enough load on the network as it is, so there is no need to
multiply this load by the number of fragments. AIX, FreeBSD, and
MacOS implement this limitation. Linux, Solaris, and HP-UX fragment
datagrams sent to a broadcast address.
Maybe it's worth adding this information somewhere to make it easier to
find?
It would also be quite easy to make this configurable -- the code in
ip_output is fairly straight forward:
/*
* Look for broadcast address and
* verify user is allowed to send
* such a packet.
*/
if (isbroadcast) {
if ((ifp->if_flags & IFF_BROADCAST) == 0) {
error = EADDRNOTAVAIL;
goto bad;
}
if ((flags & IP_ALLOWBROADCAST) == 0) {
error = EACCES;
goto bad;
}
/* don't allow broadcast messages to be fragmented */
if (ip->ip_len > ifp->if_mtu) {
error = EMSGSIZE;
goto bad;
}
if (flags & IP_SENDONES)
ip->ip_dst.s_addr = INADDR_BROADCAST;
m->m_flags |= M_BCAST;
} else {
m->m_flags &= ~M_BCAST;
}
We could add a global option, or maybe just an IP socket option.
Robert N M Watson
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FBSD 6-STABLE usb problem: umass0: BBB reset failed, IOERROR
Hello, whilst copying files from SD-Card via usb card reader with mcopy, I encountered the following error with FreeBSD 6.0-STABLE from 15.11.2005. Even though the device was reattached automatically (nice improvement, btw!), this error is very annoying. Is this behaviour already known, or should I file a pr? Apart from the reattachement, I had a similar behaviour under 5.4-STABLE. Regards, Holger Kipp %mcopy -mpv h:photos/51\* ./ Copying H:/photos/51011001.jpg Copying H:/photos/51011002.jpg .. Copying H:/photos/51109003.jpg Copying H:/photos/51109005.jpg Copying H:/photos/51109007.jpg plain_io: Input/output error file read: Input/output error Copying H:/photos/5008.jpg plain_io: Device not configured file read: Device not configured Copying H:/photos/51112001.jpg plain_io: Device not configured file read: Device not configured with /var/log/messages saying: Nov 20 13:14:54 katrin kernel: umass0: BBB reset failed, IOERROR Nov 20 13:14:54 katrin kernel: umass0: BBB bulk-in clear stall failed, IOERROR Nov 20 13:14:54 katrin kernel: umass0: at uhub4 port 8 (addr 3) disconnected Nov 20 13:14:54 katrin kernel: (da0:umass-sim0:0:0:0): lost device Nov 20 13:14:54 katrin kernel: (da0:umass-sim0:0:0:0): removing device entry Nov 20 13:14:54 katrin kernel: (da1:umass-sim0:0:0:1): lost device Nov 20 13:14:54 katrin kernel: (da1:umass-sim0:0:0:1): removing device entry Nov 20 13:14:54 katrin kernel: (da2:umass-sim0:0:0:2): lost device Nov 20 13:14:54 katrin kernel: (da2:umass-sim0:0:0:2): removing device entry Nov 20 13:14:54 katrin kernel: (da3:umass-sim0:0:0:3): lost device Nov 20 13:14:54 katrin kernel: umass0: detached Nov 20 13:14:54 katrin kernel: (da3:umass-sim0:0:0:3): Synchronize cache failed, status == 0x39, scsi status == 0x0 Nov 20 13:14:54 katrin kernel: (da3:umass-sim0:0:0:3): removing device entry Nov 20 13:14:56 katrin kernel: umass0: SMSC 223 USB97C223, rev 2.00/1.95, addr 3 ...(omitted parts for 0:0:0-0:0:2) Nov 20 13:14:56 katrin kernel: da3 at umass-sim0 bus 0 target 0 lun 3 Nov 20 13:14:56 katrin kernel: da3: Removable Direct Access SCSI-0 device Nov 20 13:14:56 katrin kernel: da3: 40.000MB/s transfers Nov 20 13:14:56 katrin kernel: da3: 483MB (990976 512 byte sectors: 64H 32S/T 483C) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Mount related panic with FreeBSD 6?
Hi, I got this panic on freshly installed FreeBSD 6. I did this df -h and noticed that /mnt/oldroot/home is somewhat mangled. The /mnt/oldroot is root of FreeBSD 4.11 system. I successfully copied some settings and all user accounts from that /mnt/oldroot/home earlier today. This is what I did before the panic: logout::wilx:~> df -h FilesystemSize Used Avail Use% Mounted on /dev/ad0s1a 496M 57M 399M 13% / devfs 1.0k 1.0k 0 100% /dev /dev/ad0s1e 989M 12k 910M 1% /tmp /dev/ad0s1f 163G 29G 120G 20% /usr /dev/ad0s1d 4.8G 2.0G 2.4G 45% /var /dev/ad2s1a 492M 317M 136M 70% /mnt/oldroot df: `/mnt/oldroot/hom': No such file or directory /dev/ad2s1f 6.7G 5.3G 1013M 85% /mnt/oldroot/usr /dev/ad2s1e 2.9G 2.2G 476M 83% /mnt/oldroot/var logout::root:~> mount /mnt/oldroot/home Notice that /mnt/oldroot/home is mounted twice here: logout::root:~> mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1e on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /usr (ufs, local, soft-updates) /dev/ad0s1d on /var (ufs, local, soft-updates) /dev/ad2s1a on /mnt/oldroot (ufs, local, read-only) /dev/ad2s1g on /mnt/oldroot/home (ufs, local, read-only) /dev/ad2s1f on /mnt/oldroot/usr (ufs, local, read-only) /dev/ad2s1e on /mnt/oldroot/var (ufs, local, read-only) /dev/ad2s1g on /mnt/oldroot/home (ufs, local, read-only) logout::root:~> umount /mnt/oldroot/home logout::root:~> mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1e on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /usr (ufs, local, soft-updates) /dev/ad0s1d on /var (ufs, local, soft-updates) /dev/ad2s1a on /mnt/oldroot (ufs, local, read-only) /dev/ad2s1g on /mnt/oldroot/home (ufs, local, read-only) /dev/ad2s1f on /mnt/oldroot/usr (ufs, local, read-only) /dev/ad2s1e on /mnt/oldroot/var (ufs, local, read-only) logout::root:~> cd /mnt/oldroot/home logout::root:/mnt/oldroot/home> ls After the ls it panicked. The only thing I see in logs is this: Nov 20 12:42:02 logout savecore: reboot after panic: page fault Nov 20 12:42:02 logout savecore: writing core to vmcore.0 Unfortunatelly trying gdb on the core didn't help. The kernel is still the generic one from the release CD: warning: "/var/crash/vmcore.0": no core file handler recognizes format, using default Can't fetch registers from this type of core file Can't fetch registers from this type of core file #0 0x in ?? () I realise that this might have been already fixed after the release. I will try to cvsup the sources and build a new kernel. Vaclav Haisman signature.asc Description: OpenPGP digital signature
Re: Centralized building
On Nov 20, 2005, at 09:50 , Eirik Øverby wrote: On Nov 19, 2005, at 19:43 , Joseph Koshy wrote: AFAICT cross-compiling amd64 on a i386 machine isn't supported yet. I ran into a similar problem when I upgraded an i386 machine to amd64. I thought I could just set CPUTYPE=athlon-64 and buildworld would do the right thing. Apparently not. Bootstrapping a single machine is supported: # make buildworld TARGET_ARCH=new-arch plus a few other steps. (See build(7)). There have been a couple of postings on the mailing lists on this topic in the recent past. I've taken a stab at describing how to cross-bootstrap too: http://edoofus.blogspot.com/2005/10/cross-building-freebsd.html The OP wanted to do a 'buildworld TARGET_ARCH=foo' on one machine and then an 'installworld' on a different set of machines. Yes, and he still wonders if this is supposed to be doable or not. I think the culprit is (partly) the fact that every architecture is built into its own subdirectory in /usr/obj, EXCEPT the architecture the build is running on. The same goes for the install part, and if the build and install architectures differ, it cannot ever work. Setting MAKEOBJDIRPREFIX on the target host makes the install start, but it fails after a couple of minutes with the "dd: not found" error. (I do notice that there is a /usr/obj/usr directory created also when cross-building; I'm assuming this contains the build bootstrap tools). Follow-up. If I enter src/sys and do a "make install", the dd step works perfectly - however it stops later when trying to install cdboot. I am assuming this is due to missing options or wrong target for make, but - from all I can tell - shows a weakness in the build/ install system. Or maybe not... Anyone?? /Eirik -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable- [EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Centralized building
On Nov 19, 2005, at 19:43 , Joseph Koshy wrote: AFAICT cross-compiling amd64 on a i386 machine isn't supported yet. I ran into a similar problem when I upgraded an i386 machine to amd64. I thought I could just set CPUTYPE=athlon-64 and buildworld would do the right thing. Apparently not. Bootstrapping a single machine is supported: # make buildworld TARGET_ARCH=new-arch plus a few other steps. (See build(7)). There have been a couple of postings on the mailing lists on this topic in the recent past. I've taken a stab at describing how to cross-bootstrap too: http://edoofus.blogspot.com/2005/10/cross-building-freebsd.html The OP wanted to do a 'buildworld TARGET_ARCH=foo' on one machine and then an 'installworld' on a different set of machines. Yes, and he still wonders if this is supposed to be doable or not. I think the culprit is (partly) the fact that every architecture is built into its own subdirectory in /usr/obj, EXCEPT the architecture the build is running on. The same goes for the install part, and if the build and install architectures differ, it cannot ever work. Setting MAKEOBJDIRPREFIX on the target host makes the install start, but it fails after a couple of minutes with the "dd: not found" error. (I do notice that there is a /usr/obj/usr directory created also when cross-building; I'm assuming this contains the build bootstrap tools). -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI problems with Dell laptops? (was: Jerky keyboard and mouse)
On Saturday, 19 November 2005 at 21:37:03 -0600, Stephen Montgomery-Smith wrote: > I recently upgraded from stable-6 of Nov 4 to stable-6 of today on > my Dell Latitude D800 Laptop, and suddenly the response of the > touchpad mouse and keyboard was bery bad. Heh. I saw the subject line and thought "I wonder if this is a Dell laptop". > In particular, when I type about 1 in 10 key presses simply do not > register. This, however, is a order of magnitude worse than what I have experienced with my Inspiron 6100. > I ended up going back to the Nov 4 stable-6, which fixed the > problem. Well, it worked around it. > Any ideas? I am happy to provide any details you may need. I'd guess that this is another ACPI issue like the one I reported a couple of weeks back. In my case, it was slow, but I didn't lose any keystrokes. What happens when you ping another system? I found that the ping time was normal (in the order of 1 µs), but it repeated only every 3 seconds. When I unloaded ACPI, things worked normally. I'm following this up to the ACPI list with a reminder that my message has been there for 2 weeks. How do I localize the problem? Greg -- See complete headers for address and phone numbers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
